Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
MIME-Version: 1.0
References: <20220207063338.6570-1-warp5tw@gmail.com> <20220207063338.6570-7-warp5tw@gmail.com>
In-Reply-To: <20220207063338.6570-7-warp5tw@gmail.com>
From:   Tali Perry <tali.perry1@gmail.com>
Date:   Tue, 8 Feb 2022 11:22:30 +0200
Message-ID: <CAHb3i=vdc_+J4pCBcY--C85ZR1uXO1LG02UsttsfSnsQBDKWAg@mail.gmail.com>
Subject: Re: [PATCH v1 6/6] i2c: npcm: Support NPCM845
To:     Tyrone Ting <warp5tw@gmail.com>
Cc:     avifishman70@gmail.com, Tomer Maimon <tmaimon77@gmail.com>,
        Patrick Venture <venture@google.com>,
        Nancy Yuen <yuenn@google.com>,
        Benjamin Fair <benjaminfair@google.com>,
        Rob Herring <robh+dt@kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>,
        semen.protsenko@linaro.org, yangyicong@hisilicon.com,
        Wolfram Sang <wsa@kernel.org>, jie.deng@intel.com,
        sven@svenpeter.dev, bence98@sch.bme.hu, lukas.bulwahn@gmail.com,
        arnd@arndb.de, olof@lixom.net,
        Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
        Tali Perry <tali.perry@nuvoton.com>,
        Avi Fishman <Avi.Fishman@nuvoton.com>,
        tomer.maimon@nuvoton.com, KWLIU@nuvoton.com, JJLIU0@nuvoton.com,
        kfting@nuvoton.com, OpenBMC Maillist <openbmc@lists.ozlabs.org>,
        Linux I2C <linux-i2c@vger.kernel.org>,
        devicetree <devicetree@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

>On 08/02/2022 09:51, Tali Perry wrote:
>>> On 08/02/2022 08:14, Tali Perry wrote:
>>>>> Subject: Re: [PATCH v1 6/6] i2c: npcm: Support NPCM845
>>>>>
>>>>> On 07/02/2022 13:00, Jonathan Neusch=C3=A4fer wrote:
>>>>>> Hello,
>>>>>>
>>>>>> On Mon, Feb 07, 2022 at 02:33:38PM +0800, Tyrone Ting wrote:
>>>>>>> From: Tyrone Ting <kfting@nuvoton.com>
>>>>>>>
>>>>>>> NPCM8XX uses a similar i2c module as NPCM7XX.
>>>>>>> The only difference is that the internal HW FIFO is larger.
>>>>>>>
>>>>>>> Related Makefile and Kconfig files are modified to support as well.
>>>>>>>
>>>>>>> Fixes: 56a1485b102e ("i2c: npcm7xx: Add Nuvoton NPCM I2C controller
>>>>>>> driver")
>>>>>>
>>>>>> It's not really a bug fix, but rather an additional feature.
>>>>>> Therefore, I suggest removing the Fixes tag from this patch.
>>>>>>
>>>>>>> Signed-off-by: Tyrone Ting <kfting@nuvoton.com>
>>>>>>> Signed-off-by: Tali Perry <tali.perry1@gmail.com>
>>>>>>> ---
>>>>>> [...]
>>>>>>>  /* init register and default value required to enable module */
>>>>>>>  #define NPCM_I2CSEGCTL 0xE4
>>>>>>> +#ifdef CONFIG_ARCH_NPCM7XX
>>>>>>>  #define NPCM_I2CSEGCTL_INIT_VAL 0x0333F000
>>>>>>> +#else
>>>>>>> +#define NPCM_I2CSEGCTL_INIT_VAL 0x9333F000
>>>>>>> +#endif
>>>>>>
>>>>>> This is going to cause problems when someone tries to compile a kern=
el
>>>>>> that runs on both NPCM7xx and NPCM8xx (because the driver will then
>>>>>> only work on NPCM7xx).
>>>>>
>>>>> Yes, good catch.
>>>>>
>>>>> The NPCM7XX is multiplatform, I guess NPCM8xx will be as well, so thi=
s looks like an invalid code. How such code is supposed to work on multipla=
tform kernel?
>>>>>
>>>>
>>>> NPCM7xx and NPCM8xx are very different devices.
>>>> They share same driver sources for some of the modules but it's not AB=
I.
>>>> Users cannot compile a single kernel with two separate DTS.
>>>> In case of the i2c controller, the npcm7xx has a 16 byte HW FIFO,
>>>> and the NPCM8xx has 32 bytes HW FIFO.
>>>> This also means that registers fields are slightly different.
>>>> For init data we can move it to the DTS, but register field sizes
>>>> can't be handled with this approach.
>>>>
>>>
>>> What do you mean they cannot compile a kernel with different DTS? Of
>>> course they can - when we talk about multiplatform sub-architectures!
>>> Maybe there is something specific in NPCMxxx which stops it but then it
>>> should not be marked multiplatform.
>>>
>>
>>
>> NCPM7xx is ARM32 bit (dual core Cortex A9)
>> NPCM8xx is ARM64 bit (quad core Cortex A35)
>>
>> They have completely different architecture so not ABI compliant.
>> I2C module is similar, but the devices are quite different and have
>> separate architectures.
>
>OK, in such case usually you indeed can't have both. :)
>
>> Sorry for the confusion.
>> This is the first patch we try to upstream for NPCM8xx.
>> In the coming weeks we will upstream the architecture of NPCM8xx as well=
.
>
>Still, ARCH_XXX should not be hard-coded in the drivers to change the
>driver's behavior, even if driver won't be used simultaneously. It
>breaks all design principles and prevents any further re-use if a new
>use case appears.
>
>You can use "ifdef ARCH_XXX" to skip building of some parts of the
>driver, but it's not the case here.
>

Correct, the main change is in FIFO size:
+#ifdef CONFIG_ARCH_NPCM7XX
#define I2C_HW_FIFO_SIZE               16
+#else
+#define I2C_HW_FIFO_SIZE               32
+#endif /* CONFIG_ARCH_NPCM7XX */

NPCM7XX will always have 16 bytes, all the next gens will have 32.

This impact some registers sizes, like this one:

+#ifdef CONFIG_ARCH_NPCM7XX
#define NPCM_I2CRXF_STS_RX_BYTES       GENMASK(4, 0)
+#else
+#define NPCM_I2CRXF_STS_RX_BYTES       GENMASK(5, 0)
+#endif /*CONFIG_ARCH_NPCM7XX*/

For this, the FIFO size should be defined before compilation.
I also don't want to let users select FIFO size per architecture.
NPCM7XX has 16, NPCM8XX has 32. This is not a user selection.
It's part of the arch.


>
>Best regards,
>Krzysztof

Thanks,
Tali