Re: [PATCH] drm/i915: properly init lockdep class
On 2017-12-13 16:00:49 [+0200], Joonas Lahtinen wrote: > On Thu, 2017-11-30 at 16:19 +0100, Sebastian Andrzej Siewior wrote: > > The code has an ifdef and uses two functions to either init the bare > > spinlock or init it and set a lock-class. It is possible to do the same > > thing without an ifdef. > > With this patch (in debug case) we first use the "default" lock class > > which is later overwritten to the supplied one. Without lockdep the set > > name/class function vanishes. > > > > Reported-by: kbuild test robot > > How exactly did kbuild test robot figure this out? I fixed it up for RT, then robot found a way to complain about it. Then I slapped myself for not submitting this patch in the first place. > At least according to the source there doesn't seem to be clarity about > what is the right thing to do, this being just one option. I don' think `ifdef CONFIG_DEBUG_SPINLOCK' is an option. Especially since the i915 driver here is the only user in tree doing this kind of thing. Then we have lockdep_set_class_and_name() (which I promote here). This looks like the official way of doing lockdep related things and it has even more than ten users in tree. > Regards, Joonas Sebastian ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v2 01/13] bootsplash: Initial implementation showing black screen
On 12/13/2017 11:47 AM, Max Staudt wrote: > This is the initial prototype for a lean Linux kernel bootsplash. > > As it is now, it will show a black screen rather than a logo, and > only if manually enabled via the kernel cmdline: > > bootsplash.enable=1 Is it .enable or .enabled? (compare below) > diff --git a/drivers/video/console/Kconfig b/drivers/video/console/Kconfig > index 7f1f1fbcef9e..f3ff976266fe 100644 > --- a/drivers/video/console/Kconfig > +++ b/drivers/video/console/Kconfig > @@ -151,6 +151,30 @@ config FRAMEBUFFER_CONSOLE_ROTATION > such that other users of the framebuffer will remain normally > oriented. > > +config BOOTSPLASH > + bool "Bootup splash screen" > + depends on FRAMEBUFFER_CONSOLE > + ---help--- > + This option enables the Linux bootsplash screen. > + > + The bootsplash is a full-screen logo or animation indicating a > + booting system. It replaces the classic scrolling text with a > + graphical alternative, similar to other systems. > + > + Since this is technically implemented as a hook on top of fbcon, > + it can only work if the FRAMEBUFFER_CONSOLE is enabled and a > + framebuffer driver is active. Thus, to get a text-free boot, > + the system needs to boot with vesafb, efifb, or similar. > + > + Once built into the kernel, the bootsplash needs to be enabled > + with bootsplash.enabled=1 and a splash file needs to be supplied. -- ~Randy ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/8] drm/sun4i: Support the Display Engine frontend
Hi, On 13-12-17 16:33, Maxime Ripard wrote: > Hi, > > This is a first serie to enable the display engine frontend. > > This hardware block is found in the first generation Display Engine from > Allwinner. Its role is to implement more advanced features that the > associated backend, even though the backend alone can be used (and was used > so far) for basic composition. > > Among those features, we will find hardware scaling, that is supported in > this serie, colorspace conversions, or more exotic formats support such as > the one output by the VPU. So, if I have read the code correctly. The frontend will be used whenever the input size differs from the output size. > > Let me know what you think, > Maxime > > Maxime Ripard (8): > drm/sun4i: backend: Move line stride setup to buffer setup function > drm/sun4i: backend: Allow a NULL plane pointer to retrieve the format > drm/sun4i: sun4i_layer: Add a custom plane state > drm/sun4i: crtc: Add a custom crtc atomic_check > drm/sun4i: Add a driver for the display frontend > drm/sun4i: sun4i_layer: Wire in the frontend > drm/sun4i: sun4i_layer: Add a custom atomic_check for the frontend > ARM: dts: sun8i: a33 Enable our display frontend > > arch/arm/boot/dts/sun8i-a33.dtsi | 1 +- > drivers/gpu/drm/sun4i/Makefile | 3 +- > drivers/gpu/drm/sun4i/sun4i_backend.c | 139 +- > drivers/gpu/drm/sun4i/sun4i_backend.h | 6 +- > drivers/gpu/drm/sun4i/sun4i_crtc.c | 14 +- > drivers/gpu/drm/sun4i/sun4i_drv.c | 16 +- > drivers/gpu/drm/sun4i/sun4i_drv.h | 1 +- > drivers/gpu/drm/sun4i/sun4i_frontend.c | 377 ++- > drivers/gpu/drm/sun4i/sun4i_frontend.h | 102 +++- > drivers/gpu/drm/sun4i/sun4i_layer.c| 75 - > drivers/gpu/drm/sun4i/sun4i_layer.h| 11 +- > drivers/gpu/drm/sun4i/sunxi_engine.h | 2 +- > 12 files changed, 727 insertions(+), 20 deletions(-) > create mode 100644 drivers/gpu/drm/sun4i/sun4i_frontend.c > create mode 100644 drivers/gpu/drm/sun4i/sun4i_frontend.h > > base-commit: 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: properly init lockdep class
+peterz context: http://www.spinics.net/lists/intel-gfx/msg149011.html On 2017-12-13 17:37:21 [+0200], Joonas Lahtinen wrote: > On Wed, 2017-12-13 at 16:06 +0100, Sebastian Andrzej Siewior wrote: > > On 2017-12-13 16:00:49 [+0200], Joonas Lahtinen wrote: > > > On Thu, 2017-11-30 at 16:19 +0100, Sebastian Andrzej Siewior wrote: > > > > The code has an ifdef and uses two functions to either init the bare > > > > spinlock or init it and set a lock-class. It is possible to do the same > > > > thing without an ifdef. > > > > With this patch (in debug case) we first use the "default" lock class > > > > which is later overwritten to the supplied one. Without lockdep the set > > > > name/class function vanishes. … > > > At least according to the source there doesn't seem to be clarity about > > > what is the right thing to do, this being just one option. > > > > I don' think `ifdef CONFIG_DEBUG_SPINLOCK' is an option. Especially > > since the i915 driver here is the only user in tree doing this kind of > > thing. > > Then we have lockdep_set_class_and_name() (which I promote here). This > > looks like the official way of doing lockdep related things and it has > > even more than ten users in tree. > > I think it be worthwhile to suggest would be the addition of > __spin_lock_init where you can pass in the the lockclass and name. I don't due to the existing interface. However I don't call the shots here and added peterz instead :) > Regards, Joonas Sebastian ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: enable eviction for Per-VM-BO
We need some commit message here. Something like this:
Allow eviction of BOs reserved by the caller when they are not part of
the current working set.
with that fixed the patch is Reviewed-by: Christian König
.
Thanks,
Christian.
Am 14.12.2017 um 09:10 schrieb Roger He:
Change-Id: I0c6ece0decd18d30ccc94e5c7ca106d351941c62
Signed-off-by: Roger He
---
drivers/gpu/drm/ttm/ttm_bo.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 098b22e..ba5b486 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -707,7 +707,6 @@ bool ttm_bo_eviction_valuable(struct ttm_buffer_object *bo,
EXPORT_SYMBOL(ttm_bo_eviction_valuable);
static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
- struct reservation_object *resv,
uint32_t mem_type,
const struct ttm_place *place,
struct ttm_operation_ctx *ctx)
@@ -722,8 +721,9 @@ static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
spin_lock(&glob->lru_lock);
for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
list_for_each_entry(bo, &man->lru[i], lru) {
- if (bo->resv == resv) {
- if (list_empty(&bo->ddestroy))
+ if (bo->resv == ctx->resv) {
+ if (!ctx->allow_reserved_eviction &&
+ list_empty(&bo->ddestroy))
continue;
} else {
locked = reservation_object_trylock(bo->resv);
@@ -835,7 +835,7 @@ static int ttm_bo_mem_force_space(struct ttm_buffer_object
*bo,
return ret;
if (mem->mm_node)
break;
- ret = ttm_mem_evict_first(bdev, bo->resv, mem_type, place, ctx);
+ ret = ttm_mem_evict_first(bdev, mem_type, place, ctx);
if (unlikely(ret != 0))
return ret;
} while (1);
@@ -1332,8 +1332,7 @@ static int ttm_bo_force_list_clean(struct ttm_bo_device
*bdev,
for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
while (!list_empty(&man->lru[i])) {
spin_unlock(&glob->lru_lock);
- ret = ttm_mem_evict_first(bdev, NULL, mem_type,
- NULL, &ctx);
+ ret = ttm_mem_evict_first(bdev, mem_type, NULL, &ctx);
if (ret)
return ret;
spin_lock(&glob->lru_lock);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104159] llvm 6.0svn: firefox GPU fault/hang with r319975
https://bugs.freedesktop.org/show_bug.cgi?id=104159 --- Comment #6 from Christoph Haag --- Created attachment 136167 --> https://bugs.freedesktop.org/attachment.cgi?id=136167&action=edit dmesg Oops, just got a hang again with newer llvm. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: rcar-du: calculate DPLLCR to be more small jitter
Hi Morimoto-san,
On Thursday, 14 December 2017 04:10:27 EET Kuninori Morimoto wrote:
> Hi Laurent
>
> Thank you for your feedback
>
> >> + * NOTES
> >> + * N = (n + 1), M = (m + 1), P = 2
> >> + * 2000 < fvco < 4096Mhz
> >
> > Are you sure that the fvco constraint is really 2kHz, and not 2GHz ? 2kHz
> > - 4GHz would be a surprisingly large range.
>
> It is 2kHz. This is came from HW team, and indicated
> on HW design sheet (?)
OK, it's a surprising VCO, no issue with that :-)
> >> + * Basically M=1
> >
> > Why is this ?
>
> This is came from HW team, too.
> They are assuming M=1, basically.
> But yes confusable, let's remove it from comment.
> m is started from 0 (= M=1), no need to explain.
Sounds good to me.
> >> + for (m = 0; m < 4; m++) {
> >> + for (n = 119; n > 38; n--) {
> >> + unsigned long long fvco = input * 2 * (n + 1) / (m + 1);
> >
> > This code runs for Gen3 only, so unsigned long would be enough. The rest
> > of the function already relies on native support for 64-bit calculation.
> > If you wanted to run this on a 32-bit CPU, you would likely need to
> > do_div() for the division, and convert input to u64 to avoid integer
> > overflows, otherwise the calculation will be performed on 32-bit before a
> > final conversion to 64-bit.
>
> (snip)
>
> >> + if ((fvco < 2000) ||
> >> + (fvco > 409600ll))
> >
> > No need for the inner parentheses, and you can write both conditions on a
> > single line. Furthemore 4096 MHz will fit in a 32-bit number, so there's
> > no need for the ll.
>
> Yes, but compiled by 32bit too, right ?
> Without this "ll", 32bit compiler say
>
> warning: this decimal constant is unsigned only in ISO C90
That's right. How about 409600UL then, to force unsigned integer types ?
Or possibly even better, 4096 * 1000 * 1000UL to make it more readable ?
> # anyway, I will add this assumption (= used only by 64bit CPU)
> # on comment to avoid future confusion
>
> > I think you can then drop the output >= 40 check inside the inner
> > fdpll loop, as the output frequency can't be higher than 4GHz if the VCO
> > frequency isn't.
>
> I think code has
>
> if (output >= 4)
>
> This is 400MHz, not 4GHz
You're right, my bad. Maybe I should write it 400 * 1000 * 1000 :-)
> >>for (fdpll = 1; fdpll < 32; fdpll++) {
> >>unsigned long output;
> >
> > The output frequency on the line below can be calculated with
> >
> > output = fvco / 2 / (fdpll + 1)
> >
> > to avoid the multiplication by (n + 1) and division by (m + 1).
>
> It is nice idea to avoid extra calculation.
> I will use this idea, and add extrate comment to avoid confusion
Thank you.
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/ttm: enable eviction for Per-VM-BO
Change-Id: I0c6ece0decd18d30ccc94e5c7ca106d351941c62
Signed-off-by: Roger He
---
drivers/gpu/drm/ttm/ttm_bo.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 098b22e..ba5b486 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -707,7 +707,6 @@ bool ttm_bo_eviction_valuable(struct ttm_buffer_object *bo,
EXPORT_SYMBOL(ttm_bo_eviction_valuable);
static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
- struct reservation_object *resv,
uint32_t mem_type,
const struct ttm_place *place,
struct ttm_operation_ctx *ctx)
@@ -722,8 +721,9 @@ static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
spin_lock(&glob->lru_lock);
for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
list_for_each_entry(bo, &man->lru[i], lru) {
- if (bo->resv == resv) {
- if (list_empty(&bo->ddestroy))
+ if (bo->resv == ctx->resv) {
+ if (!ctx->allow_reserved_eviction &&
+ list_empty(&bo->ddestroy))
continue;
} else {
locked = reservation_object_trylock(bo->resv);
@@ -835,7 +835,7 @@ static int ttm_bo_mem_force_space(struct ttm_buffer_object
*bo,
return ret;
if (mem->mm_node)
break;
- ret = ttm_mem_evict_first(bdev, bo->resv, mem_type, place, ctx);
+ ret = ttm_mem_evict_first(bdev, mem_type, place, ctx);
if (unlikely(ret != 0))
return ret;
} while (1);
@@ -1332,8 +1332,7 @@ static int ttm_bo_force_list_clean(struct ttm_bo_device
*bdev,
for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
while (!list_empty(&man->lru[i])) {
spin_unlock(&glob->lru_lock);
- ret = ttm_mem_evict_first(bdev, NULL, mem_type,
- NULL, &ctx);
+ ret = ttm_mem_evict_first(bdev, mem_type, NULL, &ctx);
if (ret)
return ret;
spin_lock(&glob->lru_lock);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
