linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.

  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).