All of lore.kernel.org
 help / color / mirror / Atom feed
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.

  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: link
Be 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.