Re: [PATCH RFC 1/2] m68k: io_mm.h: conditionalize ISA address translation on Atari

[Michael Schmitz <schmitzmic@gmail.com>]

Hi Brad,

Am 05.06.2021 um 10:49 schrieb Brad Boyer:
> On Fri, Jun 04, 2021 at 07:30:00PM +1200, Michael Schmitz wrote:
>>>> I'm still unsure whether changing the default branch for the sake of
>>>> fixing Atari behaviour is a sane idea - I was hoping for comments either
>>>> way.
>>>>
>>>
>>> You mean, what happens if a random m68k platform (other than amiga, atari
>>> and q40) were to adopt CONFIG_ISA? I guess it would be nice if that would
>>> 'just work' but it's probably never going to be needed.
>>
>> The NULL default was meant to catch incorrect use of config options related
>> to CONFIG_ISA. My repurposing the default branch for Atari's needs (no
>> translation for IDE) defeats that. But the chance that we run into such
>> incorrect use in the future are pretty slim indeed.
>
> Well, we could in theory add a trex socket driver to get PCMCIA support
> for the PowerBook 190 hardware. There was a driver for that in ppc for
> the PowerBook 5300 which uses the same chipset. I believe the PCMCIA
> drivers use these same macros in spite of not being considered ISA.

Correct - the PCMCIA device drivers use IO port addresses in the ISA 
port range.

> I don't see anything in drivers/pcmcia that is obviously an m68k
> system even though I'm pretty sure I remember discussions of supporting
> such hardware in the past.

There's the APNE driver (Amiga PCMCIA NE2000 clone), which is already 
catered for by the current code in io_mm.h. I remember seeing patches 
for that driver that would allow support of a variant of the APNE card 
that were hard to integrate in the current NE clone code framework. 
Didn't consider adding another isa_type for that card at the time - I'll 
revisit these patches if I can find them again.

Supporting PB190 PCMCIA hardware requires adding a new isa_type and the 
corresponding IO translation cases. Not much more, for all I can see. 
Existing chipset drivers from other architectures ought to work already. 
Maybe add a specific block_input() hook as for APNE (but I surmise that 
might just be code duplication from generic code in lib8390.c - didn't 
check).

Not sure what card socket code the APNE driver uses - must be one of the 
generic variants from drivers/pcmcia. If your PB190 needs something not 
already in there, we'd need to add that as well.

> Is PCMCIA support something we should also consider in all of this?

Absolutely.

Cheers,

	Michael


>
> 	Brad Boyer
> 	flar@allandria.com
>