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

[Simon Glass]

Hi Ramon,

On 12 June 2018 at 02:50, Ramon Fried <ramon.fried at gmail.com> wrote:
> 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?

Well this is how things used to work in U-Boot before driver model.

Now we are trying to move things to driver model.

It does not look like you have many calls, so it should be easy enough
to move it to a uclass.

You can also add a command to access the device. People can see the
tree of devices with 'dm tree', etc.

Regards,
Simon