- Oct 07, 2022
-
-
Jason Yen authored
This chip can not handle aux defer if the host directly program its aux registers to access edid/dpcd. So we need let software to handle the aux defer situation. Signed-off-by:
Jason Yen <jason.yen@paradetech.corp-partner.google.com> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
Sean Paul <sean@poorly.run> Commit-Queue: Pin-yen Lin <treapking@chromium.org> Tested-by:
Pin-yen Lin <treapking@chromium.org> Reviewed-by:
-
Imre Deak authored
Add a workaround making sure that PIPEDMC-A/B is enabled when the firmware needs these on D13 platforms to save/restore the registers backed by the PW_1 and PW_A power wells. Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220727164523.1621361-2-imre.deak@intel.com (cherry picked from commit f31bccd3 https://anongit.freedesktop.org/git/drm-intel.git drm-intel-next) BUG=b:242077859 TEST=i915 driver loaded successfully Change-Id: Iad21c02928dfa2b39c08e5931fea8f615ab2dcb4 Signed-off-by:
Mohanram Meenakshisundaram <mohanram.meenakshisundaram@intel.com> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/3910574 Tested-by:
Rajat Jain <rajatja@google.com> Commit-Queue: Rajat Jain <rajatja@google.com> Reviewed-by:
Drew Davenport <ddavenport@chromium.org> Reviewed-by:
-
Imre Deak authored
Disable the DMC event handlers before loading the firmware and after uninitializing the display, to make sure the firmware is inactive. This matches the Bspec "Sequences for Display C5 and C6" page for GEN12+. Add a TODO comment for doing the same on pre-GEN12 platforms. v2: - Add a macro for the number of event handlers. - Disable the event handlers only on GEN12+. - s/dev_priv/i915/ in docbook comment. Signed-off-by:
-
Madhumitha Tolakanahalli Pradeep authored
The release notes mention that DMC v2.07 has a workaround for MMIO hang issue when DC States are enabled. Signed-off-by:
Madhumitha Tolakanahalli Pradeep <madhumitha.tolakanahalli.pradeep@intel.com> Reviewed-by:
-
Anusha Srivatsa authored
gen11_gu_misc_irq_handler() and gen11_gu_misc_ack() do nothing tile specific. v2: gen11_gu_misc_irq_ack() tile agnostic like gen11_gu_misc_irq_handler() (Tvrtko) Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220721225100.693589-1-anusha.srivatsa@intel.com (cherry picked from commit ddcf980f https://anongit.freedesktop.org/git/drm-intel.git drm-intel-next) BUG=b:242077859 TEST=i915 driver loaded successfully Change-Id: I50f5e824d5a4e699ca62b8753bfdf3739f239ada Signed-off-by:
-
Anusha Srivatsa authored
Cleanup the intel_phy_is_combo to accommodate for cases where combo phy is not available. v2: retain comment that explains DG2 returning false from intel_phy_is_combo() (Arun) Cc: Arun R Murthy <arun.r.murthy@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
Arun R Murthy <arun.r.murthy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220725225028.98612-1-anusha.srivatsa@intel.com (cherry picked from commit ace98ffc https://anongit.freedesktop.org/git/drm-intel.git drm-intel-next) BUG=b:242077859 TEST=i915 driver loaded successfully Change-Id: I29d71e641eee0a3b29c1c7a3af541c86a5de111f Signed-off-by:
-
John Harrison authored
A bunch of code was copy/pasted using pr_err as the default way to report errors. However, drm_err is significantly more useful in identifying where the error came from. So update the code to use that instead. Signed-off-by:
John Harrison <John.C.Harrison@Intel.com> Reviewed-by:
Ashutosh Dixit <ashutosh.dixit@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220715004028.2126239-1-John.C.Harrison@Intel.com (cherry picked from commit a4a43070 https://anongit.freedesktop.org/git/drm-intel.git drm-intel-next) BUG=b:242077859 TEST=i915 driver loaded successfully Change-Id: I004e7ef19bbb9cdb45ddf20403deccd8d8519ac6 Signed-off-by:
-
José Roberto de Souza authored
The issue here was on for_each_intel_encoder_mask_with_psr() over the new_crtc_state encoder mask, so if the CRTC was being disabled mask would be zero and it would not have any chance to disable PSR. So here doing for_each_intel_encoder_mask_with_psr() over the old_crtc_state encoder mask and then using the new_crtc_state to check if PSR needs to be disabled. Cc: Jouni Högander <jouni.hogander@intel.com> Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Reviewed-by:
Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220714150755.154985-2-jose.souza@intel.com (cherry picked from commit 031a2fea https://anongit.freedesktop.org/git/drm-intel.git drm-intel-next) BUG=b:242077859 TEST=i915 driver loaded successfully Change-Id: I3fca454906c0df360042daef11bb8c56c7be5ee8 Signed-off-by:
-
Matt Roper authored
Accidental use of a "SLICE" macro where a "SUBSLICE" macro was intended causes the group ID for steering to be calculated incorrectly on pre-Xe_HP platforms. Fixes: 9a92732f ("drm/i915/gt: Add general DSS steering iterator to intel_gt_mcr") Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220712220513.3451794-1-matthew.d.roper@intel.com (cherry picked from commit a5e4a538) BUG=b:242077859 TEST=i915 driver loaded successfully Change-Id: I0c108f43ed667d28518ddcdc03d7eebab4f7f808 Signed-off-by:
Stéphane Marchesin <marcheu@chromium.org> Commit-Queue: Rajat Jain <rajatja@google.com> Reviewed-by:
-
Matt Roper authored
We already disable FBC when PSR2 is enabled on display version 12 and above; this new workaround now requires that we do the same with PSR1 on display versions 12 and 13. Signed-off-by:
-
Matt Roper authored
This workaround may need to be extended to other platforms soon, but for now it's marked as DG2-specific. Signed-off-by:
-
Radhakrishna Sripada authored
Add Meteorlake PCI IDs. Split into M, and P subplatforms. v2: Update PCI id's v3: Move id 7d60 under MTL_M(MattR) Bspec: 55420 Signed-off-by:
Radhakrishna Sripada <radhakrishna.sripada@intel.com> Signed-off-by:
-
Radhakrishna Sripada authored
MTL has Xe_LPD+ display IP (version = 14), MTL graphics IP (version = 12.70), and Xe_LPM+ media IP (version = 13). Bspec: 55413 Bspec: 55416 Bspec: 55417 Bspec: 55418 Bspec: 55726 Bspec: 45544 Bspec: 65380 v2: rearrange the fields in pci_info(MattR) Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
Matt Roper authored
Although all DSS belong to a single pool on Xe_HP platforms (i.e., they're not organized into slices from a topology point of view), we do still need to pass 'group' and 'instance' targets when steering register accesses to a specific instance of a per-DSS multicast register. The rules for how to determine group and instance IDs (which previously used legacy terms "slice" and "subslice") varies by platform. Some platforms determine steering by gslice membership, some platforms by cslice membership, and future platforms may have other rules. Since looping over each DSS and performing steered unicast register accesses is a relatively common pattern, let's add a dedicated iteration macro to handle this (and replace the platform-specific "instdone" loop we were using previously. This will avoid the calling code needing to figure out the details about how to obtain steering IDs for a specific DSS. Most of the places where we use this new loop are in the GPU errorstate code at the moment, but we do have some additional features coming in the future that will also need to loop over each DSS and steer some register accesses accordingly. Signed-off-by:
Matt Atwood <matthew.s.atwood@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220701232006.1016135-1-matthew.d.roper@intel.com (cherry picked from commit 9a92732f) BUG=b:242077859 TEST=i915 driver loaded successfully Change-Id: Ieb65a2a09997b584ebc789bf4fe45c4ed3242c04 Signed-off-by:
-
Alan Previn authored
Both error-capture and relay-logging mechanism use the GuC log infrastructure. That means the KMD must send a log flush complete notification back to GuC after reading the data out. This call is currently being sent synchronously. However, synchronous H2Gs cause problems when the system is backed up. There is no need for this to be synchronous. The KMD wasn't even looking at the return status from it. So make it asynchronous and then there is no issue about time outs. Signed-off-by:
Alan Previn <alan.previn.teres.alexis@intel.com> Reviewed-by:
-
Tom Rix authored
spelling changes resoluition -> resolution dont -> don't commmit -> commit Invalidade -> Invalidate Signed-off-by:
Tom Rix <trix@redhat.com> Reviewed-by:
-
Matt Roper authored
Small BAR support has now landed, which allows us to add the PCI IDs that correspond to add-in card designs of DG2 and ATS-M. There's also one additional MB-down PCI ID that recently appeared (0x5698) so we add it too. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
Gustavo Sousa authored
A new PVC-specific workaround has just been added to the BSpec. BSpec: 64027 Signed-off-by:
Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by:
-
José Roberto de Souza authored
Display is turned off by i915_drm_suspend() during the suspend procedure, removing the last reference of some gem objects that were used by display. The issue is that those objects are only actually freed when mm.free_work executed and that can happen very late in the suspend process causing issues. So here draining all freed objects released by display fixing suspend issues. Signed-off-by:
-
Lucas De Marchi authored
Like was done for read, provide the equivalent for write. Even if current users are not in the hot path, this should future-proof it. v2: - Remove default from _Generic() - callers wanting to write more than u64 should use iosys_map_memcpy_to() - Add WRITE_ONCE() cases dereferencing the pointer when using system memory v3: - Fix precedence issue when casting inside WRITE_ONCE(). By not using () around vaddr__ the offset was not part of the cast, but rather added to it, producing a wrong address - Remove compiletime_assert() as WRITE_ONCE() already contains it Signed-off-by:Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220628191016.3899428-2-lucas.demarchi@intel.com (cherry picked from commit 6fb5ee7c) BUG=b:242077859 TEST=i915 driver loaded successfully Change-Id: If18f0d38b3459ffadd019e587e1958311ed22d13 Signed-off-by:
-
Lucas De Marchi authored
Instead of always falling back to memcpy_fromio() for any size, prefer using read{b,w,l}(). When reading struct members it's common to read individual integer variables individually. Going through memcpy_fromio() for each of them poses a high penalty. Employ a similar trick as __seqprop() by using _Generic() to generate only the specific call based on a type-compatible variable. For a pariticular i915 workload producing GPU context switches, __get_engine_usage_record() is particularly hot since the engine usage is read from device local memory with dgfx, possibly multiple times since it's racy. Test execution time for this test shows a ~12.5% improvement with DG2: Before: nrepeats = 1000; min = 7.63243e+06; max = 1.01817e+07; median = 9.52548e+06; var = 526149; After: nrepeats = 1000; min = 7.03402e+06; max = 8.8832e+06; median = 8.33955e+06; var = 333113; Other things attempted that didn't prove very useful: 1) Change the _Generic() on x86 to just dereference the memory address 2) Change __get_engine_usage_record() to do just 1 read per loop, comparing with the previous value read 3) Change __get_engine_usage_record() to access the fields directly as it was before the conversion to iosys-map (3) did gave a small improvement (~3%), but doesn't seem to scale well to other similar cases in the driver. Additional test by Chris Wilson using gem_create from igt with some changes to track object creation time. This happens to accidentally stress this code path: Pre iosys_map conversion of engine busyness: lmem0: Creating 262144 4KiB objects took 59274.2ms Unpatched: lmem0: Creating 262144 4KiB objects took 108830.2ms With readl (this patch): lmem0: Creating 262144 4KiB objects took 61348.6ms s/readl/READ_ONCE/ lmem0: Creating 262144 4KiB objects took 61333.2ms So we do take a little bit more time than before the conversion, but that is due to other factors: bringing the READ_ONCE back would be as good as just doing this conversion. v2: - Remove default from _Generic() - callers wanting to read more than u64 should use iosys_map_memcpy_from() - Add READ_ONCE() cases dereferencing the pointer when using system memory v3: - Fix precedence issue when casting inside READ_ONCE(). By not using () around vaddr__ the offset was not part of the cast, but rather added to it, producing a wrong address - Remove compiletime_assert() as READ_ONCE() already contains it Signed-off-by: -
Imre Deak authored
The driver expects the pitch of the Intel CCS CC color planes to be 64 bytes aligned, adjust the modifier descriptions accordingly. Cc: Nanley Chery <nanley.g.chery@intel.com> Signed-off-by:
Nanley Chery <nanley.g.chery@intel.com> Reviewed-by:
Jordan Justen <jordan.l.justen@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220623144955.2486736-1-imre.deak@intel.com (cherry picked from commit 882d9031) BUG=b:242077859 TEST=i915 driver loaded successfully Change-Id: I24ca5ad5af7e1281fdf6697c70c5db5eeb715f7e Signed-off-by:
-
Vinay Belgaumkar authored
SLPC min/max frequency updates require H2G calls. We are seeing timeouts when GuC channel is backed up and it is unable to respond in a timely fashion causing warnings and affecting CI. This is seen when waitboosting happens during a stress test. this patch updates the waitboost path to use a non-blocking H2G call instead, which returns as soon as the message is successfully transmitted. v2: Use drm_notice to report any errors that might occur while sending the waitboost H2G request (Tvrtko) v3: Add drm_notice inside force_min_freq (Ashutosh) Cc: Ashutosh Dixit <ashutosh.dixit@intel.com> Signed-off-by:
Vinay Belgaumkar <vinay.belgaumkar@intel.com> Reviewed-by:
-
Alan Previn authored
Using two different types of workoads, it was observed that guc_update_engine_gt_clks was being called too frequently and/or causing a CPU-to-lmem bandwidth hit over PCIE. Details on the workloads and numbers are in the notes below. Background: At the moment, guc_update_engine_gt_clks can be invoked via one of 3 ways. #1 and #2 are infrequent under normal operating conditions: 1.When a predefined "ping_delay" timer expires so that GuC- busyness can sample the GTPM clock counter to ensure it doesn't miss a wrap-around of the 32-bits of the HW counter. (The ping_delay is calculated based on 1/8th the time taken for the counter go from 0x0 to 0xffffffff based on the GT frequency. This comes to about once every 28 seconds at a GT frequency of 19.2Mhz). 2.In preparation for a gt reset. 3.In response to __gt_park events (as the gt power management puts the gt into a lower power state when there is no work being done). Root-cause: For both the workloads described farther below, it was observed that when user space calls IOCTLs that unparks the gt momentarily and repeats such calls many times in quick succession, it triggers calling guc_update_engine_gt_clks as many times. However, the primary purpose of guc_update_engine_gt_clks is to ensure we don't miss the wraparound while the counter is ticking. Thus, the solution is to ensure we skip that check if gt_park is calling this function earlier than necessary. Solution: Snapshot jiffies when we do actually update the busyness stats. Then get the new jiffies every time intel_guc_busyness_park is called and bail if we are being called too soon. Use half of the ping_delay as a safe threshold. NOTE1: Workload1: IGTs' gem_create was modified to create a file handle, allocate memory with sizes that range from a min of 4K to the max supported (in power of two step-sizes). Its maps, modifies and reads back the memory. Allocations and modification is repeated until total memory allocation reaches the max. Then the file handle is closed. With this workload, guc_update_engine_gt_clks was called over 188 thousand times in the span of 15 seconds while this test ran three times. With this patch, the number of calls reduced to 14. NOTE2: Workload2: 30 transcode sessions are created in quick succession. While these sessions are created, pcm-iio tool was used to measure I/O read operation bandwidth consumption sampled at 100 milisecond intervals over the course of 20 seconds. The total bandwidth consumed over 20 seconds without this patch was measured at average at 311KBps per sample. With this patch, the number went down to about 175Kbps which is about a 43% savings. Signed-off-by:Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Acked-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by:
-
José Roberto de Souza authored
When the last reference of a gem object is removed it is added to the mm.free_list list and mm.free_work is queued to actually free the object. So gem objects that had their last reference removed by display during drm_atomic_helper_shutdown() are added to mm.free_list what could cause that mm.free_work is executed at the same time as intel_runtime_pm_driver_release() causing raw-wakerefs warning. So here only calling i915_gem_suspend() and by consequence i915_gem_drain_freed_objects() only after display is down making sure all display gem objecs are freed when intel_runtime_pm_driver_release() is executed. Signed-off-by:
-
Lucas De Marchi authored
Re-do what was attempted in commit 7a5c9223 ("drm/i915/gt: Split intel-gtt functions by arch"). The goal of that commit was to split the handlers for older hardware that depend on intel-gtt.ko so i915 can be built for non-x86 archs, after some more patches. Other archs do not need intel-gtt.ko. Main issue with the previous approach: it moved all the hooks, including the gen8, which is used by all platforms gen8 and newer. Re-do the split moving only the handlers for gen < 6, which are the only ones calling out to the separate module. While at it do some minor cleanups: - Rename the prefix s/gen5_/gmch_/ to be more accurate what platforms are covered by intel_ggtt_gmch.c - Remove dead code for gen12 out of needs_idle_maps() - Remove TODO comment leftover - Re-order if/else ladder in ggtt_probe_hw() to keep newest platforms first v2: Add minor cleanups (Matt Roper) Signed-off-by:
-
Lucas De Marchi authored
Exporting the symbols like intel_gtt_* creates some confusion inside i915 that has symbols named similarly. In an attempt to isolate platforms needing intel-gtt.ko, commit 7a5c9223 ("drm/i915/gt: Split intel-gtt functions by arch") moved way too much inside gt/intel_gt_gmch.c, even the functions that don't callout to this module. Rename the symbols to make the separation clear. Signed-off-by:
-
pengfuyuan authored
Fix spelling typo in comment. Reported-by:
k2ci <kernel-bot@kylinos.cn> Signed-off-by:
pengfuyuan <pengfuyuan@kylinos.cn> Signed-off-by:
-
Matt Roper authored
Let's replace the assortment of intel_gt_* and intel_uncore_* functions that operate on MCR registers with a cleaner set of interfaces: * intel_gt_mcr_read -- unicast read from specific instance * intel_gt_mcr_read_any[_fw] -- unicast read from any non-terminated instance * intel_gt_mcr_unicast_write -- unicast write to specific instance * intel_gt_mcr_multicast_write[_fw] -- multicast write to all instances We'll also replace the historic "slice" and "subslice" terminology with "group" and "instance" to match the documentation for more recent platforms; these days MCR steering applies to more types of replication than just slice/subslice. v2: - Reference the new kerneldoc from i915.rst. (Jani) - Tweak the wording of the documentation for a couple functions to clarify the difference between "_fw" and non-"_fw" forms. v3: - s/read/write/ to fix copy-paste mistake in a couple comments. (Harish) Signed-off-by:Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by:
Harish Chegondi <harish.chegondi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220615001019.1821989-3-matthew.d.roper@intel.com (cherry picked from commit 3fe6c7f5) Conflicts: drivers/gpu/drm/i915/gt/intel_engine_cs.c BUG=b:242077859 TEST=i915 driver loaded successfully Change-Id: I3e5c42dd906ca7834f5ef6283b9947679759e049 Signed-off-by:
-
Matt Roper authored
Handling of multicast/replicated registers is spread across intel_gt.c and intel_uncore.c today. As multicast handling and the related steering logic gets more complicated with the addition of new platforms and new rules it makes sense to centralize it all in one place. For now the existing functions have been moved to the new .c/.h as-is. Function renames and updates to operate in a more consistent manner will be done in subsequent patches. Signed-off-by:
-
Nirmoy Das authored
Determine lmem_size using ADDR_RANGE register so that lmem_setup() works on platform with small-bar as well. Signed-off-by:
Nirmoy Das <nirmoy.das@intel.com> Reviewed-by:
Matthew Auld <matthew.auld@intel.com> Signed-off-by:
-
Rob Barnes authored
Set TPM_FIRMWARE_POWER_MANAGED flag based on 'firmware-power-managed' ACPI DSD property. For the CR50 TPM, this flag defaults to true when the property is unset. When this flag is set to false, the CR50 TPM driver will always send a shutdown command whenever the system suspends. Signed-off-by:
Rob Barnes <robbarnes@google.com> Reviewed-by:
Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by:
Guenter Roeck <groeck@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/3937350 Reviewed-by:
Andrey Pronin <apronin@chromium.org>
-
AngeloGioacchino Del Regno authored
To allow this device to fill the kernel's entropy pool at boot, setup a default quality for the hwrng found in Cr50. After some testing with rngtest and dieharder it was, in short, discovered that the RNG produces fair quality randomness, giving around 99.93% successes in rngtest FIPS140-2. Notably, though, when testing with dieharder it was noticed that we get 3 WEAK results over 114, which isn't optimal, and also the p-values distribution wasn't uniform in all the cases, so a conservative quality value was chosen by applying an arbitrary penalty to the calculated values. For reference, this is how the values were calculated: The dieharder results were averaged, then normalized (0-1000) and re-averaged with the rngtest result (where the result was given a score of 99.93% of 1000, so 999.3), then aggregated together and averaged again. An arbitrary penalty of -100 was applied due to the retrieved value, which brings us finally to 700. Signed-off-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by:
-
Jes B. Klinke authored
Accept one additional numerical value of DID:VID for next generation Google TPM with new firmware, to be used in future Chromebooks. The TPM with the new firmware has the code name TI50, and is going to use the same interfaces. Signed-off-by:
Jes B. Klinke <jbk@chromium.org> Reviewed-by:
-
Linux Patches Robot authored
When removing the module we will get the following warning: [ 31.911505] i2c-core: driver [stdp2690-ge-b850v3-fw] unregistered [ 31.912484] general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN PTI [ 31.913338] KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] [ 31.915280] RIP: 0010:drm_bridge_remove+0x97/0x130 [ 31.921825] Call Trace: [ 31.922533] stdp4028_ge_b850v3_fw_remove+0x34/0x60 [megachips_stdpxxxx_ge_b850v3_fw] [ 31.923139] i2c_device_remove+0x181/0x1f0 The two bridges (stdp2690, stdp4028) do not probe at the same time, so the driver does not call ge_b850v3_resgiter() when probing, causing the driver to try to remove the object that has not been initialized. Fix this by checking whether both the bridges are probed. Fixes: 11632d4a ("drm/bridge: megachips: Ensure both bridges are probed before registration") Signed-off-by:
Zheyu Ma <zheyuma97@gmail.com> Signed-off-by:
Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220830073450.1897020-1-zheyuma97@gmail.com (cherry picked from commit 1ff67333) BUG=None TEST=None Signed-off-by:
Linux Patches Robot <linux-patches-robot@chromeos-missing-patches.google.com.iam.gserviceaccount.com> Change-Id: I1daad94a5f1a27c22043e62e7bf7486fecb83217 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/3937327 Reviewed-by:
-
Sergey Senozhatsky authored
We may end up in error cleanup before psys is initialized (GFP_ZERO allocation), so we have to check if psys is not NULL. UPSTREAM-TASK=b:149068439 UPSTREAM-TASK=b:149068672 BUG=none TEST=simulated ipu6 probing error on dedede Signed-off-by:
Sergey Senozhatsky <senozhatsky@chromium.org> Change-Id: I9cf3c2b27ae111034bc73343ec7427486804d5ae Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/3932653 Reviewed-by:
Ricardo Ribalda <ribalda@chromium.org>
-
Sergey Senozhatsky authored
All psys/isys init functions return ERR_PTR, so we need to use IS_ERR in conditionals. Additionally, we may goto out_ipu_bus_del_devices before isys/psys are initialized, so we need to also NULL check them, hence IS_ERR_OR_NULL(). UPSTREAM-TASK=b:149068439 UPSTREAM-TASK=b:149068672 BUG=none TEST=simulated allocation error on dedede Signed-off-by:
-
Sergey Senozhatsky authored
ipu_pci_probe() enters with device PM usage counter of 2: one from driver_probe_device()->pm_runtime_barrier() and one from pci_device_probe()->__pm_runtime_resume(). Then it drops it down to 0, while the device probing is not done yet and has a number of fail points. One such scenario is when FW mapping fails and ipu_pci_probe() hits the error out path, with PM counter adjusted: [ 29.815181] intel-ipu6 intel-ipu: Runtime PM usage count underflow! UPSTREAM-TASK=b:149068439 UPSTREAM-TASK=b:149068672 BUG=b:241824013 TEST=boot on redrix and dedede Signed-off-by:
-
Linux Patches Robot authored
Follow up the merge of address fields and drop the variable that became unused after the commit 9403f9a4 ("drm/msm/dpu: merge base_off with blk_off in struct dpu_hw_blk_reg_map"). Fixes: 9403f9a4 ("drm/msm/dpu: merge base_off with blk_off in struct dpu_hw_blk_reg_map") Signed-off-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by:
Stephen Boyd <swboyd@chromium.org> Reviewed-by:
Abhinav Kumar <quic_abhinavk@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/498736/ Link: https://lore.kernel.org/r/20220822172204.281045-1-dmitry.baryshkov@linaro.org Signed-off-by:
Rob Clark <robdclark@chromium.org> (cherry picked from commit 4bca8764) BUG=b:232883991, b:187576301 TEST=boot trogdor-arc-r Signed-off-by:
-
Nathan Chancellor authored
Clang warns: drivers/gpu/drm/msm/dsi/dsi_host.c:1903:14: error: variable 'device_node' is uninitialized when used here [-Werror,-Wuninitialized] of_node_put(device_node); ^~~~~~~~~~~ drivers/gpu/drm/msm/dsi/dsi_host.c:1870:44: note: initialize the variable 'device_node' to silence this warning struct device_node *endpoint, *device_node; ^ = NULL 1 error generated. device_node's assignment was removed but not all of its uses. Remove the call to of_node_put() and the variable declaration to clean up the warning. Fixes: 36246dd50225 ("drm/msm/dsi: switch to DRM_PANEL_BRIDGE") Link: https://github.com/ClangBuiltLinux/linux/issues/1700 Signed-off-by:Nathan Chancellor <nathan@kernel.org> Reviewed-by:
-
