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]
Date:	Fri, 15 Apr 2016 23:19:45 +0530
From:	Laxman Dewangan <ldewangan@...dia.com>
To:	Jon Hunter <jonathanh@...dia.com>, <swarren@...dotorg.org>,
	<thierry.reding@...il.com>, <linus.walleij@...aro.org>,
	<gnurou@...il.com>, <robh+dt@...nel.org>, <mark.rutland@....com>
CC:	<linux-tegra@...r.kernel.org>, <devicetree@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <linux-gpio@...r.kernel.org>
Subject: Re: [PATCH 6/7] pinctrl: tegra: Add DT binding for io pads control


On Friday 15 April 2016 11:14 PM, Jon Hunter wrote:
> On 15/04/16 17:41, Laxman Dewangan wrote:
>> On Friday 15 April 2016 09:15 PM, Jon Hunter wrote:
>>> On 15/04/16 16:14, Laxman Dewangan wrote:
>>>> I used pins as this is the property from pincon generic so that I can
>>>> use the generic implementation.
>>>>
>>>> Here, I will not go to the pin level control as HW does not support pin
>>>> level control.
>>>>
>>>> I will say the unit should be interface level. Should we say
>>>> IO_GROUP_CSIA, IO_GROUP_CSIB etc?
>>> So we need to reflect the hardware in device-tree and although yes the
>>> power-down for the CSI_x_xxx pads are all controlled together as a
>>> single group, it does not feel right that we add a pseudo pin called
>>> csix to represent these.
>>>
>>> The CSI_x_xxx pads are already in device-tree and so why not add a
>>> property to each of these pads which has the IO rail information for
>>> power-down and voltage-select?
>> Which dt binding docs have these?
>> I looked for nvidia,tegra210-pinmux.txt and not able to find csi_xxx.
> For CSI you are right they are not included by the current DT binding
> docs, however, the sdmmc1/3 pads are. So that makes things a bit more
> messy as some are and some are not.

Yaah and so lets have the names in new dt files. Names may be same but 
define all possible names f groups in dt binding and need not to refer 
from other file which does not have all.

>> Here I dont want to refer the individual pins as control should be as
>> group.
> I understand, however, at least for power-down control I don't see why
> we cannot refer to the individual pins and once all are inactive then
> the rail can be powered down.
>
> For switching the voltage it is a bit more complex, but may be we could
> still look-up the IO rail based upon the pads the device uses.
>

Yes, it can be done with ref count also for power down.
But interfaces are complex. As a client, it is easy to say power down 
SDMMC1 IO interface rather than saying power down 10 pins (names) of 
that group.
We need to provide all these from DT for dynamic and static 
configuration and listing all pins of groups are complicate then the pad 
names.



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ