About cachetype on ARMv7

[Kukjin Kim]

Hi all,

I have a query about cachetype on ARMv7.

Following is from arch/arm/kernel/setup.c

static void __init cacheid_init(void)
{
unsigned int cachetype = read_cpuid_cachetype();
unsigned int arch = cpu_architecture();

if (arch >= CPU_ARCH_ARMv6) {
if ((cachetype & (7 << 29)) == 4 << 29) {
/* ARMv7 register format */
cacheid = CACHEID_VIPT_NONALIASING;

(snip)

printk("CPU: %s data cache, %s instruction cache\n",
cache_is_vivt() ? "VIVT" :
cache_is_vipt_aliasing() ? "VIPT aliasing" :
cache_is_vipt_nonaliasing() ? "VIPT nonaliasing" :
"unknown",
cache_is_vivt() ? "VIVT" :
icache_is_vivt_asid_tagged() ? "VIVT ASID tagged" :
cache_is_vipt_aliasing() ? "VIPT aliasing" :
cache_is_vipt_nonaliasing() ? "VIPT nonaliasing" :
"unknown");
}

The cachetype access cp15 CTR register through read_cpuid_cachetype(). And
if ARMv7, then its [31:29] value is 100(b).

[31:29] = 100(b) on ARMv7
[31:29] = 000(b) on ARMv6

So, if ARMv7, then cacheid is mapped VIPT cache and non-aliasing,
CACHEID_VIPT_NONALIASING.

But actually, didn't check L1Ip which has policy of instruction cache, and
policy of data cache from other register at that time. Nevertheless, if
ARMv7, printed like following and used.
'CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache'

If every ARMv7 SoCs have VIPT non-aliasing d-cache and i-cache, then no
problem. But actually, Samsung S5PV310(cortex-A9) has PIPT d-cache and VIPT
non-aliasing i-cache. I think PIPT does not mean VIPT non-aliasing even
though their functionality is similar.
Isn't there any functionality difference?
And..in this case, isn't there any problems?
...

How do you think about this?

Thanks.

Best regards,
Kgene.
--
Kukjin Kim <***@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.

[Russell King - ARM Linux]

Post by Kukjin Kim
If every ARMv7 SoCs have VIPT non-aliasing d-cache and i-cache, then no
problem. But actually, Samsung S5PV310(cortex-A9) has PIPT d-cache and VIPT
non-aliasing i-cache. I think PIPT does not mean VIPT non-aliasing even
though their functionality is similar.

There is no visible difference between a non-aliasing VIPT cache and a
PIPT cache. Address bit allocation for a 32-byte cache line VIPT
non-aliasing cache with 4K page size:

[0:1] = byte offset into word
[4:2] = word offset
[N-1:5] = virtual index
[31:N] = physical tag

where N <= PAGE_SHIFT, otherwise it would be an aliasing VIPT cache.

For a PIPT non-aliasing cache:

[0:1] = byte offset into word
[4:2] = word offset
[M-1:5] = physical index
[31:M] = physical tag

where M doesn't matter as it can never alias with itself.

The requirements for N is such the CPU visible conditions which qualify a
cache as being VIPT non-aliasing also satisfy PIPT - and a non-aliasing
VIPT cache has the same properties as a PIPT cache.

[Kukjin Kim]

Post by Russell King - ARM Linux

Post by Kukjin Kim
If every ARMv7 SoCs have VIPT non-aliasing d-cache and i-cache, then no
problem. But actually, Samsung S5PV310(cortex-A9) has PIPT d-cache and VIPT
non-aliasing i-cache. I think PIPT does not mean VIPT non-aliasing even
though their functionality is similar.

There is no visible difference between a non-aliasing VIPT cache and a
PIPT cache. Address bit allocation for a 32-byte cache line VIPT
[0:1] = byte offset into word
[4:2] = word offset
[N-1:5] = virtual index
[31:N] = physical tag
where N <= PAGE_SHIFT, otherwise it would be an aliasing VIPT cache.
[0:1] = byte offset into word
[4:2] = word offset
[M-1:5] = physical index
[31:M] = physical tag
where M doesn't matter as it can never alias with itself.
The requirements for N is such the CPU visible conditions which qualify a
cache as being VIPT non-aliasing also satisfy PIPT - and a non-aliasing
VIPT cache has the same properties as a PIPT cache.

Thanks for your reply :-)

You mean PIPT is the same as VIPT non-aliasing.
Hmm..there is no need to show exactly cachetype in the kernel boot message?

Thanks.

Best regards,
Kgene.
--
Kukjin Kim <***@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.

[Russell King - ARM Linux]

Post by Kukjin Kim

Post by Russell King - ARM Linux
The requirements for N is such the CPU visible conditions which qualify a
cache as being VIPT non-aliasing also satisfy PIPT - and a non-aliasing
VIPT cache has the same properties as a PIPT cache.

Thanks for your reply :-)
You mean PIPT is the same as VIPT non-aliasing.

No, because that's not the case - they are different at the hardware
level. At the software level, they can be treated the same though.

Post by Kukjin Kim
Hmm..there is no need to show exactly cachetype in the kernel boot message?

The boot message shows how the kernel drives the cache, not what the
actual cache is - which is far more informative about what the kernel
is doing.

We can find out what the hardware is by looking in specification docs;
we don't need the kernel to tell us that.

[Kukjin Kim]

Post by Russell King - ARM Linux

Post by Kukjin Kim

Post by Russell King - ARM Linux
The requirements for N is such the CPU visible conditions which qualify a
cache as being VIPT non-aliasing also satisfy PIPT - and a

non-aliasing

Post by Russell King - ARM Linux

Post by Kukjin Kim

Post by Russell King - ARM Linux
VIPT cache has the same properties as a PIPT cache.

Thanks for your reply :-)
You mean PIPT is the same as VIPT non-aliasing.

No, because that's not the case - they are different at the hardware
level. At the software level, they can be treated the same though.

Yes, you're right. I meant from a functionality point of view in the Linux
kernel.

Post by Russell King - ARM Linux

Post by Kukjin Kim
Hmm..there is no need to show exactly cachetype in the kernel boot message?

The boot message shows how the kernel drives the cache, not what the
actual cache is - which is far more informative about what the kernel
is doing.

I see.

Post by Russell King - ARM Linux
We can find out what the hardware is by looking in specification docs;
we don't need the kernel to tell us that.

I agree with you in principle.
But I think, it would be helpful to someone if it could be shown more exact
feature in the kernel boot message especially in this case, it differs with
actual hardware information.

Thanks.

Best regards,
Kgene.
--
Kukjin Kim <***@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.

[Russell King - ARM Linux]

Post by Kukjin Kim
I agree with you in principle.
But I think, it would be helpful to someone if it could be shown more exact
feature in the kernel boot message especially in this case, it differs with
actual hardware information.

I disagree. What's interesting is how the kernel drives the cache,
not what the cache actually is - what you want to know is "the docs
say that it's a X cache, is the kernel driving it correctly" not
"can the kernel decode the cache type register and tell me what the
documentation says the cache is".

The former is what the kernel tells you today. The latter is useless
to working out if the kernel is doing the right thing, and is just a
proof that you can decode register values to strings.

[Kukjin Kim]

Post by Russell King - ARM Linux

Post by Kukjin Kim
I agree with you in principle.
But I think, it would be helpful to someone if it could be shown more exact
feature in the kernel boot message especially in this case, it differs with
actual hardware information.

I disagree. What's interesting is how the kernel drives the cache,
not what the cache actually is - what you want to know is "the docs
say that it's a X cache, is the kernel driving it correctly" not
"can the kernel decode the cache type register and tell me what the
documentation says the cache is".

Ok..I see. :-) so as I said, agree with your opinion.

Post by Russell King - ARM Linux
The former is what the kernel tells you today. The latter is useless
to working out if the kernel is doing the right thing, and is just a
proof that you can decode register values to strings.

Anyway, thanks for your kindly description.

Best regards,
Kgene.
--
Kukjin Kim <***@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.