In D15431#325512, @jhb wrote:Overall I think these look ok. I haven't tested them though.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Feed Advanced Search
Advanced Search
Advanced Search
May 15 2018
May 15 2018
skra added a comment to D15431: follow-up to r332730 and r332752: set kdb_why to "trap" for fatal traps.
Feb 14 2018
Feb 14 2018
Nov 2 2017
Nov 2 2017
Take into account race conditions in case of accessed or modified bit
May 15 2017
May 15 2017
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.
May 13 2017
May 13 2017
skra added a comment to D10218: Implement workaround for Armada 38X family HW issue between CPU and devices.
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.
May 12 2017
May 12 2017
skra added a comment to D10218: Implement workaround for Armada 38X family HW issue between CPU and devices.
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.
May 11 2017
May 11 2017
skra added a comment to D10218: Implement workaround for Armada 38X family HW issue between CPU and devices.
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.
Apr 20 2017
Apr 20 2017
Apr 1 2017
Apr 1 2017
skra added a comment to D10218: Implement workaround for Armada 38X family HW issue between CPU and devices.
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...)
Mar 29 2017
Mar 29 2017
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?
Mar 28 2017
Mar 28 2017
(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.
Jan 25 2017
Jan 25 2017
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.
Jan 24 2017
Jan 24 2017
Jan 15 2017
Jan 15 2017
Jan 14 2017
Jan 14 2017
Dec 17 2016
Dec 17 2016
Fix sscanf() format string to match an argument. This also fixes kernel
Nov 24 2016
Nov 24 2016
Nov 23 2016
Nov 23 2016
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.
Nov 22 2016
Nov 22 2016
(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.
Nov 12 2016
Nov 12 2016
The return type of is_managed() was changed from boolean_t to bool type
Always call PHYS_TO_VM_PAGE() in is_managed(). Fast road for addresses
skra added inline comments to D8502: ARMv6 pmap - fix the way how a decision is made that a page is under pv management.
Nov 11 2016
Nov 11 2016
skra retitled D8502: ARMv6 pmap - fix the way how a decision is made that a page is under pv management from to ARMv6 pmap - fix the way how a decision is made that a page is under pv management.
Oct 4 2016
Oct 4 2016
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.
Oct 3 2016
Oct 3 2016
I suggest to create ARM_GENERIC_KERNEL option which could be used in situation like here when something bizarre is implemented.
Oct 2 2016
Oct 2 2016
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.
Sep 30 2016
Sep 30 2016
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.
Aug 31 2016
Aug 31 2016
Jun 7 2016
Jun 7 2016
Remove temporary solution for storing interrupt mapping data as
Jun 5 2016
Jun 5 2016
INTRNG - change the way how an interrupt mapping data are provided
(1) Add a new bus method to get a mapping data for an interrupt.
Jun 4 2016
Jun 4 2016
Update for ARM64 and MIPS.
Jun 3 2016
Jun 3 2016
Define irq variable only in the block where used.
Postpone allocation of IRQ resource to the time when interrupt
Jun 2 2016
Jun 2 2016
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
Jun 1 2016
Jun 1 2016
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.
May 29 2016
May 29 2016
skra retitled D6634: INTRNG - rework FDT like interrupt mapping according to D6632 from to INTRNG - rework FDT like interrupt mapping according to D6632.
skra retitled D6632: INTRNG generalization step 2 - extending struct resource from to INTRNG generalization step 2 - extending struct resource.
May 27 2016
May 27 2016
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.
May 25 2016
May 25 2016
(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?
Add more info about the issue fixed in r298460. Rephrase some sentences
May 23 2016
May 23 2016
INTRNG - support new interrupt mapping type INTR_MAP_DATA_GPIO
INTRNG - use gpio generic interrupt modes definitions added in r298738.
May 22 2016
May 22 2016
INTRNG - implement pic_post_filter method. This method is fundamental
Fix some format strings to make them either correct or uniform.
May 17 2016
May 17 2016
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.
May 10 2016
May 10 2016
May 8 2016
May 8 2016
INTRNG - update gpio pin capabilities according to r299198.
INTRNG - update gpio pin capabilities according to r299166.
May 6 2016
May 6 2016
INTRNG - support new interrupt mapping type INTR_MAP_DATA_GPIO
INTRNG - use gpio interrupt modes definitions added in r298738 and
INTRNG - support new interrupt mapping type INTR_MAP_DATA_GPIO
INTRNG - use gpio interrupt modes definitions added in r298738 and
Set correct size to the size member of struct intr_map_data when
May 5 2016
May 5 2016
INTRNG - redefine struct intr_map_data to avoid headers pollution. Each
Remove superfluous check. The pic_dev member of struct pic
Apr 27 2016
Apr 27 2016
Apr 24 2016
Apr 24 2016
Apr 22 2016
Apr 22 2016
Fix duplicate TLB entries issue during section promotion/demotion.
Don't use atomic operations for page table entries and handle access
Add four functions which check a virtual address for stage 1 privileged
Apr 21 2016
Apr 21 2016
Apr 20 2016
Apr 20 2016
Apr 9 2016
Apr 9 2016
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.
Apr 7 2016
Apr 7 2016
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.
Properly initialize isrc_cpu field of ISRC which is setup for an IPI.
Fix intr_irq_shuffle(). After r297539, ISRCs doing IPI may be also
Implement intr_isrc_init_on_cpu() and use it to replace very same
Apr 6 2016
Apr 6 2016
Fix PIC lookup by device and xref. There was not taken into account
Apr 5 2016
Apr 5 2016
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.
Fix typo. No functional change.
Rework BCM283x gpio interrupt controller for INTRNG. It's used on RPI-B
Implement bcm2836 interrupt controller for INTRNG and enable it
Rework bcm283x interrupt controller for INTRNG and enable it
Apr 4 2016
Apr 4 2016
skra retitled D5822: ARM - implementation of BCM2836 local INTC for ARM_INTRNG from to ARM - implementation of BCM2836 local INTC for ARM_INTRNG.
Define local-intc for BCM2836 platform (RPI2) and make BCM2835 intc
Rework TI gpio interrupt controller for INTRNG. It's used on PANDABOARD
Rework am33xx interrupt controller for INTRNG and enable it
Remove FDT specific parts from INTRNG. Change its interface to make it