* Re: Not coherent cache DMA for G3/G4 CPUs: clarification needed
From: Mark A. Greer @ 2006-04-24 19:21 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <1468.1145570898@www002.gmx.net>
On Fri, Apr 21, 2006 at 12:08:18AM +0200, Gerhard Pircher wrote:
> > --- Ursprüngliche Nachricht ---
> > Von: Eugene Surovegin <ebs@ebshome.net>
> > An: Gerhard Pircher <gerhard_pircher@gmx.net>
> > Kopie: linuxppc-dev@ozlabs.org, debian-powerpc@lists.debian.org
> > Betreff: Re: Not coherent cache DMA for G3/G4 CPUs: clarification needed
> > Datum: Thu, 20 Apr 2006 14:55:14 -0700
> >
> > Well, you aren't the first person who tries to run G4 with
> > CONFIG_NOT_COHERENT_CACHE. This was done before and I don't remember
> > that those people had to implement anything as complex as you are
> > trying to do.
>
> Maybe these systems have cache coherent northbridges, which is not the case
> for the AmigaOne and its "famous" ArticiaS northbridge.
Nope. I believe Eugene is referring to the Marvell 64x60 line of *North*
bridges.
> > You can try asking on #mklinux. It always better to ask people who
> > actually _did_ this :).
> >
> > In fact, I just grepped 2.6 and found
> > #ifdef(CONFIG_NOT_COHERENT_CACHE) in syslib/mv64x60.c. Guess what
> > systems usually have this type of bridge? Not 4xx/8xx, that's for sure.
>
> Hmm, strange. AFAIK the NOT_COHERENT_CACHE config option is available only
> for the 4xx and 8xx platforms. Wouldn't the config option depend on
> CONFIG_6XX too, if there are not cache coherent systems with G4 cpus?
>
> At least I could not compile in the dma-mapping.c file without modifying the
> Kconfig file.
If you're looking in arch/ppc/Kconfig in either the kernel.org or paulus'
git trees, look further down. There is a separate option where
NOT_COHERENT_CACHE can be set for 64x60 bridges.
Mark
^ permalink raw reply
* Re: [PATCH] DTC - validation by device_type
From: Paul Nasrat @ 2006-04-24 19:09 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org, Jon Loeliger
In-Reply-To: <1145547307.5314.118.camel@cashmere.sps.mot.com>
On Thu, 2006-04-20 at 10:35 -0500, Jon Loeliger wrote:
> On Tue, 2006-03-28 at 20:33, Paul Nasrat wrote:
>
> > Signed-off-by: Paul Nasrat <pnasrat@redhat.com>
>
> Paul,
>
> Sorry about the hang-time here. Couple questions.
>
>
> > +static int check_network(struct node *net)
> > +{
> > +
> > + int ok = 1;
> > + struct property *prop;
> > +
> > + CHECK_HAVE(net, "reg");
> > + CHECK_HAVE(net, "local-mac-address");
> > + CHECK_HAVE(net, "mac-address");
> > + CHECK_HAVE(net, "address-bits");
> > +
> > + return ok;
> > +}
>
> This says that all network nodes have to have all four
> of those properties. It's not clear to me that they all
> need to have both local-mac-address and mac-address.
> Specifically, 1275 seems to indicate to me that the
> mac-address property, being introduced by the open
> operation, might be dynamically set at run time, rather
> than passed as a config parameter from, say, U-Boot to
> the kernel. Thus, it might not be necessary here.
1275 defines shall to indicate a mandatory requirement.
p.165 (Annexe A) defines "network" device_type:
A standard package with this "device_type" property shall implement the
following methods:
open, ...
Requirements for open method:
Execute mac-address and create a "mac-address" property with that value.
...
A standard package with this "device_type" property shall implement the
following property if the associated device has a preassigned IEEE 802.3
MAC (network) address:
So for flattened device tree my reading would be something like:
local-mac-address - for the most part this would be compulsory - does
anyone have any cases where a device would not have a preassigned MAC
address? Use of address in the booting-without-of and example should be
replaced by local-mac-address.
For a standard 1275 tree mac-address would be created on open, obviously
this isn't a hard requirement for compatibility so I think we could make
this optional.
Paul
^ permalink raw reply
* Re: 85xx FDT updates?
From: Vitaly Bordug @ 2006-04-24 19:04 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <1145900516.4251.18.camel@cashmere.sps.mot.com>
On Mon, 24 Apr 2006 12:41:56 -0500
Jon Loeliger <jdl@freescale.com> wrote:
> OK, so what is the deal with the 85xx patches
> that have been submitted for more FDT support?
> I get a variety of mixed stories, message and
> vague comments. I want some facts and direction.
>
> Can anyone verify, validate, refute, deny or
> support any of these statements? Not trying to
> be mean, point fingers or sound negative here,
> I'm just trying to pinpoint the apparent log-jam.
>
>
> 1. The 85xx patches that Andy submitted, that
> have been pulled into Kumar's 85xx git tree
> are going to sit there until further patches
> are submitted that _remove_all_85xx_support_
> from the arch/ppc tree as well.
>
> 2. The same patches are going to sit in Kumar's
> tree until 8560 patches with support for CPM
> are released and all 85xx ports appear fully
> and completely in arch/powerpc. BTW, CPM is
> waiting on approval of Vitaly's CPM proposal
> for OF FDT support.
>
> 3. Statements 1 and 2 combined.
>
That's my understanding. We agreed to have the CPM dts that is limited to "devices" only,
(scc, fcc or ucc) inside it.
Right now I am in process of update the drivers part (yet keeping compatibility with existing ppc stuff, that is tricky), then I am going to rework immap stuff a bit to utilize the parts that are common across the PQ family, and go ahead with some CPM(2) code to powerpc.
> 4. The same 85xx patches have just slipped through
> some mental crack and simply need to be pulled,
> re-applied, re-drafted, re-submitted. Oops, sorry.
> The action item is in _________'s lap.
>
> 5. There was an unresolved comment/issue that
> FSL still needs to address. BTW, that issue
> is ________.
>
> 6. We are waiting on something else and that
> item is _______.
>
Well, as already mentioned, the CPM2-related drivers the way they are could not be utilized in powerpc
sane way. Thankfully, the update is 90% ready right now.
> 7. You know, you really need to address the _other_
> 85xx ports (such as TQMs) as well. Can you
> please do something about those as well?
>
> 8. These Linux patches aren't going to be picked
> up until the corresponding U-Boot patches are
> picked up as well.
>
> Thanks,
> jdl
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: PPC exception 0x320
From: Becky Bruce @ 2006-04-24 18:55 UTC (permalink / raw)
To: jeanwelly; +Cc: linuxppc-embedded@ozlabs.org
In-Reply-To: <200604242151091399377@126.com>
Could you try to be more specific? What processor do you have, what =20
linux version are you running, and what do you mean exactly when you =20
say you "encountered PPC exception 0x320"? As far as I know, the =20
powerpc architecture does not define an exception 0x320. 0x300 is =20
usually DSI on classic powerpc parts. BookE parts handle things =20
differently.
Thanks,
-Becky
On Apr 24, 2006, at 8:51 AM, jeanwelly wrote:
> Hi,
> I encountered PPC exception 0x320, but don't know what it for. Any =20
> one could help me on this?
> Thanks!
> =09
>
> =E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80=
jeanwelly
> =E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80=
jeanwelly@126.com
> =E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80=
=E3=80=80=E3=80=802006-04-24
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* 85xx FDT updates?
From: Jon Loeliger @ 2006-04-24 17:41 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
OK, so what is the deal with the 85xx patches
that have been submitted for more FDT support?
I get a variety of mixed stories, message and
vague comments. I want some facts and direction.
Can anyone verify, validate, refute, deny or
support any of these statements? Not trying to
be mean, point fingers or sound negative here,
I'm just trying to pinpoint the apparent log-jam.
1. The 85xx patches that Andy submitted, that
have been pulled into Kumar's 85xx git tree
are going to sit there until further patches
are submitted that _remove_all_85xx_support_
from the arch/ppc tree as well.
2. The same patches are going to sit in Kumar's
tree until 8560 patches with support for CPM
are released and all 85xx ports appear fully
and completely in arch/powerpc. BTW, CPM is
waiting on approval of Vitaly's CPM proposal
for OF FDT support.
3. Statements 1 and 2 combined.
4. The same 85xx patches have just slipped through
some mental crack and simply need to be pulled,
re-applied, re-drafted, re-submitted. Oops, sorry.
The action item is in _________'s lap.
5. There was an unresolved comment/issue that
FSL still needs to address. BTW, that issue
is ________.
6. We are waiting on something else and that
item is _______.
7. You know, you really need to address the _other_
85xx ports (such as TQMs) as well. Can you
please do something about those as well?
8. These Linux patches aren't going to be picked
up until the corresponding U-Boot patches are
picked up as well.
Thanks,
jdl
^ permalink raw reply
* alignment exceptionhandler sleeps in invalid context
From: Olaf Hering @ 2006-04-24 17:32 UTC (permalink / raw)
To: linuxppc-dev
I'm not sure where the bug is. Does it mean the network stack does
something nasty, or is the exception handler itself broken? (probably the latter)
This is 2.6.16.9 on a p270.
<3>Debug: sleeping function called from invalid context at arch/powerpc/kernel/align.c:440
<4>in_atomic():1, irqs_disabled():0
<4>Call Trace:
<4>[C00000000FFE6D10] [C00000000000EE20] .show_stack+0x68/0x1b0 (unreliable)
<4>[C00000000FFE6DB0] [C000000000054248] .__might_sleep+0xd8/0xf4
<4>[C00000000FFE6E30] [C00000000000C490] .fix_alignment+0x50c/0x9c8
<4>[C00000000FFE6F10] [C000000000024E20] .alignment_exception+0x18/0xc8
<4>[C00000000FFE6F90] [C00000000000430C] alignment_common+0x10c/0x180
<4>--- Exception: 600 at .csum_partial+0x34/0x9c
<4> LR = .skb_checksum+0x194/0x35c
<4>[C00000000FFE7280] [D00000000033F3D0] 0xd00000000033f3d0 (unreliable)
<4>[C00000000FFE7340] [C0000000002EB558] .skb_checksum_help+0x98/0x124
<4>[C00000000FFE73D0] [D000000000330748] .ip_nat_fn+0x84/0x278 [iptable_nat]
<4>[C00000000FFE7490] [D000000000330C34] .ip_nat_local_fn+0x40/0xec [iptable_nat]
<4>[C00000000FFE7520] [C00000000030DAE0] .nf_iterate+0x80/0x11c
<4>[C00000000FFE75E0] [C00000000030DEC8] .nf_hook_slow+0x8c/0x17c
<4>[C00000000FFE76B0] [C00000000031D2B0] .ip_queue_xmit+0x4bc/0x5d0
<4>[C00000000FFE7800] [C00000000032FBA0] .tcp_transmit_skb+0x7d8/0x844
<4>[C00000000FFE78B0] [C0000000003318F0] .__tcp_push_pending_frames+0x2d4/0x3fc
<4>[C00000000FFE7970] [C00000000032EAD4] .tcp_rcv_established+0x894/0x964
<4>[C00000000FFE7A20] [C0000000003355C8] .tcp_v4_do_rcv+0x5c/0x48c
<4>[C00000000FFE7AF0] [C000000000338A48] .tcp_v4_rcv+0xc78/0xcfc
<4>[C00000000FFE7BC0] [C000000000316310] .ip_local_deliver+0x208/0x36c
<4>[C00000000FFE7C50] [C000000000316024] .ip_rcv+0x600/0x6e4
<4>[C00000000FFE7CF0] [C0000000002EBB34] .netif_receive_skb+0x500/0x598
<4>[C00000000FFE7D90] [C0000000002EE37C] .process_backlog+0xcc/0x1c8
<4>[C00000000FFE7E40] [C0000000002EE55C] .net_rx_action+0xe4/0x230
<4>[C00000000FFE7EF0] [C000000000066524] .__do_softirq+0x98/0x164
<4>[C00000000FFE7F90] [C000000000025854] .call_do_softirq+0x14/0x24
<4>[C0000003BA3C3370] [C00000000000BCC8] .do_softirq+0x8c/0xd8
<4>[C0000003BA3C3400] [C0000000000663E4] .local_bh_enable+0x58/0x8c
<4>[C0000003BA3C3480] [C0000000002EEA34] .dev_queue_xmit+0x2f0/0x318
<4>[C0000003BA3C3510] [C00000000031CA60] .ip_output+0x348/0x3f0
<4>[C0000003BA3C35B0] [C00000000031D2E0] .ip_queue_xmit+0x4ec/0x5d0
<4>[C0000003BA3C3700] [C00000000032FBA0] .tcp_transmit_skb+0x7d8/0x844
<4>[C0000003BA3C37B0] [C0000000003231A8] .tcp_cleanup_rbuf+0x148/0x168
<4>[C0000003BA3C3840] [C000000000325B24] .tcp_recvmsg+0x8a8/0xa00
<4>[C0000003BA3C3930] [C0000000002E0C64] .sock_common_recvmsg+0x5c/0x84
<4>[C0000003BA3C39C0] [C0000000002DD408] .do_sock_read+0x120/0x14c
<4>[C0000003BA3C3A60] [C0000000002DF034] .sock_aio_read+0x58/0x74
<4>[C0000003BA3C3B70] [C0000000000C6050] .do_sync_read+0xd4/0x130
<4>[C0000003BA3C3CF0] [C0000000000C6ECC] .vfs_read+0x134/0x1fc
<4>[C0000003BA3C3D90] [C0000000000C7390] .sys_read+0x4c/0x8c
<4>[C0000003BA3C3E30] [C00000000000871C] syscall_exit+0x0/0x40
^ permalink raw reply
* Re: [PATCH 1/2] tickless idle cpus: core patch - v2
From: Srivatsa Vaddagiri @ 2006-04-24 15:39 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17480.47308.126194.26202@cargo.ozlabs.ibm.com>
Paul,
At the outset I am slightly confused on whether you are
proposing to allow boot cpus to skip ticks or not. A clarification on
this will help!
On Fri, Apr 21, 2006 at 08:49:48PM +1000, Paul Mackerras wrote:
> Is the nohz_cpu_mask accessed by other cpus? I wonder if using a
Yes, nohz_cpu_mask can be accessed by other CPUs, as part of RCU batch
processing.
> 1-byte per-cpu variable for this, or even a bit in the thread_info
> struct, might be better because it would reduce the number of atomic
> bit set/clear operations we have to do.
Agreed that updating a global bitmask is not a scalable thing to do. But
unfortunately this is tied to RCU implementation ATM. I know that Dipankar has
plans to get rid of nohz_cpu_mask in the RCU implementation. When that happens,
maybe we can revist this.
> > +#define MAX_DEC_COUNT UINT_MAX /* Decrementer is 32-bit */
>
> The decrementer value should be restricted to INT_MAX. I think some
> implementations will take a decrementer interrupt if you set the
> decrementer to a negative value.
Ok. Thanks for pointing it out.
> > +static void account_ticks(struct pt_regs *regs)
> > +{
> > + int next_dec;
> > + int cpu = smp_processor_id();
> > + unsigned long ticks;
> > +
> > while ((ticks = tb_ticks_since(per_cpu(last_jiffy, cpu)))
> > >= tb_ticks_per_jiffy) {
> > /* Update last_jiffy */
>
> This is just the loop body from timer_interrupt, right? Why do we
Correct. Note that this loop body is common to both timer_interrupt and
start_hz_timer currently.
> have to loop around N times after we skipped N ticks? What we're
> doing inside the loop is:
>
> - account_process_time, but we know we were in the idle task, so the
> time is just idle time. If we have the accurate accounting stuff
> turned on the first call to account_process_time will account all
> the idle time anyway.
Do you mean to say that "the first call to account_system_vtime will account
all the idle time"? AFAICS account_process_time (->account_process_vtime) is
accounting just usertime.
I had a related question: if we put the idle CPU to some power-saving
state in the period that it is tickless, would its PURR value keep
getting incremented? If not, would that affect the idle time we
calculate after skipping N ticks (in case accurate acct is turned ON
that is)?
> - we're not skipping ticks on the boot cpu (yet), so we won't do the
> do_timer and timer_recalc_offset calls.
Don't follow you here. I thought we wanted to let the boot cpu to skip
ticks too (as you seem to indicate down below - while talking of
updating xtime/NTP)? If we want to allow that, then we need to be able to
call do_timer with a regs argument?
> I think we could probably rearrange this code to eliminate the need
> for the regs argument - all it's used for is telling whether we were
> in user mode, and we know we weren't since we were in the idle task.
> That would mean that we maybe could call start_hz_timer from the idle
> task body instead of inside do_IRQ etc. The only thing we'd have to
> watch out for is updating the decrementer if some interrupt handler
> called add_timer/mod_timer etc.
One problem in deferring the call to start_hz_timer like this is RCU. Ideally
we want to clear the tickless idle-CPU from nohz_cpu_mask -as soon- as it
starts processing an interrupt. Otherwise RCU will think that the CPU is in
tickless state (hence not accessing RCU-protected data structures) while the
idle-CPU is processing interrupts/softirqs and will not include the CPU in its
grace-period processing. This may be a bad thing to allow.
The other problem in deferring a call to start_hz_timer is we could cause them
to be running with an incorrect jiffy value (can happen if all cpus were
skipping ticks for a period).
IMO we should let start_hz_timer be called as it is being called now, i.e
immediately when a tickless idle-CPU wakes up. This would also
unfortunately mean that we need to embed calls to start_hz_timer from all
the interrupt paths (do_IRQ, performance_monitor_exception etc) where we
come out of tickless state.
> Assuming we make the changes we have discussed to reduce the skewing
> of the decrementer interrupts quite small, and allow any cpu to call
> do_timer, then how where you thinking that xtime and the NTP stuff
> would get updated, in the situation where all cpus are skipping ticks?
> By doing N calls to do_timer in a row? Or by adding N-1 to jiffies_64
> and then calling do_timer once?
I assume this implies we want to let boot-cpu to skip ticks?
Ideally it would be good if we add N-1 to jiffies_64 and call do_timer
once. But I wonder if it can be done w/o being racy. In order to calculate
N, we may calculate the difference, delta, between current timebase and
tb_last_stamp as:
delta = tb_ticks_since(tb_last_stamp); -> Step 1
We may then calculate N as:
N = delta / tb_ticks_per_jiffy; -> Step 2
However this will be racy, if we happen to sample timebase (Step 1) just
before a jiffy boundary. In which case, we would have missed to update
jiffy by 1? To avoid this, we may need to check for the corner case and
introduce a 'goto retry' loop?
BTW, I realized that my patch to let boot cpu to skip ticks also is
slightly buggy here:
if (cpu != do_timer_cpu)
continue;
write_seqlock(&xtime_lock);
...
do_timer(regs);
...
write_sequnlock(&xtime_lock);
There needs to a different while loop to call do_timer based on
tb_ticks_since(tb_last_stamp). Will fix it next time around.
>
> > +#ifdef CONFIG_NO_IDLE_HZ
> > + max_skip = __USE_RTC() ? HZ : MAX_DEC_COUNT / tb_ticks_per_jiffy;
> > +#endif
>
> If we allow the boot cpu to skip ticks, then we will have to make sure
> that at least one cpu wakes up in time to do the updating in
> recalc_timer_offset.
Good point. However is this critical, especially if all cpus had been
idle for quite a while? As I understand, if we don't wakeup in time to
do timer_recalc_offset, the only drawback is the first gettimeofday will
be slow (because it has make a system call)?
--
Regards,
vatsa
^ permalink raw reply
* PPC exception 0x320
From: jeanwelly @ 2006-04-24 13:51 UTC (permalink / raw)
To: linuxppc-embedded@ozlabs.org
SGksDQpJIGVuY291bnRlcmVkIFBQQyBleGNlcHRpb24gMHgzMjAsIGJ1dCBkb24ndCBrbm93IHdo
YXQgaXQgZm9yLiBBbnkgb25lIGNvdWxkIGhlbHAgbWUgb24gdGhpcz8NClRoYW5rcyENCiAJCQkJ
DQoNCqGhoaGhoaGhoaGhoaGhoaFqZWFud2VsbHkNCqGhoaGhoaGhoaGhoaGhoaFqZWFud2VsbHlA
MTI2LmNvbQ0KoaGhoaGhoaGhoaGhoaGhoaGhoaEyMDA2LTA0LTI0DQo=
^ permalink raw reply
* Re: question about Linux 2.6 with Xilinx ML-403
From: Andrei Konovalov @ 2006-04-24 12:32 UTC (permalink / raw)
To: Chang Sun; +Cc: linuxppc-embedded, Martin, Tim
In-Reply-To: <0AF7A30943B8EF42B5A41B51B30BE52C0197306B@XSJ-EXCHVS1.xlnx.xilinx.com>
Chang Sun wrote:
> Grant,
> I checked both Torvalds' tree and Paul's tree. I see the defconfig file
> for both ml300 and ml403, but I don't see any source files related to
> either ml300 or ml403 under the <platforms> subdirectory. Have you done
> a complete BSP for either ml300 or ml403?
>
> Thanks,
> Chang
arch/ppc/platforms/4xx/virtex.c
arch/ppc/platforms/4xx/virtex.h
arch/ppc/platforms/4xx/xilinx_ml300.c
arch/ppc/platforms/4xx/xilinx_ml300.h
arch/ppc/platforms/4xx/xilinx_ml403.c
arch/ppc/platforms/4xx/xilinx_ml403.h
These are in the both trees you've mentioned.
Regards,
Andrei
^ permalink raw reply
* Re: modules without a .toc section not loading
From: Alan Modra @ 2006-04-24 12:41 UTC (permalink / raw)
To: Robin H. Johnson; +Cc: linuxppc-dev
In-Reply-To: <20060423035614.GB30578@curie-int.vc.shawcable.net>
On Sat, Apr 22, 2006 at 08:56:14PM -0700, Robin H. Johnson wrote:
> On Thu, Apr 20, 2006 at 06:24:01PM +0930, Alan Modra wrote:
> > > I dug at the code, and the R_PPC_REL24 blocks need the contents of the
> > > .toc (via stub_for_addr -> create_stub -> my_r2), and I'm not certain
> > > about it.
> > Yes, the stubs need some reasonable r2 value.
> Using the .stubs values for the .toc seems to work, but I should
> construct a better test case for it, to double check.
>
> > > The R_PPC64_TOC/R_PPC64_TOC16/R_PPC64_TOC16_DS blocks shouldn't be hit
> > > when there isn't a .toc* from what I figure.
> > Yes, and finding such a reloc should trigger an error.
> Ok, there is a case where R_PPC64_TOC exists and there isn't a .toc, and
> I suspect you're just the right person to ask...
Oops. R_PPC64_TOC without a toc isn't an error, despite it looking
self-contradictory.
[snip about R_PPC64_TOC in .opd]
> It seems that these R_PPC64_TOC entries are safe to completely ignore -
> is this correct?
They are the toc pointer value used by functions defined in the module.
Since we are using .stubs+0x8000, that should be the value of these
relocs. There may be situations where the opd entry escapes out of
the module as a function pointer (eg. via an initialised global function
pointer variable), so we'd better set them to the correct value.
In fact, it probably isn't worth doing error checking of any of the
R_PPC64_TOC* relocs. If I hadn't tried to be fancy with error checks,
it seems my original patch would have been good. Oh well, revised patch
follows.
[snip]
> I have searched Google, but not actually found any documentation on what
> the format of the .opd section is supposed to be. LSB-3.1 just says it
> has to exist, without saying what it's format is.
First word is the function entry point, second word is the toc pointer
used by the function, third word is the static chain pointer (unused by
C, but used in languages like Pascal). Some Redhat compilers omit the
third word entirely, so opd entries may be either 16 bytes or 24 bytes
apart.
--
Alan Modra
IBM OzLabs - Linux Technology Centre
--- linux-2.6.16/arch/powerpc/kernel/module_64.c~ 2006-01-18 14:17:29.000000000 +1030
+++ linux-2.6.16/arch/powerpc/kernel/module_64.c 2006-04-24 22:01:19.000000000 +0930
@@ -191,11 +191,19 @@ int module_frob_arch_sections(Elf64_Ehdr
(void *)hdr
+ sechdrs[sechdrs[i].sh_link].sh_offset);
}
- if (!me->arch.stubs_section || !me->arch.toc_section) {
- printk("%s: doesn't contain .toc or .stubs.\n", me->name);
+
+ if (!me->arch.stubs_section) {
+ printk("%s: doesn't contain .stubs.\n", me->name);
return -ENOEXEC;
}
+ /* If we don't have a .toc, just use .stubs. We need to set r2
+ to some reasonable value in case the module calls out to
+ other functions via a stub, or if a function pointer escapes
+ the module by some means. */
+ if (!me->arch.toc_section)
+ me->arch.toc_section = me->arch.stubs_section;
+
/* Override the stubs size */
sechdrs[me->arch.stubs_section].sh_size = get_stubs_size(hdr, sechdrs);
return 0;
@@ -342,7 +350,7 @@ int apply_relocate_add(Elf64_Shdr *sechd
break;
case R_PPC64_TOC16:
- /* Subtact TOC pointer */
+ /* Subtract TOC pointer */
value -= my_r2(sechdrs, me);
if (value + 0x8000 > 0xffff) {
printk("%s: bad TOC16 relocation (%lu)\n",
@@ -355,7 +363,7 @@ int apply_relocate_add(Elf64_Shdr *sechd
break;
case R_PPC64_TOC16_DS:
- /* Subtact TOC pointer */
+ /* Subtract TOC pointer */
value -= my_r2(sechdrs, me);
if ((value & 3) != 0 || value + 0x8000 > 0xffff) {
printk("%s: bad TOC16_DS relocation (%lu)\n",
^ permalink raw reply
* linux 2.4.25: loading usbcore.o gives segmentation fault
From: Josef Angermeier @ 2006-04-24 12:06 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I am using linux 2.4.25 for a custom MPC875 based board. When adding
general usb support as module (-> usbcore.o), loading usbcore.o gives a
segmentation fault., while compiling it builtin seems to work. How can
i find out what could be the reasons for that ?
thanks in advance, best regards
Josef
^ permalink raw reply
* [PATCH] Reserve crashkernel memory region
From: Mohan Kumar M @ 2006-04-24 6:10 UTC (permalink / raw)
To: fastboot, linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 353 bytes --]
Hi,
Now kexec'ed kernel in a PPC64 machine does not reserve memory for crashkernel region. So kexec'ed kernel can not load kdump kernel reliably.
Attached kexec-tools patch reserves memory for kdump kernel by adding an entry in the reserve memory table. So while kexec'ed kernel is booting, it reserves memory for crashkernel region.
Regards,
Mohan.
[-- Attachment #2: reserve-crashkernel.patch --]
[-- Type: text/plain, Size: 6290 bytes --]
In PPC64, kexec'ed kernel does not reserve memory for crashkernel. So
kexec'ed kernel can not load kdump kernel reliably.
reserve-crashkernel-mem patch adds a reserve entry for crashkernel to the
reserve memory list, so that kexec'ed kernel reserves memory for kdump kernel.
This is done when user passes --append="crashkernel=X@Y" parameter to
kexec command. If user does not pass crashkernel option, memory is not
reserved for kdump kernel.
Signed-off-by: Mohan <mohan@in.ibm.com>
---
kexec-tools-1.101-kdump9/kexec/arch/ppc64/fs2dt.c | 135 ++++++++++++----
kexec-tools-1.101-kdump9/kexec/arch/ppc64/kexec-ppc64.h | 2
2 files changed, 107 insertions(+), 30 deletions(-)
diff -puN kexec-tools-1.101-kdump9/kexec/arch/ppc64/fs2dt.c~reserve-crashkernel kexec-tools-1.101-kdump9/kexec/arch/ppc64/fs2dt.c
--- patch/kexec-tools-1.101-kdump9/kexec/arch/ppc64/fs2dt.c~reserve-crashkernel 2006-04-19 18:49:06.000000000 +0530
+++ patch-mohan/kexec-tools-1.101-kdump9/kexec/arch/ppc64/fs2dt.c 2006-04-19 18:55:48.000000000 +0530
@@ -64,8 +64,7 @@ char propnames[NAMESPACE];
dvt dtstruct[TREEWORDS], *dt;
unsigned long long mem_rsrv[2*MEMRESERVE];
-static int initrd_found = 0;
-static int crash_param = 0;
+static unsigned long crashk_base = 0, crashk_size = 0;
char local_cmdline[COMMAND_LINE_SIZE] = { "" };
dvt *dt_len; /* changed len of modified cmdline in flat device-tree */
extern mem_rgns_t usablemem_rgns;
@@ -191,6 +190,50 @@ void add_usable_mem_property(int fd, int
dt += (rlen + 3)/4;
}
+unsigned long mem_parse(const char *ptr, const char **retptr)
+{
+ unsigned long ret = strtoul(ptr, (char **)retptr,10);
+
+ switch (**retptr) {
+ case 'G':
+ case 'g':
+ ret <<= 30;
+ (*retptr)++;
+ break;
+ case 'M':
+ case 'm':
+ ret <<= 20;
+ (*retptr)++;
+ break;
+ case 'K':
+ case 'k':
+ ret <<= 10;
+ (*retptr)++;
+ break;
+ }
+
+ return ret;
+}
+
+void parse_crash_param(char *param)
+{
+ char *cbase, *csize;
+ param += 12;
+ crashk_size = mem_parse(param, (const char **)&csize);
+
+ if (ALIGN(crashk_size, 0x1000000) != crashk_size)
+ printf("Warning: crashkernel size is not aligned to 16MB\n");
+
+ if (*csize == '@') {
+ csize++;
+ crashk_base = mem_parse(csize, (const char **)&cbase);
+ if (crashk_base != 0x2000000)
+ printf("Warning: PPC64 kdump kernel always runs at "
+ "32 MB\n");
+ }
+ crashk_base = 0x2000000;
+}
+
/* put all properties (files) in the property structure */
void putprops(char *fn, struct dirent **nlist, int numlist)
{
@@ -207,12 +250,6 @@ void putprops(char *fn, struct dirent **
if (lstat(pathname, statbuf))
err(pathname, ERR_STAT);
- if (!crash_param && !strcmp(fn,"linux,crashkernel-base"))
- continue;
-
- if (!crash_param && !strcmp(fn,"linux,crashkernel-size"))
- continue;
-
/*
* This property will be created for each node during kexec
* boot. So, ignore it.
@@ -230,6 +267,13 @@ void putprops(char *fn, struct dirent **
!strcmp(dp->d_name, "linux,initrd-end"))
continue;
+ /* This property will be created/modified later in putnode()
+ * So ignore it.
+ */
+ if (!strcmp(dp->d_name, "linux,crashkernel-base") ||
+ !strcmp(dp->d_name, "linux,crashkernel-size"))
+ continue;
+
if (S_ISREG(statbuf[0].st_mode)) {
int fd, len = statbuf[0].st_size;
@@ -260,7 +304,7 @@ void putprops(char *fn, struct dirent **
param = strstr(local_cmdline,
"crashkernel=");
if (param)
- crash_param = 1;
+ parse_crash_param(param);
param = strstr(local_cmdline, "root=");
}
if (!param) {
@@ -347,35 +391,66 @@ void putnode(void)
putprops(dn, namelist, numlist);
- /* Add initrd entries to the second kernel if first kernel does not
- * have and second kernel needs.
- */
- if (initrd_base && !initrd_found && !strcmp(basename,"/chosen/")) {
+ if (!strcmp(basename,"/chosen/")) {
int len = 8;
unsigned long long initrd_end;
- *dt++ = 3;
- *dt++ = len;
- *dt++ = propnum("linux,initrd-start");
- if ((len >= 8) && ((unsigned long)dt & 0x4))
- dt++;
+ /* Add initrd entries to the second kernel if first
+ * kernel does not have and second kernel needs.
+ */
+ if (initrd_base) {
+ *dt++ = 3;
+ *dt++ = len;
+ *dt++ = propnum("linux,initrd-start");
+
+ if ((len >= 8) && ((unsigned long)dt & 0x4))
+ dt++;
+
+ memcpy(dt,&initrd_base,len);
+ dt += (len + 3)/4;
+
+ len = 8;
+ *dt++ = 3;
+ *dt++ = len;
+ *dt++ = propnum("linux,initrd-end");
+
+ initrd_end = initrd_base + initrd_size;
+ if ((len >= 8) && ((unsigned long)dt & 0x4))
+ dt++;
+
+ memcpy(dt,&initrd_end,len);
+ dt += (len + 3)/4;
+
+ reserve(initrd_base, initrd_size);
+ }
+
+ /* Add crashkernel details to the second kernel if first
+ * kernel does not have and reserve memory for that
+ */
+ if (crashk_base) {
+ *dt++ = 3;
+ *dt++ = len;
+ *dt++ = propnum("linux,crashkernel-base");
- memcpy(dt,&initrd_base,len);
- dt += (len + 3)/4;
+ if ((len >= 8) && ((unsigned long)dt & 0x4))
+ dt++;
- len = 8;
- *dt++ = 3;
- *dt++ = len;
- *dt++ = propnum("linux,initrd-end");
+ memcpy(dt,&crashk_base,len);
+ dt += (len + 3)/4;
- initrd_end = initrd_base + initrd_size;
- if ((len >= 8) && ((unsigned long)dt & 0x4))
- dt++;
+ len = 8;
+ *dt++ = 3;
+ *dt++ = len;
+ *dt++ = propnum("linux,crashkernel-size");
+
+ if ((len >= 8) && ((unsigned long)dt & 0x4))
+ dt++;
- memcpy(dt,&initrd_end,len);
- dt += (len + 3)/4;
+ memcpy(dt,&crashk_size,len);
+ dt += (len + 3)/4;
- reserve(initrd_base, initrd_size);
+ reserve(crashk_base, crashk_size);
+ }
}
for (i=0; i < numlist; i++) {
diff -puN kexec-tools-1.101-kdump9/kexec/arch/ppc64/kexec-ppc64.h~reserve-crashkernel kexec-tools-1.101-kdump9/kexec/arch/ppc64/kexec-ppc64.h
--- patch/kexec-tools-1.101-kdump9/kexec/arch/ppc64/kexec-ppc64.h~reserve-crashkernel 2006-04-19 18:49:54.000000000 +0530
+++ patch-mohan/kexec-tools-1.101-kdump9/kexec/arch/ppc64/kexec-ppc64.h 2006-04-19 18:50:29.000000000 +0530
@@ -7,6 +7,8 @@
#define CORE_TYPE_ELF32 1
#define CORE_TYPE_ELF64 2
+#define ALIGN(val,align) (((val) + ((align) - 1)) & ~((align) - 1))
+
int setup_memory_ranges(unsigned long kexec_flags);
int elf_ppc64_probe(const char *buf, off_t len);
_
^ permalink raw reply
* sns-aoa more PM
From: Benjamin Herrenschmidt @ 2006-04-24 3:00 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list
(resending including the list in case somebody else is interested :)
Hi Johannes. The patch below adds mute of amps along with other changes.
In random order:
- Removed the sound_bus list that seemed useless to me and use the
normal "remove" mecanism to unregister the soundbus_dev from i2sbus. I
don't know if I ended up breaking something here, we'll have to check :)
We might need to test...
- Set proper parent so i2sbus created soundbus_dev hangs off macio-dev,
thus makes it get suspend/resume with proper ordering (that is suspend
before i2sbus and resume after).
- Renamed bits & pieces in layout fabric
- Add suspend/resume hooks to layout fabric to mure/restore amps
- Add code in onyx to restore all codec registers on wakeup
With that, I now get nicely working suspend/resume without "clacs" on my
onyx based laptop. I tried Amarok and it properly stops playing on
suspend and resumes on wakeup without a glitch.
my own little todo list:
- Cleanup printk junk, use dev_* for debug * info stuff etc...
- Look into i2s probing issues (resources on some macs etc...)
- i2s has a weird address in macio node in the device-tree, look at
this
- Get TAS working on dual g5
- Do some basic topaz for dual g5
- do a pre-layout fabric for snapper/tumbler/daca
- whatever ...
diff -urN snd-aoa/aoa/codecs/onyx/snd-aoa-codec-onyx.c snd-aoa.ben/aoa/codecs/onyx/snd-aoa-codec-onyx.c
--- snd-aoa/aoa/codecs/onyx/snd-aoa-codec-onyx.c 2006-04-07 21:22:59.000000000 +1000
+++ snd-aoa.ben/aoa/codecs/onyx/snd-aoa-codec-onyx.c 2006-04-24 12:08:00.000000000 +1000
@@ -616,10 +616,32 @@
case CLOCK_SWITCH_SLAVE:
onyx->codec.gpio->methods->all_amps_restore(onyx->codec.gpio);
break;
+ default: /* silence warning */
+ break;
}
return 0;
}
+#ifdef CONFIG_PM
+
+static int onyx_suspend(struct codec_info_item *cii, pm_message_t state)
+{
+ /* TODO */
+
+ return 0;
+}
+
+static int onyx_resume(struct codec_info_item *cii)
+{
+ struct onyx *onyx = cii->codec_data;
+
+ onyx_register_init(onyx);
+
+ return 0;
+}
+
+#endif /* CONFIG_PM */
+
static struct codec_info onyx_codec_info = {
.transfers = onyx_transfers,
.sysclock_factor = 256,
@@ -630,6 +652,10 @@
.open = onyx_open,
.close = onyx_close,
.switch_clock = onyx_switch_clock,
+#ifdef CONFIG_PM
+ .suspend = onyx_suspend,
+ .resume = onyx_resume,
+#endif
};
static int onyx_init_codec(struct aoa_codec *codec)
diff -urN snd-aoa/aoa/fabrics/snd-aoa-fabric-layout.c snd-aoa.ben/aoa/fabrics/snd-aoa-fabric-layout.c
--- snd-aoa/aoa/fabrics/snd-aoa-fabric-layout.c 2006-04-07 21:22:59.000000000 +1000
+++ snd-aoa.ben/aoa/fabrics/snd-aoa-fabric-layout.c 2006-04-24 11:51:15.000000000 +1000
@@ -225,14 +225,18 @@
struct snd_ctl_elem_value *ucontrol) \
{ \
struct gpio_runtime *gpio = snd_kcontrol_chip(kcontrol); \
- ucontrol->value.integer.value[0] = gpio->methods->get_##n(gpio);\
+ if (gpio->methods && gpio->methods->get_##n) \
+ ucontrol->value.integer.value[0] = \
+ gpio->methods->get_##n(gpio); \
return 0; \
} \
static int n##_control_put(struct snd_kcontrol *kcontrol, \
struct snd_ctl_elem_value *ucontrol) \
{ \
struct gpio_runtime *gpio = snd_kcontrol_chip(kcontrol); \
- gpio->methods->set_##n(gpio, ucontrol->value.integer.value[0]); \
+ if (gpio->methods && gpio->methods->get_##n) \
+ gpio->methods->set_##n(gpio, \
+ ucontrol->value.integer.value[0]); \
return 1; \
} \
static struct snd_kcontrol_new n##_ctl = { \
@@ -328,7 +332,7 @@
.remove_codec = layout_remove_codec,
};
-static int soundbus_probe(struct soundbus_dev *sdev)
+static int aoa_fabric_layout_probe(struct soundbus_dev *sdev)
{
struct device_node *sound = NULL;
unsigned int *layout_id;
@@ -401,7 +405,7 @@
return -ENODEV;
}
-static int soundbus_remove(struct soundbus_dev *sdev)
+static int aoa_fabric_layout_remove(struct soundbus_dev *sdev)
{
struct layout_dev *ldev = sdev->ofdev.dev.driver_data;
int i;
@@ -423,11 +427,39 @@
return 0;
}
+static int aoa_fabric_layout_suspend(struct soundbus_dev *sdev, pm_message_t state)
+{
+ struct layout_dev *ldev = sdev->ofdev.dev.driver_data;
+
+ printk("aoa_fabric_layout_suspend()\n");
+
+ if (ldev->gpio.methods && ldev->gpio.methods->all_amps_off)
+ ldev->gpio.methods->all_amps_off(&ldev->gpio);
+
+ return 0;
+}
+
+static int aoa_fabric_layout_resume(struct soundbus_dev *sdev)
+{
+ struct layout_dev *ldev = sdev->ofdev.dev.driver_data;
+
+ printk("aoa_fabric_layout_resume()\n");
+
+ if (ldev->gpio.methods && ldev->gpio.methods->all_amps_off)
+ ldev->gpio.methods->all_amps_restore(&ldev->gpio);
+
+ return 0;
+}
+
static struct soundbus_driver aoa_soundbus_driver = {
.name = "snd_aoa_soundbus_drv",
.owner = THIS_MODULE,
- .probe = soundbus_probe,
- .remove = soundbus_remove,
+ .probe = aoa_fabric_layout_probe,
+ .remove = aoa_fabric_layout_remove,
+#ifdef CONFIG_PM
+ .suspend = aoa_fabric_layout_suspend,
+ .resume = aoa_fabric_layout_resume,
+#endif
};
int __init aoa_fabric_layout_init(void)
diff -urN snd-aoa/soundbus/core.c snd-aoa.ben/soundbus/core.c
--- snd-aoa/soundbus/core.c 2006-03-31 07:56:03.000000000 +1100
+++ snd-aoa.ben/soundbus/core.c 2006-04-24 11:45:59.000000000 +1000
@@ -173,6 +173,8 @@
drv->shutdown(soundbus_dev);
}
+#ifdef CONFIG_PM
+
static int soundbus_device_suspend(struct device *dev, pm_message_t state)
{
struct soundbus_dev * soundbus_dev = to_soundbus_device(dev);
@@ -193,6 +195,8 @@
return 0;
}
+#endif /* CONFIG_PM */
+
extern struct device_attribute soundbus_dev_attrs[];
static struct bus_type soundbus_bus_type = {
@@ -201,8 +205,10 @@
.uevent = soundbus_uevent,
.remove = soundbus_device_remove,
.shutdown = soundbus_device_shutdown,
+#ifdef CONFIG_PM
.suspend = soundbus_device_suspend,
.resume = soundbus_device_resume,
+#endif
.dev_attrs = soundbus_dev_attrs,
};
@@ -216,37 +222,30 @@
bus_unregister(&soundbus_bus_type);
}
-int soundbus_device_add(struct soundbus_dev *dev)
+int soundbus_add_one(struct soundbus_dev *dev)
{
static int devcount;
/* sanity checks */
if (!dev->attach_codec ||
!dev->ofdev.node ||
- !dev->bus ||
dev->pcmname ||
dev->pcmid != -1) {
printk(KERN_ERR "soundbus: adding device failed sanity check!\n");
return -EINVAL;
}
- list_add(&dev->onbuslist, &dev->bus->devices);
-
snprintf(dev->ofdev.dev.bus_id, BUS_ID_SIZE, "soundbus:%x", ++devcount);
dev->ofdev.dev.bus = &soundbus_bus_type;
return of_device_register(&dev->ofdev);
}
-EXPORT_SYMBOL_GPL(soundbus_device_add);
+EXPORT_SYMBOL_GPL(soundbus_add_one);
-void soundbus_unregister_soundbus(struct sound_bus *soundbus)
+void soundbus_remove_one(struct soundbus_dev *dev)
{
- struct soundbus_dev *dev, *tmp;
-
- list_for_each_entry_safe(dev, tmp, &soundbus->devices, onbuslist) {
- of_device_unregister(&dev->ofdev);
- }
+ of_device_unregister(&dev->ofdev);
}
-EXPORT_SYMBOL_GPL(soundbus_unregister_soundbus);
+EXPORT_SYMBOL_GPL(soundbus_remove_one);
int soundbus_register_driver(struct soundbus_driver *drv)
{
diff -urN snd-aoa/soundbus/i2sbus/i2sbus-core.c snd-aoa.ben/soundbus/i2sbus/i2sbus-core.c
--- snd-aoa/soundbus/i2sbus/i2sbus-core.c 2006-04-24 11:01:30.000000000 +1000
+++ snd-aoa.ben/soundbus/i2sbus/i2sbus-core.c 2006-04-24 12:01:30.000000000 +1000
@@ -33,9 +33,6 @@
{ }
};
-static struct sound_bus i2s_soundbus = {
-};
-
static int alloc_dbdma_descriptor_ring(struct i2sbus_dev *i2sdev,
struct dbdma_command_mem *r, int numcmds)
{
@@ -137,11 +134,10 @@
}
}
- dev->sound.bus = &i2s_soundbus;
dev->sound.ofdev.node = np;
dev->sound.ofdev.dma_mask = macio->ofdev.dma_mask;
dev->sound.ofdev.dev.dma_mask = &dev->sound.ofdev.dma_mask;
- dev->sound.ofdev.dev.parent = NULL;
+ dev->sound.ofdev.dev.parent = &macio->ofdev.dev;
dev->sound.ofdev.dev.release = i2sbus_release_dev;
dev->sound.attach_codec = i2sbus_attach_codec;
dev->sound.detach_codec = i2sbus_detach_codec;
@@ -190,7 +186,7 @@
if (alloc_dbdma_descriptor_ring(dev, &dev->in.dbdma_ring, MAX_DBDMA_COMMANDS))
goto err;
- if (soundbus_device_add(&dev->sound)) {
+ if (soundbus_add_one(&dev->sound)) {
printk(KERN_DEBUG "i2sbus: device registration error!\n");
goto err;
}
@@ -254,6 +250,9 @@
static int i2sbus_remove(struct macio_dev* dev)
{
+ struct i2sbus_dev* i2sdev = (struct i2sbus_dev*)dev->ofdev.dev.driver_data;
+ soundbus_remove_one(&i2sdev->sound);
+
return 0;
}
@@ -267,6 +266,8 @@
/* TODO: Notify fabric so that it can mute all amps */
+ printk("i2sbus_suspend()\n");
+
/* Notify Alsa */
if (i2sdev->sound.pcm) {
/* Suspend PCM streams */
@@ -289,6 +290,8 @@
struct i2sbus_dev* i2sdev = (struct i2sbus_dev*)dev->ofdev.dev.driver_data;
int err, ret = 0;
+ printk("i2sbus_resume()\n");
+
/* Notify codecs so they can re-initialize */
list_for_each_entry(cii, &i2sdev->sound.codec_list, list) {
err = 0;
@@ -332,13 +335,11 @@
static int __init soundbus_i2sbus_init(void)
{
- INIT_LIST_HEAD(&i2s_soundbus.devices);
return macio_register_driver(&i2sbus_drv);
}
static void __exit soundbus_i2sbus_exit(void)
{
- soundbus_unregister_soundbus(&i2s_soundbus);
macio_unregister_driver(&i2sbus_drv);
}
diff -urN snd-aoa/soundbus/soundbus.h snd-aoa.ben/soundbus/soundbus.h
--- snd-aoa/soundbus/soundbus.h 2006-04-16 10:44:24.000000000 +1000
+++ snd-aoa.ben/soundbus/soundbus.h 2006-04-24 11:46:06.000000000 +1000
@@ -12,12 +12,6 @@
#include <sound/pcm.h>
#include <linux/list.h>
-/*
- * the sound_bus structure is used to describe the virtual sound bus.
- */
-struct sound_bus {
- struct list_head devices;
-};
/* When switching from master to slave or the other way around,
* you don't want to have the codec chip acting as clock source
@@ -142,7 +136,6 @@
/* information on a soundbus device */
struct soundbus_dev {
/* the bus it belongs to */
- struct sound_bus *bus;
struct list_head onbuslist;
/* the of device it represents */
@@ -178,8 +171,8 @@
#define to_soundbus_device(d) container_of(d, struct soundbus_dev, ofdev.dev)
#define of_to_soundbus_device(d) container_of(d, struct soundbus_dev, ofdev)
-extern int soundbus_device_add(struct soundbus_dev *dev);
-extern void soundbus_unregister_soundbus(struct sound_bus *soundbus);
+extern int soundbus_add_one(struct soundbus_dev *dev);
+extern void soundbus_remove_one(struct soundbus_dev *dev);
extern struct soundbus_dev *soundbus_dev_get(struct soundbus_dev *dev);
extern void soundbus_dev_put(struct soundbus_dev *dev);
^ permalink raw reply
* RE: question about Linux 2.6 with Xilinx ML-403
From: Chang Sun @ 2006-04-23 19:00 UTC (permalink / raw)
To: Grant Likely, Martin, Tim; +Cc: linuxppc-embedded
Grant,=20
I checked both Torvalds' tree and Paul's tree. I see the defconfig file
for both ml300 and ml403, but I don't see any source files related to
either ml300 or ml403 under the <platforms> subdirectory. Have you done
a complete BSP for either ml300 or ml403?
Thanks,=20
Chang
-----Original Message-----
From: linuxppc-embedded-bounces+chang.sun=3Dxilinx.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+chang.sun=3Dxilinx.com@ozlabs.org] On
Behalf Of Grant Likely
Sent: Wednesday, April 12, 2006 11:45 AM
To: Martin, Tim
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: question about Linux 2.6 with Xilinx ML-403
On 4/12/06, Martin, Tim <tim.martin@viasat.com> wrote:
> Grant,
>
> I know I could probably figure this out by looking at the GIT tree
> directly (which I'm planning to do) but could you summarize how much
> (which devices) of the ML-403 is supported by your patches?
>
> Serial? (which Xilinx core)
Yes, full uart
>
> Ethernet? (Hard-Core PLB TEMAC?, Soft-Core PLB EMAC? Localink TEMAC?
Is
> 10/100/1000 supported, or is there only 1 rate e.g. 1000 supported?)
No. I've ported the 2.4 driver, but I haven't got permission to
release it yet. (I'm a contractor; I don't own any of the work I do)
>
> Anything else (GPIO buttons/switches?)
I've got drivers for the PS/2 & VGA, but I'm still trying to get them
released.
Cheers,
g.
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* [PATCH] snd_pmac_toonie_init should to be __init
From: Andreas Schwab @ 2006-04-23 18:32 UTC (permalink / raw)
To: linuxppc-dev
snd_pmac_toonie_init is only called by __init code and calls __init code
itself.
Signed-off-by: Andreas Schwab <schwab@suse.de>
---
sound/ppc/toonie.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.17-rc2/sound/ppc/toonie.c
===================================================================
--- linux-2.6.17-rc2.orig/sound/ppc/toonie.c 2006-04-19 21:46:39.000000000 +0200
+++ linux-2.6.17-rc2/sound/ppc/toonie.c 2006-04-19 22:56:30.000000000 +0200
@@ -335,7 +335,7 @@ static void toonie_cleanup(struct snd_pm
chip->mixer_data = NULL;
}
-int snd_pmac_toonie_init(struct snd_pmac *chip)
+int __init snd_pmac_toonie_init(struct snd_pmac *chip)
{
struct pmac_toonie *mix;
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* please pull powerpc-merge.git
From: Paul Mackerras @ 2006-04-23 1:15 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev
Linus,
Please do a pull from
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc-merge.git
to get the following powerpc bug-fixes, and a defconfig update.
Thanks,
Paul.
Arnd Bergmann:
powerpc/cell: remove BUILD_BUG_ON and add sys_tee to spu_syscall_table
Becky Bruce:
ppc: Fix powersave code on arch/ppc
Benjamin Herrenschmidt:
powermac: Fix i2c on keywest based chips
powerpc: fix oops in alsa powermac driver
Kumar Gala:
powerpc/ppc: export strncasecmp
Olof Johansson:
powerpc: IOMMU support for honoring dma_mask
powerpc: Lower threshold for DART enablement to 1GB
Paul Mackerras:
powerpc: Fix define_machine so machine_is() works from modules
Will Schmidt:
powerpc: update {g5,iseries,pseries}_defconfigs
arch/powerpc/configs/g5_defconfig | 58 ++++++++++----------
arch/powerpc/configs/iseries_defconfig | 43 +++++++++------
arch/powerpc/configs/pseries_defconfig | 54 +++++++++----------
arch/powerpc/kernel/iommu.c | 38 +++++++++----
arch/powerpc/kernel/pci_iommu.c | 42 +++++++++++++--
arch/powerpc/kernel/ppc_ksyms.c | 1
arch/powerpc/kernel/prom.c | 2 -
arch/powerpc/kernel/systbl.S | 5 ++
arch/powerpc/kernel/vio.c | 6 +-
arch/powerpc/platforms/cell/spu_callbacks.c | 5 +-
arch/powerpc/platforms/powermac/low_i2c.c | 78 ++++++++++++---------------
arch/powerpc/sysdev/dart_iommu.c | 12 +++-
arch/ppc/kernel/asm-offsets.c | 1
arch/ppc/kernel/entry.S | 35 ++++++------
arch/ppc/kernel/ppc_ksyms.c | 1
drivers/macintosh/therm_adt746x.c | 4 +
include/asm-powerpc/iommu.h | 7 +-
include/asm-powerpc/machdep.h | 6 ++
sound/oss/dmasound/tas_common.c | 4 +
sound/ppc/daca.c | 2 -
sound/ppc/tumbler.c | 2 -
21 files changed, 234 insertions(+), 172 deletions(-)
^ permalink raw reply
* Re: Upgrading cramfs root file system while running (DENX wrote that is not possible)
From: Tolunay Orkun @ 2006-04-22 19:53 UTC (permalink / raw)
To: Antonio Di Bacco; +Cc: linuxppc-embedded
In-Reply-To: <200604212332.55123.antonio.dibacco@aruba.it>
Antonio Di Bacco wrote:
> Little bit off topic:
> I decided to adopt a different strategy, the sw download web page will contain
> a java applet that will act as a tftp server, then the board will be rebooted
> and an environment variable will instruct the u-boot to tftp the new software
> from the applet. What do you think? I know that applets cannot read local
> files on the PC, unless they have a valid certificate but the user should
> trust me.
>
> Bye,
> Antonio.
>
If this approach hits a roadblock for some reason (user resistance,
firewall issues with tftp etc.), think about the following...
During the update you can use a small ram based file system (tempfs)
holding everything you need, kill all unneeded processes, fill your ram
based file system. Once this ram file system is filled you will
pivot_root to it making it new root fs and proceed to update from it.
Once update is down you can reboot.
I have not done this so it is very likely there are some details that I
cannot foresee at this very moment.
Best regards,
Tolunay
^ permalink raw reply
* Re: Upgrading cramfs root file system while running (DENX wrote that is not possible)I
From: Antonio Di Bacco @ 2006-04-22 19:21 UTC (permalink / raw)
To: Stefan Eletzhofer; +Cc: linuxppc-embedded
In-Reply-To: <27FB8E28-233C-42CF-9C2A-696C70BF45C1@inquant.de>
I'm going to develop it if I don't find elsewhere.
Bye.
On Saturday 22 April 2006 13:40, Stefan Eletzhofer wrote:
> Hi,
>
> Am 21.04.2006 um 23:32 schrieb Antonio Di Bacco:
> > Little bit off topic:
> > I decided to adopt a different strategy, the sw download web page
> > will contain
> > a java applet that will act as a tftp server, then the board will
> > be rebooted
> > and an environment variable will instruct the u-boot to tftp the
> > new software
> > from the applet. What do you think? I know that applets cannot read
> > local
> > files on the PC, unless they have a valid certificate but the user
> > should
> > trust me.
>
> nice idea IMHO. Is that applet available somewhere? That would surely
> fit my needs
> (and others probably, too).
>
> Cheers,
> Stefan.
>
> > Bye,
> > Antonio.
> >
> > On Friday 21 April 2006 22:23, Wolfgang Denk wrote:
> >> In message <200604210853.32860.david.jander@protonic.nl> you wrote:
> >>> What do you mean with "something bad could happen"?
> >>
> >> System crashes.
> >>
> >>> The only thing I can think of is pulling the power plug while
> >>> flash is
> >>> being erased or written. What else could go wrong?
> >>
> >> The kernel may try to (re-) load some pages of a running executable
> >> or library which is no longer available (at least not at the
> >> addresses where they used to be). The kernel will either stumble over
> >> what it believes to be a corrupted file system, or load the wrong
> >> data -> kaboom.
> >>
> >>> We do the following: system running from read-only jffs2 partition.
> >>> Sometimes that partition is remounted read-write and single files
> >>> are
> >>> replaced, but in some occasions we need to upgrade the whole fs.
> >>> In that
> >>> case a CGI lodas the image into a ramdisk, and the upgrade
> >>> process is
> >>> started. For upgrade,
> >>
> >> You *have* to unmount the old file system here.
> >>
> >>> partition, and then "dd" again to copy the image. At that point no
> >>> critical flash-read access should be requested since dd is
> >>> already in
> >>> cache (it's
> >>
> >> The kernel might reload any page of any running executable or
> >> library.
> >>
> >> Best regards,
> >>
> >> Wolfgang Denk
> >
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: Upgrading cramfs root file system while running (DENX wrote that is not possible)
From: Tolunay Orkun @ 2006-04-22 19:07 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: White, linuxppc-embedded
In-Reply-To: <20060421165732.CD0EB3526B7@atlas.denx.de>
Wolfgang Denk wrote:
> In message <20060421055142.11025.qmail@mx1.aruba.it> you wrote:
>
>> No, I have a cramfs on flash and the kernel uses it directly from flash,
>> extracting what it needs to execute. I'm not using initrd then, I have to
>> update in situ, while running.
>>
>
> This cannot be done reliably. You have to make the file system idle,
> i. e. unmount it.
>
I agree, even if you make the executables involved in the update
statically linked (so library dependencies are removed), kernel can
choose to reload any running executables page and it would end up with a
bogus page in memory. This is particularly true if you do not have swap
which you could try to lock executable in swap. Also, you cannot
reliably depend on file system cache to contain all the executable code
you would need to complete update either.
Regards,
Tolunay
^ permalink raw reply
* Re: Upgrading cramfs root file system while running (DENX wrote that is not possible)
From: Tolunay Orkun @ 2006-04-22 18:50 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: White, linuxppc-embedded
In-Reply-To: <20060421165548.A03E53526B7@atlas.denx.de>
Wolfgang Denk wrote:
> In message <44485B3F.8080308@orkun.us> you wrote:
>
>> If your bootloader is U-Boot and you are using standard bootm command to
>> boot, U-Boot decompresses the initrd image to RAM before passing the
>> file system to Linux. So, you are not working with flash copy and
>> updating the flash copy is not a problem at all. This applies to ext2,
>> cramfs or squashfs based initrd.
>>
>
> But it makes no sense to use cramfs or squashfs on a ramdisk.
> You *want* to run these directly from flash.
> But then, of course, you need alternate images (or other tricks)
> for full image updates.
>
Well, we lose a couple of MB of RAM but squashfs as initrd has been
reliable, very compact and since the file system is in RAM, it is faster
and we can tune a bit for smaller cache etc.
Image updates have been extremely easy as a result, we did not need to
resort to alternate images and other tricks as a result. If you have
more flexibility in RAM than in flash, our approach makes sense without
complicating the matter much. I understand that not everyone might have
this option.
> [Single file updates can be done using overlay file systems; see the
> DULG for details.]
I know about the overlay fs. There is also unionfs that works similarly.
Best regards,
Tolunay
^ permalink raw reply
* Re: Fedora 5 on POWER5
From: David Woodhouse @ 2006-04-22 12:57 UTC (permalink / raw)
To: Josef Mádl; +Cc: linuxppc-dev
In-Reply-To: <001201c6650b$e507b110$0c01a8c0@KTSJMXP>
On Fri, 2006-04-21 at 08:21 +0200, Josef Mádl wrote:
> I am trying to install fedora 5 on IBM i5 system. Instalation start,
> all seems to good to partitioning disk.
> Fedora see two disks /dev/sda (real disk - virtual disk prepared with
> CRTNWSSTG) and /dev/sdb (booting disk of instalation - Prep).
> I choise /dev/sda for creating linux partitions, fedora show me how it
> will be parted but try to write to /dev/sdb - it ends with error.
>
> Do anybody know how solved this problem ?
I'm fairly sure I saw Paul helping someone work around this on Freenode
#fedora-ppc a couple of weeks ago.
--
dwmw2
^ permalink raw reply
* Re: Upgrading cramfs root file system while running (DENX wrote that is not possible)
From: Stefan Eletzhofer @ 2006-04-22 11:40 UTC (permalink / raw)
To: Antonio Di Bacco; +Cc: linuxppc-embedded
In-Reply-To: <200604212332.55123.antonio.dibacco@aruba.it>
Hi,
Am 21.04.2006 um 23:32 schrieb Antonio Di Bacco:
> Little bit off topic:
> I decided to adopt a different strategy, the sw download web page
> will contain
> a java applet that will act as a tftp server, then the board will
> be rebooted
> and an environment variable will instruct the u-boot to tftp the
> new software
> from the applet. What do you think? I know that applets cannot read
> local
> files on the PC, unless they have a valid certificate but the user
> should
> trust me.
nice idea IMHO. Is that applet available somewhere? That would surely
fit my needs
(and others probably, too).
Cheers,
Stefan.
>
> Bye,
> Antonio.
>
> On Friday 21 April 2006 22:23, Wolfgang Denk wrote:
>> In message <200604210853.32860.david.jander@protonic.nl> you wrote:
>>> What do you mean with "something bad could happen"?
>>
>> System crashes.
>>
>>> The only thing I can think of is pulling the power plug while
>>> flash is
>>> being erased or written. What else could go wrong?
>>
>> The kernel may try to (re-) load some pages of a running executable
>> or library which is no longer available (at least not at the
>> addresses where they used to be). The kernel will either stumble over
>> what it believes to be a corrupted file system, or load the wrong
>> data -> kaboom.
>>
>>> We do the following: system running from read-only jffs2 partition.
>>> Sometimes that partition is remounted read-write and single files
>>> are
>>> replaced, but in some occasions we need to upgrade the whole fs.
>>> In that
>>> case a CGI lodas the image into a ramdisk, and the upgrade
>>> process is
>>> started. For upgrade,
>>
>> You *have* to unmount the old file system here.
>>
>>> partition, and then "dd" again to copy the image. At that point no
>>> critical flash-read access should be requested since dd is
>>> already in
>>> cache (it's
>>
>> The kernel might reload any page of any running executable or
>> library.
>>
>> Best regards,
>>
>> Wolfgang Denk
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Re: [PATCH] kdump-ppc64-xmon-stop-cpu
From: Paul Mackerras @ 2006-04-22 8:43 UTC (permalink / raw)
To: David Wilder; +Cc: akpm, linuxppc-dev, mchintage, fastboot
In-Reply-To: <443ADCF5.60702@us.ibm.com>
David Wilder writes:
> - During CPU(s) hang scenarios, kdump could not stop these CPUs.
> However, the user could invoke soft-reset to shoot down CPUs reliably.
> But, when the debugger is enabled, these CPUs are returned to hang state
> after they exited from the debugger. This patch fixes this issue by
> calling crash_kexec_secondary() before returns to previous state.
All three of your patches need a good 1-line description in the
subject and better description - one which is comprehensible to
someone who doesn't know all the internals of kdump, and with correct
English grammar. I had to read this one about 4 times before I got
much of an idea what it was supposed to be about. Please resubmit all
three patches in your series.
Paul.
^ permalink raw reply
* Re: [PATCH 2/2]: Spider ethernet driver -- protect chain head
From: Linas Vepstas @ 2006-04-22 1:03 UTC (permalink / raw)
To: utz.bacher, Arnd Bergmann, Maxim Shchetynin, linuxppc-dev,
linux-kernel
In-Reply-To: <20060422001140.GA12826@gate.ebshome.net>
On Fri, Apr 21, 2006 at 05:11:40PM -0700, Eugene Surovegin wrote:
> On Fri, Apr 21, 2006 at 06:45:51PM -0500, Linas Vepstas wrote:
> > Prevent a potential race. If two threads are both calling
> > the transmit routine, both can potentially try to grab the
> > same dma descriptor. Serialize access to the head of the
> > tx ring with spinlocks.
>
> Two threads cannot be in spider_net_xmit() simultaneosuly because
> hard_start_xmit entry point is already protected by net_device
> xmit_lock, see Documentation/net/netdevices.txt
Ahh, thank you. I was wondering why I never semmed to see this
this happen in "real life".
--linas
^ permalink raw reply
* Re: [PATCH 2/2]: Spider ethernet driver -- protect chain head
From: Eugene Surovegin @ 2006-04-22 0:11 UTC (permalink / raw)
To: Linas Vepstas; +Cc: Maxim Shchetynin, Arnd Bergmann, linux-kernel, linuxppc-dev
In-Reply-To: <20060421234551.GI7242@austin.ibm.com>
On Fri, Apr 21, 2006 at 06:45:51PM -0500, Linas Vepstas wrote:
> Prevent a potential race. If two threads are both calling
> the transmit routine, both can potentially try to grab the
> same dma descriptor. Serialize access to the head of the
> tx ring with spinlocks.
Two threads cannot be in spider_net_xmit() simultaneosuly because
hard_start_xmit entry point is already protected by net_device
xmit_lock, see Documentation/net/netdevices.txt
--
Eugene
^ 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