* Root file system for powerpc 74xx board
From: mahendra varman @ 2007-10-23 14:51 UTC (permalink / raw)
To: XFree86, xorg, linuxppc-embedded, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 422 bytes --]
Hi All
Iam a beginner/Learner in this field.
I have Linux running on an intel x86 machine with cross development
environment.
I want to host 74xx file system with Xfree86 and library support on the
intel machine.
I will boot the file system using NFS to the 74xx system.
How to create/extract the file system with xfree86 support from fedora file
system ?
Please help me on the above
Thanks in advance
Mahendra
[-- Attachment #2: Type: text/html, Size: 505 bytes --]
^ permalink raw reply
* [PATCH] [POWERPC] Fix fallout from sg_page changes
From: Dale Farnsworth @ 2007-10-23 14:53 UTC (permalink / raw)
To: Jens Axboe; +Cc: linuxppc-dev, linux-kernel
Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
---
include/asm-powerpc/dma-mapping.h | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/include/asm-powerpc/dma-mapping.h b/include/asm-powerpc/dma-mapping.h
index 65be95d..43b4f3b 100644
--- a/include/asm-powerpc/dma-mapping.h
+++ b/include/asm-powerpc/dma-mapping.h
@@ -285,9 +285,9 @@ dma_map_sg(struct device *dev, struct scatterlist *sgl, int nents,
BUG_ON(direction == DMA_NONE);
for_each_sg(sgl, sg, nents, i) {
- BUG_ON(!sg->page);
- __dma_sync_page(sg->page, sg->offset, sg->length, direction);
- sg->dma_address = page_to_bus(sg->page) + sg->offset;
+ BUG_ON(!sg_page(sg));
+ __dma_sync_page(sg_page(sg), sg->offset, sg->length, direction);
+ sg->dma_address = virt_to_bus(sg_virt(sg));
}
return nents;
@@ -328,7 +328,7 @@ static inline void dma_sync_sg_for_cpu(struct device *dev,
BUG_ON(direction == DMA_NONE);
for_each_sg(sgl, sg, nents, i)
- __dma_sync_page(sg->page, sg->offset, sg->length, direction);
+ __dma_sync_page(sg_page(sg), sg->offset, sg->length, direction);
}
static inline void dma_sync_sg_for_device(struct device *dev,
@@ -341,7 +341,7 @@ static inline void dma_sync_sg_for_device(struct device *dev,
BUG_ON(direction == DMA_NONE);
for_each_sg(sgl, sg, nents, i)
- __dma_sync_page(sg->page, sg->offset, sg->length, direction);
+ __dma_sync_page(sg_page(sg), sg->offset, sg->length, direction);
}
static inline int dma_mapping_error(dma_addr_t dma_addr)
--
1.5.3.4
^ permalink raw reply related
* Root file system for powerpc 74xx board
From: mahendra varman @ 2007-10-23 14:55 UTC (permalink / raw)
To: XFree86, xorg, linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 413 bytes --]
Hi All
Iam a beginner/Learner in this field.
I have Linux running on an intel x86 machine with cross development
environment.
I want to host 74xx file system with Xfree86 and library support on the
intel machine.
I will boot the file system using NFS to the 74xx system.
How to create/extract the file system with xfree86 support from fedora file
system ?
Please help me on the above
Thanks in advance
[-- Attachment #2: Type: text/html, Size: 476 bytes --]
^ permalink raw reply
* Re: [PATCH] PowerPC: Add BCM5248 and Marvell 88E1111 PHY support to NEW EMAC.
From: Josh Boyer @ 2007-10-23 15:20 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, linuxppc-dev
In-Reply-To: <4713B10B.5000607@garzik.org>
On Mon, 15 Oct 2007 14:27:23 -0400
Jeff Garzik <jeff@garzik.org> wrote:
> Valentine Barshak wrote:
> > This patch adds BCM5248 and Marvell 88E1111 PHY support to NEW EMAC driver.
> > These PHY chips are used on PowerPC 440EPx boards.
> > The PHY code is based on the previous work by Stefan Roese <sr@denx.de>
> >
> > Signed-off-by: Stefan Roese <sr@denx.de>
> > Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
> > ---
> > drivers/net/ibm_newemac/phy.c | 39 +++++++++++++++++++++++++++++++++++++++
> > 1 files changed, 39 insertions(+)
> >
> > --- linux.orig/drivers/net/ibm_newemac/phy.c 2007-06-15 21:45:18.000000000 +0400
> > +++ linux/drivers/net/ibm_newemac/phy.c 2007-06-15 20:45:15.000000000 +0400
> > @@ -306,8 +306,47 @@
> > .ops = &cis8201_phy_ops
> > };
> >
> > +static struct mii_phy_def bcm5248_phy_def = {
> > +
> > + .phy_id = 0x0143bc00,
> > + .phy_id_mask = 0x0ffffff0,
> > + .name = "BCM5248 10/100 SMII Ethernet",
> > + .ops = &generic_phy_ops
> > +};
> > +
> > +static int m88e1111_init(struct mii_phy *phy)
> > +{
> > + printk("%s: Marvell 88E1111 Ethernet\n", __FUNCTION__);
> > + phy_write(phy, 0x14, 0x0ce3);
> > + phy_write(phy, 0x18, 0x4101);
> > + phy_write(phy, 0x09, 0x0e00);
> > + phy_write(phy, 0x04, 0x01e1);
> > + phy_write(phy, 0x00, 0x9140);
> > + phy_write(phy, 0x00, 0x1140);
> > +
> > + return 0;
> > +}
> > +
> > +static struct mii_phy_ops m88e1111_phy_ops = {
> > + .init = m88e1111_init,
> > + .setup_aneg = genmii_setup_aneg,
> > + .setup_forced = genmii_setup_forced,
> > + .poll_link = genmii_poll_link,
> > + .read_link = genmii_read_link
> > +};
> > +
> > +static struct mii_phy_def m88e1111_phy_def = {
> > +
> > + .phy_id = 0x01410CC0,
> > + .phy_id_mask = 0x0ffffff0,
> > + .name = "Marvell 88E1111 Ethernet",
> > + .ops = &m88e1111_phy_ops,
> > +};
> > +
> > static struct mii_phy_def *mii_phy_table[] = {
> > &cis8201_phy_def,
> > + &bcm5248_phy_def,
> > + &m88e1111_phy_def,
> > &genmii_phy_def,
>
> Seems sane to me -- ACK -- but we have multiple people sending me
> patches for a single driver. That's normal for janitorial cleanups
> across the whole tree, but discouraged when multiple people are actively
> working on the same driver.
>
> Please coordinate, and have ONE person send me patches...
Jeff, could you please pull in this patch for 2.6.24? We'll get the
coordination down for any further patches.
thx,
josh
>
^ permalink raw reply
* [PATCH] Bugfix to commit 18dabf473e15850c0dbc8ff13ac1e2806d542c15
From: Grant Likely @ 2007-10-23 15:20 UTC (permalink / raw)
To: linux-kernel, Jens, "Axboe <jens.axboe", linuxppc-dev,
Linus Torvalds, paulus
From: Grant Likely <grant.likely@secretlab.ca>
Fixup for commit 18dabf473e15850c0dbc8ff13ac1e2806d542c15. Changes to
dma_map_sg where done in asm-x86/dma-mapping_32.h, but were not mirrored
in include/asm-powerpc/dma-mapping.h
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
Linus, I cannot build an arch/powerpc kernel without this patch.
Cheers,
g.
include/asm-powerpc/dma-mapping.h | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/asm-powerpc/dma-mapping.h b/include/asm-powerpc/dma-mapping.h
index 65be95d..fd33ce4 100644
--- a/include/asm-powerpc/dma-mapping.h
+++ b/include/asm-powerpc/dma-mapping.h
@@ -285,9 +285,9 @@ dma_map_sg(struct device *dev, struct scatterlist *sgl, int nents,
BUG_ON(direction == DMA_NONE);
for_each_sg(sgl, sg, nents, i) {
- BUG_ON(!sg->page);
+ BUG_ON(!sg_page(sg));
__dma_sync_page(sg->page, sg->offset, sg->length, direction);
- sg->dma_address = page_to_bus(sg->page) + sg->offset;
+ sg->dma_address = sg_phys(sg);
}
return nents;
^ permalink raw reply related
* Re: Audio codec device tree entries
From: Timur Tabi @ 2007-10-23 15:27 UTC (permalink / raw)
To: Jon Smirl; +Cc: PowerPC dev list
In-Reply-To: <9e4733910710221859q6ea54810nba58907d5ddd966d@mail.gmail.com>
Jon Smirl wrote:
> Is this what the device tree entries should look like?
>
> First example is ac97 audio:
>
> ac97@2000 { // PSC1
> device_type = "sound";
> compatible = "mpc5200b-psc-ac97\0mpc5200-psc-ac97";
> cell-index = <0>;
> reg = <2000 100>;
> interrupts = <2 1 0>;
> interrupt-parent = <&mpc5200_pic>;
> codec-handle = <&codec0>
> };
I think the codec node should be a child of this node, not a separate node.
Then there should be another codec node as a child of the i2c node. The first
codec node should reference the other one via a phandle (so this part you
already have correct).
^ permalink raw reply
* Re: [PATCH] Bugfix to commit 18dabf473e15850c0dbc8ff13ac1e2806d542c15
From: Josh Boyer @ 2007-10-23 15:27 UTC (permalink / raw)
To: Grant Likely
Cc: "Axboe <jens.axboe", linux-kernel, linuxppc-dev,
paulus, Linus Torvalds, Jens
In-Reply-To: <20071023151929.12090.3835.stgit@trillian.cg.shawcable.net>
On Tue, 23 Oct 2007 09:20:25 -0600
Grant Likely <grant.likely@secretlab.ca> wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
>
> Fixup for commit 18dabf473e15850c0dbc8ff13ac1e2806d542c15. Changes to
> dma_map_sg where done in asm-x86/dma-mapping_32.h, but were not mirrored
> in include/asm-powerpc/dma-mapping.h
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> ---
>
> Linus, I cannot build an arch/powerpc kernel without this patch.
Olof Johansson already sent a patch out for this that had some other
fixes in it. I think Jens already applied it to his tree.
josh
^ permalink raw reply
* Re: [PATCH] PowerPC 440EPx Sequoia USB OHCI DTS entry
From: Josh Boyer @ 2007-10-23 15:33 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev, linux-usb-devel
In-Reply-To: <20071008142658.GA15197@ru.mvista.com>
On Mon, 8 Oct 2007 18:26:58 +0400
Valentine Barshak <vbarshak@ru.mvista.com> wrote:
> PowerPC 440EPx Sequoia USB OHCI device tree entry.
>
> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
I think I saw the OHCI big endian quirk patch go into Linus' tree
recently. Is that the only patch this one depends on?
josh
> ---
> arch/powerpc/boot/dts/sequoia.dts | 7 +++++++
> 1 files changed, 7 insertions(+)
>
> diff -pruN linux-2.6.orig/arch/powerpc/boot/dts/sequoia.dts linux-2.6/arch/powerpc/boot/dts/sequoia.dts
> --- linux-2.6.orig/arch/powerpc/boot/dts/sequoia.dts 2007-10-08 16:29:54.000000000 +0400
> +++ linux-2.6/arch/powerpc/boot/dts/sequoia.dts 2007-10-08 17:56:05.000000000 +0400
> @@ -122,6 +122,13 @@
> interrupt-map-mask = <ffffffff>;
> };
>
> + USB1: usb@e0000400 {
> + compatible = "ohci-be";
> + reg = <0 e0000400 60>;
> + interrupt-parent = <&UIC0>;
> + interrupts = <15 8>;
> + };
> +
> POB0: opb {
> compatible = "ibm,opb-440epx", "ibm,opb";
> #address-cells = <1>;
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] Bugfix to commit 18dabf473e15850c0dbc8ff13ac1e2806d542c15
From: Grant Likely @ 2007-10-23 15:35 UTC (permalink / raw)
To: linux-kernel, Jens Axboe, linuxppc-dev, Linus Torvalds, paulus
In-Reply-To: <20071023151929.12090.3835.stgit@trillian.cg.shawcable.net>
On 10/23/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
>
> Fixup for commit 18dabf473e15850c0dbc8ff13ac1e2806d542c15. Changes to
> dma_map_sg where done in asm-x86/dma-mapping_32.h, but were not mirrored
> in include/asm-powerpc/dma-mapping.h
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> ---
>
> Linus, I cannot build an arch/powerpc kernel without this patch.
Oops, ignore this patch. It's doesn't change all the references, it
uses the wrong method for calculating dma_address and 2 other people
have already sent the fix for this.
/me puts on a paper bag
g.
>
> Cheers,
> g.
>
> include/asm-powerpc/dma-mapping.h | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/asm-powerpc/dma-mapping.h b/include/asm-powerpc/dma-mapping.h
> index 65be95d..fd33ce4 100644
> --- a/include/asm-powerpc/dma-mapping.h
> +++ b/include/asm-powerpc/dma-mapping.h
> @@ -285,9 +285,9 @@ dma_map_sg(struct device *dev, struct scatterlist *sgl, int nents,
> BUG_ON(direction == DMA_NONE);
>
> for_each_sg(sgl, sg, nents, i) {
> - BUG_ON(!sg->page);
> + BUG_ON(!sg_page(sg));
> __dma_sync_page(sg->page, sg->offset, sg->length, direction);
> - sg->dma_address = page_to_bus(sg->page) + sg->offset;
> + sg->dma_address = sg_phys(sg);
> }
>
> return nents;
>
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH] PowerPC 440EPx Sequoia USB OHCI DTS entry
From: Valentine Barshak @ 2007-10-23 15:35 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, linux-usb-devel
In-Reply-To: <20071023103316.471f8afa@weaponx.rchland.ibm.com>
Josh Boyer wrote:
> On Mon, 8 Oct 2007 18:26:58 +0400
> Valentine Barshak <vbarshak@ru.mvista.com> wrote:
>
>> PowerPC 440EPx Sequoia USB OHCI device tree entry.
>>
>> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
>
> I think I saw the OHCI big endian quirk patch go into Linus' tree
> recently. Is that the only patch this one depends on?
>
Yes, now we only need a dts entry to enable ohci support for 440EP(x),
Valentine.
> josh
>
>> ---
>> arch/powerpc/boot/dts/sequoia.dts | 7 +++++++
>> 1 files changed, 7 insertions(+)
>>
>> diff -pruN linux-2.6.orig/arch/powerpc/boot/dts/sequoia.dts linux-2.6/arch/powerpc/boot/dts/sequoia.dts
>> --- linux-2.6.orig/arch/powerpc/boot/dts/sequoia.dts 2007-10-08 16:29:54.000000000 +0400
>> +++ linux-2.6/arch/powerpc/boot/dts/sequoia.dts 2007-10-08 17:56:05.000000000 +0400
>> @@ -122,6 +122,13 @@
>> interrupt-map-mask = <ffffffff>;
>> };
>>
>> + USB1: usb@e0000400 {
>> + compatible = "ohci-be";
>> + reg = <0 e0000400 60>;
>> + interrupt-parent = <&UIC0>;
>> + interrupts = <15 8>;
>> + };
>> +
>> POB0: opb {
>> compatible = "ibm,opb-440epx", "ibm,opb";
>> #address-cells = <1>;
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [linux-usb-devel] [PATCH 0/3] usb: ehci ppc device-tree-aware driver
From: Josh Boyer @ 2007-10-23 15:37 UTC (permalink / raw)
To: David Brownell; +Cc: linuxppc-dev, Stefan Roese, linux-usb-devel, Arnd Bergmann
In-Reply-To: <200710101030.02349.sr@denx.de>
On Wed, 10 Oct 2007 10:30:02 +0200
Stefan Roese <sr@denx.de> wrote:
> On Wednesday 10 October 2007, Arnd Bergmann wrote:
> > > Do PPC folk sign off on how this is done?
> > >
> > > I don't follow all the ins/outs of the OF devtree stuff...
> >
> > The driver looks good to me, both the interaction with the of_platform_bus
> > layer and the handling of I/O addresses. I haven't actually tried running
> > it, but I'm rather confident that if it works on the Sequoia, it should
> > also do the right thing on any other powerpc system that has an EHCI on
> > some other (non-PCI) bus.
> >
> > Acked-by: Arnd Bergmann <arnd@arndb.de>
>
> Acked-by: Stefan Roese <sr@denx.de>
David, were you going to pull in the echi-ppc-of driver (patch 1 of
this series) for 2.6.24? Just trying to figure out if I need to pull
the other two patches into my tree.
josh
^ permalink raw reply
* Re: [i2c] [PATCH take2] [POWERPC] i2c: adds support for i2c bus on 8xx
From: Jochen Friedrich @ 2007-10-23 15:47 UTC (permalink / raw)
To: Jean Delvare; +Cc: linuxppc-embedded, linux-kernel, i2c, Carsten Juttner
In-Reply-To: <20071017230027.334a5f48@hyperion.delvare>
Hi Jean,
> On Wed, 17 Oct 2007 21:20:37 +0200, Jochen Friedrich wrote:
>>>> + /* Select an arbitrary address. Just make sure it is unique.
>>>> + */
>>>> + out_8(&i2c->i2c_i2add, 0xfe);
>>>>
>>> It's a 7-bit address... and are you sure that 0x7e is unique? Does this
>>> driver even support slave operation?
>>>
>> It's in fact 0x7F << 1. The same value is used in the 2.4 driver and
>> in u-boot, as well. Slave operation is not supported.
>
> I'm not sure what exactly you are doing here, but 0x7f isn't a valid
> 7-bit I2C address.
That's most probably the reason why it is used everywhere in the CPM world
(old driver, u-boot) ;-)
According to the documentation, the CPM enters a loopback mode as soon
as a write access to the I2C address written to i2c_i2add takes place.
This even happens if the CPM is set to master mode. So the only way to make
sure there are no limitations to the I2C addresses which can be used is to
use this invalid address. 0x00 can't be used either or no I2C broadcasts
would be possible.
>From the MPC-823 documentation:
16.13.3.1.3 I2C Loopback Configuration. Loopback on the I2C controller is a
special part of master mode operation with a device that does not contain
internal addresses. Refer to Figure 16-127 for more information. To begin a
loopback transmission, you must prepare a TX buffer descriptor with a data
buffer N+1 bytes long, where N is the number of data bytes to be written back
to the I2C controller. You must also prepare one or more RX buffer descriptors
to receive the N bytes of data. The first byte of the TX buffer descriptor
must contain the address of the MPC823 I2C device’s own address, which is in
the I2CADD register, followed by the write bit asserted (R/W = 0). The
remaining N bytes of the TX buffer descriptor contain the data to be sent and
received by the I2C controller. Next, set the R bit in the TX buffer descriptor
and the E bit in the RX buffer descriptor. Then set the W and L bits in the TX
buffer descriptor. Setting the L bit causes a stop condition to be issued after
this buffer is transmitted to conclude the operation. Set the I bit in the TX
and RX buffer descriptors to enable the transmission and reception status to be
updated in the I2CE register and to enable I2C transmit and receive interrupts
to the core. You must then set the STR bit in the I2COM register to initiate
the loopback operation.
Thanks,
Jochen
^ permalink raw reply
* Re: [PATCH] PowerPC 440EPx Sequoia USB OHCI DTS entry
From: Josh Boyer @ 2007-10-23 15:50 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev, linux-usb-devel
In-Reply-To: <471E14AD.9090306@ru.mvista.com>
On Tue, 23 Oct 2007 19:35:09 +0400
Valentine Barshak <vbarshak@ru.mvista.com> wrote:
> Josh Boyer wrote:
> > On Mon, 8 Oct 2007 18:26:58 +0400
> > Valentine Barshak <vbarshak@ru.mvista.com> wrote:
> >
> >> PowerPC 440EPx Sequoia USB OHCI device tree entry.
> >>
> >> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
> >
> > I think I saw the OHCI big endian quirk patch go into Linus' tree
> > recently. Is that the only patch this one depends on?
> >
>
> Yes, now we only need a dts entry to enable ohci support for 440EP(x),
> Valentine.
Ok. I'll queue up this patch in a bit. Thanks.
josh
^ permalink raw reply
* Re: [PATCH] Bugfix to commit 4f9a58d75bfe82ab2b8ba5b8506dfb190a267834
From: Linus Torvalds @ 2007-10-23 15:52 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <20071023063720.GA29993@suse.de>
On Tue, 23 Oct 2007, Olaf Hering wrote:
>
> On Mon, Oct 22, Grant Likely wrote:
>
> > Olaf, do I have the correct solution here?
>
> Sure.
Side note: I already applied that patch, but take a look at the commit
message.
That's right: I had to edit the message provided to make it readable. So
I'll just take this opportunity to ask people that when they send
bug-fixes, please try to make the subject line and message make sense for
a *reader*, not for yourself (or even to me, although if it's readable to
some generic person, it's hopefully readable to me too!).
So a subject line of "Bugfix to commit <commit-sha-goes-here>" is
obviously not a very nice one, if you're looking at the kernel commit
history in gitk or some other visualizer that shows the first line as the
subject for the whole commit. It just doesn't make any sense to the
reader!
Related to that, another thing that also happens is that people write
subject lines (and the description) as if everybody realized that
something is particular to that architecture or driver. It may be true
that that particular developer (or development list) is only about ppc,
and then people write subject lines like "Fix execve() argument handling",
but again, when a *generic* person reads that, it now reads totally wrong,
since it wasn't execve() in general, it was a particular architecture that
it went wrong for.
So the rule should be:
- if it's not fairly generic, specify the area (architecture, subsystem,
driver) that the fix is for in the subject line. Even if you end up
initially sending the fix out to just a list that handles that
particular subsystem anyway.
- don't use commit names in the subject line - and while it's great to
use them in the body of the explanation, even there you don't want to
assume that people read it from within git. People see patches and
commit changelogs on the web or the commit mailing lists, so when
specifying an exact version, also specify the human-readable name of
that version.
- write the commit message for an outsider, and use whitespace. The
third-most common fixup I end up doing (after the above two) is to
split things up into shorter paragraphs, after somebody wrote a good
changelog entry, but made it one large unreadable blob of text. The
more involved and technical some description is (and that's what long
changelog entries should be - we don't want a fluffy novella here!),
the more "breather space" and individually understandable small
snippets of text readers need. Making things too dense is bad.
Anyway, this was in no way meant to be a specific problem for Grant or
Olaf - I end up editing just about half of all the commit messages of
stuff I get in email (except for Andrew's stuff, since Andrew largely does
the same kinds of cleanups anyway, so I only need to edit up a small
percentage of the patches he forwards). I'd like it to be *much* less than
that, so I thought I should speak up since I had an example of this.
Linus
^ permalink raw reply
* Re: [PATCH] DTC: Remove the need for the GLR Parser.
From: Jon Loeliger @ 2007-10-23 16:07 UTC (permalink / raw)
To: David Gibson, linuxppc-dev
In-Reply-To: <E1IkKge-00060g-2l@jdl.com>
So, like, the other day Jon Loeliger mumbled:
>
> > First, a trivial one: I remember leaving this as a right-recursion,
> > despite the stack-nastiness, because that way the properties end up in
> > the same order as in the source. I think that behaviour is worth
> > preserving, but of course we can do it with left-recursion by changing
> > chain_property() to add to the end of the list instead of the
> > beginning.
>
> Understood. And I wrestled with that as well. In fact, I even
> wrote the reverse_properties() function, which I will include,
> and used it initially. However, several test failed. So I
> removed it, and it all started happily working again.
I was confused. It was the version of the code that _did_
use the property reversal that worked.
Even Milton's asm test with labels worked. :-)
jdl
^ permalink raw reply
* Re: [PATCH] PowerPC: Add BCM5248 and Marvell 88E1111 PHY support to NEW EMAC.
From: Kumar Gala @ 2007-10-23 16:13 UTC (permalink / raw)
To: Josh Boyer; +Cc: netdev, Jeff Garzik, linuxppc-dev
In-Reply-To: <20071023102035.6d35d3fe@weaponx.rchland.ibm.com>
On Oct 23, 2007, at 10:20 AM, Josh Boyer wrote:
> On Mon, 15 Oct 2007 14:27:23 -0400
> Jeff Garzik <jeff@garzik.org> wrote:
>
>> Valentine Barshak wrote:
>>> This patch adds BCM5248 and Marvell 88E1111 PHY support to NEW
>>> EMAC driver.
>>> These PHY chips are used on PowerPC 440EPx boards.
>>> The PHY code is based on the previous work by Stefan Roese
>>> <sr@denx.de>
>>>
>>> Signed-off-by: Stefan Roese <sr@denx.de>
>>> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
>>> ---
You guys should really look at moving emac over to the phylib so we
don't have to duplicate drivers for the same phys all over the place :)
- k
^ permalink raw reply
* RE: [microblaze-uclinux] Re: [microblaze-uclinux] RE: [PATCH v3] Device tree bindings for Xilinx devices
From: Stephen Neuendorffer @ 2007-10-23 16:25 UTC (permalink / raw)
To: Michal Simek, microblaze-uclinux; +Cc: linuxppc-dev
In-Reply-To: <1837.2996-6584-798350907-1193112476@seznam.cz>
=20
> -----Original Message-----
> From:=20
> linuxppc-dev-bounces+stephen.neuendorffer=3Dxilinx.com@ozlabs.or
> g=20
> [mailto:linuxppc-dev-bounces+stephen.neuendorffer=3Dxilinx.com@o
zlabs.org] On Behalf Of Michal Simek
> Sent: Monday, October 22, 2007 9:08 PM
> To: microblaze-uclinux@itee.uq.edu.au
> Cc: Leonid; Wolfgang Reissnegger; Arnd Bergmann;=20
> linuxppc-dev@ozlabs.org
> Subject: RE: [microblaze-uclinux] Re: [microblaze-uclinux]=20
> RE: [PATCH v3] Device tree bindings for Xilinx devices
>=20
> >> In my opinion will be better generate only parameters which=20
> >> you want not all.
> >> That smells with unusable parameters.
> >
> >In the long term, this may be true. In the short term:
> >1) dtb size is not the key problem
> Yes of course
> >2) making sure that everything works is a key problem.
> >3) The code that generates the dts should be as simple as possible,
> >so that we can easily document what it does.
> Yes but you must document every parameter which your generate=20
> do. The better way is=20
> document only parameters which you want use.
No, that's exactly my point. The generator should document what it
*does*
i.e. When there is a parameter in the EDK file, then such and such
corresponding parameter will be generated in the dts. The devices and
drivers
will inevitably change over time: your proposal would result in
an unnecessary maintenance headache... The documentation of what the
individual
parameters are should be unambiguous from the EDK documentation.
The only things that the generator should handle 'specially', in my
opinion
are parameters that need to be munged to be standard names.
Steve
^ permalink raw reply
* [PATCH] Use the new sg_page() helper
From: Emil Medve @ 2007-10-23 16:14 UTC (permalink / raw)
To: axboe, paulus, chris, grundler, kyle, linux-arm-kernel, torvalds,
ashok.raj, shaohua.li, anil.s.keshavamurthy
Cc: linuxppc-dev, Emil Medve, linux-arm-kernel, parisc-linux,
linux-kernel
Fix build error messages such as this:
In file included from include/linux/dma-mapping.h:52,
from include/linux/dmaengine.h:29,
from include/linux/skbuff.h:29,
from include/linux/netlink.h:155,
from include/linux/genetlink.h:4,
from include/net/genetlink.h:4,
from include/linux/taskstats_kern.h:12,
from init/main.c:46:
include/asm/dma-mapping.h: In function 'dma_map_sg':
include/asm/dma-mapping.h:288: error: 'struct scatterlist' has no member named 'page'
include/asm/dma-mapping.h:288: error: 'struct scatterlist' has no member named 'page'
include/asm/dma-mapping.h:288: error: 'struct scatterlist' has no member named 'page'
include/asm/dma-mapping.h:290: error: 'struct scatterlist' has no member named 'page'
This change in the struct scatterlist was introduced by this commit: 18dabf473e15850c0dbc8ff13ac1e2806d542c15
Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com>
---
linux-2.6> scripts/checkpatch.pl 0001-Use-the-new-sg_page-helper.patch
Your patch has no obvious style problems and is ready for submission.
drivers/mmc/host/mmci.h | 4 ++--
drivers/pci/intel-iommu.c | 2 +-
include/asm-arm/dma-mapping.h | 8 ++++----
include/asm-parisc/scatterlist.h | 3 ++-
include/asm-powerpc/dma-mapping.h | 10 +++++-----
include/asm-xtensa/dma-mapping.h | 10 +++++-----
6 files changed, 19 insertions(+), 18 deletions(-)
diff --git a/drivers/mmc/host/mmci.h b/drivers/mmc/host/mmci.h
index 000e6a9..de3c223 100644
--- a/drivers/mmc/host/mmci.h
+++ b/drivers/mmc/host/mmci.h
@@ -112,7 +112,7 @@
* The size of the FIFO in bytes.
*/
#define MCI_FIFOSIZE (16*4)
-
+
#define MCI_FIFOHALFSIZE (MCI_FIFOSIZE / 2)
#define NR_SG 16
@@ -169,7 +169,7 @@ static inline char *mmci_kmap_atomic(struct mmci_host *host, unsigned long *flag
struct scatterlist *sg = host->sg_ptr;
local_irq_save(*flags);
- return kmap_atomic(sg->page, KM_BIO_SRC_IRQ) + sg->offset;
+ return kmap_atomic(sg_page(sg), KM_BIO_SRC_IRQ) + sg->offset;
}
static inline void mmci_kunmap_atomic(struct mmci_host *host, void *buffer, unsigned long *flags)
diff --git a/drivers/pci/intel-iommu.c b/drivers/pci/intel-iommu.c
index b3d7031..347948c 100644
--- a/drivers/pci/intel-iommu.c
+++ b/drivers/pci/intel-iommu.c
@@ -2010,7 +2010,7 @@ static int intel_nontranslate_map_sg(struct device *hddev,
struct scatterlist *sg;
for_each_sg(sglist, sg, nelems, i) {
- BUG_ON(!sg->page);
+ BUG_ON(!sg_page(sg));
sg->dma_address = virt_to_bus(SG_ENT_VIRT_ADDRESS(sg));
sg->dma_length = sg->length;
}
diff --git a/include/asm-arm/dma-mapping.h b/include/asm-arm/dma-mapping.h
index 1eb8aac..08afd5a 100644
--- a/include/asm-arm/dma-mapping.h
+++ b/include/asm-arm/dma-mapping.h
@@ -274,8 +274,8 @@ dma_map_sg(struct device *dev, struct scatterlist *sg, int nents,
for (i = 0; i < nents; i++, sg++) {
char *virt;
- sg->dma_address = page_to_dma(dev, sg->page) + sg->offset;
- virt = page_address(sg->page) + sg->offset;
+ sg->dma_address = page_to_dma(dev, sg_page(sg)) + sg->offset;
+ virt = page_address(sg_page(sg)) + sg->offset;
if (!arch_is_coherent())
dma_cache_maint(virt, sg->length, dir);
@@ -371,7 +371,7 @@ dma_sync_sg_for_cpu(struct device *dev, struct scatterlist *sg, int nents,
int i;
for (i = 0; i < nents; i++, sg++) {
- char *virt = page_address(sg->page) + sg->offset;
+ char *virt = page_address(sg_page(sg)) + sg->offset;
if (!arch_is_coherent())
dma_cache_maint(virt, sg->length, dir);
}
@@ -384,7 +384,7 @@ dma_sync_sg_for_device(struct device *dev, struct scatterlist *sg, int nents,
int i;
for (i = 0; i < nents; i++, sg++) {
- char *virt = page_address(sg->page) + sg->offset;
+ char *virt = page_address(sg_page(sg)) + sg->offset;
if (!arch_is_coherent())
dma_cache_maint(virt, sg->length, dir);
}
diff --git a/include/asm-parisc/scatterlist.h b/include/asm-parisc/scatterlist.h
index cd3cfdf..3c79a2a 100644
--- a/include/asm-parisc/scatterlist.h
+++ b/include/asm-parisc/scatterlist.h
@@ -18,7 +18,8 @@ struct scatterlist {
__u32 iova_length; /* bytes mapped */
};
-#define sg_virt_addr(sg) ((unsigned long)(page_address(sg->page) + sg->offset))
+#define sg_virt_addr(sg) \
+ ((unsigned long)(page_address(sg_page(sg)) + sg->offset))
#define sg_dma_address(sg) ((sg)->iova)
#define sg_dma_len(sg) ((sg)->iova_length)
diff --git a/include/asm-powerpc/dma-mapping.h b/include/asm-powerpc/dma-mapping.h
index 65be95d..ff52013 100644
--- a/include/asm-powerpc/dma-mapping.h
+++ b/include/asm-powerpc/dma-mapping.h
@@ -285,9 +285,9 @@ dma_map_sg(struct device *dev, struct scatterlist *sgl, int nents,
BUG_ON(direction == DMA_NONE);
for_each_sg(sgl, sg, nents, i) {
- BUG_ON(!sg->page);
- __dma_sync_page(sg->page, sg->offset, sg->length, direction);
- sg->dma_address = page_to_bus(sg->page) + sg->offset;
+ BUG_ON(!sg_page(sg));
+ __dma_sync_page(sg_page(sg), sg->offset, sg->length, direction);
+ sg->dma_address = page_to_bus(sg_page(sg)) + sg->offset;
}
return nents;
@@ -328,7 +328,7 @@ static inline void dma_sync_sg_for_cpu(struct device *dev,
BUG_ON(direction == DMA_NONE);
for_each_sg(sgl, sg, nents, i)
- __dma_sync_page(sg->page, sg->offset, sg->length, direction);
+ __dma_sync_page(sg_page(sg), sg->offset, sg->length, direction);
}
static inline void dma_sync_sg_for_device(struct device *dev,
@@ -341,7 +341,7 @@ static inline void dma_sync_sg_for_device(struct device *dev,
BUG_ON(direction == DMA_NONE);
for_each_sg(sgl, sg, nents, i)
- __dma_sync_page(sg->page, sg->offset, sg->length, direction);
+ __dma_sync_page(sg_page(sg), sg->offset, sg->length, direction);
}
static inline int dma_mapping_error(dma_addr_t dma_addr)
diff --git a/include/asm-xtensa/dma-mapping.h b/include/asm-xtensa/dma-mapping.h
index 82b03b3..2b3e975 100644
--- a/include/asm-xtensa/dma-mapping.h
+++ b/include/asm-xtensa/dma-mapping.h
@@ -58,10 +58,10 @@ dma_map_sg(struct device *dev, struct scatterlist *sg, int nents,
BUG_ON(direction == DMA_NONE);
for (i = 0; i < nents; i++, sg++ ) {
- BUG_ON(!sg->page);
+ BUG_ON(!sg_page(sg));
- sg->dma_address = page_to_phys(sg->page) + sg->offset;
- consistent_sync(page_address(sg->page) + sg->offset,
+ sg->dma_address = page_to_phys(sg_page(sg)) + sg->offset;
+ consistent_sync(page_address(sg_page(sg)) + sg->offset,
sg->length, direction);
}
@@ -128,7 +128,7 @@ dma_sync_sg_for_cpu(struct device *dev, struct scatterlist *sg, int nelems,
{
int i;
for (i = 0; i < nelems; i++, sg++)
- consistent_sync(page_address(sg->page) + sg->offset,
+ consistent_sync(page_address(sg_page(sg)) + sg->offset,
sg->length, dir);
}
@@ -138,7 +138,7 @@ dma_sync_sg_for_device(struct device *dev, struct scatterlist *sg, int nelems,
{
int i;
for (i = 0; i < nelems; i++, sg++)
- consistent_sync(page_address(sg->page) + sg->offset,
+ consistent_sync(page_address(sg_page(sg)) + sg->offset,
sg->length, dir);
}
static inline int
--
1.5.3.GIT
^ permalink raw reply related
* Re: [PATCH] PowerPC: Add BCM5248 and Marvell 88E1111 PHY support to NEW EMAC.
From: Josh Boyer @ 2007-10-23 16:17 UTC (permalink / raw)
To: Kumar Gala; +Cc: netdev, Jeff Garzik, linuxppc-dev
In-Reply-To: <38505C5B-4252-4AA7-B4F5-6B5267A6DBAA@kernel.crashing.org>
On Tue, 23 Oct 2007 11:13:48 -0500
Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Oct 23, 2007, at 10:20 AM, Josh Boyer wrote:
>
> > On Mon, 15 Oct 2007 14:27:23 -0400
> > Jeff Garzik <jeff@garzik.org> wrote:
> >
> >> Valentine Barshak wrote:
> >>> This patch adds BCM5248 and Marvell 88E1111 PHY support to NEW
> >>> EMAC driver.
> >>> These PHY chips are used on PowerPC 440EPx boards.
> >>> The PHY code is based on the previous work by Stefan Roese
> >>> <sr@denx.de>
> >>>
> >>> Signed-off-by: Stefan Roese <sr@denx.de>
> >>> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
> >>> ---
>
> You guys should really look at moving emac over to the phylib so we
> don't have to duplicate drivers for the same phys all over the place :)
Yes, we should. It's on the list. Just not for 2.6.24 since it's way
too late.
josh
^ permalink raw reply
* Re: Audio codec device tree entries
From: Segher Boessenkool @ 2007-10-23 16:56 UTC (permalink / raw)
To: Timur Tabi; +Cc: PowerPC dev list
In-Reply-To: <471E12C7.8020509@freescale.com>
>> First example is ac97 audio:
>>
>> ac97@2000 { // PSC1
> I think the codec node should be a child of this node, not a separate
> node.
> Then there should be another codec node as a child of the i2c node.
AC'97 codecs don't typically have an I2C connection (if ever).
You shouldn't have two device nodes for the same device if ever you
can help it; instead, have the device's sole device node contain a
property that points to the device node of its secondary bus. That
property could be called "i2s-handle" for a standard codec (which
probably is a direct child of an IIC bus, itself).
Segher
^ permalink raw reply
* Re: [PATCH] Use the new sg_page() helper
From: Kristoffer Ericson @ 2007-10-24 1:55 UTC (permalink / raw)
To: Emil Medve
Cc: axboe, chris, grundler, linux-kernel, anil.s.keshavamurthy, kyle,
linuxppc-dev, paulus, shaohua.li, torvalds, linux-arm-kernel,
parisc-linux, ashok.raj
In-Reply-To: <1193156092-11819-1-git-send-email-Emilian.Medve@Freescale.com>
Great, :D
Just dropped a bug report about this 5mins ago. Hope it gets commited shortly.
On Tue, 23 Oct 2007 11:14:52 -0500
Emil Medve <Emilian.Medve@Freescale.com> wrote:
> Fix build error messages such as this:
>
> In file included from include/linux/dma-mapping.h:52,
> from include/linux/dmaengine.h:29,
> from include/linux/skbuff.h:29,
> from include/linux/netlink.h:155,
> from include/linux/genetlink.h:4,
> from include/net/genetlink.h:4,
> from include/linux/taskstats_kern.h:12,
> from init/main.c:46:
> include/asm/dma-mapping.h: In function 'dma_map_sg':
> include/asm/dma-mapping.h:288: error: 'struct scatterlist' has no member named 'page'
> include/asm/dma-mapping.h:288: error: 'struct scatterlist' has no member named 'page'
> include/asm/dma-mapping.h:288: error: 'struct scatterlist' has no member named 'page'
> include/asm/dma-mapping.h:290: error: 'struct scatterlist' has no member named 'page'
>
> This change in the struct scatterlist was introduced by this commit: 18dabf473e15850c0dbc8ff13ac1e2806d542c15
>
> Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com>
> ---
>
> linux-2.6> scripts/checkpatch.pl 0001-Use-the-new-sg_page-helper.patch
> Your patch has no obvious style problems and is ready for submission.
>
> drivers/mmc/host/mmci.h | 4 ++--
> drivers/pci/intel-iommu.c | 2 +-
> include/asm-arm/dma-mapping.h | 8 ++++----
> include/asm-parisc/scatterlist.h | 3 ++-
> include/asm-powerpc/dma-mapping.h | 10 +++++-----
> include/asm-xtensa/dma-mapping.h | 10 +++++-----
> 6 files changed, 19 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/mmc/host/mmci.h b/drivers/mmc/host/mmci.h
> index 000e6a9..de3c223 100644
> --- a/drivers/mmc/host/mmci.h
> +++ b/drivers/mmc/host/mmci.h
> @@ -112,7 +112,7 @@
> * The size of the FIFO in bytes.
> */
> #define MCI_FIFOSIZE (16*4)
> -
> +
> #define MCI_FIFOHALFSIZE (MCI_FIFOSIZE / 2)
>
> #define NR_SG 16
> @@ -169,7 +169,7 @@ static inline char *mmci_kmap_atomic(struct mmci_host *host, unsigned long *flag
> struct scatterlist *sg = host->sg_ptr;
>
> local_irq_save(*flags);
> - return kmap_atomic(sg->page, KM_BIO_SRC_IRQ) + sg->offset;
> + return kmap_atomic(sg_page(sg), KM_BIO_SRC_IRQ) + sg->offset;
> }
>
> static inline void mmci_kunmap_atomic(struct mmci_host *host, void *buffer, unsigned long *flags)
> diff --git a/drivers/pci/intel-iommu.c b/drivers/pci/intel-iommu.c
> index b3d7031..347948c 100644
> --- a/drivers/pci/intel-iommu.c
> +++ b/drivers/pci/intel-iommu.c
> @@ -2010,7 +2010,7 @@ static int intel_nontranslate_map_sg(struct device *hddev,
> struct scatterlist *sg;
>
> for_each_sg(sglist, sg, nelems, i) {
> - BUG_ON(!sg->page);
> + BUG_ON(!sg_page(sg));
> sg->dma_address = virt_to_bus(SG_ENT_VIRT_ADDRESS(sg));
> sg->dma_length = sg->length;
> }
> diff --git a/include/asm-arm/dma-mapping.h b/include/asm-arm/dma-mapping.h
> index 1eb8aac..08afd5a 100644
> --- a/include/asm-arm/dma-mapping.h
> +++ b/include/asm-arm/dma-mapping.h
> @@ -274,8 +274,8 @@ dma_map_sg(struct device *dev, struct scatterlist *sg, int nents,
> for (i = 0; i < nents; i++, sg++) {
> char *virt;
>
> - sg->dma_address = page_to_dma(dev, sg->page) + sg->offset;
> - virt = page_address(sg->page) + sg->offset;
> + sg->dma_address = page_to_dma(dev, sg_page(sg)) + sg->offset;
> + virt = page_address(sg_page(sg)) + sg->offset;
>
> if (!arch_is_coherent())
> dma_cache_maint(virt, sg->length, dir);
> @@ -371,7 +371,7 @@ dma_sync_sg_for_cpu(struct device *dev, struct scatterlist *sg, int nents,
> int i;
>
> for (i = 0; i < nents; i++, sg++) {
> - char *virt = page_address(sg->page) + sg->offset;
> + char *virt = page_address(sg_page(sg)) + sg->offset;
> if (!arch_is_coherent())
> dma_cache_maint(virt, sg->length, dir);
> }
> @@ -384,7 +384,7 @@ dma_sync_sg_for_device(struct device *dev, struct scatterlist *sg, int nents,
> int i;
>
> for (i = 0; i < nents; i++, sg++) {
> - char *virt = page_address(sg->page) + sg->offset;
> + char *virt = page_address(sg_page(sg)) + sg->offset;
> if (!arch_is_coherent())
> dma_cache_maint(virt, sg->length, dir);
> }
> diff --git a/include/asm-parisc/scatterlist.h b/include/asm-parisc/scatterlist.h
> index cd3cfdf..3c79a2a 100644
> --- a/include/asm-parisc/scatterlist.h
> +++ b/include/asm-parisc/scatterlist.h
> @@ -18,7 +18,8 @@ struct scatterlist {
> __u32 iova_length; /* bytes mapped */
> };
>
> -#define sg_virt_addr(sg) ((unsigned long)(page_address(sg->page) + sg->offset))
> +#define sg_virt_addr(sg) \
> + ((unsigned long)(page_address(sg_page(sg)) + sg->offset))
> #define sg_dma_address(sg) ((sg)->iova)
> #define sg_dma_len(sg) ((sg)->iova_length)
>
> diff --git a/include/asm-powerpc/dma-mapping.h b/include/asm-powerpc/dma-mapping.h
> index 65be95d..ff52013 100644
> --- a/include/asm-powerpc/dma-mapping.h
> +++ b/include/asm-powerpc/dma-mapping.h
> @@ -285,9 +285,9 @@ dma_map_sg(struct device *dev, struct scatterlist *sgl, int nents,
> BUG_ON(direction == DMA_NONE);
>
> for_each_sg(sgl, sg, nents, i) {
> - BUG_ON(!sg->page);
> - __dma_sync_page(sg->page, sg->offset, sg->length, direction);
> - sg->dma_address = page_to_bus(sg->page) + sg->offset;
> + BUG_ON(!sg_page(sg));
> + __dma_sync_page(sg_page(sg), sg->offset, sg->length, direction);
> + sg->dma_address = page_to_bus(sg_page(sg)) + sg->offset;
> }
>
> return nents;
> @@ -328,7 +328,7 @@ static inline void dma_sync_sg_for_cpu(struct device *dev,
> BUG_ON(direction == DMA_NONE);
>
> for_each_sg(sgl, sg, nents, i)
> - __dma_sync_page(sg->page, sg->offset, sg->length, direction);
> + __dma_sync_page(sg_page(sg), sg->offset, sg->length, direction);
> }
>
> static inline void dma_sync_sg_for_device(struct device *dev,
> @@ -341,7 +341,7 @@ static inline void dma_sync_sg_for_device(struct device *dev,
> BUG_ON(direction == DMA_NONE);
>
> for_each_sg(sgl, sg, nents, i)
> - __dma_sync_page(sg->page, sg->offset, sg->length, direction);
> + __dma_sync_page(sg_page(sg), sg->offset, sg->length, direction);
> }
>
> static inline int dma_mapping_error(dma_addr_t dma_addr)
> diff --git a/include/asm-xtensa/dma-mapping.h b/include/asm-xtensa/dma-mapping.h
> index 82b03b3..2b3e975 100644
> --- a/include/asm-xtensa/dma-mapping.h
> +++ b/include/asm-xtensa/dma-mapping.h
> @@ -58,10 +58,10 @@ dma_map_sg(struct device *dev, struct scatterlist *sg, int nents,
> BUG_ON(direction == DMA_NONE);
>
> for (i = 0; i < nents; i++, sg++ ) {
> - BUG_ON(!sg->page);
> + BUG_ON(!sg_page(sg));
>
> - sg->dma_address = page_to_phys(sg->page) + sg->offset;
> - consistent_sync(page_address(sg->page) + sg->offset,
> + sg->dma_address = page_to_phys(sg_page(sg)) + sg->offset;
> + consistent_sync(page_address(sg_page(sg)) + sg->offset,
> sg->length, direction);
> }
>
> @@ -128,7 +128,7 @@ dma_sync_sg_for_cpu(struct device *dev, struct scatterlist *sg, int nelems,
> {
> int i;
> for (i = 0; i < nelems; i++, sg++)
> - consistent_sync(page_address(sg->page) + sg->offset,
> + consistent_sync(page_address(sg_page(sg)) + sg->offset,
> sg->length, dir);
> }
>
> @@ -138,7 +138,7 @@ dma_sync_sg_for_device(struct device *dev, struct scatterlist *sg, int nelems,
> {
> int i;
> for (i = 0; i < nelems; i++, sg++)
> - consistent_sync(page_address(sg->page) + sg->offset,
> + consistent_sync(page_address(sg_page(sg)) + sg->offset,
> sg->length, dir);
> }
> static inline int
> --
> 1.5.3.GIT
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [PATCH] Use the new sg_page() helper
From: Linus Torvalds @ 2007-10-23 17:00 UTC (permalink / raw)
To: Emil Medve
Cc: axboe, chris, grundler, linux-kernel, anil.s.keshavamurthy, kyle,
linuxppc-dev, paulus, shaohua.li, linux-arm-kernel, parisc-linux,
ashok.raj
In-Reply-To: <1193156092-11819-1-git-send-email-Emilian.Medve@Freescale.com>
On Tue, 23 Oct 2007, Emil Medve wrote:
>
> Fix build error messages such as this:
Some - but apparently not all - of these are already fixed in my tree,
through pulls from Jens. I just pushed out the result, can you resend the
parts that didn't already get fixed?
As is, the patch won't apply for me, since it touches many different parts
and some of them are fixed.
Linus
^ permalink raw reply
* Re: [PATCH] PowerPC 440EPx Sequoia USB OHCI DTS entry
From: Segher Boessenkool @ 2007-10-23 17:03 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev, linux-usb-devel
In-Reply-To: <20071008142658.GA15197@ru.mvista.com>
> + compatible = "ohci-be";
Can we fix this please, in the same way as with EHCI? I.e., the
"compatible" should say it is USB, e.g. "usb-ohci"; and the
"big-endian" quirkiness should be expressed by a property, not by
the "compatible" name (since that would lead to exponential
explosion of all possible combinations of quirks, if nothing else).
Segher
^ permalink raw reply
* Re: [PATCH] [POWERPC] ucc_geth: Eliminate compile warnings
From: Scott Wood @ 2007-10-23 17:10 UTC (permalink / raw)
To: Medve Emilian-EMMEDVE1; +Cc: netdev, jgarzik, David Miller, linuxppc-dev
In-Reply-To: <598D5675D34BE349929AF5EDE9B03E2701685446@az33exm24.fsl.freescale.net>
On Mon, Oct 22, 2007 at 06:47:32AM -0700, Medve Emilian-EMMEDVE1 wrote:
> Are you suggesting we leave those warnings there until somebody decides
> to fix all the portability issues of this driver? My patch is a small
> and insignificant improvement and not the revolution you're asking for,
> but is an small improvement today (I dislike warnings) vs. an improbable
> big one in the future.
It is not an improvement, as it moves the driver further away from being
64-bit clean. A better fix would be to change the definition of
tx/rx_bd_ring_offset to unsigned long (or better yet, a union).
-Scott
^ permalink raw reply
* Re: [PATCH] PowerPC 440EPx Sequoia USB OHCI DTS entry
From: Valentine Barshak @ 2007-10-23 17:18 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, linux-usb-devel
In-Reply-To: <e1b19c12c7006e763a56627fa9a05ec9@kernel.crashing.org>
Segher Boessenkool wrote:
>> + compatible = "ohci-be";
>
> Can we fix this please, in the same way as with EHCI? I.e., the
> "compatible" should say it is USB, e.g. "usb-ohci"; and the
> "big-endian" quirkiness should be expressed by a property, not by
> the "compatible" name (since that would lead to exponential
> explosion of all possible combinations of quirks, if nothing else).
>
>
> Segher
>
I was thinking about it too.
We need to fix the OHCI OF driver and all its users' dts files (if any).
Actually I also don't see much reason for the
USB_OHCI_HCD_PPC_OF_BE/USB_OHCI_HCD_PPC_OF_LE stuff.
Is this really needed?
Thanks,
Valentine.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox