Re: [PATCH] powerpc/Kconfig: Make FSL_85XX_CACHE_SRAM configurable

[王文虎]

发件人：Scott Wood <oss at buserror.net>
发送日期：2020-03-02 16:58:52
收件人："王文虎" <wenhu.wang at vivo.com>
抄送人：wangwenhu <wenhu.pku at gmail.com>,Kumar Gala <galak at kernel.crashing.org>,Benjamin Herrenschmidt <benh at kernel.crashing.org>,Paul Mackerras <paulus at samba.org>,Michael Ellerman <mpe at ellerman.id.au>,linuxppc-dev at lists.ozlabs.org,linux-kernel at vger.kernel.org,trivial at kernel.org,Rai Harninder <harninder.rai at nxp.com>
主题：Re: [PATCH] powerpc/Kconfig: Make FSL_85XX_CACHE_SRAM configurable>On Mon, 2020-03-02 at 12:42 +0800, 王文虎 wrote:
>> 发件人：Scott Wood <oss at buserror.net>
>> 发送日期：2020-03-01 07:12:58
>> 收件人："王文虎" <wenhu.wang at vivo.com>
>> 抄送人：wangwenhu <wenhu.pku at gmail.com>,Kumar Gala <galak at kernel.crashing.org>,B
>> enjamin Herrenschmidt <benh at kernel.crashing.org>,Paul Mackerras <
>> paulus at samba.org>,Michael Ellerman <mpe at ellerman.id.au>,
>> linuxppc-dev at lists.ozlabs.org,linux-kernel at vger.kernel.org,
>> trivial at kernel.org,Rai Harninder <harninder.rai at 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 <oss at buserror.net>
>> > > 发送日期：2020-01-21 13:49:59
>> > > 收件人："王文虎" <wenhu.wang at vivo.com>
>> > > 抄送人：wangwenhu <wenhu.pku at gmail.com>,Kumar Gala <
>> > > galak at kernel.crashing.org>,B
>> > > enjamin Herrenschmidt <benh at kernel.crashing.org>,Paul Mackerras <
>> > > paulus at samba.org>,Michael Ellerman <mpe at ellerman.id.au>,
>> > > linuxppc-dev at lists.ozlabs.org,linux-kernel at vger.kernel.org,
>> > > trivial at kernel.org,Rai Harninder <harninder.rai at 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 <oss at buserror.net>
>> > > > > Date: 2020-01-21 11:25:25
>> > > > > To:  wangwenhu <wenhu.pku at gmail.com>,Kumar Gala <
>> > > > > galak at kernel.crashing.org>,
>> > > > > Benjamin Herrenschmidt <benh at kernel.crashing.org>,Paul Mackerras <
>> > > > > paulus at samba.org>,Michael Ellerman <mpe at ellerman.id.au>,
>> > > > > linuxppc-dev at lists.ozlabs.org,linux-kernel at vger.kernel.org
>> > > > > Cc:  trivial at kernel.org,wenhu.wang at vivo.com,Rai Harninder <
>> > > > > harninder.rai at 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.wang at 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.wang at 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
>
>