Kumar Gala wrote:
What 32-bit chip are you looking to enable this for?
- k
I am working on some stuff for the 750GX
kevin
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
On Fri, 2008-04-25 at 19:52 -0700, Tushar Tyagi wrote:
> Hello,
> I'm working a new DMA hardware for PPC processors.
> The processor is a 32 bit architecture having 40 bit physical address
> space.
> So we need the 32 bit processor code base but we want the type
> dma_addr_t to represent 64 bit d
On Fri, 2008-04-25 at 18:58 -0500, Josh Boyer wrote:
> > > I guess them being "two short" is why they needed to be
> doubled. :-)
> >
> > Well, in that case, it makes sense, it's still pretty short and
> better
> > safe than sorry. On day I may look at actually measuring PHYs and
> see if
> > it
Hello,
I'm working a new DMA hardware for PPC processors.
The processor is a 32 bit architecture having 40 bit physical address
space.
So we need the 32 bit processor code base but we want the type
dma_addr_t to represent 64 bit data, without enabling the CONFIG_PPC64
flag.
We want to use the Li
On Sat, 26 Apr 2008 08:22:38 +1000
Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
>
> On Fri, 2008-04-25 at 16:57 -0400, Bill Fink wrote:
> > On Wed, 23 Apr 2008, Benjamin Herrenschmidt wrote:
> >
> > > This patch doubles the MDIO timeouts in EMAC as there are field
> > > cases where they are
Kumar Gala writes:
> Do we think we want to poke Paul to get this in for v2.6.26 so we can
> get it some more testing on all the ppc32 systems?
It's not going in 2.6.26, since it's a pretty substantial change and
it was first seen half-way through the merge window...
Paul.
On Fri, 2008-04-25 at 16:57 -0400, Bill Fink wrote:
> On Wed, 23 Apr 2008, Benjamin Herrenschmidt wrote:
>
> > This patch doubles the MDIO timeouts in EMAC as there are field
> > cases where they are two short to communicate with some PHYs.
>
> I guess them being "two short" is why they needed t
On Wed, 23 Apr 2008, Benjamin Herrenschmidt wrote:
> This patch doubles the MDIO timeouts in EMAC as there are field
> cases where they are two short to communicate with some PHYs.
I guess them being "two short" is why they needed to be doubled. :-)
On Fri, Apr 25, 2008 at 12:51 PM, Sascha Hauer <[EMAIL PROTECTED]> wrote:
> On Fri, Apr 25, 2008 at 04:30:55PM +0100, Matt Sealey wrote:
> > Can I make a suggestion for this chip support?
> >
> > On certain 5200 boards these devices are not usable since they are not
> > connected. My concern is
On Fri, Apr 25, 2008 at 04:30:55PM +0100, Matt Sealey wrote:
> Can I make a suggestion for this chip support?
>
> On certain 5200 boards these devices are not usable since they are not
> connected. My concern is the Efika where we only have 2 wakeup and 1 simple
> GPIO available on the board and ma
> -Original Message-
> From: Sergei Shtylyov [mailto:[EMAIL PROTECTED]
> Sent: den 25 april 2008 18:00
> To: [EMAIL PROTECTED]
> Cc: 'linuxppc-dev Development'
> Subject: Re: HR timers on PowerPC 83xx
>
> Joakim Tjernlund wrote:
>
> >>>Trying to understand what is needed to make nanosleep
This patch adds few bindings for the new drivers to be submitted through
appropriate maintainers.
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
Documentation/powerpc/booting-without-of.txt | 125 ++
1 files changed, 125 insertions(+), 0 deletions(-)
diff --git a
This is patch adds board file, device tree, and defconfig for the new
board, made by Freescale Semiconductor Inc. and Logic Product Development.
Currently supported:
1. UEC{1,2,7,4};
2. I2C;
3. SPI;
4. NS16550 serial;
5. PCI and miniPCI;
6. Intel NOR StrataFlash X16 64Mbit PC28F640P30T85;
7. Graph
This is needed to access QE GPIOs via Linux GPIO API.
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
Documentation/powerpc/booting-without-of.txt | 37 ---
arch/powerpc/sysdev/qe_lib/Kconfig |8 ++
arch/powerpc/sysdev/qe_lib/Makefile |1 +
arch/powerpc/sys
- 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_OF_PINS to QE_PIO_PINS, and place it into qe.h.
Signed-off-by: Anton Vorontsov <[EMA
This patch adds a function to the qe_lib to setup QE USB clocks routing.
To setup clocks safely, cmxgcr register needs locking, so I just reused
ucc_lock since it was used only to protect cmxgcr.
The idea behind placing clocks routing functions into the qe_lib is that
later we'll hopefully switch
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 as found in some QE and CPM chips),
or these timers could b
Hi Kumar,
Here is the third try.
I've tried to address all the comments from the previous version.
The only comment I left out is merging mpc836x_rdk.c board file into some
existing board (as I explained, there are three QE boards: mpc832x_{rdb,mds}
and mpc836x_mds, and all have board-specific f
Joakim Tjernlund wrote:
Trying to understand what is needed to make nanosleep() and friends to
have better resolution than HZ on my 83xx CPU. Is this possible
and what CONFIG options do I need to enable? Kernel is 2.6.25
Should be possible with CONFIG_HIGH_RES_TIMERS=y.
What about NO_HZ
Can I make a suggestion for this chip support?
On certain 5200 boards these devices are not usable since they are not
connected. My concern is the Efika where we only have 2 wakeup and 1 simple
GPIO available on the board and maybe a few others with a bit of tweaking
and messing around.
Instead
On Fri, 2008-04-25 at 18:18 +0400, Sergei Shtylyov wrote:
> Hello.
>
> Joakim Tjernlund wrote:
>
> > Trying to understand what is needed to make nanosleep() and friends to
> > have better resolution than HZ on my 83xx CPU. Is this possible
> > and what CONFIG options do I need to enable? Kernel
Hello.
Joakim Tjernlund wrote:
Trying to understand what is needed to make nanosleep() and friends to
have better resolution than HZ on my 83xx CPU. Is this possible
and what CONFIG options do I need to enable? Kernel is 2.6.25
Should be possible with CONFIG_HIGH_RES_TIMERS=y.
WBR, Sergei
Trying to understand what is needed to make nanosleep() and friends to
have better resolution than HZ on my 83xx CPU. Is this possible
and what CONFIG options do I need to enable? Kernel is 2.6.25
Jocke
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlab
On Thu, 2008-04-24 at 22:11 +1000, Paul Mackerras wrote:
> I have put the following patches in the powerpc.git repository on the
> master & powerpc-next branches (this includes some pulled from Kumar's
> tree). I plan to send a pull request to Linus tomorrow morning my
> time, so if there are any
On Apr 25, 2008, at 8:19 AM, Josh Boyer wrote:
On Fri, 25 Apr 2008 22:58:04 +1000
Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
On Fri, 2008-04-25 at 05:37 -0500, Josh Boyer wrote:
On Fri, 25 Apr 2008 16:24:01 +1000
Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
On Mon, 2008-04-21
Add board support for the Phytec pcm030 mpc5200b based board. It
does not need any platform specific fixups and as such is handled
as a mpc5200 simple platform.
Signed-off-by: Sascha Hauer <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/pcm030.dts | 363
arch/powerpc/configs/
- Original Message Header -
Subject: Re: [PATCH 3/3] Use __weak macro for smp_setup_processor_id
From: [EMAIL PROTECTED];
To: [EMAIL PROTECTED];
Cc: [EMAIL PROTECTED]; linuxppc-dev@ozlabs.org;
[EMAIL PROTECTED]; [EMAIL PROTECTED];
---
Warning: Attachment
- Original Message Header -
Subject: Re: [PATCH 3/3] Use __weak macro for smp_setup_processor_id
From: [EMAIL PROTECTED];
To: [EMAIL PROTECTED];
Cc: [EMAIL PROTECTED]; linuxppc-dev@ozlabs.org;
[EMAIL PROTECTED]; [EMAIL PROTECTED];
---
Warning: Attachment
On Fri, Apr 25, 2008 at 05:07:37PM +0400, Anton Vorontsov wrote:
> On Thu, Apr 24, 2008 at 05:36:59PM +0200, Sascha Hauer wrote:
>
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
>
> In the latest kernels the preferred way is to include ,
>
On Apr 25, 2008, at 8:03 AM, Benjamin Herrenschmidt wrote:
On Fri, 2008-04-25 at 09:23 +0200, Christoph Hellwig wrote:
On Thu, Apr 24, 2008 at 12:37:50AM -0500, Kumar Gala wrote:
config IRQSTACKS
bool "Use separate kernel stacks when processing interrupts"
- depends on PPC64
W
On Fri, 25 Apr 2008 22:58:04 +1000
Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
>
> On Fri, 2008-04-25 at 05:37 -0500, Josh Boyer wrote:
> > On Fri, 25 Apr 2008 16:24:01 +1000
> > Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
> >
> > >
> > > On Mon, 2008-04-21 at 16:54 +0200, Stefan Ro
On Thu, Apr 24, 2008 at 05:36:59PM +0200, Sascha Hauer wrote:
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
In the latest kernels the preferred way is to include ,
the patch introducing it was merged just recently, so few people know
about it yet.
--
On Fri, 2008-04-25 at 09:23 +0200, Christoph Hellwig wrote:
> On Thu, Apr 24, 2008 at 12:37:50AM -0500, Kumar Gala wrote:
> > config IRQSTACKS
> > bool "Use separate kernel stacks when processing interrupts"
> > - depends on PPC64
>
> Why do we have this as a user-selectable option? It sh
On Fri, 2008-04-25 at 05:37 -0500, Josh Boyer wrote:
> On Fri, 25 Apr 2008 16:24:01 +1000
> Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
>
> >
> > On Mon, 2008-04-21 at 16:54 +0200, Stefan Roese wrote:
> > > This patch adds basic endpoint support to the 4xx PCIe driver.
> > >
> > > This is
Paulus,
is there any specific reason, why out of these 7 patches only the first
one made it into the mainline? AFAICS, there has been only one comment,
suggesting to replace printk with dev_err on two occasions in one of
the patches...
Thanks
Guennadi
---
Guennadi Liakhovetski
On Fri, Apr 25, 2008 at 12:53:33PM +0200, Sascha Hauer wrote:
[...]
> >
> > As for the wide spans caused by gpt gpios, it is probably okay for
> > now, but we can rework it to do something clever (like have a single
> > registration for all gpt gpios) at a later date.
>
> I would rather teach the
On Wednesday 23 April 2008 13:12, Sergei Shtylyov wrote:
> David Woodhouse wrote:
>
> Ok. I'll submit a new patch as soon as we agree on a compatible name.
>
> >>>Did we?
>
> >>IIRC, The latest agreement was that we don't need the "compatible" and
> >>will match on node name.
>
> > Ok.
On Wed, 2008-04-23 at 23:55 +0200, Joakim Tjernlund wrote:
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:linuxppc-dev-
> > [EMAIL PROTECTED] On Behalf Of Roel Kluin
> > Sent: den 23 april 2008 22:55
> > To: [EMAIL PROTECTED]; linuxppc-dev@ozlabs.org
> > Cc: [EMAIL PROTECTED];
> -Original Message-
> From: David Woodhouse [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, April 23, 2008 2:49 AM
> To: Li Yang
> Cc: [EMAIL PROTECTED]; Stefan Roese;
> linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH] MTD: fix partition scan control logic in
> physmap_ofand fsl_elbc_nand
>
This patch adds gpiolib support for mpc5200 SOCs.
Changes since last submit:
- fixed checkpatch warnings
- use shadow variables for register accesses
- make match tables const
- Add documentation
Signed-off-by: Sascha Hauer <[EMAIL PROTECTED]>
---
Documentation/powerpc/mpc52xx-device-tree-bind
On Thu, Apr 24, 2008 at 12:45:49PM -0600, Grant Likely wrote:
> On Thu, Apr 24, 2008 at 9:36 AM, Sascha Hauer <[EMAIL PROTECTED]> wrote:
> > Hi all,
> >
> > Feel free to comment on this.
> >
> > Sascha
> >
> >
> > This patch adds gpiolib support for mpc5200 SOCs. I'm not sure
> > whether it's a
On Fri, 25 Apr 2008 16:12:50 +1000
Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
>
> On Fri, 2008-04-25 at 15:39 +1000, Tony Breeds wrote:
> > Currently we set the start of the .text section to be 4Mb for pSeries.
> > In situations where the zImage is > 8Mb we'll fail to boot (due to
> > over
On Fri, 25 Apr 2008 16:24:01 +1000
Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
>
> On Mon, 2008-04-21 at 16:54 +0200, Stefan Roese wrote:
> > 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
Hi Jon,
On Tue, 19 Feb 2008 17:42:21 +0100, Jean Delvare wrote:
> On Mon, 21 Jan 2008 15:07:40 -0500, Jon Smirl wrote:
> > Alter the mpc i2c driver to use the NO_IRQ symbol instead of
> > the constant zero when checking for valid interrupts. NO_IRQ=-1
> > on ppc and NO_IRQ=0 on powerpc so the chec
This hooks up the platform-specific [gs]et_rtc_time functions so that
kernels using CONFIG_RTC_CLASS have RTC support on most PowerPC
platforms.
Signed-off-by: David Woodhouse <[EMAIL PROTECTED]>
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 1e6715e..3e788b7 100644
--- a/drivers/rt
Hi,
Can someone suggest where to add the code for a cpu
(/sys/devices/system/cpu/cpu0) entry in sysfs?
The 2.6.24 release has a sysfs.c file but it only seems to be used for
64-bit? Anyone know why? What kind of planetary disasters will I create
if I allow it to be used in 32-bit as well?
Hi Sascha,
One small comment.
On Thu, 24 Apr 2008 17:36:59 +0200 Sascha Hauer <[EMAIL PROTECTED]> wrote:
>
> +#include
Never include , use
> +static struct of_device_id mpc52xx_wkup_gpiochip_match[] = {
const, please.
OK, I lied about only one comment :-)
> +static struct of_device_id mpc5
I'm posting a little more info 'cause no-one took the bait:
# tail -f /tmp/messages &
# reboot
The system is going down NOW!
Sending SIGTERM to all processes
Requesting system reboot
[ 2021.926957] Restarting system.
[ 2021.9[ 2021.931063] Kernel stack overflow in process c7c52c10,
r1=c01fc25b
On Thu, Apr 24, 2008 at 12:37:50AM -0500, Kumar Gala wrote:
> config IRQSTACKS
> bool "Use separate kernel stacks when processing interrupts"
> - depends on PPC64
Why do we have this as a user-selectable option? It should be on by
default on 32 or 64bit.
__
On Sat, Apr 19, 2008 at 03:19:24PM -0700, Roland McGrath wrote:
> Hi. I posted this before, but I don't see it in any of your powerpc.git
> trees. Can you push this upstream ASAP? It would make life easier for me
> trying to merge some more generic changes (that would break powerpc builds
> with
On Thu, Apr 24, Matt Sealey wrote:
> Why not just have users who wish to use console serial port autodetection
> add 3 lines to their nvramrc?
The point of autodetection is that no userinteraction is required.
I guess the serial driver does not probe the configured hardware port
speed anymore (i
51 matches
Mail list logo
