On Wed, Feb 8, 2017 at 12:09 PM, Hoegeun Kwon <hoegeun.kwon@xxxxxxxxxxx> wrote: > On 02/08/2017 04:32 PM, Krzysztof Kozlowski wrote: >> >> On Wed, Feb 8, 2017 at 9:24 AM, Hoegeun Kwon <hoegeun.kwon@xxxxxxxxxxx> >> wrote: >>>> >>>> "Remove the ports node abd move burst and esc clock frequency properties >>>> to the parent (DSI node)." >>>> >>>> The information which is missing is the answer for WHY? Why are you >>>> doing this? >>> >>> >>> The current mipi-dsi must have at least one OF graph. >>> However, for example, dsi and panel are parent-child relationships, >>> so OF graph is not needed, and fimd and dsi are not connected to the OF >>> graph. >>> In this case, an error occurred in dsi_parse in the code before patch >>> (1/5). >> >> The error occurred in case of DSI + FIMD? I do not get it whether you >> are removing the something which is not needed or fixing something. >> >>> So I modified dsi_parse_dt. >>> >>>> Does the patch depends on 1/5? >>> >>> >>> Yes, it is. >>> The 2/5 to 5/5 patches depend on the 1/5 patch. >> >> So that's a break of DT ABI for no clear (yet) reasons. Please mention >> this in 1/5 patch and explain what is really fixed. > > > I would like to post the s6e63j0x03 panel driver for exynos3250. > However, as Rob Herring noted, dsi + panel is a parental relationship, > so OF grpah is not needed. > Therefore, the current dsi_parse_dt function will throw an error, > because there is no linked OF graph for case such as fimd + dsi + panel. > I think that the OF graph of dsi should be deleted even if it is not > the purpose of the s6e63j0x03 panel driver. > > So the 1/5 patch parse the Pll, burst and esc clock frequency properties > in dsi_parse_dt and modified to create a bridge_node only if there is > an OF graph associated with dsi. > Thanks, now it makes sense. Such clear explanation should be part of commit 1/5 as a proof that ABI breakage is needed. BR, Krzysztof -- 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
