Re: [Intel-gfx] [PATCH v3 2/3] drm/i915: replace IS_GEN with IS_GEN(..., N)
On 07/12/2018 20:57, Lucas De Marchi wrote: On Fri, Dec 07, 2018 at 11:30:28AM +, Tvrtko Ursulin wrote: On 07/12/2018 01:17, Lucas De Marchi wrote: On Thu, Dec 6, 2018 at 4:37 AM Tvrtko Ursulin wrote: On 06/12/2018 06:11, Lucas De Marchi wrote: Define IS_GEN() similarly to our IS_GEN_RANGE(). but use gen instead of gen_mask to do the comparison. Now callers can pass then gen as a parameter, Since you are calling it out here, I assume there is some good reason to replace gen_mask with gen? Because in this version we don't have the commit removing gen from the device info. You had that? Totally don't remember.. what was the goal of that? Derive the same info from mask. gen = ffs(gen_mask) + 1, or something like that. Checking again I had actually removed only the macro INTEL_GEN, not the struct member. Probably because we use that than I thought we would. Checking gen instead of gen_mask is both simpler and generates smaller code (although the difference is negligible, ~100 bytes) Ok fair, and easy enough to change back once per SKU work rekindles. why would you need to change it back for per-SKU work? The compiler won't do anything smarter because of using the bitfield (provided this series is applied, which already merges IS_GEN8() || IS_GEN9() and the like). I think in my prototype I built a possible platform and gen mask from Kconfig options, and then applied that mask in the single __IS_GEN and __IS_PLATFORM macros, over the device and argument masks. That way DCE easily eliminates all unused branches. With the numerical gen it is still possible I suppose just possibly less elegant. So yeah, I think it's fine, was just wondering why since the commit message did not explain. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] v4.20-rc1: list_del corruption on thinkpad x220, graphics related?
On Sat, 2018-12-08 at 12:24 +0100, Pavel Machek wrote: > On Sat 2018-12-08 12:13:46, Pavel Machek wrote: > > Hi! > > > > > > > > There's one similar for nouveau in Bugzilla, but it seems like a > > > > > > genuine > > > > > > memory corruption (1 bit flipped): > > > > > > > > > > > > https://bugs.freedesktop.org/show_bug.cgi?id=84880 > > > > > > > > > > > > Any extra information would be of use :) > > > > > > > > > > > > Regards, Joonas > > > > > > > > > > > > PS. Could you open a bug to Bugzilla, it'll help to collect the > > > > > > information in one consolidated place: > > > > > > > > > > > > https://01.org/linuxgraphics/documentation/how-report-bugs > > > > > > > > > > I prefer email... certainly for bugs that can't be reproduced. > > > > > > > > By adding it to the Bugzilla it may be recognized by somebody else > > > > who is experiencing a similar issue. Internet points are not deducted > > > > for submitting bugs in good faith, even if they get closed as > > > > NOTABUG. > > > > Well, your documentation suggests you'll deduce my internet points: > > > > Before filing the bug, please try to reproduce your issue with the > > latest kernel. Use the latest drm-tip branch from > > http://cgit.freedesktop.org/drm-tip and build as instructed on our > > Build Guide. > > > > :-) > > I'd prefer not to run drm-tip. I'll update to 2.6.20-rc5+ and see if > it re-appears (but it takes long time to reproduce :-(). If we can or can not reproduce the issue with drm-tip, is a very useful datapoint for us. If we can not reproduce, it'll be possible to bisect which commit fixed it, and backport that. On the other hand, if it's still reproducible, we know we're not spending time on something we already fixed, and the priority gets a bump. > If you think it is useful, I can try to update my machine to > linux-next. linux-next is closer to drm-tip, so it's better. Do you have some specific reason for not wanting to run drm-tip (but linux-next is still ok)? Regards, Joonas > > Best regards, > Pavel > -- Joonas Lahtinen Open Source Graphics Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] v4.20-rc5+ on x220: Resetting chip for hang on rcs0
On Sun, 2018-12-09 at 12:18 +0100, Pavel Machek wrote: > Hi! > > Another day, another problem... but this one is different from the > previous hang, as machine survives. Please, file a bug. It says so even in the splat... Regards, Joonas > > Chromium was running with youtube video playing. > > [31850.666274] [drm] GPU hangs can indicate a bug anywhere in the > entire gfx stack, including userspace. > [31850.666277] [drm] Please file a _new_ bug report on > bugs.freedesktop.org against DRI -> DRM/Intel > [31850.666279] [drm] drm/i915 developers can then reassign to the > right component if it's not a kernel issue. > [31850.666282] [drm] The gpu crash dump is required to analyze gpu > hangs, so please always attach it. > [31850.666285] [drm] GPU crash dump saved to > /sys/class/drm/card0/error > [31850.666394] i915 :00:02.0: Resetting chip for hang on rcs0 > [31850.668474] WARNING: CPU: 0 PID: 13675 at > /data/fast/l/k/include/linux/dma-fence.h:503 > i915_request_skip+0x71/0x80 > [31850.668478] Modules linked in: > [31850.668484] CPU: 0 PID: 13675 Comm: kworker/0:3 Not tainted > 4.20.0-rc5+ #5 > [31850.668487] Hardware name: LENOVO 42872WU/42872WU, BIOS 8DET74WW > (1.44 ) 03/13/2018 > > Dmesg and /sys/class/drm/card0/error are attached. > > Best regards, > Pavel -- Joonas Lahtinen Open Source Graphics Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 04/35] drm/i915: Initialize HDCP2.2
On Sat, Dec 08, 2018 at 06:47:40PM +, Winkler, Tomas wrote: > > > > -Original Message- > > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel > > Vetter > > Sent: Friday, December 07, 2018 16:17 > > To: C, Ramalingam > > Cc: Daniel Vetter ; intel-gfx@lists.freedesktop.org; dri- > > de...@lists.freedesktop.org; daniel.vet...@ffwll.ch; Winkler, Tomas > > ; Shankar, Uma > > Subject: Re: [PATCH v8 04/35] drm/i915: Initialize HDCP2.2 > > > > On Fri, Dec 07, 2018 at 10:24:26AM +0530, C, Ramalingam wrote: > > > > > > On 12/6/2018 3:33 PM, Daniel Vetter wrote: > > > > On Tue, Nov 27, 2018 at 04:13:02PM +0530, Ramalingam C wrote: > > > > > Add the HDCP2.2 initialization to the existing HDCP1.4 stack. > > > > With the comments below addressed the commit message is a bit > > > > untrue, since this just wires up a basic hdcp2_supported flag in a few > > places. > > > > Please make that clear. > > > > > > > > > v2: > > > > >mei interface handle is protected with mutex. [Chris Wilson] > > > > > v3: > > > > >Notifiers are used for the mei interface state. > > > > > v4: > > > > >Poll for mei client device state > > > > >Error msg for out of mem [Uma] > > > > >Inline req for init function removed [Uma] > > > > > v5: > > > > >Rebase as Part of reordering. > > > > >Component is used for the I915 and MEI_HDCP interface [Daniel] > > > > > v6: > > > > >HDCP2.2 uses the I915 component master to communicate with > > mei_hdcp > > > > > - [Daniel] > > > > >Required HDCP2.2 variables defined [Sean Paul] > > > > > v7: > > > > >intel_hdcp2.2_init returns void [Uma] > > > > >Realigning the codes. > > > > > v8: > > > > >Avoid using bool structure members. > > > > >MEI interface related changes are moved into separate patch. > > > > >Commit msg is updated accordingly. > > > > >intel_hdcp_exit is defined and used from i915_unload > > > > > > > > > > Signed-off-by: Ramalingam C > > > > > --- > > > > > drivers/gpu/drm/i915/i915_drv.c | 2 + > > > > > drivers/gpu/drm/i915/intel_dp.c | 3 +- > > > > > drivers/gpu/drm/i915/intel_drv.h | 16 +++- > > > > > drivers/gpu/drm/i915/intel_hdcp.c | 172 -- > > > > > > > drivers/gpu/drm/i915/intel_hdmi.c | 2 +- > > > > > 5 files changed, 130 insertions(+), 65 deletions(-) > > > > > > > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.c > > > > > b/drivers/gpu/drm/i915/i915_drv.c index b1d23c73c147..fbedd5024afe > > > > > 100644 > > > > > --- a/drivers/gpu/drm/i915/i915_drv.c > > > > > +++ b/drivers/gpu/drm/i915/i915_drv.c > > > > > @@ -1755,6 +1755,8 @@ void i915_driver_unload(struct drm_device > > *dev) > > > > > disable_rpm_wakeref_asserts(dev_priv); > > > > > + intel_hdcp_exit(dev_priv); > > > > This smells like a separate patch. Needs to be split out. Looking at > > > > the implementation of intel_hdcp_exit I think it's papering over > > > > some unload trouble. We should be shutting down all the outputs on > > > > driver unload, which mei should be triggering (with the component > > > > stuff), which means this code should be unecessary. But I'm not sure. > > > > > > > > Either way needs to be split out, but I think proper solution is to > > > > drop it. > > > > > > As we discussed, during v7-->v8 i changed the component usage such that it > > wont affect i915 load/unload. > > > During the first connector init, component master will be added. And > > > during the mei_client dev and driver binding, component will be added > > > hence > > the binding will happen with interface initialization from mei. > > > > > > Upon HDCP2.2 request, component binding will be checked before > > attempting for HDCP2.2 auth. > > > So component master unbind triggered due to mei component_del, will > > teardown the HDCP2.2 capability of the I915. > > > > > > So in case of I915 unload trigger, from whatsoever reason, we need to > > > clear the HDCP activities and bring down the i915_hdcp_component_master > > and the interface with mei. For this purpose only intel_hdcp_exit is written > > here. > > > > Summarizing our irc discussion: > > > > - I like the component usage of v7 much more. > > > > - I still don't think we have a use-case for loading/unloading mei_hdcp on > > demand, or at least not in lockstep with i915.ko: > We are testing all the MEI modules reloading, this would be suddenly an > exception. We're doing the same. And with the component stuff you can do that too in a clean way. But there's a difference between a useful feature for developers and something we need in production. What I mean here is that I don't see a use-case for unloading mei_hdcp, while i915 still needs to keep working. That's the only difference between v7 and v8 in features support wrt driver loading/unloading. > > - CrOS won't use ME > I'm not so sure, we are working on it. Hm, that's interesting. We can't support HDCP2 on CrOS because of the ME thing
Re: [Intel-gfx] [PATCH v8 03/35] linux/mei: Header for mei_hdcp driver interface
On Sat, Dec 08, 2018 at 08:15:52PM +, Winkler, Tomas wrote:
>
> > On Fri, Dec 07, 2018 at 07:23:06PM +0530, C, Ramalingam wrote:
> > > Hi,
> > >
> > > In one of the offline discussion Tomas has shared his review comments on
> > > v8.
> >
> > Let's please have all review here on the mailing list for better
> > coordination.
> > Playing a game of telephone isn't efficient.
> It's not different from IRC or meeting on a conference, after all we end up
> with code we can comment on.
For IRC we try to summarize discussions on the mailing list too. Same for
conferences (if that ever happens for public stuff).
> > > So I am sharing the abstract of his suggestions here for the discussion
> > > and for
> > the agreement of interface in the community.
> > > Tomas please correct/add if I am missing any points.
> > >
> > > 1. Remove the include/linux/mei_hdcp.h to make the i915-mei interface
> > >more generic.
> > > 1. Move the definition of the struct mei_hdcp_data to i915 and
> > >mei_hdcp.c and pass the void* in the ops' functions.
> >
> > I don't get this. Using void * instead of the actual type we're passing
> > isn't more
> > generic, it's just less safe. If we later on need to extend the api contract
> > between mei_hdcp and i915 we can always do that. Like we already do with the
> > i915/snd-hda-intel component contract in i915_component.h and
> > drm_audio_component.h.
>
> No I haven't suggesting using void *, what I've suggest is to use HDCP
> construct instead of mei specific types.
Ah, makes sense. I thought v7 pretty much does that already though, at
least as far as we define these structures on the drm side (it's just a
register file in an i2c target address after all).
-Daniel
> > Aside: Header names for the audio interface are maybe not the best, this
> > isn't
> > primarily a component thing. So maybe call it i915_mei_hdcp_interface.h and
> > stuff all the structures/function pointers that define the interface
> > between the
> > two drivers in there. Or some other suitable name you like better.
> >
> > > 2. Move the conversion of enum port value to mei_ddi_port value
> > >into mei_hdcp.c. Let I915 pass the enum port value as such.
> >
> > logical port 2 physical register index mapping tends to shift around and is
> > always highly machine specific. As long as we do it consistently somewhere
> > we
> > should be good. Seems fine to me.
> >
> > > 3. Modified local definition of the struct mei_hdcp_data will looks
> > >like
> >
> > No local defintions of structures please. Otherwise I'm ok with whatever
> > gets
> > the job done.
> >
> > > 4.
> > >
> > >+/* hdcp data per port */
> > >+struct hdcp_port_data {
> > >+ short int port;
> > >+ u8 port_type;
> > >+ u8 protocol;
> > >+ u16 k;
> > >+ u32 seq_num_m;
> > >+ struct hdcp2_streamid_type *streams;
> > > };
> > >
> > > 2. Add K-Doc compliant commenting in the mei_hdcp.c
> >
> > If you do that, please include the relevant comments into the drm/i915
> > docbook, like we do already with the audio stuff.
> >
> > > I have implemented these changes and posted for intel-gfx-trybot. Just
> > > incase anyone wants to refer the code please look at
> > https://patchwork.freedesktop.org/series/53655/ .
> > > Not shared on #intel-gfx as further review discussions are on-going on
> > > intel-
> > gfx.
> >
> > As discussed, no void * in the interface, and we definitely need a shared
> > header
> > for ops/data structures. We want the compiler to help us catch when one side
> > of this i915/mei_hdcp api contract changes as much as possible.
> > All the other changes seem reasonable.
>
> > Thanks, Daniel
> I agree with no void *, that was not my intention.
> It will be better to comment on v9 series.
>
>
> > >
> >
> > > --Ram
> > >
> > > On 11/27/2018 4:13 PM, Ramalingam C wrote:
> > > > Data structures and Enum for the I915-MEI_HDCP interface are defined
> > > > at
> > > >
> > > > v2:
> > > >Rebased.
> > > > v3:
> > > >mei_cl_device is removed from mei_hdcp_data [Tomas]
> > > > v4:
> > > >Comment style and typo fixed [Uma]
> > > > v5:
> > > >Rebased.
> > > > v6:
> > > >No changes.
> > > > v7:
> > > >Remove redundant text from the License header
> > > >Change uintXX_t type to uXX_t types
> > > >Remove unneeded include to mei_cl_bus.h
> > > >Coding style fixed [Uma]
> > > > V8:
> > > >Tab cleanup
> > > >Fix kdoc and namespaces
> > > >Update MAINTAINERS
> > > >
> > > > Signed-off-by: Ramalingam C
> > > > Signed-off-by: Tomas Winkler
> > > > Reviewed-by: Uma Shankar
> > > > ---
> > > > MAINTAINERS | 1 +
> > > > include/linux/mei_hdcp.h | 91
> >
> > > > 2 files changed, 92 insertions(+)
> > > > create mode 100644 include/linux/mei_hdcp.h
> > > >
> > > > diff --git a/MAINTAINERS b/MAINTAINERS index
>
Re: [Intel-gfx] [PATCH] drm/dp-mst-helper: Remove hotplug callback
On Thu, Nov 29, 2018 at 01:30:59PM -0500, Lyude Paul wrote:
> Reviewed-by: Lyude Paul
Applied, thanks for your review.
-Daniel
>
> On Wed, 2018-11-28 at 23:12 +0100, Daniel Vetter wrote:
> > When everyone implements it exactly the same way, among all 4
> > implementations, there's not really a need to overwrite this at all.
> >
> > Aside: drm_kms_helper_hotplug_event is pretty much core functionality
> > at this point. Probably should move it there.
> >
> > Signed-off-by: Daniel Vetter
> > ---
> > .../drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c| 9 -
> > drivers/gpu/drm/drm_dp_mst_topology.c | 7 ---
> > drivers/gpu/drm/i915/intel_dp_mst.c| 10 --
> > drivers/gpu/drm/nouveau/dispnv50/disp.c| 8
> > drivers/gpu/drm/radeon/radeon_dp_mst.c | 9 -
> > include/drm/drm_dp_mst_helper.h| 2 --
> > 6 files changed, 4 insertions(+), 41 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> > index d02c32a1039c..9fdeca096407 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> > @@ -396,14 +396,6 @@ static void dm_dp_destroy_mst_connector(struct
> > drm_dp_mst_topology_mgr *mgr,
> > drm_connector_put(connector);
> > }
> >
> > -static void dm_dp_mst_hotplug(struct drm_dp_mst_topology_mgr *mgr)
> > -{
> > - struct amdgpu_dm_connector *master = container_of(mgr, struct
> > amdgpu_dm_connector, mst_mgr);
> > - struct drm_device *dev = master->base.dev;
> > -
> > - drm_kms_helper_hotplug_event(dev);
> > -}
> > -
> > static void dm_dp_mst_register_connector(struct drm_connector *connector)
> > {
> > struct drm_device *dev = connector->dev;
> > @@ -420,7 +412,6 @@ static void dm_dp_mst_register_connector(struct
> > drm_connector *connector)
> > static const struct drm_dp_mst_topology_cbs dm_mst_cbs = {
> > .add_connector = dm_dp_add_mst_connector,
> > .destroy_connector = dm_dp_destroy_mst_connector,
> > - .hotplug = dm_dp_mst_hotplug,
> > .register_connector = dm_dp_mst_register_connector
> > };
> >
> > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > index 08978ad72f33..639552918b44 100644
> > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > @@ -33,6 +33,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > /**
> > * DOC: dp mst helper
> > @@ -1650,7 +1651,7 @@ static void drm_dp_send_link_address(struct
> > drm_dp_mst_topology_mgr *mgr,
> > for (i = 0; i < txmsg->reply.u.link_addr.nports; i++)
> > {
> > drm_dp_add_port(mstb, mgr->dev, &txmsg-
> > >reply.u.link_addr.ports[i]);
> > }
> > - (*mgr->cbs->hotplug)(mgr);
> > + drm_kms_helper_hotplug_event(mgr->dev);
> > }
> > } else {
> > mstb->link_address_sent = false;
> > @@ -2423,7 +2424,7 @@ static int drm_dp_mst_handle_up_req(struct
> > drm_dp_mst_topology_mgr *mgr)
> > drm_dp_update_port(mstb, &msg.u.conn_stat);
> >
> > DRM_DEBUG_KMS("Got CSN: pn: %d ldps:%d ddps: %d mcs:
> > %d ip: %d pdt: %d\n", msg.u.conn_stat.port_number,
> > msg.u.conn_stat.legacy_device_plug_status,
> > msg.u.conn_stat.displayport_device_plug_status,
> > msg.u.conn_stat.message_capability_status, msg.u.conn_stat.input_port,
> > msg.u.conn_stat.peer_device_type);
> > - (*mgr->cbs->hotplug)(mgr);
> > + drm_kms_helper_hotplug_event(mgr->dev);
> >
> > } else if (msg.req_type == DP_RESOURCE_STATUS_NOTIFY) {
> > drm_dp_send_up_ack_reply(mgr, mgr->mst_primary,
> > msg.req_type, seqno, false);
> > @@ -3120,7 +3121,7 @@ static void drm_dp_destroy_connector_work(struct
> > work_struct *work)
> > send_hotplug = true;
> > }
> > if (send_hotplug)
> > - (*mgr->cbs->hotplug)(mgr);
> > + drm_kms_helper_hotplug_event(mgr->dev);
> > }
> >
> > static struct drm_private_state *
> > diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
> > b/drivers/gpu/drm/i915/intel_dp_mst.c
> > index 4de247ddf05f..f05427b74e34 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> > @@ -517,20 +517,10 @@ static void intel_dp_destroy_mst_connector(struct
> > drm_dp_mst_topology_mgr *mgr,
> > drm_connector_put(connector);
> > }
> >
> > -static void intel_dp_mst_hotplug(struct drm_dp_mst_topology_mgr *mgr)
> > -{
> > - struct intel_dp *intel_dp = container_of(mgr, struct intel_dp,
> > mst_mgr);
> > - struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> > - struct drm_device *dev
[Intel-gfx] [PATCH 0/7] legacy helper cleanup
Hi all, Just a small cleanup motivated by the last patch. After this series atomic drivers do no longer need the drm_crtc_helper.h header, and none of them use it. Except for the 2 that support both atomic and legacy kms in the same driver module (nouveau and amdgpu). Last patch is a bit huge, but splitting it up will make the churn only worse. Comments and review very much appreciated. Cheers, Daniel Daniel Vetter (7): drm/ch7006: Stop using drm_crtc_force_disable drm/nouveau: Stop using drm_crtc_force_disable drm: Unexport drm_crtc_force_disable drm: Move the legacy kms disable_all helper to crtc helpers drm/qxl: Don't set the dpms hook drm/xen: Don't set the dpms hook drm: Split out drm_probe_helper.h .../gpu/drm/amd/amdgpu/amdgpu_connectors.c| 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 1 + .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 +- .../amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c | 2 +- .../display/amdgpu_dm/amdgpu_dm_services.c| 2 +- drivers/gpu/drm/arc/arcpgu_crtc.c | 2 +- drivers/gpu/drm/arc/arcpgu_drv.c | 2 +- drivers/gpu/drm/arc/arcpgu_sim.c | 2 +- drivers/gpu/drm/arm/hdlcd_crtc.c | 2 +- drivers/gpu/drm/arm/hdlcd_drv.c | 2 +- drivers/gpu/drm/arm/malidp_crtc.c | 2 +- drivers/gpu/drm/arm/malidp_drv.c | 2 +- drivers/gpu/drm/arm/malidp_mw.c | 2 +- drivers/gpu/drm/armada/armada_510.c | 2 +- drivers/gpu/drm/armada/armada_crtc.c | 2 +- drivers/gpu/drm/armada/armada_drv.c | 2 +- drivers/gpu/drm/armada/armada_fb.c| 2 +- drivers/gpu/drm/ast/ast_drv.c | 1 + drivers/gpu/drm/ast/ast_mode.c| 1 + .../gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c| 2 +- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 2 +- drivers/gpu/drm/bochs/bochs_drv.c | 1 + drivers/gpu/drm/bochs/bochs_kms.c | 1 + drivers/gpu/drm/bridge/adv7511/adv7511.h | 2 +- drivers/gpu/drm/bridge/analogix-anx78xx.c | 3 +- .../drm/bridge/analogix/analogix_dp_core.c| 2 +- drivers/gpu/drm/bridge/cdns-dsi.c | 2 +- drivers/gpu/drm/bridge/dumb-vga-dac.c | 2 +- .../bridge/megachips-stdp-ge-b850v3-fw.c | 2 +- drivers/gpu/drm/bridge/nxp-ptn3460.c | 2 +- drivers/gpu/drm/bridge/panel.c| 2 +- drivers/gpu/drm/bridge/parade-ps8622.c| 2 +- drivers/gpu/drm/bridge/sii902x.c | 2 +- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +- drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 2 +- drivers/gpu/drm/bridge/tc358764.c | 2 +- drivers/gpu/drm/bridge/tc358767.c | 2 +- drivers/gpu/drm/bridge/ti-sn65dsi86.c | 2 +- drivers/gpu/drm/bridge/ti-tfp410.c| 2 +- drivers/gpu/drm/cirrus/cirrus_drv.c | 1 + drivers/gpu/drm/cirrus/cirrus_mode.c | 1 + drivers/gpu/drm/drm_atomic_helper.c | 1 - drivers/gpu/drm/drm_crtc.c| 41 --- drivers/gpu/drm/drm_crtc_helper.c | 35 + drivers/gpu/drm/drm_crtc_internal.h | 1 + drivers/gpu/drm/drm_dp_mst_topology.c | 2 +- drivers/gpu/drm/drm_modeset_helper.c | 2 +- drivers/gpu/drm/drm_probe_helper.c| 2 +- drivers/gpu/drm/drm_simple_kms_helper.c | 2 +- drivers/gpu/drm/etnaviv/etnaviv_drv.h | 1 - drivers/gpu/drm/exynos/exynos_dp.c| 2 +- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 2 +- drivers/gpu/drm/exynos/exynos_drm_dpi.c | 2 +- drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +- drivers/gpu/drm/exynos/exynos_drm_dsi.c | 2 +- drivers/gpu/drm/exynos/exynos_drm_fb.c| 2 +- drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 2 +- drivers/gpu/drm/exynos/exynos_drm_vidi.c | 2 +- drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c| 2 +- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 2 +- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c | 2 +- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c | 2 +- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 2 +- drivers/gpu/drm/gma500/psb_intel_drv.h| 1 + .../gpu/drm/hisilicon/hibmc/hibmc_drm_de.c| 2 +- .../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 2 +- .../gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c | 2 +- .../gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c | 2 +- drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 2 +- .../gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 2 +- .../gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 2 +- drivers/gpu/drm/i2c/ch7006_drv.c | 6 +-- drivers/gpu/drm/i2c/ch7006_priv.h | 2 +- drivers/gpu/drm/i2c/sil164_drv.c | 2 +- drivers/gpu/drm
[Intel-gfx] [PATCH 4/7] drm: Move the legacy kms disable_all helper to crtc helpers
It's not a core function, and the matching atomic functions are also
not in the core. Plus the suspend/resume helper is also already there.
Needs a tiny bit of open-coding, but less midlayer beats that I think.
Cc: Sam Bobroff
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Sean Paul
Cc: David Airlie
Cc: Ben Skeggs
Cc: Alex Deucher
Cc: "Christian König"
Cc: "David (ChunMing) Zhou"
Cc: Rex Zhu
Cc: Andrey Grodzovsky
Cc: Huang Rui
Cc: Shaoyun Liu
Cc: Monk Liu
Cc: nouv...@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
drivers/gpu/drm/drm_crtc.c | 31 ---
drivers/gpu/drm/drm_crtc_helper.c | 35 ++
drivers/gpu/drm/nouveau/nouveau_display.c | 2 +-
drivers/gpu/drm/radeon/radeon_display.c| 2 +-
include/drm/drm_crtc.h | 2 --
include/drm/drm_crtc_helper.h | 1 +
7 files changed, 39 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index c75badfa5c4c..e669297ffefb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -2689,7 +2689,7 @@ void amdgpu_device_fini(struct amdgpu_device *adev)
amdgpu_irq_disable_all(adev);
if (adev->mode_info.mode_config_initialized){
if (!amdgpu_device_has_dc_support(adev))
- drm_crtc_force_disable_all(adev->ddev);
+ drm_helper_force_disable_all(adev->ddev);
else
drm_atomic_helper_shutdown(adev->ddev);
}
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index f660819d406e..7dabbaf033a1 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -104,37 +104,6 @@ int drm_crtc_force_disable(struct drm_crtc *crtc)
return drm_mode_set_config_internal(&set);
}
-/**
- * drm_crtc_force_disable_all - Forcibly turn off all enabled CRTCs
- * @dev: DRM device whose CRTCs to turn off
- *
- * Drivers may want to call this on unload to ensure that all displays are
- * unlit and the GPU is in a consistent, low power state. Takes modeset locks.
- *
- * Note: This should only be used by non-atomic legacy drivers. For an atomic
- * version look at drm_atomic_helper_shutdown().
- *
- * Returns:
- * Zero on success, error code on failure.
- */
-int drm_crtc_force_disable_all(struct drm_device *dev)
-{
- struct drm_crtc *crtc;
- int ret = 0;
-
- drm_modeset_lock_all(dev);
- drm_for_each_crtc(crtc, dev)
- if (crtc->enabled) {
- ret = drm_crtc_force_disable(crtc);
- if (ret)
- goto out;
- }
-out:
- drm_modeset_unlock_all(dev);
- return ret;
-}
-EXPORT_SYMBOL(drm_crtc_force_disable_all);
-
static unsigned int drm_num_crtcs(struct drm_device *dev)
{
unsigned int num = 0;
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index a3c81850e755..23159eb494f1 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -984,3 +984,38 @@ void drm_helper_resume_force_mode(struct drm_device *dev)
drm_modeset_unlock_all(dev);
}
EXPORT_SYMBOL(drm_helper_resume_force_mode);
+
+/**
+ * drm_helper_force_disable_all - Forcibly turn off all enabled CRTCs
+ * @dev: DRM device whose CRTCs to turn off
+ *
+ * Drivers may want to call this on unload to ensure that all displays are
+ * unlit and the GPU is in a consistent, low power state. Takes modeset locks.
+ *
+ * Note: This should only be used by non-atomic legacy drivers. For an atomic
+ * version look at drm_atomic_helper_shutdown().
+ *
+ * Returns:
+ * Zero on success, error code on failure.
+ */
+int drm_helper_force_disable_all(struct drm_device *dev)
+{
+ struct drm_crtc *crtc;
+ int ret = 0;
+
+ drm_modeset_lock_all(dev);
+ drm_for_each_crtc(crtc, dev)
+ if (crtc->enabled) {
+ struct drm_mode_set set = {
+ .crtc = crtc,
+ };
+
+ ret = drm_mode_set_config_internal(&set);
+ if (ret)
+ goto out;
+ }
+out:
+ drm_modeset_unlock_all(dev);
+ return ret;
+}
+EXPORT_SYMBOL(drm_helper_force_disable_all);
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
b/drivers/gpu/drm/nouveau/nouveau_display.c
index f326ffd86766..5d273a655479 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -453,7 +453,7 @@ nouveau_display_fini(struct drm_device *dev, bool suspend,
bool runtime)
if (drm_drv_uses_atomic_modeset(dev))
drm_atomic_helper_shutdown(dev);
[Intel-gfx] [PATCH 1/7] drm/ch7006: Stop using drm_crtc_force_disable
The correct way for legacy drivers to update properties that need to
do a full modeset, is to do a full modeset.
Note that we don't need to call the drm_mode_config_internal helper
because we're not changing any of the refcounted paramters.
Signed-off-by: Daniel Vetter
Cc: Daniel Vetter
---
drivers/gpu/drm/i2c/ch7006_drv.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i2c/ch7006_drv.c b/drivers/gpu/drm/i2c/ch7006_drv.c
index 544a8a2d3562..719c79d3fac9 100644
--- a/drivers/gpu/drm/i2c/ch7006_drv.c
+++ b/drivers/gpu/drm/i2c/ch7006_drv.c
@@ -359,10 +359,10 @@ static int ch7006_encoder_set_property(struct drm_encoder
*encoder,
if (modes_changed) {
drm_helper_probe_single_connector_modes(connector, 0, 0);
- /* Disable the crtc to ensure a full modeset is
-* performed whenever it's turned on again. */
if (crtc)
- drm_crtc_force_disable(crtc);
+ return drm_crtc_helper_set_mode(crtc, &crtc->mode,
+ crtc->x, crtc->y,
+ crtc->primary->fb);
}
return 0;
--
2.20.0.rc1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/7] drm/qxl: Don't set the dpms hook
Doesn't do anything with atomic.
Signed-off-by: Daniel Vetter
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: virtualizat...@lists.linux-foundation.org
Cc: spice-de...@lists.freedesktop.org
---
drivers/gpu/drm/qxl/qxl_display.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
b/drivers/gpu/drm/qxl/qxl_display.c
index ce0b9c40fc21..72a1784dae54 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -1010,7 +1010,6 @@ static void qxl_conn_destroy(struct drm_connector
*connector)
}
static const struct drm_connector_funcs qxl_connector_funcs = {
- .dpms = drm_helper_connector_dpms,
.detect = qxl_conn_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
.destroy = qxl_conn_destroy,
--
2.20.0.rc1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/7] drm/xen: Don't set the dpms hook
Doesn't do anything for atomic.
Signed-off-by: Daniel Vetter
Cc: Oleksandr Andrushchenko
Cc: xen-de...@lists.xen.org
---
drivers/gpu/drm/xen/xen_drm_front_conn.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/xen/xen_drm_front_conn.c
b/drivers/gpu/drm/xen/xen_drm_front_conn.c
index c91ae532fa55..54af2669b1b3 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_conn.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_conn.c
@@ -89,7 +89,6 @@ static const struct drm_connector_helper_funcs
connector_helper_funcs = {
};
static const struct drm_connector_funcs connector_funcs = {
- .dpms = drm_helper_connector_dpms,
.fill_modes = drm_helper_probe_single_connector_modes,
.destroy = drm_connector_cleanup,
.reset = drm_atomic_helper_connector_reset,
--
2.20.0.rc1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/7] drm: Unexport drm_crtc_force_disable
It's a legacy kms only thing, good to hide it better now that all
those old drivers use the legacy crtc helpers directly.
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Sean Paul
Cc: David Airlie
---
drivers/gpu/drm/drm_crtc.c | 10 --
drivers/gpu/drm/drm_crtc_internal.h | 1 +
include/drm/drm_crtc.h | 1 -
3 files changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 1593dd6cdfb7..f660819d406e 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -93,15 +93,6 @@ struct drm_crtc *drm_crtc_from_index(struct drm_device *dev,
int idx)
}
EXPORT_SYMBOL(drm_crtc_from_index);
-/**
- * drm_crtc_force_disable - Forcibly turn off a CRTC
- * @crtc: CRTC to turn off
- *
- * Note: This should only be used by non-atomic legacy drivers.
- *
- * Returns:
- * Zero on success, error code on failure.
- */
int drm_crtc_force_disable(struct drm_crtc *crtc)
{
struct drm_mode_set set = {
@@ -112,7 +103,6 @@ int drm_crtc_force_disable(struct drm_crtc *crtc)
return drm_mode_set_config_internal(&set);
}
-EXPORT_SYMBOL(drm_crtc_force_disable);
/**
* drm_crtc_force_disable_all - Forcibly turn off all enabled CRTCs
diff --git a/drivers/gpu/drm/drm_crtc_internal.h
b/drivers/gpu/drm/drm_crtc_internal.h
index 86893448f486..216f2a9ee3d4 100644
--- a/drivers/gpu/drm/drm_crtc_internal.h
+++ b/drivers/gpu/drm/drm_crtc_internal.h
@@ -50,6 +50,7 @@ int drm_crtc_check_viewport(const struct drm_crtc *crtc,
const struct drm_framebuffer *fb);
int drm_crtc_register_all(struct drm_device *dev);
void drm_crtc_unregister_all(struct drm_device *dev);
+int drm_crtc_force_disable(struct drm_crtc *crtc);
struct dma_fence *drm_crtc_create_fence(struct drm_crtc *crtc);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 39c3900aab3c..b45bec0b7a9c 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1149,7 +1149,6 @@ static inline uint32_t drm_crtc_mask(const struct
drm_crtc *crtc)
return 1 << drm_crtc_index(crtc);
}
-int drm_crtc_force_disable(struct drm_crtc *crtc);
int drm_crtc_force_disable_all(struct drm_device *dev);
int drm_mode_set_config_internal(struct drm_mode_set *set);
--
2.20.0.rc1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/7] drm/nouveau: Stop using drm_crtc_force_disable
The correct way for legacy drivers to update properties that need to do a full modeset, is to do a full modeset. Note that we don't need to call the drm_mode_config_internal helper because we're not changing any of the refcounted paramters. Signed-off-by: Daniel Vetter Cc: Daniel Vetter Cc: Sean Paul --- drivers/gpu/drm/nouveau/dispnv04/tvnv17.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c b/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c index 6a4ca139cf5d..3e82db41f8a4 100644 --- a/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c +++ b/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c @@ -750,7 +750,9 @@ static int nv17_tv_set_property(struct drm_encoder *encoder, /* Disable the crtc to ensure a full modeset is * performed whenever it's turned on again. */ if (crtc) - drm_crtc_force_disable(crtc); + return drm_crtc_helper_set_mode(crtc, &crtc->mode, + crtc->x, crtc->y, + crtc->primary->fb); } return 0; -- 2.20.0.rc1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/dp-mst-helper: Remove hotplug callback
== Series Details ==
Series: drm/dp-mst-helper: Remove hotplug callback
URL : https://patchwork.freedesktop.org/series/53192/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5217_full -> Patchwork_10942_full
Summary
---
**WARNING**
Minor unknown changes coming with Patchwork_10942_full need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_10942_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_10942_full:
### IGT changes ###
Warnings
* igt@kms_vblank@pipe-a-ts-continuation-modeset-hang:
- shard-snb: SKIP -> PASS
* igt@kms_vblank@pipe-b-wait-busy:
- shard-snb: PASS -> SKIP +2
* igt@perf_pmu@rc6:
- shard-kbl: SKIP -> PASS
Known issues
Here are the changes found in Patchwork_10942_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@kms_busy@extended-modeset-hang-newfb-render-b:
- shard-skl: NOTRUN -> DMESG-WARN [fdo#107956]
* igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a:
- shard-skl: PASS -> DMESG-WARN [fdo#107956]
* igt@kms_ccs@pipe-c-crc-primary-rotation-180:
- {shard-iclb}: NOTRUN -> FAIL [fdo#107725]
* igt@kms_color@pipe-a-degamma:
- shard-apl: PASS -> FAIL [fdo#104782] / [fdo#108145]
* igt@kms_cursor_crc@cursor-128x128-suspend:
- shard-apl: PASS -> FAIL [fdo#103191] / [fdo#103232]
* igt@kms_cursor_crc@cursor-256x256-dpms:
- shard-skl: NOTRUN -> FAIL [fdo#103232]
* igt@kms_cursor_crc@cursor-256x256-sliding:
- {shard-iclb}: NOTRUN -> FAIL [fdo#103232] +2
* igt@kms_cursor_crc@cursor-256x85-random:
- shard-apl: PASS -> FAIL [fdo#103232]
- shard-glk: PASS -> FAIL [fdo#103232] +3
* igt@kms_draw_crc@draw-method-xrgb-mmap-cpu-untiled:
- shard-skl: PASS -> FAIL [fdo#108472]
* igt@kms_flip@flip-vs-expired-vblank-interruptible:
- shard-skl: PASS -> FAIL [fdo#102887]
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-pwrite:
- shard-apl: PASS -> FAIL [fdo#103167]
* igt@kms_frontbuffer_tracking@fbc-1p-rte:
- shard-glk: PASS -> FAIL [fdo#103167] / [fdo#105682]
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-cur-indfb-draw-mmap-cpu:
- shard-glk: PASS -> FAIL [fdo#103167] +3
* igt@kms_frontbuffer_tracking@fbc-stridechange:
- {shard-iclb}: PASS -> FAIL [fdo#105683]
* igt@kms_frontbuffer_tracking@fbcpsr-stridechange:
- shard-skl: NOTRUN -> FAIL [fdo#105683]
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-render:
- shard-skl: NOTRUN -> FAIL [fdo#103167]
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-move:
- {shard-iclb}: PASS -> FAIL [fdo#103167] +1
* igt@kms_plane_alpha_blend@pipe-a-alpha-opaque-fb:
- shard-apl: PASS -> FAIL [fdo#108145]
* igt@kms_plane_alpha_blend@pipe-b-constant-alpha-max:
- shard-glk: PASS -> FAIL [fdo#108145]
* igt@kms_plane_alpha_blend@pipe-c-alpha-transparant-fb:
- shard-skl: NOTRUN -> FAIL [fdo#108145] +2
* igt@kms_plane_multiple@atomic-pipe-a-tiling-y:
- shard-glk: PASS -> FAIL [fdo#103166]
- {shard-iclb}: PASS -> FAIL [fdo#103166]
* igt@kms_plane_scaling@pipe-b-scaler-with-pixel-format:
- {shard-iclb}: PASS -> DMESG-WARN [fdo#107724]
* igt@kms_rmfb@rmfb-ioctl:
- {shard-iclb}: NOTRUN -> DMESG-WARN [fdo#107724] +1
* igt@kms_setmode@basic:
- shard-hsw: PASS -> FAIL [fdo#99912]
* igt@pm_rpm@debugfs-read:
- shard-skl: PASS -> INCOMPLETE [fdo#107807]
* igt@pm_rps@waitboost:
- {shard-iclb}: NOTRUN -> FAIL [fdo#102250] / [fdo#108059]
Possible fixes
* igt@drm_import_export@import-close-race-flink:
- shard-skl: TIMEOUT [fdo#108667] -> PASS
* igt@gem_softpin@noreloc-s3:
- shard-skl: INCOMPLETE [fdo#104108] / [fdo#107773] -> PASS
* igt@kms_color@pipe-a-gamma:
- shard-skl: FAIL [fdo#104782] -> PASS
* igt@kms_cursor_crc@cursor-128x42-random:
- shard-glk: FAIL [fdo#103232] -> PASS
* igt@kms_cursor_crc@cursor-64x64-sliding:
- shard-apl: FAIL [fdo#103232] -> PASS +2
* igt@kms_draw_crc@draw-method-rgb565-mmap-wc-xtiled:
- {shard-iclb}: WARN [fdo#108336] -> PASS
* igt@kms_draw_crc@draw-method-xrgb-pwrite-untiled:
- shard-skl: FAIL [fdo#108472] -> PASS
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-pwrite:
- {shard-iclb}: FAIL [fdo#103167
[Intel-gfx] [PATCH 7/7] drm: Split out drm_probe_helper.h
Having the probe helper stuff (which pretty much everyone needs) in the drm_crtc_helper.h file (which atomic drivers should never need) is confusing. Split them out. To make sure I actually achieved the goal here I went through all drivers. And indeed, all atomic drivers are now free of drm_crtc_helper.h includes. Signed-off-by: Daniel Vetter Cc: linux-arm-ker...@lists.infradead.org Cc: virtualizat...@lists.linux-foundation.org Cc: etna...@lists.freedesktop.org Cc: linux-samsung-...@vger.kernel.org Cc: intel-gfx@lists.freedesktop.org Cc: linux-media...@lists.infradead.org Cc: linux-amlo...@lists.infradead.org Cc: linux-arm-...@vger.kernel.org Cc: freedr...@lists.freedesktop.org Cc: nouv...@lists.freedesktop.org Cc: spice-de...@lists.freedesktop.org Cc: amd-...@lists.freedesktop.org Cc: linux-renesas-...@vger.kernel.org Cc: linux-rockc...@lists.infradead.org Cc: linux-st...@st-md-mailman.stormreply.com Cc: linux-te...@vger.kernel.org Cc: xen-de...@lists.xen.org --- .../gpu/drm/amd/amdgpu/amdgpu_connectors.c| 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 1 + .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 +- .../amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c | 2 +- .../display/amdgpu_dm/amdgpu_dm_services.c| 2 +- drivers/gpu/drm/arc/arcpgu_crtc.c | 2 +- drivers/gpu/drm/arc/arcpgu_drv.c | 2 +- drivers/gpu/drm/arc/arcpgu_sim.c | 2 +- drivers/gpu/drm/arm/hdlcd_crtc.c | 2 +- drivers/gpu/drm/arm/hdlcd_drv.c | 2 +- drivers/gpu/drm/arm/malidp_crtc.c | 2 +- drivers/gpu/drm/arm/malidp_drv.c | 2 +- drivers/gpu/drm/arm/malidp_mw.c | 2 +- drivers/gpu/drm/armada/armada_510.c | 2 +- drivers/gpu/drm/armada/armada_crtc.c | 2 +- drivers/gpu/drm/armada/armada_drv.c | 2 +- drivers/gpu/drm/armada/armada_fb.c| 2 +- drivers/gpu/drm/ast/ast_drv.c | 1 + drivers/gpu/drm/ast/ast_mode.c| 1 + .../gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c| 2 +- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 2 +- drivers/gpu/drm/bochs/bochs_drv.c | 1 + drivers/gpu/drm/bochs/bochs_kms.c | 1 + drivers/gpu/drm/bridge/adv7511/adv7511.h | 2 +- drivers/gpu/drm/bridge/analogix-anx78xx.c | 3 +- .../drm/bridge/analogix/analogix_dp_core.c| 2 +- drivers/gpu/drm/bridge/cdns-dsi.c | 2 +- drivers/gpu/drm/bridge/dumb-vga-dac.c | 2 +- .../bridge/megachips-stdp-ge-b850v3-fw.c | 2 +- drivers/gpu/drm/bridge/nxp-ptn3460.c | 2 +- drivers/gpu/drm/bridge/panel.c| 2 +- drivers/gpu/drm/bridge/parade-ps8622.c| 2 +- drivers/gpu/drm/bridge/sii902x.c | 2 +- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +- drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 2 +- drivers/gpu/drm/bridge/tc358764.c | 2 +- drivers/gpu/drm/bridge/tc358767.c | 2 +- drivers/gpu/drm/bridge/ti-sn65dsi86.c | 2 +- drivers/gpu/drm/bridge/ti-tfp410.c| 2 +- drivers/gpu/drm/cirrus/cirrus_drv.c | 1 + drivers/gpu/drm/cirrus/cirrus_mode.c | 1 + drivers/gpu/drm/drm_atomic_helper.c | 1 - drivers/gpu/drm/drm_dp_mst_topology.c | 2 +- drivers/gpu/drm/drm_modeset_helper.c | 2 +- drivers/gpu/drm/drm_probe_helper.c| 2 +- drivers/gpu/drm/drm_simple_kms_helper.c | 2 +- drivers/gpu/drm/etnaviv/etnaviv_drv.h | 1 - drivers/gpu/drm/exynos/exynos_dp.c| 2 +- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 2 +- drivers/gpu/drm/exynos/exynos_drm_dpi.c | 2 +- drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +- drivers/gpu/drm/exynos/exynos_drm_dsi.c | 2 +- drivers/gpu/drm/exynos/exynos_drm_fb.c| 2 +- drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 2 +- drivers/gpu/drm/exynos/exynos_drm_vidi.c | 2 +- drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c| 2 +- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 2 +- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c | 2 +- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c | 2 +- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 2 +- drivers/gpu/drm/gma500/psb_intel_drv.h| 1 + .../gpu/drm/hisilicon/hibmc/hibmc_drm_de.c| 2 +- .../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 2 +- .../gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c | 2 +- .../gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c | 2 +- drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 2 +- .../gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 2 +- .../gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 2 +- drivers/gpu/drm/i2c/ch7006_priv.h | 2 +- drivers/gpu/drm/i2c/sil164_drv.c | 2 +- drivers/gpu
[Intel-gfx] [PATCH 7/7] drm: Split out drm_probe_helper.h
Having the probe helper stuff (which pretty much everyone needs) in the drm_crtc_helper.h file (which atomic drivers should never need) is confusing. Split them out. To make sure I actually achieved the goal here I went through all drivers. And indeed, all atomic drivers are now free of drm_crtc_helper.h includes. Signed-off-by: Daniel Vetter Cc: linux-arm-ker...@lists.infradead.org Cc: virtualizat...@lists.linux-foundation.org Cc: etna...@lists.freedesktop.org Cc: linux-samsung-...@vger.kernel.org Cc: intel-gfx@lists.freedesktop.org Cc: linux-media...@lists.infradead.org Cc: linux-amlo...@lists.infradead.org Cc: linux-arm-...@vger.kernel.org Cc: freedr...@lists.freedesktop.org Cc: nouv...@lists.freedesktop.org Cc: spice-de...@lists.freedesktop.org Cc: amd-...@lists.freedesktop.org Cc: linux-renesas-...@vger.kernel.org Cc: linux-rockc...@lists.infradead.org Cc: linux-st...@st-md-mailman.stormreply.com Cc: linux-te...@vger.kernel.org Cc: xen-de...@lists.xen.org --- .../gpu/drm/amd/amdgpu/amdgpu_connectors.c| 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 1 + .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 +- .../amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c | 2 +- .../display/amdgpu_dm/amdgpu_dm_services.c| 2 +- drivers/gpu/drm/arc/arcpgu_crtc.c | 2 +- drivers/gpu/drm/arc/arcpgu_drv.c | 2 +- drivers/gpu/drm/arc/arcpgu_sim.c | 2 +- drivers/gpu/drm/arm/hdlcd_crtc.c | 2 +- drivers/gpu/drm/arm/hdlcd_drv.c | 2 +- drivers/gpu/drm/arm/malidp_crtc.c | 2 +- drivers/gpu/drm/arm/malidp_drv.c | 2 +- drivers/gpu/drm/arm/malidp_mw.c | 2 +- drivers/gpu/drm/armada/armada_510.c | 2 +- drivers/gpu/drm/armada/armada_crtc.c | 2 +- drivers/gpu/drm/armada/armada_drv.c | 2 +- drivers/gpu/drm/armada/armada_fb.c| 2 +- drivers/gpu/drm/ast/ast_drv.c | 1 + drivers/gpu/drm/ast/ast_mode.c| 1 + .../gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c| 2 +- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 2 +- drivers/gpu/drm/bochs/bochs_drv.c | 1 + drivers/gpu/drm/bochs/bochs_kms.c | 1 + drivers/gpu/drm/bridge/adv7511/adv7511.h | 2 +- drivers/gpu/drm/bridge/analogix-anx78xx.c | 3 +- .../drm/bridge/analogix/analogix_dp_core.c| 2 +- drivers/gpu/drm/bridge/cdns-dsi.c | 2 +- drivers/gpu/drm/bridge/dumb-vga-dac.c | 2 +- .../bridge/megachips-stdp-ge-b850v3-fw.c | 2 +- drivers/gpu/drm/bridge/nxp-ptn3460.c | 2 +- drivers/gpu/drm/bridge/panel.c| 2 +- drivers/gpu/drm/bridge/parade-ps8622.c| 2 +- drivers/gpu/drm/bridge/sii902x.c | 2 +- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +- drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 2 +- drivers/gpu/drm/bridge/tc358764.c | 2 +- drivers/gpu/drm/bridge/tc358767.c | 2 +- drivers/gpu/drm/bridge/ti-sn65dsi86.c | 2 +- drivers/gpu/drm/bridge/ti-tfp410.c| 2 +- drivers/gpu/drm/cirrus/cirrus_drv.c | 1 + drivers/gpu/drm/cirrus/cirrus_mode.c | 1 + drivers/gpu/drm/drm_atomic_helper.c | 1 - drivers/gpu/drm/drm_dp_mst_topology.c | 2 +- drivers/gpu/drm/drm_modeset_helper.c | 2 +- drivers/gpu/drm/drm_probe_helper.c| 2 +- drivers/gpu/drm/drm_simple_kms_helper.c | 2 +- drivers/gpu/drm/etnaviv/etnaviv_drv.h | 1 - drivers/gpu/drm/exynos/exynos_dp.c| 2 +- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 2 +- drivers/gpu/drm/exynos/exynos_drm_dpi.c | 2 +- drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +- drivers/gpu/drm/exynos/exynos_drm_dsi.c | 2 +- drivers/gpu/drm/exynos/exynos_drm_fb.c| 2 +- drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 2 +- drivers/gpu/drm/exynos/exynos_drm_vidi.c | 2 +- drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c| 2 +- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 2 +- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c | 2 +- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c | 2 +- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 2 +- drivers/gpu/drm/gma500/psb_intel_drv.h| 1 + .../gpu/drm/hisilicon/hibmc/hibmc_drm_de.c| 2 +- .../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 2 +- .../gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c | 2 +- .../gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c | 2 +- drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 2 +- .../gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 2 +- .../gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 2 +- drivers/gpu/drm/i2c/ch7006_priv.h | 2 +- drivers/gpu/drm/i2c/sil164_drv.c | 2 +- drivers/gpu
[Intel-gfx] [RFT i-g-t 1/2] tests/gem_shrink: Background, direct and OOM shrinker plus userptr tests
From: Tvrtko Ursulin
...
Signed-off-by: Tvrtko Ursulin
---
lib/igt_core.c | 19 +++
lib/igt_core.h | 1 +
tests/i915/gem_shrink.c | 348
3 files changed, 368 insertions(+)
diff --git a/lib/igt_core.c b/lib/igt_core.c
index 64883d6402af..a22c4b077d85 100644
--- a/lib/igt_core.c
+++ b/lib/igt_core.c
@@ -1680,6 +1680,25 @@ void igt_stop_helper(struct igt_helper_process *proc)
assert(helper_was_alive(proc, status));
}
+/**
+ * igt_try_stop_helper:
+ * @proc: #igt_helper_process structure
+ *
+ * Terminates a helper process if it is still running and returns true, or
false
+ * if the process wasn't running.
+ */
+bool igt_try_stop_helper(struct igt_helper_process *proc)
+{
+ int status;
+
+ /* failure here means the pid is already dead and so waiting is safe */
+ kill(proc->pid, proc->use_SIGKILL ? SIGKILL : SIGTERM);
+
+ status = igt_wait_helper(proc);
+
+ return helper_was_alive(proc, status);
+}
+
static void children_exit_handler(int sig)
{
int status;
diff --git a/lib/igt_core.h b/lib/igt_core.h
index 6f8c3852a686..ed5ceebf1205 100644
--- a/lib/igt_core.h
+++ b/lib/igt_core.h
@@ -795,6 +795,7 @@ bool __igt_fork_helper(struct igt_helper_process *proc);
for (; __igt_fork_helper(proc); exit(0))
int igt_wait_helper(struct igt_helper_process *proc);
void igt_stop_helper(struct igt_helper_process *proc);
+bool igt_try_stop_helper(struct igt_helper_process *proc);
/* exit handler code */
diff --git a/tests/i915/gem_shrink.c b/tests/i915/gem_shrink.c
index c8e05814ee70..145f9d35e584 100644
--- a/tests/i915/gem_shrink.c
+++ b/tests/i915/gem_shrink.c
@@ -26,6 +26,10 @@
*
* Exercise the shrinker by overallocating GEM objects
*/
+#include
+#include
+#include
+#include
#include "igt.h"
#include "igt_gt.h"
@@ -366,6 +370,329 @@ static void reclaim(unsigned engine, int timeout)
close(fd);
}
+static unsigned long get_meminfo(const char *info, const char *tag)
+{
+ const char *str;
+ unsigned long val;
+
+ str = strstr(info, tag);
+ if (str && sscanf(str + strlen(tag), " %lu", &val) == 1)
+ return val >> 10;
+
+ igt_warn("Unrecognised /proc/meminfo field: '%s'\n", tag);
+ return 0;
+}
+
+static unsigned long get_avail_ram_mb(void)
+{
+ int fd;
+ int ret;
+ char buf[4096];
+ unsigned long ram;
+
+ fd = open("/proc/meminfo", O_RDONLY);
+ igt_assert_fd(fd);
+
+ ret = read(fd, buf, sizeof(buf));
+ igt_assert(ret >= 0);
+
+ close(fd);
+
+ ram = get_meminfo(buf, "MemAvailable:");
+ ram += get_meminfo(buf, "Buffers:");
+ ram += get_meminfo(buf, "Cached:");
+ ram += get_meminfo(buf, "SwapCached:");
+
+ return ram;
+}
+
+struct test {
+#define TEST_BO(1)
+#define TEST_USERPTR (2)
+ unsigned int flags;
+ int fd;
+};
+
+static uint32_t __get_pages(int fd, unsigned long alloc)
+{
+ uint32_t handle = gem_create(fd, alloc);
+
+ gem_set_domain(fd, handle, I915_GEM_DOMAIN_GTT, 0);
+ gem_madvise(fd, handle, I915_MADV_DONTNEED);
+
+ return handle;
+}
+
+struct test_obj {
+ void *ptr;
+ uint32_t handle;
+};
+
+#define PAGE_SIZE 4096
+static void
+__get_userptr(int fd, struct test_obj *obj, unsigned long sz)
+{
+ struct local_i915_gem_userptr userptr = { };
+ void *ptr;
+
+ igt_assert_eq(sz & 4095, 0);
+
+ ptr = mmap(NULL, sz, PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
+ assert(ptr != MAP_FAILED);
+
+ for (size_t page = 0; page < sz; page += PAGE_SIZE)
+ *(volatile uint32_t *)((unsigned char *)ptr + page) = 0;
+
+ userptr.user_size = sz;
+ userptr.user_ptr = to_user_pointer(ptr);
+ do_ioctl(fd, LOCAL_IOCTL_I915_GEM_USERPTR, &userptr);
+
+ gem_set_domain(fd, userptr.handle, I915_GEM_DOMAIN_GTT, 0);
+ gem_madvise(fd, userptr.handle, I915_MADV_DONTNEED);
+
+ obj->ptr = ptr;
+ obj->handle = userptr.handle;
+}
+
+static void *mempressure(void *arg)
+{
+ struct test_obj *list = NULL;
+ struct test *test = arg;
+ const unsigned int sz_mb = 2;
+ const unsigned int sz = sz_mb << 20;
+ unsigned int n = 0, max = 0;
+ unsigned int blocks;
+
+ igt_debug("mempressure flags=%x\n", test->flags);
+
+ for (;;) {
+ unsigned long ram_mb = get_avail_ram_mb();
+
+ if (!list) {
+ blocks = ram_mb / sz_mb;
+ list = calloc(blocks, sizeof(*list));
+ igt_assert(list);
+ } else if (ram_mb < 256) {
+ blocks = max + 1;
+ }
+
+ if (list[n].ptr || list[n].handle) {
+ if (test->flags & TEST_USERPTR) {
+ munmap(list[n].ptr, sz);
+ gem_close(test
[Intel-gfx] [RFT i-g-t 2/2] intel-ci: Unblacklist the new tests??
From: Tvrtko Ursulin Signed-off-by: Tvrtko Ursulin --- tests/intel-ci/blacklist.txt | 1 + tests/intel-ci/fast-feedback.testlist | 3 +++ 2 files changed, 4 insertions(+) diff --git a/tests/intel-ci/blacklist.txt b/tests/intel-ci/blacklist.txt index 73d127603d28..8083efc407d4 100644 --- a/tests/intel-ci/blacklist.txt +++ b/tests/intel-ci/blacklist.txt @@ -60,6 +60,7 @@ igt@gem_ring_sync_copy(@.*)? igt@gem_ring_sync_loop(@.*)? igt@gem_seqno_wrap(@.*)? igt@gem_shrink@(?!reclaim$).* +igt@gem_shrink@(?!two-reclaims-and-oom).* igt@gem_softpin@.*(hang|S4).* igt@gem_spin_batch(@.*)? igt@gem_stolen@.*hibernate.* diff --git a/tests/intel-ci/fast-feedback.testlist b/tests/intel-ci/fast-feedback.testlist index 6d42792c67f7..32c1a3266553 100644 --- a/tests/intel-ci/fast-feedback.testlist +++ b/tests/intel-ci/fast-feedback.testlist @@ -124,6 +124,9 @@ igt@gem_ringfill@basic-default igt@gem_ringfill@basic-default-interruptible igt@gem_ringfill@basic-default-forked igt@gem_ringfill@basic-default-fd +igt@gem_shrink@two-reclaims-and-oom +igt@gem_shrink@two-reclaims-and-oom-userptr +igt@gem_shrink@two-reclaims-and-oom-both igt@gem_sync@basic-all igt@gem_sync@basic-each igt@gem_sync@basic-many-each -- 2.19.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/7] drm/xen: Don't set the dpms hook
On 12/10/18 12:03 PM, Daniel Vetter wrote:
Doesn't do anything for atomic.
Signed-off-by: Daniel Vetter
Cc: Oleksandr Andrushchenko
Cc: xen-de...@lists.xen.org
---
drivers/gpu/drm/xen/xen_drm_front_conn.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/xen/xen_drm_front_conn.c
b/drivers/gpu/drm/xen/xen_drm_front_conn.c
index c91ae532fa55..54af2669b1b3 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_conn.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_conn.c
@@ -89,7 +89,6 @@ static const struct drm_connector_helper_funcs
connector_helper_funcs = {
};
static const struct drm_connector_funcs connector_funcs = {
- .dpms = drm_helper_connector_dpms,
.fill_modes = drm_helper_probe_single_connector_modes,
.destroy = drm_connector_cleanup,
.reset = drm_atomic_helper_connector_reset,
Reviewed-by: Oleksandr Andrushchenko
Thank you,
Oleksandr
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/7] drm: Split out drm_probe_helper.h
On Mon, Dec 10, 2018 at 11:11:33AM +0100, Daniel Vetter wrote: > Having the probe helper stuff (which pretty much everyone needs) in > the drm_crtc_helper.h file (which atomic drivers should never need) is > confusing. Split them out. > > To make sure I actually achieved the goal here I went through all > drivers. And indeed, all atomic drivers are now free of > drm_crtc_helper.h includes. > > Signed-off-by: Daniel Vetter > Cc: linux-arm-ker...@lists.infradead.org > Cc: virtualizat...@lists.linux-foundation.org > Cc: etna...@lists.freedesktop.org > Cc: linux-samsung-...@vger.kernel.org > Cc: intel-gfx@lists.freedesktop.org > Cc: linux-media...@lists.infradead.org > Cc: linux-amlo...@lists.infradead.org > Cc: linux-arm-...@vger.kernel.org > Cc: freedr...@lists.freedesktop.org > Cc: nouv...@lists.freedesktop.org > Cc: spice-de...@lists.freedesktop.org > Cc: amd-...@lists.freedesktop.org > Cc: linux-renesas-...@vger.kernel.org > Cc: linux-rockc...@lists.infradead.org > Cc: linux-st...@st-md-mailman.stormreply.com > Cc: linux-te...@vger.kernel.org > Cc: xen-de...@lists.xen.org > --- > .../gpu/drm/amd/amdgpu/amdgpu_connectors.c| 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 1 + > .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 +- > .../amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c | 2 +- > .../display/amdgpu_dm/amdgpu_dm_services.c| 2 +- > drivers/gpu/drm/arc/arcpgu_crtc.c | 2 +- > drivers/gpu/drm/arc/arcpgu_drv.c | 2 +- > drivers/gpu/drm/arc/arcpgu_sim.c | 2 +- > drivers/gpu/drm/arm/hdlcd_crtc.c | 2 +- > drivers/gpu/drm/arm/hdlcd_drv.c | 2 +- > drivers/gpu/drm/arm/malidp_crtc.c | 2 +- > drivers/gpu/drm/arm/malidp_drv.c | 2 +- > drivers/gpu/drm/arm/malidp_mw.c | 2 +- > drivers/gpu/drm/armada/armada_510.c | 2 +- > drivers/gpu/drm/armada/armada_crtc.c | 2 +- > drivers/gpu/drm/armada/armada_drv.c | 2 +- > drivers/gpu/drm/armada/armada_fb.c| 2 +- > drivers/gpu/drm/ast/ast_drv.c | 1 + > drivers/gpu/drm/ast/ast_mode.c| 1 + > .../gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c| 2 +- > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 2 +- > drivers/gpu/drm/bochs/bochs_drv.c | 1 + > drivers/gpu/drm/bochs/bochs_kms.c | 1 + > drivers/gpu/drm/bridge/adv7511/adv7511.h | 2 +- > drivers/gpu/drm/bridge/analogix-anx78xx.c | 3 +- > .../drm/bridge/analogix/analogix_dp_core.c| 2 +- > drivers/gpu/drm/bridge/cdns-dsi.c | 2 +- > drivers/gpu/drm/bridge/dumb-vga-dac.c | 2 +- > .../bridge/megachips-stdp-ge-b850v3-fw.c | 2 +- > drivers/gpu/drm/bridge/nxp-ptn3460.c | 2 +- > drivers/gpu/drm/bridge/panel.c| 2 +- > drivers/gpu/drm/bridge/parade-ps8622.c| 2 +- > drivers/gpu/drm/bridge/sii902x.c | 2 +- > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +- > drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 2 +- > drivers/gpu/drm/bridge/tc358764.c | 2 +- > drivers/gpu/drm/bridge/tc358767.c | 2 +- > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 2 +- > drivers/gpu/drm/bridge/ti-tfp410.c| 2 +- > drivers/gpu/drm/cirrus/cirrus_drv.c | 1 + > drivers/gpu/drm/cirrus/cirrus_mode.c | 1 + > drivers/gpu/drm/drm_atomic_helper.c | 1 - > drivers/gpu/drm/drm_dp_mst_topology.c | 2 +- > drivers/gpu/drm/drm_modeset_helper.c | 2 +- > drivers/gpu/drm/drm_probe_helper.c| 2 +- > drivers/gpu/drm/drm_simple_kms_helper.c | 2 +- > drivers/gpu/drm/etnaviv/etnaviv_drv.h | 1 - > drivers/gpu/drm/exynos/exynos_dp.c| 2 +- > drivers/gpu/drm/exynos/exynos_drm_crtc.c | 2 +- > drivers/gpu/drm/exynos/exynos_drm_dpi.c | 2 +- > drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +- > drivers/gpu/drm/exynos/exynos_drm_dsi.c | 2 +- > drivers/gpu/drm/exynos/exynos_drm_fb.c| 2 +- > drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 2 +- > drivers/gpu/drm/exynos/exynos_drm_vidi.c | 2 +- > drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +- > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c| 2 +- > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 2 +- > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c | 2 +- > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c | 2 +- > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 2 +- > drivers/gpu/drm/gma500/psb_intel_drv.h| 1 + > .../gpu/drm/hisilicon/hibmc/hibmc_drm_de.c| 2 +- > .../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 2 +- > .../gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c | 2 +- > .../gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c | 2 +- > drivers/gpu/drm/hisilicon/kirin
[Intel-gfx] [PATCH 1/4] mm: Check if mmu notifier callbacks are allowed to fail
Just a bit of paranoia, since if we start pushing this deep into
callchains it's hard to spot all places where an mmu notifier
implementation might fail when it's not allowed to.
Inspired by some confusion we had discussing i915 mmu notifiers and
whether we could use the newly-introduced return value to handle some
corner cases. Until we realized that these are only for when a task
has been killed by the oom reaper.
An alternative approach would be to split the callback into two
versions, one with the int return value, and the other with void
return value like in older kernels. But that's a lot more churn for
fairly little gain I think.
Summary from the m-l discussion on why we want something at warning
level: This allows automated tooling in CI to catch bugs without
humans having to look at everything. If we just upgrade the existing
pr_info to a pr_warn, then we'll have false positives. And as-is, no
one will ever spot the problem since it's lost in the massive amounts
of overall dmesg noise.
v2: Drop the full WARN_ON backtrace in favour of just a pr_warn for
the problematic case (Michal Hocko).
Cc: Andrew Morton
Cc: Michal Hocko
Cc: "Christian König"
Cc: David Rientjes
Cc: Daniel Vetter
Cc: "Jérôme Glisse"
Cc: linux...@kvack.org
Cc: Paolo Bonzini
Signed-off-by: Daniel Vetter
---
mm/mmu_notifier.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c
index 5119ff846769..ccc22f21b735 100644
--- a/mm/mmu_notifier.c
+++ b/mm/mmu_notifier.c
@@ -190,6 +190,9 @@ int __mmu_notifier_invalidate_range_start(struct mm_struct
*mm,
pr_info("%pS callback failed with %d in
%sblockable context.\n",
mn->ops->invalidate_range_start, _ret,
!blockable ? "non-" : "");
+ if (blockable)
+ pr_warn("%pS callback failure not
allowed\n",
+
mn->ops->invalidate_range_start);
ret = _ret;
}
}
--
2.20.0.rc1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] kernel.h: Add non_block_start/end()
In some special cases we must not block, but there's not a
spinlock, preempt-off, irqs-off or similar critical section already
that arms the might_sleep() debug checks. Add a non_block_start/end()
pair to annotate these.
This will be used in the oom paths of mmu-notifiers, where blocking is
not allowed to make sure there's forward progress.
Suggested by Michal Hocko.
Cc: Andrew Morton
Cc: Michal Hocko
Cc: David Rientjes
Cc: "Christian König"
Cc: Daniel Vetter
Cc: "Jérôme Glisse"
Cc: linux...@kvack.org
Signed-off-by: Daniel Vetter
---
include/linux/kernel.h | 10 +-
include/linux/sched.h | 4
kernel/sched/core.c| 6 +++---
3 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index d6aac75b51ba..c2cf31515b3d 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -251,7 +251,9 @@ extern int _cond_resched(void);
* might_sleep - annotation for functions that can sleep
*
* this macro will print a stack trace if it is executed in an atomic
- * context (spinlock, irq-handler, ...).
+ * context (spinlock, irq-handler, ...). Additional sections where blocking is
+ * not allowed can be annotated with non_block_start() and non_block_end()
+ * pairs.
*
* This is a useful debugging help to be able to catch problems early and not
* be bitten later when the calling function happens to sleep when it is not
@@ -260,6 +262,10 @@ extern int _cond_resched(void);
# define might_sleep() \
do { __might_sleep(__FILE__, __LINE__, 0); might_resched(); } while (0)
# define sched_annotate_sleep()(current->task_state_change = 0)
+# define non_block_start() \
+ do { current->non_block_count++; } while (0)
+# define non_block_end() \
+ do { WARN_ON(current->non_block_count-- == 0); } while (0)
#else
static inline void ___might_sleep(const char *file, int line,
int preempt_offset) { }
@@ -267,6 +273,8 @@ extern int _cond_resched(void);
int preempt_offset) { }
# define might_sleep() do { might_resched(); } while (0)
# define sched_annotate_sleep() do { } while (0)
+# define non_block_start() do { } while (0)
+# define non_block_end() do { } while (0)
#endif
#define might_sleep_if(cond) do { if (cond) might_sleep(); } while (0)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index ecffd4e37453..41249dbf8f27 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -916,6 +916,10 @@ struct task_struct {
struct mutex_waiter *blocked_on;
#endif
+#ifdef CONFIG_DEBUG_ATOMIC_SLEEP
+ int non_block_count;
+#endif
+
#ifdef CONFIG_TRACE_IRQFLAGS
unsigned intirq_events;
unsigned long hardirq_enable_ip;
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 6fedf3a98581..969d7a71f30c 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -6113,7 +6113,7 @@ void ___might_sleep(const char *file, int line, int
preempt_offset)
rcu_sleep_check();
if ((preempt_count_equals(preempt_offset) && !irqs_disabled() &&
-!is_idle_task(current)) ||
+!is_idle_task(current) && !current->non_block_count) ||
system_state == SYSTEM_BOOTING || system_state > SYSTEM_RUNNING ||
oops_in_progress)
return;
@@ -6129,8 +6129,8 @@ void ___might_sleep(const char *file, int line, int
preempt_offset)
"BUG: sleeping function called from invalid context at %s:%d\n",
file, line);
printk(KERN_ERR
- "in_atomic(): %d, irqs_disabled(): %d, pid: %d, name: %s\n",
- in_atomic(), irqs_disabled(),
+ "in_atomic(): %d, irqs_disabled(): %d, non_block: %d, pid: %d,
name: %s\n",
+ in_atomic(), irqs_disabled(), current->non_block_count,
current->pid, current->comm);
if (task_stack_end_corrupted(current))
--
2.20.0.rc1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] mm, notifier: Catch sleeping/blocking for !blockable
We need to make sure implementations don't cheat and don't have a
possible schedule/blocking point deeply burried where review can't
catch it.
I'm not sure whether this is the best way to make sure all the
might_sleep() callsites trigger, and it's a bit ugly in the code flow.
But it gets the job done.
Inspired by an i915 patch series which did exactly that, because the
rules haven't been entirely clear to us.
v2: Use the shiny new non_block_start/end annotations instead of
abusing preempt_disable/enable.
Cc: Andrew Morton
Cc: Michal Hocko
Cc: David Rientjes
Cc: "Christian König"
Cc: Daniel Vetter
Cc: "Jérôme Glisse"
Cc: linux...@kvack.org
Signed-off-by: Daniel Vetter
---
mm/mmu_notifier.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c
index ccc22f21b735..a50ed7d1ecef 100644
--- a/mm/mmu_notifier.c
+++ b/mm/mmu_notifier.c
@@ -185,7 +185,13 @@ int __mmu_notifier_invalidate_range_start(struct mm_struct
*mm,
id = srcu_read_lock(&srcu);
hlist_for_each_entry_rcu(mn, &mm->mmu_notifier_mm->list, hlist) {
if (mn->ops->invalidate_range_start) {
- int _ret = mn->ops->invalidate_range_start(mn, mm,
start, end, blockable);
+ int _ret;
+
+ if (!blockable)
+ non_block_start();
+ _ret = mn->ops->invalidate_range_start(mn, mm, start,
end, blockable);
+ if (!blockable)
+ non_block_end();
if (_ret) {
pr_info("%pS callback failed with %d in
%sblockable context.\n",
mn->ops->invalidate_range_start, _ret,
--
2.20.0.rc1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/4] mmu notifier debug checks v2
Hi all, Here's v2 of my mmu notifier debug checks. I think the last two patches could probably be extended to all callbacks, but I'm not really clear on the exact rules. But happy to extend them if there's interest. This stuff helps us catch issues in the i915 mmu notifier implementation. Thanks, Daniel Daniel Vetter (4): mm: Check if mmu notifier callbacks are allowed to fail kernel.h: Add non_block_start/end() mm, notifier: Catch sleeping/blocking for !blockable mm, notifier: Add a lockdep map for invalidate_range_start include/linux/kernel.h | 10 +- include/linux/mmu_notifier.h | 6 ++ include/linux/sched.h| 4 kernel/sched/core.c | 6 +++--- mm/mmu_notifier.c| 18 +- 5 files changed, 39 insertions(+), 5 deletions(-) -- 2.20.0.rc1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/4] mm, notifier: Add a lockdep map for invalidate_range_start
This is a similar idea to the fs_reclaim fake lockdep lock. It's
fairly easy to provoke a specific notifier to be run on a specific
range: Just prep it, and then munmap() it.
A bit harder, but still doable, is to provoke the mmu notifiers for
all the various callchains that might lead to them. But both at the
same time is really hard to reliable hit, especially when you want to
exercise paths like direct reclaim or compaction, where it's not
easy to control what exactly will be unmapped.
By introducing a lockdep map to tie them all together we allow lockdep
to see a lot more dependencies, without having to actually hit them
in a single challchain while testing.
Aside: Since I typed this to test i915 mmu notifiers I've only rolled
this out for the invaliate_range_start callback. If there's
interest, we should probably roll this out to all of them. But my
undestanding of core mm is seriously lacking, and I'm not clear on
whether we need a lockdep map for each callback, or whether some can
be shared.
v2: Use lock_map_acquire/release() like fs_reclaim, to avoid confusion
with this being a real mutex (Chris Wilson).
Cc: Chris Wilson
Cc: Andrew Morton
Cc: David Rientjes
Cc: "Jérôme Glisse"
Cc: Michal Hocko
Cc: "Christian König"
Cc: Greg Kroah-Hartman
Cc: Daniel Vetter
Cc: Mike Rapoport
Cc: linux...@kvack.org
Signed-off-by: Daniel Vetter
---
include/linux/mmu_notifier.h | 6 ++
mm/mmu_notifier.c| 7 +++
2 files changed, 13 insertions(+)
diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h
index 9893a6432adf..19be442606c6 100644
--- a/include/linux/mmu_notifier.h
+++ b/include/linux/mmu_notifier.h
@@ -12,6 +12,10 @@ struct mmu_notifier_ops;
#ifdef CONFIG_MMU_NOTIFIER
+#ifdef CONFIG_LOCKDEP
+extern struct lockdep_map __mmu_notifier_invalidate_range_start_map;
+#endif
+
/*
* The mmu notifier_mm structure is allocated and installed in
* mm->mmu_notifier_mm inside the mm_take_all_locks() protected
@@ -267,8 +271,10 @@ static inline void mmu_notifier_change_pte(struct
mm_struct *mm,
static inline void mmu_notifier_invalidate_range_start(struct mm_struct *mm,
unsigned long start, unsigned long end)
{
+ lock_map_acquire(&__mmu_notifier_invalidate_range_start_map);
if (mm_has_notifiers(mm))
__mmu_notifier_invalidate_range_start(mm, start, end, true);
+ lock_map_release(&__mmu_notifier_invalidate_range_start_map);
}
static inline int mmu_notifier_invalidate_range_start_nonblock(struct
mm_struct *mm,
diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c
index a50ed7d1ecef..c91d58fe388b 100644
--- a/mm/mmu_notifier.c
+++ b/mm/mmu_notifier.c
@@ -23,6 +23,13 @@
/* global SRCU for all MMs */
DEFINE_STATIC_SRCU(srcu);
+#ifdef CONFIG_LOCKDEP
+struct lockdep_map __mmu_notifier_invalidate_range_start_map = {
+ .name = "mmu_notifier_invalidate_range_start"
+};
+EXPORT_SYMBOL_GPL(__mmu_notifier_invalidate_range_start_map);
+#endif
+
/*
* This function allows mmu_notifier::release callback to delay a call to
* a function that will free appropriate resources. The function must be
--
2.20.0.rc1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] igt: add timeline test cases
On 2018-12-07 11:01 a.m., Chunming Zhou wrote: > Signed-off-by: Chunming Zhou > --- > include/drm-uapi/drm.h | 33 ++ > lib/igt_syncobj.c| 204 +++ > lib/igt_syncobj.h| 19 + > tests/gem_ctx_bad_exec | Bin 0 -> 1284384 bytes Please run git rm tests/gem_ctx_bad_exec and re-send the patch. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] mm: Check if mmu notifier callbacks are allowed to fail
Patches #1 and #3 are Reviewed-by: Christian König
Patch #2 is Acked-by: Christian König because
I can't judge if adding the counter in the thread structure is actually
a good idea.
In patch #4 I honestly don't understand at all how this stuff works, so
no-comment from my side on this.
Christian.
Am 10.12.18 um 11:36 schrieb Daniel Vetter:
> Just a bit of paranoia, since if we start pushing this deep into
> callchains it's hard to spot all places where an mmu notifier
> implementation might fail when it's not allowed to.
>
> Inspired by some confusion we had discussing i915 mmu notifiers and
> whether we could use the newly-introduced return value to handle some
> corner cases. Until we realized that these are only for when a task
> has been killed by the oom reaper.
>
> An alternative approach would be to split the callback into two
> versions, one with the int return value, and the other with void
> return value like in older kernels. But that's a lot more churn for
> fairly little gain I think.
>
> Summary from the m-l discussion on why we want something at warning
> level: This allows automated tooling in CI to catch bugs without
> humans having to look at everything. If we just upgrade the existing
> pr_info to a pr_warn, then we'll have false positives. And as-is, no
> one will ever spot the problem since it's lost in the massive amounts
> of overall dmesg noise.
>
> v2: Drop the full WARN_ON backtrace in favour of just a pr_warn for
> the problematic case (Michal Hocko).
>
> Cc: Andrew Morton
> Cc: Michal Hocko
> Cc: "Christian König"
> Cc: David Rientjes
> Cc: Daniel Vetter
> Cc: "Jérôme Glisse"
> Cc: linux...@kvack.org
> Cc: Paolo Bonzini
> Signed-off-by: Daniel Vetter
> ---
> mm/mmu_notifier.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c
> index 5119ff846769..ccc22f21b735 100644
> --- a/mm/mmu_notifier.c
> +++ b/mm/mmu_notifier.c
> @@ -190,6 +190,9 @@ int __mmu_notifier_invalidate_range_start(struct
> mm_struct *mm,
> pr_info("%pS callback failed with %d in
> %sblockable context.\n",
>
> mn->ops->invalidate_range_start, _ret,
> !blockable ? "non-" : "");
> + if (blockable)
> + pr_warn("%pS callback failure not
> allowed\n",
> +
> mn->ops->invalidate_range_start);
> ret = _ret;
> }
> }
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/7] drm: Split out drm_probe_helper.h
Le lun. 10 déc. 2018 à 11:24, Thierry Reding a écrit : > > On Mon, Dec 10, 2018 at 11:11:33AM +0100, Daniel Vetter wrote: > > Having the probe helper stuff (which pretty much everyone needs) in > > the drm_crtc_helper.h file (which atomic drivers should never need) is > > confusing. Split them out. > > > > To make sure I actually achieved the goal here I went through all > > drivers. And indeed, all atomic drivers are now free of > > drm_crtc_helper.h includes. > > I have difficulties to apply this with git on top of drm-misc-next. It is because of that I got errors (encoder and connector types not found) while compiling adv7511_audio.c and exynos_dp.c ? Benjamin > > Signed-off-by: Daniel Vetter > > Cc: linux-arm-ker...@lists.infradead.org > > Cc: virtualizat...@lists.linux-foundation.org > > Cc: etna...@lists.freedesktop.org > > Cc: linux-samsung-...@vger.kernel.org > > Cc: intel-gfx@lists.freedesktop.org > > Cc: linux-media...@lists.infradead.org > > Cc: linux-amlo...@lists.infradead.org > > Cc: linux-arm-...@vger.kernel.org > > Cc: freedr...@lists.freedesktop.org > > Cc: nouv...@lists.freedesktop.org > > Cc: spice-de...@lists.freedesktop.org > > Cc: amd-...@lists.freedesktop.org > > Cc: linux-renesas-...@vger.kernel.org > > Cc: linux-rockc...@lists.infradead.org > > Cc: linux-st...@st-md-mailman.stormreply.com > > Cc: linux-te...@vger.kernel.org > > Cc: xen-de...@lists.xen.org > > --- > > .../gpu/drm/amd/amdgpu/amdgpu_connectors.c| 2 +- > > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 2 +- > > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +- > > drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 1 + > > .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 +- > > .../amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c | 2 +- > > .../display/amdgpu_dm/amdgpu_dm_services.c| 2 +- > > drivers/gpu/drm/arc/arcpgu_crtc.c | 2 +- > > drivers/gpu/drm/arc/arcpgu_drv.c | 2 +- > > drivers/gpu/drm/arc/arcpgu_sim.c | 2 +- > > drivers/gpu/drm/arm/hdlcd_crtc.c | 2 +- > > drivers/gpu/drm/arm/hdlcd_drv.c | 2 +- > > drivers/gpu/drm/arm/malidp_crtc.c | 2 +- > > drivers/gpu/drm/arm/malidp_drv.c | 2 +- > > drivers/gpu/drm/arm/malidp_mw.c | 2 +- > > drivers/gpu/drm/armada/armada_510.c | 2 +- > > drivers/gpu/drm/armada/armada_crtc.c | 2 +- > > drivers/gpu/drm/armada/armada_drv.c | 2 +- > > drivers/gpu/drm/armada/armada_fb.c| 2 +- > > drivers/gpu/drm/ast/ast_drv.c | 1 + > > drivers/gpu/drm/ast/ast_mode.c| 1 + > > .../gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c| 2 +- > > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 2 +- > > drivers/gpu/drm/bochs/bochs_drv.c | 1 + > > drivers/gpu/drm/bochs/bochs_kms.c | 1 + > > drivers/gpu/drm/bridge/adv7511/adv7511.h | 2 +- > > drivers/gpu/drm/bridge/analogix-anx78xx.c | 3 +- > > .../drm/bridge/analogix/analogix_dp_core.c| 2 +- > > drivers/gpu/drm/bridge/cdns-dsi.c | 2 +- > > drivers/gpu/drm/bridge/dumb-vga-dac.c | 2 +- > > .../bridge/megachips-stdp-ge-b850v3-fw.c | 2 +- > > drivers/gpu/drm/bridge/nxp-ptn3460.c | 2 +- > > drivers/gpu/drm/bridge/panel.c| 2 +- > > drivers/gpu/drm/bridge/parade-ps8622.c| 2 +- > > drivers/gpu/drm/bridge/sii902x.c | 2 +- > > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +- > > drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 2 +- > > drivers/gpu/drm/bridge/tc358764.c | 2 +- > > drivers/gpu/drm/bridge/tc358767.c | 2 +- > > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 2 +- > > drivers/gpu/drm/bridge/ti-tfp410.c| 2 +- > > drivers/gpu/drm/cirrus/cirrus_drv.c | 1 + > > drivers/gpu/drm/cirrus/cirrus_mode.c | 1 + > > drivers/gpu/drm/drm_atomic_helper.c | 1 - > > drivers/gpu/drm/drm_dp_mst_topology.c | 2 +- > > drivers/gpu/drm/drm_modeset_helper.c | 2 +- > > drivers/gpu/drm/drm_probe_helper.c| 2 +- > > drivers/gpu/drm/drm_simple_kms_helper.c | 2 +- > > drivers/gpu/drm/etnaviv/etnaviv_drv.h | 1 - > > drivers/gpu/drm/exynos/exynos_dp.c| 2 +- > > drivers/gpu/drm/exynos/exynos_drm_crtc.c | 2 +- > > drivers/gpu/drm/exynos/exynos_drm_dpi.c | 2 +- > > drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +- > > drivers/gpu/drm/exynos/exynos_drm_dsi.c | 2 +- > > drivers/gpu/drm/exynos/exynos_drm_fb.c| 2 +- > > drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 2 +- > > drivers/gpu/drm/exynos/exynos_drm_vidi.c | 2 +- > > drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +- > > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c| 2 +- > > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 2 +- > > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c |
Re: [Intel-gfx] [PATCH 5/7] drm/i915: Return immediately if trylock fails for direct-reclaim
On 04/12/2018 14:15, Chris Wilson wrote:
Ignore trying to shrink from i915 if we fail to acquire the struct_mutex
in the shrinker while performing direct-reclaim. The trade-off being
(much) lower latency for non-i915 clients at an increased risk of being
unable to obtain a page from direct-reclaim without hitting the
oom-notifier. The proviso being that we still keep trying to hard
obtain the lock for oom so that we can reap under heavy memory pressure.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h | 4 ++--
drivers/gpu/drm/i915/i915_gem_shrinker.c | 24 +++-
2 files changed, 13 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c5f01964f0fb..1cad218b71d3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2916,9 +2916,9 @@ i915_gem_object_unpin_pages(struct drm_i915_gem_object
*obj)
__i915_gem_object_unpin_pages(obj);
}
-enum i915_mm_subclass { /* lockdep subclass for obj->mm.lock */
+enum i915_mm_subclass { /* lockdep subclass for obj->mm.lock/struct_mutex */
I915_MM_NORMAL = 0,
- I915_MM_SHRINKER
+ I915_MM_SHRINKER /* called "recursively" from direct-reclaim-esque */
};
void __i915_gem_object_put_pages(struct drm_i915_gem_object *obj,
diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c
b/drivers/gpu/drm/i915/i915_gem_shrinker.c
index ea90d3a0d511..d461f458f4af 100644
--- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
@@ -36,7 +36,9 @@
#include "i915_drv.h"
#include "i915_trace.h"
-static bool shrinker_lock(struct drm_i915_private *i915, bool *unlock)
+static bool shrinker_lock(struct drm_i915_private *i915,
+ unsigned int flags,
+ bool *unlock)
{
switch (mutex_trylock_recursive(&i915->drm.struct_mutex)) {
case MUTEX_TRYLOCK_RECURSIVE:
@@ -45,15 +47,11 @@ static bool shrinker_lock(struct drm_i915_private *i915,
bool *unlock)
case MUTEX_TRYLOCK_FAILED:
*unlock = false;
- preempt_disable();
- do {
- cpu_relax();
- if (mutex_trylock(&i915->drm.struct_mutex)) {
- *unlock = true;
- break;
- }
- } while (!need_resched());
- preempt_enable();
+ if (flags & I915_SHRINK_ACTIVE) {
+ mutex_lock_nested(&i915->drm.struct_mutex,
+ I915_MM_SHRINKER);
Nested still scares me, even though so far I failed to break it.
How about, and especially given the commit message talks about "still
trying hard under oom", you actually split this patch into two:
1. Implement exactly what the commit says - so "if (flags &
I915_SHRINK_ACTIVE)" the code keeps using the loopy trylock.
2. Add a patch which I earlier suggested, introducing
I915_SHRINK_LOCKED, so we we avoid hitting the recursive path from the
shrinker itself.
3. Cleanup the wait timeout handling in the vmap notifier case.
4. And only finally add the nested trick.
Sounds like a reasonable shrinker cleanup and improvement mini-series?
Regards,
Tvrtko
+ *unlock = true;
+ }
return *unlock;
case MUTEX_TRYLOCK_SUCCESS:
@@ -160,7 +158,7 @@ i915_gem_shrink(struct drm_i915_private *i915,
unsigned long scanned = 0;
bool unlock;
- if (!shrinker_lock(i915, &unlock))
+ if (!shrinker_lock(i915, flags, &unlock))
return 0;
/*
@@ -357,7 +355,7 @@ i915_gem_shrinker_scan(struct shrinker *shrinker, struct
shrink_control *sc)
sc->nr_scanned = 0;
- if (!shrinker_lock(i915, &unlock))
+ if (!shrinker_lock(i915, 0, &unlock))
return SHRINK_STOP;
freed = i915_gem_shrink(i915,
@@ -397,7 +395,7 @@ shrinker_lock_uninterruptible(struct drm_i915_private
*i915, bool *unlock,
do {
if (i915_gem_wait_for_idle(i915,
0, MAX_SCHEDULE_TIMEOUT) == 0 &&
- shrinker_lock(i915, unlock))
+ shrinker_lock(i915, 0, unlock))
break;
schedule_timeout_killable(1);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for legacy helper cleanup
== Series Details == Series: legacy helper cleanup URL : https://patchwork.freedesktop.org/series/53819/ State : warning == Summary == $ dim checkpatch origin/drm-tip 21656459631c drm/ch7006: Stop using drm_crtc_force_disable -:10: WARNING:TYPO_SPELLING: 'paramters' may be misspelled - perhaps 'parameters'? #10: because we're not changing any of the refcounted paramters. -:32: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 2 warnings, 0 checks, 13 lines checked f56367872f7d drm/nouveau: Stop using drm_crtc_force_disable -:10: WARNING:TYPO_SPELLING: 'paramters' may be misspelled - perhaps 'parameters'? #10: because we're not changing any of the refcounted paramters. -:30: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 2 warnings, 0 checks, 10 lines checked 9fa43c686de6 drm: Unexport drm_crtc_force_disable -:66: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 1 warnings, 0 checks, 36 lines checked aa20336b0566 drm: Move the legacy kms disable_all helper to crtc helpers -:180: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 1 warnings, 0 checks, 114 lines checked 2abb979af9c3 drm/qxl: Don't set the dpms hook 3736c5daab67 drm/xen: Don't set the dpms hook -:24: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 1 warnings, 0 checks, 7 lines checked 7b792e809a58 drm: Split out drm_probe_helper.h -:565: WARNING:OBSOLETE: drivers/gpu/drm/cirrus/cirrus_drv.c is marked as 'obsolete' in the MAINTAINERS hierarchy. No unnecessary modifications please. -:568: WARNING:OBSOLETE: drivers/gpu/drm/cirrus/cirrus_drv.c is marked as 'obsolete' in the MAINTAINERS hierarchy. No unnecessary modifications please. -:577: WARNING:OBSOLETE: drivers/gpu/drm/cirrus/cirrus_mode.c is marked as 'obsolete' in the MAINTAINERS hierarchy. No unnecessary modifications please. -:580: WARNING:OBSOLETE: drivers/gpu/drm/cirrus/cirrus_mode.c is marked as 'obsolete' in the MAINTAINERS hierarchy. No unnecessary modifications please. -:2724: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #2724: new file mode 100644 -:2729: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier tag in line 1 #2729: FILE: include/drm/drm_probe_helper.h:1: +/* -:2778: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 7 warnings, 0 checks, 1704 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/7] drm/i915/userptr: Avoid struct_mutex recursion for mmu_invalidate_range_start
On 04/12/2018 14:15, Chris Wilson wrote:
Since commit 93065ac753e4 ("mm, oom: distinguish blockable mode for mmu
notifiers") we have been able to report failure from
mmu_invalidate_range_start which allows us to use a trylock on the
struct_mutex to avoid potential recursion and report -EBUSY instead.
Furthermore, this allows us to pull the work into the main callback and
avoid the sleight-of-hand in using a workqueue to avoid lockdep.
However, not all paths to mmu_invalidate_range_start are prepared to
handle failure, so instead of reporting the recursion, deal with it by
propagating the failure upwards, who can decide themselves to handle it
or report it.
v2: Mark up the recursive lock behaviour and comment on the various weak
points.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108375
References: 93065ac753e4 ("mm, oom: distinguish blockable mode for mmu
notifiers")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h | 4 +-
drivers/gpu/drm/i915/i915_gem.c | 30 +++-
drivers/gpu/drm/i915/i915_gem_object.h | 7 +
drivers/gpu/drm/i915/i915_gem_userptr.c | 221 +++-
4 files changed, 136 insertions(+), 126 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1cad218b71d3..144b7737c0a2 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2921,8 +2921,8 @@ enum i915_mm_subclass { /* lockdep subclass for
obj->mm.lock/struct_mutex */
I915_MM_SHRINKER /* called "recursively" from direct-reclaim-esque */
};
-void __i915_gem_object_put_pages(struct drm_i915_gem_object *obj,
-enum i915_mm_subclass subclass);
+int __i915_gem_object_put_pages(struct drm_i915_gem_object *obj,
+ enum i915_mm_subclass subclass);
void __i915_gem_object_invalidate(struct drm_i915_gem_object *obj);
enum i915_map_type {
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d36a9755ad91..2ad8f94f5056 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2447,8 +2447,8 @@ __i915_gem_object_unset_pages(struct drm_i915_gem_object
*obj)
struct sg_table *pages;
pages = fetch_and_zero(&obj->mm.pages);
- if (!pages)
- return NULL;
+ if (IS_ERR_OR_NULL(pages))
+ return pages;
spin_lock(&i915->mm.obj_lock);
list_del(&obj->mm.link);
@@ -2472,22 +2472,23 @@ __i915_gem_object_unset_pages(struct
drm_i915_gem_object *obj)
return pages;
}
-void __i915_gem_object_put_pages(struct drm_i915_gem_object *obj,
-enum i915_mm_subclass subclass)
+int __i915_gem_object_put_pages(struct drm_i915_gem_object *obj,
+ enum i915_mm_subclass subclass)
{
struct sg_table *pages;
+ int ret;
if (i915_gem_object_has_pinned_pages(obj))
- return;
+ return -EBUSY;
GEM_BUG_ON(obj->bind_count);
- if (!i915_gem_object_has_pages(obj))
- return;
/* May be called by shrinker from within get_pages() (on another bo) */
mutex_lock_nested(&obj->mm.lock, subclass);
- if (unlikely(atomic_read(&obj->mm.pages_pin_count)))
+ if (unlikely(atomic_read(&obj->mm.pages_pin_count))) {
+ ret = -EBUSY;
goto unlock;
+ }
/*
* ->put_pages might need to allocate memory for the bit17 swizzle
@@ -2495,11 +2496,24 @@ void __i915_gem_object_put_pages(struct
drm_i915_gem_object *obj,
* lists early.
*/
pages = __i915_gem_object_unset_pages(obj);
+
+ /*
+* XXX Temporary hijinx to avoid updating all backends to handle
+* NULL pages. In the future, when we have more asynchronous
+* get_pages backends we should be better able to handle the
+* cancellation of the async task in a more uniform manner.
+*/
+ if (!pages && !i915_gem_object_needs_async_cancel(obj))
+ pages = ERR_PTR(-EINVAL);
+
if (!IS_ERR(pages))
obj->ops->put_pages(obj, pages);
+ ret = 0;
unlock:
mutex_unlock(&obj->mm.lock);
+
+ return ret;
}
bool i915_sg_trim(struct sg_table *orig_st)
diff --git a/drivers/gpu/drm/i915/i915_gem_object.h
b/drivers/gpu/drm/i915/i915_gem_object.h
index a6dd7c46de0d..49ce797173b5 100644
--- a/drivers/gpu/drm/i915/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/i915_gem_object.h
@@ -56,6 +56,7 @@ struct drm_i915_gem_object_ops {
#define I915_GEM_OBJECT_HAS_STRUCT_PAGE BIT(0)
#define I915_GEM_OBJECT_IS_SHRINKABLE BIT(1)
#define I915_GEM_OBJECT_IS_PROXY BIT(2)
+#define I915_GEM_OBJECT_ASYNC_CANCEL BIT(3)
/* Interface between the GEM object and its backing storage.
* get_pages() is called once prior to the use of the associated set
@@
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for mmu notifier debug checks v2
== Series Details ==
Series: mmu notifier debug checks v2
URL : https://patchwork.freedesktop.org/series/53828/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
834029401554 mm: Check if mmu notifier callbacks are allowed to fail
-:56: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 9 lines checked
735885c1e985 kernel.h: Add non_block_start/end()
-:47: WARNING:SINGLE_STATEMENT_DO_WHILE_MACRO: Single statement macros should
not use a do {} while (0) loop
#47: FILE: include/linux/kernel.h:265:
+# define non_block_start() \
+ do { current->non_block_count++; } while (0)
-:49: WARNING:SINGLE_STATEMENT_DO_WHILE_MACRO: Single statement macros should
not use a do {} while (0) loop
#49: FILE: include/linux/kernel.h:267:
+# define non_block_end() \
+ do { WARN_ON(current->non_block_count-- == 0); } while (0)
-:101: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 0 errors, 3 warnings, 0 checks, 56 lines checked
138e4dcc716f mm, notifier: Catch sleeping/blocking for !blockable
-:50: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 14 lines checked
a1c311d5605e mm, notifier: Add a lockdep map for invalidate_range_start
-:88: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 33 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for legacy helper cleanup
== Series Details ==
Series: legacy helper cleanup
URL : https://patchwork.freedesktop.org/series/53819/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5292 -> Patchwork_11055
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/53819/revisions/1/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_11055:
### IGT changes ###
Warnings
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-c:
- {fi-kbl-7567u}: PASS -> SKIP +33
Known issues
Here are the changes found in Patchwork_11055 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@cs-compute:
- fi-kbl-8809g: NOTRUN -> FAIL [fdo#108094]
* igt@amdgpu/amd_prime@amd-to-i915:
- fi-kbl-8809g: NOTRUN -> FAIL [fdo#107341]
* igt@i915_selftest@live_execlists:
- fi-apl-guc: PASS -> INCOMPLETE [fdo#103927] / [fdo#108622]
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a:
- fi-byt-clapper: PASS -> FAIL [fdo#107362]
* {igt@runner@aborted}:
- {fi-icl-y}: NOTRUN -> FAIL [fdo#108070]
Possible fixes
* igt@amdgpu/amd_basic@userptr:
- fi-kbl-8809g: DMESG-WARN [fdo#108965] -> PASS
* igt@gem_ctx_create@basic-files:
- fi-bsw-kefka: FAIL [fdo#108656] -> PASS
* igt@i915_selftest@live_gem:
- fi-bsw-n3050: DMESG-WARN -> PASS
* igt@i915_selftest@live_hangcheck:
- fi-cfl-8109u: INCOMPLETE [fdo#106070] -> PASS
- fi-kbl-7560u: INCOMPLETE [fdo#108044] -> PASS
* igt@kms_frontbuffer_tracking@basic:
- fi-byt-clapper: FAIL [fdo#103167] -> PASS
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b:
- fi-byt-clapper: FAIL [fdo#107362] -> PASS
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-cfl-8109u: DMESG-WARN -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#106070]: https://bugs.freedesktop.org/show_bug.cgi?id=106070
[fdo#107341]: https://bugs.freedesktop.org/show_bug.cgi?id=107341
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#108044]: https://bugs.freedesktop.org/show_bug.cgi?id=108044
[fdo#108070]: https://bugs.freedesktop.org/show_bug.cgi?id=108070
[fdo#108094]: https://bugs.freedesktop.org/show_bug.cgi?id=108094
[fdo#108622]: https://bugs.freedesktop.org/show_bug.cgi?id=108622
[fdo#108656]: https://bugs.freedesktop.org/show_bug.cgi?id=108656
[fdo#108965]: https://bugs.freedesktop.org/show_bug.cgi?id=108965
Participating hosts (50 -> 45)
--
Additional (1): fi-icl-y
Missing(6): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-icl-u3
Build changes
-
* Linux: CI_DRM_5292 -> Patchwork_11055
CI_DRM_5292: ec6b8cacbc8777a77119fa7af7e2930fe186091b @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4744: 4579ac1d445cf39f6de474071b20db790db575bd @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_11055: 7b792e809a58b83ddb6a4ce4b703cb69d8d4e77d @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
7b792e809a58 drm: Split out drm_probe_helper.h
3736c5daab67 drm/xen: Don't set the dpms hook
2abb979af9c3 drm/qxl: Don't set the dpms hook
aa20336b0566 drm: Move the legacy kms disable_all helper to crtc helpers
9fa43c686de6 drm: Unexport drm_crtc_force_disable
f56367872f7d drm/nouveau: Stop using drm_crtc_force_disable
21656459631c drm/ch7006: Stop using drm_crtc_force_disable
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11055/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for mmu notifier debug checks v2
== Series Details ==
Series: mmu notifier debug checks v2
URL : https://patchwork.freedesktop.org/series/53828/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5292 -> Patchwork_11056
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/53828/revisions/1/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_11056:
### IGT changes ###
Warnings
* igt@kms_busy@basic-flip-a:
- {fi-kbl-7567u}: PASS -> SKIP +2
Known issues
Here are the changes found in Patchwork_11056 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@cs-compute:
- fi-kbl-8809g: NOTRUN -> FAIL [fdo#108094]
* igt@amdgpu/amd_prime@amd-to-i915:
- fi-kbl-8809g: NOTRUN -> FAIL [fdo#107341]
* {igt@runner@aborted}:
- {fi-icl-y}: NOTRUN -> FAIL [fdo#108070]
Possible fixes
* igt@amdgpu/amd_basic@userptr:
- fi-kbl-8809g: DMESG-WARN [fdo#108965] -> PASS
* igt@gem_ctx_create@basic-files:
- fi-bsw-kefka: FAIL [fdo#108656] -> PASS
* igt@i915_selftest@live_gem:
- fi-bsw-n3050: DMESG-WARN -> PASS
* igt@i915_selftest@live_hangcheck:
- fi-cfl-8109u: INCOMPLETE [fdo#106070] -> PASS
- fi-kbl-7560u: INCOMPLETE [fdo#108044] -> PASS
* igt@kms_frontbuffer_tracking@basic:
- fi-byt-clapper: FAIL [fdo#103167] -> PASS
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b:
- fi-byt-clapper: FAIL [fdo#107362] -> PASS
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-cfl-8109u: DMESG-WARN -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#106070]: https://bugs.freedesktop.org/show_bug.cgi?id=106070
[fdo#107341]: https://bugs.freedesktop.org/show_bug.cgi?id=107341
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#108044]: https://bugs.freedesktop.org/show_bug.cgi?id=108044
[fdo#108070]: https://bugs.freedesktop.org/show_bug.cgi?id=108070
[fdo#108094]: https://bugs.freedesktop.org/show_bug.cgi?id=108094
[fdo#108656]: https://bugs.freedesktop.org/show_bug.cgi?id=108656
[fdo#108965]: https://bugs.freedesktop.org/show_bug.cgi?id=108965
Participating hosts (50 -> 45)
--
Additional (1): fi-icl-y
Missing(6): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-icl-u3
Build changes
-
* Linux: CI_DRM_5292 -> Patchwork_11056
CI_DRM_5292: ec6b8cacbc8777a77119fa7af7e2930fe186091b @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4744: 4579ac1d445cf39f6de474071b20db790db575bd @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_11056: a1c311d5605eac8919aa0c8fa62137b168ce0d18 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
a1c311d5605e mm, notifier: Add a lockdep map for invalidate_range_start
138e4dcc716f mm, notifier: Catch sleeping/blocking for !blockable
735885c1e985 kernel.h: Add non_block_start/end()
834029401554 mm: Check if mmu notifier callbacks are allowed to fail
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11056/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/7] drm: Split out drm_probe_helper.h
On 10/12/2018 11:11, Daniel Vetter wrote: > Having the probe helper stuff (which pretty much everyone needs) in > the drm_crtc_helper.h file (which atomic drivers should never need) is > confusing. Split them out. > > To make sure I actually achieved the goal here I went through all > drivers. And indeed, all atomic drivers are now free of > drm_crtc_helper.h includes. > > Signed-off-by: Daniel Vetter > Cc: linux-arm-ker...@lists.infradead.org > Cc: virtualizat...@lists.linux-foundation.org > Cc: etna...@lists.freedesktop.org > Cc: linux-samsung-...@vger.kernel.org > Cc: intel-gfx@lists.freedesktop.org > Cc: linux-media...@lists.infradead.org > Cc: linux-amlo...@lists.infradead.org > Cc: linux-arm-...@vger.kernel.org > Cc: freedr...@lists.freedesktop.org > Cc: nouv...@lists.freedesktop.org > Cc: spice-de...@lists.freedesktop.org > Cc: amd-...@lists.freedesktop.org > Cc: linux-renesas-...@vger.kernel.org > Cc: linux-rockc...@lists.infradead.org > Cc: linux-st...@st-md-mailman.stormreply.com > Cc: linux-te...@vger.kernel.org > Cc: xen-de...@lists.xen.org > --- > .../gpu/drm/amd/amdgpu/amdgpu_connectors.c| 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 1 + > .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 +- > .../amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c | 2 +- > .../display/amdgpu_dm/amdgpu_dm_services.c| 2 +- > drivers/gpu/drm/arc/arcpgu_crtc.c | 2 +- > drivers/gpu/drm/arc/arcpgu_drv.c | 2 +- > drivers/gpu/drm/arc/arcpgu_sim.c | 2 +- > drivers/gpu/drm/arm/hdlcd_crtc.c | 2 +- > drivers/gpu/drm/arm/hdlcd_drv.c | 2 +- > drivers/gpu/drm/arm/malidp_crtc.c | 2 +- > drivers/gpu/drm/arm/malidp_drv.c | 2 +- > drivers/gpu/drm/arm/malidp_mw.c | 2 +- > drivers/gpu/drm/armada/armada_510.c | 2 +- > drivers/gpu/drm/armada/armada_crtc.c | 2 +- > drivers/gpu/drm/armada/armada_drv.c | 2 +- > drivers/gpu/drm/armada/armada_fb.c| 2 +- > drivers/gpu/drm/ast/ast_drv.c | 1 + > drivers/gpu/drm/ast/ast_mode.c| 1 + > .../gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c| 2 +- > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 2 +- > drivers/gpu/drm/bochs/bochs_drv.c | 1 + > drivers/gpu/drm/bochs/bochs_kms.c | 1 + > drivers/gpu/drm/bridge/adv7511/adv7511.h | 2 +- > drivers/gpu/drm/bridge/analogix-anx78xx.c | 3 +- > .../drm/bridge/analogix/analogix_dp_core.c| 2 +- > drivers/gpu/drm/bridge/cdns-dsi.c | 2 +- > drivers/gpu/drm/bridge/dumb-vga-dac.c | 2 +- > .../bridge/megachips-stdp-ge-b850v3-fw.c | 2 +- > drivers/gpu/drm/bridge/nxp-ptn3460.c | 2 +- > drivers/gpu/drm/bridge/panel.c| 2 +- > drivers/gpu/drm/bridge/parade-ps8622.c| 2 +- > drivers/gpu/drm/bridge/sii902x.c | 2 +- > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +- > drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 2 +- > drivers/gpu/drm/bridge/tc358764.c | 2 +- > drivers/gpu/drm/bridge/tc358767.c | 2 +- > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 2 +- > drivers/gpu/drm/bridge/ti-tfp410.c| 2 +- > drivers/gpu/drm/cirrus/cirrus_drv.c | 1 + > drivers/gpu/drm/cirrus/cirrus_mode.c | 1 + > drivers/gpu/drm/drm_atomic_helper.c | 1 - > drivers/gpu/drm/drm_dp_mst_topology.c | 2 +- > drivers/gpu/drm/drm_modeset_helper.c | 2 +- > drivers/gpu/drm/drm_probe_helper.c| 2 +- > drivers/gpu/drm/drm_simple_kms_helper.c | 2 +- > drivers/gpu/drm/etnaviv/etnaviv_drv.h | 1 - > drivers/gpu/drm/exynos/exynos_dp.c| 2 +- > drivers/gpu/drm/exynos/exynos_drm_crtc.c | 2 +- > drivers/gpu/drm/exynos/exynos_drm_dpi.c | 2 +- > drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +- > drivers/gpu/drm/exynos/exynos_drm_dsi.c | 2 +- > drivers/gpu/drm/exynos/exynos_drm_fb.c| 2 +- > drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 2 +- > drivers/gpu/drm/exynos/exynos_drm_vidi.c | 2 +- > drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +- > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c| 2 +- > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 2 +- > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c | 2 +- > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c | 2 +- > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 2 +- > drivers/gpu/drm/gma500/psb_intel_drv.h| 1 + > .../gpu/drm/hisilicon/hibmc/hibmc_drm_de.c| 2 +- > .../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 2 +- > .../gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c | 2 +- > .../gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c | 2 +- > drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 2 +
Re: [Intel-gfx] [PATCH 5/7] drm/qxl: Don't set the dpms hook
On Mon, Dec 10, 2018 at 11:03:57AM +0100, Daniel Vetter wrote:
> Doesn't do anything with atomic.
>
> Signed-off-by: Daniel Vetter
> Cc: Dave Airlie
> Cc: Gerd Hoffmann
> Cc: virtualizat...@lists.linux-foundation.org
> Cc: spice-de...@lists.freedesktop.org
> ---
> drivers/gpu/drm/qxl/qxl_display.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/qxl/qxl_display.c
> b/drivers/gpu/drm/qxl/qxl_display.c
> index ce0b9c40fc21..72a1784dae54 100644
> --- a/drivers/gpu/drm/qxl/qxl_display.c
> +++ b/drivers/gpu/drm/qxl/qxl_display.c
> @@ -1010,7 +1010,6 @@ static void qxl_conn_destroy(struct drm_connector
> *connector)
> }
>
> static const struct drm_connector_funcs qxl_connector_funcs = {
> - .dpms = drm_helper_connector_dpms,
> .detect = qxl_conn_detect,
> .fill_modes = drm_helper_probe_single_connector_modes,
> .destroy = qxl_conn_destroy,
Reviewed-by: Gerd Hoffmann
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] mm: Check if mmu notifier callbacks are allowed to fail
On Mon 10-12-18 11:36:38, Daniel Vetter wrote:
> Just a bit of paranoia, since if we start pushing this deep into
> callchains it's hard to spot all places where an mmu notifier
> implementation might fail when it's not allowed to.
>
> Inspired by some confusion we had discussing i915 mmu notifiers and
> whether we could use the newly-introduced return value to handle some
> corner cases. Until we realized that these are only for when a task
> has been killed by the oom reaper.
>
> An alternative approach would be to split the callback into two
> versions, one with the int return value, and the other with void
> return value like in older kernels. But that's a lot more churn for
> fairly little gain I think.
>
> Summary from the m-l discussion on why we want something at warning
> level: This allows automated tooling in CI to catch bugs without
> humans having to look at everything. If we just upgrade the existing
> pr_info to a pr_warn, then we'll have false positives. And as-is, no
> one will ever spot the problem since it's lost in the massive amounts
> of overall dmesg noise.
OK, fair enough. If this is going to help with testing then I do not
have any objections of course.
> v2: Drop the full WARN_ON backtrace in favour of just a pr_warn for
> the problematic case (Michal Hocko).
Thanks!
> Cc: Andrew Morton
> Cc: Michal Hocko
> Cc: "Christian König"
> Cc: David Rientjes
> Cc: Daniel Vetter
> Cc: "Jérôme Glisse"
> Cc: linux...@kvack.org
> Cc: Paolo Bonzini
> Signed-off-by: Daniel Vetter
> ---
> mm/mmu_notifier.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c
> index 5119ff846769..ccc22f21b735 100644
> --- a/mm/mmu_notifier.c
> +++ b/mm/mmu_notifier.c
> @@ -190,6 +190,9 @@ int __mmu_notifier_invalidate_range_start(struct
> mm_struct *mm,
> pr_info("%pS callback failed with %d in
> %sblockable context.\n",
>
> mn->ops->invalidate_range_start, _ret,
> !blockable ? "non-" : "");
> + if (blockable)
> + pr_warn("%pS callback failure not
> allowed\n",
> +
> mn->ops->invalidate_range_start);
> ret = _ret;
> }
> }
> --
> 2.20.0.rc1
>
--
Michal Hocko
SUSE Labs
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/7] drm: Split out drm_probe_helper.h
Le lun. 10 déc. 2018 à 12:10, Benjamin Gaignard a écrit : > > Le lun. 10 déc. 2018 à 11:24, Thierry Reding > a écrit : > > > > On Mon, Dec 10, 2018 at 11:11:33AM +0100, Daniel Vetter wrote: > > > Having the probe helper stuff (which pretty much everyone needs) in > > > the drm_crtc_helper.h file (which atomic drivers should never need) is > > > confusing. Split them out. > > > > > > To make sure I actually achieved the goal here I went through all > > > drivers. And indeed, all atomic drivers are now free of > > > drm_crtc_helper.h includes. > > > > > I have difficulties to apply this with git on top of drm-misc-next. > It is because of that I got errors (encoder and connector types not > found) while compiling adv7511_audio.c and exynos_dp.c ? > Nack on this patch because it break compiling at least on sti driver. drm_probe_helper.h doesn't bring the same includes than drm_crtc_helper.h: #include #include #include so some types, structures and functions proptotypes are missing while compiling. > Benjamin > > > Signed-off-by: Daniel Vetter > > > Cc: linux-arm-ker...@lists.infradead.org > > > Cc: virtualizat...@lists.linux-foundation.org > > > Cc: etna...@lists.freedesktop.org > > > Cc: linux-samsung-...@vger.kernel.org > > > Cc: intel-gfx@lists.freedesktop.org > > > Cc: linux-media...@lists.infradead.org > > > Cc: linux-amlo...@lists.infradead.org > > > Cc: linux-arm-...@vger.kernel.org > > > Cc: freedr...@lists.freedesktop.org > > > Cc: nouv...@lists.freedesktop.org > > > Cc: spice-de...@lists.freedesktop.org > > > Cc: amd-...@lists.freedesktop.org > > > Cc: linux-renesas-...@vger.kernel.org > > > Cc: linux-rockc...@lists.infradead.org > > > Cc: linux-st...@st-md-mailman.stormreply.com > > > Cc: linux-te...@vger.kernel.org > > > Cc: xen-de...@lists.xen.org > > > --- > > > .../gpu/drm/amd/amdgpu/amdgpu_connectors.c| 2 +- > > > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 2 +- > > > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +- > > > drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 1 + > > > .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 +- > > > .../amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c | 2 +- > > > .../display/amdgpu_dm/amdgpu_dm_services.c| 2 +- > > > drivers/gpu/drm/arc/arcpgu_crtc.c | 2 +- > > > drivers/gpu/drm/arc/arcpgu_drv.c | 2 +- > > > drivers/gpu/drm/arc/arcpgu_sim.c | 2 +- > > > drivers/gpu/drm/arm/hdlcd_crtc.c | 2 +- > > > drivers/gpu/drm/arm/hdlcd_drv.c | 2 +- > > > drivers/gpu/drm/arm/malidp_crtc.c | 2 +- > > > drivers/gpu/drm/arm/malidp_drv.c | 2 +- > > > drivers/gpu/drm/arm/malidp_mw.c | 2 +- > > > drivers/gpu/drm/armada/armada_510.c | 2 +- > > > drivers/gpu/drm/armada/armada_crtc.c | 2 +- > > > drivers/gpu/drm/armada/armada_drv.c | 2 +- > > > drivers/gpu/drm/armada/armada_fb.c| 2 +- > > > drivers/gpu/drm/ast/ast_drv.c | 1 + > > > drivers/gpu/drm/ast/ast_mode.c| 1 + > > > .../gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c| 2 +- > > > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 2 +- > > > drivers/gpu/drm/bochs/bochs_drv.c | 1 + > > > drivers/gpu/drm/bochs/bochs_kms.c | 1 + > > > drivers/gpu/drm/bridge/adv7511/adv7511.h | 2 +- > > > drivers/gpu/drm/bridge/analogix-anx78xx.c | 3 +- > > > .../drm/bridge/analogix/analogix_dp_core.c| 2 +- > > > drivers/gpu/drm/bridge/cdns-dsi.c | 2 +- > > > drivers/gpu/drm/bridge/dumb-vga-dac.c | 2 +- > > > .../bridge/megachips-stdp-ge-b850v3-fw.c | 2 +- > > > drivers/gpu/drm/bridge/nxp-ptn3460.c | 2 +- > > > drivers/gpu/drm/bridge/panel.c| 2 +- > > > drivers/gpu/drm/bridge/parade-ps8622.c| 2 +- > > > drivers/gpu/drm/bridge/sii902x.c | 2 +- > > > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +- > > > drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 2 +- > > > drivers/gpu/drm/bridge/tc358764.c | 2 +- > > > drivers/gpu/drm/bridge/tc358767.c | 2 +- > > > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 2 +- > > > drivers/gpu/drm/bridge/ti-tfp410.c| 2 +- > > > drivers/gpu/drm/cirrus/cirrus_drv.c | 1 + > > > drivers/gpu/drm/cirrus/cirrus_mode.c | 1 + > > > drivers/gpu/drm/drm_atomic_helper.c | 1 - > > > drivers/gpu/drm/drm_dp_mst_topology.c | 2 +- > > > drivers/gpu/drm/drm_modeset_helper.c | 2 +- > > > drivers/gpu/drm/drm_probe_helper.c| 2 +- > > > drivers/gpu/drm/drm_simple_kms_helper.c | 2 +- > > > drivers/gpu/drm/etnaviv/etnaviv_drv.h | 1 - > > > drivers/gpu/drm/exynos/exynos_dp.c| 2 +- > > > drivers/gpu/drm/exynos/exynos_drm_crtc.c | 2 +- > > > drivers/gpu/drm/exynos/exynos_drm_dpi.c | 2 +- > > > drivers/gpu/drm/exynos
Re: [Intel-gfx] [PATCH 2/4] kernel.h: Add non_block_start/end()
I do not see any scheduler guys Cced and it would be really great to get
their opinion here.
On Mon 10-12-18 11:36:39, Daniel Vetter wrote:
> In some special cases we must not block, but there's not a
> spinlock, preempt-off, irqs-off or similar critical section already
> that arms the might_sleep() debug checks. Add a non_block_start/end()
> pair to annotate these.
>
> This will be used in the oom paths of mmu-notifiers, where blocking is
> not allowed to make sure there's forward progress.
Considering the only alternative would be to abuse
preempt_{disable,enable}, and that really has a different semantic, I
think this makes some sense. The cotext is preemptible but we do not
want notifier to sleep on any locks, WQ etc.
> Suggested by Michal Hocko.
>
> Cc: Andrew Morton
> Cc: Michal Hocko
> Cc: David Rientjes
> Cc: "Christian König"
> Cc: Daniel Vetter
> Cc: "Jérôme Glisse"
> Cc: linux...@kvack.org
> Signed-off-by: Daniel Vetter
> ---
> include/linux/kernel.h | 10 +-
> include/linux/sched.h | 4
> kernel/sched/core.c| 6 +++---
> 3 files changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> index d6aac75b51ba..c2cf31515b3d 100644
> --- a/include/linux/kernel.h
> +++ b/include/linux/kernel.h
> @@ -251,7 +251,9 @@ extern int _cond_resched(void);
> * might_sleep - annotation for functions that can sleep
> *
> * this macro will print a stack trace if it is executed in an atomic
> - * context (spinlock, irq-handler, ...).
> + * context (spinlock, irq-handler, ...). Additional sections where blocking
> is
> + * not allowed can be annotated with non_block_start() and non_block_end()
> + * pairs.
> *
> * This is a useful debugging help to be able to catch problems early and not
> * be bitten later when the calling function happens to sleep when it is not
> @@ -260,6 +262,10 @@ extern int _cond_resched(void);
> # define might_sleep() \
> do { __might_sleep(__FILE__, __LINE__, 0); might_resched(); } while (0)
> # define sched_annotate_sleep() (current->task_state_change = 0)
> +# define non_block_start() \
> + do { current->non_block_count++; } while (0)
> +# define non_block_end() \
> + do { WARN_ON(current->non_block_count-- == 0); } while (0)
> #else
>static inline void ___might_sleep(const char *file, int line,
> int preempt_offset) { }
> @@ -267,6 +273,8 @@ extern int _cond_resched(void);
> int preempt_offset) { }
> # define might_sleep() do { might_resched(); } while (0)
> # define sched_annotate_sleep() do { } while (0)
> +# define non_block_start() do { } while (0)
> +# define non_block_end() do { } while (0)
> #endif
>
> #define might_sleep_if(cond) do { if (cond) might_sleep(); } while (0)
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index ecffd4e37453..41249dbf8f27 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -916,6 +916,10 @@ struct task_struct {
> struct mutex_waiter *blocked_on;
> #endif
>
> +#ifdef CONFIG_DEBUG_ATOMIC_SLEEP
> + int non_block_count;
> +#endif
> +
> #ifdef CONFIG_TRACE_IRQFLAGS
> unsigned intirq_events;
> unsigned long hardirq_enable_ip;
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 6fedf3a98581..969d7a71f30c 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -6113,7 +6113,7 @@ void ___might_sleep(const char *file, int line, int
> preempt_offset)
> rcu_sleep_check();
>
> if ((preempt_count_equals(preempt_offset) && !irqs_disabled() &&
> - !is_idle_task(current)) ||
> + !is_idle_task(current) && !current->non_block_count) ||
> system_state == SYSTEM_BOOTING || system_state > SYSTEM_RUNNING ||
> oops_in_progress)
> return;
> @@ -6129,8 +6129,8 @@ void ___might_sleep(const char *file, int line, int
> preempt_offset)
> "BUG: sleeping function called from invalid context at %s:%d\n",
> file, line);
> printk(KERN_ERR
> - "in_atomic(): %d, irqs_disabled(): %d, pid: %d, name: %s\n",
> - in_atomic(), irqs_disabled(),
> + "in_atomic(): %d, irqs_disabled(): %d, non_block: %d, pid: %d,
> name: %s\n",
> + in_atomic(), irqs_disabled(), current->non_block_count,
> current->pid, current->comm);
>
> if (task_stack_end_corrupted(current))
> --
> 2.20.0.rc1
>
--
Michal Hocko
SUSE Labs
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] kernel.h: Add non_block_start/end()
On Mon, Dec 10, 2018 at 03:13:37PM +0100, Michal Hocko wrote:
> I do not see any scheduler guys Cced and it would be really great to get
> their opinion here.
>
> On Mon 10-12-18 11:36:39, Daniel Vetter wrote:
> > In some special cases we must not block, but there's not a
> > spinlock, preempt-off, irqs-off or similar critical section already
> > that arms the might_sleep() debug checks. Add a non_block_start/end()
> > pair to annotate these.
> >
> > This will be used in the oom paths of mmu-notifiers, where blocking is
> > not allowed to make sure there's forward progress.
>
> Considering the only alternative would be to abuse
> preempt_{disable,enable}, and that really has a different semantic, I
> think this makes some sense. The cotext is preemptible but we do not
> want notifier to sleep on any locks, WQ etc.
I'm confused... what is this supposed to do?
And what does 'block' mean here? Without preempt_disable/IRQ-off we're
subject to regular preemption and execution can stall for arbitrary
amounts of time.
The Changelog doesn't yield any clues.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for legacy helper cleanup
== Series Details ==
Series: legacy helper cleanup
URL : https://patchwork.freedesktop.org/series/53819/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5292_full -> Patchwork_11055_full
Summary
---
**WARNING**
Minor unknown changes coming with Patchwork_11055_full need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_11055_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_11055_full:
### IGT changes ###
Warnings
* igt@pm_rc6_residency@rc6-accuracy:
- shard-kbl: PASS -> SKIP
Known issues
Here are the changes found in Patchwork_11055_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@kms_busy@extended-modeset-hang-newfb-render-a:
- {shard-iclb}: PASS -> DMESG-WARN [fdo#107956]
* igt@kms_busy@extended-modeset-hang-newfb-render-b:
- {shard-iclb}: NOTRUN -> DMESG-WARN [fdo#107956]
* igt@kms_color@pipe-c-ctm-green-to-red:
- shard-skl: NOTRUN -> FAIL [fdo#107201] +1
* igt@kms_color@pipe-c-ctm-max:
- shard-apl: PASS -> FAIL [fdo#108147]
* igt@kms_cursor_crc@cursor-256x256-sliding:
- {shard-iclb}: NOTRUN -> FAIL [fdo#103232]
* igt@kms_cursor_crc@cursor-size-change:
- shard-glk: PASS -> FAIL [fdo#103232] +1
* igt@kms_draw_crc@draw-method-xrgb-mmap-wc-ytiled:
- shard-skl: PASS -> FAIL [fdo#103184]
* igt@kms_flip@flip-vs-expired-vblank-interruptible:
- shard-skl: PASS -> FAIL [fdo#102887]
* igt@kms_flip@plain-flip-ts-check:
- shard-skl: PASS -> FAIL [fdo#100368]
* igt@kms_flip_tiling@flip-changes-tiling:
- shard-skl: NOTRUN -> FAIL [fdo#108303]
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-cpu:
- shard-apl: PASS -> FAIL [fdo#103167] +1
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-gtt:
- shard-glk: PASS -> FAIL [fdo#103167] +1
* igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-fullscreen:
- shard-skl: NOTRUN -> FAIL [fdo#103167]
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-fullscreen:
- {shard-iclb}: PASS -> FAIL [fdo#103167] +6
* {igt@kms_plane@pixel-format-pipe-b-planes-source-clamping}:
- {shard-iclb}: NOTRUN -> FAIL [fdo#108948]
* igt@kms_plane@plane-position-covered-pipe-a-planes:
- shard-glk: PASS -> FAIL [fdo#103166]
* igt@kms_plane@plane-position-covered-pipe-c-planes:
- {shard-iclb}: PASS -> FAIL [fdo#103166] +1
* igt@kms_plane_alpha_blend@pipe-c-alpha-7efc:
- shard-skl: NOTRUN -> FAIL [fdo#107815] / [fdo#108145] +1
* igt@kms_psr@no_drrs:
- {shard-iclb}: PASS -> FAIL [fdo#108341]
* igt@kms_setmode@basic:
- shard-apl: PASS -> FAIL [fdo#99912]
- {shard-iclb}: PASS -> FAIL [fdo#99912]
- shard-hsw: PASS -> FAIL [fdo#99912]
- shard-kbl: PASS -> FAIL [fdo#99912]
* igt@kms_vblank@pipe-a-ts-continuation-dpms-suspend:
- {shard-iclb}: PASS -> INCOMPLETE [fdo#107713] +1
* igt@pm_rpm@gem-mmap-gtt:
- {shard-iclb}: PASS -> DMESG-WARN [fdo#107724]
* igt@pm_rpm@universal-planes:
- {shard-iclb}: PASS -> DMESG-WARN [fdo#108654]
Possible fixes
* igt@kms_busy@extended-modeset-hang-oldfb-with-reset-render-a:
- {shard-iclb}: DMESG-WARN [fdo#107724] -> PASS +16
* igt@kms_cursor_crc@cursor-256x256-dpms:
- shard-apl: FAIL [fdo#103232] -> PASS
* igt@kms_draw_crc@draw-method-xrgb2101010-blt-xtiled:
- {shard-iclb}: WARN [fdo#108336] -> PASS +2
* igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-mmap-cpu:
- {shard-iclb}: DMESG-FAIL [fdo#107724] -> PASS
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-gtt:
- shard-apl: FAIL [fdo#103167] -> PASS
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-indfb-draw-mmap-cpu:
- {shard-iclb}: DMESG-WARN [fdo#107724] / [fdo#108336] -> PASS +5
* igt@kms_plane@plane-position-covered-pipe-a-planes:
- {shard-iclb}: FAIL [fdo#103166] -> PASS +1
* igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
- shard-skl: FAIL [fdo#107815] -> PASS
* igt@kms_plane_multiple@atomic-pipe-a-tiling-x:
- shard-apl: FAIL [fdo#103166] -> PASS +2
* {igt@kms_rotation_crc@multiplane-rotation-cropping-top}:
- shard-glk: DMESG-FAIL [fdo#105763] / [fdo#106538] -> PASS
Warnings
* igt@i915_suspend@shrink:
- shard-kbl: DMESG-WARN [fdo#108784] -> INCOMPLETE [fdo
Re: [Intel-gfx] [PATCH 2/4] kernel.h: Add non_block_start/end()
On Mon 10-12-18 15:47:11, Peter Zijlstra wrote:
> On Mon, Dec 10, 2018 at 03:13:37PM +0100, Michal Hocko wrote:
> > I do not see any scheduler guys Cced and it would be really great to get
> > their opinion here.
> >
> > On Mon 10-12-18 11:36:39, Daniel Vetter wrote:
> > > In some special cases we must not block, but there's not a
> > > spinlock, preempt-off, irqs-off or similar critical section already
> > > that arms the might_sleep() debug checks. Add a non_block_start/end()
> > > pair to annotate these.
> > >
> > > This will be used in the oom paths of mmu-notifiers, where blocking is
> > > not allowed to make sure there's forward progress.
> >
> > Considering the only alternative would be to abuse
> > preempt_{disable,enable}, and that really has a different semantic, I
> > think this makes some sense. The cotext is preemptible but we do not
> > want notifier to sleep on any locks, WQ etc.
>
> I'm confused... what is this supposed to do?
>
> And what does 'block' mean here? Without preempt_disable/IRQ-off we're
> subject to regular preemption and execution can stall for arbitrary
> amounts of time.
The notifier is called from quite a restricted context - oom_reaper -
which shouldn't depend on any locks or sleepable conditionals. The code
should be swift as well but we mostly do care about it to make a forward
progress. Checking for sleepable context is the best thing we could come
up with that would describe these demands at least partially.
--
Michal Hocko
SUSE Labs
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 1/2] drm/i915/skl: Rework MOCS tables to keep common part in a define
On 07/11/2018 15:16, Tomasz Lis wrote:
The MOCS tables are going to be very similar across platforms.
To reduce the amount of copied code, this patch rips the common part and
puts it into a definition valid for all gen9 platforms.
v2: Made defines for or-ing flags. Renamed macros from MOCS_TABLE
to MOCS_ENTRIES. (Joonas)
Signed-off-by: Tomasz Lis
Suggested-by: Lucas De Marchi
Reviewed-by: Lucas De Marchi (v1)
R-b needs to be upgraded to v2 before merge.
Cc: Joonas Lahtinen
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
Cc: Lucas De Marchi
---
drivers/gpu/drm/i915/intel_mocs.c | 86 ---
1 file changed, 36 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_mocs.c
b/drivers/gpu/drm/i915/intel_mocs.c
index 77e9871..8d08a7b 100644
--- a/drivers/gpu/drm/i915/intel_mocs.c
+++ b/drivers/gpu/drm/i915/intel_mocs.c
@@ -96,71 +96,57 @@ struct drm_i915_mocs_table {
* may only be updated incrementally by adding entries at the
* end.
*/
-static const struct drm_i915_mocs_entry skylake_mocs_table[] = {
- [I915_MOCS_UNCACHED] = {
- /* 0x0009 */
- .control_value = LE_CACHEABILITY(LE_UC) |
- LE_TGT_CACHE(LE_TC_LLC_ELLC) |
- LE_LRUM(0) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) |
- LE_PFM(0) | LE_SCF(0),
-
- /* 0x0010 */
- .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_UC),
- },
- [I915_MOCS_PTE] = {
- /* 0x0038 */
- .control_value = LE_CACHEABILITY(LE_PAGETABLE) |
- LE_TGT_CACHE(LE_TC_LLC_ELLC) |
- LE_LRUM(3) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) |
- LE_PFM(0) | LE_SCF(0),
- /* 0x0030 */
- .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_WB),
+
+#define MOCS_CONTROL_VALUE(lecc, tc, lrum, daom, ersc, scc, pfm, scf) \
+ (LE_CACHEABILITY(lecc) | LE_TGT_CACHE(tc) | \
+ LE_LRUM(lrum) | LE_AOM(daom) | LE_RSC(ersc) | LE_SCC(scc) | \
+ LE_PFM(pfm) | LE_SCF(scf))
+
+#define MOCS_L3CC_VALUE(esc, scc, l3cc) \
+ (L3_ESC(esc) | L3_SCC(scc) | L3_CACHEABILITY(l3cc))
These two macros do not seem more readable than the previous code, since
one has to reference the macro to remind himself what is what. But never
mind, I am only here because Tomasz copied me on a ping email. So only a
reminder to upgrade the r-b.
Regards,
Tvrtko
+
+#define GEN9_MOCS_ENTRIES \
+ [I915_MOCS_UNCACHED] = { \
+ /* 0x0009 */ \
+ .control_value = MOCS_CONTROL_VALUE(LE_UC, LE_TC_LLC_ELLC, \
+ 0, 0, 0, 0, 0, 0), \
+ /* 0x0010 */ \
+ .l3cc_value = MOCS_L3CC_VALUE(0, 0, L3_UC), \
+ }, \
+ [I915_MOCS_PTE] = { \
+ /* 0x0038 */ \
+ .control_value = MOCS_CONTROL_VALUE(LE_PAGETABLE, LE_TC_LLC_ELLC, \
+ 3, 0, 0, 0, 0, 0), \
+ /* 0x0030 */ \
+ .l3cc_value = MOCS_L3CC_VALUE(0, 0, L3_WB), \
},
+
+static const struct drm_i915_mocs_entry skylake_mocs_table[] = {
+ GEN9_MOCS_ENTRIES
[I915_MOCS_CACHED] = {
/* 0x003b */
- .control_value = LE_CACHEABILITY(LE_WB) |
- LE_TGT_CACHE(LE_TC_LLC_ELLC) |
- LE_LRUM(3) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) |
- LE_PFM(0) | LE_SCF(0),
+ .control_value = MOCS_CONTROL_VALUE(LE_WB, LE_TC_LLC_ELLC,
+ 3, 0, 0, 0, 0, 0),
/* 0x0030 */
- .l3cc_value = L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_WB),
+ .l3cc_value = MOCS_L3CC_VALUE(0, 0, L3_WB),
},
};
/* NOTE: the LE_TGT_CACHE is not used on Broxton */
static const struct drm_i915_mocs_entry broxton_mocs_table[] = {
- [I915_MOCS_UNCACHED] = {
- /* 0x0009 */
- .control_value = LE_CACHEABILITY(LE_UC) |
- LE_TGT_CACHE(LE_TC_LLC_ELLC) |
- LE_LRUM(0) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) |
- LE_PFM(0) | LE_SCF(0),
-
- /* 0x0010 */
- .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_UC),
- },
- [I915_MOCS_PTE] = {
- /* 0x0038 */
- .control_value = LE_CACHEABILITY(LE_PAGETABLE) |
- LE_TGT_CACHE(LE_TC_LLC_ELLC) |
- LE_LRUM(3) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) |
- LE_PFM(0) | LE_SCF(0),
-
- /* 0x0030 */
- .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_WB),
- },
+ GEN9_MOCS_ENTRIES
[I915_MOCS_CACHED] = {
/* 0x0039 */
- .control_value = LE_CACHEABILITY(LE_UC) |
- LE_TGT_CACHE(LE_TC_LLC_ELLC) |
- LE_LRU
Re: [Intel-gfx] [PATCH v6 2/2] drm/i915/icl: Define MOCS table for Icelake
On 07/11/2018 15:16, Tomasz Lis wrote:
The table has been unified across OSes to minimize virtualization overhead.
The MOCS table is now published as part of bspec, and versioned. Entries
are supposed to never be modified, but new ones can be added. Adding
entries increases table version. The patch includes version 1 entries.
Meaning of each entry is now explained in bspec, and user mode clients
are expected to know what each entry means. The 3 entries used for previous
platforms are still compatible with their legacy definitions, but that is
not guaranteed to be true for future platforms.
v2: Fixed SCC values, improved commit comment (Daniele)
v3: Improved MOCS table comment (Daniele)
v4: Moved new entries below gen9 ones. Put common entries into
definition to be used in multiple arrays. (Lucas)
v5: Made defines for or-ing flags. Renamed macros from MOCS_TABLE
to MOCS_ENTRIES. Switched LE_CoS to upper case. (Joonas)
v6: Removed definitions of reserved entries. (Michal)
Increased limit of entries sent to the hardware on gen11+.
BSpec: 34007
BSpec: 560
Signed-off-by: Tomasz Lis
Reviewed-by: Daniele Ceraolo Spurio (v4)
R-b upgrade needed here as well.
Cc: Joonas Lahtinen
Cc: Chris Wilson
Cc: Mika Kuoppala
Cc: Daniele Ceraolo Spurio
Cc: Zhenyu Wang
Cc: Zhi A Wang
Cc: Anuj Phogat
Cc: Adam Cetnerowski
Cc: Piotr Rozenfeld
Cc: Lucas De Marchi
---
drivers/gpu/drm/i915/intel_mocs.c | 222 +-
1 file changed, 197 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_mocs.c
b/drivers/gpu/drm/i915/intel_mocs.c
index 8d08a7b..4eb05c6 100644
--- a/drivers/gpu/drm/i915/intel_mocs.c
+++ b/drivers/gpu/drm/i915/intel_mocs.c
@@ -44,6 +44,8 @@ struct drm_i915_mocs_table {
#define LE_SCC(value) ((value) << 8)
#define LE_PFM(value) ((value) << 11)
#define LE_SCF(value) ((value) << 14)
+#define LE_COS(value) ((value) << 15)
+#define LE_SSE(value) ((value) << 17)
/* Defines for the tables (LNCFMOCS0 - LNCFMOCS31) - two entries per word */
#define L3_ESC(value) ((value) << 0)
@@ -52,6 +54,10 @@ struct drm_i915_mocs_table {
/* Helper defines */
#define GEN9_NUM_MOCS_ENTRIES 62 /* 62 out of 64 - 63 & 64 are reserved. */
+#define GEN11_NUM_MOCS_ENTRIES 64 /* 63-64 are reserved, but configured. */
+
+#define NUM_MOCS_ENTRIES(i915) \
+ (INTEL_GEN(i915) < 11 ? GEN9_NUM_MOCS_ENTRIES : GEN11_NUM_MOCS_ENTRIES)
I have a suggestion to make this a bit more elegant by avoiding a
sprinkle of conditionals throughout the code - since I count ten
non-debug call sites of this macros.
Since the MOCS code seems nicely driven from struct drm_i915_mocs_table,
the suggestion is to store both the used and maximum valid number of
entries per platform in that structure.
It's all nicely consolidated in get_mocs_settings, where all the sanity
checks could be moved as well. Other bits of the code would then just
trust the table.
/* (e)LLC caching options */
#define LE_PAGETABLE 0
@@ -80,21 +86,21 @@ struct drm_i915_mocs_table {
* LNCFCMOCS0 - LNCFCMOCS32 registers.
*
* These tables are intended to be kept reasonably consistent across
- * platforms. However some of the fields are not applicable to all of
- * them.
+ * HW platforms, and for ICL+, be identical across OSes. To achieve
+ * that, for Icelake and above, list of entries is published as part
+ * of bspec.
*
* Entries not part of the following tables are undefined as far as
- * userspace is concerned and shouldn't be relied upon. For the time
- * being they will be implicitly initialized to the strictest caching
- * configuration (uncached) to guarantee forwards compatibility with
- * userspace programs written against more recent kernels providing
- * additional MOCS entries.
+ * userspace is concerned and shouldn't be relied upon.
+ *
+ * The last two entries are reserved by the hardware. For ICL+ they
+ * should be initialized according to bspec and never used, for older
+ * platforms they should never be written to.
*
- * NOTE: These tables MUST start with being uncached and the length
- * MUST be less than 63 as the last two registers are reserved
- * by the hardware. These tables are part of the kernel ABI and
- * may only be updated incrementally by adding entries at the
- * end.
+ * NOTE: These tables are part of bspec and defined as part of hardware
+ * interface for ICL+. For older platforms, they are part of kernel
+ * ABI. It is expected that existing entries will remain constant
+ * and the tables will only be updated by adding new entries.
*/
#define MOCS_CONTROL_VALUE(lecc, tc, lrum, daom, ersc, scc, pfm, scf) \
@@ -147,6 +153,167 @@ static const struct drm_i915_mocs_entry
broxton_mocs_table[] = {
#undef MOCS_CONTROL_VALUE
#undef MOCS_L3CC_VALUE
+#define MOCS_CONTROL_VALUE(lecc, tc, lrum, daom, ersc, scc, pf
Re: [Intel-gfx] [PATCH v6] drm/i915/icl: Preempt-to-idle support in execlists.
On 09/11/2018 17:18, Tomasz Lis wrote:
The patch adds support of preempt-to-idle requesting by setting a proper
bit within Execlist Control Register, and receiving preemption result from
Context Status Buffer.
Preemption in previous gens required a special batch buffer to be executed,
so the Command Streamer never preempted to idle directly. In Icelake it is
possible, as there is a hardware mechanism to inform the kernel about
status of the preemption request.
This patch does not cover using the new preemption mechanism when GuC is
active.
The advantage of this new preemption path is that one less context switch is
needed, and returning information about preempion being complete is received
earlier. This leads to significant improvement in our IGT latency test.
Test performed: `gem_exec_latency --run-subtest render-preemption`, executed
100 times, on the same platform, same kernel, without and with this patch.
Then taken average of the execution latency times:
subcase old preempt.icl preempt.
render-render 853.2036840.1176
render-bsd 2328.8708 2083.2576
render-blt 2080.1501 1852.0792
render-vebox1553.5134 1428.762
Improvement observed:
subcase improvement
render-render1.53%
render-bsd 10.55%
render-blt 10.96%
render-vebox 8.03%
Who can explain what do the parts other than render-render mean? At
least I can make sense of render-render - measure how long it takes for
one context to preempt another, but render-$other draws a blank for me.
How are engines pre-empting one another?
But anyway, even if only the 1.53% improvement is the real one, FWIW
that's I think good enough to justify the patch. It is sufficiently
small and contained that I don't see a problem. So:
Acked-by: Tvrtko Ursulin
Regards,
Tvrtko
v2: Added needs_preempt_context() change so that it is not created when
preempt-to-idle is supported. (Chris)
Updated setting HWACK flag so that it is cleared after
preempt-to-dle. (Chris, Daniele)
Updated to use I915_ENGINE_HAS_PREEMPTION flag. (Chris)
v3: Fixed needs_preempt_context() change. (Chris)
Merged preemption trigger functions to one. (Chris)
Fixed conyext state tonot assume COMPLETED_MASK after preemption,
since idle-to-idle case will not have it set.
v4: Simplified needs_preempt_context() change. (Daniele)
Removed clearing HWACK flag in idle-to-idle preempt. (Daniele)
v5: Renamed inject_preempt_context(). (Daniele)
Removed duplicated GEM_BUG_ON() on HWACK (Daniele)
v6: Added performance test results.
Bspec: 18922
Cc: Joonas Lahtinen
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
Cc: Michal Winiarski
Cc: Mika Kuoppala
Reviewed-by: Daniele Ceraolo Spurio
Signed-off-by: Tomasz Lis
---
drivers/gpu/drm/i915/i915_drv.h | 2 +
drivers/gpu/drm/i915/i915_gem_context.c | 3 +-
drivers/gpu/drm/i915/i915_pci.c | 3 +-
drivers/gpu/drm/i915/intel_device_info.h | 1 +
drivers/gpu/drm/i915/intel_lrc.c | 109 +--
drivers/gpu/drm/i915/intel_lrc.h | 1 +
6 files changed, 84 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 08d25aa..d2cc9f1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2579,6 +2579,8 @@ intel_info(const struct drm_i915_private *dev_priv)
((dev_priv)->info.has_logical_ring_elsq)
#define HAS_LOGICAL_RING_PREEMPTION(dev_priv) \
((dev_priv)->info.has_logical_ring_preemption)
+#define HAS_HW_PREEMPT_TO_IDLE(dev_priv) \
+ ((dev_priv)->info.has_hw_preempt_to_idle)
#define HAS_EXECLISTS(dev_priv) HAS_LOGICAL_RING_CONTEXTS(dev_priv)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c b/drivers/gpu/drm/i915/i915_gem_context.c
index b97963d..10b1d61 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -529,7 +529,8 @@ static void init_contexts(struct drm_i915_private *i915)
static bool needs_preempt_context(struct drm_i915_private *i915)
{
- return HAS_LOGICAL_RING_PREEMPTION(i915);
+ return HAS_LOGICAL_RING_PREEMPTION(i915) &&
+ !HAS_HW_PREEMPT_TO_IDLE(i915);
}
int i915_gem_contexts_init(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 4ccab83..82125cf 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -600,7 +600,8 @@ static const struct intel_device_info intel_cannonlake_info
= {
TRANSCODER_DSI0_OFFSET, TRANSCODER_DSI1_OFFSET}, \
GEN(11), \
.ddb_size = 2048, \
- .has_logical_ring_elsq = 1
+ .has_logical_ring_elsq = 1, \
+ .has_hw_preempt_to_idle = 1
static const struct intel_device_info intel_icelake_11_info = {
GEN11_FEATURES,
diff --git a
[Intel-gfx] ✗ Fi.CI.IGT: failure for mmu notifier debug checks v2
== Series Details ==
Series: mmu notifier debug checks v2
URL : https://patchwork.freedesktop.org/series/53828/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5292_full -> Patchwork_11056_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_11056_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_11056_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_11056_full:
### IGT changes ###
Possible regressions
* igt@gem_userptr_blits@dmabuf-sync:
- shard-kbl: PASS -> DMESG-WARN +8
* igt@gem_userptr_blits@map-fixed-invalidate-busy:
- shard-glk: PASS -> DMESG-WARN +6
* igt@gem_userptr_blits@map-fixed-invalidate-busy-gup:
- shard-skl: NOTRUN -> DMESG-WARN
* igt@gem_userptr_blits@map-fixed-invalidate-gup:
- shard-apl: PASS -> DMESG-WARN +6
* igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy:
- {shard-iclb}: PASS -> DMESG-WARN +6
* igt@gem_userptr_blits@map-fixed-invalidate-overlap-gup:
- shard-skl: PASS -> DMESG-WARN +7
* igt@gem_userptr_blits@sync-unmap:
- shard-hsw: PASS -> DMESG-WARN +6
* igt@gem_userptr_blits@sync-unmap-cycles:
- shard-snb: PASS -> DMESG-WARN +8
* {igt@runner@aborted}:
- shard-glk: NOTRUN -> FAIL
- shard-hsw: NOTRUN -> FAIL
- shard-snb: NOTRUN -> ( 2 FAIL )
- shard-kbl: NOTRUN -> ( 2 FAIL )
- shard-skl: NOTRUN -> ( 2 FAIL )
- {shard-iclb}: NOTRUN -> ( 2 FAIL ) [fdo#108654]
- shard-apl: NOTRUN -> FAIL
Known issues
Here are the changes found in Patchwork_11056_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_workarounds@suspend-resume:
- {shard-iclb}: PASS -> INCOMPLETE [fdo#107713]
* igt@kms_busy@extended-modeset-hang-newfb-render-a:
- {shard-iclb}: PASS -> DMESG-WARN [fdo#107956]
* igt@kms_busy@extended-modeset-hang-newfb-render-b:
- {shard-iclb}: NOTRUN -> DMESG-WARN [fdo#107956]
* igt@kms_chv_cursor_fail@pipe-a-64x64-bottom-edge:
- shard-skl: NOTRUN -> FAIL [fdo#104671]
* igt@kms_color@pipe-a-degamma:
- shard-apl: PASS -> FAIL [fdo#104782] / [fdo#108145]
* igt@kms_cursor_crc@cursor-128x128-offscreen:
- shard-skl: NOTRUN -> FAIL [fdo#103232]
* igt@kms_cursor_crc@cursor-256x256-sliding:
- {shard-iclb}: NOTRUN -> FAIL [fdo#103232]
* igt@kms_cursor_crc@cursor-size-change:
- shard-apl: PASS -> FAIL [fdo#103232]
* igt@kms_draw_crc@draw-method-xrgb2101010-blt-xtiled:
- shard-skl: NOTRUN -> FAIL [fdo#103184]
* igt@kms_draw_crc@draw-method-xrgb2101010-mmap-gtt-xtiled:
- {shard-iclb}: PASS -> WARN [fdo#108336] +2
* igt@kms_draw_crc@draw-method-xrgb-mmap-wc-ytiled:
- shard-skl: PASS -> FAIL [fdo#103184]
* igt@kms_draw_crc@draw-method-xrgb-pwrite-ytiled:
- shard-skl: NOTRUN -> FAIL [fdo#108222]
* igt@kms_flip@flip-vs-expired-vblank:
- shard-skl: PASS -> FAIL [fdo#105363]
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-cpu:
- shard-apl: PASS -> FAIL [fdo#103167] +3
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-render:
- shard-glk: PASS -> FAIL [fdo#103167]
* igt@kms_frontbuffer_tracking@fbc-1p-shrfb-fliptrack:
- shard-skl: NOTRUN -> FAIL [fdo#105682]
* igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-pwrite:
- {shard-iclb}: PASS -> DMESG-FAIL [fdo#107724] +3
* igt@kms_frontbuffer_tracking@fbcpsr-rgb101010-draw-mmap-gtt:
- shard-skl: NOTRUN -> FAIL [fdo#103167] / [fdo#105682]
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-indfb-draw-mmap-cpu:
- shard-skl: NOTRUN -> FAIL [fdo#103167] +1
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-blt:
- {shard-iclb}: PASS -> FAIL [fdo#103167] +4
* {igt@kms_plane@pixel-format-pipe-b-planes-source-clamping}:
- {shard-iclb}: NOTRUN -> FAIL [fdo#108948]
* igt@kms_plane@plane-position-hole-dpms-pipe-a-planes:
- {shard-iclb}: PASS -> DMESG-WARN [fdo#107724] / [fdo#108336] +14
* igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max:
- shard-glk: PASS -> FAIL [fdo#108145]
* igt@kms_plane_alpha_blend@pipe-c-alpha-7efc:
- shard-skl: NOTRUN -> FAIL [fdo#107815] / [fdo#108145] +2
* igt@kms_plane_multiple@atomic-pipe-a-tiling-x:
- {shard-iclb}: PASS -> FAIL [fdo#103166
Re: [Intel-gfx] [PATCH 4/7] drm: Move the legacy kms disable_all helper to crtc helpers
On Mon, Dec 10, 2018 at 5:04 AM Daniel Vetter wrote:
>
> It's not a core function, and the matching atomic functions are also
> not in the core. Plus the suspend/resume helper is also already there.
>
> Needs a tiny bit of open-coding, but less midlayer beats that I think.
>
> Cc: Sam Bobroff
> Signed-off-by: Daniel Vetter
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Sean Paul
> Cc: David Airlie
> Cc: Ben Skeggs
> Cc: Alex Deucher
> Cc: "Christian König"
> Cc: "David (ChunMing) Zhou"
> Cc: Rex Zhu
> Cc: Andrey Grodzovsky
> Cc: Huang Rui
> Cc: Shaoyun Liu
> Cc: Monk Liu
> Cc: nouv...@lists.freedesktop.org
> Cc: amd-...@lists.freedesktop.org
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
> drivers/gpu/drm/drm_crtc.c | 31 ---
> drivers/gpu/drm/drm_crtc_helper.c | 35 ++
> drivers/gpu/drm/nouveau/nouveau_display.c | 2 +-
> drivers/gpu/drm/radeon/radeon_display.c| 2 +-
> include/drm/drm_crtc.h | 2 --
> include/drm/drm_crtc_helper.h | 1 +
> 7 files changed, 39 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index c75badfa5c4c..e669297ffefb 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -2689,7 +2689,7 @@ void amdgpu_device_fini(struct amdgpu_device *adev)
> amdgpu_irq_disable_all(adev);
> if (adev->mode_info.mode_config_initialized){
> if (!amdgpu_device_has_dc_support(adev))
> - drm_crtc_force_disable_all(adev->ddev);
> + drm_helper_force_disable_all(adev->ddev);
> else
> drm_atomic_helper_shutdown(adev->ddev);
> }
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index f660819d406e..7dabbaf033a1 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -104,37 +104,6 @@ int drm_crtc_force_disable(struct drm_crtc *crtc)
> return drm_mode_set_config_internal(&set);
> }
>
> -/**
> - * drm_crtc_force_disable_all - Forcibly turn off all enabled CRTCs
> - * @dev: DRM device whose CRTCs to turn off
> - *
> - * Drivers may want to call this on unload to ensure that all displays are
> - * unlit and the GPU is in a consistent, low power state. Takes modeset
> locks.
> - *
> - * Note: This should only be used by non-atomic legacy drivers. For an atomic
> - * version look at drm_atomic_helper_shutdown().
> - *
> - * Returns:
> - * Zero on success, error code on failure.
> - */
> -int drm_crtc_force_disable_all(struct drm_device *dev)
> -{
> - struct drm_crtc *crtc;
> - int ret = 0;
> -
> - drm_modeset_lock_all(dev);
> - drm_for_each_crtc(crtc, dev)
> - if (crtc->enabled) {
> - ret = drm_crtc_force_disable(crtc);
> - if (ret)
> - goto out;
> - }
> -out:
> - drm_modeset_unlock_all(dev);
> - return ret;
> -}
> -EXPORT_SYMBOL(drm_crtc_force_disable_all);
> -
> static unsigned int drm_num_crtcs(struct drm_device *dev)
> {
> unsigned int num = 0;
> diff --git a/drivers/gpu/drm/drm_crtc_helper.c
> b/drivers/gpu/drm/drm_crtc_helper.c
> index a3c81850e755..23159eb494f1 100644
> --- a/drivers/gpu/drm/drm_crtc_helper.c
> +++ b/drivers/gpu/drm/drm_crtc_helper.c
> @@ -984,3 +984,38 @@ void drm_helper_resume_force_mode(struct drm_device *dev)
> drm_modeset_unlock_all(dev);
> }
> EXPORT_SYMBOL(drm_helper_resume_force_mode);
> +
> +/**
> + * drm_helper_force_disable_all - Forcibly turn off all enabled CRTCs
> + * @dev: DRM device whose CRTCs to turn off
> + *
> + * Drivers may want to call this on unload to ensure that all displays are
> + * unlit and the GPU is in a consistent, low power state. Takes modeset
> locks.
> + *
> + * Note: This should only be used by non-atomic legacy drivers. For an atomic
> + * version look at drm_atomic_helper_shutdown().
> + *
> + * Returns:
> + * Zero on success, error code on failure.
> + */
> +int drm_helper_force_disable_all(struct drm_device *dev)
Maybe put crtc somewhere in the function name so it's clear what we
are disabling. With that fixed:
Reviewed-by: Alex Deucher
> +{
> + struct drm_crtc *crtc;
> + int ret = 0;
> +
> + drm_modeset_lock_all(dev);
> + drm_for_each_crtc(crtc, dev)
> + if (crtc->enabled) {
> + struct drm_mode_set set = {
> + .crtc = crtc,
> + };
> +
> + ret = drm_mode_set_config_internal(&set);
> + if (ret)
> + goto out;
> + }
> +out:
> + drm_modeset_unlock_all(dev);
> + return ret;
> +}
> +EXPORT_SYMBOL(drm_helper_force_disable_all);
Re: [Intel-gfx] [PATCH 2/4] kernel.h: Add non_block_start/end()
On Mon 10-12-18 16:22:53, Peter Zijlstra wrote:
> On Mon, Dec 10, 2018 at 04:01:59PM +0100, Michal Hocko wrote:
> > On Mon 10-12-18 15:47:11, Peter Zijlstra wrote:
> > > On Mon, Dec 10, 2018 at 03:13:37PM +0100, Michal Hocko wrote:
> > > > I do not see any scheduler guys Cced and it would be really great to get
> > > > their opinion here.
> > > >
> > > > On Mon 10-12-18 11:36:39, Daniel Vetter wrote:
> > > > > In some special cases we must not block, but there's not a
> > > > > spinlock, preempt-off, irqs-off or similar critical section already
> > > > > that arms the might_sleep() debug checks. Add a non_block_start/end()
> > > > > pair to annotate these.
> > > > >
> > > > > This will be used in the oom paths of mmu-notifiers, where blocking is
> > > > > not allowed to make sure there's forward progress.
> > > >
> > > > Considering the only alternative would be to abuse
> > > > preempt_{disable,enable}, and that really has a different semantic, I
> > > > think this makes some sense. The cotext is preemptible but we do not
> > > > want notifier to sleep on any locks, WQ etc.
> > >
> > > I'm confused... what is this supposed to do?
> > >
> > > And what does 'block' mean here? Without preempt_disable/IRQ-off we're
> > > subject to regular preemption and execution can stall for arbitrary
> > > amounts of time.
> >
> > The notifier is called from quite a restricted context - oom_reaper -
> > which shouldn't depend on any locks or sleepable conditionals.
>
> You want to exclude spinlocks too? We could maybe frob something with
> lockdep if you need that?
Spinlocks are less of a problem because you cannot have a (in)direct
dependency on the page allocator that would deadlock. Spinlocks, or
preemption disabled in general should be short enough to guarantee a
forward progress.
> > The code
> > should be swift as well but we mostly do care about it to make a forward
> > progress. Checking for sleepable context is the best thing we could come
> > up with that would describe these demands at least partially.
>
> OK, no real objections to the thing. Just so long we're all on the same
> page as to what it does and doesn't do ;-)
I am not really sure whether there are other potential users besides
this one and whether the check as such is justified.
> I suppose you could extend the check to include schedule_debug() as
> well, maybe something like:
Do you mean to make the check cheaper?
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index f66920173370..b1aaa278f1af 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -3278,13 +3278,18 @@ static noinline void __schedule_bug(struct
> task_struct *prev)
> /*
> * Various schedule()-time debugging checks and statistics:
> */
> -static inline void schedule_debug(struct task_struct *prev)
> +static inline void schedule_debug(struct task_struct *prev, bool preempt)
> {
> #ifdef CONFIG_SCHED_STACK_END_CHECK
> if (task_stack_end_corrupted(prev))
> panic("corrupted stack end detected inside scheduler\n");
> #endif
>
> +#ifdef CONFIG_DEBUG_ATOMIC_SLEEP
> + if (!preempt && prev->state && prev->non_block_count)
> + // splat
> +#endif
> +
> if (unlikely(in_atomic_preempt_off())) {
> __schedule_bug(prev);
> preempt_count_set(PREEMPT_DISABLED);
> @@ -3391,7 +3396,7 @@ static void __sched notrace __schedule(bool preempt)
> rq = cpu_rq(cpu);
> prev = rq->curr;
>
> - schedule_debug(prev);
> + schedule_debug(prev, preempt);
>
> if (sched_feat(HRTICK))
> hrtick_clear(rq);
--
Michal Hocko
SUSE Labs
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/7] drm/ch7006: Stop using drm_crtc_force_disable
On Mon, Dec 10, 2018 at 11:03:53AM +0100, Daniel Vetter wrote:
> The correct way for legacy drivers to update properties that need to
> do a full modeset, is to do a full modeset.
>
> Note that we don't need to call the drm_mode_config_internal helper
> because we're not changing any of the refcounted paramters.
>
> Signed-off-by: Daniel Vetter
> Cc: Daniel Vetter
> ---
> drivers/gpu/drm/i2c/ch7006_drv.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i2c/ch7006_drv.c
> b/drivers/gpu/drm/i2c/ch7006_drv.c
> index 544a8a2d3562..719c79d3fac9 100644
> --- a/drivers/gpu/drm/i2c/ch7006_drv.c
> +++ b/drivers/gpu/drm/i2c/ch7006_drv.c
> @@ -359,10 +359,10 @@ static int ch7006_encoder_set_property(struct
> drm_encoder *encoder,
> if (modes_changed) {
> drm_helper_probe_single_connector_modes(connector, 0, 0);
>
> - /* Disable the crtc to ensure a full modeset is
> - * performed whenever it's turned on again. */
> if (crtc)
> - drm_crtc_force_disable(crtc);
> + return drm_crtc_helper_set_mode(crtc, &crtc->mode,
> + crtc->x, crtc->y,
> + crtc->primary->fb);
That guy seems to return a bool.
> }
>
> return 0;
> --
> 2.20.0.rc1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for igt: add timeline test cases (rev2)
On 2018年12月07日 18:29, Chris Wilson wrote: Quoting Patchwork (2018-12-07 10:27:46) == Series Details == Series: igt: add timeline test cases (rev2) URL : https://patchwork.freedesktop.org/series/53743/ State : failure == Summary == CI Bug Log - changes from CI_DRM_5281 -> IGTPW_2133 Summary --- **FAILURE** Serious unknown changes coming with IGTPW_2133 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in IGTPW_2133, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/53743/revisions/2/mbox/ Possible new issues --- Here are the unknown changes that may have been introduced in IGTPW_2133: ### IGT changes ### Possible regressions * igt@amdgpu/amd_basic@userptr: - fi-kbl-8809g: PASS -> DMESG-WARN What fortuitous timing! Maybe you would like to take a stab at the use-after-free in amdgpu's mmu_notifier. It's totally new test cases and should be nothing with others, Do you mean I need to resend it after sometime? -David -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] kernel.h: Add non_block_start/end()
On Mon, Dec 10, 2018 at 05:20:10PM +0100, Michal Hocko wrote:
> > OK, no real objections to the thing. Just so long we're all on the same
> > page as to what it does and doesn't do ;-)
>
> I am not really sure whether there are other potential users besides
> this one and whether the check as such is justified.
It's a debug option...
> > I suppose you could extend the check to include schedule_debug() as
> > well, maybe something like:
>
> Do you mean to make the check cheaper?
Nah, so the patch only touched might_sleep(), the below touches
schedule().
If there were a patch that hits schedule() without going through a
might_sleep() (rare in practise I think, but entirely possible) then you
won't get a splat without something like the below on top.
> > diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> > index f66920173370..b1aaa278f1af 100644
> > --- a/kernel/sched/core.c
> > +++ b/kernel/sched/core.c
> > @@ -3278,13 +3278,18 @@ static noinline void __schedule_bug(struct
> > task_struct *prev)
> > /*
> > * Various schedule()-time debugging checks and statistics:
> > */
> > -static inline void schedule_debug(struct task_struct *prev)
> > +static inline void schedule_debug(struct task_struct *prev, bool preempt)
> > {
> > #ifdef CONFIG_SCHED_STACK_END_CHECK
> > if (task_stack_end_corrupted(prev))
> > panic("corrupted stack end detected inside scheduler\n");
> > #endif
> >
> > +#ifdef CONFIG_DEBUG_ATOMIC_SLEEP
> > + if (!preempt && prev->state && prev->non_block_count)
> > + // splat
> > +#endif
> > +
> > if (unlikely(in_atomic_preempt_off())) {
> > __schedule_bug(prev);
> > preempt_count_set(PREEMPT_DISABLED);
> > @@ -3391,7 +3396,7 @@ static void __sched notrace __schedule(bool preempt)
> > rq = cpu_rq(cpu);
> > prev = rq->curr;
> >
> > - schedule_debug(prev);
> > + schedule_debug(prev, preempt);
> >
> > if (sched_feat(HRTICK))
> > hrtick_clear(rq);
>
> --
> Michal Hocko
> SUSE Labs
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] kernel.h: Add non_block_start/end()
On Mon, Dec 10, 2018 at 04:01:59PM +0100, Michal Hocko wrote:
> On Mon 10-12-18 15:47:11, Peter Zijlstra wrote:
> > On Mon, Dec 10, 2018 at 03:13:37PM +0100, Michal Hocko wrote:
> > > I do not see any scheduler guys Cced and it would be really great to get
> > > their opinion here.
> > >
> > > On Mon 10-12-18 11:36:39, Daniel Vetter wrote:
> > > > In some special cases we must not block, but there's not a
> > > > spinlock, preempt-off, irqs-off or similar critical section already
> > > > that arms the might_sleep() debug checks. Add a non_block_start/end()
> > > > pair to annotate these.
> > > >
> > > > This will be used in the oom paths of mmu-notifiers, where blocking is
> > > > not allowed to make sure there's forward progress.
> > >
> > > Considering the only alternative would be to abuse
> > > preempt_{disable,enable}, and that really has a different semantic, I
> > > think this makes some sense. The cotext is preemptible but we do not
> > > want notifier to sleep on any locks, WQ etc.
> >
> > I'm confused... what is this supposed to do?
> >
> > And what does 'block' mean here? Without preempt_disable/IRQ-off we're
> > subject to regular preemption and execution can stall for arbitrary
> > amounts of time.
>
> The notifier is called from quite a restricted context - oom_reaper -
> which shouldn't depend on any locks or sleepable conditionals.
You want to exclude spinlocks too? We could maybe frob something with
lockdep if you need that?
> The code
> should be swift as well but we mostly do care about it to make a forward
> progress. Checking for sleepable context is the best thing we could come
> up with that would describe these demands at least partially.
OK, no real objections to the thing. Just so long we're all on the same
page as to what it does and doesn't do ;-)
I suppose you could extend the check to include schedule_debug() as
well, maybe something like:
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index f66920173370..b1aaa278f1af 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -3278,13 +3278,18 @@ static noinline void __schedule_bug(struct task_struct
*prev)
/*
* Various schedule()-time debugging checks and statistics:
*/
-static inline void schedule_debug(struct task_struct *prev)
+static inline void schedule_debug(struct task_struct *prev, bool preempt)
{
#ifdef CONFIG_SCHED_STACK_END_CHECK
if (task_stack_end_corrupted(prev))
panic("corrupted stack end detected inside scheduler\n");
#endif
+#ifdef CONFIG_DEBUG_ATOMIC_SLEEP
+ if (!preempt && prev->state && prev->non_block_count)
+ // splat
+#endif
+
if (unlikely(in_atomic_preempt_off())) {
__schedule_bug(prev);
preempt_count_set(PREEMPT_DISABLED);
@@ -3391,7 +3396,7 @@ static void __sched notrace __schedule(bool preempt)
rq = cpu_rq(cpu);
prev = rq->curr;
- schedule_debug(prev);
+ schedule_debug(prev, preempt);
if (sched_feat(HRTICK))
hrtick_clear(rq);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/5] drm/dp/mst: Configure no_stop_bit correctly for remote i2c xfers
On Fri, Dec 07, 2018 at 12:45:25PM -0800, Dhinakaran Pandiyan wrote: > On Fri, 2018-09-28 at 21:03 +0300, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > We aren't supposed to force a stop+start between every i2c msg > > when performing multi message transfers. This should eg. cause > > the DDC segment address to be reset back to 0 between writing > > the segment address and reading the actual EDID extension block. > > > > To quote the E-DDC spec: > > "... this standard requires that the segment pointer be > > reset to 00h when a NO ACK or a STOP condition is received." > Related question, do you know why the segment and ddc addresses are > defined as 0x30 and 0x50? The E-DDC spec says they should be at 0x60 > and 0xA0/0xA1. The spec uses 'slave_address << 1 | r/w'. -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for mmu notifier debug checks v2 (rev2)
== Series Details == Series: mmu notifier debug checks v2 (rev2) URL : https://patchwork.freedesktop.org/series/53828/ State : failure == Summary == CALLscripts/checksyscalls.sh DESCEND objtool CHK include/generated/compile.h CC kernel/sched/core.o kernel/sched/core.c: In function ‘schedule_debug’: kernel/sched/core.c:3289:37: error: ‘struct task_struct’ has no member named ‘non_block_count’ if (!preempt && prev->state && prev->non_block_count) ^~ scripts/Makefile.build:291: recipe for target 'kernel/sched/core.o' failed make[2]: *** [kernel/sched/core.o] Error 1 scripts/Makefile.build:516: recipe for target 'kernel/sched' failed make[1]: *** [kernel/sched] Error 2 Makefile:1060: recipe for target 'kernel' failed make: *** [kernel] Error 2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Use intel_ types more consistently for watermark code
On Thu, Dec 06, 2018 at 04:54:00PM -0800, Matt Roper wrote:
> Try to be more consistent about intel_* types rather than drm_* types
> for lower-level driver functions.
>
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/i915_drv.h | 5 +-
> drivers/gpu/drm/i915/intel_display.c | 32 ++---
> drivers/gpu/drm/i915/intel_drv.h | 10 +-
> drivers/gpu/drm/i915/intel_pm.c | 250
> ---
> 4 files changed, 134 insertions(+), 163 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 0689e67c966e..7469a7785253 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -281,8 +281,7 @@ struct drm_i915_display_funcs {
> int (*get_fifo_size)(struct drm_i915_private *dev_priv,
>enum i9xx_plane_id i9xx_plane);
> int (*compute_pipe_wm)(struct intel_crtc_state *cstate);
> - int (*compute_intermediate_wm)(struct drm_device *dev,
> -struct intel_crtc *intel_crtc,
> + int (*compute_intermediate_wm)(struct intel_crtc *intel_crtc,
We could omit this argument too since it can be derived from the crtc
state.
Anyways, patch is
Reviewed-by: Ville Syrjälä
> struct intel_crtc_state *newstate);
> void (*initial_watermarks)(struct intel_atomic_state *state,
> struct intel_crtc_state *cstate);
> @@ -290,7 +289,7 @@ struct drm_i915_display_funcs {
>struct intel_crtc_state *cstate);
> void (*optimize_watermarks)(struct intel_atomic_state *state,
> struct intel_crtc_state *cstate);
> - int (*compute_global_watermarks)(struct drm_atomic_state *state);
> + int (*compute_global_watermarks)(struct intel_atomic_state *state);
> void (*update_wm)(struct intel_crtc *crtc);
> int (*modeset_calc_cdclk)(struct drm_atomic_state *state);
> /* Returns the active state of the crtc, and if the crtc is active,
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 07c861884c70..db6004a883c7 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -10661,12 +10661,9 @@ static void intel_crtc_destroy(struct drm_crtc *crtc)
> *
> * Returns true or false.
> */
> -static bool intel_wm_need_update(struct drm_plane *plane,
> - struct drm_plane_state *state)
> +static bool intel_wm_need_update(struct intel_plane_state *cur,
> + struct intel_plane_state *new)
> {
> - struct intel_plane_state *new = to_intel_plane_state(state);
> - struct intel_plane_state *cur = to_intel_plane_state(plane->state);
> -
> /* Update watermarks on tiling or size changes. */
> if (new->base.visible != cur->base.visible)
> return true;
> @@ -10775,7 +10772,8 @@ int intel_plane_atomic_calc_changes(const struct
> intel_crtc_state *old_crtc_stat
> /* must disable cxsr around plane enable/disable */
> if (plane->id != PLANE_CURSOR)
> pipe_config->disable_cxsr = true;
> - } else if (intel_wm_need_update(&plane->base, plane_state)) {
> + } else if (intel_wm_need_update(to_intel_plane_state(plane->base.state),
> + to_intel_plane_state(plane_state))) {
> if (INTEL_GEN(dev_priv) < 5 && !IS_G4X(dev_priv)) {
> /* FIXME bollocks */
> pipe_config->update_wm_pre = true;
> @@ -10954,8 +10952,7 @@ static int icl_check_nv12_planes(struct
> intel_crtc_state *crtc_state)
> static int intel_crtc_atomic_check(struct drm_crtc *crtc,
> struct drm_crtc_state *crtc_state)
> {
> - struct drm_device *dev = crtc->dev;
> - struct drm_i915_private *dev_priv = to_i915(dev);
> + struct drm_i915_private *dev_priv = to_i915(crtc->dev);
> struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> struct intel_crtc_state *pipe_config =
> to_intel_crtc_state(crtc_state);
> @@ -11004,8 +11001,7 @@ static int intel_crtc_atomic_check(struct drm_crtc
> *crtc,
>* old state and the new state. We can program these
>* immediately.
>*/
> - ret = dev_priv->display.compute_intermediate_wm(dev,
> - intel_crtc,
> + ret = dev_priv->display.compute_intermediate_wm(intel_crtc,
> pipe_config);
> if (ret) {
> DRM_DEBUG_KMS("No valid intermediate pipe watermarks
> are possible\n");
> @@ -11964,7 +11960,7 @@ static void verify_wm_state(struct drm_crtc *crtc,
> if (INTEL_GEN(dev_priv) < 9 || !new_s
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Use intel_ types more consistently for color management code
On Thu, Dec 06, 2018 at 04:54:01PM -0800, Matt Roper wrote:
> Try to be more consistent about intel_* types rather than drm_* types
> for lower-level driver functions. While we're at it, let's also be more
> consistent with state variable naming (half of the platforms use the
> name 'state' whereas the other half used 'crtc_state').
>
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/i915_drv.h | 4 +-
> drivers/gpu/drm/i915/intel_color.c | 207
> ---
> drivers/gpu/drm/i915/intel_display.c | 20 ++--
> drivers/gpu/drm/i915/intel_drv.h | 8 +-
> 4 files changed, 112 insertions(+), 127 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 7469a7785253..48fb5e9bd08b 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -321,8 +321,8 @@ struct drm_i915_display_funcs {
> /* display clock increase/decrease */
> /* pll clock increase/decrease */
>
> - void (*load_csc_matrix)(struct drm_crtc_state *crtc_state);
> - void (*load_luts)(struct drm_crtc_state *crtc_state);
> + void (*load_csc_matrix)(struct intel_crtc_state *state);
> + void (*load_luts)(struct intel_crtc_state *state);
> };
>
> #define CSR_VERSION(major, minor)((major) << 16 | (minor))
> diff --git a/drivers/gpu/drm/i915/intel_color.c
> b/drivers/gpu/drm/i915/intel_color.c
> index 5127da286a2b..335c4702fcfb 100644
> --- a/drivers/gpu/drm/i915/intel_color.c
> +++ b/drivers/gpu/drm/i915/intel_color.c
> @@ -74,12 +74,12 @@
> #define ILK_CSC_COEFF_1_0\
> ((7 << 12) | ILK_CSC_COEFF_FP(CTM_COEFF_1_0, 8))
>
> -static bool crtc_state_is_legacy_gamma(struct drm_crtc_state *state)
> +static bool crtc_state_is_legacy_gamma(struct intel_crtc_state *state)
I'd lkike s/state/crtc_state/, at least in the cases where it doesn't
make the diff too noisy.
Or maybe even follow up with a wholesale sed/cocci job to just rename
everything in the file?
Patch is
Reviewed-by: Ville Syrjälä
> {
> - return !state->degamma_lut &&
> - !state->ctm &&
> - state->gamma_lut &&
> - drm_color_lut_size(state->gamma_lut) == LEGACY_LUT_LENGTH;
> + return !state->base.degamma_lut &&
> + !state->base.ctm &&
> + state->base.gamma_lut &&
> + drm_color_lut_size(state->base.gamma_lut) == LEGACY_LUT_LENGTH;
> }
>
> /*
> @@ -108,10 +108,10 @@ static u64 *ctm_mult_by_limited(u64 *result, const u64
> *input)
> return result;
> }
>
> -static void ilk_load_ycbcr_conversion_matrix(struct intel_crtc *intel_crtc)
> +static void ilk_load_ycbcr_conversion_matrix(struct intel_crtc *crtc)
> {
> - int pipe = intel_crtc->pipe;
> - struct drm_i915_private *dev_priv = to_i915(intel_crtc->base.dev);
> + int pipe = crtc->pipe;
> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>
> I915_WRITE(PIPE_CSC_PREOFF_HI(pipe), 0);
> I915_WRITE(PIPE_CSC_PREOFF_ME(pipe), 0);
> @@ -132,14 +132,12 @@ static void ilk_load_ycbcr_conversion_matrix(struct
> intel_crtc *intel_crtc)
> I915_WRITE(PIPE_CSC_MODE(pipe), 0);
> }
>
> -static void ilk_load_csc_matrix(struct drm_crtc_state *crtc_state)
> +static void ilk_load_csc_matrix(struct intel_crtc_state *state)
> {
> - struct drm_crtc *crtc = crtc_state->crtc;
> - struct drm_i915_private *dev_priv = to_i915(crtc->dev);
> - struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> - int i, pipe = intel_crtc->pipe;
> + struct intel_crtc *crtc = to_intel_crtc(state->base.crtc);
> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> + int i, pipe = crtc->pipe;
> uint16_t coeffs[9] = { 0, };
> - struct intel_crtc_state *intel_crtc_state =
> to_intel_crtc_state(crtc_state);
> bool limited_color_range = false;
>
> /*
> @@ -147,14 +145,14 @@ static void ilk_load_csc_matrix(struct drm_crtc_state
> *crtc_state)
>* do the range compression using the gamma LUT instead.
>*/
> if (INTEL_GEN(dev_priv) >= 8 || IS_HASWELL(dev_priv))
> - limited_color_range = intel_crtc_state->limited_color_range;
> + limited_color_range = state->limited_color_range;
>
> - if (intel_crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420 ||
> - intel_crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR444) {
> - ilk_load_ycbcr_conversion_matrix(intel_crtc);
> + if (state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420 ||
> + state->output_format == INTEL_OUTPUT_FORMAT_YCBCR444) {
> + ilk_load_ycbcr_conversion_matrix(crtc);
> return;
> - } else if (crtc_state->ctm) {
> - struct drm_color_ctm *ctm = crtc_state->ctm->data;
> + } else if (state->base.ctm) {
> + struct drm_color_ctm *ctm = state->base.ctm->data;
> const u64 *input;
>
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Remove a very stale FIXME
On Thu, Dec 06, 2018 at 09:09:42AM -0800, Matt Roper wrote:
> SKL watermark calculations can and do trigger atomic transaction
> rejection if no valid set of watermarks can be found. This FIXME
> comment in the code hasn't been relevant for a very long time.
Identical patch already pushed.
>
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/intel_pm.c | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index a26b4eddda25..9500bda64f26 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -5548,10 +5548,6 @@ skl_compute_wm(struct drm_atomic_state *state)
>* Note that the DDB allocation above may have added more CRTC's that
>* weren't otherwise being modified (and set bits in dirty_pipes) if
>* pipe allocations had to change.
> - *
> - * FIXME: Now that we're doing this in the atomic check phase, we
> - * should allow skl_update_pipe_wm() to return failure in cases where
> - * no suitable watermark values can be found.
>*/
> for_each_new_crtc_in_state(state, crtc, cstate, i) {
> struct intel_crtc_state *intel_cstate =
> --
> 2.14.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/5] drm/dp/mst: Configure no_stop_bit correctly for remote i2c xfers
On Mon, 2018-12-10 at 18:39 +0200, Ville Syrjälä wrote: > On Fri, Dec 07, 2018 at 12:45:25PM -0800, Dhinakaran Pandiyan wrote: > > On Fri, 2018-09-28 at 21:03 +0300, Ville Syrjala wrote: > > > From: Ville Syrjälä > > > > > > We aren't supposed to force a stop+start between every i2c msg > > > when performing multi message transfers. This should eg. cause > > > the DDC segment address to be reset back to 0 between writing > > > the segment address and reading the actual EDID extension block. > > > > > > To quote the E-DDC spec: > > > "... this standard requires that the segment pointer be > > > reset to 00h when a NO ACK or a STOP condition is received." > > > > Related question, do you know why the segment and ddc addresses are > > defined as 0x30 and 0x50? The E-DDC spec says they should be at > > 0x60 > > and 0xA0/0xA1. > > The spec uses 'slave_address << 1 | r/w'. Got it, thanks. -DK ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Switch to level-based DDB allocation algorithm (v2)
On Thu, Dec 06, 2018 at 03:55:41PM -0800, Matt Roper wrote:
> The DDB allocation algorithm currently used by the driver grants each
> plane a very small minimum allocation of DDB blocks and then divies up
> all of the remaining blocks based on the percentage of the total data
> rate that the plane makes up. It turns out that this proportional
> allocation approach is overly-generous with the larger planes and can
> leave very small planes wthout a big enough allocation to even hit their
> level 0 watermark requirements (especially on APL, which has a smaller
> DDB in general than other gen9 platforms). Or there can be situations
> where the smallest planes hit a lower watermark level than they should
> have been able to hit with a more equitable division of DDB blocks, thus
> limiting the overall system sleep state that can be achieved.
>
> The bspec now describes an alternate algorithm that can be used to
> overcome these types of issues. With the new algorithm, we calculate
> all plane watermark values for all wm levels first, then go back and
> partition a pipe's DDB space second. The DDB allocation will calculate
> what the highest watermark level that can be achieved on *all* active
> planes, and then grant the blocks necessary to hit that level to each
> plane. Any remaining blocks are then divided up proportionally
> according to data rate, similar to the old algorithm.
OK, so it's somewhat similar to what I already did for VLV/CHV. The
difference being that on VLV/CHV I distribute purely based on the
level 0 watermark and don't even consider the data rates. Not sure
if there's a significant difference between the two approaches.
>
> There was a previous attempt to implement this algorithm a couple years
> ago in bb9d85f6e9d ("drm/i915/skl: New ddb allocation algorithm"), but
> some regressions were reported, the patch was reverted, and nobody
> ever got around to figuring out exactly where the bug was in that
> version. Our watermark code has evolved significantly in the meantime,
> but we're still getting bug reports caused by the unfair proportional
> algorithm, so let's give this another shot.
>
> v2:
> - Make sure cursor allocation stays constant and fixed at the end of
>the pipe allocation.
> - Fix some watermark level iterators that weren't handling the max
>level.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105458
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/intel_pm.c | 350
> +++-
> 1 file changed, 129 insertions(+), 221 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index b09c2a257ff1..6db2bf7b037c 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -4306,102 +4306,6 @@ icl_get_total_relative_data_rate(struct
> intel_crtc_state *intel_cstate,
> return total_data_rate;
> }
>
> -static uint16_t
> -skl_ddb_min_alloc(const struct drm_plane_state *pstate, const int plane)
> -{
> - struct drm_framebuffer *fb = pstate->fb;
> - struct intel_plane_state *intel_pstate = to_intel_plane_state(pstate);
> - uint32_t src_w, src_h;
> - uint32_t min_scanlines = 8;
> - uint8_t plane_bpp;
> -
> - if (WARN_ON(!fb))
> - return 0;
> -
> - /* For packed formats, and uv-plane, return 0 */
> - if (plane == 1 && fb->format->format != DRM_FORMAT_NV12)
> - return 0;
> -
> - /* For Non Y-tile return 8-blocks */
> - if (fb->modifier != I915_FORMAT_MOD_Y_TILED &&
> - fb->modifier != I915_FORMAT_MOD_Yf_TILED &&
> - fb->modifier != I915_FORMAT_MOD_Y_TILED_CCS &&
> - fb->modifier != I915_FORMAT_MOD_Yf_TILED_CCS)
> - return 8;
> -
> - /*
> - * Src coordinates are already rotated by 270 degrees for
> - * the 90/270 degree plane rotation cases (to match the
> - * GTT mapping), hence no need to account for rotation here.
> - */
> - src_w = drm_rect_width(&intel_pstate->base.src) >> 16;
> - src_h = drm_rect_height(&intel_pstate->base.src) >> 16;
> -
> - /* Halve UV plane width and height for NV12 */
> - if (plane == 1) {
> - src_w /= 2;
> - src_h /= 2;
> - }
> -
> - plane_bpp = fb->format->cpp[plane];
> -
> - if (drm_rotation_90_or_270(pstate->rotation)) {
> - switch (plane_bpp) {
> - case 1:
> - min_scanlines = 32;
> - break;
> - case 2:
> - min_scanlines = 16;
> - break;
> - case 4:
> - min_scanlines = 8;
> - break;
> - case 8:
> - min_scanlines = 4;
> - break;
> - default:
> - WARN(1, "Unsupported pixel depth %u for rotation",
> - plane_bpp);
> - min_scanlines = 32;
> -
[Intel-gfx] [PATCH] drm/dp: Set the MOT bit for Write_Status_Update_Request transactions
The Write_Status_Update_Request I2C transaction requires the MOT bit to
be set, Change the logical AND to OR to fix what looks like a typo.
Cc: dri-de...@lists.freedesktop.org
Cc: Jani Nikula
Cc: Ville Syrjälä
Fixes: 68ec2a2a2481 ("drm/dp: Use I2C_WRITE_STATUS_UPDATE to drain partial
I2C_WRITE requests")
Signed-off-by: Dhinakaran Pandiyan
---
drivers/gpu/drm/drm_dp_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 2d6c491a0542..d98805b517f0 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -677,7 +677,7 @@ static void drm_dp_i2c_msg_write_status_update(struct
drm_dp_aux_msg *msg)
* rest of the message
*/
if ((msg->request & ~DP_AUX_I2C_MOT) == DP_AUX_I2C_WRITE) {
- msg->request &= DP_AUX_I2C_MOT;
+ msg->request |= DP_AUX_I2C_MOT;
msg->request |= DP_AUX_I2C_WRITE_STATUS_UPDATE;
}
}
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/dp: Set the MOT bit for Write_Status_Update_Request transactions
On Mon, Dec 10, 2018 at 01:07:49PM -0800, Dhinakaran Pandiyan wrote:
> The Write_Status_Update_Request I2C transaction requires the MOT bit to
> be set, Change the logical AND to OR to fix what looks like a typo.
It's not a type. We're just preserving MOT. What makes you think it
should always be set?
>
> Cc: dri-de...@lists.freedesktop.org
> Cc: Jani Nikula
> Cc: Ville Syrjälä
> Fixes: 68ec2a2a2481 ("drm/dp: Use I2C_WRITE_STATUS_UPDATE to drain partial
> I2C_WRITE requests")
> Signed-off-by: Dhinakaran Pandiyan
> ---
> drivers/gpu/drm/drm_dp_helper.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 2d6c491a0542..d98805b517f0 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -677,7 +677,7 @@ static void drm_dp_i2c_msg_write_status_update(struct
> drm_dp_aux_msg *msg)
>* rest of the message
>*/
> if ((msg->request & ~DP_AUX_I2C_MOT) == DP_AUX_I2C_WRITE) {
> - msg->request &= DP_AUX_I2C_MOT;
> + msg->request |= DP_AUX_I2C_MOT;
> msg->request |= DP_AUX_I2C_WRITE_STATUS_UPDATE;
> }
> }
> --
> 2.17.1
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/7] legacy helper cleanup
On Mon, Dec 10, 2018 at 5:04 AM Daniel Vetter wrote: > > Hi all, > > Just a small cleanup motivated by the last patch. After this series atomic > drivers do no longer need the drm_crtc_helper.h header, and none of them > use it. Except for the 2 that support both atomic and legacy kms in the > same driver module (nouveau and amdgpu). > > Last patch is a bit huge, but splitting it up will make the churn only > worse. > > Comments and review very much appreciated. Some comments on patch 4, 1-3,4-6 are: Reviewed-by: Alex Deucher Assuming the build issues reported with patch 7 are fixed: Reviewed-by: Alex Deucher > > Cheers, Daniel > > Daniel Vetter (7): > drm/ch7006: Stop using drm_crtc_force_disable > drm/nouveau: Stop using drm_crtc_force_disable > drm: Unexport drm_crtc_force_disable > drm: Move the legacy kms disable_all helper to crtc helpers > drm/qxl: Don't set the dpms hook > drm/xen: Don't set the dpms hook > drm: Split out drm_probe_helper.h > > .../gpu/drm/amd/amdgpu/amdgpu_connectors.c| 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 4 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 1 + > .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 +- > .../amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c | 2 +- > .../display/amdgpu_dm/amdgpu_dm_services.c| 2 +- > drivers/gpu/drm/arc/arcpgu_crtc.c | 2 +- > drivers/gpu/drm/arc/arcpgu_drv.c | 2 +- > drivers/gpu/drm/arc/arcpgu_sim.c | 2 +- > drivers/gpu/drm/arm/hdlcd_crtc.c | 2 +- > drivers/gpu/drm/arm/hdlcd_drv.c | 2 +- > drivers/gpu/drm/arm/malidp_crtc.c | 2 +- > drivers/gpu/drm/arm/malidp_drv.c | 2 +- > drivers/gpu/drm/arm/malidp_mw.c | 2 +- > drivers/gpu/drm/armada/armada_510.c | 2 +- > drivers/gpu/drm/armada/armada_crtc.c | 2 +- > drivers/gpu/drm/armada/armada_drv.c | 2 +- > drivers/gpu/drm/armada/armada_fb.c| 2 +- > drivers/gpu/drm/ast/ast_drv.c | 1 + > drivers/gpu/drm/ast/ast_mode.c| 1 + > .../gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c| 2 +- > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 2 +- > drivers/gpu/drm/bochs/bochs_drv.c | 1 + > drivers/gpu/drm/bochs/bochs_kms.c | 1 + > drivers/gpu/drm/bridge/adv7511/adv7511.h | 2 +- > drivers/gpu/drm/bridge/analogix-anx78xx.c | 3 +- > .../drm/bridge/analogix/analogix_dp_core.c| 2 +- > drivers/gpu/drm/bridge/cdns-dsi.c | 2 +- > drivers/gpu/drm/bridge/dumb-vga-dac.c | 2 +- > .../bridge/megachips-stdp-ge-b850v3-fw.c | 2 +- > drivers/gpu/drm/bridge/nxp-ptn3460.c | 2 +- > drivers/gpu/drm/bridge/panel.c| 2 +- > drivers/gpu/drm/bridge/parade-ps8622.c| 2 +- > drivers/gpu/drm/bridge/sii902x.c | 2 +- > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +- > drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 2 +- > drivers/gpu/drm/bridge/tc358764.c | 2 +- > drivers/gpu/drm/bridge/tc358767.c | 2 +- > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 2 +- > drivers/gpu/drm/bridge/ti-tfp410.c| 2 +- > drivers/gpu/drm/cirrus/cirrus_drv.c | 1 + > drivers/gpu/drm/cirrus/cirrus_mode.c | 1 + > drivers/gpu/drm/drm_atomic_helper.c | 1 - > drivers/gpu/drm/drm_crtc.c| 41 --- > drivers/gpu/drm/drm_crtc_helper.c | 35 + > drivers/gpu/drm/drm_crtc_internal.h | 1 + > drivers/gpu/drm/drm_dp_mst_topology.c | 2 +- > drivers/gpu/drm/drm_modeset_helper.c | 2 +- > drivers/gpu/drm/drm_probe_helper.c| 2 +- > drivers/gpu/drm/drm_simple_kms_helper.c | 2 +- > drivers/gpu/drm/etnaviv/etnaviv_drv.h | 1 - > drivers/gpu/drm/exynos/exynos_dp.c| 2 +- > drivers/gpu/drm/exynos/exynos_drm_crtc.c | 2 +- > drivers/gpu/drm/exynos/exynos_drm_dpi.c | 2 +- > drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +- > drivers/gpu/drm/exynos/exynos_drm_dsi.c | 2 +- > drivers/gpu/drm/exynos/exynos_drm_fb.c| 2 +- > drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 2 +- > drivers/gpu/drm/exynos/exynos_drm_vidi.c | 2 +- > drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +- > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c| 2 +- > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 2 +- > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c | 2 +- > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c | 2 +- > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 2 +- > drivers/gpu/drm/gma500/psb_intel_drv.h| 1 + > .../gpu/drm/hisilicon/hibmc/hibmc_drm_de.c| 2 +- > .../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 2 +- > .../gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c | 2 +- > .../gpu/d
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/dp: Set the MOT bit for Write_Status_Update_Request transactions
== Series Details ==
Series: drm/dp: Set the MOT bit for Write_Status_Update_Request transactions
URL : https://patchwork.freedesktop.org/series/53851/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5292 -> Patchwork_11058
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/53851/revisions/1/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_11058:
### IGT changes ###
Warnings
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-c:
- {fi-kbl-7567u}: PASS -> SKIP +33
* igt@prime_vgem@basic-fence-flip:
- {fi-kbl-7500u}: SKIP -> PASS +36
Known issues
Here are the changes found in Patchwork_11058 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-icl-u2: NOTRUN -> DMESG-FAIL [fdo#103375] / [fdo#107732] /
[fdo#108070] / [fdo#108924]
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362] +1
* igt@pm_rpm@module-reload:
- fi-skl-6770hq: PASS -> DMESG-WARN [fdo#105541]
* {igt@runner@aborted}:
- fi-icl-u2: NOTRUN -> FAIL [fdo#108070]
- {fi-icl-y}: NOTRUN -> FAIL [fdo#108070]
Possible fixes
* igt@gem_ctx_create@basic-files:
- fi-bsw-kefka: FAIL [fdo#108656] -> PASS
* igt@i915_selftest@live_gem:
- fi-bsw-n3050: DMESG-WARN [fdo#108797] -> PASS
* igt@i915_selftest@live_hangcheck:
- fi-cfl-8109u: INCOMPLETE [fdo#106070] -> PASS
- fi-kbl-7560u: INCOMPLETE [fdo#108044] -> PASS
* igt@kms_chamelium@dp-crc-fast:
- {fi-kbl-7500u}: FAIL [fdo#103841] / [fdo#108767] -> PASS +4
* igt@kms_chamelium@vga-hpd-fast:
- {fi-kbl-7500u}: FAIL [fdo#103841] / [fdo#108767] -> SKIP +1
* igt@kms_frontbuffer_tracking@basic:
- fi-byt-clapper: FAIL [fdo#103167] -> PASS
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b:
- fi-byt-clapper: FAIL [fdo#107362] -> PASS
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-cfl-8109u: DMESG-WARN [fdo#109000] -> PASS
Warnings
* igt@kms_chamelium@common-hpd-after-suspend:
- {fi-kbl-7500u}: FAIL [fdo#103841] / [fdo#108767] -> DMESG-WARN
[fdo#102505] / [fdo#103558] / [fdo#105079] / [fdo#105602]
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102505]: https://bugs.freedesktop.org/show_bug.cgi?id=102505
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
[fdo#103558]: https://bugs.freedesktop.org/show_bug.cgi?id=103558
[fdo#103841]: https://bugs.freedesktop.org/show_bug.cgi?id=103841
[fdo#105079]: https://bugs.freedesktop.org/show_bug.cgi?id=105079
[fdo#105541]: https://bugs.freedesktop.org/show_bug.cgi?id=105541
[fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
[fdo#106070]: https://bugs.freedesktop.org/show_bug.cgi?id=106070
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107732]: https://bugs.freedesktop.org/show_bug.cgi?id=107732
[fdo#108044]: https://bugs.freedesktop.org/show_bug.cgi?id=108044
[fdo#108070]: https://bugs.freedesktop.org/show_bug.cgi?id=108070
[fdo#108656]: https://bugs.freedesktop.org/show_bug.cgi?id=108656
[fdo#108767]: https://bugs.freedesktop.org/show_bug.cgi?id=108767
[fdo#108797]: https://bugs.freedesktop.org/show_bug.cgi?id=108797
[fdo#108924]: https://bugs.freedesktop.org/show_bug.cgi?id=108924
[fdo#109000]: https://bugs.freedesktop.org/show_bug.cgi?id=109000
Participating hosts (50 -> 45)
--
Additional (2): fi-icl-y fi-icl-u2
Missing(7): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-icl-u3 fi-pnv-d510
Build changes
-
* Linux: CI_DRM_5292 -> Patchwork_11058
CI_DRM_5292: ec6b8cacbc8777a77119fa7af7e2930fe186091b @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4744: 4579ac1d445cf39f6de474071b20db790db575bd @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_11058: 5a89c8fa24b15684d5fbad18b8dd41d7366e6c80 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
5a89c8fa24b1 drm/dp: Set the MOT bit for Write_Status_Update_Request
transactions
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11058/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/dp: Set the MOT bit for Write_Status_Update_Request transactions
On Mon, Dec 10, 2018 at 11:29:06PM +0200, Ville Syrjälä wrote:
> On Mon, Dec 10, 2018 at 01:07:49PM -0800, Dhinakaran Pandiyan wrote:
> > The Write_Status_Update_Request I2C transaction requires the MOT bit to
> > be set, Change the logical AND to OR to fix what looks like a typo.
>
> It's not a type.
^
But this is :P
> We're just preserving MOT. What makes you think it
> should always be set?
>
> >
> > Cc: dri-de...@lists.freedesktop.org
> > Cc: Jani Nikula
> > Cc: Ville Syrjälä
> > Fixes: 68ec2a2a2481 ("drm/dp: Use I2C_WRITE_STATUS_UPDATE to drain partial
> > I2C_WRITE requests")
> > Signed-off-by: Dhinakaran Pandiyan
> > ---
> > drivers/gpu/drm/drm_dp_helper.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_helper.c
> > b/drivers/gpu/drm/drm_dp_helper.c
> > index 2d6c491a0542..d98805b517f0 100644
> > --- a/drivers/gpu/drm/drm_dp_helper.c
> > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > @@ -677,7 +677,7 @@ static void drm_dp_i2c_msg_write_status_update(struct
> > drm_dp_aux_msg *msg)
> > * rest of the message
> > */
> > if ((msg->request & ~DP_AUX_I2C_MOT) == DP_AUX_I2C_WRITE) {
> > - msg->request &= DP_AUX_I2C_MOT;
> > + msg->request |= DP_AUX_I2C_MOT;
> > msg->request |= DP_AUX_I2C_WRITE_STATUS_UPDATE;
> > }
> > }
> > --
> > 2.17.1
>
> --
> Ville Syrjälä
> Intel
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/2] drm/i915: Use intel_ types more consistently for color management code (v2)
Try to be more consistent about intel_* types rather than drm_* types
for lower-level driver functions. While we're at it, let's also be more
consistent with state variable naming (half of the platforms use the
name 'state' whereas the other half used 'crtc_state').
While we're touching these variables, let's also be more consistent
about always naming the intel_crtc_state's "crtc_state" rather than
"state" so that different platform types aren't using different naming
conventions.
v2:
- s/state/crtc_state/ for consistency between platform types (Ville)
- Drop the crtc parameter to intel_color_check(); we can just pull that
out of the state object.
Signed-off-by: Matt Roper
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 4 +-
drivers/gpu/drm/i915/intel_color.c | 215 ---
drivers/gpu/drm/i915/intel_display.c | 20 ++--
drivers/gpu/drm/i915/intel_drv.h | 8 +-
4 files changed, 117 insertions(+), 130 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 330fc0d39c8d..e70707e79386 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -320,8 +320,8 @@ struct drm_i915_display_funcs {
/* display clock increase/decrease */
/* pll clock increase/decrease */
- void (*load_csc_matrix)(struct drm_crtc_state *crtc_state);
- void (*load_luts)(struct drm_crtc_state *crtc_state);
+ void (*load_csc_matrix)(struct intel_crtc_state *crtc_state);
+ void (*load_luts)(struct intel_crtc_state *crtc_state);
};
#define CSR_VERSION(major, minor) ((major) << 16 | (minor))
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index 5127da286a2b..1d572e83db7f 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -74,12 +74,14 @@
#define ILK_CSC_COEFF_1_0 \
((7 << 12) | ILK_CSC_COEFF_FP(CTM_COEFF_1_0, 8))
-static bool crtc_state_is_legacy_gamma(struct drm_crtc_state *state)
+static bool crtc_state_is_legacy_gamma(struct intel_crtc_state *crtc_state)
{
- return !state->degamma_lut &&
- !state->ctm &&
- state->gamma_lut &&
- drm_color_lut_size(state->gamma_lut) == LEGACY_LUT_LENGTH;
+ int lut_length = drm_color_lut_size(crtc_state->base.gamma_lut);
+
+ return !crtc_state->base.degamma_lut &&
+ !crtc_state->base.ctm &&
+ crtc_state->base.gamma_lut &&
+ lut_length == LEGACY_LUT_LENGTH;
}
/*
@@ -108,10 +110,10 @@ static u64 *ctm_mult_by_limited(u64 *result, const u64
*input)
return result;
}
-static void ilk_load_ycbcr_conversion_matrix(struct intel_crtc *intel_crtc)
+static void ilk_load_ycbcr_conversion_matrix(struct intel_crtc *crtc)
{
- int pipe = intel_crtc->pipe;
- struct drm_i915_private *dev_priv = to_i915(intel_crtc->base.dev);
+ int pipe = crtc->pipe;
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
I915_WRITE(PIPE_CSC_PREOFF_HI(pipe), 0);
I915_WRITE(PIPE_CSC_PREOFF_ME(pipe), 0);
@@ -132,14 +134,12 @@ static void ilk_load_ycbcr_conversion_matrix(struct
intel_crtc *intel_crtc)
I915_WRITE(PIPE_CSC_MODE(pipe), 0);
}
-static void ilk_load_csc_matrix(struct drm_crtc_state *crtc_state)
+static void ilk_load_csc_matrix(struct intel_crtc_state *crtc_state)
{
- struct drm_crtc *crtc = crtc_state->crtc;
- struct drm_i915_private *dev_priv = to_i915(crtc->dev);
- struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
- int i, pipe = intel_crtc->pipe;
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ int i, pipe = crtc->pipe;
uint16_t coeffs[9] = { 0, };
- struct intel_crtc_state *intel_crtc_state =
to_intel_crtc_state(crtc_state);
bool limited_color_range = false;
/*
@@ -147,14 +147,14 @@ static void ilk_load_csc_matrix(struct drm_crtc_state
*crtc_state)
* do the range compression using the gamma LUT instead.
*/
if (INTEL_GEN(dev_priv) >= 8 || IS_HASWELL(dev_priv))
- limited_color_range = intel_crtc_state->limited_color_range;
+ limited_color_range = crtc_state->limited_color_range;
- if (intel_crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420 ||
- intel_crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR444) {
- ilk_load_ycbcr_conversion_matrix(intel_crtc);
+ if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420 ||
+ crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR444) {
+ ilk_load_ycbcr_conversion_matrix(crtc);
return;
- } else if (crtc_state->ctm) {
- struct drm_color_ctm *ctm = crtc_state->ctm->data;
+ } else if (crtc_state->b
[Intel-gfx] [PATCH v2 1/2] drm/i915: Use intel_ types more consistently for watermark code (v2)
Try to be more consistent about intel_* types rather than drm_* types
for lower-level driver functions.
v2:
- Also drop the intel_crtc parameter from compute_intermediate_wm()
since we can just extract it from the crtc_state parameter. (Ville)
Signed-off-by: Matt Roper
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 6 +-
drivers/gpu/drm/i915/intel_display.c | 33 ++---
drivers/gpu/drm/i915/intel_drv.h | 10 +-
drivers/gpu/drm/i915/intel_pm.c | 255 ---
4 files changed, 137 insertions(+), 167 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0689e67c966e..330fc0d39c8d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -281,16 +281,14 @@ struct drm_i915_display_funcs {
int (*get_fifo_size)(struct drm_i915_private *dev_priv,
enum i9xx_plane_id i9xx_plane);
int (*compute_pipe_wm)(struct intel_crtc_state *cstate);
- int (*compute_intermediate_wm)(struct drm_device *dev,
- struct intel_crtc *intel_crtc,
- struct intel_crtc_state *newstate);
+ int (*compute_intermediate_wm)(struct intel_crtc_state *newstate);
void (*initial_watermarks)(struct intel_atomic_state *state,
struct intel_crtc_state *cstate);
void (*atomic_update_watermarks)(struct intel_atomic_state *state,
struct intel_crtc_state *cstate);
void (*optimize_watermarks)(struct intel_atomic_state *state,
struct intel_crtc_state *cstate);
- int (*compute_global_watermarks)(struct drm_atomic_state *state);
+ int (*compute_global_watermarks)(struct intel_atomic_state *state);
void (*update_wm)(struct intel_crtc *crtc);
int (*modeset_calc_cdclk)(struct drm_atomic_state *state);
/* Returns the active state of the crtc, and if the crtc is active,
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 07c861884c70..943d6832b05d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10661,12 +10661,9 @@ static void intel_crtc_destroy(struct drm_crtc *crtc)
*
* Returns true or false.
*/
-static bool intel_wm_need_update(struct drm_plane *plane,
-struct drm_plane_state *state)
+static bool intel_wm_need_update(struct intel_plane_state *cur,
+struct intel_plane_state *new)
{
- struct intel_plane_state *new = to_intel_plane_state(state);
- struct intel_plane_state *cur = to_intel_plane_state(plane->state);
-
/* Update watermarks on tiling or size changes. */
if (new->base.visible != cur->base.visible)
return true;
@@ -10775,7 +10772,8 @@ int intel_plane_atomic_calc_changes(const struct
intel_crtc_state *old_crtc_stat
/* must disable cxsr around plane enable/disable */
if (plane->id != PLANE_CURSOR)
pipe_config->disable_cxsr = true;
- } else if (intel_wm_need_update(&plane->base, plane_state)) {
+ } else if (intel_wm_need_update(to_intel_plane_state(plane->base.state),
+ to_intel_plane_state(plane_state))) {
if (INTEL_GEN(dev_priv) < 5 && !IS_G4X(dev_priv)) {
/* FIXME bollocks */
pipe_config->update_wm_pre = true;
@@ -10954,8 +10952,7 @@ static int icl_check_nv12_planes(struct
intel_crtc_state *crtc_state)
static int intel_crtc_atomic_check(struct drm_crtc *crtc,
struct drm_crtc_state *crtc_state)
{
- struct drm_device *dev = crtc->dev;
- struct drm_i915_private *dev_priv = to_i915(dev);
+ struct drm_i915_private *dev_priv = to_i915(crtc->dev);
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
struct intel_crtc_state *pipe_config =
to_intel_crtc_state(crtc_state);
@@ -11004,9 +11001,7 @@ static int intel_crtc_atomic_check(struct drm_crtc
*crtc,
* old state and the new state. We can program these
* immediately.
*/
- ret = dev_priv->display.compute_intermediate_wm(dev,
- intel_crtc,
- pipe_config);
+ ret = dev_priv->display.compute_intermediate_wm(pipe_config);
if (ret) {
DRM_DEBUG_KMS("No valid intermediate pipe watermarks
are possible\n");
return ret;
@@ -11964,7 +11959,7 @@ static void verify_wm_state(struct drm_crtc *crtc,
if (INTEL_GEN(dev_priv) < 9 || !new_state->active)
Re: [Intel-gfx] [PATCH 1/2] drm/i915/huc: Update the HuC version for BXT
On Fri, Dec 07, 2018 at 10:28:39AM -0800, Anusha wrote: > From: Anusha Srivatsa > > We have an update for HuC for BXT. > Load the latest version. > > v2: Change the subject. > > Cc: Rodrigo Vivi > Signed-off-by: Anusha Srivatsa > --- > drivers/gpu/drm/i915/intel_huc_fw.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_huc_fw.c > b/drivers/gpu/drm/i915/intel_huc_fw.c > index f93d2384d482..9612227b3c44 100644 > --- a/drivers/gpu/drm/i915/intel_huc_fw.c > +++ b/drivers/gpu/drm/i915/intel_huc_fw.c > @@ -23,8 +23,8 @@ > */ > > #define BXT_HUC_FW_MAJOR 01 > -#define BXT_HUC_FW_MINOR 07 > -#define BXT_BLD_NUM 1398 > +#define BXT_HUC_FW_MINOR 8 > +#define BXT_BLD_NUM 2893 Reviewed-by: Rodrigo Vivi (but holding on fw availability in some master branch) > > #define SKL_HUC_FW_MAJOR 01 > #define SKL_HUC_FW_MINOR 07 > -- > 2.19.2 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v2,1/2] drm/i915: Use intel_ types more consistently for watermark code (v2)
== Series Details ==
Series: series starting with [v2,1/2] drm/i915: Use intel_ types more
consistently for watermark code (v2)
URL : https://patchwork.freedesktop.org/series/53859/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
9e0248a8ff62 drm/i915: Use intel_ types more consistently for watermark code
(v2)
13f395be drm/i915: Use intel_ types more consistently for color management
code (v2)
-:220: CHECK:UNNECESSARY_PARENTHESES: Unnecessary parentheses around
'crtc_state->gamma_mode == GAMMA_MODE_MODE_SPLIT'
#220: FILE: drivers/gpu/drm/i915/intel_color.c:369:
+ if (IS_HASWELL(dev_priv) && crtc_state->ips_enabled &&
+ (crtc_state->gamma_mode == GAMMA_MODE_MODE_SPLIT)) {
total: 0 errors, 0 warnings, 1 checks, 513 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v2,1/2] drm/i915: Use intel_ types more consistently for watermark code (v2)
== Series Details == Series: series starting with [v2,1/2] drm/i915: Use intel_ types more consistently for watermark code (v2) URL : https://patchwork.freedesktop.org/series/53859/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Use intel_ types more consistently for watermark code (v2) -drivers/gpu/drm/i915/selftests/../i915_drv.h:3563:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3561:16: warning: expression using sizeof(void) Commit: drm/i915: Use intel_ types more consistently for color management code (v2) Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/dp: Set the MOT bit for Write_Status_Update_Request transactions
On Mon, 2018-12-10 at 23:29 +0200, Ville Syrjälä wrote:
> On Mon, Dec 10, 2018 at 01:07:49PM -0800, Dhinakaran Pandiyan wrote:
> > The Write_Status_Update_Request I2C transaction requires the MOT
> > bit to
> > be set, Change the logical AND to OR to fix what looks like a typo.
>
> It's not a type. We're just preserving MOT. What makes you think it
> should always be set?
>
The table defining request commands (2-148) has the MOT bit set for
Write_Status_Update_Request, doesn't make it look like an option when
querying the status. Checking the callers again, I see that we could
get a defer when ending an i2c transaction and that will require a
Write_Status_Update_Request with MOT unset. Sorry for the noise.
> >
> > Cc: dri-de...@lists.freedesktop.org
> > Cc: Jani Nikula
> > Cc: Ville Syrjälä
> > Fixes: 68ec2a2a2481 ("drm/dp: Use I2C_WRITE_STATUS_UPDATE to drain
> > partial I2C_WRITE requests")
> > Signed-off-by: Dhinakaran Pandiyan
> > ---
> > drivers/gpu/drm/drm_dp_helper.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_helper.c
> > b/drivers/gpu/drm/drm_dp_helper.c
> > index 2d6c491a0542..d98805b517f0 100644
> > --- a/drivers/gpu/drm/drm_dp_helper.c
> > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > @@ -677,7 +677,7 @@ static void
> > drm_dp_i2c_msg_write_status_update(struct drm_dp_aux_msg *msg)
> > * rest of the message
> > */
> > if ((msg->request & ~DP_AUX_I2C_MOT) == DP_AUX_I2C_WRITE) {
> > - msg->request &= DP_AUX_I2C_MOT;
> > + msg->request |= DP_AUX_I2C_MOT;
> > msg->request |= DP_AUX_I2C_WRITE_STATUS_UPDATE;
> > }
> > }
> > --
> > 2.17.1
>
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/2] drm/i915: Use intel_ types more consistently for watermark code (v2)
== Series Details ==
Series: series starting with [v2,1/2] drm/i915: Use intel_ types more
consistently for watermark code (v2)
URL : https://patchwork.freedesktop.org/series/53859/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5293 -> Patchwork_11059
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/53859/revisions/1/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_11059:
### IGT changes ###
Warnings
* igt@kms_busy@basic-flip-a:
- {fi-kbl-7567u}: SKIP -> PASS +2
Known issues
Here are the changes found in Patchwork_11059 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_chamelium@hdmi-hpd-fast:
- {fi-kbl-7500u}: PASS -> FAIL [fdo#108767]
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b-frame-sequence:
- fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362] +1
* igt@kms_pipe_crc_basic@read-crc-pipe-b:
- fi-byt-clapper: PASS -> FAIL [fdo#107362]
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718]
* {igt@runner@aborted}:
- {fi-icl-y}: NOTRUN -> FAIL [fdo#108070]
Possible fixes
* igt@i915_selftest@live_coherency:
- fi-gdg-551: DMESG-FAIL [fdo#107164] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#107164]: https://bugs.freedesktop.org/show_bug.cgi?id=107164
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108070]: https://bugs.freedesktop.org/show_bug.cgi?id=108070
[fdo#108767]: https://bugs.freedesktop.org/show_bug.cgi?id=108767
Participating hosts (49 -> 44)
--
Additional (2): fi-icl-y fi-pnv-d510
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-bsw-n3050 fi-byt-squawks
fi-bsw-cyan fi-ctg-p8600 fi-bsw-kefka
Build changes
-
* Linux: CI_DRM_5293 -> Patchwork_11059
CI_DRM_5293: 06fd585c6c31f4c5f2de71b0901f3d10e44f6439 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4744: 4579ac1d445cf39f6de474071b20db790db575bd @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_11059: 13f395bec9eed8f47301c3021fc4f7253d83 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
13f395be drm/i915: Use intel_ types more consistently for color management
code (v2)
9e0248a8ff62 drm/i915: Use intel_ types more consistently for watermark code
(v2)
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11059/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/dp: Set the MOT bit for Write_Status_Update_Request transactions
== Series Details ==
Series: drm/dp: Set the MOT bit for Write_Status_Update_Request transactions
URL : https://patchwork.freedesktop.org/series/53851/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5292_full -> Patchwork_11058_full
Summary
---
**WARNING**
Minor unknown changes coming with Patchwork_11058_full need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_11058_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_11058_full:
### IGT changes ###
Warnings
* igt@kms_vblank@pipe-b-wait-busy:
- shard-snb: PASS -> SKIP
Known issues
Here are the changes found in Patchwork_11058_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@i915_suspend@sysfs-reader:
- shard-skl: PASS -> INCOMPLETE [fdo#104108] / [fdo#107773]
* igt@kms_busy@extended-modeset-hang-newfb-render-a:
- {shard-iclb}: PASS -> DMESG-WARN [fdo#107956]
* igt@kms_busy@extended-modeset-hang-newfb-render-b:
- {shard-iclb}: NOTRUN -> DMESG-WARN [fdo#107956]
* igt@kms_color@pipe-b-degamma:
- shard-apl: PASS -> FAIL [fdo#104782] +1
* igt@kms_cursor_crc@cursor-128x128-suspend:
- shard-apl: PASS -> FAIL [fdo#103191] / [fdo#103232]
* igt@kms_cursor_crc@cursor-128x42-onscreen:
- shard-glk: PASS -> FAIL [fdo#103232] +1
- shard-apl: PASS -> FAIL [fdo#103232] +1
* igt@kms_cursor_crc@cursor-256x256-sliding:
- {shard-iclb}: NOTRUN -> FAIL [fdo#103232]
* igt@kms_cursor_crc@cursor-256x256-suspend:
- shard-skl: PASS -> INCOMPLETE [fdo#104108]
* igt@kms_draw_crc@draw-method-xrgb-mmap-wc-ytiled:
- shard-skl: PASS -> FAIL [fdo#103184]
* igt@kms_flip@flip-vs-expired-vblank:
- shard-skl: PASS -> FAIL [fdo#105363]
* igt@kms_flip_tiling@flip-changes-tiling:
- shard-skl: NOTRUN -> FAIL [fdo#108303]
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-cpu:
- shard-apl: PASS -> FAIL [fdo#103167] +2
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-gtt:
- shard-glk: PASS -> FAIL [fdo#103167]
* igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-fullscreen:
- shard-skl: NOTRUN -> FAIL [fdo#103167]
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-blt:
- {shard-iclb}: PASS -> FAIL [fdo#103167] +2
* {igt@kms_plane@pixel-format-pipe-b-planes-source-clamping}:
- {shard-iclb}: NOTRUN -> FAIL [fdo#108948]
* igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max:
- shard-glk: PASS -> FAIL [fdo#108145]
* igt@kms_plane_alpha_blend@pipe-c-alpha-7efc:
- shard-skl: NOTRUN -> FAIL [fdo#107815] / [fdo#108145] +1
* igt@kms_plane_multiple@atomic-pipe-b-tiling-y:
- {shard-iclb}: PASS -> FAIL [fdo#103166]
* igt@kms_plane_multiple@atomic-pipe-c-tiling-x:
- shard-glk: PASS -> FAIL [fdo#103166]
- shard-apl: PASS -> FAIL [fdo#103166]
* igt@kms_rmfb@close-fd:
- {shard-iclb}: PASS -> DMESG-WARN [fdo#107724] +1
* igt@kms_setmode@basic:
- shard-apl: PASS -> FAIL [fdo#99912]
- {shard-iclb}: PASS -> FAIL [fdo#99912]
- shard-hsw: PASS -> FAIL [fdo#99912]
* igt@perf@polling:
- shard-hsw: PASS -> FAIL [fdo#102252]
* igt@pm_rpm@modeset-stress-extra-wait:
- shard-skl: PASS -> INCOMPLETE [fdo#107807] +1
Possible fixes
* igt@kms_cursor_crc@cursor-64x21-random:
- shard-apl: FAIL [fdo#103232] -> PASS +1
* igt@kms_cursor_crc@cursor-64x64-suspend:
- shard-glk: FAIL [fdo#103232] -> PASS +1
- shard-apl: FAIL [fdo#103191] / [fdo#103232] -> PASS
* igt@kms_draw_crc@draw-method-xrgb2101010-mmap-cpu-untiled:
- shard-skl: FAIL [fdo#103184] -> PASS
* igt@kms_draw_crc@draw-method-xrgb2101010-pwrite-untiled:
- {shard-iclb}: WARN [fdo#108336] -> PASS
* igt@kms_flip_tiling@flip-to-x-tiled:
- shard-skl: FAIL [fdo#108134] -> PASS
* igt@kms_flip_tiling@flip-y-tiled:
- shard-skl: FAIL [fdo#108303] -> PASS
* igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-mmap-cpu:
- {shard-iclb}: DMESG-FAIL [fdo#107724] -> PASS
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-mmap-cpu:
- shard-glk: FAIL [fdo#103167] -> PASS +2
* igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-onoff:
- {shard-iclb}: FAIL [fdo#103167] -> PASS +2
* igt@kms_frontbuffer_tracking@fbcpsr-rg
[Intel-gfx] [PATCH v3] /drm/i915/hdmi: SCDC Scrambling enable without CTS mode
From: Clint Taylor
Setting the SCDC scrambling CTS mode causes HDMI Link Layer protocol tests
HF1-12 and HF1-13 to fail.
V2: Removed "Source Shall" entries to a new patch
V3: Rebase to drm-tip
Cc: Ville Syrjälä
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107895
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107896
Signed-off-by: Clint Taylor
---
drivers/gpu/drm/i915/intel_ddi.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index f3e1d6a..92c0bf7 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1880,7 +1880,7 @@ void intel_ddi_enable_transcoder_func(const struct
intel_crtc_state *crtc_state)
temp |= TRANS_DDI_MODE_SELECT_DVI;
if (crtc_state->hdmi_scrambling)
- temp |= TRANS_DDI_HDMI_SCRAMBLING_MASK;
+ temp |= TRANS_DDI_HDMI_SCRAMBLING;
if (crtc_state->hdmi_high_tmds_clock_ratio)
temp |= TRANS_DDI_HIGH_TMDS_CHAR_RATE;
} else if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_ANALOG)) {
@@ -3793,8 +3793,7 @@ void intel_ddi_get_config(struct intel_encoder *encoder,
if (intel_dig_port->infoframe_enabled(encoder, pipe_config))
pipe_config->has_infoframe = true;
- if ((temp & TRANS_DDI_HDMI_SCRAMBLING_MASK) ==
- TRANS_DDI_HDMI_SCRAMBLING_MASK)
+ if (temp & TRANS_DDI_HDMI_SCRAMBLING)
pipe_config->hdmi_scrambling = true;
if (temp & TRANS_DDI_HIGH_TMDS_CHAR_RATE)
pipe_config->hdmi_high_tmds_clock_ratio = true;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Use intel_ types more consistently for color management code
On Mon, Dec 10, 2018 at 09:31:55PM +0200, Ville Syrjälä wrote:
> On Thu, Dec 06, 2018 at 04:54:01PM -0800, Matt Roper wrote:
> > Try to be more consistent about intel_* types rather than drm_* types
> > for lower-level driver functions. While we're at it, let's also be more
> > consistent with state variable naming (half of the platforms use the
> > name 'state' whereas the other half used 'crtc_state').
> >
> > Signed-off-by: Matt Roper
> > ---
> > drivers/gpu/drm/i915/i915_drv.h | 4 +-
> > drivers/gpu/drm/i915/intel_color.c | 207
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 20 ++--
> > drivers/gpu/drm/i915/intel_drv.h | 8 +-
> > 4 files changed, 112 insertions(+), 127 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 7469a7785253..48fb5e9bd08b 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -321,8 +321,8 @@ struct drm_i915_display_funcs {
> > /* display clock increase/decrease */
> > /* pll clock increase/decrease */
> >
> > - void (*load_csc_matrix)(struct drm_crtc_state *crtc_state);
> > - void (*load_luts)(struct drm_crtc_state *crtc_state);
> > + void (*load_csc_matrix)(struct intel_crtc_state *state);
> > + void (*load_luts)(struct intel_crtc_state *state);
> > };
> >
> > #define CSR_VERSION(major, minor) ((major) << 16 | (minor))
> > diff --git a/drivers/gpu/drm/i915/intel_color.c
> > b/drivers/gpu/drm/i915/intel_color.c
> > index 5127da286a2b..335c4702fcfb 100644
> > --- a/drivers/gpu/drm/i915/intel_color.c
> > +++ b/drivers/gpu/drm/i915/intel_color.c
> > @@ -74,12 +74,12 @@
> > #define ILK_CSC_COEFF_1_0 \
> > ((7 << 12) | ILK_CSC_COEFF_FP(CTM_COEFF_1_0, 8))
> >
> > -static bool crtc_state_is_legacy_gamma(struct drm_crtc_state *state)
> > +static bool crtc_state_is_legacy_gamma(struct intel_crtc_state *state)
>
> I'd lkike s/state/crtc_state/, at least in the cases where it doesn't
> make the diff too noisy.
>
> Or maybe even follow up with a wholesale sed/cocci job to just rename
> everything in the file?
>
> Patch is
> Reviewed-by: Ville Syrjälä
Applied the minor tweaks you suggested and BAT still looks clean.
Pushed to dinq; thanks for the review.
Matt
>
> > {
> > - return !state->degamma_lut &&
> > - !state->ctm &&
> > - state->gamma_lut &&
> > - drm_color_lut_size(state->gamma_lut) == LEGACY_LUT_LENGTH;
> > + return !state->base.degamma_lut &&
> > + !state->base.ctm &&
> > + state->base.gamma_lut &&
> > + drm_color_lut_size(state->base.gamma_lut) == LEGACY_LUT_LENGTH;
> > }
> >
> > /*
> > @@ -108,10 +108,10 @@ static u64 *ctm_mult_by_limited(u64 *result, const
> > u64 *input)
> > return result;
> > }
> >
> > -static void ilk_load_ycbcr_conversion_matrix(struct intel_crtc *intel_crtc)
> > +static void ilk_load_ycbcr_conversion_matrix(struct intel_crtc *crtc)
> > {
> > - int pipe = intel_crtc->pipe;
> > - struct drm_i915_private *dev_priv = to_i915(intel_crtc->base.dev);
> > + int pipe = crtc->pipe;
> > + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> >
> > I915_WRITE(PIPE_CSC_PREOFF_HI(pipe), 0);
> > I915_WRITE(PIPE_CSC_PREOFF_ME(pipe), 0);
> > @@ -132,14 +132,12 @@ static void ilk_load_ycbcr_conversion_matrix(struct
> > intel_crtc *intel_crtc)
> > I915_WRITE(PIPE_CSC_MODE(pipe), 0);
> > }
> >
> > -static void ilk_load_csc_matrix(struct drm_crtc_state *crtc_state)
> > +static void ilk_load_csc_matrix(struct intel_crtc_state *state)
> > {
> > - struct drm_crtc *crtc = crtc_state->crtc;
> > - struct drm_i915_private *dev_priv = to_i915(crtc->dev);
> > - struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> > - int i, pipe = intel_crtc->pipe;
> > + struct intel_crtc *crtc = to_intel_crtc(state->base.crtc);
> > + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > + int i, pipe = crtc->pipe;
> > uint16_t coeffs[9] = { 0, };
> > - struct intel_crtc_state *intel_crtc_state =
> > to_intel_crtc_state(crtc_state);
> > bool limited_color_range = false;
> >
> > /*
> > @@ -147,14 +145,14 @@ static void ilk_load_csc_matrix(struct drm_crtc_state
> > *crtc_state)
> > * do the range compression using the gamma LUT instead.
> > */
> > if (INTEL_GEN(dev_priv) >= 8 || IS_HASWELL(dev_priv))
> > - limited_color_range = intel_crtc_state->limited_color_range;
> > + limited_color_range = state->limited_color_range;
> >
> > - if (intel_crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420 ||
> > - intel_crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR444) {
> > - ilk_load_ycbcr_conversion_matrix(intel_crtc);
> > + if (state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420 ||
> > + state->output_format == INTEL_OUTPUT_FORMAT_YCBCR444) {
> > + ilk_load_y
[Intel-gfx] ✓ Fi.CI.BAT: success for /drm/i915/hdmi: SCDC Scrambling enable without CTS mode (rev3)
== Series Details ==
Series: /drm/i915/hdmi: SCDC Scrambling enable without CTS mode (rev3)
URL : https://patchwork.freedesktop.org/series/50648/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5293 -> Patchwork_11060
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/50648/revisions/3/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_11060:
### IGT changes ###
Warnings
* igt@kms_busy@basic-flip-a:
- {fi-kbl-7567u}: SKIP -> PASS +2
Known issues
Here are the changes found in Patchwork_11060 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_create@basic-files:
- fi-bsw-n3050: PASS -> FAIL [fdo#108656]
* igt@kms_chamelium@hdmi-hpd-fast:
- {fi-kbl-7500u}: PASS -> FAIL [fdo#108767]
* {igt@runner@aborted}:
- {fi-icl-y}: NOTRUN -> FAIL [fdo#108070]
Possible fixes
* igt@i915_selftest@live_coherency:
- fi-gdg-551: DMESG-FAIL [fdo#107164] -> PASS
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#107164]: https://bugs.freedesktop.org/show_bug.cgi?id=107164
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108070]: https://bugs.freedesktop.org/show_bug.cgi?id=108070
[fdo#108656]: https://bugs.freedesktop.org/show_bug.cgi?id=108656
[fdo#108767]: https://bugs.freedesktop.org/show_bug.cgi?id=108767
Participating hosts (49 -> 46)
--
Additional (2): fi-icl-y fi-pnv-d510
Missing(5): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600
Build changes
-
* Linux: CI_DRM_5293 -> Patchwork_11060
CI_DRM_5293: 06fd585c6c31f4c5f2de71b0901f3d10e44f6439 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4744: 4579ac1d445cf39f6de474071b20db790db575bd @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_11060: e69ce9969a64942a82215322c4e5f2b13ec4b59e @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
e69ce9969a64 /drm/i915/hdmi: SCDC Scrambling enable without CTS mode
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11060/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PULL] gvt-next for 4.21
On Fri, Dec 07, 2018 at 12:36:59PM +0800, Zhenyu Wang wrote: > > Hi, > > As I was hoping to possibly merge more new stuff for next kernel e.g > CFL support, etc, but seems those're still not stable enough so better > wait for next cycle, so sorry for the late. If I understood correctly Jani already sent the latest pull request targeting 4.21. Right Jani? Should we start queueing this for 4.22? > > This includes mostly one regression fix for drm-intel-next when we > introduced during previous shadow ctx ppgtt failure fix patch, and one > update on force-to-nonpriv register list. There're also three typo > fixes we received, I think they're trivial so should be no harm to > include. > > Thanks > -- > The following changes since commit 4377d4e0d3d511986033ba7b4182d5a80b7f9ea2: > > drm/i915: Update DRIVER_DATE to 20181204 (2018-12-04 19:26:17 +0200) > > are available in the Git repository at: > > https://github.com/intel/gvt-linux.git tags/gvt-next-2018-12-07 > > for you to fetch changes up to d1810909d841314ba94b14dc3de9e9fbc13b046a: > > drm/i915/gvt: fix spelling mistake "Interupts" -> "Interrupts" (2018-12-07 > 12:01:09 +0800) > > > gvt-next-2018-12-07 > > - Fix -next regression on shadow ctx's ppgtt destroy (Xiong) > - Update force-to-nonpriv register list (Yan) > - three typo fixes > > > Colin Ian King (1): > drm/i915/gvt: fix spelling mistake "Interupts" -> "Interrupts" > > Peng Hao (1): > drm/i915/gvt: fix a typo: "registeration" -> "registration". > > Xinyun Liu (1): > drm/i915/gvt: fix typo in two MI cmd annotation > > Xiong Zhang (1): > drm/i915/gvt: Fix shadow ctx ppgtt destroy function > > Zhao Yan (1): > drm/i915/gvt: update force-to-nonpriv register whitelist > > drivers/gpu/drm/i915/gvt/cmd_parser.c | 6 +++--- > drivers/gpu/drm/i915/gvt/gvt.c| 2 +- > drivers/gpu/drm/i915/gvt/gvt.h| 4 > drivers/gpu/drm/i915/gvt/handlers.c | 1 + > drivers/gpu/drm/i915/gvt/interrupt.c | 2 +- > drivers/gpu/drm/i915/gvt/scheduler.c | 33 + > 6 files changed, 43 insertions(+), 5 deletions(-) > > -- > Open Source Technology Center, Intel ltd. > > $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827 > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2,1/2] drm/i915: Use intel_ types more consistently for watermark code (v2)
== Series Details ==
Series: series starting with [v2,1/2] drm/i915: Use intel_ types more
consistently for watermark code (v2)
URL : https://patchwork.freedesktop.org/series/53859/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5293_full -> Patchwork_11059_full
Summary
---
**WARNING**
Minor unknown changes coming with Patchwork_11059_full need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_11059_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_11059_full:
### IGT changes ###
Warnings
* igt@kms_busy@extended-modeset-hang-oldfb-with-reset-render-c:
- shard-apl: PASS -> SKIP +9
* igt@pm_rc6_residency@rc6-accuracy:
- shard-kbl: SKIP -> PASS
Known issues
Here are the changes found in Patchwork_11059_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@kms_atomic_transition@plane-all-modeset-transition:
- shard-hsw: PASS -> DMESG-WARN [fdo#102614]
* igt@kms_available_modes_crc@available_mode_test_crc:
- shard-apl: PASS -> FAIL [fdo#106641]
* igt@kms_busy@extended-modeset-hang-newfb-render-b:
- shard-skl: NOTRUN -> DMESG-WARN [fdo#107956]
* igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-c:
- shard-apl: NOTRUN -> DMESG-WARN [fdo#107956] +1
* igt@kms_chv_cursor_fail@pipe-a-64x64-bottom-edge:
- shard-skl: PASS -> FAIL [fdo#104671]
* igt@kms_color@pipe-c-ctm-green-to-red:
- shard-skl: PASS -> FAIL [fdo#107201] +1
* igt@kms_color@pipe-c-legacy-gamma:
- shard-apl: PASS -> FAIL [fdo#104782]
* igt@kms_cursor_crc@cursor-128x128-offscreen:
- shard-skl: PASS -> FAIL [fdo#103232]
* igt@kms_cursor_crc@cursor-128x128-sliding:
- shard-apl: PASS -> FAIL [fdo#103232]
* igt@kms_cursor_crc@cursor-256x256-sliding:
- shard-glk: PASS -> INCOMPLETE [fdo#103359] / [k.org#198133] +1
* igt@kms_draw_crc@draw-method-xrgb2101010-blt-xtiled:
- shard-skl: PASS -> FAIL [fdo#103184]
* igt@kms_draw_crc@draw-method-xrgb-pwrite-untiled:
- {shard-iclb}: PASS -> WARN [fdo#108336]
* igt@kms_draw_crc@draw-method-xrgb-pwrite-ytiled:
- shard-skl: PASS -> FAIL [fdo#108222]
* igt@kms_flip@flip-vs-modeset-vs-hang-interruptible:
- shard-apl: PASS -> INCOMPLETE [fdo#103927] / [fdo#105602]
* igt@kms_flip_tiling@flip-changes-tiling:
- shard-skl: PASS -> FAIL [fdo#108303]
* igt@kms_flip_tiling@flip-to-y-tiled:
- {shard-iclb}: PASS -> DMESG-WARN [fdo#107724] / [fdo#108336] +1
* igt@kms_flip_tiling@flip-x-tiled:
- shard-skl: PASS -> FAIL [fdo#108145]
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-cpu:
- shard-apl: PASS -> FAIL [fdo#103167] +1
* igt@kms_frontbuffer_tracking@fbc-1p-shrfb-fliptrack:
- shard-skl: PASS -> FAIL [fdo#103167]
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-mmap-cpu:
- shard-glk: PASS -> FAIL [fdo#103167]
* igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-shrfb-plflip-blt:
- {shard-iclb}: PASS -> DMESG-FAIL [fdo#107724] +1
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-indfb-draw-mmap-cpu:
- shard-skl: PASS -> FAIL [fdo#108733]
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-blt:
- {shard-iclb}: PASS -> FAIL [fdo#103167] +4
* {igt@kms_plane@pixel-format-pipe-b-planes-source-clamping}:
- shard-skl: NOTRUN -> DMESG-WARN [fdo#106885]
* igt@kms_plane@plane-position-covered-pipe-a-planes:
- {shard-iclb}: PASS -> FAIL [fdo#103166] +1
* igt@kms_plane_alpha_blend@pipe-a-coverage-7efc:
- shard-skl: PASS -> FAIL [fdo#107815] / [fdo#108145]
* igt@kms_plane_alpha_blend@pipe-b-constant-alpha-max:
- shard-glk: PASS -> FAIL [fdo#108145]
* igt@kms_plane_alpha_blend@pipe-c-alpha-opaque-fb:
- shard-apl: NOTRUN -> FAIL [fdo#108145]
* igt@kms_plane_alpha_blend@pipe-c-constant-alpha-max:
- shard-skl: NOTRUN -> FAIL [fdo#108145]
* {igt@kms_rotation_crc@multiplane-rotation-cropping-top}:
- shard-apl: PASS -> DMESG-FAIL [fdo#103558] / [fdo#105602] /
[fdo#108950]
* igt@kms_rotation_crc@sprite-rotation-90-pos-100-0:
- shard-apl: PASS -> DMESG-WARN [fdo#103558] / [fdo#105602] +31
* igt@kms_setmode@basic:
- shard-apl: PASS -> FAIL [fdo#99912]
* igt@kms_vblank@pipe-a-ts-continuation-modeset-hang:
- {shard-iclb}: PASS -> DMESG-WARN [fdo#107724] +
[Intel-gfx] [PATCH v2 2/2] drm/i915: Switch to level-based DDB allocation algorithm (v3)
The DDB allocation algorithm currently used by the driver grants each
plane a very small minimum allocation of DDB blocks and then divies up
all of the remaining blocks based on the percentage of the total data
rate that the plane makes up. It turns out that this proportional
allocation approach is overly-generous with the larger planes and can
leave very small planes wthout a big enough allocation to even hit their
level 0 watermark requirements (especially on APL, which has a smaller
DDB in general than other gen9 platforms). Or there can be situations
where the smallest planes hit a lower watermark level than they should
have been able to hit with a more equitable division of DDB blocks, thus
limiting the overall system sleep state that can be achieved.
The bspec now describes an alternate algorithm that can be used to
overcome these types of issues. With the new algorithm, we calculate
all plane watermark values for all wm levels first, then go back and
partition a pipe's DDB space second. The DDB allocation will calculate
what the highest watermark level that can be achieved on *all* active
planes, and then grant the blocks necessary to hit that level to each
plane. Any remaining blocks are then divided up proportionally
according to data rate, similar to the old algorithm.
There was a previous attempt to implement this algorithm a couple years
ago in bb9d85f6e9d ("drm/i915/skl: New ddb allocation algorithm"), but
some regressions were reported, the patch was reverted, and nobody
ever got around to figuring out exactly where the bug was in that
version. Our watermark code has evolved significantly in the meantime,
but we're still getting bug reports caused by the unfair proportional
algorithm, so let's give this another shot.
v2:
- Make sure cursor allocation stays constant and fixed at the end of
the pipe allocation.
- Fix some watermark level iterators that weren't handling the max
level.
v3:
- Ensure we don't leave any DDB blocks unused by using DIV_ROUND_UP+min
to calculate the extra blocks for each plane. (Ville)
- Replace a while() loop with a for() loop to be more consistent with
surrounding code. (Ville)
- Clean unattainable watermark levels with memset rather than directly
clearing the member fields. Also do the same for the transition
watermark values if they can't be achieved. (Ville)
- Drop min_disp_buf_needed calculations in skl_compute_plane_wm() since
the results are no longer needed or used. (Ville)
- Drop skl_latency[0] != 0 sanity check; both watermark methods already
account for an invalid 0 latency by returning FP_16_16_MAX. (Ville)
Cc: Ville Syrjälä
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105458
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_pm.c | 376 ++--
1 file changed, 132 insertions(+), 244 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index bf970cf7b8a5..f5f86757457d 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4301,102 +4301,6 @@ icl_get_total_relative_data_rate(struct
intel_crtc_state *intel_cstate,
return total_data_rate;
}
-static uint16_t
-skl_ddb_min_alloc(const struct intel_plane_state *plane_state, const int plane)
-{
- struct drm_framebuffer *fb = plane_state->base.fb;
- uint32_t src_w, src_h;
- uint32_t min_scanlines = 8;
- uint8_t plane_bpp;
-
- if (WARN_ON(!fb))
- return 0;
-
- /* For packed formats, and uv-plane, return 0 */
- if (plane == 1 && fb->format->format != DRM_FORMAT_NV12)
- return 0;
-
- /* For Non Y-tile return 8-blocks */
- if (fb->modifier != I915_FORMAT_MOD_Y_TILED &&
- fb->modifier != I915_FORMAT_MOD_Yf_TILED &&
- fb->modifier != I915_FORMAT_MOD_Y_TILED_CCS &&
- fb->modifier != I915_FORMAT_MOD_Yf_TILED_CCS)
- return 8;
-
- /*
-* Src coordinates are already rotated by 270 degrees for
-* the 90/270 degree plane rotation cases (to match the
-* GTT mapping), hence no need to account for rotation here.
-*/
- src_w = drm_rect_width(&plane_state->base.src) >> 16;
- src_h = drm_rect_height(&plane_state->base.src) >> 16;
-
- /* Halve UV plane width and height for NV12 */
- if (plane == 1) {
- src_w /= 2;
- src_h /= 2;
- }
-
- plane_bpp = fb->format->cpp[plane];
-
- if (drm_rotation_90_or_270(plane_state->base.rotation)) {
- switch (plane_bpp) {
- case 1:
- min_scanlines = 32;
- break;
- case 2:
- min_scanlines = 16;
- break;
- case 4:
- min_scanlines = 8;
- break;
- case 8:
- min_scanlines = 4;
-
[Intel-gfx] [PATCH v2 1/2] drm/i915: Don't use DDB allocation when choosing gen9 watermark method
The bspec gives an if/else chain for choosing whether to use "method 1"
or "method 2" for calculating the watermark "Selected Result Blocks"
value for a plane. One of the branches of the if chain is:
"Else If ('plane buffer allocation' is known and (plane buffer
allocation / plane blocks per line) >=1)"
Since our driver currently calculates DDB allocations first and the
actual watermark values second, the plane buffer allocation is known at
this point in our code and we include this test in our driver's logic.
However we plan to soon move to a "watermarks first, ddb allocation
second" sequence where we won't know the DDB allocation at this point.
Let's drop this arm of the if/else statement (effectively considering
the DDB allocation unknown) as an independent patch so that any
regressions can be more accurately bisected to either the different
watermark value (in this patch) or the new DDB allocation (in the next
patch).
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_pm.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 2bba5315b764..bf970cf7b8a5 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4761,13 +4761,6 @@ static int skl_compute_plane_wm(const struct
intel_crtc_state *cstate,
wp->dbuf_block_size < 1) &&
(wp->plane_bytes_per_line / wp->dbuf_block_size < 1)) {
selected_result = method2;
- } else if (ddb_allocation >=
-fixed16_to_u32_round_up(wp->plane_blocks_per_line)) {
- if (IS_GEN9(dev_priv) &&
- !IS_GEMINILAKE(dev_priv))
- selected_result = min_fixed16(method1, method2);
- else
- selected_result = method2;
} else if (latency >= wp->linetime_us) {
if (IS_GEN9(dev_priv) &&
!IS_GEMINILAKE(dev_priv))
--
2.14.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v2,1/2] drm/i915: Don't use DDB allocation when choosing gen9 watermark method
== Series Details == Series: series starting with [v2,1/2] drm/i915: Don't use DDB allocation when choosing gen9 watermark method URL : https://patchwork.freedesktop.org/series/53862/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Don't use DDB allocation when choosing gen9 watermark method -drivers/gpu/drm/i915/i915_fixed.h:42:43: warning: expression using sizeof(void) -drivers/gpu/drm/i915/i915_fixed.h:42:43: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_pm.c:6724:35: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_pm.c:6724:35: warning: expression using sizeof(void) Commit: drm/i915: Switch to level-based DDB allocation algorithm (v3) +drivers/gpu/drm/i915/intel_pm.c:4407:25: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_pm.c:4407:25: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_pm.c:4417:25: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_pm.c:4417:25: warning: expression using sizeof(void) -drivers/gpu/drm/i915/intel_pm.c:6608:24: warning: expression using sizeof(void) -drivers/gpu/drm/i915/intel_pm.c:6608:24: warning: expression using sizeof(void) -drivers/gpu/drm/i915/intel_pm.c:6612:35: warning: expression using sizeof(void) -drivers/gpu/drm/i915/intel_pm.c:6612:35: warning: expression using sizeof(void) -drivers/gpu/drm/i915/intel_pm.c:6612:35: warning: too many warnings +drivers/gpu/drm/i915/intel_pm.c:6608:24: warning: too many warnings ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for /drm/i915/hdmi: SCDC Scrambling enable without CTS mode (rev3)
== Series Details ==
Series: /drm/i915/hdmi: SCDC Scrambling enable without CTS mode (rev3)
URL : https://patchwork.freedesktop.org/series/50648/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5293_full -> Patchwork_11060_full
Summary
---
**WARNING**
Minor unknown changes coming with Patchwork_11060_full need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_11060_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_11060_full:
### IGT changes ###
Warnings
* igt@pm_rc6_residency@rc6-accuracy:
- shard-kbl: SKIP -> PASS
- shard-snb: PASS -> SKIP
Known issues
Here are the changes found in Patchwork_11060_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_eio@in-flight-internal-1us:
- shard-glk: PASS -> FAIL [fdo#107799]
* igt@kms_available_modes_crc@available_mode_test_crc:
- shard-apl: PASS -> FAIL [fdo#106641]
* igt@kms_busy@extended-modeset-hang-newfb-render-b:
- shard-skl: NOTRUN -> DMESG-WARN [fdo#107956]
* igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-c:
- shard-apl: NOTRUN -> DMESG-WARN [fdo#107956] +1
* igt@kms_color@pipe-b-degamma:
- shard-apl: PASS -> FAIL [fdo#104782] +1
* igt@kms_color@pipe-c-ctm-green-to-red:
- shard-skl: PASS -> FAIL [fdo#107201] +1
* igt@kms_cursor_crc@cursor-128x128-sliding:
- shard-apl: PASS -> FAIL [fdo#103232]
* igt@kms_cursor_crc@cursor-128x42-random:
- shard-glk: PASS -> FAIL [fdo#103232] +1
* igt@kms_cursor_crc@cursor-64x64-suspend:
- shard-kbl: PASS -> DMESG-WARN [fdo#108566]
* igt@kms_draw_crc@draw-method-rgb565-mmap-gtt-untiled:
- shard-skl: PASS -> FAIL [fdo#103184] +1
* igt@kms_draw_crc@draw-method-xrgb2101010-mmap-gtt-xtiled:
- {shard-iclb}: PASS -> WARN [fdo#108336]
* igt@kms_flip@flip-vs-expired-vblank:
- shard-glk: PASS -> FAIL [fdo#105363]
* igt@kms_flip_tiling@flip-changes-tiling:
- shard-skl: PASS -> FAIL [fdo#108303]
* igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-render:
- shard-skl: PASS -> FAIL [fdo#105682] +2
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-fullscreen:
- shard-apl: PASS -> FAIL [fdo#103167]
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-move:
- {shard-iclb}: PASS -> FAIL [fdo#103167] +5
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-mmap-cpu:
- shard-glk: PASS -> FAIL [fdo#103167] +2
* igt@kms_frontbuffer_tracking@fbc-rgb101010-draw-mmap-gtt:
- {shard-iclb}: PASS -> DMESG-WARN [fdo#107724] / [fdo#108336] +6
* igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-mmap-wc:
- {shard-iclb}: PASS -> DMESG-FAIL [fdo#107724] +1
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-shrfb-plflip-blt:
- shard-skl: PASS -> FAIL [fdo#103167] +1
* {igt@kms_plane@pixel-format-pipe-b-planes-source-clamping}:
- shard-skl: NOTRUN -> DMESG-WARN [fdo#106885]
* igt@kms_plane@plane-position-covered-pipe-a-planes:
- shard-apl: PASS -> FAIL [fdo#103166] +1
- {shard-iclb}: PASS -> FAIL [fdo#103166] +1
* igt@kms_plane_alpha_blend@pipe-b-constant-alpha-max:
- shard-glk: PASS -> FAIL [fdo#108145]
* igt@kms_plane_alpha_blend@pipe-c-alpha-opaque-fb:
- shard-apl: NOTRUN -> FAIL [fdo#108145]
* igt@kms_plane_alpha_blend@pipe-c-constant-alpha-max:
- shard-skl: NOTRUN -> FAIL [fdo#108145]
* igt@kms_plane_multiple@atomic-pipe-b-tiling-y:
- shard-apl: NOTRUN -> FAIL [fdo#103166]
* igt@kms_psr@no_drrs:
- {shard-iclb}: PASS -> FAIL [fdo#108341]
* {igt@kms_rotation_crc@multiplane-rotation-cropping-top}:
- shard-glk: PASS -> DMESG-WARN [fdo#105763] / [fdo#106538]
* igt@kms_rotation_crc@primary-rotation-180:
- shard-skl: PASS -> FAIL [fdo#103925] / [fdo#107815]
* igt@kms_setmode@basic:
- shard-apl: PASS -> FAIL [fdo#99912]
* igt@kms_vblank@pipe-a-ts-continuation-dpms-suspend:
- {shard-iclb}: PASS -> INCOMPLETE [fdo#107713]
* igt@pm_backlight@basic-brightness:
- {shard-iclb}: PASS -> DMESG-WARN [fdo#107724] +12
* igt@pm_rpm@legacy-planes:
- {shard-iclb}: PASS -> DMESG-WARN [fdo#108654]
Possible fixes
* igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-c:
- shard-hsw: DMESG-WARN [fdo#107956] -> PASS
* igt@kms_color@pipe-a-degamma
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/2] drm/i915: Don't use DDB allocation when choosing gen9 watermark method
== Series Details == Series: series starting with [v2,1/2] drm/i915: Don't use DDB allocation when choosing gen9 watermark method URL : https://patchwork.freedesktop.org/series/53862/ State : success == Summary == CI Bug Log - changes from CI_DRM_5294 -> Patchwork_11061 Summary --- **SUCCESS** No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/53862/revisions/1/mbox/ Known issues Here are the changes found in Patchwork_11061 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live_hangcheck: - fi-bwr-2160:PASS -> DMESG-FAIL [fdo#108735] Possible fixes * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence: - fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191 [fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362 [fdo#108735]: https://bugs.freedesktop.org/show_bug.cgi?id=108735 Participating hosts (49 -> 44) -- Missing(5): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-ctg-p8600 Build changes - * Linux: CI_DRM_5294 -> Patchwork_11061 CI_DRM_5294: 791e2289df7e8ec34fb65251bb8ad30ceb28aba3 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4744: 4579ac1d445cf39f6de474071b20db790db575bd @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_11061: 847ef79c984b4068d82649abfaa6f99261af5a99 @ git://anongit.freedesktop.org/gfx-ci/linux == Kernel 32bit build == Warning: Kernel 32bit buildtest failed: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11061/build_32bit.log CALLscripts/checksyscalls.sh CHK include/generated/compile.h Kernel: arch/x86/boot/bzImage is ready (#1) Building modules, stage 2. MODPOST 109 modules ERROR: "__udivdi3" [drivers/gpu/drm/i915/i915.ko] undefined! scripts/Makefile.modpost:92: recipe for target '__modpost' failed make[1]: *** [__modpost] Error 1 Makefile:1269: recipe for target 'modules' failed make: *** [modules] Error 2 == Linux commits == 847ef79c984b drm/i915: Switch to level-based DDB allocation algorithm (v3) 419d5bd8b79d drm/i915: Don't use DDB allocation when choosing gen9 watermark method == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11061/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PULL] gvt-next for 4.21
On 2018.12.10 16:41:24 -0800, Rodrigo Vivi wrote: > > On Fri, Dec 07, 2018 at 12:36:59PM +0800, Zhenyu Wang wrote: > > > > Hi, > > > > As I was hoping to possibly merge more new stuff for next kernel e.g > > CFL support, etc, but seems those're still not stable enough so better > > wait for next cycle, so sorry for the late. > > If I understood correctly Jani already sent the latest pull request > targeting 4.21. Right Jani? > > Should we start queueing this for 4.22? > yeah, sorry I missed that window, but this one actually contains stuff for -next-fixes besides typo fixes, otherwise 4.21 will be problematic. Let me generate another one for dinf. thanks > > > > This includes mostly one regression fix for drm-intel-next when we > > introduced during previous shadow ctx ppgtt failure fix patch, and one > > update on force-to-nonpriv register list. There're also three typo > > fixes we received, I think they're trivial so should be no harm to > > include. > > > > Thanks > > -- > > The following changes since commit 4377d4e0d3d511986033ba7b4182d5a80b7f9ea2: > > > > drm/i915: Update DRIVER_DATE to 20181204 (2018-12-04 19:26:17 +0200) > > > > are available in the Git repository at: > > > > https://github.com/intel/gvt-linux.git tags/gvt-next-2018-12-07 > > > > for you to fetch changes up to d1810909d841314ba94b14dc3de9e9fbc13b046a: > > > > drm/i915/gvt: fix spelling mistake "Interupts" -> "Interrupts" > > (2018-12-07 12:01:09 +0800) > > > > > > gvt-next-2018-12-07 > > > > - Fix -next regression on shadow ctx's ppgtt destroy (Xiong) > > - Update force-to-nonpriv register list (Yan) > > - three typo fixes > > > > > > Colin Ian King (1): > > drm/i915/gvt: fix spelling mistake "Interupts" -> "Interrupts" > > > > Peng Hao (1): > > drm/i915/gvt: fix a typo: "registeration" -> "registration". > > > > Xinyun Liu (1): > > drm/i915/gvt: fix typo in two MI cmd annotation > > > > Xiong Zhang (1): > > drm/i915/gvt: Fix shadow ctx ppgtt destroy function > > > > Zhao Yan (1): > > drm/i915/gvt: update force-to-nonpriv register whitelist > > > > drivers/gpu/drm/i915/gvt/cmd_parser.c | 6 +++--- > > drivers/gpu/drm/i915/gvt/gvt.c| 2 +- > > drivers/gpu/drm/i915/gvt/gvt.h| 4 > > drivers/gpu/drm/i915/gvt/handlers.c | 1 + > > drivers/gpu/drm/i915/gvt/interrupt.c | 2 +- > > drivers/gpu/drm/i915/gvt/scheduler.c | 33 > > + > > 6 files changed, 43 insertions(+), 5 deletions(-) > > > > -- > > Open Source Technology Center, Intel ltd. > > > > $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827 > > > > > ___ > > Intel-gfx mailing list > > Intel-gfx@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > -- Open Source Technology Center, Intel ltd. $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827 signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/5] drm/dp: Implement I2C_M_STOP for i2c-over-aux
On Fri, 2018-09-28 at 21:04 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Consult the I2C_M_STOP flag to determine whether to set the MOT bit
> or
> not. Makes it possible to send multiple messages in one go with
> stop+start generated between the messages (as opposed nothing or
> repstart depending on whether thr address/rw changed).
>
> Not sure anyone has actual use for this but figured I'd handle it
> since I started to look at that flag for MST remote i2c xfers.
>
Don't see the I2C_M_STOP flag anywhere in drm_edid.c, but the change
introduced here does make sense.
Reviewed-by: Dhinakaran Pandiyan
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_dp_helper.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c
> b/drivers/gpu/drm/drm_dp_helper.c
> index 37c01b6076ec..e85cea299d2a 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -884,7 +884,8 @@ static void drm_dp_i2c_msg_set_request(struct
> drm_dp_aux_msg *msg,
> {
> msg->request = (i2c_msg->flags & I2C_M_RD) ?
> DP_AUX_I2C_READ : DP_AUX_I2C_WRITE;
> - msg->request |= DP_AUX_I2C_MOT;
> + if (!(i2c_msg->flags & I2C_M_STOP))
> + msg->request |= DP_AUX_I2C_MOT;
> }
>
> /*
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v2,1/2] drm/i915: Don't use DDB allocation when choosing gen9 watermark method
== Series Details ==
Series: series starting with [v2,1/2] drm/i915: Don't use DDB allocation when
choosing gen9 watermark method
URL : https://patchwork.freedesktop.org/series/53862/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5294_full -> Patchwork_11061_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_11061_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_11061_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_11061_full:
### IGT changes ###
Possible regressions
* igt@kms_plane@plane-position-hole-pipe-c-planes:
- shard-apl: PASS -> DMESG-WARN
* igt@kms_plane_alpha_blend@pipe-c-alpha-transparant-fb:
- {shard-iclb}: PASS -> FAIL +4
* {igt@runner@aborted}:
- shard-glk: NOTRUN -> ( 15 FAIL )
- shard-skl: NOTRUN -> ( 22 FAIL )
- {shard-iclb}: NOTRUN -> ( 6 FAIL )
- shard-apl: NOTRUN -> ( 18 FAIL )
Warnings
* igt@kms_plane_lowres@pipe-b-tiling-y:
- {shard-iclb}: PASS -> SKIP
* igt@pm_rc6_residency@rc6-accuracy:
- shard-snb: SKIP -> PASS
Known issues
Here are the changes found in Patchwork_11061_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_eio@in-flight-internal-1us:
- shard-glk: PASS -> FAIL [fdo#107799]
* igt@i915_selftest@live_contexts:
- {shard-iclb}: NOTRUN -> DMESG-FAIL [fdo#108569]
* igt@kms_available_modes_crc@available_mode_test_crc:
- shard-apl: PASS -> FAIL [fdo#106641]
* igt@kms_chv_cursor_fail@pipe-a-64x64-bottom-edge:
- shard-skl: PASS -> FAIL [fdo#104671]
* igt@kms_cursor_crc@cursor-128x128-offscreen:
- shard-skl: PASS -> FAIL [fdo#103232]
* igt@kms_cursor_crc@cursor-128x128-suspend:
- shard-skl: PASS -> INCOMPLETE [fdo#104108]
* igt@kms_draw_crc@draw-method-xrgb-mmap-wc-ytiled:
- shard-skl: PASS -> FAIL [fdo#103184]
* igt@kms_flip@flip-vs-expired-vblank:
- shard-skl: PASS -> FAIL [fdo#105363]
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-fullscreen:
- shard-apl: PASS -> DMESG-FAIL [fdo#103167] +4
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-move:
- {shard-iclb}: PASS -> FAIL [fdo#103167] +7
- shard-skl: NOTRUN -> DMESG-FAIL [fdo#103167] / [fdo#105541]
* igt@kms_frontbuffer_tracking@fbc-1p-rte:
- {shard-iclb}: PASS -> DMESG-FAIL [fdo#103167] / [fdo#107724] +3
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-blt:
- shard-glk: PASS -> DMESG-FAIL [fdo#105681] / [fdo#105763] /
[fdo#106538]
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-mmap-cpu:
- shard-glk: PASS -> DMESG-FAIL [fdo#103167] / [fdo#105763] /
[fdo#106538] +10
* igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-draw-pwrite:
- shard-skl: PASS -> DMESG-FAIL [fdo#103167] / [fdo#105541] +14
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-indfb-draw-mmap-cpu:
- shard-skl: PASS -> FAIL [fdo#103167] +1
* igt@kms_plane@pixel-format-pipe-b-planes:
- shard-skl: NOTRUN -> DMESG-WARN [fdo#106885]
* {igt@kms_plane@pixel-format-pipe-c-planes-source-clamping}:
- shard-glk: PASS -> FAIL [fdo#108948]
* igt@kms_plane@plane-position-hole-dpms-pipe-a-planes:
- shard-skl: NOTRUN -> DMESG-WARN [fdo#105541]
* igt@kms_plane@plane-position-hole-pipe-a-planes:
- shard-apl: PASS -> DMESG-FAIL [fdo#103166] +3
* igt@kms_plane@plane-position-hole-pipe-c-planes:
- shard-skl: PASS -> DMESG-FAIL [fdo#103166] / [fdo#105541] +1
* igt@kms_plane_alpha_blend@pipe-a-coverage-7efc:
- shard-skl: PASS -> FAIL [fdo#107815] / [fdo#108145]
* igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
- shard-skl: NOTRUN -> FAIL [fdo#107815]
* igt@kms_plane_multiple@atomic-pipe-b-tiling-y:
- shard-glk: PASS -> FAIL [fdo#103166] +1
* igt@kms_plane_multiple@atomic-pipe-b-tiling-yf:
- shard-apl: PASS -> FAIL [fdo#103166]
* igt@kms_plane_multiple@atomic-pipe-c-tiling-x:
- {shard-iclb}: PASS -> FAIL [fdo#103166]
* igt@kms_plane_multiple@atomic-pipe-c-tiling-y:
- shard-skl: NOTRUN -> FAIL [fdo#103166] / [fdo#107815]
* {igt@kms_rotation_crc@multiplane-rotation-cropping-top}:
- shard-kbl: PASS -> DMESG-FAIL [fdo#108950]
* igt@kms_setmode@basic:
- shard-apl: PASS -> FAIL [fdo#99912]
- shard-
Re: [Intel-gfx] [PATCH 1/5] drm/i915/psr: Allow PSR2 to be enabled when debugfs asks
On Tue, 2018-12-04 at 15:00 -0800, José Roberto de Souza wrote:
> For now PSR2 is still disabled by default for all platforms but is
> our intention to let debugfs to enable it for debug and tests
> proporses, so intel_psr2_enabled() that is also used by debugfs to
> decide if PSR2 is going to be enabled needs to take in consideration
> the debug field.
>
> Cc: Dhinakaran Pandiyan
> Cc: Rodrigo Vivi
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/intel_psr.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index 4c4dd1c310ce..15a2121aa64f 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -71,8 +71,11 @@ static bool psr_global_enabled(u32 debug)
> static bool intel_psr2_enabled(struct drm_i915_private *dev_priv,
> const struct intel_crtc_state
> *crtc_state)
> {
> + const u32 debug_mode = dev_priv->psr.debug &
> I915_PSR_DEBUG_MODE_MASK;
> +
> /* Disable PSR2 by default for all platforms */
> - if (i915_modparams.enable_psr == -1)
> + if (i915_modparams.enable_psr == -1 &&
> + debug_mode != I915_PSR_DEBUG_ENABLE)
> return false;
@@ -71,17 +71,17 @@ static bool psr_global_enabled(u32 debug)
static bool intel_psr2_enabled(struct drm_i915_private *dev_priv,
const struct intel_crtc_state
*crtc_state)
{
- /* Disable PSR2 by default for all platforms */
- if (i915_modparams.enable_psr == -1)
- return false;
-
/* Cannot enable DSC and PSR2 simultaneously */
WARN_ON(crtc_state->dsc_params.compression_enable &&
crtc_state->has_psr2);
switch (dev_priv->psr.debug & I915_PSR_DEBUG_MODE_MASK) {
+ case I915_PSR_DEBUG_DISABLE:
case I915_PSR_DEBUG_FORCE_PSR1:
return false;
+ case I915_PSR_DEBUG_DEFAULT:
+ if (i915_modparams.enable_psr <= 0)
+ return false;
default:
return crtc_state->has_psr2;
}
Does this read any better? Keeping the condition checks together and
also having a consistent priority between debugfs and module parameter
options is easier to follow IMHO.
>
> /* Cannot enable DSC and PSR2 simultaneously */
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/5] drm/i915: Refactor PSR status debugfs
On Tue, 2018-12-04 at 15:00 -0800, José Roberto de Souza wrote:
> The old debugfs fields was not following a naming partern and it was
> a bit confusing.
>
> So it went from:
> ~$ sudo more /sys/kernel/debug/dri/0/i915_edp_psr_status
> Sink_Support: yes
> PSR mode: PSR1
> Enabled: yes
> Busy frontbuffer bits: 0x000
> Main link in standby mode: no
> HW Enabled & Active bit: yes
> Source PSR status: 0x24050006 [SRDONACK]
>
> To:
> ~$ sudo more /sys/kernel/debug/dri/0/i915_edp_psr_status
> Sink support: yes [0x0003]
> Status: PSR1 enabled
> Source PSR ctl: enabled [0x81f00e26]
> Source PSR status: SRDENT [0x40040006]
> Busy frontbuffer bits: 0x
>
> The 'Main link in standby mode' was removed as it is not useful but
> if needed by someone the information is still in the register value
> of 'Source PSR ctl' inside of the brackets, PSR mode and Enabled was
> squashed into Status, some renames and reorders and we have this
> cleaner version. This will also make easy to parse debugfs for IGT
> tests.
>
> Cc: Rodrigo Vivi
> Cc: Dhinakaran Pandiyan
> Suggested-by: Dhinakaran Pandiyan
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 96 +++--
>
> 1 file changed, 49 insertions(+), 47 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 38dcee1ca062..86303ba02666 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2665,7 +2665,8 @@ DEFINE_SHOW_ATTRIBUTE(i915_psr_sink_status);
> static void
> psr_source_status(struct drm_i915_private *dev_priv, struct seq_file
> *m)
> {
> - u32 val, psr_status;
> + u32 val, status_val;
> + const char *status = "unknown";
>
> if (dev_priv->psr.psr2_enabled) {
> static const char * const live_status[] = {
> @@ -2681,14 +2682,11 @@ psr_source_status(struct drm_i915_private
> *dev_priv, struct seq_file *m)
> "BUF_ON",
> "TG_ON"
> };
> - psr_status = I915_READ(EDP_PSR2_STATUS);
> - val = (psr_status & EDP_PSR2_STATUS_STATE_MASK) >>
> - EDP_PSR2_STATUS_STATE_SHIFT;
> - if (val < ARRAY_SIZE(live_status)) {
> - seq_printf(m, "Source PSR status: 0x%x [%s]\n",
> -psr_status, live_status[val]);
> - return;
> - }
> + val = I915_READ(EDP_PSR2_STATUS);
> + status_val = (val & EDP_PSR2_STATUS_STATE_MASK) >>
> + EDP_PSR2_STATUS_STATE_SHIFT;
> + if (status_val < ARRAY_SIZE(live_status))
> + status = live_status[status_val];
> } else {
> static const char * const live_status[] = {
> "IDLE",
> @@ -2700,74 +2698,78 @@ psr_source_status(struct drm_i915_private
> *dev_priv, struct seq_file *m)
> "SRDOFFACK",
> "SRDENT_ON",
> };
> - psr_status = I915_READ(EDP_PSR_STATUS);
> - val = (psr_status & EDP_PSR_STATUS_STATE_MASK) >>
> - EDP_PSR_STATUS_STATE_SHIFT;
> - if (val < ARRAY_SIZE(live_status)) {
> - seq_printf(m, "Source PSR status: 0x%x [%s]\n",
> -psr_status, live_status[val]);
> - return;
> - }
> + val = I915_READ(EDP_PSR_STATUS);
> + status_val = (val & EDP_PSR_STATUS_STATE_MASK) >>
> + EDP_PSR_STATUS_STATE_SHIFT;
> + if (status_val < ARRAY_SIZE(live_status))
> + status = live_status[status_val];
> }
>
> - seq_printf(m, "Source PSR status: 0x%x [%s]\n", psr_status,
> "unknown");
> + seq_printf(m, "Source PSR status: %s [0x%08x]\n", status, val);
> }
>
> static int i915_edp_psr_status(struct seq_file *m, void *data)
> {
> struct drm_i915_private *dev_priv = node_to_i915(m->private);
> - u32 psrperf = 0;
> - bool enabled = false;
> - bool sink_support;
> + struct i915_psr *psr = &dev_priv->psr;
> + const char *status;
> + bool enabled;
> + u32 val;
>
> if (!HAS_PSR(dev_priv))
> return -ENODEV;
>
> - sink_support = dev_priv->psr.sink_support;
> - seq_printf(m, "Sink_Support: %s\n", yesno(sink_support));
> - if (!sink_support)
> + seq_printf(m, "Sink support: %s", yesno(psr->sink_support));
> + if (!psr->sink_support) {
> + seq_puts(m, "\n");
> return 0;
> + }
>
> intel_runtime_pm_get(dev_priv);
> + mutex_lock(&psr->lock);
>
> - mutex_lock(&dev_priv->psr.lock);
> - seq_printf(m, "PSR mode: %s\n",
> -dev_priv->psr.psr2_enabled ? "PSR2" : "PSR1");
> - seq_printf(m, "Enabled: %s\n", yesno(dev_priv->psr.enabled));
> - seq_pr
Re: [Intel-gfx] [PATCH 3/5] drm/i915/psr: Do not print last attempted entry or exit in PSR debugfs while in PSR2
On Tue, 2018-12-04 at 15:00 -0800, José Roberto de Souza wrote:
> PSR2 only trigger interruptions for AUX error, so let's not print
> useless information in debugsfs.
> Also adding a comment to intel_psr_irq_handler() about that.
The code still allows the enabling of interrupt debugging for PSR2. Fix
that to reject debugfs writes?
>
> Cc: Rodrigo Vivi
> Cc: Dhinakaran Pandiyan
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
> drivers/gpu/drm/i915/intel_psr.c| 1 +
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 86303ba02666..505d93b31eb6 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2760,7 +2760,7 @@ static int i915_edp_psr_status(struct seq_file
> *m, void *data)
> seq_printf(m, "Performance counter: %u\n", val);
> }
>
> - if (psr->debug & I915_PSR_DEBUG_IRQ) {
> + if ((psr->debug & I915_PSR_DEBUG_IRQ) && !psr->psr2_enabled) {
> seq_printf(m, "Last attempted entry at: %lld\n",
> psr->last_entry_attempt);
> seq_printf(m, "Last exit at: %lld\n", psr->last_exit);
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index 15a2121aa64f..85349a57689c 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -203,6 +203,7 @@ void intel_psr_irq_handler(struct
> drm_i915_private *dev_priv, u32 psr_iir)
> mask |= EDP_PSR_ERROR(shift);
> }
>
> + /* PSR2 don't trigger PRE_ENTRY and POST_EXIT
> interruptions */
> if (psr_iir & EDP_PSR_PRE_ENTRY(shift)) {
> dev_priv->psr.last_entry_attempt = time_ns;
> DRM_DEBUG_KMS("[transcoder %s] PSR entry
> attempt in 2 vblanks\n",
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/5] drm/i915: Add PSR2 selective update status registers and bits definitions
On Tue, 2018-12-04 at 15:00 -0800, José Roberto de Souza wrote:
> This register contains how many blocks was sent in the past selective
> updates.
> Those registers are not kept set all the times but pulling it after
> flip
> can show that the expected values are set for the current frame and
> the
> previous ones too.
>
> Cc: Rodrigo Vivi
> Cc: Dhinakaran Pandiyan
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/i915_reg.h | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h
> index 0a7d60509ca7..7d634f34ca7d 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -4248,6 +4248,12 @@ enum {
> #define EDP_PSR2_STATUS_STATE_MASK (0xf << 28)
> #define EDP_PSR2_STATUS_STATE_SHIFT28
>
> +#define EDP_PSR2_SU_STATUS _MMIO(0
> x6f914)
> +#define EDP_PSR2_SU_STATUS2 _MMIO(0
> x6F918)
> +#define EDP_PSR2_SU_STATUS3 _MMIO(0
> x6F91C)
> +#define EDP_PSR2_SU_STATUS_NUM_SU_BLOCKS_IN_FRAME_SHIFT(i) ((i) *
> 10)
> +#define EDP_PSR2_SU_STATUS_NUM_SU_BLOCKS_IN_FRAME_MASK(i) (0x3FF
> << ((i) * 10))
How about moving the MMIO selection logic to the macros?
#define PSR2_SU_HISTORY 8
#define _PSR2_SU_STATUS_0 0x6f914
#define _PSR2_SU_STATUS_1 0x6f918
#define _PSR2_SU_STATUS(dword) _MMIO(_PICK_EVEN((dword),\
_PSR2_SU_STATUS_0, _PSR2_SU_STATUS_1))
#define PSR2_SU_SHIFT(frame) ((frame) % 3) * 10
#define PSR2_SU_MASK(frame) (0x3ff << PSR2_SU_SHIFT(frame))
#define PSR2_SU_BLOCKS(frame) _PSR2_SU_STATUS((frame) / 3)
> +
> /* VGA port control */
> #define ADPA _MMIO(0x61100)
> #define PCH_ADPA_MMIO(0xe1100)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
