pci_dma_dev_setup_pSeriesLP() should use of_get_next_parent() to safely
iterate through the parent nodes.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/pseries/iommu.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc
pci_dma_dev_setup_pSeries() should use of_get_next_parent() to safely
iterate through the parent nodes.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/pseries/iommu.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platform
pci_dma_bus_setup_pSeriesLP() should use of_get_next_parent() to safely
iterate through the parent nodes.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/pseries/iommu.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platfo
pci_dma_bus_setup_pSeries() should use of_get_next_parent() to safely
iterate through the parent nodes.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/pseries/iommu.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/pla
Iterating through a device node's parents is simple enough, but dealing
with the refcounts properly is a little ugly, and replicating that logic
is asking for someone to get it wrong or forget it all together, eg:
while (dn != NULL) {
/* loop body */
tmp = of_get_parent(dn);
This patch introduces a new version of dts file, distinguished from
older files by starting with the special token /dts-v1/. dts files in
the new version take C-style literals instead of the old bare hex or
OF-style base notation. In addition, the "range" for of memreserve entries
(/memreserve/ f
The current scheme of having CELLDATA and MEMRESERVE states to
recognize hex literals instead of node or property names is
arse-backwards. The patch switches things around so that literals are
lexed in normal states, and property/node names are only recognized in
the special PROPNODENAME state, wh
So I've been doing some thinking and coding today on the dts-versioning
/ new-style literals issue. Here's a set of two patches which need a
little polish, but I think demonstrate a better way to handle the
transition; and a start on some not-directly-related improvements to the
parser design. So
From: Mark A. Greer <[EMAIL PROTECTED]>
Create necessary device nodes so that the MTD subsystem recognizes
the MTD entries in the prpmc2800's DTS file. Also bring MTD section
of the prpmc2800's DTS file up to the current DTS specification.
Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]>
---
Wit
On Thu, Oct 25, 2007 at 05:46:19PM +0200, Marian Balakowicz wrote:
> Grant Likely wrote:
> > On 10/25/07, Martin Krause <[EMAIL PROTECTED]> wrote:
[snip]
> >> On a board with 16 MiB FLASH for example the "big-fs" _and_ the "misc"
> >> partition could not be used. "big-fs", because the memory is too
On Thu, Oct 25, 2007 at 01:24:57PM -0500, Jon Loeliger wrote:
> So, like, the other day David Gibson mumbled:
> > > Use of "d#', "o#", "h#" and "b#" are gone in version 1.
> >
> > Also good. We might want to keep b#, since there's no C way of doing
> > binary literals, but in that case I'd sugges
On Fri, Oct 26, 2007 at 10:23:53AM +1000, Stephen Rothwell wrote:
> Hi Mark,
>
> On Thu, 25 Oct 2007 16:39:48 -0700 "Mark A. Greer" <[EMAIL PROTECTED]> wrote:
> >
> > +static int __init prpmc2800_register_mtd(void)
> > +{
> > + struct device_node *np = NULL;
> ^
Hi Mark,
On Thu, 25 Oct 2007 16:39:48 -0700 "Mark A. Greer" <[EMAIL PROTECTED]> wrote:
>
> +static int __init prpmc2800_register_mtd(void)
> +{
> + struct device_node *np = NULL;
^^^
Not needed if you use for_each_compatible_node().
> +
> + while ((np = o
On Thu, 25 Oct 2007 13:29:08 -0700
"Dale Farnsworth" <[EMAIL PROTECTED]> wrote:
> On Thu, Oct 25, 2007 at 09:41:14PM +0200, Domen Puncer wrote:
> > On 25/10/07 11:57 -0700, Dale Farnsworth wrote:
> > > Domen wrote:
> > > > > use your platform's dma mapping functions, rather than virt_to_phys()
> >
From: Mark A. Greer <[EMAIL PROTECTED]>
The prpmc2800 bootwrapper code currently overwrites the DTS' user FLASH
size with a predetermined value. Intead make it use whatever is specified
in the DTS unless the prpmc2800 variant the bootwrapper is running on has
no user FLASH. In that case, set the
From: Mark A. Greer <[EMAIL PROTECTED]>
Create necessary device nodes so that the MTD subsystem recognizes
the MTD entries in the prpmc2800's DTS file. Also bring MTD section
of the prpmc2800's DTS file up to the current DTS specification.
Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]>
---
ar
Dale Farnsworth wrote:
> IMO, it's still a requirement that we call dma_unmap_single() for
> each call to dma_map_single().
Yep...
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Valentine Barshak wrote:
> Matt Sealey wrote:
>> Compatible property on /[EMAIL PROTECTED]/[EMAIL PROTECTED] is
>
> We should also keep "ohci-bigendian" and "ohci-be" in the match table.
Eh.. maybe.
>> I am currently moving on the assumption that the "correct" device
>> tree for the Efika (notwi
> From: Rune Torgersen
> Sent: Thursday, October 25, 2007 2:40 PM
> On any kernel newer than 2.6.20, settimeofday does not work.
> I try to set the current date, but when I read back the time, it is
> still the old date (in our case, Jan 1 1970)
Eventually the date actually got updated. Before t
On Thu, 2007-10-25 at 22:16 +0400, Valentine Barshak wrote:
> PowerPC 440EP(x) 440GR(x) processors have the same PVR values, since
> they have identical cores. However, FPU is not supported on GR(x) and
> enabling APU instruction broadcast in the CCR0 register (to enable FPU)
> may cause unpredict
On Thu, Oct 25, 2007 at 09:41:14PM +0200, Domen Puncer wrote:
> On 25/10/07 11:57 -0700, Dale Farnsworth wrote:
> > Domen wrote:
> > > > use your platform's dma mapping functions, rather than virt_to_phys()
> > > >
> > > > it might be the exact same implementation, inside the platform
> > > > int
On 25/10/07 11:57 -0700, Dale Farnsworth wrote:
> Domen wrote:
> > > use your platform's dma mapping functions, rather than virt_to_phys()
> > >
> > > it might be the exact same implementation, inside the platform
> > > internals, but drivers should not be using this directly.
> >
> > I've repla
Hi
I upgraded my board-port from 2.6.18 (8280 in arch/ppc) to 2.6.23 (Yes,
I know, arch/powerpc. I am planning on doing that, I just wanted the old
stuff working first).
On any kernel newer than 2.6.20, settimeofday does not work.
I try to set the current date, but when I read back the time, it i
On Thu, 2007-25-10 at 15:23 +0200, Johannes Berg wrote:
> On Wed, 2007-10-24 at 10:29 -0400, Dmitry Torokhov wrote:
>
> > Do yo know who has powerbooks with older geyser models (0x214, 215,
> > 216)?
>
> Not sure, Benjamin? We're talking about the touchpad, just lsusb should
> be enough.
lsusb
Domen wrote:
> > use your platform's dma mapping functions, rather than virt_to_phys()
> >
> > it might be the exact same implementation, inside the platform
> > internals, but drivers should not be using this directly.
>
> I've replaced this with dma_map_single(), unmatched with
> dma_unmap_sin
Matt Sealey wrote:
> Compatible property on /[EMAIL PROTECTED]/[EMAIL PROTECTED] is
>
> ohci-bigendian
> ohci-be
> mpc5200-ohci
> mpc5200-usb
>
> device_type is "usb", model is "mpc5200-ohci".
>
> Although I worry about cluttering up the cleanup, it is probably just
> adding an "if property(big-
PowerPC 440EP(x) 440GR(x) processors have the same PVR values, since
they have identical cores. However, FPU is not supported on GR(x) and
enabling APU instruction broadcast in the CCR0 register (to enable FPU)
may cause unpredictable results. There's no safe way to detect FPU
support at runtime. T
So, like, the other day David Gibson mumbled:
> > Use of "d#', "o#", "h#" and "b#" are gone in version 1.
>
> Also good. We might want to keep b#, since there's no C way of doing
> binary literals, but in that case I'd suggest recognizing it at the
> lexical level, not the grammar level as we do
Matt Sealey wrote:
> Valentine,
>
> Please do the very minimal required to keep supporting the Efika.
>
> As for an little endian OHCI controller on an OF bus, I would not
> consider it an impossibility. But, not having the big-endian
> property fixes this; OHCI is little-endian by default. You n
Valentine,
Please do the very minimal required to keep supporting the Efika.
As for an little endian OHCI controller on an OF bus, I would not
consider it an impossibility. But, not having the big-endian
property fixes this; OHCI is little-endian by default. You need
only report "difference" in d
Grant Likely wrote:
> On 10/25/07, Valentine Barshak <[EMAIL PROTECTED]> wrote:
>
> If it doesn't, it can be added during prom_init.c We're already doing
> a bunch of efika fixups there anyway.
I want those to go away. Far, far away.
http://www.powerdeveloper.org/platforms/efika/devicetree
No
On Tue, Oct 23, 2007 at 04:24:04PM -0500, Scott Wood wrote:
> +#ifdef CONFIG_SUSPEND
> +void generic_suspend_disable_irqs(void)
> +{
> + preempt_disable();
> +
> + /* Disable the decrementer, so that it doesn't interfere
> + * with suspending.
> + */
> +
> + set_dec(0x7fff
Compatible property on /[EMAIL PROTECTED]/[EMAIL PROTECTED] is
ohci-bigendian
ohci-be
mpc5200-ohci
mpc5200-usb
device_type is "usb", model is "mpc5200-ohci".
Although I worry about cluttering up the cleanup, it is probably just
adding an "if property(big-endian) OR compatible(mpc5200-ohci)"
to t
Grant Likely wrote:
> On 10/25/07, Valentine Barshak <[EMAIL PROTECTED]> wrote:
>> Grant Likely wrote:
>>> On 10/24/07, David Brownell <[EMAIL PROTECTED]> wrote:
On Wednesday 24 October 2007, Matt Sealey wrote:
> Can we just make sure real quickly that the changing of compatibles
> doe
Jon Smirl wrote:
> This could work. The generic codec is a alsa soc_device_driver, not a
> of_device_driver. The codec node could instantiate the fabric as a
> of_device_driver which could then instantiate the soc_device_driver
> for the generic codec.
>
> The generic codecs are supposed to work
Grant Likely wrote:
...
>> +
>> +static int __init mpled_init(void)
>> +{
>> + int i, error;
>> +
>> + for (i = 0; i < sizeof(led) / sizeof(struct motionpro_led); i++){
>> + led[i].reg_addr = mpc52xx_find_and_map(led[i].reg_compat);
>
> Please use of-platform-bus bindings
Grant Likely wrote:
> On 10/25/07, Martin Krause <[EMAIL PROTECTED]> wrote:
>>
>> < + [EMAIL PROTECTED] {
>> < + compatible = "cfi-flash";
>> < + reg = < 0200>;
>> < + bank-width = <4>;
>> < + de
David Gibson wrote:
> On Wed, Oct 24, 2007 at 01:13:33AM +0200, Marian Balakowicz wrote:
>
> [snip]
>> +[EMAIL PROTECTED] {
>> +model = "fsl,lpb";
>> +compatible = "lpb";
>
> Not nearly specific enough. Must include a vendor prefix at least,
> and should have a lot mo
On Thursday 25 October 2007, Geert Uytterhoeven wrote:
> In many cases these ioctls can indeed not be handled.
> E.g. when using `hdparm -tT /dev/ps3da', hdparm issues an ioctl to flush the
> cache. But this ioctl is not supported, not before and not after 2.6.23.
> Before 2.6.23, it didn't print t
So, like, the other day David Gibson mumbled:
> At present, all the example dtbs we use in the testsuite are version
> 17 and have reservation map, then structure block then strings block
> (the natural ordering based on alignment constraints). However, all
> libfdt's read-only and in-place write
Olof Johansson wrote:
>
> On Wed, Oct 24, 2007 at 01:13:15AM +0200, Marian Balakowicz wrote:
>> Signed-off-by: Marian Balakowicz <[EMAIL PROTECTED]>
>> ---
>
> Your patch lacks any kind of description beyond the title. (I know, it's a
> real simple patch, but a real simple description would do to
On Thu, 25 Oct 2007, Arnd Bergmann wrote:
> On Thursday 25 October 2007, Geert Uytterhoeven wrote:
> > If you want to look into this, the question is just why these messages are
> > printed now, while they weren't printed before. I don't think any other
> > behavior got changed.
>
> I'm not so sur
So, like, the other day David Gibson mumbled:
> The fdt_set_header() macro casts an arbitrary pointer into (struct
> fdt_header *) to set fdt header fields. While we need to change the
> type, so that we can use this macro on the usual (void *) used to
> represent a device tree blob, the current m
Milton Miller wrote:
> On Wed Oct 24 17:11:29 EST 2007, Stephen Rothwell wrote:
>> On Wed, 24 Oct 2007 01:13:09 +0200 Marian Balakowicz wrote:
>>> + root = of_find_node_by_path("/");
>>> + if (root)
>>> + model = of_get_property(root, "model", NULL);
>>> +
So, like, the other day David Gibson mumbled:
> Add documentation for another handful of libfdt functions to libfdt.h
>
> Signed-off-by: David Gibson <[EMAIL PROTECTED]>
Applied.
jdl
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.
Hi
I can able to find RFS for ppc in denx website
But that RFS does not support X windows
Any Pre-compiled RFS for ppc is available ?
or
Help me to create RFS including X window support for ppc
Regards
Vishnu
___
Linuxppc-dev mailing list
Linuxppc-dev@o
On Thursday 25 October 2007, Geert Uytterhoeven wrote:
> If you want to look into this, the question is just why these messages are
> printed now, while they weren't printed before. I don't think any other
> behavior got changed.
I'm not so sure about that. The reason that the messages are printed
On 10/25/07, Valentine Barshak <[EMAIL PROTECTED]> wrote:
> Grant Likely wrote:
> > On 10/24/07, David Brownell <[EMAIL PROTECTED]> wrote:
> >> On Wednesday 24 October 2007, Matt Sealey wrote:
> >>> Can we just make sure real quickly that the changing of compatibles
> >>> doesn't break existing, no
David Gibson wrote:
> On Wed, Oct 24, 2007 at 01:13:09AM +0200, Marian Balakowicz wrote:
>> Print out '/model' property as a machine name in generic
>> show_cpuinfo() routine.
>
> There's no such thing as /model; subnodes and properties have a
> different namespace, so the root node, /, has a prop
On 10/25/07, Martin Krause <[EMAIL PROTECTED]> wrote:
>
>
> < + [EMAIL PROTECTED] {
> < + compatible = "cfi-flash";
> < + reg = < 0200>;
> < + bank-width = <4>;
> < + device-width = <2>;
> < +
On Thu, 25 Oct 2007, Johannes Berg wrote:
> On Wed, 2007-10-24 at 16:27 +0200, Arnd Bergmann wrote:
> > On Wednesday 24 October 2007, Johannes Berg wrote:
> > > Show Details
> > > I've been getting these warnings (many more of them but this is a list
> > > of unique ones) on my quad G5 with 32-
On Wed, 2007-10-24 at 16:27 +0200, Arnd Bergmann wrote:
> On Wednesday 24 October 2007, Johannes Berg wrote:
> > Show Details
> > I've been getting these warnings (many more of them but this is a list
> > of unique ones) on my quad G5 with 32-bit userspace:
> >
> > ioctl32(cdrom_id:1078): Unkn
On Wed, 2007-10-24 at 10:29 -0400, Dmitry Torokhov wrote:
> Do yo know who has powerbooks with older geyser models (0x214, 215,
> 216)?
Not sure, Benjamin? We're talking about the touchpad, just lsusb should
be enough.
> It would be nice to know if they send the data continiously and
> whether
Hello.
Benjamin Herrenschmidt wrote:
>>>Not sure when this started happening, but I wanted to report it. I'll
>>>start bisecting in a day or two if noone else has gotten around to
>>>looking at it:
>>>$ echo "int main(void) { while(1); }" > test.c ; gcc test.c
>>>$ time ./a.out & sleep 2 ; killa
On 24/10/07 14:14 -0600, Grant Likely wrote:
> On 10/24/07, Domen Puncer <[EMAIL PROTECTED]> wrote:
> > On 24/10/07 12:24 -0600, Grant Likely wrote:
> > > Domen,
> > >
> > > Here's a real solution to the problem. I've somewhat tested this on
> > > the lite5200b. Can you give it a spin on efika an
Grant Likely wrote:
> On 10/24/07, David Brownell <[EMAIL PROTECTED]> wrote:
>> On Wednesday 24 October 2007, Matt Sealey wrote:
>>> Can we just make sure real quickly that the changing of compatibles
>>> doesn't break existing, not-easily-flashable firmwares?
>> Yeah, I'm not keen on such breakage
On Wed, 24 Oct 2007, Scott Wood wrote:
> The ps3 target produces two images, and the binary one is not the
> "primary" image that corresponds to the -o flag; thus, it no longer
> uses the generic binary flag.
>
> On platforms which do use the binary flag, it no longer produces a
> .bin suffix, so
< + [EMAIL PROTECTED] {
< + compatible = "cfi-flash";
< + reg = < 0200>;
< + bank-width = <4>;
< + device-width = <2>;
< + #size-cells = <1>;
< + #addres
Domen Puncer wrote:
> +static int mpc52xx_fec_alloc_rx_buffers(struct bcom_task *rxtsk)
> +{
> + while (!bcom_queue_full(rxtsk)) {
> + struct sk_buff *skb;
> + struct bcom_fec_bd *bd;
> +
> + skb = dev_alloc_skb(FEC_RX_BUFFER_SIZE);
> + if (skb ==
On Wed, 24 Oct 2007, Geert Uytterhoeven wrote:
> On Wed, 17 Oct 2007, Scott Wood wrote:
> > Geert Uytterhoeven wrote:
> > >> diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
> > >> index 39b27e5..795f988 100755
> > >> --- a/arch/powerpc/boot/wrapper
> > >> +++ b/arch/powerpc/boot/
Jan-Bernd Themann wrote:
> napi_disable / napi_enable must be applied on all ehea queues.
>
> Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
applied
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxp
61 matches
Mail list logo
