Signed-off-by: Alexey Dobriyan
---
drivers/macintosh/via-pmu.c | 160 +---
1 file changed, 91 insertions(+), 69 deletions(-)
--- a/drivers/macintosh/via-pmu.c
+++ b/drivers/macintosh/via-pmu.c
@@ -36,6 +36,7 @@
#include
#include
#include
+#include
Signed-off-by: Alexey Dobriyan
---
arch/powerpc/platforms/iseries/mf.c | 147
1 file changed, 83 insertions(+), 64 deletions(-)
--- a/arch/powerpc/platforms/iseries/mf.c
+++ b/arch/powerpc/platforms/iseries/mf.c
@@ -855,59 +855,58 @@ static int mf_get_boot_
Oops, stupid compile bug in the !CONFIG_PPC_SUBPAGE_PROT case with the
last version. Fixed below.
Fix bug in pagetable cache cleanup with CONFIG_PPC_SUBPAGE_PROT
Commit a0668cdc154e54bf0c85182e0535eea237d53146 cleans up the handling
of kmem_caches for allocating various levels of pagetables.
Unf
On Wed, 2009-11-18 at 17:05 +, Mel Gorman wrote:
>
> diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
> index 04a8061..a82c470 100644
> --- a/arch/powerpc/platforms/Kconfig
> +++ b/arch/powerpc/platforms/Kconfig
> @@ -52,9 +52,9 @@ config PPC_UDBG_BEAT
> defa
Li Yang writes:
> There was no way to set mapped memory as cacheable if the memory
> is not managed by Linux kernel. It's not rare in real system to
> allocate some dedicated memory to a certain application which is not
> managed by kernel and then mmap'ed the memory to the application.
> The mem
Li Yang writes:
> That's my concern too. But after all mmap without O_SYNC on I/O
> devices should be deprecated.
It should? Why?
Shouldn't the onus rather be on those proposing an incompatible change
to the kernel ABI, such as this is, to show why the change is
absolutely essential?
> A war
On Fri, 2009-11-27 at 01:16 +0100, Segher Boessenkool wrote:
>
> In all code I have done for the XFB, I map it like any other RAM and
> dcbst it after writing to it. Maybe that is slower though, WIMG=0100
> might be better. Dunno.
Well, it depends also what you want to do with it. If you want
If you have only one interrupt controller, like here, you don't
need to refer to it _at all_ :-)
I think Linux requires that you do though. It might be a mistake on
our
part but heh ...
Linux doesn't require it; (old) Macs are like this, for example,
and that works fine. Oh and all Maple firm
Yup. The idea is to map the first 16MB of MEM1 with a BAT.
Mapping the whole 24MB with BATs may not be possible because we
want the framebuffer
in MEM1 for performance reasons.
How big is the fb ?
A bit more than a megabyte, something like that.
We have plenty of BATs on these things... s
We need it as it currently doesn't match with the default bus ids.
Should I introduce a .type property matching any of those above
in the
soc node, and get rid of the explicit bus probe?
You don't need any fake bus as far as I can see, just probe the
devices
you want.
But it's way easi
Maybe using FLIPPER (or GAMECUBE_FLIPPER) instead of
GAMECUBE_COMMON
is a good name?
I'd prefer to not use a name that implies a specific hardware to
describe two (mostly) similar but different hardwares.
Hollywood is 100% compatible to Flipper though.
No. There's no ARAM for example :)
On Fri, 2009-11-27 at 00:00 +0100, Segher Boessenkool wrote:
> >>> +unsigned int flipper_pic_get_irq(void)
> >>> +{
> >>> + void __iomem *io_base = flipper_irq_host->host_data;
> >>> + int irq;
> >>> + u32 irq_status;
> >>> +
> >>> + irq_status = in_be32(io_base + FLIPPER_IC
From: Segher Boessenkool
Date: Thu, 26 Nov 2009 22:36:41 +0100
>>> You're right, it's not, but makes merging less complex, and then I can
>>> refactor properly.
>>
>> Still, make them __be32 at least
>
> There is no alignment guarantee at all either, better make it all u8
> and use accessor func
On Thu, 2009-11-26 at 23:54 +0100, Segher Boessenkool wrote:
> No Ben. The whole point of EARLY_DEBUG is that it _always works_,
> because
> it is such trivial code. Don't break that please, or we'll be forced to
> add a "REALLY_EARLY_DEBUG" instead :-)
I do tend to agree but heh... temptatio
There you can find the hardware interface that supports the IPC
mechanism.
It is made up of a pair of registers to pass data between the
processors and a
pair of control/flags registers.
The hardware can interrupt the PowerPC side when there is data
available for it.
Ok. So the right way t
They are a bit special because registers are in reverse little
endian format,
must be written in 32-bit chunks, and (all things point to) they
have hardware bugs.
Well.. first what is "reverse little endian" ? :-) Big endian ?
Nah. Little-endian, with a 32-bit bus swizzle. This is not the
The usbgecko is hotplugable and hotswappable.
But as this is mostly a developer feature, not normaly used by end
users, I think that we can just let it be as it is: autodetect it
on boot (now probing for it instead of using information from the
device tree).
If you unplug it later it causes
Segher Boessenkool wrote:
>> So what is at d000 ?
>
> 0c00 is the flipper-compatible stuff
> 0d00 is the hollywood new devices
> 0d80 is the same as part of 0d00, but with some extra bits
> sometimes.
>
Also, when in Wii native mode, stuff like EXI, SI and AI (which is
flipp
Sure, the memory controllers don't do coherency. I'm slightly
worried
about two things:
1) Will the generic code use M=0 as well? Is it a problem if it
doesn't?
We can make it not do it.
2) Do lwarx. etc. work in M=0?
They should hopefully... as long as you don't rely on the reservation
+static void hlwd_pic_mask_and_ack(unsigned int virq)
+{
+ int irq = virq_to_hw(virq);
+ void __iomem *io_base = get_irq_chip_data(virq);
+
+ clear_bit(irq, io_base + HW_BROADWAY_IMR);
+ set_bit(irq, io_base + HW_BROADWAY_ICR);
+}
Same comment as with flipper. BTW. It loo
+unsigned int flipper_pic_get_irq(void)
+{
+ void __iomem *io_base = flipper_irq_host->host_data;
+ int irq;
+ u32 irq_status;
+
+ irq_status = in_be32(io_base + FLIPPER_ICR) &
+in_be32(io_base + FLIPPER_IMR);
+ if (irq_status == 0)
+
This will probably break other platforms if
CONFIG_PPC_EARLY_DEBUG_USBGECKO
is set. In general, we try hard to make it possible to build generic
kernels for multiple systems, so it would be better to also add a
runtime check here.
No Arnd. The whole point of EARLY_DEBUG is that it is -known- to
BTW. If we want to play with clocks, maybe you should look at
my proposed binding for clocks and implementing the clk API :-)
There are no clocks that are configurable from the PowerPC side
(well, maybe things like the USB clocks, but we do not know how).
+ /* Team Twiizers' 'min
On Thu, 2009-11-26 at 23:15 +0100, Segher Boessenkool wrote:
> >> If you have only one interrupt controller, like here, you don't
> >> need to refer to it _at all_ :-)
> >
> > I think Linux requires that you do though. It might be a mistake on
> > our
> > part but heh ...
>
> Linux doesn't requi
+/memreserve/ 0x0180 0xe80; /* memory hole (includes I/O
area) */
+/memreserve/ 0x1000 0x0004000; /* DSP RAM */
Weird layout... nothing you can do about I suppose.
Out of curiosity, what is that DSP RAM ? Some actual DSP core
somewhere
in the IO chip setup to use memory fro
On Thu, 2009-11-26 at 22:38 +0100, Albert Herranz wrote:
> Yup. The idea is to map the first 16MB of MEM1 with a BAT.
> Mapping the whole 24MB with BATs may not be possible because we want the
> framebuffer
> in MEM1 for performance reasons.
How big is the fb ? We have plenty of BATs on these th
+ soc {
It would be better to rename this as IMMR or the bus type. This node
doesn't actually describe the entire chip, but describes the internal
memory mapped registers.
I would really just call it "flipper" :-)
Yeah, I came to the same conclusion.
Since you're only doing 1:1 mapp
So what's your proposal then? Placing it within a fake func?
Just do a .S file :-)
Yeah. You might be able to do one that handles both GC and Wii,
maybe it's easier/clearer to keep them separate though.
Ouch. I wouldn't be surprised if those guys don't do cache coherency
in the bridge anywa
+ xfb-start = <0x01698000>; /* end-of-ram - xfb-size */
+ xfb-size = <0x168000>;
XFB address isn't fixed on the hardware, and the kernel might
want to move it, and you can easily probe for it anyway. Remove
these last two properties please.
Ok but y
If you have only one interrupt controller, like here, you don't
need to refer to it _at all_ :-)
I think Linux requires that you do though. It might be a mistake on
our
part but heh ...
Linux doesn't require it; (old) Macs are like this, for example,
and that works fine. Oh and all Maple f
Segher Boessenkool wrote:
>> We need it as it currently doesn't match with the default bus ids.
>
>> Should I introduce a .type property matching any of those above in the
>> soc node, and get rid of the explicit bus probe?
>
> You don't need any fake bus as far as I can see, just probe the devic
Segher Boessenkool wrote:
>>> Maybe using FLIPPER (or GAMECUBE_FLIPPER) instead of GAMECUBE_COMMON
>>> is a good name?
>>
>> I'd prefer to not use a name that implies a specific hardware to
>> describe two (mostly) similar but different hardwares.
>
> Hollywood is 100% compatible to Flipper though
+#ifdef CONFIG_STARLET_MINI
+
+#define HW_RESETS_OF_COMPATIBLE"nintendo,hollywood-resets"
+#define HW_GPIO_ALIAS"hw_gpio
This should be unconditional now I think? You access the hardware
directly.
Yes, at this stage direct hardware should be possible, but only if
'mini' support
Am 26.11.2009 um 16:24 schrieb Alexander Graf :
Currently userspace has no chance to find out which virtual address
space we're
in and resolve addresses. While that is a big problem for migration,
it's also
unpleasent when debugging, as gdb and the monitor don't work on
virtual
addresses.
Add support for the BootMii 'mini' firmware replacement for the
Starlet processor.
'mini' is an open source IOS replacement written from scratch by
Team Twiizers.
It's not a replacement, it doesn't have any of the same
functionality.
I didn't know 'replacement' had that semantics.
It's am
We need it as it currently doesn't match with the default bus ids.
Should I introduce a .type property matching any of those above in
the soc node, and get rid of the explicit bus probe?
You don't need any fake bus as far as I can see, just probe the devices
you want.
Segher
_
Maybe using FLIPPER (or GAMECUBE_FLIPPER) instead of GAMECUBE_COMMON
is a good name?
I'd prefer to not use a name that implies a specific hardware to
describe two (mostly) similar but different hardwares.
Hollywood is 100% compatible to Flipper though.
+/*
+ * Each interrupt has a correspo
On Thu, 2009-11-26 at 22:36 +0100, Segher Boessenkool wrote:
> >> You're right, it's not, but makes merging less complex, and then I
> >> can
> >> refactor properly.
> >
> > Still, make them __be32 at least
>
> There is no alignment guarantee at all either, better make it all u8
> and use access
Benjamin Herrenschmidt wrote:
>>> Good point. I can't even guarantee that the kernel will work reliably
>>> with nobats :-) At least you really want the kernel .text to be fully
>>> covered by an IBAT.
>>>
>> It works with nobats.
>
> But does it work -reliably- ? :-)
>
It does AFAICT. My Wii is
You're right, it's not, but makes merging less complex, and then I
can
refactor properly.
Still, make them __be32 at least
There is no alignment guarantee at all either, better make it all u8
and use accessor functions everywhere.
Segher
___
Lin
Benjamin Herrenschmidt wrote:
> On Thu, 2009-11-26 at 16:09 +0100, Albert Herranz wrote:
>
>>> Are the above OHCI and EHCI "special" ? If not, there's an existing
>>> binding for that sort of thing, which btw requires properties to
>>> indicate the endianness of the registers and in-memory data st
So what you are saying is that if the kernel has mapped a physical
page as cacheable while user application is trying to map it as
non-cacheable, there will be machine checks and checkstops rather than
just performance drop? This is new to me. Could you elaborate a bit?
If some data is in cach
On Thu, 2009-11-26 at 16:42 +0100, Albert Herranz wrote:
> Benjamin Herrenschmidt wrote:
> > On Sun, 2009-11-22 at 23:01 +0100, Albert Herranz wrote:
> >
> >> +static void hlwd_pic_mask_and_ack(unsigned int virq)
> >> +{
> >> + int irq = virq_to_hw(virq);
> >> + void __iomem *io_base = get_irq_c
On Thu, 2009-11-26 at 16:35 +0100, Albert Herranz wrote:
> Benjamin Herrenschmidt wrote:
> > On Tue, 2009-11-24 at 18:09 +0100, Albert Herranz wrote:
> >> I could use ppc_md.ioremap to duplicate ioremap except for the ioremap
> >> ram check.
> >> But calling the stock ioremap without modifying it i
On Thu, 2009-11-26 at 16:33 +0100, Albert Herranz wrote:
> Benjamin Herrenschmidt wrote:
> > On Sun, 2009-11-22 at 16:28 -0700, Grant Likely wrote:
> >>> +unsigned int flipper_pic_get_irq(void)
> >>> +{
> >>> + void __iomem *io_base = flipper_irq_host->host_data;
> >>> + int irq;
> >>>
On Thu, 2009-11-26 at 16:30 +0100, Albert Herranz wrote:
> Benjamin Herrenschmidt wrote:
> > On Sun, 2009-11-22 at 23:01 +0100, Albert Herranz wrote:
> >
> >> +static void flipper_pic_mask_and_ack(unsigned int virq)
> >> +{
> >> + int irq = virq_to_hw(virq);
> >> + void __iomem *io_base = get_ir
On Thu, 2009-11-26 at 16:28 +0100, Albert Herranz wrote:
> Benjamin Herrenschmidt wrote:
> > On Sun, 2009-11-22 at 23:01 +0100, Albert Herranz wrote:
> >> Add support for using the USB Gecko adapter via the udbg facility on
> >> the Nintendo GameCube and Wii video game consoles.
> >> The USB Gecko
> > Good point. I can't even guarantee that the kernel will work reliably
> > with nobats :-) At least you really want the kernel .text to be fully
> > covered by an IBAT.
> >
>
> It works with nobats.
But does it work -reliably- ? :-)
I haven't looked at that for years, but we used to have a
On Thu, 2009-11-26 at 16:09 +0100, Albert Herranz wrote:
> > Are the above OHCI and EHCI "special" ? If not, there's an existing
> > binding for that sort of thing, which btw requires properties to
> > indicate the endianness of the registers and in-memory data structures
> > etc...
> >
>
> They
From: Gautham R Shenoy
Currently the cpu-allocation/deallocation process comprises of two steps:
- Set the indicators and to update the device tree with DLPAR node
information.
- Online/offline the allocated/deallocated CPU.
This is achieved by writing to the sysfs tunables "probe" during all
From: Gautham R Shenoy
Currently the cpu-allocation/deallocation on pSeries is a
two step process from the Userspace.
- Set the indicators and update the device tree by writing to the sysfs
tunable "probe" during allocation and "release" during deallocation.
- Online / Offline the CPUs of the
Hi,
This is version 6 of patch series that provides a framework to choose the state
a pseries CPU must be put to when it is offlined.
Previous versions can be found here:
Version 5: http://lkml.org/lkml/2009/10/30/6
Version 4: http://lkml.org/lkml/2009/10/9/59
Version 3: http://lkml.org/lkml/2009
M. Mohan Kumar schrieb:
> On 11/26/2009 12:22 AM, Bernhard Walle wrote:
>> M. Mohan Kumar schrieb:
>>> Reserve memory for kdump kernel within RMO region
>>>
>>> When the kernel size exceeds 32MB(observed with some distros), memory
>>> for kdump kernel can not be reserved as kdump kernel base is ass
On Thu, Nov 26, 2009 at 12:01 PM, Anton Vorontsov
wrote:
> On Thu, Nov 26, 2009 at 11:50:05AM -0700, Grant Likely wrote:
>> On Thu, Nov 26, 2009 at 11:41 AM, Anton Vorontsov
>> wrote:
>> > On Thu, Nov 26, 2009 at 11:16:34AM -0700, Grant Likely wrote:
>> > [...]
>> >> The spi-cs-high property is d
On Thu, Nov 26, 2009 at 11:50:05AM -0700, Grant Likely wrote:
> On Thu, Nov 26, 2009 at 11:41 AM, Anton Vorontsov
> wrote:
> > On Thu, Nov 26, 2009 at 11:16:34AM -0700, Grant Likely wrote:
> > [...]
> >> The spi-cs-high property is defined in
> >> Documentation/powerpc/dts-bindings/spi-bus.txt, bu
On Thu, Nov 26, 2009 at 11:41 AM, Anton Vorontsov
wrote:
> On Thu, Nov 26, 2009 at 11:16:34AM -0700, Grant Likely wrote:
> [...]
>> The spi-cs-high property is defined in
>> Documentation/powerpc/dts-bindings/spi-bus.txt, but it definitely was
>> a mistake
>
> Yup.
>
>> Currently the spi-cs-high p
On Thu, Nov 26, 2009 at 11:16:34AM -0700, Grant Likely wrote:
[...]
> The spi-cs-high property is defined in
> Documentation/powerpc/dts-bindings/spi-bus.txt, but it definitely was
> a mistake
Yup.
> Currently the spi-cs-high property is parsed in the
> of_register_spi_devices() function, but the
On Thu, Nov 26, 2009 at 10:27 AM, Torsten Fleischer
wrote:
> On Thu, Nov 26, 2009 at 13:12:04 Anton Vorontsov wrote:
> [...]
>> > Ah. I understand what you're doing now. Hmmm. This approach
>> > concerns me because it relies on firmware or platform code to get CS
>> > gpios set up properly bef
On Thu, Nov 26, 2009 at 5:12 AM, Anton Vorontsov
wrote:
> On Wed, Nov 25, 2009 at 03:11:57PM -0700, Grant Likely wrote:
>> On Wed, Nov 25, 2009 at 1:41 PM, Torsten Fleischer
>> wrote:
>> > On Wen, Nov 25, 2009 at 01:33:57 Grant Likely wrote:
>> >> Thanks. However, there needs to be a proper desc
On Thu, Nov 26, 2009 at 13:12:04 Anton Vorontsov wrote:
[...]
> > Ah. I understand what you're doing now. Hmmm. This approach
> > concerns me because it relies on firmware or platform code to get CS
> > gpios set up properly before the driver is probed.
>
> Yes, that was said at the very begin
Benjamin Herrenschmidt wrote:
> On Sun, 2009-11-22 at 23:01 +0100, Albert Herranz wrote:
>
>> +static void hlwd_pic_mask_and_ack(unsigned int virq)
>> +{
>> +int irq = virq_to_hw(virq);
>> +void __iomem *io_base = get_irq_chip_data(virq);
>> +
>> +clear_bit(irq, io_base + HW_BROADWAY_I
Benjamin Herrenschmidt wrote:
> On Tue, 2009-11-24 at 18:09 +0100, Albert Herranz wrote:
>> I could use ppc_md.ioremap to duplicate ioremap except for the ioremap
>> ram check.
>> But calling the stock ioremap without modifying it is not possible
>> because it checks and bails out when ioremapping
Benjamin Herrenschmidt wrote:
> On Sun, 2009-11-22 at 16:28 -0700, Grant Likely wrote:
>>> +unsigned int flipper_pic_get_irq(void)
>>> +{
>>> + void __iomem *io_base = flipper_irq_host->host_data;
>>> + int irq;
>>> + u32 irq_status;
>>> +
>>> + irq_status = in_be32(io_base
Benjamin Herrenschmidt wrote:
> On Sun, 2009-11-22 at 23:01 +0100, Albert Herranz wrote:
>
>> +static void flipper_pic_mask_and_ack(unsigned int virq)
>> +{
>> +int irq = virq_to_hw(virq);
>> +void __iomem *io_base = get_irq_chip_data(virq);
>> +
>> +clear_bit(irq, io_base + FLIPPER_IM
Benjamin Herrenschmidt wrote:
> On Sun, 2009-11-22 at 23:01 +0100, Albert Herranz wrote:
>> Add support for using the USB Gecko adapter via the udbg facility on
>> the Nintendo GameCube and Wii video game consoles.
>> The USB Gecko is a 3rd party memory card interface adapter that provides
>> a EXI
Currently userspace has no chance to find out which virtual address space we're
in and resolve addresses. While that is a big problem for migration, it's also
unpleasent when debugging, as gdb and the monitor don't work on virtual
addresses.
This patch exports enough of the MMU segment state to us
Benjamin Herrenschmidt wrote:
> On Tue, 2009-11-24 at 19:03 +0100, Albert Herranz wrote:
>> Segher Boessenkool wrote:
Add a config option GAMECUBE_COMMON to be used as a dependency for all
options common to the Nintendo GameCube and Wii video game consoles.
>>> Maybe something like GAMECU
Benjamin Herrenschmidt wrote:
> On Wed, 2009-11-25 at 19:34 +0100, Albert Herranz wrote:
>> We need nobats (or a hack in the mmu_mapin_ram() code) because of the
>> discontiguous ram problem.
>
> I would vote for a hack in mmu_mapin_ram() for now.
>
I'll cook that.
> Cheers,
> Ben.
>
Thanks,
Benjamin Herrenschmidt wrote:
> On Wed, 2009-11-25 at 18:49 +0100, Segher Boessenkool wrote:
>>> +/memreserve/ 0x0180 0xe80; /* memory hole (includes I/O area) */
>> Like others have said already, don't do this. If you need
>> a workaround, put it in the platform code.
>>
>>> +/memreserve/
Forgot the patch.
Kári Davíðsson wrote:
Hi,
I am messing about with the fsl-diu-fb.c which handles the display on mpc512x
platforms.
The display panels we are using provide EDID information and I would like to
use that to setup
the display modes etc. The current fsl-diu-fb.c is hard coding d
Benjamin Herrenschmidt wrote:
> On Sun, 2009-11-22 at 23:01 +0100, Albert Herranz wrote:
>
>> +/memreserve/ 0x0180 0xe80; /* memory hole (includes I/O area) */
>> +/memreserve/ 0x1000 0x0004000; /* DSP RAM */
>
> Weird layout... nothing you can do about I suppose.
>
> Out of curios
Hi,
I am messing about with the fsl-diu-fb.c which handles the display on mpc512x
platforms.
The display panels we are using provide EDID information and I would like to
use that to setup
the display modes etc. The current fsl-diu-fb.c is hard coding display modes
into the driver.
I have star
On 11/26/2009 03:16 PM, Alexander Graf wrote:
You can keep pvr out of the (named) union.
So we'd have
sregs.padded.ppc64.slb?
or sregs.u.ppc64.slb.
I don't see how that is an improvement.
Buildability takes precedence.
(an alternative is to drop the union, and add a BUI
Avi Kivity wrote:
> On 11/26/2009 02:46 PM, Alexander Graf wrote:
>>
>>> Please avoid unnamed unions in user-visible headers - they're a gcc
>>> extension.
>>>
>>> Yes, we have them elsewhere, but let's not add to the pile.
>>>
>> I'm open to scalable suggestions that don't break existing use
On 11/26/2009 02:46 PM, Alexander Graf wrote:
Please avoid unnamed unions in user-visible headers - they're a gcc
extension.
Yes, we have them elsewhere, but let's not add to the pile.
I'm open to scalable suggestions that don't break existing userspace code.
If I name the union now, ex
Avi Kivity wrote:
> On 11/26/2009 01:16 PM, Alexander Graf wrote:
>> Currently userspace has no chance to find out which virtual address
>> space we're
>> in and resolve addresses. While that is a big problem for migration,
>> it's also
>> unpleasent when debugging, as gdb and the monitor don't wor
On 11/26/2009 01:16 PM, Alexander Graf wrote:
Currently userspace has no chance to find out which virtual address space we're
in and resolve addresses. While that is a big problem for migration, it's also
unpleasent when debugging, as gdb and the monitor don't work on virtual
addresses.
This pat
On Tue, Nov 24, 2009 at 01:17:41AM -0700, Grant Likely wrote:
> Nothing much to say here other than mostly mechanical merging of OF
> support code. Some of it remains a little ugly, but I'm taking the
> approach of merging the code first, and refactoring it second.
>
> I've pushed this series out
On Wed, Nov 25, 2009 at 03:11:57PM -0700, Grant Likely wrote:
> On Wed, Nov 25, 2009 at 1:41 PM, Torsten Fleischer
> wrote:
> > On Wen, Nov 25, 2009 at 01:33:57 Grant Likely wrote:
> >> Thanks. However, there needs to be a proper description of what this
> >> patch does to go in the commit header
Currently userspace has no chance to find out which virtual address space we're
in and resolve addresses. While that is a big problem for migration, it's also
unpleasent when debugging, as gdb and the monitor don't work on virtual
addresses.
This patch exports enough of the MMU segment state to us
On 11/26/2009 12:22 AM, Bernhard Walle wrote:
M. Mohan Kumar schrieb:
Reserve memory for kdump kernel within RMO region
When the kernel size exceeds 32MB(observed with some distros), memory
for kdump kernel can not be reserved as kdump kernel base is assumed to
be 32MB always. When the kernel h
Benjamin Herrenschmidt wrote on 26/11/2009 09:46:58:
>
> On Thu, 2009-11-26 at 09:30 +0100, Joakim Tjernlund wrote:
> > > I'm not sure its going to work to use get_unaligned() like that on all
> > > archs .. it might be definitely something to discuss on some more
> > > appropriate mailing list.
>
On Thu, 2009-11-26 at 09:30 +0100, Joakim Tjernlund wrote:
> > I'm not sure its going to work to use get_unaligned() like that on all
> > archs .. it might be definitely something to discuss on some more
> > appropriate mailing list.
>
> Oh, why not? Is that because I am using it wrongly or becaus
On Thu, 2009-11-26 at 09:17 +0100, Gabriel Paubert wrote:
>
> > They should hopefully... as long as you don't rely on the reservation
> > blowing as a result of a DMA write.
>
> Hmm, this really depends on whether the DMA transfers generate bus cycles
> that require coherency or not. Not the othe
eHEA driver fails to initialize on a power6 box while booting
20091125 next(f3645ca..). Following are the messages which gets
logged during failure.
Unable to handle kernel paging request for data at address 0x409d0148e8e40018
Faulting instruction address: 0xc003c0cc
Oops: Kernel access
Benjamin Herrenschmidt wrote on 24/11/2009 04:12:43:
>
> On Tue, 2009-11-10 at 10:00 +0100, Joakim Tjernlund wrote:
> > JFFS2 uses lesser compression ratio and inflate always
> > ends up in "copy direct from output" case.
> > This patch tries to optimize the direct copy procedure.
> > Uses get_una
On Thu, Nov 26, 2009 at 03:36:56PM +1100, Benjamin Herrenschmidt wrote:
> On Tue, 2009-11-24 at 22:00 +0100, Segher Boessenkool wrote:
> >
> > Sure, the memory controllers don't do coherency. I'm slightly worried
> > about two things:
> > 1) Will the generic code use M=0 as well? Is it a problem
There was no way to set mapped memory as cacheable if the memory
is not managed by Linux kernel. It's not rare in real system to
allocate some dedicated memory to a certain application which is not
managed by kernel and then mmap'ed the memory to the application.
The memory should be cacheable but
Right, that's the only sane way to do it, I just didn't remember off
hand what was said in the OF spec :-)
3.2.2.1.2 Property values
The property-encoding format is independent of hardware byte order and
alignment characteristics. The encoded byte order is well-defined (in
particular, it
89 matches
Mail list logo
