Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1319226
| From | Suman Anna <s-anna@ti.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH v3 3/3] pci: dra7xx: use pdata callbacks to perform reset |
| Date | 2016-01-27 19:20 +0100 |
| Message-ID | <qVCRe-7CM-67@gated-at.bofh.it> (permalink) |
| References | <qQQUO-8fS-13@gated-at.bofh.it> <qQQUP-8fS-37@gated-at.bofh.it> <qVCet-72J-1@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
Hi Tony, On 01/27/2016 11:31 AM, Tony Lindgren wrote: > * Kishon Vijay Abraham I <kishon@ti.com> [160114 06:12]: >> Use assert/deassert callbacks populated in the platform data to >> to perform reset of PCIe. >> >> Use these callbacks until a reset controller driver is >> is available in the kernel to reset PCIe. > ... > >> --- a/drivers/pci/host/pci-dra7xx.c >> +++ b/drivers/pci/host/pci-dra7xx.c >> @@ -347,6 +404,10 @@ static int __init dra7xx_pcie_probe(struct platform_device *pdev) >> enum of_gpio_flags flags; >> unsigned long gpio_flags; >> >> + ret = dra7xx_pcie_reset(pdev); >> + if (ret) >> + return ret; >> + >> dra7xx = devm_kzalloc(dev, sizeof(*dra7xx), GFP_KERNEL); >> if (!dra7xx) >> return -ENOMEM; > > With the hwmod data properly configured the reset already happens > for the device by the bus driver, the hwmod code in this case? > >> @@ -457,6 +518,7 @@ static int __exit dra7xx_pcie_remove(struct platform_device *pdev) >> struct pcie_port *pp = &dra7xx->pp; >> struct device *dev = &pdev->dev; >> int count = dra7xx->phy_count; >> + int ret; >> >> if (pp->irq_domain) >> irq_domain_remove(pp->irq_domain); >> @@ -467,6 +529,10 @@ static int __exit dra7xx_pcie_remove(struct platform_device *pdev) >> phy_exit(dra7xx->phy[count]); >> } >> >> + ret = dra7xx_pcie_assert_reset(pdev); >> + if (ret < 0) >> + return ret; >> + >> return 0; >> } > > Why do you need another reset here? Can't you just implement PM runtime > in the driver and do the usual pm_runtime_put_sync followed by > pm_runtime_disable? The omap_hwmod_enable/disable code does not deal with hardresets (PRCM reset lines) and so the pm_runtime_get_sync/put_sync only end up dealing with clocks, and we need to invoke the reset functions separately. Modules with softresets in SYSCONFIG are ok, as they are dealt with properly. > Basically I'm wondering how come we need these platform data callbacks > at all. The hardresets are controlled through the omap_device_assert(deassert)_hardreset functions, and since these are limited to mach-omap2, we are invoking them through platform data callbacks. regards Suman
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: [PATCH v3 3/3] pci: dra7xx: use pdata callbacks to perform reset Tony Lindgren <tony@atomide.com> - 2016-01-27 18:40 +0100
Re: [PATCH v3 3/3] pci: dra7xx: use pdata callbacks to perform reset Suman Anna <s-anna@ti.com> - 2016-01-27 19:20 +0100
Re: [PATCH v3 3/3] pci: dra7xx: use pdata callbacks to perform reset Tony Lindgren <tony@atomide.com> - 2016-01-27 20:00 +0100
csiph-web