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.)
--
