Damien Douxchamps wrote:
> Isn't all this leading to the fact that we must interpret the ROM while
> we read it, instead of just grabbing all the ROM at once?
Alas there doesn't seem to be a single strategy that yields the very
best performance with all existing cameras. Especially if
bus_info_block.max_rom == 0, you can only guess to which extent block
reads might work.
The ieee1394 driver does interpret the config ROM while reading it. It
tries to read it in chunks up to the size indicated by max_rom and falls
back to quadlet reads if it encounters any problems. I don't think we
honor the alignment restriction of block reads in case of max_rom == 1.
The firewire-core driver also interprets the config ROM while reading.
But it always only reads quadlets. The cost to do so is lower than with
ieee1394 because of gap count optimization, at least on 1394a only
buses. (1394b Beta only buses already have a low arbitration overhead;
only the transaction overhead of the hardware/ firmware/ OS remain.
Mixed 1394a and 1394b buses would profit from gap count optimization but
we don't do it if 1394b PHYs act as repeaters, because then it becomes
hard to figure out a suitable gap count.)
In addition, firewire-core exposes its config ROM cache to userspace in
/sys/devices/*/fw*/config_rom. This cache is an array of uint32_t, with
all the quadlets converted to CPU byte order. But I don't know if this
sysfs file can be recommended as interface for userspace applications
besides low-level software like udev and hald.
Note, if you are keen on getting also config ROM contents which are
located outside the 400...7ff range, you (a) have to interpret the ROM
and (b) can't entirely rely on firewire-core's config ROM cache.
(Firewire-core only looks into the 400...7ff range.) However, I don't
know if there are any IIDC devices out there with config ROM outside
that range. It seems unlikely.
-=====-=-=== ==-- ===-=