On Thu, Jan 8, 2015 at 8:35 PM, Raimonds Cicans wrote:
> On 08.01.2015 10:34, Clemens Ladisch wrote:
>>
>> Raimonds Cicans wrote:
>>>
>>> https://github.com/ljalves/linux_media/issues/66
>>
>> If the TBS driver works, why don't you use it?
>
> 1) driver is not stable in 24x7 setups
>
> 2) driver u
On Mon, Jul 1, 2013 at 11:12 PM, Mauro Carvalho Chehab
wrote:
> Em Mon, 1 Jul 2013 21:17:58 +0530
> Manu Abraham escreveu:
>
>> On Mon, Jul 1, 2013 at 9:05 PM, Mauro Carvalho Chehab
>> wrote:
>> > Em Mon, 1 Jul 2013 16:37:58 +0530
>> > Manu Abraham esc
On Mon, Jul 1, 2013 at 9:05 PM, Mauro Carvalho Chehab
wrote:
> Em Mon, 1 Jul 2013 16:37:58 +0530
> Manu Abraham escreveu:
>
>> Mauro,
>>
>> On Mon, Jul 1, 2013 at 4:28 PM, Mauro Carvalho Chehab
>> wrote:
>> > Hi Linus,
>> >
>> > Please
Mauro,
On Mon, Jul 1, 2013 at 4:28 PM, Mauro Carvalho Chehab
wrote:
> Hi Linus,
>
> Please pull from:
> git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
> v4l_for_linus
>
> For the media patches for Kernel v3.11.
>
>
> Zoran Turalija (2):
> [media] stb0899: allow minimu
Hi,
On Wed, Feb 20, 2013 at 12:28 AM, Alexey Khoroshilov
wrote:
> goto err and goto err_gateoff before mutex_lock(&state->internal->demod_lock)
> lead to unlock of unheld mutex in stv090x_sleep().
Out of curiosity, what happens when you try to unlock an unlocked mutex ?
Regards,
Manu
--
To unsu
On Thu, Oct 11, 2012 at 1:53 PM, Oliver Endriss wrote:
> Mauro Carvalho Chehab wrote:
>> Em Tue, 09 Oct 2012 14:30:24 +0100
>> David Howells escreveu:
>>
>> > Can you merge the following branch into the media tree please.
>> >
>> > This is to complete part of the Userspace API (UAPI) disintegrat
Jean Delvare wrote:
> BTW, as a rule of thumb, I am ignoring patches that are sent to the
> LKML in addition to the i2c list.
Why ? The statement would have made sense if the i2c list was not CC 'd,
but stating that if LK is CC 'd additionally sounds ...
-
To unsubscribe from this list: send
Marcel Siegert wrote:
> Manu Abraham schrieb:
>> Mauro Carvalho Chehab wrote:
>>> Em Qua, 2007-10-10 Ã s 11:59 -0400, Alan Cox escreveu:
>>>> On Wed, Oct 10, 2007 at 12:35:41PM -0300, Mauro Carvalho Chehab wrote:
>>>>> Em Qua, 2007-10-10 Ã s 00:18 -
Mauro Carvalho Chehab wrote:
> Em Qua, 2007-10-10 Ã s 11:59 -0400, Alan Cox escreveu:
>> On Wed, Oct 10, 2007 at 12:35:41PM -0300, Mauro Carvalho Chehab wrote:
>>> Em Qua, 2007-10-10 Ã s 00:18 -0400, Michael Krufky escreveu:
Is this illegal as per kernel codingstyle?
>>> Yes, it is. CodingStyl
Hello Markus,
Markus Rechberger wrote:
> The main discussion in this thread was about drivers in userspace
> are bad because the API will allow binary drivers. The guy
> who works for Hauppauge (again I also have good contacts
> at Hauppauge Europe) writes it's bad - for no technical reason.
AF
Aidan Thornton wrote:
>
> I think this will require a rethink of either how the em2880-dvb
> driver works or how frontend drivers work. The current API expects
> users to initialise their frontend and then bind a tuner to it.
> em2880-dvb is a sort of subdriver that attaches to the main driver,
>
Joerg Roedel wrote:
>>> Common new IOMMUs have only very few in common with the AGP GART. In
>>> fact, with current modern IOMMU hardware it will be possible to
>>> implement secure userspace device drivers that are even able to do DMA.
>>> This is not possible with the GART.
>>>
Though you g
Joerg Roedel wrote:
> On Fri, Sep 14, 2007 at 11:57:59AM +0400, Manu Abraham wrote:
>>>>> What do you think about IOMMU?
>>>>>
>>>>>
>>>> Just because AMD or INTEL want to invent some whizzy new technology it
>>>> doesn'
>>> What do you think about IOMMU?
>>>
>>>
>> Just because AMD or INTEL want to invent some whizzy new technology it
>> doesn't say anything about the TV card development and retail business.
>> Intel and AMD have teams of Linux engineers helping operating system
>> developers bring their ideas and
Markus Rechberger wrote:
> On 9/13/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
>> Markus Rechberger wrote:
>>> On 9/13/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
>>>>> It's only a step in development, I do not intend to keep the kernel
>>
Markus Rechberger wrote:
> On 9/13/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
>>> It's only a step in development, I do not intend to keep the kernel
>>> stub in the end, but I do intend to keep and use the userspace drivers
>>> with i2c-dev in the long ru
> It's only a step in development, I do not intend to keep the kernel
> stub in the end, but I do intend to keep and use the userspace drivers
> with i2c-dev in the long run, this requires a v4l/dvb library at the front
> of everything.
Well, this was what adq and myself did with libdvbapi and mt
linux-os (Dick Johnson) wrote:
> http://en.wikipedia.org/wiki/Solid_state_drive
>
> This is exactly what I proposed on this list a long
> time ago. It is now a reality.
It's been around for a couple of years ;-)
http://forum.pcvsconsole.com/viewthread.php?tid=15802
http://www.anandtech.com/tra
ts) {
> /* We are about to process a new TS cell. */
>
> #ifdef ULE_DEBUG
> if (ule_where >= &ule_hist[100*TS_SZ]) ule_where =
> ule_hist;
> memcpy( ule_where, ts, TS_SZ );
> if (ule_dump
d(__powerpc__) /* big-endian */
> -extern __inline__ void io_st_le32(volatile unsigned __iomem *addr, unsigned
> val)
> +static inline void io_st_le32(volatile unsigned __iomem *addr, unsigned val)
> {
> __asm__ __volatile__("stwbrx %1,0,%2":"=m"(*addr):"r
On 8/14/07, Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote:
>
> >
> > > F: drivers/media/*
> >
> >
> > This is NOT OK !
>
> This IS ok. You just need to read the definition of the 'F' tag:
>
> F: Files and directories with wildcard patterns.
>A trailing slash includes all files and subdirector
On 8/14/07, Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote:
>
> Em Seg, 2007-08-13 às 19:44 -0700, Joe Perches escreveu:
> > On Mon, 2007-08-13 at 22:08 -0400, Michael Krufky wrote:
> > > drivers/media/video -- v4l
> > > drivers/media/radio -- v4l
> > >
> > > drivers/media/dvb -- dvb
> >
> > V
On 8/14/07, Joe Perches <[EMAIL PROTECTED]> wrote:
> On Mon, 2007-08-13 at 23:22 +0400, Manu Abraham wrote:
> > > F: drivers/media/
> > This means everything under media is maintained under V4L. Incorrect
>
> What would you like?
>
media/video
and
media/rad
On 8/13/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
>
> On Mon, 2007-08-13 at 19:33 +0200, Mariusz Kozlowski wrote:
> > Hello,
> >
> > I don't recall discusion about this so here are my 3 cents:
> >
> > I like the idea.
>
> I don't actually. It shows a central MAINTAINERS file is th
On 8/13/07, Joe Perches <[EMAIL PROTECTED]> wrote:
> On Mon, 2007-08-13 at 15:15 -0300, Mauro Carvalho Chehab wrote:
> > There are more include files to be added, for the older V4L APIs:
> > F: include/linux/video_decoder.h
> > F: include/linux/videodev.h
>
> VIDEO FOR LINUX
> P: Mauro Carvalh
On 8/8/07, Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Wed, Aug 08, 2007 at 03:09:14PM +0400, Manu Abraham wrote:
> > On 08 Aug 2007 13:55:28 +0200, Andi Kleen <[EMAIL PROTECTED]> wrote:
> > > Andrew Morton <[EMAIL PROTECTED]> writes:
> > > >
&
On 08 Aug 2007 13:55:28 +0200, Andi Kleen <[EMAIL PROTECTED]> wrote:
> Andrew Morton <[EMAIL PROTECTED]> writes:
> >
> > I'd be surprised if there was significant overhead - the maximum frequency
> > at which msleep() can be called is 1000Hz. We'd need an awful lot of
> > overhead for that to caus
Hi Arjan,
On 8/6/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> On Mon, 2007-08-06 at 12:03 +0200, Roman Zippel wrote:
> > Hi,
> >
> > On Sun, 5 Aug 2007, Arjan van de Ven wrote:
> >
> > > > There's no problem to provide a high resolution sleep, but there is also
> > > > no reason to mess with
On 8/6/07, Roman Zippel <[EMAIL PROTECTED]> wrote:
> Hi,
>
> On Sun, 5 Aug 2007, Arjan van de Ven wrote:
>
> > > There's no problem to provide a high resolution sleep, but there is also
> > > no reason to mess with msleep, don't fix what ain't broken...
> >
> > John Corbet provided the patch becaus
On 8/4/07, Dave Dillow <[EMAIL PROTECTED]> wrote:
> On Fri, 2007-08-03 at 09:04 +0400, Manu Abraham wrote:
> > On 7/31/07, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> >
> > > TODO list currently includes following main items:
> > > * redundancy
On 7/31/07, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> TODO list currently includes following main items:
> * redundancy algorithm (drop me a request of your own, but it is highly
> unlikley that Reed-Solomon based will ever be used - it is too slow
> for distributed RAID, I
Hi Steve,
On 8/1/07, Steven Toth <[EMAIL PROTECTED]> wrote:
> Hi manu,
>
> Hauppauge deal with NXP on a daily basis. We have a number of 716x
> products either in the market or coming to market and we can add some
> leverage.
>
> I can push this through our FAE and account manager. Who's your cont
Hi All,
After a bit of talks with NXP, they stated that if shown enough of a
user base (future business forecast) for the SAA7160 / SAA7162 PCIe
chipset, they would take into consideration, an investment into
support, such that the chips can be better supported.
ie, i need to provide them informa
> return -ENODEV;
>
> if ((file->f_flags & O_ACCMODE) == O_RDONLY &&
> (_IOC_DIR(cmd) != _IOC_READ || cmd == FE_GET_EVENT ||
> cmd == FE_DISEQC_RECV_SLAVE_REPLY))
>
> -
Acked-by: Manu Abraham <[EMAIL PROTE
On 7/21/07, Nelson, Shannon <[EMAIL PROTECTED]> wrote:
Manu Abraham [mailto:[EMAIL PROTECTED]
>Sorry for being not clear. What i was asking is thus:
>
>A device that has legacy interrupts and MSI-X. I was thinking that if
>MSI-X failed one should fall back to MSI mode (singl
On 7/21/07, Roland Dreier <[EMAIL PROTECTED]> wrote:
> In a case where you have a device that which supports MSI-X (multiple
> interrupts) but the device in default is in MSI mode, ie some
> configuration change is needed on the device. In such a case, how
> would one handle between MSI-X and
On 7/21/07, Roland Dreier <[EMAIL PROTECTED]> wrote:
> This driver supports some chipsets that do MSI, and some that do MSI-X,
> but none that can do both.
Thanks, that's the simple answer I was hoping for. Obviously if some
chipsets only do MSI then you need the MSI code in addition to the
M
Hi,
When a device is in D3 state, is it possible to read from the PCI
config space header ? Or does a D3 state imply that the whole PC
itself is in standby ?
I am trying to relate whether a device that i have, a new device that
i am working upon, starts up in D3 state. whether that could be the
On 7/11/07, Nobin Mathew <[EMAIL PROTECTED]> wrote:
See this in the documentation
The returned virtual address is a current CPU mapping for the memory
address given. It is only valid to use this function on addresses that
have a kernel mapping
This function does not handle bus mappings for DMA
ysical memory to virtual
http://mirror.linux.org.au/linux.conf.au/2005/cdrom-beta-1/linux-mandocs-2.6.12.6/phys_to_virt.html
Nobin
On 7/11/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
> On 7/10/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >
> > Thanks for the quick
On 7/10/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Thanks for the quick reply. But I was wondering as to why I would have to map
the physical address to the virtual address when I know that the string is
permanently in the physical memory because its loaded into flash. Is there a way
to di
Bernd Petrovitsch wrote:
> On Wed, 2007-06-20 at 18:14 -0300, Tomas Neme wrote:
> []
>> Why, if you let user-compiled kernels to run in a TiVo, it might be
>> modified so the TiVo can be used to pirate-copy protected content,
>
> Or it might be modified to fix a bug - either a technical one or
[EMAIL PROTECTED] wrote:
> what sort of signal can the network controller send that couldn't be
> forged by the OS?
>
> how would you do this where the device is a receiver on the netwoek
> (such as a satellite receiver)
just for the question on the HOWTO (not on anything else)
You can easily h
Lennart Sorensen wrote:
> On Tue, Jun 19, 2007 at 07:28:22PM +0400, Manu Abraham wrote:
>> Well, it is not Tivo alone -- look at http://aminocom.com/ for an
>> example. If you want the kernel sources pay USD 50k and we will provide
>> the kernel sources, was their attitude.
&g
Alan Cox wrote:
>> Well, it is not Tivo alone -- look at http://aminocom.com/ for an
>> example. If you want the kernel sources pay USD 50k and we will provide
>> the kernel sources, was their attitude.
>
> GPLv2 deals with that case, and they can (and should) be sued for it
> [except that US copy
Lennart Sorensen wrote:
> Well much as I don't like what Tivo did with only allowing signed
> kernels to run, I don't see anything in the above that says they can't
Well, it is not Tivo alone -- look at http://aminocom.com/ for an
example. If you want the kernel sources pay USD 50k and we will pr
Johannes Stezenbach wrote:
> On Tue, Jun 19, 2007, Manu Abraham wrote:
>> Johannes Stezenbach wrote:
>>
>>> I argue that if you keep the free loaders out, you miss
>>> the chance to communicate with and educate them.
>>> Communication across borders does
Johannes Stezenbach wrote:
> I argue that if you keep the free loaders out, you miss
> the chance to communicate with and educate them.
> Communication across borders doesn't work well, and you create
> a border between the morally "good" and the "bad".
>
> Of course you can't expect that every f
Hi,
Sorry for my late reply.
Greg KH wrote:
>>> - your driver will not work on any pci-hotplug type system (that
>>> includes expresscard and pccard and lots of high-end servers.
>> This doesn't matter
>
> Are you sure? PCI Hotplug is showing up in more places that people
> realize...
Roland Dreier wrote:
> > > At least on my device (PCI ID 1131:7162) there is no MSI-X capability,
> > > so that's not an option for you. The current Linux implementation
> > > does not support more than one MSI interrupt, so you just get one
> > > interrupt with pci_enable_msi().
> >
> > Th
Roland Dreier wrote:
> > >> Another question would be if the device supports multiple messages, MSIX
> > >> should be used ?
> > >
> > > Yes. Assuming the device supports multiple MSI-X messages.
>
> At least on my device (PCI ID 1131:7162) there is no MSI-X capability,
> so that's not an opt
Roland Dreier wrote:
> > >> Another question would be if the device supports multiple messages, MSIX
> > >> should be used ?
> > >
> > > Yes. Assuming the device supports multiple MSI-X messages.
>
> At least on my device (PCI ID 1131:7162) there is no MSI-X capability,
> so that's not an opt
David Miller wrote:
> From: "H. Peter Anvin" <[EMAIL PROTECTED]>
> Date: Sat, 26 May 2007 19:34:26 -0700
>
>> There are systems which only get a single bit indication that an MSI has
>> happened.
>>
>> Presumably we need something like IRQF_MSI which can be set as
>> appropriate depending on the a
Grant Grundler wrote:
> On Sun, May 27, 2007 at 05:01:02AM +0400, Manu Abraham wrote:
>> David Miller wrote:
>>> True, on sparc64 PCI-E controllers, for example, the MSI vector is
>>> received by the PCI-E host controller, and the host controller turns
>>> thi
David Miller wrote:
> From: Grant Grundler <[EMAIL PROTECTED]>
> Date: Sat, 26 May 2007 18:16:31 -0600
>
>> Are they really? The device is generating the transaction on the bus.
>> The PCI host controller (in general) will be routing that transaction
>> to wherever the "dest addr" of the MSI lives
David Miller wrote:
> From: Manu Abraham <[EMAIL PROTECTED]>
> Date: Sat, 26 May 2007 19:03:12 +0400
>
>> i presume then i shouldn't be using IRQF_SHARED, if using MSI.
>
> That's actually a really good question.
>
> It is likely architecture dependan
Grant Grundler wrote:
> On Sat, May 26, 2007 at 07:03:12PM +0400, Manu Abraham wrote:
>> Roland Dreier wrote:
>>> > I am now wondering whether the usage of MSI would help in this case and
>>> > that i should be using enable_msi before request_irq ?
>>>
&
Roland Dreier wrote:
> > I am now wondering whether the usage of MSI would help in this case and
> > that i should be using enable_msi before request_irq ?
>
> MSI interrupts are never shared. So if pci_enable_msi() succeeds, you
> can be sure that the interrupts you get with that IRQ number ar
Roland Dreier wrote:
> Why does the device come up in a state where it generates a stream of
> interrupts as soon as you enable the PCI device? That's somewhat
> unusual behavior, although certainly not unheard of.
>
In fact the device wasn't generating a stream of interrupts when loaded
(i gue
Roland Dreier wrote:
> > It looks so, from the logs. The only problem is i can't disable the
> > interrupts, if i write "0" to 0x500, the interrupt/enable register, it
> > gives me a solid freeze. If i read from the handler, commenting out the
> > disable interrupts in init, that read also give
Roland Dreier wrote:
> > If i uncomment the saa716x_read or write, what i get is a solid freeze
> > on module load. If i leave it commented out, the module loads fine.
>
> That sounds like a typical bug during driver development... you're
> probably wedging the hardware by doing the wrong access
Roland Dreier wrote:
>>> Uncompressing Linux .. Ok, booting the kernel.
>>> BIOS bug, no explicit IRQ entries, using default mptable. (tell your hw
>>> vendor)
>>> PCI: Failed to allocate mem resource #6:[EMAIL PROTECTED] for :01:00.0
>
> This message is about device 01:00.0 as it says (your
Hi,
Do the PCI Express chipsets also use the same PCI API ? The device
specifications are thus for the device that i am looking at:
PCI Express interface
* Compliant to PCI Express Base Specification 1.0a
* The PCI Express circuit supports isochronous data traffic intended
for uninterru
Greg KH wrote:
> On Tue, May 15, 2007 at 05:15:28PM +0400, Manu Abraham wrote:
>> Manu Abraham wrote:
>>> Hi,
>>>
>>> I do have a device that's a multifunction device. Eventhough a MFD, it
>>> just has one Interrupt which is shared by by a Conf
Al Viro wrote:
> Signed-off-by: Al Viro <[EMAIL PROTECTED]>
> ---
> drivers/media/video/em28xx/Kconfig |2 +-
> drivers/media/video/ivtv/Kconfig |2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/video/em28xx/Kconfig
> b/drivers/media/video/em28xx/
Manu Abraham wrote:
> Hi,
>
> I do have a device that's a multifunction device. Eventhough a MFD, it
> just has one Interrupt which is shared by by a Configuration space for
> each function. ie, INTA is shared between them functions.
>
> In such a case, i am wondering,
Hi,
I do have a device that's a multifunction device. Eventhough a MFD, it
just has one Interrupt which is shared by by a Configuration space for
each function. ie, INTA is shared between them functions.
In such a case, i am wondering, (since pci_probe returns a pointer to
one PCI function alone
Trent Piepho wrote:
> This is not correct. The dvb_attach() system has no assumption that it will
> be used for a front-end device. There are already users which are not
> front-ends, such as tuners or lnb supply control chips,
SEC (aka Satellite Equipment Control) is a part of the frontend.
Michael Krufky wrote:
> Manu Abraham wrote:
>> Mauro Carvalho Chehab wrote:
>>> Hi Manu,
>>>
>>>> From my side, quite some time has been put forward to write that mail.
>>>> Inspite of that if you feel that you do have to go your own way, then
>
Mauro Carvalho Chehab wrote:
> Hi Manu,
>
>> From my side, quite some time has been put forward to write that mail.
>> Inspite of that if you feel that you do have to go your own way, then
>> it is completely upto you. I would say: do as you feel in such a case.
>
> The point is that those issues
Hello Mauro,
Mauro Carvalho Chehab wrote:
> Hi Manu,
>
> Em Qui, 2007-05-03 às 23:03 +0400, Manu Abraham escreveu:
>> Mauro Carvalho Chehab wrote:
>>> Enough. Let's stop arguing non technical issues.
>>>
>>> If either one of you have any technica
ead, what i wrote (and that was the only mail from
my side):
There is a saying: "He who lives by the sword, dies by the sword."
Original Message
Subject: Re: [linux-dvb] Re: Critical points about kernel 2.6.21and
pseudo-authorities
Date: Tue, 01 May 2007 04:19:
Markus Rechberger wrote:
> On 5/3/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
>> Mauro Carvalho Chehab wrote:
>> > Enough. Let's stop arguing non technical issues.
>> >
>> > If either one of you have any technical argue against the Trent'
mebody else's driver
unless it falls within your own maintainership
> Mauro.
>
> Em Qui, 2007-05-03 às 19:19 +0200, Markus Rechberger escreveu:
>> On 5/3/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
>>> Markus Rechberger wrote:
>>>
>>>> M
Michael Krufky wrote:
> Manu Abraham wrote:
>> Uwe Bugla wrote:
>>
>>> If you download the thing as tar.bz2 you get a zero file down.
>>>
>> I think could be a bug in hgweb probably.
> [snip]
>> Let me see why hgweb gives a zero length archiv
Markus Rechberger wrote:
> Manu,
>
> to me it looks like your attitude is not acceptable here, I sent
> several mails already which you just use to ignore.
You very well know the reason why i am ignoring your mails. You just
tend to flame people for nothing. I tend to ignore the flamers.
> If
Uwe Bugla wrote:
> Original-Nachricht
> Datum: Thu, 03 May 2007 19:48:50 +0400
> Von: Manu Abraham <[EMAIL PROTECTED]>
> An: Uwe Bugla <[EMAIL PROTECTED]>
> CC: [EMAIL PROTECTED], linux-kernel@vger.kernel.org, [EMAIL PROTECTED],
> [EMAIL PROTECT
Uwe Bugla wrote:
> Hi Manu,
>
> But it would be an acceptable compromise FOR NOW, wouldn't it?
The reason is i do not wish to make changes to it, till i can fix it. It
is indeed hard to fix things that support a lot of devices, with
different issues. There are enough of issues in there.
You ca
Mauro Carvalho Chehab wrote:
> Em Qua, 2007-05-02 às 04:10 -0700, Trent Piepho escreveu:
>> On Tue, 1 May 2007, Mauro Carvalho Chehab wrote:
>
>>> However, when dst is selected, I got those errors:
>> When I made this patch I was basing it off a patch I made around 9 months
>> ago. I thought sinc
Uwe Bugla wrote:
> On the technical layer I noticed that I heard some Pinnacle relais click
> during testing, but there were some i2c_bus symbols missing during
> compilation. So I guess those missing symbols are responsible for getting
> neither picture nor sound.
Can you send your compile wa
Uwe Bugla wrote:
> Original-Nachricht
> Datum: Wed, 02 May 2007 17:30:32 +0400
> Von: Manu Abraham <[EMAIL PROTECTED]>
> An: Trent Piepho <[EMAIL PROTECTED]>
> CC: Simon Arlott <[EMAIL PROTECTED]>, Linux Kernel Mailing list
> , [EMAI
Uwe Bugla wrote:
> Original-Nachricht
> Datum: Wed, 02 May 2007 17:30:32 +0400
> Von: Manu Abraham <[EMAIL PROTECTED]>
> An: Trent Piepho <[EMAIL PROTECTED]>
> CC: Simon Arlott <[EMAIL PROTECTED]>, Linux Kernel Mailing list
> , [EMAI
Trent Piepho wrote:
> On Tue, 1 May 2007, Simon Arlott wrote:
>> On 30/04/07 22:17, Markus Rechberger wrote:
>>> From my side I do not see any problem with that patch, if someone else
>>> has a problem with it please state out the reason.
>> I have no problem with the patch since it has nothing to
Uwe Bugla wrote:
> 1. You utmost personally are responsible for 4 ununsable kernels, as far as
> bt8xx cards are concerned: 2.6.13, 2.6.14, 2.6.15, 2.6.16!
> 2. You did not even want to imply to resolve that issue by incarnating that
> "community and synergy principle" that linux community needs
Trent Piepho wrote:
> The issue with dst is just a minor missing feature to fully support the dvb
> helper module customization system. So nobody needs to worry about this
> anymore, the last two patches in this repository will fix it correctly.
With regards to the dst, i have explained earlier
Pavel Machek wrote:
> STD needs to snapshot system, and then it needs devices to be
> suspended so that snapshot is consistent.
One question though, there are devices that can be suspended (broken
suspend) and restore in such a case wouldn't work at all. The only
possible way would be then to re
hermann pitton wrote:
> Am Freitag, den 20.04.2007, 03:19 +0400 schrieb Manu Abraham:
>> hermann pitton wrote:
>>> Am Freitag, den 20.04.2007, 02:51 +0400 schrieb Manu Abraham:
>>>> Markus Rechberger wrote:
>>>>> On 4/20/07, Manu Abraham <[EMAI
hermann pitton wrote:
> Am Freitag, den 20.04.2007, 02:51 +0400 schrieb Manu Abraham:
>> Markus Rechberger wrote:
>>> On 4/20/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
>>>> hermann pitton wrote:
>>>>> Am Freitag, den 20.04.2007, 00:55 +0400
Markus Rechberger wrote:
> On 4/20/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
>> hermann pitton wrote:
>> > Am Freitag, den 20.04.2007, 00:55 +0400 schrieb Manu Abraham:
>> >> Mauro Carvalho Chehab wrote:
>> >>> Em Qui, 2007-04-19 às 16:41 -0
hermann pitton wrote:
> Am Freitag, den 20.04.2007, 00:55 +0400 schrieb Manu Abraham:
>> Mauro Carvalho Chehab wrote:
>>> Em Qui, 2007-04-19 às 16:41 -0400, Michael Krufky escreveu:
>>>> Marco Gittler wrote:
>>>>> this patch has applied the hints fr
Michael Krufky wrote:
> Mauro,
>
> I've been out of town for the past few days... I just got home and saw this:
>
>
> Mauro Carvalho Chehab wrote:
>>- Fix 1/3 for bug 7819: fixed frontend hotplug issue
>>- Fix 2/3 for bug 7819: demux and dvr
>>- Fix 3/3 for bug 7819: fixed hotpluggin
On 3/25/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> There are cases where we need an API update since newer systems do show up.
> In such a case, the only way is to provide backward compatibility
> while adding in newer stuff.
>
> Currently we use the version major/minor for the userspace
On 3/23/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
On Fri, 2007-03-23 at 16:47 +0100, Marcel Siegert wrote:
> On Friday 23 March 2007, Robert P. J. Day wrote:
> >
> > Delete the unreferenced header file include/linux/dvb/version.h.
> >
> > Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
On 2/15/07, linux-os (Dick Johnson) <[EMAIL PROTECTED]> wrote:
I don't think of GPL as a religion, only as an experiment
that has run amok.
The point of GPL, is that even if the vendor stopped supporting, you
could fix the device driver by yourself. This is really happening,
vendors do sell h
On 2/15/07, Mws <[EMAIL PROTECTED]> wrote:
hi vj,
On Thursday 15 February 2007, v j wrote:
> This is in reference to the following thread:
>
> http://lkml.org/lkml/2006/12/14/63
>
> I am not sure if this is ever addressed in LKML, but linux is _very_
> popular in the embedded space. We (an embed
On 2/2/07, Erik Mouw <[EMAIL PROTECTED]> wrote:
On Fri, Feb 02, 2007 at 01:04:53AM +0100, Lapo TIN wrote:
> I need to capture at 25 frame per second from each channel...
> So 25 x 8 total frames per second on the pci.
Each PAL frame takes about 800k, so that makes 20MB/s per channel. With
8 chan
On 2/13/07, Trent Piepho <[EMAIL PROTECTED]> wrote:
On Tue, 13 Feb 2007, Jakub Jelinek wrote:
> Wouldn't it be better to kmalloc both struct dvb_device and
> struct file_operations together instead of doing 2 separate allocations?
> struct dvd_device_plus_fops
> {
> struct dvb_device dev;
> s
reetings,
> Arjan van de Ven
hi arjan,
thanks for pointing out this issue.
attached find a patch that fixes the problem.
@mauro - please pull changeset a7ac92d208fe
dvbdev: fix illegal re-usage of fileoperations struct
from http://www.linuxtv.org/hg/~mws/v4l-dvb-fixtree
Ack&#
On 2/13/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
Hi,
while working on the last pieces of the file_ops constantification, DVB
is the small village in France that is holding the Romans at bay... but
I think I found the final flaw in it now:
*pdvbdev = dvbdev = kmalloc(sizeof(struct
On 2/12/07, Nigel Cunningham <[EMAIL PROTECTED]> wrote:
Hi.
On Mon, 2007-02-12 at 02:57 +0400, Manu Abraham wrote:
> On 2/12/07, Nigel Cunningham <[EMAIL PROTECTED]> wrote:
>
> > Neither am I. I'm just asking that new drivers have power management as
> >
1 - 100 of 129 matches
Mail list logo
