Paulus,
Can you take the crash shutdown hook patches as well for 2.6.25?
http://patchwork.ozlabs.org/linuxppc/patch?person=414&id=15546
http://patchwork.ozlabs.org/linuxppc/patch?person=414&id=15547
Mikey
In message <[EMAIL PROTECTED]> you wrote:
> Aegis Lin (1):
> [POWERPC] spufs: Use s
Fix a bug in the printing of the os-area magic numbers which assumed that
magic numbers were zero terminated strings. The magic numbers are represented
in memory as integers. If the os-area sections are not initialized correctly
they could contained random data that would be printed to the displa
On 12/20/2007 08:44 PM, Paul Mackerras wrote:
> Geoff Levand writes:
>
>> Fix a bug in the printing of the os-area magic numbers which assumed that
>> magic numbers were zero terminated strings. The magic numbers are
>> represented
>> in memory as integers. If the os-area sections are not initi
Hi all,
> To the question, where what it should go, I'd leave the decision to
> Jeremy, but my current idea would be:
>
> arch/powerpc/platforms/cell/spufs -> arch/powerpc/spufs
I'd suggest arch/powerpc/sysdev/spufs to keep arch/powerpc clean.
However, this may also depend on the (intended) stru
On Fri, 21 Dec 2007 19:48:28 -0600 Josh Boyer <[EMAIL PROTECTED]> wrote:
>
> On Sat, 22 Dec 2007 11:21:05 +1100
> Stephen Rothwell <[EMAIL PROTECTED]> wrote:
>
> > On Fri, 21 Dec 2007 15:39:34 +1100 Benjamin Herrenschmidt <[EMAIL
> > PROTECTED]> wrote:
> > >
> > > +++ linux-merge/arch/powerpc/pla
On Sun, Dec 23, 2007 at 03:49:30AM +0100, Segher Boessenkool wrote:
> > +int __of_parse_gpio_bank_pin(struct device_node *np, int index,
> > +int bank_width, int max_bank)
> > +{
> > + int bank;
> > + int pin;
> > + const u32 *gpios;
> > +
> > + /*
> > +* We can
On Sun, Dec 23, 2007 at 03:47:50AM +0100, Segher Boessenkool wrote:
> > OF device tree GPIOs bindings are similar to IRQs:
>
> But GPIOs are a very different thing. Most importantly, the "number"
> of a GPIO is completely local to the GPIO controller.
Yes... just as interrupt specifiers are loca
Add a comment to the DTS file for the MPC8641 HPCN describing a wiring change
needed to get sound working on this board.
Signed-off-by: Timur Tabi <[EMAIL PROTECTED]>
---
For a two-line comment, I thought the DTS would be the best place to put this
information.
arch/powerpc/boot/dts/mpc8641_hpc
Anton Vorontsov wrote:
> + [EMAIL PROTECTED] {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "fsl,qe";
> + ranges = <0 0xe010 0x0010>;
> + reg = <0xe010 0x480>;
> + /* filled by u-boot */
>
Anton Vorontsov wrote:
> 2. QE SCCs (slow UCCs, used as an UARTs)
I a posted a driver that provides this support, I'm just waiting for
Kumar to apply it.
What revision of the 8360 does this board use?
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.
Lee Revell wrote:
> Please use DMA_32BIT_MASK (see include/linux/dma-mapping.h) instead of
> 0x.
No prob. But did you see this comment:
/*
* NOTE: do not use the below macros in new code and do not add new
definitions
* here.
*
* Instead, just open-code DMA_BIT_MASK(n) within
Scott Wood wrote:
>> None of the SOC nodes in any DTS have a "compatible" entry.
>
> Not quite true; ep88xc, mpc8272ads, and pq2fads have them.
Ah ok. So what should the compatible entry for 8641 be?
compatible = "fsl,mpc8641"
That looks a lot like what a compatible entry for the CPU
> +int __of_parse_gpio_bank_pin(struct device_node *np, int index,
> + int bank_width, int max_bank)
> +{
> + int bank;
> + int pin;
> + const u32 *gpios;
> +
> + /*
> + * We can get there only if of_get_gpio() succeeded, thus
> + * no need checkin
> OF device tree GPIOs bindings are similar to IRQs:
But GPIOs are a very different thing. Most importantly, the "number"
of a GPIO is completely local to the GPIO controller.
> pario0: [EMAIL PROTECTED] {
> #gpio-cells = <2>;
Your Linux code doesn't actually use this. Why is it needed,
On Fri, 21 Dec 2007 23:41:30 +0300 Anton Vorontsov <[EMAIL PROTECTED]> wrote:
>
> +static int __devinit upm_chip_probe(struct of_device *ofdev,
> + const struct of_device_id *ofid)
> +{
> + struct upm_data *ud;
> + struct resource io_res;
> + const u32 *p
On Fri, 21 Dec 2007 23:39:25 +0300 Anton Vorontsov <[EMAIL PROTECTED]> wrote:
>
> +int fsl_upm_get_for(struct device_node *node, const char *name,
> + struct fsl_upm *upm)
> +{
> + int ret;
> + struct device_node *lbus;
> + struct resource lbc_res;
> + ptrdiff_t mxmr
On Fri, 21 Dec 2007 23:23:09 +0300 Anton Vorontsov <[EMAIL PROTECTED]> wrote:
>
> +static struct of_device_id mpc836x_rdk_ids[] = {
Please make this __initdata.
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgp6hCLGmk8wd.pgp
Description: PGP
On Fri, 21 Dec 2007 10:40:09 -0500 Paul Gortmaker <[EMAIL PROTECTED]> wrote:
>
> cpm2_pic_init() does its own of_node_get() so we should do an of_node_put()
> before calling it.
The of_node_put() should really go after the call to cpm2_pic_init(), that
way you retain a raised ref count at all time
Hi,
This is a very large patch. It may be easier to review if it could be
split on some logical way, that is at all possible (I don't know either
way). This is just a quick note about some more trivial things.
On Fri, 21 Dec 2007 17:58:43 +0800 Zhang Wei <[EMAIL PROTECTED]> wrote:
>
> +struct r
On Sat, 2007-12-22 at 15:11 -0600, Josh Boyer wrote:
> >
> > No, platforms/xxx isn't supposed to be shared code. That's was
> syslib is
> > for.
>
> I think you mean sysdev?
Yeah, whatever the name of the day for that thing is.
(It's syslib in arch/ppc ?)
Ben.
___
On Sun, 23 Dec 2007 07:58:02 +1100
Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
>
> On Fri, 2007-12-21 at 09:23 -0800, Geoff Levand wrote:
> >
> > It seems platforms/cell should have the shared and/or generic code,
> > and the other
> > stuff moved into a new platform directory, but is it w
On Fri, 2007-12-21 at 20:15 +0100, Arnd Bergmann wrote:
> > It seems platforms/cell should have the shared and/or generic code,
> and the other
> > stuff moved into a new platform directory, but is it worth the
> effort?
>
> There is very little code in platforms/cell that can not be generic,
>
On Fri, 2007-12-21 at 09:23 -0800, Geoff Levand wrote:
>
> It seems platforms/cell should have the shared and/or generic code,
> and the other
> stuff moved into a new platform directory, but is it worth the
> effort?
No, platforms/xxx isn't supposed to be shared code. That's was syslib is
for.
> A related question is what to do about the location of the other cell
> related files. platforms/ps3 is already pretty self-contained once we have
> spufs outside of platforms/cell, but there is still some code shared between
> platforms/cell and platforms/celleb, and each of these directories a
This patch adds device tree source, default config and setup code for
DBox2 devices.
Signed-off-by: Jochen Friedrich <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/dbox2.dts | 263
arch/powerpc/configs/dbox2_defconfig | 1042 ++
arch/powerpc/platf
On Sat, Dec 22, 2007 at 05:08:14PM +0100, Jochen Friedrich wrote:
> Hi Anton,
>
> > I also hope you'll test it. ;-)
>
> yes.
>
> > +int cpm_init_par_io(void)
> > +{
> > + struct device_node *np;
> > + const u32 *num_ports;
> > +
> > + np = of_find_node_by_name(NULL, "fsl,cpm1-p
Hi Anton,
> I also hope you'll test it. ;-)
yes.
> +int cpm_init_par_io(void)
> +{
> + struct device_node *np;
> + const u32 *num_ports;
> +
> + np = of_find_node_by_name(NULL, "fsl,cpm1-pario");
> + if (!np)
> + return -ENOENT;
> +
I guess this should be:
On Sat, Dec 22, 2007 at 01:51:30PM +1100, David Gibson wrote:
> On Fri, Dec 21, 2007 at 11:09:21AM -0600, Scott Wood wrote:
> > OK. I was being lazy. :-P
>
> In general I'd approve, but having to invoke dtc in the right place
> for the dts file is a bit too big a usability problem, I think.
Yeah
http://patchwork.ozlabs.org/linuxppc/patch?id=15192 ?
--
dwmw2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Hi Vitaly,
> I had an attempt a while ago to do this but haven't had enough time to get it
> completed, so
> I am glad to see it finally picked up. There was some sort of discussion that
> time, you seem to have some of those points
> addressed but something not, please
> check: http://lkml.org
Hi Anton,
> Jochen, I kept your Signed-off-by, though this isn't your original
> patch. Hope you're okay with it. I also hope you'll test it. ;-)
>
that's OK.
Thanks,
Jochen
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/ma
31 matches
Mail list logo
