On Tue, 6 Mar 2018, Michael Schmitz wrote:
+static void zorro_esp_send_pio_cmd(struct esp *esp, u32 addr, u32 esp_count,
+ u32 dma_count, int write, u8 cmd)
+{
+ struct zorro_esp_priv *zep = ZORRO_ESP_GET_PRIV(esp);
+ u8 __iomem *fifo = esp->regs + ESP_FDATA * 16;
+ u8 phase = esp->sreg & ESP_STAT_PMASK;
+
+ cmd &= ~ESP_CMD_DMA;
+ zep->error = 0;
+
+ /* 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?
I don't know how Geert's suggestion would work in this case. But I think
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.)
Is it sufficient to solve just the tag byte/MSG IN problem to get the
driver working? (That is, the addr == esp->command_block_dma case.)
If so, might it be simpler to address the full PIO problem in a separate
patch? (Including the ESP_INTR_FDONE/MSG OUT issue.)
--
--
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
