[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YFzC19IiGZdmLCOR@smile.fi.intel.com>
Date: Thu, 25 Mar 2021 19:05:27 +0200
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: "Goswami, Sanket" <Sanket.Goswami@....com>
Cc: jarkko.nikula@...ux.intel.com, mika.westerberg@...ux.intel.com,
linux-i2c@...r.kernel.org, linux-kernel@...r.kernel.org,
Shyam Sundar S K <Shyam-sundar.S-k@....com>,
Nehal Bakulchandra Shah <Nehal-Bakulchandra.shah@....com>
Subject: Re: [PATCH] i2c: add i2c bus driver for amd navi gpu
On Mon, Mar 22, 2021 at 10:26:55PM +0530, Goswami, Sanket wrote:
> On 09-Mar-21 19:56, Andy Shevchenko wrote:
> > On Tue, Mar 09, 2021 at 07:01:47PM +0530, Sanket Goswami wrote:
...
> >> +static int amd_i2c_dw_master_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num_msgs)
> >
> > Why do you need a custom function for that? Can it be generic and not AMD
> > specific?
> This function takes care of AMD Specific bus configuration for the transfer and
> also addresses the IP issue of i2c transactions hence it is kept as custom.
Can you a bit elaborate this? IT would be nice to have a comment in the code
explaining what is the difference with a generic approach.
...
> >> + /* Enable ucsi interrupt */
> >> + if (dev->flags & AMD_NON_INTR_MODE)
> >> + regmap_write(dev->map, AMD_UCSI_INTR_REG, AMD_UCSI_INTR_EN);
> >
> > This is looks like a hack. Why is it here?
> In order to enable the interrupt for UCSI i.e. AMD NAVI GPU card,
> it is mandatory to set the right value in specific register
> (offset:0x474) as per the hardware IP specification.
Why it can not be done outside of this function?
...
> >> + if (dev->flags & AMD_NON_INTR_MODE)
> >> + return amd_i2c_dw_master_xfer(adap, msgs, num);
> >
> > Ditto.
> Initiate I2C message transfer when AMD NAVI GPU card is enabled,
> As it is polling based transfer mechanism, which does not support
> interrupt based functionalities of existing DesignWare driver.
Ditto.
And I think I already have told you that I prefer to see rather MODEL_ quirk.
...
> > Also why (1) and this can't be instantiated from ACPI / DT?
> It is in line with the existing PCIe-based DesignWare driver,
> A similar approach is used by the various vendors.
Here is no answer to the question. What prevents you to fix your ACPI tables or
DT?
We already got rid of FIFO hard coded values, timings are harder to achieve,
but we expect that new firmwares will provide values in the ACPI tables.
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists