On Tue, Jul 18, 2017 at 07:06:05PM +0200, Rafael J. Wysocki wrote: > On Tue, Jul 18, 2017 at 6:29 AM, Peter Chen <hzpeterchen@xxxxxxxxx> wrote: > > On Mon, Jul 17, 2017 at 03:39:07PM +0200, Rafael J. Wysocki wrote: > >> > Sorry, I should describe more. > >> > > >> > Let's take USB bus as an example, when the new USB device is at the > >> > host port, the device structure at device model is not created until > >> > it is discoverable by the USB bus. If this new USB device needs to be > >> > powered on before can be discoverable by the bus, the device structure > >> > will be not created without powering on operation. The code usb_alloc_dev > >> > (drivers/usb/core/usb.c) is only called for discoverable device. > >> > > >> > Unlike the other bus, eg, platform bus, it creates device structure > >> > according to DT node. The USB bus was designed for hot plug model, the > >> > device structure is for discoverable device. In recent years, we begin > >> > to have some hard-wired USB device, Eg, onboard USB-hub, onboard USB 4G > >> > Modem, etc at the market. It needs some board level power operation before > >> > it can be found by the USB bus. This patch set is designed primarily for > >> > fix this kind of problem. You will see at at pwrseq_generic.c, we use DT > >> > version clock API of_clk_get and DT version gpio API of_get_named_gpio_flags > >> > instead of device structure version, like devm_clk_get and > >> > devm_gpiod_get_optional. > >> > > >> > MMC system has similar use case, it creates power sequence platform > >> > device for this issue, but all those power stuffs (clock, gpio, etc) > >> > may not be suitable as a dedicated virtual device at DT, they are belonged > >> > to one physical device, so this patch set is created to see if this issue > >> > can be fixed better. > >> > >> OK, thanks for the explanation. > >> > >> The above needs to be part of your problem statement. > > > > Ok, I will add it to cover letter. > > > >> > > >> > The bus will power up all device nodes in this bus according to DT > >> > information, the device structure has not created at this time. > >> > >> OK > >> > >> I still think that the information on power resources depended on by devices > >> should be used for power management as well as for the initial power-up. > >> > >> The most straightforward way to arrange for that would be to make it possible > >> to find the DT node matching the device after the device has been discovered > >> and struct device created for it, say by USB. That would require adding some > >> more information on the device to the DT node, probably. > > > > After the device is created, the device node structure is under struct > > device, say dev->of_node. The most difficulty for this issue is the > > device creation is dynamic and is after the physical device is > > discovered by the bus, the initial power-up is needed before the device > > can be discovered by the bus. > > So you power up all devices on the bus using the information from > of_nodes upfront. > I think your mean call pm_device_power_up(struct device *dev) for bus level device (eg, USB HUB for USB), yeah, I can do that. But we still have below problem: Where we can put the kinds of power sequence implementation (eg, pwrseq_generic.c) and the match mechanism between device node and kinds of power sequence(eg, of_pwrseq_on at core.c)? These stuffs can be shared among subsystems, and is better to use one framework for it. MMC subsystem adds such things at its core folder (drivers/mmc/core/pwrseq*) currently. -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
