Hi Peter, > Hmm, now that I have slept on it, I find this a bit odd. For muxes, all > channels and the parent are always present. Here, that is not the case. > And don't get me wrong, I see why that is the case, but that doesn't > mean that I like it. It would be so much nicer and less disruptive if > the client devices were not unbound and rebound (which I think they are, > right?) on every master switch. Yes, we rebind on every master switch. In the first iteration of this driver, I tried the on-the-fly approach. It turned out to be very flaky because it was stretching the driver model too much. There is no support for multiple parents and no support for switching the parent at runtime. When trying to do that, you find out that e.g. the whole relationship tree needs to be rebuilt, say to keep PM hierarchy consistent. And even, just for I2C, on-the-fly switching is not really supported. Some Renesas R-Car SoCs have two different I2C IP cores which can be muxed to the same pins. One has DMA, the other slave functionality. I don't see a way to combine both into one "virtual" master. This is why I came to the current approach. The use case that the customers decide on the feature set they want to use after booting was said to be good enough. > In some cases I think it might be possible to make the switch automatic > and seamless, e.g. if there are two masters and one of them is faster > but has some glitch(es), and the other is slower but complete (or at > least complete enough). That might work for some cases, yet I'd favor a generic solution. > What do you think? Given my above experiences, I'd just drop the channel symlink and keep the driver as is :) But thanks for thinking about it! Wolfram
Attachment:
signature.asc
Description: PGP signature
