Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1690438 > unrolled thread

Re: [PATCH 7/7] PCI: dwc: qcom: Add support for IPQ8074 PCIe controller

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 7/7] PCI: dwc: qcom: Add support for IPQ8074 PCIe  controller Bjorn Andersson <bjorn.andersson@linaro.org> - 2017-07-18 18:50 +0200
    Re: [PATCH 7/7] PCI: dwc: qcom: Add support for IPQ8074 PCIe  controller Varadarajan Narayanan <varada@codeaurora.org> - 2017-07-19 09:00 +0200
      Re: [PATCH 7/7] PCI: dwc: qcom: Add support for IPQ8074 PCIe  controller Stanimir Varbanov <svarbanov@mm-sol.com> - 2017-07-19 09:20 +0200
        Re: [PATCH 7/7] PCI: dwc: qcom: Add support for IPQ8074 PCIe  controller Varadarajan Narayanan <varada@codeaurora.org> - 2017-07-19 11:30 +0200
          Re: [PATCH 7/7] PCI: dwc: qcom: Add support for IPQ8074 PCIe  controller Vivek Gautam <vivek.gautam@codeaurora.org> - 2017-07-19 12:10 +0200
          Re: [PATCH 7/7] PCI: dwc: qcom: Add support for IPQ8074 PCIe  controller Stanimir Varbanov <svarbanov@mm-sol.com> - 2017-07-19 17:50 +0200

#1690438 — Re: [PATCH 7/7] PCI: dwc: qcom: Add support for IPQ8074 PCIe controller

On Tue 18 Jul 02:58 PDT 2017, Varadarajan Narayanan wrote:

> On Mon, Jul 17, 2017 at 03:07:18PM -0700, Bjorn Andersson wrote:
> > On Mon 17 Jul 05:04 PDT 2017, Varadarajan Narayanan wrote:
[..]
> >
> > Can you confirm that this is actually version 4 of this block? Or are we
> > just incrementing an arbitrary number here?
> 
> This is not exactly the 4th version of the block. However, it is
> a different version than the ones that are already supported in
> this driver. Since the existing driver didn't exactly tie it with
> the block IP version, I too followed the same versioning
> convention.
> 

Do you have a block IP version that you could base your numbering on, to
break the trend? (We should go back and fix up the others as well)

[..]
> > > +static int qcom_pcie_enable_resources_v4(struct qcom_pcie *pcie)
> > > +{
> > > +	struct qcom_pcie_resources_v4 *res = &pcie->res.v4;
> > > +	struct dw_pcie *pci = pcie->pci;
> > > +	struct device *dev = pci->dev;
> > > +	int ret;
> > > +
> > > +	ret = clk_prepare_enable(res->sys_noc_clk);
> > > +	if (ret) {
> > > +		dev_err(dev, "cannot prepare/enable core clock\n");
> > > +		return ret;
> > > +	}
> >
> > Should these clocks really be handled explicitly in the driver? Are
> > these not the bus clocks, to be handled by "msm_bus"?
> 
> This not the bus clock. This clock is for the Bus Interface Unit
> between the PCIe module and the System NOC.
> 

Right, that was the piece I meant. Sorry for not using the right
nomenclature.

So then it would be handled by the msm_bus in the downstream kernel?


Perhaps we can merge it like this and once we have the interconnect
framework setup we can make this the fallback method.

Thanks,
Bjorn

[toc] | [next] | [standalone]

#1691037

On Tue, Jul 18, 2017 at 09:44:38AM -0700, Bjorn Andersson wrote:
> On Tue 18 Jul 02:58 PDT 2017, Varadarajan Narayanan wrote:
>
> > On Mon, Jul 17, 2017 at 03:07:18PM -0700, Bjorn Andersson wrote:
> > > On Mon 17 Jul 05:04 PDT 2017, Varadarajan Narayanan wrote:
> [..]
> > >
> > > Can you confirm that this is actually version 4 of this block? Or are we
> > > just incrementing an arbitrary number here?
> >
> > This is not exactly the 4th version of the block. However, it is
> > a different version than the ones that are already supported in
> > this driver. Since the existing driver didn't exactly tie it with
> > the block IP version, I too followed the same versioning
> > convention.
> >
>
> Do you have a block IP version that you could base your numbering on, to
> break the trend? (We should go back and fix up the others as well)

Presently, the driver supports the ipq8064, apq8064, apq8084,
msm8996, ipq4019 and ipq8074. The SoCs, qcom_pcie_ops version and
the block IP versions are as follows.

	ipq8064 - v0 - 2.1.0
	apq8064 - v0 - 2.1.0
	apq8084 - v1 - 1.0.0
	msm8996 - v2 - 2.3.2
	ipq4019 - v3 - 2.4.0
	ipq8074 - v4 - 2.3.3

I will rename the qcom_pcie_ops structure and related functions
with the block IP version instead of vX numbering and post the
patch.

> [..]
> > > > +static int qcom_pcie_enable_resources_v4(struct qcom_pcie *pcie)
> > > > +{
> > > > +	struct qcom_pcie_resources_v4 *res = &pcie->res.v4;
> > > > +	struct dw_pcie *pci = pcie->pci;
> > > > +	struct device *dev = pci->dev;
> > > > +	int ret;
> > > > +
> > > > +	ret = clk_prepare_enable(res->sys_noc_clk);
> > > > +	if (ret) {
> > > > +		dev_err(dev, "cannot prepare/enable core clock\n");
> > > > +		return ret;
> > > > +	}
> > >
> > > Should these clocks really be handled explicitly in the driver? Are
> > > these not the bus clocks, to be handled by "msm_bus"?
> >
> > This not the bus clock. This clock is for the Bus Interface Unit
> > between the PCIe module and the System NOC.
> >
>
> Right, that was the piece I meant. Sorry for not using the right
> nomenclature.
>
> So then it would be handled by the msm_bus in the downstream kernel?
>
>
> Perhaps we can merge it like this and once we have the interconnect
> framework setup we can make this the fallback method.

Agree that this has to be handled by the interconnect framework.
For now will rename this as "iface" similar to v0 and v1.

Thanks
Varada

> Thanks,
> Bjorn

--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

[toc] | [prev] | [next] | [standalone]

#1691054

Hi,

On 07/19/2017 09:49 AM, Varadarajan Narayanan wrote:
> On Tue, Jul 18, 2017 at 09:44:38AM -0700, Bjorn Andersson wrote:
>> On Tue 18 Jul 02:58 PDT 2017, Varadarajan Narayanan wrote:
>>
>>> On Mon, Jul 17, 2017 at 03:07:18PM -0700, Bjorn Andersson wrote:
>>>> On Mon 17 Jul 05:04 PDT 2017, Varadarajan Narayanan wrote:
>> [..]
>>>>
>>>> Can you confirm that this is actually version 4 of this block? Or are we
>>>> just incrementing an arbitrary number here?
>>>
>>> This is not exactly the 4th version of the block. However, it is
>>> a different version than the ones that are already supported in
>>> this driver. Since the existing driver didn't exactly tie it with
>>> the block IP version, I too followed the same versioning
>>> convention.
>>>
>>
>> Do you have a block IP version that you could base your numbering on, to
>> break the trend? (We should go back and fix up the others as well)
> 
> Presently, the driver supports the ipq8064, apq8064, apq8084,
> msm8996, ipq4019 and ipq8074. The SoCs, qcom_pcie_ops version and
> the block IP versions are as follows.
> 
> 	ipq8064 - v0 - 2.1.0
> 	apq8064 - v0 - 2.1.0
> 	apq8084 - v1 - 1.0.0
> 	msm8996 - v2 - 2.3.2
> 	ipq4019 - v3 - 2.4.0
> 	ipq8074 - v4 - 2.3.3

That's nice, but I think we need the Synopsys IP versions too, can you
provide such an information and after that we can decide how the names
should look like.

> 
> I will rename the qcom_pcie_ops structure and related functions
> with the block IP version instead of vX numbering and post the
> patch.



regards,
Stan

[toc] | [prev] | [next] | [standalone]

#1691159

Stan,

On Wed, Jul 19, 2017 at 10:12:45AM +0300, Stanimir Varbanov wrote:
> Hi,
>
> On 07/19/2017 09:49 AM, Varadarajan Narayanan wrote:
> > On Tue, Jul 18, 2017 at 09:44:38AM -0700, Bjorn Andersson wrote:
> >> On Tue 18 Jul 02:58 PDT 2017, Varadarajan Narayanan wrote:
> >>
> >>> On Mon, Jul 17, 2017 at 03:07:18PM -0700, Bjorn Andersson wrote:
> >>>> On Mon 17 Jul 05:04 PDT 2017, Varadarajan Narayanan wrote:
> >> [..]
> >>>>
> >>>> Can you confirm that this is actually version 4 of this block? Or are we
> >>>> just incrementing an arbitrary number here?
> >>>
> >>> This is not exactly the 4th version of the block. However, it is
> >>> a different version than the ones that are already supported in
> >>> this driver. Since the existing driver didn't exactly tie it with
> >>> the block IP version, I too followed the same versioning
> >>> convention.
> >>>
> >>
> >> Do you have a block IP version that you could base your numbering on, to
> >> break the trend? (We should go back and fix up the others as well)
> >
> > Presently, the driver supports the ipq8064, apq8064, apq8084,
> > msm8996, ipq4019 and ipq8074. The SoCs, qcom_pcie_ops version and
> > the block IP versions are as follows.
> >
> > 	ipq8064 - v0 - 2.1.0
> > 	apq8064 - v0 - 2.1.0
> > 	apq8084 - v1 - 1.0.0
> > 	msm8996 - v2 - 2.3.2
> > 	ipq4019 - v3 - 2.4.0
> > 	ipq8074 - v4 - 2.3.3
>
> That's nice, but I think we need the Synopsys IP versions too, can you
> provide such an information and after that we can decide how the names
> should look like.

Sorry, I posted v2 before I saw this e-mail. Will post v3 based
on what naming style is decided.

The SoCs, qcom_pcie_ops version, the block IP version and
Synopsys IP versions are as follows.

	ipq8064 - v0 - 2.1.0 - 4.01a
	apq8064 - v0 - 2.1.0 - 4.01a
	apq8084 - v1 - 1.0.0 - 4.11a
	msm8996 - v2 - 2.3.2 - 4.21a
	ipq4019 - v3 - 2.4.0 - 4.20a
	ipq8074 - v4 - 2.3.3 - 4.30a

Thanks
Varada

> > I will rename the qcom_pcie_ops structure and related functions
> > with the block IP version instead of vX numbering and post the
> > patch.
>
>
>
> regards,
> Stan

--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

[toc] | [prev] | [next] | [standalone]

#1691297

Hi,


On 07/19/2017 02:59 PM, Varadarajan Narayanan wrote:
> Stan,
>
> On Wed, Jul 19, 2017 at 10:12:45AM +0300, Stanimir Varbanov wrote:
>> Hi,
>>
>> On 07/19/2017 09:49 AM, Varadarajan Narayanan wrote:
>>> On Tue, Jul 18, 2017 at 09:44:38AM -0700, Bjorn Andersson wrote:
>>>> On Tue 18 Jul 02:58 PDT 2017, Varadarajan Narayanan wrote:
>>>>
>>>>> On Mon, Jul 17, 2017 at 03:07:18PM -0700, Bjorn Andersson wrote:
>>>>>> On Mon 17 Jul 05:04 PDT 2017, Varadarajan Narayanan wrote:
>>>> [..]
>>>>>> Can you confirm that this is actually version 4 of this block? Or are we
>>>>>> just incrementing an arbitrary number here?
>>>>> This is not exactly the 4th version of the block. However, it is
>>>>> a different version than the ones that are already supported in
>>>>> this driver. Since the existing driver didn't exactly tie it with
>>>>> the block IP version, I too followed the same versioning
>>>>> convention.
>>>>>
>>>> Do you have a block IP version that you could base your numbering on, to
>>>> break the trend? (We should go back and fix up the others as well)
>>> Presently, the driver supports the ipq8064, apq8064, apq8084,
>>> msm8996, ipq4019 and ipq8074. The SoCs, qcom_pcie_ops version and
>>> the block IP versions are as follows.
>>>
>>> 	ipq8064 - v0 - 2.1.0
>>> 	apq8064 - v0 - 2.1.0
>>> 	apq8084 - v1 - 1.0.0
>>> 	msm8996 - v2 - 2.3.2
>>> 	ipq4019 - v3 - 2.4.0
>>> 	ipq8074 - v4 - 2.3.3
>> That's nice, but I think we need the Synopsys IP versions too, can you
>> provide such an information and after that we can decide how the names
>> should look like.
> Sorry, I posted v2 before I saw this e-mail. Will post v3 based
> on what naming style is decided.
>
> The SoCs, qcom_pcie_ops version, the block IP version and
> Synopsys IP versions are as follows.
>
> 	ipq8064 - v0 - 2.1.0 - 4.01a
> 	apq8064 - v0 - 2.1.0 - 4.01a
> 	apq8084 - v1 - 1.0.0 - 4.11a
> 	msm8996 - v2 - 2.3.2 - 4.21a
> 	ipq4019 - v3 - 2.4.0 - 4.20a
> 	ipq8074 - v4 - 2.3.3 - 4.30a

I would have loved to say the dwc IP versions sounds better, but
this is the qcom wrapper over dwc. So, for me it makes more sense
to have qcom specific IP version names.
Can we have couple or more versions of qcom pcie IPs based on
same dwc IP version? I have not looked closely, but in that case
too using qcom nomenclature would again make more sense.


Thanks
Vivek

>
> Thanks
> Varada
>
>>> I will rename the qcom_pcie_ops structure and related functions
>>> with the block IP version instead of vX numbering and post the
>>> patch.
>>
>>
>> regards,
>> Stan
> --
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[toc] | [prev] | [next] | [standalone]

#1691928

Hi,

On 07/19/2017 12:29 PM, Varadarajan Narayanan wrote:
> Stan,
> 

<cut>

>> That's nice, but I think we need the Synopsys IP versions too, can you
>> provide such an information and after that we can decide how the names
>> should look like.
> 
> Sorry, I posted v2 before I saw this e-mail. Will post v3 based
> on what naming style is decided.
> 
> The SoCs, qcom_pcie_ops version, the block IP version and
> Synopsys IP versions are as follows.
> 
> 	ipq8064 - v0 - 2.1.0 - 4.01a
> 	apq8064 - v0 - 2.1.0 - 4.01a
> 	apq8084 - v1 - 1.0.0 - 4.11a
> 	msm8996 - v2 - 2.3.2 - 4.21a
> 	ipq4019 - v3 - 2.4.0 - 4.20a
> 	ipq8074 - v4 - 2.3.3 - 4.30a

I'm not sure, with Synopsys versions the mess becomes bigger.

So I tend to agree with qcom versions (because this driver taking care
of qcom wrappers over Synopsys IP) plus comments about Synopsys version
used for this particular SoC, just for completeness.


regards,
Stan

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web