**** BEGIN LOGGING AT Tue Jun 25 03:00:38 2019
Jun 25 09:15:16 <julieng> embden[m]: I just read your weekly progress. How can I help on the blockers?
Jun 25 09:18:36 <embden[m]> julieng  I want to understand how Linux setup clock
Jun 25 09:22:17 <julieng> embden[m]: Did you have a chance to look at realtime_counter_init()?
Jun 25 09:24:45 <embden[m]> julieng:  yes, I always get a feeling that it takes the value from somewhere but I can't find the place where it installs those values
Jun 25 09:27:05 <julieng> embden[m]: AFAICT, this is written towards the end of the function (see calls to writel_relaxed).
Jun 25 09:28:02 <julieng> embden[m]: They also compute the frequency and store in arch_timer_freq.
Jun 25 09:28:59 <julieng> This value will be then used by set_cntfreq() to update the register CNTFREQ (this is done via a SMC as the register can only be modified from secure mode).
Jun 25 09:29:41 <embden[m]> julieng: yes, I can see it. I don't understand from where they take the rate and why they first take installed values and the rewrite them
Jun 25 09:34:49 <julieng> embden[m]: The rate is taken from the clock sys_clkin (probably from the DT).
Jun 25 09:35:40 <julieng> For the last bits, I guess you speak about r = readl(...); r |= val; writel(...) part.
Jun 25 09:36:42 <julieng> I don't know the board, but my guess is we only want to modify part of the register.
Jun 25 09:37:21 <julieng> So you read the content, remove what you want to modify, modify it, and then write.
Jun 25 10:40:32 <embden[m]> julieng:  so, I should write a value to DT, then read it, install numerator and denumerator into appropriate regs and then install the value from DT*num/denum (which should be 20 MHz from what I can see in Linux code) to CNTRFRQ
Jun 25 10:52:32 <julieng> embden[m]: The value in the device-tree should already be present.
Jun 25 10:58:02 <julieng> embden[m]: For Xen, I think you can extend num_den to also put the clock rate in it.
Jun 25 10:58:19 * embden[m] sent a long message:  < https://matrix.org/_matrix/media/v1/download/matrix.org/ZQTVQuQSVxKsXWZVGuiWPhAk >
Jun 25 11:57:13 <julieng> embden[m]: matrix converts long message into link. So apritzel may not be notified of the message.
Jun 25 12:29:35 <pratimugale[m]> zeekhuge abhishek_ Today I was able to create a multi channel pwm example that takes duty cycle as input from the ARM (using the daemon) into the shared memory. I haven't figured out how to toggle different gpios at different frequencies yet. - because the delay_cycles() function interferes with other gpios. I'm working on solving this now.
Jun 25 12:34:40 <embden[m]> apritzel:  ^
Jun 25 12:36:52 <apritzel> embden[m]: indeed the relation between the clocks is quite puzzling
Jun 25 12:37:31 <apritzel> typically use can learn much more about by looking at /sys/kernel/debug/clk
Jun 25 12:37:55 <apritzel> especially clk_summary should give you some clue how those clocks depend on each other
Jun 25 12:38:24 <apritzel> and should answer the question which clock sysclk_in actually is
Jun 25 12:38:55 <apritzel> I couldn't find an easy match in the DT
Jun 25 12:39:10 <apritzel> the closest clock I could find is some fixed clock at 22.something MHz
Jun 25 12:40:00 <apritzel> embden[m]: I was wondering how variable the arch timer clock source really is, at least on this board
Jun 25 12:40:12 <apritzel> because typically it's a fixed frequency
Jun 25 12:41:54 <apritzel> so if you know what Linux uses for the rate, you could just put that value in the DT as clock-frequency and be done, at least for now
Jun 25 12:45:10 <embden[m]> apritzel: that's what I did and it kind of works but it doesn't work like in Linux. So, I want to find out what is the correct mapping between Linux behavior and Xen's one
Jun 25 12:48:02 <Abhishek_1> pratimugale :  after solving the problem, you could try if you can have the same thing working with rpmsg
Jun 25 12:48:18 <embden[m]> I mean Xen reads a value from DT and use it but Linux reads another value from DT (sysclk_in) and modifies it to find out the resulting value of 6.144 MHz.
Jun 25 12:48:23 <embden[m]> guest
Jun 25 12:48:40 <embden[m]> the "guest" message is occaisional*
Jun 25 12:49:01 <embden[m]> I will try to produce something during the next 10 hours
Jun 25 12:51:02 <pratimugale[m]> <Abhishek_1 "pratimugale :  after solving the"> abhishek_: ok, I will add rpmsg too
Jun 25 12:54:53 <apritzel> embden[m]: I see the Linux code as a hack, because actually it's the responsibility of the firmware to setup CNTFREQ
Jun 25 12:55:23 <apritzel> for whatever reason they don't do it in their BootROM, so U-Boot would be the next best thing to do it
Jun 25 12:55:58 <apritzel> but U-Boot has no notion of the secondary cores, so we can't easily fix that
Jun 25 12:58:39 <apritzel> the ARM arch timer spec requires the counter frequency to be fixed, so it can't change at runtime
Jun 25 12:59:29 <apritzel> so I guess the Linux code is just using the old approach of "ignore firmware, do everything in the kernel"
Jun 25 13:01:12 <apritzel> embden[m]: re: "how 24 MHz on-board oscillator is transformed to 20 MHz COUNTER_REALTIME?"
Jun 25 13:01:25 <apritzel> embden[m]: hopefully you can find that out from clk_summary
Jun 25 13:02:04 <apritzel> typically people use a PLL to generate a high rate clock (say 1.2GHz) from the 24MHz oscillator
Jun 25 13:02:26 <apritzel> then have several dividers which are being fed by that PLL
Jun 25 13:02:44 <apritzel> because dividers are much cheaper and easier
Jun 25 13:03:27 <apritzel> embden[m]: can you post the clk_summary output somewhere?
Jun 25 13:06:10 <embden[m]> apritzel: ok, but I'll do it in 5 hours
Jun 25 13:06:21 <apritzel> embden[m]: sure, no rush ...
Jun 25 15:40:13 <cwicks[m]> pratimugale: and pranav_kumar   Please remember to put in your student evaluations.  You have some time today/tomorrow morning. Please don't leave it until the last minutes.
Jun 25 15:40:29 <cwicks[m]> thank you vaishnav98_ and embden for putting in your student evaluations already.
Jun 25 15:41:22 <pranav_kumar[m]> <cwicks[m] "pratimugale: and pranav_kumar   "> Ok i will do it today
Jun 25 16:07:34 <pratimugale[m]> cwicks: Completed the evaluation
Jun 25 20:46:34 <embden[m]> julieng:  might be interesting for you, Linux output of clk_summary: https://pastebin.com/xdxkw6TP
Jun 25 21:18:23 <pranav_kumar[m]> @cwicks:matrix.org:  completed the evaluation
Jun 25 21:31:15 <ds2> pranav_kumar[m]: thanks for the docs. Can you point me to the code?
Jun 25 21:48:21 <embden[m]> julieng:  ds2  one thing I can't understand is why in https://github.com/torvalds/linux/blob/master/arch/arm/mach-omap2/timer.c#L697 first the value is read and then ORed with a new value?
Jun 25 21:49:12 <ds2> embden[m]: Read Modify Write so it just adds the bits rather then overwritting it
Jun 25 22:42:25 <embden[m]> ds2: I understand but why not to overwrite? what if there is already some garbage bits?
**** ENDING LOGGING AT Wed Jun 26 02:59:57 2019