lkml.org 
[lkml]   [2011]   [May]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 0/4] Pinmux subsystem
On Mon, May 02, 2011 at 09:16:08PM +0200, Linus Walleij wrote:
> From: Linus Walleij <linus.walleij@linaro.org>
>
> This patchset creates a pinmux subsystem and switches U300 to use that new
> subsystem as an example. The problem is not that fantastically hard to
> solve in a general way, nobody got around to it because it requires some
> upfront code I believe, and this is my stab at it.

Hi Linus

I have some questions about how you see the following situations been
solved.

Say i have a UART core. I can be used as a 3-wire serial port, or
additionally it can have hardware flow control, or additionally it can
have all the modem signals. What would i expect to find in the pinmux
driver?

I can think of two different solutions:

1) Three functions: uart-3wire, uart-hw-flow, uart-hw-flow-modem. The
first just has 2 pins, the second 4 and the last 8. The board code
selects one of these for the serial driver to use.

2) Three functions: uart-core, uart-hw-flow, uart-mode. The first has
2 pins, the second has 2 pins and the last 4 pins. The board code tells
the driver to use uart-core, plus say uart-hw-flow.

Do you think the documentation should have guidelines how best to do
this sort of core + additional optional extras?

Say i have a SoC with an SPI core. This core has the usual MISC, MOSI
and SCLK. It additionally has 4 chip select lines. My board uses chip
select lines 2 and 3 for SPI, and select lines 0 and 1 as GPIO lines.
How does the pinmux driver handle this? Again, it is the problems of a
few core pins plus additional optional extras.

Maybe the documentation should make some recommendations about what is
placed into the drivers/pinmux/pinmux-foo.c and what should be kept in
the board specific code? Without these guidelines, it seems to me,
each board for a given SoC is going to add its own peculiar pin
combination to the drivers/pinmux/pinmux-foo.c file. Maybe it makes
more sense to have a collection of standard pin functions in
drivers/pinmux/pinmux-foo.c, which cover 75% of the likely
combinations. And recommend a board file to have its own additional
list of strange pin functions which it registers with the pinmux core?

Thanks
Andrew


\
 
 \ /
  Last update: 2011-05-03 19:51    [W:1.962 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site