On Thu, Sep 25, 2008 at 01:21:23PM -0500, Scott Wood wrote:
> Grant Likely wrote:
>> On Thu, Sep 25, 2008 at 11:59 AM, Scott Wood <[EMAIL PROTECTED]> wrote:
>>> On Tue, Sep 23, 2008 at 09:02:56AM -0600, Grant Likely wrote:
For example:
/ {
model = "pengutronix,super-sexy-board"
On Mon, Sep 22, 2008 at 09:43:57PM +0200, Wolfram Sang wrote:
> Hello all,
>
> I understood that the device-tree is for describing hardware and should
> not contain driver specific information. I have problems drawing this
> line right now. I made a driver for watchdogs which are pinged by
> toggl
(I trimmed the cc list for the implementation discussion).
> On Wed, 24 Sep 2008 11:42:15 -0500 Milton Miller
> <[EMAIL PROTECTED]> wrote:
>
> > On Sep 24, 2008, at 7:30 AM, Sebastien Dugue wrote:
> > > Hi Milton,
> > > On Wed, 24 Sep 2008 04:58:22 -0500 (CDT) Milton Miller
> > > <[EMAIL PROTE
* Milton Miller | 2008-09-23 20:46:18 [-0500]:
>On Wed Sep 24 at about 06:38:57 EST in 2008, Sebastian Siewior wrote:
>> My mylinux binary incl. bss is ~5 MiB without bss less than 4 MiB.
>> Therefore I though that I could replace ei.memsize with ei.loadsize. It
>> didn't work. I'm not sure why it
On Thu, 2008-09-25 at 13:52 -0500, Scott Wood wrote:
> On Thu, Sep 25, 2008 at 05:01:36PM +1000, Benjamin Herrenschmidt wrote:
> > +#define XGLUE(a,b) a##b
> > +#define GLUE(a,b) XGLUE(a,b)
>
> GLUE() doesn't appear to be used.
Yup, obsolete remains from an earlier variant.
Ben.
__
> I hadn't really wanted to go down this route because the calculation of
> the clock, or the decision to use an external clock or calculate an
> internal clock is very board specific. I'll need to take another look
> to decide if it is reasonable to encode it into the device tree.
Could be done
Vitaly Mayatskikh <[EMAIL PROTECTED]> wrote:
> + if (!logging_enabled) {
> + spin_unlock_irqrestore(&rtasd_log_lock, s);
> + error = -ENODATA;
> + goto out;
> + } else
> + nvram_clear_error_log(
>One more thing noticed while building the kernel, it gave warning
>
>kernel/power/Kconfig:97:warning: 'select' used by config symbol
>'PM_SLEEP_SMP' refers to undefined symbol 'HOTPLUG_CPU'
Apologies, this is not related to the Fix.
Please ignore my previous post.
>
>Thanks
>Halesh
>
>
>
>
>>-
One more thing noticed while building the kernel, it gave warning
kernel/power/Kconfig:97:warning: 'select' used by config symbol
'PM_SLEEP_SMP' refers to undefined symbol 'HOTPLUG_CPU'
Thanks
Halesh
>-Original Message-
>From: Sadashiiv, Halesh
>Sent: Wednesday, September 24, 2008 2:
I have tested the provided patch on PPC32 with little modifications.
Test passed on the PPC32.
Modification to Arnd's Patch:
In systbl.h you have changed
-SYSX(sys_ni_syscall,sys_ni_syscall,ppc_select)
+SYSCALL(sys_ni_syscall)
That has to be
Timur Tabi wrote:
Scott Wood wrote:
I chose subsys_initcall() to increase the probability that fsldma is
already present when DMA clients are loaded/initialized and register.
If there's no dependency, why does it matter whether fsldma is already
present?
Re-read my explanation, please.
I r
- Original Message Follows -
From: Sebastian Siewior <[EMAIL PROTECTED]>
To: Milton Miller <[EMAIL PROTECTED]>
Cc: linuxppc-dev@ozlabs.org, David Gibson
<[EMAIL PROTECTED]>, Grant Likely
<[EMAIL PROTECTED]>
Subject: Re: [RFC] powerpc/boot: compare _start against
ei.loadsize instead ei.memsi
Scott Wood wrote:
>> I chose subsys_initcall() to increase the probability that fsldma is
>> already present when DMA clients are loaded/initialized and register.
>
> If there's no dependency, why does it matter whether fsldma is already
> present?
Re-read my explanation, please. Technically,
Timur Tabi wrote:
There are no dependencies. fsldma registers with the DMA engine,
which is always built in-kernel. The DMA engine is what handles
linking DMA clients to DMA drivers. The DMA clients get a callback
whenever a DMA driver registers with the DMA engine. If the DMA
driver is alread
On Thu, Sep 25, 2008 at 05:01:36PM +1000, Benjamin Herrenschmidt wrote:
> +#define XGLUE(a,b) a##b
> +#define GLUE(a,b) XGLUE(a,b)
GLUE() doesn't appear to be used.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/
On Thu, Sep 25, 2008 at 1:40 PM, Scott Wood <[EMAIL PROTECTED]> wrote:
> If there's a dependency there, how will it work when this is built as a
> module?
There are no dependencies. fsldma registers with the DMA engine,
which is always built in-kernel. The DMA engine is what handles
linking DMA
On Thu, Sep 25, 2008 at 08:54:30AM -0500, Timur Tabi wrote:
> Li Yang wrote:
>
> >> -subsys_initcall(of_fsl_dma_chan_init);
> >> subsys_initcall(of_fsl_dma_init);
> >
> > Not a critical problem. But module_init() are preferred for modules.
>
> This was intentional. When compiled as a module,
rtas_log_read() doesn't check file flags for O_NONBLOCK and blocks
non-blocking reader of /proc/ppc64/rtas/error_log if there's no data
available. This patch fixes the problem.
Signed-off-by: Vitaly Mayatskikh <[EMAIL PROTECTED]>
diff --git a/arch/powerpc/platforms/pseries/rtasd.c
b/arch/powerpc
Today the API is still based on a fact that QE gpio controllers
are registered. If they aren't, the API won't work (gracefully
though).
There is one caveat though: if anybody occupied the node->data
before us, or overwrote it, then bad things will happen. Luckily
this is all in the platform code t
Factored out of of_get_gpio(). Will be used by the QE pin multiplexing
functions (they need to parse the gpios = <> too).
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
drivers/of/base.c | 111
drivers/of/gpio.c | 77 +++---
Here is the sketch, only for RFC. It is tested to work, but there could be
silly thinkos anyway. I'll review the changes once again later...
Anyhow... David, is this approach looks ok? Or I'm hopeless..? ;-)
--
Anton Vorontsov
email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
_
Grant Likely wrote:
On Thu, Sep 25, 2008 at 11:59 AM, Scott Wood <[EMAIL PROTECTED]> wrote:
On Tue, Sep 23, 2008 at 09:02:56AM -0600, Grant Likely wrote:
For example:
/ {
model = "pengutronix,super-sexy-board";
#address-cells = <1>;
#size-cells = <1>;
super-sexy-board,wa
On Tue, Sep 23, 2008 at 10:38:57PM +0200, Sebastian Siewior wrote:
> My current (working) solution is to move cuImage from 4 MiB to 8 MiB.
> Something similar has been done for pSeries in 9b09c6d "powerpc: Change
> the default link address for pSeries zImage kernels". Would it be
> appropriate to m
On Thu, Sep 25, 2008 at 12:02 PM, Jon Smirl <[EMAIL PROTECTED]> wrote:
> The new mpc5200 datasheet has removed the option of using a 16x
> multiplier on a 33Mhz crystal and running the core at 528Mhz. The new
> datasheet only allows up to 400Mhz for the core. Anyone know what is
> going on?
You me
On Thu, Sep 25, 2008 at 11:59 AM, Scott Wood <[EMAIL PROTECTED]> wrote:
>
> On Tue, Sep 23, 2008 at 09:02:56AM -0600, Grant Likely wrote:
> > For example:
> > / {
> > model = "pengutronix,super-sexy-board";
> > #address-cells = <1>;
> > #size-cells = <1>;
> > super-sexy-boar
On Thu, Sep 25, 2008 at 12:57 PM, Grant Likely
<[EMAIL PROTECTED]> wrote:
> On Thu, Sep 25, 2008 at 09:51:14AM +0200, Juergen Beisert wrote:
>> Benjamin,
>>
>> On Mittwoch, 24. September 2008, Benjamin Herrenschmidt wrote:
>> > On Wed, 2008-09-24 at 12:15 -0600, Grant Likely wrote:
>> > > On Wed, S
On Tue, Sep 23, 2008 at 09:02:56AM -0600, Grant Likely wrote:
> For example:
> / {
> model = "pengutronix,super-sexy-board";
> #address-cells = <1>;
> #size-cells = <1>;
> super-sexy-board,watchdog-gpio = <&gpio_simple 19 0>;
> ...
> }
Why as a property of the root no
On Thu, Sep 25, 2008 at 09:51:14AM +0200, Juergen Beisert wrote:
> Benjamin,
>
> On Mittwoch, 24. September 2008, Benjamin Herrenschmidt wrote:
> > On Wed, 2008-09-24 at 12:15 -0600, Grant Likely wrote:
> > > On Wed, Sep 24, 2008 at 05:16:34PM +0200, Juergen Beisert wrote:
> > > > On Dienstag, 23.
On Thu, Sep 25, 2008 at 07:22:25AM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2008-09-24 at 12:15 -0600, Grant Likely wrote:
> > On Wed, Sep 24, 2008 at 05:16:34PM +0200, Juergen Beisert wrote:
> > > On Dienstag, 23. September 2008, Juergen Beisert wrote:
> > > > What Kernel do you run on your
On Fri, Sep 19, 2008 at 05:11:15PM +0200, Peter Korsgaard wrote:
> Anton> This is purposely. We also need support for 8610, and maybe
> Anton> later we'll find another chip with the same unit. So, to not touch
> Anton> the Kconfig for every new chip I just made it PPC32-wide. Other
> Anton> opt
On Fri, Sep 19, 2008 at 01:46:49PM -0500, Kumar Gala wrote:
> You are correct we try to avoid this, but than I suggest we do it by
> family. I think its confusing to show 8610 and 8349 in the same dev
> tree.
I don't think it's confusing (at least, not moreso than picking an
arbitrary chip wi
On Thu, Sep 25, 2008 at 11:33:35PM +0800, Wang Jian wrote:
> Li Yang wrote:
>> On Thu, Sep 25, 2008 at 4:54 PM, Wang Jian <[EMAIL PROTECTED]> wrote:
>>> The alternative fix can be.
>>
>> This one is better as 0 is defined as 'invalid irq' for all
>> architectures. Added linux-ide and Anton to cc.
> The current implementation of fdt_get_path() has a couple of bugs,
> fixed by this patch.
>
> First, contrary to its documentation, on success it returns the length
> of the node's path, rather than 0. The testcase is correspondingly
> wrong, and the patch fixes this as well.
>
> Second, in so
Li Yang wrote:
On Thu, Sep 25, 2008 at 4:54 PM, Wang Jian <[EMAIL PROTECTED]> wrote:
The alternative fix can be.
This one is better as 0 is defined as 'invalid irq' for all
architectures. Added linux-ide and Anton to cc.
However, this is not very true. Just git grep "#define NO_IRQ" and see
In search our code base we have the following set of properties:
"linux,boot-cpu"
"linux,boot-display"
"linux,bootx-addr"
"linux,bootx-depth"
"linux,bootx-height"
"linux,bootx-linebytes"
"linux,bootx-width"
"linux,crashkernel-base"
"linux,crashkernel-size"
"linux,drconf-usable-memory"
"linux,htab
Can anyone tell me if "linux,memory-limit" is specified anywhere. and
if so where and if not what its intent is?
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Li Yang wrote:
>> -subsys_initcall(of_fsl_dma_chan_init);
>> subsys_initcall(of_fsl_dma_init);
>
> Not a critical problem. But module_init() are preferred for modules.
This was intentional. When compiled as a module, subsys_initcall becomes
module_init(). When compiled in-kernel, this code i
On Thu, Sep 25, 2008 at 08:11:29AM -0400, Josh Boyer wrote:
>On Thu, 25 Sep 2008 12:39:04 +1000
>David Gibson <[EMAIL PROTECTED]> wrote:
>
>> The PCI bridge on the Holly board is current incorrectly represented
>> in the device tree. The current device tree node for the PCI bridge
>> sits under th
On Thu, 25 Sep 2008 12:39:04 +1000
David Gibson <[EMAIL PROTECTED]> wrote:
> The PCI bridge on the Holly board is current incorrectly represented
> in the device tree. The current device tree node for the PCI bridge
> sits under the tsi-bridge node. That's not obviously wrong, but the
> PCI brid
On Thu, Sep 25, 2008 at 06:40:59PM +0800, Li Yang wrote:
> On Thu, Sep 25, 2008 at 4:54 PM, Wang Jian <[EMAIL PROTECTED]> wrote:
> > The alternative fix can be.
>
> This one is better as 0 is defined as 'invalid irq' for all
> architectures. Added linux-ide and Anton to cc.
Thanks for the correc
On Thu, Sep 25, 2008 at 4:54 PM, Wang Jian <[EMAIL PROTECTED]> wrote:
> The alternative fix can be.
This one is better as 0 is defined as 'invalid irq' for all
architectures. Added linux-ide and Anton to cc.
- Leo
>
> diff --git a/drivers/ata/pata_of_platform.c b/drivers/ata/pata_of_platform.c
Milton Miller wrote:
My current (working) solution is to move cuImage from 4 MiB to 8 MiB.
Something similar has been done for pSeries in 9b09c6d "powerpc: Change
the default link address for pSeries zImage kernels". Would it be
appropriate to move initial address to 64 MiB as the default loading
Milton Miller wrote:
On Wed Sep 24 at about 05:54:04 EST 2008, Sebastian Siewior wrote:
this could be used by the kexec userland code.
NACK.
[...]
Thanks for explanation. I just went through the kexec user land code and
saw that the 64bit code uses the device tree to obtain some address and
3
Kumar Gala wrote:
I missing why you are doing this? Do you plan on using it w/32-bit kexec?
Yes. I plan to kexec my mpc8544 board.
- k
Sebastian
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-de
As I said, I didn't spend much time on the issue, so I don't know which patch
is better. (But I do think the patch to pata_of_platform.c is better ATM).
AFAIK, powerpc is the only consumer of pata_of_platform.c, so I think this list
is better for discussion.
I should cc: Anton Vorontsov <[EMAIL
On Thu, Sep 25, 2008 at 4:36 PM, Wang Jian <[EMAIL PROTECTED]> wrote:
> Hi,
>
> This patch is to pata_platform.c but at this time, it's powerpc specific
> because it can only be triggerred using openfirmware, so I post the patch
> here. The patch is against 2.6.26-rc8.
Powerpc isn't the only arch
I wrote:
> And here's the fix.
Well, that should of course remove that comment there too. New version
below.
From: Johannes Berg <[EMAIL PROTECTED]>
Subject: powerpc: fix shutdown
I tracked down the shutdown regression to CPUs not dying
when being shut down during power-off. This turns out to
b
The alternative fix can be.
diff --git a/drivers/ata/pata_of_platform.c b/drivers/ata/pata_of_platform.c
index 408da30..1f18ad9 100644
--- a/drivers/ata/pata_of_platform.c
+++ b/drivers/ata/pata_of_platform.c
@@ -52,7 +52,7 @@ static int __devinit pata_of_platform_probe(struct of_device
*ofdev,
Hi Scott,
>> This isn't a regression since the stuff is new in 2.6.27. IMHO this can
>> wait until 2.6.28.
>
> It would be a bug in 2.6.27 that did not exist in 2.6.26... is there
> anything that used to use another mechanism that now uses this?
No, GPIO support on CPM1/CPM2 is new in 2.6.27. B
On Wed, 24 Sep 2008 11:42:15 -0500 Milton Miller <[EMAIL PROTECTED]> wrote:
> On Sep 24, 2008, at 7:30 AM, Sebastien Dugue wrote:
> > Hi Milton,
> > On Wed, 24 Sep 2008 04:58:22 -0500 (CDT) Milton Miller
> > <[EMAIL PROTECTED]> wrote:
> >> On Mon Sep 15 at 18:04:06 EST in 2008, Sebastien Dugue
Hi,
This patch is to pata_platform.c but at this time, it's powerpc specific
because it can only be triggerred using openfirmware, so I post the patch
here. The patch is against 2.6.26-rc8.
The problem is triggerred when ata device is populated using
pata_of_platform.c, and no irq is assigned (p
On Thu, 25 Sep 2008 18:36:19 +1000 Benjamin Herrenschmidt <[EMAIL PROTECTED]>
wrote:
>
> > Do you mean creating a custom fasteoi handler into xics.c? Also, it's
> > not clear to me from looking at the code how you go about changing the
> > cpu priority.
>
> Yup. I think the priority is the CP
> Do you mean creating a custom fasteoi handler into xics.c? Also, it's
> not clear to me from looking at the code how you go about changing the
> cpu priority.
Yup. I think the priority is the CPPR.. Milton can give you more
details, if not, I'll pick it up tomorrow when at the office.
Ben.
> But how to deal with platform specific things like (in this case) unknown
> external clock or usage of the internal clock generator (= how to setup the
> frequency divider)?
You can always use the platform feature hacks like I do on powermac but
we should definitely find something better. May
Benjamin,
On Mittwoch, 24. September 2008, Benjamin Herrenschmidt wrote:
> On Wed, 2008-09-24 at 12:15 -0600, Grant Likely wrote:
> > On Wed, Sep 24, 2008 at 05:16:34PM +0200, Juergen Beisert wrote:
> > > On Dienstag, 23. September 2008, Juergen Beisert wrote:
> > > > What Kernel do you run on you
On Thu, 25 Sep 2008 17:22:41 +1000 Benjamin Herrenschmidt <[EMAIL PROTECTED]>
wrote:
> On Thu, 2008-09-25 at 09:18 +0200, Sebastien Dugue wrote:
> >
> > > Ok, that's the right approach then. It should work. I don't know
> > what
> > > the specific problems with HEA are at this stage.
> >
> >
On Thu, 25 Sep 2008 07:14:07 +1000 Benjamin Herrenschmidt <[EMAIL PROTECTED]>
wrote:
>
> > There may be some implicit assumption in that we expect the cpu
> > priority to be returned to normal by the EOI, but there is nothing in
> > the hardware that requires the EOI to come from the same cpu
On Thu, 2008-09-25 at 09:18 +0200, Sebastien Dugue wrote:
>
> > Ok, that's the right approach then. It should work. I don't know
> what
> > the specific problems with HEA are at this stage.
>
> Yep, except as it behaves in way that the current -rt fasteoi flow
> cannot handle.
We probably need
On Thu, 25 Sep 2008 07:15:17 +1000 Benjamin Herrenschmidt <[EMAIL PROTECTED]>
wrote:
> On Wed, 2008-09-24 at 14:35 +0200, Sebastien Dugue wrote:
> > Hi Ben,
> >
> > On Wed, 24 Sep 2008 20:17:47 +1000 Benjamin Herrenschmidt <[EMAIL
> > PROTECTED]> wrote:
> >
> > > On Wed, 2008-09-24 at 04:58 -0
I noticed that our ABI says callers are responsible for sign extending.
That means that all int, long or similarly signed arguments to syscalls
must be explicitly sign-extended.
We already have wrappers to do that for -some- syscalls in arch code.
Those are in C and pretty ugly, copy/pasting a bun
60 matches
Mail list logo
