Hello, I wrote:
This is the driver for the Toshiba TX4938 SoC EBUS controller ATA mode.
It has custom set_pio_mode and some hacks for big endian.
Signed-off-by: Atsushi Nemoto <anemo@xxxxxxxxxxxxx>
[...]
+static void tx4938ide_input_data_swap(ide_drive_t *drive, struct
request *rq,
+ void *buf, unsigned int len)
+{
+ unsigned long port = drive->hwif->io_ports.data_addr;
+ unsigned short *ptr = buf;
+ unsigned int count = (len + 1) / 2;
+
+ while (count--)
+ *ptr++ = cpu_to_le16(__raw_readw((void __iomem *)port));
+ __ide_flush_dcache_range((unsigned long)buf, count * 2);
+}
+
+static void tx4938ide_output_data_swap(ide_drive_t *drive, struct
request *rq,
+ void *buf, unsigned int len)
+{
+ unsigned long port = drive->hwif->io_ports.data_addr;
+ unsigned short *ptr = buf;
+ unsigned int count = (len + 1) / 2;
+
+ while (count--) {
+ __raw_writew(le16_to_cpu(*ptr), (void __iomem *)port);
+ ptr++;
+ }
+ __ide_flush_dcache_range((unsigned long)buf, count * 2);
+}
Atsushi, does TX49 really suffer from the issue that these flushes
are trying to address?
Well, looking thru the TX4939 thread, it appears that I've asked this
question already. Isn't this related to VIVT caches?
MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
