This patchset is adding the full Soft Decision Forward Error
Correction (SD-FEC) driver implementation, driver DT binding and
driver documentation.
Forward Error Correction (FEC) codes such as Low Density Parity
Check (LDPC) and turbo codes provide a means to control errors in
data transmissions over unreliable or noisy communication
channels. The SD-FEC Integrated Block is an optimized block for
soft-decision decoding of these codes. Fixed turbo codes are
supported directly, whereas custom and standardized LDPC codes
are supported through the ability to specify the parity check
matrix through an AXI4-Lite bus or using the optional programmable
(PL)-based support logic. For the further information see
https://www.xilinx.com/support/documentation/ip_documentation/
sd_fec/v1_1/pg256-sdfec-integrated-block.pdf
This driver is a platform device driver which supports SDFEC16
(16nm) IP. SD-FEC driver supports LDPC decoding and encoding and
Turbo code decoding. LDPC codes can be specified on
a codeword-by-codeword basis, also a custom LDPC code can be used.
The SD-FEC driver exposes a char device interface and supports
file operations: open(), close(), poll() and ioctl(). The driver
allows only one usage of the device, open() limits the number of
driver instances. The driver also utilize Common Clock Framework
(CCF).
The control and monitoring is supported over ioctl system call.
The features supported by ioctl():
- enable or disable data pipes to/from device
- configure the FEC algorithm parameters
- set the order of data
- provide a control of a SDFEC bypass option
- activates/deactivates SD-FEC
- collect and provide statistical data
- enable/disable interrupt mode
Poll can be utilized to detect errors on IRQ trigger rather than
using looping status and stats ioctl's.
Tested-by: Santhosh Dyavanapally <[email protected]>
Tested by: Punnaiah Choudary Kalluri <[email protected]>
Tested-by: Dragan Cvetic <[email protected]>
Signed-off-by: Derek Kiernan <[email protected]>
Signed-off-by: Dragan Cvetic <[email protected]>
Changes V1 -> V2:
- Removed unnecesary comenting from the commit messages.
- Removed error log messages which can be triggered from user space.
- Corrected the SDFEC table end addresses.
- Removed casting between user pointer and kernel pointer.
- Corrected definition of ioctl command code, used a corect type for
size parameters.
- Changes to declarations of IOCTL that pass structures, i.e. do not
use pointers for sizeof as prevents compile time checks
- IOCTL size fix, using a paging to manage a memory. Implemented a big
tables transfer from user to kernel with get_user_pages_fast().
- Removed unnecessary check after container_of.
- Removed not needed ioctl code checkes inside ioctl handler.
- Implemented compat_ioctl.
- Updated reviewer and tester lists.
- Updated documentation, added Limitation chapter related to fork()
and dup().
Link to V1 patch series:
https://lore.kernel.org/lkml/[email protected]/
Changes V2 -> V3:
- Corrected a licence in xilinx_sdfec.h changed to uapi licence format.
- Corrected driver variable data types into user space data types.
Link to V2 patch series:
https://lore.kernel.org/lkml/[email protected]/
Changes V3 -> V4:
- Migrate to simplier misc driver
- Fix DT example
- Remove helper function
- Remove unused open_count variable
- Remove some logs
- Change log level to dev_dbg in the most logs
- Change spin lock to spin_lock_irqsave/spin_lock_irqrestore
- Correct a licence date in xilinx_sdfec.c
- Add PTR_ERR in clock handling
Link to V3 patch series:
https://lore.kernel.org/lkml/[email protected]/
Changes V4 -> V5:
- change atomic variables to c type variables
- align spinlock name to better description
- correct a logicla error in LDPC algorithm
- remove log messages
- remove useless if statements
- remove not needed fec_id variable
- squash commit 4 with 6
Link to V4 patch series:
https://lore.kernel.org/lkml/[email protected]/
Changes V5 -> V6:
- the kernle/user space variables convert enums to __u32
- put device ID under IDR
Link to V5 patch series:
https://lore.kernel.org/lkml/[email protected]/
Changes V6 -> V7:
- Fix maintainers list
Link to V6 patch series:
https://lore.kernel.org/lkml/[email protected]/
Dragan Cvetic (11):
dt-bindings: xilinx-sdfec: Add SDFEC binding
misc: xilinx-sdfec: add core driver
misc: xilinx_sdfec: Add CCF support
misc: xilinx_sdfec: Store driver config and state
misc: xilinx_sdfec: Add ability to configure turbo
misc: xilinx_sdfec: Add ability to configure LDPC
misc: xilinx_sdfec: Add ability to get/set config
misc: xilinx_sdfec: Support poll file operation
misc: xilinx_sdfec: Add stats & status ioctls
Docs: misc: xilinx_sdfec: Add documentation
MAINTAINERS: add maintainer for SD-FEC
.../devicetree/bindings/misc/xlnx,sd-fec.txt | 58 +
Documentation/misc-devices/index.rst | 1 +
Documentation/misc-devices/xilinx_sdfec.rst | 291 ++++
MAINTAINERS | 9 +
drivers/misc/Kconfig | 12 +
drivers/misc/Makefile | 1 +
drivers/misc/xilinx_sdfec.c | 1516 ++++++++++++++++++++
include/uapi/misc/xilinx_sdfec.h | 448 ++++++
8 files changed, 2336 insertions(+)
create mode 100644 Documentation/devicetree/bindings/misc/xlnx,sd-fec.txt
create mode 100644 Documentation/misc-devices/xilinx_sdfec.rst
create mode 100644 drivers/misc/xilinx_sdfec.c
create mode 100644 include/uapi/misc/xilinx_sdfec.h
--
2.7.4
On Tue, Jun 11, 2019 at 06:29:34PM +0100, Dragan Cvetic wrote:
> This patchset is adding the full Soft Decision Forward Error
> Correction (SD-FEC) driver implementation, driver DT binding and
> driver documentation.
>
> Forward Error Correction (FEC) codes such as Low Density Parity
> Check (LDPC) and turbo codes provide a means to control errors in
> data transmissions over unreliable or noisy communication
> channels. The SD-FEC Integrated Block is an optimized block for
> soft-decision decoding of these codes. Fixed turbo codes are
> supported directly, whereas custom and standardized LDPC codes
> are supported through the ability to specify the parity check
> matrix through an AXI4-Lite bus or using the optional programmable
> (PL)-based support logic. For the further information see
> https://www.xilinx.com/support/documentation/ip_documentation/
> sd_fec/v1_1/pg256-sdfec-integrated-block.pdf
>
> This driver is a platform device driver which supports SDFEC16
> (16nm) IP. SD-FEC driver supports LDPC decoding and encoding and
> Turbo code decoding. LDPC codes can be specified on
> a codeword-by-codeword basis, also a custom LDPC code can be used.
>
> The SD-FEC driver exposes a char device interface and supports
> file operations: open(), close(), poll() and ioctl(). The driver
> allows only one usage of the device, open() limits the number of
> driver instances. The driver also utilize Common Clock Framework
> (CCF).
>
> The control and monitoring is supported over ioctl system call.
> The features supported by ioctl():
> - enable or disable data pipes to/from device
> - configure the FEC algorithm parameters
> - set the order of data
> - provide a control of a SDFEC bypass option
> - activates/deactivates SD-FEC
> - collect and provide statistical data
> - enable/disable interrupt mode
Is there any userspace tool that talks to this device using these custom
ioctls yet?
Doing a one-off ioctl api is always a risky thing, you are pretty much
just creating brand new system calls for one piece of hardware.
Anyway, I took the first 3 patches here because they looked sane. and
stopped when I ran into the ioctl problem...
thanks,
greg k-h
> -----Original Message-----
> From: Greg KH [mailto:[email protected]]
> Sent: Friday 21 June 2019 15:16
> To: Dragan Cvetic <[email protected]>
> Cc: [email protected]; Michal Simek <[email protected]>; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected]; Derek Kiernan <[email protected]>
> Subject: Re: [PATCH V7 00/11] misc: xilinx sd-fec drive
>
> On Tue, Jun 11, 2019 at 06:29:34PM +0100, Dragan Cvetic wrote:
> > This patchset is adding the full Soft Decision Forward Error
> > Correction (SD-FEC) driver implementation, driver DT binding and
> > driver documentation.
> >
> > Forward Error Correction (FEC) codes such as Low Density Parity
> > Check (LDPC) and turbo codes provide a means to control errors in
> > data transmissions over unreliable or noisy communication
> > channels. The SD-FEC Integrated Block is an optimized block for
> > soft-decision decoding of these codes. Fixed turbo codes are
> > supported directly, whereas custom and standardized LDPC codes
> > are supported through the ability to specify the parity check
> > matrix through an AXI4-Lite bus or using the optional programmable
> > (PL)-based support logic. For the further information see
> > https://www.xilinx.com/support/documentation/ip_documentation/
> > sd_fec/v1_1/pg256-sdfec-integrated-block.pdf
> >
> > This driver is a platform device driver which supports SDFEC16
> > (16nm) IP. SD-FEC driver supports LDPC decoding and encoding and
> > Turbo code decoding. LDPC codes can be specified on
> > a codeword-by-codeword basis, also a custom LDPC code can be used.
> >
> > The SD-FEC driver exposes a char device interface and supports
> > file operations: open(), close(), poll() and ioctl(). The driver
> > allows only one usage of the device, open() limits the number of
> > driver instances. The driver also utilize Common Clock Framework
> > (CCF).
> >
> > The control and monitoring is supported over ioctl system call.
> > The features supported by ioctl():
> > - enable or disable data pipes to/from device
> > - configure the FEC algorithm parameters
> > - set the order of data
> > - provide a control of a SDFEC bypass option
> > - activates/deactivates SD-FEC
> > - collect and provide statistical data
> > - enable/disable interrupt mode
>
> Is there any userspace tool that talks to this device using these custom
> ioctls yet?
>
Tools no, but could be the customer who is using the driver.
> Doing a one-off ioctl api is always a risky thing, you are pretty much
> just creating brand new system calls for one piece of hardware.
>
Why is that wrong and what is the risk?
What would you propose?
Definitely, I have to read about this.
> Anyway, I took the first 3 patches here because they looked sane. and
> stopped when I ran into the ioctl problem...
>
Thanks for these 3
Dragan
> thanks,
>
> greg k-h
On Fri, Jun 21, 2019 at 05:49:45PM +0000, Dragan Cvetic wrote:
>
>
> > -----Original Message-----
> > From: Greg KH [mailto:[email protected]]
> > Sent: Friday 21 June 2019 15:16
> > To: Dragan Cvetic <[email protected]>
> > Cc: [email protected]; Michal Simek <[email protected]>; [email protected]; [email protected];
> > [email protected]; [email protected]; [email protected]; Derek Kiernan <[email protected]>
> > Subject: Re: [PATCH V7 00/11] misc: xilinx sd-fec drive
> >
> > On Tue, Jun 11, 2019 at 06:29:34PM +0100, Dragan Cvetic wrote:
> > > This patchset is adding the full Soft Decision Forward Error
> > > Correction (SD-FEC) driver implementation, driver DT binding and
> > > driver documentation.
> > >
> > > Forward Error Correction (FEC) codes such as Low Density Parity
> > > Check (LDPC) and turbo codes provide a means to control errors in
> > > data transmissions over unreliable or noisy communication
> > > channels. The SD-FEC Integrated Block is an optimized block for
> > > soft-decision decoding of these codes. Fixed turbo codes are
> > > supported directly, whereas custom and standardized LDPC codes
> > > are supported through the ability to specify the parity check
> > > matrix through an AXI4-Lite bus or using the optional programmable
> > > (PL)-based support logic. For the further information see
> > > https://www.xilinx.com/support/documentation/ip_documentation/
> > > sd_fec/v1_1/pg256-sdfec-integrated-block.pdf
> > >
> > > This driver is a platform device driver which supports SDFEC16
> > > (16nm) IP. SD-FEC driver supports LDPC decoding and encoding and
> > > Turbo code decoding. LDPC codes can be specified on
> > > a codeword-by-codeword basis, also a custom LDPC code can be used.
> > >
> > > The SD-FEC driver exposes a char device interface and supports
> > > file operations: open(), close(), poll() and ioctl(). The driver
> > > allows only one usage of the device, open() limits the number of
> > > driver instances. The driver also utilize Common Clock Framework
> > > (CCF).
> > >
> > > The control and monitoring is supported over ioctl system call.
> > > The features supported by ioctl():
> > > - enable or disable data pipes to/from device
> > > - configure the FEC algorithm parameters
> > > - set the order of data
> > > - provide a control of a SDFEC bypass option
> > > - activates/deactivates SD-FEC
> > > - collect and provide statistical data
> > > - enable/disable interrupt mode
> >
> > Is there any userspace tool that talks to this device using these custom
> > ioctls yet?
> >
> Tools no, but could be the customer who is using the driver.
I don't understand this. Who has written code to talk to these
special ioctls from userspace? Is there a pointer to that code
anywhere?
> > Doing a one-off ioctl api is always a risky thing, you are pretty much
> > just creating brand new system calls for one piece of hardware.
> >
>
> Why is that wrong and what is the risk?
You now have custom syscalls for one specfic piece of hardware that you
now have to maintain working properly for the next 40+ years. You have
to make sure those calls are correct and that this is the correct api to
talk to this hardware.
> What would you propose?
> Definitely, I have to read about this.
What is this hardware and what is it used for? Who will be talking to
it from userspace? What userspace workload uses it? What tools need to
talk to it? Where is the code that uses these new apis?
thanks,
greg k-h
> -----Original Message-----
> From: Greg KH [mailto:[email protected]]
> Sent: Saturday 22 June 2019 07:02
> To: Dragan Cvetic <[email protected]>
> Cc: [email protected]; Michal Simek <[email protected]>; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected]; Derek Kiernan <[email protected]>
> Subject: Re: [PATCH V7 00/11] misc: xilinx sd-fec drive
>
> On Fri, Jun 21, 2019 at 05:49:45PM +0000, Dragan Cvetic wrote:
> >
> >
> > > -----Original Message-----
> > > From: Greg KH [mailto:[email protected]]
> > > Sent: Friday 21 June 2019 15:16
> > > To: Dragan Cvetic <[email protected]>
> > > Cc: [email protected]; Michal Simek <[email protected]>; [email protected]; [email protected];
> > > [email protected]; [email protected]; [email protected]; Derek Kiernan <[email protected]>
> > > Subject: Re: [PATCH V7 00/11] misc: xilinx sd-fec drive
> > >
> > > On Tue, Jun 11, 2019 at 06:29:34PM +0100, Dragan Cvetic wrote:
> > > > This patchset is adding the full Soft Decision Forward Error
> > > > Correction (SD-FEC) driver implementation, driver DT binding and
> > > > driver documentation.
> > > >
> > > > Forward Error Correction (FEC) codes such as Low Density Parity
> > > > Check (LDPC) and turbo codes provide a means to control errors in
> > > > data transmissions over unreliable or noisy communication
> > > > channels. The SD-FEC Integrated Block is an optimized block for
> > > > soft-decision decoding of these codes. Fixed turbo codes are
> > > > supported directly, whereas custom and standardized LDPC codes
> > > > are supported through the ability to specify the parity check
> > > > matrix through an AXI4-Lite bus or using the optional programmable
> > > > (PL)-based support logic. For the further information see
> > > > https://www.xilinx.com/support/documentation/ip_documentation/
> > > > sd_fec/v1_1/pg256-sdfec-integrated-block.pdf
> > > >
> > > > This driver is a platform device driver which supports SDFEC16
> > > > (16nm) IP. SD-FEC driver supports LDPC decoding and encoding and
> > > > Turbo code decoding. LDPC codes can be specified on
> > > > a codeword-by-codeword basis, also a custom LDPC code can be used.
> > > >
> > > > The SD-FEC driver exposes a char device interface and supports
> > > > file operations: open(), close(), poll() and ioctl(). The driver
> > > > allows only one usage of the device, open() limits the number of
> > > > driver instances. The driver also utilize Common Clock Framework
> > > > (CCF).
> > > >
> > > > The control and monitoring is supported over ioctl system call.
> > > > The features supported by ioctl():
> > > > - enable or disable data pipes to/from device
> > > > - configure the FEC algorithm parameters
> > > > - set the order of data
> > > > - provide a control of a SDFEC bypass option
> > > > - activates/deactivates SD-FEC
> > > > - collect and provide statistical data
> > > > - enable/disable interrupt mode
> > >
> > > Is there any userspace tool that talks to this device using these custom
> > > ioctls yet?
> > >
> > Tools no, but could be the customer who is using the driver.
>
> I don't understand this. Who has written code to talk to these
> special ioctls from userspace? Is there a pointer to that code
> anywhere?
>
The code which use this driver are written by the driver maintainers they are examples APP and test code which are not public.
> > > Doing a one-off ioctl api is always a risky thing, you are pretty much
> > > just creating brand new system calls for one piece of hardware.
> > >
> >
> > Why is that wrong and what is the risk?
>
> You now have custom syscalls for one specfic piece of hardware that you
> now have to maintain working properly for the next 40+ years. You have
> to make sure those calls are correct and that this is the correct api to
> talk to this hardware.
This is very specific HW, it's high speed Forward Error Correction HW.
I'll be happy if I maintain this for the next 40+ years.
Actually, forgive me asking, what architecture would make me not maintain this driver next 40+ years?
>
> > What would you propose?
> > Definitely, I have to read about this.
>
> What is this hardware and what is it used for? Who will be talking to
The Soft-Decision Forward Error Correction (SD-FEC) integrated block supports Low Density Parity Check (LDPC) decoding and encoding and Turbo code decoding.
SD-FEC use case is in high data rate applications such as 4G, 5G and DOCSIS3.1 Cable Access.
A high performance SD-FEC (i.e. >1Gbps), is a block used to enable these systems to function under non-ideal environments.
> it from userspace? What userspace workload uses it? What tools need to
There will be APP which configures the HW for the use cases listed above.
Thanks
Dragan
> talk to it? Where is the code that uses these new apis?
>
> thanks,
>
> greg k-h
> -----Original Message-----
> From: Greg KH [mailto:[email protected]]
> Sent: Saturday 22 June 2019 07:02
> To: Dragan Cvetic <[email protected]>
> Cc: [email protected]; Michal Simek <[email protected]>; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected]; Derek Kiernan <[email protected]>
> Subject: Re: [PATCH V7 00/11] misc: xilinx sd-fec drive
>
> On Fri, Jun 21, 2019 at 05:49:45PM +0000, Dragan Cvetic wrote:
> >
> >
> > > -----Original Message-----
> > > From: Greg KH [mailto:[email protected]]
> > > Sent: Friday 21 June 2019 15:16
> > > To: Dragan Cvetic <[email protected]>
> > > Cc: [email protected]; Michal Simek <[email protected]>; [email protected]; [email protected];
> > > [email protected]; [email protected]; [email protected]; Derek Kiernan <[email protected]>
> > > Subject: Re: [PATCH V7 00/11] misc: xilinx sd-fec drive
> > >
> > > On Tue, Jun 11, 2019 at 06:29:34PM +0100, Dragan Cvetic wrote:
> > > > This patchset is adding the full Soft Decision Forward Error
> > > > Correction (SD-FEC) driver implementation, driver DT binding and
> > > > driver documentation.
> > > >
> > > > Forward Error Correction (FEC) codes such as Low Density Parity
> > > > Check (LDPC) and turbo codes provide a means to control errors in
> > > > data transmissions over unreliable or noisy communication
> > > > channels. The SD-FEC Integrated Block is an optimized block for
> > > > soft-decision decoding of these codes. Fixed turbo codes are
> > > > supported directly, whereas custom and standardized LDPC codes
> > > > are supported through the ability to specify the parity check
> > > > matrix through an AXI4-Lite bus or using the optional programmable
> > > > (PL)-based support logic. For the further information see
> > > > https://www.xilinx.com/support/documentation/ip_documentation/
> > > > sd_fec/v1_1/pg256-sdfec-integrated-block.pdf
> > > >
> > > > This driver is a platform device driver which supports SDFEC16
> > > > (16nm) IP. SD-FEC driver supports LDPC decoding and encoding and
> > > > Turbo code decoding. LDPC codes can be specified on
> > > > a codeword-by-codeword basis, also a custom LDPC code can be used.
> > > >
> > > > The SD-FEC driver exposes a char device interface and supports
> > > > file operations: open(), close(), poll() and ioctl(). The driver
> > > > allows only one usage of the device, open() limits the number of
> > > > driver instances. The driver also utilize Common Clock Framework
> > > > (CCF).
> > > >
> > > > The control and monitoring is supported over ioctl system call.
> > > > The features supported by ioctl():
> > > > - enable or disable data pipes to/from device
> > > > - configure the FEC algorithm parameters
> > > > - set the order of data
> > > > - provide a control of a SDFEC bypass option
> > > > - activates/deactivates SD-FEC
> > > > - collect and provide statistical data
> > > > - enable/disable interrupt mode
> > >
> > > Is there any userspace tool that talks to this device using these custom
> > > ioctls yet?
> > >
> > Tools no, but could be the customer who is using the driver.
>
> I don't understand this. Who has written code to talk to these
> special ioctls from userspace? Is there a pointer to that code
> anywhere?
>
> > > Doing a one-off ioctl api is always a risky thing, you are pretty much
> > > just creating brand new system calls for one piece of hardware.
> > >
> >
> > Why is that wrong and what is the risk?
>
> You now have custom syscalls for one specfic piece of hardware that you
> now have to maintain working properly for the next 40+ years. You have
> to make sure those calls are correct and that this is the correct api to
> talk to this hardware.
>
The only idea I have got from the comments are to do more abstraction
eg. have a few ioctls with the abstraction done through the passing arguments?
> > What would you propose?
> > Definitely, I have to read about this.
>
> What is this hardware and what is it used for? Who will be talking to
> it from userspace? What userspace workload uses it? What tools need to
> talk to it? Where is the code that uses these new apis?
>
> thanks,
>
> greg k-h
On Sat, Jun 22, 2019 at 05:54:04PM +0000, Dragan Cvetic wrote:
>
>
> > -----Original Message-----
> > From: Greg KH [mailto:[email protected]]
> > Sent: Saturday 22 June 2019 07:02
> > To: Dragan Cvetic <[email protected]>
> > Cc: [email protected]; Michal Simek <[email protected]>; [email protected]; [email protected];
> > [email protected]; [email protected]; [email protected]; Derek Kiernan <[email protected]>
> > Subject: Re: [PATCH V7 00/11] misc: xilinx sd-fec drive
> >
> > On Fri, Jun 21, 2019 at 05:49:45PM +0000, Dragan Cvetic wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: Greg KH [mailto:[email protected]]
> > > > Sent: Friday 21 June 2019 15:16
> > > > To: Dragan Cvetic <[email protected]>
> > > > Cc: [email protected]; Michal Simek <[email protected]>; [email protected]; [email protected];
> > > > [email protected]; [email protected]; [email protected]; Derek Kiernan <[email protected]>
> > > > Subject: Re: [PATCH V7 00/11] misc: xilinx sd-fec drive
> > > >
> > > > On Tue, Jun 11, 2019 at 06:29:34PM +0100, Dragan Cvetic wrote:
> > > > > This patchset is adding the full Soft Decision Forward Error
> > > > > Correction (SD-FEC) driver implementation, driver DT binding and
> > > > > driver documentation.
> > > > >
> > > > > Forward Error Correction (FEC) codes such as Low Density Parity
> > > > > Check (LDPC) and turbo codes provide a means to control errors in
> > > > > data transmissions over unreliable or noisy communication
> > > > > channels. The SD-FEC Integrated Block is an optimized block for
> > > > > soft-decision decoding of these codes. Fixed turbo codes are
> > > > > supported directly, whereas custom and standardized LDPC codes
> > > > > are supported through the ability to specify the parity check
> > > > > matrix through an AXI4-Lite bus or using the optional programmable
> > > > > (PL)-based support logic. For the further information see
> > > > > https://www.xilinx.com/support/documentation/ip_documentation/
> > > > > sd_fec/v1_1/pg256-sdfec-integrated-block.pdf
> > > > >
> > > > > This driver is a platform device driver which supports SDFEC16
> > > > > (16nm) IP. SD-FEC driver supports LDPC decoding and encoding and
> > > > > Turbo code decoding. LDPC codes can be specified on
> > > > > a codeword-by-codeword basis, also a custom LDPC code can be used.
> > > > >
> > > > > The SD-FEC driver exposes a char device interface and supports
> > > > > file operations: open(), close(), poll() and ioctl(). The driver
> > > > > allows only one usage of the device, open() limits the number of
> > > > > driver instances. The driver also utilize Common Clock Framework
> > > > > (CCF).
> > > > >
> > > > > The control and monitoring is supported over ioctl system call.
> > > > > The features supported by ioctl():
> > > > > - enable or disable data pipes to/from device
> > > > > - configure the FEC algorithm parameters
> > > > > - set the order of data
> > > > > - provide a control of a SDFEC bypass option
> > > > > - activates/deactivates SD-FEC
> > > > > - collect and provide statistical data
> > > > > - enable/disable interrupt mode
> > > >
> > > > Is there any userspace tool that talks to this device using these custom
> > > > ioctls yet?
> > > >
> > > Tools no, but could be the customer who is using the driver.
> >
> > I don't understand this. Who has written code to talk to these
> > special ioctls from userspace? Is there a pointer to that code
> > anywhere?
> >
>
> The code which use this driver are written by the driver maintainers
> they are examples APP and test code which are not public.
So, no open code is talking to this one specific driver? And you have
run this past your lawyers? Please go talk to them about this and see
what they say (hint, creating a custom ioctl that only you use is a
"fun" legal area...)
> > > > Doing a one-off ioctl api is always a risky thing, you are pretty much
> > > > just creating brand new system calls for one piece of hardware.
> > > >
> > >
> > > Why is that wrong and what is the risk?
> >
> > You now have custom syscalls for one specfic piece of hardware that you
> > now have to maintain working properly for the next 40+ years. You have
> > to make sure those calls are correct and that this is the correct api to
> > talk to this hardware.
>
> This is very specific HW, it's high speed Forward Error Correction HW.
I have no idea what that actually means.
What is "Forward Error Correction"? What does it do? Is this a network
device? Video device? Random black box that sends radio waves?
Is there no other in-kernel driver that does much the same type of
thing? What "class" of driver would this be?
> > > What would you propose?
> > > Definitely, I have to read about this.
> >
> > What is this hardware and what is it used for? Who will be talking to
>
> The Soft-Decision Forward Error Correction (SD-FEC) integrated block
> supports Low Density Parity Check (LDPC) decoding and encoding and
> Turbo code decoding.
I still don't understand what this means.
> SD-FEC use case is in high data rate applications such as 4G, 5G and
> DOCSIS3.1 Cable Access. A high performance SD-FEC (i.e. >1Gbps), is a
> block used to enable these systems to function under non-ideal
> environments.
Nor do I understand what this is either. Do you have a pointer to this
hardware somewhere online that might describe it better? Given that I
have no clue, odds are others do not know what it is either.
> > it from userspace? What userspace workload uses it? What tools need to
>
> There will be APP which configures the HW for the use cases listed above.
What exactly are these use cases?
Where is the application? Who runs it? Is it already in a distro
somewhere? Who is going to distribute it? Who is going to support it?
Is it only for sale? What is the license of it?
thanks,
greg k-h
> -----Original Message-----
> From: Greg KH [mailto:[email protected]]
> Sent: Wednesday 31 July 2019 13:49
> To: Dragan Cvetic <[email protected]>
> Cc: [email protected]; Michal Simek <[email protected]>; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected]; Derek Kiernan <[email protected]>
> Subject: Re: [PATCH V7 00/11] misc: xilinx sd-fec drive
>
> On Sat, Jun 22, 2019 at 05:54:04PM +0000, Dragan Cvetic wrote:
> >
> >
> > > -----Original Message-----
> > > From: Greg KH [mailto:[email protected]]
> > > Sent: Saturday 22 June 2019 07:02
> > > To: Dragan Cvetic <[email protected]>
> > > Cc: [email protected]; Michal Simek <[email protected]>; [email protected]; [email protected];
> > > [email protected]; [email protected]; [email protected]; Derek Kiernan <[email protected]>
> > > Subject: Re: [PATCH V7 00/11] misc: xilinx sd-fec drive
> > >
> > > On Fri, Jun 21, 2019 at 05:49:45PM +0000, Dragan Cvetic wrote:
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Greg KH [mailto:[email protected]]
> > > > > Sent: Friday 21 June 2019 15:16
> > > > > To: Dragan Cvetic <[email protected]>
> > > > > Cc: [email protected]; Michal Simek <[email protected]>; [email protected]; [email protected];
> > > > > [email protected]; [email protected]; [email protected]; Derek Kiernan <[email protected]>
> > > > > Subject: Re: [PATCH V7 00/11] misc: xilinx sd-fec drive
> > > > >
> > > > > On Tue, Jun 11, 2019 at 06:29:34PM +0100, Dragan Cvetic wrote:
> > > > > > This patchset is adding the full Soft Decision Forward Error
> > > > > > Correction (SD-FEC) driver implementation, driver DT binding and
> > > > > > driver documentation.
> > > > > >
> > > > > > Forward Error Correction (FEC) codes such as Low Density Parity
> > > > > > Check (LDPC) and turbo codes provide a means to control errors in
> > > > > > data transmissions over unreliable or noisy communication
> > > > > > channels. The SD-FEC Integrated Block is an optimized block for
> > > > > > soft-decision decoding of these codes. Fixed turbo codes are
> > > > > > supported directly, whereas custom and standardized LDPC codes
> > > > > > are supported through the ability to specify the parity check
> > > > > > matrix through an AXI4-Lite bus or using the optional programmable
> > > > > > (PL)-based support logic. For the further information see
> > > > > > https://www.xilinx.com/support/documentation/ip_documentation/
> > > > > > sd_fec/v1_1/pg256-sdfec-integrated-block.pdf
> > > > > >
> > > > > > This driver is a platform device driver which supports SDFEC16
> > > > > > (16nm) IP. SD-FEC driver supports LDPC decoding and encoding and
> > > > > > Turbo code decoding. LDPC codes can be specified on
> > > > > > a codeword-by-codeword basis, also a custom LDPC code can be used.
> > > > > >
> > > > > > The SD-FEC driver exposes a char device interface and supports
> > > > > > file operations: open(), close(), poll() and ioctl(). The driver
> > > > > > allows only one usage of the device, open() limits the number of
> > > > > > driver instances. The driver also utilize Common Clock Framework
> > > > > > (CCF).
> > > > > >
> > > > > > The control and monitoring is supported over ioctl system call.
> > > > > > The features supported by ioctl():
> > > > > > - enable or disable data pipes to/from device
> > > > > > - configure the FEC algorithm parameters
> > > > > > - set the order of data
> > > > > > - provide a control of a SDFEC bypass option
> > > > > > - activates/deactivates SD-FEC
> > > > > > - collect and provide statistical data
> > > > > > - enable/disable interrupt mode
> > > > >
> > > > > Is there any userspace tool that talks to this device using these custom
> > > > > ioctls yet?
> > > > >
> > > > Tools no, but could be the customer who is using the driver.
> > >
> > > I don't understand this. Who has written code to talk to these
> > > special ioctls from userspace? Is there a pointer to that code
> > > anywhere?
> > >
> >
> > The code which use this driver are written by the driver maintainers
> > they are examples APP and test code which are not public.
>
> So, no open code is talking to this one specific driver? And you have
> run this past your lawyers? Please go talk to them about this and see
> what they say (hint, creating a custom ioctl that only you use is a
> "fun" legal area...)
Greg,
this driver and all example code APP will be public and open source
fully. In that sense this code is same as any other driver.
>
> > > > > Doing a one-off ioctl api is always a risky thing, you are pretty much
> > > > > just creating brand new system calls for one piece of hardware.
> > > > >
> > > >
> > > > Why is that wrong and what is the risk?
> > >
> > > You now have custom syscalls for one specfic piece of hardware that you
> > > now have to maintain working properly for the next 40+ years. You have
> > > to make sure those calls are correct and that this is the correct api to
> > > talk to this hardware.
> >
> > This is very specific HW, it's high speed Forward Error Correction HW.
>
> I have no idea what that actually means.
>
> What is "Forward Error Correction"? What does it do? Is this a network
> device? Video device? Random black box that sends radio waves?
>
> Is there no other in-kernel driver that does much the same type of
> thing? What "class" of driver would this be?
This is the RF data communication device, type "misc" driver.
>
> > > > What would you propose?
> > > > Definitely, I have to read about this.
> > >
> > > What is this hardware and what is it used for? Who will be talking to
> >
> > The Soft-Decision Forward Error Correction (SD-FEC) integrated block
> > supports Low Density Parity Check (LDPC) decoding and encoding and
> > Turbo code decoding.
>
> I still don't understand what this means.
>
> > SD-FEC use case is in high data rate applications such as 4G, 5G and
> > DOCSIS3.1 Cable Access. A high performance SD-FEC (i.e. >1Gbps), is a
> > block used to enable these systems to function under non-ideal
> > environments.
>
> Nor do I understand what this is either. Do you have a pointer to this
> hardware somewhere online that might describe it better? Given that I
> have no clue, odds are others do not know what it is either.
https://www.xilinx.com/support/documentation/ip_documentation/sd_fec/v1_1/pg256-sdfec-integrated-block.pdf
>
> > > it from userspace? What userspace workload uses it? What tools need to
> >
> > There will be APP which configures the HW for the use cases listed above.
>
> What exactly are these use cases?
>
> Where is the application? Who runs it? Is it already in a distro
> somewhere? Who is going to distribute it? Who is going to support it?
> Is it only for sale? What is the license of it?
According to marketing people here there are about 72 individual programs
spanning probably ~40 different customers. These are possible users
and APP will be created and run by them.
Driver will be supported by us, APP by customers with our technical support.
Is it for sale? Xilinx gives away all drivers and examples for free, it's up to the
Customer what they do with it and they meet open source licence legal requirements.
Greg,
I'll be out of the office from Friday for a couple of weeks, and I'll try my best to respond on your replies after that.
>
> thanks,
>
> greg k-h