Michael Krufky wrote:
For the past few months, I've been working on refactoring the analog tuner.ko
module, such that all hardware-specific code can be separated into
dvb_frontend style tuner modules.
This allows for a single module to be used by both the v4l2 tuner interface
via the
Hi Michael,
Em Seg, 2007-08-27 às 10:02 -0300, Mauro Carvalho Chehab escreveu:
I should review the source code later today.
Ok. Almost everything looked fine to my eyes.
I have just one comment, about the changesets that added the
MODULE_DESCRIPTION and MODULE_LICENSE macros, like on this
Mauro Carvalho Chehab wrote:
Hi Michael,
Em Seg, 2007-08-27 às 10:02 -0300, Mauro Carvalho Chehab escreveu:
I should review the source code later today.
Ok. Almost everything looked fine to my eyes.
I have just one comment, about the changesets that added the
MODULE_DESCRIPTION
On Monday 27 August 2007 11:01:21 am Steven Toth wrote:
Johannes Stezenbach wrote:
On Mon, Aug 20, 2007, Manu Abraham wrote:
Michael Krufky wrote:
-- this is a system-wide addition to the
dvb_frontend structure, because we are adding analog tuning
functionality to the dvb_frontend.
Am Dienstag, den 28.08.2007, 16:25 -0400 schrieb Michael Krufky:
Mauro Carvalho Chehab wrote:
Hi Michael,
Em Seg, 2007-08-27 às 10:02 -0300, Mauro Carvalho Chehab escreveu:
I should review the source code later today.
Ok. Almost everything looked fine to my eyes.
I
Michael Krufky wrote:
For the past few months, I've been working on refactoring the analog
tuner.ko module, such that all hardware-specific code can be separated
into dvb_frontend style tuner modules.
This allows for a single module to be used by both the v4l2 tuner
interface via the
You say, there weren't any log messages from tea5767 driver. -- This
is because the tuner_info line was disabled -- I've re-enabled it just
now, and push up the changeset.
Please update your tree and test again -- I believe that the only issue
here is the missing message from the tea5767
Mauro Carvalho Chehab wrote:
You say, there weren't any log messages from tea5767 driver. -- This
is because the tuner_info line was disabled -- I've re-enabled it just
now, and push up the changeset.
Please update your tree and test again -- I believe that the only issue
here is the missing
Steven Toth wrote:
MikeW wrote:
Michael Krufky mkrufky at linuxtv.org writes:
For the past few months, I've been working on refactoring the analog
tuner.ko
module, such that all
I never saw the original RFC posting on the ML. What was the date on
On 8/27/07, Steven Toth [EMAIL PROTECTED] wrote:
Steven Toth wrote:
MikeW wrote:
Michael Krufky mkrufky at linuxtv.org writes:
For the past few months, I've been working on refactoring the analog
tuner.ko
module, such that all
I never saw the original RFC posting on
Markus Rechberger wrote:
On 8/27/07, Steven Toth [EMAIL PROTECTED] wrote:
Steven Toth wrote:
MikeW wrote:
Michael Krufky mkrufky at linuxtv.org writes:
For the past few months, I've been working on refactoring the analog
tuner.ko
Johannes Stezenbach wrote:
On Mon, Aug 20, 2007, Manu Abraham wrote:
Michael Krufky wrote:
-- this is a system-wide addition to the
dvb_frontend structure, because we are adding analog tuning
functionality to the dvb_frontend.
Analog tuning is public to DVB core ? I don't
Mauro Carvalho Chehab wrote:
About the dmesg, I didn't have time to store it. Basically, on the first
compilation, I got two errors, since tuner-simple and tea5767 weren't
selected on Kconfig. I've then selected the option to auto-include the
required i2c drivers. Those two messages
Michael Krufky mkrufky at linuxtv.org writes:
For the past few months, I've been working on refactoring the analog tuner.ko
module, such that all
hardware-specific code can be separated into dvb_frontend style tuner modules.
...snip...
If there are any other questions, comments or
MikeW wrote:
Michael Krufky mkrufky at linuxtv.org writes:
For the past few months, I've been working on refactoring the analog tuner.ko
module, such that all
I never saw the original RFC posting on the ML. What was the date on
this original thread?
- Steve
Steven Toth wrote:
MikeW wrote:
Michael Krufky mkrufky at linuxtv.org writes:
For the past few months, I've been working on refactoring the analog
tuner.ko
module, such that all
I never saw the original RFC posting on the ML. What was the date on
this original thread?
I didn't reviewed yet the tea5767 changes. I expect to do it later this
week (maybe today night).
Thank you -- I appreciate that.
I did just a quick test yesterday. I didn't analyzed the source code
yet. Basically, tea5767 didn't work:
Those are the _normal_ logs from tip:
Linux video
Mauro Carvalho Chehab wrote:
I didn't reviewed yet the tea5767 changes. I expect to do it later this
week (maybe today night).
Thank you -- I appreciate that.
I did just a quick test yesterday. I didn't analyzed the source code
yet. Basically, tea5767 didn't work:
i2c_adapter
On Sat, 18 Aug 2007, Michael Krufky wrote:
For the past few months, I've been working on refactoring the analog
tuner.ko module, such that all hardware-specific code can be separated
into dvb_frontend style tuner modules.
[...]
Acked-by: Mike Isely [EMAIL PROTECTED]
I've studied the
Michael Krufky wrote:
Manu Abraham wrote:
Michael Krufky wrote:
For the past few months, I've been working on refactoring the analog
tuner.ko module, such that all hardware-specific code can be separated into
dvb_frontend style tuner modules.
This allows for a single module to be used
Manu Abraham wrote:
Michael Krufky wrote:
We cannot move struct analog_parameters out of dvb_frontend.h , since
the new set_analog_params method must be a part of the dvb_tuner_ops
structure. This is a very small price to pay, for quite a large gain,
You mean to say it is impossible to do
Hans Verkuil wrote:
At first glance that certainly seems better than adding a void pointer as
a replacement for the set_analog_params function pointer.
Sometimes elegance also matters. Other than that the convention that we
have is (from dvb_frontend.h)
151 void*
Manu Abraham wrote:
You will need to handle the IOCTL calls for analog operations some
place, whatever you remove.
I don't see at any place you are handling the IOCTL's directly in the
drivers. So you will be using callbacks from the place where you
are applying the ioctl's
You are getting
On Monday 20 August 2007 17:22:41 Michael Krufky wrote:
Manu Abraham wrote:
You will need to handle the IOCTL calls for analog operations some
place, whatever you remove.
I don't see at any place you are handling the IOCTL's directly in
the drivers. So you will be using callbacks from
Michael Krufky wrote:
THIS is the root of our disagreement -- The analog tuning functionality
is _not_ private to the device
There was a small typo. Analog operation is private to the DVB frontend
device
-- this is a system-wide addition to the
dvb_frontend structure, because we are
Em Seg, 2007-08-20 às 11:22 -0400, Michael Krufky escreveu:
Manu Abraham wrote:
You will need to handle the IOCTL calls for analog operations some
place, whatever you remove.
I don't see at any place you are handling the IOCTL's directly in the
drivers. So you will be using callbacks
Mauro Carvalho Chehab wrote:
Em Seg, 2007-08-20 às 11:22 -0400, Michael Krufky escreveu:
Manu Abraham wrote:
You will need to handle the IOCTL calls for analog operations some
place, whatever you remove.
I don't see at any place you are handling the IOCTL's directly in the
Meanwhile, I
do not plan on introducing this idea for many months, probably for
2.6.25 or 2.6.26, maybe 2.6.27... so I would rather not discuss this now
-- it is completely irrelevant to the matter at hand.
Agreed.
When I did my testing of tuner-simple and tda8290 modules, I ran into
Mauro Carvalho Chehab wrote:
Using void* priv will just create some troubles, since this will avoid
gcc to do typecast checkings for no gain.
In this specific context what is strict typecast check going to achieve
for you ?
You should probably explicitly state the problem what you face in this
On Mon, Aug 20, 2007, Manu Abraham wrote:
Michael Krufky wrote:
-- this is a system-wide addition to the
dvb_frontend structure, because we are adding analog tuning
functionality to the dvb_frontend.
Analog tuning is public to DVB core ? I don't think so. It would've been
correct, if
Johannes Stezenbach wrote:
On Mon, Aug 20, 2007, Manu Abraham wrote:
Michael Krufky wrote:
-- this is a system-wide addition to the
dvb_frontend structure, because we are adding analog tuning
functionality to the dvb_frontend.
Analog tuning is public to DVB core ? I don't think so. It
On Sunday 19 August 2007 00:25:40 Michael Krufky wrote:
For the past few months, I've been working on refactoring the analog
tuner.ko module, such that all hardware-specific code can be
separated into dvb_frontend style tuner modules.
This allows for a single module to be used by both the
Michael Krufky wrote:
For the past few months, I've been working on refactoring the analog tuner.ko
module, such that all hardware-specific code can be separated into
dvb_frontend style tuner modules.
This allows for a single module to be used by both the v4l2 tuner interface
via the
Manu Abraham wrote:
Michael Krufky wrote:
For the past few months, I've been working on refactoring the analog
tuner.ko module, such that all hardware-specific code can be separated into
dvb_frontend style tuner modules.
This allows for a single module to be used by both the v4l2 tuner
For the past few months, I've been working on refactoring the analog tuner.ko
module, such that all hardware-specific code can be separated into dvb_frontend
style tuner modules.
This allows for a single module to be used by both the v4l2 tuner interface via
the tuner.ko i2c_client driver, and
35 matches
Mail list logo
