* Re: Linuxppc-embedded Digest, Vol 35, Issue 33
From: Scott Wood @ 2007-07-16 16:09 UTC (permalink / raw)
To: Siva Prasad; +Cc: sureshtang, linuxppc-embedded
In-Reply-To: <D83235F0F3C86D4D889D8B9A0DA8C6D78D7DE9@corpexc01.corp.networkrobots.com>
Siva Prasad wrote:
> It returns kernel virtual address. If you use this buffer space for DMA,
> please use appropriate flags. You may use __pa(address) or
> virt_to_phys() to convert virtual to physical.
No, you may not -- physical and DMA addresses are not always identical.
Use the DMA mapping API.
-Scott
^ permalink raw reply
* Re: [PATCH 01/10] IB/ehca: Support for multiple event queues
From: Roland Dreier @ 2007-07-16 16:04 UTC (permalink / raw)
To: Joachim Fenkes
Cc: LKML, LinuxPPC-Dev, Christoph Raisch, OF-General, Stefan Roscher
In-Reply-To: <200707121746.36763.fenkes@de.ibm.com>
> The eHCA driver can now handle multiple event queues (read: interrupt
> sources) instead of one. The number of available EQs is selected via the
> nr_eqs module parameter.
> CQs are either assigned to the EQs based on the comp_vector index or, if the
> dist_eqs module parameter is supplied, using a round-robin scheme.
Do you have any data on how well this round-robin assignment works?
It seems not quite right to me for the driver to advertise nr_eqs
completion vectors, but then if round-robin is turned on to ignore the
consumer's decision about which vector to use.
Maybe if round-robin is turned on you should report 0 as the number of
completion vectors? Or maybe we should allow well-known values for
the completion vector passed to ib_create_cq to allow consumers to
specify a policy (like round robin) instead of a particular vector?
Maybe the whole interface is broken and we should only be exposing
policies to consumers instead of the specific vector?
I think I would rather hold off on multiple EQs for this merge window
and plan on having something really solid and thought-out for 2.6.24.
- R.
^ permalink raw reply
* Gdbserver syscall clobber
From: Bill Gatliff @ 2007-07-16 15:43 UTC (permalink / raw)
To: gdb, linuxppc-embedded
Guys:
I'm trying to track down a problem where gdbserver is issuing a bogus
syscall at the onset of a debugging session. I'm using gdb-6.6, on an
(ancient, I know) linux-2.4.16 kernel, pc603e machine. Gcc-3.4.5,
glibc-2.2.5 (both built with crosstools-0.43). Gdbserver is statically
linked.
When I run gdbserver under strace on the target, I see these in the log
shortly after initiating the connection from my workstation:
...
ptrace(PTRACE_PEEKTEXT, 947, 0x10405394, [0x103e0cb0]) = 0
ptrace(PTRACE_PEEKTEXT, 947, 0x10405398, [0x103e0ce4]) = 0
ptrace(PTRACE_PEEKTEXT, 947, 0x1040539c, [0x103e0ce8]) = 0
send(4, "$103df2cc103df2e8103df2ec103df2f"..., 644, 0) = 644
recv(4, 0x7ffffd60, 1, 0) = ? ERESTARTSYS (To be restarted)
--- SIGIO (I/O possible) @ 0 (0) ---
syscall_4294966784(0xa, 0x7ffffd34, 0x1, 0, 0x1008a3c7, 0x1008b5a3,
0x1008b5a4, 0, 0x1, 0x80808080, 0x1008e778, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0x10080000, 0x10080000, 0x10080000, 0x1008b5a3, 0x10080000,
0x1008b320, 0x100291a4, 0xd032, 0xa) = -1 (errno 38)
write(2, "putpkt(read): Function not imple"..., 39) = 39
...
Note the bogus syscall argument 4294966784. It isn't *completely*
bogus, interestingly, since if you google for that you come up with a
few hits. But no resolutions.
I'm stumped. Does this problem sound familiar to anyone? Had the same
problem with gcc-2.95.3.
Kindest regards,
b.g.
--
Bill Gatliff
bgat@billgatliff.com
^ permalink raw reply
* RE: Linuxppc-embedded Digest, Vol 35, Issue 33
From: Siva Prasad @ 2007-07-16 15:58 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: sureshtang
In-Reply-To: <mailman.1061.1184600645.8639.linuxppc-embedded@ozlabs.org>
It returns kernel virtual address. If you use this buffer space for DMA,
please use appropriate flags. You may use __pa(address) or
virt_to_phys() to convert virtual to physical.
- Siva
-----Original Message-----
Message: 3
Date: Mon, 16 Jul 2007 19:29:59 +0530
From: "suresh suresh" <sureshtang@gmail.com>
Subject: Kmalloc returns which address
To: linuxppc-embedded@ozlabs.org
Message-ID:
<e5eb93010707160659m6a7d0b02p623542739d28ab29@mail.gmail.com>
Content-Type: text/plain; charset=3D"iso-8859-1"
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
-------------- next part --------------
^ permalink raw reply
* Re: Kmalloc returns which address
From: Scott Wood @ 2007-07-16 15:46 UTC (permalink / raw)
To: suresh suresh; +Cc: linuxppc-embedded
In-Reply-To: <e5eb93010707160659m6a7d0b02p623542739d28ab29@mail.gmail.com>
suresh suresh wrote:
> I want know the address return by kmalloc function? is it physical address
> or kernel virtual address.
Kernel virtual.
> 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?
You need to convert it; read Documentation/DMA-mapping.txt.
-Scott
^ permalink raw reply
* Re: ML410 PCI support
From: Grant Likely @ 2007-07-16 15:44 UTC (permalink / raw)
To: khollan; +Cc: linuxppc-embedded
In-Reply-To: <11620099.post@talk.nabble.com>
On 7/16/07, khollan <khollan@daktronics.com> wrote:
>
>
> khollan wrote:
> >
> > I have two questions:
> > 1) Has anyone wrote linux 2.6 PCI drviers for the xilinx development
> > boards. I want to get the PCI slots working on my board.
> > 2)How do I set the HwAddr for the TEMAC driver? Im using Grants latest
> > git tree. My board boots and the HwAddr is set to 00:00:00:00:00:00
> > Thanks for your help
> > Kevin
> >
>
> 1) Still waiting to see if someone knows how to go about doing this...
No, I don't think anyone has done proper PCI support. But you might
want to double check the MontaVista 2.4 tree.
> 2) Solved this by hardcoding it in the embed_config.c file
Which is probably the best way to do it if you're booting from a
zImage. If you're booting from u-boot or another bootloader, you can
pass the addr in the board info structure.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: hvc_iseries not working
From: Will Schmidt @ 2007-07-16 15:39 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev
In-Reply-To: <20070713170540.GA1987@aepfle.de>
On Fri, 2007-07-13 at 19:05 +0200, Olaf Hering wrote:
> 2.6.21 arch/powerpc/configs/iseries_defconfig works on an i825 with v5r4
> 2.6.22 arch/powerpc/configs/iseries_defconfig does not. But it works on
> a i820 with v5r3.
> 2.6.22 boots ok with CONFIG_VIOCONS
When it works, do you have more than one processor assigned to the
partition?
I noticed something similar last last week. What I've narrowed down so
far, is that it only fails in a single-processor partition, (dedicated
or shared doesnt matter). if I assign another proc, the partition
boots as expected.
turning on initcall_debug, output to the console stops after we get as
far as hvc_vio_init().
a small sampling of register dumps show us in these places:
put_chars() calling spin_lock_irqsave()
put_chars() calling vio_get_event_buffer()
put_chars() calling vio_free_event_buffer()
spin_unlock_irqrestore() calling local_irq_restore()
>
> It gets up to this point:
>
> vio_bus_init: processing c0000000fbfff570
> vio_bus_init: processing c0000000fbfff6b0
> vio_bus_init: processing c0000000fbfff7f0
> vio_bus_init: processing c0000000fbfff930
> vio_bus_init: processing c0000000fbfffa70
> vio_bus_init: processing c0000000fbfffbb0
> audit: initializing netlink socket (disabled)
> audit(1184327881.720:1): initialized
> io scheduler noop registered
> io scheduler anticipatory registered (default)
> io scheduler deadline registered
> io scheduler cfq registered
> viopath: opening connection to partition 0, setting sinst 32778, tinst 32769
> hvc: hosting partition 0
> vio_register_driver: driver hvc_console registering
> Generic RTC Driver v1.07
> RAMDISK driver initialized: 16 RAM disks of 65536K size 1024 blo
>
>
> with ppc64_defconfig it looks like that:
>
>
> audit: initializing netlink socket (disabled)
> audit(1184326841.030:1): initialized
> VFS: Disk quotas dquot_6.5.1
> Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
> io scheduler noop registered
> io scheduler anticipatory registered
> io scheduler deadline registered
> io scheduler cfq registered (default)
> pci_hotplug: PCI Hot Plug PCI Core version: 0.5
> rpaphp: RPA HOT Plug PCI Controller Driver version: 0.1
> rpadlpar_io_init: partition not DLPAR capable
> HVSI: registered 0 devices
> viopath: opening connection to partition 0, setting sinst 32774, tinst 32769
> hvc: hosting partition 0
> vio_register_driver: driver hvc_console registering
> Generic RTC Driver v1.07
> Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: ML410 PCI support
From: khollan @ 2007-07-16 15:38 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <11547023.post@talk.nabble.com>
khollan wrote:
>
> I have two questions:
> 1) Has anyone wrote linux 2.6 PCI drviers for the xilinx development
> boards. I want to get the PCI slots working on my board.
> 2)How do I set the HwAddr for the TEMAC driver? Im using Grants latest
> git tree. My board boots and the HwAddr is set to 00:00:00:00:00:00
> Thanks for your help
> Kevin
>
1) Still waiting to see if someone knows how to go about doing this...
2) Solved this by hardcoding it in the embed_config.c file
Any help would be appreciated for the PCI issue.
Kevin
--
View this message in context: http://www.nabble.com/ML410-PCI-support-tf4064052.html#a11620099
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* 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
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