From: Wangseok Lee <wangseok.lee@samsung.com>
To: Krzysztof Kozlowski <krzk@kernel.org>,
robh+dt <robh+dt@kernel.org>, krzk+dt <krzk+dt@kernel.org>,
kishon <kishon@ti.com>, vkoul <vkoul@kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
"jesper.nilsson" <jesper.nilsson@axis.com>,
"lars.persson" <lars.persson@axis.com>
Cc: bhelgaas <bhelgaas@google.com>,
linux-phy <linux-phy@lists.infradead.org>,
linux-pci <linux-pci@vger.kernel.org>,
devicetree <devicetree@vger.kernel.org>,
"lorenzo.pieralisi" <lorenzo.pieralisi@arm.com>,
kw <kw@linux.com>, linux-arm-kernel <linux-arm-kernel@axis.com>,
kernel <kernel@axis.com>, Moon-Ki Jun <moonki.jun@samsung.com>,
Dongjin Yang <dj76.yang@samsung.com>
Subject: Re: [PATCH 0/5] Add support for Axis, ARTPEC-8 PCIe driver
Date: Fri, 22 Apr 2022 08:57:25 +0900 [thread overview]
Message-ID: <20220421235725epcms2p1fc34c904f960cba958fa692c6d5dad9c@epcms2p1> (raw)
In-Reply-To: <4a6dd90c-3f8e-ad18-0136-88b75f4d9cf9@kernel.org>
> On 18/04/2022 09:20, Wangseok Lee wrote:
>>>> Also, as you know,
>>>> exynos driver is designed according to exynos SoC platform,
>>>> so both function and variable names start with exynos.
>>>
>>> That's hardly a problem...
>>>
>>>> Compared to the existing exynos driver,
>>>> you can see that the structure and type of function are different.
>>>
>>> No, I cannot see it. You coded the driver that way, you can code it in
>>> other way.
>>>
>>>> For this reason, it is difficult to use the existing exynos driver
>>>> for artpec.
>>>
>>> Naming of functions and structures is not making it difficult. That's
>>> not the reason.
>>>
>>>> Our idea is to register a new PCIe driver for artpec-8 SoC platform
>>>> and maintain it in the future.
>>>
>>> We also want to maintain Exynos PCIe driver in the future.
>>>
>>> Best regards,
>>> Krzysztof
>>
>> Hi,
>> Sorry for delay response.
>
> Sure, happens, but I don't remember the discussion, so replying that
> late will not help your cause.
>
> You know that if you (you as Samsung) worked with upstream, e.g. by
> extending the drivers and keeping them in shape, it would be much easier
> for you (again you as Samsung) to actually add new features? It's much
> better/effective approach than the path of pushing every time new driver
> with explanation like "we do not want to maintain older driver, so we
> want a new one"...
>
>> I have listed some parts that are different from exynos pcie driver.
>>
>> PHY driver
>> PHY is different, so register map is also different.
>> Three reference clock options are available in ARTPEC-8.
>> It operates by selecting one clock among XO, IO, and SOC PLL.
>> However, the exynos phy driver sets one ref clk though sysreg.
>
> It usually trivial to code such difference in the driver.
>
>> The reset method and type of PHY for initialization are different.
>> The overall sysreg configuration is different
>
> Indeed.
>
>> Artpec-8 requires a separate sequence for phy tuning,
>> but it does not exist in exynos phy driver.
>> Artpec-8 requires pcs resources, but exynos phy driver does not exist.
>>
>
> For the phy driver indeed it might require much effort to create one driver.
>
>> Controller driver
>> Sub controller is different, so register map is also different.
>> And it is different handles lane control, link control, PHY clocking,
>> reset, interrupt control.
>> The number and type of clock resources used are different.
>> The overall sysreg configuration is different
>>
>> Also artpec-8 is performed in dual mode that supports both RC and EP.
>> As described above, the PHY and sub ontroller are different
>> and the regiser map is different.
>> sysreg is also different. And there are differences such as reset.
>> The driver will be much more complicated if both hardwares should be
>> supported in the same driver.
>
> Maybe, quite probably. The reluctance to extend any existing code makes
> me doubting this, but I admit that there are many differences.
>
>> For these reasons, my opinion is that better to create
>> a phy, controller both driver with a new file.
>> Please let me know your opinion.
>
> At the end it's mostly the decision of PCIe and phy subsystem
> maintainers whether they want to have separate drivers for DWC PCIe
> blocks in ARMv8 Samsung SoCs.
>
> In any case, the driver code looks like copied-pasted from some vendor
> sources, so you need to bring it to shape.
>
> Best regards,
> Krzysztof
Hi,
Thank you for your kindness review over several e-mails.
I will improve on PATCH 1,2,3,4 and i will return with v2.
(yaml and phy, controller driver code improvement)
At that time, i would like ask to you and phy, controller
maintainer's opinion again.
Thank you.
next prev parent reply other threads:[~2022-04-21 23:57 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20220418072049epcms2p463a9f01d8ae3e29f75b746a0dce934f1@epcms2p4>
2022-04-18 7:20 ` [PATCH 0/5] Add support for Axis, ARTPEC-8 PCIe driver Wangseok Lee
2022-04-18 16:52 ` Krzysztof Kozlowski
[not found] ` <CGME20220418072049epcms2p463a9f01d8ae3e29f75b746a0dce934f1@epcms2p1>
2022-04-21 23:57 ` Wangseok Lee [this message]
2022-05-02 10:14 ` Vinod Koul
[not found] <CGME20220328014430epcms2p7063834feb0abdf2f38a62723c96c9ff1@epcms2p7>
2022-03-28 1:44 ` 이왕석
2022-03-28 7:11 ` Krzysztof Kozlowski
[not found] ` <CGME20220328014430epcms2p7063834feb0abdf2f38a62723c96c9ff1@epcms2p8>
2022-03-28 9:02 ` 이왕석
2022-03-28 9:38 ` Krzysztof Kozlowski
[not found] ` <CGME20220328014430epcms2p7063834feb0abdf2f38a62723c96c9ff1@epcms2p4>
2022-03-28 11:29 ` 이왕석
2022-03-28 11:40 ` Krzysztof Kozlowski
2022-04-13 6:45 ` Vinod Koul
[not found] ` <CGME20220328014430epcms2p7063834feb0abdf2f38a62723c96c9ff1@epcms2p1>
2022-03-29 3:49 ` 이왕석
2022-03-29 6:41 ` Krzysztof Kozlowski
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=20220421235725epcms2p1fc34c904f960cba958fa692c6d5dad9c@epcms2p1 \
--to=wangseok.lee@samsung.com \
--cc=bhelgaas@google.com \
--cc=devicetree@vger.kernel.org \
--cc=dj76.yang@samsung.com \
--cc=jesper.nilsson@axis.com \
--cc=kernel@axis.com \
--cc=kishon@ti.com \
--cc=krzk+dt@kernel.org \
--cc=krzk@kernel.org \
--cc=kw@linux.com \
--cc=lars.persson@axis.com \
--cc=linux-arm-kernel@axis.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-phy@lists.infradead.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=moonki.jun@samsung.com \
--cc=robh+dt@kernel.org \
--cc=vkoul@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).