Re: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501

[Thomas Renninger]

On Monday, February 17, 2014 09:19:03 AM H. Peter Anvin wrote:
> What I gather is that they want to add tables where there are none, and that
> the ACPI code doesn't play along because there is no RSDP nor any
> RSDT/XSDT.
Yep, this does currently not work.

Easiest I can think of instead of trying to modify RSDP or similar, is
to still pass the tables via unzipped, glued cpio which the kernel
can access early. The same way it is done for current ACPI table overriding
and early microcode passing.

Also find them via:
file = find_cpio_data(cpio_path, data, size, &offset);
(compare with drivers/acpi/osl.c)

and add them to (compare with drivers/acpi/acpica/acglobal.h):
/*
 * acpi_gbl_root_table_list is the master list of ACPI tables that were
 * found in the RSDT/XSDT.
 */
ACPI_EXTERN struct acpi_table_list acpi_gbl_root_table_list;

But right now, this is acpica internal only.
Most elegant way should be that ACPICA people would add another OS
callback:

acpi_status
acpi_os_physical_table_add(acpi_physical_address *address,
                                u32 *table_length));

which is called right after acpi_os_physical_table_override.

Implementation of it should be in osl.c again where it can easily
be tracked whether a table has been replaced already and need not to
be added, for example something like:
__initdata struct cpio_data overridden_tables[ACPI_OVERRIDE_TABLES];

ACPICA part should not be hard as well. It's some time ago, but it
may be a simple call to:
        /* Add the table to the global root table list */

        status = acpi_tb_store_table(table_desc->address, table_desc->pointer,
                                     table_desc->length, table_desc->flags,
                                     table_index);

if acpi_os_physical_table_add() has returned a valid address/length.
This would then add the table to acpica internal:

/*
 * acpi_gbl_root_table_list is the master list of ACPI tables that were
 * found in the RSDT/XSDT.
 */
ACPI_EXTERN struct acpi_table_list acpi_gbl_root_table_list;

and later all the tables in there get loaded and set up as if they
were passed from BIOS.

       Thomas


> On February 17, 2014 8:28:05 AM PST, Thomas Renninger <trenn@xxxxxxx> wrote:
> >On Friday, February 14, 2014 10:16:41 PM Thomas Gleixner wrote:
> >> On Fri, 14 Feb 2014, H. Peter Anvin wrote:
> >> > On 02/14/2014 11:59 AM, Thomas Gleixner wrote:
> >> > > On Fri, 14 Feb 2014, H. Peter Anvin wrote:
> >> > >> On 02/14/2014 11:15 AM, Thomas Gleixner wrote:
> >> > >>> I'm fine with ACPI tables if we can provide simple means for
> >
> >embedded
> >
> >> > >>> users to load one via grub or just attach it to the kernel
> >
> >image.
> >
> >> > >> That already exists, see
> >
> >Documentation/acpi/initrd_table_override.txt.
> >
> >> > > That requires, that you have already ACPI tables.
> >> > > 
> >> > > ACPI_SIG_RSDP cannot be overridden and that's the base table you
> >
> >need
> >
> >> > > to get ACPI going in the first place. So we need support for that
> >
> >and
> >
> >> > > probably for storing the tables at some non canonical place.
> >> > 
> >> > Well, the RSDP and RSDT/XSDT are nothing but pointers to other
> >
> >tables,
> >
> >> > so if explicitly overridden I'm not sure if one actually would need
> >> > them.  That doesn't mean our current code will work without them,
> >
> >though.
> >
> >> I tried once to overload all of the tables, but failed miserably in
> >> the ACPI dungeon. RSDP was the major pain point IIRC.
> >
> >What exactly do you try to achieve?
> >I cannot imagine a use-case where RSDP  and XSDT overriding would help
> >you.
> >
> >Have you tried the current mechanism to override tables?
> >What is missing and for what do you need it for?
> >
> >I need more context, maybe I can help then.
> >
> >   Thomas

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/