* Re: [RFC,PATCH] Cleanup PC parallel port Kconfig
From: Lennox Wu @ 2011-06-15 8:02 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-mips, linux-m68k, linux-ia64, linux-sh, Chen Liqin,
Paul Mackerras, H. Peter Anvin, sparclinux, Guan Xuetao,
linux-arch, Jesper Nilsson, Russell King, Yoshinori Sato,
Helge Deller, x86, James E.J. Bottomley, Ingo Molnar,
Geert Uytterhoeven, Matt Turner, Fenghua Yu, microblaze-uclinux,
Chris Metcalf, Mikael Starvik, Ivan Kokshaysky, Thomas Gleixner,
linux-arm-kernel, Richard Henderson, Chris Zankel, Michal Simek,
Tony Luck, linux-cris-kernel, linux-parisc, linux-kernel,
Ralf Baechle, Kyle McMartin, Paul Mundt, linux-alpha,
linuxppc-dev, David S. Miller
In-Reply-To: <201106142222.43553.arnd@arndb.de>
[-- Attachment #1: Type: text/plain, Size: 439 bytes --]
2011/6/15 Arnd Bergmann <arnd@arndb.de>
>
> > config SCORE
> > - def_bool y
> > - select HAVE_GENERIC_HARDIRQS
> > - select GENERIC_IRQ_SHOW
> > + def_bool y
> > + select HAVE_GENERIC_HARDIRQS
> > + select HAVE_PC_PARPORT
> > + select GENERIC_IRQ_SHOW
> >
> > choice
> > prompt "System type"
>
> Certainly not, no PIO support
>
> Yes, there is no platform of the Score supports PIO.
Best,
Lennox
[-- Attachment #2: Type: text/html, Size: 818 bytes --]
^ permalink raw reply
* Re: [RFC,PATCH] Cleanup PC parallel port Kconfig
From: Russell King - ARM Linux @ 2011-06-15 7:39 UTC (permalink / raw)
To: H. Peter Anvin
Cc: linux-mips@linux-mips.org, linux-m68k@vger.kernel.org,
linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org, Chen Liqin,
Paul Mackerras, sparclinux@vger.kernel.org, Guan Xuetao,
Lennox Wu, linux-arch@vger.kernel.org, Jesper Nilsson,
Yoshinori Sato, Helge Deller, x86@kernel.org,
James E.J. Bottomley, Ingo Molnar, Geert Uytterhoeven,
Matt Turner, Yu, Fenghua, microblaze-uclinux@itee.uq.edu.au,
Chris Metcalf, Mikael Starvik, Ivan Kokshaysky, Thomas Gleixner,
linux-arm-kernel@lists.infradead.org, Richard Henderson,
Chris Zankel, Michal Simek, Luck, Tony,
linux-parisc@vger.kernel.org, linux-cris-kernel@axis.com,
linux-kernel@vger.kernel.org, Ralf Baechle, Kyle McMartin,
Paul Mundt, linux-alpha@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, David S. Miller
In-Reply-To: <4DF8359F.10809@zytor.com>
On Tue, Jun 14, 2011 at 09:31:27PM -0700, H. Peter Anvin wrote:
> On 06/14/2011 03:08 PM, Luck, Tony wrote:
> > I took a look at the back of all my ia64 systems - none of them
> > have a parallel port. It seems unlikely that new systems will
> > start adding parallel ports :-)
> >
> > So even if I had a printer (or other device) that used a parallel
> > port, I have no way to test it.
>
> If it has PCI slots, it can have a parallel port.
Is that a clue about where a select statement should be?
^ permalink raw reply
* Re: [RFC,PATCH] Cleanup PC parallel port Kconfig
From: Russell King - ARM Linux @ 2011-06-15 7:47 UTC (permalink / raw)
To: H. Peter Anvin
Cc: linux-mips, linux-m68k, linux-ia64, linux-sh, Chen Liqin,
Paul Mackerras, sparclinux, Guan Xuetao, Lennox Wu, linux-arch,
Jesper Nilsson, Yoshinori Sato, Helge Deller, x86,
James E.J. Bottomley, Ingo Molnar, Geert Uytterhoeven,
Matt Turner, Fenghua Yu, Arnd Bergmann, microblaze-uclinux,
Chris Metcalf, Mikael Starvik, Ivan Kokshaysky, Thomas Gleixner,
linux-arm-kernel, Richard Henderson, Chris Zankel, Michal Simek,
Tony Luck, linux-cris-kernel, linux-parisc, linux-kernel,
Ralf Baechle, Kyle McMartin, Paul Mundt, linux-alpha,
linuxppc-dev, David S. Miller
In-Reply-To: <4DF83577.6040903@zytor.com>
On Tue, Jun 14, 2011 at 09:30:47PM -0700, H. Peter Anvin wrote:
> On 06/14/2011 02:33 PM, Arnd Bergmann wrote:
> >>
> >> Why on earth restrict it like that? It's just a device driver, like
> >> more or less any other device driver...
> >
> > I'd say any other classic ISA/PC driver, including floppy, gameport or
> > serial-8250. One problem with these is that we never fully worked out
> > the dependencies for these, which we probably should. CONFIG_ISA
> > generally means ISA add-on cards, but that might not be enabled for
> > platforms that have a pc-parport but no ISA slots.
> >
>
> OK, serial-8250 is clearly just plain wrong, since the 8250 series UARTs
> are ubiquitous across just about every platform.
>
> Floppy is special (in the short bus sense), since it is closely tied to
> ISA DMA. Conditionalizing this on ISA DMA makes total sense.
No it doesn't. It depends on the ISA DMA API, not that the machine has
ISA DMA.
I have a platform which has no ISA DMA but uses the floppy driver. Please
don't break it.
^ permalink raw reply
* Re: [PATCH 00/15] Backport 8xx TLB to 2.4
From: Joakim Tjernlund @ 2011-06-15 7:43 UTC (permalink / raw)
To: Willy Tarreau, Dan Malek; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <20110614193106.GA15583@1wt.eu>
Willy Tarreau <w@1wt.eu> wrote on 2011/06/14 21:31:06:
>
> Hi Joakim,
>
> On Tue, Jun 14, 2011 at 03:54:45PM +0200, Joakim Tjernlund wrote:
> > This is a backport from 2.6 which I did to overcome 8xx CPU
> > bugs. 8xx does not update the DAR register when taking a TLB
> > error caused by dcbX and icbi insns which makes it very
> > tricky to use these insns. Also the dcbst wrongly sets the
> > the store bit when faulting into DTLB error.
> > A few more bugs very found during development.
> >
> > 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.
>
> OK, I'm not opposed to merge these patches and I really welcome your
> work and want to thank you for having done it. However, I have
> absolutely *zero* skills on ppc, so I want to ensure that someone
> (possibly you) will be able to back me up in case of reported
> regressions once these patches are merged. Since you say that the
> code works on your board, I'm not much worried but at least Dan's
> comment about the risk of performance regression has to be considered.
> If we all agree that it's a tradeoff between performance and stability
> or security, then that's a different matter of course !
Yes, I will still be here :) If there are any regressions I will help out. If
we can't fix it, we can easily back these changes out. I guess I and
Dan will come to some agreement soon and I will post additional, if needed,
patches on top of what I already sent once Dan is happy.
Jocke
^ permalink raw reply
* Re: [PATCH 06/15] 8xx: Always pin kernel instruction TLB
From: Joakim Tjernlund @ 2011-06-15 7:36 UTC (permalink / raw)
To: Dan Malek; +Cc: Scott Wood, linuxppc-dev, Willy Tarreau
In-Reply-To: <OF75A64D65.5ABAA9A9-ONC12578AF.0062124A-C12578AF.0062E416@LocalDomain>
Joakim Tjernlund/Transmode wrote on 2011/06/14 20:00:09:
> From: Joakim Tjernlund/Transmode
>
> Dan Malek <ppc6dev@digitaldans.com> wrote on 2011/06/14 18:06:45:
> >
> >
> > 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.
>
> Yes, but then you also miss out on 8xx: Optimize ITLBMiss handler.
>
> >
> > Some 8xx processors have few TLB entries, and always taking
> > one for the kernel, especially if it isn't needed, could have a
> > detrimental effect on the application performance. Even the
> > "big" 8xx processors don't have that many entries. Some
> > benchmarks run on an MPC850 would likely show this.
>
> I don't have a mpc850, do you?
>
> >
> > Anyone making modifications to this level of software should
> > know of this problem, or make it known in a comment. If you
> > are making changes, just compile the code and manually
> > check it with the couple of configuration options that affect
> > the placement of the instructions.
>
> Very fragile but then again, not much are expected to change
> in this area for 8xx.
So I checked and SRR0/SRR1 are fine w.r.t to head_8xx.S, it does
not even come close. There are SRR0/SRR1 mods in entry.S too
which works fine ATM. We don't have the same control of
that file though.
Could you check what impact pinning ITLB on 850 has?
Jocke
^ permalink raw reply
* Re: Relocatable kernel for ppc44x
From: Suzuki Poulose @ 2011-06-15 6:13 UTC (permalink / raw)
To: monstr; +Cc: linuxppc-dev, John Williams
In-Reply-To: <4DF74E5D.9020908@monstr.eu>
On 06/14/11 17:34, Michal Simek wrote:
> Hi,
>
> have someone tried to support RELOCATABLE kernel on ppc44x?
As Josh, mentioned, I will be working on this. In fact I was trying a couple of
patches towards this on PPC440x. But, I am stuck in debugging the hang that I am
experiencing with the changes. I am setting up a RISCWatch processor probe to
debug the same.
Here is some information that I wanted to share :
The PPC440X currently uses 256M TLB entries to pin the lowmem. When we go for a
relocatable kernel we have to :
1) Restrict the kernel load address to be 256M aligned
OR
2) Use 16M TLB(the next possible TLB page size supported) entries till the first
256M and then use the 256M TLB entries for the rest of lowmem.
Option 1 is not feasible.
Towards this, I have tried a patch which uses 16M TLB entries to map the entire
lowmem on an ebony board. But that doesn't seem to work. I am setting up the JTAG
to debug the state.
I have attached the patch below for your reference. Any suggestions/comments would
be really helpful.
Thanks
Suzuki
==============================
Use 16M TLB pages to pin the lowmem on PPC440x.
---
arch/powerpc/include/asm/mmu-44x.h | 9 +++++++++
arch/powerpc/kernel/head_44x.S | 2 +-
arch/powerpc/mm/44x_mmu.c | 2 +-
3 files changed, 11 insertions(+), 2 deletions(-)
Index: linux-2.6.38.1/arch/powerpc/include/asm/mmu-44x.h
===================================================================
--- linux-2.6.38.1.orig/arch/powerpc/include/asm/mmu-44x.h
+++ linux-2.6.38.1/arch/powerpc/include/asm/mmu-44x.h
@@ -121,7 +121,12 @@ typedef struct {
#endif
/* Size of the TLBs used for pinning in lowmem */
+#define PPC_PIN_SIZE (1 << 24) /* 16M */
+#define PPC44x_TLB_PIN_SIZE PPC44x_TLB_16M
+#if 0
#define PPC_PIN_SIZE (1 << 28) /* 256M */
+#define PPC44x_TLB_PIN_SIZE PPC44x_TLB_256M
+#endif
#if (PAGE_SHIFT == 12)
#define PPC44x_TLBE_SIZE PPC44x_TLB_4K
@@ -142,7 +147,11 @@ typedef struct {
#error "Unsupported PAGE_SIZE"
#endif
+#if 0
#define mmu_linear_psize MMU_PAGE_256M
+#else
+#define mmu_linear_psize MMU_PAGE_16M
+#endif
#define PPC44x_PGD_OFF_SHIFT (32 - PGDIR_SHIFT + PGD_T_LOG2)
#define PPC44x_PGD_OFF_MASK_BIT (PGDIR_SHIFT - PGD_T_LOG2)
Index: linux-2.6.38.1/arch/powerpc/kernel/head_44x.S
===================================================================
--- linux-2.6.38.1.orig/arch/powerpc/kernel/head_44x.S
+++ linux-2.6.38.1/arch/powerpc/kernel/head_44x.S
@@ -805,7 +805,7 @@ skpinv: addi r4,r4,1 /* Increment */
/* pageid fields */
clrrwi r3,r3,10 /* Mask off the effective page number */
- ori r3,r3,PPC44x_TLB_VALID | PPC44x_TLB_256M
+ ori r3,r3,PPC44x_TLB_VALID | PPC44x_TLB_PIN_SIZE
/* xlat fields */
clrrwi r4,r4,10 /* Mask off the real page number */
Index: linux-2.6.38.1/arch/powerpc/mm/44x_mmu.c
===================================================================
--- linux-2.6.38.1.orig/arch/powerpc/mm/44x_mmu.c
+++ linux-2.6.38.1/arch/powerpc/mm/44x_mmu.c
@@ -84,7 +84,7 @@ static void __init ppc44x_pin_tlb(unsign
: "r" (PPC44x_TLB_SW | PPC44x_TLB_SR | PPC44x_TLB_SX | PPC44x_TLB_G),
#endif
"r" (phys),
- "r" (virt | PPC44x_TLB_VALID | PPC44x_TLB_256M),
+ "r" (virt | PPC44x_TLB_VALID | PPC44x_TLB_PIN_SIZE),
"r" (entry),
"i" (PPC44x_TLB_PAGEID),
"i" (PPC44x_TLB_XLAT),
^ permalink raw reply
* Re: [RFC,PATCH] Cleanup PC parallel port Kconfig
From: H. Peter Anvin @ 2011-06-15 5:43 UTC (permalink / raw)
To: Guenter Roeck
Cc: linux-mips@linux-mips.org, linux-m68k@vger.kernel.org,
linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org, Chen Liqin,
Paul Mackerras, sparclinux@vger.kernel.org, Guan Xuetao,
Lennox Wu, linux-arch@vger.kernel.org, Jesper Nilsson,
Russell King, Yoshinori Sato, Helge Deller, x86@kernel.org,
James E.J. Bottomley, Ingo Molnar, Geert Uytterhoeven,
Matt Turner, Fenghua Yu, microblaze-uclinux@itee.uq.edu.au,
Chris Metcalf, Mikael Starvik, Ivan Kokshaysky, Thomas Gleixner,
linux-arm-kernel@lists.infradead.org, Richard Henderson,
Chris Zankel, Michal Simek, Tony Luck,
linux-parisc@vger.kernel.org, linux-cris-kernel@axis.com,
linux-kernel@vger.kernel.org, Ralf Baechle, Kyle McMartin,
Paul Mundt, linux-alpha@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, David S. Miller
In-Reply-To: <20110615044016.GC10553@ericsson.com>
On 06/14/2011 09:40 PM, Guenter Roeck wrote:
> On Wed, Jun 15, 2011 at 12:18:36AM -0400, H. Peter Anvin wrote:
>> On 06/14/2011 03:34 PM, Ralf Baechle wrote:
>>>
>>> There is no point in offering to build something that couldn't possibly be
>>> used. It just makes the kernel harder to configure and inflates the test
>>> matrix for no good reason.
>>>
>>
>> I see... that's why a bunch of devices that only exist on ARM and MIPS
>> SoCs are offered on x86 platforms?
>>
> http://en.wikipedia.org/wiki/Two_wrongs_make_a_right
>
Except in this case it's not wrong. It was done that way because it was
discovered a long time ago that restricting drivers that were not
*inherently* limited to specific platform just resulted in more bitrot
and nasty surprises for the users who *did* need specific things after
all, even though the maintainers had not thought so.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
^ permalink raw reply
* Re: [RFC,PATCH] Cleanup PC parallel port Kconfig
From: Guenter Roeck @ 2011-06-15 4:40 UTC (permalink / raw)
To: H. Peter Anvin
Cc: linux-mips@linux-mips.org, linux-m68k@vger.kernel.org,
linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org, Chen Liqin,
Paul Mackerras, sparclinux@vger.kernel.org, Guan Xuetao,
Lennox Wu, linux-arch@vger.kernel.org, Jesper Nilsson,
Russell King, Yoshinori Sato, Helge Deller, x86@kernel.org,
James E.J. Bottomley, Ingo Molnar, Geert Uytterhoeven,
Matt Turner, Fenghua Yu, microblaze-uclinux@itee.uq.edu.au,
Chris Metcalf, Mikael Starvik, Ivan Kokshaysky, Thomas Gleixner,
linux-arm-kernel@lists.infradead.org, Richard Henderson,
Chris Zankel, Michal Simek, Tony Luck,
linux-parisc@vger.kernel.org, linux-cris-kernel@axis.com,
linux-kernel@vger.kernel.org, Ralf Baechle, Kyle McMartin,
Paul Mundt, linux-alpha@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, David S. Miller
In-Reply-To: <4DF8329C.7000904@zytor.com>
On Wed, Jun 15, 2011 at 12:18:36AM -0400, H. Peter Anvin wrote:
> On 06/14/2011 03:34 PM, Ralf Baechle wrote:
> >
> > There is no point in offering to build something that couldn't possibly be
> > used. It just makes the kernel harder to configure and inflates the test
> > matrix for no good reason.
> >
>
> I see... that's why a bunch of devices that only exist on ARM and MIPS
> SoCs are offered on x86 platforms?
>
http://en.wikipedia.org/wiki/Two_wrongs_make_a_right
Guenter
^ permalink raw reply
* Re: [RFC,PATCH] Cleanup PC parallel port Kconfig
From: H. Peter Anvin @ 2011-06-15 4:31 UTC (permalink / raw)
To: Luck, Tony
Cc: linux-mips@linux-mips.org, linux-m68k@vger.kernel.org,
linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org, Chen Liqin,
Paul Mackerras, sparclinux@vger.kernel.org, Guan Xuetao,
Lennox Wu, linux-arch@vger.kernel.org, Jesper Nilsson,
Russell King, Yoshinori Sato, Helge Deller, x86@kernel.org,
James E.J. Bottomley, Ingo Molnar, Geert Uytterhoeven,
Matt Turner, Yu, Fenghua, microblaze-uclinux@itee.uq.edu.au,
Chris Metcalf, Mikael Starvik, Ivan Kokshaysky, Thomas Gleixner,
linux-arm-kernel@lists.infradead.org, Richard Henderson,
Chris Zankel, Michal Simek, linux-parisc@vger.kernel.org,
linux-cris-kernel@axis.com, linux-kernel@vger.kernel.org,
Ralf Baechle, Kyle McMartin, Paul Mundt,
linux-alpha@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
David S. Miller
In-Reply-To: <987664A83D2D224EAE907B061CE93D5301E7281306@orsmsx505.amr.corp.intel.com>
On 06/14/2011 03:08 PM, Luck, Tony wrote:
> diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
> index 38280ef..849805a 100644
> --- a/arch/ia64/Kconfig
> +++ b/arch/ia64/Kconfig
> @@ -23,6 +23,7 @@ config IA64
> select HAVE_ARCH_TRACEHOOK
> select HAVE_DMA_API_DEBUG
> select HAVE_GENERIC_HARDIRQS
> + select HAVE_PC_PARPORT
> select GENERIC_IRQ_PROBE
> select GENERIC_PENDING_IRQ if SMP
> select IRQ_PER_CPU
>
> I took a look at the back of all my ia64 systems - none of them
> have a parallel port. It seems unlikely that new systems will
> start adding parallel ports :-)
>
> So even if I had a printer (or other device) that used a parallel
> port, I have no way to test it.
>
If it has PCI slots, it can have a parallel port.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
^ permalink raw reply
* Re: [RFC,PATCH] Cleanup PC parallel port Kconfig
From: H. Peter Anvin @ 2011-06-15 4:30 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-mips, linux-m68k, linux-ia64, linux-sh, Chen Liqin,
Paul Mackerras, sparclinux, Guan Xuetao, Lennox Wu, linux-arch,
Jesper Nilsson, Russell King, Yoshinori Sato, Helge Deller, x86,
James E.J. Bottomley, Ingo Molnar, Geert Uytterhoeven,
Matt Turner, Fenghua Yu, microblaze-uclinux, Chris Metcalf,
Mikael Starvik, Ivan Kokshaysky, Thomas Gleixner,
linux-arm-kernel, Richard Henderson, Chris Zankel, Michal Simek,
Tony Luck, linux-cris-kernel, linux-parisc, linux-kernel,
Ralf Baechle, Kyle McMartin, Paul Mundt, linux-alpha,
linuxppc-dev, David S. Miller
In-Reply-To: <201106142333.16203.arnd@arndb.de>
On 06/14/2011 02:33 PM, Arnd Bergmann wrote:
>>
>> Why on earth restrict it like that? It's just a device driver, like
>> more or less any other device driver...
>
> I'd say any other classic ISA/PC driver, including floppy, gameport or
> serial-8250. One problem with these is that we never fully worked out
> the dependencies for these, which we probably should. CONFIG_ISA
> generally means ISA add-on cards, but that might not be enabled for
> platforms that have a pc-parport but no ISA slots.
>
OK, serial-8250 is clearly just plain wrong, since the 8250 series UARTs
are ubiquitous across just about every platform.
Floppy is special (in the short bus sense), since it is closely tied to
ISA DMA. Conditionalizing this on ISA DMA makes total sense.
Parallel port is an intermediate case... Centronics parallel ports
predate the PC ecosystem by quite a bit, and the particular arrangement
of ports became popular with the PC and spread to other platforms, but
the particular variant of it known as ECP (as opposed to EPP) is ISA DMA
specific.
> On the other hand, you have embedded platforms that currently build support
> for parport-pc but define the inb/outb macros to plain pointer dereferences
> (otherwise you can't build the 8250 driver). Loading parport-pc on those
> machines typically results in derefencing user memory in the best case.
>
> What I'd love to see is a configuration option for "arch has working
> PC-style inb/outb instructions", so we can build a kernel without them but
> still get MMIO based drivers for PCI-less platforms.
Now, isn't that was iowrite/ioread was designed for?
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
^ permalink raw reply
* Re: [RFC,PATCH] Cleanup PC parallel port Kconfig
From: H. Peter Anvin @ 2011-06-15 4:18 UTC (permalink / raw)
To: Ralf Baechle
Cc: linux-mips, linux-m68k, linux-ia64, linux-sh, Chen Liqin,
Paul Mackerras, sparclinux, Guan Xuetao, Lennox Wu, linux-arch,
Jesper Nilsson, Russell King, Yoshinori Sato, Helge Deller, x86,
James E.J. Bottomley, Ingo Molnar, Geert Uytterhoeven,
Matt Turner, Fenghua Yu, microblaze-uclinux, Chris Metcalf,
Mikael Starvik, Ivan Kokshaysky, Thomas Gleixner,
linux-arm-kernel, Richard Henderson, Chris Zankel, Michal Simek,
Tony Luck, linux-parisc, linux-cris-kernel, linux-kernel,
Kyle McMartin, Paul Mundt, linux-alpha, linuxppc-dev,
David S. Miller
In-Reply-To: <20110614223404.GA30057@linux-mips.org>
On 06/14/2011 03:34 PM, Ralf Baechle wrote:
>
> There is no point in offering to build something that couldn't possibly be
> used. It just makes the kernel harder to configure and inflates the test
> matrix for no good reason.
>
I see... that's why a bunch of devices that only exist on ARM and MIPS
SoCs are offered on x86 platforms?
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: disable timebase synchronization under the hypervisor
From: Benjamin Herrenschmidt @ 2011-06-15 2:33 UTC (permalink / raw)
To: Tabi Timur-B04825
Cc: McClintock Matthew-B29882, Wood Scott-B07421, Gala Kumar-B11780,
paulus@samba.org, linuxppc-dev@ozlabs.org
In-Reply-To: <4DF814A3.7070209@freescale.com>
On Wed, 2011-06-15 at 02:10 +0000, Tabi Timur-B04825 wrote:
> Benjamin Herrenschmidt wrote:
> > We might want to generically have a CPU feature bit indicating we are
> > running in guest vs. HV mode. I know Paulus is planning to introduce one
> > so you may want to sync with him.
>
> Are you talking about CPU_FTR_HVMODE_206?
Well, not exactly. Paul wants to break that up since we're adding some
primitive support for 201 HV mode too (for 970's). Last we discussed,
the plan was to go for a generic HV mode bit and a separate bit for the
version.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: disable timebase synchronization under the hypervisor
From: Tabi Timur-B04825 @ 2011-06-15 2:10 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Wood Scott-B07421, Tabi Timur-B04825, linuxppc-dev@ozlabs.org,
paulus@samba.org, McClintock Matthew-B29882, Gala Kumar-B11780
In-Reply-To: <1308103091.2635.13.camel@pasglop>
Benjamin Herrenschmidt wrote:
> We might want to generically have a CPU feature bit indicating we are
> running in guest vs. HV mode. I know Paulus is planning to introduce one
> so you may want to sync with him.
Are you talking about CPU_FTR_HVMODE_206?
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: disable timebase synchronization under the hypervisor
From: Benjamin Herrenschmidt @ 2011-06-15 1:58 UTC (permalink / raw)
To: Scott Wood; +Cc: Matthew McClintock, kumar.gala, Timur Tabi, linuxppc-dev
In-Reply-To: <20110614182517.776d7e77@schlenkerla.am.freescale.net>
On Tue, 2011-06-14 at 18:25 -0500, Scott Wood wrote:
> On Tue, 14 Jun 2011 18:15:26 -0500
> Timur Tabi <timur@freescale.com> wrote:
>
> > Scott Wood wrote:
> > > FWIW, it's not supported under KVM either -- though we don't support an SMP
> > > guest under KVM yet, and KVM silently ignores it rather than logs errors as
> > > the FSL HV does.
> >
> > Does KVM set the root compatible to "fsl,P4080DS-hv"?
>
> No, Qemu/KVM like to pretend they're fully emulating concrete hardware,
> even though there's stuff missing.
>
> The only upstream e500 KVM platform is currently mpc8544ds.
>
> For now, there's no SMP KVM guest support. Maybe kexec can be fixed to not
> hard-reset the core by the time that changes. :-)
We might want to generically have a CPU feature bit indicating we are
running in guest vs. HV mode. I know Paulus is planning to introduce one
so you may want to sync with him.
Cheers,
Ben.
^ permalink raw reply
* Re: [RFC,PATCH] Cleanup PC parallel port Kconfig
From: Guan Xuetao @ 2011-06-15 1:24 UTC (permalink / raw)
To: Ralf Baechle
Cc: linux-mips, linux-m68k, linux-ia64, linux-sh, Chen Liqin,
Paul Mackerras, H. Peter Anvin, sparclinux, Lennox Wu, linux-arch,
Jesper Nilsson, Russell King, Yoshinori Sato, Helge Deller, x86,
James E.J. Bottomley, Ingo Molnar, Geert Uytterhoeven,
Matt Turner, Fenghua Yu, microblaze-uclinux, Chris Metcalf,
Mikael Starvik, Ivan Kokshaysky, Thomas Gleixner,
linux-arm-kernel, Richard Henderson, Chris Zankel, Michal Simek,
Tony Luck, linux-parisc, linux-cris-kernel, linux-kernel,
Kyle McMartin, Paul Mundt, linux-alpha, linuxppc-dev,
David S. Miller
In-Reply-To: <20110614190850.GA13526@linux-mips.org>
On Tue, 2011-06-14 at 20:08 +0100, Ralf Baechle wrote:
> The PC parallel port Kconfig as acquired one of those messy terms to
> describe it's architecture dependencies:
>
> depends on (!SPARC64 || PCI) && !SPARC32 && !M32R && !FRV && \
> (!M68K || ISA) && !MN10300 && !AVR32 && !BLACKFIN
>
> This isn't just ugly - it also almost certainly describes the dependencies
> too coarse grainedly. This is an attempt at cleaing the mess up.
>
> I tried to faithfully aproximate the old behaviour but the existing
> behaviour seems inacurate if not wrong for some architectures or platforms.
> To improve on this I rely on comments from other arch and platforms
> maintainers. Any system that can take PCI multi-IO card or has a PC-style
> parallel port on the mainboard should probably should now do a
> select HAVE_PC_PARPORT. And some arch Kconfig files should further
> restrict the use of HAVE_PC_PARPORT to only those platforms that actually
> need it.
>
> Thanks,
>
> Ralf
> diff --git a/arch/unicore32/Kconfig b/arch/unicore32/Kconfig
> index e57dcce..3832e7e 100644
> --- a/arch/unicore32/Kconfig
> +++ b/arch/unicore32/Kconfig
> @@ -8,6 +8,7 @@ config UNICORE32
> select HAVE_KERNEL_BZIP2
> select HAVE_KERNEL_LZO
> select HAVE_KERNEL_LZMA
> + select HAVE_PC_PARPORT
> select GENERIC_FIND_FIRST_BIT
> select GENERIC_IRQ_PROBE
> select GENERIC_IRQ_SHOW
In UniCore32, only some debug-boards need to support parport.
So I'd like to add HAVE_PC_PARPORT and related configs to certian
*_defconfig, but not in Kconfig.
Thanks Ralf.
Guan Xuetao
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: disable timebase synchronization under the hypervisor
From: Scott Wood @ 2011-06-14 23:25 UTC (permalink / raw)
To: Timur Tabi; +Cc: Matthew McClintock, kumar.gala, linuxppc-dev
In-Reply-To: <4DF7EB8E.8020308@freescale.com>
On Tue, 14 Jun 2011 18:15:26 -0500
Timur Tabi <timur@freescale.com> wrote:
> Scott Wood wrote:
> > FWIW, it's not supported under KVM either -- though we don't support an SMP
> > guest under KVM yet, and KVM silently ignores it rather than logs errors as
> > the FSL HV does.
>
> Does KVM set the root compatible to "fsl,P4080DS-hv"?
No, Qemu/KVM like to pretend they're fully emulating concrete hardware,
even though there's stuff missing.
The only upstream e500 KVM platform is currently mpc8544ds.
For now, there's no SMP KVM guest support. Maybe kexec can be fixed to not
hard-reset the core by the time that changes. :-)
-Scott
^ permalink raw reply
* Re: [RFC,PATCH] Cleanup PC parallel port Kconfig
From: Ralf Baechle @ 2011-06-14 22:34 UTC (permalink / raw)
To: H. Peter Anvin
Cc: linux-mips, linux-m68k, linux-ia64, linux-sh, Chen Liqin,
Paul Mackerras, sparclinux, Guan Xuetao, Lennox Wu, linux-arch,
Jesper Nilsson, Russell King, Yoshinori Sato, Helge Deller, x86,
James E.J. Bottomley, Ingo Molnar, Geert Uytterhoeven,
Matt Turner, Fenghua Yu, microblaze-uclinux, Chris Metcalf,
Mikael Starvik, Ivan Kokshaysky, Thomas Gleixner,
linux-arm-kernel, Richard Henderson, Chris Zankel, Michal Simek,
Tony Luck, linux-parisc, linux-cris-kernel, linux-kernel,
Kyle McMartin, Paul Mundt, linux-alpha, linuxppc-dev,
David S. Miller
In-Reply-To: <4DF7C3CA.9050902@zytor.com>
On Tue, Jun 14, 2011 at 01:25:46PM -0700, H. Peter Anvin wrote:
> On 06/14/2011 12:08 PM, Ralf Baechle wrote:
> > The PC parallel port Kconfig as acquired one of those messy terms to
> > describe it's architecture dependencies:
> >
> > depends on (!SPARC64 || PCI) && !SPARC32 && !M32R && !FRV && \
> > (!M68K || ISA) && !MN10300 && !AVR32 && !BLACKFIN
> >
> > This isn't just ugly - it also almost certainly describes the dependencies
> > too coarse grainedly. This is an attempt at cleaing the mess up.
> >
> > I tried to faithfully aproximate the old behaviour but the existing
> > behaviour seems inacurate if not wrong for some architectures or platforms.
> > To improve on this I rely on comments from other arch and platforms
> > maintainers. Any system that can take PCI multi-IO card or has a PC-style
> > parallel port on the mainboard should probably should now do a
> > select HAVE_PC_PARPORT. And some arch Kconfig files should further
> > restrict the use of HAVE_PC_PARPORT to only those platforms that actually
> > need it.
> >
>
> Why on earth restrict it like that? It's just a device driver, like
> more or less any other device driver...
Some of the older MIPS systems are based on PC chipsets from Intel, OPTi
or others. On those you can expect the parport_pc driver to actually work.
The ISA/PCI implementations are often between lackluster and pure brokeness
such as with non-functioning I/O port address space. So I don't want to
run such drivers on such a platforms, things might turn ugly.
Embedded systems often have PCI but no PCI slots or there may even be an
apropriate SuperIO chip in the the system but nothing wired to the parallel
port bits.
And there are systems such as DECstations which have nothing that even
at a parsec's distance has a similarity to (E)ISA or PCI - but still
PARPORT_PC is offered along with 40 other options that depend on it.
There is no point in offering to build something that couldn't possibly be
used. It just makes the kernel harder to configure and inflates the test
matrix for no good reason.
Ralf
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: disable timebase synchronization under the hypervisor
From: Timur Tabi @ 2011-06-14 23:15 UTC (permalink / raw)
To: Scott Wood; +Cc: Matthew McClintock, kumar.gala, linuxppc-dev
In-Reply-To: <20110614181406.294cdf5f@schlenkerla.am.freescale.net>
Scott Wood wrote:
> FWIW, it's not supported under KVM either -- though we don't support an SMP
> guest under KVM yet, and KVM silently ignores it rather than logs errors as
> the FSL HV does.
Does KVM set the root compatible to "fsl,P4080DS-hv"?
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: disable timebase synchronization under the hypervisor
From: Scott Wood @ 2011-06-14 23:14 UTC (permalink / raw)
To: Timur Tabi; +Cc: Matthew McClintock, kumar.gala, linuxppc-dev
In-Reply-To: <1308092673-13045-1-git-send-email-timur@freescale.com>
On Tue, 14 Jun 2011 18:04:33 -0500
Timur Tabi <timur@freescale.com> wrote:
> The Freescale hypervisor does not allow guests to write to the timebase
> registers (virtualizing the timebase register was deemed too complicated),
> so don't try to synchronize the timebase registers when we're running
> under the hypervisor.
>
> This typically happens when kexec support is enabled.
>
> Signed-off-by: Timur Tabi <timur@freescale.com>
FWIW, it's not supported under KVM either -- though we don't support an SMP
guest under KVM yet, and KVM silently ignores it rather than logs errors as
the FSL HV does.
-Scott
^ permalink raw reply
* [PATCH] powerpc/85xx: disable timebase synchronization under the hypervisor
From: Timur Tabi @ 2011-06-14 23:04 UTC (permalink / raw)
To: kumar.gala, scottwood, B29882, linuxppc-dev
The Freescale hypervisor does not allow guests to write to the timebase
registers (virtualizing the timebase register was deemed too complicated),
so don't try to synchronize the timebase registers when we're running
under the hypervisor.
This typically happens when kexec support is enabled.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
arch/powerpc/platforms/85xx/p3041_ds.c | 11 +++++++++++
arch/powerpc/platforms/85xx/p4080_ds.c | 11 +++++++++++
arch/powerpc/platforms/85xx/p5020_ds.c | 11 +++++++++++
3 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/p3041_ds.c b/arch/powerpc/platforms/85xx/p3041_ds.c
index c0242bc..8b651dfe 100644
--- a/arch/powerpc/platforms/85xx/p3041_ds.c
+++ b/arch/powerpc/platforms/85xx/p3041_ds.c
@@ -40,6 +40,9 @@
static int __init p3041_ds_probe(void)
{
unsigned long root = of_get_flat_dt_root();
+#ifdef CONFIG_SMP
+ extern struct smp_ops_t smp_85xx_ops;
+#endif
if (of_flat_dt_is_compatible(root, "fsl,P3041DS"))
return 1;
@@ -51,6 +54,14 @@ static int __init p3041_ds_probe(void)
ppc_md.restart = fsl_hv_restart;
ppc_md.power_off = fsl_hv_halt;
ppc_md.halt = fsl_hv_halt;
+#ifdef CONFIG_SMP
+ /*
+ * Disable the timebase sync operations because we can't write
+ * to the timebase registers under the hypervisor.
+ */
+ smp_85xx_ops.give_timebase = NULL;
+ smp_85xx_ops.take_timebase = NULL;
+#endif
return 1;
}
diff --git a/arch/powerpc/platforms/85xx/p4080_ds.c b/arch/powerpc/platforms/85xx/p4080_ds.c
index 32ea5eb..ae859ab 100644
--- a/arch/powerpc/platforms/85xx/p4080_ds.c
+++ b/arch/powerpc/platforms/85xx/p4080_ds.c
@@ -39,6 +39,9 @@
static int __init p4080_ds_probe(void)
{
unsigned long root = of_get_flat_dt_root();
+#ifdef CONFIG_SMP
+ extern struct smp_ops_t smp_85xx_ops;
+#endif
if (of_flat_dt_is_compatible(root, "fsl,P4080DS"))
return 1;
@@ -50,6 +53,14 @@ static int __init p4080_ds_probe(void)
ppc_md.restart = fsl_hv_restart;
ppc_md.power_off = fsl_hv_halt;
ppc_md.halt = fsl_hv_halt;
+#ifdef CONFIG_SMP
+ /*
+ * Disable the timebase sync operations because we can't write
+ * to the timebase registers under the hypervisor.
+ */
+ smp_85xx_ops.give_timebase = NULL;
+ smp_85xx_ops.take_timebase = NULL;
+#endif
return 1;
}
diff --git a/arch/powerpc/platforms/85xx/p5020_ds.c b/arch/powerpc/platforms/85xx/p5020_ds.c
index 2ea9ccc..d951618 100644
--- a/arch/powerpc/platforms/85xx/p5020_ds.c
+++ b/arch/powerpc/platforms/85xx/p5020_ds.c
@@ -40,6 +40,9 @@
static int __init p5020_ds_probe(void)
{
unsigned long root = of_get_flat_dt_root();
+#ifdef CONFIG_SMP
+ extern struct smp_ops_t smp_85xx_ops;
+#endif
if (of_flat_dt_is_compatible(root, "fsl,P5020DS"))
return 1;
@@ -51,6 +54,14 @@ static int __init p5020_ds_probe(void)
ppc_md.restart = fsl_hv_restart;
ppc_md.power_off = fsl_hv_halt;
ppc_md.halt = fsl_hv_halt;
+#ifdef CONFIG_SMP
+ /*
+ * Disable the timebase sync operations because we can't write
+ * to the timebase registers under the hypervisor.
+ */
+ smp_85xx_ops.give_timebase = NULL;
+ smp_85xx_ops.take_timebase = NULL;
+#endif
return 1;
}
--
1.7.3.4
^ permalink raw reply related
* RE: [RFC,PATCH] Cleanup PC parallel port Kconfig
From: Luck, Tony @ 2011-06-14 22:08 UTC (permalink / raw)
To: Ralf Baechle, linux-arch@vger.kernel.org, Benjamin Herrenschmidt,
Chen Liqin, Chris Metcalf, Chris Zankel, David S. Miller,
Yu, Fenghua, Geert Uytterhoeven, Guan Xuetao, Helge Deller,
H. Peter Anvin, Ingo Molnar, Ivan Kokshaysky,
James E.J. Bottomley, Jesper Nilsson, Kyle McMartin, Lennox Wu,
Matt Turner, Michal Simek, Mikael Starvik, Paul Mackerras,
Paul Mundt, Richard Henderson, Russell King,
sparclinux@vger.kernel.org, Thomas Gleixner, x86@kernel.org,
Yoshinori Sato
Cc: linux-mips@linux-mips.org, linux-m68k@vger.kernel.org,
linux-ia64@vger.kernel.org, linux-parisc@vger.kernel.org,
linux-cris-kernel@axis.com, linux-sh@vger.kernel.org,
microblaze-uclinux@itee.uq.edu.au, linux-kernel@vger.kernel.org,
linux-alpha@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20110614190850.GA13526@linux-mips.org>
diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
index 38280ef..849805a 100644
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@ -23,6 +23,7 @@ config IA64
select HAVE_ARCH_TRACEHOOK
select HAVE_DMA_API_DEBUG
select HAVE_GENERIC_HARDIRQS
+ select HAVE_PC_PARPORT
select GENERIC_IRQ_PROBE
select GENERIC_PENDING_IRQ if SMP
select IRQ_PER_CPU
I took a look at the back of all my ia64 systems - none of them
have a parallel port. It seems unlikely that new systems will
start adding parallel ports :-)
So even if I had a printer (or other device) that used a parallel
port, I have no way to test it.
-Tony
^ permalink raw reply related
* Re: [RFC,PATCH] Cleanup PC parallel port Kconfig
From: Arnd Bergmann @ 2011-06-14 21:33 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-mips, linux-m68k, linux-ia64, linux-sh, Chen Liqin,
Paul Mackerras, H. Peter Anvin, sparclinux, Guan Xuetao,
Lennox Wu, linux-arch, Jesper Nilsson, Russell King,
Yoshinori Sato, Helge Deller, x86, James E.J. Bottomley,
Ingo Molnar, Geert Uytterhoeven, Matt Turner, Fenghua Yu,
microblaze-uclinux, Chris Metcalf, Mikael Starvik,
Ivan Kokshaysky, Thomas Gleixner, Richard Henderson, Chris Zankel,
Michal Simek, Tony Luck, linux-cris-kernel, linux-parisc,
linux-kernel, Ralf Baechle, Kyle McMartin, Paul Mundt,
linux-alpha, linuxppc-dev, David S. Miller
In-Reply-To: <4DF7C3CA.9050902@zytor.com>
On Tuesday 14 June 2011 22:25:46 H. Peter Anvin wrote:
> On 06/14/2011 12:08 PM, Ralf Baechle wrote:
> > The PC parallel port Kconfig as acquired one of those messy terms to
> > describe it's architecture dependencies:
> >
> > depends on (!SPARC64 || PCI) && !SPARC32 && !M32R && !FRV && \
> > (!M68K || ISA) && !MN10300 && !AVR32 && !BLACKFIN
> >
> > This isn't just ugly - it also almost certainly describes the dependencies
> > too coarse grainedly. This is an attempt at cleaing the mess up.
> >
> > I tried to faithfully aproximate the old behaviour but the existing
> > behaviour seems inacurate if not wrong for some architectures or platforms.
> > To improve on this I rely on comments from other arch and platforms
> > maintainers. Any system that can take PCI multi-IO card or has a PC-style
> > parallel port on the mainboard should probably should now do a
> > select HAVE_PC_PARPORT. And some arch Kconfig files should further
> > restrict the use of HAVE_PC_PARPORT to only those platforms that actually
> > need it.
> >
>
> Why on earth restrict it like that? It's just a device driver, like
> more or less any other device driver...
I'd say any other classic ISA/PC driver, including floppy, gameport or
serial-8250. One problem with these is that we never fully worked out
the dependencies for these, which we probably should. CONFIG_ISA
generally means ISA add-on cards, but that might not be enabled for
platforms that have a pc-parport but no ISA slots.
On the other hand, you have embedded platforms that currently build support
for parport-pc but define the inb/outb macros to plain pointer dereferences
(otherwise you can't build the 8250 driver). Loading parport-pc on those
machines typically results in derefencing user memory in the best case.
What I'd love to see is a configuration option for "arch has working
PC-style inb/outb instructions", so we can build a kernel without them but
still get MMIO based drivers for PCI-less platforms.
Arnd
^ permalink raw reply
* Re: [RFC,PATCH] Cleanup PC parallel port Kconfig
From: H. Peter Anvin @ 2011-06-14 20:25 UTC (permalink / raw)
To: Ralf Baechle
Cc: linux-mips, linux-m68k, linux-ia64, linux-sh, Chen Liqin,
Paul Mackerras, sparclinux, Guan Xuetao, Lennox Wu, linux-arch,
Jesper Nilsson, Russell King, Yoshinori Sato, Helge Deller, x86,
James E.J. Bottomley, Ingo Molnar, Geert Uytterhoeven,
Matt Turner, Fenghua Yu, microblaze-uclinux, Chris Metcalf,
Mikael Starvik, Ivan Kokshaysky, Thomas Gleixner,
linux-arm-kernel, Richard Henderson, Chris Zankel, Michal Simek,
Tony Luck, linux-parisc, linux-cris-kernel, linux-kernel,
Kyle McMartin, Paul Mundt, linux-alpha, linuxppc-dev,
David S. Miller
In-Reply-To: <20110614190850.GA13526@linux-mips.org>
On 06/14/2011 12:08 PM, Ralf Baechle wrote:
> The PC parallel port Kconfig as acquired one of those messy terms to
> describe it's architecture dependencies:
>
> depends on (!SPARC64 || PCI) && !SPARC32 && !M32R && !FRV && \
> (!M68K || ISA) && !MN10300 && !AVR32 && !BLACKFIN
>
> This isn't just ugly - it also almost certainly describes the dependencies
> too coarse grainedly. This is an attempt at cleaing the mess up.
>
> I tried to faithfully aproximate the old behaviour but the existing
> behaviour seems inacurate if not wrong for some architectures or platforms.
> To improve on this I rely on comments from other arch and platforms
> maintainers. Any system that can take PCI multi-IO card or has a PC-style
> parallel port on the mainboard should probably should now do a
> select HAVE_PC_PARPORT. And some arch Kconfig files should further
> restrict the use of HAVE_PC_PARPORT to only those platforms that actually
> need it.
>
Why on earth restrict it like that? It's just a device driver, like
more or less any other device driver...
-hpa
^ permalink raw reply
* Re: [RFC,PATCH] Cleanup PC parallel port Kconfig
From: Geert Uytterhoeven @ 2011-06-14 20:32 UTC (permalink / raw)
To: Ralf Baechle
Cc: linux-mips, linux-m68k, linux-ia64, linux-sh, Chen Liqin,
Paul Mackerras, H. Peter Anvin, sparclinux, Guan Xuetao,
Lennox Wu, linux-arch, Jesper Nilsson, Russell King,
Yoshinori Sato, Helge Deller, x86, James E.J. Bottomley,
Ingo Molnar, Matt Turner, Fenghua Yu, microblaze-uclinux,
Chris Metcalf, Mikael Starvik, Ivan Kokshaysky, Thomas Gleixner,
linux-arm-kernel, Richard Henderson, Chris Zankel, Michal Simek,
Tony Luck, linux-parisc, linux-cris-kernel, linux-kernel,
Kyle McMartin, Paul Mundt, linux-alpha, linuxppc-dev,
David S. Miller
In-Reply-To: <20110614190850.GA13526@linux-mips.org>
On Tue, Jun 14, 2011 at 21:08, Ralf Baechle <ralf@linux-mips.org> wrote:
> The PC parallel port Kconfig as acquired one of those messy terms to
> describe it's architecture dependencies:
>
> =C2=A0 =C2=A0 =C2=A0 depends on (!SPARC64 || PCI) && !SPARC32 && !M32R &&=
!FRV && \
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (!M68K || ISA) && !MN103=
00 && !AVR32 && !BLACKFIN
>
> This isn't just ugly - it also almost certainly describes the dependencie=
s
> too coarse grainedly. =C2=A0This is an attempt at cleaing the mess up.
> --- a/arch/m68k/Kconfig.mmu
> +++ b/arch/m68k/Kconfig.mmu
> @@ -399,6 +399,7 @@ config ISA
> =C2=A0 =C2=A0 =C2=A0 =C2=A0bool
> =C2=A0 =C2=A0 =C2=A0 =C2=A0depends on Q40 || AMIGA_PCMCIA
> =C2=A0 =C2=A0 =C2=A0 =C2=A0default y
> + =C2=A0 =C2=A0 =C2=A0 select PARPORT_PC
Why do you select PARPORT_PC here instead of HAVE_PC_PARPORT?
Gr{oetje,eeting}s,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k=
.org
In personal conversations with technical people, I call myself a hacker. Bu=
t
when I'm talking to journalists I just say "programmer" or something like t=
hat.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0=C2=A0 -- Linus Torvalds
^ permalink raw reply
* Re: Mapping an executable page
From: Scott Wood @ 2011-06-14 20:26 UTC (permalink / raw)
To: Thomas De Schampheleire; +Cc: linuxppc-dev, Tabi Timur-B04825
In-Reply-To: <BANLkTimhKOvY8XA=_20rjtkZ0Um45o2Bow@mail.gmail.com>
On Tue, 14 Jun 2011 10:56:31 +0200
Thomas De Schampheleire <patrickdepinguin+linuxppc@gmail.com> wrote:
> * Therefore, to make sure that the mapping I intended with __ioremap()
> is actually reflected in the TLB tables, I added dummy reads of each
> page in the TLB, prior to jumping to the boot code, as follows:
> /* make sure memory is read, once every 4Kbyte is enough */
> for (p = vaddr; p < vaddr + map_size; p += 0x1000) {
> unsigned long dummy = *(volatile unsigned long *)p;
> (void)dummy;
> }
>
> * After these changes (make sure all code is mapped + make sure to
> read all pages so that the TLBs are updated), my scenario works fine.
This is fragile -- you are assuming that it's possible to fit this
set of pages in TLB0 all at once, and that none of them will be
evicted/invalidated by the time you're done.
If you really need to do this, I sugest using settlbcam() from
arch/powerpc/mm/fsl_booke_mmu.c to create TLB1 entries with IPROT set.
Better still if you could live with whatever memory the kernel has already
pinned.
-Scott
^ 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