Lines Matching refs:like

103 like this, walking around the edge of the chip, which seems to be industry
127 some generic pinctrl_ops like this:
212 configuration in the pin controller ops like this:
295 instance like this:
347 numbers can be encoded in the range like this:
426 are chessboard-like, big ones have "holes" in some arrangement according to
428 pins you see some will be taken by things like a few VCC and GND to feed power
429 to the chip, and quite a few will be taken by large ports like an external
477   In this case the array could be something like: { spi0, i2c0, mmc0 }
518   like these:
551 mapped to any pin, like in a phone exchange. So the available pin groups for
577 group of pins would work something like this:
732 request like that, so the driver does not need to worry about such
915 driver may look like this:
931 And your machine configuration may look like this:
991 A pin controller configuration for a machine looks pretty much like a simple
1022 up the device struct (just like with clockdev or regulators). The function name
1078 .group can be specified like this:
1106 case), we define a mapping like this:
1159 The result of grabbing this mapping from the device with something like
1204 default state like this:
1277 device drivers bookkeeping operations, like checking available functions and
1298 So say that your driver is fetching its resources like this:
1310 used. If you're using the subsystems orthogonally like this, you should
1331 as a back-end for the GPIO driver like this, unless your hardware design