* [GIT PULL] SAA716x DVB driver
@ 2017-07-16 18:34 Soeren Moch
2017-07-20 10:49 ` Mauro Carvalho Chehab
` (2 more replies)
0 siblings, 3 replies; 26+ messages in thread
From: Soeren Moch @ 2017-07-16 18:34 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Greg Kroah-Hartman, Andreas Regel, Manu Abraham, Oliver Endriss,
Soeren Moch, linux-media
This is a driver for DVB cards based on the SAA7160/62 PCIe bridges from
Philips/NXP. The most important of these cards, at least for me, is the
TechnoTrend S2-6400, a high-definition full-featured DVB-S2 card, the
successor of the famous ttpci decoder cards. Other supported cards are:
Avermedia H788
Avermedia HC82 Express-54
KNC One Dual S2
KWorld DVB-T PE310
Technisat SkyStar 2 eXpress HD
Twinhan/Azurewave VP-1028
Twinhan/Azurewave VP-3071
Twinhan/Azurewave VP-6002
Twinhan/Azurewave VP-6090
The driver is taken from [1] with adaptations for current mainline,
converted to git and moved to drivers/staging/media. See TODO for
required cleanups (from my point of view, maybe more to come from
additional code review by other developers). I added myself as driver
maintainer to document my commitment to further development to get this
out of staging, help from others welcome.
This driver was licensed "GPL" from the beginning. S2-6400 firmware is
available at [2].
I want to preserve the development history of the driver, since this
is mainly work of Andreas Regel, Manu Abraham, and Oliver Endriss.
Unfortunately Andreas seems not to take care of this driver anymore, he
also did not answer my requests to integrate patches for newer kernel
versions. So I send this upstream.
With all the history this is a 280 part patch series, so I send this as
pull request. Of course I can also send this as 'git send-email' series
if desired.
Since this is intended for staging, I hope this can be pulled quickly and
fixed up in mainline. For all patches I added SOBs, the series should not
hurt kernel bisectibility since the driver is hooked up in Kconfig at the
end of this series.
Regards,
Soeren
[1] https://bitbucket.org/powARman/v4l-dvb-saa716x/
[2] http://www.aregel.de/downloads/
The following changes since commit 5771a8c08880cdca3bfb4a3fc6d309d6bba20877:
Linux v4.13-rc1 (2017-07-15 15:22:10 -0700)
are available in the git repository at:
https://github.com/s-moch/linux-saa716x for-media
for you to fetch changes up to 1a9e44df11d702b9f569605e60c7cf8e05923178:
saa716x: Add MAINTAINERS entry (2017-07-16 15:37:00 +0200)
----------------------------------------------------------------
Andreas Regel (127):
saa716x: Simplified the code for I2C transfers.
saa716x: Transport stream ports can be configured now.
saa716x_ff: Disable frontend support through STi7109 firmware.
saa716x_ff: Initialize the frontend of the TT S2-6400.
saa716x_ff: Add VIDEO_GET_PTS ioctl.
saa716x_ff: Add audio device for TT S2-6400.
saa716x_ff: Use separate interrupts for OSD commands.
saa716x_ff: Use third TS input of the STi7109 for playback
saa716x_ff: Set error code when boot of firmware failed.
saa716x_ff: Added 10ms sleep after configuring the FPGA.
saa716x: Reduce compiler warnings
saa716x: fix kernel oops caused by missing initialisation
saa716x: fixed double frontend detach
saa716x: 1ms is enough when waiting for the PLL
saa716x_ff: Adapted frontend init to latest driver changes.
saa716x: Improve PHI performance by shorten timings a bit.
saa716x_ff: use double buffering for block transfers.
saa716x_ff: Reset block_done after receiving it.
saa716x_ff: add interrupt source for firmware log messages
saa716x_ff: read FPGA version register
saa716x_ff: fixed PTS/STC signed/unsigned issue
saa716x_ff: query and print loader and firmware versions
saa716x: disable debug printk
osd.h: Add const keyword to struct members
saa716x_ff: implement ioctl VIDEO_GET_SIZE
saa716x_ff: support production version of the S2-6400
saa716x: disable OVERFLOW and AV interrupts in FGPI
saa716x_ff: add some FPGA register definitions
saa716x_ff: restart TS capturing in case of non-aligned TS error
saa716x_ff: don't clear FGPI interrupts in IRQ routine.
saa716x: comment out SPI functions that are not needed currently
saa716x: add changes needed for kernel 2.6.36 and up.
saa716x: support building with media_build_experimental
saa716x_ff: use tasklet for FIFO transfer
saa716x: fix not working MSI
saa716x: Disable shared IRQ when using MSI mode.
saa716x_ff: Do an explicit demodulator reset.
saa716x: enable wait for PLL lock when setting clocks of all ports.
saa716x_ff: add counting of interrupts
saa716x: don't set i2c_adapter id field
saa716x_ff: support non-aligned TS data
saa716x_ff: Use a TS clock of 135Mhz instead of 90 Mhz.
saa716x_ff: Ignore false remote events.
saa716x_ff: Fix possible crash in IRQ handler.
saa716x_ff: move firmware command interface code to separate file.
saa716x_ff: Allow to have osd device opened twice.
saa716x_ff: support correct TS mux setting for FPGA 1.10.
saa716x_budget: Add missing GPIO initialization.
saa716x_hybrid: Add missing GPIO initialization.
saa716x_hybrid: fix tuner settings for nemo reference board
saa716x_hybrid: TS capturing on the nemo reference board works.
saa716x_hybrid: Make TS capturing code more generic.
saa716x: remove unused members from struct saa716x_config.
saa716x: Add function saa716x_fgpi_get_write_index.
saa716x_hybrid: Use saa716x_fgpi_get_write_index to simplify code.
saa716x_ff: Use saa716x_fgpi_get_write_index to simplify code.
saa716x: Set maximum number of adapters per saa716x to 4.
saa716x_budget: Add TS capturing code.
saa716x_hybrid: Do some cleanups.
saa716x: remove unused load_config functions.
saa716x_budget: Started with SkyStar 2 eXpress HD.
saa716x_hybrid: Add support for KWorld Dual DVB-T PE310.
saa716x: Fix I2C bus assignment on SAA7160ET.
saa716x: Fix stack corruption when parsing ROM info.
saa716x: Fix memory leak in ROM parsing.
saa716x: Skip unknown device descriptors when parsing the ROM
saa716x: change verbose level for some dprintk
saa716x_ff: Enable now working EEPROM parsing.
saa716x_ff: Add error message when FPGA is not responding.
saa716x_budget: Add frontend attach for the Skystar2 eXpress HD.
saa716x_ff: Reset the frontend on the SkyStar2 eXpress HD.
saa716x_ff: support CEC remote codes.
saa716x: Use interrupts for I2C writes instead of polling.
saa716x: separate I2C reading and writing into two functions.
saa716x_ff: change remote event printk to hexadecimal output.
saa716x: Support buffered I2C transaction using interrupts.
saa716x_ff: Use buffered I2C interrupt mode.
saa716x_ff: Don't use dvb_generic_ioctl.
saa716x_budget: Use GPIO 26 for reset on the Skystar 2 eXpress HD.
saa716x_budget: Use I2C B for accessing the frontend on the Skystar.
saa716x_budget: Get the Skystar 2 eXpress HD to work.
saa716x_budget: Implement LNB power switching for Skystar 2
eXpress HD.
saa716x_ff: Fix memory leak.
saa716x_ff: Fix missing copy user <-> kernel space.
saa716x: FGPI DMA buffer size is passed to saa716x_fgpi_init.
saa716x: Fix FGPI settings for SD video capture.
saa716x: Export some FGPI functions.
saa716x: Remove unused header file.
saa716x: Remove duplicate definition.
saa716x: Make BAM register macros more generic.
saa716x: Use global macros for MMU register access.
saa716x: Add VI module implementation.
saa716x: Support one-shot video capturing.
saa716x_ff: Extend interrupt counters.
saa716x: Change video capture format from YUYV to UYUV.
saa716x_ff: Support capturing digital video coming from STi7109.
saa716x_ff: Protect reading of the captured video with a mutex.
saa716x_ff: Rename functions.
saa716x_ff: video capture refactoring.
saa716x: Use pitch value from stream params when setting FGPI_STRIDE.
saa716x: use offset from stream params instead of fixed value.
saa716x: Clear DMA buffer after allocatiion
saa716x: Support capturing raw data via FGPI unit
saa716x: Reset FGPI read index in saa716x_fgpi_start
saa716x_ff: Cancel data transfer in case of a block timeout
saa716x_ff: print decimal digits for firmware version.
saa716x: include fix for in-kernel build
saa716x: support directory structure of linux-3.7+
saa716x: section mismatch fixes
saa716x: remove __devinit and friends
saa716x: convert fifo_worker tasklet to workqueue
saa716x: TS output buffer cleanup
saa716x: Fix PHI address space offsets, cleanup register definitions.
saa716x: Clean up PHI configuration.
saa716x: Reset PHI on init.
saa716x: Print EEPROM content on DEBUG verbosity only.
saa716x: Fix errors and improve saa716x_set_clk.
saa716x_ff: Fix not setting command result length to 0 per default.
saa716x: move card specific PHI code to saa716x_ff driver
saa716x_ff: use special phi_fifo_write function
saa716x_ff: Add write-combining PCI iomem window for PHI1 access.
saa716x_ff: implement PHI speedup
saa716x: IO memory of upper PHI1 regions is mapped in saa716x_ff
driver.
saa716x_ff: Optimize access to FIFO.
saa716x_ff: Align block data on 32 bytes for firmware 0.5.0 and up
saa716x_ff: Do not return on command ready timeout
saa716x_ff: Usa faster EMI timings only for FPGA version 1.10 and
later
Manu Abraham (137):
saa716x: Initial framework driver to support SAA7160, SAA7161,
SAA7162 chips
saa716x: Add missing return, to avoid falling through the error codes
saa716x: Updated board definitions
saa716x: Add some register definitions
saa716x: Add Read/Write macros
saa716x: Initial attempt to Boot the core
saa716x: Initial attempt to initialize the I2C core
saa716x: Setup CGU
saa716x: Whitespace cleanup
saa716x: Use subsystem Vendor ID
saa716x: Small cleanups
saa716x: Enable all inputs
saa716x: Initial go at MSI setup
saa716x: Update I2C register definitions and fields
saa716x: Initial go at the I2C implementation
saa716x: Remove unused definitions
saa716x: Move i2c related stuff to it's own header
saa716x: Add some labels
saa716x: Rename files
saa716x: Fix subdevice ID
saa716x: Add more register definitions
saa716x: Update/Reorganize register definitions
saa716x: Implement internal Boot mode
saa716x: Update register definitions
saa716x: Still scratching
saa716x: Initialize MSI
saa716x: Cleanup internal Boot configuration
saa716x: Cleanup external Boot configuration
saa716x: Initialize CGU and MSI modules
saa716x: Enable more debugging
saa716x: Check DMA availability
saa716x: Small cleanups and fixes
saa716x: Fix typo
saa716x: Reset internal modules
saa716x: Still debugging
saa716x: Code simplification
saa716x: Terminate PCI ID list
saa716x: Rename Rd/Wr operations
saa716x: Fix usage of wrong datatypes
saa716x: CGU related fixes
saa716x: Continue MSI-X implementation
saa716x: Add routines to handle clock related events
saa716x: Add support for Avermedia HC82 PCIe expresscard
saa716x: Disable BAR2 access
saa716x: Code cleanup
saa716x: Register SAA716x Adapter
saa716x: Add initial support for the second adapter
saa716x: Initialize adapters on the budget device
saa716x: Register only the relevant adapters for a specific device
saa716x: Add Avermedia HC82 specific device configuration
saa716x: Fix typo
saa716x: Register an array of devices
saa716x: Add support for the Avermedia H788 device
saa716x: Add support for the Azurewave VP-6002 device
saa716x: Usea separate frontend_attach for each of the devices
saa716x: Use a separate IRQ handler for separate modules
saa716x: Try to attach the demodulator
saa716x: Fix typo in register definitions
saa716x: Updates and Code simplification
saa716x: Check device revision for I2C bus orderring
saa716x: Add support for the NXP Atlantis reference design
saa716x: Free IRQ before module unload
saa716x: Code reorganization
saa716x: Add support for the KNC1 Dual S2 device
saa716x: Add support for the VP-3071 DVB-T dual device
saa716x: Add GPIO control functions
saa716x: Use power and reset controls within a sig\ngle loop
saa716x: Use a configuration per adapter
saa716x: VP-1028: add power, reset configuration
saa716x: H788: Add power, reset configuration
saa716x: HC82: Add power, reset configuration
saa716x: Display Bus status
saa716x: Bug: Address needs to be shifted one bit
saa716x: Initial go at DMA routines
saa716x: Print warning, if MSI module is not supported
saa716x: Handle MSI in a generic manner
saa716x: Add PHI port definitions
saa716x: Initialize PHI bus
saa716x: Add GREG routines
saa716x: Reorganize CGU related routines
saa716x: Do not initialize the CGU twice
saa716x: Add more debug info, initialize handler count
saa716x: Add/remove I2C MSI vectors
saa716x: Add interrupt debugging
saa716x: Return error on MSI enable failure
saa716x: Initialize FPGI pagetables
saa716x: Setup FGPI parameters
saa716x: Use a separate module to handle Full fledged cards
saa716x: NULL terminate PCI ID list
saa716x: Read the mask bits instead
saa716x: Reduce a bit of noise in the handler debug mode
saa716x: Sleep a little while before enabling interrupts again
saa716x: Use individual handlers
saa716x: Transmit D is programmed, not S data
saa716x: Print return values
saa716x: Use adapter ordering
saa716x: Disable debugging
osd.h: Kickstart the TT S2 6400 Dual HD Premium - OSD update
saa716x: Kickstart the TT S2 6400 Dual HD Premium
saa716x: Code simplification, Overhaul, ROM dump
saa716x: Set the default rate for the NEMO reference design
saa716x: Code simplification, Overhauling, I2C related fixes
saa716x: Try to attach the frontends
saa716x: Don't cast pointers to 32 bit int
saa716x: Partial rework of SPI I/O
saa716x: Add video device support
saa716x: S2-6400: Try to attach the frontend
saa716x: Handle multiple I2C messages
saa716x: Fix ROM parser
saa716x: Setup default I2C rates
saa716x: Fix BUS ordering
saa716x: Fix swapped I2C buses
saa716x: Print wait time, reduce number of loops
saa716x: Fix missing address in single write operation
saa716x: make register definitions specific to each of the modules
saa716x: Fix register definition typo
saa716x: Add function declaration
saa716x: Fix FGPI internal clock divider state
saa716x: Fix dmabuf allocation
saa716x: Cleanup debug prints
saa716x: Handle failure correctly
saa716x: Handle proper buffer flush
saa716x: FGPI DMA handling fixes
saa716x: Finally! we have stream capture
saa716x: Make the framework buildable
saa716x: Fix build issues
saa716x: Deinitialize I2C interrupts on exit
saa716x: Factorize register/detach routines to common code
saa716x: Start DMA engine as and when requested
saa716x: Enable timeout for modules having no clock
saa716x: Reset the frontend after powerup
saa716x: GPIO fix
saa716x: Fix powerup/reset
saa716x: Use the correct I2C Bus
saa716x: Code simplification
saa716x: Try to attach frontend on the Nemo reference board
saa716x: Do not report non-fatal errors to avoid issues with buggy
BIOS's
Oliver Endriss (3):
saa716x_ff: Rename saa716x_ff.c to saa716x_ff_main.c
saa716x_ff: Support remote control receiver
saa716x: Use tasklet to transfer data to the demuxer (TT S2-6400)
Soeren Moch (13):
saa716x: i2c_del_adapter() fix
saa716x_ff: init frontends to low-power mode
saa716x_ff: Add linux-4.5 support
saa716x_ff: Avoid sleeping in fifo_worker
saa716x: remove unused saa716x_msi_handler
saa716x: pci: Remove asm includes for compatibility with linux-4.6
saa716x: add linux-4.10 support
saa716x: Remove broken MSI-X support
saa716x: Use %zu printk format for sizeof return values
saa716x_budget: Fix build in current mainline
saa716x_hybrid: Fix build in current mainline
saa716x: Hook up driver in staging/media
saa716x: Add MAINTAINERS entry
MAINTAINERS | 6 +
drivers/staging/media/Kconfig | 2 +
drivers/staging/media/Makefile | 1 +
drivers/staging/media/saa716x/Kconfig | 63 +
drivers/staging/media/saa716x/Makefile | 27 +
drivers/staging/media/saa716x/TODO | 6 +
drivers/staging/media/saa716x/saa716x_adap.c | 251 +++
drivers/staging/media/saa716x/saa716x_adap.h | 9 +
drivers/staging/media/saa716x/saa716x_aip.c | 20 +
drivers/staging/media/saa716x/saa716x_aip.h | 9 +
drivers/staging/media/saa716x/saa716x_aip_reg.h | 62 +
drivers/staging/media/saa716x/saa716x_boot.c | 319 ++++
drivers/staging/media/saa716x/saa716x_boot.h | 18 +
drivers/staging/media/saa716x/saa716x_budget.c | 664 ++++++++
drivers/staging/media/saa716x/saa716x_budget.h | 15 +
drivers/staging/media/saa716x/saa716x_cgu.c | 540 +++++++
drivers/staging/media/saa716x/saa716x_cgu.h | 63 +
drivers/staging/media/saa716x/saa716x_cgu_reg.h | 178 +++
drivers/staging/media/saa716x/saa716x_dcs_reg.h | 56 +
drivers/staging/media/saa716x/saa716x_dma.c | 308 ++++
drivers/staging/media/saa716x/saa716x_dma.h | 61 +
drivers/staging/media/saa716x/saa716x_dma_reg.h | 201 +++
drivers/staging/media/saa716x/saa716x_ff.h | 187 +++
drivers/staging/media/saa716x/saa716x_ff_cmd.c | 433 +++++
drivers/staging/media/saa716x/saa716x_ff_cmd.h | 16 +
drivers/staging/media/saa716x/saa716x_ff_ir.c | 265 +++
drivers/staging/media/saa716x/saa716x_ff_main.c | 1859
++++++++++++++++++++++
drivers/staging/media/saa716x/saa716x_ff_phi.c | 229 +++
drivers/staging/media/saa716x/saa716x_ff_phi.h | 14 +
drivers/staging/media/saa716x/saa716x_fgpi.c | 386 +++++
drivers/staging/media/saa716x/saa716x_fgpi.h | 92 ++
drivers/staging/media/saa716x/saa716x_fgpi_reg.h | 74 +
drivers/staging/media/saa716x/saa716x_gpio.c | 140 ++
drivers/staging/media/saa716x/saa716x_gpio.h | 26 +
drivers/staging/media/saa716x/saa716x_gpio_reg.h | 47 +
drivers/staging/media/saa716x/saa716x_greg.c | 42 +
drivers/staging/media/saa716x/saa716x_greg.h | 9 +
drivers/staging/media/saa716x/saa716x_greg_reg.h | 91 ++
drivers/staging/media/saa716x/saa716x_hybrid.c | 726 +++++++++
drivers/staging/media/saa716x/saa716x_hybrid.h | 13 +
drivers/staging/media/saa716x/saa716x_i2c.c | 728 +++++++++
drivers/staging/media/saa716x/saa716x_i2c.h | 52 +
drivers/staging/media/saa716x/saa716x_i2c_reg.h | 145 ++
drivers/staging/media/saa716x/saa716x_mod.h | 50 +
drivers/staging/media/saa716x/saa716x_msi.c | 479 ++++++
drivers/staging/media/saa716x/saa716x_msi.h | 87 +
drivers/staging/media/saa716x/saa716x_msi_reg.h | 143 ++
drivers/staging/media/saa716x/saa716x_pci.c | 222 +++
drivers/staging/media/saa716x/saa716x_phi.c | 23 +
drivers/staging/media/saa716x/saa716x_phi.h | 8 +
drivers/staging/media/saa716x/saa716x_phi_reg.h | 94 ++
drivers/staging/media/saa716x/saa716x_priv.h | 193 +++
drivers/staging/media/saa716x/saa716x_rom.c | 1071 +++++++++++++
drivers/staging/media/saa716x/saa716x_rom.h | 253 +++
drivers/staging/media/saa716x/saa716x_spi.c | 313 ++++
drivers/staging/media/saa716x/saa716x_spi.h | 23 +
drivers/staging/media/saa716x/saa716x_spi_reg.h | 27 +
drivers/staging/media/saa716x/saa716x_vip.c | 401 +++++
drivers/staging/media/saa716x/saa716x_vip.h | 58 +
drivers/staging/media/saa716x/saa716x_vip_reg.h | 141 ++
include/uapi/linux/dvb/osd.h | 16 +
61 files changed, 12055 insertions(+)
create mode 100644 drivers/staging/media/saa716x/Kconfig
create mode 100644 drivers/staging/media/saa716x/Makefile
create mode 100644 drivers/staging/media/saa716x/TODO
create mode 100644 drivers/staging/media/saa716x/saa716x_adap.c
create mode 100644 drivers/staging/media/saa716x/saa716x_adap.h
create mode 100644 drivers/staging/media/saa716x/saa716x_aip.c
create mode 100644 drivers/staging/media/saa716x/saa716x_aip.h
create mode 100644 drivers/staging/media/saa716x/saa716x_aip_reg.h
create mode 100644 drivers/staging/media/saa716x/saa716x_boot.c
create mode 100644 drivers/staging/media/saa716x/saa716x_boot.h
create mode 100644 drivers/staging/media/saa716x/saa716x_budget.c
create mode 100644 drivers/staging/media/saa716x/saa716x_budget.h
create mode 100644 drivers/staging/media/saa716x/saa716x_cgu.c
create mode 100644 drivers/staging/media/saa716x/saa716x_cgu.h
create mode 100644 drivers/staging/media/saa716x/saa716x_cgu_reg.h
create mode 100644 drivers/staging/media/saa716x/saa716x_dcs_reg.h
create mode 100644 drivers/staging/media/saa716x/saa716x_dma.c
create mode 100644 drivers/staging/media/saa716x/saa716x_dma.h
create mode 100644 drivers/staging/media/saa716x/saa716x_dma_reg.h
create mode 100644 drivers/staging/media/saa716x/saa716x_ff.h
create mode 100644 drivers/staging/media/saa716x/saa716x_ff_cmd.c
create mode 100644 drivers/staging/media/saa716x/saa716x_ff_cmd.h
create mode 100644 drivers/staging/media/saa716x/saa716x_ff_ir.c
create mode 100644 drivers/staging/media/saa716x/saa716x_ff_main.c
create mode 100644 drivers/staging/media/saa716x/saa716x_ff_phi.c
create mode 100644 drivers/staging/media/saa716x/saa716x_ff_phi.h
create mode 100644 drivers/staging/media/saa716x/saa716x_fgpi.c
create mode 100644 drivers/staging/media/saa716x/saa716x_fgpi.h
create mode 100644 drivers/staging/media/saa716x/saa716x_fgpi_reg.h
create mode 100644 drivers/staging/media/saa716x/saa716x_gpio.c
create mode 100644 drivers/staging/media/saa716x/saa716x_gpio.h
create mode 100644 drivers/staging/media/saa716x/saa716x_gpio_reg.h
create mode 100644 drivers/staging/media/saa716x/saa716x_greg.c
create mode 100644 drivers/staging/media/saa716x/saa716x_greg.h
create mode 100644 drivers/staging/media/saa716x/saa716x_greg_reg.h
create mode 100644 drivers/staging/media/saa716x/saa716x_hybrid.c
create mode 100644 drivers/staging/media/saa716x/saa716x_hybrid.h
create mode 100644 drivers/staging/media/saa716x/saa716x_i2c.c
create mode 100644 drivers/staging/media/saa716x/saa716x_i2c.h
create mode 100644 drivers/staging/media/saa716x/saa716x_i2c_reg.h
create mode 100644 drivers/staging/media/saa716x/saa716x_mod.h
create mode 100644 drivers/staging/media/saa716x/saa716x_msi.c
create mode 100644 drivers/staging/media/saa716x/saa716x_msi.h
create mode 100644 drivers/staging/media/saa716x/saa716x_msi_reg.h
create mode 100644 drivers/staging/media/saa716x/saa716x_pci.c
create mode 100644 drivers/staging/media/saa716x/saa716x_phi.c
create mode 100644 drivers/staging/media/saa716x/saa716x_phi.h
create mode 100644 drivers/staging/media/saa716x/saa716x_phi_reg.h
create mode 100644 drivers/staging/media/saa716x/saa716x_priv.h
create mode 100644 drivers/staging/media/saa716x/saa716x_rom.c
create mode 100644 drivers/staging/media/saa716x/saa716x_rom.h
create mode 100644 drivers/staging/media/saa716x/saa716x_spi.c
create mode 100644 drivers/staging/media/saa716x/saa716x_spi.h
create mode 100644 drivers/staging/media/saa716x/saa716x_spi_reg.h
create mode 100644 drivers/staging/media/saa716x/saa716x_vip.c
create mode 100644 drivers/staging/media/saa716x/saa716x_vip.h
create mode 100644 drivers/staging/media/saa716x/saa716x_vip_reg.h
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [GIT PULL] SAA716x DVB driver
2017-07-16 18:34 [GIT PULL] SAA716x DVB driver Soeren Moch
@ 2017-07-20 10:49 ` Mauro Carvalho Chehab
2017-07-21 20:44 ` Soeren Moch
2017-08-23 9:56 ` [GIT PULL RESEND] " Soeren Moch
2 siblings, 0 replies; 26+ messages in thread
From: Mauro Carvalho Chehab @ 2017-07-20 10:49 UTC (permalink / raw)
To: Soeren Moch
Cc: Mauro Carvalho Chehab, Greg Kroah-Hartman, Andreas Regel,
Manu Abraham, Oliver Endriss, linux-media
Hi Soeren,
Em Sun, 16 Jul 2017 20:34:23 +0200
Soeren Moch <smoch@web.de> escreveu:
> This is a driver for DVB cards based on the SAA7160/62 PCIe bridges from
> Philips/NXP. The most important of these cards, at least for me, is the
> TechnoTrend S2-6400, a high-definition full-featured DVB-S2 card, the
> successor of the famous ttpci decoder cards. Other supported cards are:
> Avermedia H788
> Avermedia HC82 Express-54
> KNC One Dual S2
> KWorld DVB-T PE310
> Technisat SkyStar 2 eXpress HD
> Twinhan/Azurewave VP-1028
> Twinhan/Azurewave VP-3071
> Twinhan/Azurewave VP-6002
> Twinhan/Azurewave VP-6090
>
> The driver is taken from [1] with adaptations for current mainline,
> converted to git and moved to drivers/staging/media. See TODO for
> required cleanups (from my point of view, maybe more to come from
> additional code review by other developers). I added myself as driver
> maintainer to document my commitment to further development to get this
> out of staging, help from others welcome.
>
> This driver was licensed "GPL" from the beginning. S2-6400 firmware is
> available at [2].
>
> I want to preserve the development history of the driver, since this
> is mainly work of Andreas Regel, Manu Abraham, and Oliver Endriss.
> Unfortunately Andreas seems not to take care of this driver anymore, he
> also did not answer my requests to integrate patches for newer kernel
> versions. So I send this upstream.
>
> With all the history this is a 280 part patch series, so I send this as
> pull request. Of course I can also send this as 'git send-email' series
> if desired.
Even on staging, reviewing a 280 patch series take a while ;)
As the patches that make it build with current upstream are at the
end of the series, you need to be sure that the saa716x Makefile
won't be included until those fixes get applied. It seems you took
care of it already, with is good!
The hole idea of adding a driver to staging is that it will be moved
some day out of staging. That's why a TODO and an entry at MAINTAINERS
is required.
By looking at the saa716x_ff_main:
https://github.com/s-moch/linux-saa716x/blob/for-media/drivers/staging/media/saa716x/saa716x_ff_main.c
I'm seeing that the main problem of this driver is that it still use
the API from the legacy ttpci driver, e. g. DVB audio, video and osd APIs.
Those APIs were deprecated because they duplicate a functionality
provided by the V4L2 API, and are obscure, because they're not
properly documented. Also, no other driver uses it upstream.
So, it was agreed several years ago that new full featured drivers
should use the V4L2 API for audio/video codecs.
We have a some drivers that use V4L2 for MPEG audio/video decoding
and encoding. The best examples are ivtv and cx18 (as both are for
PCI devices). Currently, none of those drivers support the DVB
API, though, as they're used only on analog TV devices.
It was also agreed that setup pipelines on more complex DVB
devices should use the media controller API (MC API).
Yet, we don't have, currently, any full featured drivers upstream
(except for the legacy one).
So, if we're willing to apply this driver, you should be committed
to do implement the media APIs properly, porting from DVB
audio/video/osd to V4L2 and MC APIs.
That should also reflect its TODO:
https://github.com/s-moch/linux-saa716x/blob/for-media/drivers/staging/media/saa716x/TODO
Regards,
Mauro
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [GIT PULL] SAA716x DVB driver
2017-07-16 18:34 [GIT PULL] SAA716x DVB driver Soeren Moch
2017-07-20 10:49 ` Mauro Carvalho Chehab
@ 2017-07-21 20:44 ` Soeren Moch
2017-08-27 10:30 ` Mauro Carvalho Chehab
2017-08-23 9:56 ` [GIT PULL RESEND] " Soeren Moch
2 siblings, 1 reply; 26+ messages in thread
From: Soeren Moch @ 2017-07-21 20:44 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Greg Kroah-Hartman, Andreas Regel, Manu Abraham, Oliver Endriss,
linux-media
Hi Mauro,
On 20.07.2017 07:49:36 -0300, Mauro Carvalho Chehab wrote:
>Hi Soeren,
>
>Em Sun, 16 Jul 2017 20:34:23 +0200
>Soeren Moch <smoch@xxxxxx> escreveu:
>
>> This is a driver for DVB cards based on the SAA7160/62 PCIe bridges from
>> Philips/NXP. The most important of these cards, at least for me, is the
>> TechnoTrend S2-6400, a high-definition full-featured DVB-S2 card, the
>> successor of the famous ttpci decoder cards. Other supported cards are:
>> Avermedia H788
>> Avermedia HC82 Express-54
>> KNC One Dual S2
>> KWorld DVB-T PE310
>> Technisat SkyStar 2 eXpress HD
>> Twinhan/Azurewave VP-1028
>> Twinhan/Azurewave VP-3071
>> Twinhan/Azurewave VP-6002
>> Twinhan/Azurewave VP-6090
>>
>> The driver is taken from [1] with adaptations for current mainline,
>> converted to git and moved to drivers/staging/media. See TODO for
>> required cleanups (from my point of view, maybe more to come from
>> additional code review by other developers). I added myself as driver
>> maintainer to document my commitment to further development to get this
>> out of staging, help from others welcome.
>>
>> This driver was licensed "GPL" from the beginning. S2-6400 firmware is
>> available at [2].
>>
>> I want to preserve the development history of the driver, since this
>> is mainly work of Andreas Regel, Manu Abraham, and Oliver Endriss.
>> Unfortunately Andreas seems not to take care of this driver anymore, he
>> also did not answer my requests to integrate patches for newer kernel
>> versions. So I send this upstream.
>>
>> With all the history this is a 280 part patch series, so I send this as
>> pull request. Of course I can also send this as 'git send-email' series
>> if desired.
>
>Even on staging, reviewing a 280 patch series take a while ;)
>
>As the patches that make it build with current upstream are at the
>end of the series, you need to be sure that the saa716x Makefile
>won't be included until those fixes get applied. It seems you took
>care of it already, with is good!
>
>
>The hole idea of adding a driver to staging is that it will be moved
>some day out of staging. That's why a TODO and an entry at MAINTAINERS
>is required.
>
>By looking at the saa716x_ff_main:
>
>
https://github.com/s-moch/linux-saa716x/blob/for-media/drivers/staging/media/saa716x/saa716x_ff_main.c
>
>I'm seeing that the main problem of this driver is that it still use
>the API from the legacy ttpci driver, e. g. DVB audio, video and osd APIs.
>
>Those APIs were deprecated because they duplicate a functionality
>provided by the V4L2 API, and are obscure, because they're not
>properly documented. Also, no other driver uses it upstream.
>
>So, it was agreed several years ago that new full featured drivers
>should use the V4L2 API for audio/video codecs.
>
>We have a some drivers that use V4L2 for MPEG audio/video decoding
>and encoding. The best examples are ivtv and cx18 (as both are for
>PCI devices). Currently, none of those drivers support the DVB
>API, though, as they're used only on analog TV devices.
>
>It was also agreed that setup pipelines on more complex DVB
>devices should use the media controller API (MC API).
>
>Yet, we don't have, currently, any full featured drivers upstream
>(except for the legacy one).
>
>So, if we're willing to apply this driver, you should be committed
>to do implement the media APIs properly, porting from DVB
>audio/video/osd to V4L2 and MC APIs.
>
>That should also reflect its TODO:
>
>
https://github.com/s-moch/linux-saa716x/blob/for-media/drivers/staging/media/saa716x/TODO
Thanks for your feedback. I understand all your concerns about the legacy
API and your request to convert this to v4l2. For me the whole story looks
a little bit different, though.
The only application which makes use of the decoder part of this saa716x_ff
driver is VDR (Video Disk Recorder by Klaus Schmidinger, [1] [2]) - if
anybody else knows about a different use-case, please speak up!
In fact the high-definition version of VDR (vdr-2.x) was co-developed with
the S2-6400 hardware and this saa716x_ff driver. So it is no surprise, that
this driver utilizes the - now legacy - DVB API of the ttpci cards, since
VDR was originally developed with this API in mind. The missing API
documentation, besides of course not being ideal, is therefore no real
problem here, since driver and application are closely tied together.
The S2-6400 card (the only hardware which saa716x_ff supports) only has
two simple hardware interfaces for the decoder part, a transport stream
interface for the video/audio decoder, and a DVB API command interface
for osd. There is no real separate DVB audio interface, audio TS packets
are simply multiplexed into the video TS stream.
Because there are no complicated hardware interfaces or, e.g., configurable
processing pipelines, I think a media controller driver is not applicable
for this hardware, but a v4l2 API would be possible for the video part. For
the osd part instead I'm not really sure how to convert this. The DVB osd
API contains several commands for window and palette management,
pixel/line/block drawing, and even text rendering. Typical plane/framebuffer
based overlay APIs are a very bad match for this command-based hardware
interface. And a full-blown GPU driver only for menu overlays would be quite
a big effort, especially as we do not need a standard command-to-image
processing, but a gpu-command to dvb-osd-command conversion. Even now with
the osd API command processing implemented in the S2-6400 hardware, the
overlay is relatively slow, this could only become worse with an additional
translation layer. But let's assume that is all solvable technically.
The real problem is not my commitment to convert the DVB video/osd API to
v4l2. I would do it, although this means huge additional effort. My real
concern about your request is, with converted DVB APIs in this saa716x_ff
driver, VDR would not be able to use this driver. So the only known use-case
would not work anymore, so the whole effort to mainline this driver would
not make sense for me.
I agree that new drivers should use modern APIs in the general case. But
for this driver the legacy DVB decoder API is a hard requirement for me,
as described. So I hope you will dispense with the v4l2 conversion for
this special case. I'm pretty sure that there will be no new hardware
and therefore no new driver with this legacy API, this saa716x_ff driver
also has a 7-year development history, in this sense it is not really new
and one could also think of it as some sort of legacy code.
If it helps, I can offer to also take maintainership for the saa7146/ttpci
drivers, I still have such card in productive use. This way I could at
least maintain the DVB decoder API code together, as we cannot get rid
of it.
If you got any better idea how to solve this "legacy issue" in a different
way, I'm glad to help.
Regards,
Soeren
[1] www.tvdr.de
[2] https://linuxtv.org/vdrwiki
^ permalink raw reply [flat|nested] 26+ messages in thread
* [GIT PULL RESEND] SAA716x DVB driver
2017-07-16 18:34 [GIT PULL] SAA716x DVB driver Soeren Moch
2017-07-20 10:49 ` Mauro Carvalho Chehab
2017-07-21 20:44 ` Soeren Moch
@ 2017-08-23 9:56 ` Soeren Moch
2018-03-07 15:14 ` Mauro Carvalho Chehab
2 siblings, 1 reply; 26+ messages in thread
From: Soeren Moch @ 2017-08-23 9:56 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Andreas Regel, Manu Abraham, Oliver Endriss, linux-media
Resend this pull request. Apparently my explanation one month ago,
why we need the userspace API of this driver in the current form [1],
got lost.
Regards,
Soeren
[1] https://www.mail-archive.com/linux-media@vger.kernel.org/msg116119.html
The following changes since commit 5771a8c08880cdca3bfb4a3fc6d309d6bba20877:
Linux v4.13-rc1 (2017-07-15 15:22:10 -0700)
are available in the git repository at:
https://github.com/s-moch/linux-saa716x for-media
for you to fetch changes up to 1a9e44df11d702b9f569605e60c7cf8e05923178:
saa716x: Add MAINTAINERS entry (2017-07-16 15:37:00 +0200)
----------------------------------------------------------------
Andreas Regel (127):
saa716x: Simplified the code for I2C transfers.
saa716x: Transport stream ports can be configured now.
saa716x_ff: Disable frontend support through STi7109 firmware.
saa716x_ff: Initialize the frontend of the TT S2-6400.
saa716x_ff: Add VIDEO_GET_PTS ioctl.
saa716x_ff: Add audio device for TT S2-6400.
saa716x_ff: Use separate interrupts for OSD commands.
saa716x_ff: Use third TS input of the STi7109 for playback
saa716x_ff: Set error code when boot of firmware failed.
saa716x_ff: Added 10ms sleep after configuring the FPGA.
saa716x: Reduce compiler warnings
saa716x: fix kernel oops caused by missing initialisation
saa716x: fixed double frontend detach
saa716x: 1ms is enough when waiting for the PLL
saa716x_ff: Adapted frontend init to latest driver changes.
saa716x: Improve PHI performance by shorten timings a bit.
saa716x_ff: use double buffering for block transfers.
saa716x_ff: Reset block_done after receiving it.
saa716x_ff: add interrupt source for firmware log messages
saa716x_ff: read FPGA version register
saa716x_ff: fixed PTS/STC signed/unsigned issue
saa716x_ff: query and print loader and firmware versions
saa716x: disable debug printk
osd.h: Add const keyword to struct members
saa716x_ff: implement ioctl VIDEO_GET_SIZE
saa716x_ff: support production version of the S2-6400
saa716x: disable OVERFLOW and AV interrupts in FGPI
saa716x_ff: add some FPGA register definitions
saa716x_ff: restart TS capturing in case of non-aligned TS error
saa716x_ff: don't clear FGPI interrupts in IRQ routine.
saa716x: comment out SPI functions that are not needed currently
saa716x: add changes needed for kernel 2.6.36 and up.
saa716x: support building with media_build_experimental
saa716x_ff: use tasklet for FIFO transfer
saa716x: fix not working MSI
saa716x: Disable shared IRQ when using MSI mode.
saa716x_ff: Do an explicit demodulator reset.
saa716x: enable wait for PLL lock when setting clocks of all ports.
saa716x_ff: add counting of interrupts
saa716x: don't set i2c_adapter id field
saa716x_ff: support non-aligned TS data
saa716x_ff: Use a TS clock of 135Mhz instead of 90 Mhz.
saa716x_ff: Ignore false remote events.
saa716x_ff: Fix possible crash in IRQ handler.
saa716x_ff: move firmware command interface code to separate file.
saa716x_ff: Allow to have osd device opened twice.
saa716x_ff: support correct TS mux setting for FPGA 1.10.
saa716x_budget: Add missing GPIO initialization.
saa716x_hybrid: Add missing GPIO initialization.
saa716x_hybrid: fix tuner settings for nemo reference board
saa716x_hybrid: TS capturing on the nemo reference board works.
saa716x_hybrid: Make TS capturing code more generic.
saa716x: remove unused members from struct saa716x_config.
saa716x: Add function saa716x_fgpi_get_write_index.
saa716x_hybrid: Use saa716x_fgpi_get_write_index to simplify code.
saa716x_ff: Use saa716x_fgpi_get_write_index to simplify code.
saa716x: Set maximum number of adapters per saa716x to 4.
saa716x_budget: Add TS capturing code.
saa716x_hybrid: Do some cleanups.
saa716x: remove unused load_config functions.
saa716x_budget: Started with SkyStar 2 eXpress HD.
saa716x_hybrid: Add support for KWorld Dual DVB-T PE310.
saa716x: Fix I2C bus assignment on SAA7160ET.
saa716x: Fix stack corruption when parsing ROM info.
saa716x: Fix memory leak in ROM parsing.
saa716x: Skip unknown device descriptors when parsing the ROM
saa716x: change verbose level for some dprintk
saa716x_ff: Enable now working EEPROM parsing.
saa716x_ff: Add error message when FPGA is not responding.
saa716x_budget: Add frontend attach for the Skystar2 eXpress HD.
saa716x_ff: Reset the frontend on the SkyStar2 eXpress HD.
saa716x_ff: support CEC remote codes.
saa716x: Use interrupts for I2C writes instead of polling.
saa716x: separate I2C reading and writing into two functions.
saa716x_ff: change remote event printk to hexadecimal output.
saa716x: Support buffered I2C transaction using interrupts.
saa716x_ff: Use buffered I2C interrupt mode.
saa716x_ff: Don't use dvb_generic_ioctl.
saa716x_budget: Use GPIO 26 for reset on the Skystar 2 eXpress HD.
saa716x_budget: Use I2C B for accessing the frontend on the Skystar.
saa716x_budget: Get the Skystar 2 eXpress HD to work.
saa716x_budget: Implement LNB power switching for Skystar 2
eXpress HD.
saa716x_ff: Fix memory leak.
saa716x_ff: Fix missing copy user <-> kernel space.
saa716x: FGPI DMA buffer size is passed to saa716x_fgpi_init.
saa716x: Fix FGPI settings for SD video capture.
saa716x: Export some FGPI functions.
saa716x: Remove unused header file.
saa716x: Remove duplicate definition.
saa716x: Make BAM register macros more generic.
saa716x: Use global macros for MMU register access.
saa716x: Add VI module implementation.
saa716x: Support one-shot video capturing.
saa716x_ff: Extend interrupt counters.
saa716x: Change video capture format from YUYV to UYUV.
saa716x_ff: Support capturing digital video coming from STi7109.
saa716x_ff: Protect reading of the captured video with a mutex.
saa716x_ff: Rename functions.
saa716x_ff: video capture refactoring.
saa716x: Use pitch value from stream params when setting FGPI_STRIDE.
saa716x: use offset from stream params instead of fixed value.
saa716x: Clear DMA buffer after allocatiion
saa716x: Support capturing raw data via FGPI unit
saa716x: Reset FGPI read index in saa716x_fgpi_start
saa716x_ff: Cancel data transfer in case of a block timeout
saa716x_ff: print decimal digits for firmware version.
saa716x: include fix for in-kernel build
saa716x: support directory structure of linux-3.7+
saa716x: section mismatch fixes
saa716x: remove __devinit and friends
saa716x: convert fifo_worker tasklet to workqueue
saa716x: TS output buffer cleanup
saa716x: Fix PHI address space offsets, cleanup register definitions.
saa716x: Clean up PHI configuration.
saa716x: Reset PHI on init.
saa716x: Print EEPROM content on DEBUG verbosity only.
saa716x: Fix errors and improve saa716x_set_clk.
saa716x_ff: Fix not setting command result length to 0 per default.
saa716x: move card specific PHI code to saa716x_ff driver
saa716x_ff: use special phi_fifo_write function
saa716x_ff: Add write-combining PCI iomem window for PHI1 access.
saa716x_ff: implement PHI speedup
saa716x: IO memory of upper PHI1 regions is mapped in saa716x_ff
driver.
saa716x_ff: Optimize access to FIFO.
saa716x_ff: Align block data on 32 bytes for firmware 0.5.0 and up
saa716x_ff: Do not return on command ready timeout
saa716x_ff: Usa faster EMI timings only for FPGA version 1.10 and
later
Manu Abraham (137):
saa716x: Initial framework driver to support SAA7160, SAA7161,
SAA7162 chips
saa716x: Add missing return, to avoid falling through the error codes
saa716x: Updated board definitions
saa716x: Add some register definitions
saa716x: Add Read/Write macros
saa716x: Initial attempt to Boot the core
saa716x: Initial attempt to initialize the I2C core
saa716x: Setup CGU
saa716x: Whitespace cleanup
saa716x: Use subsystem Vendor ID
saa716x: Small cleanups
saa716x: Enable all inputs
saa716x: Initial go at MSI setup
saa716x: Update I2C register definitions and fields
saa716x: Initial go at the I2C implementation
saa716x: Remove unused definitions
saa716x: Move i2c related stuff to it's own header
saa716x: Add some labels
saa716x: Rename files
saa716x: Fix subdevice ID
saa716x: Add more register definitions
saa716x: Update/Reorganize register definitions
saa716x: Implement internal Boot mode
saa716x: Update register definitions
saa716x: Still scratching
saa716x: Initialize MSI
saa716x: Cleanup internal Boot configuration
saa716x: Cleanup external Boot configuration
saa716x: Initialize CGU and MSI modules
saa716x: Enable more debugging
saa716x: Check DMA availability
saa716x: Small cleanups and fixes
saa716x: Fix typo
saa716x: Reset internal modules
saa716x: Still debugging
saa716x: Code simplification
saa716x: Terminate PCI ID list
saa716x: Rename Rd/Wr operations
saa716x: Fix usage of wrong datatypes
saa716x: CGU related fixes
saa716x: Continue MSI-X implementation
saa716x: Add routines to handle clock related events
saa716x: Add support for Avermedia HC82 PCIe expresscard
saa716x: Disable BAR2 access
saa716x: Code cleanup
saa716x: Register SAA716x Adapter
saa716x: Add initial support for the second adapter
saa716x: Initialize adapters on the budget device
saa716x: Register only the relevant adapters for a specific device
saa716x: Add Avermedia HC82 specific device configuration
saa716x: Fix typo
saa716x: Register an array of devices
saa716x: Add support for the Avermedia H788 device
saa716x: Add support for the Azurewave VP-6002 device
saa716x: Usea separate frontend_attach for each of the devices
saa716x: Use a separate IRQ handler for separate modules
saa716x: Try to attach the demodulator
saa716x: Fix typo in register definitions
saa716x: Updates and Code simplification
saa716x: Check device revision for I2C bus orderring
saa716x: Add support for the NXP Atlantis reference design
saa716x: Free IRQ before module unload
saa716x: Code reorganization
saa716x: Add support for the KNC1 Dual S2 device
saa716x: Add support for the VP-3071 DVB-T dual device
saa716x: Add GPIO control functions
saa716x: Use power and reset controls within a sig\ngle loop
saa716x: Use a configuration per adapter
saa716x: VP-1028: add power, reset configuration
saa716x: H788: Add power, reset configuration
saa716x: HC82: Add power, reset configuration
saa716x: Display Bus status
saa716x: Bug: Address needs to be shifted one bit
saa716x: Initial go at DMA routines
saa716x: Print warning, if MSI module is not supported
saa716x: Handle MSI in a generic manner
saa716x: Add PHI port definitions
saa716x: Initialize PHI bus
saa716x: Add GREG routines
saa716x: Reorganize CGU related routines
saa716x: Do not initialize the CGU twice
saa716x: Add more debug info, initialize handler count
saa716x: Add/remove I2C MSI vectors
saa716x: Add interrupt debugging
saa716x: Return error on MSI enable failure
saa716x: Initialize FPGI pagetables
saa716x: Setup FGPI parameters
saa716x: Use a separate module to handle Full fledged cards
saa716x: NULL terminate PCI ID list
saa716x: Read the mask bits instead
saa716x: Reduce a bit of noise in the handler debug mode
saa716x: Sleep a little while before enabling interrupts again
saa716x: Use individual handlers
saa716x: Transmit D is programmed, not S data
saa716x: Print return values
saa716x: Use adapter ordering
saa716x: Disable debugging
osd.h: Kickstart the TT S2 6400 Dual HD Premium - OSD update
saa716x: Kickstart the TT S2 6400 Dual HD Premium
saa716x: Code simplification, Overhaul, ROM dump
saa716x: Set the default rate for the NEMO reference design
saa716x: Code simplification, Overhauling, I2C related fixes
saa716x: Try to attach the frontends
saa716x: Don't cast pointers to 32 bit int
saa716x: Partial rework of SPI I/O
saa716x: Add video device support
saa716x: S2-6400: Try to attach the frontend
saa716x: Handle multiple I2C messages
saa716x: Fix ROM parser
saa716x: Setup default I2C rates
saa716x: Fix BUS ordering
saa716x: Fix swapped I2C buses
saa716x: Print wait time, reduce number of loops
saa716x: Fix missing address in single write operation
saa716x: make register definitions specific to each of the modules
saa716x: Fix register definition typo
saa716x: Add function declaration
saa716x: Fix FGPI internal clock divider state
saa716x: Fix dmabuf allocation
saa716x: Cleanup debug prints
saa716x: Handle failure correctly
saa716x: Handle proper buffer flush
saa716x: FGPI DMA handling fixes
saa716x: Finally! we have stream capture
saa716x: Make the framework buildable
saa716x: Fix build issues
saa716x: Deinitialize I2C interrupts on exit
saa716x: Factorize register/detach routines to common code
saa716x: Start DMA engine as and when requested
saa716x: Enable timeout for modules having no clock
saa716x: Reset the frontend after powerup
saa716x: GPIO fix
saa716x: Fix powerup/reset
saa716x: Use the correct I2C Bus
saa716x: Code simplification
saa716x: Try to attach frontend on the Nemo reference board
saa716x: Do not report non-fatal errors to avoid issues with buggy
BIOS's
Oliver Endriss (3):
saa716x_ff: Rename saa716x_ff.c to saa716x_ff_main.c
saa716x_ff: Support remote control receiver
saa716x: Use tasklet to transfer data to the demuxer (TT S2-6400)
Soeren Moch (13):
saa716x: i2c_del_adapter() fix
saa716x_ff: init frontends to low-power mode
saa716x_ff: Add linux-4.5 support
saa716x_ff: Avoid sleeping in fifo_worker
saa716x: remove unused saa716x_msi_handler
saa716x: pci: Remove asm includes for compatibility with linux-4.6
saa716x: add linux-4.10 support
saa716x: Remove broken MSI-X support
saa716x: Use %zu printk format for sizeof return values
saa716x_budget: Fix build in current mainline
saa716x_hybrid: Fix build in current mainline
saa716x: Hook up driver in staging/media
saa716x: Add MAINTAINERS entry
MAINTAINERS | 6 +
drivers/staging/media/Kconfig | 2 +
drivers/staging/media/Makefile | 1 +
drivers/staging/media/saa716x/Kconfig | 63 +
drivers/staging/media/saa716x/Makefile | 27 +
drivers/staging/media/saa716x/TODO | 6 +
drivers/staging/media/saa716x/saa716x_adap.c | 251 +++
drivers/staging/media/saa716x/saa716x_adap.h | 9 +
drivers/staging/media/saa716x/saa716x_aip.c | 20 +
drivers/staging/media/saa716x/saa716x_aip.h | 9 +
drivers/staging/media/saa716x/saa716x_aip_reg.h | 62 +
drivers/staging/media/saa716x/saa716x_boot.c | 319 ++++
drivers/staging/media/saa716x/saa716x_boot.h | 18 +
drivers/staging/media/saa716x/saa716x_budget.c | 664 ++++++++
drivers/staging/media/saa716x/saa716x_budget.h | 15 +
drivers/staging/media/saa716x/saa716x_cgu.c | 540 +++++++
drivers/staging/media/saa716x/saa716x_cgu.h | 63 +
drivers/staging/media/saa716x/saa716x_cgu_reg.h | 178 +++
drivers/staging/media/saa716x/saa716x_dcs_reg.h | 56 +
drivers/staging/media/saa716x/saa716x_dma.c | 308 ++++
drivers/staging/media/saa716x/saa716x_dma.h | 61 +
drivers/staging/media/saa716x/saa716x_dma_reg.h | 201 +++
drivers/staging/media/saa716x/saa716x_ff.h | 187 +++
drivers/staging/media/saa716x/saa716x_ff_cmd.c | 433 +++++
drivers/staging/media/saa716x/saa716x_ff_cmd.h | 16 +
drivers/staging/media/saa716x/saa716x_ff_ir.c | 265 +++
drivers/staging/media/saa716x/saa716x_ff_main.c | 1859
++++++++++++++++++++++
drivers/staging/media/saa716x/saa716x_ff_phi.c | 229 +++
drivers/staging/media/saa716x/saa716x_ff_phi.h | 14 +
drivers/staging/media/saa716x/saa716x_fgpi.c | 386 +++++
drivers/staging/media/saa716x/saa716x_fgpi.h | 92 ++
drivers/staging/media/saa716x/saa716x_fgpi_reg.h | 74 +
drivers/staging/media/saa716x/saa716x_gpio.c | 140 ++
drivers/staging/media/saa716x/saa716x_gpio.h | 26 +
drivers/staging/media/saa716x/saa716x_gpio_reg.h | 47 +
drivers/staging/media/saa716x/saa716x_greg.c | 42 +
drivers/staging/media/saa716x/saa716x_greg.h | 9 +
drivers/staging/media/saa716x/saa716x_greg_reg.h | 91 ++
drivers/staging/media/saa716x/saa716x_hybrid.c | 726 +++++++++
drivers/staging/media/saa716x/saa716x_hybrid.h | 13 +
drivers/staging/media/saa716x/saa716x_i2c.c | 728 +++++++++
drivers/staging/media/saa716x/saa716x_i2c.h | 52 +
drivers/staging/media/saa716x/saa716x_i2c_reg.h | 145 ++
drivers/staging/media/saa716x/saa716x_mod.h | 50 +
drivers/staging/media/saa716x/saa716x_msi.c | 479 ++++++
drivers/staging/media/saa716x/saa716x_msi.h | 87 +
drivers/staging/media/saa716x/saa716x_msi_reg.h | 143 ++
drivers/staging/media/saa716x/saa716x_pci.c | 222 +++
drivers/staging/media/saa716x/saa716x_phi.c | 23 +
drivers/staging/media/saa716x/saa716x_phi.h | 8 +
drivers/staging/media/saa716x/saa716x_phi_reg.h | 94 ++
drivers/staging/media/saa716x/saa716x_priv.h | 193 +++
drivers/staging/media/saa716x/saa716x_rom.c | 1071 +++++++++++++
drivers/staging/media/saa716x/saa716x_rom.h | 253 +++
drivers/staging/media/saa716x/saa716x_spi.c | 313 ++++
drivers/staging/media/saa716x/saa716x_spi.h | 23 +
drivers/staging/media/saa716x/saa716x_spi_reg.h | 27 +
drivers/staging/media/saa716x/saa716x_vip.c | 401 +++++
drivers/staging/media/saa716x/saa716x_vip.h | 58 +
drivers/staging/media/saa716x/saa716x_vip_reg.h | 141 ++
include/uapi/linux/dvb/osd.h | 16 +
61 files changed, 12055 insertions(+)
create mode 100644 drivers/staging/media/saa716x/Kconfig
create mode 100644 drivers/staging/media/saa716x/Makefile
create mode 100644 drivers/staging/media/saa716x/TODO
create mode 100644 drivers/staging/media/saa716x/saa716x_adap.c
create mode 100644 drivers/staging/media/saa716x/saa716x_adap.h
create mode 100644 drivers/staging/media/saa716x/saa716x_aip.c
create mode 100644 drivers/staging/media/saa716x/saa716x_aip.h
create mode 100644 drivers/staging/media/saa716x/saa716x_aip_reg.h
create mode 100644 drivers/staging/media/saa716x/saa716x_boot.c
create mode 100644 drivers/staging/media/saa716x/saa716x_boot.h
create mode 100644 drivers/staging/media/saa716x/saa716x_budget.c
create mode 100644 drivers/staging/media/saa716x/saa716x_budget.h
create mode 100644 drivers/staging/media/saa716x/saa716x_cgu.c
create mode 100644 drivers/staging/media/saa716x/saa716x_cgu.h
create mode 100644 drivers/staging/media/saa716x/saa716x_cgu_reg.h
create mode 100644 drivers/staging/media/saa716x/saa716x_dcs_reg.h
create mode 100644 drivers/staging/media/saa716x/saa716x_dma.c
create mode 100644 drivers/staging/media/saa716x/saa716x_dma.h
create mode 100644 drivers/staging/media/saa716x/saa716x_dma_reg.h
create mode 100644 drivers/staging/media/saa716x/saa716x_ff.h
create mode 100644 drivers/staging/media/saa716x/saa716x_ff_cmd.c
create mode 100644 drivers/staging/media/saa716x/saa716x_ff_cmd.h
create mode 100644 drivers/staging/media/saa716x/saa716x_ff_ir.c
create mode 100644 drivers/staging/media/saa716x/saa716x_ff_main.c
create mode 100644 drivers/staging/media/saa716x/saa716x_ff_phi.c
create mode 100644 drivers/staging/media/saa716x/saa716x_ff_phi.h
create mode 100644 drivers/staging/media/saa716x/saa716x_fgpi.c
create mode 100644 drivers/staging/media/saa716x/saa716x_fgpi.h
create mode 100644 drivers/staging/media/saa716x/saa716x_fgpi_reg.h
create mode 100644 drivers/staging/media/saa716x/saa716x_gpio.c
create mode 100644 drivers/staging/media/saa716x/saa716x_gpio.h
create mode 100644 drivers/staging/media/saa716x/saa716x_gpio_reg.h
create mode 100644 drivers/staging/media/saa716x/saa716x_greg.c
create mode 100644 drivers/staging/media/saa716x/saa716x_greg.h
create mode 100644 drivers/staging/media/saa716x/saa716x_greg_reg.h
create mode 100644 drivers/staging/media/saa716x/saa716x_hybrid.c
create mode 100644 drivers/staging/media/saa716x/saa716x_hybrid.h
create mode 100644 drivers/staging/media/saa716x/saa716x_i2c.c
create mode 100644 drivers/staging/media/saa716x/saa716x_i2c.h
create mode 100644 drivers/staging/media/saa716x/saa716x_i2c_reg.h
create mode 100644 drivers/staging/media/saa716x/saa716x_mod.h
create mode 100644 drivers/staging/media/saa716x/saa716x_msi.c
create mode 100644 drivers/staging/media/saa716x/saa716x_msi.h
create mode 100644 drivers/staging/media/saa716x/saa716x_msi_reg.h
create mode 100644 drivers/staging/media/saa716x/saa716x_pci.c
create mode 100644 drivers/staging/media/saa716x/saa716x_phi.c
create mode 100644 drivers/staging/media/saa716x/saa716x_phi.h
create mode 100644 drivers/staging/media/saa716x/saa716x_phi_reg.h
create mode 100644 drivers/staging/media/saa716x/saa716x_priv.h
create mode 100644 drivers/staging/media/saa716x/saa716x_rom.c
create mode 100644 drivers/staging/media/saa716x/saa716x_rom.h
create mode 100644 drivers/staging/media/saa716x/saa716x_spi.c
create mode 100644 drivers/staging/media/saa716x/saa716x_spi.h
create mode 100644 drivers/staging/media/saa716x/saa716x_spi_reg.h
create mode 100644 drivers/staging/media/saa716x/saa716x_vip.c
create mode 100644 drivers/staging/media/saa716x/saa716x_vip.h
create mode 100644 drivers/staging/media/saa716x/saa716x_vip_reg.h
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [GIT PULL] SAA716x DVB driver
2017-07-21 20:44 ` Soeren Moch
@ 2017-08-27 10:30 ` Mauro Carvalho Chehab
2017-09-09 12:52 ` Soeren Moch
0 siblings, 1 reply; 26+ messages in thread
From: Mauro Carvalho Chehab @ 2017-08-27 10:30 UTC (permalink / raw)
To: Soeren Moch
Cc: Mauro Carvalho Chehab, Greg Kroah-Hartman, Andreas Regel,
Manu Abraham, Oliver Endriss, linux-media
Em Fri, 21 Jul 2017 22:44:42 +0200
Soeren Moch <smoch@web.de> escreveu:
> Hi Mauro,
>
> On 20.07.2017 07:49:36 -0300, Mauro Carvalho Chehab wrote:
> >Hi Soeren,
> >
> >Em Sun, 16 Jul 2017 20:34:23 +0200
> >Soeren Moch <smoch@xxxxxx> escreveu:
> >
> >> This is a driver for DVB cards based on the SAA7160/62 PCIe bridges from
> >> Philips/NXP. The most important of these cards, at least for me, is the
> >> TechnoTrend S2-6400, a high-definition full-featured DVB-S2 card, the
> >> successor of the famous ttpci decoder cards. Other supported cards are:
> >> Avermedia H788
> >> Avermedia HC82 Express-54
> >> KNC One Dual S2
> >> KWorld DVB-T PE310
> >> Technisat SkyStar 2 eXpress HD
> >> Twinhan/Azurewave VP-1028
> >> Twinhan/Azurewave VP-3071
> >> Twinhan/Azurewave VP-6002
> >> Twinhan/Azurewave VP-6090
> >>
> >> The driver is taken from [1] with adaptations for current mainline,
> >> converted to git and moved to drivers/staging/media. See TODO for
> >> required cleanups (from my point of view, maybe more to come from
> >> additional code review by other developers). I added myself as driver
> >> maintainer to document my commitment to further development to get this
> >> out of staging, help from others welcome.
> >>
> >> This driver was licensed "GPL" from the beginning. S2-6400 firmware is
> >> available at [2].
> >>
> >> I want to preserve the development history of the driver, since this
> >> is mainly work of Andreas Regel, Manu Abraham, and Oliver Endriss.
> >> Unfortunately Andreas seems not to take care of this driver anymore, he
> >> also did not answer my requests to integrate patches for newer kernel
> >> versions. So I send this upstream.
> >>
> >> With all the history this is a 280 part patch series, so I send this as
> >> pull request. Of course I can also send this as 'git send-email' series
> >> if desired.
> >
> >Even on staging, reviewing a 280 patch series take a while ;)
> >
> >As the patches that make it build with current upstream are at the
> >end of the series, you need to be sure that the saa716x Makefile
> >won't be included until those fixes get applied. It seems you took
> >care of it already, with is good!
> >
> >
> >The hole idea of adding a driver to staging is that it will be moved
> >some day out of staging. That's why a TODO and an entry at MAINTAINERS
> >is required.
> >
> >By looking at the saa716x_ff_main:
> >
> >
> https://github.com/s-moch/linux-saa716x/blob/for-media/drivers/staging/media/saa716x/saa716x_ff_main.c
> >
> >I'm seeing that the main problem of this driver is that it still use
> >the API from the legacy ttpci driver, e. g. DVB audio, video and osd APIs.
> >
> >Those APIs were deprecated because they duplicate a functionality
> >provided by the V4L2 API, and are obscure, because they're not
> >properly documented. Also, no other driver uses it upstream.
> >
> >So, it was agreed several years ago that new full featured drivers
> >should use the V4L2 API for audio/video codecs.
> >
> >We have a some drivers that use V4L2 for MPEG audio/video decoding
> >and encoding. The best examples are ivtv and cx18 (as both are for
> >PCI devices). Currently, none of those drivers support the DVB
> >API, though, as they're used only on analog TV devices.
> >
> >It was also agreed that setup pipelines on more complex DVB
> >devices should use the media controller API (MC API).
> >
> >Yet, we don't have, currently, any full featured drivers upstream
> >(except for the legacy one).
> >
> >So, if we're willing to apply this driver, you should be committed
> >to do implement the media APIs properly, porting from DVB
> >audio/video/osd to V4L2 and MC APIs.
> >
> >That should also reflect its TODO:
> >
> >
> https://github.com/s-moch/linux-saa716x/blob/for-media/drivers/staging/media/saa716x/TODO
>
> Thanks for your feedback. I understand all your concerns about the legacy
> API and your request to convert this to v4l2. For me the whole story looks
> a little bit different, though.
>
> The only application which makes use of the decoder part of this saa716x_ff
> driver is VDR (Video Disk Recorder by Klaus Schmidinger, [1] [2]) - if
> anybody else knows about a different use-case, please speak up!
> In fact the high-definition version of VDR (vdr-2.x) was co-developed with
> the S2-6400 hardware and this saa716x_ff driver. So it is no surprise, that
> this driver utilizes the - now legacy - DVB API of the ttpci cards, since
> VDR was originally developed with this API in mind. The missing API
> documentation, besides of course not being ideal, is therefore no real
> problem here, since driver and application are closely tied together.
>
> The S2-6400 card (the only hardware which saa716x_ff supports) only has
> two simple hardware interfaces for the decoder part, a transport stream
> interface for the video/audio decoder, and a DVB API command interface
> for osd. There is no real separate DVB audio interface, audio TS packets
> are simply multiplexed into the video TS stream.
>
> Because there are no complicated hardware interfaces or, e.g., configurable
> processing pipelines, I think a media controller driver is not applicable
> for this hardware, but a v4l2 API would be possible for the video part.
The media controller is now implemented by the DVB core. So, it costs
about nothing to make it work for the DVB part of the board.
> For
> the osd part instead I'm not really sure how to convert this. The DVB osd
> API contains several commands for window and palette management,
> pixel/line/block drawing, and even text rendering. Typical plane/framebuffer
> based overlay APIs are a very bad match for this command-based hardware
> interface. And a full-blown GPU driver only for menu overlays would be quite
> a big effort, especially as we do not need a standard command-to-image
> processing, but a gpu-command to dvb-osd-command conversion. Even now with
> the osd API command processing implemented in the S2-6400 hardware, the
> overlay is relatively slow, this could only become worse with an additional
> translation layer. But let's assume that is all solvable technically.
If I remember well, when we discussed about the OSD API, one of the
original developers said that it could be deprecated, as other APIs
replaced it. I didn't double-checked it personally, as there's no
documentation for such API, and I don't have any FF hardware.
Yet, if the other APIs are a poor match for DVB OSD API, we could revisit
the decision of deprecating this particular API. The main reason for
deprecating this API (besides the comment) is that there's no documentation,
and nobody was interested on solving the documentation issues for it.
> The real problem is not my commitment to convert the DVB video/osd API to
> v4l2. I would do it, although this means huge additional effort. My real
> concern about your request is, with converted DVB APIs in this saa716x_ff
> driver, VDR would not be able to use this driver. So the only known use-case
> would not work anymore, so the whole effort to mainline this driver would
> not make sense for me.
If support for Linux core APIs will be added for FF, applications can
start using it. I would be interested on adding support for it on
Kaffeine, if I can get one such hardware in hands and someone solve
the driver API issues.
One alternative we could do would be to add the proper APIs for the
driver and keep for a couple of Kernel versions, in staging, a module
that would provide backward compatibility to the legacy APIs. This way,
applications will have some time to add support for the new API.
If you're willing to do that, I can merge the patches.
> I agree that new drivers should use modern APIs in the general case. But
> for this driver the legacy DVB decoder API is a hard requirement for me,
> as described. So I hope you will dispense with the v4l2 conversion for
> this special case. I'm pretty sure that there will be no new hardware
> and therefore no new driver with this legacy API, this saa716x_ff driver
> also has a 7-year development history, in this sense it is not really new
> and one could also think of it as some sort of legacy code.
FF hardware is still common on embedded devices. Sooner or later support
for them will be added upstream, and applications that support it
will appear.
> If it helps, I can offer to also take maintainership for the saa7146/ttpci
> drivers, I still have such card in productive use. This way I could at
> least maintain the DVB decoder API code together, as we cannot get rid
> of it.
Drivers added to staging has a limited lifetime: either they fix
the issues or they're removed on some newer Kernel version.
>
> If you got any better idea how to solve this "legacy issue" in a different
> way, I'm glad to help.
>
> Regards,
> Soeren
>
>
> [1] www.tvdr.de
> [2] https://linuxtv.org/vdrwiki
>
Thanks,
Mauro
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [GIT PULL] SAA716x DVB driver
2017-08-27 10:30 ` Mauro Carvalho Chehab
@ 2017-09-09 12:52 ` Soeren Moch
2017-09-09 21:20 ` Mauro Carvalho Chehab
0 siblings, 1 reply; 26+ messages in thread
From: Soeren Moch @ 2017-09-09 12:52 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Greg Kroah-Hartman, Andreas Regel, Manu Abraham, Oliver Endriss,
linux-media
Hi Mauro,
sorry for the late reply, unfortunately your email was filtered out as spam.
On 27.08.2017 12:30, Mauro Carvalho Chehab wrote:
> Em Fri, 21 Jul 2017 22:44:42 +0200
> Soeren Moch <smoch@web.de> escreveu:
>
>> Hi Mauro,
>>
>> On 20.07.2017 07:49:36 -0300, Mauro Carvalho Chehab wrote:
>>> Hi Soeren,
>>>
>>> Em Sun, 16 Jul 2017 20:34:23 +0200
>>> Soeren Moch <smoch@xxxxxx> escreveu:
>>>
>>>> This is a driver for DVB cards based on the SAA7160/62 PCIe bridges from
>>>> Philips/NXP. The most important of these cards, at least for me, is the
>>>> TechnoTrend S2-6400, a high-definition full-featured DVB-S2 card, the
>>>> successor of the famous ttpci decoder cards. Other supported cards are:
>>>> Avermedia H788
>>>> Avermedia HC82 Express-54
>>>> KNC One Dual S2
>>>> KWorld DVB-T PE310
>>>> Technisat SkyStar 2 eXpress HD
>>>> Twinhan/Azurewave VP-1028
>>>> Twinhan/Azurewave VP-3071
>>>> Twinhan/Azurewave VP-6002
>>>> Twinhan/Azurewave VP-6090
>>>>
>>>> The driver is taken from [1] with adaptations for current mainline,
>>>> converted to git and moved to drivers/staging/media. See TODO for
>>>> required cleanups (from my point of view, maybe more to come from
>>>> additional code review by other developers). I added myself as driver
>>>> maintainer to document my commitment to further development to get this
>>>> out of staging, help from others welcome.
>>>>
>>>> This driver was licensed "GPL" from the beginning. S2-6400 firmware is
>>>> available at [2].
>>>>
>>>> I want to preserve the development history of the driver, since this
>>>> is mainly work of Andreas Regel, Manu Abraham, and Oliver Endriss.
>>>> Unfortunately Andreas seems not to take care of this driver anymore, he
>>>> also did not answer my requests to integrate patches for newer kernel
>>>> versions. So I send this upstream.
>>>>
>>>> With all the history this is a 280 part patch series, so I send this as
>>>> pull request. Of course I can also send this as 'git send-email' series
>>>> if desired.
>>> Even on staging, reviewing a 280 patch series take a while ;)
>>>
>>> As the patches that make it build with current upstream are at the
>>> end of the series, you need to be sure that the saa716x Makefile
>>> won't be included until those fixes get applied. It seems you took
>>> care of it already, with is good!
>>>
>>>
>>> The hole idea of adding a driver to staging is that it will be moved
>>> some day out of staging. That's why a TODO and an entry at MAINTAINERS
>>> is required.
>>>
>>> By looking at the saa716x_ff_main:
>>>
>>>
>> https://github.com/s-moch/linux-saa716x/blob/for-media/drivers/staging/media/saa716x/saa716x_ff_main.c
>>> I'm seeing that the main problem of this driver is that it still use
>>> the API from the legacy ttpci driver, e. g. DVB audio, video and osd APIs.
>>>
>>> Those APIs were deprecated because they duplicate a functionality
>>> provided by the V4L2 API, and are obscure, because they're not
>>> properly documented. Also, no other driver uses it upstream.
>>>
>>> So, it was agreed several years ago that new full featured drivers
>>> should use the V4L2 API for audio/video codecs.
>>>
>>> We have a some drivers that use V4L2 for MPEG audio/video decoding
>>> and encoding. The best examples are ivtv and cx18 (as both are for
>>> PCI devices). Currently, none of those drivers support the DVB
>>> API, though, as they're used only on analog TV devices.
>>>
>>> It was also agreed that setup pipelines on more complex DVB
>>> devices should use the media controller API (MC API).
>>>
>>> Yet, we don't have, currently, any full featured drivers upstream
>>> (except for the legacy one).
>>>
>>> So, if we're willing to apply this driver, you should be committed
>>> to do implement the media APIs properly, porting from DVB
>>> audio/video/osd to V4L2 and MC APIs.
>>>
>>> That should also reflect its TODO:
>>>
>>>
>> https://github.com/s-moch/linux-saa716x/blob/for-media/drivers/staging/media/saa716x/TODO
>>
>> Thanks for your feedback. I understand all your concerns about the legacy
>> API and your request to convert this to v4l2. For me the whole story looks
>> a little bit different, though.
>>
>> The only application which makes use of the decoder part of this saa716x_ff
>> driver is VDR (Video Disk Recorder by Klaus Schmidinger, [1] [2]) - if
>> anybody else knows about a different use-case, please speak up!
>> In fact the high-definition version of VDR (vdr-2.x) was co-developed with
>> the S2-6400 hardware and this saa716x_ff driver. So it is no surprise, that
>> this driver utilizes the - now legacy - DVB API of the ttpci cards, since
>> VDR was originally developed with this API in mind. The missing API
>> documentation, besides of course not being ideal, is therefore no real
>> problem here, since driver and application are closely tied together.
>>
>> The S2-6400 card (the only hardware which saa716x_ff supports) only has
>> two simple hardware interfaces for the decoder part, a transport stream
>> interface for the video/audio decoder, and a DVB API command interface
>> for osd. There is no real separate DVB audio interface, audio TS packets
>> are simply multiplexed into the video TS stream.
>>
>> Because there are no complicated hardware interfaces or, e.g., configurable
>> processing pipelines, I think a media controller driver is not applicable
>> for this hardware, but a v4l2 API would be possible for the video part.
> The media controller is now implemented by the DVB core. So, it costs
> about nothing to make it work for the DVB part of the board.
OK, then I will add this this to the TODO list.
>
>> For
>> the osd part instead I'm not really sure how to convert this. The DVB osd
>> API contains several commands for window and palette management,
>> pixel/line/block drawing, and even text rendering. Typical plane/framebuffer
>> based overlay APIs are a very bad match for this command-based hardware
>> interface. And a full-blown GPU driver only for menu overlays would be quite
>> a big effort, especially as we do not need a standard command-to-image
>> processing, but a gpu-command to dvb-osd-command conversion. Even now with
>> the osd API command processing implemented in the S2-6400 hardware, the
>> overlay is relatively slow, this could only become worse with an additional
>> translation layer. But let's assume that is all solvable technically.
> If I remember well, when we discussed about the OSD API, one of the
> original developers said that it could be deprecated, as other APIs
> replaced it. I didn't double-checked it personally, as there's no
> documentation for such API, and I don't have any FF hardware.
>
> Yet, if the other APIs are a poor match for DVB OSD API, we could revisit
> the decision of deprecating this particular API. The main reason for
> deprecating this API (besides the comment) is that there's no documentation,
> and nobody was interested on solving the documentation issues for it.
Maybe another topic for my TODO. But, would that really be helpful?
The only providers of that API (ttpci and saa716x_ff) and the only user
of it (vdr) apparently know how it is supposed to work. You explicitly
want to discourage new driver and application implementations. For me
adding new documentation would guide programmers to the opposite
direction.
I also see the conflict, for you this driver is new, as it should be
merged now, for me it is seven years old. So if this driver will be
merged, this would not change the "deprecated" status of the API. I'm
pretty sure, there will never be another incarnation of a similar type
of FF card.
>> The real problem is not my commitment to convert the DVB video/osd API to
>> v4l2. I would do it, although this means huge additional effort. My real
>> concern about your request is, with converted DVB APIs in this saa716x_ff
>> driver, VDR would not be able to use this driver. So the only known use-case
>> would not work anymore, so the whole effort to mainline this driver would
>> not make sense for me.
> If support for Linux core APIs will be added for FF, applications can
> start using it. I would be interested on adding support for it on
> Kaffeine, if I can get one such hardware in hands and someone solve
> the driver API issues.
With linux core APIs for FF you probably mean some new
API combination as successor of the audio/video/osd API.
The S2-6400 unfortunately directly implements the old API
in hardware and is therefore the worst possible match for
such new driver generation.
For the new API I asked in the other thread [1].
I bought my card at dvbshop.net. It was offered there until several
month ago and seems to be sold out now.
> One alternative we could do would be to add the proper APIs for the
> driver and keep for a couple of Kernel versions, in staging, a module
> that would provide backward compatibility to the legacy APIs. This way,
> applications will have some time to add support for the new API.
>
> If you're willing to do that, I can merge the patches.
Here I do not understand what you expect me to do. The audio/video/osd
devices are closely tied together (as frontend/demux/dvr are for the
input side). The S2-6400 card expects an transport stream with audio and
video packets to be written to that video device (the audio device is
not used) and commands for overlay text/graphics over the osd device.
The osd part you considered to keep as-is. There is no general video
output possible as over a DRM device, there is no GPU processing
possible, and there is no API for video decoding as in a general v4l2
decoder device. This card's decoder only implements exactly the DVB
video and osd devices in hardware (well, card firmware I guess, as
hobbyist programmer I have no access to that), with this somewhat
strange mix of audio and video (for the card it is not strange, as audio
and video are always mux'ed in DVB streams).
>> I agree that new drivers should use modern APIs in the general case. But
>> for this driver the legacy DVB decoder API is a hard requirement for me,
>> as described. So I hope you will dispense with the v4l2 conversion for
>> this special case. I'm pretty sure that there will be no new hardware
>> and therefore no new driver with this legacy API, this saa716x_ff driver
>> also has a 7-year development history, in this sense it is not really new
>> and one could also think of it as some sort of legacy code.
> FF hardware is still common on embedded devices. Sooner or later support
> for them will be added upstream, and applications that support it
> will appear.
Yes, I would really like to get the same functionality as with S2-6400
on modern SoCs (i.MX6Q, Allwinner H5, meson-gxbb Amlogic S905,...)
with modern APIs, in an uniform way, see the other thread.
The goal with this driver submission is not to attract new users
(this will probably not happen, since the S2-6400 seems to be only
available second-hand nowadays) or to encourage application
developers to support this hardware (it was specifically designed
for vdr). My goal is to maintain this driver in mainline to ease
access for existing users, who want to use this driver with new
kernel versions. I got several such requests. An additional side
effect would be to bring support for other hardware (in which
I'm not interested personally) with the saa716x bridge to mainline.
I already received patches from other users to support more
cards in response to this pull request (not on linux-media-mailing-list).
So I hope you will pull this driver without too many change requests.
>
>> If it helps, I can offer to also take maintainership for the saa7146/ttpci
>> drivers, I still have such card in productive use. This way I could at
>> least maintain the DVB decoder API code together, as we cannot get rid
>> of it.
> Drivers added to staging has a limited lifetime: either they fix
> the issues or they're removed on some newer Kernel version.
That's clear.
Regards,
Soeren
[1] https://www.mail-archive.com/linux-media@vger.kernel.org/msg118598.html
>> If you got any better idea how to solve this "legacy issue" in a different
>> way, I'm glad to help.
>>
>> Regards,
>> Soeren
>>
>>
>> [1] www.tvdr.de
>> [2] https://linuxtv.org/vdrwiki
>>
>
>
> Thanks,
> Mauro
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [GIT PULL] SAA716x DVB driver
2017-09-09 12:52 ` Soeren Moch
@ 2017-09-09 21:20 ` Mauro Carvalho Chehab
2017-09-16 12:54 ` Soeren Moch
0 siblings, 1 reply; 26+ messages in thread
From: Mauro Carvalho Chehab @ 2017-09-09 21:20 UTC (permalink / raw)
To: Soeren Moch
Cc: Mauro Carvalho Chehab, Greg Kroah-Hartman, Andreas Regel,
Manu Abraham, Oliver Endriss, linux-media
Em Sat, 9 Sep 2017 14:52:18 +0200
Soeren Moch <smoch@web.de> escreveu:
> Hi Mauro,
>
> sorry for the late reply, unfortunately your email was filtered out as spam.
I'll focus talking about saa716x/av7110 here, as this is out of of
scope of the documentation patches.
>
> On 27.08.2017 12:30, Mauro Carvalho Chehab wrote:
> > Em Fri, 21 Jul 2017 22:44:42 +0200
> > Soeren Moch <smoch@web.de> escreveu:
> >
> >> Hi Mauro,
> >>
> >> On 20.07.2017 07:49:36 -0300, Mauro Carvalho Chehab wrote:
> >>> Hi Soeren,
> >>>
> >>> Em Sun, 16 Jul 2017 20:34:23 +0200
> >>> Soeren Moch <smoch@xxxxxx> escreveu:
> >>>
> >>>> This is a driver for DVB cards based on the SAA7160/62 PCIe bridges from
> >>>> Philips/NXP. The most important of these cards, at least for me, is the
> >>>> TechnoTrend S2-6400, a high-definition full-featured DVB-S2 card, the
> >>>> successor of the famous ttpci decoder cards. Other supported cards are:
> >>>> Avermedia H788
> >>>> Avermedia HC82 Express-54
> >>>> KNC One Dual S2
> >>>> KWorld DVB-T PE310
> >>>> Technisat SkyStar 2 eXpress HD
> >>>> Twinhan/Azurewave VP-1028
> >>>> Twinhan/Azurewave VP-3071
> >>>> Twinhan/Azurewave VP-6002
> >>>> Twinhan/Azurewave VP-6090
> >>>>
> >>>> The driver is taken from [1] with adaptations for current mainline,
> >>>> converted to git and moved to drivers/staging/media. See TODO for
> >>>> required cleanups (from my point of view, maybe more to come from
> >>>> additional code review by other developers). I added myself as driver
> >>>> maintainer to document my commitment to further development to get this
> >>>> out of staging, help from others welcome.
> >>>>
> >>>> This driver was licensed "GPL" from the beginning. S2-6400 firmware is
> >>>> available at [2].
> >>>>
> >>>> I want to preserve the development history of the driver, since this
> >>>> is mainly work of Andreas Regel, Manu Abraham, and Oliver Endriss.
> >>>> Unfortunately Andreas seems not to take care of this driver anymore, he
> >>>> also did not answer my requests to integrate patches for newer kernel
> >>>> versions. So I send this upstream.
> >>>>
> >>>> With all the history this is a 280 part patch series, so I send this as
> >>>> pull request. Of course I can also send this as 'git send-email' series
> >>>> if desired.
> >>> Even on staging, reviewing a 280 patch series take a while ;)
> >>>
> >>> As the patches that make it build with current upstream are at the
> >>> end of the series, you need to be sure that the saa716x Makefile
> >>> won't be included until those fixes get applied. It seems you took
> >>> care of it already, with is good!
> >>>
> >>>
> >>> The hole idea of adding a driver to staging is that it will be moved
> >>> some day out of staging. That's why a TODO and an entry at MAINTAINERS
> >>> is required.
> >>>
> >>> By looking at the saa716x_ff_main:
> >>>
> >>>
> >> https://github.com/s-moch/linux-saa716x/blob/for-media/drivers/staging/media/saa716x/saa716x_ff_main.c
> >>> I'm seeing that the main problem of this driver is that it still use
> >>> the API from the legacy ttpci driver, e. g. DVB audio, video and osd APIs.
> >>>
> >>> Those APIs were deprecated because they duplicate a functionality
> >>> provided by the V4L2 API, and are obscure, because they're not
> >>> properly documented. Also, no other driver uses it upstream.
> >>>
> >>> So, it was agreed several years ago that new full featured drivers
> >>> should use the V4L2 API for audio/video codecs.
> >>>
> >>> We have a some drivers that use V4L2 for MPEG audio/video decoding
> >>> and encoding. The best examples are ivtv and cx18 (as both are for
> >>> PCI devices). Currently, none of those drivers support the DVB
> >>> API, though, as they're used only on analog TV devices.
> >>>
> >>> It was also agreed that setup pipelines on more complex DVB
> >>> devices should use the media controller API (MC API).
> >>>
> >>> Yet, we don't have, currently, any full featured drivers upstream
> >>> (except for the legacy one).
> >>>
> >>> So, if we're willing to apply this driver, you should be committed
> >>> to do implement the media APIs properly, porting from DVB
> >>> audio/video/osd to V4L2 and MC APIs.
> >>>
> >>> That should also reflect its TODO:
> >>>
> >>>
> >> https://github.com/s-moch/linux-saa716x/blob/for-media/drivers/staging/media/saa716x/TODO
> >>
> >> Thanks for your feedback. I understand all your concerns about the legacy
> >> API and your request to convert this to v4l2. For me the whole story looks
> >> a little bit different, though.
> >>
> >> The only application which makes use of the decoder part of this saa716x_ff
> >> driver is VDR (Video Disk Recorder by Klaus Schmidinger, [1] [2]) - if
> >> anybody else knows about a different use-case, please speak up!
> >> In fact the high-definition version of VDR (vdr-2.x) was co-developed with
> >> the S2-6400 hardware and this saa716x_ff driver. So it is no surprise, that
> >> this driver utilizes the - now legacy - DVB API of the ttpci cards, since
> >> VDR was originally developed with this API in mind. The missing API
> >> documentation, besides of course not being ideal, is therefore no real
> >> problem here, since driver and application are closely tied together.
> >>
> >> The S2-6400 card (the only hardware which saa716x_ff supports) only has
> >> two simple hardware interfaces for the decoder part, a transport stream
> >> interface for the video/audio decoder, and a DVB API command interface
> >> for osd. There is no real separate DVB audio interface, audio TS packets
> >> are simply multiplexed into the video TS stream.
> >>
> >> Because there are no complicated hardware interfaces or, e.g., configurable
> >> processing pipelines, I think a media controller driver is not applicable
> >> for this hardware, but a v4l2 API would be possible for the video part.
> > The media controller is now implemented by the DVB core. So, it costs
> > about nothing to make it work for the DVB part of the board.
>
> OK, then I will add this this to the TODO list.
Thanks!
>
> >
> >> For
> >> the osd part instead I'm not really sure how to convert this. The DVB osd
> >> API contains several commands for window and palette management,
> >> pixel/line/block drawing, and even text rendering. Typical plane/framebuffer
> >> based overlay APIs are a very bad match for this command-based hardware
> >> interface. And a full-blown GPU driver only for menu overlays would be quite
> >> a big effort, especially as we do not need a standard command-to-image
> >> processing, but a gpu-command to dvb-osd-command conversion. Even now with
> >> the osd API command processing implemented in the S2-6400 hardware, the
> >> overlay is relatively slow, this could only become worse with an additional
> >> translation layer. But let's assume that is all solvable technically.
> > If I remember well, when we discussed about the OSD API, one of the
> > original developers said that it could be deprecated, as other APIs
> > replaced it. I didn't double-checked it personally, as there's no
> > documentation for such API, and I don't have any FF hardware.
> >
> > Yet, if the other APIs are a poor match for DVB OSD API, we could revisit
> > the decision of deprecating this particular API. The main reason for
> > deprecating this API (besides the comment) is that there's no documentation,
> > and nobody was interested on solving the documentation issues for it.
>
> Maybe another topic for my TODO. But, would that really be helpful?
> The only providers of that API (ttpci and saa716x_ff) and the only user
> of it (vdr) apparently know how it is supposed to work.
The problem with audio/video/osg DVB API is that it seems that nobody
seems to know how this work, except by a couple of persons that used to
work at Convergence between 1999 to 2003, as this was never fully
documented, nor nobody else was able to write a driver or any other
userspace application along all those years.
> You explicitly
> want to discourage new driver and application implementations.
Me? It is just the opposite: sticking with a poorly documented API
that almost nobody knows seems to be what discouraged new drivers
and applications.
> For me
> adding new documentation would guide programmers to the opposite
> direction.
> I also see the conflict, for you this driver is new, as it should be
> merged now, for me it is seven years old. So if this driver will be
> merged, this would not change the "deprecated" status of the API. I'm
> pretty sure, there will never be another incarnation of a similar type
> of FF card.
I see your point.
> >> The real problem is not my commitment to convert the DVB video/osd API to
> >> v4l2. I would do it, although this means huge additional effort. My real
> >> concern about your request is, with converted DVB APIs in this saa716x_ff
> >> driver, VDR would not be able to use this driver. So the only known use-case
> >> would not work anymore, so the whole effort to mainline this driver would
> >> not make sense for me.
> > If support for Linux core APIs will be added for FF, applications can
> > start using it. I would be interested on adding support for it on
> > Kaffeine, if I can get one such hardware in hands and someone solve
> > the driver API issues.
>
> With linux core APIs for FF you probably mean some new
> API combination as successor of the audio/video/osd API.
> The S2-6400 unfortunately directly implements the old API
> in hardware and is therefore the worst possible match for
> such new driver generation.
It sounds weird that the API is directly implemented in hardware.
I can't tell much, though, as I didn't see the code yet.
> For the new API I asked in the other thread [1].
Basically, for a simple FF card that has its own HDMI output and don't
have ways to customize its pipelines (e. g. it is not a nowadays DVB
embedded hardware), you could use DVB frontend/demux APIs + V4L2 API + OSD.
The V4L2 API has enough to control video codecs. There are some examples
about how to do that for ivtv and cx18 drivers. Also, nowadays, several
HDMI drivers got written for it (with both HDMI capture and output).
The V4L2 API has support for lots of HDMI features, including the
ones needed to detect the attached monitor and parse EDID information.
The only missing feature with that is OSD.
V4L2 currently doesn't have support yet for OSD. It shouldn't be hard
to add support for OSD on it, via V4L2 controls, but, provided that
it gets documented and makes sense for more complex FF hardware, I don't
see why not use the DVB OSD API for such purpose.
> I bought my card at dvbshop.net. It was offered there until several
> month ago and seems to be sold out now.
If you're willing to do the right thing with the driver, I'll try to buy
one and see how to add support for it on Kaffeine with the proper APIs.
> > One alternative we could do would be to add the proper APIs for the
> > driver and keep for a couple of Kernel versions, in staging, a module
> > that would provide backward compatibility to the legacy APIs. This way,
> > applications will have some time to add support for the new API.
> >
> > If you're willing to do that, I can merge the patches.
>
> Here I do not understand what you expect me to do. The audio/video/osd
> devices are closely tied together (as frontend/demux/dvr are for the
> input side). The S2-6400 card expects an transport stream with audio and
> video packets to be written to that video device (the audio device is
> not used) and commands for overlay text/graphics over the osd device.
There are two options here:
1) if the hardware itself allows to direct a filtered MPEG-TS to the demod,
by hardware, instead of reading it from /dev/dvb/.../dvr and writing it
to /dev/dvb.../video, you could use the Media Controller to
direct the video PID to the video decoder hardware directly;
The V4L2 driver device node (let's say, /dev/video0) will just
implement the HDMI output.
2) if there's no hardware pipelines between the demux and the decoders,
userspace will read video from .../dvr and write it to a /dev/video0
capture device node, implemented by a mem2mem V4L2 driver.
The mem2mem output device node (let's say, /dev/video1) will control
the HDMI output.
> The osd part you considered to keep as-is. There is no general video
> output possible as over a DRM device, there is no GPU processing
> possible, and there is no API for video decoding as in a general v4l2
> decoder device. This card's decoder only implements exactly the DVB
> video and osd devices in hardware (well, card firmware I guess, as
> hobbyist programmer I have no access to that), with this somewhat
> strange mix of audio and video (for the card it is not strange, as audio
> and video are always mux'ed in DVB streams).
>
> >> I agree that new drivers should use modern APIs in the general case. But
> >> for this driver the legacy DVB decoder API is a hard requirement for me,
> >> as described. So I hope you will dispense with the v4l2 conversion for
> >> this special case. I'm pretty sure that there will be no new hardware
> >> and therefore no new driver with this legacy API, this saa716x_ff driver
> >> also has a 7-year development history, in this sense it is not really new
> >> and one could also think of it as some sort of legacy code.
> > FF hardware is still common on embedded devices. Sooner or later support
> > for them will be added upstream, and applications that support it
> > will appear.
>
> Yes, I would really like to get the same functionality as with S2-6400
> on modern SoCs (i.MX6Q, Allwinner H5, meson-gxbb Amlogic S905,...)
> with modern APIs, in an uniform way, see the other thread.
They likely need a lot more, as modern SoC may have lots of IP
blocks to control (multiple inputs, scalers, mpeg encoding, etc). By
adding MC support, the gaps can be fulfilled.
> The goal with this driver submission is not to attract new users
> (this will probably not happen, since the S2-6400 seems to be only
> available second-hand nowadays) or to encourage application
> developers to support this hardware (it was specifically designed
> for vdr). My goal is to maintain this driver in mainline to ease
> access for existing users, who want to use this driver with new
> kernel versions. I got several such requests. An additional side
> effect would be to bring support for other hardware (in which
> I'm not interested personally) with the saa716x bridge to mainline.
> I already received patches from other users to support more
> cards in response to this pull request (not on linux-media-mailing-list).
>
> So I hope you will pull this driver without too many change requests.
>
> >
> >> If it helps, I can offer to also take maintainership for the saa7146/ttpci
> >> drivers, I still have such card in productive use. This way I could at
> >> least maintain the DVB decoder API code together, as we cannot get rid
> >> of it.
> > Drivers added to staging has a limited lifetime: either they fix
> > the issues or they're removed on some newer Kernel version.
>
> That's clear.
>
> Regards,
> Soeren
>
> [1] https://www.mail-archive.com/linux-media@vger.kernel.org/msg118598.html
>
> >> If you got any better idea how to solve this "legacy issue" in a different
> >> way, I'm glad to help.
> >>
> >> Regards,
> >> Soeren
> >>
> >>
> >> [1] www.tvdr.de
> >> [2] https://linuxtv.org/vdrwiki
> >>
> >
> >
> > Thanks,
> > Mauro
>
>
Thanks,
Mauro
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [GIT PULL] SAA716x DVB driver
2017-09-09 21:20 ` Mauro Carvalho Chehab
@ 2017-09-16 12:54 ` Soeren Moch
2017-09-16 17:49 ` Mauro Carvalho Chehab
0 siblings, 1 reply; 26+ messages in thread
From: Soeren Moch @ 2017-09-16 12:54 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Mauro Carvalho Chehab, Greg Kroah-Hartman, Andreas Regel,
Manu Abraham, Oliver Endriss, linux-media
On 09.09.2017 23:20, Mauro Carvalho Chehab wrote:
> Em Sat, 9 Sep 2017 14:52:18 +0200
> Soeren Moch <smoch@web.de> escreveu:
>
>> Hi Mauro,
>>
>> sorry for the late reply, unfortunately your email was filtered out as spam.
> I'll focus talking about saa716x/av7110 here, as this is out of of
> scope of the documentation patches.
>
>> On 27.08.2017 12:30, Mauro Carvalho Chehab wrote:
>>> Em Fri, 21 Jul 2017 22:44:42 +0200
>>> Soeren Moch <smoch@web.de> escreveu:
>>>
>>>> Hi Mauro,
>>>>
>>>> On 20.07.2017 07:49:36 -0300, Mauro Carvalho Chehab wrote:
>>>>> Hi Soeren,
>>>>>
>>>>> Em Sun, 16 Jul 2017 20:34:23 +0200
>>>>> Soeren Moch <smoch@xxxxxx> escreveu:
>>>>>
>>>>>> This is a driver for DVB cards based on the SAA7160/62 PCIe bridges from
>>>>>> Philips/NXP. The most important of these cards, at least for me, is the
>>>>>> TechnoTrend S2-6400, a high-definition full-featured DVB-S2 card, the
>>>>>> successor of the famous ttpci decoder cards. Other supported cards are:
>>>>>> Avermedia H788
>>>>>> Avermedia HC82 Express-54
>>>>>> KNC One Dual S2
>>>>>> KWorld DVB-T PE310
>>>>>> Technisat SkyStar 2 eXpress HD
>>>>>> Twinhan/Azurewave VP-1028
>>>>>> Twinhan/Azurewave VP-3071
>>>>>> Twinhan/Azurewave VP-6002
>>>>>> Twinhan/Azurewave VP-6090
>>>>>>
>>>>>> The driver is taken from [1] with adaptations for current mainline,
>>>>>> converted to git and moved to drivers/staging/media. See TODO for
>>>>>> required cleanups (from my point of view, maybe more to come from
>>>>>> additional code review by other developers). I added myself as driver
>>>>>> maintainer to document my commitment to further development to get this
>>>>>> out of staging, help from others welcome.
>>>>>>
>>>>>> This driver was licensed "GPL" from the beginning. S2-6400 firmware is
>>>>>> available at [2].
>>>>>>
>>>>>> I want to preserve the development history of the driver, since this
>>>>>> is mainly work of Andreas Regel, Manu Abraham, and Oliver Endriss.
>>>>>> Unfortunately Andreas seems not to take care of this driver anymore, he
>>>>>> also did not answer my requests to integrate patches for newer kernel
>>>>>> versions. So I send this upstream.
>>>>>>
>>>>>> With all the history this is a 280 part patch series, so I send this as
>>>>>> pull request. Of course I can also send this as 'git send-email' series
>>>>>> if desired.
>>>>> Even on staging, reviewing a 280 patch series take a while ;)
>>>>>
>>>>> As the patches that make it build with current upstream are at the
>>>>> end of the series, you need to be sure that the saa716x Makefile
>>>>> won't be included until those fixes get applied. It seems you took
>>>>> care of it already, with is good!
>>>>>
>>>>>
>>>>> The hole idea of adding a driver to staging is that it will be moved
>>>>> some day out of staging. That's why a TODO and an entry at MAINTAINERS
>>>>> is required.
>>>>>
>>>>> By looking at the saa716x_ff_main:
>>>>>
>>>>>
>>>> https://github.com/s-moch/linux-saa716x/blob/for-media/drivers/staging/media/saa716x/saa716x_ff_main.c
>>>>> I'm seeing that the main problem of this driver is that it still use
>>>>> the API from the legacy ttpci driver, e. g. DVB audio, video and osd APIs.
>>>>>
>>>>> Those APIs were deprecated because they duplicate a functionality
>>>>> provided by the V4L2 API, and are obscure, because they're not
>>>>> properly documented. Also, no other driver uses it upstream.
>>>>>
>>>>> So, it was agreed several years ago that new full featured drivers
>>>>> should use the V4L2 API for audio/video codecs.
>>>>>
>>>>> We have a some drivers that use V4L2 for MPEG audio/video decoding
>>>>> and encoding. The best examples are ivtv and cx18 (as both are for
>>>>> PCI devices). Currently, none of those drivers support the DVB
>>>>> API, though, as they're used only on analog TV devices.
>>>>>
>>>>> It was also agreed that setup pipelines on more complex DVB
>>>>> devices should use the media controller API (MC API).
>>>>>
>>>>> Yet, we don't have, currently, any full featured drivers upstream
>>>>> (except for the legacy one).
>>>>>
>>>>> So, if we're willing to apply this driver, you should be committed
>>>>> to do implement the media APIs properly, porting from DVB
>>>>> audio/video/osd to V4L2 and MC APIs.
>>>>>
>>>>> That should also reflect its TODO:
>>>>>
>>>>>
>>>> https://github.com/s-moch/linux-saa716x/blob/for-media/drivers/staging/media/saa716x/TODO
>>>>
>>>> Thanks for your feedback. I understand all your concerns about the legacy
>>>> API and your request to convert this to v4l2. For me the whole story looks
>>>> a little bit different, though.
>>>>
>>>> The only application which makes use of the decoder part of this saa716x_ff
>>>> driver is VDR (Video Disk Recorder by Klaus Schmidinger, [1] [2]) - if
>>>> anybody else knows about a different use-case, please speak up!
>>>> In fact the high-definition version of VDR (vdr-2.x) was co-developed with
>>>> the S2-6400 hardware and this saa716x_ff driver. So it is no surprise, that
>>>> this driver utilizes the - now legacy - DVB API of the ttpci cards, since
>>>> VDR was originally developed with this API in mind. The missing API
>>>> documentation, besides of course not being ideal, is therefore no real
>>>> problem here, since driver and application are closely tied together.
>>>>
>>>> The S2-6400 card (the only hardware which saa716x_ff supports) only has
>>>> two simple hardware interfaces for the decoder part, a transport stream
>>>> interface for the video/audio decoder, and a DVB API command interface
>>>> for osd. There is no real separate DVB audio interface, audio TS packets
>>>> are simply multiplexed into the video TS stream.
>>>>
>>>> Because there are no complicated hardware interfaces or, e.g., configurable
>>>> processing pipelines, I think a media controller driver is not applicable
>>>> for this hardware, but a v4l2 API would be possible for the video part.
>>> The media controller is now implemented by the DVB core. So, it costs
>>> about nothing to make it work for the DVB part of the board.
>> OK, then I will add this this to the TODO list.
> Thanks!
>
>>>
>>>> For
>>>> the osd part instead I'm not really sure how to convert this. The DVB osd
>>>> API contains several commands for window and palette management,
>>>> pixel/line/block drawing, and even text rendering. Typical plane/framebuffer
>>>> based overlay APIs are a very bad match for this command-based hardware
>>>> interface. And a full-blown GPU driver only for menu overlays would be quite
>>>> a big effort, especially as we do not need a standard command-to-image
>>>> processing, but a gpu-command to dvb-osd-command conversion. Even now with
>>>> the osd API command processing implemented in the S2-6400 hardware, the
>>>> overlay is relatively slow, this could only become worse with an additional
>>>> translation layer. But let's assume that is all solvable technically.
>>> If I remember well, when we discussed about the OSD API, one of the
>>> original developers said that it could be deprecated, as other APIs
>>> replaced it. I didn't double-checked it personally, as there's no
>>> documentation for such API, and I don't have any FF hardware.
>>>
>>> Yet, if the other APIs are a poor match for DVB OSD API, we could revisit
>>> the decision of deprecating this particular API. The main reason for
>>> deprecating this API (besides the comment) is that there's no documentation,
>>> and nobody was interested on solving the documentation issues for it.
>> Maybe another topic for my TODO. But, would that really be helpful?
>> The only providers of that API (ttpci and saa716x_ff) and the only user
>> of it (vdr) apparently know how it is supposed to work.
> The problem with audio/video/osg DVB API is that it seems that nobody
> seems to know how this work, except by a couple of persons that used to
> work at Convergence between 1999 to 2003, as this was never fully
> documented, nor nobody else was able to write a driver or any other
> userspace application along all those years.
OK, from this driver you can see that Andreas Regel was able
to write this driver and at least also people at Technotrend
understood how to use the audio/video/osd API.
>> You explicitly
>> want to discourage new driver and application implementations.
> Me? It is just the opposite: sticking with a poorly documented API
> that almost nobody knows seems to be what discouraged new drivers
> and applications.
OK, then you are fine to keep the audio/video/osd API in this driver, great!
>> For me
>> adding new documentation would guide programmers to the opposite
>> direction.
>> I also see the conflict, for you this driver is new, as it should be
>> merged now, for me it is seven years old. So if this driver will be
>> merged, this would not change the "deprecated" status of the API. I'm
>> pretty sure, there will never be another incarnation of a similar type
>> of FF card.
> I see your point.
>
>>>> The real problem is not my commitment to convert the DVB video/osd API to
>>>> v4l2. I would do it, although this means huge additional effort. My real
>>>> concern about your request is, with converted DVB APIs in this saa716x_ff
>>>> driver, VDR would not be able to use this driver. So the only known use-case
>>>> would not work anymore, so the whole effort to mainline this driver would
>>>> not make sense for me.
>>> If support for Linux core APIs will be added for FF, applications can
>>> start using it. I would be interested on adding support for it on
>>> Kaffeine, if I can get one such hardware in hands and someone solve
>>> the driver API issues.
>> With linux core APIs for FF you probably mean some new
>> API combination as successor of the audio/video/osd API.
>> The S2-6400 unfortunately directly implements the old API
>> in hardware and is therefore the worst possible match for
>> such new driver generation.
> It sounds weird that the API is directly implemented in hardware.
> I can't tell much, though, as I didn't see the code yet.
All the available code is in this pull request.
>> For the new API I asked in the other thread [1].
> Basically, for a simple FF card that has its own HDMI output and don't
> have ways to customize its pipelines (e. g. it is not a nowadays DVB
> embedded hardware), you could use DVB frontend/demux APIs + V4L2 API + OSD.
>
> The V4L2 API has enough to control video codecs. There are some examples
> about how to do that for ivtv and cx18 drivers. Also, nowadays, several
> HDMI drivers got written for it (with both HDMI capture and output).
>
> The V4L2 API has support for lots of HDMI features, including the
> ones needed to detect the attached monitor and parse EDID information.
>
> The only missing feature with that is OSD.
>
> V4L2 currently doesn't have support yet for OSD. It shouldn't be hard
> to add support for OSD on it, via V4L2 controls, but, provided that
> it gets documented and makes sense for more complex FF hardware, I don't
> see why not use the DVB OSD API for such purpose.
>
>> I bought my card at dvbshop.net. It was offered there until several
>> month ago and seems to be sold out now.
> If you're willing to do the right thing with the driver, I'll try to buy
> one and see how to add support for it on Kaffeine with the proper APIs.
I really don't understand your Kaffeine use case. Kaffeine is a media
player, which displays the decoded video on a KDE/Gnome desktop.
With the S2-6400 it is not possible to read the decoded video back,
so it is not possible to display something in a desktop window.
I cannot image what you want to do with this hardware and Kaffeine.
>>> One alternative we could do would be to add the proper APIs for the
>>> driver and keep for a couple of Kernel versions, in staging, a module
>>> that would provide backward compatibility to the legacy APIs. This way,
>>> applications will have some time to add support for the new API.
>>>
>>> If you're willing to do that, I can merge the patches.
>> Here I do not understand what you expect me to do. The audio/video/osd
>> devices are closely tied together (as frontend/demux/dvr are for the
>> input side). The S2-6400 card expects an transport stream with audio and
>> video packets to be written to that video device (the audio device is
>> not used) and commands for overlay text/graphics over the osd device.
> There are two options here:
>
> 1) if the hardware itself allows to direct a filtered MPEG-TS to the demod,
> by hardware, instead of reading it from /dev/dvb/.../dvr and writing it
> to /dev/dvb.../video, you could use the Media Controller to
> direct the video PID to the video decoder hardware directly;
This is what you want me to implement: this shortcut from
/dev/dvb/.../dvr to /dev/dvb.../video ? Since you said above that this
is already implemented in the dvb core, this should be easy and.
can of course be implemented in this driver.
> The V4L2 driver device node (let's say, /dev/video0) will just
> implement the HDMI output.
There is no separate decoder / HDMI hardware, from the driver's
point of view. The decoded video directly goes to the HDMI output.
> 2) if there's no hardware pipelines between the demux and the decoders,
> userspace will read video from .../dvr and write it to a /dev/video
> capture device node, implemented by a mem2mem V4L2 driver.
There cannot be a separate capture device node for the decoded
video. You probably refer to the video_cature:one-shot feature,
which is switched off by default.
This is a debug feature, which vdr supports. It is intended to
take a snapshot of the output image, something for debugging
vdr-skins, the graphical user interface of vdr.
>From the msleep(100); in the read path you can easily see, that
this is meant for still images, not for video. Due to bandwidth
limitations on the hardware this should normally not be used
during normal decoding.
> The mem2mem output device node (let's say, /dev/video1) will control
> the HDMI output.
As mentioned several times, it is only possible to write a transport
stream to the video device, and osd commands to the osd device.
There is no hardware interface to directly access the HDMI output.
So it is not possible to create a separate v4l2 HDMI output device.
>> The osd part you considered to keep as-is. There is no general video
>> output possible as over a DRM device, there is no GPU processing
>> possible, and there is no API for video decoding as in a general v4l2
>> decoder device. This card's decoder only implements exactly the DVB
>> video and osd devices in hardware (well, card firmware I guess, as
>> hobbyist programmer I have no access to that), with this somewhat
>> strange mix of audio and video (for the card it is not strange, as audio
>> and video are always mux'ed in DVB streams).
>>
>>>> I agree that new drivers should use modern APIs in the general case. But
>>>> for this driver the legacy DVB decoder API is a hard requirement for me,
>>>> as described. So I hope you will dispense with the v4l2 conversion for
>>>> this special case. I'm pretty sure that there will be no new hardware
>>>> and therefore no new driver with this legacy API, this saa716x_ff driver
>>>> also has a 7-year development history, in this sense it is not really new
>>>> and one could also think of it as some sort of legacy code.
>>> FF hardware is still common on embedded devices. Sooner or later support
>>> for them will be added upstream, and applications that support it
>>> will appear.
>> Yes, I would really like to get the same functionality as with S2-6400
>> on modern SoCs (i.MX6Q, Allwinner H5, meson-gxbb Amlogic S905,...)
>> with modern APIs, in an uniform way, see the other thread.
> They likely need a lot more, as modern SoC may have lots of IP
> blocks to control (multiple inputs, scalers, mpeg encoding, etc). By
> adding MC support, the gaps can be fulfilled.
Maybe this is a misunderstanding here. I do not plan to support
other hardware with this saa716x_ff driver. The other thread [1]
about documentation of modern APIs for modern SoCs is somewhat
related, but independent from this driver for the S2-6400.
This driver as successor of ttpci must implement the same DVB API
to support existing users.
Drivers for modern hardware may use other APIs, please answer
about this in the other thread (or maybe in a new one, if this is more
appropriate).
Regards,
Soeren
>
>> The goal with this driver submission is not to attract new users
>> (this will probably not happen, since the S2-6400 seems to be only
>> available second-hand nowadays) or to encourage application
>> developers to support this hardware (it was specifically designed
>> for vdr). My goal is to maintain this driver in mainline to ease
>> access for existing users, who want to use this driver with new
>> kernel versions. I got several such requests. An additional side
>> effect would be to bring support for other hardware (in which
>> I'm not interested personally) with the saa716x bridge to mainline.
>> I already received patches from other users to support more
>> cards in response to this pull request (not on linux-media-mailing-list).
>>
>> So I hope you will pull this driver without too many change requests.
>>
>>>
>>>> If it helps, I can offer to also take maintainership for the saa7146/ttpci
>>>> drivers, I still have such card in productive use. This way I could at
>>>> least maintain the DVB decoder API code together, as we cannot get rid
>>>> of it.
>>> Drivers added to staging has a limited lifetime: either they fix
>>> the issues or they're removed on some newer Kernel version.
>> That's clear.
>>
>> Regards,
>> Soeren
>>
>> [1] https://www.mail-archive.com/linux-media@vger.kernel.org/msg118598.html
>>
>>>> If you got any better idea how to solve this "legacy issue" in a different
>>>> way, I'm glad to help.
>>>>
>>>> Regards,
>>>> Soeren
>>>>
>>>>
>>>> [1] www.tvdr.de
>>>> [2] https://linuxtv.org/vdrwiki
>>>>
>>> Thanks,
>>> Mauro
>
> Thanks,
> Mauro
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [GIT PULL] SAA716x DVB driver
2017-09-16 12:54 ` Soeren Moch
@ 2017-09-16 17:49 ` Mauro Carvalho Chehab
2017-09-24 22:17 ` Soeren Moch
0 siblings, 1 reply; 26+ messages in thread
From: Mauro Carvalho Chehab @ 2017-09-16 17:49 UTC (permalink / raw)
To: Soeren Moch
Cc: Mauro Carvalho Chehab, Greg Kroah-Hartman, Andreas Regel,
Manu Abraham, Oliver Endriss, linux-media, Eugene Syromiatnikov,
Arnd Bergmann
Em Sat, 16 Sep 2017 14:54:15 +0200
Soeren Moch <smoch@web.de> escreveu:
> On 09.09.2017 23:20, Mauro Carvalho Chehab wrote:
> > Em Sat, 9 Sep 2017 14:52:18 +0200
> > Soeren Moch <smoch@web.de> escreveu:
> >
> >> You explicitly
> >> want to discourage new driver and application implementations.
> > Me? It is just the opposite: sticking with a poorly documented API
> > that almost nobody knows seems to be what discouraged new drivers
> > and applications.
> OK, then you are fine to keep the audio/video/osd API in this driver, great!
My current understanding is that keeping audio/video API doesn't make
any sense, for a couple of reasons:
1. it was never fully documented;
2. the only upstream hardware that supports them was developed on
about 17 years ago;
3. the API is broken with regards to compat32 and Y2038 (see more
below);
4. almost all (if not all) features they support are also supported
by V4L2 and ALSA;
5. V4L2 supports a lot more features that video decoders support
than video API, like H.264 and other newer video standards, plus
HDMI setup features.
In the past, we tried a lot to get documentation for those
DVB APIs, but, unfortunately, nobody that worked on its development
sent us patches addressing the API documentation.
With regards to OSD, as no other documented API emerged to
fulfill what it does, it could make sense to keep it, if
someone properly documents it.
> >> With linux core APIs for FF you probably mean some new
> >> API combination as successor of the audio/video/osd API.
> >> The S2-6400 unfortunately directly implements the old API
> >> in hardware and is therefore the worst possible match for
> >> such new driver generation.
> > It sounds weird that the API is directly implemented in hardware.
> > I can't tell much, though, as I didn't see the code yet.
> All the available code is in this pull request.
I know. I'll look on it if we reach an agreement.
> I really don't understand your Kaffeine use case. Kaffeine is a media
> player, which displays the decoded video on a KDE/Gnome desktop.
> With the S2-6400 it is not possible to read the decoded video back,
> so it is not possible to display something in a desktop window.
> I cannot image what you want to do with this hardware and Kaffeine.
I see.
> >>> One alternative we could do would be to add the proper APIs for the
> >>> driver and keep for a couple of Kernel versions, in staging, a module
> >>> that would provide backward compatibility to the legacy APIs. This way,
> >>> applications will have some time to add support for the new API.
> >>>
> >>> If you're willing to do that, I can merge the patches.
> >> Here I do not understand what you expect me to do. The audio/video/osd
> >> devices are closely tied together (as frontend/demux/dvr are for the
> >> input side). The S2-6400 card expects an transport stream with audio and
> >> video packets to be written to that video device (the audio device is
> >> not used) and commands for overlay text/graphics over the osd device.
> > There are two options here:
> >
> > 1) if the hardware itself allows to direct a filtered MPEG-TS to the demod,
> > by hardware, instead of reading it from /dev/dvb/.../dvr and writing it
> > to /dev/dvb.../video, you could use the Media Controller to
> > direct the video PID to the video decoder hardware directly;
> This is what you want me to implement: this shortcut from
> /dev/dvb/.../dvr to /dev/dvb.../video ? Since you said above that this
> is already implemented in the dvb core, this should be easy and.
> can of course be implemented in this driver.
> > The V4L2 driver device node (let's say, /dev/video0) will just
> > implement the HDMI output.
> There is no separate decoder / HDMI hardware, from the driver's
> point of view. The decoded video directly goes to the HDMI output.
If there's nothing that can be controlled at the HDMI output, why do
you need a /dev/dvb.../video devnode? If it can be controlled, a
V4L2 output will do the job.
> > 2) if there's no hardware pipelines between the demux and the decoders,
> > userspace will read video from .../dvr and write it to a /dev/video
> > capture device node, implemented by a mem2mem V4L2 driver.
> There cannot be a separate capture device node for the decoded
> video. You probably refer to the video_cature:one-shot feature,
> which is switched off by default.
> This is a debug feature, which vdr supports. It is intended to
> take a snapshot of the output image, something for debugging
> vdr-skins, the graphical user interface of vdr.
Ah, so it can't play an arbitrary MPEG-TS stream from other
sources, right?
> From the msleep(100); in the read path you can easily see, that
> this is meant for still images, not for video. Due to bandwidth
> limitations on the hardware this should normally not be used
> during normal decoding.
> > The mem2mem output device node (let's say, /dev/video1) will control
> > the HDMI output.
> As mentioned several times, it is only possible to write a transport
> stream to the video device, and osd commands to the osd device.
Hmm... now, I'm confused. Can it play a MPEG-TS video stored at the
computer or not?
> There is no hardware interface to directly access the HDMI output.
> So it is not possible to create a separate v4l2 HDMI output device.
> >> The osd part you considered to keep as-is. There is no general video
> >> output possible as over a DRM device, there is no GPU processing
> >> possible, and there is no API for video decoding as in a general v4l2
> >> decoder device. This card's decoder only implements exactly the DVB
> >> video and osd devices in hardware (well, card firmware I guess, as
> >> hobbyist programmer I have no access to that), with this somewhat
> >> strange mix of audio and video (for the card it is not strange, as audio
> >> and video are always mux'ed in DVB streams).
> >>
> >>>> I agree that new drivers should use modern APIs in the general case. But
> >>>> for this driver the legacy DVB decoder API is a hard requirement for me,
> >>>> as described. So I hope you will dispense with the v4l2 conversion for
> >>>> this special case. I'm pretty sure that there will be no new hardware
> >>>> and therefore no new driver with this legacy API, this saa716x_ff driver
> >>>> also has a 7-year development history, in this sense it is not really new
> >>>> and one could also think of it as some sort of legacy code.
> >>> FF hardware is still common on embedded devices. Sooner or later support
> >>> for them will be added upstream, and applications that support it
> >>> will appear.
> >> Yes, I would really like to get the same functionality as with S2-6400
> >> on modern SoCs (i.MX6Q, Allwinner H5, meson-gxbb Amlogic S905,...)
> >> with modern APIs, in an uniform way, see the other thread.
> > They likely need a lot more, as modern SoC may have lots of IP
> > blocks to control (multiple inputs, scalers, mpeg encoding, etc). By
> > adding MC support, the gaps can be fulfilled.
> Maybe this is a misunderstanding here. I do not plan to support
> other hardware with this saa716x_ff driver. The other thread [1]
> about documentation of modern APIs for modern SoCs is somewhat
> related, but independent from this driver for the S2-6400.
> This driver as successor of ttpci must implement the same DVB API
> to support existing users.
>
> Drivers for modern hardware may use other APIs, please answer
> about this in the other thread (or maybe in a new one, if this is more
> appropriate).
Yeah, perhaps there's a misunderstanding here. What we currently have
upstream is a single driver (av7110) that supports a hardware, developed
about 17 years ago, and that it is out of production for a long time.
We should remove this driver some day, but, as there isn't any strong
reason to remove, it is staying (and so the API header files to talk
with it).
Actually, a couple of weeks before your saa716x pull request, there was
a report that the current DVB video API is broken with regards to
compat32 and fix would break kABI [1]. It is also incompatible with
Y2038 fixes that are happening system wide. So, perhaps is time to
get rid of it for good.
[1] see https://patchwork.kernel.org/patch/7187851/ and related
e-mails.
If/when we add another full-featured DVB hardware (outside staging),
as the API defined on audio/video is too old (from the time that all
video decoders were MPEG 2), and it didn't receive any updates to
support modern hardware, it is unlikely that it would work for such
hardware. I bet that using V4L2/ALSA (perhaps with a few minor additions)
would work a way better, as those APIs always got updatates as new audio
and video codecs got added. The V4L2 also supports the needed bits to
detect HDMI monitors and adjust parameters like resolution, 3D mode
and fps rate there.
Now, on this thread you're proposing to add another driver using
DVB video obsolete (and Y2028 broken) API. What I'm saying is that,
if we're adding it on staging, we need to have a plan to reimplement
it to whatever API replaces the DVB video API, as this API likely
won't stay upstream much longer.
Thanks,
Mauro
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [GIT PULL] SAA716x DVB driver
2017-09-16 17:49 ` Mauro Carvalho Chehab
@ 2017-09-24 22:17 ` Soeren Moch
2017-11-24 16:28 ` Tycho Lürsen
2017-11-28 18:35 ` [GIT PULL] " Mauro Carvalho Chehab
0 siblings, 2 replies; 26+ messages in thread
From: Soeren Moch @ 2017-09-24 22:17 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Mauro Carvalho Chehab, Greg Kroah-Hartman, Andreas Regel,
Manu Abraham, Oliver Endriss, linux-media, Eugene Syromiatnikov,
Arnd Bergmann
On 16.09.2017 19:49, Mauro Carvalho Chehab wrote:
> Em Sat, 16 Sep 2017 14:54:15 +0200
> Soeren Moch <smoch@web.de> escreveu:
>
>> On 09.09.2017 23:20, Mauro Carvalho Chehab wrote:
>>> Em Sat, 9 Sep 2017 14:52:18 +0200
>>> Soeren Moch <smoch@web.de> escreveu:
>>>
>>>> You explicitly
>>>> want to discourage new driver and application implementations.
>>> Me? It is just the opposite: sticking with a poorly documented API
>>> that almost nobody knows seems to be what discouraged new drivers
>>> and applications.
>> OK, then you are fine to keep the audio/video/osd API in this driver, great!
> My current understanding is that keeping audio/video API doesn't make
> any sense, for a couple of reasons:
For me, keeping this interface makes a lot of sense.
> 1. it was never fully documented;
Nothing what prevents existing drivers to work, and new drivers
to be written, as can be seen from this pull request.
> 2. the only upstream hardware that supports them was developed on
> about 17 years ago;
But was sold for several years in lots of different versions,
even hardware modifications were developed and applied
by lots of users to improve the performance of these cards,
and most important, these cards are still in use.
> 3. the API is broken with regards to compat32 and Y2038 (see more
> below);
Not unique for this driver and, since this API has no business
with wall clock time, not too complicated to fix.
> 4. almost all (if not all) features they support are also supported
> by V4L2 and ALSA;
Here we come to the point. The DVB audio/video API just
works, there are working drivers, working applications (vdr)
and happy users.
The audio/video/osd device nodes are nicely grouped below
1 adapter, so it is immediately clear, which devices belong
together. It is very easy to implement the classic multimedia
set-top box use case (audio and video decoding with menu
overlays). For this use case it is the ideal interface.
You propose V4L2/ALSA instead, what has "almost all features".
May be, but "almost all" is not all, and a collection of features
does not give us a working system. /dev/videoX device names
are not stable across boots, it is even more complicated to
find matching devices for different hardware with otherwise
similar capabilities. With V4L2/ALSA there is no real A/V
synchronisation, selected ALSA devices are reassigned during
suspend or even HDMI hotplug. So audio gets lost when
switching the monitor off and on again.
So while audio/video/osd is an integrated multimedia
interface with working drivers and happy users, for me
V4L2/ALSA is not ready to immediately replace it.
> 5. V4L2 supports a lot more features that video decoders support
> than video API, like H.264 and other newer video standards, plus
> HDMI setup features.
The S2-6400 card also decodes H.264, and the API is not
limited to any set of video coding standards. This card
decodes frame synchronous audio and video and correctly
signals audio/video formats in HDMI AVI frames (e.g.
AC3 / PCM audio, video aspect ratios,...). You did not explain
how this should work with V4L2/ALSA.
For other use cases other types of v4l2 devices could be
more appropriate. The two APIs coexist for years in
mainline linux without problems.
> In the past, we tried a lot to get documentation for those
> DVB APIs, but, unfortunately, nobody that worked on its development
> sent us patches addressing the API documentation.
You probably know why the ttpci developers stopped
sending patches to linux-media.
> With regards to OSD, as no other documented API emerged to
> fulfill what it does, it could make sense to keep it, if
> someone properly documents it.
>
>>>> With linux core APIs for FF you probably mean some new
>>>> API combination as successor of the audio/video/osd API.
>>>> The S2-6400 unfortunately directly implements the old API
>>>> in hardware and is therefore the worst possible match for
>>>> such new driver generation.
>>> It sounds weird that the API is directly implemented in hardware.
>>> I can't tell much, though, as I didn't see the code yet.
>> All the available code is in this pull request.
> I know. I'll look on it if we reach an agreement.
>
>> I really don't understand your Kaffeine use case. Kaffeine is a media
>> player, which displays the decoded video on a KDE/Gnome desktop.
>> With the S2-6400 it is not possible to read the decoded video back,
>> so it is not possible to display something in a desktop window.
>> I cannot image what you want to do with this hardware and Kaffeine.
> I see.
>
>>>>> One alternative we could do would be to add the proper APIs for the
>>>>> driver and keep for a couple of Kernel versions, in staging, a module
>>>>> that would provide backward compatibility to the legacy APIs. This way,
>>>>> applications will have some time to add support for the new API.
>>>>>
>>>>> If you're willing to do that, I can merge the patches.
>>>> Here I do not understand what you expect me to do. The audio/video/osd
>>>> devices are closely tied together (as frontend/demux/dvr are for the
>>>> input side). The S2-6400 card expects an transport stream with audio and
>>>> video packets to be written to that video device (the audio device is
>>>> not used) and commands for overlay text/graphics over the osd device.
>>> There are two options here:
>>>
>>> 1) if the hardware itself allows to direct a filtered MPEG-TS to the demod,
>>> by hardware, instead of reading it from /dev/dvb/.../dvr and writing it
>>> to /dev/dvb.../video, you could use the Media Controller to
>>> direct the video PID to the video decoder hardware directly;
>> This is what you want me to implement: this shortcut from
>> /dev/dvb/.../dvr to /dev/dvb.../video ? Since you said above that this
>> is already implemented in the dvb core, this should be easy and.
>> can of course be implemented in this driver.
>>> The V4L2 driver device node (let's say, /dev/video0) will just
>>> implement the HDMI output.
>> There is no separate decoder / HDMI hardware, from the driver's
>> point of view. The decoded video directly goes to the HDMI output.
> If there's nothing that can be controlled at the HDMI output, why do
> you need a /dev/dvb.../video devnode? If it can be controlled, a
> V4L2 output will do the job.
As I wrote several times, the TS stream, which will be decoded,
is written to /dev/dvb/adapterX/video.
>>> 2) if there's no hardware pipelines between the demux and the decoders,
>>> userspace will read video from .../dvr and write it to a /dev/video
>>> capture device node, implemented by a mem2mem V4L2 driver.
>> There cannot be a separate capture device node for the decoded
>> video. You probably refer to the video_cature:one-shot feature,
>> which is switched off by default.
>> This is a debug feature, which vdr supports. It is intended to
>> take a snapshot of the output image, something for debugging
>> vdr-skins, the graphical user interface of vdr.
> Ah, so it can't play an arbitrary MPEG-TS stream from other
> sources, right?
The card will decode the TS stream written to the video device
and display the decoded audio and video over HDMI.
>
>> From the msleep(100); in the read path you can easily see, that
>> this is meant for still images, not for video. Due to bandwidth
>> limitations on the hardware this should normally not be used
>> during normal decoding.
>>> The mem2mem output device node (let's say, /dev/video1) will control
>>> the HDMI output.
>> As mentioned several times, it is only possible to write a transport
>> stream to the video device, and osd commands to the osd device.
> Hmm... now, I'm confused. Can it play a MPEG-TS video stored at the
> computer or not?
The TS stream, written to the video device for decoding,
can come from the same adapter's dvr device, from any
other adapter's dvr device, from harddisk or where-ever.
>
>> There is no hardware interface to directly access the HDMI output.
>> So it is not possible to create a separate v4l2 HDMI output device.
>>>> The osd part you considered to keep as-is. There is no general video
>>>> output possible as over a DRM device, there is no GPU processing
>>>> possible, and there is no API for video decoding as in a general v4l2
>>>> decoder device. This card's decoder only implements exactly the DVB
>>>> video and osd devices in hardware (well, card firmware I guess, as
>>>> hobbyist programmer I have no access to that), with this somewhat
>>>> strange mix of audio and video (for the card it is not strange, as audio
>>>> and video are always mux'ed in DVB streams).
>>>>
>>>>>> I agree that new drivers should use modern APIs in the general case. But
>>>>>> for this driver the legacy DVB decoder API is a hard requirement for me,
>>>>>> as described. So I hope you will dispense with the v4l2 conversion for
>>>>>> this special case. I'm pretty sure that there will be no new hardware
>>>>>> and therefore no new driver with this legacy API, this saa716x_ff driver
>>>>>> also has a 7-year development history, in this sense it is not really new
>>>>>> and one could also think of it as some sort of legacy code.
>>>>> FF hardware is still common on embedded devices. Sooner or later support
>>>>> for them will be added upstream, and applications that support it
>>>>> will appear.
>>>> Yes, I would really like to get the same functionality as with S2-6400
>>>> on modern SoCs (i.MX6Q, Allwinner H5, meson-gxbb Amlogic S905,...)
>>>> with modern APIs, in an uniform way, see the other thread.
>>> They likely need a lot more, as modern SoC may have lots of IP
>>> blocks to control (multiple inputs, scalers, mpeg encoding, etc). By
>>> adding MC support, the gaps can be fulfilled.
>> Maybe this is a misunderstanding here. I do not plan to support
>> other hardware with this saa716x_ff driver. The other thread [1]
>> about documentation of modern APIs for modern SoCs is somewhat
>> related, but independent from this driver for the S2-6400.
>> This driver as successor of ttpci must implement the same DVB API
>> to support existing users.
>>
>> Drivers for modern hardware may use other APIs, please answer
>> about this in the other thread (or maybe in a new one, if this is more
>> appropriate).
> Yeah, perhaps there's a misunderstanding here. What we currently have
> upstream is a single driver (av7110) that supports a hardware, developed
> about 17 years ago, and that it is out of production for a long time.
As already mentioned, this hardware was sold over a very long
period of time in different versions, it was hardware-modded for
better performance and is still in use.
> We should remove this driver some day, but, as there isn't any strong
> reason to remove, it is staying (and so the API header files to talk
> with it).
And now we have another driver with the same already in-tree
interface, with happy users for several years, which can as well
stay there. And, as I already offered to maintain both drivers, you
would get a maintainer for the DVB decoding API.
>
> Actually, a couple of weeks before your saa716x pull request, there was
> a report that the current DVB video API is broken with regards to
> compat32 and fix would break kABI [1]. It is also incompatible with
> Y2038 fixes that are happening system wide. So, perhaps is time to
> get rid of it for good.
As the fixes are happening tree-wide, this driver should be fixed
in the same way. There are happy users of this driver, and a
maintainer for it if you agree, no need to remove this driver.
>
> [1] see https://patchwork.kernel.org/patch/7187851/ and related
> e-mails.
>
> If/when we add another full-featured DVB hardware (outside staging),
> as the API defined on audio/video is too old (from the time that all
> video decoders were MPEG 2), and it didn't receive any updates to
> support modern hardware, it is unlikely that it would work for such
> hardware.
Here you just received a driver for more modern H.264 full-featured
DVB hardware, it is working great with this API.
> I bet that using V4L2/ALSA (perhaps with a few minor additions)
> would work a way better, as those APIs always got updatates as new audio
> and video codecs got added. The V4L2 also supports the needed bits to
> detect HDMI monitors and adjust parameters like resolution, 3D mode
> and fps rate there.
As described above, V4L2/ALSA has a lot of problems for this
use-case. All the advantages you describe for V4L2/ALSA
"with a few minor additions" are already working great
without additions in this available driver.
> Now, on this thread you're proposing to add another driver using
> DVB video obsolete (and Y2028 broken) API.
This API is used in a popular application from happy users,
so it is not obsolete.
> What I'm saying is that,
> if we're adding it on staging, we need to have a plan to reimplement
> it to whatever API replaces the DVB video API, as this API likely
> won't stay upstream much longer.
AFAIK it is not usual linux policy to remove existing drivers
with happy users and even someone who volunteered to
maintain this.
Regards,
Soeren
> Thanks,
> Mauro
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [GIT PULL] SAA716x DVB driver
2017-09-24 22:17 ` Soeren Moch
@ 2017-11-24 16:28 ` Tycho Lürsen
2017-11-27 11:24 ` Mauro Carvalho Chehab
2017-11-28 18:35 ` [GIT PULL] " Mauro Carvalho Chehab
1 sibling, 1 reply; 26+ messages in thread
From: Tycho Lürsen @ 2017-11-24 16:28 UTC (permalink / raw)
To: Soeren Moch, Mauro Carvalho Chehab; +Cc: Mauro Carvalho Chehab, linux-media
Hi Mauro,
afaik the last communication about submission of this driver was about
two months ago.
This driver is important to me, because I own several TurboSight cards
that are saa716x based. I want to submit a patch that supports my cards.
Of course I can only do so when you accept this driver in the first place.
Any chance you and Sören agree about how to proceed about this driver
anytime soon?
Regards,
Tycho
Op 25-09-17 om 00:17 schreef Soeren Moch:
> On 16.09.2017 19:49, Mauro Carvalho Chehab wrote:
>> Em Sat, 16 Sep 2017 14:54:15 +0200
>> Soeren Moch <smoch@web.de> escreveu:
>>
>>> On 09.09.2017 23:20, Mauro Carvalho Chehab wrote:
>>>> Em Sat, 9 Sep 2017 14:52:18 +0200
>>>> Soeren Moch <smoch@web.de> escreveu:
>>>>
>>>>> You explicitly
>>>>> want to discourage new driver and application implementations.
>>>> Me? It is just the opposite: sticking with a poorly documented API
>>>> that almost nobody knows seems to be what discouraged new drivers
>>>> and applications.
>>> OK, then you are fine to keep the audio/video/osd API in this driver, great!
>> My current understanding is that keeping audio/video API doesn't make
>> any sense, for a couple of reasons:
> For me, keeping this interface makes a lot of sense.
>> 1. it was never fully documented;
> Nothing what prevents existing drivers to work, and new drivers
> to be written, as can be seen from this pull request.
>> 2. the only upstream hardware that supports them was developed on
>> about 17 years ago;
> But was sold for several years in lots of different versions,
> even hardware modifications were developed and applied
> by lots of users to improve the performance of these cards,
> and most important, these cards are still in use.
>> 3. the API is broken with regards to compat32 and Y2038 (see more
>> below);
> Not unique for this driver and, since this API has no business
> with wall clock time, not too complicated to fix.
>> 4. almost all (if not all) features they support are also supported
>> by V4L2 and ALSA;
> Here we come to the point. The DVB audio/video API just
> works, there are working drivers, working applications (vdr)
> and happy users.
> The audio/video/osd device nodes are nicely grouped below
> 1 adapter, so it is immediately clear, which devices belong
> together. It is very easy to implement the classic multimedia
> set-top box use case (audio and video decoding with menu
> overlays). For this use case it is the ideal interface.
>
> You propose V4L2/ALSA instead, what has "almost all features".
> May be, but "almost all" is not all, and a collection of features
> does not give us a working system. /dev/videoX device names
> are not stable across boots, it is even more complicated to
> find matching devices for different hardware with otherwise
> similar capabilities. With V4L2/ALSA there is no real A/V
> synchronisation, selected ALSA devices are reassigned during
> suspend or even HDMI hotplug. So audio gets lost when
> switching the monitor off and on again.
>
> So while audio/video/osd is an integrated multimedia
> interface with working drivers and happy users, for me
> V4L2/ALSA is not ready to immediately replace it.
>
>> 5. V4L2 supports a lot more features that video decoders support
>> than video API, like H.264 and other newer video standards, plus
>> HDMI setup features.
> The S2-6400 card also decodes H.264, and the API is not
> limited to any set of video coding standards. This card
> decodes frame synchronous audio and video and correctly
> signals audio/video formats in HDMI AVI frames (e.g.
> AC3 / PCM audio, video aspect ratios,...). You did not explain
> how this should work with V4L2/ALSA.
>
> For other use cases other types of v4l2 devices could be
> more appropriate. The two APIs coexist for years in
> mainline linux without problems.
>> In the past, we tried a lot to get documentation for those
>> DVB APIs, but, unfortunately, nobody that worked on its development
>> sent us patches addressing the API documentation.
> You probably know why the ttpci developers stopped
> sending patches to linux-media.
>> With regards to OSD, as no other documented API emerged to
>> fulfill what it does, it could make sense to keep it, if
>> someone properly documents it.
>>
>>>>> With linux core APIs for FF you probably mean some new
>>>>> API combination as successor of the audio/video/osd API.
>>>>> The S2-6400 unfortunately directly implements the old API
>>>>> in hardware and is therefore the worst possible match for
>>>>> such new driver generation.
>>>> It sounds weird that the API is directly implemented in hardware.
>>>> I can't tell much, though, as I didn't see the code yet.
>>> All the available code is in this pull request.
>> I know. I'll look on it if we reach an agreement.
>>
>>> I really don't understand your Kaffeine use case. Kaffeine is a media
>>> player, which displays the decoded video on a KDE/Gnome desktop.
>>> With the S2-6400 it is not possible to read the decoded video back,
>>> so it is not possible to display something in a desktop window.
>>> I cannot image what you want to do with this hardware and Kaffeine.
>> I see.
>>
>>>>>> One alternative we could do would be to add the proper APIs for the
>>>>>> driver and keep for a couple of Kernel versions, in staging, a module
>>>>>> that would provide backward compatibility to the legacy APIs. This way,
>>>>>> applications will have some time to add support for the new API.
>>>>>>
>>>>>> If you're willing to do that, I can merge the patches.
>>>>> Here I do not understand what you expect me to do. The audio/video/osd
>>>>> devices are closely tied together (as frontend/demux/dvr are for the
>>>>> input side). The S2-6400 card expects an transport stream with audio and
>>>>> video packets to be written to that video device (the audio device is
>>>>> not used) and commands for overlay text/graphics over the osd device.
>>>> There are two options here:
>>>>
>>>> 1) if the hardware itself allows to direct a filtered MPEG-TS to the demod,
>>>> by hardware, instead of reading it from /dev/dvb/.../dvr and writing it
>>>> to /dev/dvb.../video, you could use the Media Controller to
>>>> direct the video PID to the video decoder hardware directly;
>>> This is what you want me to implement: this shortcut from
>>> /dev/dvb/.../dvr to /dev/dvb.../video ? Since you said above that this
>>> is already implemented in the dvb core, this should be easy and.
>>> can of course be implemented in this driver.
>>>> The V4L2 driver device node (let's say, /dev/video0) will just
>>>> implement the HDMI output.
>>> There is no separate decoder / HDMI hardware, from the driver's
>>> point of view. The decoded video directly goes to the HDMI output.
>> If there's nothing that can be controlled at the HDMI output, why do
>> you need a /dev/dvb.../video devnode? If it can be controlled, a
>> V4L2 output will do the job.
> As I wrote several times, the TS stream, which will be decoded,
> is written to /dev/dvb/adapterX/video.
>>>> 2) if there's no hardware pipelines between the demux and the decoders,
>>>> userspace will read video from .../dvr and write it to a /dev/video
>>>> capture device node, implemented by a mem2mem V4L2 driver.
>>> There cannot be a separate capture device node for the decoded
>>> video. You probably refer to the video_cature:one-shot feature,
>>> which is switched off by default.
>>> This is a debug feature, which vdr supports. It is intended to
>>> take a snapshot of the output image, something for debugging
>>> vdr-skins, the graphical user interface of vdr.
>> Ah, so it can't play an arbitrary MPEG-TS stream from other
>> sources, right?
> The card will decode the TS stream written to the video device
> and display the decoded audio and video over HDMI.
>>> From the msleep(100); in the read path you can easily see, that
>>> this is meant for still images, not for video. Due to bandwidth
>>> limitations on the hardware this should normally not be used
>>> during normal decoding.
>>>> The mem2mem output device node (let's say, /dev/video1) will control
>>>> the HDMI output.
>>> As mentioned several times, it is only possible to write a transport
>>> stream to the video device, and osd commands to the osd device.
>> Hmm... now, I'm confused. Can it play a MPEG-TS video stored at the
>> computer or not?
> The TS stream, written to the video device for decoding,
> can come from the same adapter's dvr device, from any
> other adapter's dvr device, from harddisk or where-ever.
>>> There is no hardware interface to directly access the HDMI output.
>>> So it is not possible to create a separate v4l2 HDMI output device.
>>>>> The osd part you considered to keep as-is. There is no general video
>>>>> output possible as over a DRM device, there is no GPU processing
>>>>> possible, and there is no API for video decoding as in a general v4l2
>>>>> decoder device. This card's decoder only implements exactly the DVB
>>>>> video and osd devices in hardware (well, card firmware I guess, as
>>>>> hobbyist programmer I have no access to that), with this somewhat
>>>>> strange mix of audio and video (for the card it is not strange, as audio
>>>>> and video are always mux'ed in DVB streams).
>>>>>
>>>>>>> I agree that new drivers should use modern APIs in the general case. But
>>>>>>> for this driver the legacy DVB decoder API is a hard requirement for me,
>>>>>>> as described. So I hope you will dispense with the v4l2 conversion for
>>>>>>> this special case. I'm pretty sure that there will be no new hardware
>>>>>>> and therefore no new driver with this legacy API, this saa716x_ff driver
>>>>>>> also has a 7-year development history, in this sense it is not really new
>>>>>>> and one could also think of it as some sort of legacy code.
>>>>>> FF hardware is still common on embedded devices. Sooner or later support
>>>>>> for them will be added upstream, and applications that support it
>>>>>> will appear.
>>>>> Yes, I would really like to get the same functionality as with S2-6400
>>>>> on modern SoCs (i.MX6Q, Allwinner H5, meson-gxbb Amlogic S905,...)
>>>>> with modern APIs, in an uniform way, see the other thread.
>>>> They likely need a lot more, as modern SoC may have lots of IP
>>>> blocks to control (multiple inputs, scalers, mpeg encoding, etc). By
>>>> adding MC support, the gaps can be fulfilled.
>>> Maybe this is a misunderstanding here. I do not plan to support
>>> other hardware with this saa716x_ff driver. The other thread [1]
>>> about documentation of modern APIs for modern SoCs is somewhat
>>> related, but independent from this driver for the S2-6400.
>>> This driver as successor of ttpci must implement the same DVB API
>>> to support existing users.
>>>
>>> Drivers for modern hardware may use other APIs, please answer
>>> about this in the other thread (or maybe in a new one, if this is more
>>> appropriate).
>> Yeah, perhaps there's a misunderstanding here. What we currently have
>> upstream is a single driver (av7110) that supports a hardware, developed
>> about 17 years ago, and that it is out of production for a long time.
> As already mentioned, this hardware was sold over a very long
> period of time in different versions, it was hardware-modded for
> better performance and is still in use.
>> We should remove this driver some day, but, as there isn't any strong
>> reason to remove, it is staying (and so the API header files to talk
>> with it).
> And now we have another driver with the same already in-tree
> interface, with happy users for several years, which can as well
> stay there. And, as I already offered to maintain both drivers, you
> would get a maintainer for the DVB decoding API.
>> Actually, a couple of weeks before your saa716x pull request, there was
>> a report that the current DVB video API is broken with regards to
>> compat32 and fix would break kABI [1]. It is also incompatible with
>> Y2038 fixes that are happening system wide. So, perhaps is time to
>> get rid of it for good.
> As the fixes are happening tree-wide, this driver should be fixed
> in the same way. There are happy users of this driver, and a
> maintainer for it if you agree, no need to remove this driver.
>> [1] see https://patchwork.kernel.org/patch/7187851/ and related
>> e-mails.
>>
>> If/when we add another full-featured DVB hardware (outside staging),
>> as the API defined on audio/video is too old (from the time that all
>> video decoders were MPEG 2), and it didn't receive any updates to
>> support modern hardware, it is unlikely that it would work for such
>> hardware.
> Here you just received a driver for more modern H.264 full-featured
> DVB hardware, it is working great with this API.
>> I bet that using V4L2/ALSA (perhaps with a few minor additions)
>> would work a way better, as those APIs always got updatates as new audio
>> and video codecs got added. The V4L2 also supports the needed bits to
>> detect HDMI monitors and adjust parameters like resolution, 3D mode
>> and fps rate there.
> As described above, V4L2/ALSA has a lot of problems for this
> use-case. All the advantages you describe for V4L2/ALSA
> "with a few minor additions" are already working great
> without additions in this available driver.
>> Now, on this thread you're proposing to add another driver using
>> DVB video obsolete (and Y2028 broken) API.
> This API is used in a popular application from happy users,
> so it is not obsolete.
>> What I'm saying is that,
>> if we're adding it on staging, we need to have a plan to reimplement
>> it to whatever API replaces the DVB video API, as this API likely
>> won't stay upstream much longer.
> AFAIK it is not usual linux policy to remove existing drivers
> with happy users and even someone who volunteered to
> maintain this.
>
> Regards,
> Soeren
>> Thanks,
>> Mauro
>
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [GIT PULL] SAA716x DVB driver
2017-11-24 16:28 ` Tycho Lürsen
@ 2017-11-27 11:24 ` Mauro Carvalho Chehab
2017-12-02 18:51 ` Jemma Denson
0 siblings, 1 reply; 26+ messages in thread
From: Mauro Carvalho Chehab @ 2017-11-27 11:24 UTC (permalink / raw)
To: Tycho Lürsen; +Cc: Soeren Moch, Mauro Carvalho Chehab, linux-media
Em Fri, 24 Nov 2017 17:28:37 +0100
Tycho Lürsen <tycholursen@gmail.com> escreveu:
> Hi Mauro,
>
> afaik the last communication about submission of this driver was about
> two months ago.
>
> This driver is important to me, because I own several TurboSight cards
> that are saa716x based. I want to submit a patch that supports my cards.
> Of course I can only do so when you accept this driver in the first place.
>
> Any chance you and Sören agree about how to proceed about this driver
> anytime soon?
If we can reach an agreement about what should be done for the driver
to be promoted from staging some day, I'll merge it. Otherwise,
it can be kept maintained out of tree. This driver has been maintained
OOT for a very long time, and it seems that people were happy with
that, as only at the second half of this year someone is requesting
to merge it.
So, while I agree that the best is to merge it upstream and
address the issues that made it OOT for a long time, we shouldn't
rush it with the risk of doing more harm than good.
Thanks,
Mauro
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [GIT PULL] SAA716x DVB driver
2017-09-24 22:17 ` Soeren Moch
2017-11-24 16:28 ` Tycho Lürsen
@ 2017-11-28 18:35 ` Mauro Carvalho Chehab
2017-12-02 23:58 ` Soeren Moch
1 sibling, 1 reply; 26+ messages in thread
From: Mauro Carvalho Chehab @ 2017-11-28 18:35 UTC (permalink / raw)
To: Soeren Moch
Cc: Mauro Carvalho Chehab, Greg Kroah-Hartman, Andreas Regel,
Manu Abraham, Oliver Endriss, linux-media, Eugene Syromiatnikov,
Arnd Bergmann
Em Mon, 25 Sep 2017 00:17:00 +0200
Soeren Moch <smoch@web.de> escreveu:
> > What I'm saying is that,
> > if we're adding it on staging, we need to have a plan to reimplement
> > it to whatever API replaces the DVB video API, as this API likely
> > won't stay upstream much longer.
> AFAIK it is not usual linux policy to remove existing drivers
> with happy users and even someone who volunteered to
> maintain this.
The usual Linux policy doesn't apply to staging. The goal of staging is
to add drivers that have problems, but are fixable, and whose someone
is working to solve those issues.
The staging policies include adding a TODO file describing the problems
that should be solved for the driver to be promoted. If such problems
aren't solved, the driver can be removed.
For example, this year, we removed some lirc staging drivers because
no developers were interested (and/or had the hardware) to convert
them to use the RC core (with is a Kernel's internal API).
In the case of saa716x, the issue is that it uses a deprecated
and undocumented userspace API, with is a way more serious issue.
I'm ok to add this driver to staging if we can agree on what
should be fixed, and if someone commits to try fixing it, knowing,
in advance, that, if it doesn't get fixed on a reasonable time, it
can be removed on later Kernel versions.
Thanks,
Mauro
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [GIT PULL] SAA716x DVB driver
2017-11-27 11:24 ` Mauro Carvalho Chehab
@ 2017-12-02 18:51 ` Jemma Denson
2017-12-02 19:49 ` Mauro Carvalho Chehab
0 siblings, 1 reply; 26+ messages in thread
From: Jemma Denson @ 2017-12-02 18:51 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Tycho Lürsen
Cc: Soeren Moch, Mauro Carvalho Chehab, linux-media
Hi Mauro,
On 27/11/17 11:24, Mauro Carvalho Chehab wrote:
> Em Fri, 24 Nov 2017 17:28:37 +0100
> Tycho Lürsen <tycholursen@gmail.com> escreveu:
>
>> Hi Mauro,
>>
>> afaik the last communication about submission of this driver was about
>> two months ago.
>>
>> This driver is important to me, because I own several TurboSight cards
>> that are saa716x based. I want to submit a patch that supports my cards.
>> Of course I can only do so when you accept this driver in the first place.
>>
>> Any chance you and Sören agree about how to proceed about this driver
>> anytime soon?
> If we can reach an agreement about what should be done for the driver
> to be promoted from staging some day, I'll merge it. Otherwise,
> it can be kept maintained out of tree. This driver has been maintained
> OOT for a very long time, and it seems that people were happy with
> that, as only at the second half of this year someone is requesting
> to merge it.
>
> So, while I agree that the best is to merge it upstream and
> address the issues that made it OOT for a long time, we shouldn't
> rush it with the risk of doing more harm than good.
>
> Thanks,
> Mauro
Would I be correct in thinking the main blocker to this is the *_ff features
used by the S2-6400 card? There's plenty of other cards using this chipset
that don't need that part.
Would a solution for now to be a driver with the ff components stripped out,
and then the ff API work can be done later when / if there's any interest?
I guess a problem would be finding a maintainer, I'm happy to put together
a stripped down driver just supporting the TBS card I use (I already have
one I use with dkms), but I'm not sure I have the time or knowledge of this
chipset to be a maintainer. Unfortunately my workplace is phasing out
these cards otherwise I'd try and get them to sponsor me rather than do it
on my own time!
Jemma.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [GIT PULL] SAA716x DVB driver
2017-12-02 18:51 ` Jemma Denson
@ 2017-12-02 19:49 ` Mauro Carvalho Chehab
2017-12-02 23:59 ` Soeren Moch
0 siblings, 1 reply; 26+ messages in thread
From: Mauro Carvalho Chehab @ 2017-12-02 19:49 UTC (permalink / raw)
To: Jemma Denson
Cc: Tycho Lürsen, Soeren Moch, Mauro Carvalho Chehab, linux-media
Em Sat, 2 Dec 2017 18:51:16 +0000
Jemma Denson <jdenson@gmail.com> escreveu:
> Hi Mauro,
>
> On 27/11/17 11:24, Mauro Carvalho Chehab wrote:
> > Em Fri, 24 Nov 2017 17:28:37 +0100
> > Tycho Lürsen <tycholursen@gmail.com> escreveu:
> >
> >> Hi Mauro,
> >>
> >> afaik the last communication about submission of this driver was about
> >> two months ago.
> >>
> >> This driver is important to me, because I own several TurboSight cards
> >> that are saa716x based. I want to submit a patch that supports my cards.
> >> Of course I can only do so when you accept this driver in the first place.
> >>
> >> Any chance you and Sören agree about how to proceed about this driver
> >> anytime soon?
> > If we can reach an agreement about what should be done for the driver
> > to be promoted from staging some day, I'll merge it. Otherwise,
> > it can be kept maintained out of tree. This driver has been maintained
> > OOT for a very long time, and it seems that people were happy with
> > that, as only at the second half of this year someone is requesting
> > to merge it.
> >
> > So, while I agree that the best is to merge it upstream and
> > address the issues that made it OOT for a long time, we shouldn't
> > rush it with the risk of doing more harm than good.
> >
> > Thanks,
> > Mauro
>
> Would I be correct in thinking the main blocker to this is the *_ff features
> used by the S2-6400 card? There's plenty of other cards using this chipset
> that don't need that part.
>
> Would a solution for now to be a driver with the ff components stripped out,
> and then the ff API work can be done later when / if there's any interest?
Works for me. In such case (and provided that the driver without *_ff are
in good shape), we could merge it under drivers/media (instead of merging
it on staging).
> I guess a problem would be finding a maintainer, I'm happy to put together
> a stripped down driver just supporting the TBS card I use (I already have
> one I use with dkms), but I'm not sure I have the time or knowledge of this
> chipset to be a maintainer.
As we're talking more about touching at uAPI, probably it doesn't require
chipsed knowledge. Only time and interest on doing it.
Please sync with Soeren. Perhaps if you both could help on it, it would
make the task easier.
> Unfortunately my workplace is phasing out
> these cards otherwise I'd try and get them to sponsor me rather than do it
> on my own time!
Yeah, getting sponsored to do it would make things easier.
Thanks,
Mauro
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [GIT PULL] SAA716x DVB driver
2017-11-28 18:35 ` [GIT PULL] " Mauro Carvalho Chehab
@ 2017-12-02 23:58 ` Soeren Moch
0 siblings, 0 replies; 26+ messages in thread
From: Soeren Moch @ 2017-12-02 23:58 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Mauro Carvalho Chehab, Greg Kroah-Hartman, Andreas Regel,
Manu Abraham, Oliver Endriss, linux-media, Eugene Syromiatnikov,
Arnd Bergmann
Mauro,
On 28.11.2017 19:35, Mauro Carvalho Chehab wrote:
> Em Mon, 25 Sep 2017 00:17:00 +0200
> Soeren Moch <smoch@web.de> escreveu:
>
>>> What I'm saying is that,
>>> if we're adding it on staging, we need to have a plan to reimplement
>>> it to whatever API replaces the DVB video API, as this API likely
>>> won't stay upstream much longer.
>> AFAIK it is not usual linux policy to remove existing drivers
>> with happy users and even someone who volunteered to
>> maintain this.
> The usual Linux policy doesn't apply to staging. The goal of staging is
> to add drivers that have problems, but are fixable, and whose someone
> is working to solve those issues.
It is totally clear to me what staging is for. Therefore I submitted
this driver for staging.
I was talking about the ttpci driver. This drivers lives in
drivers/media/pci/ttpci, not in staging, it implements the DVB
audio/video/osd API, works great and has happy users. So the DVB video
API _is already_ part of the linux userspace API. This pull request does
not add anything to the already available in-kernel video API.
> The staging policies include adding a TODO file describing the problems
> that should be solved for the driver to be promoted. If such problems
> aren't solved, the driver can be removed.
Yes, of course. Therefore I added such TODO file and promised to solve
these issues.
>
> For example, this year, we removed some lirc staging drivers because
> no developers were interested (and/or had the hardware) to convert
> them to use the RC core (with is a Kernel's internal API).
>
> In the case of saa716x, the issue is that it uses a deprecated
> and undocumented userspace API, with is a way more serious issue.
Unfortunately there is no other API available which provides _all_ the
functionality of DVB audio/video/osd. And the TT S2-6400 hardware is
developed in a way, so that it is as similar as possible to ttpci cards.
In order that the vdr application can easily make use of it. So it is
not surprising, that the saa716x_ff driver needs to implement the same
APIs as the ttpci driver.
> I'm ok to add this driver to staging if we can agree on what
> should be fixed, and if someone commits to try fixing it, knowing,
> in advance, that, if it doesn't get fixed on a reasonable time, it
> can be removed on later Kernel versions.
I already agreed on all these points. I already promised to fix whatever
is necessary to get this driver out of staging, as long as the userspace
API remains the same so that vdr continues to work with these cards. And
once again, this API already is part of the kernel and not specific for
this driver.
The driver version in this pull request does not build anymore with
linux-4.15-rc1. Shall I provide a new pull request with this fixed?
Thanks,
Soeren
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [GIT PULL] SAA716x DVB driver
2017-12-02 19:49 ` Mauro Carvalho Chehab
@ 2017-12-02 23:59 ` Soeren Moch
2017-12-03 10:57 ` Jemma Denson
0 siblings, 1 reply; 26+ messages in thread
From: Soeren Moch @ 2017-12-02 23:59 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Jemma Denson
Cc: Tycho Lürsen, Mauro Carvalho Chehab, linux-media
On 02.12.2017 20:49, Mauro Carvalho Chehab wrote:
> Em Sat, 2 Dec 2017 18:51:16 +0000
> Jemma Denson <jdenson@gmail.com> escreveu:
>
>> Hi Mauro,
>>
>> On 27/11/17 11:24, Mauro Carvalho Chehab wrote:
>>> Em Fri, 24 Nov 2017 17:28:37 +0100
>>> Tycho Lürsen <tycholursen@gmail.com> escreveu:
>>>
>>>> Hi Mauro,
>>>>
>>>> afaik the last communication about submission of this driver was about
>>>> two months ago.
>>>>
>>>> This driver is important to me, because I own several TurboSight cards
>>>> that are saa716x based. I want to submit a patch that supports my cards.
>>>> Of course I can only do so when you accept this driver in the first place.
>>>>
>>>> Any chance you and Sören agree about how to proceed about this driver
>>>> anytime soon?
>>> If we can reach an agreement about what should be done for the driver
>>> to be promoted from staging some day, I'll merge it. Otherwise,
>>> it can be kept maintained out of tree. This driver has been maintained
>>> OOT for a very long time, and it seems that people were happy with
>>> that, as only at the second half of this year someone is requesting
>>> to merge it.
>>>
>>> So, while I agree that the best is to merge it upstream and
>>> address the issues that made it OOT for a long time, we shouldn't
>>> rush it with the risk of doing more harm than good.
>>>
>>> Thanks,
>>> Mauro
>> Would I be correct in thinking the main blocker to this is the *_ff features
>> used by the S2-6400 card? There's plenty of other cards using this chipset
>> that don't need that part.
>>
>> Would a solution for now to be a driver with the ff components stripped out,
>> and then the ff API work can be done later when / if there's any interest?
> Works for me. In such case (and provided that the driver without *_ff are
> in good shape), we could merge it under drivers/media (instead of merging
> it on staging).
All the entries in the TODO file are not specific for saa716x_ff.
>> I guess a problem would be finding a maintainer, I'm happy to put together
>> a stripped down driver just supporting the TBS card I use (I already have
>> one I use with dkms), but I'm not sure I have the time or knowledge of this
>> chipset to be a maintainer.
There is chipset specific stuff to fix, especially irq handling.
> As we're talking more about touching at uAPI, probably it doesn't require
> chipsed knowledge. Only time and interest on doing it.
>
> Please sync with Soeren. Perhaps if you both could help on it, it would
> make the task easier.
As I already wrote to different people off-list: I'm happy to support
more cards with the saa7160 bridge and maintain these in this driver. As
hobbyist programmer this of course makes no sense to me, if the hardware
I own (S2-6400) is not supported.
Regards,
Soeren
>> Unfortunately my workplace is phasing out
>> these cards otherwise I'd try and get them to sponsor me rather than do it
>> on my own time!
> Yeah, getting sponsored to do it would make things easier.
>
> Thanks,
> Mauro
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [GIT PULL] SAA716x DVB driver
2017-12-02 23:59 ` Soeren Moch
@ 2017-12-03 10:57 ` Jemma Denson
2017-12-03 14:11 ` Soeren Moch
2018-01-19 13:59 ` Tycho Lürsen
0 siblings, 2 replies; 26+ messages in thread
From: Jemma Denson @ 2017-12-03 10:57 UTC (permalink / raw)
To: Soeren Moch, Mauro Carvalho Chehab
Cc: Tycho Lürsen, Mauro Carvalho Chehab, linux-media
On 02/12/17 23:59, Soeren Moch wrote:
> On 02.12.2017 20:49, Mauro Carvalho Chehab wrote:
>> Em Sat, 2 Dec 2017 18:51:16 +0000
>> Jemma Denson <jdenson@gmail.com> escreveu:
>>> Would I be correct in thinking the main blocker to this is the *_ff features
>>> used by the S2-6400 card? There's plenty of other cards using this chipset
>>> that don't need that part.
>>>
>>> Would a solution for now to be a driver with the ff components stripped out,
>>> and then the ff API work can be done later when / if there's any interest?
>> Works for me. In such case (and provided that the driver without *_ff are
>> in good shape), we could merge it under drivers/media (instead of merging
>> it on staging).
> All the entries in the TODO file are not specific for saa716x_ff.
Ah, it's been a few months since I looked at that. I think some of the
things listed I had already identified as problems - checkpatch especially,
and the irq code probably needs a bit more auto-detection.
I'm not sure I've seen how the other issues manifest themselves so I
might need some explanation of that (off list if you prefer)
>>> I guess a problem would be finding a maintainer, I'm happy to put together
>>> a stripped down driver just supporting the TBS card I use (I already have
>>> one I use with dkms), but I'm not sure I have the time or knowledge of this
>>> chipset to be a maintainer.
> There is chipset specific stuff to fix, especially irq handling.
Is this the module parameter kludges or something else?
>> As we're talking more about touching at uAPI, probably it doesn't require
>> chipsed knowledge. Only time and interest on doing it.
>>
>> Please sync with Soeren. Perhaps if you both could help on it, it would
>> make the task easier.
> As I already wrote to different people off-list: I'm happy to support
> more cards with the saa7160 bridge and maintain these in this driver. As
> hobbyist programmer this of course makes no sense to me, if the hardware
> I own (S2-6400) is not supported.
>
Hence my comment about finding a maintainer - I had assumed if the
immediate result didn't support your card you probably wouldn't be willing
to do that.
What I'm trying to do here is get *something* merged, and then once
that work is done any interested parties can add to it. Or at the very
least if some patches are left OOT the constant workload required to
keep that up to date should be reduced significantly because they'll be
far less to look after.
One of the problems though is choosing which fork to use. I *think* there
are 2 - the one you've got which is the original powARman branch and the
one I would be using is the CrazyCat / Luis / TBS line. There are going
to be
some differences but hopefully that's all frontend support based and one cut
down to a single frontend would end up a good base to add the rest back
in.
I'm looking at maybe finding time over christmas break.
Jemma
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [GIT PULL] SAA716x DVB driver
2017-12-03 10:57 ` Jemma Denson
@ 2017-12-03 14:11 ` Soeren Moch
2017-12-03 15:04 ` Jemma Denson
2018-01-19 13:59 ` Tycho Lürsen
1 sibling, 1 reply; 26+ messages in thread
From: Soeren Moch @ 2017-12-03 14:11 UTC (permalink / raw)
To: Jemma Denson, Mauro Carvalho Chehab
Cc: Tycho Lürsen, Mauro Carvalho Chehab, linux-media,
Manu Abraham, Andreas Regel, Oliver Endriss
On 03.12.2017 11:57, Jemma Denson wrote:
> On 02/12/17 23:59, Soeren Moch wrote:
>> On 02.12.2017 20:49, Mauro Carvalho Chehab wrote:
>>> Em Sat, 2 Dec 2017 18:51:16 +0000
>>> Jemma Denson <jdenson@gmail.com> escreveu:
>>>> Would I be correct in thinking the main blocker to this is the *_ff
>>>> features
>>>> used by the S2-6400 card? There's plenty of other cards using this
>>>> chipset
>>>> that don't need that part.
>>>>
>>>> Would a solution for now to be a driver with the ff components
>>>> stripped out,
>>>> and then the ff API work can be done later when / if there's any
>>>> interest?
>>> Works for me. In such case (and provided that the driver without
>>> *_ff are
>>> in good shape), we could merge it under drivers/media (instead of
>>> merging
>>> it on staging).
>> All the entries in the TODO file are not specific for saa716x_ff.
>
> Ah, it's been a few months since I looked at that. I think some of the
> things listed I had already identified as problems - checkpatch
> especially,
Finding checkpatch problems is easy...
> and the irq code probably needs a bit more auto-detection.
> I'm not sure I've seen how the other issues manifest themselves so I
> might need some explanation of that (off list if you prefer)
>
>>>> I guess a problem would be finding a maintainer, I'm happy to put
>>>> together
>>>> a stripped down driver just supporting the TBS card I use (I
>>>> already have
>>>> one I use with dkms), but I'm not sure I have the time or knowledge
>>>> of this
>>>> chipset to be a maintainer.
>> There is chipset specific stuff to fix, especially irq handling.
>
> Is this the module parameter kludges or something else?
>
>>> As we're talking more about touching at uAPI, probably it doesn't
>>> require
>>> chipsed knowledge. Only time and interest on doing it.
>>>
>>> Please sync with Soeren. Perhaps if you both could help on it, it would
>>> make the task easier.
>> As I already wrote to different people off-list: I'm happy to support
>> more cards with the saa7160 bridge and maintain these in this driver. As
>> hobbyist programmer this of course makes no sense to me, if the hardware
>> I own (S2-6400) is not supported.
>>
>
> Hence my comment about finding a maintainer - I had assumed if the
> immediate result didn't support your card you probably wouldn't be
> willing
> to do that.
>
> What I'm trying to do here is get *something* merged, and then once
> that work is done any interested parties can add to it. Or at the very
> least if some patches are left OOT the constant workload required to
> keep that up to date should be reduced significantly because they'll be
> far less to look after.
>
Why not merge the driver as-is? The community would get support for
several cards, easy access to the code without the need for separate git
repositories or dkms packages, and a maintainer that understands the
hardware and driver code.
The whole purpose of driver development is bringing support for existing
hardware to available user applications, preferably with existing APIs.
And exactly that is in this pull request.
In the whole discussion I cannot find a single reason, how merging this
driver would violate the linux development principles.
> One of the problems though is choosing which fork to use. I *think* there
> are 2 - the one you've got which is the original powARman branch and the
> one I would be using is the CrazyCat / Luis / TBS line. There are
> going to be
> some differences but hopefully that's all frontend support based and
> one cut
> down to a single frontend would end up a good base to add the rest back
> in.
>
I think my repository represents the main development branch, just
maintained by different people (adding Manu, Andreas, Oliver, in case
they want to object). The CrazyCat repo is not a fork (including
history), it is just a snapshot of the driver plus several patches.
I already promised to help with adding TBS support.
Regards,
Soeren
> I'm looking at maybe finding time over christmas break.
>
>
> Jemma
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [GIT PULL] SAA716x DVB driver
2017-12-03 14:11 ` Soeren Moch
@ 2017-12-03 15:04 ` Jemma Denson
2017-12-04 10:07 ` Mauro Carvalho Chehab
0 siblings, 1 reply; 26+ messages in thread
From: Jemma Denson @ 2017-12-03 15:04 UTC (permalink / raw)
To: Soeren Moch, Mauro Carvalho Chehab
Cc: Tycho Lürsen, Mauro Carvalho Chehab, linux-media,
Manu Abraham, Andreas Regel, Oliver Endriss
On 03/12/17 14:11, Soeren Moch wrote:
> On 03.12.2017 11:57, Jemma Denson wrote:
>> On 02/12/17 23:59, Soeren Moch wrote:
>>> All the entries in the TODO file are not specific for saa716x_ff.
>> Ah, it's been a few months since I looked at that. I think some of the
>> things listed I had already identified as problems - checkpatch
>> especially,
> Finding checkpatch problems is easy...
Indeed they are. They still take some time to go though.
>> Hence my comment about finding a maintainer - I had assumed if the
>> immediate result didn't support your card you probably wouldn't be
>> willing
>> to do that.
>>
>> What I'm trying to do here is get *something* merged, and then once
>> that work is done any interested parties can add to it. Or at the very
>> least if some patches are left OOT the constant workload required to
>> keep that up to date should be reduced significantly because they'll be
>> far less to look after.
>>
> Why not merge the driver as-is? The community would get support for
> several cards, easy access to the code without the need for separate git
> repositories or dkms packages, and a maintainer that understands the
> hardware and driver code.
>
> The whole purpose of driver development is bringing support for existing
> hardware to available user applications, preferably with existing APIs.
> And exactly that is in this pull request.
> In the whole discussion I cannot find a single reason, how merging this
> driver would violate the linux development principles.
That's not really one for me to answer, but Mauro has raised objections
so it can't be merged as is. I'm just trying to find a way forward that
avoids this getting stuck for another few years.
>> One of the problems though is choosing which fork to use. I *think* there
>> are 2 - the one you've got which is the original powARman branch and the
>> one I would be using is the CrazyCat / Luis / TBS line. There are
>> going to be
>> some differences but hopefully that's all frontend support based and
>> one cut
>> down to a single frontend would end up a good base to add the rest back
>> in.
>>
> I think my repository represents the main development branch, just
> maintained by different people (adding Manu, Andreas, Oliver, in case
> they want to object). The CrazyCat repo is not a fork (including
> history), it is just a snapshot of the driver plus several patches.
>
Well I know of several patches I've made to that repo that haven't
made it back to the "main" branch, so whilst maybe not a fork in
the traditional sense it certainly is functioning like one.
As I said, I'm just trying to get *something* merged. I can base a
ff-stripped patch on the powarman branch instead but it does represent
more work for me as I need to work out what else might be missing to
support the only card I have for testing this with. It might end up being
easy but I don't know that yet.
Let's get something happening here rather than just trying to argue
with the maintainers. There's absolutely nothing stopping further patches
being sent in later on once the chipset driver is merged.
Jemma.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [GIT PULL] SAA716x DVB driver
2017-12-03 15:04 ` Jemma Denson
@ 2017-12-04 10:07 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 26+ messages in thread
From: Mauro Carvalho Chehab @ 2017-12-04 10:07 UTC (permalink / raw)
To: Jemma Denson
Cc: Soeren Moch, Tycho Lürsen, Mauro Carvalho Chehab,
linux-media, Manu Abraham, Andreas Regel, Oliver Endriss
Em Sun, 3 Dec 2017 15:04:31 +0000
Jemma Denson <jdenson@gmail.com> escreveu:
> On 03/12/17 14:11, Soeren Moch wrote:
> > On 03.12.2017 11:57, Jemma Denson wrote:
> >> On 02/12/17 23:59, Soeren Moch wrote:
> > The whole purpose of driver development is bringing support for existing
> > hardware to available user applications, preferably with existing APIs.
> > And exactly that is in this pull request.
> > In the whole discussion I cannot find a single reason, how merging this
> > driver would violate the linux development principles.
>
> That's not really one for me to answer, but Mauro has raised objections
> so it can't be merged as is. I'm just trying to find a way forward that
> avoids this getting stuck for another few years.
Let me write a longer explanation about what are my concerns.
The current FF API was designed back in 1999, almost 20 years ago. It
was a pioneer design on that time, but it shows its age. I had several
discussions in the past with some chipset manufacturers and with
people interested on open sourcing their drivers for embedded devices.
The point is: the current way it is implemented doesn't fit, for
several reasons:
- The API itself is not flexible enough to support their hardware,
with usually has a different number of frontends than the number
of decoders and all sorts of other complexities. On modern
chipsets, the same pipeline is used also for other things like
hdmi input/output and even webcams/microphones. So, an API that
integrates with such components are needed. Also, on modern
hardware, the descrambler hardware can dynamically be added/removed
from the pipeline, and they usually have a pair of scrambler/descrambler
module (using a different crypto algorithm), used when the data is
written on a hard disk;
- The documentation for the API is incomplete;
- The API is broken with 64 bits kernel and 32 bits userspace. Most SoCs
nowadays use 64 bits Kernel, but lots of vendors are still using 32 bits
userspace;
- The DVB core doesn't support the FF API. Everything should be
written at the drivers.
Having an API for FF that doesn't fit on modern hardware has a practical
effect of preventing people to write it on a proper way, as APIs on
Linux are forever (in the sense that, while the API is still in usage
by non-OOT/staging drivers, it can't be removed).
The only driver that implements such API upstream isfor a hardware developed
in 1999, whose production ended ages ago. So, the status of this API,
from Kernel's PoV, is that it could be removed anytime if needed, by
simply removing one obsolete driver. Removing obsolete drivers that
are preventing adding new functionalities is allowed.
So, it is time to replace it for good, implementing something that works
for modern hardware, using APIs that fits on embedded systems needs
(as most FF implementation are for STB and TV sets).
In other words, I'm simply against adding a new driver that will
come with a bold maintenance requirement of keeping alive an obsolete
FF API that doesn't fit on modern chipset needs, and would prevent
adding a new FF API for another 20 years that would otherwise work
with modern hardware. It is time to discuss about a new FF API and
implement drivers supporting it.
In the specific case of saa716x driver, users seemed to be happy on
having it OOT, as it has been working like that for a long time without
any attempts to merge it. As new hardware using this chipset aren't
manufactured anymore (AFAIKT). So, a trivial alternative would be to
keep if OOT.
So, the only way I would agree on merging the saa716x driver upstream
(specially support for FF) is if we come up with a solution that
wouldn't force us to stick with an FF API that doesn't support modern
hardware for a long time.
As capping saa716x FF support doesn't make much sense, we should
migrate it to a new FF API, long term.
-
From what I understood, Soeren's original proposal at his initial pull
request were to add it at staging, keeping it there forever. This is
against staging policy. Staging is not a place to keep drivers forever,
but a place to add drivers that require work. A driver at staging that
isn't maintained (in the sense of solving issues that will allow
it to be moved out of staging) can be removed anytime. So, this is not
an option.
As a summary from this thread's discussion, my understanding is that
there are currently two alternatives about a way to move forward:
1) add saa716x driver at staging, with developers committed to solve
whatever issues the driver has. On other words, we should have a plan
to migrate it to an API capable of attending current needs. Both
developers and users should be aware that, if such change never happen,
the driver may be removed anytime in the future.
2) add first the parts that won't require a new API, and having developers
working on addressing the API issues for FF. Once this is addressed,
merge the FF support. While this doesn't happen, the FF part of the
driver would be maintained OOT.
That's said, I'm pretty sure that, if we merge it at staging, and it
ended by being removed on a couple of Kernel versions, this would be
a lot worse for users than just keep it maintained OOT. So, (2) could
work better, as, at worse case scenario where developers won't ever have
time to finish the FF API work, the non-FF part won't be dropped.
Regards,
Mauro
^ permalink raw reply [flat|nested] 26+ messages in thread
* SAA716x DVB driver
2017-12-03 10:57 ` Jemma Denson
2017-12-03 14:11 ` Soeren Moch
@ 2018-01-19 13:59 ` Tycho Lürsen
2018-01-19 15:11 ` Jemma Denson
1 sibling, 1 reply; 26+ messages in thread
From: Tycho Lürsen @ 2018-01-19 13:59 UTC (permalink / raw)
To: Jemma Denson, Soeren Moch, Mauro Carvalho Chehab, Luis Alves,
linux-media
Hi Jemma,
I'm with you: let's get merged at least something!
Did you find a maintainer for this driver?
I can do simple stuff like in my fork of Soeren Moch's repo, but thats
where it ends. I dont have the knowledge needed to maintain a driver.
I think that your proposal to use a stripped version of Luis Alves repo
is a no go, since it contains a couple of demod/tuner drivers that are
not upstreamed yet. That complicates the upstreaming process too much, I
think.
I used a stripped version of Soeren Moch's repo to prove its stability
instead, adding the drivers I need so I can test it. You can see what I
did at : https://github.com/bas-t/linux-saa716x/commits/for-media-stripped
This has been tested with linux 4.9.77, 4.14.14 and 4.15-rc8.
Works like a charm for me.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: SAA716x DVB driver
2018-01-19 13:59 ` Tycho Lürsen
@ 2018-01-19 15:11 ` Jemma Denson
2018-01-20 15:49 ` Tycho Lürsen
0 siblings, 1 reply; 26+ messages in thread
From: Jemma Denson @ 2018-01-19 15:11 UTC (permalink / raw)
To: Tycho Lürsen, Soeren Moch, Mauro Carvalho Chehab,
Luis Alves, Linux Media Mailing List
Hi Tycho,
On 19/01/18 13:59, Tycho Lürsen wrote:
> Hi Jemma,
>
> I'm with you: let's get merged at least something!
>
> Did you find a maintainer for this driver?
> I can do simple stuff like in my fork of Soeren Moch's repo, but thats
> where it ends. I dont have the knowledge needed to maintain a driver.
Not yet, but I can't really say I've been looking - unfortunately real
life got in the way of anything over christmas. I'm not sure I do
either, but it really depends on what's required. From what I can see
from maintaining another driver then as long as the driver is working
there's not a whole lot to do.
>
> I think that your proposal to use a stripped version of Luis Alves
> repo is a no go, since it contains a couple of demod/tuner drivers
> that are not upstreamed yet. That complicates the upstreaming process
> too much, I think.
Oh, I would have stripped it *right* down and removed every card except
my TBS6280. The end result would probably be pretty close to Soeren's at
that point anyway, so I was starting to think like what you've done and
base it on that instead.
> I used a stripped version of Soeren Moch's repo to prove its stability
> instead, adding the drivers I need so I can test it. You can see what
> I did at :
> https://github.com/bas-t/linux-saa716x/commits/for-media-stripped
>
> This has been tested with linux 4.9.77, 4.14.14 and 4.15-rc8.
> Works like a charm for me.
>
Looks like a good start, I'd be tempted to remove all the other cards
though unless you have them available to test with. Keeps the submission
simpler and less to worry about, they can be added back in later if
someone has an itch to scratch (and hardware to test with!).
I do have a few other tbs 716x cards available here at work so might be
able to test some others out, but we're a bit busy at the moment so
would have to be on my own time and there's not much of that available
at the moment either :(
Jemma.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: SAA716x DVB driver
2018-01-19 15:11 ` Jemma Denson
@ 2018-01-20 15:49 ` Tycho Lürsen
2018-01-25 17:08 ` Jemma Denson
0 siblings, 1 reply; 26+ messages in thread
From: Tycho Lürsen @ 2018-01-20 15:49 UTC (permalink / raw)
To: Jemma Denson, Soeren Moch, Mauro Carvalho Chehab, Luis Alves,
Linux Media Mailing List
Hi Jemma,
Op 19-01-18 om 16:11 schreef Jemma Denson:
> Hi Tycho,
>
> On 19/01/18 13:59, Tycho Lürsen wrote:
>> Hi Jemma,
>>
>> I'm with you: let's get merged at least something!
>>
>> Did you find a maintainer for this driver?
>> I can do simple stuff like in my fork of Soeren Moch's repo, but thats
>> where it ends. I dont have the knowledge needed to maintain a driver.
> Not yet, but I can't really say I've been looking - unfortunately real
> life got in the way of anything over christmas. I'm not sure I do
> either, but it really depends on what's required. From what I can see
> from maintaining another driver then as long as the driver is working
> there's not a whole lot to do.
Right, but we still need a maintainer. Are you capable/willing to
volunteer for the job?
>
>> I think that your proposal to use a stripped version of Luis Alves
>> repo is a no go, since it contains a couple of demod/tuner drivers
>> that are not upstreamed yet. That complicates the upstreaming process
>> too much, I think.
> Oh, I would have stripped it *right* down and removed every card except
> my TBS6280. The end result would probably be pretty close to Soeren's at
> that point anyway, so I was starting to think like what you've done and
> base it on that instead.
If you want, I can strip the driver down a lot more and ad back the
drivers you need. Just tell me what it is you need.
>
>> I used a stripped version of Soeren Moch's repo to prove its stability
>> instead, adding the drivers I need so I can test it. You can see what
>> I did at :
>> https://github.com/bas-t/linux-saa716x/commits/for-media-stripped
>>
>> This has been tested with linux 4.9.77, 4.14.14 and 4.15-rc8.
>> Works like a charm for me.
>>
> Looks like a good start, I'd be tempted to remove all the other cards
> though unless you have them available to test with. Keeps the submission
> simpler and less to worry about, they can be added back in later if
> someone has an itch to scratch (and hardware to test with!).
Isn't that a bit drastic?
I mean: those few drivers have been there for ages, and I can't recall
anyone complaining about them in a serious way.
>
> I do have a few other tbs 716x cards available here at work so might be
> able to test some others out, but we're a bit busy at the moment so
> would have to be on my own time and there's not much of that available
> at the moment either :(
As I said: give me the numbers of your tbs cards and I will add support
for them (if they are supported by Luis Alves repo).
That way you are able to test the stability of the saa716x driver in
it's present state.
>
>
> Jemma.
Tycho.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: SAA716x DVB driver
2018-01-20 15:49 ` Tycho Lürsen
@ 2018-01-25 17:08 ` Jemma Denson
0 siblings, 0 replies; 26+ messages in thread
From: Jemma Denson @ 2018-01-25 17:08 UTC (permalink / raw)
To: Tycho Lürsen, Soeren Moch, Mauro Carvalho Chehab,
Luis Alves, Linux Media Mailing List
Hi Tycho,
On 20/01/18 15:49, Tycho Lürsen wrote:
> Right, but we still need a maintainer. Are you capable/willing to
> volunteer for the job?
If no-one else will then yes I can, but I can't claim to know these devices
inside out. It would really depend on what's required of a maintainer, I'm
struggling to find this documented anywhere.
Cards I can't test with would really need someone to be able to add a
tested-by to verify they work.
>>
>>> I think that your proposal to use a stripped version of Luis Alves
>>> repo is a no go, since it contains a couple of demod/tuner drivers
>>> that are not upstreamed yet. That complicates the upstreaming process
>>> too much, I think.
>> Oh, I would have stripped it *right* down and removed every card except
>> my TBS6280. The end result would probably be pretty close to Soeren's at
>> that point anyway, so I was starting to think like what you've done and
>> base it on that instead.
> If you want, I can strip the driver down a lot more and ad back the
> drivers you need. Just tell me what it is you need.
As above, it's really just a case of making it maintainable. If someone
can step forward and ack for them working then they could be included
but if not then I think it's best dropping them until that happens.
Jemma.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [GIT PULL RESEND] SAA716x DVB driver
2017-08-23 9:56 ` [GIT PULL RESEND] " Soeren Moch
@ 2018-03-07 15:14 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 26+ messages in thread
From: Mauro Carvalho Chehab @ 2018-03-07 15:14 UTC (permalink / raw)
To: Soeren Moch; +Cc: Andreas Regel, Manu Abraham, Oliver Endriss, linux-media
Hi Sören,
Em Wed, 23 Aug 2017 11:56:50 +0200
Soeren Moch <smoch@web.de> escreveu:
> Resend this pull request. Apparently my explanation one month ago,
> why we need the userspace API of this driver in the current form [1],
> got lost.
As discussed in priv, I'm ok to merge this at staging, provided that
you add this to its TODO[1] with something like:
* The osd/video/audio APIs should be redesigned in order to fit
the needs for modern embedded hardware.
In other words, once we have an API for FF devices that work for modern
embedded hardware, this driver should either be changed to work with it
or may be removed on future Kernel versions, if it becomes incompatible
with whatever DVB core changes required for it.
[1] https://github.com/s-moch/linux-saa716x/blob/for-media/drivers/staging/media/saa716x/TODO
I'm marking the current pull request with "Changes Requested".
Thanks,
Mauro
^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2018-03-07 15:14 UTC | newest]
Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-07-16 18:34 [GIT PULL] SAA716x DVB driver Soeren Moch
2017-07-20 10:49 ` Mauro Carvalho Chehab
2017-07-21 20:44 ` Soeren Moch
2017-08-27 10:30 ` Mauro Carvalho Chehab
2017-09-09 12:52 ` Soeren Moch
2017-09-09 21:20 ` Mauro Carvalho Chehab
2017-09-16 12:54 ` Soeren Moch
2017-09-16 17:49 ` Mauro Carvalho Chehab
2017-09-24 22:17 ` Soeren Moch
2017-11-24 16:28 ` Tycho Lürsen
2017-11-27 11:24 ` Mauro Carvalho Chehab
2017-12-02 18:51 ` Jemma Denson
2017-12-02 19:49 ` Mauro Carvalho Chehab
2017-12-02 23:59 ` Soeren Moch
2017-12-03 10:57 ` Jemma Denson
2017-12-03 14:11 ` Soeren Moch
2017-12-03 15:04 ` Jemma Denson
2017-12-04 10:07 ` Mauro Carvalho Chehab
2018-01-19 13:59 ` Tycho Lürsen
2018-01-19 15:11 ` Jemma Denson
2018-01-20 15:49 ` Tycho Lürsen
2018-01-25 17:08 ` Jemma Denson
2017-11-28 18:35 ` [GIT PULL] " Mauro Carvalho Chehab
2017-12-02 23:58 ` Soeren Moch
2017-08-23 9:56 ` [GIT PULL RESEND] " Soeren Moch
2018-03-07 15:14 ` Mauro Carvalho Chehab
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).