On Aug 12, 2009, at 1:20 AM, Kumar Gala wrote:
On Aug 11, 2009, at 10:25 PM, B.J. Buchalter wrote:
I don't know the model of the board off the top of my head.
I do know that it uses the Texas Instruments XIO2000A/XIO2200 PCI
Express-to-PCI Bridge (rev 03), with the TSB82AA2 OHCI Link behi
On MPC8572 and MPC8536 the status of GPIO pins configured
as output cannot be determined by reading GPDAT register.
Workaround by reading the status of input pins from GPDAT
and the status of output pins from a shadow register.
Signed-off-by: Felix Radensky
---
arch/powerpc/sysdev/mpc8xxx_gpio.c
On Aug 11, 2009, at 10:25 PM, B.J. Buchalter wrote:
I don't know the model of the board off the top of my head.
I do know that it uses the Texas Instruments XIO2000A/XIO2200 PCI
Express-to-PCI Bridge (rev 03), with the TSB82AA2 OHCI Link behind
the bridge.
The same board definitely works
On Wed, Jul 29, 2009 at 13:05, Anton Vorontsov wrote:
> This makes it consistent with other buses (platform, i2c, vio, ...).
> I'm not sure why we use the prefixes, but there must be a reason.
>
> This was easy enough to do it, and I did it.
acked-by-me for misc blackfin/adi drivers, thanks
-mike
On Aug 11, 2009, at 9:43 PM, Kumar Gala wrote:
On Aug 11, 2009, at 5:27 PM, B.J. Buchalter wrote:
I have been trying to use a PCIe FireWire card on a MPC8377E-RDB
board.
is this an off the shelf PCIe FireWire card?
Yes.
If so which one?
I don't know the model of the board off the
On Aug 11, 2009, at 9:43 PM, Kumar Gala wrote:
On Aug 11, 2009, at 5:27 PM, B.J. Buchalter wrote:
So it seems like the XIO2000(A) is being misconfigured or
misidentified, and rather than finding the configured bus behind
the bridge, it is doing "something else", and as a result, not
f
On Aug 11, 2009, at 5:27 PM, B.J. Buchalter wrote:
I have been trying to use a PCIe FireWire card on a MPC8377E-RDB
board.
is this an off the shelf PCIe FireWire card? If so which one?
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs
On Aug 11, 2009, at 5:27 PM, B.J. Buchalter wrote:
So it seems like the XIO2000(A) is being misconfigured or
misidentified, and rather than finding the configured bus behind the
bridge, it is doing "something else", and as a result, not finding
the PCI OHCI FireWire controller on the PCI
Hey Folks,
I have been trying to use a PCIe FireWire card on a MPC8377E-RDB board.
I have tried this with both the LTIB/BSP (2.6.25) and the head of the
kernel.org tree (at least from a couple of days ago).
With 2.6.25, the PCIe buss(es) don't show up at all during boot.
With 2.6.31-rc? the
On Tue, Aug 11, 2009 at 05:42:26PM -0400, Paul Gortmaker wrote:
>On Tue, Aug 11, 2009 at 10:09 AM, Sridhar Mahadevan
>wrote:
>> Hi,
>> Am trying to compile my WRL 2.6.21 kernel for PPC architecture.
>> The processor am using is AMCC powerpc 440EP .
>
>This isn't really the best choice of forum for
On Tue, Aug 11, 2009 at 10:09 AM, Sridhar Mahadevan wrote:
> Hi,
> Am trying to compile my WRL 2.6.21 kernel for PPC architecture.
> The processor am using is AMCC powerpc 440EP .
This isn't really the best choice of forum for trying to get help like this.
Most of the people here are focused on wo
On Mon, Aug 10, 2009 at 05:22:17PM -0700, Pallipadi, Venkatesh wrote:
> Also, I don't think using just the ACPI/BIOS supplied states in _CST is
> right thing to do for offline. _CST is meant for C-state and BIOS may
> not include some C-state in _CST if the system manufacturer thinks that
> the lat
Hi,
Am trying to compile my WRL 2.6.21 kernel for PPC architecture.
The processor am using is AMCC powerpc 440EP .
I just built the file system by running the configure command with
--enable-rootfs=glibc-small and --enable-cpu-ppc-440 and i got a cross
compiler.
I took the linux kernel image and up
On Tuesday 11 August 2009 17:59:26 Nathan French wrote:
> This is good news. Can you point me towards the patch for that?
Sure. Latest version is: "[PATCH v8] spi: Add PPC4xx SPI driver":
http://article.gmane.org/gmane.linux.ports.ppc64.devel/57940
Best regards,
Stefan
_
This is good news. Can you point me towards the patch for that?
Nathan
On Tue, 2009-08-11 at 01:44 -0400, Stefan Roese wrote:
> On Monday 10 August 2009 18:07:15 Nathan French wrote:
> > > At least something similar worked for me some months ago (before we
> > > switched to a "real" driver for s
On Tue, Aug 11, 2009 at 06:12:12PM +0300, Felix Radensky wrote:
[...]
> >Plus, this are two reads instead of just one. I think it'll be better
> >to implement mpc8536_gpio_get(), and then do
> >
> >if (of_device_is_compatible(np, ... 8536-gpio-bank ...))
> > gc->get = mpc8536_gpio_get;
> >else
Anton Vorontsov wrote:
On Tue, Aug 11, 2009 at 12:04:18PM +0300, Felix Radensky wrote:
On MPC8536 Rev 1.0 the status of GPIO pins configured
as output cannot be determined by reading GPDAT register.
Workaround by reading the status of input pins from GPDAT
and the status of output pins from a
> -Original Message-
> From: Kumar Gala [mailto:ga...@kernel.crashing.org]
> Sent: Tuesday, August 11, 2009 7:11 PM
> To: Aggrwal Poonam-B10812
> Cc: linuxppc-...@ozlabs.org
> Subject: Re: [v3][PATCH][powerpc/85xx] P2020RDB Platform Support Added
>
>
> On Aug 7, 2009, at 10:35 AM, Poo
On Aug 11, 2009, at 8:44 AM, Anton Vorontsov wrote:
On Tue, Aug 11, 2009 at 12:04:18PM +0300, Felix Radensky wrote:
On MPC8536 Rev 1.0 the status of GPIO pins configured
as output cannot be determined by reading GPDAT register.
Workaround by reading the status of input pins from GPDAT
and the
On Aug 7, 2009, at 2:58 PM, Anton Vorontsov wrote:
This patch simply adds sdhci node to the device tree.
We specify clock-frequency manually, so that eSDHC will work without
upgrading U-Boot. Though, that'll only work for default setup (1500
MHz) on new board revisions. For non-default setups,
On Aug 7, 2009, at 1:41 AM, Heiko Schocher wrote:
- add I2C support
- add FCC1 and FCC2 support
Signed-off-by: Heiko Schocher
---
- against git://git.kernel.org/pub/scm/linux/kernel/git/galak/
powerpc.git
next branch
- checked with checkpatch.pl:
$ ./scripts/checkpatch.pl 0001-82xx-mgcoge-
On Tue, Aug 11, 2009 at 12:04:18PM +0300, Felix Radensky wrote:
> On MPC8536 Rev 1.0 the status of GPIO pins configured
> as output cannot be determined by reading GPDAT register.
> Workaround by reading the status of input pins from GPDAT
> and the status of output pins from a shadow register.
>
On Aug 7, 2009, at 10:35 AM, Poonam Aggrwal wrote:
+ enet2: ether...@26000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ cell-index = <2>;
+ device_type = "network";
+
On Aug 11, 2009, at 2:18 AM, Felix Radensky wrote:
Hi, Kumar
Patch subject does not match the contents. The patch is about
mpc8536ds.
Felix.
Oops, copy/paste error on my part. The subject is the one that is
wrong.
- k
___
Linuxppc-dev mail
On Aug 11, 2009, at 4:04 AM, Felix Radensky wrote:
On MPC8536 Rev 1.0 the status of GPIO pins configured
as output cannot be determined by reading GPDAT register.
Workaround by reading the status of input pins from GPDAT
and the status of output pins from a shadow register.
Signed-off-by: Feli
The build of a PowerMac 32bit kernel currently fails with
error: #warning "WARNING, CPUFREQ not recommended on SMP kernels"
This patch just disables this driver on SMP kernels, as it is obviously
not supported.
Signed-off-by: Bastian Blank
diff --git a/arch/powerpc/platforms/Kconfig b/arch/pow
On MPC8536 Rev 1.0 the status of GPIO pins configured
as output cannot be determined by reading GPDAT register.
Workaround by reading the status of input pins from GPDAT
and the status of output pins from a shadow register.
Signed-off-by: Felix Radensky
---
arch/powerpc/sysdev/mpc8xxx_gpio.c |
Hi, Kumar
Patch subject does not match the contents. The patch is about mpc8536ds.
Felix.
Kumar Gala wrote:
Added a device tree that should be similiar to mpc8536ds.dtb except
the physical addresses for all IO are above the 4G boundary.
Signed-off-by: Kumar Gala
---
arch/powerpc/boot/dts/mp
On Thu, 2009-08-06 at 14:58 +1000, Paul Mackerras wrote:
> +
> +#else /* CONFIG_PPC64 */
> +/*
> + * On 32-bit we just access the address and let hash_page create a
> + * HPTE if necessary, so there is no need to fall back to reading
> + * the page tables. Since this is called at interrupt level
29 matches
Mail list logo
