Re: [PATCH 6/6] V4L: soc-camera: remove soc-camera bus and devices on it
On Sat, Jul 16, 2011 at 02:14:03AM +0200, Guennadi Liakhovetski wrote: > Now that v4l2 subdevices have got their own device objects, having > one more device in soc-camera clients became redundant and confusing. > This patch removes those devices and the soc-camera bus, they used to > reside on. > > Signed-off-by: Guennadi Liakhovetski > --- > > This one looks pretty big, most of it are just 10-liners. It removes more > than a 100 lines of code. Tested on sh-mobile, pxa270, i.MX31. Compile > tested with all soc-camera hosts and clients. Hope it doesn't break too > many things, if it does, we'll have the whole 3.1-rc timeframe to fix > them. > Acked-by: Paul Mundt -- 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 4/6] V4L: sh_mobile_csi2: switch away from using the soc-camera bus notifier
On Sat, Jul 16, 2011 at 02:13:54AM +0200, Guennadi Liakhovetski wrote: > This moves us one more step closer to eliminating the soc-camera bus > and devices on it. Besides, as a side effect, CSI-2 runtime PM on > sh-mobile secomes finer grained now: we only have to power on the > interface, when the device nodes are open. > > Signed-off-by: Guennadi Liakhovetski > --- > arch/arm/mach-shmobile/board-ap4evb.c | 12 +-- > drivers/media/video/sh_mobile_ceu_camera.c | 117 ++-- > drivers/media/video/sh_mobile_csi2.c | 135 > +++- > include/media/sh_mobile_ceu.h | 10 ++- > include/media/sh_mobile_csi2.h |8 +- > 5 files changed, 180 insertions(+), 102 deletions(-) Acked-by: Paul Mundt -- 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] fbdev: Add FOURCC-based format configuration API
On Thu, Jun 23, 2011 at 06:08:03PM +0200, Geert Uytterhoeven wrote: > On Wed, Jun 22, 2011 at 07:45, Florian Tobias Schandinat > wrote: > > On 06/21/2011 10:31 PM, Laurent Pinchart wrote: > >> On Tuesday 21 June 2011 22:49:14 Geert Uytterhoeven wrote: > >>> As FOURCC values are always 4 ASCII characters (hence all 4 bytes must > >>> be non-zero), I don't think there are any conflicts with existing values > >>> of > >>> nonstd. To make it even safer and easier to parse, you could set bit 31 > >>> of > >>> nonstd as a FOURCC indicator. > >> > >> I would then create a union between nonstd and fourcc, and document nonstd > >> as > >> being used for the legacy API only. Most existing drivers use a couple of > >> nonstd bits only. The driver that (ab)uses nonstd the most is pxafb and > >> uses > >> bits 22:0. Bits 31:24 are never used as far as I can tell, so nonstd& > >> 0xff00 != 0 could be used as a FOURCC mode test. > >> > >> This assumes that FOURCCs will never have their last character set to > >> '\0'. Is > >> that a safe assumption for the future ? > > > > Yes, I think. The information I found indicates that space should be used > > for padding, so a \0 shouldn't exist. > > I think using only the nonstd field and requiring applications to check the > > capabilities would be possible, although not fool proof ;) > > So we can declare the 8 msb bits of nonstd reserved, and assume FOURCC if > any of them is set. > > Nicely backwards compatible, as sane drivers should reject nonstd values they > don't support (apps _will_ start filling in FOURCC values ignoring > capabilities, > won't they?). > That seems like a reasonable case, but if we're going to do that then certainly the nonstd bit encoding needs to be documented and treated as a hard ABI. I'm not so sure about the if any bit in the upper byte is set assume FOURCC case though, there will presumably be other users in the future that will want bits for themselves, too. What exactly was the issue with having a FOURCC capability bit in the upper byte? -- 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] ARM: mach-shmobile: add coherent DMA mask to CEU camera devices
On Wed, Mar 23, 2011 at 10:29:16AM +0100, Guennadi Liakhovetski wrote: > Cameras are currently broken on ARM sh-mobile platforms. They need a > suitable coherent DMA mask. > > Signed-off-by: Guennadi Liakhovetski Applied, thanks. -- 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] HDMI:Support for EDID parsing in kernel.
On Tue, Mar 22, 2011 at 02:52:59PM -0300, Mauro Carvalho Chehab wrote: > Em 22-03-2011 14:32, Mythri P K escreveu: > > Adding support for common EDID parsing in kernel. > > > > EDID - Extended display identification data is a data structure provided by > > a digital display to describe its capabilities to a video source, This a > > standard supported by CEA and VESA. > > > > There are several custom implementations for parsing EDID in kernel, some > > of them are present in fbmon.c, drm_edid.c, sh_mobile_hdmi.c, Ideally > > parsing of EDID should be done in a library, which is agnostic of the > > framework (V4l2, DRM, FB) which is using the functionality, just based on > > the raw EDID pointer with size/segment information. > > > > With other RFC's such as the one below, which tries to standardize HDMI > > API's > > It would be better to have a common EDID code in one place.It also helps to > > provide better interoperability with variety of TV/Monitor may be even by > > listing out quirks which might get missed with several custom implementation > > of EDID. > > http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/30401 > > > > This patch tries to add functions to parse some portion EDID (detailed > > timing, > > monitor limits, AV delay information, deep color mode support, Audio and > > VSDB) > > If we can align on this library approach i can enhance this library to parse > > other blocks and probably we could also add quirks from other implementation > > as well. > > > > Signed-off-by: Mythri P K > > --- > > arch/arm/include/asm/edid.h | 243 ++ > > drivers/video/edid.c| 340 > > +++ > > Hmm... if you want this to be agnostic, the header file should not be inside > arch/arm, but on some other place, like include/video/. > Ironically this adds a drivers/video/edid.c but completely ignores drivers/video/edid.h which already exists and already contains many of these definitions. I like the idea of a generalized library, but it would be nice to see the existing edid.h evolved and its users updated incrementally. -- 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_declare_coherent_memory: push ioremap() up to caller
On Fri, Dec 24, 2010 at 12:20:32AM +0100, Janusz Krzysztofik wrote: > Tested on ARM OMAP1 based Amstrad Delta with a WIP OMAP1 camera patch, > patterned upon two mach-mx3 machine types which already try to use the > dma_declare_coherent_memory() method for reserving a region of system > RAM preallocated with another dma_alloc_coherent(). Compile tested for > all modified files except arch/sh/drivers/pci/fixups-dreamcast.c. > > Signed-off-by: Janusz Krzysztofik The arch/sh/drivers/pci/fixups-dreamcast.c build fine. Acked-by: Paul Mundt -- 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_declare_coherent_memory: push ioremap() up to caller
On Thu, Dec 23, 2010 at 11:54:34PM +, Russell King - ARM Linux wrote: > On Fri, Dec 24, 2010 at 12:20:32AM +0100, Janusz Krzysztofik wrote: > > The patch tries to implement a solution suggested by Russell King, > > http://lists.infradead.org/pipermail/linux-arm-kernel/2010-December/035264.html. > > > > It is expected to solve video buffer allocation issues for at least a > > few soc_camera I/O memory less host interface drivers, designed around > > the videobuf_dma_contig layer, which allocates video buffers using > > dma_alloc_coherent(). > > > > Created against linux-2.6.37-rc5. > > > > Tested on ARM OMAP1 based Amstrad Delta with a WIP OMAP1 camera patch, > > patterned upon two mach-mx3 machine types which already try to use the > > dma_declare_coherent_memory() method for reserving a region of system > > RAM preallocated with another dma_alloc_coherent(). Compile tested for > > all modified files except arch/sh/drivers/pci/fixups-dreamcast.c. > > > > Signed-off-by: Janusz Krzysztofik > > --- > > I intended to quote Russell in my commit message and even asked him for > > his permission, but since he didn't respond, I decided to include a link > > to his original message only. > > There's no problem quoting messages which were sent to public mailing > lists, especially when there's a record of what was said in public > archives too. > > I think this is definitely a step forward. > The -tip folks have started using LKML-Reference tags to help with this, although I don't believe its usage is officially documented anywhere. -- 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: [Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
On Tue, Oct 19, 2010 at 08:39:58AM -0400, Steven Rostedt wrote:
> On Tue, 2010-10-19 at 09:26 +0200, Arnd Bergmann wrote:
> > On Tuesday 19 October 2010 06:52:32 Dave Airlie wrote:
> > > > I might be able to find some hardware still lying around here that uses
> > > > an
> > > > i810. Not sure unless I go hunting it. But I get the impression that if
> > > > the kernel is a single-CPU kernel there is not any problem anyway? Don't
> > > > distros offer a non-smp kernel as an installation option in case the
> > > > user
> > > > needs it? So in reality how big a problem is this?
> > >
> > > Not anymore, which is my old point of making a fuss. Nowadays in the
> > > modern distro world, we supply a single kernel that can at runtime
> > > decide if its running on SMP or UP and rewrite the text section
> > > appropriately with locks etc. Its like magic, and something like
> > > marking drivers as BROKEN_ON_SMP at compile time is really wrong when
> > > what you want now is a runtime warning if someone tries to hotplug a
> > > CPU with a known iffy driver loaded or if someone tries to load the
> > > driver when we are already in SMP mode.
> >
> > We could make the driver run-time non-SMP by adding
> >
> > if (num_present_cpus() > 1) {
> > pr_err("i810 no longer supports SMP\n");
> > return -EINVAL;
> > }
> >
> > to the init function. That would cover the vast majority of the
> > users of i810 hardware, I guess.
>
> I think we also need to cover the PREEMPT case too. But that could be a
> compile time check, since you can't boot a preempt kernel and make it
> non preempt.
>
There are enough nameless embedded vendors that have turned a preempt
kernel in to a non-preempt one at run-time by leaking the preempt count,
whether by design or not, so it's certainly possile :-)
--
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] SH: add Video Output Unit and AK8813 video encoder support on ecovec
On Wed, Apr 21, 2010 at 10:45:25AM +0200, Guennadi Liakhovetski wrote: > Ecovec uses the AK8813 video envoder similarly to the ms7724se platform with > the only difference, that on ecovec GPIOs are used for resetting and powering > up and down the chip. > > Signed-off-by: Guennadi Liakhovetski > --- > > This patch extends the SuperH VOU / AK881x patch series: > http://thread.gmane.org/gmane.linux.ports.sh.devel/7751/focus=7753 > > arch/sh/boards/mach-ecovec24/setup.c | 78 > ++ > 1 files changed, 78 insertions(+), 0 deletions(-) > Applied, thanks. -- 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 3/3] sh: add Video Output Unit (VOU) and AK8813 TV-encoder support to ms7724se
On Thu, Mar 11, 2010 at 02:45:00PM +0100, Guennadi Liakhovetski wrote: > Add platform bindings, GPIO initialisation and allocation and AK8813 reset > code > to ms7724se. > > Signed-off-by: Guennadi Liakhovetski > --- > > Obviously depends on the previous two VOU and AK881x patches, sorry for > not marking those with "PATCH x/3" accordingly. Those two patches do not > depend upon each other and initially I wasn't sure I'd be able to clean up > this patch sufficiently for submission. Two 10us delays are pretty random, > maybe they can be optimised out completely. I just tried to reproduced the > reset procedure from the ak8813 datasheet, and it says nothing about the > duration of respective stages. > > arch/sh/boards/mach-se/7724/setup.c | 88 > --- > 1 files changed, 81 insertions(+), 7 deletions(-) > Now that the other two patches are upstream, I've applied this. -- 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] media/IR: Add missing include file to rc-map.c
On Tue, May 11, 2010 at 08:42:14PM +0200, Peter H?we wrote: > Am Mittwoch 05 Mai 2010 17:20:21 schrieb Peter H?we: > > From: Peter Huewe > > > > This patch adds a missing include linux/delay.h to prevent > > build failures[1-5] > > > > Signed-off-by: Peter Huewe > > --- > Any updates on this patch? > Issue still exists with today's linux-next tree > You might want to send this to the linux-next list at least. If the people who introduced the breakage are unresponsive (as often tends to be the case with -next) it's still worth getting trivial fixes rolled in for the interim. This change doesn't exist outside of -next and whatever tree introduced it, so there's not much else anyone can do about it at present. -- 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/3 v2] V4L: SuperH Video Output Unit (VOU) driver
On Thu, Mar 18, 2010 at 11:28:28AM +0100, Guennadi Liakhovetski wrote: > diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig > index 64682bf..be6d016 100644 > --- a/drivers/media/video/Kconfig > +++ b/drivers/media/video/Kconfig > @@ -511,6 +511,13 @@ config DISPLAY_DAVINCI_DM646X_EVM > To compile this driver as a module, choose M here: the > module will be called vpif_display. > > +config VIDEO_SH_VOU > + tristate "SuperH VOU video output driver" > + depends on VIDEO_DEV && (SUPERH || ARCH_SHMOBILE) > + select VIDEOBUF_DMA_CONTIG > + help > + Support for the Video Output Unit (VOU) on SuperH SoCs. > + I assumed the VOU was only on SH-Mobile, in which case you can just depend on ARCH_SHMOBILE directly, since we set that for all SH-Mobile CPUs anyways. After that's done or proven to be an inaccurate assumption: Acked-by: Paul Mundt -- 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: acks needed for arch/sh parts of the patches
On Thu, Dec 03, 2009 at 10:58:08PM +0100, Guennadi Liakhovetski wrote: > unfortunately 3 of my V4L patches for 2.6.33 have to touch arch/sh > simultaneously with drivers and headers. Therefore I need your acks to > them for arch parts. All those patches have already been posted to the > list at different times, here are links to them (perhaps, with some minor > differences): > > http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/13307 > http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/11492 > http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/11504 > > I will also send patches directly to you without cc-ing the list for > easier review. If you have no objections, you can just reply to this mail > confirming your 3 acks, if you have any comments, please reply to > respective mails, and then, please, add the v4l list back to cc. > Looks good to me. Acked-by: Paul Mundt -- 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/2] SH: add support for the RJ54N1CB0C camera for the kfr2r09 platform
On Mon, Oct 05, 2009 at 05:20:48PM +0200, Guennadi Liakhovetski wrote: > On Mon, 5 Oct 2009, Paul Mundt wrote: > > > On Sat, Oct 03, 2009 at 01:21:30PM +0200, Guennadi Liakhovetski wrote: > > > Signed-off-by: Guennadi Liakhovetski > > > --- > > > arch/sh/boards/mach-kfr2r09/setup.c | 139 > > > +++ > > > 1 files changed, 139 insertions(+), 0 deletions(-) > > > > > This seems to depend on the RJ54N1CB0C driver, so I'll queue this up > > after that has been merged in the v4l tree. If it's available on a topic > > branch upstream that isn't going to be rebased, then I can pull that in, > > but this is not so critical either way. > > It actually shouldn't depend on the driver patch. The driver has no > headers, so... I haven't verified, but it should work either way. OTOH, > waiting for the driver patch is certainly a safe bet:-) > I thought it had a header dependency, but I must have been imagining things. So in that regard it looks fine, I'll split out my 2.6.32 stuff in to a separate branch momentarily and then roll this in when I start taking 2.6.33 stuff. This should at least allow us to start testing in -next when the driver is merged. -- 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/2] SH: add support for the RJ54N1CB0C camera for the kfr2r09 platform
On Sat, Oct 03, 2009 at 01:21:30PM +0200, Guennadi Liakhovetski wrote: > Signed-off-by: Guennadi Liakhovetski > --- > arch/sh/boards/mach-kfr2r09/setup.c | 139 > +++ > 1 files changed, 139 insertions(+), 0 deletions(-) > This seems to depend on the RJ54N1CB0C driver, so I'll queue this up after that has been merged in the v4l tree. If it's available on a topic branch upstream that isn't going to be rebased, then I can pull that in, but this is not so critical either way. -- 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: [PULL] soc-camera 2.6.32: new driver and a compile-fix
On Fri, Sep 25, 2009 at 01:29:08AM -0300, Mauro Carvalho Chehab wrote: > Em Fri, 25 Sep 2009 11:52:19 +0900 > Paul Mundt escreveu: > > > On Wed, Sep 23, 2009 at 06:02:04PM +0200, Guennadi Liakhovetski wrote: > > > On Wed, 23 Sep 2009, Guennadi Liakhovetski wrote: > > > > > > > Hi Mauro > > > > > > > > The following two patches are for 2.6.32. One of them fixes > > > > sh_mobile_ceu_camera compile breakage, and another one adds a new > > > > soc-camera / v4l2-subdev driver for ov9640. Marek, looks like you > > > > didn't > > > > even compile tested your driver with CONFIG_VIDEO_ADV_DEBUG=y. It > > > > didn't > > > > compile, so, I had to fix it. > > > > > > > > Please pull from http://linuxtv.org/hg/~gliakhovetski/v4l-dvb > > > > > > > > for the following 2 changesets: > > > > > > > > 01/02: V4L2: Add a v4l2-subdev (soc-camera) driver for OmniVision > > > > OV9640 sensor > > > > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=1dec51b360a3 > > > > > > > > 02/02: sh_mobile_ceu_camera: fix compile breakage, caused by a bad merge > > > > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=a798c751f06d > > > > > > Sorry, forgot to mention, somehow, the git and the hg versions got > > > different merges, both wrong, so, for the git the following equivalent > > > patch will be needed, after which the two versions shall be in sync again: > > > > > > sh_mobile_ceu_camera: fix compile breakage, caused by a bad merge > > > > > > Signed-off-by: Guennadi Liakhovetski > > > > So who wants to push this one? I'm planning on sending Linus updates > > shortly, so can roll this in with mine, as it seems to have missed the > > last v4l merge. > > Paul, > > It seems fine to me if you could do it. I have some pending stuff on other > kernel areas, so I'd appreciate if you can handle this fix. > > You have my ack on it: > > Acked-by: Mauro Carvalho Chehab > Ok, I'll queue it up, thanks! -- 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: [PULL] soc-camera 2.6.32: new driver and a compile-fix
On Wed, Sep 23, 2009 at 06:02:04PM +0200, Guennadi Liakhovetski wrote: > On Wed, 23 Sep 2009, Guennadi Liakhovetski wrote: > > > Hi Mauro > > > > The following two patches are for 2.6.32. One of them fixes > > sh_mobile_ceu_camera compile breakage, and another one adds a new > > soc-camera / v4l2-subdev driver for ov9640. Marek, looks like you didn't > > even compile tested your driver with CONFIG_VIDEO_ADV_DEBUG=y. It didn't > > compile, so, I had to fix it. > > > > Please pull from http://linuxtv.org/hg/~gliakhovetski/v4l-dvb > > > > for the following 2 changesets: > > > > 01/02: V4L2: Add a v4l2-subdev (soc-camera) driver for OmniVision OV9640 > > sensor > > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=1dec51b360a3 > > > > 02/02: sh_mobile_ceu_camera: fix compile breakage, caused by a bad merge > > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=a798c751f06d > > Sorry, forgot to mention, somehow, the git and the hg versions got > different merges, both wrong, so, for the git the following equivalent > patch will be needed, after which the two versions shall be in sync again: > > sh_mobile_ceu_camera: fix compile breakage, caused by a bad merge > > Signed-off-by: Guennadi Liakhovetski So who wants to push this one? I'm planning on sending Linus updates shortly, so can roll this in with mine, as it seems to have missed the last v4l merge. -- 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 3/3] soc-camera: fix recently introduced overlong lines
On Tue, Aug 25, 2009 at 01:06:07PM +0200, Guennadi Liakhovetski wrote: > Signed-off-by: Guennadi Liakhovetski > Cc: Paul Mundt > --- > arch/sh/boards/board-ap325rxa.c |3 ++- > drivers/media/video/mt9m111.c |9 + > drivers/media/video/mt9v022.c |5 - > drivers/media/video/mx1_camera.c |3 ++- > drivers/media/video/ov772x.c |6 -- > drivers/media/video/pxa_camera.c |3 ++- > drivers/media/video/soc_camera.c | 14 +++--- > drivers/media/video/soc_camera_platform.c |3 ++- > drivers/media/video/tw9910.c |3 ++- > include/media/soc_camera.h| 15 ++- > 10 files changed, 44 insertions(+), 20 deletions(-) > Acked-by: Paul Mundt -- 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: [BUG] drivers/video/sis: deadlock introduced by "fbdev: add mutex for fb_mmap locking"
On Sun, Jul 05, 2009 at 08:19:40AM -0700, Linus Torvalds wrote:
>
>
> On Mon, 6 Jul 2009, Paul Mundt wrote:
> > >
> > > Why not "lock" as well?
> >
> > I had that initially, but matroxfb will break if we do that, and
> > presently nothing cares about trying to take ->lock that early on.
>
> I really would rather have consistency than some odd rules like that.
>
> In particular - if matroxfb is different and needs its own lock
> initialization because it doesn't use the common allocation routine, then
> please make _that_ consistent too. Rather than have it special-case just
> one lock that it needs to initialize separately, make it clear that since
> it does its own allocations it needs to initialize _everything_
> separately.
>
Ok, here is an updated version with an updated matroxfb and the sm501fb
change reverted.
Signed-off-by: Paul Mundt
---
drivers/video/fbmem.c|2 --
drivers/video/fbsysfs.c |3 +++
drivers/video/matrox/matroxfb_base.c |1 +
drivers/video/sm501fb.c |2 --
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
index 53ea056..53eb396 100644
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -1513,8 +1513,6 @@ register_framebuffer(struct fb_info *fb_info)
if (!registered_fb[i])
break;
fb_info->node = i;
- mutex_init(&fb_info->lock);
- mutex_init(&fb_info->mm_lock);
fb_info->dev = device_create(fb_class, fb_info->device,
MKDEV(FB_MAJOR, i), NULL, "fb%d", i);
diff --git a/drivers/video/fbsysfs.c b/drivers/video/fbsysfs.c
index d4a2c11..afc04df 100644
--- a/drivers/video/fbsysfs.c
+++ b/drivers/video/fbsysfs.c
@@ -62,6 +62,9 @@ struct fb_info *framebuffer_alloc(size_t size, struct device
*dev)
mutex_init(&info->bl_curve_mutex);
#endif
+ mutex_init(&info->lock);
+ mutex_init(&info->mm_lock);
+
return info;
#undef PADDING
#undef BYTES_PER_LONG
diff --git a/drivers/video/matrox/matroxfb_base.c
b/drivers/video/matrox/matroxfb_base.c
index 59c3a2e..76bc51b 100644
--- a/drivers/video/matrox/matroxfb_base.c
+++ b/drivers/video/matrox/matroxfb_base.c
@@ -2083,6 +2083,7 @@ static int matroxfb_probe(struct pci_dev* pdev, const
struct pci_device_id* dumm
spin_lock_init(&ACCESS_FBINFO(lock.accel));
init_rwsem(&ACCESS_FBINFO(crtc2.lock));
init_rwsem(&ACCESS_FBINFO(altout.lock));
+ mutex_init(&ACCESS_FBINFO(fbcon).lock);
mutex_init(&ACCESS_FBINFO(fbcon).mm_lock);
ACCESS_FBINFO(irq_flags) = 0;
init_waitqueue_head(&ACCESS_FBINFO(crtc1.vsync.wait));
diff --git a/drivers/video/sm501fb.c b/drivers/video/sm501fb.c
index 16d4f4c..98f24f0 100644
--- a/drivers/video/sm501fb.c
+++ b/drivers/video/sm501fb.c
@@ -1624,8 +1624,6 @@ static int __devinit sm501fb_start_one(struct
sm501fb_info *info,
if (!fbi)
return 0;
- mutex_init(&info->fb[head]->mm_lock);
-
ret = sm501fb_init_fb(info->fb[head], head, drvname);
if (ret) {
dev_err(info->dev, "cannot initialise fb %s\n", drvname);
--
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: [BUG] drivers/video/sis: deadlock introduced by "fbdev: add mutex for fb_mmap locking"
On Sun, Jul 05, 2009 at 07:56:56AM -0700, Linus Torvalds wrote: > > > On Sun, 5 Jul 2009, Paul Mundt wrote: > > break; > > fb_info->node = i; > > mutex_init(&fb_info->lock); > > - mutex_init(&fb_info->mm_lock); > > Why not "lock" as well? > I had that initially, but matroxfb will break if we do that, and presently nothing cares about trying to take ->lock that early on. ->mm_lock was a special case as the lock/unlock pairs were sprinkled around well before initialization, while in the ->lock case all of the lock/unlock pairs are handled internally by the fbmem code (at least a quick grep does not show any drivers using it on their own). -- 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: [BUG] drivers/video/sis: deadlock introduced by "fbdev: add mutex for fb_mmap locking"
On Sun, Jul 05, 2009 at 07:19:33AM -0700, Linus Torvalds wrote: > > > On Sun, 5 Jul 2009, Wu Zhangjin wrote: > > > > then it works! so, I guess there is a deadlock introduced by the above > > commit. > > Hmm. Perhaps more likely, the 'mm_lock' mutex hasn't even been initialized > yet. We appear to have had that problem with matroxfb and sm501fb, and it > may be more common than that. See commit f50bf2b2. > > That said, I do agree that the mm_lock seems to be causing more problems > than it actually fixes, and maybe we should revert it. Krzysztof? > Looking at this a bit closer, just moving the mutex initialization in to framebuffer_alloc() should basically fix most of these, at least it certainly does for sm501fb and for this sis case as well. So, here's a patch to do that. As an aside note, matroxfb is the odd one out, as it doesn't use framebuffer_alloc() directly for whatever reason. This actually raises an additional issue, in that framebuffer_alloc() is already where other mutexes are initialized, which will simply never happen on matroxfb (suggesting that at least the FB_BACKLIGHT and matroxfb combination will blow up, although perhaps that's not a valid combination). Signed-off-by: Paul Mundt --- drivers/video/fbmem.c |1 - drivers/video/fbsysfs.c |2 ++ 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c index 53ea056..27a5271 100644 --- a/drivers/video/fbmem.c +++ b/drivers/video/fbmem.c @@ -1514,7 +1514,6 @@ register_framebuffer(struct fb_info *fb_info) break; fb_info->node = i; mutex_init(&fb_info->lock); - mutex_init(&fb_info->mm_lock); fb_info->dev = device_create(fb_class, fb_info->device, MKDEV(FB_MAJOR, i), NULL, "fb%d", i); diff --git a/drivers/video/fbsysfs.c b/drivers/video/fbsysfs.c index d4a2c11..dd413ad 100644 --- a/drivers/video/fbsysfs.c +++ b/drivers/video/fbsysfs.c @@ -62,6 +62,8 @@ struct fb_info *framebuffer_alloc(size_t size, struct device *dev) mutex_init(&info->bl_curve_mutex); #endif + mutex_init(&info->mm_lock); + return info; #undef PADDING #undef BYTES_PER_LONG -- 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 00/10 v2] soc-camera conversions
On Mon, Jun 08, 2009 at 09:19:50PM +0200, Guennadi Liakhovetski wrote: > On Tue, 19 May 2009, Paul Mundt wrote: > > > On Fri, May 15, 2009 at 07:18:45PM +0200, Guennadi Liakhovetski wrote: > > > this is the next round of soc-camera conversions. Run-tested on i.MX31, > > > PXA270, SH7722, compile-tested only for i.MX1. It should have been a > > > "straight-forward" port of the previous version to a more current tree, > > > but then I started converting soc_camera_platform, and things became a > > > bit > > > more complex... As a bonus, now soc-camera can handle not only i2c > > > subdevices, and we can even drop the CONFIG_I2C dependency again. I'll > > > also upload a comlpete stack somewhere a bit later, for example for > > > those, > > > wishing to test it on i.MX31, otherwise the series will not apply > > > cleanly. > > > > > > I'd like to push the first 8 of them asap, 9 and 10 will still have to be > > > reworked > > > > > > Paul, I put you on "cc" on all patches, because, unfortunately, several > > > of > > > them affect arch/sh. But I'll mention it explicitly in each such patch. > > > > > Looks ok to me, there shouldn't be any problems with taking these all > > through the v4l tree. Feel free to add my Acked-by if you like. I guess > > we will find out in -next if there are any conflicts or not :-) > > Yes, can do this, thanks, but first these 3 patches (including Magnus' > ack) have to be applied to sh: > http://www.mail-archive.com/linux-media@vger.kernel.org/msg05223.html > which in turn depend on > http://www.mail-archive.com/linux-media@vger.kernel.org/msg04724.html > and the latter one is already in the next tree. Would you like me to also > merge and pull the above three patches via v4l or would you be applying > them yourself? > I can take care of them once the dependent patch is merged. -- 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] i2c: Simplified CONFIG_I2C=n interface.
On Wed, May 27, 2009 at 09:18:31AM +0200, Jean Delvare wrote: > On Wed, 27 May 2009 16:08:50 +0900, Paul Mundt wrote: > > Another day, another module-related failure due to the i2c interface > > being used in code that optionally uses it: > > > > ERROR: "i2c_new_device" [drivers/media/video/soc_camera.ko] undefined! > > ERROR: "i2c_get_adapter" [drivers/media/video/soc_camera.ko] undefined! > > ERROR: "i2c_put_adapter" [drivers/media/video/soc_camera.ko] undefined! > > ERROR: "i2c_unregister_device" [drivers/media/video/soc_camera.ko] > > undefined! > > make[2]: *** [__modpost] Error 1 > > make[1]: *** [modules] Error 2 > > make: *** [sub-make] Error 2 > > > > In the interest of not continually inserting i2c ifdefs in to every > > driver that supports an optional i2c interface, this provides a stubbed > > set of interfaces for the CONFIG_I2C=n case. > > > > I've covered the obvious ones that cause the majority of the build > > failures, anything more involved really ought to have its dependencies > > fixed instead. > > Violent nack. Drivers which optionally use I2C are a minority. If they were a minority we wouldn't be hitting them on a weekly basis, and other busses already do similar things for similar reasons. You may not like it, but it's much less distasteful than littering random i2c ifdefs around every driver that chooses to have an optional i2c interface. If every multi-bus driver was forced to go through these sorts of hoops, the drivers would be even less readable than they already are today. -- 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] i2c: Simplified CONFIG_I2C=n interface.
Another day, another module-related failure due to the i2c interface
being used in code that optionally uses it:
ERROR: "i2c_new_device" [drivers/media/video/soc_camera.ko] undefined!
ERROR: "i2c_get_adapter" [drivers/media/video/soc_camera.ko] undefined!
ERROR: "i2c_put_adapter" [drivers/media/video/soc_camera.ko] undefined!
ERROR: "i2c_unregister_device" [drivers/media/video/soc_camera.ko] undefined!
make[2]: *** [__modpost] Error 1
make[1]: *** [modules] Error 2
make: *** [sub-make] Error 2
In the interest of not continually inserting i2c ifdefs in to every
driver that supports an optional i2c interface, this provides a stubbed
set of interfaces for the CONFIG_I2C=n case.
I've covered the obvious ones that cause the majority of the build
failures, anything more involved really ought to have its dependencies
fixed instead.
Signed-off-by: Paul Mundt
---
include/linux/i2c.h | 109
1 file changed, 109 insertions(+)
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index ad25805..ba73cd0 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -277,6 +277,8 @@ struct i2c_board_info {
.type = dev_type, .addr = (dev_addr)
+#ifdef CONFIG_I2C
+
/* Add-on boards should register/unregister their devices; e.g. a board
* with integrated I2C, a config eeprom, sensors, and a codec that's
* used in conjunction with the primary hardware.
@@ -301,6 +303,33 @@ i2c_new_dummy(struct i2c_adapter *adap, u16 address);
extern void i2c_unregister_device(struct i2c_client *);
+#else
+
+static inline struct i2c_client *
+i2c_new_device(struct i2c_adapter *adap, struct i2c_board_info const *info)
+{
+ return NULL;
+}
+
+static inline struct i2c_client *
+i2c_new_probed_device(struct i2c_adapter *adap,
+ struct i2c_board_info *info,
+ unsigned short const *addr_list)
+{
+ return NULL;
+}
+
+static inline struct i2c_client *
+i2c_new_dummy(struct i2c_adapter *adap, u16 address)
+{
+ return NULL;
+}
+
+static inline void i2c_unregister_device(struct i2c_client *client)
+{
+}
+#endif /* CONFIG_I2C */
+
/* Mainboard arch_initcall() code should register all its I2C devices.
* This is done at arch_initcall time, before declaring any i2c adapters.
* Modules for add-on boards must use other calls.
@@ -415,6 +444,7 @@ struct i2c_client_address_data {
/* - functions exported by i2c.o */
+#ifdef CONFIG_I2C
/* administration...
*/
extern int i2c_add_adapter(struct i2c_adapter *);
@@ -460,6 +490,85 @@ static inline u32 i2c_get_functionality(struct i2c_adapter
*adap)
return adap->algo->functionality(adap);
}
+#else
+
+static inline int i2c_add_adapter(struct i2c_adapter *adap)
+{
+ return -ENODEV;
+}
+
+static inline int i2c_del_adapter(struct i2c_adapter *adap)
+{
+ return -ENODEV;
+}
+
+static inline int i2c_add_numbered_adapter(struct i2c_adapter *adap)
+{
+ return -ENODEV;
+}
+
+static inline int i2c_register_driver(struct module *module,
+ struct i2c_driver *driver)
+{
+ return -ENODEV;
+}
+
+static inline void i2c_del_driver(struct i2c_driver *driver)
+{
+}
+
+static inline int i2c_add_driver(struct i2c_driver *driver)
+{
+ return -ENODEV;
+}
+
+static inline int __deprecated i2c_attach_client(struct i2c_client *client)
+{
+ return -EINVAL;
+}
+
+static inline int __deprecated i2c_detach_client(struct i2c_client *client)
+{
+ return -EINVAL;
+}
+
+static inline struct i2c_client *i2c_use_client(struct i2c_client *client)
+{
+ return NULL;
+}
+
+static inline void i2c_release_client(struct i2c_client *client)
+{
+}
+
+static inline void i2c_clients_command(struct i2c_adapter *adap,
+ unsigned int cmd, void *arg)
+{
+}
+
+static inline int i2c_probe(struct i2c_adapter *adapter,
+ const struct i2c_client_address_data *address_data,
+ int (*found_proc) (struct i2c_adapter *, int, int))
+{
+ return -ENODEV;
+}
+
+static inline struct i2c_adapter *i2c_get_adapter(int id)
+{
+ return NULL;
+}
+
+static inline void i2c_put_adapter(struct i2c_adapter *adap)
+{
+}
+
+/* Return the functionality mask */
+static inline u32 i2c_get_functionality(struct i2c_adapter *adap)
+{
+ return 0;
+}
+#endif /* CONFIG_I2C */
+
/* Return 1 if adapter supports everything we need, 0 if not. */
static inline int i2c_check_functionality(struct i2c_adapter *adap, u32 func)
{
--
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 -next] v4l2: handle unregister for non-I2C builds
On Mon, May 11, 2009 at 09:37:41AM -0700, Randy Dunlap wrote:
> From: Randy Dunlap
>
> Build fails when CONFIG_I2C=n, so handle that case in the if block:
>
> drivers/built-in.o: In function `v4l2_device_unregister':
> (.text+0x157821): undefined reference to `i2c_unregister_device'
>
> Signed-off-by: Randy Dunlap
This patch still has not been applied as far as I can tell, and builds
are still broken as a result, almost 2 weeks after the fact.
> ---
> drivers/media/video/v4l2-device.c |2 ++
> 1 file changed, 2 insertions(+)
>
> --- linux-next-20090511.orig/drivers/media/video/v4l2-device.c
> +++ linux-next-20090511/drivers/media/video/v4l2-device.c
> @@ -85,6 +85,7 @@ void v4l2_device_unregister(struct v4l2_
> /* Unregister subdevs */
> list_for_each_entry_safe(sd, next, &v4l2_dev->subdevs, list) {
> v4l2_device_unregister_subdev(sd);
> +#if defined(CONFIG_I2C) || defined(CONFIG_I2C_MODULE)
> if (sd->flags & V4L2_SUBDEV_FL_IS_I2C) {
> struct i2c_client *client = v4l2_get_subdevdata(sd);
>
> @@ -95,6 +96,7 @@ void v4l2_device_unregister(struct v4l2_
> if (client)
> i2c_unregister_device(client);
> }
> +#endif
> }
> }
> EXPORT_SYMBOL_GPL(v4l2_device_unregister);
>
>
> --
> ~Randy
> LPC 2009, Sept. 23-25, Portland, Oregon
> http://linuxplumbersconf.org/2009/
> --
> To unsubscribe from this list: send the line "unsubscribe linux-next" 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: [PATCH 00/10 v2] soc-camera conversions
On Fri, May 15, 2009 at 07:18:45PM +0200, Guennadi Liakhovetski wrote: > this is the next round of soc-camera conversions. Run-tested on i.MX31, > PXA270, SH7722, compile-tested only for i.MX1. It should have been a > "straight-forward" port of the previous version to a more current tree, > but then I started converting soc_camera_platform, and things became a bit > more complex... As a bonus, now soc-camera can handle not only i2c > subdevices, and we can even drop the CONFIG_I2C dependency again. I'll > also upload a comlpete stack somewhere a bit later, for example for those, > wishing to test it on i.MX31, otherwise the series will not apply cleanly. > > I'd like to push the first 8 of them asap, 9 and 10 will still have to be > reworked > > Paul, I put you on "cc" on all patches, because, unfortunately, several of > them affect arch/sh. But I'll mention it explicitly in each such patch. > Looks ok to me, there shouldn't be any problems with taking these all through the v4l tree. Feel free to add my Acked-by if you like. I guess we will find out in -next if there are any conflicts or not :-) -- 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] videobuf-dma-contig: remove sync operation
On Tue, Apr 28, 2009 at 05:45:39PM +0900, Magnus Damm wrote: > From: Magnus Damm > > Remove the videobuf-dma-contig sync operation. Sync is only needed > for noncoherent buffers, and since videobuf-dma-contig is built on > coherent memory allocators the memory is by definition always in sync. > Note that this also fixes a bogus oops, which is what caused this to be brought up in the first place.. > Reported-by: Matthieu CASTET > Signed-off-by: Magnus Damm > --- > > Thanks to Mattieu, Paul and Paulius for all the help! > Tested on SH7722 Migo-R with CEU and ov7725. > > drivers/media/video/videobuf-dma-contig.c | 14 -- > 1 file changed, 14 deletions(-) > Reviewed-by: Paul Mundt -- 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
