linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
To: Michael Schmitz <schmitzmic@gmail.com>
Cc: Tejun Heo <tj@kernel.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	linux-ide@vger.kernel.org,
	Linux/m68k <linux-m68k@vger.kernel.org>,
	Linux Kernel Development <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/3] ata: add m68k/Atari Falcon PATA support
Date: Tue, 10 Jan 2017 13:53:53 +0100	[thread overview]
Message-ID: <3939493.HXZ6C33pKV@amdc3058> (raw)
In-Reply-To: <CAOmrzkJP6s34DPOHd4OFFx=CXko35Kt=CfeDZthOPvKDJy-9YA@mail.gmail.com>


Hi,

On Friday, January 06, 2017 10:01:49 AM Michael Schmitz wrote:
> Hi Bartlomiej,
> 
> thanks for caring to support our legacy PATA systems!
> 
> On Sat, Dec 31, 2016 at 3:01 AM, Bartlomiej Zolnierkiewicz
> <b.zolnierkie@samsung.com> wrote:
> > Hi,
> >
> > This patchset adds m68k/Atari Falcon PATA support to libata.
> > The major difference in the new libata's pata_falcon host
> > driver when compared to legacy IDE's falconide host driver is
> > that we are using polled PIO mode and thus avoiding the need
> > for STDMA locking magic altogether.
> 
> I don't suppose this is the default libata mode for PIO?

No, by default it is used only for some commands (i.e. IDENTIFY,
SET FEATURES - XFER MODE).

> How is polling implemented in libata? Sleeping for something
> approximating the average seek latency shouldn't hurt but spinning
> wont be acceptable for a low performance single CPU architecture like
> the Falcon.

You can find actual implementation in libata-sff.c.

Please see ata_sff_pio_task() for the main polling logic:

fsm_start:
	WARN_ON_ONCE(ap->hsm_task_state == HSM_ST_IDLE);

	/*
	 * This is purely heuristic.  This is a fast path.
	 * Sometimes when we enter, BSY will be cleared in
	 * a chk-status or two.  If not, the drive is probably seeking
	 * or something.  Snooze for a couple msecs, then
	 * chk-status again.  If still busy, queue delayed work.
	 */
	status = ata_sff_busy_wait(ap, ATA_BUSY, 5);
	if (status & ATA_BUSY) {
		spin_unlock_irq(ap->lock);
		ata_msleep(ap, 2);
		spin_lock_irq(ap->lock);

		status = ata_sff_busy_wait(ap, ATA_BUSY, 10);
		if (status & ATA_BUSY) {
			ata_sff_queue_pio_task(link, ATA_SHORT_PAUSE);
			goto out_unlock;
		}
	}

	/*
	 * hsm_move() may trigger another command to be processed.
	 * clean the link beforehand.
	 */
	ap->sff_pio_task_link = NULL;
	/* move the HSM */
	poll_next = ata_sff_hsm_move(ap, qc, status, 1);

	/* another command or interrupt handler
	 * may be running at this point.
	 */
	if (poll_next)
		goto fsm_start;
out_unlock:


ata_sff_busy_wait()'s last argument is number of 10uS waits so
first check (50uS) should be quite quick.  If device is still
busy we sleep for 2ms.  Then we quickly (100uS) busy wait and
if needed  queue delayed work (with ATA_SHORT_PAUSE == 16 ms
delay).

Overall the current heuristic looks fine and spinning should be
minimal.

> > Tested under ARAnyM emulator.
> 
> Not sure that the emulator is really feature complete enough - I'll
> get this tested on my Falcon in the next few weeks. I'm a bit worried

Great!

> about IDE still generating interrupts on seek completion (did you spot
> anything like that, Geert?).
> 
> Cheers,
> 
>   Michael

BTW according to comment in arch/m68k/atari/stdma.c:

/* On the Falcon, the IDE bus uses just the ACSI/Floppy interrupt, but */
/* not the ST-DMA chip itself. So falhd.c needs not to lock the        */
/* chip. The interrupt is routed to falhd.c if IDE is configured, the  */
/* model is a Falcon and the interrupt was caused by the HD controller */
/* (can be determined by looking at its status register).              */

it should be okay to use IDE at the same time as SCSI/Floppy which
is what the new driver does (the old one is serialized operations by
ST-DMA related IRQ handling magic).

Also the comment itself may need some fixups as on Falcon it is SCSI
not ACSI (according to the earlier comment in same file) and the old
IDE host driver name is not falhd.c but falconide.c.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

  reply	other threads:[~2017-01-10 12:54 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20161230140139epcas5p160eda5a6a77be084e21f12002c85cc2a@epcas5p1.samsung.com>
2016-12-30 14:01 ` [PATCH 0/3] ata: add m68k/Atari Falcon PATA support Bartlomiej Zolnierkiewicz
     [not found]   ` <CGME20161230140141epcas5p161d9467e10e294f502863b5347e351d5@epcas5p1.samsung.com>
2016-12-30 14:01     ` [PATCH 1/3] ata: allow subsystem to be used on m68k arch Bartlomiej Zolnierkiewicz
2016-12-30 14:12       ` Christoph Hellwig
     [not found]         ` <CGME20161230171438epcas1p3c1d8ea8e4c77d796b81f7130c5e61d3f@epcas1p3.samsung.com>
2016-12-30 17:14           ` Bartlomiej Zolnierkiewicz
2017-01-08 10:08             ` Christoph Hellwig
     [not found]               ` <CGME20170109160128epcas1p36a0a8f79b32e5024ffa480fd848e3a79@epcas1p3.samsung.com>
2017-01-09 16:01                 ` Bartlomiej Zolnierkiewicz
2017-01-09 16:15       ` Geert Uytterhoeven
     [not found]   ` <CGME20161230140144epcas1p2ada13244f4ba5b45ed903ab7d614f6db@epcas1p2.samsung.com>
2016-12-30 14:01     ` [PATCH 2/3] ata: pass queued command to ->sff_data_xfer method Bartlomiej Zolnierkiewicz
     [not found]   ` <CGME20161230140147epcas5p1fa7e99f39921a8ee90aabd59ff7b7645@epcas5p1.samsung.com>
2016-12-30 14:01     ` [PATCH 3/3] ata: add Atari Falcon PATA controller driver Bartlomiej Zolnierkiewicz
2017-01-03 10:49   ` [PATCH 0/3] ata: add m68k/Atari Falcon PATA support Geert Uytterhoeven
2017-01-09 16:11     ` Bartlomiej Zolnierkiewicz
2017-01-10 16:09       ` Tejun Heo
2017-01-05 21:01   ` Michael Schmitz
2017-01-10 12:53     ` Bartlomiej Zolnierkiewicz [this message]
2017-01-10 20:02       ` Michael Schmitz
2017-01-13  2:33         ` Finn Thain
2017-01-14  8:55           ` Michael Schmitz
2017-01-14 23:47             ` Finn Thain
2017-01-15  1:48               ` Michael Schmitz
2017-01-15  4:42                 ` Finn Thain
2017-01-20  7:49                   ` Michael Schmitz
2017-01-21  7:37                     ` Finn Thain
2017-01-23  8:04                       ` Michael Schmitz
2017-01-26  8:47                         ` Finn Thain
2017-01-26  9:03                           ` Geert Uytterhoeven
2017-01-27  1:41                             ` Finn Thain
2017-01-27  4:28                           ` Michael Schmitz
2017-02-01  8:40                             ` Finn Thain
2017-02-01  8:45                               ` Geert Uytterhoeven
2017-02-02  7:48                               ` Michael Schmitz
2017-01-10 16:11   ` Tejun Heo
2017-02-15  8:45   ` Geert Uytterhoeven
2017-02-20 18:15     ` Bartlomiej Zolnierkiewicz
2017-02-21 22:18       ` Tejun Heo

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=3939493.HXZ6C33pKV@amdc3058 \
    --to=b.zolnierkie@samsung.com \
    --cc=geert@linux-m68k.org \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-m68k@vger.kernel.org \
    --cc=schmitzmic@gmail.com \
    --cc=tj@kernel.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).