Hi! I'm trying to get something to work on iwg20m, but ... something is very slow. https://lava.ciplatform.org/scheduler/job/1552 downloading https://s3-us-west-2.amazonaws.com/download.cip-project.or

Hi! 4.19.50-cip3-rt1 should be available at kernel.org. I did limited testing, but it seems to have some bugs fixed relative to 4.19.13-cip1-rt1. (Boots on x86-32 and cyclictest on iwg20m does not hit

Hi! Its first realtime release based on 4.19.50-cip3 :-). It is also based on 4.19.50-rt22. So yes, the naming is a bit confusing. If such version would previously be named -rt2, I'll obviously need t

Hi! Oh and BTW testing would be very welcome. I tried testing it on my thinkpad X60, but it is not suitable hardware; latency goes over 1msec quite easily. But I've seen 3msec with iwg20m board, too.

Hi! Thanks, applied and pushed out. Sorry for the delay. Pavel

Thanks, applied to 4.4-cip, and pushed out. Pavel

Hi! I went ahead, and applied this to linux-4.19.y-cip-rt-rebase branch, too. If it is easy to add that one to testing, it would be nice. Best regards, Pavel

Hi! First, you did a lot of work there... Ok, this is rather long/big series, and some parts are quite scary: https://gitlab.com/bijud/pcf85263/blob/master/0013-rtc-nvmem-allow-registering-the-nvmem-d

Hi! (List added to the cc). Thanks for all the help! I got -cip-rt kernel to work on EBV Socrates, and it seems to be suitable machine for testing. Latencies are under 70 usec under normal loads. They

Hi! I'm looking into it. I have -rt-rebase based on v4.4.179-rt181-cip34-rebase (close to what you want but not quite there; I can publish it if it would be useful), but duplicating same result with m

Hi! Do you want 4.4.184, too, which fixes the SACK fixes? :-). I'm up-to 4.4.179-rt181-cip32. If I attempt to move forward to 4.4.181-cip3, I get some conflicts in rather core files. Auto-merging kern

Hi! Ok, let me take a look. I assume the series are independent? Best regards, Pavel

Aha, you actually annotated series with dependencies. Thanks! I have some minor comments here, but overall series is good and I'll probably apply it tommorow if noone objects. Best regards, Pavel

This looks good to me. Best regards, Pavel

Hi! Thanks for the series. It looks fine to me. Best regards, Pavel

Hi! This is a bit unusual. I'd expect the the lock to be in data structure describing the hardware... but maybe the hardware abstraction here is so simple that we can get away with this. Best regards,

Hi! You still store "parent_rate" in "unsigned long". That is going to overflow on 32-bit systems, right? Best regards, Pavel

Hi! This is not quite correct english, but I guess it is too late to fix that. Best regards, Pavel

Hi! Thanks. Applied and pushed out. Best regards, Pavel

Thanks; applied and pushed out. Best regards, Pavel