[U-Boot] Generic uclass ID

[Ramon Fried]

On Fri, Jun 8, 2018 at 2:17 AM, Simon Glass <sjg at chromium.org> wrote:
> 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"
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