Hi
I am implementing a pinctrol driver for a pin controller with the
following attributes, relevant to the problem.
It has 2 different types of pins.
a) Pins that can be used for multiple functions, including being used as
a gpio to be toggled by SW.
b) Pins that have a dedicated function.
Both types support configuration of drive strength and pull up values.
The register formats for these are different.
The register address map can be descibed as
1) Config registers starting from the pinctrl base, for the general
purpose pins, one per pin at fixed offsets.
Each config register has fields to setup drive strength, pull up and
function for the corresponding pin.
2) After the above, we have config registers for the dedicated pins.
In this case the config register are per use case. For example
if SDCC uses dedicated pins as follows 1 clock pin, 8 data pins and 2
command pins then there will be one config register as follows
Bits 31-29 = clk pull value (1-7)
Bits 28-26 = data line pull values (1-7)
Bits 25-23 = command pull values (1-7)
Bits 8-6 = clk drive strength values (1-7)
Bits 5-3 = data drive strength values
Bits 2-0 = command drive strength values
3) After the config register for dedicated pins, we again have registers
for pin type a) that configure its direction and value
(in case pin is being used as a gpio and toggled by SW).
Solutions:
I initially tried to model this as 2 separate pin controllers
one for the general purpose pins and the other for dedicated pins but
this is complicated by the fact that
1) In this case the address map for the pinctroller 1 would be dis
contiguous.
2) Also the address range for the deidcated pins does not start at a 4K
page boundary, in fact some registers from pin type 1 overflow into the
starting page of the dedicated pin registers.
The only option I see is
1) to implement this as one pin controller, with total number of pins =
multi function pins + dedicated pins.
2) The pin descriptor registered with the framework would be part of a
bigger descriptor maintained by the driver that additionally defines the
pin type and the register manipulation methods for that type.
3) The pin number would serve as an index into the driver descriptor.
4) The register manipulation methods would be part of the of_device_id
data for the pin controller
I have not been able to find any precedence for this kind of pin
controller design. I do see some vendors with pin banks, and they too
maintain the "descriptor" as part of the vendor driver. But not this
kind of register address map. Would the above option be an acceptable
design or is there a better approach?
Is there any value add to having a private data field for the framework
pin descriptor that can be overloaded for every pin to take care of
these kinds of problems?
Thanks
Hanumant
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum, hosted by The Linux Foundation
--
On Wed, Apr 24, 2013 at 1:47 AM, hanumant <[email protected]> wrote:
> 2) After the above, we have config registers for the dedicated pins.
> In this case the config register are per use case. For example
> if SDCC uses dedicated pins as follows 1 clock pin, 8 data pins and 2
> command pins then there will be one config register as follows
> Bits 31-29 = clk pull value (1-7)
> Bits 28-26 = data line pull values (1-7)
> Bits 25-23 = command pull values (1-7)
> Bits 8-6 = clk drive strength values (1-7)
> Bits 5-3 = data drive strength values
> Bits 2-0 = command drive strength values
OK seems normal. I guess you really mean "drive strength" as in
"configurable mA output", because often the voltage (VCCQ) can
be controlled as well.
There is some overlap with regulators here, CC:ing Mark Brown
for a second opinion.
> The only option I see is
>
> 1) to implement this as one pin controller, with total number of pins =
> multi function pins + dedicated pins.
This seems easiest, this is what I would do.
> 2) The pin descriptor registered with the framework would be part of a
> bigger descriptor maintained by the driver that additionally defines the pin
> type and the register manipulation methods for that type.
Yes:
struct foo_desc {
struct pin_desc desc;
...
};
Register &foo->desc to the pinctrl subsystem, to get back to
foo_desc, use container_of() to get to your descriptor from the
&foo_desc->desc.
> 3) The pin number would serve as an index into the driver descriptor.
I do not understandd what this means.
> 4) The register manipulation methods would be part of the of_device_id
> data for the pin controller
Not following. You're saying you register on controller, don't
you rather want a field on struct foo_desc telling how to handle
the particular pin type?
> I have not been able to find any precedence for this kind of pin controller
> design.
We've covered the simple cases and now we get to the
complicated ones :-)
> Is there any value add to having a private data field for the framework pin
> descriptor that can be overloaded for every pin to take care of these kinds
> of problems?
Incidentally I already answered a similar mail earlier today, and the
answer is no.
Encapsulate struct pin_desc inside a custom struct and get used to
using container_of().
Yours,
Linus Walleij
On Fri, Apr 26, 2013 at 12:11:49PM +0200, Linus Walleij wrote:
> OK seems normal. I guess you really mean "drive strength" as in
> "configurable mA output", because often the voltage (VCCQ) can
> be controlled as well.
> There is some overlap with regulators here, CC:ing Mark Brown
> for a second opinion.
Yeah, I think it's just drive strength.