* Re: Tasks stuck in futex code (in 3.14-rc6)
From: Linus Torvalds @ 2014-03-19 16:04 UTC (permalink / raw)
To: Srikar Dronamraju
Cc: Peter Zijlstra, LKML, Davidlohr Bueso, Paul Mackerras,
Thomas Gleixner, ppc-dev, Ingo Molnar
In-Reply-To: <20140319152619.GB10406@linux.vnet.ibm.com>
On Wed, Mar 19, 2014 at 8:26 AM, Srikar Dronamraju
<srikar@linux.vnet.ibm.com> wrote:
>
> I reverted b0c29f79ecea0b6fbcefc999e70f2843ae8306db on top of v3.14-rc6 and confirmed that
> reverting the commit solved the problem.
Ok. I'll give Peter and Davidlohr a few days to perhaps find something
obvious, but I guess we'll need to revert it from 3.14 and try again
later unless some fix comes up quickly..
Oh well.
Linus
^ permalink raw reply
* [PATCH] powerpc/le: big endian arguments for ppc_rtas()
From: Greg Kurz @ 2014-03-19 16:02 UTC (permalink / raw)
To: benh, paulus; +Cc: linuxppc-dev, anton, linux-kernel
The ppc_rtas() syscall allows userspace to interact directly with RTAS.
For the moment, it assumes every thing is big endian and returns either
EINVAL or EFAULT when called in a little endian environment.
As suggested by Benjamin, to avoid bugs when userspace wants to pass
a non 32 bit value to RTAS, it is far better to stick with a simple
rationale: ppc_rtas() should be called with a big endian rtas_args
structure.
With this patch, it is now up to userspace to forge big endian arguments,
as expected by RTAS.
Signed-off-by: Greg Kurz <gkurz@linux.vnet.ibm.com>
---
Ben,
The chunk with the -1 return code check may look a bit pedantic. Please feel
free to kill it. :)
Cheers.
--
Greg
arch/powerpc/kernel/rtas.c | 22 +++++++++++++---------
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index 4cf674d..f386296 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -1013,12 +1013,13 @@ struct pseries_errorlog *get_pseries_errorlog(struct rtas_error_log *log,
return NULL;
}
+/* We assume to be passed big endian arguments */
asmlinkage int ppc_rtas(struct rtas_args __user *uargs)
{
struct rtas_args args;
unsigned long flags;
char *buff_copy, *errbuf = NULL;
- int nargs;
+ int nargs, nret, token;
int rc;
if (!capable(CAP_SYS_ADMIN))
@@ -1027,10 +1028,13 @@ asmlinkage int ppc_rtas(struct rtas_args __user *uargs)
if (copy_from_user(&args, uargs, 3 * sizeof(u32)) != 0)
return -EFAULT;
- nargs = args.nargs;
+ nargs = be32_to_cpu(args.nargs);
+ nret = be32_to_cpu(args.nret);
+ token = be32_to_cpu(args.token);
+
if (nargs > ARRAY_SIZE(args.args)
- || args.nret > ARRAY_SIZE(args.args)
- || nargs + args.nret > ARRAY_SIZE(args.args))
+ || nret > ARRAY_SIZE(args.args)
+ || nargs + nret > ARRAY_SIZE(args.args))
return -EINVAL;
/* Copy in args. */
@@ -1038,14 +1042,14 @@ asmlinkage int ppc_rtas(struct rtas_args __user *uargs)
nargs * sizeof(rtas_arg_t)) != 0)
return -EFAULT;
- if (args.token == RTAS_UNKNOWN_SERVICE)
+ if (token == RTAS_UNKNOWN_SERVICE)
return -EINVAL;
args.rets = &args.args[nargs];
- memset(args.rets, 0, args.nret * sizeof(rtas_arg_t));
+ memset(args.rets, 0, nret * sizeof(rtas_arg_t));
/* Need to handle ibm,suspend_me call specially */
- if (args.token == ibm_suspend_me_token) {
+ if (token == ibm_suspend_me_token) {
rc = rtas_ibm_suspend_me(&args);
if (rc)
return rc;
@@ -1062,7 +1066,7 @@ asmlinkage int ppc_rtas(struct rtas_args __user *uargs)
/* A -1 return code indicates that the last command couldn't
be completed due to a hardware error. */
- if (args.rets[0] == -1)
+ if (be32_to_cpu(args.rets[0]) == -1)
errbuf = __fetch_rtas_last_error(buff_copy);
unlock_rtas(flags);
@@ -1077,7 +1081,7 @@ asmlinkage int ppc_rtas(struct rtas_args __user *uargs)
/* Copy out args. */
if (copy_to_user(uargs->args + nargs,
args.args + nargs,
- args.nret * sizeof(rtas_arg_t)) != 0)
+ nret * sizeof(rtas_arg_t)) != 0)
return -EFAULT;
return 0;
^ permalink raw reply related
* Re: EDAC PCIe errors when scannning the bus
From: Johannes Thumshirn @ 2014-03-19 15:54 UTC (permalink / raw)
To: Valentin Longchamp; +Cc: linux-pci, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <532991AD.6020903@keymile.com>
On Wed, Mar 19, 2014 at 01:46:37PM +0100, Valentin Longchamp wrote:
> Hello,
>
> We have a board that is based on Freescale's P2041 SoC. The boards has 2 PCIe
> buses with this topology:
>
> PCIe 0 <---> PEX8505 switch <---> 4 network devices
> PCIE 2 <---> FPGA
>
> On 3.10.33 + a subset of the Freescale SDK 1.4 patches, both PCIe buses work
> well and we are able to use the devices on them.
>
> For each bus, I however keep getting EDAC PCIe errors at the very first stage of
> bus enumeration (please see the attached kernel log, with some debug output from
> arch/powerpc/kernel/pci-common.c and drivers/pci/probe.c) for both buses.
>
> My current "understanding" of the situation is such: since PCI_PROBE_NORMAL is
> used, pcibios_scan_phb() calls pci_scan_child_bus() that does a pci_scan_slot()
> on the bus for 32 slots. The first pci_scan_slot() is successful and it
> discovers the P2041's PCIe Controller. All the 31 other pci_scan_slot() calls
> generate an EDAC PCIe error, that is triggered by the configuration read
> transaction to read an hypothetical vendor ID of a device on the bus. This is
> relevant with that is reported by the EDAC error handler (all the 31 are the same):
>
> > PCIE error(s) detected
> > PCIE ERR_DR register: 0x00020000
>
> ICCA bit is set: Access to an illegal configuration space from
> PEX_CONFIG_ADDR/PEX_CONFIG_DATA was detected.
>
> > PCIE ERR_CAP_STAT register: 0x80000001
>
> To is set: Transaction originated from PEX_CONFIG_ADDR/PEX_CONFIG_DATA.
>
> > PCIE ERR_CAP_R0 register: 0x00000800
>
> FMT: 0b00, TYPE: 0b00100 (Config read I guess)
>
> > PCIE ERR_CAP_R1 register: 0x00000000
> > PCIE ERR_CAP_R2 register: 0x00000000
> > PCIE ERR_CAP_R3 register: 0x00000000
>
> Afterwards, pci_scan_child_bus() calls pcibios_fixup_bus (that maybe helps ?).
> From here, since the P2041's PCIe Controller is a bridge, pci_scan_bridge is
> called for this bus and all the devices are detected without having any
> configuration transaction causing EDAC errors.
>
> Has someone already observed such a behavior ? Why do these initial transaction
> generate an error ? What would be a possible fix to avoid these transaction
> errors for these 31 (unneded ?) pci_scan_slot() calls on the initial bus ?
>
> Best Regards,
>
> Valentin
Hi Valentin,
I've encountered similar problems on a P4080 based design (mine has additional
machine checks that cause an oops). I haven't solved it yet, so I unfortunately
can't offer you a fix. But I was told there are some errata workarounds that
more or less could have an impact on PCIe behavior. Could you show me the output
of U-Boot's errata command?
Especially if the workarounds for A-004580 and A-004849 are in place.
Johannes
^ permalink raw reply
* Re: Tasks stuck in futex code (in 3.14-rc6)
From: Peter Zijlstra @ 2014-03-19 15:47 UTC (permalink / raw)
To: Srikar Dronamraju
Cc: linuxppc-dev, LKML, davidlohr, paulus, tglx, torvalds, mingo
In-Reply-To: <20140319152619.GB10406@linux.vnet.ibm.com>
On Wed, Mar 19, 2014 at 08:56:19PM +0530, Srikar Dronamraju wrote:
> There are 332 tasks all stuck in futex_wait_queue_me().
> I am able to reproduce this consistently.
>
> Infact I can reproduce this if the java_constraint is either node, socket, system.
> However I am not able to reproduce if java_constraint is set to core.
What's any of that mean?
> I ran git bisect between v3.12 and v3.14-rc6 and found that
>
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b0c29f79ecea0b6fbcefc999e70f2843ae8306db
>
> commit b0c29f79ecea0b6fbcefc999e70f2843ae8306db
> Author: Davidlohr Bueso <davidlohr@hp.com>
> Date: Sun Jan 12 15:31:25 2014 -0800
>
> futexes: Avoid taking the hb->lock if there's nothing to wake up
>
> was the commit thats causing the threads to be stuck in futex.
>
> I reverted b0c29f79ecea0b6fbcefc999e70f2843ae8306db on top of v3.14-rc6 and confirmed that
> reverting the commit solved the problem.
Joy,.. let me look at that with ppc in mind.
^ permalink raw reply
* Re: [PATCH] fix dmaengine_unmap failure.
From: Dan Williams @ 2014-03-19 15:43 UTC (permalink / raw)
To: Xuelin Shi; +Cc: Vinod Koul, dmaengine@vger.kernel.org, linuxppc-dev
In-Reply-To: <30ef7093dcc247e490831a43355ec10f@BL2PR03MB147.namprd03.prod.outlook.com>
On Tue, Mar 18, 2014 at 11:39 PM, Xuelin Shi <xuelin.shi@freescale.com> wrote:
> Hi Dan,
>
> In async_mult(...) of async_raid6_recov.c, the count 3 is used to request an unmap.
> However the to_cnt and bidi_cnt are both set to 1 and from_cnt to 0.
> Then while trying to do unmap, we are getting the wrong "unmap" from a different mempool.
>
> In this patch, the mempool is associated with the unmap structure instead of computing it again.
> By this way, it is guaranteed that the unmap is the same when we get and put the unmap data.
>
> BTW: the mempool is just used to manage the struct unmap, not the pages.
>
I see, what about just storing the map_cnt at allocation time? It
could be another byte in struct dmaengine_unmap_data rather than an 8
byte pointer.
^ permalink raw reply
* Tasks stuck in futex code (in 3.14-rc6)
From: Srikar Dronamraju @ 2014-03-19 15:26 UTC (permalink / raw)
To: davidlohr; +Cc: peterz, torvalds, LKML, paulus, tglx, linuxppc-dev, mingo
Hi,
When running specjbb on a power7 numa box, I am seeing java threads
getting stuck in futex
# ps -Ao pid,tt,user,fname,tmout,f,wchan | grep futex
14808 pts/0 root java - 0 futex_wait_queue_me
14925 pts/0 root java - 0 futex_wait_queue_me
#
stack traces, I see
[ 1843.426591] Call Trace:
[ 1843.426595] [c0000017101d74d0] [0000000000000020] 0x20 (unreliable)
[ 1843.426601] [c0000017101d76a0] [c000000000014c50] .__switch_to+0x1e0/0x390
[ 1843.426607] [c0000017101d7750] [c0000000006ed314] .__schedule+0x364/0x8c0
[ 1843.426613] [c0000017101d79d0] [c000000000139c28] .futex_wait_queue_me+0xf8/0x1a0
[ 1843.426619] [c0000017101d7a60] [c00000000013afbc] .futex_wait+0x17c/0x2a0
[ 1843.426626] [c0000017101d7c10] [c00000000013cee4] .do_futex+0x254/0xd80
[ 1843.426631] [c0000017101d7d60] [c00000000013db2c] .SyS_futex+0x11c/0x1d0
[ 1843.426638] [c0000017101d7e30] [c000000000009efc] syscall_exit+0x0/0x7c
[ 1843.426643] java S 00003fffa08b16a0 0 14812 14203 0x00000080
[ 1843.426650] Call Trace:
[ 1843.426653] [c00000170c6034d0] [c000001710b09cf8] 0xc000001710b09cf8 (unreliable)
[ 1843.426660] [c00000170c6036a0] [c000000000014c50] .__switch_to+0x1e0/0x390
[ 1843.426666] [c00000170c603750] [c0000000006ed314] .__schedule+0x364/0x8c0
[ 1843.426672] [c00000170c6039d0] [c000000000139c28] .futex_wait_queue_me+0xf8/0x1a0
[ 1843.426679] [c00000170c603a60] [c00000000013afbc] .futex_wait+0x17c/0x2a0
[ 1843.453383] [c00000170c603c10] [c00000000013cee4] .do_futex+0x254/0xd80
[ 1843.453389] [c00000170c603d60] [c00000000013db2c] .SyS_futex+0x11c/0x1d0
[ 1843.453395] [c00000170c603e30] [c000000000009efc] syscall_exit+0x0/0x7c
[ 1843.453400] java S 00003fffa08b1a74 0 14813 14203 0x00000080
[ 1843.453407] Call Trace:
There are 332 tasks all stuck in futex_wait_queue_me().
I am able to reproduce this consistently.
Infact I can reproduce this if the java_constraint is either node, socket, system.
However I am not able to reproduce if java_constraint is set to core.
I ran git bisect between v3.12 and v3.14-rc6 and found that
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b0c29f79ecea0b6fbcefc999e70f2843ae8306db
commit b0c29f79ecea0b6fbcefc999e70f2843ae8306db
Author: Davidlohr Bueso <davidlohr@hp.com>
Date: Sun Jan 12 15:31:25 2014 -0800
futexes: Avoid taking the hb->lock if there's nothing to wake up
was the commit thats causing the threads to be stuck in futex.
I reverted b0c29f79ecea0b6fbcefc999e70f2843ae8306db on top of v3.14-rc6 and confirmed that
reverting the commit solved the problem.
--
Thanks and Regards
Srikar Dronamraju
^ permalink raw reply
* Re: [PATCH RFC v9 2/6] dma: mpc512x: add support for peripheral transfers
From: Vinod Koul @ 2014-03-19 14:08 UTC (permalink / raw)
To: Alexander Popov
Cc: Lars-Peter Clausen, Arnd Bergmann, Gerhard Sittig,
Andy Shevchenko, dmaengine, Dan Williams, Anatolij Gustschin,
linuxppc-dev
In-Reply-To: <CAF0T0X5egegHc3pheSbPRPuZaVaktMtdUiGPOLhcWZevH=pD=A@mail.gmail.com>
On Wed, Mar 19, 2014 at 05:26:47PM +0400, Alexander Popov wrote:
> Hello Andy
>
> 2014-03-14 13:47 GMT+04:00 Andy Shevchenko <andriy.shevchenko@linux.intel.com>:
> > On Wed, 2014-03-12 at 15:47 +0400, Alexander Popov wrote:
> >> + case DMA_SLAVE_CONFIG:
> >> + /* Constraints:
> >> + * - only transfers between a peripheral device and
> >> + * memory are supported;
> >> + * - minimal transfer chunk is 4 bytes and consequently
> >> + * source and destination addresses must be 4-byte aligned
> >> + * and transfer size must be aligned on (4 * maxburst)
> >> + * boundary;
> >> + * - during the transfer RAM address is being incremented by
> >> + * the size of minimal transfer chunk;
> >> + * - peripheral port's address is constant during the transfer.
> >> + */
> >> +
> >> + cfg = (void *)arg;
> >> +
> >> + if (!is_slave_direction(cfg->direction))
> >> + return -EINVAL;
> >
> > As far as I understand the intention you have not to use direction field
> > in the dma_slave_config. It will be removed once.
> >
> >> +
> >> + if (cfg->src_addr_width != DMA_SLAVE_BUSWIDTH_4_BYTES &&
> >> + cfg->dst_addr_width != DMA_SLAVE_BUSWIDTH_4_BYTES)
> >> + return -EINVAL;
> >> +
> >> + spin_lock_irqsave(&mchan->lock, flags);
> >> +
> >> + if (cfg->direction == DMA_DEV_TO_MEM) {
> >> + mchan->per_paddr = cfg->src_addr;
> >> + mchan->tcd_nunits = cfg->src_maxburst;
> >> + } else {
> >> + mchan->per_paddr = cfg->dst_addr;
> >> + mchan->tcd_nunits = cfg->dst_maxburst;
> >> + }
> >
> > Ditto.
>
> Excuse me, I don't understand this point.
> I have to use cfg->direction because in case of DMA_DEV_TO_MEM
> I use cfg->SRC_addr and cfg->SRC_maxburst and in case of
> DMA_MEM_TO_DEV I use cfg->DST_addr and cfg->DST_maxburst.
> Is it correct?
You store the complete config for both source and destination.
Then based on the descriptor direction you can retrive the values from channel
context and program
This way you _dont_ need to fix the direction and can use it both ways!
--
~Vinod
^ permalink raw reply
* Re: [PATCH RFC v9 2/6] dma: mpc512x: add support for peripheral transfers
From: Alexander Popov @ 2014-03-19 13:26 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Lars-Peter Clausen, Arnd Bergmann, Vinod Koul, Gerhard Sittig,
Alexander Popov, dmaengine, Dan Williams, Anatolij Gustschin,
linuxppc-dev
In-Reply-To: <1394790471.28803.247.camel@smile.fi.intel.com>
Hello Andy
2014-03-14 13:47 GMT+04:00 Andy Shevchenko <andriy.shevchenko@linux.intel.com>:
> On Wed, 2014-03-12 at 15:47 +0400, Alexander Popov wrote:
>> + case DMA_SLAVE_CONFIG:
>> + /* Constraints:
>> + * - only transfers between a peripheral device and
>> + * memory are supported;
>> + * - minimal transfer chunk is 4 bytes and consequently
>> + * source and destination addresses must be 4-byte aligned
>> + * and transfer size must be aligned on (4 * maxburst)
>> + * boundary;
>> + * - during the transfer RAM address is being incremented by
>> + * the size of minimal transfer chunk;
>> + * - peripheral port's address is constant during the transfer.
>> + */
>> +
>> + cfg = (void *)arg;
>> +
>> + if (!is_slave_direction(cfg->direction))
>> + return -EINVAL;
>
> As far as I understand the intention you have not to use direction field
> in the dma_slave_config. It will be removed once.
>
>> +
>> + if (cfg->src_addr_width != DMA_SLAVE_BUSWIDTH_4_BYTES &&
>> + cfg->dst_addr_width != DMA_SLAVE_BUSWIDTH_4_BYTES)
>> + return -EINVAL;
>> +
>> + spin_lock_irqsave(&mchan->lock, flags);
>> +
>> + if (cfg->direction == DMA_DEV_TO_MEM) {
>> + mchan->per_paddr = cfg->src_addr;
>> + mchan->tcd_nunits = cfg->src_maxburst;
>> + } else {
>> + mchan->per_paddr = cfg->dst_addr;
>> + mchan->tcd_nunits = cfg->dst_maxburst;
>> + }
>
> Ditto.
Excuse me, I don't understand this point.
I have to use cfg->direction because in case of DMA_DEV_TO_MEM
I use cfg->SRC_addr and cfg->SRC_maxburst and in case of
DMA_MEM_TO_DEV I use cfg->DST_addr and cfg->DST_maxburst.
Is it correct?
Best regards,
Alexander
^ permalink raw reply
* EDAC PCIe errors when scannning the bus
From: Valentin Longchamp @ 2014-03-19 12:46 UTC (permalink / raw)
To: linuxppc-dev@lists.ozlabs.org, linux-pci
[-- Attachment #1: Type: text/plain, Size: 2118 bytes --]
Hello,
We have a board that is based on Freescale's P2041 SoC. The boards has 2 PCIe
buses with this topology:
PCIe 0 <---> PEX8505 switch <---> 4 network devices
PCIE 2 <---> FPGA
On 3.10.33 + a subset of the Freescale SDK 1.4 patches, both PCIe buses work
well and we are able to use the devices on them.
For each bus, I however keep getting EDAC PCIe errors at the very first stage of
bus enumeration (please see the attached kernel log, with some debug output from
arch/powerpc/kernel/pci-common.c and drivers/pci/probe.c) for both buses.
My current "understanding" of the situation is such: since PCI_PROBE_NORMAL is
used, pcibios_scan_phb() calls pci_scan_child_bus() that does a pci_scan_slot()
on the bus for 32 slots. The first pci_scan_slot() is successful and it
discovers the P2041's PCIe Controller. All the 31 other pci_scan_slot() calls
generate an EDAC PCIe error, that is triggered by the configuration read
transaction to read an hypothetical vendor ID of a device on the bus. This is
relevant with that is reported by the EDAC error handler (all the 31 are the same):
> PCIE error(s) detected
> PCIE ERR_DR register: 0x00020000
ICCA bit is set: Access to an illegal configuration space from
PEX_CONFIG_ADDR/PEX_CONFIG_DATA was detected.
> PCIE ERR_CAP_STAT register: 0x80000001
To is set: Transaction originated from PEX_CONFIG_ADDR/PEX_CONFIG_DATA.
> PCIE ERR_CAP_R0 register: 0x00000800
FMT: 0b00, TYPE: 0b00100 (Config read I guess)
> PCIE ERR_CAP_R1 register: 0x00000000
> PCIE ERR_CAP_R2 register: 0x00000000
> PCIE ERR_CAP_R3 register: 0x00000000
Afterwards, pci_scan_child_bus() calls pcibios_fixup_bus (that maybe helps ?).
>From here, since the P2041's PCIe Controller is a bridge, pci_scan_bridge is
called for this bus and all the devices are detected without having any
configuration transaction causing EDAC errors.
Has someone already observed such a behavior ? Why do these initial transaction
generate an error ? What would be a possible fix to avoid these transaction
errors for these 31 (unneded ?) pci_scan_slot() calls on the initial bus ?
Best Regards,
Valentin
[-- Attachment #2: PCIe-boot-log.txt --]
[-- Type: text/plain, Size: 52105 bytes --]
U-Boot KM-v2013.10-7.0.5-00001-g29cfbaf (Mar 13 2014 - 11:40:15)
CPU0: P2041E, Version: 2.0, (0x82180120)
Core: e500mc, Version: 3.2, (0x80230032)
Clock Configuration:
CPU0:1333.333 MHz, CPU1:1333.333 MHz, CPU2:1333.333 MHz, CPU3:1333.333 MHz,
CCB:666.667 MHz,
DDR:533.333 MHz (1066.667 MT/s data rate) (Asynchronous), LBC:83.333 MHz
FMAN1: 533.333 MHz
QMAN: 333.333 MHz
PME: 333.333 MHz
L1: D-cache 32 KiB enabled
I-cache 32 KiB enabled
Reset Configuration Word (RCW):
00000000: 14600000 00000000 28200000 00000000
00000010: 148e70cf cfc02000 58000000 41000000
00000020: 00000000 00000000 00000000 f0428816
00000030: 00000000 00000000 00000000 00000000
Board: Keymile kmcoge4
I2C: ready
SPI: ready
DRAM: Initializing with SPD
Detected UDIMM
1 GiB (DDR3, 64-bit, CL=8, ECC off)
L2: 128 KiB enabled
Corenet Platform Cache: 1 MiB enabled
SERDES: bank 3 disabled
NAND: 256 MiB
SF: Detected S25FL256S_64K with page size 256 Bytes, erase size 64 KiB, total 32 MiB
PCIe FPGA config: done
PCIe1: Root Complex, x1, regs @ 0xfe200000
01:00.0 - 10b5:8505 - Bridge device
02:01.0 - 10b5:8505 - Bridge device
03:00.0 - 11ab:8000 - Network controller
02:02.0 - 10b5:8505 - Bridge device
04:00.0 - 11ab:8000 - Network controller
02:03.0 - 10b5:8505 - Bridge device
05:00.0 - 11ab:8000 - Network controller
02:04.0 - 10b5:8505 - Bridge device
06:00.0 - 11ab:8000 - Network controller
PCIe1: Bus 00 - 06
PCIe3: Root Complex, x1, regs @ 0xfe202000
08:00.0 - 10ee:000a - Memory controller
PCIe3: Bus 07 - 08
In: serial
Out: serial
Err: serial
Net: Initializing Fman
SF: Detected S25FL256S_64K with page size 256 Bytes, erase size 64 KiB, total 32 MiB
Fman1: Uploading microcode version 106.1.9
FM1@DTSEC5 [PRIME]
Warning: Bootlimit (3) exceeded. Using altbootcmd.
Hit any key to stop autoboot: 0
Using FM1@DTSEC5 device
TFTP from server 192.168.12.201; our IP address is 192.168.12.16
Filename 'kmcoge4/kmcoge4.dtb'.
Load address: 0x1f80000
Loading: ###
119.1 KiB/s
done
Bytes transferred = 30240 (7620 hex)
Using FM1@DTSEC5 device
TFTP from server 192.168.12.201; our IP address is 192.168.12.16
Filename 'kmcoge4/ecc_bch_uImage'.
Load address: 0x1000000
Loading: #################################################################
#################################################################
#################################################################
#################################################################
#############
4.4 MiB/s
done
Bytes transferred = 4002063 (3d110f hex)
WARNING: adjusting available memory to 30000000
## Booting kernel from Legacy Image at 01000000 ...
Image Name: Linux-3.10.32-kmcoge4-v0.5-00003
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 4001999 Bytes = 3.8 MiB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## Flattened Device Tree blob at 01f80000
Booting using the fdt blob at 0x1f80000
Uncompressing Kernel Image ... OK
Loading Device Tree to 03fe5000, end 03fff61f ... OK
Using Keymile kmp204x machine description
Memory CAM mapping: 256/256 Mb, residual: 510Mb
Initializing cgroup subsys cpu
Linux version 3.10.32-kmcoge4-v0.5-00003-g6885786-dirty (chlongv1@chber1-10533x.keymile.net) (gcc version 4.7.2 (GCC) ) #6 SMP Wed Mar 19 08:27:30 CET 2014
No /soc@ffe000000/qman@318000 property 'fsl,qman-fqd', using memblock_alloc(0000000000400000)
No /soc@ffe000000/qman@318000 property 'fsl,qman-pfdr', using memblock_alloc(0000000002000000)
Qman ver:0a01,01,02
No /soc@ffe000000/bman@31a000 property 'fsl,bman-fbpr', using memblock_alloc(0000000001000000)
Bman ver:0a02,01,00
Found legacy serial port 0 for /soc@ffe000000/serial@11c500
mem=ffe11c500, taddr=ffe11c500, irq=0, clk=333333330, speed=0
Found legacy serial port 1 for /soc@ffe000000/serial@11c600
mem=ffe11c600, taddr=ffe11c600, irq=0, clk=333333330, speed=0
Found legacy serial port 2 for /soc@ffe000000/serial@11d500
mem=ffe11d500, taddr=ffe11d500, irq=0, clk=333333330, speed=0
Found legacy serial port 3 for /soc@ffe000000/serial@11d600
mem=ffe11d600, taddr=ffe11d600, irq=0, clk=333333330, speed=0
CPU maps initialized for 1 thread per core
(thread shift is 0)
bootconsole [udbg0] enabled
setup_arch: bootmem
Keymile kmp204x board from Freescale Semiconductor
arch: exit
Top of RAM: 0x3fe7f000, Total RAM: 0x3fe7f000
Memory hole size: 0MB
Zone ranges:
DMA [mem 0x00000000-0x1fffffff]
Normal empty
HighMem [mem 0x20000000-0x3fe7efff]
Movable zone start for each node
Early memory node ranges
node 0: [mem 0x00000000-0x3fe7efff]
On node 0 totalpages: 261759
free_area_init_node: node 0, pgdat c07f1ec0, node_mem_map c08bf000
DMA zone: 1024 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 131072 pages, LIFO batch:31
HighMem zone: 1021 pages used for memmap
HighMem zone: 130687 pages, LIFO batch:31
MMU: Allocated 1088 bytes of context maps for 255 contexts
PERCPU: Embedded 11 pages/cpu @c10c5000 s22400 r8192 d14464 u45056
pcpu-alloc: s22400 r8192 d14464 u45056 alloc=11*4096
pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 260735
Kernel command line: root=/dev/nfs rw nfsroot=192.168.12.201:/opt/eldk/ppc_82xx debug ip=192.168.12.16:192.168.12.201:::kmcoge4:eth0:off: console=ttyS0,115200 mem=0x3fe7f000 init=/sbin/init-overlay.sh eccmode=bch phram.phram=phvar,0x3feff000,0x100000 ubi.mtd=ubi0,2048
forcing BCH ECC algorithm to: bch!
PID hash table entries: 2048 (order: 1, 8192 bytes)
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Sorting __ex_table...
High memory: 522744k
Memory: 909796k/1047036k available (7912k kernel code, 137240k reserved, 300k data, 732k bss, 324k init)
Kernel virtual memory layout:
* 0xfff5f000..0xfffff000 : fixmap
* 0xffc00000..0xffe00000 : highmem PTEs
* 0xffbfb000..0xffc00000 : early ioremap
* 0xe1000000..0xffbfb000 : vmalloc & ioremap
Hierarchical RCU implementation.
RCU debugfs-based tracing is enabled.
RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=4.
NR_IRQS:512 nr_irqs:512 16
mpic: Setting up MPIC " OpenPIC " version 1.2 at ffe040000, max 4 CPUs
mpic: ISU size: 512, shift: 9, mask: 1ff
mpic: Initializing for 512 sources
time_init: decrementer frequency = 20.833333 MHz
time_init: processor frequency = 1333.333320 MHz
clocksource: timebase mult[3000000d] shift[24] registered
clockevent: decrementer mult[5555554] shift[32] cpu[0]
Console: colour dummy device 80x25
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
Initializing cgroup subsys net_cls
mpic: requesting IPIs...
e500 family performance monitor hardware support registered
Brought up 4 CPUs
devtmpfs: initialized
NET: Registered protocol family 16
Found FSL PCI host bridge at 0x0000000ffe200000. Firmware bus number: 0->6
PCI host bridge /pcie@ffe200000 (primary) ranges:
MEM 0x0000000c00000000..0x0000000c1fffffff -> 0x00000000e0000000
IO 0x0000000ff8000000..0x0000000ff800ffff -> 0x0000000000000000
/pcie@ffe200000: PCICSRBAR @ 0xdf000000
EDAC PCI0: Giving out device to module 'MPC85xx_edac' controller 'mpc85xx_pci_err': DEV 'ffe200000.pcie' (INTERRUPT)
MPC85xx_edac acquired irq 482 for PCI Err
MPC85xx_edac PCI err registered
Found FSL PCI host bridge at 0x0000000ffe202000. Firmware bus number: 0->1
PCI host bridge /pcie@ffe202000 ranges:
MEM 0x0000000c20000000..0x0000000c3fffffff -> 0x00000000e0000000
IO 0x0000000ff8010000..0x0000000ff801ffff -> 0x0000000000000000
/pcie@ffe202000: PCICSRBAR @ 0xdf000000
EDAC PCI1: Giving out device to module 'MPC85xx_edac' controller 'mpc85xx_pci_err': DEV 'ffe202000.pcie' (INTERRUPT)
MPC85xx_edac acquired irq 480 for PCI Err
MPC85xx_edac PCI err registered
PCI: Probing PCI hardware
PCI: Scanning PHB /pcie@ffe200000
PCI: PHB IO resource = 00000000-0000ffff [100] off 0x00000000
PCI: PHB MEM resource 0 = c00000000-c1fffffff [200] off 0xb20000000
fsl-pci ffe200000.pcie: PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io 0x0000-0xffff]
pci_bus 0000:00: root bus resource [mem 0xc00000000-0xc1fffffff] (bus address [0xe0000000-0xffffffff])
pci_bus 0000:00: root bus resource [bus 00-ff]
probe mode: 0
pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to ff
pci_bus 0000:00: scanning bus
pci 0000:00:00.0: [1957:0412] type 01 class 0x0b2000
pci 0000:00:00.0: reg 10: [mem 0xdf000000-0xdfffffff]
PCI:0000:00:00.0 Resource 0 00000000df000000-00000000dfffffff [40200]
pci 0000:00:00.0: supports D1 D2
pci 0000:00:00.0: PME# supported from D0 D1 D2 D3hot D3cold
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
pci_bus 0000:00: fixups for bus
PCI: Fixup bus devices 0 (PHB)
PCI: Try to map irq for 0000:00:00.0...
Got one, spec 4 cells (0x00000010 0x00000002...) on /soc@ffe000000/pic@40000
Mapped to linux irq 482
pci 0000:00:00.0: scanning [bus 01-06] behind bridge, pass 0
pci 0000:00:00.0: scanning [bus 00-00] behind bridge, pass 1
pci_bus 0000:01: scanning bus
pci 0000:01:00.0: [10b5:8505] type 01 class 0x060400
pci 0000:01:00.0: reg 10: [mem 0xc00000000-0xc0001ffff]
PCI:0000:01:00.0 Resource 0 0000000c00000000-0000000c0001ffff [40200]
pci 0000:01:00.0: PME# supported from D0 D3hot D3cold
pci_bus 0000:01: fixups for bus
pci 0000:00:00.0: PCI bridge to [bus 01-ff]
pci 0000:00:00.0: bridge window [mem 0xc00000000-0xc1fffffff]
PCI:0000:00:00.0 Bus rsrc 1 0000000c00000000-0000000c1fffffff [200]
PCI: Fixup bus devices 1 (0000:00:00.0)
PCI: Try to map irq for 0000:01:00.0...
Got one, spec 4 cells (0x00000028 0x00000001...) on /soc@ffe000000/pic@40000
Mapped to linux irq 40
pci 0000:01:00.0: scanning [bus 02-06] behind bridge, pass 0
pci 0000:01:00.0: scanning [bus 00-00] behind bridge, pass 1
pci_bus 0000:02: scanning bus
pci 0000:02:01.0: [10b5:8505] type 01 class 0x060400
pci 0000:02:01.0: PME# supported from D0 D3hot D3cold
pci 0000:02:02.0: [10b5:8505] type 01 class 0x060400
pci 0000:02:02.0: PME# supported from D0 D3hot D3cold
pci 0000:02:03.0: [10b5:8505] type 01 class 0x060400
pci 0000:02:03.0: PME# supported from D0 D3hot D3cold
pci 0000:02:04.0: [10b5:8505] type 01 class 0x060400
pci 0000:02:04.0: PME# supported from D0 D3hot D3cold
pci_bus 0000:02: fixups for bus
pci 0000:01:00.0: PCI bridge to [bus 02-ff]
pci 0000:01:00.0: bridge window [mem 0xc00100000-0xc1fffffff]
PCI:0000:01:00.0 Bus rsrc 1 0000000c00100000-0000000c1fffffff [200]
PCI: Fixup bus devices 2 (0000:01:00.0)
PCI: Try to map irq for 0000:02:01.0...
Got one, spec 4 cells (0x00000001 0x00000001...) on /soc@ffe000000/pic@40000
Mapped to linux irq 20
PCI: Try to map irq for 0000:02:02.0...
Got one, spec 4 cells (0x00000002 0x00000001...) on /soc@ffe000000/pic@40000
Mapped to linux irq 21
PCI: Try to map irq for 0000:02:03.0...
Got one, spec 4 cells (0x00000003 0x00000002...) on /soc@ffe000000/pic@40000
Mapped to linux irq 22
PCI: Try to map irq for 0000:02:04.0...
Got one, spec 4 cells (0x00000028 0x00000001...) on /soc@ffe000000/pic@40000
Mapped to linux irq 40
pci 0000:02:01.0: scanning [bus 03-03] behind bridge, pass 0
pci 0000:02:02.0: scanning [bus 04-04] behind bridge, pass 0
pci 0000:02:03.0: scanning [bus 05-05] behind bridge, pass 0
pci 0000:02:04.0: scanning [bus 06-06] behind bridge, pass 0
pci 0000:02:01.0: scanning [bus 00-00] behind bridge, pass 1
pci_bus 0000:03: scanning bus
pci 0000:03:00.0: [11ab:8000] type 00 class 0x020000
pci 0000:03:00.0: reg 10: [mem 0xc00100000-0xc001fffff 64bit pref]
pci 0000:03:00.0: reg 18: [mem 0xc04000000-0xc07ffffff 64bit pref]
PCI:0000:03:00.0 Resource 0 0000000c00100000-0000000c001fffff [14220c]
PCI:0000:03:00.0 Resource 2 0000000c04000000-0000000c07ffffff [14220c]
pci 0000:03:00.0: supports D1 D2
pci_bus 0000:03: fixups for bus
pci 0000:02:01.0: PCI bridge to [bus 03-ff]
pci 0000:02:01.0: bridge window [mem 0xc00100000-0xc07ffffff]
PCI:0000:02:01.0 Bus rsrc 1 0000000c00100000-0000000c07ffffff [200]
PCI: Fixup bus devices 3 (0000:02:01.0)
PCI: Try to map irq for 0000:03:00.0...
Got one, spec 4 cells (0x00000001 0x00000001...) on /soc@ffe000000/pic@40000
Mapped to linux irq 20
pci_bus 0000:03: bus scan returning with max=03
pci_bus 0000:03: busn_res: [bus 03-ff] end is updated to 03
pci 0000:02:02.0: scanning [bus 00-00] behind bridge, pass 1
pci_bus 0000:04: scanning bus
pci 0000:04:00.0: [11ab:8000] type 00 class 0x020000
pci 0000:04:00.0: reg 10: [mem 0xc08000000-0xc080fffff 64bit pref]
pci 0000:04:00.0: reg 18: [mem 0xc0c000000-0xc0fffffff 64bit pref]
PCI:0000:04:00.0 Resource 0 0000000c08000000-0000000c080fffff [14220c]
PCI:0000:04:00.0 Resource 2 0000000c0c000000-0000000c0fffffff [14220c]
pci 0000:04:00.0: supports D1 D2
pci_bus 0000:04: fixups for bus
pci 0000:02:02.0: PCI bridge to [bus 04-ff]
pci 0000:02:02.0: bridge window [mem 0xc08000000-0xc0fffffff]
PCI:0000:02:02.0 Bus rsrc 1 0000000c08000000-0000000c0fffffff [200]
PCI: Fixup bus devices 4 (0000:02:02.0)
PCI: Try to map irq for 0000:04:00.0...
Got one, spec 4 cells (0x00000002 0x00000001...) on /soc@ffe000000/pic@40000
Mapped to linux irq 21
pci_bus 0000:04: bus scan returning with max=04
pci_bus 0000:04: busn_res: [bus 04-ff] end is updated to 04
pci 0000:02:03.0: scanning [bus 00-00] behind bridge, pass 1
pci_bus 0000:05: scanning bus
pci 0000:05:00.0: [11ab:8000] type 00 class 0x020000
pci 0000:05:00.0: reg 10: [mem 0xc10000000-0xc100fffff 64bit pref]
pci 0000:05:00.0: reg 18: [mem 0xc14000000-0xc17ffffff 64bit pref]
PCI:0000:05:00.0 Resource 0 0000000c10000000-0000000c100fffff [14220c]
PCI:0000:05:00.0 Resource 2 0000000c14000000-0000000c17ffffff [14220c]
pci 0000:05:00.0: supports D1 D2
pci_bus 0000:05: fixups for bus
pci 0000:02:03.0: PCI bridge to [bus 05-ff]
pci 0000:02:03.0: bridge window [mem 0xc10000000-0xc17ffffff]
PCI:0000:02:03.0 Bus rsrc 1 0000000c10000000-0000000c17ffffff [200]
PCI: Fixup bus devices 5 (0000:02:03.0)
PCI: Try to map irq for 0000:05:00.0...
Got one, spec 4 cells (0x00000003 0x00000002...) on /soc@ffe000000/pic@40000
Mapped to linux irq 22
pci_bus 0000:05: bus scan returning with max=05
pci_bus 0000:05: busn_res: [bus 05-ff] end is updated to 05
pci 0000:02:04.0: scanning [bus 00-00] behind bridge, pass 1
pci_bus 0000:06: scanning bus
pci 0000:06:00.0: [11ab:8000] type 00 class 0x020000
pci 0000:06:00.0: reg 10: [mem 0xc18000000-0xc180fffff 64bit pref]
pci 0000:06:00.0: reg 18: [mem 0xc1c000000-0xc1fffffff 64bit pref]
PCI:0000:06:00.0 Resource 0 0000000c18000000-0000000c180fffff [14220c]
PCI:0000:06:00.0 Resource 2 0000000c1c000000-0000000c1fffffff [14220c]
pci 0000:06:00.0: supports D1 D2
pci_bus 0000:06: fixups for bus
pci 0000:02:04.0: PCI bridge to [bus 06-ff]
pci 0000:02:04.0: bridge window [mem 0xc18000000-0xc1fffffff]
PCI:0000:02:04.0 Bus rsrc 1 0000000c18000000-0000000c1fffffff [200]
PCI: Fixup bus devices 6 (0000:02:04.0)
PCI: Try to map irq for 0000:06:00.0...
Got one, spec 4 cells (0x00000028 0x00000001...) on /soc@ffe000000/pic@40000
Mapped to linux irq 40
pci_bus 0000:06: bus scan returning with max=06
pci_bus 0000:06: busn_res: [bus 06-ff] end is updated to 06
pci_bus 0000:02: bus scan returning with max=06
pci_bus 0000:02: busn_res: [bus 02-ff] end is updated to 06
pci_bus 0000:01: bus scan returning with max=06
pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 06
pci_bus 0000:00: bus scan returning with max=06
pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to 06
PCI: Scanning PHB /pcie@ffe202000
PCI: PHB IO resource = 00020000-0002ffff [100] off 0x00020000
PCI: PHB MEM resource 0 = c20000000-c3fffffff [200] off 0xb40000000
fsl-pci ffe202000.pcie: PCI host bridge to bus 0001:07
pci_bus 0001:07: root bus resource [io 0x20000-0x2ffff] (bus address [0x0000-0xffff])
pci_bus 0001:07: root bus resource [mem 0xc20000000-0xc3fffffff] (bus address [0xe0000000-0xffffffff])
pci_bus 0001:07: root bus resource [bus 07-ff]
probe mode: 0
pci_bus 0001:07: busn_res: [bus 07-ff] end is updated to ff
pci_bus 0001:07: scanning bus
pci 0001:07:00.0: [1957:0412] type 01 class 0x0b2000
pci 0001:07:00.0: reg 10: [mem 0xdf000000-0xdfffffff]
PCI:0001:07:00.0 Resource 0 00000000df000000-00000000dfffffff [40200]
pci 0001:07:00.0: supports D1 D2
pci 0001:07:00.0: PME# supported from D0 D1 D2 D3hot D3cold
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
PCIE error(s) detected
PCIE ERR_DR register: 0x00020000
PCIE ERR_CAP_STAT register: 0x80000001
PCIE ERR_CAP_R0 register: 0x00000800
PCIE ERR_CAP_R1 register: 0x00000000
PCIE ERR_CAP_R2 register: 0x00000000
PCIE ERR_CAP_R3 register: 0x00000000
pci_bus 0001:07: fixups for bus
PCI: Fixup bus devices 7 (PHB)
PCI: Try to map irq for 0001:07:00.0...
Got one, spec 4 cells (0x00000010 0x00000002...) on /soc@ffe000000/pic@40000
Mapped to linux irq 480
pci 0001:07:00.0: scanning [bus 01-01] behind bridge, pass 0
pci 0001:07:00.0: Primary bus is hard wired to 0
pci 0001:07:00.0: bridge configuration invalid ([bus 01-01]), reconfiguring
pci 0001:07:00.0: scanning [bus 00-00] behind bridge, pass 1
pci_bus 0001:08: scanning bus
pci 0001:08:00.0: [10ee:000a] type 00 class 0x050000
pci 0001:08:00.0: reg 10: [mem 0xc20000000-0xc201fffff]
pci 0001:08:00.0: reg 14: [mem 0xc20200000-0xc203fffff]
PCI:0001:08:00.0 Resource 0 0000000c20000000-0000000c201fffff [40200]
PCI:0001:08:00.0 Resource 1 0000000c20200000-0000000c203fffff [40200]
pci 0001:08:00.0: supports D1 D2
pci 0001:08:00.0: PME# supported from D0 D1 D2 D3hot
pci_bus 0001:08: fixups for bus
pci 0001:07:00.0: PCI bridge to [bus 08-ff]
pci 0001:07:00.0: bridge window [mem 0xc20000000-0xc203fffff]
PCI:0001:07:00.0 Bus rsrc 1 0000000c20000000-0000000c203fffff [200]
PCI: Fixup bus devices 8 (0001:07:00.0)
PCI: Try to map irq for 0001:08:00.0...
Got one, spec 4 cells (0x0000002a 0x00000001...) on /soc@ffe000000/pic@40000
Mapped to linux irq 42
pci_bus 0001:08: bus scan returning with max=08
pci_bus 0001:08: busn_res: [bus 08-ff] end is updated to 08
pci_bus 0001:07: bus scan returning with max=08
pci_bus 0001:07: busn_res: [bus 07-ff] end is updated to 08
PCI: Allocating bus resources for 0000:00...
PCI: PHB (bus 0) bridge rsrc 4: 0000000000000000-000000000000ffff [0x100], parent c07bfa20 (PCI IO)
PCI: PHB (bus 0) bridge rsrc 5: 0000000c00000000-0000000c1fffffff [0x200], parent c07bf9f8 (PCI mem)
PCI: Allocating bus resources for 0000:01...
PCI: 0000:00:00.0 (bus 1) bridge rsrc 0: 0000000000000000-000000000000ffff [0x100], parent db14ae88 (/pcie@ffe200000)
PCI: 0000:00:00.0 (bus 1) bridge rsrc 1: 0000000c00000000-0000000c1fffffff [0x200], parent db14aeb0 (/pcie@ffe200000)
PCI: Allocating bus resources for 0000:02...
PCI: 0000:01:00.0 (bus 2) bridge rsrc 1: 0000000c00100000-0000000c1fffffff [0x200], parent db0ea698 (PCI Bus 0000:01)
PCI: Allocating bus resources for 0000:03...
PCI: 0000:02:01.0 (bus 3) bridge rsrc 1: 0000000c00100000-0000000c07ffffff [0x200], parent db0ea298 (PCI Bus 0000:02)
PCI: Allocating bus resources for 0000:04...
PCI: 0000:02:02.0 (bus 4) bridge rsrc 1: 0000000c08000000-0000000c0fffffff [0x200], parent db0ea298 (PCI Bus 0000:02)
PCI: Allocating bus resources for 0000:05...
PCI: 0000:02:03.0 (bus 5) bridge rsrc 1: 0000000c10000000-0000000c17ffffff [0x200], parent db0ea298 (PCI Bus 0000:02)
PCI: Allocating bus resources for 0000:06...
PCI: 0000:02:04.0 (bus 6) bridge rsrc 1: 0000000c18000000-0000000c1fffffff [0x200], parent db0ea298 (PCI Bus 0000:02)
PCI: Allocating bus resources for 0001:07...
PCI: PHB (bus 7) bridge rsrc 4: 0000000000020000-000000000002ffff [0x100], parent c07bfa20 (PCI IO)
PCI: PHB (bus 7) bridge rsrc 5: 0000000c20000000-0000000c3fffffff [0x200], parent c07bf9f8 (PCI mem)
PCI: Allocating bus resources for 0001:08...
PCI: 0001:07:00.0 (bus 8) bridge rsrc 0: 0000000000020000-000000000002ffff [0x100], parent db14a888 (/pcie@ffe202000)
PCI: 0001:07:00.0 (bus 8) bridge rsrc 1: 0000000c20000000-0000000c3fffffff [0x200], parent db14a8b0 (/pcie@ffe202000)
PCI: Allocating 0000:00:00.0: Resource 0: 00000000df000000..00000000dfffffff [40200]
PCI: Cannot allocate resource region 0 of device 0000:00:00.0, will remap
PCI: Allocating 0000:01:00.0: Resource 0: 0000000c00000000..0000000c0001ffff [40200]
PCI: Allocating 0000:03:00.0: Resource 0: 0000000c00100000..0000000c001fffff [14220c]
PCI: Allocating 0000:03:00.0: Resource 2: 0000000c04000000..0000000c07ffffff [14220c]
PCI: Allocating 0000:04:00.0: Resource 0: 0000000c08000000..0000000c080fffff [14220c]
PCI: Allocating 0000:04:00.0: Resource 2: 0000000c0c000000..0000000c0fffffff [14220c]
PCI: Allocating 0000:05:00.0: Resource 0: 0000000c10000000..0000000c100fffff [14220c]
PCI: Allocating 0000:05:00.0: Resource 2: 0000000c14000000..0000000c17ffffff [14220c]
PCI: Allocating 0000:06:00.0: Resource 0: 0000000c18000000..0000000c180fffff [14220c]
PCI: Allocating 0000:06:00.0: Resource 2: 0000000c1c000000..0000000c1fffffff [14220c]
PCI: Allocating 0001:07:00.0: Resource 0: 00000000df000000..00000000dfffffff [40200]
PCI: Cannot allocate resource region 0 of device 0001:07:00.0, will remap
PCI: Allocating 0001:08:00.0: Resource 0: 0000000c20000000..0000000c201fffff [40200]
PCI: Allocating 0001:08:00.0: Resource 1: 0000000c20200000..0000000c203fffff [40200]
Reserving legacy ranges for domain 0000
Candidate legacy IO: [io 0x0000-0x0fff]
PCI 0000:00 Cannot reserve Legacy IO [io 0x0000-0x0fff]
hose mem res: [mem 0xc00000000-0xc1fffffff]
Reserving legacy ranges for domain 0001
Candidate legacy IO: [io 0x20000-0x20fff]
PCI 0001:07 Cannot reserve Legacy IO [io 0x20000-0x20fff]
hose mem res: [mem 0xc20000000-0xc3fffffff]
PCI: Assigning unassigned resources...
pci 0000:02:01.0: bridge window [io 0x1000-0x0fff] to [bus 03] add_size 1000
pci 0000:02:01.0: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus 03] add_size 200000
pci 0000:02:02.0: bridge window [io 0x1000-0x0fff] to [bus 04] add_size 1000
pci 0000:02:02.0: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus 04] add_size 200000
pci 0000:02:03.0: bridge window [io 0x1000-0x0fff] to [bus 05] add_size 1000
pci 0000:02:03.0: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus 05] add_size 200000
pci 0000:02:01.0: res[7]=[io 0x1000-0x0fff] get_res_add_size add_size 1000
pci 0000:02:02.0: res[7]=[io 0x1000-0x0fff] get_res_add_size add_size 1000
pci 0000:02:03.0: res[7]=[io 0x1000-0x0fff] get_res_add_size add_size 1000
pci 0000:01:00.0: bridge window [io 0x1000-0x0fff] to [bus 02-06] add_size 3000
pci 0000:02:01.0: res[9]=[mem 0x00100000-0x000fffff 64bit pref] get_res_add_size add_size 200000
pci 0000:02:02.0: res[9]=[mem 0x00100000-0x000fffff 64bit pref] get_res_add_size add_size 200000
pci 0000:02:03.0: res[9]=[mem 0x00100000-0x000fffff 64bit pref] get_res_add_size add_size 200000
pci 0000:01:00.0: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus 02-06] add_size 600000
pci 0000:01:00.0: res[9]=[mem 0x00100000-0x000fffff 64bit pref] get_res_add_size add_size 600000
pci 0000:00:00.0: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus 01-06] add_size 600000
pci 0000:00:00.0: res[9]=[mem 0x00100000-0x000fffff 64bit pref] get_res_add_size add_size 600000
pci 0000:00:00.0: BAR 0: can't assign mem (size 0x1000000)
pci 0000:00:00.0: BAR 9: can't assign mem pref (size 0x600000)
pci 0000:00:00.0: BAR 0: can't assign mem (size 0x1000000)
pci 0000:00:00.0: BAR 9: can't assign mem pref (size 0x600000)
pci 0000:01:00.0: res[9]=[mem 0x00100000-0x000fffff 64bit pref] get_res_add_size add_size 600000
pci 0000:01:00.0: res[7]=[io 0x1000-0x0fff] get_res_add_size add_size 3000
pci 0000:01:00.0: BAR 9: can't assign mem pref (size 0x600000)
pci 0000:01:00.0: BAR 7: assigned [io 0x1000-0x3fff]
pci 0000:01:00.0: BAR 9: can't assign mem pref (size 0x600000)
pci 0000:02:01.0: res[9]=[mem 0x00100000-0x000fffff 64bit pref] get_res_add_size add_size 200000
pci 0000:02:02.0: res[9]=[mem 0x00100000-0x000fffff 64bit pref] get_res_add_size add_size 200000
pci 0000:02:03.0: res[9]=[mem 0x00100000-0x000fffff 64bit pref] get_res_add_size add_size 200000
pci 0000:02:01.0: res[7]=[io 0x1000-0x0fff] get_res_add_size add_size 1000
pci 0000:02:02.0: res[7]=[io 0x1000-0x0fff] get_res_add_size add_size 1000
pci 0000:02:03.0: res[7]=[io 0x1000-0x0fff] get_res_add_size add_size 1000
pci 0000:02:01.0: BAR 9: can't assign mem pref (size 0x200000)
pci 0000:02:02.0: BAR 9: can't assign mem pref (size 0x200000)
pci 0000:02:03.0: BAR 9: can't assign mem pref (size 0x200000)
pci 0000:02:01.0: BAR 7: assigned [io 0x1000-0x1fff]
pci 0000:02:02.0: BAR 7: assigned [io 0x2000-0x2fff]
pci 0000:02:03.0: BAR 7: assigned [io 0x3000-0x3fff]
pci 0000:02:03.0: BAR 9: can't assign mem pref (size 0x200000)
pci 0000:02:02.0: BAR 9: can't assign mem pref (size 0x200000)
pci 0000:02:01.0: BAR 9: can't assign mem pref (size 0x200000)
pci 0000:02:01.0: PCI bridge to [bus 03]
pci 0000:02:01.0: bridge window [io 0x1000-0x1fff]
pci 0000:02:01.0: bridge window [mem 0xc00100000-0xc07ffffff]
pci 0000:02:02.0: PCI bridge to [bus 04]
pci 0000:02:02.0: bridge window [io 0x2000-0x2fff]
pci 0000:02:02.0: bridge window [mem 0xc08000000-0xc0fffffff]
pci 0000:02:03.0: PCI bridge to [bus 05]
pci 0000:02:03.0: bridge window [io 0x3000-0x3fff]
pci 0000:02:03.0: bridge window [mem 0xc10000000-0xc17ffffff]
pci 0000:02:04.0: PCI bridge to [bus 06]
pci 0000:02:04.0: bridge window [mem 0xc18000000-0xc1fffffff]
pci 0000:01:00.0: PCI bridge to [bus 02-06]
pci 0000:01:00.0: bridge window [io 0x1000-0x3fff]
pci 0000:01:00.0: bridge window [mem 0xc00100000-0xc1fffffff]
pci 0000:00:00.0: PCI bridge to [bus 01-06]
pci 0000:00:00.0: bridge window [io 0x0000-0xffff]
pci 0000:00:00.0: bridge window [mem 0xc00000000-0xc1fffffff]
pci 0001:07:00.0: BAR 0: can't assign mem (size 0x1000000)
pci 0001:07:00.0: PCI bridge to [bus 08]
pci 0001:07:00.0: bridge window [io 0x20000-0x2ffff]
pci 0001:07:00.0: bridge window [mem 0xc20000000-0xc3fffffff]
Some PCI device resources are unassigned, try booting with pci=realloc
PCI: Try to map irq for 0000:00:00.0...
Got one, spec 4 cells (0x00000010 0x00000002...) on /soc@ffe000000/pic@40000
Mapped to linux irq 482
PCI: Try to map irq for 0000:01:00.0...
Got one, spec 4 cells (0x00000028 0x00000001...) on /soc@ffe000000/pic@40000
Mapped to linux irq 40
PCI: Try to map irq for 0000:02:01.0...
Got one, spec 4 cells (0x00000001 0x00000001...) on /soc@ffe000000/pic@40000
Mapped to linux irq 20
PCI: Try to map irq for 0000:02:02.0...
Got one, spec 4 cells (0x00000002 0x00000001...) on /soc@ffe000000/pic@40000
Mapped to linux irq 21
PCI: Try to map irq for 0000:02:03.0...
Got one, spec 4 cells (0x00000003 0x00000002...) on /soc@ffe000000/pic@40000
Mapped to linux irq 22
PCI: Try to map irq for 0000:02:04.0...
Got one, spec 4 cells (0x00000028 0x00000001...) on /soc@ffe000000/pic@40000
Mapped to linux irq 40
PCI: Try to map irq for 0001:07:00.0...
Got one, spec 4 cells (0x00000010 0x00000002...) on /soc@ffe000000/pic@40000
Mapped to linux irq 480
pci_bus 0000:00: resource 4 [io 0x0000-0xffff]
pci_bus 0000:00: resource 5 [mem 0xc00000000-0xc1fffffff]
pci_bus 0000:01: resource 0 [io 0x0000-0xffff]
pci_bus 0000:01: resource 1 [mem 0xc00000000-0xc1fffffff]
pci_bus 0000:02: resource 0 [io 0x1000-0x3fff]
pci_bus 0000:02: resource 1 [mem 0xc00100000-0xc1fffffff]
pci_bus 0000:03: resource 0 [io 0x1000-0x1fff]
pci_bus 0000:03: resource 1 [mem 0xc00100000-0xc07ffffff]
pci_bus 0000:04: resource 0 [io 0x2000-0x2fff]
pci_bus 0000:04: resource 1 [mem 0xc08000000-0xc0fffffff]
pci_bus 0000:05: resource 0 [io 0x3000-0x3fff]
pci_bus 0000:05: resource 1 [mem 0xc10000000-0xc17ffffff]
pci_bus 0000:06: resource 1 [mem 0xc18000000-0xc1fffffff]
pci_bus 0001:07: resource 4 [io 0x20000-0x2ffff]
pci_bus 0001:07: resource 5 [mem 0xc20000000-0xc3fffffff]
pci_bus 0001:08: resource 0 [io 0x20000-0x2ffff]
pci_bus 0001:08: resource 1 [mem 0xc20000000-0xc3fffffff]
Setting up Freescale MSI support
Setting up Freescale MSI support
Setting up Freescale MSI support
bio: create slab <bio-0> at 0
vgaarb: loaded
SCSI subsystem initialized
pps_core: LinuxPPS API ver. 1 registered
pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
PTP clock support registered
EDAC MC: Ver: 3.0.0
Bman err interrupt handler present
Bman portal initialised, cpu 0
Bman portal initialised, cpu 1
Bman portal initialised, cpu 2
Bman portal initialised, cpu 3
Bman portals initialised
Bman: BPID allocator includes range 32:32
Qman err interrupt handler present
Qman portal initialised, cpu 0
Qman portal initialised, cpu 1
Qman portal initialised, cpu 2
Qman portal initialised, cpu 3
Qman portals initialised
Qman: FQID allocator includes range 256:256
Qman: FQID allocator includes range 32768:32768
Qman: CGRID allocator includes range 0:256
Qman: pool channel allocator includes range 33:15
Switching to clocksource timebase
NET: Registered protocol family 2
TCP established hash table entries: 4096 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
TCP: reno registered
UDP hash table entries: 256 (order: 1, 8192 bytes)
UDP-Lite hash table entries: 256 (order: 1, 8192 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
PCI: CLS 32 bytes, default 64
audit: initializing netlink socket (disabled)
type=2000 audit(2.215:1): initialized
bounce pool size: 64 pages
HugeTLB registered 4 MB page size, pre-allocated 0 pages
HugeTLB registered 16 MB page size, pre-allocated 0 pages
HugeTLB registered 64 MB page size, pre-allocated 0 pages
HugeTLB registered 256 MB page size, pre-allocated 0 pages
HugeTLB registered 1 GB page size, pre-allocated 0 pages
squashfs: version 4.0 (2009/01/31) Phillip Lougher
NFS: Registering the id_resolver key type
Key type id_resolver registered
Key type id_legacy registered
NTFS driver 2.1.30 [Flags: R/O].
jffs2: version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
aufs 3.10
msgmni has been set to 884
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
serial8250.0: ttyS0 at MMIO 0xffe11c500 (irq = 36) is a 16550A
console [ttyS0] enabled, bootconsole disabled
console [ttyS0] enabled, bootconsole disabled
serial8250.0: ttyS1 at MMIO 0xffe11c600 (irq = 36) is a 16550A
serial8250.0: ttyS2 at MMIO 0xffe11d500 (irq = 37) is a 16550A
serial8250.0: ttyS3 at MMIO 0xffe11d600 (irq = 37) is a 16550A
ePAPR hypervisor byte channel driver
Generic non-volatile memory driver v1.1
brd: module loaded
loop: module loaded
st: Version 20101219, fixed bufsize 32768, s/g segs 256
phram_setup name=phvar, addr=3feff000, len=1024k
phram: phvar device: 0x100000 at 0x3feff000
ONFI param page 0 valid
ONFI flash detected
NAND device: Manufacturer ID: 0x2c, Chip ID: 0xda (Micron MT29F2G08ABAEAWP), 256MiB, page size: 2048, OOB size: 64
forcing BCH ECC algorithm to 5!
Bad block table found at page 131008, version 0x01
Bad block table found at page 130944, version 0x01
1 ofpart partitions found on MTD device ffa00000.flash
Creating 1 MTD partitions on "ffa00000.flash":
0x000000000000-0x000010000000 : "ubi0"
eLBC NAND device at 0xfffa00000, bank 0
fsl_espi ffe110000.spi: master is unqueued, this is deprecated
m25p80 spi32766.0: s25fl256s1 (32768 Kbytes)
4 ofpart partitions found on MTD device spi32766.0
Creating 4 MTD partitions on "spi32766.0":
0x000000000000-0x000000100000 : "u-boot"
0x000000100000-0x000000110000 : "env"
0x000000110000-0x000000120000 : "envred"
0x000000120000-0x000000130000 : "fman-ucode"
m25p80 spi32766.2: m25p32 (4096 Kbytes)
1 ofpart partitions found on MTD device spi32766.2
Creating 1 MTD partitions on "spi32766.2":
0x000000000000-0x000000400000 : "fpga-config"
fsl_espi ffe110000.spi: at 0xe1106000 (irq = 53)
libphy: Fixed MDIO Bus: probed
fsl-pq_mdio ffe4e1120.mdio: deferring probe since network devices not present yet
platform ffe4e1120.mdio: Driver fsl-pq_mdio requests probe deferral
libphy: Freescale XGMAC MDIO Bus: probed
FMAN(0) Fifo size settings:
- Total buffers available(512 - 256B/buffer)
- Total throughput(3Gbps)
- Max frame size(1522B)
- 1G ports TX 3(12 bufs set (min: 12))
- 1G ports RX 3(142 bufs set (min: 14))
- OH-HC ports 4(8)
- Shared extra buffers(16)
FMAN(0) open dma settings:
- Total open dma available(32)
- 1G ports TX 3(4)
- 1G ports RX 3(4)
- OH-HC ports 4(1)
- Shared extra open dma(4)
FMAN(0) Tnums settings:
- Total Tnums available(128)
- 1G ports TX 3(19)
- 1G ports RX 3(20)
- OH-HC ports 4(2)
- Shared extra tnums(3)
Freescale FM module (Mar 18 2014:15:06:49), FMD API version 21.1.0
Freescale FM Ports module (Mar 18 2014:15:06:50)
dpaa_debugfs: FSL DPAA Ethernet debugfs entries ()
fsl_mac: mac.c:417:mac_load() fsl_mac: FSL FMan MAC API based driver ()
fsl_mac ffe4e0000.ethernet: FMan dTSEC version: 0x08240101
fsl_mac ffe4e0000.ethernet: FMan MAC address: 00:11:22:33:44:55
fsl_mac ffe4e2000.ethernet: FMan dTSEC version: 0x08240101
fsl_mac ffe4e2000.ethernet: FMan MAC address: 00:11:22:33:44:55
fsl_mac ffe4e8000.ethernet: FMan dTSEC version: 0x08240101
fsl_mac ffe4e8000.ethernet: FMan MAC address: 00:e0:df:a3:45:a1
fsl_dpa: dpaa_eth.c:4320:dpa_load() fsl_dpa: FSL DPAA Ethernet driver ()
fsl_dpa ethernet.16: Using private BM buffer pools
fsl_dpa: dpaa_eth.c:3715:dpa_rx_fq_init() Using dynamic RX QM frame queues
fsl_dpa: dpaa_eth.c:3739:dpa_tx_fq_init() Using dynamic TX QM frame queues
fsl_dpa ethernet.17: Using private BM buffer pools
fsl_dpa: dpaa_eth.c:3715:dpa_rx_fq_init() Using dynamic RX QM frame queues
fsl_dpa: dpaa_eth.c:3739:dpa_tx_fq_init() Using dynamic TX QM frame queues
fsl_dpa ethernet.18: Using private BM buffer pools
fsl_dpa: dpaa_eth.c:3715:dpa_rx_fq_init() Using dynamic RX QM frame queues
fsl_dpa: dpaa_eth.c:3739:dpa_tx_fq_init() Using dynamic TX QM frame queues
fsl_oh: offline_port.c:439:oh_port_load() fsl_oh: FSL FMan Offline Parsing port driver ()
i2c /dev entries driver
mpc-i2c ffe118000.i2c: timeout 1000000 us
mpc-i2c ffe118000.i2c: SCL GPIO pin not yet available, deferring probing
mpc-i2c ffe118000.i2c: failed to request GPIOs
platform ffe118000.i2c: Driver mpc-i2c requests probe deferral
Freescale(R) MPC85xx EDAC driver, (C) 2006 Montavista Software
mpc85xx_mc_err_probe: No ECC DIMMs discovered
caam ffe300000.crypto: device ID = 0x0a12010000000000 (Era 3)
caam ffe300000.crypto: job rings = 4, qi = 1
caam ffe300000.crypto: fsl,sec-v4.2 algorithms registered in /proc/crypto
platform ffe301000.jr: registering rng-caam
qriox ffb000000.bec: GPIO ctlr registered
qriox ffb000000.bec: GPIO export registered
qriox ffb000000.bec: IRQ ctlr registered
qriox ffb000000.bec: QRIO1 Rev. 0x13 registered @ 0xffb000000..0xffb00007f, BUF_ENA=ON
qriox ffb000000.bec: Populate qriox child nodes...
bc_get_addr: bc_get_addr no node, trying compatible node
created "/proc/driver/bootcount"
bootcount driver registered.
bfticu: attaching bftic4, private db461940
bfticu: physical resources [mem 0xfe0000000-0xfe00000ff]
bfticu fe0000000.bftic4: Chip id correct 0x65
bfticu fe0000000.bftic4: Set up succesfully 48 bfticu_irqs
bfticu:init
km_event_probe: probing events for qrio_events.12
km_event_handler: setup OK.
km_event_probe: probing events for fe0000000.bftic4_events
km_event_handler: setup OK.
u32 classifier
Performance counters on
ipip: IPv4 over IPv4 tunneling driver
TCP: cubic registered
Initializing XFRM netlink socket
NET: Registered protocol family 10
sit: IPv6 over IPv4 tunneling driver
NET: Registered protocol family 17
NET: Registered protocol family 15
tipc: Activated (version 2.0.0)
NET: Registered protocol family 30
tipc: Started in single node mode
Key type dns_resolver registered
libphy: Freescale PowerQUICC MII Bus: probed
mpc-i2c ffe118000.i2c: timeout 1000000 us
mpc-i2c ffe118000.i2c: requested GPIO 180 for SCL
mpc-i2c ffe118000.i2c: requested GPIO 181 for SDA
UBI: attaching mtd1 to ubi0
UBI: scanning is finished
UBI: attached mtd1 (name "ubi0", size 256 MiB) to ubi0
UBI: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
UBI: min./max. I/O unit sizes: 2048/2048, sub-page size 512
UBI: VID header offset: 2048 (aligned 2048), data offset: 4096
UBI: good PEBs: 2044, bad PEBs: 4, corrupted PEBs: 0
UBI: user volume: 11, internal volumes: 1, max. volumes count: 128
UBI: max/mean erase counter: 2/0, WL threshold: 4096, image sequence number: 0
UBI: available PEBs: 1017, total reserved PEBs: 1027, PEBs reserved for bad PEB handling: 36
UBI: background thread "ubi_bgt0d" started, PID 110
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
IP-Config: Guessing netmask 255.255.255.0
IP-Config: Complete:
device=eth0, hwaddr=00:e0:df:a3:45:a1, ipaddr=192.168.12.16, mask=255.255.255.0, gw=255.255.255.255
host=kmcoge4, domain=, nis-domain=(none)
bootserver=192.168.12.201, rootserver=192.168.12.201, rootpath=
VFS: Mounted root (nfs filesystem) on device 0:17.
devtmpfs: mounted
Freeing unused kernel memory: 324K (c0769000 - c07ba000)
6.677 INFO init-overlay done in 0.26
8.300 INFO sysinit done in 1.61
root@kmcoge4:~#
^ permalink raw reply
* Re: [PATCH v2 2/6] powernv:cpufreq: Create a powernv_cpu_to_core_mask() helper.
From: Gautham R Shenoy @ 2014-03-19 11:02 UTC (permalink / raw)
To: Srivatsa S. Bhat; +Cc: linuxppc-dev, Gautham R. Shenoy
In-Reply-To: <53293AA8.2040609@linux.vnet.ibm.com>
On Wed, Mar 19, 2014 at 12:05:20PM +0530, Srivatsa S. Bhat wrote:
> On 03/19/2014 05:07 AM, Benjamin Herrenschmidt wrote:
> > On Mon, 2014-03-10 at 16:40 +0530, Gautham R. Shenoy wrote:
> >> From: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
> >>
> >> Create a helper method that computes the cpumask corresponding to the
> >> thread-siblings of a cpu. Use this for initializing the policy->cpus
> >> mask for a given cpu.
> >>
> >> (Original code written by Srivatsa S. Bhat. Gautham moved this to a
> >> helper function!)
> >
> > How does that differ from the existing entry in the sibling map which
> > you can obtain with the helper cpu_sibling_mask() ? (You probably want
> > to *copy* the mask of course but I don't see the need of re-creating
> > one from scratch).
> >
>
> The intent here was to have a sibling mask that is invariant of CPU
> hotplug. cpu_sibling_mask is updated on every hotplug operation, and this
> would break cpufreq, since policy->cpus has to be hotplug invariant.
>
> This should have been noted in the changelog of patch 1 as well as this
> patch. (The earlier (internal) versions of this patchset had the
> description in the changelogs, but somehow it got dropped accidentally).
> I'll work with Gautham and ensure that we have this important info
> included in the changelog. Thanks for pointing it out!
I reused that part of the code because I was unaware of
cpu_sibling_mask()!
For implementing powernv_cpufreq_get(), cpu_sibling_mask() suffices
since we are using this mask as a parameter to
smp_call_function_any(), and hence are concerned only about the online
siblings.
I shall fix the changelog to reflect Srivatsa's reason for having a
mask that does not vary with cpu-hotplug.
>
> Regards,
> Srivatsa S. Bhat
>
>
> > Also, this should have been CCed to the cpufreq mailing list and maybe
> > the relevant maintainer too.
Ok. Will do it in the subsequent version.
Thanks for the review!
> >
> > Cheers,
> > Ben.
> >
> >> Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
> >> Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
> >> ---
> >> drivers/cpufreq/powernv-cpufreq.c | 24 ++++++++++++++++++------
> >> 1 file changed, 18 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/drivers/cpufreq/powernv-cpufreq.c b/drivers/cpufreq/powernv-cpufreq.c
> >> index ab1551f..4cad727 100644
> >> --- a/drivers/cpufreq/powernv-cpufreq.c
> >> +++ b/drivers/cpufreq/powernv-cpufreq.c
> >> @@ -115,6 +115,23 @@ static struct freq_attr *powernv_cpu_freq_attr[] = {
> >>
> >> /* Helper routines */
> >>
> >> +/**
> >> + * Sets the bits corresponding to the thread-siblings of cpu in its core
> >> + * in 'cpus'.
> >> + */
> >> +static void powernv_cpu_to_core_mask(unsigned int cpu, cpumask_var_t cpus)
> >> +{
> >> + int base, i;
> >> +
> >> + base = cpu_first_thread_sibling(cpu);
> >> +
> >> + for (i = 0; i < threads_per_core; i++) {
> >> + cpumask_set_cpu(base + i, cpus);
> >> + }
> >> +
> >> + return;
> >> +}
> >> +
> >> /* Access helpers to power mgt SPR */
> >>
> >> static inline unsigned long get_pmspr(unsigned long sprn)
> >> @@ -180,13 +197,8 @@ static int powernv_set_freq(cpumask_var_t cpus, unsigned int new_index)
> >>
> >> static int powernv_cpufreq_cpu_init(struct cpufreq_policy *policy)
> >> {
> >> - int base, i;
> >> -
> >> #ifdef CONFIG_SMP
> >> - base = cpu_first_thread_sibling(policy->cpu);
> >> -
> >> - for (i = 0; i < threads_per_core; i++)
> >> - cpumask_set_cpu(base + i, policy->cpus);
> >> + powernv_cpu_to_core_mask(policy->cpu, policy->cpus);
> >> #endif
> >> policy->cpuinfo.transition_latency = 25000;
> >>
> >
> >
>
^ permalink raw reply
* [PATCH] fix wrong usage of dmaengine_unmap_put in async_xxx
From: xuelin.shi @ 2014-03-19 8:18 UTC (permalink / raw)
To: dan.j.williams, vinod.koul; +Cc: dmaengine, Xuelin Shi, linuxppc-dev
From: Xuelin Shi <xuelin.shi@freescale.com>
dmaengine_unmap_put does below two things:
a) unmap pages for srcs and dests
b) free unmap struct
The unmap struct data is generated but only initialized while
other some dma contions are met, like dma alignment etc.
If the unmap data is not initialized, call dmaengine_unmap_put
will unmap some random data in unmap->addr[...]
Also call dmaengine_get_unmap_data immediatally after generating tx
is not correct. Maybe the tx has not been finished by DMA hardware
yet but the srcs and dests are dma unmapped.
This patch fixed above two issues by:
a) only generates unmap struct data when other dma conditions are met.
b) eliminates dmaengine_unmap_put when tx is generated because tx knowes
the best time to unmap it (in interrupt processing).
Signed-off-by: Xuelin Shi <xuelin.shi@freescale.com>
---
crypto/async_tx/async_memcpy.c | 38 ++++----
crypto/async_tx/async_pq.c | 191 ++++++++++++++++++++++-------------------
crypto/async_tx/async_xor.c | 100 +++++++++++----------
3 files changed, 175 insertions(+), 154 deletions(-)
diff --git a/crypto/async_tx/async_memcpy.c b/crypto/async_tx/async_memcpy.c
index f8c0b8d..578d1bd 100644
--- a/crypto/async_tx/async_memcpy.c
+++ b/crypto/async_tx/async_memcpy.c
@@ -52,10 +52,7 @@ async_memcpy(struct page *dest, struct page *src, unsigned int dest_offset,
struct dma_async_tx_descriptor *tx = NULL;
struct dmaengine_unmap_data *unmap = NULL;
- if (device)
- unmap = dmaengine_get_unmap_data(device->dev, 2, GFP_NOIO);
-
- if (unmap && is_dma_copy_aligned(device, src_offset, dest_offset, len)) {
+ if (device && is_dma_copy_aligned(device, src_offset, dest_offset, len)) {
unsigned long dma_prep_flags = 0;
if (submit->cb_fn)
@@ -63,17 +60,24 @@ async_memcpy(struct page *dest, struct page *src, unsigned int dest_offset,
if (submit->flags & ASYNC_TX_FENCE)
dma_prep_flags |= DMA_PREP_FENCE;
- unmap->to_cnt = 1;
- unmap->addr[0] = dma_map_page(device->dev, src, src_offset, len,
- DMA_TO_DEVICE);
- unmap->from_cnt = 1;
- unmap->addr[1] = dma_map_page(device->dev, dest, dest_offset, len,
- DMA_FROM_DEVICE);
- unmap->len = len;
-
- tx = device->device_prep_dma_memcpy(chan, unmap->addr[1],
- unmap->addr[0], len,
- dma_prep_flags);
+ unmap = dmaengine_get_unmap_data(device->dev, 2, GFP_NOIO);
+ if (unmap) {
+ unmap->to_cnt = 1;
+ unmap->addr[0] = dma_map_page(device->dev, src,
+ src_offset, len,
+ DMA_TO_DEVICE);
+ unmap->from_cnt = 1;
+ unmap->addr[1] = dma_map_page(device->dev, dest,
+ dest_offset, len,
+ DMA_FROM_DEVICE);
+ unmap->len = len;
+
+ tx = device->device_prep_dma_memcpy(chan,
+ unmap->addr[1],
+ unmap->addr[0],
+ len,
+ dma_prep_flags);
+ }
}
if (tx) {
@@ -85,6 +89,8 @@ async_memcpy(struct page *dest, struct page *src, unsigned int dest_offset,
void *dest_buf, *src_buf;
pr_debug("%s: (sync) len: %zu\n", __func__, len);
+ dmaengine_unmap_put(unmap);
+
/* wait for any prerequisite operations */
async_tx_quiesce(&submit->depend_tx);
@@ -99,8 +105,6 @@ async_memcpy(struct page *dest, struct page *src, unsigned int dest_offset,
async_tx_sync_epilog(submit);
}
- dmaengine_unmap_put(unmap);
-
return tx;
}
EXPORT_SYMBOL_GPL(async_memcpy);
diff --git a/crypto/async_tx/async_pq.c b/crypto/async_tx/async_pq.c
index d05327c..a25343c 100644
--- a/crypto/async_tx/async_pq.c
+++ b/crypto/async_tx/async_pq.c
@@ -175,10 +175,7 @@ async_gen_syndrome(struct page **blocks, unsigned int offset, int disks,
BUG_ON(disks > 255 || !(P(blocks, disks) || Q(blocks, disks)));
- if (device)
- unmap = dmaengine_get_unmap_data(device->dev, disks, GFP_NOIO);
-
- if (unmap &&
+ if (device &&
(src_cnt <= dma_maxpq(device, 0) ||
dma_maxpq(device, DMA_PREP_CONTINUE) > 0) &&
is_dma_pq_aligned(device, offset, 0, len)) {
@@ -194,42 +191,52 @@ async_gen_syndrome(struct page **blocks, unsigned int offset, int disks,
/* convert source addresses being careful to collapse 'empty'
* sources and update the coefficients accordingly
*/
- unmap->len = len;
- for (i = 0, j = 0; i < src_cnt; i++) {
- if (blocks[i] == NULL)
- continue;
- unmap->addr[j] = dma_map_page(device->dev, blocks[i], offset,
- len, DMA_TO_DEVICE);
- coefs[j] = raid6_gfexp[i];
- unmap->to_cnt++;
- j++;
- }
+ unmap = dmaengine_get_unmap_data(device->dev, disks, GFP_NOIO);
+ if (unmap) {
+ unmap->len = len;
+ for (i = 0, j = 0; i < src_cnt; i++) {
+ if (blocks[i] == NULL)
+ continue;
+ unmap->addr[j] = dma_map_page(device->dev,
+ blocks[i],
+ offset,
+ len,
+ DMA_TO_DEVICE);
+ coefs[j] = raid6_gfexp[i];
+ unmap->to_cnt++;
+ j++;
+ }
- /*
- * DMAs use destinations as sources,
- * so use BIDIRECTIONAL mapping
- */
- unmap->bidi_cnt++;
- if (P(blocks, disks))
- unmap->addr[j++] = dma_map_page(device->dev, P(blocks, disks),
- offset, len, DMA_BIDIRECTIONAL);
- else {
- unmap->addr[j++] = 0;
- dma_flags |= DMA_PREP_PQ_DISABLE_P;
- }
+ /*
+ * DMAs use destinations as sources,
+ * so use BIDIRECTIONAL mapping
+ */
+ unmap->bidi_cnt++;
+ if (P(blocks, disks))
+ unmap->addr[j++] = dma_map_page(device->dev,
+ P(blocks, disks),
+ offset, len,
+ DMA_BIDIRECTIONAL);
+ else {
+ unmap->addr[j++] = 0;
+ dma_flags |= DMA_PREP_PQ_DISABLE_P;
+ }
- unmap->bidi_cnt++;
- if (Q(blocks, disks))
- unmap->addr[j++] = dma_map_page(device->dev, Q(blocks, disks),
- offset, len, DMA_BIDIRECTIONAL);
- else {
- unmap->addr[j++] = 0;
- dma_flags |= DMA_PREP_PQ_DISABLE_Q;
- }
+ unmap->bidi_cnt++;
+ if (Q(blocks, disks))
+ unmap->addr[j++] = dma_map_page(device->dev,
+ Q(blocks, disks),
+ offset, len,
+ DMA_BIDIRECTIONAL);
+ else {
+ unmap->addr[j++] = 0;
+ dma_flags |= DMA_PREP_PQ_DISABLE_Q;
+ }
- tx = do_async_gen_syndrome(chan, coefs, j, unmap, dma_flags, submit);
- dmaengine_unmap_put(unmap);
- return tx;
+ tx = do_async_gen_syndrome(chan, coefs, j, unmap,
+ dma_flags, submit);
+ return tx;
+ }
}
dmaengine_unmap_put(unmap);
@@ -293,10 +300,7 @@ async_syndrome_val(struct page **blocks, unsigned int offset, int disks,
BUG_ON(disks < 4);
- if (device)
- unmap = dmaengine_get_unmap_data(device->dev, disks, GFP_NOIO);
-
- if (unmap && disks <= dma_maxpq(device, 0) &&
+ if (device && disks <= dma_maxpq(device, 0) &&
is_dma_pq_aligned(device, offset, 0, len)) {
struct device *dev = device->dev;
dma_addr_t pq[2];
@@ -305,58 +309,63 @@ async_syndrome_val(struct page **blocks, unsigned int offset, int disks,
pr_debug("%s: (async) disks: %d len: %zu\n",
__func__, disks, len);
- unmap->len = len;
- for (i = 0; i < disks-2; i++)
- if (likely(blocks[i])) {
- unmap->addr[j] = dma_map_page(dev, blocks[i],
- offset, len,
- DMA_TO_DEVICE);
- coefs[j] = raid6_gfexp[i];
+ unmap = dmaengine_get_unmap_data(device->dev, disks, GFP_NOIO);
+ if (unmap) {
+ unmap->len = len;
+ for (i = 0; i < disks-2; i++)
+ if (likely(blocks[i])) {
+ unmap->addr[j] = dma_map_page(dev,
+ blocks[i],
+ offset,
+ len,
+ DMA_TO_DEVICE);
+ coefs[j] = raid6_gfexp[i];
+ unmap->to_cnt++;
+ src_cnt++;
+ j++;
+ }
+
+ if (!P(blocks, disks)) {
+ pq[0] = 0;
+ dma_flags |= DMA_PREP_PQ_DISABLE_P;
+ } else {
+ pq[0] = dma_map_page(dev, P(blocks, disks),
+ offset, len,
+ DMA_TO_DEVICE);
+ unmap->addr[j++] = pq[0];
+ unmap->to_cnt++;
+ }
+ if (!Q(blocks, disks)) {
+ pq[1] = 0;
+ dma_flags |= DMA_PREP_PQ_DISABLE_Q;
+ } else {
+ pq[1] = dma_map_page(dev, Q(blocks, disks),
+ offset, len,
+ DMA_TO_DEVICE);
+ unmap->addr[j++] = pq[1];
unmap->to_cnt++;
- src_cnt++;
- j++;
}
- if (!P(blocks, disks)) {
- pq[0] = 0;
- dma_flags |= DMA_PREP_PQ_DISABLE_P;
- } else {
- pq[0] = dma_map_page(dev, P(blocks, disks),
- offset, len,
- DMA_TO_DEVICE);
- unmap->addr[j++] = pq[0];
- unmap->to_cnt++;
- }
- if (!Q(blocks, disks)) {
- pq[1] = 0;
- dma_flags |= DMA_PREP_PQ_DISABLE_Q;
- } else {
- pq[1] = dma_map_page(dev, Q(blocks, disks),
- offset, len,
- DMA_TO_DEVICE);
- unmap->addr[j++] = pq[1];
- unmap->to_cnt++;
- }
-
- if (submit->flags & ASYNC_TX_FENCE)
- dma_flags |= DMA_PREP_FENCE;
- for (;;) {
- tx = device->device_prep_dma_pq_val(chan, pq,
- unmap->addr,
- src_cnt,
- coefs,
- len, pqres,
- dma_flags);
- if (likely(tx))
- break;
- async_tx_quiesce(&submit->depend_tx);
- dma_async_issue_pending(chan);
- }
+ if (submit->flags & ASYNC_TX_FENCE)
+ dma_flags |= DMA_PREP_FENCE;
+ for (;;) {
+ tx = device->device_prep_dma_pq_val(chan, pq,
+ unmap->addr,
+ src_cnt,
+ coefs,
+ len, pqres,
+ dma_flags);
+ if (likely(tx))
+ break;
+ async_tx_quiesce(&submit->depend_tx);
+ dma_async_issue_pending(chan);
+ }
- dma_set_unmap(tx, unmap);
- async_tx_submit(chan, tx, submit);
+ dma_set_unmap(tx, unmap);
+ async_tx_submit(chan, tx, submit);
- return tx;
+ return tx;
+ }
} else {
struct page *p_src = P(blocks, disks);
struct page *q_src = Q(blocks, disks);
@@ -366,6 +375,8 @@ async_syndrome_val(struct page **blocks, unsigned int offset, int disks,
void *cb_param_orig = submit->cb_param;
void *p, *q, *s;
+ dmaengine_unmap_put(unmap);
+
pr_debug("%s: (sync) disks: %d len: %zu\n",
__func__, disks, len);
@@ -411,9 +422,9 @@ async_syndrome_val(struct page **blocks, unsigned int offset, int disks,
submit->cb_param = cb_param_orig;
submit->flags = flags_orig;
async_tx_sync_epilog(submit);
-
- return NULL;
}
+
+ return NULL;
}
EXPORT_SYMBOL_GPL(async_syndrome_val);
diff --git a/crypto/async_tx/async_xor.c b/crypto/async_tx/async_xor.c
index 3c562f5..d540ac6 100644
--- a/crypto/async_tx/async_xor.c
+++ b/crypto/async_tx/async_xor.c
@@ -182,33 +182,36 @@ async_xor(struct page *dest, struct page **src_list, unsigned int offset,
BUG_ON(src_cnt <= 1);
- if (device)
- unmap = dmaengine_get_unmap_data(device->dev, src_cnt+1, GFP_NOIO);
-
- if (unmap && is_dma_xor_aligned(device, offset, 0, len)) {
+ if (device && is_dma_xor_aligned(device, offset, 0, len)) {
struct dma_async_tx_descriptor *tx;
int i, j;
/* run the xor asynchronously */
pr_debug("%s (async): len: %zu\n", __func__, len);
- unmap->len = len;
- for (i = 0, j = 0; i < src_cnt; i++) {
- if (!src_list[i])
- continue;
- unmap->to_cnt++;
- unmap->addr[j++] = dma_map_page(device->dev, src_list[i],
- offset, len, DMA_TO_DEVICE);
- }
+ unmap = dmaengine_get_unmap_data(device->dev, src_cnt + 1,
+ GFP_NOIO);
+ if (unmap) {
+ unmap->len = len;
+ for (i = 0, j = 0; i < src_cnt; i++) {
+ if (!src_list[i])
+ continue;
+ unmap->to_cnt++;
+ unmap->addr[j++] = dma_map_page(device->dev,
+ src_list[i],
+ offset, len,
+ DMA_TO_DEVICE);
+ }
- /* map it bidirectional as it may be re-used as a source */
- unmap->addr[j] = dma_map_page(device->dev, dest, offset, len,
- DMA_BIDIRECTIONAL);
- unmap->bidi_cnt = 1;
+ /* map it bidirectional as it may be re-used as a source */
+ unmap->addr[j] = dma_map_page(device->dev, dest, offset,
+ len, DMA_BIDIRECTIONAL);
+ unmap->bidi_cnt = 1;
- tx = do_async_xor(chan, unmap, submit);
- dmaengine_unmap_put(unmap);
- return tx;
+ tx = do_async_xor(chan, unmap, submit);
+ dmaengine_unmap_put(unmap);
+ return tx;
+ }
} else {
dmaengine_unmap_put(unmap);
/* run the xor synchronously */
@@ -228,9 +231,9 @@ async_xor(struct page *dest, struct page **src_list, unsigned int offset,
async_tx_quiesce(&submit->depend_tx);
do_sync_xor(dest, src_list, offset, src_cnt, len, submit);
-
- return NULL;
}
+
+ return NULL;
}
EXPORT_SYMBOL_GPL(async_xor);
@@ -278,10 +281,7 @@ async_xor_val(struct page *dest, struct page **src_list, unsigned int offset,
BUG_ON(src_cnt <= 1);
- if (device)
- unmap = dmaengine_get_unmap_data(device->dev, src_cnt, GFP_NOIO);
-
- if (unmap && src_cnt <= device->max_xor &&
+ if (device && src_cnt <= device->max_xor &&
is_dma_xor_aligned(device, offset, 0, len)) {
unsigned long dma_prep_flags = 0;
int i;
@@ -293,31 +293,39 @@ async_xor_val(struct page *dest, struct page **src_list, unsigned int offset,
if (submit->flags & ASYNC_TX_FENCE)
dma_prep_flags |= DMA_PREP_FENCE;
- for (i = 0; i < src_cnt; i++) {
- unmap->addr[i] = dma_map_page(device->dev, src_list[i],
- offset, len, DMA_TO_DEVICE);
- unmap->to_cnt++;
- }
- unmap->len = len;
-
- tx = device->device_prep_dma_xor_val(chan, unmap->addr, src_cnt,
- len, result,
- dma_prep_flags);
- if (unlikely(!tx)) {
- async_tx_quiesce(&submit->depend_tx);
-
- while (!tx) {
- dma_async_issue_pending(chan);
- tx = device->device_prep_dma_xor_val(chan,
- unmap->addr, src_cnt, len, result,
- dma_prep_flags);
+ unmap = dmaengine_get_unmap_data(device->dev, src_cnt,
+ GFP_NOIO);
+ if (unmap) {
+ for (i = 0; i < src_cnt; i++) {
+ unmap->addr[i] = dma_map_page(device->dev,
+ src_list[i],
+ offset, len,
+ DMA_TO_DEVICE);
+ unmap->to_cnt++;
+ }
+ unmap->len = len;
+
+ tx = device->device_prep_dma_xor_val(chan, unmap->addr,
+ src_cnt,
+ len, result,
+ dma_prep_flags);
+ if (unlikely(!tx)) {
+ async_tx_quiesce(&submit->depend_tx);
+
+ while (!tx) {
+ dma_async_issue_pending(chan);
+ tx = device->device_prep_dma_xor_val(chan,
+ unmap->addr, src_cnt, len,
+ result, dma_prep_flags);
+ }
}
+ dma_set_unmap(tx, unmap);
+ async_tx_submit(chan, tx, submit);
}
- dma_set_unmap(tx, unmap);
- async_tx_submit(chan, tx, submit);
} else {
enum async_tx_flags flags_orig = submit->flags;
+ dmaengine_unmap_put(unmap);
pr_debug("%s: (sync) len: %zu\n", __func__, len);
WARN_ONCE(device && src_cnt <= device->max_xor,
"%s: no space for dma address conversion\n",
@@ -335,8 +343,6 @@ async_xor_val(struct page *dest, struct page **src_list, unsigned int offset,
async_tx_sync_epilog(submit);
submit->flags = flags_orig;
}
- dmaengine_unmap_put(unmap);
-
return tx;
}
EXPORT_SYMBOL_GPL(async_xor_val);
--
1.8.3.2
^ permalink raw reply related
* RE: [PATCH] fix dmaengine_unmap failure.
From: Xuelin Shi @ 2014-03-19 6:39 UTC (permalink / raw)
To: Dan Williams; +Cc: Vinod Koul, dmaengine@vger.kernel.org, linuxppc-dev
In-Reply-To: <CAPcyv4gs-jos5TvfDbsaXTNebQf8VjJvbdjmjsbGZLZwZKi34g@mail.gmail.com>
SGkgRGFuLA0KDQpJbiBhc3luY19tdWx0KC4uLikgb2YgYXN5bmNfcmFpZDZfcmVjb3YuYywgdGhl
IGNvdW50IDMgaXMgdXNlZCB0byByZXF1ZXN0IGFuIHVubWFwLg0KSG93ZXZlciB0aGUgdG9fY250
IGFuZCBiaWRpX2NudCBhcmUgYm90aCBzZXQgdG8gMSBhbmQgZnJvbV9jbnQgdG8gMC4NClRoZW4g
d2hpbGUgdHJ5aW5nIHRvIGRvIHVubWFwLCB3ZSBhcmUgZ2V0dGluZyB0aGUgd3JvbmcgInVubWFw
IiBmcm9tIGEgZGlmZmVyZW50IG1lbXBvb2wuDQoNCkluIHRoaXMgcGF0Y2gsIHRoZSBtZW1wb29s
IGlzIGFzc29jaWF0ZWQgd2l0aCB0aGUgdW5tYXAgc3RydWN0dXJlIGluc3RlYWQgb2YgY29tcHV0
aW5nIGl0IGFnYWluLg0KQnkgdGhpcyB3YXksIGl0IGlzIGd1YXJhbnRlZWQgdGhhdCB0aGUgdW5t
YXAgaXMgdGhlIHNhbWUgd2hlbiB3ZSBnZXQgYW5kIHB1dCB0aGUgdW5tYXAgZGF0YS4NCg0KQlRX
OiB0aGUgbWVtcG9vbCBpcyBqdXN0IHVzZWQgdG8gbWFuYWdlIHRoZSBzdHJ1Y3QgdW5tYXAsIG5v
dCB0aGUgcGFnZXMuDQoNClRoYW5rcywNClh1ZWxpbiBTaGkNCg0KDQotLS0tLU9yaWdpbmFsIE1l
c3NhZ2UtLS0tLQ0KRnJvbTogRGFuIFdpbGxpYW1zIFttYWlsdG86ZGFuLmoud2lsbGlhbXNAaW50
ZWwuY29tXSANClNlbnQ6IDIwMTTE6jPUwjE5yNUgMToxNA0KVG86IFNoaSBYdWVsaW4tQjI5MjM3
DQpDYzogVmlub2QgS291bDsgbGludXhwcGMtZGV2OyBkbWFlbmdpbmVAdmdlci5rZXJuZWwub3Jn
DQpTdWJqZWN0OiBSZTogW1BBVENIXSBmaXggZG1hZW5naW5lX3VubWFwIGZhaWx1cmUuDQoNCk9u
IFR1ZSwgTWFyIDE4LCAyMDE0IGF0IDE6MzIgQU0sICA8eHVlbGluLnNoaUBmcmVlc2NhbGUuY29t
PiB3cm90ZToNCj4gRnJvbTogWHVlbGluIFNoaSA8eHVlbGluLnNoaUBmcmVlc2NhbGUuY29tPg0K
Pg0KPiBUaGUgY291bnQgd2hpY2ggaXMgdXNlZCB0byBnZXRfdW5tYXBfZGF0YSBtYXliZSBub3Qg
dGhlIHNhbWUgYXMgdGhlIA0KPiBjb3VudCBjb21wdXRlZCBpbiBkbWFlbmdpbmVfdW5tYXAgd2hp
Y2ggY2F1c2VzIHRvIGZyZWUgZGF0YSBpbiBhIHdyb25nIA0KPiBwb29sLg0KPg0KPiBUaGlzIHBh
dGNoIGZpeGVzIHRoaXMgaXNzdWUgYnkga2VlcGluZyB0aGUgcG9vbCBpbiB1bm1hcF9kYXRhIA0K
PiBzdHJ1Y3R1cmUuDQoNCldvbid0IHRoaXMgZnJlZSB0aGUgZW50aXJlIGNvdW50IGFueXdheXM/
ICBJbiB3aGF0IHNjZW5hcmlvIGlzIHRoZSBjb3VudCBkaWZmZXJlbnQgYXQgdW5tYXA/DQoNCg0K
^ permalink raw reply
* Re: [PATCH v2 2/6] powernv:cpufreq: Create a powernv_cpu_to_core_mask() helper.
From: Srivatsa S. Bhat @ 2014-03-19 6:35 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Gautham R. Shenoy, linuxppc-dev
In-Reply-To: <1395185847.30666.22.camel@pasglop>
On 03/19/2014 05:07 AM, Benjamin Herrenschmidt wrote:
> On Mon, 2014-03-10 at 16:40 +0530, Gautham R. Shenoy wrote:
>> From: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
>>
>> Create a helper method that computes the cpumask corresponding to the
>> thread-siblings of a cpu. Use this for initializing the policy->cpus
>> mask for a given cpu.
>>
>> (Original code written by Srivatsa S. Bhat. Gautham moved this to a
>> helper function!)
>
> How does that differ from the existing entry in the sibling map which
> you can obtain with the helper cpu_sibling_mask() ? (You probably want
> to *copy* the mask of course but I don't see the need of re-creating
> one from scratch).
>
The intent here was to have a sibling mask that is invariant of CPU
hotplug. cpu_sibling_mask is updated on every hotplug operation, and this
would break cpufreq, since policy->cpus has to be hotplug invariant.
This should have been noted in the changelog of patch 1 as well as this
patch. (The earlier (internal) versions of this patchset had the
description in the changelogs, but somehow it got dropped accidentally).
I'll work with Gautham and ensure that we have this important info
included in the changelog. Thanks for pointing it out!
Regards,
Srivatsa S. Bhat
> Also, this should have been CCed to the cpufreq mailing list and maybe
> the relevant maintainer too.
>
> Cheers,
> Ben.
>
>> Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
>> Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
>> ---
>> drivers/cpufreq/powernv-cpufreq.c | 24 ++++++++++++++++++------
>> 1 file changed, 18 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/cpufreq/powernv-cpufreq.c b/drivers/cpufreq/powernv-cpufreq.c
>> index ab1551f..4cad727 100644
>> --- a/drivers/cpufreq/powernv-cpufreq.c
>> +++ b/drivers/cpufreq/powernv-cpufreq.c
>> @@ -115,6 +115,23 @@ static struct freq_attr *powernv_cpu_freq_attr[] = {
>>
>> /* Helper routines */
>>
>> +/**
>> + * Sets the bits corresponding to the thread-siblings of cpu in its core
>> + * in 'cpus'.
>> + */
>> +static void powernv_cpu_to_core_mask(unsigned int cpu, cpumask_var_t cpus)
>> +{
>> + int base, i;
>> +
>> + base = cpu_first_thread_sibling(cpu);
>> +
>> + for (i = 0; i < threads_per_core; i++) {
>> + cpumask_set_cpu(base + i, cpus);
>> + }
>> +
>> + return;
>> +}
>> +
>> /* Access helpers to power mgt SPR */
>>
>> static inline unsigned long get_pmspr(unsigned long sprn)
>> @@ -180,13 +197,8 @@ static int powernv_set_freq(cpumask_var_t cpus, unsigned int new_index)
>>
>> static int powernv_cpufreq_cpu_init(struct cpufreq_policy *policy)
>> {
>> - int base, i;
>> -
>> #ifdef CONFIG_SMP
>> - base = cpu_first_thread_sibling(policy->cpu);
>> -
>> - for (i = 0; i < threads_per_core; i++)
>> - cpumask_set_cpu(base + i, policy->cpus);
>> + powernv_cpu_to_core_mask(policy->cpu, policy->cpus);
>> #endif
>> policy->cpuinfo.transition_latency = 25000;
>>
>
>
^ permalink raw reply
* Re: [PATCH 9/9] powerpc/pm: support deep sleep feature on T1040
From: Chenhui Zhao @ 2014-03-19 0:56 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, linux-kernel, Jason.Jin
In-Reply-To: <1395182529.12479.223.camel@snotra.buserror.net>
On Tue, Mar 18, 2014 at 05:42:09PM -0500, Scott Wood wrote:
> On Mon, 2014-03-17 at 19:19 +0800, Chenhui Zhao wrote:
> > On Fri, Mar 14, 2014 at 06:18:27PM -0500, Scott Wood wrote:
> > > On Wed, 2014-03-12 at 18:40 +0800, Chenhui Zhao wrote:
> > > > On Tue, Mar 11, 2014 at 08:10:24PM -0500, Scott Wood wrote:
> > > > > On Fri, 2014-03-07 at 12:58 +0800, Chenhui Zhao wrote:
> > > > > > From: Zhao Chenhui <chenhui.zhao@freescale.com>
> > > > > >
> > > > > > T1040 supports deep sleep feature, which can switch off most parts of
> > > > > > the SoC when it is in deep sleep mode. This way, it becomes more
> > > > > > energy-efficient.
> > > > > >
> > > > > > The DDR controller will also be powered off in deep sleep. Therefore,
> > > > > > the last stage (the latter part of fsl_dp_enter_low) will run without DDR
> > > > > > access. This piece of code and related TLBs will be prefetched.
> > > > > >
> > > > > > Due to the different initialization code between 32-bit and 64-bit, they
> > > > > > have seperate resume entry and precedure.
> > > > > >
> > > > > > The feature supports 32-bit and 64-bit kernel mode.
> > > > > >
> > > > > > Signed-off-by: Zhao Chenhui <chenhui.zhao@freescale.com>
> > > > > > ---
> > > > > > arch/powerpc/include/asm/booke_save_regs.h | 3 +
> > > > > > arch/powerpc/kernel/cpu_setup_fsl_booke.S | 17 ++
> > > > > > arch/powerpc/kernel/head_fsl_booke.S | 30 +++
> > > > > > arch/powerpc/platforms/85xx/Makefile | 2 +-
> > > > > > arch/powerpc/platforms/85xx/deepsleep.c | 201 +++++++++++++++++++
> > > > > > arch/powerpc/platforms/85xx/qoriq_pm.c | 38 ++++
> > > > > > arch/powerpc/platforms/85xx/sleep.S | 295 ++++++++++++++++++++++++++++
> > > > > > arch/powerpc/sysdev/fsl_soc.h | 7 +
> > > > > > 8 files changed, 592 insertions(+), 1 deletions(-)
> > > > > > create mode 100644 arch/powerpc/platforms/85xx/deepsleep.c
> > > > > > create mode 100644 arch/powerpc/platforms/85xx/sleep.S
> > > > > >
> > > > > > diff --git a/arch/powerpc/include/asm/booke_save_regs.h b/arch/powerpc/include/asm/booke_save_regs.h
> > > > > > index 87c357a..37c1f6c 100644
> > > > > > --- a/arch/powerpc/include/asm/booke_save_regs.h
> > > > > > +++ b/arch/powerpc/include/asm/booke_save_regs.h
> > > > > > @@ -88,6 +88,9 @@
> > > > > > #define HIBERNATION_FLAG 1
> > > > > > #define DEEPSLEEP_FLAG 2
> > > > > >
> > > > > > +#define CPLD_FLAG 1
> > > > > > +#define FPGA_FLAG 2
> > > > >
> > > > > What is this?
> > > >
> > > > We have two kind of boards, QDS and RDB.
> > > > They have different register map. Use the flag to indicate the current board is using which kind
> > > > of register map.
> > >
> > > CPLD versus FPGA is not a meaningful difference. We don't care what
> > > technology is used to implement programmable logic -- we care what
> > > programming interface is exposed. Customers will have their own boards
> > > that will likely not imitate either of these programming interfaces, but
> > > what they do have will still probably be implemented in a CPLD or FPGA.
> > > Likewise, Freescale may have future reference boards whose CPLD/FPGA is
> > > not compatible.
> >
> > Will use a better name.
> >
> > >
> > > So use better naming, and structure the code so it's easy to plug in
> > > implementations for new or custom boards.
> > >
> > > > > > diff --git a/arch/powerpc/kernel/head_fsl_booke.S b/arch/powerpc/kernel/head_fsl_booke.S
> > > > > > index 20204fe..3285752 100644
> > > > > > --- a/arch/powerpc/kernel/head_fsl_booke.S
> > > > > > +++ b/arch/powerpc/kernel/head_fsl_booke.S
> > > > > > @@ -162,6 +162,19 @@ _ENTRY(__early_start)
> > > > > > #include "fsl_booke_entry_mapping.S"
> > > > > > #undef ENTRY_MAPPING_BOOT_SETUP
> > > > > >
> > > > > > +#if defined(CONFIG_SUSPEND) && defined(CONFIG_FSL_CORENET_RCPM)
> > > > > > + /* if deep_sleep_flag != 0, jump to the deep sleep resume entry */
> > > > > > + LOAD_REG_ADDR(r4, deep_sleep_flag)
> > > > > > + lwz r3, 0(r4)
> > > > > > + cmpwi r3, 0
> > > > > > + beq 11f
> > > > > > + /* clear deep_sleep_flag */
> > > > > > + li r3, 0
> > > > > > + stw r3, 0(r4)
> > > > > > + b fsl_deepsleep_resume
> > > > > > +11:
> > > > > > +#endif
> > > > >
> > > > > Why do you come in via the normal kernel entry, versus specifying a
> > > > > direct entry point for deep sleep resume? How does U-Boot even know
> > > > > what the normal entry is when resuming?
> > > >
> > > > I wish to return to a specified point (like 64-bit mode), but the code in
> > > > fsl_booke_entry_mapping.S only can run in the first page. Because it
> > > > only setups a temp mapping of 4KB.
> > >
> > > Why do you need the entry mapping on 32-bit but not 64-bit?
> >
> > fsl_booke_entry_mapping.S is for 32-bit. 64-bit calls
> > initial_tlb_book3e() in exceptions-64e.S.
>
> The answer I was looking for is that __entry_deep_sleep calls
> start_initialization_book3e which calls the code to handle it.
>
> But why is it driven from sleep.S on 64-bit but not on 32-bit? Why
> can't you make it so that the 32-bit TLB setup can be called into in a
> similar manner?
Yes. I also wish to do like this. As I mentioned, the problem in 32-bit
is that the TLB setup code in fsl_booke_entry_mapping.S only setups a temp
mapping of 4KB, so these code only can run in this 4KB address space. But the
code in sleep.S is outside of the 4KB space. So can't put the TLB setup
code in sleep.S. There are two method to solve it.
1) The current method is running the TLB setup code of fsl_booke_entry_mapping.S in the 4KB
space, then jump to the code of sleep.S.
2) extend the temp mapping space in the TLB setup code to cover kernel, say 4MB or 8MB. But
not sure if there are any side effects.
>
> > > > > > +#define FSLDELAY(count) \
> > > > > > + li r3, (count)@l; \
> > > > > > + slwi r3, r3, 10; \
> > > > > > + mtctr r3; \
> > > > > > +101: nop; \
> > > > > > + bdnz 101b;
> > > > >
> > > > > You don't need a namespace prefix on local macros in a non-header file.
> > > > >
> > > > > Is the timebase stopped where you're calling this from?
> > > >
> > > > No. My purpose is to avoid jump in the last stage of entering deep sleep.
> > > > Jump may cause problem at that time.
> > >
> > > "bdnz" is a jump.
> > >
> > > What problems do you think a jump will cause?
> >
> > I mean a far jump which can jump to an address which has not been prefetched in
> > advance. I wish the code is executed in a restricted environment (predictable code
> > and address).
>
> Why would a timebase loop require a "far" jump?
I mean there is far jump in udely().
Do you mean using a timebase loop in the macro FSLDELAY? If so, I agree.
>
> > > > > You also probably want to do a "sync, readback, data dependency, isync"
> > > > > sequence to make sure that the store has hit CCSR before you begin your
> > > > > delay (or is a delay required at all if you do that?).
> > > >
> > > > Yes. It is safer with a sync sequence.
> > > >
> > > > The DDR controller need some time to signal the external DDR modules to
> > > > enter self refresh mode.
> > >
> > > Is it documented how much time it requires?
> > >
> > > -Scott
> >
> > No.
>
> How do you know the current delay is adequate in all circumstances (e.g
> clock speeds), much less on future chips? Is it documented that a delay
> is needed at all, or is this just something that appeared to make it
> work? If the latter, what happens if you put the synchronization in,
> but leave out the delay?
>
> -Scott
The code controls external parts (FPGA/CPLD, DDR module) to act, and
the sequent code must wait until external parts complete. We can't get
an ack from external parts, so use delay to make sure the sequence and
insert enough time to wait.
-Chenhui
^ permalink raw reply
* Re: [PATCH 7/9] fsl: add EPU FSM configuration for deep sleep
From: Chenhui Zhao @ 2014-03-19 0:08 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, linux-kernel, Jason.Jin
In-Reply-To: <1395184882.12479.253.camel@snotra.buserror.net>
On Tue, Mar 18, 2014 at 06:21:22PM -0500, Scott Wood wrote:
> On Mon, 2014-03-17 at 18:27 +0800, Chenhui Zhao wrote:
> > On Fri, Mar 14, 2014 at 05:51:09PM -0500, Scott Wood wrote:
> > > On Wed, 2014-03-12 at 16:34 +0800, Chenhui Zhao wrote:
> > > > On Tue, Mar 11, 2014 at 07:08:43PM -0500, Scott Wood wrote:
> > > > > On Fri, 2014-03-07 at 12:58 +0800, Chenhui Zhao wrote:
> > > > > > + /* Configure the EPU Counters */
> > > > > > + epu_write(EPCCR15, 0x92840000);
> > > > > > + epu_write(EPCCR14, 0x92840000);
> > > > > > + epu_write(EPCCR12, 0x92840000);
> > > > > > + epu_write(EPCCR11, 0x92840000);
> > > > > > + epu_write(EPCCR10, 0x92840000);
> > > > > > + epu_write(EPCCR9, 0x92840000);
> > > > > > + epu_write(EPCCR8, 0x92840000);
> > > > > > + epu_write(EPCCR5, 0x92840000);
> > > > > > + epu_write(EPCCR4, 0x92840000);
> > > > > > + epu_write(EPCCR2, 0x92840000);
> > > > > > +
> > > > > > + /* Configure the SCUs Inputs */
> > > > > > + epu_write(EPSMCR15, 0x76000000);
> > > > > > + epu_write(EPSMCR14, 0x00000031);
> > > > > > + epu_write(EPSMCR13, 0x00003100);
> > > > > > + epu_write(EPSMCR12, 0x7F000000);
> > > > > > + epu_write(EPSMCR11, 0x31740000);
> > > > > > + epu_write(EPSMCR10, 0x65000030);
> > > > > > + epu_write(EPSMCR9, 0x00003000);
> > > > > > + epu_write(EPSMCR8, 0x64300000);
> > > > > > + epu_write(EPSMCR7, 0x30000000);
> > > > > > + epu_write(EPSMCR6, 0x7C000000);
> > > > > > + epu_write(EPSMCR5, 0x00002E00);
> > > > > > + epu_write(EPSMCR4, 0x002F0000);
> > > > > > + epu_write(EPSMCR3, 0x2F000000);
> > > > > > + epu_write(EPSMCR2, 0x6C700000);
> > > > >
> > > > > Where do these magic numbers come from? Which chips are they valid for?
> > > >
> > > > They are for T1040. Can be found in the RCPM chapter of T1040RM.
> > >
> > > Then put in a comment to that effect, including what part of the RCPM
> > > chapter.
> > >
> > > How do you plan to handle the addition of another SoC with different
> > > values?
> > >
> > > -Scott
> >
> > Had thought that using an array to put these values (pairs of offset and value)
> > and passing the array to the function.
>
> Arrays are better than a long sequence of function calls in any case.
>
> > However, luckily T104x and LS1 have same values for these registers
> > according to the current Reference Manuals.
>
> If it's likely that the values will remain the same on all chips for the
> near future, then a fancy mechanism to select the array to use can wait
> -- but you should still use an array, and have a comment acknowledging
> the possibility of needing to accommodate different values in the
> future.
>
> -Scott
OK. Will use an array to pass the values.
-Chenhui
^ permalink raw reply
* Re: [PATCH v2 2/6] powernv:cpufreq: Create a powernv_cpu_to_core_mask() helper.
From: Benjamin Herrenschmidt @ 2014-03-18 23:37 UTC (permalink / raw)
To: Gautham R. Shenoy; +Cc: linuxppc-dev, srivatsa.bhat
In-Reply-To: <1394449861-8688-3-git-send-email-ego@linux.vnet.ibm.com>
On Mon, 2014-03-10 at 16:40 +0530, Gautham R. Shenoy wrote:
> From: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
>
> Create a helper method that computes the cpumask corresponding to the
> thread-siblings of a cpu. Use this for initializing the policy->cpus
> mask for a given cpu.
>
> (Original code written by Srivatsa S. Bhat. Gautham moved this to a
> helper function!)
How does that differ from the existing entry in the sibling map which
you can obtain with the helper cpu_sibling_mask() ? (You probably want
to *copy* the mask of course but I don't see the need of re-creating
one from scratch).
Also, this should have been CCed to the cpufreq mailing list and maybe
the relevant maintainer too.
Cheers,
Ben.
> Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
> Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
> ---
> drivers/cpufreq/powernv-cpufreq.c | 24 ++++++++++++++++++------
> 1 file changed, 18 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/cpufreq/powernv-cpufreq.c b/drivers/cpufreq/powernv-cpufreq.c
> index ab1551f..4cad727 100644
> --- a/drivers/cpufreq/powernv-cpufreq.c
> +++ b/drivers/cpufreq/powernv-cpufreq.c
> @@ -115,6 +115,23 @@ static struct freq_attr *powernv_cpu_freq_attr[] = {
>
> /* Helper routines */
>
> +/**
> + * Sets the bits corresponding to the thread-siblings of cpu in its core
> + * in 'cpus'.
> + */
> +static void powernv_cpu_to_core_mask(unsigned int cpu, cpumask_var_t cpus)
> +{
> + int base, i;
> +
> + base = cpu_first_thread_sibling(cpu);
> +
> + for (i = 0; i < threads_per_core; i++) {
> + cpumask_set_cpu(base + i, cpus);
> + }
> +
> + return;
> +}
> +
> /* Access helpers to power mgt SPR */
>
> static inline unsigned long get_pmspr(unsigned long sprn)
> @@ -180,13 +197,8 @@ static int powernv_set_freq(cpumask_var_t cpus, unsigned int new_index)
>
> static int powernv_cpufreq_cpu_init(struct cpufreq_policy *policy)
> {
> - int base, i;
> -
> #ifdef CONFIG_SMP
> - base = cpu_first_thread_sibling(policy->cpu);
> -
> - for (i = 0; i < threads_per_core; i++)
> - cpumask_set_cpu(base + i, policy->cpus);
> + powernv_cpu_to_core_mask(policy->cpu, policy->cpus);
> #endif
> policy->cpuinfo.transition_latency = 25000;
>
^ permalink raw reply
* Re: [PATCH 7/9] fsl: add EPU FSM configuration for deep sleep
From: Scott Wood @ 2014-03-18 23:21 UTC (permalink / raw)
To: Chenhui Zhao; +Cc: linuxppc-dev, linux-kernel, Jason.Jin
In-Reply-To: <20140317102727.GB6204@localhost.localdomain>
On Mon, 2014-03-17 at 18:27 +0800, Chenhui Zhao wrote:
> On Fri, Mar 14, 2014 at 05:51:09PM -0500, Scott Wood wrote:
> > On Wed, 2014-03-12 at 16:34 +0800, Chenhui Zhao wrote:
> > > On Tue, Mar 11, 2014 at 07:08:43PM -0500, Scott Wood wrote:
> > > > On Fri, 2014-03-07 at 12:58 +0800, Chenhui Zhao wrote:
> > > > > + /* Configure the EPU Counters */
> > > > > + epu_write(EPCCR15, 0x92840000);
> > > > > + epu_write(EPCCR14, 0x92840000);
> > > > > + epu_write(EPCCR12, 0x92840000);
> > > > > + epu_write(EPCCR11, 0x92840000);
> > > > > + epu_write(EPCCR10, 0x92840000);
> > > > > + epu_write(EPCCR9, 0x92840000);
> > > > > + epu_write(EPCCR8, 0x92840000);
> > > > > + epu_write(EPCCR5, 0x92840000);
> > > > > + epu_write(EPCCR4, 0x92840000);
> > > > > + epu_write(EPCCR2, 0x92840000);
> > > > > +
> > > > > + /* Configure the SCUs Inputs */
> > > > > + epu_write(EPSMCR15, 0x76000000);
> > > > > + epu_write(EPSMCR14, 0x00000031);
> > > > > + epu_write(EPSMCR13, 0x00003100);
> > > > > + epu_write(EPSMCR12, 0x7F000000);
> > > > > + epu_write(EPSMCR11, 0x31740000);
> > > > > + epu_write(EPSMCR10, 0x65000030);
> > > > > + epu_write(EPSMCR9, 0x00003000);
> > > > > + epu_write(EPSMCR8, 0x64300000);
> > > > > + epu_write(EPSMCR7, 0x30000000);
> > > > > + epu_write(EPSMCR6, 0x7C000000);
> > > > > + epu_write(EPSMCR5, 0x00002E00);
> > > > > + epu_write(EPSMCR4, 0x002F0000);
> > > > > + epu_write(EPSMCR3, 0x2F000000);
> > > > > + epu_write(EPSMCR2, 0x6C700000);
> > > >
> > > > Where do these magic numbers come from? Which chips are they valid for?
> > >
> > > They are for T1040. Can be found in the RCPM chapter of T1040RM.
> >
> > Then put in a comment to that effect, including what part of the RCPM
> > chapter.
> >
> > How do you plan to handle the addition of another SoC with different
> > values?
> >
> > -Scott
>
> Had thought that using an array to put these values (pairs of offset and value)
> and passing the array to the function.
Arrays are better than a long sequence of function calls in any case.
> However, luckily T104x and LS1 have same values for these registers
> according to the current Reference Manuals.
If it's likely that the values will remain the same on all chips for the
near future, then a fancy mechanism to select the array to use can wait
-- but you should still use an array, and have a comment acknowledging
the possibility of needing to accommodate different values in the
future.
-Scott
^ permalink raw reply
* Re: [PATCH 9/9] powerpc/pm: support deep sleep feature on T1040
From: Scott Wood @ 2014-03-18 23:18 UTC (permalink / raw)
To: Kevin Hao; +Cc: linuxppc-dev, Chenhui Zhao, Jason.Jin, linux-kernel
In-Reply-To: <20140316045801.GA32188@pek-khao-d1.corp.ad.wrs.com>
On Sun, 2014-03-16 at 12:58 +0800, Kevin Hao wrote:
> On Fri, Mar 14, 2014 at 05:26:27PM -0500, Scott Wood wrote:
> > On Thu, 2014-03-13 at 15:46 +0800, Kevin Hao wrote:
> > > On Wed, Mar 12, 2014 at 12:43:05PM -0500, Scott Wood wrote:
> > > > > Shouldn't we use "readback, sync" here? The following is quoted form t4240RM:
> > > > > To guarantee that the results of any sequence of writes to configuration
> > > > > registers are in effect, the final configuration register write should be
> > > > > immediately followed by a read of the same register, and that should be
> > > > > followed by a SYNC instruction. Then accesses can safely be made to memory
> > > > > regions affected by the configuration register write.
> > > >
> > > > I agree that the sync before the readback is probably not necessary,
> > > > since transactions to the same address should already be ordered.
> > > >
> > > > A sync after the readback helps if you're trying to order the readback
> > > > with subsequent memory accesses, though in that case wouldn't a sync
> > > > alone (no readback) be adequate?
> > >
> > > No, we don't just want to order the subsequent memory access here.
> > > The 'write, readback, sync' is the required sequence if we want to make
> > > sure that the writing to CCSR register does really take effect.
> > >
> > > > Though maybe not always -- see the
> > > > comment near the end of fsl_elbc_write_buf() in
> > > > drivers/mtd/nand_fsl_elbc.c. I guess the readback does more than just
> > > > make sure the device has seen the write, ensuring that the device has
> > > > finished the transaction to the point of acting on another one.
> > >
> > > Agree.
> > >
> > > >
> > > > The data dependency plus isync sequence, which is done by the normal I/O
> > > > accessors used from C code, orders the readback versus all future
> > > > instructions (not just I/O). The delay loop is not I/O.
> > >
> > > According to the PowerISA, the sequence 'load, date dependency, isync' only
> > > order the load accesses.
> >
> > The point is to order the delay loop after the load, not to order
> > storage versus storage.
>
> I think the point is to make sure that the writing of the CCSR_DDR_SDRAM_CFG_2
> does really take effect before we begin to delay loop.
Yes.
> The sequence "write, readback, sync" will guarantee this according to the manual.
If you're referring to the section you quoted above, the manual does not
say that. It only talks about when accesses "to memory regions affected
by the configuration register write" can be safely made.
> If we just want to
> order the delay loop after the load, the following sequence should be enough:
> store to CCSR_DDR_SDRAM_CFG_2
> load from CCSR_DDR_SDRAM_CFG_2
> isync or sync
> delay loop
>
> Why do we need the 'date dependency' here? According to the e6500 manual, the
> instructions can execute out of order, but complete in order. So I am really
> wondering why we need to order the load and the following delay loop if there
> is no intention to order the storage access?
The data (not date) dependency means that the twi will not execute until
after the load instruction returns data (thus, after the device has
responded to the load). The twi, being a flow control instruction
rather than a storage instruction, should be fully ordered by isync.
>From the isync description in the ISA: "Except as described in the
preceding sentence, the isync instruction may complete before storage
accesses associated with instructions preceding the
isync instruction have been performed."
I don't know if that really applies to loads (as opposed to stores), and
it probably doesn't apply to guarded loads, but I feel safer leaving the
twi in.
As for sync instead of isync, I see nothing to indicate that it would be
adequate (though it may be that the only reason there needed to be a
delay loop in the first place was the lack of a readback/sync before
doing other I/O, in which case this is moot).
> > This is a sequence we're already using on all of our I/O loads
> > (excluding accesses like in this patch that don't use the standard
> > accessors). I'm confident that it works even if it's not
> > architecturally guaranteed.
>
> This sequence is used to order the load and the followed storage access.
It's also used to order loads versus other things, such as enabling
MSR[EE].
> And this is guaranteed by the architecture. But I don't think it is suitable
> for a case like this. The following is quoted from PowerISA:
> Because stores cannot be performed “out-of-order”
> (see Book III), if a Store instruction depends on the
> value returned by a preceding Load instruction
> (because the value returned by the Load is used to
> compute either the effective address specified by the
> Store or the value to be stored), the corresponding stor-
> age accesses are performed in program order. The
> same applies if whether the Store instruction is exe-
> cuted depends on a conditional Branch instruction that
> in turn depends on the value returned by a preceding
> Load instruction.
>
> Because an isync instruction prevents the execution of
> instructions following the isync until instructions pre-
> ceding the isync have completed, if an isync follows a
> conditional Branch instruction that depends on the
> value returned by a preceding Load instruction, the
> load on which the Branch depends is performed before
> any loads caused by instructions following the isync.
>
> I think the above description would guarantee that the load will be performed
> before any storage access (both load and store) following the isync in the
> following scenario:
> lwz r4, 0(r3)
> twi 0, r4, 0
> isync
I think it's a poorly worded section, but yes, it guarantees both loads
and stores -- unnecessarily doing so in separate places with different
wording. But by the definition of isync I don't see why it does not
apply to *any* instruction after the isync, not just loads and stores.
> > I'm not sure that there exists a clear
> > architectural way of synchronizing non-storage instructions relative to
> > storage instructions.
>
> Isn't what the execution synchronization instructions such as sync, isync, mtmsr
> do?
No. Execution synchronizing just says that the previous instructions
"have completed to a point at which they have reported all the
exceptions they will cause" (I'm assuming this doesn't include machine
check error reports), and that the previous instructions won't be
affected by context changes after the execution synchronizing
instruction, not that the previous instructions are fully completed.
> > Given that isync is documented as preventing any execution of
> > instructions after the isync until all previous instructions complete,
> > it doesn't seem to make sense for the architecture to explicitly talk
> > about loads (as opposed to any other instruction) following a load,
> > dependent conditional branch, isync sequence.
>
> Sorry, I didn't get what you mean.
I mean that I do not understand why it says, "the load on which the
Branch depends is performed before any loads caused by instructions
following the isync" rather than "the Load on which the Branch depends
is performed before any instructions following the isync".
> > > So if we want to order all the storage access as well
> > > as execution synchronization, we should choose sync here.
> >
> > Do we need execution synchronization or context synchronization?
>
> There is no context-altering instruction here, so I think an execution
> synchronizing instruction should be enough here.
Is the ISA ever explicit about what constitutes "context"? In any case,
just because we don't need that aspect of context synchronization
doesn't mean execution synchronization is enough. The behavior we want
is described in the isync instruction specifically, not in "context
synchronization" or "execution synchronization".
> > The t4240 RM section that talks about a readback and a sync is in the
> > context of subsequent memory operations ("Then accesses can safely be
> > made to memory regions affected..."), not arbitrary instructions.
>
> I assume that this sequence also guarantee that the writing does take effect.
You may assume that, but the manual doesn't say that. Sync could
(AFAIK) be implemented by emitting a barrier on the bus, or delaying
future storage accesses, rather than waiting for everything to have
finished before proceeding.
> > In any case, this is not performance critical and thus it's better to
> > oversynchronize than undersynchronize.
>
> On the contrary I think that sync is oversynchronize instead of
> undersynchronize. It not only provide the execution synchronizing but also
> order all the storage accesses. That is why I prefer the sync. :-)
sync is not a superset of isync. isync is not a superset of sync. If
you want to oversynchronize to be safe, do both (though even that isn't
equivalent to a barrier that orders everything, which is partly why a
readback is needed).
-Scott
^ permalink raw reply
* Re: [PATCH 9/9] powerpc/pm: support deep sleep feature on T1040
From: Scott Wood @ 2014-03-18 22:42 UTC (permalink / raw)
To: Chenhui Zhao; +Cc: linuxppc-dev, linux-kernel, Jason.Jin
In-Reply-To: <20140317111957.GD6204@localhost.localdomain>
On Mon, 2014-03-17 at 19:19 +0800, Chenhui Zhao wrote:
> On Fri, Mar 14, 2014 at 06:18:27PM -0500, Scott Wood wrote:
> > On Wed, 2014-03-12 at 18:40 +0800, Chenhui Zhao wrote:
> > > On Tue, Mar 11, 2014 at 08:10:24PM -0500, Scott Wood wrote:
> > > > On Fri, 2014-03-07 at 12:58 +0800, Chenhui Zhao wrote:
> > > > > From: Zhao Chenhui <chenhui.zhao@freescale.com>
> > > > >
> > > > > T1040 supports deep sleep feature, which can switch off most parts of
> > > > > the SoC when it is in deep sleep mode. This way, it becomes more
> > > > > energy-efficient.
> > > > >
> > > > > The DDR controller will also be powered off in deep sleep. Therefore,
> > > > > the last stage (the latter part of fsl_dp_enter_low) will run without DDR
> > > > > access. This piece of code and related TLBs will be prefetched.
> > > > >
> > > > > Due to the different initialization code between 32-bit and 64-bit, they
> > > > > have seperate resume entry and precedure.
> > > > >
> > > > > The feature supports 32-bit and 64-bit kernel mode.
> > > > >
> > > > > Signed-off-by: Zhao Chenhui <chenhui.zhao@freescale.com>
> > > > > ---
> > > > > arch/powerpc/include/asm/booke_save_regs.h | 3 +
> > > > > arch/powerpc/kernel/cpu_setup_fsl_booke.S | 17 ++
> > > > > arch/powerpc/kernel/head_fsl_booke.S | 30 +++
> > > > > arch/powerpc/platforms/85xx/Makefile | 2 +-
> > > > > arch/powerpc/platforms/85xx/deepsleep.c | 201 +++++++++++++++++++
> > > > > arch/powerpc/platforms/85xx/qoriq_pm.c | 38 ++++
> > > > > arch/powerpc/platforms/85xx/sleep.S | 295 ++++++++++++++++++++++++++++
> > > > > arch/powerpc/sysdev/fsl_soc.h | 7 +
> > > > > 8 files changed, 592 insertions(+), 1 deletions(-)
> > > > > create mode 100644 arch/powerpc/platforms/85xx/deepsleep.c
> > > > > create mode 100644 arch/powerpc/platforms/85xx/sleep.S
> > > > >
> > > > > diff --git a/arch/powerpc/include/asm/booke_save_regs.h b/arch/powerpc/include/asm/booke_save_regs.h
> > > > > index 87c357a..37c1f6c 100644
> > > > > --- a/arch/powerpc/include/asm/booke_save_regs.h
> > > > > +++ b/arch/powerpc/include/asm/booke_save_regs.h
> > > > > @@ -88,6 +88,9 @@
> > > > > #define HIBERNATION_FLAG 1
> > > > > #define DEEPSLEEP_FLAG 2
> > > > >
> > > > > +#define CPLD_FLAG 1
> > > > > +#define FPGA_FLAG 2
> > > >
> > > > What is this?
> > >
> > > We have two kind of boards, QDS and RDB.
> > > They have different register map. Use the flag to indicate the current board is using which kind
> > > of register map.
> >
> > CPLD versus FPGA is not a meaningful difference. We don't care what
> > technology is used to implement programmable logic -- we care what
> > programming interface is exposed. Customers will have their own boards
> > that will likely not imitate either of these programming interfaces, but
> > what they do have will still probably be implemented in a CPLD or FPGA.
> > Likewise, Freescale may have future reference boards whose CPLD/FPGA is
> > not compatible.
>
> Will use a better name.
>
> >
> > So use better naming, and structure the code so it's easy to plug in
> > implementations for new or custom boards.
> >
> > > > > diff --git a/arch/powerpc/kernel/head_fsl_booke.S b/arch/powerpc/kernel/head_fsl_booke.S
> > > > > index 20204fe..3285752 100644
> > > > > --- a/arch/powerpc/kernel/head_fsl_booke.S
> > > > > +++ b/arch/powerpc/kernel/head_fsl_booke.S
> > > > > @@ -162,6 +162,19 @@ _ENTRY(__early_start)
> > > > > #include "fsl_booke_entry_mapping.S"
> > > > > #undef ENTRY_MAPPING_BOOT_SETUP
> > > > >
> > > > > +#if defined(CONFIG_SUSPEND) && defined(CONFIG_FSL_CORENET_RCPM)
> > > > > + /* if deep_sleep_flag != 0, jump to the deep sleep resume entry */
> > > > > + LOAD_REG_ADDR(r4, deep_sleep_flag)
> > > > > + lwz r3, 0(r4)
> > > > > + cmpwi r3, 0
> > > > > + beq 11f
> > > > > + /* clear deep_sleep_flag */
> > > > > + li r3, 0
> > > > > + stw r3, 0(r4)
> > > > > + b fsl_deepsleep_resume
> > > > > +11:
> > > > > +#endif
> > > >
> > > > Why do you come in via the normal kernel entry, versus specifying a
> > > > direct entry point for deep sleep resume? How does U-Boot even know
> > > > what the normal entry is when resuming?
> > >
> > > I wish to return to a specified point (like 64-bit mode), but the code in
> > > fsl_booke_entry_mapping.S only can run in the first page. Because it
> > > only setups a temp mapping of 4KB.
> >
> > Why do you need the entry mapping on 32-bit but not 64-bit?
>
> fsl_booke_entry_mapping.S is for 32-bit. 64-bit calls
> initial_tlb_book3e() in exceptions-64e.S.
The answer I was looking for is that __entry_deep_sleep calls
start_initialization_book3e which calls the code to handle it.
But why is it driven from sleep.S on 64-bit but not on 32-bit? Why
can't you make it so that the 32-bit TLB setup can be called into in a
similar manner?
> > > > > +#define FSLDELAY(count) \
> > > > > + li r3, (count)@l; \
> > > > > + slwi r3, r3, 10; \
> > > > > + mtctr r3; \
> > > > > +101: nop; \
> > > > > + bdnz 101b;
> > > >
> > > > You don't need a namespace prefix on local macros in a non-header file.
> > > >
> > > > Is the timebase stopped where you're calling this from?
> > >
> > > No. My purpose is to avoid jump in the last stage of entering deep sleep.
> > > Jump may cause problem at that time.
> >
> > "bdnz" is a jump.
> >
> > What problems do you think a jump will cause?
>
> I mean a far jump which can jump to an address which has not been prefetched in
> advance. I wish the code is executed in a restricted environment (predictable code
> and address).
Why would a timebase loop require a "far" jump?
> > > > You also probably want to do a "sync, readback, data dependency, isync"
> > > > sequence to make sure that the store has hit CCSR before you begin your
> > > > delay (or is a delay required at all if you do that?).
> > >
> > > Yes. It is safer with a sync sequence.
> > >
> > > The DDR controller need some time to signal the external DDR modules to
> > > enter self refresh mode.
> >
> > Is it documented how much time it requires?
> >
> > -Scott
>
> No.
How do you know the current delay is adequate in all circumstances (e.g
clock speeds), much less on future chips? Is it documented that a delay
is needed at all, or is this just something that appeared to make it
work? If the latter, what happens if you put the synchronization in,
but leave out the delay?
-Scott
^ permalink raw reply
* Re: [UPDATED PATCH v3 10/52] arm, kvm: Fix CPU hotplug callback registration
From: Christoffer Dall @ 2014-03-18 22:08 UTC (permalink / raw)
To: Srivatsa S. Bhat
Cc: ego, kvm@vger.kernel.org, peterz, oleg, linuxppc-dev,
Paul Mackerras, Michel Lespinasse, mingo, linux-arch,
Russell King, kvmarm@lists.cs.columbia.edu, Gleb Natapov,
Paul McKenney, linux-pm, Marc Zyngier, Rusty Russell,
Thomas Gleixner, linux-arm-kernel@lists.infradead.org, rjw,
linux-kernel@vger.kernel.org, tj, Paolo Bonzini, akpm
In-Reply-To: <53281E89.7080201@linux.vnet.ibm.com>
On 18 March 2014 03:23, Srivatsa S. Bhat
<srivatsa.bhat@linux.vnet.ibm.com> wrote:
> On 03/15/2014 12:40 AM, Christoffer Dall wrote:
>> On Fri, Mar 14, 2014 at 11:13:29AM +0530, Srivatsa S. Bhat wrote:
>>> On 03/13/2014 04:51 AM, Christoffer Dall wrote:
>>>> On Tue, Mar 11, 2014 at 02:05:38AM +0530, Srivatsa S. Bhat wrote:
>>>>> Subsystems that want to register CPU hotplug callbacks, as well as perform
>>>>> initialization for the CPUs that are already online, often do it as shown
>>>>> below:
>>>>>
> [...]
>>>> Just so we're clear, the existing code was simply racy as not prone to
>>>> deadlocks, right?
>>>>
>>>> This makes it clear that the test above for compatible CPUs can be quite
>>>> easily evaded by using CPU hotplug, but we don't really have a good
>>>> solution for handling that yet... Hmmm, grumble grumble, I guess if you
>>>> hotplug unsupported CPUs on a KVM/ARM system for now, stuff will break.
>>>>
>>>
>>> In this particular case, there was no deadlock possibility, rather the
>>> existing code had insufficient synchronization against CPU hotplug.
>>>
>>> init_hyp_mode() would invoke cpu_init_hyp_mode() on currently online CPUs
>>> using on_each_cpu(). If a CPU came online after this point and before calling
>>> register_cpu_notifier(), that CPU would remain uninitialized because this
>>> subsystem would miss the hot-online event. This patch fixes this bug and
>>> also uses the new synchronization method (instead of get/put_online_cpus())
>>> to ensure that we don't deadlock with CPU hotplug.
>>>
>>
>> Yes, that was my conclusion as well. Thanks for clarifying. (It could
>> be noted in the commit message as well if you should feel so inclined).
>>
>
> Please find the patch with updated changelog (and your Ack) below.
> (No changes in code).
>
perfect, thanks!
> From: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
> Subject: [PATCH] arm, kvm: Fix CPU hotplug callback registration
>
> Subsystems that want to register CPU hotplug callbacks, as well as perform
> initialization for the CPUs that are already online, often do it as shown
> below:
>
> get_online_cpus();
>
> for_each_online_cpu(cpu)
> init_cpu(cpu);
>
> register_cpu_notifier(&foobar_cpu_notifier);
>
> put_online_cpus();
>
> This is wrong, since it is prone to ABBA deadlocks involving the
> cpu_add_remove_lock and the cpu_hotplug.lock (when running concurrently
> with CPU hotplug operations).
>
> Instead, the correct and race-free way of performing the callback
> registration is:
>
> cpu_notifier_register_begin();
>
> for_each_online_cpu(cpu)
> init_cpu(cpu);
>
> /* Note the use of the double underscored version of the API */
> __register_cpu_notifier(&foobar_cpu_notifier);
>
> cpu_notifier_register_done();
>
>
> In the existing arm kvm code, there is no synchronization with CPU hotplug
> to avoid missing the hotplug events that might occur after invoking
> init_hyp_mode() and before calling register_cpu_notifier(). Fix this bug
> and also use the new synchronization method (instead of get/put_online_cpus())
> to ensure that we don't deadlock with CPU hotplug.
>
> Cc: Gleb Natapov <gleb@kernel.org>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Ingo Molnar <mingo@kernel.org>
> Cc: kvmarm@lists.cs.columbia.edu
> Cc: kvm@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> Acked-by: Paolo Bonzini <pbonzini@redhat.com>
> Acked-by: Christoffer Dall <christoffer.dall@linaro.org>
> Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
> ---
>
> arch/arm/kvm/arm.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
> index bd18bb8..f0e50a0 100644
> --- a/arch/arm/kvm/arm.c
> +++ b/arch/arm/kvm/arm.c
> @@ -1051,21 +1051,26 @@ int kvm_arch_init(void *opaque)
> }
> }
>
> + cpu_notifier_register_begin();
> +
> err = init_hyp_mode();
> if (err)
> goto out_err;
>
> - err = register_cpu_notifier(&hyp_init_cpu_nb);
> + err = __register_cpu_notifier(&hyp_init_cpu_nb);
> if (err) {
> kvm_err("Cannot register HYP init CPU notifier (%d)\n", err);
> goto out_err;
> }
>
> + cpu_notifier_register_done();
> +
> hyp_cpu_pm_init();
>
> kvm_coproc_table_init();
> return 0;
> out_err:
> + cpu_notifier_register_done();
> return err;
> }
>
>
>
^ permalink raw reply
* [PATCH] i2c-cpm: Fix build by adding of_address.h and of_irq.h
From: Scott Wood @ 2014-03-18 21:10 UTC (permalink / raw)
To: Jochen Friedrich, Wolfram Sang
Cc: Richard Weinberger, Geert Uytterhoeven, linux-i2c, Scott Wood,
linuxppc-dev, stable
Fixes a build break due to the undeclared use of irq_of_parse_and_map()
and of_iomap(). This build break was apparently introduced while the
driver was unbuildable due to the bug fixed by
62c19c9d29e65086e5ae76df371ed2e6b23f00cd ("i2c: Remove usage of
orphaned symbol OF_I2C"). When 62c19c was added in v3.14-rc7,
the driver was enabled again, breaking the powerpc mpc85xx_defconfig
and mpc85xx_smp_defconfig.
62c19c is marked for stable, so this should go there as well.
Signed-off-by: Scott Wood <scottwood@freescale.com>
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Richard Weinberger <richard@nod.at>
Cc: stable@kernel.org
---
There are still warnings in this driver that suggest it is broken with
CONFIG_PHYS_64BIT, but that part does not appear to be a regression.
drivers/i2c/busses/i2c-cpm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/i2c/busses/i2c-cpm.c b/drivers/i2c/busses/i2c-cpm.c
index be7f0a2..f3b89a4 100644
--- a/drivers/i2c/busses/i2c-cpm.c
+++ b/drivers/i2c/busses/i2c-cpm.c
@@ -39,7 +39,9 @@
#include <linux/i2c.h>
#include <linux/io.h>
#include <linux/dma-mapping.h>
+#include <linux/of_address.h>
#include <linux/of_device.h>
+#include <linux/of_irq.h>
#include <linux/of_platform.h>
#include <sysdev/fsl_soc.h>
#include <asm/cpm.h>
--
1.8.3.2
^ permalink raw reply related
* Re: [PATCH] fix dmaengine_unmap failure.
From: Dan Williams @ 2014-03-18 17:13 UTC (permalink / raw)
To: Xuelin Shi; +Cc: Vinod Koul, dmaengine@vger.kernel.org, linuxppc-dev
In-Reply-To: <1395131520-30207-1-git-send-email-xuelin.shi@freescale.com>
On Tue, Mar 18, 2014 at 1:32 AM, <xuelin.shi@freescale.com> wrote:
> From: Xuelin Shi <xuelin.shi@freescale.com>
>
> The count which is used to get_unmap_data maybe not the same as the
> count computed in dmaengine_unmap which causes to free data in a
> wrong pool.
>
> This patch fixes this issue by keeping the pool in unmap_data
> structure.
Won't this free the entire count anyways? In what scenario is the
count different at unmap?
^ permalink raw reply
* [UPDATED PATCH v3 10/52] arm, kvm: Fix CPU hotplug callback registration
From: Srivatsa S. Bhat @ 2014-03-18 10:23 UTC (permalink / raw)
To: Christoffer Dall
Cc: ego, kvm, peterz, oleg, linuxppc-dev, paulus, walken, mingo,
linux-arch, linux, kvmarm, Gleb Natapov, paulmck, linux-pm,
marc.zyngier, rusty, tglx, linux-arm-kernel, rjw, linux-kernel,
tj, Paolo Bonzini, akpm
In-Reply-To: <20140314191055.GF28661@cbox>
On 03/15/2014 12:40 AM, Christoffer Dall wrote:
> On Fri, Mar 14, 2014 at 11:13:29AM +0530, Srivatsa S. Bhat wrote:
>> On 03/13/2014 04:51 AM, Christoffer Dall wrote:
>>> On Tue, Mar 11, 2014 at 02:05:38AM +0530, Srivatsa S. Bhat wrote:
>>>> Subsystems that want to register CPU hotplug callbacks, as well as perform
>>>> initialization for the CPUs that are already online, often do it as shown
>>>> below:
>>>>
[...]
>>> Just so we're clear, the existing code was simply racy as not prone to
>>> deadlocks, right?
>>>
>>> This makes it clear that the test above for compatible CPUs can be quite
>>> easily evaded by using CPU hotplug, but we don't really have a good
>>> solution for handling that yet... Hmmm, grumble grumble, I guess if you
>>> hotplug unsupported CPUs on a KVM/ARM system for now, stuff will break.
>>>
>>
>> In this particular case, there was no deadlock possibility, rather the
>> existing code had insufficient synchronization against CPU hotplug.
>>
>> init_hyp_mode() would invoke cpu_init_hyp_mode() on currently online CPUs
>> using on_each_cpu(). If a CPU came online after this point and before calling
>> register_cpu_notifier(), that CPU would remain uninitialized because this
>> subsystem would miss the hot-online event. This patch fixes this bug and
>> also uses the new synchronization method (instead of get/put_online_cpus())
>> to ensure that we don't deadlock with CPU hotplug.
>>
>
> Yes, that was my conclusion as well. Thanks for clarifying. (It could
> be noted in the commit message as well if you should feel so inclined).
>
Please find the patch with updated changelog (and your Ack) below.
(No changes in code).
From: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Subject: [PATCH] arm, kvm: Fix CPU hotplug callback registration
Subsystems that want to register CPU hotplug callbacks, as well as perform
initialization for the CPUs that are already online, often do it as shown
below:
get_online_cpus();
for_each_online_cpu(cpu)
init_cpu(cpu);
register_cpu_notifier(&foobar_cpu_notifier);
put_online_cpus();
This is wrong, since it is prone to ABBA deadlocks involving the
cpu_add_remove_lock and the cpu_hotplug.lock (when running concurrently
with CPU hotplug operations).
Instead, the correct and race-free way of performing the callback
registration is:
cpu_notifier_register_begin();
for_each_online_cpu(cpu)
init_cpu(cpu);
/* Note the use of the double underscored version of the API */
__register_cpu_notifier(&foobar_cpu_notifier);
cpu_notifier_register_done();
In the existing arm kvm code, there is no synchronization with CPU hotplug
to avoid missing the hotplug events that might occur after invoking
init_hyp_mode() and before calling register_cpu_notifier(). Fix this bug
and also use the new synchronization method (instead of get/put_online_cpus())
to ensure that we don't deadlock with CPU hotplug.
Cc: Gleb Natapov <gleb@kernel.org>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: kvmarm@lists.cs.columbia.edu
Cc: kvm@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Acked-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
---
arch/arm/kvm/arm.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index bd18bb8..f0e50a0 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -1051,21 +1051,26 @@ int kvm_arch_init(void *opaque)
}
}
+ cpu_notifier_register_begin();
+
err = init_hyp_mode();
if (err)
goto out_err;
- err = register_cpu_notifier(&hyp_init_cpu_nb);
+ err = __register_cpu_notifier(&hyp_init_cpu_nb);
if (err) {
kvm_err("Cannot register HYP init CPU notifier (%d)\n", err);
goto out_err;
}
+ cpu_notifier_register_done();
+
hyp_cpu_pm_init();
kvm_coproc_table_init();
return 0;
out_err:
+ cpu_notifier_register_done();
return err;
}
^ permalink raw reply related
* [PATCH] powerpc/qe: Setup clock source for TDM
From: Xie Xiaobo @ 2014-03-18 9:09 UTC (permalink / raw)
To: linuxppc-dev, scottwood; +Cc: Xie Xiaobo
Add tdm clock configuration in both qe clock system and
ucc fast controler.
Signed-off-by: Xie Xiaobo <X.Xie@freescale.com>
Signed-off-by: Haiying Wang <Haiying.Wang@freescale.com>
---
arch/powerpc/include/asm/immap_qe.h | 5 +-
arch/powerpc/include/asm/qe.h | 13 +-
arch/powerpc/include/asm/ucc.h | 6 +-
arch/powerpc/include/asm/ucc_fast.h | 10 +-
arch/powerpc/sysdev/qe_lib/qe.c | 9 +-
arch/powerpc/sysdev/qe_lib/ucc.c | 773 +++++++++++++++++++++++++++++++++-
arch/powerpc/sysdev/qe_lib/ucc_fast.c | 40 +-
7 files changed, 845 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/include/asm/immap_qe.h b/arch/powerpc/include/asm/immap_qe.h
index bedbff8..c76ef30 100644
--- a/arch/powerpc/include/asm/immap_qe.h
+++ b/arch/powerpc/include/asm/immap_qe.h
@@ -159,10 +159,7 @@ struct spi {
/* SI */
struct si1 {
- __be16 siamr1; /* SI1 TDMA mode register */
- __be16 sibmr1; /* SI1 TDMB mode register */
- __be16 sicmr1; /* SI1 TDMC mode register */
- __be16 sidmr1; /* SI1 TDMD mode register */
+ __be16 sixmr1[4]; /* SI1 TDMx (x = A B C D) mode register */
u8 siglmr1_h; /* SI1 global mode register high */
u8 res0[0x1];
u8 sicmdr1_h; /* SI1 command register high */
diff --git a/arch/powerpc/include/asm/qe.h b/arch/powerpc/include/asm/qe.h
index 32b9bfa..1c80fdc 100644
--- a/arch/powerpc/include/asm/qe.h
+++ b/arch/powerpc/include/asm/qe.h
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2006 Freescale Semiconductor, Inc. All rights reserved.
+ * Copyright (C) 2006, 2014 Freescale Semiconductor, Inc. All rights reserved.
*
* Authors: Shlomi Gridish <gridish@freescale.com>
* Li Yang <leoli@freescale.com>
@@ -75,6 +75,8 @@ enum qe_clock {
QE_CLK22, /* Clock 22 */
QE_CLK23, /* Clock 23 */
QE_CLK24, /* Clock 24 */
+ QE_RSYNC_PIN, /* RSYNC from pin */
+ QE_TSYNC_PIN, /* TSYNC from pin */
QE_CLK_DUMMY
};
@@ -636,6 +638,15 @@ struct ucc_slow_pram {
#define UCC_BISYNC_UCCE_TXB 0x0002
#define UCC_BISYNC_UCCE_RXB 0x0001
+/* Transparent UCC Event Register (UCCE) */
+#define UCC_TRANS_UCCE_GRA 0x0080
+#define UCC_TRANS_UCCE_TXE 0x0010
+#define UCC_TRANS_UCCE_RXF 0x0008
+#define UCC_TRANS_UCCE_BSY 0x0004
+#define UCC_TRANS_UCCE_TXB 0x0002
+#define UCC_TRANS_UCCE_RXB 0x0001
+
+
/* Gigabit Ethernet Fast UCC Event Register (UCCE) */
#define UCC_GETH_UCCE_MPD 0x80000000
#define UCC_GETH_UCCE_SCAR 0x40000000
diff --git a/arch/powerpc/include/asm/ucc.h b/arch/powerpc/include/asm/ucc.h
index 6927ac2..0a942c9 100644
--- a/arch/powerpc/include/asm/ucc.h
+++ b/arch/powerpc/include/asm/ucc.h
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2006 Freescale Semiconductor, Inc. All rights reserved.
+ * Copyright (C) 2006, 2014 Freescale Semiconductor, Inc. All rights reserved.
*
* Authors: Shlomi Gridish <gridish@freescale.com>
* Li Yang <leoli@freescale.com>
@@ -41,6 +41,10 @@ int ucc_set_qe_mux_mii_mng(unsigned int ucc_num);
int ucc_set_qe_mux_rxtx(unsigned int ucc_num, enum qe_clock clock,
enum comm_dir mode);
+int ucc_set_tdm_rxtx_clk(unsigned int tdm_num, enum qe_clock clock,
+ enum comm_dir mode);
+int ucc_set_tdm_rxtx_sync(unsigned int tdm_num, enum qe_clock clock,
+ enum comm_dir mode);
int ucc_mux_set_grant_tsa_bkpt(unsigned int ucc_num, int set, u32 mask);
diff --git a/arch/powerpc/include/asm/ucc_fast.h b/arch/powerpc/include/asm/ucc_fast.h
index 72ea9ba..98e19d8 100644
--- a/arch/powerpc/include/asm/ucc_fast.h
+++ b/arch/powerpc/include/asm/ucc_fast.h
@@ -1,7 +1,7 @@
/*
* Internal header file for UCC FAST unit routines.
*
- * Copyright (C) 2006 Freescale Semiconductor, Inc. All rights reserved.
+ * Copyright (C) 2006, 2014 Freescale Semiconductor, Inc. All rights reserved.
*
* Authors: Shlomi Gridish <gridish@freescale.com>
* Li Yang <leoli@freescale.com>
@@ -27,12 +27,15 @@
#define R_I 0x10000000 /* interrupt on reception */
#define R_L 0x08000000 /* last */
#define R_F 0x04000000 /* first */
+#define R_CM 0x02000000 /* CM */
/* transmit BD's status */
#define T_R 0x80000000 /* ready bit */
#define T_W 0x20000000 /* wrap bit */
#define T_I 0x10000000 /* interrupt on completion */
#define T_L 0x08000000 /* last */
+#define T_TC 0x04000000 /* crc */
+#define T_CM 0x02000000 /* CM */
/* Rx Data buffer must be 4 bytes aligned in most cases */
#define UCC_FAST_RX_ALIGN 4
@@ -118,9 +121,12 @@ enum ucc_fast_transparent_tcrc {
/* Fast UCC initialization structure */
struct ucc_fast_info {
int ucc_num;
+ int tdm_num;
enum qe_clock rx_clock;
enum qe_clock tx_clock;
- u32 regs;
+ enum qe_clock rx_sync;
+ enum qe_clock tx_sync;
+ resource_size_t regs;
int irq;
u32 uccm_mask;
int bd_mem_part;
diff --git a/arch/powerpc/sysdev/qe_lib/qe.c b/arch/powerpc/sysdev/qe_lib/qe.c
index 238a07b..9a9f733 100644
--- a/arch/powerpc/sysdev/qe_lib/qe.c
+++ b/arch/powerpc/sysdev/qe_lib/qe.c
@@ -1,5 +1,6 @@
/*
- * Copyright (C) 2006-2010 Freescale Semiconductor, Inc. All rights reserved.
+ * Copyright (C) 2006-2010, 2014 Freescale Semiconductor, Inc.
+ * All rights reserved.
*
* Authors: Shlomi Gridish <gridish@freescale.com>
* Li Yang <leoli@freescale.com>
@@ -240,6 +241,12 @@ enum qe_clock qe_clock_source(const char *source)
if (strcasecmp(source, "none") == 0)
return QE_CLK_NONE;
+ if (strcasecmp(source, "tsync_pin") == 0)
+ return QE_TSYNC_PIN;
+
+ if (strcasecmp(source, "rsync_pin") == 0)
+ return QE_RSYNC_PIN;
+
if (strncasecmp(source, "brg", 3) == 0) {
i = simple_strtoul(source + 3, NULL, 10);
if ((i >= 1) && (i <= 16))
diff --git a/arch/powerpc/sysdev/qe_lib/ucc.c b/arch/powerpc/sysdev/qe_lib/ucc.c
index 621575b..5c27e04 100644
--- a/arch/powerpc/sysdev/qe_lib/ucc.c
+++ b/arch/powerpc/sysdev/qe_lib/ucc.c
@@ -3,7 +3,7 @@
*
* QE UCC API Set - UCC specific routines implementations.
*
- * Copyright (C) 2006 Freescale Semiconductor, Inc. All rights reserved.
+ * Copyright (C) 2006, 2014 Freescale Semiconductor, Inc. All rights reserved.
*
* Authors: Shlomi Gridish <gridish@freescale.com>
* Li Yang <leoli@freescale.com>
@@ -210,3 +210,774 @@ int ucc_set_qe_mux_rxtx(unsigned int ucc_num, enum qe_clock clock,
return 0;
}
+
+/* tdm_num: TDM A-H port num is 0-7 */
+int ucc_set_tdm_rxtx_clk(u32 tdm_num, enum qe_clock clock,
+ enum comm_dir mode)
+{
+ u32 clock_bits, shift;
+ struct qe_mux *qe_mux_reg;
+ __be32 __iomem *cmxs1cr;
+
+ clock_bits = 0;
+ qe_mux_reg = &qe_immr->qmx;
+
+ if ((tdm_num > 7 || tdm_num < 0))
+ return -EINVAL;
+
+ /* The communications direction must be RX or TX */
+ if (!((mode == COMM_DIR_RX) || (mode == COMM_DIR_TX)))
+ return -EINVAL;
+
+ switch (mode) {
+ case COMM_DIR_RX:
+ switch (tdm_num) {
+ case 0:
+ switch (clock) {
+ case QE_BRG3:
+ clock_bits = 1;
+ break;
+ case QE_BRG4:
+ clock_bits = 2;
+ break;
+ case QE_CLK1:
+ clock_bits = 4;
+ break;
+ case QE_CLK2:
+ clock_bits = 5;
+ break;
+ case QE_CLK3:
+ clock_bits = 6;
+ break;
+ case QE_CLK8:
+ clock_bits = 7;
+ break;
+ default:
+ break;
+ }
+ shift = 28;
+ break;
+ case 1:
+ switch (clock) {
+ case QE_BRG3:
+ clock_bits = 1;
+ break;
+ case QE_BRG4:
+ clock_bits = 2;
+ break;
+ case QE_CLK1:
+ clock_bits = 4;
+ break;
+ case QE_CLK2:
+ clock_bits = 5;
+ break;
+ case QE_CLK5:
+ clock_bits = 6;
+ break;
+ case QE_CLK10:
+ clock_bits = 7;
+ break;
+ default:
+ break;
+ }
+ shift = 24;
+ break;
+ case 2:
+ switch (clock) {
+ case QE_BRG3:
+ clock_bits = 1;
+ break;
+ case QE_BRG4:
+ clock_bits = 2;
+ break;
+ case QE_CLK1:
+ clock_bits = 4;
+ break;
+ case QE_CLK2:
+ clock_bits = 5;
+ break;
+ case QE_CLK7:
+ clock_bits = 6;
+ break;
+ case QE_CLK12:
+ clock_bits = 7;
+ break;
+ default:
+ break;
+ }
+ shift = 20;
+ break;
+ case 3:
+ switch (clock) {
+ case QE_BRG3:
+ clock_bits = 1;
+ break;
+ case QE_BRG4:
+ clock_bits = 2;
+ break;
+ case QE_CLK1:
+ clock_bits = 4;
+ break;
+ case QE_CLK2:
+ clock_bits = 5;
+ break;
+ case QE_CLK9:
+ clock_bits = 6;
+ break;
+ case QE_CLK14:
+ clock_bits = 7;
+ break;
+ default:
+ break;
+ }
+ shift = 16;
+ break;
+ case 4:
+ switch (clock) {
+ case QE_BRG12:
+ clock_bits = 1;
+ break;
+ case QE_BRG13:
+ clock_bits = 2;
+ break;
+ case QE_CLK23:
+ clock_bits = 4;
+ break;
+ case QE_CLK24:
+ clock_bits = 5;
+ break;
+ case QE_CLK11:
+ clock_bits = 6;
+ break;
+ case QE_CLK16:
+ clock_bits = 7;
+ break;
+ default:
+ break;
+ }
+ shift = 28;
+ break;
+ case 5:
+ switch (clock) {
+ case QE_BRG12:
+ clock_bits = 1;
+ break;
+ case QE_BRG13:
+ clock_bits = 2;
+ break;
+ case QE_CLK23:
+ clock_bits = 4;
+ break;
+ case QE_CLK24:
+ clock_bits = 5;
+ break;
+ case QE_CLK13:
+ clock_bits = 6;
+ break;
+ case QE_CLK18:
+ clock_bits = 7;
+ break;
+ default:
+ break;
+ }
+ shift = 24;
+ break;
+ case 6:
+ switch (clock) {
+ case QE_BRG12:
+ clock_bits = 1;
+ break;
+ case QE_BRG13:
+ clock_bits = 2;
+ break;
+ case QE_CLK23:
+ clock_bits = 4;
+ break;
+ case QE_CLK24:
+ clock_bits = 5;
+ break;
+ case QE_CLK15:
+ clock_bits = 6;
+ break;
+ case QE_CLK20:
+ clock_bits = 7;
+ break;
+ default:
+ break;
+ }
+ shift = 20;
+ break;
+ case 7:
+ switch (clock) {
+ case QE_BRG12:
+ clock_bits = 1;
+ break;
+ case QE_BRG13:
+ clock_bits = 2;
+ break;
+ case QE_CLK23:
+ clock_bits = 4;
+ break;
+ case QE_CLK24:
+ clock_bits = 5;
+ break;
+ case QE_CLK17:
+ clock_bits = 6;
+ break;
+ case QE_CLK22:
+ clock_bits = 7;
+ break;
+ default:
+ break;
+ }
+ shift = 16;
+ break;
+ default:
+ break;
+ }
+ break;
+ case COMM_DIR_TX:
+ switch (tdm_num) {
+ case 0:
+ switch (clock) {
+ case QE_BRG3:
+ clock_bits = 1;
+ break;
+ case QE_BRG4:
+ clock_bits = 2;
+ break;
+ case QE_CLK1:
+ clock_bits = 4;
+ break;
+ case QE_CLK2:
+ clock_bits = 5;
+ break;
+ case QE_CLK4:
+ clock_bits = 6;
+ break;
+ case QE_CLK9:
+ clock_bits = 7;
+ break;
+ default:
+ break;
+ }
+ shift = 12;
+ break;
+ case 1:
+ switch (clock) {
+ case QE_BRG3:
+ clock_bits = 1;
+ break;
+ case QE_BRG4:
+ clock_bits = 2;
+ break;
+ case QE_CLK1:
+ clock_bits = 4;
+ break;
+ case QE_CLK2:
+ clock_bits = 5;
+ break;
+ case QE_CLK6:
+ clock_bits = 6;
+ break;
+ case QE_CLK11:
+ clock_bits = 7;
+ break;
+ default:
+ break;
+ }
+ shift = 8;
+ break;
+ case 2:
+ switch (clock) {
+ case QE_BRG3:
+ clock_bits = 1;
+ break;
+ case QE_BRG4:
+ clock_bits = 2;
+ break;
+ case QE_CLK1:
+ clock_bits = 4;
+ break;
+ case QE_CLK2:
+ clock_bits = 5;
+ break;
+ case QE_CLK8:
+ clock_bits = 6;
+ break;
+ case QE_CLK13:
+ clock_bits = 7;
+ break;
+ default:
+ break;
+ }
+ shift = 4;
+ break;
+ case 3:
+ switch (clock) {
+ case QE_BRG3:
+ clock_bits = 1;
+ break;
+ case QE_BRG4:
+ clock_bits = 2;
+ break;
+ case QE_CLK1:
+ clock_bits = 4;
+ break;
+ case QE_CLK2:
+ clock_bits = 5;
+ break;
+ case QE_CLK10:
+ clock_bits = 6;
+ break;
+ case QE_CLK15:
+ clock_bits = 7;
+ break;
+ default:
+ break;
+ }
+ shift = 0;
+ break;
+ case 4:
+ switch (clock) {
+ case QE_BRG12:
+ clock_bits = 1;
+ break;
+ case QE_BRG13:
+ clock_bits = 2;
+ break;
+ case QE_CLK23:
+ clock_bits = 4;
+ break;
+ case QE_CLK24:
+ clock_bits = 5;
+ break;
+ case QE_CLK12:
+ clock_bits = 6;
+ break;
+ case QE_CLK17:
+ clock_bits = 7;
+ break;
+ default:
+ break;
+ }
+ shift = 12;
+ break;
+ case 5:
+ switch (clock) {
+ case QE_BRG12:
+ clock_bits = 1;
+ break;
+ case QE_BRG13:
+ clock_bits = 2;
+ break;
+ case QE_CLK23:
+ clock_bits = 4;
+ break;
+ case QE_CLK24:
+ clock_bits = 5;
+ break;
+ case QE_CLK14:
+ clock_bits = 6;
+ break;
+ case QE_CLK19:
+ clock_bits = 7;
+ break;
+ default:
+ break;
+ }
+ shift = 8;
+ break;
+ case 6:
+ switch (clock) {
+ case QE_BRG12:
+ clock_bits = 1;
+ break;
+ case QE_BRG13:
+ clock_bits = 2;
+ break;
+ case QE_CLK23:
+ clock_bits = 4;
+ break;
+ case QE_CLK24:
+ clock_bits = 5;
+ break;
+ case QE_CLK16:
+ clock_bits = 6;
+ break;
+ case QE_CLK21:
+ clock_bits = 7;
+ break;
+ default:
+ break;
+ }
+ shift = 4;
+ break;
+ case 7:
+ switch (clock) {
+ case QE_BRG12:
+ clock_bits = 1;
+ break;
+ case QE_BRG13:
+ clock_bits = 2;
+ break;
+ case QE_CLK23:
+ clock_bits = 4;
+ break;
+ case QE_CLK24:
+ clock_bits = 5;
+ break;
+ case QE_CLK18:
+ clock_bits = 6;
+ break;
+ case QE_CLK3:
+ clock_bits = 7;
+ break;
+ default:
+ break;
+ }
+ shift = 0;
+ break;
+ default:
+ break;
+ }
+ break;
+ default:
+ break;
+ }
+
+ if (!clock_bits)
+ return -ENOENT;
+
+ cmxs1cr = (tdm_num < 4) ? (&qe_mux_reg->cmxsi1cr_l) :
+ (&qe_mux_reg->cmxsi1cr_h);
+
+ clrsetbits_be32(cmxs1cr, QE_CMXUCR_TX_CLK_SRC_MASK << shift,
+ clock_bits << shift);
+
+ return 0;
+}
+
+
+int ucc_set_tdm_rxtx_sync(u32 tdm_num, enum qe_clock clock,
+ enum comm_dir mode)
+{
+ u32 shift, clock_bits;
+ struct qe_mux *qe_mux_reg;
+ int source;
+
+ source = 0;
+ shift = 0;
+ qe_mux_reg = &qe_immr->qmx;
+
+ if ((tdm_num > 7 || tdm_num < 0))
+ return -EINVAL;
+
+ /* The communications direction must be RX or TX */
+ if (!((mode == COMM_DIR_RX) || (mode == COMM_DIR_TX)))
+ return -EINVAL;
+
+ switch (mode) {
+ case COMM_DIR_RX:
+ switch (tdm_num) {
+ case 0:
+ switch (clock) {
+ case QE_RSYNC_PIN:
+ source = 0;
+ break;
+ case QE_BRG9:
+ source = 1;
+ break;
+ case QE_BRG10:
+ source = 2;
+ break;
+ default:
+ source = -1;
+ break;
+ }
+ shift = 30;
+ break;
+ case 1:
+ switch (clock) {
+ case QE_RSYNC_PIN:
+ source = 0;
+ break;
+ case QE_BRG9:
+ source = 1;
+ break;
+ case QE_BRG10:
+ source = 2;
+ break;
+ default:
+ source = -1;
+ break;
+ }
+ shift = 28;
+ break;
+ case 2:
+ switch (clock) {
+ case QE_RSYNC_PIN:
+ source = 0;
+ break;
+ case QE_BRG9:
+ source = 1;
+ break;
+ case QE_BRG11:
+ source = 2;
+ break;
+ default:
+ source = -1;
+ break;
+ }
+ shift = 26;
+ break;
+ case 3:
+ switch (clock) {
+ case QE_RSYNC_PIN:
+ source = 0;
+ break;
+ case QE_BRG9:
+ source = 1;
+ break;
+ case QE_BRG11:
+ source = 2;
+ break;
+ default:
+ source = -1;
+ break;
+ }
+ shift = 24;
+ break;
+ case 4:
+ switch (clock) {
+ case QE_RSYNC_PIN:
+ source = 0;
+ break;
+ case QE_BRG13:
+ source = 1;
+ break;
+ case QE_BRG14:
+ source = 2;
+ break;
+ default:
+ source = -1;
+ break;
+ }
+ shift = 22;
+ break;
+ case 5:
+ switch (clock) {
+ case QE_RSYNC_PIN:
+ source = 0;
+ break;
+ case QE_BRG13:
+ source = 1;
+ break;
+ case QE_BRG14:
+ source = 2;
+ break;
+ default:
+ source = -1;
+ break;
+ }
+ shift = 20;
+ break;
+ case 6:
+ switch (clock) {
+ case QE_RSYNC_PIN:
+ source = 0;
+ break;
+ case QE_BRG13:
+ source = 1;
+ break;
+ case QE_BRG15:
+ source = 2;
+ break;
+ default:
+ source = -1;
+ break;
+ }
+ shift = 18;
+ break;
+ case 7:
+ switch (clock) {
+ case QE_RSYNC_PIN:
+ source = 0;
+ break;
+ case QE_BRG13:
+ source = 1;
+ break;
+ case QE_BRG15:
+ source = 2;
+ break;
+ default:
+ source = -1;
+ break;
+ }
+ shift = 16;
+ break;
+ default:
+ source = -1;
+ break;
+ }
+ break;
+ case COMM_DIR_TX:
+ switch (tdm_num) {
+ case 0:
+ switch (clock) {
+ case QE_TSYNC_PIN:
+ source = 0;
+ break;
+ case QE_BRG9:
+ source = 1;
+ break;
+ case QE_BRG10:
+ source = 2;
+ break;
+ default:
+ source = -1;
+ break;
+ }
+ shift = 14;
+ break;
+ case 1:
+ switch (clock) {
+ case QE_TSYNC_PIN:
+ source = 0;
+ break;
+ case QE_BRG9:
+ source = 1;
+ break;
+ case QE_BRG10:
+ source = 2;
+ break;
+ default:
+ source = -1;
+ break;
+ }
+ shift = 12;
+ break;
+ case 2:
+ switch (clock) {
+ case QE_TSYNC_PIN:
+ source = 0;
+ break;
+ case QE_BRG9:
+ source = 1;
+ break;
+ case QE_BRG11:
+ source = 2;
+ break;
+ default:
+ source = -1;
+ break;
+ }
+ shift = 10;
+ break;
+ case 3:
+ switch (clock) {
+ case QE_TSYNC_PIN:
+ source = 0;
+ break;
+ case QE_BRG9:
+ source = 1;
+ break;
+ case QE_BRG11:
+ source = 2;
+ break;
+ default:
+ source = -1;
+ break;
+ }
+ shift = 8;
+ break;
+ case 4:
+ switch (clock) {
+ case QE_TSYNC_PIN:
+ source = 0;
+ break;
+ case QE_BRG13:
+ source = 1;
+ break;
+ case QE_BRG14:
+ source = 2;
+ break;
+ default:
+ source = -1;
+ break;
+ }
+ shift = 6;
+ break;
+ case 5:
+ switch (clock) {
+ case QE_TSYNC_PIN:
+ source = 0;
+ break;
+ case QE_BRG13:
+ source = 1;
+ break;
+ case QE_BRG14:
+ source = 2;
+ break;
+ default:
+ source = -1;
+ break;
+ }
+ shift = 4;
+ break;
+ case 6:
+ switch (clock) {
+ case QE_TSYNC_PIN:
+ source = 0;
+ break;
+ case QE_BRG13:
+ source = 1;
+ break;
+ case QE_BRG15:
+ source = 2;
+ break;
+ default:
+ source = -1;
+ break;
+ }
+ shift = 2;
+ break;
+ case 7:
+ switch (clock) {
+ case QE_TSYNC_PIN:
+ source = 0;
+ break;
+ case QE_BRG13:
+ source = 1;
+ break;
+ case QE_BRG15:
+ source = 2;
+ break;
+ default:
+ source = -1;
+ break;
+ }
+ shift = 0;
+ break;
+
+ default:
+ source = -1;
+ break;
+ }
+ break;
+ default:
+ source = -1;
+ break;
+ }
+
+ if (source == -1)
+ return -ENOENT;
+
+ clock_bits = (u32) source;
+
+ clrsetbits_be32(&qe_mux_reg->cmxsi1syr,
+ QE_CMXUCR_TX_CLK_SRC_MASK << shift,
+ clock_bits << shift);
+
+ return 0;
+}
diff --git a/arch/powerpc/sysdev/qe_lib/ucc_fast.c b/arch/powerpc/sysdev/qe_lib/ucc_fast.c
index 65aaf15..16b88d6 100644
--- a/arch/powerpc/sysdev/qe_lib/ucc_fast.c
+++ b/arch/powerpc/sysdev/qe_lib/ucc_fast.c
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2006 Freescale Semiconductor, Inc. All rights reserved.
+ * Copyright (C) 2006, 2014 Freescale Semiconductor, Inc. All rights reserved.
*
* Authors: Shlomi Gridish <gridish@freescale.com>
* Li Yang <leoli@freescale.com>
@@ -327,6 +327,44 @@ int ucc_fast_init(struct ucc_fast_info * uf_info, struct ucc_fast_private ** ucc
ucc_fast_free(uccf);
return -EINVAL;
}
+#ifdef CONFIG_FSL_UCC_TDM
+ } else {
+ /* tdm Rx clock routing */
+ if ((uf_info->rx_clock != QE_CLK_NONE) &&
+ ucc_set_tdm_rxtx_clk(uf_info->tdm_num,
+ uf_info->rx_clock, COMM_DIR_RX)) {
+ pr_err("%s: illegal value for RX clock", __func__);
+ ucc_fast_free(uccf);
+ return -EINVAL;
+ }
+
+ /* tdm Tx clock routing */
+ if ((uf_info->tx_clock != QE_CLK_NONE) &&
+ ucc_set_tdm_rxtx_clk(uf_info->tdm_num,
+ uf_info->tx_clock, COMM_DIR_TX)) {
+ pr_err("%s:illegal value for TX clock", __func__);
+ ucc_fast_free(uccf);
+ return -EINVAL;
+ }
+
+ /* tdm Rx sync clock routing */
+ if ((uf_info->rx_sync != QE_CLK_NONE) &&
+ ucc_set_tdm_rxtx_sync(uf_info->tdm_num,
+ uf_info->rx_sync, COMM_DIR_RX)) {
+ pr_err("%s:illegal value for TX clock", __func__);
+ ucc_fast_free(uccf);
+ return -EINVAL;
+ }
+
+ /* tdm Tx sync clock routing */
+ if ((uf_info->tx_sync != QE_CLK_NONE) &&
+ ucc_set_tdm_rxtx_sync(uf_info->tdm_num,
+ uf_info->tx_sync, COMM_DIR_TX)) {
+ pr_err("%s:illegal value for TX clock", __func__);
+ ucc_fast_free(uccf);
+ return -EINVAL;
+ }
+#endif
}
/* Set interrupt mask register at UCC level. */
--
1.8.4
^ permalink raw reply related
* [PATCH] fix dmaengine_unmap failure.
From: xuelin.shi @ 2014-03-18 8:32 UTC (permalink / raw)
To: vinod.koul, dan.j.williams, linuxppc-dev; +Cc: dmaengine, Xuelin Shi
From: Xuelin Shi <xuelin.shi@freescale.com>
The count which is used to get_unmap_data maybe not the same as the
count computed in dmaengine_unmap which causes to free data in a
wrong pool.
This patch fixes this issue by keeping the pool in unmap_data
structure.
Signed-off-by: Xuelin Shi <xuelin.shi@freescale.com>
---
drivers/dma/dmaengine.c | 7 +++++--
include/linux/dmaengine.h | 1 +
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index ed610b4..2977eee 100644
--- a/drivers/dma/dmaengine.c
+++ b/drivers/dma/dmaengine.c
@@ -1014,7 +1014,7 @@ static void dmaengine_unmap(struct kref *kref)
dma_unmap_page(dev, unmap->addr[i], unmap->len,
DMA_BIDIRECTIONAL);
}
- mempool_free(unmap, __get_unmap_pool(cnt)->pool);
+ mempool_free(unmap, unmap->unmap_pool->pool);
}
void dmaengine_unmap_put(struct dmaengine_unmap_data *unmap)
@@ -1071,14 +1071,17 @@ struct dmaengine_unmap_data *
dmaengine_get_unmap_data(struct device *dev, int nr, gfp_t flags)
{
struct dmaengine_unmap_data *unmap;
+ struct dmaengine_unmap_pool *unmap_pool;
- unmap = mempool_alloc(__get_unmap_pool(nr)->pool, flags);
+ unmap_pool = __get_unmap_pool(nr);
+ unmap = mempool_alloc(unmap_pool->pool, flags);
if (!unmap)
return NULL;
memset(unmap, 0, sizeof(*unmap));
kref_init(&unmap->kref);
unmap->dev = dev;
+ unmap->unmap_pool = unmap_pool;
return unmap;
}
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index c5c92d5..6a25635 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -439,6 +439,7 @@ struct dmaengine_unmap_data {
struct device *dev;
struct kref kref;
size_t len;
+ struct dmaengine_unmap_pool *unmap_pool;
dma_addr_t addr[0];
};
--
1.8.3.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