Re: [PATCH 2/2 v3] sata_mv: Support SoC controllers

2008-02-01 Thread Paul Mundt
On Fri, Feb 01, 2008 at 11:53:30AM -0500, Jeff Garzik wrote: [EMAIL PROTECTED] wrote: --- /dev/null +++ b/include/linux/sata_mv.h @@ -0,0 +1,21 @@ +/* + * Marvell integrated SATA platfrom device data definition file. + * + * Saeed Bishara [EMAIL PROTECTED] + * + * This file is licensed

Re: [PATCH 2/3] Add GD-Rom support to the SEGA Dreamcast

2007-12-20 Thread Paul Mundt
On Thu, Dec 20, 2007 at 09:53:54PM +, Adrian McMenamin wrote: On 16/12/2007, Paul Mundt [EMAIL PROTECTED] wrote: Also, __devinit/__devexit annotations? Is there any difference between __init and __devint? Yes. - To unsubscribe from this list: send the line unsubscribe linux-ide

Re: [PATCH 2/3] Add GD-Rom support to the SEGA Dreamcast

2007-12-16 Thread Paul Mundt
Ok, I don't know anything about the CD-ROM layer, so I've just commented on the general and SH-specific stuff. Hopefully someone with a clue in this area (ie, not me) can offer input on the rest of the bits. On Sun, Dec 16, 2007 at 12:21:21AM +, Adrian McMenamin wrote: +/* GD Rom registers

Re: [PATCH 1/3] [libata] pata_platform: make probe and remove functions device type neutral

2007-12-16 Thread Paul Mundt
for the OF-platform driver. Signed-off-by: Anton Vorontsov [EMAIL PROTECTED] Acked-by: Olof Johansson [EMAIL PROTECTED] Looks fine to me now, thanks for cleaning it up Anton. Acked-by: Paul Mundt [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-ide in the body

Re: [PATCH 2/3] Add GD-Rom support to the SEGA Dreamcast

2007-12-16 Thread Paul Mundt
On Sun, Dec 16, 2007 at 05:32:51PM +, Adrian McMenamin wrote: On Sun, 2007-12-16 at 18:50 +0900, Paul Mundt wrote: + for (count = 0xa000; count 0xa020; count += 4) + ctrl_inl(count); Er? This ranged dummy reading of the P2 space needs some explanation. The GD-ROM

Re: [PATCH 0/3] Add GD-Rom support to the SEGA Dreamcast

2007-12-15 Thread Paul Mundt
On Sun, Dec 16, 2007 at 12:20:54AM +, Adrian McMenamin wrote: This device is electrically compatible with ATA-3 IDE CD drives but implements a proprietary packet interface. There have been previous Dreamcast CD drivers around but this is new code and uses DMA as opposed to PIO for reads.

Re: [PATCH v2 2/4] [libata] pata_of_platform: OF-Platform PATA device driver

2007-12-04 Thread Paul Mundt
On Tue, Dec 04, 2007 at 02:01:21PM -0600, Olof Johansson wrote: On Tue, Dec 04, 2007 at 10:49:21PM +0300, Anton Vorontsov wrote: tristate Generic platform device PATA support - depends on EMBEDDED || ARCH_RPC + depends on EMBEDDED || ARCH_PPC It needs to be || PPC, not ||

Re: [PATCH v2 4/4] [libata] pata_platform: s/ioport_shift/reg_shift/g

2007-12-04 Thread Paul Mundt
on your platform, add a comment to your platform-specific code noting this particular outrage so it can be grepped for by future generations ;-) Nacked-by: Paul Mundt [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED

Re: [PATCH 0/3] OF-platform PATA driver

2007-11-28 Thread Paul Mundt
On Tue, Nov 27, 2007 at 06:37:08PM +0300, Anton Vorontsov wrote: Here is the second spin of the OF-platform PATA driver and related patches. So either the patches are missing, or I wasn't CC'ed on them. I'm going to go out on a limb and assume the latter. If you wish me to Ack them, I'm not

Re: [RFC][PATCH 0/3] OF-platform PATA driver

2007-11-25 Thread Paul Mundt
On Mon, Nov 26, 2007 at 03:23:14AM +0300, Anton Vorontsov wrote: On Sat, Nov 24, 2007 at 04:26:13PM +0900, Paul Mundt wrote: On Fri, Nov 23, 2007 at 07:49:33PM -0500, Jeff Garzik wrote: Anton Vorontsov wrote: Here is the PATA Platform driver using OF infrastructure. Mostly it's

Re: [RFC][PATCH 0/3] OF-platform PATA driver

2007-11-23 Thread Paul Mundt
On Fri, Nov 23, 2007 at 07:49:33PM -0500, Jeff Garzik wrote: Anton Vorontsov wrote: Here is the PATA Platform driver using OF infrastructure. Mostly it's just a wrapper around a bit modified pata_platform driver. Patches are well split for the easier review: First one factors out

[PATCH 1/2] libata: Support PIO polling-only hosts.

2007-11-07 Thread Paul Mundt
that want to use polling mode can simply set ATA_FLAG_PIO_POLLING and pass in a NULL IRQ handler or invalid ( 0) IRQ. Signed-off-by: Paul Mundt [EMAIL PROTECTED] --- drivers/ata/libata-core.c |7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/ata/libata-core.c b/drivers/ata

[PATCH 2/2] libata: pata_platform: Support polling-mode configuration.

2007-11-07 Thread Paul Mundt
. This conditionalizes the IRQ resource for pata_platform and lets platforms that want to use polling mode simply omit the resource entirely. Signed-off-by: Paul Mundt [EMAIL PROTECTED] --- drivers/ata/pata_platform.c | 33 ++--- 1 file changed, 26 insertions(+), 7

Re: [PATCH 1/2] libata: Support PIO polling-only hosts.

2007-11-07 Thread Paul Mundt
On Wed, Nov 07, 2007 at 09:09:30AM -0500, Mark Lord wrote: Paul Mundt wrote: On Wed, Nov 07, 2007 at 01:09:40PM +, Alan Cox wrote: On Wed, 7 Nov 2007 17:10:52 +0900 Paul Mundt [EMAIL PROTECTED] wrote: By default ata_host_activate() expects a valid IRQ in order to successfully register

Re: [PATCH 1/2] libata: Support PIO polling-only hosts.

2007-11-07 Thread Paul Mundt
On Wed, Nov 07, 2007 at 01:09:40PM +, Alan Cox wrote: On Wed, 7 Nov 2007 17:10:52 +0900 Paul Mundt [EMAIL PROTECTED] wrote: By default ata_host_activate() expects a valid IRQ in order to successfully register the host. This patch enables a special case for registering polling-only

[PATCH 2/2 take #2] libata: pata_platform: Support polling-mode configuration.

2007-11-07 Thread Paul Mundt
. This conditionalizes the IRQ resource for pata_platform and lets platforms that want to use polling mode simply omit the resource entirely. Signed-off-by: Paul Mundt [EMAIL PROTECTED] --- drivers/ata/pata_platform.c | 35 --- 1 file changed, 28 insertions(+), 7

[PATCH 1/2 take #2] libata: Support PIO polling-only hosts.

2007-11-07 Thread Paul Mundt
that want to use polling mode can simply set ATA_FLAG_PIO_POLLING and pass in an invalid IRQ. Signed-off-by: Paul Mundt [EMAIL PROTECTED] --- drivers/ata/libata-core.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c index

Re: [PATCH] pata_platform: Fix NULL pointer dereference

2007-07-17 Thread Paul Mundt
On Tue, Jul 17, 2007 at 06:24:53AM -0400, Jeff Garzik wrote: It's just reality that there are never enough people to verify every patch before it goes in. We just support way too much hardware for that to be remotely feasible. Sure we -try- to keep the driver maintainer CC'd, but alas we

[PATCH] ata: pata_platform: Disable prereset logic.

2007-05-23 Thread Paul Mundt
there is no card inserted in the slot. Simply disabling the prereset gets rid of this, and doesn't seem to cause any problems for either PCMCIA or CF cards when they're actually present. Signed-off-by: Paul Mundt [EMAIL PROTECTED] -- drivers/ata/pata_platform.c | 15 +++ 1 file changed

Re: [PATCH] ata: pata_platform: Disable prereset logic.

2007-05-23 Thread Paul Mundt
On Wed, May 23, 2007 at 10:07:08AM +0200, Tejun Heo wrote: Paul Mundt wrote: On a number of boards the current prereset logic seems to misbehave: scsi0 : pata_platform ata1: PATA max PIO0 cmd 0xb06001f0 ctl 0xb06003f6 bmdma 0x irq 0 ata1: device not ready (errno=-19), forcing

Re: [PATCH] ata: pata_platform: Disable prereset logic.

2007-05-23 Thread Paul Mundt
On Wed, May 23, 2007 at 11:29:37AM +0200, Tejun Heo wrote: Paul Mundt wrote: On Wed, May 23, 2007 at 10:07:08AM +0200, Tejun Heo wrote: Paul Mundt wrote: On a number of boards the current prereset logic seems to misbehave: scsi0 : pata_platform ata1: PATA max PIO0 cmd 0xb06001f0 ctl

Re: [PATCH] libata: implement ata_wait_after_reset()

2007-05-22 Thread Paul Mundt
On Sat, May 19, 2007 at 09:04:56PM +0200, Tejun Heo wrote: Tejun Heo wrote: Yeah, if SCR registers are accessible, 0xff doesn't indicate the device isn't there, so the whole skip-0xff logic probably shouldn't apply in such cases, but we can also achieve pretty good result by just making

Re: [PATCH] libata: implement ata_wait_after_reset()

2007-05-16 Thread Paul Mundt
On Wed, May 16, 2007 at 06:44:53PM +0200, Tejun Heo wrote: This patch is against the current libata-dev#upstream + pata_scc-fix-build-failure[1]. [1] http://article.gmane.org/gmane.linux.kernel/528405 Paul, please verify this fixes your problem. You can skip the pata_scc patch, it will

Re: [PATCH] libata: implement ata_wait_after_reset()

2007-05-16 Thread Paul Mundt
On Wed, May 16, 2007 at 06:44:53PM +0200, Tejun Heo wrote: + /* FIXME: GoVault needs 2s but we can't afford that without + * parallel probing. 800ms is enough for iVDR disk + * HHD424020F7SV00. Increase to 2secs when parallel probing + * is in place. + */ +

Re: libata reset-seq merge broke sata_sil on sh

2007-05-11 Thread Paul Mundt
On Fri, May 11, 2007 at 11:39:20AM +0200, Tejun Heo wrote: Paul Mundt wrote: Bumping the hardreset delay up does indeed fix it, I've had to bump it up to 1200 before it started working (at 600 it still fails): [0.967379] scsi0 : sata_sil [0.970425] scsi1 : sata_sil

libata reset-seq merge broke sata_sil on sh

2007-05-10 Thread Paul Mundt
Current git fails to boot via SATA on SH with the recent libata merge: sata_sil :00:01.0: cache line size not set. Driver may not function scsi0 : sata_sil scsi1 : sata_sil ata1: SATA max UDMA/100 cmd 0xfd000280 ctl 0xfd00028a bmdma 0xfd000200 irq 0 ata2: SATA max UDMA/100 cmd 0xfd0002c0 ctl

Re: libata reset-seq merge broke sata_sil on sh

2007-05-10 Thread Paul Mundt
On Thu, May 10, 2007 at 01:28:19PM +0200, Tejun Heo wrote: Paul Mundt wrote: [--snip, thanks a lot for the detailed report--] However, if I go back before any of the reset changes were introduced, things were working fine, and there were no problems with waiting for the reset. Ideas

Re: libata reset-seq merge broke sata_sil on sh

2007-05-10 Thread Paul Mundt
On Thu, May 10, 2007 at 03:08:59PM +0200, Tejun Heo wrote: Paul Mundt wrote: The detection is simply flaky after that point, however before the current master it never hit the 35 second point (and thus never implied that the link was down). I'll double check the bisect log to see