All of lore.kernel.org
 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.

WARNING: multiple messages have this Message-ID (diff)
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.

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

  parent reply	other threads:[~2022-04-21 23:57 UTC|newest]

Thread overview: 26+ 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  7:20   ` Wangseok Lee
2022-04-18 16:52   ` Krzysztof Kozlowski
2022-04-18 16:52     ` Krzysztof Kozlowski
     [not found]   ` <CGME20220418072049epcms2p463a9f01d8ae3e29f75b746a0dce934f1@epcms2p1>
2022-04-21 23:57     ` Wangseok Lee [this message]
2022-04-21 23:57       ` Wangseok Lee
2022-05-02 10:14       ` Vinod Koul
2022-05-02 10:14         ` Vinod Koul
     [not found] <CGME20220328014430epcms2p7063834feb0abdf2f38a62723c96c9ff1@epcms2p7>
2022-03-28  1:44 ` 이왕석
2022-03-28  1:44   ` 이왕석
2022-03-28  7:11   ` Krzysztof Kozlowski
2022-03-28  7:11     ` Krzysztof Kozlowski
     [not found]   ` <CGME20220328014430epcms2p7063834feb0abdf2f38a62723c96c9ff1@epcms2p8>
2022-03-28  9:02     ` 이왕석
2022-03-28  9:02       ` 이왕석
2022-03-28  9:38       ` Krzysztof Kozlowski
2022-03-28  9:38         ` Krzysztof Kozlowski
     [not found]       ` <CGME20220328014430epcms2p7063834feb0abdf2f38a62723c96c9ff1@epcms2p4>
2022-03-28 11:29         ` 이왕석
2022-03-28 11:29           ` 이왕석
2022-03-28 11:40           ` Krzysztof Kozlowski
2022-03-28 11:40             ` Krzysztof Kozlowski
2022-04-13  6:45             ` Vinod Koul
2022-04-13  6:45               ` Vinod Koul
     [not found]           ` <CGME20220328014430epcms2p7063834feb0abdf2f38a62723c96c9ff1@epcms2p1>
2022-03-29  3:49             ` 이왕석
2022-03-29  3:49               ` 이왕석
2022-03-29  6:41               ` Krzysztof Kozlowski
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.