Hi Chen-Yu, On Sat, Sep 30, 2017 at 3:58 PM, Chen-Yu Tsai <wens@xxxxxxxx> wrote: > On Sat, Sep 30, 2017 at 1:35 PM, Julian Calaby <julian.calaby@xxxxxxxxx> wrote: >> Hi Chen-Yu, >> >> On Fri, Sep 29, 2017 at 8:22 PM, Chen-Yu Tsai <wens@xxxxxxxx> wrote: >>> On Fri, Sep 29, 2017 at 6:20 PM, Maxime Ripard >>> <maxime.ripard@xxxxxxxxxxxxxxxxxx> wrote: >>>> On Fri, Sep 29, 2017 at 08:22:56AM +0000, Chen-Yu Tsai wrote: >>>>> On systems with 2 TCONs such as the A31, it is possible to demux the >>>>> output of the TCONs to one encoder. >>>>> >>>>> Add support for this for the A31. >>>>> >>>>> Signed-off-by: Chen-Yu Tsai <wens@xxxxxxxx> >>>>> --- >>>>> drivers/gpu/drm/sun4i/sun4i_tcon.c | 38 ++++++++++++++++++++++++++++++++++++++ >>>>> 1 file changed, 38 insertions(+) >>>>> >>>>> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c >>>>> index 7bf51abaee97..c949309d4285 100644 >>>>> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c >>>>> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c >>>>> @@ -112,6 +112,21 @@ void sun4i_tcon_enable_vblank(struct sun4i_tcon *tcon, bool enable) >>>>> } >>>>> EXPORT_SYMBOL(sun4i_tcon_enable_vblank); >>>>> >>>>> +static struct sun4i_tcon *sun4i_get_first_tcon(struct drm_device *drm) >>>> >>>> Would that make sense to make it a bit more generic, and pass the id >>>> to look for as an argument? >>> >>> The reason to look for TCON0 explicitly is to access the muxing registers, which >>> are only available in TCON0. Other than that, there's nothing else >>> shared between >>> the two TCONs. So there's no particular reason to look for TCON1 explicitly. >> >> In that case: in the bizarre case where we're trying to use this mux >> type and there is no TCON0, shouldn't we fail? > > It gives out a big warning, indicating something is wrong. If TCON0 is not found > it is most likely your device tree is broken. There's nothing more the > driver can do. > Are you suggesting to return NULL in this case, and also do error > handling in the > callers? You're already returning -EINVAL for other failure cases, so a lack of TCON0 might as well do the same. >> (Also, the code doesn't make sense if we have some TCON1 and TCON2 in >> that order as it'll return TCON2) > > I'm guessing you want it to return NULL. I'm just pointing out the mismatch between getting the "first" TCON and the actual behaviour. Thanks, -- Julian Calaby Email: julian.calaby@xxxxxxxxx Profile: http://www.google.com/profiles/julian.calaby/ -- 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
