In D15431#325512, @jhb wrote:

Overall I think these look ok. I haven't tested them though.

BTW, it looks that we do not have a variable with boot cpu number. If it's true, I would suggest to have it for cases like this.

In D10218#221730, @zbb wrote:

@skra Why are we not able to pmap_set_tex() while caches are enabled? We are merely modifying two registers. TLB invalidation should be the only thing that is required to be done. Could you elaborate this constraint a little? It seems that this is the only thing that is holding us back from the acceptable solution so I would like to understand the issue.
Thanks in advance for your help.

In D10218#221615, @zbb wrote:

In D10218#221537, @skra wrote:

Note that pmap_remap_vm_attr() calls pmap_set_tex() which assumes that all caches are disabled (see last two lines in this function). Caches are enabled in reinit_mmu() which is called from pmap_bootstrap_prepare() and init_secondary(). It's unfortunate that Michal did not add some comment about this to pmap_remap_vm_attr(). However, it's just a note for now as use of platform_cpu_init() is not clear so far.

Yes. This must be called where it is being called now. Unfortunately platform_ code seems to be unusable for our case.

BTW. What is unclear for you regarding the use of platform_cpu_init()? There was a need to modify the default, hard-coded settings of the mappings as well as CPUs auxiliary control register. Use of another platform callback was suggested instead of ugly ifdef or another hard-coded setting of ACTLR (that was undesirable on some Cortex revisions). That is why we created this function and we use it in the related patches (please see dependencies) to modify default CPU/MMU settings.

Note that pmap_remap_vm_attr() calls pmap_set_tex() which assumes that all caches are disabled (see last two lines in this function). Caches are enabled in reinit_mmu() which is called from pmap_bootstrap_prepare() and init_secondary(). It's unfortunate that Michal did not add some comment about this to pmap_remap_vm_attr(). However, it's just a note for now as use of platform_cpu_init() is not clear so far.

In D10218#211540, @meloun-miracle-cz wrote:

Please tell me, do you really think that hellish "#ifdef SOC_xxx" style used in Marvell subdirectory is the right one?
For me, using "#ifdef SOC_xxx" is unacceptable in common code, and is deprecated in vendor subdirs.

And, in this case, right solution for this problem is pretty easy, something like:
https://github.com/strejda/tegra/commit/3b5138751ee5643992b20fcb21b280fab433bb20
(untested, you can simply put "pmap_remap_vm_attr(VM_MEMATTR_DEVICE, VM_MEMATTR_SO);" to platform_devmap_init() or so...)

In D8616#210278, @meloun-miracle-cz wrote:

In D8616#210126, @andrew wrote:

In D8616#210013, @skra wrote:

(3) XREF_INVALID used the way you are suggesting is a nonsense. I would see XREF_INVALID only as an error code.

We already use errno values in this code so the error code would be EINVAL.

Where we pass any error code to xref parameter? Ore where we return error code from function returning xref?

(1) The staff around PIC and xref was implemented with concrete idea. You are trying to change it. So, it's not cleanup, it's an implementation of new idea. And I don't see why this change would be better.
(2) You are forcing devices which do not know (or have) their XREFs to generate some instead of using one and only XREF_UNKNOWN for these cases, which is zero.
(3) XREF_INVALID used the way you are suggesting is a nonsense. I would see XREF_INVALID only as an error code.
(4) This part of INTRNG was implemented strictly according to Michal, so I hope that you do not commit this before Michal agrees with it.

I suggest that the main reason for this change should be the replacement of pcpu_find() by get_pcpu() now. I mean the text in commit message. The cleanup should be stated as secondary.

Thanks.

In D8616#178836, @andrew wrote:

In D8616#178832, @skra wrote:

(1) Be more verbose in summary and explain why 0 is not good for unknown xref value. And what 0 xref value will mean if -1 is unknown xref value.

0 is already a valid MSI xref. Having it as the unknown value was already problematic. With ACPI we will get a second pic with an xref of 0. This patch is needed to both tell them apart, and to be able to search for them.

(2) If you need to do cosmetic change which adds flag argument to pic_create(), do it in separate change.

Adding a flag argument to pic_create is a needed change as it then passes the flag to pic_lookup_locked.

(1) Be more verbose in summary and explain why 0 is not good for unknown xref value. And what 0 xref value will mean if -1 is unknown xref value.
(2) If you need to do cosmetic change which adds flag argument to pic_create(), do it in separate change.

Hmm, if ARM_HAVE_MP_EXTENSIONS will be a hint defined in kernel configuration file, then the pattern will be the following:

Well, the pattern should be the following to work with GENERIC kernel.

In D8092#168719, @andrew wrote:

You're confusing two things: the SMP option, and the MP extensions. The former just tells the kernel it should run on the all CPUs it can (with a few restrictions), the latter is the HW support needed for running on multiple CPUs.

There is no reason to artificially restrict running an SMP kernel on a Cortex-A8 just because it doesn't have the MP extensions, just as we should be able to run a non-SMP kernel on later hardware with the MP extensions.

I suggest to create ARM_GENERIC_KERNEL option which could be used in situation like here when something bizarre is implemented.

Here, we face the fact that various Cortex-A arm cores have various features. And even if I understand the reason for GENERIC, I don't like penalization of either custom or native kernel configurations just because of it. So, here we would need three functions set - one for UP, one for SMP, and one for GENERIC.

I understand the reason for this change, however, do we really want to run SMP kernel on UP boards? Maybe, __ARM_ARCH >= 7 && defined SMP test is only some obscure way how to eliminate boards which have not implemented SMP variants of cp15 operations like cortex A8?

I have some feeling that all armv7 TLB operations are inlined already. And cache operations too. At least, it was a goal. Only cpu_setup() method is used from struct cpu_functions armv7 table. Nevertheless, I may be wrong.

Update for ARM64 and MIPS.

In D6436#141112, @andrew wrote:

So if we call bus_setup_intr the parent will allocate the intr_irqsrc, the child will then need to allocate a second intr_irqsrc for the same interrupt. This will work for a small number of interrupts, but not for say 500. The alternative is there could be some interface for the parent to pass the creation to the child, however this would defeat the point of calling bus_setup_intr

In D6436#140467, @andrew wrote:

In D6436#139713, @skra wrote:

Hmm, the thing which bothers me really is that I'm not able to define a difference between chained PIC and child PIC. A chained PIC must call bus_setup_intr() to connect itself to its parent. And there is a flag INTR_SOLO which enables calling of a PIC filter function directly, i.e. without a wrap of intr_event_handle(). Your child PIC does not call bus_setup_intr() and call a PIC filter function directly. But it does that on a range of irqs. Does it mean that we should register a chained PIC the same way how a child PIC is? In other words, if a child PIC is registered this way, why not register a chained PIC the same way?

So, what makes a child PIC different? In a chained PIC case, one parent irq is mapped to N irqs of chained PIC. In a child PIC case, N parent irqs are mapped to N irqs of child PIC. A chained PIC may not be a bus child too. Don't we rather need bus_setup_intr() to be effective for a range of irqs?

A child PIC will manage the allocated irq space, including allocating it's own strict isrc for each interrupt, removing the need from the parent. This means all the parent needs to know is when to pass an interrupt to a child.

In D6436#139055, @andrew wrote:

In D6436#138609, @skra wrote:

(1) Well, chained PIC is bound to its parent only by one irq. Considering your change, is there any other difference here except that child PIC is bound to a range of irqs? For example, could it be sufficient to register ISRC with child device_t but keep it in parent PIC?

That would need the parent to be able to handle registering children as they may not be a bus child. It would potentially mean we would need to copy the code to handle this to all drivers that allow child interrupt controllers.

(1) Well, chained PIC is bound to its parent only by one irq. Considering your change, is there any other difference here except that child PIC is bound to a range of irqs? For example, could it be sufficient to register ISRC with child device_t but keep it in parent PIC?

In general, I'm not able decide now if I like or dislike this change. For the mention reasons of this change, dynamic reallocation of global irq table would be enough. Note that INTRCNT_COUNT depends on NIRQ too. So, definitely, dynamic allocation of irq counters (intrcnt and intrnames arrays) should be solved too and IMO before. For example, the counter could be a part of struct intr_isrc and the arrays could be filled on request.

In D5573#125735, @skra wrote:

I was so curious about these enable/disable and mask/unmask registers that I've downloaded manual and looked at Linux implementation for unpublished "features". So, after this will be accepted and committed, there may be done some improvements like it looks that the interrupts could be unmasked permanently and only enable/disable registers could be used. Further, currently active interrupt on CPU irq input can be found in SW_INT_VECTOR_REG; the read zero must be checked in pending register 0, bit 0 to be sure if it's spurious irq or not.

I was so curious about these enable/disable and mask/unmask registers that I've downloaded manual and looked at Linux implementation for unpublished "features". So, after this will be accepted and committed, there may be done some improvements like it looks that the interrupts could be unmasked permanently and only enable/disable registers could be used. Further, currently active interrupt on CPU irq input can be found in SW_INT_VECTOR_REG; the read zero must be checked in pending register 0, bit 0 to be sure if it's spurious irq or not.

I'm sorry but I have changed PIC interface in r297539. It should be stable now and simpler. There are also more controllers rewritten for INTRNG in tree. The BEAGLEBONE aintc.c is a simplest one.

Thanks that you are doing this. I thought that I would do this later, as there was no immediate need to do it in D5730. Thus, thanks again and sorry for trouble.