Hi Roger, On Sat, 1 Oct 2022 at 02:37, Roger Quadros <rog...@kernel.org> wrote: > > Hi, > > On 01/10/2022 02:48, Simon Glass wrote: > > Hi, > > > > On Fri, 30 Sept 2022 at 14:18, Roger Quadros <rog...@kernel.org> wrote: > >> > >> On 30/09/2022 17:00, Tom Rini wrote: > >>> On Fri, Sep 30, 2022 at 07:28:51AM -0600, Simon Glass wrote: > >>>> Hi Roger, > >>>> > >>>> On Fri, 30 Sept 2022 at 06:47, Roger Quadros <rog...@kernel.org> wrote: > >>>>> > >>>>> Simon, > >>>>> > >>>>> On 29/09/2022 21:06, Simon Glass wrote: > >>>>>> Hi Roger, > >>>>>> > >>>>>> On Thu, 29 Sept 2022 at 01:03, Roger Quadros <rog...@kernel.org> wrote: > >>>>>>> > >>>>>>> Hi Simon, > >>>>>>> > >>>>>>> On 28/09/2022 19:27, Simon Glass wrote: > >>>>>>>> Hi Roger, > >>>>>>>> > >>>>>>>> On Wed, 28 Sept 2022 at 06:12, Roger Quadros <rog...@kernel.org> > >>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>> We will need ti-gpmc driver for SPL. Allow memory drivers > >>>>>>>>> do be built for SPL. > >>>>>>>>> > >>>>>>>>> Signed-off-by: Roger Quadros <rog...@kernel.org> > >>>>>>>>> --- > >>>>>>>>> scripts/Makefile.spl | 1 + > >>>>>>>>> 1 file changed, 1 insertion(+) > >>>>>>>> > >>>>>>>> Please can you use the existing drivers/ram directory? > >>>>>>> > >>>>>>> The ti-gpmc driver is not actually a RAM only controller. Although it > >>>>>>> can support SRAM. > >>>>>>> It is a more general purpose controller that can support different > >>>>>>> peripherals. > >>>>>>> It is similar to the drivers already existing in the divers/memory > >>>>>>> directory. > >>>>>>> > >>>>>>> I was just trying to keep the file layout similar to that in the > >>>>>>> Linux kernel. > >>>>>>> > >>>>>>> Do you still see a problem with it? > >>>>>> > >>>>>> Well in this case perhaps the RAM device would be a child of this one? > >>>>> > >>>>> That's right. > >>>>>> > >>>>>> But there is no uclass for your new device. One of the drivers in that > >>>>>> dir uses UCLASS_NOP and your one seems to use UCLASS_SIMPLE_BUS > >>>>>> > >>>>>> So let's add a uclass for it and describe exactly what it is for. > >>>>> > >>>>> Why isn't UCLASS_SIMPLE_BUS sufficient? > >>>>> By itself, the GPMC driver doesn't offer any usable functionality. > >>>>> It just configures the bus interface and then populates the children. > >>>> > >>>> That's OK, but in that case it should go in drivers/bus and perhaps > >>>> drivers/memory should go away? > >>> > >>> No, drivers/memory/stm32-fmc2-ebi.c is there and is the equivalent (more > >>> or less) of drivers/memory/stm32-fmc2-ebi.c in the linux kernel. So > >>> maybe a question is, are we talking about the equivalent of > >>> drivers/memory/omap-gpmc.c here? Or something else? > >>> > >> > >> Yes, I just picked up that file and adapted it for u-boot. > >> As GPMC is not only for OMAP devices anymore I renamed it to ti-gpmc.c. > >> If it helps we can retain the kernel naming. > > > > In the fullness of time all driver/xxx directories should have a > > uclass associated with them. So in this case, do we want to use > > UCLASS_BUS and put it in drivers/bus or add a UCLASS_MEMORY and put it > > in drivers/memory? > > I'd opt for UCLASS_MEMORY.
OK, here is an example patch for adding a new uclass: https://patchwork.ozlabs.org/project/uboot/patch/20220930120430.42307-2-p...@lespocky.de/ It is the bare minimum as it has not methods, but it seems like yours won't either. Regards, Simon