[U-Boot] Generic uclass ID

[Simon Glass]

Hi Ramon,

On 7 June 2018 at 13:41, Ramon Fried <ramon.fried at gmail.com> wrote:
> On Thu, Jun 7, 2018 at 11:28 PM, Simon Glass <sjg at chromium.org> wrote:
>> Hi Ramon,
>>
>> On 3 June 2018 at 14:32, Ramon Fried <ramon.fried at gmail.com> wrote:
>>> On Sat, Jun 2, 2018 at 10:19 PM, Ramon Fried <ramon.fried at gmail.com> wrote:
>>>> On Sat, Jun 2, 2018 at 9:03 PM, Heinrich Schuchardt <xypron.glpk at gmx.de> 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"

Should be: "...an allocate-only heap..."

Regards,
Simon