Re: ivtv: use arch_phys_wc_add() and require PAT disabled

[Ian Armstrong]

On Sun, 11 Mar 2018 23:04:02 -0500
Nick French <n...@ou.edu> wrote:

> On Sun, Mar 11, 2018 at 11:24:38PM +0000, Ian Armstrong wrote:
> > On Sat, 10 Mar 2018 16:57:41 +
> > "French, Nicholas A." <n...@ou.edu> wrote:
> >   
> > > > > No what if the framebuffer driver is just requested as a
> > > > > secondary step after firmware loading?
> > > >
> > > > Its a possibility. The decoder firmware gets loaded at the
> > > > beginning of the decoder memory range and we know its length, so
> > > > its possible to ioremap_nocache enough room for the firmware
> > > > only on init and then ioremap the remaining non-firmware
> > > > decoder memory areas appropriately after the firmware load
> > > > succeeds...
> > > 
> > > I looked in more detail, and this would be "hard" due to the way
> > > the rest of the decoder offsets are determined by either making
> > > firmware calls or scanning the decoder memory range for magic
> > > bytes and other mess.  
> > 
> > The buffers used for yuv output are fixed. They are located both
> > before and after the framebuffer. Their offset is fixed at
> > 'base_addr + IVTV_DECODER_OFFSET + yuv_offset[]'. The yuv offsets
> > can be found in 'ivtv-yuv.c'. The buffers are 622080 bytes in
> > length.
> > 
> > The range would be from 'base_addr + 0x0100 + 0x00029000' to
> > 'base_addr + 0x0100 + 0x00748200 + 0x97dff'. This is larger than
> > required, but will catch the framebuffer and should not cause any
> > problems. If you wanted to render direct to the yuv buffers, you
> > would probably want this region included anyway (not that the
> > current driver supports that).  
> 
> Am I correct that you are talking about the possibility of
> re-ioremap()-ing the 'yuv-fb-yuv' area *after* loading the firmware,
> not of mapping ranges correctly on the first go-around?
> 
> Because unless my math is letting me down, the decoder firmware is
> already loaded from 'base_addr + 0x0100 + 0x0' to 'base_addr +
> 0x0100 + 0x3' which overlaps the beginning of the yuv range.

Good catch. I'd forgotten that the firmware moves after being loaded.

Although ivtvfb.c requests the offset to the framebuffer via the
firmware, I don't believe it ever actually moves. The firmware allows
more memory to be allocated for video buffers, but will then reduce the
length of the framebuffer. At present the ivtv driver requests two more
video buffers, so the framebuffer is shortened (the start address
doesn't move). Those two buffers are located at base_addr + 0x16B0400
and 0x1748200. The now shortened framebuffer is of size 1704960 bytes
(0x1A0400).

These two offsets, plus those of the other video buffers are hardcoded
in ivtv-yuv.c. It was written on the assumption that the location of the
video buffers on the card are fixed. To the best of my knowledge, this
has never caused a problem.

>From ivtvfb.c :

/* The osd buffer size depends on the number of video buffers allocated
   on the PVR350 itself. For now we'll hardcode the smallest osd buffer
   size to prevent any overlap. */
oi->video_buffer_size = 1704960;

We know that one of the additional video buffers is at 0x16B0400, and
that this is located at the end of the now shortened 1704960 byte
framebuffer.

0x16B0400 - 0x1A0400 = 0x151.

This gives us a 0x1A0400 byte framebuffer at base_addr + 0x151.

Assuming the hardware is a PVR350 and is running stock firmware, I
thinks its safe to say this won't change.

-- 
Ian

Re: ivtv: use arch_phys_wc_add() and require PAT disabled

[Ian Armstrong]

On Sat, 10 Mar 2018 16:57:41 +
"French, Nicholas A."  wrote:

> > > No what if the framebuffer driver is just requested as a
> > > secondary step after firmware loading?  
> >
> > Its a possibility. The decoder firmware gets loaded at the
> > beginning of the decoder memory range and we know its length, so
> > its possible to ioremap_nocache enough room for the firmware only
> > on init and then ioremap the remaining non-firmware decoder memory
> > areas appropriately after the firmware load succeeds...  
> 
> I looked in more detail, and this would be "hard" due to the way the
> rest of the decoder offsets are determined by either making firmware
> calls or scanning the decoder memory range for magic bytes and other
> mess.

The buffers used for yuv output are fixed. They are located both before
and after the framebuffer. Their offset is fixed at 'base_addr +
IVTV_DECODER_OFFSET + yuv_offset[]'. The yuv offsets can be found in
'ivtv-yuv.c'. The buffers are 622080 bytes in length.

The range would be from 'base_addr + 0x0100 + 0x00029000' to
'base_addr + 0x0100 + 0x00748200 + 0x97dff'. This is larger than
required, but will catch the framebuffer and should not cause any
problems. If you wanted to render direct to the yuv buffers, you would
probably want this region included anyway (not that the current driver
supports that).

-- 
Ian

Re: Tuning file for Crystal Palace, UK (post digital switch-over)

[Ian Armstrong]

On Friday 20 April 2012, Ian Liverton wrote:

 Thanks for this - I was in the middle of trying to sort this out when it
 arrived!  When I use it with dvbscan, however, it seems to mis-detect the
 modulation on the SDN multiplex.  It's telling me it's QPSK rather than
 QAM_64.  Did you have any trouble with re-tuning?
 
  tune to:
 50600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_3_4:FEC_1_2:QPSK:TRANSMISSION_
 M ODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE
 WARNING: filter timeout pid 0x0011
 WARNING: filter timeout pid 0x
 WARNING: filter timeout pid 0x0010

I had problems with MythTV (.23-fixes) which failed to detect any channels on 
this multiplex. Had to manually add it with the correct info before doing 
another scan. Using dvbsnoop to dump the NIT also shows QPSK instead of 
QAM_64.

   DVB-DescriptorTag: 90 (0x5a)  [= terrestrial_delivery_system_descriptor]
   descriptor_length: 11 (0x0b)
   Center frequency: 0x03041840 (= 506000.000 kHz)
   Bandwidth: 0 (0x00)  [= 8 MHz]
   priority: 1 (0x01)  [= HP (high priority) or Non-hierarch.]
   Time_Slicing_indicator: 1 (0x01)  [= Time Slicing is not used.)]
   MPE-FEC_indicator: 1 (0x01)  [= MPE-FEC is not used.)]
   reserved_1: 3 (0x03)
   Constellation: 0 (0x00)  [= QPSK]
   Hierarchy information: 0 (0x00)  [= non-hierarchical (native interleaver)]
   Code_rate_HP_stream: 2 (0x02)  [= 3/4]
   Code_rate_LP_stream: 0 (0x00)  [= 1/2]
   Guard_interval: 0 (0x00)  [= 1/32]
   Transmission_mode: 1 (0x01)  [= 8k mode]
   Other_frequency_flag: 1 (0x01)
   reserved_2: 4294967295 (0x)

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

Re: RFC: Use of V4L2_FBUF_FLAG_OVERLAY

[Ian Armstrong]

On Monday 07 November 2011, Hans Verkuil wrote:
 During the recent V4L-DVB workshop we discussed the usage of the
 V4L2_FBUF_FLAG_OVERLAY flag.
 

 In the case of ivtv the behavior is as follows (from the original commit
 message):
 
 The existing yuv code limits output to the display area occupied by the
 framebuffer. This patch allows the yuv output to be 'detached' via
 V4L2_FBUF_FLAG_OVERLAY.
 
 By default, the yuv output window will be restricted to the framebuffer
 dimensions and the output position is relative to the top left corner
 of the framebuffer. This matches the behaviour of previous versions.
 
 If V4L2_FBUF_FLAG_OVERLAY is cleared, the yuv output will no longer be
 linked to the framebuffer. The maximum dimensions are either 720x576 or
 720x480 depending on the current broadcast standard, with the output
 position relative to the top left corner of the display. The framebuffer
 itself can be resized, moved and panned without affecting the yuv 
 output.
 
 So, the definition for FLAG_OVERLAY for output overlays would be:
 
 'If FLAG_OVERLAY is set, then the video output overlay window is relative
 to the top-left corner of the framebuffer and restricted to the size of
 the framebuffer. If it is cleared, then the video output overlay window is
 relative to the video output display.'
 
 Ian, does this make sense?
 
Makes sense to me, but I understand how the hardware  driver works.

With the PVR350 there is no hardware restriction that limits yuv output to the 
framebuffer area. They are effectively two separate overlays that are shown on 
the video output display. The framebuffer does not have to occupy the entire 
display area, but can be reduced to cover just a small part. There are times 
when it may be beneficial to reduce the framebuffer size (faster redraws) 
without reducing yuv output (require full-screen video). Likewise, larger 
virtual resolution framebuffers also have their uses.

V4L2_FBUF_FLAG_OVERLAY was the closest thing to an existing flag that could 
toggle the mode of operation. With it set, things like XVideo work as 
expected, with the yuv window positioned correctly within the framebuffer 
area. When V4L2_FBUF_FLAG_OVERLAY is cleared, the framebuffer  yuv output 
detach to become two separate 'windows' on the display.

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

Re: VIDIOC_G_STD, VIDIOC_S_STD, VIDIO_C_ENUMSTD for outputs

[Ian Armstrong]

On Sunday 23 May 2010, Hans Verkuil wrote:
 On Saturday 22 May 2010 19:21:32 Ian Armstrong wrote:
  On Saturday 22 May 2010, Andy Walls wrote:

   Some thoughts:
   
   1. to me it appears that the ivtv driver looks like it ties the output
   standard to the input standard currently (probably due to some firmware
   limitation).  This need not be the case in general.
  
  The ivtv limitation is the driver and not the firmware.
 
 Correct.
 
  The firmware itself
  seems quite happy with mixed standards  in some cases will automatically
  switch the output standard itself (resulting in a standards mismatch
  between the cx23415  saa7127, breaking output). For the previous 2
  months I've been running a patched version of the ivtv driver that
  separates the input  output format with no noticeable issues.
  
   2. currently the ivtv driver uses sepearte device nodes for input
   device and an output device.  If bridge drivers maintain that
   paradigm, then separate ioctl()s for S_STD, G_STD, and ENUMSTD are
   likely not needed.
  
  This is how my patched version works, talk to an input device for the
  input  an output device for the output. However, from my reading of the
  specs I do get the impression this is not the 'correct' way to do this
  and it should really be a separate ioctl. I don't know what other cards,
  if any, support mixed input  output standards or how they handle it.
 
 I have considered implementing these output ioctls as well and as mentioned
 s_std_output is actually implemented on the subdev level (it was really
 needed there).
 
 The reason it was never done for bridge drivers is twofold:
 
 1) No one ever needed it. Why would you want to select one format for input
 and another for output? Other than debugging this never happens for the
 sort of drivers we have now. So selecting e.g. PAL and have it change both
 input and output is actually what most people expect.

There's no denying that mixed standards is unusual, but is it a case of nobody 
ever wanted it, or did they just assume the hardware wasn't capable of it. The 
only reason I ever created a patch to support mixed standards in the ivtv 
driver is because it was a feature which I wanted to use.

In my case all captures are PAL, but I view a lot of NTSC material. I find 
that interlaced video looks best when displayed in its native format so I use 
a script to identify  change the output to match. Mixed standards allow 
MythTV to record a show in PAL while I'm watching an NTSC video on an NTSC  
output.

Another instance when mixed formats would be useful is when capturing a video 
which doesn't match your regions standard. If I'm trying to capture an NTSC 
video, it doesn't mean I want the output mode changed from my native PAL. Just 
because the card can output NTSC doesn't mean the display can handle it.

 2) Do we really need to make new ioctls? Here it becomes hairy. According
 to the V4L2 spec changing the std for one video device should change it
 for all others as well. So if we follow that spec, then we should indeed
 introduce new ioctls. But in practice all driver have separate device
 nodes for capture and output. So perhaps we should change the spec and
 specify that it will only change the std for those device nodes that are
 linked to the same input or output.

I doubt it's really used outside of v4l2-ctl, but the ivtv driver allows 
output configuration to be changed via the capture device. In this instance a 
new ioctl would avoid a situation where the output can only be partially 
configured through the capture device. In reality I doubt any application 
actually configures the output via the capture device, but to reuse the ioctl 
 link it to a specific device node would create an inconsistency.

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

Re: VIDIOC_G_STD, VIDIOC_S_STD, VIDIO_C_ENUMSTD for outputs

[Ian Armstrong]

On Saturday 22 May 2010, Andy Walls wrote:
 On Sat, 2010-05-22 at 15:06 +0100, Andre Draszik wrote:
  Hi,
  
  As per the spec, the above ioctl codes are defined for inputs only -
  it would be useful if there were similar codes for outputs.
  
  I therefore propose to add the following:
  
  VIDIOC_G_OUTPUT_STD
  VIDIOC_S_OUTPUT_STD
  VIDIOC_ENUM_OUTPUT_STD
  
  which would behave similar to the above, but for output devices.
  
  Thoughts?
 
 Currently the ivtv driver, for the PVR-350's output, uses VIDIOC_S_STD.
 
 From what I see:
 ivtv/ioctl.c
 zoran/zoran_driver.c
 davinci/vpif_display.c
 
 all use VIDIOC_S_STD for setting the output standard.
 
 Note that the v4l2_subdev video_ops have a s_std_output method which
 is what you can grep for in the code to verify for yourself.
 
 
 Some thoughts:
 
 1. to me it appears that the ivtv driver looks like it ties the output
 standard to the input standard currently (probably due to some firmware
 limitation).  This need not be the case in general.

The ivtv limitation is the driver and not the firmware. The firmware itself 
seems quite happy with mixed standards  in some cases will automatically 
switch the output standard itself (resulting in a standards mismatch between 
the cx23415  saa7127, breaking output). For the previous 2 months I've been 
running a patched version of the ivtv driver that separates the input  output 
format with no noticeable issues.

 2. currently the ivtv driver uses sepearte device nodes for input device
 and an output device.  If bridge drivers maintain that paradigm, then
 separate ioctl()s for S_STD, G_STD, and ENUMSTD are likely not needed.

This is how my patched version works, talk to an input device for the input  
an output device for the output. However, from my reading of the specs I do 
get the impression this is not the 'correct' way to do this and it should 
really be a separate ioctl. I don't know what other cards, if any, support 
mixed input  output standards or how they handle it.

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

Re: V4L/DVB ivtv-yuv.c: args-dst.left assigned to both nf-tru_x and nf-dst_x in ivtv_yuv_setup_frame()

[Ian Armstrong]

On Friday 15 January 2010, Roel Kluin wrote:
 vi drivers/media/video/ivtv/ivtv-yuv.c +971
 
 and note that `args-dst.left' is assigned both to
 nf-tru_x and nf-dst_x, is that ok?

It's fine. dst_x is used to set a hardware register and may be changed in 
ivtv_yuv_window_setup()

tru_x is never altered  is used in a special condition where the original 
unaltered value is required.

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