* [PATCH v3] drivers: psci: PSCI checker module
From: Paul E. McKenney @ 2016-10-26 18:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026173534.GC16248@red-moon>
On Wed, Oct 26, 2016 at 06:35:34PM +0100, Lorenzo Pieralisi wrote:
> On Wed, Oct 26, 2016 at 10:22:52AM -0700, Paul E. McKenney wrote:
> > On Wed, Oct 26, 2016 at 06:10:06PM +0100, Lorenzo Pieralisi wrote:
[ . . . ]
> > > Thanks a lot for your feedback, thoughts appreciated.
> >
> > Let me ask the question more directly.
> >
> > Why on earth are we trying to run these tests concurrently?
>
> We must prevent that, no question about that, that's why I started
> this discussion. It is not fine to enable this checker and the
> RCU/LOCK torture hotplug tests at the same time.
>
> > After all, if we just run one at a time in isolation, there is no
> > problem.
>
> Fine by me, it was to understand if the current assumptions we made
> are correct and they are definitely not. If we enable the PSCI checker
> we must disable the torture rcu/lock hotplug tests either statically or
> dynamically.
What rcutorture, locktorture, and rcuperf do is to invoke
torture_init_begin(), which returns false if one of these tests
is already running.
Perhaps we should extract this torture-test-exclusion and require
than conflicting torture tests invoke it?
Thanx, Paul
^ permalink raw reply
* [PATCHv2] ARM: dts: socfpga: Enable QSPI on the Cyclone5 sockit
From: dinguyen at opensource.altera.com @ 2016-10-26 18:05 UTC (permalink / raw)
To: linux-arm-kernel
From: Dinh Nguyen <dinguyen@opensource.altera.com>
Enable the QSPI node and add the flash chip.
Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com>
---
v2: Remove partition entries for the SoCKIT
---
arch/arm/boot/dts/socfpga_cyclone5_sockit.dts | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts b/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts
index 02e22f5..2ce6736 100644
--- a/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts
+++ b/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts
@@ -175,6 +175,27 @@
status = "okay";
};
+&qspi {
+ status = "okay";
+
+ flash: flash at 0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "n25q256a";
+ reg = <0>;
+ spi-max-frequency = <100000000>;
+
+ m25p,fast-read;
+ cdns,page-size = <256>;
+ cdns,block-size = <16>;
+ cdns,read-delay = <4>;
+ cdns,tshsl-ns = <50>;
+ cdns,tsd2d-ns = <50>;
+ cdns,tchsh-ns = <4>;
+ cdns,tslch-ns = <4>;
+ };
+};
+
&usb1 {
status = "okay";
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH] ARM: davinci: da850: Fix pwm name matching
From: Sekhar Nori @ 2016-10-26 18:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7heg33rtdl.fsf@baylibre.com>
On Wednesday 26 October 2016 09:32 PM, Kevin Hilman wrote:
> Hi Sekhar,
>
> Sekhar Nori <nsekhar@ti.com> writes:
>
>> On Tuesday 25 October 2016 11:24 PM, David Lechner wrote:
>>> This fixes pwm name matching for DA850 familiy devices. When using device
>>> tree, the da850_auxdata_lookup[] table caused pwm devices to have the exact
>>> same name, which caused errors when trying to register the devices.
>>>
>>> The names for clock matching in da850_clks[] also have to be updated to
>>> to exactly match in order for the clock lookup to work correctly.
>>>
>>> Signed-off-by: David Lechner <david@lechnology.com>
>>
>> Applied to "fixes" branch. Will send upstream after testing a bit and
>> also waiting to see if anyone else has any comments.
>
> I'm not seeing a fixes branch in your tree. Did you push this out?
> Similarily, I didn't see the updates in v4.10/defconfig either.
Pushed now. Will push a merged master branch tomorrow after some testing.
Thanks,
Sekhar
^ permalink raw reply
* Pinctrl nodes missing for USB
From: Krzysztof Kozlowski @ 2016-10-26 17:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANAwSgSfRVDA_MXN9S+G0-u-mQNhPuPJ65FT_Y-ZH5nFpX4ptg@mail.gmail.com>
On Wed, Oct 26, 2016 at 11:15:51PM +0530, Anand Moon wrote:
> Hi Krzysztof
>
> On 26 October 2016 at 22:23, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > On Wed, Oct 26, 2016 at 05:56:54PM +0530, Anand Moon wrote:
> >> Hi All,
> >>
> >> I have tried to enable CONFIG_DEBUG_PINCTRL=y on Odroid XU4.
> >> Just to try to understand the feature.
> >> Is this feature suppoted for USB nodes.
> >>
> >> Below is the output of failed to pase pinctrl for USB nodes via dts.
> >
> > I do not see any question here...
> >
> > Anyway the devices not instantiated from DT will have such warning and
> > USB devices are not present in DT, from obvious reasons... However what
> > surprises me is why pinctrl_dt_to_map() was called for USB devices?
> >
> > Best regards,
> > Krzysztof
> >
> [snip]
>
> Sorry. I was just referring HK odroidxu3 dts for reference for dwc3 controller.
>
> https://github.com/hardkernel/linux/blob/odroidxu3-3.10.y/arch/arm/boot/dts/exynos5422-odroidxu3.dts#L525
>
> I am just trying to understand if such a configuration possible for
> dwc3 controllers.
What do you mean by "configuration"? Which configuration?
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] arm64: dts: msm8996: Correct slpi region reg definition
From: Bjorn Andersson @ 2016-10-26 17:54 UTC (permalink / raw)
To: linux-arm-kernel
I missed the missing cell in the reg property of the slpi region in my review,
so let's add it.
Fixes: 2b7f0de19648 ("arm64: dts: msm8996: Add reserve-memory nodes")
Cc: Sarangdhar Joshi <spjoshi@codeaurora.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
arch/arm64/boot/dts/qcom/msm8996.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index b97647d29842..215de91e802d 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -42,7 +42,7 @@
};
slpi_region: slpi at 90b00000 {
- reg = <0x0 0x90b00000 0xa00000>;
+ reg = <0x0 0x90b00000 0x0 0xa00000>;
no-map;
};
--
2.5.0
^ permalink raw reply related
* [PATCH 02/12] ASoC: dapm: Implement stereo mixer control support
From: Mark Brown @ 2016-10-26 17:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161003110804.28235-3-wens@csie.org>
On Mon, Oct 03, 2016 at 07:07:54PM +0800, Chen-Yu Tsai wrote:
> /* find dapm widget path assoc with kcontrol */
> dapm_kcontrol_for_each_path(path, kcontrol) {
> + /*
> + * If status for the second channel was given ( >= 0 ),
> + * consider the second and later paths as the second
> + * channel.
> + */
> + if (found && rconnect >= 0)
> + soc_dapm_connect_path(path, rconnect, "mixer update");
> + else
> + soc_dapm_connect_path(path, connect, "mixer update");
> found = 1;
> - soc_dapm_connect_path(path, connect, "mixer update");
This really only works for two channels with the current inteface - the
comment makes it sound like it'll work for more but we can only pass in
two (and there's only support for specifying two everywhere).
> - change = dapm_kcontrol_set_value(kcontrol, val);
> + /* This assumes field width < (bits in unsigned int / 2) */
> + change = dapm_kcontrol_set_value(kcontrol, val | (rval << width));
That seems like a bit of an assumption in cases where we've got a single
control for both power and volume? They're very rare though, I'm not
even sure any exist. It'd be good to have a check in the code just in
case it does come up, it'll likely be a nightmare to debug if someone
does run into it.
Otherwise I think this makes sense.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161026/6a7d0d11/attachment.sig>
^ permalink raw reply
* [PATCH v2] modversions: treat symbol CRCs as 32 bit quantities on 64 bit archs
From: Ard Biesheuvel @ 2016-10-26 17:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu-MEG5ayvBcbOwEFzaWPUvOwzTHVH9JKF_tKVN683Eh7A@mail.gmail.com>
On 26 October 2016 at 14:04, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> On 26 October 2016 at 11:07, Michael Ellerman <mpe@ellerman.id.au> wrote:
>> Hi Ard,
>>
>> I like the concept, but ...
>>
>> Ard Biesheuvel <ard.biesheuvel@linaro.org> writes:
>>> The symbol CRCs are emitted as ELF symbols, which allows us to easily
>>> populate the kcrctab sections by relying on the linker to associate
>>> each kcrctab slot with the correct value.
>>>
>>> This has two downsides:
>>> - given that the CRCs are treated as pointers, we waste 4 bytes for
>>> each CRC on 64 bit architectures,
>>> - on architectures that support runtime relocation, a relocation entry is
>>> emitted for each CRC value, which may take up 24 bytes of __init space
>>> (on ELF64 systems)
>>>
>>> This comes down to a x8 overhead in [uncompressed] kernel size. In addition,
>>> each relocation has to be reverted before the CRC value can be used.
>>>
>>> Switching to explicit 32 bit values on 64 bit architectures fixes both
>>> issues, since 32 bit values are not treated as relocatable quantities on
>>> ELF64 systems, even if the value ultimately resolves to a linker supplied
>>> value.
>>
>> Are we sure that part is true? ("not treated as relocatable")
>>
>
> Thanks for testing this.
>
>> A quick test build on powerpc gives me:
>>
>> WARNING: 6829 bad relocations
>> c000000000ca3748 R_PPC64_ADDR16 *ABS*+0x0000000013f53da6
>> c000000000ca374a R_PPC64_ADDR16 *ABS*+0x00000000f7272059
>> c000000000ca374c R_PPC64_ADDR16 *ABS*+0x0000000002013d36
>> c000000000ca374e R_PPC64_ADDR16 *ABS*+0x00000000a59dffc8
>> ...
>>
>> Which is coming from our relocs_check.sh script, which checks that the
>> generated relocations are ones we know how to handle.
>>
>
> OK, first of all, it appears the ppc64 assembler interprets .word
> differently than the arm64 one, so I will need to fold this in
>
> """
> diff --git a/include/linux/export.h b/include/linux/export.h
> index fa51ab2ad190..a000d421526d 100644
> --- a/include/linux/export.h
> +++ b/include/linux/export.h
> @@ -54,7 +54,7 @@ extern struct module __this_module;
> #define __CRC_SYMBOL(sym, sec) \
> asm(" .section \"___kcrctab" sec "+" #sym "\", \"a\" \n" \
> " .weak " VMLINUX_SYMBOL_STR(__crc_##sym) " \n" \
> - " .word " VMLINUX_SYMBOL_STR(__crc_##sym) " \n" \
> + " .long " VMLINUX_SYMBOL_STR(__crc_##sym) " \n" \
> " .previous \n");
> #endif
> #else
> """
>
> With that change, the CRCs are actually emitted as
>
> WARNING: 7525 bad relocations
> c000000000ce7f50 R_PPC64_ADDR32 *ABS*+0x0000000013f53da6
> c000000000ce7f54 R_PPC64_ADDR32 *ABS*+0x0000000004f7c64e
> c000000000ce7f58 R_PPC64_ADDR32 *ABS*+0x0000000092be8a3e
>
> which is still a bit disappointing, given that we still have 7525 RELA
> entries to process.
> I tried several thing, i.e., adding -Bsymbolic to the linker command
> line, emitting the reference above as .hidden or emit the definition
> from the linker script as HIDDEN(), but nothing seems to make any
> difference. (On arm64, -Bsymbolic eliminates *all* runtime relocations
> except R_<arch>_RELATIVE ones)
>
>> And when I try to boot it I get:
>>
>> virtio: disagrees about version of symbol module_layout
>> virtio: disagrees about version of symbol module_layout
>> scsi_mod: disagrees about version of symbol module_layout
>>
>> And it can't find my root file system (unsurprisingly as it's on scsi).
>>
>
> Something like the below should fix it, I hope.
>
> """
> diff --git a/arch/powerpc/kernel/reloc_64.S b/arch/powerpc/kernel/reloc_64.S
> index d88736fbece6..99cdf2311ab5 100644
> --- a/arch/powerpc/kernel/reloc_64.S
> +++ b/arch/powerpc/kernel/reloc_64.S
> @@ -14,6 +14,7 @@
> RELA = 7
> RELACOUNT = 0x6ffffff9
> R_PPC64_RELATIVE = 22
> +R_PPC64_ADDR32 = 1
>
> /*
> * r3 = desired final address of kernel
> @@ -77,9 +78,22 @@ _GLOBAL(relocate)
> add r0,r0,r3
> stdx r0,r7,r6
> addi r9,r9,24
> - bdnz 5b
> + b 7f
> +
> + /*
> + * CRCs of exported symbols are emitted as 32-bit relocations against
> + * the *ABS* section with the CRC value recorded in the addend.
> + */
> +6: cmpdi r0,R_PPC64_ADDR32
> + bne 7f
> + ld r6,0(r9) /* reloc->r_offset */
> + ld r0,16(r9) /* reloc->r_addend */
> + stwx r0,r7,r6
> + addi r9,r9,24
> +
> +7: bdnz 5b
> + blr
>
> -6: blr
>
> .balign 8
> p_dyn: .llong __dynamic_start - 0b
> """
>
> Note that the loop no longer terminates at the first
> non-R_PPC64_RELATIVE relocation, but that seems safer to me in any
> case. It simply stores the value of r_addend at r_offset, which is the
> correct thing to do for R_PPC64_ADDR32 relocations against the *ABS*
> section, regardless of whether we are dealing with CRCs or something
> else. Note that the comparison above will fail for R_PPC64_ADDR32
> relocations against named symbols, since we compare the entire r_info
> field and not just the type (as the comment a few lines higher up
> suggests)
>
> Also a fix for relocs_check.sh:
>
> """
> diff --git a/arch/powerpc/relocs_check.sh b/arch/powerpc/relocs_check.sh
> index ec2d5c835170..2f510fbc87da 100755
> --- a/arch/powerpc/relocs_check.sh
> +++ b/arch/powerpc/relocs_check.sh
> @@ -43,7 +43,8 @@ R_PPC_ADDR16_HA
> R_PPC_RELATIVE
> R_PPC_NONE' |
> grep -E -v '\<R_PPC64_ADDR64[[:space:]]+mach_' |
> - grep -E -v '\<R_PPC64_ADDR64[[:space:]]+__crc_'
> + grep -E -v '\<R_PPC64_ADDR64[[:space:]]+__crc_' |
> + grep -E -v '\<R_PPC64_ADDR32[[:space:]]+\*ABS\*'
> )
>
> if [ -z "$bad_relocs" ]; then
> """
>
> If these changes work for PPC, I think we should fold them in.
> Hopefully, GNU ld for PPC will gain that ability to resolve absolute
> relocations at build time (like other architectures), and then the
> R_PPC64_ADDR32 handling will simply become dead code. In any case, it
> is an improvement over the mangling of CRC values to undo the runtime
> relocation, imo.
>
I have spent some more time looking into this, and it seems impossible
to coerce the powerpc linker into resolving relocations against build
time absolute constants at build time.
Interestingly, the CONFIG_MODVERSIONS + CONFIG_RELOCATABLE issue
exists on PPC32 as well, i.e., commit 0e0ed6406e61 ("powerpc/modules:
Module CRC relocation fix causes perf issues") reintroduced it on
PPC32 by making the fix PPC64 specific.
I think the fact that relocations against *ABS* symbols are converted
into R_PPC[64]_RELATIVE relocations is a linker bug. I spotted
something similar on arm64 a while ago
https://lists.gnu.org/archive/html/bug-binutils/2016-07/msg00087.html
but this has not been fixed yet either.
Having to deal with toolchain bugs when working on issues like these
is always a bit annoying, so I wonder what your take is on the PPC32
issue. If nobody cares about CONFIG_RELOCATABLE on PPC32, perhaps it
could be made mutually exclusive with CONFIG_MODVERSIONS on 32-bit
PPC.
^ permalink raw reply
* Pinctrl nodes missing for USB
From: Anand Moon @ 2016-10-26 17:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026165348.GA5600@kozik-lap>
Hi Krzysztof
On 26 October 2016 at 22:23, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Wed, Oct 26, 2016 at 05:56:54PM +0530, Anand Moon wrote:
>> Hi All,
>>
>> I have tried to enable CONFIG_DEBUG_PINCTRL=y on Odroid XU4.
>> Just to try to understand the feature.
>> Is this feature suppoted for USB nodes.
>>
>> Below is the output of failed to pase pinctrl for USB nodes via dts.
>
> I do not see any question here...
>
> Anyway the devices not instantiated from DT will have such warning and
> USB devices are not present in DT, from obvious reasons... However what
> surprises me is why pinctrl_dt_to_map() was called for USB devices?
>
> Best regards,
> Krzysztof
>
[snip]
Sorry. I was just referring HK odroidxu3 dts for reference for dwc3 controller.
https://github.com/hardkernel/linux/blob/odroidxu3-3.10.y/arch/arm/boot/dts/exynos5422-odroidxu3.dts#L525
I am just trying to understand if such a configuration possible for
dwc3 controllers.
Best Regards
Anand Moon
^ permalink raw reply
* [PATCH] PCI: mvebu: Take control of mbus windows setup by the firmware
From: Jason Gunthorpe @ 2016-10-26 17:44 UTC (permalink / raw)
To: linux-arm-kernel
The firmware may setup the mbus to access PCI-E and indicate this
has happened with a ranges mapping for the PCI-E ID. If this happens
then the mbus setup and the pci dynamic setup conflict, creating
problems.
Have PCI-E assume control of the firmware specified default mapping by
setting the value of the bridge window to match the firmware mapping.
Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
---
drivers/bus/mvebu-mbus.c | 36 ++++++++++++++++++++++++++++++++++++
drivers/pci/host/pci-mvebu.c | 22 ++++++++++++++++++++++
include/linux/mbus.h | 3 +++
3 files changed, 61 insertions(+)
In the DT this could look like:
mbus {
ranges = <MBUS_ID(0x04, 0xe8) 0 0xe0000000 0x8000000 /* PEX 0 MEM */
pex@e0000000 {
compatible = "marvell,kirkwood-pcie";
ranges = <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000 /* Controller regs */
0x82000000 1 0 MBUS_ID(0x04, 0xe8) 0 1 0 /* Port 0.0 MEM */
>;
pcie at 1,0 {
ranges = <0x82000000 0 0 0x82000000 0x1 0 1 0>;
reg = <0x0800 0 0 0 0>; // 0000:00:01.0
device at 0 {
reg = <0x0 0 0 0 0>; // 0000:01:00.0
ranges = <0x00000000 0x82000000 0x00000000 0x00000000 0x8000000>;
Which is basically the OF way to describe PCI devices downstream of
the interface and give information about what their BARs should be.
This is useful if there is even more DT stuff below the explicitly
declared device as it allows standard DT address translation to work
properly.
diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index c7f396903184..ce0ac5049c1f 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -922,6 +922,42 @@ int mvebu_mbus_add_window_by_id(unsigned int target, unsigned int attribute,
size, MVEBU_MBUS_NO_REMAP);
}
+/**
+ * mvebu_mbus_get_single_window_by_id() - return the location of the window if
+ * the target/attribute has a single enabled mapping.
+ *
+ * RETURNS:
+ * -ENODEV if no mapping and -E2BIG if there is more than one mapping
+ */
+int mvebu_mbus_get_single_window_by_id(unsigned int target,
+ unsigned int attribute,
+ phys_addr_t *base, phys_addr_t *size)
+{
+ unsigned int win;
+ unsigned int count = 0;
+
+ for (win = 0; win < mbus_state.soc->num_wins; win++) {
+ u64 wbase;
+ u32 wsize;
+ u8 wtarget, wattr;
+ int enabled;
+
+ mvebu_mbus_read_window(&mbus_state, win, &enabled, &wbase,
+ &wsize, &wtarget, &wattr, NULL);
+ if (enabled && wtarget == target && wattr == attribute) {
+ *base = wbase;
+ *size = wsize;
+ count++;
+ }
+ }
+
+ if (count == 1)
+ return 0;
+ if (count == 0)
+ return -ENODEV;
+ return -E2BIG;
+}
+
int mvebu_mbus_del_window(phys_addr_t base, size_t size)
{
int win;
diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c
index 307f81d6b479..5d5a2687b73e 100644
--- a/drivers/pci/host/pci-mvebu.c
+++ b/drivers/pci/host/pci-mvebu.c
@@ -464,6 +464,8 @@ static void mvebu_pcie_handle_membase_change(struct mvebu_pcie_port *port)
static void mvebu_sw_pci_bridge_init(struct mvebu_pcie_port *port)
{
struct mvebu_sw_pci_bridge *bridge = &port->bridge;
+ int rc;
+ phys_addr_t base, size;
memset(bridge, 0, sizeof(struct mvebu_sw_pci_bridge));
@@ -480,6 +482,26 @@ static void mvebu_sw_pci_bridge_init(struct mvebu_pcie_port *port)
/* Add capabilities */
bridge->status = PCI_STATUS_CAP_LIST;
+
+ /*
+ * If the firmware has already setup a window for PCIe then assume
+ * control of it by defaulting the BAR to the window setting.
+ */
+ rc = mvebu_mbus_get_single_window_by_id(port->mem_target,
+ port->mem_attr, &base, &size);
+ if (rc == -E2BIG)
+ pr_err(FW_BUG "%s: Too many pre-existing mbus mappings\n",
+ port->dn->name);
+ if (!rc) {
+ if ((base & 0xFFFFF) != 0 || ((size + base) & 0xFFFFF) != 0)
+ pr_err(FW_BUG "%s: Invalid pre-existing mbus mapping\n",
+ port->dn->name);
+ port->memwin_base = base;
+ port->memwin_size = size;
+ port->bridge.membase = (base >> 16) & 0xFFF0;
+ port->bridge.memlimit = ((size - 1 + base) >> 16) & 0xFFF0;
+ port->bridge.command |= PCI_COMMAND_MEMORY;
+ }
}
/*
diff --git a/include/linux/mbus.h b/include/linux/mbus.h
index d610232762e3..dfafc27b41b5 100644
--- a/include/linux/mbus.h
+++ b/include/linux/mbus.h
@@ -83,5 +83,8 @@ int mvebu_mbus_init(const char *soc, phys_addr_t mbus_phys_base,
size_t mbus_size, phys_addr_t sdram_phys_base,
size_t sdram_size);
int mvebu_mbus_dt_init(bool is_coherent);
+int mvebu_mbus_get_single_window_by_id(unsigned int target,
+ unsigned int attribute,
+ phys_addr_t *base, phys_addr_t *size);
#endif /* __LINUX_MBUS_H */
--
2.1.4
^ permalink raw reply related
* [PATCH v2 2/2] arm64: Wire up iommu_dma_{map, unmap}_resource()
From: Robin Murphy @ 2016-10-26 17:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4e84146ae49a4edd5f1226d76617be9aa92a58ee.1477503578.git.robin.murphy@arm.com>
With no coherency to worry about, just plug'em straight in.
CC: Catalin Marinas <catalin.marinas@arm.com>
CC: Will Deacon <will.deacon@arm.com>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
arch/arm64/mm/dma-mapping.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 3f74d0d98de6..5cd0a383b14b 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -796,6 +796,8 @@ static void __iommu_unmap_sg_attrs(struct device *dev,
.sync_single_for_device = __iommu_sync_single_for_device,
.sync_sg_for_cpu = __iommu_sync_sg_for_cpu,
.sync_sg_for_device = __iommu_sync_sg_for_device,
+ .map_resource = iommu_dma_map_resource,
+ .unmap_resource = iommu_dma_unmap_resource,
.dma_supported = iommu_dma_supported,
.mapping_error = iommu_dma_mapping_error,
};
--
1.9.1
^ permalink raw reply related
* [PATCH v2 1/2] iommu/dma: Implement dma_{map,unmap}_resource()
From: Robin Murphy @ 2016-10-26 17:43 UTC (permalink / raw)
To: linux-arm-kernel
With the new dma_{map,unmap}_resource() functions added to the DMA API
for the benefit of cases like slave DMA, add suitable implementations to
the arsenal of our generic layer. Since cache maintenance should not be
a concern, these can both be standalone callback implementations without
the need for arch code wrappers.
CC: Joerg Roedel <joro@8bytes.org>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
v2: Use iommu_dma_unmap_page for symmetry, instead of being sneaky.
drivers/iommu/dma-iommu.c | 13 +++++++++++++
include/linux/dma-iommu.h | 4 ++++
2 files changed, 17 insertions(+)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index c5ab8667e6f2..a2fd90a6a782 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -624,6 +624,19 @@ void iommu_dma_unmap_sg(struct device *dev, struct scatterlist *sg, int nents,
__iommu_dma_unmap(iommu_get_domain_for_dev(dev), sg_dma_address(sg));
}
+dma_addr_t iommu_dma_map_resource(struct device *dev, phys_addr_t phys,
+ size_t size, enum dma_data_direction dir, unsigned long attrs)
+{
+ return iommu_dma_map_page(dev, phys_to_page(phys), offset_in_page(phys),
+ size, dma_direction_to_prot(dir, false) | IOMMU_MMIO);
+}
+
+void iommu_dma_unmap_resource(struct device *dev, dma_addr_t handle,
+ size_t size, enum dma_data_direction dir, unsigned long attrs)
+{
+ iommu_dma_unmap_page(dev, handle, size, dir, attrs);
+}
+
int iommu_dma_supported(struct device *dev, u64 mask)
{
/*
diff --git a/include/linux/dma-iommu.h b/include/linux/dma-iommu.h
index 32c589062bd9..7f7e9a7e3839 100644
--- a/include/linux/dma-iommu.h
+++ b/include/linux/dma-iommu.h
@@ -61,6 +61,10 @@ void iommu_dma_unmap_page(struct device *dev, dma_addr_t handle, size_t size,
enum dma_data_direction dir, unsigned long attrs);
void iommu_dma_unmap_sg(struct device *dev, struct scatterlist *sg, int nents,
enum dma_data_direction dir, unsigned long attrs);
+dma_addr_t iommu_dma_map_resource(struct device *dev, phys_addr_t phys,
+ size_t size, enum dma_data_direction dir, unsigned long attrs);
+void iommu_dma_unmap_resource(struct device *dev, dma_addr_t handle,
+ size_t size, enum dma_data_direction dir, unsigned long attrs);
int iommu_dma_supported(struct device *dev, u64 mask);
int iommu_dma_mapping_error(struct device *dev, dma_addr_t dma_addr);
--
1.9.1
^ permalink raw reply related
* [PATCH] at91sam9g20.dtsi: set correct USB clock divisors
From: Andrey Yurovsky @ 2016-10-26 17:43 UTC (permalink / raw)
To: linux-arm-kernel
The AT91SAM9G20 has different clock divisors from the otherwise similar
AT91SAM9260. Set them in at91sam9g20.dtsi so that all AT91SAM9G20 users set up
the USB host controller clocks correctly.
Signed-off-by: Andrey Yurovsky <yurovsky@gmail.com>
---
arch/arm/boot/dts/at91sam9g20.dtsi | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/at91sam9g20.dtsi b/arch/arm/boot/dts/at91sam9g20.dtsi
index f593016..6c4488c 100644
--- a/arch/arm/boot/dts/at91sam9g20.dtsi
+++ b/arch/arm/boot/dts/at91sam9g20.dtsi
@@ -62,6 +62,10 @@
atmel,clk-output-range = <0 133000000>;
atmel,clk-divisors = <1 2 4 6>;
};
+
+ usb: usbck {
+ atmel,clk-divisors = <4 2 0 0>;
+ };
};
};
};
--
2.7.4
^ permalink raw reply related
* [PATCH v2 8/8] KVM: arm/arm64: Enable selective trapping of TLB instructions
From: Punit Agrawal @ 2016-10-26 17:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026174148.17172-1-punit.agrawal@arm.com>
The TTLB bit of Hypervisor Control Register controls the trapping of
guest TLB maintenance instructions. Taking the trap requires a switch to
the hypervisor and is an expensive operation.
Enable selective trapping of guest TLB instructions when the associated
perf trace event is enabled for a specific virtual machine.
Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
Cc: Christoffer Dall <christoffer.dall@linaro.org>
Cc: Marc Zyngier <marc.zyngier@arm.com>
---
virt/kvm/arm/perf_trace.c | 32 ++++++++++++++++++++++++++++++++
1 file changed, 32 insertions(+)
diff --git a/virt/kvm/arm/perf_trace.c b/virt/kvm/arm/perf_trace.c
index 1cafbc9..649ca55 100644
--- a/virt/kvm/arm/perf_trace.c
+++ b/virt/kvm/arm/perf_trace.c
@@ -17,6 +17,8 @@
#include <linux/kvm_host.h>
#include <linux/trace_events.h>
+#include <asm/kvm_emulate.h>
+
typedef int (*perf_trace_callback_fn)(struct kvm *kvm, bool enable);
struct kvm_trace_hook {
@@ -24,7 +26,37 @@ struct kvm_trace_hook {
perf_trace_callback_fn setup_fn;
};
+static int tlb_invalidate_trap(struct kvm *kvm, bool enable)
+{
+ int i;
+ struct kvm_vcpu *vcpu;
+
+ /*
+ * Halt the VM to ensure atomic update across all vcpus (this
+ * avoids racy behaviour against other modifications of
+ * HCR_EL2 such as kvm_toggle_cache/kvm_set_way_flush).
+ */
+ kvm_arm_halt_guest(kvm);
+ kvm_for_each_vcpu(i, vcpu, kvm) {
+ unsigned long hcr = vcpu_get_hcr(vcpu);
+
+ if (enable)
+ hcr |= HCR_TTLB;
+ else
+ hcr &= ~HCR_TTLB;
+
+ vcpu_set_hcr(vcpu, hcr);
+ }
+ kvm_arm_resume_guest(kvm);
+
+ return 0;
+}
+
static struct kvm_trace_hook trace_hook[] = {
+ {
+ .key = "kvm_tlb_invalidate",
+ .setup_fn = tlb_invalidate_trap,
+ },
{ },
};
--
2.9.3
^ permalink raw reply related
* [PATCH v2 7/8] arm64: KVM: Handle trappable TLB instructions
From: Punit Agrawal @ 2016-10-26 17:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026174148.17172-1-punit.agrawal@arm.com>
The ARMv8 architecture allows trapping of TLB maintenane instructions
from EL0/EL1 to higher exception levels. On encountering a trappable TLB
instruction in a guest, an exception is taken to EL2.
Add support to handle emulating the TLB instructions.
Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
Cc: Christoffer Dall <christoffer.dall@linaro.org>
Cc: Marc Zyngier <marc.zyngier@arm.com>
---
arch/arm64/include/asm/kvm_asm.h | 1 +
arch/arm64/kvm/hyp/tlb.c | 75 +++++++++++++++++++++++++++++++++++++
arch/arm64/kvm/sys_regs.c | 81 ++++++++++++++++++++++++++++++++++++++++
3 files changed, 157 insertions(+)
diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
index 18f7465..f3619f3 100644
--- a/arch/arm64/include/asm/kvm_asm.h
+++ b/arch/arm64/include/asm/kvm_asm.h
@@ -54,6 +54,7 @@ extern char __kvm_hyp_vector[];
extern void __kvm_flush_vm_context(void);
extern void __kvm_tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa);
extern void __kvm_tlb_flush_vmid(struct kvm *kvm);
+extern void __kvm_emulate_tlb_invalidate(struct kvm *kvm, u32 opcode, u64 regval);
extern int __kvm_vcpu_run(struct kvm_vcpu *vcpu);
diff --git a/arch/arm64/kvm/hyp/tlb.c b/arch/arm64/kvm/hyp/tlb.c
index 74eb562..4818ef9 100644
--- a/arch/arm64/kvm/hyp/tlb.c
+++ b/arch/arm64/kvm/hyp/tlb.c
@@ -71,3 +71,78 @@ void __hyp_text __kvm_flush_vm_context(void)
__tlbi(alle1is);
__flush_icache_all(); /* contains a dsb(ish) */
}
+
+/* Intentionally empty functions */
+static void __hyp_text __switch_to_hyp_role_nvhe(void) { }
+static void __hyp_text __switch_to_host_role_nvhe(void) { }
+
+static void __hyp_text __switch_to_hyp_role_vhe(void)
+{
+ u64 hcr = read_sysreg(hcr_el2);
+
+ /*
+ * When VHE is enabled and HCR_EL2.TGE=1, EL1&0 TLB operations
+ * apply to EL2&0 translation regime. As we prepare to emulate
+ * guest TLB operation clear HCR_TGE to target TLB operations
+ * to EL1&0 (guest).
+ */
+ hcr &= ~HCR_TGE;
+ write_sysreg(hcr, hcr_el2);
+}
+
+static void __hyp_text __switch_to_host_role_vhe(void)
+{
+ u64 hcr = read_sysreg(hcr_el2);
+
+ hcr |= HCR_TGE;
+ write_sysreg(hcr, hcr_el2);
+}
+
+static hyp_alternate_select(__switch_to_hyp_role,
+ __switch_to_hyp_role_nvhe,
+ __switch_to_hyp_role_vhe,
+ ARM64_HAS_VIRT_HOST_EXTN);
+
+static hyp_alternate_select(__switch_to_host_role,
+ __switch_to_host_role_nvhe,
+ __switch_to_host_role_vhe,
+ ARM64_HAS_VIRT_HOST_EXTN);
+
+static void __hyp_text __switch_to_guest_regime(struct kvm *kvm)
+{
+ write_sysreg(kvm->arch.vttbr, vttbr_el2);
+ __switch_to_hyp_role();
+ isb();
+}
+
+static void __hyp_text __switch_to_host_regime(void)
+{
+ __switch_to_host_role();
+ write_sysreg(0, vttbr_el2);
+}
+
+void __hyp_text
+__kvm_emulate_tlb_invalidate(struct kvm *kvm, u32 opcode, u64 regval)
+{
+ kvm = kern_hyp_va(kvm);
+
+ /*
+ * Switch to the guest before performing any TLB operations to
+ * target the appropriate VMID
+ */
+ __switch_to_guest_regime(kvm);
+
+ /*
+ * TLB maintenance operations are broadcast to
+ * inner-shareable domain when HCR_FB is set (default for
+ * KVM).
+ *
+ * Nuke all Stage 1 TLB entries for the VM. This will kill
+ * performance but it's always safe to do as we don't leave
+ * behind any strays in the TLB
+ */
+ __tlbi(vmalle1is);
+ isb();
+
+ __switch_to_host_regime();
+}
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index f302fdb..2a2846c 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -785,6 +785,18 @@ static bool access_pmuserenr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
return true;
}
+static bool emulate_tlb_invalidate(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
+ const struct sys_reg_desc *r)
+{
+ u32 opcode = sys_reg(p->Op0, p->Op1, p->CRn, p->CRm, p->Op2);
+
+ kvm_call_hyp(__kvm_emulate_tlb_invalidate,
+ vcpu->kvm, opcode, p->regval);
+ trace_kvm_tlb_invalidate(*vcpu_pc(vcpu), opcode);
+
+ return true;
+}
+
/* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
#define DBG_BCR_BVR_WCR_WVR_EL1(n) \
/* DBGBVRn_EL1 */ \
@@ -836,6 +848,35 @@ static const struct sys_reg_desc sys_reg_descs[] = {
{ Op0(0b01), Op1(0b000), CRn(0b0111), CRm(0b1110), Op2(0b010),
access_dcsw },
+ /*
+ * ARMv8 ARM: Table C5-4 TLB maintenance instructions
+ * (Ref: ARMv8 ARM C5.1 version: ARM DDI 0487A.j)
+ */
+ /* TLBI VMALLE1IS */
+ { Op0(1), Op1(0), CRn(8), CRm(3), Op2(0), emulate_tlb_invalidate },
+ /* TLBI VAE1IS */
+ { Op0(1), Op1(0), CRn(8), CRm(3), Op2(1), emulate_tlb_invalidate },
+ /* TLBI ASIDE1IS */
+ { Op0(1), Op1(0), CRn(8), CRm(3), Op2(2), emulate_tlb_invalidate },
+ /* TLBI VAAE1IS */
+ { Op0(1), Op1(0), CRn(8), CRm(3), Op2(3), emulate_tlb_invalidate },
+ /* TLBI VALE1IS */
+ { Op0(1), Op1(0), CRn(8), CRm(3), Op2(5), emulate_tlb_invalidate },
+ /* TLBI VAALE1IS */
+ { Op0(1), Op1(0), CRn(8), CRm(3), Op2(7), emulate_tlb_invalidate },
+ /* TLBI VMALLE1 */
+ { Op0(1), Op1(0), CRn(8), CRm(7), Op2(0), emulate_tlb_invalidate },
+ /* TLBI VAE1 */
+ { Op0(1), Op1(0), CRn(8), CRm(7), Op2(1), emulate_tlb_invalidate },
+ /* TLBI ASIDE1 */
+ { Op0(1), Op1(0), CRn(8), CRm(7), Op2(2), emulate_tlb_invalidate },
+ /* TLBI VAAE1 */
+ { Op0(1), Op1(0), CRn(8), CRm(7), Op2(3), emulate_tlb_invalidate },
+ /* TLBI VALE1 */
+ { Op0(1), Op1(0), CRn(8), CRm(7), Op2(5), emulate_tlb_invalidate },
+ /* TLBI VAALE1 */
+ { Op0(1), Op1(0), CRn(8), CRm(7), Op2(7), emulate_tlb_invalidate },
+
DBG_BCR_BVR_WCR_WVR_EL1(0),
DBG_BCR_BVR_WCR_WVR_EL1(1),
/* MDCCINT_EL1 */
@@ -1324,6 +1365,46 @@ static const struct sys_reg_desc cp15_regs[] = {
{ Op1( 0), CRn( 7), CRm(10), Op2( 2), access_dcsw },
{ Op1( 0), CRn( 7), CRm(14), Op2( 2), access_dcsw },
+ /*
+ * TLB operations
+ */
+ /* TLBIALLIS */
+ { Op1( 0), CRn( 8), CRm( 3), Op2( 0), emulate_tlb_invalidate},
+ /* TLBIMVAIS */
+ { Op1( 0), CRn( 8), CRm( 3), Op2( 1), emulate_tlb_invalidate},
+ /* TLBIASIDIS */
+ { Op1( 0), CRn( 8), CRm( 3), Op2( 2), emulate_tlb_invalidate},
+ /* TLBIMVAAIS */
+ { Op1( 0), CRn( 8), CRm( 3), Op2( 3), emulate_tlb_invalidate},
+ /* TLBIMVALIS */
+ { Op1( 0), CRn( 8), CRm( 3), Op2( 5), emulate_tlb_invalidate},
+ /* TLBIMVAALIS */
+ { Op1( 0), CRn( 8), CRm( 3), Op2( 7), emulate_tlb_invalidate},
+ /* ITLBIALL */
+ { Op1( 0), CRn( 8), CRm( 5), Op2( 0), emulate_tlb_invalidate},
+ /* ITLBIMVA */
+ { Op1( 0), CRn( 8), CRm( 5), Op2( 1), emulate_tlb_invalidate},
+ /* ITLBIASID */
+ { Op1( 0), CRn( 8), CRm( 5), Op2( 2), emulate_tlb_invalidate},
+ /* DTLBIALL */
+ { Op1( 0), CRn( 8), CRm( 6), Op2( 0), emulate_tlb_invalidate},
+ /* DTLBIMVA */
+ { Op1( 0), CRn( 8), CRm( 6), Op2( 1), emulate_tlb_invalidate},
+ /* DTLBIASID */
+ { Op1( 0), CRn( 8), CRm( 6), Op2( 2), emulate_tlb_invalidate},
+ /* TLBIALL */
+ { Op1( 0), CRn( 8), CRm( 7), Op2( 0), emulate_tlb_invalidate},
+ /* TLBIMVA */
+ { Op1( 0), CRn( 8), CRm( 7), Op2( 1), emulate_tlb_invalidate},
+ /* TLBIASID */
+ { Op1( 0), CRn( 8), CRm( 7), Op2( 2), emulate_tlb_invalidate},
+ /* TLBIMVAA */
+ { Op1( 0), CRn( 8), CRm( 7), Op2( 3), emulate_tlb_invalidate},
+ /* TLBIMVAL */
+ { Op1( 0), CRn( 8), CRm( 7), Op2( 5), emulate_tlb_invalidate},
+ /* TLBIMVAAL */
+ { Op1( 0), CRn( 8), CRm( 7), Op2( 7), emulate_tlb_invalidate},
+
/* PMU */
{ Op1( 0), CRn( 9), CRm(12), Op2( 0), access_pmcr },
{ Op1( 0), CRn( 9), CRm(12), Op2( 1), access_pmcnten },
--
2.9.3
^ permalink raw reply related
* [PATCH v2 6/8] arm: KVM: Handle trappable TLB instructions
From: Punit Agrawal @ 2016-10-26 17:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026174148.17172-1-punit.agrawal@arm.com>
It is possible to enable selective trapping of guest TLB maintenance
instructions executed in lower privilege levels to HYP mode. This
feature can be used to monitor guest TLB operations.
Add support to emulate the TLB instructions when their execution traps
to hyp mode.
Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
Cc: Christoffer Dall <christoffer.dall@linaro.org>
Cc: Marc Zyngier <marc.zyngier@arm.com>
---
arch/arm/include/asm/kvm_asm.h | 1 +
arch/arm/kvm/coproc.c | 55 ++++++++++++++++++++++++++++++++++++++++++
arch/arm/kvm/hyp/tlb.c | 33 +++++++++++++++++++++++++
3 files changed, 89 insertions(+)
diff --git a/arch/arm/include/asm/kvm_asm.h b/arch/arm/include/asm/kvm_asm.h
index d7ea6bc..00a6511 100644
--- a/arch/arm/include/asm/kvm_asm.h
+++ b/arch/arm/include/asm/kvm_asm.h
@@ -66,6 +66,7 @@ extern char __kvm_hyp_vector[];
extern void __kvm_flush_vm_context(void);
extern void __kvm_tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa);
extern void __kvm_tlb_flush_vmid(struct kvm *kvm);
+extern void __kvm_emulate_tlb_invalidate(struct kvm *kvm, u32 opcode, u64 regval);
extern int __kvm_vcpu_run(struct kvm_vcpu *vcpu);
diff --git a/arch/arm/kvm/coproc.c b/arch/arm/kvm/coproc.c
index 3e5e419..593edeb 100644
--- a/arch/arm/kvm/coproc.c
+++ b/arch/arm/kvm/coproc.c
@@ -205,6 +205,23 @@ static bool access_dcsw(struct kvm_vcpu *vcpu,
return true;
}
+static bool emulate_tlb_invalidate(struct kvm_vcpu *vcpu,
+ const struct coproc_params *p,
+ const struct coproc_reg *r)
+{
+ /*
+ * Based on system register encoding from ARM v8 ARM
+ * (DDI 0487A.k F5.1.103)
+ */
+ u32 opcode = p->Op1 << 21 | p->CRn << 16 | p->Op2 << 5 | p->CRm << 0;
+
+ kvm_call_hyp(__kvm_emulate_tlb_invalidate,
+ vcpu->kvm, opcode, p->Rt1);
+ trace_kvm_tlb_invalidate(*vcpu_pc(vcpu), opcode);
+
+ return true;
+}
+
/*
* Generic accessor for VM registers. Only called as long as HCR_TVM
* is set. If the guest enables the MMU, we stop trapping the VM
@@ -354,6 +371,44 @@ static const struct coproc_reg cp15_regs[] = {
{ CRn( 7), CRm( 6), Op1( 0), Op2( 2), is32, access_dcsw},
{ CRn( 7), CRm(10), Op1( 0), Op2( 2), is32, access_dcsw},
{ CRn( 7), CRm(14), Op1( 0), Op2( 2), is32, access_dcsw},
+
+ /* TLBIALLIS */
+ { CRn( 8), CRm( 3), Op1( 0), Op2( 0), is32, emulate_tlb_invalidate},
+ /* TLBIMVAIS */
+ { CRn( 8), CRm( 3), Op1( 0), Op2( 1), is32, emulate_tlb_invalidate},
+ /* TLBIASIDIS */
+ { CRn( 8), CRm( 3), Op1( 0), Op2( 2), is32, emulate_tlb_invalidate},
+ /* TLBIMVAAIS */
+ { CRn( 8), CRm( 3), Op1( 0), Op2( 3), is32, emulate_tlb_invalidate},
+ /* TLBIMVALIS */
+ { CRn( 8), CRm( 3), Op1( 0), Op2( 5), is32, emulate_tlb_invalidate},
+ /* TLBIMVAALIS */
+ { CRn( 8), CRm( 3), Op1( 0), Op2( 7), is32, emulate_tlb_invalidate},
+ /* ITLBIALL */
+ { CRn( 8), CRm( 5), Op1( 0), Op2( 0), is32, emulate_tlb_invalidate},
+ /* ITLBIMVA */
+ { CRn( 8), CRm( 5), Op1( 0), Op2( 1), is32, emulate_tlb_invalidate},
+ /* ITLBIASID */
+ { CRn( 8), CRm( 5), Op1( 0), Op2( 2), is32, emulate_tlb_invalidate},
+ /* DTLBIALL */
+ { CRn( 8), CRm( 6), Op1( 0), Op2( 0), is32, emulate_tlb_invalidate},
+ /* DTLBIMVA */
+ { CRn( 8), CRm( 6), Op1( 0), Op2( 1), is32, emulate_tlb_invalidate},
+ /* DTLBIASID */
+ { CRn( 8), CRm( 6), Op1( 0), Op2( 2), is32, emulate_tlb_invalidate},
+ /* TLBIALL */
+ { CRn( 8), CRm( 7), Op1( 0), Op2( 0), is32, emulate_tlb_invalidate},
+ /* TLBIMVA */
+ { CRn( 8), CRm( 7), Op1( 0), Op2( 1), is32, emulate_tlb_invalidate},
+ /* TLBIASID */
+ { CRn( 8), CRm( 7), Op1( 0), Op2( 2), is32, emulate_tlb_invalidate},
+ /* TLBIMVAA */
+ { CRn( 8), CRm( 7), Op1( 0), Op2( 3), is32, emulate_tlb_invalidate},
+ /* TLBIMVAL */
+ { CRn( 8), CRm( 7), Op1( 0), Op2( 5), is32, emulate_tlb_invalidate},
+ /* TLBIMVAAL */
+ { CRn( 8), CRm( 7), Op1( 0), Op2( 7), is32, emulate_tlb_invalidate},
+
/*
* L2CTLR access (guest wants to know #CPUs).
*/
diff --git a/arch/arm/kvm/hyp/tlb.c b/arch/arm/kvm/hyp/tlb.c
index 7296528..cfa7cf6 100644
--- a/arch/arm/kvm/hyp/tlb.c
+++ b/arch/arm/kvm/hyp/tlb.c
@@ -61,3 +61,36 @@ void __hyp_text __kvm_flush_vm_context(void)
write_sysreg(0, ICIALLUIS);
dsb(ish);
}
+
+static void __hyp_text __switch_to_guest_regime(struct kvm *kvm)
+{
+ write_sysreg(kvm->arch.vttbr, VTTBR);
+ isb();
+}
+
+static void __hyp_text __switch_to_host_regime(void)
+{
+ write_sysreg(0, VTTBR);
+}
+
+void __hyp_text
+__kvm_emulate_tlb_invalidate(struct kvm *kvm, u32 opcode, u64 regval)
+{
+ kvm = kern_hyp_va(kvm);
+
+ __switch_to_guest_regime(kvm);
+
+ /*
+ * TLB maintenance operations are broadcast to
+ * inner-shareable domain when HCR_FB is set (default for
+ * KVM).
+ *
+ * Nuke all Stage 1 TLB entries for the VM. This will kill
+ * performance but it's always safe to do as we don't leave
+ * behind any strays in the TLB
+ */
+ write_sysreg(0, TLBIALLIS);
+ isb();
+
+ __switch_to_host_regime();
+}
--
2.9.3
^ permalink raw reply related
* [PATCH v2 5/8] KVM: Add event to trace tlb invalidations
From: Punit Agrawal @ 2016-10-26 17:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026174148.17172-1-punit.agrawal@arm.com>
As TLB operations can have an impact on system performance, add a trace
event to enable monitoring of guest TLB maintenance operations.
Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>
---
include/trace/events/kvm.h | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/include/trace/events/kvm.h b/include/trace/events/kvm.h
index 8ade3eb..4b3d07e 100644
--- a/include/trace/events/kvm.h
+++ b/include/trace/events/kvm.h
@@ -393,6 +393,23 @@ TRACE_EVENT(kvm_halt_poll_ns,
#define trace_kvm_halt_poll_ns_shrink(vcpu_id, new, old) \
trace_kvm_halt_poll_ns(false, vcpu_id, new, old)
+TRACE_EVENT(kvm_tlb_invalidate,
+ TP_PROTO(unsigned long vcpu_pc, u32 opcode),
+ TP_ARGS(vcpu_pc, opcode),
+
+ TP_STRUCT__entry(
+ __field(unsigned long, vcpu_pc)
+ __field(u32, opcode)
+ ),
+
+ TP_fast_assign(
+ __entry->vcpu_pc = vcpu_pc;
+ __entry->opcode = opcode;
+ ),
+
+ TP_printk("vcpu_pc=0x%16lx opcode=%08x", __entry->vcpu_pc, __entry->opcode)
+);
+
#endif /* _TRACE_KVM_MAIN_H */
/* This part must be outside protection */
--
2.9.3
^ permalink raw reply related
* [PATCH v2 4/8] KVM: arm/arm64: Register perf trace event notifier
From: Punit Agrawal @ 2016-10-26 17:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026174148.17172-1-punit.agrawal@arm.com>
Register a notifier to track state changes of perf trace events.
The notifier will enable taking appropriate action for trace events
targeting VM.
Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
Cc: Christoffer Dall <christoffer.dall@linaro.org>
Cc: Marc Zyngier <marc.zyngier@arm.com>
---
arch/arm/include/asm/kvm_host.h | 8 +++
arch/arm/kvm/Kconfig | 4 ++
arch/arm/kvm/Makefile | 1 +
arch/arm/kvm/arm.c | 2 +
arch/arm64/include/asm/kvm_host.h | 8 +++
arch/arm64/kvm/Kconfig | 4 ++
arch/arm64/kvm/Makefile | 1 +
virt/kvm/arm/perf_trace.c | 122 ++++++++++++++++++++++++++++++++++++++
8 files changed, 150 insertions(+)
create mode 100644 virt/kvm/arm/perf_trace.c
diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index 2d19e02..e92c4f7 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -285,6 +285,14 @@ static inline int kvm_arch_dev_ioctl_check_extension(struct kvm *kvm, long ext)
int kvm_perf_init(void);
int kvm_perf_teardown(void);
+#if !defined(CONFIG_KVM_PERF_TRACE)
+static inline int kvm_perf_trace_init(void) { return 0; }
+static inline int kvm_perf_trace_teardown(void) { return 0; }
+#else
+int kvm_perf_trace_init(void);
+int kvm_perf_trace_teardown(void);
+#endif
+
void kvm_mmu_wp_memory_region(struct kvm *kvm, int slot);
struct kvm_vcpu *kvm_mpidr_to_vcpu(struct kvm *kvm, unsigned long mpidr);
diff --git a/arch/arm/kvm/Kconfig b/arch/arm/kvm/Kconfig
index 3e1cd04..f7d1020 100644
--- a/arch/arm/kvm/Kconfig
+++ b/arch/arm/kvm/Kconfig
@@ -16,6 +16,9 @@ menuconfig VIRTUALIZATION
if VIRTUALIZATION
+config KVM_PERF_TRACE
+ bool
+
config KVM
bool "Kernel-based Virtual Machine (KVM) support"
depends on MMU && OF
@@ -34,6 +37,7 @@ config KVM
select HAVE_KVM_IRQFD
select HAVE_KVM_IRQCHIP
select HAVE_KVM_IRQ_ROUTING
+ select KVM_PERF_TRACE if EVENT_TRACING && PERF_EVENTS
depends on ARM_VIRT_EXT && ARM_LPAE && ARM_ARCH_TIMER
---help---
Support hosting virtualized guest machines.
diff --git a/arch/arm/kvm/Makefile b/arch/arm/kvm/Makefile
index f19842e..cc3c811 100644
--- a/arch/arm/kvm/Makefile
+++ b/arch/arm/kvm/Makefile
@@ -22,6 +22,7 @@ obj-y += kvm-arm.o init.o interrupts.o
obj-y += arm.o handle_exit.o guest.o mmu.o emulate.o reset.o
obj-y += coproc.o coproc_a15.o coproc_a7.o mmio.o psci.o perf.o
obj-y += $(KVM)/arm/aarch32.o
+obj-$(CONFIG_KVM_PERF_TRACE) += $(KVM)/arm/perf_trace.o
obj-y += $(KVM)/arm/vgic/vgic.o
obj-y += $(KVM)/arm/vgic/vgic-init.o
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 08bb84f..b5b0b63 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -1232,6 +1232,7 @@ static int init_subsystems(void)
goto out;
kvm_perf_init();
+ kvm_perf_trace_init();
kvm_coproc_table_init();
out:
@@ -1422,6 +1423,7 @@ int kvm_arch_init(void *opaque)
void kvm_arch_exit(void)
{
kvm_perf_teardown();
+ kvm_perf_trace_teardown();
}
static int arm_init(void)
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index bd94e67..582d381 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -345,6 +345,14 @@ int handle_exit(struct kvm_vcpu *vcpu, struct kvm_run *run,
int kvm_perf_init(void);
int kvm_perf_teardown(void);
+#if !defined(CONFIG_KVM_PERF_TRACE)
+static inline int kvm_perf_trace_init(void) { return 0; }
+static inline int kvm_perf_trace_teardown(void) { return 0; }
+#else
+int kvm_perf_trace_init(void);
+int kvm_perf_trace_teardown(void);
+#endif
+
struct kvm_vcpu *kvm_mpidr_to_vcpu(struct kvm *kvm, unsigned long mpidr);
static inline void __cpu_init_hyp_mode(phys_addr_t pgd_ptr,
diff --git a/arch/arm64/kvm/Kconfig b/arch/arm64/kvm/Kconfig
index 6eaf12c..3618dfc 100644
--- a/arch/arm64/kvm/Kconfig
+++ b/arch/arm64/kvm/Kconfig
@@ -19,6 +19,9 @@ if VIRTUALIZATION
config KVM_ARM_VGIC_V3_ITS
bool
+config KVM_PERF_TRACE
+ bool
+
config KVM
bool "Kernel-based Virtual Machine (KVM) support"
depends on OF
@@ -39,6 +42,7 @@ config KVM
select HAVE_KVM_MSI
select HAVE_KVM_IRQCHIP
select HAVE_KVM_IRQ_ROUTING
+ select KVM_PERF_TRACE if EVENT_TRACING && PERF_EVENTS
---help---
Support hosting virtualized guest machines.
We don't support KVM with 16K page tables yet, due to the multiple
diff --git a/arch/arm64/kvm/Makefile b/arch/arm64/kvm/Makefile
index d50a82a..0c2d925 100644
--- a/arch/arm64/kvm/Makefile
+++ b/arch/arm64/kvm/Makefile
@@ -20,6 +20,7 @@ kvm-$(CONFIG_KVM_ARM_HOST) += inject_fault.o regmap.o
kvm-$(CONFIG_KVM_ARM_HOST) += hyp.o hyp-init.o handle_exit.o
kvm-$(CONFIG_KVM_ARM_HOST) += guest.o debug.o reset.o sys_regs.o sys_regs_generic_v8.o
kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/aarch32.o
+kvm-$(CONFIG_KVM_PERF_TRACE) += $(KVM)/arm/perf_trace.o
kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic.o
kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic-init.o
diff --git a/virt/kvm/arm/perf_trace.c b/virt/kvm/arm/perf_trace.c
new file mode 100644
index 0000000..1cafbc9
--- /dev/null
+++ b/virt/kvm/arm/perf_trace.c
@@ -0,0 +1,122 @@
+/*
+ * Copyright (C) 2016 ARM Ltd.
+ * Author: Punit Agrawal <punit.agrawal@arm.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+#include <linux/kvm_host.h>
+#include <linux/trace_events.h>
+
+typedef int (*perf_trace_callback_fn)(struct kvm *kvm, bool enable);
+
+struct kvm_trace_hook {
+ char *key; /* Name of the tracepoint to match */
+ perf_trace_callback_fn setup_fn;
+};
+
+static struct kvm_trace_hook trace_hook[] = {
+ { },
+};
+
+static perf_trace_callback_fn find_trace_callback(const char *trace_key)
+{
+ int i;
+
+ for (i = 0; trace_hook[i].key; i++)
+ if (!strcmp(trace_key, trace_hook[i].key))
+ return trace_hook[i].setup_fn;
+
+ return NULL;
+}
+
+static int kvm_perf_trace_notifier(struct notifier_block *nb,
+ unsigned long event, void *data)
+{
+ struct perf_event *p_event = data;
+ struct trace_event_call *tp_event = p_event->tp_event;
+ perf_trace_callback_fn setup_trace_fn;
+ struct kvm *kvm = NULL;
+ struct pid *pid;
+ bool found = false;
+
+ /*
+ * Is this a trace point?
+ */
+ if (!(tp_event->flags & TRACE_EVENT_FL_TRACEPOINT))
+ goto out;
+
+ /*
+ * We'll get here for events we care to monitor for KVM. As we
+ * only care about events attached to a VM, check that there
+ * is a task associated with the perf event.
+ */
+ if (p_event->attach_state != PERF_ATTACH_TASK)
+ goto out;
+
+ /*
+ * This notifier gets called when perf trace event instance is
+ * added or removed. Until we can restrict this to events of
+ * interest in core, minimise the overhead below.
+ *
+ * Do we care about it? i.e., is there a callback for this
+ * trace point?
+ */
+ setup_trace_fn = find_trace_callback(tp_event->tp->name);
+ if (!setup_trace_fn)
+ goto out;
+
+ pid = get_task_pid(p_event->hw.target, PIDTYPE_PID);
+
+ /*
+ * Does it match any of the VMs?
+ */
+ spin_lock(&kvm_lock);
+ list_for_each_entry(kvm, &vm_list, vm_list) {
+ if (kvm->pid == pid) {
+ found = true;
+ break;
+ }
+ }
+ spin_unlock(&kvm_lock);
+
+ put_pid(pid);
+ if (!found)
+ goto out;
+
+ switch (event) {
+ case TRACE_REG_PERF_OPEN:
+ setup_trace_fn(kvm, true);
+ break;
+
+ case TRACE_REG_PERF_CLOSE:
+ setup_trace_fn(kvm, false);
+ break;
+ }
+
+out:
+ return 0;
+}
+
+static struct notifier_block kvm_perf_trace_notifier_block = {
+ .notifier_call = kvm_perf_trace_notifier,
+};
+
+int kvm_perf_trace_init(void)
+{
+ return perf_trace_notifier_register(&kvm_perf_trace_notifier_block);
+}
+
+int kvm_perf_trace_teardown(void)
+{
+ return perf_trace_notifier_unregister(&kvm_perf_trace_notifier_block);
+}
--
2.9.3
^ permalink raw reply related
* [PATCH v2 3/8] perf/trace: Add notification for perf trace events
From: Punit Agrawal @ 2016-10-26 17:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026174148.17172-1-punit.agrawal@arm.com>
Add a mechanism to notify listeners about perf trace event state
changes. This enables listeners to take actions requiring the event
context (e.g., attached process).
The notification mechanism can be used to reduce trace point based
profiling overhead by enabling/disabling hardware traps for specific
contexts (e.g., virtual machines).
Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jiri Olsa <jolsa@kernel.org>
---
include/linux/trace_events.h | 3 +++
kernel/trace/trace_event_perf.c | 24 ++++++++++++++++++++++++
2 files changed, 27 insertions(+)
diff --git a/include/linux/trace_events.h b/include/linux/trace_events.h
index be00761..5924032 100644
--- a/include/linux/trace_events.h
+++ b/include/linux/trace_events.h
@@ -505,6 +505,9 @@ perf_trace_buf_submit(void *raw_data, int size, int rctx, u16 type,
{
perf_tp_event(type, count, raw_data, size, regs, head, rctx, task);
}
+
+extern int perf_trace_notifier_register(struct notifier_block *nb);
+extern int perf_trace_notifier_unregister(struct notifier_block *nb);
#endif
#endif /* _LINUX_TRACE_EVENT_H */
diff --git a/kernel/trace/trace_event_perf.c b/kernel/trace/trace_event_perf.c
index 562fa69..9aaaacf 100644
--- a/kernel/trace/trace_event_perf.c
+++ b/kernel/trace/trace_event_perf.c
@@ -6,10 +6,12 @@
*/
#include <linux/module.h>
+#include <linux/notifier.h>
#include <linux/kprobes.h>
#include "trace.h"
static char __percpu *perf_trace_buf[PERF_NR_CONTEXTS];
+static RAW_NOTIFIER_HEAD(perf_trace_notifier_list);
/*
* Force it to be aligned to unsigned long to avoid misaligned accesses
@@ -86,6 +88,26 @@ static int perf_trace_event_perm(struct trace_event_call *tp_event,
return 0;
}
+int perf_trace_notifier_register(struct notifier_block *nb)
+{
+ return raw_notifier_chain_register(&perf_trace_notifier_list, nb);
+}
+
+int perf_trace_notifier_unregister(struct notifier_block *nb)
+{
+ return raw_notifier_chain_unregister(&perf_trace_notifier_list, nb);
+}
+
+static void perf_trace_notify(enum trace_reg event, struct perf_event *p_event)
+{
+ /*
+ * We use raw notifiers here as we are called with the
+ * event_mutex held.
+ */
+ raw_notifier_call_chain(&perf_trace_notifier_list,
+ event, p_event);
+}
+
static int perf_trace_event_reg(struct trace_event_call *tp_event,
struct perf_event *p_event)
{
@@ -176,6 +198,7 @@ static void perf_trace_event_unreg(struct perf_event *p_event)
static int perf_trace_event_open(struct perf_event *p_event)
{
struct trace_event_call *tp_event = p_event->tp_event;
+ perf_trace_notify(TRACE_REG_PERF_OPEN, p_event);
return tp_event->class->reg(tp_event, TRACE_REG_PERF_OPEN, p_event);
}
@@ -183,6 +206,7 @@ static void perf_trace_event_close(struct perf_event *p_event)
{
struct trace_event_call *tp_event = p_event->tp_event;
tp_event->class->reg(tp_event, TRACE_REG_PERF_CLOSE, p_event);
+ perf_trace_notify(TRACE_REG_PERF_CLOSE, p_event);
}
static int perf_trace_event_init(struct trace_event_call *tp_event,
--
2.9.3
^ permalink raw reply related
* [PATCH v2 2/8] KVM: Track the pid of the VM process
From: Punit Agrawal @ 2016-10-26 17:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026174148.17172-1-punit.agrawal@arm.com>
Userspace tools such as perf can be used to profile individual
processes.
Track the PID of the virtual machine process to match profiling requests
targeted at it. This can be used to take appropriate action to enable
the requested profiling operations for the VMs of interest.
Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Radim Kr?m??" <rkrcmar@redhat.com>
Cc: Christoffer Dall <christoffer.dall@linaro.org>
Cc: Marc Zyngier <marc.zyngier@arm.com>
---
include/linux/kvm_host.h | 1 +
virt/kvm/kvm_main.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 01c0b9c..4caff20 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -375,6 +375,7 @@ struct kvm_memslots {
struct kvm {
spinlock_t mmu_lock;
struct mutex slots_lock;
+ struct pid *pid;
struct mm_struct *mm; /* userspace tied to this vm */
struct kvm_memslots *memslots[KVM_ADDRESS_SPACE_NUM];
struct srcu_struct srcu;
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 28510e7..ed3823c 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -615,6 +615,7 @@ static struct kvm *kvm_create_vm(unsigned long type)
spin_lock_init(&kvm->mmu_lock);
atomic_inc(¤t->mm->mm_count);
kvm->mm = current->mm;
+ kvm->pid = get_task_pid(current->group_leader, PIDTYPE_PID);
kvm_eventfd_init(kvm);
mutex_init(&kvm->lock);
mutex_init(&kvm->irq_lock);
@@ -714,6 +715,7 @@ static void kvm_destroy_vm(struct kvm *kvm)
int i;
struct mm_struct *mm = kvm->mm;
+ put_pid(kvm->pid);
kvm_destroy_vm_debugfs(kvm);
kvm_arch_sync_events(kvm);
spin_lock(&kvm_lock);
--
2.9.3
^ permalink raw reply related
* [PATCH v2 1/8] arm64/kvm: hyp: tlb: use __tlbi() helper
From: Punit Agrawal @ 2016-10-26 17:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026174148.17172-1-punit.agrawal@arm.com>
From: Mark Rutland <mark.rutland@arm.com>
Now that we have a __tlbi() helper, make use of this in the arm64 KVM hyp
code to get rid of asm() boilerplate. At the same time, we simplify
__tlb_flush_vm_context by using __flush_icache_all(), as this has the
appropriate instruction cache maintenance and barrier.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
[ rename tlbi -> __tlbi, convert additional sites, update commit log ]
Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
Acked-by: Christoffer Dall <christoffer.dall@linaro.org>
---
arch/arm64/kvm/hyp/tlb.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/kvm/hyp/tlb.c b/arch/arm64/kvm/hyp/tlb.c
index 9cc0ea7..74eb562 100644
--- a/arch/arm64/kvm/hyp/tlb.c
+++ b/arch/arm64/kvm/hyp/tlb.c
@@ -16,6 +16,7 @@
*/
#include <asm/kvm_hyp.h>
+#include <asm/tlbflush.h>
void __hyp_text __kvm_tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa)
{
@@ -32,7 +33,7 @@ void __hyp_text __kvm_tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa)
* whole of Stage-1. Weep...
*/
ipa >>= 12;
- asm volatile("tlbi ipas2e1is, %0" : : "r" (ipa));
+ __tlbi(ipas2e1is, ipa);
/*
* We have to ensure completion of the invalidation at Stage-2,
@@ -41,7 +42,7 @@ void __hyp_text __kvm_tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa)
* the Stage-1 invalidation happened first.
*/
dsb(ish);
- asm volatile("tlbi vmalle1is" : : );
+ __tlbi(vmalle1is);
dsb(ish);
isb();
@@ -57,7 +58,7 @@ void __hyp_text __kvm_tlb_flush_vmid(struct kvm *kvm)
write_sysreg(kvm->arch.vttbr, vttbr_el2);
isb();
- asm volatile("tlbi vmalls12e1is" : : );
+ __tlbi(vmalls12e1is);
dsb(ish);
isb();
@@ -67,7 +68,6 @@ void __hyp_text __kvm_tlb_flush_vmid(struct kvm *kvm)
void __hyp_text __kvm_flush_vm_context(void)
{
dsb(ishst);
- asm volatile("tlbi alle1is \n"
- "ic ialluis ": : );
- dsb(ish);
+ __tlbi(alle1is);
+ __flush_icache_all(); /* contains a dsb(ish) */
}
--
2.9.3
^ permalink raw reply related
* [PATCH v2 0/8] Add support for monitoring guest TLB operations
From: Punit Agrawal @ 2016-10-26 17:41 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This is the fourth posting of this series. The biggest change compared
to previous vesion is the addition of support for ARM hosts. With the
addition of ARM support, the patchset is now more complete. Prior
versions can be found at [0][1][2].
I would particularly appreciate feedback from maintainers on the
approach to tie the control of TLB monitoring with perf trace events
(Patch 3 and 4) especially if there are any suggestions on avoiding
(or reducing) the overhead of "perf trace" notifications.
I looked at using regfunc/unregfunc tracepoint hooks but they don't
include the event context. But the bigger problem was that the
callbacks are only called on the first instance of simultaneously
executing perf stat invocations.
Changelog and previous cover-letter follows.
Changes:
v1 -> v2
* New (Patch 6) - Add support for trapping and emulating TLB
operations to ARM hosts
* Move common code to handle perf trace notifications to virt/kvm/arm
* Move tracepoint to include/trace/events/kvm.h
* Drop patch to introduce __tlbi helper as it is now merged
* Reorder patches
RFC v2 -> v1
* Dropped the RFC tag
* Patch 2 - Use VM thread group id for identification
* Patch 4 - Update comment for clarity
* Patch 6 - Add comment explaining switch to hype-role when VHE is enabled
* Patch 7 - Add comment to clarify struct kvm_trace_hook
RFC -> RFC v2
* Patch 4 - Rename left-over TLBI macro to __TLBI
* Patch 6 - Replace individual TLB operation emulation with
invalidating all stage 1 TLB for the VM. TLB monitoring is expected
to be a debug feature and performance is not critical.
Although there are no PMU events to monitor TLB operations, ARMv8
supports trapping guest TLB maintenance operations to the
hypervisor. This trapping mechanism can be used to monitor the use of
guest TLB instructions.
As taking a trap for every TLB operation can have significant
overhead, trapping should only be enabled -
* on user request
* for the VM of interest
This patchset adds support to listen to perf trace event state change
notifications. The notifications and associated context are then used
to enable trapping of guest TLB operations when requested by the
user. The trap handling generates trace events (kvm_tlb_invalidate)
which can already be counted using existing perf trace functionality.
With this patchset, 'perf' tool when attached to a VM process can be
used to monitor the TLB operations. E.g., to monitor a VM with process
id 4166 -
# perf stat -e "kvm:kvm_tlb_invalidate" -p 4166
Perform some operations in VM (running 'make -j 7' on the kernel
sources in this instance). Breaking out of perf shows -
Performance counter stats for process id '4166':
7,471,974 kvm:kvm_tlb_invalidate
374.235405282 seconds time elapsed
Thanks,
Punit
[0] http://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1210715.html
[1] http://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1224353.html
[2] https://marc.info/?l=linux-kernel&m=147376184208258&w=2
Mark Rutland (1):
arm64/kvm: hyp: tlb: use __tlbi() helper
Punit Agrawal (7):
KVM: Track the pid of the VM process
perf/trace: Add notification for perf trace events
KVM: arm/arm64: Register perf trace event notifier
KVM: Add event to trace tlb invalidations
arm: KVM: Handle trappable TLB instructions
arm64: KVM: Handle trappable TLB instructions
KVM: arm/arm64: Enable selective trapping of TLB instructions
arch/arm/include/asm/kvm_asm.h | 1 +
arch/arm/include/asm/kvm_host.h | 8 ++
arch/arm/kvm/Kconfig | 4 +
arch/arm/kvm/Makefile | 1 +
arch/arm/kvm/arm.c | 2 +
arch/arm/kvm/coproc.c | 55 ++++++++++++++
arch/arm/kvm/hyp/tlb.c | 33 ++++++++
arch/arm64/include/asm/kvm_asm.h | 1 +
arch/arm64/include/asm/kvm_host.h | 8 ++
arch/arm64/kvm/Kconfig | 4 +
arch/arm64/kvm/Makefile | 1 +
arch/arm64/kvm/hyp/tlb.c | 87 +++++++++++++++++++--
arch/arm64/kvm/sys_regs.c | 81 ++++++++++++++++++++
include/linux/kvm_host.h | 1 +
include/linux/trace_events.h | 3 +
include/trace/events/kvm.h | 17 +++++
kernel/trace/trace_event_perf.c | 24 ++++++
virt/kvm/arm/perf_trace.c | 154 ++++++++++++++++++++++++++++++++++++++
virt/kvm/kvm_main.c | 2 +
19 files changed, 481 insertions(+), 6 deletions(-)
create mode 100644 virt/kvm/arm/perf_trace.c
--
2.9.3
^ permalink raw reply
* [PATCH 2/2] ARM: bus: da8xx-mstpri: new driver
From: Bartosz Golaszewski @ 2016-10-26 17:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477503355-2600-1-git-send-email-bgolaszewski@baylibre.com>
Create the driver for the da8xx master peripheral priority
configuration and implement support for writing to the three
Master Priority registers on da850 SoCs.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
.../devicetree/bindings/bus/ti,da850-mstpri.txt | 20 ++
drivers/bus/Kconfig | 9 +
drivers/bus/Makefile | 2 +
drivers/bus/da8xx-mstpri.c | 266 +++++++++++++++++++++
4 files changed, 297 insertions(+)
create mode 100644 Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt
create mode 100644 drivers/bus/da8xx-mstpri.c
diff --git a/Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt b/Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt
new file mode 100644
index 0000000..225af09
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt
@@ -0,0 +1,20 @@
+* Device tree bindings for Texas Instruments da8xx master peripheral
+ priority driver
+
+DA8XX SoCs feature a set of registers allowing to change the priority of all
+peripherals classified as masters.
+
+Documentation:
+OMAP-L138 (DA850) - http://www.ti.com/lit/ug/spruh82c/spruh82c.pdf
+
+Required properties:
+
+- compatible: "ti,da850-mstpri", "syscon" - for da850 based boards
+- reg: offset and length of the mstpri registers
+
+Example for da850-lcdk is shown below.
+
+mstpri {
+ compatible = "ti,da850-mstpri";
+ reg = <0x14110 0x0c>;
+};
diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
index 7010dca..ed6a89c 100644
--- a/drivers/bus/Kconfig
+++ b/drivers/bus/Kconfig
@@ -166,4 +166,13 @@ config VEXPRESS_CONFIG
help
Platform configuration infrastructure for the ARM Ltd.
Versatile Express.
+
+config DA8XX_MSTPRI
+ bool "TI da8xx master peripheral priority driver"
+ depends on ARCH_DAVINCI_DA8XX
+ help
+ Driver for Texas Instruments da8xx master peripheral priority
+ configuration. Allows to adjust the priorities of all master
+ peripherals.
+
endmenu
diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile
index c6cfa6b..2adb540 100644
--- a/drivers/bus/Makefile
+++ b/drivers/bus/Makefile
@@ -21,3 +21,5 @@ obj-$(CONFIG_SIMPLE_PM_BUS) += simple-pm-bus.o
obj-$(CONFIG_TEGRA_ACONNECT) += tegra-aconnect.o
obj-$(CONFIG_UNIPHIER_SYSTEM_BUS) += uniphier-system-bus.o
obj-$(CONFIG_VEXPRESS_CONFIG) += vexpress-config.o
+
+obj-$(CONFIG_DA8XX_MSTPRI) += da8xx-mstpri.o
diff --git a/drivers/bus/da8xx-mstpri.c b/drivers/bus/da8xx-mstpri.c
new file mode 100644
index 0000000..00c4f83
--- /dev/null
+++ b/drivers/bus/da8xx-mstpri.c
@@ -0,0 +1,266 @@
+/*
+ * TI da8xx master peripheral priority driver
+ *
+ * Copyright (C) 2016 BayLibre SAS
+ *
+ * Author:
+ * Bartosz Golaszewski <bgolaszewski@baylibre.com.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/io.h>
+#include <linux/regmap.h>
+#include <linux/mfd/syscon.h>
+#include <linux/of_fdt.h>
+
+/*
+ * REVISIT: Linux doesn't have a good framework for the kind of performance
+ * knobs this driver controls. We can't use device tree properties as it deals
+ * with hardware configuration rather than description. We also don't want to
+ * commit to maintaining some random sysfs attributes.
+ *
+ * For now we just hardcode the register values for the boards that need
+ * some changes (as is the case for the LCD controller on da850-lcdk - the
+ * first board we support here). When linux gets an appropriate framework,
+ * we'll easily convert the driver to it.
+ */
+
+#define DA8XX_MSTPRI0_OFFSET 0
+#define DA8XX_MSTPRI1_OFFSET 4
+#define DA8XX_MSTPRI2_OFFSET 8
+
+enum {
+ DA8XX_MSTPRI_ARM_I = 0,
+ DA8XX_MSTPRI_ARM_D,
+ DA8XX_MSTPRI_UPP,
+ DA8XX_MSTPRI_SATA,
+ DA8XX_MSTPRI_PRU0,
+ DA8XX_MSTPRI_PRU1,
+ DA8XX_MSTPRI_EDMA30TC0,
+ DA8XX_MSTPRI_EDMA30TC1,
+ DA8XX_MSTPRI_EDMA31TC0,
+ DA8XX_MSTPRI_VPIF_DMA_0,
+ DA8XX_MSTPRI_VPIF_DMA_1,
+ DA8XX_MSTPRI_EMAC,
+ DA8XX_MSTPRI_USB0CFG,
+ DA8XX_MSTPRI_USB0CDMA,
+ DA8XX_MSTPRI_UHPI,
+ DA8XX_MSTPRI_USB1,
+ DA8XX_MSTPRI_LCDC,
+};
+
+struct da8xx_mstpri_descr {
+ int reg;
+ int shift;
+ int mask;
+};
+
+static const struct da8xx_mstpri_descr da8xx_mstpri_priority_list[] = {
+ [DA8XX_MSTPRI_ARM_I] = {
+ .reg = DA8XX_MSTPRI0_OFFSET,
+ .shift = 0,
+ .mask = 0x0000000f,
+ },
+ [DA8XX_MSTPRI_ARM_D] = {
+ .reg = DA8XX_MSTPRI0_OFFSET,
+ .shift = 4,
+ .mask = 0x000000f0,
+ },
+ [DA8XX_MSTPRI_UPP] = {
+ .reg = DA8XX_MSTPRI0_OFFSET,
+ .shift = 16,
+ .mask = 0x000f0000,
+ },
+ [DA8XX_MSTPRI_SATA] = {
+ .reg = DA8XX_MSTPRI0_OFFSET,
+ .shift = 20,
+ .mask = 0x00f00000,
+ },
+ [DA8XX_MSTPRI_PRU0] = {
+ .reg = DA8XX_MSTPRI1_OFFSET,
+ .shift = 0,
+ .mask = 0x0000000f,
+ },
+ [DA8XX_MSTPRI_PRU1] = {
+ .reg = DA8XX_MSTPRI1_OFFSET,
+ .shift = 4,
+ .mask = 0x000000f0,
+ },
+ [DA8XX_MSTPRI_EDMA30TC0] = {
+ .reg = DA8XX_MSTPRI1_OFFSET,
+ .shift = 8,
+ .mask = 0x00000f00,
+ },
+ [DA8XX_MSTPRI_EDMA30TC1] = {
+ .reg = DA8XX_MSTPRI1_OFFSET,
+ .shift = 12,
+ .mask = 0x0000f000,
+ },
+ [DA8XX_MSTPRI_EDMA31TC0] = {
+ .reg = DA8XX_MSTPRI1_OFFSET,
+ .shift = 16,
+ .mask = 0x000f0000,
+ },
+ [DA8XX_MSTPRI_VPIF_DMA_0] = {
+ .reg = DA8XX_MSTPRI1_OFFSET,
+ .shift = 24,
+ .mask = 0x0f000000,
+ },
+ [DA8XX_MSTPRI_VPIF_DMA_1] = {
+ .reg = DA8XX_MSTPRI1_OFFSET,
+ .shift = 28,
+ .mask = 0xf0000000,
+ },
+ [DA8XX_MSTPRI_EMAC] = {
+ .reg = DA8XX_MSTPRI2_OFFSET,
+ .shift = 0,
+ .mask = 0x0000000f,
+ },
+ [DA8XX_MSTPRI_USB0CFG] = {
+ .reg = DA8XX_MSTPRI2_OFFSET,
+ .shift = 8,
+ .mask = 0x00000f00,
+ },
+ [DA8XX_MSTPRI_USB0CDMA] = {
+ .reg = DA8XX_MSTPRI2_OFFSET,
+ .shift = 12,
+ .mask = 0x0000f000,
+ },
+ [DA8XX_MSTPRI_UHPI] = {
+ .reg = DA8XX_MSTPRI2_OFFSET,
+ .shift = 20,
+ .mask = 0x00f00000,
+ },
+ [DA8XX_MSTPRI_USB1] = {
+ .reg = DA8XX_MSTPRI2_OFFSET,
+ .shift = 24,
+ .mask = 0x0f000000,
+ },
+ [DA8XX_MSTPRI_LCDC] = {
+ .reg = DA8XX_MSTPRI2_OFFSET,
+ .shift = 28,
+ .mask = 0xf0000000,
+ },
+};
+
+struct da8xx_mstpri_priority {
+ int which;
+ u32 val;
+};
+
+struct da8xx_mstpri_board_priorities {
+ const char *board;
+ const struct da8xx_mstpri_priority *priorities;
+ size_t numprio;
+};
+
+/*
+ * Default memory settings of da850 do not meet the throughput/latency
+ * requirements of tilcdc. This results in the image displayed being
+ * incorrect and the following warning being displayed by the LCDC
+ * drm driver:
+ *
+ * tilcdc da8xx_lcdc.0: tilcdc_crtc_irq(0x00000020): FIFO underfow
+ */
+static const struct da8xx_mstpri_priority da850_lcdk_priorities[] = {
+ {
+ .which = DA8XX_MSTPRI_LCDC,
+ .val = 0,
+ },
+ {
+ .which = DA8XX_MSTPRI_EDMA30TC1,
+ .val = 0,
+ },
+ {
+ .which = DA8XX_MSTPRI_EDMA30TC0,
+ .val = 1,
+ },
+};
+
+static const struct da8xx_mstpri_board_priorities da8xx_mstpri_board_confs[] = {
+ {
+ .board = "ti,da850-lcdk",
+ .priorities = da850_lcdk_priorities,
+ .numprio = ARRAY_SIZE(da850_lcdk_priorities),
+ },
+};
+
+static const struct da8xx_mstpri_board_priorities *
+da8xx_mstpri_get_board_prio(void)
+{
+ const struct da8xx_mstpri_board_priorities *board_prio;
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(da8xx_mstpri_board_confs); i++) {
+ board_prio = &da8xx_mstpri_board_confs[i];
+
+ if (of_machine_is_compatible(board_prio->board))
+ return board_prio;
+ }
+
+ return NULL;
+}
+
+static int da8xx_mstpri_probe(struct platform_device *pdev)
+{
+ const struct da8xx_mstpri_board_priorities *prio_list;
+ const struct da8xx_mstpri_descr *prio_descr;
+ const struct da8xx_mstpri_priority *prio;
+ struct device *dev = &pdev->dev;
+ struct regmap *mstpri;
+ int i, ret;
+
+ mstpri = syscon_regmap_lookup_by_compatible("ti,da850-mstpri");
+ if (IS_ERR(mstpri)) {
+ dev_err(dev, "unable to map mstpri registers\n");
+ return PTR_ERR(mstpri);
+ }
+
+ prio_list = da8xx_mstpri_get_board_prio();
+ if (!prio_list) {
+ dev_err(dev, "no master priotities defined for board '%s'\n",
+ of_flat_dt_get_machine_name());
+ return -EINVAL;
+ }
+
+ for (i = 0; i < prio_list->numprio; i++) {
+ prio = &prio_list->priorities[i];
+ prio_descr = &da8xx_mstpri_priority_list[prio->which];
+
+ ret = regmap_update_bits(mstpri, prio_descr->reg,
+ prio_descr->mask,
+ prio->val << prio_descr->shift);
+ if (ret) {
+ dev_warn(dev,
+ "error updating bits for register [%d]: %d\n",
+ prio_descr->reg, ret);
+ continue;
+ }
+ }
+
+ return 0;
+}
+
+static const struct of_device_id da8xx_mstpri_of_match[] = {
+ { .compatible = "ti,da850-mstpri", },
+ { },
+};
+
+static struct platform_driver da8xx_mstpri_driver = {
+ .probe = da8xx_mstpri_probe,
+ .driver = {
+ .name = "da8xx-mstpri",
+ .of_match_table = da8xx_mstpri_of_match,
+ },
+};
+module_platform_driver(da8xx_mstpri_driver);
+
+MODULE_AUTHOR("Bartosz Golaszewski <bgolaszewski@baylibre.com>");
+MODULE_DESCRIPTION("TI da8xx master peripheral priority driver");
+MODULE_LICENSE("GPL v2");
--
2.9.3
^ permalink raw reply related
* [PATCH 1/2] ARM: memory: da8xx-ddrctl: new driver
From: Bartosz Golaszewski @ 2016-10-26 17:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477503355-2600-1-git-send-email-bgolaszewski@baylibre.com>
Create a new driver for the da8xx DDR2/mDDR controller and implement
support for writing to the Peripheral Bus Burst Priority Register.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
.../memory-controllers/ti-da8xx-ddrctl.txt | 20 +++
drivers/memory/Kconfig | 8 +
drivers/memory/Makefile | 1 +
drivers/memory/da8xx-ddrctl.c | 175 +++++++++++++++++++++
4 files changed, 204 insertions(+)
create mode 100644 Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt
create mode 100644 drivers/memory/da8xx-ddrctl.c
diff --git a/Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt b/Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt
new file mode 100644
index 0000000..7e271dd
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt
@@ -0,0 +1,20 @@
+* Device tree bindings for Texas Instruments da8xx DDR2/mDDR memory controller
+
+The DDR2/mDDR memory controller present on Texas Instruments da8xx SoCs features
+a set of registers which allow to tweak the controller's behavior.
+
+Documentation:
+OMAP-L138 (DA850) - http://www.ti.com/lit/ug/spruh82c/spruh82c.pdf
+
+Required properties:
+
+- compatible: "ti,da850-ddr-controller" - for da850 SoC based boards
+- reg: a tuple containing the base address of the memory
+ controller and the size of the memory area to map
+
+Example for da850 shown below.
+
+ddrctl {
+ compatible = "ti,da850-ddr-controller";
+ reg = <0xB0000000 0x100>;
+};
diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
index 4b4c0c3..ec80e35 100644
--- a/drivers/memory/Kconfig
+++ b/drivers/memory/Kconfig
@@ -134,6 +134,14 @@ config MTK_SMI
mainly help enable/disable iommu and control the power domain and
clocks for each local arbiter.
+config DA8XX_DDRCTL
+ bool "Texas Instruments da8xx DDR2/mDDR driver"
+ depends on ARCH_DAVINCI_DA8XX
+ help
+ This driver is for the DDR2/mDDR Memory Controller present on
+ Texas Instruments da8xx SoCs. It's used to tweak various memory
+ controller configuration options.
+
source "drivers/memory/samsung/Kconfig"
source "drivers/memory/tegra/Kconfig"
diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
index b20ae38..e88097fb 100644
--- a/drivers/memory/Makefile
+++ b/drivers/memory/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_MVEBU_DEVBUS) += mvebu-devbus.o
obj-$(CONFIG_TEGRA20_MC) += tegra20-mc.o
obj-$(CONFIG_JZ4780_NEMC) += jz4780-nemc.o
obj-$(CONFIG_MTK_SMI) += mtk-smi.o
+obj-$(CONFIG_DA8XX_DDRCTL) += da8xx-ddrctl.o
obj-$(CONFIG_SAMSUNG_MC) += samsung/
obj-$(CONFIG_TEGRA_MC) += tegra/
diff --git a/drivers/memory/da8xx-ddrctl.c b/drivers/memory/da8xx-ddrctl.c
new file mode 100644
index 0000000..900e131
--- /dev/null
+++ b/drivers/memory/da8xx-ddrctl.c
@@ -0,0 +1,175 @@
+/*
+ * TI da8xx DDR2/mDDR controller driver
+ *
+ * Copyright (C) 2016 BayLibre SAS
+ *
+ * Author:
+ * Bartosz Golaszewski <bgolaszewski@baylibre.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/of_fdt.h>
+#include <linux/platform_device.h>
+#include <linux/io.h>
+
+/*
+ * REVISIT: Linux doesn't have a good framework for the kind of performance
+ * knobs this driver controls. We can't use device tree properties as it deals
+ * with hardware configuration rather than description. We also don't want to
+ * commit to maintaining some random sysfs attributes.
+ *
+ * For now we just hardcode the register values for the boards that need
+ * some changes (as is the case for the LCD controller on da850-lcdk - the
+ * first board we support here). When linux gets an appropriate framework,
+ * we'll easily convert the driver to it.
+ */
+
+struct da8xx_ddrctl_config_knob {
+ const char *name;
+ u32 reg;
+ u32 mask;
+ u32 shift;
+};
+
+static const struct da8xx_ddrctl_config_knob da8xx_ddrctl_knobs[] = {
+ {
+ .name = "da850-pbbpr",
+ .reg = 0x20,
+ .mask = 0xffffff00,
+ .shift = 0,
+ },
+};
+
+struct da8xx_ddrctl_setting {
+ const char *name;
+ u32 val;
+};
+
+struct da8xx_ddrctl_board_settings {
+ const char *board;
+ const struct da8xx_ddrctl_setting *settings;
+};
+
+static const struct da8xx_ddrctl_setting da850_lcdk_ddrctl_settings[] = {
+ {
+ .name = "da850-pbbpr",
+ .val = 0x20,
+ },
+ { }
+};
+
+static const struct da8xx_ddrctl_board_settings da8xx_ddrctl_board_confs[] = {
+ {
+ .board = "ti,da850-lcdk",
+ .settings = da850_lcdk_ddrctl_settings,
+ },
+};
+
+static const struct da8xx_ddrctl_config_knob *
+da8xx_ddrctl_match_knob(const struct da8xx_ddrctl_setting *setting)
+{
+ const struct da8xx_ddrctl_config_knob *knob;
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(da8xx_ddrctl_knobs); i++) {
+ knob = &da8xx_ddrctl_knobs[i];
+
+ if (strcmp(knob->name, setting->name) == 0)
+ return knob;
+ }
+
+ return NULL;
+}
+
+static const struct da8xx_ddrctl_setting *da8xx_ddrctl_get_board_settings(void)
+{
+ const struct da8xx_ddrctl_board_settings *board_settings;
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(da8xx_ddrctl_board_confs); i++) {
+ board_settings = &da8xx_ddrctl_board_confs[i];
+
+ if (of_machine_is_compatible(board_settings->board))
+ return board_settings->settings;
+ }
+
+ return NULL;
+}
+
+static int da8xx_ddrctl_probe(struct platform_device *pdev)
+{
+ const struct da8xx_ddrctl_config_knob *knob;
+ const struct da8xx_ddrctl_setting *setting;
+ struct device_node *node;
+ struct resource *res;
+ void __iomem *ddrctl;
+ struct device *dev;
+ u32 reg;
+
+ dev = &pdev->dev;
+ node = dev->of_node;
+
+ setting = da8xx_ddrctl_get_board_settings();
+ if (!setting) {
+ dev_err(dev, "no settings for board '%s'\n",
+ of_flat_dt_get_machine_name());
+ return -EINVAL;
+ }
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ ddrctl = devm_ioremap_resource(dev, res);
+ if (IS_ERR(ddrctl)) {
+ dev_err(dev, "unable to map memory controller registers\n");
+ return PTR_ERR(ddrctl);
+ }
+
+ for (; setting->name; setting++) {
+ knob = da8xx_ddrctl_match_knob(setting);
+ if (!knob) {
+ dev_warn(dev,
+ "no such config option: %s\n", setting->name);
+ continue;
+ }
+
+ if (knob->reg > (res->end - res->start - sizeof(u32))) {
+ dev_warn(dev,
+ "register offset of '%s' exceeds mapped memory size\n",
+ knob->name);
+ continue;
+ }
+
+ reg = __raw_readl(ddrctl + knob->reg);
+ reg &= knob->mask;
+ reg |= setting->val << knob->shift;
+
+ dev_dbg(dev, "writing 0x%08x to %s\n", reg, setting->name);
+
+ __raw_writel(reg, ddrctl + knob->reg);
+ }
+
+ return 0;
+}
+
+static const struct of_device_id da8xx_ddrctl_of_match[] = {
+ { .compatible = "ti,da850-ddr-controller", },
+ { },
+};
+
+static struct platform_driver da8xx_ddrctl_driver = {
+ .probe = da8xx_ddrctl_probe,
+ .driver = {
+ .name = "da850-ddr-controller",
+ .of_match_table = da8xx_ddrctl_of_match,
+ },
+};
+module_platform_driver(da8xx_ddrctl_driver);
+
+MODULE_AUTHOR("Bartosz Golaszewski <bgolaszewski@baylibre.com>");
+MODULE_DESCRIPTION("TI da8xx DDR2/mDDR controller driver");
+MODULE_LICENSE("GPL v2");
--
2.9.3
^ permalink raw reply related
* [PATCH 0/2] ARM: da850: new drivers for better LCDC support
From: Bartosz Golaszewski @ 2016-10-26 17:35 UTC (permalink / raw)
To: linux-arm-kernel
This series adds two new drivers in order to better support the LCDC
rev1 present on the da850 boards.
The first patch adds a new memory driver which allows to write to the
DDR2/mDDR memory controller present on the da8xx SoCs. Since the
memory controller region is not mapped by anyone else, I went with
platform_get_resource() and ioremap() approach.
The second patch adds a new bus driver which allows to interact with
the MSTPRI registers of the SYSCFG0 module. The SYSCFG0 registers
are used by many drivers, hence the syscon/regmap approach.
As is mentioned in the comments: we don't want to commit to supporting
stable interfaces (DT bindings or sysfs attributes) so we hardcode the
settings required by some boards (for now only da850-lcdk) with the
hope that linux gets an appropriate framework for performance knobs
in the future.
Potential extensions of these drivers should be straightforward in the
future.
Tested on a da850-lcdk with a display connected over VGA and some
additional work on the tilcdc driver.
NOTE I'm sending this as v1, but it's a follow-up to a series I sent
previously and the RFC with the ddrctl driver. I dropped the dt patch
for now.
Bartosz Golaszewski (2):
ARM: memory: da8xx-ddrctl: new driver
ARM: bus: da8xx-mstpri: new driver
.../devicetree/bindings/bus/ti,da850-mstpri.txt | 20 ++
.../memory-controllers/ti-da8xx-ddrctl.txt | 20 ++
drivers/bus/Kconfig | 9 +
drivers/bus/Makefile | 2 +
drivers/bus/da8xx-mstpri.c | 266 +++++++++++++++++++++
drivers/memory/Kconfig | 8 +
drivers/memory/Makefile | 1 +
drivers/memory/da8xx-ddrctl.c | 175 ++++++++++++++
8 files changed, 501 insertions(+)
create mode 100644 Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt
create mode 100644 Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt
create mode 100644 drivers/bus/da8xx-mstpri.c
create mode 100644 drivers/memory/da8xx-ddrctl.c
--
2.9.3
^ permalink raw reply
* [PATCH v3] drivers: psci: PSCI checker module
From: Lorenzo Pieralisi @ 2016-10-26 17:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026172252.GV3716@linux.vnet.ibm.com>
On Wed, Oct 26, 2016 at 10:22:52AM -0700, Paul E. McKenney wrote:
> On Wed, Oct 26, 2016 at 06:10:06PM +0100, Lorenzo Pieralisi wrote:
> > On Wed, Oct 26, 2016 at 08:18:58AM -0700, Paul E. McKenney wrote:
> > > On Wed, Oct 26, 2016 at 02:17:52PM +0100, Lorenzo Pieralisi wrote:
> > > > On Tue, Oct 25, 2016 at 11:34:36AM -0700, Paul E. McKenney wrote:
> > > >
> > > > [...]
> > > >
> > > > > > > +static int __init psci_checker(void)
> > > > > > > +{
> > > > > > > + int ret;
> > > > > > > +
> > > > > > > + /*
> > > > > > > + * Since we're in an initcall, we assume that all the CPUs that all
> > > > > > > + * CPUs that can be onlined have been onlined.
> > > > > > > + *
> > > > > > > + * The tests assume that hotplug is enabled but nobody else is using it,
> > > > > > > + * otherwise the results will be unpredictable. However, since there
> > > > > > > + * is no userspace yet in initcalls, that should be fine.
> > > > > >
> > > > > > I do not think it is. If you run a kernel with, say,
> > > > > > CONFIG_LOCK_TORTURE_TEST, cpus may disappear from the radar while
> > > > > > running the PSCI checker test itself; that at least would confuse the
> > > > > > checker, and that's just an example.
> > > > > >
> > > > > > I added Paul to check what are the assumptions behind the torture test
> > > > > > hotplug tests, in particular if there are any implicit assumptions for
> > > > > > it to work (ie it is the only kernel test hotplugging cpus in and out
> > > > > > (?)), what I know is that the PSCI checker assumptions are not correct.
> > > > >
> > > > > Both CONFIG_LOCK_TORTURE_TEST and CONFIG_RCU_TORTURE_TEST can and will
> > > > > hotplug CPUs. The locktorture.onoff_holdoff and rcutorture.onoff_holdoff
> > > > > kernel parameters can delay the start of CPU-hotplug testing, and in
> > > > > my testing I set this delay to 30 seconds after boot.
> > > > >
> > > > > One approach would be to make your test refuse to run if either of
> > > > > the lock/RCU torture tests was running. Or do what Lorenzo suggests
> > > > > below. The torture tests aren't crazy enough to offline the last CPU.
> > > > > Though they do try, just for effect, in cases where the last CPU is
> > > > > marked cpu_is_hotpluggable(). ;-)
> > > >
> > > > Thank you Paul. I have an additional question though. Is there any
> > > > implicit assumption in LOCK/RCU torture tests whereby nothing else
> > > > in the kernel is hotplugging cpus in/out (through cpu_down()/up())
> > > > while they are running ?
> > > >
> > > > I am asking because that's the main reason behind my query. Those tests
> > > > hotplug cpus in and out through cpu_down/up() but AFAICS nothing
> > > > prevents another piece of code in the kernel to call those functions and
> > > > the tests may just fail in that case (ie trying to cpu_down() a cpu
> > > > that is not online).
> > > >
> > > > Are false negatives contemplated (or I am missing something) ?
> > >
> > > The current code assumes nothing else doing CPU-hotplug operations,
> > > and will therefore print "RCU_HOTPLUG" error (or "LOCK_HOTPLUG" for
> > > locktorture) if any of the hotplug operations failed.
> > >
> > > > I just would like to understand if what this patch currently does
> > > > is safe and sound. I think that calling cpu_down() and cpu_up()
> > > > is always safe, but the test can result in false negatives if
> > > > other kernel subsystems (eg LOCK torture test) are calling those
> > > > APIs in parallel (because cpu_down()/cpu_up() calls can fail - eg
> > > > trying to cpu_down() a cpu that is not online any longer, since it
> > > > was taken down by another kernel control path), that's the question
> > > > I have.
> > >
> > > I am assuming that these added calls to cpu_down() and cpu_up() aren't
> > > enabled by default. If they are, rcutorture and locktorture need some
> > > way to turn the off.
> > >
> > > So maybe we need to have some sort of API that detects concurrent
> > > CPU-hotplug torturing? Maybe something like the following?
> > >
> > > static atomic_t n_cpu_hotplug_torturers;
> > > static atomic_t cpu_hotplug_concurrent_torture;
> > >
> > > void torture_start_cpu_hotplug(void)
> > > {
> > > if (atomic_inc_return(&n_cpu_hotplug_torturers) > 1)
> > > atomic_inc(&cpu_hotplug_concurrent_torture);
> > > }
> > >
> > > void torture_end_cpu_hotplug(void)
> > > {
> > > atomic_dec(&n_cpu_hotplug_torturers);
> > > }
> > >
> > > bool torture_cpu_hotplug_was_concurrent(void)
> > > {
> > > return !!atomic_read(&cpu_hotplug_concurrent_torture);
> > > }
> > >
> > > The locktorture and rcutorture code could then ignore CPU-hotplug
> > > errors that could be caused by concurrent access. And complain
> > > bitterly about the concurrent access, of course! ;-)
> >
> > This could do, even better if we extend the torture hotplug tests to
> > take a cpumask so that basically Kevin's patch will be based on torture
> > hotplug tests infrastructure :D (ie he/we wanted to hotplug a subset of
> > the online mask corresponding to a "cluster" of cpus, that's to test the
> > PSCI CPU ON/OFF firmware interface behind cpu hotplug operations).
> >
> > Still, this implies logging every possible cpu_down()/cpu_up() caller
> > through torture_start_cpu_hotplug().
> >
> > What about userspace and sysfs interface that allow to offline cpus then ?
> > Point is, the torture hotplug tests take a snapshot of the maxcpu at
> > kthread init time and then randomize the logical cpu number, but it is
> > definitely possible unless I am mistaken that some of those cpus
> > disappear while the test is running and this will cause failures that
> > you can't detect through the API above.
> >
> > That's why I suggested using the:
> >
> > freeze_secondary_cpus(int primary);
> >
> > for this patch because that allows us to quiesce all cpus other than
> > primary at once, with no interference possible from other kernel control
> > paths (but it is not a perfect solution either).
> >
> > Userspace notwithstanding, I think the best solution consists in either
> > making this patch hotplug tests work on top of the torture hotplug tests
> > API or solving the dependency at kconfig level by disabling the PSCI
> > checker if any of torture tests are enabled which is not ideal but
> > I do not see any other option.
> >
> > Thanks a lot for your feedback, thoughts appreciated.
>
> Let me ask the question more directly.
>
> Why on earth are we trying to run these tests concurrently?
We must prevent that, no question about that, that's why I started
this discussion. It is not fine to enable this checker and the
RCU/LOCK torture hotplug tests at the same time.
> After all, if we just run one at a time in isolation, there is no
> problem.
Fine by me, it was to understand if the current assumptions we made
are correct and they are definitely not. If we enable the PSCI checker
we must disable the torture rcu/lock hotplug tests either statically or
dynamically.
Thanks,
Lorenz
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox