On Tue, Aug 4, 2015 at 1:16 AM, Andrzej Hajda <a.hajda@xxxxxxxxxxx> wrote: > On 08/03/2015 04:04 PM, Rob Clark wrote: >> On Mon, Aug 3, 2015 at 8:03 AM, Andrzej Hajda <a.hajda@xxxxxxxxxxx> wrote: >>> Hi, >>> >>> On 07/31/2015 04:48 PM, Rob Clark wrote: >>>> On Fri, Jul 31, 2015 at 8:58 AM, Boris Brezillon >>>> <boris.brezillon@xxxxxxxxxxxxxxxxxx> wrote: >>>>> Hi Rob, >>>>> >>>>> On Fri, 31 Jul 2015 08:13:59 -0400 >>>>> Rob Clark <robdclark@xxxxxxxxx> wrote: >>>>> >>> (...) >>> >>>>> Another problem I've seen with some drm bridge drivers is that they >>>>> directly create their own connector, which, as Archit stated, is wrong >>>>> if you decide to chain this bridge with another bridge. The other >>>> I agree with Archit on this. He took this approach w/ msm support for >>>> external bridges, and it seems sensible that the last bridge >>>> constructs the connector. (Plus presumably that is where hpd, ddc >>>> probing, etc, is happing) >>> With this approach many bridges should construct connector conditionally, >>> depending if there is something behind them in pipeline (the same is true for >>> encoders and even crtcs). It works, but for me there is lot of unnecessary code >>> and all those conditional paths make things less friendly for development. >>> Wouldn't be better to move creation of the connector to the main drm driver, >>> it would require probably adding some opses/fields to drm_bridges but the >>> drivers would be simpler, I guess. >> six of one, half dozen of the other.. you'd still need to implement >> the hpd and ddc probe bits, and that sort of thing *somewhere*. >> Whether it is directly by implementing drm_connector in the bridge, or >> indirectly via some extra drm_bridge op's called by a shim connector >> in the main drm driver, doesn't really seem to change things.. > > The difference is that instead of duplicating connector related code in every > driver you will call one helper from the main drm driver/core. Which isn't more than a few lines of code.. I mean, looking at a couple connectors, the bulk of the code is hpd and ddc related. That doesn't magically go away. There isn't that many lines of boilerplate, so meh. BR, -R > Regards > Andrzej > >> >> BR, >> -R >> >>> Regards >>> Andrzej >>> >>>>> reason why the bridge should not create the connector by its own is >>>>> that in some case the encoder supports different types of connectors (a >>>>> TDMS encoder can be used to output HDMI or DVI), and thus, selecting >>>>> the connector type should be left to the part responsible for creating >>>>> the display pipelines. >>>> did you mean "should" instead of "should not"? Otherwise I don't >>>> think I understand.. >>>> >>>> BR, >>>> -R >>>> >>>>> This being said, I'm definitely not an expert in this area, so don't >>>>> hesitate to show me where I'm wrong. >>>>> >>>>> Best Regards, >>>>> >>>>> Boris >>>>> >>>>> -- >>>>> Boris Brezillon, Free Electrons >>>>> Embedded Linux and Kernel engineering >>>>> http://free-electrons.com > -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
