On 20/04/17 09:20, Mason wrote:
> On 19/04/2017 13:19, Mason wrote:
>
>> My biggest problem is that tango_unmask() is never called.
>
> FTR, the missing incantation was:
> Explicitly calling tango_{mask/unmask/ack} from the corresponding
> msi_{mask/unmask/ack}
Using irq_chip_mask_parent and co
On 19/04/2017 13:19, Mason wrote:
> My biggest problem is that tango_unmask() is never called.
FTR, the missing incantation was:
Explicitly calling tango_{mask/unmask/ack} from the corresponding
msi_{mask/unmask/ack}
Marc, I have one nagging doubt, wrt splitting MSI line selection
and MSI enabl
On 12/04/2017 11:59, Marc Zyngier wrote:
> And that's *wrong*. I've repeatedly said that you only need to deal with
> *your* irqchip. End of story. Nowhere else. Please leave the MSI irqchip
> alone, it is very unlikely that you have to provide anything at all to it.
Hello Marc,
I am hoping you
On 12/04/17 10:50, Mason wrote:
> On 12/04/2017 10:08, Marc Zyngier wrote:
>
>> On 11/04/17 18:52, Mason wrote:
>>
>>> so data->irq is the virq (30, 34, 35, 36)
>>> and data->hwirq is the domain hwirq (0, 524288, 524289, 524290)
>>>
>>> Is there a way to map hwirq 524288 to MSI 0, hwirq 524289 to
On 12/04/2017 10:08, Marc Zyngier wrote:
> On 11/04/17 18:52, Mason wrote:
>
>> so data->irq is the virq (30, 34, 35, 36)
>> and data->hwirq is the domain hwirq (0, 524288, 524289, 524290)
>>
>> Is there a way to map hwirq 524288 to MSI 0, hwirq 524289 to MSI 1, etc?
>
> Why would you need to do
On 11/04/17 18:52, Mason wrote:
> On 11/04/2017 18:43, Marc Zyngier wrote:
>
>> On 11/04/17 17:26, Mason wrote:
>>
>>> Is there a function to map virq to the hwirq in any domain?
>>
>> Be more precise. If you want the hwirq associated with the view of a
>> virq in a given domain, that's the hwirq
On 11/04/2017 18:43, Marc Zyngier wrote:
> On 11/04/17 17:26, Mason wrote:
>
>> Is there a function to map virq to the hwirq in any domain?
>
> Be more precise. If you want the hwirq associated with the view of a
> virq in a given domain, that's the hwirq field in the corresponding
> irq_data str
On 11/04/17 17:26, Mason wrote:
> On 11/04/2017 17:49, Marc Zyngier wrote:
>> On 11/04/17 16:13, Mason wrote:
>>> On 27/03/2017 19:09, Marc Zyngier wrote:
>>>
Here's what your system looks like:
PCI-EP ---> MSI Controller --> INTC
MSIIRQ
On 11/04/2017 17:49, Marc Zyngier wrote:
> On 11/04/17 16:13, Mason wrote:
>> On 27/03/2017 19:09, Marc Zyngier wrote:
>>
>>> Here's what your system looks like:
>>>
>>> PCI-EP ---> MSI Controller --> INTC
>>> MSIIRQ
>>>
>>> A PCI MSI is always edge. No ifs, no
On 11/04/17 16:13, Mason wrote:
> On 27/03/2017 19:09, Marc Zyngier wrote:
>
>> Here's what your system looks like:
>>
>> PCI-EP ---> MSI Controller --> INTC
>> MSIIRQ
>>
>> A PCI MSI is always edge. No ifs, no buts. That's what it is, and nothing
>> else. Now,
On 27/03/2017 19:09, Marc Zyngier wrote:
> Here's what your system looks like:
>
> PCI-EP ---> MSI Controller --> INTC
> MSIIRQ
>
> A PCI MSI is always edge. No ifs, no buts. That's what it is, and nothing
> else. Now, your MSI controller signals its output u
On 23/03/2017 14:05, Mason wrote:
> +/*
> + * This should probably be module_platform_driver ?
> + */
> +builtin_platform_driver(tango_pcie_driver);
For the sake of completeness,
ERROR: "pci_ecam_map_bus" [drivers/pci/host/pcie-tango.ko] undefined!
ERROR: "pci_host_common_probe" [drivers/pci/hos
On 23/03/2017 14:05, Mason wrote:
> I think this version is ready for review.
> It has all the required bits and pieces.
> I still have a few questions, embedded as comments in the code.
Superseded by [PATCH v3 0/2] Tango PCIe controller support
The v0.2 series remains relevant for one aspect: a
On 27/03/17 23:04, Mason wrote:
> On 27/03/2017 23:07, Marc Zyngier wrote:
>
>> On Mon, Mar 27 2017 at 08:44:08 PM, Mason wrote:
>>
>>> On 27/03/2017 19:09, Marc Zyngier wrote:
>>>
On 27/03/17 16:53, Mason wrote:
> I have one remaining issue with bitmaps.
>
> My HW regs are 3
On 27/03/2017 23:07, Marc Zyngier wrote:
> On Mon, Mar 27 2017 at 08:44:08 PM, Mason wrote:
>
>> On 27/03/2017 19:09, Marc Zyngier wrote:
>>
>>> On 27/03/17 16:53, Mason wrote:
>>>
I have one remaining issue with bitmaps.
My HW regs are 32b. How do I grab e.g. bits 96-127?
All
On Mon, Mar 27 2017 at 08:44:08 PM, Mason wrote:
> On 27/03/2017 19:09, Marc Zyngier wrote:
>
>> On 27/03/17 16:53, Mason wrote:
>>
>>> I have one remaining issue with bitmaps.
>>>
>>> My HW regs are 32b. How do I grab e.g. bits 96-127?
>>> All I can think of is
>>> u32 val = ((u32 *)bitmap)[3]
On 27/03/2017 19:09, Marc Zyngier wrote:
> On 27/03/17 16:53, Mason wrote:
>
>> I have one remaining issue with bitmaps.
>>
>> My HW regs are 32b. How do I grab e.g. bits 96-127?
>> All I can think of is
>> u32 val = ((u32 *)bitmap)[3];
>>
>> Is this acceptable?
>
> No.
>
>> mrutland mention
On 27/03/17 16:53, Mason wrote:
> On 24/03/2017 19:47, Marc Zyngier wrote:
>
>> On 23/03/17 17:03, Mason wrote:
>>
>>> On 23/03/2017 15:22, Marc Zyngier wrote:
>>>
On 23/03/17 13:05, Mason wrote:
> + writel_relaxed(status, pcie->msi_status); /* clear IRQs */
Why isn't this
On 24/03/2017 19:47, Marc Zyngier wrote:
> On 23/03/17 17:03, Mason wrote:
>
>> On 23/03/2017 15:22, Marc Zyngier wrote:
>>
>>> On 23/03/17 13:05, Mason wrote:
>>>
+ writel_relaxed(status, pcie->msi_status); /* clear IRQs */
>>>
>>> Why isn't this your irq_ack method instead of open-coding i
On 27/03/2017 16:46, Thomas Gleixner wrote:
> On Mon, 27 Mar 2017, Mason wrote:
>
>> On 24/03/2017 19:22, Marc Zyngier wrote:
>>
>>> You cannot directly use a pointer to a u32 in any of the bitmap
>>> operations. You need to copy the value to an unsigned long, and
>>> apply the bitmap op on that.
On Mon, 27 Mar 2017, Mason wrote:
> On 24/03/2017 19:22, Marc Zyngier wrote:
>
> > You cannot directly use a pointer to a u32 in any of the bitmap
> > operations. You need to copy the value to an unsigned long, and
> > apply the bitmap op on that.
>
> On my platform, find_first_zero_bit() resolve
On 24/03/2017 19:22, Marc Zyngier wrote:
> You cannot directly use a pointer to a u32 in any of the bitmap
> operations. You need to copy the value to an unsigned long, and
> apply the bitmap op on that.
On my platform, find_first_zero_bit() resolves to
int _find_first_zero_bit_le(const void *
On 23/03/17 17:03, Mason wrote:
> On 23/03/2017 15:22, Marc Zyngier wrote:
>
>> On 23/03/17 13:05, Mason wrote:
>>
>>> +#define MSI_COUNT 32
>>
>> Is this something that is hardcoded? Unlikely to ever change?
>
> The host bridge actually supports 256 MSIs.
>
> IIUC, what you suggested on IRC is
On 23/03/17 23:40, Mason wrote:
> On 23/03/2017 18:03, Mason wrote:
>
>> The host bridge actually supports 256 MSIs.
>>
>> IIUC, what you suggested on IRC is that I support 256 in the driver,
>> and only read the status for *enabled* MSIs.
>>
>> Pseudo-code:
>>
>> for every 32-bit blob in the enab
On 23/03/2017 18:03, Mason wrote:
> The host bridge actually supports 256 MSIs.
>
> IIUC, what you suggested on IRC is that I support 256 in the driver,
> and only read the status for *enabled* MSIs.
>
> Pseudo-code:
>
> for every 32-bit blob in the enabled bitmap
> if the value is non-zero
>
On 23/03/2017 15:22, Marc Zyngier wrote:
> On 23/03/17 13:05, Mason wrote:
>
>> +#define MSI_COUNT 32
>
> Is this something that is hardcoded? Unlikely to ever change?
The host bridge actually supports 256 MSIs.
IIUC, what you suggested on IRC is that I support 256 in the driver,
and only read
On 23/03/17 13:05, Mason wrote:
> I think this version is ready for review.
> It has all the required bits and pieces.
> I still have a few questions, embedded as comments in the code.
> (Missing are ancillary changes to Kconfig, Makefile)
May I suggest that if you think that a patch is ready for
I think this version is ready for review.
It has all the required bits and pieces.
I still have a few questions, embedded as comments in the code.
(Missing are ancillary changes to Kconfig, Makefile)
---
drivers/pci/host/pcie-tango.c | 350 ++
1 file changed
28 matches
Mail list logo