* Re: [PATCH 1/1] powerpc: Increase COMMAND_LINE_SIZE to 2048 from 512.
From: Joseph Salisbury @ 2014-04-16 18:00 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, paulus, linux-kernel, stable, anton
In-Reply-To: <1397555363.14218.6.camel@pasglop>
On 04/15/2014 05:49 AM, Benjamin Herrenschmidt wrote:
> On Mon, 2014-04-14 at 14:58 -0400, Joseph Salisbury wrote:
>> After further review, it appears ppc does not actually use the define
>> in
>> the ppc headers but uses the common generic
>> default(include/uapi/asm-generic/setup.h). COMMAND_LINE_SIZE should
>> probably become a kernel config option. Do folks agree that is the
>> correct thing to do? If so, I can re-work the patch.
> No objection on my side.
>
> Make sure you remove any unused arch define while at it.
>
> Cheers,
> Ben.
>
>
Hi Ben,
I can think of two ways to add the new config option. One would be to
have a large entry in ~/arch/Kconfig, with a default COMMAND_LINE_SIZE
line for each architecture. The other way would be to have the default
value for COMMAND_LINE_SIZE in the architecture sub-directory Kconfig
file: ~/arch/powerpc/Kconfig for example.
Do you have a preference for either way?
Thanks,
Joe
^ permalink raw reply
* Re: [PATCH v2 1/2] fsl/corenet_generic: add a particular initialization for platform
From: Scott Wood @ 2014-04-16 19:36 UTC (permalink / raw)
To: Wang Dongsheng-B40534
Cc: linuxppc-dev@lists.ozlabs.org, haokexin@gmail.com,
Kushwaha Prabhakar-B32579, Jin Zhengxiong-R64188
In-Reply-To: <77e2c53b2f154faba68c8b7ac760accc@BN1PR03MB188.namprd03.prod.outlook.com>
On Tue, 2014-04-15 at 21:58 -0500, Wang Dongsheng-B40534 wrote:
>
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Wednesday, April 16, 2014 3:39 AM
> > To: Wang Dongsheng-B40534
> > Cc: Jin Zhengxiong-R64188; haokexin@gmail.com; Kushwaha Prabhakar-B32579;
> > linuxppc-dev@lists.ozlabs.org
> > Subject: Re: [PATCH v2 1/2] fsl/corenet_generic: add a particular initialization
> > for platform
> >
> > On Tue, 2014-04-15 at 13:53 +0800, Dongsheng Wang wrote:
> > > From: Wang Dongsheng <dongsheng.wang@freescale.com>
> > >
> > > Corenet_generic is a generic platform initialization. Those based on
> > > the corenet_generic board maybe need a particular initialize to
> > > enable/set some IP-Blocks. So add "Fix Generic Initialization" to solve
> > > this kind of special cases.
> >
> > I still don't understand what you mean by "fix". What are you fixing,
> > or what is fixed?
> >
> > There is no need for adding an infrastructure layer here. Just add a
> > new piece of code for t104x diu, and have it be called by an appropriate
> > initfunc.
> >
>
> "fix" is means to handle some boards those based on corenet_generic config file,
> But those boards may need some special handle. Perhaps these used to handle
> special feature codes not have an appropriate initfunc we cannot *just find*
> an appropriate place,
I'm not asking you to "just find" anything. I'm asking you to add an
initfunc in a standalone file.
> if more and more boards need to do this, at that time maybe *initfunc*
> looks very complicated.
They would each have their own initfunc. There is no reason to tie this
in with anything else.
> > > --- a/arch/powerpc/platforms/85xx/Kconfig
> > > +++ b/arch/powerpc/platforms/85xx/Kconfig
> > > @@ -269,6 +269,17 @@ config CORENET_GENERIC
> > > The following boards are supported for both 32bit and 64bit kernel:
> > > P5020 DS and P5040 DS
> > >
> > > +config FIX_GENERIC_PLATFORM_INIT
> > > + bool "Fix Generic Initialization"
> > > + depends on CORENET_GENERIC
> >
> > Why does this depend on CORENET_GENERIC?
> >
>
> Because CORENET_GENERIC is a multiboards file, This is designed to handle this situation.
This DIU code is going to be just as applicable to a custom T104x board
which may or may not use CORENET_GENERIC.
> > > + default y
> >
> > No.
> >
>
> Why not? This will not increase any redundant operations if there is not any boards need fix.
> You can see my fix.c code.
default y should not be used for hardware specific code.
-Scott
^ permalink raw reply
* Re: [PATCH RFC v11 5/6] dma: mpc512x: add device tree binding document
From: Gerhard Sittig @ 2014-04-16 20:44 UTC (permalink / raw)
To: Alexander Popov
Cc: devicetree, Lars-Peter Clausen, Anatolij Gustschin, Arnd Bergmann,
Vinod Koul, dmaengine, Dan Williams, Andy Shevchenko,
linuxppc-dev
In-Reply-To: <1397559250-17680-6-git-send-email-a13xp0p0v88@gmail.com>
On Tue, 2014-04-15 at 14:54 +0400, Alexander Popov wrote:
>
> Introduce a device tree binding document for the MPC512x DMA controller
>
> Signed-off-by: Gerhard Sittig <gsi@denx.de>
> Signed-off-by: Alexander Popov <a13xp0p0v88@gmail.com>
I'm not certain whether the attribution is right. Is the S-o-b
appropriate when the patch is not "from" me? As I've stated
before, it's OK if you pick up and extend what I provide, but
please don't pretend that I wrote what you did, and don't pretend
that I ACKed or passed along your submission when I didn't.
This binding certainly needs further improvement to become a good
one. As I've communicated in the past, I was rather ignorant
"back then" when I wrote v1 and v2 of the RFC. We have learned
something in the meantime. Though I admit having gone silent
after several review iterations. Assumed you would pick up
information that showed up several times on public lists.
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dma/mpc512x-dma.txt
> @@ -0,0 +1,51 @@
> +* Freescale MPC512x and MPC8308 DMA Controller
> +
> +The DMA controller in the Freescale MPC512x and MPC8308 SoCs can move
> +blocks of memory contents between memory and peripherals or
> +from memory to memory.
> +
> +Refer to the "Generic DMA Controller and DMA request bindings" in
> +the dma/dma.txt file for a more detailed description of binding.
> +
> +* DMA controller
> +
> +Required properties:
> +- compatible: Should be one of
> + "fsl,mpc5121-dma"
> + "fsl,mpc8308-dma", "fsl,mpc5121-dma"
is this a duplicate? looks funny, needs a fix
or is it a requirement that for MPC8308 you need to provide both
compatible strings? that would be wrong, as MPC8308 certainly is
not an MPC5121
a quick search reveals: the drivers/dma/mpc512x_dma.c Linux
driver implementation is wrong, it should match on both strings;
expecting the MPC8308 to disguise as an MPC5121 when it's not is
inappropriate (and only went unnoticed because of missing
bindings, I guess)
> +- reg: Address and size of the DMA controller's register set
> +- interrupts: Interrupt for the DMA controller. Generic interrupt client node
> + is described in interrupt-controller/interrupts.txt
'interrupts' only works in combinations with 'interrupt-parent',
that actual .dts files don't have the latter in the nodes is an
implementation detail but not a binding's requirement
and an alternative method of specifying interrupts was introduced
recently, a reference to the common binding without naming one
specific property name could be most appropriate
> +
> +Optional properties:
> +- #dma-cells: The length of the DMA specifier, must be <1> since
> + the DMA controller uses a fixed assignment of request lines
> + per channel. Refer to dma/dma.txt for the detailed description
> + of this property
I'm afraid that a generic/common document does not and cannot
describe the specific semantics of this provider's cells
this binding should explicitly mention that the number of cells
needs to be one, and that this one cell is the DMA channel (which
translates to "peripheral request line"), because these
assigments are fixed in hardware
> +
> +Example:
> +
> + dma0: dma@14000 {
> + compatible = "fsl,mpc5121-dma";
> + reg = <0x14000 0x1800>;
> + interrupts = <65 0x8>;
> + #dma-cells = <1>;
> + };
> +
> +* DMA client
the DMA provider's binding probably need not discuss client
specs, a reference to the common binding should suffice if it's
appropriate at all
virtually yours
Gerhard Sittig
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
^ permalink raw reply
* Re: [PATCH] powerpc/mm: Fix ".__node_distance" undefined
From: Mike Qiu @ 2014-04-17 3:10 UTC (permalink / raw)
To: Mike Qiu
Cc: sfr, jlarrew, paulus, srivatsa.bhat, alistair, nfont, akpm, rcj,
linuxppc-dev
In-Reply-To: <1397570417-1714-1-git-send-email-qiudayu@linux.vnet.ibm.com>
Any update about this patch ?
Thanks
Mike
On 04/15/2014 10:00 PM, Mike Qiu wrote:
> CHK include/config/kernel.release
> CHK include/generated/uapi/linux/version.h
> CHK include/generated/utsrelease.h
> ...
> Building modules, stage 2.
> WARNING: 1 bad relocations
> c0000000013d6a30 R_PPC64_ADDR64 uprobes_fetch_type_table
> WRAP arch/powerpc/boot/zImage.pseries
> WRAP arch/powerpc/boot/zImage.epapr
> MODPOST 1849 modules
> ERROR: ".__node_distance" [drivers/block/nvme.ko] undefined!
> make[1]: *** [__modpost] Error 1
> make: *** [modules] Error 2
> make: *** Waiting for unfinished jobs....
>
> The reason is symbol "__node_distance" not been exported in powerpc.
>
> Signed-off-by: Mike Qiu <qiudayu@linux.vnet.ibm.com>
> ---
> arch/powerpc/mm/numa.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
> index 4ebbb9e..3b181b2 100644
> --- a/arch/powerpc/mm/numa.c
> +++ b/arch/powerpc/mm/numa.c
> @@ -232,6 +232,7 @@ int __node_distance(int a, int b)
>
> return distance;
> }
> +EXPORT_SYMBOL(__node_distance);
>
> static void initialize_distance_lookup_table(int nid,
> const __be32 *associativity)
^ permalink raw reply
* Powerpc: e1000e cannot work normally after system resume from sleep(standby)
From: Dongsheng.Wang @ 2014-04-17 7:00 UTC (permalink / raw)
To: linuxppc-dev@lists.ozlabs.org, linux-pci@vger.kernel.org,
netdev@vger.kernel.org, linux-pm@vger.kernel.org,
linux-kernel@vger.kernel.org
Hi all,
Now I'm developing Freescale PCIe power management feature. The following i=
s my PCIe
suspend/resume code.
when I test system wake up from sleep(STANDBY), I got below calltrace. Look=
s like e1000e
cannot transfer data, maybe watchdog has some issue. Or maybe some of the o=
ther causes.
I think this is not root cause. Because If changed mdelay(10) to 20ms. E100=
0 will work normal.
Maybe e1000e need more time to recover? Or ?
Here are my test results:
E1000e plug in PCIe slot 1, we need to delay 10ms.
E1000e plug in PCIe slot 2, we need to delay 20ms.
E1000e plug in PCIe slot 3, we need to delay 60ms.
Anyone have any idea about this?
*Suspend flow*:=20
if (fsl_pcie_check_link(hose))
return;
/* Send PME_Turn_Off Message Request */
setbits32(&pci->pex_pmcr, PEX_PMCR_PTOMR);
/* Wait trun off done */
/* RC will get this detect quickly */
for (i =3D 0; i < 50; i++) {
dr =3D in_be32(&pci->pex_pme_mes_dr);
if (dr & ENL23_DETECT_BIT) {
out_be32(&pci->pex_pme_mes_dr, dr);
break;
}
udelay(1000);
}
/*
* "PCI Bus Power Management Interface Specification" define
* Minimum System Software Guaranteed Delays
*
* D0, D1 or D2 --> D3, need delay 10ms.
* But we need to delay more time when EP plug in p1022 slot2.
*/
mdelay(10);
*Resume flow*:
if (fsl_pcie_check_link(hose))
return;
/* Send Exit L2 State Message */
setbits32(&pci->pex_pmcr, PEX_PMCR_EXL2S);
/* Wait exit done */
/* RC will get this detect quickly */
for (i =3D 0; i < 50; i++) {
dr =3D in_be32(&pci->pex_pme_mes_dr);
if (dr & EXL23_DETECT_BIT) {
out_be32(&pci->pex_pme_mes_dr, dr);
break;
}
udelay(1000);
}
/*
* "PCI Bus Power Management Interface Specification" define
* Minimum System Software Guaranteed Delays
*
* D3 hot --> D0, need delay 10ms.
* But we need to delay more time when EP plug in p1022 slot2.
*/
mdelay(10);
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
CALL TRACE
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
[root@p1022 /root]# udhcpc -i eth0
udhcpc (v1.11.2) started
IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
Sending discover...
e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Sending discover...
Sending discover...
NETDEV WATCHDOG: eth0 (e1000e): transmit queue 0 timed out
------------[ cut here ]------------
WARNING: at net/sched/sch_generic.c:264
Modules linked in:
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.14.0-173871-g9964256-dirty #42
task: ee0534e0 ti: ee070000 task.ti: ee070000
NIP: c036267c LR: c036267c CTR: c028b834
REGS: ee071d00 TRAP: 0700 Not tainted (3.14.0-173871-g9964256-dirty)
MSR: 00029000 <CE,EE,ME> CR: 42000022 XER: 20000000
GPR00: c036267c ee071db0 ee0534e0 0000003a c16393b0 c16398e8 01079000 c05c0=
3a8
GPR08: 00000001 00000001 01079000 00000132 00000132 00000000 00000004 c05ed=
040
GPR16: 00000001 00000100 00000004 fffef539 00000000 c05c10c0 00000038 fffff=
fff
GPR24: 00000000 00000001 ee070000 00000004 c05e0000 c05f0000 ee3c0000 00000=
000
NIP [c036267c] dev_watchdog+0x2c8/0x2d8
LR [c036267c] dev_watchdog+0x2c8/0x2d8
Call Trace:
[ee071db0] [c036267c] dev_watchdog+0x2c8/0x2d8 (unreliable)
[ee071de0] [c004778c] call_timer_fn.isra.24+0x28/0x84
[ee071e00] [c00479b8] run_timer_softirq+0x1d0/0x248
[ee071e40] [c004090c] __do_softirq+0x104/0x20c
[ee071ea0] [c0040cd8] irq_exit+0xa4/0xc8
[ee071eb0] [c0009ef4] timer_interrupt+0xb8/0xdc
[ee071ed0] [c000f57c] ret_from_except+0x0/0x18
--- Exception: 901 at arch_cpu_idle+0x24/0x5c
LR =3D arch_cpu_idle+0x24/0x5c
[ee071f90] [c0089534] rcu_idle_enter+0xa4/0xd0 (unreliable)
[ee071fa0] [c0076010] cpu_startup_entry+0x120/0x17c
[ee071fd0] [c0010bbc] start_secondary+0x214/0x224
[ee071ff0] [c0002154] __secondary_start+0x7c/0xc8
Instruction dump:
4e800421 80fe0224 4bffff4c 7fc3f378 4bfe5401 7fc4f378 7c651b78 3c60c055
7fe6fb78 3863e0f4 4cc63182 480e9a05 <0fe00000> 39200001 993c6f38 4bffffb4
---[ end trace 2d4f2cedfa86e32f ]---
e1000e 0002:05:00.0: Net device Info
e1000e: Device Name state trans_start last_rx
e1000e: eth0 0000000000000003 00000000FFFEF040 0000000000000000
e1000e 0002:05:00.0: Register Dump
e1000e: Register Name Value
e1000e: CTRL 58100248
e1000e: STATUS 00080783
e1000e: CTRL_EXT 18580000
e1000e: ICR 00000000
e1000e: RCTL 04008002
e1000e: RDLEN 00001000
e1000e: RDH 0000001d
e1000e: RDT 000000f0
e1000e: RDTR 00000020
e1000e: RXDCTL[0-1] 01040420 01040420
e1000e: ERT 00000000
e1000e: RDBAL 2d390000
e1000e: RDBAH 00000000
e1000e: RDFH 0000020a
e1000e: RDFT 0000020a
e1000e: RDFHS 0000020a
e1000e: RDFTS 0000020a
e1000e: RDFPC 00000000
e1000e: TCTL 3103f0fa
e1000e: TDBAL 2e158000
e1000e: TDBAH 00000000
e1000e: TDLEN 00001000
e1000e: TDH 00000001
e1000e: TDT 00000001
e1000e: TIDV 00000008
e1000e: TXDCTL[0-1] 0141011f 0141011f
e1000e: TADV 00000020
e1000e: TARC[0-1] 04000403 00000403
e1000e: TDFH 00001000
e1000e: TDFT 00001012
e1000e: TDFHS 00001000
e1000e: TDFTS 00001000
e1000e: TDFPC 00000000
e1000e 0002:05:00.0: Tx Ring Summary
e1000e: Queue [NTU] [NTC] [bi(ntc)->dma ] leng ntw timestamp
e1000e: 0 1 0 000000002C809802 005A 0 00000000FFFEF044
e1000e 0002:05:00.0: Rx Ring Summary
e1000e: Queue [NTU] [NTC]
e1000e: 0 FF 0
e1000e 0002:05:00.0 eth0: Reset adapter unexpectedly
^ permalink raw reply
* [PATCH 0/5] defconfigs: add MTD_SPI_NOR (dependency for M25P80)
From: Brian Norris @ 2014-04-17 7:21 UTC (permalink / raw)
To: Linux Kernel
Cc: Marek Vasut, linux-mips, Russell King, Stephen Warren, linux-sh,
Steven Miao, adi-buildroot-devel, Ralf Baechle, linux-tegra,
Thierry Reding, linux-mtd, linux-arm-kernel, Sascha Hauer,
Olof Johansson, Paul Mackerras, Brian Norris, linuxppc-dev,
Shawn Guo
Hi all,
We are introducing a new SPI-NOR library/framework for MTD, to support various
types of SPI-NOR flash controllers which require (or benefit from) intimate
knowledge of the flash interface, rather than just the relatively dumb SPI
interface. This library borrows much of the m25p80 driver for its abstraction
and moves this code into a spi-nor module.
This means CONFIG_M25P80 now has a dependency on CONFIG_MTD_SPI_NOR, which
should be added to the defconfigs. I'm not sure what is the best process for
doing this. Should each $ARCH maintainer just take their respective patch, even
if the MTD_SPI_NOR Kconfig symbol is not defined for them yet? Or should
maintainers plan on merging the relevant SPI-NOR code into their trees during
the development cycle? Or some third option?
Anyway, the patches are here. Please keep general comments to the cover letter,
so all parties can see.
This series is based on the development repo for MTD, in the 'spinor' branch:
git://git.infradead.org/l2-mtd.git +spinor
This series is available in the same repo at:
git://git.infradead.org/l2-mtd.git +defconfigs
I tried locally merging this into linux-next and saw a trivial conflict in
arch/arm/configs/shmobile_defconfig. I can resubmit based on an appropriate
tree, if requested.
Thanks,
Brian
P.S. I was going to purely automatically generate this diff as follows, but
it generated a lot of defconfig noise:
#!/bin/sh
for i in arm blackfin mips powerpc sh
do
for j in `git grep -l M25P80 arch/$i/configs`
do
echo $j
cp $j .config
echo CONFIG_MTD_SPI_NOR=y >> .config
make ARCH=$i savedefconfig
mv defconfig $j
done
done
So I did a mixed approach, where I filtered most of the noise out of the diff.
Brian Norris (5):
ARM: defconfigs: add MTD_SPI_NOR (new dependency for M25P80)
blackfin: defconfigs: add MTD_SPI_NOR (new dependency for M25P80)
mips: defconfigs: add MTD_SPI_NOR (new dependency for M25P80)
powerpc: defconfigs: add MTD_SPI_NOR (new dependency for M25P80)
sh: defconfig: add MTD_SPI_NOR (new dependency for M25P80)
arch/arm/configs/bockw_defconfig | 2 +-
arch/arm/configs/dove_defconfig | 2 +-
arch/arm/configs/imx_v6_v7_defconfig | 1 +
arch/arm/configs/keystone_defconfig | 1 +
arch/arm/configs/kirkwood_defconfig | 1 +
arch/arm/configs/koelsch_defconfig | 1 +
arch/arm/configs/lager_defconfig | 1 +
arch/arm/configs/lpc32xx_defconfig | 2 +-
arch/arm/configs/multi_v5_defconfig | 1 +
arch/arm/configs/multi_v7_defconfig | 1 +
arch/arm/configs/mvebu_v5_defconfig | 1 +
arch/arm/configs/mvebu_v7_defconfig | 1 +
arch/arm/configs/mxs_defconfig | 1 +
arch/arm/configs/sama5_defconfig | 2 +-
arch/arm/configs/shmobile_defconfig | 1 +
arch/arm/configs/tegra_defconfig | 1 +
arch/blackfin/configs/BF526-EZBRD_defconfig | 2 +-
arch/blackfin/configs/BF527-EZKIT-V2_defconfig | 2 +-
arch/blackfin/configs/BF527-EZKIT_defconfig | 2 +-
arch/blackfin/configs/BF548-EZKIT_defconfig | 2 +-
arch/blackfin/configs/BF609-EZKIT_defconfig | 2 +-
arch/blackfin/configs/BlackStamp_defconfig | 3 +--
arch/blackfin/configs/H8606_defconfig | 3 +--
arch/mips/configs/ath79_defconfig | 3 +--
arch/mips/configs/db1xxx_defconfig | 1 +
arch/mips/configs/rt305x_defconfig | 2 +-
arch/powerpc/configs/corenet32_smp_defconfig | 2 +-
arch/powerpc/configs/corenet64_smp_defconfig | 2 +-
arch/powerpc/configs/mpc85xx_defconfig | 2 +-
arch/powerpc/configs/mpc85xx_smp_defconfig | 2 +-
arch/sh/configs/sh7757lcr_defconfig | 2 +-
31 files changed, 31 insertions(+), 21 deletions(-)
--
1.8.3.2
^ permalink raw reply
* [PATCH 4/5] powerpc: defconfigs: add MTD_SPI_NOR (new dependency for M25P80)
From: Brian Norris @ 2014-04-17 7:21 UTC (permalink / raw)
To: Linux Kernel
Cc: Marek Vasut, linux-mtd, Paul Mackerras, Brian Norris,
linuxppc-dev
In-Reply-To: <1397719309-2022-1-git-send-email-computersforpeace@gmail.com>
These defconfigs contain the CONFIG_M25P80 symbol, which is now
dependent on the MTD_SPI_NOR symbol. Add CONFIG_MTD_SPI_NOR to the
relevant defconfigs.
At the same time, drop the now-nonexistent CONFIG_MTD_CHAR symbol.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-kernel@vger.kernel.org
---
This change is based on l2-mtd.git/spinor, which is based on 3.15-rc1:
git://git.infradead.org/l2-mtd.git +spinor
arch/powerpc/configs/corenet32_smp_defconfig | 2 +-
arch/powerpc/configs/corenet64_smp_defconfig | 2 +-
arch/powerpc/configs/mpc85xx_defconfig | 2 +-
arch/powerpc/configs/mpc85xx_smp_defconfig | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/configs/corenet32_smp_defconfig b/arch/powerpc/configs/corenet32_smp_defconfig
index bbd794deb6eb..fceaa893d37c 100644
--- a/arch/powerpc/configs/corenet32_smp_defconfig
+++ b/arch/powerpc/configs/corenet32_smp_defconfig
@@ -69,7 +69,6 @@ CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_MTD=y
CONFIG_MTD_CMDLINE_PARTS=y
-CONFIG_MTD_CHAR=y
CONFIG_MTD_BLOCK=y
CONFIG_MTD_CFI=y
CONFIG_MTD_CFI_AMDSTD=y
@@ -78,6 +77,7 @@ CONFIG_MTD_M25P80=y
CONFIG_MTD_NAND=y
CONFIG_MTD_NAND_FSL_ELBC=y
CONFIG_MTD_NAND_FSL_IFC=y
+CONFIG_MTD_SPI_NOR=y
CONFIG_PROC_DEVICETREE=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_RAM=y
diff --git a/arch/powerpc/configs/corenet64_smp_defconfig b/arch/powerpc/configs/corenet64_smp_defconfig
index 5c7fa19ae4ef..9c8d58a50df2 100644
--- a/arch/powerpc/configs/corenet64_smp_defconfig
+++ b/arch/powerpc/configs/corenet64_smp_defconfig
@@ -61,7 +61,6 @@ CONFIG_DEVTMPFS_MOUNT=y
CONFIG_MTD=y
CONFIG_MTD_OF_PARTS=y
CONFIG_MTD_CMDLINE_PARTS=y
-CONFIG_MTD_CHAR=y
CONFIG_MTD_BLKDEVS=y
CONFIG_MTD_BLOCK=y
CONFIG_FTL=y
@@ -82,6 +81,7 @@ CONFIG_MTD_NAND=y
CONFIG_MTD_NAND_IDS=y
CONFIG_MTD_NAND_FSL_ELBC=y
CONFIG_MTD_NAND_FSL_IFC=y
+CONFIG_MTD_SPI_NOR=y
CONFIG_MTD_UBI=y
CONFIG_MTD_UBI_WL_THRESHOLD=4096
CONFIG_MTD_UBI_BEB_RESERVE=1
diff --git a/arch/powerpc/configs/mpc85xx_defconfig b/arch/powerpc/configs/mpc85xx_defconfig
index 19f0fbe5ba4b..33d9c8aef4eb 100644
--- a/arch/powerpc/configs/mpc85xx_defconfig
+++ b/arch/powerpc/configs/mpc85xx_defconfig
@@ -83,7 +83,6 @@ CONFIG_DEVTMPFS_MOUNT=y
CONFIG_MTD=y
CONFIG_MTD_OF_PARTS=y
CONFIG_MTD_CMDLINE_PARTS=y
-CONFIG_MTD_CHAR=y
CONFIG_MTD_BLKDEVS=y
CONFIG_MTD_BLOCK=y
CONFIG_FTL=y
@@ -104,6 +103,7 @@ CONFIG_MTD_NAND=y
CONFIG_MTD_NAND_IDS=y
CONFIG_MTD_NAND_FSL_ELBC=y
CONFIG_MTD_NAND_FSL_IFC=y
+CONFIG_MTD_SPI_NOR=y
CONFIG_MTD_UBI=y
CONFIG_MTD_UBI_WL_THRESHOLD=4096
CONFIG_MTD_UBI_BEB_RESERVE=1
diff --git a/arch/powerpc/configs/mpc85xx_smp_defconfig b/arch/powerpc/configs/mpc85xx_smp_defconfig
index 062312e1fe1a..25174f9a6615 100644
--- a/arch/powerpc/configs/mpc85xx_smp_defconfig
+++ b/arch/powerpc/configs/mpc85xx_smp_defconfig
@@ -86,7 +86,6 @@ CONFIG_DEVTMPFS_MOUNT=y
CONFIG_MTD=y
CONFIG_MTD_OF_PARTS=y
CONFIG_MTD_CMDLINE_PARTS=y
-CONFIG_MTD_CHAR=y
CONFIG_MTD_BLKDEVS=y
CONFIG_MTD_BLOCK=y
CONFIG_FTL=y
@@ -107,6 +106,7 @@ CONFIG_MTD_NAND=y
CONFIG_MTD_NAND_IDS=y
CONFIG_MTD_NAND_FSL_ELBC=y
CONFIG_MTD_NAND_FSL_IFC=y
+CONFIG_MTD_SPI_NOR=y
CONFIG_MTD_UBI=y
CONFIG_MTD_UBI_WL_THRESHOLD=4096
CONFIG_MTD_UBI_BEB_RESERVE=1
--
1.8.3.2
^ permalink raw reply related
* [PATCH 1/3] cpufreq: ppc: Add missing #include <asm/smp.h>
From: Geert Uytterhoeven @ 2014-04-17 9:53 UTC (permalink / raw)
To: Rafael J. Wysocki, Viresh Kumar
Cc: Geert Uytterhoeven, linuxppc-dev, linux-kernel, cpufreq, linux-pm
If CONFIG_SMP=n, <linux/smp.h> does not include <asm/smp.h>, causing:
drivers/cpufreq/ppc-corenet-cpufreq.c: In function 'corenet_cpufreq_cpu_init':
drivers/cpufreq/ppc-corenet-cpufreq.c:173:3: error: implicit declaration of function 'get_hard_smp_processor_id' [-Werror=implicit-function-declaration]
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
drivers/cpufreq/ppc-corenet-cpufreq.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/cpufreq/ppc-corenet-cpufreq.c b/drivers/cpufreq/ppc-corenet-cpufreq.c
index b7e677be1df0..e78f9c806de4 100644
--- a/drivers/cpufreq/ppc-corenet-cpufreq.c
+++ b/drivers/cpufreq/ppc-corenet-cpufreq.c
@@ -22,6 +22,8 @@
#include <linux/smp.h>
#include <sysdev/fsl_soc.h>
+#include <asm/smp.h>
+
/**
* struct cpu_data - per CPU data struct
* @parent: the parent node of cpu clock
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/3] cpufreq: ppc: Fix integer overflow in expression
From: Geert Uytterhoeven @ 2014-04-17 9:53 UTC (permalink / raw)
To: Rafael J. Wysocki, Viresh Kumar
Cc: Geert Uytterhoeven, linuxppc-dev, linux-kernel, cpufreq, linux-pm
In-Reply-To: <1397728407-13909-1-git-send-email-geert+renesas@glider.be>
On 32-bit, "12 * NSEC_PER_SEC" doesn't fit in "unsigned long"
(NSEC_PER_SEC is a "long" constant), causing an integer overflow:
drivers/cpufreq/ppc-corenet-cpufreq.c: In function 'corenet_cpufreq_cpu_init':
drivers/cpufreq/ppc-corenet-cpufreq.c:211:9: warning: integer overflow in expression [-Woverflow]
Force the intermediate to be 64-bit by adding an "ULL" suffix to the
constant multiplier to fix this.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
drivers/cpufreq/ppc-corenet-cpufreq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/cpufreq/ppc-corenet-cpufreq.c b/drivers/cpufreq/ppc-corenet-cpufreq.c
index e78f9c806de4..53881d78a931 100644
--- a/drivers/cpufreq/ppc-corenet-cpufreq.c
+++ b/drivers/cpufreq/ppc-corenet-cpufreq.c
@@ -208,7 +208,7 @@ static int corenet_cpufreq_cpu_init(struct cpufreq_policy *policy)
per_cpu(cpu_data, i) = data;
policy->cpuinfo.transition_latency =
- (12 * NSEC_PER_SEC) / fsl_get_sys_freq();
+ (12ULL * NSEC_PER_SEC) / fsl_get_sys_freq();
of_node_put(np);
return 0;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 3/3] cpufreq: ppc: Fix handling of non-existent clocks
From: Geert Uytterhoeven @ 2014-04-17 9:53 UTC (permalink / raw)
To: Rafael J. Wysocki, Viresh Kumar
Cc: Geert Uytterhoeven, linuxppc-dev, linux-kernel, cpufreq, linux-pm
In-Reply-To: <1397728407-13909-1-git-send-email-geert+renesas@glider.be>
If the clock doesn't exist, clk_get_rate() returns -EINVAL, which becomes
a large number (freq is u32), failing the "freq < min_cpufreq" test.
Explicitly test for "(u32)-EINVAL" to fix this.
Update the comment, and fix a grammer issue while we're at it.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
drivers/cpufreq/ppc-corenet-cpufreq.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/cpufreq/ppc-corenet-cpufreq.c b/drivers/cpufreq/ppc-corenet-cpufreq.c
index 53881d78a931..7027eab814ce 100644
--- a/drivers/cpufreq/ppc-corenet-cpufreq.c
+++ b/drivers/cpufreq/ppc-corenet-cpufreq.c
@@ -179,10 +179,11 @@ static int corenet_cpufreq_cpu_init(struct cpufreq_policy *policy)
clk = of_clk_get(data->parent, i);
freq = clk_get_rate(clk);
/*
- * the clock is valid if its frequency is not masked
- * and large than minimum allowed frequency.
+ * the clock is valid if it exists, its frequency is not
+ * masked, and larger than minimum allowed frequency.
*/
- if (freq < min_cpufreq || (mask & (1 << i)))
+ if (freq == (u32)-EINVAL || freq < min_cpufreq ||
+ (mask & (1 << i)))
table[i].frequency = CPUFREQ_ENTRY_INVALID;
else
table[i].frequency = freq / 1000;
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH 0/5] defconfigs: add MTD_SPI_NOR (dependency for M25P80)
From: Thierry Reding @ 2014-04-17 10:53 UTC (permalink / raw)
To: Brian Norris
Cc: Marek Vasut, linux-mips, Russell King, Stephen Warren, linux-sh,
Steven Miao, Linux Kernel, Ralf Baechle, adi-buildroot-devel,
linux-tegra, linux-mtd, linux-arm-kernel, Sascha Hauer,
Olof Johansson, Paul Mackerras, linuxppc-dev, Shawn Guo
In-Reply-To: <1397719309-2022-1-git-send-email-computersforpeace@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 702 bytes --]
On Thu, Apr 17, 2014 at 12:21:44AM -0700, Brian Norris wrote:
> Hi all,
>
> We are introducing a new SPI-NOR library/framework for MTD, to support various
> types of SPI-NOR flash controllers which require (or benefit from) intimate
> knowledge of the flash interface, rather than just the relatively dumb SPI
> interface. This library borrows much of the m25p80 driver for its abstraction
> and moves this code into a spi-nor module.
If this is a common library, then the more common approach to solve this
would be to have each driver that uses it to select MTD_SPI_NOR rather
than depend on it. That way you can drop this whole series to update the
default configurations.
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 0/5] defconfigs: add MTD_SPI_NOR (dependency for M25P80)
From: Marek Vasut @ 2014-04-17 11:07 UTC (permalink / raw)
To: Brian Norris
Cc: linux-mips, Russell King, Stephen Warren, linux-sh, Steven Miao,
Linux Kernel, Ralf Baechle, adi-buildroot-devel, linux-tegra,
Thierry Reding, linux-mtd, linux-arm-kernel, Sascha Hauer,
Olof Johansson, Paul Mackerras, linuxppc-dev, Shawn Guo
In-Reply-To: <1397719309-2022-1-git-send-email-computersforpeace@gmail.com>
On Thursday, April 17, 2014 at 09:21:44 AM, Brian Norris wrote:
> Hi all,
>
> We are introducing a new SPI-NOR library/framework for MTD, to support
> various types of SPI-NOR flash controllers which require (or benefit from)
> intimate knowledge of the flash interface, rather than just the relatively
> dumb SPI interface. This library borrows much of the m25p80 driver for its
> abstraction and moves this code into a spi-nor module.
>
> This means CONFIG_M25P80 now has a dependency on CONFIG_MTD_SPI_NOR, which
> should be added to the defconfigs. I'm not sure what is the best process
> for doing this. Should each $ARCH maintainer just take their respective
> patch, even if the MTD_SPI_NOR Kconfig symbol is not defined for them yet?
> Or should maintainers plan on merging the relevant SPI-NOR code into their
> trees during the development cycle? Or some third option?
Shouldn't the M25P80 driver just "select" the SPI NOR framework? Then you won't
need the adjustment to defconfigs at all I think.
Best regards,
Marek Vasut
^ permalink raw reply
* [PATCH 0/3] of: dts: enable memory@0 quirk for PPC32 only
From: Leif Lindholm @ 2014-04-17 17:41 UTC (permalink / raw)
To: linux-kernel
Cc: Mark Rutland, devicetree, linuxppc-dev, Leif Lindholm, patches
drivers/of/fdt.c contains a workaround for a missing memory type
entry on longtrail firmware. Make that quirk PPC32 only, and while
at it - fix up the .dts files in the tree currently working only
because of that quirk.
Cc: devicetree@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-kernel@vger.kernel.org
Cc: Mark Rutland <mark.rutland@arm.com>
Leif Lindholm (3):
arm: dts: add device_type="memory" for ste-ccu8540
mips: dts: add device_type="memory" where missing
of: Handle memory@0 node on PPC32 only
arch/arm/boot/dts/ste-ccu8540.dts | 1 +
arch/mips/lantiq/dts/easy50712.dts | 1 +
arch/mips/ralink/dts/mt7620a_eval.dts | 1 +
arch/mips/ralink/dts/rt2880_eval.dts | 1 +
arch/mips/ralink/dts/rt3052_eval.dts | 1 +
arch/mips/ralink/dts/rt3883_eval.dts | 1 +
drivers/of/fdt.c | 7 ++++++-
7 files changed, 12 insertions(+), 1 deletion(-)
--
1.7.10.4
^ permalink raw reply
* [PATCH 3/3] of: Handle memory@0 node on PPC32 only
From: Leif Lindholm @ 2014-04-17 17:42 UTC (permalink / raw)
To: linux-kernel
Cc: Mark Rutland, devicetree, patches, Leif Lindholm, Grant Likely,
linuxppc-dev
In-Reply-To: <1397756521-29387-1-git-send-email-leif.lindholm@linaro.org>
In order to deal with an firmware bug on a specific ppc32 platform
(longtrail), early_init_dt_scan_memory() looks for a node called
memory@0 on all platforms. Restrict this quirk to ppc32 kernels only.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/of/fdt.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index fa16a91..7368472 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -887,14 +887,19 @@ int __init early_init_dt_scan_memory(unsigned long node, const char *uname,
/* We are scanning "memory" nodes only */
if (type == NULL) {
+#ifdef CONFIG_PPC32
/*
* The longtrail doesn't have a device_type on the
* /memory node, so look for the node called /memory@0.
*/
if (depth != 1 || strcmp(uname, "memory@0") != 0)
return 0;
- } else if (strcmp(type, "memory") != 0)
+#else
+ return 0;
+#endif
+ } else if (strcmp(type, "memory") != 0) {
return 0;
+ }
reg = of_get_flat_dt_prop(node, "linux,usable-memory", &l);
if (reg == NULL)
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH 0/3] of: dts: enable memory@0 quirk for PPC32 only
From: Rob Herring @ 2014-04-18 0:43 UTC (permalink / raw)
To: Leif Lindholm
Cc: Mark Rutland, devicetree@vger.kernel.org, linuxppc-dev,
linux-kernel@vger.kernel.org, Linaro Patches
In-Reply-To: <1397756521-29387-1-git-send-email-leif.lindholm@linaro.org>
On Thu, Apr 17, 2014 at 12:41 PM, Leif Lindholm
<leif.lindholm@linaro.org> wrote:
> drivers/of/fdt.c contains a workaround for a missing memory type
> entry on longtrail firmware. Make that quirk PPC32 only, and while
> at it - fix up the .dts files in the tree currently working only
> because of that quirk.
But why do you need this?
>
> Cc: devicetree@vger.kernel.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-kernel@vger.kernel.org
> Cc: Mark Rutland <mark.rutland@arm.com>
>
> Leif Lindholm (3):
> arm: dts: add device_type="memory" for ste-ccu8540
> mips: dts: add device_type="memory" where missing
> of: Handle memory@0 node on PPC32 only
>
> arch/arm/boot/dts/ste-ccu8540.dts | 1 +
> arch/mips/lantiq/dts/easy50712.dts | 1 +
> arch/mips/ralink/dts/mt7620a_eval.dts | 1 +
> arch/mips/ralink/dts/rt2880_eval.dts | 1 +
> arch/mips/ralink/dts/rt3052_eval.dts | 1 +
> arch/mips/ralink/dts/rt3883_eval.dts | 1 +
I'm not worried about these MIPS dts files because they are all
built-in, but you are breaking compatibility with old dtbs for this
ARM board.
Rob
> drivers/of/fdt.c | 7 ++++++-
> 7 files changed, 12 insertions(+), 1 deletion(-)
>
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 4/8] DMA: Freescale: add fsl_dma_free_descriptor() to reduce code duplication
From: Hongbo Zhang @ 2014-04-18 4:09 UTC (permalink / raw)
To: Andy Shevchenko
Cc: leo.li, vkoul, linux-kernel, scottwood, dmaengine, dan.j.williams,
linuxppc-dev
In-Reply-To: <1397482830.11914.126.camel@smile.fi.intel.com>
On 04/14/2014 09:40 PM, Andy Shevchenko wrote:
> On Fri, 2014-04-11 at 16:14 +0800, Hongbo Zhang wrote:
>> On 04/10/2014 07:29 PM, Andy Shevchenko wrote:
>>> On Thu, 2014-04-10 at 15:10 +0800, hongbo.zhang@freescale.com wrote:
> []
>
>>>> @@ -819,8 +826,7 @@ static void fsldma_cleanup_descriptor(struct fsldma_chan *chan,
>>>> dma_run_dependencies(txd);
>>>>
>>>> dma_descriptor_unmap(txd);
>>>> - chan_dbg(chan, "LD %p free\n", desc);
>>>> - dma_pool_free(chan->desc_pool, desc, txd->phys);
>>>> + fsl_dma_free_descriptor(chan, desc);
>>> Here is no list_del() call since it's been called in dma_do_tasklet().
>>> What will be the result of double list_del() against the same node?
>> Not clear with your point.
>> This patch is only introducing a common fsl_dma_free_descriptor() to
>> reduce code duplication. And later in the patch 6/8 the
>> fsldma_cleanup_descriptor() is replaced by fsldma_cleanup_descriptorS().
> In the last case you could have a broken kernel which will fails on
> double list_del(). I think it's better to leave this one untouched and
> you may remove it later.
>
> Or move this patch after you have removed that lines.
>
Good catch, thank you Andy.
Yes I prefer to leave this untouched and handle it later.
^ permalink raw reply
* Re: [PATCH 0/5] defconfigs: add MTD_SPI_NOR (dependency for M25P80)
From: Brian Norris @ 2014-04-18 6:30 UTC (permalink / raw)
To: Thierry Reding
Cc: Marek Vasut, linux-mips, Russell King, Stephen Warren, linux-sh,
Steven Miao, Linux Kernel, Ralf Baechle, adi-buildroot-devel,
linux-tegra, linux-mtd, linux-arm-kernel, Sascha Hauer,
Olof Johansson, Paul Mackerras, linuxppc-dev, Shawn Guo
In-Reply-To: <20140417105302.GA32603@ulmo>
Hi,
On Thu, Apr 17, 2014 at 12:53:03PM +0200, Thierry Reding wrote:
> On Thu, Apr 17, 2014 at 12:21:44AM -0700, Brian Norris wrote:
> > We are introducing a new SPI-NOR library/framework for MTD, to support various
> > types of SPI-NOR flash controllers which require (or benefit from) intimate
> > knowledge of the flash interface, rather than just the relatively dumb SPI
> > interface. This library borrows much of the m25p80 driver for its abstraction
> > and moves this code into a spi-nor module.
>
> If this is a common library, then the more common approach to solve this
> would be to have each driver that uses it to select MTD_SPI_NOR rather
> than depend on it. That way you can drop this whole series to update the
> default configurations.
But does MTD_SPI_NOR (and drivers/mtd/spi-nor/) qualify as a "library"
or as a "subsystem"? I thought the latter were typically expected to be
user-selectable options, not automatically-"select"ed.
I would say that, except for its age, MTD_SPI_NOR is very similar in to
MTD_NAND (driver/mtd/nand/), which I'd consider a kind of subsystem, and
which users must select before they are asked about drivers which fall
under its category.
Perhaps my usage of the word "library" in the description was a mistake,
as I don't exactly consider it like a library in the sense of many other
"select"ed libraries.
Brian
^ permalink raw reply
* Re: [PATCH 3/3] of: Handle memory@0 node on PPC32 only
From: Geert Uytterhoeven @ 2014-04-18 8:04 UTC (permalink / raw)
To: Leif Lindholm
Cc: Mark Rutland, devicetree@vger.kernel.org, patches,
linux-kernel@vger.kernel.org, Grant Likely,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1397756521-29387-4-git-send-email-leif.lindholm@linaro.org>
Hi Leif,
On Thu, Apr 17, 2014 at 7:42 PM, Leif Lindholm <leif.lindholm@linaro.org> wrote:
> In order to deal with an firmware bug on a specific ppc32 platform
> (longtrail), early_init_dt_scan_memory() looks for a node called
> memory@0 on all platforms. Restrict this quirk to ppc32 kernels only.
This breaks backwards compatibilty with old DTSes (at least on ARM/MIPS,
where you added the missing property in patches 1 and 2 of the series)?
For the Longtrail, I don't care much anymore, as mine died in 2004.
AFAIK, there have never been many users anyway.
> Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: Grant Likely <grant.likely@linaro.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: devicetree@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> ---
> drivers/of/fdt.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index fa16a91..7368472 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -887,14 +887,19 @@ int __init early_init_dt_scan_memory(unsigned long node, const char *uname,
>
> /* We are scanning "memory" nodes only */
> if (type == NULL) {
> +#ifdef CONFIG_PPC32
> /*
> * The longtrail doesn't have a device_type on the
> * /memory node, so look for the node called /memory@0.
> */
> if (depth != 1 || strcmp(uname, "memory@0") != 0)
> return 0;
> - } else if (strcmp(type, "memory") != 0)
> +#else
> + return 0;
> +#endif
> + } else if (strcmp(type, "memory") != 0) {
> return 0;
> + }
>
> reg = of_get_flat_dt_prop(node, "linux,usable-memory", &l);
> if (reg == NULL)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v4 0/8] DMA: Freescale: driver cleanups and enhancements
From: hongbo.zhang @ 2014-04-18 8:17 UTC (permalink / raw)
To: vkoul, dan.j.williams, dmaengine
Cc: scottwood, Hongbo Zhang, linuxppc-dev, linux-kernel, leo.li
From: Hongbo Zhang <hongbo.zhang@freescale.com>
Hi Vinod Koul,
Please have a look at the v4 patch set.
v3 -> v4 changes:
- Fixed a typo in [2/8] commit message.
- There was a potential double call of list_del() when apply [4/8] only,
although this defect is removed again in later [6/8]. This version
eliminates this problem by updating [4/8] and [6/8] slightly.
- Updated [8/8] to use register access method introduced by [2/8]
v2 -> v3 change:
Only add "chan->pm_state = RUNNING" for patch[8/8].
v1 -> v2 change:
The only one change is introducing a new patch[1/7] to remove the unnecessary
macro FSL_DMA_LD_DEBUG, thus the total patches number is 8 now (was 7)
v1 notes:
Note that patch 2~6 had beed sent out for upstream before, but were together
with other storage patches at that time, that was not easy for being reviewed
and merged, so I send them separately this time.
Hongbo Zhang (8):
DMA: Freescale: remove the unnecessary FSL_DMA_LD_DEBUG
DMA: Freescale: unify register access methods
DMA: Freescale: remove attribute DMA_INTERRUPT of dmaengine
DMA: Freescale: add fsl_dma_free_descriptor() to reduce code
duplication
DMA: Freescale: move functions to avoid forward declarations
DMA: Freescale: change descriptor release process for supporting
async_tx
DMA: Freescale: use spin_lock_bh instead of spin_lock_irqsave
DMA: Freescale: add suspend resume functions for DMA driver
drivers/dma/fsldma.c | 592 ++++++++++++++++++++++++++++++++------------------
drivers/dma/fsldma.h | 33 ++-
2 files changed, 410 insertions(+), 215 deletions(-)
--
1.7.9.5
^ permalink raw reply
* [PATCH v4 1/8] DMA: Freescale: remove the unnecessary FSL_DMA_LD_DEBUG
From: hongbo.zhang @ 2014-04-18 8:17 UTC (permalink / raw)
To: vkoul, dan.j.williams, dmaengine
Cc: scottwood, Hongbo Zhang, linuxppc-dev, linux-kernel, leo.li
In-Reply-To: <1397809071-5353-1-git-send-email-hongbo.zhang@freescale.com>
From: Hongbo Zhang <hongbo.zhang@freescale.com>
Some codes are calling chan_dbg with FSL_DMA_LD_DEBUG surrounded, it is really
unnecessary to use such a macro because chan_dbg is a wrapper of dev_dbg, we do
have corresponding DEBUG macro to switch on/off dev_dbg, and most of the other
codes are also calling chan_dbg directly without using FSL_DMA_LD_DEBUG.
Signed-off-by: Hongbo Zhang <hongbo.zhang@freescale.com>
---
drivers/dma/fsldma.c | 10 ----------
1 file changed, 10 deletions(-)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index f157c6f..ec50420 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -426,9 +426,7 @@ static struct fsl_desc_sw *fsl_dma_alloc_descriptor(struct fsldma_chan *chan)
desc->async_tx.tx_submit = fsl_dma_tx_submit;
desc->async_tx.phys = pdesc;
-#ifdef FSL_DMA_LD_DEBUG
chan_dbg(chan, "LD %p allocated\n", desc);
-#endif
return desc;
}
@@ -479,9 +477,7 @@ static void fsldma_free_desc_list(struct fsldma_chan *chan,
list_for_each_entry_safe(desc, _desc, list, node) {
list_del(&desc->node);
-#ifdef FSL_DMA_LD_DEBUG
chan_dbg(chan, "LD %p free\n", desc);
-#endif
dma_pool_free(chan->desc_pool, desc, desc->async_tx.phys);
}
}
@@ -493,9 +489,7 @@ static void fsldma_free_desc_list_reverse(struct fsldma_chan *chan,
list_for_each_entry_safe_reverse(desc, _desc, list, node) {
list_del(&desc->node);
-#ifdef FSL_DMA_LD_DEBUG
chan_dbg(chan, "LD %p free\n", desc);
-#endif
dma_pool_free(chan->desc_pool, desc, desc->async_tx.phys);
}
}
@@ -832,9 +826,7 @@ static void fsldma_cleanup_descriptor(struct fsldma_chan *chan,
/* Run the link descriptor callback function */
if (txd->callback) {
-#ifdef FSL_DMA_LD_DEBUG
chan_dbg(chan, "LD %p callback\n", desc);
-#endif
txd->callback(txd->callback_param);
}
@@ -842,9 +834,7 @@ static void fsldma_cleanup_descriptor(struct fsldma_chan *chan,
dma_run_dependencies(txd);
dma_descriptor_unmap(txd);
-#ifdef FSL_DMA_LD_DEBUG
chan_dbg(chan, "LD %p free\n", desc);
-#endif
dma_pool_free(chan->desc_pool, desc, txd->phys);
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH v4 2/8] DMA: Freescale: unify register access methods
From: hongbo.zhang @ 2014-04-18 8:17 UTC (permalink / raw)
To: vkoul, dan.j.williams, dmaengine
Cc: scottwood, Hongbo Zhang, linuxppc-dev, linux-kernel, leo.li
In-Reply-To: <1397809071-5353-1-git-send-email-hongbo.zhang@freescale.com>
From: Hongbo Zhang <hongbo.zhang@freescale.com>
Methods of accessing DMA controller registers are inconsistent, some registers
are accessed by DMA_IN/OUT directly, while others are accessed by functions
get/set_* which are wrappers of DMA_IN/OUT, and even for the BCR register, it
is read by get_bcr but written by DMA_OUT.
This patch unifies the inconsistent methods, all registers are accessed by
get/set_* now.
Signed-off-by: Hongbo Zhang <hongbo.zhang@freescale.com>
---
drivers/dma/fsldma.c | 52 ++++++++++++++++++++++++++++++++------------------
1 file changed, 33 insertions(+), 19 deletions(-)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index ec50420..5f32cb8 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -61,6 +61,16 @@ static u32 get_sr(struct fsldma_chan *chan)
return DMA_IN(chan, &chan->regs->sr, 32);
}
+static void set_mr(struct fsldma_chan *chan, u32 val)
+{
+ DMA_OUT(chan, &chan->regs->mr, val, 32);
+}
+
+static u32 get_mr(struct fsldma_chan *chan)
+{
+ return DMA_IN(chan, &chan->regs->mr, 32);
+}
+
static void set_cdar(struct fsldma_chan *chan, dma_addr_t addr)
{
DMA_OUT(chan, &chan->regs->cdar, addr | FSL_DMA_SNEN, 64);
@@ -71,6 +81,11 @@ static dma_addr_t get_cdar(struct fsldma_chan *chan)
return DMA_IN(chan, &chan->regs->cdar, 64) & ~FSL_DMA_SNEN;
}
+static void set_bcr(struct fsldma_chan *chan, u32 val)
+{
+ DMA_OUT(chan, &chan->regs->bcr, val, 32);
+}
+
static u32 get_bcr(struct fsldma_chan *chan)
{
return DMA_IN(chan, &chan->regs->bcr, 32);
@@ -135,7 +150,7 @@ static void set_ld_eol(struct fsldma_chan *chan, struct fsl_desc_sw *desc)
static void dma_init(struct fsldma_chan *chan)
{
/* Reset the channel */
- DMA_OUT(chan, &chan->regs->mr, 0, 32);
+ set_mr(chan, 0);
switch (chan->feature & FSL_DMA_IP_MASK) {
case FSL_DMA_IP_85XX:
@@ -144,16 +159,15 @@ static void dma_init(struct fsldma_chan *chan)
* EOLNIE - End of links interrupt enable
* BWC - Bandwidth sharing among channels
*/
- DMA_OUT(chan, &chan->regs->mr, FSL_DMA_MR_BWC
- | FSL_DMA_MR_EIE | FSL_DMA_MR_EOLNIE, 32);
+ set_mr(chan, FSL_DMA_MR_BWC | FSL_DMA_MR_EIE
+ | FSL_DMA_MR_EOLNIE);
break;
case FSL_DMA_IP_83XX:
/* Set the channel to below modes:
* EOTIE - End-of-transfer interrupt enable
* PRC_RM - PCI read multiple
*/
- DMA_OUT(chan, &chan->regs->mr, FSL_DMA_MR_EOTIE
- | FSL_DMA_MR_PRC_RM, 32);
+ set_mr(chan, FSL_DMA_MR_EOTIE | FSL_DMA_MR_PRC_RM);
break;
}
}
@@ -175,10 +189,10 @@ static void dma_start(struct fsldma_chan *chan)
{
u32 mode;
- mode = DMA_IN(chan, &chan->regs->mr, 32);
+ mode = get_mr(chan);
if (chan->feature & FSL_DMA_CHAN_PAUSE_EXT) {
- DMA_OUT(chan, &chan->regs->bcr, 0, 32);
+ set_bcr(chan, 0);
mode |= FSL_DMA_MR_EMP_EN;
} else {
mode &= ~FSL_DMA_MR_EMP_EN;
@@ -191,7 +205,7 @@ static void dma_start(struct fsldma_chan *chan)
mode |= FSL_DMA_MR_CS;
}
- DMA_OUT(chan, &chan->regs->mr, mode, 32);
+ set_mr(chan, mode);
}
static void dma_halt(struct fsldma_chan *chan)
@@ -200,7 +214,7 @@ static void dma_halt(struct fsldma_chan *chan)
int i;
/* read the mode register */
- mode = DMA_IN(chan, &chan->regs->mr, 32);
+ mode = get_mr(chan);
/*
* The 85xx controller supports channel abort, which will stop
@@ -209,14 +223,14 @@ static void dma_halt(struct fsldma_chan *chan)
*/
if ((chan->feature & FSL_DMA_IP_MASK) == FSL_DMA_IP_85XX) {
mode |= FSL_DMA_MR_CA;
- DMA_OUT(chan, &chan->regs->mr, mode, 32);
+ set_mr(chan, mode);
mode &= ~FSL_DMA_MR_CA;
}
/* stop the DMA controller */
mode &= ~(FSL_DMA_MR_CS | FSL_DMA_MR_EMS_EN);
- DMA_OUT(chan, &chan->regs->mr, mode, 32);
+ set_mr(chan, mode);
/* wait for the DMA controller to become idle */
for (i = 0; i < 100; i++) {
@@ -245,7 +259,7 @@ static void fsl_chan_set_src_loop_size(struct fsldma_chan *chan, int size)
{
u32 mode;
- mode = DMA_IN(chan, &chan->regs->mr, 32);
+ mode = get_mr(chan);
switch (size) {
case 0:
@@ -259,7 +273,7 @@ static void fsl_chan_set_src_loop_size(struct fsldma_chan *chan, int size)
break;
}
- DMA_OUT(chan, &chan->regs->mr, mode, 32);
+ set_mr(chan, mode);
}
/**
@@ -277,7 +291,7 @@ static void fsl_chan_set_dst_loop_size(struct fsldma_chan *chan, int size)
{
u32 mode;
- mode = DMA_IN(chan, &chan->regs->mr, 32);
+ mode = get_mr(chan);
switch (size) {
case 0:
@@ -291,7 +305,7 @@ static void fsl_chan_set_dst_loop_size(struct fsldma_chan *chan, int size)
break;
}
- DMA_OUT(chan, &chan->regs->mr, mode, 32);
+ set_mr(chan, mode);
}
/**
@@ -312,10 +326,10 @@ static void fsl_chan_set_request_count(struct fsldma_chan *chan, int size)
BUG_ON(size > 1024);
- mode = DMA_IN(chan, &chan->regs->mr, 32);
+ mode = get_mr(chan);
mode |= (__ilog2(size) << 24) & 0x0f000000;
- DMA_OUT(chan, &chan->regs->mr, mode, 32);
+ set_mr(chan, mode);
}
/**
@@ -889,9 +903,9 @@ static void fsl_chan_xfer_ld_queue(struct fsldma_chan *chan)
if ((chan->feature & FSL_DMA_IP_MASK) == FSL_DMA_IP_85XX) {
u32 mode;
- mode = DMA_IN(chan, &chan->regs->mr, 32);
+ mode = get_mr(chan);
mode &= ~FSL_DMA_MR_CS;
- DMA_OUT(chan, &chan->regs->mr, mode, 32);
+ set_mr(chan, mode);
}
/*
--
1.7.9.5
^ permalink raw reply related
* [PATCH v4 4/8] DMA: Freescale: add fsl_dma_free_descriptor() to reduce code duplication
From: hongbo.zhang @ 2014-04-18 8:17 UTC (permalink / raw)
To: vkoul, dan.j.williams, dmaengine
Cc: scottwood, Hongbo Zhang, linuxppc-dev, linux-kernel, leo.li
In-Reply-To: <1397809071-5353-1-git-send-email-hongbo.zhang@freescale.com>
From: Hongbo Zhang <hongbo.zhang@freescale.com>
There are several places where descriptors are freed using identical code.
This patch puts this code into a function to reduce code duplication.
Signed-off-by: Hongbo Zhang <hongbo.zhang@freescale.com>
Signed-off-by: Qiang Liu <qiang.liu@freescale.com>
---
drivers/dma/fsldma.c | 27 +++++++++++++++++----------
1 file changed, 17 insertions(+), 10 deletions(-)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index b71cc04..adc266e 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -418,6 +418,19 @@ static dma_cookie_t fsl_dma_tx_submit(struct dma_async_tx_descriptor *tx)
}
/**
+ * fsl_dma_free_descriptor - Free descriptor from channel's DMA pool.
+ * @chan : Freescale DMA channel
+ * @desc: descriptor to be freed
+ */
+static void fsl_dma_free_descriptor(struct fsldma_chan *chan,
+ struct fsl_desc_sw *desc)
+{
+ list_del(&desc->node);
+ chan_dbg(chan, "LD %p free\n", desc);
+ dma_pool_free(chan->desc_pool, desc, desc->async_tx.phys);
+}
+
+/**
* fsl_dma_alloc_descriptor - Allocate descriptor from channel's DMA pool.
* @chan : Freescale DMA channel
*
@@ -489,11 +502,8 @@ static void fsldma_free_desc_list(struct fsldma_chan *chan,
{
struct fsl_desc_sw *desc, *_desc;
- list_for_each_entry_safe(desc, _desc, list, node) {
- list_del(&desc->node);
- chan_dbg(chan, "LD %p free\n", desc);
- dma_pool_free(chan->desc_pool, desc, desc->async_tx.phys);
- }
+ list_for_each_entry_safe(desc, _desc, list, node)
+ fsl_dma_free_descriptor(chan, desc);
}
static void fsldma_free_desc_list_reverse(struct fsldma_chan *chan,
@@ -501,11 +511,8 @@ static void fsldma_free_desc_list_reverse(struct fsldma_chan *chan,
{
struct fsl_desc_sw *desc, *_desc;
- list_for_each_entry_safe_reverse(desc, _desc, list, node) {
- list_del(&desc->node);
- chan_dbg(chan, "LD %p free\n", desc);
- dma_pool_free(chan->desc_pool, desc, desc->async_tx.phys);
- }
+ list_for_each_entry_safe_reverse(desc, _desc, list, node)
+ fsl_dma_free_descriptor(chan, desc);
}
/**
--
1.7.9.5
^ permalink raw reply related
* [PATCH v4 5/8] DMA: Freescale: move functions to avoid forward declarations
From: hongbo.zhang @ 2014-04-18 8:17 UTC (permalink / raw)
To: vkoul, dan.j.williams, dmaengine
Cc: scottwood, Hongbo Zhang, linuxppc-dev, linux-kernel, leo.li
In-Reply-To: <1397809071-5353-1-git-send-email-hongbo.zhang@freescale.com>
From: Hongbo Zhang <hongbo.zhang@freescale.com>
These functions will be modified in the next patch in the series. By moving the
function in a patch separate from the changes, it will make review easier.
Signed-off-by: Hongbo Zhang <hongbo.zhang@freescale.com>
Signed-off-by: Qiang Liu <qiang.liu@freescale.com>
---
drivers/dma/fsldma.c | 190 +++++++++++++++++++++++++-------------------------
1 file changed, 95 insertions(+), 95 deletions(-)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index adc266e..e0fec68 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -459,6 +459,101 @@ static struct fsl_desc_sw *fsl_dma_alloc_descriptor(struct fsldma_chan *chan)
}
/**
+ * fsl_chan_xfer_ld_queue - transfer any pending transactions
+ * @chan : Freescale DMA channel
+ *
+ * HARDWARE STATE: idle
+ * LOCKING: must hold chan->desc_lock
+ */
+static void fsl_chan_xfer_ld_queue(struct fsldma_chan *chan)
+{
+ struct fsl_desc_sw *desc;
+
+ /*
+ * If the list of pending descriptors is empty, then we
+ * don't need to do any work at all
+ */
+ if (list_empty(&chan->ld_pending)) {
+ chan_dbg(chan, "no pending LDs\n");
+ return;
+ }
+
+ /*
+ * The DMA controller is not idle, which means that the interrupt
+ * handler will start any queued transactions when it runs after
+ * this transaction finishes
+ */
+ if (!chan->idle) {
+ chan_dbg(chan, "DMA controller still busy\n");
+ return;
+ }
+
+ /*
+ * If there are some link descriptors which have not been
+ * transferred, we need to start the controller
+ */
+
+ /*
+ * Move all elements from the queue of pending transactions
+ * onto the list of running transactions
+ */
+ chan_dbg(chan, "idle, starting controller\n");
+ desc = list_first_entry(&chan->ld_pending, struct fsl_desc_sw, node);
+ list_splice_tail_init(&chan->ld_pending, &chan->ld_running);
+
+ /*
+ * The 85xx DMA controller doesn't clear the channel start bit
+ * automatically at the end of a transfer. Therefore we must clear
+ * it in software before starting the transfer.
+ */
+ if ((chan->feature & FSL_DMA_IP_MASK) == FSL_DMA_IP_85XX) {
+ u32 mode;
+
+ mode = get_mr(chan);
+ mode &= ~FSL_DMA_MR_CS;
+ set_mr(chan, mode);
+ }
+
+ /*
+ * Program the descriptor's address into the DMA controller,
+ * then start the DMA transaction
+ */
+ set_cdar(chan, desc->async_tx.phys);
+ get_cdar(chan);
+
+ dma_start(chan);
+ chan->idle = false;
+}
+
+/**
+ * fsldma_cleanup_descriptor - cleanup and free a single link descriptor
+ * @chan: Freescale DMA channel
+ * @desc: descriptor to cleanup and free
+ *
+ * This function is used on a descriptor which has been executed by the DMA
+ * controller. It will run any callbacks, submit any dependencies, and then
+ * free the descriptor.
+ */
+static void fsldma_cleanup_descriptor(struct fsldma_chan *chan,
+ struct fsl_desc_sw *desc)
+{
+ struct dma_async_tx_descriptor *txd = &desc->async_tx;
+
+ /* Run the link descriptor callback function */
+ if (txd->callback) {
+ chan_dbg(chan, "LD %p callback\n", desc);
+ txd->callback(txd->callback_param);
+ }
+
+ /* Run any dependencies */
+ dma_run_dependencies(txd);
+
+ dma_descriptor_unmap(txd);
+ chan_dbg(chan, "LD %p free\n", desc);
+ dma_pool_free(chan->desc_pool, desc, txd->phys);
+}
+
+/**
* fsl_dma_alloc_chan_resources - Allocate resources for DMA channel.
* @chan : Freescale DMA channel
*
@@ -803,101 +898,6 @@ static int fsl_dma_device_control(struct dma_chan *dchan,
}
/**
- * fsldma_cleanup_descriptor - cleanup and free a single link descriptor
- * @chan: Freescale DMA channel
- * @desc: descriptor to cleanup and free
- *
- * This function is used on a descriptor which has been executed by the DMA
- * controller. It will run any callbacks, submit any dependencies, and then
- * free the descriptor.
- */
-static void fsldma_cleanup_descriptor(struct fsldma_chan *chan,
- struct fsl_desc_sw *desc)
-{
- struct dma_async_tx_descriptor *txd = &desc->async_tx;
-
- /* Run the link descriptor callback function */
- if (txd->callback) {
- chan_dbg(chan, "LD %p callback\n", desc);
- txd->callback(txd->callback_param);
- }
-
- /* Run any dependencies */
- dma_run_dependencies(txd);
-
- dma_descriptor_unmap(txd);
- chan_dbg(chan, "LD %p free\n", desc);
- dma_pool_free(chan->desc_pool, desc, txd->phys);
-}
-
-/**
- * fsl_chan_xfer_ld_queue - transfer any pending transactions
- * @chan : Freescale DMA channel
- *
- * HARDWARE STATE: idle
- * LOCKING: must hold chan->desc_lock
- */
-static void fsl_chan_xfer_ld_queue(struct fsldma_chan *chan)
-{
- struct fsl_desc_sw *desc;
-
- /*
- * If the list of pending descriptors is empty, then we
- * don't need to do any work at all
- */
- if (list_empty(&chan->ld_pending)) {
- chan_dbg(chan, "no pending LDs\n");
- return;
- }
-
- /*
- * The DMA controller is not idle, which means that the interrupt
- * handler will start any queued transactions when it runs after
- * this transaction finishes
- */
- if (!chan->idle) {
- chan_dbg(chan, "DMA controller still busy\n");
- return;
- }
-
- /*
- * If there are some link descriptors which have not been
- * transferred, we need to start the controller
- */
-
- /*
- * Move all elements from the queue of pending transactions
- * onto the list of running transactions
- */
- chan_dbg(chan, "idle, starting controller\n");
- desc = list_first_entry(&chan->ld_pending, struct fsl_desc_sw, node);
- list_splice_tail_init(&chan->ld_pending, &chan->ld_running);
-
- /*
- * The 85xx DMA controller doesn't clear the channel start bit
- * automatically at the end of a transfer. Therefore we must clear
- * it in software before starting the transfer.
- */
- if ((chan->feature & FSL_DMA_IP_MASK) == FSL_DMA_IP_85XX) {
- u32 mode;
-
- mode = get_mr(chan);
- mode &= ~FSL_DMA_MR_CS;
- set_mr(chan, mode);
- }
-
- /*
- * Program the descriptor's address into the DMA controller,
- * then start the DMA transaction
- */
- set_cdar(chan, desc->async_tx.phys);
- get_cdar(chan);
-
- dma_start(chan);
- chan->idle = false;
-}
-
-/**
* fsl_dma_memcpy_issue_pending - Issue the DMA start command
* @chan : Freescale DMA channel
*/
--
1.7.9.5
^ permalink raw reply related
* [PATCH v4 3/8] DMA: Freescale: remove attribute DMA_INTERRUPT of dmaengine
From: hongbo.zhang @ 2014-04-18 8:17 UTC (permalink / raw)
To: vkoul, dan.j.williams, dmaengine
Cc: scottwood, Hongbo Zhang, linuxppc-dev, linux-kernel, leo.li
In-Reply-To: <1397809071-5353-1-git-send-email-hongbo.zhang@freescale.com>
From: Hongbo Zhang <hongbo.zhang@freescale.com>
Delete attribute DMA_INTERRUPT because fsldma doesn't support this function,
exception will be thrown if talitos is used to offload xor at the same time.
Signed-off-by: Hongbo Zhang <hongbo.zhang@freescale.com>
Signed-off-by: Qiang Liu <qiang.liu@freescale.com>
---
drivers/dma/fsldma.c | 31 -------------------------------
1 file changed, 31 deletions(-)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 5f32cb8..b71cc04 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -528,35 +528,6 @@ static void fsl_dma_free_chan_resources(struct dma_chan *dchan)
}
static struct dma_async_tx_descriptor *
-fsl_dma_prep_interrupt(struct dma_chan *dchan, unsigned long flags)
-{
- struct fsldma_chan *chan;
- struct fsl_desc_sw *new;
-
- if (!dchan)
- return NULL;
-
- chan = to_fsl_chan(dchan);
-
- new = fsl_dma_alloc_descriptor(chan);
- if (!new) {
- chan_err(chan, "%s\n", msg_ld_oom);
- return NULL;
- }
-
- new->async_tx.cookie = -EBUSY;
- new->async_tx.flags = flags;
-
- /* Insert the link descriptor to the LD ring */
- list_add_tail(&new->node, &new->tx_list);
-
- /* Set End-of-link to the last link descriptor of new list */
- set_ld_eol(chan, new);
-
- return &new->async_tx;
-}
-
-static struct dma_async_tx_descriptor *
fsl_dma_prep_memcpy(struct dma_chan *dchan,
dma_addr_t dma_dst, dma_addr_t dma_src,
size_t len, unsigned long flags)
@@ -1308,12 +1279,10 @@ static int fsldma_of_probe(struct platform_device *op)
fdev->irq = irq_of_parse_and_map(op->dev.of_node, 0);
dma_cap_set(DMA_MEMCPY, fdev->common.cap_mask);
- dma_cap_set(DMA_INTERRUPT, fdev->common.cap_mask);
dma_cap_set(DMA_SG, fdev->common.cap_mask);
dma_cap_set(DMA_SLAVE, fdev->common.cap_mask);
fdev->common.device_alloc_chan_resources = fsl_dma_alloc_chan_resources;
fdev->common.device_free_chan_resources = fsl_dma_free_chan_resources;
- fdev->common.device_prep_dma_interrupt = fsl_dma_prep_interrupt;
fdev->common.device_prep_dma_memcpy = fsl_dma_prep_memcpy;
fdev->common.device_prep_dma_sg = fsl_dma_prep_sg;
fdev->common.device_tx_status = fsl_tx_status;
--
1.7.9.5
^ permalink raw reply related
* [PATCH v4 6/8] DMA: Freescale: change descriptor release process for supporting async_tx
From: hongbo.zhang @ 2014-04-18 8:17 UTC (permalink / raw)
To: vkoul, dan.j.williams, dmaengine
Cc: scottwood, Hongbo Zhang, linuxppc-dev, linux-kernel, leo.li
In-Reply-To: <1397809071-5353-1-git-send-email-hongbo.zhang@freescale.com>
From: Hongbo Zhang <hongbo.zhang@freescale.com>
Fix the potential risk when enable config NET_DMA and ASYNC_TX. Async_tx is
lack of support in current release process of dma descriptor, all descriptors
will be released whatever is acked or no-acked by async_tx, so there is a
potential race condition when dma engine is uesd by others clients (e.g. when
enable NET_DMA to offload TCP).
In our case, a race condition which is raised when use both of talitos and
dmaengine to offload xor is because napi scheduler will sync all pending
requests in dma channels, it affects the process of raid operations due to
ack_tx is not checked in fsl dma. The no-acked descriptor is freed which is
submitted just now, as a dependent tx, this freed descriptor trigger
BUG_ON(async_tx_test_ack(depend_tx)) in async_tx_submit().
TASK = ee1a94a0[1390] 'md0_raid5' THREAD: ecf40000 CPU: 0
GPR00: 00000001 ecf41ca0 ee44/921a94a0 0000003f 00000001 c00593e4 00000000 00000001
GPR08: 00000000 a7a7a7a7 00000001 045/920000002 42028042 100a38d4 ed576d98 00000000
GPR16: ed5a11b0 00000000 2b162000 00000200 046/920000000 2d555000 ed3015e8 c15a7aa0
GPR24: 00000000 c155fc40 00000000 ecb63220 ecf41d28 e47/92f640bb0 ef640c30 ecf41ca0
NIP [c02b048c] async_tx_submit+0x6c/0x2b4
LR [c02b068c] async_tx_submit+0x26c/0x2b4
Call Trace:
[ecf41ca0] [c02b068c] async_tx_submit+0x26c/0x2b448/92 (unreliable)
[ecf41cd0] [c02b0a4c] async_memcpy+0x240/0x25c
[ecf41d20] [c0421064] async_copy_data+0xa0/0x17c
[ecf41d70] [c0421cf4] __raid_run_ops+0x874/0xe10
[ecf41df0] [c0426ee4] handle_stripe+0x820/0x25e8
[ecf41e90] [c0429080] raid5d+0x3d4/0x5b4
[ecf41f40] [c04329b8] md_thread+0x138/0x16c
[ecf41f90] [c008277c] kthread+0x8c/0x90
[ecf41ff0] [c0011630] kernel_thread+0x4c/0x68
Another modification in this patch is the change of completed descriptors,
there is a potential risk which caused by exception interrupt, all descriptors
in ld_running list are seemed completed when an interrupt raised, it works fine
under normal condition, but if there is an exception occured, it cannot work as
our excepted. Hardware should not be depend on s/w list, the right way is to
read current descriptor address register to find the last completed descriptor.
If an interrupt is raised by an error, all descriptors in ld_running should not
be seemed finished, or these unfinished descriptors in ld_running will be
released wrongly.
A simple way to reproduce:
Enable dmatest first, then insert some bad descriptors which can trigger
Programming Error interrupts before the good descriptors. Last, the good
descriptors will be freed before they are processsed because of the exception
intrerrupt.
Note: the bad descriptors are only for simulating an exception interrupt. This
case can illustrate the potential risk in current fsl-dma very well.
Signed-off-by: Hongbo Zhang <hongbo.zhang@freescale.com>
Signed-off-by: Qiang Liu <qiang.liu@freescale.com>
Signed-off-by: Ira W. Snyder <iws@ovro.caltech.edu>
---
drivers/dma/fsldma.c | 197 ++++++++++++++++++++++++++++++++++++--------------
drivers/dma/fsldma.h | 17 ++++-
2 files changed, 159 insertions(+), 55 deletions(-)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index e0fec68..374ca97 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -459,6 +459,88 @@ static struct fsl_desc_sw *fsl_dma_alloc_descriptor(struct fsldma_chan *chan)
}
/**
+ * fsldma_clean_completed_descriptor - free all descriptors which
+ * has been completed and acked
+ * @chan: Freescale DMA channel
+ *
+ * This function is used on all completed and acked descriptors.
+ * All descriptors should only be freed in this function.
+ */
+static void fsldma_clean_completed_descriptor(struct fsldma_chan *chan)
+{
+ struct fsl_desc_sw *desc, *_desc;
+
+ /* Run the callback for each descriptor, in order */
+ list_for_each_entry_safe(desc, _desc, &chan->ld_completed, node)
+ if (async_tx_test_ack(&desc->async_tx))
+ fsl_dma_free_descriptor(chan, desc);
+}
+
+/**
+ * fsldma_run_tx_complete_actions - cleanup a single link descriptor
+ * @chan: Freescale DMA channel
+ * @desc: descriptor to cleanup and free
+ * @cookie: Freescale DMA transaction identifier
+ *
+ * This function is used on a descriptor which has been executed by the DMA
+ * controller. It will run any callbacks, submit any dependencies.
+ */
+static dma_cookie_t fsldma_run_tx_complete_actions(struct fsldma_chan *chan,
+ struct fsl_desc_sw *desc, dma_cookie_t cookie)
+{
+ struct dma_async_tx_descriptor *txd = &desc->async_tx;
+ dma_cookie_t ret = cookie;
+
+ BUG_ON(txd->cookie < 0);
+
+ if (txd->cookie > 0) {
+ ret = txd->cookie;
+
+ /* Run the link descriptor callback function */
+ if (txd->callback) {
+ chan_dbg(chan, "LD %p callback\n", desc);
+ txd->callback(txd->callback_param);
+ }
+ }
+
+ /* Run any dependencies */
+ dma_run_dependencies(txd);
+
+ return ret;
+}
+
+/**
+ * fsldma_clean_running_descriptor - move the completed descriptor from
+ * ld_running to ld_completed
+ * @chan: Freescale DMA channel
+ * @desc: the descriptor which is completed
+ *
+ * Free the descriptor directly if acked by async_tx api, or move it to
+ * queue ld_completed.
+ */
+static void fsldma_clean_running_descriptor(struct fsldma_chan *chan,
+ struct fsl_desc_sw *desc)
+{
+ /* Remove from the list of transactions */
+ list_del(&desc->node);
+
+ /*
+ * the client is allowed to attach dependent operations
+ * until 'ack' is set
+ */
+ if (!async_tx_test_ack(&desc->async_tx)) {
+ /*
+ * Move this descriptor to the list of descriptors which is
+ * completed, but still awaiting the 'ack' bit to be set.
+ */
+ list_add_tail(&desc->node, &chan->ld_completed);
+ return;
+ }
+
+ dma_pool_free(chan->desc_pool, desc, desc->async_tx.phys);
+}
+
+/**
* fsl_chan_xfer_ld_queue - transfer any pending transactions
* @chan : Freescale DMA channel
*
@@ -526,31 +608,58 @@ static void fsl_chan_xfer_ld_queue(struct fsldma_chan *chan)
}
/**
- * fsldma_cleanup_descriptor - cleanup and free a single link descriptor
+ * fsldma_cleanup_descriptors - cleanup link descriptors which are completed
+ * and move them to ld_completed to free until flag 'ack' is set
* @chan: Freescale DMA channel
- * @desc: descriptor to cleanup and free
*
- * This function is used on a descriptor which has been executed by the DMA
- * controller. It will run any callbacks, submit any dependencies, and then
- * free the descriptor.
+ * This function is used on descriptors which have been executed by the DMA
+ * controller. It will run any callbacks, submit any dependencies, then
+ * free these descriptors if flag 'ack' is set.
*/
-static void fsldma_cleanup_descriptor(struct fsldma_chan *chan,
- struct fsl_desc_sw *desc)
+static void fsldma_cleanup_descriptors(struct fsldma_chan *chan)
{
- struct dma_async_tx_descriptor *txd = &desc->async_tx;
+ struct fsl_desc_sw *desc, *_desc;
+ dma_cookie_t cookie = 0;
+ dma_addr_t curr_phys = get_cdar(chan);
+ int seen_current = 0;
+
+ fsldma_clean_completed_descriptor(chan);
+
+ /* Run the callback for each descriptor, in order */
+ list_for_each_entry_safe(desc, _desc, &chan->ld_running, node) {
+ /*
+ * do not advance past the current descriptor loaded into the
+ * hardware channel, subsequent descriptors are either in
+ * process or have not been submitted
+ */
+ if (seen_current)
+ break;
+
+ /*
+ * stop the search if we reach the current descriptor and the
+ * channel is busy
+ */
+ if (desc->async_tx.phys == curr_phys) {
+ seen_current = 1;
+ if (!dma_is_idle(chan))
+ break;
+ }
+
+ cookie = fsldma_run_tx_complete_actions(chan, desc, cookie);
- /* Run the link descriptor callback function */
- if (txd->callback) {
- chan_dbg(chan, "LD %p callback\n", desc);
- txd->callback(txd->callback_param);
+ fsldma_clean_running_descriptor(chan, desc);
}
- /* Run any dependencies */
- dma_run_dependencies(txd);
+ /*
+ * Start any pending transactions automatically
+ *
+ * In the ideal case, we keep the DMA controller busy while we go
+ * ahead and free the descriptors below.
+ */
+ fsl_chan_xfer_ld_queue(chan);
- dma_descriptor_unmap(txd);
- chan_dbg(chan, "LD %p free\n", desc);
- dma_pool_free(chan->desc_pool, desc, txd->phys);
+ if (cookie > 0)
+ chan->common.completed_cookie = cookie;
}
/**
@@ -621,8 +730,10 @@ static void fsl_dma_free_chan_resources(struct dma_chan *dchan)
chan_dbg(chan, "free all channel resources\n");
spin_lock_irqsave(&chan->desc_lock, flags);
+ fsldma_cleanup_descriptors(chan);
fsldma_free_desc_list(chan, &chan->ld_pending);
fsldma_free_desc_list(chan, &chan->ld_running);
+ fsldma_free_desc_list(chan, &chan->ld_completed);
spin_unlock_irqrestore(&chan->desc_lock, flags);
dma_pool_destroy(chan->desc_pool);
@@ -860,6 +971,7 @@ static int fsl_dma_device_control(struct dma_chan *dchan,
/* Remove and free all of the descriptors in the LD queue */
fsldma_free_desc_list(chan, &chan->ld_pending);
fsldma_free_desc_list(chan, &chan->ld_running);
+ fsldma_free_desc_list(chan, &chan->ld_completed);
chan->idle = true;
spin_unlock_irqrestore(&chan->desc_lock, flags);
@@ -919,6 +1031,17 @@ static enum dma_status fsl_tx_status(struct dma_chan *dchan,
dma_cookie_t cookie,
struct dma_tx_state *txstate)
{
+ struct fsldma_chan *chan = to_fsl_chan(dchan);
+ enum dma_status ret;
+
+ ret = dma_cookie_status(dchan, cookie, txstate);
+ if (ret == DMA_COMPLETE)
+ return ret;
+
+ spin_lock_bh(&chan->desc_lock);
+ fsldma_cleanup_descriptors(chan);
+ spin_unlock_bh(&chan->desc_lock);
+
return dma_cookie_status(dchan, cookie, txstate);
}
@@ -996,52 +1119,19 @@ static irqreturn_t fsldma_chan_irq(int irq, void *data)
static void dma_do_tasklet(unsigned long data)
{
struct fsldma_chan *chan = (struct fsldma_chan *)data;
- struct fsl_desc_sw *desc, *_desc;
- LIST_HEAD(ld_cleanup);
unsigned long flags;
chan_dbg(chan, "tasklet entry\n");
spin_lock_irqsave(&chan->desc_lock, flags);
- /* update the cookie if we have some descriptors to cleanup */
- if (!list_empty(&chan->ld_running)) {
- dma_cookie_t cookie;
-
- desc = to_fsl_desc(chan->ld_running.prev);
- cookie = desc->async_tx.cookie;
- dma_cookie_complete(&desc->async_tx);
-
- chan_dbg(chan, "completed_cookie=%d\n", cookie);
- }
-
- /*
- * move the descriptors to a temporary list so we can drop the lock
- * during the entire cleanup operation
- */
- list_splice_tail_init(&chan->ld_running, &ld_cleanup);
-
/* the hardware is now idle and ready for more */
chan->idle = true;
- /*
- * Start any pending transactions automatically
- *
- * In the ideal case, we keep the DMA controller busy while we go
- * ahead and free the descriptors below.
- */
- fsl_chan_xfer_ld_queue(chan);
- spin_unlock_irqrestore(&chan->desc_lock, flags);
-
- /* Run the callback for each descriptor, in order */
- list_for_each_entry_safe(desc, _desc, &ld_cleanup, node) {
-
- /* Remove from the list of transactions */
- list_del(&desc->node);
+ /* Run all cleanup for descriptors which have been completed */
+ fsldma_cleanup_descriptors(chan);
- /* Run all cleanup for this descriptor */
- fsldma_cleanup_descriptor(chan, desc);
- }
+ spin_unlock_irqrestore(&chan->desc_lock, flags);
chan_dbg(chan, "tasklet exit\n");
}
@@ -1225,6 +1315,7 @@ static int fsl_dma_chan_probe(struct fsldma_device *fdev,
spin_lock_init(&chan->desc_lock);
INIT_LIST_HEAD(&chan->ld_pending);
INIT_LIST_HEAD(&chan->ld_running);
+ INIT_LIST_HEAD(&chan->ld_completed);
chan->idle = true;
chan->common.device = &fdev->common;
diff --git a/drivers/dma/fsldma.h b/drivers/dma/fsldma.h
index d56e835..ec19517 100644
--- a/drivers/dma/fsldma.h
+++ b/drivers/dma/fsldma.h
@@ -138,8 +138,21 @@ struct fsldma_chan {
char name[8]; /* Channel name */
struct fsldma_chan_regs __iomem *regs;
spinlock_t desc_lock; /* Descriptor operation lock */
- struct list_head ld_pending; /* Link descriptors queue */
- struct list_head ld_running; /* Link descriptors queue */
+ /*
+ * Descriptors which are queued to run, but have not yet been
+ * submitted to the hardware for execution
+ */
+ struct list_head ld_pending;
+ /*
+ * Descriptors which are currently being executed by the hardware
+ */
+ struct list_head ld_running;
+ /*
+ * Descriptors which have finished execution by the hardware. These
+ * descriptors have already had their cleanup actions run. They are
+ * waiting for the ACK bit to be set by the async_tx API.
+ */
+ struct list_head ld_completed; /* Link descriptors queue */
struct dma_chan common; /* DMA common channel */
struct dma_pool *desc_pool; /* Descriptors pool */
struct device *dev; /* Channel device */
--
1.7.9.5
^ 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