[linuxsh-dev] Re: Solution Engin's ATA PC-card enabler

[kaz K. <kk...@rr...>]

NIIBE Yutaka writes:
> Let's clarify things.  
>
> #1:
> Is this correct?
> 
>  >  /* SH pcmcia io window base, start and end.  */
>  > -int sh_pcic_io_wbase = 0xb8400000;
>  > -int sh_pcic_io_start;
>  > -int sh_pcic_io_stop;
>  > +int sh_pcic_io_wbase = 0xb8600000;
>  > +int sh_pcic_io_start = 0x3000;
>  > +int sh_pcic_io_stop  = 0x3fff;
> 
> Specifically, io_wbase has been changed.  Does not cause any problem?

The windows of MR-SHPC can be mapped every 1MB-aligned position
in area 6 (0xb8000000-0xbc000000). I'm not sure why Nozawa-san makes
this change, but anyway, it doesn't cause any problem.

I missed one point. Perhaps

> port2adr(unsigned int port)
> {
>-	if (port >= 0x2000)
>+	if (port >= 0x3000)
>+		return (volatile __u16 *)  (PA_MRSHPC_IO + (port - 0x3000));

causes problem by the magic number 0x3000. It's not bad to initialize
sh_pcic_io_start and sh_pcic_io_stop but they will cheaged by PCMCIA
driver like pcmcia-cs. Nozawa-san, you can't handle these variable
as constants.

> #2:
>  > unsigned long inb(unsigned int port)
>  > {
>  > 	if (sh_pcic_io_start <= port && port <= sh_pcic_io_stop)
>  >-		return *(__u8 *) (sh_pcic_io_wbase + 0x40000 + port); 
>  >+		return *(__u8 *) port2adr(port); 
>  > 	else if (shifted_port(port))
> 
> It seems that your comments above means we need this "0x400000" for
> byte access of "read" (in).  Is there any reason why we don't need
> this "0x40000" for "write" (out)?

This chip is odd enough. These four 256KB spaces are exactly same in
write access.

	kaz