Used wrong pp interface, the original interface is
exposed by dpm on SI and paritial CI.
Pointed out by Francis David <david.francis@amd.com>
v2: dal only need to set min_dcefclk and min_fclk to smu.
so use display_clock_voltage_request interface,
instand of update all display configuration.
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
void *entry[];
};
instance = devm_kzalloc(dev, sizeof(struct foo) + sizeof(void *) * count, GFP_KERNEL);
Instead of leaving these open-coded and prone to type mistakes, we can
now use the new struct_size() helper:
instance = devm_kzalloc(dev, struct_size(instance, entry, count), GFP_KERNEL);
This issue was detected with the help of Coccinelle.
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180824010521.GA25451@embeddedor.com
Commit cafa0010cd ("Raise the minimum required gcc version to 4.6")
recently exposed a brittle part of the build for supporting non-gcc
compilers.
Both Clang and ICC define __GNUC__, __GNUC_MINOR__, and
__GNUC_PATCHLEVEL__ for quick compatibility with code bases that haven't
added compiler specific checks for __clang__ or __INTEL_COMPILER.
This is brittle, as they happened to get compatibility by posing as a
certain version of GCC. This broke when upgrading the minimal version
of GCC required to build the kernel, to a version above what ICC and
Clang claim to be.
Rather than always including compiler-gcc.h then undefining or
redefining macros in compiler-intel.h or compiler-clang.h, let's
separate out the compiler specific macro definitions into mutually
exclusive headers, do more proper compiler detection, and keep shared
definitions in compiler_types.h.
Fixes: cafa0010cd ("Raise the minimum required gcc version to 4.6")
Reported-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Suggested-by: Eli Friedman <efriedma@codeaurora.org>
Suggested-by: Joe Perches <joe@perches.com>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
SWDEV-146499: hang during multi vulkan process testing
cause:
the second frame's PREAMBLE_IB have clear-state
and LOAD actions, those actions ruin the pipeline
that is still doing process in the previous frame's
work-load IB.
fix:
need insert pipeline sync if have context switch for
SRIOV (because only SRIOV will report PREEMPTION flag
to UMD)
Signed-off-by: Monk Liu <Monk.Liu@amd.com>
Signed-off-by: Emily Deng <Emily.Deng@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This is used for handling future fences. Currently no driver use
these, and I think given the new timeline fence proposed by KHR it
would be better to have a more abstract interface for future fences.
Could be something simple like a struct dma_future_fence plus a
function to add a callback or wait for the fence to materialize.
Then syncobj (and anything else really) could grow new functions to
expose these two drivers. Normal dma_fence would then keep the nice
guarantee that they will always signal (and through ordering, be
deadlock free). dma_future_fence would then be the tricky one.
This also fixes sphinx complaining about the kerneldoc.
Cc: Jason Ekstrand <jason@jlekstrand.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180822092905.19884-1-daniel.vetter@ffwll.ch
There are several blockable mmu notifiers which might sleep in
mmu_notifier_invalidate_range_start and that is a problem for the
oom_reaper because it needs to guarantee a forward progress so it cannot
depend on any sleepable locks.
Currently we simply back off and mark an oom victim with blockable mmu
notifiers as done after a short sleep. That can result in selecting a new
oom victim prematurely because the previous one still hasn't torn its
memory down yet.
We can do much better though. Even if mmu notifiers use sleepable locks
there is no reason to automatically assume those locks are held. Moreover
majority of notifiers only care about a portion of the address space and
there is absolutely zero reason to fail when we are unmapping an unrelated
range. Many notifiers do really block and wait for HW which is harder to
handle and we have to bail out though.
This patch handles the low hanging fruit.
__mmu_notifier_invalidate_range_start gets a blockable flag and callbacks
are not allowed to sleep if the flag is set to false. This is achieved by
using trylock instead of the sleepable lock for most callbacks and
continue as long as we do not block down the call chain.
I think we can improve that even further because there is a common pattern
to do a range lookup first and then do something about that. The first
part can be done without a sleeping lock in most cases AFAICS.
The oom_reaper end then simply retries if there is at least one notifier
which couldn't make any progress in !blockable mode. A retry loop is
already implemented to wait for the mmap_sem and this is basically the
same thing.
The simplest way for driver developers to test this code path is to wrap
userspace code which uses these notifiers into a memcg and set the hard
limit to hit the oom. This can be done e.g. after the test faults in all
the mmu notifier managed memory and set the hard limit to something really
small. Then we are looking for a proper process tear down.
[akpm@linux-foundation.org: coding style fixes]
[akpm@linux-foundation.org: minor code simplification]
Link: http://lkml.kernel.org/r/20180716115058.5559-1-mhocko@kernel.org
Signed-off-by: Michal Hocko <mhocko@suse.com>
Acked-by: Christian König <christian.koenig@amd.com> # AMD notifiers
Acked-by: Leon Romanovsky <leonro@mellanox.com> # mlx and umem_odp
Reported-by: David Rientjes <rientjes@google.com>
Cc: "David (ChunMing) Zhou" <David1.Zhou@amd.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Doug Ledford <dledford@redhat.com>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Mike Marciniszyn <mike.marciniszyn@intel.com>
Cc: Dennis Dalessandro <dennis.dalessandro@intel.com>
Cc: Sudeep Dutt <sudeep.dutt@intel.com>
Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
Cc: Dimitri Sivanich <sivanich@sgi.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: "Jérôme Glisse" <jglisse@redhat.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Felix Kuehling <felix.kuehling@amd.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Reorder allocation to avoid an awkward lock/unlock/lock sequence.
Simpler code due to being able to use ida_alloc_max(), even if we can't
eliminate the driver's spinlock.
Signed-off-by: Matthew Wilcox <willy@infradead.org>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
DCN1 contains code that utilizes fp math. When
CONFIG_KCOV_INSTRUMENT_ALL and CONFIG_KCOV_ENABLE_COMPARISONS are
enabled, build errors are found. See this earlier patch for details:
https://lists.freedesktop.org/archives/dri-devel/2018-August/186131.html
As a short term solution, disable CONFIG_DRM_AMD_DC_DCN1_0 when
KCOV_INSTRUMENT_ALL and KCOV_ENABLE_COMPARISONS are enabled. In
addition, make it a fully derived config, taking into account
CONFIG_X86.
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Leo (Sunpeng) Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Fix quite a number of bugs here. Unfortunately only compile tested.
v2: fix copy&paste error
v3: fix 80 chars issue in comment
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Repeat enable dpm under pass-through because there is no actually
hardware-fini and real power-off when guest vm shutdown or reboot.
Otherwise, under pass-through it will be failed to populate populate
and upload SCLK MCLK DPM levels due to zero of pcie_speed_table.count.
Signed-off-by: Yintian Tao <yttao@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
there is no need to access register such as mmSMC_IND_INDEX_11
and mmSMC_IND_DATA_11 through KIQ because they are VF-copy.
Signed-off-by: Yintian Tao <yttao@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Do not retrain link settings if lane count and link rate are both
unknown. Causes driver to be stuck reading VBIOS register after
removing emulated connection.
Signed-off-by: Samson Tam <Samson.Tam@amd.com>
Reviewed-by: Anthony Koo <Anthony.Koo@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Pull MFD updates from Lee Jones:
"New Drivers:
- Add Cirrus Logic Madera Codec (CS47L35, CS47L85 and CS47L90/91) driver
- Add ChromeOS EC CEC driver
- Add ROHM BD71837 PMIC driver
New Device Support:
- Add support for Dialog Semi DA9063L PMIC variant to DA9063
- Add support for Intel Ice Lake to Intel-PLSS-PCI
- Add support for X-Powers AXP806 to AXP20x
New Functionality:
- Add support for USB Charging to the ChromeOS Embedded Controller
- Add support for HDMI CEC to the ChromeOS Embedded Controller
- Add support for HDMI CEC to Intel HDMI
- Add support for accessory detection to Madera devices
- Allow individual pins to be configured via DT' wlf,csnaddr-pd
- Provide legacy platform specific EEPROM/Watchdog commands; rave-sp
Fix-upsL
- Trivial renaming/spelling fixes; cros_ec, da9063-*
- Convert to Managed Resources (devm_*); da9063-*, ti_am335x_tscadc
- Transition to helper macros/functions; da9063-*
- Constify; kempld-core
- Improve error path/messages; wm8994-core
- Disable IRQs locally instead of relying on USB subsystem; dln2
- Remove unused code; rave-sp
- New exports; sec-core
Bug Fixes:
- Fix possible false I2C transaction error; arizona-core
- Fix declared memory area size; hi655x-pmic
- Fix checksum type; rave-sp
- Fix incorrect default serial port configuration: rave-sp
- Fix incorrect coherent DMA mask for sub-devices; sm501"
* tag 'mfd-next-4.19' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd: (60 commits)
mfd: madera: Add register definitions for accessory detect
mfd: sm501: Set coherent_dma_mask when creating subdevices
mfd: bd71837: Devicetree bindings for ROHM BD71837 PMIC
mfd: bd71837: Core driver for ROHM BD71837 PMIC
media: platform: cros-ec-cec: Fix dependency on MFD_CROS_EC
mfd: sec-core: Export OF module alias table
mfd: as3722: Disable auto-power-on when AC OK
mfd: axp20x: Support AXP806 in I2C mode
mfd: axp20x: Add self-working mode support for AXP806
dt-bindings: mfd: axp20x: Add "self-working" mode for AXP806
mfd: wm8994: Allow to configure CS/ADDR Pulldown from dts
mfd: wm8994: Allow to configure Speaker Mode Pullup from dts
mfd: rave-sp: Emulate CMD_GET_STATUS on device that don't support it
mfd: rave-sp: Add legacy watchdog ping command translation
mfd: rave-sp: Add legacy EEPROM access command translation
mfd: rave-sp: Initialize flow control and parity of the port
mfd: rave-sp: Fix incorrectly specified checksum type
mfd: rave-sp: Remove unused defines
mfd: hi655x: Fix regmap area declared size for hi655x
mfd: ti_am335x_tscadc: Fix struct clk memory leak
...
PLLs are the source clocks for the DDIs so in order to determine the
ddi clock we need to check the PLL configuration.
For MG PHy Ports (C - F), depending on whether it is a TBT PLL or MG
PLL the link lock can be obtained from the the PLL divisors based on
the specification.
v2 (from Paulo):
* Make the algorithm look more like what's in the spec, also document
where we differ form the spec and why.
* Make the code a little more consistent with our coding style.
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180817215209.29133-2-paulo.r.zanoni@intel.com
The register value of Divider Ratio for high speed divider
(hsdiv_ratio) in MG_CLKTOP2_HSCLKCTL_PORT register is not same as the
actual numerical value of the divider. So this patch implements
separate divider value defines for that field.
icl_mg_pll_find_divisors() can use these defines instead of magic
register values.
The new defines are going to be used in the next patch.
v2 (from Paulo):
* Rebase.
* Make it look a little more like the rest of our code.
v3 (from Paulo):
* Make hsdiv u32 now that it's a bit field (José).
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Suggested-by: James Ausmus <james.ausmus@intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180817215209.29133-1-paulo.r.zanoni@intel.com
For multi-planar formats, while calculating offsets in planes with index greater than 0
(ie second plane, third plane, etc), one needs to divide (src_x * cpp) with horizontal
chroma subsampling factor and (src_y * pitch) with vertical chroma subsampling factor.
The reason being that the planes contain subsampled (ie reduced) data (by a factor of 2) and thus
while calculating the byte position coresponding to the x and y co-ordinates, one needs to
divide it with the sampling factor.
Signed-off-by: Ayan Kumar halder <ayan.halder@arm.com>
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
Link: https://patchwork.kernel.org/patch/10569263/
After
commit 2cd9a689e9 ("drm/i915: Refactor intel_display_set_init_power() logic")
it makes more sense to check the power domain/well refcounts after
enabling the power domains functionality. Before that it's guaranteed
that most power wells (in the INIT domain) will have a reference held,
so not an interesting state.
While at it also add the check after the init_hw/fini_hw, disable and
suspend/resume steps. Make the test optional on a Kconfig option since
it may add substantial overhead: on VLV/CHV the corresponding PUNIT reg
access for each power well may take up to 20ms.
v2:
- Add the state check to more spots. (Chris)
v3:
- During suspend check the state before deiniting display core.
Afterwards DC states are disabled (and so the dc_off power well is
enabled) even though we don't hold a reference on it.
- Do the test conditionally based on a new Kconfig option. (Chris)
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[Add DRM_I915_DEBUG_RUNTIME_PM to welcome messages]
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180817145837.26592-1-imre.deak@intel.com
Pull char/misc driver updates from Greg KH:
"Here is the bit set of char/misc drivers for 4.19-rc1
There is a lot here, much more than normal, seems like everyone is
writing new driver subsystems these days... Anyway, major things here
are:
- new FSI driver subsystem, yet-another-powerpc low-level hardware
bus
- gnss, finally an in-kernel GPS subsystem to try to tame all of the
crazy out-of-tree drivers that have been floating around for years,
combined with some really hacky userspace implementations. This is
only for GNSS receivers, but you have to start somewhere, and this
is great to see.
Other than that, there are new slimbus drivers, new coresight drivers,
new fpga drivers, and loads of DT bindings for all of these and
existing drivers.
All of these have been in linux-next for a while with no reported
issues"
* tag 'char-misc-4.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (255 commits)
android: binder: Rate-limit debug and userspace triggered err msgs
fsi: sbefifo: Bump max command length
fsi: scom: Fix NULL dereference
misc: mic: SCIF Fix scif_get_new_port() error handling
misc: cxl: changed asterisk position
genwqe: card_base: Use true and false for boolean values
misc: eeprom: assignment outside the if statement
uio: potential double frees if __uio_register_device() fails
eeprom: idt_89hpesx: clean up an error pointer vs NULL inconsistency
misc: ti-st: Fix memory leak in the error path of probe()
android: binder: Show extra_buffers_size in trace
firmware: vpd: Fix section enabled flag on vpd_section_destroy
platform: goldfish: Retire pdev_bus
goldfish: Use dedicated macros instead of manual bit shifting
goldfish: Add missing includes to goldfish.h
mux: adgs1408: new driver for Analog Devices ADGS1408/1409 mux
dt-bindings: mux: add adi,adgs1408
Drivers: hv: vmbus: Cleanup synic memory free path
Drivers: hv: vmbus: Remove use of slow_virt_to_phys()
Drivers: hv: vmbus: Reset the channel callback in vmbus_onoffer_rescind()
...
