* 2.6.25: include/asm-ppc vs. include/asm-powerpc
From: Paul Smith @ 2008-08-28 13:07 UTC (permalink / raw)
To: linuxppc-embedded
I know that arch/ppc is obsolete in 2.6.26 and deprecated for earlier
releases. However, I have a port to a custom PPC-based board that was
originally done for 2.6.14 in arch/ppc, and I've ported it to our
current "standard" kernel of 26.25 and it works (anyway it boots etc.)
I absolutely do not have time now, and not for a few months, to convert
over to live in arch/powerpc (BTW, if anyone has any pointers to docs on
ways to make that transition I'm very interested).
My problem is this: I'm having trouble building some of our externel
kernel modules because they can't find various kernel header files.
Looking at the kernel's include directory I see that include/asm is
symlinked to include/asm-ppc which is what I would expect for ARCH=ppc,
and the same way it used to work in 2.6.14.
However, looking in the include/asm-ppc directory I see that many of the
files that used to be there are not there anymore... although they do
appear in include/asm-powerpc. In particular I'm interested in
ppc_asm.h which used to exist in both asm-ppc64 AND in asm-ppc, but now
only exists in asm-powerpc. What's the approved way to include this
header if asm points to asm-ppc?
In general it seems like lots of headers that used to be in both asm
directories now appear in only asm-powerpc; I don't really see how this
is supposed to work. Any tips on this would be most welcome.
Thanks!
^ permalink raw reply
* Re: [PATCH] ppc4xx_pci: necessary fixes for 4GB RAM size
From: Josh Boyer @ 2008-08-28 13:28 UTC (permalink / raw)
To: Ilya Yanok, benh; +Cc: linuxppc-dev, sr, wd, Ilya Yanok
In-Reply-To: <1219391015-6317-1-git-send-email-yanok@emcraft.com>
On Fri, 22 Aug 2008 11:43:35 +0400
Ilya Yanok <yanok@emcraft.com> wrote:
> 1. total_memory should be phys_addr_t not unsigned long
> 2. is_power_of_2() works with u32 so I just inlined (size & (size-1)) != 0
> instead.
> Also this patch fixes default initialization: res->end should be 0x7fffffff
> not 0x80000000.
>
> Signed-off-by: Ilya Yanok <yanok@emcraft.com>
Ben, any comments here? Looks right to me.
josh
> ---
> arch/powerpc/sysdev/ppc4xx_pci.c | 11 ++++++-----
> 1 files changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/arch/powerpc/sysdev/ppc4xx_pci.c b/arch/powerpc/sysdev/ppc4xx_pci.c
> index e1c7df9..645b2c9 100644
> --- a/arch/powerpc/sysdev/ppc4xx_pci.c
> +++ b/arch/powerpc/sysdev/ppc4xx_pci.c
> @@ -36,7 +36,7 @@
> static int dma_offset_set;
>
> /* Move that to a useable header */
> -extern unsigned long total_memory;
> +extern phys_addr_t total_memory;
>
> #define U64_TO_U32_LOW(val) ((u32)((val) & 0x00000000ffffffffULL))
> #define U64_TO_U32_HIGH(val) ((u32)((val) >> 32))
> @@ -105,7 +105,8 @@ static int __init ppc4xx_parse_dma_ranges(struct pci_controller *hose,
>
> /* Default */
> res->start = 0;
> - res->end = size = 0x80000000;
> + size = 0x80000000;
> + res->end = size - 1;
> res->flags = IORESOURCE_MEM | IORESOURCE_PREFETCH;
>
> /* Get dma-ranges property */
> @@ -167,13 +168,13 @@ static int __init ppc4xx_parse_dma_ranges(struct pci_controller *hose,
> */
> if (size < total_memory) {
> printk(KERN_ERR "%s: dma-ranges too small "
> - "(size=%llx total_memory=%lx)\n",
> - hose->dn->full_name, size, total_memory);
> + "(size=%llx total_memory=%llx)\n",
> + hose->dn->full_name, size, (u64)total_memory);
> return -ENXIO;
> }
>
> /* Check we are a power of 2 size and that base is a multiple of size*/
> - if (!is_power_of_2(size) ||
> + if ((size & (size - 1)) != 0 ||
> (res->start & (size - 1)) != 0) {
> printk(KERN_ERR "%s: dma-ranges unaligned\n",
> hose->dn->full_name);
^ permalink raw reply
* Re: 2.6.25: include/asm-ppc vs. include/asm-powerpc
From: Arnd Bergmann @ 2008-08-28 13:53 UTC (permalink / raw)
To: linuxppc-embedded, paul
In-Reply-To: <1219928864.16802.69.camel@homebase.localnet>
On Thursday 28 August 2008, Paul Smith wrote:
> However, looking in the include/asm-ppc directory I see that many of the
> files that used to be there are not there anymore... although they do
> appear in include/asm-powerpc. =A0In particular I'm interested in
> ppc_asm.h which used to exist in both asm-ppc64 AND in asm-ppc, but now
> only exists in asm-powerpc. =A0What's the approved way to include this
> header if asm points to asm-ppc?
>=20
> In general it seems like lots of headers that used to be in both asm
> directories now appear in only asm-powerpc; I don't really see how this
> is supposed to work. =A0Any tips on this would be most welcome.
>=20
The easiest solution should be to just include all your modules in
the kernel source as patches, rather than building them externally.
That will give you access to all the headers you need.
Of course that is only possible if all your modules are GPL, but I
assume that you would not have asked here if they were not.
Arnd <><
^ permalink raw reply
* Re: 2.6.25: include/asm-ppc vs. include/asm-powerpc
From: Darcy Watkins @ 2008-08-28 13:56 UTC (permalink / raw)
To: paul; +Cc: linuxppc-embedded
In-Reply-To: <1219928864.16802.69.camel@homebase.localnet>
Hi Paul,
A hack we did when building a ported WiMax driver against 2.6.19 was to
merge the two asm-p.*pc directories.
Below is a snippet from one of our build scripts that does this.
Assuming KERNEL_SRC_PATH is set to point to your kernel source...
#------------------
if [ ! -d $KERNEL_SRC_PATH/include/asm-ppc-merged ]; then
echo "Creating a merged include/asm for arch/ppc and arch/powerpc"
mkdir $KERNEL_SRC_PATH/include/asm-ppc-merged
cp -r $KERNEL_SRC_PATH/include/asm-powerpc/* $KERNEL_SRC_PATH/include/asm-ppc-merged
cp -r $KERNEL_SRC_PATH/include/asm-ppc/* $KERNEL_SRC_PATH/include/asm-ppc-merged
fi
echo "Symlinking the merged include/asm"
cd $KERNEL_SRC_PATH/include
rm asm
ln -s asm-ppc-merged asm
#------------------
Based on this order, files from arch/ppc win but missing files will come
from arch/powerpc.
You could try it out. Mileage may vary, especially newer than 2.6.23
since there may be device tree dependent stuff that gets into the merged
directory. We stopped using this hack for kernel 2.6.23 and newer since
we migrated to arch/powerpc for 2.6.23 and later (presently using
2.6.25) so I really don't know whether or not it will work for you.
If you use the symlinked shadow source tree facility of the Xenomai
build with your kernel, then use "-rs" instead of "-r" in the "cp"'s
above. Otherwise just use "-r" as shown above.
Regards,
Darcy
On Thu, 2008-08-28 at 06:07 -0700, Paul Smith wrote:
--snip!--
> In general it seems like lots of headers that used to be in both asm
> directories now appear in only asm-powerpc; I don't really see how
> this
> is supposed to work. Any tips on this would be most welcome.
--snip!--
--
Regards,
Darcy
--------------
Darcy L. Watkins - Senior Software Developer
Tranzeo Wireless Technologies, Inc.
19273 Fraser Way, Pitt Meadows, BC, Canada V3Y 2V4
T:604-460-6002 ext:410
http://www.tranzeo.com
^ permalink raw reply
* Re: [PATCH] ppc4xx_pci: necessary fixes for 4GB RAM size
From: Stefan Roese @ 2008-08-28 14:18 UTC (permalink / raw)
To: linuxppc-dev; +Cc: wd, Ilya Yanok
In-Reply-To: <20080828092820.2cacaba7@zod.rchland.ibm.com>
On Thursday 28 August 2008, Josh Boyer wrote:
> > 1. total_memory should be phys_addr_t not unsigned long
> > 2. is_power_of_2() works with u32 so I just inlined (size & (size-1)) !=
> > 0 instead.
> > Also this patch fixes default initialization: res->end should be
> > 0x7fffffff not 0x80000000.
> >
> > Signed-off-by: Ilya Yanok <yanok@emcraft.com>
>
> Ben, any comments here? Looks right to me.
Looks good to me too. So:
Acked-by: Stefan Roese <sr@denx.de>
Best regards,
Stefan
^ permalink raw reply
* Re: [BUG] linux-next: Tree for August 26 - Badness at kernel/notifier.c:25
From: David Woodhouse @ 2008-08-28 14:23 UTC (permalink / raw)
To: Stephen Rothwell
Cc: LKML, Kamalesh Babulal, linuxppc-dev, linux-next, mingo,
Arjan van de Ven
In-Reply-To: <20080828003821.d29d2a03.sfr@canb.auug.org.au>
On Thu, 2008-08-28 at 00:38 +1000, Stephen Rothwell wrote:
> Hi Arjan,
>
> On Thu, 28 Aug 2008 00:33:08 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > The original reported trace was during setup_system which is very early in
> > the boot.
>
> But, of course, that version didn't have the necessary extra dereference
> of the function address ...
>
> And the later debug patch did not check the address at register time,
> only at notify time.
>
> The later trace also looks to be early in the boot.
It's isa_bridge_notify(), which is neither within _[se]text nor
_[se]inittext, so the core_kernel_text() function disavows it.
Where are __devinit functions supposed to end up?
$ egrep _[es]init\|_[es]text\|isa_bridge_notify System.map
c000000000000000 T _stext
c00000000045d000 T _etext
c000000000463ca8 t .isa_bridge_notify
c00000000063a000 T _sinittext
c00000000067c3bc T _einittext
c00000000071fd80 d isa_bridge_notify
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation
^ permalink raw reply
* Re: 2.6.25: include/asm-ppc vs. include/asm-powerpc
From: Paul Smith @ 2008-08-28 14:30 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-embedded
In-Reply-To: <200808281553.18167.arnd@arndb.de>
On Thu, 2008-08-28 at 15:53 +0200, Arnd Bergmann wrote:
> The easiest solution should be to just include all your modules in
> the kernel source as patches, rather than building them externally.
>
> That will give you access to all the headers you need.
It doesn't matter whether I build my code in the kernel as patches, or
not. The problem is not that I don't have the headers handy, it's that
they simply don't exist in asm-ppc anymore, not even in the linux source
tree.
There is no asm-ppc/ppc_asm.h in the kernel anymore. In my code that
includes it, where ARCH=ppc and include/asm is linked to asm-ppc, how do
I get ahold of that file? I can't use #include <asm/ppc_asm.h> like I
used to. Do I have to use #include <asm-powerpc/ppc_asm.h> explicitly?
At least this will work... but read on:
Even more troublesome are headers like <linux/posix_types.h>, which
includes <asm/posix_types.h>, but there IS NO asm-ppc/posix_types.h file
in the kernel tree! There is only an asm-powerpc/posix_types.h... but
if asm is a link to asm-ppc, this fails and I have no way to fix it!
On the other hand, if I cheat and set the asm symlink pointing to
asm-powerpc instead, then when I include files like <linux/interrupt.h>.
which includes <linux/hardirq.h>, which includes <asm/hardirq.h>, which
(because I have CONFIG_40X defined) includes <asm/ibm44x.h>, I get the
opposite problem: there is no asm-powerpc/ibm4xx.h; that header exists
only in the asm-ppc directory. So now THAT include fails.
I seem to be out of luck here.
^ permalink raw reply
* Re: 2.6.25: include/asm-ppc vs. include/asm-powerpc
From: Josh Boyer @ 2008-08-28 14:38 UTC (permalink / raw)
To: Paul Smith; +Cc: Arnd Bergmann, linuxppc-embedded
In-Reply-To: <1219933848.16802.96.camel@homebase.localnet>
On Thu, Aug 28, 2008 at 10:30:48AM -0400, Paul Smith wrote:
>On Thu, 2008-08-28 at 15:53 +0200, Arnd Bergmann wrote:
>> The easiest solution should be to just include all your modules in
>> the kernel source as patches, rather than building them externally.
>>
>> That will give you access to all the headers you need.
>
>It doesn't matter whether I build my code in the kernel as patches, or
>not. The problem is not that I don't have the headers handy, it's that
>they simply don't exist in asm-ppc anymore, not even in the linux source
>tree.
Then you need to adapt your code to where ever that information moved
to? Maybe if you post your driver code and makefile we can help you
out.
>There is no asm-ppc/ppc_asm.h in the kernel anymore. In my code that
>includes it, where ARCH=ppc and include/asm is linked to asm-ppc, how do
>I get ahold of that file? I can't use #include <asm/ppc_asm.h> like I
>used to. Do I have to use #include <asm-powerpc/ppc_asm.h> explicitly?
>At least this will work... but read on:
>
>Even more troublesome are headers like <linux/posix_types.h>, which
>includes <asm/posix_types.h>, but there IS NO asm-ppc/posix_types.h file
>in the kernel tree! There is only an asm-powerpc/posix_types.h... but
>if asm is a link to asm-ppc, this fails and I have no way to fix it!
>
>On the other hand, if I cheat and set the asm symlink pointing to
>asm-powerpc instead, then when I include files like <linux/interrupt.h>.
>which includes <linux/hardirq.h>, which includes <asm/hardirq.h>, which
>(because I have CONFIG_40X defined) includes <asm/ibm44x.h>, I get the
>opposite problem: there is no asm-powerpc/ibm4xx.h; that header exists
>only in the asm-ppc directory. So now THAT include fails.
This is all confusing to me. Things obviously work in-kernel, or it
wouldn't build at all. There used to be a hack in the ppc makefiles to
add a -Iasm-powerpc (or a symlink or something) so that files _would_ find
the right headers. Look harder at the makefiles and try to duplicate that
for your external modules.
Or move to the latest git kernel, where this problem doesn't exist at all
since arch/ppc is removed entirely :).
josh
^ permalink raw reply
* Re: 2.6.25: include/asm-ppc vs. include/asm-powerpc
From: Arnd Bergmann @ 2008-08-28 14:42 UTC (permalink / raw)
To: linuxppc-embedded, paul
In-Reply-To: <1219933848.16802.96.camel@homebase.localnet>
On Thursday 28 August 2008, Paul Smith wrote:
> On Thu, 2008-08-28 at 15:53 +0200, Arnd Bergmann wrote:
> > The easiest solution should be to just include all your modules in
> > the kernel source as patches, rather than building them externally.
> >
> > That will give you access to all the headers you need.
>
> It doesn't matter whether I build my code in the kernel as patches, or
> not. The problem is not that I don't have the headers handy, it's that
> they simply don't exist in asm-ppc anymore, not even in the linux source
> tree.
The trick that arch/ppc uses is to create a symlink arch/ppc/include/asm
pointing to include/asm-powerpc and then passing "-Iinclude
-Iarch/ppc/include" to the compiler. This will make gcc look for
headers in asm-ppc first, and then in asm-powerpc.
It should also work with external modules if you build them in the
recommended way (see http://lwn.net/Articles/80250/), but as I said,
the easiest way is to just build all modules as part of the regular
kernel build. It should be evident that building kernel code actually
works and gets the right header files for all existing modules, so
it should work just like that for any drivers you add to the kernel.
Arnd <><
^ permalink raw reply
* Re: 2.6.25: include/asm-ppc vs. include/asm-powerpc
From: Roland Dreier @ 2008-08-28 14:48 UTC (permalink / raw)
To: paul; +Cc: Arnd Bergmann, linuxppc-embedded
In-Reply-To: <1219933848.16802.96.camel@homebase.localnet>
> It doesn't matter whether I build my code in the kernel as patches, or
> not. The problem is not that I don't have the headers handy, it's that
> they simply don't exist in asm-ppc anymore, not even in the linux source
> tree.
I believe that the kernel's build system (before arch/ppc was removed
entirely) had some magic to include files from asm-powerpc if they
didn't exist in asm-ppc. So building your code with the kernel's build
system (and Documentation/kbuild/modules.txt explains how to do that
even without building in the kernel tree itself) should work.
For example, the reason include/asm-ppc/ppc_asm.h doesn't exist is
because of commit 5f7c6907, which moved the file to asm-powerpc.
- R.
^ permalink raw reply
* Re: [BUG] linux-next: Tree for August 26 - Badness at kernel/notifier.c:25
From: David Woodhouse @ 2008-08-28 14:55 UTC (permalink / raw)
To: Stephen Rothwell
Cc: LKML, Kamalesh Babulal, linuxppc-dev, linux-next, mingo,
Arjan van de Ven
In-Reply-To: <1219933410.7107.296.camel@pmac.infradead.org>
On Thu, 2008-08-28 at 15:23 +0100, David Woodhouse wrote:
> On Thu, 2008-08-28 at 00:38 +1000, Stephen Rothwell wrote:
> > Hi Arjan,
> >
> > On Thu, 28 Aug 2008 00:33:08 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > >
> > > The original reported trace was during setup_system which is very early in
> > > the boot.
> >
> > But, of course, that version didn't have the necessary extra dereference
> > of the function address ...
> >
> > And the later debug patch did not check the address at register time,
> > only at notify time.
> >
> > The later trace also looks to be early in the boot.
>
> It's isa_bridge_notify(), which is neither within _[se]text nor
> _[se]inittext, so the core_kernel_text() function disavows it.
>
> Where are __devinit functions supposed to end up?
The TEXT_TEXT macro defined in <asm-generic/vmlinux.lds.h> should get
this right... but we don't use it. Is there any particular reason for
that, or should we....
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
--- linux-2.6.26.ppc64/arch/powerpc/kernel/vmlinux.lds.S~ 2008-07-13 22:51:29.000000000 +0100
+++ linux-2.6.26.ppc64/arch/powerpc/kernel/vmlinux.lds.S 2008-08-28 15:39:14.000000000 +0100
@@ -35,10 +35,11 @@ SECTIONS
ALIGN_FUNCTION();
*(.text.head)
_text = .;
- *(.text .fixup .text.init.refok .exit.text.refok)
+ TEXT_TEXT
SCHED_TEXT
LOCK_TEXT
KPROBES_TEXT
+ *(.fixup)
#ifdef CONFIG_PPC32
*(.got1)
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation
^ permalink raw reply
* Re: [PATCH] usb: add Freescale QE/CPM USB peripheral controller driver
From: Arnd Bergmann @ 2008-08-28 15:04 UTC (permalink / raw)
To: linuxppc-dev; +Cc: greg, Li Yang, linux-usb, dbrownell, linux-kernel
In-Reply-To: <1219916613-28827-1-git-send-email-leoli@freescale.com>
On Thursday 28 August 2008, Li Yang wrote:
> Some of Freescale SoC chips have a QE or CPM co-processor which
> supports full speed USB. The driver adds device mode support
> of both QE and CPM USB controller to Linux USB gadget. The
> driver is tested with MPC8360 and MPC8272, and should work with
> other models having QE/CPM given minor tweaks.
Looks pretty good, just a few comments on the driver:
> +config USB_GADGET_FSL_QE
> + boolean "Freescale QE/CPM USB Device Controller"
> + depends on FSL_SOC && (QUICC_ENGINE || CPM)
> + help
> + Some of Freescale PowerPC processors have a Full Speed
> + QE/CPM2 USB controller, which support device mode with 4
> + programmable endpoints. This driver supports the
> + controller in the MPC8360 and MPC8272, and should work with
> + controllers having QE or CPM2, given minor tweaks.
> +
> + Say "y" to link the driver statically, or "m" to build a
> + dynamically linked module called "fsl_qe_udc" and force all
> + gadget drivers to also be dynamically linked.
> +
> +config USB_FSL_QE
> + tristate
> + depends on USB_GADGET_FSL_QE
> + default USB_GADGET
> + select USB_GADGET_SELECTED
Why do you need the two config options, not just one?
> +#ifdef CONFIG_CPM2
> +#include <asm/cpm.h>
> +
> +#define qe_muram_addr cpm_muram_addr
> +#define qe_muram_offset cpm_muram_offset
> +#define qe_muram_alloc cpm_muram_alloc
> +#define qe_muram_free cpm_muram_free
> +#endif
...
> +static int qe_ep_cmd_restarttx(struct qe_ep *ep)
> +{
> + u8 ep_num;
> +#ifdef CONFIG_CPM2
> + u32 command;
> + u8 opcode;
> +
> + ep_num = ep->epnum << CPM_USB_EP_SHIFT;
> + command = CPM_USB_RESTART_TX | (u32)ep_num;
> + opcode = CPM_USB_RESTART_TX_OPCODE;
> + cpm_command(command, opcode);
> +#else
> + ep_num = ep->epnum;
> + qe_issue_cmd(QE_USB_RESTART_TX, QE_CR_SUBBLOCK_USB, ep_num, 0);
> +#endif
> + return 0;
> +}
This part doesn't look good, you should try to avoid hardcoding
the specific type of chip (QE or CPM2) here. AFAICT, you can build
a multiplatform kernel that supports both QE and CPM2, but your code
here would be broken in that case if you try to run it on QE.
> +static void setup_received_handle(struct qe_udc *udc,
> + struct usb_ctrlrequest *setup);
> +static int qe_ep_rxframe_handle(struct qe_ep *ep);
> +static void ep0_req_complete(struct qe_udc *udc, struct qe_req *req);
Better try to avoid static forward declarations by reordering your
functions in call order. That is the common coding style and makes
drivers easier to read when you're used to it.
> +
> + tasklet_schedule(&udc->rx_tasklet);
Not a problem, but an observation: Most new code uses work queues instead
of tasklets these days, which gives you more predictable real time
latencies.
If you don't have a specific reason to prefer a tasklet, just use
a workqueue here.
> +/*-------------------------------------------------------------------------
> + Gadget driver register and unregister.
> + --------------------------------------------------------------------------*/
> +int usb_gadget_register_driver(struct usb_gadget_driver *driver)
> +EXPORT_SYMBOL(usb_gadget_register_driver);
> +
> +int usb_gadget_unregister_driver(struct usb_gadget_driver *driver)
> +EXPORT_SYMBOL(usb_gadget_unregister_driver);
Not addressing this driver in particular, but the USB gadget layer in
general: This is a horrible interface, since every gadget driver exports
the same symbols, you can never build a kernel that includes more than
one gadget driver. Even if the drivers are all built as modules, simply
loading one of them prevents loading another one.
> + udc->dev = &ofdev->dev;
> +
> + /* use the default address for the usb parameter */
> + prop = of_get_property(np, "reg", &nsize);
> + offset = of_read_number(prop + 2, 1);
> + size = of_read_number(prop + 3, 1);
You should not assume a specific layout of the reg property but
rather use the simpler of_iomap function to get the registers,
independent of the bus mapping.
> +/*-------------------------------------------------------------------------*/
> +static struct of_device_id qe_udc_match[] = {
> + {
> + .compatible = "fsl,mpc8360-qe-usb",
> + },
> + {
> + .compatible = "fsl,mpc8272-cpm-usb",
> + },
> + {},
> +};
Since they are evidently different implementations, you should
fill out the data field in the device id as the easiest way
to identify the two (and possible future) versions of the hardware.
> +#ifdef DEBUG
> +#define VDBG(fmt, args...) printk(KERN_DEBUG "[%s] " fmt "\n", \
> + __func__, ## args)
> +#else
> +#define VDBG(fmt, args...) do {} while (0)
> +#endif
please use the standard dev_debug and pr_debug macros instead of defining
your own.
Arnd <><
^ permalink raw reply
* GPIO interrupt on AMCC 460EX
From: Felix Radensky @ 2008-08-28 14:11 UTC (permalink / raw)
To: linuxppc-embedded, Stefan Roese
Hi,
I'm writing a Linux driver for CPLD access on custom
460EX based board. CPLD generates interrupt, which
is connected to GPIO pin 45. According to 460EX user
manual, this pin, if configured as alternate function 3,
will generate external interrupt 12, which is mapped into
irq 20 on UIC3. My question is - how do I get irq number
suitable for passing to request_irq().
Thanks a lot.
Felix Radensky
Embedded Solutions Ltd.
http://www.embedded-sol.com
^ permalink raw reply
* Re: Why does one "stw" fail with address translation disabled in PPC405EP?
From: Zhou Rui @ 2008-08-28 15:53 UTC (permalink / raw)
To: Linuxppc-dev
In-Reply-To: <1219691805.6735.63.camel@zr.gii.upv.es>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=UTF-8, Size: 6349 bytes --]
Hi, all:
Well, as described before, the problem happens at "0xc0000434
<InstructionAccess+52>: stw r12,64(r11)". At this moment,
address translation is disabled and physical addresses are used, but r11
contains 0x03072da0 which is a physical address out of the range of 0x0
and 0x01ffffff. I check backward and see that value of r11 is from r1 by
tophys(r11,r1). r1 should hold the stack pointer, whose value is in the
form of 0xc3xxxxxx when the problem happens.
In this project, we make use of the concept of domain for high level
OSes above XtratuM kernel. Here Linux is the root domain and the problem
happens when we tries to load and transfer to a testing domain which
just prints some sentences, and 0x100000a0 is the entry point of the
testing domain, so we need to execute this address. We define a struct
domain_t for the domain and the stack pointer is achieved by:
....
d->sstack_st = vmalloc (DEFAULT_SSTACK_SIZE); /* DEFAULT_SSTACK_SIZE
is 0x1000 */
if (!d->sstack_st) {
destroy_domain (d);
id = -OUT_OF_MEMORY;
goto exit_load_domain;
}
d->sstack = (unsigned long *)((unsigned long)d->sstack_st +
DEFAULT_SSTACK_SIZE); /* sstack is the new domain's stack pointer that
will be moved to r1 */
After doing this, sstack will get the value of 0xc3xxxxxx.
Shouln't I use vmalloc here? Or are there any other solution?
Thanks in advance for any advice!
Best Wishes
Zhou Rui
2008-08-28
在 2008-08-25一的 21:16 +0200，Zhou Rui写é“：
> Hi,
> I think maybe you have known this project named XtratuM
> (http://www.xtratum.org). I'm porting it from x86 to PPC405. The
> implementation on PPC440 has been basically finished
> (ftp://dslab.lzu.edu.cn/pub/xtratum/xtratum-ppc/snapshots/xtratum-ppc-20071205.tar.bz2) and I know there was discussion about it in this mail list before. XtratuM is an ADEOS based nano kernel. It aims for realtime and is designed to provide virtual timer, virtual interrupt and memory space sperations for domains. Each domain is loaded by a userspace program (instead of the root domain as a kernel module) and the loader will load the domain's (ELF staticly excutable) PT_LOAD section into memory, and then raise a properly system call (passing the structurized loaded data as arguments) to load the domain via load_domain_sys() of XtratuM, and at the last step of loading the domain, xtratum will jump to the entry code of the new domain(asm wrappered start() routine) and then everything should be fine. 0x100000a0 is the entry point of the test domain, and that is why I need to start execution from it.
>
> I think I can say something of my analysis so far for the cause of my
> problem. Thanks for the mention of memory size. Once the kernel module
> of XtratuM is loaded, the symbols of it are placed to virtual addresses
> like 0xc3xxxxxx. Because in normal state, address translation is enabled
> (MSR[IR, DR] = [1, 1]), these addresses are okay. However, when loading
> the domain, because the entry point 0x100000a0 is not in TLB and it
> should be reloaded, Data TLB Miss Exception arises and DTLBMiss is
> called. The exception clears MSR[IR, DR], so address translation is
> disabled and physical address should be used at this moment. If we want
> something at the virtual address of 0xc3xxxxxx, we must access the
> physical addresses like 0x03xxxxxx. Nevertheless, the limitation of 32MB
> memory makes the valid physical address range from 0x0 to 0x1ffffff.
> Therefore, during the exception handling, the addresses out of range
> should not be accessed, but the instructions cannot know the memory
> limitation in advance and tries to do something in addresses such as
> 0x03072da0 based on the address translation mechanism, which leads to
> machine check.
> I haved tried to append "mem=32M" to kernel command line but no help. I
> think it is because when loading the kernel in normal state, address
> translation is enabled and the virtual addresses are okay. Kernel cannot
> foresee that there is going to be a TLB miss exception and the illegal
> physical addresses like 0x03xxxxxx may be accessed.
>
> So any ideas for this problem are welcome.
>
> Thank you very much for taking care.
>
> Best Wishes
>
> Zhou Rui
> 2008-08-25
>
> 在 2008-08-24日的 20:55 +0200，Wolfgang Denk写é“：
> > Dear Zhou Rui,
> >
> > In message <1219479992.7565.17.camel@localhost> you wrote:
> > >
> > > > > I am running a kernel module which will execute a user space
> > > > >application. The entry point of the application is 0x100000a0. At the
> > > >
> > > > That should be the first clue that you are doing it wrong. Don't do
> > > > stuff like that in modules...
> > >
> > > Oh, but our project needs a function like that ...
> >
> > You should really think about this. Why do you think you need this?
> > What exactly are you trying to do? [Probably there are better
> > approaches to solve your problem...]
>
> > > It is physical address at this moment. Address translation is disabled
> > > automatically (MSR[IR, DR] = [0, 0]) because of TLB Miss Exception and
> > > Instrunction Storage Exception.
> >
> > Hm.. are you absolutely sure that the 0x100000a0 mentioned above is a
> > physical address?
> >
> > > > Do you have enough DRAM to cover that? Some of those boards only come
> > > > with 32MiB of DRAM.
> > >
> > > My board only has 32MB DRAM. Do you mean 32MB is not enough for that?
> >
> > Well, 0x1000'00A0 is above 256 MB, while you have only 32 MB RAM
> > which is most probably mapped from 0x0000'0000...0x01FF'FFFF... So
> > what you claim to be a physical address (and I think your claim is
> > wrong) is far outside available physical memory.
> >
> > > The same codes can run well in a PPC440EP (Yosemite Board) which owns
> > > 256MB DRAM. At the beginning of my work, I thought memory size may be
> > > the cause of failure. But I did not know how to demonstrate it. So if
> > > the limitation of 32MB DRAM leads to the failure, are there any methods
> > > for the codes to solve it?
> >
> > I think you got lost on the wrong track. Please describe which task
> > you want to implement, and there might be another, better approach
> > for it.
> >
> > Best regards,
> >
> > Wolfgang Denk
__________________________________________________
¸Ï¿ì×¢²áÑÅ»¢³¬´óÈÝÁ¿Ãâ·ÑÓÊÏä?
http://cn.mail.yahoo.com
^ permalink raw reply
* Re: GPIO interrupt on AMCC 460EX
From: Stefan Roese @ 2008-08-28 15:20 UTC (permalink / raw)
To: Felix Radensky; +Cc: linuxppc-embedded
In-Reply-To: <48B6B201.2070101@embedded-sol.com>
Felix,
On Thursday 28 August 2008, Felix Radensky wrote:
> I'm writing a Linux driver for CPLD access on custom
> 460EX based board. CPLD generates interrupt, which
> is connected to GPIO pin 45. According to 460EX user
> manual, this pin, if configured as alternate function 3,
> will generate external interrupt 12, which is mapped into
> irq 20 on UIC3. My question is - how do I get irq number
> suitable for passing to request_irq().
arch/powerpc now used virtual interrupts. You need to include this hardware
interrupt number into your device-tree (create a new node for your CPLD) and
extract the virtual irq number from there by calling irq_of_parse_and_map().
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH v2] POWERPC: Allow 32-bit pgtable code to support 36-bit physical
From: Becky Bruce @ 2008-08-28 15:36 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <48B5E6B7.3000903@freescale.com>
On Aug 27, 2008, at 6:43 PM, Scott Wood wrote:
> Becky Bruce wrote:
>> #if _PAGE_HASHPTE != 0
>> +#ifndef CONFIG_PTE_64BIT
>> pte_update(ptep, ~_PAGE_HASHPTE, pte_val(pte) & ~_PAGE_HASHPTE);
>> #else
>> + /*
>> + * We have to do the write of the 64b pte as 2 stores. This
>> + * code assumes that the entry we're storing to is currently
>> + * not valid and that all callers have the page table lock.
>> + * Having the entry be not valid protects readers who might read
>> + * between the first and second stores.
>> + */
>> + unsigned int tmp;
>> +
>> + __asm__ __volatile__("\
>> +1: lwarx %0,0,%4\n\
>> + rlwimi %L2,%0,0,30,30\n\
>> + stw %2,0(%3)\n\
>> + eieio\n\
>> + stwcx. %L2,0,%4\n\
>> + bne- 1b"
>> + : "=&r" (tmp), "=m" (*ptep)
>> + : "r" (pte), "r" (ptep), "r" ((unsigned long)(ptep) + 4),
>> "m" (*ptep)
>> + : "cc");
>> +#endif /* CONFIG_PTE_64BIT */
>
> Could the stw to the same reservation granule as the stwcx cancel
> the reservation on some implementations? P
Not on the same processor.
> lus, if you're assuming that the entry is currently invalid and all
> callers have the page table lock, do we need the lwarx/stwcx at
> all? At the least, it should check PTE_ATOMIC_UPDATES.
I'm pretty sure I went through this in great detail at one point and
concluded that I did in fact need the lwarx/stwcx. IIRC, it has to do
with other non-set_pte_at writers not necessarily holding the page
table lock. FYI, the existing 32-bit PTE code is doing atomic updates
as well.
About PTE_ATOMIC_UPDATES, I didn't add that in because hashed page
table implementations require atomic updates. Adding it in would
create another clause in that code, because I would still need to
order the operations with a 64-bit PTE and I can't call pte_update as
it only changes the low word of the pte. I wasn't feeling too keen
on adding untested pagetable code into the kernel :) I can add it if
the peanut gallery wants it, but I'll be marking it with a big fat
"BUYER BEWARE".
>
>
> %2 should be "+&r", not "r".
>
>> diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/
>> platforms/Kconfig.cputype
>> index 7f65127..ca5b58b 100644
>> --- a/arch/powerpc/platforms/Kconfig.cputype
>> +++ b/arch/powerpc/platforms/Kconfig.cputype
>> @@ -128,18 +128,22 @@ config FSL_EMB_PERFMON
>> config PTE_64BIT
>> bool
>> - depends on 44x || E500
>> + depends on 44x || E500 || 6xx
>> default y if 44x
>> - default y if E500 && PHYS_64BIT
>> + default y if PHYS_64BIT
>
> How is this different from PHYS_64BIT?
One is the width of the PTE and one is the width of a physical
address. It's entirely plausible to have a 64-bit PTE because you
have a bunch of status bits, and only have 32-bit physical
addressing. That's why there are 2 options.
>
>
>> config PHYS_64BIT
>> - bool 'Large physical address support' if E500
>> - depends on 44x || E500
>> + bool 'Large physical address support' if E500 || 6xx
>
> Maybe "if !44x", or have 44x "select" this, rather than listing all
> arches where it's optional.
Not sure exactly what you're suggesting here........
>
>
>> + depends on 44x || E500 || 6xx
>> select RESOURCES_64BIT
>> default y if 44x
>> ---help---
>> This option enables kernel support for larger than 32-bit physical
>> - addresses. This features is not be available on all e500 cores.
>> + addresses. This features is not be available on all cores.
>
> "This features is not be"?
Heh, I didn't type that :) But I can fix it.
Thanks,
B
^ permalink raw reply
* RFC: Could cpm2_clk_setup and cpm2_set_pin be exported ?
From: Laurent Pinchart @ 2008-08-28 15:57 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1723 bytes --]
Hi everybody,
I'm facing a situation where I need to call cpm2_clk_setup and cpm2_set_pin from a device driver compiled as a module. Before submitting a patch to export both functions, I'd like to make sure there isn't a cleaner way to implement the desired functionality without calling functions that are supposed to be used by board setup code.
The hardware is an Infineon SHDSL chip connected directly to 3 SCC ports of an MPC8248. The SHDSL ports roles can be set at runtime to Central Office or Remote Terminal (thing about a kind of master/slave configuration). SCC clock routing needs to configured at runtime to accommodate the ports roles (in one of the roles the SCC uses a baud rate generator, while in the other it receives the clock from the chip). Clocks are described in the device tree, so the driver does not hardcode clock values, but I need to call cpm2_clk_setup at runtime. Should this be done through board-supplied callbacks passed to the driver in a platform data structure (in which case I can't declare the device in the device tree as I'm doing now) or would it be acceptable to export cpm2_clk_setup ?
cpm2_set_pin is used for a similar purpose, as I have to setup BRG/CLK pins in input or output mode depending on the clock configuration. Additionally, cpm2_set_pin is also used to configure all inputs as outputs when the driver detects that the optional SDHSL module is not plugged in. Would it be safe to leave those pins as floating inputs, or could that potentially damage the MPC8248 ?
Thanks for your help.
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: 2.6.25: include/asm-ppc vs. include/asm-powerpc
From: Paul Smith @ 2008-08-28 16:01 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-embedded
In-Reply-To: <200808281642.26647.arnd@arndb.de>
On Thu, 2008-08-28 at 16:42 +0200, Arnd Bergmann wrote:
> The trick that arch/ppc uses is to create a symlink
> arch/ppc/include/asm pointing to include/asm-powerpc and then passing
> "-Iinclude -Iarch/ppc/include" to the compiler. This will make gcc
> look for headers in asm-ppc first, and then in asm-powerpc.
>
> It should also work with external modules if you build them in the
> recommended way (see http://lwn.net/Articles/80250/),
Hrm... I do build that way (with M=...)... oh, I see. When the kernel
build performs that trick the arch/ppc/include/asm symlink is pointing
to a fully-qualified pathname, not a relative pathname. So, when I
export this information and use it somewhere else that link is not
pointing to anything.
Argh. Well, at least that's something I can fix. Thanks for the info;
I'll let you know how it goes.
> but as I said, the easiest way is to just build all modules as part of
> the regular kernel build.
It's not really a very easy way in our environment. We're not primarily
in the business of building the Linux kernel; it's a very small part.
Most of our work is in userspace, and we have a very significant (and
bizarre) build environment there. I definitely cannot change THAT, at
this point. We build an initrd once in a blue moon, with a kernel,
busybox, and basic, very static facilities. Then, we check in the
initrd to our source code control system and almost everyone just uses
that image; they never need to build a kernel or initrd etc. themselves.
However, some of our kernel modules do change pretty frequently and are
much more tightly tied to our userspace stuff, so if we tried to put
them into the kernel tree it would be constantly changing and it would
be a mess; we need to keep those in our normal source code control area
along with our other code. So, I create a kernel sysroot kit and check
that in with the initrd, then unpack it to build the kernel modules.
Plus, we're using a development environment provided by WindRiver so the
build model for the kernel/initrd is that what we check in is a
compressed tarball with the basic kernel sources, plus a series of
patches; these are unpacked/applied when you build the initrd (kind of
like a Red Hat SRPM). This kind of "development by patches" is just not
feasible for anything that is continuously updated (IMO). If we were
fully invested in the entire kernel development model, with git for
source code control etc., then things would be simpler (for this
anyway). But that's not how we're doing things.
It's not a licensing thing: it's a development model thing.
^ permalink raw reply
* Re: [PATCH v2] POWERPC: Allow 32-bit pgtable code to support 36-bit physical
From: Scott Wood @ 2008-08-28 16:07 UTC (permalink / raw)
To: Becky Bruce; +Cc: linuxppc-dev
In-Reply-To: <C16F93B0-766C-43E8-B4B5-40BC0FEE298F@freescale.com>
Becky Bruce wrote:
> I'm pretty sure I went through this in great detail at one point and
> concluded that I did in fact need the lwarx/stwcx. IIRC, it has to do
> with other non-set_pte_at writers not necessarily holding the page table
> lock. FYI, the existing 32-bit PTE code is doing atomic updates as well.
But will those updates happen if there isn't already a valid PTE?
> About PTE_ATOMIC_UPDATES, I didn't add that in because hashed page table
> implementations require atomic updates.
Right, I misread it and thought it was being used for non-hashed
implementations as well.
What happens if you enable 64-bit PTEs on a 603-ish CPU? The kconfig
seems to allow it.
> Adding it in would create
> another clause in that code, because I would still need to order the
> operations with a 64-bit PTE and I can't call pte_update as it only
> changes the low word of the pte. I wasn't feeling too keen on adding
> untested pagetable code into the kernel :)
Wimp. :-)
> I can add it if the peanut
> gallery wants it, but I'll be marking it with a big fat "BUYER BEWARE".
No, there's little point if nothing selects it (or is planned to in the
near future).
>>> diff --git a/arch/powerpc/platforms/Kconfig.cputype
>>> b/arch/powerpc/platforms/Kconfig.cputype
>>> index 7f65127..ca5b58b 100644
>>> --- a/arch/powerpc/platforms/Kconfig.cputype
>>> +++ b/arch/powerpc/platforms/Kconfig.cputype
>>> @@ -128,18 +128,22 @@ config FSL_EMB_PERFMON
>>> config PTE_64BIT
>>> bool
>>> - depends on 44x || E500
>>> + depends on 44x || E500 || 6xx
>>> default y if 44x
>>> - default y if E500 && PHYS_64BIT
>>> + default y if PHYS_64BIT
>>
>> How is this different from PHYS_64BIT?
>
> One is the width of the PTE and one is the width of a physical address.
> It's entirely plausible to have a 64-bit PTE because you have a bunch of
> status bits, and only have 32-bit physical addressing. That's why there
> are 2 options.
Right, I just didn't see anything that actually selects it independently
of PHYS_64BIT. Is this something that's expected to actually happen in
the future?
The "default y if 44x" line is redundant with the "default y if PHYS_64BIT".
>>> config PHYS_64BIT
>>> - bool 'Large physical address support' if E500
>>> - depends on 44x || E500
>>> + bool 'Large physical address support' if E500 || 6xx
>>
>> Maybe "if !44x", or have 44x "select" this, rather than listing all
>> arches where it's optional.
>
> Not sure exactly what you're suggesting here........
It just seems simpler to not conditionalize the bool, but instead have
CONFIG_44x do "select PHYS_64BIT". I'd rather avoid another list of
platforms accumulating in a kconfig dependency.
>>> + depends on 44x || E500 || 6xx
>>> select RESOURCES_64BIT
>>> default y if 44x
>>> ---help---
>>> This option enables kernel support for larger than 32-bit physical
>>> - addresses. This features is not be available on all e500 cores.
>>> + addresses. This features is not be available on all cores.
>>
>> "This features is not be"?
>
> Heh, I didn't type that :) But I can fix it.
You didn't type it, but you touched it. Tag, you're it. :-)
-Scott
^ permalink raw reply
* Re: cpm_dpalloc questions
From: Scott Wood @ 2008-08-28 16:23 UTC (permalink / raw)
To: bhanu jampala; +Cc: linuxppc-embedded
In-Reply-To: <4a21eaea0808272212y6be97789nb6b94dd1d4987881@mail.gmail.com>
bhanu jampala wrote:
> I am working on MCC HDLC controller on MCC8260. I have two important questions:
>
> 1. What is the range of DPRAM from which the cpm_dpalloc allocates memory?
> How does the cpm_dpalloc work?
Assuming you're using arch/powerpc on a recent kernel version, it
allocates from the memory specified in the muram node of the device tree.
> I need this because, I need to reserve the DPRAM memory for MCC2
> from (128 * 60) to (255 * 60)
> for channels ranging from 128 - 255.
Why do you need to reserve a specific address?
> 2. PROFF_SMC1 pointer placed at 0 , 64 offsets. is this not an area of
> MCC1 controller?
No, MCC1 PRAM starts at offset 0x8700. Any other areas used are under
software control.
> how if I want to use the MCC channel on MCC1.
>
> In file include/asm-powerpc/cpm2.h.
>
> /* The SMCs are relocated to any of the first eight DPRAM pages.
> * We will fix these at the first locations of DPRAM, until we
> * get some microcode patches :-).
> * The parameter ram space for the SMCs is fifty-some bytes, and
> * they are required to start on a 64 byte boundary.
> */
> #define PROFF_SMC1 (0)
> #define PROFF_SMC2 (64)
This is obsolete arch/ppc stuff and should be removed; the SMC pram is
now dynamically allocated and relocated (and before that, it came from
the device tree).
-Scott
^ permalink raw reply
* Re: Virtual IRQs on 82xx
From: Scott Wood @ 2008-08-28 16:27 UTC (permalink / raw)
To: Muller, Ralf (NSN - FI/Espoo); +Cc: linuxppc-embedded
In-Reply-To: <F9730D1BBC18E749AE72728B74D189E968356A@FIESEXC006.nsn-intra.net>
Muller, Ralf (NSN - FI/Espoo) wrote:
> I'm using a 8247 custom board and kernl 2.6.21.7
I strongly recommend using something newer. There was a lot of 82xx
work going on around that time.
> on the arch/powerpc
> branch. Here the irq are virtualized in the irq map functions now I'm
> facing several problems.
>
> * I have to manually call irq_create_of_mapping for each CPM interrupt
What's wrong with irq_of_parse_and_map()?
> And the major problem is:
> Now the kernel mixes virtual- and HW-IRQs, e.g. request_irq works with
> HW_IRQs but the interrupt handler with virtual interrupts, which can't work.
No, request_irq works with virtual interrupts as well.
> For some reason even on a powerpc the first 16 interrupts are reserved
> for legacy (PC) IRQs,
Right, there are powerpc systems with the same legacy interrupts and the
same ISA drivers that expect to be able to use ISA IRQs directly as virqs.
> so the easiest mapping HW-IRQ0 -> VIRQ16 a.s.o
The "easiest mapping" is whatever the IRQ subsystem gives you. This
isn't something that should be hardcoded.
-Scott
^ permalink raw reply
* Re: [PATCH 2/4] Add cpufreq driver for the IBM PowerPC 750GX
From: Kevin Diggs @ 2008-08-28 16:34 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <200808280946.10077.arnd@arndb.de>
Arnd Bergmann wrote:
> On Wednesday 27 August 2008, Kevin Diggs wrote:
>
>>Arnd Bergmann wrote:
>>
>>>I think the module_exit() function should leave the frequency in a
>>>well-defined state, so the easiest way to get there is probably
>>>to delete the timer, and then manually set the frequency.
>>>
>>
>>I really don't follow you here? If I let the timer fire then the cpu
>>(and the cpufreq sub-system) will be left in a well-defined state. I
>>don't understand why you want me to delete the timer and then
>>basically do manually what it was going to do anyway. There are two
>>calls to cpufreq_notify_transition(). One just before the modify_PLL()
>>call, with CPUFREQ_PRECHANGE as an argument, and one in the
>>pll_switch_cb() routine, with CPUFREQ_POSTCHANGE as an argument. I
>>would need to make sure that these are matched up.
>>
>>Even without the HRTimer stuff being used the timer fires in less than
>>4 ms (@ 250 HZ). So I can't see the user actually trying to interrupt
>>a frequency change. With HRTimers it is 100 us.
>>
>>Can we please, please leave this part as is?
>
>
> I'm still not convinced that it's actually correct if you call complete()
> from the other places as well. You have three locations in your code where
> you call complete() but only one for INIT_COMPLETION. The part that I don't
> understand (and therefore don't expect other readers to understand) is how
> the driver guarantees that only one complete() will be called on the
> completion variable after it has been initialized.
>
> What I meant with the well-defined state is that after unloading the module,
> the CPU frequency should be the same as before loading the module, typically
> the maximum frequency, but not the one that was set last.
>
As you point out, there are three calls to complete().
The first is in the switch callback, in the idle_pll_off disabled branch.
This callback is triggered from the pll switch routine in pll_if. So that
means the call to _modify_PLL() in _target worked. So the complete() call
in _target will NOT be called. The complete() call in the lock callback
is only called in the idle_pll_off enabled branch.
As just mentioned, the second complete() call in the lock callback is
only called when idle_pll_off is enabled.
The final complete() call is in the unlock exit path in _target(). This
is an error path, where for one reason or another, there was no successful
call to _modify_PLL(). Thus there will be triggering of either callback.
There is another initialization of the completion: the DECLARE_COMPLETION().
I think I will deadlock if I get unloaded before _target() is ever called.
This can happen. I may add a test_bit(...changing_pll_bit) condition on the
wait_for_completion() call.
>
> Arnd <><
>
Thanks for taking the time to review and for the comments!
kevin
^ permalink raw reply
* Re: [PATCH] usb: add Freescale QE/CPM USB peripheral controller driver
From: Scott Wood @ 2008-08-28 16:39 UTC (permalink / raw)
To: Li Yang; +Cc: greg, linux-usb, linux-kernel, dbrownell, linuxppc-dev
In-Reply-To: <1219916613-28827-1-git-send-email-leoli@freescale.com>
On Thu, Aug 28, 2008 at 05:43:33PM +0800, Li Yang wrote:
> +config USB_GADGET_FSL_QE
> + boolean "Freescale QE/CPM USB Device Controller"
> + depends on FSL_SOC && (QUICC_ENGINE || CPM)
> + help
> + Some of Freescale PowerPC processors have a Full Speed
> + QE/CPM2 USB controller, which support device mode with 4
> + programmable endpoints. This driver supports the
> + controller in the MPC8360 and MPC8272, and should work with
> + controllers having QE or CPM2, given minor tweaks.
> +
> + Say "y" to link the driver statically, or "m" to build a
> + dynamically linked module called "fsl_qe_udc" and force all
> + gadget drivers to also be dynamically linked.
How can you say "m" to something that is not a tristate?
-Scott
^ permalink raw reply
* Re: RFC: Could cpm2_clk_setup and cpm2_set_pin be exported ?
From: Laurent Pinchart @ 2008-08-28 17:07 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080828164142.GB1185@ld0162-tx32.am.freescale.net>
[-- Attachment #1: Type: text/plain, Size: 1018 bytes --]
On Thursday 28 August 2008, Scott Wood wrote:
> On Thu, Aug 28, 2008 at 05:57:13PM +0200, Laurent Pinchart wrote:
> > I'm facing a situation where I need to call cpm2_clk_setup and
> > cpm2_set_pin from a device driver compiled as a module. Before
> > submitting a patch to export both functions, I'd like to make sure
> > there isn't a cleaner way to implement the desired functionality
> > without calling functions that are supposed to be used by board setup
> > code.
>
> Have you looked at using the GPIO API?
Yes, but the GPIO API doesn't support dedicated pin usage. Basically all I can do is configure a pin as a general purpose input or output, and set its level when configured as an output. The GPIO API doesn't provide any way to access the PAR and SOR registers.
Beside, the GPIO API won't help configuring clock routing.
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Early boot problem with MPC8247 and Linux 2.6.26
From: Chris Skepper @ 2008-08-28 17:00 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-embedded
In-Reply-To: <20080827150105.GB16041@ld0162-tx32.am.freescale.net>
On Wed, 27 Aug 2008, Scott Wood wrote:
> On Wed, Aug 27, 2008 at 02:30:47PM +0100, Chris Skepper wrote:
>> I just left CONFIG_PPC_EARLY_DEBUG_CPM_ADDR at the default value for CPM2?
>> Is that likely to be correct for SMC1? (I tried looking in the MPC8272
>> reference manual, but couldn't find it.)
>
> The value depends on how the port was set up by firmware (or by the
> bootwrapper). It should be set to wherever the descriptor is, and there
> should only be one descriptor that loops back on itself.
Hi Scott,
Thanks so much for your help so far. I was able to find out this address
from the bootloader and get some output on the early debug console which
was very pleasing. It now gets as far as console_init() called from
init/main.c, which completes but then any printk seems to stall it and
you get no more output.
I am using SMC1 and have this in the DTS file for the linux,stdout-path:
serial@11a80 {
device_type = "serial";
compatible = "fsl,mpc8247-smc-uart",
"fsl,cpm2-smc-uart";
reg = <0x11a80 0x20 0x87fc 2>;
interrupts = <4 8>;
interrupt-parent = <&PIC>;
fsl,cpm-brg = <7>;
fsl,cpm-command = <0x1d000000>;
};
Any ideas what sorts of things I should check next?
Cheers,
Chris.
^ 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