diff mbox

[v3,3/3] pci: dra7xx: use pdata callbacks to perform reset

Message ID 56C5D377.50901@ti.com
State New
Headers show

Commit Message

Sekhar Nori Feb. 18, 2016, 2:21 p.m. UTC
On Friday 12 February 2016 10:50 PM, Suman Anna wrote:
> Sekhar,

> Will you be following up with above suggestion since Kishon is gonna be out?


Alright, noticed this action for me :) Went through the thread, and 
looks like this is what we want to see?

Thanks,
Sekhar

---8<---
From e3ba368f2235e1bf38a22ba8ea4e5c12aaafda19 Mon Sep 17 00:00:00 2001
Message-Id: <e3ba368f2235e1bf38a22ba8ea4e5c12aaafda19.1455803758.git.nsekhar@ti.com>
From: Sekhar Nori <nsekhar@ti.com>

Date: Thu, 18 Feb 2016 16:49:56 +0530
Subject: [PATCH 1/1] ARM: DRA7: hwmod: Add custom reset handler for PCIeSS

Add a custom reset handler for DRA7x PCIeSS. This
handler is required to deassert PCIe hardreset lines
after they have been asserted.

This enables the PCIe driver to access registers after
PCIeSS has been runtime enabled without having to
deassert hardreset lines itself.

With this patch applied, used lspci to make sure
connected PCIe device enumerates on DRA74x and DRA72x
EVMs.

Signed-off-by: Sekhar Nori <nsekhar@ti.com>

---
Applies to tag for-v4.6/omap-hwmod-a of Paul W's tree.

 arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

-- 
2.6.3

Comments

Suman Anna Feb. 18, 2016, 6:27 p.m. UTC | #1
On 02/18/2016 11:23 AM, Paul Walmsley wrote:
> 

> On Thu, 18 Feb 2016, Sekhar Nori wrote:

> 

>> On Friday 12 February 2016 10:50 PM, Suman Anna wrote:

>>> Sekhar,

>>> Will you be following up with above suggestion since Kishon is gonna be out?

>>

>> Alright, noticed this action for me :) Went through the thread, and 

>> looks like this is what we want to see?

> 

> Thanks Sekhar.  Did you try the driver unbind/bind sequence a few times to 

> ensure that works, per Suman's earlier E-mail? 


Should work since the assert/deassert is now out of the driver
probe/remove path and is done only at init time, but will let Sekhar
confirm this.

> 

> Suman, is there any further testing that you are planning to do on this 

> patch?


No, nothing on my side, since this is now localized to PCIe and only on
DRA7xx. I will relook at your custom flags solution when I consolidate
the reset for OMAP IOMMUs and remoteprocs, that looks promising to
remove the pdata quirks for resets or dependencies in drivers against a
reset API.

> 

> - Paul

> 

> 

>>

>> Thanks,

>> Sekhar

>>

>> ---8<---

>> >From e3ba368f2235e1bf38a22ba8ea4e5c12aaafda19 Mon Sep 17 00:00:00 2001

>> Message-Id: <e3ba368f2235e1bf38a22ba8ea4e5c12aaafda19.1455803758.git.nsekhar@ti.com>

>> From: Sekhar Nori <nsekhar@ti.com>

>> Date: Thu, 18 Feb 2016 16:49:56 +0530

>> Subject: [PATCH 1/1] ARM: DRA7: hwmod: Add custom reset handler for PCIeSS

>>

>> Add a custom reset handler for DRA7x PCIeSS. This

>> handler is required to deassert PCIe hardreset lines

>> after they have been asserted.

>>

>> This enables the PCIe driver to access registers after

>> PCIeSS has been runtime enabled without having to

>> deassert hardreset lines itself.

>>

>> With this patch applied, used lspci to make sure

>> connected PCIe device enumerates on DRA74x and DRA72x

>> EVMs.


Yep, this is what I had in mind. Glad that it resolves the issue.

>>

>> Signed-off-by: Sekhar Nori <nsekhar@ti.com>

>> ---

>> Applies to tag for-v4.6/omap-hwmod-a of Paul W's tree.

>>

>>  arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 23 +++++++++++++++++++++++

>>  1 file changed, 23 insertions(+)

>>

>> diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c

>> index b61355e2a771..252b74633e31 100644

>> --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c

>> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c

>> @@ -1526,8 +1526,31 @@ static struct omap_hwmod dra7xx_ocp2scp3_hwmod = {

>>   *

>>   */

>>  

>> +/*

>> + * As noted in documentation for _reset() in omap_hwmod.c, the stock reset

>> + * functionality of OMAP HWMOD layer does not deassert the hardreset lines

>> + * associated with an IP automatically leaving the driver to handle that

>> + * by itself. This does not work for PCIeSS which needs the reset lines

>> + * deasserted for the driver to start accessing registers.

>> + *

>> + * We use a PCIeSS HWMOD class specific reset handler to deassert the hardreset

>> + * lines after asserting them.

>> + */

>> +static int dra7xx_pciess_reset(struct omap_hwmod *oh)

>> +{

>> +	int i;

>> +

>> +	for (i = 0; i < oh->rst_lines_cnt; i++) {

>> +		omap_hwmod_assert_hardreset(oh, oh->rst_lines[i].name);

>> +		omap_hwmod_deassert_hardreset(oh, oh->rst_lines[i].name);


Hmm, ignoring return values??

regards
Suman

>> +	}

>> +

>> +	return 0;

>> +}

>> +

>>  static struct omap_hwmod_class dra7xx_pciess_hwmod_class = {

>>  	.name	= "pcie",

>> +	.reset	= dra7xx_pciess_reset,

>>  };

>>  

>>  /* pcie1 */

>> -- 

>> 2.6.3

>>

>>

> 

> 

> - Paul

>
Kishon Vijay Abraham I Feb. 22, 2016, 6:18 a.m. UTC | #2
Sekhar,

On Thursday 18 February 2016 07:51 PM, Sekhar Nori wrote:
> On Friday 12 February 2016 10:50 PM, Suman Anna wrote:

>> Sekhar,

>> Will you be following up with above suggestion since Kishon is gonna be out?

> 

> Alright, noticed this action for me :) Went through the thread, and 

> looks like this is what we want to see?

> 

> Thanks,

> Sekhar

> 

> ---8<---

> From e3ba368f2235e1bf38a22ba8ea4e5c12aaafda19 Mon Sep 17 00:00:00 2001

> Message-Id: <e3ba368f2235e1bf38a22ba8ea4e5c12aaafda19.1455803758.git.nsekhar@ti.com>

> From: Sekhar Nori <nsekhar@ti.com>

> Date: Thu, 18 Feb 2016 16:49:56 +0530

> Subject: [PATCH 1/1] ARM: DRA7: hwmod: Add custom reset handler for PCIeSS

> 

> Add a custom reset handler for DRA7x PCIeSS. This

> handler is required to deassert PCIe hardreset lines

> after they have been asserted.

> 

> This enables the PCIe driver to access registers after

> PCIeSS has been runtime enabled without having to

> deassert hardreset lines itself.

> 

> With this patch applied, used lspci to make sure

> connected PCIe device enumerates on DRA74x and DRA72x

> EVMs.

> 

> Signed-off-by: Sekhar Nori <nsekhar@ti.com>

> ---

> Applies to tag for-v4.6/omap-hwmod-a of Paul W's tree.

> 

>  arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 23 +++++++++++++++++++++++

>  1 file changed, 23 insertions(+)

> 

> diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c

> index b61355e2a771..252b74633e31 100644

> --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c

> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c

> @@ -1526,8 +1526,31 @@ static struct omap_hwmod dra7xx_ocp2scp3_hwmod = {

>   *

>   */

>  

> +/*

> + * As noted in documentation for _reset() in omap_hwmod.c, the stock reset

> + * functionality of OMAP HWMOD layer does not deassert the hardreset lines

> + * associated with an IP automatically leaving the driver to handle that

> + * by itself. This does not work for PCIeSS which needs the reset lines

> + * deasserted for the driver to start accessing registers.

> + *

> + * We use a PCIeSS HWMOD class specific reset handler to deassert the hardreset

> + * lines after asserting them.

> + */

> +static int dra7xx_pciess_reset(struct omap_hwmod *oh)

> +{

> +	int i;

> +

> +	for (i = 0; i < oh->rst_lines_cnt; i++) {

> +		omap_hwmod_assert_hardreset(oh, oh->rst_lines[i].name);

> +		omap_hwmod_deassert_hardreset(oh, oh->rst_lines[i].name);

> +	}

> +

> +	return 0;

> +}

> +

>  static struct omap_hwmod_class dra7xx_pciess_hwmod_class = {

>  	.name	= "pcie",

> +	.reset	= dra7xx_pciess_reset,

>  };


Thanks for the patch.

-Kishon
Kishon Vijay Abraham I Feb. 22, 2016, 9:55 a.m. UTC | #3
Hi Paul,

On Monday 22 February 2016 12:01 PM, Paul Walmsley wrote:
> Kishon,

> 

> On Mon, 22 Feb 2016, Kishon Vijay Abraham I wrote:

> 

>> Sekhar,

>>

>> On Thursday 18 February 2016 07:51 PM, Sekhar Nori wrote:

>>> On Friday 12 February 2016 10:50 PM, Suman Anna wrote:

>>>> Sekhar,

>>>> Will you be following up with above suggestion since Kishon is gonna be out?

>>>

>>> Alright, noticed this action for me :) Went through the thread, and 

>>> looks like this is what we want to see?

>>>

>>> Thanks,

>>> Sekhar

>>>

>>> ---8<---

>>> From e3ba368f2235e1bf38a22ba8ea4e5c12aaafda19 Mon Sep 17 00:00:00 2001

>>> Message-Id: <e3ba368f2235e1bf38a22ba8ea4e5c12aaafda19.1455803758.git.nsekhar@ti.com>

>>> From: Sekhar Nori <nsekhar@ti.com>

>>> Date: Thu, 18 Feb 2016 16:49:56 +0530

>>> Subject: [PATCH 1/1] ARM: DRA7: hwmod: Add custom reset handler for PCIeSS

>>>

>>> Add a custom reset handler for DRA7x PCIeSS. This

>>> handler is required to deassert PCIe hardreset lines

>>> after they have been asserted.

>>>

>>> This enables the PCIe driver to access registers after

>>> PCIeSS has been runtime enabled without having to

>>> deassert hardreset lines itself.

>>>

>>> With this patch applied, used lspci to make sure

>>> connected PCIe device enumerates on DRA74x and DRA72x

>>> EVMs.

>>>

>>> Signed-off-by: Sekhar Nori <nsekhar@ti.com>

>>> ---

>>> Applies to tag for-v4.6/omap-hwmod-a of Paul W's tree.

>>>

>>>  arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 23 +++++++++++++++++++++++

>>>  1 file changed, 23 insertions(+)

>>>

>>> diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c

>>> index b61355e2a771..252b74633e31 100644

>>> --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c

>>> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c

>>> @@ -1526,8 +1526,31 @@ static struct omap_hwmod dra7xx_ocp2scp3_hwmod = {

>>>   *

>>>   */

>>>  

>>> +/*

>>> + * As noted in documentation for _reset() in omap_hwmod.c, the stock reset

>>> + * functionality of OMAP HWMOD layer does not deassert the hardreset lines

>>> + * associated with an IP automatically leaving the driver to handle that

>>> + * by itself. This does not work for PCIeSS which needs the reset lines

>>> + * deasserted for the driver to start accessing registers.

>>> + *

>>> + * We use a PCIeSS HWMOD class specific reset handler to deassert the hardreset

>>> + * lines after asserting them.

>>> + */

>>> +static int dra7xx_pciess_reset(struct omap_hwmod *oh)

>>> +{

>>> +	int i;

>>> +

>>> +	for (i = 0; i < oh->rst_lines_cnt; i++) {

>>> +		omap_hwmod_assert_hardreset(oh, oh->rst_lines[i].name);

>>> +		omap_hwmod_deassert_hardreset(oh, oh->rst_lines[i].name);

>>> +	}

>>> +

>>> +	return 0;

>>> +}

>>> +

>>>  static struct omap_hwmod_class dra7xx_pciess_hwmod_class = {

>>>  	.name	= "pcie",

>>> +	.reset	= dra7xx_pciess_reset,

>>>  };

>>

>> Thanks for the patch.

> 

> Could you please test the bind/unbind functionality just to make sure it 

> works?


The pci-dra7xx driver neither expose the bind/unbind sysfs entry nor can be
built as module.

However I hacked the pci-dra7xx driver to be built as module [and reverted
Commit 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe error
and driver unbind")] and I don't see an abort when the PCI registers are
accessed after rmmod/modprobe cycle (that was the issue that Sekhar's patch
tried to solve). However PCI as such doesn't work after rmmod/modprobe cycle
[1], but this is a different issue most likely in PCIe core and has to debugged.

In summary, there are other issues in PCI across rmmod/modprobe cycle but the
reset of pci-dra7xx happens fine with this patch.

Thanks
Kishon

[1] -> http://pastebin.ubuntu.com/15169387/
Kishon Vijay Abraham I Feb. 23, 2016, 11:57 a.m. UTC | #4
Hi Paul,

On Monday 22 February 2016 03:25 PM, Kishon Vijay Abraham I wrote:
> Hi Paul,

> 

> On Monday 22 February 2016 12:01 PM, Paul Walmsley wrote:

>> Kishon,

>>

>> On Mon, 22 Feb 2016, Kishon Vijay Abraham I wrote:

>>

>>> Sekhar,

>>>

>>> On Thursday 18 February 2016 07:51 PM, Sekhar Nori wrote:

>>>> On Friday 12 February 2016 10:50 PM, Suman Anna wrote:

>>>>> Sekhar,

>>>>> Will you be following up with above suggestion since Kishon is gonna be out?

>>>>

>>>> Alright, noticed this action for me :) Went through the thread, and 

>>>> looks like this is what we want to see?

>>>>

>>>> Thanks,

>>>> Sekhar

>>>>

>>>> ---8<---

>>>> From e3ba368f2235e1bf38a22ba8ea4e5c12aaafda19 Mon Sep 17 00:00:00 2001

>>>> Message-Id: <e3ba368f2235e1bf38a22ba8ea4e5c12aaafda19.1455803758.git.nsekhar@ti.com>

>>>> From: Sekhar Nori <nsekhar@ti.com>

>>>> Date: Thu, 18 Feb 2016 16:49:56 +0530

>>>> Subject: [PATCH 1/1] ARM: DRA7: hwmod: Add custom reset handler for PCIeSS

>>>>

>>>> Add a custom reset handler for DRA7x PCIeSS. This

>>>> handler is required to deassert PCIe hardreset lines

>>>> after they have been asserted.

>>>>

>>>> This enables the PCIe driver to access registers after

>>>> PCIeSS has been runtime enabled without having to

>>>> deassert hardreset lines itself.

>>>>

>>>> With this patch applied, used lspci to make sure

>>>> connected PCIe device enumerates on DRA74x and DRA72x

>>>> EVMs.

>>>>

>>>> Signed-off-by: Sekhar Nori <nsekhar@ti.com>

>>>> ---

>>>> Applies to tag for-v4.6/omap-hwmod-a of Paul W's tree.

>>>>

>>>>  arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 23 +++++++++++++++++++++++

>>>>  1 file changed, 23 insertions(+)

>>>>

>>>> diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c

>>>> index b61355e2a771..252b74633e31 100644

>>>> --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c

>>>> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c

>>>> @@ -1526,8 +1526,31 @@ static struct omap_hwmod dra7xx_ocp2scp3_hwmod = {

>>>>   *

>>>>   */

>>>>  

>>>> +/*

>>>> + * As noted in documentation for _reset() in omap_hwmod.c, the stock reset

>>>> + * functionality of OMAP HWMOD layer does not deassert the hardreset lines

>>>> + * associated with an IP automatically leaving the driver to handle that

>>>> + * by itself. This does not work for PCIeSS which needs the reset lines

>>>> + * deasserted for the driver to start accessing registers.

>>>> + *

>>>> + * We use a PCIeSS HWMOD class specific reset handler to deassert the hardreset

>>>> + * lines after asserting them.

>>>> + */

>>>> +static int dra7xx_pciess_reset(struct omap_hwmod *oh)

>>>> +{

>>>> +	int i;

>>>> +

>>>> +	for (i = 0; i < oh->rst_lines_cnt; i++) {

>>>> +		omap_hwmod_assert_hardreset(oh, oh->rst_lines[i].name);

>>>> +		omap_hwmod_deassert_hardreset(oh, oh->rst_lines[i].name);

>>>> +	}

>>>> +

>>>> +	return 0;

>>>> +}

>>>> +

>>>>  static struct omap_hwmod_class dra7xx_pciess_hwmod_class = {

>>>>  	.name	= "pcie",

>>>> +	.reset	= dra7xx_pciess_reset,

>>>>  };

>>>

>>> Thanks for the patch.

>>

>> Could you please test the bind/unbind functionality just to make sure it 

>> works?

> 

> The pci-dra7xx driver neither expose the bind/unbind sysfs entry nor can be

> built as module.

> 

> However I hacked the pci-dra7xx driver to be built as module [and reverted

> Commit 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe error

> and driver unbind")] and I don't see an abort when the PCI registers are

> accessed after rmmod/modprobe cycle (that was the issue that Sekhar's patch

> tried to solve). However PCI as such doesn't work after rmmod/modprobe cycle

> [1], but this is a different issue most likely in PCIe core and has to debugged.

> 

> In summary, there are other issues in PCI across rmmod/modprobe cycle but the

> reset of pci-dra7xx happens fine with this patch.


Do you expect any other testing from me?

-Kishon

> 

> Thanks

> Kishon

> 

> [1] -> http://pastebin.ubuntu.com/15169387/

> --

> To unsubscribe from this list: send the line "unsubscribe linux-omap" in

> the body of a message to majordomo@vger.kernel.org

> More majordomo info at  http://vger.kernel.org/majordomo-info.html

>
Kishon Vijay Abraham I Feb. 24, 2016, 6:21 a.m. UTC | #5
Hi Paul,

On Tuesday 23 February 2016 11:58 PM, Paul Walmsley wrote:
> Kishon

> 

> On Tue, 23 Feb 2016, Kishon Vijay Abraham I wrote:

> 

>> On Monday 22 February 2016 03:25 PM, Kishon Vijay Abraham I wrote:

>>> On Monday 22 February 2016 12:01 PM, Paul Walmsley wrote:

>>>> On Mon, 22 Feb 2016, Kishon Vijay Abraham I wrote:

>>>>> On Thursday 18 February 2016 07:51 PM, Sekhar Nori wrote:

>>>>>> On Friday 12 February 2016 10:50 PM, Suman Anna wrote:

>>>>>>> Will you be following up with above suggestion since Kishon is gonna be out?

>>>>>>

>>>>>> Alright, noticed this action for me :) Went through the thread, and 

>>>>>> looks like this is what we want to see?

>>>>>>

>>>>>> Thanks,

>>>>>> Sekhar

>>>>>>

>>>>>> ---8<---

>>>>>> From e3ba368f2235e1bf38a22ba8ea4e5c12aaafda19 Mon Sep 17 00:00:00 2001

>>>>>> Message-Id: <e3ba368f2235e1bf38a22ba8ea4e5c12aaafda19.1455803758.git.nsekhar@ti.com>

>>>>>> From: Sekhar Nori <nsekhar@ti.com>

>>>>>> Date: Thu, 18 Feb 2016 16:49:56 +0530

>>>>>> Subject: [PATCH 1/1] ARM: DRA7: hwmod: Add custom reset handler for PCIeSS

>>>>>>

>>>>>> Add a custom reset handler for DRA7x PCIeSS. This

>>>>>> handler is required to deassert PCIe hardreset lines

>>>>>> after they have been asserted.

>>>>>>

>>>>>> This enables the PCIe driver to access registers after

>>>>>> PCIeSS has been runtime enabled without having to

>>>>>> deassert hardreset lines itself.

>>>>>>

>>>>>> With this patch applied, used lspci to make sure

>>>>>> connected PCIe device enumerates on DRA74x and DRA72x

>>>>>> EVMs.

>>>>>>

>>>>>> Signed-off-by: Sekhar Nori <nsekhar@ti.com>

>>>>>> ---

>>>>>> Applies to tag for-v4.6/omap-hwmod-a of Paul W's tree.

>>>>>>

>>>>>>  arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 23 +++++++++++++++++++++++

>>>>>>  1 file changed, 23 insertions(+)

>>>>>>

>>>>>> diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c

>>>>>> index b61355e2a771..252b74633e31 100644

>>>>>> --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c

>>>>>> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c

>>>>>> @@ -1526,8 +1526,31 @@ static struct omap_hwmod dra7xx_ocp2scp3_hwmod = {

>>>>>>   *

>>>>>>   */

>>>>>>  

>>>>>> +/*

>>>>>> + * As noted in documentation for _reset() in omap_hwmod.c, the stock reset

>>>>>> + * functionality of OMAP HWMOD layer does not deassert the hardreset lines

>>>>>> + * associated with an IP automatically leaving the driver to handle that

>>>>>> + * by itself. This does not work for PCIeSS which needs the reset lines

>>>>>> + * deasserted for the driver to start accessing registers.

>>>>>> + *

>>>>>> + * We use a PCIeSS HWMOD class specific reset handler to deassert the hardreset

>>>>>> + * lines after asserting them.

>>>>>> + */

>>>>>> +static int dra7xx_pciess_reset(struct omap_hwmod *oh)

>>>>>> +{

>>>>>> +	int i;

>>>>>> +

>>>>>> +	for (i = 0; i < oh->rst_lines_cnt; i++) {

>>>>>> +		omap_hwmod_assert_hardreset(oh, oh->rst_lines[i].name);

>>>>>> +		omap_hwmod_deassert_hardreset(oh, oh->rst_lines[i].name);

>>>>>> +	}

>>>>>> +

>>>>>> +	return 0;

>>>>>> +}

>>>>>> +

>>>>>>  static struct omap_hwmod_class dra7xx_pciess_hwmod_class = {

>>>>>>  	.name	= "pcie",

>>>>>> +	.reset	= dra7xx_pciess_reset,

>>>>>>  };

>>>>>

>>>>> Thanks for the patch.

>>>>

>>>> Could you please test the bind/unbind functionality just to make sure it 

>>>> works?

>>>

>>> The pci-dra7xx driver neither expose the bind/unbind sysfs entry nor can be

>>> built as module.

>>>

>>> However I hacked the pci-dra7xx driver to be built as module [and reverted

>>> Commit 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe error

>>> and driver unbind")] and I don't see an abort when the PCI registers are

>>> accessed after rmmod/modprobe cycle (that was the issue that Sekhar's patch

>>> tried to solve). However PCI as such doesn't work after rmmod/modprobe cycle

>>> [1], but this is a different issue most likely in PCIe core and has to debugged.

>>>

>>> In summary, there are other issues in PCI across rmmod/modprobe cycle but the

>>> reset of pci-dra7xx happens fine with this patch.

>>

>> Do you expect any other testing from me?

> 

> No I think that's sufficient for the time being, thanks - but, two 

> questions:

> 

> 1. Can I add your Tested-by: ?


sure..
Tested-by: Kishon Vijay Abraham I <kishon@ti.com>


> 

> 2. Are you going to follow up with these PCIe core issues with the PCIe 

> core developers?


yeah, I see efforts have already started to convert the PCI drivers from
built-in to module [1] and issues arising out of that will be debugged.

Thanks
Kishon

[1] -> http://lkml.iu.edu/hypermail/linux/kernel/1602.0/06011.html
> 

> 

> - Paul

>
Kishon Vijay Abraham I March 1, 2016, 11:55 a.m. UTC | #6
Hi,

On Tuesday 01 March 2016 01:55 PM, Paul Walmsley wrote:
> 

> Folks, the following is what I've queued for this.


Thanks Paul.

Bjorn,

With this patch merged, enabling pci-dra7xx won't result in system freeze
anymore. I can send a patch to revert depends on BROKEN.

Thanks
Kishon

> 

> 

> - Paul

> 

> 

> From: Sekhar Nori <nsekhar@ti.com>

> Date: Thu, 18 Feb 2016 16:49:56 +0530

> Subject: [PATCH] ARM: DRA7: hwmod: Add custom reset handler for PCIeSS

> 

> Add a custom reset handler for DRA7x PCIeSS. This

> handler is required to deassert PCIe hardreset lines

> after they have been asserted.

> 

> This enables the PCIe driver to access registers after

> PCIeSS has been runtime enabled without having to

> deassert hardreset lines itself.

> 

> With this patch applied, used lspci to make sure

> connected PCIe device enumerates on DRA74x and DRA72x

> EVMs.

> 

> Signed-off-by: Sekhar Nori <nsekhar@ti.com>

> Reported-by: Richard Cochran <richardcochran@gmail.com>

> Tested-by: Kishon Vijay Abraham I <kishon@ti.com>

> Cc: Suman Anna <s-anna@ti.com>

> Cc: Dave Gerlach <d-gerlach@ti.com>

> Cc: Tony Lindgren <tony@atomide.com>

> Cc: Bjorn Helgaas <bhelgaas@google.com>

> Cc: Russell King <linux@arm.linux.org.uk>

> Signed-off-by: Paul Walmsley <paul@pwsan.com>

> ---

>  arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 23 +++++++++++++++++++++++

>  1 file changed, 23 insertions(+)

> 

> diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c

> index b61355e2a771..252b74633e31 100644

> --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c

> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c

> @@ -1526,8 +1526,31 @@ static struct omap_hwmod dra7xx_ocp2scp3_hwmod = {

>   *

>   */

>  

> +/*

> + * As noted in documentation for _reset() in omap_hwmod.c, the stock reset

> + * functionality of OMAP HWMOD layer does not deassert the hardreset lines

> + * associated with an IP automatically leaving the driver to handle that

> + * by itself. This does not work for PCIeSS which needs the reset lines

> + * deasserted for the driver to start accessing registers.

> + *

> + * We use a PCIeSS HWMOD class specific reset handler to deassert the hardreset

> + * lines after asserting them.

> + */

> +static int dra7xx_pciess_reset(struct omap_hwmod *oh)

> +{

> +	int i;

> +

> +	for (i = 0; i < oh->rst_lines_cnt; i++) {

> +		omap_hwmod_assert_hardreset(oh, oh->rst_lines[i].name);

> +		omap_hwmod_deassert_hardreset(oh, oh->rst_lines[i].name);

> +	}

> +

> +	return 0;

> +}

> +

>  static struct omap_hwmod_class dra7xx_pciess_hwmod_class = {

>  	.name	= "pcie",

> +	.reset	= dra7xx_pciess_reset,

>  };

>  

>  /* pcie1 */

>
Suman Anna March 1, 2016, 4:55 p.m. UTC | #7
On 03/01/2016 05:55 AM, Kishon Vijay Abraham I wrote:
> Hi,

> 

> On Tuesday 01 March 2016 01:55 PM, Paul Walmsley wrote:

>>

>> Folks, the following is what I've queued for this.

> 

> Thanks Paul.

> 

> Bjorn,

> 

> With this patch merged, enabling pci-dra7xx won't result in system freeze

> anymore. I can send a patch to revert depends on BROKEN.


Kishon,
Make sure you send only that after both this patch and the pcie reset
data are in. I see the pcie reset data in Paul's for-4.6 branch.

regards
Suman

[snip]
diff mbox

Patch

diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index b61355e2a771..252b74633e31 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -1526,8 +1526,31 @@  static struct omap_hwmod dra7xx_ocp2scp3_hwmod = {
  *
  */
 
+/*
+ * As noted in documentation for _reset() in omap_hwmod.c, the stock reset
+ * functionality of OMAP HWMOD layer does not deassert the hardreset lines
+ * associated with an IP automatically leaving the driver to handle that
+ * by itself. This does not work for PCIeSS which needs the reset lines
+ * deasserted for the driver to start accessing registers.
+ *
+ * We use a PCIeSS HWMOD class specific reset handler to deassert the hardreset
+ * lines after asserting them.
+ */
+static int dra7xx_pciess_reset(struct omap_hwmod *oh)
+{
+	int i;
+
+	for (i = 0; i < oh->rst_lines_cnt; i++) {
+		omap_hwmod_assert_hardreset(oh, oh->rst_lines[i].name);
+		omap_hwmod_deassert_hardreset(oh, oh->rst_lines[i].name);
+	}
+
+	return 0;
+}
+
 static struct omap_hwmod_class dra7xx_pciess_hwmod_class = {
 	.name	= "pcie",
+	.reset	= dra7xx_pciess_reset,
 };
 
 /* pcie1 */