* mpic build failure for 7447_hpc defconfig (bisected)
From: Paul Gortmaker @ 2014-01-08 22:45 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
Commit 446f6d06fab0b49c61887ecbe8286d6aaa796637 ("powerpc/mpic: Properly
set default triggers") breaks the mpc7447_hpc_defconfig as follows:
CC arch/powerpc/sysdev/mpic.o
arch/powerpc/sysdev/mpic.c: In function 'mpic_set_irq_type':
arch/powerpc/sysdev/mpic.c:886:9: error: case label does not reduce to an integer constant
arch/powerpc/sysdev/mpic.c:890:9: error: case label does not reduce to an integer constant
arch/powerpc/sysdev/mpic.c:894:9: error: case label does not reduce to an integer constant
arch/powerpc/sysdev/mpic.c:898:9: error: case label does not reduce to an integer constant
Looking at the cpp output (gcc 4.7.3 from the kernel.org toolchains), I see:
case mpic->hw_set[MPIC_IDX_VECPRI_SENSE_EDGE] |
mpic->hw_set[MPIC_IDX_VECPRI_POLARITY_POSITIVE]:
The pointer into an array appears because CONFIG_MPIC_WEIRD=y is set for
this thing.
-------------------
#ifdef CONFIG_MPIC_WEIRD
static u32 mpic_infos[][MPIC_IDX_END] = {
[0] = { /* Original OpenPIC compatible MPIC */
[...]
#define MPIC_INFO(name) mpic->hw_set[MPIC_IDX_##name]
#else /* CONFIG_MPIC_WEIRD */
#define MPIC_INFO(name) MPIC_##name
#endif /* CONFIG_MPIC_WEIRD */
-------------------
Given it has been broken since 3.4-rc5, is it safe to say MPIC_WEIRD is dead
and unused? Or should the case be converted to if/else or similar? Or were
other versions of gcc actually able to "see" constant numbers?
Paul.
--
^ permalink raw reply
* Re: [PATCH 02/12][v4] pci: fsl: add structure fsl_pci
From: Scott Wood @ 2014-01-08 21:58 UTC (permalink / raw)
To: Minghuan Lian; +Cc: Bjorn Helgaas, linux-pci, linuxppc-dev, Zang Roy-R61911
In-Reply-To: <1389157323-3088-2-git-send-email-Minghuan.Lian@freescale.com>
On Wed, 2014-01-08 at 13:01 +0800, Minghuan Lian wrote:
> PowerPC uses structure pci_controller to describe PCI controller,
> but ARM uses structure pci_sys_data. In order to support PowerPC
> and ARM simultaneously, the patch adds a structure fsl_pci that
> contains most of the members of the pci_controller and pci_sys_data.
> Meanwhile, it defines a interface fsl_arch_sys_to_pci() which should
> be implemented in architecture-specific PCI controller driver to
> convert pci_controller or pci_sys_data to fsl_pci.
>
> Signed-off-by: Minghuan Lian <Minghuan.Lian@freescale.com>
> ---
> change log:
> v4:
> Added indirect type macro
> v1-v3:
> Derived from http://patchwork.ozlabs.org/patch/278965/
>
> Based on upstream master.
> Based on the discussion of RFC version here
> http://patchwork.ozlabs.org/patch/274487/
>
> include/linux/fsl/pci-common.h | 48 ++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 48 insertions(+)
Same comments on this patchset as last time.
-Scott
^ permalink raw reply
* Re: [v3, 3/7] powerpc: enable the relocatable support for the fsl booke 32bit kernel
From: Scott Wood @ 2014-01-08 21:46 UTC (permalink / raw)
To: Kevin Hao; +Cc: linuxppc
In-Reply-To: <20140108024235.GA20739@pek-khao-d1.corp.ad.wrs.com>
On Wed, 2014-01-08 at 10:42 +0800, Kevin Hao wrote:
> On Tue, Jan 07, 2014 at 05:46:04PM -0600, Scott Wood wrote:
> > On Sat, 2014-01-04 at 14:34 +0800, Kevin Hao wrote:
> > > > I'm having a hard time following the logic here. What is PAGE_OFFSET -
> > > > offset supposed to be? Why would we map anything belowe PAGE_OFFSET?
> > >
> > > No, we don't map the address below PAGE_OFFSET.
> > > memstart_addr is the physical start address of RAM.
> > > start is the kernel running physical address aligned with 64M.
> > >
> > > offset = memstart_addr - start
> > >
> > > So if memstart_addr < start, the offset is negative. The PAGE_OFFSET - offset
> > > is the virtual start address we should use for the init 64M map. It's above
> > > the PAGE_OFFSET instead of below.
> >
> > Oh. I think it'd be more readable to do "offset = start -
> > memstart_addr" and add offset instead of subtracting it.
>
> Yes, I agree. The reason that I use "offset = memstart_addr - start" is that
> it seems "memstart_addr" is always greater than "start" when we are booting
> a kdump kernel with a kernel option like "crashkernel=64M@80M". :-)
...so there is a situation where you map below PAGE_OFFSET. :-)
> > Also, offset should be phys_addr_t -- even if you don't expect to
> > support offsets greater than 4G on 32-bit, it's semantically the right
> > type to use. Plus, "int" would break if this code were ever used with
> > 64-bit.
>
> I thought about using phy_addr_t for the "offset" originally but gave it up
> for the following reasons:
> * It will not be greater than 4G.
> * We have to use the ugly #ifdef CONFIG_PHYS_64BIT in restore_to_as0().
> * Need more registers for arguments for restore_to_as0().
>
> Of course you can change it to phys_addr_t if you prefer.
I'd at least like to make it "long".
-Scott
^ permalink raw reply
* Re: PCIE device errors after linux kernel upgrade
From: Scott Wood @ 2014-01-08 21:07 UTC (permalink / raw)
To: ravich; +Cc: linuxppc-dev
In-Reply-To: <1389169499473-79160.post@n7.nabble.com>
On Wed, 2014-01-08 at 00:24 -0800, ravich wrote:
> Finally I found the problem causing the sudden system reset :
>
> our setup :
>
> P2020<====>PCI Bridge <=====> FPGA
>
> The reset occurs when we allocating skb and giving the Fpga dma addr of
> skb->data of this skb and when the FPGA tries to reach this address we are
> having a hardware reset.
>
> To fixed it we used GFP_DMA flag on skb allocations.
>
> If you can explain me few thinks I will be more then happy :
> 1) how come we managed to work in 2.6.32 kernel without this flag.
Maybe you got lucky, allocation patterns changed, etc?
> 2) Ok gave you a bad dma address why reset the system without any warning.
If you write to random addresses arbitrary things can happen.
-Scott
^ permalink raw reply
* Re: [PATCH RFC 2/3] ARM: kernel: add support for cpu cache information
From: Russell King - ARM Linux @ 2014-01-08 20:57 UTC (permalink / raw)
To: Sudeep Holla
Cc: devicetree, Ashok Raj, Rob Herring, x86, linux-kernel,
Greg Kroah-Hartman, linuxppc-dev, linux-arm-kernel
In-Reply-To: <1389209168-17189-3-git-send-email-sudeep.holla@arm.com>
On Wed, Jan 08, 2014 at 07:26:07PM +0000, Sudeep Holla wrote:
> +#if __LINUX_ARM_ARCH__ < 7 /* pre ARMv7 */
> +
> +#define MAX_CACHE_LEVEL 1 /* Only 1 level supported */
> +#define CTR_CTYPE_SHIFT 24
> +#define CTR_CTYPE_MASK (1 << CTR_CTYPE_SHIFT)
> +
> +static inline unsigned int get_ctr(void)
> +{
> + unsigned int ctr;
> + asm volatile ("mrc p15, 0, %0, c0, c0, 1" : "=r" (ctr));
> + return ctr;
> +}
> +
> +static enum cache_type get_cache_type(int level)
> +{
> + if (level > MAX_CACHE_LEVEL)
> + return CACHE_TYPE_NOCACHE;
> + return get_ctr() & CTR_CTYPE_MASK ?
> + CACHE_TYPE_SEPARATE : CACHE_TYPE_UNIFIED;
So, what do we do for CPUs that don't implement the CTR? Just return
random rubbish based on decoding the CPU Identity register as if it
were the cache type register?
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* Re: [PATCH RFC 1/3] drivers: base: support cpu cache information interface to userspace via sysfs
From: Greg Kroah-Hartman @ 2014-01-08 20:28 UTC (permalink / raw)
To: Sudeep Holla
Cc: devicetree, Ashok Raj, Rob Herring, x86, linux-kernel,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <1389209168-17189-2-git-send-email-sudeep.holla@arm.com>
On Wed, Jan 08, 2014 at 07:26:06PM +0000, Sudeep Holla wrote:
> From: Sudeep Holla <sudeep.holla@arm.com>
> +#define define_one_ro(_name) \
> +static struct cache_attr _name = \
> + __ATTR(_name, 0444, show_##_name, NULL)
In the future, we do have __ATTR_RO(), which should be used instead.
You should never use __ATTR() on it's own, if at all possible. I'm
sweeping the tree for all usages and fixing them slowly up over time.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH RFC 1/3] drivers: base: support cpu cache information interface to userspace via sysfs
From: Greg Kroah-Hartman @ 2014-01-08 20:27 UTC (permalink / raw)
To: Sudeep Holla
Cc: devicetree, Ashok Raj, Rob Herring, x86, linux-kernel,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <1389209168-17189-2-git-send-email-sudeep.holla@arm.com>
On Wed, Jan 08, 2014 at 07:26:06PM +0000, Sudeep Holla wrote:
> From: Sudeep Holla <sudeep.holla@arm.com>
>
> This patch adds initial support for providing processor cache information
> to userspace through sysfs interface. This is based on x86 implementation
> and hence the interface is intended to be fully compatible.
>
> A per-cpu array of cache information maintained is used mainly for
> sysfs-related book keeping.
>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
> drivers/base/Makefile | 2 +-
> drivers/base/cacheinfo.c | 296 ++++++++++++++++++++++++++++++++++++++++++++++
> include/linux/cacheinfo.h | 43 +++++++
> 3 files changed, 340 insertions(+), 1 deletion(-)
> create mode 100644 drivers/base/cacheinfo.c
> create mode 100644 include/linux/cacheinfo.h
>
> diff --git a/drivers/base/Makefile b/drivers/base/Makefile
> index 94e8a80..76f07c8 100644
> --- a/drivers/base/Makefile
> +++ b/drivers/base/Makefile
> @@ -4,7 +4,7 @@ obj-y := core.o bus.o dd.o syscore.o \
> driver.o class.o platform.o \
> cpu.o firmware.o init.o map.o devres.o \
> attribute_container.o transport_class.o \
> - topology.o
> + topology.o cacheinfo.o
> obj-$(CONFIG_DEVTMPFS) += devtmpfs.o
> obj-$(CONFIG_DMA_CMA) += dma-contiguous.o
> obj-y += power/
> diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c
> new file mode 100644
> index 0000000..f436c31
> --- /dev/null
> +++ b/drivers/base/cacheinfo.c
> @@ -0,0 +1,296 @@
> +/*
> + * cacheinfo support - processor cache information via sysfs
> + *
> + * Copyright (C) 2013 ARM Ltd.
> + * All Rights Reserved
> + *
> + * Author: Sudeep Holla <sudeep.holla@arm.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +#include <linux/bitops.h>
> +#include <linux/cacheinfo.h>
> +#include <linux/compiler.h>
> +#include <linux/cpu.h>
> +#include <linux/device.h>
> +#include <linux/init.h>
> +#include <linux/kobject.h>
> +#include <linux/of.h>
> +#include <linux/sched.h>
> +#include <linux/slab.h>
> +#include <linux/smp.h>
> +#include <linux/sysfs.h>
> +
> +struct cache_attr {
> + struct attribute attr;
> + ssize_t(*show) (unsigned int, unsigned short, char *);
> + ssize_t(*store) (unsigned int, unsigned short, const char *, size_t);
> +};
> +
> +/* pointer to kobject for cpuX/cache */
> +static DEFINE_PER_CPU(struct kobject *, ci_cache_kobject);
> +#define per_cpu_cache_kobject(cpu) (per_cpu(ci_cache_kobject, cpu))
> +
> +struct index_kobject {
> + struct kobject kobj;
> + unsigned int cpu;
> + unsigned short index;
> +};
> +
> +static cpumask_t cache_dev_map;
> +
> +/* pointer to array of kobjects for cpuX/cache/indexY */
Please don't use "raw" kobjects for this, use the device attribute
groups, that's what they are there for. Bonus is that your code should
get a lot simpler when you do that.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH RFC 1/3] drivers: base: support cpu cache information interface to userspace via sysfs
From: Greg Kroah-Hartman @ 2014-01-08 20:26 UTC (permalink / raw)
To: Sudeep Holla
Cc: devicetree, Ashok Raj, Rob Herring, x86, linux-kernel,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <1389209168-17189-2-git-send-email-sudeep.holla@arm.com>
On Wed, Jan 08, 2014 at 07:26:06PM +0000, Sudeep Holla wrote:
> From: Sudeep Holla <sudeep.holla@arm.com>
>
> This patch adds initial support for providing processor cache information
> to userspace through sysfs interface. This is based on x86 implementation
> and hence the interface is intended to be fully compatible.
>
> A per-cpu array of cache information maintained is used mainly for
> sysfs-related book keeping.
>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
> drivers/base/Makefile | 2 +-
> drivers/base/cacheinfo.c | 296 ++++++++++++++++++++++++++++++++++++++++++++++
> include/linux/cacheinfo.h | 43 +++++++
> 3 files changed, 340 insertions(+), 1 deletion(-)
> create mode 100644 drivers/base/cacheinfo.c
> create mode 100644 include/linux/cacheinfo.h
You are creating sysfs files, yet you didn't add Documentation/ABI/
information, which is required. Please fix that.
greg k-h
^ permalink raw reply
* Re: [PATCH v5 1/1] powerpc/embedded6xx: Add support for Motorola/Emerson MVME5100
From: Stephen N Chivers @ 2014-01-08 19:20 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Stephen N Chivers
In-Reply-To: <1389138670.11795.208.camel@snotra.buserror.net>
Scott Wood <scottwood@freescale.com> wrote on 01/08/2014 10:51:10 AM:
> From: Scott Wood <scottwood@freescale.com>
> To: Stephen N Chivers/AUS/CSC@CSC
> Cc: <benh@kernel.crashing.org>, <linuxppc-dev@lists.ozlabs.org>
> Date: 01/08/2014 10:51 AM
> Subject: Re: [PATCH v5 1/1] powerpc/embedded6xx: Add support for
> Motorola/Emerson MVME5100
>
> On Mon, 2014-01-06 at 12:23 +1100, Stephen Chivers wrote:
> > Add support for the Motorola/Emerson MVME5100 Single Board Computer.
> >
> > The MVME5100 is a 6U form factor VME64 computer with:
> >
> > - A single MPC7410 or MPC750 CPU
> > - A HAWK Processor Host Bridge (CPU to PCI) and
> > MultiProcessor Interrupt Controller (MPIC)
> > - Up to 500Mb of onboard memory
> > - A M48T37 Real Time Clock (RTC) and Non-Volatile Memory chip
> > - Two 16550 compatible UARTS
> > - Two Intel E100 Fast Ethernets
> > - Two PCI Mezzanine Card (PMC) Slots
> > - PPCBug Firmware
> >
> > The HAWK PHB/MPIC is compatible with the MPC10x devices.
> >
> > There is no onboard disk support. This is usually provided by
> installing a PMC
> > in first PMC slot.
> >
> > This patch revives the board support, it was present in early 2.6
> > series kernels. The board support in those days was by Matt Porter of
> > MontaVista Software.
> >
> > CSC Australia has around 31 of these boards in service. The kernel in
use
> > for the boards is based on 2.6.31. The boards are operated without
disks
> > from a file server.
> >
> > This patch is based on linux-3.13-rc2 and has been boot tested.
> >
> > Only boards with 512 Mb of memory are known to work.
> >
> > V1->V2:
> > Address comments by Kumar Gala and Scott Wood.
> > Minor adjustment to platforms/embedded6xx/Kconfig to ensure
> > correct indentation where possible.
> >
> > V2->V3:
> > Address comments by Scott Wood and Ben Herrenschmidt.
> > Address errors reported by checkpatch.
> >
> > V3->V4:
> > Address comment by Geert Uytterhoeven
> > Add tested by Alessio Bogani.
> >
> > V4->V5:
> > Correct horrible typo in patch history.
> > Kular Gama is Kumar Gala.
>
> The patch history should go below the --- line, as it's for reviewers
> who have seen previous versions rather than for the git history.
Ok.
>
> -Scott
>
>
^ permalink raw reply
* Re: 答复: [v7] clk: corenet: Adds the clock binding
From: Scott Wood @ 2014-01-08 18:43 UTC (permalink / raw)
To: Mark Rutland
Cc: Yuantian Tang, linuxppc-dev@lists.ozlabs.org,
devicetree@vger.kernel.org
In-Reply-To: <20140108093046.GB6701@e106331-lin.cambridge.arm.com>
On Wed, 2014-01-08 at 09:30 +0000, Mark Rutland wrote:
> On Wed, Jan 08, 2014 at 08:53:56AM +0000, Yuantian Tang wrote:
> >
> > ________________________________________
> > 发件人: Wood Scott-B07421
> > 发送时间: 2014年1月8日 8:21
> > 收件人: Tang Yuantian-B29983
> > 抄送: galak@kernel.crashing.org; mark.rutland@arm.com; devicetree@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
> > 主题: Re: [v7] clk: corenet: Adds the clock binding
> >
> > On Wed, Nov 20, 2013 at 05:04:49PM +0800, tang yuantian wrote:
> > > +Recommended properties:
> > > +- ranges: Allows valid translation between child's address space and
> > > + parent's. Must be present if the device has sub-nodes.
> > > +- #address-cells: Specifies the number of cells used to represent
> > > + physical base addresses. Must be present if the device has
> > > + sub-nodes and set to 1 if present
> > > +- #size-cells: Specifies the number of cells used to represent
> > > + the size of an address. Must be present if the device has
> > > + sub-nodes and set to 1 if present
> >
> > Why are we specifying #address-cells/#size-cells here?
> >
> > A: it has sub-nodes which have REG property, don't we need to
> > specify #address-cells/#size-cells?
>
> If a node has a reg entry, its parent should have #size-cells and
> #address-cells to allow it to be parsed properly.
Yes, but why do we need to specify in this binding how many cells there
will be, especially since this binding only addresses the clock provider
aspect of the clockgen nodes (e.g. it doesn't describe the reg)? Or
rather, it's partially describing the non-clock aspect, and doesn't
address the clock aspect at all AFAICT.
Where does the actual input clock frequency go? U-Boot puts it in the
clockgen node itself as clock-frequency, but that isn't described in the
binding. How does that relate to the sysclk node? If
"fsl,qoriq-sysclk-1.0" is supposed to indicate that clock-frequency can
be found in the parent node, that isn't specified by the binding, nor is
clock-frequency shown in the example.
What is the difference between "fsl,qoriq-sysclk-1.0" and
"fsl,qoriq-sysclk-2.0"? How does the concept of a fixed input clock
change?
-Scott
^ permalink raw reply
* Re: [PATCH] powerpc: Fix alignment of secondary cpu spin vars
From: Olof Johansson @ 2014-01-08 17:48 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Michael Ellerman, linuxppc-dev, linux-kernel@vger.kernel.org,
Anton Blanchard, chzigotzky
In-Reply-To: <1389154706.4672.21.camel@pasglop>
On Wed, Jan 08, 2014 at 03:18:26PM +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2014-01-08 at 15:09 +1100, Michael Ellerman wrote:
> > > Of course, main worry is that this is just hiding some latent NULL
> > deref in
> > > the kernel now... :-/
> >
> > Wow, that would have to come close to winning the
> > grossest-hack-in-arch-powerpc
> > award :)
> >
> > Have you tried changing the value at 8 to point to a reserved page?
> >
> > Some other possibilities:
> >
> > * Change the #define so FIXUP_ENDIAN is empty for PASEMI, that would
> > mean
> > you'd only be able to boot pasemi_defconfig.
No thanks -- this went uncaught because that used to be all I booted
(and for some random reason it didn't trigger in that case).
> > * Move the hack into FIXUP_ENDIAN
>
> We actually found the root cause on irc the other day, I was waiting for
> Olof to send a fix :-)
Yeah, I'm low on spare time these days, in particular spare time to spend on
ppc stuff. :-(
> Olof: Can you try this totally untested patch ?
With one fixup below:
Tested-by: Olof Johansson <olof@lixom.net>
> --- a/arch/powerpc/kernel/prom_init.c
> +++ b/arch/powerpc/kernel/prom_init.c
> @@ -1986,8 +1986,6 @@ static void __init prom_init_stdout(void)
> /* Get the full OF pathname of the stdout device */
> memset(path, 0, 256);
> call_prom("instance-to-path", 3, 1, prom.stdout, path, 255);
> - stdout_node = call_prom("instance-to-package", 1, 1, prom.stdout);
> - val = cpu_to_be32(stdout_node);
> prom_setprop(prom.chosen, "/chosen", "linux,stdout-package",
> &val, sizeof(val));
> prom_printf("OF stdout device is: %s\n", of_stdout_device);
> @@ -1995,10 +1993,14 @@ static void __init prom_init_stdout(void)
> path, strlen(path) + 1);
>
> /* If it's a display, note it */
> - memset(type, 0, sizeof(type));
> - prom_getprop(stdout_node, "device_type", type, sizeof(type));
> - if (strcmp(type, "display") == 0)
> - prom_setprop(stdout_node, path, "linux,boot-display", NULL, 0);
> + stdout_node = call_prom("instance-to-package", 1, 1, prom.stdout);
> + if (stdout_node != PROM_ERROR) {
> + val = cpu_to_be32(stdout_node);
> + memset(type, 0, sizeof(type));
> + prom_getprop(stdout_node, "device_type", type, sizeof(type));
> + if (strcmp(type, "display") == 0)
> + prom_setprop(stdout_node, path, "linux,boot-display", NU
Line is cut off, this needs "NULL, 0);" at the end.
-Olof
^ permalink raw reply
* Re: [PATCH RFC v6 4/5] dma: mpc512x: register for device tree channel lookup
From: Gerhard Sittig @ 2014-01-08 16:47 UTC (permalink / raw)
To: Alexander Popov
Cc: Lars-Peter Clausen, Arnd Bergmann, Vinod Koul, dmaengine,
Dan Williams, Anatolij Gustschin, linuxppc-dev
In-Reply-To: <CAF0T0X7wotm60Bq4tfYcRhkDwiCw2hh5R5m2WmVLmLGLZYpQsQ@mail.gmail.com>
[ dropping devicetree from the Cc: list ]
[ what is the semantics of DMA_PRIVATE capability flag?
is documentation available beyond the initial commit message?
need individual channels be handled instead of controllers? ]
On Sat, Jan 04, 2014 at 00:54 +0400, Alexander Popov wrote:
>
> Hello Gerhard.
> Thanks for your review.
>
> 2013/12/26 Gerhard Sittig <gsi@denx.de>:
> > [ dropping devicetree, we're DMA specific here ]
> >
> > On Tue, Dec 24, 2013 at 16:06 +0400, Alexander Popov wrote:
> >>
> >> --- a/drivers/dma/mpc512x_dma.c
> >> +++ b/drivers/dma/mpc512x_dma.c
> >> [ ... ]
> >> @@ -950,6 +951,7 @@ static int mpc_dma_probe(struct platform_device *op)
> >> INIT_LIST_HEAD(&dma->channels);
> >> dma_cap_set(DMA_MEMCPY, dma->cap_mask);
> >> dma_cap_set(DMA_SLAVE, dma->cap_mask);
> >> + dma_cap_set(DMA_PRIVATE, dma->cap_mask);
> >>
> >> for (i = 0; i < dma->chancnt; i++) {
> >> mchan = &mdma->channels[i];
> >
> > What are the implications of this? Is a comment due?
>
> I've involved DMA_PRIVATE flag because new of_dma_xlate_by_chan_id()
> uses dma_get_slave_channel() instead of dma_request_channel()
> (PATCH RFC v6 3/5). This flag is implicitly set in dma_request_channel(),
> but is not set in dma_get_slave_channel().
>
> There are only two places in the mainline kernel, where
> dma_get_slave_channel() is used. I've picked up the idea
> at one of these places. Please look at this patch:
> http://www.spinics.net/lists/arm-kernel/msg268718.html
I agree that the change looks simple, and there is no doubt that
other drivers apply the flag. None of this I questioned. Yet
I'm afraid that the implications are rather huge.
Unless I miss something, I'd happily learn where I'm wrong.
> > I haven't found documentation about the DMA_PRIVATE flag, only
> > saw commit 59b5ec21446b9 "dmaengine: introduce
> > dma_request_channel and private channels".
>
> Unfortunately I didn't find any description of DMA_PRIVATE flag too.
> But the comment at the beginning of drivers/dma/dmaengine.c
> may give a clue. Quotation:
> * subsystem can get access to a channel by calling dmaengine_get() followed
> * by dma_find_channel(), or if it has need for an exclusive channel
> it can call
> * dma_request_channel(). Once a channel is allocated a reference is taken
> * against its corresponding driver to disable removal.
>
> DMA_PRIVATE capability flag might indicate that the DMA controller
> can provide exclusive channels to its clients. Please correct me if I'm wrong.
>
> > Alex, unless I'm
> > missing something this one-line change is quite a change in
> > semantics, and has dramatic influence on the code's behaviour
> > (ignores the DMA controller when looking for channels that can do
> > mem-to-mem transfers)
>
> Excuse me, Gerhard, I don't see what you mean.
> Could you point to the corresponding code?
You did see `git show 59b5ec21446b9`, didn't you? The commit
message strongly suggests that DMA_PRIVATE applies to the whole
DMA controller and excludes _all_ of its channels from the
general purpose allocator which mem-to-mem transfers appear to be
using. It's not just a hint, but an active decision to reject
requests.
Not only checking code references, but doing a text search,
reveals one more comment on the DMA_PRIVATE flag in a crypto
related document, which supports my interpretation:
Documentation/crypto/async-tx-api.txt:203
Can somebody ACK or NAK my interpretation? Dan, you committed
this change which introduced the DMA_PRIVATE logic. What was the
motivation for it, or the goal to achieve? Do other platforms
have several dedicated DMA controllers, some for peripherals and
some for memory transfers? Should the "private" flag apply to
channels and not whole controllers? Am I over-estimating the
benefit or importance of DMA supported memory transfers?
Still I see a difference in the lookup approaches: Yours applies
DMA_PRIVATE globally and in advance, preventing _any_ use of DMA
for memory transfers. While the __dma_request_channel() routine
only applies it _temporarily_ around a dma_chan_get() operation.
Allowing for use of DMA channels by both individual peripherals
as well as memory transfers.
> > Consider the fact that this driver
> > handles both MPC5121 as well as MPC8308 hardware.
>
> Ah, yes, sorry. I should certainly fix this, if setting of DMA_PRIVATE flag
> is needed at all.
What I meant here is that implications for all affected platforms
should be considered. There is one driver source, but the driver
applies to more than one platform (another issue of the driver is
that this is not apparent from the doc nor the compat strings).
MPC512x has one (GP) DMA controller, of which one channel is
dedicated to DDR, and all other channels can get used for memory
transfers as well. In addition to most channels being connected
to a specific peripheral for flow control. Which your patch set
introduces initial support for.
MPC8308 has _all_ channels for memory transfers exclusively (or
at least none of its channels supports flow control).
So blocking memory transfers in mpc512x_dma.c is a total breakage
for MPC8308 (removes the only previous feature and adds nothing),
and is a regression for MPC512x (removes the previously supported
memory transfers, while it may add peripheral supports with very
few users).
virtually yours
Gerhard Sittig
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
^ permalink raw reply
* RE: [PATCH] KVM: PPC: Add devname:kvm aliases for modules
From: mihai.caraman @ 2014-01-08 15:41 UTC (permalink / raw)
To: agraf@suse.de, kvm-ppc@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org mailing list
> -----Original Message-----
> From: kvm-ppc-owner@vger.kernel.org [mailto:kvm-ppc-
> owner@vger.kernel.org] On Behalf Of Alexander Graf
> Sent: Monday, December 09, 2013 5:02 PM
> To: "; " <kvm-ppc@vger.kernel.org>"@suse.de
> Cc: kvm@vger.kernel.org mailing list
> Subject: [PATCH] KVM: PPC: Add devname:kvm aliases for modules
>=20
> Systems that support automatic loading of kernel modules through
> device aliases should try and automatically load kvm when /dev/kvm
> gets opened.
>=20
> Add code to support that magic for all PPC kvm targets, even the
> ones that don't support modules yet.
>=20
> Signed-off-by: Alexander Graf <agraf@suse.de>
...
> --- a/arch/powerpc/kvm/e500mc.c
> +++ b/arch/powerpc/kvm/e500mc.c
> @@ -391,3 +391,6 @@ static void __exit kvmppc_e500mc_exit(void)
>=20
> module_init(kvmppc_e500mc_init);
> module_exit(kvmppc_e500mc_exit);
> +#include <linux/miscdevice.h>
> +MODULE_ALIAS_MISCDEV(KVM_MINOR);
> +MODULE_ALIAS("devname:kvm");
> --
This patch breaks the build on KMV Book3E, you need to include
<linux/module.h> too.
-Mike
^ permalink raw reply
* Re: [PATCH] slub: Don't throw away partial remote slabs if there is no local memory
From: Anton Blanchard @ 2014-01-08 14:17 UTC (permalink / raw)
To: Wanpeng Li; +Cc: cl, nacc, penberg, linux-mm, paulus, mpm, linuxppc-dev
In-Reply-To: <20140107041939.GA20916@hacker.(null)>
Hi Wanpeng,
> >+ if (node_spanned_pages(node)) {
>
> s/node_spanned_pages/node_present_pages
Thanks, I hadn't come across node_present_pages() before.
Anton
^ permalink raw reply
* Re: [PATCH] slub: Don't throw away partial remote slabs if there is no local memory
From: Anton Blanchard @ 2014-01-08 14:14 UTC (permalink / raw)
To: David Laight
Cc: cl@linux-foundation.org, nacc@linux.vnet.ibm.com,
penberg@kernel.org, linux-mm@kvack.org, paulus@samba.org,
mpm@selenic.com, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D453A4E@AcuExch.aculab.com>
Hi David,
> Why not just delete the entire test?
> Presumably some time a little earlier no local memory was available.
> Even if there is some available now, it is very likely that some won't
> be available again in the near future.
I agree, the current behaviour seems strange but it has been around
since the inital slub commit.
Anton
^ permalink raw reply
* Re: [PATCH] slub: Don't throw away partial remote slabs if there is no local memory
From: Anton Blanchard @ 2014-01-08 14:03 UTC (permalink / raw)
To: Andi Kleen; +Cc: cl, nacc, penberg, linux-mm, paulus, mpm, linuxppc-dev
In-Reply-To: <871u0k5lri.fsf@tassilo.jf.intel.com>
Hi Andi,
> > Thoughts? It seems like we could hit a similar situation if a
> > machine is balanced but we run out of memory on a single node.
>
> Yes I agree, but your patch doesn't seem to attempt to handle this?
It doesn't. I was hoping someone with more mm knowledge than I could
suggest a lightweight way of doing this.
Anton
^ permalink raw reply
* Re: [PATCH] powerpc: add vr save/restore functions
From: Andreas Schwab @ 2014-01-08 9:54 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
In-Reply-To: <1389154699.2076.6.camel@concordia>
Michael Ellerman <michael@ellerman.id.au> writes:
> On Mon, 2013-12-30 at 15:31 +0100, Andreas Schwab wrote:
>> GCC 4.8 now generates out-of-line vr save/restore functions when
>> optimizing for size. They are needed for the raid6 altivec support.
>
> It looks like they're identical for 32 & 64-bit ?
They use different temporary registers and calling conventions (no .opd
for ppc64).
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: 答复: [v7] clk: corenet: Adds the clock binding
From: Mark Rutland @ 2014-01-08 9:30 UTC (permalink / raw)
To: Yuantian Tang
Cc: Scott Wood, devicetree@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <375c32b2f4e34589ae336af61468a51b@BL2PR03MB115.namprd03.prod.outlook.com>
On Wed, Jan 08, 2014 at 08:53:56AM +0000, Yuantian Tang wrote:
>
> ________________________________________
> 发件人: Wood Scott-B07421
> 发送时间: 2014年1月8日 8:21
> 收件人: Tang Yuantian-B29983
> 抄送: galak@kernel.crashing.org; mark.rutland@arm.com; devicetree@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
> 主题: Re: [v7] clk: corenet: Adds the clock binding
>
> On Wed, Nov 20, 2013 at 05:04:49PM +0800, tang yuantian wrote:
> > +Recommended properties:
> > +- ranges: Allows valid translation between child's address space and
> > + parent's. Must be present if the device has sub-nodes.
> > +- #address-cells: Specifies the number of cells used to represent
> > + physical base addresses. Must be present if the device has
> > + sub-nodes and set to 1 if present
> > +- #size-cells: Specifies the number of cells used to represent
> > + the size of an address. Must be present if the device has
> > + sub-nodes and set to 1 if present
>
> Why are we specifying #address-cells/#size-cells here?
>
> A: it has sub-nodes which have REG property, don't we need to
> specify #address-cells/#size-cells?
If a node has a reg entry, its parent should have #size-cells and
#address-cells to allow it to be parsed properly.
Mark.
^ permalink raw reply
* 答复: [v7] clk: corenet: Adds the clock binding
From: Yuantian Tang @ 2014-01-08 8:53 UTC (permalink / raw)
To: Scott Wood
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20140108002115.GA19801@home.buserror.net>
Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18Kt6K8/sjLOiBXb29kIFNj
b3R0LUIwNzQyMQq3osvNyrG85DogMjAxNMTqMdTCOMjVIDg6MjEKytW8/sjLOiBUYW5nIFl1YW50
aWFuLUIyOTk4MwqzrcvNOiBnYWxha0BrZXJuZWwuY3Jhc2hpbmcub3JnOyBtYXJrLnJ1dGxhbmRA
YXJtLmNvbTsgZGV2aWNldHJlZUB2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4cHBjLWRldkBsaXN0cy5v
emxhYnMub3JnCtb3zOI6IFJlOiBbdjddIGNsazogY29yZW5ldDogQWRkcyB0aGUgY2xvY2sgYmlu
ZGluZwoKT24gV2VkLCBOb3YgMjAsIDIwMTMgYXQgMDU6MDQ6NDlQTSArMDgwMCwgdGFuZyB5dWFu
dGlhbiB3cm90ZToKPiArUmVjb21tZW5kZWQgcHJvcGVydGllczoKPiArLSByYW5nZXM6IEFsbG93
cyB2YWxpZCB0cmFuc2xhdGlvbiBiZXR3ZWVuIGNoaWxkJ3MgYWRkcmVzcyBzcGFjZSBhbmQKPiAr
ICAgICBwYXJlbnQncy4gTXVzdCBiZSBwcmVzZW50IGlmIHRoZSBkZXZpY2UgaGFzIHN1Yi1ub2Rl
cy4KPiArLSAjYWRkcmVzcy1jZWxsczogU3BlY2lmaWVzIHRoZSBudW1iZXIgb2YgY2VsbHMgdXNl
ZCB0byByZXByZXNlbnQKPiArICAgICBwaHlzaWNhbCBiYXNlIGFkZHJlc3Nlcy4gIE11c3QgYmUg
cHJlc2VudCBpZiB0aGUgZGV2aWNlIGhhcwo+ICsgICAgIHN1Yi1ub2RlcyBhbmQgc2V0IHRvIDEg
aWYgcHJlc2VudAo+ICstICNzaXplLWNlbGxzOiBTcGVjaWZpZXMgdGhlIG51bWJlciBvZiBjZWxs
cyB1c2VkIHRvIHJlcHJlc2VudAo+ICsgICAgIHRoZSBzaXplIG9mIGFuIGFkZHJlc3MuIE11c3Qg
YmUgcHJlc2VudCBpZiB0aGUgZGV2aWNlIGhhcwo+ICsgICAgIHN1Yi1ub2RlcyBhbmQgc2V0IHRv
IDEgaWYgcHJlc2VudAoKV2h5IGFyZSB3ZSBzcGVjaWZ5aW5nICNhZGRyZXNzLWNlbGxzLyNzaXpl
LWNlbGxzIGhlcmU/CgpBOiBpdCBoYXMgc3ViLW5vZGVzIHdoaWNoIGhhdmUgUkVHIHByb3BlcnR5
LCBkb24ndCB3ZSBuZWVkIHRvIApzcGVjaWZ5ICNhZGRyZXNzLWNlbGxzLyNzaXplLWNlbGxzPwog
Cj4gKzIuIENsb2NrIFByb3ZpZGVyL0NvbnN1bWVyIEJpbmRpbmcKPiArCj4gK01vc3Qgb2YgdGhl
IGJpbmRpbmdzIGFyZSBmcm9tIHRoZSBjb21tb24gY2xvY2sgYmluZGluZ1sxXS4KPiArIFsxXSBE
b2N1bWVudGF0aW9uL2RldmljZXRyZWUvYmluZGluZ3MvY2xvY2svY2xvY2stYmluZGluZ3MudHh0
Cj4gKwo+ICtSZXF1aXJlZCBwcm9wZXJ0aWVzOgo+ICstIGNvbXBhdGlibGUgOiBTaG91bGQgaW5j
bHVkZSBvbmUgb2YgdGhlIGZvbGxvd2luZzoKPiArICAgICAqICJmc2wscW9yaXEtY29yZS1wbGwt
MS4wIiBmb3IgY29yZSBQTEwgY2xvY2tzICh2MS4wKQo+ICsgICAgKiAiZnNsLHFvcmlxLWNvcmUt
cGxsLTIuMCIgZm9yIGNvcmUgUExMIGNsb2NrcyAodjIuMCkKPiArICAgICogImZzbCxxb3JpcS1j
b3JlLW11eC0xLjAiIGZvciBjb3JlIG11eCBjbG9ja3MgKHYxLjApCj4gKyAgICAqICJmc2wscW9y
aXEtY29yZS1tdXgtMi4wIiBmb3IgY29yZSBtdXggY2xvY2tzICh2Mi4wKQo+ICsgICAgICogImZz
bCxxb3JpcS1zeXNjbGstMS4wIjogZm9yIGlucHV0IHN5c3RlbSBjbG9jayAodjEuMCkKPiArICAg
ICAqICJmc2wscW9yaXEtc3lzY2xrLTIuMCI6IGZvciBpbnB1dCBzeXN0ZW0gY2xvY2sgKHYyLjAp
CgpTb21lIG9mIHRob3NlIGxpbmVzIHVzZSB0YWJzIGFuZCBvdGhlcnMgc3BhY2VzIC0tIEkgY2Fu
IGZpeCB3aGVuIGFwcGx5aW5nLgpBOiBzb3JyeSBmb3IgdGhpcyBhbmQgdGhhbmtzIGZvciBmaXhp
bmcuCgpSZWdhcmRzLApZdWFudGlhbgoKLVNjb3R0Cg==
^ permalink raw reply
* Re: PCIE device errors after linux kernel upgrade
From: ravich @ 2014-01-08 8:24 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1383059241779-77605.post@n7.nabble.com>
Finally I found the problem causing the sudden system reset :
our setup :
P2020<====>PCI Bridge <=====> FPGA
The reset occurs when we allocating skb and giving the Fpga dma addr of
skb->data of this skb and when the FPGA tries to reach this address we are
having a hardware reset.
To fixed it we used GFP_DMA flag on skb allocations.
If you can explain me few thinks I will be more then happy :
1) how come we managed to work in 2.6.32 kernel without this flag.
2) Ok gave you a bad dma address why reset the system without any warning.
Thanks for your time and support
Leonid Ravich
--
View this message in context: http://linuxppc.10917.n7.nabble.com/Re-PCIE-device-errors-after-linux-kernel-upgrade-tp74563p79160.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* RE: [PATCH 2/2] fsl/pci: The new pci suspend/resume implementation
From: Dongsheng.Wang @ 2014-01-08 7:12 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: linuxppc-dev@lists.ozlabs.org, galak@codeaurora.org, Scott Wood,
linux-pci@vger.kernel.org, bhelgaas@google.com
In-Reply-To: <4984978.bktZCpdLkC@vostro.rjw.lan>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUmFmYWVsIEouIFd5c29j
a2kgW21haWx0bzpyandAcmp3eXNvY2tpLm5ldF0NCj4gU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5
IDA4LCAyMDE0IDQ6NDIgQU0NCj4gVG86IFdhbmcgRG9uZ3NoZW5nLUI0MDUzNA0KPiBDYzogYmhl
bGdhYXNAZ29vZ2xlLmNvbTsgV29vZCBTY290dC1CMDc0MjE7IGdhbGFrQGNvZGVhdXJvcmEub3Jn
OyBaYW5nIFJveS0NCj4gUjYxOTExOyBsaW51eC1wY2lAdmdlci5rZXJuZWwub3JnOyBsaW51eHBw
Yy1kZXZAbGlzdHMub3psYWJzLm9yZw0KPiBTdWJqZWN0OiBSZTogW1BBVENIIDIvMl0gZnNsL3Bj
aTogVGhlIG5ldyBwY2kgc3VzcGVuZC9yZXN1bWUgaW1wbGVtZW50YXRpb24NCj4gDQo+IE9uIFR1
ZXNkYXksIEphbnVhcnkgMDcsIDIwMTQgMDQ6MDQ6MDggUE0gRG9uZ3NoZW5nIFdhbmcgd3JvdGU6
DQo+ID4gRnJvbTogV2FuZyBEb25nc2hlbmcgPGRvbmdzaGVuZy53YW5nQGZyZWVzY2FsZS5jb20+
DQo+ID4NCj4gPiBUaGUgbmV3IHN1c3BlbmQvcmVzdW1lIGltcGxlbWVudGF0aW9uLCBzZW5kIHBt
ZSB0dXJub2ZmIG1lc3NhZ2UNCj4gPiBpbiBzdXNwZW5kLCBhbmQgc2VuZCBwbWUgZXhpdCBtZXNz
YWdlIGluIHJlc3VtZS4NCj4gPg0KPiA+IEFkZCBhIFBNRSBoYW5kbGVyLCB0byByZXNwb25zZSBQ
TUUgJiBtZXNzYWdlIGludGVycnVwdC4NCj4gPg0KPiA+IENoYW5nZSBwbGF0Zm9ybV9kcml2ZXIt
PnN1c3BlbmQvcmVzdW1lIHRvIHN5c2NvcmUtPnN1c3BlbmQvcmVzdW1lLg0KPiANCj4gQ2FuIHlv
dSBwbGVhc2UgZmlyc3QgZGVzY3JpYmUgdGhlIHByb2JsZW0geW91J3JlIHRyeWluZyB0byBhZGRy
ZXNzPw0KPiANCklmIHdlIGRvIG5vdGhpbmcgaW4gc3VzcGVuZC9yZXN1bWUsIHNvbWUgcGxhdGZv
cm0gUENJZSBpcC1ibG9jayBjYW4ndCBndWFyYW50ZWUNCnRoZSBsaW5rIGJhY2sgdG8gTDAgc3Rh
dGUgZnJvbSBzbGVlcCwgdGhlbiwgd2hlbiB3ZSByZWFkIHRoZSBFUCBkZXZpY2Ugd2lsbCBoYW5n
LiANCk9ubHkgd2Ugc2VuZCBwbWUgdHVybm9mZiBtZXNzYWdlIGluIHBjaSBjb250cm9sbGVyIHN1
c3BlbmQsIGFuZCBzZW5kIHBtZSBleGl0DQptZXNzYWdlIGluIHJlc3VtZSwgdGhlIGxpbmsgc3Rh
dGUgd2lsbCBiZSBub3JtYWwuDQoNCldoZW4gd2Ugc2VuZCBwbWUgdHVybm9mZiBtZXNzYWdlIGlu
IHBjaSBjb250cm9sbGVyIHN1c3BlbmQsIHRoZSBsaW5rcyB3aWxsIGludG8gbDIvbDMNCnJlYWR5
LCB0aGVuLCBob3N0IGNhbm5vdCBjb21tdW5pY2F0ZSB3aXRoIGVwIGRldmljZSwgYnV0IHBjaS1k
cml2ZXIgd2lsbCBjYWxsIGJhY2sgRVANCmRldmljZSB0byBzYXZlIHRoZW0gc3RhdGUuIFNvIHdl
IG5lZWQgdG8gY2hhbmdlIHBsYXRmb3JtX2RyaXZlci0+c3VzcGVuZC9yZXN1bWUgdG8NCnN5c2Nv
cmUtPnN1c3BlbmQvcmVzdW1lLg0KDQpUaGFua3MsDQotRG9uZ3NoZW5nDQo=
^ permalink raw reply
* RE: [PATCH 2/2] powerpc/85xx: handle the eLBC error interrupt if it exist in dts
From: Dongsheng.Wang @ 2014-01-08 7:12 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev@lists.ozlabs.org, Shaohui Xie
In-Reply-To: <1389127500.11795.184.camel@snotra.buserror.net>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29vZCBTY290dC1CMDc0
MjENCj4gU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDA4LCAyMDE0IDQ6NDUgQU0NCj4gVG86IFdh
bmcgRG9uZ3NoZW5nLUI0MDUzNA0KPiBDYzogbGludXhwcGMtZGV2QGxpc3RzLm96bGFicy5vcmc7
IFhpZSBTaGFvaHVpLUIyMTk4OTsgS3VtYXIgR2FsYQ0KPiBTdWJqZWN0OiBSZTogW1BBVENIIDIv
Ml0gcG93ZXJwYy84NXh4OiBoYW5kbGUgdGhlIGVMQkMgZXJyb3IgaW50ZXJydXB0IGlmIGl0DQo+
IGV4aXN0IGluIGR0cw0KPiANCj4gT24gVHVlLCAyMDE0LTAxLTA3IGF0IDA0OjAxIC0wNjAwLCBX
YW5nIERvbmdzaGVuZy1CNDA1MzQgd3JvdGU6DQo+ID4NCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVz
c2FnZS0tLS0tDQo+ID4gPiBGcm9tOiBXb29kIFNjb3R0LUIwNzQyMQ0KPiA+ID4gU2VudDogVHVl
c2RheSwgSmFudWFyeSAwNywgMjAxNCAyOjU4IFBNDQo+ID4gPiBUbzogV2FuZyBEb25nc2hlbmct
QjQwNTM0DQo+ID4gPiBDYzogbGludXhwcGMtZGV2QGxpc3RzLm96bGFicy5vcmc7IFhpZSBTaGFv
aHVpLUIyMTk4OTsgS3VtYXIgR2FsYQ0KPiA+ID4gU3ViamVjdDogUmU6IFtQQVRDSCAyLzJdIHBv
d2VycGMvODV4eDogaGFuZGxlIHRoZSBlTEJDIGVycm9yIGludGVycnVwdCBpZiBpdA0KPiA+ID4g
ZXhpc3QgaW4gZHRzDQo+ID4gPg0KPiA+ID4gT24gVHVlLCAyMDE0LTAxLTA3IGF0IDE0OjI3ICsw
ODAwLCBEb25nc2hlbmcgV2FuZyB3cm90ZToNCj4gPiA+ID4gRnJvbTogV2FuZyBEb25nc2hlbmcg
PGRvbmdzaGVuZy53YW5nQGZyZWVzY2FsZS5jb20+DQo+ID4gPg0KPiA+ID4gQUZBSUNUIHRoaXMg
cGF0Y2ggd2FzIG9yaWdpbmFsbHkgd3JpdHRlbiBieSBTaGFvaHVpIFhpZS4NCj4gPiA+DQo+ID4g
PiA+IE9uIFAzMDQxLCBQMTAyMCwgUDEwMjEsIFAxMDIyLCBQMTAyMyBlTEJDIGV2ZW50IGludGVy
cnVwdHMgYXJlIHJvdXRlZA0KPiA+ID4gPiB0byBJbnQ5KFAzMDQxKSAmIEludDMoUDEwMngpIHdo
aWxlIEVMQkMgZXJyb3IgaW50ZXJydXB0cyBhcmUgcm91dGVkIHRvDQo+ID4gPiA+IEludDAsIHdl
IG5lZWQgdG8gY2FsbCByZXF1ZXN0X2lycSBmb3IgZWFjaC4NCj4gPiA+DQo+ID4gPiBGb3IgcDMw
NDEgSSB0aG91Z2h0IHRoYXQgd2FzIG9ubHkgb24gZWFybHkgc2lsaWNvbiByZXZzIHRoYXQgd2Ug
ZG9uJ3QNCj4gPiA+IHN1cHBvcnQgYW55bW9yZS4NCj4gPiA+DQo+ID4gPiBBcyBmb3IgcDEwMngs
IGhhdmUgeW91IHRlc3RlZCB0aGF0IHRoaXMgaXMgYWN0dWFsbHkgd2hhdCBoYXBwZW5zPyAgSG93
DQo+ID4gPiB3b3VsZCB3ZSBkaXN0aW5ndWlzaCBlTEJDIGVycm9ycyBmcm9tIG90aGVyIGVycm9y
IHNvdXJjZXMsIGdpdmVuIHRoYXQNCj4gPiA+IHRoZXJlJ3Mgbm8gRUlTUjA/ICBEbyB3ZSBqdXN0
IGhvcGUgdGhhdCBubyBvdGhlciBlcnJvciBpbnRlcnJ1cHRzDQo+ID4gPiBoYXBwZW4/DQo+ID4g
WWVzLCBJIHRlc3RlZC4gVGhlIGludGVycnVwdCBpcyBzaGFyZCBlTEJDIGludGVycnVwdCBoYW5k
bGVyIGNvdWxkIGNoZWNrIHRoZQ0KPiBlcnJvci4NCj4gPiBUaGlzIHBhdGNoIGlzIGZpeCAibm9i
b2R5IGNhcmVkIiB0aGUgZXJyb3IgaW50ZXJydXB0LiBBZnRlciBzbGVlcCByZXN1bWUgdGhlDQo+
IGxiYw0KPiA+IHdpbGwgZ2V0IGEgY2hpcCBzZWxlY3QgZXJyb3IuDQo+IA0KPiBzL25vIG90aGVy
IGVycm9yIGludGVycnVwdHMgaGFwcGVuL25vIG90aGVyIGVycm9yIGludGVycnVwdHMgZm9yIHdo
aWNoDQo+IHdlIGRvbid0IGhhdmUgYSBoYW5kbGVyIHJlZ2lzdGVyZWQgb3Igd2hpY2ggZG9uJ3Qg
ZXZlbiBoYXZlIGFuDQo+IGFzc29jaWF0ZWQgc3RhdHVzIHJlZ2lzdGVyIGhhcHBlbi8NCj4gDQpJ
ZiB0aGUgaXAtYmxvY2sgZG9lcyBub3QgaGFuZGxlIHRoZWlyIGVycm9yIGludGVycnVwdCBpcyBh
IGlwLWJsb2NrIGlzc3VlIHRoYXQuDQpTaW5jZSB0aGUgdXNlIG9mIHRoaXMgc2hhcmVkIGludGVy
cnVwdCBtdXN0IG1haW50YWluIHRoZWlyIHN0YXR1cywgb25jZSB0aGVyZQ0KaXMgbm8gZGVhbCBz
aGFyZWQgaW50ZXJydXB0LCBpdCB3aWxsIGFmZmVjdCB0aGUgb3RoZXIgaXAtYmxvY2suDQo=
^ permalink raw reply
* [PATCH 10/12][v4] pci: fsl: support function fsl_pci_assign_primary
From: Minghuan Lian @ 2014-01-08 5:02 UTC (permalink / raw)
To: linuxppc-dev
Cc: Minghuan Lian, linux-pci, Zang Roy-R61911, Bjorn Helgaas,
Scott Wood
In-Reply-To: <1389157323-3088-1-git-send-email-Minghuan.Lian@freescale.com>
Change pci_ids to fsl_pci_ids Freescale-specific name and change
static to extern modifier for using in fsl_pci_assign_primary().
Signed-off-by: Minghuan Lian <Minghuan.Lian@freescale.com>
---
change log:
v4:
no change
v1-v3:
Derived from http://patchwork.ozlabs.org/patch/278965/
Based on upstream master.
Based on the discussion of RFC version here
http://patchwork.ozlabs.org/patch/274487/
arch/powerpc/sysdev/fsl_pci.c | 5 +++--
drivers/pci/host/pci-fsl-common.c | 4 ++--
include/linux/fsl/pci-common.h | 2 ++
3 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 38e8dca..6d9bec4 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -736,7 +736,8 @@ void fsl_pci_assign_primary(void)
of_node_put(np);
np = fsl_pci_primary;
- if (of_match_node(pci_ids, np) && of_device_is_available(np))
+ if (of_match_node(fsl_pci_ids, np) &&
+ of_device_is_available(np))
return;
}
@@ -745,7 +746,7 @@ void fsl_pci_assign_primary(void)
* designate one as primary. This can go away once
* various bugs with primary-less systems are fixed.
*/
- for_each_matching_node(np, pci_ids) {
+ for_each_matching_node(np, fsl_pci_ids) {
if (of_device_is_available(np)) {
fsl_pci_primary = np;
of_node_put(np);
diff --git a/drivers/pci/host/pci-fsl-common.c b/drivers/pci/host/pci-fsl-common.c
index e3696eb..0be7bc0 100644
--- a/drivers/pci/host/pci-fsl-common.c
+++ b/drivers/pci/host/pci-fsl-common.c
@@ -637,7 +637,7 @@ no_bridge:
return -ENODEV;
}
-static const struct of_device_id pci_ids[] = {
+const struct of_device_id fsl_pci_ids[] = {
{ .compatible = "fsl,mpc8540-pci", },
{ .compatible = "fsl,mpc8548-pcie", },
{ .compatible = "fsl,mpc8610-pci", },
@@ -728,7 +728,7 @@ static struct platform_driver fsl_pci_driver = {
.driver = {
.name = "fsl-pci",
.pm = PCI_PM_OPS,
- .of_match_table = pci_ids,
+ .of_match_table = fsl_pci_ids,
},
.probe = fsl_pci_probe,
.remove = fsl_pci_remove,
diff --git a/include/linux/fsl/pci-common.h b/include/linux/fsl/pci-common.h
index 8d33354..3247682 100644
--- a/include/linux/fsl/pci-common.h
+++ b/include/linux/fsl/pci-common.h
@@ -143,6 +143,8 @@ struct fsl_pci {
void *sys;
};
+extern const struct of_device_id fsl_pci_ids[];
+
/*
* Convert architecture specific pci controller structure to fsl_pci
* PowerPC uses structure pci_controller and ARM uses structure pci_sys_data
--
1.8.1.2
^ permalink raw reply related
* [PATCH 09/12][v4] pci: fsl: update PCI PM driver
From: Minghuan Lian @ 2014-01-08 5:02 UTC (permalink / raw)
To: linuxppc-dev
Cc: Minghuan Lian, linux-pci, Zang Roy-R61911, Bjorn Helgaas,
Scott Wood
In-Reply-To: <1389157323-3088-1-git-send-email-Minghuan.Lian@freescale.com>
The patch updates PCI PM driver, uses fsl_pci instead of
pci_controller.
Signed-off-by: Minghuan Lian <Minghuan.Lian@freescale.com>
---
change log:
v4:
no change
v1-v3:
Derived from http://patchwork.ozlabs.org/patch/278965/
Based on upstream master.
Based on the discussion of RFC version here
http://patchwork.ozlabs.org/patch/274487/
drivers/pci/host/pci-fsl-common.c | 13 +++----------
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/pci/host/pci-fsl-common.c b/drivers/pci/host/pci-fsl-common.c
index d608550..e3696eb 100644
--- a/drivers/pci/host/pci-fsl-common.c
+++ b/drivers/pci/host/pci-fsl-common.c
@@ -702,19 +702,12 @@ static int fsl_pci_remove(struct platform_device *pdev)
#ifdef CONFIG_PM
static int fsl_pci_resume(struct device *dev)
{
- struct pci_controller *hose;
- struct resource pci_rsrc;
+ struct fsl_pci *pci = dev_get_drvdata(dev);
- hose = pci_find_hose_for_OF_device(dev->of_node);
- if (!hose)
+ if (!pci)
return -ENODEV;
- if (of_address_to_resource(dev->of_node, 0, &pci_rsrc)) {
- dev_err(dev, "Get pci register base failed.");
- return -ENODEV;
- }
-
- setup_pci_atmu(hose);
+ setup_pci_atmu(pci);
return 0;
}
--
1.8.1.2
^ permalink raw reply related
* [PATCH 12/12][v4] pci: fsl: fix function check_pci_ctl_endpt_part
From: Minghuan Lian @ 2014-01-08 5:02 UTC (permalink / raw)
To: linuxppc-dev
Cc: Minghuan Lian, linux-pci, Zang Roy-R61911, Bjorn Helgaas,
Scott Wood
In-Reply-To: <1389157323-3088-1-git-send-email-Minghuan.Lian@freescale.com>
The new FSL PCI driver does not use cfg_addr of pci_controller,
we may directly access PCI CCSR using fsl_pci->regs.
Signed-off-by: Minghuan Lian <Minghuan.Lian@freescale.com>
---
change log:
v4:
no change
v1-v3:
The new patch to fix function check_pci_ctl_endpt_part
Based on upstream master.
Based on the discussion of RFC version here
http://patchwork.ozlabs.org/patch/274487/
arch/powerpc/sysdev/fsl_pci.h | 5 -----
drivers/iommu/fsl_pamu_domain.c | 6 ++++--
include/linux/fsl/pci-common.h | 1 +
3 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_pci.h b/arch/powerpc/sysdev/fsl_pci.h
index ae4dbe2..3176eb2 100644
--- a/arch/powerpc/sysdev/fsl_pci.h
+++ b/arch/powerpc/sysdev/fsl_pci.h
@@ -16,11 +16,6 @@
struct platform_device;
-
-/* FSL PCI controller BRR1 register */
-#define PCI_FSL_BRR1 0xbf8
-#define PCI_FSL_BRR1_VER 0xffff
-
extern void fsl_pcibios_fixup_bus(struct pci_bus *bus);
extern int mpc83xx_add_bridge(struct device_node *dev);
u64 fsl_pci_immrbar_base(struct pci_controller *hose);
diff --git a/drivers/iommu/fsl_pamu_domain.c b/drivers/iommu/fsl_pamu_domain.c
index c857c30..dd7bc25 100644
--- a/drivers/iommu/fsl_pamu_domain.c
+++ b/drivers/iommu/fsl_pamu_domain.c
@@ -36,6 +36,7 @@
#include <asm/pci-bridge.h>
#include <sysdev/fsl_pci.h>
+#include <linux/fsl/pci-common.h>
#include "fsl_pamu_domain.h"
#include "pci.h"
@@ -908,10 +909,11 @@ static struct iommu_group *get_device_iommu_group(struct device *dev)
static bool check_pci_ctl_endpt_part(struct pci_controller *pci_ctl)
{
u32 version;
+ struct fsl_pci *pci = fsl_arch_sys_to_pci(pci_ctl);
/* Check the PCI controller version number by readding BRR1 register */
- version = in_be32(pci_ctl->cfg_addr + (PCI_FSL_BRR1 >> 2));
- version &= PCI_FSL_BRR1_VER;
+ version = in_be32(&pci->regs->block_rev1);
+ version &= PCIE_IP_REV_MASK;
/* If PCI controller version is >= 0x204 we can partition endpoints*/
if (version >= 0x204)
return 1;
diff --git a/include/linux/fsl/pci-common.h b/include/linux/fsl/pci-common.h
index 3247682..4e4191e 100644
--- a/include/linux/fsl/pci-common.h
+++ b/include/linux/fsl/pci-common.h
@@ -18,6 +18,7 @@
#define PCIE_LTSSM_L0 0x16 /* L0 state */
#define PCIE_IP_REV_2_2 0x02080202 /* PCIE IP block version Rev2.2 */
#define PCIE_IP_REV_3_0 0x02080300 /* PCIE IP block version Rev3.0 */
+#define PCIE_IP_REV_MASK 0xffff
#define PIWAR_EN 0x80000000 /* Enable */
#define PIWAR_PF 0x20000000 /* prefetch */
#define PIWAR_TGI_LOCAL 0x00f00000 /* target - local memory */
--
1.8.1.2
^ permalink raw reply related
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