renesas/periject.git - Renesas periject clone

diff options

Diffstat (limited to 'wiki/Chat_log/20181018-io-chatlog')

0 files changed, 0 insertions, 0 deletions

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


context:
space:
mode: