UEFI Clock

UEFI Clock

[Loc Ho]

Hi Mike,

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?

-Loc

UEFI Clock

[Olof Johansson]

On Thu, Nov 14, 2013 at 4:01 PM, Loc Ho <lho@apm.com> wrote:
> Hi Mike,
>
> 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?

Most of it is handled in firmware and/or via ACPI.

In some cases the clocks are handled per driver instead, i.e. graphics
drivers have their own clock management for their part of the system,
etc.


-Olof

UEFI Clock

[Loc Ho]

Hi,

For the acpi, is that part of the acpi framework? If so, can you point
me to the location of the code for reference?

-Loc

Sent from my iPhone

> On Nov 14, 2013, at 17:36, Olof Johansson <olof@lixom.net> wrote:
>
>> On Thu, Nov 14, 2013 at 4:01 PM, Loc Ho <lho@apm.com> wrote:
>> Hi Mike,
>>
>> 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?
>
> Most of it is handled in firmware and/or via ACPI.
>
> In some cases the clocks are handled per driver instead, i.e. graphics
> drivers have their own clock management for their part of the system,
> etc.
>
>
> -Olof

UEFI Clock

[Olof Johansson]

[switched to correct devicetree list, even though this is all ACPI discussion]

On Thu, Nov 14, 2013 at 6:19 PM, Loc Ho <lho@apm.com> wrote:
> Hi,
>
> For the acpi, is that part of the acpi framework? If so, can you point
> me to the location of the code for reference?

Please don't top post replies when someone else has taken the time to
post a reply in-line. It's bad form for kernel mailing lists.

Sorry for being vague in my initial email -- I did mean to say that
most power management such as moving devices to standby modes is done
through ACPI calls on x86, I believe -- I.e. D0-D2,D3hot/D3cold is
handled through ACPI. I don't know if there's more fine-grained
runtime clock control done today.


-Olof

UEFI Clock

[Grant Likely]

On Thu, 14 Nov 2013 16:01:13 -0800, Loc Ho <lho@apm.com> wrote:
> Hi Mike,
> 
> 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.

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.

g.

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

UEFI Clock

[Hanjun Guo]

On 2013-11-18 13:57, Loc Ho wrote:
> 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

Sorry, I have no idea about this :(

> 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?

AFAIK, there is a HPET table for x86 for timer init, but there is
no standard method within ACPI to get timer for devices in DSDT.

> 
>>>
>>> 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.

It is RFC, still needs some update, I will send another version soon.
I will send to linaro-acpi at lists.linaro.org, it is a public mailing
list.

> 
>> 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.

I didn't catch up with the limitation clearly, if any specific example,
that would be great.

Thanks
Hanjun