* Memory mapped IO and Direct File IO
From: Stefan Bohne @ 2009-08-04 6:06 UTC (permalink / raw)
To: linuxppc-dev
Greetings, everyone,
I'm trying to save some data block from a memory mapped device into a
file - real fast, i.e., without any copying.
My approach so far was to get a pointer to the io memory via mmap-ing
/dev/mem, and then writing this pointer to a file (in user space).
This works, if I don't use O_DIRECT, but this is slow of course. Using
O_DIRECT, write returns EFAULT (bad address). Coyping the data to a
user-space buffer and then writing with O_DIRECT works, though.
I tracked this down to __get_user_pages in mm/memory.c where IO pages
are refused. And this is as deep as my current knowledge allows me to
go into the kernel. I don't understand why IO pointers are not
allowed.
Ultra-Fast disk IO is a requirement for our project, so any copying in
between is not an option. Any hint is appreciated.
Stefan
^ permalink raw reply
* Re: Kernel fault with simple UIO interrupt driver in 2.6.30.4
From: Michael Ellerman @ 2009-08-04 2:31 UTC (permalink / raw)
To: Frank Prepelica; +Cc: linuxppc-dev
In-Reply-To: <29DC34A6B43468409F5A371CFE34E849DFC9A1@ex01.ads.ubidyne.de>
[-- Attachment #1: Type: text/plain, Size: 444 bytes --]
On Mon, 2009-08-03 at 15:07 +0200, Frank Prepelica wrote:
> Hi all,
>
> due to a new revision of our custimized board, i need to port our current kernel (2.6.24)
> to the latest kernel version 2.6.30.4.
>
> Among other things the UIO interrupt driver makes some trouble. The driver runs
> smoothly on 2.6.24 but I'll get kernel faults when running in 2.6.30.4.
You seem to have forgotten to post the log of the oops :)
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Stop pci_set_dma_mask() from failing when RAM doesn't exceed the mask anyway
From: Benjamin Herrenschmidt @ 2009-08-03 21:05 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev
In-Reply-To: <1249305244.15714.3.camel@macbook.infradead.org>
On Mon, 2009-08-03 at 14:14 +0100, David Woodhouse wrote:
> Do we care about that scenario? I think we might be able to "fix" it by
> setting the memory_limit when we allow pci_set_dma_mask() to succeed?
> That will effectively prevent the addition of memory that our crappy
> device can't reach, won't it?
We don't support hotplug memory on those machines anyway, do we ?
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 3/20] powerpc/mm: Add HW threads support to no_hash TLB management
From: Benjamin Herrenschmidt @ 2009-08-03 21:03 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev
In-Reply-To: <1249265010.5516.31.camel@concordia>
> for (cpu = cpu_first_thread_in_core(cpu);
> cpu <= cpu_last_thread_in_core(cpu); cpu++)
> __clear_bit(id, stale_map[cpu]);
>
> ==
>
> cpu = cpu_first_thread_in_core(cpu);
> while (cpu <= cpu_last_thread_in_core(cpu)) {
> __clear_bit(id, stale_map[cpu]);
> cpu++;
> }
>
> cpu = 0
> cpu <= 1
> cpu++ (1)
> cpu <= 1
> cpu++ (2)
> cpu <= 3
> ...
Ah right, /me takes snow out of his eyes... indeed, the
upper bound is fubar. Hrm. Allright, we'll use a temp.
Cheers,
Ben.
^ permalink raw reply
* Re: [Patch 2/6] Introduce PPC64 specific Hardware Breakpoint interfaces
From: K.Prasad @ 2009-08-03 20:59 UTC (permalink / raw)
To: David Gibson
Cc: Michael Neuling, Benjamin Herrenschmidt, linuxppc-dev, paulus,
Alan Stern, Roland McGrath
In-Reply-To: <20090731061646.GH3950@yookeroo.seuss>
On Fri, Jul 31, 2009 at 04:16:46PM +1000, David Gibson wrote:
> On Mon, Jul 27, 2009 at 05:43:17AM +0530, K.Prasad wrote:
> > Introduce PPC64 implementation for the generic hardware breakpoint interfaces
> > defined in kernel/hw_breakpoint.c. Enable the HAVE_HW_BREAKPOINT flag and the
> > Makefile.
>
> [snip]
> > +/*
> > + * Handle debug exception notifications.
> > + */
> > +int __kprobes hw_breakpoint_handler(struct die_args *args)
> > +{
> > + int rc = NOTIFY_STOP;
> > + struct hw_breakpoint *bp;
> > + struct pt_regs *regs = args->regs;
> > + unsigned long dar = regs->dar;
> > + int cpu, is_kernel, stepped = 1;
> > +
> > + is_kernel = (hbp_kernel_pos == HBP_NUM) ? 0 : 1;
> > +
> > + /* Disable breakpoints during exception handling */
> > + set_dabr(0);
> > +
> > + cpu = get_cpu();
> > + /* Determine whether kernel- or user-space address is the trigger */
> > + bp = is_kernel ?
> > + per_cpu(this_hbp_kernel[0], cpu) : current->thread.hbp[0];
> > + /*
> > + * bp can be NULL due to lazy debug register switching
> > + * or due to the delay between updates of hbp_kernel_pos
> > + * and this_hbp_kernel.
> > + */
> > + if (!bp)
> > + goto out;
> > +
> > + per_cpu(dabr_data, cpu) = is_kernel ? kdabr : current->thread.dabr;
> > +
> > + /* Verify if dar lies within the address range occupied by the symbol
> > + * being watched. Since we cannot get the symbol size for
> > + * user-space requests we skip this check in that case
> > + */
> > + if (is_kernel &&
> > + !((bp->info.address <= dar) &&
> > + (dar <= (bp->info.address + bp->info.symbolsize))))
> > + /*
> > + * This exception is triggered not because of a memory access on
> > + * the monitored variable but in the double-word address range
> > + * in which it is contained. We will consume this exception,
> > + * considering it as 'noise'.
> > + */
> > + goto out;
> > +
> > + (bp->triggered)(bp, regs);
>
> It bothers me that the trigger function is executed before the
> trapping instruction, but the SIGTRAP occurs afterwards. Since
> they're both responses to the trap, it seems logical to me that they
> should occur at the same time (from the trapping program's point of
> view, at least).
>
How about moving the triggered function to the single-step handler code
for both kernel- and user-space?
That would make it behave like a trigger-after-execute (and synchronised
with the signal-delivery timing).
> > + /*
> > + * Return early without restoring DABR if the breakpoint is from
> > + * user-space which always operates in one-shot mode
> > + */
> > + if (!is_kernel) {
> > + rc = NOTIFY_DONE;
> > + goto out;
> > + }
> > +
> > + stepped = emulate_step(regs, regs->nip);
> > + /*
> > + * Single-step the causative instruction manually if
> > + * emulate_step() could not execute it
> > + */
> > + if (stepped == 0) {
> > + regs->msr |= MSR_SE;
> > + goto out;
> > + }
> > + set_dabr(per_cpu(dabr_data, cpu));
> > +
> > +out:
> > + /* Enable pre-emption only if single-stepping is finished */
> > + if (stepped) {
> > + per_cpu(dabr_data, cpu) = 0;
> > + put_cpu();
> > + }
> > + return rc;
> > +}
> > +
> > +/*
> > + * Handle single-step exceptions following a DABR hit.
> > + */
> > +int __kprobes single_step_dabr_instruction(struct die_args *args)
> > +{
> > + struct pt_regs *regs = args->regs;
> > + int cpu = get_cpu();
> > + int ret = NOTIFY_DONE;
> > + siginfo_t info;
> > + unsigned long this_dabr_data = per_cpu(dabr_data, cpu);
> > +
> > + /*
> > + * Check if we are single-stepping as a result of a
> > + * previous HW Breakpoint exception
> > + */
> > + if (this_dabr_data == 0)
> > + goto out;
> > +
> > + regs->msr &= ~MSR_SE;
> > + /* Deliver signal to user-space */
> > + if (this_dabr_data < TASK_SIZE) {
> > + info.si_signo = SIGTRAP;
> > + info.si_errno = 0;
> > + info.si_code = TRAP_HWBKPT;
> > + info.si_addr = (void __user *)(per_cpu(dabr_data, cpu));
> > + force_sig_info(SIGTRAP, &info, current);
> > + }
> > +
> > + set_dabr(this_dabr_data);
> > + per_cpu(dabr_data, cpu) = 0;
> > + ret = NOTIFY_STOP;
> > + /*
> > + * If single-stepped after hw_breakpoint_handler(), pre-emption is
> > + * already disabled.
> > + */
> > + put_cpu();
> > +
> > +out:
> > + /*
> > + * A put_cpu() call is required to complement the get_cpu()
> > + * call used initially
> > + */
> > + put_cpu();
> > + return ret;
> > +}
> > +
> > +/*
> > + * Handle debug exception notifications.
> > + */
> > +int __kprobes hw_breakpoint_exceptions_notify(
>
> Um.. there seems to be a pretty glaring problem here, in that AFAICT
> in this revision of the series, this function is never invoked, and so
> your breakpoint handling code will never be executed. i.e. the
> changes to do_dabr to connect your code seem to be missing.
>
I realised it only after you pointed out...some remnants from the
previous version have caused it. While the patch should have treated
only ptrace in a special manner (one-shot), it erroneously does it for all
user-space. I will change it in the next version of the patchset.
Thanks,
K.Prasad
^ permalink raw reply
* Re: [Patch 0/6] [Patch 0/6] PPC64-HWBKPT: Hardware Breakpoint interfaces - ver VIII
From: K.Prasad @ 2009-08-03 20:53 UTC (permalink / raw)
To: David Gibson
Cc: Michael Neuling, Benjamin Herrenschmidt, linuxppc-dev, paulus,
Alan Stern, Roland McGrath
In-Reply-To: <20090731061013.GG3950@yookeroo.seuss>
On Fri, Jul 31, 2009 at 04:10:13PM +1000, David Gibson wrote:
> On Mon, Jul 27, 2009 at 05:41:52AM +0530, K.Prasad wrote:
<edited>
> > Reasons
> > --------
> > - Signal delivery before execution of instruction requires complex workarounds
> > - One of the plausible workarounds is a two-pass hw-breakpoint handler which
> > delivers the signal after the first pass (with the breakpoints enabled).
> > In the second pass, it follows the existing semantics of
> > disable_hbp-->enable_ss-->single_step-->disable_ss-->enable_hbp.
>
> Yes, that's the only way I can see to do it.
>
> > - Possibility of nested exceptions is a problem here.
>
> Ok, why?
>
Reason as described in the para below.
> > - Proper identification of a second-pass of first exception and a new nested
> > exception is difficult. Possibility of stray exceptions due to accesses in
> > neighbouring memory regions of the breakpoint address further complicates it.
To elaborate, consider a case where a user-space address 'x' is
monitored for read or write, and the following happens (assume the
existence of the two-pass method for signal delivery).
- Instruction 'i' attempts to read/write in address 'x'
- hw-bkpt exception generated (pass I)
- Signal generated and hw-bkpt exception returns to user-space
- Signal is handled before 'i' is executed. Handler code reads/writes
data in 'x' again. Generates nested exception.
- hw-breakpoint handler code is unable to distinguish if the new
exception is from signal handler (nested) or due to second-pass (as
per design above).
Thanks,
K.Prasad
^ permalink raw reply
* Re: [PATCH] powerpc: Read buffer overflow
From: Segher Boessenkool @ 2009-08-03 20:15 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Andrew Morton, Roel Kluin
In-Reply-To: <19062.57005.981901.24666@cargo.ozlabs.ibm.com>
> The change seems unnecessary since we only compute the address of the
> element before the bounds check, we don't actually access the
> element. I believe that is legal in C.
If you have an array a[N], taking &a[0] .. &a[N] are legal C, everything
else is not.
Segher
^ permalink raw reply
* G4 radeon 9500 KMS issues
From: Christian Schmitt @ 2009-08-03 19:35 UTC (permalink / raw)
To: linuxppc-dev
Hello,
I'm testing KMS on my G4 machine, but it is making problems. I tried different
approaches:
When booting with KMS and agpmode=1 i get this output:
[drm] Initialized drm 1.1.0 20060810
[drm] radeon kernel modesetting enabled.
[drm:drm_init],
[drm:drm_get_dev],
radeon 0000:00:10.0: enabling device (0006 -> 0007)
[drm:drm_get_minor],
[drm:drm_get_minor], new minor assigned 64
[drm:drm_get_minor],
[drm:drm_get_minor], new minor assigned 0
[drm] radeon: Initializing kernel modesetting.
[drm] register mmio base: 0x90000000
[drm] register mmio size: 65536
radeon 0000:00:10.0: Invalid ROM contents
radeon 0000:00:10.0: Invalid ROM contents
[drm:radeon_get_bios] *ERROR* Unable to locate a BIOS ROM
[drm] GPU reset succeed (RBBM_STATUS=0x00000140)
[drm] Using generic clock info
[drm] Clocks initialized !
[drm] Generation 2 PCI interface, using max accessible memory
[drm] Detected VRAM RAM=32M, BAR=128M
[drm] RAM width 64bits DDR
[drm] radeon: 1 pipes initialized.
agpgart-uninorth 0000:00:0b.0: putting AGP V2 device into 4x mode
radeon 0000:00:10.0: putting AGP V2 device into 4x mode
[drm] radeon: VRAM 32M
[drm] radeon: VRAM from 0x04000000 to 0x07FFFFFF
[drm] radeon: VRAM less than aperture workaround enabled
[drm] radeon: GTT 32M
[drm] radeon: GTT from 0x00000000 to 0x01FFFFFF
[drm:drm_irq_install], irq=48
[drm] radeon: irq initialized.
[TTM] TTM available graphics memory: 757 MiB
[TTM] TTM available object memory: 373 MiB
[drm] radeon: 32M of VRAM memory ready
[drm] radeon: 32M of GTT memory ready.
[drm] radeon: cp idle (0x10000C03)
[drm] Loading R300 Microcode
[drm] radeon: ring at 0x0000000000000000
[drm] ring test succeeded in 1 usecs
[drm] radeon: ib pool ready.
[drm:radeon_fence_wait] *ERROR* fence(efb3fea0:0x00000001) 510ms timeout going
to reset GPU
[drm] CP reset succeed (RBBM_STATUS=0x00000140)
[drm] radeon: cp idle (0x10000000)
[drm] Loading R300 Microcode
[drm] radeon: ring at 0x0000000000000000
[drm:radeon_ring_test] *ERROR* radeon: ring test failed
(sracth(0x15E8)=0xCAFEDEAD)
[drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22).
[drm:r300_gpu_reset] *ERROR* Failed to reset GPU (RBBM_STATUS=0x80010140)
[drm:radeon_fence_wait] *ERROR* fence(efb3fea0:0x00000001) 666ms timeout
[drm:radeon_fence_wait] *ERROR* last signaled fence(0x00000001)
[drm:radeon_ib_test] *ERROR* radeon: ib test failed
(sracth(0x15E4)=0xCAFEDEAD)
[drm:radeon_device_init] *ERROR* radeon: failled testing IB (-22).
[drm:radeon_driver_load_kms] *ERROR* Failed to initialize radeon, disabling
IOCTL
[drm] radeon: finishing device.
[drm] radeon: cp finalized
[TTM] Used total memory is 0 bytes.
[drm] radeon: ttm finalized
[drm:drm_irq_uninstall], irq=48
[drm] radeon: fence finalized
[drm:drm_put_minor], release secondary minor 0
[drm:drm_put_minor], release secondary minor 64
radeon: probe of 0000:00:10.0 failed with error -22
When I try to disable AGP, the machine crashes badly. The problem is that I
can hardly get any debug output, as the console is not working (see above) and
I have to use a SSH session to get any access at all. Here is the log i get:
radeon agpmode=-1
Aug 3 13:17:08 [kernel] [drm] radeon kernel modesetting enabled.
Aug 3 13:17:08 [kernel] [drm:drm_init],
Aug 3 13:17:08 [kernel] [drm:drm_get_dev],
Aug 3 13:17:08 [kernel] [drm:drm_get_minor],
Aug 3 13:17:08 [kernel] [drm:drm_get_minor], new minor assigned 64
Aug 3 13:17:08 [kernel] [drm:drm_get_minor],
Aug 3 13:17:08 [kernel] [drm:drm_get_minor], new minor assigned 0
Aug 3 13:17:08 [kernel] [drm] radeon: Initializing kernel modesetting.
Aug 3 13:17:08 [kernel] [drm] Forcing AGP to PCI mode
Aug 3 13:17:08 [kernel] [drm] register mmio base: 0x90000000
Aug 3 13:17:08 [kernel] [drm] register mmio size: 65536
Aug 3 13:17:08 [kernel] radeon 0000:00:10.0: Invalid ROM contents
- Last output repeated twice -
Aug 3 13:17:08 [kernel] [drm:radeon_get_bios] *ERROR* Unable to locate a BIOS
ROM
Aug 3 13:17:08 [kernel] [drm] GPU reset succeed (RBBM_STATUS=0x00000140)
Aug 3 13:17:08 [kernel] [drm] Using generic clock info
Aug 3 13:17:08 [kernel] [drm] Clocks initialized !
Aug 3 13:17:08 [kernel] [drm] Generation 2 PCI interface, using max
accessible memory
Aug 3 13:17:08 [kernel] [drm] Detected VRAM RAM=32M, BAR=128M
Aug 3 13:17:08 [kernel] [drm] RAM width 64bits DDR
Aug 3 13:17:08 [kernel] [drm] radeon: 1 pipes initialized.
Aug 3 13:17:08 [kernel] [drm] radeon: VRAM 32M
Aug 3 13:17:08 [kernel] [drm] radeon: VRAM from 0x00000000 to 0x03FFFFFF
Aug 3 13:17:08 [kernel] [drm] radeon: VRAM less than aperture workaround
enabled
Aug 3 13:17:08 [kernel] [drm] radeon: GTT 512M
Aug 3 13:17:08 [kernel] [drm] radeon: GTT from 0x04000000 to 0x23FFFFFF
Aug 3 13:17:08 [kernel] [drm:drm_irq_install], irq=48
Aug 3 13:17:08 [kernel] [drm] radeon: irq initialized.
Aug 3 13:17:08 [kernel] [TTM] TTM available graphics memory: 757 MiB
Aug 3 13:17:08 [kernel] [TTM] TTM available object memory: 373 MiB
Aug 3 13:17:08 [kernel] [drm] radeon: 32M of VRAM memory ready
Aug 3 13:17:08 [kernel] [drm] radeon: 512M of GTT memory ready.
Aug 3 13:17:08 [kernel] [drm] GART: num cpu pages 131072, num gpu pages
131072
Aug 3 13:17:08 [kernel] [drm] radeon: cp idle (0x10000000)
Aug 3 13:17:08 [kernel] [drm] Loading R300 Microcode
Aug 3 13:17:08 [kernel] [drm] radeon: ring at 0x0000000004000000
Aug 3 13:17:08 [kernel] [drm] ring test succeeded in 1 usecs
Aug 3 13:17:08 [kernel] [drm] radeon: ib pool ready.
Aug 3 13:17:08 [kernel] [drm] ib test succeeded in 0 usecs
Aug 3 13:17:08 [kernel] [drm] Connector Table: 2 (ibook)
Aug 3 13:17:08 [kernel] [drm] Panel info derived from registers
Aug 3 13:17:08 [kernel] [drm] Panel Size 1024x768
Aug 3 13:17:08 [kernel] [drm:drm_sysfs_connector_add], adding "LVDS-1" to
sysfs
Aug 3 13:17:08 [kernel] [drm:drm_sysfs_hotplug_event], generating hotplug
event
Aug 3 13:17:08 [kernel] [drm:drm_sysfs_connector_add], adding "VGA-1" to
sysfs
Aug 3 13:17:08 [kernel] [drm:drm_sysfs_hotplug_event], generating hotplug
event
Aug 3 13:17:08 [kernel] [drm] Radeon Display Connectors
Aug 3 13:17:08 [kernel] [drm] Connector 0:
Aug 3 13:17:08 [kernel] [drm] LVDS
Aug 3 13:17:08 [kernel] [drm] DDC: 0x64 0x64 0x64 0x64 0x64 0x64 0x64 0x64
Aug 3 13:17:08 [kernel] [drm] Encoders:
Aug 3 13:17:08 [kernel] [drm] LCD1: INTERNAL_LVDS
Aug 3 13:17:08 [kernel] [drm] Connector 1:
Aug 3 13:17:08 [kernel] [drm] VGA
Aug 3 13:17:08 [kernel] [drm] DDC: 0x60 0x60 0x60 0x60 0x60 0x60 0x60 0x60
Aug 3 13:17:08 [kernel] [drm] Encoders:
Aug 3 13:17:08 [kernel] [drm] CRT2: INTERNAL_DAC2
It is really difficult to get more debug output. Any help would be
appreciated.
Cheers,
Chris
^ permalink raw reply
* Re: [PATCH] powerpc/mpc52xx/wdt: Fix 5200 wdt always being used as gpt
From: Albrecht Dreß @ 2009-08-03 18:46 UTC (permalink / raw)
To: Grant Likely; +Cc: Linux PPC Development, wim
In-Reply-To: <fa686aa40908031050g2d03abb5s9dfe4dceb2072af6@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1492 bytes --]
Am 03.08.09 19:50 schrieb(en) Grant Likely:
> Just about all mpc5200 device trees have the fsl,has-wdt property on
> GPT0 even when it isn't used as a watchdog.
Sorry, I do not understand... The file
Documentation/powerpc/dts-bindings/fsl/mpc5200.txt says
<snip>
On the mpc5200 and 5200b, GPT0 has a watchdog timer function. If the
board design supports the internal wdt, then the device node for GPT0
should include the empty property 'fsl,has-wdt'.
</snip>
I interpreted this as "if you don't want to have the wdt function of
gpt0, remove this property". If this assumption is wrong, how is the
kernel supposed to decide if a device shall be used as gpt or as wdt?
> The boards using GPT0 as a GPIO or timer will be broken by this patch.
A wdt is a security device which will (IMHO) either not be used as
such, or it is a *must not* be used for something else on a particular
board (you may even want u-boot to activate it, e.g. to detect a
hanging boot process). In both cases, a "tuned" device tree is needed.
> I know it is a lot more work, but the correct solution is to merge
> the GPT watchdog driver into the regular GPT driver so that we don't
> have two device drivers trying to bind against the same device.
I see the benefit of removing some duplicate code and of having gpio
access in parallel with the wdt, but it wouldn't solve the general
confusion above! Will look into that, though...
Best, Albrecht.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc/mpc52xx/wdt: Fix 5200 wdt always being used as gpt
From: Grant Likely @ 2009-08-03 17:50 UTC (permalink / raw)
To: Albrecht Dreß; +Cc: Linux PPC Development, wim
In-Reply-To: <1249317654.3404.0@antares>
On Mon, Aug 3, 2009 at 10:40 AM, Albrecht Dre=DF<albrecht.dress@arcor.de> w=
rote:
> In the current code, all MPC5200 timers are registered by the mpc52xx_gpt
> driver, even if gpt0 (the only one with this capability) shall be used as
> hardware watchdog which is indicated by the "fsl,has-wdt" or "has-wdt"
> property in the device tree. =A0Thus, the watchdog driver does never find=
any
> watchdog and simply doesn't work.
>
> This trivial patch protects timers with a "(fsl,)?has-wdt" property from
> being probed as gpt's. =A0The watchdog timer now works just fine.
Blech. This does solve one problem, but it causes another. Just
about all mpc5200 device trees have the fsl,has-wdt property on GPT0
even when it isn't used as a watchdog. The boards using GPT0 as a
GPIO or timer will be broken by this patch.
I know it is a lot more work, but the correct solution is to merge the
GPT watchdog driver into the regular GPT driver so that we don't have
two device drivers trying to bind against the same device.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 3/20] powerpc/mm: Add HW threads support to no_hash TLB management
From: Dave Kleikamp @ 2009-08-03 17:57 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <1249319197.6192.3.camel@norville.austin.ibm.com>
On Mon, 2009-08-03 at 12:06 -0500, Dave Kleikamp wrote:
> On Mon, 2009-08-03 at 11:21 -0500, Kumar Gala wrote:
> > On Aug 2, 2009, at 9:03 PM, Michael Ellerman wrote:
> >
> > > for (cpu = cpu_first_thread_in_core(cpu);
> > > cpu <= cpu_last_thread_in_core(cpu); cpu++)
> > > __clear_bit(id, stale_map[cpu]);
> > >
> > > ==
> > >
> > > cpu = cpu_first_thread_in_core(cpu);
> > > while (cpu <= cpu_last_thread_in_core(cpu)) {
> > > __clear_bit(id, stale_map[cpu]);
> > > cpu++;
> > > }
>
> cpu_last_thread_in_core(cpu) is a moving target. You want something
> like:
>
> cpu = cpu_first_thread_in_core(cpu);
> last = cpu_last_thread_in_core(cpu);
> while (cpu <= last) {
> __clear_bit(id, stale_map[cpu]);
> cpu++;
> }
Or, keeping the for loop:
for (cpu = cpu_first_thread_in_core(cpu), last =
cpu_last_thread_in_core(cpu);
cpu <= last; cpu++)
cpu++;
>
> > >
> > > cpu = 0
> > > cpu <= 1
> > > cpu++ (1)
> > > cpu <= 1
> > > cpu++ (2)
> > > cpu <= 3
> > > ...
> >
> > Which is pretty much what I see, in a dual core setup, I get an oops
> > because we are trying to clear cpu #2 (which clearly doesn't exist)
> >
> > cpu = 1
> > (in loop)
> > clearing 1
> > clearing 2
> > OOPS
> >
> > - k
>
--
David Kleikamp
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH 3/20] powerpc/mm: Add HW threads support to no_hash TLB management
From: Dave Kleikamp @ 2009-08-03 17:06 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <2EA75185-AC33-4BCA-AE53-A60E6D98DC46@kernel.crashing.org>
On Mon, 2009-08-03 at 11:21 -0500, Kumar Gala wrote:
> On Aug 2, 2009, at 9:03 PM, Michael Ellerman wrote:
>
> > On Sat, 2009-08-01 at 08:29 +1000, Benjamin Herrenschmidt wrote:
> >> On Thu, 2009-07-30 at 22:35 -0500, Kumar Gala wrote:
> >>>> /* XXX This clear should ultimately be part of
> >>> local_flush_tlb_mm */
> >>>> - __clear_bit(id, stale_map[cpu]);
> >>>> + for (cpu = cpu_first_thread_in_core(cpu);
> >>>> + cpu <= cpu_last_thread_in_core(cpu); cpu++)
> >>>> + __clear_bit(id, stale_map[cpu]);
> >>>> }
> >>>
> >>> This looks a bit dodgy. using 'cpu' as both the loop variable and
> >>> what you are computing to determine loop start/end..
> >>>
> >> Hrm... I would have thought that it was still correct... do you see
> >> any
> >> reason why the above code is wrong ? because if not we may be
> >> hitting a
> >> gcc issue...
> >>
> >> IE. At loop init, cpu gets clamped down to the first thread in the
> >> core,
> >> which should be fine. Then, we compare CPU to the last thread in core
> >> for the current CPU which should always return the same value.
> >>
> >> So I'm very interested to know what is actually wrong, ie, either I'm
> >> just missing something obvious, or you are just pushing a bug under
> >> the
> >> carpet which could come back and bit us later :-)
> >
> > for (cpu = cpu_first_thread_in_core(cpu);
> > cpu <= cpu_last_thread_in_core(cpu); cpu++)
> > __clear_bit(id, stale_map[cpu]);
> >
> > ==
> >
> > cpu = cpu_first_thread_in_core(cpu);
> > while (cpu <= cpu_last_thread_in_core(cpu)) {
> > __clear_bit(id, stale_map[cpu]);
> > cpu++;
> > }
cpu_last_thread_in_core(cpu) is a moving target. You want something
like:
cpu = cpu_first_thread_in_core(cpu);
last = cpu_last_thread_in_core(cpu);
while (cpu <= last) {
__clear_bit(id, stale_map[cpu]);
cpu++;
}
> >
> > cpu = 0
> > cpu <= 1
> > cpu++ (1)
> > cpu <= 1
> > cpu++ (2)
> > cpu <= 3
> > ...
>
> Which is pretty much what I see, in a dual core setup, I get an oops
> because we are trying to clear cpu #2 (which clearly doesn't exist)
>
> cpu = 1
> (in loop)
> clearing 1
> clearing 2
> OOPS
>
> - k
--
David Kleikamp
IBM Linux Technology Center
^ permalink raw reply
* [PATCH] powerpc/mpc52xx/wdt: Fix 5200 wdt always being used as gpt
From: Albrecht Dreß @ 2009-08-03 16:40 UTC (permalink / raw)
To: Linux PPC Development; +Cc: wim
[-- Attachment #1: Type: text/plain, Size: 1302 bytes --]
In the current code, all MPC5200 timers are registered by the
mpc52xx_gpt driver, even if gpt0 (the only one with this capability)
shall be used as hardware watchdog which is indicated by the
"fsl,has-wdt" or "has-wdt" property in the device tree. Thus, the
watchdog driver does never find any watchdog and simply doesn't work.
This trivial patch protects timers with a "(fsl,)?has-wdt" property
from being probed as gpt's. The watchdog timer now works just fine.
Tested on a custom (roughly Icecube based) MPC5200B board, with the
5200 watchdog driver built into the kernel.
Signed-off-by: Albrecht Dreß <albrecht.dress@arcor.de>
---
--- linux-2.6.30.3.orig/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
2009-07-24 23:47:51.000000000 +0200
+++ linux-2.6.30.3/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
2009-08-03 14:20:10.000000000 +0200
@@ -343,6 +343,14 @@
{
struct mpc52xx_gpt_priv *gpt;
+ /* do not grab devices which shall be used as watchdog */
+ if (of_get_property(ofdev->node, "fsl,has-wdt", NULL) ||
+ of_get_property(ofdev->node, "has-wdt", NULL)) {
+ pr_notice("%s: ignore wdt %s\n", __func__,
+ ofdev->node->full_name);
+ return -ENODEV;
+ }
+
gpt = kzalloc(sizeof *gpt, GFP_KERNEL);
if (!gpt)
return -ENOMEM;
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 3/20] powerpc/mm: Add HW threads support to no_hash TLB management
From: Kumar Gala @ 2009-08-03 16:21 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev
In-Reply-To: <1249265010.5516.31.camel@concordia>
On Aug 2, 2009, at 9:03 PM, Michael Ellerman wrote:
> On Sat, 2009-08-01 at 08:29 +1000, Benjamin Herrenschmidt wrote:
>> On Thu, 2009-07-30 at 22:35 -0500, Kumar Gala wrote:
>>>> /* XXX This clear should ultimately be part of
>>> local_flush_tlb_mm */
>>>> - __clear_bit(id, stale_map[cpu]);
>>>> + for (cpu = cpu_first_thread_in_core(cpu);
>>>> + cpu <= cpu_last_thread_in_core(cpu); cpu++)
>>>> + __clear_bit(id, stale_map[cpu]);
>>>> }
>>>
>>> This looks a bit dodgy. using 'cpu' as both the loop variable and
>>> what you are computing to determine loop start/end..
>>>
>> Hrm... I would have thought that it was still correct... do you see
>> any
>> reason why the above code is wrong ? because if not we may be
>> hitting a
>> gcc issue...
>>
>> IE. At loop init, cpu gets clamped down to the first thread in the
>> core,
>> which should be fine. Then, we compare CPU to the last thread in core
>> for the current CPU which should always return the same value.
>>
>> So I'm very interested to know what is actually wrong, ie, either I'm
>> just missing something obvious, or you are just pushing a bug under
>> the
>> carpet which could come back and bit us later :-)
>
> for (cpu = cpu_first_thread_in_core(cpu);
> cpu <= cpu_last_thread_in_core(cpu); cpu++)
> __clear_bit(id, stale_map[cpu]);
>
> ==
>
> cpu = cpu_first_thread_in_core(cpu);
> while (cpu <= cpu_last_thread_in_core(cpu)) {
> __clear_bit(id, stale_map[cpu]);
> cpu++;
> }
>
> cpu = 0
> cpu <= 1
> cpu++ (1)
> cpu <= 1
> cpu++ (2)
> cpu <= 3
> ...
Which is pretty much what I see, in a dual core setup, I get an oops
because we are trying to clear cpu #2 (which clearly doesn't exist)
cpu = 1
(in loop)
clearing 1
clearing 2
OOPS
- k
^ permalink raw reply
* Re: [Patch 0/6] [Patch 0/6] PPC64-HWBKPT: Hardware Breakpoint interfaces - ver VIII
From: Luis Machado @ 2009-08-03 16:14 UTC (permalink / raw)
To: David Gibson
Cc: Michael Neuling, Benjamin Herrenschmidt, linuxppc-dev, paulus,
Alan Stern, K.Prasad, Roland McGrath
In-Reply-To: <20090731061013.GG3950@yookeroo.seuss>
Hi,
On Fri, 2009-07-31 at 16:10 +1000, David Gibson wrote:
> On Mon, Jul 27, 2009 at 05:41:52AM +0530, K.Prasad wrote:
> > Hi David,
> > I'm back with a new version of patches after a brief hiatus!
> >
> > After much deliberation about modifying the code to change the timing of signal
> > delivery to user-space, it has been decided to retain the existing behaviour
> > i.e. SIGTRAP delivered to user-space after execution of causative instruction
> > although exception is raised before execution of it.
>
> Ok. Except, presumably for ptrace, since changing that would break
> gdb.
Yes. GDB works with some assumptions in mind. Hardware breakpoints
(they're not supported right now) trigger before execution, then GDB
just removes them and stepi's until we're past the breakpoint.
As for HW watchpoints, we always stop before execution (by ppc design
presumably). GDB will check the value before the trigger, remove the HW
watch, stepi it, and will check the value again to see if it has
changed.
If we're to trigger after the data load/store has happened, we could
have breakage in GDB.
Regards,
Luis
^ permalink raw reply
* Re: [PATCH] Stop pci_set_dma_mask() from failing when RAM doesn't exceed the mask anyway
From: David Woodhouse @ 2009-08-03 13:14 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1249199437.12047.11.camel@pasglop>
On Sun, 2009-08-02 at 17:50 +1000, Benjamin Herrenschmidt wrote:
> On Sat, 2009-08-01 at 10:00 +0100, David Woodhouse wrote:
> > I'm not sure. Losing 16MiB on a machine which only has 512MiB anyway
> > doesn't seem ideal, and we'll want to make the no-iommu code DTRT
> > _anyway_, surely?
> >
> > So we might as well let the DART keep its existing logic (which is
> > only
> > to bother if we have more than 1GiB of RAM;
>
> Ah right, so when do we enable the DART ? Above 1G ? I though it was
> above 2G but we may well have moved that down to 1G just for b43 indeed.
void __init alloc_dart_table(void)
{
/* Only reserve DART space if machine has more than 1GB of RAM
* or if requested with iommu=on on cmdline.
*
* 1GB of RAM is picked as limit because some default devices
* (i.e. Airport Extreme) have 30 bit address range limits.
*/
if (iommu_is_off)
return;
if (!iommu_force_on && lmb_end_of_DRAM() <= 0x40000000ull)
return;
> I definitely agree on the fix to the mask so it only compares to the
> available RAM. I'll check that in when I'm back from the snow fields
> on tuesday :-)
I see one potential failure mode with this. You need:
- No IOMMU
- Crappy devices
- Hotpluggable memory
- Boot with only "low" memory, and allow a pci_set_dma_mask() to
succeed because you don't have that much memory anyway.
- Hotplug some "high" memory that the crappy device can't reach.
Do we care about that scenario? I think we might be able to "fix" it by
setting the memory_limit when we allow pci_set_dma_mask() to succeed?
That will effectively prevent the addition of memory that our crappy
device can't reach, won't it?
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation
^ permalink raw reply
* Re: [PATCH] powerpc: Read buffer overflow
From: Wolfram Sang @ 2009-08-03 13:12 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Andrew Morton, Roel Kluin
In-Reply-To: <19062.57005.981901.24666@cargo.ozlabs.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 693 bytes --]
On Mon, Aug 03, 2009 at 10:57:17PM +1000, Paul Mackerras wrote:
> Roel Kluin writes:
>
> > Check whether index is within bounds before grabbing the element.
>
> The change seems unnecessary since we only compute the address of the
> element before the bounds check, we don't actually access the
> element. I believe that is legal in C.
I've got this strange feeling of deja vu :)
http://thread.gmane.org/gmane.linux.ports.arm.kernel/63507
(I'd vote for applying it but won't mind if not)
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Kernel fault with simple UIO interrupt driver in 2.6.30.4
From: Frank Prepelica @ 2009-08-03 13:07 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
due to a new revision of our custimized board, i need to port our =
current kernel (2.6.24)
to the latest kernel version 2.6.30.4.
Among other things the UIO interrupt driver makes some trouble. The =
driver runs
smoothly on 2.6.24 but I'll get kernel faults when running in 2.6.30.4.
It's a very simple interrupt driver which will be register for a certain =
external=20
cpu interrupt and informs our application via /dev/uioX when an =
interrupt occurs.
Is there anything that changed in the uio framework that could cause the
kernel fault with our uio driver?
Our driver looks like follow
<------------------------------------------------------------------------=
---------
#include <linux/uio_driver.h>
#include <linux/platform_device.h>
#include <linux/module.h>
static irqreturn_t interrupt_handler_irq4(int irq, struct uio_info =
*dev_info)
{
return IRQ_HANDLED;
}
static struct uio_info uio_irq4_info =3D {
.name =3D "IRQ4 Kernel Driver",
.version =3D "1.0.1",
.irq =3D 20,
.irq_flags =3DIRQF_DISABLED | IRQF_SHARED | IRQF_TRIGGER_FALLING,
.handler=3D interrupt_handler_irq4,
};
static int uio_irq4_probe(struct device *dev)
{
if (uio_register_device(dev, &uio_irq4_info)) {
kfree((void *)uio_irq4_info.mem[0].addr);
return -ENODEV;
}
else
{
return 0;
}
}
static int uio_irq4_remove(struct device *dev)
{
uio_unregister_device(&uio_irq4_info);
return 0;
}
static void uio_irq4_shutdown(struct device *dev)
{
}
static struct platform_device *uio_irq4_device;
static struct device_driver uio_irq4_driver =3D {
.name =3D "IRQ4",
.bus =3D &platform_bus_type,
.probe =3D uio_irq4_probe,
.remove =3D uio_irq4_remove,
.shutdown =3D uio_irq4_shutdown,
};
/*
* Main initialization/remove routines
*/
static int __init uio_irq4_init(void)
{
uio_irq4_device =3D platform_device_register_simple("IRQ4", -1,
NULL, 0);
if (IS_ERR(uio_irq4_device))
return PTR_ERR(uio_irq4_device);
return driver_register(&uio_irq4_driver);
}
static void __exit uio_irq4_exit(void)
{
platform_device_unregister(uio_irq4_device);
driver_unregister(&uio_irq4_driver);
}
module_init(uio_irq4_init);
module_exit(uio_irq4_exit);
MODULE_LICENSE("tbd");
MODULE_AUTHOR("Frank Prepelica, Ubidyne GmbH");
MODULE_DESCRIPTION("IRQ4 Interrupt Handler - CPLD Interrupts");
<------------------------------------------------------------------------=
---------
Any help is highly appreciated!
Kind Regards
Frank Prepelica
Software Design Engineer
Ubidyne GmbH
Lise-Meitner-Str.-14
89081 Ulm - Germany
Phone:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +49 731 88 00 71 58
Fax:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +49 731 88 00 71 99
Email:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
frank.prepelica@ubidyne.com
Homepage:=A0=A0=A0=A0=A0=A0 www.ubidyne.com
=A0
Registered office: Ulm
District court of Ulm: HRB 5295
Managing Directors:
Dipl. Ing. Ken Hawk
Dipl. Ing. Beat M=FCller
Dipl. Ing. Mike Levis
^ permalink raw reply
* Re: [PATCH] powerpc: Read buffer overflow
From: Paul Mackerras @ 2009-08-03 12:57 UTC (permalink / raw)
To: Roel Kluin; +Cc: linuxppc-dev, Andrew Morton
In-Reply-To: <4A76DB06.7090405@gmail.com>
Roel Kluin writes:
> Check whether index is within bounds before grabbing the element.
The change seems unnecessary since we only compute the address of the
element before the bounds check, we don't actually access the
element. I believe that is legal in C.
Paul.
^ permalink raw reply
* [PATCH] powerpc: Read buffer overflow
From: Roel Kluin @ 2009-08-03 12:41 UTC (permalink / raw)
To: Andrew Morton, linuxppc-dev, benh
Check whether index is within bounds before grabbing the element.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
---
diff --git a/drivers/macintosh/macio_asic.c b/drivers/macintosh/macio_asic.c
index a0f6838..588a5b0 100644
--- a/drivers/macintosh/macio_asic.c
+++ b/drivers/macintosh/macio_asic.c
@@ -294,10 +294,11 @@ static void macio_setup_interrupts(struct macio_dev *dev)
int i = 0, j = 0;
for (;;) {
- struct resource *res = &dev->interrupt[j];
+ struct resource *res;
if (j >= MACIO_DEV_COUNT_IRQS)
break;
+ res = &dev->interrupt[j];
irq = irq_of_parse_and_map(np, i++);
if (irq == NO_IRQ)
break;
@@ -321,9 +322,10 @@ static void macio_setup_resources(struct macio_dev *dev,
int index;
for (index = 0; of_address_to_resource(np, index, &r) == 0; index++) {
- struct resource *res = &dev->resource[index];
+ struct resource *res;
if (index >= MACIO_DEV_COUNT_RESOURCES)
break;
+ res = &dev->resource[index];
*res = r;
res->name = dev_name(&dev->ofdev.dev);
^ permalink raw reply related
* Re: [FTRACE] Enabling function_graph causes OOPS
From: Sachin Sant @ 2009-08-03 10:40 UTC (permalink / raw)
To: Steven Rostedt; +Cc: linuxppc-dev
In-Reply-To: <alpine.DEB.2.00.0907141844540.32740@gandalf.stny.rr.com>
Steven Rostedt wrote:
> Thanks,
>
> I've seen issues with my PPC box and function graph, but the bugs were
> also caused by other changes. I'll boot up my PPC64 box and see if
> I see the same issues you have.
>
Hi Steven,
I can still recreate this issue with 2.6.31-rc5. Let me know
if i can provide any information to find a solution for this.
Thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
^ permalink raw reply
* [PATCH v2 2/2] 82xx, mgcoge: update defconfig for 2.6.32
From: Heiko Schocher @ 2009-08-03 7:35 UTC (permalink / raw)
To: linuxppc-dev; +Cc: david
- add I2C support
- add FCC1 and FCC2 support
Signed-off-by: Heiko Schocher <hs@denx.de>
---
- against git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git
next branch
- checked with checkpatch.pl:
$ ./scripts/checkpatch.pl 0002-82xx-mgcoge-update-defconfig-for-2.6.32.patch
total: 0 errors, 0 warnings, 381 lines checked
0002-82xx-mgcoge-update-defconfig-for-2.6.32.patch has no obvious style problems and is ready for submission.
$
- changes since v1
- Add comments from David Gibson
removed 2 "device_type" entries
- Add comment from Kumar Gala
splittet into 2 patches (seperated defconfig patch)
arch/powerpc/configs/mgcoge_defconfig | 178 +++++++++++++++++++++++++-------
1 files changed, 139 insertions(+), 39 deletions(-)
diff --git a/arch/powerpc/configs/mgcoge_defconfig b/arch/powerpc/configs/mgcoge_defconfig
index 31e1df6..a6fe6b0 100644
--- a/arch/powerpc/configs/mgcoge_defconfig
+++ b/arch/powerpc/configs/mgcoge_defconfig
@@ -1,25 +1,27 @@
#
# Automatically generated make config: don't edit
-# Linux kernel version: 2.6.30-rc3
-# Wed May 13 17:21:55 2009
+# Linux kernel version: 2.6.31-rc4
+# Wed Jul 29 08:57:10 2009
#
# CONFIG_PPC64 is not set
#
# Processor support
#
-CONFIG_6xx=y
+CONFIG_PPC_BOOK3S_32=y
# CONFIG_PPC_85xx is not set
# CONFIG_PPC_8xx is not set
# CONFIG_40x is not set
# CONFIG_44x is not set
# CONFIG_E200 is not set
CONFIG_PPC_BOOK3S=y
+CONFIG_6xx=y
CONFIG_PPC_FPU=y
# CONFIG_ALTIVEC is not set
CONFIG_PPC_STD_MMU=y
CONFIG_PPC_STD_MMU_32=y
# CONFIG_PPC_MM_SLICES is not set
+CONFIG_PPC_HAVE_PMU_SUPPORT=y
# CONFIG_SMP is not set
CONFIG_PPC32=y
CONFIG_WORD_SIZE=32
@@ -30,15 +32,16 @@ CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_HARDIRQS=y
+CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y
# CONFIG_HAVE_SETUP_PER_CPU_AREA is not set
CONFIG_IRQ_PER_CPU=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
+CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_ARCH_HAS_ILOG2_U32=y
CONFIG_GENERIC_HWEIGHT=y
-CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_GENERIC_FIND_NEXT_BIT=y
CONFIG_GENERIC_GPIO=y
# CONFIG_ARCH_NO_VIRT_TO_BUS is not set
@@ -53,6 +56,7 @@ CONFIG_PPC_UDBG_16550=y
# CONFIG_GENERIC_TBSYNC is not set
CONFIG_AUDIT_ARCH=y
CONFIG_GENERIC_BUG=y
+CONFIG_DTC=y
# CONFIG_DEFAULT_UIMAGE is not set
CONFIG_HIBERNATE_32=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
@@ -60,6 +64,7 @@ CONFIG_ARCH_HIBERNATION_POSSIBLE=y
# CONFIG_PPC_DCR_MMIO is not set
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
+CONFIG_CONSTRUCTORS=y
#
# General setup
@@ -105,7 +110,6 @@ CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
-# CONFIG_STRIP_ASM_SYMS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
@@ -119,8 +123,15 @@ CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
+CONFIG_HAVE_PERF_COUNTERS=y
+
+#
+# Performance Counters
+#
+# CONFIG_PERF_COUNTERS is not set
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_PCI_QUIRKS=y
+# CONFIG_STRIP_ASM_SYMS is not set
CONFIG_COMPAT_BRK=y
CONFIG_SLAB=y
# CONFIG_SLUB is not set
@@ -134,6 +145,11 @@ CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_CLK=y
+
+#
+# GCOV-based kernel profiling
+#
+# CONFIG_GCOV_KERNEL is not set
# CONFIG_SLOW_WORK is not set
# CONFIG_HAVE_GENERIC_DMA_COHERENT is not set
CONFIG_SLABINFO=y
@@ -141,7 +157,7 @@ CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
# CONFIG_MODULES is not set
CONFIG_BLOCK=y
-# CONFIG_LBD is not set
+CONFIG_LBDAF=y
# CONFIG_BLK_DEV_INTEGRITY is not set
#
@@ -225,6 +241,7 @@ CONFIG_BINFMT_ELF=y
# CONFIG_HAVE_AOUT is not set
CONFIG_BINFMT_MISC=y
# CONFIG_IOMMU_HELPER is not set
+# CONFIG_SWIOTLB is not set
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
CONFIG_ARCH_HAS_WALK_MEMORY=y
CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE=y
@@ -240,9 +257,9 @@ CONFIG_MIGRATION=y
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
CONFIG_VIRT_TO_BUS=y
-CONFIG_UNEVICTABLE_LRU=y
CONFIG_HAVE_MLOCK=y
CONFIG_HAVE_MLOCKED_PAGE_BIT=y
+CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
CONFIG_PPC_4K_PAGES=y
# CONFIG_PPC_16K_PAGES is not set
# CONFIG_PPC_64K_PAGES is not set
@@ -313,6 +330,7 @@ CONFIG_IP_PNP_BOOTP=y
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_IP_MROUTE is not set
+# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
@@ -374,7 +392,11 @@ CONFIG_WIRELESS=y
CONFIG_WIRELESS_OLD_REGULATORY=y
# CONFIG_WIRELESS_EXT is not set
# CONFIG_LIB80211 is not set
-# CONFIG_MAC80211 is not set
+
+#
+# CFG80211 needs to be enabled for MAC80211
+#
+CONFIG_MAC80211_DEFAULT_PS_VALUE=0
# CONFIG_WIMAX is not set
# CONFIG_RFKILL is not set
@@ -484,6 +506,8 @@ CONFIG_MTD_PHYSMAP_OF=y
# CONFIG_MTD_UBI is not set
CONFIG_OF_DEVICE=y
CONFIG_OF_GPIO=y
+CONFIG_OF_I2C=y
+CONFIG_OF_MDIO=y
# CONFIG_PARPORT is not set
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_FD is not set
@@ -523,13 +547,17 @@ CONFIG_HAVE_IDE=y
#
#
-# A new alternative FireWire stack is available with EXPERIMENTAL=y
+# You can enable one or both FireWire driver stacks.
+#
+
+#
+# See the help texts for more information.
#
+# CONFIG_FIREWIRE is not set
# CONFIG_IEEE1394 is not set
# CONFIG_I2O is not set
# CONFIG_MACINTOSH_DRIVERS is not set
CONFIG_NETDEVICES=y
-CONFIG_COMPAT_NET_DEV_OPS=y
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
@@ -555,7 +583,8 @@ CONFIG_PHYLIB=y
# CONFIG_STE10XP is not set
# CONFIG_LSI_ET1011C_PHY is not set
CONFIG_FIXED_PHY=y
-# CONFIG_MDIO_BITBANG is not set
+CONFIG_MDIO_BITBANG=y
+# CONFIG_MDIO_GPIO is not set
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
# CONFIG_MACE is not set
@@ -577,11 +606,12 @@ CONFIG_MII=y
# CONFIG_IBM_NEW_EMAC_MAL_COMMON_ERR is not set
# CONFIG_NET_PCI is not set
# CONFIG_B44 is not set
+# CONFIG_KS8842 is not set
# CONFIG_ATL2 is not set
CONFIG_FS_ENET=y
CONFIG_FS_ENET_HAS_SCC=y
-# CONFIG_FS_ENET_HAS_FCC is not set
-# CONFIG_FS_ENET_MDIO_FCC is not set
+CONFIG_FS_ENET_HAS_FCC=y
+CONFIG_FS_ENET_MDIO_FCC=y
# CONFIG_NETDEV_1000 is not set
# CONFIG_NETDEV_10000 is not set
# CONFIG_TR is not set
@@ -652,8 +682,73 @@ CONFIG_HW_RANDOM=y
# CONFIG_APPLICOM is not set
# CONFIG_RAW_DRIVER is not set
CONFIG_DEVPORT=y
-# CONFIG_I2C is not set
+CONFIG_I2C=y
+CONFIG_I2C_BOARDINFO=y
+CONFIG_I2C_CHARDEV=y
+CONFIG_I2C_HELPER_AUTO=y
+
+#
+# I2C Hardware Bus support
+#
+
+#
+# PC SMBus host controller drivers
+#
+# CONFIG_I2C_ALI1535 is not set
+# CONFIG_I2C_ALI15X3 is not set
+# CONFIG_I2C_AMD756 is not set
+# CONFIG_I2C_AMD8111 is not set
+# CONFIG_I2C_I801 is not set
+# CONFIG_I2C_ISCH is not set
+# CONFIG_I2C_PIIX4 is not set
+# CONFIG_I2C_NFORCE2 is not set
+# CONFIG_I2C_SIS5595 is not set
+# CONFIG_I2C_SIS630 is not set
+# CONFIG_I2C_SIS96X is not set
+# CONFIG_I2C_VIAPRO is not set
+
+#
+# Mac SMBus host controller drivers
+#
+CONFIG_I2C_POWERMAC=y
+
+#
+# I2C system bus drivers (mostly embedded / system-on-chip)
+#
+CONFIG_I2C_CPM=y
+# CONFIG_I2C_DESIGNWARE is not set
+# CONFIG_I2C_GPIO is not set
+# CONFIG_I2C_MPC is not set
+# CONFIG_I2C_SIMTEC is not set
+
+#
+# External I2C/SMBus adapter drivers
+#
+# CONFIG_I2C_PARPORT_LIGHT is not set
+
+#
+# Graphics adapter I2C/DDC channel drivers
+#
+# CONFIG_I2C_VOODOO3 is not set
+
+#
+# Other I2C/SMBus bus drivers
+#
+# CONFIG_I2C_PCA_PLATFORM is not set
+
+#
+# Miscellaneous I2C Chip support
+#
+# CONFIG_PCF8575 is not set
+# CONFIG_I2C_DEBUG_CORE is not set
+# CONFIG_I2C_DEBUG_ALGO is not set
+# CONFIG_I2C_DEBUG_BUS is not set
+# CONFIG_I2C_DEBUG_CHIP is not set
# CONFIG_SPI is not set
+
+#
+# PPS support
+#
CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
CONFIG_ARCH_REQUIRE_GPIOLIB=y
CONFIG_GPIOLIB=y
@@ -667,6 +762,9 @@ CONFIG_GPIOLIB=y
#
# I2C GPIO expanders:
#
+# CONFIG_GPIO_MAX732X is not set
+# CONFIG_GPIO_PCA953X is not set
+# CONFIG_GPIO_PCF857X is not set
#
# PCI GPIO expanders:
@@ -695,24 +793,16 @@ CONFIG_SSB_POSSIBLE=y
# CONFIG_MFD_CORE is not set
# CONFIG_MFD_SM501 is not set
# CONFIG_HTC_PASIC3 is not set
+# CONFIG_TPS65010 is not set
+# CONFIG_TWL4030_CORE is not set
# CONFIG_MFD_TMIO is not set
+# CONFIG_PMIC_DA903X is not set
+# CONFIG_MFD_WM8400 is not set
+# CONFIG_MFD_WM8350_I2C is not set
+# CONFIG_MFD_PCF50633 is not set
+# CONFIG_AB3100_CORE is not set
# CONFIG_REGULATOR is not set
-
-#
-# Multimedia devices
-#
-
-#
-# Multimedia core support
-#
-# CONFIG_VIDEO_DEV is not set
-# CONFIG_DVB_CORE is not set
-# CONFIG_VIDEO_MEDIA is not set
-
-#
-# Multimedia drivers
-#
-# CONFIG_DAB is not set
+# CONFIG_MEDIA_SUPPORT is not set
#
# Graphics support
@@ -740,6 +830,10 @@ CONFIG_SSB_POSSIBLE=y
# CONFIG_DMADEVICES is not set
# CONFIG_AUXDISPLAY is not set
# CONFIG_UIO is not set
+
+#
+# TI VLYNQ
+#
# CONFIG_STAGING is not set
#
@@ -757,9 +851,10 @@ CONFIG_JBD=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_FS_POSIX_ACL is not set
-CONFIG_FILE_LOCKING=y
# CONFIG_XFS_FS is not set
# CONFIG_OCFS2_FS is not set
+CONFIG_FILE_LOCKING=y
+CONFIG_FSNOTIFY=y
CONFIG_DNOTIFY=y
CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y
@@ -916,6 +1011,7 @@ CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
CONFIG_HAVE_LMB=y
CONFIG_NLATTR=y
+CONFIG_GENERIC_ATOMIC64=y
#
# Kernel hacking
@@ -941,6 +1037,9 @@ CONFIG_DEBUG_KERNEL=y
# CONFIG_RT_MUTEX_TESTER is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_MUTEXES is not set
+# CONFIG_DEBUG_LOCK_ALLOC is not set
+# CONFIG_PROVE_LOCKING is not set
+# CONFIG_LOCK_STAT is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
# CONFIG_DEBUG_KOBJECT is not set
@@ -952,7 +1051,6 @@ CONFIG_DEBUG_INFO=y
# CONFIG_DEBUG_LIST is not set
# CONFIG_DEBUG_SG is not set
# CONFIG_DEBUG_NOTIFIERS is not set
-# CONFIG_BOOT_PRINTK_DELAY is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_RCU_CPU_STALL_DETECTOR is not set
# CONFIG_BACKTRACE_SELF_TEST is not set
@@ -966,16 +1064,15 @@ CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_TRACING_SUPPORT=y
-
-#
-# Tracers
-#
+CONFIG_FTRACE=y
# CONFIG_FUNCTION_TRACER is not set
+# CONFIG_IRQSOFF_TRACER is not set
# CONFIG_SCHED_TRACER is not set
-# CONFIG_CONTEXT_SWITCH_TRACER is not set
-# CONFIG_EVENT_TRACER is not set
+# CONFIG_ENABLE_DEFAULT_TRACERS is not set
# CONFIG_BOOT_TRACER is not set
-# CONFIG_TRACE_BRANCH_PROFILING is not set
+CONFIG_BRANCH_PROFILE_NONE=y
+# CONFIG_PROFILE_ANNOTATED_BRANCHES is not set
+# CONFIG_PROFILE_ALL_BRANCHES is not set
# CONFIG_STACK_TRACER is not set
# CONFIG_KMEMTRACE is not set
# CONFIG_WORKQUEUE_TRACER is not set
@@ -983,9 +1080,12 @@ CONFIG_TRACING_SUPPORT=y
# CONFIG_DYNAMIC_DEBUG is not set
# CONFIG_SAMPLES is not set
CONFIG_HAVE_ARCH_KGDB=y
+# CONFIG_PPC_DISABLE_WERROR is not set
+CONFIG_PPC_WERROR=y
CONFIG_PRINT_STACK_DEPTH=64
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_DEBUG_STACK_USAGE is not set
+# CONFIG_PPC_EMULATED_STATS is not set
# CONFIG_CODE_PATCHING_SELFTEST is not set
# CONFIG_FTR_FIXUP_SELFTEST is not set
# CONFIG_MSI_BITMAP_SELFTEST is not set
--
1.6.0.6
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply related
* [PATCH v2 1/2] 82xx, mgcoge: updates for 2.6.32
From: Heiko Schocher @ 2009-08-03 7:34 UTC (permalink / raw)
To: linuxppc-dev; +Cc: david
In-Reply-To: <20090729103203.GA6369@yookeroo.seuss>
[PATCH v2 1/2] 82xx, mgcoge: updates for 2.6.32
- add I2C support
- add FCC1 and FCC2 support
- fix bogus gpio numbering in plattformcode
Signed-off-by: Heiko Schocher <hs@denx.de>
---
- against git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git
next branch
- checked with checkpatch.pl:
$ ./scripts/checkpatch.pl 0001-82xx-mgcoge-updates-for-2.6.32.patch
total: 0 errors, 0 warnings, 147 lines checked
0001-82xx-mgcoge-updates-for-2.6.32.patch has no obvious style problems and is ready for submission.
$
- changes since v1
- Add comments from David Gibson
removed 2 "device_type" entries
- Add comment from Kumar Gala
splittet into 2 patches (seperated defconfig patch)
arch/powerpc/boot/dts/mgcoge.dts | 53 ++++++++++++++++++++++++++
arch/powerpc/platforms/82xx/mgcoge.c | 69 +++++++++++++++++++++++++++++----
2 files changed, 113 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/boot/dts/mgcoge.dts b/arch/powerpc/boot/dts/mgcoge.dts
index 633255a..0ce9664 100644
--- a/arch/powerpc/boot/dts/mgcoge.dts
+++ b/arch/powerpc/boot/dts/mgcoge.dts
@@ -162,6 +162,59 @@
fixed-link = <0 0 10 0 0>;
};
+ i2c@11860 {
+ compatible = "fsl,mpc8272-i2c",
+ "fsl,cpm2-i2c";
+ reg = <0x11860 0x20 0x8afc 0x2>;
+ interrupts = <1 8>;
+ interrupt-parent = <&PIC>;
+ fsl,cpm-command = <0x29600000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ mdio@10d40 {
+ compatible = "fsl,cpm2-mdio-bitbang";
+ reg = <0x10d00 0x14>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ fsl,mdio-pin = <12>;
+ fsl,mdc-pin = <13>;
+
+ phy0: ethernet-phy@0 {
+ reg = <0x0>;
+ };
+
+ phy1: ethernet-phy@1 {
+ reg = <0x1>;
+ };
+ };
+
+ /* FCC1 management to switch */
+ ethernet@11300 {
+ device_type = "network";
+ compatible = "fsl,cpm2-fcc-enet";
+ reg = <0x11300 0x20 0x8400 0x100 0x11390 0x1>;
+ local-mac-address = [ 00 01 02 03 04 07 ];
+ interrupts = <32 8>;
+ interrupt-parent = <&PIC>;
+ phy-handle = <&phy0>;
+ linux,network-index = <1>;
+ fsl,cpm-command = <0x12000300>;
+ };
+
+ /* FCC2 to redundant core unit over backplane */
+ ethernet@11320 {
+ device_type = "network";
+ compatible = "fsl,cpm2-fcc-enet";
+ reg = <0x11320 0x20 0x8500 0x100 0x113b0 0x1>;
+ local-mac-address = [ 00 01 02 03 04 08 ];
+ interrupts = <33 8>;
+ interrupt-parent = <&PIC>;
+ phy-handle = <&phy1>;
+ linux,network-index = <2>;
+ fsl,cpm-command = <0x16200300>;
+ };
};
PIC: interrupt-controller@10c00 {
diff --git a/arch/powerpc/platforms/82xx/mgcoge.c b/arch/powerpc/platforms/82xx/mgcoge.c
index c2af169..7a5de9e 100644
--- a/arch/powerpc/platforms/82xx/mgcoge.c
+++ b/arch/powerpc/platforms/82xx/mgcoge.c
@@ -50,16 +50,63 @@ struct cpm_pin {
static __initdata struct cpm_pin mgcoge_pins[] = {
/* SMC2 */
- {1, 8, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
- {1, 9, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
+ {0, 8, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
+ {0, 9, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
/* SCC4 */
- {3, 25, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
- {3, 24, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
- {3, 9, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
- {3, 8, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
- {4, 22, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
- {4, 21, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
+ {2, 25, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
+ {2, 24, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
+ {2, 9, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
+ {2, 8, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
+ {3, 22, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
+ {3, 21, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
+
+ /* FCC1 */
+ {0, 14, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
+ {0, 15, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
+ {0, 16, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
+ {0, 17, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
+ {0, 18, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
+ {0, 19, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
+ {0, 20, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
+ {0, 21, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
+ {0, 26, CPM_PIN_INPUT | CPM_PIN_SECONDARY},
+ {0, 27, CPM_PIN_INPUT | CPM_PIN_SECONDARY},
+ {0, 28, CPM_PIN_OUTPUT | CPM_PIN_SECONDARY},
+ {0, 29, CPM_PIN_OUTPUT | CPM_PIN_SECONDARY},
+ {0, 30, CPM_PIN_INPUT | CPM_PIN_SECONDARY},
+ {0, 31, CPM_PIN_INPUT | CPM_PIN_SECONDARY},
+
+ {2, 22, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
+ {2, 23, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
+
+ /* FCC2 */
+ {1, 18, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
+ {1, 19, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
+ {1, 20, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
+ {1, 21, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
+ {1, 22, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
+ {1, 23, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
+ {1, 24, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
+ {1, 25, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
+ {1, 26, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
+ {1, 27, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
+ {1, 28, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
+ {1, 29, CPM_PIN_OUTPUT | CPM_PIN_SECONDARY},
+ {1, 30, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
+ {1, 31, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
+
+ {2, 18, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
+ {2, 19, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
+
+ /* MDC */
+ {0, 13, CPM_PIN_OUTPUT | CPM_PIN_GPIO},
+
+#if defined(CONFIG_I2C_CPM)
+ /* I2C */
+ {3, 14, CPM_PIN_INPUT | CPM_PIN_SECONDARY | CPM_PIN_OPENDRAIN},
+ {3, 15, CPM_PIN_INPUT | CPM_PIN_SECONDARY | CPM_PIN_OPENDRAIN},
+#endif
};
static void __init init_ioports(void)
@@ -68,12 +115,16 @@ static void __init init_ioports(void)
for (i = 0; i < ARRAY_SIZE(mgcoge_pins); i++) {
const struct cpm_pin *pin = &mgcoge_pins[i];
- cpm2_set_pin(pin->port - 1, pin->pin, pin->flags);
+ cpm2_set_pin(pin->port, pin->pin, pin->flags);
}
cpm2_smc_clk_setup(CPM_CLK_SMC2, CPM_BRG8);
cpm2_clk_setup(CPM_CLK_SCC4, CPM_CLK7, CPM_CLK_RX);
cpm2_clk_setup(CPM_CLK_SCC4, CPM_CLK8, CPM_CLK_TX);
+ cpm2_clk_setup(CPM_CLK_FCC1, CPM_CLK10, CPM_CLK_RX);
+ cpm2_clk_setup(CPM_CLK_FCC1, CPM_CLK9, CPM_CLK_TX);
+ cpm2_clk_setup(CPM_CLK_FCC2, CPM_CLK13, CPM_CLK_RX);
+ cpm2_clk_setup(CPM_CLK_FCC2, CPM_CLK14, CPM_CLK_TX);
}
static void __init mgcoge_setup_arch(void)
--
1.6.0.6
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply related
* Re: [PATCH] Do not inline putprops function
From: M. Mohan Kumar @ 2009-08-03 5:49 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Neil Horman, Simon Horman, kexec, miltonm
In-Reply-To: <1245803263.9237.3.camel@concordia>
On Wed, Jun 24, 2009 at 10:27:43AM +1000, Michael Ellerman wrote:
> On Tue, 2009-06-23 at 09:56 -0400, Neil Horman wrote:
> > On Tue, Jun 23, 2009 at 06:25:34PM +0530, M. Mohan Kumar wrote:
> > >
> > Well it definately looks like removing that variable had some code changes.
> > It'll take some time to match it up to source, but Most interesting I think is
> > the variance in putprops around address f34. Looks like its doing some string
> > maniuplation in a reversed order, using a huge offset. Might be worthwhile to
> > check to see if theres any string overruns in this code.
>
> Yeah I still suspect it's just a bug in the code that's being exposed
> now.
>
Hi,
The same code works with gcc-3.4.
> Mohan, can you try running it under valgrind?
Still I am not able to use valgrind to debug kexec-tools
Regards,
M. Mohan Kumar.
^ permalink raw reply
* Re: [PATCH 3/20] powerpc/mm: Add HW threads support to no_hash TLB management
From: Michael Ellerman @ 2009-08-03 2:03 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1249079342.1509.99.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 1576 bytes --]
On Sat, 2009-08-01 at 08:29 +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2009-07-30 at 22:35 -0500, Kumar Gala wrote:
> > > /* XXX This clear should ultimately be part of
> > local_flush_tlb_mm */
> > > - __clear_bit(id, stale_map[cpu]);
> > > + for (cpu = cpu_first_thread_in_core(cpu);
> > > + cpu <= cpu_last_thread_in_core(cpu); cpu++)
> > > + __clear_bit(id, stale_map[cpu]);
> > > }
> >
> > This looks a bit dodgy. using 'cpu' as both the loop variable and
> > what you are computing to determine loop start/end..
> >
> Hrm... I would have thought that it was still correct... do you see any
> reason why the above code is wrong ? because if not we may be hitting a
> gcc issue...
>
> IE. At loop init, cpu gets clamped down to the first thread in the core,
> which should be fine. Then, we compare CPU to the last thread in core
> for the current CPU which should always return the same value.
>
> So I'm very interested to know what is actually wrong, ie, either I'm
> just missing something obvious, or you are just pushing a bug under the
> carpet which could come back and bit us later :-)
for (cpu = cpu_first_thread_in_core(cpu);
cpu <= cpu_last_thread_in_core(cpu); cpu++)
__clear_bit(id, stale_map[cpu]);
==
cpu = cpu_first_thread_in_core(cpu);
while (cpu <= cpu_last_thread_in_core(cpu)) {
__clear_bit(id, stale_map[cpu]);
cpu++;
}
cpu = 0
cpu <= 1
cpu++ (1)
cpu <= 1
cpu++ (2)
cpu <= 3
...
:)
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ 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