On Tue, Apr 12, 2016 at 2:15 PM, Mark Brown wrote:
> On Thu, Apr 07, 2016 at 11:24:00PM +0200, Rafael J. Wysocki wrote:
>> On Wednesday, April 06, 2016 11:39:27 AM Mark Rutland wrote:
>
>> > The ACPI model implies FW-driven pinctrl management, so if we're going to
>> > put
>> > the OS in direct c
On Thu, Apr 07, 2016 at 11:24:00PM +0200, Rafael J. Wysocki wrote:
> On Wednesday, April 06, 2016 11:39:27 AM Mark Rutland wrote:
> > The ACPI model implies FW-driven pinctrl management, so if we're going to
> > put
> > the OS in direct control of pinctrl, we have to make clear what expectation
On Wednesday, April 06, 2016 11:39:27 AM Mark Rutland wrote:
> On Thu, Apr 07, 2016 at 03:11:53PM +0300, Octavian Purdila wrote:
> > On Wed, Apr 6, 2016 at 3:01 AM, Mark Rutland wrote:
> > > On Tue, Apr 05, 2016 at 11:09:34PM +0300, Octavian Purdila wrote:
> > >> On Tue, Apr 5, 2016 at 9:16 PM, Ma
On Thu, Apr 7, 2016 at 4:17 PM, Octavian Purdila
wrote:
> On Wed, Apr 6, 2016 at 1:49 PM, Graeme Gregory wrote:
>> Why has there been no attempt in ASWG to make these sort of features a
>> 1st class citizen of ACPI so they can interact correctly with the other
>> features?
>
> IMO having an ASWG
On Thu, Apr 07, 2016 at 03:11:53PM +0300, Octavian Purdila wrote:
> On Wed, Apr 6, 2016 at 3:01 AM, Mark Rutland wrote:
> > On Tue, Apr 05, 2016 at 11:09:34PM +0300, Octavian Purdila wrote:
> >> On Tue, Apr 5, 2016 at 9:16 PM, Mark Rutland wrote:
> >> > * The firmware is to some extent expected t
On Wed, Apr 6, 2016 at 1:49 PM, Graeme Gregory wrote:
>>
>> I have to echo Mark's concern: wholesale importation of portions of current
>> DT bindings simply because it's expedient is one of the things I've been
>> hoping
>> to avoid. These patches seem to be just that.
>>
>> And while the late
On Wed, Apr 6, 2016 at 3:01 AM, Mark Rutland wrote:
> On Tue, Apr 05, 2016 at 11:09:34PM +0300, Octavian Purdila wrote:
>> On Tue, Apr 5, 2016 at 9:16 PM, Mark Rutland wrote:
>> > * The firmware is to some extent expected to manage pinctrl today (for
>> > power
>> > management of devices it do
On Tue, Apr 05, 2016 at 06:00:31PM -0600, Al Stone wrote:
> On 04/05/2016 02:56 AM, Charles Garcia-Tobin wrote:
> >
> >
> > On 04/04/2016 23:52, "Mark Rutland" wrote:
> >
> >> Hi,
> >>
> >> On Thu, Mar 31, 2016 at 02:44:41PM +0300, Irina Tirdea wrote:
> >>> This is a proposal for adding ACPI su
On Tue, Apr 05, 2016 at 10:37:14PM +0300, Octavian Purdila wrote:
> On Tue, Apr 5, 2016 at 7:59 PM, Mark Brown wrote:
[...]
> Lets look at this from a different perspective. The proposal is not
> about importing the DT model into ACPI but importing the Linux pinctrl
> model into ACPI. That will
On Tue, Apr 05, 2016 at 11:09:34PM +0300, Octavian Purdila wrote:
> On Tue, Apr 5, 2016 at 9:16 PM, Mark Rutland wrote:
> > * The firmware is to some extent expected to manage pinctrl today (for power
> > management of devices it does know about), and hence a pinctrl device is
> > potentially
On 04/05/2016 02:56 AM, Charles Garcia-Tobin wrote:
>
>
> On 04/04/2016 23:52, "Mark Rutland" wrote:
>
>> Hi,
>>
>> On Thu, Mar 31, 2016 at 02:44:41PM +0300, Irina Tirdea wrote:
>>> This is a proposal for adding ACPI support for pin controller
>>> configuration.
>>>
>>> It has been developed to
On 04/05/2016 01:37 PM, Octavian Purdila wrote:
> On Tue, Apr 5, 2016 at 7:59 PM, Mark Brown wrote:
>> On Tue, Apr 05, 2016 at 10:43:11AM +0200, Linus Walleij wrote:
>>[snip...]
>
> I know that there are some discussions for pinmux configuration in the
> ASWG, but it does not match the Linux pinc
On Tue, Apr 05, 2016 at 10:37:14PM +0300, Octavian Purdila wrote:
> On Tue, Apr 5, 2016 at 7:59 PM, Mark Brown wrote:
> > On Tue, Apr 05, 2016 at 10:43:11AM +0200, Linus Walleij wrote:
> >> And these products are only update-able
> >> with hairy BIOS patches that need to be applied
> >> using $SP
On Tue, Apr 5, 2016 at 9:16 PM, Mark Rutland wrote:
>>
>> Right, there is an overlap of the pinctrl "sleep" state with the ACPI power
>> management model.
>>
>> However, the main reason for implementing this is setting initial pin
>> multiplexing
>> and configuration. This is normally done by BI
On Tue, Apr 5, 2016 at 7:59 PM, Mark Brown wrote:
> On Tue, Apr 05, 2016 at 10:43:11AM +0200, Linus Walleij wrote:
>
>> And these products are only update-able
>> with hairy BIOS patches that need to be applied
>> using $SPECIAL_TOOL that "normal users" do not want to
>> concern themselves with,
On Tue, Apr 05, 2016 at 03:33:43PM +, Tirdea, Irina wrote:
> > -Original Message-
> > From: Mark Rutland [mailto:mark.rutl...@arm.com]
> > On Thu, Mar 31, 2016 at 02:44:41PM +0300, Irina Tirdea wrote:
> > > This is a proposal for adding ACPI support for pin controller
> > > configuratio
On Tue, Apr 05, 2016 at 03:51:18PM +0300, Octavian Purdila wrote:
> On Tue, Apr 5, 2016 at 12:40 AM, Mark Brown wrote:
> > So this is mainly targeted at modules being added to base boards?
> That is the main use case, yes. Velocity of platform
> debugging/enabling is another one.
The speed thin
On Tue, Apr 05, 2016 at 10:43:11AM +0200, Linus Walleij wrote:
> And these products are only update-able
> with hairy BIOS patches that need to be applied
> using $SPECIAL_TOOL that "normal users" do not want to
> concern themselves with, as this is not an "apt-get upgrade"
> kind of thing.
This
On Tue, Apr 05, 2016 at 11:00:50AM +0200, Linus Walleij wrote:
> On Mon, Apr 4, 2016 at 11:40 PM, Mark Brown wrote:
> > So this is mainly targeted at modules being added to base boards?
> > Without getting into the binding at all here it seems like this is not
> > solving the problem at the right
Heikki Krogerus; Andy Shevchenko; Purdila, Octavian; Ciocan,
> Cristina; devicet...@vger.kernel.org; linux-
> ker...@vger.kernel.org; charles.garcia-to...@arm.com
> Subject: Re: [RFC PATCH 0/4] Add ACPI support for pinctrl configuration
>
> Hi,
Hi Mark,
>
> On Thu, Mar 31, 20
On Tue, Apr 5, 2016 at 12:40 AM, Mark Brown wrote:
> On Thu, Mar 31, 2016 at 02:44:41PM +0300, Irina Tirdea wrote:
>
>> This is a proposal for adding ACPI support for pin controller
>> configuration.
>
>> It has been developed to enable the MinnowBoard and IoT community
>> by providing an easy way
On 04/04/2016 23:52, "Mark Rutland" wrote:
>Hi,
>
>On Thu, Mar 31, 2016 at 02:44:41PM +0300, Irina Tirdea wrote:
>> This is a proposal for adding ACPI support for pin controller
>> configuration.
>>
>> It has been developed to enable the MinnowBoard and IoT community
>> by providing an easy wa
On Mon, Apr 4, 2016 at 11:40 PM, Mark Brown wrote:
> On Thu, Mar 31, 2016 at 02:44:41PM +0300, Irina Tirdea wrote:
>
>> This is a proposal for adding ACPI support for pin controller
>> configuration.
>
>> It has been developed to enable the MinnowBoard and IoT community
>> by providing an easy way
On Tue, Apr 5, 2016 at 12:52 AM, Mark Rutland wrote:
> On Thu, Mar 31, 2016 at 02:44:41PM +0300, Irina Tirdea wrote:
>> This proposal is based on using _DSD properties to specify device
>> states and configuration nodes and it follows closely the device
>> tree model. Device states are defined us
On Thu, Mar 31, 2016 at 02:44:41PM +0300, Irina Tirdea wrote:
> This is a proposal for adding ACPI support for pin controller
> configuration.
> It has been developed to enable the MinnowBoard and IoT community
> by providing an easy way to specify pin multiplexing and
> pin configuration.
So th
Hi,
On Thu, Mar 31, 2016 at 02:44:41PM +0300, Irina Tirdea wrote:
> This is a proposal for adding ACPI support for pin controller
> configuration.
>
> It has been developed to enable the MinnowBoard and IoT community
> by providing an easy way to specify pin multiplexing and
> pin configuration.
This is a proposal for adding ACPI support for pin controller
configuration.
It has been developed to enable the MinnowBoard and IoT community
by providing an easy way to specify pin multiplexing and
pin configuration.
This proposal is based on using _DSD properties to specify device
states and c
27 matches
Mail list logo
