Re: How to handle PTE tables with non contiguous entries ?

Hello Cristophe. > On Sep 10, 2018, at 7:34 AM, Christophe Leroy wrote: > > On the powerpc8xx, handling 16k size pages requires to have page tables with > 4 identical entries. Do you think a 16k page is useful? Back in the day, the goal was to keep the fault handling and management

Re: [RFC] Implementing HUGEPAGE on MPC 8xx

Hello Christophe. I’m surprised there is still any interest in this processor family :) On Jun 8, 2016, at 12:03 AM, Christophe Leroy wrote: > MPC 8xx has several page sizes: 4k, 16k, 512k and 8M. > Today, 4k and 16k sizes are implemented as normal page sizes and 8M

Re: fsqrt

On Jun 7, 2013, at 4:30 PM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: Right, looking more, the code really sucks. Hey! :) …. Either you use the existing apparent ability for MATH_EMU to operate in minimal mode, ie, load/store/fmr only (which seems to do exactly the same

Re: fsqrt

Hi Ben. On Jun 7, 2013, at 5:34 PM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: The question is whether this is still relevant ? The only answer I could provide is that it's dependent upon the libraries and how the distributions are built. It's also dependent upon processors

Re: [RFC] [PATCH] powerpc: Add MSR_DE to MSR_KERNEL

Hi Joakim. On May 30, 2012, at 12:43 AM, Joakim Tjernlund wrote: I have tested this briefly with BDI2000 on P2010(e500) and it works for me. I don't know if there are any bad side effects, therfore this RFC. We used to have MSR_DE surrounded by CONFIG_something to ensure it wasn't set

Re: [PATCH 0/3] 8xx: Large page(8MB) support for 2.4

On Oct 13, 2011, at 7:00 AM, Joakim Tjernlund wrote: ehhm, do the fun stuff first? :) Need to pay the bills, first :-) Thanks for the other information. -- Dan ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org

Re: [PATCH 0/3] 8xx: Large page(8MB) support for 2.4

Hi Joakim. On Oct 12, 2011, at 2:36 PM, Joakim Tjernlund wrote: Dan, where did you go? I figured you would throw yourself at this as this is something you been meaning to do yourself for years :) Too many things to do :-) I did have the wired page version that I've been using now and

Re: [PATCH 0/3] 8xx: Large page(8MB) support for 2.4

Hi Joakim. On Oct 10, 2011, at 4:38 AM, Joakim Tjernlund wrote: This adds Large page support for 8xx and uses it for all kernel RAM - Dan, what do you think :) Since you asked, yes it looks great :-) Now, can we get this into a more contemporary kernel? I'm actually working on an

Re: [PATCH 0/3] 8xx: Large page(8MB) support for 2.4

On Oct 10, 2011, at 9:45 AM, Joakim Tjernlund wrote: That is an easy port but I will have to do that blind. Would you mind take this for a spin on 2.4 first? My current system is running 2.6, so I don't have much interested in testing 2.4 The more interesting part is if one should use other

Re: [PATCH 06/15] 8xx: Always pin kernel instruction TLB

Hi Joakim. On Jun 14, 2011, at 6:54 AM, Joakim Tjernlund wrote: Various kernel asm modifies SRR0/SRR1 just before executing a rfi. . I'm going to argue we can easily visually inspect for this since the code is static with just a couple of RFIs in these exception handlers. Some 8xx

Re: [PATCH 00/15] Backport 8xx TLB to 2.4

Hi Joakim. On Jun 14, 2011, at 6:54 AM, Joakim Tjernlund wrote: I know 2.4 is in strict maintenance mode and 8xx is obsolete but as it is still in use I wanted 8xx to age with grace. Thanks for your continued support. I have recently become involved in some 8xx development again, and have

Re: [PATCH 06/15] 8xx: Always pin kernel instruction TLB

Hi Joakim. On Jun 14, 2011, at 11:00 AM, Joakim Tjernlund wrote: I don't have a mpc850, do you? I have to say I do :-) Probably but that is another matter. You could continue with that if you like but I am stopping here ATM. Oh, come on... I've been thinking about this for years,

Re: Flushing data cache on PPC405 in Linux

On Feb 24, 2011, at 6:43 AM, John Linn wrote: It seems like this also depends on that fact that __GFP_COLD will work, otherwise some of the data could already be in the cache such that you're not guaranteed to get everything out of the cache. I wouldn't count on GFP_COLD as a guarantee the

Re: Flushing data cache on PPC405 in Linux

Hi John. On Feb 23, 2011, at 5:04 PM, John Linn wrote: Any thoughts? I can come up with two methods, but before I describe them ensure you consider the actual implementation of your 405 core. My comments are based on the standard ppc405 processor, but since you can configure the embedded

Re: minimum guaranteed alignment of dma_alloc_coherent?

On Feb 4, 2011, at 4:14 PM, Timur Tabi wrote: Is there any official statement on what the minimum alignment is for memory returned by dma_alloc_coherent? This is dependent upon the particular implementation. There have been several over the history of this API, and some would work out of a

Re: minimum guaranteed alignment of dma_alloc_coherent?

On Feb 4, 2011, at 6:04 PM, Tabi Timur-B04825 wrote: I guess I'm not clear. I was wondering why an API called dma_alloc_coherent (that has the word dma in it) needs to be told to allocate DMA-safe memory. I understood your question, and I indicated this is used in a platform specific

Re: [PATCH] fsldma: add support to 36-bit physical address

On Sep 21, 2010, at 2:49 PM, Scott Wood wrote: On Tue, 21 Sep 2010 16:43:12 -0500 Timur Tabi timur.t...@gmail.com wrote: Since we don't DMA the descriptors themselves, I just don't see how this patch does anything. Look in dmaengine.c, there are calls to dma_map_single() and

Re: Request review of device tree documentation

Hi Grant. On Jun 11, 2010, at 3:59 PM, Grant Likely wrote: I've been doing a bit of work on some introductory level documentation of the flattened device tree. Wow, I feel empowered to create device trees now :-) Seriously, I never understood this well and this is a great document. I have

Re: [PATCH 04/10] 8xx: Always pin kernel instruction TLB

On Nov 14, 2009, at 2:42 AM, Joakim Tjernlund wrote: . Avoid this by always pinning kernel instruction TLB space. You may as well map the data space, too, since you have reserved the entries. Take advantage of that performance. Also, some processor variants have very few TLB entries,

Re: [PATCH 0/8] Fix 8xx MMU/TLB

On Oct 26, 2009, at 3:47 PM, Benjamin Herrenschmidt wrote: This whole thing would be a -lot- easier to do from C code. Why ? Simply because you could just use get_user() to load the instruction rather than doing this page table walking in asm, Just be careful the get_user() doesn't

Re: [PATCH 3/6] 8xx: invalidate non present TLBs

On Oct 8, 2009, at 12:22 PM, Joakim Tjernlund wrote: hare are comments in the kernel that dcbst wrongly generates TLB Errors with store set on 8xx. Is this really so? Should dcbst always trap as a load? There are many comments written about 8xx as various behavior was discovered. Worse,

Re: [PATCH 3/6] 8xx: invalidate non present TLBs

Hi Ben. On Oct 8, 2009, at 1:28 PM, Benjamin Herrenschmidt wrote: While you are around ... I have a question :-) I'll try. Many brain cells have been replaced or lost over the years :-) Do you happen to remember what the story is with the invalidation of unpopulated (aka invalid) entries

Re: [PATCH 3/6] 8xx: invalidate non present TLBs

On Oct 8, 2009, at 1:37 PM, Joakim Tjernlund wrote: Hi, been a long time since I heard from you :) Yeah, hiding among other projects :-) Anyhow, you are welcome to have a look at the patches I have been tossing out. I've been looking, but since I'm not familiar with the current VM

Re: [PATCH] Fix remainder calculating bug in single floating point division

On Jan 6, 2008, at 12:07 PM, Benjamin Herrenschmidt wrote: It's nice to see somebody digging in that scary math emu stuff. If you could also get rid of the warnings, it would be perfect :-) Yes, it is :-) I didn't think it would have a life beyond MPC8xx. that this code was lifted

Re: [PATCH revised 3/4] powerpc: Add EXPORT_SYMBOL_GPL for symbols required by fs_enet and cpm_uart

On Nov 25, 2007, at 8:18 AM, Vitaly Bordug wrote: To prevent using those pointers from within non-GPL modules. kind of policy now... As the original copyright holder of nearly all of this of this code, I do not wish this be done. Thanks. -- Dan

Re: Hardware debuggers for PPC74xx G4 CPUs

On Nov 13, 2007, at 1:59 PM, Grant Likely wrote: Abatron BDI-2000. Oops, but that's not all that cheap. ($2750USD). If you place any value on your time or development schedule, it's a bargain. Just plug it in, and it works. Choose any of your favorite debugger front ends, from none with

Re: boards in arch/ppc - arch/powerpc for 85xx

On Oct 15, 2007, at 7:07 PM, Kumar Gala wrote: I was wondering if you cared about the following boards existing in arch/powerpc: * STX GP3 I have GP3 and GP3-SSA for testing. If you can make a first pass at the changes I'll debug and finish. Thanks. -- Dan

Re: TASK_SIZE default 0x80000000 ?

On Oct 7, 2007, at 8:02 AM, Kumar Gala wrote: It would seem like we should set the default on 8xx PReP to 0x8000 and not allow it to be modified For as much as this has been discussed in the past, I don't know why the 8xx doesn't check KERNEL_BASE and work properly with the options.

Re: [PATCH 1/9] 8xx: Fix CONFIG_PIN_TLB.

On Sep 5, 2007, at 12:27 PM, Scott Wood wrote: 1. Only map 512K of the IMMR, rather than 8M, to avoid conflicting with the default ioremap region. The original reason to map 8M was so ioremap() could use the same wired TLB rather than allocate page table entries. It should also cover all

Re: [PATCH 1/9] 8xx: Fix CONFIG_PIN_TLB.

On Sep 5, 2007, at 1:53 PM, Scott Wood wrote: Where is the code that checks for pinned TLB entries on 8xx when doing ioremap? I don't know. I haven't been the maintainer for the 2.6 changes. Why could this not be done with a 512K mapping? How was this even tested, given the obvious

Re: [PATCH 1/9] 8xx: Fix CONFIG_PIN_TLB.

On Sep 5, 2007, at 3:23 PM, Scott Wood wrote: The IMMRs I've seen from the bootloader are ff00 (Freescale boards) and fa20 (Embedded Planet). AFAICT, the number of fixed TLB entries is fixed at 4 on these chips, so using the fourth for flash wouldn't take away any