* [PATCH] powerpc/kernel: Don't add disabled serial device
From: Prabhakar Kushwaha @ 2011-04-06 7:26 UTC (permalink / raw)
To: linuxppc-dev; +Cc: meet2prabhu, Prabhakar Kushwaha
serial port nodes with the property status="disabled" are not usable and so
avoid adding "disabled" port with the system.
Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
---
Based upon git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git(branch master)
This patch is made to support "Re-organizing P1020RDB P2020RDB dts". Creation
of Serial port node doesn't follow of_platform_device_create() way which takes
care case status = "disabled".
arch/powerpc/kernel/legacy_serial.c | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/legacy_serial.c b/arch/powerpc/kernel/legacy_serial.c
index c834757..26566ca 100644
--- a/arch/powerpc/kernel/legacy_serial.c
+++ b/arch/powerpc/kernel/legacy_serial.c
@@ -330,9 +330,11 @@ void __init find_legacy_serial_ports(void)
if (!parent)
continue;
if (of_match_node(legacy_serial_parents, parent) != NULL) {
- index = add_legacy_soc_port(np, np);
- if (index >= 0 && np == stdout)
- legacy_serial_console = index;
+ if (of_device_is_available(np)) {
+ index = add_legacy_soc_port(np, np);
+ if (index >= 0 && np == stdout)
+ legacy_serial_console = index;
+ }
}
of_node_put(parent);
}
--
1.7.3
^ permalink raw reply related
* Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?
From: Uwe Kleine-König @ 2011-04-06 8:41 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: Greg KH, linuxppc-dev, LKML
In-Reply-To: <20110404235259.GA30132@iram.es>
Hi Gabriel,
On Tue, Apr 05, 2011 at 01:52:59AM +0200, Gabriel Paubert wrote:
> I've had the following funny crashes on PPC machines, with
> cataleptic X server as a consequence:
>
> kernel: [drm] Setting GART location based on new memory map
> kernel: Oops: Exception in kernel mode, sig: 4 [#1]
> kernel: CHRP
> kernel: last sysfs file: /sys/devices/pci0001:01/0001:01:08.0/resource
> kernel: NIP: c05648fc LR: c0226f58 CTR: 00000008
> kernel: REGS: ddb53d20 TRAP: 0700 Not tainted (2.6.38)
> kernel: MSR: 00089032 <EE,ME,IR,DR> CR: 48044482 XER: 00000000
> kernel: TASK = ddab12b0[3040] 'Xorg' THREAD: ddb52000
> kernel: GPR00: c0226f34 ddb53dd0 ddab12b0 00000000 c0509e6c 00000000 00000000 00000000
> kernel: GPR08: 00000000 00000000 00000000 00000000 28044488 101f3d8c bf8166b4 00002c00
> kernel: GPR16: 101b9458 1006f1a0 101ebe0c 00000001 101ebe08 00000000 df9efc20 df9efc00
> kernel: GPR24: c0591e54 80546440 ddacf660 df9efc00 c0506048 c0480210 00a00000 df9ef800
> kernel: NIP [c05648fc] platform_device_register_resndata+0x4/0xa4
> kernel: LR [c0226f58] radeon_cp_init+0xd08/0x10c4
> kernel: Call Trace:
> kernel: [ddb53dd0] [c0226f34] radeon_cp_init+0xce4/0x10c4 (unreliable)
> kernel: [ddb53df0] [c020801c] drm_ioctl+0x2c0/0x3e4
> kernel: [ddb53eb0] [c0091264] do_vfs_ioctl+0x674/0x710
> kernel: [ddb53f10] [c0091340] sys_ioctl+0x40/0x70
> kernel: [ddb53f40] [c00111a8] ret_from_syscall+0x0/0x38
> kernel: --- Exception: c01 at 0xfc54a78
> kernel: LR = 0xfc549dc
> kernel: Instruction dump:
> kernel: 736f2e31 32002f75 73722f6c 69622f6c 6962786b 6c617669 65722e73 6f2e3132
> kernel: 006c6962 786b6266 696c652e 736f2e31 <002f7573> 722f6c69 622f6c69 62786b62
> kernel: ---[ end trace ed79daba161e31d9 ]---
>
> As you can see, the processor is trying to execute ASCII strings like
> "/usr/lib/libxkb" and has trouble digesting them :-)
>
> The backtrace is actually missing radeon_cp_init_microcode and radeon_do_init_cp
> which are inlined inside radeon_cp_init.
>
> The trouble is that radeon_cp_init_microcode calls platform_device_register_simple
> which is a simple inline wrapper around platform_device_register_resndata, which
> happens to be already freed and overwritten with something looking like a list
> of filenames, since I have a non modular kernel.
>
> For now I have locally reverted 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8
> which simply added an _init_or_module section attribute to
> platform_device_register_resndata, and X is up again...
>
> Now it may be that it is the ioctl that does not have the right to do
> this. Actually I thought that the name radeon_cp that is registered there
> would appear somwhere under /sys (or /proc) but failed to find it...
I don't know for sure, but it looks strange to me that an ioctl can
register a device. But the fear for such code in the kernel made me
choose not to squash 737a3bb941 into 44f28bdea094. So my POV is that if
the maintainer of the radeon driver thinks registering the device is OK,
reverting 737a3bb9416 is fine for me.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?
From: Dave Airlie @ 2011-04-06 8:46 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: Greg KH, linuxppc-dev, LKML
In-Reply-To: <20110406084101.GB13963@pengutronix.de>
2011/4/6 Uwe Kleine-K=F6nig <u.kleine-koenig@pengutronix.de>:
> Hi Gabriel,
>
> On Tue, Apr 05, 2011 at 01:52:59AM +0200, Gabriel Paubert wrote:
>> I've had the following funny crashes on PPC machines, with
>> cataleptic X server as a consequence:
>>
>> kernel: [drm] Setting GART location based on new memory map
>> kernel: Oops: Exception in kernel mode, sig: 4 [#1]
>> kernel: CHRP
>> kernel: last sysfs file: /sys/devices/pci0001:01/0001:01:08.0/resource
>> kernel: NIP: c05648fc LR: c0226f58 CTR: 00000008
>> kernel: REGS: ddb53d20 TRAP: 0700 =A0 Not tainted =A0(2.6.38)
>> kernel: MSR: 00089032 <EE,ME,IR,DR> =A0CR: 48044482 =A0XER: 00000000
>> kernel: TASK =3D ddab12b0[3040] 'Xorg' THREAD: ddb52000
>> kernel: GPR00: c0226f34 ddb53dd0 ddab12b0 00000000 c0509e6c 00000000 000=
00000 00000000
>> kernel: GPR08: 00000000 00000000 00000000 00000000 28044488 101f3d8c bf8=
166b4 00002c00
>> kernel: GPR16: 101b9458 1006f1a0 101ebe0c 00000001 101ebe08 00000000 df9=
efc20 df9efc00
>> kernel: GPR24: c0591e54 80546440 ddacf660 df9efc00 c0506048 c0480210 00a=
00000 df9ef800
>> kernel: NIP [c05648fc] platform_device_register_resndata+0x4/0xa4
>> kernel: LR [c0226f58] radeon_cp_init+0xd08/0x10c4
>> kernel: Call Trace:
>> kernel: [ddb53dd0] [c0226f34] radeon_cp_init+0xce4/0x10c4 (unreliable)
>> kernel: [ddb53df0] [c020801c] drm_ioctl+0x2c0/0x3e4
>> kernel: [ddb53eb0] [c0091264] do_vfs_ioctl+0x674/0x710
>> kernel: [ddb53f10] [c0091340] sys_ioctl+0x40/0x70
>> kernel: [ddb53f40] [c00111a8] ret_from_syscall+0x0/0x38
>> kernel: --- Exception: c01 at 0xfc54a78
>> kernel: =A0 =A0 LR =3D 0xfc549dc
>> kernel: Instruction dump:
>> kernel: 736f2e31 32002f75 73722f6c 69622f6c 6962786b 6c617669 65722e73 6=
f2e3132
>> kernel: 006c6962 786b6266 696c652e 736f2e31 <002f7573> 722f6c69 622f6c69=
62786b62
>> kernel: ---[ end trace ed79daba161e31d9 ]---
>>
>> As you can see, the processor is trying to execute ASCII strings like
>> "/usr/lib/libxkb" and has trouble digesting them :-)
>>
>> The backtrace is actually missing radeon_cp_init_microcode and radeon_do=
_init_cp
>> which are inlined inside radeon_cp_init.
>>
>> The trouble is that radeon_cp_init_microcode calls platform_device_regis=
ter_simple
>> which is a simple inline wrapper around platform_device_register_resndat=
a, which
>> happens to be already freed and overwritten with something looking like =
a list
>> of filenames, since I have a non modular kernel.
>>
>> For now I have locally reverted 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8
>> which simply added an _init_or_module section attribute to
>> platform_device_register_resndata, and X is up again...
>>
>> Now it may be that it is the ioctl that does not have the right to do
>> this. Actually I thought that the name radeon_cp that is registered ther=
e
>> would appear somwhere under /sys (or /proc) but failed to find it...
> I don't know for sure, but it looks strange to me that an ioctl can
> register a device. But the fear for such code in the kernel made me
> choose not to squash 737a3bb941 into 44f28bdea094. So my POV is that if
> the maintainer of the radeon driver thinks registering the device is OK,
> reverting 737a3bb9416 is fine for me.
This is the old DRM driver for radeon, which relies on userspace to
start X then calls the kernel
to initialise the hardware. Due to this model, there is no device we
can hang off (the PCI device
might already be bound to fbdev), so we are forced to create a
platform device to load the firmware.
So its ugly, unless someone can suggest a better device to hang things
off I don't know of another way.
Dave.
^ permalink raw reply
* Re: [PATCH 00/34] Make kernel build deterministic
From: Ingo Molnar @ 2011-04-06 8:57 UTC (permalink / raw)
To: Artem Bityutskiy
Cc: anil_ravindranath, mchehab, mac, aacraid, linux-mtd,
allan.stephens, hpa, t.sailer, gwingerde, x86, elf, cluster-devel,
ccaulfie, mingo, dougthompson, tipc-discussion, dwmw2,
linux-media, jon.maloy, arnaud.giersch, linux-kbuild, IvDoorn,
teigland, tony.olech, apw, linux-hams, tglx, swhiteho,
linux-arm-kernel, linux-edac, Michal Marek, linux-scsi, netdev,
Greg KH, linux-wireless, linux-kernel, davem, linux-usb,
James.Bottomley, chuanxiao.dong, paulus, linuxppc-dev,
bluesmoke-devel
In-Reply-To: <1302031447.2608.41.camel@koala>
* Artem Bityutskiy <dedekind1@gmail.com> wrote:
> On Tue, 2011-04-05 at 08:49 -0700, Greg KH wrote:
> > On Tue, Apr 05, 2011 at 04:58:47PM +0200, Michal Marek wrote:
> > >
> > > Hi,
> > >
> > > this series makes it possible to build bit-identical kernel image and
> > > modules from identical sources. Of course the build is already
> > > deterministic in terms of behavior of the code, but the various
> > > timestamps embedded in the object files make it hard to compare two
> > > builds, for instance to verify that a makefile cleanup didn't
> > > accidentally change something. A prime example is /proc/config.gz, which
> > > has both a timestamp in the gzip header and a timestamp in the payload
> > > data. With this series applied, a script like this will produce
> > > identical kernels each time:
> >
> > Very nice stuff. Do you want to take the individual patches through one
> > of your trees, or do you mind if the subsystem maintainers take them
> > through theirs?
>
> But unfortunately, it is very easy to break this and for sure it'll be
> broken very soon.
>
> So additionally, I'd suggest:
> 1. Instrument checkpatch.pl and make it err or warn on timestamps.
See the grandparent mail:
checkpatch: Warn about usage of __DATE__, __TIME__ and __TIMESTAMP__
Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH 00/34] Make kernel build deterministic
From: Ingo Molnar @ 2011-04-06 9:01 UTC (permalink / raw)
To: Michal Marek
Cc: anil_ravindranath, mchehab, x86, mac, aacraid, linux-mtd,
allan.stephens, hpa, netdev, t.sailer, gwingerde, IvDoorn, elf,
cluster-devel, ccaulfie, mingo, dougthompson, linux-usb,
linux-media, arnaud.giersch, linux-kbuild, teigland, tony.olech,
apw, linux-hams, tglx, swhiteho, linux-arm-kernel, linux-edac,
jon.maloy, linux-scsi, linuxppc-dev, gregkh, linux-wireless,
linux-kernel, bluesmoke-devel, James.Bottomley, tipc-discussion,
chuanxiao.dong, paulus, dwmw2, davem
In-Reply-To: <1302015561-21047-1-git-send-email-mmarek@suse.cz>
* Michal Marek <mmarek@suse.cz> wrote:
>
> Hi,
>
> this series makes it possible to build bit-identical kernel image and
> modules from identical sources. Of course the build is already
> deterministic in terms of behavior of the code, but the various
> timestamps embedded in the object files make it hard to compare two
> builds, for instance to verify that a makefile cleanup didn't
> accidentally change something. A prime example is /proc/config.gz, which
> has both a timestamp in the gzip header and a timestamp in the payload
> data. With this series applied, a script like this will produce
> identical kernels each time:
>
> #!/bin/bash
> rm -rf /dev/shm/{source,build}{,1,2}
> export KCONFIG_NOTIMESTAMP=1
> export KBUILD_BUILD_TIMESTAMP='Sun May 1 12:00:00 CEST 2011'
> export KBUILD_BUILD_USER=user
> export KBUILD_BUILD_HOST=host
> export ROOT_DEV=FLOPPY
> for i in 1 2; do
> mkdir /dev/shm/source
> # randomize the inode order just for fun
> git ls-tree -r -z --name-only HEAD | sort -R -z | xargs -0 \
> cp --parents --target=/dev/shm/source
> pushd /dev/shm/source
> mkdir /dev/shm/build
> >/dev/shm/build/all.config
> for opt in GCOV_KERNEL UBIFS_FS_DEBUG; do
> echo "# CONFIG_$opt is not set" >>"/dev/shm/build"/all.config
> done
> make O="/dev/shm/build" KCONFIG_ALLCONFIG=1 allmodconfig
> make O="/dev/shm/build" -j64
> popd
> mv /dev/shm/source /dev/shm/source$i
> mv /dev/shm/build /dev/shm/build$i
> done
> diff -rq /dev/shm/build{1,2}
Nice!
Acked-by: Ingo Molnar <mingo@elte.hu>
> Unfortunatelly, this cannot be used to validate indentation-only
> patches, even if CONFIG_DEBUG_INFO is turned off. This is because of the
> __FILE__ and __LINE__ macros used in many places. For the same reason,
> the source and build directory needs to be the same, otherwise the
> results will differ.
Nor can it be used to validate untrusted patches in general: a subtle change
might be introduced in a piece of code that is dependent on a .config detail
that is off for that particular build.
But in the common case it's nice to be able to have deterministic/reproducable
builds.
Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH 00/34] Make kernel build deterministic
From: Michal Marek @ 2011-04-06 9:07 UTC (permalink / raw)
To: dedekind1
Cc: anil_ravindranath, mchehab, mac, aacraid, linux-mtd,
allan.stephens, hpa, t.sailer, gwingerde, x86, elf, cluster-devel,
ccaulfie, mingo, dougthompson, tipc-discussion, dwmw2,
linux-media, arnaud.giersch, linux-kbuild, IvDoorn, teigland,
tony.olech, apw, linux-hams, tglx, swhiteho, linux-arm-kernel,
linux-edac, jon.maloy, linux-scsi, netdev, Greg KH,
linux-wireless, linux-kernel, davem, linux-usb, James.Bottomley,
chuanxiao.dong, paulus, linuxppc-dev, bluesmoke-devel
In-Reply-To: <1302031447.2608.41.camel@koala>
On 5.4.2011 21:24, Artem Bityutskiy wrote:
> On Tue, 2011-04-05 at 08:49 -0700, Greg KH wrote:
>> On Tue, Apr 05, 2011 at 04:58:47PM +0200, Michal Marek wrote:
>>>
>>> Hi,
>>>
>>> this series makes it possible to build bit-identical kernel image and
>>> modules from identical sources. Of course the build is already
>>> deterministic in terms of behavior of the code, but the various
>>> timestamps embedded in the object files make it hard to compare two
>>> builds, for instance to verify that a makefile cleanup didn't
>>> accidentally change something. A prime example is /proc/config.gz, which
>>> has both a timestamp in the gzip header and a timestamp in the payload
>>> data. With this series applied, a script like this will produce
>>> identical kernels each time:
>>
>> Very nice stuff. Do you want to take the individual patches through one
>> of your trees, or do you mind if the subsystem maintainers take them
>> through theirs?
>
> But unfortunately, it is very easy to break this and for sure it'll be
> broken very soon.
I'm not so pessimistic. 34 patches and 57 files might sound like a lot,
but given that this has been accumulating since day one, the cleanup
should last for some time.
> So additionally, I'd suggest:
> 1. Instrument checkpatch.pl and make it err or warn on timestamps.
This is patch 34/34 in this series: https://lkml.org/lkml/2011/4/5/198
> 2. Probably instrument linux-next to rise a warning when people break
> this.
I'm not sure if Stephen has that much spare time, and I don't think it
is necessary. I think the checkpatch check is sufficient and I'll check
myself occasionally.
Michal
^ permalink raw reply
* Re: [PATCH 00/34] Make kernel build deterministic
From: Michal Marek @ 2011-04-06 9:23 UTC (permalink / raw)
To: Greg KH
Cc: anil_ravindranath, mchehab, x86, mac, aacraid, linux-mtd,
allan.stephens, hpa, netdev, t.sailer, gwingerde, IvDoorn, elf,
cluster-devel, ccaulfie, mingo, dougthompson, linux-media,
arnaud.giersch, linux-kbuild, teigland, tony.olech, apw,
linux-hams, tglx, swhiteho, linux-arm-kernel, linux-edac,
jon.maloy, linux-scsi, linuxppc-dev, linux-usb, linux-wireless,
linux-kernel, bluesmoke-devel, James.Bottomley, tipc-discussion,
chuanxiao.dong, paulus, dwmw2, davem
In-Reply-To: <20110405154918.GA31337@suse.de>
On 5.4.2011 17:49, Greg KH wrote:
> Very nice stuff. Do you want to take the individual patches through one
> of your trees, or do you mind if the subsystem maintainers take them
> through theirs?
I'd leave it up to the subsystem maintainers. I'll check once the merge
window opens and send the remaining patches to Linus directly.
Michal
^ permalink raw reply
* Re: [PATCH 00/34] Make kernel build deterministic
From: Artem Bityutskiy @ 2011-04-06 9:25 UTC (permalink / raw)
To: Michal Marek
Cc: anil_ravindranath, mchehab, mac, aacraid, linux-mtd,
allan.stephens, hpa, t.sailer, gwingerde, x86, elf, cluster-devel,
ccaulfie, mingo, dougthompson, tipc-discussion, dwmw2,
linux-media, arnaud.giersch, linux-kbuild, IvDoorn, teigland,
tony.olech, apw, linux-hams, tglx, swhiteho, linux-arm-kernel,
linux-edac, jon.maloy, linux-scsi, netdev, Greg KH,
linux-wireless, linux-kernel, davem, linux-usb, James.Bottomley,
chuanxiao.dong, paulus, linuxppc-dev, bluesmoke-devel
In-Reply-To: <4D9C2D56.70700@suse.cz>
On Wed, 2011-04-06 at 11:07 +0200, Michal Marek wrote:
> > So additionally, I'd suggest:
> > 1. Instrument checkpatch.pl and make it err or warn on timestamps.
>
> This is patch 34/34 in this series: https://lkml.org/lkml/2011/4/5/198
Yeah, great, did not notice, thanks!
> > 2. Probably instrument linux-next to rise a warning when people break
> > this.
>
> I'm not sure if Stephen has that much spare time, and I don't think it
> is necessary. I think the checkpatch check is sufficient and I'll check
> myself occasionally.
Yes, that's fine, I just wanted to speak this out - there is a
probability that someone gets excited and creates some instrumentation
to kbuild to automatically detect bad things and then Stephen could
easily use that.
WRT "not necessary" - well, I think it is always better to cut bad
things before they are merged, rather than afterwards.
But anyway, let's forget about this.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
^ permalink raw reply
* Re: [RFC][PATCH] powerpc/book3e: Fix CPU feature handling on e5500
From: Kumar Gala @ 2011-04-06 12:26 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20110406154147.f736d92e.sfr@canb.auug.org.au>
On Apr 6, 2011, at 12:41 AM, Stephen Rothwell wrote:
> Hi Kumar,
>=20
> On Wed, 6 Apr 2011 00:29:32 -0500 Kumar Gala =
<galak@kernel.crashing.org> wrote:
>>=20
>> * I'm concerned if its ok to assume 'enum' can handle a 64-bit mask =
or not.
>> I'm assuming this is the reason that we use a #define on =
__powerpc64__
>=20
> enums are *ints* and therefore 32 bit. gcc can cope, but warns about =
it
> (I think). So we must use the #define if any of the included bits are
> above 2^32.
Thanks, I'll rework the patch to use #define.
- k=
^ permalink raw reply
* [PATCH] powerpc/book3e: Fix CPU feature handling on 64-bit e5500
From: Kumar Gala @ 2011-04-06 12:29 UTC (permalink / raw)
To: linuxppc-dev
The CPU_FTRS_POSSIBLE and CPU_FTRS_ALWAYS defines did not encompass
e5500 CPU features when built for 64-bit. This causes issues with
cpu_has_feature() as it utilizes the POSSIBLE & ALWAYS defines as part
of its check.
Create a unique CPU_FTRS_E5500 (as its different from CPU_FTRS_E500MC),
created a new group for 64-bit Book3e based CPUs and add CPU_FTRS_E5500
to that group.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
* This patch is intened to fix some issues and I'd like to see it in v2.6.39
- k
arch/powerpc/include/asm/cputable.h | 14 ++++++++++++++
arch/powerpc/kernel/cputable.c | 2 +-
2 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/cputable.h b/arch/powerpc/include/asm/cputable.h
index be3cdf9..9028a9e 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -386,6 +386,10 @@ extern const char *powerpc_base_platform;
CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_NODSISRALIGN | \
CPU_FTR_L2CSR | CPU_FTR_LWSYNC | CPU_FTR_NOEXECUTE | \
CPU_FTR_DBELL)
+#define CPU_FTRS_E5500 (CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB | \
+ CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_NODSISRALIGN | \
+ CPU_FTR_L2CSR | CPU_FTR_LWSYNC | CPU_FTR_NOEXECUTE | \
+ CPU_FTR_DBELL | CPU_FTR_POPCNTB | CPU_FTR_POPCNTD)
#define CPU_FTRS_GENERIC_32 (CPU_FTR_COMMON | CPU_FTR_NODSISRALIGN)
/* 64-bit CPUs */
@@ -435,11 +439,15 @@ extern const char *powerpc_base_platform;
#define CPU_FTRS_COMPATIBLE (CPU_FTR_USE_TB | CPU_FTR_PPCAS_ARCH_V2)
#ifdef __powerpc64__
+#ifdef CONFIG_PPC_BOOK3E
+#define CPU_FTRS_POSSIBLE (CPU_FTRS_E5500)
+#else
#define CPU_FTRS_POSSIBLE \
(CPU_FTRS_POWER3 | CPU_FTRS_RS64 | CPU_FTRS_POWER4 | \
CPU_FTRS_PPC970 | CPU_FTRS_POWER5 | CPU_FTRS_POWER6 | \
CPU_FTRS_POWER7 | CPU_FTRS_CELL | CPU_FTRS_PA6T | \
CPU_FTR_1T_SEGMENT | CPU_FTR_VSX)
+#endif
#else
enum {
CPU_FTRS_POSSIBLE =
@@ -473,16 +481,21 @@ enum {
#endif
#ifdef CONFIG_E500
CPU_FTRS_E500 | CPU_FTRS_E500_2 | CPU_FTRS_E500MC |
+ CPU_FTRS_E5500 |
#endif
0,
};
#endif /* __powerpc64__ */
#ifdef __powerpc64__
+#ifdef CONFIG_PPC_BOOK3E
+#define CPU_FTRS_ALWAYS (CPU_FTRS_E5500)
+#else
#define CPU_FTRS_ALWAYS \
(CPU_FTRS_POWER3 & CPU_FTRS_RS64 & CPU_FTRS_POWER4 & \
CPU_FTRS_PPC970 & CPU_FTRS_POWER5 & CPU_FTRS_POWER6 & \
CPU_FTRS_POWER7 & CPU_FTRS_CELL & CPU_FTRS_PA6T & CPU_FTRS_POSSIBLE)
+#endif
#else
enum {
CPU_FTRS_ALWAYS =
@@ -513,6 +526,7 @@ enum {
#endif
#ifdef CONFIG_E500
CPU_FTRS_E500 & CPU_FTRS_E500_2 & CPU_FTRS_E500MC &
+ CPU_FTRS_E5500 &
#endif
CPU_FTRS_POSSIBLE,
};
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index c9b68d0..b9602ee 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -1973,7 +1973,7 @@ static struct cpu_spec __initdata cpu_specs[] = {
.pvr_mask = 0xffff0000,
.pvr_value = 0x80240000,
.cpu_name = "e5500",
- .cpu_features = CPU_FTRS_E500MC,
+ .cpu_features = CPU_FTRS_E5500,
.cpu_user_features = COMMON_USER_BOOKE,
.mmu_features = MMU_FTR_TYPE_FSL_E | MMU_FTR_BIG_PHYS |
MMU_FTR_USE_TLBILX,
--
1.7.3.4
^ permalink raw reply related
* [RFC][PATCH] powerpc/fsl-booke64: Add support for Debug Level exception handler
From: Kumar Gala @ 2011-04-06 12:30 UTC (permalink / raw)
To: linuxppc-dev
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/include/asm/cputable.h | 4 ++-
arch/powerpc/kernel/exceptions-64e.S | 65 ++++++++++++++++++++++++++++++++--
arch/powerpc/kernel/setup_64.c | 8 ++++
3 files changed, 73 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/cputable.h b/arch/powerpc/include/asm/cputable.h
index 9028a9e..bb9fc80 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -157,6 +157,7 @@ extern const char *powerpc_base_platform;
#define CPU_FTR_476_DD2 ASM_CONST(0x0000000000010000)
#define CPU_FTR_NEED_COHERENT ASM_CONST(0x0000000000020000)
#define CPU_FTR_NO_BTIC ASM_CONST(0x0000000000040000)
+#define CPU_FTR_DEBUG_LVL_EXC ASM_CONST(0x0000000000080000)
#define CPU_FTR_NODSISRALIGN ASM_CONST(0x0000000000100000)
#define CPU_FTR_PPC_LE ASM_CONST(0x0000000000200000)
#define CPU_FTR_REAL_LE ASM_CONST(0x0000000000400000)
@@ -389,7 +390,8 @@ extern const char *powerpc_base_platform;
#define CPU_FTRS_E5500 (CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB | \
CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_NODSISRALIGN | \
CPU_FTR_L2CSR | CPU_FTR_LWSYNC | CPU_FTR_NOEXECUTE | \
- CPU_FTR_DBELL | CPU_FTR_POPCNTB | CPU_FTR_POPCNTD)
+ CPU_FTR_DBELL | CPU_FTR_POPCNTB | CPU_FTR_POPCNTD | \
+ CPU_FTR_DEBUG_LVL_EXC)
#define CPU_FTRS_GENERIC_32 (CPU_FTR_COMMON | CPU_FTR_NODSISRALIGN)
/* 64-bit CPUs */
diff --git a/arch/powerpc/kernel/exceptions-64e.S b/arch/powerpc/kernel/exceptions-64e.S
index 5c43063..28f2223 100644
--- a/arch/powerpc/kernel/exceptions-64e.S
+++ b/arch/powerpc/kernel/exceptions-64e.S
@@ -252,9 +252,6 @@ exception_marker:
.balign 0x1000
.globl interrupt_base_book3e
interrupt_base_book3e: /* fake trap */
- /* Note: If real debug exceptions are supported by the HW, the vector
- * below will have to be patched up to point to an appropriate handler
- */
EXCEPTION_STUB(0x000, machine_check) /* 0x0200 */
EXCEPTION_STUB(0x020, critical_input) /* 0x0580 */
EXCEPTION_STUB(0x040, debug_crit) /* 0x0d00 */
@@ -454,6 +451,68 @@ interrupt_end_book3e:
kernel_dbg_exc:
b . /* NYI */
+/* Debug exception as a debug interrupt*/
+ START_EXCEPTION(debug_debug);
+ DBG_EXCEPTION_PROLOG(0xd00, PROLOG_ADDITION_2REGS)
+
+ /*
+ * If there is a single step or branch-taken exception in an
+ * exception entry sequence, it was probably meant to apply to
+ * the code where the exception occurred (since exception entry
+ * doesn't turn off DE automatically). We simulate the effect
+ * of turning off DE on entry to an exception handler by turning
+ * off DE in the DSRR1 value and clearing the debug status.
+ */
+
+ mfspr r14,SPRN_DBSR /* check single-step/branch taken */
+ andis. r15,r14,DBSR_IC@h
+ beq+ 1f
+
+ LOAD_REG_IMMEDIATE(r14,interrupt_base_book3e)
+ LOAD_REG_IMMEDIATE(r15,interrupt_end_book3e)
+ cmpld cr0,r10,r14
+ cmpld cr1,r10,r15
+ blt+ cr0,1f
+ bge+ cr1,1f
+
+ /* here it looks like we got an inappropriate debug exception. */
+ lis r14,DBSR_IC@h /* clear the IC event */
+ rlwinm r11,r11,0,~MSR_DE /* clear DE in the DSRR1 value */
+ mtspr SPRN_DBSR,r14
+ mtspr SPRN_DSRR1,r11
+ lwz r10,PACA_EXDBG+EX_CR(r13) /* restore registers */
+ ld r1,PACA_EXDBG+EX_R1(r13)
+ ld r14,PACA_EXDBG+EX_R14(r13)
+ ld r15,PACA_EXDBG+EX_R15(r13)
+ mtcr r10
+ ld r10,PACA_EXDBG+EX_R10(r13) /* restore registers */
+ ld r11,PACA_EXDBG+EX_R11(r13)
+ mfspr r13,SPRN_SPRG_DBG_SCRATCH
+ rfdi
+
+ /* Normal debug exception */
+ /* XXX We only handle coming from userspace for now since we can't
+ * quite save properly an interrupted kernel state yet
+ */
+1: andi. r14,r11,MSR_PR; /* check for userspace again */
+ beq kernel_dbg_exc; /* if from kernel mode */
+
+ /* Now we mash up things to make it look like we are coming on a
+ * normal exception
+ */
+ mfspr r15,SPRN_SPRG_DBG_SCRATCH
+ mtspr SPRN_SPRG_GEN_SCRATCH,r15
+ mfspr r14,SPRN_DBSR
+ EXCEPTION_COMMON(0xd00, PACA_EXDBG, INTS_DISABLE_ALL)
+ std r14,_DSISR(r1)
+ addi r3,r1,STACK_FRAME_OVERHEAD
+ mr r4,r14
+ ld r14,PACA_EXDBG+EX_R14(r13)
+ ld r15,PACA_EXDBG+EX_R15(r13)
+ bl .save_nvgprs
+ bl .DebugException
+ b .ret_from_except
+
/* Doorbell interrupt */
MASKABLE_EXCEPTION(0x2070, doorbell, .doorbell_exception, ACK_NONE)
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index 5a0401f..2ff0032 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -62,6 +62,7 @@
#include <asm/udbg.h>
#include <asm/kexec.h>
#include <asm/mmu_context.h>
+#include <asm/code-patching.h>
#include "setup.h"
@@ -453,6 +454,9 @@ static void __init irqstack_early_init(void)
#ifdef CONFIG_PPC_BOOK3E
static void __init exc_lvl_early_init(void)
{
+ extern unsigned int interrupt_base_book3e;
+ extern unsigned int exc_debug_debug_book3e;
+
unsigned int i;
for_each_possible_cpu(i) {
@@ -463,6 +467,10 @@ static void __init exc_lvl_early_init(void)
mcheckirq_ctx[i] = (struct thread_info *)
__va(memblock_alloc(THREAD_SIZE, THREAD_SIZE));
}
+
+ if (cpu_has_feature(CPU_FTR_DEBUG_LVL_EXC))
+ patch_branch(&interrupt_base_book3e + (0x040 / 4) + 1,
+ (unsigned long)&exc_debug_debug_book3e, 0);
}
#else
#define exc_lvl_early_init()
--
1.7.3.4
^ permalink raw reply related
* Re: halt/reset on assert?
From: Evan Lavelle @ 2011-04-06 13:01 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev
In-Reply-To: <m2sju1uoti.fsf@igel.home>
Hi Andreas -
that's great; thanks. I'm on 2.4.4, which doesn't have BUG_ON. The right
way for 2.4.4 turns out to be
#define MY_ASSERT(expr) if(!(expr)) BUG()
-Evan
^ permalink raw reply
* [PATCH 1/1] RapidIO: Add IDT CPS-1432 switch definitions
From: Alexandre Bounine @ 2011-04-06 14:56 UTC (permalink / raw)
To: akpm, linux-kernel, linuxppc-dev; +Cc: Alexandre Bounine
Signed-off-by: Alexandre Bounine <alexandre.bounine@idt.com>
Cc: Matt Porter <mporter@kernel.crashing.org>
Cc: Kumar Gala <galak@kernel.crashing.org>
---
drivers/rapidio/switches/idt_gen2.c | 1 +
include/linux/rio_ids.h | 1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/rapidio/switches/idt_gen2.c b/drivers/rapidio/switches/idt_gen2.c
index 095016a..ac2701b 100644
--- a/drivers/rapidio/switches/idt_gen2.c
+++ b/drivers/rapidio/switches/idt_gen2.c
@@ -418,3 +418,4 @@ DECLARE_RIO_SWITCH_INIT(RIO_VID_IDT, RIO_DID_IDTCPS1848, idtg2_switch_init);
DECLARE_RIO_SWITCH_INIT(RIO_VID_IDT, RIO_DID_IDTCPS1616, idtg2_switch_init);
DECLARE_RIO_SWITCH_INIT(RIO_VID_IDT, RIO_DID_IDTVPS1616, idtg2_switch_init);
DECLARE_RIO_SWITCH_INIT(RIO_VID_IDT, RIO_DID_IDTSPS1616, idtg2_switch_init);
+DECLARE_RIO_SWITCH_INIT(RIO_VID_IDT, RIO_DID_IDTCPS1432, idtg2_switch_init);
diff --git a/include/linux/rio_ids.h b/include/linux/rio_ids.h
index 7410d33..0cee015 100644
--- a/include/linux/rio_ids.h
+++ b/include/linux/rio_ids.h
@@ -35,6 +35,7 @@
#define RIO_DID_IDTCPS6Q 0x035f
#define RIO_DID_IDTCPS10Q 0x035e
#define RIO_DID_IDTCPS1848 0x0374
+#define RIO_DID_IDTCPS1432 0x0375
#define RIO_DID_IDTCPS1616 0x0379
#define RIO_DID_IDTVPS1616 0x0377
#define RIO_DID_IDTSPS1616 0x0378
--
1.7.3.1
^ permalink raw reply related
* Re: [RFC 2/5]arch:powerpc:sysdev:Makefile Remove unused config in the Makefile.
From: Justin Mattock @ 2011-04-06 15:07 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, trivial, linux-kernel, Harninder Rai
In-Reply-To: <20110405131504.1d182da4@schlenkerla.am.freescale.net>
On Tue, Apr 5, 2011 at 11:15 AM, Scott Wood <scottwood@freescale.com> wrote=
:
> On Tue, 5 Apr 2011 09:58:19 -0700
> "Justin P. Mattock" <justinmattock@gmail.com> wrote:
>
>> The patch below removes an unused config variable found by using a kerne=
l
>> cleanup script.
>> Note: I did try to cross compile these but hit erros while doing so..
>> (gcc is not setup to cross compile) and am unsure if anymore needs to be=
done.
>> Please have a look if/when anybody has free time.
>>
>> Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
>> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>> CC: linuxppc-dev@lists.ozlabs.org
>>
>> ---
>> =A0arch/powerpc/sysdev/Makefile | =A0 =A01 -
>> =A01 files changed, 0 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
>> index 1e0c933..243b6ad 100644
>> --- a/arch/powerpc/sysdev/Makefile
>> +++ b/arch/powerpc/sysdev/Makefile
>> @@ -18,7 +18,6 @@ obj-$(CONFIG_FSL_PMC) =A0 =A0 =A0 =A0 =A0 =A0 =A0 +=3D=
fsl_pmc.o
>> =A0obj-$(CONFIG_FSL_LBC) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+=3D fsl_lbc.o
>> =A0obj-$(CONFIG_FSL_GTM) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+=3D fsl_gtm.o
>> =A0obj-$(CONFIG_MPC8xxx_GPIO) =A0 +=3D mpc8xxx_gpio.o
>> -obj-$(CONFIG_FSL_85XX_CACHE_SRAM) =A0 =A0+=3D fsl_85xx_l2ctlr.o fsl_85x=
x_cache_sram.o
>> =A0obj-$(CONFIG_SIMPLE_GPIO) =A0 =A0+=3D simple_gpio.o
>> =A0obj-$(CONFIG_FSL_RIO) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+=3D fsl_rio.o
>> =A0obj-$(CONFIG_TSI108_BRIDGE) =A0+=3D tsi108_pci.o tsi108_dev.o
>
> Those files do exist, and aren't pulled in by any other means I can see.
> It was introduced by commit 6db92cc9d07db9f713da8554b4bcdfc8e54ad386, who=
se
> changelog says:
> =A0 =A0 =A0 =A0Drivers can do the following in Kconfig to use these APIs =
"select
> FSL_85XX_CACHE_SRAM if MPC85xx"
>
> Now, the absence of such a kconfig option[1] is a problem, but I don't th=
ink
> outright removal (labelled "trivial cleanup") is appropriate, unless nobo=
dy
> fixes it after the problem is pointed out. =A0And if it is removed, the f=
iles
> should go with it.
>
> -Scott
>
> [1] and of any drivers that select it, though this was added fairly
> recently -- perhaps such a driver change is on its way?
>
>
ahh.. so the: fsl_85xx_l2ctlr.o fsl_85xx_cache_sram.o is still in use
even though FSL_85XX_CACHE_SRAM is not really used, but really is used!!
but might be wrong with this.
--=20
Justin P. Mattock
^ permalink raw reply
* Re: [RFC 2/5]arch:powerpc:sysdev:Makefile Remove unused config in the Makefile.
From: Scott Wood @ 2011-04-06 16:03 UTC (permalink / raw)
To: Justin Mattock; +Cc: linuxppc-dev, trivial, linux-kernel, Harninder Rai
In-Reply-To: <BANLkTi=5A1P-WAFvCyjbT7RVva9K9d=gQQ@mail.gmail.com>
On Wed, 6 Apr 2011 08:07:58 -0700
Justin Mattock <justinmattock@gmail.com> wrote:
> ahh.. so the: fsl_85xx_l2ctlr.o fsl_85xx_cache_sram.o is still in use
> even though FSL_85XX_CACHE_SRAM is not really used, but really is used!!
>
> but might be wrong with this.
More like there are plans to use it, or possibly out-of-tree users. We
should prod people a bit to submit the driver patches that use this before
we just yank it out.
-Scott
^ permalink raw reply
* Re: [RFC 2/5]arch:powerpc:sysdev:Makefile Remove unused config in the Makefile.
From: Justin Mattock @ 2011-04-06 16:09 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, trivial, linux-kernel, Harninder Rai
In-Reply-To: <20110406110335.0f2d5f4c@schlenkerla.am.freescale.net>
On Wed, Apr 6, 2011 at 9:03 AM, Scott Wood <scottwood@freescale.com> wrote:
> On Wed, 6 Apr 2011 08:07:58 -0700
> Justin Mattock <justinmattock@gmail.com> wrote:
>
>> ahh.. so the: =A0fsl_85xx_l2ctlr.o fsl_85xx_cache_sram.o is still in use
>> even though FSL_85XX_CACHE_SRAM is not really used, but really is used!!
>>
>> but might be wrong with this.
>
> More like there are plans to use it, or possibly out-of-tree users. =A0We
> should prod people a bit to submit the driver patches that use this befor=
e
> we just yank it out.
>
> -Scott
>
>
well if this is going to be used for something down the line, then
best leave it in..
--=20
Justin P. Mattock
^ permalink raw reply
* known working sata_sil24.c setup on powerpc platforms?
From: Leon Woestenberg @ 2011-04-06 17:00 UTC (permalink / raw)
To: Linux PPC, linux-ide, Tejun Heo, Moffett, Kyle D, Jeff Garzik
Hello,
after investigating problems with sata_sil24.c on a freescale p2020
soc, I wonder if this driver works on powerpc at all?
Does anyone know of a working setup of sata_sil24 on a big endian
powerpc system?
Regards,
--
Leon
^ permalink raw reply
* [PATCH] RapidIO/mpc85xx: Fix possible mport registration problems.
From: Alexandre Bounine @ 2011-04-06 17:16 UTC (permalink / raw)
To: akpm, linux-kernel, linuxppc-dev; +Cc: Alexandre Bounine, Thomas Moll
Fix possible problem with mport registration left non cleared after
fsl_rio_setup() exits on link error. Abort mport initialization
if registration failed.
This patch is applicable to 2.6.39-rc1 only. The problem does not exists
for earlier versions.
Signed-off-by: Alexandre Bounine <alexandre.bounine@idt.com>
Cc: Kumar Gala <galak@kernel.crashing.org>
Cc: Matt Porter <mporter@kernel.crashing.org>
Cc: Li Yang <leoli@freescale.com>
Cc: Thomas Moll <thomas.moll@sysgo.com>
---
arch/powerpc/sysdev/fsl_rio.c | 4 +++-
drivers/rapidio/rio.c | 5 +++--
include/linux/rio.h | 2 +-
3 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_rio.c b/arch/powerpc/sysdev/fsl_rio.c
index 14232d5..4979853 100644
--- a/arch/powerpc/sysdev/fsl_rio.c
+++ b/arch/powerpc/sysdev/fsl_rio.c
@@ -1457,7 +1457,6 @@ int fsl_rio_setup(struct platform_device *dev)
port->ops = ops;
port->priv = priv;
port->phys_efptr = 0x100;
- rio_register_mport(port);
priv->regs_win = ioremap(regs.start, regs.end - regs.start + 1);
rio_regs_win = priv->regs_win;
@@ -1504,6 +1503,9 @@ int fsl_rio_setup(struct platform_device *dev)
dev_info(&dev->dev, "RapidIO Common Transport System size: %d\n",
port->sys_size ? 65536 : 256);
+ if (rio_register_mport(port))
+ goto err;
+
if (port->host_deviceid >= 0)
out_be32(priv->regs_win + RIO_GCCSR, RIO_PORT_GEN_HOST |
RIO_PORT_GEN_MASTER | RIO_PORT_GEN_DISCOVERED);
diff --git a/drivers/rapidio/rio.c b/drivers/rapidio/rio.c
index c29719c..86c9a09 100644
--- a/drivers/rapidio/rio.c
+++ b/drivers/rapidio/rio.c
@@ -1171,16 +1171,17 @@ static int rio_hdid_setup(char *str)
__setup("riohdid=", rio_hdid_setup);
-void rio_register_mport(struct rio_mport *port)
+int rio_register_mport(struct rio_mport *port)
{
if (next_portid >= RIO_MAX_MPORTS) {
pr_err("RIO: reached specified max number of mports\n");
- return;
+ return 1;
}
port->id = next_portid++;
port->host_deviceid = rio_get_hdid(port->id);
list_add_tail(&port->node, &rio_mports);
+ return 0;
}
EXPORT_SYMBOL_GPL(rio_local_get_device_id);
diff --git a/include/linux/rio.h b/include/linux/rio.h
index 4e37a7c..4d50611 100644
--- a/include/linux/rio.h
+++ b/include/linux/rio.h
@@ -396,7 +396,7 @@ union rio_pw_msg {
};
/* Architecture and hardware-specific functions */
-extern void rio_register_mport(struct rio_mport *);
+extern int rio_register_mport(struct rio_mport *);
extern int rio_open_inb_mbox(struct rio_mport *, void *, int, int);
extern void rio_close_inb_mbox(struct rio_mport *, int);
extern int rio_open_outb_mbox(struct rio_mport *, void *, int, int);
--
1.7.3.1
^ permalink raw reply related
* Re: sdhc/mpc8536 - SDCard always detected like read-only
From: Carlos Roberto Moratelli @ 2011-04-06 17:18 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev
In-Reply-To: <20110405234824.GB5611@pengutronix.de>
I will try address the issue in details.
When I insert the SDCard, the same is detect like read-only:
mmcblk0: mmc0:b368 NCard 966 MiB (ro)
mmcblk0:
mmc0: starting CMD18 arg 00000000 flags 000000b5
mmc0: blksz 512 blocks 8 flags 00000200 tsac 100 ms nsac 0
mmc0: CMD12 arg 00000000 flags 0000049d
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000001
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x0000000a
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000001
mmc0: req done (CMD18): 0: 00000900 00000000 00000000 00000000
mmc0: 4096 bytes transferred: 0
mmc0: (CMD12): 0: 00000b00 00000000 00000000 00000000
p1
So, I just can mount the filesystem read-only. I can read the fat32
without problems.
I tested your sugestion. I used sdhci,wp-inverted in my dtb. This
changed the behavior. Now the SDCard is detected without the read-only
flag:
mmcblk0: mmc0:b368 NCard 966 MiB
mmcblk0:
mmc0: starting CMD18 arg 00000000 flags 000000b5
mmc0: blksz 512 blocks 8 flags 00000200 tsac 100 ms nsac 0
mmc0: CMD12 arg 00000000 flags 0000049d
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000001
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x0000000a
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000001
mmc0: req done (CMD18): 0: 00000900 00000000 00000000 00000000
mmc0: 4096 bytes transferred: 0
mmc0: (CMD12): 0: 00000b00 00000000 00000000 00000000
p1
And, I can mount a rw filesystem:
#mount /dev/mmcblock1 /mnt
#cat /proc/mounts
...
/dev/mmcblock1 /mnt vfat
rw,relatime,fmask=0000,dmask=0000,allow_utime=0022,codepage=cp437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro 0 0
...
So, I can copy files to the mounted SDCard. But, When I try to umount I
see the following error mensagens:
#cp /etc/shadow /mnt
#ls /mnt
shadow
#umount /mnt
mmc0: Timeout waiting for hardware interrupt.
mmcblk0: error -110 transferring data, sector 5944, nr 1, card status
0x900
end_request: I/O error, dev mmcblk0, sector 5944
mmc0: Timeout waiting for hardware interrupt.
mmcblk0: error -110 transferring data, sector 5936, nr 1, card status
0x900
end_request: I/O error, dev mmcblk0, sector 5936
Buffer I/O error on device mmcblk0p1, logical block 3888
mmc0: Timeout waiting for hardware interrupt.
mmcblk0: error -110 transferring data, sector 2049, nr 1, card status
0x900
end_request: I/O error, dev mmcblk0, sector 2049
Buffer I/O error on device mmcblk0p1, logical block 1
mmc0: Timeout waiting for hardware interrupt.
mmcblk0: error -110 transferring data, sector 2080, nr 1, card status
0x900
end_request: I/O error, dev mmcblk0, sector 2080
...
I think I need the sdhci,wp-inverted in my dtb. But, it appears that
more something is necessary.
Has someone faced this situation?
Thanks by the help until here.
Regards,
Moratelli
Em Qua, 2011-04-06 às 01:48 +0200, Wolfram Sang escreveu:
> > sdhci@2e000 {
> > compatible = "fsl,mpc8536-esdhc", "fsl,esdhc";
> > reg = <0x2e000 0x1000>;
> > interrupts = <72 0x2>;
> > interrupt-parent = <&mpic>;
> > /* Filled in by U-Boot */
> > clock-frequency = <0>;
> > };
>
> Hmm, I am not too familiar with those SoCs, yet some 83xx needed
>
> sdhci,wp-inverted;
>
> here. Maybe yours, too? Would fit the symptoms.
>
> Regards,
>
> Wolfram
>
^ permalink raw reply
* Re: [PATCH] powerpc/book3e: Fix CPU feature handling on 64-bit e5500
From: Scott Wood @ 2011-04-06 18:02 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <1302092943-10586-1-git-send-email-galak@kernel.crashing.org>
On Wed, 6 Apr 2011 07:29:03 -0500
Kumar Gala <galak@kernel.crashing.org> wrote:
> diff --git a/arch/powerpc/include/asm/cputable.h b/arch/powerpc/include/asm/cputable.h
> index be3cdf9..9028a9e 100644
> --- a/arch/powerpc/include/asm/cputable.h
> +++ b/arch/powerpc/include/asm/cputable.h
> @@ -386,6 +386,10 @@ extern const char *powerpc_base_platform;
> CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_NODSISRALIGN | \
> CPU_FTR_L2CSR | CPU_FTR_LWSYNC | CPU_FTR_NOEXECUTE | \
> CPU_FTR_DBELL)
> +#define CPU_FTRS_E5500 (CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB | \
> + CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_NODSISRALIGN | \
E5500 cannot doze or nap in the way meant by existing code (MSR[WE]).
-Scott
^ permalink raw reply
* Re: known working sata_sil24.c setup on powerpc platforms?
From: Jeff Garzik @ 2011-04-06 18:12 UTC (permalink / raw)
To: Moffett, Kyle D
Cc: Leon Woestenberg, Linux PPC, Tejun Heo, linux-ide@vger.kernel.org
In-Reply-To: <C3A1EF35-6CB6-4674-8B0B-44CD1657FE87@boeing.com>
On 04/06/2011 01:48 PM, Moffett, Kyle D wrote:
> On Apr 06, 2011, at 13:00, Leon Woestenberg wrote:
>> after investigating problems with sata_sil24.c on a freescale p2020
>> soc, I wonder if this driver works on powerpc at all?
>>
>> Does anyone know of a working setup of sata_sil24 on a big endian
>> powerpc system?
>
> Our P2020 boards work fine with legacy PCI interrupts (I think it's a sil3124 over PCI-E); the only deficiency is that MSI does not seem to work.
>
> I know our MSI *does* work in general because we have an Intel 82571EB chipset also attached via PCI-E with working MSI.
We've definitely had issues with sata_sil24 + MSI, also...
sata_sil24 does work on big endian in general.
Jeff
^ permalink raw reply
* Re: known working sata_sil24.c setup on powerpc platforms?
From: Moffett, Kyle D @ 2011-04-06 17:48 UTC (permalink / raw)
To: Leon Woestenberg
Cc: Linux PPC, Tejun Heo, Jeff Garzik, linux-ide@vger.kernel.org
In-Reply-To: <BANLkTimXgi26RHHxyBLoN8YqaDy_PL-hGQ@mail.gmail.com>
On Apr 06, 2011, at 13:00, Leon Woestenberg wrote:
> after investigating problems with sata_sil24.c on a freescale p2020
> soc, I wonder if this driver works on powerpc at all?
>=20
> Does anyone know of a working setup of sata_sil24 on a big endian
> powerpc system?
Our P2020 boards work fine with legacy PCI interrupts (I think it's a sil31=
24 over PCI-E); the only deficiency is that MSI does not seem to work.
I know our MSI *does* work in general because we have an Intel 82571EB chip=
set also attached via PCI-E with working MSI.
Cheers,
Kyle Moffett
^ permalink raw reply
* Re: Combining multiple NAND MTDs
From: Scott Wood @ 2011-04-06 18:47 UTC (permalink / raw)
To: Barry G; +Cc: linuxppc-dev
In-Reply-To: <BANLkTim=oxHcW-HV5Z062r2p2D1nTL8mcQ@mail.gmail.com>
On Tue, 5 Apr 2011 16:35:10 -0700
Barry G <mr.scada@gmail.com> wrote:
> I want to run UBIFS on the combined 2 gigs of flash. Whats the best
> way to do this?
>
> I tried using the mtdconcat stuff and wrote a small driver
> but I am not sure how to populate the mtd_info structure since do_probe_map
> doesn't work with NAND AFAIK.
>
> I see that fsl_elbc_select_chip says "hardware does not seem to support this".
> Not sure if this is related.
It's not related -- it's talking about a single physical chip with
multiple chip selects, not a logical concatenation of multiple separate
devices.
> I see some comments in mtd-physmap.txt about using multiple reg ranges?
> Does this work with NAND?
No.
I don't know of an out-of-the-box configuration step you can take to do
mtdconcat of eLBC NAND, but you could try creating a custom map driver that
glues things together as you wish. Or if you want to be more ambitious,
perhaps a kernel command line (or other dynamic config) option that lets you
glue arbitrary MTD devices together.
-Scott
^ permalink raw reply
* Re: known working sata_sil24.c setup on powerpc platforms?
From: Leon Woestenberg @ 2011-04-06 18:50 UTC (permalink / raw)
To: Jeff Garzik
Cc: Linux PPC, Tejun Heo, Moffett, Kyle D, linux-ide@vger.kernel.org
In-Reply-To: <4D9CAD1F.6060500@garzik.org>
Hello Jeff, all,
On Wed, Apr 6, 2011 at 8:12 PM, Jeff Garzik <jeff@garzik.org> wrote:
> On 04/06/2011 01:48 PM, Moffett, Kyle D wrote:
>> On Apr 06, 2011, at 13:00, Leon Woestenberg wrote:
>>> after investigating problems with sata_sil24.c on a freescale p2020
>>> soc, I wonder if this driver works on powerpc at all?
>>>
>>> Does anyone know of a working setup of sata_sil24 on a big endian
>>> powerpc system?
>>
>> Our P2020 boards work fine with legacy PCI interrupts (I think it's a
>> sil3124 over PCI-E); the only deficiency is that MSI does not seem to work.
>>
>
> We've definitely had issues with sata_sil24 + MSI, also...
>
> sata_sil24 does work on big endian in general.
>
On my system, I have the contrary to Kyle's experience (thanks for sharing).
PowerPC P2020RDB
vanilla 2.6.38
Sil3132 on mini-PCI Express card
Enabling msi gets me further than disabling it (default).
modprobe sata_sil
[ 8.834613] sata_sil24 0001:03:00.0: version 1.1
[ 8.885581] scsi0 : sata_sil24
[ 8.901420] scsi1 : sata_sil24
[ 8.904642] ata1: SATA max UDMA/100 host m128@0xc0000000 port
0xc0004000 irq 16
[ 8.911961] ata2: SATA max UDMA/100 host m128@0xc0000000 port
0xc0006000 irq 16
[ 11.095127] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 0)
[ 14.906986] eth0: no IPv6 routers present
[ 16.099016] ata1.00: qc timeout (cmd 0xec)
[ 16.103128] ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4)
[ 18.299050] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 0)
[ 28.303026] ata1.00: qc timeout (cmd 0xec)
[ 28.307139] ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4)
[ 28.313233] ata1: limiting SATA link speed to 1.5 Gbps
[ 30.523059] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 10)
modprobe sata_sil msi=1
[ 92.984120] sata_sil24 0001:03:00.0: version 1.1
[ 92.988897] irq: irq 0 on host /soc@ffe00000/msi@41600 mapped to
virtual irq 41
[ 92.996229] sata_sil24 0001:03:00.0: Using MSI
[ 93.000675] sata_sil24 0001:03:00.0: enabling bus mastering
[ 93.011628] scsi2 : sata_sil24
[ 93.022463] scsi3 : sata_sil24
[ 93.025695] ata3: SATA max UDMA/100 host m128@0xc0000000 port
0xc0004000 irq 41
[ 93.033023] ata4: SATA max UDMA/100 host m128@0xc0000000 port
0xc0006000 irq 41
[ 95.203029] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 0)
[ 95.209045] ata3: spurious interrupt (slot_stat 0x0 active_tag
-84148995 sactive 0x0)
[ 95.217171] ata3.00: ATA-7: INTEL SSDSA2M080G2GN, 2CV102HD, max UDMA/133
[ 95.223882] ata3.00: 156301488 sectors, multi 1: LBA48 NCQ (depth 31/32)
[ 95.230905] ata3.00: configured for UDMA/100
[ 95.235399] scsi 2:0:0:0: Direct-Access ATA INTEL
SSDSA2M080 2CV1 PQ: 0 ANSI: 5
[ 95.244002] sd 2:0:0:0: Attached scsi generic sg0 type 0
[ 95.252041] sd 2:0:0:0: [sda] 156301488 512-byte logical blocks:
(80.0 GB/74.5 GiB)
[ 95.260219] sd 2:0:0:0: [sda] Write Protect is off
[ 95.265063] sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 95.270500] sd 2:0:0:0: [sda] Write cache: enabled, read cache:
enabled, doesn't support DPO or FUA
[ 95.283779] sda: sda1 sda2 sda3 sda4
[ 95.289482] sd 2:0:0:0: [sda] Attached SCSI disk
[ 95.965897] EXT3-fs: barriers not enabled
[ 95.977279] kjournald starting. Commit interval 5 seconds
[ 95.983296] EXT3-fs (sda2): using internal journal
[ 95.988143] EXT3-fs (sda2): recovery complete
[ 95.992504] EXT3-fs (sda2): mounted filesystem with writeback data mode
[ 96.111587] NTFS volume version 3.1.
[ 97.331005] ata4: SATA link down (SStatus 0 SControl 0)
root@p1020rdb:~# dd if=/dev/sda of=/dev/null bs=4k count=1000
1000+0 records in
1000+0 records out
4096000 bytes (4.1 MB) copied, 0.0315629 s, 130 MB/s
root@p1020rdb:~# dd if=/dev/sda of=/dev/null bs=4k count=10000
10000+0 records in
10000+0 records out
40960000 bytes (41 MB) copied, 0.471802 s, 86.8 MB/s
root@p1020rdb:~# dd if=/dev/sda of=/dev/null bs=4k count=100000
That stalls, I see the controller fail. See dmesg below:
^C^Cdd: reading `/dev/sda': Input/output error
51804+0 records in
51804+0 records out
212189184 bytes (212 MB) copied, 85.6537 s, 2.5 MB/s
dd: closing input file `/dev/sda': Bad file descriptor
[ 92.984120] sata_sil24 0001:03:00.0: version 1.1
[ 92.988897] irq: irq 0 on host /soc@ffe00000/msi@41600 mapped to
virtual irq 41
[ 92.996229] sata_sil24 0001:03:00.0: Using MSI
[ 93.000675] sata_sil24 0001:03:00.0: enabling bus mastering
[ 93.011628] scsi2 : sata_sil24
[ 93.022463] scsi3 : sata_sil24
[ 93.025695] ata3: SATA max UDMA/100 host m128@0xc0000000 port
0xc0004000 irq 41
[ 93.033023] ata4: SATA max UDMA/100 host m128@0xc0000000 port
0xc0006000 irq 41
[ 95.203029] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 0)
[ 95.209045] ata3: spurious interrupt (slot_stat 0x0 active_tag
-84148995 sactive 0x0)
[ 95.217171] ata3.00: ATA-7: INTEL SSDSA2M080G2GN, 2CV102HD, max UDMA/133
[ 95.223882] ata3.00: 156301488 sectors, multi 1: LBA48 NCQ (depth 31/32)
[ 95.230905] ata3.00: configured for UDMA/100
[ 95.235399] scsi 2:0:0:0: Direct-Access ATA INTEL
SSDSA2M080 2CV1 PQ: 0 ANSI: 5
[ 95.244002] sd 2:0:0:0: Attached scsi generic sg0 type 0
[ 95.252041] sd 2:0:0:0: [sda] 156301488 512-byte logical blocks:
(80.0 GB/74.5 GiB)
[ 95.260219] sd 2:0:0:0: [sda] Write Protect is off
[ 95.265063] sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 95.270500] sd 2:0:0:0: [sda] Write cache: enabled, read cache:
enabled, doesn't support DPO or FUA
[ 95.283779] sda: sda1 sda2 sda3 sda4
[ 95.289482] sd 2:0:0:0: [sda] Attached SCSI disk
[ 95.965897] EXT3-fs: barriers not enabled
[ 95.977279] kjournald starting. Commit interval 5 seconds
[ 95.983296] EXT3-fs (sda2): using internal journal
[ 95.988143] EXT3-fs (sda2): recovery complete
[ 95.992504] EXT3-fs (sda2): mounted filesystem with writeback data mode
[ 96.111587] NTFS volume version 3.1.
[ 97.331005] ata4: SATA link down (SStatus 0 SControl 0)
[ 285.891036] ata3.00: exception Emask 0x0 SAct 0x3 SErr 0x0 action 0x6 frozen
[ 285.898099] ata3.00: failed command: READ FPDMA QUEUED
[ 285.903250] ata3.00: cmd 60/00:00:e0:53:06/01:00:00:00:00/40 tag 0
ncq 131072 in
[ 285.903255] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask
0x4 (timeout)
[ 285.918028] ata3.00: status: { DRDY }
[ 285.921689] ata3.00: failed command: READ FPDMA QUEUED
[ 285.926836] ata3.00: cmd 60/00:08:e0:52:06/01:00:00:00:00/40 tag 1
ncq 131072 in
[ 285.926841] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask
0x4 (timeout)
[ 285.941615] ata3.00: status: { DRDY }
[ 285.945281] ata3: hard resetting link
[ 288.055034] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 0)
[ 293.058999] ata3.00: qc timeout (cmd 0xec)
[ 293.063106] ata3.00: failed to IDENTIFY (I/O error, err_mask=0x4)
[ 293.069198] ata3.00: revalidation failed (errno=-5)
[ 293.074077] ata3: hard resetting link
[ 295.259018] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 0)
What can I do next to investigate and help fix this issue?
Regards,
--
Leon
^ permalink raw reply
* Using dmaengine on Freescale P2020 RDB
From: Chuck Ketcham @ 2011-04-06 19:40 UTC (permalink / raw)
To: linuxppc-dev
All,
I have a Freescale P2020 Reference Design Board. I am investigating the possibility of using the dmaengine capability in the 2.6.32.13 kernel to transfer data from memory out onto the PCIe bus. As a first step, I thought I would try the DMA test client (dmatest.ko) to make sure the dmaengine was functioning. I know this doesn't transfer anything over PCIe but only transfers from one memory buffer to another, but I figured I need to get this working first. Anyway I built dmatest.ko and ran it (with insmod), and discovered it didn't do anything. I added some printk's to the kernel to investigate what was going on and I found that all attempts to find a channel within dma_request_channel were unsuccessful. Three of the channels were not used because they were already publicly allocated. One channel was not used because it didn't have DMA_MEMCPY capability.
Here are my questions then:
1. Is the dmaengine the appropriate method to use for transferring data from memory out onto the PCIe bus?
2. If dmaengine is correct, what can I do to free up a channel for my own use?
Thank you.
Chuck
^ 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