* [U-Boot] Generic uclass ID @ 2018-06-02 16:25 Ramon Fried 2018-06-02 18:03 ` Heinrich Schuchardt 0 siblings, 1 reply; 8+ messages in thread From: Ramon Fried @ 2018-06-02 16:25 UTC (permalink / raw) To: u-boot 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot] Generic uclass ID 2018-06-02 16:25 [U-Boot] Generic uclass ID Ramon Fried @ 2018-06-02 18:03 ` Heinrich Schuchardt 2018-06-02 19:19 ` Ramon Fried 0 siblings, 1 reply; 8+ messages in thread From: Heinrich Schuchardt @ 2018-06-02 18:03 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot] Generic uclass ID 2018-06-02 18:03 ` Heinrich Schuchardt @ 2018-06-02 19:19 ` Ramon Fried 2018-06-03 22:32 ` Ramon Fried 0 siblings, 1 reply; 8+ messages in thread From: Ramon Fried @ 2018-06-02 19:19 UTC (permalink / raw) To: u-boot 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot] Generic uclass ID 2018-06-02 19:19 ` Ramon Fried @ 2018-06-03 22:32 ` Ramon Fried 2018-06-07 20:28 ` Simon Glass 0 siblings, 1 reply; 8+ messages in thread From: Ramon Fried @ 2018-06-03 22:32 UTC (permalink / raw) To: u-boot 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot] Generic uclass ID 2018-06-03 22:32 ` Ramon Fried @ 2018-06-07 20:28 ` Simon Glass 2018-06-07 21:41 ` Ramon Fried 0 siblings, 1 reply; 8+ messages in thread From: Simon Glass @ 2018-06-07 20:28 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot] Generic uclass ID 2018-06-07 20:28 ` Simon Glass @ 2018-06-07 21:41 ` Ramon Fried 2018-06-07 23:17 ` Simon Glass 0 siblings, 1 reply; 8+ messages in thread From: Ramon Fried @ 2018-06-07 21:41 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot] Generic uclass ID 2018-06-07 21:41 ` Ramon Fried @ 2018-06-07 23:17 ` Simon Glass 2018-06-09 8:11 ` Ramon Fried 0 siblings, 1 reply; 8+ messages in thread From: Simon Glass @ 2018-06-07 23:17 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot] Generic uclass ID 2018-06-07 23:17 ` Simon Glass @ 2018-06-09 8:11 ` Ramon Fried 0 siblings, 0 replies; 8+ messages in thread From: Ramon Fried @ 2018-06-09 8:11 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2018-06-09 8:11 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-06-02 16:25 [U-Boot] Generic uclass ID Ramon Fried 2018-06-02 18:03 ` Heinrich Schuchardt 2018-06-02 19:19 ` Ramon Fried 2018-06-03 22:32 ` Ramon Fried 2018-06-07 20:28 ` Simon Glass 2018-06-07 21:41 ` Ramon Fried 2018-06-07 23:17 ` Simon Glass 2018-06-09 8:11 ` Ramon Fried
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.