On 17/10/13 12:16, Thierry Reding wrote: > On Thu, Oct 17, 2013 at 11:49:52AM +0300, Tomi Valkeinen wrote: >> Just my opinion, but yes, DT is that inflexible. DT bindings are like a >> syscall. Once they are there, you need to support them forever. That >> support can, of course, include some kind of DT data converters or such, >> that try to convert old bindings to new bindings at kernel boot. > > That's not entirely true. DT bindings are allowed to change, the only > restriction being that they don't break backwards compatibility. So if True, but afaik the same goes for syscalls. But yes, it's probably easier to add, say, new properties to DT bindings than adding new flags to a syscall. > Am I the only one refusing to accept that we can't provide even the most > basic functionality simply because we haven't been able to come up with > the ultimately "perfect" DT binding yet? By definition it's not very > likely that any binding will ever be perfect. With "perfect" I meant without any obvious features missing. I agree that DT bindings will never be perfect, but I at least would like them to be good enough to cover all the cases we know of. > I don't think we're doing ourselves any good by letting DT actively > hinder us in merging any of these features. I would personally prefer > having to support several bindings rather than not be able to provide > the functionality at all. I'd say the driver writer is of course free to create basic bindings for the device in question as long as the bindings are sane, and he agrees to later create any needed converters. I don't see any problem with having a driver supporting several versions of the bindings. But I don't think it's fair to push a driver with basic bindings, knowing that the bindings won't be enough in the future, and leave all the converter-mess to other people (not saying that's the case here). As a fbdev maintainer, I'm ok with adding DT bindings to device specific fb drivers, as those can be just left as they are. Even when CDF is merged, the specific fb drivers just work with the old bindings. If the driver maintainer wants to use CDF, it's up to him to create any needed binding-converters. But a generic driver for panels is more problematic, as that one should be maintained and refreshed to new features like CDF. If such was proposed to be merged to fbdev, I'd be very reluctant to merge it if there were any concerns about it. I guess one option there would be to implement a new driver for the same panel devices, one that supports CDF, and leave the old one as is. Not so nice option, though. > For crying out loud, we can use the 3D engine to render to a framebuffer > but we can't look at the result because we can't make the bloody panel > light up! Seriously!? Ah, but do you have DT bindings for the 3D engine yet, which represent how different internal blocks in the 3D engine are connected? If not, better start designing it! Then the problem is solved, you won't even have working 3D engine. ;) But seriously speaking, I'm with you. I don't get this DT stuff. And the funny thing is, DT should just represent the hardware, it doesn't matter what kind of SW drivers there are, so in a sense talking about DT problems with a SW framework like CDF is a bit silly. How hard can it be to describe the hardware properly? Very, obviously =). Tomi
Attachment:
signature.asc
Description: OpenPGP digital signature
