Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp797062pxu; Fri, 4 Dec 2020 16:20:47 -0800 (PST) X-Google-Smtp-Source: ABdhPJxIOvpXHS6tYOQjytXLGcldNNLKP+vsz2r3KYC0F/E+R8BmdciKDhzgRc5VH0RRVUklM/e1 X-Received: by 2002:a17:906:1e93:: with SMTP id e19mr9689545ejj.440.1607127647436; Fri, 04 Dec 2020 16:20:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1607127647; cv=none; d=google.com; s=arc-20160816; b=M07v74mQAe94OpS05UoAqdi5TVCQPOOrFhBwoTMKdT31LGMGgBOy4oy88KNq0itKLe kU4CAAGLkVjsOH4mLWDGrQ8rUTwPoLAGtLDLo+xA805NbFyAexVSaShTRLbE6ssLLkgT M91nd7goL45QavaBRzCz5s0ghM1NBxo8gXTxmQ2PRUACxJJAQREgd+oLxLaLeCDIVyzf 1+OwIMTMmRh14qUQIJGCxIJGCDlLG9ZgDN2wiuel9wuC1hwRZx1ouM3FDmXeLUlyZnCT I/nivag3y/w29niAneBA9alLkYj9/vuiFQ6MilGM7XrG6LmGOOqOf86oSwluKNJF22nH JQkw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=utTeGzYjnre0QYpGB+o+Kx5Eh/EBZWte4MIpGCS97Mk=; b=OfipXOL2YzcBPOCFNSMzUkl0R+28sTtwwUA8A7ikm4rrCEbH1Tw2k5oi9j8vsqfm8s qz0O+3TeRtBT6ENpiEa+zg8Py/Ga9Dk+yGn77eTKvlwgxYH1Gm/9ta5zf7vAee4LWcna kVVg2Ds0dZSbIUuzf50klWUIJvsybgYeiLdJHdSEBgnPOy4hbbSXZgDGpFlMagGSjInT zH7f5TQ0Z2sl8Kr+zR9dNbyvhZDJlxdGkhYhwemICUR3F2P+TuloNk3y0ajxrSWIg5M/ 18bYMVStvCM3MYWTPwtTql8cglbu0rRX+oAaPX+C4eUibIE/tLWhpEMDo+lQI7GatFX7 q8Ow== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=RnvGMIvV; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id aq15si2335396ejc.523.2020.12.04.16.20.25; Fri, 04 Dec 2020 16:20:47 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=RnvGMIvV; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730728AbgLEARm (ORCPT + 99 others); Fri, 4 Dec 2020 19:17:42 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43672 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726508AbgLEARl (ORCPT ); Fri, 4 Dec 2020 19:17:41 -0500 Received: from mail-oi1-x244.google.com (mail-oi1-x244.google.com [IPv6:2607:f8b0:4864:20::244]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 27358C0613D1 for ; Fri, 4 Dec 2020 16:17:01 -0800 (PST) Received: by mail-oi1-x244.google.com with SMTP id d27so665709oic.0 for ; Fri, 04 Dec 2020 16:17:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=utTeGzYjnre0QYpGB+o+Kx5Eh/EBZWte4MIpGCS97Mk=; b=RnvGMIvVG6Xy37R27w0nFCZsfL8SMYfr1j2g6qflxujBDijVLd19buyf8rD4Nict9a JYI9wOCh94Yhtz+hVW/NRKrwlNM+VygZrGeFtpzetbkMWcE5xrE1uJs0fURBEjLdGEui gTaC9pGyXUYKYc7lv0jypQ9tygpmh/+h2bZyVq9Qo0t+CK4AFnm23uuxcSb0XBfs2OHs RTXC5sWfQ0v5CQdk+RSPcRB8EOhoPcuQmj3c75PJoclm9PeOr2dHU81165ghKLCK+ETT veCpidLi8ww6qq92kNe7xD9dhB+lWUoxD2BfNKKoJf9Ndc1NMSoAANI6yofqqiaR1n04 LFYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=utTeGzYjnre0QYpGB+o+Kx5Eh/EBZWte4MIpGCS97Mk=; b=YNTtFATTngTezONRHyna7k7FBqAJb4smD+aAntdfGt2dNUJiszibDZR+4u8t541kp+ LewBPuv35BKtWvWqIfKpkX0u0ST0a5Eh/hYEBZu9yDNe/uED4FS7IuFp8xVGxexHwluR ZIC8O0ROwmfUkM+5XWeHiPYHWjI7qWtfuc+H2b1jCfYbRBVrXZpLRVm8UKQ31cCNGu/2 Z4HvZ/COttoq8RaG0yJTBrcLvtzT6fhxCX6eRXLd2q8BVmX7cT5nR3gwFPs2TSHhqcQU SkSuL0L+4H6sIECiV5NWT8/CUuFfI9impLqkAjHSTtNl6ZPpPJnPfFi3yBzHNbNqzgrs KvYA== X-Gm-Message-State: AOAM533HVd7YU0/A9SFkm2zdPcx5k9bErACU7amvDyXeap8K8Q60sWLA SojFMOxxUBbIuGYLk3Wz502yCg== X-Received: by 2002:aca:6106:: with SMTP id v6mr5106782oib.158.1607127420378; Fri, 04 Dec 2020 16:17:00 -0800 (PST) Received: from builder.lan (104-57-184-186.lightspeed.austtx.sbcglobal.net. [104.57.184.186]) by smtp.gmail.com with ESMTPSA id r7sm1013171oih.21.2020.12.04.16.16.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Dec 2020 16:16:59 -0800 (PST) Date: Fri, 4 Dec 2020 18:16:57 -0600 From: Bjorn Andersson To: "Peng Fan (OSS)" Cc: ohad@wizery.com, mathieu.poirier@linaro.org, o.rempel@pengutronix.de, shawnguo@kernel.org, s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com, linux-imx@nxp.com, linux-remoteproc@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Peng Fan , Richard Zhu Subject: Re: [PATCH V3 1/7] remoteproc: elf: support platform specific memory hook Message-ID: References: <20201204074036.23870-1-peng.fan@oss.nxp.com> <20201204074036.23870-2-peng.fan@oss.nxp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201204074036.23870-2-peng.fan@oss.nxp.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri 04 Dec 01:40 CST 2020, Peng Fan (OSS) wrote: > From: Peng Fan > > To arm64, "dc zva, dst" is used in memset. > Per ARM DDI 0487A.j, chapter C5.3.8 DC ZVA, Data Cache Zero by VA, > > "If the memory region being zeroed is any type of Device memory, > this instruction can give an alignment fault which is prioritized > in the same way as other alignment faults that are determined > by the memory type." > > On i.MX platforms, when elf is loaded to onchip TCM area, the region > is ioremapped, so "dc zva, dst" will trigger abort. And ioremap_wc() > on i.MX not able to write correct data to TCM area. > > So we need to use io helpers, and extend the elf loader to support > platform specific memory functions. > > Acked-by: Richard Zhu > Signed-off-by: Peng Fan > Reviewed-by: Mathieu Poirier > --- > drivers/remoteproc/remoteproc_elf_loader.c | 20 ++++++++++++++++++-- > include/linux/remoteproc.h | 4 ++++ > 2 files changed, 22 insertions(+), 2 deletions(-) > > diff --git a/drivers/remoteproc/remoteproc_elf_loader.c b/drivers/remoteproc/remoteproc_elf_loader.c > index df68d87752e4..6cb71fe47261 100644 > --- a/drivers/remoteproc/remoteproc_elf_loader.c > +++ b/drivers/remoteproc/remoteproc_elf_loader.c > @@ -129,6 +129,22 @@ u64 rproc_elf_get_boot_addr(struct rproc *rproc, const struct firmware *fw) > } > EXPORT_SYMBOL(rproc_elf_get_boot_addr); > > +static void rproc_elf_memcpy(struct rproc *rproc, void *dest, const void *src, size_t count) > +{ > + if (!rproc->ops->elf_memcpy) > + memcpy(dest, src, count); > + > + rproc->ops->elf_memcpy(rproc, dest, src, count); Looking at the current set of remoteproc drivers I get a feeling that we'll end up with a while bunch of functions that all just wraps memcpy_toio(). And the reason for this is that we are we're "abusing" the carveout to carry the __iomem pointer without keeping track of it. And this is not the only time we're supposed to use an io-accessor, another example is rproc_copy_segment() in rproc_coredump.c It also means that if a platform driver for some reason where to support both ioremap and normal carveouts the elf_memcpy op would be quite quirky. So I would prefer if we track the knowledge about void *va being a __iomem or not in the struct rproc_mem_entry and make rproc_da_to_va() return this information as well. Then instead of extending the ops we can make this simply call memcpy or memcpy_toio() depending on this. Regards, Bjorn > +} > + > +static void rproc_elf_memset(struct rproc *rproc, void *s, int c, size_t count) > +{ > + if (!rproc->ops->elf_memset) > + memset(s, c, count); > + > + rproc->ops->elf_memset(rproc, s, c, count); > +} > + > /** > * rproc_elf_load_segments() - load firmware segments to memory > * @rproc: remote processor which will be booted using these fw segments > @@ -214,7 +230,7 @@ int rproc_elf_load_segments(struct rproc *rproc, const struct firmware *fw) > > /* put the segment where the remote processor expects it */ > if (filesz) > - memcpy(ptr, elf_data + offset, filesz); > + rproc_elf_memcpy(rproc, ptr, elf_data + offset, filesz); > > /* > * Zero out remaining memory for this segment. > @@ -224,7 +240,7 @@ int rproc_elf_load_segments(struct rproc *rproc, const struct firmware *fw) > * this. > */ > if (memsz > filesz) > - memset(ptr + filesz, 0, memsz - filesz); > + rproc_elf_memset(rproc, ptr + filesz, 0, memsz - filesz); > } > > return ret; > diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h > index e8ac041c64d9..06c52f88a3fd 100644 > --- a/include/linux/remoteproc.h > +++ b/include/linux/remoteproc.h > @@ -373,6 +373,8 @@ enum rsc_handling_status { > * expects to find it > * @sanity_check: sanity check the fw image > * @get_boot_addr: get boot address to entry point specified in firmware > + * @elf_memcpy: platform specific elf loader memcpy > + * @elf_memset: platform specific elf loader memset > * @panic: optional callback to react to system panic, core will delay > * panic at least the returned number of milliseconds > */ > @@ -392,6 +394,8 @@ struct rproc_ops { > int (*load)(struct rproc *rproc, const struct firmware *fw); > int (*sanity_check)(struct rproc *rproc, const struct firmware *fw); > u64 (*get_boot_addr)(struct rproc *rproc, const struct firmware *fw); > + void (*elf_memcpy)(struct rproc *rproc, void *dest, const void *src, size_t count); > + void (*elf_memset)(struct rproc *rproc, void *s, int c, size_t count); > unsigned long (*panic)(struct rproc *rproc); > }; > > -- > 2.28.0 >