linux-kernel - Re: Portable Device Tree Connector -- conceptual

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5776DCA0.2020406@gmail.com>
Date:	Fri, 1 Jul 2016 14:12:00 -0700
From:	Frank Rowand <frowand.list@...il.com>
To:	Pantelis Antoniou <pantelis.antoniou@...sulko.com>
Cc:	Rob Herring <robh+dt@...nel.org>,
	David Gibson <david@...son.dropbear.id.au>,
	Stephen Boyd <stephen.boyd@...aro.org>,
	Mark Brown <broonie@...nel.org>,
	Grant Likely <grant.likely@...retlab.ca>,
	Mark Rutland <mark.rutland@....com>,
	Matt Porter <mporter@...sulko.com>,
	Koen Kooi <koen@...inion.thruhere.net>,
	Guenter Roeck <linux@...ck-us.net>,
	Marek Vasut <marex@...x.de>, Wolfram Sang <wsa@...-dreams.de>,
	devicetree <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	linux-i2c@...r.kernel.org
Subject: Re: Portable Device Tree Connector -- conceptual

On 07/01/16 12:49, Pantelis Antoniou wrote:
> Hi Frank,
> 
>> On Jul 1, 2016, at 21:21 , Frank Rowand <frowand.list@...il.com> wrote:
>>
>> On 07/01/16 09:56, Pantelis Antoniou wrote:
>>> Hi Frank,
>>>
>>>> On Jul 1, 2016, at 19:31 , Frank Rowand <frowand.list@...il.com> wrote:
>>>>
>>>> On 07/01/16 03:59, Pantelis Antoniou wrote:
>>>>> Hi Frank,
>>>>>
>>>>> Comments inline.
>>>>>
>>>>>> On Jul 1, 2016, at 03:02 , Frank Rowand <frowand.list@...il.com> wrote:

< snip >

>>>>> Your example works as long as you assume that there’s no pinmuxing
>>>>> related to the configuration of the spi controller when routed out
>>>>> to the connector pins.
>>>>
>>>> No.  Pinmuxing is part of the host board dts.
>>>>
>>>
>>> It is part of the host board DTS yes, but the connector must have
>>> a way to set the pinmux configuration according what the detected
>>> expansion board expects.
>>>
>>>> The physical connector does not change the way that pinmuxing
>>>> works.  It is just the same as if there were wires physically
>>>> connected (soldered) between the daughter board and the main
>>>> board.
>>>>
>>>
>>> The physical properties of the pin of the connector do not change.
>>>
>>> However the routing of functions in the SoC do change.
>>>
>>> By default most of the pins on the connector are HiZ or set to input when
>>> no expansion board is connected. The only fixed function pins that are
>>> known and configured by the host board dts are those that are used by
>>> the host board’s identification scheme (i.e. I2C EEPROM, set of GPIO inputs
>>> etc). 
>>>
>>> When an expansion board is connected upon boot and probing of the the expansion
>>> board manager device it will use a method that is using the configured detection
>>> pins to identify it.
>>>
>>> After getting the ID it is going to find a corresponding overlay to apply.
>>>
>>> This overlay will have to configure each pin accordingly.
>>>
>>> It is perfectly for a pin on a connector to be a GPIO output for expansion
>>> board A, I2C bus SDA for board B, etc...
>>>
>>> So there has to be a way to get the pinmux configuration according to the
>>> required connection function on each pin in use.
>>
>> Again, this is exactly the same concept as if the daughter board was soldered
>> directly to the host board with no connector involved.  The pinmux
>> configuration has nothing to do with the physical connector, it is already
>> described by the pinmux information in the host board .dtb.  The connector
>> node in the host .dtb does not need to duplicate any of that information.
>>
>> There already is a pinmux mechanism in place to choose which of the
>> possible alternative uses of a set of pins is in use at any point
>> in time.  The choice of active functionality can be changed at
>> any time.
>>
>> The pinmux configuration is already in place in the host board .dtb.
>> The host board .dtb connector node only provides a mapping to what
>> other nodes have hardware blocks that have signals that are routed
>> to the physical connector.  There is no need for the connector node
>> to be concerned with any of the details of those other nodes -- the
>> other nodes already specify the details.
>>
> 
> The mechanism to choose which of the possible alternative uses is
> geared to select between a different set of configuration settings
> for the same device. I.e. “default” -> working configuration, “powersave” ->
> put the pins in power save mode, etc.

Doesn't pinmuxing also support the case where one set of pins (or two
overlapping sets of pins) is used by two different hardware blocks and
the user wants to change which block is currently using the pins?

For instance, a headphone jack might normally supply audio, but the
user might want to change the jack to supply an RS-232 console.


> 
> I get what you’re saying but the details about pinmuxing are the killer.
> 
> Can you please spend some time and come up with an example which we can
> use as a basis for discussion?

Example above.  Putting the headphone jack on the daughter board should be
the same as if the headphone jack is on the host board from the perspective
of pinmux.

< snip >