* Re: [PATCH] move drivers/macintosh variables to BSS
From: Paul Mackerras @ 2006-09-30 0:41 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev
In-Reply-To: <20060926201554.GA886@aepfle.de>
Olaf Hering writes:
> --- linux-2.6.18.orig/drivers/macintosh/ans-lcd.c
> +++ linux-2.6.18/drivers/macintosh/ans-lcd.c
> @@ -21,8 +21,8 @@
> #define ANSLCD_CTRL_IX 0x00
> #define ANSLCD_DATA_IX 0x10
>
> -static unsigned long anslcd_short_delay = 80;
> -static unsigned long anslcd_long_delay = 3280;
> +static unsigned long anslcd_short_delay;
> +static unsigned long anslcd_long_delay;
> static volatile unsigned char __iomem *anslcd_ptr;
>
> #undef DEBUG
> @@ -164,6 +164,8 @@ anslcd_init(void)
> printk(KERN_DEBUG "LCD: init\n");
> #endif
>
> + anslcd_short_delay = 80;
> + anslcd_long_delay = 3280;
What's the point of this? I can understand removing redundant "= 0"
initializers, but why fatten the code by 3 instructions just to remove
1 word from the data section?
Paul.
^ permalink raw reply
* Re: [PATCH 10/11] Add MPC8360EMDS board support
From: Paul Mackerras @ 2006-09-30 0:49 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <C62AC4D8-39E5-44D0-88A3-E8D8042FC828@kernel.crashing.org>
Kumar Gala writes:
> However, I'm not sure this really needs a node in the device tree.
> The BCSR isn't really the same from board to board last time I
> checked. I'd be interested in Paul's thinking about why it should be
> in the tree.
I just have a general preference for putting device addresses in the
device tree, because it increases the chance that you can reuse code
for multiple boards. If the BCSR is always completely unique on every
board then there isn't so much of an argument for it, I agree.
Paul.
^ permalink raw reply
* [PATCH] Fix boot wrapper invocation if CROSS_COMPILE contains spaces
From: Michael Ellerman @ 2006-09-30 1:54 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
My CROSS_COMPILE is "ccache /opt/compilers/blah", which confuses
the boot wrapper script. Quote CROSS_COMPILE and CROSS32_COMPILE
so they can safely contain spaces.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/boot/Makefile | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: to-merge/arch/powerpc/boot/Makefile
===================================================================
--- to-merge.orig/arch/powerpc/boot/Makefile
+++ to-merge/arch/powerpc/boot/Makefile
@@ -105,10 +105,10 @@ wrapperbits := $(extra-y) $(addprefix $(
# Bits for building various flavours of zImage
ifneq ($(CROSS32_COMPILE),)
-CROSSWRAP := -C $(CROSS32_COMPILE)
+CROSSWRAP := -C "$(CROSS32_COMPILE)"
else
ifneq ($(CROSS_COMPILE),)
-CROSSWRAP := -C $(CROSS_COMPILE)
+CROSSWRAP := -C "$(CROSS_COMPILE)"
endif
endif
^ permalink raw reply
* Re: [PATCH 6/6]: powerpc/cell spidernet refine locking
From: Andrew Morton @ 2006-09-30 2:47 UTC (permalink / raw)
To: Linas Vepstas
Cc: jeff, Arnd Bergmann, netdev, James K Lewis, linux-kernel,
linuxppc-dev
In-Reply-To: <20060929232911.GN6433@austin.ibm.com>
On Fri, 29 Sep 2006 18:29:11 -0500
linas@austin.ibm.com (Linas Vepstas) wrote:
> The transmit side of the spider ethernet driver currently
> places locks around some very large chunks of code. This
> results in a fair amount of lock contention is some cases.
> This patch makes the locks much more fine-grained, protecting
> only the cirtical sections. One lock is used to protect
> three locations: the queue head and tail pointers, and the
> queue low-watermark location.
You have spider_net_set_low_watermark() walking the tx_chain outside
tx_chain.lock. Are you sure about that?
^ permalink raw reply
* Re: [PATCH 10/11] Add MPC8360EMDS board support
From: Dan Malek @ 2006-09-28 4:10 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20060927112201.293fef44@localhost.localdomain>
On Sep 27, 2006, at 12:22 PM, Olof Johansson wrote:
> Yes, also called "board port hell".
I tend to think people skilled to do a board port
will still create something elegant and functional
given whatever the existing model.
> .... So you can boot the same kernel binary on
> several boards, as long as the drivers are built in and the correct
> device tree is used. Has everyone missed/forgotten that objective
> completely?
That was never an objective when we started, although
it seems some people involved in the implementation
think it's the only objective. It just happens to be a side
effect when convenient.
If you could look back over the eight or more years
of embedded Linux development with PowerPC, this
discussion of supporting multiple boards with
single binaries has occurred. In all cases, we never
considered it a requirement, there are many others
more important in embedded systems. Our greatest
concern was sharing code among all platforms, but
in a way we could still configure the most compact
and highest performance code for a particular
processor and board.
Although processors are faster and memory is larger
today, embedded systems are still trying to do more with
less. We still try to run the slowest processor speed to
conserve power and meet environmental requirements.
Memory still costs money, and designs try to use the
minimum amount to be cost competitive. IMHO, the same
requirements for compact and efficient code are just
as important today as they were when we had the first
discussion years ago. Conversion of the information,
kernel code just hanging around in case it may be used
on some board but not another and reliance on a
particular version of boot code are things we have
always tried to avoid. We are competing against other
processor architectures that are more compact and
resource friendly, it would be nice to not lose in
those product designs.
> The device tree describes the system, not how to program it. I think
> that's where the confusion might be.
There is no confusion. This device tree discussion was started
several years ago by a couple of us trying to find a way to better
describe the wide variety of PowerPC SOC processor peripheral
variants. Kumar and I had many discussions about this, since
my old static internal memory maps weren't going to work well.
The IBM microelectronics folks were also looking for something
similar. We thought a _simple_ flat device tree along with
the platform data would be sufficient to define this internal
peripheral mapping. I wasn't too keen on the idea, but didn't
have the time to provide any alternative implementation
against the Freescale coding machine :-)
Now, we have something that is way more complex than
we initially thought was necessary, trying to describe nearly
everything addressable in the system instead of just the
internal memory map. I suspect the software to attain
(IMHO the useless) goal of a single binary for multiple
boards will create exponentially complex software,
something that highly reliable embedded systems
are trying to avoid.
> I.e. create a generic "board-controller" device node, and put a
> suitable "compatible" property in there, so the right board controller
> driver can be chosen based on it. Having the address of the controller
> in there helps too, especially if there are two boards out there with
> the same controller but at different memory location.
What value does this provide to my client trying
to create a cost effective wireless home networking
device? It certainly doesn't make the board port
from hell any easier, since cramming the software
into 4M of flash will likely cause the choice of a
processor other than PowerPC that can configure
a smaller kernel and use a tiny custom piece of
boot code. Highly configurable development/evaluation
boards running a single binary aren't high volume
products, and the additional resources required
by such software could ensure real products aren't
developed with PPCs. We need to be sensitive
to this.
Thanks.
-- Dan
^ permalink raw reply
* RE: [PATCH 6/9] qe_lib: Add QE SoC support
From: Li Yang-r58472 @ 2006-09-30 4:37 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, paulus
In-Reply-To: <46197B66-B634-444C-B63D-115CDD15F1B7@kernel.crashing.org>
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> Sent: Friday, September 29, 2006 10:13 PM
> To: Li Yang-r58472
> Cc: paulus@samba.org; linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH 6/9] qe_lib: Add QE SoC support
>=20
>=20
> On Sep 29, 2006, at 5:35 AM, Li Yang wrote:
>=20
> > Signed-off-by: Li Yang <leoli@freescale.com>
> > Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
> >
> > ---
> > arch/powerpc/sysdev/qe_lib/qe.c | 176 ++++++++++++++++++++++++++++
> > +++++++++++
> > include/linux/fsl_devices.h | 39 ++++++++-
> > 2 files changed, 214 insertions(+), 1 deletions(-)
>=20
> As I've stated in the past make this use of_device instead of
> platform_device.
As I've argued before, there are currently many off-the-tree user of ppc
arch on 8360, and we must still support that. Change the ucc_geth
driver to use of_device will add the effort of maintaining two versions
of ucc_geth driver for us (one for ppc, one for powerpc). Do you really
think it is so important to replace platform_device with of_device? I
didn't see any true benefit of doing so.
- Leo
^ permalink raw reply
* Re: [PATCH 6/9] qe_lib: Add QE SoC support
From: Kumar Gala @ 2006-09-30 5:06 UTC (permalink / raw)
To: Li Yang-r58472; +Cc: linuxppc-dev, paulus
In-Reply-To: <4879B0C6C249214CBE7AB04453F84E4D19DB0D@zch01exm20.fsl.freescale.net>
On Sep 29, 2006, at 11:37 PM, Li Yang-r58472 wrote:
>
>> -----Original Message-----
>> From: Kumar Gala [mailto:galak@kernel.crashing.org]
>> Sent: Friday, September 29, 2006 10:13 PM
>> To: Li Yang-r58472
>> Cc: paulus@samba.org; linuxppc-dev@ozlabs.org
>> Subject: Re: [PATCH 6/9] qe_lib: Add QE SoC support
>>
>>
>> On Sep 29, 2006, at 5:35 AM, Li Yang wrote:
>>
>>> Signed-off-by: Li Yang <leoli@freescale.com>
>>> Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
>>>
>>> ---
>>> arch/powerpc/sysdev/qe_lib/qe.c | 176 ++++++++++++++++++++++++++++
>>> +++++++++++
>>> include/linux/fsl_devices.h | 39 ++++++++-
>>> 2 files changed, 214 insertions(+), 1 deletions(-)
>>
>> As I've stated in the past make this use of_device instead of
>> platform_device.
>
> As I've argued before, there are currently many off-the-tree user
> of ppc
> arch on 8360, and we must still support that. Change the ucc_geth
> driver to use of_device will add the effort of maintaining two
> versions
> of ucc_geth driver for us (one for ppc, one for powerpc). Do you
> really
> think it is so important to replace platform_device with of_device? I
> didn't see any true benefit of doing so.
I dont see why you need to maintain an arch/ppc version as everything
related to 8360 is arch/powerpc. If you guys have some internal
stuff that is your own issue to manage. This is a new device and
thus should use of_device. My goal is to eventually move the other
users of platform_device over to of_device when they aren't being
sured with arch/ppc in the public tree.
- kumar
^ permalink raw reply
* extern struct module __this_module
From: Ba Ying @ 2006-09-30 5:09 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 301 bytes --]
A newbies here.
I think when a module is loaded into linux kernel,a extern variable
called __this_module will be assigned
for this module.My question is how kernel can identify each module using
the same name since all the modules
and the kernel are in the same kernel space?
Thanks.
[-- Attachment #2: Type: text/html, Size: 2485 bytes --]
^ permalink raw reply
* [PATCH] move drivers/macintosh variables to BSS
From: Olaf Hering @ 2006-09-30 7:29 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17693.48421.91877.327347@cargo.ozlabs.ibm.com>
Move all the initialized variables to bss.
Mark a version string as const.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
---
drivers/macintosh/adbhid.c | 4 ++--
drivers/macintosh/apm_emu.c | 2 +-
drivers/macintosh/mac_hid.c | 4 ++--
drivers/macintosh/therm_adt746x.c | 6 +++---
drivers/macintosh/via-cuda.c | 2 +-
drivers/macintosh/via-macii.c | 10 +++++-----
drivers/macintosh/via-maciisi.c | 6 +++---
drivers/macintosh/via-pmu.c | 11 +++++------
drivers/macintosh/via-pmu68k.c | 4 ++--
9 files changed, 24 insertions(+), 25 deletions(-)
Index: linux-2.6/drivers/macintosh/adbhid.c
===================================================================
--- linux-2.6.orig/drivers/macintosh/adbhid.c
+++ linux-2.6/drivers/macintosh/adbhid.c
@@ -580,8 +580,8 @@ static struct adb_request led_request;
static int leds_pending[16];
static int leds_req_pending;
static int pending_devs[16];
-static int pending_led_start=0;
-static int pending_led_end=0;
+static int pending_led_start;
+static int pending_led_end;
static DEFINE_SPINLOCK(leds_lock);
static void leds_done(struct adb_request *req)
Index: linux-2.6/drivers/macintosh/apm_emu.c
===================================================================
--- linux-2.6.orig/drivers/macintosh/apm_emu.c
+++ linux-2.6/drivers/macintosh/apm_emu.c
@@ -102,7 +102,7 @@ static struct pmu_sleep_notifier apm_sle
SLEEP_LEVEL_USERLAND,
};
-static char driver_version[] = "0.5"; /* no spaces */
+static const char driver_version[] = "0.5"; /* no spaces */
#ifdef DEBUG
static char * apm_event_name[] = {
Index: linux-2.6/drivers/macintosh/mac_hid.c
===================================================================
--- linux-2.6.orig/drivers/macintosh/mac_hid.c
+++ linux-2.6/drivers/macintosh/mac_hid.c
@@ -17,10 +17,10 @@
static struct input_dev *emumousebtn;
static int emumousebtn_input_register(void);
-static int mouse_emulate_buttons = 0;
+static int mouse_emulate_buttons;
static int mouse_button2_keycode = KEY_RIGHTCTRL; /* right control key */
static int mouse_button3_keycode = KEY_RIGHTALT; /* right option key */
-static int mouse_last_keycode = 0;
+static int mouse_last_keycode;
#if defined(CONFIG_SYSCTL)
/* file(s) in /proc/sys/dev/mac_hid */
Index: linux-2.6/drivers/macintosh/therm_adt746x.c
===================================================================
--- linux-2.6.orig/drivers/macintosh/therm_adt746x.c
+++ linux-2.6/drivers/macintosh/therm_adt746x.c
@@ -47,11 +47,11 @@ static u8 FAN_SPD_SET[2] = {0x30, 0x31};
static u8 default_limits_local[3] = {70, 50, 70}; /* local, sensor1, sensor2 */
static u8 default_limits_chip[3] = {80, 65, 80}; /* local, sensor1, sensor2 */
-static const char *sensor_location[3] = {NULL, NULL, NULL};
+static const char *sensor_location[3];
-static int limit_adjust = 0;
+static int limit_adjust;
static int fan_speed = -1;
-static int verbose = 0;
+static int verbose;
MODULE_AUTHOR("Colin Leroy <colin@colino.net>");
MODULE_DESCRIPTION("Driver for ADT746x thermostat in iBook G4 and "
Index: linux-2.6/drivers/macintosh/via-cuda.c
===================================================================
--- linux-2.6.orig/drivers/macintosh/via-cuda.c
+++ linux-2.6/drivers/macintosh/via-cuda.c
@@ -86,7 +86,7 @@ static int data_index;
#ifdef CONFIG_PPC
static struct device_node *vias;
#endif
-static int cuda_fully_inited = 0;
+static int cuda_fully_inited;
#ifdef CONFIG_ADB
static int cuda_probe(void);
Index: linux-2.6/drivers/macintosh/via-macii.c
===================================================================
--- linux-2.6.orig/drivers/macintosh/via-macii.c
+++ linux-2.6/drivers/macintosh/via-macii.c
@@ -107,10 +107,10 @@ static enum macii_state {
awaiting_reply
} macii_state;
-static int need_poll = 0;
-static int command_byte = 0;
-static int last_reply = 0;
-static int last_active = 0;
+static int need_poll;
+static int command_byte;
+static int last_reply;
+static int last_active;
static struct adb_request *current_req;
static struct adb_request *last_req;
@@ -124,7 +124,7 @@ static int first_byte;
static int prefix_len;
static int status = ST_IDLE|TREQ;
static int last_status;
-static int driver_running = 0;
+static int driver_running;
/* debug level 10 required for ADB logging (should be && debug_adb, ideally) */
Index: linux-2.6/drivers/macintosh/via-maciisi.c
===================================================================
--- linux-2.6.orig/drivers/macintosh/via-maciisi.c
+++ linux-2.6/drivers/macintosh/via-maciisi.c
@@ -63,10 +63,10 @@ static volatile unsigned char *via;
#undef DEBUG_MACIISI_ADB
-static struct adb_request* current_req = NULL;
-static struct adb_request* last_req = NULL;
+static struct adb_request* current_req;
+static struct adb_request* last_req;
static unsigned char maciisi_rbuf[16];
-static unsigned char *reply_ptr = NULL;
+static unsigned char *reply_ptr;
static int data_index;
static int reading_reply;
static int reply_len;
Index: linux-2.6/drivers/macintosh/via-pmu.c
===================================================================
--- linux-2.6.orig/drivers/macintosh/via-pmu.c
+++ linux-2.6/drivers/macintosh/via-pmu.c
@@ -140,13 +140,13 @@ static volatile int adb_int_pending;
static volatile int disable_poll;
static struct device_node *vias;
static int pmu_kind = PMU_UNKNOWN;
-static int pmu_fully_inited = 0;
+static int pmu_fully_inited;
static int pmu_has_adb;
static struct device_node *gpio_node;
-static unsigned char __iomem *gpio_reg = NULL;
+static unsigned char __iomem *gpio_reg;
static int gpio_irq = NO_IRQ;
static int gpio_irq_enabled = -1;
-static volatile int pmu_suspended = 0;
+static volatile int pmu_suspended;
static spinlock_t pmu_lock;
static u8 pmu_intr_mask;
static int pmu_version;
@@ -179,7 +179,7 @@ int asleep;
BLOCKING_NOTIFIER_HEAD(sleep_notifier_list);
#ifdef CONFIG_ADB
-static int adb_dev_map = 0;
+static int adb_dev_map;
static int pmu_adb_flags;
static int pmu_probe(void);
@@ -2767,7 +2767,7 @@ pmu_polled_request(struct adb_request *r
#if defined(CONFIG_PM) && defined(CONFIG_PPC32)
-static int pmu_sys_suspended = 0;
+static int pmu_sys_suspended;
static int pmu_sys_suspend(struct sys_device *sysdev, pm_message_t state)
{
@@ -2807,7 +2807,6 @@ static struct sysdev_class pmu_sysclass
};
static struct sys_device device_pmu = {
- .id = 0,
.cls = &pmu_sysclass,
};
Index: linux-2.6/drivers/macintosh/via-pmu68k.c
===================================================================
--- linux-2.6.orig/drivers/macintosh/via-pmu68k.c
+++ linux-2.6/drivers/macintosh/via-pmu68k.c
@@ -96,10 +96,10 @@ static int data_index;
static int data_len;
static int adb_int_pending;
static int pmu_adb_flags;
-static int adb_dev_map = 0;
+static int adb_dev_map;
static struct adb_request bright_req_1, bright_req_2, bright_req_3;
static int pmu_kind = PMU_UNKNOWN;
-static int pmu_fully_inited = 0;
+static int pmu_fully_inited;
int asleep;
BLOCKING_NOTIFIER_HEAD(sleep_notifier_list);
^ permalink raw reply
* Re: [PATCH] Start arch/powerpc/boot code reorganization
From: Segher Boessenkool @ 2006-09-30 8:36 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: Matt Porter, Paul Mackerras, linuxppc-dev
In-Reply-To: <451C3641.60107@ru.mvista.com>
> I looked into the OF 64-bit extensions spec, and "cell" is 64-
> bit there.
Like I said before, a "cell" in OF has nothing to do with the items
in the device tree.
> So, "address" should look valid. I don't know whether PPC64 boxes
> support 64-bit OF, or only 32-bit, however, the kernel
Most OF's on 64-bit machines are 64 bit. The only defined client
interface for PowerPC is 32 bit though. And, again, the format
of the device tree is independent of machine word size or other
environmental factors.
> doesn't seem to deal with 64-bit ones correctly, so I'm assuming
> that 32-bit OF is at least available...
> Anyway, I'm still missing the point of not using "address" which
> is clearly intended for such case.
It also has many many problems and therefore should preferably
not be used.
Segher
^ permalink raw reply
* Re: [PATCH] Preliminary MPIC MSI backend
From: Segher Boessenkool @ 2006-09-30 8:43 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, linux-kernel, Eric W. Biederman
In-Reply-To: <20060929001657.6EFE667B8F@ozlabs.org>
> A pretty hackish MPIC backend, just enough to flesh out the design.
> Based on code from Segher.
It's pretty alright, and very hackish ;-) I'll sign off on it,
but some comments...
Signed-off-by: Segher Boessenkool <segher@kernel.crashing.org>
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
> +static int msi_mpic_check(struct pci_dev *pdev, int num,
> + struct msix_entry *entries, int type)
> +{
> + /* The irq allocator needs more work to support MSI-X/multi-MSI */
> + if (type == PCI_CAP_ID_MSIX || num != 1)
> + return 1;
I never tested any MSI-X, so maybe keep MSI-X disabled completely
for now?
> +static int msi_mpic_alloc(struct pci_dev *pdev, int num,
> + struct msix_entry *entries, int type)
> +{
> + irq_hw_number_t hwirq;
> + unsigned int virq;
> +
> + /* We need a smarter allocator for MSI-X/multi-MSI */
> + hwirq = irq_map[pdev->irq].hwirq;
> + hwirq += 100;
Yep, that's the main problem with this code. A sanity check to
make sure the number isn't >= 120 would be good, too.
> + set_irq_type(virq, IRQ_TYPE_EDGE_RISING);
I also had some code to show MSI IRQs as "MSI" instead of "EDGE"
in /proc/interrupts, maybe you want to add a generic version of
that? Or maybe you have, and I judt didn't see it.
> +static int msi_mpic_setup_msi_msg(struct pci_dev *pdev,
> + struct msix_entry *entry, struct msi_msg *msg, int type)
> +{
> + msg->address_lo = 0xfee00000; /* XXX What is this value? */
> + msg->address_hi = 0;
> + msg->data = pdev->irq | 0x8000;
Lose the | 0x8000 part, that was an old experiment to work around
U3/U4 MPIC brokenness (and it didn't work).
> +static int msi_mpic_init(void)
> +{
> + /* XXX Do this in mpic_init ? */
> + pr_debug("mpic_msi_init: Registering MPIC MSI ops.\n");
> + ppc_md.get_msi_ops = mpic_get_msi_ops;
It's best to do this in the platform code I think.
Segher
^ permalink raw reply
* Re: [PATCH 2/6]: powerpc/cell spidernet low watermark patch.
From: Arnd Bergmann @ 2006-09-30 10:30 UTC (permalink / raw)
To: linuxppc-dev; +Cc: akpm, jeff, netdev, James K Lewis, linux-kernel
In-Reply-To: <20060929231730.GJ6433@austin.ibm.com>
Am Saturday 30 September 2006 01:17 schrieb Linas Vepstas:
> Implement basic low-watermark support for the transmit queue.
> Hardware low-watermarks allow a properly configured kernel
> to continously stream data to a device and not have to handle
> any interrupts at all in doing so. Correct zero-interrupt
> operation can be actually observed for this driver, when the
> socket buffer is made large enough.
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* Re: [PATCH 1/6]: powerpc/cell spidernet burst alignment patch.
From: Arnd Bergmann @ 2006-09-30 10:29 UTC (permalink / raw)
To: Linas Vepstas
Cc: akpm, jeff, netdev, James K Lewis, linux-kernel, linuxppc-dev
In-Reply-To: <20060929231511.GI6433@austin.ibm.com>
Am Saturday 30 September 2006 01:15 schrieb Linas Vepstas:
> This patch increases the Burst Address alignment from 64 to 1024 in the
> Spidernet driver. This improves transmit performance for large packets.
>
> From: James K Lewis <jklewis@us.ibm.com>
> Signed-off-by: James K Lewis <jklewis@us.ibm.com>
> Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
> Cc: Arnd Bergmann <arnd@arndb.de>
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* [PATCH] Change ucc_geth driver to use of_device
From: Li Yang @ 2006-09-30 10:33 UTC (permalink / raw)
To: paulus, Kumar; +Cc: linuxppc-dev
This patch change ucc_geth driver to use of_device from
platform_device. It also fix a bug that bcsr_regs gets
accidentally unmapped. Remove trailing space.
Sign-off-by: Li Yang <leoli@freescale.com>
---
arch/powerpc/platforms/83xx/mpc8360e_pb.c | 32 ++++-
arch/powerpc/sysdev/qe_lib/Makefile | 2
arch/powerpc/sysdev/qe_lib/qe.c | 176 --------------------------
arch/powerpc/sysdev/qe_lib/qe_common.c | 22 +++
drivers/net/ucc_geth.c | 119 +++++++++++++-----
diff --git a/arch/powerpc/platforms/83xx/mpc8360e_pb.c b/arch/powerpc/platforms/83xx/mpc8360e_pb.c
index 4c6e5db..3563b9d 100644
--- a/arch/powerpc/platforms/83xx/mpc8360e_pb.c
+++ b/arch/powerpc/platforms/83xx/mpc8360e_pb.c
@@ -5,9 +5,9 @@
* Yin Olivia <Hong-hua.Yin@freescale.com>
*
* Description:
- * MPC8360E MDS PB board specific routines.
+ * MPC8360E MDS PB board specific routines.
*
- * Changelog:
+ * Changelog:
* Jun 21, 2006 Initial version
*
* This program is free software; you can redistribute it and/or modify it
@@ -30,6 +30,7 @@ #include <linux/seq_file.h>
#include <linux/root_dev.h>
#include <linux/initrd.h>
+#include <asm/of_device.h>
#include <asm/system.h>
#include <asm/atomic.h>
#include <asm/time.h>
@@ -113,18 +114,17 @@ #ifdef CONFIG_QUICC_ENGINE
if ((np = of_find_node_by_name(np, "par_io")) != NULL) {
par_io_init(np);
of_node_put(np);
-
+
for (np = NULL; (np = of_find_node_by_name(np, "ucc")) != NULL;)
par_io_of_config(np);
}
-
- if ((np = of_find_compatible_node(NULL, "network", "ucc_geth"))
+
+ if ((np = of_find_compatible_node(NULL, "network", "ucc_geth"))
!= NULL){
/* Reset the Ethernet PHY */
bcsr_regs[9] &= ~0x20;
udelay(1000);
bcsr_regs[9] |= 0x20;
- iounmap(bcsr_regs);
of_node_put(np);
}
@@ -142,9 +142,25 @@ #else
#endif
}
-void __init mpc8360_sys_init_IRQ(void)
+static int __init mpc8360_declare_of_platform_devices(void)
{
+ struct device_node *np;
+
+ for (np = NULL; (np = of_find_compatible_node(np, "network", "ucc_geth")) != NULL;) {
+ int ucc_num;
+ char bus_id[BUS_ID_SIZE];
+
+ ucc_num = *((uint *) get_property(np, "device-id", NULL)) - 1;
+ snprintf(bus_id, BUS_ID_SIZE, "ucc_geth.%u", ucc_num);
+ of_platform_device_create(np, bus_id, NULL);
+ }
+
+ return 0;
+}
+device_initcall(mpc8360_declare_of_platform_devices);
+void __init mpc8360_sys_init_IRQ(void)
+{
struct device_node *np;
np = of_find_node_by_type(NULL, "ipic");
@@ -164,7 +180,7 @@ #ifdef CONFIG_QUICC_ENGINE
if (!np)
return;
- qe_ic_init(np, 0);
+ qe_ic_init(np, 0);
of_node_put(np);
#endif /* CONFIG_QUICC_ENGINE */
}
diff --git a/arch/powerpc/sysdev/qe_lib/Makefile b/arch/powerpc/sysdev/qe_lib/Makefile
index 9a54a81..316a63c 100644
--- a/arch/powerpc/sysdev/qe_lib/Makefile
+++ b/arch/powerpc/sysdev/qe_lib/Makefile
@@ -1,7 +1,7 @@
#
# Makefile for the linux ppc-specific parts of QE
#
-obj-$(CONFIG_QUICC_ENGINE)+= qe_common.o qe.o qe_ic.o qe_io.o
+obj-$(CONFIG_QUICC_ENGINE)+= qe_common.o qe_ic.o qe_io.o
obj-$(CONFIG_UCC) += ucc.o
obj-$(CONFIG_UCC_SLOW) += ucc_slow.o
diff --git a/arch/powerpc/sysdev/qe_lib/qe.c b/arch/powerpc/sysdev/qe_lib/qe.c
deleted file mode 100644
index df3e826..0000000
--- a/arch/powerpc/sysdev/qe_lib/qe.c
+++ /dev/null
@@ -1,176 +0,0 @@
-/*
- * Copyright (C) 2006 Freescale Semicondutor, Inc. All rights reserved.
- *
- * Author: Li Yang <LeoLi@freescale.com>
- *
- * Description:
- * FSL QE SOC setup.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
- */
-
-#include <linux/config.h>
-#include <linux/stddef.h>
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/errno.h>
-#include <linux/major.h>
-#include <linux/delay.h>
-#include <linux/irq.h>
-#include <linux/module.h>
-#include <linux/device.h>
-#include <linux/platform_device.h>
-#include <linux/fsl_devices.h>
-
-#include <asm/system.h>
-#include <asm/atomic.h>
-#include <asm/io.h>
-#include <asm/irq.h>
-#include <asm/prom.h>
-#include <sysdev/fsl_soc.h>
-#include <mm/mmu_decl.h>
-
-static phys_addr_t qebase = -1;
-
-phys_addr_t get_qe_base(void)
-{
- struct device_node *qe;
-
- if (qebase != -1)
- return qebase;
-
- qe = of_find_node_by_type(NULL, "qe");
- if (qe) {
- unsigned int size;
- void *prop = get_property(qe, "reg", &size);
- qebase = of_translate_address(qe, prop);
- of_node_put(qe);
- };
-
- return qebase;
-}
-
-EXPORT_SYMBOL(get_qe_base);
-
-static int __init ucc_geth_of_init(void)
-{
- struct device_node *np;
- unsigned int i, ucc_num;
- struct platform_device *ugeth_dev;
- struct resource res;
- int ret;
-
- for (np = NULL, i = 0;
- (np = of_find_compatible_node(np, "network", "ucc_geth")) != NULL;
- i++) {
- struct resource r[2];
- struct device_node *phy, *mdio;
- struct ucc_geth_platform_data ugeth_data;
- unsigned int *id;
- char *model;
- void *mac_addr;
- phandle *ph;
-
- memset(r, 0, sizeof(r));
- memset(&ugeth_data, 0, sizeof(ugeth_data));
-
- ret = of_address_to_resource(np, 0, &r[0]);
- if (ret)
- goto err;
-
- ugeth_data.phy_reg_addr = r[0].start;
- r[1].start = r[1].end = irq_of_parse_and_map(np, 0);
- r[1].flags = IORESOURCE_IRQ;
-
- model = get_property(np, "model", NULL);
- ucc_num = *((u32 *) get_property(np, "device-id", NULL));
- if ((strstr(model, "UCC") == NULL) ||
- (ucc_num < 1) || (ucc_num > 8)) {
- ret = -ENODEV;
- goto err;
- }
-
- ugeth_dev =
- platform_device_register_simple("ucc_geth", ucc_num - 1,
- &r[0], 2);
-
- if (IS_ERR(ugeth_dev)) {
- ret = PTR_ERR(ugeth_dev);
- goto err;
- }
-
- mac_addr = get_property(np, "mac-address", NULL);
-
- memcpy(ugeth_data.mac_addr, mac_addr, 6);
-
- ugeth_data.rx_clock = *((u32 *) get_property(np, "rx-clock",
- NULL));
- ugeth_data.tx_clock = *((u32 *) get_property(np, "tx-clock",
- NULL));
-
- ph = (phandle *) get_property(np, "phy-handle", NULL);
- phy = of_find_node_by_phandle(*ph);
-
- if (phy == NULL) {
- ret = -ENODEV;
- goto unreg;
- }
-
- mdio = of_get_parent(phy);
-
- id = (u32 *) get_property(phy, "reg", NULL);
- ret = of_address_to_resource(mdio, 0, &res);
- if (ret) {
- of_node_put(phy);
- of_node_put(mdio);
- goto unreg;
- }
-
- ugeth_data.phy_id = *id;
-
- ugeth_data.phy_interrupt = irq_of_parse_and_map(phy, 0);;
- ugeth_data.phy_interface = *((u32 *) get_property(phy,
- "interface", NULL));
-
- /* FIXME: Work around for early chip rev. */
- /* There's a bug in initial chip rev(s) in the RGMII ac */
- /* timing. */
- /* The following compensates by writing to the reserved */
- /* QE Port Output Hold Registers (CPOH1?). */
- if ((ugeth_data.phy_interface == ENET_1000_RGMII) ||
- (ugeth_data.phy_interface == ENET_100_RGMII) ||
- (ugeth_data.phy_interface == ENET_10_RGMII)) {
- u32 *tmp_reg = (u32 *) ioremap(get_immrbase()
- + 0x14A8, 0x4);
- u32 tmp_val = in_be32(tmp_reg);
- if (ucc_num == 1)
- out_be32(tmp_reg, tmp_val | 0x00003000);
- else if (ucc_num == 2)
- out_be32(tmp_reg, tmp_val | 0x0c000000);
- iounmap(tmp_reg);
- }
-
- if (ugeth_data.phy_interrupt != 0)
- ugeth_data.board_flags |= FSL_UGETH_BRD_HAS_PHY_INTR;
-
- of_node_put(phy);
- of_node_put(mdio);
-
- ret = platform_device_add_data(ugeth_dev, &ugeth_data,
- sizeof(struct ucc_geth_platform_data));
- if (ret)
- goto unreg;
- }
-
- return 0;
-
-unreg:
- platform_device_unregister(ugeth_dev);
-err:
- return ret;
-}
-
-arch_initcall(ucc_geth_of_init);
diff --git a/arch/powerpc/sysdev/qe_lib/qe_common.c b/arch/powerpc/sysdev/qe_lib/qe_common.c
index 516c186..2e6e6fe 100644
--- a/arch/powerpc/sysdev/qe_lib/qe_common.c
+++ b/arch/powerpc/sysdev/qe_lib/qe_common.c
@@ -60,6 +60,28 @@ static int qe_sdma_init(void);
static DEFINE_SPINLOCK(qe_lock);
+static phys_addr_t qebase = -1;
+
+phys_addr_t get_qe_base(void)
+{
+ struct device_node *qe;
+
+ if (qebase != -1)
+ return qebase;
+
+ qe = of_find_node_by_type(NULL, "qe");
+ if (qe) {
+ unsigned int size;
+ void *prop = get_property(qe, "reg", &size);
+ qebase = of_translate_address(qe, prop);
+ of_node_put(qe);
+ };
+
+ return qebase;
+}
+
+EXPORT_SYMBOL(get_qe_base);
+
void qe_reset(void)
{
if (qe_immr == NULL)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 6ca380b..85be97f 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -2,14 +2,11 @@
* Copyright (C) Freescale Semicondutor, Inc. 2006. All rights reserved.
*
* Author: Shlomi Gridish <gridish@freescale.com>
+ * Li Yang <leoli@freescale.com>
*
* Description:
* QE UCC Gigabit Ethernet Driver
*
- * Changelog:
- * Jul 6, 2006 Li Yang <LeoLi@freescale.com>
- * - Rearrange code and style fixes
- *
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
* Free Software Foundation; either version 2 of the License, or (at your
@@ -31,9 +28,9 @@ #include <linux/delay.h>
#include <linux/dma-mapping.h>
#include <linux/fsl_devices.h>
#include <linux/ethtool.h>
-#include <linux/platform_device.h>
#include <linux/mii.h>
+#include <asm/of_device.h>
#include <asm/uaccess.h>
#include <asm/irq.h>
#include <asm/io.h>
@@ -4146,30 +4143,47 @@ struct ethtool_ops ucc_geth_ethtool_ops
.get_ethtool_stats = NULL,
};
-static int ucc_geth_probe(struct device *device)
+static int ucc_geth_probe(struct of_device* ofdev, const struct of_device_id *match)
{
- struct platform_device *pdev = to_platform_device(device);
- struct ucc_geth_platform_data *ugeth_pdata;
+ struct device *device = &ofdev->dev;
+ struct device_node *np = ofdev->node;
struct net_device *dev = NULL;
struct ucc_geth_private *ugeth = NULL;
struct ucc_geth_info *ug_info;
- int err;
+ struct resource res;
+ struct device_node *phy;
+ int err, ucc_num, phy_interface;
static int mii_mng_configured = 0;
+ phandle *ph;
ugeth_vdbg("%s: IN", __FUNCTION__);
- ugeth_pdata = (struct ucc_geth_platform_data *)pdev->dev.platform_data;
+ ucc_num = *((int *) get_property(np, "device-id", NULL)) - 1;
+ if ((ucc_num < 0) || (ucc_num > 7))
+ return -ENODEV;
+
+ ug_info = &ugeth_info[ucc_num];
+ ug_info->uf_info.ucc_num = ucc_num;
+ ug_info->uf_info.rx_clock = *((uint *) get_property(np, "rx-clock", NULL));
+ ug_info->uf_info.tx_clock = *((uint *) get_property(np, "tx-clock", NULL));
+ err = of_address_to_resource(np, 0, &res);
+ if (err)
+ return -EINVAL;
+
+ ug_info->uf_info.regs = res.start;
+ ug_info->uf_info.irq = irq_of_parse_and_map(np, 0);
+
+ ph = (phandle *) get_property(np, "phy-handle", NULL);
+ phy = of_find_node_by_phandle(*ph);
- ug_info = &ugeth_info[pdev->id];
- ug_info->uf_info.ucc_num = pdev->id;
- ug_info->uf_info.rx_clock = ugeth_pdata->rx_clock;
- ug_info->uf_info.tx_clock = ugeth_pdata->tx_clock;
- ug_info->uf_info.regs = ugeth_pdata->phy_reg_addr;
- ug_info->uf_info.irq = platform_get_irq(pdev, 0);
- ug_info->phy_address = ugeth_pdata->phy_id;
- ug_info->enet_interface = ugeth_pdata->phy_interface;
- ug_info->board_flags = ugeth_pdata->board_flags;
- ug_info->phy_interrupt = ugeth_pdata->phy_interrupt;
+ if (phy == NULL)
+ return -ENODEV;
+
+ ug_info->phy_address = *(u8 *) get_property(phy, "reg", NULL);
+ ug_info->enet_interface = *((uint *) get_property(phy, "interface", NULL));
+ ug_info->phy_interrupt = irq_of_parse_and_map(phy, 0);
+ ug_info->board_flags = (ug_info->phy_interrupt == NO_IRQ)?
+ 0:FSL_UGETH_BRD_HAS_PHY_INTR;
printk(KERN_INFO "ucc_geth: UCC%1d at 0x%8x (irq = %d) \n",
ug_info->uf_info.ucc_num + 1, ug_info->uf_info.regs,
@@ -4177,12 +4191,43 @@ static int ucc_geth_probe(struct device
if (ug_info == NULL) {
ugeth_err("%s: [%d] Missing additional data!", __FUNCTION__,
- pdev->id);
+ ucc_num);
return -ENODEV;
}
+ /* FIXME: Work around for early chip rev. */
+ /* There's a bug in initial chip rev(s) in the RGMII ac */
+ /* timing. */
+ /* The following compensates by writing to the reserved */
+ /* QE Port Output Hold Registers (CPOH1?). */
+ phy_interface = *((int *) get_property(phy, "interface", NULL));
+ if ((phy_interface == ENET_1000_RGMII) ||
+ (phy_interface == ENET_100_RGMII) ||
+ (phy_interface == ENET_10_RGMII)) {
+ struct device_node *soc;
+ phys_addr_t immrbase = -1;
+ u32 *tmp_reg;
+ u32 tmp_val;
+
+ soc = of_find_node_by_type(NULL, "soc");
+ if (soc) {
+ unsigned int size;
+ void *prop = get_property(soc, "reg", &size);
+ immrbase = of_translate_address(soc, prop);
+ of_node_put(soc);
+ };
+
+ tmp_reg = (u32 *) ioremap(immrbase + 0x14A8, 0x4);
+ tmp_val = in_be32(tmp_reg);
+ if (ucc_num == 1)
+ out_be32(tmp_reg, tmp_val | 0x00003000);
+ else if (ucc_num == 2)
+ out_be32(tmp_reg, tmp_val | 0x0c000000);
+ iounmap(tmp_reg);
+ }
+
if (!mii_mng_configured) {
- ucc_set_qe_mux_mii_mng(ug_info->uf_info.ucc_num);
+ ucc_set_qe_mux_mii_mng(ucc_num);
mii_mng_configured = 1;
}
@@ -4229,13 +4274,14 @@ #endif /* CONFIG_UGETH_NAPI */
ugeth->ug_info = ug_info;
ugeth->dev = dev;
- memcpy(dev->dev_addr, ugeth_pdata->mac_addr, 6);
+ memcpy(dev->dev_addr, get_property(np, "mac-address", NULL), 6);
return 0;
}
-static int ucc_geth_remove(struct device *device)
+static int ucc_geth_remove(struct of_device* ofdev)
{
+ struct device *device = &ofdev->dev;
struct net_device *dev = dev_get_drvdata(device);
struct ucc_geth_private *ugeth = netdev_priv(dev);
@@ -4246,28 +4292,37 @@ static int ucc_geth_remove(struct device
return 0;
}
-/* Structure for a device driver */
-static struct device_driver ucc_geth_driver = {
- .name = DRV_NAME,
- .bus = &platform_bus_type,
- .probe = ucc_geth_probe,
- .remove = ucc_geth_remove,
+static struct of_device_id ucc_geth_match[] = {
+ {
+ .compatible = "ucc_geth",
+ },
+ {},
+};
+
+MODULE_DEVICE_TABLE(of, ucc_geth_match);
+
+static struct of_platform_driver ucc_geth_driver = {
+ .name = DRV_NAME,
+ .match_table = ucc_geth_match,
+ .probe = ucc_geth_probe,
+ .remove = ucc_geth_remove,
};
static int __init ucc_geth_init(void)
{
int i;
+
printk(KERN_INFO "ucc_geth: " DRV_DESC "\n");
for (i = 0; i < 8; i++)
memcpy(&(ugeth_info[i]), &ugeth_primary_info,
sizeof(ugeth_primary_info));
- return driver_register(&ucc_geth_driver);
+ return of_register_driver(&ucc_geth_driver);
}
static void __exit ucc_geth_exit(void)
{
- driver_unregister(&ucc_geth_driver);
+ of_unregister_driver(&ucc_geth_driver);
}
module_init(ucc_geth_init);
^ permalink raw reply related
* Re: [PATCH 5/6]: powerpc/cell spidernet ethtool -i version number
From: Arnd Bergmann @ 2006-09-30 10:35 UTC (permalink / raw)
To: Linas Vepstas
Cc: akpm, jeff, netdev, James K Lewis, linux-kernel, linuxppc-dev
In-Reply-To: <20060929232625.GM6433@austin.ibm.com>
Am Saturday 30 September 2006 01:26 schrieb Linas Vepstas:
> This patch moves transmit queue cleanup code out of the
> interrupt context, and into the NAPI polling routine.
>
> Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
> Cc: James K Lewis <jklewis@us.ibm.com>
> Cc: Arnd Bergmann <arnd@arndb.de>
The subject of this mail should be "spidernet: use NAPI poll for
TX interrupts", otherwise
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* Re: [PATCH 3/6]: powerpc/cell spidernet stop error printing patch.
From: Arnd Bergmann @ 2006-09-30 10:32 UTC (permalink / raw)
To: linuxppc-dev; +Cc: akpm, jeff, netdev, James K Lewis, linux-kernel
In-Reply-To: <20060929231922.GK6433@austin.ibm.com>
Am Saturday 30 September 2006 01:19 schrieb Linas Vepstas:
> Turn off mis-interpretation of the queue-empty interrupt
> status bit as an error. This bit is set as a part of
> the previous low-watermark patch.
>
> Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
> Signed-off-by: James K Lewis <jklewis@us.ibm.com>
> Cc: Arnd Bergmann <arnd@arndb.de>
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* Re: [PATCH 4/6]: powerpc/cell spidernet ethtool -i version number info.
From: Arnd Bergmann @ 2006-09-30 10:33 UTC (permalink / raw)
To: Linas Vepstas
Cc: akpm, jeff, netdev, James K Lewis, linux-kernel, linuxppc-dev
In-Reply-To: <20060929232139.GL6433@austin.ibm.com>
Am Saturday 30 September 2006 01:21 schrieb Linas Vepstas:
> This patch adds version information as reported by
> ethtool -i to the Spidernet driver.
>
> From: James K Lewis <jklewis@us.ibm.com>
> Signed-off-by: James K Lewis <jklewis@us.ibm.com>
> Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
> Cc: Arnd Bergmann <arnd@arndb.de>
Same comment as last time this was submitted:
> @@ -2303,6 +2304,8 @@ static struct pci_driver spider_net_driv
> =A0 */
> =A0static int __init spider_net_init(void)
> =A0{
> +=A0=A0=A0=A0=A0=A0=A0printk("spidernet Version %s.\n",VERSION);
> +
> =A0=A0=A0=A0=A0=A0=A0=A0if (rx_descriptors < SPIDER_NET_RX_DESCRIPTORS_MI=
N) {
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0rx_descriptors =3D SPIDER=
_NET_RX_DESCRIPTORS_MIN;
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0pr_info("adjusting rx des=
criptors to %i.\n",
This is missing a printk level and a space character. More importantly,
you should not print the presence of the driver to the syslog, but
the presence of a device driven by it.
Arnd <><
^ permalink raw reply
* Re: [PATCH 0/6]: powerpc/cell spidernet ethernet patches
From: Arnd Bergmann @ 2006-09-30 10:40 UTC (permalink / raw)
To: linuxppc-dev; +Cc: akpm, jeff, netdev, James K Lewis, linux-kernel
In-Reply-To: <20060929230552.GG6433@austin.ibm.com>
Am Saturday 30 September 2006 01:05 schrieb Linas Vepstas:
> Although these patches have not been baking in
> any -mm tree, they have been tested and are
> generally available as a part of the Cell SDK 2.0
> overseen by Arnd Bergmann. (Arnd, if you want
> to lend a voice of authority here, or to correct
> me, please do so...)
>
> The following sequence of six patches implement a
> series of changes to the transmit side of the
> spidernet ethernet device driver, significantly
> improving performance for large packets.
>
> This series of patches is almost identical to
> those previously mailed on 18-20 August, with one
> critical change: NAPI polling is used instead of
> homegrown polling.
>
> Although these patches improve things, I am not
> satisfied with how this driver behaves, and so
> plan to do additional work next week.
>
I'm not sure if I have missed a patch in here, but I
don't see anything reintroducing the 'netif_stop_queue'
that is missing from the transmit path.
Do you have a extra patch for that?
Arnd <><
^ permalink raw reply
* RE: [PATCH 7/9] Add MPC8360EMDS board support
From: Li Yang-r58472 @ 2006-09-30 11:39 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, paulus
In-Reply-To: <BCC8A2FA-B29A-4D87-A3EB-820F3336E1B0@kernel.crashing.org>
> > +
> > +static u8 *bcsr_regs =3D NULL;
> > +
> > +u8 *get_bcsr(void)
> > +{
> > + return bcsr_regs;
> > +}
>=20
> Does anything outside of this file use this? If so, its broken since
> you iounmap(bcsr_regs) when you reset the enet phy. If nothings
> using it, than drop the header extern and the header file.
Oops, this is a bug introduced in bcsr change. I have fixed it in the
latest patch. Current external user of bcsr is a workaround in ucc_geth
phy code.
- Leo
^ permalink raw reply
* Re: [PATCH] Change ucc_geth driver to use of_device
From: Paul Mackerras @ 2006-09-30 12:01 UTC (permalink / raw)
To: Li Yang; +Cc: linuxppc-dev
In-Reply-To: <451E4808.7010004@freescale.com>
Li Yang writes:
> This patch change ucc_geth driver to use of_device from
> platform_device. It also fix a bug that bcsr_regs gets
> accidentally unmapped. Remove trailing space.
So, does this go on top of your series of 9 patches, or is it instead
of one of them?
Paul.
^ permalink raw reply
* Re: [PATCH 10/11] Add MPC8360EMDS board support --and device tree in general
From: Jin Jiu @ 2006-09-30 14:37 UTC (permalink / raw)
To: dan; +Cc: linuxppc-dev
I have been doing linuxppc porting for quite a couple years, though
rarely email here.
the flat-device-tree, copied from a server/workstation-alike
openfirmware concept, is doing more harm than good to freescale's
powerpc chips. IMHO.
embedded products are about customization, efficiency, and cost. it
will never be standardized on low-level(e.g. u-boot-kernel-interface)
like a server/workstation does, as there are hundreds, if not
thousands different applications. plus we don't need the
_unnecessary_over_complexity_ from the device tree(e.g., the bd_t is
not perfect, but simple enough and it works!). the one binary runs on
various platform idea is not that appealing at all. i do not want to
make one pair of shoe and fit all.
i, for one, now begin to use mips for my projects. the current
embedded linuxppc direction really confused me, and it makes simple
thing so complicated to say the least(ppc->powerpc,
openfirmware-alike-flat-dev-tree...).
again, it's my personal opinion.
Jinjiu
On Sep 27, 2006, at 12:22 PM, Olof Johansson wrote:
>> Yes, also called "board port hell".
I tend to think people skilled to do a board port
will still create something elegant and functional
given whatever the existing model.
>> .... So you can boot the same kernel binary on
>> several boards, as long as the drivers are built in and the correct
>> device tree is used. Has everyone missed/forgotten that objective
>> completely?
That was never an objective when we started, although
it seems some people involved in the implementation
think it's the only objective. It just happens to be a side
effect when convenient.
If you could look back over the eight or more years
of embedded Linux development with PowerPC, this
discussion of supporting multiple boards with
single binaries has occurred. In all cases, we never
considered it a requirement, there are many others
more important in embedded systems. Our greatest
concern was sharing code among all platforms, but
in a way we could still configure the most compact
and highest performance code for a particular
processor and board.
Although processors are faster and memory is larger
today, embedded systems are still trying to do more with
less. We still try to run the slowest processor speed to
conserve power and meet environmental requirements.
Memory still costs money, and designs try to use the
minimum amount to be cost competitive. IMHO, the same
requirements for compact and efficient code are just
as important today as they were when we had the first
discussion years ago. Conversion of the information,
kernel code just hanging around in case it may be used
on some board but not another and reliance on a
particular version of boot code are things we have
always tried to avoid. We are competing against other
processor architectures that are more compact and
resource friendly, it would be nice to not lose in
those product designs.
>> The device tree describes the system, not how to program it. I think
>> that's where the confusion might be.
There is no confusion. This device tree discussion was started
several years ago by a couple of us trying to find a way to better
describe the wide variety of PowerPC SOC processor peripheral
variants. Kumar and I had many discussions about this, since
my old static internal memory maps weren't going to work well.
The IBM microelectronics folks were also looking for something
similar. We thought a _simple_ flat device tree along with
the platform data would be sufficient to define this internal
peripheral mapping. I wasn't too keen on the idea, but didn't
have the time to provide any alternative implementation
against the Freescale coding machine :-)
Now, we have something that is way more complex than
we initially thought was necessary, trying to describe nearly
everything addressable in the system instead of just the
internal memory map. I suspect the software to attain
(IMHO the useless) goal of a single binary for multiple
boards will create exponentially complex software,
something that highly reliable embedded systems
are trying to avoid.
>> I.e. create a generic "board-controller" device node, and put a
>> suitable "compatible" property in there, so the right board controller
>> driver can be chosen based on it. Having the address of the controller
>> in there helps too, especially if there are two boards out there with
>> the same controller but at different memory location.
What value does this provide to my client trying
to create a cost effective wireless home networking
device? It certainly doesn't make the board port
from hell any easier, since cramming the software
into 4M of flash will likely cause the choice of a
processor other than PowerPC that can configure
a smaller kernel and use a tiny custom piece of
boot code. Highly configurable development/evaluation
boards running a single binary aren't high volume
products, and the additional resources required
by such software could ensure real products aren't
developed with PPCs. We need to be sensitive
to this.
Thanks.
-- Dan
^ permalink raw reply
* Re: Linux not booting consistantly
From: Jeff Stevens @ 2006-09-30 15:20 UTC (permalink / raw)
To: Stefan Roese, linuxppc-embedded
In-Reply-To: <200609220650.20992.sr@denx.de>
I have been working with the hardware guys trying to
find any issues with the memory, and we haven't seen
anything yet, and we have talked to AMCC, and they
said they couldn't see anything wrong with the
hardware. I did do a post-mordum dump of the log
buffer, and this is what I get:
001e40c4: 3c353e4c 696e7578 20766572 73696f6e
<5>Linux version
001e40d4: 20322e36 2e313520 28726f6f 74406c6f
2.6.15 (root@lo
001e40e4: 63616c68 6f73742e 6c6f6361 6c646f6d
calhost.localdom
001e40f4: 61696e29 20286763 63207665 7273696f ain)
(gcc versio
001e4104: 6e20342e 302e3020 2844454e 5820454c n
4.0.0 (DENX EL
001e4114: 444b2034 2e302034 2e302e30 29292023 DK
4.0 4.0.0)) #
001e4124: 38205475 65205365 70203236 2031373a 8 Tue
Sep 26 17:
001e4134: 34393a31 33204544 54203230 30360a3c 49:13
EDT 2006.<
001e4144: 343e4a4a 533a2057 41532048 4552454a
4>JJS: WAS HEREJ
001e4154: 4a53324a 4a53334a 4a53335f 314a4a53
JS2JJS3JJS3_1JJS
001e4164: 345f4a4a 53345f31 5f4a4a53 345f325f
4_JJS4_1_JJS4_2_
001e4174: 4a4a5334 5f335f4a 4a53345f 00000000
JJS4_3_JJS4_....
001e4184: 00000000 00000000 ........
I placed a few printks in arch/ppc/kernel/start.c and
found that it crashed right after do_init_bootmem(),
right after placing the first character of "_JJS4_1".
printk("JJS3");
parse_early_param();
printk("JJS3_1");
for (i = 0; i < 1000000; i++)
{
if (i > 999999)
{
break;
}
}
printk("JJS4");
/* set up the bootmem stuff with available
memory */
do_init_bootmem();
printk("_JJS4_1");
if ( ppc_md.progress )
ppc_md.progress("setup_arch: bootmem", 0x3eab);
printk("_JJS4_2");
When it does decide to work, most of the time it gets
through the whole kernel and everything runs fine,
though I have seen it hang after probing for PCI
devices a couple of times. This looks like it is a
memory issue, but I don't know what else to try. Does
anyone have any ideas? I would appreciate any input.
Thanks,
Jeff Stevens
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* [PATCH] AC power not detected if no battery present
From: Olaf Hering @ 2006-09-30 15:25 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1159081888.5924.20.camel@localhost.localdomain>
/proc/pmu/info contains AC Power: 0 when booting without battery.
Force AC Power, it will be updated whenever the battery state changes.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
---
drivers/macintosh/via-pmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6/drivers/macintosh/via-pmu.c
===================================================================
--- linux-2.6.orig/drivers/macintosh/via-pmu.c
+++ linux-2.6/drivers/macintosh/via-pmu.c
@@ -168,7 +168,7 @@ static int option_server_mode;
int pmu_battery_count;
int pmu_cur_battery;
-unsigned int pmu_power_flags;
+unsigned int pmu_power_flags = PMU_PWR_AC_PRESENT;
struct pmu_battery_info pmu_batteries[PMU_MAX_BATTERIES];
static int query_batt_timer = BATTERY_POLLING_COUNT;
static struct adb_request batt_req;
^ permalink raw reply
* Re: [PATCH 10/11] Add MPC8360EMDS board support
From: Li Yang @ 2006-09-30 15:56 UTC (permalink / raw)
To: Dan Malek; +Cc: Olof Johansson, linuxppc-dev, Paul Mackerras
In-Reply-To: <EBD0615C-4F22-430F-BD23-1283DF98F1B3@embeddedalley.com>
Dan,
I do share the same concern as you. Single image for multiple
platforms is a great feature for server and desktop, but not as
valuable to embedded devices. Response time and footprint are more
important concerns. However, OTOH, OF device tree is a good
architecture for code reuse and porting. It is better for reuse as it
enables code sharing between embedded and desktop devices. It is more
and more popular to use peripherals from desktop on embedded systems.
Better for porting because: from the single DTS file, we can get/set
all the information about the system, instead of hacking into dozens
of drivers. It is a tough choice to make.
Well, I have an idea. Maybe it can relief the side effect of DT to
embedded systems, but I'm even not sure if it is feasible or not. If
we can rework the prom APIs, make them to have two modes, embedded and
non-embedded. It should be switched using a configuration option.
For non-embedded mode, they just act the same as what we have now,
which get properties from looking up the tree at runtime. While in
embedded mode, the prom APIs actually compile the properties to be
looked up in tree into the code as const values. Thus save the
time/space consumed by look-up. Well. The implementation maybe too
complex, maybe needs overhaul to dtc. I'm just sharing the idea to
see what others think about it. ;)
- Leo
On 9/28/06, Dan Malek <dan@embeddedalley.com> wrote:
>
> On Sep 27, 2006, at 12:22 PM, Olof Johansson wrote:
>
> > Yes, also called "board port hell".
>
> I tend to think people skilled to do a board port
> will still create something elegant and functional
> given whatever the existing model.
>
> > .... So you can boot the same kernel binary on
> > several boards, as long as the drivers are built in and the correct
> > device tree is used. Has everyone missed/forgotten that objective
> > completely?
>
> That was never an objective when we started, although
> it seems some people involved in the implementation
> think it's the only objective. It just happens to be a side
> effect when convenient.
>
> If you could look back over the eight or more years
> of embedded Linux development with PowerPC, this
> discussion of supporting multiple boards with
> single binaries has occurred. In all cases, we never
> considered it a requirement, there are many others
> more important in embedded systems. Our greatest
> concern was sharing code among all platforms, but
> in a way we could still configure the most compact
> and highest performance code for a particular
> processor and board.
>
> Although processors are faster and memory is larger
> today, embedded systems are still trying to do more with
> less. We still try to run the slowest processor speed to
> conserve power and meet environmental requirements.
> Memory still costs money, and designs try to use the
> minimum amount to be cost competitive. IMHO, the same
> requirements for compact and efficient code are just
> as important today as they were when we had the first
> discussion years ago. Conversion of the information,
> kernel code just hanging around in case it may be used
> on some board but not another and reliance on a
> particular version of boot code are things we have
> always tried to avoid. We are competing against other
> processor architectures that are more compact and
> resource friendly, it would be nice to not lose in
> those product designs.
>
> > The device tree describes the system, not how to program it. I think
> > that's where the confusion might be.
>
> There is no confusion. This device tree discussion was started
> several years ago by a couple of us trying to find a way to better
> describe the wide variety of PowerPC SOC processor peripheral
> variants. Kumar and I had many discussions about this, since
> my old static internal memory maps weren't going to work well.
> The IBM microelectronics folks were also looking for something
> similar. We thought a _simple_ flat device tree along with
> the platform data would be sufficient to define this internal
> peripheral mapping. I wasn't too keen on the idea, but didn't
> have the time to provide any alternative implementation
> against the Freescale coding machine :-)
>
> Now, we have something that is way more complex than
> we initially thought was necessary, trying to describe nearly
> everything addressable in the system instead of just the
> internal memory map. I suspect the software to attain
> (IMHO the useless) goal of a single binary for multiple
> boards will create exponentially complex software,
> something that highly reliable embedded systems
> are trying to avoid.
>
> > I.e. create a generic "board-controller" device node, and put a
> > suitable "compatible" property in there, so the right board controller
> > driver can be chosen based on it. Having the address of the controller
> > in there helps too, especially if there are two boards out there with
> > the same controller but at different memory location.
>
> What value does this provide to my client trying
> to create a cost effective wireless home networking
> device? It certainly doesn't make the board port
> from hell any easier, since cramming the software
> into 4M of flash will likely cause the choice of a
> processor other than PowerPC that can configure
> a smaller kernel and use a tiny custom piece of
> boot code. Highly configurable development/evaluation
> boards running a single binary aren't high volume
> products, and the additional resources required
> by such software could ensure real products aren't
> developed with PPCs. We need to be sensitive
> to this.
>
> Thanks.
>
> -- Dan
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: Linux not booting consistantly
From: Muruga Ganapathy @ 2006-09-30 15:38 UTC (permalink / raw)
To: Jeff Stevens, Stefan Roese, linuxppc-embedded
I would like to suggest to check the (quality of) clocks to memory
under
a. normal condition ( before loading the linux)
b. during the linux booting
Usually the clock needs to be buffered if it needs to drive
more memory chips ( banks).
Another suggestion is to increase the cas latency to a higher
value in the memory controller. ( say from 2 to 2.5 or to a higher
values.
Also there are configuration registers to introduce wait states to
memory read and write cycles. So you may want to introduce more wait
states by programming the memory controller register.
Thanks
G.Muruganandam
> I have been working with the hardware guys trying to
> find any issues with the memory, and we haven't seen
> anything yet, and we have talked to AMCC, and they
> said they couldn't see anything wrong with the
> hardware. I did do a post-mordum dump of the log
> buffer, and this is what I get:
>
> 001e40c4: 3c353e4c 696e7578 20766572 73696f6e
> <5>Linux version
> 001e40d4: 20322e36 2e313520 28726f6f 74406c6f
> 2.6.15 (root@lo
> 001e40e4: 63616c68 6f73742e 6c6f6361 6c646f6d
> calhost.localdom
> 001e40f4: 61696e29 20286763 63207665 7273696f ain)
> (gcc versio
> 001e4104: 6e20342e 302e3020 2844454e 5820454c n
> 4.0.0 (DENX EL
> 001e4114: 444b2034 2e302034 2e302e30 29292023 DK
> 4.0 4.0.0)) #
> 001e4124: 38205475 65205365 70203236 2031373a 8 Tue
> Sep 26 17:
> 001e4134: 34393a31 33204544 54203230 30360a3c 49:13
> EDT 2006.<
> 001e4144: 343e4a4a 533a2057 41532048 4552454a
> 4>JJS: WAS HEREJ
> 001e4154: 4a53324a 4a53334a 4a53335f 314a4a53
> JS2JJS3JJS3_1JJS
> 001e4164: 345f4a4a 53345f31 5f4a4a53 345f325f
> 4_JJS4_1_JJS4_2_
> 001e4174: 4a4a5334 5f335f4a 4a53345f 00000000
> JJS4_3_JJS4_....
> 001e4184: 00000000 00000000 ........
>
> I placed a few printks in arch/ppc/kernel/start.c and
> found that it crashed right after do_init_bootmem(),
> right after placing the first character of "_JJS4_1".
>
> printk("JJS3");
> parse_early_param();
> printk("JJS3_1");
> for (i = 0; i < 1000000; i++)
> {
> if (i > 999999)
> {
> break;
> }
> }
>
> printk("JJS4");
> /* set up the bootmem stuff with available
> memory */
> do_init_bootmem();
> printk("_JJS4_1");
> if ( ppc_md.progress )
> ppc_md.progress("setup_arch: bootmem", 0x3eab);
> printk("_JJS4_2");
>
>
> When it does decide to work, most of the time it gets
> through the whole kernel and everything runs fine,
> though I have seen it hang after probing for PCI
> devices a couple of times. This looks like it is a
> memory issue, but I don't know what else to try. Does
> anyone have any ideas? I would appreciate any input.
>
> Thanks,
> Jeff Stevens
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
*************************************************************
GDA Technologies, Inc.
1010 Rincon Circle
San Jose CA, 95131
Phone (408) 432-3090
Fax (408) 432-3091
Accelerate Your Innovation
**************************************************************
=====
This message contains information from GDA Technologies Inc and
affiliates, and is intended for the sole use of the individual and
entity to whom it is addressed. It may contain information, including
any attachments, that is privileged, confidential and exempt from
disclosure under applicable law. If you are not the intended addressee,
nor authorized to receive for the intended addressee, you are hereby
notified that you may not use, copy, disclose or distribute to anyone
the message or any information contained in the message. If you have
received this electronic transmission in error, please notify the
sender immediately by a "reply to sender only" message and destroy all
electronic and hard copies of the communication, including attachments.
====
^ 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