Re: [PATCH v2] gpio: Add driver for TI TPIC2810

Re: [PATCH v2] gpio: Add driver for TI TPIC2810

[Linus Walleij]

On Mon, Jan 25, 2016 at 5:14 PM, Andrew F. Davis <afd@ti.com> wrote:

> Add driver for TI TPIC2810 8-Bit LED Driver with I2C Interface.
>
> The TPIC2810 has 8 open-drain outputs that can but used to drive
> LEDs and other low-side switched resistive loads.
>
> Signed-off-by: Andrew F. Davis <afd@ti.com>
> ---
> Changes from v1:
>  - Added OF match table at Javier Martinez Canillas request

So the TI datasheet says:
"8 bit LED driver with I2C interface"

So it is *not* "general purpose input/output" (GPIO).

It is special purpose LED drive output-only circuit.

So why can it not have a driver directly in drivers/leds/*?

I understand that it can also be used as a GPIO (and that it
is then nice to put leds-gpio on top of it) but then
I want a reference to the hardware that actually went ahead
and used this as a GPIO chip rather than using a proper
GPIO expander.

Yours,
Linus Walleij

Re: [PATCH v2] gpio: Add driver for TI TPIC2810

[Andrew F. Davis]

On 01/28/2016 04:47 AM, Linus Walleij wrote:
> On Mon, Jan 25, 2016 at 5:14 PM, Andrew F. Davis <afd@ti.com> wrote:
>
>> Add driver for TI TPIC2810 8-Bit LED Driver with I2C Interface.
>>
>> The TPIC2810 has 8 open-drain outputs that can but used to drive
>> LEDs and other low-side switched resistive loads.
>>
>> Signed-off-by: Andrew F. Davis <afd@ti.com>
>> ---
>> Changes from v1:
>>   - Added OF match table at Javier Martinez Canillas request
>
> So the TI datasheet says:
> "8 bit LED driver with I2C interface"
>
> So it is *not* "general purpose input/output" (GPIO).
>
> It is special purpose LED drive output-only circuit.
>
> So why can it not have a driver directly in drivers/leds/*?
>
> I understand that it can also be used as a GPIO (and that it
> is then nice to put leds-gpio on top of it) but then
> I want a reference to the hardware that actually went ahead
> and used this as a GPIO chip rather than using a proper
> GPIO expander.
>
> Yours,
> Linus Walleij
>

These don't really have the traditional LED features (current control,
HW blinking, etc), and all the use cases I've found treat them as GPO,
including our Industrial Dev Kits (although they run them to test LEDs
as well as the IO header):

http://www.ti.com/tool/tmdsice3359
http://www.ti.com/tool/tmdxidk437x

And a couple more that I don't think have any public schematics yet.

Like you said, they can still be used for LEDs with leds-gpio, as they
don't have any LED specific features I figure this way we get both
uses with one driver.

Andrew

Re: [PATCH v2] gpio: Add driver for TI TPIC2810

[Andy Shevchenko]

On Thu, Jan 28, 2016 at 4:56 PM, Andrew F. Davis <afd@ti.com> wrote:
> On 01/28/2016 04:47 AM, Linus Walleij wrote:

>> So the TI datasheet says:
>> "8 bit LED driver with I2C interface"
>>
>> So it is *not* "general purpose input/output" (GPIO).
>>
>> It is special purpose LED drive output-only circuit.
>>
>> So why can it not have a driver directly in drivers/leds/*?
>>
>> I understand that it can also be used as a GPIO (and that it
>> is then nice to put leds-gpio on top of it) but then
>> I want a reference to the hardware that actually went ahead
>> and used this as a GPIO chip rather than using a proper
>> GPIO expander.

> These don't really have the traditional LED features (current control,
> HW blinking, etc), and all the use cases I've found treat them as GPO,
> including our Industrial Dev Kits…

It reminds me how 12 channel PWM chip is used on Intel Galileo Gen 2.
Half pins are PWM, the other half is GPIO used for discrete based pin
muxing and control. Nevertheless I think it's a userspace issue for
now, otherwise we have to provide some 'semi-virtual' way of
presenting pins as GPIO lines.

just my 2 cents.

-- 
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] gpio: Add driver for TI TPIC2810

[Linus Walleij]

On Sun, Jan 31, 2016 at 11:52 PM, Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:

> It reminds me how 12 channel PWM chip is used on Intel Galileo Gen 2.
> Half pins are PWM, the other half is GPIO used for discrete based pin
> muxing and control. Nevertheless I think it's a userspace issue for
> now, otherwise we have to provide some 'semi-virtual' way of
> presenting pins as GPIO lines.

That sounds like an MFD spawning a GPIO and a PWM cell.
That it is called "a PWM chip" is no big deal, it should be
modeled according to what it is, not what it claims to be.

(Which makes me wanna merge this present patch as a GPIO
driver since it claims to be a LED driver but is a GPO.)

See the ST Multipurpose Expander for an example
drivers/mfd/stmpe.c
drivers/gpio/gpio-stmpe.c
drivers/input/keyboard/stmpe-keypad.c

Yours,
Linus Walleij

Re: [PATCH v2] gpio: Add driver for TI TPIC2810

[Linus Walleij]

On Thu, Jan 28, 2016 at 3:56 PM, Andrew F. Davis <afd@ti.com> wrote:

>> I understand that it can also be used as a GPIO (and that it
>> is then nice to put leds-gpio on top of it) but then
>> I want a reference to the hardware that actually went ahead
>> and used this as a GPIO chip rather than using a proper
>> GPIO expander.
>
> These don't really have the traditional LED features (current control,
> HW blinking, etc), and all the use cases I've found treat them as GPO,
> including our Industrial Dev Kits (although they run them to test LEDs
> as well as the IO header):
>
> http://www.ti.com/tool/tmdsice3359
> http://www.ti.com/tool/tmdxidk437x
>
> And a couple more that I don't think have any public schematics yet.
>
> Like you said, they can still be used for LEDs with leds-gpio, as they
> don't have any LED specific features I figure this way we get both
> uses with one driver.

Fair enough, merged as you see.

Yours,
Linus Walleij

Re: [PATCH v2] gpio: Add driver for TI TPIC2810

[Andy Shevchenko]

On Wed, Feb 10, 2016 at 4:21 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Sun, Jan 31, 2016 at 11:52 PM, Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:
>
>> It reminds me how 12 channel PWM chip is used on Intel Galileo Gen 2.
>> Half pins are PWM, the other half is GPIO used for discrete based pin
>> muxing and control. Nevertheless I think it's a userspace issue for
>> now, otherwise we have to provide some 'semi-virtual' way of
>> presenting pins as GPIO lines.
>
> That sounds like an MFD spawning a GPIO and a PWM cell.
> That it is called "a PWM chip" is no big deal, it should be
> modeled according to what it is, not what it claims to be.

Although I agree with model I barely imagine how in this case drivers
should access PWM chip registers in non-race way (take into account
that PWM itself is connected to i2c bus).

> (Which makes me wanna merge this present patch as a GPIO
> driver since it claims to be a LED driver but is a GPO.)
>
> See the ST Multipurpose Expander for an example
> drivers/mfd/stmpe.c
> drivers/gpio/gpio-stmpe.c
> drivers/input/keyboard/stmpe-keypad.c

I will look to the example later, thanks.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2] gpio: Add driver for TI TPIC2810

[Linus Walleij]

On Wed, Feb 10, 2016 at 3:29 PM, Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
> On Wed, Feb 10, 2016 at 4:21 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
>> On Sun, Jan 31, 2016 at 11:52 PM, Andy Shevchenko
>> <andy.shevchenko@gmail.com> wrote:
>>
>>> It reminds me how 12 channel PWM chip is used on Intel Galileo Gen 2.
>>> Half pins are PWM, the other half is GPIO used for discrete based pin
>>> muxing and control. Nevertheless I think it's a userspace issue for
>>> now, otherwise we have to provide some 'semi-virtual' way of
>>> presenting pins as GPIO lines.
>>
>> That sounds like an MFD spawning a GPIO and a PWM cell.
>> That it is called "a PWM chip" is no big deal, it should be
>> modeled according to what it is, not what it claims to be.
>
> Although I agree with model I barely imagine how in this case drivers
> should access PWM chip registers in non-race way (take into account
> that PWM itself is connected to i2c bus).

There is a pattern for that. You add a set of accessor functions that
performs the I2C traffic in the MFD layer.

The accessor functions take a mutex. Since this is all slowpath,
waiting/preempting in a mutex is perfectly fine for all subdrivers.

Look at this:

/**
 * stmpe_reg_write() - write a single STMPE register
 * @stmpe:      Device to write to
 * @reg:        Register to write
 * @val:        Value to write
 */
int stmpe_reg_write(struct stmpe *stmpe, u8 reg, u8 val)
{
        int ret;

        mutex_lock(&stmpe->lock);
        ret = __stmpe_reg_write(stmpe, reg, val);
        mutex_unlock(&stmpe->lock);

        return ret;
}
EXPORT_SYMBOL_GPL(stmpe_reg_write);

Yours,
Linus Walleij