- 20 Sep, 2022 1 commit
-
-
Dave Airlie authored
Merge tag 'drm-intel-gt-next-2022-09-16' of git://anongit.freedesktop.org/drm/drm-intel into drm-next Cross-subsystem Changes: - MEI subsystem pieces for XeHP SDV GSC support These are Acked-by Greg. Driver Changes: - Release mmaps on RPM suspend on discrete GPUs (Anshuman) - Update GuC version to 7.5 on DG1, DG2 and ADL - Revert "drm/i915/dg2: extend Wa_1409120013 to DG2" (Lucas) - MTL enabling incl. standalone media (Matt R, Lucas) - Explicitly clear BB_OFFSET for new contexts on Gen8+ (Chris) - Fix throttling / perf limit reason decoding (Ashutosh) - XeHP SDV GSC support (Vitaly, Alexander, Tomas) - Fix issues with overrding firmware file paths (John) - Invert if-else ladders to check latest version first (Lucas) - Cancel GuC engine busyness worker synchronously (Umesh) - Skip applying copy engine fuses outside PVC (Lucas) - Eliminate Gen10 frequency read function (Lucas) - Static code checker fixes (Gaosheng) - Selftest improvements (Chris) Signed-off-by:
Dave Airlie <airlied@redhat.com> From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/YyQ4Jgl3cpGL1/As@jlahtine-mobl.ger.corp.intel.com
-
- 16 Sep, 2022 1 commit
-
-
John Harrison authored
Going forwards, the intention is for GuC firmware files to be named for their major version only and HuC firmware files to have no version number in the name at all. This patch adds those entries for all platforms that are officially GuC/HuC enabled. Also, update the expected GuC version numbers to the latest firmware release for those platforms. Signed-off-by:
John Harrison <John.C.Harrison@Intel.com> Reviewed-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220914234605.622342-2-John.C.Harrison@Intel.com
-
- 15 Sep, 2022 4 commits
-
-
git://anongit.freedesktop.org/drm/drm-intelDave Airlie authored
drm/i915 feature pull for v6.1: Features and functionality: - Early Meteorlake (MTL) enabling (José, Radhakrishna, Clint, Imre, Vandita, Ville, Jani) - Support more HDMI pixel clock frequencies on DG2 (Clint) - Sanity check PCI BARs (Piotr Piórkowski) - Enable DC5 on DG2 (Anusha) - DG2 DMC firmware version bump to v2.07 (Madhumitha) - New ADL-S PCI ID (José) Refactoring and cleanups: - Add display sub-struct to struct drm_i915_private (Jani) - Add initial runtime info to device info (Jani) - Split out HDCP and backlight registers to separate files (Jani) Fixes: - Skip wm/ddb readout for disabled pipes (Ville) - HDMI port timing quirk for GLK ECS Liva Q2 (Diego Santa Cruz) - Fix bw init null pointer dereference (Łukasz Bartosik) - Disable PPS power hook for DP AUX backlight (Jouni) - Avoid warnings on registering multiple backlight devices (Arun) - Fix dual-link DSI backlight and CABC ports for display 11+ (Jani) - Fix Type-C PHY ownership programming in HDMI legacy mode (Imre) - Fix unclaimed register access while loading PIPEDMC-C/D (Imre) - Bump up CDCLK for DG2 (Stan) - Prune modes that require HDMI 2.1 FRL (Ankit) - Disable FBC when PSR1 is enabled in display 12-13 (Matt) - Fix TGL+ HDMI transcoder clock and DDI BUF disable order (Imre) - Disable PSR before disable pipe (José) - Disable DMC handlers during firmware loading/disabling on display 12+ (Imre) - Disable clock gating for PIPEDMC-A/B as a workaround (Imre) Merges: - Two drm-next backmerges (Rodrigo, Jani) Signed-off-by:
-
Lucas De Marchi authored
Continue converting the driver to the convention of last version first, extending it to the future platforms. Now, any GRAPHICS_VER >= 11 will be handled by the first branch. Reviewed-by:
Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220908-if-ladder-v2-3-7a7b15545c93@intel.com Link: https://patchwork.freedesktop.org/patch/msgid/20220912-copy-engine-v1-1-ef92fd81758d@intel.com
-
Lucas De Marchi authored
Instead of calling read_clock_frequency() to walk the if/else ladder per platform, move the ladder to intel_gt_init_clock_frequency() and use one function per branch. With the new logic, it's now clear the call to gen9_get_crystal_clock_freq() was just dead code, as gen9 is handled by another function and there is no version 10. Remove that function and the caller. v2: Correctly handle intel_gt_check_clock_frequency() that also calls the function to read clock frequency (Gustavo) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by:
-
Lucas De Marchi authored
Continue converting the driver to the convention of last version first, extending it to the future platforms. Now, any GRAPHICS_VER >= 11 will be handled by the first branch. With the new ranges it's easier to see what platform a branch started to be taken. Besides the >= 11 change, the branch taken for GRAPHICS_VER == 10 is also different, but currently there is no such platform in i915. Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220908-if-ladder-v2-1-7a7b15545c93@intel.com
-
- 14 Sep, 2022 7 commits
-
-
John Harrison authored
The earlier update to support reduced versioning of firmware files introduced an issue with the firmware override module parameter. A self test would specify an invalid file name (invalid meaning not in the table) both with and without setting the override flag. The *non-override* case would cause an infinite loop. I.e. a situation that is impossible to hit outside of the selftest because either the file name has come from the table in first place or it came from an override. However, the override case was also broken in that it would bypass some of the later processing. The first fix is to update the scanning loop code so that if an invalid file is passed in, it will exit rather than loop forever. So if the impossible situation did somehow occur in the future, it wouldn't be such a big problem. The second flips the logic on the override early exit to be negative rather than positive. That way if an explicit override has been set, then it won't try to scan for backup options (because there is no point anyway - the user wanted X and if X is not available, that's their problem). It also means that it won't skip code that still needs to be run once a valid firmware file has been selected. v2: Also remove ANSI colour codes that accidentally got left in an error message in the original patch. Fixes: 665ae9c9 ("drm/i915/uc: Support for version reduced and multiple firmware files") Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Cc: "Thomas Hellström" <thomas.hellstrom@linux.intel.com> Cc: Venkata Sandeep Dhanalakota <venkata.s.dhanalakota@intel.com> Signed-off-by:
-
Anshuman Gupta authored
Release all mmap mapping for all lmem objects which are associated with userfault such that, while pcie function in D3hot, any access to memory mappings will raise a userfault. Runtime resume the dgpu(when gem object lies in lmem). This will transition the dgpu graphics function to D0 state if it was in D3 in order to access the mmap memory mappings. v2: - Squashes the patches. [Matt Auld] - Add adequate locking for lmem_userfault_list addition. [Matt Auld] - Reused obj->userfault_count to avoid double addition. [Matt Auld] - Added i915_gem_object_lock to check i915_gem_object_is_lmem. [Matt Auld] v3: - Use i915_ttm_cpu_maps_iomem. [Matt Auld] - Fix 'ret == 0 to ret == VM_FAULT_NOPAGE'. [Matt Auld] - Reuse obj->userfault_count as a bool 0 or 1. [Matt Auld] - Delete the mmaped obj from lmem_userfault_list in obj destruction path. [Matt Auld] - Get a wakeref for object destruction patch. [Matt Auld] - Use intel_wakeref_auto to delay runtime PM. [Matt Auld] v4: - Avoid using mmo offset to get the vma_node. [Matt Auld] - Added comment to use the lmem_userfault_lock. [Matt Auld] - Get lmem_userfault_lock in i915_gem_object_release_mmap_offset. [Matt Auld] - Fixed kernel test robot generated warning. v5: - Addressed the cosmetics comments. [Andi] - Changed i915_gem_runtime_pm_object_release_mmap_offset() name to i915_gem_object_runtime_pm_release_mmap_offset() to be rhythmic. PCIe Specs 5.3.1.4.1 Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6331 Cc: Matthew Auld <matthew.auld@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Anshuman Gupta <anshuman.gupta@intel.com> Reviewed-by:
Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220913152714.16541-3-anshuman.gupta@intel.com
-
Anshuman Gupta authored
Refactor userfault_wakeref to re-use for discrete lmem mmap mapping as well, as on discrete GTT mmap are not supported. Moving userfault_wakeref from ggtt to gt structure. Signed-off-by:
-
Chris Wilson authored
When testing whether we can get the GPU to leak information about non-privileged state, we first need to ensure that the output buffer is set to a known value as the HW may opt to skip the write into memory for a non-privileged read of a sensitive register. We chose POISON_INUSE (0x5a) so that is both non-zero and distinct from the poison values used during the test. v2: Use i915_gem_object_pin_map_unlocked Reported-by:
CQ Tang <cq.tang@intel.com> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: CQ Tang <cq.tang@intel.com> cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by:
Ramalingam C <ramalingam.c@intel.com> Reviewed-by:
Thomas Hellstrom <thomas.hellstrom@linux.intel.com> Signed-off-by:
Karolina Drobnik <karolina.drobnik@intel.com> Reviewed-by:
-
Chris Wilson authored
Ensure that we always signal the semaphore when timing out, so that if it happens to be stuck waiting for the semaphore we will quickly recover without having to wait for a reset. Reported-by:
-
Chris Wilson authored
In order to keep the context image parser simple, we assume that all commands follow a similar format. A few, especially not MI commands on the render engines, have fixed lengths not encoded in a length field. This caused us to incorrectly skip over 3D state commands, and start interpreting context data as instructions. Eventually, as Daniele discovered, this would lead us to find addition LRI as part of the data and mistakenly add invalid LRI commands to the context probes. Stop parsing after we see the first !MI command, as we know we will have seen all the context registers by that point. (Mostly true for all gen so far, though the render context does have LRI after the first page that we have been ignoring so far. It would be useful to extract those as well so that we have the full list of user accessible registers.) Similarly, emit a warning if we do try to emit an invalid zero-length LRI. Testcase: igt@i915_selftest@live@gt_lrc Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6580 Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6670Reported-by:
Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Reviewed-by:
-
Chris Wilson authored
Even though the initial protocontext we load onto HW has the register cleared, by the time we save it into the default image, BB_OFFSET has had the enable bit set. Reclear BB_OFFSET for each new context. Testcase: igt/i915_selftests/gt_lrc v2: Extend it for gen8. v3: BB_OFFSET is recorded per engine from Gen9 onwards Signed-off-by:
-
- 13 Sep, 2022 2 commits
-
-
Lucas De Marchi authored
Support for reading the fuses to check what are the Link Copy engines was added in commit ad5f74f3 ("drm/i915/pvc: read fuses for link copy engines"). However they were added unconditionally because the FUSE3 register is present since graphics version 10. However the bitfield with meml3 fuses only exists since graphics version 12. Moreover, Link Copy engines are currently only available in PVC. Tying additional copy engines to the meml3 fuses is not correct for other platforms. Make sure there is a check for `12.60 <= ver < 12.70`. Later platforms may extend this function later if it's needed to fuse off copy engines. Currently it's harmless as the Link Copy engines are still not exported: info->engine_mask only has BCS0 set and the register is only read for platforms that do have it. Signed-off-by:
Andrzej Hajda <andrzej.hajda@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220912-copy-engine-v1-1-ef92fd81758d@intel.com
-
Gaosheng Cui authored
i915_gem_lmem_obj_ops has been removed since commit 213d5092 ("drm/i915/ttm: Introduce a TTM i915 gem object backend"), so remove it. Signed-off-by:
Gaosheng Cui <cuigaosheng1@huawei.com> Acked-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
- 12 Sep, 2022 25 commits
-
-
Lucas De Marchi authored
Just like is done for compute and copy engines, extract a function to handle media engines. While at it, be consistent on using or not the uncore/gt/info variable aliases. Reviewed-by:
-
Lucas De Marchi authored
Check for media IP version instead of graphics since this is figuring out the media engines' configuration. Currently the only platform with non-matching graphics/media version is Meteor Lake: update the check in gen11_vdbox_has_sfc() so it considers not only version 12, but also any later version which then includes that platform. Reviewed-by:
-
Matt Roper authored
Top-level handling of standalone media interrupts will be processed as part of the primary GT's interrupt handler (since primary and media GTs share an MMIO space, unlike remote tile setups). When we get down to the point of handling engine interrupts, we need to take care to lookup VCS and VECS engines in the media GT rather than the primary. There are also a couple of additional "other" instance bits that correspond to the media GT's GuC and media GT's power management interrupts; we need to direct those to the media GT instance as well. Bspec: 45605 Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
Matt Roper authored
When we hook up interrupts (in the next patch), interrupts for the media GT are still processed as part of the primary GT's interrupt flow. As such, we should share the same IRQ lock with the primary GT. Let's convert gt->irq_lock into a pointer and just point the media GT's instance at the same lock the primary GT is using. v2: - Point media's gt->irq_lock at the primary GT lock properly. (Daniele) - Fix jump target for intel_root_gt_init_early errors. (Daniele) Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
-
Matt Roper authored
Xe_LPM+ platforms have "standalone media." I.e., the media unit is designed as an additional GT with its own engine list, GuC, forcewake, etc. Let's allow platforms to include media GTs in their device info. v2: - Simplify GSI register handling and split it out to a separate patch for ease of review. (Daniele) Cc: Aravind Iddamsetty <aravind.iddamsetty@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
Aravind Iddamsetty <aravind.iddamsetty@intel.com> Acked-by:
-
Matt Roper authored
The aux table invalidation registers are a bit unique --- they're engine-centric registers that reside in the GSI register space rather than within the engines' regular MMIO ranges. That means that when issuing invalidation on engines in the standalone media GT, the GSI offset must be added to the regular MMIO offset for the invalidation registers. Cc: Aravind Iddamsetty <aravind.iddamsetty@intel.com> Signed-off-by:
-
Matt Roper authored
GT non-engine registers (referred to as "GSI" registers by the spec) have the same relative offsets on standalone media as they do on the primary GT, just with an additional "GSI offset" added to their MMIO address. If we store this GSI offset in the standalone media's intel_uncore structure, it can be automatically applied to all GSI reg reads/writes that happen on that GT, allowing us to re-use our existing GT code with minimal changes. Forcewake and shadowed register tables for the media GT (which will be added in a future patch) are listed as final addresses that already include the GSI offset, so we also need to add the GSI offset before doing lookups of registers in one of those tables. v2: - Add comment on raw_reg_*() macros explaining why we don't bother with GSI offsets in them. (Daniele) Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
-
Matt Roper authored
In preparation for enabling a second GT, there are a number of GT/uncore operations that happen during initialization or suspend flows that need to be performed on each GT, not just the primary, Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
-
Matt Roper authored
In a multi-GT system we need to initialize MMIO access for each GT, not just the primary GT. Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
-
Matt Roper authored
As we start supporting multiple uncore structures in future patches, the MMIO cleanup (which may also get called mid-init if there's a failure) will become more complicated. Moving to DRM-managed actions will help keep things simple. Signed-off-by:
Radhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220906234934.3655440-8-matthew.d.roper@intel.comSigned-off-by:
-
Matt Roper authored
The common early GT init is needed for initialization of all GT types (root/primary, remote tile, standalone media). Since standalone media (coming in a future patch) will be implemented in a separate file, rename and expose the function for use. Signed-off-by:
-
Matt Roper authored
We're going to introduce an additional intel_gt for MTL's media unit soon. Let's provide a bit more multi-GT initialization framework in preparation for that. The initialization will pull the list of GTs for a platform from the device info structure. Although necessary for the immediate MTL media enabling, this same framework will also be used farther down the road when we enable remote tiles on xehpsdv and pvc. v2: - Re-add missing test for !HAS_EXTRA_GT_LIST in intel_gt_probe_all(). v3: - Move intel_gt_definition struct to intel_gt_types.h. (Jani) - Drop gtdef->setup(). For now we'll just use a switch() based on GT type since we don't have too many different handlers for the foreseeable future. (Jani) Cc: Aravind Iddamsetty <aravind.iddamsetty@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by:
-
Matt Roper authored
Unmapping of the MMIO range can be done as a DRM-managed action, which will take care of the unmapping on device teardown and error paths. This will also ensure proper ordering with respect to other DRM-managed actions that we'll be using to clean up non-primary GTs in upcoming patches. We have not yet enabled any non-root GTs in the driver yet, so the kfree() of the GT structure is effectively dead code. When we do start enabling non-root GTs in upcoming patches, those are going to be using DRM-managed allocations tied to the device lifetime, so we don't need to explicitly free them (and kfree would be incorrect anyway). Signed-off-by:
-
Matt Roper authored
We're slowly transitioning the init-time kzalloc's of the driver over to DRM-managed allocations; let's make sure the uncore objects allocated for non-root GTs are thus allocated. Signed-off-by:
-
Matt Roper authored
The original intent of intel_uncore_mmio_debug as described in commit 0a9b2630 ("drm/i915: split out uncore_mmio_debug") was to be a singleton structure that could be shared between multiple GTs' uncore objects in a multi-tile system. Somehow we went off track and started allocating separate instances of this structure for each GT, which defeats that original goal. But in reality, there isn't even a need to share the mmio_debug between multiple GTs; on all modern platforms (i.e., everything after gen7) unclaimed register accesses are something that can only be detected for display registers. There's no point in grabbing the debug spinlock and checking for unclaimed accesses on an uncore used by an xehpsdv or pvc remote tile GT, or the uncore used by a mtl standalone media GT since all of the display accesses go through the primary intel_uncore. The simplest solution is to simply leave uncore->debug NULL on all intel_uncore instances except for the primary one. This will allow us to avoid the pointless debug spinlock acquisition we've been doing on MMIO accesses coming in through these intel_uncores. Signed-off-by:
-
Matt Roper authored
Moving the locking for MMIO debug (and the final check for unclaimed accesses when resuming debug after a userspace-initiated forcewake) will make it simpler to completely skip MMIO debug handling on uncores that don't support it in future patches. Signed-off-by:
-
Ashutosh Dixit authored
Perf limit reasons bit positions were off by one. Fixes: fa68bff7 ("drm/i915/gt: Add sysfs throttle frequency interfaces") Cc: stable@vger.kernel.org # v5.18+ Signed-off-by:
Ashutosh Dixit <ashutosh.dixit@intel.com> Acked-by:
Sujaritha Sundaresan <sujaritha.sundaresan@intel.com> Signed-off-by:
-
Lucas De Marchi authored
This reverts commit 487970e8. Updated bspec and workaround database note Wa_1409120013 is not needed for DG2 (or any Xe_LPD) platform. Simply check by display version 12. v2: Simplify condition check to display version (Matt Roper) Cc: Matt Atwood <matthew.s.atwood@intel.com> Cc: Clint Taylor <Clinton.A.Taylor@intel.com> Signed-off-by:
-
Umesh Nerlige Ramappa authored
The worker is canceled in gt_park path, but earlier it was assumed that gt_park path cannot sleep and the cancel is asynchronous. This caused a race with suspend flow where the worker runs after suspend and causes an unclaimed register access warning. Cancel the worker synchronously since the gt_park is indeed allowed to sleep. v2: Fix author name and sign-off mismatch Signed-off-by:
Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4419 Fixes: 77cdd054 ("drm/i915/pmu: Connect engine busyness stats from GuC to pmu") Reviewed-by:
-
Tomas Winkler authored
GSC requires more operational memory than available on chip. Reserve 4M of LMEM for GSC operation. The memory is provided to the GSC as struct resource to the auxiliary data of the child device. Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Signed-off-by:
Tomas Winkler <tomas.winkler@intel.com> Signed-off-by:
Alexander Usyskin <alexander.usyskin@intel.com> Signed-off-by:
Alan Previn <alan.previn.teres.alexis@intel.com> Signed-off-by:
-
Tomas Winkler authored
Add pxp mode devstate to debugfs to monitor pxp state machine progress. This is useful to debug issues in scenarios in which the pxp state needs to be re-initialized, like during power transitions such as suspend/resume. With this debugfs the state could be monitored to ensure that pxp is in the ready state. CC: Vitaly Lubart <vitaly.lubart@intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Alexander Usyskin authored
The check that hardware and host ready bits are set after start is redundant and may fail and disable driver if there is back-to-back link reset issued right after start. This happens during pxp mode transitions when firmware undergo reset. Remove these checks to eliminate such failures. Signed-off-by:
-
Vitaly Lubart authored
Added transition to PXP mode in resume flow. CC: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
Vitaly Lubart <vitaly.lubart@intel.com> Signed-off-by:
-
Tomas Winkler authored
1. Retrieve extended operational memory physical pointers from the auxiliary device info. 2. Setup memory registers. 3. Notify firmware that the memory is ready by sending the memory ready command. 4. Disable PXP device if GSC is not in PXP mode. CC: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
-
Tomas Winkler authored
Add GSC memory ready command. The command indicates to the firmware that extend operation memory was setup and the firmware may enter PXP mode. CC: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
-
