* Re: merge these lists?
From: Kumar Gala @ 2006-02-07 14:36 UTC (permalink / raw)
To: Jeremy Kerr; +Cc: linuxppc64-dev, linuxppc-dev
In-Reply-To: <200602071445.45805.jk@ozlabs.org>
On Feb 6, 2006, at 9:45 PM, Jeremy Kerr wrote:
> Paul,
>
>> If we do this, we would set up the new list with the union of the
>> subscribers of the old lists, and make emails sent to linuxppc-dev
>> and linuxppc64-dev go to the new list, so it should be painless.
>>
>> Thoughts? Comments? Objections?
>
> How about the patchwork lists? Should I look at merging those too?
Hmm, how about a merged patchwork starting after 2.6.16?
- kumar
^ permalink raw reply
* Re: merge these lists?
From: Kumar Gala @ 2006-02-07 14:35 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <20060207105643.GA22234@lst.de>
On Feb 7, 2006, at 4:56 AM, Christoph Hellwig wrote:
> On Tue, Feb 07, 2006 at 02:41:39PM +1100, Paul Mackerras wrote:
>> A lot of messages seem to get cross-posted to both linuxppc-dev and
>> linuxppc64-dev these days, since we are all working in the one tree.
>> Rather than having to cross-post, I propose that we create a single
>> powerpc-dev@ozlabs.org list to replace linuxppc-dev and
>> linuxppc64-dev. (The linuxppc-embedded list would continue as at
>> present.)
>
> Why not just kill linuxppc64-dev and leave linuxppc-dev? Probably not
> worth to remove the well-known and widely used address just for the
> sake of it.
I agree. Let's just kill linuxppc64-dev and direct people at
linuxppc-dev.
- kumar
^ permalink raw reply
* Re: CPM2 USB driver & MPC8248
From: Laurent Pinchart @ 2006-02-07 14:33 UTC (permalink / raw)
To: Mike Rapoport; +Cc: linuxppc-embedded
In-Reply-To: <43E8ACB3.6030401@compulab.co.il>
> The driver development is stalled and I don't know when I'll be able to
> continue working on it.
Bad news, but I do understand. Please inform me when you will resume working
on the driver, so that I can inform you of the progress I will have made (if
any).
> >What are the major performance issues ?
>
> One of the issues in this driver is redunduncy between qe end ep
> structures and as a consequence a lot of uneeded code that make cross
> updates.
> I didn't run profiling, so I can't tell better.
Ok.
> >I noticed that the driver uses the MPC82xx packet level interface.
> >Why don't you use the transaction level interface ?
>
> The original driver I've started with used packet level. I thought on
> switching to transaction level, but I hadn't time for it because of
> other projects pressure.
Do you think it would be worth it, or are there any issue which you are aware
of that would make it difficult/impractical/impossible/useless ?
> >That might explain why some devices don't even respond to the first
> > request. I noticed that, on my EP8248 board, the controller only sends
> > 990 SOF packets per second (or rather 990 SOF interrupts are generated).
> > I might have a time base problem somewhere, as I computed the number of
> > interrupts per second with a simple
> >
> >cat /proc/driver/m8xxhci_privateh > sof.1 && sleep 300 &&
> >cat /proc/driver/m8xxhci_privateh > sof.2
>
> I'm not sure such measurements are correct, since you sleep not exatly
> 300 seconds. I haven't measured how many SOF interrupts I get, but I
> think you maybe right.
> It may happen that during transmit or recieve the interrupts are off and
> SOF packets are not sent.
My bad, this was caused by the boot loader passing 66000000Hz instead of
66666666Hz to Linux as the bus frequency. This is fixed now, and I get 1000
SOF interrupts per second.
> >Do you have the same problem ? I'll see if I can get my hands on a USB
> >protocol analyzer.
>
> Good luck, I'll try to help but unfotunately I'm very much busy with
> other projects now.
Thanks for your help already.
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH] powerpc: Fix Kernel FP unavail exception for BookE
From: Kumar Gala @ 2006-02-07 14:28 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, galak
In-Reply-To: <17384.30426.76075.491857@cargo.ozlabs.ibm.com>
On Feb 7, 2006, at 4:30 AM, Paul Mackerras wrote:
> Becky Bruce writes:
>
>> powerpc: Correct BookE FP unavailable exception
>
> ...
>
>> diff --git a/arch/powerpc/kernel/head_booke.h b/arch/powerpc/
>> kernel/head_booke.h
>
> Ummm... which tree has head_booke.h?
powerpc.git should have it. If not this is an issue that should be
fixed.
Becky, is this change also needed for arch/ppc? If so can you fixup
arch/ppc/kernel/head_booke.h and provide patch that duplicates
head_booke.h in arch/powerpc/kernel if its not there.
- k
^ permalink raw reply
* Re: CPM2 USB driver & MPC8248
From: Mike Rapoport @ 2006-02-07 14:20 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-embedded
In-Reply-To: <200602071414.28551.laurent.pinchart@tbox.biz>
Laurent Pinchart wrote:
>How is the driver development going ? You're not using the sourceforge CVS/SVN
>repository, is there another one somewhere (maybe a git tree) ? Are you
>actively working on performance issues, or is the development currently
>stalled ?
>
>
The driver development is stalled and I don't know when I'll be able to
continue working on it.
>What are the major performance issues ?
>
>
One of the issues in this driver is redunduncy between qe end ep
structures and as a consequence a lot of uneeded code that make cross
updates.
I didn't run profiling, so I can't tell better.
>I noticed that the driver uses the MPC82xx packet level interface.
>Why don't you use the transaction level interface ?
>
>
The original driver I've started with used packet level. I thought on
switching to transaction level, but I hadn't time for it because of
other projects pressure.
>
>
>>Another thing that may cause problems is how storage devices treat SOF
>>packets, but I'm not USB expert enough to be sure about that.
>>
>>
>
>That might explain why some devices don't even respond to the first request. I
>noticed that, on my EP8248 board, the controller only sends 990 SOF packets
>per second (or rather 990 SOF interrupts are generated). I might have a time
>base problem somewhere, as I computed the number of interrupts per second
>with a simple
>
>cat /proc/driver/m8xxhci_privateh > sof.1 && sleep 300 &&
>cat /proc/driver/m8xxhci_privateh > sof.2
>
>
>
I'm not sure such measurements are correct, since you sleep not exatly
300 seconds. I haven't measured how many SOF interrupts I get, but I
think you maybe right.
It may happen that during transmit or recieve the interrupts are off and
SOF packets are not sent.
>Do you have the same problem ? I'll see if I can get my hands on a USB
>protocol analyzer.
>
>
Good luck, I'll try to help but unfotunately I'm very much busy with
other projects now.
>Laurent Pinchart
>
>
>
>
>
--
Sincerely yours,
Mike Rapoport
^ permalink raw reply
* Re: CPM2 USB driver & MPC8248
From: Laurent Pinchart @ 2006-02-07 13:14 UTC (permalink / raw)
To: Mike Rapoport; +Cc: linuxppc-embedded
In-Reply-To: <43E5BAE8.9000507@compulab.co.il>
> >When I connect a USB 2.0 Mass Storage device, initialization fails when
> > trying to fetch the string descriptors. Here's what USBMon produces (I
> > decoded the USB transactions with the device).
>
> [snip]
>
> I had similar problems with mass storage devices (disk-on-key). I've
> tried to find out what was causing them but I hadn't much success with it.
> I think that problem might be in driver performance because it is very
> far from optimal.
How is the driver development going ? You're not using the sourceforge CVS/SVN
repository, is there another one somewhere (maybe a git tree) ? Are you
actively working on performance issues, or is the development currently
stalled ? What are the major performance issues ? I noticed that the driver
uses the MPC82xx packet level interface. Why don't you use the transaction
level interface ?
> Another thing that may cause problems is how storage devices treat SOF
> packets, but I'm not USB expert enough to be sure about that.
That might explain why some devices don't even respond to the first request. I
noticed that, on my EP8248 board, the controller only sends 990 SOF packets
per second (or rather 990 SOF interrupts are generated). I might have a time
base problem somewhere, as I computed the number of interrupts per second
with a simple
cat /proc/driver/m8xxhci_privateh > sof.1 && sleep 300 &&
cat /proc/driver/m8xxhci_privateh > sof.2
Do you have the same problem ? I'll see if I can get my hands on a USB
protocol analyzer.
Laurent Pinchart
^ permalink raw reply
* Re: Common Flash Interface v1.4 and MTD support in Linux-2.4.4 kernel
From: Josh Boyer @ 2006-02-07 10:52 UTC (permalink / raw)
To: David Antliff; +Cc: linuxppc-embedded
In-Reply-To: <1139283195.26357.50.camel@theoden.middle_earth>
On Tue, 2006-02-07 at 16:33 +1300, David Antliff wrote:
>
>
> I am working on an MPC852 embedded platform based on the Denx
> Linux-2.4.4 port.
To note, 2.4.4 is ancient. And this whole question would be better
asked on the MTD mailing list.
>
> We have an existing device with a fixed-flash (AMD-type) conforming to
> CFI (Common Flash Interface) version 1.2. Linux-2.4.4 supports this
> device when used by the Memory Tech Device Driver (MTD). This device has
> a single region ('plane'?) or at least constant geometry across the
> device. MTD in 2.4.4 has no problems dividing this up into a bunch of
> block devices (partitions for read-only filesystems).
Yep.
>
> A newer version has a different flash chip - an Intel P30 flash with
> multiple regions - it has two types of geometries as it is configured
> for 'boot' operation. It also conforms to CFI version 1.4. Unfortunately
> the Linux-2.4.4 MTD driver rejects this as unsupported based on CFI
> version and hard-coding it in "kinda" works - the partition devices are
> readable but the driver complains bitterly about non-alignment with
> erase blocks. I suspect the driver is picking up parameters from the
> first region (which covers the first set of blocks) and trying to use
> this across the device. One thing I don't understand yet - as the first
> region uses block sizes that are an integer division of those in the
> second region I'm not sure why the boundaries don't align when I am
> using the 2nd-region block size to define the partition boundaries.
P30 support was just recently added to the 2.6 kernel.
>
>
> What I am looking for is some advice please - what do you think is the
> best course of action in this situation?
>
> There will be others but so far I am considering:
>
> 1. back-port the CFI code from a newer 2.4 kernel to support CFI v1.4.
> - does anybody know the state of MTD in later versions? What would be a
> good version to source from?
There is no support for CFI 1.4 in any 2.4 kernel. You'd have to
backport from 2.6
>
> 2. integrate code found here and try and understand how it works:
> http://lists.infradead.org/pipermail/linux-mtd/2001-November/003645.html
That won't solve all of your problems.
>
>
> What would you suggest? Yes, I am happy for a 'quick fix' but if there
> isn't one or it's too risky I am willing to invest the time in doing it
> right.
'quick fix' is to pull the changes from cfi_cmdset_0001.c in MTD CVS
back into your kernel. But I'm not sure how quick that will be given
that your kernel is very very old.
josh
^ permalink raw reply
* Re: [PATCH] missing refcounting of of_find_node_by_name users
From: Olaf Hering @ 2006-02-07 10:58 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17384.31565.896220.384684@cargo.ozlabs.ibm.com>
On Tue, Feb 07, Paul Mackeras wrote:
> This one isn't necessary, since np is NULL by the time we get out of
> the loop. Same applies to the other places in this file that this
> patch affects.
Ok.
> > Index: linux-2.6.16-rc2-olh/arch/powerpc/platforms/powermac/pci.c
> > ===================================================================
> > --- linux-2.6.16-rc2-olh.orig/arch/powerpc/platforms/powermac/pci.c
> > +++ linux-2.6.16-rc2-olh/arch/powerpc/platforms/powermac/pci.c
> > @@ -695,6 +695,7 @@ static void __init fixup_nec_usb2(void)
> > nec->intrs[0].line);
> > }
> > }
> > + of_put_node(nec);
>
> Once again, nec is NULL by the time we get here. And of_put_node
> doesn't exist. :( Did you compile-test this?
Only with a pegasos only config, which doesnt cover these files.
--
short story of a lazy sysadmin:
alias appserv=wotan
^ permalink raw reply
* Re: merge these lists?
From: Christoph Hellwig @ 2006-02-07 10:56 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <17384.5875.790692.127762@cargo.ozlabs.ibm.com>
On Tue, Feb 07, 2006 at 02:41:39PM +1100, Paul Mackerras wrote:
> A lot of messages seem to get cross-posted to both linuxppc-dev and
> linuxppc64-dev these days, since we are all working in the one tree.
> Rather than having to cross-post, I propose that we create a single
> powerpc-dev@ozlabs.org list to replace linuxppc-dev and
> linuxppc64-dev. (The linuxppc-embedded list would continue as at
> present.)
Why not just kill linuxppc64-dev and leave linuxppc-dev? Probably not
worth to remove the well-known and widely used address just for the
sake of it.
^ permalink raw reply
* Re: [PATCH] missing refcounting of of_find_node_by_name users
From: Paul Mackerras @ 2006-02-07 10:49 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev
In-Reply-To: <20060204122013.GA20324@suse.de>
Olaf Hering writes:
> drop the refcount of the node returned from of_find_node_by_name
[snip]
> --- linux-2.6.16-rc2-olh.orig/arch/powerpc/platforms/powermac/feature.c
> +++ linux-2.6.16-rc2-olh/arch/powerpc/platforms/powermac/feature.c
> @@ -2772,6 +2772,7 @@ set_initial_features(void)
> g5_gmac_enable(np, 0, 1);
> np = of_find_node_by_name(np, "ethernet");
> }
> + of_node_put(np);
This one isn't necessary, since np is NULL by the time we get out of
the loop. Same applies to the other places in this file that this
patch affects.
> Index: linux-2.6.16-rc2-olh/arch/powerpc/platforms/powermac/pci.c
> ===================================================================
> --- linux-2.6.16-rc2-olh.orig/arch/powerpc/platforms/powermac/pci.c
> +++ linux-2.6.16-rc2-olh/arch/powerpc/platforms/powermac/pci.c
> @@ -695,6 +695,7 @@ static void __init fixup_nec_usb2(void)
> nec->intrs[0].line);
> }
> }
> + of_put_node(nec);
Once again, nec is NULL by the time we get here. And of_put_node
doesn't exist. :( Did you compile-test this?
Regards,
Paul.
^ permalink raw reply
* Re: [PATCH] powerpc: Fix Kernel FP unavail exception for BookE
From: Paul Mackerras @ 2006-02-07 10:30 UTC (permalink / raw)
To: Becky Bruce; +Cc: linuxppc-dev, galak
In-Reply-To: <Pine.LNX.4.61.0601311746250.18350@cde-tx32-ldt329.sps.mot.com>
Becky Bruce writes:
> powerpc: Correct BookE FP unavailable exception
...
> diff --git a/arch/powerpc/kernel/head_booke.h b/arch/powerpc/kernel/head_booke.h
Ummm... which tree has head_booke.h?
Paul.
^ permalink raw reply
* RE: Floating point math in kernel interrupt -- am I doing thisright?(repost)
From: Josu Onandia @ 2006-02-07 9:44 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
In the RTAI scheduler there are routines (save_fpenv, restore_fpenv) =
that are very similar to your functions. I'd suggest to look in more =
detail if there are any subtle difference.
I think also that Sylvain can be right about the stack, so it could be a =
good idea to place saved_fpr in static storage, not in the stack.
My 2 cents
Josu
-----Mensaje original-----
De: linuxppc-embedded-bounces@ozlabs.org
[mailto:linuxppc-embedded-bounces@ozlabs.org]En nombre de Joyeau Sylvain
Enviado el: martes, 07 de febrero de 2006 8:20
Para: Jeremy Friesner
CC: linuxppc-embedded@ozlabs.org
Asunto: RE: Floating point math in kernel interrupt -- am I doing
thisright?(repost)
Jeremy,
What about kernel stack overflow ?
You mention that the occurrence of the crash is proportional to the =
amount of embraced code, which generally use more stack space too... but =
you aren't very accurate about the call context of your DoMix() =
function: it can be called depth enough to tickle the interrupted thread =
control block and issue indirect spurious behavior is userland.
Hope this help.
--
sj
> -----Original Message-----
> From: linuxppc-embedded-bounces@ozlabs.org =
[mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of Jeremy =
Friesner
> Sent: lundi 6 f=E9vrier 2006 17:55
> To: Dan Malek
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: Floating point math in kernel interrupt -- am I doing =
this right?(repost)
>=20
> >
> > On Feb 5, 2006, at 9:29 PM, Jeremy Friesner wrote:
> >
> > > .... and the mixing is done inside an
> > > interrupt routine that runs 6000 times per second, and calculates =
8
> > > samples
> > > per interrupt.
> >
> > Bad news. No Floating Point allowed in the kernel.
>=20
> I'm aware of that rule, and also why -- because the Linux kernel =
doesn't want to have to save and restore the state of the
> floating point registers on every context switch. I'm also aware that =
it is nonetheless possible to use floating point in
> the kernel if you are careful to manually save and restore the proper =
state yourself, and that in fact floating point is
> sometimes used in the kernel as a means of doing 64-bit writes, as =
mentioned here:
>=20
> http://www.tldp.org/LDP/cpg/html/x295.html
>=20
> So it seems to me that it is possible to do floating point in the =
kernel, if you are careful to save and restore the proper
> context/state before and afterwards. But if it isn't, can you explain =
to me why it can't be made to work?
>=20
> > > In order to do the necessary floating point math, without =
corrupting
> > > the state
> > > of any other processes that might be using the FPU, the interrupt
> > > routine
> > > first saves the state of the FPU registers to the stack, then does =
the
> > > math,
> > > then restores FPU registers again, before returning.
> >
> > Not on 82xx. All floating point is done in hardware.
>=20
> Right; it is the hardware registers' state that I am saving to the =
stack, and then restoring afterwards.
>=20
> > > So my question is, is there some minor detail that my
> > > FPU-state-save/restore
> > > code is missing, that would cause these sort of symptoms?
> >
> > Just get all of this out of the kernel. If you used the standard =
ALSA
> > drivers and framework, lots of mixing features are available to you.
> > If you need some custom mixing, just write a plug-in to do it.
> > Your data rates are so low they don't justify making any hacks
> > like this.
>=20
> I suppose that is an option, but I'd rather understand why my hack =
isn't working before I give up and redesign my
> application, which is already working the way I want it to, 99.9999% =
of the time.
>=20
> Jeremy
>=20
>=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* RE: Floating point math in kernel interrupt -- am I doing this right?(repost)
From: Joyeau Sylvain @ 2006-02-07 7:20 UTC (permalink / raw)
To: Jeremy Friesner; +Cc: linuxppc-embedded
Jeremy,
What about kernel stack overflow ?
You mention that the occurrence of the crash is proportional to the =
amount of embraced code, which generally use more stack space too... but =
you aren't very accurate about the call context of your DoMix() =
function: it can be called depth enough to tickle the interrupted thread =
control block and issue indirect spurious behavior is userland.
Hope this help.
--
sj
> -----Original Message-----
> From: linuxppc-embedded-bounces@ozlabs.org =
[mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of Jeremy =
Friesner
> Sent: lundi 6 f=E9vrier 2006 17:55
> To: Dan Malek
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: Floating point math in kernel interrupt -- am I doing =
this right?(repost)
>=20
> >
> > On Feb 5, 2006, at 9:29 PM, Jeremy Friesner wrote:
> >
> > > .... and the mixing is done inside an
> > > interrupt routine that runs 6000 times per second, and calculates =
8
> > > samples
> > > per interrupt.
> >
> > Bad news. No Floating Point allowed in the kernel.
>=20
> I'm aware of that rule, and also why -- because the Linux kernel =
doesn't want to have to save and restore the state of the
> floating point registers on every context switch. I'm also aware that =
it is nonetheless possible to use floating point in
> the kernel if you are careful to manually save and restore the proper =
state yourself, and that in fact floating point is
> sometimes used in the kernel as a means of doing 64-bit writes, as =
mentioned here:
>=20
> http://www.tldp.org/LDP/cpg/html/x295.html
>=20
> So it seems to me that it is possible to do floating point in the =
kernel, if you are careful to save and restore the proper
> context/state before and afterwards. But if it isn't, can you explain =
to me why it can't be made to work?
>=20
> > > In order to do the necessary floating point math, without =
corrupting
> > > the state
> > > of any other processes that might be using the FPU, the interrupt
> > > routine
> > > first saves the state of the FPU registers to the stack, then does =
the
> > > math,
> > > then restores FPU registers again, before returning.
> >
> > Not on 82xx. All floating point is done in hardware.
>=20
> Right; it is the hardware registers' state that I am saving to the =
stack, and then restoring afterwards.
>=20
> > > So my question is, is there some minor detail that my
> > > FPU-state-save/restore
> > > code is missing, that would cause these sort of symptoms?
> >
> > Just get all of this out of the kernel. If you used the standard =
ALSA
> > drivers and framework, lots of mixing features are available to you.
> > If you need some custom mixing, just write a plug-in to do it.
> > Your data rates are so low they don't justify making any hacks
> > like this.
>=20
> I suppose that is an option, but I'd rather understand why my hack =
isn't working before I give up and redesign my
> application, which is already working the way I want it to, 99.9999% =
of the time.
>=20
> Jeremy
>=20
>=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: merge these lists?
From: Michael Ellerman @ 2006-02-07 4:29 UTC (permalink / raw)
To: linuxppc64-dev; +Cc: linuxppc-dev
In-Reply-To: <20060207041243.GC7626@pb15.lixom.net>
[-- Attachment #1: Type: text/plain, Size: 1291 bytes --]
On Tue, 7 Feb 2006 15:12, Olof Johansson wrote:
> On Tue, Feb 07, 2006 at 02:45:45PM +1100, Jeremy Kerr wrote:
> > Paul,
> >
> > > If we do this, we would set up the new list with the union of the
> > > subscribers of the old lists, and make emails sent to linuxppc-dev
> > > and linuxppc64-dev go to the new list, so it should be painless.
> > >
> > > Thoughts? Comments? Objections?
> >
> > How about the patchwork lists? Should I look at merging those too?
>
> I get a feeling that our maintainers might not be using them much any
> more (most patches since August of last year are still "New"), but I
> find it convenient to search for a patch that you know has gone by but
> can't find in your list mbox.
>
> I would appreciate either a merge, or a new archive started for the new
> list. It's useful.
And while Jk has nothing else to do .. I'd like to be able to managed my own
patches, ie. set them as obsolete etc etc.
Oh and yeah I think we should merge the lists :D
cheers
--
Michael Ellerman
IBM OzLabs
email: michael:ellerman.id.au
inmsg: mpe:jabber.org
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: merge these lists?
From: Olof Johansson @ 2006-02-07 4:12 UTC (permalink / raw)
To: Jeremy Kerr; +Cc: linuxppc64-dev, linuxppc-dev
In-Reply-To: <200602071445.45805.jk@ozlabs.org>
On Tue, Feb 07, 2006 at 02:45:45PM +1100, Jeremy Kerr wrote:
> Paul,
>
> > If we do this, we would set up the new list with the union of the
> > subscribers of the old lists, and make emails sent to linuxppc-dev
> > and linuxppc64-dev go to the new list, so it should be painless.
> >
> > Thoughts? Comments? Objections?
>
> How about the patchwork lists? Should I look at merging those too?
I get a feeling that our maintainers might not be using them much any
more (most patches since August of last year are still "New"), but I
find it convenient to search for a patch that you know has gone by but
can't find in your list mbox.
I would appreciate either a merge, or a new archive started for the new
list. It's useful.
-Olof
^ permalink raw reply
* Re: merge these lists?
From: Jeremy Kerr @ 2006-02-07 3:45 UTC (permalink / raw)
To: linuxppc64-dev, linuxppc-dev
In-Reply-To: <17384.5875.790692.127762@cargo.ozlabs.ibm.com>
Paul,
> If we do this, we would set up the new list with the union of the
> subscribers of the old lists, and make emails sent to linuxppc-dev
> and linuxppc64-dev go to the new list, so it should be painless.
>
> Thoughts? Comments? Objections?
How about the patchwork lists? Should I look at merging those too?
Jeremy
^ permalink raw reply
* merge these lists?
From: Paul Mackerras @ 2006-02-07 3:41 UTC (permalink / raw)
To: linuxppc-dev, linuxppc64-dev
A lot of messages seem to get cross-posted to both linuxppc-dev and
linuxppc64-dev these days, since we are all working in the one tree.
Rather than having to cross-post, I propose that we create a single
powerpc-dev@ozlabs.org list to replace linuxppc-dev and
linuxppc64-dev. (The linuxppc-embedded list would continue as at
present.)
If we do this, we would set up the new list with the union of the
subscribers of the old lists, and make emails sent to linuxppc-dev and
linuxppc64-dev go to the new list, so it should be painless.
Thoughts? Comments? Objections?
Paul.
^ permalink raw reply
* Common Flash Interface v1.4 and MTD support in Linux-2.4.4 kernel
From: David Antliff @ 2006-02-07 3:33 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
Just to be clear, this email is related to work that I do for a
commercial enterprise, however I am writing on behalf of myself.
I am working on an MPC852 embedded platform based on the Denx
Linux-2.4.4 port.
We have an existing device with a fixed-flash (AMD-type) conforming to
CFI (Common Flash Interface) version 1.2. Linux-2.4.4 supports this
device when used by the Memory Tech Device Driver (MTD). This device has
a single region ('plane'?) or at least constant geometry across the
device. MTD in 2.4.4 has no problems dividing this up into a bunch of
block devices (partitions for read-only filesystems).
A newer version has a different flash chip - an Intel P30 flash with
multiple regions - it has two types of geometries as it is configured
for 'boot' operation. It also conforms to CFI version 1.4. Unfortunately
the Linux-2.4.4 MTD driver rejects this as unsupported based on CFI
version and hard-coding it in "kinda" works - the partition devices are
readable but the driver complains bitterly about non-alignment with
erase blocks. I suspect the driver is picking up parameters from the
first region (which covers the first set of blocks) and trying to use
this across the device. One thing I don't understand yet - as the first
region uses block sizes that are an integer division of those in the
second region I'm not sure why the boundaries don't align when I am
using the 2nd-region block size to define the partition boundaries.
What I am looking for is some advice please - what do you think is the
best course of action in this situation?
There will be others but so far I am considering:
1. back-port the CFI code from a newer 2.4 kernel to support CFI v1.4.
- does anybody know the state of MTD in later versions? What would be a
good version to source from?
2. integrate code found here and try and understand how it works:
http://lists.infradead.org/pipermail/linux-mtd/2001-November/003645.html
3. unfortunately upgrading the entire kernel is not an option at this
stage, unless absolutely necessary.
What would you suggest? Yes, I am happy for a 'quick fix' but if there
isn't one or it's too risky I am willing to invest the time in doing it
right.
Thank you,
David Antliff
Stratex Networks Ltd.
New Zealand
^ permalink raw reply
* List etiquette
From: David Antliff @ 2006-02-07 2:59 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 594 bytes --]
Hello,
I'm a new subscriber to this list and looking to ask a specific question
shortly. However I would like to bring two things up based on this page:
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
1. The list rules and posting guidelines URLs are out of service:
- http://lists.linuxppc.org/rules.html
- http://lists.linuxppc.org/guidelines.html
2. There is a recommendation to look for answers to questions in the
list archives. There does not seem to be any way to search these, except
with Google site: syntax. Am I missing something here?
Regards,
David
[-- Attachment #2: Type: text/html, Size: 1207 bytes --]
^ permalink raw reply
* [PATCH] powerpc: wire up the *at system calls
From: Stephen Rothwell @ 2006-02-06 23:59 UTC (permalink / raw)
To: paulus; +Cc: Andrew Morton, LKML, ppc-dev, Linus, ppc64-dev
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/kernel/systbl.S | 13 +++++++++++++
include/asm-powerpc/unistd.h | 15 ++++++++++++++-
2 files changed, 27 insertions(+), 1 deletions(-)
This depend on the patch that creates all the compat wrappers.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
d02d8208813d8cae2c814a85734a1a31fed2f3ac
diff --git a/arch/powerpc/kernel/systbl.S b/arch/powerpc/kernel/systbl.S
index 007b15e..fe16d9c 100644
--- a/arch/powerpc/kernel/systbl.S
+++ b/arch/powerpc/kernel/systbl.S
@@ -323,3 +323,16 @@ SYSCALL(spu_run)
SYSCALL(spu_create)
COMPAT_SYS(pselect6)
COMPAT_SYS(ppoll)
+COMPAT_SYS(openat)
+COMPAT_SYS(mkdirat)
+COMPAT_SYS(mknodat)
+COMPAT_SYS(fchownat)
+COMPAT_SYS(futimesat)
+COMPAT_SYS(newfstatat)
+COMPAT_SYS(unlinkat)
+COMPAT_SYS(renameat)
+COMPAT_SYS(linkat)
+COMPAT_SYS(symlinkat)
+COMPAT_SYS(readlinkat)
+COMPAT_SYS(fchmodat)
+COMPAT_SYS(faccessat)
diff --git a/include/asm-powerpc/unistd.h b/include/asm-powerpc/unistd.h
index a40cdff..d05b85e 100644
--- a/include/asm-powerpc/unistd.h
+++ b/include/asm-powerpc/unistd.h
@@ -300,8 +300,21 @@
#define __NR_spu_create 279
#define __NR_pselect6 280
#define __NR_ppoll 281
+#define __NR_openat 282
+#define __NR_mkdirat 283
+#define __NR_mknodat 284
+#define __NR_fchownat 285
+#define __NR_futimesat 286
+#define __NR_newfstatat 287
+#define __NR_unlinkat 288
+#define __NR_renameat 289
+#define __NR_linkat 290
+#define __NR_symlinkat 291
+#define __NR_readlinkat 292
+#define __NR_fchmodat 293
+#define __NR_faccessat 294
-#define __NR_syscalls 282
+#define __NR_syscalls 295
#ifdef __KERNEL__
#define __NR__exit __NR_exit
--
1.1.5
^ permalink raw reply related
* [PATCH] documentation: add bus-frequency property to SOC node
From: Becky Bruce @ 2006-02-06 20:26 UTC (permalink / raw)
To: linuxppc-dev, linuxppc64-dev
Updated SOC node definition in documentation to include bus-frequency
property. Also extended mdio example to match specification.
Signed-off-by: Becky Bruce <becky.bruce@freescale.com>
Signed-off-by: Kumar Gala <galak@gate.crashing.org>
---
commit 3441bf59c7e1dc3823f9be57838a2536c78f6f8f
tree 2901a0e19418f1fe904ff0d041c630b3af048961
parent 66c490c9b00c52cd0f1e088ad689c9148e46f49e
author Becky Bruce <becky.bruce@freescale.com> Thu, 02 Feb 2006 15:41:11 -0600
committer Becky Bruce <becky.bruce@freescale.com> Thu, 02 Feb 2006 15:41:11 -0600
Documentation/powerpc/booting-without-of.txt | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index 1284498..54e5f9b 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -880,6 +880,10 @@ address which can extend beyond that lim
- device_type : Should be "soc"
- ranges : Should be defined as specified in 1) to describe the
translation of SOC addresses for memory mapped SOC registers.
+ - bus-frequency: Contains the bus frequency for the SOC node.
+ Typically, the value of this field is filled in by the boot
+ loader.
+
Recommended properties:
@@ -919,6 +923,7 @@ SOC.
device_type = "soc";
ranges = <00000000 e0000000 00100000>
reg = <e0000000 00003000>;
+ bus-frequency = <0>;
}
@@ -1170,6 +1175,8 @@ platforms are moved over to use the flat
mdio@24520 {
reg = <24520 20>;
+ device_type = "mdio";
+ compatible = "gianfar";
ethernet-phy@0 {
......
@@ -1317,6 +1324,7 @@ not necessary as they are usually the sa
device_type = "soc";
ranges = <00000000 e0000000 00100000>
reg = <e0000000 00003000>;
+ bus-frequency = <0>;
mdio@24520 {
reg = <24520 20>;
^ permalink raw reply related
* Re: Yosemite/440EP PLB4 vs PLB3 DMA to PCI issue
From: David Hawkins @ 2006-02-06 19:09 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-embedded
In-Reply-To: <200602061931.25370.sr@denx.de>
Hi Stefan,
> I never used DMA on 440EP/GP till now so I just noticed the two different
> PLB's and their DMA controllers. Never seen this on any 4xx PPC so far. I
> suspect that the PLB4 is integrated mainly because of the USB interface.
That sounds about right. In my app I won't be using USB, and since the
PLB4 DMA controller has larger DMA buffers, I thought it might have an
edge over the PLB3 controller.
> What version of the user manual are you referring to? Could you please give
> the pages for the current manual (Revision 1.18).
Oh, sorry, I was looking at the version 1.14 manual. I've just
downloaded the 1.18 manual. Whoa! The 1.14 manual has 1696 pages,
whereas the 1.18 manual has only 794 - I hope that means things
have got simpler ;)
(nope, looks like the 440 core just got moved into another document)
Anyways, here are the v1.18 page references;
v1.18 p365-6 has the PLB-to-PCI Transaction Handling section
showing the cases where MRL and MRM will be used.
v1.18 p407 has the PCI Memory to SDRAM DMA transfer section
with comments and forward references to the timing
diagram pages.
>>(I hope you had a nice vacation Stefan!)
>
> Thanks. Very nice. One week of sunshine in the snow. :-)
I hope that means you got some nice snowboarding or skiing!
We have a fun mountain just up the road;
http://www.mammothmountain.com/
Feel free to come and visit if you are in California anytime!
Cheers
Dave
^ permalink raw reply
* Re: Yosemite/440EP PLB4 vs PLB3 DMA to PCI issue
From: Stefan Roese @ 2006-02-06 18:31 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <43E68E85.3080100@ovro.caltech.edu>
Hi David,
I never used DMA on 440EP/GP till now so I just noticed the two different
PLB's and their DMA controllers. Never seen this on any 4xx PPC so far. I
suspect that the PLB4 is integrated mainly because of the USB interface.
On Monday 06 February 2006 00:47, David Hawkins wrote:
> I took a look at the 440EP user manual, and I haven't been
> able to explain the PLB4 DMA controller observations.
>
> Here's what I've got so far;
>
> p595: PLB-to-PCI transaction handling
> Shows the two situations where the PCI bridge will
> generate memory-read-line (MRL) and memory-read-multiple (MRM)
What version of the user manual are you referring to? Could you please give
the pages for the current manual (Revision 1.18).
<snip>
> (I hope you had a nice vacation Stefan!)
Thanks. Very nice. One week of sunshine in the snow. :-)
Ciao,
Stefan
^ permalink raw reply
* Re: Floating point math in kernel interrupt -- am I doing this right? (repost)
From: Jeremy Friesner @ 2006-02-06 16:55 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-embedded
In-Reply-To: <3c13d56389dfcf9f45ca87167295e933@embeddedalley.com>
>
> On Feb 5, 2006, at 9:29 PM, Jeremy Friesner wrote:
>
> > .... and the mixing is done inside an
> > interrupt routine that runs 6000 times per second, and calculates 8
> > samples
> > per interrupt.
>
> Bad news. No Floating Point allowed in the kernel.
I'm aware of that rule, and also why -- because the Linux kernel doesn't want to have to save and restore the state of the floating point registers on every context switch. I'm also aware that it is nonetheless possible to use floating point in the kernel if you are careful to manually save and restore the proper state yourself, and that in fact floating point is sometimes used in the kernel as a means of doing 64-bit writes, as mentioned here:
http://www.tldp.org/LDP/cpg/html/x295.html
So it seems to me that it is possible to do floating point in the kernel, if you are careful to save and restore the proper context/state before and afterwards. But if it isn't, can you explain to me why it can't be made to work=3F
> > In order to do the necessary floating point math, without corrupting
> > the state
> > of any other processes that might be using the FPU, the interrupt
> > routine
> > first saves the state of the FPU registers to the stack, then does the
> > math,
> > then restores FPU registers again, before returning.
>
> Not on 82xx. All floating point is done in hardware.
Right; it is the hardware registers' state that I am saving to the stack, and then restoring afterwards.
> > So my question is, is there some minor detail that my
> > FPU-state-save/restore
> > code is missing, that would cause these sort of symptoms=3F
>
> Just get all of this out of the kernel. If you used the standard ALSA
> drivers and framework, lots of mixing features are available to you.
> If you need some custom mixing, just write a plug-in to do it.
> Your data rates are so low they don't justify making any hacks
> like this.
I suppose that is an option, but I'd rather understand why my hack isn't working before I give up and redesign my application, which is already working the way I want it to, 99.9999% of the time.
Jeremy
^ permalink raw reply
* Re: mv-linux: Problem to implement custom driver interrupt handling
From: Andrei Konovalov @ 2006-02-06 15:14 UTC (permalink / raw)
To: Eckart Göhler; +Cc: linuxppc-embedded
In-Reply-To: <43E74FB2.6010603@ifen.com>
Hi,
In the Linux driver you should not access the interrupt controller directly.
The relevant XIntc_* calls are done by arch/ppc/syslib/xilinx_pic.c code.
E.g. the particular interrupt is unmasked when one calls request_irq().
Few more comments below.
Thanks,
Andrei
Eckart Göhler wrote:
> Hi,
>
> We try to run montavista Linux pro 3.1 on an ml300 like embedded system
> on an Virtex V2-Pro system. The system works fine with UART, Xilinx enet
> driver (booting with Das U-Boot).
> Now we try to implement some custom GPIO driver that must be triggered
> from outside interrupts. Polling for data works fine but the handler for
> HW-timer interrupts does behaves strange.
>
> The relevant Linux driver part that requests the interrupt and starts
> the timer look like below.
>
> Installing such a driver works but
> - No report of driver interrupt called is sent
> - installing the driver results in a system that almost gets stuck and
> has poor response (~sec) till the driver is rmmodded.
>
> Checking the implementation with native Xilinx example timer application
> works fine, provided the Xilinx exception handling is implemented.
>
> Its not clear for me whether on ppc environment something specific must
> be done for custom interrupts, though implementation of
> xilinx_enet/xilinx_uartlite does not hint for something specific.
>
>
> sincerely
>
> eckart goehler
>
>
> -----------------------------------------------------------------(snip)
>
> // driver snippet that reacts on timer interrupts:
>
> // timer\interrupt base addresses, modified by ioremap:
> unsigned long timer_base, interrupt_base;
>
>
> /* interrupt handler: */
> static
> void drv_interrupt_handler(int irq, void *dev_id, struct pt_regs *regs)
> {
> printk(KERN_INFO DEVICE_NAME "interrupt occurred\n");
Most probably you should clear the interrupt source here.
Otherwise you could get back into the interrupt handler as
soon as you return from it due to the interrupt request still
being active.
> }
>
>
>
> static int __init drv_init_module(void)
> {
>
> interrupt_base = (unsigned long)
> ioremap(XPAR_INTC_BASEADDR,XPAR_INTC_HIGHADDR-XPAR_INTC_BASEADDR);
> timer_base = (unsigned long)
> ioremap(XPAR_TIMER_BASEADDR,XPAR_TIMER_HIGHADDR-XPAR_TIMER_BASEADDR);
>
> // install interrupt handler:
> if (request_irq(DRV_IRQ, commdrv_interrupt_handler,
> 0, DEVICE_NAME, NULL)
> )
You call request_irq() (i.e. unmask this interrupt) too early.
Configure the timer first.
> {
> printk(KERN_INFO DEVICE_NAME ": can¢t get assigned irq %i\n",
> COMM_IRQ
> );
> }
> else { /* enable interrupt */
>
> printk(KERN_INFO DEVICE_NAME ": interrupt installed\n");
>
> /* Start the interrupt controller */
> XIntc_mMasterEnable(interrupt_base);
- must not be used in the driver
> // here: enable timer interrupt:
> /* Set the number of cycles the timer counts before interrupting */
> XTmrCtr_mSetLoadReg(timer_base, 0, TIMER_VALUE * 80000000l);
>
>
> printk(KERN_INFO DEVICE_NAME ": clear timer\n");
>
> /* Reset the timers, and clear interrupts */
> XTmrCtr_mSetControlStatusReg(timer_base, 0, XTC_CSR_INT_OCCURED_MASK
> | XTC_CSR_LOAD_MASK );
>
> printk(KERN_INFO DEVICE_NAME ": enable interrupt\n");
>
> /* Enable timer interrupts in the interrupt controller */
>
> XIntc_mEnableIntr(interrupt_base, DRV_IRQ_MASK);
- must not be used in the driver. Unmasking the interrupt is done inside request_irq().
> //printk(KERN_INFO DEVICE_NAME ": start timer\n");
> /* Start the timers */
> XTmrCtr_mSetControlStatusReg(timer_base, 0, XTC_CSR_ENABLE_TMR_MASK
> | XTC_CSR_ENABLE_INT_MASK
> | XTC_CSR_AUTO_RELOAD_MASK |
> XTC_CSR_DOWN_COUNT_MASK);
>
> }
> }
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ 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