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

[Ramon Fried]

On June 13, 2018 4:29:03 AM GMT+03:00, Simon Glass <sjg at chromium.org> wrote:
>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.
That's what I'll do. 
Thanks. 
>
>You can also add a command to access the device. People can see the
>tree of devices with 'dm tree', etc.
>
>Regards,
>Simon


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