public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* Re: Add skeleton "generic IO mapping" infrastructure.
       [not found] <200409132206.i8DM6dSC030620@hera.kernel.org>
@ 2004-09-14  8:55 ` David Woodhouse
  2004-09-14 14:30   ` Jeff Garzik
  0 siblings, 1 reply; 4+ messages in thread
From: David Woodhouse @ 2004-09-14  8:55 UTC (permalink / raw)
  To: Linux Kernel Mailing List; +Cc: jgarzik

On Mon, 2004-09-13 at 18:32 +0000, Linux Kernel Mailing List wrote:
> ChangeSet 1.1869, 2004/09/13 11:32:00-07:00, torvalds@ppc970.osdl.org
> 
> 	Add skeleton "generic IO mapping" infrastructure.
> 	
> 	Jeff wants to use this to clean up SATA and some network drivers.


> + * Read/write from/to an (offsettable) iomem cookie. It might be a PIO
> + * access or a MMIO access, these functions don't care. The info is
> + * encoded in the hardware mapping set up by the mapping functions
> + * (or the cookie itself, depending on implementation and hw).
> + *
> + * The generic routines don't assume any hardware mappings, and just
> + * encode the PIO/MMIO as part of the cookie. They coldly assume that
> + * the MMIO IO mappings are not in the low address range.
> + *
> + * Architectures for which this is not true can't use this generic
> + * implementation and should do their own copy.
> + *
> + * We encode the physical PIO addresses (0-0xffff) into the
> + * pointer by offsetting them with a constant (0x10000) and
> + * assuming that all the low addresses are always PIO. That means
> + * we can do some sanity checks on the low bits, and don't
> + * need to just take things for granted.
> + */
> +#define PIO_OFFSET	0x10000
> +#define PIO_MASK	0x0ffff
> +#define PIO_RESERVED	0x40000

> +#define IO_COND(addr, is_pio, is_mmio) do {			\
> +	unsigned long port = (unsigned long __force)addr;	\
> +	if (port < PIO_RESERVED) {				\
> +		VERIFY_PIO(port);				\
> +		port &= PIO_MASK;				\
> +		is_pio;						\
> +	} else {						\
> +		is_mmio;					\
> +	}							\
> +} while (0)

Argh! Please no. You can't infer the IO space from the address. Provide
a cookie containing {space, address} instead -- or indeed {bus,
address}. Let some architectures optimise that by ignoring the bus and
working it out from the address if you must, but don't put that in the
generic version.

-- 
dwmw2



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Add skeleton "generic IO mapping" infrastructure.
  2004-09-14  8:55 ` Add skeleton "generic IO mapping" infrastructure David Woodhouse
@ 2004-09-14 14:30   ` Jeff Garzik
  2004-09-14 14:33     ` David Woodhouse
  0 siblings, 1 reply; 4+ messages in thread
From: Jeff Garzik @ 2004-09-14 14:30 UTC (permalink / raw)
  To: David Woodhouse; +Cc: Linux Kernel Mailing List

David Woodhouse wrote:
> On Mon, 2004-09-13 at 18:32 +0000, Linux Kernel Mailing List wrote:
> 
>>ChangeSet 1.1869, 2004/09/13 11:32:00-07:00, torvalds@ppc970.osdl.org
>>
>>	Add skeleton "generic IO mapping" infrastructure.
>>	
>>	Jeff wants to use this to clean up SATA and some network drivers.
> 
> 
> 
>>+ * Read/write from/to an (offsettable) iomem cookie. It might be a PIO
>>+ * access or a MMIO access, these functions don't care. The info is
>>+ * encoded in the hardware mapping set up by the mapping functions
>>+ * (or the cookie itself, depending on implementation and hw).
>>+ *
>>+ * The generic routines don't assume any hardware mappings, and just
>>+ * encode the PIO/MMIO as part of the cookie. They coldly assume that
>>+ * the MMIO IO mappings are not in the low address range.
>>+ *
>>+ * Architectures for which this is not true can't use this generic
>>+ * implementation and should do their own copy.
>>+ *
>>+ * We encode the physical PIO addresses (0-0xffff) into the
>>+ * pointer by offsetting them with a constant (0x10000) and
>>+ * assuming that all the low addresses are always PIO. That means
>>+ * we can do some sanity checks on the low bits, and don't
>>+ * need to just take things for granted.
>>+ */
>>+#define PIO_OFFSET	0x10000
>>+#define PIO_MASK	0x0ffff
>>+#define PIO_RESERVED	0x40000
> 
> 
>>+#define IO_COND(addr, is_pio, is_mmio) do {			\
>>+	unsigned long port = (unsigned long __force)addr;	\
>>+	if (port < PIO_RESERVED) {				\
>>+		VERIFY_PIO(port);				\
>>+		port &= PIO_MASK;				\
>>+		is_pio;						\
>>+	} else {						\
>>+		is_mmio;					\
>>+	}							\
>>+} while (0)
> 
> 
> Argh! Please no. You can't infer the IO space from the address. Provide
> a cookie containing {space, address} instead -- or indeed {bus,
> address}. Let some architectures optimise that by ignoring the bus and
> working it out from the address if you must, but don't put that in the
> generic version.

Override it in your arch if you don't like the generic version ;-)

	Jeff




^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Add skeleton "generic IO mapping" infrastructure.
  2004-09-14 14:30   ` Jeff Garzik
@ 2004-09-14 14:33     ` David Woodhouse
  2004-09-14 15:06       ` Jeff Garzik
  0 siblings, 1 reply; 4+ messages in thread
From: David Woodhouse @ 2004-09-14 14:33 UTC (permalink / raw)
  To: Jeff Garzik; +Cc: Linux Kernel Mailing List

On Tue, 2004-09-14 at 10:30 -0400, Jeff Garzik wrote:
> Override it in your arch if you don't like the generic version ;-)

If you must... but make it take a cookie with enough space to give the
required information -- not just an unsigned long.

-- 
dwmw2


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Add skeleton "generic IO mapping" infrastructure.
  2004-09-14 14:33     ` David Woodhouse
@ 2004-09-14 15:06       ` Jeff Garzik
  0 siblings, 0 replies; 4+ messages in thread
From: Jeff Garzik @ 2004-09-14 15:06 UTC (permalink / raw)
  To: David Woodhouse; +Cc: Linux Kernel Mailing List

David Woodhouse wrote:
> On Tue, 2004-09-14 at 10:30 -0400, Jeff Garzik wrote:
> 
>>Override it in your arch if you don't like the generic version ;-)
> 
> 
> If you must... but make it take a cookie with enough space to give the
> required information -- not just an unsigned long.


If you have (device, address) you should have all you need...

	Jeff



^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2004-09-14 15:07 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <200409132206.i8DM6dSC030620@hera.kernel.org>
2004-09-14  8:55 ` Add skeleton "generic IO mapping" infrastructure David Woodhouse
2004-09-14 14:30   ` Jeff Garzik
2004-09-14 14:33     ` David Woodhouse
2004-09-14 15:06       ` Jeff Garzik

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox