On Fri, Apr 25, 2014 at 9:31 AM, Timur Tabi wrote:
> Rafael J. Wysocki wrote:
>>
>> I would be interested in understanding what exactly the flow is in that
>> situation, so care to educate me? What does the driver do to trigger
>> this and what exactly does happen in response to that?
>
>
> I onl
Rafael J. Wysocki wrote:
I would be interested in understanding what exactly the flow is in that
situation, so care to educate me? What does the driver do to trigger
this and what exactly does happen in response to that?
I only just learned some of this myself, so I'm no expert. My
unders
On 4/25/2014 6:13 PM, Timur Tabi wrote:
Westerberg, Mika wrote:
If you happen to have pin controller/mux driver that drives that
hardware,
I'm sure your pinmux functions gets called.
Actually, I don't think they do. On a device-tree system, the
functions get called automatically by the pinc
Westerberg, Mika wrote:
If you happen to have pin controller/mux driver that drives that hardware,
I'm sure your pinmux functions gets called.
Actually, I don't think they do. On a device-tree system, the functions
get called automatically by the pinctrl layer when it parses the device
tree.
On Fri, Apr 25, 2014 at 9:41 AM, Westerberg, Mika
wrote:
> On Thu, Apr 24, 2014 at 10:25:56AM -0500, Timur Tabi wrote:
>> On 04/24/2014 06:58 AM, Westerberg, Mika wrote:
>> >>>No, that's my point. I was expecting the pinmux functions of the
>> >>>pinctrl driver are used by ACPI, but apparently th
On Thu, Apr 24, 2014 at 10:25:56AM -0500, Timur Tabi wrote:
> On 04/24/2014 06:58 AM, Westerberg, Mika wrote:
> >>>No, that's my point. I was expecting the pinmux functions of the
> >>>pinctrl driver are used by ACPI, but apparently they aren't, and
> >>>that's why I'm asking.
>
> >Which function
On 04/24/2014 06:58 AM, Westerberg, Mika wrote:
>No, that's my point. I was expecting the pinmux functions of the
>pinctrl driver are used by ACPI, but apparently they aren't, and
>that's why I'm asking.
Which functions?
The functions in struct pinmux_ops, like get_function_groups. Will
t
On Thu, Apr 24, 2014 at 1:58 PM, Westerberg, Mika
wrote:
> On Thu, Apr 24, 2014 at 06:18:38AM -0500, Timur Tabi wrote:
>> I'm wondering why a pinctrl driver for an
>> ACPI platform should be defining pinmux function groups. I haven't
>> gotten a straight answer to that question.
>
> Are you aski
On Thu, Apr 24, 2014 at 06:18:38AM -0500, Timur Tabi wrote:
> Westerberg, Mika wrote:
> >>>That is, when the kernel parses the ASL, and it seems a command to
> >>>configure pin #3 to function #4, it calls the local pinctrl driver to do
> >>>that?
>
> >I'm not aware of ASL code that allows you to d
On Thu, Apr 24, 2014 at 06:20:02AM -0500, Timur Tabi wrote:
> Westerberg, Mika wrote:
> >Typically this is done by the boot firmware (BIOS in this case). So the OS
> >doesn't need to deal with that.
> >
> >AFAICT ACPI doesn't know anything about pin muxing.
>
> In that case, would it be correct to
Westerberg, Mika wrote:
Typically this is done by the boot firmware (BIOS in this case). So the OS
doesn't need to deal with that.
AFAICT ACPI doesn't know anything about pin muxing.
In that case, would it be correct to say that a Linux pinctrl driver for
an ACPI-only platform should not defi
Westerberg, Mika wrote:
>That is, when the kernel parses the ASL, and it seems a command to
>configure pin #3 to function #4, it calls the local pinctrl driver to do
>that?
I'm not aware of ASL code that allows you to do that. Do you have examples?
No, that's my point. I was expecting the p
On Wed, Apr 23, 2014 at 10:14:20AM -0500, Timur Tabi wrote:
> Westerberg, Mika wrote:
> >It doesn't do any pin control nor muxing and I'm not sure if it is
> >required. Can you elaborate why you think pin muxing is required with
> >GpioIo/GpioInt resources?
>
> How are the pin muxes normally confi
On Thu, Apr 24, 2014 at 12:20:12AM +0200, Linus Walleij wrote:
> On Wed, Apr 23, 2014 at 5:14 PM, Timur Tabi wrote:
>
> > How are the pin muxes normally configured in ACPI?
>
> VERY good question.
Typically this is done by the boot firmware (BIOS in this case). So the OS
doesn't need to deal wi
Linus Walleij wrote:
> All of our GPIOs have a
>pinmux on them, and so if you want to use the pin for the non-default
>functionality, you need to configure the mux. Isn't that supposed to happen
>with the through the pinctrl driver? That is, when the kernel parses the
>ASL, and it seems a comm
On Wed, Apr 23, 2014 at 5:14 PM, Timur Tabi wrote:
> How are the pin muxes normally configured in ACPI?
VERY good question.
> All of our GPIOs have a
> pinmux on them, and so if you want to use the pin for the non-default
> functionality, you need to configure the mux. Isn't that supposed to
On Sat, Apr 12, 2014 at 12:54 AM, Timur Tabi wrote:
> I know it's been ten months since you posted this driver, but I have a
> question. If this driver does not touch the pin muxing, and it
> doesn't even call pinctrl_register(), then why is it in
> drivers/pinctrl? It's not a pinctrl driver.
Westerberg, Mika wrote:
It doesn't do any pin control nor muxing and I'm not sure if it is
required. Can you elaborate why you think pin muxing is required with
GpioIo/GpioInt resources?
How are the pin muxes normally configured in ACPI? All of our GPIOs
have a pinmux on them, and so if you w
On Wed, Apr 23, 2014 at 07:07:13AM -0500, Timur Tabi wrote:
> Mathias Nyman wrote:
> >
> >Helper functions to translate the ACPI GpioIO and GpioInt resources to
> >linux gpio numbers can be found in gpio/gpiolib-acpi.c together with
> >other ACPI and gpio related helper functions.
>
> Does this al
Mathias Nyman wrote:
Helper functions to translate the ACPI GpioIO and GpioInt resources to
linux gpio numbers can be found in gpio/gpiolib-acpi.c together with
other ACPI and gpio related helper functions.
Does this also cover pin control and pin muxing? Sorry, but I sometimes
I get confuse
On 04/17/2014 07:47 PM, Timur Tabi wrote:
On 04/15/2014 05:01 AM, Mathias Nyman wrote:
This device will only be used on an ACPI system, right? And isn't ACPI
supposed to hide all the pinctrl programming from the OS? I thought
that was the whole point behind ACPI and the reason why ARM64 isn't
On 04/15/2014 05:01 AM, Mathias Nyman wrote:
This device will only be used on an ACPI system, right? And isn't ACPI
supposed to hide all the pinctrl programming from the OS? I thought
that was the whole point behind ACPI and the reason why ARM64 isn't
going to use device trees.
This was my
On 04/14/2014 06:11 PM, Timur Tabi wrote:
On 04/14/2014 02:52 AM, Mathias Nyman wrote:
This was the conclusion we reached after some discussion with Linus W.
Initially this was just a GPIO driver, but Linus correctly spotted that
Baytrail has many pinctrl-like features (like pin muxing, etc)
On 04/14/2014 02:52 AM, Mathias Nyman wrote:
This was the conclusion we reached after some discussion with Linus W.
Initially this was just a GPIO driver, but Linus correctly spotted that
Baytrail has many pinctrl-like features (like pin muxing, etc) that we
might need to address in the future
On 04/12/2014 01:54 AM, Timur Tabi wrote:
On Tue, Jun 18, 2013 at 6:33 AM, Mathias Nyman
wrote:
Pins may be muxed to alternate function instead of gpio by firmware.
This driver does not touch the pin muxing and expect firmare
to set pin muxing and pullup/down properties properly.
Signed-off-b
On Tue, Jun 18, 2013 at 6:33 AM, Mathias Nyman
wrote:
>
> Pins may be muxed to alternate function instead of gpio by firmware.
> This driver does not touch the pin muxing and expect firmare
> to set pin muxing and pullup/down properties properly.
>
> Signed-off-by: Mathias Nyman
> ---
> drivers/
On 06/18/2013 06:17 PM, Linus Walleij wrote:
On Tue, Jun 18, 2013 at 1:33 PM, Mathias Nyman
wrote:
Add support for gpio on Intel BayTrail platforms. BayTrail supports 3 banks
of gpios called SCORE, NCORE ans SUS with 102, 28 and 44 gpio pins.
Supports gpio interrupts and ACPI gpio events
Pin
On Tue, Jun 18, 2013 at 1:33 PM, Mathias Nyman
wrote:
> Add support for gpio on Intel BayTrail platforms. BayTrail supports 3 banks
> of gpios called SCORE, NCORE ans SUS with 102, 28 and 44 gpio pins.
> Supports gpio interrupts and ACPI gpio events
>
> Pins may be muxed to alternate function ins
28 matches
Mail list logo