diff options
Diffstat (limited to 'wiki/Chat_log/20150929-core-chatlog')
| -rw-r--r-- | wiki/Chat_log/20150929-core-chatlog | 456 |
1 files changed, 456 insertions, 0 deletions
diff --git a/wiki/Chat_log/20150929-core-chatlog b/wiki/Chat_log/20150929-core-chatlog new file mode 100644 index 0000000..73b2a81 --- /dev/null +++ b/wiki/Chat_log/20150929-core-chatlog @@ -0,0 +1,456 @@ +11:04 < geertu> Agenda: +11:04 < geertu> 1. Upcoming Gen3 development for the Core group, +11:04 < geertu> 2. "clock-output-names", +11:04 < geertu> 3. [PATCH/RFC v2 0/4] Renesas CPG/MSTP DT Binding Proposal, +11:04 < geertu> 4. sh-pfc, +11:04 < geertu> 5. Status check for tasks from last meeting - what is remaining? +11:04 < geertu> Topic 1. Upcoming Gen3 development for the Core group +11:05 < dammsan> I'm poking around with IPMMU +11:05 < geertu> Good to hear +11:05 < geertu> Is it fun? +11:05 < dammsan> well... +11:05 < dammsan> there is some external patch series that enabled IOMMU for arm64 +11:06 < dammsan> so we have a dependency there +11:06 < dammsan> and on gen3 there is FCPVD +11:06 < dammsan> together with VSPD +11:06 < dammsan> and i noticed that on Gen2 the DU is tied to two micro-tlbs +11:07 < dammsan> on R-Car H2 +11:07 < dammsan> so we may need to rework the driver slightly to support that +11:07 < dammsan> anyway, i intend to post some prototype patches later on this weekk +11:09 < horms> what is the origin of the "external patch series" and what it its status? +11:10 < dammsan> [PATCH v5 0/3] arm64: IOMMU-backed DMA mapping +11:10 < dammsan> by Robin Murphy from ARM +11:10 < dammsan> at this point I am mainly interested in testing the hardware +11:11 < dammsan> and adjusting the driver on a prototype basis if needed +11:11 < dammsan> but over time we may have to step up and contribute to fix the architecture and subsystem perhaps +11:11 < horms> ok, seems likely +11:12 < dammsan> but mr conspiracy-theory thinks this must be highly political +11:12 < dammsan> and a perfect way to block progress +11:12 < horms> why else whould something exist? +11:12 < dammsan> right =) +11:13 < dammsan> this may give us some time to fix up Gen2 though +11:14 < horms> no problems; only opportunities +11:15 < dammsan> so IPMMU and the IOMMU subsystem needs some attention for sure at least +11:15 < dammsan> together with that DMA Engine with IOMMU issue +11:15 < geertu> Any feedback about that from the hardware team? +11:15 < dammsan> not yet +11:15 < dammsan> i have not pinged them yet +11:16 < dammsan> but i did not trigger any issue once i implemented that identity mapping hack +11:16 < dammsan> so we likely have a mix of both hardware and software issues +11:16 < dammsan> and now lacking architecture support as well +11:16 < dammsan> =) +11:16 < geertu> software we can fix +11:17 < dammsan> so we should fix up the IOMMU and DMAC framework issue somehow +11:17 < dammsan> and in case of hardware issues on Gen2 +11:17 < dammsan> it is most likely too late to fix anything there anyway +11:18 < dammsan> in hardware i mean +11:18 < dammsan> so i think we should focus on fixing the software +11:19 < dammsan> once we've gotten the CPG in a better state then i would like to spend most of my time on IPMMU +11:19 < dammsan> hopefully that would move things forward +11:20 < dammsan> btw, +11:20 < dammsan> i have now received a package with a bunch of QSE/QTE adapters +11:20 < dammsan> and i'd like to distribute one unit per person +11:20 < geertu> Do they fit? ;-) +11:20 < dammsan> not opened the package yet =) +11:21 < dammsan> i ordered same product as you +11:21 < dammsan> but with bent connectors +11:21 < dammsan> with those adapters I/O development and things like IRQC should be easier to move forward on +11:21 < geertu> So you have to raise the boars more, as they're usually at the bottom +11:22 < geertu> Indeed. Thanks a lot! +11:22 < geertu> s/boars/boards/ +11:22 < dammsan> lets see if they work first =) +11:23 < dammsan> i have no other things related to upcoming development +11:23 < geertu> Anyone else +11:23 < geertu> ? +11:23 < horms> my only item is avb ptp, but that is probably a topic for the i/o group +11:23 < dammsan> oh, if someone could help with the CPG stuff that would of course be nice +11:24 < dammsan> i intend to refresh the series later this week +11:24 < horms> i think that has its own agenda item +11:24 < dammsan> but if someone could offload me then that would be nice +11:24 < dammsan> yeah "clock-output-names" +11:24 < geertu> Topic 2. "clock-output-names" +11:24 < geertu> i.e. CPG +11:25 < geertu> I guess everybody saw the email from Mike Turquette +11:25 < horms> aye +11:25 < dammsan> yeah +11:25 < uli___> mhm +11:25 < dammsan> and the conclusion is? +11:25 < horms> I deffer to dammsan's conspiracy theory +11:25 < dammsan> haha +11:26 < dammsan> at least we can move forward now by using clock-output-names to begin with, right? +11:26 < horms> yes +11:26 < horms> that is my understanding +11:26 < dammsan> or did i misunderstood things? +11:26 < geertu> As I don't think Mike's rework will be in v4.4 (too late), I think we should (re)add clock-putput-names +11:26 < dammsan> good +11:26 < horms> and mike can futs around with his ideas +11:26 < dammsan> yeah, i think so too +11:27 < horms> assuming we do that, what are the next steps, e.g. for v4.4? +11:27 < dammsan> seems pretty clear to me +11:27 < geertu> So people have to resend their integration patches, preferably in the right order to make Simon's work easier +11:27 < horms> yes, ideallt +11:27 < horms> yes, ideally +11:27 < dammsan> may i suggest aligning this update with the new data sheet? +11:27 < horms> though i'm trying a hub-and-spoke appraoach +11:27 < geertu> futs is not in my dictionary, nor in "dict fut"? +11:28 < dammsan> morimoto: when is the new updated datasheet coming? +11:28 < geertu> new data sheet? +11:28 < horms> futs ~= play around with +11:28 < dammsan> yourself? +11:28 < dammsan> =) +11:28 < morimoto> dammsan: there is still no information about datasheet +11:28 < horms> though i'm trying a hub-and-spoke appraoach; so dependencies may not be as bad as you may think +11:29 < geertu> As long as you're adding a new mstp register, it's OK +11:29 < horms> yes +11:29 < geertu> But some patches touch existing MSTP registers, so they may conflict +11:29 < horms> yes +11:29 < horms> that is the hard part +11:29 < dammsan> horms: so what is your plan regards to merging? +11:29 < horms> likewise with dt nodes +11:30 < horms> upstream? +11:30 < dammsan> yeah +11:30 < horms> i think we can start to push things into next +11:30 < horms> and thus towards arnd & the gang +11:30 < dammsan> something in parallel with the PFC and CPGbits? +11:30 < horms> i think that would be idea +11:30 < horms> what do you think? +11:30 < dammsan> sure, just keep it small +11:30 < horms> ok +11:30 < dammsan> i suppose you will get some feedback =) +11:31 < horms> i was thinking of using separate branches for the arm64 work +11:31 < horms> so it can be comented on separeately to the 32bit work +11:31 < dammsan> sounds good +11:31 < geertu> For integration? +11:31 < horms> I will also stock up on various colours of paint +11:31 < geertu> Or for drivers? +11:32 < horms> I was reffering to integration +11:32 < geertu> Since that's arm64, it's indeed best to use a separate branch +11:32 < horms> indeed +11:32 < geertu> or is that not how arm-soc works for mixed arm32/arm64 SoC manufacturers? +11:33 < horms> we will soon find out! +11:33 < geertu> :-) +11:33 < dammsan> geertu: we should focus on cache topology in the not so distant future too +11:33 < horms> I'm pretty sure I will need to make a trip to Google to chat to Olof at some point; thats what it took to get the 32bit stuff flowing nicely +11:33 < geertu> Let's hope they give earlier feedback then for your now-pending pull requests +11:33 < dammsan> i guess that is topic 1 more, sorry for late addition +11:34 < horms> geertu: i am skeptical +11:34 < geertu> (added task "r8a7795,v4.5,Cache topology") +11:35 < horms> dammsan: how about you start by reposting a patchset that you think is appropriate for v4.4? +11:35 < geertu> horms: I have lots of platform_data removal patches waiting for the arm-soc pull completion +11:35 < horms> in relation to that mess +11:35 < geertu> horms: Trip to ELCE? +11:35 < dammsan> horms: i think my latest patchset covers a minimal base pretty well +11:35 < horms> i plan to repost the dt/fixes separately soon +11:36 < dammsan> and i may not have time to resend until after ELCE +11:36 < horms> but i don't know when olof et al.. will actually pull anything +11:36 < horms> dammsan: does it need updating? +11:36 < dammsan> horms: how about i update the CPG series +11:36 < geertu> they seem to be busy with pulling various for-v4.3 stuff +11:36 < geertu> Topic 3. [PATCH/RFC v2 0/4] Renesas CPG/MSTP DT Binding Proposal +11:36 < dammsan> and then add some incremental patch that perhaps you can fold in? +11:37 < geertu> Has anyone read that? +11:37 < horms> geertu: thats nice, seeing that closed about a month ago +11:37 < geertu> I know it may be a bit late, but I was triggered again by some RST discussion +11:38 < geertu> R-Car Gen3 gained many more module stop/status/reset/... registers, now we have up to 10(!) sets +11:38 < horms> is this related to the mode pin (driver) discussion (with Luarent)? +11:38 < dammsan> geertu: i got a bit confused by MSSR? +11:38 < geertu> horms: no +11:39 < dammsan> this is how things are called for Gen2 or Gen3? +11:39 < geertu> 8A. Module Standby, Software Reset +11:39 < horms> ok, could you add that to the agenda, possibly for next time when he is here +11:39 < horms> ? +11:40 < geertu> 8A. Module Standby, Software Reset (Gen3) +11:40 < geertu> 7A. Module Standby and Software Reset (Gen2) +11:40 < dammsan> geertu: but isnt 7. and 8. CPG? +11:41 < geertu> Section 2. Module Standby, Software Reset (APE6) +11:41 < dammsan> I see +11:42 < geertu> yes, 7 and 8 are CPG +11:42 < dammsan> I've never seen MSSR before so I got a bit surprised +11:42 < dammsan> wasn't sure what it was +11:42 < dammsan> but now i understand +11:42 < geertu> The abbreviation is never used in the datasheet +11:42 < dammsan> were you planning on using that for DT compat strings? +11:43 < geertu> Yes, as it must be different from the existing +11:43 < dammsan> i think that was included in your proposal +11:43 < dammsan> geertu: you can match on soc-specific string too, right? +11:44 < geertu> and there would be a single mssr block, not individual blocks for the individual registers (which was the biggest problem for the 10 register sets) +11:44 < geertu> compatible = "renesas,r8a7791-cpg-mssr"; +11:44 < geertu> compatible = "renesas,r8a7795-cpg-mssr"; +11:44 < pinchartl> geertu: I'm in Belgium right now and totally jetlagged, sorry for not joining earlier +11:44 < geertu> Welcome! +11:46 < dammsan> geertu: you remedy the MSTP bit index issue in your proposal, right? +11:46 < dammsan> with split <&mstp5 R8A7790_DU0> +11:46 < geertu> You mean using register and bit index that don't match? +11:46 < dammsan> yeah +11:46 < dammsan> exactly +11:46 < geertu> Yes. +11:46 < dammsan> good. +11:47 < geertu> #define MSTP(n) (n / 100 * 32 + n % 100) +11:47 < geertu> Originally I wanted to use just e.g. " +11:47 < geertu> 318" +11:47 < geertu> Until I realized what kind of sparse arrays that would give +11:48 < geertu> So it;s translated to 3 * 32 + 18 +11:48 < dammsan> do we have issues with sparsely populated arrays? +11:48 < dammsan> i thought the DT map callback takes care of that +11:48 < horms> so its ~3 times more densely populated? +11:48 < geertu> clks = kmalloc(MSTP_MAX_CLOCKS * sizeof(*clks), GFP_KERNEL); +11:49 < geertu> For 12 registers of 32 bits, that would be 1200 instead of 12 * 32 entries +11:50 < dammsan> ok, i thought you were talking about DT size +11:50 < geertu> of xlate onecell needs a non-sparse array +11:50 < geertu> No, in DT clocks/clock-indices/clock-output-names contain the used entries only +11:50 < dammsan> ok, so DT does not use the MSTP() macro? +11:51 < geertu> They become large though, so you have to be careful to insert new entries at the right position +11:51 < geertu> include/dt-bindings/clock/r8a7791-clock.h has e.g. +11:51 < geertu> #define R8A7791_CLK_MSIOF2 MSTP(205) +11:51 < geertu> and the dtsi just uses R8A7791_CLK_MSIOF2, which is expanded to 2 * 32 + 5 +11:51 < dammsan> oh, that looks good +11:52 < geertu> And we avoid the "CCF doesn't support clock-cells = <2>" by Laurent +11:52 < dammsan> the in-driver management for clock arrays is an interneal implementation detail +11:53 < horms> is it possible to teach of xlate oncell how to handle a sparse array? +11:53 < pinchartl> geertu: that looks good to me +11:54 < geertu> See of_clk_src_onecell_get() +11:55 < geertu> horms: we can provide our own xlate method in +11:55 < geertu> of_clk_add_provider(np, of_clk_src_onecell_get, &group->data); +11:55 < dammsan> geertu: so how do we combine that and the current CPG series? +11:56 < geertu> Then we can get rid of the MSTP() macro, I think +11:56 < dammsan> horms: geertu: it would be elegant to use xlate if that would solve the issue +11:57 < geertu> pinchartl: which part? +11:57 < geertu> horms: yes +11:57 < horms> great :) +11:58 < pinchartl> geertu: the DT bindings with a single node +11:58 < geertu> dammsan: the clk-mssr driver must be added, and the call to cpg_mstp_add_clk_domain() has to be changed to cpg_mssr_add_clk_domain(), and the Makefile updated to use clk-mssr.o +11:58 < pinchartl> I haven't reviewed the implementation in detail +11:59 < geertu> pinchartl: I should have sent a git-style diff, so you could see more easily how clk-mssr.c differs from clk-mstp.c +11:59 < pinchartl> no worries +11:59 < pinchartl> implementations can always be adjusted later if needed anyway +12:00 < geertu> My biggest worry is the long clocks/clock-indices/clock-output-names arrays +12:00 < geertu> They're still error-prone +12:01 < dammsan> geertu: are those arrays per-32bit-word? +12:01 < dammsan> or one global? +12:01 < geertu> dammsan: no, they cover all MSSR moule bits +12:01 < geertu> s/moule/module/ +12:01 < dammsan> oh i see +12:02 < dammsan> would it be difficult to do it per-32bit-word? +12:02 < dammsan> that would make it easier to review and less error prone, no? +12:02 < geertu> So we need subnodes per 32-bit register (set)? +12:03 < geertu> mssr@0 { ... } +12:03 < dammsan> that sounds logical to me +12:03 < geertu> mssr@1 { ...} +12:03 < geertu> Can be done, more parsing code +12:04 < geertu> And people may still stick the wrong clocks in the wrong subnode +12:04 < dammsan> i guess we're one step away from a single plink per clock? +12:04 < geertu> it woukd avoid the "/* MSTPx */" comments +12:04 < geertu> That was my previous proposal ;-) +12:05 < geertu> For the subnodes, we need some more #address/size-cells and reg glue +12:05 < dammsan> one big array seems a bit suboptimal to me... +12:05 < dammsan> i like the single plink +12:06 < dammsan> but other people may not =) +12:06 < geertu> Yeah, Gen2 doesn't have register set 6 +12:06 < dammsan> geertu: do you need reg glue? +12:06 < geertu> so says the datasheet +12:06 < geertu> but there are bits I can toggle from U-Boot, and the status registers follow suit ;-) +12:06 < dammsan> hehe +12:07 < geertu> THe mssr main node needs #address-cells is 1, #size-cells = 0 +12:07 < geertu> The mssr@x subnodes need reg = <x> +12:07 < dammsan> i see +12:08 < geertu> In theory, the subnodes also need #clock-cells = <1> +12:08 < geertu> but dtc won't complain about that +12:08 < geertu> ah, CCF needs the #clock-cells = <1> in the subnodes +12:08 < geertu> That would be the penalties for getting rid of the "/* MSTP x */" comments in the arrays +12:09 < geertu> But I think we're running out of time... +12:09 < dammsan> i'm fine either way myself +12:09 < geertu> Please reply with your comments to the emails +12:09 < geertu> Topic 4. sh-pfc +12:09 < dammsan> lets discuss face-to-face how to combine these things +12:10 < dammsan> but i'll reply any technical feedback via email +12:10 < dammsan> yes +12:10 < dammsan> nice with the pfc bits +12:10 < geertu> So I queued up the pfc patches +12:10 < geertu> both Gen3 and non-Gen3 +12:11 < geertu> Most have been acked by LinusW +12:11 < geertu> some by Laurent +12:11 < geertu> I have more PFC patches to go out (resend) +12:12 < pinchartl> geertu: if there are core PFC patches I haven't acked could you please ping me ? +12:12 < horms> Excellent, thanks for getting that under control +12:12 < geertu> But MSIOF (and USB (Shimoda-san?)) depends on review comments for "[PATCH] [RFC] pinctrl: sh-pfc: Improve pinmux macros documentation" +12:12 < pinchartl> I won't have time to review the "pin number" patches this week +12:12 < pinchartl> but I can take a look at the core +12:12 < pinchartl> ok, that one I should review I guess :-) +12:12 < geertu> pinchartl: OK; yes ;-) +12:14 < geertu> shimoda: Ignore me, USB on Gen3 doesn't need it (Gen2 did) +12:14 < morimoto> geertu: thank you about this patch. I guess it was my task +12:15 < geertu> morimoto: you're welcome. There's still opportunity for improvement +12:15 < shimoda> geertu: sorry, and I don't understand about the pfc topic +12:15 < geertu> shimoda: pfc-r8a7791.c has "PINMUX_DATA(USB0_PWEN_MARK, FN_USB0_PWEN)" +12:15 < geertu> which uses the "raw +12:16 < geertu> which uses the "raw" PINMUX_DATA() macro +12:18 < pinchartl> (lunch time) +12:18 < geertu> Topic 5. Status check for tasks from last meeting - what is remaining +12:18 < shimoda> Umm, I don't still understand it, so I will ask Morimoto-san or Magnus-san later :) +12:18 < dammsan> shimoda: sure +12:19 < geertu> https://osdr.renesas.com/projects/linux-kernel-development/wiki/Core-todo-list +12:19 < geertu> No status changes? +12:19 < horms> I did some work on Lauren't pin mode driver idea, however I'm struggling to initialise the module(s) early enough for them to be useful to CPG on Gen2 which is used from the init_timer callback +12:20 < dammsan> horms: i wonder if some -EPROBE_DEFER changes would be useful for the CPG and/or CCF? +12:20 < pinchartl> horms: could init be performed on the first call to the get mode operation and the value then cached ? +12:20 < pinchartl> (now I really have to run, sorry) +12:20 < dammsan> and move it to later during boot +12:20 < geertu> pinchartl: bye! +12:21 < dammsan> pichartl: enjoy lunch +12:21 < horms> pinchartl: the trouble is knowing which implementer (module) to call +12:21 < horms> it needs to register itself for your idea to work +12:21 < horms> dammsan: that may work out, the devil would be in the details +12:21 < dammsan> horms: can't you use a different earlier initcall? +12:22 < horms> esp what needs a cpg to be functional at that point +12:22 < dammsan> earlier than the timer callback +12:22 < horms> i tried early +12:22 < horms> and even pure +12:22 < horms> they are both too late +12:22 < dammsan> hm.. +12:22 < geertu> machine_desc.init_early()? +12:22 < dammsan> we have the delay stuff there i think +12:22 < horms> geertu: that would work, i suppose +12:23 < horms> but it would need to call the implementor directly +12:23 < horms> rather than the higher-level wrapper; which imho is most of the point of the idea +12:23 < horms> none the less it might make it fly for gen2 +12:23 < horms> and perhaps for gen3 an initcall is early enough +12:24 < geertu> machine_desc.init_early() can set up the accessor? +12:24 < dammsan> horms: clocks and timers are a can a worms regardless of architecture +12:24 < geertu> dammsan: you don't want -EPROBE_DEFER in CCF nor CPG, as it won't be retried +12:24 < horms> geertu: yes, it could set up the accessor or cache the value; your idea is growing on me +12:25 < horms> i'll see if I can make it fly +12:25 * geertu should shut up, as he wants renesas,modemr to succeed +12:25 < horms> and if so post a prototype +12:25 < horms> fwiw, i am currently neutal regarding wich solution i would like to succeed +12:25 < horms> my aim is merely to flesh out laurent's idea so we can see what it looks like in practice +12:26 < horms> thanks for the idea +12:26 < dammsan> geertu: i guess moving CPG and CCF to later on will require some serious changes then +12:26 < horms> i think we can close that sub-topic for noe +12:27 < horms> i'm skeptical that such a rework is warranted for this particular cause +12:27 < dammsan> geertu: what is your plan regards upstreaming of the PFC bits? +12:27 < dammsan> you said sending something at -rc i recall? +12:27 < dammsan> horms: sure +12:27 < dammsan> horms: just plan b if all else fails +12:27 < horms> sure +12:27 < horms> no argument there +12:28 < geertu> dammsan: send pull request to LinusW later this week, or perhaps next week (hmm, Dublin) +12:28 < geertu> Are there many pending PFC bits? +12:28 < geertu> I have HSCIF and MSIOF +12:28 < geertu> Shimoda-san has USB? +12:29 < dammsan> does linusw like several incremental pull requests, or one single? +12:29 < horms> you have avb, right? +12:29 < geertu> damsan: no ides. I may find out ;-) +12:29 < shimoda> geertu: yes, I have USB (and PWM) +12:29 < geertu> avb is in +12:29 < horms> great +12:29 < morimoto> I guess I posted Sound and I2C +12:29 < dammsan> i think if we can get in what we have then that would be wonderful +12:30 < horms> agreed +12:30 < geertu> sh-pfc-for-v4.4 has scif, i2c, audio clock, audio ssi, avb +12:30 < dammsan> maybe we can consider the DT bindings semi-stable once things hit next? +12:31 < geertu> dammsan: which DT bindings? +12:31 < dammsan> geertu: that sounds more than is needed by the current integration series +12:31 < dammsan> r8a7795 pfc +12:31 < geertu> dammsan: that matches integration +12:31 < horms> dammsan: r.e. semi-stable: i think so +12:32 < dammsan> so it must be better to have a small set of devices agreed on early +12:32 < dammsan> compared to larger late +12:32 < geertu> Don't know whether I should postpone MSIOF PFC until I have hardware? +12:32 < dammsan> i think that is fine +12:33 < horms> its not as if it will regress any existing support +12:33 < geertu> Yeah, we had small bugs in various PFC bits for years +12:33 < horms> exactly +12:33 < geertu> They will be fixed when/if someone encounters them +12:33 < dammsan> untested most certainly means broken +12:34 < horms> yes +12:34 * geertu is actually surprised about how much of the PFC bits were correct +12:34 < dammsan> yeah +12:34 < dammsan> good with review from you guys +12:35 < dammsan> and nice that morimoto-san broke out the mega-patch +12:35 < morimoto> I hope 7795 is more readable than other pfc +12:35 < dammsan> i wonder if linusw will be at ELCE +12:35 < dammsan> if so i should bring some whiskey +12:36 < geertu> "bring some whiskey to Ireland"? +12:36 < dammsan> haha +12:36 < dammsan> well +12:36 < dammsan> sand to the beach +12:36 < horms> dammsan: I heard that Dublin is a dry county +12:37 < dammsan> as long as my coffee comes with medicin i'm happy +12:38 < dammsan> geert: would it be possible for you to prioritize sending out the PFC bits to linusw before ELCE? +12:38 < dammsan> i will do my best to update CPG on thursday +12:39 < geertu> dammsan: sure +12:39 < dammsan> thanks! +12:39 < dammsan> horms: and after ELCE i hope to hand over the integration stuff to you +12:39 < horms> dammsan: excellent +12:40 < horms> i guess there wont be a whole lot of time between then and rc5 +12:40 < dammsan> i guess so +12:40 < dammsan> alternatively i can hand it over earlier +12:41 < horms> earlier is better if its ready :) +12:41 < dammsan> i need to sync the CPG and integration bits +12:41 < horms> but do we need bindings to hit next first? +12:41 < dammsan> i think review can happen in parallel +12:41 < horms> ok +12:41 < horms> that is of course fine +12:41 < dammsan> will you be busy next week? +12:41 * horms checks +12:42 < dammsan> or if i could hand over integration stuff to you earlier +12:42 < dammsan> perhaps that may improve our chances +12:42 < horms> I don't expect to be busy next week +12:42 < dammsan> ok, so i should really send out both CPG and integration this week +12:42 < dammsan> geert: will you be online on thursday? +12:43 < horms> or the week after other than friday when i am shceduled to visit musashi works +12:43 < dammsan> but the earlier the better +12:43 < horms> the last week of October will be busy for me +12:43 < dammsan> geertu: i was hoping to chat with you how to integrate your CPG/MSSR proposal +12:43 < dammsan> will thursday be ok? +12:44 < horms> dammsan: probably its best if you handle both of those series as you are most familiar with them. but if it makes sense I could try to offload you a bit somehow +12:44 < geertu> dammsan: Thrusday is fine +12:45 < dammsan> horms: i agree, but i may ask you to do some folding yourself +12:45 < dammsan> horms: when will your new board arrive? +12:46 < horms> it was scheduled to arrive today, but didn't +12:46 < dammsan> geertu: thanks, lets chat more thursday then +12:46 < dammsan> ok +12:46 < dammsan> i will install two new boards in the remote rack tomorrow btw +12:46 < horms> is there anything special i need to know about hooking it up? +12:47 < dammsan> horms: nope +12:47 < dammsan> it is noisy +12:47 < shimoda> horms: I'm sorry I sent the board today, so it should arrive tomorrow +12:47 < horms> ok +12:47 < horms> shimoda: no problem! +12:47 < geertu> BTW, does anyone have a kzm9d? +12:47 < horms> yes +12:48 < horms> though its semi-broken these days; the kernel for it that is +12:48 < dammsan> horms: if you are not using it, can i hook it up for remote access? +12:48 < geertu> horms: I don't need a running kernel ;-) +12:48 < horms> i'm only semi-using it to test kernels +12:48 < horms> that don't boot +12:48 < horms> perhaps i could send it to dammsan ? +12:48 < geertu> horms: Can you please run "md 0xe0028008 1" from U-Boot and tell me the reported value? +12:48 < horms> oh sure +12:48 < horms> can do +12:49 < dammsan> horms: no stress, feel free to send with takkyubin or simply bring next time we meet +12:49 < horms> thanks, i'll sort something out +12:49 < dammsan> thanks +12:49 < dammsan> i intend to take the salvator-x down in the remote access rack tonight +12:50 < dammsan> i will lock you out +12:50 < dammsan> it will come back again tomorrow JST +12:50 < horms> geertu: +12:50 < horms> KZM-A9-Dual# md 0xe0028008 1 +12:50 < horms> e0028008: 0000043b ;... +12:51 < horms> dammsan: you are taking it to a club? +12:51 < geertu> horms: Thanks (GIC PL390) +12:51 < horms> geertu: any time +12:51 < dammsan> horms: i wish +12:52 < geertu> horms: So it's a dual-core, but doesn't have the CA9 MPCore GIC +12:52 < horms> interesting +12:52 < dammsan> geertu: EMEV2 was a very early CA9 implementation I've heard +12:52 < dammsan> the TWD seems quite special too +12:53 < dammsan> anyway, i should probably wrap up now +12:53 < horms> unless there are any more pressing topics i might move on +12:53 < dammsan> will see if my lager DU IPMMU hack outputs anything over VGA +12:54 < dammsan> thanks for your time guys +12:54 < horms> bye +12:54 < geertu> time for lunch... +12:54 < dammsan> bye bye +12:54 < uli___> cu +12:54 < geertu> Thanks, for joining! Bye! |