{"push_id":1107594978,"size":23,"distinct_size":23,"ref":"refs/heads/topic/wm_workarounds","head":"6a62867ae5cb58cf41242aa1452ee501969e10e9","before":"e549fcd84980d46607a0d1097f4a50d943cc210c","commits":[{"sha":"f087dc6e52623a5e7a2ffb937b402057cd0ec4a8","author":{"email":"f1605a76cb9f6387d99228a0a9260318379b62de@intel.com","name":"Matt Roper"},"message":"drm/i915: Reorganize WM structs/unions in CRTC state\n\nReorganize the nested structures and unions we have for pipe watermark\ndata in intel_crtc_state so that platform-specific data can be added in\na more sensible manner (and save a bit of memory at the same time).\n\nThe change basically changes the organization from:\n\n        union {\n                struct intel_pipe_wm ilk;\n                struct intel_pipe_wm skl;\n        } optimal;\n\n        struct intel_pipe_wm intermediate /* ILK-only */\n\nto\n\n        union {\n                struct {\n                        struct intel_pipe_wm intermediate;\n                        struct intel_pipe_wm optimal;\n                } ilk;\n\n                struct {\n                        struct intel_pipe_wm optimal;\n                } skl;\n        }\n\nThere should be no functional change here, but it will allow us to add\nmore platform-specific fields going forward (and more easily extend to\nother platform types like VLV).\n\nWhile we're at it, let's move the entire watermark substructure out to\nits own structure definition to make the code slightly more readable.\n\nSigned-off-by: Matt Roper <matthew.d.roper@intel.com>\nReviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>","distinct":true,"url":"https://api.github.com/repos/mattrope/kernel/commits/f087dc6e52623a5e7a2ffb937b402057cd0ec4a8"},{"sha":"0147e3533c1375f823d4535993dabdc176251233","author":{"email":"f1605a76cb9f6387d99228a0a9260318379b62de@intel.com","name":"Matt Roper"},"message":"drm/i915: Rename s/skl_compute_pipe_wm/skl_build_pipe_wm/\n\nWhen we added atomic watermarks, we added a new display vfunc\n'compute_pipe_wm' that is used to compute any pipe-specific watermark\ninformation that we can at atomic check time.  This was a somewhat poor\nnaming choice since we already had a 'skl_compute_pipe_wm' function that\ndoesn't quite fit this model --- the existing SKL function is something\nthat gets used at atomic commit time, after the DDB allocation has been\ndetermined.  Let's rename the existing SKL function to avoid confusion.\n\nSigned-off-by: Matt Roper <matthew.d.roper@intel.com>\nReviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>","distinct":true,"url":"https://api.github.com/repos/mattrope/kernel/commits/0147e3533c1375f823d4535993dabdc176251233"},{"sha":"683ba41586bcc4611bf889c72d14388380edba76","author":{"email":"f1605a76cb9f6387d99228a0a9260318379b62de@intel.com","name":"Matt Roper"},"message":"drm/i915/gen9: Cache plane data rates in CRTC state\n\nThis will be important when we start calculating CRTC data rates for\nin-flight CRTC states since it will allow us to calculate the total data\nrate without needing to grab the plane state for any planes that aren't\nupdated by the transaction.\n\nSigned-off-by: Matt Roper <matthew.d.roper@intel.com>\nReviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>","distinct":true,"url":"https://api.github.com/repos/mattrope/kernel/commits/683ba41586bcc4611bf889c72d14388380edba76"},{"sha":"373448e6e8e69dd96e64e11882933c8a1c43557f","author":{"email":"f1605a76cb9f6387d99228a0a9260318379b62de@intel.com","name":"Matt Roper"},"message":"drm/i915/gen9: Allow calculation of data rate for in-flight state (v2)\n\nOur skl_get_total_relative_data_rate() function gets passed a crtc state\nobject to calculate the data rate for, but it currently always looks\nup the committed plane states that correspond to that CRTC.  Let's\ncheck whether the CRTC state is an in-flight state (meaning\ncstate->state is non-NULL) and if so, use the corresponding in-flight\nplane states.\n\nWe'll soon be using this function exclusively for in-flight states; at\nthat time we'll be able to simplify the function a bit, but for now we\nallow it to be used in either mode.\n\nv2:\n - Rebase on top of changes to cache plane data rates.\n\nSigned-off-by: Matt Roper <matthew.d.roper@intel.com>\nReviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>","distinct":true,"url":"https://api.github.com/repos/mattrope/kernel/commits/373448e6e8e69dd96e64e11882933c8a1c43557f"},{"sha":"c5b0606459801dd5634b1d9183bf68a6f3c9b929","author":{"email":"f1605a76cb9f6387d99228a0a9260318379b62de@intel.com","name":"Matt Roper"},"message":"drm/i915/gen9: Store plane minimum blocks in CRTC wm state (v2)\n\nThis will eventually allow us to re-use old values without\nre-calculating them for unchanged planes (which also helps us avoid\nre-grabbing extra plane states).\n\nv2:\n -  Drop unnecessary memset's; they were meant for a later patch (which\n    got reworked anyway to not need them, but were mis-rebased into this\n    one.  (Maarten)\n\nCc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>\nSigned-off-by: Matt Roper <matthew.d.roper@intel.com>\nReviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>","distinct":true,"url":"https://api.github.com/repos/mattrope/kernel/commits/c5b0606459801dd5634b1d9183bf68a6f3c9b929"},{"sha":"2dd3772d35cb80b56e1a1373b5fb6c05574fcadc","author":{"email":"f1605a76cb9f6387d99228a0a9260318379b62de@intel.com","name":"Matt Roper"},"message":"drm/i915: Track whether an atomic transaction changes the active CRTC's\n\nFor the purposes of DDB re-allocation we need to know whether a\ntransaction changes the list of CRTC's that are active.  While\nstate->modeset could be used for this purpose, that would be slightly\ntoo aggressive since it would lead us to re-allocate the DDB when a\nCRTC's mode changes, but not its final active state.\n\nSigned-off-by: Matt Roper <matthew.d.roper@intel.com>\nReviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>","distinct":true,"url":"https://api.github.com/repos/mattrope/kernel/commits/2dd3772d35cb80b56e1a1373b5fb6c05574fcadc"},{"sha":"5b14079cdee454022878b8565889a8b40d37b065","author":{"email":"f1605a76cb9f6387d99228a0a9260318379b62de@intel.com","name":"Matt Roper"},"message":"drm/i915/gen9: Allow skl_allocate_pipe_ddb() to operate on in-flight state (v3)\n\nWe eventually want to calculate watermark values at atomic 'check' time\ninstead of atomic 'commit' time so that any requested configurations\nthat result in impossible watermark requirements are properly rejected.\nThe first step along this path is to allocate the DDB at atomic 'check'\ntime.  As we perform this transition, allow the main allocation function\nto operate successfully on either an in-flight state or an\nalready-commited state.  Once we complete the transition in a future\npatch, we'll come back and remove the unnecessary logic for the\nalready-committed case.\n\nv2: Rebase/refactor; we should no longer need to grab extra plane states\n    while allocating the DDB since we can pull cached data rates and\n    minimum block counts from the CRTC state for any planes that aren't\n    being modified by this transaction.\n\nv3:\n - Simplify memsets to clear DDB plane entries.  (Maarten)\n - Drop a redundant memset of plane[pipe][PLANE_CURSOR] that was added\n   by an earlier Coccinelle patch.  (Maarten)\n - Assign *num_active at the top of skl_ddb_get_pipe_allocation_limits()\n   so that no code paths return without setting it.  (kbuild robot)\n\nCc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>\nSigned-off-by: Matt Roper <matthew.d.roper@intel.com>\nReviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>","distinct":true,"url":"https://api.github.com/repos/mattrope/kernel/commits/5b14079cdee454022878b8565889a8b40d37b065"},{"sha":"e3cfdd2f9cdd59f0412e5aced4a0c29a93c9af7c","author":{"email":"f1605a76cb9f6387d99228a0a9260318379b62de@intel.com","name":"Matt Roper"},"message":"drm/i915: Add distrust_bios_wm flag to dev_priv (v2)\n\nSKL-style platforms can't fully trust the watermark/DDB settings\nprogrammed by the BIOS and need to do extra sanitization on their first\natomic update.  Add a flag to dev_priv that is set during hardware\nreadout and cleared at the end of the first commit.\n\nNote that for the somewhat common case where everything is turned off\nwhen the driver starts up, we don't need to bother with a recompute...we\nknow exactly what the DDB should be (all zero's) so just setup the DDB\ndirectly in that case.\n\nv2:\n - Move clearing of distrust_bios_wm up below the swap_state call since\n   it's a more natural / self-explanatory location.  (Maarten)\n - Use dev_priv->active_crtcs to test whether any CRTC's are turned on\n   during HW WM readout rather than trying to count the active CRTC's\n   again ourselves.  (Maarten)\n\nCc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>\nSigned-off-by: Matt Roper <matthew.d.roper@intel.com>","distinct":true,"url":"https://api.github.com/repos/mattrope/kernel/commits/e3cfdd2f9cdd59f0412e5aced4a0c29a93c9af7c"},{"sha":"7ea1706fd58d87419cea52b8b46e87d36b072646","author":{"email":"f1605a76cb9f6387d99228a0a9260318379b62de@intel.com","name":"Matt Roper"},"message":"drm/i915/gen9: Compute DDB allocation at atomic check time (v4)\n\nCalculate the DDB blocks needed to satisfy the current atomic\ntransaction at atomic check time.  This is a prerequisite to calculating\nSKL watermarks during the 'check' phase and rejecting any configurations\nthat we can't find valid watermarks for.\n\nDue to the nature of DDB allocation, it's possible for the addition of a\nnew CRTC to make the watermark configuration already in use on another,\nunchanged CRTC become invalid.  A change in which CRTC's are active\ntriggers a recompute of the entire DDB, which unfortunately means we\nneed to disallow any other atomic commits from racing with such an\nupdate.  If the active CRTC's change, we need to grab the lock on all\nCRTC's and run all CRTC's through their 'check' handler to recompute and\nre-check their per-CRTC DDB allocations.\n\nNote that with this patch we only compute the DDB allocation but we\ndon't actually use the computed values during watermark programming yet.\nFor ease of review/testing/bisecting, we still recompute the DDB at\nwatermark programming time and just WARN() if it doesn't match the\nprecomputed values.  A future patch will switch over to using the\nprecomputed values once we're sure they're being properly computed.\n\nAnother clarifying note:  DDB allocation itself shouldn't ever fail with\nthe algorithm we use today (i.e., we have enough DDB blocks on BXT to\nsupport the minimum needs of the worst-case scenario of every pipe/plane\nenabled at full size).  However the watermarks calculations based on the\nDDB may fail and we'll be moving those to the atomic check as well in\nfuture patches.\n\nv2:\n - Skip DDB calculations in the rare case where our transaction doesn't\n   actually touch any CRTC's at all.  Assuming at least one CRTC state\n   is present in our transaction, then it means we can't race with any\n   transactions that would update dev_priv->active_crtcs (which requires\n   _all_ CRTC locks).\n\nv3:\n - Also calculate DDB during initial hw readout, to prevent using\n   incorrect bios values. (Maarten)\n\nv4:\n - Use new distrust_bios_wm flag instead of skip_initial_wm (which was\n   never actually set).\n - Set intel_state->active_pipe_changes instead of just realloc_pipes\n\nCc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>\nCc: Lyude Paul <cpaul@redhat.com>\nCc: Radhakrishna Sripada <radhakrishna.sripada@intel.com>\nSigned-off-by: Matt Roper <matthew.d.roper@intel.com>\nSigned-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>","distinct":true,"url":"https://api.github.com/repos/mattrope/kernel/commits/7ea1706fd58d87419cea52b8b46e87d36b072646"},{"sha":"6ee1b7a55c0cdb8563e53840f48fb19425cad1b6","author":{"email":"f1605a76cb9f6387d99228a0a9260318379b62de@intel.com","name":"Matt Roper"},"message":"drm/i915/gen9: Drop re-allocation of DDB at atomic commit (v2)\n\nNow that we're properly pre-allocating the DDB during the atomic check\nphase and we trust that the allocation is appropriate, let's actually\nuse the allocation computed and not duplicate that work during the\ncommit phase.\n\nv2:\n - Significant rebasing now that we can use cached data rates and\n   minimum block allocations to avoid grabbing additional plane states.\n\nSigned-off-by: Matt Roper <matthew.d.roper@intel.com>\nReviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>","distinct":true,"url":"https://api.github.com/repos/mattrope/kernel/commits/6ee1b7a55c0cdb8563e53840f48fb19425cad1b6"},{"sha":"6a5251bfcb11111e0c3da1d7b3cbf446a9c5d7ff","author":{"email":"f1605a76cb9f6387d99228a0a9260318379b62de@intel.com","name":"Matt Roper"},"message":"drm/i915/gen9: Calculate plane WM's from state\n\nIn a future patch we'll want to calculate plane watermarks for in-flight\natomic state rather than the already-committed state.\n\nSigned-off-by: Matt Roper <matthew.d.roper@intel.com>\nReviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>","distinct":true,"url":"https://api.github.com/repos/mattrope/kernel/commits/6a5251bfcb11111e0c3da1d7b3cbf446a9c5d7ff"},{"sha":"0528894591a9da1ab9a0706ea45df68561a6c653","author":{"email":"f1605a76cb9f6387d99228a0a9260318379b62de@intel.com","name":"Matt Roper"},"message":"drm/i915/gen9: Allow watermark calculation on in-flight atomic state (v3)\n\nIn an upcoming patch we'll move this calculation to the atomic 'check'\nphase so that the display update can be rejected early if no valid\nwatermark programming is possible.\n\nv2:\n - Drop intel_pstate_for_cstate_plane() helper and add note about how\n   the code needs to evolve in the future if we start allowing more than\n   one pending commit against a CRTC.  (Maarten)\n\nv3:\n - Only have skl_compute_wm_level calculate watermarks for enabled\n   planes; we can just set the other planes on a CRTC to disabled\n   without having to look at the plane state.  This is important because\n   despite our CRTC lock we can still have racing commits that modify\n   a disabled plane's property without turning it on.  (Maarten)\n\nSigned-off-by: Matt Roper <matthew.d.roper@intel.com>\nReviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>","distinct":true,"url":"https://api.github.com/repos/mattrope/kernel/commits/0528894591a9da1ab9a0706ea45df68561a6c653"},{"sha":"2e129652cc0ec83174189853364d11b6cf7258ed","author":{"email":"f1605a76cb9f6387d99228a0a9260318379b62de@intel.com","name":"Matt Roper"},"message":"drm/i915/gen9: Use a bitmask to track dirty pipe watermarks\n\nSlightly easier to work with than an array of bools.\n\nSigned-off-by: Matt Roper <matthew.d.roper@intel.com>\nReviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>","distinct":true,"url":"https://api.github.com/repos/mattrope/kernel/commits/2e129652cc0ec83174189853364d11b6cf7258ed"},{"sha":"4d11e3c5d08040774f67e6a49415152584411bb9","author":{"email":"f1605a76cb9f6387d99228a0a9260318379b62de@intel.com","name":"Matt Roper"},"message":"drm/i915/gen9: Propagate watermark calculation failures up the call chain\n\nOnce we move watermark calculation to the atomic check phase, we'll want\nto start rejecting display configurations that exceed out watermark\nlimits.  At the moment we just assume that there's always a valid set of\nwatermarks, even though this may not actually be true.  Let's prepare by\npassing return codes up through the call stack in preparation.\n\nSigned-off-by: Matt Roper <matthew.d.roper@intel.com>\nReviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>","distinct":true,"url":"https://api.github.com/repos/mattrope/kernel/commits/4d11e3c5d08040774f67e6a49415152584411bb9"},{"sha":"48b54933a33d053fa5a6ab30d0c360398b62dfa7","author":{"email":"f1605a76cb9f6387d99228a0a9260318379b62de@intel.com","name":"Matt Roper"},"message":"drm/i915/gen9: Calculate watermarks during atomic 'check'\n\nMoving watermark calculation into the check phase will allow us to to\nreject display configurations for which there are no valid watermark\nvalues before we start trying to program the hardware (although those\ntests will come in a subsequent patch).\n\nAnother advantage of moving this calculation to the check phase is that\nwe can calculate the watermarks in a single shot as part of the atomic\ntransaction.  The watermark interfaces we inherited from our legacy\nmodesetting days are a bit broken in the atomic design because they use\nper-crtc entry points but actually re-calculate and re-program something\nthat is really more of a global state.  That worked okay in the legacy\nmodesetting world because operations only ever updated a single CRTC at\na time.  However in the atomic world, a transaction can involve multiple\nCRTC's, which means we wind up computing and programming the watermarks\nNxN times (where N is the number of CRTC's involved).  With this patch\nwe eliminate the redundant re-calculation of watermark data for atomic\nstates (which was the cause of the WARN_ON(!wm_changed) problems that\nhave plagued us for a while).\n\nWe still need to work on the 'commit' side of watermark handling so that\nwe aren't doing redundant NxN programming of watermarks, but that's\ncontent for future patches.\n\nBugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89055\nBugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92181\nSigned-off-by: Matt Roper <matthew.d.roper@intel.com>\nReviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>\nTested-by: Daniel Stone <daniels@collabora.com>","distinct":true,"url":"https://api.github.com/repos/mattrope/kernel/commits/48b54933a33d053fa5a6ab30d0c360398b62dfa7"},{"sha":"866269f07e279c9a2f61ac4c8abf0f23993f9ab5","author":{"email":"f1605a76cb9f6387d99228a0a9260318379b62de@intel.com","name":"Matt Roper"},"message":"drm/i915/gen9: Reject display updates that exceed wm limitations (v2)\n\nIf we can't find any valid level 0 watermark values for the requested\natomic transaction, reject the configuration before we try to start\nprogramming the hardware.\n\nv2:\n - Add extra debugging output when we reject level 0 watermarks so that\n   we can more easily debug how/why they were rejected.\n\nCc: Lyude Paul <cpaul@redhat.com>\nSigned-off-by: Matt Roper <matthew.d.roper@intel.com>\nReviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>","distinct":true,"url":"https://api.github.com/repos/mattrope/kernel/commits/866269f07e279c9a2f61ac4c8abf0f23993f9ab5"},{"sha":"a8ab8b5ce64f0a0700b3c9a7d1f95678c78c3ffb","author":{"email":"f1605a76cb9f6387d99228a0a9260318379b62de@intel.com","name":"Matt Roper"},"message":"drm/i915: Remove wm_config from dev_priv/intel_atomic_state\n\nWe calculate the watermark config into intel_atomic_state and then save\nit into dev_priv, but never actually use it from there.  This is\nleft-over from some early ILK-style watermark programming designs that\ngot changed over time.\n\nSigned-off-by: Matt Roper <matthew.d.roper@intel.com>\nReviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>","distinct":true,"url":"https://api.github.com/repos/mattrope/kernel/commits/a8ab8b5ce64f0a0700b3c9a7d1f95678c78c3ffb"},{"sha":"36f5f9a51e255326931e406b11756631fe5faa1b","author":{"email":"bcb0c928da53a62868e6e5bb2a7ad065ed308592@intel.com","name":"Kumar, Mahesh"},"message":"drm/i915/skl+: calculate ddb minimum allocation (v4)\n\ndon't always use 8 ddb as minimum, instead calculate using proper\nalgorithm.\n\nv2: optimizations as per Matt's comments.\n\nv3 (by Matt):\n - Fix boolean logic for !fb test in skl_ddb_min_alloc()\n - Adjust negative tiling format comparisons in skl_ddb_min_alloc() to\n   improve readability.\n\nv4 (by Matt):\n - Rebase onto recent atomic watermark changes\n - Slight tweaks to code flow to make the logic more closely match the\n   description in the bspec.\n\nCc: matthew.d.roper@intel.com\nSigned-off-by: Kumar, Mahesh <mahesh1.kumar@intel.com>\nSigned-off-by: Matt Roper <matthew.d.roper@intel.com>","distinct":true,"url":"https://api.github.com/repos/mattrope/kernel/commits/36f5f9a51e255326931e406b11756631fe5faa1b"},{"sha":"ea9b0ed5675ff231de4ef9125b9de1e9416c01e5","author":{"email":"bcb0c928da53a62868e6e5bb2a7ad065ed308592@intel.com","name":"Kumar, Mahesh"},"message":"drm/i915/skl+: calculate plane pixel rate (v4)\n\nDon't use pipe pixel rate for plane pixel rate. Calculate plane pixel according\nto formula\n\nadjusted plane_pixel_rate = adjusted pipe_pixel_rate * downscale ammount\n\ndownscale amount = max[1, src_h/dst_h] * max[1, src_w/dst_w]\nif 90/270 rotation use rotated width & height\n\nv2: use intel_plane_state->visible instead of (fb == NULL) as per Matt's\n    comment.\n\nv3 (by Matt):\n - Keep downscale amount in 16.16 fixed point rather than converting to\n   decimal fixed point.\n - Store adjusted plane pixel rate in plane state instead of the plane\n   parameters structure that we no longer use.\n\nv4 (by Matt):\n - Significant rebasing onto latest atomic watermark work\n - Don't bother storing plane pixel rate in state; just calculate it\n   right before the calls that make use of it.\n - Fix downscale calculations to actually use width values when\n   computing downscale_w rather than copy/pasted height values.\n\nCc: matthew.d.roper@intel.com\nSigned-off-by: Kumar, Mahesh <mahesh1.kumar@intel.com>\nSigned-off-by: Matt Roper <matthew.d.roper@intel.com>","distinct":true,"url":"https://api.github.com/repos/mattrope/kernel/commits/ea9b0ed5675ff231de4ef9125b9de1e9416c01e5"},{"sha":"3f14680653fe337a86a94eedd1885205aee83aa1","author":{"email":"bcb0c928da53a62868e6e5bb2a7ad065ed308592@intel.com","name":"Kumar, Mahesh"},"message":"drm/i915/skl+: Use scaling amount for plane data rate calculation (v3)\n\nif downscaling is enabled plane data rate increases according to scaling\namount. take scaling amount under consideration while calculating plane\ndata rate\n\nv2: Address Matt's comments, where data rate was overridden because of\nmissing else.\n\nv3 (by Matt):\n - Add braces to 'else' branch to match kernel coding style\n - Adjust final calculation now that skl_plane_downscale_amount()\n   returns 16.16 fixed point value instead of a decimal fixed point\n\nCc: matthew.d.roper@intel.com\nSigned-off-by: Kumar, Mahesh <mahesh1.kumar@intel.com>\nReviewed-by(v2): Matt Roper <matthew.d.roper@intel.com>\nSigned-off-by: Matt Roper <matthew.d.roper@intel.com>","distinct":true,"url":"https://api.github.com/repos/mattrope/kernel/commits/3f14680653fe337a86a94eedd1885205aee83aa1"}]}