[U-Boot] [PATCH 2/4] soc: qualcomm: Add Shared Memory Manager driver

[Ramon Fried]

On June 11, 2018 10:38:45 PM GMT+03:00, Simon Glass <sjg at chromium.org> wrote:
>Hi Ramon,
>
>On 11 June 2018 at 13:14, Ramon Fried <ramon.fried at gmail.com> wrote:
>>
>>
>> On Mon, Jun 11, 2018 at 5:53 PM, Simon Glass <sjg at chromium.org>
>wrote:
>>>
>>> Hi Ramon,
>>>
>>> On 9 June 2018 at 03:06, Ramon Fried <ramon.fried at gmail.com> wrote:
>>> > The Shared Memory Manager driver implements an interface for
>allocating
>>> > and accessing items in the memory area shared among all of the
>>> > processors in a Qualcomm platform.
>>> >
>>> > Adapted from the Linux driver (4.17)
>>> >
>>> > Changes from the original Linux driver:
>>> > * Removed HW spinlock mechanism, which is irrelevant
>>> > in U-boot particualar use case, which is just reading from the
>smem.
>>> > * adaptaion from Linux driver model to U-boot's.
>>> >
>>> > Cc: Bjorn Andersson <bjorn.andersson at linaro.org>
>>> > Signed-off-by: Ramon Fried <ramon.fried at gmail.com>
>>> > ---
>>> >
>>> >  MAINTAINERS                   |   1 +
>>> >  arch/arm/Kconfig              |   1 +
>>> >  drivers/Kconfig               |   2 +
>>> >  drivers/soc/Kconfig           |   5 +
>>> >  drivers/soc/Makefile          |   1 +
>>> >  drivers/soc/qualcomm/Kconfig  |  11 +
>>> >  drivers/soc/qualcomm/Makefile |   3 +
>>> >  drivers/soc/qualcomm/smem.c   | 934
>++++++++++++++++++++++++++++++++++
>>> >  8 files changed, 958 insertions(+)
>>> >  create mode 100644 drivers/soc/Kconfig
>>> >  create mode 100644 drivers/soc/qualcomm/Kconfig
>>> >  create mode 100644 drivers/soc/qualcomm/Makefile
>>> >  create mode 100644 drivers/soc/qualcomm/smem.c
>>>
>>> Sorry, but NAK on this.
>>>
>>> This patch supports direct calls into a driver which is not allowed.
>>> This should be done through the driver's uclass API, not through
>>> direct calls.
>>>
>> Hi Simon,
>> I see your point.
>> As you probably see, I was looking at the DM framework for the
>convenience
>> it
>> gives with binding device-tree nodes and drivers.
>> If it's not an option I'll rewrite it as as arch-code under
>mach-snapdragon.
>> Thanks,
>> Ramon.
>
>You are correct that you should be using driver model. It's that you
>need to do it fully, with a proper API. There are lots of examples.
>
Doesn't it make sense to add some facility  for drivers that don't export common functionalities. Like Linux platform drivers? 

>Regards,
>Simon


-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.