* Re: [PATCH] windfarm: fix windfarm thread freezer interaction
From: Rafael J. Wysocki @ 2007-10-23 20:17 UTC (permalink / raw)
To: Johannes Berg; +Cc: Paul Mackerras, linuxppc-dev list
In-Reply-To: <1193142822.7733.3.camel@johannes.berg>
On Tuesday, 23 October 2007 14:33, Johannes Berg wrote:
> When I fixed the windfarm freezer interaction first in commit
> 1ed2ddf380e19dafeec2150ca709ef7f4a67cd21, an earlier patch than the one
> I came up with after comments was committed. This has come back to haunt
> us now because commit d5d8c5976d6adeddb8208c240460411e2198b393 changed
> the freezer to no long send signals. Fix it by removing the windfarm
> thread's signal logic and restoring the original try_to_freeze().
>
> We could simply revert 1ed2ddf380e19dafeec2150ca709ef7f4a67cd21 now
> but I feel that the assertion that no signal is delivered to the
> windfarm thread needs not be there.
>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
> ---
> drivers/macintosh/windfarm_core.c | 10 +++-------
> 1 file changed, 3 insertions(+), 7 deletions(-)
>
> --- linux-2.6-git.orig/drivers/macintosh/windfarm_core.c 2007-10-23 14:23:02.406437623 +0200
> +++ linux-2.6-git/drivers/macintosh/windfarm_core.c 2007-10-23 14:25:28.745447695 +0200
> @@ -94,7 +94,9 @@ static int wf_thread_func(void *data)
> DBG("wf: thread started\n");
>
> set_freezable();
> - while(!kthread_should_stop()) {
> + while (!kthread_should_stop()) {
> + try_to_freeze();
> +
> if (time_after_eq(jiffies, next)) {
> wf_notify(WF_EVENT_TICK, NULL);
> if (wf_overtemp) {
> @@ -116,12 +118,6 @@ static int wf_thread_func(void *data)
> delay = next - jiffies;
> if (delay <= HZ)
> schedule_timeout_interruptible(delay);
> -
> - /* there should be no non-suspend signal, but oh well */
> - if (signal_pending(current) && !try_to_freeze()) {
> - printk(KERN_WARNING "windfarm: thread got sigl !\n");
> - break;
> - }
> }
>
> DBG("wf: thread stopped\n");
>
>
>
>
^ permalink raw reply
* [PATCH] [POWERPC] Fix mv643xx_pci sysfs .read and .write functions
From: Dale Farnsworth @ 2007-10-23 19:20 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Commit 91a69029 introduced an additional parameter to the .read and .write
methods for sysfs binary attributes. Two mv64x60_pci functions
were missed in that patch, resulting in these errors:
/cache/git/linux-2.6/arch/powerpc/sysdev/mv64x60_pci.c:77: warning: initialization from incompatible pointer type
/cache/git/linux-2.6/arch/powerpc/sysdev/mv64x60_pci.c:78: warning: initialization from incompatible pointer type
Add the missing "struct bin_attribute *" parameter.
Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
---
arch/powerpc/sysdev/mv64x60_pci.c | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/sysdev/mv64x60_pci.c b/arch/powerpc/sysdev/mv64x60_pci.c
index 9b3baa7..6933f9c 100644
--- a/arch/powerpc/sysdev/mv64x60_pci.c
+++ b/arch/powerpc/sysdev/mv64x60_pci.c
@@ -24,8 +24,9 @@
#define MV64X60_VAL_LEN_MAX 11
#define MV64X60_PCICFG_CPCI_HOTSWAP 0x68
-static ssize_t mv64x60_hs_reg_read(struct kobject *kobj, char *buf, loff_t off,
- size_t count)
+static ssize_t mv64x60_hs_reg_read(struct kobject *kobj,
+ struct bin_attribute *attr, char *buf,
+ loff_t off, size_t count)
{
struct pci_dev *phb;
u32 v;
@@ -44,8 +45,9 @@ static ssize_t mv64x60_hs_reg_read(struct kobject *kobj, char *buf, loff_t off,
return sprintf(buf, "0x%08x\n", v);
}
-static ssize_t mv64x60_hs_reg_write(struct kobject *kobj, char *buf, loff_t off,
- size_t count)
+static ssize_t mv64x60_hs_reg_write(struct kobject *kobj,
+ struct bin_attribute *attr, char *buf,
+ loff_t off, size_t count)
{
struct pci_dev *phb;
u32 v;
--
1.5.3.4
^ permalink raw reply related
* Re: [PATCH] [POWERPC] Fix fallout from sg_page changes
From: Dale Farnsworth @ 2007-10-23 19:15 UTC (permalink / raw)
To: Jens Axboe; +Cc: linux-kernel, linuxppc-dev
In-Reply-To: <20071023184448.GE14671@kernel.dk>
On Tue, Oct 23, 2007 at 08:44:48PM +0200, Jens Axboe wrote:
> On Tue, Oct 23 2007, Dale Farnsworth wrote:
> >
> > Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
> > ---
> > include/asm-powerpc/dma-mapping.h | 10 +++++-----
> > 1 files changed, 5 insertions(+), 5 deletions(-)
>
> Should already be merged in Linus' current tree.
Yes, it is. Thank you.
-Dale
^ permalink raw reply
* Re: Device trees and audio codecs
From: Scott Wood @ 2007-10-23 19:12 UTC (permalink / raw)
To: Timur Tabi; +Cc: PowerPC dev list
In-Reply-To: <471CA082.1050304@freescale.com>
On Mon, Oct 22, 2007 at 08:07:14AM -0500, Timur Tabi wrote:
> Either you do it at driver __init time, or via a probe. The probe
> actually occurs at __init time, anyway, so they're kinda the same thing.
> The only thing the probe gets you is that you're called multiple times
> for each instance of a node in the tree.
It also means that you're *not* called if there's no node in the tree at all
-- which I believe was Jon's point about being platform specific.
-Scott
^ permalink raw reply
* Re: [PATCH v6 resend 9/9] add MPC837x MDS board default device tree
From: Scott Wood @ 2007-10-23 19:02 UTC (permalink / raw)
To: Li Yang-r58472; +Cc: linuxppc-dev, paulus
In-Reply-To: <989B956029373F45A0B8AF0297081890019B5BD6@zch01exm26.fsl.freescale.net>
On Thu, Oct 18, 2007 at 11:10:43PM +0800, Li Yang-r58472 wrote:
> Do we still need address-cell and size-cell even when it has no child
> node?
Maybe not *need*, but we do want it... it makes it less likely to be
screwed up if someone adds a child node in the future.
-Scott
^ permalink raw reply
* Re: Kernel function having physical address. how?
From: Scott Wood @ 2007-10-23 18:51 UTC (permalink / raw)
To: Barisa Kisku; +Cc: linuxppc-embedded
In-Reply-To: <80bb1bc60710230322t17fa517bt324031195abced24@mail.gmail.com>
Barisa Kisku wrote:
> I have ported linux-2.6.20 in cutom board based on MPC860.Kernel
> with the KERNELBASE as default 0xc00000000. uImage is downloaded at
> some address and booted with "bootm" command.Kernel is uncompressed
> and loaded at 0x00000000.All the kernel function is now having
> physical address (e.g. 0x000020c8 instead of 0xc00020c8, which is
> given by compiler).I think this required, to run kernel before MMU is
> on, but how this change in assembled code happens.
There is no change in the code itself -- the kernel is merely careful to
avoid (or fix up) data references before the MMU is turned on (which
happens quite early).
> Does u-boot do
> this when uncompressing and loading the kernel.
No.
-Scott
^ permalink raw reply
* Re: FDT bindings for I2C devices
From: Grant Likely @ 2007-10-23 18:50 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-embedded
In-Reply-To: <471E3DD8.4060508@freescale.com>
On 10/23/07, Scott Wood <scottwood@freescale.com> wrote:
> Grant Likely wrote:
> > Scott Wood made an attempt at defining a device binding for I2C
> > devices, but it has not been merged into booting-without-of.txt yet.
> > I've copied what he wrote below. I would add to his definition the
> > following:
> > - If compatible is missing, driver should *not* fall back to the device name.
> > - 'compatible' list should include the exact device in the form "<mfg>,<part>"
>
> Those are good recommendations for any node, but I don't see why i2c in
> particular should mandate it.
I only mention it because the example given doesn't show that.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: DMA problem - mpc8xx
From: Scott Wood @ 2007-10-23 18:49 UTC (permalink / raw)
To: raul.moreno; +Cc: linuxppc-embedded
In-Reply-To: <OF0ED90B65.60296006-ONC125737D.0028DB92-C125737D.002A55F3@abengoa.com>
raul.moreno@telvent.abengoa.com wrote:
> Hi everybody,
>
> I am having problems with the serial cpm driver in a mpc866. But I've found
> out that my problem comes from the DMA and not really from the driver. The
> Rx and Tx buffers use the DMA and then the sytem hangs. However, if I set
> these buffers to internal ram memory (DPRAM), it works. The DMA address is
> configured with a kernel parameter in advance setup:
> CONFIG_CONSISTENT_START (and the size in CONFIG_CONSISTENT_SIZE), but I
> don't know what they are exactly and I could not find a right documentation
> about it.
> I saw a pair of mailing list where some guys set the
> CONFIG_CONSISTENT_START to 0xff100000, but my driver continues failing (and
> an error about dma-mapping appears in the boot).
What kernel version? arch/ppc or arch/powerpc? What is the error about
dma-mapping that you get? What does your memory map look like (in
particular, is there anything that might be getting mapped in conflict
with the consistent area at 0xff100000)?
-Scott
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix fallout from sg_page changes
From: Jens Axboe @ 2007-10-23 18:44 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20071023145300.GA18989@xyzzy.farnsworth.org>
On Tue, Oct 23 2007, Dale Farnsworth wrote:
>
> Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
> ---
> include/asm-powerpc/dma-mapping.h | 10 +++++-----
> 1 files changed, 5 insertions(+), 5 deletions(-)
Should already be merged in Linus' current tree.
--
Jens Axboe
^ permalink raw reply
* C67x00 driver and usb keyboard
From: Robertson, Joseph M. @ 2007-10-23 18:43 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1800 bytes --]
Hi,
I have everything in the kernel about usb that will compile turned on. HID, input, mousedev, keybdev, usbcore, c67x00, usbhid. And yet a keyboard or mouse does not work. USB memory keys work fine.
c67x00 detects keyboard and mouse, I get messages telling me the correct devices. But no key strokes or mouse input. Even cat /dev/input/mice gets nothing.
Kinda getting real tired of everyone saying it should 'just work'.
Theres a way and a reason how the keyboard works, and something isn't right, it does not work.
Anyone ever have a similar problem?
Thanks,
Joe Robertson
Joseph.Robertson@sanmina-sci.com
CONFIDENTIALITY
This e-mail message and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail message, you are hereby notified that any dissemination, distribution or copying of this e-mail message, and any attachments thereto, is strictly prohibited. If you have received this e-mail message in error, please immediately notify the sender and permanently delete the original and any copies of this email and any prints thereof.
ABSENT AN EXPRESS STATEMENT TO THE CONTRARY HEREINABOVE, THIS E-MAIL IS NOT INTENDED AS A SUBSTITUTE FOR A WRITING. Notwithstanding the Uniform Electronic Transactions Act or the applicability of any other law of similar substance and effect, absent an express statement to the contrary hereinabove, this e-mail message its contents, and any attachments hereto are not intended to represent an offer or acceptance to enter into a contract and are not otherwise intended to bind the sender, Sanmina-SCI Corporation (or any of its subsidiaries), or any other person or entity.
[-- Attachment #2: Type: text/html, Size: 2291 bytes --]
^ permalink raw reply
* Re: [PATCH] Use the new sg_page() helper
From: Jens Axboe @ 2007-10-23 18:40 UTC (permalink / raw)
To: Linus Torvalds
Cc: chris, grundler, linux-kernel, Emil Medve, kyle, linuxppc-dev,
paulus, anil.s.keshavamurthy, shaohua.li, linux-arm-kernel,
parisc-linux, ashok.raj
In-Reply-To: <alpine.LFD.0.999.0710230956330.30120@woody.linux-foundation.org>
On Tue, Oct 23 2007, Linus Torvalds wrote:
>
>
> 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.
Looks like just the mmc and xtensa bits, I've merged those up.
--
Jens Axboe
^ permalink raw reply
* Ocotea board?
From: Jeff Mock @ 2007-10-23 18:13 UTC (permalink / raw)
To: linuxppc-dev, linuxppc-embedded
Is the Ocotea board (the original 440GX eval board) still interesting?
I'm wrapping up a project using the 440GX, I started out hacking on the
Ocotea board to get started, but we moved off Ocotea long ago onto our
own hardware.
I'm cleaning up the lab now that the project is nearly finished and I
would like to give the board to someone that will put it to good use.
I've sponged off this mailing list quite a lot, it's about time I give a
little something back.
The board has been hacked a little bit but still works fine. I just
powered it up and it happily booted Linux via TFTP. The boot ROM now
has u-boot, the original PIBs (or whatever) is long gone. All I ask is
that you're self-sufficient and don't bug me too much about it...
Can someone recommend a good home? Otherwise it will wind up in
storeroom purgatory.
jeff
^ permalink raw reply
* Re: FDT bindings for I2C devices
From: Scott Wood @ 2007-10-23 18:30 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <fa686aa40710190738q1211a266lced10ac8767e5071@mail.gmail.com>
Grant Likely wrote:
> Scott Wood made an attempt at defining a device binding for I2C
> devices, but it has not been merged into booting-without-of.txt yet.
> I've copied what he wrote below. I would add to his definition the
> following:
> - If compatible is missing, driver should *not* fall back to the device name.
> - 'compatible' list should include the exact device in the form "<mfg>,<part>"
Those are good recommendations for any node, but I don't see why i2c in
particular should mandate it.
-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
* 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: 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] 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] 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: 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] 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
* [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: [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
* 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: [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] 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
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