From: Kishon Vijay Abraham I <kishon@ti.com>
To: Rob Herring <robh+dt@kernel.org>,
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Tom Joseph <tjoseph@cadence.com>,
Bjorn Helgaas <bhelgaas@google.com>,
Mark Rutland <mark.rutland@arm.com>,
Arnd Bergmann <arnd@arndb.de>,
Gustavo Pimentel <gustavo.pimentel@synopsys.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Frank Rowand <frowand.list@gmail.com>,
Jingoo Han <jingoohan1@gmail.com>, <linux-pci@vger.kernel.org>,
<devicetree@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
linux-omap <linux-omap@vger.kernel.org>,
"open list:ARM/Rockchip SoC..."
<linux-rockchip@lists.infradead.org>,
"moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFC PATCH 23/30] of/platform: Export of_platform_device_create_pdata()
Date: Fri, 19 Jul 2019 16:25:37 +0530 [thread overview]
Message-ID: <f9034a1d-1906-54e8-62f0-cdacf95c42ab@ti.com> (raw)
In-Reply-To: <a80c7c33-7091-70d9-cd86-a19fe43d3bc6@ti.com>
Lorenzo,
On 11/06/19 10:08 AM, Kishon Vijay Abraham I wrote:
> Hi Rob,
>
> On 10/06/19 11:13 PM, Rob Herring wrote:
>> On Tue, Jun 4, 2019 at 7:19 AM Kishon Vijay Abraham I <kishon@ti.com> wrote:
>>>
>>> Export of_platform_device_create_pdata() to be used by drivers to
>>> create child devices with the given platform data. This can be used
>>> by platform specific driver to send platform data core driver. For e.g.,
>>> this will be used by TI's J721E SoC specific PCIe driver to send
>>> ->start_link() ops and ->is_link_up() ops to Cadence core PCIe driver.
>>
>> NAK
>>
>> of_platform_device_create_pdata() is purely for legacy handling of
>> auxdata which is something I hope to get rid of someday. Or to put it
>> another way, auxdata use is a sign of platforms not fully converted to
>> DT.
>
> All right. Thanks for letting me know your thoughts.
>
> Lorenzo,
>
> We've modeled Cadence PCIe core as a separate driver and for some of the
> functionalities (for example starting LTSSM or checking link status) it has to
> invoke the wrapper driver functions (The registers for these are present in
> wrapper and not in Cadence Core). In the case of Designware, we modeled DWC
> core as a library which provided APIs to be used by wrapper driver. Now that
> Rob is not inclined for passing platform data from one driver to another (in
> this case TI specific J721E driver to Cadence PCIe driver), should we model
> Cadence core also as a library? If you agree, I can prepare patches for making
> Cadence PCIe core as a library. Please let me know your thoughts.
Can you share your thoughts on this?
Thanks
Kishon
WARNING: multiple messages have this Message-ID (diff)
From: Kishon Vijay Abraham I <kishon@ti.com>
To: Rob Herring <robh+dt@kernel.org>,
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Tom Joseph <tjoseph@cadence.com>,
Bjorn Helgaas <bhelgaas@google.com>,
Mark Rutland <mark.rutland@arm.com>,
Arnd Bergmann <arnd@arndb.de>,
Gustavo Pimentel <gustavo.pimentel@synopsys.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Frank Rowand <frowand.list@gmail.com>,
Jingoo Han <jingoohan1@gmail.com>,
linux-pci@vger.kernel.org, devicetree@vger.kernel.org,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
linux-omap <linux-omap@vger.kernel.org>,
"open list:ARM/Rockchip SoC..."
<linux-rockchip@lists.infradead.org>,
"moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFC PATCH 23/30] of/platform: Export of_platform_device_create_pdata()
Date: Fri, 19 Jul 2019 16:25:37 +0530 [thread overview]
Message-ID: <f9034a1d-1906-54e8-62f0-cdacf95c42ab@ti.com> (raw)
In-Reply-To: <a80c7c33-7091-70d9-cd86-a19fe43d3bc6@ti.com>
Lorenzo,
On 11/06/19 10:08 AM, Kishon Vijay Abraham I wrote:
> Hi Rob,
>
> On 10/06/19 11:13 PM, Rob Herring wrote:
>> On Tue, Jun 4, 2019 at 7:19 AM Kishon Vijay Abraham I <kishon@ti.com> wrote:
>>>
>>> Export of_platform_device_create_pdata() to be used by drivers to
>>> create child devices with the given platform data. This can be used
>>> by platform specific driver to send platform data core driver. For e.g.,
>>> this will be used by TI's J721E SoC specific PCIe driver to send
>>> ->start_link() ops and ->is_link_up() ops to Cadence core PCIe driver.
>>
>> NAK
>>
>> of_platform_device_create_pdata() is purely for legacy handling of
>> auxdata which is something I hope to get rid of someday. Or to put it
>> another way, auxdata use is a sign of platforms not fully converted to
>> DT.
>
> All right. Thanks for letting me know your thoughts.
>
> Lorenzo,
>
> We've modeled Cadence PCIe core as a separate driver and for some of the
> functionalities (for example starting LTSSM or checking link status) it has to
> invoke the wrapper driver functions (The registers for these are present in
> wrapper and not in Cadence Core). In the case of Designware, we modeled DWC
> core as a library which provided APIs to be used by wrapper driver. Now that
> Rob is not inclined for passing platform data from one driver to another (in
> this case TI specific J721E driver to Cadence PCIe driver), should we model
> Cadence core also as a library? If you agree, I can prepare patches for making
> Cadence PCIe core as a library. Please let me know your thoughts.
Can you share your thoughts on this?
Thanks
Kishon
WARNING: multiple messages have this Message-ID (diff)
From: Kishon Vijay Abraham I <kishon@ti.com>
To: Rob Herring <robh+dt@kernel.org>,
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
devicetree@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>,
Jingoo Han <jingoohan1@gmail.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-pci@vger.kernel.org,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"open list:ARM/Rockchip SoC..."
<linux-rockchip@lists.infradead.org>,
Tom Joseph <tjoseph@cadence.com>,
Gustavo Pimentel <gustavo.pimentel@synopsys.com>,
Bjorn Helgaas <bhelgaas@google.com>,
linux-omap <linux-omap@vger.kernel.org>,
Frank Rowand <frowand.list@gmail.com>,
"moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFC PATCH 23/30] of/platform: Export of_platform_device_create_pdata()
Date: Fri, 19 Jul 2019 16:25:37 +0530 [thread overview]
Message-ID: <f9034a1d-1906-54e8-62f0-cdacf95c42ab@ti.com> (raw)
In-Reply-To: <a80c7c33-7091-70d9-cd86-a19fe43d3bc6@ti.com>
Lorenzo,
On 11/06/19 10:08 AM, Kishon Vijay Abraham I wrote:
> Hi Rob,
>
> On 10/06/19 11:13 PM, Rob Herring wrote:
>> On Tue, Jun 4, 2019 at 7:19 AM Kishon Vijay Abraham I <kishon@ti.com> wrote:
>>>
>>> Export of_platform_device_create_pdata() to be used by drivers to
>>> create child devices with the given platform data. This can be used
>>> by platform specific driver to send platform data core driver. For e.g.,
>>> this will be used by TI's J721E SoC specific PCIe driver to send
>>> ->start_link() ops and ->is_link_up() ops to Cadence core PCIe driver.
>>
>> NAK
>>
>> of_platform_device_create_pdata() is purely for legacy handling of
>> auxdata which is something I hope to get rid of someday. Or to put it
>> another way, auxdata use is a sign of platforms not fully converted to
>> DT.
>
> All right. Thanks for letting me know your thoughts.
>
> Lorenzo,
>
> We've modeled Cadence PCIe core as a separate driver and for some of the
> functionalities (for example starting LTSSM or checking link status) it has to
> invoke the wrapper driver functions (The registers for these are present in
> wrapper and not in Cadence Core). In the case of Designware, we modeled DWC
> core as a library which provided APIs to be used by wrapper driver. Now that
> Rob is not inclined for passing platform data from one driver to another (in
> this case TI specific J721E driver to Cadence PCIe driver), should we model
> Cadence core also as a library? If you agree, I can prepare patches for making
> Cadence PCIe core as a library. Please let me know your thoughts.
Can you share your thoughts on this?
Thanks
Kishon
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-07-19 10:57 UTC|newest]
Thread overview: 104+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-04 13:14 [RFC PATCH 00/30] Add PCIe support to TI's J721E SoC Kishon Vijay Abraham I
2019-06-04 13:14 ` Kishon Vijay Abraham I
2019-06-04 13:14 ` Kishon Vijay Abraham I
2019-06-04 13:14 ` [RFC PATCH 01/30] dt-bindings: PCI: cadence: Add DT binding to use PCIe with IOMMU Kishon Vijay Abraham I
2019-06-04 13:14 ` Kishon Vijay Abraham I
2019-06-04 13:14 ` Kishon Vijay Abraham I
2019-06-04 13:14 ` [RFC PATCH 02/30] dt-bindings: PCI: cadence: Add binding to reset PERST# Kishon Vijay Abraham I
2019-06-04 13:14 ` Kishon Vijay Abraham I
2019-06-04 13:14 ` Kishon Vijay Abraham I
2019-06-04 13:14 ` [RFC PATCH 03/30] dt-bindings: PCI: cadence: Update host DT bindings with TI specific compatible Kishon Vijay Abraham I
2019-06-04 13:14 ` Kishon Vijay Abraham I
2019-06-04 13:14 ` Kishon Vijay Abraham I
2019-06-04 13:14 ` [RFC PATCH 04/30] dt-bindings: PCI: cadence: Update EP " Kishon Vijay Abraham I
2019-06-04 13:14 ` Kishon Vijay Abraham I
2019-06-04 13:14 ` Kishon Vijay Abraham I
2019-06-04 13:14 ` [RFC PATCH 05/30] linux/kernel.h: Add PTR_ALIGN_DOWN macro Kishon Vijay Abraham I
2019-06-04 13:14 ` Kishon Vijay Abraham I
2019-06-04 13:14 ` Kishon Vijay Abraham I
2019-06-04 13:14 ` [RFC PATCH 06/30] PCI: cadence: Add support to use custom read and write accessors Kishon Vijay Abraham I
2019-06-04 13:14 ` Kishon Vijay Abraham I
2019-06-04 13:14 ` Kishon Vijay Abraham I
2019-06-04 13:14 ` [RFC PATCH 07/30] PCI: cadence: Add read and write accessors to perform only 32-bit accesses Kishon Vijay Abraham I
2019-06-04 13:14 ` Kishon Vijay Abraham I
2019-06-04 13:14 ` Kishon Vijay Abraham I
2019-06-04 13:14 ` [RFC PATCH 08/30] PCI: cadence: Add support to use PCIe in J721E SoC Kishon Vijay Abraham I
2019-06-04 13:14 ` Kishon Vijay Abraham I
2019-06-04 13:14 ` Kishon Vijay Abraham I
2019-06-04 13:14 ` [RFC PATCH 09/30] PCI: cadence: Add platform_data to start link and check link status Kishon Vijay Abraham I
2019-06-04 13:14 ` Kishon Vijay Abraham I
2019-06-04 13:14 ` Kishon Vijay Abraham I
2019-06-04 13:14 ` [RFC PATCH 10/30] PCI: cadence: Use *_start_link() and *_wait_for_link() to establish link Kishon Vijay Abraham I
2019-06-04 13:14 ` Kishon Vijay Abraham I
2019-06-04 13:14 ` Kishon Vijay Abraham I
2019-06-04 13:14 ` [RFC PATCH 11/30] PCI: cadence: Add support to drive PERST# line using GPIO Kishon Vijay Abraham I
2019-06-04 13:14 ` Kishon Vijay Abraham I
2019-06-04 13:14 ` Kishon Vijay Abraham I
2019-06-04 13:14 ` [RFC PATCH 12/30] PCI: cadence: Make "mem" an optional memory resource Kishon Vijay Abraham I
2019-06-04 13:14 ` Kishon Vijay Abraham I
2019-06-04 13:14 ` Kishon Vijay Abraham I
2019-06-04 13:14 ` [RFC PATCH 13/30] PCI: cadence: Use local management register to configure Vendor ID Kishon Vijay Abraham I
2019-06-04 13:14 ` Kishon Vijay Abraham I
2019-06-04 13:14 ` Kishon Vijay Abraham I
2019-06-04 13:15 ` [RFC PATCH 14/30] PCI: endpoint: Use notification chain mechanism to notify EPC events to EPF Kishon Vijay Abraham I
2019-06-04 13:15 ` Kishon Vijay Abraham I
2019-06-04 13:15 ` Kishon Vijay Abraham I
2019-06-04 13:15 ` [RFC PATCH 15/30] PCI: endpoint: Replace spinlock with mutex Kishon Vijay Abraham I
2019-06-04 13:15 ` Kishon Vijay Abraham I
2019-06-04 13:15 ` Kishon Vijay Abraham I
2019-06-04 13:15 ` [RFC PATCH 16/30] PCI: endpoint: Assign function number of each PF in EPC core Kishon Vijay Abraham I
2019-06-04 13:15 ` Kishon Vijay Abraham I
2019-06-04 13:15 ` Kishon Vijay Abraham I
2019-06-04 13:15 ` [RFC PATCH 17/30] PCI: endpoint: Protect concurrent access to pci_epf_ops with mutex Kishon Vijay Abraham I
2019-06-04 13:15 ` Kishon Vijay Abraham I
2019-06-04 13:15 ` Kishon Vijay Abraham I
2019-06-04 13:15 ` [RFC PATCH 18/30] PCI: endpoint: Add support to add virtual function in endpoint core Kishon Vijay Abraham I
2019-06-04 13:15 ` Kishon Vijay Abraham I
2019-06-04 13:15 ` Kishon Vijay Abraham I
2019-06-04 13:15 ` [RFC PATCH 19/30] PCI: endpoint: Add support to link a physical function to a virtual function Kishon Vijay Abraham I
2019-06-04 13:15 ` Kishon Vijay Abraham I
2019-06-04 13:15 ` Kishon Vijay Abraham I
2019-06-04 13:15 ` [RFC PATCH 20/30] PCI: endpoint: Add virtual function number in pci_epc ops Kishon Vijay Abraham I
2019-06-04 13:15 ` Kishon Vijay Abraham I
2019-06-04 13:15 ` Kishon Vijay Abraham I
2019-06-04 13:15 ` [RFC PATCH 21/30] PCI: cadence: Add support to configure virtual functions Kishon Vijay Abraham I
2019-06-04 13:15 ` Kishon Vijay Abraham I
2019-06-04 13:15 ` Kishon Vijay Abraham I
2019-06-04 13:15 ` [RFC PATCH 22/30] PCI: cadence: Configure pci_epc_features to align BAR addresses to 256 Bytes Kishon Vijay Abraham I
2019-06-04 13:15 ` Kishon Vijay Abraham I
2019-06-04 13:15 ` Kishon Vijay Abraham I
2019-06-04 13:15 ` [RFC PATCH 23/30] of/platform: Export of_platform_device_create_pdata() Kishon Vijay Abraham I
2019-06-04 13:15 ` Kishon Vijay Abraham I
2019-06-04 13:15 ` Kishon Vijay Abraham I
2019-06-10 17:43 ` Rob Herring
2019-06-10 17:43 ` Rob Herring
2019-06-10 17:43 ` Rob Herring
2019-06-11 4:38 ` Kishon Vijay Abraham I
2019-06-11 4:38 ` Kishon Vijay Abraham I
2019-06-11 4:38 ` Kishon Vijay Abraham I
2019-07-19 10:55 ` Kishon Vijay Abraham I [this message]
2019-07-19 10:55 ` Kishon Vijay Abraham I
2019-07-19 10:55 ` Kishon Vijay Abraham I
2019-06-04 13:15 ` [RFC PATCH 24/30] dt-bindings: PCI: J721E: Add DT bindings for PCIe controller in J721E Kishon Vijay Abraham I
2019-06-04 13:15 ` Kishon Vijay Abraham I
2019-06-04 13:15 ` Kishon Vijay Abraham I
2019-06-04 13:15 ` [RFC PATCH 25/30] PCI: j721e: Add TI J721E PCIe driver Kishon Vijay Abraham I
2019-06-04 13:15 ` Kishon Vijay Abraham I
2019-06-04 13:15 ` Kishon Vijay Abraham I
2019-06-04 13:15 ` [RFC PATCH 26/30] MAINTAINERS: Add MAINTAINER entry for PCIe on TI's J721E SoC Kishon Vijay Abraham I
2019-06-04 13:15 ` Kishon Vijay Abraham I
2019-06-04 13:15 ` Kishon Vijay Abraham I
2019-06-04 19:45 ` Bjorn Helgaas
2019-06-04 19:45 ` Bjorn Helgaas
2019-06-04 13:15 ` [RFC PATCH 27/30] misc: pci_endpoint_test: Add J721E in pci_device_id table Kishon Vijay Abraham I
2019-06-04 13:15 ` Kishon Vijay Abraham I
2019-06-04 13:15 ` Kishon Vijay Abraham I
2019-06-04 13:15 ` [RFC PATCH 28/30] misc: pci_endpoint_test: Avoid using module parameter to determine irqtype Kishon Vijay Abraham I
2019-06-04 13:15 ` Kishon Vijay Abraham I
2019-06-04 13:15 ` Kishon Vijay Abraham I
2019-06-04 13:15 ` [RFC PATCH 29/30] misc: pci_endpoint_test: Populate sriov_configure ops to configure SRIOV device Kishon Vijay Abraham I
2019-06-04 13:15 ` Kishon Vijay Abraham I
2019-06-04 13:15 ` Kishon Vijay Abraham I
2019-06-04 13:15 ` [RFC PATCH 30/30] misc: pci_endpoint_test: Enable legacy interrupt Kishon Vijay Abraham I
2019-06-04 13:15 ` Kishon Vijay Abraham I
2019-06-04 13:15 ` Kishon Vijay Abraham I
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=f9034a1d-1906-54e8-62f0-cdacf95c42ab@ti.com \
--to=kishon@ti.com \
--cc=arnd@arndb.de \
--cc=bhelgaas@google.com \
--cc=devicetree@vger.kernel.org \
--cc=frowand.list@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=gustavo.pimentel@synopsys.com \
--cc=jingoohan1@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=mark.rutland@arm.com \
--cc=robh+dt@kernel.org \
--cc=tjoseph@cadence.com \
/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.