renesas/drm.git - libdrm, cloned from git://anongit.freedesktop.org/mesa/drm

Age	Commit message (Collapse)	Author
2006-11-08	libdrm: add support for server side functionality in libdrm	Dave Airlie
	This adds APIs to allow the X server to use libdrm from the system rather than its own in-built copy.
2006-08-30	Memory manager init and takedown.	Thomas Hellstrom

2006-02-20	Formatting cleanup, dead code removal. Remove N() namespacing macro,	Adam Jackson
	useless. Remove SIGIO handling functions as they're server-only and properly belong in libdri.
2005-11-30	Bump package and DSO numbers to 2.0 to reflect 32/64 ABI change	Adam Jackson

2005-10-20	Remove the remaining references to Xlib. libdrm is totally independent now.	Adam Jackson

2005-08-25	Include appropriate CFLAGS to find X headers, needed to build libdrm.	Eric Anholt

2005-08-20	Fix silly install issue by moving the header install rules for shared-core	Adam Jackson
	into shared-core/Makefile.am. Bump to 1.0.3.
2005-08-19	Add r300_reg.h. Bump to 1.0.2.	Adam Jackson

2005-07-13	distcheck fixes	Adam Jackson

2005-07-10	autoconfiscate libdrm	Adam Jackson

Multimedia-chat-meeting-2018-09-20 10:22 < pinchartl> welcome to the multimedia meeting 10:22 < pinchartl> topic 1, status updates 10:23 < pinchartl> * Jacopo 10:23 < pinchartl> Since last meeting: 10:23 < pinchartl> - R8A77990 (E3) VIN and CSI-2 10:23 < pinchartl> Respined Ebisu support patch, supported Laurent and Niklas in testing. 10:23 < pinchartl> - Respined the adv748x single endpoint probe patches 10:23 < pinchartl> - Reviewed and tested Sakari's v4l2-fwnode patches 10:23 < pinchartl> - Ported CEU driver to use new fwnode defaults 10:23 < pinchartl> - Tested and reviewed the D3/E3 LDS PLL patches 10:23 < pinchartl> Until next meeting: 10:23 < pinchartl> - Really look into the E3 CSI-2 issue 10:23 < pinchartl> - Test niklas v4l2-mux series 10:23 < pinchartl> - Have adv748x patches merged 10:23 < pinchartl> Issues and Blockers: None 10:23 < pinchartl> jmondi: any comment ? 10:23 < jmondi> pinchartl: not really 10:23 < jmondi> apart deciding how to procede forward with E3 VIN and CSi-2 testing 10:24 < jmondi> but that's for later, with you and neg 10:24 < pinchartl> I plan to test the next version of the adv748x patch 10:25 < jmondi> pinchartl: great, let's sync so I can support 10:25 < pinchartl> in the meantime, if there are CSI-2 and VIN debug registers that could help diagnosing the problem, it would be nice to have a small hack debug patch to read them 10:26 < pinchartl> * Kieran 10:26 < pinchartl> Since last meeting: 10:26 < pinchartl> - VSP1 and DU patch respins and posting 10:26 < pinchartl> - Testing D3/E3 LVDS patch series 10:26 < pinchartl> - Discovered and investigated rcar-du Alpha Blending bug. 10:26 < pinchartl> - ADV748x development and reviews 10:26 < pinchartl> - periupport updates for bsp370/v4.14 10:26 < pinchartl> - Posted patches to fix the alpha blend regression 10:26 < pinchartl> - Conference planning 10:26 < pinchartl> Until next meeting: 10:26 < pinchartl> - M3-N Rotation bug needs investigation. 10:26 < pinchartl> - Writeback rebase and repost. 10:26 < pinchartl> - Partition phase work 10:26 < pinchartl> - ADV748x dynamic routing. 10:26 < pinchartl> Issues and blockers: None 10:26 < pinchartl> kbingham: any comment ? 10:26 < jmondi> pinchartl: not sure where we have to look into, my guesses are now adv748x 2 lanes config (you have to test if I got it right) and the CSI-2 interface VC configuration 10:26 < jmondi> sorry 10:26 < kbingham> Only one for morimoto-san 10:26 < kbingham> morimoto, Do we need to submit cost plans for ELCE? 10:27 < morimoto> Yes, please 10:27 < kbingham> morimoto, Ack. I'll send an email this morning :) 10:27 < kbingham> Otherwise good here. 10:27 < morimoto> and, Hotel cost, too 10:28 < kbingham> Sure 10:28 < kbingham> Me Laurent and Jacopo will share accomodation I believe 10:28 < pinchartl> jmondi: I don't know where the problem is, so I can't tell you what to look into either :-) 10:29 < jmondi> pinchartl: I understand, but it's hard to pick a register to help debug, if we don't know where the problem is :) anyway, let's sync and try 10:30 < pinchartl> * Laurent 10:30 < pinchartl> Until next meeting: 10:30 < pinchartl> - More patch review 10:30 < pinchartl> - D3/E3 DU LVDS PLL upstreaming 10:30 < pinchartl> - Attend XDC (X Developers Conference) next week 10:30 < pinchartl> Since last meeting: 10:30 < pinchartl> - More patch review 10:30 < pinchartl> - D3/E3 DU LVDS PLL upstreaming 10:30 < pinchartl> - Get GMSL patches merged 10:30 < pinchartl> Issues and blockers: None 10:30 < pinchartl> any question ? 10:31 < jmondi> what about GMSL? 10:31 < jmondi> just respin the series? 10:31 < jmondi> or you need support for that? 10:32 < pinchartl> I need to finish the review, and then send a pull request 10:32 < pinchartl> or one of you could send the pull request, no issue with that 10:33 < pinchartl> * Morimoto-san 10:33 < pinchartl> Since last meeting: 10:33 < pinchartl> - TDM investigations (???) 10:33 < pinchartl> Until next meeting: 10:33 < pinchartl> - Implement TDM expand mode using StarterKit + KingFisher 10:33 < pinchartl> Issues and Blockers: 10:33 < pinchartl> - We can't check TDM split mode 10:33 < pinchartl> morimoto: any comment ? 10:33 < morimoto> no, thanks 10:34 < pinchartl> * Niklas 10:34 < pinchartl> Since last meeting: 10:34 < pinchartl> - [PATCH] v4l2-common: fix typo in documentation for v4l_bound_align_image() 10:34 < pinchartl> - [PATCH 0/3] rcar-vin: add support for UDS (Up Down Scaler) 10:34 < pinchartl> - [PATCH 0/3] i2c: adv748x: add support for CSI-2 TXA to work in 1-, 2- 10:34 < pinchartl> and 4-lane mod 10:34 < pinchartl> Until next meeting: 10:34 < pinchartl> - Work on review comments to UDS and adv748x 10:34 < pinchartl> - Pray for feedback to the multiplexed streams patch-set 10:34 < pinchartl> Issues and blockers: None 10:35 < pinchartl> neg: any comment ? 10:35 < neg> no comment, thanks 10:35 < pinchartl> prayers seem not to have worked well, could you try to push me a bit more explicitly to get the muxed streams series reviewed ? 10:36 < kbingham> morimoto, What is TDM investigations ? 10:36 < neg> will do :-) 10:36 < kbingham> Is that an audio thing ? 10:36 < morimoto> kbingham: yes. there are 3 type of format 10:36 < morimoto> TDM x 2, and Mono 10:37 < morimoto> I did was Mono, not TDM. sorry pinchartl 10:37 < morimoto> --eol-- 10:38 < pinchartl> thanks, I'll update that 10:38 < pinchartl> * Simon (Kaneko-san) 10:38 < pinchartl> Since last meeting: 10:38 < pinchartl> - Merged: [PATCH v2] ASoC: rsnd: Add device tree binding for r8a77990 10:38 < pinchartl> Until next meeting: 10:38 < pinchartl> - Testing M3-N and E3 Audio support 10:38 < pinchartl> Issues and blockers: None 10:38 < pinchartl> horms: any comment ? 10:39 < horms> Not that I need to find time to actually do the testing 10:39 < horms> Not other than that... 10:40 < pinchartl> * Ulrich 10:40 < pinchartl> Since last meeting: None 10:40 < pinchartl> - Reviewed (half of) "R-Car D3/E3 display support (with LVDS PLL)" 10:40 < pinchartl> Until next meeting: TBD 10:40 < pinchartl> Issues and blockers: None 10:40 < pinchartl> uli___: any comment ? 10:41 < uli___> i'll be afk until tuesday, will it still be ok to review the back half of the d3/e3 hdmi series then? 10:41 < horms> possibly related: I plan to close the reneas tree for v4.20 next Wednesday 10:42 < pinchartl> uli___: sure 10:42 < pinchartl> horms: ok 10:42 < uli___> ok. no other comments. 10:42 < pinchartl> the DT bindings have been approved, can I then send the DT changes for v4.20 ? 10:44 < pinchartl> horms: that was a question for you :-) 10:45 < horms> If they have been approved and you think the DT changes are finalised, then yes, feel free. 10:45 < pinchartl> thanks 10:45 < pinchartl> that's it for the status updates 10:45 < pinchartl> topic 2, additional tasks for Q4 10:46 < pinchartl> damm: do you have any comment on that before we start ? 10:47 < damm> nope 10:47 * morimoto I believe I can get some answer about 3 questions 10:47 * morimoto in later 10:48 < pinchartl> morimoto: I've seen them, we'll get to that, don't worry :-) 10:48 < pinchartl> so regarding additional tasks for Q4 10:48 < morimoto> thanks 10:48 < pinchartl> we have reduced budget 10:48 < pinchartl> which implies reduced additional tasks 10:49 < pinchartl> with 10 days per quarter I don't see how we can reasonably include upstreaming in any additional task anymore 10:49 < pinchartl> damm: I would thus like to know what type of tasks Renesas will expect now 10:49 < pinchartl> they just can't include everything from development to upstreaming anymore 10:50 < pinchartl> upstreaming will need to be handled under base time 10:50 < damm> pinchartl: yes i agree 10:51 < jmondi> which makes, depending on how much time one has left, only one task in total for q4 per person acceptable 10:51 < pinchartl> jmondi: I would go for one task per quarter, yes 10:51 < jmondi> as it will consume additional time for implementation and all base time for upstreaming 10:52 < jmondi> pinchartl: yeah, my point is that also base time will be affected, leaving not much time for the usual base tasks (review, backlog, etc) 10:53 < jmondi> but I think this a well known issue... 10:53 < pinchartl> it should be known at least 10:53 < pinchartl> it's certainly known on our side that less time means less output :-) 10:54 < pinchartl> damm: you explained before that Renesas expected upstreaming to be included in additional tasks. now that this can't be done anymore, what type of tasks would be acceptable ? 10:58 < damm> prototypes, minor bug fixes, building some hardware rig to extend testing etc 10:58 < pinchartl> ok, thanks 10:58 < damm> makign test programs 10:58 < damm> or extending them 10:58 < pinchartl> so we need to come up with additional tasks 10:58 < damm> that's my take at least 10:58 < pinchartl> I would like all multimedia developers to submit proposals 10:59 < pinchartl> you can reply to the meeting report e-mail, or we can discuss them now if you already have ideas 10:59 < kbingham> pinchartl, I'd probably consider the M3-N Rotation bug as a candidate then 11:00 < jmondi> there are a few things around adv748x but I'm not sure how to assign them 11:00 < neg> I would love to work on improving test rigs but is that not a dangerus path to prove the value of the upstream team? 11:00 < neg> Would it not be a bit more clever to package a set of IP specific upport commits as add tasks? 11:01 < pinchartl> neg: my understanding is that upport as an additional task was frowned upon by Renesas, but things might have changed 11:02 < neg> pinchartl: ahh I see was not aware of that scrap that then :-) 11:02 < damm> actually 11:02 < damm> i don't mind including the up-port bit 11:02 < damm> if it is something that can be defined clearly and is in demand 11:02 < pinchartl> damm: that's good to hear :-) 11:02 < damm> also about test rig 11:03 < damm> if we can document how things may be done in a public space then i think it has value by itself 11:04 < damm> (this is how we automate eject/insert of SD cards for example) 11:04 < kbingham> There is an automated-testing mailinglist (I think started by Tim Bird) where lots of farming talks are currently occuring in public space. 11:04 < kbingham> And a test-summit at ELCE 11:04 < kbingham> geertu, Are you attendign that test summit? 11:04 < pinchartl> the testing summit will occur at the same time as the V4L2 summit I believe :-( 11:05 < geertu> kbingham: yes I will. Will mostly be about the automated testing part, I believe 11:05 < kbingham> geertu, I'm sure that's what we need more of :) 11:06 < geertu> pinchartl: Yes, -ETOOMANYCONCURRENCY 11:06 < pinchartl> geertu: something like that 11:06 < geertu> kbingham: Not if it involves Jenkins 11:06 < kbingham> geertu, Is that their only solution ? :S 11:08 < pinchartl> let's move to the next topic 11:08 < pinchartl> morimoto: you had questions 11:08 < morimoto> yeah 11:08 < pinchartl> I've just replied to them by e-mail 11:08 < pinchartl> I'll paste my replies here 11:08 < morimoto> I got answer from kbingham and jacopo 11:09 < neg> kbingham: well is not gerrit + jenkins the silver bullet solution to all software quality and assurence it be devliverd on time? 11:09 < morimoto> thanks ! I got your answer 11:09 < pinchartl> ah, there are other answers too 11:10 < pinchartl> regarding the VSP 1x1 image size, Mauro has applied to the patch to this tree 11:10 < pinchartl> s/this tree/his tree/ 11:11 < kbingham> Oh - I missed that :) 11:11 < kbingham> But great :) 11:11 < pinchartl> for the DU reserved registers, Jacopo has submitted patches 11:12 < pinchartl> but I'm concerned about all the changes that are requested to match the datasheet to the last detail, when there's no clear indication that this is needed 11:13 < pinchartl> I can consider merging Jacopo's series this time, but next time we'll get a request along the lines of "the datasheets states this order of operations, the driver need to match" I will request a proof that the current implementation causes a real bug 11:14 < wsa> damm: about remote inserting SD cards: I got a device from Pengutronix which does that 11:14 < pinchartl> and regarding the D3/E3 LVDS PLL and clock issue, I plan to submit that as an additional task for Q4 11:14 < pinchartl> morimoto: does this answer your questions ? 11:14 < damm> wsa: great! i recall linaro had something like that too 11:14 < jmondi> pinchartl: awmm (I don't know how to properly express demotivating feelings with onomatopoeic expressions in English, hope it's clear) 11:15 < pinchartl> jmondi: it's not a judgment on the quality of your work, but I think that several requests we have received are pointless to start with 11:15 < wsa> damm: https://www.pengutronix.de/2017-10-23-usb-sd-mux-automated-sd-card-juggler.html 11:15 < pinchartl> and I don't want to continue increasing the complexity of an already complex piece of code when there's no need to 11:15 < morimoto> pinchartl: sorry my late response. Thanks, nice answer 11:15 < damm> pinchartl: since many devices are shared IP that should work on many SoCs it would make sense to give feedback to renesas to make sure the register read/write order is consistent across products 11:16 < morimoto> I will forward these to BSP team 11:16 < jmondi> pinchartl: sure I get it, I was referring to this kind of requests 11:16 < pinchartl> damm: it's not just about consistency between products, it's also that in many cases a specific write order is not required 11:17 < pinchartl> if you have to program lots of registers before starting the hardwarer 11:17 < pinchartl> more often than not the order doesn't matter 11:17 < damm> lets just say that i agree with you very much 11:17 < wsa> I could ask if they can bring some to ELCE if that helps. I can bring the one I have, too 11:17 < pinchartl> and mandating a specific order sometimes creates extra complexity in the driver by breaking the natural grouping of parameters we get from existing APIs 11:18 < damm> i'm with you 11:18 < pinchartl> thanks :-) 11:18 < damm> that kind of request makes the "alpabetize the headers" thing look good 11:18 < morimoto> pinchartl: sometimes (anytimes ?) BSP team cares very picky point 11:19 < pinchartl> damm: :-D 11:19 < pinchartl> morimoto: in many cases they have good points, they point us to small bugs that are hard to find or only happen in some corner cases, but that are bugs nevertheless, and I'm happy to fix them 11:20 < pinchartl> but sometimes it really feels like they have been asked to do something and they push the request down to us, even if the request wasn't very sensible to start with 11:20 < damm> if there are dependenices and ordering between several IPs it would be helpful to know those ahead of time 11:20 < morimoto> one reason is that it is related to customer 11:21 < morimoto> customer is checking "datasheet" and "driver" 11:21 < pinchartl> morimoto: then I think the datasheet should be updated 11:21 < pinchartl> as that's where the problem is 11:21 < morimoto> and ask to us "why datasheet and driver are not same ?" if driver and datasheet are mismatched 11:21 < pinchartl> if the hardware can work with multiple orders 11:21 < pinchartl> and the datasheet says that a specific order is required 11:21 < pinchartl> then the datasheet is wrong :-) 11:22 < damm> the data sheet is like a recommendation 11:22 < damm> it is more like fiction than fact 11:22 < morimoto> yeah, sometimes multiple order is OK. but it is case-by-case 11:23 < morimoto> This is unfortunately complex area to solve 11:23 < pinchartl> of course when some operations have to be ordered a certain way, and the driver doesn't follow that, we should fix the code 11:23 < damm> morimoto: but changing order requirement late in the process seems not very useful 11:23 < morimoto> HW team vs datasheet team vs softweare team vs customer 11:23 < pinchartl> one problem with the datasheet documenting a particular order without stating whether it's mandatory or not, 11:24 < damm> morimoto: if this was a requirement then we want to know this from day 0 11:24 < pinchartl> is that important information get lost in the noise 11:24 < pinchartl> as it then becomes easy to read the datasheet and think that it's just the usual case of a recommended order 11:24 < pinchartl> while it's actually super important 11:25 < pinchartl> so by saying that things are mandatory all around when they are not, the real mandatory ones don't clearly show 11:25 < pinchartl> but I don't think there's any fundamental disagreement among us here 11:25 < pinchartl> any other discussion topic ? 11:26 < damm> pinchartl: maybe we can implement some hardware abstraction layer and use the drivers from Integrity(tm) that follow the correct order(tm) 11:26 < morimoto> This kind of topic is unfortunately difficult to solve. I will ask to BSP team whether it is very important, or datasheet side can updated or so. 11:27 < damm> my opinion is that shared IP needs to be discussed on a broader scale 11:27 < damm> renesas needs to learn how to manage shared ip 11:28 < damm> i expect you guys to help out that process by good feedback =) 11:28 < damm> no other topic from me 11:28 < morimoto> I think this is not only Renesas issue. Many people are related to this kind of topic, but no one knows who has correct answer... 11:28 < morimoto> no topic from me, too 11:29 < jmondi> nothing to add from my side neither 11:29 < pinchartl> alright 11:29 < pinchartl> last topic then 11:29 < pinchartl> next meeting 11:29 < pinchartl> two weeks from now, on October the 4th, same time as usual ? 11:30 < kbingham> Aribtrary question from me - Has Gen4 hardware been started already ? 11:30 < morimoto> kbingham: not yet 11:30 < kbingham> ( I assume they start gen4 before Gen3 ships) 11:30 < kbingham> Oh ok - so my assumption is wrong ;) 11:30 < morimoto> it is depend on what is your "start" mean 11:31 < morimoto> "Gen4 plan" is started, "Gen4 implement" is not yet 11:31 < kbingham> :) 11:32 < kbingham> So it's 18-24 months at least or more before any g4 hardware appears then :) 11:32 < morimoto> But we will have Gen3.5 :) 11:32 < kbingham> Oh :) 11:32 < morimoto> I don't know detail, thought 11:32 < neg> Gen3.5 = new ES versions ? 11:33 < morimoto> neg: I don't know, sorry 11:33 < geertu> s/arm/risc-v/? 11:33 < neg> morimoto: no worries just curious :-) 11:33 < morimoto> geertu: not Risc-V :) 11:34 < kbingham> pinchartl, Oct 4th sounds good to me. 11:34 < morimoto> Oct 4th is OK to me 11:35 < pinchartl> that's all I have for today 11:35 < neg> 4th OK for me 11:35 < pinchartl> I propose adjourning the meeting 11:35 < pinchartl> does anyone second ? 11:36 < jmondi> fine wiht me 11:36 < neg> seconded, thanks for hosting the meeting 11:36 < morimoto> 2nd 11:36 < pinchartl> meeting adjourned, thank you all for attending, and have a nice day !