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.
Regards, Simon