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
On Thu, Jan 8, 2015 at 8:35 PM, Raimonds Cicans r...@apollo.lv 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 use
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
>> > M
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
Mauro,
On Mon, Jul 1, 2013 at 4:28 PM, Mauro Carvalho Chehab
mche...@redhat.com 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:
On Mon, Jul 1, 2013 at 9:05 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Em Mon, 1 Jul 2013 16:37:58 +0530
Manu Abraham abraham.m...@gmail.com escreveu:
Mauro,
On Mon, Jul 1, 2013 at 4:28 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Hi Linus,
Please pull from:
git
On Mon, Jul 1, 2013 at 11:12 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Em Mon, 1 Jul 2013 21:17:58 +0530
Manu Abraham abraham.m...@gmail.com escreveu:
On Mon, Jul 1, 2013 at 9:05 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Em Mon, 1 Jul 2013 16:37:58 +0530
Manu Abraham
Hi,
On Wed, Feb 20, 2013 at 12:28 AM, Alexey Khoroshilov
wrote:
> goto err and goto err_gateoff before mutex_lock(>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
Hi,
On Wed, Feb 20, 2013 at 12:28 AM, Alexey Khoroshilov
khoroshi...@ispras.ru 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 ?
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)
On Thu, Oct 11, 2012 at 1:53 PM, Oliver Endriss o.endr...@gmx.de wrote:
Mauro Carvalho Chehab mche...@infradead.org wrote:
Em Tue, 09 Oct 2012 14:30:24 +0100
David Howells dhowe...@redhat.com escreveu:
Can you merge the following branch into the media tree please.
This is to complete
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
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-1
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.
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. CodingStyle states:
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 -0400, Michael Krufky escreveu:
Is this illegal as per kernel
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.
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.
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
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't sa
>>> 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
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 technologies to
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't say anything about the TV card development and retail business.
Intel and AMD have teams of Linux
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 get a physical to
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,
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
> 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
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 mti,
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 run, this requires a v4l/dvb library at the front
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
stub in the end, but I do intend to keep and use the userspace drivers
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
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
/* We are about to process a new TS cell. */
>
> #ifdef ULE_DEBUG
> if (ule_where >= _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
__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(val),
r(addr));
Signed-off-by: Manu Abraham [EMAIL PROTECTED]
-
To unsubscribe from this list
( ule_where, ts, TS_SZ );
if (ule_dump) {
hexdump( ule_where, TS_SZ );
ule_dump = 0;
Signed-off-by: Manu Abraham [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
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
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
> >
> >
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
VIDEO FOR LINUX
P:
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 subdirectory files.
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
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
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 Carvalho Chehab
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 the wrong
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/radio
*only* belong under V4L
Manu
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
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 cause problems,
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:
I'd be surprised if there was significant overhead - the maximum
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
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 msleep, don't fix
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
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 because he had a
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:
> > > * redund
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 algorithm (drop me a request of your own, but it is
highly
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,
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
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 contact
at
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
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 PROTECTED]
||
cmd == FE_DISEQC_RECV_SLAVE_REPLY))
-
Acked-by: Manu Abraham [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read
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
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
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
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
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 MSI
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 (single message), that's
what i
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
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
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 reply. But I was wondering as to why I would
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
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
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
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
[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
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
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.
Hmm, set top boxes
[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 have
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 a
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
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 copyright
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
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
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 free
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 doesn't work well, and you create
a border between
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
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
>
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...
The PCI
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().
> >
> >
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
1 - 100 of 258 matches
Mail list logo
