* Re: [patch 3/3] [v2] powerpc: make the CMM memory hotplug aware
From: Andrew Morton @ 2009-11-20 0:14 UTC (permalink / raw)
To: Robert Jennings
Cc: mel, geralds, linuxppc-dev, paulus, brking, mingo, schwidefsky,
kamezawa.hiroyu
In-Reply-To: <20091118185907.GA30950@austin.ibm.com>
On Wed, 18 Nov 2009 12:59:08 -0600
Robert Jennings <rcj@linux.vnet.ibm.com> wrote:
> The Collaborative Memory Manager (CMM) module allocates individual pages
> over time that are not migratable. On a long running system this can
> severely impact the ability to find enough pages to support a hotplug
> memory remove operation.
>
> This patch adds a memory isolation notifier and a memory hotplug notifier.
> The memory isolation notifier will return the number of pages found
> in the range specified. This is used to determine if all of the used
> pages in a pageblock are owned by the balloon (or other entities in
> the notifier chain). The hotplug notifier will free pages in the range
> which is to be removed. The priority of this hotplug notifier is low
> so that it will be called near last, this helps avoids removing loaned
> pages in operations that fail due to other handlers.
>
> CMM activity will be halted when hotplug remove operations are active
> and resume activity after a delay period to allow the hypervisor time
> to adjust.
>
> Signed-off-by: Robert Jennings <rcj@linux.vnet.ibm.com>
> Cc: Mel Gorman <mel@csn.ul.ie>
> Cc: Ingo Molnar <mingo@elte.hu>
> Cc: Brian King <brking@linux.vnet.ibm.com>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
> Cc: Gerald Schaefer <geralds@linux.vnet.ibm.com>
> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Andrew Morton <akpm@linux-foundation.org>
>
> ---
> The pages used to track loaned pages should not be marked as MOVABLE, so
> they need to be handled during a memory offline event.
>
> Changes:
> * The structures for recording loaned pages are not allocated as MOVABLE
> * The structures for recording loaned pages are removed from sections
> being taken offline by moving their contents to a newly allocated page.
>
> arch/powerpc/platforms/pseries/cmm.c | 254 ++++++++++++++++++++++++++++++++++-
> 1 file changed, 248 insertions(+), 6 deletions(-)
Incremental patch is:
: --- a/arch/powerpc/platforms/pseries/cmm.c~powerpc-make-the-cmm-memory-hotplug-aware-update
: +++ a/arch/powerpc/platforms/pseries/cmm.c
: @@ -148,8 +148,7 @@ static long cmm_alloc_pages(long nr)
: spin_unlock(&cmm_lock);
: npa = (struct cmm_page_array *)__get_free_page(
: GFP_NOIO | __GFP_NOWARN |
: - __GFP_NORETRY | __GFP_NOMEMALLOC |
: - __GFP_MOVABLE);
: + __GFP_NORETRY | __GFP_NOMEMALLOC);
: if (!npa) {
: pr_info("%s: Can not allocate new page list\n", __func__);
: free_page(addr);
: @@ -480,6 +479,8 @@ static unsigned long cmm_count_pages(voi
: spin_lock(&cmm_lock);
: pa = cmm_page_list;
: while (pa) {
: + if ((unsigned long)pa >= start && (unsigned long)pa < end)
: + marg->pages_found++;
: for (idx = 0; idx < pa->index; idx++)
: if (pa->page[idx] >= start && pa->page[idx] < end)
: marg->pages_found++;
: @@ -531,7 +532,7 @@ static int cmm_mem_going_offline(void *a
: struct memory_notify *marg = arg;
: unsigned long start_page = (unsigned long)pfn_to_kaddr(marg->start_pfn);
: unsigned long end_page = start_page + (marg->nr_pages << PAGE_SHIFT);
: - struct cmm_page_array *pa_curr, *pa_last;
: + struct cmm_page_array *pa_curr, *pa_last, *npa;
: unsigned long idx;
: unsigned long freed = 0;
:
: @@ -539,6 +540,7 @@ static int cmm_mem_going_offline(void *a
: start_page, marg->nr_pages);
: spin_lock(&cmm_lock);
:
: + /* Search the page list for pages in the range to be offlined */
: pa_last = pa_curr = cmm_page_list;
: while (pa_curr) {
: for (idx = (pa_curr->index - 1); (idx + 1) > 0; idx--) {
: @@ -563,6 +565,37 @@ static int cmm_mem_going_offline(void *a
: }
: pa_curr = pa_curr->next;
: }
: +
: + /* Search for page list structures in the range to be offlined */
: + pa_last = NULL;
: + pa_curr = cmm_page_list;
: + while (pa_curr) {
: + if (((unsigned long)pa_curr >= start_page) &&
: + ((unsigned long)pa_curr < end_page)) {
: + npa = (struct cmm_page_array *)__get_free_page(
: + GFP_NOIO | __GFP_NOWARN |
: + __GFP_NORETRY | __GFP_NOMEMALLOC);
: + if (!npa) {
: + spin_unlock(&cmm_lock);
: + cmm_dbg("Failed to allocate memory for list "
: + "management. Memory hotplug "
: + "failed.\n");
: + return ENOMEM;
: + }
: + memcpy(npa, pa_curr, PAGE_SIZE);
: + if (pa_curr == cmm_page_list)
: + cmm_page_list = npa;
: + if (pa_last)
: + pa_last->next = npa;
: + free_page((unsigned long) pa_curr);
: + freed++;
: + pa_curr = npa;
: + }
: +
: + pa_last = pa_curr;
: + pa_curr = pa_curr->next;
: + }
: +
: spin_unlock(&cmm_lock);
: cmm_dbg("Released %ld pages in the search range.\n", freed);
:
I'm wondering what is the maximum hold time of cmm_lock. Rounded to
the nearest fortnight :)
^ permalink raw reply
* Re: [PATCH][v3] Add asynchronous notification support
From: Jeff Garzik @ 2009-11-19 23:35 UTC (permalink / raw)
To: ashish kalra; +Cc: linux-ide, linuxppc-dev
In-Reply-To: <Pine.WNT.4.64.0907012055100.868@B00888-02.fsl.freescale.net>
On 07/01/2009 11:29 AM, ashish kalra wrote:
> Enable device hot-plug support on Port multiplier fan-out ports
> v3 fixes whitespace/identation issues
>
> Signed-off-by: Ashish Kalra <Ashish.Kalra@freescale.com>
> ---
> drivers/ata/sata_fsl.c | 15 ++++++++++-----
> 1 files changed, 10 insertions(+), 5 deletions(-)
applied #upstream
^ permalink raw reply
* Re: [PATCH] sata_fsl: Split hard and soft reset
From: Jeff Garzik @ 2009-11-19 23:18 UTC (permalink / raw)
To: Anton Vorontsov
Cc: linux-ide, Jiang Yutang, Ashish Kalra, linuxppc-dev, Jeff Garzik
In-Reply-To: <20091016164436.GA12897@oksana.dev.rtsoft.ru>
On 10/16/2009 12:44 PM, Anton Vorontsov wrote:
> From: Jiang Yutang<b14898@freescale.com>
>
> Split sata_fsl_softreset() into hard and soft resets to make
> error-handling more efficient& device and PMP detection more
> reliable.
>
> Also includes fix for PMP support, driver tested with Sil3726,
> Sil4726& Exar PMP controllers.
>
> [AV: Also fixes resuming from deep sleep on MPC8315 CPUs]
>
> Signed-off-by: Jiang Yutang<b14898@freescale.com>
> Signed-off-by: Anton Vorontsov<avorontsov@ru.mvista.com>
> ---
> drivers/ata/sata_fsl.c | 84 +++++++++++++++++++++++++-----------------------
> 1 files changed, 44 insertions(+), 40 deletions(-)
applied #upstream-fixes
^ permalink raw reply
* Re: tg3: link is permanently down after ifdown and ifup
From: Michael Chan @ 2009-11-19 22:50 UTC (permalink / raw)
To: Felix Radensky, mcarlson; +Cc: netdev@vger.kernel.org, linuxppc-dev@ozlabs.org
In-Reply-To: <4B056D85.5010904@embedded-sol.com>
On Thu, 2009-11-19 at 08:08 -0800, Felix Radensky wrote:
> Hi,
>
> The problem goes away if I remove the call to
>
> tg3_set_power_state(tp, PCI_D3hot);
>
> from tg3_close().
Added Matt to CC. He is on vacation and may not be able to look into
this right away. Thanks.
^ permalink raw reply
* Re: [patch] powerpc: Fixup last users of irq_chip->typename - V2
From: Geoff Levand @ 2009-11-19 21:48 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: Scott Wood, linuxppc-dev@ozlabs.org, Ingo Molnar, LKML
In-Reply-To: <alpine.LFD.2.00.0911191035030.24119@localhost.localdomain>
On 11/19/2009 01:44 AM, Thomas Gleixner wrote:
> The typename member of struct irq_chip was kept for migration purposes
> and is obsolete since more than 2 years. Fix up the leftovers.
> Index: linux-2.6-tip/arch/powerpc/platforms/ps3/interrupt.c
> ===================================================================
> --- linux-2.6-tip.orig/arch/powerpc/platforms/ps3/interrupt.c
> +++ linux-2.6-tip/arch/powerpc/platforms/ps3/interrupt.c
> @@ -152,7 +152,7 @@ static void ps3_chip_eoi(unsigned int vi
> */
>
> static struct irq_chip ps3_irq_chip = {
> - .typename = "ps3",
> + .name = "ps3",
> .mask = ps3_chip_mask,
> .unmask = ps3_chip_unmask,
> .eoi = ps3_chip_eoi,
This PS3 part looks OK.
Acked-by: Geoff Levand <geoffrey.levand@am.sony.com>
^ permalink raw reply
* [PATCH] ppc64: re-enable kexec to allow module loads with CONFIG_MODVERSIONS and CONFIG_RELOCATABLE turned on
From: Neil Horman @ 2009-11-19 19:52 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus, nhorman
Hey there-
Before anyone flames me for what a oddball solution this is, let me just
say I'm trying to get the ball rolling here. I think there may be better
solutions that can be impemented in reloc_64.S, but I've yet to make any of the
ones I've tried work successfully. I'm open to suggestions, but this solution
is the only one so far that I've been able to get to work. thanks :)
Adjust crcs in __kcrctab_* sections if relocs are used with CONFIG_RELOCATABLE
When CONFIG_MODVERSIONS and CONFIG_RELOCATABLE are enabled on powerpc platforms,
kdump has been failing in a rather odd way. specifically modules will not
install. This is because when validating the crcs of symbols that the module
needs, the crc of the module never matches the crc that is stored in the kernel.
The underlying cause of this is how CONFIG_MODVERSIONS is implemented, and how
CONFIG_RELOCATABLE are implemented. with CONFIG_MODVERSIONS enabled, for every
exported symbol in the kernel we emit 2 symbols, __crc_#sym which is declared
extern and __kcrctab_##sym, which is placed in the __kcrctab section of the
binary. The latter has its value set equal to the address of the former
(recalling it is declared extern). After the object file is built, genksyms is
run on the processed source, and crcs are computed for each exported symbol.
genksyms then emits a linker script which defines each of the needed __crc_##sym
symbols, and sets their addresses euqal to their respective crcs. This script
is then used in a secondary link to the previously build object file, so that
the crcs of the missing symbol can be validated on module insert.
The problem here is that because __kcrctab_sym is set equal to &__crc_##sym, a
relocation entry is emitted by the compiler for the __kcrctab__##sym. Normally
this is not a problem, since relocation on other arches is done without the aid
of .rel.dyn sections. PPC however uses these relocations when
CONFIG_RELOCATABLE is enabled. nominally, since addressing starts at 0 for ppc,
its irrelevant, but if we start at a non-zero address (like we do when booting
via kexec from reserved crashkernel memory), the ppc boot code iterates over the
relocation entries, and winds up adding that relocation offset to all symbols,
including the symbols that are actually the aforementioned crc values in the
__kcrctab_* sections. This effectively corrupts the crcs and prevents any
module loads from happening during a kdump.
My solution is to 'undo' these relocations prior to boot up. If
ARCH_USES_RELOC_ENTRIES is defined, we add a symbol at address zero to the
linker script for that arch (I call it reloc_start, so that &reloc_start = 0).
This symbol will then indicate the relocation offset for any given boot. We
also add an initcall to the module code that, during boot, scans the __kcrctab_*
sections and subtracts &reloc_start from every entry in those sections,
restoring the appropriate crc value.
I've verified that this allows kexec to work properly on ppc64 systems myself.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
arch/powerpc/include/asm/local.h | 6 ++++++
arch/powerpc/kernel/vmlinux.lds.S | 4 ++++
kernel/module.c | 30 ++++++++++++++++++++++++++++++
3 files changed, 40 insertions(+)
diff --git a/arch/powerpc/include/asm/local.h b/arch/powerpc/include/asm/local.h
index 84b457a..9cc49e5 100644
--- a/arch/powerpc/include/asm/local.h
+++ b/arch/powerpc/include/asm/local.h
@@ -4,6 +4,12 @@
#include <linux/percpu.h>
#include <asm/atomic.h>
+#ifdef CONFIG_MODVERSIONS
+#define ARCH_USES_RELOC_ENTRIES
+
+extern unsigned long reloc_start;
+#endif
+
typedef struct
{
atomic_long_t a;
diff --git a/arch/powerpc/kernel/vmlinux.lds.S b/arch/powerpc/kernel/vmlinux.lds.S
index 27735a7..2b9fb2e 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -38,6 +38,10 @@ jiffies = jiffies_64 + 4;
#endif
SECTIONS
{
+ . = 0;
+ reloc_start = .;
+ . = 0;
+
. = KERNELBASE;
/*
diff --git a/kernel/module.c b/kernel/module.c
index 8b7d880..87a4928 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -181,8 +181,11 @@ extern const struct kernel_symbol __stop___ksymtab_gpl_future[];
extern const struct kernel_symbol __start___ksymtab_gpl_future[];
extern const struct kernel_symbol __stop___ksymtab_gpl_future[];
extern const unsigned long __start___kcrctab[];
+extern const unsigned long __stop___kcrctab[];
extern const unsigned long __start___kcrctab_gpl[];
+extern const unsigned long __stop___kcrctab_gpl[];
extern const unsigned long __start___kcrctab_gpl_future[];
+extern const unsigned long __stop___kcrctab_gpl_future[];
#ifdef CONFIG_UNUSED_SYMBOLS
extern const struct kernel_symbol __start___ksymtab_unused[];
extern const struct kernel_symbol __stop___ksymtab_unused[];
@@ -3144,3 +3147,30 @@ int module_get_iter_tracepoints(struct tracepoint_iter *iter)
return found;
}
#endif
+
+#ifdef ARCH_USES_RELOC_ENTRIES
+static __init int adjust_kcrctab(void)
+{
+ int i;
+ int count;
+ unsigned long *crc ;
+
+ count = __stop___kcrctab - __start___kcrctab;
+ crc = (unsigned long *)__start___kcrctab;
+ for (i = 0; i < count; i++) {
+ crc[i] -= (unsigned long)&reloc_start;
+ }
+ count = __stop___kcrctab_gpl - __start___kcrctab_gpl;
+ crc = (unsigned long *)__start___kcrctab_gpl;
+ for (i = 0; i < count; i++) {
+ crc[i] -= (unsigned long)&reloc_start;
+ }
+ count = __stop___kcrctab_gpl_future - __start___kcrctab_gpl_future;
+ crc = (unsigned long *)__start___kcrctab_gpl_future;
+ for (i = 0; i< count; i++) {
+ crc[i] -= (unsigned long)&reloc_start;
+ }
+ return 0;
+}
+early_initcall(adjust_kcrctab);
+#endif
^ permalink raw reply related
* Re: [PATCH v3 3/3] powerpc/fsl: 85xx: add cache-sram support
From: Kumar Gala @ 2009-11-19 18:51 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Vivek Mahajan
In-Reply-To: <20091119174546.GB6845@b07421-ec1.am.freescale.net>
On Nov 19, 2009, at 11:45 AM, Scott Wood wrote:
> On Thu, Nov 19, 2009 at 08:29:19AM -0600, Kumar Gala wrote:
>>>> +config FSL_85XX_CACHE_SRAM_BASE
>>>> + hex
>>>> + depends on FSL_85XX_CACHE_SRAM
>>>> + default "0xfff00000"
>>>> +
>>>
>>> I really don't like setting the physical address this way, can we
>>> not do this via the device tree?
>>
>> At a high level I think we should add something like the following in
>> the .dts:
>>
>> sram@fff00000 {
>> fsl,sram-ctrl-handle = <&L2>;
>> reg = <0xfff00000 0xNNNN>;
>> compatible = "fsl,mpc85xx-l2-sram";
>> }
>>
>> the NNNN can be the size the sram is configured as.
>
> I don't see why this needs to go in the device tree, if it's the
> kernel
> that is setting it up. The kernel can pick any address and size it
> wants.
It can, we just don't normally do physical address allocation in the
kernel. I just dont want it as a compile time thing. Either .dts or
make it runtime allocated by the kernel.
- k
^ permalink raw reply
* RE: Bug in drivers/serial/of_serial.c?
From: John Linn @ 2009-11-19 17:36 UTC (permalink / raw)
To: Stephen Neuendorffer, Alon Ziv, Arnd Bergmann, linuxppc-dev
In-Reply-To: <977C41F842E66D4CB2E41332313B615008FC3C2F@XSJ-EXCHVS1.xlnx.xilinx.com>
NAK also.
Yes we can generate a different device tree to fix this issue.
Thanks,
John
> -----Original Message-----
> From: Stephen Neuendorffer
> Sent: Thursday, November 19, 2009 10:23 AM
> To: Alon Ziv; Arnd Bergmann; linuxppc-dev@lists.ozlabs.org
> Cc: John Linn; grant.likely@secretlab.ca
> Subject: RE: Bug in drivers/serial/of_serial.c?
> =
> =
> NAK.
> =
> If the problem is in the device trees that are being generated, we
should fix the issue there.
> We've been trying to avoid putting the fully specified IP versions in
the kernel like this, since
> the IP changes so often.
> =
> Steve
> =
> > -----Original Message-----
> > From:
linuxppc-dev-bounces+stephen=3Dneuendorffer.name@lists.ozlabs.org
[mailto:linuxppc-dev-
> > bounces+stephen=3Dneuendorffer.name@lists.ozlabs.org] On Behalf Of
Alon Ziv
> > Sent: Thursday, November 19, 2009 5:49 AM
> > To: Arnd Bergmann; linuxppc-dev@lists.ozlabs.org
> > Subject: RE: Bug in drivers/serial/of_serial.c?
> >
> > On Thursday, November 19, 2009, Arnd Bergmann wrote:
> > > I'd still add support for the compatible=3D"ns16550a" property
> > > so that we do the right thing for future systems.
> > >
> >
> > OK...
> > ---
> > Xilinx 16550 UART is actually 16550A-compatible
> >
> > Signed-off-by: Alon Ziv <alonz@discretix.com>
> >
> > diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
> > index 02406ba..241be77 100644
> > --- a/drivers/serial/of_serial.c
> > +++ b/drivers/serial/of_serial.c
> > @@ -161,7 +161,9 @@ static int of_platform_serial_remove(struct
> > of_device *ofdev)
> > static struct of_device_id __devinitdata of_platform_serial_table[]
=3D {
> > { .type =3D "serial", .compatible =3D "ns8250", .data =3D (void
> > *)PORT_8250, },
> > { .type =3D "serial", .compatible =3D "ns16450", .data =3D (void
> > *)PORT_16450, },
> > + { .type =3D "serial", .compatible =3D "xlnx,xps-uart16550-2.00.b",
> > .data =3D (void *)PORT_16550A, },
> > { .type =3D "serial", .compatible =3D "ns16550", .data =3D (void
> > *)PORT_16550, },
> > + { .type =3D "serial", .compatible =3D "ns16550a", .data =3D (void
> > *)PORT_16550A, },
> > { .type =3D "serial", .compatible =3D "ns16750", .data =3D (void
> > *)PORT_16750, },
> > { .type =3D "serial", .compatible =3D "ns16850", .data =3D (void
> > *)PORT_16850, },
> > #ifdef CONFIG_SERIAL_OF_PLATFORM_NWPSERIAL
> >
************************************************************************
**********************
> > IMPORTANT: The contents of this email and any attachments are
confidential. They are intended for
> the
> > named recipient(s) only.
> > If you have received this email in error, please notify the system
manager or the sender
> immediately
> > and do
> > not disclose the contents to anyone or make copies thereof.
> >
> >
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/linuxppc-dev
This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.
^ permalink raw reply
* RE: [PATCH/RFC] Booting Xilinx ML510 board using SystemACE
From: Stephen Neuendorffer @ 2009-11-19 17:32 UTC (permalink / raw)
To: Alon Ziv, linuxppc-dev; +Cc: John Linn
In-Reply-To: <8B957E110B62714A84290A01A597805F05D2AE38@Exchange.discretix.com>
> -----Original Message-----
> From: linuxppc-dev-bounces+stephen=3Dneuendorffer.name@lists.ozlabs.org
[mailto:linuxppc-dev-
> bounces+stephen=3Dneuendorffer.name@lists.ozlabs.org] On Behalf Of Alon
Ziv
> Sent: Thursday, November 19, 2009 4:57 AM
> To: Stephen Neuendorffer; linuxppc-dev
> Cc: John Linn
> Subject: RE: [PATCH/RFC] Booting Xilinx ML510 board using SystemACE
> =
> Hi,
> =
> On Monday, November 16, 2009, Stephen wrote:
> > There are at least two other ways that you might be able to reset a
> > board:
> > 1) Internally through the ICAP device.
> > 2) Through a GPIO connected externally to the reset logic.
> >
> =
> Unfortunately none of these is relevant for the specific board in
> question (Xilinx ML510 reference system)...
Well, board !=3D system. :) ML510 could easily include an ICAP device.
> > Probably it would be best to have a mechanism in the device tree
which
> > references the reset mechanism?
> =
> I am sorely lacking in expertise for this :(, and wouldn't even know
> where to begin... Is it possible at all to add custom information
into
> the device tree? And even if yes--how will platform code bind to the
> reset mechanism?
> =
> > [...] In any event, you probably don't want a driver to
> > eplicitly reference the plaform code. If you want to do it
explicitly
> > like this, it would better to have the plaform code reference the
> driver
> > mechanism.
> =
> I don't see how this can be done: if the driver is to publish some
> "driver_reset_system" function to the platform code, it needs _some_
> mechanism for telling this fact to the system...
Think of it this way: The driver is usable on many more platforms than
just
the one you've modified. Your addition of the hook into the platform
code
requires that that hook always be there. It would be much better to
provide a configuration-based way of allowing the platform code to
make use of the sysace reset, if it desires.
> And such a mechanism
> won't look all that different from my callback, IMO (except it may be
> slightly prettied up).
The callback isn't the problem, it's how the callback gets registered
with
the platform code/device tree.
> Of course, one obvious thing that must be done is move this code out
of
> arch/powerpc/platforms/44x/virtex.c and into (e.g.)
> arch/powerpc/kernel/setup-common.c, and add some
> "set_machine_restart_function" wrapper to access it more cleanly (also
> defining this function as a null function when inapplicable). If this
> satisfies your standards, I can easily post an updated patch :)
The driver isn't even powerpc specific, it could also be used on the
microblaze,
and I think you'll find alot of resistance to adding that kind of hook
to an architecture
that has just spent a bunch of time getting rid of alot of direct
binding between
platform code and drivers. Grant, do you have a comment here?
Steve
This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.
^ permalink raw reply
* Re: [PATCH v3 3/3] powerpc/fsl: 85xx: add cache-sram support
From: Scott Wood @ 2009-11-19 17:45 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Kumar Gala, Vivek Mahajan
In-Reply-To: <2B43D645-7977-4C24-A3EF-C55A392228B4@kernel.crashing.org>
On Thu, Nov 19, 2009 at 08:29:19AM -0600, Kumar Gala wrote:
> >>+config FSL_85XX_CACHE_SRAM_BASE
> >>+ hex
> >>+ depends on FSL_85XX_CACHE_SRAM
> >>+ default "0xfff00000"
> >>+
> >
> >I really don't like setting the physical address this way, can we
> >not do this via the device tree?
>
> At a high level I think we should add something like the following in
> the .dts:
>
> sram@fff00000 {
> fsl,sram-ctrl-handle = <&L2>;
> reg = <0xfff00000 0xNNNN>;
> compatible = "fsl,mpc85xx-l2-sram";
> }
>
> the NNNN can be the size the sram is configured as.
I don't see why this needs to go in the device tree, if it's the kernel
that is setting it up. The kernel can pick any address and size it
wants.
-Scott
^ permalink raw reply
* RE: Bug in drivers/serial/of_serial.c?
From: Stephen Neuendorffer @ 2009-11-19 17:42 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: John Linn, Alon Ziv, linuxppc-dev
In-Reply-To: <200911191833.08254.arnd@arndb.de>
> -----Original Message-----
> From: linuxppc-dev-bounces+stephen=3Dneuendorffer.name@lists.ozlabs.org
[mailto:linuxppc-dev-
> bounces+stephen=3Dneuendorffer.name@lists.ozlabs.org] On Behalf Of Arnd
Bergmann
> Sent: Thursday, November 19, 2009 9:33 AM
> To: Stephen Neuendorffer
> Cc: John Linn; Alon Ziv; linuxppc-dev@lists.ozlabs.org
> Subject: Re: Bug in drivers/serial/of_serial.c?
> =
> On Thursday 19 November 2009, Stephen Neuendorffer wrote:
> > If the problem is in the device trees that are being generated, we
> > should fix the issue there.
> > We've been trying to avoid putting the fully specified IP versions
in
> > the kernel like this, since
> > the IP changes so often.
> =
> No, the problem that Alon has is that the firmware currently has no
> way whatsoever to give a correct device tree, because of-serial.c
> does not even know about ns16550a.
> =
> The patch adds both a special-case for the specific uart he
> is using so that one is grandfathered in and a new compatible
> value so future boards can specify both ns16550a and ns16550.
That's true... The 16550a line still needs to get added, but not the
xlnx-
specific line.
Steve
This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.
^ permalink raw reply
* Re: watchdog exception on 8548CDS during cpu_idle
From: Scott Wood @ 2009-11-19 17:37 UTC (permalink / raw)
To: Ming Lei; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <7301F255FCB62048851F165FFAAF9BD106E9B3F0E5@HQ-EXCH-7.corp.brocade.com>
On Wed, Nov 18, 2009 at 03:53:27PM -0800, Ming Lei wrote:
>
> I used the vanilla linux 2.6.30 and compiled with mpc85xx_defconfig(enable CONFIG_BOOK_WDT) and then ran on 8548CDS and soon after I saw the prompt I hit this watchdog.
>
> bash-2.04# PowerPC Book-E Watchdog Exception
> NIP: c000b740 LR: c00088dc CTR: c000b6b0
> REGS: cfffbf10 TRAP: 3202 Not tainted (2.6.30)
> MSR: 00029000 <EE,ME,CE> CR: 28028048 XER: 20000000
> TASK = c04f4458[0] 'swapper' THREAD: c052c000
> GPR00: c000b6b0 c052df90 c04f4458 00800000 80804080 0000001d c053af48 00069000
> GPR08: ffffffff 00000000 08954400 00000000 002167ee 7f652f31 0ffad800 0fff0000
> GPR16: 00000000 00000000 00000000 00000000 00000000 f30a620b 0ff50450 00000000
> GPR24: 00000000 00000000 c053506c c0534fa0 c0534fa0 c052c034 00000008 c052c000
> NIP [c000b740] e500_idle+0x90/0x94
> LR [c00088dc] cpu_idle+0x98/0xec
> Call Trace:
> [c052df90] [c000889c] cpu_idle+0x58/0xec (unreliable)
> [c052dfb0] [c00023ec] rest_init+0x5c/0x70
> [c052dfc0] [c04c16f4] start_kernel+0x22c/0x290
> [c052dff0] [c0000398] skpinv+0x2b0/0x2ec
> Instruction dump:
> 7c90faa6 548402ce 7c841b78 4c00012c 7c90fba6 4c00012c 7ce000a6 64e70004
> 60e78000 7c0004ac 7ce00124 4c00012c <48000000> 812b00a0 912b0090 39600000
>
> Have anyone seen this before? Why the EE bit is on in the stack trace?
> I put show_regs in watchdog exception handler in traps.c. I verified
> that EE is off when entering the watchdog exception handler. Can I
> trust this stack trace?
EE is there because it was set in the context that got interrupted, just
as all the other state is for the interrupted context.
-Scott
^ permalink raw reply
* Re: Bug in drivers/serial/of_serial.c?
From: Arnd Bergmann @ 2009-11-19 17:33 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: John Linn, Alon Ziv, linuxppc-dev
In-Reply-To: <c2bc536b-3765-4ead-b942-88bb25253ad3@VA3EHSMHS013.ehs.local>
On Thursday 19 November 2009, Stephen Neuendorffer wrote:
> If the problem is in the device trees that are being generated, we
> should fix the issue there.
> We've been trying to avoid putting the fully specified IP versions in
> the kernel like this, since
> the IP changes so often.
No, the problem that Alon has is that the firmware currently has no
way whatsoever to give a correct device tree, because of-serial.c
does not even know about ns16550a.
The patch adds both a special-case for the specific uart he
is using so that one is grandfathered in and a new compatible
value so future boards can specify both ns16550a and ns16550.
Arnd <><
^ permalink raw reply
* RE: Bug in drivers/serial/of_serial.c?
From: Stephen Neuendorffer @ 2009-11-19 17:22 UTC (permalink / raw)
To: Alon Ziv, Arnd Bergmann, linuxppc-dev; +Cc: John Linn
In-Reply-To: <8B957E110B62714A84290A01A597805F05D2AE47@Exchange.discretix.com>
NAK.
If the problem is in the device trees that are being generated, we
should fix the issue there.
We've been trying to avoid putting the fully specified IP versions in
the kernel like this, since
the IP changes so often.
Steve
> -----Original Message-----
> From: linuxppc-dev-bounces+stephen=3Dneuendorffer.name@lists.ozlabs.org
[mailto:linuxppc-dev-
> bounces+stephen=3Dneuendorffer.name@lists.ozlabs.org] On Behalf Of Alon
Ziv
> Sent: Thursday, November 19, 2009 5:49 AM
> To: Arnd Bergmann; linuxppc-dev@lists.ozlabs.org
> Subject: RE: Bug in drivers/serial/of_serial.c?
> =
> On Thursday, November 19, 2009, Arnd Bergmann wrote:
> > I'd still add support for the compatible=3D"ns16550a" property
> > so that we do the right thing for future systems.
> >
> =
> OK...
> ---
> Xilinx 16550 UART is actually 16550A-compatible
> =
> Signed-off-by: Alon Ziv <alonz@discretix.com>
> =
> diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
> index 02406ba..241be77 100644
> --- a/drivers/serial/of_serial.c
> +++ b/drivers/serial/of_serial.c
> @@ -161,7 +161,9 @@ static int of_platform_serial_remove(struct
> of_device *ofdev)
> static struct of_device_id __devinitdata of_platform_serial_table[] =3D
{
> { .type =3D "serial", .compatible =3D "ns8250", .data =3D (void
> *)PORT_8250, },
> { .type =3D "serial", .compatible =3D "ns16450", .data =3D (void
> *)PORT_16450, },
> + { .type =3D "serial", .compatible =3D "xlnx,xps-uart16550-2.00.b",
> .data =3D (void *)PORT_16550A, },
> { .type =3D "serial", .compatible =3D "ns16550", .data =3D (void
> *)PORT_16550, },
> + { .type =3D "serial", .compatible =3D "ns16550a", .data =3D (void
> *)PORT_16550A, },
> { .type =3D "serial", .compatible =3D "ns16750", .data =3D (void
> *)PORT_16750, },
> { .type =3D "serial", .compatible =3D "ns16850", .data =3D (void
> *)PORT_16850, },
> #ifdef CONFIG_SERIAL_OF_PLATFORM_NWPSERIAL
>
************************************************************************
**********************
> IMPORTANT: The contents of this email and any attachments are
confidential. They are intended for the
> named recipient(s) only.
> If you have received this email in error, please notify the system
manager or the sender immediately
> and do
> not disclose the contents to anyone or make copies thereof.
> =
> =
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.
^ permalink raw reply
* RE: Bug in drivers/serial/of_serial.c?
From: Stephen Neuendorffer @ 2009-11-19 17:20 UTC (permalink / raw)
To: Alon Ziv, Arnd Bergmann, linuxppc-dev; +Cc: John Linn
In-Reply-To: <8B957E110B62714A84290A01A597805F05D2AE31@Exchange.discretix.com>
> -----Original Message-----
> From: linuxppc-dev-bounces+stephen=3Dneuendorffer.name@lists.ozlabs.org
[mailto:linuxppc-dev-
> bounces+stephen=3Dneuendorffer.name@lists.ozlabs.org] On Behalf Of Alon
Ziv
> Sent: Thursday, November 19, 2009 4:47 AM
> To: Arnd Bergmann; linuxppc-dev@lists.ozlabs.org
> Subject: RE: Bug in drivers/serial/of_serial.c?
> =
> Hi,
> =
> On Monday, November 16, 2009, Arnd wrote:
> > > - { .type =3D "serial", .compatible =3D "ns16550", .data =3D
(void
> *)PORT_16550, },
> > > + { .type =3D "serial", .compatible =3D "ns16550", .data =3D
(void
> *)PORT_16550A, },
> >
> > Does not seem logical. If the device claims compatibility with
> ns16550, we should
> > not automatically assume it's an ns16550a. Why not add another line
> for
> >
> =
> Unfortunately, there is no way to change what the device claims--it's
> encoded into the OpenFirmware tree by the EDK tools.
> And, in any case, the device is actually not lying: it _is_ compatible
> with NS16550--just with a non-buggy one. Unfortunately the kernel
> driver for 8250-class UARTs makes the conservative choice to assume
any
> 16550 is one of the (early, buggy) revisions where the FIFO was
> non-functional; any 16550 with working UART is classed as a 16550A.
Definitely changing what is generated by EDK seems to make sense here...
Steve
This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.
^ permalink raw reply
* Re: tg3: link is permanently down after ifdown and ifup
From: Felix Radensky @ 2009-11-19 16:08 UTC (permalink / raw)
To: netdev@vger.kernel.org, linuxppc-dev@ozlabs.org
In-Reply-To: <4B056158.5060104@embedded-sol.com>
Hi,
The problem goes away if I remove the call to
tg3_set_power_state(tp, PCI_D3hot);
from tg3_close().
Some relevant stuff from dmesg:
pci 0002:05:00.0: PME# supported from D3hot D3cold
pci 0002:05:00.0: PME# disabled
tg3.c:v3.102 (September 1, 2009)
tg3 0002:05:00.0: enabling device (0000 -> 0002)
tg3 0002:05:00.0: PME# disabled
tg3 mdio bus: probed
eth2: Tigon3 [partno(BCM57760) rev 57780001] (PCI Express) MAC address
00:10:18:00:00:00
eth2: attached PHY driver [Broadcom BCM57780] (mii_bus:phy_addr=500:01)
eth2: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
eth2: dma_rwctrl[76180000] dma_mask[64-bit]
Is my problem related to hardware or it's a tg3 driver bug ?
Thanks a lot.
Felix.
Felix Radensky wrote:
> Hi,
>
> I have a problem with tg3 driver on a custom MPC8536 based board
> running linux-2.6.31, with tg3 and Broadcom phy drivers taken from
> linux-2.6.32-rc7. Broadcom NIC is BCM57760, phy is BCM57780.
>
> The problem I'm seeing is that the downing and interface leads to
> permanent link loss, even after interface is upped again. E.g, to
> reproduce the problem it is sufficient to run:
>
> modprobe tg3
> ifconfig eth2 up
> ifconfig eth2 down
> ifconfig eth2 up
>
> After ifdown PHY LEDs also go down and do not come back
> after ifup. Ethtool reports that no link is detected. After reloading
> the driver the link comes back.
>
> Am I the only one seeing this problem ?
> Any help on fixing this is appreciated.
>
> Thanks a lot.
>
> Felix.
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: Bug in drivers/serial/of_serial.c?
From: Greg KH @ 2009-11-19 16:03 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Alon Ziv, linuxppc-dev, linux-serial
In-Reply-To: <200911191509.31270.arnd@arndb.de>
On Thu, Nov 19, 2009 at 03:09:31PM +0100, Arnd Bergmann wrote:
> On Thursday 19 November 2009, Alon Ziv wrote:
> > On Thursday, November 19, 2009, Arnd Bergmann wrote:
> > > I'd still add support for the compatible="ns16550a" property
> > > so that we do the right thing for future systems.
> > >
> >
> > OK...
> > ---
> > Xilinx 16550 UART is actually 16550A-compatible
> >
> > Signed-off-by: Alon Ziv <alonz@discretix.com>
>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
>
> Does this go through the powerpc or the tty tree?
> I'd be happy if either Ben or Greg could pick this up.
>
> I'm happy to keep maintaining the driver itself but it
> would be nice to know a definite subsystem maintainer
> responsible for it.
>
> Greg, if you want to take patches for of_serial.c generally,
> I'll start forwarding them to you as they come in and make
> sure they apply to your tree.
Sure, I would be glad to do so, send them on.
thanks,
greg k-h
^ permalink raw reply
* tg3: link is permanently down after ifdown and ifup
From: Felix Radensky @ 2009-11-19 15:16 UTC (permalink / raw)
To: netdev@vger.kernel.org, linuxppc-dev@ozlabs.org
Hi,
I have a problem with tg3 driver on a custom MPC8536 based board
running linux-2.6.31, with tg3 and Broadcom phy drivers taken from
linux-2.6.32-rc7. Broadcom NIC is BCM57760, phy is BCM57780.
The problem I'm seeing is that the downing and interface leads to
permanent link loss, even after interface is upped again. E.g, to
reproduce the problem it is sufficient to run:
modprobe tg3
ifconfig eth2 up
ifconfig eth2 down
ifconfig eth2 up
After ifdown PHY LEDs also go down and do not come back
after ifup. Ethtool reports that no link is detected. After reloading
the driver the link comes back.
Am I the only one seeing this problem ?
Any help on fixing this is appreciated.
Thanks a lot.
Felix.
^ permalink raw reply
* Re: Please pull 'next' branch of 4xx tree
From: Kumar Gala @ 2009-11-19 14:49 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <20091119144558.GQ30489@zod.rchland.ibm.com>
On Nov 19, 2009, at 8:45 AM, Josh Boyer wrote:
> On Wed, Nov 04, 2009 at 01:55:19PM -0500, Josh Boyer wrote:
>> Hi Ben,
>>
>> Please pull the next branch of the 4xx tree to get the following
>> commits.
>>
>> I have some other things in the middle of being worked that may or
>> may not
>> make it in time for the next release, so I wanted to get these
>> commits into
>> your tree now rather than wait.
>
> Erm... ping? I see you've updated your next branch but not pulled
> this
> still...
Also my next branch.
- k
^ permalink raw reply
* Re: Please pull 'next' branch of 4xx tree
From: Josh Boyer @ 2009-11-19 14:45 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <20091104185519.GI31934@zod.rchland.ibm.com>
On Wed, Nov 04, 2009 at 01:55:19PM -0500, Josh Boyer wrote:
>Hi Ben,
>
>Please pull the next branch of the 4xx tree to get the following commits.
>
>I have some other things in the middle of being worked that may or may not
>make it in time for the next release, so I wanted to get these commits into
>your tree now rather than wait.
Erm... ping? I see you've updated your next branch but not pulled this
still...
josh
^ permalink raw reply
* Re: [PATCH v3 3/3] powerpc/fsl: 85xx: add cache-sram support
From: Kumar Gala @ 2009-11-19 14:29 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Vivek Mahajan
In-Reply-To: <181208B7-AC0B-4634-A04E-46468D376719@freescale.com>
On Nov 19, 2009, at 8:21 AM, Kumar Gala wrote:
>> diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/
>> platforms/85xx/Kconfig
>> index d3a975e..b6f23c3 100644
>> --- a/arch/powerpc/platforms/85xx/Kconfig
>> +++ b/arch/powerpc/platforms/85xx/Kconfig
>> @@ -144,6 +144,15 @@ config SBC8560
>> help
>> This option enables support for the Wind River SBC8560 board
>>
>> +config FSL_85XX_CACHE_SRAM
>> + bool
>> + select PPC_LIB_RHEAP
>> +
>> +config FSL_85XX_CACHE_SRAM_BASE
>> + hex
>> + depends on FSL_85XX_CACHE_SRAM
>> + default "0xfff00000"
>> +
>
> I really don't like setting the physical address this way, can we
> not do this via the device tree?
At a high level I think we should add something like the following in
the .dts:
sram@fff00000 {
fsl,sram-ctrl-handle = <&L2>;
reg = <0xfff00000 0xNNNN>;
compatible = "fsl,mpc85xx-l2-sram";
}
the NNNN can be the size the sram is configured as.
- k
^ permalink raw reply
* Re: [PATCH v3 3/3] powerpc/fsl: 85xx: add cache-sram support
From: Kumar Gala @ 2009-11-19 14:21 UTC (permalink / raw)
To: Vivek Mahajan; +Cc: linuxppc-dev
In-Reply-To: <1256129459-10685-3-git-send-email-vivek.mahajan@freescale.com>
On Oct 21, 2009, at 7:50 AM, Vivek Mahajan wrote:
> This adds QorIQ based Cache-SRAM support as under:-
>
> * A small abstraction over powerpc's remote heap allocator
> * Exports mpc85xx_cache_sram_alloc()/free() APIs
> * Supports only one contiguous SRAM window
> * Defines FSL_85XX_CACHE_SRAM and its base address
>
> Signed-off-by: Vivek Mahajan <vivek.mahajan@freescale.com>
> ---
> v2: mbar(1) -> eieio() as per Kumar G.
> v3: Fixed cache-sram ways computation
>
> arch/powerpc/include/asm/fsl_85xx_cache_sram.h | 48 ++++++
> arch/powerpc/platforms/85xx/Kconfig | 9 ++
> arch/powerpc/sysdev/Makefile | 1 +
> arch/powerpc/sysdev/fsl_85xx_cache_ctlr.h | 95 ++++++++++++
> arch/powerpc/sysdev/fsl_85xx_cache_sram.c | 141 +++++++++++++++
> +++
> arch/powerpc/sysdev/fsl_85xx_l2ctlr.c | 184 +++++++++++++++
> +++++++++
> 6 files changed, 478 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/include/asm/fsl_85xx_cache_sram.h
> create mode 100644 arch/powerpc/sysdev/fsl_85xx_cache_ctlr.h
> create mode 100644 arch/powerpc/sysdev/fsl_85xx_cache_sram.c
> create mode 100644 arch/powerpc/sysdev/fsl_85xx_l2ctlr.c
>
> diff --git a/arch/powerpc/include/asm/fsl_85xx_cache_sram.h b/arch/
> powerpc/include/asm/fsl_85xx_cache_sram.h
> new file mode 100644
> index 0000000..2af2bdc
> --- /dev/null
> +++ b/arch/powerpc/include/asm/fsl_85xx_cache_sram.h
> @@ -0,0 +1,48 @@
> +/*
> + * Copyright 2009 Freescale Semiconductor, Inc.
> + *
> + * Cache SRAM handling for QorIQ platform
should say PQ3 & some QorIQ platforms
> + *
> + * Author: Vivek Mahajan <vivek.mahajan@freescale.com>
> +
> + * This file is derived from the original work done
> + * by Sylvain Munaut for the Bestcomm SRAM allocator.
> + *
> + * This program is free software; you can redistribute it and/or
> modify it
> + * under the terms of the GNU General Public License as
> published by the
> + * Free Software Foundation; either version 2 of the License, or
> (at your
> + * option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
> + */
> +
> +#ifndef __ASM_POWERPC_FSL_85XX_CACHE_SRAM_H__
> +#define __ASM_POWERPC_FSL_85XX_CACHE_SRAM_H__
> +
> +#include <asm/rheap.h>
> +#include <linux/spinlock.h>
> +
> +/*
> + * Cache-SRAM
> + */
> +
> +struct mpc85xx_cache_sram {
> + phys_addr_t base_phys;
> + void *base_virt;
> + unsigned int size;
> + rh_info_t *rh;
> + spinlock_t lock;
> +};
> +
> +extern void mpc85xx_cache_sram_free(void *ptr);
> +extern void *mpc85xx_cache_sram_alloc(unsigned int size,
> + phys_addr_t *phys, unsigned int align);
> +
> +#endif /* __AMS_POWERPC_FSL_85XX_CACHE_SRAM_H__ */
> diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/
> platforms/85xx/Kconfig
> index d3a975e..b6f23c3 100644
> --- a/arch/powerpc/platforms/85xx/Kconfig
> +++ b/arch/powerpc/platforms/85xx/Kconfig
> @@ -144,6 +144,15 @@ config SBC8560
> help
> This option enables support for the Wind River SBC8560 board
>
> +config FSL_85XX_CACHE_SRAM
> + bool
> + select PPC_LIB_RHEAP
> +
> +config FSL_85XX_CACHE_SRAM_BASE
> + hex
> + depends on FSL_85XX_CACHE_SRAM
> + default "0xfff00000"
> +
I really don't like setting the physical address this way, can we not
do this via the device tree?
> endif # MPC85xx
>
> config TQM85xx
> diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/
> Makefile
> index 9d4b174..745994c 100644
> --- a/arch/powerpc/sysdev/Makefile
> +++ b/arch/powerpc/sysdev/Makefile
> @@ -19,6 +19,7 @@ obj-$(CONFIG_FSL_PCI) += fsl_pci.o $(fsl-msi-obj-y)
> obj-$(CONFIG_FSL_LBC) += fsl_lbc.o
> obj-$(CONFIG_FSL_GTM) += fsl_gtm.o
> obj-$(CONFIG_MPC8xxx_GPIO) += mpc8xxx_gpio.o
> +obj-$(CONFIG_FSL_85XX_CACHE_SRAM) += fsl_85xx_l2ctlr.o
> fsl_85xx_cache_sram.o
> obj-$(CONFIG_SIMPLE_GPIO) += simple_gpio.o
> obj-$(CONFIG_RAPIDIO) += fsl_rio.o
> obj-$(CONFIG_TSI108_BRIDGE) += tsi108_pci.o tsi108_dev.o
> diff --git a/arch/powerpc/sysdev/fsl_85xx_cache_ctlr.h b/arch/
> powerpc/sysdev/fsl_85xx_cache_ctlr.h
> new file mode 100644
> index 0000000..8c4a4ac
> --- /dev/null
> +++ b/arch/powerpc/sysdev/fsl_85xx_cache_ctlr.h
> @@ -0,0 +1,95 @@
> +/*
> + * Copyright 2009 Freescale Semiconductor, Inc
> + *
> + * QorIQ based Cache Controller Memory Mapped Registers
PQ3 or some QorIQ
> + *
> + * Author: Vivek Mahajan <vivek.mahajan@freescale.com>
> + *
> + * This program is free software; you can redistribute it and/or
> modify it
> + * under the terms of the GNU General Public License as
> published by the
> + * Free Software Foundation; either version 2 of the License, or
> (at your
> + * option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
> + */
> +
> +#ifndef __FSL_85XX_CACHE_CTLR_H__
> +#define __FSL_85XX_CACHE_CTLR_H__
> +
> +#define L2CR_L2FI 0x40000000 /* L2 flash invalidate */
> +#define L2CR_L2IO 0x00200000 /* L2 instruction only */
> +#define L2CR_SRAM_ZERO 0x00000000 /* L2SRAM zero size */
> +#define L2CR_SRAM_FULL 0x00010000 /* L2SRAM full size */
> +#define L2CR_SRAM_HALF 0x00020000 /* L2SRAM half size */
> +#define L2CR_SRAM_TWO_HALFS 0x00030000 /* L2SRAM two half sizes */
> +#define L2CR_SRAM_QUART 0x00040000 /* L2SRAM one quarter size */
> +#define L2CR_SRAM_TWO_QUARTS 0x00050000 /* L2SRAM two quarter size */
> +#define L2CR_SRAM_EIGHTH 0x00060000 /* L2SRAM one eighth size */
> +#define L2CR_SRAM_TWO_EIGHTH 0x00070000 /* L2SRAM two eighth size */
> +
> +#define L2SRAM_OPTIMAL_SZ_SHIFT 0x00000003 /* Optimum size for
> L2SRAM */
> +
> +#define L2SRAM_BAR_MSK_LO18 0xFFFFC000 /* Lower 18 bits */
> +#define L2SRAM_BARE_MSK_HI4 0x0000000F /* Upper 4 bits */
> +
> +enum cache_sram_lock_ways {
> + LOCK_WAYS_ZERO,
> + LOCK_WAYS_EIGHTH,
> + LOCK_WAYS_TWO_EIGHTH,
> + LOCK_WAYS_HALF = 4,
> + LOCK_WAYS_FULL = 8,
> +};
> +
> +struct mpc85xx_l2ctlr {
> + u32 ctl; /* 0x000 - L2 control */
> + u8 res1[0xC];
> + u32 ewar0; /* 0x010 - External write address 0 */
> + u32 ewarea0; /* 0x014 - External write address extended 0 */
> + u32 ewcr0; /* 0x018 - External write ctrl */
> + u8 res2[4];
> + u32 ewar1; /* 0x020 - External write address 1 */
> + u32 ewarea1; /* 0x024 - External write address extended 1 */
> + u32 ewcr1; /* 0x028 - External write ctrl 1 */
> + u8 res3[4];
> + u32 ewar2; /* 0x030 - External write address 2 */
> + u32 ewarea2; /* 0x034 - External write address extended 2 */
> + u32 ewcr2; /* 0x038 - External write ctrl 2 */
> + u8 res4[4];
> + u32 ewar3; /* 0x040 - External write address 3 */
> + u32 ewarea3; /* 0x044 - External write address extended 3 */
> + u32 ewcr3; /* 0x048 - External write ctrl 3 */
> + u8 res5[0xB4];
> + u32 srbar0; /* 0x100 - SRAM base address 0 */
> + u32 srbarea0; /* 0x104 - SRAM base addr reg ext address 0 */
> + u32 srbar1; /* 0x108 - SRAM base address 1 */
> + u32 srbarea1; /* 0x10C - SRAM base addr reg ext address 1 */
> + u8 res6[0xCF0];
> + u32 errinjhi; /* 0xE00 - Error injection mask high */
> + u32 errinjlo; /* 0xE04 - Error injection mask low */
> + u32 errinjctl; /* 0xE08 - Error injection tag/ecc control */
> + u8 res7[0x14];
> + u32 captdatahi; /* 0xE20 - Error data high capture */
> + u32 captdatalo; /* 0xE24 - Error data low capture */
> + u32 captecc; /* 0xE28 - Error syndrome */
> + u8 res8[0x14];
> + u32 errdet; /* 0xE40 - Error detect */
> + u32 errdis; /* 0xE44 - Error disable */
> + u32 errinten; /* 0xE48 - Error interrupt enable */
> + u32 errattr; /* 0xE4c - Error attribute capture */
> + u32 erradrrl; /* 0xE50 - Error address capture low */
> + u32 erradrrh; /* 0xE54 - Error address capture high */
> + u32 errctl; /* 0xE58 - Error control */
> + u8 res9[0x1A4];
> +};
> +
> +extern int instantiate_cache_sram(struct of_device *dev, unsigned
> int size);
> +extern void remove_cache_sram(struct of_device *dev);
> +
> +#endif /* __FSL_85XX_CACHE_CTLR_H__ */
> diff --git a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c b/arch/
> powerpc/sysdev/fsl_85xx_cache_sram.c
> new file mode 100644
> index 0000000..6744083
> --- /dev/null
> +++ b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
> @@ -0,0 +1,141 @@
> +/*
> + * Copyright 2009 Freescale Semiconductor, Inc.
> + *
> + * Simple memory allocator abstraction for QorIQ (P1/P2) based
> Cache-SRAM
PQ3 or some QorIQ
> + *
> + * Author: Vivek Mahajan <vivek.mahajan@freescale.com>
> + *
> + * This file is derived from the original work done
> + * by Sylvain Munaut for the Bestcomm SRAM allocator.
> + *
> + * This program is free software; you can redistribute it and/or
> modify it
> + * under the terms of the GNU General Public License as
> published by the
> + * Free Software Foundation; either version 2 of the License, or
> (at your
> + * option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/of_platform.h>
> +#include <asm/pgtable.h>
> +#include <asm/fsl_85xx_cache_sram.h>
> +
> +struct mpc85xx_cache_sram *cache_sram;
> +
> +void *mpc85xx_cache_sram_alloc(unsigned int size,
> + phys_addr_t *phys, unsigned int align)
> +{
> + unsigned long offset;
> + unsigned long flags;
> +
> + if (!size || (size > cache_sram->size) || (align > cache_sram-
> >size)) {
> + pr_err("%s(): size(=%x) or align(=%x) zero or too big\n",
> + __func__, size, align);
> + return NULL;
> + }
> +
> + if ((align & (align - 1)) || align <= 1) {
> + pr_err("%s(): align(=%x) must be power of two and >1\n",
> + __func__, align);
> + return NULL;
> + }
> +
> + spin_lock_irqsave(&cache_sram->lock, flags);
> + offset = rh_alloc_align(cache_sram->rh, size, align, NULL);
> + spin_unlock_irqrestore(&cache_sram->lock, flags);
> +
> + if (IS_ERR_VALUE(offset))
> + return NULL;
> +
> + *phys = cache_sram->base_phys + offset;
> +
> + return (unsigned char *)cache_sram->base_virt + offset;
> +}
> +EXPORT_SYMBOL(mpc85xx_cache_sram_alloc);
> +
> +void mpc85xx_cache_sram_free(void *ptr)
> +{
> + unsigned long flags;
> + BUG_ON(!ptr);
> +
> + spin_lock_irqsave(&cache_sram->lock, flags);
> + rh_free(cache_sram->rh, ptr - cache_sram->base_virt);
> + spin_unlock_irqrestore(&cache_sram->lock, flags);
> +}
> +EXPORT_SYMBOL(mpc85xx_cache_sram_free);
> +
> +int __init instantiate_cache_sram(struct of_device *dev, unsigned
> int size)
> +{
> + if (cache_sram) {
> + dev_err(&dev->dev, "Already initialized cache-sram\n");
> + return -EBUSY;
> + }
> +
> + cache_sram = kzalloc(sizeof(struct mpc85xx_cache_sram), GFP_KERNEL);
> + if (!cache_sram) {
> + dev_err(&dev->dev, "Out of memory for cache_sram structure\n");
> + return -ENOMEM;
> + }
> +
> + cache_sram->base_phys = CONFIG_FSL_85XX_CACHE_SRAM_BASE;
> + cache_sram->size = size;
> +
> + if (!request_mem_region(cache_sram->base_phys, cache_sram->size,
> + "fsl_85xx_cache_sram")) {
> + dev_err(&dev->dev, "%s: request memory failed\n",
> + dev->node->full_name);
> + kfree(cache_sram);
> + return -ENXIO;
> + }
> +
> + cache_sram->base_virt = ioremap_flags(cache_sram->base_phys,
> + cache_sram->size, _PAGE_COHERENT | PAGE_KERNEL);
> + if (!cache_sram->base_virt) {
> + dev_err(&dev->dev, "%s: ioremap_flags failed\n",
> + dev->node->full_name);
> + release_mem_region(cache_sram->base_phys, cache_sram->size);
> + kfree(cache_sram);
> + return -ENOMEM;
> + }
> +
> + cache_sram->rh = rh_create(sizeof(unsigned int));
> + if (IS_ERR(cache_sram->rh)) {
> + dev_err(&dev->dev, "%s: Unable to create remote heap\n",
> + dev->node->full_name);
> + iounmap(cache_sram->base_virt);
> + release_mem_region(cache_sram->base_phys, cache_sram->size);
> + kfree(cache_sram);
> + return PTR_ERR(cache_sram->rh);
> + }
> +
> + rh_attach_region(cache_sram->rh, 0, cache_sram->size);
> + spin_lock_init(&cache_sram->lock);
> +
> + dev_info(&dev->dev, "[base:0x%x, size:0x%x] configured and loaded
> \n",
> + cache_sram->base_phys, cache_sram->size);
> + return 0;
> +}
> +
> +void remove_cache_sram(struct of_device *dev)
> +{
> + BUG_ON(!cache_sram);
> +
> + rh_detach_region(cache_sram->rh, 0, cache_sram->size);
> + rh_destroy(cache_sram->rh);
> +
> + iounmap(cache_sram->base_virt);
> + release_mem_region(cache_sram->base_phys, cache_sram->size);
> +
> + kfree(cache_sram);
> + cache_sram = NULL;
> +
> + dev_info(&dev->dev, "MPC85xx Cache-SRAM driver unloaded\n");
> +}
> diff --git a/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c b/arch/powerpc/
> sysdev/fsl_85xx_l2ctlr.c
> new file mode 100644
> index 0000000..c851547
> --- /dev/null
> +++ b/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c
> @@ -0,0 +1,184 @@
> +/*
> + * Copyright 2009 Freescale Semiconductor, Inc.
> + *
> + * QorIQ (P1/P2) L2 controller init for Cache-SRAM instantiation
> + *
> + * Author: Vivek Mahajan <vivek.mahajan@freescale.com>
> + *
> + * This program is free software; you can redistribute it and/or
> modify it
> + * under the terms of the GNU General Public License as
> published by the
> + * Free Software Foundation; either version 2 of the License, or
> (at your
> + * option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/of_platform.h>
> +#include <asm/io.h>
> +
> +#include "fsl_85xx_cache_ctlr.h"
> +
> +static char *param;
> +struct mpc85xx_l2ctlr __iomem *l2ctlr;
> +
> +static long get_cache_sram_size(void)
> +{
> + unsigned long val;
> +
> + if (!param || (strict_strtoul(param, 0, &val) < 0))
> + return -EINVAL;
> +
we should use memparse()
> + return val;
> +}
> +
> +static int __init get_cmdline_param(char *str)
> +{
> + if (!str)
> + return 0;
> +
> + param = str;
> + return 1;
> +}
> +
> +__setup("cache-sram-size=", get_cmdline_param);
> +
> +static int __devinit mpc85xx_l2ctlr_of_probe(struct of_device *dev,
> + const struct of_device_id *match)
> +{
> + long rval;
> + unsigned int rem;
> + unsigned char ways;
> + const unsigned int *prop;
> + unsigned int l2cache_size;
> + unsigned int sram_size;
> +
> + if (!dev->node) {
> + dev_err(&dev->dev, "Device's OF-node is NULL\n");
> + return -EINVAL;
> + }
> +
> + prop = of_get_property(dev->node, "cache-size", NULL);
> + if (!prop) {
> + dev_err(&dev->dev, "Missing L2 cache-size\n");
> + return -EINVAL;
> + }
> + l2cache_size = *prop;
> +
> + rval = get_cache_sram_size();
> + if (rval <= 0) {
> + dev_err(&dev->dev,
> + "Entire L2 as cache, Aborting Cache-SRAM stuff\n");
> + return -EINVAL;
> + }
> +
> + rem = l2cache_size % (unsigned int)rval;
> + ways = LOCK_WAYS_FULL * (unsigned int)rval / l2cache_size;
> + if (rem || (ways & (ways - 1))) {
> + dev_err(&dev->dev, "Illegal cache-sram-size in command line\n");
> + return -EINVAL;
> + }
> +
> + sram_size = (unsigned int)rval;
> +
> + l2ctlr = of_iomap(dev->node, 0);
> + if (!l2ctlr) {
> + dev_err(&dev->dev, "Can't map L2 controller\n");
> + return -EINVAL;
> + }
> +
> + /*
> + * Write bits[0-17] to srbar0
> + */
> + out_be32(&l2ctlr->srbar0,
> + CONFIG_FSL_85XX_CACHE_SRAM_BASE & L2SRAM_BAR_MSK_LO18);
> +
> + /*
> + * Write bits[18-21] to srbare0
> + */
> + out_be32(&l2ctlr->srbarea0,
> + (CONFIG_FSL_85XX_CACHE_SRAM_BASE >> 10) & L2SRAM_BARE_MSK_HI4);
> +
> + clrsetbits_be32(&l2ctlr->ctl, L2CR_L2E, L2CR_L2FI);
> +
> + switch (ways) {
> + case LOCK_WAYS_EIGHTH:
> + setbits32(&l2ctlr->ctl,
> + L2CR_L2E | L2CR_L2FI | L2CR_SRAM_EIGHTH);
> + break;
> +
> + case LOCK_WAYS_TWO_EIGHTH:
> + setbits32(&l2ctlr->ctl,
> + L2CR_L2E | L2CR_L2FI | L2CR_SRAM_QUART);
> + break;
> +
> + case LOCK_WAYS_HALF:
> + setbits32(&l2ctlr->ctl,
> + L2CR_L2E | L2CR_L2FI | L2CR_SRAM_HALF);
> + break;
> +
> + case LOCK_WAYS_FULL:
> + default:
> + setbits32(&l2ctlr->ctl,
> + L2CR_L2E | L2CR_L2FI | L2CR_SRAM_FULL);
> + break;
> + }
> + eieio();
> +
> + rval = instantiate_cache_sram(dev, sram_size);
> + if (rval < 0) {
> + dev_err(&dev->dev, "Can't instantiate Cache-SRAM\n");
> + iounmap(l2ctlr);
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +static int __devexit mpc85xx_l2ctlr_of_remove(struct of_device *dev)
> +{
> + BUG_ON(!l2ctlr);
> +
> + iounmap(l2ctlr);
> + remove_cache_sram(dev);
> + dev_info(&dev->dev, "MPC85xx L2 controller unloaded\n");
> +
> + return 0;
> +}
> +
> +static struct of_device_id mpc85xx_l2ctlr_of_match[] = {
> + {
> + .compatible = "fsl,p2020-l2-cache-controller",
> + },
> + {},
> +};
> +
> +static struct of_platform_driver mpc85xx_l2ctlr_of_platform_driver
> = {
> + .name = "fsl-l2ctlr",
> + .match_table = mpc85xx_l2ctlr_of_match,
> + .probe = mpc85xx_l2ctlr_of_probe,
> + .remove = __devexit_p(mpc85xx_l2ctlr_of_remove),
> +};
> +
> +static __init int mpc85xx_l2ctlr_of_init(void)
> +{
> + return of_register_platform_driver
> (&mpc85xx_l2ctlr_of_platform_driver);
> +}
> +
> +static void __exit mpc85xx_l2ctlr_of_exit(void)
> +{
> + of_unregister_platform_driver(&mpc85xx_l2ctlr_of_platform_driver);
> +}
> +
> +subsys_initcall(mpc85xx_l2ctlr_of_init);
> +module_exit(mpc85xx_l2ctlr_of_exit);
> +
> +MODULE_DESCRIPTION("Freescale MPC85xx L2 controller init");
> +MODULE_LICENSE("GPL v2");
> --
> 1.5.6.5
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: Bug in drivers/serial/of_serial.c?
From: Arnd Bergmann @ 2009-11-19 14:09 UTC (permalink / raw)
To: Alon Ziv; +Cc: linuxppc-dev, linux-serial, Greg KH
In-Reply-To: <8B957E110B62714A84290A01A597805F05D2AE47@Exchange.discretix.com>
On Thursday 19 November 2009, Alon Ziv wrote:
> On Thursday, November 19, 2009, Arnd Bergmann wrote:
> > I'd still add support for the compatible="ns16550a" property
> > so that we do the right thing for future systems.
> >
>
> OK...
> ---
> Xilinx 16550 UART is actually 16550A-compatible
>
> Signed-off-by: Alon Ziv <alonz@discretix.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Does this go through the powerpc or the tty tree?
I'd be happy if either Ben or Greg could pick this up.
I'm happy to keep maintaining the driver itself but it
would be nice to know a definite subsystem maintainer
responsible for it.
Greg, if you want to take patches for of_serial.c generally,
I'll start forwarding them to you as they come in and make
sure they apply to your tree.
Arnd <><
> diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
> index 02406ba..241be77 100644
> --- a/drivers/serial/of_serial.c
> +++ b/drivers/serial/of_serial.c
> @@ -161,7 +161,9 @@ static int of_platform_serial_remove(struct
> of_device *ofdev)
> static struct of_device_id __devinitdata of_platform_serial_table[] = {
> { .type = "serial", .compatible = "ns8250", .data = (void
> *)PORT_8250, },
> { .type = "serial", .compatible = "ns16450", .data = (void
> *)PORT_16450, },
> + { .type = "serial", .compatible = "xlnx,xps-uart16550-2.00.b",
> .data = (void *)PORT_16550A, },
> { .type = "serial", .compatible = "ns16550", .data = (void
> *)PORT_16550, },
> + { .type = "serial", .compatible = "ns16550a", .data = (void
> *)PORT_16550A, },
> { .type = "serial", .compatible = "ns16750", .data = (void
> *)PORT_16750, },
> { .type = "serial", .compatible = "ns16850", .data = (void
> *)PORT_16850, },
> #ifdef CONFIG_SERIAL_OF_PLATFORM_NWPSERIAL
^ permalink raw reply
* Re: [PATCH] sata_fsl: Split hard and soft reset
From: Kumar Gala @ 2009-11-19 13:57 UTC (permalink / raw)
To: Kumar Gala
Cc: linux-ppc list, linux-ide, Ashish Kalra, Jeff Garzik,
Jiang Yutang
In-Reply-To: <FF648E22-3953-4121-9DCE-862BAC5995B9@kernel.crashing.org>
On Nov 19, 2009, at 7:51 AM, Kumar Gala wrote:
>
> On Nov 5, 2009, at 9:02 AM, Kumar Gala wrote:
>
>>
>> On Oct 16, 2009, at 11:44 AM, Anton Vorontsov wrote:
>>
>>> From: Jiang Yutang <b14898@freescale.com>
>>>
>>> Split sata_fsl_softreset() into hard and soft resets to make
>>> error-handling more efficient & device and PMP detection more
>>> reliable.
>>>
>>> Also includes fix for PMP support, driver tested with Sil3726,
>>> Sil4726 & Exar PMP controllers.
>>>
>>> [AV: Also fixes resuming from deep sleep on MPC8315 CPUs]
>>>
>>> Signed-off-by: Jiang Yutang <b14898@freescale.com>
>>> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
>>> ---
>>> drivers/ata/sata_fsl.c | 84 ++++++++++++++++++++++++
>>> +-----------------------
>>> 1 files changed, 44 insertions(+), 40 deletions(-)
>>
>> Jeff,
>>
>> any update on this going in for .32?
>
> Jeff?
slightly ignore me, for some reason I didn't see your reply.
- k
^ permalink raw reply
* Re: [RFC] powerpc/mm: honor O_SYNC flag for memory map
From: Kumar Gala @ 2009-11-19 13:55 UTC (permalink / raw)
To: Li Yang; +Cc: linuxppc-dev
In-Reply-To: <1258441832-20133-1-git-send-email-leoli@freescale.com>
On Nov 17, 2009, at 1:10 AM, Li Yang wrote:
> Rather than the original intelligent way, we grant user more freedom.
> This enables user to map cacheable memory not managed by Linux.
>
> Signed-off-by: Li Yang <leoli@freescale.com>
> ---
> The only direct users of this function is fb_mmap() and /dev/mem mmap.
> Although I'm not sure if anything is depending on the intelligent
> setting of
> cacheability.
is there some reason to change this?
- k
>
> arch/powerpc/mm/mem.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
> index 579382c..0fd267e 100644
> --- a/arch/powerpc/mm/mem.c
> +++ b/arch/powerpc/mm/mem.c
> @@ -101,7 +101,7 @@ pgprot_t phys_mem_access_prot(struct file *file,
> unsigned long pfn,
> if (ppc_md.phys_mem_access_prot)
> return ppc_md.phys_mem_access_prot(file, pfn, size, vma_prot);
>
> - if (!page_is_ram(pfn))
> + if (file->f_flags & O_SYNC)
> vma_prot = pgprot_noncached(vma_prot);
>
> return vma_prot;
> --
> 1.6.4
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ 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