Re: [PATCH 00/15] Improve DVB documentation and reduce its gap

[Soeren Moch]

On 04.09.2017 13:29, Mauro Carvalho Chehab wrote:
> Em Mon, 4 Sep 2017 02:55:15 +0200
> Soeren Moch  escreveu:
>
>> Hi Mauro,
>>
>> On 01.09.2017 11:32, Mauro Carvalho Chehab wrote:
>>> Em Fri, 1 Sep 2017 10:40:28 +0200
>>> Honza Petrouš  escreveu:
>>>  
 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.
>
>> av7110 cards may be old, but there are still users of these cards. 
>> For instance I'm watching TV received and decoded with such card in this 
>> moment.
>> So what do you mean with "deprecated hardware"?
> Nobody is telling otherwise. What I mean by "deprecated" is that it is
> not a product that you could got to a shop and buy a new one. Its 
> production stopped a long time ago.
>
 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.  
>>> Yeah, av7110 made history. Please notice that this series doesn't
>>> remove any API that it is used by it. All it removes are the APIs
>>> that there's no Kernel driver using.
>>>
>>> Carry on APIs without client is usually a very bad idea, as nobody
>>> could be certain about how to use it. It is even worse when such
>>> APIs are not properly documented (with is the case here).
>>>  
 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(*)  
>>> We have one driver for a SoC DVB hardware at:
>>> drivers/media/platform/sti/c8sectpfe/
>>>
>>> I guess it still doesn't cover the entire SoC, but this is a WiP. If I
>>> remember well, at the midia part of the SoC, they started by submitting
>>> the Remote Controller code.
>>>  
 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.  
>>> Re-adding the removed bits is easy. However, the API defined for
>>> av7110 is old and it is showing its age: it assumes a limited number
>>> of possible inputs/outputs. Modern SoC has a lot more ways link the
>>> audio/video IP blocks than what the API provides. On a modern SoC,
>>> not only DVB is supported, but also analog inputs (to support things
>>> like composite input), cameras, HDMI inputs and even analog TV.
>>> All of them interconnected to a media ISP. The current FF API can't
>>> represent such hardware.
>>>
>>> The best API to represent those pipelines that exist on SoC for
>>> multimedia is the media controller, where all IP blocks and their
>>> links (whatever they are) can be represented, if needed.
>>>
>>> The audio and video DVB API is also too limited: it hasn't
>>> evolved since when it was added. For audio, the ALSA API
>>> allows a way more control of the hardware; for video, the
>>> V4L2 API nowadays has all the bits to control video decoding
>>> and encoding. Both APIs provide support for audio and video
>>> inputs commonly found on those devices.  
>> The real advantage of the DVB audio/video/osd API is the possibility
>> of frame synchronous audio/video/overlay output for high-quality
>> audio/video playback, maybe with picture-in-picture functionality.
>>
>> Especially audio synchronization is not easy when the audio format
>> changes from compressed audio (e.g. AC-3) to PCM (stereo), e.g. on
>> HDMI output. While HDMI output hardware usually takes video frames and
>> audio packets (and AVI info frames for 

Re: [PATCH 00/15] Improve DVB documentation and reduce its gap

[Mauro Carvalho Chehab]

Em Mon, 4 Sep 2017 02:55:15 +0200
Soeren Moch  escreveu:

> Hi Mauro,
> 
> On 01.09.2017 11:32, Mauro Carvalho Chehab wrote:
> > Em Fri, 1 Sep 2017 10:40:28 +0200
> > Honza Petrouš  escreveu:
> >  
> >> 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.
> >>>
> av7110 cards may be old, but there are still users of these cards. 
> For instance I'm watching TV received and decoded with such card in this 
> moment.
> So what do you mean with "deprecated hardware"?

Nobody is telling otherwise. What I mean by "deprecated" is that it is
not a product that you could got to a shop and buy a new one. Its 
production stopped a long time ago.

> >> 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.  
> > Yeah, av7110 made history. Please notice that this series doesn't
> > remove any API that it is used by it. All it removes are the APIs
> > that there's no Kernel driver using.
> >
> > Carry on APIs without client is usually a very bad idea, as nobody
> > could be certain about how to use it. It is even worse when such
> > APIs are not properly documented (with is the case here).
> >  
> >> 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(*)  
> > We have one driver for a SoC DVB hardware at:
> > drivers/media/platform/sti/c8sectpfe/
> >
> > I guess it still doesn't cover the entire SoC, but this is a WiP. If I
> > remember well, at the midia part of the SoC, they started by submitting
> > the Remote Controller code.
> >  
> >> 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.  
> > Re-adding the removed bits is easy. However, the API defined for
> > av7110 is old and it is showing its age: it assumes a limited number
> > of possible inputs/outputs. Modern SoC has a lot more ways link the
> > audio/video IP blocks than what the API provides. On a modern SoC,
> > not only DVB is supported, but also analog inputs (to support things
> > like composite input), cameras, HDMI inputs and even analog TV.
> > All of them interconnected to a media ISP. The current FF API can't
> > represent such hardware.
> >
> > The best API to represent those pipelines that exist on SoC for
> > multimedia is the media controller, where all IP blocks and their
> > links (whatever they are) can be represented, if needed.
> >
> > The audio and video DVB API is also too limited: it hasn't
> > evolved since when it was added. For audio, the ALSA API
> > allows a way more control of the hardware; for video, the
> > V4L2 API nowadays has all the bits to control video decoding
> > and encoding. Both APIs provide support for audio and video
> > inputs commonly found on those devices.  
> The real advantage of the DVB audio/video/osd API is the possibility
> of frame synchronous audio/video/overlay output for high-quality
> audio/video playback, maybe with picture-in-picture functionality.
> 
> Especially audio synchronization is not easy when the audio format
> changes from compressed audio (e.g. AC-3) to PCM (stereo), e.g. on
> HDMI output. While HDMI output hardware usually takes video frames and
> audio packets (and AVI info frames for audio/video format signalization)
> synchronously, V4L2 and ALSA rip these 

Re: [PATCH 00/15] Improve DVB documentation and reduce its gap

[Soeren Moch]

Hi Mauro,

On 01.09.2017 11:32, Mauro Carvalho Chehab wrote:
> Em Fri, 1 Sep 2017 10:40:28 +0200
> Honza Petrouš  escreveu:
>
>> 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.
>>>  
av7110 cards may be old, but there are still users of these cards. For
instance I'm watching TV received and decoded with such card in this moment.
So what do you mean with "deprecated hardware"?
>> 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.
> Yeah, av7110 made history. Please notice that this series doesn't
> remove any API that it is used by it. All it removes are the APIs
> that there's no Kernel driver using.
>
> Carry on APIs without client is usually a very bad idea, as nobody
> could be certain about how to use it. It is even worse when such
> APIs are not properly documented (with is the case here).
>
>> 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(*)
> We have one driver for a SoC DVB hardware at:
>   drivers/media/platform/sti/c8sectpfe/
>
> I guess it still doesn't cover the entire SoC, but this is a WiP. If I
> remember well, at the midia part of the SoC, they started by submitting
> the Remote Controller code.
>
>> 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.
> Re-adding the removed bits is easy. However, the API defined for
> av7110 is old and it is showing its age: it assumes a limited number
> of possible inputs/outputs. Modern SoC has a lot more ways link the
> audio/video IP blocks than what the API provides. On a modern SoC,
> not only DVB is supported, but also analog inputs (to support things
> like composite input), cameras, HDMI inputs and even analog TV.
> All of them interconnected to a media ISP. The current FF API can't
> represent such hardware.
>
> The best API to represent those pipelines that exist on SoC for
> multimedia is the media controller, where all IP blocks and their
> links (whatever they are) can be represented, if needed.
>
> The audio and video DVB API is also too limited: it hasn't
> evolved since when it was added. For audio, the ALSA API
> allows a way more control of the hardware; for video, the
> V4L2 API nowadays has all the bits to control video decoding
> and encoding. Both APIs provide support for audio and video
> inputs commonly found on those devices.
The real advantage of the DVB audio/video/osd API is the possibility
of frame synchronous audio/video/overlay output for high-quality
audio/video playback, maybe with picture-in-picture functionality.

Especially audio synchronization is not easy when the audio format
changes from compressed audio (e.g. AC-3) to PCM (stereo), e.g. on
HDMI output. While HDMI output hardware usually takes video frames and
audio packets (and AVI info frames for audio/video format signalization)
synchronously, V4L2 and ALSA rip these data blocks apart and push these
through different pipelines with different buffering properties. This
makes it very difficult for userspace applications. With the DVB API
the hardware takes care of the synchronisation.
> Also, nowadays, video decoding usually happens at the GPU on SoC. So, 
> in practice, a SoC FF would likely use the DRM subsystem to control the
> video codecs.
I think this is a common misunderstanding. Video is decoded on separate
hardware 

Re: [PATCH 00/15] Improve DVB documentation and reduce its gap

[Mauro Carvalho Chehab]

Em Fri, 1 Sep 2017 10:40:28 +0200
Honza Petrouš  escreveu:

> 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.

Yeah, av7110 made history. Please notice that this series doesn't
remove any API that it is used by it. All it removes are the APIs
that there's no Kernel driver using.

Carry on APIs without client is usually a very bad idea, as nobody
could be certain about how to use it. It is even worse when such
APIs are not properly documented (with is the case here).

> 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(*)

We have one driver for a SoC DVB hardware at:
drivers/media/platform/sti/c8sectpfe/

I guess it still doesn't cover the entire SoC, but this is a WiP. If I
remember well, at the midia part of the SoC, they started by submitting
the Remote Controller code.

> 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.

Re-adding the removed bits is easy. However, the API defined for
av7110 is old and it is showing its age: it assumes a limited number
of possible inputs/outputs. Modern SoC has a lot more ways link the
audio/video IP blocks than what the API provides. On a modern SoC,
not only DVB is supported, but also analog inputs (to support things
like composite input), cameras, HDMI inputs and even analog TV.
All of them interconnected to a media ISP. The current FF API can't
represent such hardware.

The best API to represent those pipelines that exist on SoC for
multimedia is the media controller, where all IP blocks and their
links (whatever they are) can be represented, if needed.

The audio and video DVB API is also too limited: it hasn't
evolved since when it was added. For audio, the ALSA API
allows a way more control of the hardware; for video, the
V4L2 API nowadays has all the bits to control video decoding
and encoding. Both APIs provide support for audio and video
inputs commonly found on those devices.

Also, nowadays, video decoding usually happens at the GPU on SoC. So, 
in practice, a SoC FF would likely use the DRM subsystem to control the
video codecs.

So, anyone wanting to upstream drivers for a modern FF hardware would need
to touch a lot inside the DVB API, for it to cover all the needs. A more
appropriate approach to support those devices would be, instead, 
to use a set of APIs: DVB, V4L2, ALSA, RC, CEC, MC, DRM.

> 
> 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.

Thanks,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/15] Improve DVB documentation and reduce its gap

[Honza Petrouš]

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 00/15] Improve DVB documentation and reduce its gap

[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.

Mauro Carvalho Chehab (15):
  media: dvb/intro: use the term Digital TV to refer to the system
  media: dvb/intro: update references for TV standards
  media: dvb/intro: update the history part of the document
  media: dvb/intro: adjust the notices about optional hardware
  media: dvb/frontend.h: move out a private internal structure
  media: dvb/frontend.h: document the uAPI file
  media: dvb frontend docs: use kernel-doc documentation
  media: fe_property_parameters.rst: better define properties usage
  media: fe_property_parameters.rst: better document bandwidth
  media: dmx.h: get rid of unused DMX_KERNEL_CLIENT
  media: dmx.h: get rid of DMX_GET_CAPS
  media: dmx.h: get rid of DMX_SET_SOURCE
  media: dmx.h: get rid of GET_DMX_EVENT
  media: dmx.h: add kernel-doc markups and use it at Documentation/
  media: net.rst: Fix the level of a section of the net chapter

 Documentation/media/dmx.h.rst.exceptions   |   20 +-
 Documentation/media/frontend.h.rst.exceptions  |  185 ++-
 Documentation/media/uapi/dvb/dmx-get-caps.rst  |   41 -
 Documentation/media/uapi/dvb/dmx-get-event.rst |   60 -
 Documentation/media/uapi/dvb/dmx-set-source.rst|   44 -
 Documentation/media/uapi/dvb/dmx_fcalls.rst|3 -
 Documentation/media/uapi/dvb/dmx_types.rst |  225 +---
 Documentation/media/uapi/dvb/dtv-fe-stats.rst  |   17 -
 Documentation/media/uapi/dvb/dtv-properties.rst|   15 -
 Documentation/media/uapi/dvb/dtv-property.rst  |   31 -
 Documentation/media/uapi/dvb/dtv-stats.rst |   18 -
 Documentation/media/uapi/dvb/dvbproperty-006.rst   |   12 -
 Documentation/media/uapi/dvb/dvbproperty.rst   |   28 +-
 .../media/uapi/dvb/fe-diseqc-recv-slave-reply.rst  |   40 +-
 .../media/uapi/dvb/fe-diseqc-send-burst.rst|   31 +-
 .../media/uapi/dvb/fe-diseqc-send-master-cmd.rst   |   29 +-
 Documentation/media/uapi/dvb/fe-get-info.rst   |  370 +-
 Documentation/media/uapi/dvb/fe-get-property.rst   |2 +-
 Documentation/media/uapi/dvb/fe-read-status.rst|   83 --
 Documentation/media/uapi/dvb/fe-set-tone.rst   |   30 -
 .../media/uapi/dvb/fe_property_parameters.rst  | 1383 +++-
 Documentation/media/uapi/dvb/frontend-header.rst   |4 +
 Documentation/media/uapi/dvb/intro.rst |   76 +-
 Documentation/media/uapi/dvb/net.rst   |1 -
 drivers/media/dvb-core/dvb_frontend.c  |   11 +
 include/uapi/linux/dvb/dmx.h   |  171 ++-
 include/uapi/linux/dvb/frontend.h  |  589 +++--
 27 files changed, 1082 insertions(+), 2437 deletions(-)
 delete mode 100644 Documentation/media/uapi/dvb/dmx-get-caps.rst
 delete mode 100644 Documentation/media/uapi/dvb/dmx-get-event.rst
 delete mode 100644 Documentation/media/uapi/dvb/dmx-set-source.rst
 delete mode 100644 Documentation/media/uapi/dvb/dtv-fe-stats.rst
 delete mode 100644 Documentation/media/uapi/dvb/dtv-properties.rst
 delete mode 100644 Documentation/media/uapi/dvb/dtv-property.rst
 delete mode 100644 Documentation/media/uapi/dvb/dtv-stats.rst
 delete mode 100644 Documentation/media/uapi/dvb/dvbproperty-006.rst
 create mode 100644 Documentation/media/uapi/dvb/frontend-header.rst

-- 
2.13.5


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html