2
0
mirror of https://github.com/edk2-porting/linux-next.git synced 2024-12-30 16:13:54 +08:00
Commit Graph

7 Commits

Author SHA1 Message Date
Bartlomiej Zolnierkiewicz
d7f5143522 palm_bk3710: palm_bk3710_udmatimings[] CodingStyle fixup
Remove superfluous commas and add missing whitespaces.

Noticed-by: Joe Perches <joe@perches.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
2009-04-23 22:53:45 +02:00
David Brownell
33e86019f7 palm_bk3710: those registers/bitfields don't exist
Bugfixes noted by checking the code against the controller
documentation (TI document number SPRUE21):

 - Remove declarations for eight non-existent registers (!);
   and remove accesses to two of them.

 - Remove access to various non-existent bitfields in some of
   the registers which *do* exist (those fields must-be-zero).

 - Provide comment to replace bogus reset logic (removed above,
   it relied on non-existent bitfields).  Resets require GPIO
   help; this driver doesn't currently know about that.

With some minor cleanup:  relocate a comment, avoid an extra
lookup of the PIO timings.

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
2009-04-23 22:53:43 +02:00
David Brownell
db2f38c22e palm_bk3710: UDMA performance fix
Fix UDMA throughput bug:  tCYC averages t2CYCTYP/2, but the code
previously assumed it was the same as t2CYCTYP.  (That is, it was
using just one clock edge, not both.)  Move the table's type
declaration so it's adjacent to the table, making it more clear
what those numbers mean.

On one system this change increased throughput by almost 4x: UDMA/66
sometimes topped 23 MB/sec (on a drive known to do much better).  On
another system it was around a 10% win (UDMA/66 up to 7+ MB/sec).

The difference might be caused by the ratio between memory and IDE
clocks.  In the system with large speedup, this was exactly 2 (as a
workaround for a rev 1.1 silicon bug).  The other system used a more
standard ratio of 1.63 (and rev 2.1 silicon) ... clock domain synch
might have some issues, they're not unheard-of.

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
2009-04-22 20:33:40 +02:00
Kevin Hilman
13b8860d10 IDE: palm_bk3710: use ioremap instead of arch-specific IO_ADDRESS()
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
[bart: minor CodingStyle fixup per Sergei's suggestion]
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
2009-03-27 12:46:23 +01:00
David Brownell
ef183f6b59 drivers/ide/palm_bk3710.c buildfix
CC      drivers/ide/palm_bk3710.o
drivers/ide/palm_bk3710.c: In function 'palm_bk3710_probe':
drivers/ide/palm_bk3710.c:382: warning: assignment makes integer from pointer without a cast

Someone should fix hw_regs_t to neither be a typedef, nor
use "unsigned long" where it should use "void __iomem *".

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
2009-01-19 13:46:57 +01:00
Sergei Shtylyov
3f023b0138 ide: don't set hwif->dma_ops in init_dma() method
Replace setting of 'hwif->dma_ops' in the 'alim15x3' and 'palm_bk3710' drivers'
init_dma() methods with initializing the corresponding member of their 'struct
ide_port_info' instances and remove such setting from the 'hpt366' driver that
just doesn't use 'sff_dma_ops'. Along with some code save, this prepares us for
the next patch...

Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
2009-01-06 17:21:01 +01:00
Bartlomiej Zolnierkiewicz
2bfba3c444 ide: remove useless subdirs from drivers/ide/
Suggested-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
2008-10-21 20:57:23 +02:00