On 15/04/16 18:49, Laxman Dewangan wrote:
On Friday 15 April 2016 11:14 PM, Jon Hunter wrote:I still do not like that. In the case of sdmmc we now have two pinctrl
On 15/04/16 17:41, Laxman Dewangan wrote:Yaah and so lets have the names in new dt files. Names may be same but
On Friday 15 April 2016 09:15 PM, Jon Hunter wrote:For CSI you are right they are not included by the current DT binding
On 15/04/16 16:14, Laxman Dewangan wrote:Which dt binding docs have these?
I used pins as this is the property from pincon generic so that I canSo we need to reflect the hardware in device-tree and although yes the
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?
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?
I looked for nvidia,tegra210-pinmux.txt and not able to find csi_xxx.
docs, however, the sdmmc1/3 pads are. So that makes things a bit more
messy as some are and some are not.
define all possible names f groups in dt binding and need not to refer
from other file which does not have all.
drivers to deal with for a single set of pins. That does not seem
correct IMO.
But interfaces are complex. As a client, it is easy to say power downRight and like I said, we could always look up the IO rail from the pins
SDMMC1 IO interface rather than saying power down 10 pins (names) of
that group.
associated once at probe time and then control it from there.