Hi Jacopo and Laurent, On Wednesday, January 11, 2017, jacopo mondi wrote: > A big difference from what pinctrl-single does and what the table-based > approach does is that it creates groups, pins and functions at run-time, > parsing the dts... See, this makes me think that this will chew up even more system memory. The thing about the RZ/A1 series is that it has internal RAM and we use that along with XIP_KERNEL in order to build systems that do not require external RAM. So in the end, even if we can get sh-pfc to functionally work for RZ/A1, it would be pretty sad if the device driver that uses the most system memory is one that is really only used at boot time just to change some pin configurations. > As a final note: maybe we need to decide what to do with this series, > people is spending time reviewing it, and I've just sent v2 out. If we > want to go in a different direction, we should stop here :) Personally, for the RZ/A series, I don't see the sh-pfc driver as a long term solution. If people need something in the kernel today to general testing, that's one thing. But if someone starts laying out a board with any differences from the Renesas reference design, they might be in for a rude awaking when trying to put together a BSP for their board. If people really want this sh-pcf based driver upstreamed, I will try to do some testing on my boards to make sure it at least does what it is supposed to do. (wait for V3 patch set???) Even so, I still plan on mocking up a new driver with the ideas from this discussion (create a renesas-pfc.c) as a long term solution for the RZ/A series. Whether that new driver architecture is worth upstreaming or not, I guess we'll have to wait and see. Cheers Chris
