[Bug 200645] 4.18-rc regression bisected to e03fd3f30: amdgpu polaris11/rx460 only activates on one output/monitor of two
https://bugzilla.kernel.org/show_bug.cgi?id=200645 Duncan (1i5t5.dun...@cox.net) changed: What|Removed |Added Kernel Version|4.18-rc1-4.18-rc6+ |4.18-rc1-4.19-rc1 --- Comment #8 from Duncan (1i5t5.dun...@cox.net) --- Regression from 4.17 still alive on 4.19-rc1 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107572] Unrecoverable GPU hang with IP block:gfx_v8_0 is hung
https://bugs.freedesktop.org/show_bug.cgi?id=107572 --- Comment #19 from Andrew Cook --- Tried again using the debug kernel in fedora Couldn't reproduce the unigen crash Obduction crashed in the same way, nothing new in dmesg Kernel: 4.17.19-200.fc28.x86_64+debug -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] drm/debugfs: Add support for dynamic debugfs initialization
On Fri, 2018-08-31 at 10:53 +0200, Daniel Vetter wrote:
> On Mon, Aug 27, 2018 at 08:36:24PM -0400, Lyude Paul wrote:
> > Currently all debugfs related initialization for the DRM core happens in
> > drm_debugfs_init(), which is called when registering the minor device.
> > While this works fine for features such as atomic modesetting and GEM,
> > this doesn't work at all for resources like DP MST topology managers
> > which can potentially be created both before and after the minor
> > device has been registered.
> >
> > So, in order to add driver-wide debugfs files for MST we'll need to be
> > able to handle debugfs initialization for such resources. We do so by
> > introducing drm_debugfs_callback_register() and
> > drm_debugfs_callback_unregister(). These functions allow driver-agnostic
> > parts of DRM to add additional debugfs initialization callbacks at any
> > point during a DRM driver's lifetime.
> >
> > Signed-off-by: Lyude Paul
> > Cc: Maarten Lankhorst
> > Cc: Daniel Stone
>
> So the debugfs lifetime rules are indeed silly and broken. I'm not sure
> this is what we want to do though:
>
> - Thanks to Noralf's cleanup you don't need a debugfs cleanup callback
> anymore really, it will auto-clean-up on device unregistration.
This is true, but the cleanup there is more-so to handle the theoretical case
that a driver uninitializes an MST topology mgr before the rest of debugfs is
torn down.
>
> - For stuff tied to connectors we have the connector->register/unregister
> callbacks. Imo connector-related debugfs stuff, like for mst, should be
> put there.
Since this would tie the lifetime of the debugfs files we make to the lifetime
of the connector, as it should be, we'd be able to pull off a much nicer
debugfs hierarchy:
/sys/kernel/debug/dri/0
DP-1
edid_override
dp_mst
status
DP-2
edid_override
dp_mst
status
DP-3
edid_override
dp_mst
status
The only thing I don't like about that approach though is that now we've given
up on the idea of these debugfs nodes being added to drivers using MST
automatically, since drivers wanting this would have to add calls into
late_register/early_unregister.
Since I think this would probably be useful for more then just connectors,
what if we added some sort of similar dynamic initialization system that could
be used per-DRM object? That way drivers would still get the debugfs files for
free, and we'd get a nice hierarchy and a sane way for DRM helpers to add
additional debugfs files to drivers for free. Assumably, such a system would
be added in addition to a device-wide dynamic init system like the one this
patch adds.
>
> - debugfs_init is a dead idea, as you point out it's fundamentally racy.
>
> - Dropping the silly notion that we have to duplicate all debugfs entries
> per-minor would be really sweet (last time I checked there's not a
> single debugfs file that's actually different per minor).
Yeah I'm down for this as well, I've never once seen anything actually use the
minor debugfs files. Plus, we're supposed to be able to do whatever we want in
debugfs anyway! So I don't see the harm in just gutting the duplicate minor
debugfs stuff entirely
>
> Cheers, Daniel
>
> > ---
> > drivers/gpu/drm/drm_debugfs.c | 173 +++--
> > drivers/gpu/drm/drm_drv.c | 3 +
> > drivers/gpu/drm/drm_internal.h | 5 +
> > include/drm/drm_debugfs.h | 27 +
> > include/drm/drm_file.h | 4 +
> > 5 files changed, 203 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
> > index 6f28fe58f169..a53a454b167f 100644
> > --- a/drivers/gpu/drm/drm_debugfs.c
> > +++ b/drivers/gpu/drm/drm_debugfs.c
> > @@ -39,6 +39,13 @@
> >
> > #if defined(CONFIG_DEBUG_FS)
> >
> > +struct drm_debugfs_callback {
> > + void (*init)(void *data);
> > + void (*cleanup_cb)(void *data);
> > + void *data;
> > + struct list_head list;
> > +};
> > +
> > /***
> > * Initialization, etc.
> > **/
> > @@ -67,6 +74,113 @@ static const struct file_operations drm_debugfs_fops =
> > {
> > .release = single_release,
> > };
> >
> > +/**
> > + * drm_debugfs_register_callback - Register a callback for initializing
> > + * dynamic driver-agnostic debugfs files
> > + * @minor: device minor number
> > + * @init: The callback to invoke to perform the debugfs initialization
> > + * @cleanup_cb: The callback to invoke to cleanup any resources for the
> > + * callback
> > + * @data: Data to pass to @init and @cleanup_cb
> > + * @out: Where to store the pointer to the callback struct
> > + *
> > + * Register an initialization callback with debugfs. This callback can be
> > used
> > + * to creating debugfs nodes for DRM resources that might get created
> > before
> > + * the
[Bug 100995] System hang using OpenGL 4+ features
https://bugs.freedesktop.org/show_bug.cgi?id=100995 Paul changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution|--- |FIXED --- Comment #9 from Paul --- (In reply to Timothy Arceri from comment #8) > Is this working for you now? I've since removed linux from the system and handed it down to a family member, so it's not possible for me to test anymore. However I would expect the bug would have been fixed by now, according to the current RadeonFeature support table. -- 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 0/2] drm/nouveau: Use more standard logging styles
For the whole series: Reviewed-by: Lyude Paul Nice catch! On Thu, 2018-08-30 at 11:36 -0700, Joe Perches wrote: > Reduces object size ~4kb > > Joe Perches (2): > drm/nouveau: Add new logging function nv_cli_printk > drm/nouveau: Convert NV_PRINTK macros and uses to new nv_cli_ > macros > > drivers/gpu/drm/nouveau/nouveau_abi16.c | 2 +- > drivers/gpu/drm/nouveau/nouveau_chan.c | 12 +++ > drivers/gpu/drm/nouveau/nouveau_drm.c | 21 +++ > drivers/gpu/drm/nouveau/nouveau_drv.h | 44 ++- > drivers/gpu/drm/nouveau/nouveau_gem.c | 62 > - > 5 files changed, 87 insertions(+), 54 deletions(-) > -- Cheers, Lyude Paul ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] Documentation/fb/vesafb.txt: "inverse" option corrections
On Thu, 16 Aug 2018 21:12:07 -0700 Randy Dunlap wrote: > From: Randy Dunlap > > Spell the vesafb "inverse" option correctly and tell what it does. > Applied, thanks. This is the first nontrivial change to this file since 2005... jon ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 93829] [Wine] Lockup with MotoGP 2
https://bugs.freedesktop.org/show_bug.cgi?id=93829 --- Comment #3 from Clément Guérin --- I will try with my R9 Fury. -- 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 2/2] vgaarb: Keep adding VGA device in queue
If failed to find the deivice owning the boot framebuffer, try to use the first VGA device instead of the last one. Usually the 1st device is integrated GPU who owns the boot framebuffer. Signed-off-by: Aaron Ma --- drivers/gpu/vga/vgaarb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c index 8d90e66994b0..dc8e039bfab5 100644 --- a/drivers/gpu/vga/vgaarb.c +++ b/drivers/gpu/vga/vgaarb.c @@ -676,7 +676,7 @@ static bool vga_arbiter_add_pci_device(struct pci_dev *pdev) vga_arbiter_check_bridge_sharing(vgadev); /* Add to the list */ - list_add(>list, _list); + list_add_tail(>list, _list); vga_count++; vgaarb_info(>dev, "VGA device added: decodes=%s,owns=%s,locks=%s\n", vga_iostate_to_str(vgadev->decodes), -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] vgaarb: Add support for 64-bit frame buffer address
EFI GOP uses 64-bit frame buffer address when some BIOS
disabled CSM support. vgaarb only stores lfb_base,
this will lead boot framebuffer to wrong device.
Add ext_lfb_base support to use 64-bit fb address.
Signed-off-by: Aaron Ma
---
drivers/gpu/vga/vgaarb.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
index c61b04555779..8d90e66994b0 100644
--- a/drivers/gpu/vga/vgaarb.c
+++ b/drivers/gpu/vga/vgaarb.c
@@ -1408,6 +1408,18 @@ static void __init vga_arb_select_default_device(void)
struct vga_device *vgadev;
#if defined(CONFIG_X86) || defined(CONFIG_IA64)
+ u64 base = screen_info.lfb_base;
+ u64 size = screen_info.lfb_size;
+ u64 limit;
+ resource_size_t start, end;
+ unsigned long flags;
+ int i;
+
+ if (screen_info.capabilities & VIDEO_CAPABILITY_64BIT_BASE)
+ base |= (u64)screen_info.ext_lfb_base << 32;
+
+ limit = base + size;
+
list_for_each_entry(vgadev, _list, list) {
struct device *dev = >pdev->dev;
/*
@@ -1418,11 +1430,6 @@ static void __init vga_arb_select_default_device(void)
* Select the device owning the boot framebuffer if there is
* one.
*/
- resource_size_t start, end, limit;
- unsigned long flags;
- int i;
-
- limit = screen_info.lfb_base + screen_info.lfb_size;
/* Does firmware framebuffer belong to us? */
for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
@@ -1437,7 +1444,7 @@ static void __init vga_arb_select_default_device(void)
if (!start || !end)
continue;
- if (screen_info.lfb_base < start || limit >= end)
+ if (base < start || limit >= end)
continue;
if (!vga_default_device())
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 10/14] drm/msm/dpu: move hw resource tracking to crtc state
On Fri, Aug 31, 2018 at 12:22:04PM -0700, Jeykumar Sankaran wrote:
> On 2018-08-31 07:56, Sean Paul wrote:
> > On Tue, Aug 28, 2018 at 05:39:59PM -0700, Jeykumar Sankaran wrote:
> > > Prep changes for state based resource management.
> > >
> > > Moves all the hw block tracking for the crtc to the state
> > > object.
> >
> > Changes in v4...
> >
> > >
> > > Signed-off-by: Jeykumar Sankaran
> > > ---
> > > drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 60
> > ++--
> > > drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 22 ++--
> > > 2 files changed, 44 insertions(+), 38 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> > b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> > > index e061847..7ab320d 100644
> > > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> > > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> > > @@ -163,9 +163,9 @@ static void _dpu_crtc_program_lm_output_roi(struct
> > drm_crtc *crtc)
> > > crtc_state = to_dpu_crtc_state(crtc->state);
> > >
> > > lm_horiz_position = 0;
> > > - for (lm_idx = 0; lm_idx < dpu_crtc->num_mixers; lm_idx++) {
> > > + for (lm_idx = 0; lm_idx < crtc_state->num_mixers; lm_idx++) {
> > > const struct drm_rect *lm_roi =
> > _state->lm_bounds[lm_idx];
> > > - struct dpu_hw_mixer *hw_lm =
> > dpu_crtc->mixers[lm_idx].hw_lm;
> > > + struct dpu_hw_mixer *hw_lm =
> > crtc_state->mixers[lm_idx].hw_lm;
> > > struct dpu_hw_mixer_cfg cfg;
> > >
> > > if (!lm_roi || !drm_rect_visible(lm_roi))
> > > @@ -246,7 +246,7 @@ static void _dpu_crtc_blend_setup_mixer(struct
> > drm_crtc *crtc,
> > > fb ? fb->modifier : 0);
> > >
> > > /* blend config update */
> > > - for (lm_idx = 0; lm_idx < dpu_crtc->num_mixers; lm_idx++)
> > {
> > > + for (lm_idx = 0; lm_idx < cstate->num_mixers; lm_idx++) {
> > > _dpu_crtc_setup_blend_cfg(mixer + lm_idx,
> > > pstate, format);
> > >
> > > @@ -270,7 +270,7 @@ static void _dpu_crtc_blend_setup_mixer(struct
> > drm_crtc *crtc,
> > > static void _dpu_crtc_blend_setup(struct drm_crtc *crtc)
> > > {
> > > struct dpu_crtc *dpu_crtc;
> > > - struct dpu_crtc_state *dpu_crtc_state;
> > > + struct dpu_crtc_state *cstate;
> > > struct dpu_crtc_mixer *mixer;
> > > struct dpu_hw_ctl *ctl;
> > > struct dpu_hw_mixer *lm;
> > > @@ -281,17 +281,17 @@ static void _dpu_crtc_blend_setup(struct
> > > drm_crtc
> > *crtc)
> > > return;
> > >
> > > dpu_crtc = to_dpu_crtc(crtc);
> > > - dpu_crtc_state = to_dpu_crtc_state(crtc->state);
> > > - mixer = dpu_crtc->mixers;
> > > + cstate = to_dpu_crtc_state(crtc->state);
> > > + mixer = cstate->mixers;
> > >
> > > DPU_DEBUG("%s\n", dpu_crtc->name);
> > >
> > > - if (dpu_crtc->num_mixers > CRTC_DUAL_MIXERS) {
> > > - DPU_ERROR("invalid number mixers: %d\n",
> > dpu_crtc->num_mixers);
> > > + if (cstate->num_mixers > CRTC_DUAL_MIXERS) {
> >
> > This is not possible.
> >
> > > + DPU_ERROR("invalid number mixers: %d\n",
> > cstate->num_mixers);
> > > return;
> > > }
> > >
> > > - for (i = 0; i < dpu_crtc->num_mixers; i++) {
> > > + for (i = 0; i < cstate->num_mixers; i++) {
> > > if (!mixer[i].hw_lm || !mixer[i].hw_ctl) {
> > > DPU_ERROR("invalid lm or ctl assigned to
> > mixer\n");
> > > return;
> > > @@ -308,7 +308,7 @@ static void _dpu_crtc_blend_setup(struct drm_crtc
> > *crtc)
> > >
> > > _dpu_crtc_blend_setup_mixer(crtc, dpu_crtc, mixer);
> > >
> > > - for (i = 0; i < dpu_crtc->num_mixers; i++) {
> > > + for (i = 0; i < cstate->num_mixers; i++) {
> > > ctl = mixer[i].hw_ctl;
> > > lm = mixer[i].hw_lm;
> > >
> > > @@ -530,7 +530,7 @@ static void _dpu_crtc_setup_mixer_for_encoder(
> > > struct drm_crtc *crtc,
> > > struct drm_encoder *enc)
> > > {
> > > - struct dpu_crtc *dpu_crtc = to_dpu_crtc(crtc);
> > > + struct dpu_crtc_state *cstate = to_dpu_crtc_state(crtc->state);
> > > struct dpu_kms *dpu_kms = _dpu_crtc_get_kms(crtc);
> > > struct dpu_rm *rm = _kms->rm;
> > > struct dpu_crtc_mixer *mixer;
> > > @@ -542,8 +542,8 @@ static void _dpu_crtc_setup_mixer_for_encoder(
> > > dpu_rm_init_hw_iter(_iter, enc->base.id, DPU_HW_BLK_CTL);
> > >
> > > /* Set up all the mixers and ctls reserved by this encoder */
> > > - for (i = dpu_crtc->num_mixers; i < ARRAY_SIZE(dpu_crtc->mixers);
> > i++) {
> > > - mixer = _crtc->mixers[i];
> > > + for (i = cstate->num_mixers; i < ARRAY_SIZE(cstate->mixers); i++)
> > {
> > > + mixer = >mixers[i];
> > >
> > > if (!dpu_rm_get_hw(rm, _iter))
> > > break;
> > > @@ -568,7 +568,7 @@ static void _dpu_crtc_setup_mixer_for_encoder(
> > >
> > > mixer->encoder = enc;
> > >
> > > - dpu_crtc->num_mixers++;
> > > + cstate->num_mixers++;
> > >
Re: [PATCH 05/14] drm/msm/dpu: enable master-slave encoders explicitly
On Fri, Aug 31, 2018 at 12:16:46PM -0700, Jeykumar Sankaran wrote:
> On 2018-08-30 09:24, Sean Paul wrote:
> > On Tue, Aug 28, 2018 at 05:39:54PM -0700, Jeykumar Sankaran wrote:
> > > Identify slave-master encoders during initialization and enable
> > > the encoders explicitly as the current logic has redundant and
> > > ambiguous loops.
> >
> > Please include a "Changes in vX" section so I don't need to figure it
> > out
> > myself.
> >
> Since I split these clean up changes into a new series, I was not sure
> how to handle the versioning. With "changes in v4" log, Should I also
> change the prefix labeling to [PATCH v4 05/14]? A couple of changes
> are also introduced in this series.
Yeah, sometimes it's best just to choose an arbitrarily high version if multiple
series' are coming together. In this case it's more simple since we're just
adding patches to the series, so v4 would have worked. As far as the new
patches,
just add:
Changed in v4:
- Introduced patch (split from "blah blah")
or
Changed in v4:
- Introduced patch (suggested by Sean)
Sean
>
> Thanks,
> Jeykumar S.
>
> > >
> > > Signed-off-by: Jeykumar Sankaran
> > > ---
> > > drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 46
> > ++---
> > > 1 file changed, 15 insertions(+), 31 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> > b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> > > index 991b22c..b223bd2 100644
> > > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> > > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> > > @@ -180,6 +180,7 @@ struct dpu_encoder_virt {
> > > unsigned int num_phys_encs;
> > > struct dpu_encoder_phys *phys_encs[MAX_PHYS_ENCODERS_PER_VIRTUAL];
> > > struct dpu_encoder_phys *cur_master;
> > > + struct dpu_encoder_phys *cur_slave;
> > > struct dpu_hw_pingpong *hw_pp[MAX_CHANNELS_PER_ENC];
> > >
> > > bool intfs_swapped;
> > > @@ -1141,7 +1142,8 @@ void dpu_encoder_virt_restore(struct drm_encoder
> > *drm_enc)
> > > static void dpu_encoder_virt_enable(struct drm_encoder *drm_enc)
> > > {
> > > struct dpu_encoder_virt *dpu_enc = NULL;
> > > - int i, ret = 0;
> > > + struct dpu_encoder_phys *phys = NULL;
> > > + int ret = 0;
> > > struct drm_display_mode *cur_mode = NULL;
> > >
> > > if (!drm_enc) {
> > > @@ -1154,21 +1156,14 @@ static void dpu_encoder_virt_enable(struct
> > drm_encoder *drm_enc)
> > > trace_dpu_enc_enable(DRMID(drm_enc), cur_mode->hdisplay,
> > >cur_mode->vdisplay);
> > >
> > > - dpu_enc->cur_master = NULL;
> > > - for (i = 0; i < dpu_enc->num_phys_encs; i++) {
> > > - struct dpu_encoder_phys *phys = dpu_enc->phys_encs[i];
> > > + /* always enable slave encoder before master */
> > > + phys = dpu_enc->cur_slave;
> >
> > I think this variable makes things less readable. It made sense in the
> > loop since
> > you're indented an extra level and they're obfuscated anyways, but since
> > they're
> > explicit now, could you please just use dpu_enc->cur_slave/master
> > directly?
> >
> > With this nit and the added changelog in the commit addressed,
> >
> > Reviewed-by: Sean Paul
> >
> >
> > > + if (phys && phys->ops.enable)
> > > + phys->ops.enable(phys);
> > >
> > > - if (phys && phys->ops.is_master &&
> > phys->ops.is_master(phys)) {
> > > - DPU_DEBUG_ENC(dpu_enc, "master is now idx %d\n",
> > i);
> > > - dpu_enc->cur_master = phys;
> > > - break;
> > > - }
> > > - }
> > > -
> > > - if (!dpu_enc->cur_master) {
> > > - DPU_ERROR("virt encoder has no master! num_phys %d\n", i);
> > > - return;
> > > - }
> > > + phys = dpu_enc->cur_master;
> > > + if (phys && phys->ops.enable)
> > > + phys->ops.enable(phys);
> > >
> > > ret = dpu_encoder_resource_control(drm_enc,
> > DPU_ENC_RC_EVENT_KICKOFF);
> > > if (ret) {
> > > @@ -1177,21 +1172,6 @@ static void dpu_encoder_virt_enable(struct
> > drm_encoder *drm_enc)
> > > return;
> > > }
> > >
> > > - for (i = 0; i < dpu_enc->num_phys_encs; i++) {
> > > - struct dpu_encoder_phys *phys = dpu_enc->phys_encs[i];
> > > -
> > > - if (!phys)
> > > - continue;
> > > -
> > > - if (phys != dpu_enc->cur_master) {
> > > - if (phys->ops.enable)
> > > - phys->ops.enable(phys);
> > > - }
> > > - }
> > > -
> > > - if (dpu_enc->cur_master->ops.enable)
> > > - dpu_enc->cur_master->ops.enable(dpu_enc->cur_master);
> > > -
> > > _dpu_encoder_virt_enable_helper(drm_enc);
> > > }
> > >
> > > @@ -2062,6 +2042,11 @@ static int dpu_encoder_virt_add_phys_encs(
> > > ++dpu_enc->num_phys_encs;
> > > }
> > >
> > > + if (params->split_role == ENC_ROLE_SLAVE)
> > > + dpu_enc->cur_slave = enc;
> > > + else
> > > + dpu_enc->cur_master = enc;
> > > +
> > > return 0;
> > > }
> > >
> > > @@ -2228,7 +2213,6 @@ int
Re: [PATCH 10/14] drm/msm/dpu: move hw resource tracking to crtc state
On 2018-08-31 07:56, Sean Paul wrote:
On Tue, Aug 28, 2018 at 05:39:59PM -0700, Jeykumar Sankaran wrote:
Prep changes for state based resource management.
Moves all the hw block tracking for the crtc to the state
object.
Changes in v4...
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 60
++--
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 22 ++--
2 files changed, 44 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index e061847..7ab320d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -163,9 +163,9 @@ static void _dpu_crtc_program_lm_output_roi(struct
drm_crtc *crtc)
crtc_state = to_dpu_crtc_state(crtc->state);
lm_horiz_position = 0;
- for (lm_idx = 0; lm_idx < dpu_crtc->num_mixers; lm_idx++) {
+ for (lm_idx = 0; lm_idx < crtc_state->num_mixers; lm_idx++) {
const struct drm_rect *lm_roi =
_state->lm_bounds[lm_idx];
- struct dpu_hw_mixer *hw_lm =
dpu_crtc->mixers[lm_idx].hw_lm;
+ struct dpu_hw_mixer *hw_lm =
crtc_state->mixers[lm_idx].hw_lm;
struct dpu_hw_mixer_cfg cfg;
if (!lm_roi || !drm_rect_visible(lm_roi))
@@ -246,7 +246,7 @@ static void _dpu_crtc_blend_setup_mixer(struct
drm_crtc *crtc,
fb ? fb->modifier : 0);
/* blend config update */
- for (lm_idx = 0; lm_idx < dpu_crtc->num_mixers; lm_idx++)
{
+ for (lm_idx = 0; lm_idx < cstate->num_mixers; lm_idx++) {
_dpu_crtc_setup_blend_cfg(mixer + lm_idx,
pstate, format);
@@ -270,7 +270,7 @@ static void _dpu_crtc_blend_setup_mixer(struct
drm_crtc *crtc,
static void _dpu_crtc_blend_setup(struct drm_crtc *crtc)
{
struct dpu_crtc *dpu_crtc;
- struct dpu_crtc_state *dpu_crtc_state;
+ struct dpu_crtc_state *cstate;
struct dpu_crtc_mixer *mixer;
struct dpu_hw_ctl *ctl;
struct dpu_hw_mixer *lm;
@@ -281,17 +281,17 @@ static void _dpu_crtc_blend_setup(struct
drm_crtc
*crtc)
return;
dpu_crtc = to_dpu_crtc(crtc);
- dpu_crtc_state = to_dpu_crtc_state(crtc->state);
- mixer = dpu_crtc->mixers;
+ cstate = to_dpu_crtc_state(crtc->state);
+ mixer = cstate->mixers;
DPU_DEBUG("%s\n", dpu_crtc->name);
- if (dpu_crtc->num_mixers > CRTC_DUAL_MIXERS) {
- DPU_ERROR("invalid number mixers: %d\n",
dpu_crtc->num_mixers);
+ if (cstate->num_mixers > CRTC_DUAL_MIXERS) {
This is not possible.
+ DPU_ERROR("invalid number mixers: %d\n",
cstate->num_mixers);
return;
}
- for (i = 0; i < dpu_crtc->num_mixers; i++) {
+ for (i = 0; i < cstate->num_mixers; i++) {
if (!mixer[i].hw_lm || !mixer[i].hw_ctl) {
DPU_ERROR("invalid lm or ctl assigned to
mixer\n");
return;
@@ -308,7 +308,7 @@ static void _dpu_crtc_blend_setup(struct drm_crtc
*crtc)
_dpu_crtc_blend_setup_mixer(crtc, dpu_crtc, mixer);
- for (i = 0; i < dpu_crtc->num_mixers; i++) {
+ for (i = 0; i < cstate->num_mixers; i++) {
ctl = mixer[i].hw_ctl;
lm = mixer[i].hw_lm;
@@ -530,7 +530,7 @@ static void _dpu_crtc_setup_mixer_for_encoder(
struct drm_crtc *crtc,
struct drm_encoder *enc)
{
- struct dpu_crtc *dpu_crtc = to_dpu_crtc(crtc);
+ struct dpu_crtc_state *cstate = to_dpu_crtc_state(crtc->state);
struct dpu_kms *dpu_kms = _dpu_crtc_get_kms(crtc);
struct dpu_rm *rm = _kms->rm;
struct dpu_crtc_mixer *mixer;
@@ -542,8 +542,8 @@ static void _dpu_crtc_setup_mixer_for_encoder(
dpu_rm_init_hw_iter(_iter, enc->base.id, DPU_HW_BLK_CTL);
/* Set up all the mixers and ctls reserved by this encoder */
- for (i = dpu_crtc->num_mixers; i < ARRAY_SIZE(dpu_crtc->mixers);
i++) {
- mixer = _crtc->mixers[i];
+ for (i = cstate->num_mixers; i < ARRAY_SIZE(cstate->mixers); i++)
{
+ mixer = >mixers[i];
if (!dpu_rm_get_hw(rm, _iter))
break;
@@ -568,7 +568,7 @@ static void _dpu_crtc_setup_mixer_for_encoder(
mixer->encoder = enc;
- dpu_crtc->num_mixers++;
+ cstate->num_mixers++;
DPU_DEBUG("setup mixer %d: lm %d\n",
i, mixer->hw_lm->idx - LM_0);
DPU_DEBUG("setup mixer %d: ctl %d\n",
@@ -579,11 +579,11 @@ static void _dpu_crtc_setup_mixer_for_encoder(
static void _dpu_crtc_setup_mixers(struct drm_crtc *crtc)
{
struct dpu_crtc *dpu_crtc = to_dpu_crtc(crtc);
+ struct dpu_crtc_state
[Bug 107045] [4.18rc2] RX470 dGPU on hybrid laptop freezes screen after use
https://bugs.freedesktop.org/show_bug.cgi?id=107045 --- Comment #23 from taij...@posteo.de --- Oh, and before I forget - GNOME bug is here: https://gitlab.gnome.org/GNOME/gnome-settings-daemon/issues/53 -- 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 107045] [4.18rc2] RX470 dGPU on hybrid laptop freezes screen after use
https://bugs.freedesktop.org/show_bug.cgi?id=107045 --- Comment #22 from taij...@posteo.de --- OK, after some further testing, here is some more information on my issue: 1) It turns out that the crashing/hanging behaviour ONLY happens when I'm logged into a graphical session (GNOME in my case). When working exclusively from a tty, then the system remains stable. 2) A Wayland session seems to be slightly more stable/resillient to crashing than an X11 session. While the latter crashes almost immediately when doing anything with the backlight, the former goes through a couple of cycles of extreme lag, stuttering and recovery before finally succumbing to whatever the problem is. 3) I can reliably and reproduceably crash my graphical session by messing with screen brightness in any way - either through the tools of the graphical shell or by doing #echo X > /sys/class/backlight/intel_backlight/brightness. 4) Why is this an amdgpu bug then? Because the issue only arises when amdgpu is loaded in DC mode, because in this mode the display connectors directly connected to the dGPU (DP, eDP and HDMI) are being ennumerated. With dc=0 they are not recognized and can therefore not create any problems. 5) What I think happens is that the graphical shell tries to adjust brightness on the displays that are ennumerated as connectors but not actually connected, and by doing so eventually get amdgpu to crash irrecoverably. 6) When intel_backlight gets manipulated, the following always shows up in dmesg (the first couple of times the dGPU gets to the 'reset', at some point is just crashes before that, taking the system with it). Aug 31 17:58:54 alien-arch kernel: [drm] PCIE GART of 256M enabled (table at 0x00F4). Aug 31 17:58:54 alien-arch kernel: amdgpu: [powerplay] failed to send message 62 ret is 0 Aug 31 17:58:54 alien-arch kernel: amdgpu: [powerplay] last message was failed ret is 0 Aug 31 17:58:55 alien-arch kernel: amdgpu: [powerplay] failed to send message 18f ret is 0 Aug 31 17:58:55 alien-arch kernel: [drm] UVD and UVD ENC initialized successfully. Aug 31 17:58:55 alien-arch kernel: [drm] VCE initialized successfully. Aug 31 17:58:56 alien-arch kernel: [drm] Cannot find any crtc or sizes Aug 31 17:58:57 alien-arch kernel: amdgpu: [powerplay] failed to send message 15b ret is 0 Aug 31 17:58:58 alien-arch kernel: amdgpu: [powerplay] failed to send message 155 ret is 0 Aug 31 17:59:06 alien-arch kernel: amdgpu: [powerplay] failed to send message 281 ret is 0 Aug 31 17:59:07 alien-arch kernel: amdgpu: [powerplay] last message was failed ret is 0 Aug 31 17:59:07 alien-arch kernel: amdgpu: [powerplay] failed to send message 261 ret is 0 Aug 31 17:59:08 alien-arch kernel: amdgpu: [powerplay] last message was failed ret is 0 Aug 31 17:59:08 alien-arch kernel: amdgpu: [powerplay] failed to send message 261 ret is 0 Aug 31 17:59:09 alien-arch kernel: amdgpu: [powerplay] last message was failed ret is 0 Aug 31 17:59:10 alien-arch kernel: amdgpu: [powerplay] failed to send message 261 ret is 0 Aug 31 17:59:10 alien-arch kernel: amdgpu: [powerplay] last message was failed ret is 0 Aug 31 17:59:11 alien-arch kernel: amdgpu: [powerplay] failed to send message 261 ret is 0 Aug 31 17:59:12 alien-arch kernel: amdgpu: [powerplay] last message was failed ret is 0 Aug 31 17:59:12 alien-arch kernel: amdgpu: [powerplay] failed to send message 261 ret is 0 Aug 31 17:59:13 alien-arch kernel: amdgpu: [powerplay] last message was failed ret is 0 Aug 31 17:59:13 alien-arch kernel: amdgpu: [powerplay] failed to send message 261 ret is 0 Aug 31 17:59:14 alien-arch kernel: amdgpu: [powerplay] last message was failed ret is 0 Aug 31 17:59:14 alien-arch kernel: amdgpu: [powerplay] failed to send message 261 ret is 0 Aug 31 17:59:14 alien-arch kernel: amdgpu :01:00.0: GPU pci config reset -- 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 05/14] drm/msm/dpu: enable master-slave encoders explicitly
On 2018-08-30 09:24, Sean Paul wrote:
On Tue, Aug 28, 2018 at 05:39:54PM -0700, Jeykumar Sankaran wrote:
Identify slave-master encoders during initialization and enable
the encoders explicitly as the current logic has redundant and
ambiguous loops.
Please include a "Changes in vX" section so I don't need to figure it
out
myself.
Since I split these clean up changes into a new series, I was not sure
how to handle the versioning. With "changes in v4" log, Should I also
change the prefix labeling to [PATCH v4 05/14]? A couple of changes
are also introduced in this series.
Thanks,
Jeykumar S.
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 46
++---
1 file changed, 15 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 991b22c..b223bd2 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -180,6 +180,7 @@ struct dpu_encoder_virt {
unsigned int num_phys_encs;
struct dpu_encoder_phys *phys_encs[MAX_PHYS_ENCODERS_PER_VIRTUAL];
struct dpu_encoder_phys *cur_master;
+ struct dpu_encoder_phys *cur_slave;
struct dpu_hw_pingpong *hw_pp[MAX_CHANNELS_PER_ENC];
bool intfs_swapped;
@@ -1141,7 +1142,8 @@ void dpu_encoder_virt_restore(struct drm_encoder
*drm_enc)
static void dpu_encoder_virt_enable(struct drm_encoder *drm_enc)
{
struct dpu_encoder_virt *dpu_enc = NULL;
- int i, ret = 0;
+ struct dpu_encoder_phys *phys = NULL;
+ int ret = 0;
struct drm_display_mode *cur_mode = NULL;
if (!drm_enc) {
@@ -1154,21 +1156,14 @@ static void dpu_encoder_virt_enable(struct
drm_encoder *drm_enc)
trace_dpu_enc_enable(DRMID(drm_enc), cur_mode->hdisplay,
cur_mode->vdisplay);
- dpu_enc->cur_master = NULL;
- for (i = 0; i < dpu_enc->num_phys_encs; i++) {
- struct dpu_encoder_phys *phys = dpu_enc->phys_encs[i];
+ /* always enable slave encoder before master */
+ phys = dpu_enc->cur_slave;
I think this variable makes things less readable. It made sense in the
loop since
you're indented an extra level and they're obfuscated anyways, but
since
they're
explicit now, could you please just use dpu_enc->cur_slave/master
directly?
With this nit and the added changelog in the commit addressed,
Reviewed-by: Sean Paul
+ if (phys && phys->ops.enable)
+ phys->ops.enable(phys);
- if (phys && phys->ops.is_master &&
phys->ops.is_master(phys)) {
- DPU_DEBUG_ENC(dpu_enc, "master is now idx %d\n",
i);
- dpu_enc->cur_master = phys;
- break;
- }
- }
-
- if (!dpu_enc->cur_master) {
- DPU_ERROR("virt encoder has no master! num_phys %d\n", i);
- return;
- }
+ phys = dpu_enc->cur_master;
+ if (phys && phys->ops.enable)
+ phys->ops.enable(phys);
ret = dpu_encoder_resource_control(drm_enc,
DPU_ENC_RC_EVENT_KICKOFF);
if (ret) {
@@ -1177,21 +1172,6 @@ static void dpu_encoder_virt_enable(struct
drm_encoder *drm_enc)
return;
}
- for (i = 0; i < dpu_enc->num_phys_encs; i++) {
- struct dpu_encoder_phys *phys = dpu_enc->phys_encs[i];
-
- if (!phys)
- continue;
-
- if (phys != dpu_enc->cur_master) {
- if (phys->ops.enable)
- phys->ops.enable(phys);
- }
- }
-
- if (dpu_enc->cur_master->ops.enable)
- dpu_enc->cur_master->ops.enable(dpu_enc->cur_master);
-
_dpu_encoder_virt_enable_helper(drm_enc);
}
@@ -2062,6 +2042,11 @@ static int dpu_encoder_virt_add_phys_encs(
++dpu_enc->num_phys_encs;
}
+ if (params->split_role == ENC_ROLE_SLAVE)
+ dpu_enc->cur_slave = enc;
+ else
+ dpu_enc->cur_master = enc;
+
return 0;
}
@@ -2228,7 +2213,6 @@ int dpu_encoder_setup(struct drm_device *dev,
struct drm_encoder *enc,
if (ret)
goto fail;
- dpu_enc->cur_master = NULL;
spin_lock_init(_enc->enc_spinlock);
atomic_set(_enc->frame_done_timeout, 0);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum,
a Linux Foundation Collaborative Project
--
Jeykumar S
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105251] [Vega10] GPU lockup on boot: VMC page fault
https://bugs.freedesktop.org/show_bug.cgi?id=105251
--- Comment #47 from Marek Olšák ---
The log is truncated for some reason. Can you apply this to make it shorter?
diff --git a/src/gallium/drivers/radeonsi/si_debug.c
b/src/gallium/drivers/radeonsi/si_debug.c
index 5e80469cee1..325e1e3ed01 100644
--- a/src/gallium/drivers/radeonsi/si_debug.c
+++ b/src/gallium/drivers/radeonsi/si_debug.c
@@ -101,6 +101,7 @@ static void si_dump_shader(struct si_screen *sscreen,
enum pipe_shader_type processor,
const struct si_shader *shader, FILE *f)
{
+ return;
if (shader->shader_log)
fwrite(shader->shader_log, shader->shader_log_size, 1, f);
else
--
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 107689] System freezes on shutdown. [drm:gfx_v8_0_hw_fini [amdgpu]] *ERROR* KCQ disabled failed (scratch(0xC040)=0xCAFEDEAD)
https://bugs.freedesktop.org/show_bug.cgi?id=107689 --- Comment #7 from john-s...@gmx.net --- What I have done: - Applied the patches - Pressed the power on button for suspend - Pressed the power on button again for resume - Copy and paste the dmesg log How critical are these errors? Respectively, which error causes the error state? 1. amdgpu: [powerplay] Voltage value looks like a Leakage ID but it's not patched 2. amdgpu: [powerplay] failed to send message 254 ret is 0 3. [drm:gfx_v8_0_ring_test_ring [amdgpu]] *ERROR* amdgpu: ring 0 test failed (scratch(0xC040)=0xCAFEDEAD) [drm:amdgpu_device_ip_resume_phase2 [amdgpu]] *ERROR* resume of IP block failed -22 [drm:amdgpu_device_resume [amdgpu]] *ERROR* amdgpu_device_ip_resume failed (-22). [drm:gfx_v8_0_ring_test_ring [amdgpu]] *ERROR* amdgpu: ring 9 test failed (scratch(0xC040)=0xCAFEDEAD) [drm:gfx_v8_0_hw_fini [amdgpu]] *ERROR* KCQ disable failed 4. amdgpu :01:00.0: kfd not supported on this ASIC 5. amdgpu: [powerplay] Failed to retrieve minimum clocks. amdgpu: [powerplay] Error in phm_get_clock_info 6. [drm:dc_create [amdgpu]] *ERROR* DC: Number of connectors is zero! -- 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 1/3] drm: rcar-du: Update Gen3 output limitations
The R-Car Gen3 DU utilises the VSP1 hardware for memory access. The
limits on the RPF and WPF in this pipeline are 8190x8190.
Update the supported maximum sizes accordingly.
Signed-off-by: Kieran Bingham
---
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index ed7fa3204892..7c7aff8cdf77 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -512,12 +512,22 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu)
dev->mode_config.min_width = 0;
dev->mode_config.min_height = 0;
- dev->mode_config.max_width = 4095;
- dev->mode_config.max_height = 2047;
dev->mode_config.normalize_zpos = true;
dev->mode_config.funcs = _du_mode_config_funcs;
dev->mode_config.helper_private = _du_mode_config_helper;
+ if (rcdu->info->gen < 3) {
+ dev->mode_config.max_width = 4095;
+ dev->mode_config.max_height = 2047;
+ } else {
+ /*
+* The Gen3 DU uses the VSP1 for memory access, and is limited
+* to frame sizes of 8190x8190.
+*/
+ dev->mode_config.max_width = 8190;
+ dev->mode_config.max_height = 8190;
+ }
+
rcdu->num_crtcs = hweight8(rcdu->info->channels_mask);
ret = rcar_du_properties_init(rcdu);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/3] drm: rcar-du: Update DU support
3 patches to remove current limitations in the DU. Image formats that the hardware is capable of were not listed in the driver, and are added by Koji Masuoka. Frame sizes on Gen3 platforms were artificially limited to the Gen2 framesizes, and so this has been lifted to support larger displays such as 4K outputs. Finally restrictions on the framebuffer strides and alignments are lifted due to the greater flexibility of the VSP. Kieran Bingham (1): drm: rcar-du: Update Gen3 output limitations Koji Matsuoka (1): drm: rcar-du: Add pixel format support Laurent Pinchart (1): drm: rcar-du: Update framebuffer pitch and alignment limits for Gen3 drivers/gpu/drm/rcar-du/rcar_du_kms.c | 81 ++- 1 file changed, 67 insertions(+), 14 deletions(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm: rcar-du: Update framebuffer pitch and alignment limits for Gen3
From: Laurent Pinchart
The framebuffer pitch and alignment constraints reflect the limitations
of the Gen2 DU hardware. On Gen3, the DU has no memory interface and
thus doesn't impose any constraint. The limitations come instead from
the VSP that has a limit of 65535 bytes for the pitch and no alignment
constraint. Update the checks accordingly.
Signed-off-by: Laurent Pinchart
Signed-off-by: Kieran Bingham
---
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 35 ++-
1 file changed, 23 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index d1bd174ec893..1d5f49503b93 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -204,7 +204,6 @@ rcar_du_fb_create(struct drm_device *dev, struct drm_file
*file_priv,
const struct rcar_du_format_info *format;
unsigned int max_pitch;
unsigned int align;
- unsigned int bpp;
unsigned int i;
format = rcar_du_format_info(mode_cmd->pixel_format);
@@ -214,20 +213,32 @@ rcar_du_fb_create(struct drm_device *dev, struct drm_file
*file_priv,
return ERR_PTR(-EINVAL);
}
- /*
-* The pitch and alignment constraints are expressed in pixels on the
-* hardware side and in bytes in the DRM API.
-*/
- bpp = format->planes == 1 ? format->bpp / 8 : 1;
- max_pitch = 4096 * bpp;
+ if (rcdu->info->gen < 3) {
+ /*
+* On Gen2 the DU limits the pitch to 4095 pixels and requires
+* buffers to be aligned to a 16 pixels boundary (or 128 bytes
+* on some platforms).
+*/
+ unsigned int bpp = format->planes == 1 ? format->bpp / 8 : 1;
- if (rcar_du_needs(rcdu, RCAR_DU_QUIRK_ALIGN_128B))
- align = 128;
- else
- align = 16 * bpp;
+ max_pitch = 4095 * bpp;
+
+ if (rcar_du_needs(rcdu, RCAR_DU_QUIRK_ALIGN_128B))
+ align = 128;
+ else
+ align = 16 * bpp;
+ } else {
+ /*
+* On Gen3 the memory interface is handled by the VSP that
+* limits the pitch to 65535 bytes and has no alignment
+* constraint.
+*/
+ max_pitch = 65535;
+ align = 1;
+ }
if (mode_cmd->pitches[0] & (align - 1) ||
- mode_cmd->pitches[0] >= max_pitch) {
+ mode_cmd->pitches[0] > max_pitch) {
dev_dbg(dev->dev, "invalid pitch value %u\n",
mode_cmd->pitches[0]);
return ERR_PTR(-EINVAL);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm: rcar-du: Add pixel format support
From: Koji Matsuoka
This patch supports pixel format of RGB332, ARGB, XRGB,
BGR888, RGB888, BGRA, BGRX and YVYU.
VYUY pixel format is not supported by H/W specification.
Signed-off-by: Koji Matsuoka
Signed-off-by: Kieran Bingham
---
This patch does not remove existing support for multiplanar YVUY, even
though the hardware does not explicitly provide it, because we support
it through software by swapping the plane buffers.
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 32 +++
1 file changed, 32 insertions(+)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index 7c7aff8cdf77..d1bd174ec893 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -124,6 +124,38 @@ static const struct rcar_du_format_info
rcar_du_format_infos[] = {
.fourcc = DRM_FORMAT_YVU444,
.bpp = 24,
.planes = 3,
+ }, {
+ .fourcc = DRM_FORMAT_RGB332,
+ .bpp = 8,
+ .planes = 1,
+ }, {
+ .fourcc = DRM_FORMAT_ARGB,
+ .bpp = 16,
+ .planes = 1,
+ }, {
+ .fourcc = DRM_FORMAT_XRGB,
+ .bpp = 16,
+ .planes = 1,
+ }, {
+ .fourcc = DRM_FORMAT_BGR888,
+ .bpp = 24,
+ .planes = 1,
+ }, {
+ .fourcc = DRM_FORMAT_RGB888,
+ .bpp = 24,
+ .planes = 1,
+ }, {
+ .fourcc = DRM_FORMAT_BGRA,
+ .bpp = 32,
+ .planes = 1,
+ }, {
+ .fourcc = DRM_FORMAT_BGRX,
+ .bpp = 32,
+ .planes = 1,
+ }, {
+ .fourcc = DRM_FORMAT_YVYU,
+ .bpp = 16,
+ .planes = 1,
},
};
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Question on 640x480 @ 72fps
Hi Sean/Ville
Thanks for the comments.
This mode 640x480 @ 72Hz comes directly from the VESA spec ( DMT
Standards and Guidelines Summary ).
Yes, I understand that the hardware will still be running at 72.8 Hz.
The background behind the test is its actually testing out the EDID
parser with different EDID blobs to make sure the modes
are populated correctly and this rounding introduces a mismatch between
the expected and observed mode.
This is not a functionality failure OR any incorrect visual behavior at
this point but just an error captured from the parsed result.
Hence we wanted to highlight it.
I agree that DIV_ROUND_CLOSEST is the way to go but due to this specific
mode, the parsed result is incorrect.
Looking at the larger picture, if we should ignore this, we will do
that.
Thanks
Abhinav
On 2018-08-31 05:23, Sean Paul wrote:
On Thu, Aug 30, 2018 at 07:32:58PM -0700, abhin...@codeaurora.org
wrote:
Hello
During one of our internal tests, we ran into an issue where the
calculated
refresh rate for the mode using the drm_mode_vrefresh() API doesnt
match the theoretical value due to rounding.
552{ DRM_MODE("640x480", DRM_MODE_TYPE_DRIVER, 31500, 640, 664,
553 704, 832, 0, 480, 489, 492, 520, 0,
554 DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC) }, /*
640x480@72Hz */
int drm_mode_vrefresh(const struct drm_display_mode *mode)
{
int refresh = 0;
if (mode->vrefresh > 0)
refresh = mode->vrefresh;
else if (mode->htotal > 0 && mode->vtotal > 0) {
unsigned int num, den;
num = mode->clock * 1000;
den = mode->htotal * mode->vtotal;
if (mode->flags & DRM_MODE_FLAG_INTERLACE)
num *= 2;
if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
den *= 2;
if (mode->vscan > 1)
den *= mode->vscan;
refresh = DIV_ROUND_CLOSEST(num, den);
}
return refresh;
}
EXPORT_SYMBOL(drm_mode_vrefresh);
As per the math of this API, the vrefresh comes up to 72.8 fps ( 31500
*
1000 ) / (832 * 520) .
Hence this gets rounded to 73fps.
However as per the spec, this mode should have the vrefresh as 72fps.
I'm not sure where the official spec is, but this random webpage [1] I
found with
Google has the same timing values as you have above. The timing
information for
the mode doesn't specify the refresh rate, but rather the pclk. The
refresh rate
comes from (pclk / (vtotal * htotal)), which comes out to 72.8Hz. We
have to
round one way or the other, so DIV_ROUND_CLOSEST is more correct.
Like Ville said, the rounding doesn't really make a difference. Since
we'll be
generating the correct pixel clock with the correct pitch, the hardware
will be
operating with a 72.8Hz refresh.
Hopefully that makes sense?
Sean
[1] http://martin.hinner.info/vga/timing.html
So to satisfy that, we must round-down in this function. That might
break
other modes though.
Do you have any suggestions on how to fix-up this mode ? Shall we just
directly specify the vrefresh in the edid_est_modes[] and
drm_dmt_modes[]
static array?
I can submit a PATCH based on the approach we agree on here.
Thanks
Abhinav
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm/dpu: Remove dpu_mdss_isr when dpu_mdss_destroy is called
On Tue, Aug 28, 2018 at 03:23:04PM -0600, Jordan Crouse wrote:
> The MDSS device is created before the MSM driver attempts to bind the
> sub components. If any of the components return -EPROBE_DEFER the MDSS
> device is destroyed and tried again later.
>
> If this happens the "dpu_mdss_isr" interrupt created from the DPU MDSS
> is not freed when the MDSS device is destroyed and has a risk of
> triggering later and hitting a fault by accessing a mmio region that
> no longer exists. Even if the interrupt isn't triggered by
> accident when the device attempts to reprobe it would error out
> when it tries to re-register the interrupt so unconditionally removing
> it in the destroy is the right move.
>
> Switch the device managed "dpu_mdss_isr" to be unmanaged and add a
> free_irq() in the mdss destroy function.
>
> Signed-off-by: Jordan Crouse
Reviewed-by: Sean Paul
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
> index 9e533b86682c..2235ef8129f4 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
> @@ -158,6 +158,8 @@ static void dpu_mdss_destroy(struct drm_device *dev)
>
> _dpu_mdss_irq_domain_fini(dpu_mdss);
>
> + free_irq(platform_get_irq(pdev, 0), dpu_mdss);
> +
> msm_dss_put_clk(mp->clk_config, mp->num_clk);
> devm_kfree(>dev, mp->clk_config);
>
> @@ -215,7 +217,7 @@ int dpu_mdss_init(struct drm_device *dev)
> if (ret)
> goto irq_domain_error;
>
> - ret = devm_request_irq(dev->dev, platform_get_irq(pdev, 0),
> + ret = request_irq(platform_get_irq(pdev, 0),
> dpu_mdss_irq, 0, "dpu_mdss_isr", dpu_mdss);
> if (ret) {
> DPU_ERROR("failed to init irq: %d\n", ret);
> --
> 2.18.0
>
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/5] drm: Add support for handling linear tile formats
On Fri, Aug 31, 2018 at 05:12:24PM +0200, Daniel Vetter wrote:
> On Fri, Aug 31, 2018 at 02:20:31PM +0300, Ville Syrjälä wrote:
> > On Fri, Aug 31, 2018 at 10:14:14AM +0200, Daniel Vetter wrote:
> > > On Thu, Aug 23, 2018 at 06:43:40PM +0100, Alexandru-Cosmin Gheorghe wrote:
> > > > On Wed, Aug 22, 2018 at 10:18:51PM +0200, Daniel Vetter wrote:
> > > > > On Tue, Aug 21, 2018 at 07:30:03PM +0100, Alexandru Gheorghe wrote:
> > > > > > The previous patch added tile_w and tile_h, which represent the
> > > > > > horizontal and vertical sizes of a tile.
> > > > > >
> > > > > > This one uses that to plumb through drm core in order to be able to
> > > > > > handle linear tile formats without the need for drivers to roll up
> > > > > > their own implementation.
> > > > > >
> > > > > > This patch had been written with Mali-dp X0L2 and X0L0 in mind which
> > > > > > is a 1 plane YCbCr 420 format with a 2x2 tile, that uses in average
> > > > > > 2
> > > > > > bytes per pixel and where tiles are laid out in a linear manner.
> > > > > >
> > > > > > Now what are the restrictions:
> > > > > >
> > > > > > 1. Pitch in bytes is expected to cover at least tile_h * width in
> > > > > > pixels. Due to this the places where the pitch is checked/used need
> > > > > > to
> > > > > > be updated to take into consideration the tile_w, tile_h and
> > > > > > tile_size.
> > > > > > tile_size = cpp * tile_w * tile_h
> > > > > >
> > > > > > 2. When doing source cropping plane_src_x/y need to be a multiple of
> > > > > > tile_w/tile_h and we need to take into consideration the
> > > > > > tile_w/tile_h
> > > > > > when computing the start address.
> > > > > >
> > > > > > For all non-tiled formats the tile_w and tile_h will be 1, so if I
> > > > > > didn't miss anything nothing should change.
> > > > > >
> > > > > > Regarding multi-planar linear tile formats, I'm not sure how those
> > > > > > should be handle I kind of assumed that tile_h/tile_w will have to
> > > > > > be
> > > > > > divided by horizontal/subsampling. Anyway, I think it's best to just
> > > > > > put an warning in there and handle it when someone tries to add
> > > > > > support for them.
> > > > > >
> > > > > > Signed-off-by: Alexandru Gheorghe
> > > > > >
> > > > > > ---
> > > > > > drivers/gpu/drm/drm_atomic.c | 8 +++
> > > > > > drivers/gpu/drm/drm_fb_cma_helper.c | 11 -
> > > > > > drivers/gpu/drm/drm_fourcc.c | 52
> > > > > >
> > > > > > drivers/gpu/drm/drm_framebuffer.c| 19 +--
> > > > > > drivers/gpu/drm/drm_gem_framebuffer_helper.c | 10 ++--
> > > > > > include/drm/drm_fourcc.h | 2 +
> > > > > > 6 files changed, 94 insertions(+), 8 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/drm_atomic.c
> > > > > > b/drivers/gpu/drm/drm_atomic.c
> > > > > > index 3eb061e11e2e..7a3e893a4cd1 100644
> > > > > > --- a/drivers/gpu/drm/drm_atomic.c
> > > > > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > > > > @@ -1087,6 +1087,14 @@ static int drm_atomic_plane_check(struct
> > > > > > drm_plane *plane,
> > > > > > return -ENOSPC;
> > > > > > }
> > > > > >
> > > > > > + /* Make sure source coordinates are a multiple of tile sizes */
> > > > > > + if ((state->src_x >> 16) % state->fb->format->tile_w ||
> > > > > > + (state->src_y >> 16) % state->fb->format->tile_h) {
> > > > > > + DRM_DEBUG_ATOMIC("[PLANE:%d:%s] Source coordinates do
> > > > > > not meet tile restrictions",
> > > > > > +plane->base.id, plane->name);
> > > > > > + return -EINVAL;
> > > > > > + }
> > > > > > +
> > > > > > if (plane_switching_crtc(state->state, plane, state)) {
> > > > > > DRM_DEBUG_ATOMIC("[PLANE:%d:%s] switching CRTC
> > > > > > directly\n",
> > > > > > plane->base.id, plane->name);
> > > > > > diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
> > > > > > b/drivers/gpu/drm/drm_fb_cma_helper.c
> > > > > > index 47e0e2f6642d..4d8052adce67 100644
> > > > > > --- a/drivers/gpu/drm/drm_fb_cma_helper.c
> > > > > > +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
> > > > > > @@ -87,6 +87,8 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct
> > > > > > drm_framebuffer *fb,
> > > > > > struct drm_gem_cma_object *obj;
> > > > > > dma_addr_t paddr;
> > > > > > u8 h_div = 1, v_div = 1;
> > > > > > + u32 tile_w = drm_format_tile_width(fb->format, plane);
> > > > > > + u32 tile_h = drm_format_tile_height(fb->format, plane);
> > > > > >
> > > > > > obj = drm_fb_cma_get_gem_obj(fb, plane);
> > > > > > if (!obj)
> > > > > > @@ -99,8 +101,13 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct
> > > > > > drm_framebuffer *fb,
> > > > > > v_div = fb->format->vsub;
> > > > > > }
> > > > > >
> > > > > > - paddr += (fb->format->cpp[plane] * (state->src_x >> 16)) /
> > > > > > h_div;
> > > > > > - paddr +=
Re: [PATCH v2 4/5] drm: Add support for handling linear tile formats
Hi,
On Fri, Aug 31, 2018 at 05:12:24PM +0200, Daniel Vetter wrote:
> On Fri, Aug 31, 2018 at 02:20:31PM +0300, Ville Syrjälä wrote:
> > On Fri, Aug 31, 2018 at 10:14:14AM +0200, Daniel Vetter wrote:
> > > On Thu, Aug 23, 2018 at 06:43:40PM +0100, Alexandru-Cosmin Gheorghe wrote:
> > > > On Wed, Aug 22, 2018 at 10:18:51PM +0200, Daniel Vetter wrote:
> > > > > On Tue, Aug 21, 2018 at 07:30:03PM +0100, Alexandru Gheorghe wrote:
> > > > > > The previous patch added tile_w and tile_h, which represent the
> > > > > > horizontal and vertical sizes of a tile.
> > > > > >
> > > > > > This one uses that to plumb through drm core in order to be able to
> > > > > > handle linear tile formats without the need for drivers to roll up
> > > > > > their own implementation.
> > > > > >
> > > > > > This patch had been written with Mali-dp X0L2 and X0L0 in mind which
> > > > > > is a 1 plane YCbCr 420 format with a 2x2 tile, that uses in average
> > > > > > 2
> > > > > > bytes per pixel and where tiles are laid out in a linear manner.
> > > > > >
> > > > > > Now what are the restrictions:
> > > > > >
> > > > > > 1. Pitch in bytes is expected to cover at least tile_h * width in
> > > > > > pixels. Due to this the places where the pitch is checked/used need
> > > > > > to
> > > > > > be updated to take into consideration the tile_w, tile_h and
> > > > > > tile_size.
> > > > > > tile_size = cpp * tile_w * tile_h
> > > > > >
> > > > > > 2. When doing source cropping plane_src_x/y need to be a multiple of
> > > > > > tile_w/tile_h and we need to take into consideration the
> > > > > > tile_w/tile_h
> > > > > > when computing the start address.
> > > > > >
> > > > > > For all non-tiled formats the tile_w and tile_h will be 1, so if I
> > > > > > didn't miss anything nothing should change.
> > > > > >
> > > > > > Regarding multi-planar linear tile formats, I'm not sure how those
> > > > > > should be handle I kind of assumed that tile_h/tile_w will have to
> > > > > > be
> > > > > > divided by horizontal/subsampling. Anyway, I think it's best to just
> > > > > > put an warning in there and handle it when someone tries to add
> > > > > > support for them.
> > > > > >
> > > > > > Signed-off-by: Alexandru Gheorghe
> > > > > >
> > > > > > ---
> > > > > > drivers/gpu/drm/drm_atomic.c | 8 +++
> > > > > > drivers/gpu/drm/drm_fb_cma_helper.c | 11 -
> > > > > > drivers/gpu/drm/drm_fourcc.c | 52
> > > > > >
> > > > > > drivers/gpu/drm/drm_framebuffer.c| 19 +--
> > > > > > drivers/gpu/drm/drm_gem_framebuffer_helper.c | 10 ++--
> > > > > > include/drm/drm_fourcc.h | 2 +
> > > > > > 6 files changed, 94 insertions(+), 8 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/drm_atomic.c
> > > > > > b/drivers/gpu/drm/drm_atomic.c
> > > > > > index 3eb061e11e2e..7a3e893a4cd1 100644
> > > > > > --- a/drivers/gpu/drm/drm_atomic.c
> > > > > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > > > > @@ -1087,6 +1087,14 @@ static int drm_atomic_plane_check(struct
> > > > > > drm_plane *plane,
> > > > > > return -ENOSPC;
> > > > > > }
> > > > > >
> > > > > > + /* Make sure source coordinates are a multiple of tile sizes */
> > > > > > + if ((state->src_x >> 16) % state->fb->format->tile_w ||
> > > > > > + (state->src_y >> 16) % state->fb->format->tile_h) {
> > > > > > + DRM_DEBUG_ATOMIC("[PLANE:%d:%s] Source coordinates do
> > > > > > not meet tile restrictions",
> > > > > > +plane->base.id, plane->name);
> > > > > > + return -EINVAL;
> > > > > > + }
> > > > > > +
> > > > > > if (plane_switching_crtc(state->state, plane, state)) {
> > > > > > DRM_DEBUG_ATOMIC("[PLANE:%d:%s] switching CRTC
> > > > > > directly\n",
> > > > > > plane->base.id, plane->name);
> > > > > > diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
> > > > > > b/drivers/gpu/drm/drm_fb_cma_helper.c
> > > > > > index 47e0e2f6642d..4d8052adce67 100644
> > > > > > --- a/drivers/gpu/drm/drm_fb_cma_helper.c
> > > > > > +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
> > > > > > @@ -87,6 +87,8 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct
> > > > > > drm_framebuffer *fb,
> > > > > > struct drm_gem_cma_object *obj;
> > > > > > dma_addr_t paddr;
> > > > > > u8 h_div = 1, v_div = 1;
> > > > > > + u32 tile_w = drm_format_tile_width(fb->format, plane);
> > > > > > + u32 tile_h = drm_format_tile_height(fb->format, plane);
> > > > > >
> > > > > > obj = drm_fb_cma_get_gem_obj(fb, plane);
> > > > > > if (!obj)
> > > > > > @@ -99,8 +101,13 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct
> > > > > > drm_framebuffer *fb,
> > > > > > v_div = fb->format->vsub;
> > > > > > }
> > > > > >
> > > > > > - paddr += (fb->format->cpp[plane] * (state->src_x >> 16)) /
> > > > > > h_div;
> > > > > > - paddr +=
[Bug 99857] Radeon R7 M260/M265 *ERROR* amdgpu asic reset failed - Suspending notebook freezes it
https://bugs.freedesktop.org/show_bug.cgi?id=99857 Andrey Grodzovsky changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #12 from Andrey Grodzovsky --- Seems to work in latest kernel. -- 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 99857] Radeon R7 M260/M265 *ERROR* amdgpu asic reset failed - Suspending notebook freezes it
https://bugs.freedesktop.org/show_bug.cgi?id=99857 --- Comment #11 from Andrey Grodzovsky --- (In reply to copperly from comment #10) > I downloaded kernel 4.18 and it seems to be working. (I must have looked > crazy opening and closing my laptop lid over and over again :) ) > Thank you so much for your help Glad to hear that. -- 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 libdrm v2 4/5] intel: make gen9 use generic gen macro
On Fri, Aug 31, 2018 at 09:21:32AM +0100, Chris Wilson wrote:
> Quoting Lucas De Marchi (2018-08-29 01:35:31)
> > The 2 PCI IDs that are used for the command line overrid mechanism
> > were left defined. The rest can be gone and then we just use the kernel
> > defines.
> >
> > Signed-off-by: Lucas De Marchi
> > ---
> > intel/intel_chipset.c | 5 ++
> > intel/intel_chipset.h | 187 +-
> > 2 files changed, 6 insertions(+), 186 deletions(-)
> >
> > diff --git a/intel/intel_chipset.c b/intel/intel_chipset.c
> > index 0c2ba884..c984d8ac 100644
> > --- a/intel/intel_chipset.c
> > +++ b/intel/intel_chipset.c
> > @@ -36,6 +36,11 @@ static const struct pci_device {
> > } pciids[] = {
> > INTEL_ICL_11_IDS(11),
> > INTEL_CNL_IDS(10),
> > + INTEL_CFL_IDS(9),
> > + INTEL_GLK_IDS(9),
> > + INTEL_KBL_IDS(9),
> > + INTEL_BXT_IDS(9),
> > + INTEL_SKL_IDS(9),
>
> The gradual conversion lgtm. But why stop here? :)
From cover letter:
Initially my plan was to convert all gens, back to gen2, but
that proved slightly difficult since there are some corner cases
to cover and I didn't want to block the important part, i.e.:
for recent gens, there's no risk of missing a PCI ID.
With the last approach moving the implementation to a .c file I think it
will be easier to implement for older gens, but there's no point in
doing the manual boring labor of converting all gens just to have to
change the approach in a v2, v3 of the patch set. Like I did for v1 ->
v2. I can convert the rest if we agree the current approach is
okish
I'm even ok with letting older ones as is since I hope we won't add a
new pci id for e.g. gen3, so I won't have to touch that.
Lucas De Marchi
> -Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm v2 1/5] intel: add generic functions to check PCI ID
Quoting Lucas De Marchi (2018-08-31 17:06:01)
> On Fri, Aug 31, 2018 at 09:16:23AM +0100, Chris Wilson wrote:
> > Quoting Lucas De Marchi (2018-08-29 01:35:28)
> > > +bool intel_is_genx(unsigned int devid, int gen)
> > > +{
> > > + const struct pci_device *p,
> > > + *pend = pciids + sizeof(pciids) / sizeof(pciids[0]);
> > > +
> > > + for (p = pciids; p < pend; p++) {
> > > + /* PCI IDs are sorted */
> > > + if (p->gen < gen)
> > > + break;
> >
> > If we have lots of gen with lots of subids, a binary search for gen
> > would be sensible. However, do we need this function? Do we not just
> > convert everyone over to a lookup of pci-id on entry?
>
> in some places we need the single IS_GEN9(). The advantage of using this
> function rather than intel_get_genx() is that it can be faster due to
> stopping here, or doing a binary search as you pointed out.
> With intel_get_genx we don't have this. IS_GEN9() is may be called in
> non-initialization code paths, so IMO its worth.
>
> What we *can* do here instead is: guarantee all codepaths will occur
> after the call to drm_intel_bufmgr_gem_init() then remove all macros and
> just implement a single function that checks the "cached value".
That would be similar to how we handle elsewhere. But there's no need to
jump there in one series.
> > Idle thought
> > #ifdef SELFTEST
> > int main(void)
> > {
> > /* check pci-ids are ordered by gen */
> > }
> > #endif
>
> $ git grep SELFTEST
> $
>
> you do know this is a patch for libdrm, right?
Wouldn't be that hard to add a check_PROGRAMS target with a -DSELFTEST.
It was just an idle thought if you cared to improve the standard of a
stagnant library. It might as well retire with grace ;)
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] add gitlab-ci builds of libdrm
On Friday, 2018-08-31 16:03:44 +0100, Daniel Stone wrote: > Hi Eric, > > On Fri, 31 Aug 2018 at 15:22, Eric Engestrom wrote: > > +- LIBPCIACCESS_VERSION=libpciaccess-0.10 && > > + wget --no-check-certificate > > https://xorg.freedesktop.org/releases/individual/lib/$LIBPCIACCESS_VERSION.tar.bz2 > > && > > Why are you using --no-check-certificate?! Right, forgot to add a comment for this, sorry. fd.o uses LetsEncrypt, which is not present in the ca-certificate on debian:stable. I had to choose between ignoring the certificate error or use a custom CA, which just didn't seem worth it. > > Cheers, > Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 14/14] drm/msm/dpu: remove cdm block support from resource manager
On Tue, Aug 28, 2018 at 05:40:03PM -0700, Jeykumar Sankaran wrote:
> Support for CDM block is not present in DPU. Remove CDM
> handlers from resource manager.
I think there's some leftovers that can be cleaned up...
$ ack -i cdm
disp/dpu1/dpu_hw_mdss.h
103:DPU_HW_BLK_CDM,
192:enum dpu_cdm {
193:CDM_0 = 1,
194:CDM_1,
195:CDM_MAX
454:#define DPU_DBG_MASK_CDM (1 << 1)
disp/dpu1/dpu_hw_catalog.h
533: * struct dpu_cdm_cfg - information of chroma down blocks
537: * @intf_connect Bitmask of INTF IDs this CDM can connect to
539:struct dpu_cdm_cfg {
737:u32 cdm_count;
738:struct dpu_cdm_cfg *cdm;
776:#define BLK_CDM(s) ((s)->cdm)
disp/dpu1/dpu_hw_catalog.c
324: * CDM sub blocks config
326:static struct dpu_cdm_cfg sdm845_cdm[] = {
328:.name = "cdm_0", .id = CDM_0,
461:.cdm_count = ARRAY_SIZE(sdm845_cdm),
462:.cdm = sdm845_cdm,
>
> Signed-off-by: Jeykumar Sankaran
> ---
> drivers/gpu/drm/msm/Makefile | 1 -
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 2 -
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 5 -
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_cdm.c | 323
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_cdm.h | 139 --
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 14 -
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h | 4 -
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c | 18 --
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.h | 17 --
> drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 68 +
> drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h| 4 -
> 11 files changed, 2 insertions(+), 593 deletions(-)
> delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_cdm.c
> delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_cdm.h
>
> diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
> index 261fa79..19ab521 100644
> --- a/drivers/gpu/drm/msm/Makefile
> +++ b/drivers/gpu/drm/msm/Makefile
> @@ -58,7 +58,6 @@ msm-y := \
> disp/dpu1/dpu_formats.o \
> disp/dpu1/dpu_hw_blk.o \
> disp/dpu1/dpu_hw_catalog.o \
> - disp/dpu1/dpu_hw_cdm.o \
> disp/dpu1/dpu_hw_ctl.o \
> disp/dpu1/dpu_hw_interrupts.o \
> disp/dpu1/dpu_hw_intf.o \
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
> index e453271..e844afa 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
> @@ -32,11 +32,9 @@
> /**
> * Encoder functions and data types
> * @intfs: Interfaces this encoder is using, INTF_MODE_NONE if unused
> - * @needs_cdm: Encoder requests a CDM based on pixel format conversion
> needs
> */
> struct dpu_encoder_hw_resources {
> enum dpu_intf_mode intfs[INTF_MAX];
> - bool needs_cdm;
> };
>
> /**
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
> index b5fc65c..f796683 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
> @@ -22,7 +22,6 @@
> #include "dpu_hw_pingpong.h"
> #include "dpu_hw_ctl.h"
> #include "dpu_hw_top.h"
> -#include "dpu_hw_cdm.h"
> #include "dpu_encoder.h"
> #include "dpu_crtc.h"
>
> @@ -205,8 +204,6 @@ struct dpu_encoder_irq {
> * @parent_ops: Callbacks exposed by the parent to the phys_enc
> * @hw_mdptop: Hardware interface to the top registers
> * @hw_ctl: Hardware interface to the ctl registers
> - * @hw_cdm: Hardware interface to the cdm registers
> - * @cdm_cfg: Chroma-down hardware configuration
> * @hw_pp: Hardware interface to the ping pong registers
> * @dpu_kms: Pointer to the dpu_kms top level
> * @cached_mode: DRM mode cached at mode_set time, acted on in enable
> @@ -235,8 +232,6 @@ struct dpu_encoder_phys {
> const struct dpu_encoder_virt_ops *parent_ops;
> struct dpu_hw_mdp *hw_mdptop;
> struct dpu_hw_ctl *hw_ctl;
> - struct dpu_hw_cdm *hw_cdm;
> - struct dpu_hw_cdm_cfg cdm_cfg;
> struct dpu_hw_pingpong *hw_pp;
> struct dpu_kms *dpu_kms;
> struct drm_display_mode cached_mode;
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_cdm.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_cdm.c
> deleted file mode 100644
> index 554874b..000
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_cdm.c
> +++ /dev/null
> @@ -1,323 +0,0 @@
> -/* Copyright (c) 2015-2018, The Linux Foundation. All rights reserved.
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License version 2 and
> - * only version 2 as published by the Free Software Foundation.
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - *
Re: [PATCH 13/14] drm/msm/dpu: remove display H_TILE from encoder
On Tue, Aug 28, 2018 at 05:40:02PM -0700, Jeykumar Sankaran wrote:
> Encoder H_TILE values are not used for allocating the hw blocks.
> no. of hw_intf blocks provides the info.
>
> Signed-off-by: Jeykumar Sankaran
Reviewed-by: Sean Paul
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 5 -
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 3 ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 3 +--
> 3 files changed, 1 insertion(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> index 56ef349..bfc082d 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> @@ -175,8 +175,6 @@ struct dpu_encoder_virt {
> spinlock_t enc_spinlock;
> uint32_t bus_scaling_client;
>
> - uint32_t display_num_of_h_tiles;
> -
> unsigned int num_phys_encs;
> struct dpu_encoder_phys *phys_encs[MAX_PHYS_ENCODERS_PER_VIRTUAL];
> struct dpu_encoder_phys *cur_master;
> @@ -455,7 +453,6 @@ void dpu_encoder_get_hw_resources(struct drm_encoder
> *drm_enc,
>
> /* Query resources used by phys encs, expected to be without overlap */
> memset(hw_res, 0, sizeof(*hw_res));
> - hw_res->display_num_of_h_tiles = dpu_enc->display_num_of_h_tiles;
>
> for (i = 0; i < dpu_enc->num_phys_encs; i++) {
> struct dpu_encoder_phys *phys = dpu_enc->phys_encs[i];
> @@ -2103,8 +2100,6 @@ static int dpu_encoder_setup_display(struct
> dpu_encoder_virt *dpu_enc,
>
> WARN_ON(disp_info->num_of_h_tiles < 1);
>
> - dpu_enc->display_num_of_h_tiles = disp_info->num_of_h_tiles;
> -
> DPU_DEBUG("dsi_info->num_of_h_tiles %d\n", disp_info->num_of_h_tiles);
>
> if ((disp_info->capabilities & MSM_DISPLAY_CAP_CMD_MODE) ||
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
> index c5600e6..e453271 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
> @@ -33,13 +33,10 @@
> * Encoder functions and data types
> * @intfs: Interfaces this encoder is using, INTF_MODE_NONE if unused
> * @needs_cdm: Encoder requests a CDM based on pixel format conversion
> needs
> - * @display_num_of_h_tiles: Number of horizontal tiles in case of split
> - * interface
> */
> struct dpu_encoder_hw_resources {
> enum dpu_intf_mode intfs[INTF_MAX];
> bool needs_cdm;
> - u32 display_num_of_h_tiles;
> };
>
> /**
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
> index fbd489f..388ae65 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
> @@ -813,8 +813,7 @@ static int _dpu_rm_populate_requirements(
> conn_state->connector->connector_type == DRM_MODE_CONNECTOR_DSI)
> reqs->top_ctrl |= BIT(DPU_RM_TOPCTL_DS);
>
> - DRM_DEBUG_KMS("top_ctrl: 0x%llX num_h_tiles: %d\n", reqs->top_ctrl,
> - reqs->hw_res.display_num_of_h_tiles);
> + DRM_DEBUG_KMS("top_ctrl: 0x%llX\n", reqs->top_ctrl);
> DRM_DEBUG_KMS("num_lm: %d num_ctl: %d split_display: %d\n",
> reqs->topology->num_lm, reqs->topology->num_ctl,
> reqs->topology->needs_split_display);
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 12/14] drm/msm/dpu: remove topology name
On Tue, Aug 28, 2018 at 05:40:01PM -0700, Jeykumar Sankaran wrote:
> Strip down the support for topology enums. It
> can be replaced with simple hw count checks.
>
Changes in v4:
...
> Signed-off-by: Jeykumar Sankaran
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c| 3 --
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h| 1 -
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 9 --
> .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 7 +++--
> drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 36
> ++
> drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 24 ---
> 6 files changed, 19 insertions(+), 61 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> index dbf669e..56ef349 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> @@ -1013,7 +1013,6 @@ static void dpu_encoder_virt_mode_set(struct
> drm_encoder *drm_enc,
> struct drm_connector *conn = NULL, *conn_iter;
> struct dpu_rm_hw_iter pp_iter, ctl_iter;
> struct msm_display_topology topology;
> - enum dpu_rm_topology_name topology_name;
> struct dpu_hw_ctl *hw_ctl[MAX_CHANNELS_PER_ENC] = { NULL };
> int i = 0, ret;
>
> @@ -1069,7 +1068,6 @@ static void dpu_encoder_virt_mode_set(struct
> drm_encoder *drm_enc,
> hw_ctl[i] = (struct dpu_hw_ctl *)ctl_iter.hw;
> }
>
> - topology_name = dpu_rm_get_topology_name(topology);
> for (i = 0; i < dpu_enc->num_phys_encs; i++) {
> struct dpu_encoder_phys *phys = dpu_enc->phys_encs[i];
>
> @@ -1089,7 +1087,6 @@ static void dpu_encoder_virt_mode_set(struct
> drm_encoder *drm_enc,
> phys->hw_ctl = hw_ctl[i];
>
> phys->connector = conn->state->connector;
> - phys->topology_name = topology_name;
> if (phys->ops.mode_set)
> phys->ops.mode_set(phys, mode, adj_mode);
> }
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
> index 60f809f..c5600e6 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
> @@ -35,7 +35,6 @@
> * @needs_cdm: Encoder requests a CDM based on pixel format conversion
> needs
> * @display_num_of_h_tiles: Number of horizontal tiles in case of split
> * interface
> - * @topology: Topology of the display
> */
> struct dpu_encoder_hw_resources {
> enum dpu_intf_mode intfs[INTF_MAX];
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
> index b3917e0..b5fc65c 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
> @@ -24,6 +24,7 @@
> #include "dpu_hw_top.h"
> #include "dpu_hw_cdm.h"
> #include "dpu_encoder.h"
> +#include "dpu_crtc.h"
>
> #define DPU_ENCODER_NAME_MAX 16
>
> @@ -213,7 +214,6 @@ struct dpu_encoder_irq {
> * @split_role: Role to play in a split-panel configuration
> * @intf_mode: Interface mode
> * @intf_idx:Interface index on dpu hardware
> - * @topology_name: topology selected for the display
> * @enc_spinlock:Virtual-Encoder-Wide Spin Lock for IRQ purposes
> * @enable_state:Enable state tracking
> * @vblank_refcount: Reference count of vblank request
> @@ -243,7 +243,6 @@ struct dpu_encoder_phys {
> enum dpu_enc_split_role split_role;
> enum dpu_intf_mode intf_mode;
> enum dpu_intf intf_idx;
> - enum dpu_rm_topology_name topology_name;
> spinlock_t *enc_spinlock;
> enum dpu_enc_enable_state enable_state;
> atomic_t vblank_refcount;
> @@ -361,11 +360,15 @@ struct dpu_encoder_phys *dpu_encoder_phys_cmd_init(
> static inline enum dpu_3d_blend_mode dpu_encoder_helper_get_3d_blend_mode(
> struct dpu_encoder_phys *phys_enc)
> {
> + struct dpu_crtc_state *dpu_cstate;
> +
> if (!phys_enc || phys_enc->enable_state == DPU_ENC_DISABLING)
> return BLEND_3D_NONE;
>
> + dpu_cstate = to_dpu_crtc_state(phys_enc->parent->crtc->state);
> +
> if (phys_enc->split_role == ENC_ROLE_SOLO &&
> - phys_enc->topology_name == DPU_RM_TOPOLOGY_DUALPIPE_3DMERGE)
> + (dpu_cstate->num_mixers == 2))
I guess this should be CRTC_DUAL_MIXERS? Perhaps you should add a helper called
dpu_crtc_state_is_stereo() instead of littering these checks everywhere.
> return BLEND_3D_H_ROW_INT;
>
> return BLEND_3D_NONE;
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
> index 6de13f4..1643e2f 100644
> ---
Re: [PATCH libdrm v2 1/5] intel: add generic functions to check PCI ID
On Fri, Aug 31, 2018 at 09:16:23AM +0100, Chris Wilson wrote:
> Quoting Lucas De Marchi (2018-08-29 01:35:28)
> > +static const struct pci_device {
> > + uint16_t device;
> > + uint16_t gen;
> > +} pciids[] = {
>
> Add a comment here as well for the ordering requirement.
>
> /* Keep ids sorted by gen; latest gen first */
>
> We're unlikely to notice a comment in the function later trying to
> impose its restriction.
ok
>
> > +};
> > +
> > +bool intel_is_genx(unsigned int devid, int gen)
> > +{
> > + const struct pci_device *p,
> > + *pend = pciids + sizeof(pciids) / sizeof(pciids[0]);
> > +
> > + for (p = pciids; p < pend; p++) {
> > + /* PCI IDs are sorted */
> > + if (p->gen < gen)
> > + break;
>
> If we have lots of gen with lots of subids, a binary search for gen
> would be sensible. However, do we need this function? Do we not just
> convert everyone over to a lookup of pci-id on entry?
in some places we need the single IS_GEN9(). The advantage of using this
function rather than intel_get_genx() is that it can be faster due to
stopping here, or doing a binary search as you pointed out.
With intel_get_genx we don't have this. IS_GEN9() is may be called in
non-initialization code paths, so IMO its worth.
What we *can* do here instead is: guarantee all codepaths will occur
after the call to drm_intel_bufmgr_gem_init() then remove all macros and
just implement a single function that checks the "cached value".
>
> > +
> > + if (p->device != devid)
> > + continue;
> > +
> > + if (gen == p->gen)
> > + return true;
> > +
> > + break;
> > + }
> > +
> > + return false;
> > +}
> > +
> > +bool intel_get_genx(unsigned int devid, int *gen)
> > +{
> > + const struct pci_device *p,
> > + *pend = pciids + sizeof(pciids) / sizeof(pciids[0]);
> > +
> > + for (p = pciids; p < pend; p++) {
> > + if (p->device != devid)
> > + continue;
> > +
> > + if (gen)
> > + *gen = p->gen;
> > +
> > + return true;
> > + }
> > +
> > + return false;
> > +}
>
> Idle thought
> #ifdef SELFTEST
> int main(void)
> {
> /* check pci-ids are ordered by gen */
> }
> #endif
$ git grep SELFTEST
$
you do know this is a patch for libdrm, right?
>
> > diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
> > index 4a34b7be..0e14c58f 100644
> > --- a/intel/intel_chipset.h
> > +++ b/intel/intel_chipset.h
> > @@ -568,6 +568,13 @@
> >
> > #define IS_GEN11(devid)(IS_ICELAKE_11(devid))
> >
> > +/* New platforms use kernel pci ids */
> > +#include
> > +
> > +bool intel_is_genx(unsigned int devid, int gen);
> > +bool intel_get_genx(unsigned int devid, int *gen);
> > +
> > +/* all platforms */
>
> Quite clearly not all platforms :-p
by some definition of "all" the " New platforms use kernel pci ids " + the
ones that don't ;)
I'm ok with just removing the comment
Lucas De Marchi
>
> > #define IS_9XX(dev)(IS_GEN3(dev) || \
> > IS_GEN4(dev) || \
> > IS_GEN5(dev) || \
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 11/14] drm/msm/dpu: rename hw_ctl to lm_ctl
On Tue, Aug 28, 2018 at 05:40:00PM -0700, Jeykumar Sankaran wrote:
> Rename hw_ctl to lm_ctl to mean the ctl associated
> with the hw layer mixer block.
>
> sed -i 's/\([*@.>]\)hw_ctl\([^s]\)/\1lm_ctl\2/g' dpu_crtc.c dpu_crtc.h
>
> Signed-off-by: Jeykumar Sankaran
Reviewed-by: Sean Paul
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 26 +-
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 4 ++--
> 2 files changed, 15 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> index 7ab320d..aeb0f1a 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> @@ -202,7 +202,7 @@ static void _dpu_crtc_blend_setup_mixer(struct drm_crtc
> *crtc,
> return;
> }
>
> - ctl = mixer->hw_ctl;
> + ctl = mixer->lm_ctl;
> lm = mixer->hw_lm;
> stage_cfg = _crtc->stage_cfg;
> cstate = to_dpu_crtc_state(crtc->state);
> @@ -292,15 +292,15 @@ static void _dpu_crtc_blend_setup(struct drm_crtc *crtc)
> }
>
> for (i = 0; i < cstate->num_mixers; i++) {
> - if (!mixer[i].hw_lm || !mixer[i].hw_ctl) {
> + if (!mixer[i].hw_lm || !mixer[i].lm_ctl) {
> DPU_ERROR("invalid lm or ctl assigned to mixer\n");
> return;
> }
> mixer[i].mixer_op_mode = 0;
> mixer[i].flush_mask = 0;
> - if (mixer[i].hw_ctl->ops.clear_all_blendstages)
> - mixer[i].hw_ctl->ops.clear_all_blendstages(
> - mixer[i].hw_ctl);
> + if (mixer[i].lm_ctl->ops.clear_all_blendstages)
> + mixer[i].lm_ctl->ops.clear_all_blendstages(
> + mixer[i].lm_ctl);
> }
>
> /* initialize stage cfg */
> @@ -309,7 +309,7 @@ static void _dpu_crtc_blend_setup(struct drm_crtc *crtc)
> _dpu_crtc_blend_setup_mixer(crtc, dpu_crtc, mixer);
>
> for (i = 0; i < cstate->num_mixers; i++) {
> - ctl = mixer[i].hw_ctl;
> + ctl = mixer[i].lm_ctl;
> lm = mixer[i].hw_lm;
>
> lm->ops.setup_alpha_out(lm, mixer[i].mixer_op_mode);
> @@ -553,14 +553,14 @@ static void _dpu_crtc_setup_mixer_for_encoder(
> if (!dpu_rm_get_hw(rm, _iter)) {
> DPU_DEBUG("no ctl assigned to lm %d, using previous\n",
> mixer->hw_lm->idx - LM_0);
> - mixer->hw_ctl = last_valid_ctl;
> + mixer->lm_ctl = last_valid_ctl;
> } else {
> - mixer->hw_ctl = (struct dpu_hw_ctl *)ctl_iter.hw;
> - last_valid_ctl = mixer->hw_ctl;
> + mixer->lm_ctl = (struct dpu_hw_ctl *)ctl_iter.hw;
> + last_valid_ctl = mixer->lm_ctl;
> }
>
> /* Shouldn't happen, mixers are always >= ctls */
> - if (!mixer->hw_ctl) {
> + if (!mixer->lm_ctl) {
> DPU_ERROR("no valid ctls found for lm %d\n",
> mixer->hw_lm->idx - LM_0);
> return;
> @@ -572,7 +572,7 @@ static void _dpu_crtc_setup_mixer_for_encoder(
> DPU_DEBUG("setup mixer %d: lm %d\n",
> i, mixer->hw_lm->idx - LM_0);
> DPU_DEBUG("setup mixer %d: ctl %d\n",
> - i, mixer->hw_ctl->idx - CTL_0);
> + i, mixer->lm_ctl->idx - CTL_0);
> }
> }
>
> @@ -1567,11 +1567,11 @@ static int _dpu_debugfs_status_show(struct seq_file
> *s, void *data)
> m = >mixers[i];
> if (!m->hw_lm)
> seq_printf(s, "\tmixer[%d] has no lm\n", i);
> - else if (!m->hw_ctl)
> + else if (!m->lm_ctl)
> seq_printf(s, "\tmixer[%d] has no ctl\n", i);
> else
> seq_printf(s, "\tmixer:%d ctl:%d width:%d height:%d\n",
> - m->hw_lm->idx - LM_0, m->hw_ctl->idx - CTL_0,
> + m->hw_lm->idx - LM_0, m->lm_ctl->idx - CTL_0,
> out_width, mode->vdisplay);
> }
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
> index 7aa772f..9b1056c 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
> @@ -83,14 +83,14 @@ struct dpu_crtc_smmu_state_data {
> /**
> * struct dpu_crtc_mixer: stores the map for each virtual pipeline in the
> CRTC
> * @hw_lm: LM HW Driver context
> - * @hw_ctl: CTL Path HW driver context
> + * @lm_ctl: CTL Path HW driver context
> * @encoder: Encoder attached to this lm & ctl
> * @mixer_op_mode: mixer blending operation mode
>
Re: [PATCH] drm: Describe pixel_blend_mode in drm_plane_state
On Fri, Aug 31, 2018 at 05:24:46PM +0200, Maarten Lankhorst wrote:
> Op 31-08-18 om 17:09 schreef Sean Paul:
> > From: Sean Paul
> >
> > Adds docs for pixel_blend_mode in drm_plane_state. Fixes the warning
> > found by kbuild test robot:
> >
> > htmldocs: include/drm/drm_plane.h:189: warning: Function parameter or
> > member 'pixel_blend_mode' not described in 'drm_plane_state'
> >
> > Cc: Daniel Vetter
> > Cc: Lowry Li
> > Signed-off-by: Sean Paul
> > ---
> > include/drm/drm_plane.h | 7 +++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
> > index 35ef64a9398b..16f5b66684ca 100644
> > --- a/include/drm/drm_plane.h
> > +++ b/include/drm/drm_plane.h
> > @@ -117,6 +117,13 @@ struct drm_plane_state {
> > * details.
> > */
> > u16 alpha;
> > +
> > + /**
> > +* @pixel_blend_mode:
> > +* The alpha blending equation selection, describing how the pixels from
> > +* the current plane are composited with the background. Value can be
> > +* one of DRM_MODE_BLEND_*
> > +*/
> > uint16_t pixel_blend_mode;
> >
> > /**
>
> Reviewed-by: Maarten Lankhorst
Applied to -misc-next, thanks Maarten!
Sean
>
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] libdrm: Allow dynamic drm majors on linux
On 08/31/2018 05:27 PM, Emil Velikov wrote: On 31 August 2018 at 15:38, Michel Dänzer wrote: [ Adding the amd-gfx list ] On 2018-08-31 3:05 p.m., Thomas Hellstrom wrote: On 08/31/2018 02:30 PM, Emil Velikov wrote: On 31 August 2018 at 12:54, Thomas Hellstrom wrote: To determine whether a device node is a drm device node or not, the code currently compares the node's major number to the static drm major device number. This breaks the standalone vmwgfx driver on XWayland dri clients, Any particular reason why the code doesn't use a fixed node there? It will make the diff vs the in-kernel driver a bit smaller. Because then it won't be able to interoperate with other in-tree drivers, like virtual drm drivers or passthrough usb drm drivers. There is no clean way to share the minor number allocation with in-tree drm, so standalone vmwgfx is using dynamic major allocation. I wonder why I haven't heard of any of these issues with the standalone version of amdgpu shipped in packaged AMD releases. Does that also use a different major number? If yes, maybe it's just that nobody has tried Xwayland clients with that driver. If no, how does it avoid the other issues described above? AFAICT, the difference is that the standalone vmwgfx uses an internal copy of drm core. It doesn't reuse the in-kernel drm, hence it cannot know which minor it can use. -Emil Actually, standalone vmwgfx could perhaps also try to allocate minors from 63 and downwards. That might work, but needs some verification. /Thomas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] libdrm: Allow dynamic drm majors on linux
Am 31.08.2018 um 17:27 schrieb Emil Velikov: On 31 August 2018 at 15:38, Michel Dänzer wrote: [ Adding the amd-gfx list ] On 2018-08-31 3:05 p.m., Thomas Hellstrom wrote: On 08/31/2018 02:30 PM, Emil Velikov wrote: On 31 August 2018 at 12:54, Thomas Hellstrom wrote: To determine whether a device node is a drm device node or not, the code currently compares the node's major number to the static drm major device number. This breaks the standalone vmwgfx driver on XWayland dri clients, Any particular reason why the code doesn't use a fixed node there? It will make the diff vs the in-kernel driver a bit smaller. Because then it won't be able to interoperate with other in-tree drivers, like virtual drm drivers or passthrough usb drm drivers. There is no clean way to share the minor number allocation with in-tree drm, so standalone vmwgfx is using dynamic major allocation. I wonder why I haven't heard of any of these issues with the standalone version of amdgpu shipped in packaged AMD releases. Does that also use a different major number? If yes, maybe it's just that nobody has tried Xwayland clients with that driver. If no, how does it avoid the other issues described above? AFAICT, the difference is that the standalone vmwgfx uses an internal copy of drm core. It doesn't reuse the in-kernel drm, hence it cannot know which minor it can use. The amdgpu pro package has it's own drm core copy as well and there it still works. Not sure how our back-porting guys handle that. Christian. -Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] libdrm: Allow dynamic drm majors on linux
On 31 August 2018 at 15:38, Michel Dänzer wrote: > > [ Adding the amd-gfx list ] > > On 2018-08-31 3:05 p.m., Thomas Hellstrom wrote: >> On 08/31/2018 02:30 PM, Emil Velikov wrote: >>> On 31 August 2018 at 12:54, Thomas Hellstrom >>> wrote: To determine whether a device node is a drm device node or not, the code currently compares the node's major number to the static drm major device number. This breaks the standalone vmwgfx driver on XWayland dri clients, >>> Any particular reason why the code doesn't use a fixed node there? >>> It will make the diff vs the in-kernel driver a bit smaller. >> Because then it won't be able to interoperate with other in-tree >> drivers, like virtual drm drivers or passthrough usb drm drivers. >> There is no clean way to share the minor number allocation with in-tree >> drm, so standalone vmwgfx is using dynamic major allocation. > > I wonder why I haven't heard of any of these issues with the standalone > version of amdgpu shipped in packaged AMD releases. Does that also use a > different major number? If yes, maybe it's just that nobody has tried > Xwayland clients with that driver. If no, how does it avoid the other > issues described above? > AFAICT, the difference is that the standalone vmwgfx uses an internal copy of drm core. It doesn't reuse the in-kernel drm, hence it cannot know which minor it can use. -Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Describe pixel_blend_mode in drm_plane_state
Op 31-08-18 om 17:09 schreef Sean Paul:
> From: Sean Paul
>
> Adds docs for pixel_blend_mode in drm_plane_state. Fixes the warning
> found by kbuild test robot:
>
> htmldocs: include/drm/drm_plane.h:189: warning: Function parameter or member
> 'pixel_blend_mode' not described in 'drm_plane_state'
>
> Cc: Daniel Vetter
> Cc: Lowry Li
> Signed-off-by: Sean Paul
> ---
> include/drm/drm_plane.h | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
> index 35ef64a9398b..16f5b66684ca 100644
> --- a/include/drm/drm_plane.h
> +++ b/include/drm/drm_plane.h
> @@ -117,6 +117,13 @@ struct drm_plane_state {
>* details.
>*/
> u16 alpha;
> +
> + /**
> + * @pixel_blend_mode:
> + * The alpha blending equation selection, describing how the pixels from
> + * the current plane are composited with the background. Value can be
> + * one of DRM_MODE_BLEND_*
> + */
> uint16_t pixel_blend_mode;
>
> /**
Reviewed-by: Maarten Lankhorst
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107694] [wine] RAGE: texture problems
https://bugs.freedesktop.org/show_bug.cgi?id=107694 --- Comment #3 from James B --- FYI, This bug does not occur on the 64-bit version of the game only the 32-bit. The 32-bit is very unstable for me also, it crashes quite often. Unfortunately, the 64-bit version's in-game audio is broken on Proton currently. I have spent hours testing different settings on and off for over a year, never managed to find a setting that cured the issue. The game works fine on proprietary drivers. System info: -- Arch 64-bit -- GPU: RX Vega 56 -- Mesa 18.3.0-devel (git-e345247092) -- Kernel 4.18.5 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/5] drm: Add support for handling linear tile formats
On Fri, Aug 31, 2018 at 02:20:31PM +0300, Ville Syrjälä wrote:
> On Fri, Aug 31, 2018 at 10:14:14AM +0200, Daniel Vetter wrote:
> > On Thu, Aug 23, 2018 at 06:43:40PM +0100, Alexandru-Cosmin Gheorghe wrote:
> > > On Wed, Aug 22, 2018 at 10:18:51PM +0200, Daniel Vetter wrote:
> > > > On Tue, Aug 21, 2018 at 07:30:03PM +0100, Alexandru Gheorghe wrote:
> > > > > The previous patch added tile_w and tile_h, which represent the
> > > > > horizontal and vertical sizes of a tile.
> > > > >
> > > > > This one uses that to plumb through drm core in order to be able to
> > > > > handle linear tile formats without the need for drivers to roll up
> > > > > their own implementation.
> > > > >
> > > > > This patch had been written with Mali-dp X0L2 and X0L0 in mind which
> > > > > is a 1 plane YCbCr 420 format with a 2x2 tile, that uses in average 2
> > > > > bytes per pixel and where tiles are laid out in a linear manner.
> > > > >
> > > > > Now what are the restrictions:
> > > > >
> > > > > 1. Pitch in bytes is expected to cover at least tile_h * width in
> > > > > pixels. Due to this the places where the pitch is checked/used need to
> > > > > be updated to take into consideration the tile_w, tile_h and
> > > > > tile_size.
> > > > > tile_size = cpp * tile_w * tile_h
> > > > >
> > > > > 2. When doing source cropping plane_src_x/y need to be a multiple of
> > > > > tile_w/tile_h and we need to take into consideration the tile_w/tile_h
> > > > > when computing the start address.
> > > > >
> > > > > For all non-tiled formats the tile_w and tile_h will be 1, so if I
> > > > > didn't miss anything nothing should change.
> > > > >
> > > > > Regarding multi-planar linear tile formats, I'm not sure how those
> > > > > should be handle I kind of assumed that tile_h/tile_w will have to be
> > > > > divided by horizontal/subsampling. Anyway, I think it's best to just
> > > > > put an warning in there and handle it when someone tries to add
> > > > > support for them.
> > > > >
> > > > > Signed-off-by: Alexandru Gheorghe
> > > > > ---
> > > > > drivers/gpu/drm/drm_atomic.c | 8 +++
> > > > > drivers/gpu/drm/drm_fb_cma_helper.c | 11 -
> > > > > drivers/gpu/drm/drm_fourcc.c | 52
> > > > >
> > > > > drivers/gpu/drm/drm_framebuffer.c| 19 +--
> > > > > drivers/gpu/drm/drm_gem_framebuffer_helper.c | 10 ++--
> > > > > include/drm/drm_fourcc.h | 2 +
> > > > > 6 files changed, 94 insertions(+), 8 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/drm_atomic.c
> > > > > b/drivers/gpu/drm/drm_atomic.c
> > > > > index 3eb061e11e2e..7a3e893a4cd1 100644
> > > > > --- a/drivers/gpu/drm/drm_atomic.c
> > > > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > > > @@ -1087,6 +1087,14 @@ static int drm_atomic_plane_check(struct
> > > > > drm_plane *plane,
> > > > > return -ENOSPC;
> > > > > }
> > > > >
> > > > > + /* Make sure source coordinates are a multiple of tile sizes */
> > > > > + if ((state->src_x >> 16) % state->fb->format->tile_w ||
> > > > > + (state->src_y >> 16) % state->fb->format->tile_h) {
> > > > > + DRM_DEBUG_ATOMIC("[PLANE:%d:%s] Source coordinates do
> > > > > not meet tile restrictions",
> > > > > + plane->base.id, plane->name);
> > > > > + return -EINVAL;
> > > > > + }
> > > > > +
> > > > > if (plane_switching_crtc(state->state, plane, state)) {
> > > > > DRM_DEBUG_ATOMIC("[PLANE:%d:%s] switching CRTC
> > > > > directly\n",
> > > > >plane->base.id, plane->name);
> > > > > diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
> > > > > b/drivers/gpu/drm/drm_fb_cma_helper.c
> > > > > index 47e0e2f6642d..4d8052adce67 100644
> > > > > --- a/drivers/gpu/drm/drm_fb_cma_helper.c
> > > > > +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
> > > > > @@ -87,6 +87,8 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct
> > > > > drm_framebuffer *fb,
> > > > > struct drm_gem_cma_object *obj;
> > > > > dma_addr_t paddr;
> > > > > u8 h_div = 1, v_div = 1;
> > > > > + u32 tile_w = drm_format_tile_width(fb->format, plane);
> > > > > + u32 tile_h = drm_format_tile_height(fb->format, plane);
> > > > >
> > > > > obj = drm_fb_cma_get_gem_obj(fb, plane);
> > > > > if (!obj)
> > > > > @@ -99,8 +101,13 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct
> > > > > drm_framebuffer *fb,
> > > > > v_div = fb->format->vsub;
> > > > > }
> > > > >
> > > > > - paddr += (fb->format->cpp[plane] * (state->src_x >> 16)) /
> > > > > h_div;
> > > > > - paddr += (fb->pitches[plane] * (state->src_y >> 16)) / v_div;
> > > > > + paddr += (fb->format->cpp[plane] * tile_w * (state->src_x >>
> > > > > 16))
> > > > > + / h_div;
> > > > > + /*
> > > > > + * For tile formats pitches are expected to cover at least
> > > >
[PATCH] drm: Describe pixel_blend_mode in drm_plane_state
From: Sean Paul
Adds docs for pixel_blend_mode in drm_plane_state. Fixes the warning
found by kbuild test robot:
htmldocs: include/drm/drm_plane.h:189: warning: Function parameter or member
'pixel_blend_mode' not described in 'drm_plane_state'
Cc: Daniel Vetter
Cc: Lowry Li
Signed-off-by: Sean Paul
---
include/drm/drm_plane.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
index 35ef64a9398b..16f5b66684ca 100644
--- a/include/drm/drm_plane.h
+++ b/include/drm/drm_plane.h
@@ -117,6 +117,13 @@ struct drm_plane_state {
* details.
*/
u16 alpha;
+
+ /**
+* @pixel_blend_mode:
+* The alpha blending equation selection, describing how the pixels from
+* the current plane are composited with the background. Value can be
+* one of DRM_MODE_BLEND_*
+*/
uint16_t pixel_blend_mode;
/**
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] add gitlab-ci builds of libdrm
Hi Eric, On Fri, 31 Aug 2018 at 15:22, Eric Engestrom wrote: > +- LIBPCIACCESS_VERSION=libpciaccess-0.10 && > + wget --no-check-certificate > https://xorg.freedesktop.org/releases/individual/lib/$LIBPCIACCESS_VERSION.tar.bz2 > && Why are you using --no-check-certificate?! Cheers, Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] libdrm: Allow dynamic drm majors on linux
On 08/31/2018 04:49 PM, Michel Dänzer wrote: On 2018-08-31 4:46 p.m., Thomas Hellstrom wrote: On 08/31/2018 04:38 PM, Michel Dänzer wrote: [ Adding the amd-gfx list ] On 2018-08-31 3:05 p.m., Thomas Hellstrom wrote: On 08/31/2018 02:30 PM, Emil Velikov wrote: On 31 August 2018 at 12:54, Thomas Hellstrom wrote: To determine whether a device node is a drm device node or not, the code currently compares the node's major number to the static drm major device number. This breaks the standalone vmwgfx driver on XWayland dri clients, Any particular reason why the code doesn't use a fixed node there? It will make the diff vs the in-kernel driver a bit smaller. Because then it won't be able to interoperate with other in-tree drivers, like virtual drm drivers or passthrough usb drm drivers. There is no clean way to share the minor number allocation with in-tree drm, so standalone vmwgfx is using dynamic major allocation. I wonder why I haven't heard of any of these issues with the standalone version of amdgpu shipped in packaged AMD releases. Does that also use a different major number? If yes, maybe it's just that nobody has tried Xwayland clients with that driver. If no, how does it avoid the other issues described above? Is standalone AMD supposed to be able to coexist with in-tree drm drivers? Yes, it does, it's working e.g. on laptops with an Intel integrated and an AMD discrete GPU. Hmm. The symptoms with xf86-video-vmware are that when mesa initializes, we get: MESA-LOADER: failed to retrieve device information MESA-LOADER: failed to retrieve device information MESA-LOADER: failed to retrieve device information but then vmwgfx_dri.so loads anyway. With XWayland, mesa just silently tries swrast instead of vmwgfx. Not sure this has always been the case though. It might be due to a recent XWayland change. In any case, the change to libdrm silence the warnings on Xorg and makes mesa try vmwgfx on XWayland. /Thomas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 10/14] drm/msm/dpu: move hw resource tracking to crtc state
On Tue, Aug 28, 2018 at 05:39:59PM -0700, Jeykumar Sankaran wrote:
> Prep changes for state based resource management.
>
> Moves all the hw block tracking for the crtc to the state
> object.
Changes in v4...
>
> Signed-off-by: Jeykumar Sankaran
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 60
> ++--
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 22 ++--
> 2 files changed, 44 insertions(+), 38 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> index e061847..7ab320d 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> @@ -163,9 +163,9 @@ static void _dpu_crtc_program_lm_output_roi(struct
> drm_crtc *crtc)
> crtc_state = to_dpu_crtc_state(crtc->state);
>
> lm_horiz_position = 0;
> - for (lm_idx = 0; lm_idx < dpu_crtc->num_mixers; lm_idx++) {
> + for (lm_idx = 0; lm_idx < crtc_state->num_mixers; lm_idx++) {
> const struct drm_rect *lm_roi = _state->lm_bounds[lm_idx];
> - struct dpu_hw_mixer *hw_lm = dpu_crtc->mixers[lm_idx].hw_lm;
> + struct dpu_hw_mixer *hw_lm = crtc_state->mixers[lm_idx].hw_lm;
> struct dpu_hw_mixer_cfg cfg;
>
> if (!lm_roi || !drm_rect_visible(lm_roi))
> @@ -246,7 +246,7 @@ static void _dpu_crtc_blend_setup_mixer(struct drm_crtc
> *crtc,
> fb ? fb->modifier : 0);
>
> /* blend config update */
> - for (lm_idx = 0; lm_idx < dpu_crtc->num_mixers; lm_idx++) {
> + for (lm_idx = 0; lm_idx < cstate->num_mixers; lm_idx++) {
> _dpu_crtc_setup_blend_cfg(mixer + lm_idx,
> pstate, format);
>
> @@ -270,7 +270,7 @@ static void _dpu_crtc_blend_setup_mixer(struct drm_crtc
> *crtc,
> static void _dpu_crtc_blend_setup(struct drm_crtc *crtc)
> {
> struct dpu_crtc *dpu_crtc;
> - struct dpu_crtc_state *dpu_crtc_state;
> + struct dpu_crtc_state *cstate;
> struct dpu_crtc_mixer *mixer;
> struct dpu_hw_ctl *ctl;
> struct dpu_hw_mixer *lm;
> @@ -281,17 +281,17 @@ static void _dpu_crtc_blend_setup(struct drm_crtc *crtc)
> return;
>
> dpu_crtc = to_dpu_crtc(crtc);
> - dpu_crtc_state = to_dpu_crtc_state(crtc->state);
> - mixer = dpu_crtc->mixers;
> + cstate = to_dpu_crtc_state(crtc->state);
> + mixer = cstate->mixers;
>
> DPU_DEBUG("%s\n", dpu_crtc->name);
>
> - if (dpu_crtc->num_mixers > CRTC_DUAL_MIXERS) {
> - DPU_ERROR("invalid number mixers: %d\n", dpu_crtc->num_mixers);
> + if (cstate->num_mixers > CRTC_DUAL_MIXERS) {
This is not possible.
> + DPU_ERROR("invalid number mixers: %d\n", cstate->num_mixers);
> return;
> }
>
> - for (i = 0; i < dpu_crtc->num_mixers; i++) {
> + for (i = 0; i < cstate->num_mixers; i++) {
> if (!mixer[i].hw_lm || !mixer[i].hw_ctl) {
> DPU_ERROR("invalid lm or ctl assigned to mixer\n");
> return;
> @@ -308,7 +308,7 @@ static void _dpu_crtc_blend_setup(struct drm_crtc *crtc)
>
> _dpu_crtc_blend_setup_mixer(crtc, dpu_crtc, mixer);
>
> - for (i = 0; i < dpu_crtc->num_mixers; i++) {
> + for (i = 0; i < cstate->num_mixers; i++) {
> ctl = mixer[i].hw_ctl;
> lm = mixer[i].hw_lm;
>
> @@ -530,7 +530,7 @@ static void _dpu_crtc_setup_mixer_for_encoder(
> struct drm_crtc *crtc,
> struct drm_encoder *enc)
> {
> - struct dpu_crtc *dpu_crtc = to_dpu_crtc(crtc);
> + struct dpu_crtc_state *cstate = to_dpu_crtc_state(crtc->state);
> struct dpu_kms *dpu_kms = _dpu_crtc_get_kms(crtc);
> struct dpu_rm *rm = _kms->rm;
> struct dpu_crtc_mixer *mixer;
> @@ -542,8 +542,8 @@ static void _dpu_crtc_setup_mixer_for_encoder(
> dpu_rm_init_hw_iter(_iter, enc->base.id, DPU_HW_BLK_CTL);
>
> /* Set up all the mixers and ctls reserved by this encoder */
> - for (i = dpu_crtc->num_mixers; i < ARRAY_SIZE(dpu_crtc->mixers); i++) {
> - mixer = _crtc->mixers[i];
> + for (i = cstate->num_mixers; i < ARRAY_SIZE(cstate->mixers); i++) {
> + mixer = >mixers[i];
>
> if (!dpu_rm_get_hw(rm, _iter))
> break;
> @@ -568,7 +568,7 @@ static void _dpu_crtc_setup_mixer_for_encoder(
>
> mixer->encoder = enc;
>
> - dpu_crtc->num_mixers++;
> + cstate->num_mixers++;
> DPU_DEBUG("setup mixer %d: lm %d\n",
> i, mixer->hw_lm->idx - LM_0);
> DPU_DEBUG("setup mixer %d: ctl %d\n",
> @@ -579,11 +579,11 @@ static void _dpu_crtc_setup_mixer_for_encoder(
> static void _dpu_crtc_setup_mixers(struct drm_crtc *crtc)
> {
> struct dpu_crtc *dpu_crtc =
Re: [PATCH libdrm] libdrm: Allow dynamic drm majors on linux
On 2018-08-31 4:46 p.m., Thomas Hellstrom wrote: > On 08/31/2018 04:38 PM, Michel Dänzer wrote: >> [ Adding the amd-gfx list ] >> >> On 2018-08-31 3:05 p.m., Thomas Hellstrom wrote: >>> On 08/31/2018 02:30 PM, Emil Velikov wrote: On 31 August 2018 at 12:54, Thomas Hellstrom wrote: > To determine whether a device node is a drm device node or not, the > code > currently compares the node's major number to the static drm major > device > number. > > This breaks the standalone vmwgfx driver on XWayland dri clients, > Any particular reason why the code doesn't use a fixed node there? It will make the diff vs the in-kernel driver a bit smaller. >>> Because then it won't be able to interoperate with other in-tree >>> drivers, like virtual drm drivers or passthrough usb drm drivers. >>> There is no clean way to share the minor number allocation with in-tree >>> drm, so standalone vmwgfx is using dynamic major allocation. >> I wonder why I haven't heard of any of these issues with the standalone >> version of amdgpu shipped in packaged AMD releases. Does that also use a >> different major number? If yes, maybe it's just that nobody has tried >> Xwayland clients with that driver. If no, how does it avoid the other >> issues described above? >> >> > Is standalone AMD supposed to be able to coexist with in-tree drm drivers? Yes, it does, it's working e.g. on laptops with an Intel integrated and an AMD discrete GPU. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] libdrm: Allow dynamic drm majors on linux
On 08/31/2018 04:38 PM, Michel Dänzer wrote: [ Adding the amd-gfx list ] On 2018-08-31 3:05 p.m., Thomas Hellstrom wrote: On 08/31/2018 02:30 PM, Emil Velikov wrote: On 31 August 2018 at 12:54, Thomas Hellstrom wrote: To determine whether a device node is a drm device node or not, the code currently compares the node's major number to the static drm major device number. This breaks the standalone vmwgfx driver on XWayland dri clients, Any particular reason why the code doesn't use a fixed node there? It will make the diff vs the in-kernel driver a bit smaller. Because then it won't be able to interoperate with other in-tree drivers, like virtual drm drivers or passthrough usb drm drivers. There is no clean way to share the minor number allocation with in-tree drm, so standalone vmwgfx is using dynamic major allocation. I wonder why I haven't heard of any of these issues with the standalone version of amdgpu shipped in packaged AMD releases. Does that also use a different major number? If yes, maybe it's just that nobody has tried Xwayland clients with that driver. If no, how does it avoid the other issues described above? Is standalone AMD supposed to be able to coexist with in-tree drm drivers? /Thomas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 09/14] drm/msm/dpu: make crtc get_mixer_width helper static
On Tue, Aug 28, 2018 at 05:39:58PM -0700, Jeykumar Sankaran wrote:
> Mark CRTC get_mixer_width helper API static as it is
> not used outside the file.
>
> Signed-off-by: Jeykumar Sankaran
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 21 ++---
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 18 --
> 2 files changed, 18 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> index 92eda3e..e061847 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> @@ -47,6 +47,20 @@
> #define LEFT_MIXER 0
> #define RIGHT_MIXER 1
>
> +static inline int _dpu_crtc_get_mixer_width(struct dpu_crtc *dpu_crtc,
> + struct dpu_crtc_state *cstate, struct drm_display_mode *mode)
> +{
> + u32 mixer_width;
> +
> + if (!dpu_crtc || !cstate || !mode)
> + return 0;
> +
> + mixer_width = (cstate->num_mixers == CRTC_DUAL_MIXERS ?
> + mode->hdisplay / CRTC_DUAL_MIXERS : mode->hdisplay);
> +
> + return mixer_width;
> +}
This function feels a little too beefy to be inline.
However(!!):
- None of the NULL checks are needed
- the mixer_width local variable isn't needed
- dpu_crtc isn't even used
- the divisor is always == cstate->num_mixers
So you can actually get an inline-worth function out of this, all of that
simplifies down to:
static inline int dpu_crtc_get_mixer_width(struct dpu_crtc_state *cstate,
struct drm_display_mode *mode)
{
return mode->hdisplay / cstate->num_mixers;
}
> +
> static inline struct dpu_kms *_dpu_crtc_get_kms(struct drm_crtc *crtc)
> {
> struct msm_drm_private *priv;
> @@ -601,7 +615,8 @@ static void _dpu_crtc_setup_lm_bounds(struct drm_crtc
> *crtc,
> cstate = to_dpu_crtc_state(state);
>
> adj_mode = >adjusted_mode;
> - crtc_split_width = dpu_crtc_get_mixer_width(dpu_crtc, cstate, adj_mode);
> + crtc_split_width = _dpu_crtc_get_mixer_width(dpu_crtc, cstate,
> + adj_mode);
>
> for (i = 0; i < dpu_crtc->num_mixers; i++) {
> struct drm_rect *r = >lm_bounds[i];
> @@ -1299,7 +1314,7 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
>
> memset(pipe_staged, 0, sizeof(pipe_staged));
>
> - mixer_width = dpu_crtc_get_mixer_width(dpu_crtc, cstate, mode);
> + mixer_width = _dpu_crtc_get_mixer_width(dpu_crtc, cstate, mode);
>
> _dpu_crtc_setup_lm_bounds(crtc, state);
>
> @@ -1536,7 +1551,7 @@ static int _dpu_debugfs_status_show(struct seq_file *s,
> void *data)
>
> mutex_lock(_crtc->crtc_lock);
> mode = >state->adjusted_mode;
> - out_width = dpu_crtc_get_mixer_width(dpu_crtc, cstate, mode);
> + out_width = _dpu_crtc_get_mixer_width(dpu_crtc, cstate, mode);
>
> seq_printf(s, "crtc:%d width:%d height:%d\n", crtc->base.id,
> mode->hdisplay, mode->vdisplay);
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
> index ec9c538..5e4dc5c 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
> @@ -238,24 +238,6 @@ struct dpu_crtc_state {
> container_of(x, struct dpu_crtc_state, base)
>
> /**
> - * dpu_crtc_get_mixer_width - get the mixer width
> - * Mixer width will be same as panel width(/2 for split)
> - */
> -static inline int dpu_crtc_get_mixer_width(struct dpu_crtc *dpu_crtc,
> - struct dpu_crtc_state *cstate, struct drm_display_mode *mode)
> -{
> - u32 mixer_width;
> -
> - if (!dpu_crtc || !cstate || !mode)
> - return 0;
> -
> - mixer_width = (dpu_crtc->num_mixers == CRTC_DUAL_MIXERS ?
> - mode->hdisplay / CRTC_DUAL_MIXERS : mode->hdisplay);
> -
> - return mixer_width;
> -}
> -
> -/**
> * dpu_crtc_get_mixer_height - get the mixer height
> * Mixer height will be same as panel height
> */
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] libdrm: Allow dynamic drm majors on linux
[ Adding the amd-gfx list ] On 2018-08-31 3:05 p.m., Thomas Hellstrom wrote: > On 08/31/2018 02:30 PM, Emil Velikov wrote: >> On 31 August 2018 at 12:54, Thomas Hellstrom >> wrote: >>> To determine whether a device node is a drm device node or not, the code >>> currently compares the node's major number to the static drm major >>> device >>> number. >>> >>> This breaks the standalone vmwgfx driver on XWayland dri clients, >>> >> Any particular reason why the code doesn't use a fixed node there? >> It will make the diff vs the in-kernel driver a bit smaller. > Because then it won't be able to interoperate with other in-tree > drivers, like virtual drm drivers or passthrough usb drm drivers. > There is no clean way to share the minor number allocation with in-tree > drm, so standalone vmwgfx is using dynamic major allocation. I wonder why I haven't heard of any of these issues with the standalone version of amdgpu shipped in packaged AMD releases. Does that also use a different major number? If yes, maybe it's just that nobody has tried Xwayland clients with that driver. If no, how does it avoid the other issues described above? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm] add gitlab-ci builds of libdrm
It currently does 4 builds: 2 using Meson and 2 using Autotools, 2 using the latest dependencies on ArchLinux and 2 using very old dependencies on Debian (including manually building libpciaccess to have the oldest version supported, to make sure it keeps being supported). All the build options are turned on for both Meson and Autotools. Signed-off-by: Eric Engestrom --- See it in action on my fork: https://gitlab.freedesktop.org/eric/libdrm/pipelines/3885 --- .gitlab-ci.yml | 173 + 1 file changed, 173 insertions(+) create mode 100644 .gitlab-ci.yml diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml new file mode 100644 index ..a0f3ecb9d7f7f95443a7 --- /dev/null +++ b/.gitlab-ci.yml @@ -0,0 +1,173 @@ +latest-meson: + stage: build + image: base/archlinux:latest + before_script: +- pacman -Syu --noconfirm --needed +base-devel +meson +libpciaccess +libxslt docbook-xsl +valgrind +libatomic_ops +cairo cunit + script: +- meson _build +-D amdgpu=true +-D cairo-tests=true +-D etnaviv=true +-D exynos=true +-D freedreno=true +-D freedreno-kgsl=true +-D intel=true +-D libkms=true +-D man-pages=true +-D nouveau=true +-D omap=true +-D radeon=true +-D tegra=true +-D udev=true +-D valgrind=true +-D vc4=true +-D vmwgfx=true +- ninja -C _build +- ninja -C _build test + +latest-autotools: + stage: build + image: base/archlinux:latest + before_script: +- pacman -Syu --noconfirm --needed +base-devel +libpciaccess +libxslt docbook-xsl +valgrind +libatomic_ops +cairo cunit +xorg-util-macros +git # autogen.sh depends on git + script: +- mkdir _build +- cd _build +- ../autogen.sh +--enable-udev +--enable-libkms +--enable-intel +--enable-radeon +--enable-admgpu +--enable-nouveau +--enable-vmwfgx +--enable-omap-experimental-api +--enable-exynos-experimental-api +--enable-freedreno +--enable-freedreno-kgsl +--enable-tegra-experimental-api +--enable-vc4 +--enable-etnaviv-experimental-api +- make +- make check + +oldest-meson: + stage: build + image: debian:stable + before_script: +- printf > /etc/dpkg/dpkg.cfg.d/99-exclude-cruft "%s\n" +'path-exclude=/usr/share/doc/*' +'path-exclude=/usr/share/man/*' +- printf > /usr/sbin/policy-rc.d "%s\n" +'#!/bin/sh' +'exit 101' +- chmod +x /usr/sbin/policy-rc.d +- apt-get update +- apt-get -y --no-install-recommends install +build-essential +pkg-config +xsltproc +libxslt1-dev docbook-xsl +valgrind +libatomic-ops-dev +libcairo2-dev libcunit1-dev +ninja-build +python3 python3-pip +wget +- LIBPCIACCESS_VERSION=libpciaccess-0.10 && + wget --no-check-certificate https://xorg.freedesktop.org/releases/individual/lib/$LIBPCIACCESS_VERSION.tar.bz2 && + tar -jxvf $LIBPCIACCESS_VERSION.tar.bz2 && + (cd $LIBPCIACCESS_VERSION && ./configure --prefix=$HOME/prefix && make install) +- pip3 install wheel setuptools +- pip3 install meson==0.43 + script: +- export PKG_CONFIG_PATH=$HOME/prefix/lib/pkgconfig:$HOME/prefix/share/pkgconfig +- export LD_LIBRARY_PATH="$HOME/prefix/lib:$LD_LIBRARY_PATH" +- meson _build +-D amdgpu=true +-D cairo-tests=true +-D etnaviv=true +-D exynos=true +-D freedreno=true +-D freedreno-kgsl=true +-D intel=true +-D libkms=true +-D man-pages=true +-D nouveau=true +-D omap=true +-D radeon=true +-D tegra=true +-D udev=true +-D valgrind=true +-D vc4=true +-D vmwgfx=true +- ninja -C _build +- ninja -C _build test + +oldest-autotools: + stage: build + image: debian:stable + before_script: +- printf > /etc/dpkg/dpkg.cfg.d/99-exclude-cruft "%s\n" +'path-exclude=/usr/share/doc/*' +'path-exclude=/usr/share/man/*' +- printf > /usr/sbin/policy-rc.d "%s\n" +'#!/bin/sh' +'exit 101' +- chmod +x /usr/sbin/policy-rc.d +- apt-get update +- apt-get -y --no-install-recommends install +build-essential +automake +autoconf +libtool +pkg-config +xsltproc +libxslt1-dev docbook-xsl +valgrind +libatomic-ops-dev +libcairo2-dev libcunit1-dev +wget +xutils-dev +git # autogen.sh depends on git +- LIBPCIACCESS_VERSION=libpciaccess-0.10 && + wget --no-check-certificate https://xorg.freedesktop.org/releases/individual/lib/$LIBPCIACCESS_VERSION.tar.bz2 && +
[PATCH v3] of/platform: initialise AMBA default DMA masks
This addresses a v4.19-rc1 regression in the PL111 DRM driver
in drivers/gpu/pl111/*
The driver uses the CMA KMS helpers and will thus at some
point call down to dma_alloc_attrs() to allocate a chunk
of contigous DMA memory for the framebuffer.
It appears that in v4.18, it was OK that this (and other
DMA mastering AMBA devices) left dev->coherent_dma_mask
blank (zero).
In v4.19-rc1 the WARN_ON_ONCE(dev && !dev->coherent_dma_mask)
in dma_alloc_attrs() in include/linux/dma-mapping.h is
triggered. The allocation later fails when get_coherent_dma_mask()
is called from __dma_alloc() and __dma_alloc() returns
NULL:
drm-clcd-pl111 dev:20: coherent DMA mask is unset
drm-clcd-pl111 dev:20: [drm:drm_fb_helper_fbdev_setup] *ERROR*
Failed to set fbdev configuration
It turns out that in commit 4d8bde883bfb
("OF: Don't set default coherent DMA mask")
the OF core stops setting the default DMA mask on new devices,
especially those lines of the patch:
- if (!dev->coherent_dma_mask)
- dev->coherent_dma_mask = DMA_BIT_MASK(32);
Robin Murphy solved a similar problem in
a5516219b102 ("of/platform: Initialise default DMA masks")
by simply assigning dev.coherent_dma_mask and the
dev.dma_mask to point to the same when creating devices
from the device tree, and introducing the same code into
the code path creating AMBA/PrimeCell devices solved my
problem, graphics now come up.
The code simply assumes that the device can access all
of the system memory by setting the coherent DMA mask
to 0x when creating a device from the device
tree, which is crude, but seems to be what kernel v4.18
assumed.
The AMBA PrimeCells do not differ between coherent and
streaming DMA so we can just assign the same to any
DMA mask.
Possibly drivers should augment their coherent DMA mask
in accordance with "dma-ranges" from the device tree
if more finegranular masking is needed.
Reported-by: Russell King
Fixes: 4d8bde883bfb ("OF: Don't set default coherent DMA mask")
Cc: Russell King
Cc: Christoph Hellwig
Cc: Robin Murphy
Signed-off-by: Linus Walleij
---
ChangeLog v2->v3:
- Provide proper root cause analysis, point to the right
offending commit with Fixes:
- Make even more elaborate description of what is causing
this.
ChangeLog v1->v2:
- Provide a better description for the change.
---
drivers/of/platform.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 7ba90c290a42..6c59673933e9 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -241,6 +241,10 @@ static struct amba_device *of_amba_device_create(struct
device_node *node,
if (!dev)
goto err_clear_flag;
+ /* AMBA devices only support a single DMA mask */
+ dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
+ dev->dev.dma_mask = >dev.coherent_dma_mask;
+
/* setup generic device info */
dev->dev.of_node = of_node_get(node);
dev->dev.fwnode = >fwnode;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107694] [wine] RAGE: texture problems
https://bugs.freedesktop.org/show_bug.cgi?id=107694 --- Comment #2 from Sven Arvidsson --- Created attachment 141396 --> https://bugs.freedesktop.org/attachment.cgi?id=141396=edit rendering on i965/skylake Can't say that I agree. Attached is a screenshot from the same place in the game, with the same settings on i965/Skylake, no texture bug. Software rendering with llvmpipe is likewise fine. Maybe you're thinking of the notorious texture pop-ins? This is quite a different problem. The second video clip I linked to was recorded on a Tahiti GPU in 2016 and was presumably using radeon and not amdgpu. Probably why my regression testing lead nowhere. -- 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 libdrm] libdrm: Allow dynamic drm majors on linux
Hi, Emil On 08/31/2018 02:30 PM, Emil Velikov wrote: Hi Thomas, On 31 August 2018 at 12:54, Thomas Hellstrom wrote: To determine whether a device node is a drm device node or not, the code currently compares the node's major number to the static drm major device number. This breaks the standalone vmwgfx driver on XWayland dri clients, Any particular reason why the code doesn't use a fixed node there? It will make the diff vs the in-kernel driver a bit smaller. Because then it won't be able to interoperate with other in-tree drivers, like virtual drm drivers or passthrough usb drm drivers. There is no clean way to share the minor number allocation with in-tree drm, so standalone vmwgfx is using dynamic major allocation. and any future attempt to introduce dynamic device numbers for drm. I'm not sure how well any such attempt will pan out, regardless of the libdrm checks. Namely: the static 226 has been used by a number of tools that interpose the libc' ioctl function. There could be others that also depend on it. True, in any case for existing drivers changing static 226 to something else is at least 10+ years away according to Linus' policy, so the main issue here is really to get rid of a big annoyance in the standalone vmwgfx case. /Thomas Personally, I'd go with the kernel developers decision. Dave, Daniel, others Should we keep or drop the major == 226 checks. Thanks Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 96620] build failure in igt_fb.c due to missing inttypes.h
https://bugs.freedesktop.org/show_bug.cgi?id=96620 Lakshmi changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution|--- |FIXED --- Comment #4 from Lakshmi --- Sorry for the delay... I assume this issue has been fixed. Closing now. Feel free to reopen if you still have the issue. -- 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 96620] build failure in igt_fb.c due to missing inttypes.h
https://bugs.freedesktop.org/show_bug.cgi?id=96620 Lakshmi changed: What|Removed |Added Status|RESOLVED|CLOSED -- 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 libdrm] libdrm: Allow dynamic drm majors on linux
Hi Thomas, On 31 August 2018 at 12:54, Thomas Hellstrom wrote: > To determine whether a device node is a drm device node or not, the code > currently compares the node's major number to the static drm major device > number. > > This breaks the standalone vmwgfx driver on XWayland dri clients, > https://cgit.freedesktop.org/mesa/vmwgfx Any particular reason why the code doesn't use a fixed node there? It will make the diff vs the in-kernel driver a bit smaller. > and any future attempt to introduce dynamic device numbers for drm. > I'm not sure how well any such attempt will pan out, regardless of the libdrm checks. Namely: the static 226 has been used by a number of tools that interpose the libc' ioctl function. There could be others that also depend on it. Personally, I'd go with the kernel developers decision. Dave, Daniel, others Should we keep or drop the major == 226 checks. Thanks Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Question on 640x480 @ 72fps
On Thu, Aug 30, 2018 at 07:32:58PM -0700, abhin...@codeaurora.org wrote:
> Hello
>
> During one of our internal tests, we ran into an issue where the calculated
> refresh rate for the mode using the drm_mode_vrefresh() API doesnt
> match the theoretical value due to rounding.
>
> 552{ DRM_MODE("640x480", DRM_MODE_TYPE_DRIVER, 31500, 640, 664,
> 553 704, 832, 0, 480, 489, 492, 520, 0,
> 554 DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC) }, /*
> 640x480@72Hz */
>
>
> int drm_mode_vrefresh(const struct drm_display_mode *mode)
> {
> int refresh = 0;
>
> if (mode->vrefresh > 0)
> refresh = mode->vrefresh;
> else if (mode->htotal > 0 && mode->vtotal > 0) {
> unsigned int num, den;
>
> num = mode->clock * 1000;
> den = mode->htotal * mode->vtotal;
>
> if (mode->flags & DRM_MODE_FLAG_INTERLACE)
> num *= 2;
> if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
> den *= 2;
> if (mode->vscan > 1)
> den *= mode->vscan;
>
> refresh = DIV_ROUND_CLOSEST(num, den);
> }
> return refresh;
> }
> EXPORT_SYMBOL(drm_mode_vrefresh);
>
> As per the math of this API, the vrefresh comes up to 72.8 fps ( 31500 *
> 1000 ) / (832 * 520) .
>
> Hence this gets rounded to 73fps.
>
> However as per the spec, this mode should have the vrefresh as 72fps.
I'm not sure where the official spec is, but this random webpage [1] I found
with
Google has the same timing values as you have above. The timing information for
the mode doesn't specify the refresh rate, but rather the pclk. The refresh rate
comes from (pclk / (vtotal * htotal)), which comes out to 72.8Hz. We have to
round one way or the other, so DIV_ROUND_CLOSEST is more correct.
Like Ville said, the rounding doesn't really make a difference. Since we'll be
generating the correct pixel clock with the correct pitch, the hardware will be
operating with a 72.8Hz refresh.
Hopefully that makes sense?
Sean
[1] http://martin.hinner.info/vga/timing.html
>
> So to satisfy that, we must round-down in this function. That might break
> other modes though.
>
> Do you have any suggestions on how to fix-up this mode ? Shall we just
> directly specify the vrefresh in the edid_est_modes[] and drm_dmt_modes[]
> static array?
>
> I can submit a PATCH based on the approach we agree on here.
>
> Thanks
>
> Abhinav
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dt-bindings: Fix typo in compatible description.
On Wed, Aug 22, 2018 at 03:43:48PM +0200, Jan Tuerk wrote: > This fixes the error in the compatible documentation for the EDT > etm0700[g].. panels which have accidentally documented as etm0700[8]0.. This needs a more specific subject. > > Signed-off-by: Jan Tuerk > --- > .../devicetree/bindings/display/panel/edt,et-series.txt | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git > a/Documentation/devicetree/bindings/display/panel/edt,et-series.txt > b/Documentation/devicetree/bindings/display/panel/edt,et-series.txt > index f56b99ebd9be..5759d64d0c15 100644 > --- a/Documentation/devicetree/bindings/display/panel/edt,et-series.txt > +++ b/Documentation/devicetree/bindings/display/panel/edt,et-series.txt > @@ -23,13 +23,13 @@ simple-panel.txt > > +-+-+-+ > | Identifier | compatbile | description > | > > +=+=+=+ > -| ETM0700G0DH6| edt,etm070080dh6| WVGA TFT Display with capacitive > | > +| ETM0700G0DH6| edt,etm0700g0dh6| WVGA TFT Display with capacitive > | > | | | Touchscreen > | > > +-+-+-+ > -| ETM0700G0BDH6 | edt,etm070080bdh6 | Same as ETM0700G0DH6 but with > | > +| ETM0700G0BDH6 | edt,etm0700g0bdh6 | Same as ETM0700G0DH6 but with > | > | | | inverted pixel clock. > | > > +-+-+-+ > -| ETM0700G0EDH6 | edt,etm070080edh6 | Same display as the ETM0700G0BDH6, > | > +| ETM0700G0EDH6 | edt,etm0700g0edh6 | Same display as the ETM0700G0BDH6, > | > | | | but with changed Hardware for the > | > | | | backlight and the touch interface > | > > +-+-+-+ > -- > 2.18.0 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] libdrm: Allow dynamic drm majors on linux
On Friday, 2018-08-31 13:54:19 +0200, Thomas Hellstrom wrote:
> To determine whether a device node is a drm device node or not, the code
> currently compares the node's major number to the static drm major device
> number.
>
> This breaks the standalone vmwgfx driver on XWayland dri clients,
> https://cgit.freedesktop.org/mesa/vmwgfx
> and any future attempt to introduce dynamic device numbers for drm.
>
> So instead of checking for the device major, instead check for the presence
> of the /sys/dev/char/:/device/drm directory.
Just FYI, this means it now matches /dev/fb0 too.
I don't think this will be an issue, but just pointing it out so people notice.
>
> Signed-off-by: Thomas Hellstrom
> ---
> xf86drm.c | 31 +++
> 1 file changed, 23 insertions(+), 8 deletions(-)
>
> diff --git a/xf86drm.c b/xf86drm.c
> index 7807dce9..4cfc5d3e 100644
> --- a/xf86drm.c
> +++ b/xf86drm.c
> @@ -2761,6 +2761,21 @@ char *drmGetDeviceNameFromFd(int fd)
> return strdup(name);
> }
>
> +static bool
> +drmNodeIsDRM(int maj, int min)
> +{
> +#ifdef __linux__
> + char path[64];
> + struct stat sbuf;
> +
> + snprintf(path, sizeof(path), "/sys/dev/char/%d:%d/device/drm",
> +maj, min);
Nit: mixing tabs and space on this line.
With that fixed:
Reviewed-by: Eric Engestrom
> + return stat(path, ) == 0;
> +#else
> + return maj == DRM_MAJOR;
> +#endif
> +}
> +
> int drmGetNodeTypeFromFd(int fd)
> {
> struct stat sbuf;
> @@ -2772,7 +2787,7 @@ int drmGetNodeTypeFromFd(int fd)
> maj = major(sbuf.st_rdev);
> min = minor(sbuf.st_rdev);
>
> -if (maj != DRM_MAJOR || !S_ISCHR(sbuf.st_mode)) {
> +if (!drmNodeIsDRM(maj, min) || !S_ISCHR(sbuf.st_mode)) {
> errno = EINVAL;
> return -1;
> }
> @@ -2837,7 +2852,7 @@ static char *drmGetMinorNameForFD(int fd, int type)
> maj = major(sbuf.st_rdev);
> min = minor(sbuf.st_rdev);
>
> -if (maj != DRM_MAJOR || !S_ISCHR(sbuf.st_mode))
> +if (!drmNodeIsDRM(maj, min) || !S_ISCHR(sbuf.st_mode))
> return NULL;
>
> snprintf(buf, sizeof(buf), "/sys/dev/char/%d:%d/device/drm", maj, min);
> @@ -2871,7 +2886,7 @@ static char *drmGetMinorNameForFD(int fd, int type)
> maj = major(sbuf.st_rdev);
> min = minor(sbuf.st_rdev);
>
> -if (maj != DRM_MAJOR || !S_ISCHR(sbuf.st_mode))
> +if (!drmNodeIsDRM(maj, min) || !S_ISCHR(sbuf.st_mode))
> return NULL;
>
> switch (type) {
> @@ -3731,7 +3746,7 @@ process_device(drmDevicePtr *device, const char *d_name,
> maj = major(sbuf.st_rdev);
> min = minor(sbuf.st_rdev);
>
> -if (maj != DRM_MAJOR || !S_ISCHR(sbuf.st_mode))
> +if (!drmNodeIsDRM(maj, min) || !S_ISCHR(sbuf.st_mode))
> return -1;
>
> subsystem_type = drmParseSubsystemType(maj, min);
> @@ -3845,7 +3860,7 @@ int drmGetDevice2(int fd, uint32_t flags, drmDevicePtr
> *device)
> maj = major(sbuf.st_rdev);
> min = minor(sbuf.st_rdev);
>
> -if (maj != DRM_MAJOR || !S_ISCHR(sbuf.st_mode))
> +if (!drmNodeIsDRM(maj, min) || !S_ISCHR(sbuf.st_mode))
> return -EINVAL;
>
> node_type = drmGetMinorType(min);
> @@ -3911,7 +3926,7 @@ int drmGetDevice2(int fd, uint32_t flags, drmDevicePtr
> *device)
> maj = major(sbuf.st_rdev);
> min = minor(sbuf.st_rdev);
>
> -if (maj != DRM_MAJOR || !S_ISCHR(sbuf.st_mode))
> +if (!drmNodeIsDRM(maj, min) || !S_ISCHR(sbuf.st_mode))
> return -EINVAL;
>
> subsystem_type = drmParseSubsystemType(maj, min);
> @@ -4071,7 +4086,7 @@ char *drmGetDeviceNameFromFd2(int fd)
> maj = major(sbuf.st_rdev);
> min = minor(sbuf.st_rdev);
>
> -if (maj != DRM_MAJOR || !S_ISCHR(sbuf.st_mode))
> +if (!drmNodeIsDRM(maj, min) || !S_ISCHR(sbuf.st_mode))
> return NULL;
>
> snprintf(path, sizeof(path), "/sys/dev/char/%d:%d", maj, min);
> @@ -4097,7 +4112,7 @@ char *drmGetDeviceNameFromFd2(int fd)
> maj = major(sbuf.st_rdev);
> min = minor(sbuf.st_rdev);
>
> -if (maj != DRM_MAJOR || !S_ISCHR(sbuf.st_mode))
> +if (!drmNodeIsDRM(maj, min) || !S_ISCHR(sbuf.st_mode))
> return NULL;
>
> node_type = drmGetMinorType(min);
> --
> 2.18.0.rc1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm] libdrm: Allow dynamic drm majors on linux
To determine whether a device node is a drm device node or not, the code
currently compares the node's major number to the static drm major device
number.
This breaks the standalone vmwgfx driver on XWayland dri clients,
https://cgit.freedesktop.org/mesa/vmwgfx
and any future attempt to introduce dynamic device numbers for drm.
So instead of checking for the device major, instead check for the presence
of the /sys/dev/char/:/device/drm directory.
Signed-off-by: Thomas Hellstrom
---
xf86drm.c | 31 +++
1 file changed, 23 insertions(+), 8 deletions(-)
diff --git a/xf86drm.c b/xf86drm.c
index 7807dce9..4cfc5d3e 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -2761,6 +2761,21 @@ char *drmGetDeviceNameFromFd(int fd)
return strdup(name);
}
+static bool
+drmNodeIsDRM(int maj, int min)
+{
+#ifdef __linux__
+ char path[64];
+ struct stat sbuf;
+
+ snprintf(path, sizeof(path), "/sys/dev/char/%d:%d/device/drm",
+ maj, min);
+ return stat(path, ) == 0;
+#else
+ return maj == DRM_MAJOR;
+#endif
+}
+
int drmGetNodeTypeFromFd(int fd)
{
struct stat sbuf;
@@ -2772,7 +2787,7 @@ int drmGetNodeTypeFromFd(int fd)
maj = major(sbuf.st_rdev);
min = minor(sbuf.st_rdev);
-if (maj != DRM_MAJOR || !S_ISCHR(sbuf.st_mode)) {
+if (!drmNodeIsDRM(maj, min) || !S_ISCHR(sbuf.st_mode)) {
errno = EINVAL;
return -1;
}
@@ -2837,7 +2852,7 @@ static char *drmGetMinorNameForFD(int fd, int type)
maj = major(sbuf.st_rdev);
min = minor(sbuf.st_rdev);
-if (maj != DRM_MAJOR || !S_ISCHR(sbuf.st_mode))
+if (!drmNodeIsDRM(maj, min) || !S_ISCHR(sbuf.st_mode))
return NULL;
snprintf(buf, sizeof(buf), "/sys/dev/char/%d:%d/device/drm", maj, min);
@@ -2871,7 +2886,7 @@ static char *drmGetMinorNameForFD(int fd, int type)
maj = major(sbuf.st_rdev);
min = minor(sbuf.st_rdev);
-if (maj != DRM_MAJOR || !S_ISCHR(sbuf.st_mode))
+if (!drmNodeIsDRM(maj, min) || !S_ISCHR(sbuf.st_mode))
return NULL;
switch (type) {
@@ -3731,7 +3746,7 @@ process_device(drmDevicePtr *device, const char *d_name,
maj = major(sbuf.st_rdev);
min = minor(sbuf.st_rdev);
-if (maj != DRM_MAJOR || !S_ISCHR(sbuf.st_mode))
+if (!drmNodeIsDRM(maj, min) || !S_ISCHR(sbuf.st_mode))
return -1;
subsystem_type = drmParseSubsystemType(maj, min);
@@ -3845,7 +3860,7 @@ int drmGetDevice2(int fd, uint32_t flags, drmDevicePtr
*device)
maj = major(sbuf.st_rdev);
min = minor(sbuf.st_rdev);
-if (maj != DRM_MAJOR || !S_ISCHR(sbuf.st_mode))
+if (!drmNodeIsDRM(maj, min) || !S_ISCHR(sbuf.st_mode))
return -EINVAL;
node_type = drmGetMinorType(min);
@@ -3911,7 +3926,7 @@ int drmGetDevice2(int fd, uint32_t flags, drmDevicePtr
*device)
maj = major(sbuf.st_rdev);
min = minor(sbuf.st_rdev);
-if (maj != DRM_MAJOR || !S_ISCHR(sbuf.st_mode))
+if (!drmNodeIsDRM(maj, min) || !S_ISCHR(sbuf.st_mode))
return -EINVAL;
subsystem_type = drmParseSubsystemType(maj, min);
@@ -4071,7 +4086,7 @@ char *drmGetDeviceNameFromFd2(int fd)
maj = major(sbuf.st_rdev);
min = minor(sbuf.st_rdev);
-if (maj != DRM_MAJOR || !S_ISCHR(sbuf.st_mode))
+if (!drmNodeIsDRM(maj, min) || !S_ISCHR(sbuf.st_mode))
return NULL;
snprintf(path, sizeof(path), "/sys/dev/char/%d:%d", maj, min);
@@ -4097,7 +4112,7 @@ char *drmGetDeviceNameFromFd2(int fd)
maj = major(sbuf.st_rdev);
min = minor(sbuf.st_rdev);
-if (maj != DRM_MAJOR || !S_ISCHR(sbuf.st_mode))
+if (!drmNodeIsDRM(maj, min) || !S_ISCHR(sbuf.st_mode))
return NULL;
node_type = drmGetMinorType(min);
--
2.18.0.rc1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 2/2] drm/mali-dp: Implement plane alpha and pixel blend on malidp
Checks the pixel blending mode and plane alpha value when
do the plane_check. Mali DP supports blending the current plane
with the background either based on the pixel alpha blending
mode or by using the layer's alpha value, but not both at the
same time. If both case, plane_check will return failed.
Sets the HW when doing plane_update accordingly. If plane alpha
is the 0x, set the pixel blending bits accordingly. If not
we'd set ALPHA bit as zero and layer alpha value.
Changes since v1:
- Introduces to use it in the malidp driver, which depends on
the plane alpha patch
Changes since v2:
- Refines the comments of drm/mali-dp patchset
Changes since v3:
- Adds hardware limitation check
Changes since v4:
- Updates on drm/malidp, hardware limitation check only when
the format has alpha pixel.
- Rebases on drm-misc-next.
Signed-off-by: Lowry Li
Acked-by: Liviu Dudau
---
drivers/gpu/drm/arm/malidp_planes.c | 75 ++---
1 file changed, 44 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_planes.c
b/drivers/gpu/drm/arm/malidp_planes.c
index 49c37f6..96ee429 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -36,6 +36,7 @@
#define LAYER_COMP_MASK (0x3 << 12)
#define LAYER_COMP_PIXEL (0x3 << 12)
#define LAYER_COMP_PLANE (0x2 << 12)
+#define LAYER_PMUL_ENABLE(0x1 << 14)
#define LAYER_ALPHA_OFFSET (16)
#define LAYER_ALPHA_MASK (0xff)
#define LAYER_ALPHA(x) (((x) & LAYER_ALPHA_MASK) <<
LAYER_ALPHA_OFFSET)
@@ -180,6 +181,7 @@ static int malidp_de_plane_check(struct drm_plane *plane,
struct malidp_plane_state *ms = to_malidp_plane_state(state);
bool rotated = state->rotation & MALIDP_ROTATED_MASK;
struct drm_framebuffer *fb;
+ u16 pixel_alpha = state->pixel_blend_mode;
int i, ret;
if (!state->crtc || !state->fb)
@@ -242,6 +244,12 @@ static int malidp_de_plane_check(struct drm_plane *plane,
ms->rotmem_size = val;
}
+ /* HW can't support plane + pixel blending */
+ if ((state->alpha != DRM_BLEND_ALPHA_OPAQUE) &&
+ (pixel_alpha != DRM_MODE_BLEND_PIXEL_NONE) &&
+ fb->format->has_alpha)
+ return -EINVAL;
+
return 0;
}
@@ -323,17 +331,19 @@ static void malidp_de_plane_update(struct drm_plane
*plane,
{
struct malidp_plane *mp;
struct malidp_plane_state *ms = to_malidp_plane_state(plane->state);
+ struct drm_plane_state *state = plane->state;
+ u16 pixel_alpha = state->pixel_blend_mode;
+ u8 plane_alpha = state->alpha >> 8;
u32 src_w, src_h, dest_w, dest_h, val;
int i;
- bool format_has_alpha = plane->state->fb->format->has_alpha;
mp = to_malidp_plane(plane);
/* convert src values from Q16 fixed point to integer */
- src_w = plane->state->src_w >> 16;
- src_h = plane->state->src_h >> 16;
- dest_w = plane->state->crtc_w;
- dest_h = plane->state->crtc_h;
+ src_w = state->src_w >> 16;
+ src_h = state->src_h >> 16;
+ dest_w = state->crtc_w;
+ dest_h = state->crtc_h;
val = malidp_hw_read(mp->hwdev, mp->layer->base);
val = (val & ~LAYER_FORMAT_MASK) | ms->format;
@@ -342,14 +352,14 @@ static void malidp_de_plane_update(struct drm_plane
*plane,
for (i = 0; i < ms->n_planes; i++) {
/* calculate the offset for the layer's plane registers */
u16 ptr = mp->layer->ptr + (i << 4);
- dma_addr_t fb_addr = drm_fb_cma_get_gem_addr(plane->state->fb,
-plane->state, i);
+ dma_addr_t fb_addr = drm_fb_cma_get_gem_addr(state->fb,
+state, i);
malidp_hw_write(mp->hwdev, lower_32_bits(fb_addr), ptr);
malidp_hw_write(mp->hwdev, upper_32_bits(fb_addr), ptr + 4);
}
malidp_de_set_plane_pitches(mp, ms->n_planes,
- plane->state->fb->pitches);
+ state->fb->pitches);
if ((plane->state->color_encoding != old_state->color_encoding) ||
(plane->state->color_range != old_state->color_range))
@@ -362,8 +372,8 @@ static void malidp_de_plane_update(struct drm_plane *plane,
malidp_hw_write(mp->hwdev, LAYER_H_VAL(dest_w) | LAYER_V_VAL(dest_h),
mp->layer->base + MALIDP_LAYER_COMP_SIZE);
- malidp_hw_write(mp->hwdev, LAYER_H_VAL(plane->state->crtc_x) |
- LAYER_V_VAL(plane->state->crtc_y),
+ malidp_hw_write(mp->hwdev, LAYER_H_VAL(state->crtc_x) |
+ LAYER_V_VAL(state->crtc_y),
mp->layer->base + MALIDP_LAYER_OFFSET);
if (mp->layer->id ==
[Bug 92248] [KBL/SKL/BYT/BXT/GLK] igt/kms_plane_scaling fail
https://bugs.freedesktop.org/show_bug.cgi?id=92248 Lakshmi changed: What|Removed |Added Status|RESOLVED|CLOSED -- 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 92248] [KBL/SKL/BYT/BXT/GLK] igt/kms_plane_scaling fail
https://bugs.freedesktop.org/show_bug.cgi?id=92248 Lakshmi changed: What|Removed |Added Resolution|--- |INVALID Status|REOPENED|RESOLVED --- Comment #47 from Lakshmi --- Too many issues in one bug. This is anyway a CI issue which should only be tracked in CI Bug Log. Closing as invalid. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/5] drm: Add support for handling linear tile formats
On Fri, Aug 31, 2018 at 10:14:14AM +0200, Daniel Vetter wrote:
> On Thu, Aug 23, 2018 at 06:43:40PM +0100, Alexandru-Cosmin Gheorghe wrote:
> > On Wed, Aug 22, 2018 at 10:18:51PM +0200, Daniel Vetter wrote:
> > > On Tue, Aug 21, 2018 at 07:30:03PM +0100, Alexandru Gheorghe wrote:
> > > > The previous patch added tile_w and tile_h, which represent the
> > > > horizontal and vertical sizes of a tile.
> > > >
> > > > This one uses that to plumb through drm core in order to be able to
> > > > handle linear tile formats without the need for drivers to roll up
> > > > their own implementation.
> > > >
> > > > This patch had been written with Mali-dp X0L2 and X0L0 in mind which
> > > > is a 1 plane YCbCr 420 format with a 2x2 tile, that uses in average 2
> > > > bytes per pixel and where tiles are laid out in a linear manner.
> > > >
> > > > Now what are the restrictions:
> > > >
> > > > 1. Pitch in bytes is expected to cover at least tile_h * width in
> > > > pixels. Due to this the places where the pitch is checked/used need to
> > > > be updated to take into consideration the tile_w, tile_h and
> > > > tile_size.
> > > > tile_size = cpp * tile_w * tile_h
> > > >
> > > > 2. When doing source cropping plane_src_x/y need to be a multiple of
> > > > tile_w/tile_h and we need to take into consideration the tile_w/tile_h
> > > > when computing the start address.
> > > >
> > > > For all non-tiled formats the tile_w and tile_h will be 1, so if I
> > > > didn't miss anything nothing should change.
> > > >
> > > > Regarding multi-planar linear tile formats, I'm not sure how those
> > > > should be handle I kind of assumed that tile_h/tile_w will have to be
> > > > divided by horizontal/subsampling. Anyway, I think it's best to just
> > > > put an warning in there and handle it when someone tries to add
> > > > support for them.
> > > >
> > > > Signed-off-by: Alexandru Gheorghe
> > > > ---
> > > > drivers/gpu/drm/drm_atomic.c | 8 +++
> > > > drivers/gpu/drm/drm_fb_cma_helper.c | 11 -
> > > > drivers/gpu/drm/drm_fourcc.c | 52
> > > > drivers/gpu/drm/drm_framebuffer.c| 19 +--
> > > > drivers/gpu/drm/drm_gem_framebuffer_helper.c | 10 ++--
> > > > include/drm/drm_fourcc.h | 2 +
> > > > 6 files changed, 94 insertions(+), 8 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > > > index 3eb061e11e2e..7a3e893a4cd1 100644
> > > > --- a/drivers/gpu/drm/drm_atomic.c
> > > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > > @@ -1087,6 +1087,14 @@ static int drm_atomic_plane_check(struct
> > > > drm_plane *plane,
> > > > return -ENOSPC;
> > > > }
> > > >
> > > > + /* Make sure source coordinates are a multiple of tile sizes */
> > > > + if ((state->src_x >> 16) % state->fb->format->tile_w ||
> > > > + (state->src_y >> 16) % state->fb->format->tile_h) {
> > > > + DRM_DEBUG_ATOMIC("[PLANE:%d:%s] Source coordinates do
> > > > not meet tile restrictions",
> > > > +plane->base.id, plane->name);
> > > > + return -EINVAL;
> > > > + }
> > > > +
> > > > if (plane_switching_crtc(state->state, plane, state)) {
> > > > DRM_DEBUG_ATOMIC("[PLANE:%d:%s] switching CRTC
> > > > directly\n",
> > > > plane->base.id, plane->name);
> > > > diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
> > > > b/drivers/gpu/drm/drm_fb_cma_helper.c
> > > > index 47e0e2f6642d..4d8052adce67 100644
> > > > --- a/drivers/gpu/drm/drm_fb_cma_helper.c
> > > > +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
> > > > @@ -87,6 +87,8 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct
> > > > drm_framebuffer *fb,
> > > > struct drm_gem_cma_object *obj;
> > > > dma_addr_t paddr;
> > > > u8 h_div = 1, v_div = 1;
> > > > + u32 tile_w = drm_format_tile_width(fb->format, plane);
> > > > + u32 tile_h = drm_format_tile_height(fb->format, plane);
> > > >
> > > > obj = drm_fb_cma_get_gem_obj(fb, plane);
> > > > if (!obj)
> > > > @@ -99,8 +101,13 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct
> > > > drm_framebuffer *fb,
> > > > v_div = fb->format->vsub;
> > > > }
> > > >
> > > > - paddr += (fb->format->cpp[plane] * (state->src_x >> 16)) /
> > > > h_div;
> > > > - paddr += (fb->pitches[plane] * (state->src_y >> 16)) / v_div;
> > > > + paddr += (fb->format->cpp[plane] * tile_w * (state->src_x >>
> > > > 16))
> > > > + / h_div;
> > > > + /*
> > > > +* For tile formats pitches are expected to cover at least
> > > > +* width * tile_h pixels
> > > > +*/
> > > > + paddr += ((fb->pitches[plane] / tile_h) * (state->src_y >> 16))
> > > > / v_div;
> > > >
> > > > return paddr;
> > > > }
> > > > diff --git
[Bug 98981] [IVB] igt/gem_exec_suspend/basic-s3 hangs when used with intel-ci/fast-feedback.testlist
https://bugs.freedesktop.org/show_bug.cgi?id=98981 Lakshmi changed: What|Removed |Added Status|RESOLVED|CLOSED -- 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 98981] [IVB] igt/gem_exec_suspend/basic-s3 hangs when used with intel-ci/fast-feedback.testlist
https://bugs.freedesktop.org/show_bug.cgi?id=98981 Lakshmi changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution|--- |DUPLICATE --- Comment #7 from Lakshmi --- This bug is outdated. Replace with the one used in CIbuglog. *** This bug has been marked as a duplicate of bug 106220 *** -- 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 v7 2/2] drm/i915: Adding YUV444 packed format(DRM_FORMAT_XYUV) support.
On Fri, Aug 31, 2018 at 07:24:48AM +, Lisovskiy, Stanislav wrote: > On Thu, 2018-08-30 at 11:15 -0700, Dhinakaran Pandiyan wrote: > > On Thu, 2018-08-30 at 13:57 +0100, Lisovskiy, Stanislav wrote: > > > On Wed, 2018-08-29 at 12:16 -0700, Dhinakaran Pandiyan wrote: > > > > > > > > On Wed, 2018-08-29 at 21:10 +0300, Ville Syrjälä wrote: > > > > > On Wed, Aug 29, 2018 at 02:28:47PM +0300, Stanislav Lisovskiy > > > > > wrote: > > > > > > PLANE_CTL_FORMAT_AYUV is already supported, according to > > > > > > hardware > > > > > > specification. > > > > > > > > > > > > v2: Edited commit message, removed redundant whitespaces. > > > > > > > > > > > > v3: Fixed fallthrough logic for the format switch cases. > > > > > > > > > > > > v4: Yet again fixed fallthrough logic, to reuse code from > > > > > > other > > > > > > case > > > > > > labels. > > > > > > > > > > > > v5: Started to use XYUV instead of AYUV, as we don't use > > > > > > alpha. > > > > Curious what the reason is. Is it because the hardware does not > > support > > alpha with this format? > > As I understood yes, this is a hardware limitation. > > > > > > > > > > > > > > > v6: Removed unneeded initializer for new XYUV format. > > > > > > > > > > > > v7: Added scaling support for DRM_FORMAT_XYUV > > > > > > > > I don't see yuv formats in skl_format_to_fourcc(), any idea why? > > > > > > Good point. I guess would be nice idea to add at least XYUV there > > > now. > > > I can add rest of the formats with a separate patch afterwards. > > > > Wonder if the expectation is BIOS not use yuv formats. Ville? > > I talked to Ville yesterday, I think that was basically what he said. Yes. Although I have this dream of full plane state readout (which we could then use for verification purposes at least), so adding the missing formats there would be a decent idea. -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Question on 640x480 @ 72fps
On Thu, Aug 30, 2018 at 07:32:58PM -0700, abhin...@codeaurora.org wrote:
> Hello
>
> During one of our internal tests, we ran into an issue where the
> calculated refresh rate for the mode using the drm_mode_vrefresh() API
> doesnt
> match the theoretical value due to rounding.
>
> 552{ DRM_MODE("640x480", DRM_MODE_TYPE_DRIVER, 31500, 640, 664,
> 553 704, 832, 0, 480, 489, 492, 520, 0,
> 554 DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC) }, /*
> 640x480@72Hz */
>
>
> int drm_mode_vrefresh(const struct drm_display_mode *mode)
> {
> int refresh = 0;
>
> if (mode->vrefresh > 0)
> refresh = mode->vrefresh;
> else if (mode->htotal > 0 && mode->vtotal > 0) {
> unsigned int num, den;
>
> num = mode->clock * 1000;
> den = mode->htotal * mode->vtotal;
>
> if (mode->flags & DRM_MODE_FLAG_INTERLACE)
> num *= 2;
> if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
> den *= 2;
> if (mode->vscan > 1)
> den *= mode->vscan;
>
> refresh = DIV_ROUND_CLOSEST(num, den);
> }
> return refresh;
> }
> EXPORT_SYMBOL(drm_mode_vrefresh);
>
> As per the math of this API, the vrefresh comes up to 72.8 fps ( 31500 *
> 1000 ) / (832 * 520) .
>
> Hence this gets rounded to 73fps.
>
> However as per the spec, this mode should have the vrefresh as 72fps.
Why should anyone care if it gets rounded differently?
>
> So to satisfy that, we must round-down in this function. That might
> break other modes though.
>
> Do you have any suggestions on how to fix-up this mode ? Shall we just
> directly specify the vrefresh in the edid_est_modes[] and
> drm_dmt_modes[] static array?
>
> I can submit a PATCH based on the approach we agree on here.
>
> Thanks
>
> Abhinav
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107693] [wine] Wolfenstein: The Old Blood - can't find GL_EXT_framebuffer_object
https://bugs.freedesktop.org/show_bug.cgi?id=107693 --- Comment #3 from Sven Arvidsson --- AFAIK none of the id Tech 5/6 actually uses any legacy stuff. The compatibility context is only used for initial probing by the GLEW library. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] of/platform: initialise AMBA default DMA masks
On Fri, Aug 31, 2018 at 10:26:14AM +0200, Linus Walleij wrote:
> This addresses a v4.19-rc1 regression in the PL111 DRM driver
> in drivers/gpu/pl111/*
>
> The driver uses the CMA KMS helpers and will thus at some
> point call down to dma_alloc_attrs() to allocate a chunk
> of contigous DMA memory for the framebuffer.
>
> It appears that in v4.18, it was OK that this (and other
> DMA mastering AMBA devices) left dev->coherent_dma_mask
> blank (zero).
>
> In v4.19-rc1 the WARN_ON_ONCE(dev && !dev->coherent_dma_mask)
> in dma_alloc_attrs() in include/linux/dma-mapping.h is
> triggered. The allocation later fails when get_coherent_dma_mask()
> is called from __dma_alloc() and __dma_alloc() returns
> NULL:
>
> drm-clcd-pl111 dev:20: coherent DMA mask is unset
> drm-clcd-pl111 dev:20: [drm:drm_fb_helper_fbdev_setup] *ERROR*
> Failed to set fbdev configuration
>
> I have not been able to properly bisect down to the actual
> committ causing it beacuse the kernel simply fails to build
> at to many bisection points, pushing the bisect back to places
> like the merge of entire subsystem trees, where things have
> likely been resolved while merging them.
>
> I found that Robin Murphy solved a similar problem in
> a5516219b102 ("of/platform: Initialise default DMA masks")
> by simply assigning dev.coherent_dma_mask and the
> dev.dma_mask to point to the same when creating devices
> from the device tree, and introducing the same code into
> the code path creating AMBA/PrimeCell devices solved my
> problem, graphics now come up.
>
> The code simply assumes that the device can access all
> of the system memory by setting the coherent DMA mask
> to 0x when creating a device from the device
> tree, which is crude, but seems to be what kernel v4.18
> assumed.
>
> Cc: Russell King
> Cc: Christoph Hellwig
> Cc: Robin Murphy
> Signed-off-by: Linus Walleij
> ---
> Russell, Christoph: this is probably not the last patch.
> But it has a more accurate description of the problem.
> I still do not know what change to the kernel made
> it start triggering this, whether in the DMA API or
> in DRM :(
Doing some research, it seems the warning was added in v4.16-rc1, and
it is only a warning - it doesn't otherwise change the behaviour, so
it's not the actual warning that's the problem.
I can't see anything in the DMA API nor DRM which would cause this
either, but there are changes in the DT code.
However, there are changes to of_dma_configure() which will be called
just before the driver's probe function is called - and I guess the
culpret is 4d8bde883bfb ("OF: Don't set default coherent DMA mask").
So I guess that's the root cause of the problem, and indeed this
change was made in 4.19-rc1.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 13.8Mbps down 630kbps up
According to speedtest.net: 13Mbps down 490kbps up
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 2/2] drm/panel: Add device_link from panel device to drm device
On 31.08.2018 10:56, Linus Walleij wrote: > On Thu, Aug 30, 2018 at 4:41 PM Andrzej Hajda wrote: >> [Me] >>> This happens because the connector struct device is the >>> same as the bridge struct device, I suppose. >> I guess it is rather because the code tries to make circular dependency: >> 1. panel depends on dsi-host because it is MIPI-DSI child device. >> 2. dsi-host probably depends on drm parent device (connector->dev->dev) >> - what drm driver do you use? > The driver is added in this patch, it's at this uncomfortable stage > where I have to make a big upfront design for a new DRM driver > and everything is shaky and unreviewed. > > So to get it out for proper review it needs to be working and to > get it working I need review :D DRM development catch 22. > > But here is the patch adding it all, in some in-flight state: > https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson.git/commit/?h=ux500-mcde > > Thanks a lot for these notes, I hope I can figure it out! > >> 3. drm parent dev depends on panel: this patch adds this dependency. >> >> If 2nd point is true it becomes circular dependency, but please verify it. > I tried to not make the DRM parent dev depend on the panel. > > AFAICT (1) is true, (2) is true but not (3). See code of drm_panel_attach after subject patch [1]: panel->link = device_link_add(connector->dev->dev, panel->dev, 0); It is quite clear that connector->dev->dev is 'drm_device parent device' so you have drm-parent depends on panel->dev. IMO this is incorrect dependency, and the cause of error, it is not drm_device parent who depends on the panel, but drm_device itself. [1]: https://elixir.bootlin.com/linux/v4.19-rc1/source/drivers/gpu/drm/drm_panel.c#L108 Regards Andrzej > > Yours, > Linus Walleij > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105333] [gallium-nine] missing geometry after commit ac: replace ac_build_kill with ac_build_kill_if_false
https://bugs.freedesktop.org/show_bug.cgi?id=105333 Timothy Arceri changed: What|Removed |Added Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org QA Contact|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org Component|Drivers/Gallium/radeonsi|Gallium/StateTracker/galliu ||mnine -- 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 93829] [Wine] Lockup with MotoGP 2
https://bugs.freedesktop.org/show_bug.cgi?id=93829 Timothy Arceri changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #2 from Timothy Arceri --- Is this issue fixed with a current version of Mesa/kernel? -- 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 105379] The Witcher: Enhanced Edition under Wine fails to launch
https://bugs.freedesktop.org/show_bug.cgi?id=105379 Timothy Arceri changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution|--- |FIXED --- Comment #5 from Timothy Arceri --- Yeah I suspect the following commit fixed it: commit 7083ac7290a0c37a45494437a45441112f3cc36c Author: Marek Olšák Date: Tue Apr 24 17:01:35 2018 -0400 util/u_queue: fix a deadlock in util_queue_finish Cc: 18.0 18.1 Reviewed-by: Nicolai Hähnle Feel free to reopen if you are still having problems. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 00/12] remove_conflicting_framebuffers() cleanup
Quoting Daniel Vetter (2018-08-31 10:04:39) > On Thu, Aug 30, 2018 at 11:00:01PM +0200, Michał Mirosław wrote: > > This series cleans up duplicated code for replacing firmware FB > > driver with proper DRI driver and adds handover support to > > Tegra driver. > > > > This is a sligtly updated version of a series sent on 24 Nov 2017. > > > > v2: > > - rebased on current drm-next > > - dropped staging/sm750fb changes > > - added kernel docs for DRM helpers > > > > Michał Mirosław (12): > > fbdev: show fbdev number for debugging > > fbdev: allow apertures == NULL in remove_conflicting_framebuffers() > > fbdev: add remove_conflicting_pci_framebuffers() > > drm/amdgpu: use simpler remove_conflicting_pci_framebuffers() > > drm/bochs: use simpler remove_conflicting_pci_framebuffers() > > drm/cirrus: use simpler remove_conflicting_pci_framebuffers() > > drm/mgag200: use simpler remove_conflicting_pci_framebuffers() > > drm/radeon: use simpler remove_conflicting_pci_framebuffers() > > drm/virtio: use simpler remove_conflicting_pci_framebuffers() > > drm/vc4: use simpler remove_conflicting_framebuffers(NULL) > > drm/sun4i: use simpler remove_conflicting_framebuffers(NULL) > > drm/tegra: kick out simplefb > > Looks very neat. A bit confused about the drm changes in the fbdev-titled > patches 1&3, but I guess we can merge as-is. Up to you whether you want to > split or not I'd say. Ahah, someone is looking at remove_conflicting_framebuffers(). May I interest you in a use-after-free? [ 378.423513] stack segment: [#1] PREEMPT SMP PTI [ 378.423530] CPU: 1 PID: 4338 Comm: pm_rpm Tainted: G U 4.19.0-rc1-CI-CI_DRM_4746+ #1 [ 378.423548] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./J4205-ITX, BIOS P1.10 09/29/2016 [ 378.423570] RIP: 0010:do_remove_conflicting_framebuffers+0x56/0x170 [ 378.423587] Code: 49 8b 45 00 48 85 c0 74 50 f6 40 0a 08 74 4a 4d 85 e4 48 8b a8 78 04 00 00 74 1f 48 85 ed 74 1a 41 8b 0c 24 31 db 85 c9 74 10 <8b> 55 00 85 d2 75 42 83 c3 01 41 39 1c 24 77 f0 48 85 ed 74 1a 45 [ 378.423620] RSP: 0018:c91dfa88 EFLAGS: 00010202 [ 378.423632] RAX: 880274470008 RBX: RCX: 0001 [ 378.423646] RDX: 0001 RSI: a025c634 RDI: 88025cc3b428 [ 378.423660] RBP: 6b6b6b6b6b6b6b6b R08: 1edaddfa R09: a025c634 [ 378.423673] R10: c91dfae8 R11: 820de938 R12: 88025cc3b428 [ 378.423687] R13: 8234ca20 R14: 8234cb20 R15: 0001 [ 378.423701] FS: 7fcf03d0a980() GS:880277e8() knlGS: [ 378.423717] CS: 0010 DS: ES: CR0: 80050033 [ 378.423729] CR2: 7fffece1fdb8 CR3: 0001fe32e000 CR4: 003406e0 [ 378.423742] Call Trace: [ 378.423756] remove_conflicting_framebuffers+0x28/0x40 [ 378.423856] i915_driver_load+0x7f5/0x10c0 [i915] [ 378.423873] ? _raw_spin_unlock_irqrestore+0x4c/0x60 [ 378.423887] ? lockdep_hardirqs_on+0xe0/0x1b0 [ 378.423962] i915_pci_probe+0x29/0xa0 [i915] [ 378.423977] pci_device_probe+0xa1/0x130 [ 378.423990] really_probe+0x25d/0x3c0 [ 378.424002] driver_probe_device+0x10a/0x120 [ 378.424013] __driver_attach+0xdb/0x100 [ 378.424025] ? driver_probe_device+0x120/0x120 [ 378.424037] bus_for_each_dev+0x74/0xc0 [ 378.424048] bus_add_driver+0x15f/0x250 [ 378.424060] ? 0xa069d000 [ 378.424070] driver_register+0x56/0xe0 [ 378.424080] ? 0xa069d000 [ 378.424090] do_one_initcall+0x58/0x2e0 [ 378.424101] ? rcu_lockdep_current_cpu_online+0x8f/0xd0 [ 378.424116] ? do_init_module+0x1d/0x1ea [ 378.424127] ? rcu_read_lock_sched_held+0x6f/0x80 [ 378.424141] ? kmem_cache_alloc_trace+0x264/0x290 [ 378.424154] do_init_module+0x56/0x1ea [ 378.424167] load_module+0x26ba/0x29a0 [ 378.424182] ? vfs_read+0x122/0x140 [ 378.424199] ? __se_sys_finit_module+0xd3/0xf0 [ 378.424210] __se_sys_finit_module+0xd3/0xf0 [ 378.424226] do_syscall_64+0x55/0x190 [ 378.424237] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 378.424249] RIP: 0033:0x7fcf02f9b839 [ 378.424258] Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 1f f6 2c 00 f7 d8 64 89 01 48 [ 378.424290] RSP: 002b:7fffece21f58 EFLAGS: 0246 ORIG_RAX: 0139 [ 378.424307] RAX: ffda RBX: 56344e1a4d80 RCX: 7fcf02f9b839 [ 378.424321] RDX: RSI: 7fcf026470e5 RDI: 0003 [ 378.424336] RBP: 7fcf026470e5 R08: R09: [ 378.424349] R10: 0003 R11: 0246 R12: [ 378.424363] R13: 56344e1a R14: R15: 56344e1a4d80 https://intel-gfx-ci.01.org/tree/drm-tip/IGT_4613/fi-bxt-j4205/dmesg0.log -Chris ___ dri-devel mailing list
[Bug 105733] Amdgpu randomly hangs and only ssh works. Mouse cursor moves sometimes but does nothing. Keyboard stops working.
https://bugs.freedesktop.org/show_bug.cgi?id=105733 --- Comment #35 from markusr...@gmail.com --- It might be that kernel option apci=ht ( also apci=off ) solve the problem. It is taking more time to waiting the possible problem appearance. At least it worth of testing. But this is not maybe the final solution for this bug? [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.18.5-041805-generic root=UUID=c3df607f-ac6e-11e8-9f6b-3497f638e103 ro acpi=ht [0.00] Malformed early option 'acpi' -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 00/12] remove_conflicting_framebuffers() cleanup
On Thu, Aug 30, 2018 at 11:00:01PM +0200, Michał Mirosław wrote: > This series cleans up duplicated code for replacing firmware FB > driver with proper DRI driver and adds handover support to > Tegra driver. > > This is a sligtly updated version of a series sent on 24 Nov 2017. > > v2: > - rebased on current drm-next > - dropped staging/sm750fb changes > - added kernel docs for DRM helpers > > Michał Mirosław (12): > fbdev: show fbdev number for debugging > fbdev: allow apertures == NULL in remove_conflicting_framebuffers() > fbdev: add remove_conflicting_pci_framebuffers() > drm/amdgpu: use simpler remove_conflicting_pci_framebuffers() > drm/bochs: use simpler remove_conflicting_pci_framebuffers() > drm/cirrus: use simpler remove_conflicting_pci_framebuffers() > drm/mgag200: use simpler remove_conflicting_pci_framebuffers() > drm/radeon: use simpler remove_conflicting_pci_framebuffers() > drm/virtio: use simpler remove_conflicting_pci_framebuffers() > drm/vc4: use simpler remove_conflicting_framebuffers(NULL) > drm/sun4i: use simpler remove_conflicting_framebuffers(NULL) > drm/tegra: kick out simplefb Looks very neat. A bit confused about the drm changes in the fbdev-titled patches 1&3, but I guess we can merge as-is. Up to you whether you want to split or not I'd say. Bartlomiej, ack for pullin in this entire pile through drm-misc? Thanks, Daniel > > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 24 +- > drivers/gpu/drm/bochs/bochs_drv.c| 18 +-- > drivers/gpu/drm/cirrus/cirrus_drv.c | 23 +- > drivers/gpu/drm/mgag200/mgag200_drv.c| 21 + > drivers/gpu/drm/mgag200/mgag200_main.c | 9 -- > drivers/gpu/drm/radeon/radeon_drv.c | 23 +- > drivers/gpu/drm/sun4i/sun4i_drv.c| 18 +-- > drivers/gpu/drm/tegra/drm.c | 4 +++ > drivers/gpu/drm/vc4/vc4_drv.c| 20 +--- > drivers/gpu/drm/virtio/virtgpu_drm_bus.c | 24 ++ > drivers/video/fbdev/core/fbmem.c | 40 ++-- > include/drm/drm_fb_helper.h | 34 > include/linux/fb.h | 2 ++ > 13 files changed, 88 insertions(+), 172 deletions(-) > > -- > 2.18.0 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 02/12] fbdev: allow apertures == NULL in remove_conflicting_framebuffers()
On Fri, Aug 31, 2018 at 10:56:56AM +0200, Daniel Vetter wrote:
> On Thu, Aug 30, 2018 at 11:00:05PM +0200, Michał Mirosław wrote:
> > Interpret (otherwise-invalid) NULL apertures argument to mean all-memory
> > range. This will allow to remove several duplicates of this code from
> > drivers in following patches.
> >
> > Signed-off-by: Michał Mirosław
> > [for v1]
> > Acked-by: Bartlomiej Zolnierkiewicz
> >
> > ---
> > v2: added kerneldoc to corresponding DRM helper
> > ---
> > drivers/video/fbdev/core/fbmem.c | 14 ++
> > include/drm/drm_fb_helper.h | 10 ++
> > 2 files changed, 24 insertions(+)
> >
> > diff --git a/drivers/video/fbdev/core/fbmem.c
> > b/drivers/video/fbdev/core/fbmem.c
> > index 30a18d4c9de4..0df148eb4699 100644
> > --- a/drivers/video/fbdev/core/fbmem.c
> > +++ b/drivers/video/fbdev/core/fbmem.c
> > @@ -1779,11 +1779,25 @@ int remove_conflicting_framebuffers(struct
> > apertures_struct *a,
> > const char *name, bool primary)
> > {
> > int ret;
> > + bool do_free = false;
> > +
> > + if (!a) {
> > + a = alloc_apertures(1);
> > + if (!a)
> > + return -ENOMEM;
> > +
> > + a->ranges[0].base = 0;
> > + a->ranges[0].size = ~0;
> > + do_free = true;
> > + }
> >
> > mutex_lock(_lock);
> > ret = do_remove_conflicting_framebuffers(a, name, primary);
> > mutex_unlock(_lock);
> >
> > + if (do_free)
> > + kfree(a);
> > +
> > return ret;
> > }
> > EXPORT_SYMBOL(remove_conflicting_framebuffers);
> > diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> > index b069433e7fc1..1c1e53abb25d 100644
> > --- a/include/drm/drm_fb_helper.h
> > +++ b/include/drm/drm_fb_helper.h
> > @@ -566,6 +566,16 @@ static inline void
> > drm_fb_helper_output_poll_changed(struct drm_device *dev)
> >
> > #endif
> >
> > +/**
> > + * drm_fb_helper_remove_conflicting_framebuffers - remove firmware
> > framebuffers
> > + * @a: memory range, users of which are to be removed
> > + * @name: requesting driver name
> > + * @primary: also kick vga16fb if present
> > + *
> > + * This function removes framebuffer devices (eg. initialized by firmware)
> > + * which use memory range described by @a. If @a is NULL all such devices
> > are
> > + * removed.
> > + */
>
> This looks like misplaced copypasta. You only need this once I think.
Ah no, just a fixup for the lack of kerneldoc we have. Can you pls split
this out into a separate patch?
Thanks, Daniel
> -Daniel
>
> > static inline int
> > drm_fb_helper_remove_conflicting_framebuffers(struct apertures_struct *a,
> > const char *name, bool primary)
> > --
> > 2.18.0
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 02/12] fbdev: allow apertures == NULL in remove_conflicting_framebuffers()
On Thu, Aug 30, 2018 at 11:00:05PM +0200, Michał Mirosław wrote:
> Interpret (otherwise-invalid) NULL apertures argument to mean all-memory
> range. This will allow to remove several duplicates of this code from
> drivers in following patches.
>
> Signed-off-by: Michał Mirosław
> [for v1]
> Acked-by: Bartlomiej Zolnierkiewicz
>
> ---
> v2: added kerneldoc to corresponding DRM helper
> ---
> drivers/video/fbdev/core/fbmem.c | 14 ++
> include/drm/drm_fb_helper.h | 10 ++
> 2 files changed, 24 insertions(+)
>
> diff --git a/drivers/video/fbdev/core/fbmem.c
> b/drivers/video/fbdev/core/fbmem.c
> index 30a18d4c9de4..0df148eb4699 100644
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -1779,11 +1779,25 @@ int remove_conflicting_framebuffers(struct
> apertures_struct *a,
> const char *name, bool primary)
> {
> int ret;
> + bool do_free = false;
> +
> + if (!a) {
> + a = alloc_apertures(1);
> + if (!a)
> + return -ENOMEM;
> +
> + a->ranges[0].base = 0;
> + a->ranges[0].size = ~0;
> + do_free = true;
> + }
>
> mutex_lock(_lock);
> ret = do_remove_conflicting_framebuffers(a, name, primary);
> mutex_unlock(_lock);
>
> + if (do_free)
> + kfree(a);
> +
> return ret;
> }
> EXPORT_SYMBOL(remove_conflicting_framebuffers);
> diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> index b069433e7fc1..1c1e53abb25d 100644
> --- a/include/drm/drm_fb_helper.h
> +++ b/include/drm/drm_fb_helper.h
> @@ -566,6 +566,16 @@ static inline void
> drm_fb_helper_output_poll_changed(struct drm_device *dev)
>
> #endif
>
> +/**
> + * drm_fb_helper_remove_conflicting_framebuffers - remove firmware
> framebuffers
> + * @a: memory range, users of which are to be removed
> + * @name: requesting driver name
> + * @primary: also kick vga16fb if present
> + *
> + * This function removes framebuffer devices (eg. initialized by firmware)
> + * which use memory range described by @a. If @a is NULL all such devices are
> + * removed.
> + */
This looks like misplaced copypasta. You only need this once I think.
-Daniel
> static inline int
> drm_fb_helper_remove_conflicting_framebuffers(struct apertures_struct *a,
> const char *name, bool primary)
> --
> 2.18.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 2/2] drm/panel: Add device_link from panel device to drm device
On Thu, Aug 30, 2018 at 4:41 PM Andrzej Hajda wrote: > [Me] > > This happens because the connector struct device is the > > same as the bridge struct device, I suppose. > > I guess it is rather because the code tries to make circular dependency: > 1. panel depends on dsi-host because it is MIPI-DSI child device. > 2. dsi-host probably depends on drm parent device (connector->dev->dev) > - what drm driver do you use? The driver is added in this patch, it's at this uncomfortable stage where I have to make a big upfront design for a new DRM driver and everything is shaky and unreviewed. So to get it out for proper review it needs to be working and to get it working I need review :D DRM development catch 22. But here is the patch adding it all, in some in-flight state: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson.git/commit/?h=ux500-mcde Thanks a lot for these notes, I hope I can figure it out! > 3. drm parent dev depends on panel: this patch adds this dependency. > > If 2nd point is true it becomes circular dependency, but please verify it. I tried to not make the DRM parent dev depend on the panel. AFAICT (1) is true, (2) is true but not (3). Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] drm/debugfs: Add support for dynamic debugfs initialization
On Mon, Aug 27, 2018 at 08:36:24PM -0400, Lyude Paul wrote:
> Currently all debugfs related initialization for the DRM core happens in
> drm_debugfs_init(), which is called when registering the minor device.
> While this works fine for features such as atomic modesetting and GEM,
> this doesn't work at all for resources like DP MST topology managers
> which can potentially be created both before and after the minor
> device has been registered.
>
> So, in order to add driver-wide debugfs files for MST we'll need to be
> able to handle debugfs initialization for such resources. We do so by
> introducing drm_debugfs_callback_register() and
> drm_debugfs_callback_unregister(). These functions allow driver-agnostic
> parts of DRM to add additional debugfs initialization callbacks at any
> point during a DRM driver's lifetime.
>
> Signed-off-by: Lyude Paul
> Cc: Maarten Lankhorst
> Cc: Daniel Stone
So the debugfs lifetime rules are indeed silly and broken. I'm not sure
this is what we want to do though:
- Thanks to Noralf's cleanup you don't need a debugfs cleanup callback
anymore really, it will auto-clean-up on device unregistration.
- For stuff tied to connectors we have the connector->register/unregister
callbacks. Imo connector-related debugfs stuff, like for mst, should be
put there.
- debugfs_init is a dead idea, as you point out it's fundamentally racy.
- Dropping the silly notion that we have to duplicate all debugfs entries
per-minor would be really sweet (last time I checked there's not a
single debugfs file that's actually different per minor).
Cheers, Daniel
> ---
> drivers/gpu/drm/drm_debugfs.c | 173 +++--
> drivers/gpu/drm/drm_drv.c | 3 +
> drivers/gpu/drm/drm_internal.h | 5 +
> include/drm/drm_debugfs.h | 27 +
> include/drm/drm_file.h | 4 +
> 5 files changed, 203 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
> index 6f28fe58f169..a53a454b167f 100644
> --- a/drivers/gpu/drm/drm_debugfs.c
> +++ b/drivers/gpu/drm/drm_debugfs.c
> @@ -39,6 +39,13 @@
>
> #if defined(CONFIG_DEBUG_FS)
>
> +struct drm_debugfs_callback {
> + void (*init)(void *data);
> + void (*cleanup_cb)(void *data);
> + void *data;
> + struct list_head list;
> +};
> +
> /***
> * Initialization, etc.
> **/
> @@ -67,6 +74,113 @@ static const struct file_operations drm_debugfs_fops = {
> .release = single_release,
> };
>
> +/**
> + * drm_debugfs_register_callback - Register a callback for initializing
> + * dynamic driver-agnostic debugfs files
> + * @minor: device minor number
> + * @init: The callback to invoke to perform the debugfs initialization
> + * @cleanup_cb: The callback to invoke to cleanup any resources for the
> + * callback
> + * @data: Data to pass to @init and @cleanup_cb
> + * @out: Where to store the pointer to the callback struct
> + *
> + * Register an initialization callback with debugfs. This callback can be
> used
> + * to creating debugfs nodes for DRM resources that might get created before
> + * the debugfs node for @minor has been created.
> + *
> + * When a callback is registered with this function before the debugfs root
> + * has been created, the callback's execution will be delayed until all other
> + * debugfs nodes (including those owned by the DRM device's driver) have been
> + * instantiated. If a callback is registered with this function after the
> + * debugfs root has been created, @init and @cleanup_cb will be executed
> + * immediately without creating a drm_debugfs_callback.
> + *
> + * In the event that debugfs creation for the device fails; all registered
> + * debugfs callbacks will have their @cleanup_cb callbacks invoked without
> + * having their @init callbacks invoked. This is to ensure that no resources
> + * are leaked during initialization of debugfs, even if the initialization
> + * process fails. Likewise; any callbacks that are registered after DRM has
> + * failed to initialize it's debugfs files will have their @cleanup_cb
> + * callbacks invoked immediately and all of their respective resources
> + * destroyed.
> + *
> + * Implementations of @cleanup_cb should clean up all resources for the
> + * callback, with the exception of freeing the memory for @out. Freeing @out
> + * will be handled by the DRM core automatically.
> + *
> + * Users of this function should take care to add a symmetric call to
> + * @drm_debugfs_unregister_callback to handle destroying a registered
> callback
> + * in case the resources for the user of this function are destroyed before
> + * debugfs root is initialized.
> + *
> + */
> +int
> +drm_debugfs_register_callback(struct drm_minor *minor,
> + void (*init)(void *),
> + void
Re: [PATCH v7] Add udmabuf misc device
On Mon, Aug 27, 2018 at 11:34:44AM +0200, Gerd Hoffmann wrote:
> A driver to let userspace turn memfd regions into dma-bufs.
>
> Use case: Allows qemu create dmabufs for the vga framebuffer or
> virtio-gpu ressources. Then they can be passed around to display
> those guest things on the host. To spice client for classic full
> framebuffer display, and hopefully some day to wayland server for
> seamless guest window display.
>
> qemu test branch:
> https://git.kraxel.org/cgit/qemu/log/?h=sirius/udmabuf
>
> Cc: David Airlie
> Cc: Tomeu Vizoso
> Cc: Laurent Pinchart
> Cc: Daniel Vetter
> Signed-off-by: Gerd Hoffmann
> ---
> Documentation/ioctl/ioctl-number.txt | 1 +
> include/uapi/linux/udmabuf.h | 33 +++
> drivers/dma-buf/udmabuf.c | 287
> ++
> tools/testing/selftests/drivers/dma-buf/udmabuf.c | 96
> MAINTAINERS | 16 ++
> drivers/dma-buf/Kconfig | 8 +
> drivers/dma-buf/Makefile | 1 +
> tools/testing/selftests/drivers/dma-buf/Makefile | 5 +
> 8 files changed, 447 insertions(+)
> create mode 100644 include/uapi/linux/udmabuf.h
> create mode 100644 drivers/dma-buf/udmabuf.c
> create mode 100644 tools/testing/selftests/drivers/dma-buf/udmabuf.c
> create mode 100644 tools/testing/selftests/drivers/dma-buf/Makefile
>
> diff --git a/Documentation/ioctl/ioctl-number.txt
> b/Documentation/ioctl/ioctl-number.txt
> index 13a7c999c0..f2ac672eb7 100644
> --- a/Documentation/ioctl/ioctl-number.txt
> +++ b/Documentation/ioctl/ioctl-number.txt
> @@ -272,6 +272,7 @@ Code Seq#(hex) Include FileComments
> 't' 90-91 linux/toshiba.h toshiba and toshiba_acpi SMM
> 'u' 00-1F linux/smb_fs.h gone
> 'u' 20-3F linux/uvcvideo.hUSB video class host driver
> +'u' 40-4f linux/udmabuf.h userspace dma-buf misc device
> 'v' 00-1F linux/ext2_fs.h conflict!
> 'v' 00-1F linux/fs.h conflict!
> 'v' 00-0F linux/sonypi.h conflict!
> diff --git a/include/uapi/linux/udmabuf.h b/include/uapi/linux/udmabuf.h
> new file mode 100644
> index 00..46b6532ed8
> --- /dev/null
> +++ b/include/uapi/linux/udmabuf.h
> @@ -0,0 +1,33 @@
> +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
> +#ifndef _UAPI_LINUX_UDMABUF_H
> +#define _UAPI_LINUX_UDMABUF_H
> +
> +#include
> +#include
> +
> +#define UDMABUF_FLAGS_CLOEXEC0x01
> +
> +struct udmabuf_create {
> + __u32 memfd;
> + __u32 flags;
> + __u64 offset;
> + __u64 size;
> +};
> +
> +struct udmabuf_create_item {
> + __u32 memfd;
> + __u32 __pad;
> + __u64 offset;
> + __u64 size;
> +};
> +
> +struct udmabuf_create_list {
> + __u32 flags;
> + __u32 count;
> + struct udmabuf_create_item list[];
> +};
> +
> +#define UDMABUF_CREATE _IOW('u', 0x42, struct udmabuf_create)
> +#define UDMABUF_CREATE_LIST _IOW('u', 0x43, struct udmabuf_create_list)
> +
> +#endif /* _UAPI_LINUX_UDMABUF_H */
> diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
> new file mode 100644
> index 00..8e24204526
> --- /dev/null
> +++ b/drivers/dma-buf/udmabuf.c
> @@ -0,0 +1,287 @@
> +// SPDX-License-Identifier: GPL-2.0
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +struct udmabuf {
> + u32 pagecount;
> + struct page **pages;
> +};
> +
> +static int udmabuf_vm_fault(struct vm_fault *vmf)
> +{
> + struct vm_area_struct *vma = vmf->vma;
> + struct udmabuf *ubuf = vma->vm_private_data;
> +
> + if (WARN_ON(vmf->pgoff >= ubuf->pagecount))
> + return VM_FAULT_SIGBUS;
> +
> + vmf->page = ubuf->pages[vmf->pgoff];
> + get_page(vmf->page);
> + return 0;
> +}
> +
> +static const struct vm_operations_struct udmabuf_vm_ops = {
> + .fault = udmabuf_vm_fault,
> +};
> +
> +static int mmap_udmabuf(struct dma_buf *buf, struct vm_area_struct *vma)
> +{
> + struct udmabuf *ubuf = buf->priv;
> +
> + if ((vma->vm_flags & (VM_SHARED | VM_MAYSHARE)) == 0)
> + return -EINVAL;
> +
> + vma->vm_ops = _vm_ops;
> + vma->vm_private_data = ubuf;
> + return 0;
> +}
> +
> +static struct sg_table *map_udmabuf(struct dma_buf_attachment *at,
> + enum dma_data_direction direction)
> +{
> + struct udmabuf *ubuf = at->dmabuf->priv;
> + struct sg_table *sg;
> +
> + sg = kzalloc(sizeof(*sg), GFP_KERNEL);
> + if (!sg)
> + goto err1;
> + if (sg_alloc_table_from_pages(sg, ubuf->pages, ubuf->pagecount,
> + 0, ubuf->pagecount << PAGE_SHIFT,
> + GFP_KERNEL) < 0)
> + goto err2;
> + if (!dma_map_sg(at->dev, sg->sgl, sg->nents, direction))
>
Re: [PATCH] drm/vkms: Fix race condition around accessing frame number
On Fri, Aug 24, 2018 at 02:16:34AM +0300, Haneen Mohammed wrote:
> crtc_state is accessed by both vblank_handle() and the ordered
> work_struct handle vkms_crc_work_handle() to retrieve and or update
> the frame number for computed CRC.
>
> Since work_struct can fail, add frame_end to account for missing frame
> numbers.
>
> use atomic_t witth appropriate flags for synchronization between hrtimer
> callback and ordered work_struct handle since spinlock can't be used
> with work_struct handle and mutex can't be used with hrtimer callback.
>
> This patch passes the following subtests from igt kms_pipe_crc_basic test:
> bad-source, read-crc-pipe-A, read-crc-pipe-A-frame-sequence,
> nonblocking-crc-pipe-A, nonblocking-crc-pipe-A-frame-sequence
>
> Signed-off-by: Haneen Mohammed
So atomic_t is probably the greatest trap in the linux kernel. It sounds
like the right thing, but in 99% of all case you want to use it it isn't.
The trouble is that atomic_t is _very_ unordered, the only thing it
guarantees is that atomic_t transactions to the _same_ variable are
consistent. But anything else can be reordered at will.
This is very confusing since the new C++ atomic standards has fully
ordered atomics as the default, and you expressedly need to ask for the
weakly ordered ones. In linux you need to sprinkle epic amounts of
smb_barrier* and similar things around them to make atomic_t behave like a
"normal" C++ atomic type.
tldr; atomic_t is good for special refcounting needs, when the normal
refcount_t doesn't cut it. Not much else.
What usually should be done:
- Use normal u64 (to match the vblank counter size) instead of atomic_t
here.
- Make sure all access is protect by an appropriate spinlock.
> ---
> drivers/gpu/drm/vkms/vkms_crc.c | 33 ++--
> drivers/gpu/drm/vkms/vkms_crtc.c | 13 +++--
> drivers/gpu/drm/vkms/vkms_drv.h | 6 --
> 3 files changed, 46 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/vkms/vkms_crc.c b/drivers/gpu/drm/vkms/vkms_crc.c
> index ed47d67cecd6..4a1ba5b7886a 100644
> --- a/drivers/gpu/drm/vkms/vkms_crc.c
> +++ b/drivers/gpu/drm/vkms/vkms_crc.c
> @@ -34,6 +34,15 @@ static uint32_t _vkms_get_crc(struct vkms_crc_data
> *crc_data)
> return crc;
> }
>
> +/**
> + * vkms_crc_work_handle - ordered work_struct to compute CRC
> + *
> + * @work: work_struct
> + *
> + * Work handler for computing CRCs. work_struct scheduled in
> + * an ordered workqueue that's periodically scheduled to run by
> + * _vblank_handle() and flushed at vkms_atomic_crtc_destroy_state().
> + */
> void vkms_crc_work_handle(struct work_struct *work)
> {
> struct vkms_crtc_state *crtc_state = container_of(work,
> @@ -45,8 +54,18 @@ void vkms_crc_work_handle(struct work_struct *work)
> output);
> struct vkms_crc_data *primary_crc = NULL;
> struct drm_plane *plane;
> -
> u32 crc32 = 0;
> + u32 frame_start, frame_end;
> +
> + frame_start = atomic_read(_state->frame_start);
> + frame_end = atomic_read(_state->frame_end);
> + /* _vblank_handle() hasn't updated frame_start yet */
> + if (!frame_start) {
I think if we go with u64 we can ignore the issues for wrap-arround, since
that will simply never happen. But a comment would be good.
Aside from the atomic_t issue I think this looks good.
-Daniel
> + return;
> + } else if (frame_start == frame_end) {
> + atomic_set(_state->frame_start, 0);
> + return;
> + }
>
> drm_for_each_plane(plane, >drm) {
> struct vkms_plane_state *vplane_state;
> @@ -67,7 +86,17 @@ void vkms_crc_work_handle(struct work_struct *work)
> if (primary_crc)
> crc32 = _vkms_get_crc(primary_crc);
>
> - drm_crtc_add_crc_entry(crtc, true, crtc_state->n_frame, );
> + frame_end = drm_crtc_accurate_vblank_count(crtc);
> +
> + /* queue_work can fail to schedule crc_work; add crc for
> + * missing frames
> + */
> + while (frame_start <= frame_end)
> + drm_crtc_add_crc_entry(crtc, true, frame_start++, );
> +
> + /* to avoid using the same value again */
> + atomic_set(_state->frame_end, frame_end);
> + atomic_set(_state->frame_start, 0);
> }
>
> static int vkms_crc_parse_source(const char *src_name, bool *enabled)
> diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c
> b/drivers/gpu/drm/vkms/vkms_crtc.c
> index 9d0b1a325a78..a170677acd46 100644
> --- a/drivers/gpu/drm/vkms/vkms_crtc.c
> +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
> @@ -22,8 +22,17 @@ static void _vblank_handle(struct vkms_output *output)
> DRM_ERROR("vkms failure on handling vblank");
>
> if (state && output->crc_enabled) {
> - state->n_frame = drm_crtc_accurate_vblank_count(crtc);
> - queue_work(output->crc_workq, >crc_work);
> + u32 frame = drm_crtc_accurate_vblank_count(crtc);
> +
> +
[Bug 105379] The Witcher: Enhanced Edition under Wine fails to launch
https://bugs.freedesktop.org/show_bug.cgi?id=105379 Timothy Arceri changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #4 from Timothy Arceri --- The game launches fine for me with mesa from git are you still having issues? -- 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 (repost) 5/5] drm/amdgpu: add DisplayPort CEC-Tunneling-over-AUX support
On 08/24/2018 04:59 PM, Alex Deucher wrote:
> On Fri, Aug 24, 2018 at 3:20 AM Hans Verkuil wrote:
>>
>> On 08/23/2018 08:38 PM, Harry Wentland wrote:
>>> On 2018-08-17 10:11 AM, Hans Verkuil wrote:
From: Hans Verkuil
Add DisplayPort CEC-Tunneling-over-AUX support to amdgpu.
Signed-off-by: Hans Verkuil
Acked-by: Alex Deucher
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 13 +++--
.../drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 2 ++
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 34f34823bab5..77898c95bef6 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -898,6 +898,7 @@ amdgpu_dm_update_connector_after_detect(struct
amdgpu_dm_connector *aconnector)
aconnector->dc_sink = sink;
if (sink->dc_edid.length == 0) {
aconnector->edid = NULL;
+drm_dp_cec_unset_edid(>dm_dp_aux.aux);
} else {
aconnector->edid =
(struct edid *) sink->dc_edid.raw_edid;
@@ -905,10 +906,13 @@ amdgpu_dm_update_connector_after_detect(struct
amdgpu_dm_connector *aconnector)
drm_connector_update_edid_property(connector,
aconnector->edid);
+drm_dp_cec_set_edid(>dm_dp_aux.aux,
+aconnector->edid);
}
amdgpu_dm_add_sink_to_freesync_module(connector,
aconnector->edid);
} else {
+drm_dp_cec_unset_edid(>dm_dp_aux.aux);
amdgpu_dm_remove_sink_from_freesync_module(connector);
drm_connector_update_edid_property(connector, NULL);
aconnector->num_modes = 0;
@@ -1059,12 +1063,16 @@ static void handle_hpd_rx_irq(void *param)
drm_kms_helper_hotplug_event(dev);
}
}
+
if ((dc_link->cur_link_settings.lane_count != LANE_COUNT_UNKNOWN) ||
-(dc_link->type == dc_connection_mst_branch))
+(dc_link->type == dc_connection_mst_branch)) {
dm_handle_hpd_rx_irq(aconnector);
+}
>>>
>>> These lines don't really add anything functional.
>>
>> Oops, a left-over from debugging code. I'll remove this 'change' and post a
>> v2
>> with all the Acks/reviewed-bys.
>>
>> Any idea who would typically merge a patch series like this?
>
> I (or anyone else with drm-misc rights) can push them for you, however
> drm-misc is a committer tree so if you'd like access to apply patches
> yourself, you could do that too. Request access here:
> https://www.freedesktop.org/wiki/AccountRequests/
OK, I pushed this series to drm-next. It's the first time I'm using dim &
drm-misc
so let me know if I did anything silly.
Regards,
Hans
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] of/platform: initialise AMBA default DMA masks
This addresses a v4.19-rc1 regression in the PL111 DRM driver
in drivers/gpu/pl111/*
The driver uses the CMA KMS helpers and will thus at some
point call down to dma_alloc_attrs() to allocate a chunk
of contigous DMA memory for the framebuffer.
It appears that in v4.18, it was OK that this (and other
DMA mastering AMBA devices) left dev->coherent_dma_mask
blank (zero).
In v4.19-rc1 the WARN_ON_ONCE(dev && !dev->coherent_dma_mask)
in dma_alloc_attrs() in include/linux/dma-mapping.h is
triggered. The allocation later fails when get_coherent_dma_mask()
is called from __dma_alloc() and __dma_alloc() returns
NULL:
drm-clcd-pl111 dev:20: coherent DMA mask is unset
drm-clcd-pl111 dev:20: [drm:drm_fb_helper_fbdev_setup] *ERROR*
Failed to set fbdev configuration
I have not been able to properly bisect down to the actual
committ causing it beacuse the kernel simply fails to build
at to many bisection points, pushing the bisect back to places
like the merge of entire subsystem trees, where things have
likely been resolved while merging them.
I found that Robin Murphy solved a similar problem in
a5516219b102 ("of/platform: Initialise default DMA masks")
by simply assigning dev.coherent_dma_mask and the
dev.dma_mask to point to the same when creating devices
from the device tree, and introducing the same code into
the code path creating AMBA/PrimeCell devices solved my
problem, graphics now come up.
The code simply assumes that the device can access all
of the system memory by setting the coherent DMA mask
to 0x when creating a device from the device
tree, which is crude, but seems to be what kernel v4.18
assumed.
Cc: Russell King
Cc: Christoph Hellwig
Cc: Robin Murphy
Signed-off-by: Linus Walleij
---
Russell, Christoph: this is probably not the last patch.
But it has a more accurate description of the problem.
I still do not know what change to the kernel made
it start triggering this, whether in the DMA API or
in DRM :(
I am looking into Russell's suggestion to use the DMA
ranges, and thusly patch all device trees with DMA
mastering devices adding DMA ranges to them and parsing
that in the device tree AMBA/PrimeCell population code.
Possibly that is the right path forward.
---
drivers/of/platform.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 7ba90c290a42..6c59673933e9 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -241,6 +241,10 @@ static struct amba_device *of_amba_device_create(struct
device_node *node,
if (!dev)
goto err_clear_flag;
+ /* AMBA devices only support a single DMA mask */
+ dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
+ dev->dev.dma_mask = >dev.coherent_dma_mask;
+
/* setup generic device info */
dev->dev.of_node = of_node_get(node);
dev->dev.fwnode = >fwnode;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm v2 4/5] intel: make gen9 use generic gen macro
Quoting Lucas De Marchi (2018-08-29 01:35:31)
> The 2 PCI IDs that are used for the command line overrid mechanism
> were left defined. The rest can be gone and then we just use the kernel
> defines.
>
> Signed-off-by: Lucas De Marchi
> ---
> intel/intel_chipset.c | 5 ++
> intel/intel_chipset.h | 187 +-
> 2 files changed, 6 insertions(+), 186 deletions(-)
>
> diff --git a/intel/intel_chipset.c b/intel/intel_chipset.c
> index 0c2ba884..c984d8ac 100644
> --- a/intel/intel_chipset.c
> +++ b/intel/intel_chipset.c
> @@ -36,6 +36,11 @@ static const struct pci_device {
> } pciids[] = {
> INTEL_ICL_11_IDS(11),
> INTEL_CNL_IDS(10),
> + INTEL_CFL_IDS(9),
> + INTEL_GLK_IDS(9),
> + INTEL_KBL_IDS(9),
> + INTEL_BXT_IDS(9),
> + INTEL_SKL_IDS(9),
The gradual conversion lgtm. But why stop here? :)
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [ANNOUNCE] libdrm 2.4.94
On Fri, Aug 24, 2018 at 06:37:35PM +0200, Michel Dänzer wrote: > On 2018-08-24 6:27 p.m., Kristian Høgsberg wrote: > > > > I don't know what all is pending for libdrm, but I know that we've > > agreed on a very low bar for when to release libdrm: > > > >"The release criteria for libdrm is essentially "if you need a release, > > make one". There is no designated release engineer or maintainer. > > Anybody is free to make a release if there's a certain feature or bug > > fix they need in a released version of libdrm." > > First of all, let me assure you that I'm not picking on you in > particular, this applies to anybody who makes a release. > > Quite frankly, that sucks. :) A brief "heads up, I'm cutting a libdrm > release, let me know if there's something you want in it" e-mail at > least 24 hours (not counting weekend days) before making the release > shouldn't be asking too much. Given that making a libdrm release is pretty much for free I'm not sure about the concern. We've had plenty of back-to-back libdrm releases. Since libdrm is supposed to be always in release state (it's mostly just headers and simple wrappers) I don't see a downside aside from "looks mildly silly" :-) If we'd have a libdrm release maintainer that'd be different, but no one volunteered (and for years) so that's unlikely to change. -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 libdrm v2 4/5] intel: make gen9 use generic gen macro
Quoting Lucas De Marchi (2018-08-29 17:01:11) > On Wed, Aug 29, 2018 at 11:32:35AM +0100, Chris Wilson wrote: > > Quoting Lucas De Marchi (2018-08-29 01:35:31) > > > The 2 PCI IDs that are used for the command line overrid mechanism > > > were left defined. > > > > What makes them so special? Why not just match on the override devid? > > because it's a name -> id mapping? It maps a short string like "skl" to > a single specific PCI ID... how useful is that and if we should retain > its behavior, I have dunno. But > i915_pciids.h doesn't have defines for individual PCI IDs, but groups of > them. My bad, I've always used pci-id overrides as a pci-id! > I would either have to create an accessor/iter for gen x in > intel_chipset.c or do some macros to extract the first id from the > i915_pciids.h, just to get an ID that is set in stone and change the > current id used :-/ Having the i915_pciids.h contain the codename (and /rough/ marketing name) was pencilled in to my plans now that it no longer appears to be a freak out. Once we have configurable macros, the extra parameters just disappear when unwanted. -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v2 1/3] drm/fourcc: Add 'bpp' field for formats with non-integer bytes-per-pixel
On Thu, Aug 23, 2018 at 04:23:41PM +0100, Brian Starkey wrote:
> Some formats have a non-integer number of bytes per pixel, which can't
> be handled with the existing 'cpp' field in drm_format_info. To handle
> these formats, add a 'bpp' field, which is only used if cpp[0] == 0.
>
> This updates all the users of format->cpp in the core DRM code,
> converting them to use a new function to get the bits-per-pixel for any
> format.
>
> It's assumed that drivers will use the 'bpp' field when they add support
> for pixel formats with non-integer bytes-per-pixel.
>
> Signed-off-by: Brian Starkey
I assume you still require that stuff is eventually aligned to bytes? In
that case, can we subsume this into the tile work Alex is doing? It's
essentially just another special case of having storage-size units
measured in bytes which span more than 1x1 pixel. And I kinda don't want a
metric pile of special cases here in the format code, because that just
means every driver handles a different subset, with different bugs.
-Daniel
> ---
> drivers/gpu/drm/drm_fb_cma_helper.c | 6 +++-
> drivers/gpu/drm/drm_fb_helper.c | 8 +++--
> drivers/gpu/drm/drm_fourcc.c | 50
>
> drivers/gpu/drm/drm_framebuffer.c| 8 ++---
> drivers/gpu/drm/drm_gem_framebuffer_helper.c | 3 +-
> include/drm/drm_fourcc.h | 4 +++
> 6 files changed, 70 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
> b/drivers/gpu/drm/drm_fb_cma_helper.c
> index 186d00adfb5f..e279d70d3e60 100644
> --- a/drivers/gpu/drm/drm_fb_cma_helper.c
> +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
> @@ -118,13 +118,17 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct
> drm_framebuffer *fb,
> {
> struct drm_gem_cma_object *obj;
> dma_addr_t paddr;
> + u8 bpp = drm_format_info_plane_bpp(fb->format, plane);
> +
> + /* This can't work for non-integer bytes-per-pixel */
> + WARN_ON(bpp % 8);
>
> obj = drm_fb_cma_get_gem_obj(fb, plane);
> if (!obj)
> return 0;
>
> paddr = obj->paddr + fb->offsets[plane];
> - paddr += fb->format->cpp[plane] * (state->src_x >> 16);
> + paddr += (bpp / 8) * (state->src_x >> 16);
> paddr += fb->pitches[plane] * (state->src_y >> 16);
>
> return paddr;
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 0646b108030b..ab369f250af4 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -1572,6 +1572,7 @@ 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;
> int depth;
> + u8 bpp = drm_format_info_plane_bpp(fb->format, 0);
>
> if (var->pixclock != 0 || in_dbg_master())
> return -EINVAL;
> @@ -1580,14 +1581,14 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo
> *var,
>* Changes struct fb_var_screeninfo are currently not pushed back
>* to KMS, hence fail if different settings are requested.
>*/
> - if (var->bits_per_pixel != fb->format->cpp[0] * 8 ||
> + if (var->bits_per_pixel != bpp ||
> var->xres > fb->width || var->yres > fb->height ||
> var->xres_virtual > fb->width || var->yres_virtual > fb->height) {
> DRM_DEBUG("fb requested width/height/bpp can't fit in current
> fb "
> "request %dx%d-%d (virtual %dx%d) > %dx%d-%d\n",
> var->xres, var->yres, var->bits_per_pixel,
> var->xres_virtual, var->yres_virtual,
> - fb->width, fb->height, fb->format->cpp[0] * 8);
> + fb->width, fb->height, bpp);
> return -EINVAL;
> }
>
> @@ -1949,11 +1950,12 @@ void drm_fb_helper_fill_var(struct fb_info *info,
> struct drm_fb_helper *fb_helpe
> uint32_t fb_width, uint32_t fb_height)
> {
> struct drm_framebuffer *fb = fb_helper->fb;
> + u8 bpp = drm_format_info_plane_bpp(fb->format, 0);
>
> info->pseudo_palette = fb_helper->pseudo_palette;
> info->var.xres_virtual = fb->width;
> info->var.yres_virtual = fb->height;
> - info->var.bits_per_pixel = fb->format->cpp[0] * 8;
> + info->var.bits_per_pixel = bpp;
> info->var.accel_flags = FB_ACCELF_TEXT;
> info->var.xoffset = 0;
> info->var.yoffset = 0;
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index 3b42c25bd58d..bb28919c32f3 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -272,10 +272,60 @@ int drm_format_plane_cpp(uint32_t format, int plane)
> if (!info || plane >= info->num_planes)
> return 0;
>
> + /*
> + * Not valid for formats with non-integer cpp,
> + * use drm_format{_info}_plane_bpp instead
> +
Re: [PATCH libdrm v2 1/5] intel: add generic functions to check PCI ID
Quoting Lucas De Marchi (2018-08-29 01:35:28)
> +static const struct pci_device {
> + uint16_t device;
> + uint16_t gen;
> +} pciids[] = {
Add a comment here as well for the ordering requirement.
/* Keep ids sorted by gen; latest gen first */
We're unlikely to notice a comment in the function later trying to
impose its restriction.
> +};
> +
> +bool intel_is_genx(unsigned int devid, int gen)
> +{
> + const struct pci_device *p,
> + *pend = pciids + sizeof(pciids) / sizeof(pciids[0]);
> +
> + for (p = pciids; p < pend; p++) {
> + /* PCI IDs are sorted */
> + if (p->gen < gen)
> + break;
If we have lots of gen with lots of subids, a binary search for gen
would be sensible. However, do we need this function? Do we not just
convert everyone over to a lookup of pci-id on entry?
> +
> + if (p->device != devid)
> + continue;
> +
> + if (gen == p->gen)
> + return true;
> +
> + break;
> + }
> +
> + return false;
> +}
> +
> +bool intel_get_genx(unsigned int devid, int *gen)
> +{
> + const struct pci_device *p,
> + *pend = pciids + sizeof(pciids) / sizeof(pciids[0]);
> +
> + for (p = pciids; p < pend; p++) {
> + if (p->device != devid)
> + continue;
> +
> + if (gen)
> + *gen = p->gen;
> +
> + return true;
> + }
> +
> + return false;
> +}
Idle thought
#ifdef SELFTEST
int main(void)
{
/* check pci-ids are ordered by gen */
}
#endif
> diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
> index 4a34b7be..0e14c58f 100644
> --- a/intel/intel_chipset.h
> +++ b/intel/intel_chipset.h
> @@ -568,6 +568,13 @@
>
> #define IS_GEN11(devid)(IS_ICELAKE_11(devid))
>
> +/* New platforms use kernel pci ids */
> +#include
> +
> +bool intel_is_genx(unsigned int devid, int gen);
> +bool intel_get_genx(unsigned int devid, int *gen);
> +
> +/* all platforms */
Quite clearly not all platforms :-p
> #define IS_9XX(dev)(IS_GEN3(dev) || \
> IS_GEN4(dev) || \
> IS_GEN5(dev) || \
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/5] drm: Add support for handling linear tile formats
On Thu, Aug 23, 2018 at 06:43:40PM +0100, Alexandru-Cosmin Gheorghe wrote:
> On Wed, Aug 22, 2018 at 10:18:51PM +0200, Daniel Vetter wrote:
> > On Tue, Aug 21, 2018 at 07:30:03PM +0100, Alexandru Gheorghe wrote:
> > > The previous patch added tile_w and tile_h, which represent the
> > > horizontal and vertical sizes of a tile.
> > >
> > > This one uses that to plumb through drm core in order to be able to
> > > handle linear tile formats without the need for drivers to roll up
> > > their own implementation.
> > >
> > > This patch had been written with Mali-dp X0L2 and X0L0 in mind which
> > > is a 1 plane YCbCr 420 format with a 2x2 tile, that uses in average 2
> > > bytes per pixel and where tiles are laid out in a linear manner.
> > >
> > > Now what are the restrictions:
> > >
> > > 1. Pitch in bytes is expected to cover at least tile_h * width in
> > > pixels. Due to this the places where the pitch is checked/used need to
> > > be updated to take into consideration the tile_w, tile_h and
> > > tile_size.
> > > tile_size = cpp * tile_w * tile_h
> > >
> > > 2. When doing source cropping plane_src_x/y need to be a multiple of
> > > tile_w/tile_h and we need to take into consideration the tile_w/tile_h
> > > when computing the start address.
> > >
> > > For all non-tiled formats the tile_w and tile_h will be 1, so if I
> > > didn't miss anything nothing should change.
> > >
> > > Regarding multi-planar linear tile formats, I'm not sure how those
> > > should be handle I kind of assumed that tile_h/tile_w will have to be
> > > divided by horizontal/subsampling. Anyway, I think it's best to just
> > > put an warning in there and handle it when someone tries to add
> > > support for them.
> > >
> > > Signed-off-by: Alexandru Gheorghe
> > > ---
> > > drivers/gpu/drm/drm_atomic.c | 8 +++
> > > drivers/gpu/drm/drm_fb_cma_helper.c | 11 -
> > > drivers/gpu/drm/drm_fourcc.c | 52
> > > drivers/gpu/drm/drm_framebuffer.c| 19 +--
> > > drivers/gpu/drm/drm_gem_framebuffer_helper.c | 10 ++--
> > > include/drm/drm_fourcc.h | 2 +
> > > 6 files changed, 94 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > > index 3eb061e11e2e..7a3e893a4cd1 100644
> > > --- a/drivers/gpu/drm/drm_atomic.c
> > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > @@ -1087,6 +1087,14 @@ static int drm_atomic_plane_check(struct drm_plane
> > > *plane,
> > > return -ENOSPC;
> > > }
> > >
> > > + /* Make sure source coordinates are a multiple of tile sizes */
> > > + if ((state->src_x >> 16) % state->fb->format->tile_w ||
> > > + (state->src_y >> 16) % state->fb->format->tile_h) {
> > > + DRM_DEBUG_ATOMIC("[PLANE:%d:%s] Source coordinates do not meet
> > > tile restrictions",
> > > + plane->base.id, plane->name);
> > > + return -EINVAL;
> > > + }
> > > +
> > > if (plane_switching_crtc(state->state, plane, state)) {
> > > DRM_DEBUG_ATOMIC("[PLANE:%d:%s] switching CRTC directly\n",
> > >plane->base.id, plane->name);
> > > diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
> > > b/drivers/gpu/drm/drm_fb_cma_helper.c
> > > index 47e0e2f6642d..4d8052adce67 100644
> > > --- a/drivers/gpu/drm/drm_fb_cma_helper.c
> > > +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
> > > @@ -87,6 +87,8 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct
> > > drm_framebuffer *fb,
> > > struct drm_gem_cma_object *obj;
> > > dma_addr_t paddr;
> > > u8 h_div = 1, v_div = 1;
> > > + u32 tile_w = drm_format_tile_width(fb->format, plane);
> > > + u32 tile_h = drm_format_tile_height(fb->format, plane);
> > >
> > > obj = drm_fb_cma_get_gem_obj(fb, plane);
> > > if (!obj)
> > > @@ -99,8 +101,13 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct
> > > drm_framebuffer *fb,
> > > v_div = fb->format->vsub;
> > > }
> > >
> > > - paddr += (fb->format->cpp[plane] * (state->src_x >> 16)) / h_div;
> > > - paddr += (fb->pitches[plane] * (state->src_y >> 16)) / v_div;
> > > + paddr += (fb->format->cpp[plane] * tile_w * (state->src_x >> 16))
> > > + / h_div;
> > > + /*
> > > + * For tile formats pitches are expected to cover at least
> > > + * width * tile_h pixels
> > > + */
> > > + paddr += ((fb->pitches[plane] / tile_h) * (state->src_y >> 16)) / v_div;
> > >
> > > return paddr;
> > > }
> > > diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> > > index f55cd93ba2d0..d6c9c5aa4036 100644
> > > --- a/drivers/gpu/drm/drm_fourcc.c
> > > +++ b/drivers/gpu/drm/drm_fourcc.c
> > > @@ -557,3 +557,55 @@ int drm_format_plane_height(int height, uint32_t
> > > format, int plane)
> > > return height / info->vsub;
> > > }
> > > EXPORT_SYMBOL(drm_format_plane_height);
> > > +
> > > +/**
> > > + * drm_format_tile_width - width of a tile for tile formats, should be 1
[PATCH 2/2] fbdev: sbuslib: integer overflow in sbusfb_ioctl_helper()
The "index + count" addition can overflow. Both come directly from the
user. This bug leads to an information leak.
Signed-off-by: Dan Carpenter
---
Btw, commit 250c6c49e3b6 ("fbdev: Fixing arbitrary kernel leak in case
FBIOGETCMAP_SPARC in sbusfb_ioctl_helper().") doesn't do anything so
far as I can see. The "cmap->len" variable is type u32, so the
comparison was already unsigned in the original code because of type
promotion. But the commit was also harmless and nice cleanup.
diff --git a/drivers/video/fbdev/sbuslib.c b/drivers/video/fbdev/sbuslib.c
index 90c51330969c..01a7110e61a7 100644
--- a/drivers/video/fbdev/sbuslib.c
+++ b/drivers/video/fbdev/sbuslib.c
@@ -171,7 +171,7 @@ int sbusfb_ioctl_helper(unsigned long cmd, unsigned long
arg,
get_user(ublue, >blue))
return -EFAULT;
- if (index + count > cmap->len)
+ if (index > cmap->len || count > cmap->len - index)
return -EINVAL;
for (i = 0; i < count; i++) {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] fbdev: sbuslib: use checked version of put_user()
I'm not sure why the code assumes that only the first put_user() needs an access_ok() check. I have made all the put_user() and get_user() calls checked. Signed-off-by: Dan Carpenter diff --git a/drivers/video/fbdev/sbuslib.c b/drivers/video/fbdev/sbuslib.c index a436d44f1b7f..90c51330969c 100644 --- a/drivers/video/fbdev/sbuslib.c +++ b/drivers/video/fbdev/sbuslib.c @@ -106,11 +106,11 @@ int sbusfb_ioctl_helper(unsigned long cmd, unsigned long arg, struct fbtype __user *f = (struct fbtype __user *) arg; if (put_user(type, >fb_type) || - __put_user(info->var.yres, >fb_height) || - __put_user(info->var.xres, >fb_width) || - __put_user(fb_depth, >fb_depth) || - __put_user(0, >fb_cmsize) || - __put_user(fb_size, >fb_cmsize)) + put_user(info->var.yres, >fb_height) || + put_user(info->var.xres, >fb_width) || + put_user(fb_depth, >fb_depth) || + put_user(0, >fb_cmsize) || + put_user(fb_size, >fb_cmsize)) return -EFAULT; return 0; } @@ -125,10 +125,10 @@ int sbusfb_ioctl_helper(unsigned long cmd, unsigned long arg, unsigned int index, count, i; if (get_user(index, >index) || - __get_user(count, >count) || - __get_user(ured, >red) || - __get_user(ugreen, >green) || - __get_user(ublue, >blue)) + get_user(count, >count) || + get_user(ured, >red) || + get_user(ugreen, >green) || + get_user(ublue, >blue)) return -EFAULT; cmap.len = 1; @@ -165,10 +165,10 @@ int sbusfb_ioctl_helper(unsigned long cmd, unsigned long arg, u8 red, green, blue; if (get_user(index, >index) || - __get_user(count, >count) || - __get_user(ured, >red) || - __get_user(ugreen, >green) || - __get_user(ublue, >blue)) + get_user(count, >count) || + get_user(ured, >red) || + get_user(ugreen, >green) || + get_user(ublue, >blue)) return -EFAULT; if (index + count > cmap->len) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2.1 06/23] v4l: mediabus: Recognise CSI-2 D-PHY and C-PHY
The CSI-2 bus may use either D-PHY or C-PHY. Make this visible in media
bus enum.
Signed-off-by: Sakari Ailus
Tested-by: Steve Longerbeam
---
since v2:
- drivers/gpu/ipu-v3/ipu-csi.c got changed, requiring changes here.
drivers/gpu/ipu-v3/ipu-csi.c | 6 +++---
drivers/media/i2c/adv7180.c | 2 +-
drivers/media/i2c/ov5640.c | 4 ++--
drivers/media/i2c/ov5645.c | 2 +-
drivers/media/i2c/ov7251.c | 4 ++--
drivers/media/i2c/s5c73m3/s5c73m3-core.c | 2 +-
drivers/media/i2c/s5k5baf.c | 4 ++--
drivers/media/i2c/s5k6aa.c | 2 +-
drivers/media/i2c/smiapp/smiapp-core.c | 2 +-
drivers/media/i2c/soc_camera/ov5642.c| 2 +-
drivers/media/i2c/tc358743.c | 4 ++--
drivers/media/pci/intel/ipu3/ipu3-cio2.c | 2 +-
drivers/media/platform/cadence/cdns-csi2rx.c | 2 +-
drivers/media/platform/cadence/cdns-csi2tx.c | 2 +-
drivers/media/platform/marvell-ccic/mcam-core.c | 4 ++--
drivers/media/platform/marvell-ccic/mmp-driver.c | 2 +-
drivers/media/platform/omap3isp/isp.c| 2 +-
drivers/media/platform/pxa_camera.c | 2 +-
drivers/media/platform/rcar-vin/rcar-csi2.c | 2 +-
drivers/media/platform/soc_camera/soc_mediabus.c | 2 +-
drivers/media/platform/stm32/stm32-dcmi.c| 2 +-
drivers/media/platform/ti-vpe/cal.c | 2 +-
drivers/media/v4l2-core/v4l2-fwnode.c| 2 +-
drivers/staging/media/imx/imx-media-csi.c| 2 +-
drivers/staging/media/imx/imx6-mipi-csi2.c | 2 +-
drivers/staging/media/imx074/imx074.c| 2 +-
include/media/v4l2-mediabus.h| 6 --
27 files changed, 37 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-csi.c b/drivers/gpu/ipu-v3/ipu-csi.c
index 954eefe144e2..aa0e30a2ba18 100644
--- a/drivers/gpu/ipu-v3/ipu-csi.c
+++ b/drivers/gpu/ipu-v3/ipu-csi.c
@@ -232,7 +232,7 @@ static int mbus_code_to_bus_cfg(struct ipu_csi_bus_config
*cfg, u32 mbus_code,
case MEDIA_BUS_FMT_BGR565_2X8_LE:
case MEDIA_BUS_FMT_RGB565_2X8_BE:
case MEDIA_BUS_FMT_RGB565_2X8_LE:
- if (mbus_type == V4L2_MBUS_CSI2)
+ if (mbus_type == V4L2_MBUS_CSI2_DPHY)
cfg->data_fmt = CSI_SENS_CONF_DATA_FMT_RGB565;
else
cfg->data_fmt = CSI_SENS_CONF_DATA_FMT_BAYER;
@@ -359,7 +359,7 @@ static int fill_csi_bus_cfg(struct ipu_csi_bus_config
*csicfg,
else
csicfg->clk_mode = IPU_CSI_CLK_MODE_CCIR656_PROGRESSIVE;
break;
- case V4L2_MBUS_CSI2:
+ case V4L2_MBUS_CSI2_DPHY:
/*
* MIPI CSI-2 requires non gated clock mode, all other
* parameters are not applicable for MIPI CSI-2 bus.
@@ -611,7 +611,7 @@ int ipu_csi_set_mipi_datatype(struct ipu_csi *csi, u32 vc,
if (vc > 3)
return -EINVAL;
- ret = mbus_code_to_bus_cfg(, mbus_fmt->code, V4L2_MBUS_CSI2);
+ ret = mbus_code_to_bus_cfg(, mbus_fmt->code, V4L2_MBUS_CSI2_DPHY);
if (ret < 0)
return ret;
diff --git a/drivers/media/i2c/adv7180.c b/drivers/media/i2c/adv7180.c
index de10367d550b..2848a46d149a 100644
--- a/drivers/media/i2c/adv7180.c
+++ b/drivers/media/i2c/adv7180.c
@@ -761,7 +761,7 @@ static int adv7180_g_mbus_config(struct v4l2_subdev *sd,
struct adv7180_state *state = to_state(sd);
if (state->chip_info->flags & ADV7180_FLAG_MIPI_CSI2) {
- cfg->type = V4L2_MBUS_CSI2;
+ cfg->type = V4L2_MBUS_CSI2_DPHY;
cfg->flags = V4L2_MBUS_CSI2_1_LANE |
V4L2_MBUS_CSI2_CHANNEL_0 |
V4L2_MBUS_CSI2_CONTINUOUS_CLOCK;
diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index 071f4bc240ca..942531aaae92 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -1786,7 +1786,7 @@ static int ov5640_set_power(struct ov5640_dev *sensor,
bool on)
if (ret)
goto power_off;
- if (sensor->ep.bus_type == V4L2_MBUS_CSI2) {
+ if (sensor->ep.bus_type == V4L2_MBUS_CSI2_DPHY) {
/*
* start streaming briefly followed by stream off in
* order to coax the clock lane into LP-11 state.
@@ -2550,7 +2550,7 @@ static int ov5640_s_stream(struct v4l2_subdev *sd, int
enable)
goto out;
}
- if (sensor->ep.bus_type == V4L2_MBUS_CSI2)
+ if (sensor->ep.bus_type == V4L2_MBUS_CSI2_DPHY)
ret = ov5640_set_stream_mipi(sensor, enable);
else
ret = ov5640_set_stream_dvp(sensor, enable);
diff --git
Re: [PATCH v2 4/5] drm: Add support for handling linear tile formats
On Thu, Aug 23, 2018 at 06:19:31PM +0100, Alexandru-Cosmin Gheorghe wrote:
> On Thu, Aug 23, 2018 at 05:30:36PM +0300, Ville Syrjälä wrote:
> > On Wed, Aug 22, 2018 at 09:48:29PM +0200, Daniel Vetter wrote:
> > > On Wed, Aug 22, 2018 at 4:05 PM, Alexandru-Cosmin Gheorghe
> > > wrote:
> > > > On Wed, Aug 22, 2018 at 04:45:34PM +0300, Ville Syrjälä wrote:
> > > >> On Wed, Aug 22, 2018 at 02:36:06PM +0100, Alexandru-Cosmin Gheorghe
> > > >> wrote:
> > > >> > On Wed, Aug 22, 2018 at 04:18:54PM +0300, Ville Syrjälä wrote:
> > > >> > > On Tue, Aug 21, 2018 at 07:30:03PM +0100, Alexandru Gheorghe wrote:
> > > >> > > > The previous patch added tile_w and tile_h, which represent the
> > > >> > > > horizontal and vertical sizes of a tile.
> > > >> > > >
> > > >> > > > This one uses that to plumb through drm core in order to be able
> > > >> > > > to
> > > >> > > > handle linear tile formats without the need for drivers to roll
> > > >> > > > up
> > > >> > > > their own implementation.
> > > >> > > >
> > > >> > > > This patch had been written with Mali-dp X0L2 and X0L0 in mind
> > > >> > > > which
> > > >> > > > is a 1 plane YCbCr 420 format with a 2x2 tile, that uses in
> > > >> > > > average 2
> > > >> > > > bytes per pixel and where tiles are laid out in a linear manner.
> > > >> > > >
> > > >> > > > Now what are the restrictions:
> > > >> > > >
> > > >> > > > 1. Pitch in bytes is expected to cover at least tile_h * width in
> > > >> > > > pixels. Due to this the places where the pitch is checked/used
> > > >> > > > need to
> > > >> > > > be updated to take into consideration the tile_w, tile_h and
> > > >> > > > tile_size.
> > > >> > > > tile_size = cpp * tile_w * tile_h
> > > >> > > >
> > > >> > > > 2. When doing source cropping plane_src_x/y need to be a
> > > >> > > > multiple of
> > > >> > > > tile_w/tile_h and we need to take into consideration the
> > > >> > > > tile_w/tile_h
> > > >> > > > when computing the start address.
> > > >> > > >
> > > >> > > > For all non-tiled formats the tile_w and tile_h will be 1, so if
> > > >> > > > I
> > > >> > > > didn't miss anything nothing should change.
> > > >> > > >
> > > >> > > > Regarding multi-planar linear tile formats, I'm not sure how
> > > >> > > > those
> > > >> > > > should be handle I kind of assumed that tile_h/tile_w will have
> > > >> > > > to be
> > > >> > > > divided by horizontal/subsampling. Anyway, I think it's best to
> > > >> > > > just
> > > >> > > > put an warning in there and handle it when someone tries to add
> > > >> > > > support for them.
> > > >> > > >
> > > >> > > > Signed-off-by: Alexandru Gheorghe
> > > >> > > >
> > > >> > > > ---
> > > >> > > > drivers/gpu/drm/drm_atomic.c | 8 +++
> > > >> > > > drivers/gpu/drm/drm_fb_cma_helper.c | 11 -
> > > >> > > > drivers/gpu/drm/drm_fourcc.c | 52
> > > >> > > >
> > > >> > > > drivers/gpu/drm/drm_framebuffer.c| 19 +--
> > > >> > > > drivers/gpu/drm/drm_gem_framebuffer_helper.c | 10 ++--
> > > >> > > > include/drm/drm_fourcc.h | 2 +
> > > >> > > > 6 files changed, 94 insertions(+), 8 deletions(-)
> > > >> > > >
> > > >> > > > diff --git a/drivers/gpu/drm/drm_atomic.c
> > > >> > > > b/drivers/gpu/drm/drm_atomic.c
> > > >> > > > index 3eb061e11e2e..7a3e893a4cd1 100644
> > > >> > > > --- a/drivers/gpu/drm/drm_atomic.c
> > > >> > > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > >> > > > @@ -1087,6 +1087,14 @@ static int drm_atomic_plane_check(struct
> > > >> > > > drm_plane *plane,
> > > >> > > > return -ENOSPC;
> > > >> > > > }
> > > >> > > >
> > > >> > > > + /* Make sure source coordinates are a multiple of tile
> > > >> > > > sizes */
> > > >> > > > + if ((state->src_x >> 16) % state->fb->format->tile_w ||
> > > >> > > > + (state->src_y >> 16) % state->fb->format->tile_h) {
> > > >> > > > + DRM_DEBUG_ATOMIC("[PLANE:%d:%s] Source
> > > >> > > > coordinates do not meet tile restrictions",
> > > >> > > > +plane->base.id, plane->name);
> > > >> > > > + return -EINVAL;
> > > >> > > > + }
> > > >> > >
> > > >> > > Feels rather wrong to me to put such hardware specific limitations
> > > >> > > into
> > > >> > > the core.
> > > >> >
> > > >> > Yeah, the problem is that otherwise drm_fb_cma_get_gem_addr wouldn't
> > > >> > work.
> > > >>
> > > >> If that guy is supposed to give you a tile aligned address then it
> > > >> could
> > > >> just do that and leave it up to the driver to deal with the remainder
> > > >> of
> > > >> the coordinates?
> > > >>
> > > >> >
> > > >> > An alternative, would be to include it in the driver and put an WARN
> > > >> > in drm_fb_cma_get_gem_addr in case someone else uses it with a
> > > >> > src_x/src_y tile multiples.
> > > >> >
> > > >> > What do you think about that ?
> > > >> >
> > > >> > >
> > > >> > > > +
> > > >> > > >
Re: [Intel-gfx] [PATCH v7 2/2] drm/i915: Adding YUV444 packed format(DRM_FORMAT_XYUV) support.
On Thu, 2018-08-30 at 11:15 -0700, Dhinakaran Pandiyan wrote:
> On Thu, 2018-08-30 at 13:57 +0100, Lisovskiy, Stanislav wrote:
> > On Wed, 2018-08-29 at 12:16 -0700, Dhinakaran Pandiyan wrote:
> > >
> > > On Wed, 2018-08-29 at 21:10 +0300, Ville Syrjälä wrote:
> > > > On Wed, Aug 29, 2018 at 02:28:47PM +0300, Stanislav Lisovskiy
> > > > wrote:
> > > > > PLANE_CTL_FORMAT_AYUV is already supported, according to
> > > > > hardware
> > > > > specification.
> > > > >
> > > > > v2: Edited commit message, removed redundant whitespaces.
> > > > >
> > > > > v3: Fixed fallthrough logic for the format switch cases.
> > > > >
> > > > > v4: Yet again fixed fallthrough logic, to reuse code from
> > > > > other
> > > > > case
> > > > > labels.
> > > > >
> > > > > v5: Started to use XYUV instead of AYUV, as we don't use
> > > > > alpha.
>
> Curious what the reason is. Is it because the hardware does not
> support
> alpha with this format?
As I understood yes, this is a hardware limitation.
>
> > > > >
> > > > > v6: Removed unneeded initializer for new XYUV format.
> > > > >
> > > > > v7: Added scaling support for DRM_FORMAT_XYUV
> > >
> > > I don't see yuv formats in skl_format_to_fourcc(), any idea why?
> >
> > Good point. I guess would be nice idea to add at least XYUV there
> > now.
> > I can add rest of the formats with a separate patch afterwards.
>
> Wonder if the expectation is BIOS not use yuv formats. Ville?
I talked to Ville yesterday, I think that was basically what he said.
>
> >
> > >
> > > Also, shouldn't plane_color_ctl_alpha() be updated?
> >
> > I guess not, as we don't support alpha in that case.
>
> Right, the default case should take care of setting
> PLANE_CTL_ALPHA_DISABLE. I misread it.
>
> >
> > >
> > > > >
> > > > > Signed-off-by: Stanislav Lisovskiy > > > > .c
> > > > > om
> > > > > >
> > > > >
> > > > > ---
> > > > > drivers/gpu/drm/i915/intel_display.c | 8
> > > > > drivers/gpu/drm/i915/intel_sprite.c | 1 +
> > > > > 2 files changed, 9 insertions(+)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > > > b/drivers/gpu/drm/i915/intel_display.c
> > > > > index 30fdfd1a3037..3c96fa3a2b61 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > > > @@ -86,6 +86,7 @@ static const uint32_t skl_primary_formats[]
> > > > > =
> > > > > {
> > > > > DRM_FORMAT_YVYU,
> > > > > DRM_FORMAT_UYVY,
> > > > > DRM_FORMAT_VYUY,
> > > > > + DRM_FORMAT_XYUV,
> > > > > };
> > > > >
> > > > > static const uint32_t skl_pri_planar_formats[] = {
> > > > > @@ -102,6 +103,7 @@ static const uint32_t
> > > > > skl_pri_planar_formats[]
> > > > > = {
> > > > > DRM_FORMAT_UYVY,
> > > > > DRM_FORMAT_VYUY,
> > > > > DRM_FORMAT_NV12,
> > > > > + DRM_FORMAT_XYUV,
> > > >
> > > > I would keep the NV12 at the end so that the arrays are easier
> > > > to
> > > > compare visually.
> > > >
> > > > > };
> > > > >
> > > > > static const uint64_t skl_format_modifiers_noccs[] = {
> > > > > @@ -3501,6 +3503,8 @@ static u32
> > > > > skl_plane_ctl_format(uint32_t
> > > > > pixel_format)
> > > > > return PLANE_CTL_FORMAT_XRGB_2101010;
> > > > > case DRM_FORMAT_XBGR2101010:
> > > > > return PLANE_CTL_ORDER_RGBX |
> > > > > PLANE_CTL_FORMAT_XRGB_2101010;
> > > > > + case DRM_FORMAT_XYUV:
> > > > > + return PLANE_CTL_FORMAT_AYUV;
> > > >
> > > > We should probably rename that define to XYUV as well since it
> > > > doesn't
> > > > support per-pixel alpha.
> > > >
> > > > Since you've only implemented this for skl+ you chould mention
> > > > that
> > > > in the commit msg. IVB+ support should be equally trivial to
> > > > implement (wink wink).
> > > >
> > > > > case DRM_FORMAT_YUYV:
> > > > > return PLANE_CTL_FORMAT_YUV422 |
> > > > > PLANE_CTL_YUV422_YUYV;
> > > > > case DRM_FORMAT_YVYU:
> > > > > @@ -4959,6 +4963,7 @@ static int
> > > > > skl_update_scaler_plane(struct
> > > > > intel_crtc_state *crtc_state,
> > > > > case DRM_FORMAT_UYVY:
> > > > > case DRM_FORMAT_VYUY:
> > > > > case DRM_FORMAT_NV12:
> > > > > + case DRM_FORMAT_XYUV:
> > > > > break;
> > > > > default:
> > > > > DRM_DEBUG_KMS("[PLANE:%d:%s] FB:%d
> > > > > unsupported
> > > > > scaling format 0x%x\n",
> > > > > @@ -13399,6 +13404,7 @@ static bool
> > > > > skl_plane_format_mod_supported(struct drm_plane *_plane,
> > > > > }
> > > > >
> > > > > switch (format) {
> > > > > +
> > > >
> > > > Bogus whitespace.
> > > >
> > > > > case DRM_FORMAT_XRGB:
> > > > > case DRM_FORMAT_XBGR:
> > > > > case DRM_FORMAT_ARGB:
> > > > > @@ -13414,6 +13420,7 @@ static bool
> > > > > skl_plane_format_mod_supported(struct drm_plane *_plane,
> > > > > case DRM_FORMAT_UYVY:
> > > > > case DRM_FORMAT_VYUY:
> > > > > case
[PATCH v2 11/12] drm/sun4i: use simpler remove_conflicting_framebuffers(NULL)
Use remove_conflicting_framebuffers(NULL) instead of duplicating it.
Signed-off-by: Michał Mirosław
Acked-by: Maxime Ripard
Acked-by: Daniel Vetter
---
drivers/gpu/drm/sun4i/sun4i_drv.c | 18 +-
1 file changed, 1 insertion(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c
b/drivers/gpu/drm/sun4i/sun4i_drv.c
index 50d19605c38f..555b5db8036f 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -60,22 +60,6 @@ static struct drm_driver sun4i_drv_driver = {
/* Frame Buffer Operations */
};
-static void sun4i_remove_framebuffers(void)
-{
- struct apertures_struct *ap;
-
- ap = alloc_apertures(1);
- if (!ap)
- return;
-
- /* The framebuffer can be located anywhere in RAM */
- ap->ranges[0].base = 0;
- ap->ranges[0].size = ~0;
-
- drm_fb_helper_remove_conflicting_framebuffers(ap, "sun4i-drm-fb",
false);
- kfree(ap);
-}
-
static int sun4i_drv_bind(struct device *dev)
{
struct drm_device *drm;
@@ -118,7 +102,7 @@ static int sun4i_drv_bind(struct device *dev)
drm->irq_enabled = true;
/* Remove early framebuffers (ie. simplefb) */
- sun4i_remove_framebuffers();
+ drm_fb_helper_remove_conflicting_framebuffers(NULL, "sun4i-drm-fb",
false);
/* Create our framebuffer */
ret = sun4i_framebuffer_init(drm);
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 06/12] drm/cirrus: use simpler remove_conflicting_pci_framebuffers()
Signed-off-by: Michał Mirosław
Acked-by: Daniel Vetter
---
drivers/gpu/drm/cirrus/cirrus_drv.c | 23 +--
1 file changed, 1 insertion(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/cirrus/cirrus_drv.c
b/drivers/gpu/drm/cirrus/cirrus_drv.c
index 69c4e352dd78..85ed8657c862 100644
--- a/drivers/gpu/drm/cirrus/cirrus_drv.c
+++ b/drivers/gpu/drm/cirrus/cirrus_drv.c
@@ -42,33 +42,12 @@ static const struct pci_device_id pciidlist[] = {
};
-static int cirrus_kick_out_firmware_fb(struct pci_dev *pdev)
-{
- struct apertures_struct *ap;
- bool primary = false;
-
- ap = alloc_apertures(1);
- if (!ap)
- return -ENOMEM;
-
- ap->ranges[0].base = pci_resource_start(pdev, 0);
- ap->ranges[0].size = pci_resource_len(pdev, 0);
-
-#ifdef CONFIG_X86
- primary = pdev->resource[PCI_ROM_RESOURCE].flags &
IORESOURCE_ROM_SHADOW;
-#endif
- drm_fb_helper_remove_conflicting_framebuffers(ap, "cirrusdrmfb",
primary);
- kfree(ap);
-
- return 0;
-}
-
static int cirrus_pci_probe(struct pci_dev *pdev,
const struct pci_device_id *ent)
{
int ret;
- ret = cirrus_kick_out_firmware_fb(pdev);
+ ret = drm_fb_helper_remove_conflicting_pci_framebuffers(pdev, 0,
"cirrusdrmfb");
if (ret)
return ret;
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
