On 11/14/2013 03:27 AM, Tomasz Nowicki wrote:

On 14.11.2013 10:10, Graeme Gregory wrote:

On Wed, Nov 13, 2013 at 01:08:25PM -0700, Al Stone wrote:

On 11/13/2013 01:44 AM, Hanjun Guo wrote:

On 2013-11-13 15:59, Andrea Gallo wrote:

Al

I am not sure about this.

What if one day we have ARM vendors showing up with x86-like fake
registers just to be fully fixed hw profile compliant and feeling
they could be safer than with the resuced hw profile, for whichever
reason?

I would suggest we have two flags, which would be both set in 99.9%
of ARM platforms but maybe there could be a 0.1% where it is ARM
and fixed profile one day?

I agree with Andrea.
we can't just let ARM = HW-reduced, some OEM vendors may implement
ACPI hardware one day.

Thanks
Hanjun

Hrm.  I was unaware that some vendors were already going down
the path of full ACPI hardware.  In that case, we should leave
things as they are and if a particular vendor wants to have
reduced HW the default (or not), then they can do that in their
specific Kconfig items.  So, I'm withdrawing this patch as
unneeded.

I very much disagree with Andrea and Hanjun, we cannot design software
for an infinite number of "what if?". Especially when its a complex
system which requires testing. I very much doubt someone will come up
with an emulated non reduced hardware platform on arm that just works on
first boot. Considering they will have to do a lot of testing and
probably
code changes then one line in a config file is not a major extra bit of
work.

Also consider if we do not push this patch we will be answering the
question
approximately once a day of why our ARM acpi code core dumps due to
random
memory access because someone forgot to set that flag in their .config.

Graeme

I also would like to see hardware reduce selected along with ARM. This
way vendors are somehow forced to implement new feature in generic way,
what means all flavour of ARM platforms can use it (eventual others
platforms too). Personally, my feeling is that fixed version of ACPI is
only for x86 and hardware reduce is right direction.

Tomasz

I think I may have answered in haste (it has been a *long* week
already and I've been tired).

The more I think about this, I realize I have to withdraw my
withdrawal :).  The issue is that the reduced HW profile is
meant to be more architecturally neutral, while the full ACPI
profile is actually x86-dependent.  Not only is it x86 specific,
it carries with it a whole raft of baggage from pre-ACPI 5.0
legacy systems (there are Atom systems using reduced HW mode
just to avoid this cruft).

As the most egregious example, if an ARM vendor is to make an
SoC that implements the full ACPI profile, they *must* implement
an NMI interrupt line that behaves like a real NMI (none of this
priority stuff).  If they do, is that really an ARM processor?
I don't think so -- it's some sort of hybrid beast.  The same
problem exists for SCI, and possibly MCE and others that are
very specific to x86 *and* impose HW requirements on the SoC
vendors to step outside of a normal ARM implementation.

The next layer is that the FACS table would also impose the
requirement to implement various registers with very specific
semantics, again specific to x86, and outside the definition
of ARM.

The final thought that occurs to me is that without reduced HW
profile, we *must* implement a single global lock in ACPI.  That
lock could be abused in a bazillion different ways that would
end up creating a single global lock in the kernel.  Since there
is by definition no ACPI global lock in reduced HW, that cannot
happen.

So, now that I think about it more, we *must* link reduced HW and
ARM ACPI unless we want to force HW requirements on SoC vendors
that would (a) force them to add x86-specific features to their
ARM hardware, and (b) force them to support legacy x86 hardware
features that even Intel is moving away from.

--
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Linaro Enterprise Group
al.stone@linaro.org
-----------------------------------

_______________________________________________
Linaro-acpi mailing list
Linaro-acpi@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-acpi