* [PATCH 1/2] [v2] powerpc: export ppc_proc_freq and ppc_tb_freq as GPL symbols
From: Timur Tabi @ 2010-09-20 16:23 UTC (permalink / raw)
To: benh, linuxppc-dev, kumar.gala, linux-watchdog, jwboyer
Export the global variable 'ppc_tb_freq', so that modules (like the Book-E
watchdog driver) can use it. To maintain consistency, ppc_proc_freq is changed
to a GPL-only export. This is okay, because any module that needs this symbol
should be an actual Linux driver, which must be GPL-licensed.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
This export is necessary for the Book-E watchdog driver to be compiled as a
module.
arch/powerpc/kernel/time.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index 8533b3b..0c0c241 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -161,8 +161,9 @@ extern struct timezone sys_tz;
static long timezone_offset;
unsigned long ppc_proc_freq;
-EXPORT_SYMBOL(ppc_proc_freq);
+EXPORT_SYMBOL_GPL(ppc_proc_freq);
unsigned long ppc_tb_freq;
+EXPORT_SYMBOL_GPL(ppc_tb_freq);
static DEFINE_PER_CPU(u64, last_jiffy);
--
1.7.2.3
^ permalink raw reply related
* [PATCH 2/2] [v2] powerpc/watchdog: allow the e500 watchdog driver to be compiled as a module
From: Timur Tabi @ 2010-09-20 16:23 UTC (permalink / raw)
To: benh, linuxppc-dev, kumar.gala, linux-watchdog, jwboyer
In-Reply-To: <1284999822-24753-1-git-send-email-timur@freescale.com>
Register the __init and __exit functions in the PowerPC e500 watchdog driver
as module entry/exit functions, and modify the Kconfig entry.
Add a .release method for the PowerPC e500 watchdog driver, so that the
watchdog is disabled when the driver is closed.
Loosely based on original code from Jiang Yutang <b14898@freescale.com>.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
This patch requires:
powerpc: export ppc_proc_freq and ppc_tb_freq as GPL symbols
drivers/watchdog/Kconfig | 5 ++++-
drivers/watchdog/booke_wdt.c | 39 +++++++++++++++++++++++++++++++++++++--
2 files changed, 41 insertions(+), 3 deletions(-)
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 24efd8e..a6812eb 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -957,9 +957,12 @@ config PIKA_WDT
the Warp platform.
config BOOKE_WDT
- bool "PowerPC Book-E Watchdog Timer"
+ tristate "PowerPC Book-E Watchdog Timer"
depends on BOOKE || 4xx
---help---
+ Watchdog driver for PowerPC Book-E chips, such as the Freescale
+ MPC85xx SOCs and the IBM PowerPC 440.
+
Please see Documentation/watchdog/watchdog-api.txt for
more information.
diff --git a/drivers/watchdog/booke_wdt.c b/drivers/watchdog/booke_wdt.c
index 3d49671..a989998 100644
--- a/drivers/watchdog/booke_wdt.c
+++ b/drivers/watchdog/booke_wdt.c
@@ -4,7 +4,7 @@
* Author: Matthew McClintock
* Maintainer: Kumar Gala <galak@kernel.crashing.org>
*
- * Copyright 2005, 2008 Freescale Semiconductor Inc.
+ * Copyright 2005, 2008, 2010 Freescale Semiconductor Inc.
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
@@ -114,6 +114,27 @@ static void __booke_wdt_enable(void *data)
mtspr(SPRN_TCR, val);
}
+/**
+ * booke_wdt_disable - disable the watchdog on the given CPU
+ *
+ * This function is called on each CPU. It disables the watchdog on that CPU.
+ *
+ * TCR[WRC] cannot be changed once it has been set to non-zero, but we can
+ * effectively disable the watchdog by setting its period to the maximum value.
+ */
+static void __booke_wdt_disable(void *data)
+{
+ u32 val;
+
+ val = mfspr(SPRN_TCR);
+ val &= ~(TCR_WIE | WDTP_MASK);
+ mtspr(SPRN_TCR, val);
+
+ /* clear status to make sure nothing is pending */
+ __booke_wdt_ping(NULL);
+
+}
+
static ssize_t booke_wdt_write(struct file *file, const char __user *buf,
size_t count, loff_t *ppos)
{
@@ -193,12 +214,21 @@ static int booke_wdt_open(struct inode *inode, struct file *file)
return nonseekable_open(inode, file);
}
+static int booke_wdt_release(struct inode *inode, struct file *file)
+{
+ on_each_cpu(__booke_wdt_disable, NULL, 0);
+ booke_wdt_enabled = 0;
+
+ return 0;
+}
+
static const struct file_operations booke_wdt_fops = {
.owner = THIS_MODULE,
.llseek = no_llseek,
.write = booke_wdt_write,
.unlocked_ioctl = booke_wdt_ioctl,
.open = booke_wdt_open,
+ .release = booke_wdt_release,
};
static struct miscdevice booke_wdt_miscdev = {
@@ -237,4 +267,9 @@ static int __init booke_wdt_init(void)
return ret;
}
-device_initcall(booke_wdt_init);
+
+module_init(booke_wdt_init);
+module_exit(booke_wdt_exit);
+
+MODULE_DESCRIPTION("PowerPC Book-E watchdog driver");
+MODULE_LICENSE("GPL");
--
1.7.2.3
^ permalink raw reply related
* Re: cuImage and multi image?
From: Shawn Jin @ 2010-09-20 17:52 UTC (permalink / raw)
To: tiejun.chen; +Cc: ppcdev, uboot
In-Reply-To: <4C91C77B.8080501@windriver.com>
>> I have a cuImage kernel in order to support legacy u-boot and a
>> ramdisk image. Kernel boots fine if these two images are separate and
>> "bootm $kernel $ramdisk" is used. But I can not make it to work using
>> a single multi image that contains the kernel and ramdisk images. Is
>> it even technically possible to boot a multi-image with cuboot
>> wrapper?
>
> Try the following steps:
> ------
> 1. cp <your ramdisk.gz> arch/powerpc/boot/ramdisk.image.gz
> 2. make cuImage.initrd.<your target>
>
> You can get one Image, cuImage.initrd.<your target>, including kernel and ramdisk.
A follow up question. With this method, the total image size
(uncompressed) is limited to the 4MB (the link address of the boot
wrapper)?
Thanks,
-Shawn.
^ permalink raw reply
* RE: [PATCH 1/2] PPC4xx: Generelizing drivers/dma/ppc4xx/adma.c
From: Tirumala Marri @ 2010-09-20 18:00 UTC (permalink / raw)
To: Wolfgang Denk
Cc: neilb, yur, linux-raid, herbert, linux-crypto, dan.j.williams,
linuxppc-dev
In-Reply-To: <20100918210920.E05AE157D71@gemini.denx.de>
Mr. Wolfgang
>
> Will this driver ever include any 40x processors? If not, you probably
> should use "44x" instead (here and everywhere in the rest of the
> code).
[Marri] Yes there is 40x based DMA engine we planned to include in the
future.
> > +/* Pointer to DMA0, DMA1 CP/CS FIFO */
> > +static void *ppc440spe_dma_fifo_buf;
>
> Seems this should go into "ppc440spe-dma.h"?
>
>
> > +/* This array is used in data-check operations for storing a pattern
> */
> > +static char ppc440spe_qword[16];
> > +
> > +static atomic_t ppc4xx_adma_err_irq_ref;
> > +static dcr_host_t ppc440spe_mq_dcr_host;
> > +static unsigned int ppc440spe_mq_dcr_len;
>
> Ditto?
>
> > +static unsigned long ppc440spe_rxor_state;
> > +
> > +static struct page *ppc440spe_rxor_srcs[32];
>
> And here again - please check globally!
>
>
> > +/**
> > + * ppc440spe_can_rxor - check if the operands may be processed with
> RXOR
> > + */
> > +static int ppc440spe_can_rxor(struct page **srcs, int src_cnt,
> size_t len)
>
> Again, should this then not be in ppc440spe specific files?
>
>
> It seems the split / generalization is highly incomplete yet.
[Marri] Some of the stuff can go into ppc440spe-dma.h. This is just
Beginning to add more new DMA engines support. I expect more changes to
come in.
Regards,
Marri
^ permalink raw reply
* Re: [PATCH 1/2] powerpc: export ppc_tb_freq so that modules can reference it
From: Scott Wood @ 2010-09-20 18:51 UTC (permalink / raw)
To: Josh Boyer
Cc: linuxppc-dev, Gala Kumar-B11780, Tabi Timur-B04825,
linux-watchdog
In-Reply-To: <AANLkTi=RXjc=GZ+RRsKjL3qdYFayXOCX0s1SU5jojeXg@mail.gmail.com>
On Sat, 18 Sep 2010 14:22:12 -0400
Josh Boyer <jwboyer@gmail.com> wrote:
> Capitalizing? The patch you posted that uses this symbol is for a GPL
> driver so you gain or lose nothing by having this symbol be
> EXPORT_SYMBOL_GPL. Are you somehow advocating and getting some sort
> of gain by allowing non-GPL modules? If so, I find that unfortunate.
> If not, then I guess I don't understand what you mean by capitalizing.
One can dislike DRM (even a very weak form such as this) without having
a particular desire to go outside the bounds of what it allows.
I thought EXPORT_SYMBOL_GPL was originally meant to indicate the
symbols whose use is likely to be indicitave of code that is, in some
copyright-meaningful way, derived from GPL code? I have a hard time
seeing that being the case here. If every symbol is made GPL-only,
then that just gives the binary-only people[1] more incentive to
circumvent the entire mechanism. It loses its meaning.
Documentation/DocBook/kernel-hacking.tmpl says, "It implies that the
function is considered an internal implementation issue, and not really
an interface."
-Scott
[1] Plus anyone who might want to make a kernel module out of code
which is open source, but not under a license the GPLv2 is compatible
with.
^ permalink raw reply
* Re: [PATCH v2 03/10] RapidIO: Use stored ingress port number instead of register read
From: Andrew Morton @ 2010-09-20 19:17 UTC (permalink / raw)
To: Bounine, Alexandre; +Cc: linux-kernel, Thomas Moll, linuxppc-dev
In-Reply-To: <0CE8B6BE3C4AD74AB97D9D29BD24E55201303D0E@CORPEXCH1.na.ads.idt.com>
On Mon, 20 Sep 2010 07:31:22 -0700
"Bounine, Alexandre" <Alexandre.Bounine@idt.com> wrote:
> Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> > > @@ -219,6 +219,7 @@ struct rio_net {
> > > /**
> > > * struct rio_switch - RIO switch info
> > > * @node: Node in global list of switches
> > > + * @rdev: Associated RIO device structure
> > > * @switchid: Switch ID that is unique across a network
> > > * @hopcount: Hopcount to this switch
> > > * @destid: Associated destid in the path
> > > @@ -234,6 +235,7 @@ struct rio_net {
> > > */
> > > struct rio_switch {
> > > struct list_head node;
> > > + struct rio_dev *rdev;
> > > u16 switchid;
> > > u16 hopcount;
> > > u16 destid;
> >
> > What is the locking for rdev?
>
> This question prompted me consider the following change:
>
> Because the rio_switch structure (in current implementation) is a
> dynamically allocated part of rio_dev, I think it may be simpler to
> combine them into single allocation by using zero length array
> declaration:
>
> struct rio_dev {
> struct list_head global_list;
> struct list_head net_list;
> .....
> ..... rest of rio_dev
> .....
> struct rio_switch switch[0];
> }
>
> This will remove extra memory allocation, remove overlapping structure
> members and clean code sections like one shown below:
>
> u8 hopcount = 0xff;
> u16 destid = rdev->destid;
>
> if (rdev->rswitch) {
> destid = rdev->rswitch->destid;
> hopcount = rdev->rswitch->hopcount;
> }
>
> And this looks better aligned with RapidIO definitions - both: endpoints
> and switches are RIO devices. The current implementation of rio_dev
> somewhat separates rio_switch from its common part (this is why I have
> added that link into rio_switch). We may keep using the pointer to
> associated rio_dev, but reworking the rio_dev structure seems better way
> to me.
>
> Please, let me know what do you think about this conversion. And if
> there are no objections I will make a patch.
>
If you say so ;)
The "variable length array at the end of the struct" thing is pretty
commonly used and works well. As long as we never want to change the
number of switches on the fly (hotplug?).
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/watchdog: allow the e500 watchdog driver to be compiled as a module
From: Josh Boyer @ 2010-09-20 19:30 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, kumar.gala, linux-watchdog
In-Reply-To: <AANLkTimp-0zdw-fAaX8qCwHW0NMn--6RK0_USDGOSe47@mail.gmail.com>
On Mon, Sep 20, 2010 at 10:51:37AM -0500, Timur Tabi wrote:
>On Fri, Sep 17, 2010 at 7:37 PM, Josh Boyer <jwboyer@gmail.com> wrote:
>>> config BOOKE_WDT
>>> - bool "PowerPC Book-E Watchdog Timer"
>>> + tristate "PowerPC Book-E Watchdog Timer"
>>> depends on BOOKE || 4xx
>>> ---help---
>>> + Watchdog driver for PowerPC e500 chips, such as the Freescale
>>> + MPC85xx SOCs.
>>> +
>>
>> Again, used for more than e500. That || 4xx in the depends statement
>> right above your addition isn't there for fun :).
>
>Does this mean that this comment which is already in the driver is
>wrong? It alludes that "Book-E" is synonymous with "e500".
>
>/* If the kernel parameter wdt=1, the watchdog will be enabled at boot.
> * Also, the wdt_period sets the watchdog timer period timeout.
> * For E500 cpus the wdt_period sets which bit changing from 0->1 will
> * trigger a watchog timeout. This watchdog timeout will occur 3 times, the
> * first time nothing will happen, the second time a watchdog exception will
> * occur, and the final time the board will reset.
> */
I guess I don't see what you mean. It talks about e500 but it doesn't
say "Book-E" anywhere in that comment. (Though I'm pretty sure that
comment does apply to 4xx.)
>
>#ifdef CONFIG_FSL_BOOKE
>#define WDT_PERIOD_DEFAULT 38 /* Ex. wdt_period=28 bus=333Mhz,reset=~40sec */
>#else
>#define WDT_PERIOD_DEFAULT 3 /* Refer to the PPC40x and PPC4xx manuals */
>#endif /* for timing information */
And this bit is marked as "FSL_BOOKE" vs. 40x and 44x.
josh
^ permalink raw reply
* Re: [PATCH 1/2] [v2] powerpc: export ppc_proc_freq and ppc_tb_freq as GPL symbols
From: Josh Boyer @ 2010-09-20 19:30 UTC (permalink / raw)
To: Timur Tabi; +Cc: kumar.gala, linux-watchdog, linuxppc-dev
In-Reply-To: <1284999822-24753-1-git-send-email-timur@freescale.com>
On Mon, Sep 20, 2010 at 11:23:41AM -0500, Timur Tabi wrote:
>Export the global variable 'ppc_tb_freq', so that modules (like the Book-E
>watchdog driver) can use it. To maintain consistency, ppc_proc_freq is changed
>to a GPL-only export. This is okay, because any module that needs this symbol
>should be an actual Linux driver, which must be GPL-licensed.
>
>Signed-off-by: Timur Tabi <timur@freescale.com>
Acked-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
>---
>
>This export is necessary for the Book-E watchdog driver to be compiled as a
>module.
>
> arch/powerpc/kernel/time.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
>diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
>index 8533b3b..0c0c241 100644
>--- a/arch/powerpc/kernel/time.c
>+++ b/arch/powerpc/kernel/time.c
>@@ -161,8 +161,9 @@ extern struct timezone sys_tz;
> static long timezone_offset;
>
> unsigned long ppc_proc_freq;
>-EXPORT_SYMBOL(ppc_proc_freq);
>+EXPORT_SYMBOL_GPL(ppc_proc_freq);
> unsigned long ppc_tb_freq;
>+EXPORT_SYMBOL_GPL(ppc_tb_freq);
>
> static DEFINE_PER_CPU(u64, last_jiffy);
>
>--
>1.7.2.3
>
>
>_______________________________________________
>Linuxppc-dev mailing list
>Linuxppc-dev@lists.ozlabs.org
>https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* RE: [PATCH v2 03/10] RapidIO: Use stored ingress port number instead of register read
From: Bounine, Alexandre @ 2010-09-20 19:49 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Thomas Moll, linuxppc-dev
In-Reply-To: <20100920121725.66bb96d0.akpm@linux-foundation.org>
Andrew Morton <akpm@linux-foundation.org> wrote:
>=20
> The "variable length array at the end of the struct" thing is pretty
> commonly used and works well. As long as we never want to change the
> number of switches on the fly (hotplug?).
This is expected to be a "strange" array - its size can be 0 or 1 only.
No number of switches in that array should be changed on the fly.
In the hotplug situation entire rio_dev structure should be added (or
removed).
RIO device can be endpoint or switch. If a RIO device is a switch - the
rio_switch
structure will be added at the end.
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/watchdog: allow the e500 watchdog driver to be compiled as a module
From: Timur Tabi @ 2010-09-20 19:53 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, kumar.gala, linux-watchdog
In-Reply-To: <20100920193016.GA3845@zod.rchland.ibm.com>
Josh Boyer wrote:
> I guess I don't see what you mean. It talks about e500 but it doesn't
> say "Book-E" anywhere in that comment. (Though I'm pretty sure that
> comment does apply to 4xx.)
That was my point. The comment says e500, but the code is also intended for
4xx.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH v2 03/10] RapidIO: Use stored ingress port number instead of register read
From: Micha Nelissen @ 2010-09-20 20:40 UTC (permalink / raw)
To: Bounine, Alexandre; +Cc: linux-kernel, Thomas Moll, Andrew Morton, linuxppc-dev
In-Reply-To: <0CE8B6BE3C4AD74AB97D9D29BD24E55201303D0E@CORPEXCH1.na.ads.idt.com>
Hi Alex,
Bounine, Alexandre wrote:
> struct rio_dev {
> struct list_head global_list;
> struct list_head net_list;
> .....
> ..... rest of rio_dev
> .....
> struct rio_switch switch[0];
> }
It makes sense to let rio_dev structures point to the switch they are
attached to. That can be useful in various situations, but is not
possible with this setup.
If a rio_dev is a switch then rdev->rswitch->rdev == rdev holds.
> This will remove extra memory allocation, remove overlapping structure
> members and clean code sections like one shown below:
>
> u8 hopcount = 0xff;
> u16 destid = rdev->destid;
>
> if (rdev->rswitch) {
> destid = rdev->rswitch->destid;
> hopcount = rdev->rswitch->hopcount;
> }
Note that it is possible for rdev->destid to differ from
rdev->rswitch->destid even if rswitch->rdev == rdev (for non-hosts i.e.
agents). rswitch->destid is the destid by which we discovered the switch
(and can reach it) but rdev->destid is the actual id given to the switch.
Micha
^ permalink raw reply
* Re: [PATCH 1/2] PPC4xx: Generelizing drivers/dma/ppc4xx/adma.c
From: Wolfgang Denk @ 2010-09-20 21:31 UTC (permalink / raw)
To: Tirumala Marri
Cc: neilb, yur, linux-raid, herbert, linux-crypto, dan.j.williams,
linuxppc-dev
In-Reply-To: <7707889dee57e97ad50b4ce5c7697466@mail.gmail.com>
Dear Tirumala Marri,
In message <7707889dee57e97ad50b4ce5c7697466@mail.gmail.com> you wrote:
>
> > > +/**
> > > + * ppc440spe_can_rxor - check if the operands may be processed with RXOR
> > > + */
> > > +static int ppc440spe_can_rxor(struct page **srcs, int src_cnt,
> > size_t len)
> >
> > Again, should this then not be in ppc440spe specific files?
> >
> >
> > It seems the split / generalization is highly incomplete yet.
>
> [Marri] Some of the stuff can go into ppc440spe-dma.h. This is just
> Beginning to add more new DMA engines support. I expect more changes to
> come in.
Why would that go into a header file? This is source code, not header
stuff. It should stay in a .c file! [Note that Ilya asked the same
question.]
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Intel's new motto: United we stand. Divided we fall!
^ permalink raw reply
* RE: Generating elf kernel ?
From: Chen, Tiejun @ 2010-09-21 1:00 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Guillaume Dargaud
In-Reply-To: <20100920104353.5dbd9201@udp111988uds.am.freescale.net>
> -----Original Message-----
> From: Scott Wood [mailto:scottwood@freescale.com]=20
> Sent: Monday, September 20, 2010 11:44 PM
> To: Chen, Tiejun
> Cc: linuxppc-dev@lists.ozlabs.org; Guillaume Dargaud
> Subject: Re: Generating elf kernel ?
>=20
> On Sun, 19 Sep 2010 09:40:15 +0800
> "tiejun.chen" <tiejun.chen@windriver.com> wrote:
>=20
> > Scott Wood wrote:
> > > On Fri, 17 Sep 2010 09:58:41 +0800
> > > "tiejun.chen" <tiejun.chen@windriver.com> wrote:
> > >=20
> > >> Scott Wood wrote:
> > >>> The guest OS *is* the same as native Linux, as far as=20
> TLB handling=20
> > >>> is concerned.
> > >> Looks you means the TLB exception handler should be same between=20
> > >> the native and the guest OS. Right?
> > >=20
> > > Yes.
> >=20
> > I don't think so. The HY should assist the guest OS on MMU since I=20
> > already point the guest OS have no authority to create a=20
> real TLB directly as I previously said.
>=20
> Of course the hypervisor assists, when a trap is taken. That=20
> doesn't mean the code is any different in the guest.
This should be depend on the hypervisor design implementation. I think
your=20
option should be based on the Freescale hypervisor.
>=20
> > > Yes, of course. But that's not the point. I was just=20
> using it as a=20
> > > convenient example because that's what I've recently done ELF=20
> > > loading with... There's no reason U-Boot couldn't do the same if=20
> > > its ELF loader were updated to support device trees. Currently=20
> > > U-Boot loads bootwrapperless uImages to physical address zero.
> >=20
> > I never doubt the U-boot can do this for uImage. But I think we're=20
> > always talking about vmlinux, a bare Image.
>=20
> uImage is pretty much a bare image. It just has a header=20
> with a checksum and some info like OS/architecture, kernel=20
> version, build date, etc.
Yes. But it also inlcude load address and entry point used to u-boot.
>=20
> There would be *no* problem doing this with vmlinux in U-Boot=20
> if someone put in the code to pass a device tree.
This is just I always emphasize previously.
Cheers
Tiejun
>=20
> -Scott
>=20
>=20
^ permalink raw reply
* RE: cuImage and multi image?
From: Chen, Tiejun @ 2010-09-21 1:03 UTC (permalink / raw)
To: Shawn Jin; +Cc: ppcdev, uboot
In-Reply-To: <AANLkTikrYdi=V6jM4HS3V4XzMutGdkPA2qHRBgviKHM8@mail.gmail.com>
> -----Original Message-----
> From: Shawn Jin [mailto:shawnxjin@gmail.com]=20
> Sent: Tuesday, September 21, 2010 1:53 AM
> To: Chen, Tiejun
> Cc: ppcdev; uboot
> Subject: Re: cuImage and multi image?
>=20
> >> I have a cuImage kernel in order to support legacy u-boot and a=20
> >> ramdisk image. Kernel boots fine if these two images are=20
> separate and=20
> >> "bootm $kernel $ramdisk" is used. But I can not make it to=20
> work using=20
> >> a single multi image that contains the kernel and ramdisk=20
> images. Is=20
> >> it even technically possible to boot a multi-image with cuboot=20
> >> wrapper?
> >
> > Try the following steps:
> > ------
> > 1. cp <your ramdisk.gz> arch/powerpc/boot/ramdisk.image.gz
> > 2. make cuImage.initrd.<your target>
> >
> > You can get one Image, cuImage.initrd.<your target>,=20
> including kernel and ramdisk.
>=20
> A follow up question. With this method, the total image size
> (uncompressed) is limited to the 4MB (the link address of the=20
> boot wrapper)?
No.
Cheers
Tiejun
>=20
> Thanks,
> -Shawn.
>=20
^ permalink raw reply
* Dual ethernet attachment with single FEC
From: LEROY Christophe @ 2010-09-21 7:30 UTC (permalink / raw)
To: LinuxPPC-dev, netdev
Hello,
I have a board with 2 PHYs attached to one FEC ethernet controler on
powerpc.
I want to implement some kind of main-standby attachment to LAN by
setting the ISOLATE bit on one on the two PHYs then monitoring the link
status and switch to the other PHY when the link status goes down.
I see this behaviour is implemented in the sis900 driver, but it doesn't
use the standard PHY layer as the Freescale FEC driver does.
What would be the most proper way to implement this functionality ?
* Modify FEC driver to manage that ?
* Implement a virtual PHY driver that would manage that ?
* Other solution ?
Best regards
C. Leroy
^ permalink raw reply
* [PATCH] fsldma: add support to 36-bit physical address
From: Li Yang @ 2010-09-21 10:57 UTC (permalink / raw)
To: dan.j.williams; +Cc: linuxppc-dev, linux-kernel
Signed-off-by: Li Yang <leoli@freescale.com>
---
drivers/dma/fsldma.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index cea08be..9163552 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -1,7 +1,7 @@
/*
* Freescale MPC85xx, MPC83xx DMA Engine support
*
- * Copyright (C) 2007 Freescale Semiconductor, Inc. All rights reserved.
+ * Copyright (C) 2007-2009 Freescale Semiconductor, Inc. All rights reserved.
*
* Author:
* Zhang Wei <wei.zhang@freescale.com>, Jul 2007
@@ -1338,6 +1338,7 @@ static int __devinit fsldma_of_probe(struct platform_device *op,
fdev->common.device_control = fsl_dma_device_control;
fdev->common.dev = &op->dev;
+ dma_set_mask(&op->dev, DMA_BIT_MASK(36));
dev_set_drvdata(&op->dev, fdev);
/*
--
1.6.6-rc1.GIT
^ permalink raw reply related
* Re: [PATCH 1/2] powerpc: export ppc_tb_freq so that modules can reference it
From: Detlev Zundel @ 2010-09-21 12:34 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20100920135136.04ceb772__36164.799918379$1285008751$gmane$org@udp111988uds.am.freescale.net>
Hi Scott,
> On Sat, 18 Sep 2010 14:22:12 -0400
> Josh Boyer <jwboyer@gmail.com> wrote:
>
>> Capitalizing? The patch you posted that uses this symbol is for a GPL
>> driver so you gain or lose nothing by having this symbol be
>> EXPORT_SYMBOL_GPL. Are you somehow advocating and getting some sort
>> of gain by allowing non-GPL modules? If so, I find that unfortunate.
>> If not, then I guess I don't understand what you mean by capitalizing.
>
> One can dislike DRM (even a very weak form such as this) without having
> a particular desire to go outside the bounds of what it allows.
>
> I thought EXPORT_SYMBOL_GPL was originally meant to indicate the
> symbols whose use is likely to be indicitave of code that is, in some
> copyright-meaningful way, derived from GPL code?
Google finds this, which coincides with what I remmber[1]:
EXPORT_SYMBOL_GPL
Some kernel developers are unhappy with providing external interfaces to
their code, only to see those interfaces being used by binary only
modules. They view it as their work being appropriated. Whether you
agree with that view or not is completely irrelevant, the person who
owns the copyright decides how their work can be used.
EXPORT_SYMBOL_GPL() allows for new interfaces to be marked as only
available to modules with a GPL compatible license. This is independent
of the kernel tainting, but obviously takes advantage of
MODULE_LICENSE() strings.
EXPORT_SYMBOL_GPL() may only be used for new exported symbols, Linus has
spoken. I believe the phrase involved killer penguins with chainsaws for
anybody who changed existing exported interfaces.
Cheers
Detlev
[1] http://lkml.indiana.edu/hypermail/linux/kernel/0110.2/0369.html
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu@denx.de
^ permalink raw reply
* Re: [PATCH] fsldma: add support to 36-bit physical address
From: Kumar Gala @ 2010-09-21 12:55 UTC (permalink / raw)
To: Li Yang; +Cc: dan.j.williams, linuxppc-dev, linux-kernel
In-Reply-To: <1285066638-7473-1-git-send-email-leoli@freescale.com>
On Sep 21, 2010, at 5:57 AM, Li Yang wrote:
> Signed-off-by: Li Yang <leoli@freescale.com>
> ---
We really should have a sentence about how or why this works to address =
36-bit addressing.
> drivers/dma/fsldma.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>=20
> diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
> index cea08be..9163552 100644
> --- a/drivers/dma/fsldma.c
> +++ b/drivers/dma/fsldma.c
> @@ -1,7 +1,7 @@
> /*
> * Freescale MPC85xx, MPC83xx DMA Engine support
> *
> - * Copyright (C) 2007 Freescale Semiconductor, Inc. All rights =
reserved.
> + * Copyright (C) 2007-2009 Freescale Semiconductor, Inc. All rights =
reserved.
> *
> * Author:
> * Zhang Wei <wei.zhang@freescale.com>, Jul 2007
> @@ -1338,6 +1338,7 @@ static int __devinit fsldma_of_probe(struct =
platform_device *op,
> fdev->common.device_control =3D fsl_dma_device_control;
> fdev->common.dev =3D &op->dev;
>=20
> + dma_set_mask(&op->dev, DMA_BIT_MASK(36));
> dev_set_drvdata(&op->dev, fdev);
>=20
> /*
> --=20
> 1.6.6-rc1.GIT
>=20
>=20
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Questions on interrupt vector assignment on MPC8641D
From: david.hagood @ 2010-09-21 14:12 UTC (permalink / raw)
To: linuxppc-dev
I'm new to developing on the PPC (most of my experience is on x86), and I
have a couple of questions about mapping of interrupts on the PPC,
specifically on the Freescale 8641D embedded CPU.
1) How does one allocate interrupt vectors for the embedded devices, such
as the MPIC? All the kernel how-tos are really targeting the x86 and PCI,
so I've been unable to find a good document on "that which is not an X86".
2) Are there any good guides to programming the PPC generally, and the
MPC8641 specifically, that I can go read to answer my other questions?
I'm trying to write a driver to map the 8641D's PCIe controllers *as
endpoints* into something frobablbe from user space - to allow setting the
BARs and outbound address translation units via sysfs files, and to allow
mapping of inbound interrupts to sysfs "doorbell"-style files. If I can
get it worked out I want to submit it back to the kernel for general
distribution.
If anybody has any insights, I'd greatly appreciate it if you'd copy my
work email (david.hagood at aeroflex.com) as well (I am using my personal
email as work insisted upon adding a one paragraph "wart" to all outbound
email that isn't acceptable for a list like this.)
Also, if anybody out there has experience with the 8641D PEX's in endpoint
mode and wouldn't mind answering a couple of questions about programming
the OWBARs, I'd be greatly obliged.
^ permalink raw reply
* Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
From: Stephan Gatzka @ 2010-09-21 16:54 UTC (permalink / raw)
To: netdev, devicetree-discuss, linux-kernel, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <20100906063327.GA4549@riccoc20.at.omicron.at>
[-- Attachment #1: Type: text/plain, Size: 402 bytes --]
Hi Richard,
> 1. Character device
> 2. POSIX clock with dynamic ids
>
> Please, just take your pick ;^)
Just to reopen this nearly dead but very interesting thread: I'm happy
with every solution that has no impact on the accuracy of the PTP clock.
If I can choose, I would prefer the POSIX clock with dynamic ids solution.
Kind regards and thanks for your effort,
Stephan Gatzka
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5136 bytes --]
^ permalink raw reply
* RE: [PATCH 1/2] PPC4xx: Generelizing drivers/dma/ppc4xx/adma.c
From: Tirumala Marri @ 2010-09-21 16:51 UTC (permalink / raw)
To: Ilya Yanok, linuxppc-dev
In-Reply-To: <loom.20100919T215645-646@post.gmane.org>
> -----Original Message-----
> From: linuxppc-dev-bounces+tmarri=amcc.com@lists.ozlabs.org
> [mailto:linuxppc-dev-bounces+tmarri=amcc.com@lists.ozlabs.org] On
> Behalf Of Ilya Yanok
> Sent: Sunday, September 19, 2010 1:01 PM
> To: linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH 1/2] PPC4xx: Generelizing drivers/dma/ppc4xx/adma.c
>
> Hi Tirumala,
>
> > drivers/dma/ppc4xx/adma.c | 4370 +++-------------------------
> ----------
> > drivers/dma/ppc4xx/adma.h | 116 +-
> > drivers/dma/ppc4xx/ppc4xx-adma.h | 4020
> +++++++++++++++++++++++++++++++++++
>
> You've moved tons of code to the header file. Why?
>
> Regards, Ilya.
>
My intention is to keep the SoC specific code in the header files.
Something iop-dma is also doing.
^ permalink raw reply
* Re: Generating elf kernel ?
From: Scott Wood @ 2010-09-21 17:00 UTC (permalink / raw)
To: Chen, Tiejun; +Cc: linuxppc-dev, Guillaume Dargaud
In-Reply-To: <52CF90264091A14888078A031D780F4306C8BD2F@ism-mail03.corp.ad.wrs.com>
On Tue, 21 Sep 2010 03:00:40 +0200
"Chen, Tiejun" <Tiejun.Chen@windriver.com> wrote:
> This should be depend on the hypervisor design implementation. I think
> your
> option should be based on the Freescale hypervisor.
Again, I was giving an example, about ELF loading. I was not making any
claims about what all hypervisors do. :-P
-Scott
^ permalink raw reply
* Re: [U-Boot] cuImage and multi image?
From: Scott Wood @ 2010-09-21 17:52 UTC (permalink / raw)
To: Chen, Tiejun; +Cc: ppcdev, uboot
In-Reply-To: <52CF90264091A14888078A031D780F4306C8BD30@ism-mail03.corp.ad.wrs.com>
On Tue, 21 Sep 2010 03:03:22 +0200
"Chen, Tiejun" <Tiejun.Chen@windriver.com> wrote:
> > -----Original Message-----
> > From: Shawn Jin [mailto:shawnxjin@gmail.com]
> > Sent: Tuesday, September 21, 2010 1:53 AM
> > To: Chen, Tiejun
> > Cc: ppcdev; uboot
> > Subject: Re: cuImage and multi image?
> >
> > >> I have a cuImage kernel in order to support legacy u-boot and a
> > >> ramdisk image. Kernel boots fine if these two images are
> > separate and
> > >> "bootm $kernel $ramdisk" is used. But I can not make it to
> > work using
> > >> a single multi image that contains the kernel and ramdisk
> > images. Is
> > >> it even technically possible to boot a multi-image with cuboot
> > >> wrapper?
> > >
> > > Try the following steps:
> > > ------
> > > 1. cp <your ramdisk.gz> arch/powerpc/boot/ramdisk.image.gz
> > > 2. make cuImage.initrd.<your target>
> > >
> > > You can get one Image, cuImage.initrd.<your target>,
> > including kernel and ramdisk.
> >
> > A follow up question. With this method, the total image size
> > (uncompressed) is limited to the 4MB (the link address of the
> > boot wrapper)?
>
> No.
Yes, unless you change the link address, or provide a vmlinux_alloc
callback (which currently only happens on true OF, not cuImage).
Unless you're talking about the "(uncompressed)"? The limit applies to
the uncompressed boot image -- anything that the bootwrapper itself is
decompressing. It does not apply to any further uncompression of the
ramdisk itself.
-Scott
^ permalink raw reply
* Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
From: Kyle Moffett @ 2010-09-21 20:47 UTC (permalink / raw)
To: John Stultz
Cc: Rodolfo Giometti, Arnd Bergmann, netdev, devicetree-discuss,
linux-kernel, linuxppc-dev, Richard Cochran, linux-arm-kernel,
Krzysztof Halasa
In-Reply-To: <1282948239.2268.155.camel@jstultz-laptop>
On Fri, Aug 27, 2010 at 18:30, John Stultz <johnstul@us.ibm.com> wrote:
> On one side, there is the view that the kernel should abstract and hide
> the hardware details to increase app portability. And the other is that
> the raw hardware details should be exposed, so the OS stays out of the
> way.
>
> Neither of these views are always right. Ideally we can come up with a
> abstracted way to provide the hardware data needed that's generic enough
> that applications don't have to be changed when moving between hardware
> or configurations.
>
> The posix clock id interface is frustrating because the flat static
> enumeration is really limiting.
>
> I wonder if a dynamic enumeration for posix clocks would be possibly a
> way to go?
Well how about something much more straightforward:
#define CLOCK_FD 0x80000000
fd = open("/dev/clocks/some_clock_name", O_RDONLY);
clock_gettime(CLOCK_FD | fd, &ts);
This would provide all of the standard character-device semantics that
everyone is accustomed to, and furthermore you could allow non-root
users to manage specific clocks using just DAC permission bits.
You'd still probably need to add a clock_adjtimex() syscall, but it
could easily fail with EINVAL for software or per-thread clocks, but
that seems like it would nicely abstract the hardware without forcing
a numeric address space.
Cheers,
Kyle Moffett
^ permalink raw reply
* Re: [PATCH] fsldma: add support to 36-bit physical address
From: Timur Tabi @ 2010-09-21 21:24 UTC (permalink / raw)
To: Kumar Gala; +Cc: dan.j.williams, linuxppc-dev, linux-kernel
In-Reply-To: <877FD0B5-19A7-4A16-831E-369B80B104EA@kernel.crashing.org>
On Tue, Sep 21, 2010 at 7:55 AM, Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Sep 21, 2010, at 5:57 AM, Li Yang wrote:
>
>> Signed-off-by: Li Yang <leoli@freescale.com>
>> ---
>
> We really should have a sentence about how or why this works to address 36-bit addressing.
For example, I would like to know which memory is going to be
allocated above 4GB. I don't know much about the kernel's async
library, but my understanding is that fsldma does not allocate any of
the memory buffers that it copies data to/from. The only memory that
fsldma allocates is for the DMA descriptors, which are very small and
probably don't take up more than a couple pages.
--
Timur Tabi
Linux kernel developer at Freescale
^ 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