Hi Finn, Geert,
+ /* We are passed DMA addresses i.e. physical addresses, but must use
+ * kernel virtual addresses here, so remap to virtual. This is easy
+ * enough for the case of residual bytes of an extended message in
+ * transfer - we know the address must be esp->command_block_dma.
+ * In other cases, hope that phys_to_virt() works ...
+ */
+ if (addr == esp->command_block_dma)
+ addr = (u32) esp->command_block;
+ else
+ addr = (u32) phys_to_virt(addr);
To avoid having a need for phys_to_virt(), you should remember the
addresses passed to/returned from dma_map_*().
Interesting - can we be certain that only one mapping is being used at
any one time?
Tests have revealed that we can't rely on a single mapping active at any
one time (it's rare, but I get some messages printed when I log
zorro_esp_map_single() being called with a mapping already saved).
I don't know how Geert's suggestion would work in this case. But I think
I suppose storing the virtual address in the driver private data struct,
and looking up that stored virtual address in the PIO transfer function.
we covered this problem back in December:
https://marc.info/?l=linux-m68k&m=151365452606870
(That thread also helps explain the PIO vs. ESP_CMD_SELAS issue.)
Yes, rereading that thread now suggests we had explored a few options
but the issue of autosense commands was making it a little too complicated.
We have no need to find out the correct virtual address for a given DMA
mapping as long as we only use PIO for message byte transfer. I'll leave
finding a proper solution for a rainy day (or rather, a few rainy
weeks). Anyone familiar with Auckland will know what that means :-)
Cheers,
Michael
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
