Re: [PATCH 1/6] drm: include drm_device.h from drm_legacy.h
On Thu, 27 Dec 2018, Daniel Vetter wrote: > On Thu, Dec 27, 2018 at 05:04:20PM +0100, Daniel Vetter wrote: >> On Thu, Dec 27, 2018 at 02:56:36PM +0200, Jani Nikula wrote: >> > Make it easier to drop drmP.h includes. >> > >> > Cc: Sam Ravnborg >> > Cc: Daniel Vetter >> > Cc: Laurent Pinchart >> > Signed-off-by: Jani Nikula >> > --- >> > include/drm/drm_legacy.h | 1 + >> > 1 file changed, 1 insertion(+) >> > >> > diff --git a/include/drm/drm_legacy.h b/include/drm/drm_legacy.h >> > index 8fad66f88e4f..743d7e70c896 100644 >> > --- a/include/drm/drm_legacy.h >> > +++ b/include/drm/drm_legacy.h >> > @@ -2,6 +2,7 @@ >> > #define __DRM_DRM_LEGACY_H__ >> > >> > #include >> > +#include >> >> From a quick look, shouldn't a >> >> struct drm_device; >> >> forward decl be enough? You might need a pile more forward decl, but >> that's all drm_device.h seems to pull in that drm_legacy.h needs. > > Reviewed-by: Daniel Vetter with the forward decl > (assuming it all works out). The forward declaration is not enough, there's a &dev->maplist reference in the static inline drm_legacy_findmap(). BR, Jani. > -Daniel > >> -Daniel >> > >> > /* >> > * Legacy driver interfaces for the Direct Rendering Manager >> > -- >> > 2.11.0 >> > >> >> -- >> Daniel Vetter >> Software Engineer, Intel Corporation >> http://blog.ffwll.ch -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm: forward declare struct drm_file in drm_syncobj.h
Make it easier to drop drmP.h includes. Switch from "" to <> includes while at it. v2: forward declare instead of including drm_file.h (Daniel) Cc: Sam Ravnborg Cc: Daniel Vetter Cc: Laurent Pinchart Reviewed-by: Daniel Vetter Signed-off-by: Jani Nikula --- include/drm/drm_syncobj.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/include/drm/drm_syncobj.h b/include/drm/drm_syncobj.h index 7c6ed845c70d..0311c9fdbd2f 100644 --- a/include/drm/drm_syncobj.h +++ b/include/drm/drm_syncobj.h @@ -26,7 +26,9 @@ #ifndef __DRM_SYNCOBJ_H__ #define __DRM_SYNCOBJ_H__ -#include "linux/dma-fence.h" +#include + +struct drm_file; /** * struct drm_syncobj - sync object. -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109163] employee module is not working
https://bugs.freedesktop.org/show_bug.cgi?id=109163 Bug ID: 109163 Summary: employee module is not working Product: DRI Version: XOrg git Hardware: All OS: All Status: NEW Severity: major Priority: medium Component: DRM/amdkfd Assignee: dri-devel@lists.freedesktop.org Reporter: bhawanawadalkar...@gmail.com after filling all the details modules failed to create new employee. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109163] employee module is not working
https://bugs.freedesktop.org/show_bug.cgi?id=109163 bhawanawadalkar...@gmail.com changed: What|Removed |Added QA Contact||choudhari@gmail.com -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109163] employee module is not working
https://bugs.freedesktop.org/show_bug.cgi?id=109163 bhawanawadalkar...@gmail.com changed: What|Removed |Added Assignee|dri-devel@lists.freedesktop |pujabanage...@gmail.com |.org| -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: avoid division by zero on skl_calc_wrpll_link
On Mon, 17 Dec 2018, Yang Xiao wrote:
> From: Young Xiao
>
> If for some unexpected reason the registers all read zero it's better
> to WARN and return instead of dividing by zero and completely freezing
> the machine.
>
> See commit 0e005888b833 ("drm/i915: avoid division by zero on
> cnl_calc_wrpll_link") for detail.
>
> Signed-off-by: Young Xiao
Pushed to drm-intel-next-queued, thanks for the patch.
BR,
Jani.
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 5186cd7..cfa7d6f 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1360,6 +1360,9 @@ static int skl_calc_wrpll_link(struct drm_i915_private
> *dev_priv,
> dco_freq += (((cfgcr1_val & DPLL_CFGCR1_DCO_FRACTION_MASK) >> 9) * 24 *
> 1000) / 0x8000;
>
> + if (WARN_ON(p0 == 0 || p1 == 0 || p2 == 0))
> + return 0;
> +
> return dco_freq / (p0 * p1 * p2 * 5);
> }
--
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 9/9] MAINTAINERS: Add maintainer for arm komeda driver
On Mon, Dec 24, 2018 at 02:05:43PM +0100, Daniel Vetter wrote: > On Mon, Dec 24, 2018 at 1:33 PM Liviu Dudau wrote: > > > > On Fri, Dec 21, 2018 at 10:01:06AM +, james qian wang (Arm Technology > > China) wrote: > > > v2: Adjusted the position of KOMEDA by alphabetical order > > > > > > Signed-off-by: James (Qian) Wang > > > > Acked-by: Liviu Dudau > > > > Best regards, > > Liviu > > > > > --- > > > MAINTAINERS | 9 + > > > 1 file changed, 9 insertions(+) > > > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > > index 254b7b267731..e48c2e5fd29f 100644 > > > --- a/MAINTAINERS > > > +++ b/MAINTAINERS > > > @@ -1124,6 +1124,15 @@ S: Supported > > > F: drivers/gpu/drm/arm/hdlcd_* > > > F: Documentation/devicetree/bindings/display/arm,hdlcd.txt > > > > > > +ARM KOMEDA DRM-KMS DRIVER > > > +M: James (Qian) Wang > > > +M: Mali DP Maintainers > > > +S: Supported > > > +F: drivers/gpu/drm/arm/display/include/ > > > +F: drivers/gpu/drm/arm/display/komeda/ > > > +F: Documentation/devicetree/bindings/display/arm/arm,komeda.txt > > > +F: Documentation/gpu/komeda-kms.rst > > Mentioning the git tree would be good. And I guess you'll do some kind > of group maintainership? Probably still good if you send out a > dedicated/topic pull request for this new driver, but from then on > it's all in the same git repo. > -Daniel Hi Daniel: The komeda driver will use an Arm-hosted tree: git git://linux-arm.org/linux-ld.git for-upstream/mali-dp Same as other arm display drivers. And Liviu Dudau will help to send the pull request to merge this topic into drm-next. And we are planning to adopt a group maintainership and migrate towards drm-misc-next, but we just need to have enough people and enough experience with working with upstream before we jump all in. Last a T: entry will be added in the next version. T: git git://linux-arm.org/linux-ld.git for-upstream/mali-dp James > > > + > > > ARM MALI-DP DRM DRIVER > > > M: Liviu Dudau > > > M: Brian Starkey > > > -- > > > 2.17.1 > > > > > > > -- > > > > | I would like to | > > | fix the world, | > > | but they're not | > > | giving me the | > > \ source code! / > > --- > > ¯\_(ツ)_/¯ > > > > -- > 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
Re: [Intel-gfx] [PATCH v3 0/3] CRTC background color
Am Fr., 28. Dez. 2018, 02:09 hat Stéphane Marchesin geschrieben: > On Thu, Dec 27, 2018 at 4:45 PM Matt Roper > wrote: > > > > On Thu, Dec 27, 2018 at 04:22:28PM -0800, Stéphane Marchesin wrote: > > > On Thu, Dec 27, 2018 at 3:49 PM Li, Wei C wrote: > > > > > > > > Matt, > > > > > > > > Is that possible for you to get some time to review > https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1387366 > > and confirm the FROMLIST change if it looks good to you so we could move > forward? > > > > > > > > > > To be more precise, I am trying to assess what's needed before this > > > patch goes usptream, and in particular, I'd like to know if we are > > > blocked on any Chrome-side thing. > > > > > > Stéphane > > > > > > > Hi Stéphane. On the Chrome side of things, I believe we need an Ack > > from the ChromeOS userspace team on the ABI, plus a pointer to where the > > final, reviewed userspace patches are that correspond to it (mailing > > list link or gerrit or whatever). I have an old gerrit link to some > > in-development chromium/ozone patches for this from November 2nd, but > > I'm not sure if there's a newer one now. > > IMO from user space the ABI is good. I think the question is more > whether other hw would be fine with it. For example if we notice that > other platforms can only do black as a background color, how can we > make this API standard. Hopefully other folks can chime in here about > other hw capabilities. black background is already the default, so "no prop" = "black background". The problem is a bit figuring out whether you can make the primary plane non-fullscreen, which atm is a TEST_ONLY guessing game for userspace. We've discussed some "can_scale" and "can_position" properties for that, but aside from reworking the helpers to check plane updates nothing happened. -Daniel > > Stéphane > > > > > > Aside from satisfying the ABI/userspace requirements, we still need all > > the patches to get reviewed by the upstream kernel devs. An older > > version of patch #2 has a r-b from Sean, but patches 1 and 3 haven't > > been accepted yet. Actually it looks like I never sent the latest > > version of my series that incorporates some additional feedback from > > Brian Starkey to the list; I'll do that tomorrow. I think a lot of > > people are still out on holiday vacation at the moment, so if necessary > > I'll start pinging IRC for reviews in a week or two when people are back > > in office. > > > > > > Matt > > > > > > > > > BTW, I've backported your kernel patch into Chrome OS and verified > it using the TEST=drm-tests/atomictest -t crtc_background_color on a Google > Pixelbook with KBL graphics. > > > > > > > > Thanks, > > > > Wei > > > > > > > > -Original Message- > > > > From: Stéphane Marchesin [mailto:marc...@chromium.org] > > > > Sent: Thursday, December 27, 2018 3:27 PM > > > > To: Roper, Matthew D > > > > Cc: intel-gfx ; Li, Wei C < > wei.c...@intel.com>; dri-devel > > > > Subject: Re: [Intel-gfx] [PATCH v3 0/3] CRTC background color > > > > > > > > Hey, > > > > > > > > Is there anything missing on the Chrome side to move forward with > this series? > > > > > > > > Stéphane > > > > > > > > On Thu, Nov 15, 2018 at 2:14 PM Matt Roper < > matthew.d.ro...@intel.com> wrote: > > > > > > > > > > Third version of the series previously posted here: > > > > > > > > > > > https://lists.freedesktop.org/archives/intel-gfx/2018-November/181777. > > > > > html > > > > > > > > > > This version incorporates review feedback from Ville and Sean Paul. > > > > > > > > > > The first patch here can be merged whenever it receives review > approval. > > > > > The second and third patches still need to wait for opensource > > > > > userspace to be ready before merging (there's ChromeOS work > underway). > > > > > > > > > > Cc: dri-devel@lists.freedesktop.org > > > > > Cc: Wei C Li > > > > > Cc: Sean Paul > > > > > Cc: Ville Syrjälä > > > > > > > > > > Matt Roper (3): > > > > > drm/i915: Force background color to black for gen9+ (v2) > > > > > drm: Add CRTC background color property (v2) > > > > > drm/i915/gen9+: Add support for pipe background color (v3) > > > > > > > > > > drivers/gpu/drm/drm_atomic_state_helper.c | 1 + > > > > > drivers/gpu/drm/drm_atomic_uapi.c | 5 > > > > > drivers/gpu/drm/drm_blend.c | 21 +--- > > > > > drivers/gpu/drm/drm_mode_config.c | 6 + > > > > > drivers/gpu/drm/i915/i915_debugfs.c | 9 +++ > > > > > drivers/gpu/drm/i915/i915_reg.h | 6 + > > > > > drivers/gpu/drm/i915/intel_display.c | 40 > +++ > > > > > include/drm/drm_blend.h | 1 + > > > > > include/drm/drm_crtc.h| 17 + > > > > > include/drm/drm_mode_config.h | 5 > > > > > include/uapi/drm/drm_mode.h | 28 > ++ > > > > > 11 files changed, 136 ins
Re: [PATCH v3 9/9] MAINTAINERS: Add maintainer for arm komeda driver
On Fri, Dec 28, 2018 at 12:15 PM james qian wang (Arm Technology China) wrote: > > On Mon, Dec 24, 2018 at 02:05:43PM +0100, Daniel Vetter wrote: > > On Mon, Dec 24, 2018 at 1:33 PM Liviu Dudau wrote: > > > > > > On Fri, Dec 21, 2018 at 10:01:06AM +, james qian wang (Arm Technology > > > China) wrote: > > > > v2: Adjusted the position of KOMEDA by alphabetical order > > > > > > > > Signed-off-by: James (Qian) Wang > > > > > > Acked-by: Liviu Dudau > > > > > > Best regards, > > > Liviu > > > > > > > --- > > > > MAINTAINERS | 9 + > > > > 1 file changed, 9 insertions(+) > > > > > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > > > index 254b7b267731..e48c2e5fd29f 100644 > > > > --- a/MAINTAINERS > > > > +++ b/MAINTAINERS > > > > @@ -1124,6 +1124,15 @@ S: Supported > > > > F: drivers/gpu/drm/arm/hdlcd_* > > > > F: Documentation/devicetree/bindings/display/arm,hdlcd.txt > > > > > > > > +ARM KOMEDA DRM-KMS DRIVER > > > > +M: James (Qian) Wang > > > > +M: Mali DP Maintainers > > > > +S: Supported > > > > +F: drivers/gpu/drm/arm/display/include/ > > > > +F: drivers/gpu/drm/arm/display/komeda/ > > > > +F: Documentation/devicetree/bindings/display/arm/arm,komeda.txt > > > > +F: Documentation/gpu/komeda-kms.rst > > > > Mentioning the git tree would be good. And I guess you'll do some kind > > of group maintainership? Probably still good if you send out a > > dedicated/topic pull request for this new driver, but from then on > > it's all in the same git repo. > > -Daniel > > Hi Daniel: > > The komeda driver will use an Arm-hosted tree: > > git git://linux-arm.org/linux-ld.git for-upstream/mali-dp > > Same as other arm display drivers. And Liviu Dudau will help to send the pull > request to merge this topic into drm-next. > > And we are planning to adopt a group maintainership and migrate towards > drm-misc-next, > but we just need to have enough people and enough experience with working > with upstream > before we jump all in. arm drivers are probably a bit too big for drm-misc, but you could use the same tooling to maintain a drm-arm tree. I guess that's the idea? -Daniel > Last a T: entry will be added in the next version. > > T: git git://linux-arm.org/linux-ld.git for-upstream/mali-dp > > James > > > > > + > > > > ARM MALI-DP DRM DRIVER > > > > M: Liviu Dudau > > > > M: Brian Starkey > > > > -- > > > > 2.17.1 > > > > > > > > > > -- > > > > > > | I would like to | > > > | fix the world, | > > > | but they're not | > > > | giving me the | > > > \ source code! / > > > --- > > > ¯\_(ツ)_/¯ > > > > > > > > -- > > Daniel Vetter > > Software Engineer, Intel Corporation > > +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- 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
Re: [PATCH 6/6] drm/i915: drop all drmP.h includes
On Thu, Dec 27, 2018 at 06:27:53PM +0200, Jani Nikula wrote: > On Thu, 27 Dec 2018, Daniel Vetter wrote: > > I guess next up would be to split up i915_drv.h and intel_drv.h and see > > how much our driver is a spaghetti mess where everything needs everything > > else :-) > > In general this got me wondering how self-contained the header files > really need to be. Turns out even isn't self-contained, > it fails on do_div() for my config if isn't included some > other route. Didn't dig deep, but by the looks of it this is not a new > breakage (if you can call it that). In a reasonable project I'd urge you to send the fix, but given my last endevaour into touching linux/kernel.h I can't really recommend that :-/ -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: [RFC PATCH 1/2] drm/fb-helper: Bring back workaround for bugs of SDL 1.2
On Fri, Dec 28, 2018 at 04:26:56AM +0500, Ivan Mironov wrote:
> On Thu, 2018-12-27 at 13:00 +0100, Daniel Vetter wrote:
> > > + /*
> > > + * Workaround for SDL 1.2, which is known to be setting all pixel format
> > > + * fields values to zero in some cases. We treat this situation as a
> > > + * kind of "use some reasonable autodetected values".
> > > + */
> > > + if (!var->red.offset && !var->green.offset&&
> > > + !var->blue.offset&& !var->transp.offset &&
> > > + !var->red.length && !var->green.length&&
> > > + !var->blue.length&& !var->transp.length &&
> > > + !var->red.msb_right && !var->green.msb_right &&
> > > + !var->blue.msb_right && !var->transp.msb_right) {
> > > + u8 depth;
> > > +
> > > + /*
> > > + * There is no way to guess the right value for depth when
> > > + * bpp is 16 or 32. So we just restore the behaviour previously
> > > + * introduced here by commit 785b93ef8c309. In fact, this was
> > > + * implemented even earlier in various device drivers.
> > > + */
> > > + switch (var->bits_per_pixel) {
> > > + case 16:
> > > + depth = 15;
> > > + break;
> > > + case 32:
> > > + depth = 24;
> > > + break;
> > > + default:
> > > + depth = var->bits_per_pixel;
> > > + break;
> > > + }
> >
> > The guesswork here looks fishy. We should still have the drm-side format,
> > and should use that.
>
> This existed for a very long time until problematic commit was applied.
> And there is a clear evidence that it was actually used by
> applications.
I'm not against guessing this stuff, but we know have much better format
handling code than when this code was originally written. I just want to
use that (like it's used everywhere else in this file now). fb->format
gives you the right depth, no guessing needed at all.
And if you guess wrong here, you'll fail in these format checks later on.
-Daniel
>
> > Otherwise the patches look good I think, but they
> > need a Fixes: tag and cc: stable so backporters know what to do with
> > these.
> >
>
> I added "cc: stable" into the regression fix. Also added more info into
> the commit messages. See the PATCH v1 in the mailing list.
>
> Thanks.
>
>
>
--
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 v1 2/2] drm/fb-helper: Ignore the value of fb_var_screeninfo.pixclock
On Fri, Dec 28, 2018 at 04:13:08AM +0500, Ivan Mironov wrote:
> Strict requirement of pixclock to be zero breaks support of SDL 1.2
> which contains hardcoded table of supported video modes with non-zero
> pixclock values[1].
>
> To better understand which pixclock values are considered valid and how
> driver should handle these values, I briefly examined few existing fbdev
> drivers and documentation in Documentation/fb/. And it looks like there
> are no strict rules on that and actual behaviour varies:
>
> * some drivers treat (pixclock == 0) as "use defaults" (uvesafb.c);
> * some treat (pixclock == 0) as invalid value which leads to
> -EINVAL (clps711x-fb.c);
> * some pass converted pixclock value to hardware (uvesafb.c);
> * some are trying to find nearest value from predefined table
> (vga16fb.c, video_gx.c).
>
> Given this, I believe that it should be safe to just ignore this value if
> changing is not supported. It seems that any portable fbdev application
> which was not written only for one specific device working under one
> specific kernel version should not rely on any particular behaviour of
> pixclock anyway.
>
> However, while enabling SDL1 applications to work out of the box when
> there is no /etc/fb.modes with valid settings, this change affects the
> video mode choosing logic in SDL. Depending on current screen
> resolution, contents of /etc/fb.modes and resolution requested by
> application, this may lead to user-visible difference (not always):
> image will be displayed in a right way, but it will be aligned to the
> left instead of center. There is no "right behaviour" here as well, as
> emulated fbdev, opposing to old fbdev drivers, simply ignores any
> requsts of video mode changes with resolutions smaller than current.
>
> Feel free to NAK this patch if you think that it causes breakage of
> user-space =).
It's a regression, we don't nack regression fixes :-)
> The easiest way to reproduce this problem is to install sdl-sopwith[2],
> remove /etc/fb.modes file if it exists, and then try to run sopwith
> from console without X. At least in Fedora 29, sopwith may be simply
> installed from standard repositories.
>
> [1] SDL 1.2.15 source code, src/video/fbcon/SDL_fbvideo.c, vesa_timings
> [2] http://sdl-sopwith.sourceforge.net/
>
> Signed-off-by: Ivan Mironov
I thought this is also a regression fix, so also needs Fixes: and cc:
stable?
-Daniel
> ---
> drivers/gpu/drm/drm_fb_helper.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index aff576c3c4fb..b95a0c23c7c8 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -1690,9 +1690,14 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo
> *var,
> struct drm_fb_helper *fb_helper = info->par;
> struct drm_framebuffer *fb = fb_helper->fb;
>
> - if (var->pixclock != 0 || in_dbg_master())
> + if (in_dbg_master())
> return -EINVAL;
>
> + if (var->pixclock != 0) {
> + DRM_DEBUG("fbdev emulation doesn't support changing the pixel
> clock, value of pixclock is ignored\n");
> + var->pixclock = 0;
> + }
> +
> if ((drm_format_info_block_width(fb->format, 0) > 1) ||
> (drm_format_info_block_height(fb->format, 0) > 1))
> return -EINVAL;
> --
> 2.20.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vc4: Allow fb modifiers early enough to fill IN_FORMATS property
On Thu, Dec 27, 2018 at 03:36:20PM -0800, Eric Anholt wrote: > Paul Kocialkowski writes: > > > The KMS mode_config elements are currently configured in vc4_kms_load, > > that is called after all components are binded (component_bind_all). > > However, the CRTC component (for the Pixel Valve) needs to access the > > allow_fb_modifiers element at bind time, when initializing its planes > > through drm_universal_plane_init. > > > > This helpers checks allow_fb_modifiers to decide whether to fill the > > IN_FORMATS property. Because allow_fb_modifiers is still set to false > > at this point, the property is never filled and userspace cannot > > retrieve the combination of supported formats and modifiers. > > > > Fix this by setting allow_fb_modifiers right after calling > > drm_mode_config_init (which initializes the structure), before binding > > the components of the driver. > > This makes me wonder if the flag could be removed and replaced with "did > non-NULL modifiers get supplied to plane init?" I think I've tripped > over this flag in other KMS hacking, too. Sounds like a good idea to me. Just setting it in plane_init should work I think ... -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/6] drm: include drm_device.h from drm_legacy.h
On Fri, Dec 28, 2018 at 10:23:00AM +0200, Jani Nikula wrote: > On Thu, 27 Dec 2018, Daniel Vetter wrote: > > On Thu, Dec 27, 2018 at 05:04:20PM +0100, Daniel Vetter wrote: > >> On Thu, Dec 27, 2018 at 02:56:36PM +0200, Jani Nikula wrote: > >> > Make it easier to drop drmP.h includes. > >> > > >> > Cc: Sam Ravnborg > >> > Cc: Daniel Vetter > >> > Cc: Laurent Pinchart > >> > Signed-off-by: Jani Nikula > >> > --- > >> > include/drm/drm_legacy.h | 1 + > >> > 1 file changed, 1 insertion(+) > >> > > >> > diff --git a/include/drm/drm_legacy.h b/include/drm/drm_legacy.h > >> > index 8fad66f88e4f..743d7e70c896 100644 > >> > --- a/include/drm/drm_legacy.h > >> > +++ b/include/drm/drm_legacy.h > >> > @@ -2,6 +2,7 @@ > >> > #define __DRM_DRM_LEGACY_H__ > >> > > >> > #include > >> > +#include > >> > >> From a quick look, shouldn't a > >> > >> struct drm_device; > >> > >> forward decl be enough? You might need a pile more forward decl, but > >> that's all drm_device.h seems to pull in that drm_legacy.h needs. > > > > Reviewed-by: Daniel Vetter with the forward decl > > (assuming it all works out). > > The forward declaration is not enough, there's a &dev->maplist reference > in the static inline drm_legacy_findmap(). Missed that, despite that I tried checking for static inlines. And a static inline for a O(n) lookup ... tempted to just deinline that. Reviewed-by: Daniel Vetter on either your v1 or a patch that deinlines the offending function and just uses a forward decl. Cheers, Daniel > > BR, > Jani. > > > -Daniel > > > >> -Daniel > >> > > >> > /* > >> > * Legacy driver interfaces for the Direct Rendering Manager > >> > -- > >> > 2.11.0 > >> > > >> > >> -- > >> Daniel Vetter > >> Software Engineer, Intel Corporation > >> http://blog.ffwll.ch > > -- > Jani Nikula, Intel Open Source Graphics Center -- 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 v1 1/2] drm/fb-helper: Bring back workaround for bugs of SDL 1.2
On Fri, Dec 28, 2018 at 04:13:07AM +0500, Ivan Mironov wrote:
> SDL 1.2 sets all fields related to the pixel format to zero in some
> cases[1]. Prior to commit db05c48197759 ("drm: fb-helper: Reject all
> pixel format changing requests"), there was an unintentional workaround
> for this that existed for more than a decade. First in device-specific DRM
> drivers, then here in drm_fb_helper.c.
>
> Previous code containing this workaround just ignores pixel format fields
> from userspace code. Not a good thing either, as this way, driver may
> silently use pixel format different from what client actually requested,
> and this in turn will lead to displaying garbage on the screen. I think
> that returning EINVAL to userspace in this particular case is the right
> option, so I decided to left code from problematic commit untouched
> instead of just reverting it entirely.
>
> Here is the steps required to reproduce this problem exactly:
> 1) Compile fceux[2] with SDL 1.2.15 and without GTK or OpenGL
> support. SDL should be compiled with fbdev support (which is
> on by default).
> 2) Create /etc/fb.modes with following contents (values seems
> not used, and just required to trigger problematic code in
> SDL):
>
> mode "test"
> geometry 1 1 1 1 1
> timings 1 1 1 1 1 1 1
> endmode
>
> 3) Create ~/.fceux/fceux.cfg with following contents:
>
> SDL.Hotkeys.Quit = 27
> SDL.DoubleBuffering = 1
>
> 4) Ensure that screen resolution is at least 1280x960 (e.g.
> append "video=Virtual-1:1280x960-32" to the kernel cmdline
> for qemu/QXL).
>
> 5) Try to run fceux on VT with some ROM file[3]:
>
> # ./fceux color_test.nes
>
> [1] SDL 1.2.15 source code, src/video/fbcon/SDL_fbvideo.c,
> FB_SetVideoMode()
> [2] http://www.fceux.com
> [3] Example ROM:
> https://github.com/bokuweb/rustynes/blob/master/roms/color_test.nes
>
> Reported-by: saahriktu
> Suggested-by: saahriktu
> Cc: sta...@vger.kernel.org
> Fixes: db05c48197759 ("drm: fb-helper: Reject all pixel format changing
> requests")
> Signed-off-by: Ivan Mironov
> ---
> drivers/gpu/drm/drm_fb_helper.c | 146
> 1 file changed, 93 insertions(+), 53 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index d3af098b0922..aff576c3c4fb 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -1621,6 +1621,64 @@ static bool drm_fb_pixel_format_equal(const struct
> fb_var_screeninfo *var_1,
> var_1->transp.msb_right == var_2->transp.msb_right;
> }
>
> +static void drm_fb_helper_fill_pixel_fmt(struct fb_var_screeninfo *var,
> + u8 depth)
> +{
> + switch (depth) {
> + case 8:
> + var->red.offset = 0;
> + var->green.offset = 0;
> + var->blue.offset = 0;
> + var->red.length = 8; /* 8bit DAC */
> + var->green.length = 8;
> + var->blue.length = 8;
> + var->transp.offset = 0;
> + var->transp.length = 0;
> + break;
> + case 15:
> + var->red.offset = 10;
> + var->green.offset = 5;
> + var->blue.offset = 0;
> + var->red.length = 5;
> + var->green.length = 5;
> + var->blue.length = 5;
> + var->transp.offset = 15;
> + var->transp.length = 1;
> + break;
> + case 16:
> + var->red.offset = 11;
> + var->green.offset = 5;
> + var->blue.offset = 0;
> + var->red.length = 5;
> + var->green.length = 6;
> + var->blue.length = 5;
> + var->transp.offset = 0;
> + break;
> + case 24:
> + var->red.offset = 16;
> + var->green.offset = 8;
> + var->blue.offset = 0;
> + var->red.length = 8;
> + var->green.length = 8;
> + var->blue.length = 8;
> + var->transp.offset = 0;
> + var->transp.length = 0;
> + break;
> + case 32:
> + var->red.offset = 16;
> + var->green.offset = 8;
> + var->blue.offset = 0;
> + var->red.length = 8;
> + var->green.length = 8;
> + var->blue.length = 8;
> + var->transp.offset = 24;
> + var->transp.length = 8;
> + break;
> + default:
> + break;
> + }
> +}
> +
> /**
> * drm_fb_helper_check_var - implementation for &fb_ops.fb_check_var
> * @var: screeninfo to check
> @@ -1654,6 +1712,40 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo
> *var,
> return -EINVAL;
> }
>
> + /*
> + * Workaround for SDL 1.2, which is known to b
Re: [PATCH 01/10] drm/etnaviv: move job context pointer to etnaviv_gem_submit
Am Mi., 19. Dez. 2018 um 15:45 Uhr schrieb Lucas Stach :
>
> The context isn't really related to the cmdbuf, but is a property of
> the job. This has been missed when moving to a properly refcounted
> etnaviv_gem_submit.
>
> Signed-off-by: Lucas Stach
Reviewed-by: Christian Gmeiner
> ---
> drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.h | 2 --
> drivers/gpu/drm/etnaviv/etnaviv_gem.h| 1 +
> drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 2 +-
> drivers/gpu/drm/etnaviv/etnaviv_sched.c | 2 +-
> 4 files changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.h
> b/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.h
> index acb68c698363..4d5d1a77eb2a 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.h
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.h
> @@ -15,8 +15,6 @@ struct etnaviv_perfmon_request;
> struct etnaviv_cmdbuf {
> /* suballocator this cmdbuf is allocated from */
> struct etnaviv_cmdbuf_suballoc *suballoc;
> - /* user context key, must be unique between all active users */
> - struct etnaviv_file_private *ctx;
> /* cmdbuf properties */
> int suballoc_offset;
> void *vaddr;
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.h
> b/drivers/gpu/drm/etnaviv/etnaviv_gem.h
> index 76079c2291f8..f0abb744ef95 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gem.h
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.h
> @@ -95,6 +95,7 @@ struct etnaviv_gem_submit_bo {
> struct etnaviv_gem_submit {
> struct drm_sched_job sched_job;
> struct kref refcount;
> + struct etnaviv_file_private *ctx;
> struct etnaviv_gpu *gpu;
> struct dma_fence *out_fence, *in_fence;
> int out_fence_id;
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> index 983e67f19e45..86c005ab0c91 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> @@ -506,7 +506,7 @@ int etnaviv_ioctl_gem_submit(struct drm_device *dev, void
> *data,
> if (ret)
> goto err_submit_objects;
>
> - submit->cmdbuf.ctx = file->driver_priv;
> + submit->ctx = file->driver_priv;
> submit->exec_state = args->exec_state;
> submit->flags = args->flags;
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
> b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
> index e5a9fae31ab7..1bb076f8b2b7 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
> @@ -150,7 +150,7 @@ int etnaviv_sched_push_job(struct drm_sched_entity
> *sched_entity,
> mutex_lock(&submit->gpu->fence_lock);
>
> ret = drm_sched_job_init(&submit->sched_job, sched_entity,
> -submit->cmdbuf.ctx);
> +submit->ctx);
> if (ret)
> goto out_unlock;
>
> --
> 2.19.1
>
--
greets
--
Christian Gmeiner, MSc
https://christian-gmeiner.info
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/6] drm/i915: drmP.h include removal w/ drm prep work
Hi Jani. On Thu, Dec 27, 2018 at 02:56:35PM +0200, Jani Nikula wrote: > First make some drm headers self-contained, removing the implicit > dependency on a previous drmP.h include. Then remove all drmP.h includes > from drm/i915. > > Inspired by Sam's series [1]. Theres a one line trivial conflict between > that one and this series in drm_file.h (patch 3), but I'm keeping this > series self-contained. Should be easy enough to resolve. > > I'm fine with merging the first 5 through either drm-misc or drm-intel, > but I'd rather merge the last one through drm-intel. > > BR, > Jani. > > Cc: Sam Ravnborg > Cc: Daniel Vetter > Cc: Laurent Pinchart > > > Jani Nikula (6): > drm: include drm_device.h from drm_legacy.h > drm: include kernel.h and agp_backend.h from intel-gtt.h > drm: include idr.h from drm_file.h > drm: include types.h from drm_hdcp.h > drm: include drm_file.h from drm_syncobj.h > drm/i915: drop all drmP.h includes Series looks good. Could I ask you to include the following patch in your series: diff --git a/include/drm/drm_framebuffer.h b/include/drm/drm_framebuffer.h index c50502c656e5..112944eed49d 100644 --- a/include/drm/drm_framebuffer.h +++ b/include/drm/drm_framebuffer.h @@ -23,8 +23,10 @@ #ifndef __DRM_FRAMEBUFFER_H__ #define __DRM_FRAMEBUFFER_H__ -#include #include +#include +#include + #include struct drm_framebuffer; Without this all users of drm_framebuffer.h needs to include linux/sched.h The only thing required from sched.h is TASK_COMM_LEN but I did not find any good way to avoid this dependency. (I sorted the includes in alphabetic order too). No need to credit me in any way for this trivial fix. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm: un-inline drm_legacy_findmap()
Also include drm_hashtab.h and add struct drm_device forward declaration
in drm_legacy.h to make it more self-contained. Make it easier to drop
drmP.h includes.
v2: avoid including drm_device.h by un-inlining (Daniel)
Cc: Sam Ravnborg
Cc: Daniel Vetter
Cc: Laurent Pinchart
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_bufs.c | 11 +++
include/drm/drm_legacy.h | 14 --
2 files changed, 15 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index d7d10cabb9bb..a39ab2193bfe 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -377,6 +377,17 @@ int drm_legacy_addmap(struct drm_device *dev,
resource_size_t offset,
}
EXPORT_SYMBOL(drm_legacy_addmap);
+struct drm_local_map *drm_legacy_findmap(struct drm_device *dev,
+unsigned int token)
+{
+ struct drm_map_list *_entry;
+ list_for_each_entry(_entry, &dev->maplist, head)
+ if (_entry->user_token == token)
+ return _entry->map;
+ return NULL;
+}
+EXPORT_SYMBOL(drm_legacy_findmap);
+
/**
* Ioctl to specify a range of memory that is available for mapping by a
* non-root process.
diff --git a/include/drm/drm_legacy.h b/include/drm/drm_legacy.h
index 8fad66f88e4f..3e99ab69c122 100644
--- a/include/drm/drm_legacy.h
+++ b/include/drm/drm_legacy.h
@@ -2,6 +2,9 @@
#define __DRM_DRM_LEGACY_H__
#include
+#include
+
+struct drm_device;
/*
* Legacy driver interfaces for the Direct Rendering Manager
@@ -156,6 +159,7 @@ struct drm_map_list {
int drm_legacy_addmap(struct drm_device *d, resource_size_t offset,
unsigned int size, enum drm_map_type type,
enum drm_map_flags flags, struct drm_local_map **map_p);
+struct drm_local_map *drm_legacy_findmap(struct drm_device *dev, unsigned int
token);
void drm_legacy_rmmap(struct drm_device *d, struct drm_local_map *map);
int drm_legacy_rmmap_locked(struct drm_device *d, struct drm_local_map *map);
void drm_legacy_master_rmmaps(struct drm_device *dev,
@@ -194,14 +198,4 @@ void drm_legacy_ioremap(struct drm_local_map *map, struct
drm_device *dev);
void drm_legacy_ioremap_wc(struct drm_local_map *map, struct drm_device *dev);
void drm_legacy_ioremapfree(struct drm_local_map *map, struct drm_device *dev);
-static inline struct drm_local_map *drm_legacy_findmap(struct drm_device *dev,
- unsigned int token)
-{
- struct drm_map_list *_entry;
- list_for_each_entry(_entry, &dev->maplist, head)
- if (_entry->user_token == token)
- return _entry->map;
- return NULL;
-}
-
#endif /* __DRM_DRM_LEGACY_H__ */
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/6] drm: include drm_device.h from drm_legacy.h
On Fri, 28 Dec 2018, Daniel Vetter wrote: > On Fri, Dec 28, 2018 at 10:23:00AM +0200, Jani Nikula wrote: >> On Thu, 27 Dec 2018, Daniel Vetter wrote: >> > On Thu, Dec 27, 2018 at 05:04:20PM +0100, Daniel Vetter wrote: >> >> On Thu, Dec 27, 2018 at 02:56:36PM +0200, Jani Nikula wrote: >> >> > Make it easier to drop drmP.h includes. >> >> > >> >> > Cc: Sam Ravnborg >> >> > Cc: Daniel Vetter >> >> > Cc: Laurent Pinchart >> >> > Signed-off-by: Jani Nikula >> >> > --- >> >> > include/drm/drm_legacy.h | 1 + >> >> > 1 file changed, 1 insertion(+) >> >> > >> >> > diff --git a/include/drm/drm_legacy.h b/include/drm/drm_legacy.h >> >> > index 8fad66f88e4f..743d7e70c896 100644 >> >> > --- a/include/drm/drm_legacy.h >> >> > +++ b/include/drm/drm_legacy.h >> >> > @@ -2,6 +2,7 @@ >> >> > #define __DRM_DRM_LEGACY_H__ >> >> > >> >> > #include >> >> > +#include >> >> >> >> From a quick look, shouldn't a >> >> >> >> struct drm_device; >> >> >> >> forward decl be enough? You might need a pile more forward decl, but >> >> that's all drm_device.h seems to pull in that drm_legacy.h needs. >> > >> > Reviewed-by: Daniel Vetter with the forward decl >> > (assuming it all works out). >> >> The forward declaration is not enough, there's a &dev->maplist reference >> in the static inline drm_legacy_findmap(). > > Missed that, despite that I tried checking for static inlines. And a > static inline for a O(n) lookup ... tempted to just deinline that. > > Reviewed-by: Daniel Vetter on either your v1 or a > patch that deinlines the offending function and just uses a forward decl. It'll still require drm_hashtab.h include, but less intrusive than drm_device.h I guess. Patch sent. BR, Jani. > > Cheers, Daniel > >> >> BR, >> Jani. >> >> > -Daniel >> > >> >> -Daniel >> >> > >> >> > /* >> >> > * Legacy driver interfaces for the Direct Rendering Manager >> >> > -- >> >> > 2.11.0 >> >> > >> >> >> >> -- >> >> Daniel Vetter >> >> Software Engineer, Intel Corporation >> >> http://blog.ffwll.ch >> >> -- >> Jani Nikula, Intel Open Source Graphics Center -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: un-inline drm_legacy_findmap()
On Fri, Dec 28, 2018 at 03:04:46PM +0200, Jani Nikula wrote:
> Also include drm_hashtab.h and add struct drm_device forward declaration
> in drm_legacy.h to make it more self-contained. Make it easier to drop
> drmP.h includes.
>
> v2: avoid including drm_device.h by un-inlining (Daniel)
>
> Cc: Sam Ravnborg
> Cc: Daniel Vetter
> Cc: Laurent Pinchart
> Signed-off-by: Jani Nikula
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_bufs.c | 11 +++
> include/drm/drm_legacy.h | 14 --
> 2 files changed, 15 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
> index d7d10cabb9bb..a39ab2193bfe 100644
> --- a/drivers/gpu/drm/drm_bufs.c
> +++ b/drivers/gpu/drm/drm_bufs.c
> @@ -377,6 +377,17 @@ int drm_legacy_addmap(struct drm_device *dev,
> resource_size_t offset,
> }
> EXPORT_SYMBOL(drm_legacy_addmap);
>
> +struct drm_local_map *drm_legacy_findmap(struct drm_device *dev,
> + unsigned int token)
> +{
> + struct drm_map_list *_entry;
> + list_for_each_entry(_entry, &dev->maplist, head)
> + if (_entry->user_token == token)
> + return _entry->map;
> + return NULL;
> +}
> +EXPORT_SYMBOL(drm_legacy_findmap);
> +
> /**
> * Ioctl to specify a range of memory that is available for mapping by a
> * non-root process.
> diff --git a/include/drm/drm_legacy.h b/include/drm/drm_legacy.h
> index 8fad66f88e4f..3e99ab69c122 100644
> --- a/include/drm/drm_legacy.h
> +++ b/include/drm/drm_legacy.h
> @@ -2,6 +2,9 @@
> #define __DRM_DRM_LEGACY_H__
>
> #include
> +#include
> +
> +struct drm_device;
>
> /*
> * Legacy driver interfaces for the Direct Rendering Manager
> @@ -156,6 +159,7 @@ struct drm_map_list {
> int drm_legacy_addmap(struct drm_device *d, resource_size_t offset,
> unsigned int size, enum drm_map_type type,
> enum drm_map_flags flags, struct drm_local_map **map_p);
> +struct drm_local_map *drm_legacy_findmap(struct drm_device *dev, unsigned
> int token);
> void drm_legacy_rmmap(struct drm_device *d, struct drm_local_map *map);
> int drm_legacy_rmmap_locked(struct drm_device *d, struct drm_local_map *map);
> void drm_legacy_master_rmmaps(struct drm_device *dev,
> @@ -194,14 +198,4 @@ void drm_legacy_ioremap(struct drm_local_map *map,
> struct drm_device *dev);
> void drm_legacy_ioremap_wc(struct drm_local_map *map, struct drm_device
> *dev);
> void drm_legacy_ioremapfree(struct drm_local_map *map, struct drm_device
> *dev);
>
> -static inline struct drm_local_map *drm_legacy_findmap(struct drm_device
> *dev,
> -unsigned int token)
> -{
> - struct drm_map_list *_entry;
> - list_for_each_entry(_entry, &dev->maplist, head)
> - if (_entry->user_token == token)
> - return _entry->map;
> - return NULL;
> -}
> -
> #endif /* __DRM_DRM_LEGACY_H__ */
> --
> 2.11.0
>
--
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
[Bug 108340] Ambient Occlusion in Two Point Hospital shows black spot artifacts
https://bugs.freedesktop.org/show_bug.cgi?id=108340 --- Comment #2 from wietse.joris...@gmail.com --- I am noticing the same issue, also running on max graphical settings. Ubuntu 18.10 Kernel 4.18.0-13-generic AMD RX 480 OpenGL version string: 4.4 (Compatibility Profile) Mesa 18.2.2 Steps followed: 1. Installed apitrace (sudo apt-get install apitrace) 2. Looked up the ID of Two Point Hospital (535930) 3. Ran the following command in terminal (DEBUGGER="apitrace trace" steam steam://rungameid/535930) 4. Once ingame with the Ambient Occlusion option active, I zoomed in and out and moved the camera around as this seems to exacerbate the black spots. 5. The trace file is stored next to the game executable (/home/username/.local/share/Steam/steamapps/common/TPH/TPH.x86_64.trace) 6. I compressed the trace file with 7z https://mega.nz/#!y3IzRY6A!ksUZcYGjgeHnBk9XtZb3J7pnIb5meZV8TxB-T27XmPs The file is hosted on MEGA, and I used 7z compression to make the uploaded file somewhat smaller. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/docs: improve docs for drm_drv.c
Just a bit of drive-by reading: - drm_dev_set_unique() is really the exception, make that clear. - drm_dev_init() is the recomended approach. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_drv.c | 23 +++ 1 file changed, 11 insertions(+), 12 deletions(-) diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c index 12e5e2be7890..5623b82038b8 100644 --- a/drivers/gpu/drm/drm_drv.c +++ b/drivers/gpu/drm/drm_drv.c @@ -265,14 +265,13 @@ void drm_minor_release(struct drm_minor *minor) * DOC: driver instance overview * * A device instance for a drm driver is represented by &struct drm_device. This - * is allocated with drm_dev_alloc(), usually from bus-specific ->probe() + * is initialized with drm_dev_init(), usually from bus-specific ->probe() * callbacks implemented by the driver. The driver then needs to initialize all * the various subsystems for the drm device like memory management, vblank * handling, modesetting support and intial output configuration plus obviously - * initialize all the corresponding hardware bits. An important part of this is - * also calling drm_dev_set_unique() to set the userspace-visible unique name of - * this device instance. Finally when everything is up and running and ready for - * userspace the device instance can be published using drm_dev_register(). + * initialize all the corresponding hardware bits. Finally when everything is up + * and running and ready for userspace the device instance can be published + * using drm_dev_register(). * * There is also deprecated support for initalizing device instances using * bus-specific helpers and the &drm_driver.load callback. But due to @@ -288,9 +287,6 @@ void drm_minor_release(struct drm_minor *minor) * Note that the lifetime rules for &drm_device instance has still a lot of * historical baggage. Hence use the reference counting provided by * drm_dev_get() and drm_dev_put() only carefully. - * - * It is recommended that drivers embed &struct drm_device into their own device - * structure, which is supported through drm_dev_init(). */ /** @@ -476,6 +472,9 @@ static void drm_fs_inode_free(struct inode *inode) * The initial ref-count of the object is 1. Use drm_dev_get() and * drm_dev_put() to take and drop further ref-counts. * + * It is recommended that drivers embed &struct drm_device into their own device + * structure. + * * Drivers that do not want to allocate their own device struct * embedding &struct drm_device can call drm_dev_alloc() instead. For drivers * that do embed &struct drm_device it must be placed first in the overall @@ -766,7 +765,7 @@ static void remove_compat_control_link(struct drm_device *dev) * @flags: Flags passed to the driver's .load() function * * Register the DRM device @dev with the system, advertise device to user-space - * and start normal device operation. @dev must be allocated via drm_dev_alloc() + * and start normal device operation. @dev must be initialized via drm_dev_init() * previously. * * Never call this twice on any device! @@ -878,9 +877,9 @@ EXPORT_SYMBOL(drm_dev_unregister); * @dev: device of which to set the unique name * @name: unique name * - * Sets the unique name of a DRM device using the specified string. Drivers - * can use this at driver probe time if the unique name of the devices they - * drive is static. + * Sets the unique name of a DRM device using the specified string. This is + * already done by drm_dev_init(), drivers should only override the default + * unique name for backwards compatibility reasons. * * Return: 0 on success or a negative error code on failure. */ -- 2.17.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/6] drm/i915: drmP.h include removal w/ drm prep work
On Thu, 27 Dec 2018, Daniel Vetter wrote: > On Thu, Dec 27, 2018 at 02:56:35PM +0200, Jani Nikula wrote: >> First make some drm headers self-contained, removing the implicit >> dependency on a previous drmP.h include. Then remove all drmP.h includes >> from drm/i915. >> >> Inspired by Sam's series [1]. Theres a one line trivial conflict between >> that one and this series in drm_file.h (patch 3), but I'm keeping this >> series self-contained. Should be easy enough to resolve. >> >> I'm fine with merging the first 5 through either drm-misc or drm-intel, >> but I'd rather merge the last one through drm-intel. > > Usually I'd say stuff it into drm-misc and then backmerge for the last > patch, but -rc1 is still a few weeks away I think, so not great. Probably > best if you stuff this into a topic branch in drm-intel, and then send out > pull requests to both drm-misc-next and dinq. Thanks for all the reviews, pushed patches 1-5 to topic/drmp-cleanup with $(git merge-base drm-misc-next drm-intel-next-queued) as the starting point. It's also included in drm-tip now. I'll probably let it simmer there until, uh, next year, and send the pull requests to drm-misc and drm-intel after that. And then apply patch 6 on top of dinq. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vc4: Allow fb modifiers early enough to fill IN_FORMATS property
On Fri, 2018-12-28 at 13:08 +0100, Daniel Vetter wrote: > On Thu, Dec 27, 2018 at 03:36:20PM -0800, Eric Anholt wrote: > > Paul Kocialkowski writes: > > > > > The KMS mode_config elements are currently configured in vc4_kms_load, > > > that is called after all components are binded (component_bind_all). > > > However, the CRTC component (for the Pixel Valve) needs to access the > > > allow_fb_modifiers element at bind time, when initializing its planes > > > through drm_universal_plane_init. > > > > > > This helpers checks allow_fb_modifiers to decide whether to fill the > > > IN_FORMATS property. Because allow_fb_modifiers is still set to false > > > at this point, the property is never filled and userspace cannot > > > retrieve the combination of supported formats and modifiers. > > > > > > Fix this by setting allow_fb_modifiers right after calling > > > drm_mode_config_init (which initializes the structure), before binding > > > the components of the driver. > > > > This makes me wonder if the flag could be removed and replaced with "did > > non-NULL modifiers get supplied to plane init?" I think I've tripped > > over this flag in other KMS hacking, too. > > Sounds like a good idea to me. Just setting it in plane_init should work I > think ... Yeah, we probably need to keep the flag around since it's used in various places, but we could totally have it auto-set as soon as a plane is registered with a list of modifiers. I was also thinking of allowing the core to fill-in the IN_FORMATS prop even without this flag set, which would only list formats (but not modifiers). What do you think? Cheers, Paul -- Paul Kocialkowski, Bootlin (formerly Free Electrons) Embedded Linux and kernel engineering https://bootlin.com ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/nouveau: fix incorrect FB_BACKLIGHT usage in Kconfig
Making FB_BACKLIGHT tristate by commit b4a1ed0cd18b ("fbdev:
make FB_BACKLIGHT a tristate") caused unmet dependencies in
some configurations:
WARNING: unmet direct dependencies detected for FB_BACKLIGHT
Depends on [m]: HAS_IOMEM [=y] && FB [=m]
Selected by [y]:
- DRM_NOUVEAU [=y] && HAS_IOMEM [=y] && DRM [=y] && PCI [=y] && MMU [=y] &&
DRM_NOUVEAU_BACKLIGHT [=y]
Selected by [m]:
- FB_NVIDIA [=m] && HAS_IOMEM [=y] && FB [=m] && PCI [=y] &&
FB_NVIDIA_BACKLIGHT [=y]
Fix it by making DRM_NOUVEAU select BACKLIGHT_CLASS_DEVICE and
BACKLIGHT_LCD_SUPPORT instead of FB_BACKLIGHT.
Fixes: b4a1ed0cd18b ("fbdev: make FB_BACKLIGHT a tristate")
Reported-by: Randy Dunlap
Cc: Rob Clark
Cc: Arnd Bergmann
Cc: Ben Skeggs
Cc: David Airlie
Cc: Daniel Vetter
Cc: Stephen Rothwell
Signed-off-by: Bartlomiej Zolnierkiewicz
---
I would like to merge this patch through fbdev tree for v4.21
(as it is needed to fix commit currently in fbdev tree).
drivers/gpu/drm/nouveau/Kconfig |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: b/drivers/gpu/drm/nouveau/Kconfig
===
--- a/drivers/gpu/drm/nouveau/Kconfig 2018-11-30 11:46:55.716464505 +0100
+++ b/drivers/gpu/drm/nouveau/Kconfig 2018-12-28 14:54:51.655965845 +0100
@@ -4,7 +4,8 @@ config DRM_NOUVEAU
select FW_LOADER
select DRM_KMS_HELPER
select DRM_TTM
- select FB_BACKLIGHT if DRM_NOUVEAU_BACKLIGHT
+ select BACKLIGHT_CLASS_DEVICE if DRM_NOUVEAU_BACKLIGHT
+ select BACKLIGHT_LCD_SUPPORT if DRM_NOUVEAU_BACKLIGHT
select ACPI_VIDEO if ACPI && X86 && BACKLIGHT_CLASS_DEVICE && INPUT
select X86_PLATFORM_DEVICES if ACPI && X86
select ACPI_WMI if ACPI && X86
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/fb-helper: Scale back depth to supported maximum
The following happened when migrating an old fbdev driver to DRM:
The Integrator/CP PL111 supports 16BPP but only ARGB1555/ABGR1555
or XRGB1555/XBGR1555 i.e. the maximum depth is 15.
This makes the initialization of the framebuffer fail since
the code in drm_fb_helper_single_fb_probe() assigns the same value
to sizes.surface_bpp and sizes.surface_depth. I.e. it simply assumes
a 1-to-1 mapping between BPP and depth, which is true in most cases
but not for this hardware that only support odd formats.
To support the odd case of a driver supporting 16BPP with only 15
bits of depth, this patch will make the code loop over the formats
supported on the primary plane on each CRTC managed by the FB
helper and cap the depth to the maximum supported on any primary
plane.
On the PL110 Integrator, this makes drm_mode_legacy_fb_format()
select DRM_FORMAT_XRGB1555 which is acceptable for this driver, and
thus we get framebuffer, penguin and console on the Integrator/CP.
Cc: Noralf Trønnes
Cc: Ville Syrjälä
Signed-off-by: Linus Walleij
---
ChangeLog v1->v2:
- Loop over the CRTCs managed by the helper and check the
crtc->primary on each CRTC for the applicable formats and
thus depths.
- Skip over YUV formats. The framebuffer emulation cannot
handle these formats.
The v1 was sent some while back in february and I only recently
got back to fixing this up to support the last CLCD displays.
It was agreed that it is probably best to augment the framebuffer
initializer to pass a desired pixel format instead of just
BPP as today, but that is a bit daunting, and Daniel said that
we would probably anyways need a fallback like this.
---
drivers/gpu/drm/drm_fb_helper.c | 47 -
1 file changed, 46 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index d3af098b0922..57be06d932e4 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1797,6 +1797,7 @@ static int drm_fb_helper_single_fb_probe(struct
drm_fb_helper *fb_helper,
int i;
struct drm_fb_helper_surface_size sizes;
int gamma_size = 0;
+ int best_depth = 0;
memset(&sizes, 0, sizeof(struct drm_fb_helper_surface_size));
sizes.surface_depth = 24;
@@ -1804,7 +1805,10 @@ static int drm_fb_helper_single_fb_probe(struct
drm_fb_helper *fb_helper,
sizes.fb_width = (u32)-1;
sizes.fb_height = (u32)-1;
- /* if driver picks 8 or 16 by default use that for both depth/bpp */
+ /*
+* If driver picks 8 or 16 by default use that for both depth/bpp
+* to begin with
+*/
if (preferred_bpp != sizes.surface_bpp)
sizes.surface_depth = sizes.surface_bpp = preferred_bpp;
@@ -1839,6 +1843,47 @@ static int drm_fb_helper_single_fb_probe(struct
drm_fb_helper *fb_helper,
}
}
+ /*
+* If we run into a situation where, for example, the primary plane
+* supports RGBA5551 (16 bpp, depth 15) but not RGB565 (16 bpp, depth
+* 16) we need to scale down the depth of the sizes we request.
+*/
+ for (i = 0; i < fb_helper->crtc_count; i++) {
+ struct drm_mode_set *mode_set =
&fb_helper->crtc_info[i].mode_set;
+ struct drm_crtc *crtc = mode_set->crtc;
+ struct drm_plane *plane = crtc->primary;
+ int j;
+
+ DRM_DEBUG("test CRTC %d primary plane\n", i);
+
+ for (j = 0; j < plane->format_count; j++) {
+ const struct drm_format_info *fmt;
+
+ fmt = drm_format_info(plane->format_types[j]);
+
+ /* Do not consider YUV formats for framebuffers */
+ if (fmt->is_yuv)
+ continue;
+
+ /* We found a perfect fit, great */
+ if (fmt->depth == sizes.surface_depth)
+ break;
+
+ /* Skip depths above what we're looking for */
+ if (fmt->depth > sizes.surface_depth)
+ continue;
+
+ /* Best depth found so far */
+ if (fmt->depth > best_depth)
+ best_depth = fmt->depth;
+ }
+ }
+ if (sizes.surface_depth != best_depth) {
+ DRM_INFO("requested bpp %d, scaled depth down to %d",
+ sizes.surface_bpp, best_depth);
+ sizes.surface_depth = best_depth;
+ }
+
crtc_count = 0;
for (i = 0; i < fb_helper->crtc_count; i++) {
struct drm_display_mode *desired_mode;
--
2.19.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/fb-helper: Scale back depth to supported maximum
On Fri, Dec 28, 2018 at 4:40 PM Linus Walleij wrote:
>
> The following happened when migrating an old fbdev driver to DRM:
>
> The Integrator/CP PL111 supports 16BPP but only ARGB1555/ABGR1555
> or XRGB1555/XBGR1555 i.e. the maximum depth is 15.
>
> This makes the initialization of the framebuffer fail since
> the code in drm_fb_helper_single_fb_probe() assigns the same value
> to sizes.surface_bpp and sizes.surface_depth. I.e. it simply assumes
> a 1-to-1 mapping between BPP and depth, which is true in most cases
> but not for this hardware that only support odd formats.
>
> To support the odd case of a driver supporting 16BPP with only 15
> bits of depth, this patch will make the code loop over the formats
> supported on the primary plane on each CRTC managed by the FB
> helper and cap the depth to the maximum supported on any primary
> plane.
>
> On the PL110 Integrator, this makes drm_mode_legacy_fb_format()
> select DRM_FORMAT_XRGB1555 which is acceptable for this driver, and
> thus we get framebuffer, penguin and console on the Integrator/CP.
>
> Cc: Noralf Trønnes
> Cc: Ville Syrjälä
> Signed-off-by: Linus Walleij
> ---
> ChangeLog v1->v2:
> - Loop over the CRTCs managed by the helper and check the
> crtc->primary on each CRTC for the applicable formats and
> thus depths.
> - Skip over YUV formats. The framebuffer emulation cannot
> handle these formats.
>
> The v1 was sent some while back in february and I only recently
> got back to fixing this up to support the last CLCD displays.
> It was agreed that it is probably best to augment the framebuffer
> initializer to pass a desired pixel format instead of just
> BPP as today, but that is a bit daunting, and Daniel said that
> we would probably anyways need a fallback like this.
> ---
> drivers/gpu/drm/drm_fb_helper.c | 47 -
> 1 file changed, 46 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index d3af098b0922..57be06d932e4 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -1797,6 +1797,7 @@ static int drm_fb_helper_single_fb_probe(struct
> drm_fb_helper *fb_helper,
> int i;
> struct drm_fb_helper_surface_size sizes;
> int gamma_size = 0;
> + int best_depth = 0;
>
> memset(&sizes, 0, sizeof(struct drm_fb_helper_surface_size));
> sizes.surface_depth = 24;
> @@ -1804,7 +1805,10 @@ static int drm_fb_helper_single_fb_probe(struct
> drm_fb_helper *fb_helper,
> sizes.fb_width = (u32)-1;
> sizes.fb_height = (u32)-1;
>
> - /* if driver picks 8 or 16 by default use that for both depth/bpp */
> + /*
> +* If driver picks 8 or 16 by default use that for both depth/bpp
> +* to begin with
> +*/
> if (preferred_bpp != sizes.surface_bpp)
> sizes.surface_depth = sizes.surface_bpp = preferred_bpp;
>
> @@ -1839,6 +1843,47 @@ static int drm_fb_helper_single_fb_probe(struct
> drm_fb_helper *fb_helper,
> }
> }
>
> + /*
> +* If we run into a situation where, for example, the primary plane
> +* supports RGBA5551 (16 bpp, depth 15) but not RGB565 (16 bpp, depth
> +* 16) we need to scale down the depth of the sizes we request.
> +*/
> + for (i = 0; i < fb_helper->crtc_count; i++) {
> + struct drm_mode_set *mode_set =
> &fb_helper->crtc_info[i].mode_set;
> + struct drm_crtc *crtc = mode_set->crtc;
> + struct drm_plane *plane = crtc->primary;
> + int j;
> +
> + DRM_DEBUG("test CRTC %d primary plane\n", i);
> +
> + for (j = 0; j < plane->format_count; j++) {
> + const struct drm_format_info *fmt;
> +
> + fmt = drm_format_info(plane->format_types[j]);
> +
> + /* Do not consider YUV formats for framebuffers */
> + if (fmt->is_yuv)
I think better to skip all funny formats with fmt->depth == 0. With that:
Reviewed-by: Daniel Vetter
> + continue;
> +
> + /* We found a perfect fit, great */
> + if (fmt->depth == sizes.surface_depth)
> + break;
> +
> + /* Skip depths above what we're looking for */
> + if (fmt->depth > sizes.surface_depth)
> + continue;
> +
> + /* Best depth found so far */
> + if (fmt->depth > best_depth)
> + best_depth = fmt->depth;
> + }
> + }
> + if (sizes.surface_depth != best_depth) {
> + DRM_INFO("requested bpp %d, scaled depth down to %d",
> + sizes.surface_bpp, best_depth);
> + sizes.surface_depth = best_depth;
> + }
>
Re: [PATCH v3 9/9] MAINTAINERS: Add maintainer for arm komeda driver
On Fri, Dec 28, 2018 at 12:56:27PM +0100, Daniel Vetter wrote: > On Fri, Dec 28, 2018 at 12:15 PM james qian wang (Arm Technology > China) wrote: > > > > On Mon, Dec 24, 2018 at 02:05:43PM +0100, Daniel Vetter wrote: > > > On Mon, Dec 24, 2018 at 1:33 PM Liviu Dudau wrote: > > > > > > > > On Fri, Dec 21, 2018 at 10:01:06AM +, james qian wang (Arm > > > > Technology China) wrote: > > > > > v2: Adjusted the position of KOMEDA by alphabetical order > > > > > > > > > > Signed-off-by: James (Qian) Wang > > > > > > > > Acked-by: Liviu Dudau > > > > > > > > Best regards, > > > > Liviu > > > > > > > > > --- > > > > > MAINTAINERS | 9 + > > > > > 1 file changed, 9 insertions(+) > > > > > > > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > > > > index 254b7b267731..e48c2e5fd29f 100644 > > > > > --- a/MAINTAINERS > > > > > +++ b/MAINTAINERS > > > > > @@ -1124,6 +1124,15 @@ S: Supported > > > > > F: drivers/gpu/drm/arm/hdlcd_* > > > > > F: Documentation/devicetree/bindings/display/arm,hdlcd.txt > > > > > > > > > > +ARM KOMEDA DRM-KMS DRIVER > > > > > +M: James (Qian) Wang > > > > > +M: Mali DP Maintainers > > > > > +S: Supported > > > > > +F: drivers/gpu/drm/arm/display/include/ > > > > > +F: drivers/gpu/drm/arm/display/komeda/ > > > > > +F: Documentation/devicetree/bindings/display/arm/arm,komeda.txt > > > > > +F: Documentation/gpu/komeda-kms.rst > > > > > > Mentioning the git tree would be good. And I guess you'll do some kind > > > of group maintainership? Probably still good if you send out a > > > dedicated/topic pull request for this new driver, but from then on > > > it's all in the same git repo. > > > -Daniel > > > > Hi Daniel: > > > > The komeda driver will use an Arm-hosted tree: > > > > git git://linux-arm.org/linux-ld.git for-upstream/mali-dp > > > > Same as other arm display drivers. And Liviu Dudau will help to send the > > pull > > request to merge this topic into drm-next. > > > > And we are planning to adopt a group maintainership and migrate towards > > drm-misc-next, > > but we just need to have enough people and enough experience with working > > with upstream > > before we jump all in. > > arm drivers are probably a bit too big for drm-misc, but you could use > the same tooling to maintain a drm-arm tree. I guess that's the idea? Yes, the long term plan is to have the same process. We're just at the early steps right now, where we're getting weened off internal tools had bad habits :) Best regards, Liviu > -Daniel > > > Last a T: entry will be added in the next version. > > > > T: git git://linux-arm.org/linux-ld.git for-upstream/mali-dp > > > > James > > > > > > > + > > > > > ARM MALI-DP DRM DRIVER > > > > > M: Liviu Dudau > > > > > M: Brian Starkey > > > > > -- > > > > > 2.17.1 > > > > > > > > > > > > > > > -- > > > Daniel Vetter > > > Software Engineer, Intel Corporation > > > +41 (0) 79 365 57 48 - http://blog.ffwll.ch > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ツ)_/¯ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v3 0/3] CRTC background color
On Fri, Dec 28, 2018 at 12:53:29PM +0100, Daniel Vetter wrote: > Am Fr., 28. Dez. 2018, 02:09 hat Stéphane Marchesin > geschrieben: > > On Thu, Dec 27, 2018 at 4:45 PM Matt Roper > > wrote: > > > > > > On Thu, Dec 27, 2018 at 04:22:28PM -0800, Stéphane Marchesin wrote: > > > > On Thu, Dec 27, 2018 at 3:49 PM Li, Wei C wrote: > > > > > > > > > > Matt, > > > > > > > > > > Is that possible for you to get some time to review > > https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1387366 > > > > and confirm the FROMLIST change if it looks good to you so we could move > > forward? > > > > > > > > > > > > > To be more precise, I am trying to assess what's needed before this > > > > patch goes usptream, and in particular, I'd like to know if we are > > > > blocked on any Chrome-side thing. > > > > > > > > Stéphane > > > > > > > > > > Hi Stéphane. On the Chrome side of things, I believe we need an Ack > > > from the ChromeOS userspace team on the ABI, plus a pointer to where the > > > final, reviewed userspace patches are that correspond to it (mailing > > > list link or gerrit or whatever). I have an old gerrit link to some > > > in-development chromium/ozone patches for this from November 2nd, but > > > I'm not sure if there's a newer one now. > > > > IMO from user space the ABI is good. I think the question is more > > whether other hw would be fine with it. For example if we notice that > > other platforms can only do black as a background color, how can we > > make this API standard. Hopefully other folks can chime in here about > > other hw capabilities. > > black background is already the default, so "no prop" = "black > background". The problem is a bit figuring out whether you can make the > primary plane non-fullscreen, which atm is a TEST_ONLY guessing game for > userspace. We've discussed some "can_scale" and "can_position" properties > for that, but aside from reworking the helpers to check plane updates > nothing happened. > -Daniel Based on feedback from Brian and Eric, it sounds like the thing we need to get better clarity on is whether all hardware can apply pipe-level degamma/csc/gamma to the background color the same way it does to plane content (even for platforms where the background color is always a non-programmable black). My initial assumption (which I'll clarify in the kerneldoc) is that background color should be treated the same way as a plane filled with that solid color; i.e., it should go through the same pipe-level color transformations. Based on Eric's email, it sounds like Raspberry Pi matches my assumption. For Intel hardware, we have register bits that specify whether color management should be applied to the background color or not (they're not set today for gen9+, which I consider that a bug since it seems like inconsistent behavior; the first patch of my series addresses that). If there are any platforms that don't/can't apply degamma/csc/gamma to the background color (regardless of whether that background color is programmable or always fixed at black), we should probably find some way to make that known to userspace (maybe some extra immutable property?). Matt > > > > Stéphane > > > > > > > > > > Aside from satisfying the ABI/userspace requirements, we still need all > > > the patches to get reviewed by the upstream kernel devs. An older > > > version of patch #2 has a r-b from Sean, but patches 1 and 3 haven't > > > been accepted yet. Actually it looks like I never sent the latest > > > version of my series that incorporates some additional feedback from > > > Brian Starkey to the list; I'll do that tomorrow. I think a lot of > > > people are still out on holiday vacation at the moment, so if necessary > > > I'll start pinging IRC for reviews in a week or two when people are back > > > in office. > > > > > > > > > > > > Matt > > > > > > > > > > > > BTW, I've backported your kernel patch into Chrome OS and verified > > it using the TEST=drm-tests/atomictest -t crtc_background_color on a Google > > Pixelbook with KBL graphics. > > > > > > > > > > Thanks, > > > > > Wei > > > > > > > > > > -Original Message- > > > > > From: Stéphane Marchesin [mailto:marc...@chromium.org] > > > > > Sent: Thursday, December 27, 2018 3:27 PM > > > > > To: Roper, Matthew D > > > > > Cc: intel-gfx ; Li, Wei C < > > wei.c...@intel.com>; dri-devel > > > > > Subject: Re: [Intel-gfx] [PATCH v3 0/3] CRTC background color > > > > > > > > > > Hey, > > > > > > > > > > Is there anything missing on the Chrome side to move forward with > > this series? > > > > > > > > > > Stéphane > > > > > > > > > > On Thu, Nov 15, 2018 at 2:14 PM Matt Roper < > > matthew.d.ro...@intel.com> wrote: > > > > > > > > > > > > Third version of the series previously posted here: > > > > > > > > > > > > > > https://lists.freedesktop.org/archives/intel-gfx/2018-November/181777. > > > > > > html > > > > > > > > > > > > This version incorporates review feedback from Ville a
[Bug 105910] Graphical artifacts on unresponsible surfaces on AMD Radeon RX 570
https://bugs.freedesktop.org/show_bug.cgi?id=105910 Michel Dänzer changed: What|Removed |Added Attachment #138632|text/x-log |text/plain mime type|| -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v3 0/3] CRTC background color
On Fri, Dec 28, 2018 at 5:35 PM Matt Roper wrote: > > On Fri, Dec 28, 2018 at 12:53:29PM +0100, Daniel Vetter wrote: > > Am Fr., 28. Dez. 2018, 02:09 hat Stéphane Marchesin > > geschrieben: > > > On Thu, Dec 27, 2018 at 4:45 PM Matt Roper > > > wrote: > > > > > > > > On Thu, Dec 27, 2018 at 04:22:28PM -0800, Stéphane Marchesin wrote: > > > > > On Thu, Dec 27, 2018 at 3:49 PM Li, Wei C wrote: > > > > > > > > > > > > Matt, > > > > > > > > > > > > Is that possible for you to get some time to review > > > https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1387366 > > > and confirm the FROMLIST change if it looks good to you so we could move > > > forward? > > > > > > > > > > > > > > > > To be more precise, I am trying to assess what's needed before this > > > > > patch goes usptream, and in particular, I'd like to know if we are > > > > > blocked on any Chrome-side thing. > > > > > > > > > > Stéphane > > > > > > > > > > > > > Hi Stéphane. On the Chrome side of things, I believe we need an Ack > > > > from the ChromeOS userspace team on the ABI, plus a pointer to where the > > > > final, reviewed userspace patches are that correspond to it (mailing > > > > list link or gerrit or whatever). I have an old gerrit link to some > > > > in-development chromium/ozone patches for this from November 2nd, but > > > > I'm not sure if there's a newer one now. > > > > > > IMO from user space the ABI is good. I think the question is more > > > whether other hw would be fine with it. For example if we notice that > > > other platforms can only do black as a background color, how can we > > > make this API standard. Hopefully other folks can chime in here about > > > other hw capabilities. > > > > black background is already the default, so "no prop" = "black > > background". The problem is a bit figuring out whether you can make the > > primary plane non-fullscreen, which atm is a TEST_ONLY guessing game for > > userspace. We've discussed some "can_scale" and "can_position" properties > > for that, but aside from reworking the helpers to check plane updates > > nothing happened. > > -Daniel > > Based on feedback from Brian and Eric, it sounds like the thing we need > to get better clarity on is whether all hardware can apply pipe-level > degamma/csc/gamma to the background color the same way it does to plane > content (even for platforms where the background color is always a > non-programmable black). > > My initial assumption (which I'll clarify in the kerneldoc) is that > background color should be treated the same way as a plane filled with > that solid color; i.e., it should go through the same pipe-level color > transformations. Based on Eric's email, it sounds like Raspberry Pi > matches my assumption. For Intel hardware, we have register bits that > specify whether color management should be applied to the background > color or not (they're not set today for gen9+, which I consider that a > bug since it seems like inconsistent behavior; the first patch of my > series addresses that). > > If there are any platforms that don't/can't apply degamma/csc/gamma to > the background color (regardless of whether that background color is > programmable or always fixed at black), we should probably find some way > to make that known to userspace (maybe some extra immutable property?). Nah, I'd say since most hw seems to have the background color before the CRTC degamma/ctm/gamma stuff we can just require that the odd one out manually feed the background color through the color stuff before writing it to hardware. And updating it every time the gamma tables change again ofc. We could even do a little helper for this and store the post-color_mgmt background in the crtc_state. Offloading that to userspace seems silly to me. -Daniel > > > Matt > > > > > > > Stéphane > > > > > > > > > > > > > > Aside from satisfying the ABI/userspace requirements, we still need all > > > > the patches to get reviewed by the upstream kernel devs. An older > > > > version of patch #2 has a r-b from Sean, but patches 1 and 3 haven't > > > > been accepted yet. Actually it looks like I never sent the latest > > > > version of my series that incorporates some additional feedback from > > > > Brian Starkey to the list; I'll do that tomorrow. I think a lot of > > > > people are still out on holiday vacation at the moment, so if necessary > > > > I'll start pinging IRC for reviews in a week or two when people are back > > > > in office. > > > > > > > > > > > > > > > > > > Matt > > > > > > > > > > > > > > > BTW, I've backported your kernel patch into Chrome OS and verified > > > it using the TEST=drm-tests/atomictest -t crtc_background_color on a > > > Google > > > Pixelbook with KBL graphics. > > > > > > > > > > > > Thanks, > > > > > > Wei > > > > > > > > > > > > -Original Message- > > > > > > From: Stéphane Marchesin [mailto:marc...@chromium.org] > > > > > > Sent: Thursday, December 27, 2018 3:27 PM > > > > > > To
[Bug 105910] Graphical artifacts on unresponsible surfaces on AMD Radeon RX 570
https://bugs.freedesktop.org/show_bug.cgi?id=105910 Michel Dänzer changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTOURBUG --- Comment #9 from Michel Dänzer --- At least with xeyes, this is expected with i3, see https://github.com/i3/i3/issues/2742#issuecomment-433304928 and later comments. I suspect it could be similar with VirtualBox. The issue with alacritty on Wayland is probably different, maybe in Xwayland, or if it uses the Wayland protocol directly, maybe one of the known issues described on https://github.com/jwilm/alacritty => https://github.com/tomaka/winit/issues/306 . Anyway, I don't see clear evidence of a driver bug here. -- 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: [Intel-gfx] [PATCH v3 0/3] CRTC background color
On Fri, Dec 28, 2018 at 06:14:40PM +0100, Daniel Vetter wrote: > On Fri, Dec 28, 2018 at 5:35 PM Matt Roper wrote: > > > > On Fri, Dec 28, 2018 at 12:53:29PM +0100, Daniel Vetter wrote: > > > Am Fr., 28. Dez. 2018, 02:09 hat Stéphane Marchesin > > > geschrieben: > > > > On Thu, Dec 27, 2018 at 4:45 PM Matt Roper > > > > wrote: > > > > > > > > > > On Thu, Dec 27, 2018 at 04:22:28PM -0800, Stéphane Marchesin wrote: > > > > > > On Thu, Dec 27, 2018 at 3:49 PM Li, Wei C > > > > > > wrote: > > > > > > > > > > > > > > Matt, > > > > > > > > > > > > > > Is that possible for you to get some time to review > > > > https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1387366 > > > > and confirm the FROMLIST change if it looks good to you so we could move > > > > forward? > > > > > > > > > > > > > > > > > > > To be more precise, I am trying to assess what's needed before this > > > > > > patch goes usptream, and in particular, I'd like to know if we are > > > > > > blocked on any Chrome-side thing. > > > > > > > > > > > > Stéphane > > > > > > > > > > > > > > > > Hi Stéphane. On the Chrome side of things, I believe we need an Ack > > > > > from the ChromeOS userspace team on the ABI, plus a pointer to where > > > > > the > > > > > final, reviewed userspace patches are that correspond to it (mailing > > > > > list link or gerrit or whatever). I have an old gerrit link to some > > > > > in-development chromium/ozone patches for this from November 2nd, but > > > > > I'm not sure if there's a newer one now. > > > > > > > > IMO from user space the ABI is good. I think the question is more > > > > whether other hw would be fine with it. For example if we notice that > > > > other platforms can only do black as a background color, how can we > > > > make this API standard. Hopefully other folks can chime in here about > > > > other hw capabilities. > > > > > > black background is already the default, so "no prop" = "black > > > background". The problem is a bit figuring out whether you can make the > > > primary plane non-fullscreen, which atm is a TEST_ONLY guessing game for > > > userspace. We've discussed some "can_scale" and "can_position" properties > > > for that, but aside from reworking the helpers to check plane updates > > > nothing happened. > > > -Daniel > > > > Based on feedback from Brian and Eric, it sounds like the thing we need > > to get better clarity on is whether all hardware can apply pipe-level > > degamma/csc/gamma to the background color the same way it does to plane > > content (even for platforms where the background color is always a > > non-programmable black). > > > > My initial assumption (which I'll clarify in the kerneldoc) is that > > background color should be treated the same way as a plane filled with > > that solid color; i.e., it should go through the same pipe-level color > > transformations. Based on Eric's email, it sounds like Raspberry Pi > > matches my assumption. For Intel hardware, we have register bits that > > specify whether color management should be applied to the background > > color or not (they're not set today for gen9+, which I consider that a > > bug since it seems like inconsistent behavior; the first patch of my > > series addresses that). > > > > If there are any platforms that don't/can't apply degamma/csc/gamma to > > the background color (regardless of whether that background color is > > programmable or always fixed at black), we should probably find some way > > to make that known to userspace (maybe some extra immutable property?). > > Nah, I'd say since most hw seems to have the background color before > the CRTC degamma/ctm/gamma stuff we can just require that the odd one > out manually feed the background color through the color stuff before > writing it to hardware. And updating it every time the gamma tables > change again ofc. We could even do a little helper for this and store > the post-color_mgmt background in the crtc_state. Offloading that to > userspace seems silly to me. > -Daniel I think the only problem would be if we come across hardware that has a non-programmable (always black) background colors that also doesn't pass its background black through the gamma/csc pipeline. Matt > > > > > > > Matt > > > > > > > > > > Stéphane > > > > > > > > > > > > > > > > > > Aside from satisfying the ABI/userspace requirements, we still need > > > > > all > > > > > the patches to get reviewed by the upstream kernel devs. An older > > > > > version of patch #2 has a r-b from Sean, but patches 1 and 3 haven't > > > > > been accepted yet. Actually it looks like I never sent the latest > > > > > version of my series that incorporates some additional feedback from > > > > > Brian Starkey to the list; I'll do that tomorrow. I think a lot of > > > > > people are still out on holiday vacation at the moment, so if > > > > > necessary > > > > > I'll start pinging IRC for reviews in a week or two when people are > > > > > back
Re: [PATCH v1 1/2] drm/fb-helper: Bring back workaround for bugs of SDL 1.2
On Fri, 2018-12-28 at 04:13 +0500, Ivan Mironov wrote:
> SDL 1.2 sets all fields related to the pixel format to zero in some
> cases[1]. Prior to commit db05c48197759 ("drm: fb-helper: Reject all
> pixel format changing requests"), there was an unintentional workaround
> for this that existed for more than a decade. First in device-specific DRM
> drivers, then here in drm_fb_helper.c.
>
> Previous code containing this workaround just ignores pixel format fields
> from userspace code. Not a good thing either, as this way, driver may
> silently use pixel format different from what client actually requested,
> and this in turn will lead to displaying garbage on the screen. I think
> that returning EINVAL to userspace in this particular case is the right
> option, so I decided to left code from problematic commit untouched
> instead of just reverting it entirely.
Yep, reverting commit db05c48197759 ("drm: fb-helper: Reject all pixel
format changing requests") isn't a good idea as it will break Weston with
fbdev-backend where we get exactly described situation - we request one
pixel format but kernel successfully and silently set another one. So we
get picturesque garbage on the screen :)
> Here is the steps required to reproduce this problem exactly:
> 1) Compile fceux[2] with SDL 1.2.15 and without GTK or OpenGL
> support. SDL should be compiled with fbdev support (which is
> on by default).
> 2) Create /etc/fb.modes with following contents (values seems
> not used, and just required to trigger problematic code in
> SDL):
>
> mode "test"
> geometry 1 1 1 1 1
> timings 1 1 1 1 1 1 1
> endmode
>
> 3) Create ~/.fceux/fceux.cfg with following contents:
>
> SDL.Hotkeys.Quit = 27
> SDL.DoubleBuffering = 1
>
> 4) Ensure that screen resolution is at least 1280x960 (e.g.
> append "video=Virtual-1:1280x960-32" to the kernel cmdline
> for qemu/QXL).
>
> 5) Try to run fceux on VT with some ROM file[3]:
>
> # ./fceux color_test.nes
>
> [1] SDL 1.2.15 source code, src/video/fbcon/SDL_fbvideo.c,
> FB_SetVideoMode()
> [2]
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.fceux.com&d=DwIDAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=ZlJN1MriPUTkBKCrPSx67GmaplEUGcAEk9yPtCLdUX
> I&m=qIoApAq-LY8cjTow82_lYWwm4L8HiOYnLp_E4AziAxo&s=fM_yxMF6T5-RyXKlbbff_S62k_opHxlolqNPXV0RPa4&e=
> [3] Example ROM:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_bokuweb_rustynes_blob_master_roms_color-5Ftest.nes&d=DwIDAg&c=DPL6_
> X_6JkXFx7AXWqB0tg&r=ZlJN1MriPUTkBKCrPSx67GmaplEUGcAEk9yPtCLdUXI&m=qIoApAq-
> LY8cjTow82_lYWwm4L8HiOYnLp_E4AziAxo&s=4gNM8PW1yNqinYiWW9lGjj3ik0Kmo40XXQYLl0UcEHc&e=
>
> Reported-by: saahriktu
> Suggested-by: saahriktu
> Cc: sta...@vger.kernel.org
> Fixes: db05c48197759 ("drm: fb-helper: Reject all pixel format changing
> requests")
> Signed-off-by: Ivan Mironov
> ---
> drivers/gpu/drm/drm_fb_helper.c | 146
> 1 file changed, 93 insertions(+), 53 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index d3af098b0922..aff576c3c4fb 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -1621,6 +1621,64 @@ static bool drm_fb_pixel_format_equal(const struct
> fb_var_screeninfo *var_1,
> var_1->transp.msb_right == var_2->transp.msb_right;
> }
>
> +static void drm_fb_helper_fill_pixel_fmt(struct fb_var_screeninfo *var,
> + u8 depth)
> +{
> + switch (depth) {
> + case 8:
> + var->red.offset = 0;
> + var->green.offset = 0;
> + var->blue.offset = 0;
> + var->red.length = 8; /* 8bit DAC */
> + var->green.length = 8;
> + var->blue.length = 8;
> + var->transp.offset = 0;
> + var->transp.length = 0;
> + break;
> + case 15:
> + var->red.offset = 10;
> + var->green.offset = 5;
> + var->blue.offset = 0;
> + var->red.length = 5;
> + var->green.length = 5;
> + var->blue.length = 5;
> + var->transp.offset = 15;
> + var->transp.length = 1;
> + break;
> + case 16:
> + var->red.offset = 11;
> + var->green.offset = 5;
> + var->blue.offset = 0;
> + var->red.length = 5;
> + var->green.length = 6;
> + var->blue.length = 5;
> + var->transp.offset = 0;
> + break;
> + case 24:
> + var->red.offset = 16;
> + var->green.offset = 8;
> + var->blue.offset = 0;
> + var->red.length = 8;
> + var->green.length = 8;
> + var->blue.length = 8;
> + var->transp.offset = 0;
> +
Re: [PATCH v2 1/3] dt-bindings: display: bridge: fork out ti, ds90c185 from lvds-transmitter
On Thu, Dec 27, 2018 at 4:54 PM Peter Rosin wrote: > > On 2018-12-27 22:27, Rob Herring wrote: > > On Wed, Dec 19, 2018 at 02:04:47PM +0100, Peter Rosin wrote: > >> From: Peter Rosin > >> > >> DS90C185 has a shutdown pin which does not fit in the lvds-transmitter > >> binding, which is meant to be generic. > >> > >> The sister chip DS90C187 is similar to DS90C185, describe it here as well. > >> > >> Signed-off-by: Peter Rosin > >> --- > >> .../bindings/display/bridge/lvds-transmitter.txt | 8 +--- > >> .../bindings/display/bridge/ti,ds90c185.txt| 55 > >> ++ > >> 2 files changed, 56 insertions(+), 7 deletions(-) > >> create mode 100644 > >> Documentation/devicetree/bindings/display/bridge/ti,ds90c185.txt > >> > >> diff --git > >> a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt > >> b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt > >> index 50220190c203..fd39ad34c383 100644 > >> --- a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt > >> +++ b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt > >> @@ -22,13 +22,7 @@ among others. > >> > >> Required properties: > >> > >> -- compatible: Must be one or more of the following > >> - - "ti,ds90c185" for the TI DS90C185 FPD-Link Serializer > >> - - "lvds-encoder" for a generic LVDS encoder device > >> - > >> - When compatible with the generic version, nodes must list the > >> - device-specific version corresponding to the device first > >> - followed by the generic version. > >> +- compatible: Must be "lvds-encoder" > >> > >> Required nodes: > >> > >> diff --git > >> a/Documentation/devicetree/bindings/display/bridge/ti,ds90c185.txt > >> b/Documentation/devicetree/bindings/display/bridge/ti,ds90c185.txt > >> new file mode 100644 > >> index ..a13e778503e6 > >> --- /dev/null > >> +++ b/Documentation/devicetree/bindings/display/bridge/ti,ds90c185.txt > >> @@ -0,0 +1,55 @@ > >> +Texas Instruments FPD-Link (LVDS) Serializer > >> + > >> + > >> +The DS90C185 and DS90C187 are low-power serializers for portable > >> +battery-powered applications that reduces the size of the RGB > >> +interface between the host GPU and the display. > >> + > >> +Required properties: > >> + > >> +- compatible: Should be > >> + "ti,ds90c185", "lvds-encoder" for the TI DS90C185 FPD-Link Serializer > >> + "ti,ds90c187", "lvds-encoder" for the TI DS90C187 FPD-Link Serializer > >> + > >> +Optional properties: > >> + > >> +- pwdn-gpios: Power down control GPIO (the PDB pin, active-low) > > > > powerdown-gpios is the standard name. > > The lvds-encoder driver handles this binding, and that driver incidentally > also implements the thine,thc63lvdm83d binding which already has a > pwdn-gpios property. Should the thine,thc63lvdm83d binding be updated and > the driver be made to support both properties? > > Since the lvds-encoder driver never had support for the pwdn-gpios (at least > not upstream) I suppose there is also the option to simply go with > powerdown-gpios as you suggest and not bother with support for the > pwdn-gpios property. It is probably safe to just change it given it is not used in any dts nor supported in the driver. Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109162] Bugs Bunny: Lost in Time
https://bugs.freedesktop.org/show_bug.cgi?id=109162 --- Comment #8 from smoki --- Got this old OpenGL game accelerated, by using gldirect: http://sourceforge.net/projects/gldirect/ That seems supports OpenGL 1.x to D3D9 just fine :) And then asking d3dadapter nine to play opengl game and everything looks fine this way. Well, this bug is still there since this is OpenGL game and should play on OpenGL driver fine. -- 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] qcom-scm: Include header
Hi Bjorn,
On Fri, Dec 28, 2018 at 5:31 PM Bjorn Andersson
wrote:
>
> On Wed 26 Dec 04:06 PST 2018, Fabio Estevam wrote:
>
> > Since commit e6f6d63ed14c ("drm/msm: add headless gpu device for imx5")
> > the DRM_MSM symbol can be selected by SOC_IMX5 causing the following
> > error when building imx_v6_v7_defconfig:
> >
> > In file included from ../drivers/gpu/drm/msm/adreno/a5xx_gpu.c:17:0:
> > ../include/linux/qcom_scm.h: In function 'qcom_scm_set_cold_boot_addr':
> > ../include/linux/qcom_scm.h:73:10: error: 'ENODEV' undeclared (first use in
> > this function)
> > return -ENODEV;
> >
> > Include the header file to fix this problem.
> >
>
> Reviewed-by: Bjorn Andersson
>
> Andy, please pick up for inclusion in -rc
Yes, it would be really nice if we could get this fix into 4.20-rc1 so
that imx_v6_v7_defconfig could be built.
> Fabio, please use get_maintainers, so your patches hits the appropriate
> mailing lists (linux-arm-msm@ in this case)
Sorry, I copied the folks involved in the offending commit:
e6f6d63ed14c ("drm/msm: add headless gpu device for imx5")
By the way, I just ran get_maintainers in this patch and linux-arm-msm
is not listed.
Thanks
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] qcom-scm: Include header
Hi Bjorn, On Fri, Dec 28, 2018 at 5:52 PM Fabio Estevam wrote: > By the way, I just ran get_maintainers in this patch and linux-arm-msm > is not listed. Would you like to me to submit a patch like this to fix this problem? diff --git a/MAINTAINERS b/MAINTAINERS index 7a9804a891fd..e014de05b046 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4797,6 +4797,7 @@ L:freedr...@lists.freedesktop.org T: git git://people.freedesktop.org/~robclark/linux S: Maintained F: drivers/gpu/drm/msm/ +F: include/linux/qcom_scm.h F: include/uapi/drm/msm_drm.h F: Documentation/devicetree/bindings/display/msm/ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] qcom-scm: Include header
On Fri, Dec 28, 2018 at 5:52 PM Fabio Estevam wrote: > > Andy, please pick up for inclusion in -rc > > Yes, it would be really nice if we could get this fix into 4.20-rc1 so > that imx_v6_v7_defconfig could be built. Ops, I meant 4.21-rc1 :-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] qcom-scm: Include header
On Fri, Dec 28, 2018 at 5:56 PM Fabio Estevam wrote: > > Hi Bjorn, > > On Fri, Dec 28, 2018 at 5:52 PM Fabio Estevam wrote: > > > By the way, I just ran get_maintainers in this patch and linux-arm-msm > > is not listed. > > Would you like to me to submit a patch like this to fix this problem? Just realized that include/linux/qcom_scm.h is used in several subsystems, so maybe a better location would be under ARM/QUALCOMM SUPPORT? diff --git a/MAINTAINERS b/MAINTAINERS index 7a9804a891fd..77836b9a8ffd 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1950,6 +1950,7 @@ F:drivers/tty/serial/msm_serial.c F: drivers/*/pm8???-* F: drivers/mfd/ssbi.c F: drivers/firmware/qcom_scm* +F: include/linux/qcom_scm.h T: git git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git ARM/RADISYS ENP2611 MACHINE SUPPORT ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/9] drm/fb-helper: Add generic fbdev emulation .fb_probe function
On Tue, May 29, 2018 at 9:54 AM Daniel Vetter wrote:
>
> On Fri, May 25, 2018 at 02:42:02PM +0200, Noralf Trønnes wrote:
> >
> > Den 24.05.2018 11.16, skrev Daniel Vetter:
> > > On Wed, May 23, 2018 at 04:34:07PM +0200, Noralf Trønnes wrote:
> > > > This is the first step in getting generic fbdev emulation.
> > > > A drm_fb_helper_funcs.fb_probe function is added which uses the
> > > > DRM client API to get a framebuffer backed by a dumb buffer.
> > > >
> > > > A transitional hack for tinydrm is needed in order to switch over all
> > > > CMA helper drivers in a later patch. This hack will be removed when
> > > > tinydrm moves to vmalloc buffers.
> > > >
> > > > Signed-off-by: Noralf Trønnes
> > > > ---
> > > > drivers/gpu/drm/drm_fb_helper.c | 164
> > > >
> > > > include/drm/drm_fb_helper.h | 26 +++
> > > > 2 files changed, 190 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_fb_helper.c
> > > > b/drivers/gpu/drm/drm_fb_helper.c
> > > > index 2ee1eaa66188..444c2b4040ea 100644
> > > > --- a/drivers/gpu/drm/drm_fb_helper.c
> > > > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > > > @@ -30,11 +30,13 @@
> > > > #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> > > > #include
> > > > +#include
> > > > #include
> > > > #include
> > > > #include
> > > > #include
> > > > #include
> > > > +#include
> > > > #include
> > > > #include
> > > > #include
> > > > @@ -2928,6 +2930,168 @@ void drm_fb_helper_output_poll_changed(struct
> > > > drm_device *dev)
> > > > }
> > > > EXPORT_SYMBOL(drm_fb_helper_output_poll_changed);
> > > > +/* @user: 1=userspace, 0=fbcon */
> > > > +static int drm_fbdev_fb_open(struct fb_info *info, int user)
> > > > +{
> > > > + struct drm_fb_helper *fb_helper = info->par;
> > > > +
> > > > + if (!try_module_get(fb_helper->dev->driver->fops->owner))
> > > > + return -ENODEV;
> > > > +
> > > > + return 0;
> > > > +}
> > > > +
> > > > +static int drm_fbdev_fb_release(struct fb_info *info, int user)
> > > > +{
> > > > + struct drm_fb_helper *fb_helper = info->par;
> > > > +
> > > > + module_put(fb_helper->dev->driver->fops->owner);
> > > > +
> > > > + return 0;
> > > > +}
> > > Hm, I thought earlier versions of your patch series had this separately,
> > > for everyone. What's the reasons for merging this into the fb_probe
> > > implementation.
> >
> > This is only necessary when struct fb_ops is defined in a library where
> > the owner field is the library module and not the driver module.
> > I realised that with this generic version it's highly unlikely that we
> > get another library that defines struct fb_ops, so it's only needed here.
>
> Hm, I'm still not 100% convinced we can fully subsume the tinydrm fbdev
> code with the generic one, due to the varios slight issues around defio
> tracking that we still have.
I have a new idea for 100% generic defio support in the fbdev helpers.
Haven't tried it thought, but I think this could work around the
problem if your mmap isn't struct page backed:
- In the drm_fbdev_fb_mmap helper, if we need defio, change the
default page prots to write-protected with something like this:
vma->vm_page_prot = pgprot_wrprotect(vma->vm_page_prot);
- After the driver's mmap function completed, copy the vm_ops
structure and WARN_ON if it has an mkwrite and sync callback set.
There's no real race here as long as we do all this before we return
to userspace.
- Set the mkwrite and fsync callbacks with similar implementions to
the core fbdev defio stuff. These should all work on plain ptes, they
don't actually require a struct page.
uff. These should all work on plain ptes, they don't actually require
a struct page.
- We might also need to overwrite the vma_ops fault callback, just
forwarding to the underlying vma_ops instead of copying them would be
cleaner. The overhead won't matter, especially not for defio drivers.
- Also copypaste all the other bits of the core fbdev defio code we'll
need, that would allow us to also clean up the cleanup() warts ...
All of this would ofc only be done if the fb has a ->dirty callback.
We can also just stuff this into todo.rst.
Cheers, Daniel
>
> But it's also easy to export this later on. If you add a comment
> explaining what you explained here to the commit message I think this is
> all fine with me as-is.
> -Daniel
>
> >
> > Noralf.
> >
> > > > +
> > > > +/*
> > > > + * fb_ops.fb_destroy is called by the last put_fb_info() call at the
> > > > end of
> > > > + * unregister_framebuffer() or fb_release().
> > > > + */
> > > > +static void drm_fbdev_fb_destroy(struct fb_info *info)
> > > > +{
> > > > + struct drm_fb_helper *fb_helper = info->par;
> > > > + struct fb_ops *fbops = NULL;
> > > > +
> > > > + DRM_DEBUG("\n");
> > > > +
> > > > + if (fb_helper->fbdev->fbdefio) {
> > > > + fb_deferred_io_cleanup(fb_helper->fbdev);
> > > > + fbops = fb_helper->fbdev->fbops;
> > > > + }
> > > > +
> > > > + drm_fb
Re: [Intel-gfx] [PATCH v3 0/3] CRTC background color
On Fri, Dec 28, 2018 at 6:19 PM Matt Roper wrote: > > On Fri, Dec 28, 2018 at 06:14:40PM +0100, Daniel Vetter wrote: > > On Fri, Dec 28, 2018 at 5:35 PM Matt Roper > > wrote: > > > > > > On Fri, Dec 28, 2018 at 12:53:29PM +0100, Daniel Vetter wrote: > > > > Am Fr., 28. Dez. 2018, 02:09 hat Stéphane Marchesin > > > > > > > > geschrieben: > > > > > On Thu, Dec 27, 2018 at 4:45 PM Matt Roper > > > > > wrote: > > > > > > > > > > > > On Thu, Dec 27, 2018 at 04:22:28PM -0800, Stéphane Marchesin wrote: > > > > > > > On Thu, Dec 27, 2018 at 3:49 PM Li, Wei C > > > > > > > wrote: > > > > > > > > > > > > > > > > Matt, > > > > > > > > > > > > > > > > Is that possible for you to get some time to review > > > > > https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1387366 > > > > > and confirm the FROMLIST change if it looks good to you so we could > > > > > move > > > > > forward? > > > > > > > > > > > > > > > > > > > > > > To be more precise, I am trying to assess what's needed before > > > > > > > this > > > > > > > patch goes usptream, and in particular, I'd like to know if we are > > > > > > > blocked on any Chrome-side thing. > > > > > > > > > > > > > > Stéphane > > > > > > > > > > > > > > > > > > > Hi Stéphane. On the Chrome side of things, I believe we need an Ack > > > > > > from the ChromeOS userspace team on the ABI, plus a pointer to > > > > > > where the > > > > > > final, reviewed userspace patches are that correspond to it (mailing > > > > > > list link or gerrit or whatever). I have an old gerrit link to some > > > > > > in-development chromium/ozone patches for this from November 2nd, > > > > > > but > > > > > > I'm not sure if there's a newer one now. > > > > > > > > > > IMO from user space the ABI is good. I think the question is more > > > > > whether other hw would be fine with it. For example if we notice that > > > > > other platforms can only do black as a background color, how can we > > > > > make this API standard. Hopefully other folks can chime in here about > > > > > other hw capabilities. > > > > > > > > black background is already the default, so "no prop" = "black > > > > background". The problem is a bit figuring out whether you can make the > > > > primary plane non-fullscreen, which atm is a TEST_ONLY guessing game for > > > > userspace. We've discussed some "can_scale" and "can_position" > > > > properties > > > > for that, but aside from reworking the helpers to check plane updates > > > > nothing happened. > > > > -Daniel > > > > > > Based on feedback from Brian and Eric, it sounds like the thing we need > > > to get better clarity on is whether all hardware can apply pipe-level > > > degamma/csc/gamma to the background color the same way it does to plane > > > content (even for platforms where the background color is always a > > > non-programmable black). > > > > > > My initial assumption (which I'll clarify in the kerneldoc) is that > > > background color should be treated the same way as a plane filled with > > > that solid color; i.e., it should go through the same pipe-level color > > > transformations. Based on Eric's email, it sounds like Raspberry Pi > > > matches my assumption. For Intel hardware, we have register bits that > > > specify whether color management should be applied to the background > > > color or not (they're not set today for gen9+, which I consider that a > > > bug since it seems like inconsistent behavior; the first patch of my > > > series addresses that). > > > > > > If there are any platforms that don't/can't apply degamma/csc/gamma to > > > the background color (regardless of whether that background color is > > > programmable or always fixed at black), we should probably find some way > > > to make that known to userspace (maybe some extra immutable property?). > > > > Nah, I'd say since most hw seems to have the background color before > > the CRTC degamma/ctm/gamma stuff we can just require that the odd one > > out manually feed the background color through the color stuff before > > writing it to hardware. And updating it every time the gamma tables > > change again ofc. We could even do a little helper for this and store > > the post-color_mgmt background in the crtc_state. Offloading that to > > userspace seems silly to me. > > -Daniel > > I think the only problem would be if we come across hardware that has a > non-programmable (always black) background colors that also doesn't pass > its background black through the gamma/csc pipeline. That just sounds broken. I guess in that case you don't get to use both the color mgmt pipeline and have a non-fullscreen primary plane. Mea culpa, build better hw :-) -Daniel > > > Matt > > > > > > > > > > > > Matt > > > > > > > > > > > > > Stéphane > > > > > > > > > > > > > > > > > > > > > > Aside from satisfying the ABI/userspace requirements, we still need > > > > > > all > > > > > > the patches to get reviewed by the upstream kernel devs. An older > > > > > > v
[Bug 107561] [amdgpu] / rx550 / half the fps after thaw
https://bugs.freedesktop.org/show_bug.cgi?id=107561 arne_woer...@yahoo.com changed: What|Removed |Added Severity|major |critical -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107561] [amdgpu] / rx550 / half the fps after thaw
https://bugs.freedesktop.org/show_bug.cgi?id=107561 --- Comment #1 from arne_woer...@yahoo.com --- Hi! The bug is still there. Is there something I could do in order to fix it? Or is suspend/resume not really supported? I use it daily and almost never use `halt -p`... Thx. Bye. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107561] [amdgpu] / rx550 / half the fps after thaw
https://bugs.freedesktop.org/show_bug.cgi?id=107561 Alex Deucher changed: What|Removed |Added QA Contact|dri-devel@lists.freedesktop | |.org| Product|Mesa|DRI Component|Drivers/Gallium/radeonsi|DRM/AMDgpu --- Comment #2 from Alex Deucher --- Please attach your xorg log and dmesg output. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/etnaviv: fix some off by one bugs
Am Fr., 13. Juli 2018 um 17:00 Uhr schrieb Dan Carpenter
:
>
> The ->nr_signal is the supposed to be the number of elements in the
> ->signal array. There was one place where it was 5 but it was supposed
> to be 4. That looks like a copy and paste bug. There were also two
> checks that were off by one.
>
> Fixes: 9e2c2e273012 ("drm/etnaviv: add infrastructure to query perf counter")
> Signed-off-by: Dan Carpenter
Reviewed-by: Christian Gmeiner
Tested-by: Christian Gmeiner
> ---
> Not tested.
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
> b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
> index 9980d81a26e3..4227a4006c34 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
> @@ -113,7 +113,7 @@ static const struct etnaviv_pm_domain doms_3d[] = {
> .name = "PE",
> .profile_read = VIVS_MC_PROFILE_PE_READ,
> .profile_config = VIVS_MC_PROFILE_CONFIG0,
> - .nr_signals = 5,
> + .nr_signals = 4,
> .signal = (const struct etnaviv_pm_signal[]) {
> {
> "PIXEL_COUNT_KILLED_BY_COLOR_PIPE",
> @@ -435,7 +435,7 @@ int etnaviv_pm_query_sig(struct etnaviv_gpu *gpu,
>
> dom = meta->domains + signal->domain;
>
> - if (signal->iter > dom->nr_signals)
> + if (signal->iter >= dom->nr_signals)
> return -EINVAL;
>
> sig = &dom->signal[signal->iter];
> @@ -461,7 +461,7 @@ int etnaviv_pm_req_validate(const struct
> drm_etnaviv_gem_submit_pmr *r,
>
> dom = meta->domains + r->domain;
>
> - if (r->signal > dom->nr_signals)
> + if (r->signal >= dom->nr_signals)
> return -EINVAL;
>
> return 0;
--
greets
--
Christian Gmeiner, MSc
https://christian-gmeiner.info
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/3] dt-bindings: gpu: samsung-rotator: Document s5pv210 support
On Fri, 28 Dec 2018 16:19:03 +0100, =?UTF-8?q?Pawe=C5=82=20Chmiel?= wrote: > This commit documents new compatible for s5pv210 soc, > which will be also supported by this driver. > > Signed-off-by: Paweł Chmiel > --- > Changes from v1: > - Removed list enumeration > - Placed s5pv210 at beginning of list (it's the oldest chipset) > --- > Documentation/devicetree/bindings/gpu/samsung-rotator.txt | 7 --- > 1 file changed, 4 insertions(+), 3 deletions(-) > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/3] dt-bindings: gpu: samsung-rotator: Document s5pv210 support
On Fri, 28 Dec 2018 at 16:19, Paweł Chmiel wrote: > > This commit documents new compatible for s5pv210 soc, > which will be also supported by this driver. > > Signed-off-by: Paweł Chmiel > --- > Changes from v1: > - Removed list enumeration > - Placed s5pv210 at beginning of list (it's the oldest chipset) > --- > Documentation/devicetree/bindings/gpu/samsung-rotator.txt | 7 --- > 1 file changed, 4 insertions(+), 3 deletions(-) Acked-by: Krzysztof Kozlowski Best regards, Krzysztof ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109169] Stuck with 800x600 resolution on DisplayPort of RX570.
https://bugs.freedesktop.org/show_bug.cgi?id=109169 Bug ID: 109169 Summary: Stuck with 800x600 resolution on DisplayPort of RX570. Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: critical Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: s...@gmx.de Hi I've a VGA Monitor connected to DisplayPort via an Adapter, when using the Adapter on my old NVidia or Intel GPU every resolution works fine, but when I connect the Adapter to my new RX570 it will only work on 800x600 resolution and when switching to an higher resolution the screen turns black with a bit of flickering. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 0/3] CRTC background color
Fourth version of the series previously posted here: https://lists.freedesktop.org/archives/intel-gfx/2018-November/181939.html Code-wise, this version mainly just drops the bgcolor_changed flag. Most of the changes here are just to the kerneldoc: clarifying the interaction of background color with crtc degamma/csc/gamma, and why having a non-opaque background color might actually make sense for very specific use cases (memory writeback connectors). As before, the first patch in this series is just an Intel-specific bugfix that is unrelated to the ABI change and thus can be merged immediately after review. The second and third patches need a pointer to the ready, reviewed userspace that's going to use this (I believe ChromeOS pretty much has this ready, but I don't have a link to their patches yet). I heard there's also someone working on adding support for this to Weston, but I'm not sure what the status of that work is. Matt Roper (3): drm/i915: Force background color to black for gen9+ (v2) drm: Add CRTC background color property (v4) drm/i915/gen9+: Add support for pipe background color (v4) drivers/gpu/drm/drm_atomic_uapi.c| 4 drivers/gpu/drm/drm_blend.c | 28 ++--- drivers/gpu/drm/drm_mode_config.c| 6 ++ drivers/gpu/drm/i915/i915_debugfs.c | 9 drivers/gpu/drm/i915/i915_reg.h | 6 ++ drivers/gpu/drm/i915/intel_display.c | 40 include/drm/drm_blend.h | 1 + include/drm/drm_crtc.h | 12 +++ include/drm/drm_mode_config.h| 5 + include/uapi/drm/drm_mode.h | 28 + 10 files changed, 136 insertions(+), 3 deletions(-) -- 2.14.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/3] drm/i915: Force background color to black for gen9+ (v2)
We don't yet allow userspace to control the CRTC background color, but
we should manually program the color to black to ensure the BIOS didn't
leave us with some other color. We should also set the pipe gamma and
pipe CSC bits so that the background color goes through the same color
management transformations that a plane with black pixels would.
v2: Rename register to SKL_BOTTOM_COLOR to more closely follow
bspec naming. (Ville)
Cc: Ville Syrjälä
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/i915_reg.h | 6 ++
drivers/gpu/drm/i915/intel_display.c | 19 +++
2 files changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 02af9b5add34..9962dcb475d4 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5699,6 +5699,12 @@ enum {
#define PIPEMISC_DITHER_TYPE_SP (0 << 2)
#define PIPEMISC(pipe) _MMIO_PIPE2(pipe, _PIPE_MISC_A)
+/* Skylake+ pipe bottom (background) color */
+#define _SKL_BOTTOM_COLOR_A0x70034
+#define SKL_BOTTOM_COLOR_GAMMA_ENABLE(1 << 31)
+#define SKL_BOTTOM_COLOR_CSC_ENABLE (1 << 30)
+#define SKL_BOTTOM_COLOR(pipe) _MMIO_PIPE2(pipe, _SKL_BOTTOM_COLOR_A)
+
#define VLV_DPFLIPSTAT _MMIO(VLV_DISPLAY_BASE +
0x70028)
#define PIPEB_LINE_COMPARE_INT_EN(1 << 29)
#define PIPEB_HLINE_INT_EN (1 << 28)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index f0b480fba980..cc19b276f2c1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3894,6 +3894,16 @@ static void intel_update_pipe_config(const struct
intel_crtc_state *old_crtc_sta
else if (old_crtc_state->pch_pfit.enabled)
ironlake_pfit_disable(old_crtc_state);
}
+
+ /*
+* We don't (yet) allow userspace to control the pipe background color,
+* so force it to black, but apply pipe gamma and CSC so that its
+* handling will match how we program our planes.
+*/
+ if (INTEL_GEN(dev_priv) >= 9)
+ I915_WRITE(SKL_BOTTOM_COLOR(crtc->pipe),
+ SKL_BOTTOM_COLOR_GAMMA_ENABLE |
+ SKL_BOTTOM_COLOR_CSC_ENABLE);
}
static void intel_fdi_normal_train(struct intel_crtc *crtc)
@@ -15399,6 +15409,15 @@ static void intel_sanitize_crtc(struct intel_crtc
*crtc,
plane->base.type != DRM_PLANE_TYPE_PRIMARY)
intel_plane_disable_noatomic(crtc, plane);
}
+
+ /*
+* Disable any background color set by the BIOS, but enable the
+* gamma and CSC to match how we program our planes.
+*/
+ if (INTEL_GEN(dev_priv) >= 9)
+ I915_WRITE(SKL_BOTTOM_COLOR(crtc->pipe),
+ SKL_BOTTOM_COLOR_GAMMA_ENABLE |
+ SKL_BOTTOM_COLOR_CSC_ENABLE);
}
/* Adjust the state of the output pipe according to whether we
--
2.14.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 2/3] drm: Add CRTC background color property (v4)
Some display controllers can be programmed to present non-black colors
for pixels not covered by any plane (or pixels covered by the
transparent regions of higher planes). Compositors that want a UI with
a solid color background can potentially save memory bandwidth by
setting the CRTC background property and using smaller planes to display
the rest of the content.
To avoid confusion between different ways of encoding RGB data, we
define a standard 64-bit format that should be used for this property's
value. Helper functions and macros are provided to generate and dissect
values in this standard format with varying component precision values.
v2:
- Swap internal representation's blue and red bits to make it easier
to read if printed out. (Ville)
- Document bgcolor property in drm_blend.c. (Sean Paul)
- s/background_color/bgcolor/ for consistency between property name and
value storage field. (Sean Paul)
- Add a convenience function to attach property to a given crtc.
v3:
- Restructure ARGB component extraction macros to be easier to
understand and enclose the parameters in () to avoid calculations
if expressions are passed. (Sean Paul)
- s/rgba/argb/ in helper function/macro names. Even though the idea is
to not worry about the internal representation of the u64, it can
still be confusing to look at code that uses 'rgba' terminology, but
stores values with argb ordering. (Ville)
v4:
- Drop the bgcolor_changed flag. (Ville, Brian Starkey)
- Clarify in kerneldoc that background color is expected to undergo the
same pipe-level degamma/csc/gamma transformations that planes do.
(Brian Starkey)
- Update kerneldoc to indicate non-opaque colors are allowed, but are
generally only useful in special cases such as when writeback
connectors are used (Brian Starkey / Eric Anholt)
Cc: dri-devel@lists.freedesktop.org
Cc: wei.c...@intel.com
Cc: harish.krupo@intel.com
Cc: Ville Syrjälä
Cc: Sean Paul
Cc: Brian Starkey
Cc: Eric Anholt
Cc: Stéphane Marchesin
Cc: Daniel Vetter
Signed-off-by: Matt Roper
Reviewed-by(v2): Sean Paul
---
drivers/gpu/drm/drm_atomic_uapi.c | 4
drivers/gpu/drm/drm_blend.c | 27 ---
drivers/gpu/drm/drm_mode_config.c | 6 ++
include/drm/drm_blend.h | 1 +
include/drm/drm_crtc.h| 12
include/drm/drm_mode_config.h | 5 +
include/uapi/drm/drm_mode.h | 28
7 files changed, 80 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index c40889888a16..d282362b318e 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -469,6 +469,8 @@ static int drm_atomic_crtc_set_property(struct drm_crtc
*crtc,
return -EFAULT;
set_out_fence_for_crtc(state->state, crtc, fence_ptr);
+ } else if (property == config->bgcolor_property) {
+ state->bgcolor = val;
} else if (crtc->funcs->atomic_set_property) {
return crtc->funcs->atomic_set_property(crtc, state, property,
val);
} else {
@@ -503,6 +505,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
*val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
else if (property == config->prop_out_fence_ptr)
*val = 0;
+ else if (property == config->bgcolor_property)
+ *val = state->bgcolor;
else if (crtc->funcs->atomic_get_property)
return crtc->funcs->atomic_get_property(crtc, state, property,
val);
else
diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
index 0c78ca386cbe..d451ac9e1d6d 100644
--- a/drivers/gpu/drm/drm_blend.c
+++ b/drivers/gpu/drm/drm_blend.c
@@ -175,9 +175,22 @@
* plane does not expose the "alpha" property, then this is
* assumed to be 1.0
*
- * Note that all the property extensions described here apply either to the
- * plane or the CRTC (e.g. for the background color, which currently is not
- * exposed and assumed to be black).
+ * The property extensions described above all apply to the plane. Drivers
+ * may also expose the following crtc property extension:
+ *
+ * BACKGROUND_COLOR:
+ * Background color is setup with drm_crtc_add_bgcolor_property(). It
+ * controls the ARGB color of a full-screen layer that exists below all
+ * planes. This color will be used for pixels not covered by any plane
+ * and may also be blended with plane contents as allowed by a plane's
+ * alpha values. The background color defaults to black, and is assumed
+ * to be black for drivers that do not expose this property. Although
+ * background color isn't a plane, it is assumed that the color provided
+ * here undergoes the same pipe-level degamma/CSC/gamma transformations
+ * that planes undergo. Note that the color
[PATCH v4 3/3] drm/i915/gen9+: Add support for pipe background color (v4)
Gen9+ platforms allow CRTC's to be programmed with a background/canvas
color below the programmable planes. Let's expose this for use by
compositors.
v2:
- Split out bgcolor sanitization and programming of csc/gamma bits to a
separate patch that we can land before the ABI changes are ready to
go in. (Ville)
- Change a temporary variable name to be more consistent with
other similar functions. (Ville)
- Change register name to SKL_CANVAS for consistency with the
CHV_CANVAS register.
v3:
- Switch register name back to SKL_BOTTOM_COLOR. (Ville)
- Use non-_FW register write. (Ville)
- Minor parameter rename for consistency. (Ville)
v4:
- Removed use of bgcolor_changed flag.
Cc: dri-devel@lists.freedesktop.org
Cc: wei.c...@intel.com
Cc: harish.krupo@intel.com
Cc: Ville Syrjälä
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/i915_debugfs.c | 9 +++
drivers/gpu/drm/i915/intel_display.c | 46 +++-
2 files changed, 44 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index b89abbba4604..5d6a9d11edb6 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3122,6 +3122,15 @@ static int i915_display_info(struct seq_file *m, void
*unused)
intel_plane_info(m, crtc);
}
+ if (INTEL_GEN(dev_priv) >= 9 && pipe_config->base.active) {
+ uint64_t background = pipe_config->base.bgcolor;
+
+ seq_printf(m, "\tbackground color (10bpc): r=%x g=%x
b=%x\n",
+ DRM_ARGB_RED(background, 10),
+ DRM_ARGB_GREEN(background, 10),
+ DRM_ARGB_BLUE(background, 10));
+ }
+
seq_printf(m, "\tunderrun reporting: cpu=%s pch=%s \n",
yesno(!crtc->cpu_fifo_underrun_disabled),
yesno(!crtc->pch_fifo_underrun_disabled));
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index cc19b276f2c1..703502d9e71a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3860,6 +3860,28 @@ void intel_finish_reset(struct drm_i915_private
*dev_priv)
clear_bit(I915_RESET_MODESET, &dev_priv->gpu_error.flags);
}
+static void
+skl_update_background_color(const struct intel_crtc_state *crtc_state)
+{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ uint64_t propval = crtc_state->base.bgcolor;
+ uint32_t tmp;
+
+ /* Hardware is programmed with 10 bits of precision */
+ tmp = DRM_ARGB_RED(propval, 10) << 20
+ | DRM_ARGB_GREEN(propval, 10) << 10
+ | DRM_ARGB_BLUE(propval, 10);
+
+ /*
+* Set CSC and gamma for bottom color to ensure background pixels
+* receive the same color transformations as plane content.
+*/
+ tmp |= SKL_BOTTOM_COLOR_CSC_ENABLE | SKL_BOTTOM_COLOR_GAMMA_ENABLE;
+
+ I915_WRITE(SKL_BOTTOM_COLOR(crtc->pipe), tmp);
+}
+
static void intel_update_pipe_config(const struct intel_crtc_state
*old_crtc_state,
const struct intel_crtc_state
*new_crtc_state)
{
@@ -3895,15 +3917,8 @@ static void intel_update_pipe_config(const struct
intel_crtc_state *old_crtc_sta
ironlake_pfit_disable(old_crtc_state);
}
- /*
-* We don't (yet) allow userspace to control the pipe background color,
-* so force it to black, but apply pipe gamma and CSC so that its
-* handling will match how we program our planes.
-*/
if (INTEL_GEN(dev_priv) >= 9)
- I915_WRITE(SKL_BOTTOM_COLOR(crtc->pipe),
- SKL_BOTTOM_COLOR_GAMMA_ENABLE |
- SKL_BOTTOM_COLOR_CSC_ENABLE);
+ skl_update_background_color(new_crtc_state);
}
static void intel_fdi_normal_train(struct intel_crtc *crtc)
@@ -10986,6 +11001,8 @@ static int intel_crtc_atomic_check(struct drm_crtc
*crtc,
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
struct intel_crtc_state *pipe_config =
to_intel_crtc_state(crtc_state);
+ struct drm_crtc_state *old_crtc_state =
+ drm_atomic_get_old_crtc_state(crtc_state->state, crtc);
int ret;
bool mode_changed = needs_modeset(crtc_state);
@@ -11013,6 +11030,9 @@ static int intel_crtc_atomic_check(struct drm_crtc
*crtc,
crtc_state->planes_changed = true;
}
+ if (crtc_state->bgcolor != old_crtc_state->bgcolor)
+ pipe_config->update_pipe = true;
+
ret = 0;
if (dev_priv->display.compute_pipe_wm) {
ret = dev_priv->display.compute_pipe_wm(pipe_con
Re: [PATCH v6 2/2] arm64: dts: sdm845: Add gpu and gmu device nodes
Quoting Rajendra Nayak (2018-12-20 20:52:34)
>
> On 12/21/2018 2:59 AM, Stephen Boyd wrote:
> > Quoting Rob Herring (2018-12-19 15:47:25)
> >> On Wed, Dec 19, 2018 at 4:40 PM Doug Anderson
> >> wrote:
> >>> On Wed, Dec 19, 2018 at 12:40 PM Doug Anderson
> >>> wrote:
> On Wed, Dec 19, 2018 at 12:09 PM Rob Herring wrote:
> ...but it does have a frequency, doesn't it?
>
> + compatible = "operating-points-v2-qcom-level";
> +
> + opp-71000 {
> + opp-hz = /bits/ 64 <71000>;
> + qcom,level = ;
> + };
> >>>
> >>> Ah, I perhaps see the confusion. So Rajendra's usage of
> >>> "operating-points-v2-qcom-level" [1] doesn't have a frequency but
> >>> Jordan's do. So I guess it makes sense that Jordan's have the
> >>> fallback compatible but Rajendra's don't?
> >>
> >> Is having it useful to s/w that doesn't understand
> >> "operating-points-v2-qcom-level"? If so, then add
> >> "operating-points-v2". If not, then don't.
> >
> > The only benefit I see in having "operating-points-v2" is that we don't
> > need to update the of_skipped_node_table[] in drivers/platform/of.c to
> > have all the variants of operating-points-v2-* when they decide to not
> > use anything from the "base" binding.
> >
> > If that fails to work because opp-hz is required for the
> > "operating-points-v2" binding but sometimes
> > operating-points-v2-qcom-level doesn't require it I guess we need to
> > update the skip table or make some generic property like
> > 'this-is-not-a-device' that these various data tables in DT can be
> > marked with so we don't make platform devices for them.
> >
> > Regardless of the above, we should update the binding for
> > operating-points-v2-qcom-level to say that opp-hz isn't always required
> > when the qcom-level compatible is present. It looks like it just says
> > that it builds on top of the opp binding so that's not obvious.
>
> Sure, I can respin with those details added in.
Ok.
> So I am guessing the conclusion is to use a fallback "operating-points-v2"
> compatible *only* when we do have opp-hz along with qcom,level (as in the
> case with gpu) and not have a fallback compatible in cases when we don't
> have opp-hz (as in the case of rpm power domains)?
> That seems a little inconsistent, and given Rob said either way is fine,
> just do one way or the other and not both, I am inclined to think we should
> just have a "operating-points-v2-qcom-level" and no fallback compatible.
> Does that make sense?
>
Are you going to update the skip table to not create platform devices?
Or introduce some generic property to indicate that this is just data
and not a device node?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107561] [amdgpu] / rx550 / half the fps after thaw
https://bugs.freedesktop.org/show_bug.cgi?id=107561 --- Comment #3 from arne_woer...@yahoo.com --- Created attachment 142906 --> https://bugs.freedesktop.org/attachment.cgi?id=142906&action=edit Xorg.0.log from fresh boot until second suspend -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107561] [amdgpu] / rx550 / half the fps after thaw
https://bugs.freedesktop.org/show_bug.cgi?id=107561 --- Comment #4 from arne_woer...@yahoo.com --- Created attachment 142907 --> https://bugs.freedesktop.org/attachment.cgi?id=142907&action=edit log messages from reboot until second suspend -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107561] [amdgpu] / rx550 / half the fps after thaw
https://bugs.freedesktop.org/show_bug.cgi?id=107561 --- Comment #5 from arne_woer...@yahoo.com --- Comment on attachment 142907 --> https://bugs.freedesktop.org/attachment.cgi?id=142907 log messages from reboot until second suspend i removed the lines with crond|CROND|iptables(vaako.intern.wgboome.org kernel: IN=eth0 OUT= MAC=) -arne -- 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: [git pull] drm next leftovers for rc1
The pull request you sent on Thu, 27 Dec 2018 10:09:49 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-next-2018-12-27 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/7e59fad9c9d1aeacdc96dfffd35f9e12ddc34dbf Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 2/3] drm: Add CRTC background color property (v4)
Hi Matt, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING on next-20181224] [cannot apply to v4.20] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Matt-Roper/CRTC-background-color/20181229-101622 config: arm-omap2plus_defconfig (attached as .config) compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree GCC_VERSION=7.2.0 make.cross ARCH=arm All warnings (new ones prefixed by >>): In file included from drivers/gpu/drm/omapdrm/dss/dispc.c:44:0: >> include/drm/drm_blend.h:61:43: warning: 'struct drm_crtc' declared inside >> parameter list will not be visible outside of this definition or declaration void drm_crtc_add_bgcolor_property(struct drm_crtc *crtc); ^~~~ vim +61 include/drm/drm_blend.h 44 45 int drm_plane_create_alpha_property(struct drm_plane *plane); 46 int drm_plane_create_rotation_property(struct drm_plane *plane, 47 unsigned int rotation, 48 unsigned int supported_rotations); 49 unsigned int drm_rotation_simplify(unsigned int rotation, 50 unsigned int supported_rotations); 51 52 int drm_plane_create_zpos_property(struct drm_plane *plane, 53 unsigned int zpos, 54 unsigned int min, unsigned int max); 55 int drm_plane_create_zpos_immutable_property(struct drm_plane *plane, 56 unsigned int zpos); 57 int drm_atomic_normalize_zpos(struct drm_device *dev, 58struct drm_atomic_state *state); 59 int drm_plane_create_blend_mode_property(struct drm_plane *plane, 60 unsigned int supported_modes); > 61 void drm_crtc_add_bgcolor_property(struct drm_crtc *crtc); --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
