Remove the code in omap_vout_probe() which calls display->driver->update() for
all the displays. This isn't correct because:
- An update in probe doesn't make sense, because we don't have any valid content
to show at this time.
- Calling update for a panel which isn't enabled is not supported by
Add support for DSI panels. DSI video mode panels will work directly. For
command mode panels, we will need to trigger updates regularly. This isn't done
by the omap_vout driver currently. It can still be supported if we connect a
framebuffer device to the panel and configure it in auto update mode
Currently, in omap_vout_isr(), if the panel type is DPI, and if we
get either VSYNC or VSYNC2 interrupts, we proceed ahead to set the
current buffers state to VIDEOBUF_DONE and prepare to display the
next frame in the queue.
On OMAP4, because we have 2 LCD managers, the panel type itself is not
su
Currently, there is a lot of redundant code is between DPI and VENC panels, this
can be made common by moving out field/interlace specific code to a separate
function called omapvid_handle_interlace_display(). There is no functional
change made.
Signed-off-by: Archit Taneja
---
drivers/media/vid
The commit 383e4f69879d11c86ebdd38b3356f6d0690fb4cc makes reqbuf prevent
requesting a larger size buffer than what is allocated at kernel boot during
omap_vout_probe.
The requested size is compared with vout->buffer_size, this isn't correct as
vout->buffer_size is later set to the size requested i
This set includes patches which do the following:
- Fix crash if a we call dssdev->driver->update for a disabled panel.
- Fix the issue of not being able to request for a buffer which is larger than
what we did the last time.
- Fix a small bug in omap_vout_isr()
- Remove some redundant code in om
On OMAP3, in order to enable alpha blending for LCD and TV managers, we needed
to set LCDALPHABLENDERENABLE/TVALPHABLENDERENABLE bits in DISPC_CONFIG. On
OMAP4, alpha blending is always enabled by default, if the above bits are set,
we switch to an OMAP3 compatibility mode where the zorder values i
Hi,
On Wednesday 21 September 2011 04:15 PM, Taneja, Archit wrote:
Hi,
On Wednesday 21 September 2011 03:35 PM, Hiremath, Vaibhav wrote:
-Original Message-
From: Taneja, Archit
Sent: Friday, September 16, 2011 3:31 PM
To: Hiremath, Vaibhav
Cc: Valkeinen, Tomi; linux-o...@vger.kernel.
Em 25-09-2011 10:55, Devin Heitmueller escreveu:
> On Sun, Sep 25, 2011 at 8:33 AM, Patrick Dickey wrote:
>> Hello there,
>>
>> I tried to follow the steps for cloning both the "media_tree.git" and
>> "media_build.git" repositories, and received errors for both. The
>> media_tree repository faile
Em 25-09-2011 15:03, Johannes Stezenbach escreveu:
> On Sun, Sep 25, 2011 at 07:33:57AM -0500, Patrick Dickey wrote:
>>
>> I tried to follow the steps for cloning both the "media_tree.git" and
>> "media_build.git" repositories, and received errors for both. The
>> media_tree repository failed on t
Mauro,
This patch simplifies the locking by moving the em28xx_init_extension() call
until em28xx_usb_probe() has finished with the dev->lock mutex. It therefore
makes the second and subsequent "plugging" events logically identical to the
first "plugging" event when the em28xx-dvb and em28xx-al
Hi Mauro,
On Sat, Sep 24, 2011 at 05:34, Mauro Carvalho Chehab wrote:
> Everything at patchwork were reviewed by me, and I've applied all patches
> that I didn't notice any review by the drivers maintainers.
>
> Driver maintainers:
> Please review the remaining patches.
(...)
> ==
--- On Sun, 25/9/11, Mauro Carvalho Chehab wrote:
> Yes. Just after creating a device, udev tries to access it.
> This bug is more sensitive on multi-CPU machines, as udev may run on
> another CPU.
Heh, I have a hyper-threaded quad-core here. I suspect that counts as
"multi-CPU" :-).
However, I
Em 25-09-2011 16:28, Chris Rankin escreveu:
> --- On Sun, 25/9/11, Mauro Carvalho Chehab wrote:
>> Ok, I've applied it, but it doesn't sound a good idea to me
>> to do:
>>
>> +mutex_unlock(&dev->lock);
>> em28xx_init_extension(dev);
>> +mutex_lock(&dev->lock);
>>
>
> Yes, I suppose i
Em 25-09-2011 10:32, Chris Rankin escreveu:
> On 25/09/11 14:00, Mauro Carvalho Chehab wrote:
>> Hmm... This would probably work better (not tested). Could you please test it
>> on your hardware?
>
> Hmm, I don't understand this.
> The deadlock isn't about taking em28xx_devlist_mutex, but happens
--- On Sun, 25/9/11, Mauro Carvalho Chehab wrote:
> Ok, I've applied it, but it doesn't sound a good idea to me
> to do:
>
> + mutex_unlock(&dev->lock);
> em28xx_init_extension(dev);
> + mutex_lock(&dev->lock);
>
Yes, I suppose it's the logical equivalent of moving the
em28xx_init_e
On Sun, Sep 25, 2011 at 07:33:57AM -0500, Patrick Dickey wrote:
>
> I tried to follow the steps for cloning both the "media_tree.git" and
> "media_build.git" repositories, and received errors for both. The
> media_tree repository failed on the first line
>
> > git clone
> > git://git.kernel.org
2011/9/24 Jin Kazama :
> On 9/24/11 12:06 AM, Antti Palosaari wrote:
>>
>> On 09/24/2011 12:06 AM, Jin Kazama wrote:
>>>
>>> Hello,
>>> I've been testing af9015/tda18218 based usb DVB-T tuners on a 2.6.39.4
>>> kernel with the latest v4l drivers avaiable (from git).
>>> When I'm using a single USB
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:Sun Sep 25 19:00:15 CEST 2011
git hash:d7222e7d6fb06ca3e7aa7a1ab07f8e6c6adb1d22
gcc version: i686-linux-gcc (GC
Hello Sakari,
On 09/25/2011 12:08 PM, Sakari Ailus wrote:
> On Fri, Sep 23, 2011 at 12:12:58PM +0200, Sylwester Nawrocki wrote:
>> On 09/23/2011 12:02 AM, Sakari Ailus wrote:
>>> Hi Sylwester,
>>>
>>> I have a few additional comments below, they don't depend on my earlier
>>> ones.
>>
>> Thanks a
I haven't gotten any feedback, and didn't see any comments on the lists
(though I've checked them only occasionally), so I think you're probably
right it fell between the cracks.
Jyrki
25.09.2011 19:13, Carlos Corbacho kirjoitti:
On Monday 22 Aug 2011 20:19:42 Jyrki Kuoppala wrote:
The patc
On Monday 22 Aug 2011 20:19:42 Jyrki Kuoppala wrote:
> The patch fixes frequency selection for some UHF frequencies e.g.
> channel 32 (562 MHz) on the qt1010 tuner. The tuner is used e.g. in the
> MSI Mega Sky dvb-t stick ("MSI Mega Sky 55801 DVB-T USB2.0")
>
> One example of problem reports of th
On Sun, Sep 25, 2011 at 3:33 PM, Patrick Dickey wrote:
> Hello there,
>
> I tried to follow the steps for cloning both the "media_tree.git" and
> "media_build.git" repositories, and received errors for both. The
> media_tree repository failed on the first line
>
>> git clone
>> git://git.kernel.
On Sun, Sep 25, 2011 at 8:33 AM, Patrick Dickey wrote:
> Hello there,
>
> I tried to follow the steps for cloning both the "media_tree.git" and
> "media_build.git" repositories, and received errors for both. The
> media_tree repository failed on the first line
>
>> git clone
>> git://git.kernel.
Mauro,
This patch just removes the prototypes for the two functions that I've already
deleted in my previous patches.
Cheers,
Chris
Signed-off-by: Chris Rankin
--- linux/drivers/media/video/em28xx/em28xx.h.orig 2011-09-25 14:46:02.0 +0100
+++ linux/drivers/media/video/em28xx/em28xx.h
On 25/09/11 14:00, Mauro Carvalho Chehab wrote:
Hmm... This would probably work better (not tested). Could you please test it
on your hardware?
Hmm, I don't understand this. The deadlock isn't about taking
em28xx_devlist_mutex, but happens because em28xx_dvb_init() tries to retake
dev->lock w
On 25/09/11 13:49, Mauro Carvalho Chehab wrote:
Ok, I've applied it, but it doesn't sound a good idea to me to do:
+ mutex_unlock(&dev->lock);
em28xx_init_extension(dev);
+ mutex_lock(&dev->lock);
I'll later test it with some hardware and see how well this behaves
in practic
Em 24-09-2011 17:54, Chris Rankin escreveu:
> This fixes the deadlock that occurs with either multiple PCTV 290e adapters
> or when a single PCTV 290e adapter is replugged.
>
> For DVB devices, the device lock must now *not* be held when adding/removing
> either a device or an extension to the r
Em 24-09-2011 17:54, Chris Rankin escreveu:
> This fixes the deadlock that occurs with either multiple PCTV 290e adapters
> or when a single PCTV 290e adapter is replugged.
>
> For DVB devices, the device lock must now *not* be held when adding/removing
> either a device or an extension to the r
Em 24-09-2011 15:29, Manu Abraham escreveu:
> On Sat, Sep 24, 2011 at 6:04 PM, Mauro Carvalho Chehab
> wrote:
>> Everything at patchwork were reviewed by me, and I've applied all patches
>> that I didn't notice any review by the drivers maintainers.
>>
>> Driver maintainers:
>> Please review the r
Hello there,
I tried to follow the steps for cloning both the "media_tree.git" and
"media_build.git" repositories, and received errors for both. The
media_tree repository failed on the first line
> git clone
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git v4l-dvb
which
On Sat, 2011-09-24 at 18:42 +0200, Lawrence Rust wrote:
> On Sat, 2011-09-24 at 09:39 -0400, Andy Walls wrote:
> > On Sat, 2011-09-24 at 09:16 -0400, Andy Walls wrote:
> > > On Fri, 2011-09-23 at 20:43 -0300, Mauro Carvalho Chehab wrote:
> > > > Em 19-09-2011 08:12, Lawrence Rust escreveu:
> > > >
Em 24-09-2011 15:11, Manu Abraham escreveu:
> On Sat, Sep 24, 2011 at 6:04 PM, Mauro Carvalho Chehab
> wrote:
>> Everything at patchwork were reviewed by me, and I've applied all patches
>> that I didn't notice any review by the drivers maintainers.
>>
>> Driver maintainers:
>> Please review the r
Em 25-09-2011 07:25, Doron Cohen escreveu:
> On Fri, 2011-09-23 at 17:20 -0300, Mauro Carvalho Chehab wrote:
>> Em 20-09-2011 07:30, Doron Cohen escreveu:
>>> Hi,
>>> It took a long time to merge all the changes in kernel.org with Siano
>>> sources which were updated in a different repository for t
On Wed, Sep 21, 2011 at 11:06:41AM +0200, Laurent Pinchart wrote:
> Hi Deepthy,
Hi,
(Dropped most of people and lists from cc. I don't think Andrew Morton, for
example, has immediate interest towards this topic. Feel free to prome me
wrong.)
> On Wednesday 21 September 2011 07:32:44 Ravi, Deepth
On Fri, 2011-09-23 at 17:20 -0300, Mauro Carvalho Chehab wrote:
> Em 20-09-2011 07:30, Doron Cohen escreveu:
> > Hi,
> > It took a long time to merge all the changes in kernel.org with Siano
> > sources which were updated in a different repository for the last couple
> > of years.
> > I have made a
On Fri, Sep 23, 2011 at 12:12:58PM +0200, Sylwester Nawrocki wrote:
> Hi Sakari,
Hi Sylwester,
> On 09/23/2011 12:02 AM, Sakari Ailus wrote:
> > Hi Sylwester,
> >
> > I have a few additional comments below, they don't depend on my earlier
> > ones.
>
> Thanks a lot for your follow up review!
>
Hello Friend', I have a transaction which is of mutual benefits and I would
like to share with you. if interested for more information please get back to
me via email.Thank you.Yours sincerely,Mr.Tong Hao.
38 matches
Mail list logo
