Convert the MPC8313 RDB dts file to v1 format. Entries for
values normally parsed by humans are left in decimal (i.e. IRQ,
cache size, clock rates, basic counts and index values).
Signed-off-by: Paul Gortmaker <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mpc8313erdb.dts | 126 +
Convert the MPC8349 MITX GP dts file to v1 format. Entries for
values normally parsed by humans are left in decimal (i.e. IRQ,
cache size, clock rates, basic counts and index values).
Signed-off-by: Paul Gortmaker <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mpc8349emitxgp.dts | 107 ++
Convert the MPC8349 MITX dts file to v1 format. Entries for
values normally parsed by humans are left in decimal (i.e. IRQ,
cache size, clock rates, basic counts and index values).
Signed-off-by: Paul Gortmaker <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mpc8349emitx.dts | 153 +++
Convert the MPC832x RDB dts file to v1 format. Entries for
values normally parsed by humans are left in decimal (i.e. IRQ,
cache size, clock rates, basic counts and index values).
Signed-off-by: Paul Gortmaker <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mpc832x_rdb.dts | 150 +
Convert the MPC832x MDS dts file to v1 format. Entries for
values normally parsed by humans are left in decimal (i.e. IRQ,
cache size, clock rates, basic counts and index values).
Signed-off-by: Paul Gortmaker <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mpc832x_mds.dts | 234 +
Convert the MPC836x MDS dts file to v1 format. Entries for
values normally parsed by humans are left in decimal (i.e. IRQ,
cache size, clock rates, basic counts and index values).
Signed-off-by: Paul Gortmaker <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mpc836x_mds.dts | 254 +
This series incorporates my earlier qe/muram fix before converting
the existing mpc83xx DTS files to v1 format. I've also redone the
mpc834x_mds with the IRQs as decimal as per Kumar's comments and
re-included that too. I've kept each board as a separate commit
in case one of them conflicts with
Currently there are several dts that don't specify address or size
cells for the muram. This causes dtc to use default values, one of
which is an address-cells of two, and this breaks the parsing of the
muram ranges, which is assuming an address-cells of one. For example:
Warning (reg_format): "r
To be consistent with the other DTS v1 conversions pending,
things like cache size and IRQ values should be decimal.
Signed-off-by: Paul Gortmaker <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/sbc8349.dts | 40 ++--
1 files changed, 20 insertions(+), 20 deletions
Move mpc834x_mds device tree source forward to dts-v1 format. Nothing
too complex in this one, so it boils down to just adding a bunch of 0x
in the right places and converting clock speeds to decimal.
Signed-off-by: Paul Gortmaker <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mpc834x_mds.dts |
On Sun, 2008-01-27 at 17:13 +0100, Michel Dänzer wrote:
>
> > Do you see behavior change (from good->bad) immediately after
> applying that patch
> > during your bisect process?
>
> Yes, confirmed by trying that commit and its parent again.
Just to be paranoid... can you try with a different g
cpm_uart_core has a dependency on fsl,cpm-brg/clock-frequency, this
means that a .dts that uses the cpm uart driver needs to supply a
clock-frequency entry for get_brgfreq to return a meaningful number.
Included is a patchset which adds the correct brgclk to the adder port -
@ 50Mhz and also adds
On Sun, Jan 27, 2008 at 01:59:51PM -0700, Grant Likely wrote:
a> On 1/27/08, Anton Vorontsov <[EMAIL PROTECTED]> wrote:
> > On Sun, Jan 27, 2008 at 02:42:12PM +0100, Jochen Friedrich wrote:
> > > Hi Anton,
> > >
> > > > +static void qe_gpio_set(struct gpio_chip *gc, unsigned int gpio, int
> > > >
On 1/27/08, Anton Vorontsov <[EMAIL PROTECTED]> wrote:
> On Sun, Jan 27, 2008 at 02:42:12PM +0100, Jochen Friedrich wrote:
> > Hi Anton,
> >
> > > +static void qe_gpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
> > > +{
> > > + struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
>
Hi Paul,
On PPC, I see a disparity between clock_getres implementations in the
vdso and syscall. I am using a IBM Openpower hardware and 2.6.24 kernel
with CONFIG_HIGH_RES_TIMERS=y.
clock_getres call for CLOCK_REALTIME returns 1 millisecond. However,
when I edit arch/powerpc/kernel/vdso*/gettime
On 1/27/08, Balbir Singh <[EMAIL PROTECTED]> wrote:
> * Paul Mackerras <[EMAIL PROTECTED]> [2008-01-27 22:55:43]:
>
> > Balbir Singh writes:
> >
> > > Here's a better and more complete fix for the problem. Could you
> > > please see if it works for you? I tested it on a real NUMA box and it
> > > s
On 01/27/2008 03:15 AM, Geert Uytterhoeven wrote:
> On Sun, 27 Jan 2008, Andrew Morton wrote:
>> > On Sun, 27 Jan 2008 10:44:40 +0100 (CET) Geert Uytterhoeven <[EMAIL
>> > PROTECTED]> wrote:
>> > I posted these patches before, about 2 months ago. Unfortunately I didn't
>> > CC
>> > you at that ti
On 1/27/08, David Brownell <[EMAIL PROTECTED]> wrote:
> General comment: if you're going to index arrays by enum
> values, it's best to initialize them that way too. Else
> you're expecting a particular optional policy for how the
> enums get grown...
Even better is the way the m41t80 driver doe
General comment: if you're going to index arrays by enum
values, it's best to initialize them that way too. Else
you're expecting a particular optional policy for how the
enums get grown...
- Dave
On Monday 21 January 2008, Jean Delvare wrote:
> --- linux-2.6.24-rc8.orig/drivers/rtc/rtc-ds1307
On Sun, Jan 27, 2008 at 02:42:12PM +0100, Jochen Friedrich wrote:
> Hi Anton,
>
> > +static void qe_gpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
> > +{
> > + struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
> > + struct port_regs *regs = mm_gc->regs;
> > + u32 pin_mask;
So, like, the other day Josh Boyer mumbled:
>
> There are lots of powerpc sub-trees. Kumar's, Geoff's, mine, Olof's,
> Grant's, Vitaly's are just the ones I can think of the top of my head.
>
> Shouldn't we just ask Paul to sync up more often rather than have
> Andrew track X number of trees tha
On Sat, 2008-01-26 at 10:39 +0530, Srivatsa Vaddagiri wrote:
> On Sat, Jan 26, 2008 at 03:13:54PM +1100, Benjamin Herrenschmidt wrote:
>
> > > Also were the dd process and the niced processes running under
> > > different user ids? If so, that is expected behavior, that we divide
> > > CPU equa
* Paul Mackerras <[EMAIL PROTECTED]> [2008-01-27 22:55:43]:
> Balbir Singh writes:
>
> > Here's a better and more complete fix for the problem. Could you
> > please see if it works for you? I tested it on a real NUMA box and it
> > seemed to work fine there.
>
> There are a couple of other chang
On Sun, 27 Jan 2008 12:15:28 +0100 (CET)
Geert Uytterhoeven <[EMAIL PROTECTED]> wrote:
> Hi Andrew,
>
> On Sun, 27 Jan 2008, Andrew Morton wrote:
> > > On Sun, 27 Jan 2008 10:44:40 +0100 (CET) Geert Uytterhoeven <[EMAIL
> > > PROTECTED]> wrote:
> > > On Sat, 26 Jan 2008, Andrew Morton wrot
Hi Anton,
> +static void qe_gpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
> +{
> + struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
> + struct port_regs *regs = mm_gc->regs;
> + u32 pin_mask;
> + u32 tmp_val;
> +
> + /* calculate pin location */
> + pin_
Balbir Singh writes:
> Here's a better and more complete fix for the problem. Could you
> please see if it works for you? I tested it on a real NUMA box and it
> seemed to work fine there.
There are a couple of other changes in behaviour that your patch
introduces, and I'd like to understand them
Hi Andrew,
On Sun, 27 Jan 2008, Andrew Morton wrote:
> > On Sun, 27 Jan 2008 10:44:40 +0100 (CET) Geert Uytterhoeven <[EMAIL
> > PROTECTED]> wrote:
> > On Sat, 26 Jan 2008, Andrew Morton wrote:
> > > > On Fri, 25 Jan 2008 16:06:23 +0100 Geert Uytterhoeven <[EMAIL
> > > > PROTECTED]> wrot
> On Sun, 27 Jan 2008 10:44:40 +0100 (CET) Geert Uytterhoeven <[EMAIL
> PROTECTED]> wrote:
> Hi Andrew,
>
> On Sat, 26 Jan 2008, Andrew Morton wrote:
> > > On Fri, 25 Jan 2008 16:06:23 +0100 Geert Uytterhoeven <[EMAIL PROTECTED]>
> > > wrote:
> > > Hare are the ps3av/fb patches for 2.6.25:
On Sat, 26 Jan 2008, Andrew Morton wrote:
> > On Fri, 25 Jan 2008 16:06:32 +0100 Geert Uytterhoeven <[EMAIL PROTECTED]>
> > wrote:
> > static int ps3fb_cmp_mode(const struct fb_videomode *vmode,
> > const struct fb_var_screeninfo *var)
> > {
> > - /* resolution + black bo
Hi Andrew,
On Sat, 26 Jan 2008, Andrew Morton wrote:
> > On Fri, 25 Jan 2008 16:06:23 +0100 Geert Uytterhoeven <[EMAIL PROTECTED]>
> > wrote:
> > Hare are the ps3av/fb patches for 2.6.25:
>
> I would have to say: it's a bit late to be submitting things of this nature
> for 2.6.25. Given
On Sat, 26 Jan 2008, Andrew Morton wrote:
> > On Fri, 25 Jan 2008 16:06:27 +0100 Geert Uytterhoeven <[EMAIL PROTECTED]>
> > wrote:
> > From: Geert Uytterhoeven <[EMAIL PROTECTED]>
> >
> > ps3fb: inline the X_OFF(), Y_OFF(), WIDTH(), HEIGHT(), and VP_OFF() macros,
> > as they're used in one place
31 matches
Mail list logo
