Hi, thanks for the patch.
> See updated patch on ml.
This raises two concerns for me:
[1]. Clients must split an I2C transaction of one read into two,
releasing the lock between them.
They might be interrupted (for example) by other read transaction
to another tuner, (or by other, un-related I2C
Hi, thanks for the example patch.
> Here is debug log I tested multibyte i2c writes using zl10353 demod. All
> returned bytes are not same, but it due to write only register bits I
> think.
>
> dvb_usb_gl861 1-13:1.0: 1 | c0 02 00 1e 50 00 01 00 <<< 03
> dvb_usb_gl861 1-13:1.0: 1 | c0 02 00 1e 51
Hi,
> I suspect all whole friio_reset() function is not needed as it has
> worked even I/O has been broken.
It worked because the old driver
(that I rmmod'ed before installing the testing driver)
properly init'ed the device.
If I re-plug it (or reboot), it does not work.
So it is needed.
> Also
> Could you please test the patch and check if the return results are
> now consistent and that it won't break anything?
I have tested the patch and it worked without problems.
Testd-by: Akihiro Tsukada
I could not noticed the bug because
the device was registered without any err
> Does anyone have this hardware? This device must have been dead for about
> a year, ever since commit b30cc07de8a9 was merged.
I have one. (and I wrote the patch).
Since I do not use it regularly and
my app did not use the return value meaningfully,
I have not noticed.
regards,
Akihiro
> Will it be better, if dvb_pll_devcount is decremented in dvb_pll_release(),
> instead of removing module params?
But you cannot know deterministically which device corrensponds to
what "id" (when you have multiple dvb_pll devices),
since "id" is dependent on the history of register and unregis
Hi,
> diff --git a/drivers/media/dvb-frontends/dvb-pll.c
> b/drivers/media/dvb-frontends/dvb-pll.c
> index ba0c49107bd2..c850f1d69bce 100644
> --- a/drivers/media/dvb-frontends/dvb-pll.c
> +++ b/drivers/media/dvb-frontends/dvb-pll.c
> @@ -788,6 +788,9 @@ struct dvb_frontend *dvb_pll_attach(struct
Hi,
thank you for reviewing my patch,
( <20190110095623.28070-1-tsk...@gmail.com>
https://patchwork.linuxtv.org/patch/53834/ ),
and excuse me for my late reply.
I somehow lost your mail and noticed it just today by checking Patchwork.
On Mon, 18 Feb 2019 21:04:28 +, you wrote:
> It might b
Hi,
thanks for the review.
>> +gl861_i2c_rawwrite(struct dvb_usb_device *d, u8 addr, u8 *wbuf, u16 wlen)>>
>> +{>> + u8 *buf;>> +int ret;>> +>> +buf = kmalloc(wlen,
>> GFP_KERNEL);>> +if (!buf)>> + return -ENOMEM;>> +>> +
>> usleep_range(1000, 2000); /* avoid I2C erro
> I don't understand those control message parts and it is bit too hard to
> read i2c adapter implementation to get understanding. Could you offer
> simple 2 sniff examples, register write to demod and register write to
> tuner.
Here is the part of a packet log.
1. write to demod (addr:0x18)
reg
> I simply cannot see why it cannot work. Just add i2c adapter and
> suitable logic there. Transaction on your example is simply and there is
> no problem to implement that kind of logic to demod i2c adapter.
I might be totally wrong, but...
i2c transactions to a tuner must use:
1. usb_control_ms
Hi,
thanks for the comment.
> You should implement i2c adapter to demod driver and not add such glue
> to that USB-bridge. I mean that "relayed" stuff, i2c communication to
> tuner via demod. I2C-mux may not work I think as there is no gate-style
> multiplexing so you probably need plain i2c adapt
Hi,
As the new i2c binding helper was introduced,
I am now re-writing the following patches to use new helper functions.
> 5. Jan,16 2015: [v2,1/2] dvb: tua6034: add a new driver for Infineon tua6034
> tuner
> http://patchwork.linuxtv.org/patch/27927
> 6. Jan,16 2015: [v2,2/2] dvb-usb-f
thanks for the replys.
so, the new i2c "attach" helper code should
1. be usable for V4L2-DVB multi-functional(hybrid) tuner devices
(or at least co-exist well with them),
2. properly ref-count driver module
to prevent (accidental) 'unload before use' by users.
3. a. block un-binding of the d
Hi,
excuse me for taking up a very old post again,
but I'd like to know the status of the patch:
https://patchwork.linuxtv.org/patch/27922/
, which provides helper code for defining/loading i2c DVB subdev drivers.
Was it rejected and
each i2c demod/tuner drivers should provide its own version o
Hi, Satoshi,
just some small comments about tuners/qm1d1c0042...
> --- a/drivers/media/tuners/qm1d1c0042.c
> +++ b/drivers/media/tuners/qm1d1c0042.c
> @@ -32,14 +32,23 @@
> #include "qm1d1c0042.h"
>
> #define QM1D1C0042_NUM_REGS 0x20
> -
> -static const u8 reg_initval[QM1D1C0042_NUM_REGS] = {
You still haven't described any concrete reasons
why you revert those existing drivers,
and I definitely disagree with this patch.
--
akihiro
--
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
Moikka,
thank you for the comment.
(and sorry for the late reply. I was off from work until recently.)
> Basically the issue is registering I2C driver and after that reference
> counting it as there is dvb frontend ops which are called.
In current DVB drivers, "struct dvb_frontend"s can be alloc
Moikka,
thank you for the comment.
On 2015年01月14日 03:54, Antti Palosaari wrote:
>> --- a/drivers/media/dvb-core/dvb_frontend.h
>> +++ b/drivers/media/dvb-core/dvb_frontend.h
>> @@ -415,6 +415,7 @@ struct dtv_frontend_properties {
>> struct dvb_frontend {
>> struct dvb_frontend_ops ops;
>>
On 2015年01月06日 03:29, Mauro Carvalho Chehab wrote:
> Em Mon, 05 Jan 2015 23:36:00 +0900
>> And if so,
>> Shouldn't only the (tuner) subdevices be registered separately
>> in dvb_i2c_attach_tuner(), instead of dvb_i2c_attach_fe()?
>
> No, it seems better to let dmxdev to register. That means that
On 2015年01月02日 00:51, Mauro Carvalho Chehab wrote:
> /*
> @@ -416,6 +418,11 @@ struct dvb_frontend {
> struct dvb_frontend_ops ops;
> struct dvb_adapter *dvb;
> struct i2c_client *fe_cl;
> +#if defined(CONFIG_MEDIA_CONTROLLER)
> + struct media_device *mdev;
> + struct med
moikka,
On 2015年01月02日 06:30, Antti Palosaari wrote:
> I am on holiday trip now. But generally speaking I would like to separate all
> drivers from the interfaces. That means for example I2C tuner driver is just
> a I2C driver and nothing more - no relations to DVB nor V4L API. That is
> someth
> The only thing I noticed is that it is causing some warnings at
> dmesg about trying to create already created sysfs nodes, when the
> driver is removed/reinserted.
>
> Probably, the remove callback is called too soon or too late.
I don't have any warnings in syslog when reinserting earth-pt3 +
Hi, thank you for the comment.
I understood the naming conventions you mentioned,
and I'll update them in the next version.
>> diff --git a/drivers/media/dvb-core/dvb_i2c.c
>> b/drivers/media/dvb-core/dvb_i2c.c
>> new file mode 100644
>> index 000..4ea4e5e
>> --- /dev/null
>> +++ b/drivers/me
ping.
we don't need this kind of feature in the dvb-core?
--
akihiro
--
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
> So at first it would be nice if someone could confirm my findings.
> Applying the same kind of code like my patch and unplug something that
> uses the affected frontend should be enough.
I tried that for tc90522, and I could remove earth-pt3
(which uses tc90522), tc90522 and tuner modules withou
> I realize captions is an application-layer function, and intend to work
> with the CCExtractor team. Do any other applications already have ISDB
> caption support?
there's a mplayer patch for subtitle support:
https://github.com/0p1pp1/mplayer/commit/6debc831d34cad98d1b251920fbdb48f74a880df
It
I already posted v2 to this ML,
but it was at top-level, not in-reply-to this thread.
Sorry for the confusing posts.
v2 of this patch:
https://patchwork.linuxtv.org/patch/26652/
and the other two patches
https://patchwork.linuxtv.org/patch/26651/
https://patchwork.linuxtv.org/patch/26653/
Hi,
> I would really prefer if you could use the autotools toolchain
> (autoconf, automake, libtool) to produce the two gconv modules. You
> might be able to have a look at the v4l-plugins Makefiles in this project.
As the upstream glibc does not use autotools,
I looked through the Makefiles ther
Hi,
the patch is aimed to do just as you wrote,
i.e. add wrapper funcs with the original names.
sorry for my bad english.
--
akihiro
--
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.k
> Hmm... Is this due to a spec definition, or is it just how satellite
> operators decided?
>
> If ARIB spec doesn't allow polarization set, we should remove it from the
> Kernel DocBook.
ARIB spec does NOT limit polarization, just the satellite operators do.
>
> Btw, how does the PT1 driver h
Hi,
After I re-checked the source,
I noticed that dvb_scan_add_entry() also breaks API/ABI compatibility
as well as dvb_new_freq_is_needed(), and those functions are
marked as "ancillary functions used internally inside the library"
in dvb-scan.h.
So I think it would rather be better to move those
On 2014年11月01日 04:47, Mauro Carvalho Chehab wrote:
> This one failed to build here:
>
> Making all in gconv
> make[3]: Entering directory `/devel/v4l/v4l-utils/lib/gconv'
> make[3]: *** No rule to make target `all'. Stop.
Sorry, I forgot to "git add -f Makefile".
I'll repost v4.
> I had to add
I withdrew this patch as it's meaningless.
Originally I mis-understood that when dvbv5-scan was run
with "-G" option, the props in channel config file that
are not specified in dvb-v5-std.c::sys_foo_props[] were
once loaded to "parms" structure to be scanned,
but later discarded in dvb_fe_get_parm
> Using my Fedora package maintainer's hat, I would only enable this
> on a patch that would also be packaging the gconf module as a
> separate subpackage, as this would make easier to deprecate it
> if/when this gets merged at gconv's upstream.
I'm afraid that gconv upstream won't merge those app
On 2014年10月27日 23:46, Mauro Carvalho Chehab wrote:
> Always right circular polarization? I guess I read something at the specs
> sometime ago about left polarization too. Not sure if this is actually used.
Currently all transponders of ISDB-S use right polarization.
but I modifed this part and re
On 2014年10月27日 01:33, Antti Palosaari wrote:
> You should calculate bw too as tuners needs set filters according to
> used channel bw. You could calculate nominal needed be using formula:
> bandwidth = roll-off factor * symbol rate
I'll include it in the next version.
thx
--
Akihiro
--
To unsubscr
>> Reported by David Binderman
>
> ^^ See Documentation/SubmittingPatches
Though I knew that Reported-by: tag should not be used,
I wrote it just to express my appreciation for his report,
and did not mean to attach the tag.
But I admit that it is confusing,
so I'd like to beg Mauro to do me the
Hi, Mauro,
thanks for the review.
I'll update the patch soon.
And I wrote some comments and questions as a reply to
your each review mail.
On 2014年10月09日 01:22, Mauro Carvalho Chehab wrote:
> Yeah, it will likely require a table just like the one we've added
> for EN 300 468 specific charset wit
On 2014年10月09日 01:04, Mauro Carvalho Chehab wrote:
>> @@ -251,6 +251,16 @@ static int run_scan(struct arguments *args,
>> if (dvb_retrieve_entry_prop(entry, DTV_POLARIZATION, &pol))
>> pol = POLARIZATION_OFF;
>>
>> +if (parms->current_sys == SYS_ISDBS
(some Cc:'s removed, to exclude those who are not directly involved)
It seems that I should make some counterarguments.
On 2014年10月05日 21:39, AreMa Inc. wrote:
> We started developing and publishing PT3 drivers (chardev and DVB versions)
> on 2013 and have been submitting the patches to this
> Maybe that is proper fix. I didn't test it.
I had some tests with/without inserting a deliberate error return
from dvb_register_frontend() and with/without CONFIG_MODULES option,
and the all combinations seem to have worked fine.
kiitos, Antti and Randy.
--
akihiro
--
To unsubscribe from this l
> Ok, but see the definition at the API spec:
>
>
> http://linuxtv.org/downloads/v4l-dvb-apis/FE_GET_SET_PROPERTY.html#isdb-hierq-layers
>
> Basically, we use 0, 1, 2, 4 no matter what mode, e. g.
I understand.
(though I wonder why "4" is assigned instead of "3"
when it is not a flag bit
> - b = (((s64) freq) << 20) / state->cfg.xtal_freq - (((s64) a) << 20);
> + b = (s32)div64_s64(((s64) freq) << 20,
> +state->cfg.xtal_freq - (((s64) a) << 20));
> +
I'm afraid it should be like the following.
> + b = (s32)(div64_s64(((s64) freq) << 20, state->c
> And TMCC returns it as 0, 1, 2, 3, 4, instead of 0, 1, 2, 4, 8.
According to ARIB STD B31 3.15.6.7 (table 3.30),
The value is encoded and depends on the "mode".
so demods have to encode/decode anyway.
> AFAIKT, that doesn't work in Sound Broadcast mode, as the demod won't
> be able to read the
> Btw, please check if your driver is handling it well, as the valid
> values for interleave are 0, 1, 2, 4 (actually, dib8000 also
> supports interleaving equal to 8, if sound_broadcast).
I have no info on how to set time interleaving parameters,
although I can read them as a part of TMCC info.
I
Sorry to bother you with those build warnings.
Somehow I didn't see them when I built the modules myself on 64bit box.
maybe since I forgot to test all-y config (and 32bit build),
the gcc cmd did not include [-Wmissing-prototypes].
--
To unsubscribe from this list: send the line "unsubscribe linux
Hi,
On 2014年09月24日 05:07, Mauro Carvalho Chehab wrote:
> I applied this series, as we're discussing it already for a long time,
> and it seems in a good shape...
thanks for your reviews and advices.
>> +static int tc90522s_read_status(struct dvb_frontend *fe, fe_status_t
>> *status)
..
Moi!,
thanks for the review.
>> +static int reg_read(struct mxl301rf_state *state, u8 reg, u8 *val)
...
>> +ret = i2c_transfer(state->i2c->adapter, msgs, ARRAY_SIZE(msgs));
>> +if (ret >= 0 && ret < ARRAY_SIZE(msgs))
>> +ret = -EIO;
>> +return (ret == ARRAY_SIZE(msgs)) ? 0
moikka!,
> Basically it is 2 functions, af9035_add_i2c_dev() and af9035_del_i2c_dev()
I used request_module()/try_module_get()/module_put()
just like the above example (and bridge-core.c).
It works, but when I unload bridge driver(earth_pt3),
its demod and tuner modules stay loaded, with the refc
Moikka!,
thanks for the comments and advices.
I had been updating my code and during that, I also found that
updating property cache in tuner_ops.get_signal_strength() was
simple and (seemed to me) better than using a kthread,
so the current implementation (under testing) is just like
what Mauro p
Moi!
> Yes, using the I2C binding way provides a better decoupling than using the
> legacy way. The current dvb_attach() macros are hacks that were created
> by the time where the I2C standard bind didn't work with DVB.
I understand. I converted my code to use i2c binding model,
but I'm uncertain
Hi,
> Also, I would like to see all new drivers (demod and tuner) implemented
> as a standard kernel I2C drivers (or any other bus). I have converted
> already quite many drivers, si2168, si2157, m88ds3103, m88ts2022,
> it913x, tda18212, ...
I wrote the code in the old style using dvb_attach()
be
Hi Matthias,
thanks for the comment.
> it sounds wrong to export a second function besides tc90522_attach.
> This way there is a hard dependency of the bridge driver to the demod
> driver.
> In this case it is the only possible demod, but in general it violates
> the design of demod drivers and th
moikka,
> Start polling thread, which polls once per 2 sec or so, which reads RSSI
> and writes value to struct dtv_frontend_properties. That it is, in my
> understanding. Same for all those DVBv5 stats. Mauro knows better as he
> designed that functionality.
I understand that RSSI property shoul
moikka,
thanks for the comment.
> I have feeling DVBv5 API is aimed to transfer data via property cached.
> I haven't done much driver for DVBv5 statistics, but recently I
> implemented CNR (DVBv5 stats) to Si2168 driver and it just writes all
> the values directly to property cache. I expect RF s
On 2014年08月16日 01:17, Mauro Carvalho Chehab wrote:
..
>> +++ b/drivers/media/pci/pt3/pt3.c
..
>> +static int pt3_fetch_thread(void *data)
>> +{
>> +struct pt3_adapter *adap = data;
>> +
>> +#define PT3_FETCH_DELAY (10 * 1000)
>> +#define PT3_INITIAL_DISCARD_BUFS 4
>> +
>> +p
Hi Mauro,
thanks for the review.
I will update the patch and post it later.
Before doing so, I'd like to ask some questions.
>> +++ b/drivers/media/tuners/mxl301rf.c
>> +/* *strength : [1/1000 dBm] */
>> +static int mxl301rf_get_rf_strength(struct dvb_frontend *fe, u16 *strength)
>> +{
...
>
On 2014年08月16日 01:09, Mauro Carvalho Chehab wrote:
>> +++ b/drivers/media/dvb-frontends/tc90522.c
>> +static int tc90522s_get_frontend(struct dvb_frontend *fe)
>> +{
.
>> +c->delivery_system = SYS_ISDBS;
>> +c->symbol_rate = 2886;
>
> Hmm... symbol rate is fixe
Hi Bud,
It seems that the tuner modules use fe->ops.write()
for i2c communications, which is set by parent module.
but I'm afraid fe->ops.write() is not for the purpose.
Shouldn't they use i2c_adapters passed from _attach() etc. instead?
regards,
akihiro
--
To unsubscribe from this list: send th
Hi,
It would be nice if you consider integrating this driver and pt1.
Because PT3 is a PCIe successor of PT2 and designed by the same person,
I guess they can share much code about bridge FPGA chip and
demod IC (tc90512 in PT1/2 and tc90522 in PT3),
though their frontends are obviously different.
Hi,
> diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.h
> b/drivers/media/dvb/dvb-core/dvb_frontend.h
> index 7c64c09..bec0cda 100644
> --- a/drivers/media/dvb/dvb-core/dvb_frontend.h
> +++ b/drivers/media/dvb/dvb-core/dvb_frontend.h
> @@ -368,11 +368,8 @@ struct dtv_frontend_properties {
>
> [channel name]
> property = value
> ...
> property = value
Currently, at least gstreamer's dvbbasebin and mplayer assumue that
the channel configuration file has the format of one line per channel.
So when I personally patched them to use v5 parameters,
I chose the one-line-per-chann
Hi Mauro,
>> I wrote several patches those days in order to allow dvb-apps to properly
>> parse ISDB-T channel.conf.
I think it would be convenient if channel.conf allows
the kind of format of PROPNAME=VALUE list, for readability and extensibility
of the conf file.
there are already so many pa
From: Akihiro Tsukada
This patch adds a fix to accept frequency with its center shifted.
The driver used to accept center frequencies of the normal UHF band channels,
but in ISDB-T, center frequency is shifted with 1/7MHz.
It was shifted internally in the driver,
but this patch enables to
> so, which device can I buy, working in Japan, in linux, and in digital
> (working after 2011)?
known to work devices
0. 774 Friio white
http://www.friio.com/ (in Japanese)
USB2.0 ISDB-T, with a card-reader device, without BCAS card
DVB driver: in v4l-dvb main repository
direct net shoppin
> My tuner card is a Pixela PIXDT090-PE0
Hi Romont,
As you might know, all Japanese DTV programs are scrambled with BCAS.
BCAS scrambling algorithm itself is opend in the standard,
but in addition to that, PC devices have to encrypt received data
locally in order to get authorized for BCAS.
So mo
From: Akihiro Tsukada
This patch removes some fe->ops.X() functions which do nothing more useful than
the default.
Priority: normal
Signed-off-by: Akihiro Tsukada
---
friio-fe.c | 38 --
1 file changed, 38 deletions(-)
diff --git a/linux/drivers/me
From: Akihiro Tsukada
This patch makes the driver return the correct DTV_DELIVERY_SYSTEM.
The driver previously returned SYS_UNDEFINED for DTV_DELIVERY_SYSTEM property,
as it lacked any driver specific S2API support.
Priority: normal
Signed-off-by: Akihiro Tsukada
---
friio-fe.c | 27
From: Akihiro Tsukada
This patch adds driver for 774 Friio White, ISDB-T USB receiver
Friio White is an USB 2.0 ISDB-T receiver. (http://www.friio.com/)
The device has a GL861 chip and a Comtech JDVBT90502 canned tuner module.
This driver ignores all the frontend_parameters except frequency,
as
ino to ARIB STD-B31)
as a reference in the document may help readers.
-----
Akihiro TSUKADA
--
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
71 matches
Mail list logo
