* Re: Fix for fsl_upm
From: Kumar Gala @ 2011-11-24 7:46 UTC (permalink / raw)
To: Rusev; +Cc: Shaohui.Xie, linux-kernel, Shengzhou.Liu, paulus, linuxppc-dev
In-Reply-To: <4EA9683D.8030100@dev.rtsoft.ru>
On Oct 27, 2011, at 9:18 AM, Rusev wrote:
> patch is vs. 2.6.39, yet it applied to 3.1
>=20
>=20
>=20
> Fix of UPM driver for Freescale PowerPC processors
>=20
> If Freescale LBC driver fails to initialise itself from device tree,
> then internal structure is freed only but not NULL-fied.
> As result functions fsl_lbc_find() after checking the structure is not =
NULL are
> trying to access device registers.
>=20
> Signed-off-by: Alexandre Rusev <arusev@dev.rtsoft.ru>=20
applied to next
- k=
^ permalink raw reply
* RE: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
From: Li Yang-R58472 @ 2011-11-24 7:49 UTC (permalink / raw)
To: dedekind1@gmail.com, Liu Shuo-B35362
Cc: Artem.Bityutskiy@nokia.com, Wood Scott-B07421,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
linux-mtd@lists.infradead.org, akpm@linux-foundation.org,
dwmw2@infradead.org
In-Reply-To: <1322120515.24797.296.camel@sauron.fi.intel.com>
PiBTdWJqZWN0OiBSZTogW1BBVENIIDMvM10gbXRkL25hbmQgOiB3b3JrYXJvdW5kIGZvciBGcmVl
c2NhbGUgRkNNIHRvIHN1cHBvcnQNCj4gbGFyZ2UtcGFnZSBOYW5kIGNoaXANCj4gDQo+IE9uIFRo
dSwgMjAxMS0xMS0yNCBhdCAwODo0MSArMDgwMCwgYjM1MzYyQGZyZWVzY2FsZS5jb20gd3JvdGU6
DQo+ID4gKyAgICAgICAgICAgICAgIC8qDQo+ID4gKyAgICAgICAgICAgICAgICAqIEZyZWVzY2Fs
ZSBGQ00gY29udHJvbGxlciBoYXMgYSAySyBzaXplIGxpbWl0YXRpb24gb2YgYnVmZmVyDQo+ID4g
KyAgICAgICAgICAgICAgICAqIFJBTSwgc28gZWxiY19mY21fY3RybC0+YnVmZmVyIGhhdmUgdG8g
YmUgdXNlZCBpZiB3cml0ZXNpemUNCj4gPiArICAgICAgICAgICAgICAgICogb2YgY2hpcCBpcyBn
cmVhdGVyIHRoYW4gMjA0OC4NCj4gPiArICAgICAgICAgICAgICAgICogV2UgbWFsbG9jIGEgbGFy
Z2UgZW5vdWdoIGJ1ZmZlciAobWF4aW11bSBwYWdlIHNpemUgaXMNCj4gMTZLKS4NCj4gPiArICAg
ICAgICAgICAgICAgICovDQo+ID4gKyAgICAgICAgICAgICAgIGVsYmNfZmNtX2N0cmwtPmJ1ZmZl
ciA9IGttYWxsb2MoMTAyNCAqIDE2ICsgMTAyNCwNCj4gR0ZQX0tFUk5FTCk7DQo+IA0KPiBBcmUg
dGhlcmUgTkFORHMgd2l0aCAxNktpQiBwYWdlIHNpemU/DQoNCldlIGFyZSBub3Qgc3VyZSwgYnV0
IGFyZSB0aGVyZSBwb3NzaWJpbGl0eSB0aGF0IGNoaXAgd2l0aCAxNksgcGFnZSB3aWxsIGFwcGVh
cj8gIE9yIG1heWJlIHdlIGNhbiBhZGQgYSBNQUNSTyBmb3IgdGhlIG1heGltdW0gcGFnZSBzaXpl
Pw0KDQotIExlbw0K
^ permalink raw reply
* Re: [PATCH] net: fsl_pq_mdio: fix oops when using uninitialized mutex
From: Kumar Gala @ 2011-11-24 7:50 UTC (permalink / raw)
To: Andy Fleming; +Cc: netdev, Baruch Siach, linuxppc-dev, Andy Fleming
In-Reply-To: <CAKWjMd5WCx8pSJiL5U_WkD6XA5dSZLgLZkvMA6sjAKNuAz7PKg@mail.gmail.com>
On Nov 9, 2011, at 2:10 PM, Andy Fleming wrote:
>> Fix this by moving the of_mdiobus_register() call earlier.
>>=20
>> Cc: Andy Fleming <afleming@freescale.com>
>> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
>> ---
>> drivers/net/ethernet/freescale/fsl_pq_mdio.c | 14 +++++++-------
>> 1 files changed, 7 insertions(+), 7 deletions(-)
>>=20
>> diff --git a/drivers/net/ethernet/freescale/fsl_pq_mdio.c =
b/drivers/net/ethernet/freescale/fsl_pq_mdio.c
>> index 52f4e8a..e17fd2f 100644
>> --- a/drivers/net/ethernet/freescale/fsl_pq_mdio.c
>> +++ b/drivers/net/ethernet/freescale/fsl_pq_mdio.c
>> @@ -385,6 +385,13 @@ static int fsl_pq_mdio_probe(struct =
platform_device *ofdev)
>> tbiaddr =3D *prop;
>> }
>>=20
>> + err =3D of_mdiobus_register(new_bus, np);
>> + if (err) {
>> + printk (KERN_ERR "%s: Cannot register as MDIO bus\n",
>> + new_bus->name);
>> + goto err_free_irqs;
>> + }
>> +
>=20
>=20
> This fix totally breaks the point of setting tbipa beforehand.
> mdiobus_register will cause the bus to be scanned, and if any of the
> PHYs are at the default address for tbipa, they won't be found. I have
> a different fix which I will (re)submit today.
What happened here, did you send a patch?
- k=
^ permalink raw reply
* Re: [PATCH] P1021: set IReady in QE Microcode Upload
From: Kumar Gala @ 2011-11-24 7:55 UTC (permalink / raw)
To: Tabi Timur-B04825
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
Kokoris, Ioannis
In-Reply-To: <CAOZdJXXOrSaUgynqu+CL64SnivtOWHBDMcJK9Fh000M_JBK58Q@mail.gmail.com>
On Nov 15, 2011, at 9:02 PM, Tabi Timur-B04825 wrote:
> On Mon, Nov 14, 2011 at 2:55 AM, Kokoris, Ioannis
> <ioannis.kokoris@siemens-enterprise.com> wrote:
>> Ready register is needed for ROM-less devices such as P1021, MPC859, =
MPC8306 etc.
>> For ROM-based devices such as MCP8323 the Ready register does not =
exist.
>> Is there a global definition for conditionally including this code?
>=20
> I'll have to check. But this patch can't be applied as-is unless it's
> proven safe for all QE-enabled chips.
Any update on trying this on a MPC8323?
- k=
^ permalink raw reply
* Re: [PATCH] powerpc/usb: use ioremap instead of base plus offset to access regs
From: Kumar Gala @ 2011-11-24 7:57 UTC (permalink / raw)
To: Xie Shaohui-B21989
Cc: David Laight, linuxppc-dev@lists.ozlabs.org,
linux-usb@vger.kernel.org
In-Reply-To: <267A3B246C22C34A8E574051858E077017FA88@039-SN1MPN1-005.039d.mgd.msft.net>
On Nov 2, 2011, at 4:39 AM, Xie Shaohui-B21989 wrote:
>> -----Original Message-----
>> From: David Laight [mailto:David.Laight@ACULAB.COM]
>> Sent: Wednesday, November 02, 2011 5:07 PM
>> To: Xie Shaohui-B21989; linuxppc-dev@lists.ozlabs.org
>> Cc: linux-usb@vger.kernel.org
>> Subject: RE: [PATCH] powerpc/usb: use ioremap instead of base plus =
offset
>> to access regs
>>=20
>>=20
>>> #ifndef CONFIG_ARCH_MXC
>>> if (pdata->have_sysif_regs)
>>> - usb_sys_regs =3D (struct usb_sys_interface *)
>>> - ((u32)dr_regs + USB_DR_SYS_OFFSET);
>>> + usb_sys_regs =3D ioremap(res->start + USB_DR_SYS_OFFSET,
>>> + sizeof(struct
>> usb_sys_interface)/sizeof(int));
>>> #endif
>>=20
>> That ioremap() doesn't look right.
>> Isn't the 'size' in bytes??
> [Xie Shaohui] Yes, should not use sizeof(int).
>=20
>> (Although it will only matter if it crosses a page boundary.) Mind =
you,
>> I'd have though the original ioremap() should have covered the entire
>> structure??
> [Xie Shaohui] The original ioremap() did cover the entire structure, =
but the sysif_regs are not defined in dr_regs,
> So regs of sysif_regs cannot be accessed as a member of a structure, =
current driver handle this by type casting, this did work in 32-bit, but =
in 64-bit, this is not safe. So I use ioremap() to cover it again.
What's status on a new version of this patch.
Also, make sure to CC: Greg (gregkh@suse.de) on usb patches
- k=
^ permalink raw reply
* RE: [PATCH][RFC] fsldma: fix performance degradation by optimizing spinlock use.
From: Shi Xuelin-B29237 @ 2011-11-24 8:12 UTC (permalink / raw)
To: Ira W. Snyder
Cc: vinod.koul@intel.com, dan.j.williams@intel.com,
linuxppc-dev@lists.ozlabs.org, Li Yang-R58472,
linux-kernel@vger.kernel.org
In-Reply-To: <20111122185924.GA23323@ovro.caltech.edu>
Hi Ira,
Thanks for your review.
After second thought, I think your scenario may not occur.
Because the cookie 20 we query must be returned by fsl_dma_tx_submit(...) i=
n practice.=20
We never query a cookie not returned by fsl_dma_tx_submit(...).
When we call fsl_tx_status(20), the chan->common.cookie is definitely wrote=
as 20 and cpu2 could not read as 19.
How do you think?=20
Happy Thanks Giving day,
Forrest
-----Original Message-----
From: Ira W. Snyder [mailto:iws@ovro.caltech.edu]=20
Sent: 2011=1B$BG/=1B(B11=1B$B7n=1B(B23=1B$BF|=1B(B 2:59
To: Shi Xuelin-B29237
Cc: dan.j.williams@intel.com; Li Yang-R58472; zw@zh-kernel.org; vinod.koul@=
intel.com; linuxppc-dev@lists.ozlabs.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH][RFC] fsldma: fix performance degradation by optimizing=
spinlock use.
On Tue, Nov 22, 2011 at 12:55:05PM +0800, b29237@freescale.com wrote:
> From: Forrest Shi <b29237@freescale.com>
>=20
> dma status check function fsl_tx_status is heavily called in
> a tight loop and the desc lock in fsl_tx_status contended by
> the dma status update function. this caused the dma performance
> degrades much.
>=20
> this patch releases the lock in the fsl_tx_status function.
> I believe it has no neglect impact on the following call of
> dma_async_is_complete(...).
>=20
> we can see below three conditions will be identified as success
> a) x < complete < use
> b) x < complete+N < use+N
> c) x < complete < use+N
> here complete is the completed_cookie, use is the last_used
> cookie, x is the querying cookie, N is MAX cookie
>=20
> when chan->completed_cookie is being read, the last_used may
> be incresed. Anyway it has no neglect impact on the dma status
> decision.
>=20
> Signed-off-by: Forrest Shi <xuelin.shi@freescale.com>
> ---
> drivers/dma/fsldma.c | 5 -----
> 1 files changed, 0 insertions(+), 5 deletions(-)
>=20
> diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c index=20
> 8a78154..1dca56f 100644
> --- a/drivers/dma/fsldma.c
> +++ b/drivers/dma/fsldma.c
> @@ -986,15 +986,10 @@ static enum dma_status fsl_tx_status(struct dma_cha=
n *dchan,
> struct fsldma_chan *chan =3D to_fsl_chan(dchan);
> dma_cookie_t last_complete;
> dma_cookie_t last_used;
> - unsigned long flags;
> -
> - spin_lock_irqsave(&chan->desc_lock, flags);
> =20
This will cause a bug. See below for a detailed explanation. You need this =
instead:
/*
* On an SMP system, we must ensure that this CPU has seen the
* memory accesses performed by another CPU under the
* chan->desc_lock spinlock.
*/
smp_mb();
> last_complete =3D chan->completed_cookie;
> last_used =3D dchan->cookie;
> =20
> - spin_unlock_irqrestore(&chan->desc_lock, flags);
> -
> dma_set_tx_state(txstate, last_complete, last_used, 0);
> return dma_async_is_complete(cookie, last_complete, last_used); }
Facts:
- dchan->cookie is the same member as chan->common.cookie (same memory loca=
tion)
- chan->common.cookie is the "last allocated cookie for a pending transacti=
on"
- chan->completed_cookie is the "last completed transaction"
I have replaced "dchan->cookie" with "chan->common.cookie" in the below exp=
lanation, to keep everything referenced from the same structure.
Variable usage before your change. Everything is used locked.
- RW chan->common.cookie (fsl_dma_tx_submit)
- R chan->common.cookie (fsl_tx_status)
- R chan->completed_cookie (fsl_tx_status)
- W chan->completed_cookie (dma_do_tasklet)
Variable usage after your change:
- RW chan->common.cookie LOCKED
- R chan->common.cookie NO LOCK
- R chan->completed_cookie NO LOCK
- W chan->completed_cookie LOCKED
What if we assume that you have a 2 CPU system (such as a P2020). After you=
r changes, one possible sequence is:
=3D=3D=3D CPU1 - allocate + submit descriptor: fsl_dma_tx_submit() =3D=3D=
=3D spin_lock_irqsave
descriptor->cookie =3D 20 (x in your example)
chan->common.cookie =3D 20 (used in your example)
spin_unlock_irqrestore
=3D=3D=3D CPU2 - immediately calls fsl_tx_status() =3D=3D=3D
chan->common.cookie =3D=3D 19
chan->completed_cookie =3D=3D 19
descriptor->cookie =3D=3D 20
Since we don't have locks anymore, CPU2 may not have seen the write to
chan->common.cookie yet.
Also assume that the DMA hardware has not started processing the transactio=
n yet. Therefore dma_do_tasklet() has not been called, and
chan->completed_cookie has not been updated.
In this case, dma_async_is_complete() (on CPU2) returns DMA_SUCCESS, even t=
hough the DMA operation has not succeeded. The DMA operation has not even s=
tarted yet!
The smp_mb() fixes this, since it forces CPU2 to have seen all memory opera=
tions that happened before CPU1 released the spinlock. Spinlocks are implic=
it SMP memory barriers.
Therefore, the above example becomes:
smp_mb();
chan->common.cookie =3D=3D 20
chan->completed_cookie =3D=3D 19
descriptor->cookie =3D=3D 20
Then dma_async_is_complete() returns DMA_IN_PROGRESS, which is correct.
Thanks,
Ira
^ permalink raw reply
* Re: [PATCH] 8250: add workaround for MPC8[356]xx UART break IRQ storm
From: Kumar Gala @ 2011-11-24 8:14 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: linuxppc-dev, linux-serial
In-Reply-To: <1267212301-26851-1-git-send-email-paul.gortmaker@windriver.com>
On Feb 26, 2010, at 1:25 PM, Paul Gortmaker wrote:
> Sending a break on the SOC UARTs found in some MPC83xx/85xx/86xx
> chips seems to cause a short lived IRQ storm (/proc/interrupts
> typically shows somewhere between 300 and 1500 events). Unfortunately
> this renders SysRQ over the serial console completely inoperable.
> Testing with obvious things like ACKing the event doesn't seem to
> change anything vs. a completely dumb approach of just ignoring
> it and waiting for it to stop, so that is what is implemented here.
>=20
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
> ---
>=20
> This is a refresh of a patch I'd done earlier -- I've tried to make
> the bug support as generic as possible to minimize having board
> specific ifdef crap in 8250.c -- any suggestions on how to further
> improve it are welcome.
>=20
> drivers/serial/8250.c | 6 ++++++
> drivers/serial/8250.h | 20 ++++++++++++++++++++
> drivers/serial/Kconfig | 14 ++++++++++++++
> include/linux/serial_reg.h | 2 ++
> 4 files changed, 42 insertions(+), 0 deletions(-)
Did we ever decide what to do with this or trying to get it accepted =
upstream?
- k=
^ permalink raw reply
* RE: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
From: Artem Bityutskiy @ 2011-11-24 8:16 UTC (permalink / raw)
To: Li Yang-R58472
Cc: Wood Scott-B07421, Artem.Bityutskiy@nokia.com,
linuxppc-dev@lists.ozlabs.org, Liu Shuo-B35362,
linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org,
akpm@linux-foundation.org, dwmw2@infradead.org
In-Reply-To: <3F607A5180246847A760FD34122A1E052DC61F@039-SN1MPN1-003.039d.mgd.msft.net>
[-- Attachment #1: Type: text/plain, Size: 1257 bytes --]
On Thu, 2011-11-24 at 07:49 +0000, Li Yang-R58472 wrote:
> > Subject: Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support
> > large-page Nand chip
> >
> > On Thu, 2011-11-24 at 08:41 +0800, b35362@freescale.com wrote:
> > > + /*
> > > + * Freescale FCM controller has a 2K size limitation of buffer
> > > + * RAM, so elbc_fcm_ctrl->buffer have to be used if writesize
> > > + * of chip is greater than 2048.
> > > + * We malloc a large enough buffer (maximum page size is
> > 16K).
> > > + */
> > > + elbc_fcm_ctrl->buffer = kmalloc(1024 * 16 + 1024,
> > GFP_KERNEL);
> >
> > Are there NANDs with 16KiB page size?
>
> We are not sure, but are there possibility that chip with 16K page will appear? Or maybe we can add a MACRO for the maximum page size?
I do not know, but I know that allocating 32KiB of contiguous physical
RAM may cause unneeded memory pressure and even fail if the memory is
too fragmented. So I would not go for this unless this is necessary.
Did you try to look how the NAND base interface could be changed to
avoid re-allocation altogether, BTW?
--
Best Regards,
Artem Bityutskiy
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [patch 1/1] drivers/edac/mpc85xx_edac.c: fix memory controller compatible for edac
From: Kumar Gala @ 2011-11-24 8:25 UTC (permalink / raw)
To: akpm; +Cc: Shaohui.Xie, linuxppc-dev
In-Reply-To: <201111152252.pAFMqMYB032421@wpaz1.hot.corp.google.com>
On Nov 15, 2011, at 4:52 PM, akpm@linux-foundation.org wrote:
> From: Shaohui Xie <Shaohui.Xie@freescale.com>
> Subject: drivers/edac/mpc85xx_edac.c: fix memory controller compatible =
for edac
>=20
> compatible in dts has been changed, so the driver needs to be updated
> accordingly.
>=20
> Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
> Cc: Kumar Gala <galak@kernel.crashing.org>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
>=20
> drivers/edac/mpc85xx_edac.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
applied to merge
- k=
^ permalink raw reply
* Re: [PATCH] [v3] powerpc/fsl_msi: add support for the fsl, msi property in PCI nodes
From: Kumar Gala @ 2011-11-24 8:25 UTC (permalink / raw)
To: Timur Tabi; +Cc: miltonm, michael, linuxppc-dev, scottwood, tglx
In-Reply-To: <1320098795-7658-1-git-send-email-timur@freescale.com>
On Oct 31, 2011, at 5:06 PM, Timur Tabi wrote:
> On Freescale parts with multiple MSI controllers, the controllers are
> combined into one "pool" of interrupts. Whenever a device requests an =
MSI
> interrupt, the next available interrupt from the pool is selected,
> regardless of which MSI controller the interrupt is from. This works
> because each PCI bus has an ATMU to all of CCSR, so any PCI device can
> access any MSI interrupt register.
>=20
> The fsl,msi property is used to specify that a given PCI bus should =
only
> use a specific MSI device. This is necessary, for example, with the
> Freescale hypervisor, because the MSI devices are assigned to specific
> partitions.
>=20
> Ideally, we'd like to be able to assign MSI devices to PCI busses =
within
> the MSI or PCI layers. However, there does not appear to be a =
mechanism
> to do that. Whenever the MSI layer wants to allocate an MSI interrupt =
to
> a PCI device, it just calls arch_setup_msi_irqs(). It would be nice =
if we
> could register an MSI device with a specific PCI bus.
>=20
> So instead we remember the phandles of each MSI device, and we use =
that to
> limit our search for an available interrupt. Whenever we are asked to
> allocate a new interrupt for a PCI device, we check the fsl,msi =
property
> of the PCI bus for that device. If it exists, then as we are looping =
over
> all MSI devices, we skip the ones that don't have a matching phandle.
>=20
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
>=20
> v3: added check for invalid fsl,msi phandles
>=20
> arch/powerpc/sysdev/fsl_msi.c | 39 =
+++++++++++++++++++++++++++++++++++++++
> arch/powerpc/sysdev/fsl_msi.h | 3 +++
> 2 files changed, 42 insertions(+), 0 deletions(-)
applied to next
- k=
^ permalink raw reply
* Re: [PATCH] serial: Add missing call to init UCC UART port timeout
From: Kumar Gala @ 2011-11-24 8:25 UTC (permalink / raw)
To: Chuck Meade; +Cc: linuxppc-dev
In-Reply-To: <4C1B7312.6080708@ThePTRGroup.com>
On Jun 18, 2010, at 8:22 AM, Chuck Meade wrote:
> From: Chuck Meade <chuck@ThePTRGroup.com>
>
> The UCC UART driver is missing a call to uart_update_timeout().
> Without this call, attempting to close the port after outputting large
> amounts of data (i.e. using tty and uart buffering) results in long
> timeouts before the port will actually be shut down.
>
> For example, cat a large file to a UCC UART port. With the current
> driver, the port will stay open for 30 seconds after the last byte
> of data is output. But with this patch, the port is closed as
> expected, just after the data has been output (tx fifos empty).
>
> Signed-off-by: Chuck Meade <chuck@ThePTRGroup.com>
> ---
> drivers/serial/ucc_uart.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
applied to next
- k
^ permalink raw reply
* Re: [git pull] Please pull powerpc.git merge branch (updated)
From: Kumar Gala @ 2011-11-24 8:36 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <6E4772AD-8272-4A7D-8262-88C385CE9619@kernel.crashing.org>
Ben,
Pulled in a bunch of other minor fixes that have been sitting around for a
while.
- k
The following changes since commit caca6a03d365883564885f2c1da3e88dcf65d139:
Linux 3.2-rc3 (2011-11-23 20:20:28 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git merge
Alexandre Rusev (1):
powerpc/fsl-lbc: Fix for fsl_upm
Joakim Tjernlund (1):
powerpc/qe: Fixup QE_General4 errata
Julia Lawall (1):
arch/powerpc/sysdev/ehv_pic.c: add missing kfree
Kumar Gala (1):
powerpc/85xx: Fix compile error on p3060_qds.c
Paul Bolle (1):
powerpc/p3060qds: Fix select of 'MPC8xxx_GPIO'
Roy Zang (1):
powerpc/p1023: set IRQ[4:6,11] to active-high level sensitive for PCIe
Shaohui Xie (1):
drivers/edac/mpc85xx_edac.c: fix memory controller compatible for edac
arch/powerpc/boot/dts/p1023rds.dts | 17 +++++++++++++----
arch/powerpc/platforms/85xx/Kconfig | 2 +-
arch/powerpc/platforms/85xx/p3060_qds.c | 2 +-
arch/powerpc/sysdev/ehv_pic.c | 1 +
arch/powerpc/sysdev/fsl_lbc.c | 1 +
arch/powerpc/sysdev/qe_lib/qe.c | 2 +-
drivers/edac/mpc85xx_edac.c | 2 +-
7 files changed, 19 insertions(+), 8 deletions(-)
^ permalink raw reply
* [git pull] Please pull powerpc.git next branch
From: Kumar Gala @ 2011-11-24 8:39 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
Ben,
'next' branch pull request that includes 'merge' as well.
- k
The following changes since commit caca6a03d365883564885f2c1da3e88dcf65d139:
Linux 3.2-rc3 (2011-11-23 20:20:28 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git next
Alexandre Rusev (1):
powerpc/fsl-lbc: Fix for fsl_upm
Chuck Meade (1):
drivers/serial/ucc_uart.c: Add missing call to init UCC UART port timeout
Dmitry Eremin-Solenikov (6):
powerpc/83xx: consolidate init_IRQ functions
powerpc/83xx: consolidate of_platform_bus_probe calls
powerpc/83xx: merge PCI bridge additions
powerpc/83xx: make mpc830x_rdb use mpc83xx_setup_pci
powerpc/85xx: separate cpm2 pic init
powerpc/85xx: consolidate of_platform_bus_probe calls
Jason Jin (1):
powerpc/fsl-pci: Don't hide resource for pci/e when configured as Agent/EP
Jia Hongtao (1):
powerpc/85xx: Add lbc suspend support for PM
Joakim Tjernlund (1):
powerpc/qe: Fixup QE_General4 errata
Julia Lawall (1):
arch/powerpc/sysdev/ehv_pic.c: add missing kfree
Kai Jiang (1):
powerpc/8xxx: Update device tree bus probe for new RapidIO node binding
Kumar Gala (33):
powerpc/85xx: Fix compile error on p3060_qds.c
powerpc/85xx: Simplify P1020RDB CAMP dts using includes
powerpc/85xx: Rework PCI nodes on P1020RDB
powerpc/85xx: Update SPI binding to match binding spec for P1020RDB
powerpc/85xx: Update P1020 SEC3.3 node to match actual SoC HW
powerpc/85xx: Add ethernet magic packet property to P1020 device tree
powerpc/85xx: p1020si.dtsi update interrupt handling
powerpc/85xx: create dts components to build up an SoC
powerpc/85xx: Rework MPC8536DS device trees
powerpc/85xx: Rework MPC8544DS device tree
powerpc/85xx: Rework MPC8548CDS device trees
powerpc/85xx: Rework MPC8568MDS device tree
powerpc/85xx: Rework MPC8569MDS device tree
powerpc/85xx: Rework MPC8572DS device tree
powerpc/85xx: Rework P1010RDB and P1010 device tree
powerpc/85xx: Add RTC to P1010RDB device tree
powerpc/85xx: Add crypto engine to P1010 SoC device tree
powerpc/85xx: Add a P1010RDB 36-bit address map device tree
powerpc/85xx: Rework P1020RDB device tree
powerpc/85xx: Add P1020RDB 36-bit address map device tree
powerpc/85xx: Rework P1021MDS device tree
powerpc/85xx: Rework P1022DS device tree
powerpc/85xx: Rework P1023RDS device tree
powerpc/85xx: Rework P2020DS device tree
powerpc/85xx: Rework P2020RDB device tree
powerpc/85xx: Rework P2041RDB device tree
powerpc/85xx: Rework P3041DS device tree
powerpc/85xx: Rework P3060QDS device tree
powerpc/85xx: Rework P4080DS device trees
powerpc/85xx: Rework P5020DS device tree
powerpc/85xx: Update SRIO device tree nodes
powerpc/85xx: Additional consolidate of_platform_bus_probe calls
powerpc/85xx: Renamed mpc85xx_common.c to common.c
Liu Gang (3):
powerpc/fsl: Document rapidio node binding-information
fsl-rio: Split rio driver into two parts, RapidIO endpoint and message unit
fsl-rio: Add two ports and rapidio message units support
Paul Bolle (1):
powerpc/p3060qds: Fix select of 'MPC8xxx_GPIO'
Roy Zang (1):
powerpc/p1023: set IRQ[4:6,11] to active-high level sensitive for PCIe
Shaohui Xie (1):
drivers/edac/mpc85xx_edac.c: fix memory controller compatible for edac
Timur Tabi (2):
powerpc/85xx: add pixis indirect mode device tree node
powerpc/fsl_msi: add support for the fsl, msi property in PCI nodes
.../devicetree/bindings/powerpc/fsl/srio-rmu.txt | 163 +++
.../devicetree/bindings/powerpc/fsl/srio.txt | 103 ++
arch/powerpc/boot/dts/fsl/mpc8536si-post.dtsi | 248 ++++
arch/powerpc/boot/dts/fsl/mpc8536si-pre.dtsi | 63 +
arch/powerpc/boot/dts/fsl/mpc8544si-post.dtsi | 191 +++
arch/powerpc/boot/dts/fsl/mpc8544si-pre.dtsi | 63 +
arch/powerpc/boot/dts/fsl/mpc8548si-post.dtsi | 143 ++
arch/powerpc/boot/dts/fsl/mpc8548si-pre.dtsi | 62 +
arch/powerpc/boot/dts/fsl/mpc8568si-post.dtsi | 270 ++++
arch/powerpc/boot/dts/fsl/mpc8568si-pre.dtsi | 65 +
arch/powerpc/boot/dts/fsl/mpc8569si-post.dtsi | 304 ++++
arch/powerpc/boot/dts/fsl/mpc8569si-pre.dtsi | 64 +
arch/powerpc/boot/dts/fsl/mpc8572si-post.dtsi | 196 +++
arch/powerpc/boot/dts/fsl/mpc8572si-pre.dtsi | 70 +
arch/powerpc/boot/dts/fsl/p1010si-post.dtsi | 198 +++
arch/powerpc/boot/dts/fsl/p1010si-pre.dtsi | 64 +
arch/powerpc/boot/dts/fsl/p1020si-post.dtsi | 174 +++
arch/powerpc/boot/dts/fsl/p1020si-pre.dtsi | 68 +
arch/powerpc/boot/dts/fsl/p1021si-post.dtsi | 225 +++
arch/powerpc/boot/dts/fsl/p1021si-pre.dtsi | 68 +
arch/powerpc/boot/dts/fsl/p1022si-post.dtsi | 235 +++
arch/powerpc/boot/dts/fsl/p1022si-pre.dtsi | 68 +
arch/powerpc/boot/dts/fsl/p1023si-post.dtsi | 224 +++
arch/powerpc/boot/dts/fsl/p1023si-pre.dtsi | 76 +
arch/powerpc/boot/dts/fsl/p2020si-post.dtsi | 194 +++
arch/powerpc/boot/dts/fsl/p2020si-pre.dtsi | 69 +
arch/powerpc/boot/dts/fsl/p2041si-post.dtsi | 325 +++++
arch/powerpc/boot/dts/fsl/p2041si-pre.dtsi | 111 ++
arch/powerpc/boot/dts/fsl/p3041si-post.dtsi | 352 +++++
arch/powerpc/boot/dts/fsl/p3041si-pre.dtsi | 112 ++
arch/powerpc/boot/dts/fsl/p3060si-post.dtsi | 296 ++++
arch/powerpc/boot/dts/fsl/p3060si-pre.dtsi | 125 ++
arch/powerpc/boot/dts/fsl/p4080si-post.dtsi | 350 +++++
arch/powerpc/boot/dts/fsl/p4080si-pre.dtsi | 143 ++
arch/powerpc/boot/dts/fsl/p5020si-post.dtsi | 355 +++++
arch/powerpc/boot/dts/fsl/p5020si-pre.dtsi | 96 ++
arch/powerpc/boot/dts/fsl/pq3-dma-0.dtsi | 66 +
arch/powerpc/boot/dts/fsl/pq3-dma-1.dtsi | 66 +
arch/powerpc/boot/dts/fsl/pq3-duart-0.dtsi | 51 +
arch/powerpc/boot/dts/fsl/pq3-esdhc-0.dtsi | 41 +
arch/powerpc/boot/dts/fsl/pq3-espi-0.dtsi | 41 +
arch/powerpc/boot/dts/fsl/pq3-etsec1-0.dtsi | 53 +
arch/powerpc/boot/dts/fsl/pq3-etsec1-1.dtsi | 53 +
arch/powerpc/boot/dts/fsl/pq3-etsec1-2.dtsi | 53 +
arch/powerpc/boot/dts/fsl/pq3-etsec1-3.dtsi | 53 +
arch/powerpc/boot/dts/fsl/pq3-etsec1-timer-0.dtsi | 39 +
arch/powerpc/boot/dts/fsl/pq3-etsec2-0.dtsi | 60 +
arch/powerpc/boot/dts/fsl/pq3-etsec2-1.dtsi | 60 +
arch/powerpc/boot/dts/fsl/pq3-etsec2-2.dtsi | 59 +
arch/powerpc/boot/dts/fsl/pq3-etsec2-grp2-0.dtsi | 42 +
arch/powerpc/boot/dts/fsl/pq3-etsec2-grp2-1.dtsi | 42 +
arch/powerpc/boot/dts/fsl/pq3-etsec2-grp2-2.dtsi | 42 +
arch/powerpc/boot/dts/fsl/pq3-gpio-0.dtsi | 41 +
arch/powerpc/boot/dts/fsl/pq3-i2c-0.dtsi | 43 +
arch/powerpc/boot/dts/fsl/pq3-i2c-1.dtsi | 43 +
arch/powerpc/boot/dts/fsl/pq3-mpic-timer-B.dtsi | 42 +
arch/powerpc/boot/dts/fsl/pq3-mpic.dtsi | 66 +
arch/powerpc/boot/dts/fsl/pq3-rmu-0.dtsi | 68 +
arch/powerpc/boot/dts/fsl/pq3-sata2-0.dtsi | 40 +
arch/powerpc/boot/dts/fsl/pq3-sata2-1.dtsi | 40 +
arch/powerpc/boot/dts/fsl/pq3-sec2.1-0.dtsi | 43 +
arch/powerpc/boot/dts/fsl/pq3-sec3.0-0.dtsi | 45 +
arch/powerpc/boot/dts/fsl/pq3-sec3.1-0.dtsi | 45 +
arch/powerpc/boot/dts/fsl/pq3-sec3.3-0.dtsi | 45 +
arch/powerpc/boot/dts/fsl/pq3-sec4.4-0.dtsi | 65 +
arch/powerpc/boot/dts/fsl/pq3-usb2-dr-0.dtsi | 41 +
arch/powerpc/boot/dts/fsl/pq3-usb2-dr-1.dtsi | 41 +
arch/powerpc/boot/dts/fsl/qoriq-dma-0.dtsi | 66 +
arch/powerpc/boot/dts/fsl/qoriq-dma-1.dtsi | 66 +
arch/powerpc/boot/dts/fsl/qoriq-duart-0.dtsi | 51 +
arch/powerpc/boot/dts/fsl/qoriq-duart-1.dtsi | 51 +
arch/powerpc/boot/dts/fsl/qoriq-esdhc-0.dtsi | 40 +
arch/powerpc/boot/dts/fsl/qoriq-espi-0.dtsi | 41 +
arch/powerpc/boot/dts/fsl/qoriq-gpio-0.dtsi | 41 +
arch/powerpc/boot/dts/fsl/qoriq-i2c-0.dtsi | 53 +
arch/powerpc/boot/dts/fsl/qoriq-i2c-1.dtsi | 53 +
arch/powerpc/boot/dts/fsl/qoriq-mpic.dtsi | 106 ++
arch/powerpc/boot/dts/fsl/qoriq-rmu-0.dtsi | 68 +
arch/powerpc/boot/dts/fsl/qoriq-sata2-0.dtsi | 39 +
arch/powerpc/boot/dts/fsl/qoriq-sata2-1.dtsi | 39 +
arch/powerpc/boot/dts/fsl/qoriq-sec4.0-0.dtsi | 100 ++
arch/powerpc/boot/dts/fsl/qoriq-sec4.1-0.dtsi | 109 ++
arch/powerpc/boot/dts/fsl/qoriq-sec4.2-0.dtsi | 109 ++
arch/powerpc/boot/dts/fsl/qoriq-usb2-dr-0.dtsi | 41 +
arch/powerpc/boot/dts/fsl/qoriq-usb2-mph-0.dtsi | 41 +
arch/powerpc/boot/dts/mpc8536ds.dts | 456 +------
arch/powerpc/boot/dts/mpc8536ds.dtsi | 141 ++
arch/powerpc/boot/dts/mpc8536ds_36b.dts | 410 +-----
arch/powerpc/boot/dts/mpc8544ds.dts | 473 +------
arch/powerpc/boot/dts/mpc8544ds.dtsi | 161 +++
arch/powerpc/boot/dts/mpc8548cds.dts | 505 ++-----
arch/powerpc/boot/dts/mpc8568mds.dts | 482 +------
arch/powerpc/boot/dts/mpc8569mds.dts | 414 +-----
arch/powerpc/boot/dts/mpc8572ds.dts | 757 +----------
arch/powerpc/boot/dts/mpc8572ds.dtsi | 397 +++++
arch/powerpc/boot/dts/mpc8572ds_36b.dts | 746 +----------
arch/powerpc/boot/dts/mpc8572ds_camp_core0.dts | 487 +------
arch/powerpc/boot/dts/mpc8572ds_camp_core1.dts | 245 +---
arch/powerpc/boot/dts/mpc8641_hpcn.dts | 69 +-
arch/powerpc/boot/dts/p1010rdb.dts | 228 +---
arch/powerpc/boot/dts/p1010rdb.dtsi | 229 +++
arch/powerpc/boot/dts/p1010rdb_36b.dts | 89 ++
arch/powerpc/boot/dts/p1010si.dtsi | 374 -----
arch/powerpc/boot/dts/p1020rdb.dts | 262 +----
arch/powerpc/boot/dts/p1020rdb.dtsi | 242 ++++
arch/powerpc/boot/dts/p1020rdb_36b.dts | 66 +
arch/powerpc/boot/dts/p1020rdb_camp_core0.dts | 154 +--
arch/powerpc/boot/dts/p1020rdb_camp_core1.dts | 11 +-
arch/powerpc/boot/dts/p1020si.dtsi | 377 -----
arch/powerpc/boot/dts/p1021mds.dts | 421 +-----
arch/powerpc/boot/dts/p1022ds.dts | 449 +------
arch/powerpc/boot/dts/p1023rds.dts | 383 +-----
arch/powerpc/boot/dts/p2020ds.dts | 353 +-----
arch/powerpc/boot/dts/p2020ds.dtsi | 316 ++++
arch/powerpc/boot/dts/p2020rdb.dts | 63 +-
arch/powerpc/boot/dts/p2020rdb_camp_core0.dts | 141 +--
arch/powerpc/boot/dts/p2020rdb_camp_core1.dts | 107 +--
arch/powerpc/boot/dts/p2020si.dtsi | 382 -----
arch/powerpc/boot/dts/p2041rdb.dts | 22 +-
arch/powerpc/boot/dts/p2041si.dtsi | 692 ---------
arch/powerpc/boot/dts/p3041ds.dts | 23 +-
arch/powerpc/boot/dts/p3041si.dtsi | 729 ----------
arch/powerpc/boot/dts/p3060qds.dts | 12 +-
arch/powerpc/boot/dts/p3060si.dtsi | 719 ---------
arch/powerpc/boot/dts/p4080ds.dts | 24 +-
arch/powerpc/boot/dts/p4080si.dtsi | 755 ----------
arch/powerpc/boot/dts/p5020ds.dts | 24 +-
arch/powerpc/boot/dts/p5020si.dtsi | 716 ---------
arch/powerpc/include/asm/fsl_lbc.h | 7 +-
arch/powerpc/kernel/pci-common.c | 3 +
arch/powerpc/platforms/83xx/asp834x.c | 35 +-
arch/powerpc/platforms/83xx/km83xx.c | 58 +-
arch/powerpc/platforms/83xx/misc.c | 77 +
arch/powerpc/platforms/83xx/mpc830x_rdb.c | 40 +-
arch/powerpc/platforms/83xx/mpc831x_rdb.c | 43 +-
arch/powerpc/platforms/83xx/mpc832x_mds.c | 53 +-
arch/powerpc/platforms/83xx/mpc832x_rdb.c | 56 +-
arch/powerpc/platforms/83xx/mpc834x_itx.c | 30 +-
arch/powerpc/platforms/83xx/mpc834x_mds.c | 42 +-
arch/powerpc/platforms/83xx/mpc836x_mds.c | 53 +-
arch/powerpc/platforms/83xx/mpc836x_rdk.c | 48 +-
arch/powerpc/platforms/83xx/mpc837x_mds.c | 46 +-
arch/powerpc/platforms/83xx/mpc837x_rdb.c | 47 +-
arch/powerpc/platforms/83xx/mpc83xx.h | 16 +
arch/powerpc/platforms/83xx/sbc834x.c | 45 +-
arch/powerpc/platforms/85xx/Kconfig | 2 +-
arch/powerpc/platforms/85xx/Makefile | 2 +
arch/powerpc/platforms/85xx/common.c | 66 +
arch/powerpc/platforms/85xx/corenet_ds.c | 2 +-
arch/powerpc/platforms/85xx/ksi8560.c | 46 +-
arch/powerpc/platforms/85xx/mpc8536_ds.c | 16 +-
arch/powerpc/platforms/85xx/mpc85xx.h | 11 +
arch/powerpc/platforms/85xx/mpc85xx_ads.c | 52 +-
arch/powerpc/platforms/85xx/mpc85xx_cds.c | 16 +-
arch/powerpc/platforms/85xx/mpc85xx_ds.c | 20 +-
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 47 +-
arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 18 +-
arch/powerpc/platforms/85xx/p1010rdb.c | 15 +-
arch/powerpc/platforms/85xx/p1022_ds.c | 7 +-
arch/powerpc/platforms/85xx/p1023_rds.c | 19 +-
arch/powerpc/platforms/85xx/p3060_qds.c | 2 +-
arch/powerpc/platforms/85xx/sbc8548.c | 18 +-
arch/powerpc/platforms/85xx/sbc8560.c | 52 +-
arch/powerpc/platforms/85xx/socrates.c | 13 +-
arch/powerpc/platforms/85xx/stx_gp3.c | 51 +-
arch/powerpc/platforms/85xx/tqm85xx.c | 51 +-
arch/powerpc/platforms/85xx/xes_mpc85xx.c | 20 +-
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 2 +-
arch/powerpc/sysdev/Makefile | 2 +-
arch/powerpc/sysdev/ehv_pic.c | 1 +
arch/powerpc/sysdev/fsl_lbc.c | 37 +
arch/powerpc/sysdev/fsl_msi.c | 39 +
arch/powerpc/sysdev/fsl_msi.h | 3 +
arch/powerpc/sysdev/fsl_rio.c | 1519 ++++----------------
arch/powerpc/sysdev/fsl_rio.h | 135 ++
arch/powerpc/sysdev/fsl_rmu.c | 1103 ++++++++++++++
arch/powerpc/sysdev/qe_lib/qe.c | 2 +-
drivers/edac/mpc85xx_edac.c | 2 +-
drivers/tty/serial/ucc_uart.c | 3 +
179 files changed, 12808 insertions(+), 13967 deletions(-)
create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/srio-rmu.txt
create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/srio.txt
create mode 100644 arch/powerpc/boot/dts/fsl/mpc8536si-post.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/mpc8536si-pre.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/mpc8544si-post.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/mpc8544si-pre.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/mpc8548si-post.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/mpc8548si-pre.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/mpc8568si-post.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/mpc8568si-pre.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/mpc8569si-post.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/mpc8569si-pre.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/mpc8572si-post.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/mpc8572si-pre.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/p1010si-post.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/p1010si-pre.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/p1020si-post.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/p1020si-pre.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/p1021si-post.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/p1021si-pre.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/p1022si-post.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/p1022si-pre.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/p1023si-post.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/p1023si-pre.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/p2020si-post.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/p2020si-pre.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/p2041si-post.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/p2041si-pre.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/p3041si-post.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/p3041si-pre.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/p3060si-post.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/p3060si-pre.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/p4080si-post.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/p4080si-pre.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/p5020si-post.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/p5020si-pre.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/pq3-dma-0.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/pq3-dma-1.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/pq3-duart-0.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/pq3-esdhc-0.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/pq3-espi-0.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/pq3-etsec1-0.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/pq3-etsec1-1.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/pq3-etsec1-2.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/pq3-etsec1-3.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/pq3-etsec1-timer-0.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/pq3-etsec2-0.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/pq3-etsec2-1.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/pq3-etsec2-2.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/pq3-etsec2-grp2-0.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/pq3-etsec2-grp2-1.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/pq3-etsec2-grp2-2.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/pq3-gpio-0.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/pq3-i2c-0.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/pq3-i2c-1.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/pq3-mpic-timer-B.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/pq3-mpic.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/pq3-rmu-0.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/pq3-sata2-0.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/pq3-sata2-1.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/pq3-sec2.1-0.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/pq3-sec3.0-0.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/pq3-sec3.1-0.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/pq3-sec3.3-0.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/pq3-sec4.4-0.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/pq3-usb2-dr-0.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/pq3-usb2-dr-1.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-dma-0.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-dma-1.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-duart-0.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-duart-1.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-esdhc-0.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-espi-0.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-gpio-0.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-i2c-0.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-i2c-1.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-mpic.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-rmu-0.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-sata2-0.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-sata2-1.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-sec4.0-0.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-sec4.1-0.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-sec4.2-0.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-usb2-dr-0.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-usb2-mph-0.dtsi
create mode 100644 arch/powerpc/boot/dts/mpc8536ds.dtsi
create mode 100644 arch/powerpc/boot/dts/mpc8544ds.dtsi
create mode 100644 arch/powerpc/boot/dts/mpc8572ds.dtsi
create mode 100644 arch/powerpc/boot/dts/p1010rdb.dtsi
create mode 100644 arch/powerpc/boot/dts/p1010rdb_36b.dts
delete mode 100644 arch/powerpc/boot/dts/p1010si.dtsi
create mode 100644 arch/powerpc/boot/dts/p1020rdb.dtsi
create mode 100644 arch/powerpc/boot/dts/p1020rdb_36b.dts
delete mode 100644 arch/powerpc/boot/dts/p1020si.dtsi
create mode 100644 arch/powerpc/boot/dts/p2020ds.dtsi
delete mode 100644 arch/powerpc/boot/dts/p2020si.dtsi
delete mode 100644 arch/powerpc/boot/dts/p2041si.dtsi
delete mode 100644 arch/powerpc/boot/dts/p3041si.dtsi
delete mode 100644 arch/powerpc/boot/dts/p3060si.dtsi
delete mode 100644 arch/powerpc/boot/dts/p4080si.dtsi
delete mode 100644 arch/powerpc/boot/dts/p5020si.dtsi
create mode 100644 arch/powerpc/platforms/85xx/common.c
create mode 100644 arch/powerpc/platforms/85xx/mpc85xx.h
create mode 100644 arch/powerpc/sysdev/fsl_rio.h
create mode 100644 arch/powerpc/sysdev/fsl_rmu.c
^ permalink raw reply
* Re: [PATCH] powerpc/40x: Add APM8018X SOC support
From: Tanmay Inamdar @ 2011-11-24 9:07 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <CA+5PVA4wpGfSXbX9oTdtDaGiWFkwZfiL9Md6SGJpXtOK6rG2ww@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 18335 bytes --]
Hello Josh,
Thanks for the review. The comments are appreciated. Please see my inline
replies.
Thanks,
Tanmay
On Wed, Nov 23, 2011 at 7:40 PM, Josh Boyer <jwboyer@gmail.com> wrote:
> On Wed, Nov 23, 2011 at 4:44 AM, Tanmay Inamdar <tinamdar@apm.com> wrote:
> >
> > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> > index b177caa..3f2cc36 100644
> > --- a/arch/powerpc/Kconfig
> > +++ b/arch/powerpc/Kconfig
> > @@ -978,3 +978,9 @@ config PPC_LIB_RHEAP
> > bool
> >
> > source "arch/powerpc/kvm/Kconfig"
> > +
> > +config UART_16550_WORD_ADDRESSABLE
> > + bool
> > + default n
> > + help
> > + Enable this if your UART 16550 is word addressable.
>
> Ugh. What is this for? More specifically, if the UART requires word
> reads and writes, shouldn't it be using reg-shift/reg-offset in the
> device tree? I'm confused why UDBG would need this sort of code, but
> the runtime serial driver doesn't?
>
It seems the name 'UART_16550_WORD_ADDRESSABLE' is confusing here.
The UART has been modeled after the industry-standard 16550. However,
the register address space has been relocated to 32-bit data boundaries.
For each register, only 1st bit is valid and rest 3 bits are just reserved
and read
as zero. Hence we need to pack the structure accordingly.
runtime serial driver also needs changes in register definitions. However
it is not
included in this patch.
In the next version of patch, I will remove UART stuff. I will make
separate patch
for UART.
>
> > diff --git a/arch/powerpc/boot/dts/klondike.dts
> b/arch/powerpc/boot/dts/klondike.dts
>
>
> > + OCM: ocm@20000000 {
> > + compatible = "ibm,ocm";
> > + status = "enabled";
> > + cell-index = <1>;
> > + reg = < 0x20000000 0x1f000 /* 128K - 4K NAND */
> > + 0xfffe0000 0x1f000>; /* 128K - 4K I2C */
> > + bootmode = "nand";
> > + };
>
> What is this? There's nothing in the kernel or in this patch that
> binds with "ibm,ocm". Also, that 'bootmode' property doesn't seem
> like a hardware value, but a human descriptor of something that
> switches it to boot from NAND.
>
> OCM driver is not yet submitted. I will skip the blocks in the dts which
are still
not supported in the next version.
You are right about bootmode. OCM gets mapped to different addresses in
different boot modes. Uboot takes care of updating this parameter.
>
> > + crypto: crypto@40000000 {
> > + device_type = "crypto";
> > + compatible = "405ex-crypto",
> "amcc,ppc405ex-crypto", "amcc,ppc4xx-crypto";
>
> Why is the "405ex-crypto" string there?
>
> > + EDMA: edma@40080000 {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + compatible = "amcc,edma";
> > + device_type = "dma";
> > + /*complQ-fifo-memory = "ocm";*/
> > + cell-index = <0>;
> > + reg = <0x40080000 0x00010000>;
> > + dcr-reg = <0x060 0x09f>;
> > +
> > + interrupt-parent = <&UIC0>;
> > + interrupts = </*complQ A */ 0x4 4
> > + /*EDMA Err */ 0x6 4 >;
> > +
> > + dma-channel@0 {
> > + compatible = "amcc,edma-channel";
> > + /*descriptor-memory = "ocm";*/
> > + cell-index = <0>;
> > + dcr-reg = <0x0000006a 0x0000006b>;
> > + };
> > + };
>
> What's this? Again, nothing binds to "amcc,edma" in the kernel or
> patch. At the very least this (and OCM above) need some binding
> descriptions added to Documentation/devicetree/bindings/powerpc/4xx/
>
I will skip this in next patch. I will consider the bindings.
> > +
> > + MSI: dwc_pcie-msi@40090000 {
> > + compatible = "amcc,dwc_pcie-msi", "dwc_pcie-msi";
> > + status = "ok";
>
> Is the status property something that is set by U-Boot, or will it
> always be "ok"? If the latter, I don't think you need to specify it
> at all.
>
>
Correct. There is no need of status. MSI is always enabled
> > + reg = <0x40090000 0x100>;
> > + interrupts =<0x0 0x1 0x2 0x3>;
> > + interrupt-parent = <&MSI>;
> > + #interrupt-cells = <1>;
> > + #address-cells = <0>;
> > + #size-cells = <0>;
> > + interrupt-map = <0x0 &UIC0 0x0C 0x1
> > + 0x1 &UIC0 0x0D 0x1
> > + 0x2 &UIC0 0x0E 0x1
> > + 0x3 &UIC0 0x0F 0x1>;
> > + };
>
> Same binding comment here.
>
> > +
> > + AHB: ahb {
> > + device_type = "ahb";
>
> I doubt the device_type is needed.
>
I believe device_type can be skipped in most of the cases.
I will take care of this in next revision of patch.
>
> > + compatible = "amcc,405ex-ahb", "ibm,ahb";
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + ranges;
> > + clock-frequency = <0>; /* Filled in by U-Boot */
>
> Same binding comment for ahb.
>
> > +
> > + lcd: lcd@58060000 {
> > + device_type = "lcd";
>
> Drop device_type.
>
> > + compatible = "apm,apm-lcd","apm,db9000";
> > + version = "apm-1.1";
>
> Why is 'version' there? Version of what? The hardware itself, the
> driver? I doubt this is needed.
>
It is chip version. There are some changes in this block with respect to
chip
revision. The PVR remains the same as old chip revision and there is no
other register to specify revision. Uboot updates this parameter.
I will skip this block from next patch and will reintroduce it when the
actual
driver is added.
> > + reg = <0x58060000 0x00001000>;
> > + interrupt-parent = <&UIC0>;
> > + /*
> > + * interrupt index 0 for chip 1.0
> > + * interrupt index 1 for chip 1.1
> > + */
> > + interrupts = <0x1c 2 0x1c 4>;
> > + };
>
> Same binding comment for apm,apm-lcd. I'm just going to assert again
> that anything that doesn't have a defined binding and/or driver needs
> to be documented when it's introduced. Repeat that for the rest of
> the patch :).
>
Yes.
>
> > +
> > + sdhc0: sdhc@58050000 {
> > + device_type = "sdhc";
>
> Drop device_type.
>
> > + compatible = "amcc,ahb-sdhc";
> > + #interrupt-cells = <1>;
> > + reg = <0x58050000 0x100>;
> > + interrupt-parent = <&UIC0>;
> > + interrupts = <0x18 0x4>;
> > + bootmode = "i2c";
> > + };
> > +
> > + tdm0: tdm@58010000 {
> > + device_type = "tdm";
>
> Drop device_type.
>
> > + status = "disabled";
>
> Is that set by U-Boot?
>
Yes. The chip is multiplexed. Some IPs get disabled/enabled based on
bootmodes.
>
> > + compatible = "apm,ahb-tdm";
> > + #interrupt-cells = <1>;
> > + reg = <0x58010000 0x100>;
> > + interrupt-parent = <&UIC1>;
> > + interrupts = <0x15 0x1>;
> > + };
> > +
> > + usbotg0: usbotg@58080000 {
> > + device_type = "usb";
>
> Drop device_type.
>
> > + compatible = "apm,usb-otg";
> > + reg = <0x58080000 0x10000>;
> > + interrupt-parent = <&UIC0>;
> > + interrupts = <0x1B 4>;
> > + mode = "host";
> > + };
> > + spi0: spi@50000000 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + device_type = "spi";
>
> Drop device_type. I think you're starting to get the trend, so repeat
> for the rest of the devices.
>
> > + compatible = "apm,apm-spi";
> > + reg = <0x50000000 0x100>;
> > + interrupt-parent = <&UIC0>;
> > + interrupts = <0x7 1>; /* interrupt
> number->0x7 Polarity->HIGH Sensitivity->LEVEL */
> > + half_duplex = <0x1>; /*0 = rx/tx mode,
> 1 = eprom read mode */
> > + sysclk = <100000000>; /* input clock */
> > + bus_num = <0x0>; /* SPI = 0 */
>
> > +
> > + PCIE0: pciex@58020000 {
> > + device_type = "pci";
> > + compatible = "ibm,plb-pciex",
> "dwc-pciex", "amcc,dwc-pciex";
>
> Why the unprefixed dwc-pciex compatible property?
>
I will correct it.
> > + #interrupt-cells = <1>;
> > + #size-cells = <2>;
> > + #address-cells = <3>;
> > + primary;
> > + port = <0>; /* port number */
> > + status = "ok";
>
>
> > + PCIE1: pciex@58030000 {
> > + device_type = "pci";
> > + compatible = "ibm,plb-pciex",
> "dwc-pciex", "amcc,dwc-pciex";
> > + #interrupt-cells = <1>;
> > + #size-cells = <2>;
> > + #address-cells = <3>;
> > + primary;
> > + port = <1>; /* port number */
> > + status = "disabled";
>
> Is this set by U-Boot?
>
Yes. Same as multiplexed comment.
>
>
> > + sata@58040000 {
> > + compatible = "sata-ahci";
>
> Uh.. what?
>
It is designware SATA IP compatible with AHCI standard.
I will reintroduce this block along with its driver.
>
> > + reg = <0x58040000 0x2000>;
> > + interrupt-parent = <&UIC0>;
> > + interrupts = <0x1a 1>;
>
>
> > + ufc@0xFE000000 {
> > + compatible = "ibm,ufc";
> > + reg = <0xFE000000 0x00010000>;
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + bootmode = "nand";
>
> Is UFC some kind of new flash controller that isn't NDFC? Also,
> bootmode seems to be a human and/or driver variable, not a description
> of the hardware.
>
Yes. UFC is new flash controller. You are right about bootmode.
> > + UART0: serial@50001000 {
> > + device_type = "serial";
> > + compatible = "ns16550";
> > + reg = <0x50001000 0x00000100>;
> > + virtual-reg = <0x50001000>;
> > + clock-frequency = <300000000>; /* Filled
> in by U-Boot */
> > + current-speed = <115200>;
> > + interrupt-parent = <&UIC0>;
> > + interrupts = <0x0 0x4>;
> > + /*reg-shift = <2>;*/
>
> This is commented out, but seems to be needed when you take the
> word-addressed UDBG thing into account?
>
Yes. I will rethink on how it is implemented.
>
> > + IEEE1588_0: ieee1588ts0@400a5000 {
> > + status = "ok";
> > + compatible = "ieee1588-ts";
>
> What is that?
>
This is AMCC IEEE1588 block. I will correct the compatible string.
> > diff --git a/arch/powerpc/configs/40x/klondike_defconfig
> b/arch/powerpc/configs/40x/klondike_defconfig
> > new file mode 100644
> > index 0000000..840f438
> > --- /dev/null
> > +++ b/arch/powerpc/configs/40x/klondike_defconfig
> > @@ -0,0 +1,1353 @@
> > +#
> > +# Automatically generated file; DO NOT EDIT.
> > +# Linux/powerpc 3.2.0-rc2 Kernel Configuration
> > +#
> > +# CONFIG_PPC64 is not set
>
> This is a full defconfig. We don't need a full config file. You can
> generate one with 'make savedefconfig' that contains only the options
> you need to set.
>
> I will do that.
>
>
>
> > diff --git a/arch/powerpc/kernel/udbg_16550.c
> b/arch/powerpc/kernel/udbg_16550.c
> > index 6837f83..dd3bce9 100644
> > --- a/arch/powerpc/kernel/udbg_16550.c
> > +++ b/arch/powerpc/kernel/udbg_16550.c
> > @@ -18,6 +18,19 @@ extern void real_writeb(u8 data, volatile u8 __iomem
> *addr);
> > extern u8 real_205_readb(volatile u8 __iomem *addr);
> > extern void real_205_writeb(u8 data, volatile u8 __iomem *addr);
> >
> > +#ifdef CONFIG_UART_16550_WORD_ADDRESSABLE
> > +struct NS16550 {
> > + /* this struct must be packed */
> > + unsigned char rbr; /* 0 */ u8 s0[3];
>
> An array of length 3 for something "word-addressable"? When did words
> change to 3 bytes? Now, I still haven't finished my coffee yet, but
> that is really confusing.
>
Again the name WORD_ADDRESSABLE is confusing. Hopefully my previous
comment clears the confusion.
> > + unsigned char ier; /* 1 */ u8 s1[3];
> > + unsigned char fcr; /* 2 */ u8 s2[3];
> > + unsigned char lcr; /* 3 */ u8 s3[3];
> > + unsigned char mcr; /* 4 */ u8 s4[3];
> > + unsigned char lsr; /* 5 */ u8 s5[3];
> > + unsigned char msr; /* 6 */ u8 s6[3];
> > + unsigned char scr; /* 7 */ u8 s7[3];
> > +};
> > +#else
> > struct NS16550 {
> > /* this struct must be packed */
> > unsigned char rbr; /* 0 */
> > @@ -29,6 +42,7 @@ struct NS16550 {
> > unsigned char msr; /* 6 */
> > unsigned char scr; /* 7 */
> > };
> > +#endif /* CONFIG_UART_16550_WORD_ADDRESSABLE */
> >
> > #define thr rbr
> > #define iir fcr
> > @@ -52,8 +66,16 @@ static struct NS16550 __iomem *udbg_comport;
> > static void udbg_550_flush(void)
> > {
> > if (udbg_comport) {
> > +#if defined(CONFIG_APM8018X)
> > + int index;
> > + for (index = 0; index < 3500; index++) {
> > + if ((in_8(&udbg_comport->lsr) & LSR_THRE) ==
> LSR_THRE)
> > + break;
> > + }
> > +#else
>
> What is index, and why do you read the same register 3500 times? That
> doesn't sound like an index, it sounds like some kind of poor-mans
> timeout.
>
This is hardware bug. Ideally there should not be any change in the code. I
will try to
fix it in better way.
>
> > while ((in_8(&udbg_comport->lsr) & LSR_THRE) == 0)
> > /* wait for idle */;
> > +#endif /* CONFIG_APM8018X */
> > }
> > }
> >
> > diff --git a/arch/powerpc/platforms/40x/Kconfig
> b/arch/powerpc/platforms/40x/Kconfig
> > index 1530229..3d0d1d9 100644
> > --- a/arch/powerpc/platforms/40x/Kconfig
> > +++ b/arch/powerpc/platforms/40x/Kconfig
> > @@ -186,3 +186,14 @@ config IBM405_ERR51
> > # bool
> > # depends on !STB03xxx && PPC4xx_DMA
> > # default y
> > +#
> > +
> > +config APM8018X
> > + bool "APM8018X"
> > + depends on 40x
> > + default y
>
> default n please.
>
Yes.
>
> > + select PPC40x_SIMPLE
> > + select UART_16550_WORD_ADDRESSABLE
> > + help
> > + This option enables support for the AppliedMicro Klondike
> board.
> > +
> > diff --git a/arch/powerpc/platforms/40x/ppc40x_simple.c
> b/arch/powerpc/platforms/40x/ppc40x_simple.c
> > index e8dd5c5..c8576af 100644
> > --- a/arch/powerpc/platforms/40x/ppc40x_simple.c
> > +++ b/arch/powerpc/platforms/40x/ppc40x_simple.c
> > @@ -17,7 +17,7 @@
> > #include <asm/pci-bridge.h>
> > #include <asm/ppc4xx.h>
> > #include <asm/prom.h>
> > -#include <asm/time.h>
> > +#include <linux/time.h>
>
> Is this needed for a reason? If so, it should be submitted as a separate
> patch.
>
checkpatch.pl scripts throws warning. It asks to change <asm/time.h> to
<linux/time.h>
> > #include <asm/udbg.h>
> > #include <asm/uic.h>
> >
> > @@ -29,6 +29,7 @@ static __initdata struct of_device_id ppc40x_of_bus[]
> = {
> > { .compatible = "ibm,plb4", },
> > { .compatible = "ibm,opb", },
> > { .compatible = "ibm,ebc", },
> > + { .compatible = "ibm,ahb", },
> > { .compatible = "simple-bus", },
> > {},
> > };
> > @@ -55,6 +56,7 @@ static const char *board[] __initdata = {
> > "amcc,haleakala",
> > "amcc,kilauea",
> > "amcc,makalu",
> > + "amcc,klondike",
> > "est,hotfoot"
> > };
> >
> > --
> > 1.6.1.rc3
> >
> >
>
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments,
is for the sole use of the intended recipient(s) and contains information
that is confidential and proprietary to AppliedMicro Corporation or its subsidiaries.
It is to be used solely for the purpose of furthering the parties' business relationship.
All unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by reply e-mail
and destroy all copies of the original message.
[-- Attachment #2: Type: text/html, Size: 25957 bytes --]
^ permalink raw reply
* Re: [PATCH] USB: fsl_udc_core: Use (&) instead of (==) to compare ISO XFER
From: Felipe Balbi @ 2011-11-24 9:37 UTC (permalink / raw)
To: Michal Nazarewicz
Cc: gregkh, linux-usb, balbi, Peter Chen, linuxppc-dev, stable
In-Reply-To: <op.v5bqaaw33l0zgt@mpn-glaptop>
[-- Attachment #1: Type: text/plain, Size: 900 bytes --]
On Tue, Nov 22, 2011 at 02:26:24AM +0100, Michal Nazarewicz wrote:
> >On Tue, 22 Nov 2011 02:15:21 +0100, Peter Chen <peter.chen@freescale.com> wrote:
> >>@@ -877,7 +877,7 @@ fsl_ep_queue(struct usb_ep *_ep, struct usb_request *_req, gfp_t gfp_flags)
> >> VDBG("%s, bad ep", __func__);
> >> return -EINVAL;
> >> }
> >>- if (ep->desc->bmAttributes == USB_ENDPOINT_XFER_ISOC) {
> >>+ if (ep->desc->bmAttributes & USB_ENDPOINT_XFER_ISOC) {
>
> On Tue, 22 Nov 2011 02:22:10 +0100, Michal Nazarewicz <mina86@mina86.com> wrote:
> >What you really meant is:
> >
> >(ep->desc->bmAttributes & USB_ENDPOINT_XFERTYPE_MASK) == USB_ENDPOINT_XFER_ISOC
> >
> >It would probably be useful to create a function that performs that check rather
> >than having to type all of that every time.
>
> Ah, there it is:
>
> usb_endpoint_xfer_isoc(ep)
yeah, please use the helpers.
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] usb/fsl_udc: fix dequeuing a request in progress
From: Felipe Balbi @ 2011-11-24 9:32 UTC (permalink / raw)
To: Li Yang-R58472
Cc: linux-usb@vger.kernel.org, Chen Peter-B29397, gregkh@suse.de,
balbi@ti.com, linuxppc-dev@lists.ozlabs.org, Peter Chen
In-Reply-To: <3F607A5180246847A760FD34122A1E052DB395@039-SN1MPN1-003.039d.mgd.msft.net>
[-- Attachment #1: Type: text/plain, Size: 1079 bytes --]
On Wed, Nov 23, 2011 at 08:20:54AM +0000, Li Yang-R58472 wrote:
> >Leo, I have debugged this issue at my board just now, the reason of
> >failure is we only have one ep struct for ep0, so when talking about ep0,
> >it always pointers to udc->ep[0]. So even we initialize the current qh
> >address for ep0in at probe, it still can't get the ep0in's qh address
> >through ep structure, as ep0 is always udc->ep[0].
>
> Oops. I forgot the fact that we used a single ep structure to handle
> both IN and OUT ep0 because the gadget layer only knows about one ep0
> structure.
the gadget framework knows about USB endpoints which are bidirectional
logical entities. One USB endpoint is composed of two unidirectional HW
endpoints.
> I guess currently we have no other way out unless the gadget layer do
> honor ep0 with direction. IMHO, it is a limitation to current gadget
> APIs that each udc driver need to take too much care of the protocol
> related stuff on ep0.
indeed, if you can come up with a sensible patch we're here to review
;-)
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v2] USB: fsl_udc_core: use usb_endpoint_xfer_isoc to judge ISO XFER
From: Felipe Balbi @ 2011-11-24 9:47 UTC (permalink / raw)
To: Peter Chen
Cc: gregkh, linux-usb, mina86, balbi, linuxppc-dev, stable,
hzpeterchen
In-Reply-To: <1321926945-8182-1-git-send-email-peter.chen@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 362 bytes --]
On Tue, Nov 22, 2011 at 09:55:45AM +0800, Peter Chen wrote:
> Some ISO gadgets, like audio, has SYNC attribute as well as
> USB_ENDPOINT_XFER_ISOC for their bmAttributes at ISO endpoint
> descriptor. So, it needs to use usb_endpoint_xfer_isoc to judge
> ISO XFER.
>
> Signed-off-by: Peter Chen <peter.chen@freescale.com>
applied, thanks
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v2] usb/fsl_udc: fix dequeuing a request in progress
From: Felipe Balbi @ 2011-11-24 9:48 UTC (permalink / raw)
To: Li Yang; +Cc: gregkh, linuxppc-dev, linux-usb, balbi, Peter Chen
In-Reply-To: <1322050376-13553-1-git-send-email-leoli@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 363 bytes --]
On Wed, Nov 23, 2011 at 08:12:56PM +0800, Li Yang wrote:
> The original implementation of dequeuing a request in progress
> is not correct. Change to use a correct process and also clean
> up the related functions a little bit.
>
> Signed-off-by: Li Yang <leoli@freescale.com>
> Cc: Peter Chen <peter.chen@freescale.com>
applied, thanks
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
From: LiuShuo @ 2011-11-24 10:02 UTC (permalink / raw)
To: dedekind1
Cc: Artem.Bityutskiy@nokia.com, Li Yang-R58472, Wood Scott-B07421,
dwmw2@infradead.org, linux-kernel@vger.kernel.org,
linux-mtd@lists.infradead.org, akpm@linux-foundation.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1322122592.24797.299.camel@sauron.fi.intel.com>
=E4=BA=8E 2011=E5=B9=B411=E6=9C=8824=E6=97=A5 16:16, Artem Bityutskiy =E5=
=86=99=E9=81=93:
> On Thu, 2011-11-24 at 07:49 +0000, Li Yang-R58472 wrote:
>>> Subject: Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to s=
upport
>>> large-page Nand chip
>>>
>>> On Thu, 2011-11-24 at 08:41 +0800, b35362@freescale.com wrote:
>>>> + /*
>>>> + * Freescale FCM controller has a 2K size limitation=
of buffer
>>>> + * RAM, so elbc_fcm_ctrl->buffer have to be used if =
writesize
>>>> + * of chip is greater than 2048.
>>>> + * We malloc a large enough buffer (maximum page siz=
e is
>>> 16K).
>>>> + */
>>>> + elbc_fcm_ctrl->buffer =3D kmalloc(1024 * 16 + 1024,
>>> GFP_KERNEL);
>>>
>>> Are there NANDs with 16KiB page size?
>> We are not sure, but are there possibility that chip with 16K page wil=
l appear? Or maybe we can add a MACRO for the maximum page size?
> I do not know, but I know that allocating 32KiB of contiguous physical
> RAM may cause unneeded memory pressure and even fail if the memory is
> too fragmented. So I would not go for this unless this is necessary.
What is your suggestion ? 8k is enough ?
> Did you try to look how the NAND base interface could be changed to
> avoid re-allocation altogether, BTW?
This buffer is a controller-wide resource( as Scott said), I only=20
allocate buffer one time in this version.
It should be a large enough buffer for all chips.
-Liu Shuo
^ permalink raw reply
* RE: [PATCH 2/2] powerpc/85xx: Renamed mpc85xx_common.c to common.c
From: David Laight @ 2011-11-24 10:22 UTC (permalink / raw)
To: Kumar Gala, linuxppc-dev
In-Reply-To: <1322118527-14348-2-git-send-email-galak@kernel.crashing.org>
=20
> Subject: [PATCH 2/2] powerpc/85xx: Renamed mpc85xx_common.c=20
> to common.c
>=20
> The file name is already scoped by the directory its in.
...
> rename from arch/powerpc/platforms/85xx/mpc85xx_common.c
> rename to arch/powerpc/platforms/85xx/common.c
All very well until you only have a reference to the
filename part somewhere and want to 'find' the file
in a large directory tree.
David
^ permalink raw reply
* [PATCH 1/1] SPI: disable CONFIG_SPI_FSL_ESPI=m build
From: Jiri Slaby @ 2011-11-24 10:41 UTC (permalink / raw)
To: grant.likely; +Cc: linuxppc-dev, linux-kernel, jirislaby
When spi_fsl_espi is chosen to be built as a module, there is a build
error because we test only CONFIG_SPI_FSL_ESPI in declaration of
struct mpc8xxx_spi in drivers/spi/spi_fsl_lib.h. Also some called
functions are not exported.
So we forbid CONFIG_SPI_FSL_ESPI to be tristate here.
The error looks like:
drivers/spi/spi_fsl_espi.c: In function 'fsl_espi_bufs':
drivers/spi/spi_fsl_espi.c:232: error: 'struct mpc8xxx_spi' has no member named 'len'
...
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Kumar Gala <galak@kernel.crashing.org>
---
drivers/spi/Kconfig | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 9c90a7a..3d292be 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -198,7 +198,7 @@ config SPI_FSL_LIB
depends on FSL_SOC
config SPI_FSL_SPI
- tristate "Freescale SPI controller"
+ bool "Freescale SPI controller"
depends on FSL_SOC
select SPI_FSL_LIB
help
@@ -207,7 +207,7 @@ config SPI_FSL_SPI
MPC8569 uses the controller in QE mode, MPC8610 in cpu mode.
config SPI_FSL_ESPI
- tristate "Freescale eSPI controller"
+ bool "Freescale eSPI controller"
depends on FSL_SOC
select SPI_FSL_LIB
help
--
1.7.7.3
^ permalink raw reply related
* Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
From: Artem Bityutskiy @ 2011-11-24 11:07 UTC (permalink / raw)
To: LiuShuo
Cc: Artem.Bityutskiy@nokia.com, Li Yang-R58472, Wood Scott-B07421,
dwmw2@infradead.org, linux-kernel@vger.kernel.org,
linux-mtd@lists.infradead.org, akpm@linux-foundation.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4ECE162D.7080408@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 1507 bytes --]
On Thu, 2011-11-24 at 18:02 +0800, LiuShuo wrote:
> 于 2011年11月24日 16:16, Artem Bityutskiy 写道:
> > On Thu, 2011-11-24 at 07:49 +0000, Li Yang-R58472 wrote:
> >>> Subject: Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support
> >>> large-page Nand chip
> >>>
> >>> On Thu, 2011-11-24 at 08:41 +0800, b35362@freescale.com wrote:
> >>>> + /*
> >>>> + * Freescale FCM controller has a 2K size limitation of buffer
> >>>> + * RAM, so elbc_fcm_ctrl->buffer have to be used if writesize
> >>>> + * of chip is greater than 2048.
> >>>> + * We malloc a large enough buffer (maximum page size is
> >>> 16K).
> >>>> + */
> >>>> + elbc_fcm_ctrl->buffer = kmalloc(1024 * 16 + 1024,
> >>> GFP_KERNEL);
> >>>
> >>> Are there NANDs with 16KiB page size?
> >> We are not sure, but are there possibility that chip with 16K page will appear? Or maybe we can add a MACRO for the maximum page size?
> > I do not know, but I know that allocating 32KiB of contiguous physical
> > RAM may cause unneeded memory pressure and even fail if the memory is
> > too fragmented. So I would not go for this unless this is necessary.
> What is your suggestion ? 8k is enough ?
Up to you, I do not have suggestions, just expressed a concern. I'd keep
the buffer smaller if possible. By the time 16KiB pages appear, your HW
may retire already :-)
--
Best Regards,
Artem Bityutskiy
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: do not force PHYS_64BIT on the P1022DS
From: Tabi Timur-B04825 @ 2011-11-24 13:56 UTC (permalink / raw)
To: Gala Kumar-B11780; +Cc: <linuxppc-dev@ozlabs.org>
In-Reply-To: <C0BC3E1D-5FCF-42EC-A030-4F86EC1D76F3@freescale.com>
On Nov 24, 2011, at 1:12 AM, Kumar Gala <kumar.gala@freescale.com> wrote:
>=20
> If you want me to apply this please also provided a 32-bit .dts for p1022=
ds. This should be pretty trivial based on my recent .dts cleanups.
Ok, I'll do that.=
^ permalink raw reply
* Re: [PATCH] P1021: set IReady in QE Microcode Upload
From: Tabi Timur-B04825 @ 2011-11-24 13:57 UTC (permalink / raw)
To: Kumar Gala
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
Kokoris, Ioannis
In-Reply-To: <DF5BDBFF-A726-4E1C-832E-EF2629F60DC9@kernel.crashing.org>
On Nov 24, 2011, at 1:55 AM, Kumar Gala <galak@kernel.crashing.org> wrote:
>>=20
>> I'll have to check. But this patch can't be applied as-is unless it's
>> proven safe for all QE-enabled chips.
>=20
> Any update on trying this on a MPC8323?
Haiying said it should be ok, but I haven't tried it yet. I'll try it on M=
onday.
^ permalink raw reply
* Re: [PATCH v2] Integrated Flash Controller support
From: Kumar Gala @ 2011-11-24 14:24 UTC (permalink / raw)
To: Artem Bityutskiy
Cc: Artem.Bityutskiy, Li Yang-R58472,
linuxppc-dev@lists.ozlabs.org list, b35362@freescale.com>,
linux-kernel@vger.kernel.org Kernel, linux-mtd, Scott Wood,
Andrew Morton, David Woodhouse
In-Reply-To: <CCF7C6DB-437C-4140-894F-2F497AD610DC@kernel.crashing.org>
On Nov 22, 2011, at 9:41 PM, Kumar Gala wrote:
>=20
> On Oct 31, 2011, at 4:38 AM, <b35362@freescale.com> =
<b35362@freescale.com> wrote:
>=20
>> From: Liu Shuo <b35362@freescale.com>
>>=20
>> Integrated Flash Controller supports various flashes like NOR, NAND
>> and other devices using NOR, NAND and GPCM Machine available on it.
>> IFC supports four chip selects.
>>=20
>> Signed-off-by: Dipen Dudhat <Dipen.Dudhat@freescale.com>
>> Signed-off-by: Scott Wood <scottwood@freescale.com>
>> Signed-off-by: Li Yang <leoli@freescale.com>
>> Signed-off-by: Liu Shuo <b35362@freescale.com>
>> ---
>> arch/powerpc/Kconfig | 4 +
>> arch/powerpc/include/asm/fsl_ifc.h | 834 =
++++++++++++++++++++++++++++++++++++
>> arch/powerpc/sysdev/Makefile | 1 +
>> arch/powerpc/sysdev/fsl_ifc.c | 322 ++++++++++++++
>> 4 files changed, 1161 insertions(+), 0 deletions(-)
>> create mode 100644 arch/powerpc/include/asm/fsl_ifc.h
>> create mode 100644 arch/powerpc/sysdev/fsl_ifc.c
>=20
> Guys,
>=20
> How are we handling this patchset since it touches drivers/mtd/nand?
Artem,
thoughts?
- k=
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox