Re: [RFC] Initial scan files troubles and brainstorming
On 19-12-12 00:23, Jonathan McCrohan wrote: Hi Oliver, On 18/12/12 22:01, Oliver Schinagl wrote: Unfortunatly, I have had zero replies. Apologies. I wasn't subscribed to linux-media. I am now. So why bring it up again? On 2012/11/30 Jakub Kasprzycki provided us with updated polish DVB-T frequencies for his region. This has yet to be merged, almost 3 weeks later. While I know people are busy and merging frequency updates doesn't seem critical, for people who somewhat depend on them, the sooner, the better. I can relate. I currently have two patch files that I am trying to get merged myself I have been contacting Manu and Christoph) directly because previous attempts at posting to linux-media were left unattended for a good period of time. I'll quickly repeat why I think this approach would be quite reasonable. * dvb-apps binary changes don't result in unnecessary releases * frequency updates don't result in unnecessary dvb-app releases * Less strict requirements for commits (code reviews etc) * Possibly easier entry for new submitters * much easier to package (tag it once per month if an update was) * Separate maintainer possible * just seems more logical to have it separated ;) This obviously should find a nice home on linuxtv where it belongs! I like this approach, but I'm afraid that decoupling dvb-apps and scan files may result in distributions paying less attention to scan files. At the moment, they are forced to update the scan files when a new release of dvb-apps appears. So if no code changes are needed/done, but scan files are updated, a new dvb-apps release needs to be made? That also results in grief for packagers. Packages need to be made but more importantly tested against many combinations. While the changes (binary anyway) would be trivial/non-existant, it would result in annoyance for packagers and could even be ignored. scanfiles could be packaged and released just as easily and since there are applications already out there, that do not even use or need dvb-apps, it makes sense to seperate them. TVheadend for example does not need dvb-apps in any form and i'm sure there's more. So it goes both ways :p If an issue is that none of the original maintainers are not looking forward to do the job, I am willing to take maintenance on me for now. To be honest, I think the current system works okay. I think more people just need to be given hg commit access. This would solve the current delays. Jon -- 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 1/6] Add header files and Kbuild plumbing for SI476x MFD core
On Tue, Dec 18, 2012 at 07:07:28PM -0800, Andrey Smirnov wrote:
On 12-12-18 11:37 AM, Mauro Carvalho Chehab wrote:
Em Mon, 8 Oct 2012 11:38:01 -0700
Andrey Smirnov andrey.smir...@convergeddevices.net escreveu:
Guys, please delete irrelevant context from mails. I just TL;DRed this
so if there's anything you're expecting from me on this please let me
know.
On 10/08/2012 01:43 AM, Hans Verkuil wrote:
On Sat October 6 2012 03:54:57 Andrey Smirnov wrote:
This patch adds all necessary header files and Kbuild plumbing for the
core driver for Silicon Laboratories Si476x series of AM/FM tuner
chips.
The driver as a whole is implemented as an MFD device and this patch
adds a core portion of it that provides all the necessary
functionality to the two other drivers that represent radio and audio
codec subsystems of the chip.
Signed-off-by: Andrey Smirnov andrey.smir...@convergeddevices.net
---
drivers/mfd/Kconfig | 14 ++
drivers/mfd/Makefile|3 +
include/linux/mfd/si476x-core.h | 529
+++
include/media/si476x.h | 449 +
4 files changed, 995 insertions(+)
create mode 100644 include/linux/mfd/si476x-core.h
create mode 100644 include/media/si476x.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index b1a1462..3fab06d 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -895,6 +895,20 @@ config MFD_WL1273_CORE
driver connects the radio-wl1273 V4L2 module and the wl1273
audio codec.
+config MFD_SI476X_CORE
+ tristate Support for Silicon Laboratories 4761/64/68 AM/FM radio.
+ depends on I2C
+ select MFD_CORE
+ default n
+ help
+ This is the core driver for the SI476x series of AM/FM radio. This MFD
+ driver connects the radio-si476x V4L2 module and the si476x
+ audio codec.
+
+ To compile this driver as a module, choose M here: the
+ module will be called si476x-core.
+
+
config MFD_OMAP_USB_HOST
bool Support OMAP USBHS core driver
depends on USB_EHCI_HCD_OMAP || USB_OHCI_HCD_OMAP3
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 79dd22d..942257b 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -132,3 +132,6 @@ obj-$(CONFIG_MFD_RC5T583) += rc5t583.o
rc5t583-irq.o
obj-$(CONFIG_MFD_SEC_CORE) += sec-core.o sec-irq.o
obj-$(CONFIG_MFD_ANATOP)+= anatop-mfd.o
obj-$(CONFIG_MFD_LM3533)+= lm3533-core.o lm3533-ctrlbank.o
+
+si476x-core-objs := si476x-cmd.o si476x-prop.o si476x-i2c.o
+obj-$(CONFIG_MFD_SI476X_CORE)+= si476x-core.o
diff --git a/include/linux/mfd/si476x-core.h
b/include/linux/mfd/si476x-core.h
new file mode 100644
index 000..eb6f52a
--- /dev/null
+++ b/include/linux/mfd/si476x-core.h
@@ -0,0 +1,529 @@
+/*
+ * include/media/si476x-core.h -- Common definitions for si476x core
+ * device
+ *
+ * Copyright (C) 2012 Innovative Converged Devices(ICD)
+ *
+ * Author: Andrey Smirnov andrey.smir...@convergeddevices.net
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ */
+
+#ifndef SI476X_CORE_H
+#define SI476X_CORE_H
+
+#include linux/kfifo.h
+#include linux/atomic.h
+#include linux/i2c.h
+#include linux/mutex.h
+#include linux/mfd/core.h
+#include linux/videodev2.h
+
+#include media/si476x.h
+
+#ifdef DEBUG
+#define DBG_BUFFER(device, header, buffer, bcount)
\
+ do {\
+ dev_info((device), header); \
+ print_hex_dump_bytes(,\
+ DUMP_PREFIX_OFFSET,\
+ buffer, bcount); \
+ } while (0)
+#else
+#define DBG_BUFFER(device, header, buffer, bcount)
\
+ do {} while (0)
+#endif
+
+enum si476x_freq_suppoted_chips {
typo: suppoted - supported
+ SI476X_CHIP_SI4761 = 1,
+ SI476X_CHIP_SI4762,
+ SI476X_CHIP_SI4763,
+ SI476X_CHIP_SI4764,
+ SI476X_CHIP_SI4768,
+ SI476X_CHIP_SI4769,
+};
+
+enum si476x_mfd_cells {
+ SI476X_RADIO_CELL = 0,
+ SI476X_CODEC_CELL,
+ SI476X_MFD_CELLS,
+};
+
+
+/**
+ * enum si476x_power_state - possible power state of the si476x
+ * device.
+ *
+ * @SI476X_POWER_DOWN: In this state all regulators are turned off
+ * and the reset line is pulled low. The device is completely
+ * inactive.
+ * @SI476X_POWER_UP_FULL: In this state all the
Re: [RFC v2 0/5] Common Display Framework
Hi Laurent - On Tue, 18 Dec 2012, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Jani, 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! 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. BR, Jani. -- 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] [media] DocBook: fix an index reference
Error: no ID for constraint linkend: V4L2-PIX-FMT-NV12MT-16X16. Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com --- Documentation/DocBook/media/v4l/pixfmt-nv12m.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/DocBook/media/v4l/pixfmt-nv12m.xml b/Documentation/DocBook/media/v4l/pixfmt-nv12m.xml index a990b34..f3a3d45 100644 --- a/Documentation/DocBook/media/v4l/pixfmt-nv12m.xml +++ b/Documentation/DocBook/media/v4l/pixfmt-nv12m.xml @@ -6,7 +6,7 @@ refnamediv refname id=V4L2-PIX-FMT-NV12MconstantV4L2_PIX_FMT_NV12M/constant/refname refname id=V4L2-PIX-FMT-NV21MconstantV4L2_PIX_FMT_NV21M/constant/refname - refname id=V4L2-PIX-FMT-NV12MT_16X16constantV4L2_PIX_FMT_NV12MT_16X16/constant/refname + refname id=V4L2-PIX-FMT-NV12MT-16X16constantV4L2_PIX_FMT_NV12MT_16X16/constant/refname refpurposeVariation of constantV4L2_PIX_FMT_NV12/constant and constantV4L2_PIX_FMT_NV21/constant with planes non contiguous in memory. /refpurpose /refnamediv -- 1.7.11.7 -- 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
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. Tomi signature.asc Description: OpenPGP digital signature
Re: [RFC v2 0/5] Common Display Framework
On Wed, Dec 19, 2012 at 8:57 AM, Jani Nikula jani.nik...@linux.intel.com wrote: Hi Laurent - On Tue, 18 Dec 2012, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Jani, 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. BR, -R 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. BR, Jani. -- 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 -- 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
On 2012-12-19 17:26, Rob Clark wrote: On Wed, Dec 19, 2012 at 8:57 AM, Jani Nikula jani.nik...@linux.intel.com wrote: Hi Laurent - On Tue, 18 Dec 2012, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Jani, 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. 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. Tomi signature.asc Description: OpenPGP digital signature
Re: [RFC v2 0/5] Common Display Framework
On Wed, Dec 19, 2012 at 9:37 AM, Tomi Valkeinen tomi.valkei...@ti.com 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. 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. BR, -R Tomi -- 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
On Mon, Dec 17, 2012 at 10:21 PM, Rob Clark rob.cl...@linaro.org wrote: On Mon, Dec 17, 2012 at 11:04 PM, Dave Airlie airl...@gmail.com 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.. You can probe the device tree from a normal DRM driver. For example in nouveau for PPC we probe the OF device tree looking for connectors. I don't see how sub-devices or extra platform drivers help with that, as long as the device tree is populated upfront somehow... Stéphane 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. 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. 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 BR, -R Dave. ___ dri-devel mailing list dri-de...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-de...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel -- 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
On Tue, Dec 18, 2012 at 1:38 AM, Inki Dae inki@samsung.com wrote: 2012/12/18 Daniel Vetter dan...@ffwll.ch On Tue, Dec 18, 2012 at 7:21 AM, Rob Clark rob.cl...@linaro.org 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. If you're talking about us, this is misleading, as we didn't try to duplicate the eDP driver. What we did is remove it from driver/video and put it in DRM. The reason for that is that it's not needed for fbdev, since KMS helpers let you implement fbdev. So we can just remove all the exynos graphics support from drivers/video since it becomes obsolete with the KMS fbdev helpers. And everything can be in DRM. And later, we can remove the multiple platform drivers from DRM as well, since they're not needed either. Stéphane 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 - 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. Thanks, Inki Dae -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line unsubscribe linux-fbdev in the
cron job: media_tree daily build: ERRORS
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:Wed Dec 19 19:00:26 CET 2012 git hash:49cc629df16f2a15917800a8579bd9c25c41b634 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: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: WARNINGS 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: ERRORS 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: ERRORS apps: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.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
rtl2832u+r820t dvb-t usb
I have a rtl2832u+r820t dvb-t usb dongle; I use linux (x86). There is good support for using it as sdr. However, using it to watch dvb-t (I am in Europa) turned out to be difficult. The only way that worked: downgrade my linux kernel to 2.6.33.3, and compiling these sources: https://groups.google.com/d/msg/ultra-cheap-sdr/QiIo7834sLI/7YpqSRnYud4J which forced me to using an older commit of v4l (mercurial df33bbd60225), and to comment out all references to rtl2832u_rc_keys_map_table. In a word: it works, but the situation is disappointing. Since such dongles are probably to be sold massively (taking the place of the dismissed e4000-based ones), can anybody help me porting this stuff to a more maintainable form? PS: Be aware: identification of these cheap dongles can be very messy. In my case, lsusb returned 0bda:2838, which is the same as other ones having e4000 or fc0012, as ezcap EzTV646. Even the appearance can be misleading: there are e4000 looking exactly the same. -- 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] [RFC] dma-buf: implement vmap refcounting in the interface logic
On 12/17/2012 03:58 PM, Daniel Vetter wrote:
All drivers which implement this need to have some sort of refcount to
allow concurrent vmap usage. Hence implement this in the dma-buf core.
To protect against concurrent calls we need a lock, which potentially
causes new funny locking inversions. But this shouldn't be a problem
for exporters with statically allocated backing storage, and more
dynamic drivers have decent issues already anyway.
Inspired by some refactoring patches from Aaron Plattner, who
implemented the same idea, but only for drm/prime drivers.
v2: Check in dma_buf_release that no dangling vmaps are left.
Suggested by Aaron Plattner. We might want to do similar checks for
attachments, but that's for another patch. Also fix up ERR_PTR return
for vmap.
v3: Check whether the passed-in vmap address matches with the cached
one for vunmap. Eventually we might want to remove that parameter -
compared to the kmap functions there's no need for the vaddr for
unmapping. Suggested by Chris Wilson.
Cc: Aaron Plattner aplatt...@nvidia.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
Compile-tested only - Aaron has been bugging me too a bit too often
about this on irc.
Cheers, Daniel
---
Documentation/dma-buf-sharing.txt | 6 +-
drivers/base/dma-buf.c| 43 ++-
include/linux/dma-buf.h | 4 +++-
3 files changed, 46 insertions(+), 7 deletions(-)
diff --git a/Documentation/dma-buf-sharing.txt
b/Documentation/dma-buf-sharing.txt
index 0188903..4966b1b 100644
--- a/Documentation/dma-buf-sharing.txt
+++ b/Documentation/dma-buf-sharing.txt
@@ -302,7 +302,11 @@ Access to a dma_buf from the kernel context involves three
steps:
void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
The vmap call can fail if there is no vmap support in the exporter, or if
it
- runs out of vmalloc space. Fallback to kmap should be implemented.
+ runs out of vmalloc space. Fallback to kmap should be implemented. Note that
+ the dma-buf layer keeps a reference count for all vmap access and calls down
+ into the exporter's vmap function only when no vmapping exists, and only
+ unmaps it once. Protection against concurrent vmap/vunmap calls is provided
+ by taking the dma_buf-lock mutex.
3. Finish access
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index a3f79c4..67d3cd5 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -39,6 +39,8 @@ static int dma_buf_release(struct inode *inode, struct file
*file)
dmabuf = file-private_data;
+ BUG_ON(dmabuf-vmapping_counter);
+
dmabuf-ops-release(dmabuf);
kfree(dmabuf);
return 0;
@@ -482,12 +484,34 @@ EXPORT_SYMBOL_GPL(dma_buf_mmap);
*/
void *dma_buf_vmap(struct dma_buf *dmabuf)
{
+ void *ptr;
+
if (WARN_ON(!dmabuf))
return NULL;
- if (dmabuf-ops-vmap)
- return dmabuf-ops-vmap(dmabuf);
- return NULL;
+ if (!dmabuf-ops-vmap)
+ return NULL;
+
+ mutex_lock(dmabuf-lock);
+ if (dmabuf-vmapping_counter) {
+ dmabuf-vmapping_counter++;
+ BUG_ON(!dmabuf-vmap_ptr);
+ ptr = dmabuf-vmap_ptr;
+ goto out_unlock;
+ }
+
+ BUG_ON(dmabuf-vmap_ptr);
+
+ ptr = dmabuf-ops-vmap(dmabuf);
+ if (IS_ERR_OR_NULL(ptr))
+ goto out_unlock;
+
+ dmabuf-vmap_ptr = ptr;
+ dmabuf-vmapping_counter = 1;
+
+out_unlock:
+ mutex_unlock(dmabuf-lock);
+ return ptr;
}
EXPORT_SYMBOL_GPL(dma_buf_vmap);
@@ -501,7 +525,16 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
if (WARN_ON(!dmabuf))
return;
- if (dmabuf-ops-vunmap)
- dmabuf-ops-vunmap(dmabuf, vaddr);
+ BUG_ON(!dmabuf-vmap_ptr);
+ BUG_ON(dmabuf-vmapping_counter 0);
This should be BUG_ON(vmapping_counter == 0);
Otherwise, this seems to work fine.
--
Aaron
+ BUG_ON(dmabuf-vmap_ptr != vaddr);
+
+ mutex_lock(dmabuf-lock);
+ if (--dmabuf-vmapping_counter == 0) {
+ if (dmabuf-ops-vunmap)
+ dmabuf-ops-vunmap(dmabuf, vaddr);
+ dmabuf-vmap_ptr = NULL;
+ }
+ mutex_unlock(dmabuf-lock);
}
EXPORT_SYMBOL_GPL(dma_buf_vunmap);
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index bd2e52c..e3bf2f6 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -119,8 +119,10 @@ struct dma_buf {
struct file *file;
struct list_head attachments;
const struct dma_buf_ops *ops;
- /* mutex to serialize list manipulation and attach/detach */
+ /* mutex to serialize list manipulation, attach/detach and vmap/unmap */
struct mutex lock;
+ unsigned vmapping_counter;
+ void *vmap_ptr;
void *priv;
};
--
To unsubscribe from this list: send the line unsubscribe
[PATCH] For new revision of the board AVerMedia Hybrid TV / Radio (A16D)
Hello,
I'm trying to add support for card AVerMedia Hybrid TV / Radio (A16D)
two new revisions. subsystem: 1461:fb36, subsystem: 1461:fc36.
The card capable of DVB-T, analog TV and FM radio.
--- drivers/media/pci/saa7134/saa7134-cards.c.orig 2012-12-17
22:14:54.0 +0300
+++ drivers/media/pci/saa7134/saa7134-cards.c 2012-12-20
04:01:51.673631779 +0300
@@ -6858,6 +6858,18 @@
.subdevice= 0xf936,
.driver_data = SAA7134_BOARD_AVERMEDIA_A16D,
}, {
+.vendor = PCI_VENDOR_ID_PHILIPS,
+.device = PCI_DEVICE_ID_PHILIPS_SAA7133,
+.subvendor= 0x1461, /* Avermedia Technologies Inc */
+.subdevice= 0xfb36, /*A16D-ZL10353*/
+.driver_data = SAA7134_BOARD_AVERMEDIA_A16D,
+}, {
+.vendor = PCI_VENDOR_ID_PHILIPS,
+.device = PCI_DEVICE_ID_PHILIPS_SAA7133,
+.subvendor= 0x1461, /* Avermedia Technologies Inc */
+.subdevice= 0xfc36, /*A16D-ANALOG*/
+.driver_data = SAA7134_BOARD_AVERMEDIA_A16D,
+}, {
.vendor = PCI_VENDOR_ID_PHILIPS,
.device = PCI_DEVICE_ID_PHILIPS_SAA7133,
.subvendor= 0x1461, /* Avermedia Technologies Inc */
The result is:
[ 22.893960] saa7130/34: v4l2 driver version 0, 2, 17 loaded
[ 22.894167] saa7133[0]: found at :05:02.0, rev: 209, irq: 18,
latency: 64, mmio: 0xfebff800
[ 22.894322] saa7133[0]: subsystem: 1461:fb36, board: AVerMedia Hybrid
TV/Radio (A16D) [card=137,autodetected]
[ 22.894502] saa7133[0]: board init: gpio is 20
[ 23.068033] saa7133[0]: i2c eeprom 00: 61 14 36 fb 00 00 00 00 00 00
00 00 00 00 00 00
[ 23.068960] saa7133[0]: i2c eeprom 10: ff ff ff ff ff 20 ff ff ff ff
ff ff ff ff ff ff
[ 23.069876] saa7133[0]: i2c eeprom 20: 01 40 01 02 02 01 01 00 08 ff
00 10 ff ff ff ff
[ 23.070795] saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff
[ 23.071709] saa7133[0]: i2c eeprom 40: ff 6a 00 ff c2 1e ff ff ff ff
ff ff ff ff ff ff
[ 23.072643] saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff
[ 23.073558] saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff
[ 23.074470] saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff
[ 23.075384] saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff
[ 23.076314] saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff
[ 23.077233] saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff
[ 23.078144] saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff
[ 23.079030] saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff
[ 23.079915] saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff
[ 23.080820] saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff
[ 23.081708] saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff
[ 23.660110] tuner 1-0061: Tuner -1 found with type(s) Radio TV.
[ 23.887953] xc2028 1-0061: creating new instance
[ 23.888099] xc2028 1-0061: type set to XCeive xc2028/xc3028 tuner
[ 23.889581] saa7133[0]: registered device video0 [v4l2]
[ 23.889961] saa7133[0]: registered device vbi0
[ 23.922834] saa7133[0]: registered device radio0
[ 23.928898] xc2028 1-0061: Loading 80 firmware images from
xc3028-v27.fw, type: xc2028 firmware, ver 2.7
[ 23.975442] dvb_init() allocating 1 frontend
[ 24.023475] xc2028 1-0061: Loading firmware for type=BASE F8MHZ (3),
id .
[ 24.551822] saa7134 ALSA driver for DMA sound loaded
[ 24.551987] saa7133[0]/alsa: saa7133[0] at 0xfebff800 irq 18
registered as card -1
[ 33.092040] (0), id 00ff:
[ 33.092112] xc2028 1-0061: Loading firmware for type=(0), id
00010007.
[ 33.260020] xc2028 1-0061: Loading SCODE for type=MONO SCODE
HAS_IF_5320 (60008000), id 000f0007.
[ 33.382173] ppdev: user-space parallel port driver
[ 33.460032] xc2028 1-0061: Loading firmware for type=BASE FM (401),
id .
[ 41.824143] xc2028 1-0061: Loading firmware for type=FM (400), id
.
[ 42.144085] xc2028 1-0061: Loading firmware for type=BASE F8MHZ (3),
id .
[ 50.728030] (0), id 00ff:
[ 50.728133] xc2028 1-0061: Loading firmware for type=(0), id
00010007.
[ 50.896027] xc2028 1-0061: Loading SCODE for type=MONO SCODE
HAS_IF_5320 (60008000), id 000f0007.
[ 51.088666] xc2028 1-0061: Error on line 1293: -5
[ 51.093507] xc2028 1-0061: Error on line 1293: -5
With this patch board starts and takes the analog signal. To receive a
DVB-T, add the support demodulator zl10353 вместо Zarlink MT352
Any ideas?
--
To unsubscribe from this
Re: [PATCH] dma-buf: Add debugfs support
On Fri, Dec 14, 2012 at 7:36 PM, sumit.sem...@ti.com wrote: From: Sumit Semwal sumit.sem...@linaro.org Add debugfs support to make it easier to print debug information about the dma-buf buffers. I like thie idea, /home/airlied/devel/kernel/drm-2.6/drivers/base/dma-buf.c: In function ‘dma_buf_describe’: /home/airlied/devel/kernel/drm-2.6/drivers/base/dma-buf.c:563:5: warning: format ‘%d’ expects argument of type ‘int’, but argument 6 has type ‘long int’ [-Wformat] /home/airlied/devel/kernel/drm-2.6/drivers/base/dma-buf.c: At top level: /home/airlied/devel/kernel/drm-2.6/drivers/base/dma-buf.c:528:123: warning: ‘dma_buf_init’ defined but not used [-Wunused-function] not sure my compiler does though. Dave. -- 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] dma-buf: Add debugfs support
On Thu, Dec 20, 2012 at 11:26 AM, Dave Airlie airl...@gmail.com wrote: On Fri, Dec 14, 2012 at 7:36 PM, sumit.sem...@ti.com wrote: From: Sumit Semwal sumit.sem...@linaro.org Add debugfs support to make it easier to print debug information about the dma-buf buffers. I've attached two patches that make it work on my system, and fix the warnings, I've used it to debug some leaks I was seeing, feel free to squash these patches into the original patch. Dave. 0001-dma_buf-fix-debugfs-init.patch Description: Binary data 0002-dma-buf-fix-warning-in-seq_printf.patch Description: Binary data
[GIT PULL]: dma-buf updates for 3.8
Hi Linus, A fairly small dma-buf pull request for 3.8 - only 2 patches. Could you please pull? Thanks! ~Sumit. The following changes since commit f01af9f85855e38fbd601e033a8eac204cc4cc1c: Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc (2012-12-19 20:31:02 -0800) are available in the git repository at: git://git.linaro.org/people/sumitsemwal/linux-dma-buf.git tags/tag-for-linus-3.8 for you to fetch changes up to ada65c74059f8c104f1b467c126205471634c435: dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER (2012-12-20 12:05:06 +0530) 3.8: dma-buf minor updates Maarten Lankhorst (1): dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER Rob Clark (1): dma-buf: might_sleep() in dma_buf_unmap_attachment() drivers/base/dma-buf.c |2 + include/linux/dma-buf.h | 99 --- 2 files changed, 2 insertions(+), 99 deletions(-) -- 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
