On Wed, Feb 9, 2011 at 7:12 AM, Alex Deucher <alexdeuc...@gmail.com> wrote: > On Tue, Feb 8, 2011 at 5:47 PM, Andy Walls <awa...@md.metrocast.net> wrote: >> On Tue, 2011-02-08 at 10:28 -0500, Alex Deucher wrote: >>> On Tue, Feb 8, 2011 at 4:47 AM, Hans Verkuil <hansv...@cisco.com> wrote: >>> > Just two quick notes. I'll try to do a full review this weekend. >>> > >>> > On Tuesday, February 08, 2011 10:30:22 Tomasz Stanislawski wrote: >>> >> ============== >>> >> Introduction >>> >> ============== >>> >> >>> >> The purpose of this RFC is to discuss the driver for a TV output >>> >> interface >>> >> available in upcoming Samsung SoC. The HW is able to generate digital and >>> >> analog signals. Current version of the driver supports only digital >>> >> output. >>> >> >>> >> Internally the driver uses videobuf2 framework, and CMA memory allocator. >>> > Not >>> >> all of them are merged by now, but I decided to post the sources to start >>> >> discussion driver's design. >> >>> > >>> > Cisco (i.e. a few colleagues and myself) are working on this. We hope to >>> > post >>> > an RFC by the end of this month. We also have a proposal for CEC support >>> > in >>> > the pipeline. >>> >>> Any reason to not use the drm kms APIs for modesetting, display >>> configuration, and hotplug support? We already have the >>> infrastructure in place for complex display configurations and >>> generating events for hotplug interrupts. It would seem to make more >>> sense to me to fix any deficiencies in the KMS APIs than to spin a new >>> API. Things like CEC would be a natural fit since a lot of desktop >>> GPUs support hdmi audio/3d/etc. and are already using kms. >>> >>> Alex >> >> I'll toss one out: lack of API documentation for driver or application >> developers to use. >> >> >> When I last looked at converting ivtvfb to use DRM, KMS, TTM, etc. (to >> possibly get rid of reliance on the ivtv X video driver >> http://dl.ivtvdriver.org/xf86-video-ivtv/ ), I found the documentation >> was really sparse. >> >> DRM had the most documentation under Documentation/DocBook/drm.tmpl, but >> the userland API wasn't fleshed out. GEM was talked about a bit in >> there as well, IIRC. >> >> TTM documentation was essentially non-existant. >> >> I can't find any KMS documentation either. >> >> I recall having to read much of the drm code, and having to look at the >> radeon driver, just to tease out what the DRM ioctls needed to do. >> >> Am I missing a Documentation source for the APIs?
Yes, My summer of code project's purpose was to create something of a tutorial for writing a KMS driver. The code, split out into something like 15 step-by-step patches, and accompanying documentation are available from Google's website. http://code.google.com/p/google-summer-of-code-2010-xorg/downloads/detail?name=Matt_Turner.tar.gz My repository (doesn't include the documentation) is available here: http://git.kernel.org/?p=linux/kernel/git/mattst88/glint.git;a=summary There's a 'rebased' branch that contains API changes required for the code to work with 2.6.37~. I hope it's useful to you. I can't image how the lack of documentation of an used and tested API could be a serious reason to write you own. That makes absolutely no sense to me, so I hope you'll decide to use KMS. Matt -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
