From nobody Fri Apr 14 17:01:44 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4PyjQy6z8qz45bfm for ; Fri, 14 Apr 2023 17:01:46 +0000 (UTC) (envelope-from mhorne@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PyjQy1Yckz3KS8 for ; Fri, 14 Apr 2023 17:01:46 +0000 (UTC) (envelope-from mhorne@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1681491706; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=64uby4W5Q7AkE8uC/4gp4+XgiEvDBd6y8XgMGhA/N9g=; b=xBkQskFzfnXnxzYsn6BpVnv4MUMipigXSoRRzg4la/ldgxnyUqd/SnbLDRxXXZVhKSaHeB YAV9tiAkHgExOnj86OEpZa01aesJD8I7j2XDcPNg3MV2E7TcL/h7gHkgiACDKyOu70MZA8 0NfUh2I5vTHy5jF7S+og0d/D8qkfbnN9j97TtwKuoxYqw6IDqG7C0RYlLCIY6tpVvXs3rj Lvy4UNj8uhMjnJ5XjywRonN9NGGqGgVTP8XoW+u/6doKDBuGXQ/N8hmnXKtlnYZRVWKm+P T7lhquyyv7PIyLQmZ20uBH6EfhzVqMlnkuT71RFOIZuvMs+mG53lECL+Xl3Ogg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1681491706; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=64uby4W5Q7AkE8uC/4gp4+XgiEvDBd6y8XgMGhA/N9g=; b=bjbilC0a1+WascdfN9vdZJpj0tkyo3o3s9vkwzE4oUPWqEQW7qoP7C7SW+SbEXAFFxRR8j 5eFbNe88p7Z1/hNK69/FPNftWzsm9Ol02d71aX3UrQkBhGkah6TLP8G0ECOY0ankKvu9VR K6MrvJ3Gycl9vqdWu1qTxmHM0idvpdlrv9KN4hTpCAvb0JKX8Xum1WblO8k9DRT3DKcnXS pmTqA2cEIIqMF90tK6ExQZ0qMRt2eB6MIDaNbAIjEoNLxCwZ84OQ1t9xeH/QPOZrznfr+x Spix/Gts1MwTFCdc/RnCvMCWBsSPYWFDNu1bFNN+4XtTuUCSOOruL46aJlsYSg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1681491706; a=rsa-sha256; cv=none; b=cezKvMJGcrVRL44JmGqxIOEOxK4TDT42c/elQ/PGnwvRUlJqTEUX956souEY4Vvxeg0rE7 e5/CxKHdHmgnIwzaw5K/s9bNJ/56K23mx5yxAD4Lucm72bcEIEx1pm0tSMlKP3yOMy8aNg hISBFPNFHrg94/wTSTuj3dBeNcoDU3fq5ixeEUeQJoIfDxd2khOExC032Kv3AZQHZWMF+e 3PEo3laQGcFlwV/C+UP908trHziEBEsfoADCa9pXFtumhg973Bau4vL8+rhB8z2qve/SNR dx6s+k4nocZpUp/IqTvvNM/Gg3B5zW/Wjbo68CiX2waQjui7V4YCfkLL9JrtBQ== Received: from [192.168.1.151] (host-173-212-76-127.public.eastlink.ca [173.212.76.127]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: mhorne) by smtp.freebsd.org (Postfix) with ESMTPSA id 4PyjQx6zwSzFxy for ; Fri, 14 Apr 2023 17:01:45 +0000 (UTC) (envelope-from mhorne@freebsd.org) Message-ID: Date: Fri, 14 Apr 2023 14:01:44 -0300 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: About PHYS_TO_DMAP Content-Language: en-CA To: freebsd-arm@freebsd.org References: <86ildyucuv.fsf@peasant.tower.home> From: Mitchell Horne In-Reply-To: <86ildyucuv.fsf@peasant.tower.home> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ThisMailContainsUnwantedMimeParts: N On 4/14/23 04:31, Dmitry Salychev wrote: > > Hi, > > I'm struggling to understand which KVA will be returned by PHYS_TO_DMAP > on arm64. For example, if I'll create a DMA tag this way: > > bus_dma_tag_create( > bus_get_dma_tag(dev), > sc->buf_align, 0, /* alignment, boundary */ > DMAP_MAX_PHYSADDR, /* low restricted addr */ > DMAP_MIN_PHYSADDR, /* high restricted addr */ I think you are confused about the purpose of lowaddr and highaddr. They specify the window of bus-space addresses that are *inaccessible* *to the device* for DMA. It does not prevent you from providing a buffer backed by physical memory within this range, but in this case bounce pages will be used as an intermediate to perform the DMA transaction. Most commonly, if the device can only address a 32-bit range, then the values lowaddr=BUS_SPACE_MAXADDR_32BIT and highaddr=BUS_SPACE_MAXADDR will be given. If the entire bus range is accessible to the device for DMA, a zero-sized window will be given: lowaddr=BUS_SPACE_MAXADDR, highaddr=BUS_SPACE_MAXADDR. This is all described in adequate detail in busdma(9), but it is still not easily understood without a lot of code study, in my experience. > NULL, NULL, /* filter, filterarg */ > BUF_SIZE, 1, /* maxsize, nsegments */ > BUF_SIZE, 0, /* maxsegsize, flags */ > NULL, NULL, /* lockfunc, lockarg */ > &dmat); > > in order to restrict any physical addresses but a window defined by > DMAP_MIN_PHYSADDR and DMAP_MAX_PHYSADDR. Later on when I'll be > mapping my mbuf (BUF_SIZE) with > > bus_dmamap_load_mbuf_sg(dmat, dmap, > m, &segs, &nsegs, BUS_DMA_NOWAIT); > > I expect that > > m->m_data == PHYS_TO_DMAP(segs[0].ds_addr) Why do you expect or need this to be the case? busdma is not responsible for setting or modifying m_data, it comes from wherever you allocated the mbuf. Calling bus_dmamap_load_mbuf_sg() will prepare a DMA mapping where the m_data buffer is used as the source/destination for the DMA transaction, but busdma does not allocate the buffer itself. > > but it isn't true. Could somebody explain what exactly is returned by > PHYS_TO_DMAP in this case and whether it's possible to translate > physical address to KVA as fast as possible (O(1) ideally). > PHYS_TO_DMAP is always a linear calculation of: physaddr + DMAP_MIN_ADDRESS. I do not think PHYS_TO_DMAP is in use at all in this example, or anywhere within busdma really. > Regards, > Dmitry > > -- > Open source software/hardware enthusiast > hackaday.io/dsl | github.com/mcusim | patreon.com/salychev >