linux-kernel - Re: [PATCH v4 10/10] drm/vs: add simple dsi encoder

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <u7zx25g7zwf56unal4qwgh65hmjydfa7d2vnbgwxnulygtcj3w@uicmayewp4r4>
Date: Tue, 25 Jun 2024 13:59:06 +0300
From: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
To: Keith Zhao <keith.zhao@...rfivetech.com>
Cc: "andrzej.hajda@...el.com" <andrzej.hajda@...el.com>, 
	"neil.armstrong@...aro.org" <neil.armstrong@...aro.org>, "rfoss@...nel.org" <rfoss@...nel.org>, 
	"Laurent.pinchart@...asonboard.com" <Laurent.pinchart@...asonboard.com>, "jonas@...boo.se" <jonas@...boo.se>, 
	"jernej.skrabec@...il.com" <jernej.skrabec@...il.com>, 
	"maarten.lankhorst@...ux.intel.com" <maarten.lankhorst@...ux.intel.com>, "mripard@...nel.org" <mripard@...nel.org>, 
	"tzimmermann@...e.de" <tzimmermann@...e.de>, "airlied@...il.com" <airlied@...il.com>, 
	"daniel@...ll.ch" <daniel@...ll.ch>, "robh@...nel.org" <robh@...nel.org>, 
	"krzk+dt@...nel.org" <krzk+dt@...nel.org>, "conor+dt@...nel.org" <conor+dt@...nel.org>, 
	"hjc@...k-chips.com" <hjc@...k-chips.com>, "heiko@...ech.de" <heiko@...ech.de>, 
	"andy.yan@...k-chips.com" <andy.yan@...k-chips.com>, Xingyu Wu <xingyu.wu@...rfivetech.com>, 
	"p.zabel@...gutronix.de" <p.zabel@...gutronix.de>, Jack Zhu <jack.zhu@...rfivetech.com>, 
	Shengyang Chen <shengyang.chen@...rfivetech.com>, 
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>, "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, 
	"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v4 10/10] drm/vs: add simple dsi encoder

On Tue, Jun 25, 2024 at 08:33:48AM GMT, Keith Zhao wrote:
> 
> 
> > -----Original Message-----
> > From: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
> > Sent: 2024年6月24日 5:11
> > To: Keith Zhao <keith.zhao@...rfivetech.com>
> > Cc: andrzej.hajda@...el.com; neil.armstrong@...aro.org; rfoss@...nel.org;
> > Laurent.pinchart@...asonboard.com; jonas@...boo.se;
> > jernej.skrabec@...il.com; maarten.lankhorst@...ux.intel.com;
> > mripard@...nel.org; tzimmermann@...e.de; airlied@...il.com;
> > daniel@...ll.ch; robh@...nel.org; krzk+dt@...nel.org; conor+dt@...nel.org;
> > hjc@...k-chips.com; heiko@...ech.de; andy.yan@...k-chips.com; Xingyu Wu
> > <xingyu.wu@...rfivetech.com>; p.zabel@...gutronix.de; Jack Zhu
> > <jack.zhu@...rfivetech.com>; Shengyang Chen
> > <shengyang.chen@...rfivetech.com>; dri-devel@...ts.freedesktop.org;
> > devicetree@...r.kernel.org; linux-kernel@...r.kernel.org;
> > linux-arm-kernel@...ts.infradead.org
> > Subject: Re: [PATCH v4 10/10] drm/vs: add simple dsi encoder
> > 
> > On Sun, Jun 23, 2024 at 07:17:09AM GMT, Keith Zhao wrote:
> > > Hi Dmitry:
> > >
> > > > On Tue, May 21, 2024 at 06:58:17PM +0800, keith wrote:
> > 
> > > > > +								  "starfive,syscon",
> > > > > +								  2, args);
> > > > > +
> > > > > +	if (IS_ERR(simple->dss_regmap)) {
> > > > > +		return dev_err_probe(dev, PTR_ERR(simple->dss_regmap),
> > > > > +				     "getting the regmap failed\n");
> > > > > +	}
> > > > > +
> > > > > +	simple->offset = args[0];
> > > > > +	simple->mask = args[1];
> > > >
> > > > Is the value that you've read platform dependent or use case dependent?
> > > > What is the actual value being written? Why are you using syscon for it?
> > >
> > > The syscon is used to select crtcs binded with encoder, If this
> > > encoder binds to crtc0 , set the syscon reg bit0 = 1 If this encoder
> > > binds to crtc1 , set the syscon reg bit1 = 1 (0x2) Maybe I can do this
> > > by the possible_crtc instead of using args from dts
> > 
> > If this is a constant between your platforms, it should not be a part of DT.
> > 
> > >
> > >
> > > >
> > > > > +
> > > > > +	return 0;
> > > > > +}
> > > > > +
> > > > > +static void vs_encoder_atomic_enable(struct drm_encoder *encoder,
> > > > > +struct drm_atomic_state *state) {
> > > > > +	struct vs_simple_encoder *simple = to_simple_encoder(encoder);
> > > > > +
> > > > > +	regmap_update_bits(simple->dss_regmap, simple->offset,
> > > > > +simple->mask,
> > > > > +simple->mask);
> > > >
> > > >
> > > > A purist in me would ask to have separate mask and value to write.
> > > Understand , will avoid this action
> > > >
> > > > > +}
> > > >
> > > > Is it necessary to clear those bits when stopping the stream?
> > > No need to do this , if clear those bits , the encoder will point to a
> > > unknown crtc
> > 
> > what are the consequences? Is it desirable or not?
> There are two crtcs.
> Each display terminal encoder can combine any crtc, depending on the value of possible crtc.
> When the bit is 0, it means that the encoder matches crtc0.
> When the bit is 1, it means that the encoder matches crtc1.
> The possible crtc of this encoder is 2 , the reg bit is 1.    
> When the video stream is stopped, if the bit is cleared, the result is that the encoder hardware points to crtc0, 
> and the encoder points to crtc1 based on the drm framework(because the possible crtc no change).

I'm not sure if I understood you correctly. If it doesn't disable or
disconnect the encoder, I'd skip that in the .disable path.

-- 
With best wishes
Dmitry