All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kishon Vijay Abraham I <kishon@ti.com>
To: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Murali Karicheri <m-karicheri2@ti.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>, <linux-pci@vger.kernel.org>,
	Bjorn Helgaas <helgaas@google.com>,
	Trent Piepho <tpiepho@impinj.com>,
	Jingoo Han <jingoohan1@gmail.com>,
	Gustavo Pimentel <gustavo.pimentel@synopsys.com>,
	<faiz_abbas@ti.com>, Joao Pinto <Joao.Pinto@synopsys.com>,
	Vignesh R <vigneshr@ti.com>
Subject: Re: [PATCH 3/3] PCI: designware: Move interrupt acking into the proper callback
Date: Wed, 12 Dec 2018 11:24:20 +0530	[thread overview]
Message-ID: <78e2d1db-fe10-2bc4-4e06-eee07b740130@ti.com> (raw)
In-Reply-To: <20181211123550.GA31209@e107981-ln.cambridge.arm.com>

Hi Lorenzo,

On 11/12/18 6:05 PM, Lorenzo Pieralisi wrote:
> On Fri, Dec 07, 2018 at 03:43:00PM +0530, Kishon Vijay Abraham I wrote:
>> Hi,
>>
>> On 07/12/18 3:15 PM, Marc Zyngier wrote:
>>> On 07/12/2018 08:12, Kishon Vijay Abraham I wrote:
>>>> Hi Marc,
>>>>
>>>> On 04/12/18 7:15 PM, Marc Zyngier wrote:
>>>>> On Tue, 4 Dec 2018 15:50:32 +0530
>>>>> Kishon Vijay Abraham I <kishon@ti.com> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> On 14/11/18 4:27 AM, Marc Zyngier wrote:
>>>>>>> The write to the status register is really an ACK for the HW,
>>>>>>> and should be treated as such by the driver. Let's move it to the
>>>>>>> irq_ack callback, which will prevent people from moving it around
>>>>>>> in order to paper over other bugs.
>>>>>>>
>>>>>>> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>>>>>>> ---
>>>>>>>  drivers/pci/controller/dwc/pcie-designware-host.c | 13 +++++++------
>>>>>>>  1 file changed, 7 insertions(+), 6 deletions(-)
>>>>>>>
>>>>>>> diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c
>>>>>>> index 0a76948ed49e..f06e67c60593 100644
>>>>>>> --- a/drivers/pci/controller/dwc/pcie-designware-host.c
>>>>>>> +++ b/drivers/pci/controller/dwc/pcie-designware-host.c
>>>>>>> @@ -99,9 +99,6 @@ irqreturn_t dw_handle_msi_irq(struct pcie_port *pp)
>>>>>>>  					       (i * MAX_MSI_IRQS_PER_CTRL) +
>>>>>>>  					       pos);
>>>>>>>  			generic_handle_irq(irq);
>>>>>>> -			dw_pcie_wr_own_conf(pp, PCIE_MSI_INTR0_STATUS +
>>>>>>> -						(i * MSI_REG_CTRL_BLOCK_SIZE),
>>>>>>> -					    4, 1 << pos);
>>>>>>>  			pos++;
>>>>>>>  		}
>>>>>>>  	}
>>>>>>> @@ -200,14 +197,18 @@ static void dw_pci_bottom_unmask(struct irq_data *data)
>>>>>>>  
>>>>>>>  static void dw_pci_bottom_ack(struct irq_data *d)
>>>>>>>  {
>>>>>>> -	struct msi_desc *msi = irq_data_get_msi_desc(d);
>>>>>>> -	struct pcie_port *pp;
>>>>>>> +	struct pcie_port *pp  = irq_data_get_irq_chip_data(d);
>>>>>>> +	unsigned int res, bit, ctrl;
>>>>>>>  	unsigned long flags;
>>>>>>>  
>>>>>>> -	pp = msi_desc_to_pci_sysdata(msi);
>>>>>>> +	ctrl = d->hwirq / MAX_MSI_IRQS_PER_CTRL;
>>>>>>> +	res = ctrl * MSI_REG_CTRL_BLOCK_SIZE;
>>>>>>> +	bit = d->hwirq % MAX_MSI_IRQS_PER_CTRL;
>>>>>>>  
>>>>>>>  	raw_spin_lock_irqsave(&pp->lock, flags);
>>>>>>>  
>>>>>>> +	dw_pcie_wr_own_conf(pp, PCIE_MSI_INTR0_STATUS + res, 4, 1 << bit);  
>>>>>>
>>>>>> This register should be written only if msi_irq_ack callback is not populated
>>>>>> similar to other dw_pci_bottom_*() functions.
>>>>>
>>>>> Why? This was so far unconditionally written, and my understanding is
>>>>> that without this write, no further MSI can be delivered.
>>>>
>>>> Not all platforms invoke dw_handle_msi_irq() for handling MSI irq.
>>>>
>>>> Platforms that doesn't use the MSI functionality of Designware makes use of the
>>>> various callbacks like msi_irq_ack, msi_host_init etc., Keystone has MSI
>>>> controller in the Keystone wrapper, AM654 uses GIC ITS etc.,
>>>>
>>>> The platforms that doesn't use MSI functionality of Designware doesn't have to
>>>> write to Designware's MSI configuration registers.
>>>
>>> Let's be clear: a platform that doesn't use the DW MSI functionality
>>> should never get anywhere this code. If they do, then that's a terrible
>>> bug, and it should be fixed by making the TI stuff standalone instead of
>>> calling into the internals.
>>
>> That makes sense to me. We can start by removing msi_set_irq, msi_clear_irq and
>> msi_irq_ack callbacks from dw_pcie_host_ops.
>>
>> This functionality can be added directly in keystone driver.
>>>
>>> Frankly, this whole thing should be marked as BROKEN until it is sorted
>>> out for good.
>>
>> Maybe remove those callbacks and make only Keystone broken?
> 
> Hi Kishon, Murali,
> 
> Is it possible to rework keystone as discussed on this thread on top of
> my pci/dwc-msi branch please ?

yeah, I'll work on that.

Thanks
Kishon

  reply	other threads:[~2018-12-12  5:54 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-13 22:57 [PATCH 0/3] PCI: designware: Fixing MSI handling flow Marc Zyngier
2018-11-13 22:57 ` [PATCH 1/3] PCI: designware: Use interrupt masking instead of disabling Marc Zyngier
2018-12-03 18:02   ` [1/3] " Niklas Cassel
2018-12-04  9:41   ` [PATCH 1/3] " Gustavo Pimentel
2018-11-13 22:57 ` [PATCH 2/3] PCI: designware: Take lock when ACKing an interrupt Marc Zyngier
2018-11-14 19:08   ` Trent Piepho
2018-12-03 18:02   ` [2/3] " Niklas Cassel
2018-12-04  9:41   ` [PATCH 2/3] " Gustavo Pimentel
2018-11-13 22:57 ` [PATCH 3/3] PCI: designware: Move interrupt acking into the proper callback Marc Zyngier
2018-11-14 19:01   ` Trent Piepho
2018-12-03 18:02   ` [3/3] " Niklas Cassel
2018-12-04  9:41   ` [PATCH 3/3] " Gustavo Pimentel
2018-12-04 10:20   ` Kishon Vijay Abraham I
2018-12-04 13:45     ` Marc Zyngier
2018-12-07  8:12       ` Kishon Vijay Abraham I
2018-12-07  9:45         ` Marc Zyngier
2018-12-07 10:13           ` Kishon Vijay Abraham I
2018-12-11 12:35             ` Lorenzo Pieralisi
2018-12-12  5:54               ` Kishon Vijay Abraham I [this message]
2018-11-13 23:16 ` [PATCH 0/3] PCI: designware: Fixing MSI handling flow Gustavo Pimentel
2018-11-14  9:54   ` Marc Zyngier
2018-11-14 19:19     ` Trent Piepho
2018-11-14 22:01       ` Marc Zyngier
2018-11-14 22:25         ` Trent Piepho
2018-11-14 22:44           ` Marc Zyngier
2018-11-14 23:23             ` Trent Piepho
2018-11-19 20:37         ` Trent Piepho
2018-11-22 12:03     ` Gustavo Pimentel
2018-11-22 16:07       ` Gustavo Pimentel
2018-11-22 16:26       ` Lorenzo Pieralisi
2018-11-22 16:38         ` Marc Zyngier
2018-11-22 17:40           ` Gustavo Pimentel
2018-11-26 16:06           ` Trent Piepho
2018-11-27  7:51             ` Marc Zyngier
2018-11-27 17:23               ` Trent Piepho
2018-11-22 17:49         ` Gustavo Pimentel
2018-11-26 15:52       ` Trent Piepho
2018-11-27  7:50         ` Marc Zyngier
2018-11-27 18:12           ` Trent Piepho
2018-12-07 16:16           ` Gustavo Pimentel
2018-11-14 18:28 ` Trent Piepho
2018-11-14 22:07   ` Marc Zyngier
2018-11-14 22:50     ` Trent Piepho
2018-11-15 15:22   ` Gustavo Pimentel
2018-11-15 18:37     ` Trent Piepho
2018-11-15 19:29       ` Marc Zyngier
2018-11-19 20:14         ` Trent Piepho
2018-11-21 17:24 ` Stanimir Varbanov
2018-12-01 23:50   ` Niklas Cassel
2018-12-02 11:28     ` Stanimir Varbanov
2018-12-03 10:42     ` Lorenzo Pieralisi
2018-12-03 13:09       ` Niklas Cassel
2018-12-03 17:42         ` Lorenzo Pieralisi
2018-12-03 20:31           ` Trent Piepho
2018-12-10 16:17 ` Lorenzo Pieralisi
2018-12-10 16:30   ` Marc Zyngier
2018-12-10 18:15   ` Trent Piepho
2018-12-10 18:31     ` Marc Zyngier
2018-12-10 20:34       ` Trent Piepho
2018-12-12  9:10         ` Gustavo Pimentel
2018-12-12  8:55   ` Gustavo Pimentel
2018-12-11 11:43 ` Lorenzo Pieralisi

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=78e2d1db-fe10-2bc4-4e06-eee07b740130@ti.com \
    --to=kishon@ti.com \
    --cc=Joao.Pinto@synopsys.com \
    --cc=faiz_abbas@ti.com \
    --cc=gustavo.pimentel@synopsys.com \
    --cc=helgaas@google.com \
    --cc=jingoohan1@gmail.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=m-karicheri2@ti.com \
    --cc=marc.zyngier@arm.com \
    --cc=tpiepho@impinj.com \
    --cc=vigneshr@ti.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 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.