mtd:nor: unlock enhancement for cmdset0002
Hi,
I'm not so much experienced in MTD area, so please correct me, if I'm wrong.
NOR flashes supported by cmdset0002 (AMD & Fujitsu Standard Vendor Command Set)
are not able to unlock one particular eraseblock, the unlocking is
done by unlock
the whole chip. Because of that the driver (cfi_cmdset_0002.c) do it
in free steps:
1) remember all locked eraseblocks
2) do chip unlock
3) lock all remaining eraseblocks (minus, of course ones which have to be
enabled by current ioctl call).
Unfortunately, in step 2 (unlocking chip) there is used unlocking over
all eraseblocks
which belong to requested unlock area. It means that chip unlock operation
is doing multiple times, without any reason of doing so. It is enough to do
unlock only on one eraseblock (as it already means full chip unlock). This way
we can save programming time, on bigger parts even more dramatically
(one chip unlock per request vs. [number of eraseblocks] * chip unlock).
So I would like to ask, if my finding is correct.
Thanks
/Honza
BTW, in current project we have one NOR chip, so when I applied
the following patch (I know it has to be generalized, even now I
understand that it can not work correctly in case of multiple NOR chips
or with different eraseblock sizes, ... etc) I lowered unlocking for 20x
on 64MB filesystem.
diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c
b/drivers/mtd/chips/cfi_cmdset_0002.c
index 9dca881..36e45d2 100644
--- a/drivers/mtd/chips/cfi_cmdset_0002.c
+++ b/drivers/mtd/chips/cfi_cmdset_0002.c
@@ -2694,8 +2694,8 @@ static int __maybe_unused cfi_ppb_unlock(struct
mtd_info *mtd, loff_t ofs,
}
/* Now unlock the whole chip */
- ret = cfi_varsize_frob(mtd, do_ppb_xxlock, ofs, len,
- DO_XXLOCK_ONEBLOCK_UNLOCK);
+ ret = do_ppb_xxlock(map, &cfi->chips[0], 0, regions[0].erasesize,
+DO_XXLOCK_ONEBLOCK_UNLOCK);
if (ret) {
kfree(sect);
return ret;
Re: mtd:nor: unlock enhancement for cmdset0002
Sorry for self-answering, but I forgot to add mtd maintainers and
mtd-mailinglist.
/Honza
2017-05-11 12:11 GMT+02:00 Honza Petrouš :
> Hi,
>
> I'm not so much experienced in MTD area, so please correct me, if I'm wrong.
>
> NOR flashes supported by cmdset0002 (AMD & Fujitsu Standard Vendor Command
> Set)
> are not able to unlock one particular eraseblock, the unlocking is
> done by unlock
> the whole chip. Because of that the driver (cfi_cmdset_0002.c) do it
> in free steps:
> 1) remember all locked eraseblocks
> 2) do chip unlock
> 3) lock all remaining eraseblocks (minus, of course ones which have to be
> enabled by current ioctl call).
>
> Unfortunately, in step 2 (unlocking chip) there is used unlocking over
> all eraseblocks
> which belong to requested unlock area. It means that chip unlock operation
> is doing multiple times, without any reason of doing so. It is enough to do
> unlock only on one eraseblock (as it already means full chip unlock). This way
> we can save programming time, on bigger parts even more dramatically
> (one chip unlock per request vs. [number of eraseblocks] * chip unlock).
>
> So I would like to ask, if my finding is correct.
>
> Thanks
> /Honza
>
> BTW, in current project we have one NOR chip, so when I applied
> the following patch (I know it has to be generalized, even now I
> understand that it can not work correctly in case of multiple NOR chips
> or with different eraseblock sizes, ... etc) I lowered unlocking for 20x
> on 64MB filesystem.
>
>
> diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c
> b/drivers/mtd/chips/cfi_cmdset_0002.c
> index 9dca881..36e45d2 100644
> --- a/drivers/mtd/chips/cfi_cmdset_0002.c
> +++ b/drivers/mtd/chips/cfi_cmdset_0002.c
> @@ -2694,8 +2694,8 @@ static int __maybe_unused cfi_ppb_unlock(struct
> mtd_info *mtd, loff_t ofs,
> }
>
> /* Now unlock the whole chip */
> - ret = cfi_varsize_frob(mtd, do_ppb_xxlock, ofs, len,
> - DO_XXLOCK_ONEBLOCK_UNLOCK);
> + ret = do_ppb_xxlock(map, &cfi->chips[0], 0, regions[0].erasesize,
> +DO_XXLOCK_ONEBLOCK_UNLOCK);
> if (ret) {
> kfree(sect);
> return ret;
Re: [RFC] [DVB][FRONTEND] Added a new ioctl for optimizing frontend property set operation
2017-09-14 22:50 GMT+02:00 Mauro Carvalho Chehab :
> Hi Satendra,
>
> Em Thu, 14 Sep 2017 05:59:27 -0400
> Satendra Singh Thakur escreveu:
>
>> -For setting one frontend property , one FE_SET_PROPERTY ioctl is called
>> -Since, size of struct dtv_property is 72 bytes, this ioctl requires
>> ---allocating 72 bytes of memory in user space
>> ---allocating 72 bytes of memory in kernel space
>> ---copying 72 bytes of data from user space to kernel space
>> -However, for all the properties, only 8 out of 72 bytes are used
>> for setting the property
>
> That's true. Yet, for get, the size can be bigger, as ISDB-T can
> return statistics per layer, plus a global one.
>
>> -Four bytes are needed for specifying property type and another 4 for
>> property value
>> -Moreover, there are 2 properties DTV_CLEAR and DTV_TUNE which use
>> only 4 bytes for property name
>> ---They don't use property value
>> -Therefore, we have defined new short variant/forms/version of currently
>> used structures for such 8 byte properties.
>> -This results in 89% (8*100/72) of memory saving in user and kernel space
>> each.
>> -This also results in faster copy (8 bytes as compared to 72 bytes) from
>> user to kernel space
>> -We have added new ioctl FE_SET_PROPERTY_SHORT which utilizes above
>> mentioned new property structures
>> -This ioctl can co-exist with present ioctl FE_SET_PROPERTY
>> -If the apps wish to use shorter forms they can use
>> proposed FE_SET_PROPERTY_SHORT, rest of them can continue to use
>> current versions FE_SET_PROPERTY
>
>> -We are currently not validating incoming properties in
>> function dtv_property_short_process_set because most of
>> the frontend drivers in linux source are not using the
>> method ops.set_property. Just two drivers are using it
>> drivers/media/dvb-frontends/stv0288.c
>> driver/media/usb/dvb-usb/friio-fe.c
>> -Moreover, stv0288 driver implemments blank function
>> for set_property.
>> -If needed in future, we can define a new
>> ops.set_property_short method to support
>> struct dtv_property_short.
>
> Nah. Better to just get rid of get_property()/set_froperty() for good.
>
> Just sent a RFC patch series doing that.
>
> The only thing is that stv6110 seems to have a dirty hack that may
> depend on that. Someone need to double-check if the patch series
> I just sent doesn't break anything. If it breaks, then we'll need
> to add an extra parameter to stv6110 attach for it to know what
> behavior is needed there.
Do you mean in stv6110_set_frequency()?
I must say I was shocked by the beginning of it.
Can somebody explain me the reason for such strange
srate computation?
See the head of function:
static int stv6110_set_frequency(struct dvb_frontend *fe, u32 frequency)
{
struct stv6110_priv *priv = fe->tuner_priv;
struct dtv_frontend_properties *c = &fe->dtv_property_cache;
u8 ret = 0x04;
u32 divider, ref, p, presc, i, result_freq, vco_freq;
s32 p_calc, p_calc_opt = 1000, r_div, r_div_opt = 0, p_val;
s32 srate;
dprintk("%s, freq=%d kHz, mclk=%d Hz\n", __func__,
frequency, priv->mclk);
/* K = (Reference / 100) - 16 */
priv->regs[RSTV6110_CTRL1] &= ~(0x1f << 3);
priv->regs[RSTV6110_CTRL1] |=
priv->mclk / 100) - 16) & 0x1f) << 3);
/* BB_GAIN = db/2 */
if (fe->ops.set_property && fe->ops.get_property) {
srate = c->symbol_rate;
dprintk("%s: Get Frontend parameters: srate=%d\n",
__func__, srate);
} else
srate = 1500;
here I would like to note, there there is NO MORE
anything dependant on srate. It looks like some dead code for me.
And the condition sentence looks even more funny - is it
for real to check of retrieval of srate only in case
if some other function pointers are not null?
/Honza
PS: Don't forget that we have duplicated drivers for STV6110,
stv6110 by Igor and stv6110x by Manu.
Re: [PATCH 12/15] media: dmx.h: get rid of DMX_SET_SOURCE
2017-09-01 1:46 GMT+02:00 Mauro Carvalho Chehab :
> No driver uses this ioctl, nor it is documented anywhere.
>
> So, get rid of it.
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
> Documentation/media/dmx.h.rst.exceptions| 13
> Documentation/media/uapi/dvb/dmx-set-source.rst | 44
> -
> Documentation/media/uapi/dvb/dmx_fcalls.rst | 1 -
> Documentation/media/uapi/dvb/dmx_types.rst | 20 ---
> include/uapi/linux/dvb/dmx.h| 12 ---
> 5 files changed, 90 deletions(-)
> delete mode 100644 Documentation/media/uapi/dvb/dmx-set-source.rst
>
> diff --git a/Documentation/media/dmx.h.rst.exceptions
> b/Documentation/media/dmx.h.rst.exceptions
> index 5572d2dc9d0e..d2dac35bb84b 100644
> --- a/Documentation/media/dmx.h.rst.exceptions
> +++ b/Documentation/media/dmx.h.rst.exceptions
> @@ -40,18 +40,6 @@ replace enum dmx_input :c:type:`dmx_input`
> replace symbol DMX_IN_FRONTEND :c:type:`dmx_input`
> replace symbol DMX_IN_DVR :c:type:`dmx_input`
>
> -# dmx_source_t symbols
> -replace enum dmx_source :c:type:`dmx_source`
> -replace symbol DMX_SOURCE_FRONT0 :c:type:`dmx_source`
> -replace symbol DMX_SOURCE_FRONT1 :c:type:`dmx_source`
> -replace symbol DMX_SOURCE_FRONT2 :c:type:`dmx_source`
> -replace symbol DMX_SOURCE_FRONT3 :c:type:`dmx_source`
> -replace symbol DMX_SOURCE_DVR0 :c:type:`dmx_source`
> -replace symbol DMX_SOURCE_DVR1 :c:type:`dmx_source`
> -replace symbol DMX_SOURCE_DVR2 :c:type:`dmx_source`
> -replace symbol DMX_SOURCE_DVR3 :c:type:`dmx_source`
> -
> -
> # Flags for struct dmx_sct_filter_params
> replace define DMX_CHECK_CRC :c:type:`dmx_sct_filter_params`
> replace define DMX_ONESHOT :c:type:`dmx_sct_filter_params`
> @@ -61,4 +49,3 @@ replace define DMX_IMMEDIATE_START
> :c:type:`dmx_sct_filter_params`
> replace typedef dmx_filter_t :c:type:`dmx_filter`
> replace typedef dmx_pes_type_t :c:type:`dmx_pes_type`
> replace typedef dmx_input_t :c:type:`dmx_input`
> -replace typedef dmx_source_t :c:type:`dmx_source`
> diff --git a/Documentation/media/uapi/dvb/dmx-set-source.rst
> b/Documentation/media/uapi/dvb/dmx-set-source.rst
> deleted file mode 100644
> index ac7f77b25e06..
> --- a/Documentation/media/uapi/dvb/dmx-set-source.rst
> +++ /dev/null
> @@ -1,44 +0,0 @@
> -.. -*- coding: utf-8; mode: rst -*-
> -
> -.. _DMX_SET_SOURCE:
> -
> -==
> -DMX_SET_SOURCE
> -==
> -
> -Name
> -
> -
> -DMX_SET_SOURCE
> -
> -
> -Synopsis
> -
> -
> -.. c:function:: int ioctl(fd, DMX_SET_SOURCE, struct dmx_source *src)
> -:name: DMX_SET_SOURCE
> -
> -
> -Arguments
> --
> -
> -
> -``fd``
> -File descriptor returned by :c:func:`open() `.
> -
> -``src``
> - Undocumented.
> -
> -
> -Description
>
> -
> -.. note:: This ioctl is undocumented. Documentation is welcome.
> -
> -
> -Return Value
> -
> -
> -On success 0 is returned, on error -1 and the ``errno`` variable is set
> -appropriately. The generic error codes are described at the
> -:ref:`Generic Error Codes ` chapter.
> diff --git a/Documentation/media/uapi/dvb/dmx_fcalls.rst
> b/Documentation/media/uapi/dvb/dmx_fcalls.rst
> index 49e013d4540f..be98d60877f2 100644
> --- a/Documentation/media/uapi/dvb/dmx_fcalls.rst
> +++ b/Documentation/media/uapi/dvb/dmx_fcalls.rst
> @@ -21,6 +21,5 @@ Demux Function Calls
> dmx-get-event
> dmx-get-stc
> dmx-get-pes-pids
> -dmx-set-source
> dmx-add-pid
> dmx-remove-pid
> diff --git a/Documentation/media/uapi/dvb/dmx_types.rst
> b/Documentation/media/uapi/dvb/dmx_types.rst
> index 9e907b85cf16..a205c02ccdc1 100644
> --- a/Documentation/media/uapi/dvb/dmx_types.rst
> +++ b/Documentation/media/uapi/dvb/dmx_types.rst
> @@ -197,23 +197,3 @@ struct dmx_stc
> unsigned int base; /* output: divisor for stc to get 90 kHz clock */
> __u64 stc; /* output: stc in 'base'*90 kHz units */
> };
> -
> -
> -
> -enum dmx_source
> -===
> -
> -.. c:type:: dmx_source
> -
> -.. code-block:: c
> -
> -typedef enum dmx_source {
> - DMX_SOURCE_FRONT0 = 0,
> - DMX_SOURCE_FRONT1,
> - DMX_SOURCE_FRONT2,
> - DMX_SOURCE_FRONT3,
> - DMX_SOURCE_DVR0 = 16,
> - DMX_SOURCE_DVR1,
> - DMX_SOURCE_DVR2,
> - DMX_SOURCE_DVR3
> -} dmx_source_t;
> diff --git a/include/uapi/linux/dvb/dmx.h b/include/uapi/linux/dvb/dmx.h
> index c0ee44fbdb13..dd2b832c02ce 100644
> --- a/include/uapi/linux/dvb/dmx.h
> +++ b/include/uapi/linux/dvb/dmx.h
> @@ -117,17 +117,6 @@ struct dmx_pes_filter_params
> __u32 flags;
> };
>
> -typedef enum dmx_source {
> - DMX_SOURCE_FRONT0 = 0,
> - DMX_SOURCE_FRONT1,
> - DMX_SOURCE_FRONT2,
> - DMX_SOURCE_FRONT3,
> - DMX_SOURCE_DVR0 = 16,
> - DMX_SOURCE_DVR1,
> - DMX_SOURCE_DVR2,
> - DMX_SOURCE_DVR3
> -} dmx_source_t;
> -
> struct dmx_stc {
> unsigned int num; /* input : which STC?
Re: [PATCH 00/15] Improve DVB documentation and reduce its gap
2017-09-01 1:46 GMT+02:00 Mauro Carvalho Chehab : > The DVB documentation was negligected for a long time, with > resulted on several gaps between the API description and its > documentation. > > I'm doing a new reading at the documentation. As result of it, > this series: > > - improves the introductory chapter, making it more generic; > - Do some adjustments at the frontend API, using kernel-doc > when possible. > - Remove unused APIs at DVB demux. I suspect that the drivers > implementing such APIs were either never merged upstream, > or the API itself were never used or was deprecated a long > time ago. In any case, it doesn't make any sense to carry > on APIs that aren't properly documented, nor are used on the > upstream Kernel. > > With this patch series, the gap between documentation and > code is solved for 3 DVB APIs: > > - Frontend API; > - Demux API; > - Net API. > > There is still a gap at the CA API that I'll try to address when I > have some time[1]. > > [1] There's a gap also on the legacy audio, video and OSD APIs, > but, as those are used only by a single very old deprecated > hardware (av7110), it is probably not worth the efforts. > I agree that av7110 is very very old piece of hw (but it is already in my hall of fame because of its Skystar 1 incarnation as first implementation of DVB in Linux) and it is sad that we still don't have at least one driver for any SoC with embedded DVB devices. I understand that the main issue is that no any DVB-enabled SoC vendor is interested in upstreaming theirs code, but I still hope it will change in near future(*) Without having full-featured DVB device in vanilla, we surely don't get some parts of DVB API covered. I can imagine that when somebody comes with such full-featured device he wants to reinvent just removed bits. It's my 5 cents /Honza (*) My favourite is HiSilicon with very nice Hi3798 4K chip with announced support from Linaro and already available devboard for reasonable price. PS: I'm in no any way connected with HiSilicon nor any other DVB-enabled SoC vendor.
Re: [PATCH 12/15] media: dmx.h: get rid of DMX_SET_SOURCE
2017-09-01 11:37 GMT+02:00 Mauro Carvalho Chehab : > Em Fri, 1 Sep 2017 08:28:20 +0200 > Honza Petrouš escreveu: > >> 2017-09-01 1:46 GMT+02:00 Mauro Carvalho Chehab : >> > No driver uses this ioctl, nor it is documented anywhere. >> > >> > So, get rid of it. >> > >> > Signed-off-by: Mauro Carvalho Chehab >> > --- >> > Documentation/media/dmx.h.rst.exceptions| 13 >> > Documentation/media/uapi/dvb/dmx-set-source.rst | 44 >> > - >> > Documentation/media/uapi/dvb/dmx_fcalls.rst | 1 - >> > Documentation/media/uapi/dvb/dmx_types.rst | 20 --- >> > include/uapi/linux/dvb/dmx.h| 12 --- >> > 5 files changed, 90 deletions(-) >> > delete mode 100644 Documentation/media/uapi/dvb/dmx-set-source.rst >> > >> > diff --git a/Documentation/media/dmx.h.rst.exceptions >> > b/Documentation/media/dmx.h.rst.exceptions >> > index 5572d2dc9d0e..d2dac35bb84b 100644 >> > --- a/Documentation/media/dmx.h.rst.exceptions >> > +++ b/Documentation/media/dmx.h.rst.exceptions >> > @@ -40,18 +40,6 @@ replace enum dmx_input :c:type:`dmx_input` >> > replace symbol DMX_IN_FRONTEND :c:type:`dmx_input` >> > replace symbol DMX_IN_DVR :c:type:`dmx_input` >> > >> > -# dmx_source_t symbols >> > -replace enum dmx_source :c:type:`dmx_source` >> > -replace symbol DMX_SOURCE_FRONT0 :c:type:`dmx_source` >> > -replace symbol DMX_SOURCE_FRONT1 :c:type:`dmx_source` >> > -replace symbol DMX_SOURCE_FRONT2 :c:type:`dmx_source` >> > -replace symbol DMX_SOURCE_FRONT3 :c:type:`dmx_source` >> > -replace symbol DMX_SOURCE_DVR0 :c:type:`dmx_source` >> > -replace symbol DMX_SOURCE_DVR1 :c:type:`dmx_source` >> > -replace symbol DMX_SOURCE_DVR2 :c:type:`dmx_source` >> > -replace symbol DMX_SOURCE_DVR3 :c:type:`dmx_source` >> > - >> > - >> > # Flags for struct dmx_sct_filter_params >> > replace define DMX_CHECK_CRC :c:type:`dmx_sct_filter_params` >> > replace define DMX_ONESHOT :c:type:`dmx_sct_filter_params` >> > @@ -61,4 +49,3 @@ replace define DMX_IMMEDIATE_START >> > :c:type:`dmx_sct_filter_params` >> > replace typedef dmx_filter_t :c:type:`dmx_filter` >> > replace typedef dmx_pes_type_t :c:type:`dmx_pes_type` >> > replace typedef dmx_input_t :c:type:`dmx_input` >> > -replace typedef dmx_source_t :c:type:`dmx_source` >> > diff --git a/Documentation/media/uapi/dvb/dmx-set-source.rst >> > b/Documentation/media/uapi/dvb/dmx-set-source.rst >> > deleted file mode 100644 >> > index ac7f77b25e06.. >> > --- a/Documentation/media/uapi/dvb/dmx-set-source.rst >> > +++ /dev/null >> > @@ -1,44 +0,0 @@ >> > -.. -*- coding: utf-8; mode: rst -*- >> > - >> > -.. _DMX_SET_SOURCE: >> > - >> > -== >> > -DMX_SET_SOURCE >> > -== >> > - >> > -Name >> > - >> > - >> > -DMX_SET_SOURCE >> > - >> > - >> > -Synopsis >> > - >> > - >> > -.. c:function:: int ioctl(fd, DMX_SET_SOURCE, struct dmx_source *src) >> > -:name: DMX_SET_SOURCE >> > - >> > - >> > -Arguments >> > -- >> > - >> > - >> > -``fd`` >> > -File descriptor returned by :c:func:`open() `. >> > - >> > -``src`` >> > - Undocumented. >> > - >> > - >> > -Description >> > >> > - >> > -.. note:: This ioctl is undocumented. Documentation is welcome. >> > - >> > - >> > -Return Value >> > - >> > - >> > -On success 0 is returned, on error -1 and the ``errno`` variable is set >> > -appropriately. The generic error codes are described at the >> > -:ref:`Generic Error Codes ` chapter. >> > diff --git a/Documentation/media/uapi/dvb/dmx_fcalls.rst >> > b/Documentation/media/uapi/dvb/dmx_fcalls.rst >> > index 49e013d4540f..be98d60877f2 100644 >> > --- a/Documentation/media/uapi/dvb/dmx_fcalls.rst >> > +++ b/Documentation/media/uapi/dvb/dmx_fcalls.rst >> > @@ -21,6 +21,5 @@ Demux Function Calls >> > dmx-get-event >> > dmx-get-stc >> > dmx-get-pes-pids >> > -dmx-set-source >> > dmx-add-pid >> > dmx-remove-pid >> > diff --git a/Documentation/media/uapi
Re: [PATCH 12/15] media: dmx.h: get rid of DMX_SET_SOURCE
2017-09-01 12:45 GMT+02:00 Mauro Carvalho Chehab : > Em Fri, 1 Sep 2017 11:53:11 +0200 > Honza Petrouš escreveu: > >> 2017-09-01 11:37 GMT+02:00 Mauro Carvalho Chehab : >> > Em Fri, 1 Sep 2017 08:28:20 +0200 >> > Honza Petrouš escreveu: >> > >> >> 2017-09-01 1:46 GMT+02:00 Mauro Carvalho Chehab >> >> : >> >> > No driver uses this ioctl, nor it is documented anywhere. >> >> > >> >> > So, get rid of it. >> >> > >> >> > Signed-off-by: Mauro Carvalho Chehab >> >> > --- >> >> > Documentation/media/dmx.h.rst.exceptions| 13 >> >> > Documentation/media/uapi/dvb/dmx-set-source.rst | 44 >> >> > - >> >> > Documentation/media/uapi/dvb/dmx_fcalls.rst | 1 - >> >> > Documentation/media/uapi/dvb/dmx_types.rst | 20 --- >> >> > include/uapi/linux/dvb/dmx.h| 12 --- >> >> > 5 files changed, 90 deletions(-) >> >> > delete mode 100644 Documentation/media/uapi/dvb/dmx-set-source.rst >> >> > >> >> > diff --git a/Documentation/media/dmx.h.rst.exceptions >> >> > b/Documentation/media/dmx.h.rst.exceptions >> >> > index 5572d2dc9d0e..d2dac35bb84b 100644 >> >> > --- a/Documentation/media/dmx.h.rst.exceptions >> >> > +++ b/Documentation/media/dmx.h.rst.exceptions >> >> > @@ -40,18 +40,6 @@ replace enum dmx_input :c:type:`dmx_input` >> >> > replace symbol DMX_IN_FRONTEND :c:type:`dmx_input` >> >> > replace symbol DMX_IN_DVR :c:type:`dmx_input` >> >> > >> >> > -# dmx_source_t symbols >> >> > -replace enum dmx_source :c:type:`dmx_source` >> >> > -replace symbol DMX_SOURCE_FRONT0 :c:type:`dmx_source` >> >> > -replace symbol DMX_SOURCE_FRONT1 :c:type:`dmx_source` >> >> > -replace symbol DMX_SOURCE_FRONT2 :c:type:`dmx_source` >> >> > -replace symbol DMX_SOURCE_FRONT3 :c:type:`dmx_source` >> >> > -replace symbol DMX_SOURCE_DVR0 :c:type:`dmx_source` >> >> > -replace symbol DMX_SOURCE_DVR1 :c:type:`dmx_source` >> >> > -replace symbol DMX_SOURCE_DVR2 :c:type:`dmx_source` >> >> > -replace symbol DMX_SOURCE_DVR3 :c:type:`dmx_source` >> >> > - >> >> > - >> >> > # Flags for struct dmx_sct_filter_params >> >> > replace define DMX_CHECK_CRC :c:type:`dmx_sct_filter_params` >> >> > replace define DMX_ONESHOT :c:type:`dmx_sct_filter_params` >> >> > @@ -61,4 +49,3 @@ replace define DMX_IMMEDIATE_START >> >> > :c:type:`dmx_sct_filter_params` >> >> > replace typedef dmx_filter_t :c:type:`dmx_filter` >> >> > replace typedef dmx_pes_type_t :c:type:`dmx_pes_type` >> >> > replace typedef dmx_input_t :c:type:`dmx_input` >> >> > -replace typedef dmx_source_t :c:type:`dmx_source` >> >> > diff --git a/Documentation/media/uapi/dvb/dmx-set-source.rst >> >> > b/Documentation/media/uapi/dvb/dmx-set-source.rst >> >> > deleted file mode 100644 >> >> > index ac7f77b25e06.. >> >> > --- a/Documentation/media/uapi/dvb/dmx-set-source.rst >> >> > +++ /dev/null >> >> > @@ -1,44 +0,0 @@ >> >> > -.. -*- coding: utf-8; mode: rst -*- >> >> > - >> >> > -.. _DMX_SET_SOURCE: >> >> > - >> >> > -== >> >> > -DMX_SET_SOURCE >> >> > -== >> >> > - >> >> > -Name >> >> > - >> >> > - >> >> > -DMX_SET_SOURCE >> >> > - >> >> > - >> >> > -Synopsis >> >> > - >> >> > - >> >> > -.. c:function:: int ioctl(fd, DMX_SET_SOURCE, struct dmx_source *src) >> >> > -:name: DMX_SET_SOURCE >> >> > - >> >> > - >> >> > -Arguments >> >> > -- >> >> > - >> >> > - >> >> > -``fd`` >> >> > -File descriptor returned by :c:func:`open() `. >> >> > - >> >> > -``src`` >> >> > - Undocumented. >> >> > - >> >> > - >> >> > -Description >> >> > >> >> > - >> >> > -.. n
Re: [PATCH v2 00/26] Improve DVB documentation and reduce its gap
> There is still a gap at the CA API, as there are three ioctls that are used
> only by a few drivers and whose structs are not properly documented:
> CA_GET_MSG, CA_SEND_MSG and CA_SET_DESCR.
>
> The first two ones seem to be related to a way that a few drivers
> provide to send/receive messages.
I never seen usage of such R/W ioctls, all drivers I have access to
are using read()/write() variant of communication.
Yet, I was unable to get what
> "index" and "type" means on those ioctls. The CA_SET_DESCR is
> only supported by av7110 driver, and has an even weirder
> undocumented struct. I was unable to discover at the Kernel, VDR
> or Kaffeine how those structs are filled. I suspect that there's
> something wrong there, but I won't risk trying to fix without
> knowing more about them. So, let's just document that those
> are needing documentation :-)
>
1) #define CA_SET_DESCR _IOW('o', 134, ca_descr_t)
CA_SET_DESCR is used for feeding descrambler device
with correct keys (called here "control words") what
allows to get services unscrambled.
The best docu is:
"Digital Video Broadcasting (DVB);
Support for use of the DVB Scrambling Algorithm version 3
within digital broadcasting systems"
Defined as DVB Document A125 and publicly
available here:
https://www.dvb.org/resources/public/standards/a125_dvb-csa3.pdf
typedef struct ca_descr {
unsigned int index;
unsigned int parity;/* 0 == even, 1 == odd */
unsigned char cw[8];
} ca_descr_t;
The 'index' is adress of the descrambler instance, as there exist
limited number of them (retieved by CA_GET_DESCR_INFO).
See below:
2) #define CA_SET_PID_IOW('o', 135, ca_pid_t)
===
The second ioctl was used to link particular PID with particular
descrambler, what means that all such pids (you are allowed
to create n-to-1 link), can be descrambled by one descrambler.
This is needed in case of multiservice descrambling, when
usually exist one key (control word) per one service (so all PIDs
for one service have to be linked with one descrambler)
Without this ioctl there is no way to address particular
descrambler and so no way to use more then ONE descrambler
per demux
/Honza
Re: [PATCH v2 00/26] Improve DVB documentation and reduce its gap
> There is still a gap at the CA API, as there are three ioctls that are used > only by a few drivers and whose structs are not properly documented: > CA_GET_MSG, CA_SEND_MSG and CA_SET_DESCR. > > The first two ones seem to be related to a way that a few drivers > provide to send/receive messages. Yet, I was unable to get what > "index" and "type" means on those ioctls. The CA_SET_DESCR is > only supported by av7110 driver, and has an even weirder > undocumented struct. I was unable to discover at the Kernel, VDR > or Kaffeine how those structs are filled. I suspect that there's > something wrong there, but I won't risk trying to fix without > knowing more about them. So, let's just document that those > are needing documentation :-) > BTW, I just remembered dvblast app, part of videolan.org: http://www.videolan.org/projects/dvblast.html which is using CA_GET_MSG/CA_SEND_MSG: https://code.videolan.org/videolan/dvblast/blob/master/en50221.c /Honza
Re: [PATCH v2 00/26] Improve DVB documentation and reduce its gap
2017-09-04 2:54 GMT+02:00 Mauro Carvalho Chehab :
> Em Sun, 3 Sep 2017 22:05:23 +0200
> Honza Petrouš escreveu:
>
>> 1) #define CA_SET_DESCR _IOW('o', 134, ca_descr_t)
>>
>>
>> CA_SET_DESCR is used for feeding descrambler device
>> with correct keys (called here "control words") what
>> allows to get services unscrambled.
>>
>> The best docu is:
>>
>> "Digital Video Broadcasting (DVB);
>> Support for use of the DVB Scrambling Algorithm version 3
>> within digital broadcasting systems"
>>
>> Defined as DVB Document A125 and publicly
>> available here:
>>
>> https://www.dvb.org/resources/public/standards/a125_dvb-csa3.pdf
>>
>>
>> typedef struct ca_descr {
>> unsigned int index;
>> unsigned int parity;/* 0 == even, 1 == odd */
>> unsigned char cw[8];
>> } ca_descr_t;
>>
>> The 'index' is adress of the descrambler instance, as there exist
>> limited number of them (retieved by CA_GET_DESCR_INFO).
>
> Thanks for the info. If I understood well, the enclosed patch should
> be documenting it.
>
>
> Thanks,
> Mauro
>
> [PATCH] media: ca docs: document CA_SET_DESCR ioctl and structs
>
> The av7110 driver uses CA_SET_DESCR to store the descrambler
> control words at the CA descrambler slots.
>
> Document it.
>
> Thanks-to: Honza Petrouš
> Signed-off-by: Mauro Carvalho Chehab
>
> diff --git a/Documentation/media/uapi/dvb/ca-set-descr.rst
> b/Documentation/media/uapi/dvb/ca-set-descr.rst
> index 9c484317d55c..a6c47205ffd8 100644
> --- a/Documentation/media/uapi/dvb/ca-set-descr.rst
> +++ b/Documentation/media/uapi/dvb/ca-set-descr.rst
> @@ -28,22 +28,11 @@ Arguments
> ``msg``
>Pointer to struct :c:type:`ca_descr`.
>
> -.. c:type:: ca_descr
> -
> -.. code-block:: c
> -
> -struct ca_descr {
> - unsigned int index;
> - unsigned int parity;
> - unsigned char cw[8];
> -};
> -
> -
> Description
> ---
>
> -.. note:: This ioctl is undocumented. Documentation is welcome.
> -
> +CA_SET_DESCR is used for feeding descrambler CA slots with descrambling
> +keys (refered as control words).
>
> Return Value
>
> diff --git a/include/uapi/linux/dvb/ca.h b/include/uapi/linux/dvb/ca.h
> index f66ed53f4dc7..a62ddf0cebcd 100644
> --- a/include/uapi/linux/dvb/ca.h
> +++ b/include/uapi/linux/dvb/ca.h
> @@ -109,9 +109,16 @@ struct ca_msg {
> unsigned char msg[256];
> };
>
> +/**
> + * struct ca_descr - CA descrambler control words info
> + *
> + * @index: CA Descrambler slot
> + * @parity: control words parity, where 0 means even and 1 means odd
> + * @cw: CA Descrambler control words
> + */
> struct ca_descr {
> unsigned int index;
> - unsigned int parity;/* 0 == even, 1 == odd */
> + unsigned int parity;
> unsigned char cw[8];
> };
>
>
Yeh, it should be that way.
BTW, the only issue I have in mind is how to link particular
descrambler with the PID
after your removal of the CA_SET_PID. And yes, I know that currently we have
no any user of such ioctl in our driver base :)
/Honza
Re: [PATCH v2 00/26] Improve DVB documentation and reduce its gap
2017-09-04 11:06 GMT+02:00 Mauro Carvalho Chehab :
> Em Mon, 4 Sep 2017 09:12:49 +0200
> Honza Petrouš escreveu:
>
>> 2017-09-04 2:54 GMT+02:00 Mauro Carvalho Chehab :
>> > Em Sun, 3 Sep 2017 22:05:23 +0200
>> > Honza Petrouš escreveu:
>> >
>> >> 1) #define CA_SET_DESCR _IOW('o', 134, ca_descr_t)
>> >>
>> >>
>> >> CA_SET_DESCR is used for feeding descrambler device
>> >> with correct keys (called here "control words") what
>> >> allows to get services unscrambled.
>> >>
>> >> The best docu is:
>> >>
>> >> "Digital Video Broadcasting (DVB);
>> >> Support for use of the DVB Scrambling Algorithm version 3
>> >> within digital broadcasting systems"
>> >>
>> >> Defined as DVB Document A125 and publicly
>> >> available here:
>> >>
>> >> https://www.dvb.org/resources/public/standards/a125_dvb-csa3.pdf
>> >>
>> >>
>> >> typedef struct ca_descr {
>> >> unsigned int index;
>> >> unsigned int parity;/* 0 == even, 1 == odd */
>> >> unsigned char cw[8];
>> >> } ca_descr_t;
>> >>
>> >> The 'index' is adress of the descrambler instance, as there exist
>> >> limited number of them (retieved by CA_GET_DESCR_INFO).
>> >
>> > Thanks for the info. If I understood well, the enclosed patch should
>> > be documenting it.
>> >
>> >
>> > Thanks,
>> > Mauro
>> >
>> > [PATCH] media: ca docs: document CA_SET_DESCR ioctl and structs
>> >
>> > The av7110 driver uses CA_SET_DESCR to store the descrambler
>> > control words at the CA descrambler slots.
>> >
>> > Document it.
>> >
>> > Thanks-to: Honza Petrouš
>> > Signed-off-by: Mauro Carvalho Chehab
>> >
>> > diff --git a/Documentation/media/uapi/dvb/ca-set-descr.rst
>> > b/Documentation/media/uapi/dvb/ca-set-descr.rst
>> > index 9c484317d55c..a6c47205ffd8 100644
>> > --- a/Documentation/media/uapi/dvb/ca-set-descr.rst
>> > +++ b/Documentation/media/uapi/dvb/ca-set-descr.rst
>> > @@ -28,22 +28,11 @@ Arguments
>> > ``msg``
>> >Pointer to struct :c:type:`ca_descr`.
>> >
>> > -.. c:type:: ca_descr
>> > -
>> > -.. code-block:: c
>> > -
>> > -struct ca_descr {
>> > - unsigned int index;
>> > - unsigned int parity;
>> > - unsigned char cw[8];
>> > -};
>> > -
>> > -
>> > Description
>> > ---
>> >
>> > -.. note:: This ioctl is undocumented. Documentation is welcome.
>> > -
>> > +CA_SET_DESCR is used for feeding descrambler CA slots with descrambling
>> > +keys (refered as control words).
>> >
>> > Return Value
>> >
>> > diff --git a/include/uapi/linux/dvb/ca.h b/include/uapi/linux/dvb/ca.h
>> > index f66ed53f4dc7..a62ddf0cebcd 100644
>> > --- a/include/uapi/linux/dvb/ca.h
>> > +++ b/include/uapi/linux/dvb/ca.h
>> > @@ -109,9 +109,16 @@ struct ca_msg {
>> > unsigned char msg[256];
>> > };
>> >
>> > +/**
>> > + * struct ca_descr - CA descrambler control words info
>> > + *
>> > + * @index: CA Descrambler slot
>> > + * @parity: control words parity, where 0 means even and 1 means odd
>> > + * @cw: CA Descrambler control words
>> > + */
>> > struct ca_descr {
>> > unsigned int index;
>> > - unsigned int parity;/* 0 == even, 1 == odd */
>> > + unsigned int parity;
>> > unsigned char cw[8];
>> > };
>> >
>> >
>>
>> Yeh, it should be that way.
>
> Good! I'll add this patch to the series.
>
>> BTW, the only issue I have in mind is how to link particular
>> descrambler with the PID
>> after your removal of the CA_SET_PID. And yes, I know that currently we have
>> no any user of such ioctl in our driver base :)
>
> Well, I don't think that an ioctl like CA_SET_PID would solve it.
>
> On a generic case with is quite common nowadays on embedded hardware,
> We have K demods and M CIs (where K may be different than M).
>
> Also, You may need to route N PIDs to O descramblers.
TBH that is exactly most common use-case = most Digit
Re: [RESEND PATCH v3] UBI: add debugfs file for tracking PEB state
2017-05-16 20:22 GMT+02:00 Richard Weinberger : > Zach, > > Am 16.05.2017 um 19:58 schrieb Zach Brown: >> From: Ben Shelton >> >> Add a file under debugfs to allow easy access to the erase count for >> each physical erase block on an UBI device. This is useful when >> debugging data integrity issues with UBIFS on NAND flash devices. >> >> Signed-off-by: Ben Shelton >> Signed-off-by: Zach Brown > > Hmmm, I thought I applied this to my v4.12 queue, but seems > like I didn't. So, it will be part of v4.13. > I'm very sorry, please accept my apologies. Yes, you did it - at least my Linus' github repo clone has it already = 7bccd12d27b7e358823feb5429731b8ee698b173 /Honza
Re: [PATCH v4 02/12] [media] cxd2880-spi: Add support for CXD2880 SPI interface
Hi Yasunari
2017-10-13 7:59 GMT+02:00 :
> From: Yasunari Takiguchi
>
> This is the SPI adapter part of the driver for the
> Sony CXD2880 DVB-T2/T tuner + demodulator.
>
[...]
> +static const struct of_device_id cxd2880_spi_of_match[] = {
> + { .compatible = "sony,cxd2880" },
> + { /* sentinel */ }
> +};
> +
> +MODULE_DEVICE_TABLE(of, cxd2880_spi_of_match);
> +
> +static int
> +cxd2880_spi_probe(struct spi_device *spi)
> +{
> + int ret;
> + struct cxd2880_dvb_spi *dvb_spi = NULL;
> + struct cxd2880_config config;
> +
> + if (!spi) {
> + pr_err("invalid arg.\n");
> + return -EINVAL;
> + }
> +
> + dvb_spi = kzalloc(sizeof(struct cxd2880_dvb_spi), GFP_KERNEL);
> + if (!dvb_spi)
> + return -ENOMEM;
> +
> + dvb_spi->spi = spi;
> + mutex_init(&dvb_spi->spi_mutex);
> + dev_set_drvdata(&spi->dev, dvb_spi);
> + config.spi = spi;
> + config.spi_mutex = &dvb_spi->spi_mutex;
> +
> + ret = dvb_register_adapter(&dvb_spi->adapter,
> + "CXD2880",
> + THIS_MODULE,
> + &spi->dev,
> + adapter_nr);
> + if (ret < 0) {
> + pr_err("dvb_register_adapter() failed\n");
> + goto fail_adapter;
> + }
> +
> + if (!dvb_attach(cxd2880_attach, &dvb_spi->dvb_fe, &config)) {
> + pr_err("cxd2880_attach failed\n");
> + goto fail_attach;
> + }
> +
> + ret = dvb_register_frontend(&dvb_spi->adapter,
> + &dvb_spi->dvb_fe);
> + if (ret < 0) {
> + pr_err("dvb_register_frontend() failed\n");
> + goto fail_frontend;
> + }
> +
> + dvb_spi->demux.dmx.capabilities = DMX_TS_FILTERING;
> + dvb_spi->demux.priv = dvb_spi;
> + dvb_spi->demux.filternum = CXD2880_MAX_FILTER_SIZE;
> + dvb_spi->demux.feednum = CXD2880_MAX_FILTER_SIZE;
> + dvb_spi->demux.start_feed = cxd2880_start_feed;
> + dvb_spi->demux.stop_feed = cxd2880_stop_feed;
> +
> + ret = dvb_dmx_init(&dvb_spi->demux);
> + if (ret < 0) {
> + pr_err("dvb_dmx_init() failed\n");
> + goto fail_dmx;
> + }
> +
> + dvb_spi->dmxdev.filternum = CXD2880_MAX_FILTER_SIZE;
> + dvb_spi->dmxdev.demux = &dvb_spi->demux.dmx;
> + dvb_spi->dmxdev.capabilities = 0;
> + ret = dvb_dmxdev_init(&dvb_spi->dmxdev,
> + &dvb_spi->adapter);
> + if (ret < 0) {
> + pr_err("dvb_dmxdev_init() failed\n");
> + goto fail_dmxdev;
> + }
> +
> + dvb_spi->dmx_fe.source = DMX_FRONTEND_0;
> + ret = dvb_spi->demux.dmx.add_frontend(&dvb_spi->demux.dmx,
> + &dvb_spi->dmx_fe);
> + if (ret < 0) {
> + pr_err("add_frontend() failed\n");
> + goto fail_dmx_fe;
> + }
> +
> + ret = dvb_spi->demux.dmx.connect_frontend(&dvb_spi->demux.dmx,
> + &dvb_spi->dmx_fe);
> + if (ret < 0) {
> + pr_err("dvb_register_frontend() failed\n");
> + goto fail_fe_conn;
> + }
> +
> + pr_info("Sony CXD2880 has successfully attached.\n");
> +
> + return 0;
> +
> +fail_fe_conn:
> + dvb_spi->demux.dmx.remove_frontend(&dvb_spi->demux.dmx,
> + &dvb_spi->dmx_fe);
> +fail_dmx_fe:
> + dvb_dmxdev_release(&dvb_spi->dmxdev);
> +fail_dmxdev:
> + dvb_dmx_release(&dvb_spi->demux);
> +fail_dmx:
> + dvb_unregister_frontend(&dvb_spi->dvb_fe);
> +fail_frontend:
> + dvb_frontend_detach(&dvb_spi->dvb_fe);
> +fail_attach:
> + dvb_unregister_adapter(&dvb_spi->adapter);
> +fail_adapter:
> + kfree(dvb_spi);
> + return ret;
> +}
> +
> +static int
> +cxd2880_spi_remove(struct spi_device *spi)
> +{
> + struct cxd2880_dvb_spi *dvb_spi;
> +
> + if (!spi) {
> + pr_err("invalid arg\n");
> + return -EINVAL;
> + }
> +
> + dvb_spi = dev_get_drvdata(&spi->dev);
> +
> + if (!dvb_spi) {
> + pr_err("failed\n");
> + return -EINVAL;
> + }
> + dvb_spi->demux.dmx.remove_frontend(&dvb_spi->demux.dmx,
> + &dvb_spi->dmx_fe);
> + dvb_dmxdev_release(&dvb_spi->dmxdev);
> + dvb_dmx_release(&dvb_spi->demux);
> + dvb_unregister_frontend(&dvb_spi->dvb_fe);
> + dvb_frontend_detach(&dvb_spi->dvb_fe);
> + dvb_unregister_adapter(&dvb_spi->adapter);
> +
> + kfree(dvb_spi);
> + pr_info("cxd2880_spi remove ok.\n");
> +
> + return 0;
> +}
> +
> +static const struct spi_device_id cxd2880_spi_id[] = {
> + { "cxd2880", 0 },
> + { /* sentinel */ }
> +};
> +MODULE_DEVIC
Re: [PATCH v4 02/12] [media] cxd2880-spi: Add support for CXD2880 SPI interface
Hi Takiguchi, >> If I understand it right, it uses SPI bus also for passing transport stream >> to the host system (also having some pid piltering inside!), isn't it? >> It would be interesting to know what is the max throughput of the CXD's SPI? > > Yes, max clock rate of spi is written in sony-cxd2880.txt of [patch v4 01/12]. > > spi-max-frequency = <5500>; /* 55MHz */ Ehh, I overlooked this! Thanks for pointing me out. BTW, is there any device, preferable some devboard with this silicon on the market? /Honza
