All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kishon Vijay Abraham I <kishon@ti.com>
To: Lukasz Majewski <lukma@denx.de>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Jingoo Han <jingoohan1@gmail.com>,
	Joao Pinto <Joao.Pinto@synopsys.com>,
	linux-omap@vger.kernel.org, linux-pci@vger.kernel.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] pcie: ti: Provide patch to force GEN1 PCIe operation
Date: Mon, 16 Jan 2017 15:43:58 +0530	[thread overview]
Message-ID: <587C9CE6.8040001@ti.com> (raw)
In-Reply-To: <20170116103136.21c899ac@jawa>

+ Joao, Jingoo

Hi,

On Monday 16 January 2017 03:01 PM, Lukasz Majewski wrote:
> Hi Kishon,
> 
>> Hi Łukasz,
>>
>> On Monday 16 January 2017 12:19 PM, Lukasz Majewski wrote:
>>> Hi Kishon,
>>>
>>>> Hi,
>>>>
>>>> On Sunday 15 January 2017 06:49 PM, Lukasz Majewski wrote:
>>>>> Some devices (due to e.g. bad PCIe signal integrity) require to
>>>>> run with forced GEN1 speed on PCIe bus.
>>>>>
>>>>> This patch changes the speed explicitly on dra7 based devices when
>>>>> proper device tree attribute is defined for the PCIe controller.
>>>>>
>>>>> Signed-off-by: Lukasz Majewski <lukma@denx.de>
>>>>
>>>> Bjorn has already queued a patch to do the same thing
>>>> https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/log/?h=pci/host-dra7xx
>>>
>>> It seems like Bjorn only modifies CAP registers.
>>
>> The patch also modifies the LNKCTL2 register.
>>>
>>> He also needs to change register with 0x080C offset to actually
>>> ( PCIECTRL_PL_WIDTH_SPEED_CTL )
>>
>> This bit is used to initiate speed change (after the link is
>> initialized in GEN1). Resetting the bit (like what you have done
>> here) prevents speed change.
> 
> This is strange, but e2e advised me to do things as I did in the patch
> to _force_ GEN1 operation on PCIe2 port [1] (AM5728)
> 
> Link:
> [1] https://e2e.ti.com/support/arm/sitara_arm/f/791/t/566421
> 
> Both patches modify 0x5180 007C register to set GEN1 capability
> (PCI_EXP_LNKCAP_SLS_2_5GB)
> 
> The problem is with second register (in your patch):
> 
> From SPRUHZ6G TRM:
> 
> PCIECTRL_EP_DBICS_LNK_CAS_2 (0x5180 00A0)
> - TRGT_LINK_SPEED (Reset 0x1) - "Target Link Speed" - no more
>   description in TRM
> 
> It is set to PCI_EXP_LNKCAP_SLS_2_5GB = 0x1, which is the same as
> default /reset value.

The default value is 0x2 (or else none of the cards would have enumerated in GEN2)
> 
> 
> Could you clarify which way to _force_ PCIe GEN1 operation is correct?
> Mine shows differences in lspci output (as posted in [1]).

You'll see the difference even with the patch in Bjorn's tree ;-)

I think these are 2 different approaches to keep the link at GEN1. Joao or
Jingoo, do you have any suggestion here?

> 
>>
>> IMO the better way is to set the LNKCTL2 to GEN1 instead of hacking
>> the IP register.
> 
> From the original patch description:
> 
> "Add support to force Root Complex to work in GEN1 mode if so desired,
> but don't force GEN1 mode on any board just yet."
> 
> Are there any (floating around) patches allowing forcing GEN1 operation
> on any board (I would like to reuse/port them to my current solution)?

For setting to GEN1 mode, "max-link-speed" should be set to 1 in dt with the
patch in Bjorn's tree.

Thanks
Kishon

WARNING: multiple messages have this Message-ID (diff)
From: Kishon Vijay Abraham I <kishon@ti.com>
To: Lukasz Majewski <lukma@denx.de>,
	Joao Pinto <Joao.Pinto@synopsys.com>,
	"jingoohan1@gmail.com" <jingoohan1@gmail.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Jingoo Han <jingoohan1@gmail.com>,
	Joao Pinto <Joao.Pinto@synopsys.com>,
	<linux-omap@vger.kernel.org>, <linux-pci@vger.kernel.org>,
	<devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] pcie: ti: Provide patch to force GEN1 PCIe operation
Date: Mon, 16 Jan 2017 15:43:58 +0530	[thread overview]
Message-ID: <587C9CE6.8040001@ti.com> (raw)
In-Reply-To: <20170116103136.21c899ac@jawa>

+ Joao, Jingoo

Hi,

On Monday 16 January 2017 03:01 PM, Lukasz Majewski wrote:
> Hi Kishon,
> 
>> Hi Łukasz,
>>
>> On Monday 16 January 2017 12:19 PM, Lukasz Majewski wrote:
>>> Hi Kishon,
>>>
>>>> Hi,
>>>>
>>>> On Sunday 15 January 2017 06:49 PM, Lukasz Majewski wrote:
>>>>> Some devices (due to e.g. bad PCIe signal integrity) require to
>>>>> run with forced GEN1 speed on PCIe bus.
>>>>>
>>>>> This patch changes the speed explicitly on dra7 based devices when
>>>>> proper device tree attribute is defined for the PCIe controller.
>>>>>
>>>>> Signed-off-by: Lukasz Majewski <lukma@denx.de>
>>>>
>>>> Bjorn has already queued a patch to do the same thing
>>>> https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/log/?h=pci/host-dra7xx
>>>
>>> It seems like Bjorn only modifies CAP registers.
>>
>> The patch also modifies the LNKCTL2 register.
>>>
>>> He also needs to change register with 0x080C offset to actually
>>> ( PCIECTRL_PL_WIDTH_SPEED_CTL )
>>
>> This bit is used to initiate speed change (after the link is
>> initialized in GEN1). Resetting the bit (like what you have done
>> here) prevents speed change.
> 
> This is strange, but e2e advised me to do things as I did in the patch
> to _force_ GEN1 operation on PCIe2 port [1] (AM5728)
> 
> Link:
> [1] https://e2e.ti.com/support/arm/sitara_arm/f/791/t/566421
> 
> Both patches modify 0x5180 007C register to set GEN1 capability
> (PCI_EXP_LNKCAP_SLS_2_5GB)
> 
> The problem is with second register (in your patch):
> 
> From SPRUHZ6G TRM:
> 
> PCIECTRL_EP_DBICS_LNK_CAS_2 (0x5180 00A0)
> - TRGT_LINK_SPEED (Reset 0x1) - "Target Link Speed" - no more
>   description in TRM
> 
> It is set to PCI_EXP_LNKCAP_SLS_2_5GB = 0x1, which is the same as
> default /reset value.

The default value is 0x2 (or else none of the cards would have enumerated in GEN2)
> 
> 
> Could you clarify which way to _force_ PCIe GEN1 operation is correct?
> Mine shows differences in lspci output (as posted in [1]).

You'll see the difference even with the patch in Bjorn's tree ;-)

I think these are 2 different approaches to keep the link at GEN1. Joao or
Jingoo, do you have any suggestion here?

> 
>>
>> IMO the better way is to set the LNKCTL2 to GEN1 instead of hacking
>> the IP register.
> 
> From the original patch description:
> 
> "Add support to force Root Complex to work in GEN1 mode if so desired,
> but don't force GEN1 mode on any board just yet."
> 
> Are there any (floating around) patches allowing forcing GEN1 operation
> on any board (I would like to reuse/port them to my current solution)?

For setting to GEN1 mode, "max-link-speed" should be set to 1 in dt with the
patch in Bjorn's tree.

Thanks
Kishon

  reply	other threads:[~2017-01-16 10:13 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-15 13:19 [PATCH] pcie: ti: Provide patch to force GEN1 PCIe operation Lukasz Majewski
2017-01-15 13:19 ` Lukasz Majewski
2017-01-16  6:37 ` Kishon Vijay Abraham I
2017-01-16  6:37   ` Kishon Vijay Abraham I
2017-01-16  6:49   ` Lukasz Majewski
2017-01-16  6:49     ` Lukasz Majewski
2017-01-16  8:12     ` Kishon Vijay Abraham I
2017-01-16  8:12       ` Kishon Vijay Abraham I
2017-01-16  9:31       ` Lukasz Majewski
2017-01-16  9:31         ` Lukasz Majewski
2017-01-16 10:13         ` Kishon Vijay Abraham I [this message]
2017-01-16 10:13           ` Kishon Vijay Abraham I
2017-01-16 10:34           ` Lukasz Majewski
2017-01-16 10:34             ` Lukasz Majewski
2017-01-16 13:40           ` Joao Pinto
2017-01-16 13:40             ` Joao Pinto
2017-01-16 17:01           ` Joao Pinto
2017-01-16 17:01             ` Joao Pinto
2017-01-16 21:44             ` Lukasz Majewski
2017-01-16 21:44               ` Lukasz Majewski
2017-01-17 10:43               ` Joao Pinto
2017-01-17 10:43                 ` Joao Pinto
2017-01-17 11:23                 ` Joao Pinto
2017-01-17 11:23                   ` Joao Pinto
2017-01-17 11:38                   ` Lukasz Majewski
2017-01-17 11:38                     ` Lukasz Majewski
2017-01-17 11:48                     ` Joao Pinto
2017-01-17 11:48                       ` Joao Pinto
     [not found]             ` <76d18446-78c9-87f2-22ad-f7ea38771285-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
2017-01-17  5:35               ` Kishon Vijay Abraham I
2017-01-17  5:35                 ` Kishon Vijay Abraham I
2017-01-17 10:19                 ` Joao Pinto
2017-01-17 10:19                   ` Joao Pinto
2017-01-28 20:54 ` Bjorn Helgaas

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=587C9CE6.8040001@ti.com \
    --to=kishon@ti.com \
    --cc=Joao.Pinto@synopsys.com \
    --cc=bhelgaas@google.com \
    --cc=devicetree@vger.kernel.org \
    --cc=jingoohan1@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lukma@denx.de \
    --cc=mark.rutland@arm.com \
    --cc=robh+dt@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.