On 2013-02-11 11:31, Marcus Lorentzon wrote: > Ok, so what about a compromise which I think would work for "both" HWs > ... we allow the "configure" operation during video on, then each HW > driver could decide if this means you have to stop or not to do the > changes required. But then it is also important that we keep all config > in one struct and not split it up. Otherwise HW like ours that has so be > stopped could need to stop once for each setting/operation called. > So in short, allow configure(bus_params) during video on, keep all > bus_params in the struct. It is in kernel struct so it can easily be > changed/refactored. Right, we need some way to group the configuration parameters. Either one big struct, or something like start_config() and end_config(). I think we could also think what parameters make no sense to be configured on the fly, and possibly have those separately. Although it may be a bit difficult to think of all the (weird) use cases. > Again, this probing and bus muxing is platform/bus specific and not > panel specific. Any panel of that type will only ever work on Omap (or The parameters used for configuration itself is platform specific, and that's why it needs to be defined in the DT data. But the API itself is not platform specific. The parameters are information about how the panel is connected, just like, say, number of data lines is for DPI. Which is also something I think should be configured by the panel. > someone else implementing the same muxing features) as I see it. So why No, it works for everyone. Well, at least I still don't see anything omap or platform specific in the API. Of course, if the platform/device doesn't support modifying the pin functions, then the function does nothing. > not just put that config on the bus master, dispc? I still can't see how > this is panel config. You are only pushing CDF API and meta data to > describe something that is only needed by one bus master. I have never The information about how the panel is connected (the wiring) has to be somewhere in the DT data. We could have the info in the DSI master or in the DSI slave. Or, in some platforms where the DSS is not involved in the muxing/config, the info could be totally separate, in the boards pinmuxing data. I think all those work ok for normal cases without hotplug. But if you have hotplug, then you need separate pinmuxing/config data for each panel. You could possibly have a list of panels in your DSI master node, containing the muxing data, but that sounds rather hacky, and also very hardcoded, i.e. you need to know each panel that is ever going to be connected. If, on the other hand, you have the info in the panel node, it "just works". When a new panel is connected, the relevant panel DT data comes from somewhere (it's not relevant where), and it tells the DSI master how it's connected. Something like this is probably needed for the BeagleBone capes, if you have happened to follow the discussion. Although it could be argued that the capes may perhaps be not runtime hotswappable, and thus the configuration can be done only once during boot after the cape has been probed. But I'd rather not design the API so that we prevent hot swapping. > seen any DSI slave that can change their pin config. And since there is Well, if omap is the only SoC/device out there that supports configuring the pin functions, and everybody is against the API, I'm not going to press it. But then again, I think similar configuration support may be needed even for the normal pinmuxing, even in the case where you can't reconfigure the DSI pin functions. You still need to mux the pins (perhaps, say, between DSI and a GPIO), depending on how many lanes the panel uses. In fact, speaking about all pins in general, I'm not very fond of having a static pinmuxing in the board DT data, handled by the board setup code. I think generally the pins should be muxed to safe-mode by the board setup code, and then configured to their proper function by the driver when it is initializing. > no generic hot plug detect of DSI panels, at least not before DSI bus is > available, I have to assume this probing it very platform specific. We > have some products that provide 1-2 gpios to specify what panel is > available, some use I2C sensor probing to then assume the panel plugged. Yes, the hotplug mechanism is platform/board specific. But that's not relevant here. > At least in the first step I don't think this type of hot plug should be > in the API. Then once the base panel driver is in we could discuss > different solutions for you hot plug scenario. Yes, as I said, I also think we shouldn't aim for hotplug in the v1. But we also shouldn't prevent it. Tomi
Attachment:
signature.asc
Description: OpenPGP digital signature
