On Vi, 2019-07-12 at 11:21 +0200, paul.kocialkowski@xxxxxxxxxxx wrote: > Hi, > > On Thu 11 Jul 19, 13:57, Mirela Rabulea wrote: > > > > On Jo, 2019-07-11 at 10:18 +0200, Paul Kocialkowski wrote: > > > > > > Caution: EXT Email > > > > > > Hi, > > > > > > On Wed 03 Jul 19, 18:15, Mirela Rabulea wrote: > > > > > > > > > > > > The added format is V4L2_PIX_FMT_YUV24, this is a packed > > > > YUV 4:4:4 format, with 8 bits for each component, 24 bits > > > > per sample. > > > > > > > > This format is used by the i.MX 8QuadMax and i.MX > > > > 8DualXPlus/8QuadXPlus > > > > JPEG encoder/decoder. > > > So this format is not aligned to 32-bit words at all and we can > > > expect > > > to see cases where a single 32-bit word contains data for two > > > pixels? > > > > > > Nothing wrong with that, just checking whether I understood this > > > right :) > > > > > Hi Paul, > > yes, your understanding is correct. > Out of curiosity, is the JPEG block assmiliated to (one of) the > Hantro VPUs > or is it a totally different and unrelated hardware block? > > Anyway the change looks good to me: > Reviewed-by: Paul Kocialkowski <paul.kocialkowski@xxxxxxxxxxx> > > Cheers, > > Paul Hi Paul, thanks for taking the time to review. The JPEG decoder is a standalone core & wrapper, not assimilated to the VPU. It is described in the reference manual here: https://www.nxp.com/docs/en/reference-manual/IMX8DQXPRM.pdf in chapters "15.6.3 JPEG Decoder (JPEGDEC)" and "15.6.5 JPEG Decoder Wrapper". The JPEG core is from a third party, and the wrapper from NXP. Regards, Mirela
