[U-Boot] Generic uclass ID

[U-Boot] Generic uclass ID

[Ramon Fried]

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 ?

Thanks,
Ramon.

[U-Boot] Generic uclass ID

[Heinrich Schuchardt]

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

[U-Boot] Generic uclass ID

[Ramon Fried]

On Sat, Jun 2, 2018 at 9:03 PM, Heinrich Schuchardt <xypron.glpk@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.

[U-Boot] Generic uclass ID

[Ramon Fried]

On Sat, Jun 2, 2018 at 10:19 PM, Ramon Fried <ramon.fried@gmail.com> wrote:
> On Sat, Jun 2, 2018 at 9:03 PM, Heinrich Schuchardt <xypron.glpk@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.

[U-Boot] Generic uclass ID

[Simon Glass]

Hi Ramon,

On 3 June 2018 at 14:32, Ramon Fried <ramon.fried@gmail.com> wrote:
> On Sat, Jun 2, 2018 at 10:19 PM, Ramon Fried <ramon.fried@gmail.com> wrote:
>> On Sat, Jun 2, 2018 at 9:03 PM, Heinrich Schuchardt <xypron.glpk@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?

Regards,
Simon

[U-Boot] Generic uclass ID

[Ramon Fried]

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

Thanks,
Ramon.

>
> Regards,
> Simon

[U-Boot] Generic uclass ID

[Simon Glass]

Hi Ramon,

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

[U-Boot] Generic uclass ID

[Ramon Fried]

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