On 12/05/14 17:26, Tony Lindgren wrote: >>> The omapdss case is different, there the "omapdss" points to a sw thing, >>> it does not describe the hardware. It's only needed as we don't have >>> proper sw drivers for the devices. >>> >>> That said, I think what you describe would work. But I would rather keep >>> the .dts files clean and correct, and keep that hacks hidden inside the >>> kernel. >>> >> >> Thanks for the explanation. Since DT are meant to describe hardware >> and not software I agree with you that we shouldn't leak an >> implementation detail to the DeviceTrees. >> >> And after all fortunately we don't have a stable API in the kernel >> like the one that is enforced in the DT so we can fix it later ;-) > > This remapping of compatible flags sounds smelly to me, please discuss > it first with the device tree people. It's already in v3.15. I agree it's smelly, but it smelly only inside the kernel, not visible anywhere, and we can remove it when we have common panel drivers, without any modifications to .dts files. > I think we're better off just using the compatible properties limited > to the simple-panel.txt for now and actually describe the real > hardware. The fact that the panel is connected to DSS should be possible > to find out based on the phandles. I'm not sure what you mean. We do describe only the real hardware. The compatible string in the .dts file is "sharp,ls037v7dw01". Prepending the "omapdss" to the compatible string is required for the device/driver matching to work, because we can't use the "sharp,ls037v7dw01" compatible string in our omap specific panel driver. I'm not sure what it would give us to try to be compatible with simple-panel.txt. The simple-panel bindings won't probably be compatible with the future common display drivers in any case, as the simple-panel binding is just too limited and doesn't describe the hardware fully. Tomi
Attachment:
signature.asc
Description: OpenPGP digital signature
