On Tue, Apr 22, 2008 at 01:50:05PM +1000, Stephen Rothwell wrote:
> Hi Tony,
>
> On Tue, 22 Apr 2008 13:30:06 +1000 (EST) Tony Breeds <[EMAIL PROTECTED]>
> wrote:
> >
> > +void __init initialise_pacas(void)
> > +{
> > + int cpu;
> > + unsigned long kernel_toc = (unsigned long)(&__toc_start) +
On Monday 21 April 2008, Benjamin Herrenschmidt wrote:
> On Mon, 2008-04-21 at 16:54 +0200, Stefan Roese wrote:
> > --
> > - As suggested by Benjamin Herrenschmidt, don't determine endpoint mode
> > by looking at the already configured PCIe port state, but evaluate
> > the device_ty
> -Original Message-
> From: Michael Ellerman [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, April 22, 2008 12:35 PM
> To: Jin Zhengxiong
> Cc: linuxppc-dev list; Gala Kumar
> Subject: RE: [PATCH 1/3] MSI driver for Freescale 83xx/85xx/86xx cpu
>
> On Mon, 2008-04-21 at 18:01 +0800, Jin Zh
On Tuesday 22 April 2008, Benjamin Herrenschmidt wrote:
> On Sat, 2008-02-23 at 08:27 +1100, Benjamin Herrenschmidt wrote:
> > On Fri, 2008-02-22 at 09:32 +0100, Stefan Roese wrote:
> > > 405EX(r) has SDR0_MFR[E0CS/E1CS] set after reset. This selects
> > > the internal loopback mode. Clear these bi
On Mon, 2008-04-21 at 18:01 +0800, Jin Zhengxiong wrote:
> Hi, Michael,
>
> Thank you very much for you input, please see my inline answer.
No worries.
> > > +static int fsl_msi_reserve_dt_hwirqs(struct fsl_msi *msi)
> > > +{
> > > + int i, len;
> > > + const u32 *p;
> > > +
> > > + p = of_get_p
Hi Tony,
On Tue, 22 Apr 2008 13:30:06 +1000 (EST) Tony Breeds <[EMAIL PROTECTED]> wrote:
>
> Currently all iSeries secondary CPU's spin directly on the cpu_start in thier
> paca. Make them spin on the global __secondary_hold_spinloop, until after the
> pacas have been initialised.
>
> Signed-off
Hi Tony,
On Tue, 22 Apr 2008 13:30:06 +1000 (EST) Tony Breeds <[EMAIL PROTECTED]> wrote:
>
> +void __init initialise_pacas(void)
> +{
> + int cpu;
> + unsigned long kernel_toc = (unsigned long)(&__toc_start) + 0x8000UL;
This line could do with a comment saying what it is doing ...
> +++
Currently all iSeries secondary CPU's spin directly on the cpu_start in thier
paca. Make them spin on the global __secondary_hold_spinloop, until after the
pacas have been initialised.
Signed-off-by: Tony Breeds <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/iseries/exception.S | 27 ++
With NR_CPUS=1024
textdata bss dec hex filename
137 1704032 0 1704169 1a00e9 arch/powerpc/kernel/paca.o :Before
121 1179744 524288 1704153 1a00d9 arch/powerpc/kernel/paca.o :After
Now that we're not staatically allocating the paca, we don't need the
NR_STATIC_PACAS #defi
As the pacas are statically initialised increasing NR_CPUS beyond 128,
means that any additional pacas will be empty ... which is bad.
This patch adds the required functionality to fill in any excess pacas
at runtime.
Signed-off-by: Tony Breeds <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/paca.c
This fixes atyfb to not truncate 64 bits resources on 32 bits
platforms. Unfortunately, there are still issues with addresses
returned to userspace via struct fb_fix_screeninfo. This will
have to be dealt with separately.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
drivers/vide
This fixes aty128fb to not truncate 64 bits resources on 32 bits
platforms. Unfortunately, there are still issues with addresses
returned to userspace via struct fb_fix_screeninfo. This will
have to be dealt with separately.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
drivers/v
This fixes radeonfb to not truncate 64 bits resources on 32 bits
platforms. Unfortunately, there are still issues with addresses
returned to userspace via struct fb_fix_screeninfo. This will
have to be dealt with separately.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
drivers/v
On Mon, Apr 21, 2008 at 11:25:29PM +0200, Segher Boessenkool wrote:
> >> The last time arch/ppc built for me (a few days ago), it got
> >> 535 warnings.
Heh.
> >> I don't think anyone would notice one more.
Well, it wouldn't be one more, it'd be one per file that includes the
header. If we cho
Commit 0119536cd314ef95553604208c25bc35581f7f0a added an assembly version
of strncmp to PowerPC. However, it changed a common header file between
arch/ppc and arch/powerpc without adding strncmp to arch/ppc. This fixes
that omission so that arch/ppc links again.
Signed-off-by: Josh Boyer <[EMAIL
Commit d04ceb3fc294ea2c4f538a04343f3a473953a3b0 moved phys_addr_t definitions
to include/asm-powerpc/types.h. However, arch/ppc 440 builds had a duplicate
definition in include/asm-ppc/mmu.h that caused the build to fail.
This removes the duplicate definition in arch/ppc.
Signed-off-by: Josh Boy
From: Valentine Barshak <[EMAIL PROTECTED]>
This patch adds ibm_newemac PHY clock workaround for 440EP/440GR EMAC
attached to a PHY which doesn't generate RX clock if there is no link.
The code is based on the previous ibm_emac driver stuff. The 440EP/440GR
allows controlling each EMAC clock separ
The following two patches fix arch/ppc 440 builds. Unless some miracle
occurs and people stop breaking arch/ppc with commits, this will likely
be the last kernel where it builds.
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs
From: Valentine Barshak <[EMAIL PROTECTED]>
The PowerPC 440GX Taishan board fails to reset EMAC3 (reset timeout error)
if there's no link. Because of that it fails to find PHY chip. The older
ibm_emac
driver had a workaround for that: the EMAC_CLK_INTERNAL/EMAC_CLK_EXTERNAL
macros,
which toggle
From: Josh Boyer <[EMAIL PROTECTED]>
Convert ibm_newemac to use the of_device_is_available function when checking
for unused/unwired EMACs. We leave the current check for an "unused" property
to maintain backwards compatibility for older device trees. Newer device
trees should simply use the sta
From: Josh Boyer <[EMAIL PROTECTED]>
This patch fixes several section mismatch warnings in the
ibm_newemac driver similar to:
WARNING: vmlinux.o(.devinit.text+0x3a04): Section mismatch in reference from
the function emac_probe() to the function .devexit.text:tah_detach()
The function __devinit e
From: Stefan Roese <[EMAIL PROTECTED]>
On some 4xx PPC's (e.g. 460EX/GT), the rx channel number is a multiple
of 8 (e.g. 8 for EMAC1, 16 for EMAC2), but enabling in MAL_RXCASR needs
the divided by 8 value for the bitmask.
Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
Signed-off-by: Benjamin Her
From: Stefan Roese <[EMAIL PROTECTED]>
This fixes the jumbo frame support on EMAC V4 systems. Now the correct
bit is set depending on the EMAC version configured.
Tested on Kilauea (405EX) and Canyonlands (460EX).
Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
Signed-off-by: Benjamin Herrenschm
Kumar Gala writes:
> > Once again I want to go through it carefully and understand how it all
> > works, and in particular understand things like the way it ensures
> > that the base address for the kmap region is aligned to a 4M boundary
> > so all the kmap ptes are in a single page (assuming it
On Sat, 2008-02-23 at 08:27 +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2008-02-22 at 09:32 +0100, Stefan Roese wrote:
> > 405EX(r) has SDR0_MFR[E0CS/E1CS] set after reset. This selects
> > the internal loopback mode. Clear these bits so that both EMACs
> > don't use loopback mode as default.
>
On Mon, Apr 21, 2008 at 12:39 PM, Scott Wood <[EMAIL PROTECTED]> wrote:
> On Mon, Apr 21, 2008 at 08:03:31AM -0600, Grant Likely wrote:
>
> > > +r) Freescale General-purpose Timers Module
> > > +
> > > +Required properties:
> > > + - compatible : should be "fsl,gtm" ("fsl,qe-gtm
On Mon, 2008-04-21 at 17:31 -0500, Kumar Gala wrote:
> Ok, but we'd also need to fix setup_750_7400_hid0 and
> setup_745x_specifics to test.
>
> There's a bit more cleanup that needs to be done here. I'm not
> going
> to worry about it for this patch since it covers handling a chip
> errat
On Apr 21, 2008, at 5:12 PM, Benjamin Herrenschmidt wrote:
On Mon, 2008-04-21 at 17:04 -0500, Kumar Gala wrote:
On Apr 21, 2008, at 4:22 PM, Benjamin Herrenschmidt wrote:
_GLOBAL(__setup_cpu_603)
- b setup_common_caches
+ mflrr4
+BEGIN_FTR_SECTION
+ bl __in
On Monday 21 April 2008, Anton Vorontsov wrote:
> On Mon, Apr 21, 2008 at 01:01:12PM -0700, David Brownell wrote:
> > The way other platforms do this is to hav SOC-specific
> > init code, and have board-specific initcalls call the
> > relevant SOC-specific setup.
>
> I don't know about other plat
On Mon, 2008-04-21 at 17:04 -0500, Kumar Gala wrote:
> On Apr 21, 2008, at 4:22 PM, Benjamin Herrenschmidt wrote:
> >
> >>
> >> _GLOBAL(__setup_cpu_603)
> >> - b setup_common_caches
> >> + mflrr4
> >> +BEGIN_FTR_SECTION
> >> + bl __init_fpu_registers
> >> +END_FTR_SECTION_IFCLR(C
On Mon, Apr 21, 2008 at 03:05:25PM -0600, Grant Likely wrote:
> On Fri, Apr 18, 2008 at 1:10 PM, Anton Vorontsov
> <[EMAIL PROTECTED]> wrote:
> > This is patch adds board file, device tree, and defconfig for the new
> > board, made by Freescale Semiconductor Inc. and Logic Product Development.
>
On Apr 21, 2008, at 4:22 PM, Benjamin Herrenschmidt wrote:
_GLOBAL(__setup_cpu_603)
- b setup_common_caches
+ mflrr4
+BEGIN_FTR_SECTION
+ bl __init_fpu_registers
+END_FTR_SECTION_IFCLR(CPU_FTR_FPU_UNAVAILABLE)
+ bl __init_fpu_registers
+ bl
On Mon, Apr 21, 2008 at 01:01:12PM -0700, David Brownell wrote:
> On Monday 21 April 2008, Anton Vorontsov wrote:
> > From: J. Random Hacker
> > Subject: [POWERPC] cleanup board initialization code
> >
> > This patch removes vast amount of machine_arch_initcall()s that were
> > used to solely
On Mon, Apr 21, 2008 at 02:02:56PM -0700, Remi Machet wrote:
> The MPSC driver and prpmc2800.dts have been modified to
> use property 'cell-index' as the serial port number but
> the early serial console driver for the mv64x60 has not
> been modified to use this new property.
>
> Signed-off-by:
The last time arch/ppc built for me (a few days ago), it got
535 warnings. I don't think anyone would notice one more.
Also, whoever doesn't yet know arch/ppc will be going away
has been living under a rock for the last two years.
You say that as if it is an uncommon living condition.
Oh
>
> _GLOBAL(__setup_cpu_603)
> - b setup_common_caches
> + mflrr4
> +BEGIN_FTR_SECTION
> + bl __init_fpu_registers
> +END_FTR_SECTION_IFCLR(CPU_FTR_FPU_UNAVAILABLE)
> + bl __init_fpu_registers
> + bl setup_common_caches
> + mtlrr4
> + blr
On Mon, 2008-04-21 at 16:54 +0200, Stefan Roese wrote:
> --
> - As suggested by Benjamin Herrenschmidt, don't determine endpoint mode
> by looking at the already configured PCIe port state, but evaluate
> the device_type property instead. This makes it possible for boards
> with
On Mon, Apr 21, 2008 at 3:10 PM, Segher Boessenkool
<[EMAIL PROTECTED]> wrote:
>
> > Speaking of making it obvious, is it time to put a #warning in some
> > prominent arch/ppc header?
> >
>
> The last time arch/ppc built for me (a few days ago), it got
> 535 warnings. I don't think anyone would
On Mon, Apr 21, 2008 at 10:41 AM, Anton Vorontsov
<[EMAIL PROTECTED]> wrote:
> On Mon, Apr 21, 2008 at 08:58:09AM -0600, Grant Likely wrote:
> > Its not great. It has a boot time impact for every platform compiled
> > into the kernel. The problem gets worse every time another block of
> > code
On Mon, 2008-04-21 at 13:55 +0200, Christian Ehrhardt wrote:
> Benjamin Herrenschmidt wrote:
> >> Yes you're right. Early at the pci initialization are errors of the
> >> allocation for pi ressources.
> >> And that are exactly the ressources failing later, so that pci
> >> initialization seem to
Speaking of making it obvious, is it time to put a #warning in some
prominent arch/ppc header?
The last time arch/ppc built for me (a few days ago), it got
535 warnings. I don't think anyone would notice one more.
Also, whoever doesn't yet know arch/ppc will be going away
has been living under
On Fri, Apr 18, 2008 at 1:10 PM, Anton Vorontsov
<[EMAIL PROTECTED]> wrote:
> This is patch adds board file, device tree, and defconfig for the new
> board, made by Freescale Semiconductor Inc. and Logic Product Development.
> arch/powerpc/platforms/83xx/mpc836x_rdk.c | 106 +++
I don't
The MPSC driver and prpmc2800.dts have been modified to
use property 'cell-index' as the serial port number but
the early serial console driver for the mv64x60 has not
been modified to use this new property.
Signed-off-by: Remi Machet ([EMAIL PROTECTED])
---
arch/powerpc/sysdev/mv64x60_udbg.c
On Apr 21, 2008, at 3:19 PM, Gabriel Paubert wrote:
On Mon, Apr 21, 2008 at 02:57:47PM -0500, Kumar Gala wrote:
603 CPUs have the same issue that some 750 CPUs have in that they
can crash
in funny ways if a store from an FPU register instruction is
executed on a
register that has never been
On Mon, Apr 21, 2008 at 02:57:47PM -0500, Kumar Gala wrote:
> 603 CPUs have the same issue that some 750 CPUs have in that they can crash
> in funny ways if a store from an FPU register instruction is executed on a
> register that has never been initialized since power on. This patch fixes
> it by
603 CPUs have the same issue that some 750 CPUs have in that they can crash
in funny ways if a store from an FPU register instruction is executed on a
register that has never been initialized since power on. This patch fixes
it by making sure all FP registers have been properly initialized at kern
On Monday 21 April 2008, Anton Vorontsov wrote:
> From: J. Random Hacker
> Subject: [POWERPC] cleanup board initialization code
>
> This patch removes vast amount of machine_arch_initcall()s that were
> used to solely initialize some hardware, like this:
>
> qe_add_gpio_chips();
> fsl_gtm_i
603 CPUs have the same issue that some 750 CPUs have in that they can crash
in funny ways if a store from an FPU register instruction is executed on a
register that has never been initialized since power on. This patch fixes
it by making sure all FP registers have been properly initialized at kern
On Mon, Apr 21, 2008 at 11:46:12AM -0700, Remi Machet wrote:
> If one of the devices of the mv64x60 init fails, the remaining
> devices are not initialized => This patch changes the code to
> display an error and continue the initialization.
>
> Signed-off-by: Remi Machet ([EMAIL PROTECTED])
Ac
If one of the devices of the mv64x60 init fails, the remaining
devices are not initialized => This patch changes the code to
display an error and continue the initialization.
Signed-off-by: Remi Machet ([EMAIL PROTECTED])
---
Integrated the few format changes requested by Dale in the
previous v
On Mon, Apr 21, 2008 at 08:03:31AM -0600, Grant Likely wrote:
> > +r) Freescale General-purpose Timers Module
> > +
> > +Required properties:
> > + - compatible : should be "fsl,gtm" ("fsl,qe-gtm" in addition for QE
> > + GTMs or "fsl,cpm2-gtm" for CPM2 GTMs).
On Mon, Apr 21, 2008 at 10:25:09AM -0500, Kumar Gala wrote:
>
> On Apr 19, 2008, at 1:14 PM, Grant Likely wrote:
> >On Sat, Apr 19, 2008 at 9:52 AM, Kumar Gala
> ><[EMAIL PROTECTED]> wrote:
> >>We have a board port in arch/powerpc so we dont need this one
> >>anymore.
> >>
> >>Signed-off-by: K
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 be configured at compile time by setting
CONFIG_PAGE_OFFSET, CONFIG_KERNEL_START, and CONFIG_PHYSICAL_START as
desired.
Altern
On Mon, Apr 21, 2008 at 10:37:14AM -0700, Remi Machet wrote:
> If one of the devices of the mv64x60 init fails, the remaining
> devices are not initialized => This patch change the code to
> display an error and continue the initialization.
>
> Signed-off-by: Remi Machet ([EMAIL PROTECTED])
> --
On Mon, Apr 21, 2008 at 10:36:48AM -0700, Remi Machet wrote:
> I2C parameters freq_m and freq_n are assigned default in the code
> but if those properties are not found in the open firmware description
> the init returns an error => the code now uses the default
> values if the properties are not
On Fri, Apr 18, 2008 at 01:34:29PM +0200, Laurent Pinchart wrote:
> Scott Wood was concerned in
> http://patchwork.ozlabs.org/linuxppc/patch?id=17490 that the gpio lib might
> be an unnecessary burden for memory-constraint platforms. Should we keep two
> mdio bitbang drivers, one with direct acc
On Apr 19, 2008, at 7:18 AM, Paul Mackerras wrote:
Kumar Gala writes:
[POWERPC] 85xx: Add support for relocatble kernel (and booting at
non-
zero)
Should be OK to go though probably not in the first batch. I want to
look through it carefully again since it's touching code that is
common t
On Apr 19, 2008, at 6:07 AM, Gerhard Pircher wrote:
Original-Nachricht
Datum: Thu, 17 Apr 2008 21:57:05 -0500 (CDT)
Von: Kumar Gala <[EMAIL PROTECTED]>
An: Paul Mackerras <[EMAIL PROTECTED]>
CC: linuxppc-dev@ozlabs.org
Betreff: [PATCH] [POWERPC] Port fixmap from x86 and use f
If one of the devices of the mv64x60 init fails, the remaining
devices are not initialized => This patch change the code to
display an error and continue the initialization.
Signed-off-by: Remi Machet ([EMAIL PROTECTED])
---
This is the second part of the re-submission of my patch of 4/17/2008
t
I2C parameters freq_m and freq_n are assigned default in the code
but if those properties are not found in the open firmware description
the init returns an error => the code now uses the default
values if the properties are not found.
Signed-off-by: Remi Machet ([EMAIL PROTECTED])
---
This is th
On Mon, 21 Apr 2008 12:02:25 -0400
"Steven A. Falco" <[EMAIL PROTECTED]> wrote:
> I am using a recent DENX git tree. I want to enable debugging in
> prom_parse.c.
> When I do that, I see link warnings like:
I already sent a patch a month and a half ago to clean all these
warnings up. It never
Juergen Beisert wrote:
Please don't forget what Sylvian said about this driver: "I also completely
skipped the 5200 (not B) support ..." and your own "I think it should be left
noted here that the CCR size changed from 16 bits to 32 bits from 5200 to
5200B in order to reduce confusion.". Its
On Mon, Apr 21, 2008 at 10:55 AM, Bartlomiej Sieka <[EMAIL PROTECTED]> wrote:
> Grant Likely wrote:
>
> > On Mon, Apr 21, 2008 at 7:57 AM, Bartlomiej Sieka <[EMAIL PROTECTED]>
> wrote:
> >
> > > Bartlomiej Sieka wrote:
> > >
> > >
> > > > Board-specific defconfigs based on current mpc5200_defconfig
Grant Likely wrote:
On Mon, Apr 21, 2008 at 7:57 AM, Bartlomiej Sieka <[EMAIL PROTECTED]> wrote:
Bartlomiej Sieka wrote:
Board-specific defconfigs based on current mpc5200_defconfig, archival
lite5200_defconfig, and [cm5200|motionpro|tqm5200]_defconfig from the
linux-2.6-denx tree. Kernels bui
The easiest way is to edit the .mhs by hand.
Steve
> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:linuxppc-dev-
> [EMAIL PROTECTED] On Behalf Of
Guillaume Dargaud
> Sent: Monday, April 21, 2008 9:16 AM
> To: Rick Moleres; linuxppc-dev@ozlabs.org
> Subject: Re: Xilinx network trou
On Mon, Apr 21, 2008 at 08:58:09AM -0600, Grant Likely wrote:
> On Mon, Apr 21, 2008 at 8:49 AM, Anton Vorontsov
> <[EMAIL PROTECTED]> wrote:
> > > > Should this really be a arch_initcall()? Would it be better for
> > > > platforms needing it to call it explicitly from one of the platform's
> >
Also, why is encoded in compatible? Do the different banks
have different register interfaces?
Yes, they could. For example, interrupt pins are bank-specific.
In what way? If different banks just have different IRQ #s,
there are easier ways to express this.
Segher
___
+static inline void gtm_ack_timer16(struct gtm_timer *tmr, u16
events)
+{
+ out_be16(tmr->gtevr, events);
+}
Drop 'inline' and expect gcc to do the right thing.
Not sure about newer gccs, but older complained about "defined but not
used" functions w/o inline keyword. I'm almost sure
Hello, I wrote:
Ah, that's what happens -- BAR0 in functions 0/1 takes up the whole
265 MiB of the PCI memory space (128+128), so no place is left for other
memory BARs.
What's interesting, the Sequoia/Rainier board user manual says that PCI
memory is 0x8000 thru 0xbfff (i.e. 1
I am using a recent DENX git tree. I want to enable debugging in prom_parse.c.
When I do that, I see link warnings like:
WARNING: drivers/net/ibm_newemac/ibm_newemac.o(.data+0x6e0): Section mismatch
in reference from the variable emac_of_bus_notifier to the function
.devinit.text:emac_of_bus_no
Hi Rick,
You might try v1.00a of the xps_ll_temac core. There are a couple of
issues with v1.00b (posted previously on this list) that may (or may
not) be causing the problem you see.
Thanks for the answer... but I can't figure out how to revert to 1.00a. Is
the option accessible from xps ?
On Apr 19, 2008, at 1:14 PM, Grant Likely wrote:
On Sat, Apr 19, 2008 at 9:52 AM, Kumar Gala
<[EMAIL PROTECTED]> wrote:
We have a board port in arch/powerpc so we dont need this one
anymore.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
Personally, I'd rather not do the piecemeal removal
Christian Ehrhardt wrote:
+else {
+printk(KERN_ERR"%s - continue with start 0x%0lx on %p\n", __func__,
(this->end + 1), this->sibling);
+}
new->start = this->end + 1;
this = this->sibling;
And here. Yet it's not clear why you call resource's 'end' 'start'.
This patch adds basic endpoint support to the 4xx PCIe driver.
This is done by checking the device_type property of the PCIe
device node ("pci" for root-complex and "pci-endpoint" for endpoint
configuration).
Note: Currently we map a fixed 64MByte window to PLB address 0 (SDRAM).
This should prob
On Mon, Apr 21, 2008 at 8:49 AM, Anton Vorontsov
<[EMAIL PROTECTED]> wrote:
> > > Should this really be a arch_initcall()? Would it be better for
> > > platforms needing it to call it explicitly from one of the platform's
> > > machine_arch_initcall()? Otherwise it gets called for all platform
On Mon, Apr 21, 2008 at 06:33:13PM +0400, Anton Vorontsov wrote:
[...]
> > > +static int __init qe_add_gpiochips(void)
> > > +{
> > > + int ret;
> > > + struct device_node *np;
> > > +
> > > + for_each_compatible_node(np, NULL, "fsl,qe-pario-bank") {
> > > + s
On Mon, Apr 21, 2008 at 08:19:05AM -0600, Grant Likely wrote:
> On Fri, Apr 18, 2008 at 1:09 PM, Anton Vorontsov
> <[EMAIL PROTECTED]> wrote:
> > This is needed to access QE GPIOs via Linux GPIO API.
> >
> > Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
> > ---
> > diff --git a/Documentatio
On Fri, Apr 18, 2008 at 11:10 AM, Jochen Friedrich <[EMAIL PROTECTED]> wrote:
> This patch implement GPIO LIB support for the CPM1 GPIOs.
>
> Signed-off-by: Jochen Friedrich <[EMAIL PROTECTED]>
> ---
> arch/powerpc/platforms/8xx/Kconfig | 10 ++
> arch/powerpc/sysdev/cpm1.c | 261
>
On Mon, Apr 21, 2008 at 08:03:31AM -0600, Grant Likely wrote:
> 2008/4/18 Anton Vorontsov <[EMAIL PROTECTED]>:
> > GTM stands for General-purpose Timers Module and able to generate
> > timer{1,2,3,4} interrupts. These timers are used by the drivers that
> > need time precise interrupts (like for
On Mon, Apr 21, 2008 at 08:08:39AM -0600, Grant Likely wrote:
> On Fri, Apr 18, 2008 at 1:09 PM, Anton Vorontsov
> <[EMAIL PROTECTED]> wrote:
> > - split and export __par_io_config_pin() out of par_io_config_pin(), so we
> > could use the prefixed version with GPIO LIB API;
> > - rename struct p
On Mon, Apr 21, 2008 at 7:57 AM, Bartlomiej Sieka <[EMAIL PROTECTED]> wrote:
> Bartlomiej Sieka wrote:
>
> > Board-specific defconfigs based on current mpc5200_defconfig, archival
> > lite5200_defconfig, and [cm5200|motionpro|tqm5200]_defconfig from the
> > linux-2.6-denx tree. Kernels build using
On Mon, 21 Apr 2008 15:36:06 +0200, "Gabriel Paubert" <[EMAIL PROTECTED]>
said:
> On Mon, Apr 21, 2008 at 03:07:13PM +0200, Alexander van Heukelum wrote:
> > On Mon, 21 Apr 2008 22:13:06 +1000, "Paul Mackerras" <[EMAIL PROTECTED]>
> > said:
> > > Alexander van Heukelum writes:
> > > > Powerpc would
On Fri, Apr 18, 2008 at 1:09 PM, Anton Vorontsov
<[EMAIL PROTECTED]> wrote:
> This is needed to access QE GPIOs via Linux GPIO API.
>
> Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
> ---
> diff --git a/Documentation/powerpc/booting-without-of.txt
> b/Documentation/powerpc/booting-without-
On Fri, Apr 18, 2008 at 1:09 PM, Anton Vorontsov
<[EMAIL PROTECTED]> wrote:
> - split and export __par_io_config_pin() out of par_io_config_pin(), so we
> could use the prefixed version with GPIO LIB API;
> - rename struct port_regs to qe_pio_regs, and place it into qe.h;
> - rename #define NUM
Sergei Shtylyov wrote:
Hello.
Christian Ehrhardt wrote:
Cheers,
Ben.
For comparison I defined DEBUG in the good kernel (arch=ppc) and that
is what the initialization prints (pci ...:0a:1 is the secondary head
of the same graphic card an it's not an issue if thats not allocated):
[...]
2008/4/18 Anton Vorontsov <[EMAIL PROTECTED]>:
> GTM stands for General-purpose Timers Module and able to generate
> timer{1,2,3,4} interrupts. These timers are used by the drivers that
> need time precise interrupts (like for USB transactions scheduling for
> the Freescale USB Host controller a
Bartlomiej Sieka wrote:
Board-specific defconfigs based on current mpc5200_defconfig, archival
lite5200_defconfig, and [cm5200|motionpro|tqm5200]_defconfig from the
linux-2.6-denx tree. Kernels build using these defconfigs were verified
to boot with root filesystem mounted over NFS on Motion-PRO,
On Mon, Apr 21, 2008 at 03:07:13PM +0200, Alexander van Heukelum wrote:
> On Mon, 21 Apr 2008 22:13:06 +1000, "Paul Mackerras" <[EMAIL PROTECTED]>
> said:
> > Alexander van Heukelum writes:
> > > Powerpc would pick up an optimized version via this chain: generic fls64
> > > ->
> > > powerpc __fls -
On Mon, Apr 21, 2008 at 2:43 AM, Sascha Hauer <[EMAIL PROTECTED]> wrote:
> On Fri, Apr 18, 2008 at 09:10:04AM -0700, Grant Likely wrote:
>
>
> > Update dts files to current format
> >
> > From: Grant Likely <[EMAIL PROTECTED]>
> >
> > Signed-off-by: Grant Likely <[EMAIL PROTECTED]>
> > ---
>
On Sun, 20 Apr 2008 20:56:20 -0700
"Stephen Neuendorffer" <[EMAIL PROTECTED]> wrote:
>
>
> > > +void dcr_unmap_generic(dcr_host_t host, unsigned int dcr_c)
> > > +{
> > > + if (host.type == NATIVE)
> > > + dcr_unmap_native(host.host.native, dcr_c);
> > > + else
> > > + dcr_unmap_
On Mon, 21 Apr 2008 22:13:06 +1000, "Paul Mackerras" <[EMAIL PROTECTED]>
said:
> Alexander van Heukelum writes:
> > Powerpc would pick up an optimized version via this chain: generic fls64
> > ->
> > powerpc __fls --> __ilog2 --> asm (PPC_CNTLZL "%0,%1" : "=r" (lz) : "r"
> > (x)).
>
> Why wouldn't
Hello.
Christian Ehrhardt wrote:
Cheers,
Ben.
For comparison I defined DEBUG in the good kernel (arch=ppc) and that is
what the initialization prints (pci ...:0a:1 is the secondary head of
the same graphic card an it's not an issue if thats not allocated):
good case:
PCI: Probing PCI hardw
On Monday 21 April 2008, Laurent Pinchart wrote:
> > > > Is there any chance they will got to 2.6.26?
> > >
> > > I'm not sure. I didn't have the time to look at it myself, but I am
> > > under the impression that the powerpc folks are tired of having to wait
> > > for me and may push it to Linus t
Ingo Molnar writes:
> Paul, do you agree with those generic bitops changes? Just in case it's
Well, it looks OK, but I'm sure people are going to get confused with
fls vs. fls64 vs. __fls all being subtly different. I'd say it's
worth putting a little file in the Documentation directory to expl
Alexander van Heukelum writes:
> Powerpc would pick up an optimized version via this chain: generic fls64
> ->
> powerpc __fls --> __ilog2 --> asm (PPC_CNTLZL "%0,%1" : "=r" (lz) : "r"
> (x)).
Why wouldn't powerpc continue to use the fls64 that I have in there
now?
> However, the generic version
On Saturday 19 April 2008 18:43, Jochen Friedrich wrote:
> Jean Delvare wrote:
> > On Sat, 19 Apr 2008 15:09:55 +0200, Jochen Friedrich wrote:
> > > Hi Jean,
> > >
> > > > > > Is the new-style driver conversion patch in 2.6.25-rc8-mm2
> > > > > > scheduled for 2.6.26 ?
> > > > > hope so! :)
> > >
Benjamin Herrenschmidt wrote:
Yes you're right. Early at the pci initialization are errors of the allocation
for pi ressources.
And that are exactly the ressources failing later, so that pci initialization
seem to be the reason for my problem.
Was there any simple solution (e.g. just somehow in
On Mon, 21 Apr 2008 13:19:50 +0200, "Alexander van Heukelum"
<[EMAIL PROTECTED]> said:
> On Mon, 21 Apr 2008 11:51:02 +0200, "Ingo Molnar" <[EMAIL PROTECTED]> said:
> > * Stephen Rothwell <[EMAIL PROTECTED]> wrote:
> >
> > > Hi all,
> > >
> > > Today's linux-next merge of the x86-latest tree got
On Mon, 21 Apr 2008 11:51:02 +0200, "Ingo Molnar" <[EMAIL PROTECTED]> said:
>
> * Stephen Rothwell <[EMAIL PROTECTED]> wrote:
>
> > Hi all,
> >
> > Today's linux-next merge of the x86-latest tree got a conflict in
> > include/asm-powerpc/bitops.h between commit
> > cd008c0f03f3d451e5fbd108b8e7
Hi, Michael,
Thank you very much for you input, please see my inline answer.
B.R
Jason
> -Original Message-
> From: Michael Ellerman [mailto:[EMAIL PROTECTED]
> Sent: Monday, April 21, 2008 2:22 PM
> To: Jin Zhengxiong
> Cc: linuxppc-dev@ozlabs.org; Gala Kumar
> Subject: Re: [PATCH 1/3
1 - 100 of 116 matches
Mail list logo
