Hi Finn,
Am 06.03.2018 um 16:04 schrieb Finn Thain:
> 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
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.
> 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.)
The driver works just fine using PIO exclusively for transferring the
extended message bytes in message in phase, and doing everything else by
DMA. The whole !write branch will never be executed, and I could just
omit it entirely for now, or leave it as it was in the Mac driver.
Cheers,
Michael
