On Tue, 02 Sep 2014 14:02:31 +0100, Marc Zyngier wrote:
> On 02/09/14 12:48, Tomasz Nowicki wrote:
> > On 01.09.2014 19:35, Marc Zyngier wrote:
> >> On 01/09/14 15:57, Hanjun Guo wrote:
> >>> From: Tomasz Nowicki
> >>>
> >>> ACPI kernel uses MADT table for proper GIC initialization. It needs to
>
Hi Grant,
On 11/09/14 12:48, Grant Likely wrote:
> On Tue, 02 Sep 2014 13:48:37 +0200, Tomasz Nowicki
> wrote:
>> On 01.09.2014 19:35, Marc Zyngier wrote:
>>> On 01/09/14 15:57, Hanjun Guo wrote:
From: Tomasz Nowicki
ACPI kernel uses MADT table for proper GIC initialization. It n
On Tue, 02 Sep 2014 13:48:37 +0200, Tomasz Nowicki
wrote:
> On 01.09.2014 19:35, Marc Zyngier wrote:
> > On 01/09/14 15:57, Hanjun Guo wrote:
> >> From: Tomasz Nowicki
> >>
> >> ACPI kernel uses MADT table for proper GIC initialization. It needs to
> >> parse GIC related subtables, collect CPU i
On 09/03/2014 02:42 PM, Arnd Bergmann wrote:
> On Monday 01 September 2014 22:57:51 Hanjun Guo wrote:
>> + /* Collect CPU base addresses */
>> + count = acpi_parse_entries(sizeof(struct acpi_table_madt),
>> + gic_acpi_parse_madt_cpu, table,
>> +
On 09/03/2014 10:57 AM, Arnd Bergmann wrote:
> On Wednesday 03 September 2014 11:26:14 Tomasz Nowicki wrote:
> In particular, the ACPI tables describing the irqchip have no way to
> identify the GIC at all, if I read the spec correctly, you have to
> parse the tables, ioremap the registers and the
On 09/03/2014 06:30 AM, Marc Zyngier wrote:
> On 02/09/14 16:45, Hanjun Guo wrote:
>> This value is for max processors entries in MADT, and we will use it to scan
>> MADT
>> for SMP/GIC Init, I just make it big enough for GICv3/4. since ACPI core
>> will stop
>> scan MADT if the real numbers of
On 09/01/2014 01:35 PM, Marc Zyngier wrote:
> On 01/09/14 15:57, Hanjun Guo wrote:
>> From: Tomasz Nowicki
>>
>> ACPI kernel uses MADT table for proper GIC initialization. It needs to
>> parse GIC related subtables, collect CPU interface and distributor
>> addresses and call driver initialization
On 05.09.2014 12:39, Marc Zyngier wrote:
On 05/09/14 11:13, Arnd Bergmann wrote:
On Friday 05 September 2014 10:47:30 Marc Zyngier wrote:
I still prefer being explicit here for the same reason I mentioned earlier:
I want it to be very clear that we don't support arbitrary irqchips other
than
On 05/09/14 11:13, Arnd Bergmann wrote:
> On Friday 05 September 2014 10:47:30 Marc Zyngier wrote:
>>>
>>> I still prefer being explicit here for the same reason I mentioned earlier:
>>> I want it to be very clear that we don't support arbitrary irqchips other
>>> than the ones in the APCI specific
On 05.09.2014 12:13, Arnd Bergmann wrote:
On Friday 05 September 2014 10:47:30 Marc Zyngier wrote:
I still prefer being explicit here for the same reason I mentioned earlier:
I want it to be very clear that we don't support arbitrary irqchips other
than the ones in the APCI specification. The
On Friday 05 September 2014 10:47:30 Marc Zyngier wrote:
> >
> > I still prefer being explicit here for the same reason I mentioned earlier:
> > I want it to be very clear that we don't support arbitrary irqchips other
> > than the ones in the APCI specification. The infrastructure exists on DT
>
On 03/09/14 15:57, Arnd Bergmann wrote:
> On Wednesday 03 September 2014 11:26:14 Tomasz Nowicki wrote:
>> On 02.09.2014 15:02, Marc Zyngier wrote:
>>> On 02/09/14 12:48, Tomasz Nowicki wrote:
On 01.09.2014 19:35, Marc Zyngier wrote:
>> @@ -78,6 +79,10 @@ void __init set_handle_irq(void (*
On 03.09.2014 16:57, Arnd Bergmann wrote:
On Wednesday 03 September 2014 11:26:14 Tomasz Nowicki wrote:
On 02.09.2014 15:02, Marc Zyngier wrote:
On 02/09/14 12:48, Tomasz Nowicki wrote:
On 01.09.2014 19:35, Marc Zyngier wrote:
@@ -78,6 +79,10 @@ void __init set_handle_irq(void (*handle_irq)
On 2014年09月03日 19:17, Hanjun Guo wrote:
>>> +
>>> +#ifdef CONFIG_ACPI
>>> +#define ACPI_MAX_GIC_CPU_INTERFACE_ENTRIES 65535
>> With GICv2? I doubt it.
> I will create macro for each GIC driver:
> #define ACPI_MAX_GICV2_CPU_INTERFACE_ENTRIES8
> #define ACPI_MAX_GICV3
On 04.09.2014 12:14, Arnd Bergmann wrote:
On Thursday 04 September 2014 12:10:28 Tomasz Nowicki wrote:
On 03.09.2014 20:42, Arnd Bergmann wrote:
On Monday 01 September 2014 22:57:51 Hanjun Guo wrote:
+ /* Collect CPU base addresses */
+ count = acpi_parse_entries(sizeof(struct acpi
On Thursday 04 September 2014 12:10:28 Tomasz Nowicki wrote:
> On 03.09.2014 20:42, Arnd Bergmann wrote:
> > On Monday 01 September 2014 22:57:51 Hanjun Guo wrote:
> >> + /* Collect CPU base addresses */
> >> + count = acpi_parse_entries(sizeof(struct acpi_table_madt),
> >> +
On 03.09.2014 20:42, Arnd Bergmann wrote:
On Monday 01 September 2014 22:57:51 Hanjun Guo wrote:
+ /* Collect CPU base addresses */
+ count = acpi_parse_entries(sizeof(struct acpi_table_madt),
+ gic_acpi_parse_madt_cpu, table,
+
On Monday 01 September 2014 22:57:51 Hanjun Guo wrote:
> + /* Collect CPU base addresses */
> + count = acpi_parse_entries(sizeof(struct acpi_table_madt),
> + gic_acpi_parse_madt_cpu, table,
> + ACPI_MADT_TYPE_GENERIC_INT
On Wednesday 03 September 2014 11:26:14 Tomasz Nowicki wrote:
> On 02.09.2014 15:02, Marc Zyngier wrote:
> > On 02/09/14 12:48, Tomasz Nowicki wrote:
> >> On 01.09.2014 19:35, Marc Zyngier wrote:
> @@ -78,6 +79,10 @@ void __init set_handle_irq(void (*handle_irq)(struct
> pt_regs *))
> >>
>> +
>> +#ifdef CONFIG_ACPI
>> +#define ACPI_MAX_GIC_CPU_INTERFACE_ENTRIES 65535
> With GICv2? I doubt it.
I will create macro for each GIC driver:
#define ACPI_MAX_GICV2_CPU_INTERFACE_ENTRIES8
#define ACPI_MAX_GICV3_CPU_INTERFACE_ENTRIES65535
>>> Where do y
On 02/09/14 16:45, Hanjun Guo wrote:
> On 2014年09月02日 21:02, Marc Zyngier wrote:
>> On 02/09/14 12:48, Tomasz Nowicki wrote:
>>> On 01.09.2014 19:35, Marc Zyngier wrote:
On 01/09/14 15:57, Hanjun Guo wrote:
> From: Tomasz Nowicki
>
> ACPI kernel uses MADT table for proper GIC init
On 02.09.2014 15:02, Marc Zyngier wrote:
On 02/09/14 12:48, Tomasz Nowicki wrote:
On 01.09.2014 19:35, Marc Zyngier wrote:
On 01/09/14 15:57, Hanjun Guo wrote:
From: Tomasz Nowicki
ACPI kernel uses MADT table for proper GIC initialization. It needs to
parse GIC related subtables, collect CPU
On Tue, Sep 02, 2014 at 12:48:37PM +0100, Tomasz Nowicki wrote:
> On 01.09.2014 19:35, Marc Zyngier wrote:
> > On 01/09/14 15:57, Hanjun Guo wrote:
> >> From: Tomasz Nowicki
> >>
> >> ACPI kernel uses MADT table for proper GIC initialization. It needs to
> >> parse GIC related subtables, collect C
On 02/09/14 16:45, Hanjun Guo wrote:
On 2014年09月02日 21:02, Marc Zyngier wrote:
On 02/09/14 12:48, Tomasz Nowicki wrote:
On 01.09.2014 19:35, Marc Zyngier wrote:
On 01/09/14 15:57, Hanjun Guo wrote:
From: Tomasz Nowicki
ACPI kernel uses MADT table for proper GIC initialization. It needs to
On 02/09/14 16:45, Hanjun Guo wrote:
> On 2014年09月02日 21:02, Marc Zyngier wrote:
>> On 02/09/14 12:48, Tomasz Nowicki wrote:
>>> On 01.09.2014 19:35, Marc Zyngier wrote:
On 01/09/14 15:57, Hanjun Guo wrote:
> From: Tomasz Nowicki
>
> ACPI kernel uses MADT table for proper GIC init
On 2014年09月02日 21:02, Marc Zyngier wrote:
> On 02/09/14 12:48, Tomasz Nowicki wrote:
>> On 01.09.2014 19:35, Marc Zyngier wrote:
>>> On 01/09/14 15:57, Hanjun Guo wrote:
From: Tomasz Nowicki
ACPI kernel uses MADT table for proper GIC initialization. It needs to
parse GIC relate
On 02/09/14 12:48, Tomasz Nowicki wrote:
> On 01.09.2014 19:35, Marc Zyngier wrote:
>> On 01/09/14 15:57, Hanjun Guo wrote:
>>> From: Tomasz Nowicki
>>>
>>> ACPI kernel uses MADT table for proper GIC initialization. It needs to
>>> parse GIC related subtables, collect CPU interface and distributor
On 01.09.2014 19:35, Marc Zyngier wrote:
On 01/09/14 15:57, Hanjun Guo wrote:
From: Tomasz Nowicki
ACPI kernel uses MADT table for proper GIC initialization. It needs to
parse GIC related subtables, collect CPU interface and distributor
addresses and call driver initialization function (which
On 1 September 2014 19:35, Marc Zyngier wrote:
>
> On 01/09/14 15:57, Hanjun Guo wrote:
> > From: Tomasz Nowicki
> >
> > ACPI kernel uses MADT table for proper GIC initialization. It needs to
> > parse GIC related subtables, collect CPU interface and distributor
> > addresses and call driver init
On 01/09/14 15:57, Hanjun Guo wrote:
> From: Tomasz Nowicki
>
> ACPI kernel uses MADT table for proper GIC initialization. It needs to
> parse GIC related subtables, collect CPU interface and distributor
> addresses and call driver initialization function (which is hardware
> abstraction agnostic
From: Tomasz Nowicki
ACPI kernel uses MADT table for proper GIC initialization. It needs to
parse GIC related subtables, collect CPU interface and distributor
addresses and call driver initialization function (which is hardware
abstraction agnostic). In a similar way, FDT initialize GICv1/2.
NOT
31 matches
Mail list logo
