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

-- 

Reply via email to