The iSeries HV only needs the first two fields of the paca statically
initialised, so create an alternate paca that contains only those and
switch to our real paca immediately after boot.
This is in order to make the 1024 cpu patches easier since they will no
longer have to statically initialise t
On Apr 9, 2008, at 11:24 PM, Stephen Rothwell wrote:
On Wed, 9 Apr 2008 22:11:38 -0500 Kumar Gala <[EMAIL PROTECTED]
> wrote:
Yeah the are mpc85xx_defconfig and mpc83xx_defconfig.
So should we add mpc83xx_defconfig to the kisskb builds and remove
mpc885_ads_defconfig (we already do a mpc85xx
Hi Jon,
On Saturday 12 January 2008 03:47, Jon Smirl wrote:
> Convert pfc8563 i2c driver from old style to new style. The
> driver is also modified to support device tree names via the
> i2c mod alias mechanism.
The patch breaks the pfc8563 driver.
The old style driver allocated memory for a pcf
Scott Wood schrieb:
Andre Schwarz wrote:
Scott Wood schrieb:
Andre Schwarz wrote:
-> find_legacy_serial_port()
stdout is /[EMAIL PROTECTED]/[EMAIL PROTECTED]
It looks like you have some memory corruption between here...
clocksource: timebase mult[3c1] shift[22] registered
!!!
[POWERPC] Clean up some linker and symbol usage
No comments. Straight forward patch.
Well, it is changing behaviour. In particular, klimit is not
necessarily the same as _end. It starts out initialized to &_end but
then gets advanced by some allocations very early in the boot IIRC.
It might
On Thursday 10 April 2008, Benjamin Herrenschmidt wrote:
> On Wed, 2008-04-02 at 17:12 +0200, Stefan Roese wrote:
>
>../..
>
> Overall looks good, just a few things:
Ben, thanks for the review.
> In general, while I have nothing against the idea of reading the HW
> setup left by uboot, I wond
Hi,
I'm porting vanilla 2.6.25-rc8 (arch=powerpc) to a new board. UART is
already working in the kernel and Uboot with UART and ethernet is also
working.
But I can't get the emac driver (ibm_newemac) working under Linux.
On boot emac_init get's called and exits normally, but no probe or
open will g
On Wed, Apr 09, 2008 at 12:39:48PM -0500, Scott Wood wrote:
> Sascha Hauer wrote:
>> Right, so it's probably not worth the effort. I stumbled on this while
>> porting my board to the new binding code. I was quite confused when
>> seeing this so I made this fix to understand what's going on here.
>>
* Updated the phys_addr_t patch to be a bit cleaner
* reworked order of patches a bit (bootwrapper now second to last)
* added patch to properly set physical address of PHDR
* reverted change in prom.c to use PHYSICAL_START & klimit for lmb_reserve
These patches exist in the following git tree:
Nothing appears to use BOOT_LOAD so remove it as a configurable option.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
arch/powerpc/Kconfig | 16
1 files changed, 0 insertions(+), 16 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 625342e..c12111
There does not appear to be any reason that we shouldn't just have
-Iarch/$(ARCH) on both ppc32 and ppc64 builds.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
arch/powerpc/Makefile | 10 --
1 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/Makefile b/arch/
A number of users of PPC_MEMSTART (40x, ppc_mmu_32) can just always use
0 as we don't support booting these kernels at non-zero physical addresses
since their exception vectors must be at 0 (or 0xfffx_).
For the sub-arches that support relocatable interrupt vectors (book-e) its
reasonable to h
total_lowmem represents the amount of low memory not the physical address
that low memory ends at. If the start of memory is at 0 it happends that
total_lowmem can be used as both the size and the address that lowmem
ends at. (technical its one byte beyond the end)
To make the code a bit more cle
* Determine the RPN we are running the kernel at runtime rather
than using compile time constant for initial TLB
* Cleanup adjust_total_lowmem() to respect memstart_addr and
be a bit more clear on variables that are sizes vs addresses.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
arch/p
Now that we have a proper variable that is the address of the top
of low memory we can use it to limit the lmb allocations.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
include/asm-powerpc/lmb.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/asm-powerpc/l
We always use __initial_memory_limit as an address so rename it
to be clear.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
arch/powerpc/mm/fsl_booke_mmu.c |2 +-
arch/powerpc/mm/init_32.c | 10 +-
arch/powerpc/mm/mmu_decl.h |2 +-
arch/powerpc/mm/ppc_mmu_32.c|
* PAGE_OFFSET is not always the start of code, use _stext instead.
* grab PAGE_SIZE and KERNELBASE from asm/page.h like ppc64 does. Makes the
code a bit more common and provide a single place to manipulate the
defines for things like kdump.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
a
On Wed, 2008-04-02 at 17:12 +0200, Stefan Roese wrote:
../..
Overall looks good, just a few things:
In general, while I have nothing against the idea of reading the HW
setup left by uboot, I wonder if it wouldn't be best to have this file
capable of fully configuring it in either mode based
Signed-off-by: Laurent Pinchart <[EMAIL PROTECTED]>
---
include/asm-powerpc/cpm.h | 14 ++
include/asm-powerpc/cpm1.h | 13 -
include/asm-powerpc/cpm2.h | 11 +--
3 files changed, 15 insertions(+), 23 deletions(-)
diff --git a/include/asm-powerpc/cpm.h b/in
Moved phys_addr_t out of mmu-*.h and into asm/types.h so we can use it in
places that before would have caused recursive includes.
For example to use phys_addr_t in we would have included
which would have possibly included which
includes . Wh recursive include.
CONFIG_PHYS_64BIT is a bit
Now that we properly set the physical address in the program header of the
vmlinux ELF we can extract it to properly set the load and entry point for
u-boot uImages. Before we always hard coded the laod & entry point to 0.
However there are situations that the kernel may be built with a non-zero
p
We can set LOAD_OFFSET and use the AT attribute on sections and the
linker will properly set the physical address of the LOAD program
header for us.
This allows us to know how the PHYSICAL_START the user configured a
kernel with by just looking at the resulting vmlinux ELF.
This is pretty much st
Added support to allow an 85xx kernel to be run from a non-zero physical
address (useful for cooperative asymmetric multiprocessing situations) and
kdump. The support can either be at compile time or runtime
(CONFIG_RELOCATABLE).
Currently we are limited to running at a physical address that is m
On Apr 9, 2008, at 9:25 PM, Paul Mackerras wrote:
Kumar Gala writes:
So now we can look at the vmlinux and determine the physical offset.
The question is how best to do that. Here are the options I see:
* readelf, grep and parse output
* objdump grep and parse output
* simple C program that r
On Thu, Apr 10, 2008 at 07:03:22AM +1000, Benjamin Herrenschmidt wrote:
> I don't think there's any difference between the _ONSTACK variant
> and the normal one without lockdep, is there ?
No there's not. Thus it's a guaranteed no-op and can easily go in.
Hi Sylvain,
Last year you have posted a MPC5200 PSC AC97 driver patch
"[PATCH 9/9] sound: Add support for Freescale MPC5200 AC97 interface."
with the following comment:
> Not quite a clean driver, but it get things done (well, mostly).
> Only included to be able to test functionalityi/usage of
>
Paul Mackerras <[EMAIL PROTECTED]> wrote:
> The following patches have been added to the master and powerpc-next
> branches of the powerpc.git repository. There is a bunch that I
Paul-san,
Could you apply my "take 2" patchset?
[PATCH 0/11] celleb: patchset for 2.6.26 (take 2)
http://ozlabs.org/
Hi Kumar,
On Thu, 10 Apr 2008 03:51:42 -0500 Kumar Gala <[EMAIL PROTECTED]> wrote:
>
> We should probably add mpc83xx_defconfig to kisskb. However,
> mpc885_ads_defconfig is an 8xx (extreme low end) and mpc85xx_defconfig
> (higher end) cover two different processor families so we shouldn't
On Thursday 10 April 2008, M B wrote:
> I'm porting vanilla 2.6.25-rc8 (arch=powerpc) to a new board. UART is
> already working in the kernel and Uboot with UART and ethernet is also
> working.
> But I can't get the emac driver (ibm_newemac) working under Linux.
> On boot emac_init get's called and
On Thu, 2008-04-10 at 12:21 +0200, Stefan Roese wrote:
>
> Sure, this would be optimal. But frankly, I currently have no need for
> this
> non U-Boot mode, and therefore I didn't implement it. This can be
> added later
> when really needed don't you think?
It can... but on the other hand, it's
Hi Paul,
could you please add the following patches ?
[PATCHv4 1/5] cpm_uart: Allocate DPRAM memory for SMC ports on CPM2-based
platforms.
http://ozlabs.org/pipermail/linuxppc-dev/2008-April/053858.html
[PATCHv4 2/5] powerpc: Add bootwrapper function to get virtual reg from the
device tree.
ht
On Thu, 10 Apr 2008 12:37:45 +0200
"M B" <[EMAIL PROTECTED]> wrote:
> Hi,
> I'm porting vanilla 2.6.25-rc8 (arch=powerpc) to a new board. UART is
> already working in the kernel and Uboot with UART and ethernet is also
> working.
> But I can't get the emac driver (ibm_newemac) working under Linux.
On Tue, 08 Apr 2008 11:49:14 -0500
Jerone Young <[EMAIL PROTECTED]> wrote:
> 2 files changed, 77 insertions(+), 1 deletion(-)
> arch/powerpc/platforms/44x/Makefile |2
> arch/powerpc/platforms/44x/idle.c | 76 +++
>
>
> Updates: Now setting MSR_WE is now de
On Mon, 07 Apr 2008 15:53:31 -0500
Hollis Blanchard <[EMAIL PROTECTED]> wrote:
> Implement initial support for KVM for PowerPC 440. There are just two small
> prerequisite patches, and then the bulk of the code can't be split easily.
>
> Please review; I would like to submit these for 2.6.26. The
On Thursday 10 April 2008, Benjamin Herrenschmidt wrote:
> On Thu, 2008-04-10 at 12:21 +0200, Stefan Roese wrote:
> > Sure, this would be optimal. But frankly, I currently have no need for
> > this
> > non U-Boot mode, and therefore I didn't implement it. This can be
> > added later
> > when really
On Thu, 2008-04-10 at 12:56 +0200, Christoph Hellwig wrote:
> On Thu, Apr 10, 2008 at 07:03:22AM +1000, Benjamin Herrenschmidt wrote:
> > I don't think there's any difference between the _ONSTACK variant
> > and the normal one without lockdep, is there ?
>
> No there's not. Thus it's a guarantee
On Thu, 2008-04-10 at 13:59 +0200, Stefan Roese wrote:
> Understood. But for this "dynamic" root-complex/endpoint configuration as
> implemented with the current version of the patch, I can't change the PCIe
> node in the dts from root-complex mode to endpoint mode, since I would loose
> root-c
Laurent Pinchart writes:
> could you please add the following patches ?
Sure, if Kumar acks them, since they are all 8xxx-related as far as I
can see (with the exception of the part of 2/5 that adds the new
dt_get_virtual_reg function). Or Kumar can put them in his tree.
Paul.
_
On Thu, Apr 10, 2008 at 1:52 PM, Josh Boyer <[EMAIL PROTECTED]> wrote:
> You have to call of_platform_bus_probe with the various bus types for
> your board. See the top few functions of:
>
> arch/powerpc/platforms/40x/walnut.c
Well I did this, but I made a typo (plb4 instead of plb3).
So than
On Thursday 10 April 2008, Benjamin Herrenschmidt wrote:
> > Understood. But for this "dynamic" root-complex/endpoint configuration as
> > implemented with the current version of the patch, I can't change the
> > PCIe node in the dts from root-complex mode to endpoint mode, since I
> > would loose
On Thu, Apr 10, 2008 at 12:44:43PM +0200, Marian Balakowicz wrote:
> Last year you have posted a MPC5200 PSC AC97 driver patch
> "[PATCH 9/9] sound: Add support for Freescale MPC5200 AC97 interface."
> with the following comment:
>
> > Not quite a clean driver, but it get things done (well, mostly)
On Tuesday 08 April 2008, Jerone Young wrote:
> +static struct sleep_mode modes[] = {
> + { .name = "wait", .entry = &ppc44x_idle },
> + { .name = "spin", .entry = NULL },
> +};
> +
> +int __init ppc44x_idle_init(void)
> +{
> + void *func = modes[current_mode].entry;
> + ppc
Laurent,
The cpm/82xx ones should go via me.
- k
On Apr 10, 2008, at 6:46 AM, Laurent Pinchart wrote:
Hi Paul,
could you please add the following patches ?
[PATCHv4 1/5] cpm_uart: Allocate DPRAM memory for SMC ports on CPM2-
based
platforms.
http://ozlabs.org/pipermail/linuxppc-dev/2008-Ap
On Apr 10, 2008, at 7:32 AM, Paul Mackerras wrote:
Laurent Pinchart writes:
could you please add the following patches ?
Sure, if Kumar acks them, since they are all 8xxx-related as far as I
can see (with the exception of the part of 2/5 that adds the new
dt_get_virtual_reg function). Or Ku
Hi Kumar,
On Thursday 10 April 2008 16:10, Kumar Gala wrote:
> Laurent,
>
> The cpm/82xx ones should go via me.
Sorry, I didn't know that. I'll e-mail you directly next time.
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2
Guy's
if you have work you want in 2.6.26 related to Freescale PPC's let me
know. Ideally you can provide links to the patches in http://patchwork.ozlabs.org/linuxppc/
thanks
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs
On Thursday 10 April 2008 16:11, Kumar Gala wrote:
>
> On Apr 10, 2008, at 7:32 AM, Paul Mackerras wrote:
> > Laurent Pinchart writes:
> >
> >> could you please add the following patches ?
> >
> > Sure, if Kumar acks them, since they are all 8xxx-related as far as I
> > can see (with the exception
On Mon, 07 Apr 2008 15:53:32 -0500
Hollis Blanchard <[EMAIL PROTECTED]> wrote:
> 1 file changed, 2 insertions(+)
> include/asm-powerpc/mmu-44x.h |2 ++
>
>
> PowerPC 440 KVM needs to know how many TLB entries are used for the host
> kernel
> linear mapping (it does not modify these mappings
On Thursday 10 April 2008 06:55:18 Josh Boyer wrote:
> On Mon, 07 Apr 2008 15:53:31 -0500
>
> Hollis Blanchard <[EMAIL PROTECTED]> wrote:
> > Implement initial support for KVM for PowerPC 440. There are just two
> > small prerequisite patches, and then the bulk of the code can't be split
> > easily
On Apr 10, 2008, at 9:28 AM, Laurent Pinchart wrote:
On Thursday 10 April 2008 16:11, Kumar Gala wrote:
On Apr 10, 2008, at 7:32 AM, Paul Mackerras wrote:
Laurent Pinchart writes:
could you please add the following patches ?
Sure, if Kumar acks them, since they are all 8xxx-related as far
On Apr 10, 2008, at 6:46 AM, Laurent Pinchart wrote:
Hi Paul,
could you please add the following patches ?
[PATCHv4 1/5] cpm_uart: Allocate DPRAM memory for SMC ports on CPM2-
based
platforms.
http://ozlabs.org/pipermail/linuxppc-dev/2008-April/053858.html
[PATCHv4 2/5] powerpc: Add bootwra
anyone looking into this?
http://kisskb.ellerman.id.au/kisskb/buildresult/23299/
Its really a Kconfig issue.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
On Apr 1, 2008, at 7:33 AM, Laurent Pinchart wrote:
Hi everybody,
these 5 patches reset the CPM in cpm2_reset() and fix the cpm_uart
driver to
initialise SMC ports correctly without relying on any initialisation
performed by the boot loader/wrapper. They update the boot wrapper
code and
t
On Thursday 10 April 2008 16:21, Kumar Gala wrote:
> Guy's
>
> if you have work you want in 2.6.26 related to Freescale PPC's let me
> know. Ideally you can provide links to the patches in
> http://patchwork.ozlabs.org/linuxppc/
Could you please add this one ?
fs_enet: Don't call NAPI functi
I have a copy of the driver I hacked to work with the new PSC framework
but it doesn't "work" anymore - I have no idea why.
Mail me privately if you want it, I have no time to make patches or
look for a good reason for the breakages, but it compiles at least.
The Efika hack should be gone now (ir
On Apr 3, 2008, at 11:46 AM, Randy Vinson wrote:
When steal_context is used on SMP systems, it can steal a context in
use by one of the other processors. This patch adds context tracking
to
prevent this as suggested by BenH.
Can we be more descriptive in the problem/bug symptom in the
des
On Apr 10, 2008, at 10:20 AM, Laurent Pinchart wrote:
On Thursday 10 April 2008 16:21, Kumar Gala wrote:
Guy's
if you have work you want in 2.6.26 related to Freescale PPC's let me
know. Ideally you can provide links to the patches in
http://patchwork.ozlabs.org/linuxppc/
Could you please a
Hi everybody,
I need to pass a limited amount of information from the boot loader to the
Linux kernel, such as the boot mode chosen by the user or the last boot
reason (power up, reset, watchdog, ...).
What is the best way to pass that kind of information from the boot loader to
the kernel ? S
On Thu, Apr 10, 2008 at 9:50 AM, Laurent Pinchart
<[EMAIL PROTECTED]> wrote:
> Hi everybody,
>
> I need to pass a limited amount of information from the boot loader to the
> Linux kernel, such as the boot mode chosen by the user or the last boot
> reason (power up, reset, watchdog, ...).
>
> Wh
Sascha Hauer wrote:
See bottom of this mail. The board really is a 8260 based board. Our
bootloader does not fill in the clock values, so they are hardcoded. I'm
not very sure about the muram entries because the dpram is organized
slightly different on the 8260. It has some dedicated FCC space an
On Tue, 8 Apr 2008 13:54:41 +1000
David Gibson <[EMAIL PROTECTED]> wrote:
> On Mon, Apr 07, 2008 at 10:25:32PM -0500, Hollis Blanchard wrote:
> > On Monday 07 April 2008 20:11:28 David Gibson wrote:
> > > On Mon, Apr 07, 2008 at 03:53:33PM -0500, Hollis Blanchard wrote:
> > > > 1 file changed, 7 i
Hello, I wrote:
Those functions are going to break on 32-bit platforms with
extended physical address (well, that's starting with Pentiums which
had 36-bit PAE :-) AND devices mapped beyond 4 GB (e.g. PowerPC
44x). You should have used resource_size_t for the 'offset'
parameter. As this m
On Apr 10, 2008, at 10:50 AM, Laurent Pinchart wrote:
Hi everybody,
I need to pass a limited amount of information from the boot loader
to the
Linux kernel, such as the boot mode chosen by the user or the last
boot
reason (power up, reset, watchdog, ...).
What is the best way to pass that
On Apr 10, 2008, at 11:56 AM, Sergei Shtylyov wrote:
Hello, I wrote:
Those functions are going to break on 32-bit platforms with
extended physical address (well, that's starting with Pentiums
which had 36-bit PAE :-) AND devices mapped beyond 4 GB (e.g.
PowerPC 44x). You should have us
On Wed, 9 Apr 2008 13:50:43 -0600
"Grant Likely" <[EMAIL PROTECTED]> wrote:
> On Wed, Apr 9, 2008 at 12:00 PM, John Bonesio <[EMAIL PROTECTED]> wrote:
> > I understand that many people are using a bootloader that already sets up
> > the
> > cache for the kernel, but I'm wondering if Xilinx board
Kumar Gala wrote:
Those functions are going to break on 32-bit platforms with
extended physical address (well, that's starting with Pentiums
which had 36-bit PAE :-) AND devices mapped beyond 4 GB (e.g.
PowerPC 44x). You should have used resource_size_t for the
'offset' parameter. As t
On Apr 10, 2008, at 1:24 PM, Sergei Shtylyov wrote:
Kumar Gala wrote:
Those functions are going to break on 32-bit platforms with
extended physical address (well, that's starting with Pentiums
which had 36-bit PAE :-) AND devices mapped beyond 4 GB (e.g.
PowerPC 44x). You should have
On Thu, 2008-04-10 at 15:44 +0200, Arnd Bergmann wrote:
> On Tuesday 08 April 2008, Jerone Young wrote:
> > +static struct sleep_mode modes[] = {
> > + { .name = "wait", .entry = &ppc44x_idle },
> > + { .name = "spin", .entry = NULL },
> > +};
> > +
> > +int __init ppc44x_idle_init(void
The kconfig entry can go away once arch/ppc and references to the config in
drivers are removed.
Signed-off-by: Scott Wood <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/82xx/Kconfig |3 -
arch/powerpc/platforms/85xx/Kconfig |8 -
arch/powerpc/platforms/8xx/Kconfig |4 -
arch/powerpc
> +#ifndef thread_info_cache_init
> +#define thread_info_cache_init do { } while(0)
> +#endif
> +
Blah ! Missing a pair of () here. Ooops. I'll send a fixed patch.
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/ma
On Thu, 2008-04-10 at 15:37 +0200, Stefan Roese wrote:
>
> Now I have to re-check to see what you really have in mind. Do you think
> about
> creating two different PCIe nodes, one for root-complex and one for endpoint
> functionality? Or is your idea to add a property to the existing PCIe
>
From: Laurent Pinchart <[EMAIL PROTECTED]>
Date: Thu, 10 Apr 2008 17:20:36 +0200
> On Thursday 10 April 2008 16:21, Kumar Gala wrote:
> > Guy's
> >
> > if you have work you want in 2.6.26 related to Freescale PPC's let me
> > know. Ideally you can provide links to the patches in
> > http://pat
Please use [EMAIL PROTECTED] for patch and development
discussion, linux-net is for user discussions only.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
On Thu, 2008-04-10 at 15:16 -0700, David Miller wrote:
> From: Laurent Pinchart <[EMAIL PROTECTED]>
> Date: Thu, 10 Apr 2008 17:20:36 +0200
>
> > On Thursday 10 April 2008 16:21, Kumar Gala wrote:
> > > Guy's
> > >
> > > if you have work you want in 2.6.26 related to Freescale PPC's let me
> >
The following patches add support for the Wind River SBC8641D board.
I've done it by starting with the current mpc8641_hpcn support and
then making the changes from there, so it should be 1:1 comparable
with the HPCN platform, which aids in tracking/applying future changes.
The SBC8641D support e
This adds support for the Wind River SBC8641D board, based
largely on the mpc86xx_hpcn support. The biggest difference is
the lack of the Uli and the i8259 cascade, which simplifies things.
Signed-off-by: Paul Gortmaker <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/86xx/Kconfig|8 ++-
a
This adds in the device tree source for the SBC8641D, based
largely on the mpc8641_hpcn.dts. The biggest differences are
the lack of a complex IRQ mapping (since no Uli/i8259 cascade)
and the different layout of devices on the localbus node.
Signed-off-by: Paul Gortmaker <[EMAIL PROTECTED]>
---
This adds a sample defconfig for the Wind River SBC8641D
board, with SMP, PCI and NFS root enabled.
Signed-off-by: Paul Gortmaker <[EMAIL PROTECTED]>
---
arch/powerpc/configs/sbc8641d_defconfig | 1342 +++
1 files changed, 1342 insertions(+), 0 deletions(-)
create mod
The gianfar priv struct has an entry for the mii_bus, but it
isn't being populated. Assign a value for it at the same time
as we assign the phydev, so that it can be used in calls like
gianfar_mdio_read/write.
Signed-off-by: Paul Gortmaker <[EMAIL PROTECTED]>
---
drivers/net/gianfar.c |1 +
I've tested on 8360, 8540 and 8641D and in all cases, the PHY
ID returned for bus addr 0x1f is all zeros, and not all 0xf.
This means we've been allocating a phydev for this "ghost".
In addition to marking 0x0 as an invalid PHY ID, I've also
changed the existing somewhat useless printk to actually
The gfar was previously using the mii_bus->priv to directly
store the gfar_mii regs, which leaves no room/flexibility to
store anything else there. I believe it makes more sense to
have mii_bus->priv point at a struct gianfar_mdio_data and
then have the regs stored as a field within that. It make
The gfar_local_mdio_read/write functions were brought in via
extern since they go right at the regs vs. going via the normal
gfar_mdio_read/write functions. With the priv->mii_bus properly
set, we can get rid of the externs, the casts etc. and use the
normal gfar_mdio_read/write. We just need to m
Currently the MDIO address for the gianfar Ten Bit
Interface is hard coded to be 0x1f, which can conflit
with some boards if they happen to put a PHY there.
Previous discussions indicated that the proper approach
here would be to dynamically allocate it, based on
picking the highest MDIO address t
On Apr 10, 2008, at 12:51, Paul Gortmaker wrote:
This patch series consists of some minor cleanups that eventually
allow us to implement a dynamic assignment of the gianfar TBIPA.
This was the implementation that Andy and Scott indicated was
the most desireable solution at the bottom of this d
TBIPA needs to be set to a value (on connected MDIO buses) that doesn't
conflict with PHYs on the bus. By hardcoding it to 0x1f, we were preventing
boards with PHYs at 0x1f from working properly. Instead, scan the bus when
it comes up, and find an address that doesn't have a PHY on it. The TBI P
Some architecture need to maintain a kmem cache for thread info
structures. (next patch adds that to powerpc to fix an alignment
problem).
There is no good arch callback to use to initialize that cache
that I can find, so this adds a new one and adds an empty macro
for when it's not implemented.
The powerpc kernel stacks need to be naturally aligned, as they
contain the thread info at the bottom, which is obtained by
clearing the low bits of the stack pointer.
However, when using 64K pages (the stack is smaller than a page),
we use kmalloc to allocate it, which doesn't provide that guaran
This patch series consists of some minor cleanups that eventually
allow us to implement a dynamic assignment of the gianfar TBIPA.
This was the implementation that Andy and Scott indicated was
the most desireable solution at the bottom of this discussion:
http://patchwork.ozlabs.org/linuxppc-embe
On Apr 10, 2008, at 3:45 PM, Scott Wood wrote:
The kconfig entry can go away once arch/ppc and references to the
config in
drivers are removed.
just to be clear. arch/powerpc will always just use the new binding
and arch/ppc uses the old (or has the option)?
- k
Hi Paul,
Just a couple of comments.
On Thu, 10 Apr 2008 19:22:17 -0400 Paul Gortmaker <[EMAIL PROTECTED]> wrote:
>
> +++ b/arch/powerpc/platforms/86xx/sbc8641d.c
> +#undef DEBUG
> +
> +#ifdef DEBUG
> +#define DBG(fmt...) do { printk(KERN_ERR fmt); } while(0)
^^^
On Thursday 10 April 2008, Jerone Young wrote:
> Well it could be this simple. But the current code leaves a lot more
> room to add different type waits or spins if need be (if they are ever
> needed ... though none off the top of my head at the moment)...but it
> does allow you to create another w
On Fri, 2008-04-11 at 10:05 +1000, Stephen Rothwell wrote:
> Hi Paul,
>
> Just a couple of comments.
>
> On Thu, 10 Apr 2008 19:22:17 -0400 Paul Gortmaker <[EMAIL PROTECTED]> wrote:
> >
> > +++ b/arch/powerpc/platforms/86xx/sbc8641d.c
> > +#undef DEBUG
> > +
> > +#ifdef DEBUG
> > +#define DBG(fmt
On Fri, 2008-04-11 at 02:18 +0200, Arnd Bergmann wrote:
> > > static int __init idle_param(char *p)
> > > {
> > > if (!strcmp(modes[i].name, "spin"))
> > > ppc_md.power_save = NULL;
> > > }
> > > early_param("idle", idle_param);
> > >
> > > if you statically initialize the ppc_
The allyesconfig (among others) build was giving this:
In file included from include/linux/gfp.h:4,
from include/linux/slab.h:14,
from include/linux/percpu.h:5,
from include2/asm/time.h:18,
from include2/asm/cputime.h:26,
Hi Kumar,
On Thu, 10 Apr 2008 10:01:27 -0500 Kumar Gala <[EMAIL PROTECTED]> wrote:
>
> anyone looking into this?
>
> http://kisskb.ellerman.id.au/kisskb/buildresult/23299/
>
> Its really a Kconfig issue.
Just posted a patch.
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
htt
> This crashes my powerpc mac g5.
It worked fine on mine.
> It happens after the boot, during the first login-over-ssh.
Mine did lots of stuff fine.
> This is with most of the rest of the -mm poopile applied. i386 and x86_64
> seem OK.
I had only tested with Linus's tree plus the small handfu
On Thu, Apr 10, 2008 at 07:22:17PM -0400, Paul Gortmaker wrote:
> This adds support for the Wind River SBC8641D board, based
> largely on the mpc86xx_hpcn support. The biggest difference is
> the lack of the Uli and the i8259 cascade, which simplifies things.
Hi Paul,
A couple issues. (These sh
On Thu, 10 Apr 2008 18:36:35 -0700 (PDT) Roland McGrath <[EMAIL PROTECTED]>
wrote:
> > This crashes my powerpc mac g5.
>
> It worked fine on mine.
>
> > It happens after the boot, during the first login-over-ssh.
>
> Mine did lots of stuff fine.
>
> > This is with most of the rest of the -mm
Kumar Gala wrote:
but there is no reason not to make it work properly. For example I
believe libata uses devm_* and the fsl SATA driver (non-PCI) will
need to work in cases similar to the 44x.
Well, as for sata_fsl, it calls of_iomap() which does The Right Thing.
Fair, but I don't see w
In message: Re: [PATCH 0/5] dynamic detection of gianfar TPIPA
on 10/04/2008 Andy Fleming wrote:
>
> I may be missing something, but I don't think this quite right.
>
> If you have a PHY at 0x1f, this patchset will cause no PHY device to be
> allocated for that address, and you'll actually end up
1 - 100 of 102 matches
Mail list logo
