From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ramon Fried Date: Sat, 9 Jun 2018 11:11:57 +0300 Subject: [U-Boot] Generic uclass ID In-Reply-To: References: Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Fri, Jun 8, 2018 at 2:17 AM, Simon Glass wrote: > Hi Ramon, > > On 7 June 2018 at 13:41, Ramon Fried wrote: >> On Thu, Jun 7, 2018 at 11:28 PM, Simon Glass wrote: >>> Hi Ramon, >>> >>> On 3 June 2018 at 14:32, Ramon Fried wrote: >>>> On Sat, Jun 2, 2018 at 10:19 PM, Ramon Fried wrote: >>>>> On Sat, Jun 2, 2018 at 9:03 PM, Heinrich Schuchardt wrote: >>>>>> On 06/02/2018 06:25 PM, Ramon Fried wrote: >>>>>>> Hi Simon, all. >>>>>>> >>>>>>> I want to port a specific driver from Linux Kernel (Qualcomm smem) >>>>>>> which is declared in Linux as platform device. >>>>>>> The implementation is very specific and It doesn't fall into any >>>>>>> defined uclass id. >>>>>>> I still want to use the dm framework, what's the approach taken on >>>>>>> these kind of things ? >>>>>>> Is it possible to create a generic uclass id ? >>>>>> >>>>>> Hello Ramon, >>>>>> >>>>>> a major benefit of the driver model is that drivers are selected via the >>>>>> device tree. >>>>>> >>>>>> In Linux the driver is in drivers/soc. Wouldn't it make sense to create >>>>>> a minimal uclass for platform devices in drivers/soc on U-Boot? >>>>>> >>>>>> drivers/ram/ram-uclass.c shows what a minimal uclass looks like. >>>>>> The identifier has to be added in include/dm/uclass-id.h. >>>>>> >>>>>> Best regards >>>>>> >>>>>> Heinrich >>>>> Thanks for the comment Heinrich. >>>>> My initial intention was to place the driver under drivers/soc and I >>>>> do thing that >>>>> creating a UCLASS_PLATFORM make sense, acutally, it's exaclt what I'm suggesting >>>>> in a different name. >>>>> The thing is that there's no apperent ops that I think will suit all >>>>> the platform drivers as they're different in nature. >>>>> So, I don't see any requirement to create a platform_uclass.c file. >>>>> >>>>> Thanks, >>>>> Ramon. >>>> >>>> Added some initial contributors to uclass for comments. >>> >>> It's OK to create a uclass if you need to. What does your driver do? >> Hi Simon, thanks for replying. >> The driver purpose is to provide a way to access Qualcomm's shared >> memory region and >> to read and write properties to it accessed by other cores (Trustzone >> for instance). >> The Linux kernel driver I use as a reference >> (https://elixir.bootlin.com/linux/latest/source/drivers/soc/qcom/smem.c) >> relies heavily on device-tree bindings, and I wanted to keep as much >> of the driver intact. >> >> As this is very specific to Qualcomm, I don't think that it fits any >> other UCLASS_ definition and thus I >> suggested adding UCLASS_PLATFORM which is intended for platform >> specific drivers/devices. >> >> In such a case, the .ops will be empty as there isn't any shared >> functionailty that can be generalized. >> >> Does this make sense ? should I ditch the driver-module idea and just >> implement it as piece of code under arch/arm/mach-snapdragon ? > > I don't see why this is specific to Qualcomm. What is specific about > it? The driver certainly may be specific, but the idea of wanting to > maintain shared memory and control access to it from different CPUs > seems pretty general to me, and I think it would be useful as a > uclass. > > Here are some ideas: > > mailbox - has multiple channels but is stream-based > misc - single channel read/write but does have ioctl() and call() > remoteproc - more about executing code remotely > > If none of these suits or can be enhanced, how about creating a new one? > > BTW it would be great if you could send a patch to fix the first line > of the description of that module in the link you provided: > > "The Qualcomm shared memory system is a allocate only heap structure that" Fixed that in the U-boot case. I'm not sure that a change from a -> an will be accepted. > > Should be: "...an allocate-only heap..." I didn't manage to find any common functionality I can declare in ops. just check out the EXPORT functions in smem.c. In Addition, I'm not familiar with others specific soc shared memory managers. I ended up declaring a new class UCLASS_SOC. just sent the patchset. please tell me what you think. Thanks ! > > Regards, > Simon