From: Sergei Shtylyov <sshtylyov@ru.mvista.com>
To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc: linux-mips@linux-mips.org, linux-ide@vger.kernel.org,
bzolnier@gmail.com, ralf@linux-mips.org
Subject: Re: [PATCH 1/2] ide: Add tx4939ide driver
Date: Fri, 12 Sep 2008 19:34:06 +0400 [thread overview]
Message-ID: <48CA8BEE.1090305@ru.mvista.com> (raw)
In-Reply-To: <20080912.005243.48535230.anemo@mba.ocn.ne.jp>
Atsushi Nemoto wrote:
>>>+static void tx4939ide_check_error_ints(ide_hwif_t *hwif, u16 stat)
>>>+{
>>>+ if (stat & TX4939IDE_INT_BUSERR) {
>>>+ unsigned long base = TX4939IDE_BASE(hwif);
>>>+ /* reset FIFO */
>>>+ TX4939IDE_writew(TX4939IDE_readw(base, Sys_Ctl) |
>>>+ 0x4000,
>>>+ base, Sys_Ctl);
>> Are you sure bit 14 is self-clearing? The datashhet doesn't seem to
>>say that...
> Well, I cannot remember... I thought I checked that bit cleard by
> reading it, but actually the bit is write-only. Maybe clearing
> explicitly would be a safe bet.
It's also write-only on TC86C001, and the original driver (as well as
mine) cleared it explicitly.
>>>+ rc = __tx4939ide_dma_setup(drive);
>>>+ if (rc == 0) {
>>>+ /* Number of sectors to transfer. */
>>>+ nframes = 0;
>>>+ for (i = 0; i < hwif->sg_nents; i++)
>>>+ nframes += sg_dma_len(&hwif->sg_table[i]);
>>>+ BUG_ON(nframes % sect_size != 0);
>>>+ nframes /= sect_size;
>>>+ BUG_ON(nframes == 0);
>>>+ TX4939IDE_writew(nframes, base, Sec_Cnt);
>> Ugh, it looks much easier in my TC86C001 driver... doesn't
>>hwgroup->rq->nr_sectors give you a number of 512 sectors?
>>Why bother with other (multiple of 512) sizes when you can always
>>program transfer in 512-byte sectors? Or was I wrong there?
Anyway, the TX3939 datasheet says that sector size must be a multiple of
256 words when transferring more than 1 sector.
> Hmm. Good idea. I will try it.
At least it worked with a CD-ROM for me. :-)
>>>+static int tx4939ide_dma_end(ide_drive_t *drive)
>>>+{
>>>+ if ((dma_stat & 7) == 0 &&
>>>+ (ctl & (TX4939IDE_INT_XFEREND | TX4939IDE_INT_HOST)) ==
>>>+ (TX4939IDE_INT_XFEREND | TX4939IDE_INT_HOST))
>>>+ /* INT_IDE lost... bug? */
>>>+ return 0;
>> You shouldn't fake the BMDMA interrupt. If it's not there, it's not
>>there. Or does this actually happen?
> IIRC, Yes.
Hum, let me think... worth printing a message if this happens.
>>>+ /*
>>>+ * If only one of XFERINT and HOST was asserted, mask
>>>+ * this interrupt and wait for an another one. Note
>> This comment somewhat contradicts the code which returns 1 if only
>>HOST interupt is asserted if ERR is set.
Which is not its business to test. I think you should remove that above
check -- if there's INTRQ asserted, then it's asserted. I wonder if BMIDE
interrupt bit gets set in that case (suspecting it's not)...
> Indeed. I will make the comment more precise.
>>>+ case TX4939IDE_INT_HOST | TX4939IDE_INT_XFEREND:
>>>+ dma_stat = TX4939IDE_readb(base, DMA_stat);
>>>+ if (!(dma_stat & 4))
>>>+ pr_debug("%s: weired interrupt status. "
>>>
>> Weird.
> Sure. But it can happen IIRC...
I meant the typo. :-)
>>>#ifdef __BIG_ENDIAN
>>>+/* custom iops (independent from SWAP_IO_SPACE) */
>>>
>>>+static u8 mm_inb(unsigned long port)
>>>+{
>>>+ return (u8)readb((void __iomem *)port);
>>>+}
>>>+static void mm_outb(u8 value, unsigned long port)
>>>+{
>>>+ writeb(value, (void __iomem *)port);
>>>+}
>>>+static void mm_tf_load(ide_drive_t *drive, ide_task_t *task)
>>>+{
>>>
>>[...]
>>>+ if (task->tf_flags & IDE_TFLAG_OUT_DEVICE) {
>>>+ unsigned long base = TX4939IDE_BASE(hwif);
>>>+ mm_outb((tf->device & HIHI) | drive->select,
>>>+ io_ports->device_addr);
>> I'm seeing no sense in re-defining so far...
>>>+ /* Fix ATA100 CORE System Control Register */
>>>+ TX4939IDE_writew(TX4939IDE_readw(base, Sys_Ctl) & 0x07f0,
>>>+ base, Sys_Ctl);
>> Ah... you're doing it here (but not in LE mode?). I think to avoid
>>duplicating ide_tf_load() you need ot use selectproc().
> Oh, my fault. LE mode also needs this fix. I still need ide_tf_load
> on BE mode to support IDE_TFLAG_OUT_DATA.
Yeah, that totally useless flag...
>>>+static void mm_insw_swap(unsigned long port, void *addr, u32 count)
>>>+{
>>>+ unsigned short *ptr = addr;
>>>+ unsigned long size = count * 2;
>>>+ port &= ~1;
>>>+ while (count--)
>>>+ *ptr++ = le16_to_cpu(__raw_readw((void __iomem *)port));
>>>+ __ide_flush_dcache_range((unsigned long)addr, size);
>> Why is this needed BTW?
> Do you mean __ide_flush_dcache_range? This is needed to avoid cache
> inconsistency on PIO drive. PIO transfer only writes to cache but
> upper layers expects the data is in main memory.
Hum, then I wonder why it's MIPS specific...
>>>+static const struct ide_tp_ops tx4939ide_tp_ops = {
>>>+ .exec_command = ide_exec_command,
>>>+ .read_status = ide_read_status,
>>>+ .read_altstatus = ide_read_altstatus,
>>>+ .read_sff_dma_status = tx4939ide_read_sff_dma_status,
>> Hum, it should be re-defined in both LE and BE mode (but actually not
>>called anyway).
> What do you mean? Please elaborate?
I mean that in LE mode you're using ide_read_sff_dma_status() but not
setting hwif->dma_base, so it won't work. But since it shouldn't be called in
this driver's case, this doesn't hurt.
MBR, Sergei
next prev parent reply other threads:[~2008-09-12 15:33 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-09 16:08 [PATCH 1/2] ide: Add tx4939ide driver Atsushi Nemoto
2008-09-09 16:44 ` Alan Cox
2008-09-09 17:08 ` Sergei Shtylyov
2008-09-10 15:12 ` Atsushi Nemoto
2008-09-10 15:06 ` Atsushi Nemoto
2008-09-13 13:37 ` Atsushi Nemoto
2008-09-09 17:50 ` Sergei Shtylyov
2008-09-10 15:32 ` Atsushi Nemoto
2008-09-10 15:55 ` Sergei Shtylyov
2008-09-10 16:25 ` Sergei Shtylyov
2008-09-11 15:03 ` Atsushi Nemoto
2008-09-11 15:18 ` Sergei Shtylyov
2008-09-10 23:02 ` Sergei Shtylyov
2008-09-11 15:52 ` Atsushi Nemoto
2008-09-12 15:34 ` Sergei Shtylyov [this message]
2008-09-12 15:59 ` Atsushi Nemoto
2008-09-12 16:44 ` Sergei Shtylyov
2008-09-12 17:19 ` Sergei Shtylyov
2008-09-13 12:32 ` Atsushi Nemoto
2008-09-16 21:15 ` Sergei Shtylyov
2008-09-16 21:39 ` Sergei Shtylyov
2008-09-27 16:19 ` Bartlomiej Zolnierkiewicz
2008-09-27 22:09 ` Tejun Heo
2008-09-30 13:07 ` Atsushi Nemoto
2008-09-30 15:09 ` James Bottomley
2008-10-04 2:56 ` Tejun Heo
2008-10-07 12:09 ` Jens Axboe
2008-09-28 8:41 ` Ralf Baechle
2008-09-11 22:33 ` Sergei Shtylyov
2008-09-12 14:37 ` Atsushi Nemoto
2008-09-12 15:01 ` Sergei Shtylyov
2008-09-13 21:48 ` Sergei Shtylyov
2008-09-14 13:05 ` Atsushi Nemoto
2008-09-16 10:29 ` Sergei Shtylyov
2008-09-16 15:20 ` Atsushi Nemoto
2008-09-16 15:32 ` Sergei Shtylyov
2008-09-16 16:24 ` Sergei Shtylyov
2008-09-16 21:02 ` Sergei Shtylyov
2008-09-14 20:55 ` Sergei Shtylyov
2008-09-15 14:01 ` Atsushi Nemoto
2008-09-16 21:59 ` Sergei Shtylyov
2008-09-17 15:12 ` Atsushi Nemoto
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48CA8BEE.1090305@ru.mvista.com \
--to=sshtylyov@ru.mvista.com \
--cc=anemo@mba.ocn.ne.jp \
--cc=bzolnier@gmail.com \
--cc=linux-ide@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=ralf@linux-mips.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).