ChanServ changed the topic of #armlinux to: ARM kernel talk [Upstream kernel, find your vendor forums for questions about their kernels] | https://libera.irclog.whitequark.org/armlinux
amg_project has quit [Quit: Leaving]
mraynal has quit [Remote host closed the connection]
mraynal has joined #armlinux
apritzel_ has quit [Ping timeout: 268 seconds]
m5_ has quit [Ping timeout: 260 seconds]
krzk has quit [Ping timeout: 244 seconds]
krzk has joined #armlinux
ajfriesen1645 has joined #armlinux
ajfriesen164 has quit [Ping timeout: 272 seconds]
ajfriesen1645 is now known as ajfriesen164
jclsn has quit [Ping timeout: 272 seconds]
jclsn has joined #armlinux
krzk has quit [Ping timeout: 252 seconds]
krzk has joined #armlinux
<wens> looking at existing code, I assume it is OK to cast and drop the __iomem qualifier on pointers returned by ioremap_wc() for blocks of DRAM or SRAM. Is that true?
<wens> I looked at a couple remoteproc drivers
m5_ has joined #armlinux
m5_ has quit [Ping timeout: 248 seconds]
m5_ has joined #armlinux
heat has quit [Ping timeout: 272 seconds]
m5_ has quit [Read error: Connection reset by peer]
m5_ has joined #armlinux
m5_ has quit [Ping timeout: 272 seconds]
m5_ has joined #armlinux
nsaenz has joined #armlinux
prabhakalad has quit [Ping timeout: 268 seconds]
prabhakalad has joined #armlinux
nsaenz has quit [Ping timeout: 248 seconds]
Lucanis has joined #armlinux
System_Error has quit [Remote host closed the connection]
Lucanis has quit [Ping timeout: 268 seconds]
System_Error has joined #armlinux
Lucanis has joined #armlinux
mvaittin_ has joined #armlinux
System_Error has quit [Remote host closed the connection]
System_Error has joined #armlinux
<arnd> wens: in portable code, casting __iomem is not ok.
<arnd> if you want to map something that is not an MMIO register, you should use memremap() as the portable way to give you a pointer you can dereference
<arnd> If you just want to access it as RAM, then you usually want a cacheable map (MEMREMAP_WB) rather than write-combining (MEMREMAP_WC)
<arnd> it gets a lot trickier if there is another device that may do DMA on the same memory
<wens> ack. it's ww1
<wens> it's a remoteproc driver for an onboard coprocessor, so likely not portable
System_Error has quit [Remote host closed the connection]
<arnd> wens: so is this buffer part of system RAM, or some special SRAM that is part of the coprocessor?
<wens> there's both
<wens> one block is in system RAM, the other is in some TCM (tightly coupled memory)
System_Error has joined #armlinux
<arnd> TCM is a third option, I think we've thrown out most of the TCM infrastructure over time as it was rarely used
monstr has joined #armlinux
<arnd> For the part in system RAM, there should be a way to make that appear as the backing for dma_alloc_coherent(), we used to do that with dma_declare_coherent_memory() but I forget what the devicetree equivalent of that is
<arnd> assuming the device uses cache-coherent DMA, that should give you a cacheable mapping as well, which would be faster
<arnd> for the TCM, I think you need an uncached (PROT_NORMAL_NC) mapping, so probably MEMREMAP_WC is the closes approximation
<arnd> In both cases, you probably need explicit dma_wmb()/dma_rmb() barriers when accessing the memory with a pointer if you need to serialize accesses against the device
apritzel_ has joined #armlinux
monstr has quit [Ping timeout: 252 seconds]
<wens> DT equiv: memory-region pointing to a reserved memory node w/ "???-dma-pool"?
apritzel_ has quit [Ping timeout: 245 seconds]
CounterPillow has quit [Quit: Bye.]
CounterPillow has joined #armlinux
cbeznea has joined #armlinux
clegoffic has joined #armlinux
clegoffic has quit [Changing host]
clegoffic has joined #armlinux
prabhakalad has quit [Remote host closed the connection]
prabhakalad has joined #armlinux
LainExperiments has joined #armlinux
LainExperiments5 has joined #armlinux
LainExperiments has quit [Ping timeout: 240 seconds]
nsaenz has joined #armlinux
rvalue has quit [Ping timeout: 248 seconds]
LainExperiments5 has quit [Ping timeout: 240 seconds]
LainExperiments has joined #armlinux
rvalue has joined #armlinux
frieder has joined #armlinux
luispm has joined #armlinux
apritzel has joined #armlinux
monstr has joined #armlinux
jn has quit []
jn has joined #armlinux
sszy has joined #armlinux
fancer has joined #armlinux
<robmur01> wens: yup, shared-dma-pool is the one
<bjdooks> today will mostly be fixing proprierary software's config scripts as newer gccs cause it to fail to configure properly
fancer has quit [Quit: Konversation terminated!]
fancer has joined #armlinux
dliviu has quit [Quit: Going away]
heat has joined #armlinux
dliviu has joined #armlinux
LainExperiments2 has joined #armlinux
LainExperiments4 has joined #armlinux
LainExperiments has quit [Ping timeout: 240 seconds]
LainExperiments2 has quit [Ping timeout: 240 seconds]
System_Error has quit [Remote host closed the connection]
System_Error has joined #armlinux
LainExperiments has joined #armlinux
LainExperiments4 has quit [Ping timeout: 240 seconds]
nsaenz has quit [Remote host closed the connection]
jn has quit [Ping timeout: 244 seconds]
jn has joined #armlinux
LainExperiments3 has joined #armlinux
LainExperiments has quit [Ping timeout: 240 seconds]
LainExperiments2 has joined #armlinux
LainExperiments has joined #armlinux
sibis has quit [Remote host closed the connection]
LainExperiments3 has quit [Ping timeout: 240 seconds]
CounterPillow has quit [Quit: Bye.]
LainExperiments2 has quit [Ping timeout: 240 seconds]
CounterPillow has joined #armlinux
fancer has quit [Quit: Konversation terminated!]
nsaenz has joined #armlinux
fancer has joined #armlinux
fancer has quit [Client Quit]
fancer has joined #armlinux
LainExperiments has quit [Quit: Client closed]
LainExperiments has joined #armlinux
aneesh has joined #armlinux
<aneesh> I am wondering why we look at MMFR4_EL1.E2H0 to decide ARM64_HAS_HCR_NV1 capability. I might be missing some assumption there. If i rename ARM64_HAS_HCR_NV1 to something like ARM64_HAS_E2H0_FEAT, i find code more easy to follow. Something like
<aneesh> @@ -2976,11 +2980,11 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
<aneesh> .matches = test_has_mpam_hcr,
<aneesh> },
<aneesh> -.desc = "NV1",
<aneesh> {
<aneesh> -.capability = ARM64_HAS_HCR_NV1,
<aneesh> +.desc = "Programming ability of E2H",
<aneesh> +.capability = ARM64_HAS_E2H0_FEAT,
<aneesh> .type = ARM64_CPUCAP_SYSTEM_FEATURE,
<aneesh> -.matches = has_nv1,
<aneesh> -ARM64_CPUID_FIELDS_NEG(ID_AA64MMFR4_EL1, E2H0, NI_NV1)
<aneesh> +.matches = has_e2h0_feat,
<aneesh> +ARM64_CPUID_FIELDS(ID_AA64MMFR4_EL1, E2H0, IMP)
<aneesh> },
<aneesh> #ifdef CONFIG_ARM64_POE
<aneesh> {
<aneesh> modified arch/arm64/kvm/n
<aneesh> @@ -1843,8 +1843,12 @@ static bool unmap_kernel_at_el0(const struct arm64_cpu_capabilities *entry,
<aneesh> return !meltdown_safe;
<aneesh> }
<aneesh>
<aneesh> -static bool has_nv1(const struct arm64_cpu_capabilities *entry, int scope)
<aneesh> +static bool has_e2h0_feat(const struct arm64_cpu_capabilities *entry, int scope)
<aneesh> {
<aneesh> +/*
<aneesh> + * Fruity CPUs seem to have HCR_EL2.E2H set to RAO/WI, but
<aneesh> + * don't advertise it (they predate this relaxation).
<aneesh> + */
<aneesh> /*
<aneesh> * Although the Apple M2 family appears to support NV1, the
<aneesh> * PTW barfs on the nVHE EL2 S1 page table format. Pretend
<aneesh> @@ -1864,7 +1868,7 @@ static bool has_nv1(const struct arm64_cpu_capabilities *entry, int scope)
<aneesh> dump_stack();
<aneesh>
<aneesh> return (__system_matches_cap(ARM64_HAS_NESTED_VIRT) &&
<aneesh> -!(has_cpuid_feature(entry, scope) ||
<aneesh> +(has_cpuid_feature(entry, scope) ||
<aneesh> is_midr_in_range_list(read_cpuid_id(), nv1_ni_list)));
<aneesh> }
<aneesh>
<aneesh> That make the rest of the place where we check for NV1 cap to update HCR_EL2.E2H use E2H0_FEAT
<aneesh> ie,
<aneesh> -if (!cpus_have_final_cap(ARM64_HAS_HCR_NV1))
<aneesh> +/* if we can't mark E2H 0 consider it RES1 */
<aneesh> +if (!cpus_have_final_cap(ARM64_HAS_E2H0_FEAT))
<aneesh> val |= HCR_E2H;
<aneesh> Any reason we name that NV1 cap instead of E2H0_FEAT cap
<aneesh> Also can MMPRF4_EL1.E2H value 0 and value -1 indicate NV1 capability?
LainExperiments has quit [Quit: Client closed]
<aneesh> Sorry i meant can MMFR4_EL1 value between -8 -> -3 indicate NV1 capability? (-2 implies NV1 is RES0)
<javierm> aneesh: please use a paste service when pasting big chunks of text
LainExperiments has joined #armlinux
psydroid2 has joined #armlinux
sibis has joined #armlinux
System_Error has quit [Remote host closed the connection]
System_Error has joined #armlinux
<maz> aneesh: we do that because that's how the spec is written?
<maz> also, aside from the IRC pollution, these questions are better asked on the list.
<aneesh> sure.
<maz> also, detecting this late whether E2H can be written to is pretty pointless. If we made it that far, we have a precise idea of that state.
<maz> by the time that code you find unbearable gets run, we're firmly with a final value of E2H that will *never* change.
<aneesh> didn't follow that. The diff i shared do that as part of capability update. So it is early. What did in the diff is instead of calling it NV1 cap, i am wondering whether we should name it E2H update capability?
<maz> no, it is fsckin late. *very* late.
<maz> we already use that state in the first 10 instructions at boot time. *that* early.
<maz> just look at init_kernel_el.
<maz> and NV1 is really NV1. that's what KVM wants to know.
<maz> we want to know whether HCR_EL2.NV1 is RES0 or not. that's the only thing we are interested about.
<aneesh> does a value of MMFR4.EL1 value of -3 indicate NV1 RES0?
<aneesh> ie, 0b1101
<maz> there is no such field in ID_AA64MMFR4_EL1. what field are you talking about?
monstr has quit [Ping timeout: 252 seconds]
<maz> if you are talking about the E2H0 field, then any negative value removes functionalities from the value strictly higher.
<maz> so E2H0 implemented = 0, E2H0 not implemented = -1; E2H not implemented *and* NV1 not implemented = -2.
LainExperiments has quit [Quit: Client closed]
<maz> if the architecture decide to remove something else (no idea what), -3 will still not have E2H0 nor NV1.
<aneesh> ok. got that.
LainExperiments has joined #armlinux
mvaittin_ has quit [Ping timeout: 248 seconds]
LainExperiments9 has joined #armlinux
LainExperiments has quit [Ping timeout: 240 seconds]
aneesh has quit [Quit: Leaving]
LainExperiments9 has quit [Ping timeout: 240 seconds]
LainExperiments has joined #armlinux
LainExperiments has quit [Ping timeout: 240 seconds]
dmart has joined #armlinux
fancer has quit [Quit: Konversation terminated!]
headless has joined #armlinux
sszy has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
frieder has quit [Remote host closed the connection]
headless has quit [Quit: Konversation terminated!]
apritzel has quit [Ping timeout: 265 seconds]
fvincenzo has quit [Quit: Lost terminal]
fvincenzo has joined #armlinux
siak has joined #armlinux
fancer has joined #armlinux
nsaenz has quit [Remote host closed the connection]
nsaenz has joined #armlinux
nsaenz has quit [Remote host closed the connection]
nsaenz has joined #armlinux
nsaenz has quit [Ping timeout: 272 seconds]
fancer has quit [Quit: Konversation terminated!]
tscherer has quit [Quit: WeeChat 3.8]
tscherer has joined #armlinux
siak has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
System_Error has quit [Remote host closed the connection]
cbeznea has quit [Ping timeout: 248 seconds]
System_Error has joined #armlinux
psydroid2 has quit [Quit: KVIrc 5.2.6 Quasar http://www.kvirc.net/]
apritzel_ has joined #armlinux
nsaenz has joined #armlinux
nsaenz has quit [Ping timeout: 272 seconds]
sihloo_ has joined #armlinux
sihloo has quit [Ping timeout: 260 seconds]