LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Kristian Høgsberg" <krh@bitplanet.net>
To: "Philipp Beyer" <philipp.beyer@alliedvisiontec.com>
Cc: "Stefan Richter" <stefanr@s5r6.in-berlin.de>,
	linux1394-devel@lists.sourceforge.net,
	linux-kernel@vger.kernel.org
Subject: Re: ieee1394 feature needed: overwrite SPLIT_TIMEOUT from userspace
Date: Mon, 15 Jan 2007 13:54:52 -0500	[thread overview]
Message-ID: <59ad55d30701151054j48831ca1v96f2700dccd4d512@mail.gmail.com> (raw)
In-Reply-To: <1168867271.5190.9.camel@ahr-pbe-lx.avtnet.local>

On 1/15/07, Philipp Beyer <philipp.beyer@alliedvisiontec.com> wrote:
>
> Thanks for your input. My post was based on the (wrong) idea that
> the kernel already uses different timeout values per node.
>
> Therefore, having read your answer, I have a different opinion about
> how to solve this now.
>
> About your suggestions:
> Unfortunately sending an early response and using a secondary register
> as indication for completed flash writes doesnt work. In short, the
> device isn't able to process packets while writing to flash and an early
> answer followed by a period of non-responsiveness might lead to problems
> on the windows side.
>
> Also I dont like the idea of having such a big timeout for every bus
> transaction. In case of 'normal' operation the device runs fine with
> a standard timeout value.

I read the thread briefly, so I may be off here, but another solution
is to implement an FCP-style protocol.  That is, instead of trying to
cram a long operation into the SPLIT_TIMEOUT window, just use two
write transactions to device specific address areas: one for the
request from the PC and one for the response from the device.  Or you
could even use a vendor specific FCP frame.

If you use unified transactions (i.e. your devices sends ACK_COMPLETE
when it receives the write) it doesn't even generate more traffic on
the bus.  And since the device will send the response write request
once it has completed programming the flash, it doesn't need to
respond to packets while it is programming.  But even if the write
transactions themselves are split transactions, it is still a low
overheads solution to your problem that avoids messing with
SPLIT_TIMEOUT.

cheers,
Kristian

      parent reply	other threads:[~2007-01-15 18:54 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-12 11:42 Philipp Beyer
2007-01-13 18:15 ` Stefan Richter
2007-01-15 13:21   ` Philipp Beyer
2007-01-15 14:06     ` Stefan Richter
2007-01-15 14:54       ` Philipp Beyer
2007-01-15 18:30         ` Stefan Richter
2007-01-15 18:54     ` Kristian Høgsberg [this message]

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=59ad55d30701151054j48831ca1v96f2700dccd4d512@mail.gmail.com \
    --to=krh@bitplanet.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux1394-devel@lists.sourceforge.net \
    --cc=philipp.beyer@alliedvisiontec.com \
    --cc=stefanr@s5r6.in-berlin.de \
    --subject='Re: ieee1394 feature needed: overwrite SPLIT_TIMEOUT from userspace' \
    /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

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).