发件人:Scott Wood <o...@buserror.net> 发送日期:2020-03-02 16:58:52 收件人:"王文虎" <wenhu.w...@vivo.com> 抄送人:wangwenhu <wenhu....@gmail.com>,Kumar Gala <ga...@kernel.crashing.org>,Benjamin Herrenschmidt <b...@kernel.crashing.org>,Paul Mackerras <pau...@samba.org>,Michael Ellerman <m...@ellerman.id.au>,linuxppc-dev@lists.ozlabs.org,linux-ker...@vger.kernel.org,triv...@kernel.org,Rai Harninder <harninder....@nxp.com> 主题:Re: [PATCH] powerpc/Kconfig: Make FSL_85XX_CACHE_SRAM configurable>On Mon, 2020-03-02 at 12:42 +0800, 王文虎 wrote: >> 发件人:Scott Wood <o...@buserror.net> >> 发送日期:2020-03-01 07:12:58 >> 收件人:"王文虎" <wenhu.w...@vivo.com> >> 抄送人:wangwenhu <wenhu....@gmail.com>,Kumar Gala <ga...@kernel.crashing.org>,B >> enjamin Herrenschmidt <b...@kernel.crashing.org>,Paul Mackerras < >> pau...@samba.org>,Michael Ellerman <m...@ellerman.id.au>, >> linuxppc-dev@lists.ozlabs.org,linux-ker...@vger.kernel.org, >> triv...@kernel.org,Rai Harninder <harninder....@nxp.com> >> 主题:Re: Re: [PATCH] powerpc/Kconfig: Make FSL_85XX_CACHE_SRAM configurable>On >> Tue, 2020-01-21 at 14:38 +0800, 王文虎 wrote: >> > > 发件人:Scott Wood <o...@buserror.net> >> > > 发送日期:2020-01-21 13:49:59 >> > > 收件人:"王文虎" <wenhu.w...@vivo.com> >> > > 抄送人:wangwenhu <wenhu....@gmail.com>,Kumar Gala < >> > > ga...@kernel.crashing.org>,B >> > > enjamin Herrenschmidt <b...@kernel.crashing.org>,Paul Mackerras < >> > > pau...@samba.org>,Michael Ellerman <m...@ellerman.id.au>, >> > > linuxppc-dev@lists.ozlabs.org,linux-ker...@vger.kernel.org, >> > > triv...@kernel.org,Rai Harninder <harninder....@nxp.com> >> > > 主题:Re: [PATCH] powerpc/Kconfig: Make FSL_85XX_CACHE_SRAM configurable>On >> > > Tue, 2020-01-21 at 13:20 +0800, 王文虎 wrote: >> > > > > From: Scott Wood <o...@buserror.net> >> > > > > Date: 2020-01-21 11:25:25 >> > > > > To: wangwenhu <wenhu....@gmail.com>,Kumar Gala < >> > > > > ga...@kernel.crashing.org>, >> > > > > Benjamin Herrenschmidt <b...@kernel.crashing.org>,Paul Mackerras < >> > > > > pau...@samba.org>,Michael Ellerman <m...@ellerman.id.au>, >> > > > > linuxppc-dev@lists.ozlabs.org,linux-ker...@vger.kernel.org >> > > > > Cc: triv...@kernel.org,wenhu.w...@vivo.com,Rai Harninder < >> > > > > harninder....@nxp.com> >> > > > > Subject: Re: [PATCH] powerpc/Kconfig: Make FSL_85XX_CACHE_SRAM >> > > > > configurable>On Mon, 2020-01-20 at 06:43 -0800, wangwenhu wrote: >> > > > > > > From: wangwenhu <wenhu.w...@vivo.com> >> > > > > > > >> > > > > > > When generating .config file with menuconfig on Freescale BOOKE >> > > > > > > SOC, FSL_85XX_CACHE_SRAM is not configurable for the lack of >> > > > > > > description in the Kconfig field, which makes it impossible >> > > > > > > to support L2Cache-Sram driver. Add a description to make it >> > > > > > > configurable. >> > > > > > > >> > > > > > > Signed-off-by: wangwenhu <wenhu.w...@vivo.com> >> > > > > > >> > > > > > The intent was that drivers using the SRAM API would select the >> > > > > > symbol. What >> > > > > > is the use case for selecting it manually? >> > > > > > >> > > > > >> > > > > With a repository of multiple products(meaning different defconfigs) >> > > > > and >> > > > > multiple >> > > > > developers, the Kconfigs of the Kernel Source Tree change >> > > > > frequently. So >> > > > > the >> > > > > "make menuconfig" >> > > > > process is needed for defconfigs' re-generating or updating for the >> > > > > complexity of dependencies >> > > > > between different features defined in the Kconfigs. >> > > > >> > > > That doesn't answer my question of how the SRAM code would be useful >> > > > other >> > > > than to some other driver that uses the API (which would use >> > > > "select"). There >> > > > is no userspace API. You could use the kernel command line to >> > > > configure >> > > > the >> > > > SRAM but you need to get the address of it for it to be useful. >> > > > >> > > >> > > Like you've asked below, via /dev/mem or direct calling within the >> > > Kernel. >> > > And they are not submitted yes, under development. >> > >> > If they are calling within the kernel, then whatever driver that is should >> > select FSL_85XX_CACHE_SRAM. Directly accessing /dev/mem without any way >> > for >> > the kernel to advertise where it is or which parts of SRAM are available >> > for >> > use sounds like a bad idea. >> > >> >> Yes, definitely. So like we enable the moulde which should selet >> FSL_85XX_CACHE_SRAM to build vmlinux, FSL_85XX_CACHE_SRAM >> could not be seleted because of the Kconfig definition problem >> which I am trying to fix now. So would you please merge the patch >> for the convenience of later works depending on the driver. > >Sorry, I don't think it's something that should be enabled by itself with >nothing using the allocators. Suppose we took this patch, and people enabled >it and accessed it via /dev/mem. Then suppose a driver is patched to allocate >some sram and use it. They'd be stepping on each others' toes undetected. > Right, and maybe i did not explain it clear: I mean that we are developing modules both in kernel which call the interfaces of FSL_85XX_CACHE_SRAM directly, and in user space which is a further consideration upon the work we have done. Cause we have not exported the code under developing, it seems like that nothing uses FSL_85XX_CACHE_SRAM.
>If you want to expose it to userspace, add code that allocates some or all of >the sram and make it something userspace can mmap. Or, if nothing's going to >use them, remove the allocators and export the entire thing to userspace >(again via an sram-specific mappable rather than /dev/mem). As for /dev/mem, it was one of our choices ever but now a user-space driver is preferred for further consideration. But currently, the functionality that directly calls the insterfaces of FSL_85XX_CACHE_SRAM have been under developing for couples of days and would be exported in the future. They would be used on hw-platforms like PPCe500. Just some time it takes. Do you mean the exporting is a pre-condition? If not, the merge would do a favor for the convenience. Wenhu > >-Scott > >