lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20221021151423.6lube6aqtqahwpwf@notapiano>
Date:   Fri, 21 Oct 2022 11:14:23 -0400
From:   Nícolas F. R. A. Prado 
        <nfraprado@...labora.com>
To:     "xinlei.lee" <xinlei.lee@...iatek.com>
Cc:     matthias.bgg@...il.com, rex-bc.chen@...iatek.com,
        angelogioacchino.delregno@...labora.com, jason-jh.lin@...iatek.com,
        chunkuang.hu@...nel.org, p.zabel@...gutronix.de, airlied@...ux.ie,
        daniel@...ll.ch, dri-devel@...ts.freedesktop.org,
        linux-mediatek@...ts.infradead.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        Project_Global_Chrome_Upstream_Group@...iatek.com
Subject: Re: [PATCH v12,1/3] soc: mediatek: Add all settings to
 mtk_mmsys_ddp_dpi_fmt_config func

On Fri, Oct 21, 2022 at 07:59:02PM +0800, xinlei.lee wrote:
> On Thu, 2022-10-20 at 12:33 -0400, Nícolas F. R. A. Prado wrote:
> > Hi,
> > 
> > On Wed, Oct 19, 2022 at 10:52:14AM +0800, xinlei.lee@...iatek.com
> > wrote:
> > > From: Xinlei Lee <xinlei.lee@...iatek.com>
> > > 
> > > The difference between MT8186 and other ICs is that when modifying
> > > the
> > > output format, we need to modify the mmsys_base+0x400 register to
> > > take
> > > effect.
> > > So when setting the dpi output format, we need to call mmsys_func
> > > to set
> > 
> > mmsys_func isn't something that exists in the code. Instead mention
> > the actual
> > function name: mtk_mmsys_ddp_dpi_fmt_config.
> > 
> > > it to MT8186 synchronously.
> > 
> > 
> > Here, before saying that the commit adds all the settings for dpi,
> > you could
> > have mentioned that the previous commit lacked those, to make it
> > clearer:
> > 
> > Commit a071e52f75d1 ("soc: mediatek: Add mmsys func to adapt to dpi
> > output for MT8186")
> > lacked some of the possible output formats and also had a wrong
> > bitmask.
> > 
> > 
> > > Adding mmsys all the settings that need to be modified with dpi are
> > > for
> > > mt8186.
> > 
> > This sentence I would change to the following one:
> > 
> > Add the missing output formats and fix the bitmask.
> > 
> > 
> > Finally, you're also making the function more HW-agnostic (although
> > in my
> > opinion this could've been a future separate commit), so it's worth
> > mentioning
> > it here:
> > 
> > While at it, also update mtk_mmsys_ddp_dpi_fmt_config() to use
> > generic formats,
> > so that it is slightly easier to extend for other platforms.
> > 
> > > 
> > > Fixes: a071e52f75d1 ("soc: mediatek: Add mmsys func to adapt to dpi
> > > output for MT8186")
> > 
> > The fixes tag should be kept in a single line, without wrapping.
> > 
> > > 
> > > Signed-off-by: Xinlei Lee <xinlei.lee@...iatek.com>
> > > Reviewed-by: AngeloGioacchino Del Regno <
> > > angelogioacchino.delregno@...labora.com>
> > > Reviewed-by: CK Hu <ck.hu@...iatek.com>
> > > ---
> > >  drivers/soc/mediatek/mt8186-mmsys.h    |  8 +++++---
> > >  drivers/soc/mediatek/mtk-mmsys.c       | 27 ++++++++++++++++++++
> > > ------
> > >  include/linux/soc/mediatek/mtk-mmsys.h |  7 +++++++
> > >  3 files changed, 33 insertions(+), 9 deletions(-)
> > > 
> > > diff --git a/drivers/soc/mediatek/mt8186-mmsys.h
> > > b/drivers/soc/mediatek/mt8186-mmsys.h
> > > index 09b1ccbc0093..035aec1eb616 100644
> > > --- a/drivers/soc/mediatek/mt8186-mmsys.h
> > > +++ b/drivers/soc/mediatek/mt8186-mmsys.h
> > > @@ -5,9 +5,11 @@
> > >  
> > >  /* Values for DPI configuration in MMSYS address space */
> > >  #define MT8186_MMSYS_DPI_OUTPUT_FORMAT		0x400
> > > -#define DPI_FORMAT_MASK					0x1
> > > -#define DPI_RGB888_DDR_CON				BIT(0)
> > > -#define DPI_RGB565_SDR_CON				BIT(1)
> > > +#define DPI_FORMAT_MASK					GENMASK
> > > (1, 0)
> > > +#define DPI_RGB888_SDR_CON				0
> > > +#define DPI_RGB888_DDR_CON				1
> > > +#define DPI_RGB565_SDR_CON				2
> > > +#define DPI_RGB565_DDR_CON				3
> > 
> > These defines should all have a MT8186_ prefix. This will avoid
> > confusions now
> > that mtk_mmsys_ddp_dpi_fmt_config() is being made more platform-
> > agnostic.
> > 
> > >  
> > >  #define MT8186_MMSYS_OVL_CON			0xF04
> > >  #define MT8186_MMSYS_OVL0_CON_MASK			0x3
> > > diff --git a/drivers/soc/mediatek/mtk-mmsys.c
> > > b/drivers/soc/mediatek/mtk-mmsys.c
> > > index d2c7a87aab87..205f6de45851 100644
> > > --- a/drivers/soc/mediatek/mtk-mmsys.c
> > > +++ b/drivers/soc/mediatek/mtk-mmsys.c
> > > @@ -238,12 +238,27 @@ static void mtk_mmsys_update_bits(struct
> > > mtk_mmsys *mmsys, u32 offset, u32 mask,
> > >  
> > >  void mtk_mmsys_ddp_dpi_fmt_config(struct device *dev, u32 val)
> > >  {
> > > -	if (val)
> > > -		mtk_mmsys_update_bits(dev_get_drvdata(dev),
> > > MT8186_MMSYS_DPI_OUTPUT_FORMAT,
> > > -				      DPI_RGB888_DDR_CON,
> > > DPI_FORMAT_MASK);
> > > -	else
> > > -		mtk_mmsys_update_bits(dev_get_drvdata(dev),
> > > MT8186_MMSYS_DPI_OUTPUT_FORMAT,
> > > -				      DPI_RGB565_SDR_CON,
> > > DPI_FORMAT_MASK);
> > > +	struct mtk_mmsys *mmsys = dev_get_drvdata(dev);
> > > +
> > > +	switch (val) {
> > > +	case MTK_DPI_RGB888_SDR_CON:
> > > +		mtk_mmsys_update_bits(mmsys,
> > > MT8186_MMSYS_DPI_OUTPUT_FORMAT,
> > > +				      DPI_FORMAT_MASK,
> > > DPI_RGB888_SDR_CON);
> > > +		break;
> > > +	case MTK_DPI_RGB565_SDR_CON:
> > > +		mtk_mmsys_update_bits(mmsys,
> > > MT8186_MMSYS_DPI_OUTPUT_FORMAT,
> > > +				      DPI_FORMAT_MASK,
> > > DPI_RGB565_SDR_CON);
> > > +		break;
> > > +	case MTK_DPI_RGB565_DDR_CON:
> > > +		mtk_mmsys_update_bits(mmsys,
> > > MT8186_MMSYS_DPI_OUTPUT_FORMAT,
> > > +				      DPI_FORMAT_MASK,
> > > DPI_RGB565_DDR_CON);
> > > +		break;
> > > +	case MTK_DPI_RGB888_DDR_CON:
> > > +	default:
> > > +		mtk_mmsys_update_bits(mmsys,
> > > MT8186_MMSYS_DPI_OUTPUT_FORMAT,
> > > +				      DPI_FORMAT_MASK,
> > > DPI_RGB888_DDR_CON);
> > > +		break;
> > > +	}
> > 
> > To be honest I don't really see the point of making the function
> > slightly more
> > platform-agnostic like this. With a single platform making use of it
> > it's just
> > an unneeded extra abstraction, and it could easily be done when a
> > second
> > platform starts requiring this as well...
> > 
> > In any case,
> > 
> > Reviewed-by: Nícolas F. R. A. Prado <nfraprado@...labora.com>
> > 
> > Thanks,
> > Nícolas
> > 
> > >  }
> > 
> > [..]
> 
> Hi Nícolas:
> 
> Thanks for your detailed reply and correction.
> Before sending out the next edition, I have two questions I would like 
> to confirm with you in response to your responses:
> 1.While at it, also update mtk_mmsys_ddp_dpi_fmt_config() to use 
> generic formats, so that it is slightly easier to extend for other 
> platforms.
> => This is to make this mtk_mmsys_ddp_dpi_fmt_config() func more 
> general? 
> This function may only be used by MT8186, because only MT8186
> has 
> corresponding modifications on HW, and enables the registers reserved 
> in mmsys for dpi use to control the output format. Because this 
> register is not defined for other ic, I added control to this function 
> call in mtk_dpi.c. If you think there are other ways to make it look 
> more generic, where should I correct it?

You already made the mtk_mmsys_ddp_dpi_fmt_config() more generic by making it's
format parameter decoupled from its register representation on MT8186, that is,
MTK_DPI_RGB888_SDR_CON instead of DPI_RGB888_SDR_CON.

I wasn't asking for any code modification on that comment, I was suggesting you
add this sentence in the commit message, so it reflects the changes you're
already doing.

To be extra clear, I was suggesting you update the commit message to the
following:

  The difference between MT8186 and other ICs is that when modifying the output
  format, we need to modify the mmsys_base+0x400 register to take effect. So when
  setting the dpi output format, we need to call mtk_mmsys_ddp_dpi_fmt_config to
  set it to MT8186 synchronously.
  
  Commit a071e52f75d1 ("soc: mediatek: Add mmsys func to adapt to dpi output for
  MT8186") lacked some of the possible output formats and also had a wrong
  bitmask.
  
  Add the missing output formats and fix the bitmask.
  
  While at it, also update mtk_mmsys_ddp_dpi_fmt_config() to use generic formats,
  so that it is slightly easier to extend for other platforms.
  
  Fixes: a071e52f75d1 ("soc: mediatek: Add mmsys func to adapt to dpi output for MT8186")

> 
> 2. These definitions should all have a MT8186_ prefix. This will avoid 
> confusion as mtk_mmsys_ddp_dpi_fmt_config() becomes more platform 
> independent.
> 
> Honestly, I don't really see the point of making the feature platform-
> agnostic like this. Using it on a single platform is just an extra 
> abstraction that isn't needed, when a second platform starts needing 
> it too, it can be done easily...
> 
> => My understanding here is that prefixing variables with labels is 
> more conducive to making functions generic, and can be reused if there 
> is such a situation in the future. I understand the importance of 
> keeping the function platform agnostic, but as mentioned, it may only 
> be used by the MT8186 if there are special cases where other ICs may 
> rely on mtk_mmsys_update_bits to create new functions.

What I'm saying is that, even though you've made the function receive a generic
format as a parameter, like MTK_DPI_RGB888_SDR_CON, at this point in time
MT8186 is the only SoC that has a register in mmsys for it, so the values

DPI_FORMAT_MASK
DPI_RGB888_SDR_CON
DPI_RGB888_DDR_CON
DPI_RGB565_SDR_CON
DPI_RGB565_DDR_CON

are really all MT8186-specific, at least at this point. Leaving them without the
MT8186_ can give the false impression that they're already used elsewhere. Also
it's really easy to mistake them for the generic ones (like
MTK_DPI_RGB888_SDR_CON). MT8186_MMSYS_DPI_OUTPUT_FORMAT already has the MT8186_
prefix, so I'm really just saying that the other ones should have as well.

If/when the same address, mask or values for this register start being used on a
different SoC, then you can remove the prefix and move it to the mtk-mmsys.h
generic header.

But for now adding the prefixes will avoid confusion and make it clear this is
MT8186 specific.

Thanks,
Nícolas

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ