All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Schmitz <schmitzmic@googlemail.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Michael Schmitz <schmitzmic@googlemail.com>,
	Thorsten Glaser <tg@mirbsd.de>,
	linux-m68k@vger.kernel.org
Subject: Re: Atari ROM port ISA
Date: Sun, 22 Apr 2012 22:36:45 +1200	[thread overview]
Message-ID: <4F93DF3D.5050402@gmail.com> (raw)
In-Reply-To: <CAMuHMdW6tYbn6aW46x9yDiG7hptjSPz9gGDhS=n7bBTs7=pLkA@mail.gmail.com>

Geert,
> On Sat, Apr 21, 2012 at 10:20, Geert Uytterhoeven<geert@linux-m68k.org>  wrote:
>>> I've had a look at the NetUSBee docs and see that the USB part of it does
>>> require 8 bit writes but little endian 16 bit reads. So we will need to
>>> retain the 16 bit reads for potential USB support there.
>> OK. But you ain't gonna get the right 16 bits using
>>
>> #define rom_in_be16(addr) \
>>         ({ u16 __v = (*(__force volatile u16 *) (addr)); __v>>= 8; __v; })
>> #define rom_in_le16(addr) \
>>         ({ u16 __v = le16_to_cpu(*(__force volatile u16 *) (addr));
>> __v>>= 8; __v; })
>>
>> as they both do a 16-bit read and shift the result.
>> Perhaps it should just be a 32-bit read instead?
Correct - the 16 bit read should not do any shifts instead.
>> Are the schematics publicly available?
> I found netusbee.zip.
> Unfortunately I (my computer) can't grok the schematics files.
Same here - I'm sure software to read these is available somewhere. I 
did not look closely though.
> However, program_spec.txt says (a.o., I encourage all interested
> parties to read it in full):
DId that ...
> | USB Data Reads
> | ==============
> |
> | Data Reads from USB are done at base address 0xFA8000 (activating a read
> | cycle) as a 16bit word.  Data appears on D8-15 as most significant byte, and
> | D0-7 as least significant byte.  Notice how A15 has to be set to 1 to make it
> | a USB cycle.
>
> So inw() should just do a 16-bit big-endian read.
You're right - I got my big vs. little endian mixed up. The ISP1160 
driver is a little-endian beast but the byte swap has been done in 
hardware here if I read the paragraph right.
> | USB Data Writes
> | ===============
> |
> | Data reads at base address 0xFB8000 actually cause data to be written.  As
> | the write interface is only 8 bits wide, the 16bits of data must be passed
> | through this "8 bit window".  The Least Signifant Byte is transferred first
> | by left shifting data once and added to 0xFA8000.  This is followed by the
> | Most significant byte, transferred by left shifting data once and then added
> | to 0xFB8000.  On this last cycle is where the transfer is actually done.
> | Notice how A15 has to be set to 1 to make it a USB cycle.
>
> So outw() should do 2 byte reads.
Correct again  - the A15 we can implement via the address field itself 
(just as the USB command vs. data cycle on A14). The ISP1160 driver has 
provisions to use two 8-bit writes in place of a 16 bit one but it might 
be cleaner to implement the 16 bit write the way the USB driver needs it.

Now - does anyone here on this list or on debian-68k own such hardware 
and would be in a position to test a USB driver written to this spec? Is 
the hardware still for sale?
(Not that I am at all sure whether the ISP1160 driver will run in a 
timer polled mode at all ...)

Cheers,

   Michael

  reply	other threads:[~2012-04-22  2:41 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-15  9:34 Atari ROM port ISA Geert Uytterhoeven
2012-04-16  7:50 ` Michael Schmitz
2012-04-16  9:09   ` Andreas Schwab
2012-04-16  9:42   ` Geert Uytterhoeven
2012-04-16 20:21     ` Michael Schmitz
2012-04-17  5:05   ` Brad Boyer
2012-04-19 15:00     ` Thorsten Glaser
2012-04-19 20:38       ` Michael Schmitz
2012-04-19 20:43         ` Thorsten Glaser
2012-04-21 15:44           ` Michael Schmitz
2012-04-21  8:20             ` Geert Uytterhoeven
2012-04-21 19:39               ` Geert Uytterhoeven
2012-04-22 10:36                 ` Michael Schmitz [this message]
2012-05-13 10:33                   ` David Gálvez
2012-05-13 23:27                     ` Michael Schmitz
2012-05-14 11:17                       ` David Gálvez
2012-05-17  6:10                       ` David Gálvez
2012-05-17  6:51                         ` Michael Schmitz

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=4F93DF3D.5050402@gmail.com \
    --to=schmitzmic@googlemail.com \
    --cc=geert@linux-m68k.org \
    --cc=linux-m68k@vger.kernel.org \
    --cc=tg@mirbsd.de \
    /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.