Quantcast
Channel: Xilinx Wiki : Xilinx Wiki - all changes
Viewing all 11776 articles
Browse latest View live

Video_Mixer

$
0
0
= {under.jpg}
=

{under.jpg}
=

Overview
The Linux Video Mixer driver is an early access DRM kernel driver designed to provide support for the Xilinx LogiCORE IP Video Mixer (v2.0). The Video Mixer is a configurable IP core than can blend up to eight video layers in addition to an optional logo layer into a single output video stream.

Video_Mixer

$
0
0
...
8
Layer Video Formats
...
RGBX8, YUYV8, RGBA8,
RGBA8,
BGRA8, Y_UV8, Y_UV8_420
Y_UV8_420

[2017.1/2 list
...
YUV8, YUVX8, YUVA8,
YUVA8,
Y8, UYVY8
UYVY8

Layer Alpha
Yes

Video_Mixer

$
0
0

Xilinx V4L2 VPSS Scaler driver (2017.3 Updates)

$
0
0

{under.jpg}
{under.jpg} 2017.3 Updates
The purpose of this page is to describe the Linux V4L2 driver for Xilinx VPSS Scaler soft IP. VPSS refers to the Video Processing Sub System.
To understand more about the capabilities of this IP please see the Product Guide (Scaler Only configuration) for VPSS.
Overview
The Linux VPSS Scaler driver (xilinx-vpss-scaler.c) based on the V4L2 framework creates a subdev node(/dev/v4l-subdev*) which can be used to configure the VPSS Scaler IP core. The V4L2 VPSS Scaler driver controls the VPSS Scaler soft IP to achieve upscaling and downscaling of Video and it also provides certain color space conversions.
...
The dts node should be defined with correct hardware configuration. How to define the node is documented here:
Documentation/devicetree/bindings/media/xilinx/xlnx,v-vpss-scaler.txt
...
to your linuxLinux kernel source
Limitations
No driver support for bi-linear or bi-cubic scalers in this release
Asymmetrical scaler taps are not supported. Horizontal taps must be same as Vertical taps.
Colorspace support options are limited to only RGB | YUV 4:4:4 | YUV 4:2:2 | YUV 4:2:0. All other colorspace options are not supported in this release.
Although VPSS Scaler enabled YUV 4:4:4 and YUV 4:2:0 support, current V4L2 infrastructure will not support YUV 4:4:4 and YUV 4:2:0 in this release.
10,12
12 and 16
...
to 8-bit and 10-bit in this
Supported Features
The following table compares the IP features against those supported by the V4L2 driver:
Scaler Only - VPSS (v 2.0) IP Features
VPSS Scaler V4L2 Driver Support
1. 8-bit color depth
2017.1 Early Access
2. Scaling Algorithm - Polyphase - 8 tap
2017.1 Early Access
3. Enable Color Space Conversion Selected (Enabled)
with Color Space Support for
RGB | YUV 4:4:4 | YUV 4:2:2 | YUV 4:2:0
2017.1 Early Access
(support for YUV 420 media bus format in
2017.3 Early Access)
4. 10-bit color depth
2017.3 Early Access
5. Scaling Algorithm - Bilinear
2017.3 Early Access
6. Scaling Algorithm - Bicubic
2017.3 Early Access
7. Scaling Algorithm - Polyphase
6, 8, 10, and 12 tap
2017.3 Early Access
8. Enable Color Space Conversion Unselected
(Color Space Conversion disabled)
Not Supported
9. Enable Color Space Conversion Selected (Enabled)
with Color Space Support for
RGB | YUV 4:4:4 | YUV 4:2:2
Not Supported
10.Enable Color Space Conversion Selected (Enabled)
with Color Space Support for
RGB | YUV 4:4:4
Not Supported

The VPSS Scaler driver supports only the following features are supported including:
Scaling using 6 tapbilinear, bicubic and poly-phase (6, 8, 10 and 12 tap) filters that
Color Space Conversion. The following color space conversions have been tested.
RGB to YUYV
Scaling Formats that have been tested are as follow :
Sr No.
...
3840x2160
1920x1080
...
maximum of 3840x2160).3840x2160 and a minimum of 224X128).
Vivado IP Configuration
The following snapshots show the Vivado GUI configuration that is supported. All other configurations are not supported in this release.
...
Pick RGB | YUV 4:4:4 | YUV 4:2:2 | YUV 4:2:0
{vpss-scaler.jpg}
4. Pick 8 tapsBilinear, Bicubic or Polyphase filter for both
{vpss-scaler-taps.jpg}
Boards Supported
...
ZCU106 Rev C
Technical Reference Designs
Coming SoonreVision Getting Started
Work to be done
Support to program custom values to the H-scaler and V-scaler coefficients entered by the user.
...
Xilinx V4L2 driver
VPSS Product Guide
Save

Xilinx V4L2 VPSS Scaler driver

$
0
0
...
2. Scaling Algorithm - Polyphase - 8 tap
2017.1 Early Access
...
Selected (Enabled)
with Color Space Support for
RGB | YUV 4:4:4 | YUV 4:2:2 | YUV 4:2:0
2017.1 Early Access
...
format in
2017.3 Early Access)
4. 10-bit color depth
...
(Color Space Conversion disabled)
Not Supported
...
Selected (Enabled)
with Color Space Support for
RGB | YUV 4:4:4 | YUV 4:2:2
Not Supported
...
Selected (Enabled)
with Color Space Support for
RGB | YUV 4:4:4
...
Xilinx V4L2 driver
VPSS Product Guide
Save

Video_Mixer

$
0
0
...
These properties, if described in the device tree, will be represented as DRM plane properties. To understand more about these capabilities, please refer to the Video Mixer Product Guide [PG243].
Additionally, the Video Mixer supports generation of solid background color when either the AXI streaming input is not connected or the layer is otherwise disabled. On initialization, this color is programmed to default to blue. The color may be configured using a value representing packed RGB little-endian format via the DRM plane property bg_color. This property is attached to the primary plane.
Test Procedure
To verify the proper configuration and operation of the IP, a suitable hardware design will need to include at a minimum:
1) Video DMA IP to supply an input stream to the Mixer IP (layer 0) (e.g. VDMA or Framebuffer DMA)
2) Video Mixer IP
3) HDMI Tx
modetest
Modetest is a test tool which can be found as part of the libdrm suite of test tools. We will use this tool to ensure proper configuration and operation of the Mixer IP. Modetest can be used to activate overlay layers and alter layer properties (e.g. layer alpha, layer scaling, background color)
Test 1 - Ensure DRM driver has been properly loaded and is configured
root@mixer_proj:~# modetest -M xilinx_drm_mixer
Output should include information about the Encoder, Connector, CRTC (the Mixer), Planes (Mixer layers). All Mixer layers will be deactivate by invoking modetest so the screen should become a solid hue of blue (the default background color).
Sample output (edited for brevity and clarity):
Encoders:
id crtc type possible crtcs possible clones
36 35 TMDS 0x00000001 0xffffffff
Connectors:
id encoder status name size (mm) modes encoders
37 36 connected HDMI-A-1 520x290 40 36
modes:
name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot)
3840x2160 30 3840 4016 4104 4400 2160 2168 2178 2250 flags: phsync, pvsync; type: driver
3840x2160 30 3840 4016 4104 4400 2160 2168 2178 2250 flags: phsync, pvsync; type: driver
3840x2160 25 3840 4896 4984 5280 2160 2168 2178 2250 flags: phsync, pvsync; type: driver
<snip>
640x480 60 640 656 752 800 480 490 492 525 flags: nhsync, nvsync; type: driver
720x400 70 720 738 846 900 400 412 414 449 flags: nhsync, pvsync; type: driver
props:
1 EDID:
flags: immutable blob
blobs:
value:
00ffffffffffff004c2dd30c44534d30
131a010380341d782a1255a9544d9f25
0c5054bfef80714f810081c081809500
a9c0b300010108e80030f2705a80b058
8a0009252100001e000000fd00184b1e
873c000a202020202020000000fc0055
3234453539300a2020202020000000ff
00485450483530313132310a2020011b
020334f04d611203130420221f105f60
5d5e23090707830100006d030c002000
803c20106001020367d85dc401788003
e30f0104023a801871382d40582c4500
09252100001e023a80d072382d40102c
458009252100001e011d007251d01e20
6e28550009252100001e565e00a0a0a0
29503020350009252100001a000000a0
2 DPMS:
flags: enum
enums: On=0 Standby=1 Suspend=2 Off=3
value: 0
CRTCs:
id fb pos size
35 44 (0,0) (1024x768)
1024x768 60 1024 1048 1184 1344 768 771 777 806 flags: nhsync, nvsync; type: driver
props:
Planes:
id crtc fb CRTC x,y x,y gamma size possible crtcs
26 0 0 0,0 0,0 0 0x00000001
formats: RA24
props:
5 type:
flags: immutable enum
enums: Overlay=0 Primary=1 Cursor=2
value: 2
23 scale:
flags: range
values: 0 2
value: 0
24 alpha:
flags: range
values: 0 256
value: 256
27 0 0 0,0 0,0 0 0x00000001
formats: YUYV
props:
5 type:
flags: immutable enum
enums: Overlay=0 Primary=1 Cursor=2
value: 0
23 scale:
flags: range
values: 0 2
value: 0
24 alpha:
flags: range
values: 0 256
value: 256
28 0 0 0,0 0,0 0 0x00000001
formats: UYVY
props:
5 type:
flags: immutable enum
enums: Overlay=0 Primary=1 Cursor=2
value: 0
23 scale:
flags: range
values: 0 2
value: 0
24 alpha:
flags: range
values: 0 256
value: 256
29 0 0 0,0 0,0 0 0x00000001
formats: AR24
props:
5 type:
flags: immutable enum
enums: Overlay=0 Primary=1 Cursor=2
value: 0
23 scale:
flags: range
values: 0 2
value: 0
24 alpha:
flags: range
values: 0 256
value: 256
30 0 0 0,0 0,0 0 0x00000001
formats: GREY
props:
5 type:
flags: immutable enum
enums: Overlay=0 Primary=1 Cursor=2
value: 0
23 scale:
flags: range
values: 0 2
value: 0
24 alpha:
flags: range
values: 0 256
value: 256
31 0 0 0,0 0,0 0 0x00000001
formats: XR24
props:
5 type:
flags: immutable enum
enums: Overlay=0 Primary=1 Cursor=2
value: 0
23 scale:
flags: range
values: 0 2
value: 0
24 alpha:
flags: range
values: 0 256
value: 256
32 0 0 0,0 0,0 0 0x00000001
formats: NV12
props:
5 type:
flags: immutable enum
enums: Overlay=0 Primary=1 Cursor=2
value: 0
23 scale:
flags: range
values: 0 2
value: 0
24 alpha:
flags: range
values: 0 256
value: 256
33 0 0 0,0 0,0 0 0x00000001
formats: BG24
props:
5 type:
flags: immutable enum
enums: Overlay=0 Primary=1 Cursor=2
value: 0
23 scale:
flags: range
values: 0 2
value: 0
24 alpha:
flags: range
values: 0 256
value: 256
34 35 44 0,0 0,0 0 0x00000001
formats: BG24
props:
5 type:
flags: immutable enum
enums: Overlay=0 Primary=1 Cursor=2
value: 1
25 bg_color:
flags: range
values: 0 16777215
value: 16711680
Frame buffers:
id size pitch
Test 2 - Activate an overlay layer
We will activate an overlay plane (RGB in this case) and position it to the top left corner while the background color is being generated using the following command:
root@mixer_proj:~# modetest -M xilinx_drm_mixer -P 35:640x480+0+0@BG24
Output should indicate the plane id that was activated:
testing 640x480@BG24 overlay plane 33
Additionally, the plane should be presented with diagonally stripped color pattern on screen.
Test 3 - Scale the layer (if enabled for the layer)
From within another console window (and/or if the previous test was run in the background), adjust the layer scale property using modetest.
The plane id (33 in case of the example above) will be needed to adjust overlay properties like scale, alpha or background color
root@mixer_proj:~# modetest -M xilinx_drm_mixer -w 33:scale:1
Note that the range of possible values for a property appears in the output of modetest. For example, in the case of plane id 33:
33 0 0 0,0 0,0 0 0x00000001
formats: BG24
props:
5 type:
flags: immutable enum
enums: Overlay=0 Primary=1 Cursor=2
value: 0
23 scale:
flags: range
values: 0 2
value: 0
24 alpha:
flags: range
values: 0 256
value: 256
Assuming the up-scaled version of the plane image will fit within the screen, the plane data should be doubled in size by setting the scale property to '1'.
Test 4 - Change layer alpha (if enabled for the layer)
Test 5 - Change the background color
vbltest
vbltest is a test tool which is part of the libdrm suite of test tools. It is used to ensure vertical blanking interrupts are properly sent by the DRM driver.

Video_Mixer

$
0
0
...
Assuming the up-scaled version of the plane image will fit within the screen, the plane data should be doubled in size by setting the scale property to '1'.
Test 4 - Change layer alpha (if enabled for the layer)
Changing the layer alpha will make an existing overlay layer appear more or less transparent. An alpha value of '0' will render the overlay invisible and a value of '256' will be completely opaque.
With an existing layer being displayed (see test 2), change the alpha property to '0' to render the layer invisible.
root@mixer_proj:~# modetest -M xilinx_drm_mixer -w 33:alpha:0
The layer should disappear.
Changing the alpha property back to 256 by repeating the above command with a value of 256 should render it visible again.
root@mixer_proj:~# modetest -M xilinx_drm_mixer -w 33:alpha:256

Test 5 - Change the background color
vbltest

Video_Mixer

$
0
0
...
root@mixer_proj:~# modetest -M xilinx_drm_mixer -w 33:alpha:256
Test 5 - Change the background color
The Mixer generates a background color when the primary layer is inactive. By default, this is blue. The color is controlled by an internal RGB-based register and is represented by modetest as a decimal value.
The most significant bits represent 'blue' and the least 'red'. As such, by default, only the upper 8 bits are set to generate a solid blue (0xFF0000) resulting in a default value of 16711680.
Change the background color to solid red:
root@mixer_proj:~# modetest -M xilinx_drm_mixer -w 34:bg_color:255
The background color should be a pure red and the new value of the bg_color property will be 255 (0x0000FF).

vbltest
vbltest is a test tool which is part of the libdrm suite of test tools. It is used to ensure vertical blanking interrupts are properly sent by the DRM driver.
root@mixer_proj:~# vbltest -M xilinx_drm_mixer
starting count: 0
freq: 60.49Hz
freq: 60.00Hz
freq: 60.00Hz
freq: 60.00Hz
The exact frequency output reported should correspond to the display refresh rate (60 Hz in this example). Simply terminate the test when satisfied.


Video_Mixer

$
0
0

Video_Mixer

$
0
0
...
root@mixer_proj:~# modetest -M xilinx_drm_mixer -w 34:bg_color:255
The background color should be a pure red and the new value of the bg_color property will be 255 (0x0000FF).
Test 6 - Change the output resolution
To change Mixer output to a new resolution, modetest must be invoked with the connector id and new resolution. In this example, we change to output 1024x768:
root@mixer_proj:~# modetest -M xilinx_drm_mixer -s 37@35:1024x768@BG24
The output should be an SMPTE color bar pattern on the screen in the new resolution specified (note: an optional refresh rate can be added to the above command when multiple options are available via the monitor's EDID).
setting mode 1024x768-75Hz@BG24 on connectors 37, crtc 35

vbltest
vbltest is a test tool which is part of the libdrm suite of test tools. It is used to ensure vertical blanking interrupts are properly sent by the DRM driver.

Video Framebuffer Read

$
0
0
...
This completes the lifecycle of a buffer descriptor. As can be seen, with four possible states, it is best to allocate at least four buffers to maintain consistent frame processing. Fewer buffers will result in gaps within the pipeline and result in frame data within a given buffer being read one or more times (depending on how few buffers are queued and the number of resulting gaps in the driver’s buffer pipeline).
Note: normally, registers programmed while the IP is running will not take effect until the next frame. The very first frame, however, is an exception: the IP is not yet running and, as such, the values take effect immediately. Nevertheless, there is no additional special treatment given the first frame buffer. As such, it will be read from, in effect, twice.
Test Approach
Testing the Framebuffer Read driver is best done when incorporated into a larger design designed for display output. It is best to reference the test procedure for the Video Mixer.
In particular, run test #6 (change output resolution).
Additionally, run modetest to change the output resolution with the -v argument which will result in page flipping on the primary plane
root@mixer_proj:~# modetest -M xilinx_drm_mixer -s 37:640x480@BG24 -v
setting mode 640x480-75Hz@BG24 on connectors 37, crtc 35
select timed out or error (ret 0)
freq: 7.20Hz
freq: 15.00Hz
freq: 15.00Hz
freq: 15.00Hz
freq: 15.00Hz
freq: 15.00Hz
The output frequency reported should be approximately 1/4 that of the current refresh rate. This is because modetest only creates a single framebuffer and the Video Framebuffer driver requires four (4) buffers for optimal operation.

Video Framebuffer Read

$
0
0
=
{under.jpg}
=
Overview
Video Framebuffer Read IP cores are designed for video applications requiring frame buffers and is designed for high-bandwidth access between the AXI4-Stream video interface and the AXI4-interface.
...
Note: normally, registers programmed while the IP is running will not take effect until the next frame. The very first frame, however, is an exception: the IP is not yet running and, as such, the values take effect immediately. Nevertheless, there is no additional special treatment given the first frame buffer. As such, it will be read from, in effect, twice.
Test Approach
...
Video Mixer.
In

In
particular, run
...
output resolution).
Additionally, run modetest to change the output resolution with the -v argument which will result in page flipping on the primary plane
root@mixer_proj:~# modetest -M xilinx_drm_mixer -s 37:640x480@BG24 -v

Video Framebuffer Read

$
0
0

{under.jpg}
{under.jpg}
Overview
Video Framebuffer Read IP cores are designed for video applications requiring frame buffers and is designed for high-bandwidth access between the AXI4-Stream video interface and the AXI4-interface.

VxWorks

$
0
0
...
Operating System (supporting Zynq)
OS Name and version/release :
...
VxWorks 7 for Zynq-7000
VxWorks 7 for Zynq UltraScale+ MPSoC

Supported configurations SMP, UP, AMP :
All
...
VxWorks 7 for Xilinx ZC702 and ZC706
VxWorks 6.9 Xilinx ZC702 and ZC706
VxWorks 7 for Xilinx ZCU102 APU
All VxWorks BSPs for Xilinx (includes legacy)
Certifications

Xilinx V4L2 VPSS CSC driver

$
0
0

{under.jpg}
{under.jpg} 2017.3 Updates
The purpose of this page is to describe the Linux V4L2 driver for Xilinx VPSS Color Space Converter (CSC) soft IP. VPSS refers to the Video Processing Sub System.
Overview
...
Technical Reference Designs
Coming Soon
Work to be doneFuture Improvements
Support to program custom coefficients into the 3x4 Matrix as supplied by the user.
Related Links

Xilinx V4L2 Gamma Correction LUT driver

$
0
0
...
Technical Reference Designs
reVision Getting Started
Work to be doneFuture Improvements
User/Application programmable coefficients to program the Red, Blue and Green Look Up Tables.
Related Links

Xilinx V4L2 VPSS Scaler driver

$
0
0
...
Technical Reference Designs
reVision Getting Started
Work to be doneFuture Improvements
Support to program custom values to the H-scaler and V-scaler coefficients entered by the user.
Related Links

Video Framebuffer Write

$
0
0
=
{under.jpg}
=
{under.jpg}
Overview
Video Framebuffer Write IP cores are designed for video applications requiring frame buffers and is designed for high-bandwidth access between the AXI4-Stream video interface and the AXI4-interface.
...
dmaengine_terminate_all(frmbuf_dma);
DMA Interleaved Template Requirements
...
planes need tonot be strictly
...
within a singler, larger contiguous frame
...
before chroma data.data within this frame buffer space. Note that
...
as follows:
linux/dmaengine.h:

From linux/dmaengine.h:

struct dma_interleaved_template:
...
to this value)value)>
src_sgl = false
dst_sgl = true
...
done
When a DMA client calls dma_commit(), the buffer descriptor is placed in the driver’s “pending” queue. Multiple buffers can be queued in this manner by the DMA client before proceeding to the next step (see step 4 of Interfacing with the Video Framebuffer Driver from DMA Clients).
...
called (step 5),5 in the client code sample above), the driver
When the currently active frame completed, the buffer descriptor is classified as “active” in the driver. At this point, a new descriptor is plucked from the pending list and this new buffer is marked as “staged” with its values programmed into the IP registers as described earlier. The buffer marked “active” represents the data currently being written to memory. Other than being held in the “active” state, no other action is taken with the buffer
When the active frame completes, it is moved to the “done” list. The driver utilizes a tasklet which is called at the end of the frame interrupt handler. The tasklet will process any buffer descriptors on the done list by removing them from the list and calling any callback the client has linked to the descriptor.
This completes the lifecycle of a buffer descriptor. As can be seen, with four possible states, it is best to allocate at least four buffers to maintain consistent frame processing. Fewer buffers will result in gaps within the pipeline and result in frame data within a given buffer being overwritten one or more times (depending on how few buffers are queued and the number of resulting gaps in the driver’s buffer pipeline).
&#42; Note:Note: normally, registers
...
effect, twice.
Test Approach
To ensure the Framebuffer Write IP Linux driver has been configured to work properly, a suitable test design will require an input source (i.e. HDMI Rx) connected to the Framebuffer.
Once properly configured, the design can be tested via the tool known as "yavta". Yavta may be found here.
To run yavta, data must be streaming into your media pipeline. To verify the status of your media pipleline, run the tool known as "media-ctl":
root@hdmi_proj:~# media-ctl -p
Media controller API version 0.1.0
Media device information
------------------------
driver xilinx-video
model Xilinx Video Composite Device
serial
bus info
hw revision 0x0
driver version 0.0.0
Device topology
- entity 1: vcap_hdmi output 0 (1 pad, 1 link)
type Node subtype V4L flags 0
device node name /dev/video0
pad0: Sink
<- "a0000000.v_hdmi_rx_ss":0 [ENABLED]
- entity 5: a0000000.v_hdmi_rx_ss (1 pad, 1 link)
type V4L2 subdev subtype Unknown flags 0
device node name /dev/v4l-subdev0
pad0: Source
[fmt:UYVY/1920x1080 field:none]
[dv.caps:BT.656/1120 min:0x0@25000000 max:4096x2160@297000000 stds:CEA-861,DMT,CVT,GTF caps:progressive,reduced-blanking,custom]
[dv.detect:BT.656/1120 1920x1080p60 (2200x1125) stds:CEA-861 flags:CE-video]
-> "vcap_hdmi output 0":0 [ENABLED]
In the above example, entity 5 represents the HDMI Rx input source which happens to be receiving RGB-based media at 1080p resolution. The Video Framebuffer driver is managed/controlled by a V4L2 "client" driver represented by entity 1. The above pipeline is suitable for capturing and writing to memory any of the supported RGB[X] 8-bit formats.
A frame capture to local binary files can now be performed using the yavta tool:

Video Framebuffer Write

$
0
0
...
[dv.detect:BT.656/1120 1920x1080p60 (2200x1125) stds:CEA-861 flags:CE-video]
-> "vcap_hdmi output 0":0 [ENABLED]
...
be receiving RGB-basedYUYV-based media at
A frame capture to local binary files can now be performed using the yavta tool:
root@hdmi_proj:~# yavta -c10 -f YUYV -s 1920x1080 --skip 7 -F /dev/video0 &
[2] 2362
Device /dev/video0 opened.
Device `vcap_hdmi output 0' on `platform:vcap_hdmi:0' is a video output (without mplanes) device.
Video format set: YUYV (56595559) 1920x1080 field n[ 1393.139514]
one, 1 planes:
* Stride 3840, buffer size 4147200
<snip>
[ 1393.747654] xhdmi_s_stream enable = 0
Captured 10 frames in 0.289203 seconds (34.577689 fps, 0.000000 B/s).
8 buffers released.
[2]- Done yavta -c10 -f YUYV -s 1920x1080 --skip 7 -F /dev/video0
root@hdmi_proj:~# ls
frame-000007.bin frame-000008.bin frame-000009.bin
The above command syntax specifies 10 frames to capture (-c10) writing to memory in packed YUYV format (-f YUYV) with 1920x1080 dimensions (-s 1920x1080) and to only write out the last 3 frames captured to a file (--skip 7). These instructions are sent to the file descriptor which represents the V4L2 driver controlling, ulimately, the Video Framebuffer (-F /dev/video0).
Lastly, we list the contents of the directory within which we execute the yavta command and we see three files named frame-* . These files can be opened in a viewer utility like yuvplayer.exe an inspected to ensure that frame capture occurred properly.

Video Framebuffer Write

$
0
0
Viewing all 11776 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>