On Thu, Aug 22, 2013 at 1:23 AM, Stephen Warren wrote:
> Shouldn't this simply be fixed inside whichever driver is performing
> circular operations, rather than leaving the driver performing circular
> operations, and attemping to make the subsystems support something that
> can't be supported?
On 08/21/2013 05:07 PM, Linus Walleij wrote:
> On Mon, Aug 19, 2013 at 9:15 PM, Stephen Warren wrote:
>> On 08/17/2013 08:56 AM, Linus Walleij wrote:
>
>>> and the pin controller need the GPIO driver to be ready.
>>
>> Why does that happen?
>
> The pin controller call back into the GPIO-side
On Mon, Aug 19, 2013 at 9:15 PM, Stephen Warren wrote:
> On 08/17/2013 08:56 AM, Linus Walleij wrote:
>> and the pin controller need the GPIO driver to be ready.
>
> Why does that happen?
The pin controller call back into the GPIO-side controller
functions by utilizing the GPIO ranges.
(Maybe
On Wed, Aug 21, 2013 at 7:45 PM, Stephen Warren wrote:
> On 08/19/2013 01:21 PM, Stephen Warren wrote:
>> On 08/17/2013 08:56 AM, Linus Walleij wrote:
>>> We currently defer probing of the caller if a pinctrl GPIO
>>> request or direction setting comes in before the range mapping
>>> a certain
On 08/19/2013 01:21 PM, Stephen Warren wrote:
> On 08/17/2013 08:56 AM, Linus Walleij wrote:
>> We currently defer probing of the caller if a pinctrl GPIO
>> request or direction setting comes in before the range mapping
>> a certain GPIO to a certain pin controller is available.
>>
>> This can
On 08/19/2013 01:21 PM, Stephen Warren wrote:
On 08/17/2013 08:56 AM, Linus Walleij wrote:
We currently defer probing of the caller if a pinctrl GPIO
request or direction setting comes in before the range mapping
a certain GPIO to a certain pin controller is available.
This can end up with a
On Wed, Aug 21, 2013 at 7:45 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 08/19/2013 01:21 PM, Stephen Warren wrote:
On 08/17/2013 08:56 AM, Linus Walleij wrote:
We currently defer probing of the caller if a pinctrl GPIO
request or direction setting comes in before the range mapping
a
On Mon, Aug 19, 2013 at 9:15 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 08/17/2013 08:56 AM, Linus Walleij wrote:
and the pin controller need the GPIO driver to be ready.
Why does that happen?
The pin controller call back into the GPIO-side controller
functions by utilizing the GPIO
On 08/21/2013 05:07 PM, Linus Walleij wrote:
On Mon, Aug 19, 2013 at 9:15 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 08/17/2013 08:56 AM, Linus Walleij wrote:
and the pin controller need the GPIO driver to be ready.
Why does that happen?
The pin controller call back into the
On Thu, Aug 22, 2013 at 1:23 AM, Stephen Warren swar...@wwwdotorg.org wrote:
Shouldn't this simply be fixed inside whichever driver is performing
circular operations, rather than leaving the driver performing circular
operations, and attemping to make the subsystems support something that
On 08/17/2013 08:56 AM, Linus Walleij wrote:
> We currently defer probing of the caller if a pinctrl GPIO
> request or direction setting comes in before the range mapping
> a certain GPIO to a certain pin controller is available.
>
> This can end up with a circular dependency: the GPIO driver
>
On 08/17/2013 08:56 AM, Linus Walleij wrote:
> We currently defer probing of the caller if a pinctrl GPIO
> request or direction setting comes in before the range mapping
> a certain GPIO to a certain pin controller is available.
>
> This can end up with a circular dependency: the GPIO driver
>
On 08/17/2013 08:56 AM, Linus Walleij wrote:
We currently defer probing of the caller if a pinctrl GPIO
request or direction setting comes in before the range mapping
a certain GPIO to a certain pin controller is available.
This can end up with a circular dependency: the GPIO driver
needs
On 08/17/2013 08:56 AM, Linus Walleij wrote:
We currently defer probing of the caller if a pinctrl GPIO
request or direction setting comes in before the range mapping
a certain GPIO to a certain pin controller is available.
This can end up with a circular dependency: the GPIO driver
needs
We currently defer probing of the caller if a pinctrl GPIO
request or direction setting comes in before the range mapping
a certain GPIO to a certain pin controller is available.
This can end up with a circular dependency: the GPIO driver
needs the pin controller to be ready and the pin
We currently defer probing of the caller if a pinctrl GPIO
request or direction setting comes in before the range mapping
a certain GPIO to a certain pin controller is available.
This can end up with a circular dependency: the GPIO driver
needs the pin controller to be ready and the pin
16 matches
Mail list logo
