* Re: Legacy ISA registers/interrupts in PCI device tree node
From: Segher Boessenkool @ 2007-07-16 15:05 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev
In-Reply-To: <20070716132902.118450@gmx.net>
>>> I wonder, if there is a recommended way to specify ISA register
>>> addresses and interrupts for a PCI device (unlike for a PCI2ISA
>>> bridge)?
>>
>> The PCI binding describes the required way to do this.
> Hmm, I must reread the PCI binding spec. It didn't seem to contain any
> information about this.
You can describe address regions in "reg" that aren't
corresponding to any PCI BAR. There is also a facility
to describe subtractive decoding (though I don't think
you need this).
>> Yes, it should, even if you don't use this in the Linux
>> kernel yet.
> Well, I still have to wire up the IDE interrupts in the platform setup
> code, right?
Sure, if you want those interrupts to work, anyway ;-)
Segher
^ permalink raw reply
* Re: [patch 3/6] Add 8548 CDS PCI express controller node and PCI-X device node
From: Segher Boessenkool @ 2007-07-16 15:00 UTC (permalink / raw)
To: Kumar Gala; +Cc: Paul Mackerras, linuxppc-dev list
In-Reply-To: <3F1CA06C-23E3-44EC-8A6E-E16BF690F664@kernel.crashing.org>
>>>> is this the only fix, I've already applied a version of this to my
>>>> tree (with the irq sense fix) and just want to make sure there
>>>> isn't
>>>> anything else.
>>> I do not get more.
>>> I'd like to enroll Segher's suggestion together with VIA chip
>>> function
>>> in next step.
>>> We need to make basic pcie work on 8548 CDS board first.
>>
>> If you can, please make the "compatible" properties correct
>> ("pcie" instead of "pciex") before the patch goes in; it'll
>> be less work total and less confusing in the end.
>
> I've taken care of that as well.
>
> They are now 'fsl,mpc8548-pcie, and 'fsl,mpc8641-pcie'
Perfect, thanks!
Segher
^ permalink raw reply
* Re: [patch 5/6] ps3: BD/DVD/CD-ROM Storage Driver
From: Geert Uytterhoeven @ 2007-07-16 14:59 UTC (permalink / raw)
To: Jens Axboe
Cc: James Bottomley, Arnd Bergmann, linux-scsi,
Linux Kernel Development, Alessandro Rubini,
Linux/PPC Development, Paul Mackerras
In-Reply-To: <20070716143852.GW5195@kernel.dk>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2132 bytes --]
On Mon, 16 Jul 2007, Jens Axboe wrote:
> On Mon, Jul 16 2007, James Bottomley wrote:
> > On Mon, 2007-07-16 at 14:16 +0200, Jens Axboe wrote:
> > > On Mon, Jul 16 2007, Geert Uytterhoeven wrote:
> > > > On Fri, 13 Jul 2007, Geert Uytterhoeven wrote:
> > > > > Ah, that explains it. flush_dcache_page() is used in some drivers.
> > > > > I'll update my patches. Thanks for the comments!
> > > >
> > > > Does this look OK?
> > > > - Replaced KM_USER0 by KM_IRQ0 (all routines are either called from an
> > > > interrupt handler, from .request_fn (ps3disk), or from .queuecommand
> > > > (ps3rom))
> > >
> > > That looks good.
> > >
> > > > - Add a call to flush_kernel_dcache_page() in routines that write to buffers
> > >
> > > Hmm, I would have thought a flush_dcache_page() would be more
> > > appropriate, the backing could be page cache pages.
> >
> > No ... that was the point of flush_kernel_dcache_page(). The page in
> > question is page cache backed and contains user mappings. However, the
> > block layer has already done a flush_dcache_page() in get_user_pages()
> > and the user shouldn't be touching memory under I/O (unless they want
> > self induced aliasing problems) so we're free to assume all the user
> > cachelines are purged, hence all we have to do is flush the kernel alias
> > to bring the page up to date and make the users see it correctly.
>
> Oh indeed, I missed the flush_dcache_page() in get_user_pages().
Good, thanks for reaching a consensus, so I can update my patch series.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: [PATCH 1/4] Add DMA sector to Documentation/powerpc/booting-without-of.txt file.
From: Segher Boessenkool @ 2007-07-16 14:56 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, paulus, Wei.Zhang
In-Reply-To: <46967C8C.9010602@freescale.com>
> It's not that bad in most respects, though unlike some, I don't
> think we need to stick dogmatically to the exact way that Open
> Firmware(tm) did everything.
s/did/does/
And for the record: neither do I.
Segher
^ permalink raw reply
* Re: [PATCH 1/4] Add DMA sector to Documentation/powerpc/booting-without-of.txt file.
From: Segher Boessenkool @ 2007-07-16 14:54 UTC (permalink / raw)
To: pterry; +Cc: linuxppc-dev, paulus, Wei.Zhang
In-Reply-To: <1184260375.24515.35.camel@pterry-fc6.micromemory.com>
> I thought the idea of the dts/of was for the hardware specific boot
> loader to tell the kernel about hardware that the kernel couldn't
> otherwise know about, because its not detectable by a bus probe
> method,
> etc. Its not there to tell you how to use the device or arbitrate
> which
> other devices get to use a device when there are resource conflicts,
> etc.
>
> If the dts/of/boot loader tells the kernel its a fsl soc then it knows
> how to work out which one and what level, and therefore knows what
> devices, such as the DMA device are present.
The device tree describes _all_ hardware in the system,
not just the things that are somewhat harder to probe
for. Kernel drivers are free to not use all info provided
in the device tree and just hardcode some (correct or
incorrect) implicit knowledge about the device in question.
Whether this is a good idea or not is a different thing.
> I'm truly interested in understanding the correct interpretation
> because
> we are developing a DMA based, rapidio distributed system on fsl 8641
> and from lurking on here and reading the archives etc, all I see is a
> constant butting of heads on what the dts/of is and how its
> supposed to
> work.
Really, most of what you see is developing bindings for
specific devices, which takes a lot of discussion since
it needs to be made future-proof.
> Quite why we are using a 20 year old spec, which was never
> finished, and
> ceased to be a formal spec 10 years ago as the "new" way forward is a
> puzzle to me as well.
You have some misconceptions about Open Firmware I'm afraid.
> Not flame bait,
Good, let's drop this then :-)
> but if someone could point me to
> background material it would be helpful for my education in getting up
> to speed (on the rationale for using it going forwards, not all the
> old
> sites for the spec itself).
I'm afraid you'll have to get some experience using the OF
device tree to truly appreciate its power and flexibility,
and how many problems it solves. Yeah this is a pretty weak
answer.
Segher
^ permalink raw reply
* Re: [patch 5/6] ps3: BD/DVD/CD-ROM Storage Driver
From: Jens Axboe @ 2007-07-16 14:38 UTC (permalink / raw)
To: James Bottomley
Cc: Arnd Bergmann, linux-scsi, Linux Kernel Development,
Alessandro Rubini, Linux/PPC Development, Paul Mackerras,
Geert Uytterhoeven
In-Reply-To: <1184593643.3447.9.camel@localhost.localdomain>
On Mon, Jul 16 2007, James Bottomley wrote:
> On Mon, 2007-07-16 at 14:16 +0200, Jens Axboe wrote:
> > On Mon, Jul 16 2007, Geert Uytterhoeven wrote:
> > > On Fri, 13 Jul 2007, Geert Uytterhoeven wrote:
> > > > Ah, that explains it. flush_dcache_page() is used in some drivers.
> > > > I'll update my patches. Thanks for the comments!
> > >
> > > Does this look OK?
> > > - Replaced KM_USER0 by KM_IRQ0 (all routines are either called from an
> > > interrupt handler, from .request_fn (ps3disk), or from .queuecommand
> > > (ps3rom))
> >
> > That looks good.
> >
> > > - Add a call to flush_kernel_dcache_page() in routines that write to buffers
> >
> > Hmm, I would have thought a flush_dcache_page() would be more
> > appropriate, the backing could be page cache pages.
>
> No ... that was the point of flush_kernel_dcache_page(). The page in
> question is page cache backed and contains user mappings. However, the
> block layer has already done a flush_dcache_page() in get_user_pages()
> and the user shouldn't be touching memory under I/O (unless they want
> self induced aliasing problems) so we're free to assume all the user
> cachelines are purged, hence all we have to do is flush the kernel alias
> to bring the page up to date and make the users see it correctly.
Oh indeed, I missed the flush_dcache_page() in get_user_pages().
--
Jens Axboe
^ permalink raw reply
* Re: [RFC][PATCH 6/8] Walnut DTS
From: Segher Boessenkool @ 2007-07-16 14:34 UTC (permalink / raw)
To: Yoder Stuart-B08248; +Cc: linuxppc-dev
In-Reply-To: <9696D7A991D0824DBA8DFAC74A9C5FA3030669AF@az33exm25.fsl.freescale.net>
>>> + #address-cells = <0>;
>>> + #size-cells = <0>;
>>
>> No need for these.
>
> Isn't a good practice to put #address-cells in interrupt controller
> nodes?
It is not.
> If the device tree has an interrupt map defined the interrupt
> parent 'unit interrupt specifier' has to be interpreted according
> to the #address-cells of the interrupt parent.
And "#address-cells" is defaulted to 0 if it is absent,
for the purpose of interrupt mapping (but not for its
other purposes). Typically, such interrupt controllers
don't have device tree children so it doesn't make sense
to give them an "#address-cells" anyway.
> It seems like
> typical practice in the current DTS files to explicitly define this
> in the interrupt controller.
That "typical practice" is inspired by the need to explicitly
put #address-cells and #size-cells into the device tree if you
want Linux to properly parse the device tree, even if the default
values would work perfectly (if Linux would work correctly,
that is).
> Of course this particular device tree doesn't have an interrupt
> map...
>
> #size-cells is not needed.
There are no child nodes, and no binding that says there can
be any; neither #address-cells not #size-cells should be there.
Segher
^ permalink raw reply
* Re: [patch 3/6] Add 8548 CDS PCI express controller node and PCI-X device node
From: Kumar Gala @ 2007-07-16 14:29 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Paul Mackerras, linuxppc-dev list
In-Reply-To: <68D5EA7E-30DF-4856-8526-BABEFE230C05@kernel.crashing.org>
On Jul 16, 2007, at 8:05 AM, Segher Boessenkool wrote:
>>> is this the only fix, I've already applied a version of this to my
>>> tree (with the irq sense fix) and just want to make sure there isn't
>>> anything else.
>> I do not get more.
>> I'd like to enroll Segher's suggestion together with VIA chip
>> function
>> in next step.
>> We need to make basic pcie work on 8548 CDS board first.
>
> If you can, please make the "compatible" properties correct
> ("pcie" instead of "pciex") before the patch goes in; it'll
> be less work total and less confusing in the end.
I've taken care of that as well.
They are now 'fsl,mpc8548-pcie, and 'fsl,mpc8641-pcie'
- k
^ permalink raw reply
* Kmalloc returns which address
From: suresh suresh @ 2007-07-16 13:59 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 451 bytes --]
Hi,
I am porting MPC8280 driver from vxWorks to Linux.
I want know the address return by kmalloc function? is it physical address
or kernel virtual address.
For Tx and Rx, hardware uses buffers, so I have to allocate buffers and pass
the pointer to hardware. Can I pass the pointer returned kmalloc? or I
should convert it into physical address?
If it returns kernel virtual address, then how to convert into physical?
Thanks & Regards-
Suresh
[-- Attachment #2: Type: text/html, Size: 514 bytes --]
^ permalink raw reply
* Re: [patch 5/6] ps3: BD/DVD/CD-ROM Storage Driver
From: James Bottomley @ 2007-07-16 13:47 UTC (permalink / raw)
To: Jens Axboe
Cc: Arnd Bergmann, linux-scsi, Linux Kernel Development,
Alessandro Rubini, Linux/PPC Development, Paul Mackerras,
Geert Uytterhoeven
In-Reply-To: <20070716121649.GI5195@kernel.dk>
On Mon, 2007-07-16 at 14:16 +0200, Jens Axboe wrote:
> On Mon, Jul 16 2007, Geert Uytterhoeven wrote:
> > On Fri, 13 Jul 2007, Geert Uytterhoeven wrote:
> > > Ah, that explains it. flush_dcache_page() is used in some drivers.
> > > I'll update my patches. Thanks for the comments!
> >
> > Does this look OK?
> > - Replaced KM_USER0 by KM_IRQ0 (all routines are either called from an
> > interrupt handler, from .request_fn (ps3disk), or from .queuecommand
> > (ps3rom))
>
> That looks good.
>
> > - Add a call to flush_kernel_dcache_page() in routines that write to buffers
>
> Hmm, I would have thought a flush_dcache_page() would be more
> appropriate, the backing could be page cache pages.
No ... that was the point of flush_kernel_dcache_page(). The page in
question is page cache backed and contains user mappings. However, the
block layer has already done a flush_dcache_page() in get_user_pages()
and the user shouldn't be touching memory under I/O (unless they want
self induced aliasing problems) so we're free to assume all the user
cachelines are purged, hence all we have to do is flush the kernel alias
to bring the page up to date and make the users see it correctly.
James
^ permalink raw reply
* Re: [patch 5/6] ps3: BD/DVD/CD-ROM Storage Driver
From: Jens Axboe @ 2007-07-16 13:33 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: James Bottomley, Arnd Bergmann, linux-scsi,
Linux Kernel Development, Alessandro Rubini,
Linux/PPC Development, Paul Mackerras
In-Reply-To: <Pine.LNX.4.62.0707161515460.1072@pademelon.sonytel.be>
On Mon, Jul 16 2007, Geert Uytterhoeven wrote:
> On Mon, 16 Jul 2007, Geert Uytterhoeven wrote:
> > On Mon, 16 Jul 2007, Jens Axboe wrote:
> > > On Mon, Jul 16 2007, Geert Uytterhoeven wrote:
> > > > On Fri, 13 Jul 2007, Geert Uytterhoeven wrote:
> > > > > Ah, that explains it. flush_dcache_page() is used in some drivers.
> > > > > I'll update my patches. Thanks for the comments!
> > > >
> > > > Does this look OK?
> > > > - Replaced KM_USER0 by KM_IRQ0 (all routines are either called from an
> > > > interrupt handler, from .request_fn (ps3disk), or from .queuecommand
> > > > (ps3rom))
> > >
> > > That looks good.
> > >
> > > > - Add a call to flush_kernel_dcache_page() in routines that write to buffers
> > >
> > > Hmm, I would have thought a flush_dcache_page() would be more
> > > appropriate, the backing could be page cache pages.
> >
> > OK, I'll change it to flush_dcache_page().
>
> Upon closer look, while flush_kernel_dcache_page() is a no-op on ppc64,
> flush_dcache_page() isn't. So I'd prefer to not call it if not really needed.
>
> And according to James, flush_kernel_dcache_page() should be sufficient...
>
> So I'm getting puzzled again...
I'll let James expand on why he thinks flush_kernel_dcache_page() should
be sufficient. If the backing is always user memory from
get_user_pages(), then the flush_kernel_dcache_page() looks sufficient.
For the normal IO paths, it could be that or page cache pages too for
instance.
--
Jens Axboe
^ permalink raw reply
* Re: Legacy ISA registers/interrupts in PCI device tree node
From: Gerhard Pircher @ 2007-07-16 13:29 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <D0634B84-BD83-460E-AEC2-E8BB2837B237@kernel.crashing.org>
-------- Original-Nachricht --------
Datum: Mon, 16 Jul 2007 14:40:48 +0200
Von: Segher Boessenkool <segher@kernel.crashing.org>
An: Gerhard Pircher <gerhard_pircher@gmx.net>
CC: linuxppc-dev@ozlabs.org
Betreff: Re: Legacy ISA registers/interrupts in PCI device tree node
> > I wonder, if there is a recommended way to specify ISA register
> > addresses and interrupts for a PCI device (unlike for a PCI2ISA
> > bridge)?
>
> The PCI binding describes the required way to do this.
Hmm, I must reread the PCI binding spec. It didn't seem to contain any
information about this.
> Yes, it should, even if you don't use this in the Linux
> kernel yet.
Well, I still have to wire up the IDE interrupts in the platform setup
code, right?
Gerhard
--
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
^ permalink raw reply
* Re: [patch 5/6] ps3: BD/DVD/CD-ROM Storage Driver
From: Geert Uytterhoeven @ 2007-07-16 13:24 UTC (permalink / raw)
To: Jens Axboe
Cc: James Bottomley, Arnd Bergmann, linux-scsi,
Linux Kernel Development, Alessandro Rubini,
Linux/PPC Development, Paul Mackerras
In-Reply-To: <Pine.LNX.4.62.0707161459010.1072@pademelon.sonytel.be>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1687 bytes --]
On Mon, 16 Jul 2007, Geert Uytterhoeven wrote:
> On Mon, 16 Jul 2007, Jens Axboe wrote:
> > On Mon, Jul 16 2007, Geert Uytterhoeven wrote:
> > > On Fri, 13 Jul 2007, Geert Uytterhoeven wrote:
> > > > Ah, that explains it. flush_dcache_page() is used in some drivers.
> > > > I'll update my patches. Thanks for the comments!
> > >
> > > Does this look OK?
> > > - Replaced KM_USER0 by KM_IRQ0 (all routines are either called from an
> > > interrupt handler, from .request_fn (ps3disk), or from .queuecommand
> > > (ps3rom))
> >
> > That looks good.
> >
> > > - Add a call to flush_kernel_dcache_page() in routines that write to buffers
> >
> > Hmm, I would have thought a flush_dcache_page() would be more
> > appropriate, the backing could be page cache pages.
>
> OK, I'll change it to flush_dcache_page().
Upon closer look, while flush_kernel_dcache_page() is a no-op on ppc64,
flush_dcache_page() isn't. So I'd prefer to not call it if not really needed.
And according to James, flush_kernel_dcache_page() should be sufficient...
So I'm getting puzzled again...
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: [patch 3/6] Add 8548 CDS PCI express controller node and PCI-X device node
From: Segher Boessenkool @ 2007-07-16 13:05 UTC (permalink / raw)
To: Zang Roy-r61911; +Cc: linuxppc-dev list, Paul Mackerras
In-Reply-To: <1184240183.28074.113.camel@localhost.localdomain>
>> is this the only fix, I've already applied a version of this to my
>> tree (with the irq sense fix) and just want to make sure there isn't
>> anything else.
> I do not get more.
> I'd like to enroll Segher's suggestion together with VIA chip function
> in next step.
> We need to make basic pcie work on 8548 CDS board first.
If you can, please make the "compatible" properties correct
("pcie" instead of "pciex") before the patch goes in; it'll
be less work total and less confusing in the end.
Segher
^ permalink raw reply
* Re: [patch 5/6] ps3: BD/DVD/CD-ROM Storage Driver
From: Jens Axboe @ 2007-07-16 13:04 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: James Bottomley, Arnd Bergmann, linux-scsi,
Linux Kernel Development, Alessandro Rubini,
Linux/PPC Development, Paul Mackerras
In-Reply-To: <Pine.LNX.4.62.0707161459010.1072@pademelon.sonytel.be>
On Mon, Jul 16 2007, Geert Uytterhoeven wrote:
> On Mon, 16 Jul 2007, Jens Axboe wrote:
> > On Mon, Jul 16 2007, Geert Uytterhoeven wrote:
> > > On Fri, 13 Jul 2007, Geert Uytterhoeven wrote:
> > > > Ah, that explains it. flush_dcache_page() is used in some drivers.
> > > > I'll update my patches. Thanks for the comments!
> > >
> > > Does this look OK?
> > > - Replaced KM_USER0 by KM_IRQ0 (all routines are either called from an
> > > interrupt handler, from .request_fn (ps3disk), or from .queuecommand
> > > (ps3rom))
> >
> > That looks good.
> >
> > > - Add a call to flush_kernel_dcache_page() in routines that write to buffers
> >
> > Hmm, I would have thought a flush_dcache_page() would be more
> > appropriate, the backing could be page cache pages.
>
> OK, I'll change it to flush_dcache_page().
Then you may add my acked-by as well, if you want.
--
Jens Axboe
^ permalink raw reply
* Re: possible dead CONFIG-related content under arch/powerpc
From: Michael Ellerman @ 2007-07-16 13:05 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Linux PPC Mailing List, Robert P. J. Day
In-Reply-To: <Pine.LNX.4.62.0707161116280.1072@pademelon.sonytel.be>
[-- Attachment #1: Type: text/plain, Size: 605 bytes --]
On Mon, 2007-07-16 at 11:16 +0200, Geert Uytterhoeven wrote:
> On Sat, 14 Jul 2007, Robert P. J. Day wrote:
> > ========== SPE_BASE ==========
> > arch/powerpc/mm/hash_utils_64.c:612:#ifdef CONFIG_SPE_BASE
> > arch/powerpc/mm/hash_utils_64.c:747:#ifdef CONFIG_SPE_BASE
>
> Interesting, should this one be CONFIG_SPU_BASE?
Yes, ouch.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [patch 5/6] ps3: BD/DVD/CD-ROM Storage Driver
From: Geert Uytterhoeven @ 2007-07-16 12:59 UTC (permalink / raw)
To: Jens Axboe
Cc: James Bottomley, Arnd Bergmann, linux-scsi,
Linux Kernel Development, Alessandro Rubini,
Linux/PPC Development, Paul Mackerras
In-Reply-To: <20070716121649.GI5195@kernel.dk>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1342 bytes --]
On Mon, 16 Jul 2007, Jens Axboe wrote:
> On Mon, Jul 16 2007, Geert Uytterhoeven wrote:
> > On Fri, 13 Jul 2007, Geert Uytterhoeven wrote:
> > > Ah, that explains it. flush_dcache_page() is used in some drivers.
> > > I'll update my patches. Thanks for the comments!
> >
> > Does this look OK?
> > - Replaced KM_USER0 by KM_IRQ0 (all routines are either called from an
> > interrupt handler, from .request_fn (ps3disk), or from .queuecommand
> > (ps3rom))
>
> That looks good.
>
> > - Add a call to flush_kernel_dcache_page() in routines that write to buffers
>
> Hmm, I would have thought a flush_dcache_page() would be more
> appropriate, the backing could be page cache pages.
OK, I'll change it to flush_dcache_page().
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: [PATCH v2] Allow exec on 32-bit from readable, non-exec pages, with a warning.
From: Segher Boessenkool @ 2007-07-16 12:55 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <D575BC2B-0554-4290-A6D0-D4FEEE691C11@kernel.crashing.org>
>>>> Actually I see no good reason to enforce no-exec at all if we
>>>> can't do
>>>> it consistently. And if we're not going to enforce it then
>>>> there is
>>>> no point whinging about it.
>>>
>>>
>>> I have a new patch with just this behaviour, Scott is
>>> testing it on old glibc (I think it succeeded, need
>>> confirmation though),
>>
>> It worked fine on glibc 2.2.5 and 2.3.3 (the former of which failed
>> without the patch).
>
> It sounds like this is a candidate for stable 2.6.22.x as well
Yes, it replaces the previous patch and is a bugfix to it.
> once you release the patch.
The only reason I didn't send it out immediately was to not
confuse things further with a broken patch ;-)
Segher
^ permalink raw reply
* Re: Legacy ISA registers/interrupts in PCI device tree node
From: Segher Boessenkool @ 2007-07-16 12:40 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev
In-Reply-To: <20070716075317.15260@gmx.net>
> I wonder, if there is a recommended way to specify ISA register
> addresses
> and interrupts for a PCI device (unlike for a PCI2ISA bridge)?
The PCI binding describes the required way to do this.
> The device in question is the integrated IDE controller of the VIA686B
> southbridge, which works in compatible/legacy mode and thus uses
> interrupts
> 14 and 15 of the i8259 PIC. Should the fdt contain this information
Yes, it should, even if you don't use this in the Linux
kernel yet.
> or should I hardcode the values in the platform setup code?
No.
Segher
^ permalink raw reply
* Re: [patch 5/6] ps3: BD/DVD/CD-ROM Storage Driver
From: Jens Axboe @ 2007-07-16 12:16 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: James Bottomley, Arnd Bergmann, linux-scsi,
Linux Kernel Development, Alessandro Rubini,
Linux/PPC Development, Paul Mackerras
In-Reply-To: <Pine.LNX.4.62.0707161338230.1072@pademelon.sonytel.be>
On Mon, Jul 16 2007, Geert Uytterhoeven wrote:
> On Fri, 13 Jul 2007, Geert Uytterhoeven wrote:
> > Ah, that explains it. flush_dcache_page() is used in some drivers.
> > I'll update my patches. Thanks for the comments!
>
> Does this look OK?
> - Replaced KM_USER0 by KM_IRQ0 (all routines are either called from an
> interrupt handler, from .request_fn (ps3disk), or from .queuecommand
> (ps3rom))
That looks good.
> - Add a call to flush_kernel_dcache_page() in routines that write to buffers
Hmm, I would have thought a flush_dcache_page() would be more
appropriate, the backing could be page cache pages.
--
Jens Axboe
^ permalink raw reply
* Re: [patch 5/6] ps3: BD/DVD/CD-ROM Storage Driver
From: Segher Boessenkool @ 2007-07-16 12:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: James Bottomley, Arnd Bergmann, linux-scsi, linux-kernel,
Alessandro Rubini, linuxppc-dev, Paul Mackerras, Jens Axboe,
Geert Uytterhoeven
In-Reply-To: <1184368328.6059.271.camel@localhost.localdomain>
>> I'm pretty sure that no ppc64 machine needs alias resolution in
>> the kernel,
>> although some are VIPT. Last time we discussed this, Segher
>> explained it
>> to me, but I don't remember which way Cell does it. IIRC, it
>> automatically
>> flushes cache lines that are accessed through aliases.
>
> Ah yes, I remember reading about this automatic flushing thing. I
> don't
> know how the caches actually work on most of our PPC's, but the
> fact is,
> we don't have aliasing issues, so I can safely ignore it for a bit
> longer :-)
That is the very short version of the story, yes: some
PowerPC implementations are VIPT physically, but there
are no aliasing issues we have to worry about.
Anyone interested in how this works, can download the
PPC970 UM (or 970FX or 970MP); it has a very detailed
explanation of all this. Cell might be slightly different
but the base idea is the same.
Segher
^ permalink raw reply
* Re: [patch 5/6] ps3: BD/DVD/CD-ROM Storage Driver
From: Geert Uytterhoeven @ 2007-07-16 11:43 UTC (permalink / raw)
To: James Bottomley, Jens Axboe
Cc: Arnd Bergmann, linux-scsi, Linux Kernel Development,
Alessandro Rubini, Linux/PPC Development, Paul Mackerras
In-Reply-To: <Pine.LNX.4.62.0707132212520.23000@chinchilla.sonytel.be>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3186 bytes --]
On Fri, 13 Jul 2007, Geert Uytterhoeven wrote:
> Ah, that explains it. flush_dcache_page() is used in some drivers.
> I'll update my patches. Thanks for the comments!
Does this look OK?
- Replaced KM_USER0 by KM_IRQ0 (all routines are either called from an
interrupt handler, from .request_fn (ps3disk), or from .queuecommand
(ps3rom))
- Add a call to flush_kernel_dcache_page() in routines that write to buffers
If this is OK, I'll fold it into my original patch series and will resend.
Thanks!
---
drivers/block/ps3disk.c | 5 +++--
drivers/scsi/ps3rom.c | 9 +++++----
2 files changed, 8 insertions(+), 6 deletions(-)
--- a/drivers/block/ps3disk.c
+++ b/drivers/block/ps3disk.c
@@ -109,13 +109,14 @@ static void ps3disk_scatter_gather(struc
bio_sectors(bio), sector);
bio_for_each_segment(bvec, bio, j) {
size = bio_cur_sectors(bio)*KERNEL_SECTOR_SIZE;
- buf = __bio_kmap_atomic(bio, j, KM_USER0);
+ buf = __bio_kmap_atomic(bio, j, KM_IRQ0);
if (gather)
memcpy(dev->bounce_buf+offset, buf, size);
else
memcpy(buf, dev->bounce_buf+offset, size);
offset += size;
- __bio_kunmap_atomic(bio, KM_USER0);
+ flush_kernel_dcache_page(bio_iovec_idx(bio, j)->bv_page);
+ __bio_kunmap_atomic(bio, KM_IRQ0);
}
sectors += bio_sectors(bio);
i++;
--- a/drivers/scsi/ps3rom.c
+++ b/drivers/scsi/ps3rom.c
@@ -112,7 +112,7 @@ static int fill_from_dev_buffer(struct s
active = 1;
for (k = 0, req_len = 0, act_len = 0; k < cmd->use_sg; ++k, ++sgpnt) {
if (active) {
- kaddr = kmap_atomic(sgpnt->page, KM_USER0);
+ kaddr = kmap_atomic(sgpnt->page, KM_IRQ0);
if (!kaddr)
return -1;
len = sgpnt->length;
@@ -121,7 +121,8 @@ static int fill_from_dev_buffer(struct s
len = buflen - req_len;
}
memcpy(kaddr + sgpnt->offset, buf + req_len, len);
- kunmap_atomic(kaddr, KM_USER0);
+ flush_kernel_dcache_page(sgpnt->page);
+ kunmap_atomic(kaddr, KM_IRQ0);
act_len += len;
}
req_len += sgpnt->length;
@@ -149,7 +150,7 @@ static int fetch_to_dev_buffer(struct sc
sgpnt = cmd->request_buffer;
for (k = 0, req_len = 0, fin = 0; k < cmd->use_sg; ++k, ++sgpnt) {
- kaddr = kmap_atomic(sgpnt->page, KM_USER0);
+ kaddr = kmap_atomic(sgpnt->page, KM_IRQ0);
if (!kaddr)
return -1;
len = sgpnt->length;
@@ -158,7 +159,7 @@ static int fetch_to_dev_buffer(struct sc
fin = 1;
}
memcpy(buf + req_len, kaddr + sgpnt->offset, len);
- kunmap_atomic(kaddr, KM_USER0);
+ kunmap_atomic(kaddr, KM_IRQ0);
if (fin)
return req_len + len;
req_len += sgpnt->length;
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* WDT with 82xx
From: Matvejchikov Ilya @ 2007-07-16 11:15 UTC (permalink / raw)
To: linuxppc-embedded
Hi all!
Does anybody use watchdog timer with mpc82xx?
^ permalink raw reply
* Re: [patch] use __attribute__ in asm-powerpc
From: Andreas Schwab @ 2007-07-16 9:30 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linuxppc-dev, Mike Frysinger, linux-kernel, paulus
In-Reply-To: <Pine.LNX.4.62.0707161117150.1072@pademelon.sonytel.be>
Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> writes:
> If the code is not exported to userspace (and thus not subject to different
> compilers), I think the preferred form is plain `attribute'.
That does not exist without underscores.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [patch] use __attribute__ in asm-powerpc
From: Robert P. J. Day @ 2007-07-16 9:20 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: paulus, Mike Frysinger, linux-kernel, linuxppc-dev
In-Reply-To: <Pine.LNX.4.62.0707161117150.1072@pademelon.sonytel.be>
On Mon, 16 Jul 2007, Geert Uytterhoeven wrote:
> On Sat, 14 Jul 2007, Mike Frysinger wrote:
> > Pretty much everyone uses "__attribute__" or "attribute", no one
> > uses "__attribute". This patch tweaks the three places in asm-powerpc where
> > this comes up. While only asm-powerpc/types.h is interesting (for userspace),
> > I did asm-powerpc/processor.h as well for consistency.
> >
> > Signed-off-by: Mike Frysinger <vapier@gentoo.org>
> > ---
> > diff --git a/include/asm-powerpc/processor.h b/include/asm-powerpc/processor.h
> > index d947b16..2ce6ea6 100644
> > --- a/include/asm-powerpc/processor.h
> > +++ b/include/asm-powerpc/processor.h
> > @@ -153,9 +153,9 @@ struct thread_struct {
> > unsigned long dabr; /* Data address breakpoint register */
> > #ifdef CONFIG_ALTIVEC
> > /* Complete AltiVec register set */
> > - vector128 vr[32] __attribute((aligned(16)));
> > + vector128 vr[32] __attribute__((aligned(16)));
>
> If the code is not exported to userspace (and thus not subject to
> different compilers), I think the preferred form is plain
> `attribute'.
compiler-gcc.h also defines the common form of the shortcut:
#define __aligned(x) __attribute__((aligned(x)))
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================
^ 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