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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.