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.

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

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