linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Daney <ddaney@caviumnetworks.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: linux-ide@vger.kernel.org, linux-mips <linux-mips@linux-mips.org>
Subject: Re: [PATCH] ide: New libata driver for OCTEON SOC Compact Flash interface.
Date: Fri, 21 Nov 2008 09:05:46 -0800	[thread overview]
Message-ID: <4926EA6A.7040704@caviumnetworks.com> (raw)
In-Reply-To: <20081121102137.634616c5@lxorguk.ukuu.org.uk>

Alan Cox wrote:
>> + * Called to enable the use of DMA based on kernel command line.
>> + */
>> +void octeon_cf_enable_dma(void)
>> +{
>> +	use_cf_dma = 1;
>> +}
> 
> Why not use the standard module parameter interface ?
> 

I will do that.

> 
>> +	/*
>> +	 * PIO modes 0-4 all allow the device to deassert IORDY to slow down
>> +	 * the host.
>> +	 */
> 
> See ata_timing_compute() which also knows about master/slave timing,
> PIO5/6 rules and timing adjustments as well as doing bus clock
> quantisations and lengthenings for you.
> 

OK.

>> +	use_iordy = 1;
> 
> This depends on the device as well and gets quite complicated. We have
> ata_pio_need_iordy() to do the work for you.
> 
>> +	t1 = (t1 * clocks_us) / 1000 / 2;
>> +	if (t1)
>> +		t1--;
> 
> Even if you wanted to do it this way you could just use arrays and lookup
> tables as many other drivers do - ie
> 
> 	pio = dev->pio_mode - XFER_PIO_0;
> 	t1 = data[pio];
> 

The timing calculations are based on the CPU clock rate, It is difficult 
to encapsulate that in a table.

[...]
>> +	/*
>> +	 * Odd lengths are not supported. We should always be a
>> +	 * multiple of 512.
>> +	 */
>> +	BUG_ON(buflen & 1);
> 
> If you get a request for an odd length you should write an extra word
> containing the last byte and one other. See how the standard methods
> handle this.
> 

OK.

> 
>> +	if (ocd->is16bit) {
> 
> Or you could have two methods and two transfer routines defined
> 

Good idea.

>> +			while (words--) {
>> +				*(uint16_t *)buffer = ioread16(data_addr);
>> +				buffer += sizeof(uint16_t);
> 
> By definition tht is 2. Do you have an ioread16_rep ?
> 

It appears to be broken.  One would expect ioread16 and ioread16_rep to 
do endian swapping in the same manner.  On MIPS they do not.  Perhaps it 
would be better to fix the problem at the source.

> 
>> +
>> +/**
>> + * Get ready for a dma operation.  We do nothing, as all DMA
>> + * operations are taken care of in octeon_cf_bmdma_start.
>> + */
>> +void octeon_cf_qc_prep(struct ata_queued_cmd *qc)
>> +{
>> +}
> 
> ata_noop_qc_prep
> 

OK.

> 
>> +/**
>> + * Check if any queued commands have more DMAs, if so start the next
>> + * transfer, else do standard handling.
>> + */
>> +irqreturn_t octeon_cf_interrupt(int irq, void *dev_instance)
> 
> A lot of these functions could be static it seems

An oversight on my part.  I will make them all static.

> 
>> +static void octeon_cf_delayed_irq(unsigned long data)
>> +{
> 
> What stops the following occuring
> 
> 	ATA irq
> 		BUSY still set
> 		Queue tasklet
> 
> 	Other irq on same line
> 	ATA busy clear
> 		Handle command
> 
> 	Tasklet runs but command was sorted out
> 
> (or a reset of the ata controller in the gap)
> 

Probably nothing.  I will try to sort it out.


>> +	base = cs0 + ocd->base_region_bias;
>> +	if (!ocd->is16bit) {
> 
> 	ata_std_
>> +		ap->ioaddr.cmd_addr	= base + ATA_REG_CMD;
> 
> ata_sff_std_ports ? (at least for the 8bit case)
> 

OK.

Thanks,

David Daney



  reply	other threads:[~2008-11-21 17:06 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-21  2:24 [PATCH] ide: New libata driver for OCTEON SOC Compact Flash interface David Daney
2008-11-21 10:21 ` Alan Cox
2008-11-21 17:05   ` David Daney [this message]
2008-11-21 17:26     ` Sergei Shtylyov
2008-11-21 17:47       ` David Daney
2008-11-21 18:07       ` Alan Cox
2008-11-21 17:49     ` Alan Cox
2008-11-21 16:40 ` Sergei Shtylyov
2008-11-21 17:29   ` David Daney
2008-11-21 18:14     ` Sergei Shtylyov
2008-11-21 18:43       ` Chad Reese
2008-11-21 17:46   ` Alan Cox
2008-11-21 17:37 ` Sergei Shtylyov
2008-11-21 18:12   ` Alan Cox
2008-11-22 13:57 ` Sergei Shtylyov
2008-11-22 14:52   ` Alan Cox
2008-11-22 15:05     ` Sergei Shtylyov
2008-11-23 17:14       ` Sergei Shtylyov
2008-11-24 20:40     ` David Daney
2008-11-24 22:33       ` Sergei Shtylyov
2008-11-22 15:13   ` Sergei Shtylyov
2008-11-22 18:38     ` Chad Reese
2008-11-23 15:13       ` Sergei Shtylyov
2008-11-23 15:24         ` Sergei Shtylyov
2008-11-23 17:10           ` Sergei Shtylyov
2008-11-23 17:32     ` Sergei Shtylyov

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=4926EA6A.7040704@caviumnetworks.com \
    --to=ddaney@caviumnetworks.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-mips@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).