From owner-svn-src-all@freebsd.org Thu Jun 2 18:48:19 2016 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C4ABEB6564D for ; Thu, 2 Jun 2016 18:48:19 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9E9A4186C for ; Thu, 2 Jun 2016 18:48:19 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 93418573-28f2-11e6-8929-8ded99d5e9d7 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.34.117.227 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.34.117.227]) by outbound2.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Thu, 2 Jun 2016 18:48:19 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.14.9) with ESMTP id u52ImA8f011053; Thu, 2 Jun 2016 12:48:10 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1464893290.1204.186.camel@freebsd.org> Subject: Re: svn commit: r301220 - in head/sys: arm/mv dev/cesa From: Ian Lepore To: Zbigniew Bodek , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Date: Thu, 02 Jun 2016 12:48:10 -0600 In-Reply-To: <201606021831.u52IVb1O006883@repo.freebsd.org> References: <201606021831.u52IVb1O006883@repo.freebsd.org> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 18:48:19 -0000 On Thu, 2016-06-02 at 18:31 +0000, Zbigniew Bodek wrote: > Author: zbb > Date: Thu Jun 2 18:31:36 2016 > New Revision: 301220 > URL: https://svnweb.freebsd.org/changeset/base/301220 > > Log: > Map CESA SRAM memory in driver attach for Armada38x > > On other platforms with CESA accelerator the SRAM memory is mapped > in > early init before driver is attached. This method only works > correctly > with mappings no smaller than L1 section size (1MB). There may be > more > SRAM blocks and they may have smaller sizes than 1MB as is the case > for Armada38x. Instead, map SRAM memory with bus_space_map() in > CESA > driver attach. Note that we can no longer assume that VA == PA for > the > SRAM. > > Submitted by: Michal Stanek Obtained from: Semihalf > Sponsored by: Stormshield > Differential revision: https://reviews.freebsd.org/D6215 > [...] > - > + rv = OF_getprop(sram_node, "reg", (void *)sram_reg, > sizeof(sram_reg)); > + if (rv <= 0) > + return (rv); > + > + sc->sc_sram_base_pa = fdt32_to_cpu(sram_reg[0]); > + /* Store SRAM size to be able to unmap in detach() */ > + sc->sc_sram_size = fdt32_to_cpu(sram_reg[1]); > + OF_getprop() followed by fdt32_to_cpu() calls is properly spelled OF_getencprop() (with no fdt32_to_cpu calls). > +#if defined(SOC_MV_ARMADA38X) > + /* SRAM memory was not mapped in platform_sram_devmap(), map > it now */ > + rv = bus_space_map(fdtbus_bs_tag, sc->sc_sram_base_pa, sc > ->sc_sram_size, > + 0, &(sc->sc_sram_base_va)); bus_space_map() returns a bus_space_handle_t for use with other bus_space functions. The handle is not necessarily "just the virtual address" (although that happens to be the case right now on arm). I don't see any bus_space_xxxxx() calls using this handle, that means that probably the correct function to use is pmap_mapdev(), not bus_space_map(). -- Ian