* Re: hang w/ppc6xx_defconfig related to 'simple-bus' compatible
From: Scott Wood @ 2008-08-06 17:35 UTC (permalink / raw)
To: Grant Likely; +Cc: ppc-dev list
In-Reply-To: <20080806134128.GA9533@secretlab.ca>
On Wed, Aug 06, 2008 at 07:41:28AM -0600, Grant Likely wrote:
> On Tue, Aug 05, 2008 at 08:21:31AM -0500, Kumar Gala wrote:
> > I'm trying to get the ppc6xx_defconfig booting on any 8641 (74xx/e600)
> > system. If I remove the 'simple-bus' compatible from the soc node in
> > the .dts it works. Otherwise it hangs at but and looks to be crashed in
> > the serial driver due to accessing memory at 0.
> >
> > I've tried the same .dts (w/'simple-bus') using the
> > mpc8641_hpcn_defconfig and things work.
>
> The Xilinx folks hit something similar. ns16550 nodes get matched if
> the parent claims simple-bus. If extra stuff needs to be done to use
> that port, then bad things happen.
If extra stuff needs to be done, it shouldn't claim to be a simple-bus.
-Scott
^ permalink raw reply
* RE: hang w/ppc6xx_defconfig related to 'simple-bus' compatible
From: Stephen Neuendorffer @ 2008-08-06 18:02 UTC (permalink / raw)
To: Scott Wood, grant.likely; +Cc: ppc-dev list
In-Reply-To: <20080806173547.GD3138@ld0162-tx32.am.freescale.net>
The problem (in my case) is that the legacy-serial driver doesn't accept
all of the 16550 configurations accepted by the regular ns16550 driver.
The problem is not related to simple-bus, but only became visible when
simple-bus bindings are used because the legacy-serial driver
specifically looks for an ns16550 node contained by a simple-bus.
Most likely the hpcn_defconfig disables the legacy-serial driver
altogether.
Steve
> -----Original Message-----
> From: linuxppc-dev-bounces+stephen.neuendorffer=3Dxilinx.com@ozlabs.org
[mailto:linuxppc-dev-
> bounces+stephen.neuendorffer=3Dxilinx.com@ozlabs.org] On Behalf Of Scott
Wood
> Sent: Wednesday, August 06, 2008 10:36 AM
> To: grant.likely@secretlab.ca
> Cc: ppc-dev list
> Subject: Re: hang w/ppc6xx_defconfig related to 'simple-bus'
compatible
> =
> On Wed, Aug 06, 2008 at 07:41:28AM -0600, Grant Likely wrote:
> > On Tue, Aug 05, 2008 at 08:21:31AM -0500, Kumar Gala wrote:
> > > I'm trying to get the ppc6xx_defconfig booting on any 8641
(74xx/e600)
> > > system. If I remove the 'simple-bus' compatible from the soc node
in
> > > the .dts it works. Otherwise it hangs at but and looks to be
crashed in
> > > the serial driver due to accessing memory at 0.
> > >
> > > I've tried the same .dts (w/'simple-bus') using the
> > > mpc8641_hpcn_defconfig and things work.
> >
> > The Xilinx folks hit something similar. ns16550 nodes get matched
if
> > the parent claims simple-bus. If extra stuff needs to be done to
use
> > that port, then bad things happen.
> =
> If extra stuff needs to be done, it shouldn't claim to be a
simple-bus.
> =
> -Scott
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/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: Big include file move breaks user mode
From: René Rebe @ 2008-08-06 17:44 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev, Arnd Bergmann
In-Reply-To: <20080806110124.40280d13@lappy.seanm.ca>
Hi,
Sean MacLennan wrote:
> On Wed, 6 Aug 2008 16:51:40 +0200
> "Arnd Bergmann" <arnd@arndb.de> wrote:
>
>
>> The user space headers are provided by your distribution, not
>> by the kernel, so include/asm should be a directory, not a symlink.
>> If you are building your own distro, don't just copy the files
>> but rather use 'make headers_install' to get a sanitized version.
>>
>
> Sorry, I forgot to reply to the list :( Kumar mentioned the "make
> headers_install" and I got it working with our build system. So
> everything is back on track.
>
Heh, you might also consider using "off the shelf" build systems, such
as the T2 SDE:
http://t2-project.org
To avoid re-inventing the wheel again and again.
Yours,
--
René Rebe - ExactCODE GmbH - Europe, Germany, Berlin
http://exactcode.de | http://t2-project.org | http://rene.rebe.name
^ permalink raw reply
* Re: Big include file move breaks user mode
From: René Rebe @ 2008-08-06 17:43 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev, Arnd Bergmann
In-Reply-To: <20080806110124.40280d13@lappy.seanm.ca>
Hi,
Sean MacLennan wrote:
> On Wed, 6 Aug 2008 16:51:40 +0200
> "Arnd Bergmann" <arnd@arndb.de> wrote:
>
>
>> The user space headers are provided by your distribution, not
>> by the kernel, so include/asm should be a directory, not a symlink.
>> If you are building your own distro, don't just copy the files
>> but rather use 'make headers_install' to get a sanitized version.
>>
>
> Sorry, I forgot to reply to the list :( Kumar mentioned the "make
> headers_install" and I got it working with our build system. So
> everything is back on track.
>
Heh, you might also consider using "off the shelf" build systems, such
as the T2 SDE:
http://t2-project.org
To avoid re-inventing the whell again and again.
Yours,
--
René Rebe - ExactCODE GmbH - Europe, Germany, Berlin
http://exactcode.de | http://t2-project.org | http://rene.rebe.name
^ permalink raw reply
* Re: hang w/ppc6xx_defconfig related to 'simple-bus' compatible
From: Kumar Gala @ 2008-08-06 18:39 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: Scott Wood, ppc-dev list
In-Reply-To: <20080806180206.35FAB718066@mail214-wa4.bigfish.com>
Do you know what the CONFIG_ option is called for the legacy driver.
- k
On Aug 6, 2008, at 1:02 PM, Stephen Neuendorffer wrote:
>
> The problem (in my case) is that the legacy-serial driver doesn't
> accept
> all of the 16550 configurations accepted by the regular ns16550
> driver.
> The problem is not related to simple-bus, but only became visible when
> simple-bus bindings are used because the legacy-serial driver
> specifically looks for an ns16550 node contained by a simple-bus.
>
> Most likely the hpcn_defconfig disables the legacy-serial driver
> altogether.
>
> Steve
>
>> -----Original Message-----
>> From: linuxppc-dev-bounces+stephen.neuendorffer=xilinx.com@ozlabs.org
> [mailto:linuxppc-dev-
>> bounces+stephen.neuendorffer=xilinx.com@ozlabs.org] On Behalf Of
>> Scott
> Wood
>> Sent: Wednesday, August 06, 2008 10:36 AM
>> To: grant.likely@secretlab.ca
>> Cc: ppc-dev list
>> Subject: Re: hang w/ppc6xx_defconfig related to 'simple-bus'
> compatible
>>
>> On Wed, Aug 06, 2008 at 07:41:28AM -0600, Grant Likely wrote:
>>> On Tue, Aug 05, 2008 at 08:21:31AM -0500, Kumar Gala wrote:
>>>> I'm trying to get the ppc6xx_defconfig booting on any 8641
> (74xx/e600)
>>>> system. If I remove the 'simple-bus' compatible from the soc node
> in
>>>> the .dts it works. Otherwise it hangs at but and looks to be
> crashed in
>>>> the serial driver due to accessing memory at 0.
>>>>
>>>> I've tried the same .dts (w/'simple-bus') using the
>>>> mpc8641_hpcn_defconfig and things work.
>>>
>>> The Xilinx folks hit something similar. ns16550 nodes get matched
> if
>>> the parent claims simple-bus. If extra stuff needs to be done to
> use
>>> that port, then bad things happen.
>>
>> If extra stuff needs to be done, it shouldn't claim to be a
> simple-bus.
>>
>> -Scott
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>
> This email and any attachments are intended for the sole use of the
> named recipient(s) and contain(s) confidential information that may
> be proprietary, privileged or copyrighted under applicable law. If
> you are not the intended recipient, do not read, copy, or forward
> this email message or any attachments. Delete this email message and
> any attachments immediately.
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* RE: hang w/ppc6xx_defconfig related to 'simple-bus' compatible
From: John Linn @ 2008-08-06 19:03 UTC (permalink / raw)
To: Kumar Gala, Stephen Neuendorffer; +Cc: Scott Wood, ppc-dev list
In-Reply-To: <2EA786FE-D62D-4F09-BE3E-F5198D71FDB1@kernel.crashing.org>
I was thinking it's CONFIG_PPC_UDBG_16550.
-- John
> -----Original Message-----
> From: linuxppc-dev-bounces+john.linn=3Dxilinx.com@ozlabs.org
[mailto:linuxppc-dev-
> bounces+john.linn=3Dxilinx.com@ozlabs.org] On Behalf Of Kumar Gala
> Sent: Wednesday, August 06, 2008 12:39 PM
> To: Stephen Neuendorffer
> Cc: Scott Wood; ppc-dev list
> Subject: Re: hang w/ppc6xx_defconfig related to 'simple-bus'
compatible
> =
> Do you know what the CONFIG_ option is called for the legacy driver.
> =
> - k
> =
> On Aug 6, 2008, at 1:02 PM, Stephen Neuendorffer wrote:
> =
> >
> > The problem (in my case) is that the legacy-serial driver doesn't
> > accept
> > all of the 16550 configurations accepted by the regular ns16550
> > driver.
> > The problem is not related to simple-bus, but only became visible
when
> > simple-bus bindings are used because the legacy-serial driver
> > specifically looks for an ns16550 node contained by a simple-bus.
> >
> > Most likely the hpcn_defconfig disables the legacy-serial driver
> > altogether.
> >
> > Steve
> >
> >> -----Original Message-----
> >> From:
linuxppc-dev-bounces+stephen.neuendorffer=3Dxilinx.com@ozlabs.org
> > [mailto:linuxppc-dev-
> >> bounces+stephen.neuendorffer=3Dxilinx.com@ozlabs.org] On Behalf Of
> >> Scott
> > Wood
> >> Sent: Wednesday, August 06, 2008 10:36 AM
> >> To: grant.likely@secretlab.ca
> >> Cc: ppc-dev list
> >> Subject: Re: hang w/ppc6xx_defconfig related to 'simple-bus'
> > compatible
> >>
> >> On Wed, Aug 06, 2008 at 07:41:28AM -0600, Grant Likely wrote:
> >>> On Tue, Aug 05, 2008 at 08:21:31AM -0500, Kumar Gala wrote:
> >>>> I'm trying to get the ppc6xx_defconfig booting on any 8641
> > (74xx/e600)
> >>>> system. If I remove the 'simple-bus' compatible from the soc
node
> > in
> >>>> the .dts it works. Otherwise it hangs at but and looks to be
> > crashed in
> >>>> the serial driver due to accessing memory at 0.
> >>>>
> >>>> I've tried the same .dts (w/'simple-bus') using the
> >>>> mpc8641_hpcn_defconfig and things work.
> >>>
> >>> The Xilinx folks hit something similar. ns16550 nodes get matched
> > if
> >>> the parent claims simple-bus. If extra stuff needs to be done to
> > use
> >>> that port, then bad things happen.
> >>
> >> If extra stuff needs to be done, it shouldn't claim to be a
> > simple-bus.
> >>
> >> -Scott
> >> _______________________________________________
> >> Linuxppc-dev mailing list
> >> Linuxppc-dev@ozlabs.org
> >> https://ozlabs.org/mailman/listinfo/linuxppc-dev
> >
> >
> > This email and any attachments are intended for the sole use of the
> > named recipient(s) and contain(s) confidential information that may
> > be proprietary, privileged or copyrighted under applicable law. If
> > you are not the intended recipient, do not read, copy, or forward
> > this email message or any attachments. Delete this email message and
> > any attachments immediately.
> >
> >
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-dev
> =
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/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: [RFC] [PATCH 0/5 V2] Huge page backed user-space stacks
From: Andi Kleen @ 2008-08-06 18:49 UTC (permalink / raw)
To: Andrew Morton
Cc: Mel Gorman, linuxppc-dev, libhugetlbfs-devel, linux-kernel,
linux-mm
In-Reply-To: <20080730103407.b110afc2.akpm@linux-foundation.org>
Andrew Morton <akpm@linux-foundation.org> writes:
> Do we expect that this change will be replicated in other
> memory-intensive apps? (I do).
The catch with 2MB pages on x86 is that x86 CPUs generally have
much less 2MB TLB entries than 4K entries. So if you're unlucky
and access a lot of mappings you might actually thrash more with
them. That is why they are not necessarily an universal win.
-Andi
^ permalink raw reply
* Re: Big include file move breaks user mode
From: Kumar Gala @ 2008-08-06 19:21 UTC (permalink / raw)
To: René Rebe
Cc: ppc-dev list, Linux-Embedded, Arnd Bergmann, Sean MacLennan
In-Reply-To: <4899E2FE.6090709@exactcode.de>
On Aug 6, 2008, at 12:44 PM, Ren=E9 Rebe wrote:
>
> Heh, you might also consider using "off the shelf" build systems, such
> as the T2 SDE:
>
> http://t2-project.org
>
> To avoid re-inventing the wheel again and again.
>
> Yours,
>
Whee.. another rootfs build system. Why we can't converge some of =20
these towards so we have a larger community is beyond me.
- k=
^ permalink raw reply
* problem in booting kernel with mpc836x_mds.dtb
From: surendranath.moilla @ 2008-08-06 19:46 UTC (permalink / raw)
To: Linuxppc-dev
Hi,
I have the following problem, when i am trying to boot linux on
MPC8360E MDS board with the mpc836x_mds.dtb created using dtc and
mpc836x_mds.dts in from /arch/powerpc/boot/platforms/dts/ directory of
linux-2.6.22 version.
fdt_chosen: FDT_ERR_BADMAGIC
after this it is trying to re boot.
how to resolve this issue, so i need to apply any pathces to
mpc836x_mds.dts file.
NOTE: i am using dtc compiled from linux-2.6.26 version.
Regards
Surendra
^ permalink raw reply
* Re: [RFC] [PATCH 0/5 V2] Huge page backed user-space stacks
From: Dave Hansen @ 2008-08-06 19:50 UTC (permalink / raw)
To: Mel Gorman
Cc: linux-mm, libhugetlbfs-devel, linux-kernel, linuxppc-dev, abh,
ebmunson, Andrew Morton
In-Reply-To: <20080806090222.GD21190@csn.ul.ie>
On Wed, 2008-08-06 at 10:02 +0100, Mel Gorman wrote:
> > That said, this particular patch doesn't appear *too* bound to hugetlb
> > itself. But, some of its limitations *do* come from the filesystem,
> > like its inability to handle VM_GROWS...
>
> The lack of VM_GROWSX is an issue, but on its own it does not justify
> the amount of churn necessary to support direct pagetable insertions for
> MAP_ANONYMOUS|MAP_PRIVATE. I think we'd need another case or two that would
> really benefit from direct insertions to pagetables instead of hugetlbfs so
> that the path would get adequately tested.
I'm jumping around here a bit, but I'm trying to get to the core of what
my problem with these patches is. I'll see if I can close the loop
here.
The main thing this set of patches does that I care about is take an
anonymous VMA and replace it with a hugetlb VMA. It does this on a
special cue, but does it nonetheless.
This patch has crossed a line in that it is really the first
*replacement* of a normal VMA with a hugetlb VMA instead of the creation
of the VMAs at the user's request. I'm really curious what the plan is
to follow up on this. Will this stack stuff turn out to be one-off
code, or is this *the* route for getting transparent large pages in the
future?
Because of the limitations like its inability to grow the VMA, I can't
imagine that this would be a generic mechanism that we can use
elsewhere.
-- Dave
^ permalink raw reply
* Re: to schedule() or not to schedule() ?
From: Arnd Bergmann @ 2008-08-06 21:12 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Kevin Diggs
In-Reply-To: <4899059A.3020703@hypersurf.com>
On Wednesday 06 August 2008, Kevin Diggs wrote:
> For the purpose of learning, there is no direct, correct way to yield
> the cpu when in a timer fired routine, right?
>
No, in a timer, you interrupt a totally unrelated thread, so sleeping
would prevent that from running on, as well as preventing other timers
from being run, so it's not an option.
One thing that might work for you would be to re-arm the existing
timer and return from your function, so you get back to it after
a short while.
Arnd <><
^ permalink raw reply
* [PATCH] Delete completed "ppc removal" task from feature removal file.
From: Robert P. J. Day @ 2008-08-06 17:58 UTC (permalink / raw)
To: Linux PPC Mailing List; +Cc: Andrew Morton
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
---
unless this is in someone's tree already.
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index c239554..17cab3c 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -205,19 +205,6 @@ Who: Tejun Heo <htejun@gmail.com>
---------------------------
-What: The arch/ppc and include/asm-ppc directories
-When: Jun 2008
-Why: The arch/powerpc tree is the merged architecture for ppc32 and ppc64
- platforms. Currently there are efforts underway to port the remaining
- arch/ppc platforms to the merged tree. New submissions to the arch/ppc
- tree have been frozen with the 2.6.22 kernel release and that tree will
- remain in bug-fix only mode until its scheduled removal. Platforms
- that are not ported by June 2008 will be removed due to the lack of an
- interested maintainer.
-Who: linuxppc-dev@ozlabs.org
-
----------------------------
-
What: i386/x86_64 bzImage symlinks
When: April 2010
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
Have classroom, will lecture.
http://crashcourse.ca Waterloo, Ontario, CANADA
========================================================================
^ permalink raw reply related
* Re: [RFC/PATCH 1/3] powerpc: add ioremap_bat() function for setting up BAT translated IO regions.
From: Grant Likely @ 2008-08-06 21:54 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, paulus, miltonm
In-Reply-To: <CD66FAA8-BC99-4630-9FFF-E2C651E5DE9A@kernel.crashing.org>
On Wed, Aug 6, 2008 at 8:07 AM, Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Aug 6, 2008, at 1:02 AM, Grant Likely wrote:
>
>> From: Grant Likely <grant.likely@secretlab.ca>
>>
>> ioremap_bat() is useful for things like mapping SoC internally memory
>> mapped
>> register and early text because it allows mappings to devices to be setup
>> early in the boot process where they are needed, and the mappings persist
>> after the MMU is configured.
>>
>> Without ioremap_bat(), setting up the MMU would cause the early text
>> mappings to get lost and mostly likely result in a kernel panic on the
>> next
>> attempt at output.
>>
>> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
>> ---
>
> why can't we just do this in ioremap itself?
I suppose we could; but the usecase is somewhat different and I wanted
to keep it simple. Using a separate API also helps reenforce that the
caller really needs to know what they are doing because BATs are a
limited resource.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [RFC/PATCH 1/3] powerpc: add ioremap_bat() function for setting up BAT translated IO regions.
From: Kumar Gala @ 2008-08-06 22:11 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, paulus, miltonm
In-Reply-To: <fa686aa40808061454t14737278h3fd15fb0ccdbf251@mail.gmail.com>
On Aug 6, 2008, at 4:54 PM, Grant Likely wrote:
> On Wed, Aug 6, 2008 at 8:07 AM, Kumar Gala
> <galak@kernel.crashing.org> wrote:
>>
>> On Aug 6, 2008, at 1:02 AM, Grant Likely wrote:
>>
>>> From: Grant Likely <grant.likely@secretlab.ca>
>>>
>>> ioremap_bat() is useful for things like mapping SoC internally
>>> memory
>>> mapped
>>> register and early text because it allows mappings to devices to
>>> be setup
>>> early in the boot process where they are needed, and the mappings
>>> persist
>>> after the MMU is configured.
>>>
>>> Without ioremap_bat(), setting up the MMU would cause the early text
>>> mappings to get lost and mostly likely result in a kernel panic on
>>> the
>>> next
>>> attempt at output.
>>>
>>> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
>>> ---
>>
>> why can't we just do this in ioremap itself?
>
> I suppose we could; but the usecase is somewhat different and I wanted
> to keep it simple. Using a separate API also helps reenforce that the
> caller really needs to know what they are doing because BATs are a
> limited resource.
there is a bunch of error checking and difference in semantics that
you need to fix. I think introduce a new API for this is silly,
especially since we expect there to only be one actual invocation of
the API for serial console access.
- k
^ permalink raw reply
* Re: [RFC/PATCH 1/3] powerpc: add ioremap_bat() function for setting up BAT translated IO regions.
From: Benjamin Herrenschmidt @ 2008-08-06 22:26 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, paulus, miltonm
In-Reply-To: <20080806060223.30717.35175.stgit@trillian.secretlab.ca>
On Wed, 2008-08-06 at 00:02 -0600, Grant Likely wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
>
> ioremap_bat() is useful for things like mapping SoC internally memory mapped
> register and early text because it allows mappings to devices to be setup
> early in the boot process where they are needed, and the mappings persist
> after the MMU is configured.
>
> Without ioremap_bat(), setting up the MMU would cause the early text
> mappings to get lost and mostly likely result in a kernel panic on the next
> attempt at output.
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> ---
First comment, make the name more generic. This facility could be
implemented on processors without BATs using different techniques.
Maybe ioremap_block() or ioremap_early() or something like that.
> diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
> index 066e65c..7b25b57 100644
> --- a/arch/powerpc/kernel/setup_32.c
> +++ b/arch/powerpc/kernel/setup_32.c
> @@ -113,6 +113,15 @@ notrace unsigned long __init early_init(unsigned long dt_ptr)
> */
> notrace void __init machine_init(unsigned long dt_ptr, unsigned long phys)
> {
> + /* Do the bare minimum to start allocting from the IO region so
> + * that ioremap_bat() works */
> +#ifdef CONFIG_HIGHMEM
> + ioremap_base = PKMAP_BASE;
> +#else
> + ioremap_base = 0xfe000000UL; /* for now, could be 0xfffff000 */
> +#endif /* CONFIG_HIGHMEM */
> + ioremap_bot = ioremap_base;
> +
Can't these be statically initialized ? If not, then do a function call
to mm/ please. Something like mm_init_early().
> + /* BAT mappings must be 128k aligned */
> + if (addr != _ALIGN_DOWN(addr, 128 << 10))
> + return NULL;
Mustn't they be naturally aligned on their size ?
Cheers,
Ben.
^ permalink raw reply
* Re: [RFC/PATCH 1/3] powerpc: add ioremap_bat() function for setting up BAT translated IO regions.
From: Scott Wood @ 2008-08-06 22:31 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, paulus, miltonm
In-Reply-To: <75A0A752-FF2C-41B6-A6D3-E510E8FD4E91@kernel.crashing.org>
Kumar Gala wrote:
> On Aug 6, 2008, at 4:54 PM, Grant Likely wrote:
>> I suppose we could; but the usecase is somewhat different and I
>> wanted to keep it simple. Using a separate API also helps
>> reenforce that the caller really needs to know what they are doing
>> because BATs are a limited resource.
>
> there is a bunch of error checking and difference in semantics that
> you need to fix. I think introduce a new API for this is silly,
Why is it silly? It seems silly to me to complicate ioremap() with
knowing when to use BATs and when not to use them.
> especially since we expect there to only be one actual invocation of
> the API for serial console access.
I could also see a BAT (or equivalent) being used for IMMR-space, or
other frequently accessed registers, to save TLB entries.
-Scott
^ permalink raw reply
* Re: [RFC/PATCH 1/3] powerpc: add ioremap_bat() function for setting up BAT translated IO regions.
From: Benjamin Herrenschmidt @ 2008-08-06 22:28 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, paulus, miltonm
In-Reply-To: <75A0A752-FF2C-41B6-A6D3-E510E8FD4E91@kernel.crashing.org>
> there is a bunch of error checking and difference in semantics that
> you need to fix. I think introduce a new API for this is silly,
> especially since we expect there to only be one actual invocation of
> the API for serial console access.
Not necessarily....
There's another aspect to BAT mappings here. First, they should be
permanent (ie, not unmappable). That way, we have ioremap just use
an existing BAT mapping when asked for a device that is covered
by a BAT. This allows to have platform code do something like setup
a BAT over a bunch of SOC registers or over a device, to automagically
get drivers doing ioremap to that area benefit from it.
Ben.
^ permalink raw reply
* Re: [RFC/PATCH 1/3] powerpc: add ioremap_bat() function for setting up BAT translated IO regions.
From: Grant Likely @ 2008-08-06 23:02 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, paulus, miltonm
In-Reply-To: <75A0A752-FF2C-41B6-A6D3-E510E8FD4E91@kernel.crashing.org>
On Wed, Aug 6, 2008 at 4:11 PM, Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Aug 6, 2008, at 4:54 PM, Grant Likely wrote:
>
>> On Wed, Aug 6, 2008 at 8:07 AM, Kumar Gala <galak@kernel.crashing.org>
>> wrote:
>>>
>>> On Aug 6, 2008, at 1:02 AM, Grant Likely wrote:
>>>
>>>> From: Grant Likely <grant.likely@secretlab.ca>
>>>>
>>>> ioremap_bat() is useful for things like mapping SoC internally memory
>>>> mapped
>>>> register and early text because it allows mappings to devices to be
>>>> setup
>>>> early in the boot process where they are needed, and the mappings
>>>> persist
>>>> after the MMU is configured.
>>>>
>>>> Without ioremap_bat(), setting up the MMU would cause the early text
>>>> mappings to get lost and mostly likely result in a kernel panic on the
>>>> next
>>>> attempt at output.
>>>>
>>>> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
>>>> ---
>>>
>>> why can't we just do this in ioremap itself?
>>
>> I suppose we could; but the usecase is somewhat different and I wanted
>> to keep it simple. Using a separate API also helps reenforce that the
>> caller really needs to know what they are doing because BATs are a
>> limited resource.
>
> there is a bunch of error checking and difference in semantics that you need
> to fix.
details please? I agree that it can be tightened up in some areas,
but I'd like to know if you've seen something I haven't.
> I think introduce a new API for this is silly,
I don't think so. I actually prefer it being an different API. It
forces the caller to understand what the function does. It forces the
programmer to think and to understand the effect of mapping large io
blocks.
> especially since we
> expect there to only be one actual invocation of the API for serial console
> access.
Actually, this is not only for early serial. Early serial just
happens to be the first user.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [RFC/PATCH 1/3] powerpc: add ioremap_bat() function for setting up BAT translated IO regions.
From: Grant Likely @ 2008-08-06 23:11 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, paulus, miltonm
In-Reply-To: <1218061585.24157.246.camel@pasglop>
On Wed, Aug 6, 2008 at 4:26 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Wed, 2008-08-06 at 00:02 -0600, Grant Likely wrote:
>> From: Grant Likely <grant.likely@secretlab.ca>
>>
>> ioremap_bat() is useful for things like mapping SoC internally memory mapped
>> register and early text because it allows mappings to devices to be setup
>> early in the boot process where they are needed, and the mappings persist
>> after the MMU is configured.
>>
>> Without ioremap_bat(), setting up the MMU would cause the early text
>> mappings to get lost and mostly likely result in a kernel panic on the next
>> attempt at output.
>>
>> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
>> ---
>
> First comment, make the name more generic. This facility could be
> implemented on processors without BATs using different techniques.
>
> Maybe ioremap_block() or ioremap_early() or something like that.
okay
>> diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
>> index 066e65c..7b25b57 100644
>> --- a/arch/powerpc/kernel/setup_32.c
>> +++ b/arch/powerpc/kernel/setup_32.c
>> @@ -113,6 +113,15 @@ notrace unsigned long __init early_init(unsigned long dt_ptr)
>> */
>> notrace void __init machine_init(unsigned long dt_ptr, unsigned long phys)
>> {
>> + /* Do the bare minimum to start allocting from the IO region so
>> + * that ioremap_bat() works */
>> +#ifdef CONFIG_HIGHMEM
>> + ioremap_base = PKMAP_BASE;
>> +#else
>> + ioremap_base = 0xfe000000UL; /* for now, could be 0xfffff000 */
>> +#endif /* CONFIG_HIGHMEM */
>> + ioremap_bot = ioremap_base;
>> +
>
> Can't these be statically initialized ? If not, then do a function call
> to mm/ please. Something like mm_init_early().
heh, I had just moved this code block without thinking about it. I'll
investigate and see what I can do.
>> + /* BAT mappings must be 128k aligned */
>> + if (addr != _ALIGN_DOWN(addr, 128 << 10))
>> + return NULL;
>
> Mustn't they be naturally aligned on their size ?
I'm not sure what you're asking. Are you asking about this particular
test, or are you asking why I don't also test the size?
I do this particular test to make absolute sure that the caller
absolutely understands the limitations of the block mapping. If they
call this with something that isn't 128k aligned, then I make it fail
immediately so the coder is forced to go and understand what they are
allowed to do. Basically, I'm reinforcing the fact that this is not
the same as ioremap().
I haven't decided yet if I should test size in the same way. Thoughts?
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [RFC/PATCH 1/3] powerpc: add ioremap_bat() function for setting up BAT translated IO regions.
From: Grant Likely @ 2008-08-06 23:11 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, paulus, miltonm
In-Reply-To: <1218061709.24157.249.camel@pasglop>
On Wed, Aug 6, 2008 at 4:28 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
>
>> there is a bunch of error checking and difference in semantics that
>> you need to fix. I think introduce a new API for this is silly,
>> especially since we expect there to only be one actual invocation of
>> the API for serial console access.
>
> Not necessarily....
>
> There's another aspect to BAT mappings here. First, they should be
> permanent (ie, not unmappable). That way, we have ioremap just use
> an existing BAT mapping when asked for a device that is covered
> by a BAT. This allows to have platform code do something like setup
> a BAT over a bunch of SOC registers or over a device, to automagically
> get drivers doing ioremap to that area benefit from it.
Actually, that is exactly what I am in the process of doing right now
for all the 5200 platforms. It is a performance win with no apparent
downside.
Next I want to investigate if it makes sense to do it for PCI IO regions.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [RFC PATCH] Link the bootwrapper as a position-independent executable
From: Paul Mackerras @ 2008-08-06 23:37 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <A1BAD7C8-8459-4D6E-80BA-639D305611DD@kernel.crashing.org>
Segher Boessenkool writes:
> Hurray! Looks good, just a few nits...
Thanks for reviewing.
> > + bl .+4
> > +p_base: mflr r10 /* r10 now points to runtime addr of p_base */
>
> bl p_base instead?
I went back and forth on that. I ended up with it that way to
emphasize that the bl does need to branch to the *next* instruction
for the idiom to work.
> > +10: or. r8,r0,r9 /* skip relocation if we don't have both */
> > beq 3f
>
> Either the code or the comment is wrong -- the code says "skip
> relocation
> if we don't have either".
Ah, operator precedence rules in English. :) I (and I think most
native English speakers) would parse my comment as "don't (have both)"
whereas I think you parsed it as "(don't have) both". Similarly what
you say the code says parses as "don't (have either)" for me rather
than "(don't have) either". IOW, "don't have either" means "both are
missing".
Anyway I can change the comment to say "we need both to do
relocation". OK?
> > + cmpwi r0,22 /* R_PPC_RELATIVE */
> > + bne 3f
>
> It would be nice if there was some way to complain (at build time?)
> if there are unhandled relocations present. Prevents a lot of headaches
> when things go wrong (and they will ;-) )
Yes, that would be a good idea. There is one extra relocation when I
build for pSeries, which was for _platform_stack_top (which is
undefined), which we're OK ignoring.
> > 4: dcbf r0,r9
> > icbi r0,r9
>
> Fix these while you're at it? It's not r0, it's 0.
Yeah.
> > + .dynsym : { *(.dynsym) }
> > + .dynstr : { *(.dynstr) }
> > + .dynamic :
> > + {
> > + __dynamic_start = .;
> > + *(.dynamic)
> > + }
> > + .hash : { *(.hash) }
> > + .interp : { *(.interp) }
> > + .rela.dyn : { *(.rela*) }
>
> Do some of these sections need alignment?
I suppose they should ideally be 4-byte aligned. We don't actually
use .dynsym, .dynstr, .hash or .interp, but I couldn't find any way to
make the linker omit them.
Paul.
^ permalink raw reply
* Re: [RFC/PATCH 1/3] powerpc: add ioremap_bat() function for setting up BAT translated IO regions.
From: Brad Boyer @ 2008-08-06 22:55 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, paulus, miltonm
In-Reply-To: <1218061709.24157.249.camel@pasglop>
On Thu, Aug 07, 2008 at 08:28:29AM +1000, Benjamin Herrenschmidt wrote:
>
> > there is a bunch of error checking and difference in semantics that
> > you need to fix. I think introduce a new API for this is silly,
> > especially since we expect there to only be one actual invocation of
> > the API for serial console access.
>
> Not necessarily....
>
> There's another aspect to BAT mappings here. First, they should be
> permanent (ie, not unmappable). That way, we have ioremap just use
> an existing BAT mapping when asked for a device that is covered
> by a BAT. This allows to have platform code do something like setup
> a BAT over a bunch of SOC registers or over a device, to automagically
> get drivers doing ioremap to that area benefit from it.
The m68k arch code does something similar with TT registers and ioremap,
but it's a little hackish currently. If there was a more generic way
to handle it, that would make things a little cleaner. In the m68k
implementation, there are just exceptions in the ioremap code that are
hard wired to know about the ranges that are normally set earlier. Since
the ranges end up being in multiple files, it's more fragile to change
what is mapped in these blocks.
Brad Boyer
flar@allandria.com
^ permalink raw reply
* Re: [PATCH]: Remove bogons from the iSeries console
From: Paul Mackerras @ 2008-08-06 23:43 UTC (permalink / raw)
To: Alan Cox; +Cc: boutcher, linuxppc-dev, torvalds, devilbis
In-Reply-To: <20080806140629.268fcf07@lxorguk.ukuu.org.uk>
Alan Cox writes:
> --- a/drivers/char/viocons.c
> +++ b/drivers/char/viocons.c
> @@ -705,10 +705,6 @@ static int viotty_ioctl(struct tty_struct *tty, struct file *file,
> case KDSKBLED:
> return 0;
> }
> - /* FIXME: WTF is this being called for ??? */
> - lock_kernel();
> - ret = n_tty_ioctl(tty, file, cmd, arg);
> - unlock_kernel();
> return ret;
> }
I think you want "return -ENOIOCTLCMD" rather than "return ret" since
ret is uninitialized with your patch applied. I agree the call to
n_tty_ioctl is bogus but I think we just want to return -ENOIOCTLCMD.
Paul.
^ permalink raw reply
* Re: [PATCH]: Remove bogons from the iSeries console
From: Alan Cox @ 2008-08-06 23:35 UTC (permalink / raw)
To: Paul Mackerras; +Cc: boutcher, linuxppc-dev, torvalds, devilbis
In-Reply-To: <18586.14112.751080.325656@cargo.ozlabs.ibm.com>
On Thu, 7 Aug 2008 09:43:28 +1000
Paul Mackerras <paulus@samba.org> wrote:
> Alan Cox writes:
>
> > --- a/drivers/char/viocons.c
> > +++ b/drivers/char/viocons.c
> > @@ -705,10 +705,6 @@ static int viotty_ioctl(struct tty_struct *tty, struct file *file,
> > case KDSKBLED:
> > return 0;
> > }
> > - /* FIXME: WTF is this being called for ??? */
> > - lock_kernel();
> > - ret = n_tty_ioctl(tty, file, cmd, arg);
> > - unlock_kernel();
> > return ret;
> > }
>
> I think you want "return -ENOIOCTLCMD" rather than "return ret" since
> ret is uninitialized with your patch applied. I agree the call to
> n_tty_ioctl is bogus but I think we just want to return -ENOIOCTLCMD.
Agreed
^ permalink raw reply
* [PATCH] of/powerpc: remove include of linux/of_platform.h from asm/of_platform.h
From: Stephen Rothwell @ 2008-08-07 0:30 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Now that we have removed all inclusions of asm/of_platform.h, this
compatibility include can be removed.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/include/asm/of_platform.h | 3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/of_platform.h b/arch/powerpc/include/asm/of_platform.h
index 18659ef..53b4650 100644
--- a/arch/powerpc/include/asm/of_platform.h
+++ b/arch/powerpc/include/asm/of_platform.h
@@ -11,9 +11,6 @@
*
*/
-/* This is just here during the transition */
-#include <linux/of_platform.h>
-
/* Platform drivers register/unregister */
static inline int of_register_platform_driver(struct of_platform_driver *drv)
{
--
1.5.6.3
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
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