UEFI Clock

[Loc Ho]

Hi,

>>> I will be looking into covering the clock driver to support UEFI.
>>> Before I do this, can someone explain to me how x86 system handle each
>>> IP clock as I don't see such thing?
>>
>>UEFI is completely unrelated to the clock drivers, it is only a firmware
>>interface for the OS loader. UEFI mostly disappears after Linux is
>>loaded. Are you perhaps asking about ACPI?
>>
>>There isn't such a thing on x86. This is entirely new territory. On x86
>>as far as I know any clock manipulation that does need to be done would
>>be performed by an ACPI method, but there is no concept of an IP clock
>>in the ACPI namespace, and so no standard way of describing them.
>
> Yes, there is no standard way (ACPI device object or ACPI table) to
> describe clocks for x86 in ACPI spec, but there is a table called GTDT
> (Generic Timer Description Table) for ARM which contains information
> for arch timer initialization.
>
> you can refer to ACPI spec 5.0 chapter 5.2.24:
> http://www.acpi.info/spec50.htm
[Loc Ho]
Do you know how an IP (such as SATA controller) clock is enabled for
x86? Or x86 is mostly PCIe and the clock is handled inside the driver
itself. Another related question would be how x86 enables the PCIe
controller clock? Is that too handled inside the host controller
driver itself or by some standard method within ACPI?

>>
>>You'd be much better of talking to Al Stone and Grame Gregory about what
>>their plans are for clock support in ACPI and to post your question to
>>the ACPI mailing list.
>
> We already finished the implementation of convert fixed clock and arch
> timer to ACPI, and I had already post the RFC patch set for review now:
>
> http://marc.info/?l=linaro-acpi&m=138450991609818&w=2
[Loc Ho]
Looked over this one. We will take this patch into our kernel.

> http://marc.info/?l=linaro-acpi&m=138198249622451&w=2
[Loc Ho]
>From what I can tell with DT, the only reason that an IP would need
this would be an common clock interface for framework to enable an IP
clock. If the framework expected an clock instance and one isn't
available, it will fail. Other than that, if an IP can handle its
clock initialization, do we really need this at all. For reference
clock and a few others, this is required if an IP clock is scaled from
an reference clock for say. I would like an agreement on the IP clock
itself. Is it required or they will be handled by the IP driver
itself?

Please be aware of the following limitation that we (at APM) ran into
and looking for an fix:

1. The fixed 32-bit memory resource can NOT be overlapped with another
memory resource with kernel version below 3.12. Don't know if this
limitation still existed in 3.12 kernel. May be this limit is removed
if one use 64-bit resource address but hasn't tried yet.
2. Overlap memory resource may be required if the same clock resource
combined other reset fields into the same registers. For this, one can
NOT use the standard _CRS as the same region may be defined with the
IP driver. Don't see an solution besides to use an non-standard
address. Then, what do one put in the _CRS as the ACPI expect one. If
you use an empty entry with 0 for address and 0 for length, other OS
vendor will complaint as well.

-Loc