* Device tree and external RTC
From: Bruce_Leonard @ 2007-10-03 21:00 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
I'm seriously confused by how things are supposed to work now with device
trees on the PowerPC arch. I'm bringing up our custom HW which is bassed
on the mpc8347e, with an m41t00 RTC hanging off the i2c bus, U-boot is
1.2.0, kernel is 2.6.22. My problem is I can't get the kernel to access
the RTC. It works fine in U-boot, but nothing in the kernel.
Where I get confused is I'm not sure if this is something that the device
tree is supposed to be telling the kernel about or if it's something that
the kernel should probe for. I've turned on everything in Kconfig I can
find for I2C and RTC. Here's what I think are the relavant parts of
.config:
<snip># CONFIG_TCG_TPM is not set
CONFIG_DEVPORT=y
CONFIG_I2C=y
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_CHARDEV=y
#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=y
CONFIG_I2C_ALGOPCF=y
CONFIG_I2C_ALGOPCA=y
#
# I2C Hardware Bus support
#
CONFIG_I2C_ALI1535=y
# CONFIG_I2C_ALI1563 is not set
CONFIG_I2C_ALI15X3=y
CONFIG_I2C_AMD756=y
# CONFIG_I2C_AMD756_S4882 is not set
CONFIG_I2C_AMD8111=y
CONFIG_I2C_I801=y
CONFIG_I2C_I810=y
CONFIG_I2C_PIIX4=y
CONFIG_I2C_MPC=y
CONFIG_I2C_NFORCE2=y
# CONFIG_I2C_OCORES is not set
CONFIG_I2C_PARPORT_LIGHT=y
CONFIG_I2C_PROSAVAGE=y
# CONFIG_I2C_SAVAGE4 is not set
CONFIG_I2C_SIMTEC=y
CONFIG_I2C_SIS5595=y
CONFIG_I2C_SIS630=y
CONFIG_I2C_SIS96X=y
# CONFIG_I2C_STUB is not set
# CONFIG_I2C_VIA is not set
CONFIG_I2C_VIAPRO=y
CONFIG_I2C_VOODOO3=y
#
# Miscellaneous I2C Chip support
#
# CONFIG_SENSORS_DS1337 is not set
# CONFIG_SENSORS_DS1374 is not set
# CONFIG_SENSORS_EEPROM is not set
# CONFIG_SENSORS_PCF8574 is not set
# CONFIG_SENSORS_PCA9539 is not set
# CONFIG_SENSORS_PCF8591 is not set
CONFIG_SENSORS_M41T00=y
# CONFIG_SENSORS_MAX6875 is not set
CONFIG_I2C_DEBUG_CORE=y
CONFIG_I2C_DEBUG_ALGO=y
CONFIG_I2C_DEBUG_BUS=y
CONFIG_I2C_DEBUG_CHIP=y
<snip>
#
# Real Time Clock
#
CONFIG_RTC_LIB=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
CONFIG_RTC_DEBUG=y
#
# RTC interfaces
#
CONFIG_RTC_INTF_SYSFS=y
CONFIG_RTC_INTF_PROC=y
CONFIG_RTC_INTF_DEV=y
# CONFIG_RTC_INTF_DEV_UIE_EMUL is not set
# CONFIG_RTC_DRV_TEST is not set
#
# I2C RTC drivers
#
CONFIG_RTC_DRV_DS1307=y
# CONFIG_RTC_DRV_DS1672 is not set
# CONFIG_RTC_DRV_MAX6900 is not set
# CONFIG_RTC_DRV_RS5C372 is not set
# CONFIG_RTC_DRV_ISL1208 is not set
# CONFIG_RTC_DRV_X1205 is not set
# CONFIG_RTC_DRV_PCF8563 is not set
# CONFIG_RTC_DRV_PCF8583 is not set
#
# SPI RTC drivers
#
#
# Platform RTC drivers
#
# CONFIG_RTC_DRV_DS1553 is not set
# CONFIG_RTC_DRV_DS1742 is not set
# CONFIG_RTC_DRV_M48T86 is not set
# CONFIG_RTC_DRV_V3020 is not set
#
# on-CPU RTC drivers
#
However, I get the following error when I run hwclock --debug:
hwclock from util-linux-2.12r
hwclock: Open of /dev/rtc failed, errno=19: No such device. (note that
the device is present with a major of 10 and a minor of 135)
No usable clock interface found.
Cannot access the Hardware Clock via any known method.
When I dump out ppc_md, all the RTC functions (i.e., get_rtc_time,
read_rtc_val, etc.) are all NULL.
I've searched through all the device tree files that come with the kernel
and I can't find any that explicitly show an external device as a child
node to a SoC I2C controller but it sure seems to me that the purpose of
the device tree is to describe to the kernel all the hardware in the
system. Therefore it seems to me that there should be something like the
following in the device tree:
<snip>
i2c@3000 {
device_type = "i2c";
compatible = "fsl-i2c";
reg = <3000 100>;
interrupts = <e 8>;
interrupt-parent = < &ipic >;
dfsrr;
rtc@54 {
device_type = "rtc";
something;
something;
something;
}
}
<snip>
I've googled for "device tree & rtc" and various other things that haven't
poped out anything that really gives me any direction and
booting_without_of.txt doesn't really help me very much because I think
I'm just too dumb to understand it :-\. (Took me two days to understand
the ranges filed for the PCI node :( ).
So, long winded way to get to it: Am I missing something in Kconfig for
the kernel or am I missing something in the device tree? Also, is there
any place where things like the "dfsrr" attribute in the above device tree
are described/defined? I have no idea what that's supposed to mean and
conversly I don't know what things are acceptable. For example, if I need
a RTC node in my device tree, what are the required attributes and what
should the be set to? Any direction as to where I should be looking to
figure this sort of stuff out is greatly appreciated.
Sorry for the length of this post and thanks for any direction that can be
provided.
Bruce
^ permalink raw reply
* Re: [PATCH 2 6/7] Uartlite: Add of-platform-bus binding
From: Benjamin Herrenschmidt @ 2007-10-03 21:21 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40710030739k13e05571l7063aa635a8727dc@mail.gmail.com>
On Wed, 2007-10-03 at 08:39 -0600, Grant Likely wrote:
> Right, okay. Looking at platform_device_add(), the default parent is
> platform_bus, but it can be overridden. of_platform_bus devices get
> the hierarchy of the device tree by default. So in the platform bus
> case, the constructor would need to explicitly set the parent device?
> Correct?
>
> Also, how do you see the constructor code getting executed? Called
> explicitly from the platform code, or some form of auto binding? I
> look at fsl_soc.c and I shudder as each constructor does a pass of the
> whole tree looking for compatible nodes.
My idea was to have some platform code at boot walk the DT and call the
constructors on the way, passing them the parent. Constructors return a
struct device * so it would keep track of who is where.
Drivers or platform code can then register constructors along with of
match tables.
Ben.
^ permalink raw reply
* Re: Stdout console clogging => 300ms blocked
From: Hollis Blanchard @ 2007-10-03 20:49 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <8D433CD511BE4646B47F8B31C900818ECB97AF@kndmex01.barco.com>
On Tue, 02 Oct 2007 09:41:28 +0200, Willaert, Bernard wrote:
> System details:
> Freescale MPC8347@200MHz
> Kernel 2.6.18
>
> Problem:
> When we log debug output via the serial console on a multithreaded
> application, the console throughput may get clogged and then we
> experience a >300ms deadlock.
>
> Quick and dirty test program: threadtest.c:
> //----------------------------------------------------------------------
> -------------------------
> #include <pthread.h>
> #include <stdio.h>
> #include <sys/time.h>
>
> #define THREAD_DELAY 1000
>
> void* thread_1(void* unused)
> {
> while (1)
> {
> usleep(THREAD_DELAY);
> fprintf(stdout," <----- thread 1\n");
> }
> return NULL;
> }
>
> void* thread_2(void* unused)
> {
> static long ts_old;
> long ts;
> struct timeval tv;
>
> while (1)
> {
> usleep(THREAD_DELAY);
> fprintf(stdout," <----- thread 2\n");
>
> gettimeofday (&tv, NULL);
> ts = (tv.tv_sec * 1000L) + (tv.tv_usec / 1000L);
> if ((ts - ts_old) > 100)
> {
> fprintf(stdout, "!!!!!!!!!!! thread2 interval
> timeout = %d ms\n",(int)(ts - ts_old));
> }
> ts_old = ts;
> }
> return NULL;
>
> }
>
>
>
> int main()
> {
> pthread_t pthread_id_1, pthread_id_2;
>
> pthread_create(&pthread_id_1,NULL,&thread_1,NULL);
> pthread_create(&pthread_id_2,NULL,&thread_2,NULL);
> while (1)
> {
> }
> return 0;
>
> }
>
> //----------------------------------------------------------------------
> -------------------------
>
> Build command on our platform:
> powerpc-linux-uclibc-gcc threadtest.c -lpthread -o threadtest
> Execute: ./threadtest > /dev/console &
>
> Uboot settings for the serial console:
> consoledev=ttyS0
> baudrate=115200
> stdin=serial
> stdout=serial
> stderr=serial
> boot_go=setenv bootargs console=$consoledev,$baudrate $args_rtc
> $args_mtd $args_nfs $args_debug;bootm $addr_kernel $addr_root $addr_dtb
>
>
> Expected output [snippet] on the console:
> .... /\ ........
> <----- thread 1
> <----- thread 2
> <----- thread 1
> <----- thread 2
> <----- thread 1
> <----- thread 2
> <----- thread 1
> <----- thread 2
> <----- thread 1
> <----- thread 2
> <----- thread 1
> .... /\ ........
>
> Real output on the console:
>
> .... /\ ........
> <----- thread 1
> <----- thread 2
> <----- thread 1
> <----- thread 2
> <----- thread 1
> <----- thread 2
> !!!!!!!!!!! thread2 interval timeout = 335 ms
> <----- thread 1
> <----- thread 2
> <----- thread 1
> <----- thread 2
> <----- thread 1
> .... /\ ........
>
> This timeout shows up around every second and has always about the same
> value of 335 ms.
> Can somebody reproduce this behaviour ( the console speed and/or thread
> interval may have to be tweaked to clog the serial output) ?
> Thank you in advance for your help.
Could you not post HTML please? Thanks.
"Deadlock" means dead due to incorrect locking. Instead, you seem to be
talking about a momentary pause. :)
Are you saying that the problem does not occur when you do not use
/dev/console? What about /dev/ttyS0, or whatever your serial port device
is?
You're certain that this isn't simply a result of multitasking?
--
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply
* RE: [PATCH] PPC 85xx failure with odd memory sizes and CONFIG_HIGHMEM
From: Rune Torgersen @ 2007-10-03 21:45 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
In-Reply-To: <0B763FCF-9EFD-48E5-B2D9-53EAB0396522@kernel.crashing.org>
> From: Kumar Gala
> The code would have to change to allow for 1G of lowmem.
> Max lowmem with KERNELBASE @ 0xc000_0000 is 768M.
Which is why I asked. On 82xx it is supported without a codechange by
setting KERNELBASE to 0xa000_0000 in Kconfig menu (and also changing
start of virtual mem, also done by config option).
^ permalink raw reply
* Re: [PATCH 0/5] Add MPC8610 HPCD Base Port
From: Kumar Gala @ 2007-10-03 22:09 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1191442145.21463.73.camel@ld0161-tx32>
On Oct 3, 2007, at 3:09 PM, Jon Loeliger wrote:
> Kumar and Paul,
>
> These five patches add the base port for the newly
> introduced MPC8610 HPCD reference board. We would
> like to see these added to 2.6.24 if possible!
>
> Thanks,
> jdl
>
>
> arch/powerpc/boot/dts/mpc8610_hpcd.dts | 191 +++++
> arch/powerpc/configs/mpc8610_hpcd_defconfig | 1023 ++++++++++++++++
> +++++++++++
> arch/powerpc/platforms/86xx/Kconfig | 13 +
> arch/powerpc/platforms/86xx/Makefile | 1 +
> arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 267 +++++++
> arch/powerpc/sysdev/fsl_pci.c | 1 +
> include/linux/pci_ids.h | 1 +
> 7 files changed, 1497 insertions(+), 0 deletions(-)
applied.
- k
^ permalink raw reply
* Re: [PATCH] fsl_spi_init: Support non-QE processors
From: Kumar Gala @ 2007-10-03 22:11 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: linuxppc-dev@ozlabs.org list
In-Reply-To: <fa686aa40710031117x528e5afarb059d8f1c9eb3e7f@mail.gmail.com>
On Oct 3, 2007, at 1:17 PM, Grant Likely wrote:
> On 10/3/07, Peter Korsgaard <jacmet@sunsite.dk> wrote:
>>>>>>> "Grant" == Grant Likely <grant.likely@secretlab.ca> writes:
>>
>> Hi,
>>
>> Grant> Why not just:
>>
>> Grant> np = of_find_node_by_type(NULL, "qe");
>> Grant> + if (!np)
>> Grant> + np = of_find_node_by_type(NULL, "soc");
>> Grant> if (!np)
>> Grant> return -ENODEV;
>>
>> My first iteration did it like that, but then you don't get a -ENODEV
>> if the node is missing (and you'll end up using the wrong clock) and
>> it doesn't support processors with SPI on and off QE (if that
>> exists/will ever exist).
>
> Okay, but you should at least be able confine your determination of
> which sysclk value to use to one part of the function. Otherwise, it
> looks good.
Peter, can you respin this w/Grant's modification. I've grabbed the
other patches and applied them. waiting on this one.
- k
^ permalink raw reply
* Re: [PATCH v4] qe: miscellaneous code improvements and fixes to the QE library
From: Kumar Gala @ 2007-10-03 22:41 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, Stephen Hemminger, netdev
In-Reply-To: <4703D8B9.5080006@freescale.com>
On Oct 3, 2007, at 1:00 PM, Timur Tabi wrote:
> Stephen Hemminger wrote:
>
>> Separate the changes into individual patches to allow for better
>> comment/review
>> and bisection in case of regression.
>
> That would be too difficult. Some of the changes are single lines,
> and this patch has already been approved -- I just cross-posted to
> netdev because I made a few ucc_geth changes that can't be
> docoupled from the powerpc changes. A series of 18 patches would
> just be convoluted.
Normally I would agree, but at this point I'm not going to gripe too
much about it.
- k
^ permalink raw reply
* Re: [PATCH] PPC 85xx failure with odd memory sizes and CONFIG_HIGHMEM
From: Kumar Gala @ 2007-10-03 22:48 UTC (permalink / raw)
To: Rune Torgersen; +Cc: linuxppc-embedded
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B037591FD@ismail.innsys.innovsys.com>
On Oct 3, 2007, at 4:45 PM, Rune Torgersen wrote:
>> From: Kumar Gala
>> The code would have to change to allow for 1G of lowmem.
>> Max lowmem with KERNELBASE @ 0xc000_0000 is 768M.
>
> Which is why I asked. On 82xx it is supported without a codechange by
> setting KERNELBASE to 0xa000_0000 in Kconfig menu (and also changing
> start of virtual mem, also done by config option).
we could make this work. Its just no one's griped about needing it
to date.
Its a bit of testing to make sure we respect the kernel config
changes and a slight be of code to handle using up to 1G TLB sizes on
e500v2 or greater.
- k
^ permalink raw reply
* Re: Device tree and external RTC
From: Bruce_Leonard @ 2007-10-03 23:15 UTC (permalink / raw)
To: Bruce_Leonard; +Cc: linuxppc-embedded
In-Reply-To: <OFFFD4BE8F.17F6E427-ON88257369.006D8651-88257369.00736D96@selinc.com>
linuxppc-embedded-bounces+brucle=selinc.com@ozlabs.org wrote on 10/03/2007
02:00:49 PM:
> Hi all,
>
> I'm seriously confused by how things are supposed to work now with
device
> trees on the PowerPC arch. I'm bringing up our custom HW which is
bassed
<HUGE snip>
Follow up:
Okay, I figured out that I was indeed reading the clock (should have been
using date command rather than hwclock command), so sorry for the noise.
So what is is that hwclock is trying to do that it's unhappy about?
I still think I've got a valid question about the device tree. Isn't the
purpose of the device tree to completely describe the HW to the kernel?
Shouldn't I be able to add a child node to the i2c node describing the
M41T00 RTC and have the kernel figure out that there's an RTC hanging off
the I2C bus? Or am I completely off base here?
Bruce
^ permalink raw reply
* Re: Device tree and external RTC
From: Jon Smirl @ 2007-10-03 23:33 UTC (permalink / raw)
To: Bruce_Leonard@selinc.com; +Cc: linuxppc-embedded
In-Reply-To: <OF5A3A8901.AAC62E29-ON88257369.007F3E0B-88257369.007FC5D0@selinc.com>
On 10/3/07, Bruce_Leonard@selinc.com <Bruce_Leonard@selinc.com> wrote:
> I still think I've got a valid question about the device tree. Isn't the
> purpose of the device tree to completely describe the HW to the kernel?
> Shouldn't I be able to add a child node to the i2c node describing the
> M41T00 RTC and have the kernel figure out that there's an RTC hanging off
> the I2C bus? Or am I completely off base here?
I am having the same question about audio codecs. ALSA soc support is
designed to automatically load the right drivers depending on the
hardware in the device. Doesn't the device tree need to include the
codec chips? These chips are hooked up with various combinations of
i2s, ac97 and i2c.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* linux ethernet problem
From: jxnuxdy @ 2007-10-04 0:59 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <9e4733910710031633v3bb409c9j32b345e12396c1b0@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 313 bytes --]
Hi, I use the 440epx CPU and bcm5241 PHY in my system, the ehternet works fine in u-boot, however I can't use the ethernet in linux if I didn't active the ehernet in u-boot(such as 'ping'... or 'tftp'...). Is there anyone even encounter such problem? is the issue due to my u-boot or linux? ,Regards- Denny
[-- Attachment #2: Type: text/html, Size: 805 bytes --]
^ permalink raw reply
* Re: [PATCH] SPI: Use fsl_spi instead of mpc83xx_spi
From: David Gibson @ 2007-10-04 1:54 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: linuxppc-dev
In-Reply-To: <878x6kxk62.fsf@macbook.be.48ers.dk>
On Wed, Oct 03, 2007 at 06:00:37PM +0200, Peter Korsgaard wrote:
> >>>>> "Grant" == Grant Likely <grant.likely@secretlab.ca> writes:
>
> Hi,
>
> >> - compatible = "mpc83xx_spi";
> >> + compatible = "fsl_spi";
>
> Grant> Compatible is a list property; this might be more appropriate:
>
> Grant> compatible = "fsl,mpc8313_spi", "fsl_spi";
>
> Fine by me, I'm just following booting-without-of.txt.
Yeah, some of the older bits of booting-without-of.txt are a bit
crufty. There should certainly be a specific compatible value in the
list as well as the general "fsl_spi" one.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* [PATCH] [POWERPC] Remove some section mismatch warnings
From: Stephen Rothwell @ 2007-10-04 2:00 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev
>From g5_defconfig:
WARNING: vmlinux.o(.text+0x2ff5c): Section mismatch: reference to .init.text:.pmac_find_ide_boot (between '.note_bootable_part' and '.note_scsi_host')
>From holly_defconfig:
WARNING: vmlinux.o(.text+0x164fe): Section mismatch: reference to .init.data:boot_command_line (between 'note_bootable_part' and 'find_via_pmu')
WARNING: vmlinux.o(.text+0x16506): Section mismatch: reference to .init.data:boot_command_line (between 'note_bootable_part' and 'find_via_pmu')
>From linkstation_defconfig:
WARNING: vmlinux.o(.text+0x158fe): Section mismatch: reference to .init.data:boot_command_line (between 'note_bootable_part' and 'find_via_pmu')
WARNING: vmlinux.o(.text+0x15906): Section mismatch: reference to .init.data:boot_command_line (between 'note_bootable_part' and 'find_via_pmu')
>From mpc7448_hpc2_defconfig:
WARNING: vmlinux.o(.text+0x1583e): Section mismatch: reference to .init.data:boot_command_line (between 'note_bootable_part' and 'find_via_pmu')
WARNING: vmlinux.o(.text+0x15846): Section mismatch: reference to .init.data:boot_command_line (between 'note_bootable_part' and 'find_via_pmu')
>From pmac32_defconfig:
WARNING: vmlinux.o(.text+0x154ca): Section mismatch: reference to .init.data:boot_command_line (between 'note_bootable_part' and 'note_scsi_host')
WARNING: vmlinux.o(.text+0x154d2): Section mismatch: reference to .init.data:boot_command_line (between 'note_bootable_part' and 'note_scsi_host')
WARNING: vmlinux.o(.text+0x1553c): Section mismatch: reference to .init.text:pmac_find_ide_boot (between 'note_bootable_part' and 'note_scsi_host')
>From ppc64_defconfig:
WARNING: vmlinux.o(.text+0x3acdc): Section mismatch: reference to .init.text:.pmac_find_ide_boot (between '.note_bootable_part' and '.note_scsi_host')
>From prpmc2800_defconfig:
WARNING: vmlinux.o(.text+0x1611e): Section mismatch: reference to .init.data:boot_command_line (between 'note_bootable_part' and 'find_via_pmu')
WARNING: vmlinux.o(.text+0x16126): Section mismatch: reference to .init.data:boot_command_line (between 'note_bootable_part' and 'find_via_pmu')
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/platforms/powermac/setup.c | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --git a/arch/powerpc/platforms/powermac/setup.c b/arch/powerpc/platforms/powermac/setup.c
index 7ccb923..840f5b4 100644
--- a/arch/powerpc/platforms/powermac/setup.c
+++ b/arch/powerpc/platforms/powermac/setup.c
@@ -466,8 +466,13 @@ static int pmac_late_init(void)
late_initcall(pmac_late_init);
-/* can't be __init - can be called whenever a disk is first accessed */
-void note_bootable_part(dev_t dev, int part, int goodness)
+/*
+ * This is __init_refok because we check for "initializing" before
+ * touching any of the __init sensitive things and "initializing"
+ * will be false after __init time. This can't be __init because it
+ * can be called whenever a disk is first accessed.
+ */
+void __init_refok note_bootable_part(dev_t dev, int part, int goodness)
{
static int found_boot = 0;
char *p;
--
1.5.3.3
^ permalink raw reply related
* Re: [PATCH 2/5] Add initial MPC8610 HPCD Platform files.
From: Stephen Rothwell @ 2007-10-04 3:41 UTC (permalink / raw)
To: Jon Loeliger, Xianghua Xiao; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1191442173.21463.77.camel@ld0161-tx32>
[-- Attachment #1: Type: text/plain, Size: 669 bytes --]
On Wed, 03 Oct 2007 15:09:33 -0500 Jon Loeliger <jdl@freescale.com> wrote:
>
> +++ b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
> +#include <linux/stddef.h>
> +#include <linux/kernel.h>
> +#include <linux/pci.h>
> +#include <linux/kdev_t.h>
> +#include <linux/delay.h>
> +#include <linux/seq_file.h>
> +
> +#include <asm/system.h>
> +#include <asm/time.h>
> +#include <asm/machdep.h>
> +#include <asm/pci-bridge.h>
> +#include <asm/mpc86xx.h>
> +#include <asm/prom.h>
You should include linux/of.h as well to use the of_ accessor functions.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] Remove unused old code from powermac setup code
From: Paul Mackerras @ 2007-10-04 3:47 UTC (permalink / raw)
To: linuxppc-dev
Since bootdevice never gets initialized, it's always NULL, and hence a
whole pile of code in arch/powerpc/platforms/setup.c never gets used.
(This was the code that originally was there so that the automatic
root partition selection mechanism would prefer a rootish-looking
partition on the device that OF loaded the kernel from over a similar
partition on other devices.)
This removes the unused code.
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
diff --git a/arch/powerpc/platforms/powermac/setup.c b/arch/powerpc/platforms/powermac/setup.c
index 7ccb923..c59a508 100644
--- a/arch/powerpc/platforms/powermac/setup.c
+++ b/arch/powerpc/platforms/powermac/setup.c
@@ -387,69 +387,13 @@ static void __init pmac_setup_arch(void)
#endif /* CONFIG_ADB */
}
-char *bootpath;
-char *bootdevice;
-void *boot_host;
-int boot_target;
-int boot_part;
-static dev_t boot_dev;
-
#ifdef CONFIG_SCSI
void note_scsi_host(struct device_node *node, void *host)
{
- int l;
- char *p;
-
- l = strlen(node->full_name);
- if (bootpath != NULL && bootdevice != NULL
- && strncmp(node->full_name, bootdevice, l) == 0
- && (bootdevice[l] == '/' || bootdevice[l] == 0)) {
- boot_host = host;
- /*
- * There's a bug in OF 1.0.5. (Why am I not surprised.)
- * If you pass a path like scsi/sd@1:0 to canon, it returns
- * something like /bandit@F2000000/gc@10/53c94@10000/sd@0,0
- * That is, the scsi target number doesn't get preserved.
- * So we pick the target number out of bootpath and use that.
- */
- p = strstr(bootpath, "/sd@");
- if (p != NULL) {
- p += 4;
- boot_target = simple_strtoul(p, NULL, 10);
- p = strchr(p, ':');
- if (p != NULL)
- boot_part = simple_strtoul(p + 1, NULL, 10);
- }
- }
}
EXPORT_SYMBOL(note_scsi_host);
#endif
-#if defined(CONFIG_BLK_DEV_IDE) && defined(CONFIG_BLK_DEV_IDE_PMAC)
-static dev_t __init find_ide_boot(void)
-{
- char *p;
- int n;
- dev_t __init pmac_find_ide_boot(char *bootdevice, int n);
-
- if (bootdevice == NULL)
- return 0;
- p = strrchr(bootdevice, '/');
- if (p == NULL)
- return 0;
- n = p - bootdevice;
-
- return pmac_find_ide_boot(bootdevice, n);
-}
-#endif /* CONFIG_BLK_DEV_IDE && CONFIG_BLK_DEV_IDE_PMAC */
-
-static void __init find_boot_device(void)
-{
-#if defined(CONFIG_BLK_DEV_IDE) && defined(CONFIG_BLK_DEV_IDE_PMAC)
- boot_dev = find_ide_boot();
-#endif
-}
-
static int initializing = 1;
static int pmac_late_init(void)
@@ -469,7 +413,6 @@ late_initcall(pmac_late_init);
/* can't be __init - can be called whenever a disk is first accessed */
void note_bootable_part(dev_t dev, int part, int goodness)
{
- static int found_boot = 0;
char *p;
if (!initializing)
@@ -481,15 +424,8 @@ void note_bootable_part(dev_t dev, int part, int goodness)
if (p != NULL && (p == boot_command_line || p[-1] == ' '))
return;
- if (!found_boot) {
- find_boot_device();
- found_boot = 1;
- }
- if (!boot_dev || dev == boot_dev) {
- ROOT_DEV = dev + part;
- boot_dev = 0;
- current_root_goodness = goodness;
- }
+ ROOT_DEV = dev + part;
+ current_root_goodness = goodness;
}
#ifdef CONFIG_ADB_CUDA
^ permalink raw reply related
* Re: [PATCH] Remove unused old code from powermac setup code
From: Benjamin Herrenschmidt @ 2007-10-04 3:56 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18180.25146.321019.568200@cargo.ozlabs.ibm.com>
On Thu, 2007-10-04 at 13:47 +1000, Paul Mackerras wrote:
> Since bootdevice never gets initialized, it's always NULL, and hence a
> whole pile of code in arch/powerpc/platforms/setup.c never gets used.
> (This was the code that originally was there so that the automatic
> root partition selection mechanism would prefer a rootish-looking
> partition on the device that OF loaded the kernel from over a similar
> partition on other devices.)
>
> This removes the unused code.
>
> Signed-off-by: Paul Mackerras <paulus@samba.org>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
^ permalink raw reply
* Re: [PATCH] fsl_spi_init: Support non-QE processors
From: Stephen Rothwell @ 2007-10-04 4:01 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: linuxppc-dev
In-Reply-To: <87lkakxky1.fsf@macbook.be.48ers.dk>
[-- Attachment #1: Type: text/plain, Size: 453 bytes --]
On Wed, 03 Oct 2007 17:43:50 +0200 Peter Korsgaard <jacmet@sunsite.dk> wrote:
>
> @@ -1220,14 +1220,17 @@ int __init fsl_spi_init(struct spi_board_info *board_infos,
> {
> struct device_node *np;
> unsigned int i;
> - const u32 *sysclk;
> + const u32 *qe_sysclk = 0, *soc_sysclk = 0;
Please use NULL when referring to pointers.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] Bootwrapper: Enable debug info on boot wrapper
From: Grant Likely @ 2007-10-04 4:05 UTC (permalink / raw)
To: linuxppc-dev, david, paulus
From: Grant Likely <grant.likely@secretlab.ca>
Add '-g' to BOOTCFLAGS if CONFIG_DEBUG_INFO is set.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
arch/powerpc/boot/Makefile | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index cf80db3..9dfe79b 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -25,6 +25,10 @@ BOOTCFLAGS := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
-isystem $(shell $(CROSS32CC) -print-file-name=include)
BOOTAFLAGS := -D__ASSEMBLY__ $(BOOTCFLAGS) -traditional -nostdinc
+ifdef CONFIG_DEBUG_INFO
+BOOTCFLAGS += -g
+endif
+
ifeq ($(call cc-option-yn, -fstack-protector),y)
BOOTCFLAGS += -fno-stack-protector
endif
^ permalink raw reply related
* [PATCH 2/3] Sysace: sparse fixes
From: Grant Likely @ 2007-10-04 4:13 UTC (permalink / raw)
To: jens.axboe, linux-kernel, linuxppc-dev
In-Reply-To: <20071004041114.20868.34605.stgit@trillian.cg.shawcable.net>
From: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
drivers/block/xsysace.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/block/xsysace.c b/drivers/block/xsysace.c
index 3847464..5b73471 100644
--- a/drivers/block/xsysace.c
+++ b/drivers/block/xsysace.c
@@ -195,7 +195,7 @@ struct ace_device {
/* Details of hardware device */
unsigned long physaddr;
- void *baseaddr;
+ void __iomem *baseaddr;
int irq;
int bus_width; /* 0 := 8 bit; 1 := 16 bit */
struct ace_reg_ops *reg_ops;
@@ -227,20 +227,20 @@ struct ace_reg_ops {
/* 8 Bit bus width */
static u16 ace_in_8(struct ace_device *ace, int reg)
{
- void *r = ace->baseaddr + reg;
+ void __iomem *r = ace->baseaddr + reg;
return in_8(r) | (in_8(r + 1) << 8);
}
static void ace_out_8(struct ace_device *ace, int reg, u16 val)
{
- void *r = ace->baseaddr + reg;
+ void __iomem *r = ace->baseaddr + reg;
out_8(r, val);
out_8(r + 1, val >> 8);
}
static void ace_datain_8(struct ace_device *ace)
{
- void *r = ace->baseaddr + 0x40;
+ void __iomem *r = ace->baseaddr + 0x40;
u8 *dst = ace->data_ptr;
int i = ACE_FIFO_SIZE;
while (i--)
@@ -250,7 +250,7 @@ static void ace_datain_8(struct ace_device *ace)
static void ace_dataout_8(struct ace_device *ace)
{
- void *r = ace->baseaddr + 0x40;
+ void __iomem *r = ace->baseaddr + 0x40;
u8 *src = ace->data_ptr;
int i = ACE_FIFO_SIZE;
while (i--)
^ permalink raw reply related
* [PATCH 1/3] Sysace: Minor coding convention fixup
From: Grant Likely @ 2007-10-04 4:13 UTC (permalink / raw)
To: jens.axboe, linux-kernel, linuxppc-dev
In-Reply-To: <20071004041114.20868.34605.stgit@trillian.cg.shawcable.net>
From: Grant Likely <grant.likely@secretlab.ca>
Put function call and return code test on separate lines.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
drivers/block/xsysace.c | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/block/xsysace.c b/drivers/block/xsysace.c
index 3ea172b..3847464 100644
--- a/drivers/block/xsysace.c
+++ b/drivers/block/xsysace.c
@@ -1091,7 +1091,8 @@ ace_alloc(struct device *dev, int id, unsigned long physaddr,
ace->bus_width = bus_width;
/* Call the setup code */
- if ((rc = ace_setup(ace)) != 0)
+ rc = ace_setup(ace);
+ if (rc)
goto err_setup;
dev_set_drvdata(dev, ace);
@@ -1253,11 +1254,13 @@ static int __init ace_init(void)
goto err_blk;
}
- if ((rc = ace_of_register()) != 0)
+ rc = ace_of_register();
+ if (rc)
goto err_of;
pr_debug("xsysace: registering platform binding\n");
- if ((rc = platform_driver_register(&ace_platform_driver)) != 0)
+ rc = platform_driver_register(&ace_platform_driver);
+ if (rc)
goto err_plat;
pr_info("Xilinx SystemACE device driver, major=%i\n", ace_major);
^ permalink raw reply related
* [PATCH 3/3] Sysace: Don't enable IRQ until after interrupt handler is registered
From: Grant Likely @ 2007-10-04 4:13 UTC (permalink / raw)
To: jens.axboe, linux-kernel, linuxppc-dev
In-Reply-To: <20071004041114.20868.34605.stgit@trillian.cg.shawcable.net>
From: Grant Likely <grant.likely@secretlab.ca>
The previous patch to move the interrupt handler registration moved it
below enabling interrupts which could be a problem if the device is on
a shared interrupt line. This patch fixes the order.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
drivers/block/xsysace.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/block/xsysace.c b/drivers/block/xsysace.c
index 5b73471..9e7652d 100644
--- a/drivers/block/xsysace.c
+++ b/drivers/block/xsysace.c
@@ -1005,11 +1005,6 @@ static int __devinit ace_setup(struct ace_device *ace)
ace_out(ace, ACE_CTRL, ACE_CTRL_FORCECFGMODE |
ACE_CTRL_DATABUFRDYIRQ | ACE_CTRL_ERRORIRQ);
- /* Enable interrupts */
- val = ace_in(ace, ACE_CTRL);
- val |= ACE_CTRL_DATABUFRDYIRQ | ACE_CTRL_ERRORIRQ;
- ace_out(ace, ACE_CTRL, val);
-
/* Now we can hook up the irq handler */
if (ace->irq != NO_IRQ) {
rc = request_irq(ace->irq, ace_interrupt, 0, "systemace", ace);
@@ -1020,6 +1015,11 @@ static int __devinit ace_setup(struct ace_device *ace)
}
}
+ /* Enable interrupts */
+ val = ace_in(ace, ACE_CTRL);
+ val |= ACE_CTRL_DATABUFRDYIRQ | ACE_CTRL_ERRORIRQ;
+ ace_out(ace, ACE_CTRL, val);
+
/* Print the identification */
dev_info(ace->dev, "Xilinx SystemACE revision %i.%i.%i\n",
(version >> 12) & 0xf, (version >> 8) & 0x0f, version & 0xff);
^ permalink raw reply related
* [PATCH 0/3] Fixups to SystemACE driver
From: Grant Likely @ 2007-10-04 4:13 UTC (permalink / raw)
To: jens.axboe, linux-kernel, linuxppc-dev
Jens,
Here are some more Sysace patches based on comments received on the
first series and a run through sparse. Can you please queue them up
for 2.6.24?
Thanks,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH] Fix performance monitor on machines with logical PVR
From: Paul Mackerras @ 2007-10-04 4:18 UTC (permalink / raw)
To: linuxppc-dev
Some IBM machines supply a "logical" PVR (processor version register)
value in the device tree in the cpu nodes rather than the real PVR.
This is used for instance to indicate that the processors in a POWER6
partition have been configured by the hypervisor to run in POWER5+
mode rather than POWER6 mode. To cope with this, we call identify_cpu
a second time with the logical PVR value (the first call is with the
real PVR value in the very early setup code).
However, POWER5+ machines can also supply a logical PVR value, and use
the same value (the value that indicates a v2.04 architecture
compliant processor). This causes problems for code that uses the
performance monitor (such as oprofile), because the PMU registers are
different in POWER6 (even in POWER5+ mode) from the real POWER5+.
This change works around this problem by taking out the PMU
information from the cputable entries for the logical PVR values, and
changing identify_cpu so that the second call to it won't overwrite
the PMU information that was established by the first call (the one
with the real PVR), but does update the other fields.
So that we can create a mixed cputable entry, we now make cur_cpu_spec
point to a single static struct cpu_spec, and copy stuff from
cpu_specs[i] into it. This has the side-effect that we can now make
cpu_specs[] be initdata.
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index b03a442..8662cf0 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -71,7 +71,7 @@ extern void __restore_cpu_ppc970(void);
#define COMMON_USER_BOOKE (PPC_FEATURE_32 | PPC_FEATURE_HAS_MMU | \
PPC_FEATURE_BOOKE)
-static struct cpu_spec cpu_specs[] = {
+static struct cpu_spec __initdata cpu_specs[] = {
#ifdef CONFIG_PPC64
{ /* Power3 */
.pvr_mask = 0xffff0000,
@@ -327,14 +327,6 @@ static struct cpu_spec cpu_specs[] = {
.cpu_user_features = COMMON_USER_POWER5_PLUS,
.icache_bsize = 128,
.dcache_bsize = 128,
- .num_pmcs = 6,
- .pmc_type = PPC_PMC_IBM,
- .oprofile_cpu_type = "ppc64/power6",
- .oprofile_type = PPC_OPROFILE_POWER4,
- .oprofile_mmcra_sihv = POWER6_MMCRA_SIHV,
- .oprofile_mmcra_sipr = POWER6_MMCRA_SIPR,
- .oprofile_mmcra_clear = POWER6_MMCRA_THRM |
- POWER6_MMCRA_OTHER,
.platform = "power5+",
},
{ /* Power6 */
@@ -364,14 +356,6 @@ static struct cpu_spec cpu_specs[] = {
.cpu_user_features = COMMON_USER_POWER6,
.icache_bsize = 128,
.dcache_bsize = 128,
- .num_pmcs = 6,
- .pmc_type = PPC_PMC_IBM,
- .oprofile_cpu_type = "ppc64/power6",
- .oprofile_type = PPC_OPROFILE_POWER4,
- .oprofile_mmcra_sihv = POWER6_MMCRA_SIHV,
- .oprofile_mmcra_sipr = POWER6_MMCRA_SIPR,
- .oprofile_mmcra_clear = POWER6_MMCRA_THRM |
- POWER6_MMCRA_OTHER,
.platform = "power6",
},
{ /* Cell Broadband Engine */
@@ -1316,18 +1300,37 @@ static struct cpu_spec cpu_specs[] = {
#endif /* CONFIG_PPC32 */
};
-struct cpu_spec *identify_cpu(unsigned long offset, unsigned int pvr)
+static struct cpu_spec the_cpu_spec;
+
+struct cpu_spec * __init identify_cpu(unsigned long offset, unsigned int pvr)
{
struct cpu_spec *s = cpu_specs;
- struct cpu_spec **cur = &cur_cpu_spec;
+ struct cpu_spec *t = &the_cpu_spec;
int i;
s = PTRRELOC(s);
- cur = PTRRELOC(cur);
+ t = PTRRELOC(t);
for (i = 0; i < ARRAY_SIZE(cpu_specs); i++,s++)
if ((pvr & s->pvr_mask) == s->pvr_value) {
- *cur = cpu_specs + i;
+ /*
+ * If we are overriding a previous value derived
+ * from the real PVR with a new value obtained
+ * using a logical PVR value, don't modify the
+ * performance monitor fields.
+ */
+ if (t->num_pmcs && !s->num_pmcs) {
+ t->cpu_name = s->cpu_name;
+ t->cpu_features = s->cpu_features;
+ t->cpu_user_features = s->cpu_user_features;
+ t->icache_bsize = s->icache_bsize;
+ t->dcache_bsize = s->dcache_bsize;
+ t->cpu_setup = s->cpu_setup;
+ t->cpu_restore = s->cpu_restore;
+ t->platform = s->platform;
+ } else
+ *t = *s;
+ *PTRRELOC(&cur_cpu_spec) = &the_cpu_spec;
#if defined(CONFIG_PPC64) || defined(CONFIG_BOOKE)
/* ppc64 and booke expect identify_cpu to also call
* setup_cpu for that processor. I will consolidate
^ permalink raw reply related
* Re: [PATCH 2/5] Add initial MPC8610 HPCD Platform files.
From: Kumar Gala @ 2007-10-04 4:35 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev@ozlabs.org, Xianghua Xiao
In-Reply-To: <20071004134115.cc099dd1.sfr@canb.auug.org.au>
On Oct 3, 2007, at 10:41 PM, Stephen Rothwell wrote:
> On Wed, 03 Oct 2007 15:09:33 -0500 Jon Loeliger <jdl@freescale.com>
> wrote:
>>
>> +++ b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
>> +#include <linux/stddef.h>
>> +#include <linux/kernel.h>
>> +#include <linux/pci.h>
>> +#include <linux/kdev_t.h>
>> +#include <linux/delay.h>
>> +#include <linux/seq_file.h>
>> +
>> +#include <asm/system.h>
>> +#include <asm/time.h>
>> +#include <asm/machdep.h>
>> +#include <asm/pci-bridge.h>
>> +#include <asm/mpc86xx.h>
>> +#include <asm/prom.h>
>
> You should include linux/of.h as well to use the of_ accessor
> functions.
added.
- k
^ permalink raw reply
* [PATCH] Don't build arch/powerpc/sysdev/dcr.c for ARCH=ppc kernels
From: Grant Likely @ 2007-10-04 4:50 UTC (permalink / raw)
To: paulus, linuxppc-dev, benh
From: Grant Likely <grant.likely@secretlab.ca>
dcr.c is an arch/powerpc only thing.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
Ben/Paulus,
As far as I can tell this is correct. Having sysdev/dcr.c in the arch/ppc
build spits out warnings. Grep doesn't show anything in arch/ppc that
is using it.
Cheers,
g.
arch/powerpc/sysdev/Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index 592c17e..7f88d4e 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -6,7 +6,6 @@ mpic-msi-obj-$(CONFIG_PCI_MSI) += mpic_msi.o mpic_u3msi.o
obj-$(CONFIG_MPIC) += mpic.o $(mpic-msi-obj-y)
obj-$(CONFIG_PPC_MPC106) += grackle.o
-obj-$(CONFIG_PPC_DCR) += dcr.o
obj-$(CONFIG_PPC_DCR_NATIVE) += dcr-low.o
obj-$(CONFIG_PPC_PMI) += pmi.o
obj-$(CONFIG_U3_DART) += dart_iommu.o
@@ -31,6 +30,7 @@ endif
# Temporary hack until we have migrated to asm-powerpc
ifeq ($(ARCH),powerpc)
+obj-$(CONFIG_PPC_DCR) += dcr.o
obj-$(CONFIG_CPM2) += cpm2_common.o cpm2_pic.o
obj-$(CONFIG_8xx) += mpc8xx_pic.o commproc.o
obj-$(CONFIG_UCODE_PATCH) += micropatch.o
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox