Hi,
On Mon, Dec 3, 2018 at 6:41 PM Jeykumar Sankaran <jsanka@xxxxxxxxxxxxxx> wrote:
> >> + dsi1: dsi@ae96000 {
> >> + compatible = "qcom,mdss-dsi-ctrl";
> >> + reg = <0xae96000 0x400>;
> >> + reg-names = "dsi_ctrl";
> >> +
> >> + interrupt-parent = <&mdss>;
> >> + interrupts = <5 IRQ_TYPE_LEVEL_HIGH>;
> >> +
> >> + clocks = <&dispcc
> >> DISP_CC_MDSS_BYTE1_CLK>,
> >> + <&dispcc
> >> DISP_CC_MDSS_BYTE1_INTF_CLK>,
> >> + <&dispcc
> >> DISP_CC_MDSS_PCLK1_CLK>,
> >> + <&dispcc
> >> DISP_CC_MDSS_ESC1_CLK>,
> >> + <&dispcc
> >> DISP_CC_MDSS_AHB_CLK>,
> >> + <&dispcc
> >> DISP_CC_MDSS_AXI_CLK>;
> >> + clock-names = "byte",
> >> + "byte_intf",
> >> + "pixel",
> >> + "core",
> >> + "iface",
> >> + "bus";
> >> +
> >> + phys = <&dsi1_phy>;
> >> + phy-names = "dsi1";
> >> +
> >> + status = "disabled";
> >
> > This "disabled" is causing me problems. I don't actually need "dsi1"
> > but if I don't enable "dsi1" then my display doesn't come up. :( I
> > ran out of time to debug but I wonder if this is this the standard
> > thing where DRM needs to wait for all the components to probe until it
> > can finish? If nobody on this list just knows I'll dig tomorrow and
> > confirm that my memory isn't faulty and see what we've done about this
> > in the past.
> >
> https://patchwork.kernel.org/patch/10467895/
>
> Can you try out with this change (reviewed but not merged yet). It
> validates
> the nodes before adding to the DSI list.
No, that doesn't fix it. I also don't see your printout.
OK, found the problem and posted a patch. See
<https://lkml.kernel.org/r/20181204180441.218160-1-dianders@xxxxxxxxxxxx>.
Please test and review if you are able.
> > One last note: it's pretty weird that you sent out only 1/3 and not
> > 2/3 and 3/3. If you're not ready to send out MTP stuff yet then you
> > should send out v6 as just a singleton patch.
> Yes. I was trying to separate this one out as an independent change.
> Sandeep
> is working on the comments on removing the pinctrl nodes and updated
> mtp nodes. He should be posting 2/3 and 3/3 in the next couple of days.
OK, good to know. Probably 2/3 and 3/3 will be squashed anyway since
(as I suggested in the review) they should both be touching the MTP
device tree file.
...in any case, you should send yours out as a singleton patch and
then you don't have to guess how many patches might or might not be
sent out later. Sandeep can send out his patch and say it depends on
yours.
-Doug
