Hi Chris, On Monday 09 Jan 2017 23:53:39 Chris Brandt wrote: > On Monday, January 09, 2017, Laurent Pinchart wrote: > > Both the existing RZ/A model and the pinctrl model are in my opinion > > improvements over the RZ/G and R-Car models. I don't care much about > > whether pinctrl-single can be used, but we really need hardware > > architectures that don't require those huge data tables. > > I can definitely agree to that. > > > It's more complex than that. Both the pin-based and group-based models > > have their pros and cons, and the pinctrl API is some kind of mix that > > allows both options. > > Here is my general question: Which of these 2 approaches are better? > > A) In the DT, the user ask "enable Ethernet please" and magic happens in > the pfc driver. > > B) In the DT, the user looks up the correct pin/function assignments in > the SoC Hardware Manual and manually spells out what they need. > > R-Car looks more like A. I've been using a driver that looks more like B. > > For most drivers (USB, MMC, SDHI, etc..,), I'm happy when 'magic happens' > and I don't really have to open a HW manual at all. > But, for something like setting up the PFC when someone gets a shiny new > board, making people actually open a HW manual seems acceptable to me. >From a user point of view, option A looks better to me. However, it has two drawbacks: - Through deciding what pin groups we make available we create a DT ABI that will make it difficult to fix mistakes in case the groups are not fine-grained enough. - The data tables in C code are large, and we end up compiling many of them in multi-platform kernel, significantly increasing the kernel size. I would thus favour option B. -- Regards, Laurent Pinchart
