Len Brown wrote:
On Tue, 16 Dec 2008, Ingo Molnar wrote:
* Jeremy Fitzhardinge <jeremy@xxxxxxxx> wrote:
Hi Len,
Have you seen these three patches? Do they look OK to you?
Yinghai Lu improve the third patch ("acpi: remove final __acpi_map_table
mapping before setting acpi_gbl_permanent_mmap"), which I think Ingo
sent you instead.
Len,
i asked about these patches before too - and if that's fine with you we'd
just queue them up in the x86 tree (like we did before the .28 merge
window). Most of the impact will be on x86. So an Acked-by from you would
be fine to start this.
Sorry for the delay.
I recall reading your e-mail on this and thought I replied to it,
but for some reason I found neither your original message nor
my reply when I searched my archives today.
But I did recall Ingo making a branch for this one, and so looking
at remotes/origin/acpi-for-len in ingo's tree...
It isn't immediately clear to me what problem this patch series solves,
and thus it is hard to judge how important this is.
It touches a lot of files, and it is going to run into a bunch of merge
conflicts.
I'm not thrilled that the first part of the series makes changes
which are then undone by the later part of the series --
that doesn't help w/ conflict resolution...
The change to tbxface.c is an ACPICA API change.
It looks reasonable and it might be the right change,
but it is extra work -- we should sync with Bob
when he gets back from break.
So, this one is sort of a headache, how important is it?
Well, there's several aspects to this series:
The important one from my perspective is using early_ioremap to map the
acpi memory, rather than using a private mapping function; this is
necessary when running under Xen, so that the right memory gets mapped.
This in itself is pretty straightforward, but it raises a few issues.
One is that the acpi code doesn't properly unmap its mapped memory, but
relies on a "new mapping replaces old" semantic. Putting a wrapper
around early_ioremap to emulate this is fairly straightforward, but it
does leave one trailing mapping, which causes early_ioremap to raise a
warning.
I addressed this warning by putting in a hook to unmap the last
mapping. This was simple, but pretty hackish. Yinghai went the extra
distance by making the acpi code properly pair map and unmap calls on
all the resources it needs, doing away with the "new map unmaps
previous" behaviour, and cleaning up the warning in the process.
Thanks,
J
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
