- Home
- :
- i.MX Forums
- :
- i.MX Processors
- :
- PXP PS Scaling

Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.

Showing results forย

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page

PXP PS Scaling

โ06-11-2019
06:05 PM

176 Views

steveschefterti

Contributor III

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

Can someone clarify the setting of the PS Scale Factor Register (PXP_PS_SCALE) in the Pixel Pipeline?

The description in the iMX6 RMs is a tad confusing/incomplete.

The manual says that each X/Y scale is "two bit integer and 12 bit fractional representation" (total 14 bits) but shows the scales occupying 15 bits each (plus a single reserved bit to make up one 16 bit half-word). Am I correct to assume they are really 14 bits each (bits 29-16, 13-0) plus two reserved bits?

Next, the manual says "The reciprocal of the scale factor should be loaded into this register", but it is not clear how to make a "reciprocal" out of the above bit fields.

The following up scaling examples are provided:

00.0100_0000_0000 scale up by 4

00.0010_0000_0000 scale up by 2

00.1010_0000_0000 scale up by 8/5

Especially with the last one I don't see where they are getting the register settings.

The 2x and 4x examples might make sense to me, except that I wonder why the most significant nibble is being set. And how, in that case, would you represent a scaling factor of 0x20 for example?

Thanks,

Steve

4 Replies

โ06-25-2019
01:32 PM

63 Views

Bio_TICFSL

NXP TechSupport

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

Hello Steve,

I find no reference to a PXP register PS_SCALE in any MX6 documentation.

Is this issue really about the MX6? If not, what device is being used?

Regards

โ06-25-2019
01:45 PM

63 Views

steveschefterti

Contributor III

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

The PXP, including the PXP_PS_SCALE register, is part of the iMX6UL,

iMX6ULL, iMX6Solo/DualLite. It's not found in the iMX6D/Q which have an

IPU instead.

โ06-27-2019
07:54 AM

63 Views

Bio_TICFSL

NXP TechSupport

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

The manual says that each X/Y scale is "two bit integer and 12 bit fractional representation" (total 14 bits) but shows the scales occupying 15 bits each (plus a single reserved bit to make up one 16 bit half-word). Am I correct to assume they are really 14 bits each (bits 29-16, 13-0) plus two reserved bits?

>>> Bits 30 and 14 are not usable per the note in the RM that states that "The maximum value programmed should be 2 since scaling down by a factor greater than 2 is not supported with the bilinear filter".

Next, the manual says "The reciprocal of the scale factor should be loaded into this register", but it is not clear how to make a "reciprocal" out of the above bit fields.

>>> The value to be programmed is 1/desired_scale_factor. The radix point is between bits 28-27 and 12-11 for each register. The two bits to the left of the radix point are the "integer" (valid values are 0 through 2) and the bits to the right are the fractional part. The examples given in the RM match the algorithm here for converting a binary fraction to decimal.

00.0100_0000_0000 scale up by 4 => scale = reciprocal of ( 1/2^2 ) = 1/ (1/4) = 4

00.0010_0000_0000 scale up by 2 => bit field here is incorrect, should be 00.1000_0000_0000, which is 1/2, reciprocal is 2

00.1010_0000_0000 scale up by 8/5 => scale = reciprocal of ( 1/2 + 1/8 ) = 1 / (0.5 + 0.125) = 8

Regards

โ06-27-2019
12:34 PM

63 Views

steveschefterti

Contributor III

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

Good to have a further indication that it is just the figure showing the register bits is incorrect in the RM.

Thanks a lot for the link to the algorithm. That's just what I was looking for.

Steve