I was revisiting this in my mind:
2009/5/20 Ben Dooks <ben-linux@xxxxxxxxx>:
> On Tue, May 19, 2009 at 04:36:50PM +0200, Linus Walleij wrote:
(...)
>> +/*
>> + * Here we define all the platform devices that appear
>> + * as children of the AB3100. These are regular platform
>> + * devices with the IORESOURCE_IO .start and .end set
>> + * to correspond to the internal AB3100 register range
>> + * mapping to the corresponding subdevice.
>> + */
>> +
>> +#define AB3100_DEVICE(devname, devid, regstart, regend) \
>> +static struct resource ab3100_##devname##_resource[] = { \
>> + { \
>> + .start = regstart, \
>> + .end = regend, \
>> + .flags = IORESOURCE_IO, \
>> + } \
>
> is IORESOURCE_IO a good idea here, we may need to add some form of
> flag to say 'generic data' and for the driver core to not try and
> register it with any of the ioport or iomem structures.
I face the issue of adding sub-drivers to the AB3100 which will likely
be the same for other chips in the same series, so that say
drivers/rtc-ab3100.c will be used for all AB3xxx chips.
Register X thru X+size-1 (maps to .start and .end) will be
used for a certain subdevice.
So naturally I want these drivers to be relative to some base I2C
register adress and this needs to be passed down as a resource.
(Each I2C device has max 256 registers only for natural resons,
but may still contain several functions.)
Type, as defined in ioport.h is only four unique bits and all four
are taken:
#define IORESOURCE_TYPE_BITS 0x00000f00 /* Resource type */
#define IORESOURCE_IO 0x00000100
#define IORESOURCE_MEM 0x00000200
#define IORESOURCE_IRQ 0x00000400
#define IORESOURCE_DMA 0x00000800
(Pretty generic.)
There is no space for any IORESOURCE_GENERIC or so.
So putting in a resource of type IORESOURCE_IO is still the
best thing I can think of here, any other suggestions?
(I can think of kludgy things like using the bus-specific bits 7-0.)
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
