* Re: [linuxppc-release] [powerpc] boot up problem
From: Kumar Gala @ 2011-12-07 14:53 UTC (permalink / raw)
To: Jia Hongtao-B38951
Cc: linuxppc-dev@lists.ozlabs.org, Fleming Andy-AFLEMING,
Tabi Timur-B04825, Li Yang-R58472
In-Reply-To: <412C8208B4A0464FA894C5F0C278CD5DFE170A@039-SN1MPN1-005.039d.mgd.msft.net>
This still needs a dts fix from Andy.
- k
On Dec 7, 2011, at 1:27 AM, Jia Hongtao-B38951 wrote:
> Is this the patch you mentioned?
> http://patchwork.ozlabs.org/patch/128806/
>=20
> I applied this patch but the issue was still there.
>=20
> -----Original Message-----
> From: Tabi Timur-B04825=20
> Sent: Friday, December 02, 2011 11:56 AM
> To: Jia Hongtao-B38951
> Cc: Kumar Gala; linuxppc-dev@lists.ozlabs.org; Li Yang-R58472; Fleming =
Andy-AFLEMING
> Subject: Re: [linuxppc-release] [powerpc] boot up problem
>=20
> Jia Hongtao-B38951 wrote:
>> Hi
>>=20
>> I just found that the 'next' branch you mentioned have problem to =
boot up.
>> I test it in p1022ds and p1010rdb boards and the result are both the =
same.
>> Note that for p1022ds I use "make p1022ds.dtb" to make the dtb =
file(36bit) with 36bit-uboot.
>> And for p1010rdb I use all 32bit image.
>> The problem list below:
>>=20
>> scsi0 : sata_fsl
>> ata1: SATA max UDMA/133 irq 74
>> fsl-sata fffe19000.sata: Sata FSL Platform/CSB Driver init
>> scsi1 : sata_fsl
>> ata2: SATA max UDMA/133 irq 41
>> Fixed MDIO Bus: probed
>> Unable to handle kernel paging request for data at address 0x00000000=20=
>> Faulting instruction address: 0xc0451630
>> Oops: Kernel access of bad area, sig: 11 [#1]
>=20
> Andy has phy driver patch that fixes this.
>=20
> --
> Timur Tabi
> Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH v3 2/8] [booke] Rename mapping based RELOCATABLE to DYNAMIC_MEMSTART for BookE
From: Josh Boyer @ 2011-12-07 12:47 UTC (permalink / raw)
To: Suzuki Poulose; +Cc: Scott Wood, Josh Poimboeuf, David Laight, linuxppc-dev
In-Reply-To: <4EDF5ED7.2030709@in.ibm.com>
On Wed, Dec 7, 2011 at 7:40 AM, Suzuki Poulose <suzuki@in.ibm.com> wrote:
> Josh,
>
> I rebased my patches to 3.2.0-rc3 and was able to verify it on my QEMU
> setup.
> However I am facing problems getting the my boards booted with the network
> cards
> (even without the patches). Here is what I see :
>
>
> Creating 2 MTD partitions on "1ff800000.large-flash":
> 0x000000000000-0x000000380000 : "fs"
> 0x000000380000-0x000000400000 : "firmware"
> PPC 4xx OCP EMAC driver, version 3.54
> mal0: failed to map interrupts !
That's the problem.
There was a bogus commit that was added to the generic OF code that
prevented the normal mapping that the MAL nodes do from working. It
was later reverted after Benh told Linus it was bogus. I don't
remember which -rc that wound up in, but if you move to 3.2-rc4 that
should help.
josh
^ permalink raw reply
* Re: [PATCH v3 2/8] [booke] Rename mapping based RELOCATABLE to DYNAMIC_MEMSTART for BookE
From: Suzuki Poulose @ 2011-12-07 12:40 UTC (permalink / raw)
To: Josh Boyer; +Cc: Scott Wood, Josh Poimboeuf, David Laight, linuxppc-dev
In-Reply-To: <CA+5PVA7r215N3NZV9gaTiXzeiwBnPBMbssX0Qo3zJ-9eGJaypA@mail.gmail.com>
On 11/30/11 20:11, Josh Boyer wrote:
> On Mon, Nov 28, 2011 at 5:59 PM, Scott Wood<scottwood@freescale.com> wrote:
>> On 11/23/2011 10:47 AM, Josh Boyer wrote:
>>> On Mon, Nov 14, 2011 at 12:41 AM, Suzuki K. Poulose<suzuki@in.ibm.com> wrote:
>>>> The current implementation of CONFIG_RELOCATABLE in BookE is based
>>>> on mapping the page aligned kernel load address to KERNELBASE. This
>>>> approach however is not enough for platforms, where the TLB page size
>>>> is large (e.g, 256M on 44x). So we are renaming the RELOCATABLE used
>>>> currently in BookE to DYNAMIC_MEMSTART to reflect the actual method.
>>
>> Should reword the config help to make it clear what the alignment
>> restriction is, or where to find the information for a particular
>> platform. Someone reading "page aligned" without any context that we're
>> talking about special large pages is going to think 4K -- and on e500,
>> many large page sizes are supported, so the required alignment is found
>> in Linux init code rather than a CPU manual.
>>
>>>>
>>>> The CONFIG_RELOCATABLE for PPC32(BookE) based on processing of the
>>>> dynamic relocations will be introduced in the later in the patch series.
>>>>
>>>> This change would allow the use of the old method of RELOCATABLE for
>>>> platforms which can afford to enforce the page alignment (platforms with
>>>> smaller TLB size).
>>>
>>> I'm OK with the general direction, but this touches a lot of non-4xx
>>> code. I'd prefer it if Ben took this directly on whatever final
>>> solution is done.
>>>
>>>> I haven tested this change only on 440x. I don't have an FSL BookE to verify
>>>> the changes there.
>>>>
>>>> Scott,
>>>> Could you please test this patch on FSL and let me know the results ?
>>>
>>> Scott, did you ever get around to testing this? In my opinion, this
>>> shouldn't go in without a Tested-by: from someone that tried it on an
>>> FSL platform.
>>
>> Booted OK for me on e500v2 with RAM starting at 256M.
>>
>> Tested-by: Scott Wood<scottwood@freescale.com>
>>
>>> We add DYNAMIC_MEMSTART for 32-bit, and we have RELOCATABLE for
>>> 64-bit. Then throughout almost the rest of the patch, all we're doing
>>> is duplicating what RELOCATABLE already did (e.g. if ! either thing).
>>> It works, but it is kind of ugly.
>>>
>>> Instead, could we define a helper config variable that can be used in
>>> place of that construct? Something like:
>>>
>>> config NONSTATIC_KERNEL (or whatever)
>>> bool
>>> default n
>>>
>>> ...
>>>
>>> config DYNAMIC_MEMSTART
>>> <blah>
>>> select NONSTATIC_KERNEL
>>>
>>> ...
>>>
>>> config RELOCATABLE
>>> <blah>
>>> select NONSTATIC_KERNEL
>>
>> I agree.
>
> Suzie do you think you could respin this patch with the suggested
> changes and include Scott's Tested-by? The rest of the series looks
> fine and I'd like to get it included in my next branch.
>
Josh,
I rebased my patches to 3.2.0-rc3 and was able to verify it on my QEMU setup.
However I am facing problems getting the my boards booted with the network cards
(even without the patches). Here is what I see :
Creating 2 MTD partitions on "1ff800000.large-flash":
0x000000000000-0x000000380000 : "fs"
0x000000380000-0x000000400000 : "firmware"
PPC 4xx OCP EMAC driver, version 3.54
mal0: failed to map interrupts !
ZMII /plb/opb/emac-zmii@40000780 initialized
/plb/opb/ethernet@40000800: Timeout waiting for dependent devices
/plb/opb/ethernet@40000900: Timeout waiting for dependent devices
TCP cubic registered
NET: Registered protocol family 17
Root-NFS: no NFS server address
VFS: Unable to mount root fs via NFS, trying floppy.
VFS: Cannot open root device "(null)" or unknown-block(2,0)
Please append a correct "root=" boot option; here are the available partitions:
1f00 512 mtdblock0 (driver?)
1f01 3584 mtdblock1 (driver?)
1f02 512 mtdblock2 (driver?)
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0)
Have you come across this message ?
Thanks
Suzuki
^ permalink raw reply
* Re: [PATCH net-next v6 4/4] powerpc: tqm8548/tqm8xx: add and update CAN device nodes
From: Wolfgang Grandegger @ 2011-12-07 8:25 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, netdev, devicetree-discuss, socketcan-users,
linux-can
In-Reply-To: <1323243268.660.71.camel@pasglop>
On 12/07/2011 08:34 AM, Benjamin Herrenschmidt wrote:
> On Thu, 2011-12-01 at 10:41 +0100, Wolfgang Grandegger wrote:
>> This patch enables or updates support for the CC770 and AN82527
>> CAN controller on the TQM8548 and TQM8xx boards.
>
> I'm a bit confused by the net-next prefix here. Those patches seem to
> be only touching arch/powerpc and seem to be sent primarily toward
> netdev with a net-next prefix.
These patches are part of a series implementing a new netdev CAN driver
with device-tree support for CC770/i82527 CAN controllers. The
device-tree support and bindings are properly documented and some DTS
files have been updated accordingly. The relevant maintainers and
mailing list have been addressed.
> Also there have been at least 3 versions in a couple of days already
> without comments nor indication of what was changed...
Unfortunately, no response from those sub-system guys.
> Can you clarify things a bit please ? It looks like they really should
> go to linuxppc-dev (and you can probably drop a bunch of other lists) or
> am I missing an important piece of the puzzle ? (Such as patch 1/4 and
> 2/4 ...)
I have not sent the whole series. The changes are documented in the
cover-letter, which I have not sent for those patches. Well, I think
it's better to sent the whole series to all parties instead?
> Let me know if I should just remove them from powerpc patchwork.
Dave has already applied all patches.
Sorry for the confusion. Any advice on how to handle multi subsystem
series of patches properly is welcome.
Wolfgang.
^ permalink raw reply
* Re: ibm_newemac tx problem with jumbo frame enabled
From: Prashant Bhole @ 2011-12-07 8:05 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1322198727.32635.25.camel@pasglop>
On Fri, Nov 25, 2011 at 10:55 AM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Fri, 2011-11-18 at 10:33 +0530, Prashant Bhole wrote:
>> Hi,
>> I have been facing problem with ibm_newemac driver (v3.54).
>> The board gets disconnected and can not be pinged in between
>> some heavy network traffic. In my case I am running IOmeter
>> "All-in-One" 8 threads on the iSCSI target. MTU is 4088.
>>
>> I found that after executing emac_full_tx_reset(), the board can
>> be pinged again. Again after some heavy traffic of 5-6 seconds,
>> traffic stops. This can be repeated after full tx reset.
>>
>> Is this a known issue? what could cause this?
>> Any pointers would be greatly appreciated.
>
> Not that I know of. Can you check if any of the error reporting
> registers trip anything ? Could it just be a fifo overflow which we may
> not be handling properly in the driver ?
>
> Cheers,
> Ben.
Still couldn't find anything like fifo overflow...
I noticed one more thing, this problem happens only when mtu size on
the initiator (the other end) is set to 4088, regardless of any mtu size set
for EMAC.
-
Prashant
^ permalink raw reply
* Re: [PATCH net-next v6 4/4] powerpc: tqm8548/tqm8xx: add and update CAN device nodes
From: Benjamin Herrenschmidt @ 2011-12-07 7:42 UTC (permalink / raw)
To: David Miller
Cc: netdev, devicetree-discuss, linux-can, linuxppc-dev,
socketcan-users
In-Reply-To: <20111207.023916.980093028693181777.davem@davemloft.net>
On Wed, 2011-12-07 at 02:39 -0500, David Miller wrote:
> From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Date: Wed, 07 Dec 2011 18:34:28 +1100
>
> > Let me know if I should just remove them from powerpc patchwork.
>
> These are DT entries for CAN devices for which drivers only exist in
> the net-next tree, I already included this patch into the net-next
> tree so you do not have to.
Thanks.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH net-next v6 4/4] powerpc: tqm8548/tqm8xx: add and update CAN device nodes
From: David Miller @ 2011-12-07 7:39 UTC (permalink / raw)
To: benh; +Cc: netdev, devicetree-discuss, linux-can, linuxppc-dev,
socketcan-users
In-Reply-To: <1323243268.660.71.camel@pasglop>
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Wed, 07 Dec 2011 18:34:28 +1100
> Let me know if I should just remove them from powerpc patchwork.
These are DT entries for CAN devices for which drivers only exist in
the net-next tree, I already included this patch into the net-next
tree so you do not have to.
^ permalink raw reply
* Re: [PATCH net-next v6 4/4] powerpc: tqm8548/tqm8xx: add and update CAN device nodes
From: Benjamin Herrenschmidt @ 2011-12-07 7:34 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: linuxppc-dev, netdev, devicetree-discuss, socketcan-users,
linux-can
In-Reply-To: <1322732481-2255-5-git-send-email-wg@grandegger.com>
On Thu, 2011-12-01 at 10:41 +0100, Wolfgang Grandegger wrote:
> This patch enables or updates support for the CC770 and AN82527
> CAN controller on the TQM8548 and TQM8xx boards.
I'm a bit confused by the net-next prefix here. Those patches seem to
be only touching arch/powerpc and seem to be sent primarily toward
netdev with a net-next prefix.
Also there have been at least 3 versions in a couple of days already
without comments nor indication of what was changed...
Can you clarify things a bit please ? It looks like they really should
go to linuxppc-dev (and you can probably drop a bunch of other lists) or
am I missing an important piece of the puzzle ? (Such as patch 1/4 and
2/4 ...)
Let me know if I should just remove them from powerpc patchwork.
Cheers,
Ben.
> CC: devicetree-discuss@lists.ozlabs.org
> CC: linuxppc-dev@ozlabs.org
> CC: Kumar Gala <galak@kernel.crashing.org>
> Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
> ---
> arch/powerpc/boot/dts/tqm8548-bigflash.dts | 19 ++++++++++++++-----
> arch/powerpc/boot/dts/tqm8548.dts | 19 ++++++++++++++-----
> arch/powerpc/boot/dts/tqm8xx.dts | 25 +++++++++++++++++++++++++
> 3 files changed, 53 insertions(+), 10 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/tqm8548-bigflash.dts b/arch/powerpc/boot/dts/tqm8548-bigflash.dts
> index 9452c3c..d918752 100644
> --- a/arch/powerpc/boot/dts/tqm8548-bigflash.dts
> +++ b/arch/powerpc/boot/dts/tqm8548-bigflash.dts
> @@ -352,7 +352,7 @@
> ranges = <
> 0 0x0 0xfc000000 0x04000000 // NOR FLASH bank 1
> 1 0x0 0xf8000000 0x08000000 // NOR FLASH bank 0
> - 2 0x0 0xa3000000 0x00008000 // CAN (2 x i82527)
> + 2 0x0 0xa3000000 0x00008000 // CAN (2 x CC770)
> 3 0x0 0xa3010000 0x00008000 // NAND FLASH
>
> >;
> @@ -393,18 +393,27 @@
> };
>
> /* Note: CAN support needs be enabled in U-Boot */
> - can0@2,0 {
> - compatible = "intel,82527"; // Bosch CC770
> + can@2,0 {
> + compatible = "bosch,cc770"; // Bosch CC770
> reg = <2 0x0 0x100>;
> interrupts = <4 1>;
> interrupt-parent = <&mpic>;
> + bosch,external-clock-frequency = <16000000>;
> + bosch,disconnect-rx1-input;
> + bosch,disconnect-tx1-output;
> + bosch,iso-low-speed-mux;
> + bosch,clock-out-frequency = <16000000>;
> };
>
> - can1@2,100 {
> - compatible = "intel,82527"; // Bosch CC770
> + can@2,100 {
> + compatible = "bosch,cc770"; // Bosch CC770
> reg = <2 0x100 0x100>;
> interrupts = <4 1>;
> interrupt-parent = <&mpic>;
> + bosch,external-clock-frequency = <16000000>;
> + bosch,disconnect-rx1-input;
> + bosch,disconnect-tx1-output;
> + bosch,iso-low-speed-mux;
> };
>
> /* Note: NAND support needs to be enabled in U-Boot */
> diff --git a/arch/powerpc/boot/dts/tqm8548.dts b/arch/powerpc/boot/dts/tqm8548.dts
> index 619776f..988d887 100644
> --- a/arch/powerpc/boot/dts/tqm8548.dts
> +++ b/arch/powerpc/boot/dts/tqm8548.dts
> @@ -352,7 +352,7 @@
> ranges = <
> 0 0x0 0xfc000000 0x04000000 // NOR FLASH bank 1
> 1 0x0 0xf8000000 0x08000000 // NOR FLASH bank 0
> - 2 0x0 0xe3000000 0x00008000 // CAN (2 x i82527)
> + 2 0x0 0xe3000000 0x00008000 // CAN (2 x CC770)
> 3 0x0 0xe3010000 0x00008000 // NAND FLASH
>
> >;
> @@ -393,18 +393,27 @@
> };
>
> /* Note: CAN support needs be enabled in U-Boot */
> - can0@2,0 {
> - compatible = "intel,82527"; // Bosch CC770
> + can@2,0 {
> + compatible = "bosch,cc770"; // Bosch CC770
> reg = <2 0x0 0x100>;
> interrupts = <4 1>;
> interrupt-parent = <&mpic>;
> + bosch,external-clock-frequency = <16000000>;
> + bosch,disconnect-rx1-input;
> + bosch,disconnect-tx1-output;
> + bosch,iso-low-speed-mux;
> + bosch,clock-out-frequency = <16000000>;
> };
>
> - can1@2,100 {
> - compatible = "intel,82527"; // Bosch CC770
> + can@2,100 {
> + compatible = "bosch,cc770"; // Bosch CC770
> reg = <2 0x100 0x100>;
> interrupts = <4 1>;
> interrupt-parent = <&mpic>;
> + bosch,external-clock-frequency = <16000000>;
> + bosch,disconnect-rx1-input;
> + bosch,disconnect-tx1-output;
> + bosch,iso-low-speed-mux;
> };
>
> /* Note: NAND support needs to be enabled in U-Boot */
> diff --git a/arch/powerpc/boot/dts/tqm8xx.dts b/arch/powerpc/boot/dts/tqm8xx.dts
> index f6da7ec..c3dba25 100644
> --- a/arch/powerpc/boot/dts/tqm8xx.dts
> +++ b/arch/powerpc/boot/dts/tqm8xx.dts
> @@ -57,6 +57,7 @@
>
> ranges = <
> 0x0 0x0 0x40000000 0x800000
> + 0x3 0x0 0xc0000000 0x200
> >;
>
> flash@0,0 {
> @@ -67,6 +68,30 @@
> bank-width = <4>;
> device-width = <2>;
> };
> +
> + /* Note: CAN support needs be enabled in U-Boot */
> + can@3,0 {
> + compatible = "intc,82527";
> + reg = <3 0x0 0x80>;
> + interrupts = <8 1>;
> + interrupt-parent = <&PIC>;
> + bosch,external-clock-frequency = <16000000>;
> + bosch,disconnect-rx1-input;
> + bosch,disconnect-tx1-output;
> + bosch,iso-low-speed-mux;
> + bosch,clock-out-frequency = <16000000>;
> + };
> +
> + can@3,100 {
> + compatible = "intc,82527";
> + reg = <3 0x100 0x80>;
> + interrupts = <8 1>;
> + interrupt-parent = <&PIC>;
> + bosch,external-clock-frequency = <16000000>;
> + bosch,disconnect-rx1-input;
> + bosch,disconnect-tx1-output;
> + bosch,iso-low-speed-mux;
> + };
> };
>
> soc@fff00000 {
^ permalink raw reply
* RE: [linuxppc-release] [powerpc] boot up problem
From: Jia Hongtao-B38951 @ 2011-12-07 7:27 UTC (permalink / raw)
To: Tabi Timur-B04825
Cc: Fleming Andy-AFLEMING, linuxppc-dev@lists.ozlabs.org,
Li Yang-R58472
In-Reply-To: <4ED84C32.3010807@freescale.com>
Is this the patch you mentioned?
http://patchwork.ozlabs.org/patch/128806/
I applied this patch but the issue was still there.
-----Original Message-----
From: Tabi Timur-B04825=20
Sent: Friday, December 02, 2011 11:56 AM
To: Jia Hongtao-B38951
Cc: Kumar Gala; linuxppc-dev@lists.ozlabs.org; Li Yang-R58472; Fleming Andy=
-AFLEMING
Subject: Re: [linuxppc-release] [powerpc] boot up problem
Jia Hongtao-B38951 wrote:
> Hi
>
> I just found that the 'next' branch you mentioned have problem to boot up=
.
> I test it in p1022ds and p1010rdb boards and the result are both the same=
.
> Note that for p1022ds I use "make p1022ds.dtb" to make the dtb file(36bit=
) with 36bit-uboot.
> And for p1010rdb I use all 32bit image.
> The problem list below:
>
> scsi0 : sata_fsl
> ata1: SATA max UDMA/133 irq 74
> fsl-sata fffe19000.sata: Sata FSL Platform/CSB Driver init
> scsi1 : sata_fsl
> ata2: SATA max UDMA/133 irq 41
> Fixed MDIO Bus: probed
> Unable to handle kernel paging request for data at address 0x00000000=20
> Faulting instruction address: 0xc0451630
> Oops: Kernel access of bad area, sig: 11 [#1]
Andy has phy driver patch that fixes this.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* RE: [PATCH 1/2 v2] mtd/nand: fixup for fmr initialization of Freescale NAND controller
From: Liu Shengzhou-B36685 @ 2011-12-07 6:30 UTC (permalink / raw)
To: Wood Scott-B07421
Cc: linux-mtd@lists.infradead.org, Gala Kumar-B11780,
linuxppc-dev@lists.ozlabs.org, dwmw2@infradead.org
In-Reply-To: <4EDE4DEC.7010308@freescale.com>
DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFdvb2QgU2NvdHQtQjA3NDIx
DQo+IFNlbnQ6IFdlZG5lc2RheSwgRGVjZW1iZXIgMDcsIDIwMTEgMToxNiBBTQ0KPiBUbzogTGl1
IFNoZW5nemhvdS1CMzY2ODUNCj4gQ2M6IGxpbnV4cHBjLWRldkBsaXN0cy5vemxhYnMub3JnOyBs
aW51eC1tdGRAbGlzdHMuaW5mcmFkZWFkLm9yZzsNCj4gZHdtdzJAaW5mcmFkZWFkLm9yZzsgR2Fs
YSBLdW1hci1CMTE3ODANCj4gU3ViamVjdDogUmU6IFtQQVRDSCAxLzIgdjJdIG10ZC9uYW5kOiBm
aXh1cCBmb3IgZm1yIGluaXRpYWxpemF0aW9uIG9mDQo+IEZyZWVzY2FsZSBOQU5EIGNvbnRyb2xs
ZXINCj4gDQo+IE9uIDEyLzA2LzIwMTEgMDI6NTQgQU0sIFNoZW5nemhvdSBMaXUgd3JvdGU6DQo+
ID4gVGhlcmUgd2FzIGEgYnVnIGZvciBmbXIgaW5pdGlhbGl6YXRpb24sIHdoaWNoIGxlYWQgdG8g
IGZtciB3YXMgYWx3YXlzDQo+ID4gMHgxMDAgaW4gZnNsX2VsYmNfY2hpcF9pbml0KCkgYW5kIGNh
dXNlZCBGQ00gY29tbWFuZCB0aW1lb3V0IGJlZm9yZQ0KPiA+IGNhbGxpbmcgZnNsX2VsYmNfY2hp
cF9pbml0X3RhaWwoKSwgbm93IHdlIGluaXRpYWxpemUgQ1dUTyB0byBtYXhpbXVtDQo+ID4gdGlt
ZW91dCB2YWx1ZSBhbmQgbm90IHJlbHlpbmcgb24gdGhlIHNldHRpbmcgb2YgYm9vdGxvYWRlci4N
Cj4gPg0KPiA+IFNpZ25lZC1vZmYtYnk6IFNoZW5nemhvdSBMaXUgPFNoZW5nemhvdS5MaXVAZnJl
ZXNjYWxlLmNvbT4NCj4gPiAtLS0NCj4gPiB2MjogbWFrZSBmbXIgbm90IHJlbHlpbmcgb24gdGhl
IHNldHRpbmcgb2YgYm9vdGxvYWRlci4NCj4gPg0KPiA+ICBkcml2ZXJzL210ZC9uYW5kL2ZzbF9l
bGJjX25hbmQuYyB8ICAgMTAgKysrKystLS0tLQ0KPiA+ICAxIGZpbGVzIGNoYW5nZWQsIDUgaW5z
ZXJ0aW9ucygrKSwgNSBkZWxldGlvbnMoLSkNCj4gPg0KPiA+IGRpZmYgLS1naXQgYS9kcml2ZXJz
L210ZC9uYW5kL2ZzbF9lbGJjX25hbmQuYw0KPiA+IGIvZHJpdmVycy9tdGQvbmFuZC9mc2xfZWxi
Y19uYW5kLmMNCj4gPiBpbmRleCBlZWRkOGVlLi40ZjQwNWEwIDEwMDY0NA0KPiA+IC0tLSBhL2Ry
aXZlcnMvbXRkL25hbmQvZnNsX2VsYmNfbmFuZC5jDQo+ID4gKysrIGIvZHJpdmVycy9tdGQvbmFu
ZC9mc2xfZWxiY19uYW5kLmMNCj4gPiBAQCAtNjU5LDkgKzY1OSw3IEBAIHN0YXRpYyBpbnQgZnNs
X2VsYmNfY2hpcF9pbml0X3RhaWwoc3RydWN0IG10ZF9pbmZvDQo+ICptdGQpDQo+ID4gIAlpZiAo
Y2hpcC0+cGFnZW1hc2sgJiAweGZmMDAwMDAwKQ0KPiA+ICAJCWFsKys7DQo+ID4NCj4gPiAtCS8q
IGFkZCB0byBFQ0NNIG1vZGUgc2V0IGluIGZzbF9lbGJjX2luaXQgKi8NCj4gPiAtCXByaXYtPmZt
ciB8PSAoMTIgPDwgRk1SX0NXVE9fU0hJRlQpIHwgIC8qIFRpbWVvdXQgPiAxMiBtcyAqLw0KPiA+
IC0JICAgICAgICAgICAgIChhbCA8PCBGTVJfQUxfU0hJRlQpOw0KPiA+ICsJcHJpdi0+Zm1yIHw9
IGFsIDw8IEZNUl9BTF9TSElGVDsNCj4gPg0KPiA+ICAJZGV2X2RiZyhwcml2LT5kZXYsICJmc2xf
ZWxiY19pbml0OiBuYW5kLT5udW1jaGlwcyA9ICVkXG4iLA0KPiA+ICAJICAgICAgICBjaGlwLT5u
dW1jaGlwcyk7DQo+ID4gQEAgLTc2NCw4ICs3NjIsMTAgQEAgc3RhdGljIGludCBmc2xfZWxiY19j
aGlwX2luaXQoc3RydWN0IGZzbF9lbGJjX210ZA0KPiAqcHJpdikNCj4gPiAgCXByaXYtPm10ZC5w
cml2ID0gY2hpcDsNCj4gPiAgCXByaXYtPm10ZC5vd25lciA9IFRISVNfTU9EVUxFOw0KPiA+DQo+
ID4gLQkvKiBTZXQgdGhlIEVDQ00gYWNjb3JkaW5nIHRvIHRoZSBzZXR0aW5ncyBpbiBib290bG9h
ZGVyLiovDQo+ID4gLQlwcml2LT5mbXIgPSBpbl9iZTMyKCZsYmMtPmZtcikgJiBGTVJfRUNDTTsN
Cj4gPiArCS8qIHNldCB0aW1lb3V0IHRvIG1heGltdW0gKi8NCj4gPiArCXByaXYtPmZtciA9IDE1
IDw8IEZNUl9DV1RPX1NISUZUOw0KPiA+ICsJaWYgKGluX2JlMzIoJmxiYy0+YmFua1twcml2LT5i
YW5rXS5vcikgJiBPUl9GQ01fUEdTKQ0KPiA+ICsJCXByaXYtPmZtciB8PSBGTVJfRUNDTTsNCj4g
DQo+IFBsZWFzZSBkbyBub3QgY2hhbmdlIHRoZSB3YXkgRUNDTSBpcyBoYW5kbGVkLiAgV2UgcHJv
YmFibHkgc2hvdWxkIGhhdmUNCj4gZG9uZSBpdCB0aGlzIHdheSBmcm9tIHRoZSBzdGFydCwgYnV0
IGF0IHRoaXMgcG9pbnQgaXQgYnJlYWtzDQo+IGNvbXBhdGliaWxpdHkgaWYgeW91IGhhdmUgYSBs
YXJnZSBwYWdlIGZsYXNoIGFuZCB0aGUgZmlybXdhcmUgZGlkbid0DQo+IHRvdWNoIE5BTkQuDQo+
IA0KPiAtU2NvdHQNCltTaGVuZ3pob3VdIFRoaXMgcGF0Y2ggZG9lc24ndCBjaGFuZ2UgdGhlIHdh
eSBFQ0NNIGlzIGhhbmRsZWQsIGl0J3Mgc3RpbGwgc2FtZSBhcyBiZWZvcmUsIGp1c3QgbWFrZSBz
dXJlIENXVE8gdGltZW91dCBpcyBzZXQgdG8gbWF4aW11bS4gIA0K
^ permalink raw reply
* Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
From: LiuShuo @ 2011-12-07 3:55 UTC (permalink / raw)
To: Scott Wood
Cc: Artem.Bityutskiy, linuxppc-dev, linux-kernel, shuo.liu, linux-mtd,
akpm, dwmw2
In-Reply-To: <4EDEAEB9.6020703@freescale.com>
=E4=BA=8E 2011=E5=B9=B412=E6=9C=8807=E6=97=A5 08:09, Scott Wood =E5=86=99=
=E9=81=93:
> On 12/03/2011 10:31 PM, shuo.liu@freescale.com wrote:
>> From: Liu Shuo<shuo.liu@freescale.com>
>>
>> Freescale FCM controller has a 2K size limitation of buffer RAM. In or=
der
>> to support the Nand flash chip whose page size is larger than 2K bytes=
,
>> we read/write 2k data repeatedly by issuing FIR_OP_RB/FIR_OP_WB and sa=
ve
>> them to a large buffer.
>>
>> Signed-off-by: Liu Shuo<shuo.liu@freescale.com>
>> ---
>> v3:
>> -remove page_size of struct fsl_elbc_mtd.
>> -do a oob write by NAND_CMD_RNDIN.
>>
>> drivers/mtd/nand/fsl_elbc_nand.c | 243 ++++++++++++++++++++++++++++=
++++++----
>> 1 files changed, 218 insertions(+), 25 deletions(-)
> What is the plan for bad block marker migration?
This patch has been ported to uboot now, I think we can make a special=20
uboot image for bad
block marker migration when first use the chip.
>> @@ -473,13 +568,72 @@ static void fsl_elbc_cmdfunc(struct mtd_info *mt=
d, unsigned int command,
>> * write so the HW generates the ECC.
>> */
>> if (elbc_fcm_ctrl->oob || elbc_fcm_ctrl->column !=3D 0 ||
>> - elbc_fcm_ctrl->index !=3D mtd->writesize + mtd->oobsize)
>> - out_be32(&lbc->fbcr,
>> - elbc_fcm_ctrl->index - elbc_fcm_ctrl->column);
>> - else
>> + elbc_fcm_ctrl->index !=3D mtd->writesize + mtd->oobsize) {
>> + if (elbc_fcm_ctrl->oob&& mtd->writesize> 2048) {
>> + out_be32(&lbc->fbcr, 64);
>> + } else {
>> + out_be32(&lbc->fbcr, elbc_fcm_ctrl->index
>> + - elbc_fcm_ctrl->column);
>> + }
> We need to limit ourselves to the regions that have actually been
> written to in the buffer. fbcr needs to be set separately for first an=
d
> last subpages, with intermediate subpages having 0, 64, or 2112 as
> appropriate. Subpages that are entirely before column or entirely afte=
r
> column + index should be skipped.
I have considered this case, but I don't think it is useful.
1.There isn't a 'length' parameter in driver interface, although we=20
can get it from 'index - column'.
2.To see nand_do_write_oob() in nand_base.c, it fill '0xff' to=20
entire oob area first and write the user data by nand_fill_oob(), then=20
call ecc.write_oob (default is nand_write_oob_std()). 'column' is=20
mtd->writesize and 'length' of write_buf() is mtd->oobsize. So I don't=20
think we need to deal with it there.
>> + } else {
>> + out_be32(&lbc->fir, FIR_OP_WB<< FIR_OP1_SHIFT);
>> + for (i =3D 1; i< n; i++) {
>> + if (i =3D=3D n - 1) {
>> + elbc_fcm_ctrl->use_mdr =3D 1;
>> + out_be32(&lbc->fir,
>> + (FIR_OP_WB<< FIR_OP1_SHIFT) |
>> + (FIR_OP_CM3<< FIR_OP2_SHIFT) |
>> + (FIR_OP_CW1<< FIR_OP3_SHIFT) |
>> + (FIR_OP_RS<< FIR_OP4_SHIFT));
> Please explicitly show the (FIR_OP_NOP<< FIR_OP0_SHIFT) compenent.
>
>> + } else if (mtd->writesize>=3D 2048&& mtd->writesize<=3D 16 * 1024) =
{
>> +
>> setbits32(&lbc->bank[priv->bank].or, OR_FCM_PGS);
> Don't insert a blank line here.
>
Ok.
-LiuShuo
> -Scott
^ permalink raw reply
* [PATCH 01/16 v3] pmac_zilog: fix unexpected irq
From: Finn Thain @ 2011-12-07 3:49 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linux-m68k, linuxppc-dev, linux-serial
In-Reply-To: <alpine.LNX.2.00.1112070203310.14968@nippy.intranet>
On most 68k Macs the SCC IRQ is an autovector interrupt and cannot be
masked. This can be a problem when pmac_zilog starts up.
For example, the serial debugging code in arch/m68k/kernel/head.S may be
used beforehand. It disables the SCC interrupts at the chip but doesn't
ack them. Then when a pmac_zilog port is used, the machine locks up with
"unexpected interrupt".
This can happen in pmz_shutdown() since the irq is freed before the
channel interrupts are disabled.
Fix this by clearing interrupt enable bits before the handler is
uninstalled. Also move the interrupt control bit flipping into a separate
pmz_interrupt_control() routine. Replace all instances of these operations
with calls to this routine. Omit the zssync() calls that seem to serve no
purpose.
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Acked-by: Alan Cox <alan@linux.intel.com>
---
Re-implemented as v2 using a simpler approach that avoids messing with the
Master Interrupt Enable bit. As well as the ifdef problem, it turns out
that v1 was not sufficient to entirely fix the problem.
v3 avoids needless changes to the logic and locking in the suspend and
shutdown code and tries to keep register writes closer to their original
sequence.
This patch has been tested on a PowerBook 520 but no PowerMacs yet.
Index: linux-git/drivers/tty/serial/pmac_zilog.c
===================================================================
--- linux-git.orig/drivers/tty/serial/pmac_zilog.c 2011-12-07 12:36:32.000000000 +1100
+++ linux-git/drivers/tty/serial/pmac_zilog.c 2011-12-07 14:29:21.000000000 +1100
@@ -216,6 +216,18 @@ static void pmz_maybe_update_regs(struct
}
}
+static void pmz_interrupt_control(struct uart_pmac_port *uap, int enable)
+{
+ if (enable) {
+ uap->curregs[1] |= INT_ALL_Rx | TxINT_ENAB;
+ if (!ZS_IS_EXTCLK(uap))
+ uap->curregs[1] |= EXT_INT_ENAB;
+ } else {
+ uap->curregs[1] &= ~(EXT_INT_ENAB | TxINT_ENAB | RxINT_MASK);
+ }
+ write_zsreg(uap, R1, uap->curregs[1]);
+}
+
static struct tty_struct *pmz_receive_chars(struct uart_pmac_port *uap)
{
struct tty_struct *tty = NULL;
@@ -339,9 +351,7 @@ static struct tty_struct *pmz_receive_ch
return tty;
flood:
- uap->curregs[R1] &= ~(EXT_INT_ENAB | TxINT_ENAB | RxINT_MASK);
- write_zsreg(uap, R1, uap->curregs[R1]);
- zssync(uap);
+ pmz_interrupt_control(uap, 0);
pmz_error("pmz: rx irq flood !\n");
return tty;
}
@@ -990,12 +1000,9 @@ static int pmz_startup(struct uart_port
if (ZS_IS_IRDA(uap))
pmz_irda_reset(uap);
- /* Enable interrupts emission from the chip */
+ /* Enable interrupt requests for the channel */
spin_lock_irqsave(&port->lock, flags);
- uap->curregs[R1] |= INT_ALL_Rx | TxINT_ENAB;
- if (!ZS_IS_EXTCLK(uap))
- uap->curregs[R1] |= EXT_INT_ENAB;
- write_zsreg(uap, R1, uap->curregs[R1]);
+ pmz_interrupt_control(uap, 1);
spin_unlock_irqrestore(&port->lock, flags);
pmz_debug("pmz: startup() done.\n");
@@ -1015,6 +1022,25 @@ static void pmz_shutdown(struct uart_por
mutex_lock(&pmz_irq_mutex);
+ spin_lock_irqsave(&port->lock, flags);
+
+ if (!ZS_IS_ASLEEP(uap)) {
+ /* Disable interrupt requests for the channel */
+ pmz_interrupt_control(uap, 0);
+
+ if (!ZS_IS_CONS(uap)) {
+ /* Disable receiver and transmitter */
+ uap->curregs[R3] &= ~RxENABLE;
+ uap->curregs[R5] &= ~TxENABLE;
+
+ /* Disable break assertion */
+ uap->curregs[R5] &= ~SND_BRK;
+ pmz_maybe_update_regs(uap);
+ }
+ }
+
+ spin_unlock_irqrestore(&port->lock, flags);
+
/* Release interrupt handler */
free_irq(uap->port.irq, uap);
@@ -1025,29 +1051,8 @@ static void pmz_shutdown(struct uart_por
if (!ZS_IS_OPEN(uap->mate))
pmz_get_port_A(uap)->flags &= ~PMACZILOG_FLAG_IS_IRQ_ON;
- /* Disable interrupts */
- if (!ZS_IS_ASLEEP(uap)) {
- uap->curregs[R1] &= ~(EXT_INT_ENAB | TxINT_ENAB | RxINT_MASK);
- write_zsreg(uap, R1, uap->curregs[R1]);
- zssync(uap);
- }
-
- if (ZS_IS_CONS(uap) || ZS_IS_ASLEEP(uap)) {
- spin_unlock_irqrestore(&port->lock, flags);
- mutex_unlock(&pmz_irq_mutex);
- return;
- }
-
- /* Disable receiver and transmitter. */
- uap->curregs[R3] &= ~RxENABLE;
- uap->curregs[R5] &= ~TxENABLE;
-
- /* Disable all interrupts and BRK assertion. */
- uap->curregs[R5] &= ~SND_BRK;
- pmz_maybe_update_regs(uap);
-
- /* Shut the chip down */
- pmz_set_scc_power(uap, 0);
+ if (!ZS_IS_ASLEEP(uap) && !ZS_IS_CONS(uap))
+ pmz_set_scc_power(uap, 0); /* Shut the chip down */
spin_unlock_irqrestore(&port->lock, flags);
@@ -1352,19 +1357,15 @@ static void pmz_set_termios(struct uart_
spin_lock_irqsave(&port->lock, flags);
/* Disable IRQs on the port */
- uap->curregs[R1] &= ~(EXT_INT_ENAB | TxINT_ENAB | RxINT_MASK);
- write_zsreg(uap, R1, uap->curregs[R1]);
+ pmz_interrupt_control(uap, 0);
/* Setup new port configuration */
__pmz_set_termios(port, termios, old);
/* Re-enable IRQs on the port */
- if (ZS_IS_OPEN(uap)) {
- uap->curregs[R1] |= INT_ALL_Rx | TxINT_ENAB;
- if (!ZS_IS_EXTCLK(uap))
- uap->curregs[R1] |= EXT_INT_ENAB;
- write_zsreg(uap, R1, uap->curregs[R1]);
- }
+ if (ZS_IS_OPEN(uap))
+ pmz_interrupt_control(uap, 1);
+
spin_unlock_irqrestore(&port->lock, flags);
}
@@ -1671,14 +1672,17 @@ static int pmz_suspend(struct macio_dev
spin_lock_irqsave(&uap->port.lock, flags);
if (ZS_IS_OPEN(uap) || ZS_IS_CONS(uap)) {
- /* Disable receiver and transmitter. */
+ /* Disable interrupt requests for the channel */
+ pmz_interrupt_control(uap, 0);
+
+ /* Disable receiver and transmitter */
uap->curregs[R3] &= ~RxENABLE;
uap->curregs[R5] &= ~TxENABLE;
- /* Disable all interrupts and BRK assertion. */
- uap->curregs[R1] &= ~(EXT_INT_ENAB | TxINT_ENAB | RxINT_MASK);
+ /* Disable break assertion */
uap->curregs[R5] &= ~SND_BRK;
pmz_load_zsregs(uap, uap->curregs);
+
uap->flags |= PMACZILOG_FLAG_IS_ASLEEP;
mb();
}
@@ -1738,14 +1742,6 @@ static int pmz_resume(struct macio_dev *
/* Take care of config that may have changed while asleep */
__pmz_set_termios(&uap->port, &uap->termios_cache, NULL);
- if (ZS_IS_OPEN(uap)) {
- /* Enable interrupts */
- uap->curregs[R1] |= INT_ALL_Rx | TxINT_ENAB;
- if (!ZS_IS_EXTCLK(uap))
- uap->curregs[R1] |= EXT_INT_ENAB;
- write_zsreg(uap, R1, uap->curregs[R1]);
- }
-
spin_unlock_irqrestore(&uap->port.lock, flags);
if (ZS_IS_CONS(uap))
@@ -1757,6 +1753,12 @@ static int pmz_resume(struct macio_dev *
enable_irq(uap->port.irq);
}
+ if (ZS_IS_OPEN(uap)) {
+ spin_lock_irqsave(&uap->port.lock, flags);
+ pmz_interrupt_control(uap, 1);
+ spin_unlock_irqrestore(&uap->port.lock, flags);
+ }
+
bail:
mutex_unlock(&state->port.mutex);
mutex_unlock(&pmz_irq_mutex);
^ permalink raw reply
* [GIT PULL] tty-next: Fix Fsl 8250 BRK bug
From: Paul Gortmaker @ 2011-12-07 3:39 UTC (permalink / raw)
To: gregkh; +Cc: linux-kernel, linuxppc-dev, linux-serial, alan
Hi Greg,
This is the Freescale hardware bug fix which turned into a
six-pack of 8250 updates. This is exactly what was posted
in the v2 review, with just Alan's ack added[1]. Since nobody
else has had any follow-on comments since then, I'm assuming
that it is now good to go.
[1] https://lkml.org/lkml/2011/12/5/156
Thanks,
Paul.
---
Please pull for tty-next to get:
The following changes since commit 5611cc4572e889b62a7b4c72a413536bf6a9c416:
Linux 3.2-rc4 (2011-12-01 14:56:01 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux fsl-uart-fix
Paul Gortmaker (6):
serial: move struct uart_8250_port from 8250.c to 8250.h
serial: clean up parameter passing for 8250 Rx IRQ handling
serial: export the key functions for an 8250 IRQ handler
serial: make 8250 timeout use the specified IRQ handler
serial: manually inline serial8250_handle_port
serial: add irq handler for Freescale 16550 errata.
arch/powerpc/kernel/legacy_serial.c | 3 +
drivers/tty/serial/8250.c | 92 ++++++++++++-----------------------
drivers/tty/serial/8250.h | 26 ++++++++++
drivers/tty/serial/8250_fsl.c | 63 ++++++++++++++++++++++++
drivers/tty/serial/Kconfig | 5 ++
drivers/tty/serial/Makefile | 1 +
include/linux/serial_8250.h | 5 ++
7 files changed, 134 insertions(+), 61 deletions(-)
create mode 100644 drivers/tty/serial/8250_fsl.c
^ permalink raw reply
* RE: [PATCH 2/2 v2] mtd/nand: Add ONFI support for FSL NAND controller
From: Liu Shengzhou-B36685 @ 2011-12-07 3:16 UTC (permalink / raw)
To: Wood Scott-B07421
Cc: linux-mtd@lists.infradead.org, Gala Kumar-B11780,
linuxppc-dev@lists.ozlabs.org, dwmw2@infradead.org
In-Reply-To: <4EDE4E1D.4030408@freescale.com>
DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFdvb2QgU2NvdHQtQjA3NDIx
DQo+IFNlbnQ6IFdlZG5lc2RheSwgRGVjZW1iZXIgMDcsIDIwMTEgMToxNyBBTQ0KPiBUbzogTGl1
IFNoZW5nemhvdS1CMzY2ODUNCj4gQ2M6IGxpbnV4cHBjLWRldkBsaXN0cy5vemxhYnMub3JnOyBs
aW51eC1tdGRAbGlzdHMuaW5mcmFkZWFkLm9yZzsNCj4gZHdtdzJAaW5mcmFkZWFkLm9yZzsgR2Fs
YSBLdW1hci1CMTE3ODANCj4gU3ViamVjdDogUmU6IFtQQVRDSCAyLzIgdjJdIG10ZC9uYW5kOiBB
ZGQgT05GSSBzdXBwb3J0IGZvciBGU0wgTkFORA0KPiBjb250cm9sbGVyDQo+IA0KPiBPbiAxMi8w
Ni8yMDExIDAyOjU0IEFNLCBTaGVuZ3pob3UgTGl1IHdyb3RlOg0KPiA+IGRpZmYgLS1naXQgYS9k
cml2ZXJzL210ZC9uYW5kL2ZzbF9lbGJjX25hbmQuYw0KPiBiL2RyaXZlcnMvbXRkL25hbmQvZnNs
X2VsYmNfbmFuZC5jDQo+ID4gaW5kZXggNGY0MDVhMC4uYjRkYjQwNyAxMDA2NDQNCj4gPiAtLS0g
YS9kcml2ZXJzL210ZC9uYW5kL2ZzbF9lbGJjX25hbmQuYw0KPiA+ICsrKyBiL2RyaXZlcnMvbXRk
L25hbmQvZnNsX2VsYmNfbmFuZC5jDQo+ID4gQEAgLTM0OSwxOSArMzQ5LDI0IEBAIHN0YXRpYyB2
b2lkIGZzbF9lbGJjX2NtZGZ1bmMoc3RydWN0IG10ZF9pbmZvICptdGQsDQo+IHVuc2lnbmVkIGlu
dCBjb21tYW5kLA0KPiA+ICAJCWZzbF9lbGJjX3J1bl9jb21tYW5kKG10ZCk7DQo+ID4gIAkJcmV0
dXJuOw0KPiA+DQo+ID4gLQkvKiBSRUFESUQgbXVzdCByZWFkIGFsbCA1IHBvc3NpYmxlIGJ5dGVz
IHdoaWxlIENFQiBpcyBhY3RpdmUgKi8NCj4gPiAgCWNhc2UgTkFORF9DTURfUkVBRElEOg0KPiA+
IC0JCWRldl92ZGJnKHByaXYtPmRldiwgImZzbF9lbGJjX2NtZGZ1bmM6IE5BTkRfQ01EX1JFQURJ
RC5cbiIpOw0KPiA+ICsJY2FzZSBOQU5EX0NNRF9QQVJBTToNCj4gPiArCQlkZXZfdmRiZyhwcml2
LT5kZXYsICJmc2xfZWxiY19jbWRmdW5jOiBOQU5EX0NNRCAleFxuIiwNCj4gY29tbWFuZCk7DQo+
ID4NCj4gPiAgCQlvdXRfYmUzMigmbGJjLT5maXIsIChGSVJfT1BfQ00wIDw8IEZJUl9PUDBfU0hJ
RlQpIHwNCj4gPiAgCQkgICAgICAgICAgICAgICAgICAgIChGSVJfT1BfVUEgIDw8IEZJUl9PUDFf
U0hJRlQpIHwNCj4gPiAgCQkgICAgICAgICAgICAgICAgICAgIChGSVJfT1BfUkJXIDw8IEZJUl9P
UDJfU0hJRlQpKTsNCj4gPiAtCQlvdXRfYmUzMigmbGJjLT5mY3IsIE5BTkRfQ01EX1JFQURJRCA8
PCBGQ1JfQ01EMF9TSElGVCk7DQo+ID4gLQkJLyogbmFuZF9nZXRfZmxhc2hfdHlwZSgpIHJlYWRz
IDggYnl0ZXMgb2YgZW50aXJlIElEIHN0cmluZyAqLw0KPiA+IC0JCW91dF9iZTMyKCZsYmMtPmZi
Y3IsIDgpOw0KPiA+IC0JCWVsYmNfZmNtX2N0cmwtPnJlYWRfYnl0ZXMgPSA4Ow0KPiA+ICsJCW91
dF9iZTMyKCZsYmMtPmZjciwgY29tbWFuZCA8PCBGQ1JfQ01EMF9TSElGVCk7DQo+ID4gKwkJLyog
cmVhZHMgOCBieXRlcyBvZiBlbnRpcmUgSUQgc3RyaW5nICovDQo+ID4gKwkJaWYgKE5BTkRfQ01E
X1JFQURJRCA9PSBjb21tYW5kKSB7DQo+IA0KPiBpZiAoY29tbWFuZCA9PSBOQU5EX0NNRF9SRUFE
SUQpIHsNCj4gDQo+ID4gKwkJCW91dF9iZTMyKCZsYmMtPmZiY3IsIDgpOw0KPiA+ICsJCQllbGJj
X2ZjbV9jdHJsLT5yZWFkX2J5dGVzID0gODsNCj4gPiArCQl9IGVsc2Ugew0KPiA+ICsJCQlvdXRf
YmUzMigmbGJjLT5mYmNyLCAyNTYpOw0KPiA+ICsJCQllbGJjX2ZjbV9jdHJsLT5yZWFkX2J5dGVz
ID0gMjU2Ow0KPiA+ICsJCX0NCj4gDQo+IEFueSBoYXJtIGluIGFsd2F5cyB1c2luZyAyNTY/DQo+
IA0KPiAtU2NvdHQNCltTaGVuZ3pob3VdIEZvciBOQU5EX0NNRF9SRUFESUQgY29tbWFuZCwgdGhl
IHRvdGFsIGJ5dGVzIG9mIGVudGlyZSBJRCBzdHJpbmcgYXJlIDgsIHRoZXJlIGFyZSBub3QgMjU2
IGJ5dGVzIHNvIG1hbnksIGl0J3MgdW5uZWNlc3NhcnkgYW5kIGxvb2tzIG5vdCBzbyB3ZWxsIGxv
Z2ljYWxseSB0byBhbHdheXMgdXNpbmcgMjU2LCB0aG91Z2ggaXQgd29ya3MuDQoNCg0K
^ permalink raw reply
* RE: [PATCH] rapidio/tsi721: Fix mailbox resource reporting
From: Bounine, Alexandre @ 2011-12-07 2:33 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20111206143638.12598c7b.akpm@linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 1195 bytes --]
Tsi721 patches are applicable to 3.2-rc1 and newer only. Sorry for not describing it properly.
This and following patch are fixes for issues found since 3.2-rc1.
I will update changelogs for these patches with more details and resubmit them tomorrow.
________________________________
From: linuxppc-dev-bounces+alexandre.bounine=idt.com@lists.ozlabs.org on behalf of Andrew Morton
Sent: Tue 12/6/2011 5:36 PM
To: Bounine, Alexandre
Cc: linuxppc-dev@lists.ozlabs.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH] rapidio/tsi721: Fix mailbox resource reporting
On Tue, 6 Dec 2011 14:01:27 -0500
Alexandre Bounine <alexandre.bounine@idt.com> wrote:
> Report support of four RapidIO mailboxes (MBOX0 - MBOX3) instead of MBOX0
> only.
I don't know how important these changes are and I don't know what
their end user visible effects are. Hence I am unable to decide which
kernel version(s) we should merge the patches into.
That's why these things should always be explained in changelogs,
please.
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[-- Attachment #2: Type: text/html, Size: 1916 bytes --]
^ permalink raw reply
* Re: pata_sl82c105 is unable to properly handle dma (indeed it try to use mwdma2)
From: Benjamin Herrenschmidt @ 2011-12-07 2:21 UTC (permalink / raw)
To: acrux_it@libero.it; +Cc: linux-ide, linuxppc-dev
In-Reply-To: <28546010.491181323220500482.JavaMail.defaultUser@defaultHost>
On Wed, 2011-12-07 at 02:15 +0100, acrux_it@libero.it wrote:
> New pata_sl82c105 is unable to properly handle dma (indeed it try to use
> mwdma2).
> Old ide driver instead worked fine.
>
> Tested on IBM 9114-275 where to use it i must boot with dma disabled i.e. with
> libata.dma=0
Adding the linux-ide list on CC. Can you also send a dmesg with the old
IDE driver ? It might be useful to compare the values programmed by the
2 versions of the driver in the timing registers.
Cheers,
Ben.
> [...]
> pata_sl82c105 0000:00:03.1: enabling device (0144 -> 0145)
> scsi1 : pata_sl82c105
> scsi2 : pata_sl82c105
> ata1: PATA max MWDMA2 cmd 0x1f000 ctl 0x1f010 bmdma 0x1f040 irq 165
> ata2: PATA max MWDMA2 cmd 0x1f020 ctl 0x1f030 bmdma 0x1f048 irq 165
> ata1.00: ATAPI: IBM DROM00205, NR38, max UDMA/33
> ata1.00: configured for MWDMA2
> [...]
> scsi 1:0:0:0: CD-ROM IBM DROM00205 NR38 PQ: 0 ANSI: 2
> sr0: scsi3-mmc drive: 24x/24x cd/rw xa/form2 cdda tray
> cdrom: Uniform CD-ROM driver Revision: 3.20
> sr 1:0:0:0: Attached scsi generic sg3 type 5
> [...]
> ata1: lost interrupt (Status 0x50)
> ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
> sr 1:0:0:0: CDB: Get configuration: 46 00 00 00 00 00 00 00 20 00
> ata1.00: cmd a0/01:00:00:20:00/00:00:00:00:00/a0 tag 0 dma 16416 in
> res 40/00:02:00:0c:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
> ata1.00: status: { DRDY }
> ata1: soft resetting link
> ata1.00: configured for MWDMA2
> ata1: EH complete
> sr0: CDROM (ioctl) error, command: Get configuration 46 00 00 00 00 00 00 00
> 20 00
> sr: Sense Key : Aborted Command [current] [descriptor]
> sr: Add. Sense: No additional sense information
> ata1: lost interrupt (Status 0x50)
> ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
> sr 1:0:0:0: CDB: Xdread, Read track info: 52 01 00 00 00 01 00 00 20 00
> ata1.00: cmd a0/01:00:00:20:00/00:00:00:00:00/a0 tag 0 dma 16416 in
> res 40/00:02:00:08:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
> ata1.00: status: { DRDY }
> ata1: soft resetting link
> ata1.00: configured for MWDMA2
> ata1: EH complete
> sr0: CDROM (ioctl) error, command: Xdread, Read track info 52 01 00 00 00 01
> 00 000
> sr: Sense Key : Aborted Command [current] [descriptor]
> sr: Add. Sense: No additional sense information
> ata1: lost interrupt (Status 0x50)
> ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
> sr 1:0:0:0: CDB: Get configuration: 46 00 00 00 00 00 00 00 20 00
> ata1.00: cmd a0/01:00:00:20:00/00:00:00:00:00/a0 tag 0 dma 16416 in
> res 40/00:02:00:0c:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
> ata1.00: status: { DRDY }
> ata1: soft resetting link
> ata1.00: configured for MWDMA2
> ata1: EH complete
> sr0: CDROM (ioctl) error, command: Get configuration 46 00 00 00 00 00 00 00
> 20 00
> sr: Sense Key : Aborted Command [current] [descriptor]
> sr: Add. Sense: No additional sense information
> ata1: lost interrupt (Status 0x50)
> ata1.00: limiting speed to MWDMA1:PIO4
> ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
> sr 1:0:0:0: CDB: Get configuration: 46 00 00 00 00 00 00 00 20 00
> ata1.00: cmd a0/01:00:00:20:00/00:00:00:00:00/a0 tag 0 dma 16416 in
> res 40/00:02:00:0c:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
> ata1.00: status: { DRDY }
> ata1: soft resetting link
> ata1.00: configured for MWDMA1
> ata1: EH complete
> sr0: CDROM (ioctl) error, command: Get configuration 46 00 00 00 00 00 00 00
> 20 00
> sr: Sense Key : Aborted Command [current] [descriptor]
> sr: Add. Sense: No additional sense information
> ata1: lost interrupt (Status 0x50)
> ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
> sr 1:0:0:0: CDB: Get configuration: 46 00 00 00 00 00 00 00 20 00
> ata1.00: cmd a0/01:00:00:20:00/00:00:00:00:00/a0 tag 0 dma 16416 in
> res 40/00:02:00:0c:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
> ata1.00: status: { DRDY }
> ata1: soft resetting link
> ata1.00: configured for MWDMA1
> ata1: EH complete
> sr0: CDROM (ioctl) error, command: Get configuration 46 00 00 00 00 00 00 00
> 20 00
> sr: Sense Key : Aborted Command [current] [descriptor]
> sr: Add. Sense: No additional sense information
> ata1: lost interrupt (Status 0x50)
> ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
> sr 1:0:0:0: CDB: Get configuration: 46 00 00 00 00 00 00 00 20 00
> ata1.00: cmd a0/01:00:00:20:00/00:00:00:00:00/a0 tag 0 dma 16416 in
> res 40/00:02:00:0c:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
> ata1.00: status: { DRDY }
> ata1: soft resetting link
> ata1.00: configured for MWDMA1
> ata1: EH complete
> sr0: CDROM (ioctl) error, command: Get configuration 46 00 00 00 00 00 00 00
> 20 00
> sr: Sense Key : Aborted Command [current] [descriptor]
> sr: Add. Sense: No additional sense information
> ata1: lost interrupt (Status 0x50)
> ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
> sr 1:0:0:0: CDB: Get configuration: 46 00 00 00 00 00 00 00 20 00
> ata1.00: cmd a0/01:00:00:20:00/00:00:00:00:00/a0 tag 0 dma 16416 in
> res 40/00:02:00:0c:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
> ata1.00: status: { DRDY }
> ata1: soft resetting link
> ata1.00: configured for MWDMA1
> ata1: EH complete
> sr0: CDROM (ioctl) error, command: Get configuration 46 00 00 00 00 00 00 00
> 20 00
> sr: Sense Key : Aborted Command [current] [descriptor]
> sr: Add. Sense: No additional sense information
> ata1: lost interrupt (Status 0x50)
> ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
> sr 1:0:0:0: CDB: Get configuration: 46 00 00 00 00 00 00 00 20 00
> ata1.00: cmd a0/01:00:00:20:00/00:00:00:00:00/a0 tag 0 dma 16416 in
> res 40/00:02:00:0c:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
> ata1.00: status: { DRDY }
> ata1: soft resetting link
> ata1.00: configured for MWDMA1
> ata1: EH complete
>
>
>
>
>
>
>
> cheers,
> --nico
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH 01/16 v2] pmac_zilog: fix unexpected irq
From: Finn Thain @ 2011-12-07 1:26 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linux-m68k, linuxppc-dev, linux-serial
In-Reply-To: <CAMuHMdUB-jQQB=ieumYTehdZz1EnoSazEAhsnEunHSnK2o=k8Q@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2634 bytes --]
On Tue, 6 Dec 2011, Geert Uytterhoeven wrote:
> Hi Finn,
>
> On Tue, Dec 6, 2011 at 16:13, Finn Thain <fthain@telegraphics.com.au> wrote:
> > +static void pmz_interrupt_control(struct uart_pmac_port *uap, int enable)
> > +{
> > + if (enable) {
> > + uap->curregs[1] |= INT_ALL_Rx | TxINT_ENAB;
> > + if (!ZS_IS_EXTCLK(uap))
> > + uap->curregs[1] |= EXT_INT_ENAB;
> > + } else {
> > + uap->curregs[1] &= ~(EXT_INT_ENAB | TxINT_ENAB | RxINT_MASK);
>
> Should there be a call to zssync() here?
I don't think so. Though I should have mentioned the change in the patch
header.
> The old code always did that after disabling interrupts.
pmz_load_zsregs(), pmz_set_termios() and pmz_suspend() don't do it.
sunzilog only does it on sparc64 and only when writing to the data
register or writing command modifiers to the control register ("On 64-bit
sparc we only need to flush single writes to ensure completion.")
I can't find any purpose for control register reads in the chip manual.
The zssync() calls following some WR1 writes originate here:
http://git.kernel.org/?p=linux/kernel/git/tglx/history.git;a=commitdiff;h=9e9d9f693c7def3900725c04c6b64311655eea51
So I don't see any need for control register reads but hopefully Ben can
say for sure.
Reading the patch now I notice that I dropped a pmz_maybe_update_regs() or
pmz_load_zsregs() in the suspend path. I will send a new patch.
Finn
>
> > + }
> > + write_zsreg(uap, R1, uap->curregs[1]);
> > +}
> > +
> > static struct tty_struct *pmz_receive_chars(struct uart_pmac_port *uap)
> > {
> > struct tty_struct *tty = NULL;
> > @@ -339,9 +351,7 @@ static struct tty_struct *pmz_receive_ch
> >
> > return tty;
> > flood:
> > - uap->curregs[R1] &= ~(EXT_INT_ENAB | TxINT_ENAB | RxINT_MASK);
> > - write_zsreg(uap, R1, uap->curregs[R1]);
> > - zssync(uap);
>
> Cfr. e.g. here.
>
> > + pmz_interrupt_control(uap, 0);
> > pmz_error("pmz: rx irq flood !\n");
> > return tty;
> > }
>
> 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
* pata_sl82c105 is unable to properly handle dma (indeed it try to use mwdma2)
From: acrux_it @ 2011-12-07 1:15 UTC (permalink / raw)
To: linuxppc-dev
New pata_sl82c105 is unable to properly handle dma (indeed it try to use
mwdma2).
Old ide driver instead worked fine.
Tested on IBM 9114-275 where to use it i must boot with dma disabled i.e. with
libata.dma=0
[...]
pata_sl82c105 0000:00:03.1: enabling device (0144 -> 0145)
scsi1 : pata_sl82c105
scsi2 : pata_sl82c105
ata1: PATA max MWDMA2 cmd 0x1f000 ctl 0x1f010 bmdma 0x1f040 irq 165
ata2: PATA max MWDMA2 cmd 0x1f020 ctl 0x1f030 bmdma 0x1f048 irq 165
ata1.00: ATAPI: IBM DROM00205, NR38, max UDMA/33
ata1.00: configured for MWDMA2
[...]
scsi 1:0:0:0: CD-ROM IBM DROM00205 NR38 PQ: 0 ANSI: 2
sr0: scsi3-mmc drive: 24x/24x cd/rw xa/form2 cdda tray
cdrom: Uniform CD-ROM driver Revision: 3.20
sr 1:0:0:0: Attached scsi generic sg3 type 5
[...]
ata1: lost interrupt (Status 0x50)
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
sr 1:0:0:0: CDB: Get configuration: 46 00 00 00 00 00 00 00 20 00
ata1.00: cmd a0/01:00:00:20:00/00:00:00:00:00/a0 tag 0 dma 16416 in
res 40/00:02:00:0c:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
ata1.00: status: { DRDY }
ata1: soft resetting link
ata1.00: configured for MWDMA2
ata1: EH complete
sr0: CDROM (ioctl) error, command: Get configuration 46 00 00 00 00 00 00 00
20 00
sr: Sense Key : Aborted Command [current] [descriptor]
sr: Add. Sense: No additional sense information
ata1: lost interrupt (Status 0x50)
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
sr 1:0:0:0: CDB: Xdread, Read track info: 52 01 00 00 00 01 00 00 20 00
ata1.00: cmd a0/01:00:00:20:00/00:00:00:00:00/a0 tag 0 dma 16416 in
res 40/00:02:00:08:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
ata1.00: status: { DRDY }
ata1: soft resetting link
ata1.00: configured for MWDMA2
ata1: EH complete
sr0: CDROM (ioctl) error, command: Xdread, Read track info 52 01 00 00 00 01
00 000
sr: Sense Key : Aborted Command [current] [descriptor]
sr: Add. Sense: No additional sense information
ata1: lost interrupt (Status 0x50)
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
sr 1:0:0:0: CDB: Get configuration: 46 00 00 00 00 00 00 00 20 00
ata1.00: cmd a0/01:00:00:20:00/00:00:00:00:00/a0 tag 0 dma 16416 in
res 40/00:02:00:0c:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
ata1.00: status: { DRDY }
ata1: soft resetting link
ata1.00: configured for MWDMA2
ata1: EH complete
sr0: CDROM (ioctl) error, command: Get configuration 46 00 00 00 00 00 00 00
20 00
sr: Sense Key : Aborted Command [current] [descriptor]
sr: Add. Sense: No additional sense information
ata1: lost interrupt (Status 0x50)
ata1.00: limiting speed to MWDMA1:PIO4
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
sr 1:0:0:0: CDB: Get configuration: 46 00 00 00 00 00 00 00 20 00
ata1.00: cmd a0/01:00:00:20:00/00:00:00:00:00/a0 tag 0 dma 16416 in
res 40/00:02:00:0c:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
ata1.00: status: { DRDY }
ata1: soft resetting link
ata1.00: configured for MWDMA1
ata1: EH complete
sr0: CDROM (ioctl) error, command: Get configuration 46 00 00 00 00 00 00 00
20 00
sr: Sense Key : Aborted Command [current] [descriptor]
sr: Add. Sense: No additional sense information
ata1: lost interrupt (Status 0x50)
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
sr 1:0:0:0: CDB: Get configuration: 46 00 00 00 00 00 00 00 20 00
ata1.00: cmd a0/01:00:00:20:00/00:00:00:00:00/a0 tag 0 dma 16416 in
res 40/00:02:00:0c:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
ata1.00: status: { DRDY }
ata1: soft resetting link
ata1.00: configured for MWDMA1
ata1: EH complete
sr0: CDROM (ioctl) error, command: Get configuration 46 00 00 00 00 00 00 00
20 00
sr: Sense Key : Aborted Command [current] [descriptor]
sr: Add. Sense: No additional sense information
ata1: lost interrupt (Status 0x50)
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
sr 1:0:0:0: CDB: Get configuration: 46 00 00 00 00 00 00 00 20 00
ata1.00: cmd a0/01:00:00:20:00/00:00:00:00:00/a0 tag 0 dma 16416 in
res 40/00:02:00:0c:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
ata1.00: status: { DRDY }
ata1: soft resetting link
ata1.00: configured for MWDMA1
ata1: EH complete
sr0: CDROM (ioctl) error, command: Get configuration 46 00 00 00 00 00 00 00
20 00
sr: Sense Key : Aborted Command [current] [descriptor]
sr: Add. Sense: No additional sense information
ata1: lost interrupt (Status 0x50)
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
sr 1:0:0:0: CDB: Get configuration: 46 00 00 00 00 00 00 00 20 00
ata1.00: cmd a0/01:00:00:20:00/00:00:00:00:00/a0 tag 0 dma 16416 in
res 40/00:02:00:0c:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
ata1.00: status: { DRDY }
ata1: soft resetting link
ata1.00: configured for MWDMA1
ata1: EH complete
sr0: CDROM (ioctl) error, command: Get configuration 46 00 00 00 00 00 00 00
20 00
sr: Sense Key : Aborted Command [current] [descriptor]
sr: Add. Sense: No additional sense information
ata1: lost interrupt (Status 0x50)
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
sr 1:0:0:0: CDB: Get configuration: 46 00 00 00 00 00 00 00 20 00
ata1.00: cmd a0/01:00:00:20:00/00:00:00:00:00/a0 tag 0 dma 16416 in
res 40/00:02:00:0c:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
ata1.00: status: { DRDY }
ata1: soft resetting link
ata1.00: configured for MWDMA1
ata1: EH complete
cheers,
--nico
^ permalink raw reply
* Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
From: Scott Wood @ 2011-12-07 0:09 UTC (permalink / raw)
To: shuo.liu
Cc: Artem.Bityutskiy, linuxppc-dev, linux-kernel, linux-mtd, akpm,
dwmw2
In-Reply-To: <1322973098-2528-3-git-send-email-shuo.liu@freescale.com>
On 12/03/2011 10:31 PM, shuo.liu@freescale.com wrote:
> From: Liu Shuo <shuo.liu@freescale.com>
>
> Freescale FCM controller has a 2K size limitation of buffer RAM. In order
> to support the Nand flash chip whose page size is larger than 2K bytes,
> we read/write 2k data repeatedly by issuing FIR_OP_RB/FIR_OP_WB and save
> them to a large buffer.
>
> Signed-off-by: Liu Shuo <shuo.liu@freescale.com>
> ---
> v3:
> -remove page_size of struct fsl_elbc_mtd.
> -do a oob write by NAND_CMD_RNDIN.
>
> drivers/mtd/nand/fsl_elbc_nand.c | 243 ++++++++++++++++++++++++++++++++++----
> 1 files changed, 218 insertions(+), 25 deletions(-)
What is the plan for bad block marker migration?
> @@ -473,13 +568,72 @@ static void fsl_elbc_cmdfunc(struct mtd_info *mtd, unsigned int command,
> * write so the HW generates the ECC.
> */
> if (elbc_fcm_ctrl->oob || elbc_fcm_ctrl->column != 0 ||
> - elbc_fcm_ctrl->index != mtd->writesize + mtd->oobsize)
> - out_be32(&lbc->fbcr,
> - elbc_fcm_ctrl->index - elbc_fcm_ctrl->column);
> - else
> + elbc_fcm_ctrl->index != mtd->writesize + mtd->oobsize) {
> + if (elbc_fcm_ctrl->oob && mtd->writesize > 2048) {
> + out_be32(&lbc->fbcr, 64);
> + } else {
> + out_be32(&lbc->fbcr, elbc_fcm_ctrl->index
> + - elbc_fcm_ctrl->column);
> + }
We need to limit ourselves to the regions that have actually been
written to in the buffer. fbcr needs to be set separately for first and
last subpages, with intermediate subpages having 0, 64, or 2112 as
appropriate. Subpages that are entirely before column or entirely after
column + index should be skipped.
> + } else {
> + out_be32(&lbc->fir, FIR_OP_WB << FIR_OP1_SHIFT);
> + for (i = 1; i < n; i++) {
> + if (i == n - 1) {
> + elbc_fcm_ctrl->use_mdr = 1;
> + out_be32(&lbc->fir,
> + (FIR_OP_WB << FIR_OP1_SHIFT) |
> + (FIR_OP_CM3 << FIR_OP2_SHIFT) |
> + (FIR_OP_CW1 << FIR_OP3_SHIFT) |
> + (FIR_OP_RS << FIR_OP4_SHIFT));
Please explicitly show the (FIR_OP_NOP << FIR_OP0_SHIFT) compenent.
> + } else if (mtd->writesize >= 2048 && mtd->writesize <= 16 * 1024) {
> +
> setbits32(&lbc->bank[priv->bank].or, OR_FCM_PGS);
Don't insert a blank line here.
-Scott
^ permalink raw reply
* Re: [PATCH][v2] powerpc/85xx: Rework P1022DS device tree
From: Tabi Timur-B04825 @ 2011-12-06 22:44 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1321540377-3672-1-git-send-email-galak@kernel.crashing.org>
On Thu, Nov 17, 2011 at 8:32 AM, Kumar Gala <galak@kernel.crashing.org> wro=
te:=0A=
>=0A=
> @@ -585,30 +222,11 @@=0A=
> =A0 =A0 =A0 =A0};=0A=
>=0A=
> =A0 =A0 =A0 =A0pci1: pcie@fffe0a000 {=0A=
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 compatible =3D "fsl,p1022-pcie";=0A=
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 device_type =3D "pci";=0A=
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 #interrupt-cells =3D <1>;=0A=
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 #size-cells =3D <2>;=0A=
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 #address-cells =3D <3>;=0A=
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0reg =3D <0xf 0xffe0a000 0 0x1000>;=0A=
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 bus-range =3D <0 255>;=0A=
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ranges =3D <0x2000000 0x0 0xc0000000 0xc 0=
x40000000 0x0 0x20000000=0A=
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A00x1000000 0x0 0x000000=
00 0xf 0xffc20000 0x0 0x10000>;=0A=
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 clock-frequency =3D <33333333>;=0A=
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 interrupts =3D <16 2 0 0>;=0A=
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 interrupt-map-mask =3D <0xf800 0 0 7>;=0A=
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 interrupt-map =3D <=0A=
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* IDSEL 0x0 */=0A=
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0000 0 0 1 &mpic 0 1=0A=
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0000 0 0 2 &mpic 1 1=0A=
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0000 0 0 3 &mpic 2 1=0A=
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0000 0 0 4 &mpic 3 1=0A=
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >;=0A=
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0pcie@0 {=0A=
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0reg =3D <0x0 0x0 0x0 0x0 0=
x0>;=0A=
=0A=
Did you forget to delete this 'reg' line?=0A=
=0A=
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 #size-cells =3D <2>;=0A=
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 #address-cells =3D <3>;=0A=
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 device_type =3D "pci";=0A=
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ranges =3D <0x2000000 0x0 =
0xe0000000=0A=
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A00x2000=
000 0x0 0xe0000000=0A=
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A00x0 0x=
20000000=0A=
=0A=
-- =0A=
Timur Tabi=0A=
Linux kernel developer at Freescale=0A=
^ permalink raw reply
* Re: [PATCH] rapidio/tsi721: Fix mailbox resource reporting
From: Andrew Morton @ 2011-12-06 22:36 UTC (permalink / raw)
To: Alexandre Bounine; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1323198088-11669-1-git-send-email-alexandre.bounine@idt.com>
On Tue, 6 Dec 2011 14:01:27 -0500
Alexandre Bounine <alexandre.bounine@idt.com> wrote:
> Report support of four RapidIO mailboxes (MBOX0 - MBOX3) instead of MBOX0
> only.
I don't know how important these changes are and I don't know what
their end user visible effects are. Hence I am unable to decide which
kernel version(s) we should merge the patches into.
That's why these things should always be explained in changelogs,
please.
^ permalink raw reply
* [PATCH] rapidio/tsi721: Fix mailbox resource reporting
From: Alexandre Bounine @ 2011-12-06 19:01 UTC (permalink / raw)
To: akpm, linux-kernel, linuxppc-dev; +Cc: Alexandre Bounine
Report support of four RapidIO mailboxes (MBOX0 - MBOX3) instead of MBOX0
only.
Signed-off-by: Alexandre Bounine <alexandre.bounine@idt.com>
---
drivers/rapidio/devices/tsi721.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/rapidio/devices/tsi721.c b/drivers/rapidio/devices/tsi721.c
index 514c28c..83ac8728 100644
--- a/drivers/rapidio/devices/tsi721.c
+++ b/drivers/rapidio/devices/tsi721.c
@@ -2107,8 +2107,8 @@ static int __devinit tsi721_setup_mport(struct tsi721_device *priv)
INIT_LIST_HEAD(&mport->dbells);
rio_init_dbell_res(&mport->riores[RIO_DOORBELL_RESOURCE], 0, 0xffff);
- rio_init_mbox_res(&mport->riores[RIO_INB_MBOX_RESOURCE], 0, 0);
- rio_init_mbox_res(&mport->riores[RIO_OUTB_MBOX_RESOURCE], 0, 0);
+ rio_init_mbox_res(&mport->riores[RIO_INB_MBOX_RESOURCE], 0, 3);
+ rio_init_mbox_res(&mport->riores[RIO_OUTB_MBOX_RESOURCE], 0, 3);
strcpy(mport->name, "Tsi721 mport");
/* Hook up interrupt handler */
--
1.7.6
^ permalink raw reply related
* [PATCH] rapidio/tsi721: modify PCIe capability settings
From: Alexandre Bounine @ 2011-12-06 19:01 UTC (permalink / raw)
To: akpm, linux-kernel, linuxppc-dev; +Cc: Alexandre Bounine
In-Reply-To: <1323198088-11669-1-git-send-email-alexandre.bounine@idt.com>
Change Completion Timeout Value to avoid data transfer aborts during
intensive data transfers.
Remove hardcoded offset for PCIe capability registers.
Signed-off-by: Alexandre Bounine <alexandre.bounine@idt.com>
---
drivers/rapidio/devices/tsi721.c | 20 +++++++++++++++-----
drivers/rapidio/devices/tsi721.h | 2 ++
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/rapidio/devices/tsi721.c b/drivers/rapidio/devices/tsi721.c
index 83ac8728..691b1ab 100644
--- a/drivers/rapidio/devices/tsi721.c
+++ b/drivers/rapidio/devices/tsi721.c
@@ -2154,7 +2154,7 @@ static int __devinit tsi721_probe(struct pci_dev *pdev,
const struct pci_device_id *id)
{
struct tsi721_device *priv;
- int i;
+ int i, cap;
int err;
u32 regval;
@@ -2262,10 +2262,20 @@ static int __devinit tsi721_probe(struct pci_dev *pdev,
dev_info(&pdev->dev, "Unable to set consistent DMA mask\n");
}
- /* Clear "no snoop" and "relaxed ordering" bits. */
- pci_read_config_dword(pdev, 0x40 + PCI_EXP_DEVCTL, ®val);
- regval &= ~(PCI_EXP_DEVCTL_RELAX_EN | PCI_EXP_DEVCTL_NOSNOOP_EN);
- pci_write_config_dword(pdev, 0x40 + PCI_EXP_DEVCTL, regval);
+ cap = pci_pcie_cap(pdev);
+ BUG_ON(cap == 0);
+
+ /* Clear "no snoop" and "relaxed ordering" bits, use default MRRS. */
+ pci_read_config_dword(pdev, cap + PCI_EXP_DEVCTL, ®val);
+ regval &= ~(PCI_EXP_DEVCTL_READRQ | PCI_EXP_DEVCTL_RELAX_EN |
+ PCI_EXP_DEVCTL_NOSNOOP_EN);
+ regval |= 0x2 << MAX_READ_REQUEST_SZ_SHIFT;
+ pci_write_config_dword(pdev, cap + PCI_EXP_DEVCTL, regval);
+
+ /* Adjust PCIe completion timeout. */
+ pci_read_config_dword(pdev, cap + PCI_EXP_DEVCTL2, ®val);
+ regval &= ~(0x0f);
+ pci_write_config_dword(pdev, cap + PCI_EXP_DEVCTL2, regval | 0x2);
/*
* FIXUP: correct offsets of MSI-X tables in the MSI-X Capability Block
diff --git a/drivers/rapidio/devices/tsi721.h b/drivers/rapidio/devices/tsi721.h
index 58be4de..822e54c 100644
--- a/drivers/rapidio/devices/tsi721.h
+++ b/drivers/rapidio/devices/tsi721.h
@@ -72,6 +72,8 @@
#define TSI721_MSIXPBA_OFFSET 0x2a000
#define TSI721_PCIECFG_EPCTL 0x400
+#define MAX_READ_REQUEST_SZ_SHIFT 12
+
/*
* Event Management Registers
*/
--
1.7.6
^ permalink raw reply related
* Re: [PATCH 2/2 v2] mtd/nand: Add ONFI support for FSL NAND controller
From: Scott Wood @ 2011-12-06 17:17 UTC (permalink / raw)
To: Shengzhou Liu; +Cc: linux-mtd, kumar.gala, linuxppc-dev, dwmw2
In-Reply-To: <1323161655-19050-2-git-send-email-Shengzhou.Liu@freescale.com>
On 12/06/2011 02:54 AM, Shengzhou Liu wrote:
> diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
> index 4f405a0..b4db407 100644
> --- a/drivers/mtd/nand/fsl_elbc_nand.c
> +++ b/drivers/mtd/nand/fsl_elbc_nand.c
> @@ -349,19 +349,24 @@ static void fsl_elbc_cmdfunc(struct mtd_info *mtd, unsigned int command,
> fsl_elbc_run_command(mtd);
> return;
>
> - /* READID must read all 5 possible bytes while CEB is active */
> case NAND_CMD_READID:
> - dev_vdbg(priv->dev, "fsl_elbc_cmdfunc: NAND_CMD_READID.\n");
> + case NAND_CMD_PARAM:
> + dev_vdbg(priv->dev, "fsl_elbc_cmdfunc: NAND_CMD %x\n", command);
>
> out_be32(&lbc->fir, (FIR_OP_CM0 << FIR_OP0_SHIFT) |
> (FIR_OP_UA << FIR_OP1_SHIFT) |
> (FIR_OP_RBW << FIR_OP2_SHIFT));
> - out_be32(&lbc->fcr, NAND_CMD_READID << FCR_CMD0_SHIFT);
> - /* nand_get_flash_type() reads 8 bytes of entire ID string */
> - out_be32(&lbc->fbcr, 8);
> - elbc_fcm_ctrl->read_bytes = 8;
> + out_be32(&lbc->fcr, command << FCR_CMD0_SHIFT);
> + /* reads 8 bytes of entire ID string */
> + if (NAND_CMD_READID == command) {
if (command == NAND_CMD_READID) {
> + out_be32(&lbc->fbcr, 8);
> + elbc_fcm_ctrl->read_bytes = 8;
> + } else {
> + out_be32(&lbc->fbcr, 256);
> + elbc_fcm_ctrl->read_bytes = 256;
> + }
Any harm in always using 256?
-Scott
^ permalink raw reply
* Re: [PATCH 1/2 v2] mtd/nand: fixup for fmr initialization of Freescale NAND controller
From: Scott Wood @ 2011-12-06 17:16 UTC (permalink / raw)
To: Shengzhou Liu; +Cc: linux-mtd, kumar.gala, linuxppc-dev, dwmw2
In-Reply-To: <1323161655-19050-1-git-send-email-Shengzhou.Liu@freescale.com>
On 12/06/2011 02:54 AM, Shengzhou Liu wrote:
> There was a bug for fmr initialization, which lead to fmr was always 0x100
> in fsl_elbc_chip_init() and caused FCM command timeout before calling
> fsl_elbc_chip_init_tail(), now we initialize CWTO to maximum timeout value
> and not relying on the setting of bootloader.
>
> Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
> ---
> v2: make fmr not relying on the setting of bootloader.
>
> drivers/mtd/nand/fsl_elbc_nand.c | 10 +++++-----
> 1 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
> index eedd8ee..4f405a0 100644
> --- a/drivers/mtd/nand/fsl_elbc_nand.c
> +++ b/drivers/mtd/nand/fsl_elbc_nand.c
> @@ -659,9 +659,7 @@ static int fsl_elbc_chip_init_tail(struct mtd_info *mtd)
> if (chip->pagemask & 0xff000000)
> al++;
>
> - /* add to ECCM mode set in fsl_elbc_init */
> - priv->fmr |= (12 << FMR_CWTO_SHIFT) | /* Timeout > 12 ms */
> - (al << FMR_AL_SHIFT);
> + priv->fmr |= al << FMR_AL_SHIFT;
>
> dev_dbg(priv->dev, "fsl_elbc_init: nand->numchips = %d\n",
> chip->numchips);
> @@ -764,8 +762,10 @@ static int fsl_elbc_chip_init(struct fsl_elbc_mtd *priv)
> priv->mtd.priv = chip;
> priv->mtd.owner = THIS_MODULE;
>
> - /* Set the ECCM according to the settings in bootloader.*/
> - priv->fmr = in_be32(&lbc->fmr) & FMR_ECCM;
> + /* set timeout to maximum */
> + priv->fmr = 15 << FMR_CWTO_SHIFT;
> + if (in_be32(&lbc->bank[priv->bank].or) & OR_FCM_PGS)
> + priv->fmr |= FMR_ECCM;
Please do not change the way ECCM is handled. We probably should have
done it this way from the start, but at this point it breaks
compatibility if you have a large page flash and the firmware didn't
touch NAND.
-Scott
^ 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