On Wed, 2005-08-10 at 23:04 -0400, Jeff Garzik wrote:
mdelay() should be investigated as to why its not working on your
platform. do_gettimeofday() is -less- granular and accurate than
mdelay(), usually.
Agreed. mdelay() should have worked.
Ben.
-
To unsubscribe from this list: send the
Hi Bart !
That seem to be a new problem though I can't tell for sure when it
started. I've had reports from users for some time now of
occasional (once in a while, maybe once a day) lost interrupts on the
mac hard disk. I have about 30 days uptime and just saw a similar one in
my log. It happen
On Fri, 2006-12-01 at 22:05 +0300, Sergei Shtylyov wrote:
Olaf Hering wrote:
The printk in pci_request_region has 'bar + 1', so 6 should be possible
if i becomes 5.
Does the IO region of the last bar look correct?
I think BAR 5 is unassigned by the firmware, though when OF does that,
it
I don't think that is the problem. pci_request_regions() handles all
this internally. It is incorrect for me to not request BAR 5
if present as nobody else should use that resource with my driver loaded.
The underlying problem appears to be that PPC64 isn't setting up the
resources properly
On Mon, 2006-12-04 at 14:22 +, Alan wrote:
The discussion I was having was about sl82cxx and handling unassigned
resources. The zero address isn't relevant to that.
Well, actually, it's unclear to me wether the resource is unassigned or
has been assigned to 0 :-) And in the later case, why
On Mon, 2006-12-04 at 21:53 +0100, Guennadi Liakhovetski wrote:
On Mon, 4 Dec 2006, Sergei Shtylyov wrote:
When Linus remaps IRQ0 on x86, I'll follow that code as a testament.
Until
this happens, I consider is just an opinion. Forcing every arch but x86
to
remap IRQ0 is an
Could that be related to the fix
[PATCH] libata: fix oops with sparsemem
That Arnd Bergmann just posted ? I'm copying it below in case you
haven't seen it.
From:
Arnd Bergmann
[EMAIL PROTECTED]
To:
[EMAIL PROTECTED]
Add to pseries/pci.c a quirk for that chipset (don't forget to test for
machine_is(pseries) in the quirk as they get called for all platforms in
a combo kernel. The quirk shall check if resource 6 has a 0 base and
clear the size as Alan suggested (possibly setting the UNSET flag as
On Fri, 2007-01-05 at 11:26 +0100, Olaf Hering wrote:
On Fri, Jan 05, Benjamin Herrenschmidt wrote:
Nah, but also set resource-end = 0 too and or-in IORESOURCE_UNSET for
flags not (=) (or just set it to 0, I have no problem with completely
clearing the resource, that will keep it out
Actually, an even stronger reason to use an abstraction is the
fact that this is not really a PCI device and you therefore
don't use readl/writel, but rather in_be32/out_be32.
If you think the code gets better by using the low-level calls,
then it would be good if you also do the patch to
On Thu, 2007-01-11 at 18:30 +0900, Akira Iguchi wrote:
Hi, Arnd-san.
Thank you for checking our patches.
On Thursday 11 January 2007 09:56, Akira Iguchi wrote:
This patch modifies some static functions in libata-core.c
and libata.h to use them in ata_scc.c.
Exporting new symbols
Why is it that other drivers did not need this functions? Did they
copy them? Or maybe they don't need them?
Most drivers can use the common functions as is. The problem starts when
you need special mecanisms to access the taskfile registers.
Ben.
-
To unsubscribe from this list: send the
On Fri, 2007-01-12 at 10:24 +, Alan wrote:
On Fri, 12 Jan 2007 19:00:45 +0900
Akira Iguchi [EMAIL PROTECTED] wrote:
Dear everyone,
This is the patchset (based on 2.6.20-rc4) to add low-level I/O calls
which access the taskfile registers. The idea comes from drivers/ide
IN*/OUT*
On Wed, 2007-01-24 at 20:20 -0500, Jeff Garzik wrote:
Akira Iguchi wrote:
This is the patch for PATA controller of Celleb.
It depends on the previous add another IRQ calls patch.
Because this driver needs special taskfile accesses, there is
a copy of ata_std_softreset().
2.6.20 has been released and (I think) it is the time of merge-window
for 2.6.21. I want this patch to be merged at this time.
Please tell me if there are anything I should do.
FYI, Jeff, we have merged the rest of the celleb platform support in the
2.6.21 merge window, so it would be
On Thu, 2007-02-15 at 00:12 -0500, Jeff Garzik wrote:
My overall impression of spidernet development is that EVERYBODY is
submitting patches at once, and expecting me to sort out the mess. No
thanks.
Speaking with one voice would be much appreciated. And said speaker should
patch
I'm totally confused about who the heck is the spidernet maintainer.
Me too :-)
My
inbox is pelted by spidernet driver updates from multiple people, and
often the spidernet patches (regardless of author) receive comments that
give me pause. The MAINTAINERS file says
SPIDERNET
On Fri, 2007-02-16 at 17:55 +0300, Sergei Shtylyov wrote:
Hello.
Bartlomiej Zolnierkiewicz wrote:
I'm sorry, how those 2 drivers can be equivalent?! The pata_winbond
driver
is for VLB only, sl81c105 was for PCI only -- you certainly want to use
pata_sl82c105 (indeed better
On Mon, 2007-02-19 at 21:56 +, Alan wrote:
I fear that the hardest part is yet to come, when we integrate the
driver for the the PS3 (currently called gelic_net) into spidernet.
The trouble is that the hardware is sufficiently similar to share
all the high-level mechanisms like the DMA
On Mon, 2007-02-19 at 21:56 +, Alan wrote:
I fear that the hardest part is yet to come, when we integrate the
driver for the the PS3 (currently called gelic_net) into spidernet.
The trouble is that the hardware is sufficiently similar to share
all the high-level mechanisms like the DMA
On Mon, 2007-02-19 at 23:46 +, Alan wrote:
into one in drivers/ide but really want splitting for libata with some
kind of libata-pmac owning the shared stuff
You meand driver/ide/ppc/pmac.c ?
Yes
moving them out of the macio_asic to a PCI device at one point, so yes,
maybe
On Tue, 2007-02-20 at 00:17 +0100, Bartlomiej Zolnierkiewicz wrote:
On Tuesday 20 February 2007 00:46, Alan wrote:
into one in drivers/ide but really want splitting for libata with some
kind of libata-pmac owning the shared stuff
You meand driver/ide/ppc/pmac.c ?
Yes
On Wed, 2007-04-04 at 13:16 +0200, Olaf Hering wrote:
The pegaos board needs an irq quirk in pata_via.
Where is the quirk list for libata? I dont see one in pata_via.c
drivers/ide/pci/via82cxxx.c:init_hwif_via82cxxx()
440 #ifdef CONFIG_PPC_CHRP
441 if(machine_is(chrp)
On Wed, 2007-04-04 at 20:11 +0200, Olaf Hering wrote:
On Wed, Apr 04, Bartlomiej Zolnierkiewicz wrote:
?
You are right, I did not test the ide driver again. pata_via works with
the change.
Probably only the first channel works...
Ben.
-
To unsubscribe from this list: send the line
There might be also the another issue here - the chipset claims fully native
mode (prog-if 8f - taken from your previous mail) so driver takes IRQ value
from dev-irq (which your patch fixes to be 14 instead of 20 if I'm reading
it correctly) but in reality chipset seems to be still using
Since this is a 2.6.17-2.6.18 regression narrowing the problem down to
the specific changeset (or at least -git or even -rc) seems like a most
promising way in discovering the source of the issue.
Dunno... unless I missed something in the logs, both 2.6.17 and .18 seem
to report initially the
Great. That should fit perfectly with the glue I have now, it'll turn
into the constructor instead.
I honestly don't see what the benefit is of this recent obsession
with creating of_platform devices for every new device that's not
PCI, especially when there's an already well-fitting
tested it on a Cell blade and it seems to work fine.
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
drivers/ata/pata_sil680.c | 64 +++---
1 file changed, 60 insertions(+), 4 deletions(-)
Index: linux-cell/drivers/ata/pata_sil680.c
tested it on a Cell blade and it seems to work fine.
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
drivers/ata/pata_sil680.c | 70 --
1 file changed, 62 insertions(+), 8 deletions(-)
Index: linux-cell/drivers/ata/pata_sil680.c
On Tue, 2007-05-15 at 16:11 +1000, Benjamin Herrenschmidt wrote:
This patch adds MMIO support to the pata_sil680 for taskfile IOs,
based on what the old siimage does.
I haven't bothered changing the chip setup stuff from PCI config
cycles to MMIO though (siimage does it), I don't think
On Tue, 2007-05-15 at 16:12 +1000, Benjamin Herrenschmidt wrote:
This patch adds MMIO support to the pata_sil680 for taskfile IOs,
based on what the old siimage does.
I haven't bothered changing the chip setup stuff from PCI config
cycles to MMIO though (siimage does it), I don't think
On Tue, 2007-05-15 at 07:08 -0400, Alan Cox wrote:
On Tue, May 15, 2007 at 04:11:23PM +1000, Benjamin Herrenschmidt wrote:
+ if (!try_mmio)
+ goto use_pio;
Please use a different naming scheme PIO means something quite different
in ATA
Indeed, the naming's a bit confusing
tested it on a Cell blade and it seems to work fine.
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
This version uses a better name use_ioports for the fallback
label in the probe code.
drivers/ata/pata_sil680.c | 70 --
1 file changed
On Sat, 2007-05-19 at 12:29 +0200, Tejun Heo wrote:
Recent mmio change broke compilation if PM is turned on. Fix it.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
Cc: Benjamin Herrenschmidt [EMAIL PROTECTED]
Oops.. sorry about that.
Cheers,
Ben.
---
pata_sil680.c |4 +++-
1 file
On Wed, 2007-05-23 at 14:42 +0100, Alan Cox wrote:
I'm going to have to NAK this on further review as it will break SRST
handling in some cases. Until ata_bus_softreset has been fixed (see
FIXME: entries) we shouldn't push this patch mainstream, or if we have
then someone should fix the
On Thu, 2007-05-24 at 00:31 +0100, Alan Cox wrote:
Anything non taskfile, which is tricky to do arbitarily for all
controllers - this is why I didn't just stuff in a simple fix and post it.
We might have to provide an optional -flush() that is device specific ?
Config space access would do
On Thu, 2007-05-24 at 02:02 -0400, Jeff Garzik wrote:
MMIO has always been like this (libata-core.c):
/* software reset. causes dev0 to be selected */
iowrite8(ap-ctl, ioaddr-ctl_addr);
udelay(20); /* FIXME: flush */
iowrite8(ap-ctl | ATA_SRST,
On Thu, 2007-05-24 at 05:55 -0400, Jeff Garzik wrote:
Alan Cox wrote:
On Thu, May 24, 2007 at 02:02:11AM -0400, Jeff Garzik wrote:
Ben's patch got merged because it does not change the status quo. This
Yes it does - Thats PATA and now
PATA + MMIO so the problem case.
hmmm, true.
On Thu, 2007-05-24 at 16:56 -0400, Mark Lord wrote:
Benjamin Herrenschmidt wrote:
The only thing that I'm wondering about a bit is that ata_pause so far
uses read of altstatus which _is_ a taskfile register. It's my
understanding that we should avoid doing so in that case.
Technically
On Thu, 2007-05-24 at 23:33 -0400, Jeff Garzik wrote:
I moved the sil680 MMIO changes from 'upstream' (queued for 2.6.23) to
a
side branch 'sil680-mmio'.
To be clear, I am still quite interested in the patch (w/ the reset
fix), but I did not want to delay other unrelated stuff that was
On Fri, 2007-05-25 at 00:26 -0400, Jeff Garzik wrote:
Just replace the ata_std_softreset() call with code that does MMIO
flushes on a safe register?
Yeah well... if just reading altstatus is enough, I don't see the point
of doing anything MMIO-dependant or whatever. I can just add reading of
On Fri, 2007-05-25 at 00:41 -0400, Jeff Garzik wrote:
Sorry, to be clear I would not want to change the core code to bang
AltStatus in the middle of the SRST twiddles...
The core code only fails (in theory) for PATA+MMIO cases, and the
easiest fix should be to read some innocuous
This patch should have no effect on the default kernel behavior because
IDE pmac driver doesn't enable -autotune (this would also explain why some
of the above bugs remained unfixed for so long).
This part of the patch description is actually incorrect: -tuneproc is used
unconditionally
On Sun, 2007-07-22 at 20:19 +0200, Bartlomiej Zolnierkiewicz wrote:
pmac_ide_tune_chipset() don't set drive-init_speed.
Fix it by setting drive-{current,init}_speed in pmac_ide_do_setfeature()
and clean up pmac_ide_{tune_chipset,mdma_enable,udma_enable}().
Acked-by: Benjamin Herrenschmidt
it actually
compiles.
* Removal of kauai_lookup_timing() return value checking went to separate
patch.
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
Cc: Sergei Shtylyov [EMAIL PROTECTED]
---
replacement patch for the one in IDE
On Sun, 2007-07-22 at 20:20 +0200, Bartlomiej Zolnierkiewicz wrote:
kauai_lookup_timing() should always return non-zero return value:
* BUG() in kauai_lookup_timing() if the timing info cannot be found.
* Remove code checking for zero return value from all callers.
Acked-by: Benjamin
in
pmac_ide_do_setfeature() will program new timings before the transfer mode
is set on the device - this was pointed out by Sergei). This change makes
pmac_ide_tune_chipset() behavior match this of pmac_ide_{m,u}dma_enable().
Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
Signed
value is passed (shouldn't happen).
* Matching access/recovery timings always exist so remove redundant check.
* Make set_timings_mdma() void.
* Update pmac_ide_tune_chipset()'s comment.
Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL
On Sun, 2007-07-22 at 20:23 +0200, Bartlomiej Zolnierkiewicz wrote:
pmac_ide_do_setfeature() contains matching nIEN setting/clearing so this
Device Control register messing in pmac_ide_dma_check() is totally
unnecessary.
Cc: Benjamin Herrenschmidt [EMAIL PROTECTED]
Signed-off
ide_max_dma_mode()).
There should be no functionality changes caused by this patch.
Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
drivers/ide/ppc/pmac.c | 101
-
1 file changed
before we get here.
I had issues in those areas ... I'd like to keep a warning at least or
something in there for now.
Ben.
Cc: Benjamin Herrenschmidt [EMAIL PROTECTED]
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
drivers/ide/ppc/pmac.c | 12 +---
1 file changed
sec for device to clear BUSY_STAT.
* Check DRQ_STAT bit (shouldn't be set for good device status).
Also remove no longer needed wait_for_ready() from ide-iops.c.
Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
drivers/ide
: Benjamin Herrenschmidt [EMAIL PROTECTED]
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
drivers/ide/ppc/pmac.c |1 -
1 file changed, 1 deletion(-)
Index: b/drivers/ide/ppc/pmac.c
===
--- a/drivers/ide/ppc
static int
pmac_ide_dma_check(ide_drive_t *drive)
{
- struct hd_driveid *id = drive-id;
Actually, this one breaks compile, id is used a bit further below in
that function.
Cheers,
Ben.
- ide_hwif_t *hwif = HWIF(drive);
- pmac_ide_hwif_t* pmif = (pmac_ide_hwif_t
Note that with all your patches applied, it doesn't seem to auto-tune
the speed at boot anymore and doesn't enable DMA. I can make it do so
with hdparm -d1, in which case, for example, on this wallstreet, I get
MDMA2 which is correct, however, it seems to also set PIO0 which it
should set PIO4...
On Mon, 2007-07-23 at 09:55 +1000, Benjamin Herrenschmidt wrote:
Note that with all your patches applied, it doesn't seem to auto-tune
the speed at boot anymore and doesn't enable DMA. I can make it do so
with hdparm -d1, in which case, for example, on this wallstreet, I get
MDMA2 which
On Mon, 2007-07-23 at 11:21 +1000, Benjamin Herrenschmidt wrote:
On Mon, 2007-07-23 at 09:55 +1000, Benjamin Herrenschmidt wrote:
Note that with all your patches applied, it doesn't seem to auto-tune
the speed at boot anymore and doesn't enable DMA. I can make it do so
with hdparm -d1
Ok, there's a combination of things here:
- First, doing a set_pio from userland (hdparm -p XX) causes the kernel
to disable DMA, which I think is incorrect. It's not the case with
2.6.22 from my quick tests. The problem is that ide_config_drive_speed
disables DMA, but only re-enables it
Gah! Why the debug messages might be using KERN_ERR?
Blah, other debug messages where like that and I copy/pasted stupidly. I
suppose at one point, somebody (maybe me) decided that it was a PITA to
have to add debug on the kernel command line :-)
I will change all of these to pr_debug
On Mon, 2007-07-23 at 23:22 +0200, Bartlomiej Zolnierkiewicz wrote:
Hi,
Thanks for reviewing and testing this patch series.
On Monday 23 July 2007, Benjamin Herrenschmidt wrote:
Ok, there's a combination of things here:
- First, doing a set_pio from userland (hdparm -p XX
On Tue, 2007-07-24 at 02:06 +0400, Sergei Shtylyov wrote:
Ugh ? It re-enables DMA in the sense that if called to configure a
DMA
speed, it re-enables dma on the host, thus effectively leaving with
DMA
enabled.
No. DMA is still diabled for the IDE core at this point. You need
a real
On Thu, 2007-07-26 at 20:04 +0200, Bartlomiej Zolnierkiewicz wrote:
On Tuesday 24 July 2007, Benjamin Herrenschmidt wrote:
On Tue, 2007-07-24 at 00:29 +0200, Bartlomiej Zolnierkiewicz wrote:
Use ide_config_drive_speed() instead of pmac_ide_do_setfeature() and
remove
the latter, also
On Mon, 2007-08-06 at 20:04 +0200, Segher Boessenkool wrote:
That's of course the smarter choice, _if_ we have a choice at
all -- on PowerPC, the PCI setup on certain platforms is done
by the firmware (and we don't want to mess with it for various
reasons), and some _do_ map PCI legacy I/O at
On Mon, 2007-09-24 at 22:27 +0100, Matt Sealey wrote:
Yeah I'll ack it if it matters, although I'd make a nit about the
fixing of device tree entries in prom_init and have it moved to
nvramrc or a Forth script or boot loader..
Pegasos IDE quirks have been fixed so many times now in Linux,
Saw that popping up in my log today on a brand new T61 thinkpad:
[ 427.712000] ata1.00: exception Emask 0x2 SAct 0x18 SErr 0x0 action 0x2 frozen
[ 427.712000] ata1.00: (spurious completions during NCQ issue=0x0 SAct=0x18
FIS=004040a1:0024)
[ 427.712000] ata1.00: cmd
Let me guess... this is a T61 or X61 ?
There's a problem with these that we don't fully understand yet, we're
getting those stale interrupts all over the range.
I wonder if it could be a bug with the ICH8 chipset...
If yours is one of these, it's being dealt with (or attempted to deal
with) at
On Thu, 2007-09-27 at 10:05 +, Paul Rolland wrote:
Hello,
On Thu, 27 Sep 2007 19:04:11 +1000
Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:
Let me guess... this is a T61 or X61 ?
Bad luck ;)
This is an Asus P5W-DH Deluxe motherboard, with a Core2 6400 CPU,
a bunch of disk (2
On Thu, 2007-09-27 at 13:35 -0700, Tejun Heo wrote:
Benjamin Herrenschmidt wrote:
Saw that popping up in my log today on a brand new T61 thinkpad:
[ 427.712000] ata1.00: exception Emask 0x2 SAct 0x18 SErr 0x0 action 0x2
frozen
[ 427.712000] ata1.00: (spurious completions during NCQ
On Sun, 2007-10-14 at 00:41 +0200, Bartlomiej Zolnierkiewicz wrote:
On Sunday 14 October 2007, Alan Cox wrote:
/* Probably a PCI interface... */
for (i = IDE_DATA_OFFSET; i = IDE_STATUS_OFFSET; ++i)
hw-io_ports[i] = data_port + i -
How's about this patch?
[PATCH] ide-pmac: fix pmac_ide_init_hwif_ports()
* pmac_ide_init_hwif_ports() can be called by ide_init_hwif_ports()
(through ppc_ide_md.ide_init_hwif hook) for non IDE PMAC interfaces.
If this is the case the hw-io_ports[] should be already setup by
At least 2 drivers (siimage and cs5535) have a bug where they use
the construct:
ide_drive_t *pair = hwif-drives[drive-dn ^ 1];
To access the other drive in a master/slave pair. This is bogus
because drive-dn is not the unit number, but the global drive
number, thus can be 2 3 for
The siimage use an incorrect construct to access the other drive
of a pair, causing it to access beyond an array boundary on non-0
interfaces. This fixes it by using the new ide_get_paired_drive()
hepler instead.
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
drivers/ide/pci
The cs5535 use an incorrect construct to access the other drive
of a pair, causing it to access beyond an array boundary on non-0
interfaces. This fixes it by using the new ide_get_paired_drive()
hepler instead.
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
drivers/ide/pci/cs5535
On Thu, 2007-10-18 at 15:54 +0400, Sergei Shtylyov wrote:
Hello.
Benjamin Herrenschmidt wrote:
At least 2 drivers (siimage and cs5535) have a bug where they use
the construct:
ide_drive_t *pair = hwif-drives[drive-dn ^ 1];
To access the other drive in a master/slave
On Fri, 2007-10-19 at 16:21 -0400, Jeff Garzik wrote:
Take a look at tg3.c net driver change
2fbe43f6f631dd7ce19fb1499d6164a5bdb34568 which is a similar situation.
However, it may turn out that removing the pci_intx() stuff as a
general
rule is easier than quirking these devices, if
On Mon, 2007-11-05 at 00:17 +0100, Bartlomiej Zolnierkiewicz wrote:
We can skip conservative PIO downgrade (PIO3 becomes PIO2 etc.) on PMAC.
Problem reported by Mikael.
Cc: Mikael Pettersson [EMAIL PROTECTED]
Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
Signed-off-by: Bartlomiej
On Sun, 2007-11-18 at 23:41 +0100, Bartlomiej Zolnierkiewicz wrote:
* Make remaining built-in only IDE host drivers modular, add ide-scan-pci.c
file for probing PCI host drivers registered with IDE core (special case
for built-in IDE and CONFIG_IDEPCI_PCIBUS_ORDER=y) and then take care of
On Fri, 2007-11-23 at 20:52 +0300, Anton Vorontsov wrote:
As an alternative approach we can use plain pata_platform
driver, but I'm not sure how Linux OF bindings' ideologists will
or will not like it.
So, these patches are strongly Request For Comments. Feel free
to train your nitpicking
On Wed, 2007-11-28 at 00:00 +0100, Bartlomiej Zolnierkiewicz wrote:
Move setting hwif-sg_max_nents from pmac_ide_setup_device()
to pmac_ide_setup_dma().
Cc: Benjamin Herrenschmidt [EMAIL PROTECTED]
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
Ack.
---
drivers/ide/ppc
On Thu, 2008-01-03 at 19:43 -0600, Robert Hancock wrote:
Benjamin Herrenschmidt wrote:
Another thing about the PacDigi core: one has to be very careful
to avoid sequential accesses to sequential PCI locations when
programming the chip -- it cannot handle merged register writes.
So
On Wed, 2008-01-23 at 00:12 +0100, Bartlomiej Zolnierkiewicz wrote:
* Replace incorrect CONFIG_BLK_DEV_IDE #ifdef in
check_media_bay() by CONFIG_MAC_FLOPPY one.
* Replace incorrect CONFIG_BLK_DEV_IDE #ifdef-s by
CONFIG_BLK_DEV_IDE_PMAC ones.
* check_media_bay() is used only by
Since Alan has commented on it:
http://lkml.org/lkml/2007/12/17/422
5520 in fact is always enabled as it is the host bridge.
pci_enable_device_io will do just fine. The 5520 fun is if you disable it
the system hangs.
I moved on assuming that either submitter or integrator
On Fri, 2008-02-08 at 19:40 +1100, Benjamin Herrenschmidt wrote:
On Fri, 2008-02-08 at 01:44 +0100, Bartlomiej Zolnierkiewicz wrote:
- couple of fixes and preparatory patches
- rework of PowerMac media-bay support ([un]register IDE devices instead of
[un]registering IDE interface
On Tue, 2008-02-12 at 12:49 +0100, Gabriel Paubert wrote:
On Fri, Feb 08, 2008 at 07:40:43PM +1100, Benjamin Herrenschmidt wrote:
On Fri, 2008-02-08 at 01:44 +0100, Bartlomiej Zolnierkiewicz wrote:
- couple of fixes and preparatory patches
- rework of PowerMac media-bay support
On Mon, 2008-02-25 at 19:15 -0500, Jeff Garzik wrote:
Mark Lord wrote:
Jeff,
We had a discussion here today about IOMMUs,
and they *never* split sg list entries -- they only ever *merge*.
And this happens only after the block layer has
already done merging while respecting
The block layer uses seg_boundary_mask to ensure that we never have
to split them again in the LLD.
A very long time ago, when I wrote the IDE DMA code, this was not the case.
Not good enough, still, because the boundaries can change due to the
iommu merging, thus the split must be re-done.
James B. suggests that we stick a WARN_ON() into libata to let us
know if that precondition is violated. Sounds like an easy thing to do
for a couple of -rc cycles someday.
If the block layer gives us a 32k block aligned on a 32k boundary
(aligned), we have no guarantee that the iommu will
On Mon, 2008-02-25 at 23:38 -0500, Mark Lord wrote:
Benjamin Herrenschmidt wrote:
James B. suggests that we stick a WARN_ON() into libata to let us
know if that precondition is violated. Sounds like an easy thing to do
for a couple of -rc cycles someday.
If the block layer gives us
On Tue, 2008-02-26 at 00:43 -0500, Mark Lord wrote:
I suppose so. I don't remember all of the details, but iirc, it has to
do with crossing 64K boundaries. Some controllers can't handle it.
It's not only the _size_ of the segments, it's their alignment.
The iommu will not keep
89 matches
Mail list logo
