* [PATCH v3 1/4] dt/bindings: Add binding for the DA8xx MUSB driver
From: Alexandre Bailon @ 2016-10-27 9:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477560847-8929-1-git-send-email-abailon@baylibre.com>
From: Petr Kulhavy <petr@barix.com>
DT binding for the TI DA8xx/OMAP-L1x/AM17xx/AM18xx MUSB driver.
Signed-off-by: Petr Kulhavy <petr@barix.com>
Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
---
.../devicetree/bindings/usb/da8xx-usb.txt | 43 ++++++++++++++++++++++
1 file changed, 43 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/da8xx-usb.txt
diff --git a/Documentation/devicetree/bindings/usb/da8xx-usb.txt b/Documentation/devicetree/bindings/usb/da8xx-usb.txt
new file mode 100644
index 0000000..ccb844a
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/da8xx-usb.txt
@@ -0,0 +1,43 @@
+TI DA8xx MUSB
+~~~~~~~~~~~~~
+For DA8xx/OMAP-L1x/AM17xx/AM18xx platforms.
+
+Required properties:
+~~~~~~~~~~~~~~~~~~~~
+ - compatible : Should be set to "ti,da830-musb".
+
+ - reg: Offset and length of the USB controller register set.
+
+ - interrupts: The USB interrupt number.
+
+ - interrupt-names: Should be set to "mc".
+
+ - dr_mode: The USB operation mode. Should be one of "host", "peripheral" or "otg".
+
+ - phys: Phandle for the PHY device
+
+ - phy-names: Should be "usb-phy"
+
+Optional properties:
+~~~~~~~~~~~~~~~~~~~~
+ - vbus-supply: Phandle to a regulator providing the USB bus power.
+
+Example:
+ usb_phy: usb-phy {
+ compatible = "ti,da830-usb-phy";
+ #phy-cells = <0>;
+ status = "okay";
+ };
+ usb0: usb at 200000 {
+ compatible = "ti,da830-musb";
+ reg = <0x00200000 0x10000>;
+ interrupts = <58>;
+ interrupt-names = "mc";
+
+ dr_mode = "host";
+ vbus-supply = <&usb_vbus>;
+ phys = <&usb_phy 0>;
+ phy-names = "usb-phy";
+
+ status = "okay";
+ };
--
2.7.3
^ permalink raw reply related
* [PATCH v3 0/4] Add DT support for DA8xx
From: Alexandre Bailon @ 2016-10-27 9:34 UTC (permalink / raw)
To: linux-arm-kernel
Changes in v2:
* Remove unrelated changes in patch 3
* Rename the device node in patch 4
Changes in v3:
* Fix few mistakes in DT binding sample
* Only build the device table if DT is enabled
Alexandre Bailon (1):
ARM: dts: da850: Add the usb otg device node
Petr Kulhavy (3):
dt/bindings: Add binding for the DA8xx MUSB driver
usb: musb: core: added helper function for parsing DT
usb: musb: da8xx: Add DT support for the DA8xx driver
.../devicetree/bindings/usb/da8xx-usb.txt | 43 ++++++++++++++++++++
arch/arm/boot/dts/da850-lcdk.dts | 8 ++++
arch/arm/boot/dts/da850.dtsi | 15 +++++++
drivers/usb/musb/da8xx.c | 46 ++++++++++++++++++++++
drivers/usb/musb/musb_core.c | 19 +++++++++
drivers/usb/musb/musb_core.h | 5 +++
6 files changed, 136 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/da8xx-usb.txt
--
2.7.3
^ permalink raw reply
* [PATCH v2 2/9] dt-bindings: interrupt-controller: add DT binding for meson GPIO interrupt controller
From: Mark Rutland @ 2016-10-27 9:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026214234.4q6wmecehqh6q32o@rob-hp-laptop>
On Wed, Oct 26, 2016 at 04:42:35PM -0500, Rob Herring wrote:
> On Wed, Oct 19, 2016 at 05:21:13PM +0200, Jerome Brunet wrote:
> >
> > This commit adds the device tree bindings description for Amlogic's GPIO
> > interrupt controller available on the meson8, meson8b and gxbb SoC families
> >
> > Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> > ---
> > Rob, I did not include the Ack you gave for the RFC as bindings have slightly
> > changed. Only the interrupt property has be removed following a discussion I
> > had with Marc
>
> As Mark R already said, you should keep the interrupts property.
To be clear, the interrupt routing should be described *somehow*, though
I don't think the generic interrupts property is correct, as this is an
interrupt *router*, i.e. this device doesn't own the interrupt, it just
joins two parts of the line together (and so flags are meaningless).
Thanks,
Mark.
^ permalink raw reply
* [PATCH V4 2/3] ARM64 LPC: Add missing range exception for special ISA
From: zhichang.yuan @ 2016-10-27 9:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026222542.g4etrqesqb7febid@rob-hp-laptop>
Hi, Rob,
Thanks for your comments!
Please check the response blow.
BTW, Are there any comments from other maintainers/hackers??
Thanks in advance!
On 2016/10/27 6:25, Rob Herring wrote:
> On Thu, Oct 20, 2016 at 05:15:39PM +0800, zhichang.yuan wrote:
>> Currently if the range property is not specified of_translate_one
>> returns an error. There are some special devices that work on a
>> range of I/O ports where it's is not correct to specify a range
>> property as the cpu addresses are used by special accessors.
>> Here we add a new exception in of_translate_one to return
>> the cpu address if the range property is not there. The exception
>> checks if the parent bus is ISA and if the special accessors are
>> defined.
>>
>> Signed-off-by: zhichang.yuan <yuanzhichang@hisilicon.com>
>> Signed-off-by: Gabriele Paoloni <gabriele.paoloni@huawei.com>
>> ---
>> arch/arm64/include/asm/io.h | 7 +++++++
>> arch/arm64/kernel/extio.c | 24 +++++++++++++++++++++++
>> drivers/of/address.c | 47 +++++++++++++++++++++++++++++++++++++++++++--
>> drivers/pci/pci.c | 6 +++---
>> include/linux/of_address.h | 17 ++++++++++++++++
>> 5 files changed, 96 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
>> index 136735d..e480199 100644
>> --- a/arch/arm64/include/asm/io.h
>> +++ b/arch/arm64/include/asm/io.h
>> @@ -175,6 +175,13 @@ static inline u64 __raw_readq(const volatile void __iomem *addr)
>> #define outsl outsl
>>
>> DECLARE_EXTIO(l, u32)
>> +
>> +
>> +#define indirect_io_ison indirect_io_ison
>> +extern int indirect_io_ison(void);
>> +
>> +#define chk_indirect_range chk_indirect_range
>> +extern int chk_indirect_range(u64 taddr);
>> #endif
>>
>>
>> diff --git a/arch/arm64/kernel/extio.c b/arch/arm64/kernel/extio.c
>> index 80cafd5..55df8dc 100644
>> --- a/arch/arm64/kernel/extio.c
>> +++ b/arch/arm64/kernel/extio.c
>> @@ -19,6 +19,30 @@
>>
>> struct extio_ops *arm64_extio_ops;
>>
>> +/**
>> + * indirect_io_ison - check whether indirectIO can work well. This function only call
>> + * before the target I/O address was obtained.
>> + *
>> + * Returns 1 when indirectIO can work.
>> + */
>> +int indirect_io_ison()
>> +{
>> + return arm64_extio_ops ? 1 : 0;
>> +}
>> +
>> +/**
>> + * check_indirect_io - check whether the input taddr is for indirectIO.
>> + * @taddr: the io address to be checked.
>> + *
>> + * Returns 1 when taddr is in the range; otherwise return 0.
>> + */
>> +int chk_indirect_range(u64 taddr)
>> +{
>> + if (arm64_extio_ops->start > taddr || arm64_extio_ops->end < taddr)
>> + return 0;
>> +
>> + return 1;
>> +}
>>
>> BUILD_EXTIO(b, u8)
>>
>> diff --git a/drivers/of/address.c b/drivers/of/address.c
>> index 02b2903..0bee822 100644
>> --- a/drivers/of/address.c
>> +++ b/drivers/of/address.c
>> @@ -479,6 +479,39 @@ static int of_empty_ranges_quirk(struct device_node *np)
>> return false;
>> }
>>
>> +
>> +/*
>> + * Check whether the current device being translating use indirectIO.
>> + *
>> + * return 1 if the check is past, or 0 represents fail checking.
>> + */
>> +static int of_isa_indirect_io(struct device_node *parent,
>
> Make the return bool.
ok. will update it.
>
>> + struct of_bus *bus, __be32 *addr,
>> + int na, u64 *presult)
>> +{
>> + unsigned int flags;
>> + unsigned int rlen;
>> +
>> + /* whether support indirectIO */
>> + if (!indirect_io_ison())
>
> indirect_io_is_enabled() would be a bit more readable.
Ok.
>
>> + return 0;
>> +
>> + if (!of_bus_isa_match(parent))
>> + return 0;
>> +
>> + flags = bus->get_flags(addr);
>> + if (!(flags & IORESOURCE_IO))
>> + return 0;
>> +
>> + /* there is ranges property, apply the normal translation directly. */
>> + if (of_get_property(parent, "ranges", &rlen))
>> + return 0;
>> +
>> + *presult = of_read_number(addr + 1, na - 1);
>> +
>> + return chk_indirect_range(*presult);
>> +}
>> +
>> static int of_translate_one(struct device_node *parent, struct of_bus *bus,
>> struct of_bus *pbus, __be32 *addr,
>> int na, int ns, int pna, const char *rprop)
>> @@ -532,7 +565,7 @@ static int of_translate_one(struct device_node *parent, struct of_bus *bus,
>> }
>> memcpy(addr, ranges + na, 4 * pna);
>>
>> - finish:
>> +finish:
>
> This hunk is unrelated. Drop it.
Yes. Will drop this change.
>
>> of_dump_addr("parent translation for:", addr, pna);
>> pr_debug("with offset: %llx\n", (unsigned long long)offset);
>>
>> @@ -595,6 +628,15 @@ static u64 __of_translate_address(struct device_node *dev,
>> result = of_read_number(addr, na);
>> break;
>> }
>> + /*
>> + * For indirectIO device which has no ranges property, get
>> + * the address from reg directly.
>> + */
>> + if (of_isa_indirect_io(dev, bus, addr, na, &result)) {
>> + pr_info("isa indirectIO matched(%s)..addr = 0x%llx\n",
>> + of_node_full_name(dev), result);
>
> This should be debugging.
ok. will replace with pr_debug.
thanks!
Zhichang
>
>> + break;
>> + }
>>
>> /* Get new parent bus and counts */
>> pbus = of_match_bus(parent);
>> @@ -688,8 +730,9 @@ static int __of_address_to_resource(struct device_node *dev,
>> if (taddr == OF_BAD_ADDR)
>> return -EINVAL;
>> memset(r, 0, sizeof(struct resource));
>> - if (flags & IORESOURCE_IO) {
>> + if (flags & IORESOURCE_IO && taddr >= PCIBIOS_MIN_IO) {
>> unsigned long port;
>> +
>> port = pci_address_to_pio(taddr);
>> if (port == (unsigned long)-1)
>> return -EINVAL;
>> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>> index ba34907..1a08511 100644
>> --- a/drivers/pci/pci.c
>> +++ b/drivers/pci/pci.c
>> @@ -3263,7 +3263,7 @@ int __weak pci_register_io_range(phys_addr_t addr, resource_size_t size)
>>
>> #ifdef PCI_IOBASE
>> struct io_range *range;
>> - resource_size_t allocated_size = 0;
>> + resource_size_t allocated_size = PCIBIOS_MIN_IO;
>>
>> /* check if the range hasn't been previously recorded */
>> spin_lock(&io_range_lock);
>> @@ -3312,7 +3312,7 @@ phys_addr_t pci_pio_to_address(unsigned long pio)
>>
>> #ifdef PCI_IOBASE
>> struct io_range *range;
>> - resource_size_t allocated_size = 0;
>> + resource_size_t allocated_size = PCIBIOS_MIN_IO;
>>
>> if (pio > IO_SPACE_LIMIT)
>> return address;
>> @@ -3335,7 +3335,7 @@ unsigned long __weak pci_address_to_pio(phys_addr_t address)
>> {
>> #ifdef PCI_IOBASE
>> struct io_range *res;
>> - resource_size_t offset = 0;
>> + resource_size_t offset = PCIBIOS_MIN_IO;
>> unsigned long addr = -1;
>>
>> spin_lock(&io_range_lock);
>> diff --git a/include/linux/of_address.h b/include/linux/of_address.h
>> index 3786473..0ba7e21 100644
>> --- a/include/linux/of_address.h
>> +++ b/include/linux/of_address.h
>> @@ -24,6 +24,23 @@ struct of_pci_range {
>> #define for_each_of_pci_range(parser, range) \
>> for (; of_pci_range_parser_one(parser, range);)
>>
>> +
>> +#ifndef indirect_io_ison
>> +#define indirect_io_ison indirect_io_ison
>> +static inline int indirect_io_ison(void)
>> +{
>> + return 0;
>> +}
>> +#endif
>> +
>> +#ifndef chk_indirect_range
>> +#define chk_indirect_range chk_indirect_range
>> +static inline int chk_indirect_range(u64 taddr)
>> +{
>> + return 0;
>> +}
>> +#endif
>> +
>> /* Translate a DMA address from device space to CPU space */
>> extern u64 of_translate_dma_address(struct device_node *dev,
>> const __be32 *in_addr);
>> --
>> 1.9.1
>>
>
> .
>
^ permalink raw reply
* [GIT PULL] ARM: keystone: add TI SCI protocol support for v4.10
From: Tero Kristo @ 2016-10-27 9:30 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd, Olof, Kevin,
This pull introduces the TI SCI protocol support for keystone family of
devices, targeted for v4.10 merge window. We discussed with Santosh
(keystone maintainer) that it would probably be better that I'll be
sending the pull requests for this directly, avoiding one extra step of
merges.
-Tero
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
https://github.com/t-kristo/linux-pm.git for-4.10-ti-sci-base
for you to fetch changes up to 912cffb4ed8612dc99ee0251cc0c9785855162cd:
firmware: ti_sci: Add support for reboot core service (2016-10-27
12:09:12 +0300)
----------------------------------------------------------------
Nishanth Menon (5):
Documentation: Add support for TI System Control Interface
(TI-SCI) protocol
firmware: Add basic support for TI System Control Interface
(TI-SCI) protocol
firmware: ti_sci: Add support for Device control
firmware: ti_sci: Add support for Clock control
firmware: ti_sci: Add support for reboot core service
.../devicetree/bindings/arm/keystone/ti,sci.txt | 81 +
MAINTAINERS | 10 +
drivers/firmware/Kconfig | 15 +
drivers/firmware/Makefile | 1 +
drivers/firmware/ti_sci.c | 1991
++++++++++++++++++++
drivers/firmware/ti_sci.h | 492 +++++
include/linux/soc/ti/ti_sci_protocol.h | 249 +++
7 files changed, 2839 insertions(+)
create mode 100644
Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
create mode 100644 drivers/firmware/ti_sci.c
create mode 100644 drivers/firmware/ti_sci.h
create mode 100644 include/linux/soc/ti/ti_sci_protocol.h
^ permalink raw reply
* [PATCH 01/18] 32-bit ABI: introduce ARCH_32BIT_OFF_T config option
From: Yury Norov @ 2016-10-27 9:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <22426495.JIjM4XpfGo@wuerfel>
On Tue, Oct 25, 2016 at 12:22:47AM +0200, Arnd Bergmann wrote:
> On Monday, October 24, 2016 12:30:47 PM CEST Chris Metcalf wrote:
> > On 10/21/2016 4:33 PM, Yury Norov wrote:
> > > All new 32-bit architectures should have 64-bit off_t type, but existing
> > > architectures has 32-bit ones.
> > >
> > > [...]
> > > For syscalls sys_openat() and sys_open_by_handle_at() force_o_largefile()
> > > is called, to set O_LARGEFILE flag, and this is the only difference
> > > comparing to compat versions. All compat ABIs are already turned to use
> > > 64-bit off_t, except tile. So, compat versions for this syscalls are not
> > > needed anymore. Tile is handled explicitly.
> > >
> > > [...]
> > > --- a/arch/tile/kernel/compat.c
> > > +++ b/arch/tile/kernel/compat.c
> > > @@ -103,6 +103,9 @@ COMPAT_SYSCALL_DEFINE5(llseek, unsigned int, fd, unsigned int, offset_high,
> > > #define compat_sys_readahead sys32_readahead
> > > #define sys_llseek compat_sys_llseek
> > >
> > > +#define sys_openat compat_sys_openat
> > > +#define sys_open_by_handle_at compat_sys_open_by_handle_at
> > > +
> > > /* Call the assembly trampolines where necessary. */
> > > #define compat_sys_rt_sigreturn _compat_sys_rt_sigreturn
> > > #define sys_clone _sys_clone
> >
> > This patch accomplishes two goals that could be completely separated.
> > It's confusing to have them mixed in the same patch without any
> > discussion of why they are in the same patch.
> >
> > First, you want to modify the default <asm/unistd.h> behavior for
> > compat syscalls so that the default is sys_openat (etc) rather than
> > the existing compat_sys_openat, and then use that new behavior for
> > arm64 ILP32. This lets you force O_LARGEFILE for arm64 ILP32 to
> > support having a 64-bit off_t at all times. To do that, you fix the
> > asm-generic header, and then make tile have a special override.
> > This seems reasonable enough.
> >
> > Second, you introduce ARCH_32BIT_OFF_T basically as a synonym for
> > "BITS_PER_WORD == 32", so that new 32-bit architectures can choose not
> > to enable it. This is fine in the abstract, but I'm a bit troubled by
> > the fact that you are not actually introducing a new 32-bit
> > architecture here (just a new 32-bit mode for the arm 64-bit kernel).
> > Shouldn't this part of the change wait until someone actually has a
> > new 32-bit kernel to drive this forward?
>
> I asked for this specifically because we identified the problem
> during the review of the aarch64 ilp32 code, and it might not
> be noticed in the next architecture submission.
>
> The most important aspect from my perspective is that the new
> ilp32 ABI on aarch64 behaves the same way that any native 32-bit
> architecture does, and when we change the default, it should
> be done for both compat mode and native mode at the same time.
>
> > If you want to push forward the ARCH_32BIT_OFF_T change in the absence
> > of an architecture that supports it, I would think it would be a lot
> > less confusing to have these two in separate patches, and make it
> > clear that the ARCH_32BIT_OFF_T change is just laying groundwork
> > for some hypothetical future architecture.
> >
> > The existing commit language itself is also confusing. You write "All
> > compat ABIs are already turned to use 64-bit off_t, except tile."
> > First, I'm not sure what you mean by "turned" here. And, tile is just
> > one of many compat ABIs that allow O_LARGEFILE not to be part of the
> > open call: see arm64's AArch32 ABI, MIPS o32, s390 31-bit emulation,
> > sparc64's 32-bit mode, and of course x86's 32-bit compat mode.
> > Presumably your point here is that tile is the only pre-existing
> > architecture that #includes <asm/unistd.h> to create its compat
> > syscall table, and so I think "all except tile" here is particularly
> > confusing, since there are no architectures except tile that use the
> > __SYSCALL_COMPAT functionality in the current tree.
>
> Agreed, this could be made clearer, and splitting the patch up
> in two also seems reasonable, though I didn't see it as important.
>
> Arnd
In the past it was a separated series of 2 patches, and it was even
acked by Arnd, but not submitted.
http://lists-archives.com/linux-kernel/28471253-32-bit-abi-introduce-arch_32bit_off_t-config-option.html
I can restore that small series in aarch64/ilp32 for next iteration, or resend
it separately if you think to submit it before aarch64/ilp32 (which is
better, for me).
Yury
^ permalink raw reply
* [RFC PATCH 5/5] of: overlay-mgr: add a detector for headers stored on a ds2431 eeprom over w1
From: Matthias Brugger @ 2016-10-27 9:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026145756.21689-6-antoine.tenart@free-electrons.com>
On 10/26/2016 04:57 PM, Antoine Tenart wrote:
> Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
> ---
Please provide a commit message.
Thanks,
Matthias
^ permalink raw reply
* [PATCH] arm/arm64: KVM: Perform local TLB invalidation when multiplexing vcpus on a single CPU
From: Christoffer Dall @ 2016-10-27 9:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477323088-18768-1-git-send-email-marc.zyngier@arm.com>
On Mon, Oct 24, 2016 at 04:31:28PM +0100, Marc Zyngier wrote:
> Architecturally, TLBs are private to the (physical) CPU they're
> associated with. But when multiple vcpus from the same VM are
> being multiplexed on the same CPU, the TLBs are not private
> to the vcpus (and are actually shared across the VMID).
>
> Let's consider the following scenario:
>
> - vcpu-0 maps PA to VA
> - vcpu-1 maps PA' to VA
>
> If run on the same physical CPU, vcpu-1 can hit TLB entries generated
> by vcpu-0 accesses, and access the wrong physical page.
>
> The solution to this is to keep a per-VM map of which vcpu ran last
> on each given physical CPU, and invalidate local TLBs when switching
> to a different vcpu from the same VM.
Just making sure I understand this: The reason you cannot rely on the
guest doing the necessary distinction with ASIDs or invalidating the TLB
is that a guest (which assumes it's running on hardware) can validly
defer any neccessary invalidation until it starts running on other
physical CPUs, but we do this transparently in KVM?
Thanks,
-Christoffer
>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> ---
> arch/arm/include/asm/kvm_host.h | 5 +++++
> arch/arm/include/asm/kvm_hyp.h | 1 +
> arch/arm/kvm/arm.c | 35 ++++++++++++++++++++++++++++++++++-
> arch/arm/kvm/hyp/switch.c | 9 +++++++++
> arch/arm64/include/asm/kvm_host.h | 6 +++++-
> arch/arm64/kvm/hyp/switch.c | 8 ++++++++
> 6 files changed, 62 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
> index 2d19e02..035e744 100644
> --- a/arch/arm/include/asm/kvm_host.h
> +++ b/arch/arm/include/asm/kvm_host.h
> @@ -57,6 +57,8 @@ struct kvm_arch {
> /* VTTBR value associated with below pgd and vmid */
> u64 vttbr;
>
> + int __percpu *last_vcpu_ran;
> +
> /* Timer */
> struct arch_timer_kvm timer;
>
> @@ -174,6 +176,9 @@ struct kvm_vcpu_arch {
> /* vcpu power-off state */
> bool power_off;
>
> + /* TLBI required */
> + bool requires_tlbi;
> +
> /* Don't run the guest (internal implementation need) */
> bool pause;
>
> diff --git a/arch/arm/include/asm/kvm_hyp.h b/arch/arm/include/asm/kvm_hyp.h
> index 343135e..5850890 100644
> --- a/arch/arm/include/asm/kvm_hyp.h
> +++ b/arch/arm/include/asm/kvm_hyp.h
> @@ -71,6 +71,7 @@
> #define ICIALLUIS __ACCESS_CP15(c7, 0, c1, 0)
> #define ATS1CPR __ACCESS_CP15(c7, 0, c8, 0)
> #define TLBIALLIS __ACCESS_CP15(c8, 0, c3, 0)
> +#define TLBIALL __ACCESS_CP15(c8, 0, c7, 0)
> #define TLBIALLNSNHIS __ACCESS_CP15(c8, 4, c3, 4)
> #define PRRR __ACCESS_CP15(c10, 0, c2, 0)
> #define NMRR __ACCESS_CP15(c10, 0, c2, 1)
> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
> index 03e9273..09942f0 100644
> --- a/arch/arm/kvm/arm.c
> +++ b/arch/arm/kvm/arm.c
> @@ -114,11 +114,18 @@ void kvm_arch_check_processor_compat(void *rtn)
> */
> int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
> {
> - int ret = 0;
> + int ret, cpu;
>
> if (type)
> return -EINVAL;
>
> + kvm->arch.last_vcpu_ran = alloc_percpu(typeof(*kvm->arch.last_vcpu_ran));
> + if (!kvm->arch.last_vcpu_ran)
> + return -ENOMEM;
> +
> + for_each_possible_cpu(cpu)
> + *per_cpu_ptr(kvm->arch.last_vcpu_ran, cpu) = -1;
> +
> ret = kvm_alloc_stage2_pgd(kvm);
> if (ret)
> goto out_fail_alloc;
> @@ -141,6 +148,8 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
> out_free_stage2_pgd:
> kvm_free_stage2_pgd(kvm);
> out_fail_alloc:
> + free_percpu(kvm->arch.last_vcpu_ran);
> + kvm->arch.last_vcpu_ran = NULL;
> return ret;
> }
>
> @@ -168,6 +177,9 @@ void kvm_arch_destroy_vm(struct kvm *kvm)
> {
> int i;
>
> + free_percpu(kvm->arch.last_vcpu_ran);
> + kvm->arch.last_vcpu_ran = NULL;
> +
> for (i = 0; i < KVM_MAX_VCPUS; ++i) {
> if (kvm->vcpus[i]) {
> kvm_arch_vcpu_free(kvm->vcpus[i]);
> @@ -310,6 +322,27 @@ int kvm_arch_vcpu_init(struct kvm_vcpu *vcpu)
> return 0;
> }
>
> +void kvm_arch_sched_in(struct kvm_vcpu *vcpu, int cpu)
> +{
> + int *last_ran;
> +
> + last_ran = per_cpu_ptr(vcpu->kvm->arch.last_vcpu_ran, cpu);
> +
> + /*
> + * If we're very unlucky and get preempted before having ran
> + * this vcpu for real, we'll end-up in a situation where any
> + * vcpu that gets scheduled will perform an invalidation (this
> + * vcpu explicitely requires it, and all the others will have
> + * a different vcpu_id).
> + */
> + if (*last_ran != vcpu->vcpu_id) {
> + if (*last_ran != -1)
> + vcpu->arch.requires_tlbi = true;
> +
> + *last_ran = vcpu->vcpu_id;
> + }
> +}
> +
> void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
> {
> vcpu->cpu = cpu;
> diff --git a/arch/arm/kvm/hyp/switch.c b/arch/arm/kvm/hyp/switch.c
> index 92678b7..ab8ee3b 100644
> --- a/arch/arm/kvm/hyp/switch.c
> +++ b/arch/arm/kvm/hyp/switch.c
> @@ -75,6 +75,15 @@ static void __hyp_text __activate_vm(struct kvm_vcpu *vcpu)
> {
> struct kvm *kvm = kern_hyp_va(vcpu->kvm);
> write_sysreg(kvm->arch.vttbr, VTTBR);
> + if (vcpu->arch.requires_tlbi) {
> + /* Force vttbr to be written */
> + isb();
> + /* Local invalidate only for this VMID */
> + write_sysreg(0, TLBIALL);
> + dsb(nsh);
> + vcpu->arch.requires_tlbi = false;
> + }
> +
> write_sysreg(vcpu->arch.midr, VPIDR);
> }
>
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index bd94e67..5b42010 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -62,6 +62,8 @@ struct kvm_arch {
> /* VTTBR value associated with above pgd and vmid */
> u64 vttbr;
>
> + int __percpu *last_vcpu_ran;
> +
> /* The maximum number of vCPUs depends on the used GIC model */
> int max_vcpus;
>
> @@ -252,6 +254,9 @@ struct kvm_vcpu_arch {
> /* vcpu power-off state */
> bool power_off;
>
> + /* TLBI required */
> + bool requires_tlbi;
> +
> /* Don't run the guest (internal implementation need) */
> bool pause;
>
> @@ -368,7 +373,6 @@ static inline void __cpu_reset_hyp_mode(unsigned long vector_ptr,
> static inline void kvm_arch_hardware_unsetup(void) {}
> static inline void kvm_arch_sync_events(struct kvm *kvm) {}
> static inline void kvm_arch_vcpu_uninit(struct kvm_vcpu *vcpu) {}
> -static inline void kvm_arch_sched_in(struct kvm_vcpu *vcpu, int cpu) {}
> static inline void kvm_arch_vcpu_block_finish(struct kvm_vcpu *vcpu) {}
>
> void kvm_arm_init_debug(void);
> diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
> index 83037cd..8d9c3eb 100644
> --- a/arch/arm64/kvm/hyp/switch.c
> +++ b/arch/arm64/kvm/hyp/switch.c
> @@ -131,6 +131,14 @@ static void __hyp_text __activate_vm(struct kvm_vcpu *vcpu)
> {
> struct kvm *kvm = kern_hyp_va(vcpu->kvm);
> write_sysreg(kvm->arch.vttbr, vttbr_el2);
> + if (vcpu->arch.requires_tlbi) {
> + /* Force vttbr_el2 to be written */
> + isb();
> + /* Local invalidate only for this VMID */
> + asm volatile("tlbi vmalle1" : : );
> + dsb(nsh);
> + vcpu->arch.requires_tlbi = false;
> + }
> }
>
> static void __hyp_text __deactivate_vm(struct kvm_vcpu *vcpu)
> --
> 2.1.4
>
^ permalink raw reply
* [RFC PATCH 5/5] of: overlay-mgr: add a detector for headers stored on a ds2431 eeprom over w1
From: Matthias Brugger @ 2016-10-27 9:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026145756.21689-6-antoine.tenart@free-electrons.com>
On 10/26/2016 04:57 PM, Antoine Tenart wrote:
> Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
> ---
Please provide a commit message.
> drivers/of/overlay-manager/Kconfig | 10 ++++++++++
> drivers/w1/slaves/w1_ds2431.c | 39 ++++++++++++++++++++++++++++++++++++++
> 2 files changed, 49 insertions(+)
>
> diff --git a/drivers/of/overlay-manager/Kconfig b/drivers/of/overlay-manager/Kconfig
> index 1a36613c0c53..ad0a5b8e9e5e 100644
> --- a/drivers/of/overlay-manager/Kconfig
> +++ b/drivers/of/overlay-manager/Kconfig
> @@ -16,4 +16,14 @@ config OF_OVERLAY_MGR_FORMAT_CHIP
>
> endmenu
>
> +menu "Overlay Manager detectors"
> +
> +config OF_OVERLAY_MGR_DETECTOR_DS2431
> + bool "Dip header on a DS2431 EEPROM"
> + depends on W1_SLAVE_DS2431
> + help
> + Enable dip header DS2431 EEPROM support.
> +
> +endmenu
> +
> endif
> diff --git a/drivers/w1/slaves/w1_ds2431.c b/drivers/w1/slaves/w1_ds2431.c
> index 80572cb63ba8..760325f9a2bd 100644
> --- a/drivers/w1/slaves/w1_ds2431.c
> +++ b/drivers/w1/slaves/w1_ds2431.c
> @@ -15,6 +15,9 @@
> #include <linux/device.h>
> #include <linux/types.h>
> #include <linux/delay.h>
> +#include <linux/slab.h>
> +
> +#include <linux/overlay-manager.h>
>
> #include "../w1.h"
> #include "../w1_int.h"
> @@ -280,7 +283,43 @@ static const struct attribute_group *w1_f2d_groups[] = {
> NULL,
> };
>
> +#if IS_ENABLED(CONFIG_OF_OVERLAY_MGR_DETECTOR_DS2431)
> +static int chip_dip_callback(struct w1_slave *sl)
> +{
> + char **candidates = NULL;
> + int i, n, err = 0;
> + u8 *data;
> +
> + data = kzalloc(OVERLAY_MGR_DIP_MAX_SZ, GFP_KERNEL);
> + if (!data)
> + return -ENOMEM;
> +
> + /* sizeof(struct chip_header) is a mulitple of 8 */
> + for (i = 0; i < OVERLAY_MGR_DIP_MAX_SZ; i += 8) {
> + if (w1_f2d_readblock(sl, i, 8, &data[i])) {
> + err = -EIO;
> + goto end;
> + }
> + }
> +
> + overlay_mgr_parse(&sl->dev, data, &candidates, &n);
> + if (!n) {
> + err = -EINVAL;
> + goto end;
> + }
> +
> + err = overlay_mgr_apply(&sl->dev, candidates, n);
> +
> +end:
> + kfree(data);
> + return err;
> +}
> +#endif
> +
> static struct w1_family_ops w1_f2d_fops = {
> +#if IS_ENABLED(CONFIG_OF_OVERLAY_MGR_DETECTOR_DS2431)
> + .callback = chip_dip_callback,
> +#endif
> .groups = w1_f2d_groups,
> };
>
>
^ permalink raw reply
* [PATCH 2/5] Documentation: devicetree: net: add NS2 bindings to amac
From: Andrew Lunn @ 2016-10-27 9:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477510561-17035-3-git-send-email-jon.mason@broadcom.com>
On Wed, Oct 26, 2016 at 03:35:58PM -0400, Jon Mason wrote:
> Signed-off-by: Jon Mason <jon.mason@broadcom.com>
> ---
> Documentation/devicetree/bindings/net/brcm,amac.txt | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/brcm,amac.txt b/Documentation/devicetree/bindings/net/brcm,amac.txt
> index ba5ecc1..f92caee 100644
> --- a/Documentation/devicetree/bindings/net/brcm,amac.txt
> +++ b/Documentation/devicetree/bindings/net/brcm,amac.txt
> @@ -2,15 +2,18 @@ Broadcom AMAC Ethernet Controller Device Tree Bindings
> -------------------------------------------------------------
>
> Required properties:
> - - compatible: "brcm,amac" or "brcm,nsp-amac"
> + - compatible: "brcm,amac", "brcm,nsp-amac", or "brcm,ns2-amac"
> - reg: Address and length of the GMAC registers,
> Address and length of the GMAC IDM registers
> + Address and length of the NIC Port Manager registers (optional)
> - reg-names: Names of the registers. Must have both "amac_base" and
> - "idm_base"
> + "idm_base". "nicpm_base" is optional (required for NS2)
> - interrupts: Interrupt number
>
> Optional properties:
> - mac-address: See ethernet.txt file in the same directory
> +- brcm,enet-phy-lane-swap:
> + boolean; Swap the PHY lanes (needed on some SKUs of NS2)
Maybe i'm missing something here, but the patch to the PHY swapped the
lanes. This seems to be a PHY property, not a MAC property. And it
swapped them unconditionally....
Andrew
^ permalink raw reply
* [PATCH 1/5] net: phy: broadcom: Add BCM54810 phy entry
From: Andrew Lunn @ 2016-10-27 9:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477510561-17035-2-git-send-email-jon.mason@broadcom.com>
On Wed, Oct 26, 2016 at 03:35:57PM -0400, Jon Mason wrote:
> From: Vikas Soni <vsoni@broadcom.com>
>
> Add BCM54810 phy entry
Hi Jon, Vikis
The subject line is a bit misleading. It does more than add a PHY ID
entry.
> Signed-off-by: Vikas Soni <vsoni@broadcom.com>
> Signed-off-by: Jon Mason <jon.mason@broadcom.com>
> ---
> drivers/net/phy/Kconfig | 2 +-
> drivers/net/phy/broadcom.c | 65 ++++++++++++++++++++++++++++++++++++++++++++++
> include/linux/brcmphy.h | 7 +++++
> 3 files changed, 73 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
> index 45f68ea..31967ca 100644
> --- a/drivers/net/phy/Kconfig
> +++ b/drivers/net/phy/Kconfig
> @@ -217,7 +217,7 @@ config BROADCOM_PHY
> select BCM_NET_PHYLIB
> ---help---
> Currently supports the BCM5411, BCM5421, BCM5461, BCM54616S, BCM5464,
> - BCM5481 and BCM5482 PHYs.
> + BCM5481, BCM54810 and BCM5482 PHYs.
>
> config CICADA_PHY
> tristate "Cicada PHYs"
> diff --git a/drivers/net/phy/broadcom.c b/drivers/net/phy/broadcom.c
> index 870327e..cdce761 100644
> --- a/drivers/net/phy/broadcom.c
> +++ b/drivers/net/phy/broadcom.c
> @@ -35,6 +35,35 @@ static int bcm54xx_auxctl_write(struct phy_device *phydev, u16 regnum, u16 val)
> return phy_write(phydev, MII_BCM54XX_AUX_CTL, regnum | val);
> }
>
> +static int bcm54810_config(struct phy_device *phydev)
> +{
> + int rc;
> +
> + /* Disable BroadR-Reach */
> + rc = bcm_phy_write_exp(phydev, BCM54810_EXP_BROADREACH_LRE_MISC_CTL, 0);
> + if (rc < 0)
> + return rc;
> +
> + /* SKEW DISABLE */
> + rc = bcm54xx_auxctl_write(phydev, MII_BCM54XX_AUXCTL_SHDWSEL_MISC,
> + 0xF0E0);
> + if (rc < 0)
> + return rc;
> +
> + /* DELAY DISABLE */
> + rc = bcm54xx_auxctl_write(phydev, MII_BCM54XX_AUXCTL_SHDWSEL_MISC,
> + 0x7000);
This driver mostly uses symbolic names, not #defines. Please can you
use #defines here and else were in this patch.
> + if (rc < 0)
> + return rc;
> +
> + /* DELAY DISABLE */
> + rc = bcm_phy_write_shadow(phydev, BCM54810_SHD_CLK_CTL, 0);
> + if (rc < 0)
> + return rc;
Twice the same comment?
> +
> + return 0;
> +}
> +
> /* Needs SMDSP clock enabled via bcm54xx_phydsp_config() */
> static int bcm50610_a0_workaround(struct phy_device *phydev)
> {
> @@ -207,6 +236,20 @@ static int bcm54xx_config_init(struct phy_device *phydev)
> (phydev->dev_flags & PHY_BRCM_AUTO_PWRDWN_ENABLE))
> bcm54xx_adjust_rxrefclk(phydev);
>
> + if (BRCM_PHY_MODEL(phydev) == PHY_ID_BCM54810) {
> + err = bcm54810_config(phydev);
> + if (err)
> + return err;
> +
> + reg = phy_read(phydev, MII_BMCR);
> + if (reg < 0)
> + return reg;
> +
> + err = phy_write(phydev, MII_BMCR, reg & ~BMCR_PDOWN);
> + if (err)
> + return err;
This seems a bit odd. I would expect the PHY core correctly handles
the PHY being powered down. Can you explain this a bit more, why it is
needed.
Thanks
Andrew
^ permalink raw reply
* Add Allwinner Q8 tablets hardware manager
From: Hans de Goede @ 2016-10-27 9:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJ-oXjQbOkrkNToEXYmPUZOgYBGbxQREZ4NL4bMcZmG=KP2vQQ@mail.gmail.com>
Hi,
On 27-10-16 01:45, Pierre-Hugues Husson wrote:
> Hi,
>
> 2016-10-26 13:46 GMT+02:00 Hans de Goede <hdegoede at redhat.com <mailto:hdegoede@redhat.com>>:
>
>> And as I tried to explain before, for this specific use-case describing
>> all this board specific knowledge in a generic manner in dt is simply
>> impossible, unless we add a turing complete language to dt aka aml.
>
>
> You keep saying this is a "specific use-case", but I don't agree.
> Most of cheap phone and tablets SoC manufacturer's Linux variant that I know of have (rather stupid) auto-detection methods.
True.
> Not every phone manufacturer use it, because some have proper and constant supply chain, but still, that's not always the case.
> For instance you might look at this dts: https://github.com/Dee-UK/RK3288_Lollipop_Kernel/commit/9e056a10b0a773d285e8d2ae819e7c2451816492#diff-b25e1abc92522c85e9ef28704bf9284aR410
> This DTS is meant, like what you do, to be compatible with as many devices as possible at once.
> So it declares 4 different PMICs (and no they will never all be there at the same time), and two different accelerometers, 3 audio codecs, and two touchscreens.
> Or you can look at CodeAurora (Qualcomm public opensource tree) DTSs and see that a standard DTS support at least three different panels ( see https://github.com/omnirom/android_kernel_oppo_msm8974/blob/27080b724f4cf281d598e7830abc5fc1292b5803/arch/arm/boot/dts/msm8974-mtp.dtsi#L15 )
> And that's the fairly clean examples. Some SoC kernels are still using good old platform_data detection methods.
>
> Thus I believe that having a board-specific driver is not a good thing, because we would get many of those.
In my experience with these cheap boards, there is a mix of auto-probing +
device / revision specific os-image modifications. I keep coming back to
the touchscreen controller firmware (but also the orientation), for the
gsl1680 controller I need at least 2 different firmware files (per gsl1680
revision) to make all q8 tablets I have working. This is simply not solved
by the vendor android code, they just shove the right firmware into the
os-image. Likewise for the touchscreen orientation (x-mirored, y-mirored,
etc) too is just a hard-coded setting in the os-image.
Thinking more about this, we may be able to come up with a generic way to
deal with i2c device detection, just like many vendor os-images are doing.
The kernel actually already has a detect() method in struct i2c_driver,
we could use that (we would need to implement it in drivers which do not
have it yet). Note on second thought it seems it may be better to use
probe() for this, see below.
Then we could have something like this in dt:
&i2c0 {
touchscreen1: gsl1680 at 40 {
reg = <0x40>;
compatible = "silead,gsl1680";
enable-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
status = "disabled";
};
touchscreen2: ektf2127 at 15 {
reg = <0x15>;
compatible = "elan,ektf2127";
enable-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
status = "disabled";
};
i2c-probe-stop-at-first-match = <&touchscreen1>, <&touchscreen2>;
}
Which would make the i2c subsys call detect (*) on each device, until
a device is found. Likewise we could have a "i2c-probe-all" property
which also walks a list of phandles but does not stop on the first
match.
Mark would something like this scheme work for you ?
Note that things are not this simple though, there are multiple challenges
with this approach:
1) pinctrl, even the detect() method of the driver may need to use
e.g. some gpios so we would need to activate pinctrl as normally the
kernel device core would do this before calling probe(). This is solvable,
but I wonder if we need to mention anything about this in the bindings
docs ? Note this would be solved by just instantiating the client / device
and then try probe().
2) Note the enable-gpios, those will need to be handled in the detect()
method, but this requires a device to be instantiated to call devm_get_...
on, likewise for other resources.
Alternatively the probe code could know about this (as part of the
i2c-probe-stop-at-first-match binding) and enable it before probing ?
3) Optional regulators, I've one q8 tablet where the touchscreen is
powered by a separate regulator, currently my hardware-mgr simply
first tries to probe all possible models with the regulator disabled
(and stops at -ETIMEDOUT which means the i2c bus is stuck and further
probing without enabling the regulator is useless).
How do we deal with this? This is a tricky one do we do this in
the code which walks over the i2c-probe-stop-at-first-match list,
or do we punt this to the driver?
Sofar I've only seen this with one type of touchscreen so an easy cop-out
would be to add an "optional-vddio-supply" to the the bindings for the
specific touchscreen use and put all the necessary logic in the driver.
This does require propagating the learned need for the regulator
from the drivers detect() callback to probe() or alternatively I'm
thinking we should just use probe() instead of detect()to begin with,
that will save a lot of duplication with things
like code for enable gpio-s and regulators.
So assuming we go for the cop-out option for 3. (I'm ok with that),
this would be a pretty clean solution adding just the 2 new:
i2c-probe-stop-at-first-match and i2c-probe-all properties to
the i2c-bus bindings. One problem here is that we may want to have
multiple i2c-probe-stop-at-first-match phandle lists on a single bus
(e.g. try 3 touchscreens + 6 accelerometers on the same bus, stop at
first touchscreen / first accelerometer), anyone have any ideas for
that?
*) Yes this sounds Linux specific, but it really is just "execute to-be-probed
device compatible specific detection method"
> When it comes to detection, I've witnessed various things.
> It can be kernel-side or bootloader-side "global setting" reading (like an ADC/resistor value, or an OTP), it can be bootloader doing the "brute-force", or it can be the kernel doing all the probes.
>
> For instance, as of today, on a Spreadtrum ODM tree, the bootloader will detect the screen by testing all knowns screens, the screen-drivers declare a get_id function, and the bootloader probes until the get_id matches the id declared by the screen driver.
> And then the bootloader tells the kernel, via cmdline, which screen is actually there (but auto-detection is also coded in kernel).
> Finally all possible sensors/touchscreen/camera are declared in DTS, and probe will filter-out N/C ones in the kernel.
>
> Now the big difference between my experience and what Hans is trying to do, is that I've always worked with devices with "safely" queriable IDs, either on i2c or dsi. I've never encountered SPI. This makes probing inherently more dangerous, but I believe the question roughly remains the same.
I'm dealing with i2c too, Mark mistakenly used SPI in his reply,
which I think is what got you thinking I've SPI.
> I understand Mark's will of taking care of this "earlier" (either bootloader or a later kernel-loader (pxa-impedance-matcher)), but I feel like this is only giving the problem to someone else.
Big ack to this, moving this to the bootloader is not solving the
problem, it just moves the problem elsewhere.
> I think that those auto-detection methods should be declared in a device-tree, though as Hans noted, this might end to be a turing-complete language.
See above, I think that we can make this work by delegating the actual
detection to the driver (so each compatible can have a different detect method / code).
So with this we can remove a big part of drivers/misc/q8-hardwaremgr.c, but not all
of it. We still need board specific code somewhere to deal with things like picking
the right touchscreen firmware and touchscreen orientation. This is all somewhat
gsl1680 specific.
I actually have the same problem on x86 where the ACPI description of the device
basically says: "There is a gsl1680 at this bus at this address" and does not say
anything about firmware / orientation (again this is simply hardcoded
in the os-image these devices ship with).
For x86 my plan is to have an array of configs in the driver and select the right
one based on DMI strings, which is in essence putting board specific info in the
driver.
I can imagine mirroring this for ARM, and have an array of configs in the driver
there too (for cases where cannot simply hardcode everything in dt only) and have
some board specific code (activated by of_machine_is_compatible()) to select the
right config.
> In my experience, I have never encountered a device requiring more than ordered probes, but backward compatibility was expected. (i.e. if IDs couldn't help distinguish two devices, the manufacturer would add another way to identify)
>
> As to whether this is bootloader's job or kernel's job, I don't have a really strong opinion.
> On one side, the kernel has all the drivers and probe functions, this would need little work to make this work.
> On the other side, if the "rules" are something like "read bus XXX, address YYY, expect ZZZ", the bootloader can handle it as well. But I don't think it is a good idea to have the bootloader know all the gsensor/screen/camera/... drivers (even if they are partial drivers dedicated to detection only)
Ack I to really believe this belongs in the kernel. Thank you for your reply,
it has made me realized that there are 2 problems here:
1) auto-detect of i2c-devices from a fixed list of i2c devices the board may
have, for this we really need 2 bits: a) generic mechanism to describe this,
call the driver detect methods b) hardware (compatible) specific detection
routines. b) really belongs in the driver, and since things like sensor
drivers (another good example btw) do not belong in the bootloader we
really need this bit in the kernel.
If we can get some consensus on this I'm willing to work on this
(as time allows, this is a spare time project). At least up to feature parity
with my current hard-coded q8-hardwaremgr.c, which in hind-sight indeed is
ugly as the detect code really belongs in the driver (I've been copy and
pasting about 10 - 30 lines from each driver into q8-hardwaremgr.c).
2) miscellaneous extra config on top of figuring out which ICs are connected,
basically the kind of stuff many vendors simply hard-code in their device
specific os-image. This one is much more difficult to deal with and I think
we need to figure this out on a case by case basis. This will require board
specific code (just like the kernel has tons of DMI string activated board
specific code on x86) and what is the best code for this place to live will
be a case by case thing too.
Regards,
Hans
^ permalink raw reply
* [PATCH v3] drivers: psci: PSCI checker module
From: Lorenzo Pieralisi @ 2016-10-27 9:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026181148.GW3716@linux.vnet.ibm.com>
On Wed, Oct 26, 2016 at 11:11:48AM -0700, Paul E. McKenney wrote:
> 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?
Yes if it can be extracted as a check (but it should also prevent the
torture tests from running and vice versa), either that or Kconfig
dependency (which we could do as a first step, waiting to add the
required interface to the torture test code ?).
Thanks !
Lorenzo
^ permalink raw reply
* [PATCH 9/9] Input: wm97xx: add new AC97 bus support
From: Charles Keepax @ 2016-10-27 9:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477510907-23495-10-git-send-email-robert.jarzmik@free.fr>
On Wed, Oct 26, 2016 at 09:41:47PM +0200, Robert Jarzmik wrote:
> This adds support for the new AC97 bus code, which discovers the devices
> rather than uses platform data.
>
> As part of this discovery, it enables a multi-function device wm97xx,
> which supports touchscreen, battery, ADC and an audio codec. This patch
> adds the code to bind the touchscreen "cell" as the touchscreen driver.
>
> This was tested on the pxa architecture with a pxa270 + wm9713 + the
> mioa701 touchscreen.
>
> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
> ---
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Thanks,
Charles
^ permalink raw reply
* [PATCH 8/9] mfd: wm97xx-core: core support for wm97xx Codec
From: Charles Keepax @ 2016-10-27 9:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477510907-23495-9-git-send-email-robert.jarzmik@free.fr>
On Wed, Oct 26, 2016 at 09:41:46PM +0200, Robert Jarzmik wrote:
> The WM9705, WM9712 and WM9713 are highly integrated codecs, with an
> audio codec, DAC and ADC, GPIO unit and a touchscreen interface.
>
> Historically the support was spread across drivers/input/touchscreen and
> sound/soc/codecs. The sharing was done through ac97 bus sharing. This
> model will not withstand the new AC97 bus model, where codecs are
> discovered on runtime.
>
> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
> ---
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Thanks,
Charles
^ permalink raw reply
* [RFC PATCH 1/5] of: introduce the overlay manager
From: Matthias Brugger @ 2016-10-27 9:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026145756.21689-2-antoine.tenart@free-electrons.com>
On 10/26/2016 04:57 PM, Antoine Tenart wrote:
> The overlay manager is an in-kernel library helping to handle dt overlay
> loading when using capes.
>
> Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
> ---
> drivers/of/Kconfig | 2 +
> drivers/of/Makefile | 1 +
> drivers/of/overlay-manager/Kconfig | 6 +
> drivers/of/overlay-manager/Makefile | 1 +
> drivers/of/overlay-manager/overlay-manager.c | 199 +++++++++++++++++++++++++++
> include/linux/overlay-manager.h | 38 +++++
> 6 files changed, 247 insertions(+)
> create mode 100644 drivers/of/overlay-manager/Kconfig
> create mode 100644 drivers/of/overlay-manager/Makefile
> create mode 100644 drivers/of/overlay-manager/overlay-manager.c
> create mode 100644 include/linux/overlay-manager.h
>
> diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
> index bc07ad30c9bf..e57aeaf0bf4f 100644
> --- a/drivers/of/Kconfig
> +++ b/drivers/of/Kconfig
> @@ -116,4 +116,6 @@ config OF_OVERLAY
> config OF_NUMA
> bool
>
> +source "drivers/of/overlay-manager/Kconfig"
> +
> endif # OF
> diff --git a/drivers/of/Makefile b/drivers/of/Makefile
> index d7efd9d458aa..d738fd41271f 100644
> --- a/drivers/of/Makefile
> +++ b/drivers/of/Makefile
> @@ -16,3 +16,4 @@ obj-$(CONFIG_OF_OVERLAY) += overlay.o
> obj-$(CONFIG_OF_NUMA) += of_numa.o
>
> obj-$(CONFIG_OF_UNITTEST) += unittest-data/
> +obj-y += overlay-manager/
> diff --git a/drivers/of/overlay-manager/Kconfig b/drivers/of/overlay-manager/Kconfig
> new file mode 100644
> index 000000000000..eeb76054dcb8
> --- /dev/null
> +++ b/drivers/of/overlay-manager/Kconfig
> @@ -0,0 +1,6 @@
> +config OF_OVERLAY_MGR
> + bool "Device Tree Overlay Manager"
> + depends on OF_OVERLAY
> + help
> + Enable the overlay manager to handle automatic overlay loading when
> + devices are detected.
> diff --git a/drivers/of/overlay-manager/Makefile b/drivers/of/overlay-manager/Makefile
> new file mode 100644
> index 000000000000..86d2b53950e7
> --- /dev/null
> +++ b/drivers/of/overlay-manager/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_OF_OVERLAY_MGR) += overlay-manager.o
> diff --git a/drivers/of/overlay-manager/overlay-manager.c b/drivers/of/overlay-manager/overlay-manager.c
> new file mode 100644
> index 000000000000..a725d7e24d38
> --- /dev/null
> +++ b/drivers/of/overlay-manager/overlay-manager.c
> @@ -0,0 +1,199 @@
> +/*
> + * Copyright (C) 2016 - Antoine Tenart <antoine.tenart@free-electrons.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include <linux/firmware.h>
> +#include <linux/list.h>
> +#include <linux/of.h>
> +#include <linux/of_fdt.h>
> +#include <linux/overlay-manager.h>
> +#include <linux/slab.h>
> +#include <linux/spinlock.h>
> +
> +struct overlay_mgr_overlay {
> + struct list_head list;
> + char *name;
> +};
> +
> +LIST_HEAD(overlay_mgr_overlays);
> +LIST_HEAD(overlay_mgr_formats);
Maybe you can find some better names for this, or rename the structs.
This will make the code more readable.
> +DEFINE_SPINLOCK(overlay_mgr_lock);
> +DEFINE_SPINLOCK(overlay_mgr_format_lock);
As Thomas already said, a mutex should be fine. We are not doing any
time critical here, right?
> +
> +/*
> + * overlay_mgr_register_format()
> + *
> + * Adds a new format candidate to the list of supported formats. The registered
> + * formats are used to parse the headers stored on the dips.
> + */
> +int overlay_mgr_register_format(struct overlay_mgr_format *candidate)
> +{
> + struct overlay_mgr_format *format;
> + int err = 0;
> +
> + spin_lock(&overlay_mgr_format_lock);
> +
> + /* Check if the format is already registered */
> + list_for_each_entry(format, &overlay_mgr_formats, list) {
> + if (!strcpy(format->name, candidate->name)) {
> + err = -EEXIST;
> + goto err;
> + }
> + }
> +
> + list_add_tail(&candidate->list, &overlay_mgr_formats);
> +
> +err:
> + spin_unlock(&overlay_mgr_format_lock);
> + return err;
> +}
> +EXPORT_SYMBOL_GPL(overlay_mgr_register_format);
> +
> +/*
> + * overlay_mgr_parse()
> + *
> + * Parse raw data with registered format parsers. Fills the candidate string if
> + * one parser understood the raw data format.
> + */
> +int overlay_mgr_parse(struct device *dev, void *data, char ***candidates,
> + unsigned *n)
> +{
> + struct list_head *pos, *tmp;
> + struct overlay_mgr_format *format;
> +
> + list_for_each_safe(pos, tmp, &overlay_mgr_formats) {
> + format = list_entry(pos, struct overlay_mgr_format, list);
> +
> + format->parse(dev, data, candidates, n);
> + if (n > 0)
> + return 0;
> + }
> +
> + return -EINVAL;
> +}
> +EXPORT_SYMBOL_GPL(overlay_mgr_parse);
> +
> +static int overlay_mgr_check_overlay(struct device_node *node)
> +{
> + struct property *p;
> + const char *str = NULL;
> +
> + p = of_find_property(node, "compatible", NULL);
> + if (!p)
> + return -EINVAL;
> +
> + do {
> + str = of_prop_next_string(p, str);
> + if (of_machine_is_compatible(str))
> + return 0;
> + } while (str);
> +
> + return -EINVAL;
> +}
> +
> +/*
> + * _overlay_mgr_insert()
> + *
> + * Try to request and apply an overlay given a candidate name.
> + */
> +static int _overlay_mgr_apply(struct device *dev, char *candidate)
Should be __overlay_mgr_apply(...)
Cheers,
Matthias
^ permalink raw reply
* [PATCH v2 2/4] dt-bindings: Add TI SCI PM Domains
From: Tero Kristo @ 2016-10-27 9:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026220457.kvbd4wgtizdbndf3@rob-hp-laptop>
On 27/10/16 01:04, Rob Herring wrote:
> On Wed, Oct 19, 2016 at 03:33:45PM -0500, Dave Gerlach wrote:
>> Add a generic power domain implementation, TI SCI PM Domains, that
>> will hook into the genpd framework and allow the TI SCI protocol to
>> control device power states.
>>
>> Also, provide macros representing each device index as understood
>> by TI SCI to be used in the device node power-domain references.
>> These are identifiers for the K2G devices managed by the PMMC.
>>
>> Signed-off-by: Nishanth Menon <nm@ti.com>
>> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
>> ---
>> .../devicetree/bindings/soc/ti/sci-pm-domain.txt | 54 +++++++++++++
>> MAINTAINERS | 2 +
>> include/dt-bindings/genpd/k2g.h | 90 ++++++++++++++++++++++
>> 3 files changed, 146 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>> create mode 100644 include/dt-bindings/genpd/k2g.h
>>
>> diff --git a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>> new file mode 100644
>> index 000000000000..32f38a349656
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>> @@ -0,0 +1,54 @@
>> +Texas Instruments TI-SCI Generic Power Domain
>> +---------------------------------------------
>> +
>> +Some TI SoCs contain a system controller (like the PMMC, etc...) that is
>> +responsible for controlling the state of the IPs that are present.
>> +Communication between the host processor running an OS and the system
>> +controller happens through a protocol known as TI-SCI [1]. This pm domain
>> +implementation plugs into the generic pm domain framework and makes use of
>> +the TI SCI protocol power on and off each device when needed.
>> +
>> +[1] Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
>> +
>> +PM Domain Node
>> +==============
>> +The PM domain node represents the global PM domain managed by the PMMC,
>> +which in this case is the single implementation as documented by the generic
>> +PM domain bindings in Documentation/devicetree/bindings/power/power_domain.txt.
>> +
>> +Required Properties:
>> +--------------------
>> +- compatible: should be "ti,sci-pm-domain"
>> +- #power-domain-cells: Must be 0.
>> +- ti,sci: Phandle to the TI SCI device to use for managing the devices.
>> +
>> +Example:
>> +--------------------
>> +k2g_pds: k2g_pds {
>> + compatible = "ti,sci-pm-domain";
>> + #power-domain-cells = <0>;
>> + ti,sci = <&pmmc>;
>> +};
>
> Why not just make the PMMC node be the power-domain provider itself? If
> not that, then make this a child node of it. The same comment applies to
> all the SCI functions, but I guess I've already acked some of them.
This seems to be a bug in this documentation actually. ti,sci handle is
no longer supported, and all the sci stuff must be under the parent sci
node.
>
> I really don't like reviewing all these TI SCI bindings one by one. Each
> one on its own seems fine, but I don't see the full picture.
The full picture is represented under the documentation for the main
protocol support itself. See this patch:
https://patchwork.kernel.org/patch/9383281/
Copy pasted here as ref:
Example (K2G):
-------------
pmmc: pmmc {
compatible = "ti,k2g-sci";
...
my_clk_node: clk_node {
...
...
};
my_pd_node: pd_node {
...
...
};
};
^ permalink raw reply
* [PATCH 7/9] Input: wm97xx: split out touchscreen registering
From: Charles Keepax @ 2016-10-27 9:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477510907-23495-8-git-send-email-robert.jarzmik@free.fr>
On Wed, Oct 26, 2016 at 09:41:45PM +0200, Robert Jarzmik wrote:
> wm97xx-core does several things in it initialization :
> - touchscreen input device setup
> - battery device creation
>
> As the wm97xx is actually a multi-function device handling an audio
> codec, a touchscreen, a gpio block and an ADC, reshape the probing to
> isolate what is truly input/touchscreen specific from the remaining
> part.
>
> This is only code shuffling, there is no functional change.
>
> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
> ---
> drivers/input/touchscreen/wm97xx-core.c | 193 ++++++++++++++++++--------------
> 1 file changed, 112 insertions(+), 81 deletions(-)
>
> diff --git a/drivers/input/touchscreen/wm97xx-core.c b/drivers/input/touchscreen/wm97xx-core.c
> index 83cf11312fd9..50a110e2988b 100644
<snip>
> +static void wm97xx_remove_battery(struct wm97xx *wm)
> +{
> + platform_device_put(wm->battery_dev);
> +}
<snip>
> @@ -724,10 +757,8 @@ static int wm97xx_remove(struct device *dev)
> {
> struct wm97xx *wm = dev_get_drvdata(dev);
>
> - platform_device_unregister(wm->battery_dev);
> - platform_device_unregister(wm->touch_dev);
> - input_unregister_device(wm->input_dev);
> - kfree(wm);
> + wm97xx_remove_battery(wm);
The commit message says this is just shifting code around but the
platform_device_unregister for the battery_dev seems to have
turned into a platform_device_put here.
Thanks,
Charles
^ permalink raw reply
* [PATCH] fpga zynq: Check the bitstream for validity
From: Matthias Brugger @ 2016-10-27 8:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026225413.GA6220@obsidianresearch.com>
On 10/27/2016 12:54 AM, Jason Gunthorpe wrote:
> There is no sense in sending a bitstream we know will not work, and
> with the variety of options for bitstream generation in Xilinx tools
> it is not terribly clear or very well documented what the correct
> input should be, especially since auto-detection was removed from this
> driver.
>
> All Zynq full configuration bitstreams must start with the sync word in
> the correct byte order.
>
> Zynq is also only able to DMA dword quantities, so bitstreams must be
> a multiple of 4 bytes. This also fixes a DMA-past the end bug.
>
> Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
> ---
> drivers/fpga/zynq-fpga.c | 25 ++++++++++++++++---------
> 1 file changed, 16 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/fpga/zynq-fpga.c b/drivers/fpga/zynq-fpga.c
> index c2fb4120bd62..46a38772e7ee 100644
> --- a/drivers/fpga/zynq-fpga.c
> +++ b/drivers/fpga/zynq-fpga.c
> @@ -184,12 +184,26 @@ static int zynq_fpga_ops_write_init(struct fpga_manager *mgr, u32 flags,
>
> priv = mgr->priv;
>
> + /* All valid bitstreams are multiples of 32 bits */
> + if ((count % 4) != 0)
> + return -EINVAL;
> +
> err = clk_enable(priv->clk);
> if (err)
> return err;
>
> /* don't globally reset PL if we're doing partial reconfig */
> if (!(flags & FPGA_MGR_PARTIAL_RECONFIG)) {
> + /* Sanity check the proposed bitstream. It must start with the
> + * sync word in the correct byte order and be a multiple of 4
> + * bytes.
> + */
> + if (count <= 4 || buf[0] != 0x66 || buf[1] != 0x55 ||
> + buf[2] != 0x99 || buf[3] != 0xaa) {
This checks if the bit stream is bigger then 4 bytes. We error out
before, if it is smaller. So you should fix the wording in the comment
and check for count == 4.
Regards,
Matthias
^ permalink raw reply
* [PATCH] ARM: imx: gpc: Initialize all power domains
From: Lucas Stach @ 2016-10-27 8:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161019141556.GA18806@tiger>
Am Mittwoch, den 19.10.2016, 22:15 +0800 schrieb Shawn Guo:
> On Tue, Oct 11, 2016 at 02:53:33PM -0300, Fabio Estevam wrote:
> > When booting a kernel built with multi_v7_defconfig the following
> > probe error is seen:
> >
> > imx-gpc: probe of 20dc000.gpc failed with error -22
> >
> > Later on the kernel crashes like this:
> >
> > [ 1.723358] Unable to handle kernel NULL pointer dereference at virtual address 00000040
> > [ 1.731500] pgd = c0204000
> > [ 1.731863] hctosys: unable to open rtc device (rtc0)
> > [ 1.739301] [00000040] *pgd=00000000
> > [ 1.739310] Internal error: Oops: 5 [#1] SMP ARM
> > [ 1.739319] Modules linked in:
> > [ 1.739328] CPU: 1 PID: 95 Comm: kworker/1:4 Not tainted 4.8.0-11897-g6b5e09a #1
> > [ 1.739331] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
> > [ 1.739352] Workqueue: pm genpd_power_off_work_fn
> > [ 1.739356] task: ee63d400 task.stack: ee70a000
> > [ 1.739365] PC is at mutex_lock+0xc/0x4c
> > [ 1.739374] LR is at regulator_disable+0x2c/0x60
> > [ 1.739379] pc : [<c0bc0da0>] lr : [<c06e4b10>] psr: 60000013
> > [ 1.739379] sp : ee70beb0 ip : 10624dd3 fp : ee6e6280
> > [ 1.739382] r10: eefb0900 r9 : 00000000 r8 : c1309918
> > [ 1.739385] r7 : 00000000 r6 : 00000040 r5 : 00000000 r4 : 00000040
> > [ 1.739390] r3 : 0000004c r2 : 7fffd540 r1 : 000001e4 r0 : 00000040
> >
> > The gpc probe fails because of_genpd_add_provider_onecell() checks
> > if all the domains are initialized via pm_genpd_present() function
> > and it returns an error on the multi_v7_defconfig case.
>
> It's not clear to me why this is only with multi_v7_defconfig, not
> imx_v6_v7_defconfig. Also, is it a regression or long-standing issue?
It's a regression in v4.9 and should be applied as a fix.
I don't see the crash on imx_v6_v7_defconfig, but without this patch the
GPC no longer probes correctly on v4.9 and other dependent devices will
not show up at all.
Regards,
Lucas
^ permalink raw reply
* [PATCH v8 0/3] ARM: dts: imx6q: Add Engicam i.CoreM6 dts
From: Jagan Teki @ 2016-10-27 8:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477037153-20484-1-git-send-email-jteki@openedev.com>
Hi Shawn,
On Fri, Oct 21, 2016 at 1:35 PM, Jagan Teki <jteki@openedev.com> wrote:
> From: Jagan Teki <jagan@amarulasolutions.com>
>
> This is series add dts support for Engicam I.Core M6 qdl modules. just
> rebased on top of linux-next.
>
> Jagan Teki (3):
> ARM: dts: imx6q: Add Engicam i.CoreM6 Quad/Dual initial support
> ARM: dts: imx6q: Add Engicam i.CoreM6 DualLite/Solo initial support
> ARM: dts: imx6qdl-icore: Add FEC support
>
> arch/arm/boot/dts/Makefile | 2 +
> arch/arm/boot/dts/imx6dl-icore.dts | 59 ++++++++
> arch/arm/boot/dts/imx6q-icore.dts | 59 ++++++++
> arch/arm/boot/dts/imx6qdl-icore.dtsi | 265 +++++++++++++++++++++++++++++++++++
> 4 files changed, 385 insertions(+)
> create mode 100644 arch/arm/boot/dts/imx6dl-icore.dts
> create mode 100644 arch/arm/boot/dts/imx6q-icore.dts
> create mode 100644 arch/arm/boot/dts/imx6qdl-icore.dtsi
Please let me know if you have any inputs on this?
thanks!
--
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
^ permalink raw reply
* [PATCH 6/9] power_supply: wm97xx_battery: use power_supply_get_drvdata
From: Charles Keepax @ 2016-10-27 8:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477510907-23495-7-git-send-email-robert.jarzmik@free.fr>
On Wed, Oct 26, 2016 at 09:41:44PM +0200, Robert Jarzmik wrote:
> As the power supply framework provides a way to store and retrieve
> private supply data, use it.
>
> In the process, change the platform data for wm97xx_battery from a
> container of a single struct wm97xx_batt_pdata to the direct point to wm97xx_batt_pdata.
>
> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
> ---
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Thanks,
Charles
^ permalink raw reply
* [PATCH 4/9] ASoC: wm9713: add ac97 new bus support
From: Charles Keepax @ 2016-10-27 8:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477510907-23495-5-git-send-email-robert.jarzmik@free.fr>
On Wed, Oct 26, 2016 at 09:41:42PM +0200, Robert Jarzmik wrote:
> Add support for the new ac97 bus model, where devices are automatically
> discovered on AC-Links.
>
> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
> ---
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Thanks,
Charles
^ permalink raw reply
* [PATCH V3 0/8] IOMMU probe deferral support
From: Sricharan @ 2016-10-27 8:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <421e2b14-0231-d376-02a0-097423120b3d@arm.com>
Hi Robin,
>>
>>
>>
>>> [ 39.901592] iommu: Removing device 0000:08:00.0 from group 0
>
>Yikes, on second look, that definitely shouldn't be happening.
>Everything below is probably the resulting fallout.
[ 40.206703] vfio-pci 0000:08:00.0: Failed to setup iommu ops
I think the above print which says "failed to setup iommu_ops"
because the call ops->add_device failed in of_pci_iommu_configure
is the reason for the failure, in my case i simply do not get this even with
your scripts. ops->add_device succeeds in the rebind as well. So still
checking what could be happening in your case.
Regards,
Sricharan
>
>Robin.
>
>>> [ 39.907383] ------------[ cut here ]------------
>>> [ 39.911969] WARNING: CPU: 0 PID: 174 at
>>> arch/arm64/mm/dma-mapping.c:856 arch_teardown_dma_ops+0x48/0x68
>>> [ 39.921266] Modules linked in:
>>> [ 39.924290]
>>> [ 39.925766] CPU: 0 PID: 174 Comm: vfio Not tainted 4.9.0-rc2+ #1249
>>> [ 39.931967] Hardware name: ARM Juno development board (r1) (DT)
>>> [ 39.937826] task: ffffffc975ee9900 task.stack: ffffffc974d60000
>>> [ 39.943687] PC is at arch_teardown_dma_ops+0x48/0x68
>>> [ 39.948603] LR is at arch_teardown_dma_ops+0x34/0x68
>>> [ 39.953516] pc : [<ffffff80080948f8>] lr : [<ffffff80080948e4>]
>>> pstate: 60000145
>>> [ 39.960834] sp : ffffffc974d63ca0
>>> [ 39.964112] x29: ffffffc974d63ca0 x28: ffffffc974d60000
>>> [ 39.969377] x27: ffffff80088a2000 x26: 0000000000000040
>>> [ 39.974642] x25: 0000000000000123 x24: ffffffc976a48918
>>> [ 39.979907] x23: ffffffc974d63eb8 x22: ffffff8008db7550
>>> [ 39.985171] x21: 000000000000000d x20: ffffffc9763e9b50
>>> [ 39.990435] x19: ffffffc9763f20a0 x18: 0000000000000010
>>> [ 39.995699] x17: 0000007f99c18018 x16: ffffff80080c0580
>>> [ 40.000964] x15: ffffff8008bb7000 x14: 000137c100013798
>>> [ 40.006228] x13: ffffffffff000000 x12: ffffffffffffffff
>>> [ 40.011492] x11: 0000000000000018 x10: 000000000000000d
>>> [ 40.016757] x9 : 0000000040000000 x8 : 0000000000210d00
>>> [ 40.022021] x7 : 00000049771bc000 x6 : 00000000001f17ed
>>> [ 40.027286] x5 : ffffff80084c4208 x4 : 0000000000000080
>>> [ 40.032551] x3 : ffffffc975ea9800 x2 : ffffffbf25d7aa50
>>> [ 40.037815] x1 : 0000000000000000 x0 : 0000000000000080
>>> [ 40.043078]
>>> [ 40.044549] ---[ end trace 35c1e743d6e6c035 ]---
>>> [ 40.049117] Call trace:
>>> [ 40.051537] Exception stack(0xffffffc974d63ad0 to 0xffffffc974d63c00)
>>> [ 40.057914] 3ac0: ffffffc9763f20a0
>>> 0000008000000000
>>> [ 40.065668] 3ae0: ffffffc974d63ca0 ffffff80080948f8 ffffffbf25d7aa40
>>> ffffffc975ea9800
>>> [ 40.073421] 3b00: ffffffc974d60000 000000000002fc80 ffffffc976801e00
>>> ffffffc974d60000
>>> [ 40.081175] 3b20: ffffff80084c4208 0000000000000040 ffffff80088a2000
>>> ffffffc974d60000
>>> [ 40.088928] 3b40: ffffff80084caf78 ffffffc974d60000 ffffffc974d60000
>>> ffffffc974d60000
>>> [ 40.096682] 3b60: ffffffc975ea9800 ffffffc974d60000 0000000000000080
>>> 0000000000000000
>>> [ 40.104435] 3b80: ffffffbf25d7aa50 ffffffc975ea9800 0000000000000080
>>> ffffff80084c4208
>>> [ 40.112188] 3ba0: 00000000001f17ed 00000049771bc000 0000000000210d00
>>> 0000000040000000
>>> [ 40.119941] 3bc0: 000000000000000d 0000000000000018 ffffffffffffffff
>>> ffffffffff000000
>>> [ 40.127695] 3be0: 000137c100013798 ffffff8008bb7000 ffffff80080c0580
>>> 0000007f99c18018
>>> [ 40.135450] [<ffffff80080948f8>] arch_teardown_dma_ops+0x48/0x68
>>> [ 40.141400] [<ffffff8008764a14>] of_dma_deconfigure+0xc/0x18
>>> [ 40.147005] [<ffffff8008552804>] dma_deconfigure+0xc/0x18
>>> [ 40.152353] [<ffffff800853ba10>] __device_release_driver+0x88/0x120
>>> [ 40.158560] [<ffffff800853bacc>] device_release_driver+0x24/0x38
>>> [ 40.164507] [<ffffff800853a868>] unbind_store+0xe8/0x110
>>> [ 40.169767] [<ffffff8008539c70>] drv_attr_store+0x20/0x30
>>> [ 40.175113] [<ffffff800823ab18>] sysfs_kf_write+0x48/0x58
>>> [ 40.180458] [<ffffff8008239ea8>] kernfs_fop_write+0xb0/0x1d8
>>> [ 40.186063] [<ffffff80081c507c>] __vfs_write+0x1c/0x100
>>> [ 40.191237] [<ffffff80081c5e80>] vfs_write+0xa0/0x1b8
>>> [ 40.196239] [<ffffff80081c7274>] SyS_write+0x44/0xa0
>>> [ 40.201155] [<ffffff8008082ef0>] el0_svc_naked+0x24/0x28
>>> [ 40.206703] vfio-pci 0000:08:00.0: Failed to setup iommu ops
>>> [ 40.212382] vfio-pci: probe of 0000:08:00.0 failed with error -22
>>> [ 40.228075] ------------[ cut here ]------------
>>> [ 40.235263] WARNING: CPU: 1 PID: 174 at ./include/linux/kref.h:46
>>> kobject_get+0x64/0x88
>>> [ 40.243181] Modules linked in:
>>> [ 40.246201]
>>> [ 40.247673] CPU: 1 PID: 174 Comm: vfio Tainted: G W
>>> 4.9.0-rc2+ #1249
>>> [ 40.255076] Hardware name: ARM Juno development board (r1) (DT)
>>> [ 40.260932] task: ffffffc975ee9900 task.stack: ffffffc974d60000
>>> [ 40.266787] PC is at kobject_get+0x64/0x88
>>> [ 40.270840] LR is at iommu_bus_notifier+0x40/0x110
>>> [ 40.275577] pc : [<ffffff800834d20c>] lr : [<ffffff80084c3fd0>]
>>> pstate: 80000145
>>> [ 40.282894] sp : ffffffc974d63c00
>>> [ 40.286169] x29: ffffffc974d63c00 x28: ffffffc974d60000
>>> [ 40.291431] x27: ffffff80088a2000 x26: 0000000000000040
>>> [ 40.296692] x25: 0000000000000123 x24: ffffffc974c8f418
>>> [ 40.301953] x23: 0000000000000006 x22: ffffffc9763f10a0
>>> [ 40.307214] x21: ffffffc9763e9a00 x20: ffffffc9763f10a0
>>> [ 40.312474] x19: ffffffc9763ebc80 x18: 0000007fd65069e0
>>> [ 40.317734] x17: 0000007f8d0ae3c0 x16: ffffff80081c7230
>>> [ 40.322995] x15: 0000007f8d136588 x14: ffffffffffffffff
>>> [ 40.328255] x13: 0000000000000004 x12: 0000000000000030
>>> [ 40.333515] x11: 0000000000000030 x10: 0101010101010101
>>> [ 40.338775] x9 : feff716475687163 x8 : 7f7f7f7f7f7f7f7f
>>> [ 40.344035] x7 : feff716475687163 x6 : ffffffc976abf400
>>> [ 40.349295] x5 : ffffffc976abf400 x4 : 0000000000000000
>>> [ 40.354555] x3 : ffffff80084c3f90 x2 : ffffffc9763ebcb8
>>> [ 40.359814] x1 : 0000000000000001 x0 : ffffff8008d4f000
>>> [ 40.365074]
>>> [ 40.366542] ---[ end trace 35c1e743d6e6c036 ]---
>>> [ 40.371107] Call trace:
>>> [ 40.373523] Exception stack(0xffffffc974d63a30 to 0xffffffc974d63b60)
>>> [ 40.379895] 3a20: ffffffc9763ebc80
>>> 0000008000000000
>>> [ 40.387643] 3a40: ffffffc974d63c00 ffffff800834d20c ffffffc976812400
>>> ffffff8008237d94
>>> [ 40.395391] 3a60: ffffffbf25d78940 ffffffc974d60000 ffffffc975e259d8
>>> 0000000000005b81
>>> [ 40.403139] 3a80: ffffffc974d60000 ffffff8008d4b31f ffffff8008b0f000
>>> ffffffc976811c80
>>> [ 40.410887] 3aa0: ffffffc974d60000 ffffffc974d60000 ffffffc974d60000
>>> ffffff8008237000
>>> [ 40.418634] 3ac0: ffffffc975e259d8 ffffff8008b1b9a8 ffffff8008d4f000
>>> 0000000000000001
>>> [ 40.426382] 3ae0: ffffffc9763ebcb8 ffffff80084c3f90 0000000000000000
>>> ffffffc976abf400
>>> [ 40.434130] 3b00: ffffffc976abf400 feff716475687163 7f7f7f7f7f7f7f7f
>>> feff716475687163
>>> [ 40.441877] 3b20: 0101010101010101 0000000000000030 0000000000000030
>>> 0000000000000004
>>> [ 40.449625] 3b40: ffffffffffffffff 0000007f8d136588 ffffff80081c7230
>>> 0000007f8d0ae3c0
>>> [ 40.457372] [<ffffff800834d20c>] kobject_get+0x64/0x88
>>> [ 40.462455] [<ffffff80084c3fd0>] iommu_bus_notifier+0x40/0x110
>>> [ 40.468227] [<ffffff80080da288>] notifier_call_chain+0x50/0x90
>>> [ 40.473997] [<ffffff80080da694>] __blocking_notifier_call_chain+0x4c/0x90
>>> [ 40.480713] [<ffffff80080da6ec>] blocking_notifier_call_chain+0x14/0x20
>>> [ 40.487259] [<ffffff800853b9e4>] __device_release_driver+0x5c/0x120
>>> [ 40.493460] [<ffffff800853bacc>] device_release_driver+0x24/0x38
>>> [ 40.499402] [<ffffff800853a868>] unbind_store+0xe8/0x110
>>> [ 40.504656] [<ffffff8008539c70>] drv_attr_store+0x20/0x30
>>> [ 40.509997] [<ffffff800823ab18>] sysfs_kf_write+0x48/0x58
>>> [ 40.515337] [<ffffff8008239ea8>] kernfs_fop_write+0xb0/0x1d8
>>> [ 40.520936] [<ffffff80081c507c>] __vfs_write+0x1c/0x100
>>> [ 40.526104] [<ffffff80081c5e80>] vfs_write+0xa0/0x1b8
>>> [ 40.531100] [<ffffff80081c7274>] SyS_write+0x44/0xa0
>>> [ 40.536011] [<ffffff8008082ef0>] el0_svc_naked+0x24/0x28
>>> [ 40.541324] ata1.00: disabled
>>> [ 40.544878] sd 0:0:0:0: [sda] Synchronizing SCSI cache
>>> [ 40.550062] sd 0:0:0:0: [sda] Synchronize Cache(10) failed: Result:
>>> hostbyte=0x04 driverbyte=0x00
>>> [ 40.558871] sd 0:0:0:0: [sda] Stopping disk
>>> [ 40.563037] sd 0:0:0:0: [sda] Start/Stop Unit failed: Result:
>>> hostbyte=0x04 driverbyte=0x00
>>> [ 40.586990] Unable to handle kernel paging request at virtual address
>>> 0002003e
>>> [ 40.594702] pgd = ffffffc974c80000
>>> [ 40.598165] [0002003e] *pgd=00000009f5102003[ 40.602241] ,
>>> *pud=00000009f5102003
>>> , *pmd=0000000000000000[ 40.607694]
>>> [ 40.609171] Internal error: Oops: 96000006 [#1] PREEMPT SMP
>>> [ 40.614684] Modules linked in:
>>> [ 40.617712] CPU: 3 PID: 174 Comm: vfio Tainted: G W
>>> 4.9.0-rc2+ #1249
>>> [ 40.625118] Hardware name: ARM Juno development board (r1) (DT)
>>> [ 40.630977] task: ffffffc975ee9900 task.stack: ffffffc974d60000
>>> [ 40.636841] PC is at kobject_get+0x14/0x88
>>> [ 40.640897] LR is at iommu_get_domain_for_dev+0x1c/0x48
>>> [ 40.646068] pc : [<ffffff800834d1bc>] lr : [<ffffff80084c3dec>]
>>> pstate: 60000145
>>> [ 40.653387] sp : ffffffc974d63c60
>>> [ 40.656664] x29: ffffffc974d63c60 x28: ffffffc974d60000
>>> [ 40.661928] x27: ffffff80088a2000 x26: 0000000000000040
>>> [ 40.667193] x25: 0000000000000123 x24: ffffffc974c8f418
>>> [ 40.672457] x23: ffffffc974d63eb8 x22: ffffff8008dab568
>>> [ 40.677720] x21: 000000000000000d x20: ffffff8008dab568
>>> [ 40.682984] x19: 0000000000020002 x18: 0000000000000000
>>> [ 40.688246] x17: 0000000000000007 x16: 0000000000000001
>>> [ 40.693509] x15: ffffffc974cd091c x14: ffffffffffffffff
>>> [ 40.698773] x13: ffffffc974cd01cd x12: 0000000000000030
>>> [ 40.704036] x11: 0101010101010101 x10: 7f7f7f7f7f7f7f7f
>>> [ 40.709300] x9 : 0000000040000000 x8 : 0000000000210d00
>>> [ 40.714563] x7 : ffffffc975f95018 x6 : 0000000000000000
>>> [ 40.719826] x5 : 0000000000000000 x4 : ffffffc9763f1210
>>> [ 40.725088] x3 : 0000000000000000 x2 : ffffffc9763f10e8
>>> [ 40.730351] x1 : 0000000000000000 x0 : 0000000000020002
>>> [ 40.735613]
>>> [ 40.737085] Process vfio (pid: 174, stack limit = 0xffffffc974d60020)
>>> [ 40.743460] Stack: (0xffffffc974d63c60 to 0xffffffc974d64000)
>>> [ 40.749150] 3c60: ffffffc974d63c80 ffffff80084c3dec ffffffc9763e9a00
>>> ffffff80085377a4
>>> [ 40.756904] 3c80: ffffffc974d63ca0 ffffff80080948c4 ffffffc9763f10a0
>>> ffffff8008dab568
>>> [ 40.764658] 3ca0: ffffffc974d63cc0 ffffff8008764a14 ffffffc9763f10a0
>>> ffffff8008dab568
>>> [ 40.772411] 3cc0: ffffffc974d63cd0 ffffff8008552804 ffffffc974d63ce0
>>> ffffff800853ba10
>>> [ 40.780165] 3ce0: ffffffc974d63d00 ffffff800853bacc ffffffc9763f1100
>>> ffffffc9763f10a0
>>> [ 40.787918] 3d00: ffffffc974d63d20 ffffff800853a868 ffffff8008d68f18
>>> ffffffc9763f10a0
>>> [ 40.795672] 3d20: ffffffc974d63d50 ffffff8008539c70 000000000000000d
>>> ffffffc974c8f400
>>> [ 40.803425] 3d40: ffffffc9757d5880 0000000000000000 ffffffc974d63d60
>>> ffffff800823ab18
>>> [ 40.811178] 3d60: ffffffc974d63d70 ffffff8008239ea8 ffffffc974d63dc0
>>> ffffff80081c507c
>>> [ 40.818931] 3d80: 000000000000000d 0000000000000000 ffffffc974c8f100
>>> ffffffc974d63eb8
>>> [ 40.826684] 3da0: 000000001285f6a0 0000000000000015 0000000000000123
>>> ffffff80080bf6ac
>>> [ 40.834437] 3dc0: ffffffc974d63e40 ffffff80081c5e80 000000000000000d
>>> 0000000000000000
>>> [ 40.842190] 3de0: ffffffc974d63e30 ffffff80080c087c ffffffc974d63e20
>>> ffffff80081c5c0c
>>> [ 40.849943] 3e00: ffffffc974c8f100 0000000000000001 ffffffc974c8f100
>>> ffffffc974d63eb8
>>> [ 40.857696] 3e20: ffffffc974d63e40 ffffff80081c5f48 000000000000000d
>>> ffffffc974c8f100
>>> [ 40.865450] 3e40: ffffffc974d63e80 ffffff80081c7274 ffffffc974c8f100
>>> ffffffc974c8f100
>>> [ 40.873203] 3e60: 000000001285f6a0 000000000000000d 0000000060000000
>>> 0000000000000000
>>> [ 40.880956] 3e80: 0000000000000000 ffffff8008082ef0 0000000000000000
>>> 0000000000000001
>>> [ 40.888709] 3ea0: ffffffffffffffff 0000007f8d0ae3dc 0000000000000000
>>> 0000000000000000
>>> [ 40.896461] 3ec0: 0000000000000001 000000001285f6a0 000000000000000d
>>> 0000000000000000
>>> [ 40.904215] 3ee0: ae2e2e2e3f464b49 0000000000000000 000000001285f6b0
>>> 39322f392f2f2f2f
>>> [ 40.911968] 3f00: 0000000000000040 fefefeff2f2d2f2f 7f7f7f7f7f7f7f7f
>>> 0101010101010101
>>> [ 40.919721] 3f20: 0000000000000002 0000000000000004 ffffffffffffffff
>>> 0000007f8d136588
>>> [ 40.927474] 3f40: 0000000000000000 0000007f8d0ae3c0 0000007fd65069e0
>>> 00000000004ee000
>>> [ 40.935226] 3f60: 0000000000000001 000000001285f6a0 000000000000000d
>>> 0000000000000001
>>> [ 40.942980] 3f80: 0000000000000020 000000001285eed8 00000000004ba158
>>> 0000000000000000
>>> [ 40.950732] 3fa0: 0000000000000000 0000007fd6507f30 000000000040e74c
>>> 0000007fd6507130
>>> [ 40.958485] 3fc0: 0000007f8d0ae3dc 0000000060000000 0000000000000001
>>> 0000000000000040
>>> [ 40.966238] 3fe0: 0000000000000000 0000000000000000 0000002000103a00
>>> 4000000010000000
>>> [ 40.973986] Call trace:
>>> [ 40.976405] Exception stack(0xffffffc974d63a90 to 0xffffffc974d63bc0)
>>> [ 40.982780] 3a80: 0000000000020002
>>> 0000008000000000
>>> [ 40.990533] 3aa0: ffffffc974d63c60 ffffff800834d1bc ffffffc974d63ae0
>>> ffffff80085377a4
>>> [ 40.998287] 3ac0: ffffffc974d63b10 ffffff8008537424 ffffffc975e3ac28
>>> ffffffc975e3ac38
>>> [ 41.006041] 3ae0: ffffffc974d63b30 ffffff80081737cc ffffffc975e3ac38
>>> ffffff8008da62c0
>>> [ 41.013794] 3b00: ffffffc975e98100 ffffff80085401b0 0000000000000001
>>> ffffff8008540a08
>>> [ 41.021547] 3b20: 00000000000036b8 0000000000000040 0000000000020002
>>> 0000000000000000
>>> [ 41.029300] 3b40: ffffffc9763f10e8 0000000000000000 ffffffc9763f1210
>>> 0000000000000000
>>> [ 41.037053] 3b60: 0000000000000000 ffffffc975f95018 0000000000210d00
>>> 0000000040000000
>>> [ 41.044805] 3b80: 7f7f7f7f7f7f7f7f 0101010101010101 0000000000000030
>>> ffffffc974cd01cd
>>> [ 41.052558] 3ba0: ffffffffffffffff ffffffc974cd091c 0000000000000001
>>> 0000000000000007
>>> [ 41.060311] [<ffffff800834d1bc>] kobject_get+0x14/0x88
>>> [ 41.065398] [<ffffff80084c3dec>] iommu_get_domain_for_dev+0x1c/0x48
>>> [ 41.071607] [<ffffff80080948c4>] arch_teardown_dma_ops+0x14/0x68
>>> [ 41.077556] [<ffffff8008764a14>] of_dma_deconfigure+0xc/0x18
>>> [ 41.083161] [<ffffff8008552804>] dma_deconfigure+0xc/0x18
>>> [ 41.088509] [<ffffff800853ba10>] __device_release_driver+0x88/0x120
>>> [ 41.094715] [<ffffff800853bacc>] device_release_driver+0x24/0x38
>>> [ 41.100663] [<ffffff800853a868>] unbind_store+0xe8/0x110
>>> [ 41.105922] [<ffffff8008539c70>] drv_attr_store+0x20/0x30
>>> [ 41.111268] [<ffffff800823ab18>] sysfs_kf_write+0x48/0x58
>>> [ 41.116612] [<ffffff8008239ea8>] kernfs_fop_write+0xb0/0x1d8
>>> [ 41.122216] [<ffffff80081c507c>] __vfs_write+0x1c/0x100
>>> [ 41.127390] [<ffffff80081c5e80>] vfs_write+0xa0/0x1b8
>>> [ 41.132391] [<ffffff80081c7274>] SyS_write+0x44/0xa0
>>> [ 41.137307] [<ffffff8008082ef0>] el0_svc_naked+0x24/0x28
>>> [ 41.142567] Code: 910003fd f9000bf3 aa0003f3 b4000180 (3940f000)
>>> [ 41.148667] ---[ end trace 35c1e743d6e6c037 ]---
>>> Segmentation fault
>>> / #
>>>
>>>
>>> _______________________________________________
>>> linux-arm-kernel mailing list
>>> linux-arm-kernel at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
>
>
>_______________________________________________
>linux-arm-kernel mailing list
>linux-arm-kernel at lists.infradead.org
>http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/2] mm/memblock: prepare a capability to support memblock near alloc
From: Leizhen (ThunderTown) @ 2016-10-27 8:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161027072235.GB6454@dhcp22.suse.cz>
On 2016/10/27 15:22, Michal Hocko wrote:
> On Thu 27-10-16 10:41:24, Leizhen (ThunderTown) wrote:
>>
>>
>> On 2016/10/26 17:31, Michal Hocko wrote:
>>> On Wed 26-10-16 11:10:44, Leizhen (ThunderTown) wrote:
>>>>
>>>>
>>>> On 2016/10/25 21:23, Michal Hocko wrote:
>>>>> On Tue 25-10-16 10:59:17, Zhen Lei wrote:
>>>>>> If HAVE_MEMORYLESS_NODES is selected, and some memoryless numa nodes are
>>>>>> actually exist. The percpu variable areas and numa control blocks of that
>>>>>> memoryless numa nodes need to be allocated from the nearest available
>>>>>> node to improve performance.
>>>>>>
>>>>>> Although memblock_alloc_try_nid and memblock_virt_alloc_try_nid try the
>>>>>> specified nid at the first time, but if that allocation failed it will
>>>>>> directly drop to use NUMA_NO_NODE. This mean any nodes maybe possible at
>>>>>> the second time.
>>>>>>
>>>>>> To compatible the above old scene, I use a marco node_distance_ready to
>>>>>> control it. By default, the marco node_distance_ready is not defined in
>>>>>> any platforms, the above mentioned functions will work as normal as
>>>>>> before. Otherwise, they will try the nearest node first.
>>>>>
>>>>> I am sorry but it is absolutely unclear to me _what_ is the motivation
>>>>> of the patch. Is this a performance optimization, correctness issue or
>>>>> something else? Could you please restate what is the problem, why do you
>>>>> think it has to be fixed at memblock layer and describe what the actual
>>>>> fix is please?
>>>>
>>>> This is a performance optimization.
>>>
>>> Do you have any numbers to back the improvements?
>>
>> I have not collected any performance data, but at least in theory,
>> it's beneficial and harmless, except make code looks a bit
>> urly.
>
> The whole memoryless area is cluttered with hacks because everybody just
> adds pieces here and there to make his particular usecase work IMHO.
> Adding more on top for performance reasons which are even not measured
OK, I will ask my colleagues for help, whether some APPs can be used or not.
> to prove a clear win is a no go. Please step back try to think how this
> could be done with an existing infrastructure we have (some cleanups
OK, I will try to do it. But some infrastructures maybe only restricted in the
theoretical analysis, I don't have the related testing environment, so there is
no way to verify.
> while doing that would be hugely appreciated) and if that is not
> possible then explain why and why it is not feasible to fix that before
I think it will be feasible.
> you start adding a new API.
>
> Thanks!
>
^ 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