* [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
* 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-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-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] 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-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
* [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 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).