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
On Fri, Apr 25, 2014 at 9:31 AM, Timur Tabi ti...@codeaurora.org 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?
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
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
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
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
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
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 functions?
The
On Fri, Apr 25, 2014 at 9:41 AM, Westerberg, Mika
mika.westerb...@intel.com 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
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
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
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
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
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
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
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
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
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
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
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
On Thu, Apr 24, 2014 at 12:20:12AM +0200, Linus Walleij wrote:
On Wed, Apr 23, 2014 at 5:14 PM, Timur Tabi ti...@codeaurora.org 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
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 configured in
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
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
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 say that
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 do that. Do you
On Thu, Apr 24, 2014 at 1:58 PM, Westerberg, Mika
mika.westerb...@intel.com 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
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
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
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
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
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
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
On Sat, Apr 12, 2014 at 12:54 AM, Timur Tabi ti...@codeaurora.org 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
On Wed, Apr 23, 2014 at 5:14 PM, Timur Tabi ti...@codeaurora.org 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
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 command
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
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
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 also cover
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
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/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 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
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.
On 04/12/2014 01:54 AM, Timur Tabi wrote:
On Tue, Jun 18, 2013 at 6:33 AM, Mathias Nyman
mathias.ny...@linux.intel.com 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
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
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
> ---
>
On Tue, Jun 18, 2013 at 6:33 AM, Mathias Nyman
mathias.ny...@linux.intel.com 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
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
On 06/18/2013 06:17 PM, Linus Walleij wrote:
On Tue, Jun 18, 2013 at 1:33 PM, Mathias Nyman
mathias.ny...@linux.intel.com 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
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
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 instead of gpio by firmware.
This driver does not touch the pin
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 instead of gpio by firmware.
This driver does not touch the pin
On Tue, Jun 18, 2013 at 1:33 PM, Mathias Nyman
mathias.ny...@linux.intel.com 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
58 matches
Mail list logo
