On June 13, 2018 4:29:03 AM GMT+03:00, Simon Glass sjg@chromium.org wrote:
Hi Ramon,
On 12 June 2018 at 02:50, Ramon Fried ramon.fried@gmail.com wrote:
On June 11, 2018 10:38:45 PM GMT+03:00, Simon Glass
sjg@chromium.org wrote:
Hi Ramon,
On 11 June 2018 at 13:14, Ramon Fried ramon.fried@gmail.com wrote:
On Mon, Jun 11, 2018 at 5:53 PM, Simon Glass sjg@chromium.org
wrote:
Hi Ramon,
On 9 June 2018 at 03:06, Ramon Fried ramon.fried@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@linaro.org Signed-off-by: Ramon Fried ramon.fried@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