Re: [Freedreno] [PATCH v2 02/34] component: Introduce the aggregate bus_type
On Thu, Oct 07, 2021 at 04:42:48PM -0400, Stephen Boyd wrote: > Quoting Greg Kroah-Hartman (2021-10-06 22:37:40) > > On Wed, Oct 06, 2021 at 12:37:47PM -0700, Stephen Boyd wrote: > > > > > > Let's make the component driver into an actual device driver that has > > > probe/remove/shutdown functions. The driver will only be bound to the > > > aggregate device once all component drivers have called component_add() > > > to indicate they're ready to assemble the aggregate driver. This allows > > > us to attach shutdown logic (and in the future runtime PM logic) to the > > > aggregate driver so that it runs the hooks in the correct order. > > > > Why are you creating a new bus type and not using the auxiliary bus > > instead? > > > > You have seen Documentation/driver-api/auxiliary_bus.rst, right? > > > > Nope, but I read it now. Thanks for the pointer. > > My read of it is that the auxiliary bus is a way to slice up a single IP > block into multiple devices and then have drivers attach to those > different "pieces" of the IP. It avoids polluting the platform bus with > devices that don't belong on the platform bus because they are sub > components of a larger IP block that sits on the platform bus. > > The aggregate bus is solving the reverse problem. It is rounding up a > collection of IP blocks that live on some bus (platform, i2c, spi, > whatever) and presenting them as a single aggregate device (sound card, > display card, whatever) whenever all the component devices call > component_add(). For example, we don't want to do operations on the > entire display pipeline until all the devices that make up the display > are probed and drivers are attached. I suppose the aggregate_device in > this patch series has a 1:1 relationship with the drm class_type that > makes up /sys/class/drm/cardN but there's also a couple sound users and > a power_supply user so I don't know the equivalent there. > > Long term, maybe all of this component code could be placed directly > into the driver core? That's probably even more invasive of a change but > I imagine we could make device links with component_add() as we're > already doing with these patches and then have driver core call some > class function pointer when all the links are probed. That would > handle the 'bind/probe' callback for the aggregate device but it won't > handle the component_bind_all() path where we call bind_component() for > each component device that makes up the aggregate device. Maybe we can > add even more devices for the components and then call probe there too. > > Sorry that's a long-winded non-answer. I don't think they're solving the > same problem so using the same bus type looks wrong. We'd have to take > two different paths depending on what type of device it is (aggregate > vs. auxiliary) so there's not much of anything that is shared code-wise. Yeah component is the reverse of auxiliary, and right now a lot of subsystems have their own hand-rolled version of this. I do hope that component.c does become more of a standard (that's why it's in drivers/base/), but I guess that's a bit tricky if the device model maintainer hasn't seen it yet ... Hopefully putting more proper device model concepts into it can fix this problem :-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [Freedreno] [PATCH v2 02/34] component: Introduce the aggregate bus_type
Quoting Saravana Kannan (2021-10-07 18:32:20) > On Thu, Oct 7, 2021 at 6:24 PM Stephen Boyd wrote: > > > > Anyway, I think we still have to do a rescan so that we can try to bind > > the aggregate device. Is there a better API to use for that? > > If you know the exact device, you could call device_attach()? That's > what bus_rescan_devices() eventually calls, but you skip the > unnecessary looping over all the other devices. > Unfortunately we don't know the device. At this point it's possible that the aggregate device hasn't even been registered yet.
Re: [Freedreno] [PATCH v2 02/34] component: Introduce the aggregate bus_type
Quoting Saravana Kannan (2021-10-07 18:10:24) > On Thu, Oct 7, 2021 at 1:11 PM Stephen Boyd wrote: > > > > Quoting Stephen Boyd (2021-10-07 11:40:07) > > > Quoting Saravana Kannan (2021-10-06 20:07:11) > > > > On Wed, Oct 6, 2021 at 12:38 PM Stephen Boyd > > > > wrote: > > > > > diff --git a/drivers/base/component.c b/drivers/base/component.c > > > > > index 0a41bbe14981..d99e99cabb99 100644 > > > > > --- a/drivers/base/component.c > > > > > +++ b/drivers/base/component.c > > > [...] > > > > > + continue; > > > > > + > > > > > + /* Matches put in component_del() */ > > > > > + get_device(&adev->dev); > > > > > + c->link = device_link_add(&adev->dev, c->dev, > > > > > + DL_FLAG_STATELESS | > > > > > DL_FLAG_PM_RUNTIME); > > > > > > > > Remove the STATELESS flag and you'll get a bunch of other stuff done > > > > for free: > > > > > > I tried that and it didn't work for me. The aggregate device never > > > probed and I was left with no display. Let me see if I can reproduce it > > > with logging to provide more details. > > > > This patch fixes it (whitespace damaged sorry). > > Not sure why you have to trigger an explicit rescan, but instead of > this patch below, you could also try setting this flag instead? > DL_FLAG_AUTOPROBE_CONSUMER > I'd rather not conflate component driver probe with component_add() being called. It's simpler if that is the case, i.e. all component drivers are calling component_add() in their driver probe routine, but I don't know if that's always true. I did this poor audit of the kernel $ git grep -p \[^_]component_add | grep \.c= | grep -v probe drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c=static int amdgpu_dm_audio_init(struct amdgpu_device *adev) drivers/gpu/drm/i915/display/intel_audio.c=static void i915_audio_component_init(struct drm_i915_private *dev_priv) drivers/gpu/drm/i915/display/intel_hdcp.c=void intel_hdcp_component_init(struct drm_i915_private *dev_priv) drivers/gpu/drm/nouveau/dispnv50/disp.c=nv50_audio_component_init(struct nouveau_drm *drm) drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c=static int dw_mipi_dsi_rockchip_host_attach(void *priv_data, drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c=static int dw_mipi_dsi_dphy_init(struct phy *phy) drivers/gpu/drm/vc4/vc4_dsi.c=static int vc4_dsi_host_attach(struct mipi_dsi_host *host, and then peeking at rockchip above I see that component_add() is called in the mipi dsi attach ops and then I got lost trying to figure out where it ends up. Maybe it is still in some probe call? Anyway, I think we still have to do a rescan so that we can try to bind the aggregate device. Is there a better API to use for that?
Re: [Freedreno] [PATCH v2 02/34] component: Introduce the aggregate bus_type
Quoting Greg Kroah-Hartman (2021-10-06 22:37:40) > On Wed, Oct 06, 2021 at 12:37:47PM -0700, Stephen Boyd wrote: > > > > Let's make the component driver into an actual device driver that has > > probe/remove/shutdown functions. The driver will only be bound to the > > aggregate device once all component drivers have called component_add() > > to indicate they're ready to assemble the aggregate driver. This allows > > us to attach shutdown logic (and in the future runtime PM logic) to the > > aggregate driver so that it runs the hooks in the correct order. > > Why are you creating a new bus type and not using the auxiliary bus > instead? > > You have seen Documentation/driver-api/auxiliary_bus.rst, right? > Nope, but I read it now. Thanks for the pointer. My read of it is that the auxiliary bus is a way to slice up a single IP block into multiple devices and then have drivers attach to those different "pieces" of the IP. It avoids polluting the platform bus with devices that don't belong on the platform bus because they are sub components of a larger IP block that sits on the platform bus. The aggregate bus is solving the reverse problem. It is rounding up a collection of IP blocks that live on some bus (platform, i2c, spi, whatever) and presenting them as a single aggregate device (sound card, display card, whatever) whenever all the component devices call component_add(). For example, we don't want to do operations on the entire display pipeline until all the devices that make up the display are probed and drivers are attached. I suppose the aggregate_device in this patch series has a 1:1 relationship with the drm class_type that makes up /sys/class/drm/cardN but there's also a couple sound users and a power_supply user so I don't know the equivalent there. Long term, maybe all of this component code could be placed directly into the driver core? That's probably even more invasive of a change but I imagine we could make device links with component_add() as we're already doing with these patches and then have driver core call some class function pointer when all the links are probed. That would handle the 'bind/probe' callback for the aggregate device but it won't handle the component_bind_all() path where we call bind_component() for each component device that makes up the aggregate device. Maybe we can add even more devices for the components and then call probe there too. Sorry that's a long-winded non-answer. I don't think they're solving the same problem so using the same bus type looks wrong. We'd have to take two different paths depending on what type of device it is (aggregate vs. auxiliary) so there's not much of anything that is shared code-wise.
Re: [Freedreno] [PATCH v2 02/34] component: Introduce the aggregate bus_type
Quoting Stephen Boyd (2021-10-07 11:40:07) > Quoting Saravana Kannan (2021-10-06 20:07:11) > > On Wed, Oct 6, 2021 at 12:38 PM Stephen Boyd wrote: > > > diff --git a/drivers/base/component.c b/drivers/base/component.c > > > index 0a41bbe14981..d99e99cabb99 100644 > > > --- a/drivers/base/component.c > > > +++ b/drivers/base/component.c > [...] > > > + continue; > > > + > > > + /* Matches put in component_del() */ > > > + get_device(&adev->dev); > > > + c->link = device_link_add(&adev->dev, c->dev, > > > + DL_FLAG_STATELESS | > > > DL_FLAG_PM_RUNTIME); > > > > Remove the STATELESS flag and you'll get a bunch of other stuff done for > > free: > > I tried that and it didn't work for me. The aggregate device never > probed and I was left with no display. Let me see if I can reproduce it > with logging to provide more details. This patch fixes it (whitespace damaged sorry). 8< diff --git a/drivers/base/component.c b/drivers/base/component.c index 65042c9f8a42..43cac9ed70b7 100644 --- a/drivers/base/component.c +++ b/drivers/base/component.c @@ -202,7 +202,7 @@ static int find_components(struct aggregate_device *adev) /* Matches put in component_del() */ get_device(&adev->dev); c->link = device_link_add(&adev->dev, c->dev, - DL_FLAG_STATELESS | DL_FLAG_PM_RUNTIME); + DL_FLAG_PM_RUNTIME); c->adev = adev; } @@ -749,7 +749,9 @@ static int __component_add(struct device *dev, const struct component_ops *ops, mutex_unlock(&component_mutex); /* Try to bind */ - return bus_rescan_devices(&aggregate_bus_type); + bus_rescan_devices(&aggregate_bus_type); + + return 0; } /** The important part is ignoring the return value of bus_rescan_devices(). It's a cycle problem. The last component is probing and calling component_add() in its probe function. The call to component_add() is trying to probe the aggregate device now that all components are added. But when it tries to probe the aggregate device it sees that a supplier, which is this component calling compnent_add(), hasn't been probed yet, so it returns -EPROBE_DEFER. That is passed up to the component and it defers probe. I don't think the component device cares at all about the aggregate device being able to probe or not. We should be able to ignore the return value of bus_rescan_devices() in component_add(). I'll add a comment to the code here so it's more obvious.
Re: [Freedreno] [PATCH v2 02/34] component: Introduce the aggregate bus_type
Quoting Saravana Kannan (2021-10-06 20:07:11) > On Wed, Oct 6, 2021 at 12:38 PM Stephen Boyd wrote: > > diff --git a/drivers/base/component.c b/drivers/base/component.c > > index 0a41bbe14981..d99e99cabb99 100644 > > --- a/drivers/base/component.c > > +++ b/drivers/base/component.c [...] > > + continue; > > + > > + /* Matches put in component_del() */ > > + get_device(&adev->dev); > > + c->link = device_link_add(&adev->dev, c->dev, > > + DL_FLAG_STATELESS | > > DL_FLAG_PM_RUNTIME); > > Remove the STATELESS flag and you'll get a bunch of other stuff done for free: I tried that and it didn't work for me. The aggregate device never probed and I was left with no display. Let me see if I can reproduce it with logging to provide more details. > 1. The aggregate device would get force unbound when the component > devices unbind. > 2. You don't need to explicitly keep track of and delete the link. If > either of the devices get deleted, it'll get deleted automatically. > 3. It will avoid useless probe attempts of the aggregate device before > all the component devices are probed. > I don't think point 3 is happening right now. We only try to probe the aggregate device once all components probe.
Re: [Freedreno] [PATCH v2 02/34] component: Introduce the aggregate bus_type
On Wed, Oct 06, 2021 at 12:37:47PM -0700, Stephen Boyd wrote: > The component driver only provides 'bind' and 'unbind' callbacks to tell > the host driver that it is time to assemble the aggregate driver now > that all the components have probed. The component driver model doesn't > attempt to resolve runtime PM or suspend/resume ordering, and explicitly > mentions this in the code. This lack of support leads to some pretty > gnarly usages of the 'prepare' and 'complete' power management hooks in > drivers that host the aggregate device, and it fully breaks down when > faced with ordering shutdown between the various components, the > aggregate driver, and the host driver that registers the whole thing. > > In a concrete example, the MSM display driver at drivers/gpu/drm/msm is > using 'prepare' and 'complete' to call the drm helpers > drm_mode_config_helper_suspend() and drm_mode_config_helper_resume() > respectively, so that it can move the aggregate driver suspend/resume > callbacks to be before and after the components that make up the drm > device call any suspend/resume hooks they have. This only works as long > as the component devices don't do anything in their own 'prepare' and > 'complete' callbacks. If they did, then the ordering would be incorrect > and we would be doing something in the component drivers before the > aggregate driver could do anything. Yuck! > > Similarly, when trying to add shutdown support to the MSM driver we run > across a problem where we're trying to shutdown the drm device via > drm_atomic_helper_shutdown(), but some of the devices in the encoder > chain have already been shutdown. This time, the component devices > aren't the problem (although they could be if they did anything in their > shutdown callbacks), but there's a DSI to eDP bridge in the encoder > chain that has already been shutdown before the driver hosting the > aggregate device runs shutdown. The ordering of driver probe is like > this: > > 1. msm_pdev_probe() (host driver) > 2. DSI bridge > 3. aggregate bind > > When it comes to shutdown we have this order: > > 1. DSI bridge > 2. msm_pdev_shutdown() (host driver) > > and so the bridge is already off, but we want to communicate to it to > turn things off on the display during msm_pdev_shutdown(). Double yuck! > Unfortunately, this time we can't split shutdown into multiple phases > and swap msm_pdev_shutdown() with the DSI bridge. > > Let's make the component driver into an actual device driver that has > probe/remove/shutdown functions. The driver will only be bound to the > aggregate device once all component drivers have called component_add() > to indicate they're ready to assemble the aggregate driver. This allows > us to attach shutdown logic (and in the future runtime PM logic) to the > aggregate driver so that it runs the hooks in the correct order. Why are you creating a new bus type and not using the auxiliary bus instead? You have seen Documentation/driver-api/auxiliary_bus.rst, right? thanks, greg k-h
Re: [Freedreno] [PATCH v2 02/34] component: Introduce the aggregate bus_type
Hi Stephen,
I love your patch! Yet something to improve:
[auto build test ERROR on e4e737bb5c170df6135a127739a9e6148ee3da82]
url:
https://github.com/0day-ci/linux/commits/Stephen-Boyd/component-Make-into-an-aggregate-bus/20211007-034200
base: e4e737bb5c170df6135a127739a9e6148ee3da82
config: hexagon-randconfig-r045-20211006 (attached as .config)
compiler: clang version 14.0.0 (https://github.com/llvm/llvm-project
c0039de2953d15815448b4b3c3bafb45607781e0)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/0day-ci/linux/commit/b7f12127fd97fe811eaf9600a6677fb1cbb66554
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Stephen-Boyd/component-Make-into-an-aggregate-bus/20211007-034200
git checkout b7f12127fd97fe811eaf9600a6677fb1cbb66554
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1
ARCH=hexagon
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
>> drivers/base/component.c:509:13: error: incompatible function pointer types
>> initializing 'void (*)(struct device *)' with an expression of type 'int
>> (struct device *)' [-Werror,-Wincompatible-function-pointer-types]
.remove = aggregate_driver_remove,
^~~
1 error generated.
vim +509 drivers/base/component.c
504
505 static struct bus_type aggregate_bus_type = {
506 .name = "aggregate",
507 .match = aggregate_device_match,
508 .probe = aggregate_driver_probe,
> 509 .remove = aggregate_driver_remove,
510 .shutdown = aggregate_driver_shutdown,
511 };
512
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
