devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@gmail.com>
To: Manikanta Maddireddy <mmaddireddy@nvidia.com>
Cc: bhelgaas@google.com, lorenzo.pieralisi@arm.com, cyndis@kapsi.fi,
	jonathanh@nvidia.com, robh+dt@kernel.org, frowand.list@gmail.com,
	rjw@rjwysocki.net, tglx@linutronix.de, vidyas@nvidia.com,
	kthota@nvidia.com, linux-tegra@vger.kernel.org,
	devicetree@vger.kernel.org, linux-pci@vger.kernel.org,
	linux-pm@vger.kernel.org
Subject: Re: [PATCH V6 6/7] PCI: tegra: Broadcast PME_Turn_Off message before link goes to L2
Date: Mon, 29 Jan 2018 16:18:42 +0100	[thread overview]
Message-ID: <20180129151842.GA26264@ulmo> (raw)
In-Reply-To: <8adc2a7d-009b-168c-07f6-b50526ce0605@nvidia.com>

[-- Attachment #1: Type: text/plain, Size: 5244 bytes --]

On Mon, Jan 29, 2018 at 10:11:42AM +0530, Manikanta Maddireddy wrote:
> 
> 
> On 25-Jan-18 8:06 PM, Thierry Reding wrote:
> > On Thu, Jan 11, 2018 at 11:38:07AM +0530, Manikanta Maddireddy wrote:
> >> Per PCIe r3.0, sec 5.3.3.2.1, PCIe root port shoould broadcast PME_Turn_Off
> >> message before PCIe link goes to L2. PME_Turn_Off broadcast mechanism is
> >> implemented in AFI module. Each Tegra PCIe root port has its own
> >> PME_Turn_Off and PME_TO_Ack bitmap in AFI_PME register, program this
> >> register to broadcast PME_Turn_Off message.
> >>
> >> Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
> >> ---
> >> V2:
> >> * no change in this patch
> >> V3:
> >> * add PME bitmap in soc data instead of using compatible string
> >> * replace while loop with readl_poll_timeout() for polling
> >> * commit log correction
> >> V4:
> >> * no change in this patch
> >> V5:
> >> * Rebased on linux-next
> >> V6:
> >> * no change in this patch
> >>
> >>  drivers/pci/host/pci-tegra.c | 45 ++++++++++++++++++++++++++++++++++++++++++++
> >>  1 file changed, 45 insertions(+)
> >>
> >> diff --git a/drivers/pci/host/pci-tegra.c b/drivers/pci/host/pci-tegra.c
> >> index 981f126b14d6..cc33fc0fb300 100644
> >> --- a/drivers/pci/host/pci-tegra.c
> >> +++ b/drivers/pci/host/pci-tegra.c
> >> @@ -31,6 +31,7 @@
> >>  #include <linux/delay.h>
> >>  #include <linux/export.h>
> >>  #include <linux/interrupt.h>
> >> +#include <linux/iopoll.h>
> >>  #include <linux/irq.h>
> >>  #include <linux/irqdomain.h>
> >>  #include <linux/kernel.h>
> >> @@ -153,6 +154,8 @@
> >>  #define  AFI_INTR_EN_FPCI_TIMEOUT	(1 << 7)
> >>  #define  AFI_INTR_EN_PRSNT_SENSE	(1 << 8)
> >>  
> >> +#define AFI_PCIE_PME		0xf0
> >> +
> >>  #define AFI_PCIE_CONFIG					0x0f8
> >>  #define  AFI_PCIE_CONFIG_PCIE_DISABLE(x)		(1 << ((x) + 1))
> >>  #define  AFI_PCIE_CONFIG_PCIE_DISABLE_ALL		0xe
> >> @@ -233,6 +236,8 @@
> >>  #define PADS_REFCLK_CFG_PREDI_SHIFT		8  /* 11:8 */
> >>  #define PADS_REFCLK_CFG_DRVI_SHIFT		12 /* 15:12 */
> >>  
> >> +#define PME_ACK_TIMEOUT 10000
> >> +
> >>  struct tegra_msi {
> >>  	struct msi_controller chip;
> >>  	DECLARE_BITMAP(used, INT_PCI_MSI_NR);
> >> @@ -251,6 +256,8 @@ struct tegra_pcie_soc {
> >>  	u32 tx_ref_sel;
> >>  	u32 pads_refclk_cfg0;
> >>  	u32 pads_refclk_cfg1;
> >> +	u8 pme_turnoff_bit[3];
> >> +	u8 pme_ack_bit[3];
> > 
> > This seems suboptimal to me. Perhaps a better way would be:
> > 
> > 	struct tegra_pcie_port_soc {
> > 		struct {
> > 			u8 turnoff_bit;
> > 			u8 ack_bit;
> > 		} pme;
> > 	};
> > 
> > And since we already have num_ports which defines exactly how many ports
> > we have:
> > 
> > 	struct tegra_pcie_soc {
> > 		unsigned int num_ports;
> > 		const struct tegra_pcie_port_soc *ports;
> > 		...
> > 	};
> > 
> > I suspect that as you're adding more features we may need more of this
> > data.
> > 
> > But I'm fine to keep it like this. We can always switch to something
> > different if the above becomes too much cluttered.
> > 
> I agree it is sub optimal. I moved pme bitmap values to soc data because
> tegra30 and tegra186 have different bitmap values. To differentiate this
> I allocated static memory in tegra_pcie_soc. I am a bit hesitant do dynamic
> allocation based on num_ports because I need to use compatible string
> to distinguish between tegra30 & tegra186 in runtime. I believe it is OK
> to have trade off 16 bits to avoid these compatible check?

Sorry if I was unclear. I didn't suggest that you'd dynamically allocate
memory, instead you'd hook it up like so:

	static const struct tegra_pcie_port_soc tegra186_pcie_ports[] = {
		{ .turnoff_bit =  0, .ack_bit =  5 },
		{ .turnoff_bit =  8, .ack_bit = 10 },
		{ .turnoff_bit = 12, .ack_bit = 14 },
	};

And then in the existing tegra186_pcie, you'd set this:

	static const struct tegra_pcie_soc tegra186_pcie = {
		.num_ports = 3,
		.ports = tegra186_pcie_ports,
		...
	};

And similar for the others. I realize that this is somewhat more verbose
than your original, but I think it's more readable.

It also allows you to reuse data, such as:

	static const struct tegra_pcie_port_soc tegra20_pcie_ports[] = {
		{ .turnoff_bit = 0, .ack_bit =  5 },
		{ .turnoff_bit = 8, .ack_bit = 10 },
	};

	...

	static const struct tegra_pcie_soc tegra20_pcie = {
		.num_ports = 2,
		.ports = tegra20_pcie_ports,
		...
	};

	...

	static const struct tegra_pcie_soc tegra124_pcie = {
		.num_ports = 2,
		.ports = tegra20_pcie_ports,
		...
	};

	static const struct tegra_pcie_soc tegra210_pcie = {
		.num_ports = 2,
		.ports = tegra20_pcie_ports,
		...
	};

Of course the sharing only works as long as the port definitions don't
contain data that's different between the chips.

You could even go and derive the .num_ports as ARRAY_SIZE() of the ports
definition.

So the above does not dynamically allocate memory, it is just a more
explicit way of specifying the data. It puts the data closer together,
and thereby makes it easier to read, in my opinion.

But as I said, feel free to leave this as-is. We can easily rework this
later on or if necessary.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2018-01-29 15:18 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-11  6:08 [PATCH V6 0/7] Add loadable kernel module and power management support Manikanta Maddireddy
     [not found] ` <1515650888-9459-1-git-send-email-mmaddireddy-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2018-01-11  6:08   ` [PATCH V6 1/7] of: Export of_pci_range_to_resource() Manikanta Maddireddy
2018-01-11  6:08   ` [PATCH V6 3/7] PCI: tegra: Remove PCI_REASSIGN_ALL_BUS flag for Tegra PCIe Manikanta Maddireddy
2018-01-11  6:08 ` [PATCH V6 2/7] PCI: tegra: Use bus->sysdata to store and get host private data Manikanta Maddireddy
2018-01-11  6:08 ` [PATCH V6 4/7] PCI: tegra: Free resources on probe failure Manikanta Maddireddy
     [not found]   ` <1515650888-9459-5-git-send-email-mmaddireddy-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2018-01-25 14:25     ` Thierry Reding
2018-01-11  6:08 ` [PATCH V6 5/7] PCI: tegra: Add loadable kernel module support Manikanta Maddireddy
     [not found]   ` <1515650888-9459-6-git-send-email-mmaddireddy-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2018-01-25 14:27     ` Thierry Reding
2018-01-11  6:08 ` [PATCH V6 6/7] PCI: tegra: Broadcast PME_Turn_Off message before link goes to L2 Manikanta Maddireddy
2018-01-25 14:36   ` Thierry Reding
2018-01-29  4:41     ` Manikanta Maddireddy
2018-01-29 15:18       ` Thierry Reding [this message]
2018-01-11  6:08 ` [PATCH V6 7/7] PCI: tegra: Add power management support Manikanta Maddireddy
2018-01-25 14:48   ` Thierry Reding
2018-01-29  4:46     ` Manikanta Maddireddy

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=20180129151842.GA26264@ulmo \
    --to=thierry.reding@gmail.com \
    --cc=bhelgaas@google.com \
    --cc=cyndis@kapsi.fi \
    --cc=devicetree@vger.kernel.org \
    --cc=frowand.list@gmail.com \
    --cc=jonathanh@nvidia.com \
    --cc=kthota@nvidia.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=mmaddireddy@nvidia.com \
    --cc=rjw@rjwysocki.net \
    --cc=robh+dt@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=vidyas@nvidia.com \
    /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 NNTP newsgroup(s).