From: "Jiawen Wu" <jiawenwu@trustnetic•com>
To: "'Piotr Raczynski'" <piotr.raczynski@intel•com>
Cc: <netdev@vger•kernel.org>, <jarkko.nikula@linux•intel.com>,
<andriy.shevchenko@linux•intel.com>,
<mika.westerberg@linux•intel.com>, <jsd@semihalf•com>,
<Jose.Abreu@synopsys•com>, <andrew@lunn•ch>,
<hkallweit1@gmail•com>, <linux@armlinux•org.uk>,
<linux-i2c@vger•kernel.org>, <linux-gpio@vger•kernel.org>,
<mengyuanlou@net-swift•com>
Subject: RE: [PATCH net-next v7 2/9] i2c: designware: Add driver support for Wangxun 10Gb NIC
Date: Wed, 10 May 2023 14:43:50 +0800 [thread overview]
Message-ID: <009d01d9830a$c7c6dab0$57549010$@trustnetic.com> (raw)
In-Reply-To: <ZFpQF4hi0FciwQsj@nimitz>
On Tuesday, May 9, 2023 9:52 PM, Piotr Raczynski wrote:
> On Tue, May 09, 2023 at 10:27:27AM +0800, Jiawen Wu wrote:
> > Wangxun 10Gb ethernet chip is connected to Designware I2C, to
> > communicate with SFP.
> >
> > Introduce the property "snps,i2c-platform" to match device data for
> > Wangxun in software node case. Since IO resource was mapped on the
> > ethernet driver, add a model quirk to get regmap from parent device.
> >
> > The exists IP limitations are dealt as workarounds:
> > - IP does not support interrupt mode, it works on polling mode.
> > - Additionally set FIFO depth address the chip issue.
> >
> > Signed-off-by: Jiawen Wu <jiawenwu@trustnetic•com>
>
> I'm definitely not an i2c expert, a couple of nit picks below, thanks.
> Reviewed-by: Piotr Raczynski <piotr.raczynski@intel•com>
>
> > ---
> > drivers/i2c/busses/i2c-designware-common.c | 8 ++
> > drivers/i2c/busses/i2c-designware-core.h | 1 +
> > drivers/i2c/busses/i2c-designware-master.c | 89
> > +++++++++++++++++++-- drivers/i2c/busses/i2c-designware-platdrv.c |
> > 15 ++++
> > 4 files changed, 108 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/i2c/busses/i2c-designware-common.c
> > b/drivers/i2c/busses/i2c-designware-common.c
> > index 0dc6b1ce663f..a7c2e67ccbf6 100644
> > --- a/drivers/i2c/busses/i2c-designware-common.c
> > +++ b/drivers/i2c/busses/i2c-designware-common.c
> > @@ -575,6 +575,14 @@ int i2c_dw_set_fifo_size(struct dw_i2c_dev *dev)
> > unsigned int param;
> > int ret;
> >
> > + /* DW_IC_COMP_PARAM_1 not implement for IP issue */
> > + if ((dev->flags & MODEL_MASK) == MODEL_WANGXUN_SP) {
> > + dev->tx_fifo_depth = 4;
> I understand this is some kind of workaround but is the number chosen
> empirically? Maybe a defined value would be clearer instead of magic
> number.
Yes, this value setting worked and passed test.
> > @@ -559,13 +621,19 @@ i2c_dw_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[], int num)
> > pm_runtime_get_sync(dev->dev);
> >
> > /*
> > - * Initiate I2C message transfer when AMD NAVI GPU card is enabled,
> > + * Initiate I2C message transfer when polling mode is enabled,
> > * As it is polling based transfer mechanism, which does not support
> > * interrupt based functionalities of existing DesignWare driver.
> > */
> > - if ((dev->flags & MODEL_MASK) == MODEL_AMD_NAVI_GPU) {
> > + switch (dev->flags & MODEL_MASK) {
> > + case MODEL_AMD_NAVI_GPU:
> > ret = amd_i2c_dw_xfer_quirk(adap, msgs, num);
> > goto done_nolock;
> > + case MODEL_WANGXUN_SP:
> > + ret = txgbe_i2c_dw_xfer_quirk(adap, msgs, num);
> > + goto done_nolock;
> > + default:
> > + break;
> > }
> Nit pick, when I first saw above code it looked a little weird,
> maybe it would be a little clearer with:
>
> if (i2c_dw_is_model_poll(dev)) {
> switch (dev->flags & MODEL_MASK) {
> case MODEL_AMD_NAVI_GPU:
> ret = amd_i2c_dw_xfer_quirk(adap, msgs, num);
> break;
> case MODEL_WANGXUN_SP:
> ret = txgbe_i2c_dw_xfer_quirk(adap, msgs, num);
> break;
> default:
> break;
> }
> goto done_nolock;
> }
>
> I do not insist though.
Sure, it looks more obvious as polling mode quirk.
next prev parent reply other threads:[~2023-05-10 6:46 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-09 2:27 [PATCH net-next v7 0/9] TXGBE PHYLINK support Jiawen Wu
2023-05-09 2:27 ` [PATCH net-next v7 1/9] net: txgbe: Add software nodes to support phylink Jiawen Wu
2023-05-09 12:38 ` Piotr Raczynski
2023-05-09 2:27 ` [PATCH net-next v7 2/9] i2c: designware: Add driver support for Wangxun 10Gb NIC Jiawen Wu
2023-05-09 13:52 ` Piotr Raczynski
2023-05-10 6:43 ` Jiawen Wu [this message]
2023-05-10 7:47 ` andy.shevchenko
2023-05-10 8:00 ` Jiawen Wu
2023-05-09 2:27 ` [PATCH net-next v7 3/9] net: txgbe: Register fixed rate clock Jiawen Wu
2023-05-09 15:32 ` Simon Horman
2023-05-10 6:47 ` Jiawen Wu
2023-05-09 2:27 ` [PATCH net-next v7 4/9] net: txgbe: Register I2C platform device Jiawen Wu
2023-05-11 12:13 ` Andrew Lunn
2023-05-11 20:16 ` Piotr Raczynski
2023-05-09 2:27 ` [PATCH net-next v7 5/9] net: txgbe: Add SFP module identify Jiawen Wu
2023-05-11 12:13 ` Andrew Lunn
2023-05-11 20:18 ` Piotr Raczynski
2023-05-09 2:27 ` [PATCH net-next v7 6/9] net: txgbe: Support GPIO to SFP socket Jiawen Wu
2023-05-11 12:31 ` Andrew Lunn
2023-05-12 6:38 ` Jiawen Wu
2023-05-12 14:20 ` Andrew Lunn
2023-05-11 12:38 ` Andrew Lunn
2023-05-12 6:35 ` Jiawen Wu
2023-05-11 20:45 ` andy.shevchenko
2023-05-12 8:57 ` Jiawen Wu
2023-05-12 9:43 ` Andy Shevchenko
2023-05-12 9:32 ` Russell King (Oracle)
2023-05-12 10:46 ` Jiawen Wu
2023-05-09 2:27 ` [PATCH net-next v7 7/9] net: pcs: Add 10GBASE-R mode for Synopsys Designware XPCS Jiawen Wu
2023-05-11 12:40 ` Andrew Lunn
2023-05-09 2:27 ` [PATCH net-next v7 8/9] net: txgbe: Implement phylink pcs Jiawen Wu
2023-05-11 19:33 ` Andrew Lunn
2023-05-11 20:32 ` Piotr Raczynski
2023-05-12 9:22 ` Jiawen Wu
2023-05-09 2:27 ` [PATCH net-next v7 9/9] net: txgbe: Support phylink MAC layer Jiawen Wu
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='009d01d9830a$c7c6dab0$57549010$@trustnetic.com' \
--to=jiawenwu@trustnetic$(echo .)com \
--cc=Jose.Abreu@synopsys$(echo .)com \
--cc=andrew@lunn$(echo .)ch \
--cc=andriy.shevchenko@linux$(echo .)intel.com \
--cc=hkallweit1@gmail$(echo .)com \
--cc=jarkko.nikula@linux$(echo .)intel.com \
--cc=jsd@semihalf$(echo .)com \
--cc=linux-gpio@vger$(echo .)kernel.org \
--cc=linux-i2c@vger$(echo .)kernel.org \
--cc=linux@armlinux$(echo .)org.uk \
--cc=mengyuanlou@net-swift$(echo .)com \
--cc=mika.westerberg@linux$(echo .)intel.com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=piotr.raczynski@intel$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox