summaryrefslogtreecommitdiff
path: root/libdrm
AgeCommit message (Collapse)Author
2007-02-25drm: remove unnecessary NULL checks, and fix some indents..Jakob Bornecrantz
2007-02-16Simple fence object sample driver for via, based on idling the GPU.Thomas Hellstrom
Buffer object driver for via. Some changes to buffer object driver callbacks. Improve fence flushing.
2007-02-15Initial support for fence object classes.Thomas Hellstrom
(Fence objects belonging to different command submission mechanisms).
2006-11-09libdrm: add drmOpenOnce + drmCloseOnce to libdrmDave Airlie
2006-11-08libdrm: add support for server side functionality in libdrmDave Airlie
This adds APIs to allow the X server to use libdrm from the system rather than its own in-built copy.
2006-10-29Minor bugfix, indentation and removal of unnused variables.Thomas Hellstrom
2006-10-27Reserve the new IOCTLs also for *bsd.Thomas Hellstrom
Bump libdrm version number to 2.2.0
2006-10-27Last minute changes to support multi-page size buffer offset alignments.Thomas Hellstrom
This will come in very handy for tiled buffers on intel hardware. Also add some padding to interface structures to allow future binary backwards compatible changes.
2006-10-18Merging drm-ttm-0-2-branchThomas Hellstrom
Conflicts: linux-core/drmP.h linux-core/drm_drv.c linux-core/drm_irq.c linux-core/drm_stub.c shared-core/drm.h shared-core/i915_drv.h shared-core/i915_irq.c
2006-10-17Remove some debugging messages.Thomas Hellstrom
2006-10-17Remove max number of locked pages check and call, sinceThomas Hellstrom
that is now handled by the memory accounting.
2006-10-17Implement mm_lock and mm_unlock functions.Thomas Hellstrom
The mm_lock function is used when leaving vt. It evicts _all_ buffers. Buffers with the DRM_BO_NO_MOVE attribute set will be guaranteed to get the same offset when / if they are rebound.
2006-10-17Extend generality for more memory types.Thomas Hellstrom
Fix up init and destruction code.
2006-10-11Compatibility code for 2.6.15-2.6.18. It is ugly but a little comfort is thatThomas Hellstrom
it will go away in the mainstream kernel. Some bugfixes, mainly in error paths.
2006-10-11Big update:Thomas Hellstrom
Adapt for new functions in the 2.6.19 kernel. Remove the ability to have multiple regions in one TTM. This simplifies a lot of code. Remove the ability to access TTMs from user space. We don't need it anymore without ttm regions. Don't change caching policy for evicted buffers. Instead change it only when the buffer is accessed by the CPU (on the first page fault). This tremendously speeds up eviction rates. Current code is safe for kernels <= 2.6.14. Should also be OK with 2.6.19 and above.
2006-10-02Bug 6242: [mach64] Use private DMA buffers, part #3.George Sapountzis
Add DRM_PCI_BUFFER_RO flag for mapping PCI DMA buffer read-only. An additional flag is needed, since PCI DMA buffers do not have an associated map.
2006-10-02Make the user_token 44-bit for TTMs, and have them occupy a unique file spaceThomas Hellstrom
starting at 0x00100000000. This will hopefully allow us to use unmap_mapping_range(). Note that user-space will need 64-bit file offset support.
2006-09-29Core vsync: Add flag DRM_VBLANK_NEXTONMISS.Michel Dänzer
When this flag is set and the target sequence is missed, wait for the next vertical blank instead of returning immediately. (cherry picked from 89e323e4900af84cc33219ad24eb0b435a039d23 commit)
2006-09-29Add definition of DRM_VBLANK_SECONDARY.Michel Dänzer
(cherry picked from 84b38b63f05e04ade8b1ddfb770047fd86de0d64 commit)
2006-09-29Add support for tracking drawable information to coreMichel Dänzer
Actually make the existing ioctls for adding and removing drawables do something useful, and add another ioctl for the X server to update drawable information. The only kind of drawable information tracked so far is cliprects. (cherry picked from 29598e5253ff5c085ccf63580fd24b84db848424 commit)
2006-09-28Core vsync: Add flag DRM_VBLANK_NEXTONMISS.Michel Dänzer
When this flag is set and the target sequence is missed, wait for the next vertical blank instead of returning immediately.
2006-09-28Add definition of DRM_VBLANK_SECONDARY.Michel Dänzer
2006-09-28Add support for tracking drawable information to coreMichel Dänzer
Actually make the existing ioctls for adding and removing drawables do something useful, and add another ioctl for the X server to update drawable information. The only kind of drawable information tracked so far is cliprects.
2006-09-26Silence valgrind.Thomas Hellstrom
2006-09-20Allow for 64-bit map handles of ttms and buffer objects.Thomas Hellstrom
2006-09-18Alternative implementation of page table zeroing using zap page_range.Thomas Hellstrom
(Disabled for now) Fix bo_wait_idle bug. Remove stray debug message.
2006-09-18More verbose error reporting in some cases.Thomas Hellstrom
Add a buffer object waitIdle user-space function. Fix some names and minor glitches.
2006-09-15Some bugfixes.Thomas Hellstrom
Change the fence object interface somewhat to allow some more flexibility. Make list IOCTLS really restartable. Try to avoid busy-waits in the kernel using immediate return to user-space with an -EAGAIN.
2006-09-12Use lazy fence wait when possible even for RW fences. Saves some CPU.Thomas Hellstrom
Lindent.
2006-09-12More bugfixes.Thomas Hellstrom
Disable the i915 IRQ turnoff for now since it seems to be causing problems.
2006-09-08Various bugfixes.Thomas Hellstrom
2006-09-05Multithreaded application note.Thomas Hellstrom
2006-09-05Fence all unfenced buffers function.Thomas Hellstrom
2006-09-04Libdrm function headers. Some renaming.Thomas Hellstrom
2006-09-01Flag bit pattern bugfixes. Remove some error messages.Thomas Hellstrom
2006-09-01Export buffer info on map and validate ioctls.Thomas Hellstrom
Add an info ioctl operation.
2006-09-01Various bugfixes.Thomas Hellstrom
2006-08-31More mapping synchronization.Thomas Hellstrom
libdrm validate and fencing functions.
2006-08-30Remove the buffer object hint field and use it onlyThomas Hellstrom
as an argument. Validate stub.
2006-08-30Add missing map flags.Thomas Hellstrom
2006-08-30Buffer object mapping and mapping synchronization for multiple clients.Thomas Hellstrom
2006-08-30Memory manager init and takedown.Thomas Hellstrom
2006-08-29Part of buffer object libdrm interface.Thomas Hellstrom
2006-08-29Checkpoint commit. Buffer object flags and IOCTL argument list.Thomas Hellstrom
2006-08-2964-bit IOCTL integer (Michel Dänzer & Brian Paul)Thomas Hellstrom
2006-08-28Add a 64-bit drm unsigned type for 64-bit clean IOCTLS.Thomas Hellstrom
Conversion functions in drmP.h and xf86drm.c.
2006-08-27Bugfixes.Thomas Hellstrom
2006-08-27Remove the ioctl multiplexing, and instead allow for genericThomas Hellstrom
drm ioctls 0x80 - 0xFF.
2006-08-22Add a fence object class field for future use (For example VSYNC fence objects)Thomas Hellstrom
2006-08-21User / Kernel space fence objects (device-independent part).Thomas Hellstrom
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-30 20:58:17 +0000
orimoto: maybe we can revisit next quarter? 09:22 < morimoto> By SoW do you mena ? 09:23 < morimoto> s/mena/mean/ 09:23 < pinchartl> note that the latest patch series should improve the hotplug use cases, so maybe the problem has been fixed 09:23 < pinchartl> (maybe...) 09:23 < dammsan> morimoto: no, when pincharl is back from vacation 09:23 < morimoto> Ahh, OK, np 09:23 < morimoto> not urgent, but I wanted to tell 09:24 < pinchartl> thank you 09:24 < dammsan> morimoto: thanks for sharing 09:24 < pinchartl> morimoto: your turn 09:24 < morimoto> OK 09:24 < morimoto> Before my ABC, I have request to Laurent (before vacation :) 09:25 < pinchartl> go ahead 09:25 < morimoto> BSP team is waiting answer from you, about 09:25 < morimoto> Subject: About Graphics Performance 09:25 < morimoto> Date: Wed, 8 Feb 2017 10:04:54 +0900 09:25 < morimoto> Please makes BSP team happy :P 09:25 < pinchartl> that's the second topic for today, as I mentioned when we started the meeting :) 09:25 < morimoto> OK 09:25 < morimoto> A) What have I done since last time: 09:25 < morimoto> - I posted OF-graph patch again. 09:26 < morimoto> - I created 40bit Descriptor Mode on Audio DMAC 09:26 < morimoto> - Forwarded BSP team question to Multimedia member 09:26 < morimoto> B) What I plan to do till next time: 09:26 < morimoto> - Missing 8ch support on Audio (not urgent) 09:26 < morimoto> - Consider Tx/Rx interrupt sharing (not urgent) 09:26 < morimoto> last one was I reported by email, but finished :P 09:26 < morimoto> C) Problems I have currently: 09:26 < pinchartl> :-) 09:26 < morimoto> - I want to post HDMI sound patch-set which is based on 09:26 < morimoto> posted OF-graph patch-set. Rob's response is... 09:27 < morimoto> D) Posted/Accepted bugfix patches: 09:27 < morimoto> Subject: [PATCH] ASoC: rsnd: fix sound route path when using SRC6/SRC9 09:27 < morimoto> Subject: [PATCH] ASoC: rcar: avoid SSI_MODEx settings for SSI8 09:27 < morimoto> --EOF-- 09:27 < pinchartl> do I need to list those patches or will they be picked up by your script ? 09:28 < morimoto> my script is very clever, more than me :) 09:28 < morimoto> so, D) is no longer needed on meeting, actually 09:28 < pinchartl> :) 09:28 < pinchartl> so Rob said "..." ? 09:29 < morimoto> no response from him 09:29 < morimoto> Am I mistaken 09:29 < morimoto> ? 09:29 < morimoto> Rob is no maintener ? 09:29 < morimoto> s/no/not/ 09:29 < pinchartl> he's a DT maintainer 09:29 < pinchartl> I expect him to be busy this week 09:29 < pinchartl> with Linaro Connect in Budapest 09:30 < morimoto> Ahh... 09:30 < pinchartl> so maybe you should try to ping him next week ? 09:30 < morimoto> OK, will do. thanks 09:31 < pinchartl> you're welcome 09:31 < pinchartl> next, neg 09:31 < neg> a) Started to rework VIN driver for Gen3 to only use media graph and let userspace handle subdevice configuration and supported BSP team with investigation regarding the VIN. 09:31 < neg> b) Complete the VIN Gen3 rewrite. 09:32 < neg> c) None 09:32 < neg> d) None 09:32 < neg> -- EOT of short version, see reply to meeting invatation for more details -- 09:32 < morimoto> Ahh, neg and pinchartl, I sent camera board check request 09:32 < morimoto> please check it 09:32 < pinchartl> should I ignore the issue reported in the e-mail then ? 09:33 < neg> morimoto: I checked and replied to it :-) 09:33 < morimoto> thanks 09:33 < pinchartl> next, uli___ 09:34 < uli___> i tried to get a mainline kernel to run on the acer chromebook r13 09:34 < uli___> to give us a model organism for gpu development 09:34 < uli___> see my status update on how that has failed so far... 09:34 < uli___> the next thing i'm going to do is put together a prototype for a OV10365/MAX9271/MAX9286 camera setup 09:35 < uli___> that's it for now 09:35 < uli___> driver prototype, that is 09:35 < uli___> i'm not completely awake yet :) 09:35 < pinchartl> :-) 09:35 < neg> for the chromebook lack of serial console, is netconsole an option? 09:36 < pinchartl> neg: nope, we have no network 09:36 < pinchartl> the problem at hand is to get a kernel to boot at all 09:36 < pinchartl> it certainly doesn't boot to UI 09:36 < neg> I see than I'm out of ideas :-( 09:36 < pinchartl> and doesn't boot to the network either 09:36 < pinchartl> I still thing our best option is to get this think opened and locate a serial port 09:37 < pinchartl> dammsan: any other idea ? 09:38 < geertu> uli___: "blinky LEDs are behind the embedded controller" 09:38 < uli___> yes 09:38 < geertu> uli___: Can you talk to them through the EC? 09:39 < geertu> (on FOSDEM, there was a presentation about the EC) 09:39 < dammsan> i just asked same thing as geertu over email 09:39 < dammsan> getting an LED to blink would be very nice 09:39 < dammsan> i can take it from there 09:40 < uli___> might work 09:40 < uli___> but the ec driver isn't trivial either 09:41 < pinchartl> why don't anyone listen when I say we should crack the case open ? :-) 09:41 < dammsan> perhaps it is possible to scale it down somehow? 09:41 < uli___> i think writing custom code that talks to the ec is more likely to succeed 09:41 < dammsan> uli___: what do you think about opening it up? 09:42 < pinchartl> there might even be a jtag port inside 09:43 < uli___> i don't know. i'm afraid it might end up open forever, with an unpredictable degree of functionality :) 09:43 < pinchartl> open forever isn't a big issue 09:43 < dammsan> you need to press a key to boot 09:44 < pinchartl> the unpredictable degree of functionality is a bit more annoying 09:46 < pinchartl> so what's the plan there ? 09:46 < uli___> i can look into getting the ec leds to blink 09:47 < dammsan> my hope is that ulrich will hand over his result to me including LED blink code 09:48 < pinchartl> so do you want to go for one more round and try to talk to the EC from a mainline kernel ? 09:49 < dammsan> i can port it 09:49 < dammsan> i've done things like that before 09:49 < dammsan> no biggie 09:49 < pinchartl> I don't have high hopes there, but if you think it's useful, it's your choice :) 09:49 < dammsan> seems our best choice right now 09:49 < pinchartl> I *still* believe the best choice is to open it up 09:49 < dammsan> but please note that next quarter additional batch 1 will not cover the GPU 09:50 < dammsan> to give some time to figure things out 09:50 < geertu> Do we know what's expected to be found inside? 09:50 < dammsan> pinchartl: how about we compete about it in parallel once you are back from vacation? 09:51 < dammsan> =) 09:51 < pinchartl> dammsan: no, thanks, I have lots of work on DU, VSP and VIN already :) 09:51 < dammsan> i'll take a blinky LED over unknown hardware any day 09:51 < dammsan> there you go =) 09:51 < dammsan> answer is pretty clear 09:52 < pinchartl> ok, let's put that on hold then 09:52 < pinchartl> this finishes the status update portion of this meeting 09:53 < pinchartl> Topic 2. Graphics Performance issue 09:53 < pinchartl> this was reported by the BSP team 09:54 < pinchartl> who noticed a performance regression between v4.6 and v4.9 09:54 < pinchartl> due to commit f1f0197796a61e5548af32606f15bcf8cf353267 09:54 < pinchartl> drm: rcar-du: Map memory through the VSP device 09:54 < pinchartl> and commit 60facdbd4d62b863917263bb1ad77bbb4a4a9369 09:54 < pinchartl> v4l: vsp1: Add API to map and unmap DRM buffers through the VSP 09:55 < pinchartl> those two patches ensure proper operation of the DU + VSP on Gen3 when the VSP is behind an IOMMU 09:55 < pinchartl> this is required, but leads to an additional cache flush 09:55 < pinchartl> which in turn degrades performances 09:56 < pinchartl> (~300µs per frame) 09:56 < pinchartl> the cache flush is needed 09:57 < pinchartl> in the sense that, in the general case, the CPU will render to the buffer 09:57 < pinchartl> (of course optimizations are possible when the CPU doesn't touch the buffer, but that's a separate topic) 09:57 < pinchartl> *but* 09:58 < pinchartl> the memory is currently mapped uncached to the CPU 09:58 < pinchartl> so as long as this doesn't change, we could skip the cache handling operations 09:59 < pinchartl> the DMA mapping API supports skipping cache management 09:59 < pinchartl> when the DMA_ATTR_SKIP_CPU_SYNC flag is set 09:59 < pinchartl> s/flag/attribute flag/ 10:00 < pinchartl> we should experiment with that 10:00 < pinchartl> I can give it a try after coming back from vacation 10:00 < pinchartl> and I'll reply to the BSP team's e-mail today with this information 10:00 < pinchartl> morimoto: does this answer your question ? 10:01 < morimoto> Yes, maybe 10:01 < morimoto> something feedback to BSP team makes them happy at this point 10:01 < morimoto> I don't know how urgent it is 10:02 < morimoto> do you think it will be long-term problem ? 10:02 < pinchartl> note that those two commits are not upstream 10:02 < pinchartl> they're part of the IOMMU support work for DU+VSP 10:02 < pinchartl> but haven't been merged yet 10:03 < pinchartl> hopefully it won't be a long-term issue 10:03 < pinchartl> setting the DMA_ATTR_SKIP_CPU_SYNC attribute might be all we need 10:03 < pinchartl> but it has to be analyzed in more details, maybe there's more behind it 10:03 < morimoto> OK, thanks 10:05 < pinchartl> next topic, 10:05 < pinchartl> Topic 3. Multimedia plan 10:05 < pinchartl> which is related to 10:05 < pinchartl> Topic 4. Additional tasks for Q2 10:05 < pinchartl> additional tasks for Q1 are due mid-March 10:05 < pinchartl> so ideally we should already have started negotiating additional tasks for Q2 10:06 < pinchartl> which isn't the case 10:06 < pinchartl> and it realistically can't be finalized before I leave at the end of this week 10:06 < pinchartl> which means we would need to delay additional tasks once again 10:07 < pinchartl> we have, however, started drafting a plan for multimedia development in Q2 and beyond when we were in Portland 10:08 < pinchartl> with task proposals for Q2 10:08 < pinchartl> I thus propose trying more losely-defined additional tasks for the first batch of Q2, with the details shifted from the SoW to the overall multimedia development plan and schedule 10:09 < pinchartl> in practice this means that SoWs could be negotiated faster 10:09 < pinchartl> but the deliverables and milestones will be as clearly defined as before 10:09 < dammsan> sure, we just need a plan =) 10:09 < pinchartl> dammsan: did I send you the spreadsheet we wrote during the meeting ? 10:10 < dammsan> i don't think so 10:10 < pinchartl> I thought I did but couldn't find that in my mailbox 10:10 < pinchartl> ok 10:10 < pinchartl> that's fixed now 10:10 < dammsan> thanks!! 10:11 < neg> if possible I would also like a copy of the portland spreadsheet :-) 10:11 < uli___> same here 10:11 < dammsan> pinchartl: would it be possible for you to extract loose additional tasks for each member from the spread sheet? 10:12 < pinchartl> neg: uli___: done 10:12 < neg> thanks 10:12 < pinchartl> dammsan: the focus is VIN for all team members for the first half of Q2 10:12 < dammsan> pinchartl: or i can do it if you are busy 10:12 < pinchartl> (except for me I suppose, as VSP and DU still need maintenance) 10:13 < pinchartl> so I propose the same additional task for everybody 10:13 < pinchartl> so I propose the same additional task for everybody 10:13 < pinchartl> along the lines of "VIN CSI-2 multiple virtual channels development for Gen3" 10:13 < dammsan> ok, so what is the deliverable then? 10:14 < pinchartl> the type of deliverables is still kernel code, tests, documentation, as usual. posted to the same mailing lists and wikis 10:14 < pinchartl> and the exact tasks are then defined in a plan 10:15 < pinchartl> we had 10:15 < pinchartl> ADV7482 Gen3 support upstream 10:15 < pinchartl> MAX9260 driver prototype (Blanche) 10:15 < pinchartl> MAX9271 driver prototype (Camera) 10:15 < pinchartl> MAX9286 driver prototype with a single channel (Gen3) 10:15 < pinchartl> V4L2 multiplexed stream support (.s_stream(), frame descriptors) 10:15 < pinchartl> V4L2 pad-aware async subdev support 10:15 < pinchartl> we need to revisit the details a bit as MAX9260 + Blanche might not make too much sense at this point 10:16 < pinchartl> (as our PCB development plans got cancelled things may need to be adapted) 10:16 < dammsan> sure 10:17 < dammsan> so based on the spread sheet 10:17 < dammsan> it looks like it is possible to deliver a bunch of prototypes for the first batch 10:18 < dammsan> that would be 5/M as due date 10:19 < pinchartl> yes 10:19 < pinchartl> but there are many dependencies 10:19 < pinchartl> so we'll need to adjust the goals dynamically if some parts get delayed 10:20 < pinchartl> the OV10635 + MAX9271 + MAX9286 prototype is very important in that regard 10:20 < pinchartl> uli___: we all count on you :-) 10:20 < uli___> omg... 10:20 < dammsan> so all tasks marked with Q2/1 can be baked into a single task then? 10:20 < pinchartl> that's my proposal 10:21 < pinchartl> same additional task wording for everybody 10:21 < pinchartl> still with clearly defined goals internally, which can be communicated to Renesas 10:21 < dammsan> sure 10:21 < pinchartl> and we'll follow progress at least bi-weekly during the multimedia meetings 10:21 < dammsan> can you communicate this plan with all members? 10:22 < dammsan> so people not present in portland knows whatis going on 10:22 < pinchartl> I would like to add to the SoWs that team members are responsible for reporting any current or foreseen issue or blocker ASAP to make it possible for the plan to be maintained dynamically 10:22 < pinchartl> let me send the spreadsheet to the periperi list 10:23 < dammsan> so how do we make the task description? 10:23 < pinchartl> or actually I'll attach it to the meeting report 10:23 < dammsan> wait until you're back? 10:23 < pinchartl> do you mean the SoW description or the tasks ? 10:24 < dammsan> i mean the SoW description 10:24 < dammsan> i guess we all want the papers in our hand 10:25 < pinchartl> I would call them something along the line of "VIN CSI-2 multiple virtual channels development for Gen3" 10:25 < pinchartl> all the boilerplate text can be copied from previous SoWs 10:25 < pinchartl> with an additional paragraph asking to report issues and blockers proactively 10:25 < pinchartl> and then a small description of the goal 10:26 < dammsan> okhow about including the list of device drivers? 10:26 < pinchartl> with short-term goals being communicated as part of the multimedia team management 10:26 < pinchartl> yes, I'd include VIN, CSI-2, MAX*, ADV*, ... 10:26 < pinchartl> we should list all of them 10:26 < pinchartl> I can try to send you a draft before I leave 10:26 < dammsan> can we have prototype driver support included as delvierable? 10:27 < pinchartl> yes 10:27 < dammsan> good 10:27 < dammsan> sure, if you can manage before you leave that would be great 10:28 < pinchartl> regarding the work itself and the detailed tasks 10:28 < pinchartl> there's a proposal in the spreadsheet 10:28 < pinchartl> but it will depend on the work Ulrich is doing 10:29 < pinchartl> so we'll still need a few weeks before we can start the work on those external components 10:29 < pinchartl> that's not an issue for Niklas (who will work on the VIN driver itself), Kieran (who will work on ADV7482) or me (who will be away for two weeks anyway) 10:30 < pinchartl> for Jacopo and Ulrich, I think continuing the work on the OV10635 and MAX* is still the next logical step 10:30 < dammsan> sounds good to me 10:31 < pinchartl> jmondi: how long will you still be busy with your current tasks, when will you need new ones ? 10:31 < pinchartl> dammsan: maybe you can help answering that question 10:32 < jmondi> for multimedia only: let's say I can fill this week with test application 10:32 < dammsan> pinchartl: i'm sure jacopo is happy to follow your plan as top priority 10:33 < jmondi> I can buy some time with IO and Core tasks (hopefully some feedback will arrive on both now that 4.12 merge window has closed) 10:33 < jmondi> I can live with what I have been tasked with until the end of March... 10:33 < pinchartl> I'll be back on the 26th of March 10:34 < pinchartl> if you need more work before I come back, there's the OV10635 driver 10:34 < pinchartl> morimoto: I think you mentioned during the Portland meeting that you could get a datasheet (under NDA) for that sensor 10:34 < pinchartl> do you know when we could get it ? 10:34 < jmondi> I can start looking into that, sure... Maybe not deliver that much, but studying it yes 10:35 < jmondi> If my understanding is correct, uli___ has some bsp code I can look at for that driver, right? 10:35 < pinchartl> correct 10:35 < pinchartl> the goal is to turn that into a proper V4L2 subdev driver 10:35 < pinchartl> with the help of the datasheet 10:36 < pinchartl> I think you'll have at least a week of work you can do before having to test anything 10:36 < morimoto> pinchartl: I'm sorry, but which sensor ? 10:36 < pinchartl> OV10635 10:37 < morimoto> ? you didn't get it from Jinso ? 10:37 < pinchartl> let me verify that 10:37 < pinchartl> I got the schematics of the MAX9286 board 10:37 < pinchartl> and the MAX9286 datasheet 10:37 < pinchartl> the MAX9271 datasheet is publicly available so that's fine 10:38 < pinchartl> but I haven't received the OV10635 datasheet 10:38 < morimoto> OK, will check 10:38 < pinchartl> thank you 10:39 < pinchartl> could you please also provide it to Magnus (through Jinso if needed) ? 10:39 < pinchartl> dammsan: and could you then forward it to Jacopo ? 10:39 < pinchartl> or can Jinso provide it to Jacopo directly ? 10:40 < morimoto> pinchartl: will do 10:41 < pinchartl> thank you 10:42 < pinchartl> I think that's all for the plan/additional tasks topic, unless someone has more questions 10:42 < dammsan> sounds good 10:43 < pinchartl> this actually leaves me without additional tasks ;-) 10:43 < jmondi> I'll sync with uli___ to have that bsp driver shared 10:43 < pinchartl> but I'm ok until end of March this time, so we can negotiate them when I'll be back 10:44 < pinchartl> dammsan: is that ok with you ? do you think we can proceed fast at end of March ? 10:44 < jmondi> and wait for that datasheet to land in my inbox from morimoto or dammsan 10:45 < pinchartl> jmondi: it's here https://github.com/CogentEmbedded/meta-rcar/blob/v2.12.0/meta-rcar-gen3/recipes-kernel/linux/linux-renesas/0040-H3-MAX9286-TI964-support-add-10635-10640-cameras.patch 10:46 < jmondi> pinchartl: oh, thanks... 10:46 < jmondi> ov10635.h 1159 lines... loving it already 10:46 < neg> :-) 10:46 < pinchartl> and it combines 3 drivers... it's quite messy 10:47 < pinchartl> there's also https://patchwork.linuxtv.org/patch/18768/ 10:47 < dammsan> pinchartl: i'm flexible 10:47 < jmondi> is this saner? 10:48 < pinchartl> jmondi: in the sense that it's a driver for the ov10635 alone, yes. it has to be ported away from soc-camera 10:48 < pinchartl> dammsan: ok, let's do that then 10:49 < pinchartl> morimoto: as I'll propose additional tasks for me at end of this month, please let me know if there's any particular request from the BSP team 10:49 < morimoto> jmondi, you can find ov10635 (local) driver here 10:49 < morimoto> http://git.ti.com/android-sdk/kernel-omap/blobs/eb15176df1e988393d12a2b8c2becd30078edbd8/drivers/media/i2c/ov10635.c 10:50 < pinchartl> it's the same driver. possibly slightly modified though 10:50 < pinchartl> jmondi: you'll have to consolidate all the code available I think 10:50 < morimoto> pinchartl: will do, with Magnus 10:51 < pinchartl> morimoto: thank you 10:51 < pinchartl> there are also base contracts that need to be renewed 10:51 < pinchartl> dammsan: any news about that ? 10:51 < jmondi> morimoto: pinchartl: thanks both... I'll save these and study 10:52 < morimoto> jmondi: worst case, you can create driver without datasheet :) 10:52 < pinchartl> jmondi: thank you. feel free to first focus on your other tasks, I could then be back when you'll start on the ov10635 to answer questions 10:53 < dammsan> pinchart: base tasks are higher priority than additional 10:53 < dammsan> i think they will be similar to before 10:53 < jmondi> morimoto: and if I know OV datasheet a bit, that would not make a big difference. pinchartl: that's the plan, right! 10:54 < pinchartl> dammsan: ok. I don't really expect anything new there indeed, but if you need any information from me, please let me know 10:54 < dammsan> however the "developer" task might go from per-group to a unified description for all groups 10:54 < pinchartl> I'm fine with that 10:54 < dammsan> the group leader tasks will still be separate 10:54 < pinchartl> it's a base contract anyway, it has to be losely defined 10:54 < pinchartl> thanks. I don't want to start leading other groups, we already have leaders who handle that fine :-) 10:55 < pinchartl> jmondi: the OV datasheets are not perfect, but they can still help 10:55 < pinchartl> dammsan: there's also a 25% base contract for Kieran in the pipe, right ? 10:55 < dammsan> i believee so 10:56 < dammsan> need to double check in the renesas office later this week 10:56 < pinchartl> great, thanks 10:57 < pinchartl> next topics then 10:57 < pinchartl> (let's finish this meeting...) 10:57 < pinchartl> Topic 5. Meeting around LinuxCon Japan 10:57 < pinchartl> uli___: could you please provide your availabilities ? 10:58 < uli___> for linuxcon japan? 10:59 < pinchartl> yes 10:59 < pinchartl> see "[periperi] Meeting around LinuxCon Japan" 10:59 < uli___> not available, i'm afraid 11:00 < pinchartl> not at all ? 11:00 < uli___> no, sorry. 11:00 < pinchartl> ok 11:00 < pinchartl> that's a shame 11:01 < pinchartl> but at least you don't have difficult requirements :-) 11:01 < uli___> always happy to help :) 11:01 < pinchartl> then 11:02 < pinchartl> the result is 11:02 < pinchartl> 66-77-788-77-76 11:02 < pinchartl> (rounded) 11:03 < pinchartl> it's nearly a tie between before LCJ (77) and after (76) 11:04 < pinchartl> I'm tempted to go for 77 in that case 11:04 < pinchartl> but Niklas had a 11 score for that 11:04 < pinchartl> while Kieran and Jacopo have a 43 and 55 score respectively for the two days after the conference 11:05 < pinchartl> neg: how bad would it be for you before LCJ ? 11:05 < neg> managable 11:06 < jmondi> if for Niklas is not that pressing, I would encourage meeting before LCJ :) 11:06 < neg> at this point I'm more focused on setting the date and then I can work around it :-) 11:07 < pinchartl> then I'd rather go for monday-tuesday before the conference, as it has the highest score 11:07 < pinchartl> (nothing personal, it's all 99 for me) 11:08 < neg> works for me 11:08 < pinchartl> thank you 11:08 < pinchartl> then it's settled 11:09 < pinchartl> and I'll propose social events on the weekend after the conference (at least on Saturday) as that's 77 11:09 < pinchartl> I'll be happy to hang out with anyone during the first or second weekend 11:09 < pinchartl> final topic 11:10 < pinchartl> Topic 6. Next meeting 11:10 < pinchartl> as I'll be away for two weeks, we'll have to postpone until end of March 11:10 < pinchartl> I propose the 28th or 29th, same time as today 11:10 < jmondi> works for me (both meeting and conference dates) 11:11 < neg> both ok for me 11:11 < dammsan> same here 11:11 < uli___> slight preference for the 28th 11:12 < pinchartl> then let's go for the 28th. the sooner the better as it will already be late 11:12 < pinchartl> that's all for today 11:12 < pinchartl> sorry for the long meeting 11:13 < neg> thanks all cu next time and pinchartl enjoy africa 11:13 < jmondi> pinchartl: is winter there right? how bad is climate down there? 11:14 < pinchartl> thank you 11:14 < pinchartl> no, it's summer 11:14 < geertu> pinchartl: Enjoy the holidays! 11:14 < morimoto> thanks all, pinchartl: enjoy your holidays 11:15 * jmondi confused on what season is now in his emisphere 11:15 < jmondi> thank you all 11:15 < geertu> jmondi: Winter ;-) 11:17 < dammsan> thanks bye bye 11:17 < uli___> bye, everyone
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-30 20:58:17 +0000