Re: [PATCH v3 hmm 11/12] mm/hmm: Remove confusing comment and logic from hmm_release
On Sat, Jun 15, 2019 at 07:21:06AM -0700, Christoph Hellwig wrote:
> On Thu, Jun 13, 2019 at 09:44:49PM -0300, Jason Gunthorpe wrote:
> > From: Jason Gunthorpe
> >
> > hmm_release() is called exactly once per hmm. ops->release() cannot
> > accidentally trigger any action that would recurse back onto
> > hmm->mirrors_sem.
>
> In linux-next amdgpu actually calls hmm_mirror_unregister from its
> release function. That whole release function looks rather sketchy,
> but we probably need to sort that out first.
Does it? I see this:
static void amdgpu_hmm_mirror_release(struct hmm_mirror *mirror)
{
struct amdgpu_mn *amn = container_of(mirror, struct amdgpu_mn, mirror);
INIT_WORK(&amn->work, amdgpu_mn_destroy);
schedule_work(&amn->work);
}
static struct hmm_mirror_ops amdgpu_hmm_mirror_ops[] = {
[AMDGPU_MN_TYPE_GFX] = {
.sync_cpu_device_pagetables = amdgpu_mn_sync_pagetables_gfx,
.release = amdgpu_hmm_mirror_release
},
[AMDGPU_MN_TYPE_HSA] = {
.sync_cpu_device_pagetables = amdgpu_mn_sync_pagetables_hsa,
.release = amdgpu_hmm_mirror_release
},
};
Am I looking at the wrong thing? Looks like it calls it through a work
queue should should be OK..
Though very strange that amdgpu only destroys the mirror via release,
that cannot be right.
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/7] lib/hexdump.c: Relax rowsize checks in hex_dump_to_buffer
On Mon, 2019-06-17 at 15:47 -0700, Randy Dunlap wrote:
> Hi,
> Just a comment style nit below...
>
> On 6/16/19 7:04 PM, Alastair D'Silva wrote:
> > From: Alastair D'Silva
> >
> > This patch removes the hardcoded row limits and allows for
> > other lengths. These lengths must still be a multiple of
> > groupsize.
> >
> > This allows structs that are not 16/32 bytes to display on
> > a single line.
> >
> > This patch also expands the self-tests to test row sizes
> > up to 64 bytes (though they can now be arbitrarily long).
> >
> > Signed-off-by: Alastair D'Silva
> > ---
> > lib/hexdump.c | 48 --
> > lib/test_hexdump.c | 52 ++--
> > --
> > 2 files changed, 75 insertions(+), 25 deletions(-)
> >
> > diff --git a/lib/hexdump.c b/lib/hexdump.c
> > index 81b70ed37209..3943507bc0e9 100644
> > --- a/lib/hexdump.c
> > +++ b/lib/hexdump.c
> > @@ -246,17 +248,29 @@ void print_hex_dump(const char *level, const
> > char *prefix_str, int prefix_type,
> > {
> > const u8 *ptr = buf;
> > int i, linelen, remaining = len;
> > - unsigned char linebuf[32 * 3 + 2 + 32 + 1];
> > + unsigned char *linebuf;
> > + unsigned int linebuf_len;
> >
> > - if (rowsize != 16 && rowsize != 32)
> > - rowsize = 16;
> > + if (rowsize % groupsize)
> > + rowsize -= rowsize % groupsize;
> > +
> > + /* Worst case line length:
> > +* 2 hex chars + space per byte in, 2 spaces, 1 char per byte
> > in, NULL
> > +*/
>
> According to Documentation/process/coding-style.rst:
>
> The preferred style for long (multi-line) comments is:
>
> .. code-block:: c
>
> /*
>* This is the preferred style for multi-line
>* comments in the Linux kernel source code.
>* Please use it consistently.
>*
>* Description: A column of asterisks on the left side,
>* with beginning and ending almost-blank lines.
>*/
>
Thanks Randy, I'll address this.
--
Alastair D'Silva mob: 0423 762 819
skype: alastair_dsilva
Twitter: @EvilDeece
blog: http://alastair.d-silva.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v17 03/15] arm64: Introduce prctl() options to control the tagged user addresses ABI
On 17/06/2019 14:56, Catalin Marinas wrote: > On Wed, Jun 12, 2019 at 01:43:20PM +0200, Andrey Konovalov wrote: >> From: Catalin Marinas >> >> It is not desirable to relax the ABI to allow tagged user addresses into >> the kernel indiscriminately. This patch introduces a prctl() interface >> for enabling or disabling the tagged ABI with a global sysctl control >> for preventing applications from enabling the relaxed ABI (meant for >> testing user-space prctl() return error checking without reconfiguring >> the kernel). The ABI properties are inherited by threads of the same >> application and fork()'ed children but cleared on execve(). >> >> The PR_SET_TAGGED_ADDR_CTRL will be expanded in the future to handle >> MTE-specific settings like imprecise vs precise exceptions. >> >> Signed-off-by: Catalin Marinas > > A question for the user-space folk: if an application opts in to this > ABI, would you want the sigcontext.fault_address and/or siginfo.si_addr > to contain the tag? We currently clear it early in the arm64 entry.S but > we could find a way to pass it down if needed. to me it makes sense to keep the tag in si_addr / fault_address. but i don't know in detail how those fields are used currently. keeping the tag is certainly useful for MTE to debug wrong tag failures unless there is a separate mechanism for that. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 16/25] PCI/P2PDMA: use the dev_pagemap internal refcount
On 2019-06-17 6:27 a.m., Christoph Hellwig wrote:
> The functionality is identical to the one currently open coded in
> p2pdma.c.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Logan Gunthorpe
I also did a quick test with the full patch-set to ensure that the setup
and tear down paths for p2pdma still work correctly and it all does.
Thanks,
Logan
> ---
> drivers/pci/p2pdma.c | 56
> 1 file changed, 4 insertions(+), 52 deletions(-)
>
> diff --git a/drivers/pci/p2pdma.c b/drivers/pci/p2pdma.c
> index 48a88158e46a..608f84df604a 100644
> --- a/drivers/pci/p2pdma.c
> +++ b/drivers/pci/p2pdma.c
> @@ -24,12 +24,6 @@ struct pci_p2pdma {
> bool p2pmem_published;
> };
>
> -struct p2pdma_pagemap {
> - struct dev_pagemap pgmap;
> - struct percpu_ref ref;
> - struct completion ref_done;
> -};
> -
> static ssize_t size_show(struct device *dev, struct device_attribute *attr,
>char *buf)
> {
> @@ -78,32 +72,6 @@ static const struct attribute_group p2pmem_group = {
> .name = "p2pmem",
> };
>
> -static struct p2pdma_pagemap *to_p2p_pgmap(struct percpu_ref *ref)
> -{
> - return container_of(ref, struct p2pdma_pagemap, ref);
> -}
> -
> -static void pci_p2pdma_percpu_release(struct percpu_ref *ref)
> -{
> - struct p2pdma_pagemap *p2p_pgmap = to_p2p_pgmap(ref);
> -
> - complete(&p2p_pgmap->ref_done);
> -}
> -
> -static void pci_p2pdma_percpu_kill(struct dev_pagemap *pgmap)
> -{
> - percpu_ref_kill(pgmap->ref);
> -}
> -
> -static void pci_p2pdma_percpu_cleanup(struct dev_pagemap *pgmap)
> -{
> - struct p2pdma_pagemap *p2p_pgmap =
> - container_of(pgmap, struct p2pdma_pagemap, pgmap);
> -
> - wait_for_completion(&p2p_pgmap->ref_done);
> - percpu_ref_exit(&p2p_pgmap->ref);
> -}
> -
> static void pci_p2pdma_release(void *data)
> {
> struct pci_dev *pdev = data;
> @@ -153,11 +121,6 @@ static int pci_p2pdma_setup(struct pci_dev *pdev)
> return error;
> }
>
> -static const struct dev_pagemap_ops pci_p2pdma_pagemap_ops = {
> - .kill = pci_p2pdma_percpu_kill,
> - .cleanup= pci_p2pdma_percpu_cleanup,
> -};
> -
> /**
> * pci_p2pdma_add_resource - add memory for use as p2p memory
> * @pdev: the device to add the memory to
> @@ -171,7 +134,6 @@ static const struct dev_pagemap_ops
> pci_p2pdma_pagemap_ops = {
> int pci_p2pdma_add_resource(struct pci_dev *pdev, int bar, size_t size,
> u64 offset)
> {
> - struct p2pdma_pagemap *p2p_pgmap;
> struct dev_pagemap *pgmap;
> void *addr;
> int error;
> @@ -194,22 +156,12 @@ int pci_p2pdma_add_resource(struct pci_dev *pdev, int
> bar, size_t size,
> return error;
> }
>
> - p2p_pgmap = devm_kzalloc(&pdev->dev, sizeof(*p2p_pgmap), GFP_KERNEL);
> - if (!p2p_pgmap)
> + pgmap = devm_kzalloc(&pdev->dev, sizeof(*pgmap), GFP_KERNEL);
> + if (!pgmap)
> return -ENOMEM;
> -
> - init_completion(&p2p_pgmap->ref_done);
> - error = percpu_ref_init(&p2p_pgmap->ref,
> - pci_p2pdma_percpu_release, 0, GFP_KERNEL);
> - if (error)
> - goto pgmap_free;
> -
> - pgmap = &p2p_pgmap->pgmap;
> -
> pgmap->res.start = pci_resource_start(pdev, bar) + offset;
> pgmap->res.end = pgmap->res.start + size - 1;
> pgmap->res.flags = pci_resource_flags(pdev, bar);
> - pgmap->ref = &p2p_pgmap->ref;
> pgmap->type = MEMORY_DEVICE_PCI_P2PDMA;
> pgmap->pci_p2pdma_bus_offset = pci_bus_address(pdev, bar) -
> pci_resource_start(pdev, bar);
> @@ -223,7 +175,7 @@ int pci_p2pdma_add_resource(struct pci_dev *pdev, int
> bar, size_t size,
> error = gen_pool_add_owner(pdev->p2pdma->pool, (unsigned long)addr,
> pci_bus_address(pdev, bar) + offset,
> resource_size(&pgmap->res), dev_to_node(&pdev->dev),
> - &p2p_pgmap->ref);
> + pgmap->ref);
> if (error)
> goto pages_free;
>
> @@ -235,7 +187,7 @@ int pci_p2pdma_add_resource(struct pci_dev *pdev, int
> bar, size_t size,
> pages_free:
> devm_memunmap_pages(&pdev->dev, pgmap);
> pgmap_free:
> - devm_kfree(&pdev->dev, p2p_pgmap);
> + devm_kfree(&pdev->dev, pgmap);
> return error;
> }
> EXPORT_SYMBOL_GPL(pci_p2pdma_add_resource);
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm v2 4/4] meson.build: Fix meson script on FreeBSD
On 2019-06-17 11:14, Eric Engestrom wrote: On Sunday, 2019-06-16 14:23:43 +0100, Emil Velikov wrote: From: Niclas Zeising FreeBSD requires sys/types.h for sys/sysctl.h, add it as part of the includes when checking for headers. Instead of splitting out the check for sys/sysctl.h from the other header checks, just add sys/types.h to all header checks. v2 [Emil] - add inline comment - drop bash/sh hunk Signed-off-by: Emil Velikov Series is: Reviewed-by: Eric Engestrom But I agree with Emil, it's a FreeBSD bug for it to not include a required header, this should also be fixed upstream. I'm not sure if my e-mails are getting to the mailing list. This is the way it's documented in FreeBSD, and there is a lot of legacy reasons it is this way. I doubt it will change, and even if it does, there will be about 5 years of transition period before all supported releases has the change, most likely. This is the first time, to my knowledge, this issue has come up. (I'm not saying I disagree with you, just saying it's probably easier to patch here rather than try to change upstream.) Regards -- Niclas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amd/powerplay: Delete a redundant memory setting in vega20_set_default_od8_setttings()
From: Markus Elfring
Date: Mon, 17 Jun 2019 14:24:14 +0200
The memory was set to zero already by a call of the function “kzalloc”.
Thus remove an extra call of the function “memset” for this purpose.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/gpu/drm/amd/powerplay/vega20_ppt.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/powerplay/vega20_ppt.c
b/drivers/gpu/drm/amd/powerplay/vega20_ppt.c
index 4aa8f5a69c4c..62497ad66a39 100644
--- a/drivers/gpu/drm/amd/powerplay/vega20_ppt.c
+++ b/drivers/gpu/drm/amd/powerplay/vega20_ppt.c
@@ -1295,7 +1295,6 @@ static int vega20_set_default_od8_setttings(struct
smu_context *smu)
if (!table_context->od8_settings)
return -ENOMEM;
- memset(table_context->od8_settings, 0, sizeof(struct
vega20_od8_settings));
od8_settings = (struct vega20_od8_settings
*)table_context->od8_settings;
if (smu_feature_is_enabled(smu, FEATURE_DPM_SOCCLK_BIT)) {
--
2.22.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] arm: dts: add ARM Mali GPU node for Odroid XU3
Hi Krzysztof,
Thanks for the review.
On Sun, Jun 16, 2019 at 1:59 AM Krzysztof Kozlowski wrote:
>
> On Fri, Jun 14, 2019 at 04:57:19PM -0700, Joseph Kogut wrote:
> > Add device tree node for mali gpu on Odroid XU3 SoCs.
> >
> > Signed-off-by: Joseph Kogut
> > ---
> >
> > Changes v1 -> v2:
> > - Use interrupt name ordering from binding doc
> > - Specify a single clock for GPU node
> > - Add gpu opp table
> > - Fix warnings from IRQ_TYPE_NONE
> >
> > .../boot/dts/exynos5422-odroidxu3-common.dtsi | 26 +++
>
> This should go to exynos5422-odroid-core.dtsi instead, because it is
> common to entire Odroid Exynos5422 family (not only XU3 family).
>
> > 1 file changed, 26 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> > b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> > index 93a48f2dda49..b8a4246e3b37 100644
> > --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> > +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> > @@ -48,6 +48,32 @@
> > cooling-levels = <0 130 170 230>;
> > };
> >
> > + gpu: gpu@1180 {
> > + compatible = "samsung,exynos-mali", "arm,mali-t628";
>
> This is common to all Exynos542x chips so it should go to
> exynos5420.dtsi. Here you would need to only enable it and provide
> regulator.
>
To clarify, which pieces are specific to the Odroid Exynos 5422
family, and which are common to the entire Exynos 542x family? I'm
thinking the gpu node is common to the 542x family, including the
interrupts and clock, and the regulator and opp table are specific to
the Odroid 5422?
> Probably this should be also associated with tmu_gpu as a cooling device
> (if Mali registers a cooling device...). Otherwise the tmu_gpu is not
> really used for it.
>
We have two operating performance points for the GPU, but I'm not sure
at what temperature we should trip the lower opp. Looking at the trip
temperatures for the CPU, we have four alerts, and one critical trip.
The highest alert is 85 C, would it be reasonable to trigger the lower
GPU opp at this temperature? Should it trigger sooner?
> > + reg = <0x1180 0x5000>;
> > + interrupts = ,
> > + ,
> > + ;
> > + interrupt-names = "job", "mmu", "gpu";
> > + clocks = <&clock CLK_G3D>;
> > + mali-supply = <&buck4_reg>;
>
> Please check if always-on property could be removed from buck4.
I've checked, and this property can be removed safely.
> Also, what about LDO27? It should be used as well (maybe through
> vendor-specific properties which would justify the need of new vendor
> compatible).
>
I'm unsure how LDO27 is used, can you elaborate?
Best,
Joseph
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v17 03/15] arm64: Introduce prctl() options to control the tagged user addresses ABI
On Mon, Jun 17, 2019 at 09:57:36AM -0700, Evgenii Stepanov wrote: > On Mon, Jun 17, 2019 at 6:56 AM Catalin Marinas > wrote: > > On Wed, Jun 12, 2019 at 01:43:20PM +0200, Andrey Konovalov wrote: > > > From: Catalin Marinas > > > > > > It is not desirable to relax the ABI to allow tagged user addresses into > > > the kernel indiscriminately. This patch introduces a prctl() interface > > > for enabling or disabling the tagged ABI with a global sysctl control > > > for preventing applications from enabling the relaxed ABI (meant for > > > testing user-space prctl() return error checking without reconfiguring > > > the kernel). The ABI properties are inherited by threads of the same > > > application and fork()'ed children but cleared on execve(). > > > > > > The PR_SET_TAGGED_ADDR_CTRL will be expanded in the future to handle > > > MTE-specific settings like imprecise vs precise exceptions. > > > > > > Signed-off-by: Catalin Marinas > > > > A question for the user-space folk: if an application opts in to this > > ABI, would you want the sigcontext.fault_address and/or siginfo.si_addr > > to contain the tag? We currently clear it early in the arm64 entry.S but > > we could find a way to pass it down if needed. > > For HWASan this would not be useful because we instrument memory > accesses with explicit checks anyway. For MTE, on the other hand, it > would be very convenient to know the fault address tag without > disassembling the code. I could as this differently: does anything break if, once the user opts in to TBI, fault_address and/or si_addr have non-zero top byte? Alternatively, we could present the original FAR_EL1 register as a separate field as we do with ESR_EL1, independently of whether the user opted in to TBI or not. -- Catalin ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 hmm 10/12] mm/hmm: Do not use list*_rcu() for hmm->ranges
On Sat, Jun 15, 2019 at 07:18:26AM -0700, Christoph Hellwig wrote: > On Thu, Jun 13, 2019 at 09:44:48PM -0300, Jason Gunthorpe wrote: > > range->hmm = hmm; > > kref_get(&hmm->kref); > > - list_add_rcu(&range->list, &hmm->ranges); > > + list_add(&range->list, &hmm->ranges); > > > > /* > > * If there are any concurrent notifiers we have to wait for them for > > @@ -934,7 +934,7 @@ void hmm_range_unregister(struct hmm_range *range) > > struct hmm *hmm = range->hmm; > > > > mutex_lock(&hmm->lock); > > - list_del_rcu(&range->list); > > + list_del(&range->list); > > mutex_unlock(&hmm->lock); > > Looks fine: > > Signed-off-by: Christoph Hellwig > > Btw, is there any reason new ranges are added to the front and not the > tail of the list? Couldn't find one. I think order on this list doesn't matter. Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 08/25] memremap: move dev_pagemap callbacks into a separate structure
On 2019-06-17 6:27 a.m., Christoph Hellwig wrote:
> diff --git a/drivers/pci/p2pdma.c b/drivers/pci/p2pdma.c
> index a98126ad9c3a..e083567d26ef 100644
> --- a/drivers/pci/p2pdma.c
> +++ b/drivers/pci/p2pdma.c
> @@ -100,7 +100,7 @@ static void pci_p2pdma_percpu_cleanup(struct percpu_ref
> *ref)
> struct p2pdma_pagemap *p2p_pgmap = to_p2p_pgmap(ref);
>
> wait_for_completion(&p2p_pgmap->ref_done);
> - percpu_ref_exit(&p2p_pgmap->ref);
> + percpu_ref_exit(ref);
> }
>
> static void pci_p2pdma_release(void *data)
> @@ -152,6 +152,11 @@ static int pci_p2pdma_setup(struct pci_dev *pdev)
> return error;
> }
>
> +static const struct dev_pagemap_ops pci_p2pdma_pagemap_ops = {
> + .kill = pci_p2pdma_percpu_kill,
> + .cleanup= pci_p2pdma_percpu_cleanup,
> +};
> +
> /**
> * pci_p2pdma_add_resource - add memory for use as p2p memory
> * @pdev: the device to add the memory to
> @@ -207,8 +212,6 @@ int pci_p2pdma_add_resource(struct pci_dev *pdev, int
> bar, size_t size,
> pgmap->type = MEMORY_DEVICE_PCI_P2PDMA;
> pgmap->pci_p2pdma_bus_offset = pci_bus_address(pdev, bar) -
> pci_resource_start(pdev, bar);
> - pgmap->kill = pci_p2pdma_percpu_kill;
> - pgmap->cleanup = pci_p2pdma_percpu_cleanup;
I just noticed this is missing a line to set pgmap->ops to
pci_p2pdma_pagemap_ops. I must have gotten confused by the other users
in my original review. Though I'm not sure how this compiles as the new
struct is static and unused. However, it is rendered moot in Patch 16
when this is all removed.
Logan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 hmm 04/12] mm/hmm: Simplify hmm_get_or_create and make it reliable
On Sat, Jun 15, 2019 at 07:12:11AM -0700, Christoph Hellwig wrote:
> > + spin_lock(&mm->page_table_lock);
> > + if (mm->hmm) {
> > + if (kref_get_unless_zero(&mm->hmm->kref)) {
> > + spin_unlock(&mm->page_table_lock);
> > + return mm->hmm;
> > + }
> > + }
> > + spin_unlock(&mm->page_table_lock);
>
> This could become:
>
> spin_lock(&mm->page_table_lock);
> hmm = mm->hmm
> if (hmm && kref_get_unless_zero(&hmm->kref))
> goto out_unlock;
> spin_unlock(&mm->page_table_lock);
>
> as the last two lines of the function already drop the page_table_lock
> and then return hmm. Or drop the "hmm = mm->hmm" asignment above and
> return mm->hmm as that should be always identical to hmm at the end
> to save another line.
Yeah, I can fuss it some more.
> > + /*
> > +* The mm->hmm pointer is kept valid while notifier ops can be running
> > +* so they don't have to deal with a NULL mm->hmm value
> > +*/
>
> The comment confuses me. How does the page_table_lock relate to
> possibly running notifiers, as I can't find that we take
> page_table_lock? Or is it just about the fact that we only clear
> mm->hmm in the free callback, and not in hmm_free?
It was late when I wrote this fixup, the comment is faulty, and there
is no reason to delay this until the SRCU cleanup at this point in the
series.
The ops all get their struct hmm from container_of, the only thing
that refers to mm->hmm is hmm_get_or_create().
I'll revise it tomorrow, the comment will go away and the =NULL will
go to the release callback
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] Re: [PATCH v2 5/9] drm/sun4i: tcon_top: Register clock gates in probe
On Mon, Jun 17, 2019 at 6:31 PM Chen-Yu Tsai wrote: > > On Mon, Jun 17, 2019 at 7:45 PM Maxime Ripard > wrote: > > > > On Fri, Jun 14, 2019 at 10:13:20PM +0530, Jagan Teki wrote: > > > TCON TOP have clock gates for TV0, TV1, dsi and right > > > now these are register during bind call. > > > > > > Of which, dsi clock gate would required during DPHY probe > > > but same can miss to get since tcon top is not bound at > > > that time. > > > > > > To solve, this circular dependency move the clock gate > > > registration from bind to probe so-that DPHY can get the > > > dsi gate clock on time. > > > > It's not really clear to me what the circular dependency is? > > > > if you have a chain that is: > > > > tcon-top +-> DSI > > +-> D-PHY > > > > There's no loop, right? > > Looking at how the DTSI patch structures things (without going into > whether it is correct or accurate): > > The D-PHY is not part of the component graph. However it requests > the DSI gate clock from the TCON-TOP. > > The TCON-TOP driver, in its current form, only registers the clocks > it provides at component bind time. Thus the D-PHY can't successfully > probe until the TCON-TOP has been bound. > > The DSI interface requires the D-PHY to bind. It will return -EPROBE_DEFER > if it cannot request it. This in turn goes into the error path of > component_bind_all, which unbinds all previous components. > > So it's actually > > D-PHY -> TCON-TOP -> DSI > ^ | > | > > I've not checked, but I suspect there's no possibility of having other > drivers probe (to deal with deferred probing) within component_bind_all. > Otherwise we shouldn't run into this weird circular dependency issue. > > So the question for Jagan is that is this indeed the case? Does this > patch solve it, or at least work around it. Yes, this is what I was mentioned in initial version, since the "dsi" gate in tcon top is registering during bind, the dphy of dsi controller won't get the associated clock for "mod" so it is keep on returning -EPROBE_DEFER. By moving the clock gate registration to probe, everything bound as expected. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v17 03/15] arm64: Introduce prctl() options to control the tagged user addresses ABI
On Wed, Jun 12, 2019 at 01:43:20PM +0200, Andrey Konovalov wrote: > From: Catalin Marinas > > It is not desirable to relax the ABI to allow tagged user addresses into > the kernel indiscriminately. This patch introduces a prctl() interface > for enabling or disabling the tagged ABI with a global sysctl control > for preventing applications from enabling the relaxed ABI (meant for > testing user-space prctl() return error checking without reconfiguring > the kernel). The ABI properties are inherited by threads of the same > application and fork()'ed children but cleared on execve(). > > The PR_SET_TAGGED_ADDR_CTRL will be expanded in the future to handle > MTE-specific settings like imprecise vs precise exceptions. > > Signed-off-by: Catalin Marinas A question for the user-space folk: if an application opts in to this ABI, would you want the sigcontext.fault_address and/or siginfo.si_addr to contain the tag? We currently clear it early in the arm64 entry.S but we could find a way to pass it down if needed. -- Catalin ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v17 03/15] arm64: Introduce prctl() options to control the tagged user addresses ABI
On Mon, Jun 17, 2019 at 10:18 AM Catalin Marinas wrote: > > On Mon, Jun 17, 2019 at 09:57:36AM -0700, Evgenii Stepanov wrote: > > On Mon, Jun 17, 2019 at 6:56 AM Catalin Marinas > > wrote: > > > On Wed, Jun 12, 2019 at 01:43:20PM +0200, Andrey Konovalov wrote: > > > > From: Catalin Marinas > > > > > > > > It is not desirable to relax the ABI to allow tagged user addresses into > > > > the kernel indiscriminately. This patch introduces a prctl() interface > > > > for enabling or disabling the tagged ABI with a global sysctl control > > > > for preventing applications from enabling the relaxed ABI (meant for > > > > testing user-space prctl() return error checking without reconfiguring > > > > the kernel). The ABI properties are inherited by threads of the same > > > > application and fork()'ed children but cleared on execve(). > > > > > > > > The PR_SET_TAGGED_ADDR_CTRL will be expanded in the future to handle > > > > MTE-specific settings like imprecise vs precise exceptions. > > > > > > > > Signed-off-by: Catalin Marinas > > > > > > A question for the user-space folk: if an application opts in to this > > > ABI, would you want the sigcontext.fault_address and/or siginfo.si_addr > > > to contain the tag? We currently clear it early in the arm64 entry.S but > > > we could find a way to pass it down if needed. > > > > For HWASan this would not be useful because we instrument memory > > accesses with explicit checks anyway. For MTE, on the other hand, it > > would be very convenient to know the fault address tag without > > disassembling the code. > > I could as this differently: does anything break if, once the user > opts in to TBI, fault_address and/or si_addr have non-zero top byte? I think it would be fine. > Alternatively, we could present the original FAR_EL1 register as a > separate field as we do with ESR_EL1, independently of whether the user > opted in to TBI or not. > > -- > Catalin ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v17 03/15] arm64: Introduce prctl() options to control the tagged user addresses ABI
On Mon, Jun 17, 2019 at 6:56 AM Catalin Marinas wrote: > > On Wed, Jun 12, 2019 at 01:43:20PM +0200, Andrey Konovalov wrote: > > From: Catalin Marinas > > > > It is not desirable to relax the ABI to allow tagged user addresses into > > the kernel indiscriminately. This patch introduces a prctl() interface > > for enabling or disabling the tagged ABI with a global sysctl control > > for preventing applications from enabling the relaxed ABI (meant for > > testing user-space prctl() return error checking without reconfiguring > > the kernel). The ABI properties are inherited by threads of the same > > application and fork()'ed children but cleared on execve(). > > > > The PR_SET_TAGGED_ADDR_CTRL will be expanded in the future to handle > > MTE-specific settings like imprecise vs precise exceptions. > > > > Signed-off-by: Catalin Marinas > > A question for the user-space folk: if an application opts in to this > ABI, would you want the sigcontext.fault_address and/or siginfo.si_addr > to contain the tag? We currently clear it early in the arm64 entry.S but > we could find a way to pass it down if needed. For HWASan this would not be useful because we instrument memory accesses with explicit checks anyway. For MTE, on the other hand, it would be very convenient to know the fault address tag without disassembling the code. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/7] lib/hexdump.c: Relax rowsize checks in hex_dump_to_buffer
Hi,
Just a comment style nit below...
On 6/16/19 7:04 PM, Alastair D'Silva wrote:
> From: Alastair D'Silva
>
> This patch removes the hardcoded row limits and allows for
> other lengths. These lengths must still be a multiple of
> groupsize.
>
> This allows structs that are not 16/32 bytes to display on
> a single line.
>
> This patch also expands the self-tests to test row sizes
> up to 64 bytes (though they can now be arbitrarily long).
>
> Signed-off-by: Alastair D'Silva
> ---
> lib/hexdump.c | 48 --
> lib/test_hexdump.c | 52 ++
> 2 files changed, 75 insertions(+), 25 deletions(-)
>
> diff --git a/lib/hexdump.c b/lib/hexdump.c
> index 81b70ed37209..3943507bc0e9 100644
> --- a/lib/hexdump.c
> +++ b/lib/hexdump.c
> @@ -246,17 +248,29 @@ void print_hex_dump(const char *level, const char
> *prefix_str, int prefix_type,
> {
> const u8 *ptr = buf;
> int i, linelen, remaining = len;
> - unsigned char linebuf[32 * 3 + 2 + 32 + 1];
> + unsigned char *linebuf;
> + unsigned int linebuf_len;
>
> - if (rowsize != 16 && rowsize != 32)
> - rowsize = 16;
> + if (rowsize % groupsize)
> + rowsize -= rowsize % groupsize;
> +
> + /* Worst case line length:
> + * 2 hex chars + space per byte in, 2 spaces, 1 char per byte in, NULL
> + */
According to Documentation/process/coding-style.rst:
The preferred style for long (multi-line) comments is:
.. code-block:: c
/*
* This is the preferred style for multi-line
* comments in the Linux kernel source code.
* Please use it consistently.
*
* Description: A column of asterisks on the left side,
* with beginning and ending almost-blank lines.
*/
except in networking software.
> + linebuf_len = rowsize * 3 + 2 + rowsize + 1;
> + linebuf = kzalloc(linebuf_len, GFP_KERNEL);
> + if (!linebuf) {
> + printk("%s%shexdump: Could not alloc %u bytes for buffer\n",
> + level, prefix_str, linebuf_len);
> + return;
> + }
--
~Randy
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amd/display: Delete a redundant memory setting in amdgpu_dm_irq_register_interrupt()
From: Markus Elfring Date: Mon, 17 Jun 2019 13:56:39 +0200 The memory was set to zero already by a call of the function “kzalloc”. Thus remove an extra call of the function “memset” for this purpose. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c index 1b59d3d42f7b..fa5d503d379c 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c @@ -277,8 +277,6 @@ void *amdgpu_dm_irq_register_interrupt(struct amdgpu_device *adev, return DAL_INVALID_IRQ_HANDLER_IDX; } - memset(handler_data, 0, sizeof(*handler_data)); - init_handler_common_data(handler_data, ih, handler_args, &adev->dm); irq_source = int_params->irq_source; -- 2.22.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amd/display: Add missing newline at end of file
"git diff" says: \ No newline at end of file after modifying the file. Signed-off-by: Geert Uytterhoeven --- drivers/gpu/drm/amd/display/modules/power/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/modules/power/Makefile b/drivers/gpu/drm/amd/display/modules/power/Makefile index 87851f892a52d372..9d1b22d35ece9136 100644 --- a/drivers/gpu/drm/amd/display/modules/power/Makefile +++ b/drivers/gpu/drm/amd/display/modules/power/Makefile @@ -28,4 +28,4 @@ MOD_POWER = power_helpers.o AMD_DAL_MOD_POWER = $(addprefix $(AMDDALPATH)/modules/power/,$(MOD_POWER)) #$(info DAL POWER MODULE MAKEFILE ) -AMD_DISPLAY_FILES += $(AMD_DAL_MOD_POWER) \ No newline at end of file +AMD_DISPLAY_FILES += $(AMD_DAL_MOD_POWER) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
arm32 build failure after abe882a39a9c ("drm/amd/display: fix issue with eDP not detected on driver load")
Hi all,
After commit abe882a39a9c ("drm/amd/display: fix issue with eDP not
detected on driver load") in -next, arm32 allyesconfig builds start
failing at link time:
arm-linux-gnueabi-ld: drivers/gpu/drm/amd/display/dc/core/dc_link.o: in
function `dc_link_detect':
dc_link.c:(.text+0x260c): undefined reference to `__bad_udelay'
arm32 only allows a udelay value of up to 2000, see
arch/arm/include/asm/delay.h for more info.
Please look into this when you have a chance!
Nathan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] [PATCH v2 5/9] drm/sun4i: tcon_top: Register clock gates in probe
On Mon, Jun 17, 2019 at 6:30 PM Jagan Teki wrote:
>
> On Sun, Jun 16, 2019 at 11:01 AM Chen-Yu Tsai wrote:
> >
> > On Sat, Jun 15, 2019 at 12:44 AM Jagan Teki
> > wrote:
> > >
> > > TCON TOP have clock gates for TV0, TV1, dsi and right
> > > now these are register during bind call.
> > >
> > > Of which, dsi clock gate would required during DPHY probe
> > > but same can miss to get since tcon top is not bound at
> > > that time.
> > >
> > > To solve, this circular dependency move the clock gate
> > > registration from bind to probe so-that DPHY can get the
> > > dsi gate clock on time.
> > >
> > > Signed-off-by: Jagan Teki
> > > ---
> > > drivers/gpu/drm/sun4i/sun8i_tcon_top.c | 94 ++
> > > 1 file changed, 49 insertions(+), 45 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
> > > b/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
> > > index 465e9b0cdfee..a8978b3fe851 100644
> > > --- a/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
> > > +++ b/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
> > > @@ -124,7 +124,53 @@ static struct clk_hw
> > > *sun8i_tcon_top_register_gate(struct device *dev,
> > > static int sun8i_tcon_top_bind(struct device *dev, struct device *master,
> > >void *data)
> > > {
> > > - struct platform_device *pdev = to_platform_device(dev);
> > > + struct sun8i_tcon_top *tcon_top = dev_get_drvdata(dev);
> > > + int ret;
> > > +
> > > + ret = reset_control_deassert(tcon_top->rst);
> > > + if (ret) {
> > > + dev_err(dev, "Could not deassert ctrl reset control\n");
> > > + return ret;
> > > + }
> > > +
> > > + ret = clk_prepare_enable(tcon_top->bus);
> > > + if (ret) {
> > > + dev_err(dev, "Could not enable bus clock\n");
> > > + goto err_assert_reset;
> > > + }
> >
> > You have to de-assert the reset control and enable the clock before the
> > clocks it provides are registered. Otherwise a consumer may come in and
> > ask for the provided clock to be enabled, but since the TCON TOP's own
> > reset and clock are still disabled, you can't actually access the registers
> > that controls the provided clock.
>
> These rst and bus are common reset and bus clocks not tcon top clocks
> that are trying to register here. ie reason I have not moved it in
> top.
And you're sure that toggling bits in the TCON TOP block doesn't require
the reset to be de-asserted and the bus clock enabled?
Somehow I doubt that.
Once the driver register the clocks it provides, they absolutely must work.
They can't only work after the bind phase when the reset gets de-asserted
and the bus clock enabled. Or you should provide proper error reporting
in the clock ops. I doubt you want to go that way either.
ChenYu
Re: [EXT] Re: [PATCH 2/2] drm/panel: Add support for Raydium RM67191 panel driver
Hi Sam,
Thank you for your suggestions.
See my reply inline.
On Vi, 2019-06-14 at 17:10 +0200, Sam Ravnborg wrote:
> Hi Robert.
>
> On top of the feedback from Fabio here is a bit more.
>
> >
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> Divide include up in block in following order:
>
> #include
>
> #include
>
> #incude
>
> Within each block sort alphabetically.
> Do not use the deprecated drmP.h - replace it with the necessary
> includes.
> Use an empty line between each include block.
Thanks. Will do.
>
> >
> > +
> > +/* Write Manufacture Command Set Control */
> > +#define WRMAUCCTR 0xFE
> > +
> > +/* Manufacturer Command Set pages (CMD2) */
> > +struct cmd_set_entry {
> > + u8 cmd;
> > + u8 param;
> > +};
> > +
> > +/*
> > + * There is no description in the Reference Manual about these
> > commands.
> > + * We received them from vendor, so just use them as is.
> > + */
> > +static const struct cmd_set_entry manufacturer_cmd_set[] = {
> > + {0xFE, 0x0B},
> > + {0x28, 0x40},
> > + {0x29, 0x4F},
> ...
> >
> > + {0x51, 0x04},
> > +};
> > +
> > +static const u32 rad_bus_formats[] = {
> > + MEDIA_BUS_FMT_RGB888_1X24,
> > + MEDIA_BUS_FMT_RGB666_1X18,
> > + MEDIA_BUS_FMT_RGB565_1X16,
> > +};
> > +
> > +struct rad_panel {
> > + struct drm_panel base;
> In the other raydium driver we name this "panel", which is a more
> descriptive name.
>
> >
> > + struct mipi_dsi_device *dsi;
> > +
> > + struct gpio_desc *reset;
> > + struct backlight_device *backlight;
> > +
> > + bool prepared;
> > + bool enabled;
> > +
> > + struct videomode vm;
> > + u32 width_mm;
> > + u32 height_mm;
> > +};
> > +
> > +static int rad_panel_prepare(struct drm_panel *panel)
> > +{
> > + struct rad_panel *rad = to_rad_panel(panel);
> > +
> > + if (rad->prepared)
> > + return 0;
> > +
> > + if (rad->reset) {
> > + gpiod_set_value(rad->reset, 0);
> > + usleep_range(5000, 1);
> > + gpiod_set_value(rad->reset, 1);
> > + usleep_range(2, 25000);
> > + }
> > +
> > + rad->prepared = true;
> > +
> > + return 0;
> > +}
> > +
> > +static int rad_panel_unprepare(struct drm_panel *panel)
> > +{
> > + struct rad_panel *rad = to_rad_panel(panel);
> > + struct device *dev = &rad->dsi->dev;
> > +
> > + if (!rad->prepared)
> > + return 0;
> > +
> > + if (rad->enabled) {
> > + DRM_DEV_ERROR(dev, "Panel still enabled!\n");
> > + return -EPERM;
> > + }
> This seems like overkill, what should trigger this?
Probably, just bad written code in the DSI host driver, but you are
right, it's overkill. I will remove this.
>
> >
> > +
> > + if (rad->reset) {
> > + gpiod_set_value(rad->reset, 0);
> > + usleep_range(15000, 17000);
> > + gpiod_set_value(rad->reset, 1);
> > + }
> > +
> > + rad->prepared = false;
> > +
> > + return 0;
> > +}
> > +
> > +static int rad_panel_enable(struct drm_panel *panel)
> > +{
> > + struct rad_panel *rad = to_rad_panel(panel);
> > + struct mipi_dsi_device *dsi = rad->dsi;
> > + struct device *dev = &dsi->dev;
> > + int color_format = color_format_from_dsi_format(dsi->format);
> > + u16 brightness;
> > + int ret;
> > +
> > + if (rad->enabled)
> > + return 0;
> > +
> > + if (!rad->prepared) {
> > + DRM_DEV_ERROR(dev, "Panel not prepared!\n");
> > + return -EPERM;
> > + }
> Seems like overkill.
>
> >
> > +
> > + dsi->mode_flags |= MIPI_DSI_MODE_LPM;
> > +
> > + ret = rad_panel_push_cmd_list(dsi);
> > + if (ret < 0) {
> > + DRM_DEV_ERROR(dev, "Failed to send MCS (%d)\n", ret);
> > + goto fail;
> > + }
> > +
> > + /* Select User Command Set table (CMD1) */
> > + ret = mipi_dsi_generic_write(dsi, (u8[]){ WRMAUCCTR, 0x00 },
> > 2);
> > + if (ret < 0)
> > + goto fail;
> > +
> > + /* Software reset */
> > + ret = mipi_dsi_dcs_soft_reset(dsi);
> > + if (ret < 0) {
> > + DRM_DEV_ERROR(dev, "Failed to do Software Reset
> > (%d)\n", ret);
> > + goto fail;
> > + }
> > +
> > + usleep_range(15000, 17000);
> > +
> > + /* Set DSI mode */
> > + ret = mipi_dsi_generic_write(dsi, (u8[]){ 0xC2, 0x0B }, 2);
> > + if (ret < 0) {
> > + DRM_DEV_ERROR(dev, "Failed to set DSI mode (%d)\n",
> > ret);
> > + goto fail;
> > + }
> > + /* Set tear ON */
> > + ret = mipi_dsi_dcs_set_tear_on(dsi,
> > MIPI_DSI_DCS_TEAR_MODE_VBLANK);
> > + if (ret < 0) {
> > + DRM_DEV_ERROR(dev, "Failed to set tear ON (%d)\n",
> > ret);
> > + goto fail;
> > + }
> > + /* Set tear scanline */
> > + ret = mipi_dsi_dcs_set_t
Re: [PATCH 1/2] dt-bindings: gpu: add Exynos Mali vendor specifics
On Tue, 18 Jun 2019 at 00:06, Rob Herring wrote: > > On Sun, Jun 16, 2019 at 2:16 AM Krzysztof Kozlowski wrote: > > > > On Fri, Jun 14, 2019 at 01:31:43PM -0700, Joseph Kogut wrote: > > > Document vendor specific compatible string for Mali gpus on Exynos SoCs. > > > > > > Signed-off-by: Joseph Kogut > > > --- > > > Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt | 1 + > > > 1 file changed, 1 insertion(+) > > > > > > diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt > > > b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt > > > index 1b1a74129141..a9704c736d07 100644 > > > --- a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt > > > +++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt > > > @@ -18,6 +18,7 @@ Required properties: > > > + "amlogic,meson-gxm-mali" > > > + "rockchip,rk3288-mali" > > > + "rockchip,rk3399-mali" > > > ++ "samsung,exynos-mali" > > > > Are there any driver differences for Exynos? If not then why adding > > another compatible? > > Wrong question. Are there any hardware differences? (Trick question > because difference compared to what?) > > Really, this shouldn't be 'exynos', but per SoC. But I'll leave it to > the Samsung folks to decide how specific it should be. If vendor compatible is expected, then let's go with per-soc (Exynos5420) because other SoCs use different Midgard chipsets so they might come with own differences. Best regards, Krzysztof ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] Re: [PATCH v2 5/9] drm/sun4i: tcon_top: Register clock gates in probe
On Tue, Jun 18, 2019 at 3:12 PM Jagan Teki wrote: > > On Mon, Jun 17, 2019 at 6:31 PM Chen-Yu Tsai wrote: > > > > On Mon, Jun 17, 2019 at 7:45 PM Maxime Ripard > > wrote: > > > > > > On Fri, Jun 14, 2019 at 10:13:20PM +0530, Jagan Teki wrote: > > > > TCON TOP have clock gates for TV0, TV1, dsi and right > > > > now these are register during bind call. > > > > > > > > Of which, dsi clock gate would required during DPHY probe > > > > but same can miss to get since tcon top is not bound at > > > > that time. > > > > > > > > To solve, this circular dependency move the clock gate > > > > registration from bind to probe so-that DPHY can get the > > > > dsi gate clock on time. > > > > > > It's not really clear to me what the circular dependency is? > > > > > > if you have a chain that is: > > > > > > tcon-top +-> DSI > > > +-> D-PHY > > > > > > There's no loop, right? > > > > Looking at how the DTSI patch structures things (without going into > > whether it is correct or accurate): > > > > The D-PHY is not part of the component graph. However it requests > > the DSI gate clock from the TCON-TOP. > > > > The TCON-TOP driver, in its current form, only registers the clocks > > it provides at component bind time. Thus the D-PHY can't successfully > > probe until the TCON-TOP has been bound. > > > > The DSI interface requires the D-PHY to bind. It will return -EPROBE_DEFER > > if it cannot request it. This in turn goes into the error path of > > component_bind_all, which unbinds all previous components. > > > > So it's actually > > > > D-PHY -> TCON-TOP -> DSI > > ^ | > > | > > > > I've not checked, but I suspect there's no possibility of having other > > drivers probe (to deal with deferred probing) within component_bind_all. > > Otherwise we shouldn't run into this weird circular dependency issue. > > > > So the question for Jagan is that is this indeed the case? Does this > > patch solve it, or at least work around it. > > Yes, this is what I was mentioned in initial version, since the "dsi" > gate in tcon top is registering during bind, the dphy of dsi > controller won't get the associated clock for "mod" so it is keep on > returning -EPROBE_DEFER. By moving the clock gate registration to > probe, everything bound as expected. I believe you failed to mention the DSI block, which is the part that completes the circular dependency. Don't expect others to have full awareness of the context. You have to provide it in your commit log. ChenYu
[git pull] vmwgfx-fixes-5.2
Dave, Daniel, A couple of fixes for vmwgfx. Two fixes for a DMA sg-list debug warning message. These are not cc'd stable since there is no evidence of actual breakage. On fix for the high-bandwidth backdoor port which is cc'd stable due to upcoming hardware, on which the code would otherwise break. The following changes since commit 5ed7f4b5eca11c3c69e7c8b53e4321812bc1ee1e: drm/vmwgfx: integer underflow in vmw_cmd_dx_set_shader() leading to an invalid read (2019-05-21 10:23:10 +0200) are available in the Git repository at: git://people.freedesktop.org/~thomash/linux vmwgfx-fixes-5.2 for you to fetch changes up to 39916897cd815a0ee07ba1f6820cf88a63e459fc: drm/vmwgfx: fix a warning due to missing dma_parms (2019-06-11 17:00:53 +0200) Qian Cai (1): drm/vmwgfx: fix a warning due to missing dma_parms Thomas Hellstrom (2): drm/vmwgfx: Use the backdoor port if the HB port is not available drm/vmwgfx: Honor the sg list segment size limitation drivers/gpu/drm/vmwgfx/vmwgfx_drv.c| 3 + drivers/gpu/drm/vmwgfx/vmwgfx_msg.c| 146 +++-- drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 10 +- 3 files changed, 125 insertions(+), 34 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/rcar-du: Fix error check when retrieving crtc state
Hi Sean,
Thank you for the patch.
On Mon, Jun 17, 2019 at 02:15:42PM -0400, Sean Paul wrote:
> From: Sean Paul
>
> drm_atomic_get_crtc_state() returns an error pointer when it fails, so
> the null check is doing nothing here.
>
> Credit to 0-day/Dan Carpenter for reporting this.
>
> Fixes: 6f3b62781bbd ("drm: Convert connector_helper_funcs->atomic_check to
> accept drm_atomic_state")
> Cc: Daniel Vetter
> Cc: Ville Syrjälä
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
> Cc: Rodrigo Vivi
> Cc: Ben Skeggs
> Cc: Laurent Pinchart
> Cc: Kieran Bingham
> Cc: Eric Anholt
> Cc: Laurent Pinchart [for rcar lvds]
> Cc: Sean Paul
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Sean Paul
> Cc: David Airlie
> Cc: Lyude Paul
> Cc: Karol Herbst
> Cc: Ilia Mirkin
> Cc: dri-devel@lists.freedesktop.org
> Cc: intel-...@lists.freedesktop.org
> Cc: linux-renesas-...@vger.kernel.org
> Reported-by: kbuild test robot
> Reported-by: Dan Carpenter
> Signed-off-by: Sean Paul
Reviewed-by: Laurent Pinchart
I have no pending conflicting changes for rcar_lvds.c. Do you plan to
merge this through drm-misc ?
> ---
> drivers/gpu/drm/rcar-du/rcar_lvds.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> index f2a5d4d997073..1c62578590f46 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> @@ -115,8 +115,8 @@ static int rcar_lvds_connector_atomic_check(struct
> drm_connector *connector,
>
> /* We're not allowed to modify the resolution. */
> crtc_state = drm_atomic_get_crtc_state(state, conn_state->crtc);
> - if (!crtc_state)
> - return -EINVAL;
> + if (IS_ERR(crtc_state))
> + return PTR_ERR(crtc_state);
>
> if (crtc_state->mode.hdisplay != panel_mode->hdisplay ||
> crtc_state->mode.vdisplay != panel_mode->vdisplay)
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 26/59] drm/rcar-du: Drop drm_gem_prime_export/import
Hi Daniel,
Thank you for the patch.
On Fri, Jun 14, 2019 at 10:35:42PM +0200, Daniel Vetter wrote:
> They're the default.
>
> Aside: Would be really nice to switch the others over to
> drm_gem_object_funcs.
>
> Signed-off-by: Daniel Vetter
> Cc: Laurent Pinchart
> Cc: Kieran Bingham
> Cc: linux-renesas-...@vger.kernel.org
Reviewed-by: Laurent Pinchart
Feel free to merged this as part of the series.
> ---
> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> index 83685250319d..9c93eb4fad8b 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> @@ -446,8 +446,6 @@ static struct drm_driver rcar_du_driver = {
> .gem_vm_ops = &drm_gem_cma_vm_ops,
> .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> - .gem_prime_import = drm_gem_prime_import,
> - .gem_prime_export = drm_gem_prime_export,
> .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
> .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
> .gem_prime_vmap = drm_gem_cma_prime_vmap,
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 28/59] drm/shmob: Drop drm_gem_prime_export/import
Hi Daniel,
Thank you for the patch.
On Fri, Jun 14, 2019 at 10:35:44PM +0200, Daniel Vetter wrote:
> They're the default.
>
> Aside: Would be really nice to switch the others over to
> drm_gem_object_funcs.
>
> Signed-off-by: Daniel Vetter
> Cc: Laurent Pinchart
> Cc: Kieran Bingham
> Cc: linux-renesas-...@vger.kernel.org
Reviewed-by: Laurent Pinchart
Feel free to merged this as part of the series.
> ---
> drivers/gpu/drm/shmobile/shmob_drm_drv.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/shmobile/shmob_drm_drv.c
> b/drivers/gpu/drm/shmobile/shmob_drm_drv.c
> index 9047a49ff35e..6c106b7a3bfe 100644
> --- a/drivers/gpu/drm/shmobile/shmob_drm_drv.c
> +++ b/drivers/gpu/drm/shmobile/shmob_drm_drv.c
> @@ -133,8 +133,6 @@ static struct drm_driver shmob_drm_driver = {
> .gem_vm_ops = &drm_gem_cma_vm_ops,
> .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> - .gem_prime_import = drm_gem_prime_import,
> - .gem_prime_export = drm_gem_prime_export,
> .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
> .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
> .gem_prime_vmap = drm_gem_cma_prime_vmap,
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] drm/virtio: simplify cursor updates
> Even nicer would be to add the fence using > drm_atomic_set_fence_for_plane() in the prepare_fb hook. Assuming this > isn't necessary for correctness (but then I kinda have questions about > races and stuff). I'll have a look. Maybe this way I can drop struct virtio_gpu_framebuffer (where the fence is the only thing beside struct drm_framebuffer). cheers, Gerd
Re: [linux-sunxi] [PATCH v2 5/9] drm/sun4i: tcon_top: Register clock gates in probe
On Tue, Jun 18, 2019 at 12:49 PM Chen-Yu Tsai wrote:
>
> On Mon, Jun 17, 2019 at 6:30 PM Jagan Teki wrote:
> >
> > On Sun, Jun 16, 2019 at 11:01 AM Chen-Yu Tsai wrote:
> > >
> > > On Sat, Jun 15, 2019 at 12:44 AM Jagan Teki
> > > wrote:
> > > >
> > > > TCON TOP have clock gates for TV0, TV1, dsi and right
> > > > now these are register during bind call.
> > > >
> > > > Of which, dsi clock gate would required during DPHY probe
> > > > but same can miss to get since tcon top is not bound at
> > > > that time.
> > > >
> > > > To solve, this circular dependency move the clock gate
> > > > registration from bind to probe so-that DPHY can get the
> > > > dsi gate clock on time.
> > > >
> > > > Signed-off-by: Jagan Teki
> > > > ---
> > > > drivers/gpu/drm/sun4i/sun8i_tcon_top.c | 94 ++
> > > > 1 file changed, 49 insertions(+), 45 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
> > > > b/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
> > > > index 465e9b0cdfee..a8978b3fe851 100644
> > > > --- a/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
> > > > +++ b/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
> > > > @@ -124,7 +124,53 @@ static struct clk_hw
> > > > *sun8i_tcon_top_register_gate(struct device *dev,
> > > > static int sun8i_tcon_top_bind(struct device *dev, struct device
> > > > *master,
> > > >void *data)
> > > > {
> > > > - struct platform_device *pdev = to_platform_device(dev);
> > > > + struct sun8i_tcon_top *tcon_top = dev_get_drvdata(dev);
> > > > + int ret;
> > > > +
> > > > + ret = reset_control_deassert(tcon_top->rst);
> > > > + if (ret) {
> > > > + dev_err(dev, "Could not deassert ctrl reset control\n");
> > > > + return ret;
> > > > + }
> > > > +
> > > > + ret = clk_prepare_enable(tcon_top->bus);
> > > > + if (ret) {
> > > > + dev_err(dev, "Could not enable bus clock\n");
> > > > + goto err_assert_reset;
> > > > + }
> > >
> > > You have to de-assert the reset control and enable the clock before the
> > > clocks it provides are registered. Otherwise a consumer may come in and
> > > ask for the provided clock to be enabled, but since the TCON TOP's own
> > > reset and clock are still disabled, you can't actually access the
> > > registers
> > > that controls the provided clock.
> >
> > These rst and bus are common reset and bus clocks not tcon top clocks
> > that are trying to register here. ie reason I have not moved it in
> > top.
>
> And you're sure that toggling bits in the TCON TOP block doesn't require
> the reset to be de-asserted and the bus clock enabled?
>
> Somehow I doubt that.
>
> Once the driver register the clocks it provides, they absolutely must work.
> They can't only work after the bind phase when the reset gets de-asserted
> and the bus clock enabled. Or you should provide proper error reporting
> in the clock ops. I doubt you want to go that way either.
Why would they won't work after bind phase? unlike tcon top gates,
these reset, and bus are common like what we have in other DE block
so enable them in bind won't be an issue as per as I understand. let
me know if you want me to check in other directions.
Log:
[1.381410] sun6i-mipi-dsi 1ca.dsi: Attached panel s070wv20-ct16-icn62
[1.398405] sun4i-drm display-engine: bound 110.mixer (ops 0xc074ce64)
[1.407134] sun4i-drm display-engine: bound 120.mixer (ops 0xc074ce64)
[1.414043] sun4i-drm display-engine: bound 1c7.tcon-top (ops 0xc0750e80)
[1.421407] sun4i_dclk_recalc_rate: val = 1, rate = 29700
[1.427358] sun4i-drm display-engine: No panel or bridge found...
RGB output disabled
[1.435217] sun4i-drm display-engine: bound 1c71000.lcd-controller
(ops 0xc0749594)
[1.442891] 0.0 drm_connector_init
[1.446294] 0. -1066106880-1-0 (null)
[1.449965] 0.1 drm_connector_init
[1.453368] 0.2 drm_connector_init
[1.456768] 1. drm_connector_init
[1.460094] 2. drm_connector_init
[1.463413] drm_connector_init: connector name = DSI-1
[1.468560] sun4i-drm display-engine: bound 1ca.dsi (ops 0xc074c0e4)
[1.475272] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[1.481892] [drm] No driver support for vblank timestamp query.
[1.488240] [drm] Initialized sun4i-drm 1.0.0 20150629 for
display-engine on minor 0
[1.497996] sun4i_dclk_round_rate: min_div = 6 max_div = 6, rate = 3000
[1.498106] ideal = 180, rounded = 18000
[1.498111] sun4i_dclk_round_rate: div = 6 rate = 2970
[1.498116] sun4i_dclk_round_rate: min_div = 6 max_div = 6, rate = 3000
[1.498154] ideal = 180, rounded = 18000
[1.498158] sun4i_dclk_round_rate: div = 6 rate = 2970
[1.498217] sun4i_dclk_recalc_rate: val = 1, rate = 17820
[1.498251] rate = 17820
[1.498253] parent_rate = 29700
[1.498256] reg = 0x80c0
[1.49
Re: [linux-sunxi] Re: [PATCH v2 5/9] drm/sun4i: tcon_top: Register clock gates in probe
On Tue, Jun 18, 2019 at 12:53 PM Chen-Yu Tsai wrote: > > On Tue, Jun 18, 2019 at 3:12 PM Jagan Teki wrote: > > > > On Mon, Jun 17, 2019 at 6:31 PM Chen-Yu Tsai wrote: > > > > > > On Mon, Jun 17, 2019 at 7:45 PM Maxime Ripard > > > wrote: > > > > > > > > On Fri, Jun 14, 2019 at 10:13:20PM +0530, Jagan Teki wrote: > > > > > TCON TOP have clock gates for TV0, TV1, dsi and right > > > > > now these are register during bind call. > > > > > > > > > > Of which, dsi clock gate would required during DPHY probe > > > > > but same can miss to get since tcon top is not bound at > > > > > that time. > > > > > > > > > > To solve, this circular dependency move the clock gate > > > > > registration from bind to probe so-that DPHY can get the > > > > > dsi gate clock on time. > > > > > > > > It's not really clear to me what the circular dependency is? > > > > > > > > if you have a chain that is: > > > > > > > > tcon-top +-> DSI > > > > +-> D-PHY > > > > > > > > There's no loop, right? > > > > > > Looking at how the DTSI patch structures things (without going into > > > whether it is correct or accurate): > > > > > > The D-PHY is not part of the component graph. However it requests > > > the DSI gate clock from the TCON-TOP. > > > > > > The TCON-TOP driver, in its current form, only registers the clocks > > > it provides at component bind time. Thus the D-PHY can't successfully > > > probe until the TCON-TOP has been bound. > > > > > > The DSI interface requires the D-PHY to bind. It will return -EPROBE_DEFER > > > if it cannot request it. This in turn goes into the error path of > > > component_bind_all, which unbinds all previous components. > > > > > > So it's actually > > > > > > D-PHY -> TCON-TOP -> DSI > > > ^ | > > > | > > > > > > I've not checked, but I suspect there's no possibility of having other > > > drivers probe (to deal with deferred probing) within component_bind_all. > > > Otherwise we shouldn't run into this weird circular dependency issue. > > > > > > So the question for Jagan is that is this indeed the case? Does this > > > patch solve it, or at least work around it. > > > > Yes, this is what I was mentioned in initial version, since the "dsi" > > gate in tcon top is registering during bind, the dphy of dsi > > controller won't get the associated clock for "mod" so it is keep on > > returning -EPROBE_DEFER. By moving the clock gate registration to > > probe, everything bound as expected. > > I believe you failed to mention the DSI block, which is the part that > completes the circular dependency. Don't expect others to have full > awareness of the context. You have to provide it in your commit log. I have mentioned DPHY and yes it is possible to give more information will update in next version, no problem. thanks for mentioning that. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] [PATCH v2 5/9] drm/sun4i: tcon_top: Register clock gates in probe
On Tue, Jun 18, 2019 at 3:45 PM Jagan Teki wrote:
>
> On Tue, Jun 18, 2019 at 12:49 PM Chen-Yu Tsai wrote:
> >
> > On Mon, Jun 17, 2019 at 6:30 PM Jagan Teki
> > wrote:
> > >
> > > On Sun, Jun 16, 2019 at 11:01 AM Chen-Yu Tsai wrote:
> > > >
> > > > On Sat, Jun 15, 2019 at 12:44 AM Jagan Teki
> > > > wrote:
> > > > >
> > > > > TCON TOP have clock gates for TV0, TV1, dsi and right
> > > > > now these are register during bind call.
> > > > >
> > > > > Of which, dsi clock gate would required during DPHY probe
> > > > > but same can miss to get since tcon top is not bound at
> > > > > that time.
> > > > >
> > > > > To solve, this circular dependency move the clock gate
> > > > > registration from bind to probe so-that DPHY can get the
> > > > > dsi gate clock on time.
> > > > >
> > > > > Signed-off-by: Jagan Teki
> > > > > ---
> > > > > drivers/gpu/drm/sun4i/sun8i_tcon_top.c | 94
> > > > > ++
> > > > > 1 file changed, 49 insertions(+), 45 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
> > > > > b/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
> > > > > index 465e9b0cdfee..a8978b3fe851 100644
> > > > > --- a/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
> > > > > +++ b/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
> > > > > @@ -124,7 +124,53 @@ static struct clk_hw
> > > > > *sun8i_tcon_top_register_gate(struct device *dev,
> > > > > static int sun8i_tcon_top_bind(struct device *dev, struct device
> > > > > *master,
> > > > >void *data)
> > > > > {
> > > > > - struct platform_device *pdev = to_platform_device(dev);
> > > > > + struct sun8i_tcon_top *tcon_top = dev_get_drvdata(dev);
> > > > > + int ret;
> > > > > +
> > > > > + ret = reset_control_deassert(tcon_top->rst);
> > > > > + if (ret) {
> > > > > + dev_err(dev, "Could not deassert ctrl reset
> > > > > control\n");
> > > > > + return ret;
> > > > > + }
> > > > > +
> > > > > + ret = clk_prepare_enable(tcon_top->bus);
> > > > > + if (ret) {
> > > > > + dev_err(dev, "Could not enable bus clock\n");
> > > > > + goto err_assert_reset;
> > > > > + }
> > > >
> > > > You have to de-assert the reset control and enable the clock before the
> > > > clocks it provides are registered. Otherwise a consumer may come in and
> > > > ask for the provided clock to be enabled, but since the TCON TOP's own
> > > > reset and clock are still disabled, you can't actually access the
> > > > registers
> > > > that controls the provided clock.
> > >
> > > These rst and bus are common reset and bus clocks not tcon top clocks
> > > that are trying to register here. ie reason I have not moved it in
> > > top.
> >
> > And you're sure that toggling bits in the TCON TOP block doesn't require
> > the reset to be de-asserted and the bus clock enabled?
> >
> > Somehow I doubt that.
> >
> > Once the driver register the clocks it provides, they absolutely must work.
> > They can't only work after the bind phase when the reset gets de-asserted
> > and the bus clock enabled. Or you should provide proper error reporting
> > in the clock ops. I doubt you want to go that way either.
>
> Why would they won't work after bind phase? unlike tcon top gates,
> these reset, and bus are common like what we have in other DE block
> so enable them in bind won't be an issue as per as I understand. let
> me know if you want me to check in other directions.
You misunderstood. When you moved the clock registering parts to the probe
phase, but didn't move the clock enable and reset de-assert parts to go with,
the clock ops will not work as expected between probe and bind time.
Simple way to verify it: Just use devmem to disable the TCON TOP bus gate
and/or assert its reset control. Then try to toggle any of the bits in the
TCON TOP block and see if it works, or if the bits stick.
Whether another driver actually does so is not the question. It is just bad
implementation.
> Log:
> [1.381410] sun6i-mipi-dsi 1ca.dsi: Attached panel s070wv20-ct16-icn62
> [1.398405] sun4i-drm display-engine: bound 110.mixer (ops 0xc074ce64)
> [1.407134] sun4i-drm display-engine: bound 120.mixer (ops 0xc074ce64)
> [1.414043] sun4i-drm display-engine: bound 1c7.tcon-top (ops
> 0xc0750e80)
> [1.421407] sun4i_dclk_recalc_rate: val = 1, rate = 29700
> [1.427358] sun4i-drm display-engine: No panel or bridge found...
> RGB output disabled
> [1.435217] sun4i-drm display-engine: bound 1c71000.lcd-controller
> (ops 0xc0749594)
> [1.442891] 0.0 drm_connector_init
> [1.446294] 0. -1066106880-1-0 (null)
> [1.449965] 0.1 drm_connector_init
> [1.453368] 0.2 drm_connector_init
> [1.456768] 1. drm_connector_init
> [1.460094] 2. drm_connector_init
> [1.463413] drm_connector_init: connector name = DSI-1
> [1.468560] sun4i-drm display-engine: bound 1ca.dsi (ops 0xc074c0e
Re: [PATCH V2 4/5] drm/vkms: Use index instead of 0 in possible crtc
Interestingly, even with the previous code, possible_crtcs=1 was exposed to userspace [1]. I think this is because of a safeguard in drm_crtc_init_with_planes (drm_crtc.c:284) which sets the primary and cursor plane's possible_crtcs to the first CRTC if zero. If we want to warn on possible_crtcs=0, we should probably remove this safeguard. Checking first whether this safeguard is used by any driver is probably a good idea. [1]: https://drmdb.emersion.fr/devices/f218d1242714
Re: [PATCH 40/59] drm/vram-helper: Drop drm_gem_prime_export/import
On Tue, Jun 18, 2019 at 6:49 AM Gerd Hoffmann wrote: > > Hi, > > > > While most callbacks are pretty straight forward (just hook the same > > > callbacks into the drm_gem_object_funcs. struct) the mmap bits are a > > > bit more obscure. > > > > > > First, there seem to be two ways to mmap a gem buffer: > > > > > > (1) drm_driver->fops->mmap, and > > > (2) drm_driver->gem_prime_mmap. > > > > > > drm_gem_object_funcs has just a single vm_ops ... > > > > > > Also it is not obvious how one would convert something which basically > > > calls ttm_bo_mmap() in drm_driver->fops->mmap to the new interface. > > > > Yeah the mmap side is still a mess, but my series here was getting a bit > > too long already. There's a bunch of problems here: > > > > drm_driver->gem_prime_mmap could be nuked and instead we use > > drm_gem_prime_mmap everywhere. Especially the various versions in helpers > > really don't add much. > > Well, everything using ttm has the problem that we have another > duplication here: both gem and ttm have a vma_node ... > > So (for example) drm_gem_vram_driver_gem_prime_mmap() is a thin wrapper > which does (a) copy vm_node.start from ttm to gem vma_node and (b) calls > drm_gem_prime_mmap(). Hm ... maybe we should ditch the ttm vma offset stuff and fold that over entirely to the gem way of doing things. The only thing you're going to loose is the ->verify_access callback, which again is just to get back to gem I think. You would need a slightly differrent vm_ops structure though, since the ttm vm ops expect a ttm_buffer_object, whereas gem gives you a drm_gem_buffer_object. So either need to overwrite all those, or maybe it's inded time to just make ttm_bo a subclass of gem_bo. > > Second one is drm_driver->fops->mmap. That one we need to keep, but this > > isn't mmap on a buffer, but mmap on the entire drm_device. The one which > > should be replaced by drm_gem_object_funcs.vm_ops is > > drm_driver->gem_vm_ops. > > Hmm, seems ttm hasn't something I can hook into drm_driver->gem_vm_ops ... ttm_bo_vm_ops seems to be the thing you want. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/komeda: Enable dual-link support
Komeda HW can support dual-link which splits display frame to two halves
(left/link0, right/link1) and output them by two output links.
Due to the halved pixel rate of each link, the pxlclk of dual-link can be
reduced two times compare with single-link.
For enabling dual-link:
- The DT need to configure two output-links for the pipeline node.
- Komeda enable dual-link when both link0 and link1 have been connected.
Example of how the pipeline node will look like for dual-link setup
pipe0: pipeline@0 {
clocks = <&fpgaosc2>;
clock-names = "pxclk";
reg = <0>;
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
#address-cells = <1>;
#size-cells = <0>;
dp0_pipe0_link0: endpoint@0 {
reg = <0>;
remote-endpoint = <&dlink_connector_in0>;
};
dp0_pipe0_link1: endpoint@1 {
reg = <1>;
remote-endpoint = <&dlink_connector_in1>;
};
};
};
Signed-off-by: James Qian Wang (Arm Technology China)
---
.../arm/display/komeda/d71/d71_component.c| 6 +-
.../gpu/drm/arm/display/komeda/komeda_crtc.c | 73 +--
.../gpu/drm/arm/display/komeda/komeda_dev.c | 5 +-
.../gpu/drm/arm/display/komeda/komeda_drv.c | 8 +-
.../gpu/drm/arm/display/komeda/komeda_kms.h | 2 +-
.../drm/arm/display/komeda/komeda_pipeline.c | 19 -
.../drm/arm/display/komeda/komeda_pipeline.h | 6 +-
.../display/komeda/komeda_pipeline_state.c| 2 +-
8 files changed, 85 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
index 049e8bfac27b..8e9d44d01e91 100644
--- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
+++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
@@ -4,8 +4,6 @@
* Author: James.Qian.Wang
*
*/
-
-#include
#include "d71_dev.h"
#include "komeda_kms.h"
#include "malidp_io.h"
@@ -1088,6 +1086,10 @@ static void d71_timing_ctrlr_update(struct
komeda_component *c,
/* configure bs control register */
value = BS_CTRL_EN | BS_CTRL_VM;
+ if (c->pipeline->dual_link) {
+ malidp_write32(reg, BS_DRIFT_TO, hfront_porch + 16);
+ value |= BS_CTRL_DL;
+ }
malidp_write32(reg, BLK_CONTROL, value);
}
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
index 98e36e1fb2ad..ec43032f3c2c 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
@@ -28,7 +28,7 @@ static void komeda_crtc_update_clock_ratio(struct
komeda_crtc_state *kcrtc_st)
}
pxlclk = kcrtc_st->base.adjusted_mode.crtc_clock * 1000;
- aclk = komeda_calc_aclk(kcrtc_st) << 32;
+ aclk = komeda_crtc_get_aclk(kcrtc_st) << 32;
do_div(aclk, pxlclk);
kcrtc_st->clock_ratio = aclk;
@@ -75,14 +75,6 @@ komeda_crtc_atomic_check(struct drm_crtc *crtc,
return 0;
}
-unsigned long komeda_calc_aclk(struct komeda_crtc_state *kcrtc_st)
-{
- struct komeda_dev *mdev = kcrtc_st->base.crtc->dev->dev_private;
- unsigned long aclk = kcrtc_st->base.adjusted_mode.crtc_clock;
-
- return clk_round_rate(mdev->aclk, aclk * 1000);
-}
-
/* For active a crtc, mainly need two parts of preparation
* 1. adjust display operation mode.
* 2. enable needed clk
@@ -119,7 +111,7 @@ komeda_crtc_prepare(struct komeda_crtc *kcrtc)
* to enable it again.
*/
if (new_mode != KOMEDA_MODE_DUAL_DISP) {
- err = clk_set_rate(mdev->aclk, komeda_calc_aclk(kcrtc_st));
+ err = clk_set_rate(mdev->aclk, komeda_crtc_get_aclk(kcrtc_st));
if (err)
DRM_ERROR("failed to set aclk.\n");
err = clk_prepare_enable(mdev->aclk);
@@ -345,29 +337,58 @@ komeda_crtc_atomic_flush(struct drm_crtc *crtc,
komeda_crtc_do_flush(crtc, old);
}
+/* Returns the minimum frequency of the aclk rate (main engine clock) in Hz */
+static unsigned long
+komeda_calc_min_aclk_rate(struct komeda_crtc *kcrtc,
+ unsigned long pxlclk)
+{
+ /* Once dual-link one display pipeline drives two display outputs,
+* the aclk needs run on the double rate of pxlclk
+*/
+ if (kcrtc->master->dual_link)
+ return pxlclk * 2;
+ else
+ return pxlclk;
+}
+
+/* Get current aclk rate that specified by state */
+unsigned long komeda_crtc_get_aclk(struct komeda_crtc_state *kcrtc_st)
+{
+ struct drm_crtc *crtc = kcrtc_st->base.crtc;
+ struct komeda_dev *mdev = crtc->dev->dev_private;
+ unsigned long pxlclk = kcrtc_st->base.adjusted_mode.crtc_clock * 1000;
+ unsigned long min_aclk;
+
+ min_
[PATCH 0/2] drm/komeda: Enable dual-link support
Komeda HW can support dual-link which splits display frame to two halves
(left/link0, right/link1) and output them by two output links.
Due to the halved pixel rate of each link, the pxlclk of dual-link can be
reduced two times compare with single-link.
For enabling dual-link:
- The DT need to configure two output-links for the pipeline node.
- Komeda enable dual-link when both link0 and link1 have been connected.
Example of how the pipeline node will look like for dual-link setup
pipe0: pipeline@0 {
clocks = <&fpgaosc2>;
clock-names = "pxclk";
reg = <0>;
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
#address-cells = <1>;
#size-cells = <0>;
dp0_pipe0_link0: endpoint@0 {
reg = <0>;
remote-endpoint = <&dlink_connector_in0>;
};
dp0_pipe0_link1: endpoint@1 {
reg = <1>;
remote-endpoint = <&dlink_connector_in1>;
};
};
};
James Qian Wang (Arm Technology China) (2):
drm/komeda: Use drm_display_mode "crtc_" prefixed hardware timings
drm/komeda: Enable dual-link support
.../arm/display/komeda/d71/d71_component.c| 42 +
.../gpu/drm/arm/display/komeda/komeda_crtc.c | 89 +--
.../gpu/drm/arm/display/komeda/komeda_dev.c | 5 +-
.../gpu/drm/arm/display/komeda/komeda_drv.c | 8 +-
.../gpu/drm/arm/display/komeda/komeda_kms.h | 4 +-
.../drm/arm/display/komeda/komeda_pipeline.c | 19 +++-
.../drm/arm/display/komeda/komeda_pipeline.h | 6 +-
.../display/komeda/komeda_pipeline_state.c| 2 +-
8 files changed, 118 insertions(+), 57 deletions(-)
--
2.17.1
[PATCH 1/2] drm/komeda: Use drm_display_mode "crtc_" prefixed hardware timings
struct drm_display_mode contains two copies of timings.
- plain timings.
- hardware timings, the ones with "crtc_" prefix.
According to the definition, update komeda to use the hardware timing.
Signed-off-by: James Qian Wang (Arm Technology China)
---
.../arm/display/komeda/d71/d71_component.c| 36 ---
.../gpu/drm/arm/display/komeda/komeda_crtc.c | 20 ++-
.../gpu/drm/arm/display/komeda/komeda_kms.h | 2 --
3 files changed, 35 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
index 87248babca1f..049e8bfac27b 100644
--- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
+++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
@@ -937,7 +937,7 @@ static int d71_downscaling_clk_check(struct komeda_pipeline
*pipe,
denominator = (mode->htotal - 1) * v_out - 2 * v_in;
}
- return aclk_rate * denominator >= mode->clock * 1000 * fraction ?
+ return aclk_rate * denominator >= mode->crtc_clock * 1000 * fraction ?
0 : -EINVAL;
}
@@ -1056,21 +1056,31 @@ static void d71_timing_ctrlr_update(struct
komeda_component *c,
struct komeda_component_state *state)
{
struct drm_crtc_state *crtc_st = state->crtc->state;
+ struct drm_display_mode *mode = &crtc_st->adjusted_mode;
u32 __iomem *reg = c->reg;
- struct videomode vm;
+ u32 hactive, hfront_porch, hback_porch, hsync_len;
+ u32 vactive, vfront_porch, vback_porch, vsync_len;
u32 value;
- drm_display_mode_to_videomode(&crtc_st->adjusted_mode, &vm);
-
- malidp_write32(reg, BS_ACTIVESIZE, HV_SIZE(vm.hactive, vm.vactive));
- malidp_write32(reg, BS_HINTERVALS, BS_H_INTVALS(vm.hfront_porch,
- vm.hback_porch));
- malidp_write32(reg, BS_VINTERVALS, BS_V_INTVALS(vm.vfront_porch,
- vm.vback_porch));
-
- value = BS_SYNC_VSW(vm.vsync_len) | BS_SYNC_HSW(vm.hsync_len);
- value |= vm.flags & DISPLAY_FLAGS_VSYNC_HIGH ? BS_SYNC_VSP : 0;
- value |= vm.flags & DISPLAY_FLAGS_HSYNC_HIGH ? BS_SYNC_HSP : 0;
+ hactive = mode->crtc_hdisplay;
+ hfront_porch = mode->crtc_hsync_start - mode->crtc_hdisplay;
+ hsync_len = mode->crtc_hsync_end - mode->crtc_hsync_start;
+ hback_porch = mode->crtc_htotal - mode->crtc_hsync_end;
+
+ vactive = mode->crtc_vdisplay;
+ vfront_porch = mode->crtc_vsync_start - mode->crtc_vdisplay;
+ vsync_len = mode->crtc_vsync_end - mode->crtc_vsync_start;
+ vback_porch = mode->crtc_vtotal - mode->crtc_vsync_end;
+
+ malidp_write32(reg, BS_ACTIVESIZE, HV_SIZE(hactive, vactive));
+ malidp_write32(reg, BS_HINTERVALS, BS_H_INTVALS(hfront_porch,
+ hback_porch));
+ malidp_write32(reg, BS_VINTERVALS, BS_V_INTVALS(vfront_porch,
+ vback_porch));
+
+ value = BS_SYNC_VSW(vsync_len) | BS_SYNC_HSW(hsync_len);
+ value |= mode->flags & DRM_MODE_FLAG_PVSYNC ? BS_SYNC_VSP : 0;
+ value |= mode->flags & DRM_MODE_FLAG_PHSYNC ? BS_SYNC_HSP : 0;
malidp_write32(reg, BS_SYNC, value);
malidp_write32(reg, BS_PROG_LINE, D71_DEFAULT_PREPRETCH_LINE - 1);
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
index 1b4ea8ab41fa..98e36e1fb2ad 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
@@ -27,7 +27,7 @@ static void komeda_crtc_update_clock_ratio(struct
komeda_crtc_state *kcrtc_st)
return;
}
- pxlclk = kcrtc_st->base.adjusted_mode.clock * 1000;
+ pxlclk = kcrtc_st->base.adjusted_mode.crtc_clock * 1000;
aclk = komeda_calc_aclk(kcrtc_st) << 32;
do_div(aclk, pxlclk);
@@ -78,9 +78,9 @@ komeda_crtc_atomic_check(struct drm_crtc *crtc,
unsigned long komeda_calc_aclk(struct komeda_crtc_state *kcrtc_st)
{
struct komeda_dev *mdev = kcrtc_st->base.crtc->dev->dev_private;
- unsigned long pxlclk = kcrtc_st->base.adjusted_mode.clock;
+ unsigned long aclk = kcrtc_st->base.adjusted_mode.crtc_clock;
- return clk_round_rate(mdev->aclk, pxlclk * 1000);
+ return clk_round_rate(mdev->aclk, aclk * 1000);
}
/* For active a crtc, mainly need two parts of preparation
@@ -93,7 +93,7 @@ komeda_crtc_prepare(struct komeda_crtc *kcrtc)
struct komeda_dev *mdev = kcrtc->base.dev->dev_private;
struct komeda_pipeline *master = kcrtc->master;
struct komeda_crtc_state *kcrtc_st = to_kcrtc_st(kcrtc->base.state);
- unsigned long pxlclk_rate = kcrtc_st->base.adjusted_mode.clock * 1000;
+ struct drm_display_mode *mode = &kcrtc_st->base.adjusted_mode;
[PATCH v2] drm/panfrost: Make sure a BO is only unmapped when appropriate
mmu_ops->unmap() will fail when called on a BO that has not been
previously mapped, and the error path in panfrost_ioctl_create_bo()
can call drm_gem_object_put_unlocked() (which in turn calls
panfrost_mmu_unmap()) on a BO that has not been mapped yet.
Keep track of the mapped/unmapped state to avoid such issues.
Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver")
Cc:
Signed-off-by: Boris Brezillon
---
Changes in v2:
* Check is_mapped val in the caller and add WARN_ON() in the mmu code
(suggested by Tomeu)
---
drivers/gpu/drm/panfrost/panfrost_gem.c | 3 ++-
drivers/gpu/drm/panfrost/panfrost_gem.h | 1 +
drivers/gpu/drm/panfrost/panfrost_mmu.c | 8
3 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.c
b/drivers/gpu/drm/panfrost/panfrost_gem.c
index 886875ae31d3..b46416be5a54 100644
--- a/drivers/gpu/drm/panfrost/panfrost_gem.c
+++ b/drivers/gpu/drm/panfrost/panfrost_gem.c
@@ -19,7 +19,8 @@ static void panfrost_gem_free_object(struct drm_gem_object
*obj)
struct panfrost_gem_object *bo = to_panfrost_bo(obj);
struct panfrost_device *pfdev = obj->dev->dev_private;
- panfrost_mmu_unmap(bo);
+ if (bo->is_mapped)
+ panfrost_mmu_unmap(bo);
spin_lock(&pfdev->mm_lock);
drm_mm_remove_node(&bo->node);
diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.h
b/drivers/gpu/drm/panfrost/panfrost_gem.h
index 045000eb5fcf..6dbcaba020fc 100644
--- a/drivers/gpu/drm/panfrost/panfrost_gem.h
+++ b/drivers/gpu/drm/panfrost/panfrost_gem.h
@@ -11,6 +11,7 @@ struct panfrost_gem_object {
struct drm_gem_shmem_object base;
struct drm_mm_node node;
+ bool is_mapped;
};
static inline
diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c
b/drivers/gpu/drm/panfrost/panfrost_mmu.c
index 762b1bd2a8c2..92ac995dd9c6 100644
--- a/drivers/gpu/drm/panfrost/panfrost_mmu.c
+++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c
@@ -156,6 +156,9 @@ int panfrost_mmu_map(struct panfrost_gem_object *bo)
struct sg_table *sgt;
int ret;
+ if (WARN_ON(bo->is_mapped))
+ return 0;
+
sgt = drm_gem_shmem_get_pages_sgt(obj);
if (WARN_ON(IS_ERR(sgt)))
return PTR_ERR(sgt);
@@ -189,6 +192,7 @@ int panfrost_mmu_map(struct panfrost_gem_object *bo)
pm_runtime_mark_last_busy(pfdev->dev);
pm_runtime_put_autosuspend(pfdev->dev);
+ bo->is_mapped = true;
return 0;
}
@@ -203,6 +207,9 @@ void panfrost_mmu_unmap(struct panfrost_gem_object *bo)
size_t unmapped_len = 0;
int ret;
+ if (WARN_ON(!bo->is_mapped))
+ return;
+
dev_dbg(pfdev->dev, "unmap: iova=%llx, len=%zx", iova, len);
ret = pm_runtime_get_sync(pfdev->dev);
@@ -230,6 +237,7 @@ void panfrost_mmu_unmap(struct panfrost_gem_object *bo)
pm_runtime_mark_last_busy(pfdev->dev);
pm_runtime_put_autosuspend(pfdev->dev);
+ bo->is_mapped = false;
}
static void mmu_tlb_inv_context_s1(void *cookie)
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 3/4] drm/panfrost: Add an helper to check the GPU generation
All models with an ID >= 0x1000 are Bifrost GPUs for now (might change
with new gens).
Suggested-by: Alyssa Rosenzweig
Signed-off-by: Boris Brezillon
Reviewed-by: Alyssa Rosenzweig
---
Changes in v4:
- Add Alyssa's R-b
Changes in v3:
* New patch
---
drivers/gpu/drm/panfrost/panfrost_device.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/panfrost/panfrost_device.h
b/drivers/gpu/drm/panfrost/panfrost_device.h
index 031168f83bd2..e86581c4af7b 100644
--- a/drivers/gpu/drm/panfrost/panfrost_device.h
+++ b/drivers/gpu/drm/panfrost/panfrost_device.h
@@ -110,6 +110,11 @@ static inline int panfrost_model_cmp(struct
panfrost_device *pfdev, s32 id)
return match_id - id;
}
+static inline bool panfrost_model_is_bifrost(struct panfrost_device *pfdev)
+{
+ return panfrost_model_cmp(pfdev, 0x1000) >= 0;
+}
+
static inline bool panfrost_model_eq(struct panfrost_device *pfdev, s32 id)
{
return !panfrost_model_cmp(pfdev, id);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 4/4] drm/panfrost: Expose performance counters through unstable ioctls
Expose performance counters through 2 driver specific ioctls: one to
enable/disable the perfcnt block, and one to dump the counter values.
There are discussions to expose global performance monitors (those
counters that can't be retrieved on a per-job basis) in a consistent
way, but this is likely to take time to settle on something that works
for various HW/users.
The ioctls are marked unstable so we can get rid of them when the time
comes. We initally went for a debugfs-based interface, but this was
making the transition to per-FD address space more complicated (we need
to specify the namespace the GPU has to use when dumping the perf
counters), hence the decision to switch back to driver specific ioctls
which are passed the FD they operate on and thus will have a dedicated
address space attached to them.
Other than that, the implementation is pretty simple: it basically dumps
all counters and copy the values to a userspace buffer. The parsing is
left to userspace which has to know the specific layout that's used
by the GPU (layout differs on a per-revision basis).
Signed-off-by: Boris Brezillon
Acked-by: Alyssa Rosenzweig
---
Changes in v4:
* Fix a "cast to pointer from integer of different size" warning
(reported by kbuild bots)
* Add Alyssa's R-b
* Use drm_gem_shmem_v[un]map() instead of drm_gem_v[un]map()
Changes in v3:
* Expose things through ioctls instead of debugs (suggested by Rob)
* Fix the BO size calculation (reported by Steven)
* Drop perfcnt suspend/resume logic (runtime suspend is prevented when
perfcnt is enabled)
* Disable the perfcnt block in the _fini() path (suggested by Rob)
* Do not mess with the INT reg in _init() (suggested by Rob)
* Provide a way to select both set of counters on Bifrost GPUs
(suggested by Steven)
Changes in v2:
* Complete rewrite to expose things through debugfs in a simple way
(no counter layout abstraction and no per-job counter tracking to
avoid the perf penalty incurred by the extra serialization fence)
---
drivers/gpu/drm/panfrost/Makefile | 3 +-
drivers/gpu/drm/panfrost/panfrost_device.c | 8 +
drivers/gpu/drm/panfrost/panfrost_device.h | 3 +
drivers/gpu/drm/panfrost/panfrost_drv.c | 4 +
drivers/gpu/drm/panfrost/panfrost_gpu.c | 7 +
drivers/gpu/drm/panfrost/panfrost_perfcnt.c | 329
drivers/gpu/drm/panfrost/panfrost_perfcnt.h | 18 ++
drivers/gpu/drm/panfrost/panfrost_regs.h| 19 ++
include/uapi/drm/panfrost_drm.h | 24 ++
9 files changed, 414 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/panfrost/panfrost_perfcnt.c
create mode 100644 drivers/gpu/drm/panfrost/panfrost_perfcnt.h
diff --git a/drivers/gpu/drm/panfrost/Makefile
b/drivers/gpu/drm/panfrost/Makefile
index 6de72d13c58f..ecf0864cb515 100644
--- a/drivers/gpu/drm/panfrost/Makefile
+++ b/drivers/gpu/drm/panfrost/Makefile
@@ -7,6 +7,7 @@ panfrost-y := \
panfrost_gem.o \
panfrost_gpu.o \
panfrost_job.o \
- panfrost_mmu.o
+ panfrost_mmu.o \
+ panfrost_perfcnt.o
obj-$(CONFIG_DRM_PANFROST) += panfrost.o
diff --git a/drivers/gpu/drm/panfrost/panfrost_device.c
b/drivers/gpu/drm/panfrost/panfrost_device.c
index ccb8eb2a518c..8a111d7c0200 100644
--- a/drivers/gpu/drm/panfrost/panfrost_device.c
+++ b/drivers/gpu/drm/panfrost/panfrost_device.c
@@ -14,6 +14,7 @@
#include "panfrost_gpu.h"
#include "panfrost_job.h"
#include "panfrost_mmu.h"
+#include "panfrost_perfcnt.h"
static int panfrost_reset_init(struct panfrost_device *pfdev)
{
@@ -171,7 +172,13 @@ int panfrost_device_init(struct panfrost_device *pfdev)
pm_runtime_mark_last_busy(pfdev->dev);
pm_runtime_put_autosuspend(pfdev->dev);
+ err = panfrost_perfcnt_init(pfdev);
+ if (err)
+ goto err_out5;
+
return 0;
+err_out5:
+ panfrost_job_fini(pfdev);
err_out4:
panfrost_mmu_fini(pfdev);
err_out3:
@@ -187,6 +194,7 @@ int panfrost_device_init(struct panfrost_device *pfdev)
void panfrost_device_fini(struct panfrost_device *pfdev)
{
+ panfrost_perfcnt_fini(pfdev);
panfrost_job_fini(pfdev);
panfrost_mmu_fini(pfdev);
panfrost_gpu_fini(pfdev);
diff --git a/drivers/gpu/drm/panfrost/panfrost_device.h
b/drivers/gpu/drm/panfrost/panfrost_device.h
index e86581c4af7b..83cc01cafde1 100644
--- a/drivers/gpu/drm/panfrost/panfrost_device.h
+++ b/drivers/gpu/drm/panfrost/panfrost_device.h
@@ -14,6 +14,7 @@ struct panfrost_device;
struct panfrost_mmu;
struct panfrost_job_slot;
struct panfrost_job;
+struct panfrost_perfcnt;
#define NUM_JOB_SLOTS 3
@@ -78,6 +79,8 @@ struct panfrost_device {
struct panfrost_job *jobs[NUM_JOB_SLOTS];
struct list_head scheduled_jobs;
+ struct panfrost_perfcnt *perfcnt;
+
struct mutex sched_lock;
struct mutex reset_lock;
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index 754881ece8d7..e34e8
[PATCH v4 2/4] drm/panfrost: Add a module parameter to expose unstable ioctls
We plan to expose performance counters through 2 driver specific
ioctls until there's a solution to expose them in a generic way.
In order to be able to deprecate those ioctls when this new
infrastructure is in place we add an unsafe module parameter that
will keep those ioctls hidden unless it's set to true (which also
has the effect of tainting the kernel).
All unstable ioctl handlers should use panfrost_unstable_ioctl_check()
to check whether they're supposed to handle the request or reject it
with ENOSYS.
Suggested-by: Emil Velikov
Signed-off-by: Boris Brezillon
Reviewed-by: Alyssa Rosenzweig
---
Changes in v4:
- Add Alyssa's R-b
Changes in v3:
* New patch
---
drivers/gpu/drm/panfrost/panfrost_device.h | 2 ++
drivers/gpu/drm/panfrost/panfrost_drv.c| 11 +++
2 files changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/panfrost/panfrost_device.h
b/drivers/gpu/drm/panfrost/panfrost_device.h
index 8074f221034b..031168f83bd2 100644
--- a/drivers/gpu/drm/panfrost/panfrost_device.h
+++ b/drivers/gpu/drm/panfrost/panfrost_device.h
@@ -115,6 +115,8 @@ static inline bool panfrost_model_eq(struct panfrost_device
*pfdev, s32 id)
return !panfrost_model_cmp(pfdev, id);
}
+int panfrost_unstable_ioctl_check(void);
+
int panfrost_device_init(struct panfrost_device *pfdev);
void panfrost_device_fini(struct panfrost_device *pfdev);
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index d11e2281dde6..754881ece8d7 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -20,6 +20,9 @@
#include "panfrost_job.h"
#include "panfrost_gpu.h"
+static bool unstable_ioctls;
+module_param_unsafe(unstable_ioctls, bool, 0600);
+
static int panfrost_ioctl_get_param(struct drm_device *ddev, void *data,
struct drm_file *file)
{
struct drm_panfrost_get_param *param = data;
@@ -297,6 +300,14 @@ static int panfrost_ioctl_get_bo_offset(struct drm_device
*dev, void *data,
return 0;
}
+int panfrost_unstable_ioctl_check(void)
+{
+ if (!unstable_ioctls)
+ return -ENOSYS;
+
+ return 0;
+}
+
static int
panfrost_open(struct drm_device *dev, struct drm_file *file)
{
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 0/4] drm/panfrost: Expose perf counters to userspace
Hello,
This a new version of the panfrost perfcnt series, this time exposing
this functionality through 2 ioctls instead of the debugfs approach
used in v2.
I also went for Emil's suggestion to expose those ioctls only when
the unstable_iocts unsafe param is set to true. This way, I hope we'll
be able to deprecate those ioctls when the generic solution to expose
global perf counters is out.
Also addressed the problems reported by Rob and Steven.
Regards,
Boris
Changes in v4:
* Fix a warning reported by kbuild bots
* Add R-b/A-b
* Use drm_gem_shmem_v[un]map() instead of drm_gem_v[un]map()
Changes in v3:
* Expose things through ioctls instead of debugfs (needed for
per-FD address space that is being worked on by Rob)
Changes in v2:
* Complete rewrite to expose things through debugfs
Boris Brezillon (4):
drm/panfrost: Move gpu_{write,read}() macros to panfrost_regs.h
drm/panfrost: Add a module parameter to expose unstable ioctls
drm/panfrost: Add an helper to check the GPU generation
drm/panfrost: Expose performance counters through unstable ioctls
drivers/gpu/drm/panfrost/Makefile | 3 +-
drivers/gpu/drm/panfrost/panfrost_device.c | 8 +
drivers/gpu/drm/panfrost/panfrost_device.h | 10 +
drivers/gpu/drm/panfrost/panfrost_drv.c | 15 +
drivers/gpu/drm/panfrost/panfrost_gpu.c | 10 +-
drivers/gpu/drm/panfrost/panfrost_perfcnt.c | 329
drivers/gpu/drm/panfrost/panfrost_perfcnt.h | 18 ++
drivers/gpu/drm/panfrost/panfrost_regs.h| 22 ++
include/uapi/drm/panfrost_drm.h | 24 ++
9 files changed, 435 insertions(+), 4 deletions(-)
create mode 100644 drivers/gpu/drm/panfrost/panfrost_perfcnt.c
create mode 100644 drivers/gpu/drm/panfrost/panfrost_perfcnt.h
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/4] drm/panfrost: Move gpu_{write, read}() macros to panfrost_regs.h
So they can be used from other files.
Signed-off-by: Boris Brezillon
Reviewed-by: Alyssa Rosenzweig
---
Changes in v4:
- Add Alyssa's R-b
Changes in v3:
- None
Changes in v2:
- None
---
drivers/gpu/drm/panfrost/panfrost_gpu.c | 3 ---
drivers/gpu/drm/panfrost/panfrost_regs.h | 3 +++
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_gpu.c
b/drivers/gpu/drm/panfrost/panfrost_gpu.c
index 58ef25573cda..6e68a100291c 100644
--- a/drivers/gpu/drm/panfrost/panfrost_gpu.c
+++ b/drivers/gpu/drm/panfrost/panfrost_gpu.c
@@ -17,9 +17,6 @@
#include "panfrost_gpu.h"
#include "panfrost_regs.h"
-#define gpu_write(dev, reg, data) writel(data, dev->iomem + reg)
-#define gpu_read(dev, reg) readl(dev->iomem + reg)
-
static irqreturn_t panfrost_gpu_irq_handler(int irq, void *data)
{
struct panfrost_device *pfdev = data;
diff --git a/drivers/gpu/drm/panfrost/panfrost_regs.h
b/drivers/gpu/drm/panfrost/panfrost_regs.h
index 578c5fc2188b..42d08860fd76 100644
--- a/drivers/gpu/drm/panfrost/panfrost_regs.h
+++ b/drivers/gpu/drm/panfrost/panfrost_regs.h
@@ -295,4 +295,7 @@
#define AS_FAULTSTATUS_ACCESS_TYPE_READ(0x2 << 8)
#define AS_FAULTSTATUS_ACCESS_TYPE_WRITE (0x3 << 8)
+#define gpu_write(dev, reg, data) writel(data, dev->iomem + reg)
+#define gpu_read(dev, reg) readl(dev->iomem + reg)
+
#endif
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm/vkms: stop generating CRCs on buffer overflow
On Mon, Jun 17, 2019 at 10:53:46PM -0300, Rodrigo Siqueira wrote:
> Hi Oleg,
>
> First of all, thank you for your patchset.
>
> On 06/13, Daniel Vetter wrote:
> > On Thu, Jun 13, 2019 at 03:18:01PM +0300, Oleg Vasilev wrote:
> > > Because interrupts are generated artifitially, kernel bug may lead to
> > > infinte attempts to submit CRC.
> > >
> > > Signed-off-by: Oleg Vasilev
> > > ---
> > > drivers/gpu/drm/vkms/vkms_crc.c | 10 +-
> > > 1 file changed, 9 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/vkms/vkms_crc.c
> > > b/drivers/gpu/drm/vkms/vkms_crc.c
> > > index d7b409a3c0f8..bc717ab5 100644
> > > --- a/drivers/gpu/drm/vkms/vkms_crc.c
> > > +++ b/drivers/gpu/drm/vkms/vkms_crc.c
> > > @@ -167,6 +167,7 @@ void vkms_crc_work_handle(struct work_struct *work)
> > > u32 crc32 = 0;
> > > u64 frame_start, frame_end;
> > > unsigned long flags;
> > > + int ret;
> > >
> > > spin_lock_irqsave(&out->state_lock, flags);
> > > frame_start = crtc_state->frame_start;
> > > @@ -202,7 +203,14 @@ void vkms_crc_work_handle(struct work_struct *work)
> > >* missing frames
> > >*/
> > > while (frame_start <= frame_end)
> > > - drm_crtc_add_crc_entry(crtc, true, frame_start++, &crc32);
> > > + {
> >
> > Bikeshed: Kernel codingstyle puts this on the same line as the closing )
> > of the while/if/for.
>
> I recommend you to create a post-commit script in your git repo.
> Something like this:
>
> touch .git/hooks/post-commit
>
> In the post-commit, add:
>
> exec git show --format=email HEAD | ./scripts/checkpatch.pl --strict
> --codespell
>
> > Aside from that not sure that's useful here, we've fixed the bug by now
> > ...
>
> IMHO, this patch is useful because it handles the return value from
> drm_crtc_add_crc_entry() which make the code a little bit more reliable.
> Additionally, it avoids polluting the dmesg output in case of a
> problem.
If it's the return value that annoys you, there's an easy fix: Let's
remove it! None of the other drivers look at it either.
Imo that's clearer than trying to do something reasonable when facing
driver bugs (which this is here).
-Daniel
>
> > -Daniel
> >
> > > + ret = drm_crtc_add_crc_entry(crtc, true, frame_start++, &crc32);
> > > + if (ret) {
> > > + DRM_WARN("VKMS stop generating CRCs\n");
> > > + out->crc_enabled = false;
> > > + break;
> > > + }
> > > + }
> > >
> > > out:
> > > /* to avoid using the same value for frame number again */
> > > --
> > > 2.21.0
> > >
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
>
> --
> Rodrigo Siqueira
> https://siqueira.tech
--
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 01/10] drm/vkms: Fix crc worker races
On Mon, Jun 17, 2019 at 11:39:31PM -0300, Rodrigo Siqueira wrote: > On 06/12, Daniel Vetter wrote: > > On Wed, Jun 12, 2019 at 10:33:11AM -0300, Rodrigo Siqueira wrote: > > > On Thu, Jun 6, 2019 at 7:28 PM Daniel Vetter > > > wrote: > > > > > > > > The issue we have is that the crc worker might fall behind. We've > > > > tried to handle this by tracking both the earliest frame for which it > > > > still needs to compute a crc, and the last one. Plus when the > > > > crtc_state changes, we have a new work item, which are all run in > > > > order due to the ordered workqueue we allocate for each vkms crtc. > > > > > > > > Trouble is there's been a few small issues in the current code: > > > > - we need to capture frame_end in the vblank hrtimer, not in the > > > > worker. The worker might run much later, and then we generate a lot > > > > of crc for which there's already a different worker queued up. > > > > - frame number might be 0, so create a new crc_pending boolean to > > > > track this without confusion. > > > > - we need to atomically grab frame_start/end and clear it, so do that > > > > all in one go. This is not going to create a new race, because if we > > > > race with the hrtimer then our work will be re-run. > > > > - only race that can happen is the following: > > > > 1. worker starts > > > > 2. hrtimer runs and updates frame_end > > > > 3. worker grabs frame_start/end, already reading the new frame_end, > > > > and clears crc_pending > > > > 4. hrtimer calls queue_work() > > > > 5. worker completes > > > > 6. worker gets re-run, crc_pending is false > > > > Explain this case a bit better by rewording the comment. > > > > > > > > v2: Demote warning level output to debug when we fail to requeue, this > > > > is expected under high load when the crc worker can't quite keep up. > > > > > > > > Cc: Shayenne Moura > > > > Cc: Rodrigo Siqueira > > > > Signed-off-by: Daniel Vetter > > > > Cc: Haneen Mohammed > > > > Cc: Daniel Vetter > > > > --- > > > > drivers/gpu/drm/vkms/vkms_crc.c | 27 +-- > > > > drivers/gpu/drm/vkms/vkms_crtc.c | 9 +++-- > > > > drivers/gpu/drm/vkms/vkms_drv.h | 2 ++ > > > > 3 files changed, 22 insertions(+), 16 deletions(-) > > > > > > > > diff --git a/drivers/gpu/drm/vkms/vkms_crc.c > > > > b/drivers/gpu/drm/vkms/vkms_crc.c > > > > index d7b409a3c0f8..66603da634fe 100644 > > > > --- a/drivers/gpu/drm/vkms/vkms_crc.c > > > > +++ b/drivers/gpu/drm/vkms/vkms_crc.c > > > > @@ -166,16 +166,24 @@ void vkms_crc_work_handle(struct work_struct > > > > *work) > > > > struct drm_plane *plane; > > > > u32 crc32 = 0; > > > > u64 frame_start, frame_end; > > > > + bool crc_pending; > > > > unsigned long flags; > > > > > > > > spin_lock_irqsave(&out->state_lock, flags); > > > > frame_start = crtc_state->frame_start; > > > > frame_end = crtc_state->frame_end; > > > > + crc_pending = crtc_state->crc_pending; > > > > + crtc_state->frame_start = 0; > > > > + crtc_state->frame_end = 0; > > > > + crtc_state->crc_pending = false; > > > > spin_unlock_irqrestore(&out->state_lock, flags); > > > > > > > > - /* _vblank_handle() hasn't updated frame_start yet */ > > > > - if (!frame_start || frame_start == frame_end) > > > > - goto out; > > > > + /* > > > > +* We raced with the vblank hrtimer and previous work already > > > > computed > > > > +* the crc, nothing to do. > > > > +*/ > > > > + if (!crc_pending) > > > > + return; > > > > > > I think this condition is not reachable because crc_pending will be > > > filled with true in `vkms_vblank_simulate()` which in turn schedule > > > the function `vkms_crc_work_handle()`. Just for checking, I tried to > > > reach this condition by running kms_flip, kms_pipe_crc_basic, and > > > kms_cursor_crc with two different VM setups[1], but I couldn't reach > > > it. What do you think? > > > > thread Athread B > > 1. run vblank hrtimer > > > > 2. starts running crc work (from previous > > vblank) > > > > 3. spin_lock() -> gets stalled on the spin_lock() > > because > >thread A has it already > > > > 4. update frame_end (only in > > later patches, atm this is > > impossible). crc_pending is set > > already. > > > > 5. schedule_work: since the work > > is running already, this means it > > is scheduled to run once more. > > > > 6. spin_unlock > > > > 7. compute crc, clear crc_pending > > 8. work finishes > > 9. work gets run again > > 8. crc_pending=false > > > > Since the spin_lock critical section is _very_ short (less than 1 usec I > > bet), this race is very hard to hit. > > First
Re: [PATCH 00/10] drm/vkms: rework crc worker
On Mon, Jun 17, 2019 at 11:49:04PM -0300, Rodrigo Siqueira wrote: > On 06/12, Daniel Vetter wrote: > > On Wed, Jun 12, 2019 at 10:28:41AM -0300, Rodrigo Siqueira wrote: > > > Hi Daniel, > > > > > > First of all, thank you very much for your patchset. > > > > > > I tried to make a detailed review of your series, and you can see my > > > comments in each patch. You’ll notice that I asked many things related > > > to the DRM subsystem with the hope that I could learn a little bit > > > more about DRM from your comments. > > > > > > Before you go through the review, I would like to start a discussion > > > about the vkms race conditions. First, I have to admit that I did not > > > understand the race conditions that you described before because I > > > couldn’t reproduce them. Now, I'm suspecting that I could not > > > experience the problem because I'm using QEMU with KVM; with this idea > > > in mind, I suppose that we have two scenarios for using vkms in a > > > virtual machine: > > > > > > * Scenario 1: The user has hardware virtualization support; in this > > > case, it is a little bit harder to experience race conditions with > > > vkms. > > > > > > * Scenario 2: Without hardware virtualization support, it is much > > > easier to experience race conditions. > > > > > > With these two scenarios in mind, I conducted a bunch of experiments > > > for trying to shed light on this issue. I did: > > > > > > 1. Enabled lockdep > > > > > > 2. Defined two different environments for testing both using QEMU with > > > and without kvm. See below the QEMU hardware options: > > > > > > * env_kvm: -enable-kvm -daemonize -m 1G -smp cores=2,cpus=2 > > > * env_no_kvm: -daemonize -m 2G -smp cores=4,cpus=4 > > > > > > 3. My test protocol: I) turn on the vm, II) clean /proc/lock_stat, > > > III) execute kms_cursor_crc, III) save the lock_stat file, and IV) > > > turn off the vm. > > > > > > 4. From the lockdep_stat, I just highlighted the row related to vkms > > > and the columns holdtime-total and holdtime-avg > > > > > > I would like to highlight that the following data does not have any > > > statistical approach, and its intention is solely to assist our > > > discussion. See below the summary of the collected data: > > > > > > Summary of the experiment results: > > > > > > ++++ > > > || env_kvm| env_no_kvm | > > > ++++ > > > | Test | Before | After | Before | After | > > > +++---++---+ > > > | kms_cursor_crc | S1 | S2 | M1 | M2 | > > > +++---++---+ > > > > > > * Before: before apply this patchset > > > * After: after apply this patchset > > > > > > -+--+--- > > > S1: Without this patchset and with kvm | holdtime-total | holdtime-avg > > > -++- > > > &(&vkms_out->lock)->rlock: | 21983.52 | 6.21 > > > (work_completion)(&vkms_state->crc_wo: | 20.47 | 20.47 > > > (wq_completion)vkms_crc_workq: | 3999507.87| 3352.48 > > > &(&vkms_out->state_lock)->rlock: | 378.47| 0.30 > > > (work_completion)(&vkms_state->crc_#2: | 3999066.30| 2848.34 > > > -++- > > > S2: With this patchset and with kvm || > > > -++- > > > &(&vkms_out->lock)->rlock: | 23262.83 | 6.34 > > > (work_completion)(&vkms_state->crc_wo: | 8.98 | 8.98 > > > &(&vkms_out->crc_lock)->rlock: | 307.28| 0.32 > > > (wq_completion)vkms_crc_workq: | 6567727.05| 12345.35 > > > (work_completion)(&vkms_state->crc_#2: | 6567135.15| 4488.81 > > > -++- > > > M1: Without this patchset and without kvm|| > > > -++- > > > &(&vkms_out->state_lock)->rlock: | 4994.72 | 1.61 > > > &(&vkms_out->lock)->rlock: | 247190.04 | 39.39 > > > (work_completion)(&vkms_state->crc_wo: | 31.32 | 31.32 > > > (wq_completion)vkms_crc_workq: | 20991073.78 | 13525.18 > > > (work_completion)(&vkms_state->crc_#2: | 20988347.18 | 11904.90 > > > -++- > > > M2: With this patchset and without kvm || > > > -++- > > > (wq_completion)vkms_crc_workq: | 42819161.68 | 36597.57 > > > &(&vkms_out->lock)->rlock: | 251257.06 | 35.80 > > > (work_complet
Re: [RFC PATCH 2/2] soc: ti: Add Support for the TI Page-based Address Translator (PAT)
On 07/06/2019 22:35, Andrew F. Davis wrote:
This patch adds a driver for the Page-based Address Translator (PAT)
present on various TI SoCs. A PAT device performs address translation
using tables stored in an internal SRAM. Each PAT supports a set number
of pages, each occupying a programmable 4KB, 16KB, 64KB, or 1MB of
addresses in a window for which an incoming transaction will be
translated.
Signed-off-by: Andrew F. Davis
---
drivers/soc/ti/Kconfig | 9 +
drivers/soc/ti/Makefile | 1 +
drivers/soc/ti/ti-pat.c | 569
include/uapi/linux/ti-pat.h | 44 +++
4 files changed, 623 insertions(+)
create mode 100644 drivers/soc/ti/ti-pat.c
create mode 100644 include/uapi/linux/ti-pat.h
diff --git a/drivers/soc/ti/Kconfig b/drivers/soc/ti/Kconfig
index f0be35d3dcba..b838ae74d01f 100644
--- a/drivers/soc/ti/Kconfig
+++ b/drivers/soc/ti/Kconfig
@@ -86,4 +86,13 @@ config TI_SCI_INTA_MSI_DOMAIN
help
Driver to enable Interrupt Aggregator specific MSI Domain.
+config TI_PAT
+ tristate "TI PAT DMA-BUF exporter"
+ select REGMAP
What is the reasoning for using regmap for internal register access? Why
not just use direct readl/writel for everything? To me it seems this is
only used during probe time also...
+ help
+ Driver for TI Page-based Address Translator (PAT). This driver
+ provides the an API allowing the remapping of a non-contiguous
+ DMA-BUF into a contiguous one that is sutable for devices needing
+ coniguous memory.
Minor typo: contiguous.
+
endif # SOC_TI
diff --git a/drivers/soc/ti/Makefile b/drivers/soc/ti/Makefile
index b3868d392d4f..1369642b40c3 100644
--- a/drivers/soc/ti/Makefile
+++ b/drivers/soc/ti/Makefile
@@ -9,3 +9,4 @@ obj-$(CONFIG_AMX3_PM) += pm33xx.o
obj-$(CONFIG_WKUP_M3_IPC) += wkup_m3_ipc.o
obj-$(CONFIG_TI_SCI_PM_DOMAINS) += ti_sci_pm_domains.o
obj-$(CONFIG_TI_SCI_INTA_MSI_DOMAIN) += ti_sci_inta_msi.o
+obj-$(CONFIG_TI_PAT) += ti-pat.o
diff --git a/drivers/soc/ti/ti-pat.c b/drivers/soc/ti/ti-pat.c
new file mode 100644
index ..7359ea0f7ccf
--- /dev/null
+++ b/drivers/soc/ti/ti-pat.c
@@ -0,0 +1,569 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * TI PAT mapped DMA-BUF memory re-exporter
+ *
+ * Copyright (C) 2018-2019 Texas Instruments Incorporated - http://www.ti.com/
+ * Andrew F. Davis
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#define TI_PAT_DRIVER_NAME "ti-pat"
Why do you have a define for this seeing it is only used in single location?
+
+/* TI PAT MMRS registers */
+#define TI_PAT_MMRS_PID0x0 /* Revision Register */
+#define TI_PAT_MMRS_CONFIG 0x4 /* Config Register */
+#define TI_PAT_MMRS_CONTROL0x10 /* Control Register */
+
+/* TI PAT CONTROL register field values */
+#define TI_PAT_CONTROL_ARB_MODE_UF 0x0 /* Updates first */
+#define TI_PAT_CONTROL_ARB_MODE_RR 0x2 /* Round-robin */
+
+#define TI_PAT_CONTROL_PAGE_SIZE_4KB 0x0
+#define TI_PAT_CONTROL_PAGE_SIZE_16KB 0x1
+#define TI_PAT_CONTROL_PAGE_SIZE_64KB 0x2
+#define TI_PAT_CONTROL_PAGE_SIZE_1MB 0x3
+
+static unsigned int ti_pat_page_sizes[] = {
+ [TI_PAT_CONTROL_PAGE_SIZE_4KB] = 4 * 1024,
+ [TI_PAT_CONTROL_PAGE_SIZE_16KB] = 16 * 1024,
+ [TI_PAT_CONTROL_PAGE_SIZE_64KB] = 64 * 1024,
+ [TI_PAT_CONTROL_PAGE_SIZE_1MB] = 1024 * 1024,
+};
+
+enum ti_pat_mmrs_fields {
+ /* Revision */
+ F_PID_MAJOR,
+ F_PID_MINOR,
+
+ /* Controls */
+ F_CONTROL_ARB_MODE,
+ F_CONTROL_PAGE_SIZE,
+ F_CONTROL_REPLACE_OID_EN,
+ F_CONTROL_EN,
+
+ /* sentinel */
+ F_MAX_FIELDS
+};
+
+static const struct reg_field ti_pat_mmrs_reg_fields[] = {
+ /* Revision */
+ [F_PID_MAJOR] = REG_FIELD(TI_PAT_MMRS_PID, 8, 10),
+ [F_PID_MINOR] = REG_FIELD(TI_PAT_MMRS_PID, 0, 5),
+ /* Controls */
+ [F_CONTROL_ARB_MODE]= REG_FIELD(TI_PAT_MMRS_CONTROL, 6, 7),
+ [F_CONTROL_PAGE_SIZE] = REG_FIELD(TI_PAT_MMRS_CONTROL, 4, 5),
+ [F_CONTROL_REPLACE_OID_EN] = REG_FIELD(TI_PAT_MMRS_CONTROL, 1, 1),
+ [F_CONTROL_EN] = REG_FIELD(TI_PAT_MMRS_CONTROL, 0, 0),
+};
+
+/**
+ * struct ti_pat_data - PAT device instance data
+ * @dev: PAT device structure
+ * @mdev: misc device
+ * @mmrs_map: Register map of MMRS region
+ * @table_base: Base address of TABLE region
Please add kerneldoc comments for all fields.
+ */
+struct ti_pat_data {
+ struct device *dev;
+ struct miscdevice mdev;
+ struct regmap *mmrs_map;
+ struct regmap_field *mmrs_fields[F_MAX_FIELDS];
+ void __iomem *table_base;
+ unsigned int page_count;
+ unsigned int page_size;
+ phys_addr_t window_base;
+
Re: [PULL] topic/remove-fbcon-notifiers for v5.3
Op 14-06-2019 om 11:25 schreef Maarten Lankhorst: > Hi all, > > As discussed with Daniel V, I'm just doing the paperwork here as drm-misc > maintainer. > > This is the topic pull request for the fbdev notifier removal. > > Bar, please make a final check and pull into your fbdev tree. > > Lee, please make a final check and pull into your backlight tree. > > Greg, this is just fyi, you already acked all the vt and staging patches in > here > to land through other trees. > > I'll pull this into drm-misc-next once Bart & Lee acked it. > > Cheers, Maarten. Bart, Lee, ping? > topic/remove-fbcon-notifiers-2019-06-14-1: > > topic/remove-fbcon-notifiers: > - remove fbdev notifier usage for fbcon, as prep work to clean up the fbcon > locking > - assorted locking checks in vt/console code > - assorted notifier and cleanups in fbdev and backlight code > > The following changes since commit d1fdb6d8f6a4109a4263176c84b899076a5f8008: > > Linux 5.2-rc4 (2019-06-08 20:24:46 -0700) > > are available in the Git repository at: > > git://anongit.freedesktop.org/drm/drm-misc > tags/topic/remove-fbcon-notifiers-2019-06-14-1 > > for you to fetch changes up to 1dcff4ae65185e8c0300972f6d8d39d9a9db2bda: > > backlight: simplify lcd notifier (2019-06-13 10:07:20 +0200) > > > Daniel Vetter (33): > dummycon: Sprinkle locking checks > fbdev: locking check for fb_set_suspend > vt: might_sleep() annotation for do_blank_screen > vt: More locking checks > fbdev/sa1100fb: Remove dead code > fbdev/cyber2000: Remove struct display > fbdev/aty128fb: Remove dead code > fbcon: s/struct display/struct fbcon_display/ > fbcon: Remove fbcon_has_exited > fbcon: call fbcon_fb_(un)registered directly > fbdev/sh_mobile: remove sh_mobile_lcdc_display_notify > fbdev/omap: sysfs files can't disappear before the device is gone > fbdev: sysfs files can't disappear before the device is gone > staging/olpc: lock_fb_info can't fail > fbdev/atyfb: lock_fb_info can't fail > fbdev: lock_fb_info cannot fail > fbcon: call fbcon_fb_bind directly > fbdev: make unregister/unlink functions not fail > fbdev: unify unlink_framebuffer paths > fbdev/sh_mob: Remove fb notifier callback > fbdev: directly call fbcon_suspended/resumed > fbcon: Call fbcon_mode_deleted/new_modelist directly > fbdev: Call fbcon_get_requirement directly > Revert "backlight/fbcon: Add FB_EVENT_CONBLANK" > fbmem: pull fbcon_fb_blanked out of fb_blank > fbdev: remove FBINFO_MISC_USEREVENT around fb_blank > fb: Flatten control flow in fb_set_var > fbcon: replace FB_EVENT_MODE_CHANGE/_ALL with direct calls > vgaswitcheroo: call fbcon_remap_all directly > fbcon: Call con2fb_map functions directly > fbcon: Document what I learned about fbcon locking > staging/olpc_dcon: Add drm conversion to TODO > backlight: simplify lcd notifier > > arch/arm/mach-pxa/am200epd.c| 13 +- > drivers/gpu/vga/vga_switcheroo.c| 11 +- > drivers/media/pci/ivtv/ivtvfb.c | 6 +- > drivers/staging/fbtft/fbtft-core.c | 4 +- > drivers/staging/olpc_dcon/TODO | 7 + > drivers/staging/olpc_dcon/olpc_dcon.c | 6 +- > drivers/tty/vt/vt.c | 18 ++ > drivers/video/backlight/backlight.c | 2 +- > drivers/video/backlight/lcd.c | 12 - > drivers/video/console/dummycon.c| 6 + > drivers/video/fbdev/aty/aty128fb.c | 64 > drivers/video/fbdev/aty/atyfb_base.c| 3 +- > drivers/video/fbdev/core/fbcmap.c | 6 +- > drivers/video/fbdev/core/fbcon.c| 313 --- > drivers/video/fbdev/core/fbcon.h| 6 +- > drivers/video/fbdev/core/fbmem.c| 399 > +--- > drivers/video/fbdev/core/fbsysfs.c | 20 +- > drivers/video/fbdev/cyber2000fb.c | 1 - > drivers/video/fbdev/neofb.c | 9 +- > drivers/video/fbdev/omap2/omapfb/omapfb-sysfs.c | 21 +- > drivers/video/fbdev/sa1100fb.c | 25 -- > drivers/video/fbdev/savage/savagefb_driver.c| 9 +- > drivers/video/fbdev/sh_mobile_lcdcfb.c | 132 +--- > drivers/video/fbdev/sh_mobile_lcdcfb.h | 5 - > include/linux/console_struct.h | 5 +- > include/linux/fb.h | 45 +-- > include/linux/fbcon.h | 30 ++ > 27 files changed, 396 insertions(+), 782 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/d
[PATCH 2/2] drm/prime: Update docs
Yes this is a bit a big patch, but since it's essentially a complete rewrite of all the prime docs I didn't see how to better split it up. Changes: - Consistently point to drm_gem_object_funcs as the preferred hooks, where applicable. - Document all the hooks in &drm_driver that lacked kerneldoc. - Completely new overview section, which now also includes the cleaned up lifetime/reference counting subchapter. I also mentioned the weak references in there due to the lookup caches. - Completely rewritten helper intro section, highlight the import/export related functionality. - Polish for all the functions and more cross references. I also sprinkled a bunch of todos all over. Most important: 0 code changes in here. The cleanup motivated by reading and improving all this will follow later on. v2: Actually update the prime helper docs. Plus add a few FIXMEs that I won't address right away in subsequent cleanup patches. v3: - Split out the function moving. This patch is now exclusively documentation changes. - Typos and nits (Sam). Cc: Sam Ravnborg Cc: Eric Anholt Cc: Emil Velikov Signed-off-by: Daniel Vetter --- Documentation/gpu/drm-mm.rst | 40 +-- drivers/gpu/drm/drm_prime.c | 197 +-- include/drm/drm_drv.h| 104 +++--- include/drm/drm_gem.h| 18 ++-- 4 files changed, 226 insertions(+), 133 deletions(-) diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst index c8ebd4f66a6a..b664f054c259 100644 --- a/Documentation/gpu/drm-mm.rst +++ b/Documentation/gpu/drm-mm.rst @@ -433,43 +433,11 @@ PRIME is the cross device buffer sharing framework in drm, originally created for the OPTIMUS range of multi-gpu platforms. To userspace PRIME buffers are dma-buf based file descriptors. -Overview and Driver Interface -- +Overview and Lifetime Rules +--- -Similar to GEM global names, PRIME file descriptors are also used to -share buffer objects across processes. They offer additional security: -as file descriptors must be explicitly sent over UNIX domain sockets to -be shared between applications, they can't be guessed like the globally -unique GEM names. - -Drivers that support the PRIME API must set the DRIVER_PRIME bit in the -struct :c:type:`struct drm_driver ` -driver_features field, and implement the prime_handle_to_fd and -prime_fd_to_handle operations. - -int (\*prime_handle_to_fd)(struct drm_device \*dev, struct drm_file -\*file_priv, uint32_t handle, uint32_t flags, int \*prime_fd); int -(\*prime_fd_to_handle)(struct drm_device \*dev, struct drm_file -\*file_priv, int prime_fd, uint32_t \*handle); Those two operations -convert a handle to a PRIME file descriptor and vice versa. Drivers must -use the kernel dma-buf buffer sharing framework to manage the PRIME file -descriptors. Similar to the mode setting API PRIME is agnostic to the -underlying buffer object manager, as long as handles are 32bit unsigned -integers. - -While non-GEM drivers must implement the operations themselves, GEM -drivers must use the :c:func:`drm_gem_prime_handle_to_fd()` and -:c:func:`drm_gem_prime_fd_to_handle()` helper functions. Those -helpers rely on the driver gem_prime_export and gem_prime_import -operations to create a dma-buf instance from a GEM object (dma-buf -exporter role) and to create a GEM object from a dma-buf instance -(dma-buf importer role). - -struct dma_buf \* (\*gem_prime_export)(struct drm_device \*dev, -struct drm_gem_object \*obj, int flags); struct drm_gem_object \* -(\*gem_prime_import)(struct drm_device \*dev, struct dma_buf -\*dma_buf); These two operations are mandatory for GEM drivers that -support PRIME. +.. kernel-doc:: drivers/gpu/drm/drm_prime.c + :doc: overview and lifetime rules PRIME Helper Functions -- diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c index 68b4de85370c..2234206288fa 100644 --- a/drivers/gpu/drm/drm_prime.c +++ b/drivers/gpu/drm/drm_prime.c @@ -38,47 +38,53 @@ #include "drm_internal.h" -/* - * DMA-BUF/GEM Object references and lifetime overview: - * - * On the export the dma_buf holds a reference to the exporting GEM - * object. It takes this reference in handle_to_fd_ioctl, when it - * first calls .prime_export and stores the exporting GEM object in - * the dma_buf priv. This reference needs to be released when the - * final reference to the &dma_buf itself is dropped and its - * &dma_buf_ops.release function is called. For GEM-based drivers, - * the dma_buf should be exported using drm_gem_dmabuf_export() and - * then released by drm_gem_dmabuf_release(). - * - * On the import the importing GEM object holds a reference to the - * dma_buf (which in turn holds a ref to the exporting GEM object). - * It takes that reference in the fd_to_handle ioctl. - * It calls dma_buf_get, creates an attachment to it and stores the - * attachment in the GEM object. When this attachmen
[PATCH 1/2] drm/prime: Shuffle functions.
Reorder all the functions in drm_prime.[hc] into three groups: core,
export helpers, import helpers.
Not other changes beyond moving the functions and their unchanged
kerneldoc around in here.
Cc: Sam Ravnborg
Cc: Eric Anholt
Cc: Emil Velikov
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_prime.c | 770 ++--
include/drm/drm_prime.h | 42 +-
2 files changed, 409 insertions(+), 403 deletions(-)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index d0c01318076b..68b4de85370c 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -181,42 +181,6 @@ static int drm_prime_lookup_buf_handle(struct
drm_prime_file_private *prime_fpri
return -ENOENT;
}
-/**
- * drm_gem_map_attach - dma_buf attach implementation for GEM
- * @dma_buf: buffer to attach device to
- * @attach: buffer attachment data
- *
- * Calls &drm_driver.gem_prime_pin for device specific handling. This can be
- * used as the &dma_buf_ops.attach callback.
- *
- * Returns 0 on success, negative error code on failure.
- */
-int drm_gem_map_attach(struct dma_buf *dma_buf,
- struct dma_buf_attachment *attach)
-{
- struct drm_gem_object *obj = dma_buf->priv;
-
- return drm_gem_pin(obj);
-}
-EXPORT_SYMBOL(drm_gem_map_attach);
-
-/**
- * drm_gem_map_detach - dma_buf detach implementation for GEM
- * @dma_buf: buffer to detach from
- * @attach: attachment to be detached
- *
- * Cleans up &dma_buf_attachment. This can be used as the &dma_buf_ops.detach
- * callback.
- */
-void drm_gem_map_detach(struct dma_buf *dma_buf,
- struct dma_buf_attachment *attach)
-{
- struct drm_gem_object *obj = dma_buf->priv;
-
- drm_gem_unpin(obj);
-}
-EXPORT_SYMBOL(drm_gem_map_detach);
-
void drm_prime_remove_buf_handle_locked(struct drm_prime_file_private
*prime_fpriv,
struct dma_buf *dma_buf)
{
@@ -242,64 +206,18 @@ void drm_prime_remove_buf_handle_locked(struct
drm_prime_file_private *prime_fpr
}
}
-/**
- * drm_gem_map_dma_buf - map_dma_buf implementation for GEM
- * @attach: attachment whose scatterlist is to be returned
- * @dir: direction of DMA transfer
- *
- * Calls &drm_driver.gem_prime_get_sg_table and then maps the scatterlist. This
- * can be used as the &dma_buf_ops.map_dma_buf callback.
- *
- * Returns sg_table containing the scatterlist to be returned; returns ERR_PTR
- * on error. May return -EINTR if it is interrupted by a signal.
- */
-
-struct sg_table *drm_gem_map_dma_buf(struct dma_buf_attachment *attach,
-enum dma_data_direction dir)
+void drm_prime_init_file_private(struct drm_prime_file_private *prime_fpriv)
{
- struct drm_gem_object *obj = attach->dmabuf->priv;
- struct sg_table *sgt;
-
- if (WARN_ON(dir == DMA_NONE))
- return ERR_PTR(-EINVAL);
-
- if (obj->funcs)
- sgt = obj->funcs->get_sg_table(obj);
- else
- sgt = obj->dev->driver->gem_prime_get_sg_table(obj);
-
- if (!dma_map_sg_attrs(attach->dev, sgt->sgl, sgt->nents, dir,
- DMA_ATTR_SKIP_CPU_SYNC)) {
- sg_free_table(sgt);
- kfree(sgt);
- sgt = ERR_PTR(-ENOMEM);
- }
-
- return sgt;
+ mutex_init(&prime_fpriv->lock);
+ prime_fpriv->dmabufs = RB_ROOT;
+ prime_fpriv->handles = RB_ROOT;
}
-EXPORT_SYMBOL(drm_gem_map_dma_buf);
-/**
- * drm_gem_unmap_dma_buf - unmap_dma_buf implementation for GEM
- * @attach: attachment to unmap buffer from
- * @sgt: scatterlist info of the buffer to unmap
- * @dir: direction of DMA transfer
- *
- * This can be used as the &dma_buf_ops.unmap_dma_buf callback.
- */
-void drm_gem_unmap_dma_buf(struct dma_buf_attachment *attach,
- struct sg_table *sgt,
- enum dma_data_direction dir)
+void drm_prime_destroy_file_private(struct drm_prime_file_private *prime_fpriv)
{
- if (!sgt)
- return;
-
- dma_unmap_sg_attrs(attach->dev, sgt->sgl, sgt->nents, dir,
- DMA_ATTR_SKIP_CPU_SYNC);
- sg_free_table(sgt);
- kfree(sgt);
+ /* by now drm_gem_release should've made sure the list is empty */
+ WARN_ON(!RB_EMPTY_ROOT(&prime_fpriv->dmabufs));
}
-EXPORT_SYMBOL(drm_gem_unmap_dma_buf);
/**
* drm_gem_dmabuf_export - dma_buf export implementation for GEM
@@ -351,128 +269,101 @@ void drm_gem_dmabuf_release(struct dma_buf *dma_buf)
EXPORT_SYMBOL(drm_gem_dmabuf_release);
/**
- * drm_gem_dmabuf_vmap - dma_buf vmap implementation for GEM
- * @dma_buf: buffer to be mapped
- *
- * Sets up a kernel virtual mapping. This can be used as the &dma_buf_ops.vmap
- * callback.
+ * drm_gem_prime_fd_to_handle - PRIME import function for GEM drivers
+ * @dev: dev to export the buffer from
+ * @file_priv: drm file-private structure
+ * @prime_fd:
[Bug 109754] util_blitter_generate_mipmap: Assertion `!util_format_has_stencil(desc)' failed
https://bugs.freedesktop.org/show_bug.cgi?id=109754 Pierre-Eric Pelloux-Prayer changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Pierre-Eric Pelloux-Prayer --- This issue has been fixed with https://cgit.freedesktop.org/mesa/mesa/commit/?id=4b11ed443b85e4fcddc5d0ef60dec096ecdb951e. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V2 1/5] drm/vkms: Move functions from vkms_crc to vkms_composer
On Mon, Jun 17, 2019 at 11:42:33PM -0300, Rodrigo Siqueira wrote:
> The vkms_crc file has functions related to compose operations which are
> not directly associated with CRC. This patch, move those function for a
> new file named vkms_composer.
>
> Signed-off-by: Rodrigo Siqueira
I guess my suggestion wasn't quite clear: I thought we should rename the
entire file from vkms_crc.c to vkms_composor.c. And then adjust functions
and datastructures to use vkms_composer instead of vkms_crc as the prefix.
-Daniel
> ---
> drivers/gpu/drm/vkms/Makefile| 9 +++-
> drivers/gpu/drm/vkms/vkms_composer.c | 69
> drivers/gpu/drm/vkms/vkms_composer.h | 12 +
> drivers/gpu/drm/vkms/vkms_crc.c | 65 +-
> 4 files changed, 90 insertions(+), 65 deletions(-)
> create mode 100644 drivers/gpu/drm/vkms/vkms_composer.c
> create mode 100644 drivers/gpu/drm/vkms/vkms_composer.h
>
> diff --git a/drivers/gpu/drm/vkms/Makefile b/drivers/gpu/drm/vkms/Makefile
> index 89f09bec7b23..b4c040854bd6 100644
> --- a/drivers/gpu/drm/vkms/Makefile
> +++ b/drivers/gpu/drm/vkms/Makefile
> @@ -1,4 +1,11 @@
> # SPDX-License-Identifier: GPL-2.0-only
> -vkms-y := vkms_drv.o vkms_plane.o vkms_output.o vkms_crtc.o vkms_gem.o
> vkms_crc.o
> +vkms-y := \
> + vkms_drv.o \
> + vkms_plane.o \
> + vkms_output.o \
> + vkms_crtc.o \
> + vkms_gem.o \
> + vkms_composer.o \
> + vkms_crc.o
>
> obj-$(CONFIG_DRM_VKMS) += vkms.o
> diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
> b/drivers/gpu/drm/vkms/vkms_composer.c
> new file mode 100644
> index ..3d7c5e316d6e
> --- /dev/null
> +++ b/drivers/gpu/drm/vkms/vkms_composer.c
> @@ -0,0 +1,69 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +
> +#include "vkms_drv.h"
> +#include "vkms_composer.h"
> +#include
> +
> +/**
> + * blend - belnd value at vaddr_src with value at vaddr_dst
> + * @vaddr_dst: destination address
> + * @vaddr_src: source address
> + * @dest: destination framebuffer's metadata
> + * @src: source framebuffer's metadata
> + *
> + * Blend value at vaddr_src with value at vaddr_dst.
> + * Currently, this function write value at vaddr_src on value
> + * at vaddr_dst using buffer's metadata to locate the new values
> + * from vaddr_src and their distenation at vaddr_dst.
> + *
> + * Todo: Use the alpha value to blend vaddr_src with vaddr_dst
> + *instead of overwriting it.
> + */
> +void blend(void *vaddr_dst, void *vaddr_src, struct vkms_crc_data *dest,
> +struct vkms_crc_data *src)
> +{
> + int i, j, j_dst, i_dst;
> + int offset_src, offset_dst;
> +
> + int x_src = src->src.x1 >> 16;
> + int y_src = src->src.y1 >> 16;
> +
> + int x_dst = src->dst.x1;
> + int y_dst = src->dst.y1;
> + int h_dst = drm_rect_height(&src->dst);
> + int w_dst = drm_rect_width(&src->dst);
> +
> + int y_limit = y_src + h_dst;
> + int x_limit = x_src + w_dst;
> +
> + for (i = y_src, i_dst = y_dst; i < y_limit; ++i) {
> + for (j = x_src, j_dst = x_dst; j < x_limit; ++j) {
> + offset_dst = dest->offset
> + + (i_dst * dest->pitch)
> + + (j_dst++ * dest->cpp);
> + offset_src = src->offset
> + + (i * src->pitch)
> + + (j * src->cpp);
> +
> + memcpy(vaddr_dst + offset_dst,
> +vaddr_src + offset_src, sizeof(u32));
> + }
> + i_dst++;
> + }
> +}
> +
> +void compose_cursor(struct vkms_crc_data *cursor,
> + struct vkms_crc_data *primary, void *vaddr_out)
> +{
> + struct drm_gem_object *cursor_obj;
> + struct vkms_gem_object *cursor_vkms_obj;
> +
> + cursor_obj = drm_gem_fb_get_obj(&cursor->fb, 0);
> + cursor_vkms_obj = drm_gem_to_vkms_gem(cursor_obj);
> +
> + if (WARN_ON(!cursor_vkms_obj->vaddr))
> + return;
> +
> + blend(vaddr_out, cursor_vkms_obj->vaddr, primary, cursor);
> +}
> +
> diff --git a/drivers/gpu/drm/vkms/vkms_composer.h
> b/drivers/gpu/drm/vkms/vkms_composer.h
> new file mode 100644
> index ..53fdee17a632
> --- /dev/null
> +++ b/drivers/gpu/drm/vkms/vkms_composer.h
> @@ -0,0 +1,12 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +
> +#ifndef _VKMS_COMPOSER_H_
> +#define _VKMS_COMPOSER_H_
> +
> +void blend(void *vaddr_dst, void *vaddr_src, struct vkms_crc_data *dest,
> +struct vkms_crc_data *src);
> +
> +void compose_cursor(struct vkms_crc_data *cursor,
> + struct vkms_crc_data *primary, void *vaddr_out);
> +
> +#endif /* _VKMS_COMPOSER_H_ */
> diff --git a/drivers/gpu/drm/vkms/vkms_crc.c b/drivers/gpu/drm/vkms/vkms_crc.c
> index 4b3146d83265..3c6a35aba494 100644
> --- a/drivers/gpu/drm/vkms/vkms_crc.c
> +++ b/drivers/gpu/drm/vkms/vkms_crc.c
> @@ -1,6 +1,7 @@
> // SPDX-License-Identifier: GPL-2.0+
>
> #include
Re: [PATCH v2 2/2] arm: dts: add ARM Mali GPU node for Odroid XU3
On Sat, 15 Jun 2019 at 01:57, Joseph Kogut wrote:
>
> Add device tree node for mali gpu on Odroid XU3 SoCs.
>
> Signed-off-by: Joseph Kogut
> ---
>
> Changes v1 -> v2:
> - Use interrupt name ordering from binding doc
> - Specify a single clock for GPU node
> - Add gpu opp table
> - Fix warnings from IRQ_TYPE_NONE
>
> .../boot/dts/exynos5422-odroidxu3-common.dtsi | 26 +++
> 1 file changed, 26 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> index 93a48f2dda49..b8a4246e3b37 100644
> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> @@ -48,6 +48,32 @@
> cooling-levels = <0 130 170 230>;
> };
>
> + gpu: gpu@1180 {
> + compatible = "samsung,exynos-mali", "arm,mali-t628";
> + reg = <0x1180 0x5000>;
> + interrupts = ,
> +,
> +;
> + interrupt-names = "job", "mmu", "gpu";
> + clocks = <&clock CLK_G3D>;
> + mali-supply = <&buck4_reg>;
> + operating-points-v2 = <&gpu_opp_table>;
> + };
> +
> + gpu_opp_table: gpu-opp-table {
One more thing - use "opp_table" as node name (generic class of node,
matches style with other tables).
Best regards,
Krzysztof
> + compatible = "operating-points-v2";
> +
> + opp-17700 {
> + opp-hz = /bits/ 64 <11700>;
> + opp-microvolt = <812500>;
> + };
> +
> + opp-6 {
> + opp-hz = /bits/ 64 <6>;
> + opp-microvolt = <115>;
> + };
> + };
> +
> thermal-zones {
> cpu0_thermal: cpu0-thermal {
> thermal-sensors = <&tmu_cpu0 0>;
> --
> 2.22.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V2 4/5] drm/vkms: Use index instead of 0 in possible crtc
On Mon, Jun 17, 2019 at 11:45:29PM -0300, Rodrigo Siqueira wrote:
> When vkms calls drm_universal_plane_init(), it sets 0 for the
> possible_crtcs parameter which works well for a single encoder and
> connector; however, this approach is not flexible and does not fit well
> for vkms. This commit adds an index parameter for vkms_plane_init()
> which makes code flexible and enables vkms to support other DRM features.
>
> Signed-off-by: Rodrigo Siqueira
> ---
> drivers/gpu/drm/vkms/vkms_drv.c| 2 +-
> drivers/gpu/drm/vkms/vkms_drv.h| 4 ++--
> drivers/gpu/drm/vkms/vkms_output.c | 6 +++---
> drivers/gpu/drm/vkms/vkms_plane.c | 4 ++--
> 4 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
> index cc53ef88a331..966b3d653189 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.c
> +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> @@ -127,7 +127,7 @@ static int vkms_modeset_init(struct vkms_device *vkmsdev)
> dev->mode_config.preferred_depth = 24;
> dev->mode_config.helper_private = &vkms_mode_config_helpers;
>
> - return vkms_output_init(vkmsdev);
> + return vkms_output_init(vkmsdev, 0);
Having to hard-code the index because for the crtc you need the planes,
but for the planes you need drm_crtc_index of their crtc is annoying, but
not really a better way :-/
Reviewed-by: Daniel Vetter
> }
>
> static int __init vkms_init(void)
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
> index 8d628d18105e..ad63dbe5e994 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.h
> +++ b/drivers/gpu/drm/vkms/vkms_drv.h
> @@ -115,10 +115,10 @@ bool vkms_get_vblank_timestamp(struct drm_device *dev,
> unsigned int pipe,
> int *max_error, ktime_t *vblank_time,
> bool in_vblank_irq);
>
> -int vkms_output_init(struct vkms_device *vkmsdev);
> +int vkms_output_init(struct vkms_device *vkmsdev, int index);
>
> struct drm_plane *vkms_plane_init(struct vkms_device *vkmsdev,
> - enum drm_plane_type type);
> + enum drm_plane_type type, int index);
>
> /* Gem stuff */
> struct drm_gem_object *vkms_gem_create(struct drm_device *dev,
> diff --git a/drivers/gpu/drm/vkms/vkms_output.c
> b/drivers/gpu/drm/vkms/vkms_output.c
> index 56fb5c2a2315..fb1941a6522c 100644
> --- a/drivers/gpu/drm/vkms/vkms_output.c
> +++ b/drivers/gpu/drm/vkms/vkms_output.c
> @@ -35,7 +35,7 @@ static const struct drm_connector_helper_funcs
> vkms_conn_helper_funcs = {
> .get_modes= vkms_conn_get_modes,
> };
>
> -int vkms_output_init(struct vkms_device *vkmsdev)
> +int vkms_output_init(struct vkms_device *vkmsdev, int index)
> {
> struct vkms_output *output = &vkmsdev->output;
> struct drm_device *dev = &vkmsdev->drm;
> @@ -45,12 +45,12 @@ int vkms_output_init(struct vkms_device *vkmsdev)
> struct drm_plane *primary, *cursor = NULL;
> int ret;
>
> - primary = vkms_plane_init(vkmsdev, DRM_PLANE_TYPE_PRIMARY);
> + primary = vkms_plane_init(vkmsdev, DRM_PLANE_TYPE_PRIMARY, index);
> if (IS_ERR(primary))
> return PTR_ERR(primary);
>
> if (enable_cursor) {
> - cursor = vkms_plane_init(vkmsdev, DRM_PLANE_TYPE_CURSOR);
> + cursor = vkms_plane_init(vkmsdev, DRM_PLANE_TYPE_CURSOR, index);
> if (IS_ERR(cursor)) {
> ret = PTR_ERR(cursor);
> goto err_cursor;
> diff --git a/drivers/gpu/drm/vkms/vkms_plane.c
> b/drivers/gpu/drm/vkms/vkms_plane.c
> index 8cf40297cf56..3f8e8b53f3bb 100644
> --- a/drivers/gpu/drm/vkms/vkms_plane.c
> +++ b/drivers/gpu/drm/vkms/vkms_plane.c
> @@ -176,7 +176,7 @@ static const struct drm_plane_helper_funcs
> vkms_primary_helper_funcs = {
> };
>
> struct drm_plane *vkms_plane_init(struct vkms_device *vkmsdev,
> - enum drm_plane_type type)
> + enum drm_plane_type type, int index)
> {
> struct drm_device *dev = &vkmsdev->drm;
> const struct drm_plane_helper_funcs *funcs;
> @@ -198,7 +198,7 @@ struct drm_plane *vkms_plane_init(struct vkms_device
> *vkmsdev,
> funcs = &vkms_primary_helper_funcs;
> }
>
> - ret = drm_universal_plane_init(dev, plane, 0,
> + ret = drm_universal_plane_init(dev, plane, 1 << index,
> &vkms_plane_funcs,
> formats, nformats,
> NULL, type, NULL);
> --
> 2.21.0
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH V2 5/5] drm/vkms: Add support for writeback
On Mon, Jun 17, 2019 at 11:45:55PM -0300, Rodrigo Siqueira wrote:
> This patch implements the necessary functions to add writeback support
> for vkms. This feature is useful for testing compositors if you don't
> have hardware with writeback support.
>
> Change in V2:
> - Rework signal completion (Brian)
> - Integrates writeback with active_planes (Daniel)
> - Compose cursor (Daniel)
Not quite what I had in mind ... my idea was to reuse the crc worker
(hence renaming all that stuff to vkms_composer). The problem here is that
now we have the blend/compose code duplicated, at least parts of it. Plus
if you enable both crc and writeback, then we compose 2x, which is a bit
too much.
Rough sketch of an implementation:
- add writeback_pending, like we have crc_pending already. Difference is
that writeback is one-shot, i.e. set it in atomic_check somewhere, clear
it in the crc_worker (well, composer_worker now). vblank hrtimer will
not re-enable that one (unlike crc_pending).
- in the crc worker, if writeback_pending is set, then compose everything
into the writeback buffer instead of into our private crc buffer. Except
that we use different memory, crc computation will be done exactly the
same. For subsequent frames with the same crtc_state we will again use
the normal crc buffer to compose & compute the crc.
The benefit here is that we'll only have one place in vkms that does
composing, so if we add lots more features in the future, it'll be much
easier to maintain. Also since this guarantees that the crc will match
exactly what we've written back, we can use the crc to help validate our
writeback code.
Cheers, Daniel
>
> Signed-off-by: Rodrigo Siqueira
> ---
> drivers/gpu/drm/vkms/Makefile | 3 +-
> drivers/gpu/drm/vkms/vkms_drv.c | 7 ++
> drivers/gpu/drm/vkms/vkms_drv.h | 6 +
> drivers/gpu/drm/vkms/vkms_output.c| 6 +
> drivers/gpu/drm/vkms/vkms_writeback.c | 166 ++
> 5 files changed, 187 insertions(+), 1 deletion(-)
> create mode 100644 drivers/gpu/drm/vkms/vkms_writeback.c
>
> diff --git a/drivers/gpu/drm/vkms/Makefile b/drivers/gpu/drm/vkms/Makefile
> index b4c040854bd6..091e6fa643d1 100644
> --- a/drivers/gpu/drm/vkms/Makefile
> +++ b/drivers/gpu/drm/vkms/Makefile
> @@ -6,6 +6,7 @@ vkms-y := \
> vkms_crtc.o \
> vkms_gem.o \
> vkms_composer.o \
> - vkms_crc.o
> + vkms_crc.o \
> + vkms_writeback.o
>
> obj-$(CONFIG_DRM_VKMS) += vkms.o
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
> index 966b3d653189..d870779abf9d 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.c
> +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> @@ -30,6 +30,10 @@ bool enable_cursor;
> module_param_named(enable_cursor, enable_cursor, bool, 0444);
> MODULE_PARM_DESC(enable_cursor, "Enable/Disable cursor support");
>
> +bool enable_writeback;
> +module_param_named(enable_writeback, enable_writeback, bool, 0444);
> +MODULE_PARM_DESC(enable_writeback, "Enable/Disable writeback connector");
> +
> static const struct file_operations vkms_driver_fops = {
> .owner = THIS_MODULE,
> .open = drm_open,
> @@ -158,6 +162,9 @@ static int __init vkms_init(void)
> goto out_fini;
> }
>
> + if (enable_writeback)
> + DRM_INFO("Writeback connector enabled");
> +
> ret = vkms_modeset_init(vkms_device);
> if (ret)
> goto out_fini;
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
> index ad63dbe5e994..bf3fa737b3d7 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.h
> +++ b/drivers/gpu/drm/vkms/vkms_drv.h
> @@ -7,6 +7,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #define XRES_MIN20
> @@ -19,6 +20,7 @@
> #define YRES_MAX 8192
>
> extern bool enable_cursor;
> +extern bool enable_writeback;
>
> struct vkms_data {
> struct drm_framebuffer fb;
> @@ -63,6 +65,7 @@ struct vkms_output {
> struct drm_crtc crtc;
> struct drm_encoder encoder;
> struct drm_connector connector;
> + struct drm_writeback_connector wb_connector;
> struct hrtimer vblank_hrtimer;
> ktime_t period_ns;
> struct drm_pending_vblank_event *event;
> @@ -143,4 +146,7 @@ int vkms_verify_crc_source(struct drm_crtc *crtc, const
> char *source_name,
> size_t *values_cnt);
> void vkms_crc_work_handle(struct work_struct *work);
>
> +/* Writeback */
> +int enable_writeback_connector(struct vkms_device *vkmsdev);
> +
> #endif /* _VKMS_DRV_H_ */
> diff --git a/drivers/gpu/drm/vkms/vkms_output.c
> b/drivers/gpu/drm/vkms/vkms_output.c
> index fb1941a6522c..3b093ae8f373 100644
> --- a/drivers/gpu/drm/vkms/vkms_output.c
> +++ b/drivers/gpu/drm/vkms/vkms_output.c
> @@ -84,6 +84,12 @@ int vkms_output_init(struct vkms_device *vkmsdev, int
> index)
> goto err_attach;
> }
>
> + if (enable_writeback) {
> +
Re: [PATCH 20/59] drm/meson: Drop drm_gem_prime_export/import
On 14/06/2019 22:35, Daniel Vetter wrote:
> They're the default.
>
> Aside: Would be really nice to switch the others over to
> drm_gem_object_funcs.
Yep, adding this to my infinite TODO list
>
> Signed-off-by: Daniel Vetter
> Cc: Neil Armstrong
> Cc: Kevin Hilman
> Cc: linux-amlo...@lists.infradead.org
> Cc: linux-arm-ker...@lists.infradead.org
> ---
> drivers/gpu/drm/meson/meson_drv.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/meson/meson_drv.c
> b/drivers/gpu/drm/meson/meson_drv.c
> index 140363f93575..37dca83d6eb1 100644
> --- a/drivers/gpu/drm/meson/meson_drv.c
> +++ b/drivers/gpu/drm/meson/meson_drv.c
> @@ -101,8 +101,6 @@ static struct drm_driver meson_driver = {
> /* PRIME Ops */
> .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> - .gem_prime_import = drm_gem_prime_import,
> - .gem_prime_export = drm_gem_prime_export,
> .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
> .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
> .gem_prime_vmap = drm_gem_cma_prime_vmap,
>
Acked-by: Neil Armstrong
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 30/59] drm/stm: Drop drm_gem_prime_export/import
Hi Daniel,
Acked-by: Philippe Cornu
We will have a look to simplify this part of the code.
Thank you for your patch.
Philippe :-)
On 6/14/19 10:35 PM, Daniel Vetter wrote:
> They're the default.
>
> Aside: Would be really nice to switch the others over to
> drm_gem_object_funcs.
>
> Signed-off-by: Daniel Vetter
> Cc: Yannick Fertre
> Cc: Philippe Cornu
> Cc: Benjamin Gaignard
> Cc: Vincent Abriou
> Cc: Maxime Coquelin
> Cc: Alexandre Torgue
> Cc: linux-st...@st-md-mailman.stormreply.com
> Cc: linux-arm-ker...@lists.infradead.org
> ---
> drivers/gpu/drm/stm/drv.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/stm/drv.c b/drivers/gpu/drm/stm/drv.c
> index 4026c33ccc39..331f5e8d779b 100644
> --- a/drivers/gpu/drm/stm/drv.c
> +++ b/drivers/gpu/drm/stm/drv.c
> @@ -67,8 +67,6 @@ static struct drm_driver drv_driver = {
> .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> .gem_free_object_unlocked = drm_gem_cma_free_object,
> .gem_vm_ops = &drm_gem_cma_vm_ops,
> - .gem_prime_export = drm_gem_prime_export,
> - .gem_prime_import = drm_gem_prime_import,
> .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
> .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
> .gem_prime_vmap = drm_gem_cma_prime_vmap,
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm/stm: drv: fix suspend/resume
Hi Yannick,
Thank you for your patch.
Acked-by: Philippe Cornu
Philippe :-)
On 6/17/19 9:18 AM, Yannick Fertré wrote:
> Without this fix, the system can not go in "suspend" mode
> due to an error in drv_suspend function.
>
> Fixes: 35ab6cf ("drm/stm: support runtime power management")
>
> Signed-off-by: Yannick Fertré
> ---
> drivers/gpu/drm/stm/drv.c | 15 ---
> 1 file changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/stm/drv.c b/drivers/gpu/drm/stm/drv.c
> index 5659572..9dee4e4 100644
> --- a/drivers/gpu/drm/stm/drv.c
> +++ b/drivers/gpu/drm/stm/drv.c
> @@ -136,8 +136,7 @@ static __maybe_unused int drv_suspend(struct device *dev)
> struct ltdc_device *ldev = ddev->dev_private;
> struct drm_atomic_state *state;
>
> - if (WARN_ON(!ldev->suspend_state))
> - return -ENOENT;
> + WARN_ON(ldev->suspend_state);
>
> state = drm_atomic_helper_suspend(ddev);
> if (IS_ERR(state))
> @@ -155,15 +154,17 @@ static __maybe_unused int drv_resume(struct device *dev)
> struct ltdc_device *ldev = ddev->dev_private;
> int ret;
>
> + if (WARN_ON(!ldev->suspend_state))
> + return -ENOENT;
> +
> pm_runtime_force_resume(dev);
> ret = drm_atomic_helper_resume(ddev, ldev->suspend_state);
> - if (ret) {
> + if (ret)
> pm_runtime_force_suspend(dev);
> - ldev->suspend_state = NULL;
> - return ret;
> - }
>
> - return 0;
> + ldev->suspend_state = NULL;
> +
> + return ret;
> }
>
> static __maybe_unused int drv_runtime_suspend(struct device *dev)
>
Re: [PULL] topic/remove-fbcon-notifiers for v5.3
On Tue, 18 Jun 2019, Maarten Lankhorst wrote: > Op 14-06-2019 om 11:25 schreef Maarten Lankhorst: > > Hi all, > > > > As discussed with Daniel V, I'm just doing the paperwork here as drm-misc > > maintainer. > > > > This is the topic pull request for the fbdev notifier removal. > > > > Bar, please make a final check and pull into your fbdev tree. > > > > Lee, please make a final check and pull into your backlight tree. > > > > Greg, this is just fyi, you already acked all the vt and staging patches in > > here > > to land through other trees. > > > > I'll pull this into drm-misc-next once Bart & Lee acked it. > > > > Cheers, Maarten. > > Bart, Lee, ping? Asking for an Ack on a PR is kind of odd. If you have all of the patch Acks you need, and you've made the PR has small as possible, then you should be good to go. My plan is to see if any of this collides with my PR to Linus. If it doesn't then I may not have to pull it in at all. > > topic/remove-fbcon-notifiers-2019-06-14-1: > > > > topic/remove-fbcon-notifiers: > > - remove fbdev notifier usage for fbcon, as prep work to clean up the fbcon > > locking > > - assorted locking checks in vt/console code > > - assorted notifier and cleanups in fbdev and backlight code > > > > The following changes since commit d1fdb6d8f6a4109a4263176c84b899076a5f8008: > > > > Linux 5.2-rc4 (2019-06-08 20:24:46 -0700) > > > > are available in the Git repository at: > > > > git://anongit.freedesktop.org/drm/drm-misc > > tags/topic/remove-fbcon-notifiers-2019-06-14-1 > > > > for you to fetch changes up to 1dcff4ae65185e8c0300972f6d8d39d9a9db2bda: > > > > backlight: simplify lcd notifier (2019-06-13 10:07:20 +0200) > > > > > > Daniel Vetter (33): > > dummycon: Sprinkle locking checks > > fbdev: locking check for fb_set_suspend > > vt: might_sleep() annotation for do_blank_screen > > vt: More locking checks > > fbdev/sa1100fb: Remove dead code > > fbdev/cyber2000: Remove struct display > > fbdev/aty128fb: Remove dead code > > fbcon: s/struct display/struct fbcon_display/ > > fbcon: Remove fbcon_has_exited > > fbcon: call fbcon_fb_(un)registered directly > > fbdev/sh_mobile: remove sh_mobile_lcdc_display_notify > > fbdev/omap: sysfs files can't disappear before the device is gone > > fbdev: sysfs files can't disappear before the device is gone > > staging/olpc: lock_fb_info can't fail > > fbdev/atyfb: lock_fb_info can't fail > > fbdev: lock_fb_info cannot fail > > fbcon: call fbcon_fb_bind directly > > fbdev: make unregister/unlink functions not fail > > fbdev: unify unlink_framebuffer paths > > fbdev/sh_mob: Remove fb notifier callback > > fbdev: directly call fbcon_suspended/resumed > > fbcon: Call fbcon_mode_deleted/new_modelist directly > > fbdev: Call fbcon_get_requirement directly > > Revert "backlight/fbcon: Add FB_EVENT_CONBLANK" > > fbmem: pull fbcon_fb_blanked out of fb_blank > > fbdev: remove FBINFO_MISC_USEREVENT around fb_blank > > fb: Flatten control flow in fb_set_var > > fbcon: replace FB_EVENT_MODE_CHANGE/_ALL with direct calls > > vgaswitcheroo: call fbcon_remap_all directly > > fbcon: Call con2fb_map functions directly > > fbcon: Document what I learned about fbcon locking > > staging/olpc_dcon: Add drm conversion to TODO > > backlight: simplify lcd notifier > > > > arch/arm/mach-pxa/am200epd.c| 13 +- > > drivers/gpu/vga/vga_switcheroo.c| 11 +- > > drivers/media/pci/ivtv/ivtvfb.c | 6 +- > > drivers/staging/fbtft/fbtft-core.c | 4 +- > > drivers/staging/olpc_dcon/TODO | 7 + > > drivers/staging/olpc_dcon/olpc_dcon.c | 6 +- > > drivers/tty/vt/vt.c | 18 ++ > > drivers/video/backlight/backlight.c | 2 +- > > drivers/video/backlight/lcd.c | 12 - > > drivers/video/console/dummycon.c| 6 + > > drivers/video/fbdev/aty/aty128fb.c | 64 > > drivers/video/fbdev/aty/atyfb_base.c| 3 +- > > drivers/video/fbdev/core/fbcmap.c | 6 +- > > drivers/video/fbdev/core/fbcon.c| 313 --- > > drivers/video/fbdev/core/fbcon.h| 6 +- > > drivers/video/fbdev/core/fbmem.c| 399 > > +--- > > drivers/video/fbdev/core/fbsysfs.c | 20 +- > > drivers/video/fbdev/cyber2000fb.c | 1 - > > drivers/video/fbdev/neofb.c | 9 +- > > drivers/video/fbdev/omap2/omapfb/omapfb-sysfs.c | 21 +- > > drivers/video/fbdev/sa1100fb.c | 25 -- > > drivers/video/fbdev/savage/savagefb_dri
Re: [PULL] topic/remove-fbcon-notifiers for v5.3
On Tue, Jun 18, 2019 at 11:03:47AM +0100, Lee Jones wrote: > On Tue, 18 Jun 2019, Maarten Lankhorst wrote: > > > Op 14-06-2019 om 11:25 schreef Maarten Lankhorst: > > > Hi all, > > > > > > As discussed with Daniel V, I'm just doing the paperwork here as drm-misc > > > maintainer. > > > > > > This is the topic pull request for the fbdev notifier removal. > > > > > > Bar, please make a final check and pull into your fbdev tree. > > > > > > Lee, please make a final check and pull into your backlight tree. > > > > > > Greg, this is just fyi, you already acked all the vt and staging patches > > > in here > > > to land through other trees. > > > > > > I'll pull this into drm-misc-next once Bart & Lee acked it. > > > > > > Cheers, Maarten. > > > > Bart, Lee, ping? > > Asking for an Ack on a PR is kind of odd. If you have all of the > patch Acks you need, and you've made the PR has small as possible, > then you should be good to go. Ime there's lots of ways to screw up a pull request, so asking for a "yup looks good to me" seems reasonable. I've done that with all the topic pulls in the past. > My plan is to see if any of this collides with my PR to Linus. If it > doesn't then I may not have to pull it in at all. For simple conflicts Linus usually prefers to resolve them himself. The topic pull is needed if there's more stuff on top, like patches that need to be rebased ... -Daniel > > > > topic/remove-fbcon-notifiers-2019-06-14-1: > > > > > > topic/remove-fbcon-notifiers: > > > - remove fbdev notifier usage for fbcon, as prep work to clean up the > > > fbcon locking > > > - assorted locking checks in vt/console code > > > - assorted notifier and cleanups in fbdev and backlight code > > > > > > The following changes since commit > > > d1fdb6d8f6a4109a4263176c84b899076a5f8008: > > > > > > Linux 5.2-rc4 (2019-06-08 20:24:46 -0700) > > > > > > are available in the Git repository at: > > > > > > git://anongit.freedesktop.org/drm/drm-misc > > > tags/topic/remove-fbcon-notifiers-2019-06-14-1 > > > > > > for you to fetch changes up to 1dcff4ae65185e8c0300972f6d8d39d9a9db2bda: > > > > > > backlight: simplify lcd notifier (2019-06-13 10:07:20 +0200) > > > > > > > > > Daniel Vetter (33): > > > dummycon: Sprinkle locking checks > > > fbdev: locking check for fb_set_suspend > > > vt: might_sleep() annotation for do_blank_screen > > > vt: More locking checks > > > fbdev/sa1100fb: Remove dead code > > > fbdev/cyber2000: Remove struct display > > > fbdev/aty128fb: Remove dead code > > > fbcon: s/struct display/struct fbcon_display/ > > > fbcon: Remove fbcon_has_exited > > > fbcon: call fbcon_fb_(un)registered directly > > > fbdev/sh_mobile: remove sh_mobile_lcdc_display_notify > > > fbdev/omap: sysfs files can't disappear before the device is gone > > > fbdev: sysfs files can't disappear before the device is gone > > > staging/olpc: lock_fb_info can't fail > > > fbdev/atyfb: lock_fb_info can't fail > > > fbdev: lock_fb_info cannot fail > > > fbcon: call fbcon_fb_bind directly > > > fbdev: make unregister/unlink functions not fail > > > fbdev: unify unlink_framebuffer paths > > > fbdev/sh_mob: Remove fb notifier callback > > > fbdev: directly call fbcon_suspended/resumed > > > fbcon: Call fbcon_mode_deleted/new_modelist directly > > > fbdev: Call fbcon_get_requirement directly > > > Revert "backlight/fbcon: Add FB_EVENT_CONBLANK" > > > fbmem: pull fbcon_fb_blanked out of fb_blank > > > fbdev: remove FBINFO_MISC_USEREVENT around fb_blank > > > fb: Flatten control flow in fb_set_var > > > fbcon: replace FB_EVENT_MODE_CHANGE/_ALL with direct calls > > > vgaswitcheroo: call fbcon_remap_all directly > > > fbcon: Call con2fb_map functions directly > > > fbcon: Document what I learned about fbcon locking > > > staging/olpc_dcon: Add drm conversion to TODO > > > backlight: simplify lcd notifier > > > > > > arch/arm/mach-pxa/am200epd.c| 13 +- > > > drivers/gpu/vga/vga_switcheroo.c| 11 +- > > > drivers/media/pci/ivtv/ivtvfb.c | 6 +- > > > drivers/staging/fbtft/fbtft-core.c | 4 +- > > > drivers/staging/olpc_dcon/TODO | 7 + > > > drivers/staging/olpc_dcon/olpc_dcon.c | 6 +- > > > drivers/tty/vt/vt.c | 18 ++ > > > drivers/video/backlight/backlight.c | 2 +- > > > drivers/video/backlight/lcd.c | 12 - > > > drivers/video/console/dummycon.c| 6 + > > > drivers/video/fbdev/aty/aty128fb.c | 64 > > > drivers/video/fbdev/aty/atyfb_base.c| 3 +- > > > drivers/video/fbdev/core/fbcmap.c
Re: [linux-sunxi] [PATCH v2 5/9] drm/sun4i: tcon_top: Register clock gates in probe
On Tue, Jun 18, 2019 at 1:23 PM Chen-Yu Tsai wrote:
>
> On Tue, Jun 18, 2019 at 3:45 PM Jagan Teki wrote:
> >
> > On Tue, Jun 18, 2019 at 12:49 PM Chen-Yu Tsai wrote:
> > >
> > > On Mon, Jun 17, 2019 at 6:30 PM Jagan Teki
> > > wrote:
> > > >
> > > > On Sun, Jun 16, 2019 at 11:01 AM Chen-Yu Tsai wrote:
> > > > >
> > > > > On Sat, Jun 15, 2019 at 12:44 AM Jagan Teki
> > > > > wrote:
> > > > > >
> > > > > > TCON TOP have clock gates for TV0, TV1, dsi and right
> > > > > > now these are register during bind call.
> > > > > >
> > > > > > Of which, dsi clock gate would required during DPHY probe
> > > > > > but same can miss to get since tcon top is not bound at
> > > > > > that time.
> > > > > >
> > > > > > To solve, this circular dependency move the clock gate
> > > > > > registration from bind to probe so-that DPHY can get the
> > > > > > dsi gate clock on time.
> > > > > >
> > > > > > Signed-off-by: Jagan Teki
> > > > > > ---
> > > > > > drivers/gpu/drm/sun4i/sun8i_tcon_top.c | 94
> > > > > > ++
> > > > > > 1 file changed, 49 insertions(+), 45 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
> > > > > > b/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
> > > > > > index 465e9b0cdfee..a8978b3fe851 100644
> > > > > > --- a/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
> > > > > > +++ b/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
> > > > > > @@ -124,7 +124,53 @@ static struct clk_hw
> > > > > > *sun8i_tcon_top_register_gate(struct device *dev,
> > > > > > static int sun8i_tcon_top_bind(struct device *dev, struct device
> > > > > > *master,
> > > > > >void *data)
> > > > > > {
> > > > > > - struct platform_device *pdev = to_platform_device(dev);
> > > > > > + struct sun8i_tcon_top *tcon_top = dev_get_drvdata(dev);
> > > > > > + int ret;
> > > > > > +
> > > > > > + ret = reset_control_deassert(tcon_top->rst);
> > > > > > + if (ret) {
> > > > > > + dev_err(dev, "Could not deassert ctrl reset
> > > > > > control\n");
> > > > > > + return ret;
> > > > > > + }
> > > > > > +
> > > > > > + ret = clk_prepare_enable(tcon_top->bus);
> > > > > > + if (ret) {
> > > > > > + dev_err(dev, "Could not enable bus clock\n");
> > > > > > + goto err_assert_reset;
> > > > > > + }
> > > > >
> > > > > You have to de-assert the reset control and enable the clock before
> > > > > the
> > > > > clocks it provides are registered. Otherwise a consumer may come in
> > > > > and
> > > > > ask for the provided clock to be enabled, but since the TCON TOP's own
> > > > > reset and clock are still disabled, you can't actually access the
> > > > > registers
> > > > > that controls the provided clock.
> > > >
> > > > These rst and bus are common reset and bus clocks not tcon top clocks
> > > > that are trying to register here. ie reason I have not moved it in
> > > > top.
> > >
> > > And you're sure that toggling bits in the TCON TOP block doesn't require
> > > the reset to be de-asserted and the bus clock enabled?
> > >
> > > Somehow I doubt that.
> > >
> > > Once the driver register the clocks it provides, they absolutely must
> > > work.
> > > They can't only work after the bind phase when the reset gets de-asserted
> > > and the bus clock enabled. Or you should provide proper error reporting
> > > in the clock ops. I doubt you want to go that way either.
> >
> > Why would they won't work after bind phase? unlike tcon top gates,
> > these reset, and bus are common like what we have in other DE block
> > so enable them in bind won't be an issue as per as I understand. let
> > me know if you want me to check in other directions.
>
> You misunderstood. When you moved the clock registering parts to the probe
> phase, but didn't move the clock enable and reset de-assert parts to go with,
> the clock ops will not work as expected between probe and bind time.
If I understand correctly, I have moved tcon clock gates, not the bus
clock or the reset. Both have independent enablement phase, the bus
clock is enable in tcon top bind and the clock gate ("dsi") enable in
init call of phy_ops. is both bus clock and clock gates are same and
related that is what you are saying?
>
> Simple way to verify it: Just use devmem to disable the TCON TOP bus gate
> and/or assert its reset control. Then try to toggle any of the bits in the
> TCON TOP block and see if it works, or if the bits stick.
Yes I have verified "dsi" gate enablement before via devmem. Below is
the bus, reset disablement and re-enablement and result is similar for
the reset, bus clock in bind and even in probe.
00. get the existing value
# devmem 0x1c70020
0x0001
# devmem 0x1c20064
0x44021000
# devmem 0x1c202c4
0x44021000
01: disable bus, and assert reset
# devmem 0x1c20064 32 0x4021000
# devmem 0x1c202c4 32 0x4021000
# devmem 0x1c20064
0x04021000
# devmem 0x1c202c4
0x04021000
# devme
Re: [PATCH v3 07/10] drm: rcar-du: Provide for_each_group helper
Hi Laurent,
On 17/06/2019 22:09, Laurent Pinchart wrote:
> From: Kieran Bingham
>
> Refactoring of the group control code will soon require more iteration
> over the available groups. Simplify this process by introducing a group
> iteration helper.
>
> Signed-off-by: Kieran Bingham
> Signed-off-by: Laurent Pinchart
> ---
> Changes since v2:
>
> - Don't assign __group in the condition part of the for statement of the
> for_each_rcdu_group() macro
Nice!.
> ---
> drivers/gpu/drm/rcar-du/rcar_du_drv.h | 5 +
> drivers/gpu/drm/rcar-du/rcar_du_kms.c | 10 ++
> 2 files changed, 7 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> index 1327cd0df90a..0cc0984bf2ea 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> @@ -96,6 +96,11 @@ struct rcar_du_device {
> unsigned int vspd1_sink;
> };
>
> +#define for_each_rcdu_group(__rcdu, __group, __i) \
> + for ((__i) = 0, (__group) = &(__rcdu)->groups[0]; \
> + (__i) < DIV_ROUND_UP((__rcdu)->num_crtcs, 2); \
> + __i++, __group++)
Aha - studying the difference here, I do like this better.
--
KB.
> +
> static inline bool rcar_du_has(struct rcar_du_device *rcdu,
> unsigned int feature)
> {
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> index 144c0c1b1591..c04136674e58 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> @@ -627,9 +627,9 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu)
>
> struct drm_device *dev = rcdu->ddev;
> struct drm_encoder *encoder;
> + struct rcar_du_group *rgrp;
> unsigned int dpad0_sources;
> unsigned int num_encoders;
> - unsigned int num_groups;
> unsigned int swindex;
> unsigned int hwindex;
> unsigned int i;
> @@ -670,11 +670,7 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu)
> return ret;
>
> /* Initialize the groups. */
> - num_groups = DIV_ROUND_UP(rcdu->num_crtcs, 2);
> -
> - for (i = 0; i < num_groups; ++i) {
> - struct rcar_du_group *rgrp = &rcdu->groups[i];
> -
> + for_each_rcdu_group(rcdu, rgrp, i) {
> mutex_init(&rgrp->lock);
>
> rgrp->dev = rcdu;
> @@ -711,8 +707,6 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu)
>
> /* Create the CRTCs. */
> for (swindex = 0, hwindex = 0; swindex < rcdu->num_crtcs; ++hwindex) {
> - struct rcar_du_group *rgrp;
> -
> /* Skip unpopulated DU channels. */
> if (!(rcdu->info->channels_mask & BIT(hwindex)))
> continue;
>
--
Regards
--
Kieran
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 00/59] prime doc polish and ... a few cleanups
On 2019/06/17, Emil Velikov wrote: > Hi Daniel, > > On Fri, 14 Jun 2019 at 21:36, Daniel Vetter wrote: > > > > Hi all, > > > > So I figured let's get going and polish the docs for the last part of drm > > core/helpers that hasn't yet seen some neat polish last few years. With > > the goal to make docs for driver kapi a requirement henceforth - see last > > patch. Aside from that final doc patch I also included some todo.rst > > updates, bunch of things have progressed quite a bit. > > > > Of course spotted some lower-hanging fruit to untangle the prime helpers > > and interfaces, and decided to at least fix a few of those. > > > > Patch series survived some light testing on i915+vgem, but that's it. So > > review, testing, comments and anything else really highgly welcome. > > > > Cheers, Daniel > > > > Daniel Vetter (59): > I think this is the larges series from you so far. As already > mentioned - might be good idea to split this up a bit and merge it > into a few pieces? > Should make the churn much more manageable. > > > drm/prime: Unconditionally set up the prime file private > > drm/prime: Make DRIVER_PRIME a no-op > > drm/prime: Actually remove DRIVER_PRIME everywhere > Patch set#1 > Reviewed-by: Emil Velikov > > > drm/arm/komeda: Remove DRIVER_HAVE_IRQ > > drm/omapdrm: drop fb_debug_enter/leave > I'd keep these separate - each one is: > Reviewed-by: Emil Velikov > > > drm/arc: Drop drm_gem_prime_export/import > > drm/arm: Drop drm_gem_prime_export/import > > drm/atmel: Drop drm_gem_prime_export/import > > drm/etnaviv: Drop drm_gem_prime_export/import > > drm/exynos: Drop drm_gem_prime_export > > drm/fsl-dcu: Drop drm_gem_prime_export/import > > drm/hisilicon: Drop drm_gem_prime_export/import > > drm/imx: Drop drm_gem_prime_export/import > > drm/mcde: Drop drm_gem_prime_export/import > > drm/mtk: Drop drm_gem_prime_export/import > > drm/meson: Drop drm_gem_prime_export/import > > drm/msm: Drop drm_gem_prime_export/import > > drm/mxsfb: Drop drm_gem_prime_export/import > > drm/nouveau: Drop drm_gem_prime_export/import > > drm/pl111: Drop drm_gem_prime_export/import > > drm/qxl: Drop drm_gem_prime_export/import > > drm/rcar-du: Drop drm_gem_prime_export/import > > drm/rockchip: Drop drm_gem_prime_export/import > > drm/shmob: Drop drm_gem_prime_export/import > > drm/sti: Drop drm_gem_prime_export/import > > drm/stm: Drop drm_gem_prime_export/import > > drm/tilcdc: Drop drm_gem_prime_export/import > > drm/tve2000: Drop drm_gem_prime_export/import > > drm/vboxvideo: Drop drm_gem_prime_export/import > > drm/vc3: Drop drm_gem_prime_import > > drm/radeon: Drop drm_gem_prime_import > > drm/vgem: Drop drm_gem_prime_export > > drm/virtio: Drop drm_gem_prime_export/import > > drm/xen: Drop drm_gem_prime_export/import > > drm/zte: Drop drm_gem_prime_export/import > > drm/vram-helper: Drop drm_gem_prime_export/import > > The above are completely orthogonal of the preceding prime patches. For this > lot > Reviewed-by: Emil Velikov > > I'll get to the rest tomorrow. > > HTH > Emil > > > drm/todo: Improve drm_gem_object funcs todo > > drm/gem: Unexport drm_gem_(un)pin/v(un)map > Series X++: Reviewed-by: Emil Velikov > > drm/prime: Update docs > Will look/reply in v2 of the above. > > drm/prime: Align gem_prime_export with obj_funcs.export > Reviewed-by: Emil Velikov > > drm/prime: automatically set gem_obj->resv on import > > drm/etnaviv: Drop resv argument from etnaviv_gem_new_impl > > drm/lima: Drop resv argument from lima_bo_create_struct > > drm/mediatek: Use drm_atomic_helper_wait_for_fences > > drm/msm: Drop robj from msm_gem_new_impl > > drm/panfrost: don't set gem_obj->resv for prime import anymore > > drm/vc4: Don set gem_obj->resv in prime import anymore > > drm/vgem: Ditch attach trickery in the fence ioctl Series X++: Reviewed-by: Emil Velikov > > drm/msm: Use drm_gem_fb_prepare_fb > > drm/vc4: Use drm_gem_fb_prepare_fb Series X++? My atomic foo isn't that great so I cannot provide any meaningful review > > drm/radeon: Fill out gem_object->resv > > drm/nouveau: Fill out gem_object->resv > > drm/amdgpu: Fill out gem_object->resv > > drm/prime: Ditch gem_prime_res_obj hook Series X++. For the lot: Reviewed-by: Emil Velikov > > drm/todo: remove gem_prime_import/export todo > > drm/todo: Update backlight todo > > drm/todo: Update mmap todo > > drm/todo: Add new debugfs todo > > drm/doc: Document kapi doc expectations > > For the documentation updates Acked-by: Emil Velikov Thanks Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v10 01/11] drm/sun4i: dsi: Fix TCON DRQ set bits
On Fri, Jun 14, 2019 at 8:15 PM Maxime Ripard wrote: > > On Fri, Jun 14, 2019 at 12:03:13PM +0530, Jagan Teki wrote: > > On Thu, Jun 13, 2019 at 6:56 PM Maxime Ripard > > wrote: > > > > > > On Wed, Jun 05, 2019 at 01:17:11PM +0530, Jagan Teki wrote: > > > > On Tue, Jun 4, 2019 at 3:30 PM Maxime Ripard > > > > wrote: > > > > > > > > > > On Wed, May 29, 2019 at 11:44:56PM +0530, Jagan Teki wrote: > > > > > > On Wed, May 29, 2019 at 8:24 PM Maxime Ripard > > > > > > wrote: > > > > > > > > > > > > > > On Fri, May 24, 2019 at 03:48:51PM +0530, Jagan Teki wrote: > > > > > > > > On Fri, May 24, 2019 at 2:04 AM Maxime Ripard > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > On Mon, May 20, 2019 at 02:33:08PM +0530, Jagan Teki wrote: > > > > > > > > > > According to "DRM kernel-internal display mode structure" in > > > > > > > > > > include/drm/drm_modes.h the current driver is trying to > > > > > > > > > > include > > > > > > > > > > sync timings along with front porch value while checking and > > > > > > > > > > computing drq set bits in non-burst mode. > > > > > > > > > > > > > > > > > > > > mode->hsync_end - mode->hdisplay => horizontal front porch > > > > > > > > > > + sync > > > > > > > > > > > > > > > > > > > > With adding additional sync timings, the dsi controller > > > > > > > > > > leads to > > > > > > > > > > wrong drq set bits for "bananapi,s070wv20-ct16" panel which > > > > > > > > > > indeed > > > > > > > > > > trigger panel flip_done timed out as: > > > > > > > > > > > > > > > > > > > > WARNING: CPU: 0 PID: 31 at > > > > > > > > > > drivers/gpu/drm/drm_atomic_helper.c:1429 > > > > > > > > > > drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0 > > > > > > > > > > [CRTC:46:crtc-0] vblank wait timed out > > > > > > > > > > Modules linked in: > > > > > > > > > > CPU: 0 PID: 31 Comm: kworker/0:1 Not tainted > > > > > > > > > > 5.1.0-next-20190514-00026-g01f0c75b902d-dirty #13 > > > > > > > > > > Hardware name: Allwinner sun8i Family > > > > > > > > > > Workqueue: events deferred_probe_work_func > > > > > > > > > > [] (unwind_backtrace) from [] > > > > > > > > > > (show_stack+0x10/0x14) > > > > > > > > > > [] (show_stack) from [] > > > > > > > > > > (dump_stack+0x84/0x98) > > > > > > > > > > [] (dump_stack) from [] > > > > > > > > > > (__warn+0xfc/0x114) > > > > > > > > > > [] (__warn) from [] > > > > > > > > > > (warn_slowpath_fmt+0x44/0x68) > > > > > > > > > > [] (warn_slowpath_fmt) from [] > > > > > > > > > > (drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0) > > > > > > > > > > [] (drm_atomic_helper_wait_for_vblanks.part.1) > > > > > > > > > > from [] > > > > > > > > > > (drm_atomic_helper_commit_tail_rpm+0x5c/0x6c) > > > > > > > > > > [] (drm_atomic_helper_commit_tail_rpm) from > > > > > > > > > > [] (commit_tail+0x40/0x6c) > > > > > > > > > > [] (commit_tail) from [] > > > > > > > > > > (drm_atomic_helper_commit+0xbc/0x128) > > > > > > > > > > [] (drm_atomic_helper_commit) from [] > > > > > > > > > > (restore_fbdev_mode_atomic+0x1cc/0x1dc) > > > > > > > > > > [] (restore_fbdev_mode_atomic) from [] > > > > > > > > > > (drm_fb_helper_restore_fbdev_mode_unlocked+0x54/0xa0) > > > > > > > > > > [] (drm_fb_helper_restore_fbdev_mode_unlocked) > > > > > > > > > > from [] (drm_fb_helper_set_par+0x30/0x54) > > > > > > > > > > [] (drm_fb_helper_set_par) from [] > > > > > > > > > > (fbcon_init+0x560/0x5ac) > > > > > > > > > > [] (fbcon_init) from [] > > > > > > > > > > (visual_init+0xbc/0x104) > > > > > > > > > > [] (visual_init) from [] > > > > > > > > > > (do_bind_con_driver+0x1b0/0x390) > > > > > > > > > > [] (do_bind_con_driver) from [] > > > > > > > > > > (do_take_over_console+0x13c/0x1c4) > > > > > > > > > > [] (do_take_over_console) from [] > > > > > > > > > > (do_fbcon_takeover+0x74/0xcc) > > > > > > > > > > [] (do_fbcon_takeover) from [] > > > > > > > > > > (notifier_call_chain+0x44/0x84) > > > > > > > > > > [] (notifier_call_chain) from [] > > > > > > > > > > (__blocking_notifier_call_chain+0x48/0x60) > > > > > > > > > > [] (__blocking_notifier_call_chain) from > > > > > > > > > > [] (blocking_notifier_call_chain+0x18/0x20) > > > > > > > > > > [] (blocking_notifier_call_chain) from > > > > > > > > > > [] (register_framebuffer+0x1e0/0x2f8) > > > > > > > > > > [] (register_framebuffer) from [] > > > > > > > > > > (__drm_fb_helper_initial_config_and_unlock+0x2fc/0x50c) > > > > > > > > > > [] (__drm_fb_helper_initial_config_and_unlock) > > > > > > > > > > from [] (drm_fbdev_client_hotplug+0xe8/0x1b8) > > > > > > > > > > [] (drm_fbdev_client_hotplug) from [] > > > > > > > > > > (drm_fbdev_generic_setup+0x88/0x118) > > > > > > > > > > [] (drm_fbdev_generic_setup) from [] > > > > > > > > > > (sun4i_drv_bind+0x128/0x160) > > > > > > > > > > [] (sun4i_drv_bind) from [] > > > > > > > > > > (try_to_bring_up_master+0x164/0x1a0) > > > > > > > > > > [] (try_to_bring_up_master) from [] > > > > > > > > > > (__component_add+0x9
Re: [linux-sunxi] [PATCH v2 5/9] drm/sun4i: tcon_top: Register clock gates in probe
On Tue, Jun 18, 2019 at 6:34 PM Jagan Teki wrote:
>
> On Tue, Jun 18, 2019 at 1:23 PM Chen-Yu Tsai wrote:
> >
> > On Tue, Jun 18, 2019 at 3:45 PM Jagan Teki
> > wrote:
> > >
> > > On Tue, Jun 18, 2019 at 12:49 PM Chen-Yu Tsai wrote:
> > > >
> > > > On Mon, Jun 17, 2019 at 6:30 PM Jagan Teki
> > > > wrote:
> > > > >
> > > > > On Sun, Jun 16, 2019 at 11:01 AM Chen-Yu Tsai wrote:
> > > > > >
> > > > > > On Sat, Jun 15, 2019 at 12:44 AM Jagan Teki
> > > > > > wrote:
> > > > > > >
> > > > > > > TCON TOP have clock gates for TV0, TV1, dsi and right
> > > > > > > now these are register during bind call.
> > > > > > >
> > > > > > > Of which, dsi clock gate would required during DPHY probe
> > > > > > > but same can miss to get since tcon top is not bound at
> > > > > > > that time.
> > > > > > >
> > > > > > > To solve, this circular dependency move the clock gate
> > > > > > > registration from bind to probe so-that DPHY can get the
> > > > > > > dsi gate clock on time.
> > > > > > >
> > > > > > > Signed-off-by: Jagan Teki
> > > > > > > ---
> > > > > > > drivers/gpu/drm/sun4i/sun8i_tcon_top.c | 94
> > > > > > > ++
> > > > > > > 1 file changed, 49 insertions(+), 45 deletions(-)
> > > > > > >
> > > > > > > diff --git a/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
> > > > > > > b/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
> > > > > > > index 465e9b0cdfee..a8978b3fe851 100644
> > > > > > > --- a/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
> > > > > > > +++ b/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
> > > > > > > @@ -124,7 +124,53 @@ static struct clk_hw
> > > > > > > *sun8i_tcon_top_register_gate(struct device *dev,
> > > > > > > static int sun8i_tcon_top_bind(struct device *dev, struct device
> > > > > > > *master,
> > > > > > >void *data)
> > > > > > > {
> > > > > > > - struct platform_device *pdev = to_platform_device(dev);
> > > > > > > + struct sun8i_tcon_top *tcon_top = dev_get_drvdata(dev);
> > > > > > > + int ret;
> > > > > > > +
> > > > > > > + ret = reset_control_deassert(tcon_top->rst);
> > > > > > > + if (ret) {
> > > > > > > + dev_err(dev, "Could not deassert ctrl reset
> > > > > > > control\n");
> > > > > > > + return ret;
> > > > > > > + }
> > > > > > > +
> > > > > > > + ret = clk_prepare_enable(tcon_top->bus);
> > > > > > > + if (ret) {
> > > > > > > + dev_err(dev, "Could not enable bus clock\n");
> > > > > > > + goto err_assert_reset;
> > > > > > > + }
> > > > > >
> > > > > > You have to de-assert the reset control and enable the clock before
> > > > > > the
> > > > > > clocks it provides are registered. Otherwise a consumer may come in
> > > > > > and
> > > > > > ask for the provided clock to be enabled, but since the TCON TOP's
> > > > > > own
> > > > > > reset and clock are still disabled, you can't actually access the
> > > > > > registers
> > > > > > that controls the provided clock.
> > > > >
> > > > > These rst and bus are common reset and bus clocks not tcon top clocks
> > > > > that are trying to register here. ie reason I have not moved it in
> > > > > top.
> > > >
> > > > And you're sure that toggling bits in the TCON TOP block doesn't require
> > > > the reset to be de-asserted and the bus clock enabled?
> > > >
> > > > Somehow I doubt that.
> > > >
> > > > Once the driver register the clocks it provides, they absolutely must
> > > > work.
> > > > They can't only work after the bind phase when the reset gets
> > > > de-asserted
> > > > and the bus clock enabled. Or you should provide proper error reporting
> > > > in the clock ops. I doubt you want to go that way either.
> > >
> > > Why would they won't work after bind phase? unlike tcon top gates,
> > > these reset, and bus are common like what we have in other DE block
> > > so enable them in bind won't be an issue as per as I understand. let
> > > me know if you want me to check in other directions.
> >
> > You misunderstood. When you moved the clock registering parts to the probe
> > phase, but didn't move the clock enable and reset de-assert parts to go
> > with,
> > the clock ops will not work as expected between probe and bind time.
>
> If I understand correctly, I have moved tcon clock gates, not the bus
> clock or the reset. Both have independent enablement phase, the bus
> clock is enable in tcon top bind and the clock gate ("dsi") enable in
> init call of phy_ops. is both bus clock and clock gates are same and
> related that is what you are saying?
I am saying that you may need the tcon top bus gates and resets properly
configured to be able to read/write the tcon top address range. That includes
enabling/disabling the clocks that the tcon top driver registers.
In other words, the TCON TOP's bus gate and reset control have everything to do
with what you can do within the TCON TOP block or address range.
> >
> > Simple way to verify it: Just use devmem
Re: [PATCH 1/4] drm/vmwgfx: Assign eviction priorities to resources
Hi Thomas, On 2019/06/18, Thomas Hellström (VMware) wrote: > From: Thomas Hellstrom > > TTM provides a means to assign eviction priorities to buffer object. This > means that all buffer objects with a lower priority will be evicted first > on memory pressure. > Use this to make sure surfaces and in particular non-dirty surfaces are > evicted first. Evicting in particular shaders, cotables and contexts imply > a significant performance hit on vmwgfx, so make sure these resources are > evicted last. > Some buffer objects are sub-allocated in user-space which means we can have > many resources attached to a single buffer object or resource. In that case > the buffer object is given the highest priority of the attached resources. > > Signed-off-by: Thomas Hellstrom > Reviewed-by: Deepak Rawat Fwiw patches 1-3 are: Reviewed-by: Emil Velikov Patch 4 is: Acked-by: Emil Velikov Huge thanks for sorting this out. Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v10 02/11] drm/sun4i: dsi: Update start value in video start delay
On Fri, Jun 14, 2019 at 7:58 PM Maxime Ripard wrote: > > On Thu, Jun 13, 2019 at 01:34:04PM +0530, Jagan Teki wrote: > > On Fri, May 31, 2019 at 12:23 AM Maxime Ripard > > wrote: > > > > > > On Fri, May 24, 2019 at 03:55:42PM +0530, Jagan Teki wrote: > > > > On Fri, May 24, 2019 at 2:07 AM Maxime Ripard > > > > wrote: > > > > > > > > > > On Mon, May 20, 2019 at 02:33:09PM +0530, Jagan Teki wrote: > > > > > > start value in video start delay computation done in below commit > > > > > > is as per the legacy bsp drivers/video/sunxi/legacy.. > > > > > > "drm/sun4i: dsi: Change the start delay calculation" > > > > > > (sha1: da676c6aa6413d59ab0a80c97bbc273025e640b2) > > > > > > > > > > > > This existing start delay computation gives start value of 35, > > > > > > for "bananapi,s070wv20-ct16" panel timings which indeed trigger > > > > > > panel flip_done timed out as: > > > > > > > > > > > > WARNING: CPU: 0 PID: 31 at > > > > > > drivers/gpu/drm/drm_atomic_helper.c:1429 > > > > > > drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0 > > > > > > [CRTC:46:crtc-0] vblank wait timed out > > > > > > Modules linked in: > > > > > > CPU: 0 PID: 31 Comm: kworker/0:1 Tainted: GW > > > > > > 5.1.0-next-20190514-00025-gf928bc7cc146 #15 > > > > > > Hardware name: Allwinner sun8i Family > > > > > > Workqueue: events deferred_probe_work_func > > > > > > [] (unwind_backtrace) from [] > > > > > > (show_stack+0x10/0x14) > > > > > > [] (show_stack) from [] (dump_stack+0x84/0x98) > > > > > > [] (dump_stack) from [] (__warn+0xfc/0x114) > > > > > > [] (__warn) from [] > > > > > > (warn_slowpath_fmt+0x44/0x68) > > > > > > [] (warn_slowpath_fmt) from [] > > > > > > (drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0) > > > > > > [] (drm_atomic_helper_wait_for_vblanks.part.1) from > > > > > > [] (drm_atomic_helper_commit_tail_rpm+0x5c/0x6c) > > > > > > [] (drm_atomic_helper_commit_tail_rpm) from [] > > > > > > (commit_tail+0x40/0x6c) > > > > > > [] (commit_tail) from [] > > > > > > (drm_atomic_helper_commit+0xbc/0x128) > > > > > > [] (drm_atomic_helper_commit) from [] > > > > > > (restore_fbdev_mode_atomic+0x1cc/0x1dc) > > > > > > [] (restore_fbdev_mode_atomic) from [] > > > > > > (drm_fb_helper_pan_display+0xac/0x1d0) > > > > > > [] (drm_fb_helper_pan_display) from [] > > > > > > (fb_pan_display+0xcc/0x134) > > > > > > [] (fb_pan_display) from [] > > > > > > (bit_update_start+0x14/0x30) > > > > > > [] (bit_update_start) from [] > > > > > > (fbcon_switch+0x3d8/0x4e0) > > > > > > [] (fbcon_switch) from [] > > > > > > (redraw_screen+0x174/0x238) > > > > > > [] (redraw_screen) from [] > > > > > > (fbcon_prepare_logo+0x3c4/0x400) > > > > > > [] (fbcon_prepare_logo) from [] > > > > > > (fbcon_init+0x3c8/0x5ac) > > > > > > [] (fbcon_init) from [] > > > > > > (visual_init+0xbc/0x104) > > > > > > [] (visual_init) from [] > > > > > > (do_bind_con_driver+0x1b0/0x390) > > > > > > [] (do_bind_con_driver) from [] > > > > > > (do_take_over_console+0x13c/0x1c4) > > > > > > [] (do_take_over_console) from [] > > > > > > (do_fbcon_takeover+0x74/0xcc) > > > > > > [] (do_fbcon_takeover) from [] > > > > > > (notifier_call_chain+0x44/0x84) > > > > > > [] (notifier_call_chain) from [] > > > > > > (__blocking_notifier_call_chain+0x48/0x60) > > > > > > [] (__blocking_notifier_call_chain) from [] > > > > > > (blocking_notifier_call_chain+0x18/0x20) > > > > > > [] (blocking_notifier_call_chain) from [] > > > > > > (register_framebuffer+0x1e0/0x2f8) > > > > > > [] (register_framebuffer) from [] > > > > > > (__drm_fb_helper_initial_config_and_unlock+0x2fc/0x50c) > > > > > > [] (__drm_fb_helper_initial_config_and_unlock) from > > > > > > [] (drm_fbdev_client_hotplug+0xe8/0x1b8) > > > > > > [] (drm_fbdev_client_hotplug) from [] > > > > > > (drm_fbdev_generic_setup+0x88/0x118) > > > > > > [] (drm_fbdev_generic_setup) from [] > > > > > > (sun4i_drv_bind+0x128/0x160) > > > > > > [] (sun4i_drv_bind) from [] > > > > > > (try_to_bring_up_master+0x164/0x1a0) > > > > > > [] (try_to_bring_up_master) from [] > > > > > > (__component_add+0x94/0x140) > > > > > > [] (__component_add) from [] > > > > > > (sun6i_dsi_probe+0x144/0x234) > > > > > > [] (sun6i_dsi_probe) from [] > > > > > > (platform_drv_probe+0x48/0x9c) > > > > > > [] (platform_drv_probe) from [] > > > > > > (really_probe+0x1dc/0x2c8) > > > > > > [] (really_probe) from [] > > > > > > (driver_probe_device+0x60/0x160) > > > > > > [] (driver_probe_device) from [] > > > > > > (bus_for_each_drv+0x74/0xb8) > > > > > > [] (bus_for_each_drv) from [] > > > > > > (__device_attach+0xd0/0x13c) > > > > > > [] (__device_attach) from [] > > > > > > (bus_probe_device+0x84/0x8c) > > > > > > [] (bus_probe_device) from [] > > > > > > (deferred_probe_work_func+0x64/0x90) > > > > > > [] (deferred_probe_work_func) from [] > > > > > > (process_one_work+0x204/0x420) > > > > > > [] (process_one_work) from [] > > > > > > (worker_thre
[Bug 110831] [AMD TAHITI XT][amd-staging-drm-next][bisected] broken since 5.2-rc1 rebase
https://bugs.freedesktop.org/show_bug.cgi?id=110831 --- Comment #5 from Sylvain BERTRAND --- Did update the amd-staging-drm-next branch earlier today. The hanging boot is gone. Did a quick check: your patch was already applied. So it probably did fix 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
Re: [PATCH V2 4/5] drm/vkms: Use index instead of 0 in possible crtc
On Tue, Jun 18, 2019 at 07:56:23AM +, Simon Ser wrote: > Interestingly, even with the previous code, possible_crtcs=1 was > exposed to userspace [1]. I think this is because of a safeguard in > drm_crtc_init_with_planes (drm_crtc.c:284) which sets the primary and > cursor plane's possible_crtcs to the first CRTC if zero. > > If we want to warn on possible_crtcs=0, we should probably remove this > safeguard. Checking first whether this safeguard is used by any driver > is probably a good idea. > > [1]: https://drmdb.emersion.fr/devices/f218d1242714 Yeaht it's a bit a mess, that's why I've suggested we should bite this bullet and fix it for real. There's a bunch others such bitmasks that many drivers seem to not set correctly. -Daniel -- 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: [PULL] topic/remove-fbcon-notifiers for v5.3
Hi, On 6/18/19 11:20 AM, Maarten Lankhorst wrote: > Op 14-06-2019 om 11:25 schreef Maarten Lankhorst: >> Hi all, >> >> As discussed with Daniel V, I'm just doing the paperwork here as drm-misc >> maintainer. >> >> This is the topic pull request for the fbdev notifier removal. >> >> Bar, please make a final check and pull into your fbdev tree. >> >> Lee, please make a final check and pull into your backlight tree. >> >> Greg, this is just fyi, you already acked all the vt and staging patches in >> here >> to land through other trees. >> >> I'll pull this into drm-misc-next once Bart & Lee acked it. >> >> Cheers, Maarten. > > Bart, Lee, ping? Looks OK to me (I have test pulled it locally and there is only trivial merge conflict on removed mxsfb fbdev driver) but it seems that all patches miss your "S-o-B:" line (there is only "Reviewed-by:" tag which is OK but has a different meaning)? Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics > >> topic/remove-fbcon-notifiers-2019-06-14-1: >> >> topic/remove-fbcon-notifiers: >> - remove fbdev notifier usage for fbcon, as prep work to clean up the fbcon >> locking >> - assorted locking checks in vt/console code >> - assorted notifier and cleanups in fbdev and backlight code >> >> The following changes since commit d1fdb6d8f6a4109a4263176c84b899076a5f8008: >> >> Linux 5.2-rc4 (2019-06-08 20:24:46 -0700) >> >> are available in the Git repository at: >> >> git://anongit.freedesktop.org/drm/drm-misc >> tags/topic/remove-fbcon-notifiers-2019-06-14-1 >> >> for you to fetch changes up to 1dcff4ae65185e8c0300972f6d8d39d9a9db2bda: >> >> backlight: simplify lcd notifier (2019-06-13 10:07:20 +0200) >> >> >> Daniel Vetter (33): >> dummycon: Sprinkle locking checks >> fbdev: locking check for fb_set_suspend >> vt: might_sleep() annotation for do_blank_screen >> vt: More locking checks >> fbdev/sa1100fb: Remove dead code >> fbdev/cyber2000: Remove struct display >> fbdev/aty128fb: Remove dead code >> fbcon: s/struct display/struct fbcon_display/ >> fbcon: Remove fbcon_has_exited >> fbcon: call fbcon_fb_(un)registered directly >> fbdev/sh_mobile: remove sh_mobile_lcdc_display_notify >> fbdev/omap: sysfs files can't disappear before the device is gone >> fbdev: sysfs files can't disappear before the device is gone >> staging/olpc: lock_fb_info can't fail >> fbdev/atyfb: lock_fb_info can't fail >> fbdev: lock_fb_info cannot fail >> fbcon: call fbcon_fb_bind directly >> fbdev: make unregister/unlink functions not fail >> fbdev: unify unlink_framebuffer paths >> fbdev/sh_mob: Remove fb notifier callback >> fbdev: directly call fbcon_suspended/resumed >> fbcon: Call fbcon_mode_deleted/new_modelist directly >> fbdev: Call fbcon_get_requirement directly >> Revert "backlight/fbcon: Add FB_EVENT_CONBLANK" >> fbmem: pull fbcon_fb_blanked out of fb_blank >> fbdev: remove FBINFO_MISC_USEREVENT around fb_blank >> fb: Flatten control flow in fb_set_var >> fbcon: replace FB_EVENT_MODE_CHANGE/_ALL with direct calls >> vgaswitcheroo: call fbcon_remap_all directly >> fbcon: Call con2fb_map functions directly >> fbcon: Document what I learned about fbcon locking >> staging/olpc_dcon: Add drm conversion to TODO >> backlight: simplify lcd notifier >> >> arch/arm/mach-pxa/am200epd.c| 13 +- >> drivers/gpu/vga/vga_switcheroo.c| 11 +- >> drivers/media/pci/ivtv/ivtvfb.c | 6 +- >> drivers/staging/fbtft/fbtft-core.c | 4 +- >> drivers/staging/olpc_dcon/TODO | 7 + >> drivers/staging/olpc_dcon/olpc_dcon.c | 6 +- >> drivers/tty/vt/vt.c | 18 ++ >> drivers/video/backlight/backlight.c | 2 +- >> drivers/video/backlight/lcd.c | 12 - >> drivers/video/console/dummycon.c| 6 + >> drivers/video/fbdev/aty/aty128fb.c | 64 >> drivers/video/fbdev/aty/atyfb_base.c| 3 +- >> drivers/video/fbdev/core/fbcmap.c | 6 +- >> drivers/video/fbdev/core/fbcon.c| 313 --- >> drivers/video/fbdev/core/fbcon.h| 6 +- >> drivers/video/fbdev/core/fbmem.c| 399 >> +--- >> drivers/video/fbdev/core/fbsysfs.c | 20 +- >> drivers/video/fbdev/cyber2000fb.c | 1 - >> drivers/video/fbdev/neofb.c | 9 +- >> drivers/video/fbdev/omap2/omapfb/omapfb-sysfs.c | 21 +- >> drivers/video/fbdev/sa1100fb.c | 25 -- >> drivers/video/fbdev/savage/savagefb_driver.c| 9 +- >> drivers/vide
Re: [PULL] topic/remove-fbcon-notifiers for v5.3
On Tue, 18 Jun 2019, Daniel Vetter wrote: > On Tue, Jun 18, 2019 at 11:03:47AM +0100, Lee Jones wrote: > > On Tue, 18 Jun 2019, Maarten Lankhorst wrote: > > > > > Op 14-06-2019 om 11:25 schreef Maarten Lankhorst: > > > > Hi all, > > > > > > > > As discussed with Daniel V, I'm just doing the paperwork here as > > > > drm-misc maintainer. > > > > > > > > This is the topic pull request for the fbdev notifier removal. > > > > > > > > Bar, please make a final check and pull into your fbdev tree. > > > > > > > > Lee, please make a final check and pull into your backlight tree. > > > > > > > > Greg, this is just fyi, you already acked all the vt and staging > > > > patches in here > > > > to land through other trees. > > > > > > > > I'll pull this into drm-misc-next once Bart & Lee acked it. > > > > > > > > Cheers, Maarten. > > > > > > Bart, Lee, ping? > > > > Asking for an Ack on a PR is kind of odd. If you have all of the > > patch Acks you need, and you've made the PR has small as possible, > > then you should be good to go. > > Ime there's lots of ways to screw up a pull request, so asking for a "yup > looks good to me" seems reasonable. I've done that with all the topic > pulls in the past. Instead of burdening others, it's probably best to take 'no news is good news' stance. In all of the immutable branch PRs I've sent out, other than the occasional 'pulled thanks', no one has ever reviewed/ acked them before. > > My plan is to see if any of this collides with my PR to Linus. If it > > doesn't then I may not have to pull it in at all. > > For simple conflicts Linus usually prefers to resolve them himself. The > topic pull is needed if there's more stuff on top, like patches that need > to be rebased ... There are multiple uses for immutable branches. I'll pull this one if the need arises. > > > > topic/remove-fbcon-notifiers-2019-06-14-1: > > > > > > > > topic/remove-fbcon-notifiers: > > > > - remove fbdev notifier usage for fbcon, as prep work to clean up the > > > > fbcon locking > > > > - assorted locking checks in vt/console code > > > > - assorted notifier and cleanups in fbdev and backlight code > > > > > > > > The following changes since commit > > > > d1fdb6d8f6a4109a4263176c84b899076a5f8008: > > > > > > > > Linux 5.2-rc4 (2019-06-08 20:24:46 -0700) > > > > > > > > are available in the Git repository at: > > > > > > > > git://anongit.freedesktop.org/drm/drm-misc > > > > tags/topic/remove-fbcon-notifiers-2019-06-14-1 > > > > > > > > for you to fetch changes up to 1dcff4ae65185e8c0300972f6d8d39d9a9db2bda: > > > > > > > > backlight: simplify lcd notifier (2019-06-13 10:07:20 +0200) > > > > > > > > > > > > Daniel Vetter (33): > > > > dummycon: Sprinkle locking checks > > > > fbdev: locking check for fb_set_suspend > > > > vt: might_sleep() annotation for do_blank_screen > > > > vt: More locking checks > > > > fbdev/sa1100fb: Remove dead code > > > > fbdev/cyber2000: Remove struct display > > > > fbdev/aty128fb: Remove dead code > > > > fbcon: s/struct display/struct fbcon_display/ > > > > fbcon: Remove fbcon_has_exited > > > > fbcon: call fbcon_fb_(un)registered directly > > > > fbdev/sh_mobile: remove sh_mobile_lcdc_display_notify > > > > fbdev/omap: sysfs files can't disappear before the device is gone > > > > fbdev: sysfs files can't disappear before the device is gone > > > > staging/olpc: lock_fb_info can't fail > > > > fbdev/atyfb: lock_fb_info can't fail > > > > fbdev: lock_fb_info cannot fail > > > > fbcon: call fbcon_fb_bind directly > > > > fbdev: make unregister/unlink functions not fail > > > > fbdev: unify unlink_framebuffer paths > > > > fbdev/sh_mob: Remove fb notifier callback > > > > fbdev: directly call fbcon_suspended/resumed > > > > fbcon: Call fbcon_mode_deleted/new_modelist directly > > > > fbdev: Call fbcon_get_requirement directly > > > > Revert "backlight/fbcon: Add FB_EVENT_CONBLANK" > > > > fbmem: pull fbcon_fb_blanked out of fb_blank > > > > fbdev: remove FBINFO_MISC_USEREVENT around fb_blank > > > > fb: Flatten control flow in fb_set_var > > > > fbcon: replace FB_EVENT_MODE_CHANGE/_ALL with direct calls > > > > vgaswitcheroo: call fbcon_remap_all directly > > > > fbcon: Call con2fb_map functions directly > > > > fbcon: Document what I learned about fbcon locking > > > > staging/olpc_dcon: Add drm conversion to TODO > > > > backlight: simplify lcd notifier > > > > > > > > arch/arm/mach-pxa/am200epd.c| 13 +- > > > > drivers/gpu/vga/vga_switcheroo.c| 11 +- > > > > drivers/media/pci/ivtv/ivtvfb.c | 6 +- > > > > drivers/staging/fbtft/fbtft-core.c | 4 +- > > >
Re: [linux-sunxi] Re: [PATCH v10 01/11] drm/sun4i: dsi: Fix TCON DRQ set bits
On Tue, Jun 18, 2019 at 6:51 PM Jagan Teki wrote: > > On Fri, Jun 14, 2019 at 8:15 PM Maxime Ripard > wrote: > > > > On Fri, Jun 14, 2019 at 12:03:13PM +0530, Jagan Teki wrote: > > > On Thu, Jun 13, 2019 at 6:56 PM Maxime Ripard > > > wrote: > > > > > > > > On Wed, Jun 05, 2019 at 01:17:11PM +0530, Jagan Teki wrote: > > > > > On Tue, Jun 4, 2019 at 3:30 PM Maxime Ripard > > > > > wrote: > > > > > > > > > > > > On Wed, May 29, 2019 at 11:44:56PM +0530, Jagan Teki wrote: > > > > > > > On Wed, May 29, 2019 at 8:24 PM Maxime Ripard > > > > > > > wrote: > > > > > > > > > > > > > > > > On Fri, May 24, 2019 at 03:48:51PM +0530, Jagan Teki wrote: > > > > > > > > > On Fri, May 24, 2019 at 2:04 AM Maxime Ripard > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > On Mon, May 20, 2019 at 02:33:08PM +0530, Jagan Teki wrote: > > > > > > > > > > > According to "DRM kernel-internal display mode structure" > > > > > > > > > > > in > > > > > > > > > > > include/drm/drm_modes.h the current driver is trying to > > > > > > > > > > > include > > > > > > > > > > > sync timings along with front porch value while checking > > > > > > > > > > > and > > > > > > > > > > > computing drq set bits in non-burst mode. > > > > > > > > > > > > > > > > > > > > > > mode->hsync_end - mode->hdisplay => horizontal front > > > > > > > > > > > porch + sync > > > > > > > > > > > > > > > > > > > > > > With adding additional sync timings, the dsi controller > > > > > > > > > > > leads to > > > > > > > > > > > wrong drq set bits for "bananapi,s070wv20-ct16" panel > > > > > > > > > > > which indeed > > > > > > > > > > > trigger panel flip_done timed out as: > > > > > > > > > > > > > > > > > > > > > > WARNING: CPU: 0 PID: 31 at > > > > > > > > > > > drivers/gpu/drm/drm_atomic_helper.c:1429 > > > > > > > > > > > drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0 > > > > > > > > > > > [CRTC:46:crtc-0] vblank wait timed out > > > > > > > > > > > Modules linked in: > > > > > > > > > > > CPU: 0 PID: 31 Comm: kworker/0:1 Not tainted > > > > > > > > > > > 5.1.0-next-20190514-00026-g01f0c75b902d-dirty #13 > > > > > > > > > > > Hardware name: Allwinner sun8i Family > > > > > > > > > > > Workqueue: events deferred_probe_work_func > > > > > > > > > > > [] (unwind_backtrace) from [] > > > > > > > > > > > (show_stack+0x10/0x14) > > > > > > > > > > > [] (show_stack) from [] > > > > > > > > > > > (dump_stack+0x84/0x98) > > > > > > > > > > > [] (dump_stack) from [] > > > > > > > > > > > (__warn+0xfc/0x114) > > > > > > > > > > > [] (__warn) from [] > > > > > > > > > > > (warn_slowpath_fmt+0x44/0x68) > > > > > > > > > > > [] (warn_slowpath_fmt) from [] > > > > > > > > > > > (drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0) > > > > > > > > > > > [] (drm_atomic_helper_wait_for_vblanks.part.1) > > > > > > > > > > > from [] > > > > > > > > > > > (drm_atomic_helper_commit_tail_rpm+0x5c/0x6c) > > > > > > > > > > > [] (drm_atomic_helper_commit_tail_rpm) from > > > > > > > > > > > [] (commit_tail+0x40/0x6c) > > > > > > > > > > > [] (commit_tail) from [] > > > > > > > > > > > (drm_atomic_helper_commit+0xbc/0x128) > > > > > > > > > > > [] (drm_atomic_helper_commit) from > > > > > > > > > > > [] (restore_fbdev_mode_atomic+0x1cc/0x1dc) > > > > > > > > > > > [] (restore_fbdev_mode_atomic) from > > > > > > > > > > > [] > > > > > > > > > > > (drm_fb_helper_restore_fbdev_mode_unlocked+0x54/0xa0) > > > > > > > > > > > [] (drm_fb_helper_restore_fbdev_mode_unlocked) > > > > > > > > > > > from [] (drm_fb_helper_set_par+0x30/0x54) > > > > > > > > > > > [] (drm_fb_helper_set_par) from [] > > > > > > > > > > > (fbcon_init+0x560/0x5ac) > > > > > > > > > > > [] (fbcon_init) from [] > > > > > > > > > > > (visual_init+0xbc/0x104) > > > > > > > > > > > [] (visual_init) from [] > > > > > > > > > > > (do_bind_con_driver+0x1b0/0x390) > > > > > > > > > > > [] (do_bind_con_driver) from [] > > > > > > > > > > > (do_take_over_console+0x13c/0x1c4) > > > > > > > > > > > [] (do_take_over_console) from [] > > > > > > > > > > > (do_fbcon_takeover+0x74/0xcc) > > > > > > > > > > > [] (do_fbcon_takeover) from [] > > > > > > > > > > > (notifier_call_chain+0x44/0x84) > > > > > > > > > > > [] (notifier_call_chain) from [] > > > > > > > > > > > (__blocking_notifier_call_chain+0x48/0x60) > > > > > > > > > > > [] (__blocking_notifier_call_chain) from > > > > > > > > > > > [] (blocking_notifier_call_chain+0x18/0x20) > > > > > > > > > > > [] (blocking_notifier_call_chain) from > > > > > > > > > > > [] (register_framebuffer+0x1e0/0x2f8) > > > > > > > > > > > [] (register_framebuffer) from [] > > > > > > > > > > > (__drm_fb_helper_initial_config_and_unlock+0x2fc/0x50c) > > > > > > > > > > > [] (__drm_fb_helper_initial_config_and_unlock) > > > > > > > > > > > from [] (drm_fbdev_client_hotplug+0xe8/0x1b8) > > > > > > > > > > > [] (drm_fbdev_client_hotplug) from > > > > > > > > > > > [] (drm_fbdev_generic_setup+0x88/0x118) > > > >
Re: [PULL] topic/remove-fbcon-notifiers for v5.3
Op 18-06-2019 om 13:17 schreef Bartlomiej Zolnierkiewicz: > Hi, > > On 6/18/19 11:20 AM, Maarten Lankhorst wrote: >> Op 14-06-2019 om 11:25 schreef Maarten Lankhorst: >>> Hi all, >>> >>> As discussed with Daniel V, I'm just doing the paperwork here as drm-misc >>> maintainer. >>> >>> This is the topic pull request for the fbdev notifier removal. >>> >>> Bar, please make a final check and pull into your fbdev tree. >>> >>> Lee, please make a final check and pull into your backlight tree. >>> >>> Greg, this is just fyi, you already acked all the vt and staging patches in >>> here >>> to land through other trees. >>> >>> I'll pull this into drm-misc-next once Bart & Lee acked it. >>> >>> Cheers, Maarten. >> Bart, Lee, ping? > Looks OK to me (I have test pulled it locally and there is only trivial > merge conflict on removed mxsfb fbdev driver) but it seems that all > patches miss your "S-o-B:" line (there is only "Reviewed-by:" tag which > is OK but has a different meaning)? Hey, I created the topic branch, but daniel pushed the patches to it. :) That explains why there's a R-B but no S-o-B. Cheers, Maarten > Best regards, > -- > Bartlomiej Zolnierkiewicz > Samsung R&D Institute Poland > Samsung Electronics > >>> topic/remove-fbcon-notifiers-2019-06-14-1: >>> >>> topic/remove-fbcon-notifiers: >>> - remove fbdev notifier usage for fbcon, as prep work to clean up the fbcon >>> locking >>> - assorted locking checks in vt/console code >>> - assorted notifier and cleanups in fbdev and backlight code >>> >>> The following changes since commit d1fdb6d8f6a4109a4263176c84b899076a5f8008: >>> >>> Linux 5.2-rc4 (2019-06-08 20:24:46 -0700) >>> >>> are available in the Git repository at: >>> >>> git://anongit.freedesktop.org/drm/drm-misc >>> tags/topic/remove-fbcon-notifiers-2019-06-14-1 >>> >>> for you to fetch changes up to 1dcff4ae65185e8c0300972f6d8d39d9a9db2bda: >>> >>> backlight: simplify lcd notifier (2019-06-13 10:07:20 +0200) >>> >>> >>> Daniel Vetter (33): >>> dummycon: Sprinkle locking checks >>> fbdev: locking check for fb_set_suspend >>> vt: might_sleep() annotation for do_blank_screen >>> vt: More locking checks >>> fbdev/sa1100fb: Remove dead code >>> fbdev/cyber2000: Remove struct display >>> fbdev/aty128fb: Remove dead code >>> fbcon: s/struct display/struct fbcon_display/ >>> fbcon: Remove fbcon_has_exited >>> fbcon: call fbcon_fb_(un)registered directly >>> fbdev/sh_mobile: remove sh_mobile_lcdc_display_notify >>> fbdev/omap: sysfs files can't disappear before the device is gone >>> fbdev: sysfs files can't disappear before the device is gone >>> staging/olpc: lock_fb_info can't fail >>> fbdev/atyfb: lock_fb_info can't fail >>> fbdev: lock_fb_info cannot fail >>> fbcon: call fbcon_fb_bind directly >>> fbdev: make unregister/unlink functions not fail >>> fbdev: unify unlink_framebuffer paths >>> fbdev/sh_mob: Remove fb notifier callback >>> fbdev: directly call fbcon_suspended/resumed >>> fbcon: Call fbcon_mode_deleted/new_modelist directly >>> fbdev: Call fbcon_get_requirement directly >>> Revert "backlight/fbcon: Add FB_EVENT_CONBLANK" >>> fbmem: pull fbcon_fb_blanked out of fb_blank >>> fbdev: remove FBINFO_MISC_USEREVENT around fb_blank >>> fb: Flatten control flow in fb_set_var >>> fbcon: replace FB_EVENT_MODE_CHANGE/_ALL with direct calls >>> vgaswitcheroo: call fbcon_remap_all directly >>> fbcon: Call con2fb_map functions directly >>> fbcon: Document what I learned about fbcon locking >>> staging/olpc_dcon: Add drm conversion to TODO >>> backlight: simplify lcd notifier >>> >>> arch/arm/mach-pxa/am200epd.c| 13 +- >>> drivers/gpu/vga/vga_switcheroo.c| 11 +- >>> drivers/media/pci/ivtv/ivtvfb.c | 6 +- >>> drivers/staging/fbtft/fbtft-core.c | 4 +- >>> drivers/staging/olpc_dcon/TODO | 7 + >>> drivers/staging/olpc_dcon/olpc_dcon.c | 6 +- >>> drivers/tty/vt/vt.c | 18 ++ >>> drivers/video/backlight/backlight.c | 2 +- >>> drivers/video/backlight/lcd.c | 12 - >>> drivers/video/console/dummycon.c| 6 + >>> drivers/video/fbdev/aty/aty128fb.c | 64 >>> drivers/video/fbdev/aty/atyfb_base.c| 3 +- >>> drivers/video/fbdev/core/fbcmap.c | 6 +- >>> drivers/video/fbdev/core/fbcon.c| 313 --- >>> drivers/video/fbdev/core/fbcon.h| 6 +- >>> drivers/video/fbdev/core/fbmem.c| 399 >>> +--- >>> drivers/video/fbdev/core/fbsysfs.c | 20 +- >>> driver
Re: [PATCH 1/7] video: add HDMI state notifier support
On Tue, Jun 11, 2019 at 8:35 PM Daniel Vetter wrote: > > On Tue, Jun 11, 2019 at 08:10:38PM +0800, Cheng-yi Chiang wrote: > > On Tue, Jun 4, 2019 at 3:24 PM Daniel Vetter wrote: > > > > > > On Tue, Jun 04, 2019 at 10:32:50AM +0800, Cheng-yi Chiang wrote: > > > > On Mon, Jun 3, 2019 at 4:09 PM Daniel Vetter wrote: > > > > > > > > > > On Mon, Jun 03, 2019 at 09:45:49AM +0200, Hans Verkuil wrote: > > > > > > On 6/3/19 6:32 AM, Cheng-Yi Chiang wrote: > > > > > > > From: Hans Verkuil > > > > > > > > > > > > > > Add support for HDMI hotplug and EDID notifiers, which is used to > > > > > > > convey > > > > > > > information from HDMI drivers to their CEC and audio counterparts. > > > > > > > > > > > > > > Based on an earlier version from Russell King: > > > > > > > > > > > > > > https://patchwork.kernel.org/patch/9277043/ > > > > > > > > > > > > > > The hdmi_notifier is a reference counted object containing the > > > > > > > HDMI state > > > > > > > of an HDMI device. > > > > > > > > > > > > > > When a new notifier is registered the current state will be > > > > > > > reported to > > > > > > > that notifier at registration time. > > > > > > > > > > > > > > Based on Hans Verkuil's patch: > > > > > > > > > > > > > > https://patchwork.kernel.org/patch/9472521/ > > > > > > > > > > > > Erm, you are aware that this patch morphed into a CEC-specific > > > > > > notifier > > > > > > found in drivers/media/cec/cec-notifier.c? > > > > > > > > > > > > I don't think it makes sense to have two notifier implementations > > > > > > in the kernel. > > > > > > The original intention was to have the notifier deal with both CEC > > > > > > and ASoC > > > > > > notifications, but there was not enough interest for the ASoC bits > > > > > > at the time > > > > > > and it was dropped. > > > > > > > > > > > > I am planning changes to the cec-notifier API, I hope to work on > > > > > > that this > > > > > > week. I'll CC you when I post those. Those might be a good starting > > > > > > point > > > > > > to convert the cec-notifier to an hdmi-notifier as was originally > > > > > > intended. > > > > > > > > > > > > I've added your colleague Dariusz Marcinkiewicz to the CC list > > > > > > since he's been > > > > > > working on some nice cec-notifier improvements as well. > > > > > > > > > > We also have some interfaces for drm/alsa interactions around hdmi > > > > > already in drm/drm_audio_component.h, but it's not used by anything > > > > > outside of i915. Imo we should extend that, not reinvent a new wheel. > > > > > > > > > Hi Daniel, > > > > Thank you for the pointer. Looking at the ops, it seems that it is > > > > specific to HDA. > > > > I am not familiar with drm and HDA. I am not sure how applicable it > > > > would be to report jack status to ASoC. > > > > There is a use case in sound/soc/codecs/hdac_hdmi.c though so it > > > > should be possible. > > > > > > Currently hda is the only user, but the idea was to make it more generic. > > > Jack status in alsa is what drm calls connector status btw. > > > > > > So if we can take that as a baseline and extend it (probably needs some > > > registration boilerplate and helpers to look up the right endpoint using > > > of/dt for soc systems, we use component.c in i915/hda for this), that > > > would be great I think. > > > > > > > > Another note: notifiers considered evil, imo. Gets the job done for > > > > > one > > > > > case, as soon as you have multiple devices and need to make sure you > > > > > get > > > > > the update for the right one it all comes crashing down. Please > > > > > create an > > > > > api which registers for updates from a specific device only, plus > > > > > something that has real callbacks (like the drm_audio_component.h > > > > > thing we > > > > > started already). > > > > > > > > To clarify a bit, this hdmi-notifier indeed supports updating from a > > > > specific device only. > > > > hdmi_notifier_get takes a device and return the notifier. > > > > > > Hm I missed that, I thought it's global, so one of my usual notifier > > > concerns addressed. > > > > > > > It seems that a major difference between drm_audio_components and > > > > hdmi-notifier is that > > > > drm_audio_components defines all supported ops in > > > > drm_audio_component_audio_ops. > > > > On the other hand, hdmi-notifier passes different events using an enum > > > > like HDMI_CONNECTED and let listener handle different events. > > > > In this regard I agree with you that drm_audio_component is cleaner. > > > > Anyway, I will look into it a bit more and see how it works. > > > > > > Yeah I think if we could combine the approach, i.e. notifier side for > > > registration, some _ops structure for the actual notifications, then > > > there's a solid interface. I just really don't like the opaque void * > > > interface notifier provides, it encourages abuse way too much. > > > > > > Ofc the registration side would then no longer be based on the notifier > > > datastructure,
[PATCH 5/6] drm/amdgpu: add independent DMA-buf export v6
The caching of SGT's is actually quite harmful and should probably removed
altogether when all drivers are audited.
Start by providing a separate DMA-buf export implementation in amdgpu.
This is also a prerequisite of unpinned DMA-buf handling.
v2: fix unintended recursion, remove debugging leftovers
v3: split out from unpinned DMA-buf work
v4: rebase on top of new no_sgt_cache flag
v5: fix some warnings by including amdgpu_dma_buf.h
v6: fix locking for non amdgpu exports
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 210 +---
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h | 1 -
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 -
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 5 +
4 files changed, 139 insertions(+), 78 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
index 489041df1f45..579e33b31f2d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
@@ -34,26 +34,11 @@
#include "amdgpu.h"
#include "amdgpu_display.h"
#include "amdgpu_gem.h"
+#include "amdgpu_dma_buf.h"
#include
#include
#include
-/**
- * amdgpu_gem_prime_get_sg_table - &drm_driver.gem_prime_get_sg_table
- * implementation
- * @obj: GEM buffer object (BO)
- *
- * Returns:
- * A scatter/gather table for the pinned pages of the BO's memory.
- */
-struct sg_table *amdgpu_gem_prime_get_sg_table(struct drm_gem_object *obj)
-{
- struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
- int npages = bo->tbo.num_pages;
-
- return drm_prime_pages_to_sg(bo->tbo.ttm->pages, npages);
-}
-
/**
* amdgpu_gem_prime_vmap - &dma_buf_ops.vmap implementation
* @obj: GEM BO
@@ -179,92 +164,163 @@ __reservation_object_make_exclusive(struct
reservation_object *obj)
}
/**
- * amdgpu_dma_buf_map_attach - &dma_buf_ops.attach implementation
- * @dma_buf: Shared DMA buffer
+ * amdgpu_dma_buf_attach - &dma_buf_ops.attach implementation
+ *
+ * @dmabuf: DMA-buf where we attach to
+ * @attach: attachment to add
+ *
+ * Add the attachment as user to the exported DMA-buf.
+ */
+static int amdgpu_dma_buf_attach(struct dma_buf *dmabuf,
+struct dma_buf_attachment *attach)
+{
+ struct drm_gem_object *obj = dmabuf->priv;
+ struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
+ struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
+ int r;
+
+ if (attach->dev->driver == adev->dev->driver)
+ return 0;
+
+ r = amdgpu_bo_reserve(bo, false);
+ if (unlikely(r != 0))
+ return r;
+
+ /*
+* We only create shared fences for internal use, but importers
+* of the dmabuf rely on exclusive fences for implicitly
+* tracking write hazards. As any of the current fences may
+* correspond to a write, we need to convert all existing
+* fences on the reservation object into a single exclusive
+* fence.
+*/
+ r = __reservation_object_make_exclusive(bo->tbo.resv);
+ if (r)
+ return r;
+
+ bo->prime_shared_count++;
+ amdgpu_bo_unreserve(bo);
+ return 0;
+}
+
+/**
+ * amdgpu_dma_buf_detach - &dma_buf_ops.detach implementation
+ *
+ * @dmabuf: DMA-buf where we remove the attachment from
+ * @attach: the attachment to remove
+ *
+ * Called when an attachment is removed from the DMA-buf.
+ */
+static void amdgpu_dma_buf_detach(struct dma_buf *dmabuf,
+ struct dma_buf_attachment *attach)
+{
+ struct drm_gem_object *obj = dmabuf->priv;
+ struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
+ struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
+
+ if (attach->dev->driver != adev->dev->driver && bo->prime_shared_count)
+ bo->prime_shared_count--;
+}
+
+/**
+ * amdgpu_dma_buf_pin - &dma_buf_ops.pin implementation
+ *
+ * @attach: attachment to pin down
+ *
+ * Pin the BO which is backing the DMA-buf so that it can't move any more.
+ */
+static int amdgpu_dma_buf_pin(struct dma_buf_attachment *attach)
+{
+ struct drm_gem_object *obj = attach->dmabuf->priv;
+ struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
+
+ /* pin buffer into GTT */
+ return amdgpu_bo_pin(bo, AMDGPU_GEM_DOMAIN_GTT);
+}
+
+/**
+ * amdgpu_dma_buf_unpin - &dma_buf_ops.unpin implementation
+ *
+ * @attach: attachment to unpin
+ *
+ * Unpin a previously pinned BO to make it movable again.
+ */
+static void amdgpu_dma_buf_unpin(struct dma_buf_attachment *attach)
+{
+ struct drm_gem_object *obj = attach->dmabuf->priv;
+ struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
+
+ amdgpu_bo_unpin(bo);
+}
+
+/**
+ * amdgpu_dma_buf_map_dma_buf - &dma_buf_ops.map_dma_buf implementation
* @attach: DMA-buf attachment
+ * @dir: DMA direction
*
* Makes sure that the shared DMA buffer can be accessed by the target device.
* For now, simply pi
Re: [PATCH 1/7] video: add HDMI state notifier support
On Tue, Jun 11, 2019 at 9:11 PM Hans Verkuil wrote: > > On 6/11/19 2:10 PM, Cheng-yi Chiang wrote: > > On Tue, Jun 4, 2019 at 3:24 PM Daniel Vetter wrote: > >> > >> On Tue, Jun 04, 2019 at 10:32:50AM +0800, Cheng-yi Chiang wrote: > >>> On Mon, Jun 3, 2019 at 4:09 PM Daniel Vetter wrote: > > On Mon, Jun 03, 2019 at 09:45:49AM +0200, Hans Verkuil wrote: > > On 6/3/19 6:32 AM, Cheng-Yi Chiang wrote: > >> From: Hans Verkuil > >> > >> Add support for HDMI hotplug and EDID notifiers, which is used to > >> convey > >> information from HDMI drivers to their CEC and audio counterparts. > >> > >> Based on an earlier version from Russell King: > >> > >> https://patchwork.kernel.org/patch/9277043/ > >> > >> The hdmi_notifier is a reference counted object containing the HDMI > >> state > >> of an HDMI device. > >> > >> When a new notifier is registered the current state will be reported to > >> that notifier at registration time. > >> > >> Based on Hans Verkuil's patch: > >> > >> https://patchwork.kernel.org/patch/9472521/ > > > > Erm, you are aware that this patch morphed into a CEC-specific notifier > > found in drivers/media/cec/cec-notifier.c? > > > > I don't think it makes sense to have two notifier implementations in > > the kernel. > > The original intention was to have the notifier deal with both CEC and > > ASoC > > notifications, but there was not enough interest for the ASoC bits at > > the time > > and it was dropped. > > > > I am planning changes to the cec-notifier API, I hope to work on that > > this > > week. I'll CC you when I post those. Those might be a good starting > > point > > to convert the cec-notifier to an hdmi-notifier as was originally > > intended. > > > > I've added your colleague Dariusz Marcinkiewicz to the CC list since > > he's been > > working on some nice cec-notifier improvements as well. > > We also have some interfaces for drm/alsa interactions around hdmi > already in drm/drm_audio_component.h, but it's not used by anything > outside of i915. Imo we should extend that, not reinvent a new wheel. > > >>> Hi Daniel, > >>> Thank you for the pointer. Looking at the ops, it seems that it is > >>> specific to HDA. > >>> I am not familiar with drm and HDA. I am not sure how applicable it > >>> would be to report jack status to ASoC. > >>> There is a use case in sound/soc/codecs/hdac_hdmi.c though so it > >>> should be possible. > >> > >> Currently hda is the only user, but the idea was to make it more generic. > >> Jack status in alsa is what drm calls connector status btw. > >> > >> So if we can take that as a baseline and extend it (probably needs some > >> registration boilerplate and helpers to look up the right endpoint using > >> of/dt for soc systems, we use component.c in i915/hda for this), that > >> would be great I think. > >> > Another note: notifiers considered evil, imo. Gets the job done for one > case, as soon as you have multiple devices and need to make sure you get > the update for the right one it all comes crashing down. Please create an > api which registers for updates from a specific device only, plus > something that has real callbacks (like the drm_audio_component.h thing > we > started already). > >>> > >>> To clarify a bit, this hdmi-notifier indeed supports updating from a > >>> specific device only. > >>> hdmi_notifier_get takes a device and return the notifier. > >> > >> Hm I missed that, I thought it's global, so one of my usual notifier > >> concerns addressed. > >> > >>> It seems that a major difference between drm_audio_components and > >>> hdmi-notifier is that > >>> drm_audio_components defines all supported ops in > >>> drm_audio_component_audio_ops. > >>> On the other hand, hdmi-notifier passes different events using an enum > >>> like HDMI_CONNECTED and let listener handle different events. > >>> In this regard I agree with you that drm_audio_component is cleaner. > >>> Anyway, I will look into it a bit more and see how it works. > >> > >> Yeah I think if we could combine the approach, i.e. notifier side for > >> registration, some _ops structure for the actual notifications, then > >> there's a solid interface. I just really don't like the opaque void * > >> interface notifier provides, it encourages abuse way too much. > >> > >> Ofc the registration side would then no longer be based on the notifier > >> datastructure, list_head (like cec-notifier.c) of registeres devices with > >> their _ops structure should be enough. > >> -Daniel > > > > Hi Daniel, > > Yes, I agree the above statement that we should have a more solid interface. > > > > Hi Hans, > > I am not sure if I missed the patch. > > You haven't :-) > > > Do you have a estimated timeline for new cec-notifier interface you > > are worki
[PATCH 6/6] drm/amdgpu: add independent DMA-buf import v6
Instead of relying on the DRM functions just implement our own import
functions. This prepares support for taking care of unpinned DMA-buf.
v2: enable for all exporters, not just amdgpu, fix invalidation
handling, lock reservation object while setting callback
v3: change to new dma_buf attach interface
v4: split out from unpinned DMA-buf work
v5: rebased and cleanup on new DMA-buf interface
v6: squash with invalidation callback change,
stop using _(map|unmap)_locked
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 65 -
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h | 4 --
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 -
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 6 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 32 --
5 files changed, 83 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
index 579e33b31f2d..31511d7de8a0 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
@@ -424,31 +424,28 @@ struct dma_buf *amdgpu_gem_prime_export(struct drm_device
*dev,
}
/**
- * amdgpu_gem_prime_import_sg_table - &drm_driver.gem_prime_import_sg_table
- * implementation
+ * amdgpu_dma_buf_create_obj - create BO for DMA-buf import
+ *
* @dev: DRM device
- * @attach: DMA-buf attachment
- * @sg: Scatter/gather table
+ * @dma_buf: DMA-buf
*
- * Imports shared DMA buffer memory exported by another device.
+ * Creates an empty SG BO for DMA-buf import.
*
* Returns:
* A new GEM BO of the given DRM device, representing the memory
* described by the given DMA-buf attachment and scatter/gather table.
*/
-struct drm_gem_object *
-amdgpu_gem_prime_import_sg_table(struct drm_device *dev,
-struct dma_buf_attachment *attach,
-struct sg_table *sg)
+static struct drm_gem_object *
+amdgpu_dma_buf_create_obj(struct drm_device *dev, struct dma_buf *dma_buf)
{
- struct reservation_object *resv = attach->dmabuf->resv;
+ struct reservation_object *resv = dma_buf->resv;
struct amdgpu_device *adev = dev->dev_private;
struct amdgpu_bo *bo;
struct amdgpu_bo_param bp;
int ret;
memset(&bp, 0, sizeof(bp));
- bp.size = attach->dmabuf->size;
+ bp.size = dma_buf->size;
bp.byte_align = PAGE_SIZE;
bp.domain = AMDGPU_GEM_DOMAIN_CPU;
bp.flags = 0;
@@ -459,11 +456,9 @@ amdgpu_gem_prime_import_sg_table(struct drm_device *dev,
if (ret)
goto error;
- bo->tbo.sg = sg;
- bo->tbo.ttm->sg = sg;
bo->allowed_domains = AMDGPU_GEM_DOMAIN_GTT;
bo->preferred_domains = AMDGPU_GEM_DOMAIN_GTT;
- if (attach->dmabuf->ops != &amdgpu_dmabuf_ops)
+ if (dma_buf->ops != &amdgpu_dmabuf_ops)
bo->prime_shared_count = 1;
ww_mutex_unlock(&resv->lock);
@@ -474,6 +469,32 @@ amdgpu_gem_prime_import_sg_table(struct drm_device *dev,
return ERR_PTR(ret);
}
+/**
+ * amdgpu_gem_prime_invalidate_mappings - &attach.invalidate implementation
+ *
+ * @attach: the DMA-buf attachment
+ *
+ * Invalidate the DMA-buf attachment, making sure that the we re-create the
+ * mapping before the next use.
+ */
+static void
+amdgpu_gem_prime_invalidate_mappings(struct dma_buf_attachment *attach)
+{
+ struct ttm_operation_ctx ctx = { false, false };
+ struct drm_gem_object *obj = attach->importer_priv;
+ struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
+ struct ttm_placement placement = {};
+ int r;
+
+ r = ttm_bo_validate(&bo->tbo, &placement, &ctx);
+ if (r)
+ DRM_ERROR("Failed to invalidate DMA-buf import (%d))\n", r);
+}
+
+static const struct dma_buf_attach_ops amdgpu_dma_buf_attach_ops = {
+ .invalidate = amdgpu_gem_prime_invalidate_mappings
+};
+
/**
* amdgpu_gem_prime_import - &drm_driver.gem_prime_import implementation
* @dev: DRM device
@@ -488,6 +509,7 @@ amdgpu_gem_prime_import_sg_table(struct drm_device *dev,
struct drm_gem_object *amdgpu_gem_prime_import(struct drm_device *dev,
struct dma_buf *dma_buf)
{
+ struct dma_buf_attachment *attach;
struct drm_gem_object *obj;
if (dma_buf->ops == &amdgpu_dmabuf_ops) {
@@ -502,5 +524,18 @@ struct drm_gem_object *amdgpu_gem_prime_import(struct
drm_device *dev,
}
}
- return drm_gem_prime_import(dev, dma_buf);
+ obj = amdgpu_dma_buf_create_obj(dev, dma_buf);
+ if (IS_ERR(obj))
+ return obj;
+
+ attach = dma_buf_dynamic_attach(dma_buf, dev->dev,
+ &amdgpu_dma_buf_attach_ops, obj);
+ if (IS_ERR(attach)) {
+ drm_gem_object_put(obj);
+ return ERR_CAST(attach);
+ }
+
+ get_dma_buf(dma_buf);
+
[PATCH 1/6] dma-buf: add dynamic DMA-buf handling v10
On the exporter side we add optional explicit pinning callbacks. If those
callbacks are implemented the framework no longer caches sg tables and the
map/unmap callbacks are always called with the lock of the reservation object
held.
On the importer side we add an optional invalidate callback. This callback is
used by the exporter to inform the importers that their mappings should be
destroyed as soon as possible.
This allows the exporter to provide the mappings without the need to pin
the backing store.
v2: don't try to invalidate mappings when the callback is NULL,
lock the reservation obj while using the attachments,
add helper to set the callback
v3: move flag for invalidation support into the DMA-buf,
use new attach_info structure to set the callback
v4: use importer_priv field instead of mangling exporter priv.
v5: drop invalidation_supported flag
v6: squash together with pin/unpin changes
v7: pin/unpin takes an attachment now
v8: nuke dma_buf_attachment_(map|unmap)_locked,
everything is now handled backward compatible
v9: always cache when export/importer don't agree on dynamic handling
v10: minimal style cleanup
Signed-off-by: Christian König
---
drivers/dma-buf/dma-buf.c | 188 --
include/linux/dma-buf.h | 109 --
2 files changed, 283 insertions(+), 14 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 6c15deb5d4ad..9c9c95a88655 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -531,6 +531,9 @@ struct dma_buf *dma_buf_export(const struct
dma_buf_export_info *exp_info)
return ERR_PTR(-EINVAL);
}
+ if (WARN_ON(exp_info->ops->cache_sgt_mapping && exp_info->ops->pin))
+ return ERR_PTR(-EINVAL);
+
if (!try_module_get(exp_info->owner))
return ERR_PTR(-ENOENT);
@@ -651,10 +654,12 @@ void dma_buf_put(struct dma_buf *dmabuf)
EXPORT_SYMBOL_GPL(dma_buf_put);
/**
- * dma_buf_attach - Add the device to dma_buf's attachments list; optionally,
+ * dma_buf_dynamic_attach - Add the device to dma_buf's attachments list;
optionally,
* calls attach() of dma_buf_ops to allow device-specific attach functionality
- * @dmabuf:[in]buffer to attach device to.
- * @dev: [in]device to be attached.
+ * @dmabuf:[in]buffer to attach device to.
+ * @dev: [in]device to be attached.
+ * @importer_ops [in]importer operations for the attachment
+ * @importer_priv [in]importer private pointer for the attachment
*
* Returns struct dma_buf_attachment pointer for this attachment. Attachments
* must be cleaned up by calling dma_buf_detach().
@@ -668,8 +673,10 @@ EXPORT_SYMBOL_GPL(dma_buf_put);
* accessible to @dev, and cannot be moved to a more suitable place. This is
* indicated with the error code -EBUSY.
*/
-struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
- struct device *dev)
+struct dma_buf_attachment *
+dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev,
+ const struct dma_buf_attach_ops *importer_ops,
+ void *importer_priv)
{
struct dma_buf_attachment *attach;
int ret;
@@ -683,6 +690,8 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf
*dmabuf,
attach->dev = dev;
attach->dmabuf = dmabuf;
+ attach->importer_ops = importer_ops;
+ attach->importer_priv = importer_priv;
mutex_lock(&dmabuf->lock);
@@ -691,16 +700,72 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf
*dmabuf,
if (ret)
goto err_attach;
}
+ reservation_object_lock(dmabuf->resv, NULL);
list_add(&attach->node, &dmabuf->attachments);
+ reservation_object_unlock(dmabuf->resv);
mutex_unlock(&dmabuf->lock);
+ /* When either the importer or the exporter can't handle dynamic
+* mappings we cache the mapping here to avoid issues with the
+* reservation object lock.
+*/
+ if (dma_buf_attachment_is_dynamic(attach) !=
+ dma_buf_is_dynamic(dmabuf)) {
+ struct sg_table *sgt;
+
+ if (dma_buf_is_dynamic(attach->dmabuf)) {
+ reservation_object_lock(attach->dmabuf->resv, NULL);
+ ret = dma_buf_pin(attach);
+ if (ret)
+ goto err_unlock;
+ }
+
+ sgt = dmabuf->ops->map_dma_buf(attach, DMA_BIDIRECTIONAL);
+ if (!sgt)
+ sgt = ERR_PTR(-ENOMEM);
+ if (IS_ERR(sgt)) {
+ ret = PTR_ERR(sgt);
+ goto err_unpin;
+ }
+ if (dma_buf_is_dynamic(attach->dmabuf))
+ reservation_object_unlock(attach->dmabuf->re
[PATCH v2] drm/mcde: Fix uninitialized variable
We need to handle the case when of_drm_find_bridge() returns
NULL.
Reported-by: Dan Carpenter
Cc: Dan Carpenter
Signed-off-by: Linus Walleij
---
ChangeLog v1->v2:
- Account for both NULL and error pointers by two clauses.
---
drivers/gpu/drm/mcde/mcde_drv.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mcde/mcde_drv.c b/drivers/gpu/drm/mcde/mcde_drv.c
index baf63fb6850a..a810568c76df 100644
--- a/drivers/gpu/drm/mcde/mcde_drv.c
+++ b/drivers/gpu/drm/mcde/mcde_drv.c
@@ -319,7 +319,7 @@ static int mcde_probe(struct platform_device *pdev)
struct device *dev = &pdev->dev;
struct drm_device *drm;
struct mcde *mcde;
- struct component_match *match;
+ struct component_match *match = NULL;
struct resource *res;
u32 pid;
u32 val;
@@ -485,6 +485,10 @@ static int mcde_probe(struct platform_device *pdev)
}
put_device(p);
}
+ if (!match) {
+ dev_err(dev, "no matching components\n");
+ return -ENODEV;
+ }
if (IS_ERR(match)) {
dev_err(dev, "could not create component match\n");
ret = PTR_ERR(match);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/6] drm/amdgpu: use allowed_domains for exported DMA-bufs
Avoid that we ping/pong the buffers when we stop to pin DMA-buf
exports by using the allowed domains for exported buffers.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index dc63707e426f..0da512341194 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
@@ -414,7 +415,9 @@ static int amdgpu_cs_bo_validate(struct amdgpu_cs_parser *p,
/* Don't move this buffer if we have depleted our allowance
* to move it. Don't move anything if the threshold is zero.
*/
- if (p->bytes_moved < p->bytes_moved_threshold) {
+ if (p->bytes_moved < p->bytes_moved_threshold &&
+ (!bo->gem_base.dma_buf ||
+ list_empty(&bo->gem_base.dma_buf->attachments))) {
if (!amdgpu_gmc_vram_full_visible(&adev->gmc) &&
(bo->flags & AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED)) {
/* And don't move a CPU_ACCESS_REQUIRED BO to limited
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/6] drm/ttm: remove the backing store if no placement is given
Pipeline removal of the BOs backing store when no placement is given
during validation.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index c7de667d482a..682a1a035b35 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1240,6 +1240,18 @@ int ttm_bo_validate(struct ttm_buffer_object *bo,
uint32_t new_flags;
reservation_object_assert_held(bo->resv);
+
+ /*
+* Remove the backing store if no placement is given.
+*/
+ if (!placement->num_placement && !placement->num_busy_placement) {
+ ret = ttm_bo_pipeline_gutting(bo);
+ if (ret)
+ return ret;
+
+ return ttm_tt_create(bo, false);
+ }
+
/*
* Check whether we need to move buffer.
*/
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/6] drm/ttm: use the parent resv for ghost objects v2
This way we can even pipeline imported BO evictions.
v2: Limit this to only cases when the parent object uses a separate
reservation object as well. This fixes another OOM problem.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 895d77d799e4..95f47d685921 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -517,9 +517,11 @@ static int ttm_buffer_object_transfer(struct
ttm_buffer_object *bo,
kref_init(&fbo->base.kref);
fbo->base.destroy = &ttm_transfered_destroy;
fbo->base.acc_size = 0;
- fbo->base.resv = &fbo->base.ttm_resv;
- reservation_object_init(fbo->base.resv);
- ret = reservation_object_trylock(fbo->base.resv);
+ if (bo->resv == &bo->ttm_resv)
+ fbo->base.resv = &fbo->base.ttm_resv;
+
+ reservation_object_init(&fbo->base.ttm_resv);
+ ret = reservation_object_trylock(&fbo->base.ttm_resv);
WARN_ON(!ret);
*new_obj = &fbo->base;
@@ -716,7 +718,7 @@ int ttm_bo_move_accel_cleanup(struct ttm_buffer_object *bo,
if (ret)
return ret;
- reservation_object_add_excl_fence(ghost_obj->resv, fence);
+ reservation_object_add_excl_fence(&ghost_obj->ttm_resv, fence);
/**
* If we're not moving to fixed memory, the TTM object
@@ -729,7 +731,7 @@ int ttm_bo_move_accel_cleanup(struct ttm_buffer_object *bo,
else
bo->ttm = NULL;
- ttm_bo_unreserve(ghost_obj);
+ reservation_object_unlock(&ghost_obj->ttm_resv);
ttm_bo_put(ghost_obj);
}
@@ -772,7 +774,7 @@ int ttm_bo_pipeline_move(struct ttm_buffer_object *bo,
if (ret)
return ret;
- reservation_object_add_excl_fence(ghost_obj->resv, fence);
+ reservation_object_add_excl_fence(&ghost_obj->ttm_resv, fence);
/**
* If we're not moving to fixed memory, the TTM object
@@ -785,7 +787,7 @@ int ttm_bo_pipeline_move(struct ttm_buffer_object *bo,
else
bo->ttm = NULL;
- ttm_bo_unreserve(ghost_obj);
+ reservation_object_unlock(&ghost_obj->ttm_resv);
ttm_bo_put(ghost_obj);
} else if (from->flags & TTM_MEMTYPE_FLAG_FIXED) {
@@ -841,7 +843,7 @@ int ttm_bo_pipeline_gutting(struct ttm_buffer_object *bo)
if (ret)
return ret;
- ret = reservation_object_copy_fences(ghost->resv, bo->resv);
+ ret = reservation_object_copy_fences(&ghost->ttm_resv, bo->resv);
/* Last resort, wait for the BO to be idle when we are OOM */
if (ret)
ttm_bo_wait(bo, false, false);
@@ -850,7 +852,7 @@ int ttm_bo_pipeline_gutting(struct ttm_buffer_object *bo)
bo->mem.mem_type = TTM_PL_SYSTEM;
bo->ttm = NULL;
- ttm_bo_unreserve(ghost);
+ reservation_object_unlock(&ghost->ttm_resv);
ttm_bo_put(ghost);
return 0;
--
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: debugfs: make drm_debugfs_remove_files() a void function
On Fri, Jun 14, 2019 at 05:37:58PM +0200, Daniel Vetter wrote: > On Fri, Jun 14, 2019 at 5:20 PM Greg Kroah-Hartman > wrote: > > > > On Fri, Jun 14, 2019 at 04:59:08PM +0200, Daniel Vetter wrote: > > > On Fri, Jun 14, 2019 at 11:51:09AM +0200, Greg Kroah-Hartman wrote: > > > > The function can not fail, and no one checks the current return value, > > > > so just mark it as a void function so no one gets confused. > > > > > > > > Cc: Maarten Lankhorst > > > > Cc: Maxime Ripard > > > > Cc: Sean Paul > > > > Cc: David Airlie > > > > Cc: Daniel Vetter > > > > Cc: dri-devel@lists.freedesktop.org > > > > Signed-off-by: Greg Kroah-Hartman > > > > --- > > > > drivers/gpu/drm/drm_debugfs.c | 5 ++--- > > > > include/drm/drm_debugfs.h | 9 - > > > > 2 files changed, 6 insertions(+), 8 deletions(-) > > > > > > > > diff --git a/drivers/gpu/drm/drm_debugfs.c > > > > b/drivers/gpu/drm/drm_debugfs.c > > > > index 6f2802e9bfb5..515569002c86 100644 > > > > --- a/drivers/gpu/drm/drm_debugfs.c > > > > +++ b/drivers/gpu/drm/drm_debugfs.c > > > > @@ -270,8 +270,8 @@ int drm_debugfs_init(struct drm_minor *minor, int > > > > minor_id, > > > > } > > > > > > > > > > > > -int drm_debugfs_remove_files(const struct drm_info_list *files, int > > > > count, > > > > -struct drm_minor *minor) > > > > +void drm_debugfs_remove_files(const struct drm_info_list *files, int > > > > count, > > > > + struct drm_minor *minor) > > > > > > We're trying to entirely nuke this function here, see the kerneldoc for > > > drm_debugfs_create_files(). Only user left is tegra, and we call the > > > "remove all debugfs files" and the ->early_unregister hooks all from the > > > same place. So this can all be garbage collected. It's mildly annoying > > > because we'd need to move the kfree from ->early_unregister into ->destroy > > > callbacks, because connectors are unregister before we throw away all the > > > debugfs files in drm_dev_unregister(). But imo that's cleaner anway. > > > > I would love to see this function gone, it can also make things a lot > > simpler from the point of view of creating the debugfs files as well, as > > no dentries will need to be saved. > > > > > Up for that? > > > > Sure, I can do that. I have a much larger patch messing with > > drm_debugfs_create_files() that I want you all to be in a good mood for > > when I submit it (it touches all drivers at once), so I might as well > > clean this up first :) > > Oh don't worry, we've had a pile of cleanup todo tasks in this area > since a long time. You doing them all is going to make me a happy > camper :-) > > Only thing to be aware of is that we have a bit a habit of dragging > good contributors of refactoring/cleanup/fundamental work like this > into the drm fold for good. You might get stuck ... Hah... Anyway, what tree/branch should I do this work on? I see drm-next, is that the one to use, but it doesn't seem to have the other patches you all said you accepted from me for this debugfs cleanup already. thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] Re: [PATCH v10 01/11] drm/sun4i: dsi: Fix TCON DRQ set bits
On Tue, Jun 18, 2019 at 5:13 PM Chen-Yu Tsai wrote: > > On Tue, Jun 18, 2019 at 6:51 PM Jagan Teki wrote: > > > > On Fri, Jun 14, 2019 at 8:15 PM Maxime Ripard > > wrote: > > > > > > On Fri, Jun 14, 2019 at 12:03:13PM +0530, Jagan Teki wrote: > > > > On Thu, Jun 13, 2019 at 6:56 PM Maxime Ripard > > > > wrote: > > > > > > > > > > On Wed, Jun 05, 2019 at 01:17:11PM +0530, Jagan Teki wrote: > > > > > > On Tue, Jun 4, 2019 at 3:30 PM Maxime Ripard > > > > > > wrote: > > > > > > > > > > > > > > On Wed, May 29, 2019 at 11:44:56PM +0530, Jagan Teki wrote: > > > > > > > > On Wed, May 29, 2019 at 8:24 PM Maxime Ripard > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > On Fri, May 24, 2019 at 03:48:51PM +0530, Jagan Teki wrote: > > > > > > > > > > On Fri, May 24, 2019 at 2:04 AM Maxime Ripard > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > On Mon, May 20, 2019 at 02:33:08PM +0530, Jagan Teki > > > > > > > > > > > wrote: > > > > > > > > > > > > According to "DRM kernel-internal display mode > > > > > > > > > > > > structure" in > > > > > > > > > > > > include/drm/drm_modes.h the current driver is trying to > > > > > > > > > > > > include > > > > > > > > > > > > sync timings along with front porch value while > > > > > > > > > > > > checking and > > > > > > > > > > > > computing drq set bits in non-burst mode. > > > > > > > > > > > > > > > > > > > > > > > > mode->hsync_end - mode->hdisplay => horizontal front > > > > > > > > > > > > porch + sync > > > > > > > > > > > > > > > > > > > > > > > > With adding additional sync timings, the dsi controller > > > > > > > > > > > > leads to > > > > > > > > > > > > wrong drq set bits for "bananapi,s070wv20-ct16" panel > > > > > > > > > > > > which indeed > > > > > > > > > > > > trigger panel flip_done timed out as: > > > > > > > > > > > > > > > > > > > > > > > > WARNING: CPU: 0 PID: 31 at > > > > > > > > > > > > drivers/gpu/drm/drm_atomic_helper.c:1429 > > > > > > > > > > > > drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0 > > > > > > > > > > > > [CRTC:46:crtc-0] vblank wait timed out > > > > > > > > > > > > Modules linked in: > > > > > > > > > > > > CPU: 0 PID: 31 Comm: kworker/0:1 Not tainted > > > > > > > > > > > > 5.1.0-next-20190514-00026-g01f0c75b902d-dirty #13 > > > > > > > > > > > > Hardware name: Allwinner sun8i Family > > > > > > > > > > > > Workqueue: events deferred_probe_work_func > > > > > > > > > > > > [] (unwind_backtrace) from [] > > > > > > > > > > > > (show_stack+0x10/0x14) > > > > > > > > > > > > [] (show_stack) from [] > > > > > > > > > > > > (dump_stack+0x84/0x98) > > > > > > > > > > > > [] (dump_stack) from [] > > > > > > > > > > > > (__warn+0xfc/0x114) > > > > > > > > > > > > [] (__warn) from [] > > > > > > > > > > > > (warn_slowpath_fmt+0x44/0x68) > > > > > > > > > > > > [] (warn_slowpath_fmt) from [] > > > > > > > > > > > > (drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0) > > > > > > > > > > > > [] > > > > > > > > > > > > (drm_atomic_helper_wait_for_vblanks.part.1) from > > > > > > > > > > > > [] > > > > > > > > > > > > (drm_atomic_helper_commit_tail_rpm+0x5c/0x6c) > > > > > > > > > > > > [] (drm_atomic_helper_commit_tail_rpm) from > > > > > > > > > > > > [] (commit_tail+0x40/0x6c) > > > > > > > > > > > > [] (commit_tail) from [] > > > > > > > > > > > > (drm_atomic_helper_commit+0xbc/0x128) > > > > > > > > > > > > [] (drm_atomic_helper_commit) from > > > > > > > > > > > > [] (restore_fbdev_mode_atomic+0x1cc/0x1dc) > > > > > > > > > > > > [] (restore_fbdev_mode_atomic) from > > > > > > > > > > > > [] > > > > > > > > > > > > (drm_fb_helper_restore_fbdev_mode_unlocked+0x54/0xa0) > > > > > > > > > > > > [] > > > > > > > > > > > > (drm_fb_helper_restore_fbdev_mode_unlocked) from > > > > > > > > > > > > [] (drm_fb_helper_set_par+0x30/0x54) > > > > > > > > > > > > [] (drm_fb_helper_set_par) from [] > > > > > > > > > > > > (fbcon_init+0x560/0x5ac) > > > > > > > > > > > > [] (fbcon_init) from [] > > > > > > > > > > > > (visual_init+0xbc/0x104) > > > > > > > > > > > > [] (visual_init) from [] > > > > > > > > > > > > (do_bind_con_driver+0x1b0/0x390) > > > > > > > > > > > > [] (do_bind_con_driver) from [] > > > > > > > > > > > > (do_take_over_console+0x13c/0x1c4) > > > > > > > > > > > > [] (do_take_over_console) from [] > > > > > > > > > > > > (do_fbcon_takeover+0x74/0xcc) > > > > > > > > > > > > [] (do_fbcon_takeover) from [] > > > > > > > > > > > > (notifier_call_chain+0x44/0x84) > > > > > > > > > > > > [] (notifier_call_chain) from [] > > > > > > > > > > > > (__blocking_notifier_call_chain+0x48/0x60) > > > > > > > > > > > > [] (__blocking_notifier_call_chain) from > > > > > > > > > > > > [] (blocking_notifier_call_chain+0x18/0x20) > > > > > > > > > > > > [] (blocking_notifier_call_chain) from > > > > > > > > > > > > [] (register_framebuffer+0x1e0/0x2f8) > > > > > > > > > > > > [] (register_framebuffer) from [] > > > > > > > > > > > > (__drm_fb_he
Re: [PATCH 1/7] video: add HDMI state notifier support
On Tue, Jun 18, 2019 at 07:48:06PM +0800, Cheng-yi Chiang wrote: > On Tue, Jun 11, 2019 at 8:35 PM Daniel Vetter wrote: > > > > On Tue, Jun 11, 2019 at 08:10:38PM +0800, Cheng-yi Chiang wrote: > > > On Tue, Jun 4, 2019 at 3:24 PM Daniel Vetter wrote: > > > > > > > > On Tue, Jun 04, 2019 at 10:32:50AM +0800, Cheng-yi Chiang wrote: > > > > > On Mon, Jun 3, 2019 at 4:09 PM Daniel Vetter wrote: > > > > > > > > > > > > On Mon, Jun 03, 2019 at 09:45:49AM +0200, Hans Verkuil wrote: > > > > > > > On 6/3/19 6:32 AM, Cheng-Yi Chiang wrote: > > > > > > > > From: Hans Verkuil > > > > > > > > > > > > > > > > Add support for HDMI hotplug and EDID notifiers, which is used > > > > > > > > to convey > > > > > > > > information from HDMI drivers to their CEC and audio > > > > > > > > counterparts. > > > > > > > > > > > > > > > > Based on an earlier version from Russell King: > > > > > > > > > > > > > > > > https://patchwork.kernel.org/patch/9277043/ > > > > > > > > > > > > > > > > The hdmi_notifier is a reference counted object containing the > > > > > > > > HDMI state > > > > > > > > of an HDMI device. > > > > > > > > > > > > > > > > When a new notifier is registered the current state will be > > > > > > > > reported to > > > > > > > > that notifier at registration time. > > > > > > > > > > > > > > > > Based on Hans Verkuil's patch: > > > > > > > > > > > > > > > > https://patchwork.kernel.org/patch/9472521/ > > > > > > > > > > > > > > Erm, you are aware that this patch morphed into a CEC-specific > > > > > > > notifier > > > > > > > found in drivers/media/cec/cec-notifier.c? > > > > > > > > > > > > > > I don't think it makes sense to have two notifier implementations > > > > > > > in the kernel. > > > > > > > The original intention was to have the notifier deal with both > > > > > > > CEC and ASoC > > > > > > > notifications, but there was not enough interest for the ASoC > > > > > > > bits at the time > > > > > > > and it was dropped. > > > > > > > > > > > > > > I am planning changes to the cec-notifier API, I hope to work on > > > > > > > that this > > > > > > > week. I'll CC you when I post those. Those might be a good > > > > > > > starting point > > > > > > > to convert the cec-notifier to an hdmi-notifier as was originally > > > > > > > intended. > > > > > > > > > > > > > > I've added your colleague Dariusz Marcinkiewicz to the CC list > > > > > > > since he's been > > > > > > > working on some nice cec-notifier improvements as well. > > > > > > > > > > > > We also have some interfaces for drm/alsa interactions around hdmi > > > > > > already in drm/drm_audio_component.h, but it's not used by anything > > > > > > outside of i915. Imo we should extend that, not reinvent a new > > > > > > wheel. > > > > > > > > > > > Hi Daniel, > > > > > Thank you for the pointer. Looking at the ops, it seems that it is > > > > > specific to HDA. > > > > > I am not familiar with drm and HDA. I am not sure how applicable it > > > > > would be to report jack status to ASoC. > > > > > There is a use case in sound/soc/codecs/hdac_hdmi.c though so it > > > > > should be possible. > > > > > > > > Currently hda is the only user, but the idea was to make it more > > > > generic. > > > > Jack status in alsa is what drm calls connector status btw. > > > > > > > > So if we can take that as a baseline and extend it (probably needs some > > > > registration boilerplate and helpers to look up the right endpoint using > > > > of/dt for soc systems, we use component.c in i915/hda for this), that > > > > would be great I think. > > > > > > > > > > Another note: notifiers considered evil, imo. Gets the job done for > > > > > > one > > > > > > case, as soon as you have multiple devices and need to make sure > > > > > > you get > > > > > > the update for the right one it all comes crashing down. Please > > > > > > create an > > > > > > api which registers for updates from a specific device only, plus > > > > > > something that has real callbacks (like the drm_audio_component.h > > > > > > thing we > > > > > > started already). > > > > > > > > > > To clarify a bit, this hdmi-notifier indeed supports updating from a > > > > > specific device only. > > > > > hdmi_notifier_get takes a device and return the notifier. > > > > > > > > Hm I missed that, I thought it's global, so one of my usual notifier > > > > concerns addressed. > > > > > > > > > It seems that a major difference between drm_audio_components and > > > > > hdmi-notifier is that > > > > > drm_audio_components defines all supported ops in > > > > > drm_audio_component_audio_ops. > > > > > On the other hand, hdmi-notifier passes different events using an enum > > > > > like HDMI_CONNECTED and let listener handle different events. > > > > > In this regard I agree with you that drm_audio_component is cleaner. > > > > > Anyway, I will look into it a bit more and see how it works. > > > > > > > > Yeah I think if we could combine the approach, i.e. notifier side for > > > > registr
Re: [PATCH 1/2] drm: debugfs: make drm_debugfs_remove_files() a void function
On Tue, Jun 18, 2019 at 02:01:35PM +0200, Greg Kroah-Hartman wrote: > On Fri, Jun 14, 2019 at 05:37:58PM +0200, Daniel Vetter wrote: > > On Fri, Jun 14, 2019 at 5:20 PM Greg Kroah-Hartman > > wrote: > > > > > > On Fri, Jun 14, 2019 at 04:59:08PM +0200, Daniel Vetter wrote: > > > > On Fri, Jun 14, 2019 at 11:51:09AM +0200, Greg Kroah-Hartman wrote: > > > > > The function can not fail, and no one checks the current return value, > > > > > so just mark it as a void function so no one gets confused. > > > > > > > > > > Cc: Maarten Lankhorst > > > > > Cc: Maxime Ripard > > > > > Cc: Sean Paul > > > > > Cc: David Airlie > > > > > Cc: Daniel Vetter > > > > > Cc: dri-devel@lists.freedesktop.org > > > > > Signed-off-by: Greg Kroah-Hartman > > > > > --- > > > > > drivers/gpu/drm/drm_debugfs.c | 5 ++--- > > > > > include/drm/drm_debugfs.h | 9 - > > > > > 2 files changed, 6 insertions(+), 8 deletions(-) > > > > > > > > > > diff --git a/drivers/gpu/drm/drm_debugfs.c > > > > > b/drivers/gpu/drm/drm_debugfs.c > > > > > index 6f2802e9bfb5..515569002c86 100644 > > > > > --- a/drivers/gpu/drm/drm_debugfs.c > > > > > +++ b/drivers/gpu/drm/drm_debugfs.c > > > > > @@ -270,8 +270,8 @@ int drm_debugfs_init(struct drm_minor *minor, int > > > > > minor_id, > > > > > } > > > > > > > > > > > > > > > -int drm_debugfs_remove_files(const struct drm_info_list *files, int > > > > > count, > > > > > -struct drm_minor *minor) > > > > > +void drm_debugfs_remove_files(const struct drm_info_list *files, int > > > > > count, > > > > > + struct drm_minor *minor) > > > > > > > > We're trying to entirely nuke this function here, see the kerneldoc for > > > > drm_debugfs_create_files(). Only user left is tegra, and we call the > > > > "remove all debugfs files" and the ->early_unregister hooks all from the > > > > same place. So this can all be garbage collected. It's mildly annoying > > > > because we'd need to move the kfree from ->early_unregister into > > > > ->destroy > > > > callbacks, because connectors are unregister before we throw away all > > > > the > > > > debugfs files in drm_dev_unregister(). But imo that's cleaner anway. > > > > > > I would love to see this function gone, it can also make things a lot > > > simpler from the point of view of creating the debugfs files as well, as > > > no dentries will need to be saved. > > > > > > > Up for that? > > > > > > Sure, I can do that. I have a much larger patch messing with > > > drm_debugfs_create_files() that I want you all to be in a good mood for > > > when I submit it (it touches all drivers at once), so I might as well > > > clean this up first :) > > > > Oh don't worry, we've had a pile of cleanup todo tasks in this area > > since a long time. You doing them all is going to make me a happy > > camper :-) > > > > Only thing to be aware of is that we have a bit a habit of dragging > > good contributors of refactoring/cleanup/fundamental work like this > > into the drm fold for good. You might get stuck ... > > Hah... > > Anyway, what tree/branch should I do this work on? I see drm-next, is > that the one to use, but it doesn't seem to have the other patches you > all said you accepted from me for this debugfs cleanup already. linux-next is usually a good starting point, drm stuff is a bit too much spread around multiple trees. The only caveat is that some trees (drm-misc and drm-intel) keep merging during the feature freeze (after -rc6) and merge window, to collect patches for the merge-window+1. In those cases it might be better to rebase on top of drm-tip: https://cgit.freedesktop.org/drm-tip It's kinda like linux-next, but for drm. Only downside is that not all drm trees participate in that integration tree. Simpelst is probably to just base on linux-next and dump everything that hasn't landed after -rc2 onto dri-devel again. Cheers, Daniel -- 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 1/4] drm/vmwgfx: Assign eviction priorities to resources
On Tue, Jun 18, 2019 at 11:54:08AM +0100, Emil Velikov wrote: > Hi Thomas, > > On 2019/06/18, Thomas Hellström (VMware) wrote: > > From: Thomas Hellstrom > > > > TTM provides a means to assign eviction priorities to buffer object. This > > means that all buffer objects with a lower priority will be evicted first > > on memory pressure. > > Use this to make sure surfaces and in particular non-dirty surfaces are > > evicted first. Evicting in particular shaders, cotables and contexts imply > > a significant performance hit on vmwgfx, so make sure these resources are > > evicted last. > > Some buffer objects are sub-allocated in user-space which means we can have > > many resources attached to a single buffer object or resource. In that case > > the buffer object is given the highest priority of the attached resources. > > > > Signed-off-by: Thomas Hellstrom > > Reviewed-by: Deepak Rawat > Fwiw patches 1-3 are: > Reviewed-by: Emil Velikov > > Patch 4 is: > Acked-by: Emil Velikov > > Huge thanks for sorting this out. Oh, does this mean we can remove the varios master* callbacks from drm_driver now? Iirc vmwgfx was the only user, and those callbacks seem very tempting to various folks for implementing questionable driver hacks ... Happy to type the patches, but maybe simpler if you do that since all this gets merged through the vmwgfx tree. Cheers, Daniel -- 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 v2] drm/mcde: Fix uninitialized variable
Thanks! regards, dan carpenter ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 48/59] drm/vgem: Ditch attach trickery in the fence ioctl
Quoting Daniel Vetter (2019-06-14 21:36:04)
> It looks like this was done purely to get a consistent place to look
> up the reservation object pointer. With the drm_prime.c helper code
> now also setting gem_object->resv for imported objects we can just use
> that pointer directly, instead of first ensuring a dma-buf exists.
Oh. commit 1ba627148ef5 ("drm: Add reservation_object to drm_gem_object")
embedded a reservation_object into the struct. I was wondering what on
earth I was doing if the code should have been so simple.
References: 1ba627148ef5 ("drm: Add reservation_object to drm_gem_object")
> Signed-off-by: Daniel Vetter
Reviewed-by: Chris Wilson
Quick leave before I start ranting about the horrors of
reservation_object.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 02/10] media: vsp1: drm: Don't configure hardware when the pipeline is disabled
Hi Laurent,
On 17/06/2019 22:09, Laurent Pinchart wrote:
> The vsp1_du_atomic_flush() function calls vsp1_du_pipeline_configure()
> to configure the hardware pipeline. The function is currently guaranteed
> to be called with the pipeline enabled, but this will change by future
> rework of the DU driver. Guard the hardware configuration to skip it
> when the pipeline is disabled. The hardware will be configured the next
> time the pipeline gets enabled.
Aha, Yes, I think this now makes sense to why I was still getting hangs!
Thanks for the fix!
> Signed-off-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
> ---
> drivers/media/platform/vsp1/vsp1_drm.c | 13 -
> drivers/media/platform/vsp1/vsp1_drm.h | 2 ++
> 2 files changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/platform/vsp1/vsp1_drm.c
> b/drivers/media/platform/vsp1/vsp1_drm.c
> index 7957e1439de0..900465caf1bf 100644
> --- a/drivers/media/platform/vsp1/vsp1_drm.c
> +++ b/drivers/media/platform/vsp1/vsp1_drm.c
> @@ -723,6 +723,8 @@ int vsp1_du_atomic_enable(struct device *dev, unsigned
> int pipe_index,
> /* Configure all entities in the pipeline. */
> vsp1_du_pipeline_configure(pipe);
>
> + drm_pipe->enabled = true;
> +
> unlock:
> mutex_unlock(&vsp1->drm->lock);
>
> @@ -800,6 +802,8 @@ int vsp1_du_atomic_disable(struct device *dev, unsigned
> int pipe_index)
> pipe->brx->pipe = NULL;
> pipe->brx = NULL;
>
> + drm_pipe->enabled = false;
> +
> mutex_unlock(&vsp1->drm->lock);
>
> vsp1_dlm_reset(pipe->output->dlm);
> @@ -992,7 +996,14 @@ void vsp1_du_atomic_flush(struct device *dev, unsigned
> int pipe_index,
> }
>
> vsp1_du_pipeline_setup_inputs(vsp1, pipe);
> - vsp1_du_pipeline_configure(pipe);
> +
> + /*
> + * We may get called before the pipeline gets enabled, postpone
> + * configuration in that case. vsp1_du_pipeline_configure() will be
> + * called from vsp1_du_atomic_enable().
> + */
> + if (drm_pipe->enabled)
> + vsp1_du_pipeline_configure(pipe);
>
> done:
> mutex_unlock(&vsp1->drm->lock);
> diff --git a/drivers/media/platform/vsp1/vsp1_drm.h
> b/drivers/media/platform/vsp1/vsp1_drm.h
> index e85ad4366fbb..d780dafc1324 100644
> --- a/drivers/media/platform/vsp1/vsp1_drm.h
> +++ b/drivers/media/platform/vsp1/vsp1_drm.h
> @@ -20,6 +20,7 @@
> /**
> * vsp1_drm_pipeline - State for the API exposed to the DRM driver
> * @pipe: the VSP1 pipeline used for display
> + * @enabled: true if the pipeline is enabled
> * @width: output display width
> * @height: output display height
> * @force_brx_release: when set, release the BRx during the next
> reconfiguration
> @@ -31,6 +32,7 @@
> */
> struct vsp1_drm_pipeline {
> struct vsp1_pipeline pipe;
> + bool enabled;
>
> unsigned int width;
> unsigned int height;
>
--
Regards
--
Kieran
Re: [PATCH v3 01/10] media: vsp1: drm: Split vsp1_du_setup_lif()
Thank you for your patch.
> On June 17, 2019 at 11:09 PM Laurent Pinchart
> wrote:
>
>
> From: Kieran Bingham
>
> Break vsp1_du_setup_lif() into components more suited to the DRM Atomic
> API. The existing vsp1_du_setup_lif() API call is maintained as it is
> still used from the DU.
>
> Signed-off-by: Kieran Bingham
> Signed-off-by: Laurent Pinchart
> ---
> Changes since v2:
>
> - Minor formatting changes
> - Fix NULL pointer dereference in vsp1_du_setup_lif()
> ---
> drivers/media/platform/vsp1/vsp1_drm.c | 220 ++---
> include/media/vsp1.h | 32 +++-
> 2 files changed, 189 insertions(+), 63 deletions(-)
>
> diff --git a/drivers/media/platform/vsp1/vsp1_drm.c
> b/drivers/media/platform/vsp1/vsp1_drm.c
> index a4a45d68a6ef..7957e1439de0 100644
> --- a/drivers/media/platform/vsp1/vsp1_drm.c
> +++ b/drivers/media/platform/vsp1/vsp1_drm.c
> @@ -616,10 +616,10 @@ int vsp1_du_init(struct device *dev)
> EXPORT_SYMBOL_GPL(vsp1_du_init);
>
> /**
> - * vsp1_du_setup_lif - Setup the output part of the VSP pipeline
> + * vsp1_du_atomic_modeset - Configure the mode as part of an atomic update
> * @dev: the VSP device
> * @pipe_index: the DRM pipeline index
> - * @cfg: the LIF configuration
> + * @cfg: the mode configuration
> *
> * Configure the output part of VSP DRM pipeline for the given frame
> @cfg.width
> * and @cfg.height. This sets up formats on the BRx source pad, the WPF sink
> and
> @@ -636,14 +636,12 @@ EXPORT_SYMBOL_GPL(vsp1_du_init);
> *
> * Return 0 on success or a negative error code on failure.
> */
> -int vsp1_du_setup_lif(struct device *dev, unsigned int pipe_index,
> - const struct vsp1_du_lif_config *cfg)
> +int vsp1_du_atomic_modeset(struct device *dev, unsigned int pipe_index,
> +const struct vsp1_du_modeset_config *cfg)
> {
> struct vsp1_device *vsp1 = dev_get_drvdata(dev);
> struct vsp1_drm_pipeline *drm_pipe;
> struct vsp1_pipeline *pipe;
> - unsigned long flags;
> - unsigned int i;
> int ret;
>
> if (pipe_index >= vsp1->info->lif_count)
> @@ -652,60 +650,6 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int
> pipe_index,
> drm_pipe = &vsp1->drm->pipe[pipe_index];
> pipe = &drm_pipe->pipe;
>
> - if (!cfg) {
> - struct vsp1_brx *brx;
> -
> - mutex_lock(&vsp1->drm->lock);
> -
> - brx = to_brx(&pipe->brx->subdev);
> -
> - /*
> - * NULL configuration means the CRTC is being disabled, stop
> - * the pipeline and turn the light off.
> - */
> - ret = vsp1_pipeline_stop(pipe);
> - if (ret == -ETIMEDOUT)
> - dev_err(vsp1->dev, "DRM pipeline stop timeout\n");
> -
> - for (i = 0; i < ARRAY_SIZE(pipe->inputs); ++i) {
> - struct vsp1_rwpf *rpf = pipe->inputs[i];
> -
> - if (!rpf)
> - continue;
> -
> - /*
> - * Remove the RPF from the pipe and the list of BRx
> - * inputs.
> - */
> - WARN_ON(!rpf->entity.pipe);
> - rpf->entity.pipe = NULL;
> - list_del(&rpf->entity.list_pipe);
> - pipe->inputs[i] = NULL;
> -
> - brx->inputs[rpf->brx_input].rpf = NULL;
> - }
> -
> - drm_pipe->du_complete = NULL;
> - pipe->num_inputs = 0;
> -
> - dev_dbg(vsp1->dev, "%s: pipe %u: releasing %s\n",
> - __func__, pipe->lif->index,
> - BRX_NAME(pipe->brx));
> -
> - list_del(&pipe->brx->list_pipe);
> - pipe->brx->pipe = NULL;
> - pipe->brx = NULL;
> -
> - mutex_unlock(&vsp1->drm->lock);
> -
> - vsp1_dlm_reset(pipe->output->dlm);
> - vsp1_device_put(vsp1);
> -
> - dev_dbg(vsp1->dev, "%s: pipeline disabled\n", __func__);
> -
> - return 0;
> - }
> -
> drm_pipe->width = cfg->width;
> drm_pipe->height = cfg->height;
> pipe->interlaced = cfg->interlaced;
> @@ -722,8 +666,43 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int
> pipe_index,
> goto unlock;
>
> ret = vsp1_du_pipeline_setup_output(vsp1, pipe);
> - if (ret < 0)
> - goto unlock;
> +
> +unlock:
> + mutex_unlock(&vsp1->drm->lock);
> +
> + return ret;
> +}
> +
> +/**
> + * vsp1_du_atomic_enable - Enable and start a DU pipeline
> + * @dev: the VSP device
> + * @pipe_index: the DRM pipeline index
> + * @cfg: the enablement configuration
> + *
> + * The @pipe_index argument selects which DRM pipeline to enable. The number
> of
> + * available pipelines depend on the VSP instance.
"depends".
> + *
> + * The configuration passes a callback function to register n
Re: [PATCH v3 02/10] media: vsp1: drm: Don't configure hardware when the pipeline is disabled
> On June 17, 2019 at 11:09 PM Laurent Pinchart
> wrote:
>
>
> The vsp1_du_atomic_flush() function calls vsp1_du_pipeline_configure()
> to configure the hardware pipeline. The function is currently guaranteed
> to be called with the pipeline enabled, but this will change by future
> rework of the DU driver. Guard the hardware configuration to skip it
> when the pipeline is disabled. The hardware will be configured the next
> time the pipeline gets enabled.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/media/platform/vsp1/vsp1_drm.c | 13 -
> drivers/media/platform/vsp1/vsp1_drm.h | 2 ++
> 2 files changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/platform/vsp1/vsp1_drm.c
> b/drivers/media/platform/vsp1/vsp1_drm.c
> index 7957e1439de0..900465caf1bf 100644
> --- a/drivers/media/platform/vsp1/vsp1_drm.c
> +++ b/drivers/media/platform/vsp1/vsp1_drm.c
> @@ -723,6 +723,8 @@ int vsp1_du_atomic_enable(struct device *dev, unsigned
> int pipe_index,
> /* Configure all entities in the pipeline. */
> vsp1_du_pipeline_configure(pipe);
>
> + drm_pipe->enabled = true;
> +
> unlock:
> mutex_unlock(&vsp1->drm->lock);
>
> @@ -800,6 +802,8 @@ int vsp1_du_atomic_disable(struct device *dev, unsigned
> int pipe_index)
> pipe->brx->pipe = NULL;
> pipe->brx = NULL;
>
> + drm_pipe->enabled = false;
> +
> mutex_unlock(&vsp1->drm->lock);
>
> vsp1_dlm_reset(pipe->output->dlm);
> @@ -992,7 +996,14 @@ void vsp1_du_atomic_flush(struct device *dev, unsigned
> int pipe_index,
> }
>
> vsp1_du_pipeline_setup_inputs(vsp1, pipe);
> - vsp1_du_pipeline_configure(pipe);
> +
> + /*
> + * We may get called before the pipeline gets enabled, postpone
> + * configuration in that case. vsp1_du_pipeline_configure() will be
> + * called from vsp1_du_atomic_enable().
> + */
> + if (drm_pipe->enabled)
> + vsp1_du_pipeline_configure(pipe);
>
> done:
> mutex_unlock(&vsp1->drm->lock);
> diff --git a/drivers/media/platform/vsp1/vsp1_drm.h
> b/drivers/media/platform/vsp1/vsp1_drm.h
> index e85ad4366fbb..d780dafc1324 100644
> --- a/drivers/media/platform/vsp1/vsp1_drm.h
> +++ b/drivers/media/platform/vsp1/vsp1_drm.h
> @@ -20,6 +20,7 @@
> /**
> * vsp1_drm_pipeline - State for the API exposed to the DRM driver
> * @pipe: the VSP1 pipeline used for display
> + * @enabled: true if the pipeline is enabled
> * @width: output display width
> * @height: output display height
> * @force_brx_release: when set, release the BRx during the next
> reconfiguration
> @@ -31,6 +32,7 @@
> */
> struct vsp1_drm_pipeline {
> struct vsp1_pipeline pipe;
> + bool enabled;
>
> unsigned int width;
> unsigned int height;
> --
> Regards,
>
> Laurent Pinchart
>
Reviewed-by: Ulrich Hecht
CU
Uli
Re: [PATCH v3 03/10] drm: rcar-du: Convert to the new VSP atomic API
> On June 17, 2019 at 11:09 PM Laurent Pinchart
> wrote:
>
>
> From: Kieran Bingham
>
> The configuration API between the VSP and the DU has been updated to
> provide finer grain control over modesetting, and enablement.
>
> Split rcar_du_vsp_enable() into rcar_du_vsp_modeset() and
> rcar_du_vsp_enable() accordingly, and update each function to use the
> new VSP API.
>
> There are no further users of the deprecated vsp1_du_setup_lif() which
> can now be removed.
>
> Signed-off-by: Kieran Bingham
> Signed-off-by: Laurent Pinchart
> ---
> Changes since v2:
>
> - Minor formatting changes
> ---
> drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 4 +++-
> drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 20 ++--
> drivers/gpu/drm/rcar-du/rcar_du_vsp.h | 2 ++
> 3 files changed, 19 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> index 2da46e3dc4ae..cccd6fe85749 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> @@ -492,8 +492,10 @@ static void rcar_du_crtc_setup(struct rcar_du_crtc
> *rcrtc)
> rcar_du_group_write(rcrtc->group, rcrtc->index % 2 ? DS2PR : DS1PR, 0);
>
> /* Enable the VSP compositor. */
> - if (rcar_du_has(rcrtc->dev, RCAR_DU_FEATURE_VSP1_SOURCE))
> + if (rcar_du_has(rcrtc->dev, RCAR_DU_FEATURE_VSP1_SOURCE)) {
> + rcar_du_vsp_modeset(rcrtc);
> rcar_du_vsp_enable(rcrtc);
> + }
>
> /* Turn vertical blanking interrupt reporting on. */
> drm_crtc_vblank_on(&rcrtc->crtc);
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> index 5e4faf258c31..3d007d38d7c1 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> @@ -44,16 +44,14 @@ static void rcar_du_vsp_complete(void *private, unsigned
> int status, u32 crc)
> drm_crtc_add_crc_entry(&crtc->crtc, false, 0, &crc);
> }
>
> -void rcar_du_vsp_enable(struct rcar_du_crtc *crtc)
> +void rcar_du_vsp_modeset(struct rcar_du_crtc *crtc)
> {
> const struct drm_display_mode *mode = &crtc->crtc.state->adjusted_mode;
> struct rcar_du_device *rcdu = crtc->dev;
> - struct vsp1_du_lif_config cfg = {
> + struct vsp1_du_modeset_config cfg = {
> .width = mode->hdisplay,
> .height = mode->vdisplay,
> .interlaced = mode->flags & DRM_MODE_FLAG_INTERLACE,
> - .callback = rcar_du_vsp_complete,
> - .callback_data = crtc,
> };
> struct rcar_du_plane_state state = {
> .state = {
> @@ -90,12 +88,22 @@ void rcar_du_vsp_enable(struct rcar_du_crtc *crtc)
>*/
> crtc->group->need_restart = true;
>
> - vsp1_du_setup_lif(crtc->vsp->vsp, crtc->vsp_pipe, &cfg);
> + vsp1_du_atomic_modeset(crtc->vsp->vsp, crtc->vsp_pipe, &cfg);
> +}
> +
> +void rcar_du_vsp_enable(struct rcar_du_crtc *crtc)
> +{
> + struct vsp1_du_enable_config cfg = {
> + .callback = rcar_du_vsp_complete,
> + .callback_data = crtc,
> + };
> +
> + vsp1_du_atomic_enable(crtc->vsp->vsp, crtc->vsp_pipe, &cfg);
> }
>
> void rcar_du_vsp_disable(struct rcar_du_crtc *crtc)
> {
> - vsp1_du_setup_lif(crtc->vsp->vsp, crtc->vsp_pipe, NULL);
> + vsp1_du_atomic_disable(crtc->vsp->vsp, crtc->vsp_pipe);
> }
>
> void rcar_du_vsp_atomic_begin(struct rcar_du_crtc *crtc)
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
> b/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
> index 9b4724159378..a6f6bb4690f2 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
> @@ -58,6 +58,7 @@ to_rcar_vsp_plane_state(struct drm_plane_state *state)
> #ifdef CONFIG_DRM_RCAR_VSP
> int rcar_du_vsp_init(struct rcar_du_vsp *vsp, struct device_node *np,
>unsigned int crtcs);
> +void rcar_du_vsp_modeset(struct rcar_du_crtc *crtc);
> void rcar_du_vsp_enable(struct rcar_du_crtc *crtc);
> void rcar_du_vsp_disable(struct rcar_du_crtc *crtc);
> void rcar_du_vsp_atomic_begin(struct rcar_du_crtc *crtc);
> @@ -73,6 +74,7 @@ static inline int rcar_du_vsp_init(struct rcar_du_vsp *vsp,
> {
> return -ENXIO;
> }
> +static inlinc void rcar_du_vsp_modeset(struct rcar_du_crtc *crtc) { };
> static inline void rcar_du_vsp_enable(struct rcar_du_crtc *crtc) { };
> static inline void rcar_du_vsp_disable(struct rcar_du_crtc *crtc) { };
> static inline void rcar_du_vsp_atomic_begin(struct rcar_du_crtc *crtc) { };
> --
> Regards,
>
> Laurent Pinchart
>
Reviewed-by: Ulrich Hecht
CU
Uli
Re: [PATCH v3 04/10] media: vsp1: drm: Remove vsp1_du_setup_lif()
> On June 17, 2019 at 11:09 PM Laurent Pinchart
> wrote:
>
>
> From: Kieran Bingham
>
> The vsp1_du_setup_lif() function is deprecated, and the users have been
> removed. Remove the implementation and the associated configuration
> structure.
>
> Signed-off-by: Kieran Bingham
> Signed-off-by: Laurent Pinchart
> ---
> drivers/media/platform/vsp1/vsp1_drm.c | 46 --
> include/media/vsp1.h | 22
> 2 files changed, 68 deletions(-)
>
> diff --git a/drivers/media/platform/vsp1/vsp1_drm.c
> b/drivers/media/platform/vsp1/vsp1_drm.c
> index 900465caf1bf..3452d7a6dd89 100644
> --- a/drivers/media/platform/vsp1/vsp1_drm.c
> +++ b/drivers/media/platform/vsp1/vsp1_drm.c
> @@ -815,52 +815,6 @@ int vsp1_du_atomic_disable(struct device *dev, unsigned
> int pipe_index)
> }
> EXPORT_SYMBOL_GPL(vsp1_du_atomic_disable);
>
> -/**
> - * vsp1_du_setup_lif - Setup the output part of the VSP pipeline
> - * @dev: the VSP device
> - * @pipe_index: the DRM pipeline index
> - * @cfg: the LIF configuration
> - *
> - * Configure the output part of VSP DRM pipeline for the given frame
> @cfg.width
> - * and @cfg.height. This sets up formats on the BRx source pad, the WPF sink
> and
> - * source pads, and the LIF sink pad.
> - *
> - * The @pipe_index argument selects which DRM pipeline to setup. The number
> of
> - * available pipelines depend on the VSP instance.
> - *
> - * As the media bus code on the blend unit source pad is conditioned by the
> - * configuration of its sink 0 pad, we also set up the formats on all blend
> unit
> - * sinks, even if the configuration will be overwritten later by
> - * vsp1_du_setup_rpf(). This ensures that the blend unit configuration is
> set to
> - * a well defined state.
> - *
> - * Return 0 on success or a negative error code on failure.
> - */
> -int vsp1_du_setup_lif(struct device *dev, unsigned int pipe_index,
> - const struct vsp1_du_lif_config *cfg)
> -{
> - struct vsp1_du_modeset_config modes;
> - struct vsp1_du_enable_config enable;
> - int ret;
> -
> - if (!cfg)
> - return vsp1_du_atomic_disable(dev, pipe_index);
> -
> - modes.width = cfg->width;
> - modes.height = cfg->height;
> - modes.interlaced = cfg->interlaced;
> -
> - ret = vsp1_du_atomic_modeset(dev, pipe_index, &modes);
> - if (ret)
> - return ret;
> -
> - enable.callback = cfg->callback;
> - enable.callback_data = cfg->callback_data;
> -
> - return vsp1_du_atomic_enable(dev, pipe_index, &enable);
> -}
> -EXPORT_SYMBOL_GPL(vsp1_du_setup_lif);
> -
> /**
> * vsp1_du_atomic_begin - Prepare for an atomic update
> * @dev: the VSP device
> diff --git a/include/media/vsp1.h b/include/media/vsp1.h
> index 56643f97d4c9..b8eadd62fd15 100644
> --- a/include/media/vsp1.h
> +++ b/include/media/vsp1.h
> @@ -20,28 +20,6 @@ int vsp1_du_init(struct device *dev);
> #define VSP1_DU_STATUS_COMPLETE BIT(0)
> #define VSP1_DU_STATUS_WRITEBACK BIT(1)
>
> -/**
> - * struct vsp1_du_lif_config - VSP LIF configuration - Deprecated
> - * @width: output frame width
> - * @height: output frame height
> - * @interlaced: true for interlaced pipelines
> - * @callback: frame completion callback function (optional). When a callback
> - * is provided, the VSP driver guarantees that it will be called once
> - * and only once for each vsp1_du_atomic_flush() call.
> - * @callback_data: data to be passed to the frame completion callback
> - */
> -struct vsp1_du_lif_config {
> - unsigned int width;
> - unsigned int height;
> - bool interlaced;
> -
> - void (*callback)(void *data, unsigned int status, u32 crc);
> - void *callback_data;
> -};
> -
> -int vsp1_du_setup_lif(struct device *dev, unsigned int pipe_index,
> - const struct vsp1_du_lif_config *cfg);
> -
> /**
> * struct vsp1_du_modeset_config - VSP display mode configuration
> * @width: output frame width
> --
> Regards,
>
> Laurent Pinchart
>
Reviewed-by: Ulrich Hecht
CU
Uli
[Bug 110831] [AMD TAHITI XT][amd-staging-drm-next][bisected] broken since 5.2-rc1 rebase
https://bugs.freedesktop.org/show_bug.cgi?id=110831 Sylvain BERTRAND changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED -- 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] backlight: gpio-backlight: Set power state instead of brightness at probe
Hi,
On Fri, 2019-05-17 at 17:05 +0200, Paul Kocialkowski wrote:
> On a trivial gpio-backlight setup with a panel using the backlight but
> no boot software to enable it beforehand, we fall in a case where the
> backlight is disabled (not just blanked) and thus remains disabled when
> the panel gets enabled.
>
> Setting gbl->def_value via the device-tree prop allows enabling the
> backlight in this situation, but it will be unblanked straight away,
> in compliance with the binding. This does not work well when there was no
> boot software to display something before, since we really need to unblank
> by the time the panel is enabled, not before.
>
> Resolve the situation by setting the brightness to 1 at probe and
> managing the power state accordingly, a bit like it's done in
> pwm-backlight.
Any feedback on this? I was under the impression that it could be quite
controversial, as it implies that the backlight can no longer be
enabled without a bound panel (which IMO makes good sense but could be
a matter to debate).
Cheers,
Paul
> Fixes: 8b770e3c9824 ("backlight: Add GPIO-based backlight driver")
> Signed-off-by: Paul Kocialkowski
> ---
> drivers/video/backlight/gpio_backlight.c | 19 ++-
> 1 file changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/video/backlight/gpio_backlight.c
> b/drivers/video/backlight/gpio_backlight.c
> index e470da95d806..c9cb97fa13d0 100644
> --- a/drivers/video/backlight/gpio_backlight.c
> +++ b/drivers/video/backlight/gpio_backlight.c
> @@ -57,6 +57,21 @@ static const struct backlight_ops gpio_backlight_ops = {
> .check_fb = gpio_backlight_check_fb,
> };
>
> +static int gpio_backlight_initial_power_state(struct gpio_backlight *gbl)
> +{
> + struct device_node *node = gbl->dev->of_node;
> +
> + /* If we absolutely want the backlight enabled at boot. */
> + if (gbl->def_value)
> + return FB_BLANK_UNBLANK;
> +
> + /* If there's no panel to unblank the backlight later. */
> + if (!node || !node->phandle)
> + return FB_BLANK_UNBLANK;
> +
> + return FB_BLANK_POWERDOWN;
> +}
> +
> static int gpio_backlight_probe_dt(struct platform_device *pdev,
> struct gpio_backlight *gbl)
> {
> @@ -142,7 +157,9 @@ static int gpio_backlight_probe(struct platform_device
> *pdev)
> return PTR_ERR(bl);
> }
>
> - bl->props.brightness = gbl->def_value;
> + bl->props.brightness = 1;
> + bl->props.power = gpio_backlight_initial_power_state(gbl);
> +
> backlight_update_status(bl);
>
> platform_set_drvdata(pdev, bl);
--
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
[PATCH] drm: return -EFAULT if copy_one_buf() fails
The copy_to_user() function returns the number of bytes remaining to be
copied, but we want to return -EFAULT. This function is called from
__drm_legacy_infobufs() which expects negative error codes.
Fixes: 5c7640ab6258 ("switch compat_drm_infobufs() to drm_ioctl_kernel()")
Signed-off-by: Dan Carpenter
---
This goes through Al's tree and not through drm. Presumably this patch
will just get folded into the original.
drivers/gpu/drm/drm_bufs.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index 68dacf8422c6..8ce9d73fab4f 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -1351,7 +1351,10 @@ static int copy_one_buf(void *data, int count, struct
drm_buf_entry *from)
.size = from->buf_size,
.low_mark = from->low_mark,
.high_mark = from->high_mark};
- return copy_to_user(to, &v, offsetof(struct drm_buf_desc, flags));
+
+ if (copy_to_user(to, &v, offsetof(struct drm_buf_desc, flags)))
+ return -EFAULT;
+ return 0;
}
int drm_legacy_infobufs(struct drm_device *dev, void *data,
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 05/10] drm: rcar-du: Handle CRTC standby from commit tail handler
> On June 17, 2019 at 11:09 PM Laurent Pinchart
> wrote:
>
>
> From: Kieran Bingham
>
> Manage the power state, and initial configuration of the CRTC from the
> commit tail handler. CRTCs which need to be activated are taken out of
> standby, and any deactivated CRTCs are put into standby.
>
> This aims at removing CRTC state tracking from the rcar_du_crtc
> structure. The initial configuration of the CRTC background colours and
> disabling of all planes is taken out of rcar_du_crtc_setup() and moved
> inline into rcar_du_crtc_enable(). rcar_du_crtc_get() and
> rcar_du_crtc_put() are kept as they are needed to configure the VSP at
> the correct time, this will be addressed in a separate change.
>
> Signed-off-by: Kieran Bingham
> Signed-off-by: Laurent Pinchart
> ---
> Changes since v2:
>
> - Add more documentation
> - Keep rcar_du_crtc_get() and rcar_du_crtc_put()
> - Renamed rcar_du_crtc_enable() to rcar_du_crtc_exit_standby() and
> rcar_du_crtc_disable() to rcar_du_crtc_enter_standby()
> - Reword commit message
>
> Changes since v1:
>
> - Registers sequence confirmed unchanged
> - Re-ordered in the series to handle before groups
> - Do not merge rcar_du_crtc_setup() (now handled by _crtc_pre_commit)
> ---
> drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 90 --
> drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 5 ++
> drivers/gpu/drm/rcar-du/rcar_du_kms.c | 4 ++
> 3 files changed, 81 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> index cccd6fe85749..23f4bdef0e3a 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> @@ -480,17 +480,10 @@ static void rcar_du_crtc_wait_page_flip(struct
> rcar_du_crtc *rcrtc)
>
> static void rcar_du_crtc_setup(struct rcar_du_crtc *rcrtc)
> {
> - /* Set display off and background to black */
> - rcar_du_crtc_write(rcrtc, DOOR, DOOR_RGB(0, 0, 0));
> - rcar_du_crtc_write(rcrtc, BPOR, BPOR_RGB(0, 0, 0));
> -
> /* Configure display timings and output routing */
> rcar_du_crtc_set_display_timing(rcrtc);
> rcar_du_group_set_routing(rcrtc->group);
>
> - /* Start with all planes disabled. */
> - rcar_du_group_write(rcrtc->group, rcrtc->index % 2 ? DS2PR : DS1PR, 0);
> -
> /* Enable the VSP compositor. */
> if (rcar_du_has(rcrtc->dev, RCAR_DU_FEATURE_VSP1_SOURCE)) {
> rcar_du_vsp_modeset(rcrtc);
> @@ -501,17 +494,10 @@ static void rcar_du_crtc_setup(struct rcar_du_crtc
> *rcrtc)
> drm_crtc_vblank_on(&rcrtc->crtc);
> }
>
> -static int rcar_du_crtc_get(struct rcar_du_crtc *rcrtc)
> +static int rcar_du_crtc_exit_standby(struct rcar_du_crtc *rcrtc)
> {
> int ret;
>
> - /*
> - * Guard against double-get, as the function is called from both the
> - * .atomic_enable() and .atomic_begin() handlers.
> - */
> - if (rcrtc->initialized)
> - return 0;
> -
> ret = clk_prepare_enable(rcrtc->clock);
> if (ret < 0)
> return ret;
> @@ -524,8 +510,12 @@ static int rcar_du_crtc_get(struct rcar_du_crtc *rcrtc)
> if (ret < 0)
> goto error_group;
>
> - rcar_du_crtc_setup(rcrtc);
> - rcrtc->initialized = true;
> + /* Set display off and background to black. */
> + rcar_du_crtc_write(rcrtc, DOOR, DOOR_RGB(0, 0, 0));
> + rcar_du_crtc_write(rcrtc, BPOR, BPOR_RGB(0, 0, 0));
> +
> + /* Start with all planes disabled. */
> + rcar_du_group_write(rcrtc->group, rcrtc->index % 2 ? DS2PR : DS1PR, 0);
>
> return 0;
>
> @@ -536,13 +526,29 @@ static int rcar_du_crtc_get(struct rcar_du_crtc *rcrtc)
> return ret;
> }
>
> -static void rcar_du_crtc_put(struct rcar_du_crtc *rcrtc)
> +static void rcar_du_crtc_enter_standby(struct rcar_du_crtc *rcrtc)
> {
> rcar_du_group_put(rcrtc->group);
>
> clk_disable_unprepare(rcrtc->extclock);
> clk_disable_unprepare(rcrtc->clock);
> +}
>
> +static void rcar_du_crtc_get(struct rcar_du_crtc *rcrtc)
> +{
> + /*
> + * Guard against double-get, as the function is called from both the
> + * .atomic_enable() and .atomic_begin() handlers.
> + */
> + if (rcrtc->initialized)
> + return;
> +
> + rcar_du_crtc_setup(rcrtc);
> + rcrtc->initialized = true;
> +}
> +
> +static void rcar_du_crtc_put(struct rcar_du_crtc *rcrtc)
> +{
> rcrtc->initialized = false;
> }
>
> @@ -662,6 +668,54 @@ static int rcar_du_crtc_atomic_check(struct drm_crtc
> *crtc,
> return 0;
> }
>
> +/*
> + * Take all CRTCs that are made active in this commit out of standby.
> + * CRTCs that are deactivated by the commit are untouched and will be
> + * put in standby by rcar_du_crtc_atomic_enter_standby().
> + */
> +int rcar_du_crtc_atomic_exit_standby(struct drm_device *dev,
> + struct drm_atomic_state *state)
> +{
> + struct drm_crt
Re: [PATCH 1/4] drm/vmwgfx: Assign eviction priorities to resources
On 6/18/19 2:19 PM, Daniel Vetter wrote: On Tue, Jun 18, 2019 at 11:54:08AM +0100, Emil Velikov wrote: Hi Thomas, On 2019/06/18, Thomas Hellström (VMware) wrote: From: Thomas Hellstrom TTM provides a means to assign eviction priorities to buffer object. This means that all buffer objects with a lower priority will be evicted first on memory pressure. Use this to make sure surfaces and in particular non-dirty surfaces are evicted first. Evicting in particular shaders, cotables and contexts imply a significant performance hit on vmwgfx, so make sure these resources are evicted last. Some buffer objects are sub-allocated in user-space which means we can have many resources attached to a single buffer object or resource. In that case the buffer object is given the highest priority of the attached resources. Signed-off-by: Thomas Hellstrom Reviewed-by: Deepak Rawat Fwiw patches 1-3 are: Reviewed-by: Emil Velikov Patch 4 is: Acked-by: Emil Velikov Huge thanks for sorting this out. Oh, does this mean we can remove the varios master* callbacks from drm_driver now? Iirc vmwgfx was the only user, and those callbacks seem very tempting to various folks for implementing questionable driver hacks ... Happy to type the patches, but maybe simpler if you do that since all this gets merged through the vmwgfx tree. Cheers, Daniel In case someone follow this, I'll paste in the commit message of 4/4 which is the relevant one here.. 8< At one point, the GPU command verifier and user-space handle manager couldn't properly protect GPU clients from accessing each other's data. Instead there was an elaborate mechanism to make sure only the active master's primary clients could render. The other clients were either put to sleep or even killed (if the master had exited). VRAM was evicted on master switch. With the advent of render-node functionality, we relaxed the VRAM eviction, but the other mechanisms stayed in place. Now that the GPU command verifier and ttm object manager properly isolates primary clients from different master realms we can remove the master switch related code and drop those legacy features. 8<--- I think we can at least take a look. I'm out on a fairly long vacation soon so in any case it won't be before August or so. One use we still have for master_set() is that if a master is switched away, and then the mode list changes, and then the master is switched back, it will typically not remember to act on the sysfs event received while switched out, and come back in an incorrect mode. Since mode-list changes happen quite frequently with virtual display adapters that's bad. But perhaps we can consider moving that to core, if that's what needed to get rid of the master switch callbacks. /Thomas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 06/10] drm: rcar-du: Handle CRTC configuration from commit tail handler
> On June 17, 2019 at 11:09 PM Laurent Pinchart
> wrote:
>
>
> From: Kieran Bingham
>
> The CRTC mode setting and routing configuration are performed at the
> earliest of atomic enable and atomic begin, to ensure that a valid
> configuration is applied to the hardware before the CRTC gets enabled
> and before planes are setup (the latter being required in particular by
> the VSP). This requires the rcar_du_crtc structure to track the CRTC
> enabled state.
>
> Simplify the code and remove the manual state tracking by moving CRTC
> setup to a new rcar_du_crtc_atomic_modeset() function, called directly
> from the commit tail handler. The function iterates over all CRTCs in
> the state transaction and performs CRTC mode setting, routing
> configuration and VSP configuration.
>
> drm_crtc_vblank_on() has to be called from the atomic begin handler, to
> ensure that vertical blanking reporting is enabled before the call to
> drm_crtc_vblank_get() in the atomic flush handler. As the
> drm_crtc_vblank_on() and drm_crtc_vblank_off() calls don't need to be
> balanced this is not an issue. A balanced alternative would have been to
> call drm_crtc_vblank_on() and drm_crtc_vblank_off() from the CRTC exit
> and enter standby handlers respectively, but
> drm_atomic_helper_commit_modeset_disables() complains if
> drm_crtc_vblank_off() hasn't been called by the atomic disable handler.
>
> As a result, the vsp1_du_atomic_flush() operation can be called with the
> DRM pipeline disabled. Correct operation has been ensured by "media:
> vsp1: drm: Don't configure hardware when the pipeline is disabled".
>
> Signed-off-by: Kieran Bingham
> Signed-off-by: Laurent Pinchart
> ---
> Changes since v2:
>
> - Deconstruct rcar_du_crtc_setup() completely
> ---
> drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 89 +++---
> drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 4 +-
> drivers/gpu/drm/rcar-du/rcar_du_kms.c | 1 +
> 3 files changed, 42 insertions(+), 52 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> index 23f4bdef0e3a..d11a474f6f72 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> @@ -478,22 +478,6 @@ static void rcar_du_crtc_wait_page_flip(struct
> rcar_du_crtc *rcrtc)
> * Start/Stop and Suspend/Resume
> */
>
> -static void rcar_du_crtc_setup(struct rcar_du_crtc *rcrtc)
> -{
> - /* Configure display timings and output routing */
> - rcar_du_crtc_set_display_timing(rcrtc);
> - rcar_du_group_set_routing(rcrtc->group);
> -
> - /* Enable the VSP compositor. */
> - if (rcar_du_has(rcrtc->dev, RCAR_DU_FEATURE_VSP1_SOURCE)) {
> - rcar_du_vsp_modeset(rcrtc);
> - rcar_du_vsp_enable(rcrtc);
> - }
> -
> - /* Turn vertical blanking interrupt reporting on. */
> - drm_crtc_vblank_on(&rcrtc->crtc);
> -}
> -
> static int rcar_du_crtc_exit_standby(struct rcar_du_crtc *rcrtc)
> {
> int ret;
> @@ -534,24 +518,6 @@ static void rcar_du_crtc_enter_standby(struct
> rcar_du_crtc *rcrtc)
> clk_disable_unprepare(rcrtc->clock);
> }
>
> -static void rcar_du_crtc_get(struct rcar_du_crtc *rcrtc)
> -{
> - /*
> - * Guard against double-get, as the function is called from both the
> - * .atomic_enable() and .atomic_begin() handlers.
> - */
> - if (rcrtc->initialized)
> - return;
> -
> - rcar_du_crtc_setup(rcrtc);
> - rcrtc->initialized = true;
> -}
> -
> -static void rcar_du_crtc_put(struct rcar_du_crtc *rcrtc)
> -{
> - rcrtc->initialized = false;
> -}
> -
> static void rcar_du_crtc_start(struct rcar_du_crtc *rcrtc)
> {
> bool interlaced;
> @@ -716,6 +682,40 @@ int rcar_du_crtc_atomic_enter_standby(struct drm_device
> *dev,
> return 0;
> }
>
> +/*
> + * Configure the mode for all CRTCs that require it. For now we only handle
> mode
> + * set on the VSP, CRTC configuration will be handled later.
> + */
> +int rcar_du_crtc_atomic_modeset(struct drm_device *dev,
> + struct drm_atomic_state *state)
> +{
> + struct drm_crtc_state *crtc_state;
> + struct drm_crtc *crtc;
> + unsigned int i;
> +
> + for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
> + struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
> +
> + /*
> + * Skip commits that don't change the mode. We manually skip
> + * inactive CRTCs as disabling a CRTC is considered as a mode
> + * set by drm_atomic_crtc_needs_modeset().
> + */
> + if (!drm_atomic_crtc_needs_modeset(crtc_state) ||
> + !crtc_state->active)
> + continue;
> +
> + /* Configure display timings and output routing. */
> + rcar_du_crtc_set_display_timing(rcrtc);
> + rcar_du_group_set_routing(rcrtc->group);
> +
> + if (rcar_du_has(rcrtc->dev, R
[PATCH] drm: rcar-du: Replace drm_driver GEM ops with GEM object functions
The recommended way to specify GEM object functions is to provide a
drm_gem_object_funcs structure instance and set the GEM object to point
to it. The drm_cma_gem_create_object_default_funcs() function provided
by the GEM CMA helper does so when creating the GEM object, simplifying
the driver implementation. Switch to it, and remove the then unneeded
GEM-related opertions from rcar_du_driver.
Suggested-by: Daniel Vetter
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
Daniel, is this what you had in mind ?
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index 3e5e835ea2b6..4cbb82009931 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -445,16 +445,10 @@ DEFINE_DRM_GEM_CMA_FOPS(rcar_du_fops);
static struct drm_driver rcar_du_driver = {
.driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME
| DRIVER_ATOMIC,
- .gem_free_object_unlocked = drm_gem_cma_free_object,
- .gem_vm_ops = &drm_gem_cma_vm_ops,
+ .gem_create_object = drm_cma_gem_create_object_default_funcs,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
- .gem_prime_import = drm_gem_prime_import,
- .gem_prime_export = drm_gem_prime_export,
- .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
.gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
- .gem_prime_vmap = drm_gem_cma_prime_vmap,
- .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
.gem_prime_mmap = drm_gem_cma_prime_mmap,
.dumb_create= rcar_du_dumb_create,
.fops = &rcar_du_fops,
--
Regards,
Laurent Pinchart
