From: Fabrizio Castro <fabrizio.castro@bp.renesas.com> To: Peter Rosin <peda@axentia.se>, Linus Walleij <linus.walleij@linaro.org>, Mark Brown <broonie@kernel.org> Cc: Geert Uytterhoeven <geert+renesas@glider.be>, Wolfram Sang <wsa@the-dreams.de>, Dave Airlie <airlied@linux.ie>, Boris BREZILLON <boris.brezillon@free-electrons.com>, Chris Paterson <Chris.Paterson2@renesas.com>, "open list:DRM PANEL DRIVERS" <dri-devel@lists.freedesktop.org>, Biju Das <biju.das@bp.renesas.com>, Linux-Renesas <linux-renesas-soc@vger.kernel.org>, Simon Horman <horms@verge.net.au>, Laurent Pinchart <Laurent.pinchart@ideasonboard.com>, "linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org> Subject: RE: [RFC] drm/bridge/sii902x: Fix EDID readback Date: Thu, 1 Nov 2018 16:04:41 +0000 [thread overview] Message-ID: <TY1PR01MB1770677FAD621ADA6CC810FBC0CE0@TY1PR01MB1770.jpnprd01.prod.outlook.com> (raw) In-Reply-To: <7d0df588-8051-b426-aed7-635e013bd2a3@axentia.se> Hello Peter, Thank you for your feedback! > > The "mux-locked" implementation was the one I first tried and I discovered > > it doesn't work for me, as other traffic on the parent adapter can get in the > > way. What we need for this device is no other traffic on the bus during the > > "select transaction deselect" procedure, that's why I went with the parent > > locking. Also this device needs a delay between stop and start conditions > > while addressing the monitor. > > Ok, I thought the problem was that a delay was needed between the STOP > of the command opening the gate and the START of the edid eeprom xfer, and > that everything else worked normally. Too bad this wasn't the actual problem. > > Hmm. If it is indeed true that other xfers must never creep into the "select > xfer deselect" procedure then you are indeed stuck with a parent-locking. > But is that really the case? Could it be that the extra delay between > STOP-START is only needed after the absolutely last xfer before the > command closing the gate? > > If that problem description is correct, it should be possible to go back to > a mux-locked gate, but then in your deselect implementation grab the i2c adapter > lock manually - with i2c_lock_bus(adapter, I2C_LOCK_ROOT_ADAPTER) - before the > 30 us delay, then open code the command to close the gate with an unlocked i2c > access, and finally release the i2c bus lock. That way you have ensured silence > on the bus for the required time before closing the gate. You would still need > to bypass regmap, but only in this one place (but maybe you should bypass > regmap for opening the gate too, for symmetry). To further detail the problem, the system is vulnerable from before the last write performed by sii902x_i2c_bypass_select to after we confirm we need the switch to be closed within sii902x_i2c_bypass_deselect, that's the minimum amount of time we could keep the parent adapter locked for, I guess I am stuck with a parent-locking architecture, aren't I? But I guess I could release it when it's not actually needed, or is this going to be a pain to maintain? Shall I just keep going with the parent-locking but using bare i2c transactions only within select and deselect and leave regmap to deal with everything else? snip > > > > Ah, do you think the following is going to cause any issue in the future? > > -edid = drm_get_edid(connector, sii902x->i2c->adapter); > > +edid = drm_get_edid(connector, sii902x->i2cmux->adapter[0]); > > No, that was a critical part of the idea to use a gate to introduce the > needed delay. Again, thank you very much for spending your time looking into this, your feedback is very much appreciated. Fab > > Cheers, > Peter Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING: multiple messages have this Message-ID (diff)
From: Fabrizio Castro <fabrizio.castro@bp.renesas.com> To: Peter Rosin <peda@axentia.se>, Linus Walleij <linus.walleij@linaro.org>, Mark Brown <broonie@kernel.org> Cc: Archit Taneja <architt@codeaurora.org>, Andrzej Hajda <a.hajda@samsung.com>, Dave Airlie <airlied@linux.ie>, Wolfram Sang <wsa@the-dreams.de>, Laurent Pinchart <Laurent.pinchart@ideasonboard.com>, "open list:DRM PANEL DRIVERS" <dri-devel@lists.freedesktop.org>, Simon Horman <horms@verge.net.au>, Geert Uytterhoeven <geert+renesas@glider.be>, Chris Paterson <Chris.Paterson2@renesas.com>, Biju Das <biju.das@bp.renesas.com>, Linux-Renesas <linux-renesas-soc@vger.kernel.org>, "linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>, Inki Dae <inki.dae@samsung.com>, Boris BREZILLON <boris.brezillon@free-electrons.com> Subject: RE: [RFC] drm/bridge/sii902x: Fix EDID readback Date: Thu, 1 Nov 2018 16:04:41 +0000 [thread overview] Message-ID: <TY1PR01MB1770677FAD621ADA6CC810FBC0CE0@TY1PR01MB1770.jpnprd01.prod.outlook.com> (raw) In-Reply-To: <7d0df588-8051-b426-aed7-635e013bd2a3@axentia.se> Hello Peter, Thank you for your feedback! > > The "mux-locked" implementation was the one I first tried and I discovered > > it doesn't work for me, as other traffic on the parent adapter can get in the > > way. What we need for this device is no other traffic on the bus during the > > "select transaction deselect" procedure, that's why I went with the parent > > locking. Also this device needs a delay between stop and start conditions > > while addressing the monitor. > > Ok, I thought the problem was that a delay was needed between the STOP > of the command opening the gate and the START of the edid eeprom xfer, and > that everything else worked normally. Too bad this wasn't the actual problem. > > Hmm. If it is indeed true that other xfers must never creep into the "select > xfer deselect" procedure then you are indeed stuck with a parent-locking. > But is that really the case? Could it be that the extra delay between > STOP-START is only needed after the absolutely last xfer before the > command closing the gate? > > If that problem description is correct, it should be possible to go back to > a mux-locked gate, but then in your deselect implementation grab the i2c adapter > lock manually - with i2c_lock_bus(adapter, I2C_LOCK_ROOT_ADAPTER) - before the > 30 us delay, then open code the command to close the gate with an unlocked i2c > access, and finally release the i2c bus lock. That way you have ensured silence > on the bus for the required time before closing the gate. You would still need > to bypass regmap, but only in this one place (but maybe you should bypass > regmap for opening the gate too, for symmetry). To further detail the problem, the system is vulnerable from before the last write performed by sii902x_i2c_bypass_select to after we confirm we need the switch to be closed within sii902x_i2c_bypass_deselect, that's the minimum amount of time we could keep the parent adapter locked for, I guess I am stuck with a parent-locking architecture, aren't I? But I guess I could release it when it's not actually needed, or is this going to be a pain to maintain? Shall I just keep going with the parent-locking but using bare i2c transactions only within select and deselect and leave regmap to deal with everything else? snip > > > > Ah, do you think the following is going to cause any issue in the future? > > -edid = drm_get_edid(connector, sii902x->i2c->adapter); > > +edid = drm_get_edid(connector, sii902x->i2cmux->adapter[0]); > > No, that was a critical part of the idea to use a gate to introduce the > needed delay. Again, thank you very much for spending your time looking into this, your feedback is very much appreciated. Fab > > Cheers, > Peter Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
next prev parent reply other threads:[~2018-11-01 16:04 UTC|newest] Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-10-31 12:57 [RFC] drm/bridge/sii902x: Fix EDID readback Fabrizio Castro 2018-10-31 12:57 ` Fabrizio Castro 2018-10-31 16:07 ` Linus Walleij 2018-10-31 16:07 ` Linus Walleij 2018-10-31 16:55 ` Fabrizio Castro 2018-10-31 16:55 ` Fabrizio Castro 2018-10-31 20:36 ` Peter Rosin 2018-10-31 20:36 ` Peter Rosin 2018-11-01 11:04 ` Fabrizio Castro 2018-11-01 11:04 ` Fabrizio Castro 2018-11-01 15:19 ` Peter Rosin 2018-11-01 15:19 ` Peter Rosin 2018-11-01 16:04 ` Fabrizio Castro [this message] 2018-11-01 16:04 ` Fabrizio Castro 2018-11-01 16:47 ` Peter Rosin 2018-11-01 16:47 ` Peter Rosin 2018-11-01 17:32 ` Fabrizio Castro 2018-11-01 17:32 ` Fabrizio Castro 2018-11-02 8:53 ` Peter Rosin 2018-11-02 8:53 ` Peter Rosin 2018-11-02 12:07 ` Fabrizio Castro 2018-11-02 12:07 ` Fabrizio Castro 2018-11-01 11:21 ` Mark Brown 2018-11-01 11:21 ` Mark Brown 2018-11-02 12:05 ` Fabrizio Castro 2018-11-02 12:05 ` Fabrizio Castro
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=TY1PR01MB1770677FAD621ADA6CC810FBC0CE0@TY1PR01MB1770.jpnprd01.prod.outlook.com \ --to=fabrizio.castro@bp.renesas.com \ --cc=Chris.Paterson2@renesas.com \ --cc=Laurent.pinchart@ideasonboard.com \ --cc=airlied@linux.ie \ --cc=biju.das@bp.renesas.com \ --cc=boris.brezillon@free-electrons.com \ --cc=broonie@kernel.org \ --cc=dri-devel@lists.freedesktop.org \ --cc=geert+renesas@glider.be \ --cc=horms@verge.net.au \ --cc=linus.walleij@linaro.org \ --cc=linux-i2c@vger.kernel.org \ --cc=linux-renesas-soc@vger.kernel.org \ --cc=peda@axentia.se \ --cc=wsa@the-dreams.de \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.