This *should* only add support. If I were to do this now, I'd detect the
chip rev and branch accordingly. That would only apply the additional IO
to chips that require the extra setup. The next step would be to try to
do the initialization IO only once, then just do the connect/disconnect
as needed.
In any case, being an Imation geek, I only had Imation hardware to test
with. I had positive results using a c8 and c6 chip. I've got a tape
backup that also uses epat but i've been pokey about trying it out with
that. In short, I haven't heard of of the c7|c8 patch breaking the earlier
chips. Anyone else who has seen something different should speak up
because AFAIK, it works fine.
Also, it's probably preferrable to keep it an option (default to no) for
the standard epat given the IO penalty. There's no reason to turn it on
unless it's actually needed.
Josh Jore
On Thu, 3 May 2001, Tim Waugh wrote:
> On Fri, Apr 27, 2001 at 09:53:32AM -0500, Joshua Jore wrote:
>
> > You may want to try applying the patch at
> > http://moomonk.timelords.org/epat. It adds support for the c7/c8 revs of
> > the epat chip at a slight IO penalty.
>
> Incidentally, the reason this isn't in the mainstream kernel yet is
> that I was unable to convince myself that the added c7/c8
> functionality was in addition to the pre-existing protocol stuff,
> rather than just being a toggle between the two types.
>
> In other words, if you enable C7/C8 support, do you lose any support
> or just gain support?
>
> Tim.
> */
>
-- To unsubscribe, send mail to: linux-parport-request@torque.net --
-- with the single word "unsubscribe" in the body of the message. --
This archive was generated by hypermail 2b29 : Fri May 04 2001 - 16:44:16 EDT