On 2020-11-27 12:45, John Garry wrote:
On 27/11/2020 09:57, Marc Zyngier wrote:
If I understand the code correctly, MSI_ALLOC_FLAGS_SHARED_DEVICE is
supposed to be set in info->flags in platform_msi_set_desc(), but
this
is called per-msi after its_msi_prepare(), so we don't the flags set
at th
On 27/11/2020 09:57, Marc Zyngier wrote:
If I understand the code correctly, MSI_ALLOC_FLAGS_SHARED_DEVICE is
supposed to be set in info->flags in platform_msi_set_desc(), but this
is called per-msi after its_msi_prepare(), so we don't the flags set
at the right time. That's how it looks to me...
On 2020-11-26 16:52, John Garry wrote:
Hi Marc,
https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/log/?h=irq/hacks
ok, I'll have a look
I tried that and it doesn't look to work.
I find that for the its_msi_prepare() call, its_dev->shared does not
get set, as MSI_ALLOC
Hi Marc,
https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/log/?h=irq/hacks
ok, I'll have a look
I tried that and it doesn't look to work.
I find that for the its_msi_prepare() call, its_dev->shared does not get
set, as MSI_ALLOC_FLAGS_SHARED_DEVICE is not set in inf
Hi Marc,
I did:
https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/log/?h=irq/hacks
ok, I'll have a look
You still should be able to enable my favorite
CONFIG_DEBUG_TEST_DRIVER_REMOVE=y, while the distro still boot. But
I'll just test if you want.
Ah! Let me try that
Hi John,
On 2020-11-26 10:47, John Garry wrote:
Hi Marc,
Right, I did consider this.
FWIW, I've pushed my hack branch[1]
Did you miss that reference?
I did:
https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/log/?h=irq/hacks
out with a couple of patches
for you to
Hi Marc,
Right, I did consider this.
FWIW, I've pushed my hack branch[1]
Did you miss that reference?
out with a couple of patches
for you to try (the top 3 patches). They allow platform-MSI domains
created by devices (mbigen, ICU) to be advertised as shared between
devices, so that the lo
On 2020-11-24 17:38, John Garry wrote:
Hi Marc,
So initially in the msi_prepare method we setup the its dev - this is
from the mbigen probe. Then when all the irqs are unmapped later for
end device driver removal, we release this its device in
its_irq_domain_free(). But I don't see anything to
Hi Marc,
So initially in the msi_prepare method we setup the its dev - this is
from the mbigen probe. Then when all the irqs are unmapped later for
end device driver removal, we release this its device in
its_irq_domain_free(). But I don't see anything to set it up again. Is
it improper to have
On 2020-11-23 15:45, John Garry wrote:
Hi John,
But it looks like there is more to it than that, which I'm worried is
far from non-trivial. For example, just calling irq_dispose_mapping()
for removal and then plaform_get_irq()->acpi_get_irq() second time
fails as it looks like more tidy-up is n
Hi Marc,
So is there a reason for which irq dispose mapping is not a
requirement for drivers when finished with the irq? because of shared
interrupts?
For a bunch of reasons: IRQ number used to be created 1:1 with their
physical counterpart, so there wasn't a need to "get rid" of the
associate
Hi John,
On 2020-11-23 12:54, John Garry wrote:
Hi Marc,
Right, but if the driver is removed then the interrupts should be
deallocated, right?
When removing the driver we just call free_irq(), which removes the
handler and disables the interrupt.
But about the irq_desc, this is created whe
Hi Marc,
Right, but if the driver is removed then the interrupts should be
deallocated, right?
When removing the driver we just call free_irq(), which removes the
handler and disables the interrupt.
But about the irq_desc, this is created when the mapping is created in
irq_create_fwspec_mapp
On Fri, 20 Nov 2020 11:52:09 +,
John Garry wrote:
>
> Hi Thomas,
>
> >> Just mentioning a couple of things here, which could be a clue to what
> >> is going on:
> >> - the device is behind mbigen secondary irq controller
> >> - the flow in the LLDD is to allocate all 128 interrupts during pr
Hi Thomas,
Just mentioning a couple of things here, which could be a clue to what
is going on:
- the device is behind mbigen secondary irq controller
- the flow in the LLDD is to allocate all 128 interrupts during probe,
but we only register handlers for a subset with device managed API
Right,
On Thu, Nov 19 2020 at 19:56, John Garry wrote:
3) Interrupt has already been switched to managed. Double init is not
really a good sign either.
>>> I just tested that and case 3) would be a problem. I don't see us
>>> clearing the managed flag when free'ing the interrupt. So wit
Hi Thomas,
3) Interrupt has already been switched to managed. Double init is not
really a good sign either.
I just tested that and case 3) would be a problem. I don't see us
clearing the managed flag when free'ing the interrupt. So with
CONFIG_DEBUG_TEST_DRIVER_REMOVE=y, we attempt thi
On Thu, Nov 19 2020 at 09:31, John Garry wrote:
>> 1) Interrupt does not exist. Definitely a full fail
>>
>> 2) Interrupt is already started up. Not a good idea on init() and
>> a clear fail.
>>
>> 3) Interrupt has already been switched to managed. Double init is not
>> really a g
Hi Thomas,
+int irq_update_affinity_desc(unsigned int irq,
+struct irq_affinity_desc *affinity)
Just a note on the return value, in the only current callsite -
platform_get_irqs_affinity() - we don't check the return value and
propagate the error. This is because we
John,
On Wed, Nov 18 2020 at 11:34, John Garry wrote:
>> +/**
>> + * irq_update_affinity_desc - Update affinity management for an interrupt
>> + * @irq:The interrupt number to update
>> + * @affinity: Pointer to the affinity descriptor
>> + *
>> + * This interface can be used to configur
Hi Thomas,
Sorry for the delay.
No worries, Thanks for the effort.
Supporting this truly on x86 needs some more
thought and surgery, but for ARM it should not matter.
ok, as long as you are content not to support x86 atm.
I made a few
tweaks to your original code. See below.
I think
On Mon, Nov 02 2020 at 21:35, Thomas Gleixner wrote:
> On Mon, Nov 02 2020 at 17:32, John Garry wrote:
> Correct. I have a halfways working solution for that, but I need to fix
> some other thing first.
Sorry for the delay. Supporting this truly on x86 needs some more
thought and surgery, but for
On Mon, Nov 02 2020 at 17:32, John Garry wrote:
> On 28/10/2020 18:22, Thomas Gleixner wrote:
>> But all of this can't work on x86 due to the way how vector allocation
>> works. Let me think about that.
>
> Is the problem that we reserve per-cpu managed interrupt space when
> allocated irq vectors
On 28/10/2020 18:22, Thomas Gleixner wrote:
On Wed, Oct 28 2020 at 20:33, John Garry wrote:
Hi Thomas,
+int irq_update_affinity_desc(unsigned int irq,
+struct irq_affinity_desc *affinity)
+{
+ unsigned long flags;
+ struct irq_desc *desc = irq_get_de
Add a function to allow the affinity of an interrupt be switched to
managed, such that interrupts allocated for platform devices may be
managed.
Suggested-by: Thomas Gleixner
Signed-off-by: John Garry
---
include/linux/interrupt.h | 8
kernel/irq/manage.c | 19 ++
On Wed, Oct 28 2020 at 20:33, John Garry wrote:
>
> +int irq_update_affinity_desc(unsigned int irq,
> + struct irq_affinity_desc *affinity)
> +{
> + unsigned long flags;
> + struct irq_desc *desc = irq_get_desc_lock(irq, &flags, 0);
> +
> + if (!desc)
> +
26 matches
Mail list logo
