* [rjarzmik:work/ac97 8/13] sound/soc/codecs/wm9713.c:20:30: fatal error: linux/mfd/wm97xx.h: No such file or directory
From: kbuild test robot @ 2016-10-26 22:42 UTC (permalink / raw)
To: linux-arm-kernel
tree: https://github.com/rjarzmik/linux work/ac97
head: 223e9c527c425b1b519468e54fff9f4f82a7f390
commit: ded8ecc42087f1cdc4e356f118ea2e0d51691001 [8/13] ASoC: wm9713: add ac97 new bus support
config: m32r-allyesconfig (attached as .config)
compiler: m32r-linux-gcc (GCC) 6.2.0
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout ded8ecc42087f1cdc4e356f118ea2e0d51691001
# save the attached .config to linux build tree
make.cross ARCH=m32r
Note: the rjarzmik/work/ac97 HEAD 223e9c527c425b1b519468e54fff9f4f82a7f390 builds fine.
It only hurts bisectibility.
All errors (new ones prefixed by >>):
>> sound/soc/codecs/wm9713.c:20:30: fatal error: linux/mfd/wm97xx.h: No such file or directory
#include <linux/mfd/wm97xx.h>
^
compilation terminated.
vim +20 sound/soc/codecs/wm9713.c
14 * o Support for AC97 Codec, Voice DAC and Aux DAC
15 * o Support for DAPM
16 */
17
18 #include <linux/init.h>
19 #include <linux/slab.h>
> 20 #include <linux/mfd/wm97xx.h>
21 #include <linux/module.h>
22 #include <linux/device.h>
23 #include <linux/regmap.h>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 37174 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161027/e80c0cd2/attachment-0001.gz>
^ permalink raw reply
* [PATCH V4 3/3] ARM64 LPC: LPC driver implementation on Hip06
From: Rob Herring @ 2016-10-26 22:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476954940-242159-4-git-send-email-yuanzhichang@hisilicon.com>
On Thu, Oct 20, 2016 at 05:15:40PM +0800, zhichang.yuan wrote:
> On Hip06, the accesses to LPC peripherals work in an indirect way. A
> corresponding LPC driver configure some registers in LPC master at first, then
> the real accesses on LPC slave devices are finished by the LPC master, which
> is transparent to LPC driver.
> This patch implement the relevant driver for Hip06 LPC. Cooperating with
> indirect-IO, ipmi messages is in service without any changes on ipmi driver.
>
> Signed-off-by: zhichang.yuan <yuanzhichang@hisilicon.com>
> Signed-off-by: Gabriele Paoloni <gabriele.paoloni@huawei.com>
> ---
> .../arm/hisilicon/hisilicon-low-pin-count.txt | 31 ++
> MAINTAINERS | 8 +
> drivers/bus/Kconfig | 8 +
> drivers/bus/Makefile | 1 +
> drivers/bus/hisi_lpc.c | 501 +++++++++++++++++++++
> 5 files changed, 549 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
> create mode 100644 drivers/bus/hisi_lpc.c
>
> diff --git a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
> new file mode 100644
> index 0000000..e681419
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
> @@ -0,0 +1,31 @@
> +Hisilicon Hip06 low-pin-count device
> + Usually LPC controller is part of PCI host bridge, so the legacy ISA ports
> + locate on LPC bus can be accessed direclty. But some SoCs have independent
> + LPC controller, and access the legacy ports by triggering LPC I/O cycles.
> + Hisilicon Hip06 implements this LPC device.
> +
> +Required properties:
> +- compatible: should be "hisilicon,low-pin-count"
This should be an SoC specific compatible string.
> +- #address-cells: must be 2 which stick to the ISA/EISA binding doc.
> +- #size-cells: must be 1 which stick to the ISA/EISA binding doc.
> +- reg: base memory range where the register set for this device is mapped.
> +
> +Note:
> + The node name before '@' must be "isa" to represent the binding stick to the
> + ISA/EISA binding specification.
> +
> +Example:
> +
> +isa at a01b0000 {
> + compatible = "hisilicom,low-pin-count";
> + #address-cells = <2>;
> + #size-cells = <1>;
> + reg = <0x0 0xa01b0000 0x0 0x1000>;
> +
> + ipmi0: bt at e4 {
> + compatible = "ipmi-bt";
> + device_type = "ipmi";
> + reg = <0x01 0xe4 0x04>;
> + status = "disabled";
> + };
> +};
^ permalink raw reply
* [PATCH V4 2/3] ARM64 LPC: Add missing range exception for special ISA
From: Rob Herring @ 2016-10-26 22:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476954940-242159-3-git-send-email-yuanzhichang@hisilicon.com>
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.
> + 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.
> + 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.
> 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.
> + 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
* [PATCH 1/2] of, numa: Add function to disable of_node_to_nid().
From: Robert Richter @ 2016-10-26 22:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5810E112.3070908@caviumnetworks.com>
There has been some significant rework around
__alloc_pages_nodemask(), adding Mel and linux-mm.
-Robert
On 26.10.16 10:00:02, David Daney wrote:
> On 10/26/2016 06:43 AM, Robert Richter wrote:
> >On 25.10.16 14:31:00, David Daney wrote:
> >>From: David Daney <david.daney@cavium.com>
> >>
> >>On arm64 NUMA kernels we can pass "numa=off" on the command line to
> >>disable NUMA. A side effect of this is that kmalloc_node() calls to
> >>non-zero nodes will crash the system with an OOPS:
> >>
> >>[ 0.000000] [<fffffc00081bba84>] __alloc_pages_nodemask+0xa4/0xe68
> >>[ 0.000000] [<fffffc00082163a8>] new_slab+0xd0/0x57c
> >>[ 0.000000] [<fffffc000821879c>] ___slab_alloc+0x2e4/0x514
> >>[ 0.000000] [<fffffc000823882c>] __slab_alloc+0x48/0x58
> >>[ 0.000000] [<fffffc00082195a0>] __kmalloc_node+0xd0/0x2e0
> >>[ 0.000000] [<fffffc00081119b8>] __irq_domain_add+0x7c/0x164
> >>[ 0.000000] [<fffffc0008b75d30>] its_probe+0x784/0x81c
> >>[ 0.000000] [<fffffc0008b75e10>] its_init+0x48/0x1b0
> >>.
> >>.
> >>.
> >>
> >>This is caused by code like this in kernel/irq/irqdomain.c
> >>
> >> domain = kzalloc_node(sizeof(*domain) + (sizeof(unsigned int) * size),
> >> GFP_KERNEL, of_node_to_nid(of_node));
> >>
> >>When NUMA is disabled, the concept of a node is really undefined, so
> >>of_node_to_nid() should unconditionally return NUMA_NO_NODE.
> >>
> >>Add __of_force_no_numa() to allow of_node_to_nid() to be forced to
> >>return NUMA_NO_NODE.
> >>
> >>The follow on patch will call this new function from the arm64 numa
> >>code.
> >
> >Didn't that work before?
>
> I am fairly certain that it used to work.
>
> >numa=off just maps all mem to node 0.
>
> Yes, that is the current behavior.
>
> >If mem
> >allocation is requested for another node it should just fall back to a
> >node with mem (node 0 then).
>
> This is the root of the problem. The ITS code is allocating memory. It
> calls of_node_to_nid() to determine which node it resides on. The answer in
> the failing case is node-1. Since we have mapped all the memory to node-0
> the __kmalloc_node(..., 1) call fails with the OOPS shown.
>
> It could be that __kmalloc_node() used to allocate memory on a node other
> than the requested node if the request couldn't be met. But in v4.8 and
> later it produces that OOPS.
>
> If you pass a node containing free memory or NUMA_NO_NODE to
> __kmalloc_node(), the allocation succeeds.
>
> When we first did these patches, I advocated removing the numa=off feature,
> and requiring people to install usable firmware on their systems. That was
> rejected on the grounds that not everybody has the ability to change their
> firmware and we would like to allow NUMA kernels to run on systems with
> defective firmware by supplying this command line parameter. Now that I
> have seen requests from the wild for this, I think it is a good idea to
> allow numa=off to be used to work around this bad firmware.
>
> The change in this patch set is fairly small, and seems to get the job done.
> An alternative would be to change __kmalloc_node() to ignore the node
> parameter if the request cannot be made, but I assume that there were good
> reasons to have the current behavior, so that would be a much more
> complicated change to make.
>
>
>
> >I suspect there is something wrong with
> >the page initialization, see:
> >
> > http://www.spinics.net/lists/arm-kernel/msg535191.html
> > https://bugzilla.redhat.com/show_bug.cgi?id=1387793
> >
> >What is the complete oops?
> >
> >So I think k*alloc_node() must be able to handle requests to
> >non-existing nodes. Otherwise your fix is incomplete, assume a failed
> >of_numa_init() causing a dummy init but still some devices reporting a
> >node.
>
> .
> .
> .
> EFI stub: Booting Linux Kernel...
> EFI stub: Using DTB from configuration table
> EFI stub: Exiting boot services and installing virtual address map...
> [ 0.000000] Booting Linux on physical CPU 0x0
> [ 0.000000] Linux version 4.8.0-rc8-dd (ddaney at localhost.localdomain)
> (gcc version 4.8.5 20150623 (Red Hat 4.8.5-11) (GCC) ) #29 SMP Tue Sep 27
> 15:50:35 PDT 2016
> [ 0.000000] Boot CPU: AArch64 Processor [431f0a10]
> [ 0.000000] NUMA turned off
> [ 0.000000] earlycon: pl11 at MMIO 0x000087e024000000 (options '')
> [ 0.000000] bootconsole [pl11] enabled
> [ 0.000000] efi: Getting EFI parameters from FDT:
> [ 0.000000] efi: EFI v2.40 by Cavium Thunder cn88xx EFI
> jenkins_weekly_build_40-0-ga1f880f Sep 13 2016 17:05:35
> [ 0.000000] efi: ACPI=0xfffff000 ACPI 2.0=0xfffff014 SMBIOS
> 3.0=0x10ffafcf000
> [ 0.000000] cma: Reserved 512 MiB at 0x00000000c0000000
> [ 0.000000] NUMA disabled
> [ 0.000000] NUMA: Faking a node at [mem
> 0x0000000000000000-0x0000010fffffffff]
> [ 0.000000] NUMA: Adding memblock [0x1400000 - 0xfffdffff] on node 0
> [ 0.000000] NUMA: Adding memblock [0xfffe0000 - 0xffffffff] on node 0
> [ 0.000000] NUMA: Adding memblock [0x100000000 - 0xfffffffff] on node 0
> [ 0.000000] NUMA: Adding memblock [0x10000400000 - 0x10ffa38ffff] on node
> 0
> [ 0.000000] NUMA: Adding memblock [0x10ffa390000 - 0x10ffa41ffff] on node
> 0
> [ 0.000000] NUMA: Adding memblock [0x10ffa420000 - 0x10ffaeaffff] on node
> 0
> [ 0.000000] NUMA: Adding memblock [0x10ffaeb0000 - 0x10ffaffffff] on node
> 0
> [ 0.000000] NUMA: Adding memblock [0x10ffb000000 - 0x10ffffaffff] on node
> 0
> [ 0.000000] NUMA: Adding memblock [0x10ffffb0000 - 0x10fffffffff] on node
> 0
> [ 0.000000] NUMA: Initmem setup node 0 [mem 0x01400000-0x10fffffffff]
> [ 0.000000] NUMA: NODE_DATA [mem 0x10ffffae480-0x10ffffaff7f]
> [ 0.000000] Zone ranges:
> [ 0.000000] DMA [mem 0x0000000001400000-0x00000000ffffffff]
> [ 0.000000] Normal [mem 0x0000000100000000-0x0000010fffffffff]
> [ 0.000000] Movable zone start for each node
> [ 0.000000] Early memory node ranges
> [ 0.000000] node 0: [mem 0x0000000001400000-0x00000000fffdffff]
> [ 0.000000] node 0: [mem 0x00000000fffe0000-0x00000000ffffffff]
> [ 0.000000] node 0: [mem 0x0000000100000000-0x0000000fffffffff]
> [ 0.000000] node 0: [mem 0x0000010000400000-0x0000010ffa38ffff]
> [ 0.000000] node 0: [mem 0x0000010ffa390000-0x0000010ffa41ffff]
> [ 0.000000] node 0: [mem 0x0000010ffa420000-0x0000010ffaeaffff]
> [ 0.000000] node 0: [mem 0x0000010ffaeb0000-0x0000010ffaffffff]
> [ 0.000000] node 0: [mem 0x0000010ffb000000-0x0000010ffffaffff]
> [ 0.000000] node 0: [mem 0x0000010ffffb0000-0x0000010fffffffff]
> [ 0.000000] Initmem setup node 0 [mem
> 0x0000000001400000-0x0000010fffffffff]
> [ 0.000000] psci: probing for conduit method from DT.
> [ 0.000000] psci: PSCIv0.2 detected in firmware.
> [ 0.000000] psci: Using standard PSCI v0.2 function IDs
> [ 0.000000] psci: Trusted OS resident on physical CPU 0x0
> [ 0.000000] percpu: Embedded 3 pages/cpu @ffffff0ff6900000 s116736 r8192
> d71680 u196608
> [ 0.000000] Detected VIPT I-cache on CPU0
> [ 0.000000] CPU features: enabling workaround for Cavium erratum 27456
> [ 0.000000] Built 1 zonelists in Node order, mobility grouping on. Total
> pages: 2094720
> [ 0.000000] Policy zone: Normal
> [ 0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz-4.8.0-rc8-dd
> root=/dev/mapper/rhel-root ro crashkernel=auto rd.lvm.lv=rhel/root
> rd.lvm.lv=rhel/swap LANG=en_US.UTF-8 numa=off console=ttyAMA0,115200n8
> earlycon=pl011,0x87e024000000
> [ 0.000000] log_buf_len individual max cpu contribution: 4096 bytes
> [ 0.000000] log_buf_len total cpu_extra contributions: 389120 bytes
> [ 0.000000] log_buf_len min size: 524288 bytes
> [ 0.000000] log_buf_len: 1048576 bytes
> [ 0.000000] early log buf free: 519176(99%)
> [ 0.000000] PID hash table entries: 4096 (order: -1, 32768 bytes)
> [ 0.000000] software IO TLB [mem 0xfbfd0000-0xfffd0000] (64MB) mapped at
> [fffffe00fbfd0000-fffffe00fffcffff]
> [ 0.000000] Memory: 133391936K/134193152K available (7356K kernel code,
> 1359K rwdata, 3392K rodata, 1216K init, 6799K bss, 276928K reserved, 524288K
> cma-reserved)
> [ 0.000000] Virtual kernel memory layout:
> [ 0.000000] modules : 0xfffffc0000000000 - 0xfffffc0008000000 (
> 128 MB)
> [ 0.000000] vmalloc : 0xfffffc0008000000 - 0xfffffdff5fff0000 (
> 2045 GB)
> [ 0.000000] .text : 0xfffffc0008080000 - 0xfffffc00087b0000 (
> 7360 KB)
> [ 0.000000] .rodata : 0xfffffc00087b0000 - 0xfffffc0008b10000 (
> 3456 KB)
> [ 0.000000] .init : 0xfffffc0008b10000 - 0xfffffc0008c40000 (
> 1216 KB)
> [ 0.000000] .data : 0xfffffc0008c40000 - 0xfffffc0008d93e00 (
> 1360 KB)
> [ 0.000000] .bss : 0xfffffc0008d93e00 - 0xfffffc0009437d48 (
> 6800 KB)
> [ 0.000000] fixed : 0xfffffdff7e7d0000 - 0xfffffdff7ec00000 (
> 4288 KB)
> [ 0.000000] PCI I/O : 0xfffffdff7ee00000 - 0xfffffdff7fe00000 (
> 16 MB)
> [ 0.000000] vmemmap : 0xfffffdff80000000 - 0xfffffe0000000000 (
> 2 GB maximum)
> [ 0.000000] 0xfffffdff80005000 - 0xfffffdffc4000000 (
> 1087 MB actual)
> [ 0.000000] memory : 0xfffffe0001400000 - 0xffffff1000000000
> (1114092 MB)
> [ 0.000000] SLUB: HWalign=128, Order=0-3, MinObjects=0, CPUs=96, Nodes=1
> [ 0.000000] Hierarchical RCU implementation.
> [ 0.000000] Build-time adjustment of leaf fanout to 64.
> [ 0.000000] RCU restricting CPUs from NR_CPUS=4096 to nr_cpu_ids=96.
> [ 0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=64, nr_cpu_ids=96
> [ 0.000000] NR_IRQS:64 nr_irqs:64 0
> [ 0.000000] GICv3: GIC: Using split EOI/Deactivate mode
> [ 0.000000] ITS: /interrupt-controller at 801000000000/gic-its at 801000020000
> [ 0.000000] ITS at 0x0000801000020000: allocated 2097152 Devices
> @10001000000 (flat, esz 8, psz 64K, shr 1)
> [ 0.000000] ITS: /interrupt-controller at 801000000000/gic-its at 901000020000
> [ 0.000000] ITS at 0x0000901000020000: allocated 2097152 Devices
> @10002000000 (flat, esz 8, psz 64K, shr 1)
> [ 0.000000] Unable to handle kernel NULL pointer dereference at virtual
> address 00001680
> [ 0.000000] pgd = fffffc0009470000
> [ 0.000000] [00001680] *pgd=0000010ffff90003, *pud=0000010ffff90003,
> *pmd=0000010ffff90003, *pte=0000000000000000
> [ 0.000000] Internal error: Oops: 96000006 [#1] SMP
> [ 0.000000] Modules linked in:
> [ 0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.8.0-rc8-dd #29
> [ 0.000000] Hardware name: Cavium ThunderX CN88XX board (DT)
> [ 0.000000] task: fffffc0008c71c80 task.stack: fffffc0008c40000
> [ 0.000000] PC is at __alloc_pages_nodemask+0xa4/0xe68
> [ 0.000000] LR is at __alloc_pages_nodemask+0x38/0xe68
> [ 0.000000] pc : [<fffffc00081c8950>] lr : [<fffffc00081c88e4>] pstate:
> 600000c5
> [ 0.000000] sp : fffffc0008c43880
> [ 0.000000] x29: fffffc0008c43880 x28: ffffff000041fc00
> [ 0.000000] x27: 0000000000201200 x26: 0000000000000000
> [ 0.000000] x25: 0000000000000001 x24: 0000000000001680
> [ 0.000000] x23: 0000000000201200 x22: fffffc0008c439c8
> [ 0.000000] x21: fffffc0008c63000 x20: 0000000000201200
> [ 0.000000] x19: 0000000000000000 x18: 0000000000000070
> [ 0.000000] x17: 0000000000000008 x16: 0000000000000000
> [ 0.000000] x15: 0000000000000000 x14: 2820303030303030
> [ 0.000000] x13: 3230303031402073 x12: 6563697665442032
> [ 0.000000] x11: 0000000000000020 x10: fffffc0009334000
> [ 0.000000] x9 : 0000000001bfff3f x8 : 7f7f7f7f7f7f7f7f
> [ 0.000000] x7 : 0000000001210111 x6 : fffffdffc00010a0
> [ 0.000000] x5 : 0000000000000000 x4 : 0000000000000000
> [ 0.000000] x3 : 0000000000000000 x2 : 0000000000000000
> [ 0.000000] x1 : 0000000000000000 x0 : fffffc0008c63bb0
> [ 0.000000]
> [ 0.000000] Process swapper/0 (pid: 0, stack limit = 0xfffffc0008c40020)
> [ 0.000000] Stack: (0xfffffc0008c43880 to 0xfffffc0008c44000)
> [ 0.000000] 3880: fffffc0008c439f0 fffffc000821fa70 ffffff000041fc00
> 0000000000000200
> [ 0.000000] 38a0: fffffc0008115374 0000000000000000 0000000000000000
> 0000000000000001
> [ 0.000000] 38c0: 0000000000000000 0000000000000000 0000000000201200
> ffffff000041fc00
> [ 0.000000] 38e0: fffffc0008c43960 fffffc000810bc20 fffffc0008c43960
> fffffc0008c43960
> [ 0.000000] 3900: fffffc0008c43930 00000000ffffffd0 fffffc0008c43960
> fffffc0008c43960
> [ 0.000000] 3920: fffffc0008c43930 00000000ffffffd0 fffffc0008c43970
> fffffc0008221658
> [ 0.000000] 3940: 7f7f7f7f7f7f7f7f 0000000000000002 0101010101010101
> 0000000000000020
> [ 0.000000] 3960: fffffc0008c43a70 fffffc0008221c04 0000000000000001
> 00000000024080c0
> [ 0.000000] 3980: fffffc0008115374 fffffc0008bf8648 0000000000001000
> 0000000000000000
> [ 0.000000] 39a0: ffffff000041fc00 0000000000000001 ffffff0ff691e840
> ffffff000041fc00
> [ 0.000000] 39c0: ffffff0ff691e840 0000000000001680 0000000000000000
> 0000000000000000
> [ 0.000000] 39e0: 0000000100000000 0000000000000000 fffffc0008c43a70
> fffffc0008221e24
> [ 0.000000] 3a00: 0000000000000001 00000000024080c0 fffffc0008115374
> fffffc0008bf8648
> [ 0.000000] 3a20: 0000000000001000 0000000000000000 0000000000000000
> 0000000000000001
> [ 0.000000] 3a40: ffffff0ff691e840 ffffff000041fc00 fffffc000928a1e8
> 024080c000000006
> [ 0.000000] 3a60: fffffc0008ca6a38 000000000000005c fffffc0008c43b90
> fffffc0008239498
> [ 0.000000] 3a80: 00000000000000c0 ffffff000041fc00 ffffff0000424f00
> 0000000000000070
> [ 0.000000] 3aa0: 0000000000000001 fffffc0008115374 ffffff000041fc00
> fffffc00093f1000
> [ 0.000000] 3ac0: ffffff0002000000 ffffff0000433000 fffffc0008c43bd0
> fffffc0008a308f0
> [ 0.000000] 3ae0: 0000000000010000 0000020000000000 0000000000000000
> 0000000000000001
> [ 0.000000] 3b00: fffffc0008c43b30 fffffc000861f07c fffffc000941efc0
> 00000000000000c0
> [ 0.000000] 3b20: ffffff0ffff44e60 00000000000000c0 fffffc0008c43b70
> fffffc000861f234
> [ 0.000000] 3b40: ffffff0ffff44e60 0000000000000004 ffffff0ffff44e60
> fffffc0008c43c70
> [ 0.000000] 3b60: 0000000000000000 fffffc0008a74460 fffffc0008c43ba0
> fffffc000861f3fc
> [ 0.000000] 3b80: fffffc0008c43ba0 fffffc00083ca55c fffffc0008c43bd0
> fffffc0008222c20
> [ 0.000000] 3ba0: ffffff000041fc00 00000000024080c0 ffffff0ff691e840
> fffffc0008115374
> [ 0.000000] 3bc0: 0000000000000001 00000000024080c0 fffffc0008c43c20
> fffffc0008115374
> [ 0.000000] 3be0: 0000000000000070 ffffff0ffff44e80 ffffff0ffff44e60
> 0000000000000000
> [ 0.000000] 3c00: fffffc0008849a18 ffffffffffffffff 0000000000000000
> ffffff0000433000
> [ 0.000000] 3c20: fffffc0008c43c80 fffffc0008b461dc ffffff0000424e80
> 2800000000000000
> [ 0.000000] 3c40: 0000000000010000 0000020000000000 0000000000000000
> 0000000000000400
> [ 0.000000] 3c60: 0000000000000400 ffffff00004330f8 0000000000000001
> ffffff0ffffabe00
> [ 0.000000] 3c80: fffffc0008c43dc0 fffffc0008b462bc fffffc0008d33488
> fffffc0008d33000
> [ 0.000000] 3ca0: ffffff0ffff44e60 fffffc0008c6c840 ffffff0000424b00
> ffffff0000424880
> [ 0.000000] 3cc0: 0000000000000002 0000000000000000 0000000001bae074
> 0000000001f1001c
> [ 0.000000] 3ce0: 0000000000000000 fffffc0008a30890 ffffff0000424b00
> fffffc0008849940
> [ 0.000000] 3d00: ffffff0000433020 fffffc0008a308f0 ffffff0000433008
> ffffff0ffff44e60
> [ 0.000000] 3d20: fffffc000ac00000 0000000000000008 0000000000000001
> 8107000000000000
> [ 0.000000] 3d40: 00000000000000c0 0000000001000000 00000008fff44e60
> 0000010002000000
> [ 0.000000] 3d60: 0000000000000100 81070000000000ff fffffc0008c43dc0
> 0000000008b462cc
> [ 0.000000] 3d80: 0000901000020000 000090100021ffff ffffff0ffff44f08
> 0000000000000200
> [ 0.000000] 3da0: 0000000000000000 0000000000000000 0000000000000000
> 0000000000000000
> [ 0.000000] 3dc0: fffffc0008c43e10 fffffc0008b4543c fffffc0008c6c828
> fffffc0008d32000
> [ 0.000000] 3de0: fffffc0008c6c000 ffffff0ffff44470 fffffc0008849000
> ffffff0000424880
> [ 0.000000] 3e00: fffffc0008c43e10 fffffc0008b45420 fffffc0008c43e60
> fffffc0008b456bc
> [ 0.000000] 3e20: 0000000000000002 0000000000000003 0000000000000030
> ffffff0000424880
> [ 0.000000] 3e40: ffffff0ffff44470 0000000000000000 0000000000000018
> fffffc0008000000
> [ 0.000000] 3e60: fffffc0008c43f00 fffffc0008b5aec8 ffffff0000424700
> fffffc0008c43f60
> [ 0.000000] 3e80: fffffc0008c43f60 0000000000000000 fffffc0008c43f70
> fffffc0008d92000
> [ 0.000000] 3ea0: fffffc0008a734e0 fffffc0008a734b8 fffffc0008c43f00
> 0000000208b5ae3c
> [ 0.000000] 3ec0: 0000000000000000 00009010805fffff ffffff0ffff44518
> 0000000000000200
> [ 0.000000] 3ee0: 0000000000000000 0000000000000000 0000000000000000
> 0000000000000000
> [ 0.000000] 3f00: fffffc0008c43f80 fffffc0008b43f9c fffffc0008c60000
> fffffc0008b66628
> [ 0.000000] 3f20: fffffc0008b66628 fffffc0008dc0000 fffffc0008c60000
> ffffff0ffffac580
> [ 0.000000] 3f40: 0000000002840000 0000000002870000 0000000000000020
> 0000000000000000
> [ 0.000000] 3f60: fffffc0008c43f60 fffffc0008c43f60 fffffc0008c43f70
> fffffc0008c43f70
> [ 0.000000] 3f80: fffffc0008c43f90 fffffc0008b12d60 fffffc0008c43fa0
> fffffc0008b10a3c
> [ 0.000000] 3fa0: 0000000000000000 fffffc0008b101c4 0000010ff7a35218
> 0000000000000e12
> [ 0.000000] 3fc0: 0000000021200000 0000000030d00980 0000000000000000
> 0000000001400000
> [ 0.000000] 3fe0: 0000000000000000 fffffc0008b66628 0000000000000000
> 0000000000000000
> [ 0.000000] Call trace:
> [ 0.000000] Exception stack(0xfffffc0008c436b0 to 0xfffffc0008c437e0)
> [ 0.000000] 36a0: 0000000000000000
> 0000040000000000
> [ 0.000000] 36c0: fffffc0008c43880 fffffc00081c8950 ffffff0ffffaf180
> 0000000000000003
> [ 0.000000] 36e0: fffffc0008c63000 00000000ffffffff 0000000000000001
> 0000000000000000
> [ 0.000000] 3700: fffffc0008c43720 fffffc00081e25cc 0000000000000000
> 0000000001bfff3f
> [ 0.000000] 3720: fffffc0008c43750 fffffc00081c8454 0000000000000012
> 0000000000000000
> [ 0.000000] 3740: fffffffffffffff8 0000000000000012 fffffc0008c63bb0
> 0000000000000000
> [ 0.000000] 3760: 0000000000000000 0000000000000000 0000000000000000
> 0000000000000000
> [ 0.000000] 3780: fffffdffc00010a0 0000000001210111 7f7f7f7f7f7f7f7f
> 0000000001bfff3f
> [ 0.000000] 37a0: fffffc0009334000 0000000000000020 6563697665442032
> 3230303031402073
> [ 0.000000] 37c0: 2820303030303030 0000000000000000 0000000000000000
> 0000000000000008
> [ 0.000000] [<fffffc00081c8950>] __alloc_pages_nodemask+0xa4/0xe68
> [ 0.000000] [<fffffc000821fa70>] new_slab+0xd0/0x564
> [ 0.000000] [<fffffc0008221e24>] ___slab_alloc+0x2e4/0x514
> [ 0.000000] [<fffffc0008239498>] __slab_alloc+0x48/0x58
> [ 0.000000] [<fffffc0008222c20>] __kmalloc_node+0xd0/0x2dc
> [ 0.000000] [<fffffc0008115374>] __irq_domain_add+0x7c/0x164
> [ 0.000000] [<fffffc0008b461dc>] its_probe+0x784/0x81c
> [ 0.000000] [<fffffc0008b462bc>] its_init+0x48/0x1b0
> [ 0.000000] [<fffffc0008b4543c>] gic_init_bases+0x228/0x360
> [ 0.000000] [<fffffc0008b456bc>] gic_of_init+0x148/0x1cc
> [ 0.000000] [<fffffc0008b5aec8>] of_irq_init+0x184/0x298
> [ 0.000000] [<fffffc0008b43f9c>] irqchip_init+0x14/0x38
> [ 0.000000] [<fffffc0008b12d60>] init_IRQ+0xc/0x30
> [ 0.000000] [<fffffc0008b10a3c>] start_kernel+0x240/0x3b8
> [ 0.000000] [<fffffc0008b101c4>] __primary_switched+0x30/0x6c
> [ 0.000000] Code: 912ec2a0 b9403809 0a0902fb 37b007db (f9400300)
> [ 0.000000] ---[ end trace 0000000000000000 ]---
> [ 0.000000] Kernel panic - not syncing: Fatal exception
> [ 0.000000] ---[ end Kernel panic - not syncing: Fatal exception
>
>
> Same thing on v4.8.x and v4.9-rc?
>
>
>
>
> >
> >-Robert
> >
>
>
> _______________________________________________
> 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 v2 1/8] drm/bridge: rgb-to-vga: Support an enable GPIO
From: Maxime Ripard @ 2016-10-26 22:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026221346.tdpmbrwca4jehch2@rob-hp-laptop>
Hi Rob,
On Wed, Oct 26, 2016 at 05:13:46PM -0500, Rob Herring wrote:
> On Thu, Oct 20, 2016 at 11:43:37AM +0800, Chen-Yu Tsai wrote:
> > Some rgb-to-vga bridges have an enable GPIO, either directly tied to
> > an enable pin on the bridge IC, or indirectly controlling a power
> > switch.
> >
> > Add support for it.
> >
> > Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> > ---
> > .../bindings/display/bridge/dumb-vga-dac.txt | 2 ++
> > drivers/gpu/drm/bridge/dumb-vga-dac.c | 28 ++++++++++++++++++++++
> > 2 files changed, 30 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
> > index 003bc246a270..d3484822bf77 100644
> > --- a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
> > +++ b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
> > @@ -16,6 +16,8 @@ graph bindings specified in Documentation/devicetree/bindings/graph.txt.
> > - Video port 0 for RGB input
> > - Video port 1 for VGA output
> >
> > +Optional properties:
> > +- enable-gpios: GPIO pin to enable or disable the bridge
>
> This should also define the active state.
>
> > +static void dumb_vga_enable(struct drm_bridge *bridge)
> > +{
> > + struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
> > +
> > + if (vga->enable_gpio)
> > + gpiod_set_value_cansleep(vga->enable_gpio, 1);
>
> So the driver should allow either active high or low.
You mean like having a enable-active-high property? Isn't that
redundant with the GPIO flags?
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161027/b9eb1a24/attachment.sig>
^ permalink raw reply
* [PATCH v2 1/8] drm/bridge: rgb-to-vga: Support an enable GPIO
From: Rob Herring @ 2016-10-26 22:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020034344.14154-2-wens@csie.org>
On Thu, Oct 20, 2016 at 11:43:37AM +0800, Chen-Yu Tsai wrote:
> Some rgb-to-vga bridges have an enable GPIO, either directly tied to
> an enable pin on the bridge IC, or indirectly controlling a power
> switch.
>
> Add support for it.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> ---
> .../bindings/display/bridge/dumb-vga-dac.txt | 2 ++
> drivers/gpu/drm/bridge/dumb-vga-dac.c | 28 ++++++++++++++++++++++
> 2 files changed, 30 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
> index 003bc246a270..d3484822bf77 100644
> --- a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
> +++ b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
> @@ -16,6 +16,8 @@ graph bindings specified in Documentation/devicetree/bindings/graph.txt.
> - Video port 0 for RGB input
> - Video port 1 for VGA output
>
> +Optional properties:
> +- enable-gpios: GPIO pin to enable or disable the bridge
This should also define the active state.
> +static void dumb_vga_enable(struct drm_bridge *bridge)
> +{
> + struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
> +
> + if (vga->enable_gpio)
> + gpiod_set_value_cansleep(vga->enable_gpio, 1);
So the driver should allow either active high or low.
> +}
> +
> +static void dumb_vga_disable(struct drm_bridge *bridge)
> +{
> + struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
> +
> + if (vga->enable_gpio)
> + gpiod_set_value_cansleep(vga->enable_gpio, 0);
> +}
> +
^ permalink raw reply
* [PATCH 1/6] dt/bindings: adjust bindings for Layerscape SCFG MSI
From: Leo Li @ 2016-10-26 22:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026103101.GC19965@leverpostej>
> -----Original Message-----
> From: Mark Rutland [mailto:mark.rutland at arm.com]
> Sent: Wednesday, October 26, 2016 5:31 AM
> To: M.H. Lian <minghuan.lian@nxp.com>
> Cc: linux-arm-kernel at lists.infradead.org; linux-kernel at vger.kernel.org;
> devicetree at vger.kernel.org; Marc Zyngier <marc.zyngier@arm.com>; Stuart
> Yoder <stuart.yoder@nxp.com>; Leo Li <leoyang.li@nxp.com>; Scott Wood
> <scott.wood@nxp.com>; Shawn Guo <shawnguo@kernel.org>; Mingkai Hu
> <mingkai.hu@nxp.com>
> Subject: Re: [PATCH 1/6] dt/bindings: adjust bindings for Layerscape SCFG MSI
>
> On Tue, Oct 25, 2016 at 08:35:40PM +0800, Minghuan Lian wrote:
> > 1. The different version of a SoC may have different MSI
> > implementation. But compatible "fsl,<soc-name>-msi" can not describe
> > the SoC version.
>
> Surely, "fsl,<soc-name>-<rev>-msi" can describe this?
>
> If the hardware differs, it needs a new compatible string.
>
> If there's some configuration value that varies across revisions (e.g.
> number of slots), you can add a proeprty to describe that explciitly.
>
> > The MSI driver will use SoC match interface to get SoC type and
> > version instead of compatible string. So all MSI node can use the
> > common compatible "fsl,ls-scfg-msi" and the original compatible is
> > unnecessary.
> >
> > 2. Layerscape SoCs may have one or several MSI controllers.
> > In order to increase MSI interrupt number of a PCIe, the patch moves
> > all MSI node into the parent node "msi-controller". So a PCIe can
> > request MSI from all the MSI controllers.
>
> This is not necessary, and does not represent a real block of hardware.
> So NAK for this approach.
>
> The msi-parent property can contain a list of MSI controllers. See the examples
> in Documentation/devicetree/bindings/interrupt-controller/msi.txt.
> Likewise, the msi-map property can map to a number of MSI controllers.
>
> If the core code can only consider one at a time, then that's an issue to be
> addressed in core code, not one to be bodged around in bindings.
>
> >
> > Signed-off-by: Minghuan Lian <Minghuan.Lian@nxp.com>
> > ---
> > .../interrupt-controller/fsl,ls-scfg-msi.txt | 57 +++++++++++++++++++---
> > 1 file changed, 49 insertions(+), 8 deletions(-)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-scfg-m
> > si.txt
> > b/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-scfg-m
> > si.txt
> > index 9e38949..29f95fd 100644
> > ---
> > a/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-scfg-m
> > si.txt
> > +++ b/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-sc
> > +++ fg-msi.txt
> > @@ -1,18 +1,28 @@
> > * Freescale Layerscape SCFG PCIe MSI controller
> >
> > +Layerscape SoCs may have one or multiple MSI controllers.
> > +Each MSI controller must be showed as a child node.
> > +
> > Required properties:
> >
> > -- compatible: should be "fsl,<soc-name>-msi" to identify
> > - Layerscape PCIe MSI controller block such as:
> > - "fsl,1s1021a-msi"
> > - "fsl,1s1043a-msi"
> > +- compatible: should be "fsl,ls-scfg-msi"
>
> This breaks old DTBs, and throws away information which you describe above as
> valuable. So another NAK for that.
I agree with you that we should maintain the backward compatibility. But on the other hand, I just found that there is a silly typo in the original binding that "ls" is wrongly spelled as "1s" and they look too close to be noticed in previous patch reviews. :( The driver and all the DTSes used the binding with the typo which covered up the problem. So even if we want to keep the "fsl,<soc-name>-msi" binding, we probably want to fix the typo, right? And that breaks the backward compatibility too.
Regards,
Leo
^ permalink raw reply
* [PATCH v2 2/4] dt-bindings: Add TI SCI PM Domains
From: Rob Herring @ 2016-10-26 22:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161019203347.17893-3-d-gerlach@ti.com>
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.
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.
Rob
^ permalink raw reply
* [PATCH v2 2/4] dt-bindings: Add TI SCI PM Domains
From: Rob Herring @ 2016-10-26 21:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7h1sz51y3p.fsf@baylibre.com>
On Mon, Oct 24, 2016 at 12:00 PM, Kevin Hilman <khilman@baylibre.com> wrote:
> Dave Gerlach <d-gerlach@ti.com> writes:
>
>> Hi,
>> On 10/21/2016 01:48 PM, Kevin Hilman wrote:
>>> Dave Gerlach <d-gerlach@ti.com> writes:
>>>
>>>> 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 {
>>>
>>> should use generic name like "power-contoller", e.g. k2g_pds: power-controller
>>
>> Ok, that makes more sense.
>>
>>>
>>>> + compatible = "ti,sci-pm-domain";
>>>> + #power-domain-cells = <0>;
>>>> + ti,sci = <&pmmc>;
>>>> +};
>>>> +
>>>> +PM Domain Consumers
>>>> +===================
>>>> +Hardware blocks that require SCI control over their state must provide
>>>> +a reference to the sci-pm-domain they are part of and a unique device
>>>> +specific ID that identifies the device.
>>>> +
>>>> +Required Properties:
>>>> +--------------------
>>>> +- power-domains: phandle pointing to the corresponding PM domain node.
>>>> +- ti,sci-id: index representing the device id to be passed oevr SCI to
>>>> + be used for device control.
>>>
>>> This ID doesn't look right.
>>>
>>> Why not use #power-domain-cells = <1> and pass the index in the DT? ...
Exactly. ti,sci-id is a NAK for me.
>>>
>>>> +See dt-bindings/genpd/k2g.h for the list of valid identifiers for k2g.
>>>> +
>>>> +Example:
>>>> +--------------------
>>>> +uart0: serial at 02530c00 {
>>>> + compatible = "ns16550a";
>>>> + ...
>>>> + power-domains = <&k2g_pds>;
>>>> + ti,sci-id = <K2G_DEV_UART0>;
>>>
>>> ... like this:
>>>
>>> power-domains = <&k2g_pds K2G_DEV_UART0>;
>>
>> That's how I did it in version one actually. I was able to define my
>> own xlate function to parse the phandle and get that index, but Ulf
>> pointed me to this series by Jon Hunter [1] that simplified genpd
>> providers and dropped the concept of adding your own xlate. This locks
>> the onecell approach to using a fixed static array of genpds that get
>> indexed into (without passing the index to the provider, just the
>> genpd that's looked up), which doesn't fit our usecase, as we don't
>> want a 1 to 1 genpd to device mapping based on the comments provided
>> in v1. Now we just use the genpd device attach/detach hooks to parse
>> the sci-id and then use it in the genpd device start/stop hooks.
I have no idea what any of this means. All sounds like driver
architecture, not anything to do with bindings.
>
> Ah, right. I remember now. This approach allows you to use a single
> genpd as discussed earlier.
>
> Makes sense now, suggestion retracted.
IIRC, the bindings in Jon's case had a node for each domain and didn't
need any additional property.
Rob
^ permalink raw reply
* [PATCH V6 01/10] Documentation: DT: qcom_hidma: update binding for MSI
From: Sinan Kaya @ 2016-10-26 21:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026214512.ofwbxnl2d46n6ef5@rob-hp-laptop>
On 10/26/2016 5:45 PM, Rob Herring wrote:
> On Wed, Oct 19, 2016 at 01:51:43PM -0400, Sinan Kaya wrote:
>> Adding a new binding for qcom,hidma-1.1 to distinguish HW supporting
>> MSI interrupts from the older revision.
>>
>> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
>> ---
>> Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt | 8 +++++++-
>> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> Please add acks when posting new versions.
>
Sure, sorry about that. Your acked version already got merged to Vinod's branch.
During the merge, Vinod got some merge conflicts for the remainder of the patches.
I was trying to post the remaining patches for Vinod to pick it up.
Apologies if it was not clear.
I posted V7 with only four remaining patches without the already merged
DT changes.
> Rob
> --
> To unsubscribe from this list: send the line "unsubscribe dmaengine" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH 4/5] net: ethernet: bgmac: add NS2 support
From: Florian Fainelli @ 2016-10-26 21:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477510561-17035-5-git-send-email-jon.mason@broadcom.com>
On 10/26/2016 12:36 PM, Jon Mason wrote:
> Add support for the variant of amac hardware present in the Broadcom
> Northstar2 based SoCs. Northstar2 requires an additional register to be
> configured with the port speed/duplexity (NICPM). This can be added to
> the link callback to hide it from the instances that do not use this.
> Also, the bgmac_chip_reset() was intentionally removed to prevent the
> resetting of the chip to the default values on open. Finally, clearing
> of the pending interrupts on init is required due to observed issues on
> some platforms.
>
> Signed-off-by: Jon Mason <jon.mason@broadcom.com>
> ---
> +static void bgmac_nicpm_speed_set(struct net_device *net_dev)
> +{
> + struct bgmac *bgmac = netdev_priv(net_dev);
> + u32 val;
> +
> + if (!bgmac->plat.nicpm_base)
> + return;
> +
> + val = NICPM_IOMUX_CTRL_INIT_VAL;
> + switch (bgmac->net_dev->phydev->speed) {
> + default:
> + pr_err("Unsupported speed. Defaulting to 1000Mb\n");
> + case SPEED_1000:
> + val |= NICPM_IOMUX_CTRL_SPD_1000M << NICPM_IOMUX_CTRL_SPD_SHIFT;
> + break;
> + case SPEED_100:
> + val |= NICPM_IOMUX_CTRL_SPD_100M << NICPM_IOMUX_CTRL_SPD_SHIFT;
> + break;
> + case SPEED_10:
> + val |= NICPM_IOMUX_CTRL_SPD_10M << NICPM_IOMUX_CTRL_SPD_SHIFT;
> + break;
> + }
> +
> + writel(val, bgmac->plat.nicpm_base + NICPM_IOMUX_CTRL);
> +
> + usleep_range(10, 100);
Does not seem like a good idea, do you need that sleep?
> +
> + bgmac_adjust_link(bgmac->net_dev);
> +}
> +
> static int platform_phy_connect(struct bgmac *bgmac)
> {
> struct phy_device *phy_dev;
>
> - phy_dev = of_phy_get_and_connect(bgmac->net_dev, bgmac->dev->of_node,
> - bgmac_adjust_link);
> + if (bgmac->plat.nicpm_base)
> + phy_dev = of_phy_get_and_connect(bgmac->net_dev,
> + bgmac->dev->of_node,
> + bgmac_nicpm_speed_set);
> + else
> + phy_dev = of_phy_get_and_connect(bgmac->net_dev,
> + bgmac->dev->of_node,
> + bgmac_adjust_link);
> if (!phy_dev) {
> dev_err(bgmac->dev, "Phy connect failed\n");
> return -ENODEV;
> }
>
> + if (bgmac->feature_flags & BGMAC_FEAT_LANE_SWAP)
> + phy_dev->dev_flags |= PHY_BRCM_EXP_LANE_SWAP;
> +
> return 0;
> }
>
> @@ -140,6 +188,9 @@ static int bgmac_probe(struct platform_device *pdev)
>
> platform_set_drvdata(pdev, bgmac);
>
> + if (of_property_read_bool(np, "brcm,enet-phy-lane-swap"))
> + bgmac->feature_flags |= BGMAC_FEAT_LANE_SWAP;
> +
> /* Set the features of the 4707 family */
> bgmac->feature_flags |= BGMAC_FEAT_CLKCTLST;
> bgmac->feature_flags |= BGMAC_FEAT_NO_RESET;
> @@ -182,6 +233,14 @@ static int bgmac_probe(struct platform_device *pdev)
> if (IS_ERR(bgmac->plat.idm_base))
> return PTR_ERR(bgmac->plat.idm_base);
>
> + regs = platform_get_resource_byname(pdev, IORESOURCE_MEM, "nicpm_base");
> + if (regs) {
> + bgmac->plat.nicpm_base = devm_ioremap_resource(&pdev->dev,
> + regs);
> + if (IS_ERR(bgmac->plat.nicpm_base))
> + return PTR_ERR(bgmac->plat.nicpm_base);
> + }
> +
> bgmac->read = platform_bgmac_read;
> bgmac->write = platform_bgmac_write;
> bgmac->idm_read = platform_bgmac_idm_read;
> @@ -213,6 +272,7 @@ static int bgmac_remove(struct platform_device *pdev)
> static const struct of_device_id bgmac_of_enet_match[] = {
> {.compatible = "brcm,amac",},
> {.compatible = "brcm,nsp-amac",},
> + {.compatible = "brcm,ns2-amac",},
> {},
> };
>
> diff --git a/drivers/net/ethernet/broadcom/bgmac.c b/drivers/net/ethernet/broadcom/bgmac.c
> index 38876ec..1796208 100644
> --- a/drivers/net/ethernet/broadcom/bgmac.c
> +++ b/drivers/net/ethernet/broadcom/bgmac.c
> @@ -1082,6 +1082,9 @@ static void bgmac_enable(struct bgmac *bgmac)
> /* http://bcm-v4.sipsolutions.net/mac-gbit/gmac/chipinit */
> static void bgmac_chip_init(struct bgmac *bgmac)
> {
> + /* Clear any erroneously pending interrupts */
> + bgmac_write(bgmac, BGMAC_INT_STATUS, ~0);
> +
> /* 1 interrupt per received frame */
> bgmac_write(bgmac, BGMAC_INT_RECV_LAZY, 1 << BGMAC_IRL_FC_SHIFT);
>
> @@ -1158,8 +1161,6 @@ static int bgmac_open(struct net_device *net_dev)
> struct bgmac *bgmac = netdev_priv(net_dev);
> int err = 0;
>
> - bgmac_chip_reset(bgmac);
> -
Is this removal intentional? Maybe it should be special cased with
checking for a NS2 BGMAC instance and not do it in that case?
--
Florian
^ permalink raw reply
* [PATCH v6 2/2] Documentation: DT: MMC: meson-gx: new bindings doc
From: Rob Herring @ 2016-10-26 21:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161019181825.2186-2-khilman@baylibre.com>
On Wed, Oct 19, 2016 at 11:18:25AM -0700, Kevin Hilman wrote:
> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
> ---
> .../devicetree/bindings/mmc/amlogic,meson-gx.txt | 33 ++++++++++++++++++++++
> 1 file changed, 33 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mmc/amlogic,meson-gx.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH V6 01/10] Documentation: DT: qcom_hidma: update binding for MSI
From: Rob Herring @ 2016-10-26 21:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476899512-20431-2-git-send-email-okaya@codeaurora.org>
On Wed, Oct 19, 2016 at 01:51:43PM -0400, Sinan Kaya wrote:
> Adding a new binding for qcom,hidma-1.1 to distinguish HW supporting
> MSI interrupts from the older revision.
>
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> ---
> Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
Please add acks when posting new versions.
Rob
^ permalink raw reply
* [PATCH v2 2/9] dt-bindings: interrupt-controller: add DT binding for meson GPIO interrupt controller
From: Rob Herring @ 2016-10-26 21:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476890480-8884-3-git-send-email-jbrunet@baylibre.com>
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.
^ permalink raw reply
* [PATCH 0/5] Minimal cpuidle fixes for omap5 and dra7
From: Tony Lindgren @ 2016-10-26 21:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c1b6bf69-ed11-3355-323f-9d6503180310@ti.com>
* Nishanth Menon <nm@ti.com> [161026 13:57]:
> Tony,
> On 10/26/2016 10:16 AM, Tony Lindgren wrote:
> > Hi all,
> >
> > Here are some fixes to get minimal cpuidle support working with omap5
> > and dra7. Not sure if there are still some unsorted issues on enabling
> > this on dra7, but at least omap5 has been behving for me for few
> > weeks with these.
>
> I am OK with cpuidle for OMAP5, but NOT dra7. we have enabled this series of
> patches close to a couple of years back and hit quiet a few issues that do
> not have silicon resolution. CPU states lower than WFI will not work in
> cpuidle for DRA7 and has already been "descoped" from TI investigation
> charter. details of the issue remain TI internal, given that the descope was
> already done.
Hmm OK, no point adding it if not supported by hardware. I'll modify the
series for omap5 only.
> Again, OMAP5 has only had limited exposure from verification point of view -
> and all of it TI internal (unlike OMAP4 which has had production devices go
> ahead) -> at the very least, I'd link it with experimental.
Sure, this is a subset already to let's see how that works before adding
any other modes.
Regards,
Tony
^ permalink raw reply
* MAINTAINERS entry for ARM/CLKDEV SUPPORT
From: Stephen Boyd @ 2016-10-26 21:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026191938.GT4418@mwanda>
On 10/26/2016 12:19 PM, Dan Carpenter wrote:
> On Mon, Oct 10, 2016 at 03:18:19PM +0100, Russell King - ARM Linux wrote:
>> On Mon, Oct 10, 2016 at 05:08:10PM +0300, Dan Carpenter wrote:
>>> Hello Stephen Boyd,
>> Okay, that's really not nice.
>>
>> This is _not_ a question for Stephen. Stephen does _not_ co-maintain
>> clkdev or the clk API, but co-maintains CCF. I've no idea why you are
>> addressing this to Stephen when this is clearly a question for me to
>> answer.
>>
> Sorry, I didn't mean to offend. He's the one who deleted the clkdev.h
> file though so I thought he might know if it should still be listed or
> if it was gone for good.
>
Yes, the arm version isn't coming back. We should delete
arch/arm/include/asm/clkdev.h from the maintainers file and perhaps
replace it with the asm-generic one. But we can delete the generic file
too once blackfin removes their clkdev.h header. That patch is still
outstanding.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [rjarzmik:work/ac97 9/13] sound/arm/pxa2xx-ac97.c:34:34: error: passing argument 1 of 'pxa2xx_ac97_try_cold_reset' from incompatible pointer type
From: kbuild test robot @ 2016-10-26 21:06 UTC (permalink / raw)
To: linux-arm-kernel
tree: https://github.com/rjarzmik/linux work/ac97
head: 223e9c527c425b1b519468e54fff9f4f82a7f390
commit: 99ed942665174ff3212a5e2353a1dc2e6df76ff9 [9/13] ASoC: pxa: switch to new ac97 bus support
config: arm-viper_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 99ed942665174ff3212a5e2353a1dc2e6df76ff9
# save the attached .config to linux build tree
make.cross ARCH=arm
All errors (new ones prefixed by >>):
sound/arm/pxa2xx-ac97.c: In function 'pxa2xx_ac97_reset':
>> sound/arm/pxa2xx-ac97.c:34:34: error: passing argument 1 of 'pxa2xx_ac97_try_cold_reset' from incompatible pointer type [-Werror=incompatible-pointer-types]
if (!pxa2xx_ac97_try_cold_reset(ac97)) {
^~~~
In file included from sound/arm/pxa2xx-ac97.c:24:0:
include/sound/pxa2xx-lib.h:31:13: note: expected 'struct ac97_controller *' but argument is of type 'struct snd_ac97 *'
extern bool pxa2xx_ac97_try_cold_reset(struct ac97_controller *adrv);
^~~~~~~~~~~~~~~~~~~~~~~~~~
>> sound/arm/pxa2xx-ac97.c:35:30: error: passing argument 1 of 'pxa2xx_ac97_try_warm_reset' from incompatible pointer type [-Werror=incompatible-pointer-types]
pxa2xx_ac97_try_warm_reset(ac97);
^~~~
In file included from sound/arm/pxa2xx-ac97.c:24:0:
include/sound/pxa2xx-lib.h:30:13: note: expected 'struct ac97_controller *' but argument is of type 'struct snd_ac97 *'
extern bool pxa2xx_ac97_try_warm_reset(struct ac97_controller *adrv);
^~~~~~~~~~~~~~~~~~~~~~~~~~
>> sound/arm/pxa2xx-ac97.c:38:27: error: passing argument 1 of 'pxa2xx_ac97_finish_reset' from incompatible pointer type [-Werror=incompatible-pointer-types]
pxa2xx_ac97_finish_reset(ac97);
^~~~
In file included from sound/arm/pxa2xx-ac97.c:24:0:
include/sound/pxa2xx-lib.h:32:13: note: expected 'struct ac97_controller *' but argument is of type 'struct snd_ac97 *'
extern void pxa2xx_ac97_finish_reset(struct ac97_controller *adrv);
^~~~~~~~~~~~~~~~~~~~~~~~
sound/arm/pxa2xx-ac97.c: At top level:
>> sound/arm/pxa2xx-ac97.c:42:10: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
.read = pxa2xx_ac97_read,
^~~~~~~~~~~~~~~~
sound/arm/pxa2xx-ac97.c:42:10: note: (near initialization for 'pxa2xx_ac97_ops.read')
sound/arm/pxa2xx-ac97.c:43:11: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
.write = pxa2xx_ac97_write,
^~~~~~~~~~~~~~~~~
sound/arm/pxa2xx-ac97.c:43:11: note: (near initialization for 'pxa2xx_ac97_ops.write')
cc1: some warnings being treated as errors
vim +/pxa2xx_ac97_try_cold_reset +34 sound/arm/pxa2xx-ac97.c
a09e64fb Russell King 2008-08-05 28 #include <mach/audio.h>
2c484df0 Takashi Iwai 2005-06-30 29
2c484df0 Takashi Iwai 2005-06-30 30 #include "pxa2xx-pcm.h"
2c484df0 Takashi Iwai 2005-06-30 31
d18f8376 Takashi Iwai 2005-11-17 32 static void pxa2xx_ac97_reset(struct snd_ac97 *ac97)
2c484df0 Takashi Iwai 2005-06-30 33 {
9c636342 Dmitry Eremin-Solenikov 2008-09-10 @34 if (!pxa2xx_ac97_try_cold_reset(ac97)) {
9c636342 Dmitry Eremin-Solenikov 2008-09-10 @35 pxa2xx_ac97_try_warm_reset(ac97);
2c484df0 Takashi Iwai 2005-06-30 36 }
2c484df0 Takashi Iwai 2005-06-30 37
9c636342 Dmitry Eremin-Solenikov 2008-09-10 @38 pxa2xx_ac97_finish_reset(ac97);
2c484df0 Takashi Iwai 2005-06-30 39 }
2c484df0 Takashi Iwai 2005-06-30 40
d18f8376 Takashi Iwai 2005-11-17 41 static struct snd_ac97_bus_ops pxa2xx_ac97_ops = {
2c484df0 Takashi Iwai 2005-06-30 @42 .read = pxa2xx_ac97_read,
2c484df0 Takashi Iwai 2005-06-30 43 .write = pxa2xx_ac97_write,
2c484df0 Takashi Iwai 2005-06-30 44 .reset = pxa2xx_ac97_reset,
2c484df0 Takashi Iwai 2005-06-30 45 };
:::::: The code at line 34 was first introduced by commit
:::::: 9c63634221f67450ead19820e33996b69691194f ALSA: Separate common pxa2xx-ac97 code
:::::: TO: Dmitry Baryshkov <dbaryshkov@gmail.com>
:::::: CC: Jaroslav Kysela <perex@perex.cz>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 18279 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161027/286943ab/attachment-0001.gz>
^ permalink raw reply
* [PATCH v1 1/4] dt-bindings: Document Broadcom iProc mailbox controller driver
From: Rob Herring @ 2016-10-26 21:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476817238-1226-2-git-send-email-jonathan.richardson@broadcom.com>
On Tue, Oct 18, 2016 at 12:00:35PM -0700, Jonathan Richardson wrote:
> Reviewed-by: Jonathan Richardson <jonathan.richardson@broadcom.com>
> Tested-by: Jonathan Richardson <jonathan.richardson@broadcom.com>
> Reviewed-by: Vikram Prakash <vikram.prakash@broadcom.com>
> Reviewed-by: Ray Jui <ray.jui@broadcom.com>
> Reviewed-by: Shreesha Rajashekar <shreesha.rajashekar@broadcom.com>
> Reviewed-by: Scott Branden <scott.branden@broadcom.com>
> Signed-off-by: Jonathan Richardson <jonathan.richardson@broadcom.com>
> ---
> .../bindings/mailbox/brcm,iproc-mailbox.txt | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mailbox/brcm,iproc-mailbox.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 0/5] Minimal cpuidle fixes for omap5 and dra7
From: Nishanth Menon @ 2016-10-26 20:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026151703.24730-1-tony@atomide.com>
Tony,
On 10/26/2016 10:16 AM, Tony Lindgren wrote:
> Hi all,
>
> Here are some fixes to get minimal cpuidle support working with omap5
> and dra7. Not sure if there are still some unsorted issues on enabling
> this on dra7, but at least omap5 has been behving for me for few
> weeks with these.
I am OK with cpuidle for OMAP5, but NOT dra7. we have enabled this
series of patches close to a couple of years back and hit quiet a few
issues that do not have silicon resolution. CPU states lower than WFI
will not work in cpuidle for DRA7 and has already been "descoped" from
TI investigation charter. details of the issue remain TI internal,
given that the descope was already done.
Again, OMAP5 has only had limited exposure from verification point of
view - and all of it TI internal (unlike OMAP4 which has had
production devices go ahead) -> at the very least, I'd link it with
experimental.
--
Regards,
Nishanth Menon
^ permalink raw reply
* Add Allwinner Q8 tablets hardware manager
From: Rob Herring @ 2016-10-26 20:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161024173900.GP15620@leverpostej>
On Mon, Oct 24, 2016 at 06:39:01PM +0100, Mark Rutland wrote:
> On Fri, Oct 14, 2016 at 09:53:31AM +0200, Hans de Goede wrote:
> > Hi Rob, Mark, et al.,
>
> Hi Hans,
>
> Apologies for the delay in replying to this.
>
> I'd like to be clear that I do understand that there is a problem that
> needs to be addressed here. However, I do not believe that the *current*
> in-kernel approach is correct. More on that below.
>
> > Mark, I know that we discussed this at ELCE and you clearly indicated
> > that according to you this does not belong in the kernel. I was a bit
> > surprised by this part of the discussion.
> >
> > I had posted a RFC earlier and Rob had indicated that given that the q8
> > tablets are a special case, as my code uses actual probing rather then some
> > pre-arranged id mechanism with say an eeprom, that doing this in a
> > non-generic manner would be ok for my special case.
>
> To some extent, Rob and I may have differing views here; I'm not
> entirely sure what Rob's view is, and I cannot talk on his behalf. I
> certainly must apologise for having not commented on said RFC, however.
I've focused mainly on the bindings which I certainly had issues with
how the RFC was done. As to where this should be done, keeping all the
dirty bits in firmware/bootloader is certainly appealing. However, there
are cases where data alone can't abstract out board differences and we
need board code. Whether this is one of them, well, that is Hans' job to
convince Mark.
Rob
^ permalink raw reply
* [PATCH 1/6] dt: bindings: Add Allwinner Q8 tablets hardware manager bindings
From: Rob Herring @ 2016-10-26 20:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161014075337.10452-2-hdegoede@redhat.com>
On Fri, Oct 14, 2016 at 09:53:32AM +0200, Hans de Goede wrote:
> Allwinnner A13 / A23 / A33 based Q8 tablets are popular cheap 7" tablets
> of which a new batch is produced every few weeks. Each batch uses a
> different mix of touchscreen, accelerometer and wifi peripherals.
>
> Given that each batch is different creating a devicetree for each variant
> is not desirable, work is being done on a Q8 tablet hardware manager which
> auto-detects the touchscreen and accelerometer and will update the dt with
> what it has found, so that a single generic dt can be used for these tablets.
>
> This commit adds dt-bindings for this hardware manager.
>
> Note the wifi is connected to a discoverable bus (sdio or usb) and will be
> autodetected by the mmc resp. usb subsystems.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> .../misc/allwinner,sunxi-q8-hardwaremgr.txt | 71 ++++++++++++++++++++++
> 1 file changed, 71 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/misc/allwinner,sunxi-q8-hardwaremgr.txt
>
> diff --git a/Documentation/devicetree/bindings/misc/allwinner,sunxi-q8-hardwaremgr.txt b/Documentation/devicetree/bindings/misc/allwinner,sunxi-q8-hardwaremgr.txt
> new file mode 100644
> index 0000000..a81b258
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/misc/allwinner,sunxi-q8-hardwaremgr.txt
> @@ -0,0 +1,71 @@
> +Q8 tablet hardware manager
> +--------------------------
> +
> +Allwinnner A13 / A23 / A33 based Q8 tablets are popular cheap 7" tablets of
> +which a new batch is produced every few weeks. Each batch uses a different
> +mix of touchscreen, accelerometer and wifi peripherals.
> +
> +Given that each batch is different creating a devicetree for each variant is
> +not desirable. The Q8 tablet hardware manager bindings are bindings for an os
> +module which auto-detects the touchscreen and accelerometer so that a single
> +generic dts can be used for these tablets.
> +
> +The wifi is connected to a discoverable bus and will be autodetected by the os.
> +
> +Required properties:
> + - toplevel / machine compatible, one of:
> + "allwinner,q8-a13"
> + "allwinner,q8-a23"
> + "allwinner,q8-a33"
> + - touchscreen node : There must be a template touchscreen node named
> + "touchscreen", this must be a child node of the
> + touchscreen i2c bus
> + - accelerometer node : There must be a template accelerometer node named
> + "accelerometer", this must be a child node of the
> + accelerometer i2c bus
> +
> +touchscreen node required properties:
> + - interrupt-parent : phandle pointing to the interrupt controller
> + serving the touchscreen interrupt
> + - interrupts : interrupt specification for the touchscreen interrupt
> + - power-gpios : Specification for the pin connected to the touchscreen's
> + enable / wake pin. This needs to be driven high to
> + enable the touchscreen controller
enable-gpios is the common name.
I was going to say you need to list possible compatible strings here
also. However, I now wonder if this binding doc is even needed. The
binding docs should just be the bindings for each touchscreen or
accelerometer. The fact that the node is completed at run-time whether
the bootloader or kernel doesn't matter for the binding definition. When
and it is completed is orthogonal to the binding definition.
Rob
^ permalink raw reply
* [PATCH 2/5] ARM: OMAP5: Fix mpuss_early_init
From: Tony Lindgren @ 2016-10-26 20:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026151703.24730-3-tony@atomide.com>
* Tony Lindgren <tony@atomide.com> [161026 08:18]:
> We need to properly initialize mpuss also on omap5 like we do on omap4.
> Otherwise we run into similar kexec problems like we had on omap4 when
> trying to kexec from a kernel with PM initialized.
...
> + else if (cpu_is_omap446x())
> startup_pa = virt_to_phys(omap4460_secondary_startup);
> + else
> + startup_pa = virt_to_phys(omap5_secondary_startup);
Here we need to check for omap5_secondary_hyp_startup too. And with
omap4 and omap5 being optional, we need to fix up things for make
randconfig builds as reported by the kbuild test robot.
Updated patch below.
Regards,
Tony
8< -----------------------
>From tony Mon Sep 17 00:00:00 2001
From: Tony Lindgren <tony@atomide.com>
Date: Tue, 25 Oct 2016 08:33:32 -0700
Subject: [PATCH] ARM: OMAP5: Fix mpuss_early_init
We need to properly initialize mpuss also on omap5 like we do on omap4.
Otherwise we run into similar kexec problems like we had on omap4 when
trying to kexec from a kernel with PM initialized.
Fixes: 0573b957fc21 ("ARM: OMAP4+: Prevent CPU1 related hang with kexec")
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/mach-omap2/common.h | 38 +++++++++++++++++++++++--------
arch/arm/mach-omap2/io.c | 3 ++-
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 32 ++++++++++++++++++++------
arch/arm/mach-omap2/omap4-sar-layout.h | 2 ++
4 files changed, 58 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -262,8 +262,6 @@ extern void __iomem *omap4_get_sar_ram_base(void);
extern void omap4_mpuss_early_init(void);
extern void omap_do_wfi(void);
-extern void omap4_secondary_startup(void);
-extern void omap4460_secondary_startup(void);
#ifdef CONFIG_SMP
/* Needed for secondary core boot */
@@ -275,16 +273,11 @@ extern void omap4_cpu_die(unsigned int cpu);
extern int omap4_cpu_kill(unsigned int cpu);
extern const struct smp_operations omap4_smp_ops;
-
-extern void omap5_secondary_startup(void);
-extern void omap5_secondary_hyp_startup(void);
#endif
#if defined(CONFIG_SMP) && defined(CONFIG_PM)
extern int omap4_mpuss_init(void);
extern int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state);
-extern int omap4_finish_suspend(unsigned long cpu_state);
-extern void omap4_cpu_resume(void);
extern int omap4_hotplug_cpu(unsigned int cpu, unsigned int power_state);
#else
static inline int omap4_enter_lowpower(unsigned int cpu,
@@ -305,14 +298,41 @@ static inline int omap4_mpuss_init(void)
return 0;
}
+#endif
+
+#ifdef CONFIG_ARCH_OMAP4
+void omap4_secondary_startup(void);
+void omap4460_secondary_startup(void);
+int omap4_finish_suspend(unsigned long cpu_state);
+void omap4_cpu_resume(void);
+#else
+static inline void omap4_secondary_startup(void)
+{
+}
+
+static inline void omap4460_secondary_startup(void)
+{
+}
static inline int omap4_finish_suspend(unsigned long cpu_state)
{
return 0;
}
-
static inline void omap4_cpu_resume(void)
-{}
+{
+}
+#endif
+#if defined(CONFIG_SOC_OMAP5) || defined(CONFIG_SOC_DRA7XX)
+void omap5_secondary_startup(void);
+void omap5_secondary_hyp_startup(void);
+#else
+static inline void omap5_secondary_startup(void)
+{
+}
+
+static inline void omap5_secondary_hyp_startup(void)
+{
+}
#endif
void pdata_quirks_init(const struct of_device_id *);
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -717,10 +717,11 @@ void __init omap5_init_early(void)
OMAP2_L4_IO_ADDRESS(OMAP54XX_SCM_BASE));
omap2_set_globals_prcm_mpu(OMAP2_L4_IO_ADDRESS(OMAP54XX_PRCM_MPU_BASE));
omap2_control_base_init();
- omap4_pm_init_early();
omap2_prcm_base_init();
omap5xxx_check_revision();
omap4_sar_ram_init();
+ omap4_mpuss_early_init();
+ omap4_pm_init_early();
omap54xx_voltagedomains_init();
omap54xx_powerdomains_init();
omap54xx_clockdomains_init();
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -48,6 +48,7 @@
#include <asm/smp_scu.h>
#include <asm/pgalloc.h>
#include <asm/suspend.h>
+#include <asm/virt.h>
#include <asm/hardware/cache-l2x0.h>
#include "soc.h"
@@ -371,8 +372,12 @@ int __init omap4_mpuss_init(void)
pm_info = &per_cpu(omap4_pm_info, 0x0);
if (sar_base) {
pm_info->scu_sar_addr = sar_base + SCU_OFFSET0;
- pm_info->wkup_sar_addr = sar_base +
- CPU0_WAKEUP_NS_PA_ADDR_OFFSET;
+ if (cpu_is_omap44xx())
+ pm_info->wkup_sar_addr = sar_base +
+ CPU0_WAKEUP_NS_PA_ADDR_OFFSET;
+ else
+ pm_info->wkup_sar_addr = sar_base +
+ OMAP5_CPU0_WAKEUP_NS_PA_ADDR_OFFSET;
pm_info->l2x0_sar_addr = sar_base + L2X0_SAVE_OFFSET0;
}
pm_info->pwrdm = pwrdm_lookup("cpu0_pwrdm");
@@ -391,8 +396,12 @@ int __init omap4_mpuss_init(void)
pm_info = &per_cpu(omap4_pm_info, 0x1);
if (sar_base) {
pm_info->scu_sar_addr = sar_base + SCU_OFFSET1;
- pm_info->wkup_sar_addr = sar_base +
- CPU1_WAKEUP_NS_PA_ADDR_OFFSET;
+ if (cpu_is_omap44xx())
+ pm_info->wkup_sar_addr = sar_base +
+ CPU1_WAKEUP_NS_PA_ADDR_OFFSET;
+ else
+ pm_info->wkup_sar_addr = sar_base +
+ OMAP5_CPU1_WAKEUP_NS_PA_ADDR_OFFSET;
pm_info->l2x0_sar_addr = sar_base + L2X0_SAVE_OFFSET1;
}
@@ -453,15 +462,24 @@ void __init omap4_mpuss_early_init(void)
{
unsigned long startup_pa;
- if (!cpu_is_omap44xx())
+ if (!(cpu_is_omap44xx() || soc_is_omap54xx()))
return;
sar_base = omap4_get_sar_ram_base();
if (cpu_is_omap443x())
startup_pa = virt_to_phys(omap4_secondary_startup);
- else
+ else if (cpu_is_omap446x())
startup_pa = virt_to_phys(omap4460_secondary_startup);
+ else if ((__boot_cpu_mode & MODE_MASK) == HYP_MODE)
+ startup_pa = virt_to_phys(omap5_secondary_hyp_startup);
+ else
+ startup_pa = virt_to_phys(omap5_secondary_startup);
- writel_relaxed(startup_pa, sar_base + CPU1_WAKEUP_NS_PA_ADDR_OFFSET);
+ if (cpu_is_omap44xx())
+ writel_relaxed(startup_pa, sar_base +
+ CPU1_WAKEUP_NS_PA_ADDR_OFFSET);
+ else
+ writel_relaxed(startup_pa, sar_base +
+ OMAP5_CPU1_WAKEUP_NS_PA_ADDR_OFFSET);
}
diff --git a/arch/arm/mach-omap2/omap4-sar-layout.h b/arch/arm/mach-omap2/omap4-sar-layout.h
--- a/arch/arm/mach-omap2/omap4-sar-layout.h
+++ b/arch/arm/mach-omap2/omap4-sar-layout.h
@@ -31,6 +31,8 @@
/* CPUx Wakeup Non-Secure Physical Address offsets in SAR_BANK3 */
#define CPU0_WAKEUP_NS_PA_ADDR_OFFSET 0xa04
#define CPU1_WAKEUP_NS_PA_ADDR_OFFSET 0xa08
+#define OMAP5_CPU0_WAKEUP_NS_PA_ADDR_OFFSET 0xe00
+#define OMAP5_CPU1_WAKEUP_NS_PA_ADDR_OFFSET 0xe04
#define SAR_BACKUP_STATUS_OFFSET (SAR_BANK3_OFFSET + 0x500)
#define SAR_SECURE_RAM_SIZE_OFFSET (SAR_BANK3_OFFSET + 0x504)
--
2.9.3
^ permalink raw reply
* [PATCH 2/3] ARM: convert to generated system call tables
From: Robert Jarzmik @ 2016-10-26 20:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdVy_h6Uss9bwVK5hGD42bXeEBcBsBDwCpx_eYnT9r+=Lw@mail.gmail.com>
Geert Uytterhoeven <geert@linux-m68k.org> writes:
> On Sat, Oct 22, 2016 at 10:23 PM, Robert Jarzmik <robert.jarzmik@free.fr> wrote:
>> Arnd Bergmann <arnd@arndb.de> writes:
>>
>>> On Friday, October 21, 2016 4:48:56 PM CEST Russell King - ARM Linux wrote:
>>>> What's the point of the x32 mode?
>>>
>>> On x86, the motivation is faster code for most use cases that
>>> don't need a lot of memory, as the 64-bit opcodes have 16 registers
>>> rather than 8 in 32-bit mode but 32-bit pointers have lower
>>> cache footprint than 64-bit pointers.
>>
>> For completness, the second point of x32 AFAIU is the IP-relative addressing
>> which is not available in standard 32 bit mode, which improves PIC code. For
>> simple not algorithmic code (think Android HAL for example) with many shared
>> libraries, it's better in the Hardware Abstraction Layer Libraries, instead of
>> the push-to-stack and pop register.
>
> But that's not an advantage compared to full am64 mode, right?
Nope, the amd64 (that's what you have in mind with am64, not aarch64 right ?)
mode has the IP-relative has well, so x32 has no advantage over amd64 in this
area.
x32 over amd64 advantage is cache and memory footprint AFAICT, I don't see other
benefits. There doesn't seem to be any ISA differences, or I didn't really
notice in my daily system performance analysis job.
There was a nice presentation made by Peter Anvin at a Plumber conference, here
: http://linuxplumbersconf.org/2011/ocw/sessions/531
Cheers.
--
Robert
^ permalink raw reply
* [PATCH] ARM: davinci: register the usb20_phy clock on the DT file
From: David Lechner @ 2016-10-26 20:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKXjFTNyNEykVn3+mxiaQionxuzrp812nfdD=9uNgrbddv939Q@mail.gmail.com>
On 10/26/2016 03:05 PM, Axel Haslam wrote:
> On Wed, Oct 26, 2016 at 10:03 PM, David Lechner <david@lechnology.com> wrote:
>> On 10/26/2016 03:01 PM, David Lechner wrote:
>>>
>>> On 10/26/2016 02:49 PM, ahaslam at baylibre.com wrote:
>>>>
>>>> From: Axel Haslam <ahaslam@baylibre.com>
>>>>
>>>> The usb20_phy clock needs to be registered for the driver to be able
>>>> to get and enable a clock. Currently the usb phy clocks are registered
>>>> form board files, which will not be called during a device tree based
>>>> boot.
>>>>
>>>> To be able to probe correctly usb form a device tree boot, register
>>>> the usb phy clocks form the DT specific init.
>>>>
>>>> Unfourtunatly, davinci does not have proper clock support on device tree
>>>> yet, so by registering the clock form de DT specific file we are
>>>> forced to hardcode the parent clock, and cannot select refclkin as
>>>> parent for any of the phy clocks of the da850 family.
>>>>
>>>> As none of the current da850 based boards currently in mainline use
>>>> refclkin as source. I guess we can live with this limitation until clocks
>>>> are correctly represented through CCF/device tree.
>>>>
>>>> Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
>>>> ---
>>>>
>>>> This patch depends on David's series for usb clocks:
>>>>
>>>> currently:
>>>> [PATCH v6 0/5] da8xx USB PHY platform devices and clocks
>>>> https://lkml.org/lkml/2016/10/25/867
>>>>
>>>> arch/arm/mach-davinci/da8xx-dt.c | 2 ++
>>>> 1 file changed, 2 insertions(+)
>>>>
>>>> diff --git a/arch/arm/mach-davinci/da8xx-dt.c
>>>> b/arch/arm/mach-davinci/da8xx-dt.c
>>>> index c9f7e92..7947267 100644
>>>> --- a/arch/arm/mach-davinci/da8xx-dt.c
>>>> +++ b/arch/arm/mach-davinci/da8xx-dt.c
>>>> @@ -45,6 +45,8 @@
>>>>
>>>> static void __init da850_init_machine(void)
>>>> {
>>>> + da8xx_register_usb20_phy_clk(false);
>>>> + da8xx_register_usb11_phy_clk(false);
>>>> of_platform_default_populate(NULL, da850_auxdata_lookup, NULL);
>>>> }
>>>>
>>>>
>>>
>>>
>>> You should check for error on return and print a warning if there is an
>>> error. Like this: https://patchwork.kernel.org/patch/9395635/
>>>
>>> (I actually just had to make this change a few minutes ago to
>>> troubleshoot a problem that I am working on.
>>> da8xx_register_usb11_phy_clk() is failing for some reason that I have
>>> not figured out yet.)
>>
>>
>>
>> And actually, since my patch that provides these functions has not been
>> accepted yet, why don't I just add this change to that series?
>
> Ok, sure, if you are planing on sending another version.
>
> Regards
> Axel
>
Yes, I have some more changes to make and resubmit, so I will include
this too.
^ permalink raw reply
* [PATCH] ARM: davinci: register the usb20_phy clock on the DT file
From: Axel Haslam @ 2016-10-26 20:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <48fa5315-74db-cf33-1f34-86764f0e2c1c@lechnology.com>
On Wed, Oct 26, 2016 at 10:03 PM, David Lechner <david@lechnology.com> wrote:
> On 10/26/2016 03:01 PM, David Lechner wrote:
>>
>> On 10/26/2016 02:49 PM, ahaslam at baylibre.com wrote:
>>>
>>> From: Axel Haslam <ahaslam@baylibre.com>
>>>
>>> The usb20_phy clock needs to be registered for the driver to be able
>>> to get and enable a clock. Currently the usb phy clocks are registered
>>> form board files, which will not be called during a device tree based
>>> boot.
>>>
>>> To be able to probe correctly usb form a device tree boot, register
>>> the usb phy clocks form the DT specific init.
>>>
>>> Unfourtunatly, davinci does not have proper clock support on device tree
>>> yet, so by registering the clock form de DT specific file we are
>>> forced to hardcode the parent clock, and cannot select refclkin as
>>> parent for any of the phy clocks of the da850 family.
>>>
>>> As none of the current da850 based boards currently in mainline use
>>> refclkin as source. I guess we can live with this limitation until clocks
>>> are correctly represented through CCF/device tree.
>>>
>>> Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
>>> ---
>>>
>>> This patch depends on David's series for usb clocks:
>>>
>>> currently:
>>> [PATCH v6 0/5] da8xx USB PHY platform devices and clocks
>>> https://lkml.org/lkml/2016/10/25/867
>>>
>>> arch/arm/mach-davinci/da8xx-dt.c | 2 ++
>>> 1 file changed, 2 insertions(+)
>>>
>>> diff --git a/arch/arm/mach-davinci/da8xx-dt.c
>>> b/arch/arm/mach-davinci/da8xx-dt.c
>>> index c9f7e92..7947267 100644
>>> --- a/arch/arm/mach-davinci/da8xx-dt.c
>>> +++ b/arch/arm/mach-davinci/da8xx-dt.c
>>> @@ -45,6 +45,8 @@
>>>
>>> static void __init da850_init_machine(void)
>>> {
>>> + da8xx_register_usb20_phy_clk(false);
>>> + da8xx_register_usb11_phy_clk(false);
>>> of_platform_default_populate(NULL, da850_auxdata_lookup, NULL);
>>> }
>>>
>>>
>>
>>
>> You should check for error on return and print a warning if there is an
>> error. Like this: https://patchwork.kernel.org/patch/9395635/
>>
>> (I actually just had to make this change a few minutes ago to
>> troubleshoot a problem that I am working on.
>> da8xx_register_usb11_phy_clk() is failing for some reason that I have
>> not figured out yet.)
>
>
>
> And actually, since my patch that provides these functions has not been
> accepted yet, why don't I just add this change to that series?
Ok, sure, if you are planing on sending another version.
Regards
Axel
^ 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