Smartcard/SIM card subsystem, LDO regulator and signal modelling

Smartcard/SIM card subsystem, LDO regulator and signal modelling

[Linus Walleij]

Hi folks,

I have this special regulator in the AB5500 which we will attempt to
submit for mainline inclusion soon:

It's basically an LDO for powering a SIM card (which in turn is basically
a smartcard), but apart from plain regulation also expose some other
electrical properties of the interface to software:

- Select pull-up resistance on some I/O lines
- Select weak pull-down on some data lines
- Select load capacitance limits on the data lines
- Select whether to run in low impedance or transmission gate mode

I think these will be mostly similar so what other SIM card controllers
will need to have. All the stuff needs to have userspace interfaces
since the stuff is usually controlled on behalf of another CPU
running the modem (and also performing the actual traffic on
the SIM data lines).

My first naïve idea was that this could be some plain regulator,
then add a few sysfs files for the custom stuff and have these
in the regulator driver.

However now I think we might even need to create a misc device
or a new drivers/smartcard/* subsystem, just that it will include
spawning a regulator for the LDO part. If drivers/smartcard/*
was created we'd easily fold into that, but since we're not
needing the generics of actually talking to the card we end
up in a strange place where we'd go implementing a
framework that we don't use and cannot test :-/

Maybe we should indeed create drivers/smartcard/*
and only add a tentative API for power & regulator
such as <linux/smartcard/power.h> or so?

Any thoughts on this, have you seen this before etc?

Also CC:ing some people with SoC systems that include a
SIM/smartcard reader ... RealView and Freescale comes to
mind.

Yours,
Linus Walleij

Re: Smartcard/SIM card subsystem, LDO regulator and signal modelling

[Mark Brown]

On Wed, May 18, 2011 at 12:36:17PM +0200, Linus Walleij wrote:

> It's basically an LDO for powering a SIM card (which in turn is basically
> a smartcard), but apart from plain regulation also expose some other
> electrical properties of the interface to software:

> - Select pull-up resistance on some I/O lines
> - Select weak pull-down on some data lines
> - Select load capacitance limits on the data lines
> - Select whether to run in low impedance or transmission gate mode

> I think these will be mostly similar so what other SIM card controllers
> will need to have. All the stuff needs to have userspace interfaces
> since the stuff is usually controlled on behalf of another CPU
> running the modem (and also performing the actual traffic on
> the SIM data lines).

The above also sounds rather like the standard sort of stuff you get
with pin muxes - the pulls are certainly very common for random GPIO
or I2C use, for example.  No real idea on the SIM interface itself.

Re: Smartcard/SIM card subsystem, LDO regulator and signal modelling

[Linus Walleij]

2011/5/18 Mark Brown <broonie@opensource.wolfsonmicro.com>:

> The above also sounds rather like the standard sort of stuff you get
> with pin muxes - the pulls are certainly very common for random GPIO
> or I2C use, for example.  No real idea on the SIM interface itself.

Yeah :-/

I am now starting to contemplate if I should rename the pinmux
subsystem to "pinctrl" and not only handle muxing but also
biasing in that system.

Linus Walleij

Re: Smartcard/SIM card subsystem, LDO regulator and signal modelling

[Mark Brown]

On Wed, May 18, 2011 at 07:03:38PM +0200, Linus Walleij wrote:

> I am now starting to contemplate if I should rename the pinmux
> subsystem to "pinctrl" and not only handle muxing but also
> biasing in that system.

I've not yet had time to look at pinmux but I'd certainly expect that
sort of feature - many systems rely on the mode configuration to get the
functions working (eg, I2C might be a function but you also need to put
the pin into open drain mode for it to function correctly).

Re: Smartcard/SIM card subsystem, LDO regulator and signal modelling

[Linus Walleij]

On Thu, May 19, 2011 at 12:19 AM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Wed, May 18, 2011 at 07:03:38PM +0200, Linus Walleij wrote:
>
>> I am now starting to contemplate if I should rename the pinmux
>> subsystem to "pinctrl" and not only handle muxing but also
>> biasing in that system.
>
> I've not yet had time to look at pinmux but I'd certainly expect that
> sort of feature - many systems rely on the mode configuration to get the
> functions working (eg, I2C might be a function but you also need to put
> the pin into open drain mode for it to function correctly).

I've renamed the subsystem folder "pinctrl" in next iteration, with
pinmux implemented. We will then expand it to handle other
control such as biasing, driver strength etc, as we go along.

Linus Walleij