Thread (138 messages) 138 messages, 6 authors, 2013-10-25

Re: [PATCH 2/4] pinmux: Add TB10x pinmux driver

From: Christian Ruppert <hidden>
Date: 2013-07-26 09:43:20
Also in: lkml

On Thu, Jul 18, 2013 at 01:54:18PM -0600, Stephen Warren wrote:
On 07/18/2013 10:07 AM, Christian Ruppert wrote:
...
quoted
Well, perhaps my definition of "inside"/"outside" pins was not quite
clear: The pin groups define the set of (kernel internal) pin numbers of
"outside" pins which are used by pin controller to map a given
interface. Inside pins are not numbered and the inside interfaces are
only used to determine which outside pins are part of the same group
(namely those for which the pin controller hardware provides a mux
connection to the same inside interface):

                       4
                4  /|--/-- SPI
   PINS[0..3] --/--||  4
                   \|--/-- GPIO[0..3]

                   4
   PINS[4..7] -----/------ GPIO[4..7]

                       2
                2  /|--/-- I2C
   PINS[8..9] --/--||  2
                   \|--/-- GPIO[8..9]

Pins 0..3 are in the SPI group because on the "inside" they can be muxed
to the SPI interface.
Pins 8..9 are in the I2C group because on the "inside" they can be muxed
to the I2C interface.
Pins 0..9 are in the GPIO group because on the "inside" they can be
muxed to the GPIO controller.

All pin numbers are relative to the "outside", however, or conflict
management would not be possible. I hope this is more understandable
than my previous explanations.
Both muxes are controlled by the same register. In our overly simplistic
example this is not strictly necessary but in reality you might have pin
conflicts between the different interfaces.
Same register, or same field/bits in that register?

If it's the same field/bits, I would expect to see the following pin groups:

1) PINS[0..3], PINS[8..9]
2) PINS[4..7]

... since those are the things that are independently muxable.
Otherwise, I'd expect to see the following groups:

1) PINS[0..3]
2) PINS[4..7]
3) PINS[8..9]
quoted
After the discussion we had so far I'm not so sure if extending the
pinctrl system with this kind of features is a very good idea.
That makes things simple:-)

One thing I still don't understand; in a previous mail, you'd mentioned
3 DT properties for configuring the pinmux; one represented the pin
group, one represented the mux function that was selected for that pin
group, and there was a third ("config"?) property. I still don't
understand that third property. I only see pins/pingroups and mux
functions in the diagram I quoted above.
In my proposal, pin groups represent interfaces instead of ports: All
three pin groups are configured through the same bit field in the same
register but they represent _logically_ independent functionalities.
The three DT properties are:

1. interface (which pins are we actually interested in when requesting
   this)
2. port (which bit field/register is used to configure this)
3. configuration of that port (which mux function(s) in that bit
   field/register are possible to make the interface available)

-- 
  Christian Ruppert              ,          [off-list ref]
                                /|
  Tel: +41/(0)22 816 19-42     //|                 3, Chemin du Pré-Fleuri
                             _// | bilis Systems   CH-1228 Plan-les-Ouates
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help