Hi, On Fri, Mar 20, 2015 at 09:54:21AM +0100, Dr. H. Nikolaus Schaller wrote: > [...] > And we do not write a driver for the w2sg0004 but the regulator inside that > chip. DT describes the hardware structure and not the Linux driver structure. > You also won’t expect that the omap3 driver hides everything. You > expect that the twl4030 provides some regulators that can be enabled > by subsystems inside the omap3. And if I remember correctly there are > regulators inside the omap3 which have explicit regulator nodes in the DT. so let's have a look at twl regulators. They can be found below the twl node, so they will look similar to / -> omap3 -> i2c -> twl -> regulator So properly mapped to the w2sg0004 device this would put your regulator to / -> omap3 -> serial -> w2sg0004 -> regulator This will gain you nothing as far as I can tell. Please note that subdevices under the serial node are pretty useful, since then the kernel can e.g. automatically setup correct line disciplines for serial attached bluetooth chips and make bluetooth work out of the box. I am aware, that the Linux kernel has no such thing for serial attached GPS devices, but that's Linux specific and irrelevant for the DT description. > The w2sg0004-regulator approach just follows this principle. > Anyone willing to control the power of the w2sg0004 can use this > regulator interface. From a HW perspective your regulator "hides" the information, that there is a device attached to the serial port and instead claims, that a regulator is needed to make the serial port work. Apart from that this interface is limited in its features. I'm currently working on N900's bluetooth chip. This one needs to set a gpio before data is sent data to the chip, has a reset gpio and a gpio to wakeup the OMAP SoC from idle states to avoid data loss on the UART. -- Sebastian
Attachment:
signature.asc
Description: Digital signature
