cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Mon Dec 24 19:00:24 CET 2012 git hash:8b2aea7878f64814544d0527c659011949d52358 gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: WARNINGS linux-git-arm-eabi-exynos: OK linux-git-arm-eabi-omap: WARNINGS linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-3.3-i686: WARNINGS linux-3.4-i686: WARNINGS linux-3.5-i686: WARNINGS linux-3.6-i686: WARNINGS linux-3.7-i686: WARNINGS linux-3.8-rc1-i686: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-x86_64: WARNINGS linux-3.4-x86_64: WARNINGS linux-3.5-x86_64: WARNINGS linux-3.6-x86_64: WARNINGS linux-3.7-x86_64: WARNINGS linux-3.8-rc1-x86_64: WARNINGS apps: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 0/5] Common Display Framework
Hi Rob, (CC'ing Hans Verkuil) On Wednesday 19 December 2012 10:05:27 Rob Clark wrote: > On Wed, Dec 19, 2012 at 9:37 AM, Tomi Valkeinen wrote: > > On 2012-12-19 17:26, Rob Clark wrote: > >> And, there are also external HDMI encoders (for example connected over > >> i2c) that can also be shared between boards. So I think there will be > >> a number of cases where CDF is appropriate for HDMI drivers. Although > >> trying to keep this all independent of DRM (as opposed to just something > >> similar to what drivers/gpu/i2c is today) seems a bit overkill for me. > >> Being able to use the helpers in drm and avoiding an extra layer of > >> translation seems like the better option to me. So my vote would be > >> drivers/gpu/cdf. > > > > Well, we need to think about that. I would like to keep CDF independent > > of DRM. I don't like tying different components/frameworks together if > > there's no real need for that. > > > > Also, something that Laurent mentioned in our face-to-face discussions: > > Some IPs/chips can be used for other purposes than with DRM. > > > > He had an example of a board, that (if I understood right) gets video > > signal from somewhere outside the board, processes the signal with some > > IPs/chips, and then outputs the signal. So there's no framebuffer, and > > the image is not stored anywhere. I think the framework used in these > > cases is always v4l2. > > > > The IPs/chips in the above model may be the exact same IPs/chips that > > are used with "normal" display. If the CDF was tied to DRM, using the > > same drivers for normal and these streaming cases would probably not be > > possible. > > Well, maybe there is a way, but it really seems to be over-complicating > things unnecessarily to keep CDF independent of DRM.. there will be a lot > more traditional uses of CDF compared to one crazy use-case. So I don't > really fancy making it more difficult than in needs to be for everyone. Most of the use cases will be in DRM, we agree on that. However, I don't think that the use case mentioned by Tomi is in any way crazy. TI has DaVinci chips that can process/capture/generate up to 18 (if my memory is correct) video streams, and those are extensively used in video conferencing solutions or set top boxes for instance. A couple of the output video streams are display-based and should be handled by DRM/KMS, but most of them are V4L2 streams. That's something we should discuss with Hans Verkuil, he might be able to provide us with more information. > Probably the thing to do is take a step back and reconsider that one crazy > use-case. For example, KMS doesn't enforce that the buffer handled passed > when you create a drm framebuffer object to scan out is a GEM buffer. So on > that one crazy platform, maybe it makes sense to have a DRM/KMS display > driver that takes a handle to identify which video stream coming from the > capture end of the pipeline. Anyways, that is just an off-the-top-of-my- > head idea, probably there are other options too. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 0/5] Common Display Framework
Hi Rob, On Wednesday 19 December 2012 09:26:40 Rob Clark wrote: > On Wed, Dec 19, 2012 at 8:57 AM, Jani Nikula wrote: > > On Tue, 18 Dec 2012, Laurent Pinchart wrote: > >> On Monday 17 December 2012 18:53:37 Jani Nikula wrote: > >>> I can see the need for a framework for DSI panels and such (in fact Tomi > >>> and I have talked about it like 2-3 years ago already!) but what is the > >>> story for HDMI and DP? In particular, what's the relationship between > >>> DRM and CDF here? Is there a world domination plan to switch the DRM > >>> drivers to use this framework too? ;) Do you have some rough plans how > >>> DRM and CDF should work together in general? > >> > >> There's always a world domination plan, isn't there ? :-) > >> > >> I certainly want CDF to be used by DRM (or more accurately KMS). That's > >> what the C stands for, common refers to sharing panel and other display > >> entity drivers between FBDEV, KMS and V4L2. > >> > >> I currently have no plan to expose CDF internals to userspace through the > >> KMS API. We might have to do so later if the hardware complexity grows > >> in such a way that finer control than what KMS provides needs to be > >> exposed to userspace, but I don't think we're there yet. The CDF API > >> will thus only be used internally in the kernel by display controller > >> drivers. The KMS core might get functions to handle common display > >> entity operations, but the bulk of the work will be in the display > >> controller drivers to start with. We will then see what can be > >> abstracted in KMS helper functions. > >> > >> Regarding HDMI and DP, I imagine HDMI and DP drivers that would use the > >> CDF API. That's just a thought for now, I haven't tried to implement > >> them, but it would be nice to handle HDMI screens and DPI/DBI/DSI panels > >> in a generic way. > >> > >> Do you have thoughts to share on this topic ? > > > > It just seems to me that, at least from a DRM/KMS perspective, adding > > another layer (=CDF) for HDMI or DP (or legacy outputs) would be > > overengineering it. They are pretty well standardized, and I don't see > > there would be a need to write multiple display drivers for them. Each > > display controller has one, and can easily handle any chip specific > > requirements right there. It's my gut feeling that an additional > > framework would just get in the way. Perhaps there could be more common > > HDMI/DP helper style code in DRM to reduce overlap across KMS drivers, > > but that's another thing. > > > > So is the HDMI/DP drivers using CDF a more interesting idea from a > > non-DRM perspective? Or, put another way, is it more of an alternative > > to using DRM? Please enlighten me if there's some real benefit here that > > I fail to see! > > fwiw, I think there are at least a couple cases where multiple SoC's > have the same HDMI IP block. > > And, there are also external HDMI encoders (for example connected over > i2c) that can also be shared between boards. So I think there will be > a number of cases where CDF is appropriate for HDMI drivers. Although > trying to keep this all independent of DRM (as opposed to just > something similar to what drivers/gpu/i2c is today) seems a bit > overkill for me. Being able to use the helpers in drm and avoiding an > extra layer of translation seems like the better option to me. So my > vote would be drivers/gpu/cdf. I don't think there will be any need for translation (except perhaps between the DRM mode structures and the common video mode structure that is being discussed). Add a drm_ prefix to the existing CDF functions and structures, and there you go :-) The reason why I'd like to keep CDF separate from DRM (or at least not requiring a drm_device) is that HDMI/DP encoders can be used by pure V4L2 drivers. > > For DSI panels (or DSI-to-whatever bridges) it's of course another > > story. You typically need a panel specific driver. And here I see the > > main point of the whole CDF: decoupling display controllers and the > > panel drivers, and sharing panel (and converter chip) specific drivers > > across display controllers. Making it easy to write new drivers, as > > there would be a model to follow. I'm definitely in favour of coming up > > with some framework that would tackle that. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 0/5] Common Display Framework
Hi Tomi, On Wednesday 19 December 2012 17:07:50 Tomi Valkeinen wrote: > On 2012-12-19 16:57, Jani Nikula wrote: > > It just seems to me that, at least from a DRM/KMS perspective, adding > > another layer (=CDF) for HDMI or DP (or legacy outputs) would be > > overengineering it. They are pretty well standardized, and I don't see > > there would be a need to write multiple display drivers for them. Each > > display controller has one, and can easily handle any chip specific > > requirements right there. It's my gut feeling that an additional > > framework would just get in the way. Perhaps there could be more common > > HDMI/DP helper style code in DRM to reduce overlap across KMS drivers, > > but that's another thing. > > > > So is the HDMI/DP drivers using CDF a more interesting idea from a > > non-DRM perspective? Or, put another way, is it more of an alternative > > to using DRM? Please enlighten me if there's some real benefit here that > > I fail to see! > > The use of CDF is an option, not something that has to be done. A DRM > driver developer may use it if it gives benefit for him for that > particular driver. > > I don't know much about desktop display hardware, but I guess that using > CDF would not really give much there. In some cases it could, if the IPs > used on the graphics card are something that are used elsewhere also > (sounds quite unlikely, though). In that case there could be separate > drivers for the IPs. > > And note that CDF is not really about the dispc side, i.e. the part that > creates the video stream from pixels in the memory. It's more about the > components after that, and how to connect those components. > > > For DSI panels (or DSI-to-whatever bridges) it's of course another > > story. You typically need a panel specific driver. And here I see the > > main point of the whole CDF: decoupling display controllers and the > > panel drivers, and sharing panel (and converter chip) specific drivers > > across display controllers. Making it easy to write new drivers, as > > there would be a model to follow. I'm definitely in favour of coming up > > with some framework that would tackle that. > > Right. But if you implement drivers for DSI panels with CDF for, say, > OMAP, I think it's simpler to use CDF also for HDMI/DP on OMAP. > Otherwise it'll be a mishmash with two different models. I second your point here, using CDF for encoders should be simpler, but it will not be enforced. A display controller driver developer who wants to control the on-SoC encoder without conforming to the CDF model will be totally free to do so and won't be blamed. -- Regards, Laurent Pinchart signature.asc Description: This is a digitally signed message part.
Re: [RFC v2 0/5] Common Display Framework
Hi Jani, On Wednesday 19 December 2012 16:57:56 Jani Nikula wrote: > On Tue, 18 Dec 2012, Laurent Pinchart wrote: > > On Monday 17 December 2012 18:53:37 Jani Nikula wrote: > >> I can see the need for a framework for DSI panels and such (in fact Tomi > >> and I have talked about it like 2-3 years ago already!) but what is the > >> story for HDMI and DP? In particular, what's the relationship between > >> DRM and CDF here? Is there a world domination plan to switch the DRM > >> drivers to use this framework too? ;) Do you have some rough plans how > >> DRM and CDF should work together in general? > > > > There's always a world domination plan, isn't there ? :-) > > > > I certainly want CDF to be used by DRM (or more accurately KMS). That's > > what the C stands for, common refers to sharing panel and other display > > entity drivers between FBDEV, KMS and V4L2. > > > > I currently have no plan to expose CDF internals to userspace through the > > KMS API. We might have to do so later if the hardware complexity grows in > > such a way that finer control than what KMS provides needs to be exposed > > to userspace, but I don't think we're there yet. The CDF API will thus > > only be used internally in the kernel by display controller drivers. The > > KMS core might get functions to handle common display entity operations, > > but the bulk of the work will be in the display controller drivers to > > start with. We will then see what can be abstracted in KMS helper > > functions. > > > > Regarding HDMI and DP, I imagine HDMI and DP drivers that would use the > > CDF API. That's just a thought for now, I haven't tried to implement them, > > but it would be nice to handle HDMI screens and DPI/DBI/DSI panels in a > > generic way. > > > > Do you have thoughts to share on this topic ? > > It just seems to me that, at least from a DRM/KMS perspective, adding > another layer (=CDF) for HDMI or DP (or legacy outputs) would be > overengineering it. They are pretty well standardized, and I don't see there > would be a need to write multiple display drivers for them. Each display > controller has one, and can easily handle any chip specific requirements > right there. It's my gut feeling that an additional framework would just get > in the way. Perhaps there could be more common HDMI/DP helper style code in > DRM to reduce overlap across KMS drivers, but that's another thing. > > So is the HDMI/DP drivers using CDF a more interesting idea from a non-DRM > perspective? Or, put another way, is it more of an alternative to using DRM? > Please enlighten me if there's some real benefit here that I fail to see! As Rob pointed out, you can have external HDMI/DP encoders, and even internal HDMI/DP encoder IPs can be shared between SoCs and SoC vendors. CDF aims at sharing a single driver between SoCs and boards for a given HDMI/DP encoder. CDF isn't an alternative to DRM/KMS. It should be seen as a framework that helps DRM/KMS drivers (as well as V4L2 drivers, and possibly FBDEV drivers, although those should be ported to DRM/KMS) sharing encoder and connector code. > For DSI panels (or DSI-to-whatever bridges) it's of course another story. > You typically need a panel specific driver. And here I see the main point of > the whole CDF: decoupling display controllers and the panel drivers, and > sharing panel (and converter chip) specific drivers across display > controllers. Making it easy to write new drivers, as there would be a model > to follow. I'm definitely in favour of coming up with some framework that > would tackle that. That's the main (and original) goal of CDF (originally called Generic Panel Framwork, and renamed to CDF to support encoder drivers as explained above). I'm glad to know that you're in favour of it :-) -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 0/5] Common Display Framework
Hi Sylwester, On Tuesday 18 December 2012 11:59:35 Sylwester Nawrocki wrote: > On 12/18/2012 07:21 AM, Rob Clark wrote: > > On Mon, Dec 17, 2012 at 11:04 PM, Dave Airlie wrote: > >> So this might be a bit off topic but this whole CDF triggered me > >> looking at stuff I generally avoid: > >> > >> The biggest problem I'm having currently with the whole ARM graphics > >> and output world is the proliferation of platform drivers for every > >> little thing. The whole ordering of operations with respect to things > >> like suspend/resume or dynamic power management is going to be a real > >> nightmare if there are dependencies between the drivers. How do you > >> enforce ordering of s/r operations between all the various components? > > There have been already some ideas proposed to resolve this at the PM > subsystem level [1]. And this problem is of course not only specific to > platform drivers. The idea of having monolithic drivers, just because we > can't get the suspend/resume sequences right otherwise, doesn't really sound > appealing. SoC IPs get reused on multiple different SoC series, no only by > single manufacturer. Whole graphics/video subsystems are composed from > smaller blocks in SoCs, with various number of distinct sub-blocks and same > sub-blocks repeated different number of times in a specific SoC revision. > Expressing an IP as a platform device seems justified to me, often these > platform devices have enough differences to treat them as such. E.g. belong > in different power domain/use different clocks. Except there is big issue > with the power management... However probably more important is to be able > to have driver for a specific IP in a separate module. > > And this suspend/resume ordering issue is not only about the platform > devices. E.g. camera subsystem can be composed of an image sensor sub-device > driver, which is most often an I2C client driver, and of multiple SoC > processing blocks. The image sensor can have dependencies on the SoC sub- > blocks. So even if we created monolithic driver for the SoC part, there are > still two pieces to get s/r ordering right - I2C client and SoC drivers. And > please don't propose to merge the sensor sub-device driver too. There has > been a lot of effort in V4L2 to separate those various functional blocks > into sub-devices, so they can be freely reused, without reimplementing same > functionality in each driver. BTW, there has been a nice talk about these > topics at ELCE [2], particularly slide 22 is interesting. > > I believe the solution for these issues really needs to be sought in the PM > subsystem itself. I tend to agree with you, or at least I believe we should research a proper solution in the PM framework. In the meantime, though, I think early suspend/late resume might provide an intermediate solution. > > I tend to think that sub-devices are useful just to have a way to > > probe hw which may or may not be there, since on ARM we often don't > > have any alternative.. but beyond that, suspend/resume, and other > > life-cycle aspects, they should really be treated as all one device. > > Especially to avoid undefined suspend/resume ordering. > > [1] https://lkml.org/lkml/2009/9/9/373 > [2] > http://elinux.org/images/9/90/ELCE2012-Modular-Graphics-on-Embedded-ARM.pdf -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 0/5] Common Display Framework
Hi Marcus, On Tuesday 18 December 2012 11:39:11 Marcus Lorentzon wrote: > On 12/18/2012 06:04 AM, Dave Airlie wrote: > >> Many developers showed interest in the first RFC, and I've had the > >> opportunity to discuss it with most of them. I would like to thank (in > >> no particular order) Tomi Valkeinen for all the time he spend helping me > >> to draft v2, Marcus Lorentzon for his useful input during Linaro Connect > >> Q4 2012, and Linaro for inviting me to Connect and providing a venue to > >> discuss this topic. > > > > So this might be a bit off topic but this whole CDF triggered me > > looking at stuff I generally avoid: > > I like the effort, right now it seems like x86 and arm display sub systems > are quite different in terms of DRM driver (and HW) design. I think this is > partly due to little information shared about these different architectures > and ideas behind the choices made. I hope some discussion will light up both > sides. And an early discussion will hopefully give you less pain when CDF > drivers starts to get pushed your way. On the topic of discussions, would anyone be interested in a BoF/brainstorming/whatever session during the FOSDEM ? > > The biggest problem I'm having currently with the whole ARM graphics > > and output world is the proliferation of platform drivers for every > > little thing. The whole ordering of operations with respect to things > > like suspend/resume or dynamic power management is going to be a real > > nightmare if there are dependencies between the drivers. How do you > > enforce ordering of s/r operations between all the various components? > > Could you give an example? Personally I don't think it is that many. I > might not have counted the plat devs in all arm drivers. But the STE one > have one per HW IP block in the HW (1 DSS + 3 DSI encoder/formatters). > Then of course there are all these panel devices. But I hope that when > CDF is "finished" we will have DSI devices on the DSI bus and DBI > devices on the DBI bus. I think most vendors have used platform devices > for these since they normally can't be probed in a generic way. But as > they are off SoC I feel this is not the best choice. And then many of > the panels are I2C devices (control bus) and that I guess is similar to > "x86" encoders/connectors? Tomi Valkeinen proposed dropping the DSI and DBI busses in favor of the platform bus. Although I still believe that DSI and DBI busses would make sense, I agree that they don't provide much in terms of probing and power management. You can read the discussion at http://www.spinics.net/lists/linux- fbdev/msg09250.html. > Another part of the difference I feel is that in x86 a DRM device is > most likely a PCI device, and as such has one huge driver for all IPs on > that board. The closest thing we get to that in ARM is probably the DSS > (collection of IPs on SoC, like 3D, 2D, display output, encoders). But > it doesn't fell right to create a single driver for all these. And as > you know often 3D is even from a separate vendor. All these lead up to a > slight increase in the number of devices and drivers. Right way, I feel > so, but you are welcome to show a better way. > > > The other thing I'd like you guys to do is kill the idea of fbdev and > > v4l drivers that are "shared" with the drm codebase, really just > > implement fbdev and v4l on top of the drm layer, some people might > > think this is some sort of maintainer thing, but really nothing else > > makes sense, and having these shared display frameworks just to avoid > > having using drm/kms drivers seems totally pointless. Fix the drm > > fbdev emulation if an fbdev interface is needed. But creating a fourth > > framework because our previous 3 frameworks didn't work out doesn't > > seem like a situation I want to get behind too much. > > I have no intention to use CDF outside KMS connector/encoder and I have > not heard Laurent talk about this either. I don't either. CDF will mostly target KMS connectors, and can also be used for KMS encoders. I have no plan to touch the CRTC. > Personally I see CDF as "helpers" to create and reuse connector/encoder > drivers between SoCs instead of each SoC do their own panel drivers (which > would be about a hundred, times the number of supported SoCs). We probably > need to discuss the connector/encoder mappings to CDF/panels. That's a topic I was planning to discuss at some point. One of the issues is that the KMS model can only have 3 entities in the pipeline, while hardware pipelines (especially in the embedded world) could be made of 4 or more entities (such as CRTC -> DSI encoder -> DSI to HDMI converter -> HDMI connector). We might not have to expose all details to userspace, but we need mapping rules. > But I think we need to flush out the higher level details like control bus > vs. data bus vs. display entities. While I like the generic way of the > display entities, I also like the pure bus/device/driver model with
Re: em28xx: module parameter prefer_bulk ?
Em Mon, 24 Dec 2012 12:25:38 +0100 Frank Schäfer escreveu: > Hi Mauro, > > now that we prefer bulk transfers for webcams and isoc transfers for TV, > I wonder if prefer_bulk is still a good name for this module parameter. > What about something like 'usb_mode', 'usb_xfer_mode' or > 'frame_xfer_mode' with 0=auto, 1=prefer isoc, 2=prefer bulk ? while keeping it as-is is not bad, IMHO, we can change it if people prefer renaming it. usb_xfer_mode sounds good for me. Feel free to submit a patch if you want. It should be noticed that we can change it while it was not upstreamed. With regards to the range, we generally use -1 for "auto" (at least, we do that on several other places). -- Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Patch update notification: 37 patches updated
Em Mon, 24 Dec 2012 11:56:22 +0100 Frank Schäfer escreveu: > Am 23.12.2012 15:57, schrieb Mauro Carvalho Chehab: > > Em Sun, 23 Dec 2012 14:45:31 +0100 > > Frank Schäfer escreveu: > > > >> Hi Mauro, > >> > >> Am 23.12.2012 01:08, schrieb Patchwork: > >>> Hello, > >>> > >>> The following patches (submitted by you) have been updated in patchwork: > >>> > >>> * [3/6] em28xx: fix capture type setting in em28xx_urb_data_copy_vbi() > >>> - http://patchwork.linuxtv.org/patch/15651/ > >>> was: New > >>> now: Accepted > >>> > >>> * [8/9] em28xx: move the em2710/em2750/em28xx specific frame data > >>> processing code to a separate function > >>> - http://patchwork.linuxtv.org/patch/15798/ > >>> was: New > >>> now: Accepted > >>> > >>> * [4/6] em28xx: fix/improve frame field handling in > >>> em28xx_urb_data_copy_vbi() > >>> - http://patchwork.linuxtv.org/patch/15652/ > >>> was: New > >>> now: Accepted > >> This patch has not been applied yet to the media-tree. > >> Without this patch, frame data processing for non-interlaced devices is > >> broken. > > Not sure what happened there: I couldn't see this specific patch. Yet, > > at least some of the changes there seem to be applied. My guess is that > > somehow, this patch got merged with some other patch, or maybe the > > conflicts solving when the vbi-merge patches got applied (partially) > > fixed it. > > > > In any case, you'll need to rebase it, as it doesn't apply anymore. > > Ok, I did a git diff against my local version and all changes (except > the remaining i2c stuff) seem to be applied. > > One thing I noticed: you fixed strings with lines > 80 characters. > This is handled differently everywhere... > I know splitting strings breaks grepping, OTOH checkpatch complains. > So you prefer violating the 80 chars rule ? 80-chars is a warning, and, from time to time, it rises discussions here and at LKML, as there are know cases where this is violated for good. We prefer to not break long string lines due to grep. It also can makes the code a little more obfuscate (like on one place on your patchset where the same string was broken into 3 or 4 lines). The hole idea of the 80 cols rule is to avoid obfuscation, by avoiding having complex logic inside the Kernel, and not to create more obfuscation ;) Of course, we don't want a big "style fix" patch changing it, but, as the code is being touched, we fix those style stuff. Regards, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 0/5] Common Display Framework
Hi Tomasz, On Friday 21 December 2012 11:00:52 Tomasz Figa wrote: > On Tuesday 18 of December 2012 08:31:30 Vikas Sajjan wrote: > > On 17 December 2012 20:55, Laurent Pinchart wrote: > > > Hi Vikas, > > > > > > Sorry for the late reply. I now have more time to work on CDF, so > > > delays should be much shorter. > > > > > > On Thursday 06 December 2012 10:51:15 Vikas Sajjan wrote: > > > > Hi Laurent, > > > > > > > > I was thinking of porting CDF to samsung EXYNOS 5250 platform, what > > > > I found is that, the exynos display controller is MIPI DSI based > > > > controller. > > > > > > > > But if I look at CDF patches, it has only support for MIPI DBI based > > > > Display controller. > > > > > > > > So my question is, do we have any generic framework for MIPI DSI > > > > based display controller? basically I wanted to know, how to go about > > > > porting CDF for such kind of display controller. > > > > > > MIPI DSI support is not available yet. The only reason for that is > > > that I don't have any MIPI DSI hardware to write and test the code > > > with :-) > > > > > > The common display framework should definitely support MIPI DSI. I > > > think the existing MIPI DBI code could be used as a base, so the > > > implementation shouldn't be too high. > > > > > > Yeah, i was also thinking in similar lines, below is my though for > > > MIPI DSI support in CDF. > > > > o MIPI DSI support as part of CDF framework will expose > > § mipi_dsi_register_device(mpi_device) (will be called mach-xxx-dt.c > > file ) > > § mipi_dsi_register_driver(mipi_driver, bus ops) (will be called from > > platform specific init driver call ) > > ·bus ops will be > > o read data > > o write data > > o write command > > § MIPI DSI will be registered as bus_register() > > > > When MIPI DSI probe is called, it (e.g., Exynos or OMAP MIPI DSI) will > > initialize the MIPI DSI HW IP. > > > > This probe will also parse the DT file for MIPI DSI based panel, add > > the panel device (device_add() ) to kernel and register the display > > entity with its control and video ops with CDF. > > > > I can give this a try. > > I am currently in progress of reworking Exynos MIPI DSIM code and s6e8ax0 > LCD driver to use the v2 RFC of Common Display Framework. I have most of > the work done, I have just to solve several remaining problems. Do you already have code that you can publish ? I'm particularly interested (and I think Tomi Valkeinen would be as well) in looking at the DSI operations you expose to DSI sinks (panels, transceivers, ...). -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 0/5] Common Display Framework
Hi Inki, On Tuesday 18 December 2012 18:38:31 Inki Dae wrote: > 2012/12/18 Daniel Vetter > > On Tue, Dec 18, 2012 at 7:21 AM, Rob Clark wrote: > > >> The other thing I'd like you guys to do is kill the idea of fbdev and > > >> v4l drivers that are "shared" with the drm codebase, really just > > >> implement fbdev and v4l on top of the drm layer, some people might > > >> think this is some sort of maintainer thing, but really nothing else > > >> makes sense, and having these shared display frameworks just to avoid > > >> having using drm/kms drivers seems totally pointless. Fix the drm > > >> fbdev emulation if an fbdev interface is needed. But creating a fourth > > >> framework because our previous 3 frameworks didn't work out doesn't > > >> seem like a situation I want to get behind too much. > > > > > > yeah, let's not have multiple frameworks to do the same thing.. For > > > fbdev, it is pretty clear that it is a dead end. For v4l2 > > > (subdev+mcf), it is perhaps bit more flexible when it comes to random > > > arbitrary hw pipelines than kms. But to take advantage of that, your > > > userspace isn't going to be portable anyways, so you might as well use > > > driver specific properties/ioctls. But I tend to think that is more > > > useful for cameras. And from userspace perspective, kms planes are > > > less painful to use for output than v4l2, so lets stick to drm/kms for > > > output (and not try to add camera/capture support to kms).. k, thx > > > > Yeah, I guess having a v4l device also exported by the same driver > > that exports the drm interface might make sense in some cases. But in > > many cases I think the video part is just an independent IP block and > > shuffling data around with dma-buf is all we really need. So yeah, I > > guess sharing display resources between v4l and drm kms driver should > > be a last resort option, since coordination (especially if it's > > supposed to be somewhat dynamic) will be extremely hairy. > > I think the one reason that the CDF was appeared is to avoid duplicating > codes. For example, we should duplicate mipi-dsi or dbi drivers into drm to > avoid ordering issue. And for this, those should be re-implemented in based > on drm framework so that those could be treated as all one device. > Actually, in case of Exynos, some guys tried to duplicate eDP driver into > exynos drm framework in same issue. So I think the best way is to avoid > duplicating codes and resolve ordering issue such as s/r operations between > all the various components. > > And the below is my opinion, > > ++ > Display Controller CDF - |MIPI-DSI/DBI---LCD Panel| > ++ > > 1. to access MIPI-DSI/DBI and LCD Panel drivers. > - Display Controller is controlled by linux framebuffer or drm kms > based specific drivers like now. And each driver calls some interfaces of > CDF. > > 2. to control the power of these devices. > - drm kms based specific driver calls dpms operation and next the dpms > operation calls fb blank operation of linux framebuffer. > But for this, we need some interfaces that it can connect between drm > and linux framebuffer framework and you can refer to the below link. > > http://lists.freedesktop.org/archives/dri-devel/2011-July/013242.html (Just FYI, I plan to clean up the backlight framework when I'll be done with CDF, to remove the FBDEV dependency) > - linux framebuffer based driver calls fb blank operation. > > fb blank(fb)-pm runtime(fb)---fb_blank--mipi and lcd > dpms(drm kms)pm runtime(drm kms)--fb_blank--mipi and lcd > > 3. suspend/resume > - pm suspend/resume are implemented only in linux framebuffer or drm > kms based specific drivers. > - MIPI-DSI/DBI and LCD Panel drivers are controlled only by fb blank > interfaces. > > s/r(fb)pm runtime(fb)fb blank---mipi and lcd > s/r(drm kms)---dpms(drm kms)---pm runtime(drm kms)---fb_blank---mipi and lcd > > > We could resolve ordering issue to suspend/resume simply duplicating > relevant drivers but couldn't avoid duplicating codes. So I think we could > avoid the ordering issue using fb blank interface of linux framebuffer and > also duplicating codes. As I mentioned before, we have multiple ordering issues related to suspend and resume. Panels and display controllers will likely want to enforce a S/R order on the video bus, and control busses will also require a specific S/R order. My plan is to use early suspend/late resume in the display controller driver to control the video busses, and let the PM core handle control bus ordering issues. This will of course need to be prototyped and tested. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a messa
Re: [RFC v2 0/5] Common Display Framework
Hi Daniel, On Tuesday 18 December 2012 09:30:00 Daniel Vetter wrote: > On Tue, Dec 18, 2012 at 7:21 AM, Rob Clark wrote: > >> The other thing I'd like you guys to do is kill the idea of fbdev and > >> v4l drivers that are "shared" with the drm codebase, really just > >> implement fbdev and v4l on top of the drm layer, some people might > >> think this is some sort of maintainer thing, but really nothing else > >> makes sense, and having these shared display frameworks just to avoid > >> having using drm/kms drivers seems totally pointless. Fix the drm > >> fbdev emulation if an fbdev interface is needed. But creating a fourth > >> framework because our previous 3 frameworks didn't work out doesn't > >> seem like a situation I want to get behind too much. > > > > yeah, let's not have multiple frameworks to do the same thing.. For > > fbdev, it is pretty clear that it is a dead end. For v4l2 > > (subdev+mcf), it is perhaps bit more flexible when it comes to random > > arbitrary hw pipelines than kms. But to take advantage of that, your > > userspace isn't going to be portable anyways, so you might as well use > > driver specific properties/ioctls. But I tend to think that is more > > useful for cameras. And from userspace perspective, kms planes are > > less painful to use for output than v4l2, so lets stick to drm/kms for > > output (and not try to add camera/capture support to kms).. k, thx > > Yeah, I guess having a v4l device also exported by the same driver that > exports the drm interface might make sense in some cases. But in many cases > I think the video part is just an independent IP block and shuffling data > around with dma-buf is all we really need. So yeah, I guess sharing display > resources between v4l and drm kms driver should be a last resort option, > since coordination (especially if it's supposed to be somewhat dynamic) will > be extremely hairy. I totally agree. As explained in my replies to Dave and Rob, I don't want to share devices between the different subsystems at runtime, but I'd like to avoid writing two drivers for a single device that can be used for display and graphics on one board, and video output on another board (HDMI transmitters are a good example). -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 0/5] Common Display Framework
Hi Rob, On Tuesday 18 December 2012 00:21:32 Rob Clark wrote: > On Mon, Dec 17, 2012 at 11:04 PM, Dave Airlie wrote: > >> Many developers showed interest in the first RFC, and I've had the > >> opportunity to discuss it with most of them. I would like to thank (in > >> no particular order) Tomi Valkeinen for all the time he spend helping me > >> to draft v2, Marcus Lorentzon for his useful input during Linaro Connect > >> Q4 2012, and Linaro for inviting me to Connect and providing a venue to > >> discuss this topic. > > > > So this might be a bit off topic but this whole CDF triggered me > > looking at stuff I generally avoid: > > > > The biggest problem I'm having currently with the whole ARM graphics > > and output world is the proliferation of platform drivers for every > > little thing. The whole ordering of operations with respect to things > > like suspend/resume or dynamic power management is going to be a real > > nightmare if there are dependencies between the drivers. How do you > > enforce ordering of s/r operations between all the various components? > > I tend to think that sub-devices are useful just to have a way to probe hw > which may or may not be there, since on ARM we often don't have any > alternative.. but beyond that, suspend/resume, and other life-cycle aspects, > they should really be treated as all one device. Especially to avoid > undefined suspend/resume ordering. I tend to agree, except that I try to reuse the existing PM infrastructure when possible to avoid reinventing the wheel. So far handling suspend/resume ordering related to data busses in early suspend/late resume operations and allowing the Linux PM core to handle control busses using the Linux device tree worked pretty well. > CDF or some sort of mechanism to share panel drivers between drivers is > useful. Keeping it within drm, is probably a good idea, if nothing else to > simplify re-use of helper fxns (like avi-infoframe stuff, for example) and > avoid dealing with merging changes across multiple trees. Treating them more > like shared libraries and less like sub-devices which can be dynamically > loaded/unloaded (ie. they should be not built as separate modules or > suspend/resumed or probed/removed independently of the master driver) is a > really good idea to avoid uncovering nasty synchronization issues later > (remove vs modeset or pageflip) or surprising userspace in bad ways. We've tried that in V4L2 years ago and realized that the approach led to a dead-end, especially when OF/DT got involved. With DT-based device probing, I2C camera sensors started getting probed asynchronously to the main camera device, as they are children of the I2C bus master. We will have similar issues with I2C HDMI transmitters or panels, so we should be prepared for it. On PC hardware the I2C devices are connected to an I2C master provided by the GPU, but on embedded devices they are usually connected to an independent I2C master. We thus can't have a single self-contained driver that controls everything internally, and need to interface with the rest of the SoC drivers. I agree that probing/removing devices independently of the master driver can lead to bad surprises, which is why I want to establish clear rules in CDF regarding what can and can't be done with display entities. Reference counting will be one way to make sure that devices don't disappear all of a sudden. > > The other thing I'd like you guys to do is kill the idea of fbdev and > > v4l drivers that are "shared" with the drm codebase, really just > > implement fbdev and v4l on top of the drm layer, some people might > > think this is some sort of maintainer thing, but really nothing else > > makes sense, and having these shared display frameworks just to avoid > > having using drm/kms drivers seems totally pointless. Fix the drm > > fbdev emulation if an fbdev interface is needed. But creating a fourth > > framework because our previous 3 frameworks didn't work out doesn't > > seem like a situation I want to get behind too much. > > yeah, let's not have multiple frameworks to do the same thing.. For fbdev, > it is pretty clear that it is a dead end. For v4l2 (subdev+mcf), it is > perhaps bit more flexible when it comes to random arbitrary hw pipelines > than kms. But to take advantage of that, your userspace isn't going to be > portable anyways, so you might as well use driver specific > properties/ioctls. But I tend to think that is more useful for cameras. > And from userspace perspective, kms planes are less painful to use for > output than v4l2, so lets stick to drm/kms for output (and not try to add > camera/capture support to kms).. Agreed. I've started to advocate the deprecation of FBDEV during LPC. The positive response has motivated me to continue doing so :-) For V4L2 the situation is a little bit different, I think V4L2 shouldn't be used for graphics and display hardware, but it still has use cases on the video output
Re: [RFC v2 0/5] Common Display Framework
Hi Dave, On Tuesday 18 December 2012 15:04:02 Dave Airlie wrote: > > Many developers showed interest in the first RFC, and I've had the > > opportunity to discuss it with most of them. I would like to thank (in no > > particular order) Tomi Valkeinen for all the time he spend helping me to > > draft v2, Marcus Lorentzon for his useful input during Linaro Connect Q4 > > 2012, and Linaro for inviting me to Connect and providing a venue to > > discuss this topic. > > So this might be a bit off topic but this whole CDF triggered me looking at > stuff I generally avoid: > > The biggest problem I'm having currently with the whole ARM graphics and > output world is the proliferation of platform drivers for every little > thing. The whole ordering of operations with respect to things like > suspend/resume or dynamic power management is going to be a real nightmare > if there are dependencies between the drivers. We share the same concern, although my analysis of the problem is somewhat different. The power management ordering issues isn't only caused by the software architecture, but also comes from complex hardware requirements. The root cause, in my opinion, is the split control and data busses: as soon as a device sits on multiple busses and has power management ordering requirements related to those busses the Linux power management model breaks. Note that the problem isn't restricted to the display, we have run into the exact same issues years ago on the video capture side. > How do you enforce ordering of s/r operations between all the various > components? The way we have handled this problem on the camera side is to use early suspend and late resume operations to handle the data (video) busses suspend and resume operations, and let the kernel handle the rest using the control bus based device tree model. The camera controller stops the video pipeline in its early suspend operation (and resumes it in the late resume operation) by calling operations provided by the entities (through function pointers of course, we don't want direct dependencies between the drivers). The control suspend/resume (such as sending a standby command through I2C to put the chip in low-power mode, or turning its power supply or clock off) is then handled by the PM core. > The other thing I'd like you guys to do is kill the idea of fbdev and v4l > drivers that are "shared" with the drm codebase, really just implement fbdev > and v4l on top of the drm layer, some people might think this is some sort > of maintainer thing, but really nothing else makes sense, and having these > shared display frameworks just to avoid having using drm/kms drivers seems > totally pointless. Fix the drm fbdev emulation if an fbdev interface is > needed. But creating a fourth framework because our previous 3 frameworks > didn't work out doesn't seem like a situation I want to get behind too much. I think there's a misunderstanding here. I'm definitely not trying to create a framework to expose the FBDEV/KMS/V4L2 APIs through different drivers on top of the same hardware device. That's an idea I really dislike, and I fully agree that the FBDEV API should be provided on top of KMS using the DRM FBDEV emulation layer. V4L2 on top of KMS doesn't make too much sense to me, as V4L2 isn't really a display and graphics API anyway. My goal here is to share code for chips that are used by different "devices" (in the sense of an agregate device, such as a camera or a graphics card) supported by different subsystems. For instance, the same I2C-controlled HDMI transmitter can be used by a display device when connected to a display controller on an SoC, but can also be used by a video output device when connected to a video output (some complex TI SoCs have pass-through video pipelines with no associated frame buffer, making the V4L2 API better suited than DRM/KMS). As the first device would be supported by a DRM/KMS driver and the second device by a pure V4L2 driver, we need a common framework to share code between both. If the same framework can be used to share panel drivers between DRM/KMS and pure FBDEV drivers (we have a bunch of those, not all of them will be ported to DRM/KMS, at least not in the very near future) that's also a bonus. To summarize my point, CDF aims at creating a self-contained framework that can be used by FBDEV, DRM/KMS and V4L2 drivers to interface with various display-related devices. It does not provide any userspace API, and does not offer any way to share devices between the three subsystems at runtime. In a way you can think of CDF as a DRM panel framework, but without the drm_ prefix. I hope this clarifies my goals. If not, or if there's still concerns and/or disagreements, let's discuss them. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.k
Re: [RFC v2 0/5] Common Display Framework
Hi Vikas, On Tuesday 18 December 2012 08:31:30 Vikas Sajjan wrote: > On 17 December 2012 20:55, Laurent Pinchart wrote: > > Hi Vikas, > > > > Sorry for the late reply. I now have more time to work on CDF, so delays > > should be much shorter. > > > > On Thursday 06 December 2012 10:51:15 Vikas Sajjan wrote: > > > Hi Laurent, > > > > > > I was thinking of porting CDF to samsung EXYNOS 5250 platform, what I > > > found is that, the exynos display controller is MIPI DSI based > > > controller. > > > > > > But if I look at CDF patches, it has only support for MIPI DBI based > > > Display controller. > > > > > > So my question is, do we have any generic framework for MIPI DSI based > > > display controller? basically I wanted to know, how to go about porting > > > CDF for such kind of display controller. > > > > MIPI DSI support is not available yet. The only reason for that is that I > > don't have any MIPI DSI hardware to write and test the code with :-) > > > > The common display framework should definitely support MIPI DSI. I think > > the existing MIPI DBI code could be used as a base, so the implementation > > shouldn't be too high. > > > > Yeah, i was also thinking in similar lines, below is my though for MIPI > > DSI support in CDF. > > o MIPI DSI support as part of CDF framework will expose > § mipi_dsi_register_device(mpi_device) (will be called mach-xxx-dt.c > file) > § mipi_dsi_register_driver(mipi_driver, bus ops) (will be called from > platform specific init driver call ) > · bus ops will be > o read data > o write data > o write command > § MIPI DSI will be registered as bus_register() > > When MIPI DSI probe is called, it (e.g., Exynos or OMAP MIPI DSI) will > initialize the MIPI DSI HW IP. > > This probe will also parse the DT file for MIPI DSI based panel, add > the panel device (device_add() ) to kernel and register the display > entity with its control and video ops with CDF. After discussing the DBI/DSI busses with Tomi Valkeinen we concluded that creating a real bus for DBI and DSI, although possible, wasn't required. DSI operations should thus be provided through display entity video source operations. You can find a proposed implementation in Tomi's patch set. > > I can give this a try. Does the existing Exynos 5250 driver support MIPI > > DSI ? Is the device documentation publicly available ? Can you point me to > > a MIPI DSI panel with public documentation (preferably with an existing > > mainline driver if possible) ? > > yeah, existing Exynos 5250 driver support MIPI DSI ass well as eDP. > > i think device documentation is NOT available publicly. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] v4l2-compliance: Print invalid return codes in control tests
Signed-off-by: Laurent Pinchart
---
utils/v4l2-compliance/v4l2-test-controls.cpp | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/utils/v4l2-compliance/v4l2-test-controls.cpp
b/utils/v4l2-compliance/v4l2-test-controls.cpp
index 27c0117..2e03551 100644
--- a/utils/v4l2-compliance/v4l2-test-controls.cpp
+++ b/utils/v4l2-compliance/v4l2-test-controls.cpp
@@ -153,7 +153,7 @@ static int checkQCtrl(struct node *node, struct
test_queryctrl &qctrl)
qmenu.index = i;
ret = doioctl(node, VIDIOC_QUERYMENU, &qmenu);
if (ret && ret != EINVAL)
- return fail("invalid QUERYMENU return code\n");
+ return fail("invalid QUERYMENU return code (%d)\n",
ret);
if (ret)
continue;
if (i < qctrl.minimum || i > qctrl.maximum)
@@ -194,7 +194,7 @@ int testQueryControls(struct node *node)
if (ret == ENOTTY)
return ret;
if (ret && ret != EINVAL)
- return fail("invalid queryctrl return code\n");
+ return fail("invalid queryctrl return code (%d)\n",
ret);
if (ret)
break;
if (checkQCtrl(node, qctrl))
@@ -244,7 +244,7 @@ int testQueryControls(struct node *node)
qctrl.id = id;
ret = doioctl(node, VIDIOC_QUERYCTRL, &qctrl);
if (ret && ret != EINVAL)
- return fail("invalid queryctrl return code\n");
+ return fail("invalid queryctrl return code (%d)\n",
ret);
if (ret)
continue;
if (qctrl.id != id)
@@ -260,7 +260,7 @@ int testQueryControls(struct node *node)
qctrl.id = id;
ret = doioctl(node, VIDIOC_QUERYCTRL, &qctrl);
if (ret && ret != EINVAL)
- return fail("invalid queryctrl return code\n");
+ return fail("invalid queryctrl return code (%d)\n",
ret);
if (ret)
break;
if (qctrl.id != id)
@@ -352,7 +352,7 @@ int testSimpleControls(struct node *node)
ctrl.id = iter->id;
ctrl.value = iter->default_value;
} else if (ret)
- return fail("g_ctrl returned an error\n");
+ return fail("g_ctrl returned an error (%d)\n", ret);
else if (checkSimpleCtrl(ctrl, *iter))
return fail("invalid control %08x\n", iter->id);
@@ -417,7 +417,7 @@ int testSimpleControls(struct node *node)
if (!valid && !ret)
return fail("could set invalid menu
item %d\n", i);
if (ret && ret != EINVAL)
- return fail("setting invalid menu item
returned wrong error\n");
+ return fail("setting invalid menu item
returned wrong error (%d)\n", ret);
}
} else {
// at least min, max and default values should work
@@ -581,7 +581,7 @@ int testExtendedControls(struct node *node)
if (ctrls.error_idx != 0)
return fail("invalid error index read only
control\n");
} else if (ret) {
- return fail("try_ext_ctrls returned an error\n");
+ return fail("try_ext_ctrls returned an error (%d)\n",
ret);
}
// Try to set the current value (or the default value for write
only controls)
@@ -597,7 +597,7 @@ int testExtendedControls(struct node *node)
ret = 0;
}
if (ret)
- return fail("s_ext_ctrls returned an error\n");
+ return fail("s_ext_ctrls returned an error
(%d)\n", ret);
if (checkExtendedCtrl(ctrl, *iter))
return fail("s_ext_ctrls returned invalid
control contents (%08x)\n", iter->id);
--
1.7.8.6
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] v4l2-compliance: Print invalid error_idx values in control tests
Signed-off-by: Laurent Pinchart
---
utils/v4l2-compliance/v4l2-test-controls.cpp |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/utils/v4l2-compliance/v4l2-test-controls.cpp
b/utils/v4l2-compliance/v4l2-test-controls.cpp
index 2e03551..70b8aba 100644
--- a/utils/v4l2-compliance/v4l2-test-controls.cpp
+++ b/utils/v4l2-compliance/v4l2-test-controls.cpp
@@ -614,7 +614,7 @@ int testExtendedControls(struct node *node)
if (ret != EINVAL)
return fail("g_ext_ctrls accepted invalid control ID\n");
if (ctrls.error_idx != ctrls.count)
- return fail("g_ext_ctrls(0) invalid error_idx\n");
+ return fail("g_ext_ctrls(0) invalid error_idx %u\n",
ctrls.error_idx);
ctrl.id = 0;
ctrl.size = 0;
ctrl.value = 0;
@@ -622,12 +622,12 @@ int testExtendedControls(struct node *node)
if (ret != EINVAL)
return fail("try_ext_ctrls accepted invalid control ID\n");
if (ctrls.error_idx != 0)
- return fail("try_ext_ctrls(0) invalid error_idx\n");
+ return fail("try_ext_ctrls(0) invalid error_idx %u\n",
ctrls.error_idx);
ret = doioctl(node, VIDIOC_S_EXT_CTRLS, &ctrls);
if (ret != EINVAL)
return fail("s_ext_ctrls accepted invalid control ID\n");
if (ctrls.error_idx != ctrls.count)
- return fail("s_ext_ctrls(0) invalid error_idx\n");
+ return fail("s_ext_ctrls(0) invalid error_idx %u\n",
ctrls.error_idx);
for (iter = node->controls.begin(); iter != node->controls.end();
++iter) {
struct v4l2_ext_control ctrl;
--
1.7.8.6
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] v4l2-compliance: Reject invalid ioctl error codes
Hi Hans, On Monday 24 December 2012 10:24:48 Hans Verkuil wrote: > On Sun December 23 2012 23:24:04 Laurent Pinchart wrote: > > The recent uvcvideo regression that broke pulseaudio/KDE (see commit > > 9c016d61097cc39427a2f5025bdd97ac633d26a6 in the mainline kernel) was > > caused by the uvcvideo driver returning a -ENOENT error code to > > userspace by mistake. > > > > To make sure such regressions will be caught before reaching users, test > > ioctl error codes to make sure they're valid. > > I don't like this change. Error codes should be checked in the test for > the actual ioctl. > > Apparently it is QUERYCTRL that is returning the wrong error code in uvc, > but looking at the code in v4l2-test-controls.cpp it is already checking > for ENOTTY or EINVAL and returning a failure if it is a different error > code. So why is that not triggered in this case? I've just checked that, the missing control class issue made the control tests stop early before hitting the wrong return value. I guess that's a good reason to fix *all* compliance errors... We can drop this patch. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] uvcvideo: Set error_idx properly for extended controls API failures
Hi Hans,
On Thursday 27 September 2012 17:16:15 Laurent Pinchart wrote:
> When one of the requested controls doesn't exist the error_idx field
> must reflect that situation. For G_EXT_CTRLS and S_EXT_CTRLS, error_idx
> must be set to the control count. For TRY_EXT_CTRLS, it must be set to
> the index of the unexisting control.
>
> This issue was found by the v4l2-compliance tool.
I'm revisiting this patch as it has been reverted in v3.8-rc1.
> Signed-off-by: Laurent Pinchart
> ---
> drivers/media/usb/uvc/uvc_ctrl.c | 17 ++---
> drivers/media/usb/uvc/uvc_v4l2.c | 19 ---
> 2 files changed, 22 insertions(+), 14 deletions(-)
[snip]
> diff --git a/drivers/media/usb/uvc/uvc_v4l2.c
> b/drivers/media/usb/uvc/uvc_v4l2.c index f00db30..e5817b9 100644
> --- a/drivers/media/usb/uvc/uvc_v4l2.c
> +++ b/drivers/media/usb/uvc/uvc_v4l2.c
> @@ -591,8 +591,10 @@ static long uvc_v4l2_do_ioctl(struct file *file,
[snip]
> @@ -637,8 +639,9 @@ static long uvc_v4l2_do_ioctl(struct file *file,
> unsigned int cmd, void *arg) ret = uvc_ctrl_get(chain, ctrl);
> if (ret < 0) {
> uvc_ctrl_rollback(handle);
> - ctrls->error_idx = i;
> - return ret;
> + ctrls->error_idx = ret == -ENOENT
> + ? ctrls->count : i;
> + return ret == -ENOENT ? -EINVAL : ret;
> }
> }
> ctrls->error_idx = 0;
> @@ -661,8 +664,10 @@ static long uvc_v4l2_do_ioctl(struct file *file,
> unsigned int cmd, void *arg) ret = uvc_ctrl_set(chain, ctrl);
> if (ret < 0) {
> uvc_ctrl_rollback(handle);
> - ctrls->error_idx = i;
> - return ret;
> + ctrls->error_idx = (ret == -ENOENT &&
> + cmd == VIDIOC_S_EXT_CTRLS)
> + ? ctrls->count : i;
> + return ret == -ENOENT ? -EINVAL : ret;
> }
> }
I've reread the V4L2 specification, and the least I can say is that the text
is pretty ambiguous. Let's clarify it.
Is there a reason to differentiate between invalid control IDs and other
errors as far as error_idx is concerned ? It would be simpler if error_idx was
set to the index of the first error for get and try operations, regardless of
the error type. What do you think ?
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] v4l2-compliance: Print invalid return codes in control tests
Signed-off-by: Laurent Pinchart
---
utils/v4l2-compliance/v4l2-test-controls.cpp |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/utils/v4l2-compliance/v4l2-test-controls.cpp
b/utils/v4l2-compliance/v4l2-test-controls.cpp
index 1a1dc96..e16d71d 100644
--- a/utils/v4l2-compliance/v4l2-test-controls.cpp
+++ b/utils/v4l2-compliance/v4l2-test-controls.cpp
@@ -153,7 +153,7 @@ static int checkQCtrl(struct node *node, struct
test_queryctrl &qctrl)
qmenu.index = i;
ret = doioctl(node, VIDIOC_QUERYMENU, &qmenu);
if (ret && ret != EINVAL)
- return fail("invalid QUERYMENU return code\n");
+ return fail("invalid QUERYMENU return code (%d)\n",
ret);
if (ret)
continue;
if (i < qctrl.minimum || i > qctrl.maximum)
@@ -194,7 +194,7 @@ int testQueryControls(struct node *node)
if (ret == ENOTTY)
return ret;
if (ret && ret != EINVAL)
- return fail("invalid queryctrl return code\n");
+ return fail("invalid queryctrl return code (%d)\n",
ret);
if (ret)
break;
if (checkQCtrl(node, qctrl))
@@ -244,7 +244,7 @@ int testQueryControls(struct node *node)
qctrl.id = id;
ret = doioctl(node, VIDIOC_QUERYCTRL, &qctrl);
if (ret && ret != EINVAL)
- return fail("invalid queryctrl return code\n");
+ return fail("invalid queryctrl return code (%d)\n",
ret);
if (ret)
continue;
if (qctrl.id != id)
@@ -260,7 +260,7 @@ int testQueryControls(struct node *node)
qctrl.id = id;
ret = doioctl(node, VIDIOC_QUERYCTRL, &qctrl);
if (ret && ret != EINVAL)
- return fail("invalid queryctrl return code\n");
+ return fail("invalid queryctrl return code (%d)\n",
ret);
if (ret)
break;
if (qctrl.id != id)
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
em28xx: module parameter prefer_bulk ?
Hi Mauro, now that we prefer bulk transfers for webcams and isoc transfers for TV, I wonder if prefer_bulk is still a good name for this module parameter. What about something like 'usb_mode', 'usb_xfer_mode' or 'frame_xfer_mode' with 0=auto, 1=prefer isoc, 2=prefer bulk ? Regards, Frank -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/5] em28xx: respect the message size constraints for i2c transfers
Am 23.12.2012 15:46, schrieb Mauro Carvalho Chehab:
> Em Sun, 23 Dec 2012 14:58:12 +0100
> Frank Schäfer escreveu:
>
>> Am 23.12.2012 01:07, schrieb Mauro Carvalho Chehab:
>>> Em Sun, 16 Dec 2012 19:23:28 +0100
>>> Frank Schäfer escreveu:
>>>
The em2800 can transfer up to 4 bytes per i2c message.
All other em25xx/em27xx/28xx chips can transfer at least 64 bytes per
message.
I2C adapters should never split messages transferred via the I2C subsystem
into multiple message transfers, because the result will almost always NOT
be
the same as when the whole data is transferred to the I2C client in a
single
message.
If the message size exceeds the capabilities of the I2C adapter,
-EOPNOTSUPP
should be returned.
Signed-off-by: Frank Schäfer
---
drivers/media/usb/em28xx/em28xx-i2c.c | 44
++---
1 Datei geändert, 18 Zeilen hinzugefügt(+), 26 Zeilen entfernt(-)
diff --git a/drivers/media/usb/em28xx/em28xx-i2c.c
b/drivers/media/usb/em28xx/em28xx-i2c.c
index 44533e4..c508c12 100644
--- a/drivers/media/usb/em28xx/em28xx-i2c.c
+++ b/drivers/media/usb/em28xx/em28xx-i2c.c
@@ -50,14 +50,18 @@ do {
\
} while (0)
/*
- * em2800_i2c_send_max4()
- * send up to 4 bytes to the i2c device
+ * em2800_i2c_send_bytes()
+ * send up to 4 bytes to the em2800 i2c device
*/
-static int em2800_i2c_send_max4(struct em28xx *dev, u8 addr, u8 *buf, u16
len)
+static int em2800_i2c_send_bytes(struct em28xx *dev, u8 addr, u8 *buf,
u16 len)
{
int ret;
int write_timeout;
u8 b2[6];
+
+ if (len < 1 || len > 4)
+ return -EOPNOTSUPP;
+
>>> Except if you actually tested it with all em2800 devices, I think that
>>> this change just broke it for em2800.
>> Yes, I have tested it. ;)
>> But it should be obvious that splitting messages doesn't work, because
>> the first byte of each message is treated as register address:
>>
>> Let's say we want to transfer the 8 bytes 11 22 33 44 55 66 77 88 to
>> registers A0-A7 of a client.
>> The correspondig i2c message transferred via the i2c subsystem is A0 11
>> 22 33 44 55 66 77 88
>> The current in em28xx splits this message into 3 messages:
>>
>> message 1: A0 11 22 33
>> message 2: 44 55 66 77
>> message 3: 88
>>
>> The result is, that only the first 3 bytes are transferred correctly.
>> The data bytes 44 and 88 are interpreted as register index and get lost,
>> data bytes 55 66 77 end up in registers 0x44, 0x45 and 0x46 instead of
>> 0xA4 to 0xA6.
>> Ouch !
> I see your point, but there are devices that allow sending a message
> splitted into smaller URB data and do the right thing when the I2C
> transfer actually happen. The cx231xx is one of such devices: it has
> 4 I2C buses internally; a few of them have a limit of 4 bytes per
> transfer. Even so, manufacturers use this limited buses, plugging
> I2C devices there that require I2C transfers with more than 4 bytes.
>
> One of the tricks used on such devices to write long messages is
> to disable I2C stop on the first I2C block, and to disable I2C
> start+address data on the next messages. Only the I2C bus can do
> such things, and such logic avoids to push down to all I2C clients
> a complex logic to split messages there.
Yes, if the i2c adapter supports this feature, there is no problem with
splitting messages.
> I'm not sure if this is the case of em2800 though, as I don't have
> any device with it.
I'm not aware of a possibility to do this with the em2800.
> In any case, before dropping it, we should be sure that this won't
> break any supported device. Probably the worse case are the TV-based
> em2800 boards, with tuners, as they may need to transfer more than 4
> bytes via I2C.
I agree.
We currently have 6 boards with the em2800. Used i2c clients are
TDA9887
SAA711X
TUNER_PHILIPS_FCV1236D
TUNER_LG_PAL_NEW_TAPC
TUNER_LG_TALN
and in case of the Terratec Cinergy 200 USB an external IR receiver IC
None of these clients tries to transfer more than 4 bytes at once.
Terratec Cinergy 200 USB has also been tested by me.
Anyway, even if one of those client drivers would writes more than 4
bytes at once to the device, it wouldn't work with the current code.
>>> Maybe Sascha could review this patch series on his em2800 devices.
>> Comments / reviews are appreciated.
> Let's give him some time to review, before merging it.
Sure.
>>> Those devices are limited, and just like other devices (cx231xx for
>>> example),
>>> the I2C bus need to split long messages, otherwise the I2C devices will
>>> fail.
>> I2C adapters are supposed to fail with -EOPNOTSUPP if the message length
>> exceeds their capabilities.
>> Drivers must be able to handle this error, otherwise they have to be fixed.
> Currently, afaikt, no V4L2 I
Re: Patch update notification: 37 patches updated
Am 23.12.2012 15:57, schrieb Mauro Carvalho Chehab: > Em Sun, 23 Dec 2012 14:45:31 +0100 > Frank Schäfer escreveu: > >> Hi Mauro, >> >> Am 23.12.2012 01:08, schrieb Patchwork: >>> Hello, >>> >>> The following patches (submitted by you) have been updated in patchwork: >>> >>> * [3/6] em28xx: fix capture type setting in em28xx_urb_data_copy_vbi() >>> - http://patchwork.linuxtv.org/patch/15651/ >>> was: New >>> now: Accepted >>> >>> * [8/9] em28xx: move the em2710/em2750/em28xx specific frame data >>> processing code to a separate function >>> - http://patchwork.linuxtv.org/patch/15798/ >>> was: New >>> now: Accepted >>> >>> * [4/6] em28xx: fix/improve frame field handling in >>> em28xx_urb_data_copy_vbi() >>> - http://patchwork.linuxtv.org/patch/15652/ >>> was: New >>> now: Accepted >> This patch has not been applied yet to the media-tree. >> Without this patch, frame data processing for non-interlaced devices is >> broken. > Not sure what happened there: I couldn't see this specific patch. Yet, > at least some of the changes there seem to be applied. My guess is that > somehow, this patch got merged with some other patch, or maybe the > conflicts solving when the vbi-merge patches got applied (partially) > fixed it. > > In any case, you'll need to rebase it, as it doesn't apply anymore. Ok, I did a git diff against my local version and all changes (except the remaining i2c stuff) seem to be applied. One thing I noticed: you fixed strings with lines > 80 characters. This is handled differently everywhere... I know splitting strings breaks grepping, OTOH checkpatch complains. So you prefer violating the 80 chars rule ? Regards, Frank > Cheers, > Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] v4l2-compliance: Reject invalid ioctl error codes
On Sun December 23 2012 23:24:04 Laurent Pinchart wrote:
> The recent uvcvideo regression that broke pulseaudio/KDE (see commit
> 9c016d61097cc39427a2f5025bdd97ac633d26a6 in the mainline kernel) was
> caused by the uvcvideo driver returning a -ENOENT error code to
> userspace by mistake.
>
> To make sure such regressions will be caught before reaching users, test
> ioctl error codes to make sure they're valid.
I don't like this change. Error codes should be checked in the test for
the actual ioctl.
Apparently it is QUERYCTRL that is returning the wrong error code in uvc, but
looking at the code in v4l2-test-controls.cpp it is already checking for ENOTTY
or EINVAL and returning a failure if it is a different error code. So why is
that not triggered in this case?
Regards,
Hans
> Signed-off-by: Laurent Pinchart
> ---
> utils/v4l2-compliance/v4l2-compliance.cpp |7 +++
> 1 files changed, 7 insertions(+), 0 deletions(-)
>
> A white list of valid error codes might be more appropriate. I can fix the
> patch accordingly, but I'd like a general opinion first.
>
> diff --git a/utils/v4l2-compliance/v4l2-compliance.cpp
> b/utils/v4l2-compliance/v4l2-compliance.cpp
> index 1e4646f..ff1ad9b 100644
> --- a/utils/v4l2-compliance/v4l2-compliance.cpp
> +++ b/utils/v4l2-compliance/v4l2-compliance.cpp
> @@ -112,6 +112,13 @@ int doioctl_name(struct node *node, unsigned long int
> request, void *parm, const
> fail("%s returned %d instead of 0 or -1\n", name, retval);
> return -1;
> }
> +
> + /* Reject invalid error codes */
> + switch (errno) {
> + case ENOENT:
> + fail("%s returned invalid error %d\n", name, errno);
> + break;
> + }
> return e;
> }
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v3.8-rc1] Multimedia regression, ioctl(17,..)-API changed ?
2012/12/23 Mauro Carvalho Chehab : > Hi Jörg, > > Em Sun, 23 Dec 2012 17:46:07 +0100 > Jörg Otte escreveu: > >> With kernel v3.8 all multimedia programs under KDE4 don't work (Kubuntu >> 12.04). >> They alltogether ( at least Dragonplayer (Mediaplayer), Knotify4 >> (system-sound), >> System-Settings-Multimedia,..) are looping forever producing 100% CPU-usage >> and must be killed. >> >> With kernel 3.7 there are no problems. > > Do you have any other non-uvc device to test? No I haven't. Thanks, Jörg -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v3.8-rc1] Multimedia regression, ioctl(17,..)-API changed ?
Yes it works, incl. usb-camera. I am now at: 637704cbc95c02d18741b4a6e7a5d2397f8b28ce Merge branch 'i2c-embedded/for-next' of git://git.pengutronix.de/git/wsa/linux Thanks, Jörg 2012/12/23 Linus Torvalds : > Jörg - does current git work for you? It has a patch from Rafael that > just reverts the insane error code, and fixed something very similar > for him. > > (I just pushed out, so it might take a few minutes to mirror out to > the public sites). > > Linus > > On Sun, Dec 23, 2012 at 8:46 AM, Jörg Otte wrote: >> With kernel v3.8 all multimedia programs under KDE4 don't work (Kubuntu >> 12.04). >> They alltogether ( at least Dragonplayer (Mediaplayer), Knotify4 >> (system-sound), >> System-Settings-Multimedia,..) are looping forever producing 100% CPU-usage >> and must be killed. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL FOR v3.9] separate Montage ts2020 from ds3000 and rs2000, support for new TeVii cards
The following changes since commit 8b2aea7878f64814544d0527c659011949d52358: [media] em28xx: prefer bulk mode on webcams (2012-12-23 17:24:30 -0200) are available in the git repository at: git://git.linuxtv.org/liplianin/media_tree.git ts2020_v3.9 for you to fetch changes up to 2ff52e6f487c2ee841f3df9709d1b4e4416a1b15: ts2020: separate from m88rs2000 (2012-12-24 01:26:12 +0300) Igor M. Liplianin (4): Tevii S421 and S632 support m88rs2000: SNR BER implemented ds3000: lock led procedure added ts2020: separate from m88rs2000 Konstantin Dimitrov (3): ds3000: remove ts2020 tuner related code ts2020: add ts2020 tuner driver make the other drivers take use of the new ts2020 driver drivers/media/dvb-frontends/Kconfig | 7 +++ drivers/media/dvb-frontends/Makefile| 1 + drivers/media/dvb-frontends/ds3000.c| 255 +- drivers/media/dvb-frontends/ds3000.h| 10 ++-- drivers/media/dvb-frontends/m88rs2000.c | 420 + drivers/media/dvb-frontends/m88rs2000.h | 6 --- drivers/media/dvb-frontends/ts2020.c| 372 + drivers/media/dvb-frontends/ts2020.h| 50 + drivers/media/pci/cx23885/Kconfig | 1 + drivers/media/pci/cx23885/cx23885-dvb.c | 11 +++- drivers/media/pci/cx88/Kconfig | 2 + drivers/media/pci/cx88/cx88-dvb.c | 11 +++- drivers/media/pci/dm1105/Kconfig| 1 + drivers/media/pci/dm1105/dm1105.c | 11 +++- drivers/media/usb/dvb-usb-v2/Kconfig| 1 + drivers/media/usb/dvb-usb-v2/lmedm04.c | 9 +++- drivers/media/usb/dvb-usb/Kconfig | 2 + drivers/media/usb/dvb-usb/dw2102.c | 143 18 files changed, 772 insertions(+), 541 deletions(-) create mode 100644 drivers/media/dvb-frontends/ts2020.c create mode 100644 drivers/media/dvb-frontends/ts2020.h -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
