Add compatible string and the include file for gcc clock
controller for SDM845.
Signed-off-by: Amit Nischal <anischal@codeaurora.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
The code is complicated because we want to check if the GDSC is enabled
or disabled based on different bits in different registers while the
GDSC hardware is slightly different across chips. Furthermore, we poll
the status of the enable or disable state by checking if the gdsc is
enabled or not, and then comparing that to if the gdsc is being enabled
or disabled. Let's push all that into one function, so we can ask if the
status matches what we want, either on or off. Then the call site can
just ask that question, and the logic to check that state can simply
return yes or no, and not 1 or 0 or 0 or 1 depending on if we're
enabling or disabling respectively.
Tested-by: Taniya Das <tdas@codeaurora.org>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
For some root clock generators, there could be child branches which are
controlled by an entity other than application processor subsystem. For
such RCGs, as per application processor subsystem clock driver, all of
its downstream clocks are disabled and RCG is in disabled state but in
reality downstream clocks can be left enabled before.
So in this scenario, when RCG is disabled as per clock driver's point of
view and when rate scaling request comes before downstream clock enable
request, then RCG fails to update its configuration because in reality
RCG is on and it expects its new source to already be in enable state but
in reality new source is off. In order to avoid having the RCG to go into
an invalid state, add support to update the CFG, M, N and D registers
during set_rate() without configuration update and defer the actual RCG
configuration update to be done during clk_enable() as at this point of
time, both its new parent and safe source will be already enabled and RCG
can safely switch to new parent.
During clk_disable() request, configure it to safe source as both its
parents, safe source and current parent will be enabled and RCG can
safely execute a switch.
Signed-off-by: Taniya Das <tdas@codeaurora.org>
Signed-off-by: Amit Nischal <anischal@codeaurora.org>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
We need to return here instead of setting up the freed sdev device as a
transport.
Fixes: 907b6d1491 ("firmware: arm_scmi: add per-protocol channels support using idr objects")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
The clk.rst is already in ReST format. So, move it to the
driver-api guide, where it belongs.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
The circular-buffers.txt is already in ReST format. So, move it to the
core-api guide, where it belongs.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
The cachetlb.txt is already in ReST format. So, move it to the
core-api guide, where it belongs.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
The bcache.txt is already in ReST format. So, move it to the
admin guide, where it belongs.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
A number of new docs were added, but they're currently not on
the index.rst from the session they're supposed to be, causing
Sphinx warnings.
Add them.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Pull libata fixes from Tejun Heo:
"An earlier commit to add reset control for embedded ahci controllers
affected some of the hardware specific drivers and got reverted for
now.
Other than that, just per-device workarounds and trivial changes"
* 'for-4.17-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata:
driver core: add __printf verification to __ata_ehi_pushv_desc
ata: fix spelling mistake: "directon" -> "direction"
libata: Apply NOLPM quirk for SanDisk SD7UB3Q*G1001 SSDs
libata: Apply NOLPM quirk for SAMSUNG MZMPC128HBFU-000MV SSD
ata: ahci: mvebu: override ahci_stop_engine for mvebu AHCI
libahci: Allow drivers to override stop_engine
Revert "ata: ahci-platform: add reset control support"
- Two major fixes for the Intel Cherryview and Sunrisepoint
pin controllers, adjusting numberspaces so that they do
get aligned with various messed-up numbers encoded into
the BIOS.
- A fix for the Meson driver GPIO pin range.
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJa8aWcAAoJEEEQszewGV1zjSoQAK1lSHCY5WX309bNxES+uEhF
YJs09sqNTS+6Y7ZFiLsq78akvNEJ299B1fcnWwc6m3JIBj6CbhBKIY5Olddt8WZU
92LtRWEZ02dZKVTdRpf3uuxgSyHhnftWDQKSwfp9asFJn4L8a93UgW7ipC43S3+o
yK52loDZ1qRVcICE6MFSCdHgVr9uWT+wk9pULzz9T/GN59Hixf+AS5r3dDZONK2c
bVF3wL/c5pTvw+glVCcUP1DtuBJL9jYMtDcHPeQq1vmJsW2jr5EuoTSTPXpUUY0w
taNA6s6kQSEmmxesOBg4/tbyoc6J15f9EIgOyQTs/falTQzjjvafDaKbsA8XXBJp
6n7vqYrTrEY3siMtY+BaXo0oihNlgda8lLt6ok+PzJLyTYpBlhoLdKJVw0LQcQOo
nuDpYubmbgUi1n4DvJfFL5fUWpRHASxwn3MfrgzTAn+vxL0fjFlM1PIV+yGmhaeC
XgZFY2q/SlUCcVsMOSD9/SqxkMCVXPaEKQt9XvZfHzhTJDSpQoT04XVVIbAuEVQM
OllBrGtccJSkU257ZDx86s4dECTTHIIN0TK+sFtsUk0kLGvwbZrYkdyArjRDsm9w
XwzFQcIrmTwqNnqlkk0KnwWVgkcnQo+EodYDVsex7AtwpdIIvmD//2xLg3ZsDthe
nYUSMyUfmHhsdZYt/FSP
=fTEB
-----END PGP SIGNATURE-----
Merge tag 'pinctrl-v4.17-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
Pull pin control fixes from Linus Walleij:
"Here are three pin control fixes.
The Intel fixes are the most serious and important things I had queued
since it affects a large portion of deployed Chromebooks.
- Two major fixes for the Intel Cherryview and Sunrisepoint pin
controllers, adjusting numberspaces so that they get aligned with
various messed-up numbers encoded into the BIOS.
- A fix for the Meson driver GPIO pin range"
* tag 'pinctrl-v4.17-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl:
pinctrl: sunrisepoint: Align GPIO number space with Windows
pinctrl: cherryview: Associate IRQ descriptors to irqdomain
pinctrl: meson-axg: fix the range of aobus bank
- Fix proper IRQ unmasking in the Aspeed driver.
- Do not free unrequested descriptors on the errorpath when
creating line handles from the userspace chardev
requested GPIO lines.
- Also fix the errorpath in the linehandle creation function.
- Fix the get/set multiple GPIO lines for a few of the
funky industrial GPIO cards on the ISA bus.
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJa8ZjfAAoJEEEQszewGV1zkdUP/29+sFVtGti/3G9Njg2RWV9l
dnmr+cyFeSS1YvG6MAsAPkWKp87MRPJoHDVOCqKPNUxCDXQODF1XFoGQfxTlmGdk
Q2B99c2lOJsCsEjJOm6rmctJfkJDMhhxwl9334w7WsopnPG/kr7rO6zwECvpxeVR
OpwZF8dLWpwC4+G7liAnh0Y0aVtO1E8k5aQg1pB8DUDARBmhaIOcN7sE6fezmQ7I
iAy4+psQWfzGguGdR328YAhxcD+SgQmThh9/nQ/e/kjwC9HyTasXbDTyjv7GtXsX
C9l4eUArnPLRwlM6VU3aNfWEjYjlwUZjElg5NXbZlcjDfmbXoCwsYtYI5S3yzAWr
8HgUcT55D3ZDLbJE2VRoHqeZxUq/kXMgsP47jVbzFCmr9tK1/geER4TkY6v/qoRs
gR+XWvxDvscG0dkjp0dRRuCo6HPANr2bsBED3atHs5hZhSjhJv+XZp8TuTmcKnaw
HenTFtP/0orPw2/KodWYsenB4kiAL6MHTZecD75cRZGb9hkCMdnJRnr9R+wexHBg
y1YQ0w0NbUQXJF7CqIRTkns5JUbPHCZEcdtPrpbdIV8GWYAOtEcdBwvI4j0f6Gn0
5acydVD0BfU/2fEfs+uS9n0Cv+9a39B6qN9gyIxIX+FPJfNYIG2Kdk74sp2veQyi
d7VYqR127VN66v8+aEbf
=8XsF
-----END PGP SIGNATURE-----
Merge tag 'gpio-v4.17-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio
Pull GPIO fixes from Linus Walleij:
"Sorry for lagging behind on sending the first batch of GPIO fixes for
this cycle. Just too busy conferencing and the weather was too nice.
Here it is anyway: some real important polishing on the error path
facing userspace (tagged for stable as well) and some normal driver
fixes.
- Fix proper IRQ unmasking in the Aspeed driver.
- Do not free unrequested descriptors on the errorpath when creating
line handles from the userspace chardev requested GPIO lines.
- Also fix the errorpath in the linehandle creation function.
- Fix the get/set multiple GPIO lines for a few of the funky
industrial GPIO cards on the ISA bus"
* tag 'gpio-v4.17-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio:
gpio: pcie-idio-24: Fix off-by-one error in get_multiple loop
gpio: pcie-idio-24: Fix port memory offset for get_multiple/set_multiple callbacks
gpio: pci-idio-16: Fix port memory offset for get_multiple callback
gpio: fix error path in lineevent_create
gpioib: do not free unrequested descriptors
gpio: fix aspeed_gpio unmask irq
The document describes userspace API and as such it belongs to
Documentation/admin-guide/mm
Signed-off-by: Mike Rapoport <rppt@linux.vnet.ibm.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
The document describes NUMA memory policy and as it is a part of the Linux
documentation it's obvious that this is Linux memory policy. Besides,
"Linux memory policy" may refer to other policies, e.g. memory hotplug
policy, and using term NUMA makes the documentation less ambiguous.
Signed-off-by: Mike Rapoport <rppt@linux.vnet.ibm.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Uses '!RWSEM_GENERIC_SPINLOCK' in place of 'Optimized asm/rwsem.h' as
Kconfig for 'rwsem-optimized': the new Kconfig expresses this feature
equivalently, while also enabling the script 'features-refresh.sh' to
operate on the corresponding arch support status file. Also refreshes
the status matrix by using the script 'features-refresh.sh'.
Suggested-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Andrea Parri <andrea.parri@amarulasolutions.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Commit 6077776b59 split 'HAVE_BPF_JIT' into cBPF and eBPF variant.
Adds arch support status files for the new variants, and removes the
status file corresponding to 'HAVE_BPT_JIT'. The new status matrices
were auto-generated using the script 'features-refresh.sh'.
Signed-off-by: Andrea Parri <andrea.parri@amarulasolutions.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Now that the script 'features-refresh.sh' is available, uses this script
to refresh all the arch-support.txt files in place.
Signed-off-by: Andrea Parri <andrea.parri@amarulasolutions.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Provides the script:
Documentation/features/scripts/features-refresh.sh
which operates on the arch-support.txt files and refreshes them in place.
This way [1],
"[...] we soft- decouple the refreshing of the entries from the
introduction of the features, while still making it all easy to
keep sync and to extend."
[1] http://lkml.kernel.org/r/20180328122211.GA25420@andrea
Suggested-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Andrea Parri <andrea.parri@amarulasolutions.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Make the description of the kernel command line option "blkdevparts"
a bit more flowing and readable.
Fix a few typos.
Add the optional <size> and <offset> suffixes.
Note that size can be "-" to indicate all of the remaining space.
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Cai Zhiyong <caizhiyong@huawei.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Update vfio_add_group_dev description to match the current API.
Signed-off-by: Dong Bo <dongbo4@huawei.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
This came up in discussions when reviewing drm patches.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
VM_PKEY_BITx are defined only if CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS
is enabled. Powerpc also needs these bits. Hence lets define the
VM_PKEY_BITx bits for any architecture that enables
CONFIG_ARCH_HAS_PKEYS.
Reviewed-by: Dave Hansen <dave.hansen@intel.com>
Signed-off-by: Ram Pai <linuxram@us.ibm.com>
Reviewed-by: Ingo Molnar <mingo@kernel.org>
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
-----BEGIN PGP SIGNATURE-----
iQFHBAABCgAxFiEENrCndlB/VnAEWuH5k9IU1zQoZfEFAlrxYywTHG1rbEBwZW5n
dXRyb25peC5kZQAKCRCT0hTXNChl8frFB/0REZC1xUNIZBMxfeIBn9wzyuRoF7S2
qiJ/JJ/jIITR4xzbabnSHzvXFOvvwyywEnBSvwNAPtY4RQIo4JoAApONe1GUzfmY
djFMERAf7sp5XjZhfdIenOQJ1bnIU87rZffgK3RbRfI3ciTgxb3HP9P5Ai2azmwR
zrUsqmdcNBFGOg7gZpE6tiC0dzrZ5gFqzJ9D0/pbq6hxJ01h+dWoDHe2NJplWI8J
nK60jXyRjlJLTffDnUxMFYYTXUoL7UwJdQWqtF6RE7GrPT4U+0L//O/RH0abC8bY
qplLICtBe0KvU7YbXmkLKtq9HDOfymjCegA/qX0rLO4OhnofqSijo+fX
=RtwO
-----END PGP SIGNATURE-----
Merge tag 'linux-can-fixes-for-4.17-20180508' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can
Marc Kleine-Budde says:
====================
pull-request: can 2018-05-08
this is a pull request for 7 patches for net/master.
The first patch is by Jakob Unterwurzacher and increases the severity of
bus-off messages in the generic CAN device infrastructure. The next two patches
are by Uwe Kleine-König and fix the endianess detection in the flexcan driver.
Jimmy Assarsson's patch for the kvaser driver corrects the stats counter for
dropped tx-messages. Geert Uytterhoeven provides one patch and Sergei Shtylyov
two patches for the rcan_canfd device tree binding description.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Stefan Schmidt says:
====================
pull-request: ieee802154 2018-05-08
An update from ieee802154 for your *net* tree.
Two fixes for the mcr20a driver, which was being added in the 4.17 merge window,
by Gustavo and myself.
The atusb driver got a change to GFP_KERNEL where no GFP_ATOMIC is needed by
Jia-Ju.
The last and most important fix is from Alex to get IPv6 reassembly working
again for the ieee802154 6lowpan adaptation. This got broken in 4.16 so please
queue this one also up for the 4.16 stable tree.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Michael Chan says:
====================
bnxt_en: Fixes for net-next.
This series includes a bug fix for a regression in firmware message polling
introduced recently on net-next. There are 3 additional minor fixes for
unsupported link speed checking, VF MAC address handling, and setting
PHY eeprom length.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
The current code already forwards the VF MAC address to the PF, except
in one case. If the VF driver gets a valid MAC address from the firmware
during probe time, it will not forward the MAC address to the PF,
incorrectly assuming that the PF already knows the MAC address. This
causes "ip link show" to show zero VF MAC addresses for this case.
This assumption is not correct. Newer firmware remembers the VF MAC
address last used by the VF and provides it to the VF driver during
probe. So we need to always forward the VF MAC address to the PF.
The forwarded MAC address may now be the PF assigned MAC address and so we
need to make sure we approve it for this case.
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
For SFP+ modules, 0xA2 page is available only when Diagnostic Monitoring
Type [Address A0h, Byte 92] is implemented. Extend bnxt_get_module_info(),
to read optical diagnostics support at offset 92(0x5c) and set eeprom_len
length to ETH_MODULE_SFF_8436_LEN (to exclude A2 page), if dianostics is
not supported.
Also in bnxt_get_module_info(), module id is read from offset 0x5e which
is not correct. It was working by accident, as offset was not effective
without setting enables flag in the firmware request. SFP module id is
present at location 0. Fix this by removing the offset and read it
from location 0.
Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Only non-NPAR PFs need to actively check and manage unsupported link
speeds. NPAR functions and VFs do not control the link speed and
should skip the unsupported speed detection logic, to avoid warning
messages from firmware rejecting the unsupported firmware calls.
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
A recent change to reduce delay granularity waiting for firmware
reponse has caused a regression. With a tighter delay loop,
the driver may see the beginning part of the response faster.
The original 5 usec delay to wait for the rest of the message
is not long enough and some messages are detected as invalid.
Increase the maximum wait time from 5 usec to 20 usec. Also, fix
the debug message that shows the total delay time for the response
when the message times out. With the new logic, the delay time
is not fixed per iteration of the loop, so we define a macro to
show the total delay time.
Fixes: 9751e8e714 ("bnxt_en: reduce timeout on initial HWRM calls")
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
During request submission, we call the engine->schedule() function so
that we may reorder the active requests as required for inheriting the
new request's priority. This may schedule several tasklets to run on the
local CPU, but we will need to schedule the tasklets again for the new
request. Delay all the local tasklets until the end, so that we only
have to process the queue just once.
v2: Beware PREEMPT_RCU, as then local_bh_disable() is then not a
superset of rcu_read_lock().
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180507135731.10587-2-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
When called from process context tasklet_schedule() defers itself to
ksoftirqd. From experience this may cause unacceptable latencies of over
200ms in executing the submission tasklet, our goal is to reprioritise
the HW execution queue and trigger HW preemption immediately, so disable
bh over the call to schedule and force the tasklet to run afterwards if
scheduled.
v2: Keep rcu_read_lock() around for PREEMPT_RCU
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180507135731.10587-1-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
As we flush each test and wait for idle before the next, also switch
back to the kernel context. This helps limit the amount of collateral
damage a test may cause by resetting to the default state each time (and
also helps clean up temporaries used by the test).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180508115312.12628-1-chris@chris-wilson.co.uk
Correct a trinity finding for the perf_event_open() system call with
a perf event attribute structure that uses a frequency but has the
sampling frequency set to zero. This causes a FP divide exception during
the sample rate initialization for the hardware sampling facility.
Fixes: 8c069ff4bd ("s390/perf: add support for the CPU-Measurement Sampling Facility")
Cc: stable@vger.kernel.org # 3.14+
Reviewed-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Hendrik Brueckner <brueckner@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Same EEPROM as on Koelsch, et al.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
The multiplication of 100000 * cfg80211_calculate_bitrate() is a 32 bit
operation and can overflow if cfg80211_calculate_bitrate is greater
than 42949. Although I don't believe this is occurring at present, it
would be safer to avoid the potential overflow by making the constant
100000 an ULL to ensure a 64 multiplication occurs.
Detected by CoverityScan, CID#1468643 ("Unintentional integer overflow")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Add the support for A83T.
A83T SoC has an additional register than A80 to handle CPU configurations:
R_CPUS_CFG. Information about the register comes from Allwinner's BSP
driver.
An important difference is the Power Off Gating register for clusters
which is BIT(4) in case of SUN9I-A80 and BIT(0) in case of SUN8I-A83T.
There is also a bit swap between sun8i-a83t and sun9i-a80 that must be
handled.
Signed-off-by: Mylène Josserand <mylene.josserand@bootlin.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
To prepare the support of sun8i-a83t, add a field in the smp_data
structure to know if we are on sun9i-a80 or sun8i-a83t.
Add also a global variable to retrieve which architecture we are
having.
Signed-off-by: Mylène Josserand <mylene.josserand@bootlin.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
To prepare the support for sun8i-a83t, rename the macro that handles
the power-off of clusters because it is different from sun9i-a80 to
sun8i-a83t.
The power off register for clusters are different from a80 and a83t.
Signed-off-by: Mylène Josserand <mylene.josserand@bootlin.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Reviewed-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Now that a common function is available for CNTVOFF's
initialization, let's convert shmobile-apmu code to use
this function.
Signed-off-by: Mylène Josserand <mylene.josserand@bootlin.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Fix `[drm:intel_enable_lvds] *ERROR* timed out waiting for panel to
power on` in kernel log at boot time.
Toshiba Satellite Z930 laptops needs between 1 and 2 seconds to power
on its screen during Intel i915 DRM initialization. This currently
results in a `[drm:intel_enable_lvds] *ERROR* timed out waiting for
panel to power on` message appearing in the kernel log during boot
time and when stopping the machine.
This change increases the timeout of the `intel_enable_lvds` function
from 1 to 5 seconds, letting enough time for the Satellite 930 LCD
screen to power on, and suppressing the error message from the kernel
log.
This patch has been successfully tested on Linux 4.14 running on a
Toshiba Satellite Z930.
[vsyrjala: bump the timeout from 2 to 5 seconds to match the DP
code and properly cover the max hw timeout of ~4 seconds, and
drop the comment about the specific machine since this is not
a particulary surprising issue, nor specific to that one machine]
Signed-off-by: Florent Flament <contact@florentflament.com>
Cc: stable@vger.kernel.org
Cc: Pavel Petrovic <ppetrovic@acm.org>
Cc: Sérgio M. Basto <sergio@serjux.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103414
References: https://bugzilla.kernel.org/show_bug.cgi?id=57591
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180419160700.19828-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
(cherry picked from commit 280b54ade5)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
During state readout we first read out the pipe src size, store
that information in the user mode h/vdisplay, but later on we overwrite
that with the actual crtc timings. That makes our read out crtc state
inconsistent with itself when the BIOS has enabled the panel fitter to
scale the pipe contents. Let's preserve the pipe src size based
information in the user mode to make things consistent again.
This fixes a problem introduced by commit a2936e3d9a ("drm/i915:
Use drm_mode_get_hv_timing() to populate plane clip rectangle")
where the inconsistent state is now leading the plane clipping code
to report a failure on account the plane dst coordinates not matching
the user mode size. Previously we did the plane clipping based on
the pipe src size instead and thus never noticed the inconsistency.
The failure manifests as a WARN:
[ 0.762117] [drm:intel_dump_pipe_config [i915]] requested mode:
[ 0.762142] [drm:drm_mode_debug_printmodeline [drm]] Modeline 0:"1366x768" 60 72143 1366 1414 1446 1526 768 771 777 784 0x40 0xa
...
[ 0.762327] [drm:intel_dump_pipe_config [i915]] port clock: 72143, pipe src size: 1024x768, pixel rate 72143
...
[ 0.764666] [drm:drm_atomic_helper_check_plane_state [drm_kms_helper]] Plane must cover entire CRTC
[ 0.764690] [drm:drm_rect_debug_print [drm]] dst: 1024x768+0+0
[ 0.764711] [drm:drm_rect_debug_print [drm]] clip: 1366x768+0+0
[ 0.764713] ------------[ cut here ]------------
[ 0.764714] Could not determine valid watermarks for inherited state
[ 0.764792] WARNING: CPU: 4 PID: 159 at drivers/gpu/drm/i915/intel_display.c:14584 intel_modeset_init+0x3ce/0x19d0 [i915]
...
Cc: FadeMind <fademind@gmail.com>
Cc: Dave Jones <davej@codemonkey.org.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reported-by: FadeMind <fademind@gmail.com>
Reported-by: Dave Jones <davej@codemonkey.org.uk>
Tested-by: Dave Jones <davej@codemonkey.org.uk>
References: https://lists.freedesktop.org/archives/intel-gfx/2018-April/163186.html
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105992
Fixes: a2936e3d9a ("drm/i915: Use drm_mode_get_hv_timing() to populate plane clip rectangle")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180426163015.14232-1-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Larry Finger <Larry.Finger@lwfinger.net>
Tested-by: FadeMind <fademind@gmail.com>
(cherry picked from commit bd4cd03c81)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
On intel_dp_compute_config() we were calculating the needed vco
for eDP on gen9 and we stashing it in
intel_atomic_state.cdclk.logical.vco
However few moments later on intel_modeset_checks() we fully
replace entire intel_atomic_state.cdclk.logical with
dev_priv->cdclk.logical fully overwriting the logical desired
vco for eDP on gen9.
So, with wrong VCO value we end up with wrong desired cdclk, but
also it will raise a lot of WARNs: On gen9, when we read
CDCLK_CTL to verify if we configured properly the desired
frequency the CD Frequency Select bits [27:26] == 10b can mean
337.5 or 308.57 MHz depending on the VCO. So if we have wrong
VCO value stashed we will believe the frequency selection didn't
stick and start to raise WARNs of cdclk mismatch.
[ 42.857519] [drm:intel_dump_cdclk_state [i915]] Changing CDCLK to 308571 kHz, VCO 8640000 kHz, ref 24000 kHz, bypass 24000 kHz, voltage level 0
[ 42.897269] cdclk state doesn't match!
[ 42.901052] WARNING: CPU: 5 PID: 1116 at drivers/gpu/drm/i915/intel_cdclk.c:2084 intel_set_cdclk+0x5d/0x110 [i915]
[ 42.938004] RIP: 0010:intel_set_cdclk+0x5d/0x110 [i915]
[ 43.155253] WARNING: CPU: 5 PID: 1116 at drivers/gpu/drm/i915/intel_cdclk.c:2084 intel_set_cdclk+0x5d/0x110 [i915]
[ 43.170277] [drm:intel_dump_cdclk_state [i915]] [hw state] 337500 kHz, VCO 8100000 kHz, ref 24000 kHz, bypass 24000 kHz, voltage level 0
[ 43.182566] [drm:intel_dump_cdclk_state [i915]] [sw state] 308571 kHz, VCO 8640000 kHz, ref 24000 kHz, bypass 24000 kHz, voltage level 0
v2: Move the entire eDP's vco logical adjustment to inside
the skl_modeset_calc_cdclk as suggested by Ville.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Fixes: bb0f4aab0e ("drm/i915: Track full cdclk state for the logical and actual cdclk frequencies")
Cc: <stable@vger.kernel.org> # v4.12+
Link: https://patchwork.freedesktop.org/patch/msgid/20180502175255.5344-1-rodrigo.vivi@intel.com
(cherry picked from commit 3297234a05)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Add the initialization of CNTVOFF for sun8i-a83t.
For boot CPU, create a new machine that handles this
function's call in an "init_early" callback. We need to initialize
CNTVOFF before the arch timer's initialization otherwise, it will
not be taken into account and fails to boot correctly.
Because of that, this function can't be called in SMP's early_initcall
function which is called after timer's init.
For secondary CPUs, add this function into secondary_startup
assembly entry.
Signed-off-by: Mylène Josserand <mylene.josserand@bootlin.com>
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
The CNTVOFF register from arch timer is uninitialized.
It should be done by the bootloader but it is currently not the case,
even for boot CPU because this SoC is booting in secure mode.
It leads to an random offset value meaning that each CPU will have a
different time, which isn't working very well.
Add assembly code used for boot CPU and secondary CPU cores to make
sure that the CNTVOFF register is initialized. Because this code can
be used by different platforms, add this assembly file in ARM's common
folder.
Signed-off-by: Mylène Josserand <mylene.josserand@bootlin.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
