path: root/wiki/Chat_log/20150929-core-chatlog

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!