From: Mayank Rana <quic_mrana@quicinc.com>
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
<linux-pci@vger.kernel.org>, <lpieralisi@kernel.org>,
<kw@linux.com>, <robh@kernel.org>, <bhelgaas@google.com>,
<andersson@kernel.org>, <manivannan.sadhasivam@linaro.org>,
<krzysztof.kozlowski+dt@linaro.org>, <conor+dt@kernel.org>,
<devicetree@vger.kernel.org>
Cc: <linux-arm-msm@vger.kernel.org>, <quic_ramkri@quicinc.com>,
<quic_nkela@quicinc.com>, <quic_shazhuss@quicinc.com>,
<quic_msarkar@quicinc.com>, <quic_nitegupt@quicinc.com>
Subject: Re: [RFC PATCH 1/2] dt-bindings: pcie: Document QCOM PCIE ECAM compatible root complex
Date: Thu, 18 Apr 2024 11:56:15 -0700 [thread overview]
Message-ID: <708e1adf-833d-4de5-9e94-406883337d16@quicinc.com> (raw)
In-Reply-To: <ce17f2dc-decf-4509-969e-e23bdef42eb9@linaro.org>
On 4/8/2024 11:21 PM, Krzysztof Kozlowski wrote:
> On 08/04/2024 21:09, Mayank Rana wrote:
>>>> + Firmware configures PCIe controller in RC mode with static iATU window mappings
>>>> + of configuration space for entire supported bus range in ECAM compatible mode.
>>>> +
>>>> +maintainers:
>>>> + - Mayank Rana <quic_mrana@quicinc.com>
>>>> +
>>>> +allOf:
>>>> + - $ref: /schemas/pci/pci-bus.yaml#
>>>> + - $ref: /schemas/power-domain/power-domain-consumer.yaml
>>>> +
>>>> +properties:
>>>> + compatible:
>>>> + const: qcom,pcie-ecam-rc
>>>
>>> No, this must have SoC specific compatibles.
>> This driver is proposed to work with any PCIe controller supported ECAM
>> functionality on Qualcomm platform
>> where firmware running on other VM/processor is controlling PCIe PHY and
>> controller for PCIe link up functionality.
>> Do you still suggest to have SoC specific compatibles here ?
>
> What does the writing-bindings document say? Why this is different than
> all other bindings?
Thank you for all your review comment and suggestions.
If it is must to have SOC name, then I am not sure how
pci-host-generic.c driver having non SOC prefix for standard ECAM
driver. I am here saying this is QCOM vendor specific generic ECAM
driver. saying that it seems that I would be updating now
pci-host-generic.c driver to add generic functionality as Rob suggested
part of review comment. With
that I am seeing possible options as i.e. continue using default generic
compatible as "pcie-host-ecam-generic" OR use new as
"qcom,pcie-host-ecam-generic". will this work ?>>>> +
>>>> + reg:
>>>> + minItems: 1
>>>
>>> maxItems instead
>>>
>>>> + description: ECAM address space starting from root port till supported bus range
>>>> +
>>>> + interrupts:
>>>> + minItems: 1
>>>> + maxItems: 8
>>>
>>> This is way too unspecific.
>> will review and update.
>>>> +
>>>> + ranges:
>>>> + minItems: 2
>>>> + maxItems: 3
>>>
>>> Why variable?
>> It depends on how ECAM configured to support 32-bit and 64-bit based
>> prefetch address space.
>> So there are different combination of prefetch (32-bit or 64-bit or
>> both) and non-prefetch (32-bit), and IO address space available. hence
>> kept it as variable with based on required use case and address space
>> availability.
>
> Really? So same device has it configured once for 32 once for 64-bit
> address space? Randomly?
no. as binding is not saying for any specific SOC. Depends on memory map
on particular SOC, how PCIe address space available based on that this
would change for particular SOC variant.
> Best regards,
> Krzysztof
>
next prev parent reply other threads:[~2024-04-18 18:56 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-04 19:11 [RFC PATCH 0/2] Add Qualcomm PCIe ECAM root complex driver Mayank Rana
2024-04-04 19:11 ` [RFC PATCH 1/2] dt-bindings: pcie: Document QCOM PCIE ECAM compatible root complex Mayank Rana
2024-04-04 19:30 ` Krzysztof Kozlowski
2024-04-08 19:09 ` Mayank Rana
2024-04-09 6:21 ` Krzysztof Kozlowski
2024-04-18 18:56 ` Mayank Rana [this message]
2024-04-18 20:53 ` Krzysztof Kozlowski
2024-04-04 19:11 ` [RFC PATCH 2/2] PCI: Add Qualcomm PCIe ECAM root complex driver Mayank Rana
2024-04-04 19:33 ` Krzysztof Kozlowski
2024-04-05 5:30 ` Manivannan Sadhasivam
2024-04-05 17:41 ` Mayank Rana
2024-04-06 4:17 ` Manivannan Sadhasivam
2024-04-08 18:57 ` Mayank Rana
2024-04-10 6:26 ` Manivannan Sadhasivam
2024-04-10 16:58 ` Rob Herring
2024-04-15 23:30 ` Mayank Rana
2024-05-31 22:47 ` Mayank Rana
2024-04-05 18:30 ` Bjorn Helgaas
2024-04-06 0:43 ` Mayank Rana
2024-04-04 19:33 ` [RFC PATCH 0/2] " Krzysztof Kozlowski
2024-04-04 23:02 ` Mayank Rana
2024-04-05 6:50 ` Krzysztof Kozlowski
2024-04-05 17:45 ` Mayank Rana
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=708e1adf-833d-4de5-9e94-406883337d16@quicinc.com \
--to=quic_mrana@quicinc.com \
--cc=andersson@kernel.org \
--cc=bhelgaas@google.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=krzysztof.kozlowski@linaro.org \
--cc=kw@linux.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=manivannan.sadhasivam@linaro.org \
--cc=quic_msarkar@quicinc.com \
--cc=quic_nitegupt@quicinc.com \
--cc=quic_nkela@quicinc.com \
--cc=quic_ramkri@quicinc.com \
--cc=quic_shazhuss@quicinc.com \
--cc=robh@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 read-only IMAP folder(s) and NNTP newsgroup(s).