From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 86F02C43334 for ; Tue, 28 Jun 2022 21:38:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229878AbiF1ViN (ORCPT ); Tue, 28 Jun 2022 17:38:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46200 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229510AbiF1ViN (ORCPT ); Tue, 28 Jun 2022 17:38:13 -0400 Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B8B08B66 for ; Tue, 28 Jun 2022 14:38:10 -0700 (PDT) Received: by mail-pg1-x52f.google.com with SMTP id v126so9242300pgv.11 for ; Tue, 28 Jun 2022 14:38:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=WjW+6GW3ETFm2JU8jE79XhUoTv6z3/GSxYftllUP/xs=; b=Hl4POJee6IPPulGeCkhFVzmaewHFoLW/+/aEoDQjxUpbODhZ1oymIgaTqZ81qNcby5 tayUWDYOl9MImX18J8dQD7IqMr+zmUU1bqZHU+pNimB587Iq3zDvd9733Lpd08PJ3ZqN hCcDuWiBdimpZlnAS7LXz+VIQLfHxUzeRmXR/DhhOL+83rGT7oCb0qCs+I3LD5qbJUOY Z7gwLbNztnnB2BuHaZLhgR2hoazBRvaRufJfP7NUdv99H5O/s5nLD+ERJ1SZjBEJ5o3/ g1yNYiH51zSIYiit2licB5Pp4Mw6FaB2n5sZmRFysJGeMTkqmhnQmnjN1azWYVr/4Saz dDKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=WjW+6GW3ETFm2JU8jE79XhUoTv6z3/GSxYftllUP/xs=; b=AQQO/GIRrRvdM2cINNf01HMnbiPppmTj2F+pkS1Lw52XZSKWLmDjv6b3ntorUVvS3v vJDXWrvHFVMvdeCSE7kO0rPTu27poU4zbage8mq52KnKKBEmd3j5QLY4I7EthaCzl0Jz g9q9KQw6K0zHhoFcO0XXglu0b+6hSyzT14RcRuSTtOCWO4ab5yibQCBTpD9zQleJnQOX cIvlXmXyiVFrU4vI/oXNnubIIL2rNWeRYl6eDW+WhHdm/U1Mo/Fkm/vqGxhgcCm9zuR0 aYc72w0QFvN58qFiTc6rGpEMni8ZVf4fQV/yI9qSVUO3ruINaOQ5bneEbTE03hKWDknM qMNw== X-Gm-Message-State: AJIora+nSjnLePh1dNX5w+J3uFr7+MFQuT+jNXOLC4huqo+RgzU4DbRf 6FC14BopXjaGiZBOx48OS0o= X-Google-Smtp-Source: AGRyM1sFO6YgYAr9GnaRe8/Ve8aBPD9B79jMLNzzxljl0q+mxUt4Mwk0qg0QIVqzTJY3FgSvSPWrFw== X-Received: by 2002:a63:3545:0:b0:40c:95f7:d114 with SMTP id c66-20020a633545000000b0040c95f7d114mr5443pga.150.1656452290295; Tue, 28 Jun 2022 14:38:10 -0700 (PDT) Received: from ?IPV6:2001:df0:0:200c:75aa:d6ca:4354:6033? ([2001:df0:0:200c:75aa:d6ca:4354:6033]) by smtp.gmail.com with ESMTPSA id b8-20020a170902650800b00168a651316csm9770467plk.270.2022.06.28.14.38.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 28 Jun 2022 14:38:09 -0700 (PDT) Message-ID: Date: Wed, 29 Jun 2022 09:38:00 +1200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [PATCH v2 3/3] arch/*/: remove CONFIG_VIRT_TO_BUS Content-Language: en-US To: Arnd Bergmann Cc: Geert Uytterhoeven , scsi , Linux Kernel Mailing List , Arnd Bergmann , Jakub Kicinski , Christoph Hellwig , Marek Szyprowski , Robin Murphy , Linux IOMMU , Khalid Aziz , "Maciej W . Rozycki" , Matt Wang , Miquel van Smoorenburg , Mark Salyzyn , linuxppc-dev , Linux-Arch , alpha , linux-m68k , Parisc List , Denis Efremov , Michael Ellerman , John Paul Adrian Glaubitz References: <20220617125750.728590-1-arnd@kernel.org> <20220617125750.728590-4-arnd@kernel.org> <6ba86afe-bf9f-1aca-7af1-d0d348d75ffc@gmail.com> <9289fd82-285c-035f-5355-4d70ce4f87b0@gmail.com> From: Michael Schmitz In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-m68k@vger.kernel.org Hi Arnd, On 28/06/22 19:08, Arnd Bergmann wrote: > On Tue, Jun 28, 2022 at 5:25 AM Michael Schmitz wrote: >> Am 28.06.2022 um 09:12 schrieb Michael Schmitz: >> >> Leaving the bounce buffer handling in place, and taking a few other >> liberties - this is what converting the easiest case (a3000 SCSI) might >> look like. Any obvious mistakes? The mvme147 driver would be very >> similar to handle (after conversion to a platform device). >> >> The driver allocates bounce buffers using kmalloc if it hits an >> unaligned data buffer - can such buffers still even happen these days? >> If I understand dma_map_single() correctly, the resulting dma handle >> would be equally misaligned? >> >> To allocate a bounce buffer, would it be OK to use dma_alloc_coherent() >> even though AFAIU memory used for DMA buffers generally isn't consistent >> on m68k? > I think it makes sense to skip the bounce buffering as you do here: > the only standardized way we have for integrating that part is to > use the swiotlb infrastructure, but as you mentioned earlier that > part is probably too resource-heavy here for Amiga. OK, leaving the old custom logic in place allows to convert the 24 bit DMA drivers more easily. > > I see two other problems with your patch though: > > a) you still duplicate the cache handling: the cache_clear()/cache_push() > is supposed to already be done by dma_map_single() when the device > is not cache-coherent. That's one of the 'liberties' I alluded to. The reason I left these in is that I'm none too certain what device feature the DMA API uses to decide a device isn't cache-coherent. If it's dev->coherent_dma_mask, the way I set up the device in the a3000 driver should leave the coherent mask unchanged. For the Zorro drivers, devices are set up to use the same storage to store normal and coherent masks - something we most likely want to change. I need to think about the ramifications of that. Note that zorro_esp.c uses dma_sync_single_for_device() and uses a 32 bit coherent DMA mask which does work OK. I might  ask Adrian to test a change to only set dev->dma_mask, and drop the dma_sync_single_for_device() calls if there's any doubt on this aspect. > b) The bounce buffer is never mapped here, instead you have the > virt_to_phys() here, which is not the same. I think you need to map > the pointer that actually gets passed down to the device after deciding > to use a bouce buffer or not. I hadn't realized that I can map the bounce buffer just as it's done for the SCp data buffer. Should have been obvious, but I'm still learning about the DMA API. I've updated the patch now, will re-send as part of a complete series once done. Cheers,     Michael > > Arnd