* Re: use of BAT before taking over the MMU
From: Benjamin Herrenschmidt @ 2010-10-05 8:09 UTC (permalink / raw)
To: Albert Cahalan; +Cc: linuxppc-dev
In-Reply-To: <AANLkTikPhpvJetY+NDFggYE6Wp6ppyt2BLmzEbsiwHuZ@mail.gmail.com>
On Sat, 2010-10-02 at 14:32 -0400, Albert Cahalan wrote:
> On the prom boot path, with the firmware supposed to
> be managing the MMU, there is a case where:
>
> 1. Linux changes some BAT registers.
> 2. Bits 0x00000070 are/become set in the MSR.
> 3. Linux takes an MMU fault.
Meeep ! Linux should never take an MMU fault at that point :-) If it
does, then there's a bug somewhere that needs squashing.
> 4. The firmware handles it.
>
> AFAIK, you can't expect the firmware to leave the BAT alone.
> If the firmware provides mapping services by using the BAT
> as a software-filled TLB, Linux's BAT changes may be lost.
>
> You also can't expect that your BAT changes will not conflict
> with mappings that the firmware uses for itself. The firmware
> might write to your new BAT mapping, relying on those virtual
> addresses to be something else entirely.
Right, which is why the moment Linux takes over the BATs, it shouldn't
call into FW anymore nor take faults.
Cheers,
Ben.
^ permalink raw reply
* Re: use of BAT before taking over the MMU
From: Segher Boessenkool @ 2010-10-05 7:54 UTC (permalink / raw)
To: Albert Cahalan; +Cc: linuxppc-dev
In-Reply-To: <AANLkTikt9e5s3UUn1+k=NY7UhqosM5qkgdih=UD+Hd+L@mail.gmail.com>
>> The PowerPC OF binding requires the firmware to save and restore
>> the BATs on entry to / exit from the firmware.
>
> This sucks, because using the BAT is **much** easier for
> the firmware. In my case, it also means I don't need to worry
> about Linux stomping on anything -- I have nothing in RAM.
It's easy to save and restore the BATs on firmware entry/exit,
where do you see a problem?
> Page tables would need to go in RAM. If Linux wants to
> use that memory...?
Same way as when the client uses *any* memory OF has claimed:
it has to stop calling OF from then on.
> It seems that Linux does tend to ask;
> will it panic if I refuse? Are there addresses Linux won't
> ever ask for?
Linux always "kills" OF pretty early on.
> It also looks like I could just start up Linux w/o the MMU on.
Yes, that's common and works. You will still need BATs (or
something else) to do I/O from the firmware though.
Segher
^ permalink raw reply
* Re: [PATCH 2/9] v3 Add mutex for adding/removing memory blocks
From: KAMEZAWA Hiroyuki @ 2010-10-05 5:06 UTC (permalink / raw)
To: Nathan Fontenot
Cc: Greg KH, steiner, linux-kernel, Dave Hansen, linux-mm, Robin Holt,
linuxppc-dev
In-Reply-To: <4CA62896.2060307@austin.ibm.com>
On Fri, 01 Oct 2010 13:29:42 -0500
Nathan Fontenot <nfont@austin.ibm.com> wrote:
> Add a new mutex for use in adding and removing of memory blocks. This
> is needed to avoid any race conditions in which the same memory block could
> be added and removed at the same time.
>
> Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
>
Reviewed-By: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
^ permalink raw reply
* Re: [PATCH 1/9] v3 Move find_memory_block routine
From: KAMEZAWA Hiroyuki @ 2010-10-05 5:01 UTC (permalink / raw)
To: Nathan Fontenot
Cc: Greg KH, steiner, linux-kernel, Dave Hansen, linux-mm, Robin Holt,
linuxppc-dev
In-Reply-To: <4CA62857.4030803@austin.ibm.com>
On Fri, 01 Oct 2010 13:28:39 -0500
Nathan Fontenot <nfont@austin.ibm.com> wrote:
> Move the find_memory_block() routine up to avoid needing a forward
> declaration in subsequent patches.
>
> Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
>
Reviewd-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
^ permalink raw reply
* Re: [PATCH 9/9] v3 Update memory hotplug documentation
From: KAMEZAWA Hiroyuki @ 2010-10-05 5:18 UTC (permalink / raw)
To: Nathan Fontenot
Cc: Greg KH, steiner, linux-kernel, Dave Hansen, linux-mm, Robin Holt,
linuxppc-dev
In-Reply-To: <4CA62A7D.8030905@austin.ibm.com>
On Fri, 01 Oct 2010 13:37:49 -0500
Nathan Fontenot <nfont@austin.ibm.com> wrote:
> Update the memory hotplug documentation to reflect the new behaviors of
> memory blocks reflected in sysfs.
>
> Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
>
Reviewed-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Thank you for your patient work!.
> ---
> Documentation/memory-hotplug.txt | 47 +++++++++++++++++++++++++--------------
> 1 file changed, 31 insertions(+), 16 deletions(-)
>
> Index: linux-next/Documentation/memory-hotplug.txt
> ===================================================================
> --- linux-next.orig/Documentation/memory-hotplug.txt 2010-09-29 14:56:24.000000000 -0500
> +++ linux-next/Documentation/memory-hotplug.txt 2010-09-30 14:59:47.000000000 -0500
> @@ -126,36 +126,51 @@
> --------------------------------
> 4 sysfs files for memory hotplug
> --------------------------------
> -All sections have their device information under /sys/devices/system/memory as
> +All sections have their device information in sysfs. Each section is part of
> +a memory block under /sys/devices/system/memory as
>
> /sys/devices/system/memory/memoryXXX
> -(XXX is section id.)
> +(XXX is the section id.)
>
> -Now, XXX is defined as start_address_of_section / section_size.
> +Now, XXX is defined as (start_address_of_section / section_size) of the first
> +section contained in the memory block. The files 'phys_index' and
> +'end_phys_index' under each directory report the beginning and end section id's
> +for the memory block covered by the sysfs directory. It is expected that all
> +memory sections in this range are present and no memory holes exist in the
> +range. Currently there is no way to determine if there is a memory hole, but
> +the existence of one should not affect the hotplug capabilities of the memory
> +block.
>
> For example, assume 1GiB section size. A device for a memory starting at
> 0x100000000 is /sys/device/system/memory/memory4
> (0x100000000 / 1Gib = 4)
> This device covers address range [0x100000000 ... 0x140000000)
>
> -Under each section, you can see 4 files.
> +Under each section, you can see 4 or 5 files, the end_phys_index file being
> +a recent addition and not present on older kernels.
>
> -/sys/devices/system/memory/memoryXXX/phys_index
> +/sys/devices/system/memory/memoryXXX/start_phys_index
> +/sys/devices/system/memory/memoryXXX/end_phys_index
> /sys/devices/system/memory/memoryXXX/phys_device
> /sys/devices/system/memory/memoryXXX/state
> /sys/devices/system/memory/memoryXXX/removable
>
> -'phys_index' : read-only and contains section id, same as XXX.
> -'state' : read-write
> - at read: contains online/offline state of memory.
> - at write: user can specify "online", "offline" command
> -'phys_device': read-only: designed to show the name of physical memory device.
> - This is not well implemented now.
> -'removable' : read-only: contains an integer value indicating
> - whether the memory section is removable or not
> - removable. A value of 1 indicates that the memory
> - section is removable and a value of 0 indicates that
> - it is not removable.
> +'phys_index' : read-only and contains section id of the first section
> + in the memory block, same as XXX.
> +'end_phys_index' : read-only and contains section id of the last section
> + in the memory block.
> +'state' : read-write
> + at read: contains online/offline state of memory.
> + at write: user can specify "online", "offline" command
> + which will be performed on al sections in the block.
> +'phys_device' : read-only: designed to show the name of physical memory
> + device. This is not well implemented now.
> +'removable' : read-only: contains an integer value indicating
> + whether the memory block is removable or not
> + removable. A value of 1 indicates that the memory
> + block is removable and a value of 0 indicates that
> + it is not removable. A memory block is removable only if
> + every section in the block is removable.
>
> NOTE:
> These directories/files appear after physical memory hotplug phase.
>
>
>
^ permalink raw reply
* Re: advice on reading a call trace
From: Jean-Mickael Guerin @ 2010-10-05 5:21 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <4CA9B967.9060907@6wind.com>
SLUB is turned on, and the oops does not seem to happen when SLAB replaces SLUB.
I just got lucky with SLAB, or does it sound familiar on ppc?
Regards,
Jean-Mickael
On 10/4/2010 1:24 PM, Jean-Mickael Guerin wrote:
> Hello,
> I'm stepping into ppc world and I'd like to know how to read this call trace,
> I enabled debug options but I'm not able to track the origin of this bug, I mean
> what happens before handle_page_fault():
>
> Unable to handle kernel paging request for data at address 0x00000008
> Faulting instruction address: 0xc00abcd8
>
> [c1d0dd40] [c00ab2e4] swapin_readahead+0x34/0xbc
> [c1d0dd80] [c009e91c] handle_mm_fault+0x724/0x9b0
> [c1d0dde0] [c0014e10] do_page_fault+0x2e8/0x55c
> [c1d0df40] [c000fc8c] handle_page_fault+0xc/0x80
> Instruction dump:
> 80010034 7d435378 bb210014 38210030 7c0803a6 4e800020 7d695b78 4bffff00
> 387a007c 4847616d 38000001 7c00f830 <817b0008> 7d3c0214 7f895840 7f9ee378
> Kernel panic - not syncing: Fatal exception
>
> Another one:
> NIP: c00b6980 LR: c00b6978 CTR: 0f9ffb20
> REGS: d6a9dc60 TRAP: 0300 Not tainted (2.6.34.6-00392-g31e1857)
> MSR: 10029002 CR: 24004442 XER: 00000000
> DEAR: 00000008, ESR: 00000000
> TASK = da6a7440[4915] 'smrd' THREAD: d6a9c000 CPU: 0
> GPR00: 00000008 d6a9dd10 da6a7440 c0738340 00000000 00000000 00000000 00000001
> GPR08: 00000000 00000000 c00b6978 00000000 44004442 10027f04 c077790c d79f94a8
> GPR16: d6a9dd88 c07a0000 d72301f0 d6a9c000 000001ff 00000000 0f9ffb20 da5c6f78
> GPR24: d79f9440 c0738340 d6a9dd48 00000000 07832400 00000001 00000003 07832400
> NIP [c00b6980] valid_swaphandles+0x19c/0x1d0
> LR [c00b6978] valid_swaphandles+0x194/0x1d0
> Call Trace:
> [d6a9dd10] [c00b6978] valid_swaphandles+0x194/0x1d0 (unreliable)
> [d6a9dd40] [c00b5a10] swapin_readahead+0x34/0xbc
> [d6a9dd80] [c00a9064] handle_mm_fault+0x7c0/0x868
> [d6a9dde0] [c00158d8] do_page_fault+0x2fc/0x570
> [d6a9df40] [c001061c] handle_page_fault+0xc/0x80
> Instruction dump:
> 38210030 7c0803a6 4e800020 7d695b78 4bffff04 3d20c074 39298300 3b290040
> 7f23cb78 484843a9 38000001 7c00f030 <817b0008> 7d3f0214 7f895840 7ffdfb78
> Kernel panic - not syncing: Fatal exception
> Call Trace:
> [d6a9dba0] [c000765c] show_stack+0x40/0x15c (unreliable)
> [d6a9dbd0] [c053b780] panic+0x94/0x118
> [d6a9dc20] [c000d630] die+0x15c/0x1bc
> [d6a9dc40] [c00155a4] bad_page_fault+0x90/0xc8
> [d6a9dc50] [c001068c] handle_page_fault+0x7c/0x80
> [d6a9dd10] [c00b6978] valid_swaphandles+0x194/0x1d0
> [d6a9dd40] [c00b5a10] swapin_readahead+0x34/0xbc
> [d6a9dd80] [c00a9064] handle_mm_fault+0x7c0/0x868
> [d6a9dde0] [c00158d8] do_page_fault+0x2fc/0x570
> [d6a9df40] [c001061c] handle_page_fault+0xc/0x80
> Rebooting in 5 seconds..
>
> Thanks,
> Jean-Mickael
^ permalink raw reply
* Re: [PATCH 6/9] v3 Update node sysfs code
From: KAMEZAWA Hiroyuki @ 2010-10-05 5:15 UTC (permalink / raw)
To: Nathan Fontenot
Cc: Greg KH, steiner, linux-kernel, Dave Hansen, linux-mm, Robin Holt,
linuxppc-dev
In-Reply-To: <4CA629BA.60100@austin.ibm.com>
On Fri, 01 Oct 2010 13:34:34 -0500
Nathan Fontenot <nfont@austin.ibm.com> wrote:
> Update the node sysfs code to be aware of the new capability for a memory
> block to contain multiple memory sections and be aware of the memory block
> structure name changes (start_section_nr). This requires an additional
> parameter to unregister_mem_sect_under_nodes so that we know which memory
> section of the memory block to unregister.
>
> Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
Reviewed-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
^ permalink raw reply
* Re: [PATCH 5/9] v3 rename phys_index properties of memory block struct
From: KAMEZAWA Hiroyuki @ 2010-10-05 5:14 UTC (permalink / raw)
To: Nathan Fontenot
Cc: Greg KH, steiner, linux-kernel, Dave Hansen, linux-mm, Robin Holt,
linuxppc-dev
In-Reply-To: <4CA62982.5080900@austin.ibm.com>
On Fri, 01 Oct 2010 13:33:38 -0500
Nathan Fontenot <nfont@austin.ibm.com> wrote:
> Update the 'phys_index' property of a the memory_block struct to be
> called start_section_nr, and add a end_section_nr property. The
> data tracked here is the same but the updated naming is more in line
> with what is stored here, namely the first and last section number
> that the memory block spans.
>
> The names presented to userspace remain the same, phys_index for
> start_section_nr and end_phys_index for end_section_nr, to avoid breaking
> anything in userspace.
>
> Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
Reviewed-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
^ permalink raw reply
* Re: [PATCH 4/9] v3 Allow memory blocks to span multiple memory sections
From: KAMEZAWA Hiroyuki @ 2010-10-05 5:13 UTC (permalink / raw)
To: Nathan Fontenot
Cc: Greg KH, steiner, linux-kernel, Dave Hansen, linux-mm, Robin Holt,
linuxppc-dev
In-Reply-To: <4CA62FE2.2000003@austin.ibm.com>
On Fri, 01 Oct 2010 14:00:50 -0500
Nathan Fontenot <nfont@austin.ibm.com> wrote:
> Update the memory sysfs code such that each sysfs memory directory is now
> considered a memory block that can span multiple memory sections per
> memory block. The default size of each memory block is SECTION_SIZE_BITS
> to maintain the current behavior of having a single memory section per
> memory block (i.e. one sysfs directory per memory section).
>
> For architectures that want to have memory blocks span multiple
> memory sections they need only define their own memory_block_size_bytes()
> routine.
>
This should be commented in code before MEMORY_BLOCK_SIZE declaration.
> Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
>
Reviewed-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
^ permalink raw reply
* Re: [PATCH 3/9] v3 Add section count to memory_block struct
From: KAMEZAWA Hiroyuki @ 2010-10-05 5:08 UTC (permalink / raw)
To: Nathan Fontenot
Cc: Greg KH, steiner, linux-kernel, Dave Hansen, linux-mm, Robin Holt,
linuxppc-dev
In-Reply-To: <4CA628D0.6030508@austin.ibm.com>
On Fri, 01 Oct 2010 13:30:40 -0500
Nathan Fontenot <nfont@austin.ibm.com> wrote:
> Add a section count property to the memory_block struct to track the number
> of memory sections that have been added/removed from a memory block. This
> allows us to know when the last memory section of a memory block has been
> removed so we can remove the memory block.
>
> Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
>
Reviewed-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
a nitpick,
> Index: linux-next/include/linux/memory.h
> ===================================================================
> --- linux-next.orig/include/linux/memory.h 2010-09-29 14:56:29.000000000 -0500
> +++ linux-next/include/linux/memory.h 2010-09-30 14:13:50.000000000 -0500
> @@ -23,6 +23,8 @@
> struct memory_block {
> unsigned long phys_index;
> unsigned long state;
> + int section_count;
I prefer
int section_count; /* updated under mutex */
or some for this kind of non-atomic counters. but nitpick.
^ permalink raw reply
* Re: Introduce support for little endian PowerPC
From: Benjamin Herrenschmidt @ 2010-10-04 22:50 UTC (permalink / raw)
To: Michel Dänzer; +Cc: paulus, linuxppc-dev, linux-kernel, Ian Munsie
In-Reply-To: <1286188242.15020.349.camel@thor.local>
On Mon, 2010-10-04 at 12:30 +0200, Michel Dänzer wrote:
> > And last I looked X still pukes if you give it a pixmap in non native
> > byte order but that might have been fixed.
>
> I'm not sure what exactly you mean by that, but I'm not aware of any
> such issues offhand.
Hrm, I meant on the DDX side. Anyways, doesn't matter. Even if it works
fine on X side. Fact is, there's tons and tons of existing SW stack and
drivers on the field that are totally incapable of doing BE and
essentially unfixable without major work that the customer(s) is(are)
unwilling to do at this stage.
(Think embedded gfx IP cores mostly, including codecs etc...)
> I didn't say anything about that, just that IME it should be mostly
> possible to deal with endianness within the driver stack.
To some extent yes. Completely, I'm not sure. Apps manipulating pixels,
such as video players doing hand-made overlay etc... will potentially
have issues. It's more than actual pixel byte ordering. It's anything
that accesses a quantity in memory using different size accessors, ie,
storing a u32 and then expecting to find the LSB at u8* of the same
address etc... that sort of stuff happens more often in gfx-oriented
code than anywhere else in my experience.
> Note that I'm not arguing against these changes, just pointing out some
> apparent inaccuracies in the reasoning for them.
Right, I possibly made an incorrect statement relative to Xorg (I had
assumed the fb layer only worked properly in native endian format), but
that doesn't matter much since the problem here is existing code &
drivers and goes way beyond X (probably no X on the target setups
anyways).
Cheers,
Ben
^ permalink raw reply
* Re: in_atomic() check in page_cache_get_speculative()
From: Scott Wood @ 2010-10-04 20:37 UTC (permalink / raw)
To: Nick Piggin, linuxppc-dev
In-Reply-To: <20101004152259.25c56ad2@udp111988uds.am.freescale.net>
[Updated with Nick's current address; previous one bounced]
On Mon, 4 Oct 2010 15:22:59 -0500
Scott Wood <scottwood@freescale.com> wrote:
> I'm seeing the in_atomic() check in page_cache_get_speculative()
> (linux/pagemap.h:138) fail when running e500 KVM with .
Sorry, that should finish as "with CONFIG_DEBUG_VM."
> It's coming
> from get_user_pages_fast(), from KVM's hva_to_pfn(). This is on kvm.git
> plus a few local patches that should be completely unrelated, but it
> looks like this code hasn't changed much in a couple years.
>
> Interrupts are disabled by get_user_pages_fast(), but apparently
> preemption was not separately disabled. The comment in
> page_cache_get_speculative() says that preemption disabling is done by
> rcu_read_lock(), and that "this function must be called inside the same
> rcu_read_lock() section as has been used to lookup the page in the
> pagecache radix-tree (or page table)".
>
> Where is this RCU lock supposed to be acquired? I don't see any RCU in
> arch/powerpc/mm/gup.c. Is it buried in some macro or function call?
>
> -Scott
^ permalink raw reply
* in_atomic() check in page_cache_get_speculative()
From: Scott Wood @ 2010-10-04 20:22 UTC (permalink / raw)
To: Nick Piggin, linuxppc-dev
I'm seeing the in_atomic() check in page_cache_get_speculative()
(linux/pagemap.h:138) fail when running e500 KVM with . It's coming
from get_user_pages_fast(), from KVM's hva_to_pfn(). This is on kvm.git
plus a few local patches that should be completely unrelated, but it
looks like this code hasn't changed much in a couple years.
Interrupts are disabled by get_user_pages_fast(), but apparently
preemption was not separately disabled. The comment in
page_cache_get_speculative() says that preemption disabling is done by
rcu_read_lock(), and that "this function must be called inside the same
rcu_read_lock() section as has been used to lookup the page in the
pagecache radix-tree (or page table)".
Where is this RCU lock supposed to be acquired? I don't see any RCU in
arch/powerpc/mm/gup.c. Is it buried in some macro or function call?
-Scott
^ permalink raw reply
* RE: [PATCH] PPC4xx: ADMA separating SoC specific functions
From: Tirumala Marri @ 2010-10-04 17:30 UTC (permalink / raw)
To: Greg KH, Dan Williams
Cc: linux-raid, linuxppc-dev, Wolfgang Denk, yur, linux-crypto
In-Reply-To: <20101002184957.GA17774@kroah.com>
> >
> > You definitely need to be able to resolve "used but not defined" and
> > "defined but not used" warnings before tackling a driver conversion
> > like this. In light of this comment I wonder if it would be
> > appropriate to submit your original driver, that just duplicated
> > routines from the ppc440spe driver, to the -staging tree. Then it
> > would be available for someone familiar with driver conversions to
> > take a shot at unifying.
> >
> > Greg, is this an appropriate use of -staging?
>
> Possibly, but I really don't like duplication if possible. What's
> keeping this code from being fixed up now properly?
[Marri] Hello Greg, I am working on restructuring ppc4xx/adma.c driver
into
Common code and SoC specific code. This way I can add support for similar
DMA engines.
In this process I had to declare some Of the functions non static so that
I can suppress "defined but not used" and "used but not defined".
Here is what series of patches I planned to work on.
1. First set patches to re-arrange the code. Functionally no change except
Structured into different files.
2. Second set to rename the common functions which are shared between SoC
dma-engines.
3. Add support of new DMA engine for different SoC.
I am working on first patch set right now.
Regards,
Marri
^ permalink raw reply
* Re: powerpc, fs_enet: scanning PHY after Linux is up
From: Grant Likely @ 2010-10-04 16:20 UTC (permalink / raw)
To: hs; +Cc: linuxppc-dev, devicetree-discuss, Holger Brunck, Detlev Zundel,
netdev
In-Reply-To: <4CA9830A.2030605@denx.de>
On Mon, Oct 4, 2010 at 1:32 AM, Heiko Schocher <hs@denx.de> wrote:
> Hello all,
>
> we have on the mgcoge arch/powerpc/boot/dts/mgcoge.dts 3 fs_enet
> devices. The first is accessible on boot, and so get correct
> probed and works fine. For the other two fs_enet devices the PHYs
> are on startup in reset, and gets later, through userapplikations,
> out of reset ... so, on bootup, this 2 fs_enet devices could
> not detect the PHY in drivers/of/of_mdio.c of_mdiobus_register(),
> and if we want to use them later, we get for example:
>
> -bash-3.2# ifconfig eth2 172.31.31.33
> net eth2: Could not attach to PHY
> SIOCSIFFLAGS: No such device
>
> So the problem is, that we cannot rescan the PHYs, if they are
> accessible. Also we could not load the fs_enet driver as a module,
> because the first port is used fix.
>
> So, first question which comes in my mind, is:
>
> Is detecting the phy in drivers/of/of_mdio.c of_mdiobus_register()
> the right place, or should it not better be done, when really
> using the port?
>
> But we found another way to solve this issue:
>
> After the PHYs are out of reset, we just have to rescan the PHYs
> with (for example PHY with addr 1)
>
> err =3D mdiobus_scan(bus, 1);
>
> and
>
> of_find_node_by_path("/soc@f0000000/cpm@119c0/mdio@10d40/ethernet-phy@1")=
;
> of_node_get(np);
> dev_archdata_set_node(&err->dev.archdata, np);
>
> but thats just a hack ...
Yeah, that's a hack. It really needs to be done via the of_mdio
mechanisms so that dt <--> phy_device linkages remain consistent.
> So, the question is, is there a possibility to solve this problem?
>
> If there is no standard option, what would be with adding a
> "scan_phy" file in
>
> /proc/device-tree/soc\@f0000000/cpm\@119c0/mdio\@10d40
> (or better destination?)
>
> which with we could rescan a PHY with
> "echo addr > /proc/device-tree/soc\@f0000000/cpm\@119c0/mdio\@10d40/scan_=
phy"
> (so there is no need for using of_find_node_by_path(), as we should
> =A0have the associated device node here, and can step through the child
> =A0nodes with "for_each_child_of_node(np, child)" and check if reg =3D=3D=
addr)
>
> or shouldn;t be at least, if the phy couldn;t be found when opening
> the port, retrigger a scanning, if the phy now is accessible?
One option would be to still register a phy_device for each phy
described in the device tree, but defer binding a driver to each phy
that doesn't respond. Then at of_phy_find_device() time, if it
matches with a phy_device that isn't bound to a driver yet, then
re-trigger the binding operation. At which point the phy id can be
probed and the correct driver can be chosen. If binding succeeds,
then return the phy_device handle. If not, then fail as it currently
does.
g.
^ permalink raw reply
* Re: use of BAT before taking over the MMU
From: Albert Cahalan @ 2010-10-04 16:06 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <63799.84.105.60.153.1286166325.squirrel@gate.crashing.org>
On Mon, Oct 4, 2010 at 12:25 AM, Segher Boessenkool
<segher@kernel.crashing.org> wrote:
> The PowerPC OF binding requires the firmware to save and restore
> the BATs on entry to / exit from the firmware.
This sucks, because using the BAT is **much** easier for
the firmware. In my case, it also means I don't need to worry
about Linux stomping on anything -- I have nothing in RAM.
(this is an emulator, but I don't want to cheat too much
because adding special cases affects performance)
Page tables would need to go in RAM. If Linux wants to
use that memory...? It seems that Linux does tend to ask;
will it panic if I refuse? Are there addresses Linux won't
ever ask for?
It also looks like I could just start up Linux w/o the MMU on.
I'm just making 1:1 mappings anyway.
^ permalink raw reply
* Re: Serial RapidIO Maintaintance read causes lock up
From: Bounine, Alexandre @ 2010-10-04 15:49 UTC (permalink / raw)
To: bastiaan.nijkamp; +Cc: linuxppc-dev
Hi Bastiaan,
Are you trying board-to-board connection?
I am not familiar with WRS SBC8548 board - which type of connector they
use for SRIO?
Assuming that all configuration is correct,
I would recommend first to try setting up x1 link mode at the lowest
link speed.
The x4 mode may present challenges in some cases.
For quick test you may just add port width override into fsl_rio.c
like shown below (ugly but sometimes it helps ;) ):
@@ -1461,10 +1461,16 @@ int fsl_rio_setup(struct platform_device *dev)
rio_register_mport(port);
=20
priv->regs_win =3D ioremap(regs.start, regs.end - regs.start + 1);
rio_regs_win =3D priv->regs_win;
=20
+dev_info(&dev->dev, "Overriding RIO_PORT setting to single lane 0\n");
+out_be32(priv->regs_win + 0x15C, in_be32(priv->regs_win + 0x15C) |
0x800000);
+out_be32(priv->regs_win + 0x15C, in_be32(priv->regs_win + 0x15C) |
0x2000000);
+out_be32(priv->regs_win + 0x15C, in_be32(priv->regs_win + 0x15C) &
~0x800000);
+msleep(100);
+
/* Probe the master port phy type */
ccsr =3D in_be32(priv->regs_win + RIO_CCSR);
port->phy_type =3D (ccsr & 1) ? RIO_PHY_SERIAL : RIO_PHY_PARALLEL;
dev_info(&dev->dev, "RapidIO PHY type: %s\n",
(port->phy_type =3D=3D RIO_PHY_PARALLEL) ?
"parallel" :
Let me know what happens.
Please keep me in the CC: list next time when posting RapidIO questions
to the linuxppc-dev or kernel mailing lists.
Regards,
Alex.
=20
^ permalink raw reply
* Re: [PATCH 2/3 v4] P4080/mtd: Only make elbc nand driver detect nand flash partitions
From: Scott Wood @ 2010-10-04 15:38 UTC (permalink / raw)
To: Zang Roy-R61911
Cc: Wood Scott-B07421, dedekind1, Lan Chunhe-B25806, linuxppc-dev,
linux-mtd, akpm, dwmw2, Gala Kumar-B11780
In-Reply-To: <3850A844E6A3854C827AC5C0BEC7B60A256099@zch01exm23.fsl.freescale.net>
On Sat, 2 Oct 2010 05:36:27 -0700
"Zang Roy-R61911" <r61911@freescale.com> wrote:
>
>
> > -----Original Message-----
> > From: Anton Vorontsov [mailto:cbouatmailru@gmail.com]
> > Sent: Monday, September 20, 2010 21:19 PM
> > To: Zang Roy-R61911
> > Cc: linux-mtd@lists.infradead.org; dwmw2@infradead.org; dedekind1@gmail.com;
> > akpm@linux-foundation.org; Lan Chunhe-B25806; Wood Scott-B07421; Gala Kumar-
> > B11780; linuxppc-dev@ozlabs.org
> > Subject: Re: [PATCH 2/3 v4] P4080/mtd: Only make elbc nand driver detect nand
> > flash partitions
> >
> > On Fri, Sep 17, 2010 at 03:01:08PM +0800, Roy Zang wrote:
> > [...]
> > > +static struct mutex fsl_elbc_nand_mutex;
> > > +
> > > +static int __devinit fsl_elbc_nand_probe(struct platform_device *dev)
> > > {
> > > - struct fsl_lbc_regs __iomem *lbc = ctrl->regs;
> > > + struct fsl_lbc_regs __iomem *lbc;
> > > struct fsl_elbc_mtd *priv;
> > > struct resource res;
> > > + struct fsl_elbc_fcm_ctrl *elbc_fcm_ctrl = NULL;
> >
> > No need for = NULL.
> Any harm? Or just personal habit or style? Can you explain about why?
Besides not wanting superfluous code on general principle, it could
hide a bug if in the future the real initialization is missing on some
code path. It would become a runtime NULL dereference rather than a
compiler warning.
-Scott
^ permalink raw reply
* Re: [PATCH 7/9] v3 Define memory_block_size_bytes for powerpc/pseries
From: Nathan Fontenot @ 2010-10-04 14:45 UTC (permalink / raw)
To: balbir
Cc: Greg KH, steiner, linux-kernel, Dave Hansen, linux-mm, Robin Holt,
linuxppc-dev, KAMEZAWA Hiroyuki
In-Reply-To: <20101003182701.GI7896@balbir.in.ibm.com>
On 10/03/2010 01:27 PM, Balbir Singh wrote:
> * Dave Hansen <dave@linux.vnet.ibm.com> [2010-10-03 11:11:01]:
>
>> On Sun, 2010-10-03 at 13:07 -0500, Robin Holt wrote:
>>> On Sun, Oct 03, 2010 at 11:25:00PM +0530, Balbir Singh wrote:
>>>> * Nathan Fontenot <nfont@austin.ibm.com> [2010-10-01 13:35:54]:
>>>>
>>>>> Define a version of memory_block_size_bytes() for powerpc/pseries such that
>>>>> a memory block spans an entire lmb.
>>>>
>>>> I hope I am not missing anything obvious, but why not just call it
>>>> lmb_size, why do we need memblock_size?
>>>>
>>>> Is lmb_size == memblock_size after your changes true for all
>>>> platforms?
>>>
>>> What is an lmb? I don't recall anything like lmb being referred to in
>>> the rest of the kernel.
>>
>> Heh. It's the OpenFirmware name for a Logical Memory Block. Basically
>> what we use to determine the SECTION_SIZE on powerpc. Probably not the
>> best terminology to use elsewhere in the kernel.
>
> Agreed for the kernel, this patch was for powerpc/pseries, hence was
> checking in this context.
>
I don't really see a reason to name it lmb_size, it seems easier
to stick with the naming used by the rest of the kernel.
-Nathan
^ permalink raw reply
* advice on reading a call trace
From: Jean-Mickael Guerin @ 2010-10-04 11:24 UTC (permalink / raw)
To: linuxppc-dev
Hello,
I'm stepping into ppc world and I'd like to know how to read this call trace,
I enabled debug options but I'm not able to track the origin of this bug, I mean
what happens before handle_page_fault():
Unable to handle kernel paging request for data at address 0x00000008
Faulting instruction address: 0xc00abcd8
[c1d0dd40] [c00ab2e4] swapin_readahead+0x34/0xbc
[c1d0dd80] [c009e91c] handle_mm_fault+0x724/0x9b0
[c1d0dde0] [c0014e10] do_page_fault+0x2e8/0x55c
[c1d0df40] [c000fc8c] handle_page_fault+0xc/0x80
Instruction dump:
80010034 7d435378 bb210014 38210030 7c0803a6 4e800020 7d695b78 4bffff00
387a007c 4847616d 38000001 7c00f830 <817b0008> 7d3c0214 7f895840 7f9ee378
Kernel panic - not syncing: Fatal exception
Another one:
NIP: c00b6980 LR: c00b6978 CTR: 0f9ffb20
REGS: d6a9dc60 TRAP: 0300 Not tainted (2.6.34.6-00392-g31e1857)
MSR: 10029002 CR: 24004442 XER: 00000000
DEAR: 00000008, ESR: 00000000
TASK = da6a7440[4915] 'smrd' THREAD: d6a9c000 CPU: 0
GPR00: 00000008 d6a9dd10 da6a7440 c0738340 00000000 00000000 00000000 00000001
GPR08: 00000000 00000000 c00b6978 00000000 44004442 10027f04 c077790c d79f94a8
GPR16: d6a9dd88 c07a0000 d72301f0 d6a9c000 000001ff 00000000 0f9ffb20 da5c6f78
GPR24: d79f9440 c0738340 d6a9dd48 00000000 07832400 00000001 00000003 07832400
NIP [c00b6980] valid_swaphandles+0x19c/0x1d0
LR [c00b6978] valid_swaphandles+0x194/0x1d0
Call Trace:
[d6a9dd10] [c00b6978] valid_swaphandles+0x194/0x1d0 (unreliable)
[d6a9dd40] [c00b5a10] swapin_readahead+0x34/0xbc
[d6a9dd80] [c00a9064] handle_mm_fault+0x7c0/0x868
[d6a9dde0] [c00158d8] do_page_fault+0x2fc/0x570
[d6a9df40] [c001061c] handle_page_fault+0xc/0x80
Instruction dump:
38210030 7c0803a6 4e800020 7d695b78 4bffff04 3d20c074 39298300 3b290040
7f23cb78 484843a9 38000001 7c00f030 <817b0008> 7d3f0214 7f895840 7ffdfb78
Kernel panic - not syncing: Fatal exception
Call Trace:
[d6a9dba0] [c000765c] show_stack+0x40/0x15c (unreliable)
[d6a9dbd0] [c053b780] panic+0x94/0x118
[d6a9dc20] [c000d630] die+0x15c/0x1bc
[d6a9dc40] [c00155a4] bad_page_fault+0x90/0xc8
[d6a9dc50] [c001068c] handle_page_fault+0x7c/0x80
[d6a9dd10] [c00b6978] valid_swaphandles+0x194/0x1d0
[d6a9dd40] [c00b5a10] swapin_readahead+0x34/0xbc
[d6a9dd80] [c00a9064] handle_mm_fault+0x7c0/0x868
[d6a9dde0] [c00158d8] do_page_fault+0x2fc/0x570
[d6a9df40] [c001061c] handle_page_fault+0xc/0x80
Rebooting in 5 seconds..
Thanks,
Jean-Mickael
^ permalink raw reply
* Re: Introduce support for little endian PowerPC
From: Michel Dänzer @ 2010-10-04 10:30 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: paulus, linuxppc-dev, linux-kernel, Ian Munsie
In-Reply-To: <1285966204.2463.137.camel@pasglop>
On Sam, 2010-10-02 at 06:50 +1000, Benjamin Herrenschmidt wrote:=20
> On Fri, 2010-10-01 at 18:20 +0200, Michel D=C3=A4nzer wrote:
> > On Fre, 2010-10-01 at 22:14 +1000, Benjamin Herrenschmidt wrote:=20
> > >=20
> > > Now, the main reasons in practice are anything touching graphics.
> > >=20
> > > There's quite a few IP cores out there for SoCs that don't have HW
> > > swappers, and -tons- of more or less ugly code that can't deal with n=
on
> > > native pixel ordering (hell, even Xorg isn't good at it, we really on=
ly
> > > support cards that have HW swappers today).
> >=20
> > That's not true. Even the radeon driver doesn't really need the HW
> > swappers anymore with KMS.
>=20
> And last I looked X still pukes if you give it a pixmap in non native
> byte order but that might have been fixed.
I'm not sure what exactly you mean by that, but I'm not aware of any
such issues offhand.
> > > There's an even bigger pile of application code that deals with graph=
ics
> > > without any regard for endianness and is essentially unfixable.
> >=20
> > Out of curiosity, what kind of APIs are those apps using? X11 and OpenG=
L
> > have well-defined semantics wrt endianness, allowing the drivers to
> > handle any necessary byte swapping internally, and IME the vast majorit=
y
> > of apps handle this correctly.
>=20
> So why is it so hard to get any video card working on ppc ? :-)
I didn't say anything about that, just that IME it should be mostly
possible to deal with endianness within the driver stack.
Note that I'm not arguing against these changes, just pointing out some
apparent inaccuracies in the reasoning for them.
--=20
Earthling Michel D=C3=A4nzer | http://www.vmware.c=
om
Libre software enthusiast | Debian, X and DRI developer
^ permalink raw reply
* Ppc to PowerPC changes relating to XGPIO
From: Guillaume Dargaud @ 2010-10-04 9:33 UTC (permalink / raw)
To: linuxppc-dev
Hello all,
when I was using the PPC kernel a couple versions back, I had modified the
xgpio_ioctl.h file (and its related adapter.c) in order to extend the
xgpio_ioctl() function with new commands for my needs.
But now I don't see where the equivalent code is located with the new
architecture. How do I interact win GPIOs from usermode if not for ioctl calls
? (I need to manipulate the direction bits, not just read/write values).
Note: I'm using the kernel provided by the Xilinx git, so maybe my question
isn't relevant here.
Thanks
--
Guillaume Dargaud
http://www.gdargaud.net/
^ permalink raw reply
* powerpc, fs_enet: scanning PHY after Linux is up
From: Heiko Schocher @ 2010-10-04 7:32 UTC (permalink / raw)
To: linuxppc-dev; +Cc: netdev, devicetree-discuss, Holger Brunck, Detlev Zundel
Hello all,
we have on the mgcoge arch/powerpc/boot/dts/mgcoge.dts 3 fs_enet
devices. The first is accessible on boot, and so get correct
probed and works fine. For the other two fs_enet devices the PHYs
are on startup in reset, and gets later, through userapplikations,
out of reset ... so, on bootup, this 2 fs_enet devices could
not detect the PHY in drivers/of/of_mdio.c of_mdiobus_register(),
and if we want to use them later, we get for example:
-bash-3.2# ifconfig eth2 172.31.31.33
net eth2: Could not attach to PHY
SIOCSIFFLAGS: No such device
So the problem is, that we cannot rescan the PHYs, if they are
accessible. Also we could not load the fs_enet driver as a module,
because the first port is used fix.
So, first question which comes in my mind, is:
Is detecting the phy in drivers/of/of_mdio.c of_mdiobus_register()
the right place, or should it not better be done, when really
using the port?
But we found another way to solve this issue:
After the PHYs are out of reset, we just have to rescan the PHYs
with (for example PHY with addr 1)
err = mdiobus_scan(bus, 1);
and
of_find_node_by_path("/soc@f0000000/cpm@119c0/mdio@10d40/ethernet-phy@1");
of_node_get(np);
dev_archdata_set_node(&err->dev.archdata, np);
but thats just a hack ...
So, the question is, is there a possibility to solve this problem?
If there is no standard option, what would be with adding a
"scan_phy" file in
/proc/device-tree/soc\@f0000000/cpm\@119c0/mdio\@10d40
(or better destination?)
which with we could rescan a PHY with
"echo addr > /proc/device-tree/soc\@f0000000/cpm\@119c0/mdio\@10d40/scan_phy"
(so there is no need for using of_find_node_by_path(), as we should
have the associated device node here, and can step through the child
nodes with "for_each_child_of_node(np, child)" and check if reg == addr)
or shouldn;t be at least, if the phy couldn;t be found when opening
the port, retrigger a scanning, if the phy now is accessible?
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply
* Re: use of BAT before taking over the MMU
From: Segher Boessenkool @ 2010-10-04 4:25 UTC (permalink / raw)
To: Albert Cahalan; +Cc: linuxppc-dev
In-Reply-To: <AANLkTikPhpvJetY+NDFggYE6Wp6ppyt2BLmzEbsiwHuZ@mail.gmail.com>
> On the prom boot path, with the firmware supposed to
> be managing the MMU, there is a case where:
>
> 1. Linux changes some BAT registers.
> 2. Bits 0x00000070 are/become set in the MSR.
> 3. Linux takes an MMU fault.
> 4. The firmware handles it.
>
> AFAIK, you can't expect the firmware to leave the BAT alone.
> If the firmware provides mapping services by using the BAT
> as a software-filled TLB, Linux's BAT changes may be lost.
>
> You also can't expect that your BAT changes will not conflict
> with mappings that the firmware uses for itself. The firmware
> might write to your new BAT mapping, relying on those virtual
> addresses to be something else entirely.
The PowerPC OF binding requires the firmware to save and restore
the BATs on entry to / exit from the firmware.
Segher
^ permalink raw reply
* Re: ppc44x - how do i optimize driver for tlb hits
From: Benjamin Herrenschmidt @ 2010-10-03 22:38 UTC (permalink / raw)
To: Ayman El-Khashab; +Cc: linuxppc-dev
In-Reply-To: <20101003191305.GA7345@crust.elkhashab.com>
On Sun, 2010-10-03 at 14:13 -0500, Ayman El-Khashab wrote:
> On Sat, Sep 25, 2010 at 08:11:04AM +1000, Benjamin Herrenschmidt wrote:
> > On Fri, 2010-09-24 at 08:08 -0500, Ayman El-Khashab wrote:
> > >
> > > I suppose another option is to to use the kernel profiling option I
> > > always see but have never used. Is that a viable option to figure out
> > > what is happening here?
> >
> > With perf and stochastic sampling ? If you sample fast enough... but
> > you'll mostly point to your routine I suppose... though it might tell
> > you statistically where in your code, which -might- help.
> >
>
> Thanks I didn't end up profiling it b/c we found the biggest culprit.
> Basically we were mapping this memory in kernel space and as long as we
> did that ONLY everything was ok. But then we would mmap the physical
> addresses into user space. Using MAP_SHARED made it extremely slow.
> Using MAP_PRIVATE made it very fast. So it works, but why is MAP_SHARED
> that much slower?
I don't see any reason off hand why this would be the case. Can you
inspect the content of the TLB with either xmon or whatever HW debugger
you may have at hand and show me what difference you have between an
entry for your workload coming from MAP_SHARED vs. one coming from
MAP_PRIVATE ?
> The other optimization was a change in the algorithm to take advantage
> of the L2 prefetching. Since we were operating on many simultaneous
> streams it seems that the cache performance was not good.
Cheers,
Ben.
> thanks
> ame
^ 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