On June 13, 2018 4:29:03 AM GMT+03:00, Simon Glass <s...@chromium.org> wrote: >Hi Ramon, > >On 12 June 2018 at 02:50, Ramon Fried <ramon.fr...@gmail.com> wrote: >> On June 11, 2018 10:38:45 PM GMT+03:00, Simon Glass ><s...@chromium.org> wrote: >>>Hi Ramon, >>> >>>On 11 June 2018 at 13:14, Ramon Fried <ramon.fr...@gmail.com> wrote: >>>> >>>> >>>> On Mon, Jun 11, 2018 at 5:53 PM, Simon Glass <s...@chromium.org> >>>wrote: >>>>> >>>>> Hi Ramon, >>>>> >>>>> On 9 June 2018 at 03:06, Ramon Fried <ramon.fr...@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.anders...@linaro.org> >>>>> > Signed-off-by: Ramon Fried <ramon.fr...@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. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot