<swiftgeek>
t3st3r: i will try to not facepalm too hard
<t3st3r>
at least its "sdio" things and "sdr" (wow, I haven't even thought they could THAT)
<swiftgeek>
this is spectral stuff
<swiftgeek>
oh but pretty decent in performance, interesting
<t3st3r>
from what I see it allows one to synthesize arbitrary signal or so
<swiftgeek>
t3st3r: well that's why i said spectral
<swiftgeek>
t3st3r: you use that to 1. certify device 2. find bess channel for link on both sides
<swiftgeek>
*best
<swiftgeek>
but i never saw anyone trying to recreate 802.11 frame from it, that's fun xD
<swiftgeek>
t3st3r: any idea what they have recreated ?
<swiftgeek>
802.11b/g/n ?
<t3st3r>
well, from what I remember, many devices are implemented like that - high speed ADC/DAC and I/Q to radio frontend, but most things do not allow one to touch ADC/DAC directly.
<swiftgeek>
t3st3r: ofc they allow
<swiftgeek>
you wouldn't be able to certify device XD
<t3st3r>
why do you have to touch ADC/DAC directly to certify?
<swiftgeek>
how else you are going to do it
leviathan has joined #linux-sunxi
<swiftgeek>
i guess you could bake some test routine into chip but that would be mad
<t3st3r>
in ath9k it seems there is some special mode for continious emission and so on, but it does not looks like if it deals with i/q samples or so
<swiftgeek>
t3st3r: every chip i know of has that feature one way or the other :P
<swiftgeek>
it's not always exposed to the user but it's always there for certification
<swiftgeek>
so FCC knows that in worst possible scenario the device isn't jamming something important outside of ISM
<t3st3r>
ath9k looks more or less like hardware automation, but it internally got ADC/DAC things. Since most things doing RF that way.
<t3st3r>
they can't know it for sure in case of ADC+DAC :)
<swiftgeek>
well they can since you are driving it directly
<t3st3r>
most constraints are calibrations/firmware/etc and one can get well beyond that stuff
<swiftgeek>
and with that you bypass firmware and software calibrations
<swiftgeek>
which is what matters for fcc
<swiftgeek>
it's a bit like absolute maximum ratings ^^
<t3st3r>
I can imagine one can well exceed what FCC willing to tolerate by re-programming freq synth and soing arbitrary modulations using DAC directly.
<swiftgeek>
t3st3r: this is why you have filters on analog frontend
<t3st3r>
I can imagine there are "analog" filters to get rid of out of band emissions, but they would only be anyhow efficient for freqs far away of target ones.
<[7]>
heh that mmc0_sample looks like a typo somehow - but no idea where it's coming from, apparently not from the device tree
<BenG83>
so it's set to 1008Mhz
<BenG83>
btw there is a small tool to measure cpu frequency exactly from willy tarreau
<[7]>
I'm currently less interested in the CPU clocking (although getting some ondemand scaling working there would be nice) than in getting the AHB/APB clocks set up right to get reasonable SPI speed
<[7]>
so from what this looks like, the AHB-side clock of the SPI is already okay, it's just the "module" clock that should be coming from somewhere else
<BenG83>
yeah seems like it's just clocked from the XTAL
<[7]>
btw, ehere does this summary file come from? is it read back from hardware control regs or just based on some internal assumptions of the kernel based on the device tree?
<[7]>
where*
<BenG83>
I guess from the clock-ng framework
<BenG83>
probably what is in the registers
<[7]>
is it possible to configure these clocks (e.g. CPU, AHB, ...) in the device tree?
<BenG83>
should be
<BenG83>
the ccu node
<[7]>
there's a lot of stuff in Documentation/devicetree/bindings/clock/sunxi.txt but I haven't quite figured out what actually applies to H3 and how it needs to be configured
<BenG83>
maybe it's also configured from the SPI node?
<BenG83>
if you request a max speed that is >24Mhz?
<BenG83>
what is the limit on H3?
<[7]>
I'd think 100MHz bus clock, which requires a 200MHz mod clock
<[7]>
as far as I can tell there's no "intelligence" in the system that choses a fitting clock, it just takes whatever it gets as mod clk and then tries its best to reach the requested output clock
<[7]>
yes, that's what I have (other than that I have 40MHz clock in there)
<[7]>
anyway, it seems like a ton of clocking relationships is still defined in kernel code somewhere? it seems to know a *lot* more than what's actually in the device tree
<BenG83>
I guess clk_summary is just the state of the CCU
<BenG83>
and whatever is in those registers after reset as a default if it isnt set from devicetree
<[7]>
hmmm... just realized that on 4.16-rc6 the whole mtd node for the flash is missing as well
<BenG83>
what board?
<[7]>
orange pi zero
<[7]>
but with a custom device tree
<[7]>
that used to work on 4.15 though...
<BenG83>
is the spi flash mounted by default?
<BenG83>
I think my zero doesnt actually have one on the PCB
<[7]>
the newer ones do
<BenG83>
ah ok
<[7]>
the older ones only had it on the 512MB model
<ElBarto>
iirc it was optional
<ElBarto>
I'm pretty sure that my 512MB one doesn't have spi populated
<BenG83>
I use the SPI flash on the SOPine and there it works ok
<BenG83>
but I think at 24Mhz atm
<BenG83>
but to load u-boot that's not too bad
<BenG83>
if you load a kernel image from flash that maybe a bit slow
<BenG83>
afaik the SPI flash driver for u-boot is not upstream anyways
<[7]>
yeah but that part I've figured out already ;)
<[7]>
IIUC this should work in linux if I just specify compatible="jedec,spi-nor";?
<BenG83>
look at my spi example from my Rock64 above
<[7]>
yeah, I also had a couple other chip names in there, but IIUC those are just ignored anyway
<BenG83>
the basic read/write commands are mostly the same across those spi flash devices
jstein_ has joined #linux-sunxi
jstein_ is now known as jstein
<BenG83>
but some of the higher performance read/write commands need device specific handling
<[7]>
the driver seems to be identifying the chip based on interrogating its ID, not based on the aliases in the DT
<BenG83>
I guess the device specific compatible is mostly to add quirks to the driver if necessary
<BenG83>
should something come up in the future
LargePrime has joined #linux-sunxi
<[7]>
comments in the driver suggest that it's legacy, but people seem to keep using it for some reason
<[7]>
so if I wanted to change the CPU/DRAM clock, how would I do that through the DT?
<[7]>
and how would I get runtime DVFS / cpufreq working?
<BenG83>
you need to grab one of the wip branches for DVFS
<BenG83>
and the thermal driver
<BenG83>
then you can add opps to the dts
<BenG83>
and thermal zones
<BenG83>
not sure how much of it works for H3 already
<BenG83>
embed3 is away for exams and his thesis work afaik
<BenG83>
maybe shoot him a mail
<[7]>
and if I want to configure static values, is that already working in 4.16?
<BenG83>
I think you need to go via u-boot atm
<BenG83>
the clock should be in the config
<[7]>
yeah, I have a custom u-boot anyway, I had just hoped to be able to change it without having to reflash the bootloader
<[7]>
and I don't think u-boot can pick it from the environment - this is possibly even done in SPL already