1 files changed, 203 insertions, 0 deletions
diff --git a/wiki/Chat_log/20151119-io-chatlog b/wiki/Chat_log/20151119-io-chatlog
new file mode 100644
index 0000000..0d06431
--- /dev/null
+++ b/wiki/Chat_log/20151119-io-chatlog
@@ -0,0 +1,203 @@
+--- Log opened Thu Nov 19 09:52:39 2015
+09:52 -!- wsa_ [~wsa@p4FE2557F.dip0.t-ipconnect.de] has joined #periperi-io
+09:52 -!- Irssi: #periperi-io: Total of 2 nicks [1 ops, 0 halfops, 0 voices, 1 normal]
+09:52 -!- Irssi: Join to #periperi-io was synced in 0 secs
+10:11 -!- morimoto [~user@relprex2.renesas.com] has joined #periperi-io
+10:11 < morimoto> Hi
+10:11 <@geertu> hi
+10:11 -!- dammsan [~dammsan@s214090.ppp.asahi-net.or.jp] has joined #periperi-io
+10:12 -!- shimoda [~shimoda@relprex2.renesas.com] has joined #periperi-io
+10:12 < wsa_> great
+10:12 < wsa_> everyone's here...
+10:13 < wsa_> so, let's get started
+10:13 < wsa_> i assume people in Japan want to go home soon ;)
+10:14 < shimoda> :)
+10:14 < wsa_> my topics as mentioned:
+10:14 < wsa_> 1) gen3 updates
+10:14 < wsa_> 2) clocks-off as default?
+10:14 < wsa_> are there topics from your side?
+10:15 < shimoda> none from me
+10:15 < morimoto> Did you get email from shimoda-san about I2C macro issue ?
+10:16 < wsa_> morimoto-san: yes, i even replied
+10:16 < wsa_> morimoto: laurent and i found the same issue yesterday
+10:16 < shimoda> wsa_: thank you for the information. this is useful to me
+10:17 < morimoto> Oops I got email from you just during Renesas network issue time :)
+10:17 < shimoda> so, i will forward this information to the customer
+10:17 < wsa_> yes, and it was useful confirmation for me, too
+10:17 < wsa_> as we are talking I2C already
+10:18 < wsa_> any estimation when the HW team answers the "what is low drive only LVTTL" question?
+10:19 < shimoda> wsa_: i am asking this and they returned something, but I don't get useful information yet for now
+10:20 <@geertu> I think it's just the lower half of a regular push-pull output
+10:20 < wsa_> i was thinking the same
+10:20 <@geertu> I.e. similar like open drain, but with smaller transistors supporting only LVTLL voltage levels
+10:20 < wsa_> but that would mean those busses are not multi-master capable
+10:20 <@geertu> Typically open drain supports much higher voltage levels
+10:21 <@geertu> Why not multi-master?
+10:21 <@geertu> (higher voltage levels = much higher than vdd)
+10:21 <@geertu> s/LVTLL/LVTTL/
+10:23 < wsa_> to be precise, they might not be multi-master compatible
+10:23 < wsa_> it depends how it is done
+10:23 <@geertu> lower half of a regular push-pull output == open drain
+10:24 < wsa_> then why is not everyone doing it when it is so much faster?
+10:25 < wsa_> that i wonder and why i'd like some details
+10:25 <@geertu> Isn't it faster because of LVTTL levels? The lower voltage the pull-up, the faster it is (regular i2c is 5v, right)
+10:25 < wsa_> yes, but rcar does only 3v3 at max
+10:26 < wsa_> hmmm
+10:26 < wsa_> makes sense
+10:26 < wsa_> need to think about it
+10:26 < wsa_> not now ;)
+10:26 < wsa_> i saw the watchdog driver made it to the bsp
+10:26 < wsa_> so bsp team was happy with it?
+10:26 < wsa_> and we can continue upstreaming i guess
+10:27 < shimoda> wsa_: i think so because bsp team doesn't ask me about it for now :)
+10:28 < wsa_> :)
+10:28 < wsa_> the PCIE driver works here for me
+10:29 < wsa_> the interrupt issue found attention by Marc Zygnier, so I guess he and Phil will work it out
+10:29 < shimoda> nice!
+10:30 < wsa_> i can also scan the new bsp for sata patches. should be low-hanging fruit to upstream
+10:31 -!- dammsan [~dammsan@s214090.ppp.asahi-net.or.jp] has quit Remote host closed the connection
+10:31 -!- dammsan [~dammsan@s214090.ppp.asahi-net.or.jp] has joined #periperi-io
+10:32 < wsa_> then we wanted to find an upstream path for SDHI DMA
+10:32 < wsa_> shimoda-san: is this still valid?
+10:32 < wsa_> or did something other urgent show up?
+10:32 < shimoda> i think so about sata. about porting from bsp to upstream, kaneko san of horms can do it, i guess
+10:33 < wsa_> ok
+10:33 < dammsan> guys
+10:33 < shimoda> wsa_: yes, it is still valid, i think noone care about SDHI DMA for upstreamining
+10:33 < dammsan> may i simply ask you to prioritize the I2C stuff over other leaf node devices?
+10:33 < dammsan> that will be my only request =)
+10:34 < wsa_> dammsan: i will send out v3 of my refactoring series today
+10:34 < wsa_> this has all known issues addressed; needs thorough testing, of course
+10:35 < dammsan> good - thanks a lot
+10:35 < wsa_> and people do test currently which is great!
+10:36 < dammsan> wsa_: you can use my remote access system anytime
+10:36 < wsa_> dammsan: i will
+10:36 < dammsan> ideally to test stuff on a wide range of boards before you queue it up
+10:36 < wsa_> and i will run the continous edid read test
+10:36 < dammsan> thanks
+10:36 < dammsan> i cannot guarantee that the TV will be there forever
+10:37 < dammsan> but looping HDMI back to the VIN may be good
+10:37 < dammsan> but anyway, i will try not to steal your time with this anymore
+10:37 < dammsan> =)
+10:38 < wsa_> dammsan: sure thing. i always tested your koelsch. yet, all kernels were build with a toolchain that "worked" :/
+10:38 < wsa_> but this time laurent tested even before v3 is released ;)
+10:40 < wsa_> but i understand this long standing issue is worrying
+10:40 < dammsan> great, thanks!
+10:41 < wsa_> shimoda: so kaneko-san will do SATA, nice. I noted it
+10:41 < shimoda> i will ask simon-san about this later though :)
+10:42 < wsa_> ok
+10:43 < wsa_> there is a thermal driver now in the bsp \o/
+10:44 < wsa_> not in an upstreamable condition, though
+10:44 < wsa_> i guess this needs to be done somewhen but it is not urgent?
+10:45 < shimoda> I think so (it is not urgent) because they have a code
+10:46 < shimoda> however, i will ask bsp team when it needs to upstream
+10:47 < wsa_> so what is USB status? I see USB3 support will be pulled in soon?
+10:47 < shimoda> yes, xhci maintainer mentioned about it
+10:48 < shimoda> about USB2.0 host (usb2.0 phy), I should ping to kishon later
+10:50 < wsa_> nice
+10:50 < shimoda> about USB3.0 peri, I am developing it now
+10:50 < shimoda> about USB2.0 peri, it should work after usb2.0 phy patch is merged
+10:50 < wsa_> great
+10:51 < wsa_> shimoda-san == USB hero
+10:51 < wsa_> :)
+10:51 < shimoda> :)
+10:51 < wsa_> geertu: did you have any time left for SCIF or SPI development?
+10:52 <@geertu> Expect SCK and full BRG support for (H)SCIF later today
+10:53 < dammsan> how to handle the fifo drain issue?
+10:53 < dammsan> i guess we need to fix that eventually
+10:53 < wsa_> geertu: nice
+10:54 <@geertu> I don't know enough about the tty/serial layer innards to answer that question
+10:54 < dammsan> sure, no worries
+10:54 < dammsan> it would be good to keep track of the task though, to show this to high level people
+10:55 < dammsan> or maybe it will cause fire =)
+10:56 < wsa_> noted
+10:56 < dammsan> thanks!
+10:58 < wsa_> so, can we go over to the clocks-off discussion?
+10:58 < shimoda> yes
+11:00 < wsa_> proposal: I'd like to make them mandatory for io-group upstream development
+11:01 < wsa_> that would mean that 7791 has to be added
+11:01 < wsa_> but their usefulness justify that IMO
+11:01 < wsa_> comments?
+11:02 <@geertu> 7791?
+11:02 < wsa_> 7790
+11:02 < wsa_> sorry
+11:03 < wsa_> ideally they would be in some branch, so that we developers can merge it into our codebase when we start hacking
+11:04 < dammsan> [1;5Dwhy not including it in upstream by default?
+11:06 < dammsan> perhaps you already have a good answer to that from a different thread?
+11:06 <@geertu> It's ugly
+11:06 < dammsan> ok but so is life
+11:07 < dammsan> if you prefer not to then if it of course fine
+11:07 < dammsan> just seems like a handy feature
+11:07 <@geertu> with the new cpg-mssr driver, we could disable all clocks early in that driver
+11:07 <@geertu> but then we have to list all of them
+11:07 < dammsan> ok, self-contained ugliness =)
+11:07 <@geertu> and I really mean all of them
+11:08 <@geertu> thus including the non-documented ones ;-)
+11:08 < dammsan> sure
+11:08 <@geertu> or live with the hex numbers, alternatively
+11:08 < dammsan> but it is easy to start doing that early compared to later in the process, no?
+11:08 <@geertu> actually the hex numbers is probably the best way
+11:08 < wsa_> the debug interface is also nice but also doesn't seem upstreamable to me
+11:09 <@geertu> indeed
+11:09 < wsa_>  /proc \o/
+11:10 < wsa_> geertu: can you provide a branch?
+11:10 < wsa_> or keep them integrated in renesas-drivers?
+11:10 < wsa_> or is the latter too much work?
+11:11 <@geertu> I can provide a branch
+11:12 <@geertu> There's no classified information in there? E.g. clocks marked "secure"
+11:12 < wsa_> that i don't know
+11:12 < dammsan> you may find bugs =)
+11:13 < dammsan> if so we shall really report them
+11:13 < dammsan> not sure how secret it is
+11:13 < dammsan> but should be fine unless you violate copyright
+11:15 < wsa_> shimoda: morimoto: if geert provides a "clocks-off" branch, would you be OK using it?
+11:15 < morimoto> sure of course
+11:15 < dammsan> wsa_: including it in renesas-drivers may be a bit difficult for bsp people
+11:15 < shimoda> wsa_: yes
+11:16 < dammsan> i think that needs to be coordinated
+11:16 < dammsan> if so
+11:16 < dammsan> just a topic branch is something else
+11:16 < wsa_> dammsan: i agree
+11:17 < wsa_> the first thought was to reduce merge conflict resolutions, but on second thought it is too invasive
+11:18 <@geertu> Do you need the full thing with debug interface, or just writing the hardcoded hex numbers to the mstpcr registers?
+11:19 < wsa_> is it much work to keep the debug interface?
+11:20 < wsa_> or maybe we start small
+11:20 < wsa_> and port the debug interface when needed
+11:24 < wsa_> ok?
+11:25 <@geertu> ok
+11:26 <@geertu> wsa_: can you extend the current "full" version to r8a7790?
+11:27 < wsa_> i'll try
+11:27 < wsa_> i'll come back to you if i have questions
+11:27 <@geertu> ok, thx
+11:28 < wsa_> anything more?
+11:28 < wsa_> i think we are done
+11:29 < shimoda> i think so
+11:29 <@geertu> I have a small note
+11:29 <@geertu> I added gpio-leds and gpio-keys to Salvator-X dts
+11:30 <@geertu> Either of them work on their own, but not combined, as the LEDs and keys share GPIOs
+11:30 < dammsan> GPIOF_SHARED?
+11:30 < dammsan> like for IRQs? =)
+11:30 <@geertu> This is an "interesting" DT issue, as both hardware descriptions are correct :-)
+11:31 < dammsan> similar to our pinmux policy setting
+11:31 < dammsan> with a single uart described but in reality the pinmux is what is limiting
+11:31 <@geertu> I have some ideas for a proof-of-convept driver combining gpio-leds and gpio-keys-polled
+11:31 < dammsan> gool
+11:31 < dammsan> i mean cool =)
+11:32 <@geertu> A while ago I had asked LinusW if something like that already existed, and he was interested in it.
+11:32 <@geertu> Sharing a GPIO for both key and LED is a classic microcontroller trick
+11:33 <@geertu> If I find some time, I'll implement it. Probably it will trigger an interesting DT discussion, so stay tuned :-)
+11:34  * wsa_ orders some popcorn
+11:34 <@geertu> Nothing else from my side for now
+11:34 < wsa_> first time i hear someone starts a DT discussion for fun... ;)
+11:35 < wsa_> ok
+11:36 < wsa_> we are done
+11:36 < wsa_> thank you!
+11:36 < morimoto> gool, thx
+11:36 < wsa_> and have a great rest of the day
+11:37 <@geertu> cu, bye!
+11:37 < wsa_> very gool!
+11:37 < shimoda> bye! :)
+11:37 < dammsan> cya
+11:37 -!- shimoda [~shimoda@relprex2.renesas.com] has quit Quit: WeeChat 0.4.2
+11:38 -!- morimoto [~user@relprex2.renesas.com] has left #periperi-io ["ERC Version 5.3 (IRC client for Emacs)"]
+--- Log closed Thu Nov 19 11:41:26 2015