path: root/wiki/Chat_log/20151119-io-chatlog

--- 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