All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vadim Pasternak <vadimp@mellanox.com>
To: Peter Rosin <peda@axentia.se>, "wsa@the-dreams.de" <wsa@the-dreams.de>
Cc: "linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"jiri@resnulli.us" <jiri@resnulli.us>,
	Michael Shych <michaelsh@mellanox.com>
Subject: RE: [patch v5] i2c: mux: mellanox: add driver
Date: Thu, 3 Nov 2016 05:20:25 +0000	[thread overview]
Message-ID: <AM5PR0501MB2097C2A4BA889C44549A0E9FA2A30@AM5PR0501MB2097.eurprd05.prod.outlook.com> (raw)
In-Reply-To: c530714e-b61e-8a38-a054-9d335f0e8a71@axentia.se

Hi,

I see that this patch has not been picked-up yet for i2c-next.
Is it possible it was missed from some reason?

Thanks,
Vadim.

> -----Original Message-----
> From: Vadim Pasternak
> Sent: Friday, September 23, 2016 2:57 PM
> To: 'Peter Rosin' <peda@axentia.se>; wsa@the-dreams.de
> Cc: linux-i2c@vger.kernel.org; linux-kernel@vger.kernel.org; jiri@resnulli.us;
> Michael Shych <michaelsh@mellanox.com>
> Subject: RE: [patch v5] i2c: mux: mellanox: add driver
> 
> 
> 
> > -----Original Message-----
> > From: Peter Rosin [mailto:peda@axentia.se]
> > Sent: Friday, September 23, 2016 12:36 PM
> > To: Vadim Pasternak <vadimp@mellanox.com>; wsa@the-dreams.de
> > Cc: linux-i2c@vger.kernel.org; linux-kernel@vger.kernel.org;
> > jiri@resnulli.us; Michael Shych <michaelsh@mellanox.com>
> > Subject: Re: [patch v5] i2c: mux: mellanox: add driver
> >
> > On 2016-09-13 22:37, vadimp@mellanox.com wrote:
> > > From: Vadim Pasternak <vadimp@mellanox.com>
> > >
> > > This driver allows I2C routing controlled through CPLD select
> > > registers on a wide range of Mellanox systems (CPLD Lattice device).
> > > MUX selection is provided by digital and analog HW. Analog part is
> > > not under SW control.
> > > Digital part is under CPLD control (channel selection/de-selection).
> > >
> > > Connectivity schema.
> > > i2c-mlxcpld                                 Digital               Analog
> > > driver
> > > *--------*                                 * -> mux1 (virt bus2) -> mux ->|
> > > | I2CLPC | i2c physical                    * -> mux2 (virt bus3) -> mux ->|
> > > | bridge | bus 1                 *---------*                              |
> > > | logic  |---------------------> * mux reg *                              |
> > > | in CPLD|                       *---------*                              |
> > > *--------*   i2c-mux-mlxpcld          ^    * -> muxn (virt busn) -> mux ->|
> > >     |        driver                   |                                   |
> > >     |        *---------------*        |                             Devices
> > >     |        * CPLD (i2c bus)* select |
> > >     |        * registers for *--------*
> > >     |        * mux selection * deselect
> > >     |        *---------------*
> > >     |                 |
> > > <-------->     <----------->
> > > i2c cntrl      Board cntrl reg
> > > reg space      space (mux select,
> > >                IO, LED, WD, info)
> >
> > Hmm, I'm wondering about the above schematics, which seems a bit
> > overly complex. I mean, it's not relevant to this driver how the
> > I2CLPC bridge logic in the CPLD is controlled. Particularly so since
> > it does not need to be a this particular i2c adapter that is muxed.
> >
> > But what I'm really wondering is if this mux can mux same other bus
> > than is used to control the mux. I.e. is it possible to do something like this:
> >
> >   .---.          .-------------.
> >   |   |          |             |-- i2c2 --
> >   | l |-- i2c0 --| mlxcpld mux |
> >   | i |          |             |-- i2c3 --
> >   | n |          '-------------'
> >   | u |                 |
> >   | x |-- i2c1 ---------'
> >   |   |
> >   '---'
> >
> > Or is it always as below, with the mux being controlled from the same
> > i2c bus it muxes?
> >
> >   .---.             .-------------.
> >   | l |             |             |-- i2c1 --
> >   | i |-- i2c0 --+--| mlxcpld mux |
> >   | n |          |  |             |-- i2c2 --
> >   | u |          |  '-------------'
> >   | x |          |         |
> >   '---'          '---------'
> >
> 
> Hi Peter,
> 
> Thank you very much for this and all previous feedbacks.
> 
> Yes, it is not coupled with I2CLPC bridge logic.
> When I sent my initial patch, it was marked as 1/2, while 1/1 was patch for i2c-
> mlxcpld controller.
> So, maybe my comment here is redundant I can make it simpler.
> 
> Actual description you provided is better.
> 
> Would you like me to submit patch with this modification only?
> 
> 
> Just as an example to show how we are going to use this driver.
> 
> This is x86 systems, when we do have LPCI2C as controller (we have on these
> systems management CPLD attached to LPC on carrier board and I2C attached
> CLPD on switch board:
> .---.             .-------------.
> | l |             |             |-- i2cx1 -- i2cy8
> | i |-- i2c1 --+--| mlxcpld mux |
> | n |          |  |             |-- i2y1 -- i2cy8
> | u |          |  '-------------'
> | x |          |         |
>  '---'          '---------'
> 
> I2C CPLD is attached to bus 1 at 0x62, and has register 0x81 - 0x85 for access to
> 4 or 5 banks of QSFP ports (each bank of 8).
> 
> This is coming systems equipped with BMC Aspeed 2520 SoC ARM11 based (by
> the way this driver now also in review process):
> .---.             .-------------.
> | l |             |             |-- i2cx1 -- i2cy8
> | i |-- i2cn --+--| mlxcpld mux |
> | n |          |  |             |-- i2y1 -- i2cy8
> | u |          |  '-------------'
> | x |          |         |
>  '---'          '---------
> 
> I2C CPLD is attached to bus n (SoC equipped with 14 I2C busses) at 0x62, and has
> register 0xz1 - 0xz1 for access to 4 or 5 banks of QSFP ports (each bank of 8).
> 
> Cheers,
> Vadim.
> 
> > Cheers,
> > Peter

  parent reply	other threads:[~2016-11-03  6:53 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-13 20:37 [patch v5] i2c: mux: mellanox: add driver vadimp
2016-09-14  7:49 ` Peter Rosin
2016-09-14  7:49   ` Peter Rosin
2016-09-14  8:10   ` Vadim Pasternak
2016-09-14  8:42     ` Peter Rosin
2016-09-23  9:36 ` Peter Rosin
2016-09-23  9:36   ` Peter Rosin
2016-09-23 11:57   ` Vadim Pasternak
2016-11-03  5:20   ` Vadim Pasternak [this message]
2016-11-10 11:13     ` Peter Rosin
2016-11-10 12:56       ` Vadim Pasternak
2016-11-10 13:02         ` Peter Rosin
2016-11-10 13:04           ` Vadim Pasternak

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=AM5PR0501MB2097C2A4BA889C44549A0E9FA2A30@AM5PR0501MB2097.eurprd05.prod.outlook.com \
    --to=vadimp@mellanox.com \
    --cc=jiri@resnulli.us \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michaelsh@mellanox.com \
    --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.