Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki On 10/05/17 11:33, Jyri Sarha wrote: > On 10/05/17 09:53, Tomi Valkeinen wrote: >> On 04/10/17 17:56, Rob Herring wrote: >>> On Mon, Oct 2, 2017 at 10:53 PM, <frowand.list@xxxxxxxxx> wrote: >>>> From: Frank Rowand <frank.rowand@xxxxxxxx> >>>> >>>> I have found the device tree overlay code to be difficult to read and >>>> maintain. This patch series attempts to improve that situation. >>>> >>>> The cleanup includes some changes visible to users of overlays. The >>>> only in kernel user of overlays is fixed up for those changes. The >>>> in kernel user is: >>>> >>>> drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c >>> >>> At what point can we remove this? I'm assuming at some point users >>> will need to update their dtb's for other reasons and this becomes >>> obsolete. >> >> To be honest, I have no idea, or how to find that out. >> > > I think the first approach could be setting the DRM_TILCDC_SLAVE_COMPAT > default to n and listen if there is any reports about breakage. > After giving it more thought. Maybe we can drop the DRM_TILCDC_SLAVE_COMPAT in v4.16. 2017 LTS is out already, so there should be plenty of time for whoever is still using the legacy DTBs to get rid of them. >> Do we need to get rid of it? Afaik, we haven't do much (or any?) >> maintenance on tilcdc_slave_compat.c since it was written, so from our >> perspective it's been a minimal burden. Is it creating burden for others? >> >> Is the approach done with tilcdc_slave_compat.c something that's not >> recommended? I'm sure similar situations happen with other drivers too, >> and I think it's a good idea to have a recommended way of keeping >> compatibility. >> > > For tilcdc I would say that we soon need a similar mechanism to get rid > off tilcdc internal panel driver and to start using generic panel > drivers instead. That is, if we want to keep the kernel compatible with > old devicetree blobs. > Actually for tilcdc this is not that bad. The messy tilcdc slave mechanism has been gotten rid of. The rest of tilcdc specific legacy drivers - the tilcdc legacy panel support and the tilcdc legacy tfp410 driver - do not have any external dependencies and they can basically remain there for ever for backward compatibility. But in general, a generic mechanism to translate legacy DTBs to follow a new binding would be a handy tool in keeping the drivers clean while keeping up the support for legacy DTBs. Best regards, Jyri -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
