On Monday 23 April 2007, Paul Sokolovsky wrote:
> Hello David,
>
> Thursday, April 19, 2007, 5:22:44 AM, you wrote:
>
> >> >> > So, talking about what an (optional) implementation framework might
> >> >> > look like (and which could handle the SOC, FPGA, I2C, and MFD cases
> >> >> > I've looked
Hello David,
Thursday, April 19, 2007, 5:22:44 AM, you wrote:
>> >> > So, talking about what an (optional) implementation framework might
>> >> > look like (and which could handle the SOC, FPGA, I2C, and MFD cases
>> >> > I've looked at):
>>
>> > See patches in following messages ... a
Hello David,
Thursday, April 19, 2007, 5:22:44 AM, you wrote:
So, talking about what an (optional) implementation framework might
look like (and which could handle the SOC, FPGA, I2C, and MFD cases
I've looked at):
See patches in following messages ... a preliminary gpio_chip core
On Monday 23 April 2007, Paul Sokolovsky wrote:
Hello David,
Thursday, April 19, 2007, 5:22:44 AM, you wrote:
So, talking about what an (optional) implementation framework might
look like (and which could handle the SOC, FPGA, I2C, and MFD cases
I've looked at):
See patches
> >> > So, talking about what an (optional) implementation framework might
> >> > look like (and which could handle the SOC, FPGA, I2C, and MFD cases
> >> > I've looked at):
>
> > See patches in following messages ... a preliminary "gpio_chip" core
> > for such a framework, plus example support
So, talking about what an (optional) implementation framework might
look like (and which could handle the SOC, FPGA, I2C, and MFD cases
I've looked at):
See patches in following messages ... a preliminary gpio_chip core
for such a framework, plus example support for one SOC family's
Hello David,
Sunday, April 15, 2007, 10:47:57 PM, you wrote:
> On Thursday 12 April 2007 6:57 am, Paul Sokolovsky wrote:
>> Wednesday, April 11, 2007, 7:52:20 AM, you wrote:
>> > So, talking about what an (optional) implementation framework might
>> > look like (and which could handle the SOC,
Hello David,
Sunday, April 15, 2007, 10:47:57 PM, you wrote:
On Thursday 12 April 2007 6:57 am, Paul Sokolovsky wrote:
Wednesday, April 11, 2007, 7:52:20 AM, you wrote:
So, talking about what an (optional) implementation framework might
look like (and which could handle the SOC, FPGA,
To merge, this would be split apart ... what's interesting here is
the way the new leds-gpio driver can be made to talk to leds that
sit across an I2C link.
== CUT HERE
This presumes various patches updating:
- LED framework to support generic GPIOs (in MM and LED queue)
- LED
Makes OMAP use the infrastructure in the preceding patch; slightly
slows down the code, because it adds an indirect function call and
uses a non-table lookup, but GPIOs aren't accessed on critical paths.
=== CUT HERE
Update OMAP to use the new GPIO implementation framework. This is
This patch shows some almost-mergeable code matching $SUBJECT.
CUT HERE
Provide some implementation infrastructure that platforms may choose
to use when implementing the GPIO programming interface.
As previously discussed on LKML, this can be very desirable on some
platforms --
On Thursday 12 April 2007 6:57 am, Paul Sokolovsky wrote:
> Wednesday, April 11, 2007, 7:52:20 AM, you wrote:
> > So, talking about what an (optional) implementation framework might
> > look like (and which could handle the SOC, FPGA, I2C, and MFD cases
> > I've looked at):
See patches in
On Thursday 12 April 2007 6:57 am, Paul Sokolovsky wrote:
Wednesday, April 11, 2007, 7:52:20 AM, you wrote:
So, talking about what an (optional) implementation framework might
look like (and which could handle the SOC, FPGA, I2C, and MFD cases
I've looked at):
See patches in following
To merge, this would be split apart ... what's interesting here is
the way the new leds-gpio driver can be made to talk to leds that
sit across an I2C link.
== CUT HERE
This presumes various patches updating:
- LED framework to support generic GPIOs (in MM and LED queue)
- LED
Makes OMAP use the infrastructure in the preceding patch; slightly
slows down the code, because it adds an indirect function call and
uses a non-table lookup, but GPIOs aren't accessed on critical paths.
=== CUT HERE
Update OMAP to use the new GPIO implementation framework. This is
This patch shows some almost-mergeable code matching $SUBJECT.
CUT HERE
Provide some implementation infrastructure that platforms may choose
to use when implementing the GPIO programming interface.
As previously discussed on LKML, this can be very desirable on some
platforms --
Hello David,
Wednesday, April 11, 2007, 7:52:20 AM, you wrote:
> On Tuesday 10 April 2007 4:11 pm, Paul Sokolovsky wrote:
>>
>> > /* defined by the platform using array, if/else/..., IDR, or
>> > whatever */
>> > struct gpio_yyy *gpio_to_yyy(unsigned gpio);
>>
>>I assume
Hello David,
Wednesday, April 11, 2007, 7:52:20 AM, you wrote:
On Tuesday 10 April 2007 4:11 pm, Paul Sokolovsky wrote:
/* defined by the platform using array, if/else/..., IDR, or
whatever */
struct gpio_yyy *gpio_to_yyy(unsigned gpio);
I assume by platform you
On Tuesday 10 April 2007 4:11 pm, Paul Sokolovsky wrote:
>
> > /* defined by the platform using array, if/else/..., IDR, or
> > whatever */
> > struct gpio_yyy *gpio_to_yyy(unsigned gpio);
>
>I assume by "platform" you mean CPU architecture.
Nope. ARM (v4, v5, v6, etc) is
Hello David,
Monday, April 9, 2007, 11:22:25 PM, you wrote:
> On Monday 09 April 2007 10:18 am, Paul Sokolovsky wrote:
>> > Nobody who really wants to have such an implementation framework has yet
>> > ponied up and done the work to make one.
>>
>> Well, sorry if it wasn't made clear, but we
Hello David,
Monday, April 9, 2007, 11:22:25 PM, you wrote:
On Monday 09 April 2007 10:18 am, Paul Sokolovsky wrote:
Nobody who really wants to have such an implementation framework has yet
ponied up and done the work to make one.
Well, sorry if it wasn't made clear, but we
On Tuesday 10 April 2007 4:11 pm, Paul Sokolovsky wrote:
/* defined by the platform using array, if/else/..., IDR, or
whatever */
struct gpio_yyy *gpio_to_yyy(unsigned gpio);
I assume by platform you mean CPU architecture.
Nope. ARM (v4, v5, v6, etc) is a CPU
22 matches
Mail list logo
