Commit graph

932,869 commits

Author SHA1 Message Date
Mao Wenan
767637416e cfg80211: pmsr: use eth_broadcast_addr() to assign broadcast address
This patch is to use eth_broadcast_addr() to assign broadcast address
insetad of memset().

Signed-off-by: Mao Wenan <maowenan@huawei.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-02-22 13:34:30 +01:00
Toke Høiland-Jørgensen
5c14a4d05f mac80211: Change default tx_sk_pacing_shift to 7
When we did the original tests for the optimal value of sk_pacing_shift, we
came up with 6 ms of buffering as the default. Sadly, 6 is not a power of
two, so when picking the shift value I erred on the size of less buffering
and picked 4 ms instead of 8. This was probably wrong; those 2 ms of extra
buffering makes a larger difference than I thought.

So, change the default pacing shift to 7, which corresponds to 8 ms of
buffering. The point of diminishing returns really kicks in after 8 ms, and
so having this as a default should cut down on the need for extensive
per-device testing and overrides needed in the drivers.

Cc: stable@vger.kernel.org
Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-02-22 13:32:55 +01:00
Li RongQing
1740771524 mac80211_hwsim: propagate genlmsg_reply return code
genlmsg_reply can fail, so propagate its return code

Signed-off-by: Li RongQing <lirongqing@baidu.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-02-22 13:27:22 +01:00
Christophe Leroy
e66c3209c7 powerpc: Move page table dump files in a dedicated subdirectory
This patch moves the files related to page table dump in a
dedicated subdirectory.

The purpose is to clean a bit arch/powerpc/mm by regrouping
multiple files handling a dedicated function.

Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
[mpe: Shorten the file names while we're at it]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2019-02-22 22:29:22 +11:00
Chris Wilson
07c100b187 drm/i915/guc: Flush the residual log capture irq on disabling
As we disable the log capture events, flush any residual interrupt
before we flush and disable the worker.

v2: Mika pointed out that it wasn't the worker re-queueing itself, but a
rogue irq.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109716
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/20190221163833.21393-1-chris@chris-wilson.co.uk
2019-02-22 11:25:32 +00:00
Lucas Stach
a0ea4ffff2 drm/imx: only send commit done event when all state has been applied
Currently there is a small race window where we could manage to arm the
vblank event from atomic flush, but programming the hardware was too close
to the frame end, so the hardware will only apply the current state on the
next vblank. In this case we will send out the commit done event too early
causing userspace to reuse framebuffes that are still in use.

Instead of using the event arming mechnism, just remember the pending event
and send it from the vblank IRQ handler, once we are sure that all state
has been applied successfully.

Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
[p.zabel@pengutronix.de: inverted logic: done -> pending, added back
 spinlock in atomic_flush, commit message typo fix]
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2019-02-22 12:17:58 +01:00
Philipp Zabel
f6019702d9 drm/imx: allow building under COMPILE_TEST
Allow to compile-test imx-drm on other platforms.

Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
2019-02-22 12:17:58 +01:00
Philipp Zabel
2acef9c333 drm/imx: imx-tve: depend on COMMON_CLK
Since the TVE provides a clock to the DI, the driver can only be
compiled if the common clock framework is enabled. With the COMMON_CLK
dependency in place, it will be possible to allow building the other
parts of imx-drm under COMPILE_TEST on architectures that do not select
the common clock framework.

Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
2019-02-22 12:17:58 +01:00
Philipp Zabel
74a3dba26c drm/imx: ipuv3-plane: add zpos property
Add a zpos property to planes. Call drm_atomic_helper_check() instead of
calling drm_atomic_helper_check_modeset() and drm_atomic_check_planes()
manually. This effectively adds a call to drm_atomic_normalize_zpos()
before checking planes. Reorder atomic update to allow changing plane
zpos without modeset.

Note that the initial zpos is set in ipu_plane_state_reset(). The
initial value set in ipu_plane_init() is just for show. The zpos
parameter of drm_plane_create_zpos_property() is ignored because
the newly created plane do not have state yet.

Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Tested-by: Marius Vlad <marius.vlad@collabora.com>
2019-02-22 12:17:54 +01:00
Lucas Stach
70e8a0c71e drm/imx: ipuv3-plane: add function to query atomic update status
This function allows upper layer to check if a requested atomic update
to the plane has been applied or is still pending.

Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
[p.zabel@pengutronix.de: inverted logic: done -> pending]
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2019-02-22 11:58:45 +01:00
Lucas Stach
4bfbd561fc gpu: ipu-v3: prg: add function to get channel configure status
This allows channels using the PRG to check if a requested configuration
update has been applied or is still pending.

Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
[p.zabel@pengutronix.de: inverted logic: done -> pending]
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2019-02-22 11:58:45 +01:00
Lucas Stach
0a29b1abaf gpu: ipu-v3: pre: add double buffer status readback
This allows the upper layers to check if a double buffer update has
been applied by the PRE or is still pending.

Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
[p.zabel@pengutronix.de: inverted logic: done -> pending]
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2019-02-22 11:58:45 +01:00
Thomas Petazzoni
33776d0596 PCI: pci-bridge-emul: Extend pci_bridge_emul_init() with flags
Depending on the capabilities of the PCI controller/platform, the
PCI-to-PCI bridge emulation behavior might need to be different. For
example, on platforms that use the pci-mvebu code, we currently don't
support prefetchable memory BARs, so the corresponding fields in the
PCI-to-PCI bridge configuration space should be read-only.

To implement this, extend pci_bridge_emul_init() to take a "flags"
argument, with currently one flag supported:

PCI_BRIDGE_EMUL_NO_PREFETCHABLE_BAR

that will make the prefetchable memory base and limit registers
read-only.

The pci-mvebu and pci-aardvark drivers are updated accordingly.

Fixes: 1f08673eef ("PCI: mvebu: Convert to PCI emulated bridge config space")
Reported-by: Luís Mendes <luis.p.mendes@gmail.com>
Reported-by: Leigh Brown <leigh@solinno.co.uk>
Tested-by: Leigh Brown <leigh@solinno.co.uk>
Tested-by: Luis Mendes <luis.p.mendes@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: stable@vger.kernel.org
Cc: Luís Mendes <luis.p.mendes@gmail.com>
Cc: Leigh Brown <leigh@solinno.co.uk>
2019-02-22 10:51:14 +00:00
Thomas Petazzoni
59f81c35e0 PCI: pci-bridge-emul: Create per-bridge copy of register behavior
The behavior of the different registers of the PCI-to-PCI bridge is
currently encoded in two global arrays, shared by all instances of
PCI-to-PCI bridge emulation.

However, we will need to tweak the behavior on a per-bridge basis, to
accommodate for different capabilities of the platforms where this
code is used. In preparation for this, create a per-bridge copy of the
register behavior arrays, so that they can later be tweaked on a
per-bridge basis.

Fixes: 1f08673eef ("PCI: mvebu: Convert to PCI emulated bridge config space")
Reported-by: Luís Mendes <luis.p.mendes@gmail.com>
Reported-by: Leigh Brown <leigh@solinno.co.uk>
Tested-by: Leigh Brown <leigh@solinno.co.uk>
Tested-by: Luis Mendes <luis.p.mendes@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: stable@vger.kernel.org
Cc: Luís Mendes <luis.p.mendes@gmail.com>
Cc: Leigh Brown <leigh@solinno.co.uk>
2019-02-22 10:47:30 +00:00
Christian Borntraeger
11ba5961a2 KVM: s390: add debug logging for cpu model subfunctions
As userspace can now get/set the subfunctions we want to trace those.
This will allow to also check QEMUs cpu model vs. what the real
hardware provides.

Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Janosch Frank <frankja@linux.vnet.ibm.com>
2019-02-22 11:04:35 +01:00
Christian Borntraeger
346fa2f891 KVM: s390: implement subfunction processor calls
While we will not implement interception for query functions yet, we can
and should disable functions that have a control bit based on the given
CPU model.

Let us start with enabling the subfunction interface.

Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Janosch Frank <frankja@linux.vnet.ibm.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
2019-02-22 11:04:35 +01:00
Dave Martin
c88b093693 arm64: KVM: Fix architecturally invalid reset value for FPEXC32_EL2
Due to what looks like a typo dating back to the original addition
of FPEXC32_EL2 handling, KVM currently initialises this register to
an architecturally invalid value.

As a result, the VECITR field (RES1) in bits [10:8] is initialised
with 0, and the two reserved (RES0) bits [6:5] are initialised with
1.  (In the Common VFP Subarchitecture as specified by ARMv7-A,
these two bits were IMP DEF.  ARMv8-A removes them.)

This patch changes the reset value from 0x70 to 0x700, which
reflects the architectural constraints and is presumably what was
originally intended.

Cc: <stable@vger.kernel.org> # 4.12.x-
Cc: Christoffer Dall <christoffer.dall@arm.com>
Fixes: 62a89c4495 ("arm64: KVM: 32bit handling of coprocessor traps")
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2019-02-22 09:59:20 +00:00
Sameer Pujar
c0bde003a0 ALSA: hda/tegra: sound card name from device tree
A platform can have multiple sound cards for different audio paths.
Following is the print seen duirng device boot for jetson-xavier,
  ALSA device list:
    #0: nvidia,p2972-0000 at 0x3518000 irq 17
By looking at above, it is not very clear if the sound card is for
HDA. It becomes confusing when platform has registered multiple cards,
and platform model name is used for card.

This patch uses "nvidia,model" property mentioned in hda device tree
to get the card name. Since property is optional, legacy boards will
continue to use "tegra-hda". Custom name can be passed wherever needed.
This naming convention is conistent with the way sound cards are named
in general.

Signed-off-by: Sameer Pujar <spujar@nvidia.com>
Reviewed-by: Jonathan Hunter <jonathanh@nvidia.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-02-22 10:46:43 +01:00
Sameer Pujar
11ce430830 arm64: tegra: custom name for hda sound card
"nvidia,model" property is added to pass custom name for hda sound card.
This is parsed in hda driver and used for card name. This aligns with the
way with which sound cards are named in general.

This patch populates above for jetson-tx1, jetson-tx2 and jetson-xavier.

Signed-off-by: Sameer Pujar <spujar@nvidia.com>
Reviewed-by: Jonathan Hunter <jonathanh@nvidia.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-02-22 10:46:37 +01:00
Sameer Pujar
a0d183c329 ALSA: hda/tegra: property for card name
An optional property "nvidia,model" is introduced for hda to pass custom
name for the sound card. The suffix "-hda" in the name passed is useful
to distinguish between multiple cards available for a platform.
When the property is not specified, default name("tegra-hda") mentioned
in hda driver is used. This property can be added in platform specific
file of the board and card name can relate to the board in use.

Signed-off-by: Sameer Pujar <spujar@nvidia.com>
Reviewed-by: Jonathan Hunter <jonathanh@nvidia.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-02-22 10:46:31 +01:00
Shaokun Zhang
7f5d9c1bc0 KVM: arm/arm64: Remove unused timer variable
The 'timer' local variable became unused after commit bee038a674
("KVM: arm/arm64: Rework the timer code to use a timer_map").
Remove it to avoid [-Wunused-but-set-variable] warning.

Cc: Christoffer Dall <christoffer.dall@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Suzuki K Pouloze <suzuki.poulose@arm.com>
Reviewed-by: Julien Thierry <julien.thierry@arm.com>
Signed-off-by: Shaokun Zhang <zhangshaokun@hisilicon.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2019-02-22 09:41:52 +00:00
Aisheng Dong
28528fca49 irqchip/imx-irqsteer: Add multi output interrupts support
One irqsteer channel can support up to 8 output interrupts.

Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: Shawn Guo <shawnguo@kernel.org>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2019-02-22 09:23:46 +00:00
Aisheng Dong
deb904e45b irqchip/imx-irqsteer: Change to use reg_num instead of irq_group
One group can manage 64 interrupts by using two registers (e.g. STATUS/SET).
However, the integrated irqsteer may support only 32 interrupts which
needs only one register in a group. But the current driver assume there's
a mininum of two registers in a group which result in a wrong register map
for 32 interrupts per channel irqsteer. Let's use the reg_num caculated by
interrupts per channel instead of irq_group to cover this case.

Cc: Rob Herring <robh+dt@kernel.org>
Cc: Shawn Guo <shawnguo@kernel.org>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2019-02-22 09:22:56 +00:00
Aisheng Dong
e482c01dc7 dt-bindings: irq: imx-irqsteer: Add multi output interrupts support
One irqsteer channel can support up to 8 output interrupts.

Cc: Rob Herring <robh+dt@kernel.org>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: devicetree@vger.kernel.org
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2019-02-22 09:22:46 +00:00
Aisheng Dong
e12ba23254 dt-binding: irq: imx-irqsteer: Use irq number instead of group number
Not all 64 interrupts may be used in one group. e.g. most irqsteer in
imx8qxp and imx8qm subsystems supports only 32 interrupts.

As the IP integration parameters are Channel number and interrupts number,
let's use fsl,irqs-num to represents how many interrupts supported
by this irqsteer channel.

Note this will break the compatibility of old binding. As the original
fsl,irq-groups was born out of a misunderstanding of the HW config
options and we are not aware of any users of the current binding.
And the old binding was just published in recent months, so it's
worth to change now to avoid confusing in the future.

Cc: Rob Herring <robh+dt@kernel.org>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: devicetree@vger.kernel.org
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2019-02-22 09:22:22 +00:00
Rafael J. Wysocki
5b317cbf2b Merge branch 'pm-cpufreq-fixes'
* pm-cpufreq-fixes:
  cpufreq: scmi: Fix use-after-free in scmi_cpufreq_exit()
2019-02-22 10:17:11 +01:00
Bartosz Golaszewski
837ccda348 drivers: depend on HAS_IOMEM for devm_platform_ioremap_resource()
We only build devm_ioremap_resource() if HAS_IOMEM is selected, so this
dependency must cascade down to devm_platform_ioremap_resource().

Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-02-22 10:08:43 +01:00
Dmitry Torokhov
7bae0432a6 usb: core: add option of only authorizing internal devices
On Chrome OS we want to use USBguard to potentially limit access to USB
devices based on policy. We however to do not want to wait for userspace to
come up before initializing fixed USB devices to not regress our boot
times.

This patch adds option to instruct the kernel to only authorize devices
connected to the internal ports. Previously we could either authorize
all or none (or, by default, we'd only authorize wired devices).

The behavior is controlled via usbcore.authorized_default command line
option.

Signed-off-by: Dmitry Torokhov <dtor@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-22 09:27:55 +01:00
Pierre Morel
36360658eb s390: vfio_ap: link the vfio_ap devices to the vfio_ap bus subsystem
Libudev relies on having a subsystem link for non-root devices. To
avoid libudev (and potentially other userspace tools) choking on the
matrix device let us introduce a matrix bus and with it the matrix
bus subsytem. Also make the matrix device reside within the matrix
bus.

Doing this we remove the forced link from the matrix device to the
vfio_ap driver and the device_type we do not need anymore.

Since the associated matrix driver is not the vfio_ap driver any more,
we have to change the search for the devices on the vfio_ap driver in
the function vfio_ap_verify_queue_reserved.
Fixes: 1fde573413 ("s390: vfio-ap: base implementation of VFIO AP device driver")
Cc: stable@vger.kernel.org

Reported-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Reported-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Pierre Morel <pmorel@linux.ibm.com>
Tested-by: Christian Borntraeger <borntraeger@de.ibm.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Tony Krowiak <akrowiak@linux.ibm.com>
Acked-by: Halil Pasic <pasic@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2019-02-22 09:20:01 +01:00
Thomas Richter
47b7478583 s390/cpum_cf: Handle EBUSY return code from CPU counter facility reservation
Rservation of the CPU Measurement Counter facility may fail if
it is already in use by the cf_diag device driver.
This is indicated by a non zero return code (-EBUSY).
However this return code is ignored and the counter facility
may be used in parallel by different device drivers.

Handle the failing reservation and return an error to the
caller.

Signed-off-by: Thomas Richter <tmricht@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2019-02-22 09:19:58 +01:00
Thomas Richter
fb3a0b61e0 s390/cpum_cf: Add kernel message exaplanations
The CPU Measurement facility for counters and counter set
rework adds a few new kernel messages to the system log.
Add an explanation for some of these.

Signed-off-by: Thomas Richter <tmricht@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2019-02-22 09:19:57 +01:00
Thomas Richter
fe5908bccc s390/cpum_cf_diag: Add support for s390 counter facility diagnostic trace
Introduce a PMU device named cpum_cf_diag. It extracts the
values of all counters in all authorized counter sets and stores
them as event raw data. This is done with the STORE CPU COUNTER
MULTIPLE instruction to speed up access. All counter sets
fit into one buffer. The values of each counter are taken
when the event is started on the performance sub-system and when
the event is stopped.
This results in counter values available at the start and
at the end of the measurement time frame. The difference is
calculated for each counter. The differences of all
counters are then saved as event raw data in the perf.data
file.

The counter values are accompanied by the time stamps
when the counter set was started and when the counter set
was stopped. This data is part of a trailer entry which
describes the time frame, counter set version numbers,
CPU speed, and machine type for later analysis.

Signed-off-by: Thomas Richter <tmricht@linux.ibm.com>
Reviewed-by: Hendrik Brueckner <brueckner@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2019-02-22 09:19:56 +01:00
Hendrik Brueckner
86c0b75715 s390/cpum_cf: add ctr_stcctm() function
Introduce the ctr_stcctm() function as wrapper function to extract counters
from a particular counter set.  Note that the counter set is part of the
stcctm instruction opcode, few indirections are necessary to specify the
counter set as variable.

Signed-off-by: Hendrik Brueckner <brueckner@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2019-02-22 09:19:55 +01:00
Hendrik Brueckner
7f5ac1a022 s390/cpum_cf: move common functions into a separate file
Move common functions of the couter facility support into a separate
file.

Signed-off-by: Hendrik Brueckner <brueckner@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2019-02-22 09:19:55 +01:00
Hendrik Brueckner
869f4f98fa s390/cpum_cf: introduce kernel_cpumcf_avail() function
A preparation to move out common CPU-MF counter facility support
functions, first introduce a function that indicates whether the
support is ready to use.

Signed-off-by: Hendrik Brueckner <brueckner@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2019-02-22 09:19:54 +01:00
Hendrik Brueckner
346d034d7f s390/cpu_mf: replace stcctm5() with the stcctm() function
Remove the stcctm5() function to extract counters from the MT-diagnostic
counter set with the stcctm() function.  For readability, introduce an
enum to map the counter sets names to respective numbers for the stcctm
instruction.

Signed-off-by: Hendrik Brueckner <brueckner@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2019-02-22 09:19:53 +01:00
Hendrik Brueckner
778fb10ccc s390/cpu_mf: add store cpu counter multiple instruction support
Add support for the STORE CPU COUNTER MULTIPLE instruction to extract
a range of counters from a counter set.

An assembler macro is used to create the instruction opcode because
the counter set identifier is part of the instruction and, thus,
cannot be easily specified as parameter.

Signed-off-by: Hendrik Brueckner <brueckner@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2019-02-22 09:19:52 +01:00
Hendrik Brueckner
17bebcc68e s390/cpum_cf: Add minimal in-kernel interface for counter measurements
Introduce a minimal interface for doing counter measurements of small
units of work within the kernel.  Use the kernel_cpumcf_begin() function
start a measurement session and, later, stop it with kernel_cpumcf_end().

During the measreument session, you can enable and start/stop counter sets
by using ctr_set_* functions.  To make these changes effective use the
lcctl() function.  You can then use the ecctr() function to extract counters
from the different counter sets.
Please note that you have to check whether the counter sets to be enabled
are authorized.

Note that when a measurement session is active, other users cannot perform
counter measurements.  In such cases, kernel_cpumcf_begin() indicates this
with returning -EBUSY.  If the counter facility is not available,
kernel_cpumcf_begin() returns -ENODEV.

Note that this interface is restricted to the current CPU and, thus,
preemption must be turned off.

Example:

	u32 state, err;
	u64 cycles, insn;

	err = kernel_cpumcf_begin();
	if (err)
		goto out_busy;

	state = 0;
	ctr_set_enable(&state, CPUMF_CTR_SET_BASIC);
	ctr_set_start(&state, CPUMF_CTR_SET_BASIC);

	err = lcctl(state);
	if (err)
		goto ;

	/* ... do your work ... */

	ctr_set_stop(&state, CPUMF_CTR_SET_BASIC);
	err = lcctl(state);
	if (err)
		goto out;

	cycles = insn = 0;
	ecctr(0, &cycles);
	ecctr(1, &insn);

	/* ... */

	kernel_cpumcf_end();
out_busy:

Signed-off-by: Hendrik Brueckner <brueckner@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2019-02-22 09:19:50 +01:00
Hendrik Brueckner
26b8317f51 s390/cpum_cf: introduce kernel_cpumcf_alert() to obtain measurement alerts
During a __kernel_cpumcf_begin()/end() session, save measurement alerts
for the counter facility in the per-CPU cpu_cf_events variable.
Users can obtain and, optionally, clear the alerts by calling
kernel_cpumcf_alert() to specifically handle alerts.

Signed-off-by: Hendrik Brueckner <brueckner@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2019-02-22 09:19:50 +01:00
Hendrik Brueckner
f944bcdf5b s390/cpu_mf: move struct cpu_cf_events and per-CPU variable to header file
Make the struct cpu_cf_events and the respective per-CPU variable available
to in-kernel users.  Access to this per-CPU variable shall be done between
the calls to __kernel_cpumcf_begin() and __kernel_cpumcf_end().

Signed-off-by: Hendrik Brueckner <brueckner@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2019-02-22 09:19:49 +01:00
Hendrik Brueckner
f1c0b83173 s390/cpum_cf: rename per-CPU counter facility structure and variables
Rename the struct cpu_hw_events to cpu_cf_events and also the respective
per-CPU variable to make its name more clear.  No functional changes.

Signed-off-by: Hendrik Brueckner <brueckner@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2019-02-22 09:19:48 +01:00
Hendrik Brueckner
3d33345aa3 s390/cpum_cf: prepare for in-kernel counter measurements
Prepare the counter facility support to be used by other in-kernel
users.  The first step introduces the __kernel_cpumcf_begin() and
__kernel_cpumcf_end() functions to reserve the counter facility
for doing measurements and to release after the measurements are
done.

Signed-off-by: Hendrik Brueckner <brueckner@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2019-02-22 09:19:47 +01:00
Hendrik Brueckner
30e145f811 s390/cpum_cf: move counter set controls to a new header file
Move counter set specific controls and functions to the asm/cpu_mcf.h
header file containg all counter facility support definitions.  Also
adapt few variable names and header file includes.  No functional changes.

Signed-off-by: Hendrik Brueckner <brueckner@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2019-02-22 09:19:46 +01:00
Colin Xu
1e8b15a198 drm/i915/gvt: Add in context mmio 0x20D8 to gen9 mmio list
Depends on GEN family and I915_PARAM_HAS_CONTEXT_ISOLATION, Mesa driver
will decide whether constant buffer 0 address is relative or absolute,
and load GPU initial state by lri to context mmio INSTPM (GEN8)
or 0x20D8 (>=GEN9).
Mesa Commit fa8a764b62
("i965: Use absolute addressing for constant buffer 0 on Kernel 4.16+.")

INSTPM is already added to gen8_engine_mmio_list, but 0x20D8 is missed
in gen9_engine_mmio_list. From GVT point of view, different guest could
have different context so should switch those mmio accordingly.

v2: Update fixes commit ID.

Fixes: 1786571393 ("drm/i915/gvt: vGPU context switch")
Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Colin Xu <colin.xu@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-02-22 16:19:34 +08:00
Andy Shevchenko
a9443a6328 clk: x86: Move clk-lpss.h to platform_data/x86
clk-lpss.h is solely x86 related header. Move it to correct folder.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2019-02-22 00:14:31 -08:00
Katsuhiro Suzuki
d13501a2be clk: fractional-divider: check parent rate only if flag is set
Custom approximation of fractional-divider may not need parent clock
rate checking. For example Rockchip SoCs work fine using grand parent
clock rate even if target rate is greater than parent.

This patch checks parent clock rate only if CLK_SET_RATE_PARENT flag
is set.

For detailed example, clock tree of Rockchip I2S audio hardware.
  - Clock rate of CPLL is 1.2GHz, GPLL is 491.52MHz.
  - i2s1_div is integer divider can divide N (N is 1~128).
    Input clock is CPLL or GPLL. Initial divider value is N = 1.
    Ex) PLL = CPLL, N = 10, i2s1_div output rate is
      CPLL / 10 = 1.2GHz / 10 = 120MHz
  - i2s1_frac is fractional divider can divide input to x/y, x and
    y are 16bit integer.

CPLL --> | selector | ---> i2s1_div -+--> | selector | --> I2S1 MCLK
GPLL --> |          | ,--------------'    |          |
                      `--> i2s1_frac ---> |          |

Clock mux system try to choose suitable one from i2s1_div and
i2s1_frac for master clock (MCLK) of I2S1.

Bad scenario as follows:
  - Try to set MCLK to 8.192MHz (32kHz audio replay)
    Candidate setting is
    - i2s1_div: GPLL / 60 = 8.192MHz
    i2s1_div candidate is exactly same as target clock rate, so mux
    choose this clock source. i2s1_div output rate is changed
    491.52MHz -> 8.192MHz

  - After that try to set to 11.2896MHz (44.1kHz audio replay)
    Candidate settings are
    - i2s1_div : CPLL / 107 = 11.214945MHz
    - i2s1_frac: i2s1_div   = 8.192MHz
      This is because clk_fd_round_rate() thinks target rate
      (11.2896MHz) is higher than parent rate (i2s1_div = 8.192MHz)
      and returns parent clock rate.

Above is current upstreamed behavior. Clock mux system choose
i2s1_div, but this clock rate is not acceptable for I2S driver, so
users cannot replay audio.

Expected behavior is:
  - Try to set master clock to 11.2896MHz (44.1kHz audio replay)
    Candidate settings are
    - i2s1_div : CPLL / 107          = 11.214945MHz
    - i2s1_frac: i2s1_div * 147/6400 = 11.2896MHz
                 Change i2s1_div to GPLL / 1 = 491.52MHz at same
                 time.

If apply this commit, clk_fd_round_rate() calls custom approximate
function of Rockchip even if target rate is higher than parent.
Custom function changes both grand parent (i2s1_div) and parent
(i2s_frac) settings at same time. Clock mux system can choose
i2s1_frac and audio works fine.

Signed-off-by: Katsuhiro Suzuki <katsuhiro@katsuster.net>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
[sboyd@kernel.org: Make function into a macro instead]
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2019-02-22 00:11:47 -08:00
Jeffrey Hugo
760be6586f clk: qcom: Make common clk_hw registrations
Several clock controller drivers define a list of clk_hw devices, and then
register those devices in probe() before using common code to process the
rest of initialization.  Extend the common code to accept a list of clk_hw
devices to process, thus eliminating many duplicate implementations.

Signed-off-by: Jeffrey Hugo <jhugo@codeaurora.org>
Suggested-by: Stephen Boyd <sboyd@kernel.org>
Reviewed-by: Vinod Koul <vkoul@kernel.org>
Tested-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2019-02-22 00:06:57 -08:00
Manivannan Sadhasivam
ed6b4795ec clk: actions: Add clock driver for S500 SoC
Add common clock driver for Actions Semi S500 SoC.

Signed-off-by: Edgar Bernardi Righi <edgar.righi@lsitec.org.br>
[Mani: cleaned up the driver]
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2019-02-22 00:01:08 -08:00
Edgar Bernardi Righi
0c8c53e033 dt-bindings: clock: Add DT bindings for Actions Semi S500 CMU
Add devicetree bindings for Actions Semi S500 Clock Management Unit.

Signed-off-by: Edgar Bernardi Righi <edgar.righi@lsitec.org.br>
[Mani: Documented S500 CMU compatible]
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Reviewed-by: Rob Herring <robh@kernel.org>
[sboyd@kernel.org: Fix SPDX comment style in header file]
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2019-02-22 00:01:08 -08:00
Manivannan Sadhasivam
9831289f6f clk: actions: Add configurable PLL delay
S500 SoC requires configurable delay for different PLLs. Hence, add
a separate macro for declaring a PLL with configurable delay and also
modify the existing OWL_PLL_NO_PARENT macro to use default delay so
that no need to modify the existing S700/S900 drivers.

Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2019-02-21 23:58:12 -08:00