* [PATCH 05/37] PCI: dwc: Add platform_set_drvdata
From: Joao Pinto @ 2017-01-13 17:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484216786-17292-6-git-send-email-kishon@ti.com>
Hi,
?s 10:25 AM de 1/12/2017, Kishon Vijay Abraham I escreveu:
> Add platform_set_drvdata in all designware based drivers to store the
> private data structure of the driver so that dev_set_drvdata can be
> used to get back private data pointer in add_pcie_port/host_init.
> This is in preparation for splitting struct pcie_port into core and
> host only structures. After the split pcie_port will not be part of
> the driver's private data structure and *container_of* used now
> to get the private data pointer cannot be used.
>
> Cc: Jingoo Han <jingoohan1@gmail.com>
> Cc: Richard Zhu <hongxing.zhu@nxp.com>
> Cc: Lucas Stach <l.stach@pengutronix.de>
> Cc: Murali Karicheri <m-karicheri2@ti.com>
> Cc: Minghuan Lian <minghuan.Lian@freescale.com>
> Cc: Mingkai Hu <mingkai.hu@freescale.com>
> Cc: Roy Zang <tie-fei.zang@freescale.com>
> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Cc: Niklas Cassel <niklas.cassel@axis.com>
> Cc: Jesper Nilsson <jesper.nilsson@axis.com>
> Cc: Joao Pinto <Joao.Pinto@synopsys.com>
> Cc: Zhou Wang <wangzhou1@hisilicon.com>
> Cc: Gabriele Paoloni <gabriele.paoloni@huawei.com>
> Cc: Stanimir Varbanov <svarbanov@mm-sol.com>
> Cc: Pratyush Anand <pratyush.anand@gmail.com>
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> ---
> drivers/pci/dwc/pci-dra7xx.c | 3 ++-
> drivers/pci/dwc/pci-exynos.c | 3 ++-
> drivers/pci/dwc/pci-imx6.c | 3 ++-
> drivers/pci/dwc/pci-keystone.c | 2 ++
> drivers/pci/dwc/pci-layerscape.c | 2 ++
> drivers/pci/dwc/pcie-armada8k.c | 2 ++
> drivers/pci/dwc/pcie-artpec6.c | 2 ++
> drivers/pci/dwc/pcie-designware-plat.c | 2 ++
> drivers/pci/dwc/pcie-hisi.c | 2 ++
> drivers/pci/dwc/pcie-qcom.c | 2 ++
> drivers/pci/dwc/pcie-spear13xx.c | 3 ++-
> 11 files changed, 22 insertions(+), 4 deletions(-)
>
This is an example of a change that could be merged with another patch that
gives it more meaning, like I wrote in the review of patch 9/37.
Thanks,
Joao
^ permalink raw reply
* [PATCH v2 2/2] vring: Force use of DMA API for ARM-based systems
From: Will Deacon @ 2017-01-13 17:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170113183222-mutt-send-email-mst@kernel.org>
On Fri, Jan 13, 2017 at 06:46:32PM +0200, Michael S. Tsirkin wrote:
> On Fri, Jan 13, 2017 at 09:25:22AM +0000, Will Deacon wrote:
> > On Fri, Jan 13, 2017 at 12:12:56AM +0200, Michael S. Tsirkin wrote:
> > > On Wed, Jan 11, 2017 at 10:01:39AM +0000, Will Deacon wrote:
> > > > On Wed, Jan 11, 2017 at 01:33:31AM +0200, Michael S. Tsirkin wrote:
> > > > > On Tue, Jan 10, 2017 at 05:51:18PM +0000, Robin Murphy wrote:
> > > > > > From: Will Deacon <will.deacon@arm.com>
> > > > > >
> > > > > > Booting Linux on an ARM fastmodel containing an SMMU emulation results
> > > > > > in an unexpected I/O page fault from the legacy virtio-blk PCI device:
> > > > > >
> > > > > > [ 1.211721] arm-smmu-v3 2b400000.smmu: event 0x10 received:
> > > > > > [ 1.211800] arm-smmu-v3 2b400000.smmu: 0x00000000fffff010
> > > > > > [ 1.211880] arm-smmu-v3 2b400000.smmu: 0x0000020800000000
> > > > > > [ 1.211959] arm-smmu-v3 2b400000.smmu: 0x00000008fa081002
> > > > > > [ 1.212075] arm-smmu-v3 2b400000.smmu: 0x0000000000000000
> > > > > > [ 1.212155] arm-smmu-v3 2b400000.smmu: event 0x10 received:
> > > > > > [ 1.212234] arm-smmu-v3 2b400000.smmu: 0x00000000fffff010
> > > > > > [ 1.212314] arm-smmu-v3 2b400000.smmu: 0x0000020800000000
> > > > > > [ 1.212394] arm-smmu-v3 2b400000.smmu: 0x00000008fa081000
> > > > > > [ 1.212471] arm-smmu-v3 2b400000.smmu: 0x0000000000000000
> > > > > >
> > > > > > <system hangs failing to read partition table>
> > > > > >
> > > > > > This is because the virtio-blk is behind an SMMU, so we have consequently
> > > > > > swizzled its DMA ops and configured the SMMU to translate accesses. This
> > > > > > then requires the vring code to use the DMA API to establish translations,
> > > > > > otherwise all transactions will result in fatal faults and termination.
> > > > > >
> > > > > > Given that ARM-based systems only see an SMMU if one is really present
> > > > > > (the topology is all described by firmware tables such as device-tree or
> > > > > > IORT), then we can safely use the DMA API for all virtio devices.
> > > > > >
> > > > > > Cc: Andy Lutomirski <luto@kernel.org>
> > > > > > Cc: Michael S. Tsirkin <mst@redhat.com>
> > > > > > Signed-off-by: Will Deacon <will.deacon@arm.com>
> > > > >
> > > > > I'd like to better understand then need for this one.
> > > > > Can't the device in question just set VIRTIO_F_IOMMU_PLATFORM ?
> > > > >
> > > > > I'd rather we avoided need for more hacks and just
> > > > > have everyone switch to that.
> > > >
> > > > There are a couple of problems with VIRTIO_F_IOMMU_PLATFORM:
> > > >
> > > > 1. It doesn't exist for legacy devices, which are all we have on the
> > > > platform in question.
> > > >
> > > > 2. It's not documented in the virtio sp^H^HSTOP PRESS. I see you applied
> > > > my patch ;). Thanks.
> > > >
> > > > In which case, for non-legacy devices we should definitely be using
> > > > VIRTIO_F_IOMMU_PLATFORM, but since this platform hasn't yet moved to the
> > > > world of flying cars, could we unconditionally set the DMA ops on ARM
> > > > for legacy devices? The alternative is disabling the SMMU altogether,
> > > > but that's less than ideal because there are non-virtio devices on the
> > > > same PCI bus.
> > > >
> > >
> > > I'd rather people didn't use SMMU with legacy devices.
> >
> > I'm afraid we've been doing that for two years and the model already
> > exists in a mature state, being actively used for development and
> > validation by ARM and our partners. One of the big things its used for
> > is to develop SMMU and GIC (our interrupt controller) code with PCI, so
> > dropping the SMMU from the picture isn't an option.
>
> Oh so this fixes a regression? This is something I didn't realize.
Yes, thanks. The regression came about because we implemented SMMU-backed
DMA ops and only then was it apparent that the virtio stuff was bypassing
even with translation enabled (because it wasn't using the DMA API).
> A "Fixes:" tag can't hurt here. I then wonder
> might DMA ops ever use a DMA address which isn't a physical address
> from QEMU point of view? If that happens, this hack breaks
> because in legacy mode QEMU still uses the GPA.
If QEMU doesn't advertise an SMMU, then it will work fine with the GPA,
because we won't swizzle the DMA ops for the master device. If QEMU does
advertise an SMMU, then we'll allocate DMA addresses to fit within the
the intersection of the SMMU aperture and device's DMA mask.
> > > Can't you guys just code up the virtio 1 layout in QEMU?
> > > I took a look and it's not a big deal now that two other
> > > transports converted, except mmio code in QEMU doesn't
> > > use linux header to it's a bit messy.
> > > I'll send a patch to clean that up.
> >
> > If the model ever changes in this area (which isn't planned atm), the
> > right thing to do would be to move to modern virtio. However, we're stuck
> > with what we have for the forseeable future and it works just fine if we
> > use the DMA API. If we don't use it, Linux no longer boots because it
> > installs the SMMU-backed DMA ops for the virtio devices and everything
> > faults.
> >
> > I really don't understand why this is controversial.
> >
> I agree we need to keep working things working. I just don't yet
> understand what change broke things and how did it happen - legacy
> devices used to just poke at guest PA from QEMU, what does it matter
> that there are changes in DMA ops if neither host nor guest use them for
> legacy setups?
The problem is that platforms which advertise an SMMU downstream of the
(virtual) PCI-RC now automatically have their PCI devices attached to the
SMMU, so if they don't use the DMA ops then they will fault.
> I guess that's just me now knowing about how DMA ops work on SMMU
> or missing some other basic point about SMMU.
>
> I take your word that it's the right thing to do, but I'd like to figure
> it out before merging this. I'll read up in the coming days to make
> sure I understand what the patch does, any pointers welcome.
Ok, thanks. Just shout if you have more questions. I'm also happy with
only doing this for legacy devices, given that modern virtio has the
IOMMU flag.
Will
^ permalink raw reply
* [PATCH 07/37] PCI: dwc: designware: Get device pointer at the start of dw_pcie_host_init
From: Joao Pinto @ 2017-01-13 17:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484216786-17292-8-git-send-email-kishon@ti.com>
Hi!
?s 10:25 AM de 1/12/2017, Kishon Vijay Abraham I escreveu:
> No functional change. Get device pointer at the beginning of
> dw_pcie_host_init instead of getting it all over dw_pcie_host_init.
> This is in preparation for splitting struct pcie_port into host and
> core structures (Once split pcie_port will not have device pointer).
>
I think change should be condense with another patch to reduce the patch-set
number and to give it real meaning. I understand why you are breaking so much
the patch, it is has a lot of changes, but in my opinion is too much fragmented.
Thanks
Joao
^ permalink raw reply
* [PATCH] KVM: arm64: Increase number of memslots to 512
From: Linu Cherian @ 2017-01-13 17:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <61fa02f8-b244-6bae-eaa1-cb745ea543e1@arm.com>
On Fri, Jan 13, 2017 at 5:33 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
> Hi Linu,
>
> On 11/01/17 16:52, linucherian at gmail.com wrote:
>> From: Linu Cherian <linu.cherian@cavium.com>
>>
>> Having only 32 memslots is a real constraint for the maximum number of
>> PCI devices that can be assigned to a single guest. Assuming each PCI
>> device/virtual function having two memory BAR regions, we could assign
>> only 15 devices/virtual functions to a guest.
>>
>> So increase KVM_MEM_SLOTS_NUM to 512 as done in other archs like x86 and
>> powerpc. For this, KVM_USER_MEM_SLOTS has been changed to 508.
>>
>> Signed-off-by: Linu Cherian <linu.cherian@cavium.com>
>> ---
>> arch/arm/kvm/arm.c | 3 +++
>> arch/arm64/include/asm/kvm_host.h | 2 +-
>> 2 files changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
>> index 8f92efa..a19389b 100644
>> --- a/arch/arm/kvm/arm.c
>> +++ b/arch/arm/kvm/arm.c
>> @@ -221,6 +221,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
>> case KVM_CAP_MAX_VCPUS:
>> r = KVM_MAX_VCPUS;
>> break;
>> + case KVM_CAP_NR_MEMSLOTS:
>> + r = KVM_USER_MEM_SLOTS;
>> + break;
>> case KVM_CAP_MSI_DEVID:
>> if (!kvm)
>> r = -EINVAL;
>> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
>> index e505038..88f017d 100644
>> --- a/arch/arm64/include/asm/kvm_host.h
>> +++ b/arch/arm64/include/asm/kvm_host.h
>> @@ -30,7 +30,7 @@
>>
>> #define __KVM_HAVE_ARCH_INTC_INITIALIZED
>>
>> -#define KVM_USER_MEM_SLOTS 32
>> +#define KVM_USER_MEM_SLOTS 508
>> #define KVM_PRIVATE_MEM_SLOTS 4
>> #define KVM_COALESCED_MMIO_PAGE_OFFSET 1
>> #define KVM_HALT_POLL_NS_DEFAULT 500000
>>
>
> I'm not opposed to that patch, but if I may ask: how has that been tested?
>
I have tested this on Cavium ARM64 SOC, by assigning multiple
VFs(virtual functions) of a SRIOV device to a single VM. Each VF has
two memory regions(two BARs) implemented.
Without, this change, when the number of virtual functions assigned to
the guest crosses 15, qemu aborts with
"kvm_alloc_slot: no free slot available", during guest kernel booting.
Now, with this change guest kernel boots fine with more than 15 VFs
assigned(tested upto 29) and also all the PCI VFs assigned to the guest
get listed under lspci with memory resources configured.
Please let me know if you are looking for more specifics like bootlogs etc.
^ permalink raw reply
* [PATCH v1 2/2] arm: dts: mt2701: add nor flash node
From: Marek Vasut @ 2017-01-13 17:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170113175628.1793f433@bbrezillon>
On 01/13/2017 05:56 PM, Boris Brezillon wrote:
> On Fri, 13 Jan 2017 17:44:12 +0100
> Marek Vasut <marek.vasut@gmail.com> wrote:
>
>> On 01/13/2017 05:28 PM, Boris Brezillon wrote:
>>> On Fri, 13 Jan 2017 17:13:55 +0100
>>> Marek Vasut <marek.vasut@gmail.com> wrote:
>>>
>>>> On 01/13/2017 04:12 PM, Matthias Brugger wrote:
>>>>>
>>>>>
>>>>> On 13/01/17 15:17, Boris Brezillon wrote:
>>>>>> On Fri, 13 Jan 2017 15:13:29 +0800
>>>>>> Guochun Mao <guochun.mao@mediatek.com> wrote:
>>>>>>
>>>>>>> Add Mediatek nor flash node.
>>>>>>>
>>>>>>> Signed-off-by: Guochun Mao <guochun.mao@mediatek.com>
>>>>>>> ---
>>>>>>> arch/arm/boot/dts/mt2701-evb.dts | 25 +++++++++++++++++++++++++
>>>>>>> arch/arm/boot/dts/mt2701.dtsi | 12 ++++++++++++
>>>>>>> 2 files changed, 37 insertions(+)
>>>>>>>
>>>>>>> diff --git a/arch/arm/boot/dts/mt2701-evb.dts
>>>>>>> b/arch/arm/boot/dts/mt2701-evb.dts
>>>>>>> index 082ca88..85e5ae8 100644
>>>>>>> --- a/arch/arm/boot/dts/mt2701-evb.dts
>>>>>>> +++ b/arch/arm/boot/dts/mt2701-evb.dts
>>>>>>> @@ -24,6 +24,31 @@
>>>>>>> };
>>>>>>> };
>>>>>>>
>>>>>>> +&nor_flash {
>>>>>>> + pinctrl-names = "default";
>>>>>>> + pinctrl-0 = <&nor_pins_default>;
>>>>>>> + status = "okay";
>>>>>>> + flash at 0 {
>>>>>>> + compatible = "jedec,spi-nor";
>>>>>>> + reg = <0>;
>>>>>>> + };
>>>>>>> +};
>>>>>>> +
>>>>>>> +&pio {
>>>>>>> + nor_pins_default: nor {
>>>>>>> + pins1 {
>>>>>>> + pinmux = <MT2701_PIN_240_EXT_XCS__FUNC_EXT_XCS>,
>>>>>>> + <MT2701_PIN_241_EXT_SCK__FUNC_EXT_SCK>,
>>>>>>> + <MT2701_PIN_239_EXT_SDIO0__FUNC_EXT_SDIO0>,
>>>>>>> + <MT2701_PIN_238_EXT_SDIO1__FUNC_EXT_SDIO1>,
>>>>>>> + <MT2701_PIN_237_EXT_SDIO2__FUNC_EXT_SDIO2>,
>>>>>>> + <MT2701_PIN_236_EXT_SDIO3__FUNC_EXT_SDIO3>;
>>>>>>> + drive-strength = <MTK_DRIVE_4mA>;
>>>>>>> + bias-pull-up;
>>>>>>> + };
>>>>>>> + };
>>>>>>> +};
>>>>>>> +
>>>>>>> &uart0 {
>>>>>>> status = "okay";
>>>>>>> };
>>>>>>> diff --git a/arch/arm/boot/dts/mt2701.dtsi
>>>>>>> b/arch/arm/boot/dts/mt2701.dtsi
>>>>>>> index bdf8954..1eefce4 100644
>>>>>>> --- a/arch/arm/boot/dts/mt2701.dtsi
>>>>>>> +++ b/arch/arm/boot/dts/mt2701.dtsi
>>>>>>> @@ -227,6 +227,18 @@
>>>>>>> status = "disabled";
>>>>>>> };
>>>>>>>
>>>>>>> + nor_flash: spi at 11014000 {
>>>>>>> + compatible = "mediatek,mt2701-nor",
>>>>>>> + "mediatek,mt8173-nor";
>>>>>>
>>>>>> Why define both here? Is "mediatek,mt8173-nor" really providing a
>>>>>> subset of the features supported by "mediatek,mt2701-nor"?
>>>>>>
>>>>>
>>>>> I think even if the ip block is the same, we should provide both
>>>>> bindings, just in case in the future we find out that mt2701 has some
>>>>> hidden bug, feature or bug-feature. This way even if we update the
>>>>> driver, we stay compatible with older device tree blobs in the wild.
>>>>>
>>>>> We can drop the mt2701-nor in the bindings definition if you want.
>>>
>>> Oh, sorry, I misunderstood. What I meant is that if you want to
>>> list/support all possible compatibles, maybe you should just put one
>>> compatible in your DT and patch your driver (+ binding doc) to define
>>> all of them.
>>
>> Uh, what ? I lost you here :-)
>>
>>>> This exactly. We should have a DT compat in the form:
>>>> compatible = "vendor,<soc>-block", "vendor,<oldest-compat-soc>-block";
>>>> Then if we find a problem in the future, we can match on the
>>>> "vendor,<soc>-block" and still support the old DTs.
>>>
>>> Not sure it's only in term of whose IP appeared first. My understanding
>>> is that it's a way to provide inheritance. For example:
>>>
>>> "<soc-vendor>,<ip-version>", "<ip-vendor>,<ip-version>";
>>>
>>> or
>>>
>>> "<soc-vendor>,<full-featured-ip-version>","<soc-vendor>,<basic-feature-ip-version>";
>>>
>>> BTW, which one is the oldest between mt8173 and mt2701? :-)
>>
>> And that's another thing and I agree with you, but I don't think that's
>> what we're discussing in this thread. But (!), OT, I think we should
>> codify the rules in Documentation/ . This discussion came up multiple
>> times recently.
>>
>> And my question still stands, what do we put into the DT here, IMO
>> compatible = "mediatek,mt2701-nor", "mediatek,mt8173-nor";
>
> I'd say
>
> compatible = "mediatek,mt8173-nor";
>
> because both compatible are referring to very specific IP version. It's
> not the same as
But then you don't have the ability to handle a block in this particular
SoC in case there's a bug found in it in the future,
so IMO it should be:
compatible = "mediatek,mt2701-nor", "mediatek,mt8173-nor";
> compatible = "mediatek,mt8173-nor", "mediatek,mt81xx-nor";
This doesn't look right, since here we add two new compatibles ...
> where you clearly have a generic compatible which is overloaded by a
> specific one.
>
> But anyway, I'm not the one taking the decision here, let's wait for DT
> maintainers reviews.
>
>> and what goes into the binding document ? I guess both too ?
>
> If both exist, they should be both documented.
>
--
Best regards,
Marek Vasut
^ permalink raw reply
* [PATCH v11 01/12] dt-bindings: display: mediatek: update supported chips
From: Rob Herring @ 2017-01-13 17:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484117473-46644-2-git-send-email-yt.shen@mediatek.com>
On Wed, Jan 11, 2017 at 02:51:02PM +0800, YT Shen wrote:
> Add decriptions about supported chips, including MT2701 & MT8173
>
> Signed-off-by: YT Shen <yt.shen@mediatek.com>
> ---
> Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt | 2 ++
> Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt | 2 ++
> 2 files changed, 4 insertions(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH] clk: imx6: don't restrict LDB mux changes on QuadPlus
From: Lucas Stach @ 2017-01-13 17:39 UTC (permalink / raw)
To: linux-arm-kernel
The LDB mux/gate layout has been fixed on QuadPlus, so there is no need
to restrict the LDB mux changes on this hardware, as the erratum
preventing this from working properly is gone.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
---
drivers/clk/imx/clk-imx6q.c | 21 +++++++++++++--------
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/clk/imx/clk-imx6q.c b/drivers/clk/imx/clk-imx6q.c
index 42ffc1c92bab..c07df719b8a3 100644
--- a/drivers/clk/imx/clk-imx6q.c
+++ b/drivers/clk/imx/clk-imx6q.c
@@ -592,15 +592,20 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
imx6q_mmdc_ch1_mask_handshake(base);
- /*
- * The LDB_DI0/1_SEL muxes are registered read-only due to a hardware
- * bug. Set the muxes to the requested values before registering the
- * ldb_di_sel clocks.
- */
- init_ldb_clks(np, base);
+ if (clk_on_imx6qp()) {
+ clk[IMX6QDL_CLK_LDB_DI0_SEL] = imx_clk_mux_flags("ldb_di0_sel", base + 0x2c, 9, 3, ldb_di_sels, ARRAY_SIZE(ldb_di_sels), CLK_SET_RATE_PARENT);
+ clk[IMX6QDL_CLK_LDB_DI1_SEL] = imx_clk_mux_flags("ldb_di1_sel", base + 0x2c, 12, 3, ldb_di_sels, ARRAY_SIZE(ldb_di_sels), CLK_SET_RATE_PARENT);
+ } else {
+ /*
+ * The LDB_DI0/1_SEL muxes are registered read-only due to a hardware
+ * bug. Set the muxes to the requested values before registering the
+ * ldb_di_sel clocks.
+ */
+ init_ldb_clks(np, base);
- clk[IMX6QDL_CLK_LDB_DI0_SEL] = imx_clk_mux_ldb("ldb_di0_sel", base + 0x2c, 9, 3, ldb_di_sels, ARRAY_SIZE(ldb_di_sels));
- clk[IMX6QDL_CLK_LDB_DI1_SEL] = imx_clk_mux_ldb("ldb_di1_sel", base + 0x2c, 12, 3, ldb_di_sels, ARRAY_SIZE(ldb_di_sels));
+ clk[IMX6QDL_CLK_LDB_DI0_SEL] = imx_clk_mux_ldb("ldb_di0_sel", base + 0x2c, 9, 3, ldb_di_sels, ARRAY_SIZE(ldb_di_sels));
+ clk[IMX6QDL_CLK_LDB_DI1_SEL] = imx_clk_mux_ldb("ldb_di1_sel", base + 0x2c, 12, 3, ldb_di_sels, ARRAY_SIZE(ldb_di_sels));
+ }
clk[IMX6QDL_CLK_IPU1_DI0_PRE_SEL] = imx_clk_mux_flags("ipu1_di0_pre_sel", base + 0x34, 6, 3, ipu_di_pre_sels, ARRAY_SIZE(ipu_di_pre_sels), CLK_SET_RATE_PARENT);
clk[IMX6QDL_CLK_IPU1_DI1_PRE_SEL] = imx_clk_mux_flags("ipu1_di1_pre_sel", base + 0x34, 15, 3, ipu_di_pre_sels, ARRAY_SIZE(ipu_di_pre_sels), CLK_SET_RATE_PARENT);
clk[IMX6QDL_CLK_IPU2_DI0_PRE_SEL] = imx_clk_mux_flags("ipu2_di0_pre_sel", base + 0x38, 6, 3, ipu_di_pre_sels, ARRAY_SIZE(ipu_di_pre_sels), CLK_SET_RATE_PARENT);
--
2.11.0
^ permalink raw reply related
* [PATCH 12/37] PCI: dwc: Create a new config symbol to enable pci dwc host
From: Joao Pinto @ 2017-01-13 17:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484216786-17292-13-git-send-email-kishon@ti.com>
Hi Kishon,
?s 10:26 AM de 1/12/2017, Kishon Vijay Abraham I escreveu:
> Now that pci designware host has a separate file, create a new
> config symbol to select the host only driver. This is in preparation
> to enable endpoint support to designware driver.
>
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> ---
> drivers/pci/dwc/Kconfig | 26 +++++++++++++++-----------
> drivers/pci/dwc/Makefile | 3 ++-
> drivers/pci/dwc/pcie-designware.h | 29 +++++++++++++++++++++++++----
> 3 files changed, 42 insertions(+), 16 deletions(-)
>
You are already working in a base where dwc/ already exists. I know you made a
rename / re-structure patch for pci, but I think it was not yet accepted, right?
I don't see it in any of Bjorn' dev branches.
Thanks.
> diff --git a/drivers/pci/dwc/Kconfig b/drivers/pci/dwc/Kconfig
> index 8b08519..d0bdfb5 100644
> --- a/drivers/pci/dwc/Kconfig
> +++ b/drivers/pci/dwc/Kconfig
> @@ -3,13 +3,17 @@ menu "DesignWare PCI Core Support"
>
> config PCIE_DW
> bool
> +
> +config PCIE_DW_HOST
> + bool
> depends on PCI_MSI_IRQ_DOMAIN
> + select PCIE_DW
>
> config PCI_DRA7XX
> bool "TI DRA7xx PCIe controller"
> depends on OF && HAS_IOMEM && TI_PIPE3
> depends on PCI_MSI_IRQ_DOMAIN
> - select PCIE_DW
> + select PCIE_DW_HOST
> help
> Enables support for the PCIe controller in the DRA7xx SoC. There
> are two instances of PCIe controller in DRA7xx. This controller can
> @@ -18,7 +22,7 @@ config PCI_DRA7XX
> config PCIE_DW_PLAT
> bool "Platform bus based DesignWare PCIe Controller"
> depends on PCI_MSI_IRQ_DOMAIN
> - select PCIE_DW
> + select PCIE_DW_HOST
> ---help---
> This selects the DesignWare PCIe controller support. Select this if
> you have a PCIe controller on Platform bus.
> @@ -32,21 +36,21 @@ config PCI_EXYNOS
> depends on SOC_EXYNOS5440 || COMPILE_TEST
> depends on PCI_MSI_IRQ_DOMAIN
> select PCIEPORTBUS
> - select PCIE_DW
> + select PCIE_DW_HOST
>
> config PCI_IMX6
> bool "Freescale i.MX6 PCIe controller"
> depends on SOC_IMX6Q || COMPILE_TEST
> depends on PCI_MSI_IRQ_DOMAIN
> select PCIEPORTBUS
> - select PCIE_DW
> + select PCIE_DW_HOST
>
> config PCIE_SPEAR13XX
> bool "STMicroelectronics SPEAr PCIe controller"
> depends on ARCH_SPEAR13XX || COMPILE_TEST
> depends on PCI_MSI_IRQ_DOMAIN
> select PCIEPORTBUS
> - select PCIE_DW
> + select PCIE_DW_HOST
> help
> Say Y here if you want PCIe support on SPEAr13XX SoCs.
>
> @@ -55,7 +59,7 @@ config PCI_KEYSTONE
> depends on ARCH_KEYSTONE || COMPILE_TEST
> depends on PCI_MSI_IRQ_DOMAIN
> select PCIEPORTBUS
> - select PCIE_DW
> + select PCIE_DW_HOST
> help
> Say Y here if you want to enable PCI controller support on Keystone
> SoCs. The PCI controller on Keystone is based on Designware hardware
> @@ -67,7 +71,7 @@ config PCI_LAYERSCAPE
> depends on OF && (ARM || ARCH_LAYERSCAPE || COMPILE_TEST)
> depends on PCI_MSI_IRQ_DOMAIN
> select MFD_SYSCON
> - select PCIE_DW
> + select PCIE_DW_HOST
> help
> Say Y here if you want PCIe controller support on Layerscape SoCs.
>
> @@ -76,7 +80,7 @@ config PCI_HISI
> bool "HiSilicon Hip05 and Hip06 SoCs PCIe controllers"
> depends on PCI_MSI_IRQ_DOMAIN
> select PCIEPORTBUS
> - select PCIE_DW
> + select PCIE_DW_HOST
> help
> Say Y here if you want PCIe controller support on HiSilicon
> Hip05 and Hip06 SoCs
> @@ -86,7 +90,7 @@ config PCIE_QCOM
> depends on (ARCH_QCOM || COMPILE_TEST) && OF
> depends on PCI_MSI_IRQ_DOMAIN
> select PCIEPORTBUS
> - select PCIE_DW
> + select PCIE_DW_HOST
> help
> Say Y here to enable PCIe controller support on Qualcomm SoCs. The
> PCIe controller uses the Designware core plus Qualcomm-specific
> @@ -97,7 +101,7 @@ config PCIE_ARMADA_8K
> depends on ARCH_MVEBU || COMPILE_TEST
> depends on PCI_MSI_IRQ_DOMAIN
> select PCIEPORTBUS
> - select PCIE_DW
> + select PCIE_DW_HOST
> help
> Say Y here if you want to enable PCIe controller support on
> Armada-8K SoCs. The PCIe controller on Armada-8K is based on
> @@ -109,7 +113,7 @@ config PCIE_ARTPEC6
> depends on MACH_ARTPEC6 || COMPILE_TEST
> depends on PCI_MSI_IRQ_DOMAIN
> select PCIEPORTBUS
> - select PCIE_DW
> + select PCIE_DW_HOST
> help
> Say Y here to enable PCIe controller support on Axis ARTPEC-6
> SoCs. This PCIe controller uses the DesignWare core.
> diff --git a/drivers/pci/dwc/Makefile b/drivers/pci/dwc/Makefile
> index 3b57e55..a2df13c 100644
> --- a/drivers/pci/dwc/Makefile
> +++ b/drivers/pci/dwc/Makefile
> @@ -1,4 +1,5 @@
> -obj-$(CONFIG_PCIE_DW) += pcie-designware.o pcie-designware-host.o
> +obj-$(CONFIG_PCIE_DW) += pcie-designware.o
> +obj-$(CONFIG_PCIE_DW_HOST) += pcie-designware-host.o
> obj-$(CONFIG_PCIE_DW_PLAT) += pcie-designware-plat.o
> obj-$(CONFIG_PCI_DRA7XX) += pci-dra7xx.o
> obj-$(CONFIG_PCI_EXYNOS) += pci-exynos.o
> diff --git a/drivers/pci/dwc/pcie-designware.h b/drivers/pci/dwc/pcie-designware.h
> index 808d17b..8f3dcb2 100644
> --- a/drivers/pci/dwc/pcie-designware.h
> +++ b/drivers/pci/dwc/pcie-designware.h
> @@ -162,10 +162,6 @@ struct dw_pcie {
>
> int dw_pcie_read(void __iomem *addr, int size, u32 *val);
> int dw_pcie_write(void __iomem *addr, int size, u32 val);
> -irqreturn_t dw_handle_msi_irq(struct pcie_port *pp);
> -void dw_pcie_msi_init(struct pcie_port *pp);
> -void dw_pcie_setup_rc(struct pcie_port *pp);
> -int dw_pcie_host_init(struct pcie_port *pp);
>
> u32 dw_pcie_readl_dbi(struct dw_pcie *pci, u32 reg);
> void dw_pcie_writel_dbi(struct dw_pcie *pci, u32 reg, u32 val);
> @@ -175,4 +171,29 @@ void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int index,
> int type, u64 cpu_addr, u64 pci_addr,
> u32 size);
> void dw_pcie_setup(struct dw_pcie *pci);
> +
> +#ifdef CONFIG_PCIE_DW_HOST
> +irqreturn_t dw_handle_msi_irq(struct pcie_port *pp);
> +void dw_pcie_msi_init(struct pcie_port *pp);
> +void dw_pcie_setup_rc(struct pcie_port *pp);
> +int dw_pcie_host_init(struct pcie_port *pp);
> +#else
> +static inline irqreturn_t dw_handle_msi_irq(struct pcie_port *pp)
> +{
> + return IRQ_NONE;
> +}
> +
> +static inline void dw_pcie_msi_init(struct pcie_port *pp)
> +{
> +}
> +
> +static inline void dw_pcie_setup_rc(struct pcie_port *pp)
> +{
> +}
> +
> +static inline int dw_pcie_host_init(struct pcie_port *pp)
> +{
> + return 0;
> +}
> +#endif
> #endif /* _PCIE_DESIGNWARE_H */
>
^ permalink raw reply
* [kvm-unit-tests PATCH 1/6] libcflat: add PRI(dux)32 format types
From: Andrew Jones @ 2017-01-13 18:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170112165629.nbczamlqlpsqaauh@hawk.localdomain>
On Thu, Jan 12, 2017 at 05:56:29PM +0100, Andrew Jones wrote:
> On Thu, Jan 12, 2017 at 01:29:24PM +0100, Paolo Bonzini wrote:
> >
> >
> > On 11/01/2017 17:28, Alex Benn?e wrote:
> > > So we can have portable formatting of uint32_t types. However there is
> > > a catch. Different compilers can use legally subtly different types
> > > though so we need to probe the compiler defined intdef.h first.
> >
> > Interesting, what platform has long uint32_t? I thought the issue was
> > whether 64-bit is long or "long long".
> >
> > Paolo
> >
> > > Signed-off-by: Alex Benn?e <alex.bennee@linaro.org>
> > > ---
> > > Makefile | 1 +
> > > configure | 13 +++++++++++++
> > > lib/libcflat.h | 9 +++++++++
> > > 3 files changed, 23 insertions(+)
> > >
> > > diff --git a/Makefile b/Makefile
> > > index a32333b..9822d9a 100644
> > > --- a/Makefile
> > > +++ b/Makefile
> > > @@ -55,6 +55,7 @@ CFLAGS += $(fomit_frame_pointer)
> > > CFLAGS += $(fno_stack_protector)
> > > CFLAGS += $(fno_stack_protector_all)
> > > CFLAGS += $(wno_frame_address)
> > > +CFLAGS += $(if $(U32_LONG_FMT),-D__U32_LONG_FMT__,)
> > >
> > > CXXFLAGS += $(CFLAGS)
> > >
> > > diff --git a/configure b/configure
> > > index 995c8fa..127868c 100755
> > > --- a/configure
> > > +++ b/configure
> > > @@ -109,6 +109,18 @@ if [ -f $testdir/run ]; then
> > > ln -fs $testdir/run $testdir-run
> > > fi
> > >
> > > +# check if uint32_t needs a long format modifier
> > > +cat << EOF > lib_test.c
> > > +#include <inttypes.h>
> > > +EOF
> > > +
> > > +$cross_prefix$cc lib_test.c -E | grep "typedef" | grep "long" | grep "uint32_t" &> /dev/null
>
> This won't work with cross compilers that don't have inttypes.h in their
> path (like mine). How about something like
Paolo,
I see you merged the above. As I stated in this mail, that doesn't work
for my environment, neither arm nor powerpc cross-compile for me now...
Please replace with something like I proposed below. We can probably
replace the awk with a grep though.
Thanks,
drew
>
> cat << EOF > lib_test.c
> __UINT32_TYPE__
> EOF
> u32_long="`aarch64-linux-gnu-gcc lib_test.c -E | awk '/unsigned/ && $2 == "long"'`"
>
> Although I feel there should be a compiler macro way to do this without
> a need for configure/makefile trickery at all...
>
> Thanks,
> drew
>
>
> > > +exit=$?
> > > +if [ $exit -eq 0 ]; then
> > > + u32_long=true
> > > +fi
> > > +rm -f lib_test.c
> > > +
> > > # check for dependent 32 bit libraries
> > > if [ "$arch" != "arm" ]; then
> > > cat << EOF > lib_test.c
> > > @@ -155,4 +167,5 @@ TEST_DIR=$testdir
> > > FIRMWARE=$firmware
> > > ENDIAN=$endian
> > > PRETTY_PRINT_STACKS=$pretty_print_stacks
> > > +U32_LONG_FMT=$u32_long
> > > EOF
> > > diff --git a/lib/libcflat.h b/lib/libcflat.h
> > > index 380395f..e80fc50 100644
> > > --- a/lib/libcflat.h
> > > +++ b/lib/libcflat.h
> > > @@ -58,12 +58,21 @@ typedef _Bool bool;
> > > #define true 1
> > >
> > > #if __SIZEOF_LONG__ == 8
> > > +# define __PRI32_PREFIX
> > > # define __PRI64_PREFIX "l"
> > > # define __PRIPTR_PREFIX "l"
> > > #else
> > > +#if defined(__U32_LONG_FMT__)
> > > +# define __PRI32_PREFIX "l"
> > > +#else
> > > +# define __PRI32_PREFIX
> > > +#endif
> > > # define __PRI64_PREFIX "ll"
> > > # define __PRIPTR_PREFIX
> > > #endif
> > > +#define PRId32 __PRI32_PREFIX "d"
> > > +#define PRIu32 __PRI32_PREFIX "u"
> > > +#define PRIx32 __PRI32_PREFIX "x"
> > > #define PRId64 __PRI64_PREFIX "d"
> > > #define PRIu64 __PRI64_PREFIX "u"
> > > #define PRIx64 __PRI64_PREFIX "x"
> > >
> > --
> > To unsubscribe from this list: send the line "unsubscribe kvm" in
> > the body of a message to majordomo at vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 16/37] PCI: endpoint: Introduce configfs entry for configuring EP functions
From: Christoph Hellwig @ 2017-01-13 18:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484216786-17292-17-git-send-email-kishon@ti.com>
Hi Kishon,
a couple comments on the configfs layout based on my experiments with
your previous drop to implement a NVMe device using it.
I don't think most of these configfs files should be present here, as
they are properties of the implemented PCIe devices. E.g. for my
NVMe device they will be sort of hardcoded most of the time, as they
would be for other devices that would always have a fixed vendor/device/
class ID, cacheline size, etc.
In the end what we'll to be able to do here is to be able to create
a directory for each function driver, which then can create it's own
attributes inside it.
^ permalink raw reply
* [PATCH 1/2] ARM: dts: dra7-evm: increase QSPI SPL partition size
From: Tony Lindgren @ 2017-01-13 18:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484311234-21978-2-git-send-email-ravibabu@ti.com>
* Ravi Babu <ravibabu@ti.com> [170113 04:41]:
> The SPL size for DRA74x platform has increased and
> is now more than 64KB. Increase QSPI SPL partition
> size to 256KB for DRA74x EVM.
>
> QSPI partition numbering changes because of this.
And this will break the existing partitions potentially..
See what was discussed on the list few days ago in thread
"[PATCH 1/6] ARM: dts: am335x-phycore-som: Update NAND
partition table".
It's best to have these left empty or as they originally
were and let u-boot configure the partitions.
Regards,
Tony
> Signed-off-by: Ravi Babu <ravibabu@ti.com>
> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
> ---
> arch/arm/boot/dts/dra7-evm.dts | 24 ++++++------------------
> 1 file changed, 6 insertions(+), 18 deletions(-)
>
> diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
> index 132f2be..2784241 100644
> --- a/arch/arm/boot/dts/dra7-evm.dts
> +++ b/arch/arm/boot/dts/dra7-evm.dts
> @@ -681,41 +681,29 @@
> */
> partition at 0 {
> label = "QSPI.SPL";
> - reg = <0x00000000 0x000010000>;
> + reg = <0x00000000 0x000040000>;
> };
> partition at 1 {
> - label = "QSPI.SPL.backup1";
> - reg = <0x00010000 0x00010000>;
> - };
> - partition at 2 {
> - label = "QSPI.SPL.backup2";
> - reg = <0x00020000 0x00010000>;
> - };
> - partition at 3 {
> - label = "QSPI.SPL.backup3";
> - reg = <0x00030000 0x00010000>;
> - };
> - partition at 4 {
> label = "QSPI.u-boot";
> reg = <0x00040000 0x00100000>;
> };
> - partition at 5 {
> + partition at 2 {
> label = "QSPI.u-boot-spl-os";
> reg = <0x00140000 0x00080000>;
> };
> - partition at 6 {
> + partition at 3 {
> label = "QSPI.u-boot-env";
> reg = <0x001c0000 0x00010000>;
> };
> - partition at 7 {
> + partition at 4 {
> label = "QSPI.u-boot-env.backup1";
> reg = <0x001d0000 0x0010000>;
> };
> - partition at 8 {
> + partition at 5 {
> label = "QSPI.kernel";
> reg = <0x001e0000 0x0800000>;
> };
> - partition at 9 {
> + partition at 6 {
> label = "QSPI.file-system";
> reg = <0x009e0000 0x01620000>;
> };
> --
> 1.9.1
>
^ permalink raw reply
* [PATCH] firmware: qcom: scm: Mask APQ8064 core clk dependency
From: Bjorn Andersson @ 2017-01-13 18:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484175483-25333-1-git-send-email-andy.gross@linaro.org>
On Wed 11 Jan 14:58 PST 2017, Andy Gross wrote:
> This patch masks the core clk requirement for the APQ8064. Until the
> other peripherals correctly describe their clock dependencies or the
> bus driver is put in place to handle the RPM dependencies, this bit
> will remain masked.
>
> Signed-off-by: Andy Gross <andy.gross@linaro.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Regards,
Bjorn
> ---
> drivers/firmware/qcom_scm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
> index 893f953ea..65d0d9d 100644
> --- a/drivers/firmware/qcom_scm.c
> +++ b/drivers/firmware/qcom_scm.c
> @@ -387,7 +387,7 @@ static int qcom_scm_probe(struct platform_device *pdev)
>
> static const struct of_device_id qcom_scm_dt_match[] = {
> { .compatible = "qcom,scm-apq8064",
> - .data = (void *) SCM_HAS_CORE_CLK,
> + /* FIXME: This should have .data = (void *) SCM_HAS_CORE_CLK */
> },
> { .compatible = "qcom,scm-msm8660",
> .data = (void *) SCM_HAS_CORE_CLK,
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v3] ARM: dts: Add LEGO MINDSTORMS EV3 dts
From: David Lechner @ 2017-01-13 18:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3066d614-0676-319a-6149-6d723e1cf35f@ti.com>
On 01/13/2017 06:04 AM, Sekhar Nori wrote:
> On Friday 13 January 2017 02:02 AM, David Lechner wrote:
>> This adds a device tree definition file for LEGO MINDSTORMS EV3.
>>
...
>
> There are couple of checkpatch errors that show up. The compatible
> "lego,ev3" needs to be documented in
> Documentation/devicetree/bindings/arm/davinci.txt
>
> "at24,24c128" is undocumented. Is that an atmel chip on the EV3? If the
> manufacturer name is not clear,
> Documentation/devicetree/bindings/eeprom/eeprom.txt advises using just
> "24c128"
The mfg is microchip, so I guess I will just go with "24c128"
>
> Finally, lego needs to be added to
> Documentation/devicetree/bindings/vendor-prefixes.txt
>
> Can you please submit the documentation portions as separate patches in
> a series along with this patch.
Yes.
>
> Thanks,
> Sekhar
>
^ permalink raw reply
* [PATCH] KVM: arm64: Increase number of memslots to 512
From: Marc Zyngier @ 2017-01-13 18:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGOz-0aD-hV7sDAX70pSGdCj1J4s4xc4qQBwbaKzVZArfRK2AQ@mail.gmail.com>
On 13/01/17 17:25, Linu Cherian wrote:
> On Fri, Jan 13, 2017 at 5:33 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
>> Hi Linu,
>>
>> On 11/01/17 16:52, linucherian at gmail.com wrote:
>>> From: Linu Cherian <linu.cherian@cavium.com>
>>>
>>> Having only 32 memslots is a real constraint for the maximum number of
>>> PCI devices that can be assigned to a single guest. Assuming each PCI
>>> device/virtual function having two memory BAR regions, we could assign
>>> only 15 devices/virtual functions to a guest.
>>>
>>> So increase KVM_MEM_SLOTS_NUM to 512 as done in other archs like x86 and
>>> powerpc. For this, KVM_USER_MEM_SLOTS has been changed to 508.
>>>
>>> Signed-off-by: Linu Cherian <linu.cherian@cavium.com>
>>> ---
>>> arch/arm/kvm/arm.c | 3 +++
>>> arch/arm64/include/asm/kvm_host.h | 2 +-
>>> 2 files changed, 4 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
>>> index 8f92efa..a19389b 100644
>>> --- a/arch/arm/kvm/arm.c
>>> +++ b/arch/arm/kvm/arm.c
>>> @@ -221,6 +221,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
>>> case KVM_CAP_MAX_VCPUS:
>>> r = KVM_MAX_VCPUS;
>>> break;
>>> + case KVM_CAP_NR_MEMSLOTS:
>>> + r = KVM_USER_MEM_SLOTS;
>>> + break;
>>> case KVM_CAP_MSI_DEVID:
>>> if (!kvm)
>>> r = -EINVAL;
>>> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
>>> index e505038..88f017d 100644
>>> --- a/arch/arm64/include/asm/kvm_host.h
>>> +++ b/arch/arm64/include/asm/kvm_host.h
>>> @@ -30,7 +30,7 @@
>>>
>>> #define __KVM_HAVE_ARCH_INTC_INITIALIZED
>>>
>>> -#define KVM_USER_MEM_SLOTS 32
>>> +#define KVM_USER_MEM_SLOTS 508
>>> #define KVM_PRIVATE_MEM_SLOTS 4
>>> #define KVM_COALESCED_MMIO_PAGE_OFFSET 1
>>> #define KVM_HALT_POLL_NS_DEFAULT 500000
>>>
>>
>> I'm not opposed to that patch, but if I may ask: how has that been tested?
>>
>
> I have tested this on Cavium ARM64 SOC, by assigning multiple
> VFs(virtual functions) of a SRIOV device to a single VM. Each VF has
> two memory regions(two BARs) implemented.
>
> Without, this change, when the number of virtual functions assigned to
> the guest crosses 15, qemu aborts with
> "kvm_alloc_slot: no free slot available", during guest kernel booting.
>
> Now, with this change guest kernel boots fine with more than 15 VFs
> assigned(tested upto 29) and also all the PCI VFs assigned to the guest
> get listed under lspci with memory resources configured.
>
> Please let me know if you are looking for more specifics like bootlogs etc.
Let me be more precise. At the moment, KVM on arm64 doesn't support the
delivery of MSIs generated by physical devices into a guest (patches are
in progress, but not merged yet). So unless you used devices that have
no need for interrupts, I don't see how this works.
Can you shed some light on your test process?
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [GIT PULL] Amlogic fixes for v4.10-rc4
From: Kevin Hilman @ 2017-01-13 18:17 UTC (permalink / raw)
To: linux-arm-kernel
Arnd, Olof,
Please pull a couple fixes for v4.10-rc.
The branch is based on v4.10-rc3 to not conflict with another DT fix
that when in for -rc2.
Kevin
The following changes since commit a121103c922847ba5010819a3f250f1f7fc84ab8:
Linux 4.10-rc3 (2017-01-08 14:18:17 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git tags/amlogic-fixes-2
for you to fetch changes up to 64a8225e9f9dec0e5cd2f5640743699056da4e4e:
ARM64: dts: meson-gx: Add reserved memory zone and usable memory range (2017-01-12 17:00:50 -0800)
----------------------------------------------------------------
Amlogic fixes for v4.10-rc4
- odroid-c2: disable DVFS to avoid crashes due to broken SCPI
- fix misc. crashes by adding known reserved memory regions
----------------------------------------------------------------
Neil Armstrong (2):
ARM64: dts: meson-gxbb-odroidc2: Disable SCPI DVFS
ARM64: dts: meson-gx: Add reserved memory zone and usable memory range
arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi | 5 -----
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 12 ++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts | 6 +++++-
arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 10 +++++++++-
arch/arm64/boot/dts/amlogic/meson-gxbb-p200.dts | 9 +++++++++
arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts | 9 +++++++++
arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 5 -----
arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts | 6 +++++-
arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts | 6 +++++-
arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts | 6 +++++-
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 2 +-
arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts | 6 +++++-
arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts | 9 +++++++++
arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p231.dts | 9 +++++++++
arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts | 6 +++++-
arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 6 +++++-
arch/arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts | 9 +++++++++
arch/arm64/boot/dts/amlogic/meson-gxm-s912-q201.dts | 9 +++++++++
18 files changed, 111 insertions(+), 19 deletions(-)
^ permalink raw reply
* [RFC PATCH v2 09/10] drivers/perf: Add support for ARMv8.2 Statistical Profiling Extension
From: Kim Phillips @ 2017-01-13 18:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170113170307.GK3253@arm.com>
On Fri, 13 Jan 2017 17:03:07 +0000
Will Deacon <will.deacon@arm.com> wrote:
> On Fri, Jan 13, 2017 at 10:40:42AM -0600, Kim Phillips wrote:
> > On Fri, 13 Jan 2017 16:03:48 +0000
> > Will Deacon <will.deacon@arm.com> wrote:
> >
> > > +#define DRVNAME "arm_spe_pmu"
> >
> > PMU is implied. "arm_spe"?
>
> As stated before, I'm going for consistency here.
me too, but apparently under the user-visible interface domain rather
than the driver source path domain.
> Is it causing any
> real issues on the tooling side?
Intel has a consistent "intel_pt", "intel_bts", and 'pmu' occurs
nowhere in their nomenclature.
Whether good or bad, we currently have "cs_etm". This patch now gives
us "arm_spe_pmu". I'm just trying to save the suffix consistency for
now, esp. since IDK how amenable "cs_etm" is to change, and 'perf list'
calls things "PMU event"s anyway.
I think the root cause might be the device tree node's
"arm,arm-spe-pmu-v1" compatiblity string, which I also find
a bit self-redundant ("arm,arm-"), but I'm not familiar with what's
being denoted there either (e.g., if the latter 'arm-' is an arch
reference, then SPE's might be 'armv8'?). The device tree node isn't
exposed to the user, however.
> > > + if (is_kernel_in_hyp_mode()) {
> > > + if (attr->exclude_kernel != attr->exclude_hv)
> > > + return -EOPNOTSUPP;
> > > + } else if (!attr->exclude_hv) {
> > > + return -EOPNOTSUPP;
> > > + }
> > > +
> > > + reg = arm_spe_event_to_pmsfcr(event);
> > > + if ((reg & BIT(PMSFCR_EL1_FE_SHIFT)) &&
> > > + !(spe_pmu->features & SPE_PMU_FEAT_FILT_EVT))
> > > + return -EOPNOTSUPP;
> > > +
> > > + if ((reg & BIT(PMSFCR_EL1_FT_SHIFT)) &&
> > > + !(spe_pmu->features & SPE_PMU_FEAT_FILT_TYP))
> > > + return -EOPNOTSUPP;
> > > +
> > > + if ((reg & BIT(PMSFCR_EL1_FL_SHIFT)) &&
> > > + !(spe_pmu->features & SPE_PMU_FEAT_FILT_LAT))
> > > + return -EOPNOTSUPP;
> > > +
> > > + return 0;
> > > +}
> >
> > Please insert pr_* statements before blindly returning errors before a
> > better facility becomes available.
>
> That was discussed in the thread I linked to last time:
>
> https://lkml.org/lkml/2015/8/26/661
ok, thanks for pinpointing the exact message this time.
> and there are good reasons not to add those prints.
Processing that message (indentations are now quoting Peter Zijlstra):
> Not really. That is something that's limited to root. Whereas the
> problem is very much wider than that.
For the purposes of the SPE driver discussion, I'm ok limiting the
context of using the SPE as root.
> If you set one bit wrong in the pretty large perf_event_attr you've got
> a fair chance of getting -EINVAL on trying to create the event. Good
> luck finding what you did wrong.
yes, this is the problem, and the SPE introduces a whole new set of
validity requirements that should be being communicated clearly, e.g.,
its restrictive event frequency specification.
> Any user can create events (for their own tasks), this does not require
> root.
I don't think this is relevant to our discussion.
> Allowing users to flip your @debugging flag would be an insta DoS.
I think this is a reference to the non-root case, and might be mitigated
by either using dynamic or ratelimited pr_ versions if it were.
> Furthermore, its very unfriendly in that you have to (manually) go
> correlate random dmesg output with some program action.
Andrew Morton addresses this, and I did read all other follow-ups and
still conclude that adding pr_ messages is 1000x better than not, for
the user, and at least for the time being.
Kim
^ permalink raw reply
* [PATCH v3] ARM: dts: Add LEGO MINDSTORMS EV3 dts
From: David Lechner @ 2017-01-13 18:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0d69ff4b-c3a6-5126-2590-2268d3b25f92@lechnology.com>
On 01/13/2017 12:16 PM, David Lechner wrote:
> On 01/13/2017 06:04 AM, Sekhar Nori wrote:
>> On Friday 13 January 2017 02:02 AM, David Lechner wrote:
>>> This adds a device tree definition file for LEGO MINDSTORMS EV3.
>>>
> ...
>>
>> There are couple of checkpatch errors that show up. The compatible
>> "lego,ev3" needs to be documented in
>> Documentation/devicetree/bindings/arm/davinci.txt
>>
>> "at24,24c128" is undocumented. Is that an atmel chip on the EV3? If the
>> manufacturer name is not clear,
>> Documentation/devicetree/bindings/eeprom/eeprom.txt advises using just
>> "24c128"
>
> The mfg is microchip, so I guess I will just go with "24c128"
I think I have let the device tree bindings doc confuse me. On second
though, I think the correct thing is to included the manufacturer.
>
>>
>> Finally, lego needs to be added to
>> Documentation/devicetree/bindings/vendor-prefixes.txt
>>
>> Can you please submit the documentation portions as separate patches in
>> a series along with this patch.
>
> Yes.
>
>>
>> Thanks,
>> Sekhar
>>
>
^ permalink raw reply
* [GIT PULL] arm64 fixes for 4.10-rc4
From: Catalin Marinas @ 2017-01-13 18:21 UTC (permalink / raw)
To: linux-arm-kernel
Hi Linus,
Please pull the arm64 fixes below. Thanks.
The following changes since commit a121103c922847ba5010819a3f250f1f7fc84ab8:
Linux 4.10-rc3 (2017-01-08 14:18:17 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-fixes
for you to fetch changes up to 41c066f2c4d436c535616fe182331766c57838f0:
arm64: assembler: make adr_l work in modules under KASLR (2017-01-12 18:10:52 +0000)
----------------------------------------------------------------
- Fix huge_ptep_set_access_flags() to return "changed" when any of the
ptes in the contiguous range is changed, not just the last one
- Fix the adr_l assembly macro to work in modules under KASLR
----------------------------------------------------------------
Ard Biesheuvel (1):
arm64: assembler: make adr_l work in modules under KASLR
Huang Shijie (1):
arm64: hugetlb: fix the wrong return value for huge_ptep_set_access_flags
arch/arm64/include/asm/assembler.h | 36 +++++++++++++++++++++++++++---------
arch/arm64/mm/hugetlbpage.c | 2 +-
2 files changed, 28 insertions(+), 10 deletions(-)
--
Catalin
^ permalink raw reply
* [PATCH v2 2/2] vring: Force use of DMA API for ARM-based systems
From: Michael S. Tsirkin @ 2017-01-13 18:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170113172154.GL3253@arm.com>
On Fri, Jan 13, 2017 at 05:21:54PM +0000, Will Deacon wrote:
> On Fri, Jan 13, 2017 at 06:46:32PM +0200, Michael S. Tsirkin wrote:
> > On Fri, Jan 13, 2017 at 09:25:22AM +0000, Will Deacon wrote:
> > > On Fri, Jan 13, 2017 at 12:12:56AM +0200, Michael S. Tsirkin wrote:
> > > > On Wed, Jan 11, 2017 at 10:01:39AM +0000, Will Deacon wrote:
> > > > > On Wed, Jan 11, 2017 at 01:33:31AM +0200, Michael S. Tsirkin wrote:
> > > > > > On Tue, Jan 10, 2017 at 05:51:18PM +0000, Robin Murphy wrote:
> > > > > > > From: Will Deacon <will.deacon@arm.com>
> > > > > > >
> > > > > > > Booting Linux on an ARM fastmodel containing an SMMU emulation results
> > > > > > > in an unexpected I/O page fault from the legacy virtio-blk PCI device:
> > > > > > >
> > > > > > > [ 1.211721] arm-smmu-v3 2b400000.smmu: event 0x10 received:
> > > > > > > [ 1.211800] arm-smmu-v3 2b400000.smmu: 0x00000000fffff010
> > > > > > > [ 1.211880] arm-smmu-v3 2b400000.smmu: 0x0000020800000000
> > > > > > > [ 1.211959] arm-smmu-v3 2b400000.smmu: 0x00000008fa081002
> > > > > > > [ 1.212075] arm-smmu-v3 2b400000.smmu: 0x0000000000000000
> > > > > > > [ 1.212155] arm-smmu-v3 2b400000.smmu: event 0x10 received:
> > > > > > > [ 1.212234] arm-smmu-v3 2b400000.smmu: 0x00000000fffff010
> > > > > > > [ 1.212314] arm-smmu-v3 2b400000.smmu: 0x0000020800000000
> > > > > > > [ 1.212394] arm-smmu-v3 2b400000.smmu: 0x00000008fa081000
> > > > > > > [ 1.212471] arm-smmu-v3 2b400000.smmu: 0x0000000000000000
> > > > > > >
> > > > > > > <system hangs failing to read partition table>
> > > > > > >
> > > > > > > This is because the virtio-blk is behind an SMMU, so we have consequently
> > > > > > > swizzled its DMA ops and configured the SMMU to translate accesses. This
> > > > > > > then requires the vring code to use the DMA API to establish translations,
> > > > > > > otherwise all transactions will result in fatal faults and termination.
> > > > > > >
> > > > > > > Given that ARM-based systems only see an SMMU if one is really present
> > > > > > > (the topology is all described by firmware tables such as device-tree or
> > > > > > > IORT), then we can safely use the DMA API for all virtio devices.
> > > > > > >
> > > > > > > Cc: Andy Lutomirski <luto@kernel.org>
> > > > > > > Cc: Michael S. Tsirkin <mst@redhat.com>
> > > > > > > Signed-off-by: Will Deacon <will.deacon@arm.com>
> > > > > >
> > > > > > I'd like to better understand then need for this one.
> > > > > > Can't the device in question just set VIRTIO_F_IOMMU_PLATFORM ?
> > > > > >
> > > > > > I'd rather we avoided need for more hacks and just
> > > > > > have everyone switch to that.
> > > > >
> > > > > There are a couple of problems with VIRTIO_F_IOMMU_PLATFORM:
> > > > >
> > > > > 1. It doesn't exist for legacy devices, which are all we have on the
> > > > > platform in question.
> > > > >
> > > > > 2. It's not documented in the virtio sp^H^HSTOP PRESS. I see you applied
> > > > > my patch ;). Thanks.
> > > > >
> > > > > In which case, for non-legacy devices we should definitely be using
> > > > > VIRTIO_F_IOMMU_PLATFORM, but since this platform hasn't yet moved to the
> > > > > world of flying cars, could we unconditionally set the DMA ops on ARM
> > > > > for legacy devices? The alternative is disabling the SMMU altogether,
> > > > > but that's less than ideal because there are non-virtio devices on the
> > > > > same PCI bus.
> > > > >
> > > >
> > > > I'd rather people didn't use SMMU with legacy devices.
> > >
> > > I'm afraid we've been doing that for two years and the model already
> > > exists in a mature state, being actively used for development and
> > > validation by ARM and our partners. One of the big things its used for
> > > is to develop SMMU and GIC (our interrupt controller) code with PCI, so
> > > dropping the SMMU from the picture isn't an option.
> >
> > Oh so this fixes a regression? This is something I didn't realize.
>
> Yes, thanks. The regression came about because we implemented SMMU-backed
> DMA ops and only then was it apparent that the virtio stuff was bypassing
> even with translation enabled (because it wasn't using the DMA API).
Could you point out a commit ID?
> > A "Fixes:" tag can't hurt here. I then wonder
> > might DMA ops ever use a DMA address which isn't a physical address
> > from QEMU point of view? If that happens, this hack breaks
> > because in legacy mode QEMU still uses the GPA.
>
> If QEMU doesn't advertise an SMMU, then it will work fine with the GPA,
> because we won't swizzle the DMA ops for the master device. If QEMU does
> advertise an SMMU, then we'll allocate DMA addresses to fit within the
> the intersection of the SMMU aperture and device's DMA mask.
Right but doesn't just poking from qemu into phys addresses work
anymore? It used to ...
> > > > Can't you guys just code up the virtio 1 layout in QEMU?
> > > > I took a look and it's not a big deal now that two other
> > > > transports converted, except mmio code in QEMU doesn't
> > > > use linux header to it's a bit messy.
> > > > I'll send a patch to clean that up.
> > >
> > > If the model ever changes in this area (which isn't planned atm), the
> > > right thing to do would be to move to modern virtio. However, we're stuck
> > > with what we have for the forseeable future and it works just fine if we
> > > use the DMA API. If we don't use it, Linux no longer boots because it
> > > installs the SMMU-backed DMA ops for the virtio devices and everything
> > > faults.
> > >
> > > I really don't understand why this is controversial.
> > >
> > I agree we need to keep working things working. I just don't yet
> > understand what change broke things and how did it happen - legacy
> > devices used to just poke at guest PA from QEMU, what does it matter
> > that there are changes in DMA ops if neither host nor guest use them for
> > legacy setups?
>
> The problem is that platforms which advertise an SMMU downstream of the
> (virtual) PCI-RC now automatically have their PCI devices attached to the
> SMMU, so if they don't use the DMA ops then they will fault.
>
> > I guess that's just me now knowing about how DMA ops work on SMMU
> > or missing some other basic point about SMMU.
> >
> > I take your word that it's the right thing to do, but I'd like to figure
> > it out before merging this. I'll read up in the coming days to make
> > sure I understand what the patch does, any pointers welcome.
>
> Ok, thanks. Just shout if you have more questions. I'm also happy with
> only doing this for legacy devices, given that modern virtio has the
> IOMMU flag.
>
> Will
^ permalink raw reply
* [RFC PATCH v2 10/10] dt-bindings: Document devicetree binding for ARM SPE
From: Mark Rutland @ 2017-01-13 18:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484323429-15231-11-git-send-email-will.deacon@arm.com>
On Fri, Jan 13, 2017 at 04:03:49PM +0000, Will Deacon wrote:
> This patch documents the devicetree binding in use for ARM SPE.
>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Rob Herring <robh@kernel.org>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
> Documentation/devicetree/bindings/arm/spe-pmu.txt | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/spe-pmu.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/spe-pmu.txt b/Documentation/devicetree/bindings/arm/spe-pmu.txt
> new file mode 100644
> index 000000000000..d6540b491af4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/spe-pmu.txt
> @@ -0,0 +1,20 @@
> +* ARMv8.2 Statistical Profiling Extension (SPE) Performance Monitor Units (PMU)
> +
> +ARMv8.2 introduces the optional Statistical Profiling Extension for collecting
> +performance sample data using an in-memory trace buffer.
> +
> +** SPE Required properties:
> +
> +- compatible : should be one of:
> + "arm,arm-spe-pmu-v1"
The second "arm" here doesn't seem to add much. Should that be "armv8.2"
instead?
That would roughly match what we do with the architected timers to
describe the specific architectural version.
Otherwise, this looks fine to me.
Thanks,
Mark.
> +- interrupts : Exactly 1 PPI must be listed. For heterogeneous systems where
> + SPE is only supported on a subset of the CPUs, please consult
> + the arm,gic-v3 binding for details on describing a PPI partition.
> +
> +** Example:
> +
> +spe-pmu {
> + compatible = "arm,arm-spe-pmu-v1";
> + interrupts = <GIC_PPI 05 IRQ_TYPE_EDGE_RISING &part1>;
> +};
> --
> 2.1.4
>
^ permalink raw reply
* Unhandled level 2 translation fault (11) at 0x000000b8, esr 0x92000046, rpi3 (aarch64)
From: Bas van Tiel @ 2017-01-13 18:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111153349.GK3699@e103592.cambridge.arm.com>
On Wed, Jan 11, 2017 at 4:33 PM, Dave Martin <Dave.Martin@arm.com> wrote:
> On Wed, Jan 11, 2017 at 02:49:03PM +0000, Catalin Marinas wrote:
>> On Tue, Jan 10, 2017 at 12:14:23PM +0000, Catalin Marinas wrote:
>> > On Mon, Jan 09, 2017 at 07:06:19PM +0100, Bas van Tiel wrote:
>> > > > I defined STACKSIZE to the kernel's SIGSTKSZ (16384) and it seems to run
>> > > > fine, though I'll leave it longer/overnight (on a Juno board). With the
>> > > > 4K signal stack it was crashing shortly after start.
>> > >
>> > > I tried the STACKSIZE of 16384 for both the RPI3 and the PINEA64 board
>> > > and still see the same behaviour of crashing. Sometimes the process
>> > > is also blocked for a long time before it crashes.
>> > >
>> > > Setting the interval to 200 usec [5 Khz] will help to crash it faster.
>> > >
>> > > To further isolate the issue I will create a kernel module (based on a
>> > > hrtimer) that will sent a periodic signal to the registered process
>> > > and execute the same sighandler logic to check if the problem is still
>> > > there.
>> >
>> > I lowered the interval to 100us (it was 100ms in the original file) and
>> > I can indeed trigger segfault easily on Juno. But it doesn't fail in the
>> > same way every time, I sometimes get permission fault, other times bad
>> > frame.
>>
>> With 100us interval, it segfaults on x86 fairly quickly as well, so I
>> don't think it's a kernel issue.
>
> To be able to take a signal at all, stacks need to be at least SIGSTKSZ
> bytes in practice:
>
>
> diff --git a/context_demo.c b/context_demo.c
> index 2cc63f7..b1f3bbc 100644
> --- a/context_demo.c
> +++ b/context_demo.c
> @@ -22,7 +22,7 @@
>
>
> #define NUMCONTEXTS 10 /* how many contexts to make */
> -#define STACKSIZE 4096 /* stack size */
> +#define STACKSIZE SIGSTKSZ /* stack size */
> #define INTERVAL 100 /* timer interval in nanoseconds */
>
> sigset_t set; /* process wide signal mask */
>
>
> The other issue looks a bit subtler, to do with signal masking.
>
> SIGALRM will be masked on entry to timer_interrupt() and restored on
> return, due to and absence of SA_NODEFER from sa_flags when calling
> sigaction. (Setting SIGALRM in sa_mask also has this effect, but this
> is redundant without SA_NODEFER.)
>
> However, by explicitly clearing this signal from
> signal_context.uc_sigmask, we'll enter scheduler() with SIGALRM
> unmasked. If a new SIGALRM is taken before scheduler() has called
> setcontext(), we'll pile up another signal on signal_stack and call
> schedule() again, still on signal_stack ... and this can repeat
> indefinitely.
>
> There's no need to clear SIGALRM from the signal mask: it will be
> cleared when timer_interrupt() returns after resuming an interrupted
> task (as part of the signal frame restore work done by rt_sigreturn).
> So:
>
> @@ -61,7 +61,6 @@ timer_interrupt(int j, siginfo_t *si, void *old_context)
> signal_context.uc_stack.ss_sp = signal_stack;
> signal_context.uc_stack.ss_size = STACKSIZE;
> signal_context.uc_stack.ss_flags = 0;
> - sigemptyset(&signal_context.uc_sigmask);
> makecontext(&signal_context, scheduler, 1);
>
> /* save running thread, jump to scheduler */
>
> For me, this seems to fix the problem.
>
> It also makes sense of what we've seen: we need either short timer
> intervals, slow machines, or high system load (or some combination) in
> order to take enough extra signals in scheduler() to cause a stack
> overflow.
so the piling up of the signals is because the handling time of the
signal takes more than the influx of signals related to the interval
time => userspace issue (programming error), thank you for the
explanation and pointing this out to userspace.
In my case the unmasking of SIGALRM cannot be done, because that would
hide the fact that the processing is too slow compared to the influx.
I did a rerun of the program on the 64-bit rpi3 and was able to have
an interval of 13 [us] in which the contexts are executing
a while(1) with a few nops for 6 hours (isolcpus, sched_fifo,
prio:99). Going below below 13 [us] the segfault occurs.
>
> I can't see the purpose of running scheduler() in its own context here,
> except so that it doesn't contribute stack overhead to the thread
> stacks (which hardly seems worthwhile, since its overhead is probably a
> lot smaller than the signal overhead anyway -- maybe I'm missing
> something).
The reason is to have an HPC usecase with context scheduling in 1
process on a dedicated isolated core (CONFIG_NO_HZ_FULL). The signal
can be seen as an HW/SW-IRQ that can be elevated above the
main-process at all times when it occurs.
> makeconext() and swapcontext() are obsoleted by POSIX.1-2008 and
> considered non-portable (see makecontext(3), swapcontext(3)). Really,
> the ucontext API should not be used for anything except cooperative
> switching now (certainly this covered the vast majority or real-world
> usage the last time I looked into it).
agree
> For anything else, pthreads
> almost certainly do it better.
>
agree
--
Bas
^ permalink raw reply
* [PATCH] phy: meson8b-usb2: fix offsets for some of the registers
From: Martin Blumenstingl @ 2017-01-13 18:53 UTC (permalink / raw)
To: linux-arm-kernel
The register offsets for REG_DBG_UART (and all following) were off by
0x4. This was not a problem yet because these registers are currently
not used by the driver.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
drivers/phy/phy-meson8b-usb2.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/phy/phy-meson8b-usb2.c b/drivers/phy/phy-meson8b-usb2.c
index 33c9f4ba157d..30f56a6a411f 100644
--- a/drivers/phy/phy-meson8b-usb2.c
+++ b/drivers/phy/phy-meson8b-usb2.c
@@ -81,9 +81,9 @@
#define REG_ADP_BC_ACA_PIN_GND BIT(25)
#define REG_ADP_BC_ACA_PIN_FLOAT BIT(26)
-#define REG_DBG_UART 0x14
+#define REG_DBG_UART 0x10
-#define REG_TEST 0x18
+#define REG_TEST 0x14
#define REG_TEST_DATA_IN_MASK GENMASK(3, 0)
#define REG_TEST_EN_MASK GENMASK(7, 4)
#define REG_TEST_ADDR_MASK GENMASK(11, 8)
@@ -93,7 +93,7 @@
#define REG_TEST_DATA_OUT_MASK GENMASK(19, 16)
#define REG_TEST_DISABLE_ID_PULLUP BIT(20)
-#define REG_TUNE 0x1c
+#define REG_TUNE 0x18
#define REG_TUNE_TX_RES_TUNE_MASK GENMASK(1, 0)
#define REG_TUNE_TX_HSXV_TUNE_MASK GENMASK(3, 2)
#define REG_TUNE_TX_VREF_TUNE_MASK GENMASK(7, 4)
--
2.11.0
^ permalink raw reply related
* [PATCH] arm64: dts: marvell: add generic-ahci compatibles for CP110 ahci
From: Russell King @ 2017-01-13 18:57 UTC (permalink / raw)
To: linux-arm-kernel
Testing with an Armada 8040 board shows that adding the generic-ahci
compatible to the CP110 AHCI nodes gets us working AHCI on the board.
A previous patch series posted by Thomas Petazzoni was retracted when
it was realised that the IP was supposed to be, and is, compatible
with the standard register layout.
Add this compatible.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi | 3 ++-
arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
index 464b491c7291..65ad781d7910 100644
--- a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
@@ -128,7 +128,8 @@
};
cpm_sata0: sata at 540000 {
- compatible = "marvell,armada-8k-ahci";
+ compatible = "marvell,armada-8k-ahci",
+ "generic-ahci";
reg = <0x540000 0x30000>;
interrupts = <ICU_GRP_NSR 107 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpm_syscon0 1 15>;
diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
index b10f4781d8fb..168d667d50a3 100644
--- a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
@@ -128,7 +128,8 @@
};
cps_sata0: sata at 540000 {
- compatible = "marvell,armada-8k-ahci";
+ compatible = "marvell,armada-8k-ahci",
+ "generic-ahci";
reg = <0x540000 0x30000>;
interrupts = <ICU_GRP_NSR 107 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cps_syscon0 1 15>;
--
2.7.4
^ permalink raw reply related
* [PATCH 1/4] clk: rockchip: add rk3288 isp_in clock ids
From: Heiko Stuebner @ 2017-01-13 18:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484049560-14820-1-git-send-email-jacob-chen@iotwrt.com>
Am Dienstag, 10. Januar 2017, 19:59:17 CET schrieb Jacob Chen:
> Add clock-ids for the isp block of the rk3288.
>
>
> Signed-off-by: Jacob Chen <jacob-chen@iotwrt.com>
applied for 4.11
Thanks
Heiko
^ permalink raw reply
* [PATCH 2/4] clk: rockchip: use rk3288 isp_in clock ids
From: Heiko Stuebner @ 2017-01-13 18:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484049560-14820-2-git-send-email-jacob-chen@iotwrt.com>
Am Dienstag, 10. Januar 2017, 19:59:18 CET schrieb Jacob Chen:
> Reference the newly added isp clock-ids in the clock-tree.
>
>
> Signed-off-by: Jacob Chen <jacob-chen@iotwrt.com>
applied for 4.11
Thanks
Heiko
^ 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