Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH v3 05/10] media: i2c: imx290: Add configurable link frequency and pixel rate
From: Sakari Ailus @ 2020-05-26  9:58 UTC (permalink / raw)
  To: Andrey Konovalov
  Cc: devicetree, c.barrett, linux-kernel, a.brela, peter.griffin,
	manivannan.sadhasivam, mchehab, linux-arm-kernel, linux-media
In-Reply-To: <91992bdb-deb1-0355-e61f-78c38a68f6d1@linaro.org>

Hi Andrey,

On Tue, May 26, 2020 at 12:27:17PM +0300, Andrey Konovalov wrote:
> Hi Sakari,
> 
> Thank you for the review!

You're welcome!

> 
> On 26.05.2020 12:12, Sakari Ailus wrote:
> > Hi Andrey,
> > 
> > On Sun, May 24, 2020 at 10:25:00PM +0300, Andrey Konovalov wrote:
> > > From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> > > 
> > > IMX290 operates with multiple link frequency and pixel rate combinations.
> > > The initial driver used a single setting for both but since we now have
> > > the lane count support in place, let's add configurable link frequency
> > > and pixel rate.
> > > 
> > > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> > > Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org>
> > > ---
> > >   drivers/media/i2c/imx290.c | 100 ++++++++++++++++++++++++-------------
> > >   1 file changed, 66 insertions(+), 34 deletions(-)
> > > 
> > > diff --git a/drivers/media/i2c/imx290.c b/drivers/media/i2c/imx290.c
> > > index a361c9ac8bd5..e800557cf423 100644
> > > --- a/drivers/media/i2c/imx290.c
> > > +++ b/drivers/media/i2c/imx290.c
> > > @@ -38,8 +38,6 @@
> > >   #define IMX290_HMAX_2_720 0x19C8
> > >   #define IMX290_HMAX_4_720 0x0CE4
> > > -#define IMX290_DEFAULT_LINK_FREQ 445500000
> > > -
> > >   static const char * const imx290_supply_name[] = {
> > >   	"vdda",
> > >   	"vddd",
> > > @@ -56,8 +54,6 @@ struct imx290_regval {
> > >   struct imx290_mode {
> > >   	u32 width;
> > >   	u32 height;
> > > -	u32 pixel_rate;
> > > -	u32 link_freq_index;
> > >   	const struct imx290_regval *data;
> > >   	u32 data_size;
> > > @@ -248,8 +244,13 @@ static const struct imx290_regval imx290_10bit_settings[] = {
> > >   };
> > >   /* supported link frequencies */
> > > -static const s64 imx290_link_freq[] = {
> > > -	IMX290_DEFAULT_LINK_FREQ,
> > > +static const s64 imx290_link_freq_2lanes[] = {
> > > +	891000000, /* 1920x1080 -  2 lane */
> > > +	594000000, /* 1280x720  -  2 lane */
> > > +};
> > > +static const s64 imx290_link_freq_4lanes[] = {
> > > +	445500000, /* 1920x1080 -  4 lane */
> > > +	297000000, /* 1280x720  -  4 lane */
> > >   };
> > >   /* Mode configs */
> > > @@ -259,16 +260,12 @@ static const struct imx290_mode imx290_modes[] = {
> > >   		.height = 1080,
> > >   		.data = imx290_1080p_settings,
> > >   		.data_size = ARRAY_SIZE(imx290_1080p_settings),
> > > -		.pixel_rate = 178200000,
> > > -		.link_freq_index = 0,
> > >   	},
> > >   	{
> > >   		.width = 1280,
> > >   		.height = 720,
> > >   		.data = imx290_720p_settings,
> > >   		.data_size = ARRAY_SIZE(imx290_720p_settings),
> > > -		.pixel_rate = 178200000,
> > > -		.link_freq_index = 0,
> > >   	},
> > >   };
> > > @@ -442,6 +439,32 @@ static int imx290_get_fmt(struct v4l2_subdev *sd,
> > >   	return 0;
> > >   }
> > > +static u8 imx290_get_link_freq_index(struct imx290 *imx290)
> > > +{
> > > +	const struct imx290_mode *cur_mode = imx290->current_mode;
> > > +
> > > +	return (cur_mode->width == 1920) ? 0 : 1;
> > 
> > Could you use (imx290->current_mode - imx290_modes) / sizeof(*imx290_modes)
> > or something like that? It'd have fewer chances of breaking if new modes
> > are added.
> > 
> > > +}
> > > +
> > > +static s64 imx290_get_link_freq(struct imx290 *imx290)
> > > +{
> > > +	u8 index = imx290_get_link_freq_index(imx290);
> > > +
> > > +	if (imx290->nlanes == 4)
> > > +		return imx290_link_freq_4lanes[index];
> > > +	else
> > > +		return imx290_link_freq_2lanes[index];
> > 
> > Or even better: store the link frequencies to the modes themselves. They
> > are a property of the modes after all.
> 
> Then we will get two sets (for 2 lanes and for 4 lanes) of two modes (1080p and 720p), right?

Correct.

> 
> > > +}
> > > +
> > > +static u64 imx290_calc_pixel_rate(struct imx290 *imx290)
> > > +{
> > > +	s64 link_freq = imx290_get_link_freq(imx290);
> > > +	u8 nlanes = imx290->nlanes;
> > > +
> > > +	/* pixel rate = link_freq * 2 * nr_of_lanes / bits_per_sample */
> > > +	return (link_freq * 2 * nlanes / 10);
> > > +}
> > > +
> > >   static int imx290_set_fmt(struct v4l2_subdev *sd,
> > >   			  struct v4l2_subdev_pad_config *cfg,
> > >   		      struct v4l2_subdev_format *fmt)
> > > @@ -475,10 +498,14 @@ static int imx290_set_fmt(struct v4l2_subdev *sd,
> > >   		format = v4l2_subdev_get_try_format(sd, cfg, fmt->pad);
> > >   	} else {
> > >   		format = &imx290->current_format;
> > > -		__v4l2_ctrl_s_ctrl(imx290->link_freq, mode->link_freq_index);
> > > -		__v4l2_ctrl_s_ctrl_int64(imx290->pixel_rate, mode->pixel_rate);
> > > -
> > >   		imx290->current_mode = mode;
> > > +
> > > +		if (imx290->link_freq)
> > > +			__v4l2_ctrl_s_ctrl(imx290->link_freq,
> > > +					   imx290_get_link_freq_index(imx290));
> > > +		if (imx290->pixel_rate)
> > > +			__v4l2_ctrl_s_ctrl_int64(imx290->pixel_rate,
> > > +						 imx290_calc_pixel_rate(imx290));
> > >   	}
> > >   	*format = fmt->format;
> > > @@ -502,12 +529,11 @@ static int imx290_entity_init_cfg(struct v4l2_subdev *subdev,
> > >   	return 0;
> > >   }
> > > -static int imx290_write_current_format(struct imx290 *imx290,
> > > -				       struct v4l2_mbus_framefmt *format)
> > > +static int imx290_write_current_format(struct imx290 *imx290)
> > >   {
> > >   	int ret;
> > > -	switch (format->code) {
> > > +	switch (imx290->current_format.code) {
> > >   	case MEDIA_BUS_FMT_SRGGB10_1X10:
> > >   		ret = imx290_set_register_array(imx290, imx290_10bit_settings,
> > >   						ARRAY_SIZE(
> > > @@ -558,8 +584,8 @@ static int imx290_start_streaming(struct imx290 *imx290)
> > >   		return ret;
> > >   	}
> > > -	/* Set current frame format */
> > > -	ret = imx290_write_current_format(imx290, &imx290->current_format);
> > > +	/* Apply the register values related to current frame format */
> > > +	ret = imx290_write_current_format(imx290);
> > >   	if (ret < 0) {
> > >   		dev_err(imx290->dev, "Could not set frame format\n");
> > >   		return ret;
> > > @@ -821,12 +847,6 @@ static int imx290_probe(struct i2c_client *client)
> > >   		goto free_err;
> > >   	}
> > > -	if (imx290->ep.link_frequencies[0] != IMX290_DEFAULT_LINK_FREQ) {
> > 
> > This check needs to be modified to correspond to the driver's new
> > capabilities, not removed.
> 
> Agreed.
> Do I understand correct that as the driver uses two link frequencies
> for a given number of lanes now, it must check that *the both* frequencies
> (for the given number of lanes) are listed in the device tree node?

Yes. The smiapp driver does this, for example.

-- 
Sakari Ailus

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH v3 1/6] arm64: Detect the ARMv8.4 TTL feature
From: Marc Zyngier @ 2020-05-26 10:06 UTC (permalink / raw)
  To: Zhenyu Ye
  Cc: mark.rutland, peterz, catalin.marinas, linux-mm, guohanjun, will,
	linux-arch, yuzhao, aneesh.kumar, suzuki.poulose, steven.price,
	arm, Dave.Martin, arnd, Anshuman Khandual, npiggin, zhangshaokun,
	broonie, rostedt, prime.zeng, kuhn.chenqun, tglx,
	linux-arm-kernel, xiexiangyou, linux-kernel, akpm
In-Reply-To: <050b7ee6-c7aa-5d61-4dff-4792a411464e@huawei.com>

On 2020-05-26 07:40, Zhenyu Ye wrote:
> Hi Anshuman,
> 
> On 2020/5/26 10:39, Anshuman Khandual wrote:
>> This patch (https://patchwork.kernel.org/patch/11557359/) is adding 
>> some
>> more ID_AA64MMFR2 features including the TTL. I am going to respin 
>> parts
>> of the V4 series patches along with the above mentioned patch. So 
>> please
>> rebase this series accordingly, probably on latest next.

No. Please.

>> 
> 
> I noticed that some patches of your series have been merged into arm64
> tree (for-next/cpufeature), such as TLB range, but this one not. Why?
> 
> BTW, this patch is provided by Marc in his NV series [1], maybe you
> should also let him know.
> 
> I will rebase my series after your patch is merged.

Please don't rebase on -next. That's the worse thing to do. Always base
your series on a well known -rc, and stick to that. Maintainers can
always do the rebase and resolve conflicts.

Thanks,

         M.
-- 
Jazz is not dead. It just smells funny...

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [RFC PATCH v12 03/11] psci: export smccc conduit get helper.
From: Sudeep Holla @ 2020-05-26 10:10 UTC (permalink / raw)
  To: Jianyong Wu
  Cc: Mark Rutland, kvm@vger.kernel.org, will@kernel.org,
	kvmarm@lists.cs.columbia.edu, Justin He, Wei Chen, maz@kernel.org,
	Steven Price, Kaly Xin, Suzuki Poulose, richardcochran@gmail.com,
	yangbo.lu@nxp.com, john.stultz@linaro.org, tglx@linutronix.de, nd,
	linux-arm-kernel@lists.infradead.org, Steve Capper,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	sean.j.christopherson@intel.com, Sudeep Holla,
	pbonzini@redhat.com
In-Reply-To: <HE1PR0802MB255537CD21C5E7F7F4A899A2F4B30@HE1PR0802MB2555.eurprd08.prod.outlook.com>

On Mon, May 25, 2020 at 01:37:56AM +0000, Jianyong Wu wrote:
> Hi Sudeep,
> 
> > -----Original Message-----
> > From: Sudeep Holla <sudeep.holla@arm.com>
> > Sent: Friday, May 22, 2020 9:12 PM
> > To: Jianyong Wu <Jianyong.Wu@arm.com>
> > Cc: netdev@vger.kernel.org; yangbo.lu@nxp.com; john.stultz@linaro.org;
> > tglx@linutronix.de; pbonzini@redhat.com; sean.j.christopherson@intel.com;
> > maz@kernel.org; richardcochran@gmail.com; Mark Rutland
> > <Mark.Rutland@arm.com>; will@kernel.org; Suzuki Poulose
> > <Suzuki.Poulose@arm.com>; Steven Price <Steven.Price@arm.com>; Justin
> > He <Justin.He@arm.com>; Wei Chen <Wei.Chen@arm.com>;
> > kvm@vger.kernel.org; Steve Capper <Steve.Capper@arm.com>; linux-
> > kernel@vger.kernel.org; Kaly Xin <Kaly.Xin@arm.com>; nd <nd@arm.com>;
> > Sudeep Holla <Sudeep.Holla@arm.com>; kvmarm@lists.cs.columbia.edu;
> > linux-arm-kernel@lists.infradead.org
> > Subject: Re: [RFC PATCH v12 03/11] psci: export smccc conduit get helper.
> > 
> > On Fri, May 22, 2020 at 04:37:16PM +0800, Jianyong Wu wrote:
> > > Export arm_smccc_1_1_get_conduit then modules can use smccc helper
> > > which adopts it.
> > >
> > > Acked-by: Mark Rutland <mark.rutland@arm.com>
> > > Signed-off-by: Jianyong Wu <jianyong.wu@arm.com>
> > > ---
> > >  drivers/firmware/psci/psci.c | 1 +
> > >  1 file changed, 1 insertion(+)
> > >
> > > diff --git a/drivers/firmware/psci/psci.c
> > > b/drivers/firmware/psci/psci.c index 2937d44b5df4..fd3c88f21b6a 100644
> > > --- a/drivers/firmware/psci/psci.c
> > > +++ b/drivers/firmware/psci/psci.c
> > > @@ -64,6 +64,7 @@ enum arm_smccc_conduit
> > > arm_smccc_1_1_get_conduit(void)
> > >
> > >  	return psci_ops.conduit;
> > >  }
> > > +EXPORT_SYMBOL(arm_smccc_1_1_get_conduit);
> > >
> > 
> > I have moved this into drivers/firmware/smccc/smccc.c [1] Please update
> > this accordingly.
> 
> Ok, I will remove this patch next version.

You may need it still, just that this patch won't apply as the function
is moved to a new file.

-- 
Regards,
Sudeep

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH v2 6/6] dt-bindings: drm: bridge: adi,adv7511.txt: convert to yaml
From: Laurent Pinchart @ 2020-05-26 10:11 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	Geert Uytterhoeven, Wei Xu, Rob Herring, Collabora Kernel ML,
	Ricardo Cañuelo, Linux ARM
In-Reply-To: <CAMuHMdXinhY13us9rt9h7EvrT_8zhnQg6tmOBtA0nEQ=1G1O7Q@mail.gmail.com>

Hi Geert,

On Tue, May 26, 2020 at 09:03:09AM +0200, Geert Uytterhoeven wrote:
> On Tue, May 26, 2020 at 3:44 AM Laurent Pinchart wrote:
> > On Mon, May 25, 2020 at 09:43:35AM +0200, Ricardo Cañuelo wrote:
> > > On jue 14-05-2020 18:22:39, Laurent Pinchart wrote:
> > > > > If we want to be more strict and require the definition of all the
> > > > > supplies, there will be many more DTs changes in the series, and I'm not
> > > > > sure I'll be able to do that in a reasonable amount of time. I'm looking
> > > > > at them and it's not always clear which regulators to use or if they are
> > > > > even defined.
> > > >
> > > > We can decouple the two though (I think). The bindings should reflect
> > > > what we consider right, and the dts files could be fixed on top.
> > >
> > > Do you have a suggestion on how to do this? If we decouple the two
> > > tasks most of the work would be searching for DTs to fix and finding a
> > > way to fix each one of them, and unless I do this _before_ the binding
> > > conversion I'll get a lot of dtbs_check errors.
> >
> > Rob should answer this question as it will be his decision, but I've
> > personally never considered non-compliant DT sources to be an obstacle
> > to bindings conversion to YAML. The DT sources should be fixed, but I
> > don't see it as a prerequisite (although it's a good practice).
> 
> I do my best to avoid introducing regressions when the binding conversions
> go upstream.

Please note that we're not talking about runtime regressions, as drivers
are not updated. It's "only" dtbs_check that would produce new errors.

> FTR, hence patches 1-3 are already in v5.7-rc7.

-- 
Regards,

Laurent Pinchart

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipelin
From: Maxime Ripard @ 2020-05-26 10:20 UTC (permalink / raw)
  To: Jian-Hong Pan
  Cc: devicetree, Linux Kernel, dri-devel, linux-i2c, Eric Anholt,
	bcm-kernel-feedback-list, Nicolas Saenz Julienne,
	Linux Upstreaming Team, linux-clk, linux-arm-kernel,
	linux-rpi-kernel
In-Reply-To: <CAPpJ_ed9TMJjN8xS1_3saf5obQhULJSLNgQSAFxgiWM2QX9A7Q@mail.gmail.com>

Hi,

On Mon, May 11, 2020 at 11:12:05AM +0800, Jian-Hong Pan wrote:
> Jian-Hong Pan <jian-hong@endlessm.com> 於 2020年5月8日 週五 下午2:20寫道:
> >
> > Maxime Ripard <maxime@cerno.tech> 於 2020年5月8日 週五 上午1:22寫道:
> > >
> > > On Mon, May 04, 2020 at 02:35:08PM +0800, Jian-Hong Pan wrote:
> > > > Maxime Ripard <maxime@cerno.tech> 於 2020年4月29日 週三 上午12:21寫道:
> > > > >
> > > > > Hi,
> > > > >
> > > > > On Mon, Apr 27, 2020 at 03:23:42PM +0800, Jian-Hong Pan wrote:
> > > > > > Hi Maxime,
> > > > > >
> > > > > > Thanks for your V2 patch series!  I'm testing it.
> > > > > >
> > > > > > This patch series is applied upon mainline kernel 5.7-rc2 cleanly and built.
> > > > > > System can boot into console text mode, but no graphic UI.
> > > > > >
> > > > > > Get the error in vc5_hdmi_phy_init(), and full dmesg is at [1]:
> > > > > >
> > > > > > [    5.587543] vc4_hdmi fef00700.hdmi: Unknown register ID 46
> > > > > > [    5.587700] debugfs: Directory 'fef00700.hdmi' with parent 'vc4-hdmi' already present!
> > > > > > [    5.588070] vc4_hdmi fef00700.hdmi: vc4-hdmi-hifi <-> fef00700.hdmi mapping ok
> > > > > > [    5.588076] vc4_hdmi fef00700.hdmi: ASoC: no DMI vendor name!
> > > > > > [    5.588263] vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops)
> > > > > > [    5.588299] vc4_hdmi fef05700.hdmi: Unknown register ID 46
> > > > > > [    5.588373] debugfs: Directory 'vc4-hdmi' with parent 'asoc' already present!
> > > > > > [    5.588673] vc4_hdmi fef05700.hdmi: vc4-hdmi-hifi <-> fef05700.hdmi mapping ok
> > > > > > [    5.588677] vc4_hdmi fef05700.hdmi: ASoC: no DMI vendor name!
> > > > > > [    5.588809] vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops)
> > > > > > [    5.588854] vc4-drm gpu: bound fe806000.vec (ops vc4_vec_ops)
> > > > > > [    5.588897] vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops)
> > > > > > [    5.588934] vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops)
> > > > > > [    5.588990] vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops)
> > > > > > [    5.589030] vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops)
> > > > > > [    5.589074] vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops)
> > > > > > [    5.589106] vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops)
> > > > > > [    5.589145] vc4-drm gpu: bound fec12000.pixelvalve (ops vc4_crtc_ops)
> > > > > > [    5.589294] checking generic (3e513000 6d8c00) vs hw (0 ffffffffffffffff)
> > > > > > [    5.589297] fb0: switching to vc4drmfb from simple
> > > > > > [    5.589433] Console: switching to colour dummy device 80x25
> > > > > > [    5.589481] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> > > > > > [    5.589816] [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0
> > > > > > [    5.601079] ------------[ cut here ]------------
> > > > > > [    5.601095] WARNING: CPU: 2 PID: 127 at drivers/gpu/drm/vc4/vc4_hdmi_phy.c:413 vc5_hdmi_phy_init+0x7ac/0x2078
> > > > > > [    5.601097] Modules linked in:
> > > > > > [    5.601103] CPU: 2 PID: 127 Comm: kworker/2:1 Not tainted 5.7.0-rc2-00091-ga181df59a930 #7
> > > > > > [    5.601105] Hardware name: Raspberry Pi 4 Model B (DT)
> > > > > > [    5.601112] Workqueue: events deferred_probe_work_func
> > > > > > [    5.601116] pstate: 20000005 (nzCv daif -PAN -UAO)
> > > > > > [    5.601119] pc : vc5_hdmi_phy_init+0x7ac/0x2078
> > > > > > [    5.601123] lr : vc4_hdmi_encoder_enable+0x1b8/0x1ac0
> > > > > > [    5.601124] sp : ffff80001217b410
> > > > > > [    5.601126] x29: ffff80001217b410 x28: ffff0000ec6370f0
> > > > > > [    5.601129] x27: ffff0000f650d400 x26: 000000008a500000
> > > > > > [    5.601132] x25: ffff8000113b4ac0 x24: 0000000000002060
> > > > > > [    5.601135] x23: 000000000a500000 x22: 0000000000000300
> > > > > > [    5.601137] x21: 0000000008d9ee20 x20: ffff0000ec535080
> > > > > > [    5.601140] x19: 000000010989e7c0 x18: 0000000000000000
> > > > > > [    5.601142] x17: 0000000000000001 x16: 0000000000005207
> > > > > > [    5.601145] x15: 00004932ad293c92 x14: 0000000000000137
> > > > > > [    5.601147] x13: ffff800010015000 x12: 0000000000000001
> > > > > > [    5.601150] x11: 0000000000000001 x10: 0000000000000000
> > > > > > [    5.601152] x9 : 0000000000000000 x8 : ffff800010015038
> > > > > > [    5.601154] x7 : 0000000000000001 x6 : ffff80001217b368
> > > > > > [    5.601157] x5 : 0000000000000000 x4 : 000000000000004c
> > > > > > [    5.601159] x3 : 0000000000000000 x2 : ffff8000113b4ac0
> > > > > > [    5.601162] x1 : ffff8000120c5f44 x0 : 00000000dc8984ff
> > > > > > [    5.601164] Call trace:
> > > > > > [    5.601169]  vc5_hdmi_phy_init+0x7ac/0x2078
> > > > > > [    5.601172]  vc4_hdmi_encoder_enable+0x1b8/0x1ac0
> > > > > > [    5.601176]  drm_atomic_helper_commit_modeset_enables+0x224/0x248
> > > > > > [    5.601179]  vc4_atomic_complete_commit+0x400/0x558
> > > > > > [    5.601182]  vc4_atomic_commit+0x1e0/0x200
> > > > > > [    5.601185]  drm_atomic_commit+0x4c/0x60
> > > > > > [    5.601190]  drm_client_modeset_commit_atomic.isra.0+0x17c/0x238
> > > > > > [    5.601192]  drm_client_modeset_commit_locked+0x5c/0x198
> > > > > > [    5.601195]  drm_client_modeset_commit+0x30/0x58
> > > > > > [    5.601201]  drm_fb_helper_restore_fbdev_mode_unlocked+0x78/0xe0
> > > > > > [    5.601204]  drm_fb_helper_set_par+0x30/0x68
> > > > > > [    5.601208]  fbcon_init+0x3d4/0x598
> > > > > > [    5.601212]  visual_init+0xb0/0x108
> > > > > > [    5.601214]  do_bind_con_driver+0x1d0/0x3a8
> > > > > > [    5.601217]  do_take_over_console+0x144/0x208
> > > > > > [    5.601219]  do_fbcon_takeover+0x68/0xd8
> > > > > > [    5.601222]  fbcon_fb_registered+0x100/0x118
> > > > > > [    5.601226]  register_framebuffer+0x1f4/0x338
> > > > > > [    5.601229]  __drm_fb_helper_initial_config_and_unlock+0x2f8/0x4a0
> > > > > > [    5.601232]  drm_fbdev_client_hotplug+0xd4/0x1b0
> > > > > > [    5.601235]  drm_fbdev_generic_setup+0xb0/0x130
> > > > > > [    5.601238]  vc4_drm_bind+0x184/0x1a0
> > > > > > [    5.601241]  try_to_bring_up_master+0x168/0x1c8
> > > > > > [    5.601244]  __component_add+0xa4/0x170
> > > > > > [    5.601246]  component_add+0x14/0x20
> > > > > > [    5.601248]  vc4_vec_dev_probe+0x20/0x30
> > > > > > [    5.601252]  platform_drv_probe+0x54/0xa8
> > > > > > [    5.601254]  really_probe+0xd8/0x320
> > > > > > [    5.601256]  driver_probe_device+0x58/0xf0
> > > > > > [    5.601258]  __device_attach_driver+0x84/0xc8
> > > > > > [    5.601263]  bus_for_each_drv+0x78/0xc8
> > > > > > [    5.601265]  __device_attach+0xe4/0x140
> > > > > > [    5.601267]  device_initial_probe+0x14/0x20
> > > > > > [    5.601269]  bus_probe_device+0x9c/0xa8
> > > > > > [    5.601271]  deferred_probe_work_func+0x74/0xb0
> > > > > > [    5.601276]  process_one_work+0x1bc/0x338
> > > > > > [    5.601279]  worker_thread+0x1f8/0x428
> > > > > > [    5.601282]  kthread+0x138/0x158
> > > > > > [    5.601286]  ret_from_fork+0x10/0x1c
> > > > > > [    5.601288] ---[ end trace cfba0996218c3f3d ]---
> > > > >
> > > > > Thanks for testing!
> > > > >
> > > > > Do you have a bit more details regarding your setup? Was it connected to an
> > > > > external display?
> > > >
> > > > Yes, the HDMI cable is connected to HDMI0 port on RPi 4.
> > > >
> > > > > If so, do you know the resolution it was trying to setup?
> > > >
> > > > According to the log, I think it is 1920x1080:
> > > > Apr 27 15:37:25 endless gdm-Xorg-:0[1960]: (II) modeset(0): Output
> > > > HDMI-1 connected
> > > > Apr 27 15:37:25 endless gdm-Xorg-:0[1960]: (II) modeset(0): Output
> > > > HDMI-2 disconnected
> > > > Apr 27 15:37:25 endless gdm-Xorg-:0[1960]: (II) modeset(0): Output
> > > > Composite-1 disconnected
> > > > Apr 27 15:37:25 endless gdm-Xorg-:0[1960]: (II) modeset(0): Using
> > > > exact sizes for initial modes
> > > > Apr 27 15:37:25 endless gdm-Xorg-:0[1960]: (II) modeset(0): Output
> > > > HDMI-1 using initial mode 1920x1080 +0+0
> > > >
> > > > https://gist.github.com/starnight/45e1468bfa0426a54d2fb4a9269cfb94
> > >
> > > It looks to be fairly standard then, and I'm testing on the same resolution so
> > > it should be alright.
> > >
> > > Given from your log, it looks like you're running as arm64 though, while I stuck
> > > with arm32, so it could be the explanation.
> >
> > Yes, I build it as arm64.
> >
> > > Can you share your config.txt and .config so that I can try to reproduce it
> > > here?
> >
> > Here is the config
> > https://gist.github.com/starnight/320b757441b6769c36160704b401c98b
> 
> Here is the only one line in config.txt:
> enable_uart=1
> 
> Actually, we make the Raspberry Pi's firmware bring up U-Boot, then
> U-Boot boots kernel.

I gave it a try with U-Boot with my latest work and couldn't reproduce it, so it
seems that I fixed it along the way

Maxime

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH 1/4] i2c: smbus: add core function handling SMBus host-notify
From: Alain Volmat @ 2020-05-26 10:23 UTC (permalink / raw)
  To: Wolfram Sang
  Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
	Alexandre TORGUE, linux-kernel@vger.kernel.org,
	Pierre Yves MORDRET, robh+dt@kernel.org, Benjamin Tissoires,
	linux-i2c@vger.kernel.org, mcoquelin.stm32@gmail.com,
	Fabrice GASNIER, linux-stm32@st-md-mailman.stormreply.com,
	linux-arm-kernel@lists.infradead.org
In-Reply-To: <20200523104624.GB3459@ninjato>

On Sat, May 23, 2020 at 10:46:25AM +0000, Wolfram Sang wrote:
> 
> Adding Benjamin who mainly implemented this.
> 
> On Tue, May 05, 2020 at 07:51:08AM +0200, Alain Volmat wrote:
> > SMBus Host-Notify protocol, from the adapter point of view
> > consist of receiving a message from a client, including the
> > client address and some other data.
> > 
> > It can be simply handled by creating a new slave device
> > and registering a callback performing the parsing of the
> > message received from the client.
> > 
> > This commit introduces two new core functions
> >   * i2c_new_smbus_host_notify_device
> >   * i2c_free_smbus_host_notify_device
> > that take care of registration of the new slave device and
> > callback and will call i2c_handle_smbus_host_notify once a
> > Host-Notify event is received.
> 
> Yay, cool idea to use the slave interface. I like it a lot!
> 
> > +static int i2c_smbus_host_notify_cb(struct i2c_client *client,
> > +				    enum i2c_slave_event event, u8 *val)
> > +{
> > +	struct i2c_smbus_host_notify_status *status = client->dev.platform_data;
> > +	int ret;
> > +
> > +	switch (event) {
> > +	case I2C_SLAVE_WRITE_REQUESTED:
> > +		status->notify_start = true;
> > +		break;
> > +	case I2C_SLAVE_WRITE_RECEIVED:
> > +		/* We only retrieve the first byte received (addr)
> > +		 * since there is currently no way to retrieve the data
> > +		 * parameter from the client.
> 
> Maybe s/no way/no support/ ? I still wonder if we couldn't add it
> somehow. Once we find a device which needs this, of course.

Indeed. Such support can be added later on once such device is found. For the
time being I will state "no support"

> 
> > +		 */
> > +		if (!status->notify_start)
> > +			break;
> > +		status->addr = *val;
> > +		status->notify_start = false;
> > +		break;
> > +	case I2C_SLAVE_STOP:
> 
> What about setting 'notify_start' to false here as well? In the case of
> an incomplete write?

Ok. I will check that notify_start is false before calling host_notify
(since otherwise it will call i2c_handle_smbus_host_notify with a bad addr
value) and reset notify_start to false if it is still true.

> 
> > +		ret = i2c_handle_smbus_host_notify(client->adapter,
> > +						   status->addr);
> > +		if (ret < 0) {
> > +			dev_warn(&client->adapter->dev, "failed to handle host_notify (%d)\n",
> > +				ret);
> 
> I think we should rather add such error strings to the core if we think
> they are needed. I am not convinced they are, though.

Agreed, this error can be removed.

> 
> > +			return ret;
> > +		}
> > +		break;
> > +	default:
> > +		/* Only handle necessary events */
> > +		break;
> > +	}
> > +
> > +	return 0;
> > +}
> > +
> 
> Rest of the code looks good. Maybe we should compile all this only when
> I2C_SLAVE is enabled?
> 

Yes, I will enclose that around I2C_SLAVE support check.



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH v7 0/3] perf arm-spe: Add support for synthetic events
From: Will Deacon @ 2020-05-26 10:26 UTC (permalink / raw)
  To: Leo Yan
  Cc: Mark Rutland, Al Grant, Mathieu Poirier, Peter Zijlstra,
	linux-kernel, Arnaldo Carvalho de Melo, Alexander Shishkin,
	Ingo Molnar, James Clark, Namhyung Kim, Jiri Olsa,
	linux-arm-kernel, Mike Leach
In-Reply-To: <20200522030919.GE32389@leoy-ThinkPad-X240s>

On Fri, May 22, 2020 at 11:09:19AM +0800, Leo Yan wrote:
> On Mon, May 04, 2020 at 07:56:22PM +0800, Leo Yan wrote:
> > This patch set is to support synthetic events with enabling Arm SPE
> > decoder.  Since before Xiaojun Tan (Hisilicon) and James Clark (Arm)
> > have contributed much for this task, so this patch set is based on their
> > privous work and polish for the version 7.
> > 
> > The main work in this version is to polished the core patch "perf
> > arm-spe: Support synthetic events", e.g. rewrite the code to calculate
> > ip, packet generation for multiple types (L1 data cache, Last level
> > cache, TLB, remote access, etc).  It also heavily refactors code for
> > data structure and program flow, which removed unused fields in
> > structure and polished the program flow to achieve neat code as
> > possible.
> > 
> > This patch set has been checked with checkpatch.pl, though it leaves
> > several warnings, but these warnings are delibarately kept after
> > reviewing.  Some warnings ask to add maintainer (so far it's not
> > necessary), and some warnings complaint for patch 02 "perf auxtrace:
> > Add four itrace options" for the text format, since need to keep the
> > consistency with the same code format in the source code, this is why
> > this patch doesn't get rid of checkpatch warnings.
> 
> Gentle ping ...
> 
> It would be appreciate if can get some review for this patch set.

I was hoping that James Clark would have a look, since he was the last
person to go near the userspace side of SPE.

Will

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH][V3] arm64: perf: Get the wrong PC value in REGS_ABI_32 mode
From: Mark Rutland @ 2020-05-26 10:26 UTC (permalink / raw)
  To: Jiping Ma
  Cc: zhe.he, bruce.ashfield, yue.tao, will.deacon, linux-kernel,
	paul.gortmaker, catalin.marinas, linux-arm-kernel
In-Reply-To: <1589165527-188401-1-git-send-email-jiping.ma2@windriver.com>

On Mon, May 11, 2020 at 10:52:07AM +0800, Jiping Ma wrote:
> Modified the patch subject and the change description.
> 
> PC value is get from regs[15] in REGS_ABI_32 mode, but correct PC
> is regs->pc(regs[PERF_REG_ARM64_PC]) in arm64 kernel, which caused
> that perf can not parser the backtrace of app with dwarf mode in the 
> 32bit system and 64bit kernel.
> 
> Signed-off-by: Jiping Ma <jiping.ma2@windriver.com>

Thanks for this.


> ---
>  arch/arm64/kernel/perf_regs.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/arch/arm64/kernel/perf_regs.c b/arch/arm64/kernel/perf_regs.c
> index 0bbac61..0ef2880 100644
> --- a/arch/arm64/kernel/perf_regs.c
> +++ b/arch/arm64/kernel/perf_regs.c
> @@ -32,6 +32,10 @@ u64 perf_reg_value(struct pt_regs *regs, int idx)
>  	if ((u32)idx == PERF_REG_ARM64_PC)
>  		return regs->pc;
>  
> +	if (perf_reg_abi(current) == PERF_SAMPLE_REGS_ABI_32
> +		&& idx == 15)
> +		return regs->pc;

I think there are some more issues here, and we may need a more
substantial rework. For a compat thread, we always expose
PERF_SAMPLE_REGS_ABI_32 via per_reg_abi(), but for some reason
perf_reg_value() also munges the compat SP/LR into their ARM64
equivalents, which don't exist in the 32-bit sample ABI. We also don't
zero the regs that don't exist in 32-bit (including the aliasing PC).

I reckon what we should do is have seperate functions for the two ABIs,
to ensure we don't conflate them, e.g.

u64 perf_reg_value_abi32(struct pt_regs *regs, int idx)
{
	if ((u32)idx > PERF_REG_ARM32_PC)
		return 0;
	if (idx == PERF_REG_ARM32_PC)
		return regs->pc;
	
	/*
	 * Compat SP and LR already in-place
	 */
	return regs->regs[idx];
}

u64 perf_reg_value_abi64(struct pt_regs *regs, int idx)
{
	if ((u32)idx > PERF_REG_ARM64_MAX)
		return 0;
	if ((u32)idx == PERF_REG_ARM64_SP)
		return regs->sp;
	if ((u32)idx == PERF_REG_ARM64_PC)
		return regs->pc;
	
	reutrn regs->regs[idx];
}

u64 perf_reg_value(struct pt_regs *regs, int idx)
{
	if (compat_user_mode(regs))
		return perf_reg_value_abi32(regs, idx);
	else
		return perf_reg_value_abi64(regs, idx);
}

Thanks,
Mark.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH 3/4] dt-bindings: i2c-stm32: add SMBus Alert bindings
From: Alain Volmat @ 2020-05-26 10:31 UTC (permalink / raw)
  To: wsa@kernel.org
  Cc: mark.rutland@arm.com, Rob Herring, Alexandre TORGUE,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	Pierre Yves MORDRET, linux-i2c@vger.kernel.org,
	mcoquelin.stm32@gmail.com, Fabrice GASNIER,
	linux-stm32@st-md-mailman.stormreply.com,
	linux-arm-kernel@lists.infradead.org
In-Reply-To: <20200523103601.GA3459@ninjato>

On Sat, May 23, 2020 at 10:36:01AM +0000, wsa@kernel.org wrote:
> 
> > > > +        st,smbus-alert:
> > > > +          description: Enable the SMBus Alert feature
> > > > +          $ref: /schemas/types.yaml#/definitions/flag
> > > > +
> > > 
> > > We already have smbus_alert interrupt. Can't you just check for this in 
> > > the slave nodes and enable if found?
> > 
> > My understanding reading the code (smbalert_probe within i2c-smbus.c, of_i2c_setup_smbus_alert called when
> > registering an adapter within i2c-core-smbus.c) is that smbus_alert refers to an interrupt on the
> > adapter side. That is an interrupt that would be triggered when the adapter is receiving an smbus_alert
> > message.
> > In our case (stm32f7), we do not have specific interrupt for that purpose. The interrupt triggered when
> > an SMBUS Alert is received (by the adapter) is the same interrupt as for other reasons and we check
> > within the irq handler within stm32f7 the reason before calling i2c_handle_smbus_alert if the status
> > register indicated an SMBUS Alert.
> > So my understanding is that we cannot rely on the mechanism of naming an interrupt smbus_alert.
> > Did I misunderstood something ?
> 
> I just wonder what is bad about specifying the same interrupt twice in
> the interrupt properties? You could then check in probe if "smbus_alert"
> is populated and if it matches the main irq.
> 

Here's my understanding of the current implementation.
During the adapter registration, the function of_i2c_setup_smbus_alert is called
and if a interrupt is named "smbus_alert" in the adapter node, a new device
"smbus_alert" will be created. This will leads to smbalert_probe to be called,
and a request_irq will be done with the irq value read from the adapter node.
This means that we will have both our handle (the handler of the main irq
of the stm32 i2c driver) and the smbus_alert handler on the same irq. Leading
to smbus_alert being called everytime there is a irq (most of the time not
smbus_alert related) coming from the stm32_i2c. (since this is our main irq).

So to me this approach can't work. I'd understand if the smbus_alert property
was on the client node in the same way as it is done for host-notify however
that's not the case.
This is why I was proposing to have our own st,smbus-alert property to decide
to enable or not the smbus_alert. In our case, we cannot rely on the mechanism
done by of_i2c_setup_smbus_alert since for us, smbus_alert irq is just one
case of all the other stm32 i2c irq. (this is the same irq, and we check after
by reading the interrupt status register).

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH v5 6/8] drm/panel: Add ilitek ili9341 panel driver
From: Noralf Trønnes @ 2020-05-26 10:38 UTC (permalink / raw)
  To: dillon min, Andy Shevchenko
  Cc: devicetree, Linus Walleij, linux-clk, Linux Kernel Mailing List,
	dri-devel, linux-spi, Mark Brown, Sam Ravnborg, linux-stm32,
	linux-arm Mailing List
In-Reply-To: <CAL9mu0+jmcivC6zAXxK0-oXy3n44pAU1QGD7BDq=CT2D7twROQ@mail.gmail.com>



Den 26.05.2020 11.08, skrev dillon min:
> Hi Andy,
> 
> Thanks for input.
> 
> On Tue, May 26, 2020 at 3:46 PM Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:
>>
>> On Mon, May 25, 2020 at 6:46 AM <dillon.minfei@gmail.com> wrote:
>>>
>>> From: dillon min <dillon.minfei@gmail.com>
>>>
>>>     This driver combine tiny/ili9341.c mipi_dbi_interface driver
>>>     with mipi_dpi_interface driver, can support ili9341 with serial
>>>     mode or parallel rgb interface mode by register configuration.
>>
>> Noralf told once that this driver should be unified with mi0283qt.c.
>>
>> So, what should we do here?
>>
>> --
>> With Best Regards,
>> Andy Shevchenko
> 
> from sam's suggestion, we can't setup two drivers to support one panel
> in the tree. so, i copy the mipi dbi part from tiny/ili9341.c. to this driver
> from register settings and dts binding is keep the same to tiny/ili9341.c.
> 
> so, in my opinion if tiny/ili9341.c is unified with mi0283qt.c, this
> driver should be
> too.
> 

There's a discussion about MIPI DBI panels here:

MIPI DSI, DBI, and tinydrm drivers
https://lists.freedesktop.org/archives/dri-devel/2020-May/267031.html

Noralf.

> thanks.
> 
> best regards,
> 
> Dillon,
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH 4/4] i2c: stm32f7: Add SMBus-specific protocols support
From: Alain Volmat @ 2020-05-26 10:39 UTC (permalink / raw)
  To: Wolfram Sang
  Cc: mark.rutland, devicetree, alexandre.torgue, linux-kernel,
	pierre-yves.mordret, robh+dt, Benjamin Tissoires, linux-i2c,
	mcoquelin.stm32, fabrice.gasnier, linux-stm32, linux-arm-kernel
In-Reply-To: <20200523110140.GD3459@ninjato>

On Sat, May 23, 2020 at 01:01:40PM +0200, Wolfram Sang wrote:
> 
> > +static int stm32f7_i2c_reg_client(struct i2c_client *client)
> > +{
> > +	struct stm32f7_i2c_dev *i2c_dev = i2c_get_adapdata(client->adapter);
> > +	int ret;
> > +
> > +	if (client->flags & I2C_CLIENT_HOST_NOTIFY) {
> > +		/* Only enable on the first device registration */
> > +		if (atomic_inc_return(&i2c_dev->host_notify_cnt) == 1) {
> > +			ret = stm32f7_i2c_enable_smbus_host(i2c_dev);
> > +			if (ret) {
> > +				dev_err(i2c_dev->dev,
> > +					"failed to enable SMBus host notify (%d)\n",
> > +					ret);
> > +				return ret;
> > +			}
> > +		}
> > +	}
> > +
> > +	return 0;
> > +}
> 
> So, as mentioned in the other review, I'd like to evaluate other
> possibilities for the above:
> 
> - One option is to enable it globally in probe(). Then you lose the
>   possibility to have a device at address 0x08.

I'd prefer avoid this solution to not lose the address 0x08.

> - Enable it in probe() only if there is a generic binding "host-notify".

Do you mean having the adapter walk through childs node and see if at least
one of them have the host-notify property ? This mean that such solution
wouldn't work for device relying on platform data rather than DT nodes.

> - Let the core scan for a device with HOST_NOTIFY when registering an
>   adapter and then call back into the driver somehow?

You mean at adapter registration time only ? Not device probing time ?
At probing time, we could have the core (i2c_device_probe) check for the flag
HOST_NOTIFY and if setted call a dedicated host-notify reg callback ?

> 
> Other ideas?
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH v2 6/6] dt-bindings: drm: bridge: adi, adv7511.txt: convert to yaml
From: Geert Uytterhoeven @ 2020-05-26 10:39 UTC (permalink / raw)
  To: Laurent Pinchart
  Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	Geert Uytterhoeven, Wei Xu, Rob Herring, Collabora Kernel ML,
	Ricardo Cañuelo, Linux ARM
In-Reply-To: <20200526101158.GA5903@pendragon.ideasonboard.com>

Hi Laurent,

On Tue, May 26, 2020 at 12:12 PM Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Tue, May 26, 2020 at 09:03:09AM +0200, Geert Uytterhoeven wrote:
> > On Tue, May 26, 2020 at 3:44 AM Laurent Pinchart wrote:
> > > On Mon, May 25, 2020 at 09:43:35AM +0200, Ricardo Cañuelo wrote:
> > > > On jue 14-05-2020 18:22:39, Laurent Pinchart wrote:
> > > > > > If we want to be more strict and require the definition of all the
> > > > > > supplies, there will be many more DTs changes in the series, and I'm not
> > > > > > sure I'll be able to do that in a reasonable amount of time. I'm looking
> > > > > > at them and it's not always clear which regulators to use or if they are
> > > > > > even defined.
> > > > >
> > > > > We can decouple the two though (I think). The bindings should reflect
> > > > > what we consider right, and the dts files could be fixed on top.
> > > >
> > > > Do you have a suggestion on how to do this? If we decouple the two
> > > > tasks most of the work would be searching for DTs to fix and finding a
> > > > way to fix each one of them, and unless I do this _before_ the binding
> > > > conversion I'll get a lot of dtbs_check errors.
> > >
> > > Rob should answer this question as it will be his decision, but I've
> > > personally never considered non-compliant DT sources to be an obstacle
> > > to bindings conversion to YAML. The DT sources should be fixed, but I
> > > don't see it as a prerequisite (although it's a good practice).
> >
> > I do my best to avoid introducing regressions when the binding conversions
> > go upstream.
>
> Please note that we're not talking about runtime regressions, as drivers
> are not updated. It's "only" dtbs_check that would produce new errors.

Exactly.  I was talking about "make dtbs_check" regressions, too.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH RFCv2 3/9] kvm/arm64: Rename kvm_vcpu_get_hsr() to kvm_vcpu_get_esr()
From: Mark Rutland @ 2020-05-26 10:42 UTC (permalink / raw)
  To: Gavin Shan
  Cc: aarcange, drjones, suzuki.poulose, catalin.marinas, linux-kernel,
	eric.auger, james.morse, shan.gavin, maz, will, kvmarm,
	linux-arm-kernel
In-Reply-To: <20200508032919.52147-4-gshan@redhat.com>

On Fri, May 08, 2020 at 01:29:13PM +1000, Gavin Shan wrote:
> Since kvm/arm32 was removed, this renames kvm_vcpu_get_hsr() to
> kvm_vcpu_get_esr() to it a bit more self-explaining because the
> functions returns ESR instead of HSR on aarch64. This shouldn't
> cause any functional changes.
> 
> Signed-off-by: Gavin Shan <gshan@redhat.com>

I think that this would be a nice cleanup on its own, and could be taken
independently of the rest of this series if it were rebased and sent as
a single patch.

Mark.

> ---
>  arch/arm64/include/asm/kvm_emulate.h | 36 +++++++++++++++-------------
>  arch/arm64/kvm/handle_exit.c         | 12 +++++-----
>  arch/arm64/kvm/hyp/switch.c          |  2 +-
>  arch/arm64/kvm/sys_regs.c            |  6 ++---
>  virt/kvm/arm/hyp/aarch32.c           |  2 +-
>  virt/kvm/arm/hyp/vgic-v3-sr.c        |  4 ++--
>  virt/kvm/arm/mmu.c                   |  6 ++---
>  7 files changed, 35 insertions(+), 33 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h
> index a30b4eec7cb4..bd1a69e7c104 100644
> --- a/arch/arm64/include/asm/kvm_emulate.h
> +++ b/arch/arm64/include/asm/kvm_emulate.h
> @@ -265,14 +265,14 @@ static inline bool vcpu_mode_priv(const struct kvm_vcpu *vcpu)
>  	return mode != PSR_MODE_EL0t;
>  }
>  
> -static __always_inline u32 kvm_vcpu_get_hsr(const struct kvm_vcpu *vcpu)
> +static __always_inline u32 kvm_vcpu_get_esr(const struct kvm_vcpu *vcpu)
>  {
>  	return vcpu->arch.fault.esr_el2;
>  }
>  
>  static __always_inline int kvm_vcpu_get_condition(const struct kvm_vcpu *vcpu)
>  {
> -	u32 esr = kvm_vcpu_get_hsr(vcpu);
> +	u32 esr = kvm_vcpu_get_esr(vcpu);
>  
>  	if (esr & ESR_ELx_CV)
>  		return (esr & ESR_ELx_COND_MASK) >> ESR_ELx_COND_SHIFT;
> @@ -297,64 +297,66 @@ static inline u64 kvm_vcpu_get_disr(const struct kvm_vcpu *vcpu)
>  
>  static inline u32 kvm_vcpu_hvc_get_imm(const struct kvm_vcpu *vcpu)
>  {
> -	return kvm_vcpu_get_hsr(vcpu) & ESR_ELx_xVC_IMM_MASK;
> +	return kvm_vcpu_get_esr(vcpu) & ESR_ELx_xVC_IMM_MASK;
>  }
>  
>  static __always_inline bool kvm_vcpu_dabt_isvalid(const struct kvm_vcpu *vcpu)
>  {
> -	return !!(kvm_vcpu_get_hsr(vcpu) & ESR_ELx_ISV);
> +	return !!(kvm_vcpu_get_esr(vcpu) & ESR_ELx_ISV);
>  }
>  
>  static inline unsigned long kvm_vcpu_dabt_iss_nisv_sanitized(const struct kvm_vcpu *vcpu)
>  {
> -	return kvm_vcpu_get_hsr(vcpu) & (ESR_ELx_CM | ESR_ELx_WNR | ESR_ELx_FSC);
> +	return kvm_vcpu_get_esr(vcpu) &
> +	       (ESR_ELx_CM | ESR_ELx_WNR | ESR_ELx_FSC);
>  }
>  
>  static inline bool kvm_vcpu_dabt_issext(const struct kvm_vcpu *vcpu)
>  {
> -	return !!(kvm_vcpu_get_hsr(vcpu) & ESR_ELx_SSE);
> +	return !!(kvm_vcpu_get_esr(vcpu) & ESR_ELx_SSE);
>  }
>  
>  static inline bool kvm_vcpu_dabt_issf(const struct kvm_vcpu *vcpu)
>  {
> -	return !!(kvm_vcpu_get_hsr(vcpu) & ESR_ELx_SF);
> +	return !!(kvm_vcpu_get_esr(vcpu) & ESR_ELx_SF);
>  }
>  
>  static __always_inline int kvm_vcpu_dabt_get_rd(const struct kvm_vcpu *vcpu)
>  {
> -	return (kvm_vcpu_get_hsr(vcpu) & ESR_ELx_SRT_MASK) >> ESR_ELx_SRT_SHIFT;
> +	return (kvm_vcpu_get_esr(vcpu) & ESR_ELx_SRT_MASK) >> ESR_ELx_SRT_SHIFT;
>  }
>  
>  static __always_inline bool kvm_vcpu_dabt_iss1tw(const struct kvm_vcpu *vcpu)
>  {
> -	return !!(kvm_vcpu_get_hsr(vcpu) & ESR_ELx_S1PTW);
> +	return !!(kvm_vcpu_get_esr(vcpu) & ESR_ELx_S1PTW);
>  }
>  
>  static __always_inline bool kvm_vcpu_dabt_iswrite(const struct kvm_vcpu *vcpu)
>  {
> -	return !!(kvm_vcpu_get_hsr(vcpu) & ESR_ELx_WNR) ||
> +	return !!(kvm_vcpu_get_esr(vcpu) & ESR_ELx_WNR) ||
>  		kvm_vcpu_dabt_iss1tw(vcpu); /* AF/DBM update */
>  }
>  
>  static inline bool kvm_vcpu_dabt_is_cm(const struct kvm_vcpu *vcpu)
>  {
> -	return !!(kvm_vcpu_get_hsr(vcpu) & ESR_ELx_CM);
> +	return !!(kvm_vcpu_get_esr(vcpu) & ESR_ELx_CM);
>  }
>  
>  static __always_inline unsigned int kvm_vcpu_dabt_get_as(const struct kvm_vcpu *vcpu)
>  {
> -	return 1 << ((kvm_vcpu_get_hsr(vcpu) & ESR_ELx_SAS) >> ESR_ELx_SAS_SHIFT);
> +	return 1 << ((kvm_vcpu_get_esr(vcpu) & ESR_ELx_SAS) >>
> +		     ESR_ELx_SAS_SHIFT);
>  }
>  
>  /* This one is not specific to Data Abort */
>  static __always_inline bool kvm_vcpu_trap_il_is32bit(const struct kvm_vcpu *vcpu)
>  {
> -	return !!(kvm_vcpu_get_hsr(vcpu) & ESR_ELx_IL);
> +	return !!(kvm_vcpu_get_esr(vcpu) & ESR_ELx_IL);
>  }
>  
>  static __always_inline u8 kvm_vcpu_trap_get_class(const struct kvm_vcpu *vcpu)
>  {
> -	return ESR_ELx_EC(kvm_vcpu_get_hsr(vcpu));
> +	return ESR_ELx_EC(kvm_vcpu_get_esr(vcpu));
>  }
>  
>  static inline bool kvm_vcpu_trap_is_iabt(const struct kvm_vcpu *vcpu)
> @@ -364,12 +366,12 @@ static inline bool kvm_vcpu_trap_is_iabt(const struct kvm_vcpu *vcpu)
>  
>  static __always_inline u8 kvm_vcpu_trap_get_fault(const struct kvm_vcpu *vcpu)
>  {
> -	return kvm_vcpu_get_hsr(vcpu) & ESR_ELx_FSC;
> +	return kvm_vcpu_get_esr(vcpu) & ESR_ELx_FSC;
>  }
>  
>  static __always_inline u8 kvm_vcpu_trap_get_fault_type(const struct kvm_vcpu *vcpu)
>  {
> -	return kvm_vcpu_get_hsr(vcpu) & ESR_ELx_FSC_TYPE;
> +	return kvm_vcpu_get_esr(vcpu) & ESR_ELx_FSC_TYPE;
>  }
>  
>  static __always_inline bool kvm_vcpu_dabt_isextabt(const struct kvm_vcpu *vcpu)
> @@ -393,7 +395,7 @@ static __always_inline bool kvm_vcpu_dabt_isextabt(const struct kvm_vcpu *vcpu)
>  
>  static __always_inline int kvm_vcpu_sys_get_rt(struct kvm_vcpu *vcpu)
>  {
> -	u32 esr = kvm_vcpu_get_hsr(vcpu);
> +	u32 esr = kvm_vcpu_get_esr(vcpu);
>  	return ESR_ELx_SYS64_ISS_RT(esr);
>  }
>  
> diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
> index aacfc55de44c..c5b75a4d5eda 100644
> --- a/arch/arm64/kvm/handle_exit.c
> +++ b/arch/arm64/kvm/handle_exit.c
> @@ -89,7 +89,7 @@ static int handle_no_fpsimd(struct kvm_vcpu *vcpu, struct kvm_run *run)
>   */
>  static int kvm_handle_wfx(struct kvm_vcpu *vcpu, struct kvm_run *run)
>  {
> -	if (kvm_vcpu_get_hsr(vcpu) & ESR_ELx_WFx_ISS_WFE) {
> +	if (kvm_vcpu_get_esr(vcpu) & ESR_ELx_WFx_ISS_WFE) {
>  		trace_kvm_wfx_arm64(*vcpu_pc(vcpu), true);
>  		vcpu->stat.wfe_exit_stat++;
>  		kvm_vcpu_on_spin(vcpu, vcpu_mode_priv(vcpu));
> @@ -119,7 +119,7 @@ static int kvm_handle_wfx(struct kvm_vcpu *vcpu, struct kvm_run *run)
>   */
>  static int kvm_handle_guest_debug(struct kvm_vcpu *vcpu, struct kvm_run *run)
>  {
> -	u32 hsr = kvm_vcpu_get_hsr(vcpu);
> +	u32 hsr = kvm_vcpu_get_esr(vcpu);
>  	int ret = 0;
>  
>  	run->exit_reason = KVM_EXIT_DEBUG;
> @@ -146,7 +146,7 @@ static int kvm_handle_guest_debug(struct kvm_vcpu *vcpu, struct kvm_run *run)
>  
>  static int kvm_handle_unknown_ec(struct kvm_vcpu *vcpu, struct kvm_run *run)
>  {
> -	u32 hsr = kvm_vcpu_get_hsr(vcpu);
> +	u32 hsr = kvm_vcpu_get_esr(vcpu);
>  
>  	kvm_pr_unimpl("Unknown exception class: hsr: %#08x -- %s\n",
>  		      hsr, esr_get_class_string(hsr));
> @@ -226,7 +226,7 @@ static exit_handle_fn arm_exit_handlers[] = {
>  
>  static exit_handle_fn kvm_get_exit_handler(struct kvm_vcpu *vcpu)
>  {
> -	u32 hsr = kvm_vcpu_get_hsr(vcpu);
> +	u32 hsr = kvm_vcpu_get_esr(vcpu);
>  	u8 hsr_ec = ESR_ELx_EC(hsr);
>  
>  	return arm_exit_handlers[hsr_ec];
> @@ -267,7 +267,7 @@ int handle_exit(struct kvm_vcpu *vcpu, struct kvm_run *run,
>  		       int exception_index)
>  {
>  	if (ARM_SERROR_PENDING(exception_index)) {
> -		u8 hsr_ec = ESR_ELx_EC(kvm_vcpu_get_hsr(vcpu));
> +		u8 hsr_ec = ESR_ELx_EC(kvm_vcpu_get_esr(vcpu));
>  
>  		/*
>  		 * HVC/SMC already have an adjusted PC, which we need
> @@ -333,5 +333,5 @@ void handle_exit_early(struct kvm_vcpu *vcpu, struct kvm_run *run,
>  	exception_index = ARM_EXCEPTION_CODE(exception_index);
>  
>  	if (exception_index == ARM_EXCEPTION_EL1_SERROR)
> -		kvm_handle_guest_serror(vcpu, kvm_vcpu_get_hsr(vcpu));
> +		kvm_handle_guest_serror(vcpu, kvm_vcpu_get_esr(vcpu));
>  }
> diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
> index 8a1e81a400e0..2c3242bcfed2 100644
> --- a/arch/arm64/kvm/hyp/switch.c
> +++ b/arch/arm64/kvm/hyp/switch.c
> @@ -437,7 +437,7 @@ static bool __hyp_text __hyp_handle_fpsimd(struct kvm_vcpu *vcpu)
>  
>  static bool __hyp_text handle_tx2_tvm(struct kvm_vcpu *vcpu)
>  {
> -	u32 sysreg = esr_sys64_to_sysreg(kvm_vcpu_get_hsr(vcpu));
> +	u32 sysreg = esr_sys64_to_sysreg(kvm_vcpu_get_esr(vcpu));
>  	int rt = kvm_vcpu_sys_get_rt(vcpu);
>  	u64 val = vcpu_get_reg(vcpu, rt);
>  
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index 51db934702b6..5b61465927b7 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -2214,7 +2214,7 @@ static int kvm_handle_cp_64(struct kvm_vcpu *vcpu,
>  			    size_t nr_specific)
>  {
>  	struct sys_reg_params params;
> -	u32 hsr = kvm_vcpu_get_hsr(vcpu);
> +	u32 hsr = kvm_vcpu_get_esr(vcpu);
>  	int Rt = kvm_vcpu_sys_get_rt(vcpu);
>  	int Rt2 = (hsr >> 10) & 0x1f;
>  
> @@ -2271,7 +2271,7 @@ static int kvm_handle_cp_32(struct kvm_vcpu *vcpu,
>  			    size_t nr_specific)
>  {
>  	struct sys_reg_params params;
> -	u32 hsr = kvm_vcpu_get_hsr(vcpu);
> +	u32 hsr = kvm_vcpu_get_esr(vcpu);
>  	int Rt  = kvm_vcpu_sys_get_rt(vcpu);
>  
>  	params.is_aarch32 = true;
> @@ -2387,7 +2387,7 @@ static void reset_sys_reg_descs(struct kvm_vcpu *vcpu,
>  int kvm_handle_sys_reg(struct kvm_vcpu *vcpu, struct kvm_run *run)
>  {
>  	struct sys_reg_params params;
> -	unsigned long esr = kvm_vcpu_get_hsr(vcpu);
> +	unsigned long esr = kvm_vcpu_get_esr(vcpu);
>  	int Rt = kvm_vcpu_sys_get_rt(vcpu);
>  	int ret;
>  
> diff --git a/virt/kvm/arm/hyp/aarch32.c b/virt/kvm/arm/hyp/aarch32.c
> index d31f267961e7..864b477e660a 100644
> --- a/virt/kvm/arm/hyp/aarch32.c
> +++ b/virt/kvm/arm/hyp/aarch32.c
> @@ -51,7 +51,7 @@ bool __hyp_text kvm_condition_valid32(const struct kvm_vcpu *vcpu)
>  	int cond;
>  
>  	/* Top two bits non-zero?  Unconditional. */
> -	if (kvm_vcpu_get_hsr(vcpu) >> 30)
> +	if (kvm_vcpu_get_esr(vcpu) >> 30)
>  		return true;
>  
>  	/* Is condition field valid? */
> diff --git a/virt/kvm/arm/hyp/vgic-v3-sr.c b/virt/kvm/arm/hyp/vgic-v3-sr.c
> index ccf1fde9836c..8a7a14ec9120 100644
> --- a/virt/kvm/arm/hyp/vgic-v3-sr.c
> +++ b/virt/kvm/arm/hyp/vgic-v3-sr.c
> @@ -441,7 +441,7 @@ static int __hyp_text __vgic_v3_bpr_min(void)
>  
>  static int __hyp_text __vgic_v3_get_group(struct kvm_vcpu *vcpu)
>  {
> -	u32 esr = kvm_vcpu_get_hsr(vcpu);
> +	u32 esr = kvm_vcpu_get_esr(vcpu);
>  	u8 crm = (esr & ESR_ELx_SYS64_ISS_CRM_MASK) >> ESR_ELx_SYS64_ISS_CRM_SHIFT;
>  
>  	return crm != 8;
> @@ -1007,7 +1007,7 @@ int __hyp_text __vgic_v3_perform_cpuif_access(struct kvm_vcpu *vcpu)
>  	bool is_read;
>  	u32 sysreg;
>  
> -	esr = kvm_vcpu_get_hsr(vcpu);
> +	esr = kvm_vcpu_get_esr(vcpu);
>  	if (vcpu_mode_is_32bit(vcpu)) {
>  		if (!kvm_condition_valid(vcpu)) {
>  			__kvm_skip_instr(vcpu);
> diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
> index e3b9ee268823..5da0d0e7519b 100644
> --- a/virt/kvm/arm/mmu.c
> +++ b/virt/kvm/arm/mmu.c
> @@ -1922,7 +1922,7 @@ int kvm_handle_guest_abort(struct kvm_vcpu *vcpu, struct kvm_run *run)
>  		 * For RAS the host kernel may handle this abort.
>  		 * There is no need to pass the error into the guest.
>  		 */
> -		if (!kvm_handle_guest_sea(fault_ipa, kvm_vcpu_get_hsr(vcpu)))
> +		if (!kvm_handle_guest_sea(fault_ipa, kvm_vcpu_get_esr(vcpu)))
>  			return 1;
>  
>  		if (unlikely(!is_iabt)) {
> @@ -1931,7 +1931,7 @@ int kvm_handle_guest_abort(struct kvm_vcpu *vcpu, struct kvm_run *run)
>  		}
>  	}
>  
> -	trace_kvm_guest_fault(*vcpu_pc(vcpu), kvm_vcpu_get_hsr(vcpu),
> +	trace_kvm_guest_fault(*vcpu_pc(vcpu), kvm_vcpu_get_esr(vcpu),
>  			      kvm_vcpu_get_hfar(vcpu), fault_ipa);
>  
>  	/* Check the stage-2 fault is trans. fault or write fault */
> @@ -1940,7 +1940,7 @@ int kvm_handle_guest_abort(struct kvm_vcpu *vcpu, struct kvm_run *run)
>  		kvm_err("Unsupported FSC: EC=%#x xFSC=%#lx ESR_EL2=%#lx\n",
>  			kvm_vcpu_trap_get_class(vcpu),
>  			(unsigned long)kvm_vcpu_trap_get_fault(vcpu),
> -			(unsigned long)kvm_vcpu_get_hsr(vcpu));
> +			(unsigned long)kvm_vcpu_get_esr(vcpu));
>  		return -EFAULT;
>  	}
>  
> -- 
> 2.23.0
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH v7 0/3] perf arm-spe: Add support for synthetic events
From: Leo Yan @ 2020-05-26 10:43 UTC (permalink / raw)
  To: Will Deacon
  Cc: Mark Rutland, Al Grant, Mathieu Poirier, Peter Zijlstra,
	linux-kernel, Arnaldo Carvalho de Melo, Alexander Shishkin,
	Ingo Molnar, James Clark, Namhyung Kim, Jiri Olsa,
	linux-arm-kernel, Mike Leach
In-Reply-To: <20200526102602.GA27166@willie-the-truck>

Hi Will,

On Tue, May 26, 2020 at 11:26:03AM +0100, Will Deacon wrote:
> On Fri, May 22, 2020 at 11:09:19AM +0800, Leo Yan wrote:
> > On Mon, May 04, 2020 at 07:56:22PM +0800, Leo Yan wrote:
> > > This patch set is to support synthetic events with enabling Arm SPE
> > > decoder.  Since before Xiaojun Tan (Hisilicon) and James Clark (Arm)
> > > have contributed much for this task, so this patch set is based on their
> > > privous work and polish for the version 7.
> > > 
> > > The main work in this version is to polished the core patch "perf
> > > arm-spe: Support synthetic events", e.g. rewrite the code to calculate
> > > ip, packet generation for multiple types (L1 data cache, Last level
> > > cache, TLB, remote access, etc).  It also heavily refactors code for
> > > data structure and program flow, which removed unused fields in
> > > structure and polished the program flow to achieve neat code as
> > > possible.
> > > 
> > > This patch set has been checked with checkpatch.pl, though it leaves
> > > several warnings, but these warnings are delibarately kept after
> > > reviewing.  Some warnings ask to add maintainer (so far it's not
> > > necessary), and some warnings complaint for patch 02 "perf auxtrace:
> > > Add four itrace options" for the text format, since need to keep the
> > > consistency with the same code format in the source code, this is why
> > > this patch doesn't get rid of checkpatch warnings.
> > 
> > Gentle ping ...
> > 
> > It would be appreciate if can get some review for this patch set.
> 
> I was hoping that James Clark would have a look, since he was the last
> person to go near the userspace side of SPE.

Yes, I have offline synced with James and James has verified this
patch set at his side.

I don't want to rush to ask Arnaldo to merge patches, so just
want to get wider reviewing if possible; otherwise, I will rebase this
patch set and resend to ML.

Thanks,
Leo

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH RFCv2 5/9] kvm/arm64: Replace hsr with esr
From: Mark Rutland @ 2020-05-26 10:45 UTC (permalink / raw)
  To: Gavin Shan
  Cc: aarcange, drjones, suzuki.poulose, catalin.marinas, linux-kernel,
	eric.auger, james.morse, shan.gavin, maz, will, kvmarm,
	linux-arm-kernel
In-Reply-To: <20200508032919.52147-6-gshan@redhat.com>

On Fri, May 08, 2020 at 01:29:15PM +1000, Gavin Shan wrote:
> This replace the variable names to make them self-explaining. The
> tracepoint isn't changed accordingly because they're part of ABI:
> 
>    * @hsr to @esr
>    * @hsr_ec to @ec
>    * Use kvm_vcpu_trap_get_class() helper if possible
> 
> Signed-off-by: Gavin Shan <gshan@redhat.com>

As with patch 3, I think this cleanup makes sense independent from the
rest of the series, and I think it'd make sense to bundle all the
patches renaming hsr -> esr, and send those as a preparatory series.

Thanks,
Mark.

> ---
>  arch/arm64/kvm/handle_exit.c | 28 ++++++++++++++--------------
>  arch/arm64/kvm/hyp/switch.c  |  9 ++++-----
>  arch/arm64/kvm/sys_regs.c    | 30 +++++++++++++++---------------
>  3 files changed, 33 insertions(+), 34 deletions(-)
> 
> diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
> index 00858db82a64..e3b3dcd5b811 100644
> --- a/arch/arm64/kvm/handle_exit.c
> +++ b/arch/arm64/kvm/handle_exit.c
> @@ -123,13 +123,13 @@ static int kvm_handle_wfx(struct kvm_vcpu *vcpu, struct kvm_run *run)
>   */
>  static int kvm_handle_guest_debug(struct kvm_vcpu *vcpu, struct kvm_run *run)
>  {
> -	u32 hsr = kvm_vcpu_get_esr(vcpu);
> +	u32 esr = kvm_vcpu_get_esr(vcpu);
>  	int ret = 0;
>  
>  	run->exit_reason = KVM_EXIT_DEBUG;
> -	run->debug.arch.hsr = hsr;
> +	run->debug.arch.hsr = esr;
>  
> -	switch (ESR_ELx_EC(hsr)) {
> +	switch (kvm_vcpu_trap_get_class(esr)) {
>  	case ESR_ELx_EC_WATCHPT_LOW:
>  		run->debug.arch.far = vcpu->arch.fault.far_el2;
>  		/* fall through */
> @@ -139,8 +139,8 @@ static int kvm_handle_guest_debug(struct kvm_vcpu *vcpu, struct kvm_run *run)
>  	case ESR_ELx_EC_BRK64:
>  		break;
>  	default:
> -		kvm_err("%s: un-handled case hsr: %#08x\n",
> -			__func__, (unsigned int) hsr);
> +		kvm_err("%s: un-handled case esr: %#08x\n",
> +			__func__, (unsigned int)esr);
>  		ret = -1;
>  		break;
>  	}
> @@ -150,10 +150,10 @@ static int kvm_handle_guest_debug(struct kvm_vcpu *vcpu, struct kvm_run *run)
>  
>  static int kvm_handle_unknown_ec(struct kvm_vcpu *vcpu, struct kvm_run *run)
>  {
> -	u32 hsr = kvm_vcpu_get_esr(vcpu);
> +	u32 esr = kvm_vcpu_get_esr(vcpu);
>  
> -	kvm_pr_unimpl("Unknown exception class: hsr: %#08x -- %s\n",
> -		      hsr, esr_get_class_string(hsr));
> +	kvm_pr_unimpl("Unknown exception class: esr: %#08x -- %s\n",
> +		      esr, esr_get_class_string(esr));
>  
>  	kvm_inject_undefined(vcpu);
>  	return 1;
> @@ -230,10 +230,10 @@ static exit_handle_fn arm_exit_handlers[] = {
>  
>  static exit_handle_fn kvm_get_exit_handler(struct kvm_vcpu *vcpu)
>  {
> -	u32 hsr = kvm_vcpu_get_esr(vcpu);
> -	u8 hsr_ec = ESR_ELx_EC(hsr);
> +	u32 esr = kvm_vcpu_get_esr(vcpu);
> +	u8 ec = kvm_vcpu_trap_get_class(esr);
>  
> -	return arm_exit_handlers[hsr_ec];
> +	return arm_exit_handlers[ec];
>  }
>  
>  /*
> @@ -273,15 +273,15 @@ int handle_exit(struct kvm_vcpu *vcpu, struct kvm_run *run,
>  {
>  	if (ARM_SERROR_PENDING(exception_index)) {
>  		u32 esr = kvm_vcpu_get_esr(vcpu);
> -		u8 hsr_ec = ESR_ELx_EC(esr);
> +		u8 ec = kvm_vcpu_trap_get_class(esr);
>  
>  		/*
>  		 * HVC/SMC already have an adjusted PC, which we need
>  		 * to correct in order to return to after having
>  		 * injected the SError.
>  		 */
> -		if (hsr_ec == ESR_ELx_EC_HVC32 || hsr_ec == ESR_ELx_EC_HVC64 ||
> -		    hsr_ec == ESR_ELx_EC_SMC32 || hsr_ec == ESR_ELx_EC_SMC64) {
> +		if (ec == ESR_ELx_EC_HVC32 || ec == ESR_ELx_EC_HVC64 ||
> +		    ec == ESR_ELx_EC_SMC32 || ec == ESR_ELx_EC_SMC64) {
>  			u32 adj =  kvm_vcpu_trap_il_is32bit(esr) ? 4 : 2;
>  			*vcpu_pc(vcpu) -= adj;
>  		}
> diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
> index 369f22f49f3d..7bf4840bf90e 100644
> --- a/arch/arm64/kvm/hyp/switch.c
> +++ b/arch/arm64/kvm/hyp/switch.c
> @@ -356,8 +356,8 @@ static bool __hyp_text __populate_fault_info(struct kvm_vcpu *vcpu)
>  static bool __hyp_text __hyp_handle_fpsimd(struct kvm_vcpu *vcpu)
>  {
>  	u32 esr = kvm_vcpu_get_esr(vcpu);
> +	u8 ec = kvm_vcpu_trap_get_class(esr);
>  	bool vhe, sve_guest, sve_host;
> -	u8 hsr_ec;
>  
>  	if (!system_supports_fpsimd())
>  		return false;
> @@ -372,14 +372,13 @@ static bool __hyp_text __hyp_handle_fpsimd(struct kvm_vcpu *vcpu)
>  		vhe = has_vhe();
>  	}
>  
> -	hsr_ec = kvm_vcpu_trap_get_class(esr);
> -	if (hsr_ec != ESR_ELx_EC_FP_ASIMD &&
> -	    hsr_ec != ESR_ELx_EC_SVE)
> +	if (ec != ESR_ELx_EC_FP_ASIMD &&
> +	    ec != ESR_ELx_EC_SVE)
>  		return false;
>  
>  	/* Don't handle SVE traps for non-SVE vcpus here: */
>  	if (!sve_guest)
> -		if (hsr_ec != ESR_ELx_EC_FP_ASIMD)
> +		if (ec != ESR_ELx_EC_FP_ASIMD)
>  			return false;
>  
>  	/* Valid trap.  Switch the context: */
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index 012fff834a4b..58f81ab519af 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -2182,10 +2182,10 @@ static void unhandled_cp_access(struct kvm_vcpu *vcpu,
>  				struct sys_reg_params *params)
>  {
>  	u32 esr = kvm_vcpu_get_esr(vcpu);
> -	u8 hsr_ec = kvm_vcpu_trap_get_class(esr);
> +	u8 ec = kvm_vcpu_trap_get_class(esr);
>  	int cp = -1;
>  
> -	switch(hsr_ec) {
> +	switch (ec) {
>  	case ESR_ELx_EC_CP15_32:
>  	case ESR_ELx_EC_CP15_64:
>  		cp = 15;
> @@ -2216,17 +2216,17 @@ static int kvm_handle_cp_64(struct kvm_vcpu *vcpu,
>  			    size_t nr_specific)
>  {
>  	struct sys_reg_params params;
> -	u32 hsr = kvm_vcpu_get_esr(vcpu);
> -	int Rt = kvm_vcpu_sys_get_rt(hsr);
> -	int Rt2 = (hsr >> 10) & 0x1f;
> +	u32 esr = kvm_vcpu_get_esr(vcpu);
> +	int Rt = kvm_vcpu_sys_get_rt(esr);
> +	int Rt2 = (esr >> 10) & 0x1f;
>  
>  	params.is_aarch32 = true;
>  	params.is_32bit = false;
> -	params.CRm = (hsr >> 1) & 0xf;
> -	params.is_write = ((hsr & 1) == 0);
> +	params.CRm = (esr >> 1) & 0xf;
> +	params.is_write = ((esr & 1) == 0);
>  
>  	params.Op0 = 0;
> -	params.Op1 = (hsr >> 16) & 0xf;
> +	params.Op1 = (esr >> 16) & 0xf;
>  	params.Op2 = 0;
>  	params.CRn = 0;
>  
> @@ -2273,18 +2273,18 @@ static int kvm_handle_cp_32(struct kvm_vcpu *vcpu,
>  			    size_t nr_specific)
>  {
>  	struct sys_reg_params params;
> -	u32 hsr = kvm_vcpu_get_esr(vcpu);
> -	int Rt  = kvm_vcpu_sys_get_rt(hsr);
> +	u32 esr = kvm_vcpu_get_esr(vcpu);
> +	int Rt = kvm_vcpu_sys_get_rt(esr);
>  
>  	params.is_aarch32 = true;
>  	params.is_32bit = true;
> -	params.CRm = (hsr >> 1) & 0xf;
> +	params.CRm = (esr >> 1) & 0xf;
>  	params.regval = vcpu_get_reg(vcpu, Rt);
> -	params.is_write = ((hsr & 1) == 0);
> -	params.CRn = (hsr >> 10) & 0xf;
> +	params.is_write = ((esr & 1) == 0);
> +	params.CRn = (esr >> 10) & 0xf;
>  	params.Op0 = 0;
> -	params.Op1 = (hsr >> 14) & 0x7;
> -	params.Op2 = (hsr >> 17) & 0x7;
> +	params.Op1 = (esr >> 14) & 0x7;
> +	params.Op2 = (esr >> 17) & 0x7;
>  
>  	if (!emulate_cp(vcpu, &params, target_specific, nr_specific) ||
>  	    !emulate_cp(vcpu, &params, global, nr_global)) {
> -- 
> 2.23.0
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH v4 0/5] Update CoreSight infrastructure to select a default sink.
From: Mike Leach @ 2020-05-26 10:46 UTC (permalink / raw)
  To: linux-arm-kernel, coresight, mathieu.poirier
  Cc: Mike Leach, acme, suzuki.poulose

This patchset provides a proposed infrastructure to allow for the automatic
selection of a sink during CoreSight tracing operations.

Currently starting tracing using perf requires a sink selection on the
command line:-

sudo ./perf record -e cs_etm/@tmc_etr0/ --per-thread uname -a

After this set (and the follow-up perf change set) the infrastructure will
be able to select a default sink:-

sudo ./perf record -e cs_etm// --per-thread uname -a

This matches with the default operation provided with perf and intelpt.

Where no sink is specified at the start of a trace session, the CoreSight
system will walk the connection graph from the source ETM, to find a
suitable sink using the first encountered highest priority device.

The CoreSight infrastructure is updated to define sink sub_types to
differentiate between sinks with built in buffers (ETB / ETF) - BUFFER
type, and those that use system memory (ETR) - SYSMEM - types.

SYSMEM types are considered higher priority.

When two sinks are found of equal priority, then the closest sink to the
source in terms of connection nodes is chosen.

The automatic sink selection will also operate if an ETM is enabled using
sysfs commands, and no sink is currently enabled.

Applies to Linux coresight/next branch

Changes since v3:
1) Removed RFC designation and distributed to wider audience.
2) Split set into CoreSight driver code (this set), and perf user runtime set.
3) Minor cosmetic changes.

Mike Leach (5):
  coresight: Fix comment in main header file.
  coresight: Add default sink selection to CoreSight base
  coresight: tmc: Update sink types for default selection.
  coresight: etm: perf: Add default sink selection to etm perf
  coresight: sysfs: Allow select default sink on source enable.

 .../hwtracing/coresight/coresight-etm-perf.c  |  17 +-
 drivers/hwtracing/coresight/coresight-priv.h  |   2 +
 drivers/hwtracing/coresight/coresight-tmc.c   |   3 +-
 drivers/hwtracing/coresight/coresight.c       | 147 +++++++++++++++++-
 include/linux/coresight.h                     |   6 +-
 5 files changed, 168 insertions(+), 7 deletions(-)

-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH v4 1/5] coresight: Fix comment in main header file.
From: Mike Leach @ 2020-05-26 10:46 UTC (permalink / raw)
  To: linux-arm-kernel, coresight, mathieu.poirier
  Cc: Mike Leach, acme, suzuki.poulose
In-Reply-To: <20200526104642.9526-1-mike.leach@linaro.org>

Comment for an elemnt in the coresight_device structure appears to have
been corrupted & makes no sense. Fix this before making further changes.

Signed-off-by: Mike Leach <mike.leach@linaro.org>
---
 include/linux/coresight.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/include/linux/coresight.h b/include/linux/coresight.h
index e3e9f0e3a878..84dc695e87d4 100644
--- a/include/linux/coresight.h
+++ b/include/linux/coresight.h
@@ -179,7 +179,8 @@ struct coresight_sysfs_link {
  * @enable:	'true' if component is currently part of an active path.
  * @activated:	'true' only if a _sink_ has been activated.  A sink can be
  *		activated but not yet enabled.  Enabling for a _sink_
- *		appens when a source has been selected for that it.
+ *		happens when a source has been selected and a path is enabled
+ *		from source to that sink.
  * @ea:		Device attribute for sink representation under PMU directory.
  * @ect_dev:	Associated cross trigger device. Not part of the trace data
  *		path or connections.
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [PATCH v4 2/5] coresight: Add default sink selection to CoreSight base
From: Mike Leach @ 2020-05-26 10:46 UTC (permalink / raw)
  To: linux-arm-kernel, coresight, mathieu.poirier
  Cc: Mike Leach, acme, suzuki.poulose
In-Reply-To: <20200526104642.9526-1-mike.leach@linaro.org>

Adds a method to select a suitable sink connected to a given source.

In cases where no sink is defined, the coresight_find_default_sink
routine can search from a given source, through the child connections
until a suitable sink is found.

The suitability is defined in by the sink coresight_dev_subtype on the
CoreSight device, and the distance from the source by counting
connections.

Higher value subtype is preferred - where these are equal, shorter
distance from source is used as a tie-break.

This allows for default sink to be discovered were none is specified
(e.g. perf command line)

Signed-off-by: Mike Leach <mike.leach@linaro.org>
---
 drivers/hwtracing/coresight/coresight-priv.h |   2 +
 drivers/hwtracing/coresight/coresight.c      | 136 +++++++++++++++++++
 include/linux/coresight.h                    |   3 +
 3 files changed, 141 insertions(+)

diff --git a/drivers/hwtracing/coresight/coresight-priv.h b/drivers/hwtracing/coresight/coresight-priv.h
index 36c943ae94d5..f2dc625ea585 100644
--- a/drivers/hwtracing/coresight/coresight-priv.h
+++ b/drivers/hwtracing/coresight/coresight-priv.h
@@ -150,6 +150,8 @@ int coresight_enable_path(struct list_head *path, u32 mode, void *sink_data);
 struct coresight_device *coresight_get_sink(struct list_head *path);
 struct coresight_device *coresight_get_enabled_sink(bool reset);
 struct coresight_device *coresight_get_sink_by_id(u32 id);
+struct coresight_device *
+coresight_find_default_sink(struct coresight_device *csdev);
 struct list_head *coresight_build_path(struct coresight_device *csdev,
 				       struct coresight_device *sink);
 void coresight_release_path(struct list_head *path);
diff --git a/drivers/hwtracing/coresight/coresight.c b/drivers/hwtracing/coresight/coresight.c
index f3efbb3b2b4d..7632d060e25d 100644
--- a/drivers/hwtracing/coresight/coresight.c
+++ b/drivers/hwtracing/coresight/coresight.c
@@ -769,6 +769,142 @@ void coresight_release_path(struct list_head *path)
 	path = NULL;
 }
 
+/* return true if the device is a suitable type for a default sink */
+static inline bool coresight_is_def_sink_type(struct coresight_device *csdev)
+{
+	/* sink & correct subtype */
+	if (((csdev->type == CORESIGHT_DEV_TYPE_SINK) ||
+	     (csdev->type == CORESIGHT_DEV_TYPE_LINKSINK)) &&
+	    (csdev->subtype.sink_subtype >= CORESIGHT_DEV_SUBTYPE_SINK_BUFFER))
+		return true;
+	return false;
+}
+
+/**
+ * coresight_select_best_sink - return the best sink for use as default from
+ * the two provided.
+ *
+ * @sink:	current best sink.
+ * @depth:      search depth where current sink was found.
+ * @new_sink:	new sink for comparison with current sink.
+ * @new_depth:  search depth where new sink was found.
+ *
+ * Sinks prioritised according to coresight_dev_subtype_sink, with only
+ * subtypes CORESIGHT_DEV_SUBTYPE_SINK_BUFFER or higher being used.
+ *
+ * Where two sinks of equal priority are found, the sink closest to the
+ * source is used (smallest search depth).
+ *
+ * return @new_sink & update @depth if better than @sink, else return @sink.
+ */
+static struct coresight_device *
+coresight_select_best_sink(struct coresight_device *sink, int *depth,
+			   struct coresight_device *new_sink, int new_depth)
+{
+	bool update = false;
+
+	if (!sink) {
+		/* first found at this level */
+		update = true;
+	} else if (new_sink->subtype.sink_subtype >
+		   sink->subtype.sink_subtype) {
+		/* found better sink */
+		update = true;
+	} else if ((new_sink->subtype.sink_subtype ==
+		    sink->subtype.sink_subtype) &&
+		   (*depth > new_depth)) {
+		/* found same but closer sink */
+		update = true;
+	}
+
+	if (update)
+		*depth = new_depth;
+	return update ? new_sink : sink;
+}
+
+/**
+ * coresight_find_sink - recursive function to walk trace connections from
+ * source to find a suitable default sink.
+ *
+ * @csdev: source / current device to check.
+ * @depth: [in] search depth of calling dev, [out] depth of found sink.
+ *
+ * This will walk the connection path from a source (ETM) till a suitable
+ * sink is encountered and return that sink to the original caller.
+ *
+ * If current device is a plain sink return that & depth, otherwise recursively
+ * call child connections looking for a sink. Select best possible using
+ * coresight_select_best_sink.
+ *
+ * return best sink found, or NULL if not found at this node or child nodes.
+ */
+static struct coresight_device *
+coresight_find_sink(struct coresight_device *csdev, int *depth)
+{
+	int i, curr_depth = *depth + 1, found_depth = 0;
+	struct coresight_device *found_sink = NULL;
+
+	if (coresight_is_def_sink_type(csdev)) {
+		found_depth = curr_depth;
+		found_sink = csdev;
+		if (csdev->type == CORESIGHT_DEV_TYPE_SINK)
+			goto return_def_sink;
+		/* look past LINKSINK for something better */
+	}
+
+	/*
+	 * Not a sink we want - or possible child sink may be better.
+	 * recursively explore each port found on this element.
+	 */
+	for (i = 0; i < csdev->pdata->nr_outport; i++) {
+		struct coresight_device *child_dev, *sink = NULL;
+		int child_depth = curr_depth;
+
+		child_dev = csdev->pdata->conns[i].child_dev;
+		if (child_dev)
+			sink = coresight_find_sink(child_dev, &child_depth);
+
+		if (sink)
+			found_sink = coresight_select_best_sink(found_sink,
+								&found_depth,
+								sink,
+								child_depth);
+	}
+
+return_def_sink:
+	/* return found sink and depth */
+	if (found_sink)
+		*depth = found_depth;
+	return found_sink;
+}
+
+/**
+ * coresight_find_default_sink: Find a sink suitable for use as a
+ * default sink.
+ *
+ * @csdev: starting source to find a connected sink.
+ *
+ * Walks connections graph looking for a suitable sink to enable for the
+ * supplied source. Uses CoreSight device subtypes and distance from source
+ * to select the best sink.
+ *
+ * If a sink is found, then the default sink for this device is set and
+ * will be automatically used in future.
+ *
+ * Used in cases where the CoreSight user (perf / sysfs) has not selected a
+ * sink.
+ */
+struct coresight_device *
+coresight_find_default_sink(struct coresight_device *csdev)
+{
+	int depth = 0;
+
+	/* look for a default sink if we have not found for this device */
+	if (!csdev->def_sink)
+		csdev->def_sink = coresight_find_sink(csdev, &depth);
+	return csdev->def_sink;
+}
+
 /** coresight_validate_source - make sure a source has the right credentials
  *  @csdev:	the device structure for a source.
  *  @function:	the function this was called from.
diff --git a/include/linux/coresight.h b/include/linux/coresight.h
index 84dc695e87d4..58fffdecdbfd 100644
--- a/include/linux/coresight.h
+++ b/include/linux/coresight.h
@@ -48,6 +48,7 @@ enum coresight_dev_subtype_sink {
 	CORESIGHT_DEV_SUBTYPE_SINK_NONE,
 	CORESIGHT_DEV_SUBTYPE_SINK_PORT,
 	CORESIGHT_DEV_SUBTYPE_SINK_BUFFER,
+	CORESIGHT_DEV_SUBTYPE_SINK_SYSMEM,
 };
 
 enum coresight_dev_subtype_link {
@@ -182,6 +183,7 @@ struct coresight_sysfs_link {
  *		happens when a source has been selected and a path is enabled
  *		from source to that sink.
  * @ea:		Device attribute for sink representation under PMU directory.
+ * @def_sink:	cached reference to default sink found for this device.
  * @ect_dev:	Associated cross trigger device. Not part of the trace data
  *		path or connections.
  * @nr_links:   number of sysfs links created to other components from this
@@ -200,6 +202,7 @@ struct coresight_device {
 	/* sink specific fields */
 	bool activated;	/* true only if a sink is part of a path */
 	struct dev_ext_attribute *ea;
+	struct coresight_device *def_sink;
 	/* cross trigger handling */
 	struct coresight_device *ect_dev;
 	/* sysfs links between components */
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [PATCH v4 3/5] coresight: tmc: Update sink types for default selection.
From: Mike Leach @ 2020-05-26 10:46 UTC (permalink / raw)
  To: linux-arm-kernel, coresight, mathieu.poirier
  Cc: Mike Leach, acme, suzuki.poulose
In-Reply-To: <20200526104642.9526-1-mike.leach@linaro.org>

An additional sink subtype is added to differentiate ETB/ETF buffer
sinks and ETR type system memory sinks.

This allows the prioritised selection of default sinks.

Signed-off-by: Mike Leach <mike.leach@linaro.org>
---
 drivers/hwtracing/coresight/coresight-tmc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/hwtracing/coresight/coresight-tmc.c b/drivers/hwtracing/coresight/coresight-tmc.c
index 39fba1d16e6e..0d2eb7e0e1bb 100644
--- a/drivers/hwtracing/coresight/coresight-tmc.c
+++ b/drivers/hwtracing/coresight/coresight-tmc.c
@@ -484,7 +484,7 @@ static int tmc_probe(struct amba_device *adev, const struct amba_id *id)
 		break;
 	case TMC_CONFIG_TYPE_ETR:
 		desc.type = CORESIGHT_DEV_TYPE_SINK;
-		desc.subtype.sink_subtype = CORESIGHT_DEV_SUBTYPE_SINK_BUFFER;
+		desc.subtype.sink_subtype = CORESIGHT_DEV_SUBTYPE_SINK_SYSMEM;
 		desc.ops = &tmc_etr_cs_ops;
 		ret = tmc_etr_setup_caps(dev, devid,
 					 coresight_get_uci_data(id));
@@ -496,6 +496,7 @@ static int tmc_probe(struct amba_device *adev, const struct amba_id *id)
 		break;
 	case TMC_CONFIG_TYPE_ETF:
 		desc.type = CORESIGHT_DEV_TYPE_LINKSINK;
+		desc.subtype.sink_subtype = CORESIGHT_DEV_SUBTYPE_SINK_BUFFER;
 		desc.subtype.link_subtype = CORESIGHT_DEV_SUBTYPE_LINK_FIFO;
 		desc.ops = &tmc_etf_cs_ops;
 		dev_list = &etf_devs;
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [PATCH v4 5/5] coresight: sysfs: Allow select default sink on source enable.
From: Mike Leach @ 2020-05-26 10:46 UTC (permalink / raw)
  To: linux-arm-kernel, coresight, mathieu.poirier
  Cc: Mike Leach, acme, suzuki.poulose
In-Reply-To: <20200526104642.9526-1-mike.leach@linaro.org>

When enabling a trace source using sysfs, allow the CoreSight system to
auto-select a default sink if none has been enabled by the user.

Uses the sink select algorithm that uses the default select priorities
set when sinks are registered with the system. At present this will
prefer ETR over ETB / ETF.

Signed-off-by: Mike Leach <mike.leach@linaro.org>
---
 drivers/hwtracing/coresight/coresight.c | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight.c b/drivers/hwtracing/coresight/coresight.c
index 7632d060e25d..bd1a52a65d00 100644
--- a/drivers/hwtracing/coresight/coresight.c
+++ b/drivers/hwtracing/coresight/coresight.c
@@ -965,8 +965,15 @@ int coresight_enable(struct coresight_device *csdev)
 	 */
 	sink = coresight_get_enabled_sink(false);
 	if (!sink) {
-		ret = -EINVAL;
-		goto out;
+		/* look for a default sink if nothing enabled */
+		sink = coresight_find_default_sink(csdev);
+		if (!sink) {
+			ret = -EINVAL;
+			goto out;
+		}
+		/* mark the default as enabled */
+		sink->activated = true;
+		dev_info(&sink->dev, "Enabled default sink.");
 	}
 
 	path = coresight_build_path(csdev, sink);
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [PATCH v4 4/5] coresight: etm: perf: Add default sink selection to etm perf
From: Mike Leach @ 2020-05-26 10:46 UTC (permalink / raw)
  To: linux-arm-kernel, coresight, mathieu.poirier
  Cc: Mike Leach, acme, suzuki.poulose
In-Reply-To: <20200526104642.9526-1-mike.leach@linaro.org>

Add default sink selection to the perf trace handling in the etm driver.
Uses the select default sink infrastructure to select a sink for the perf
session, if no other sink is specified.

Signed-off-by: Mike Leach <mike.leach@linaro.org>
---
 .../hwtracing/coresight/coresight-etm-perf.c    | 17 ++++++++++++++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c b/drivers/hwtracing/coresight/coresight-etm-perf.c
index 84f1dcb69827..1a3169e69bb1 100644
--- a/drivers/hwtracing/coresight/coresight-etm-perf.c
+++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
@@ -226,9 +226,6 @@ static void *etm_setup_aux(struct perf_event *event, void **pages,
 		sink = coresight_get_enabled_sink(true);
 	}
 
-	if (!sink)
-		goto err;
-
 	mask = &event_data->mask;
 
 	/*
@@ -253,6 +250,16 @@ static void *etm_setup_aux(struct perf_event *event, void **pages,
 			continue;
 		}
 
+		/*
+		 * No sink provided - look for a default sink for one of the
+		 * devices. At present we only support topology where all CPUs
+		 * use the same sink [N:1], so only need to find one sink. The
+		 * coresight_build_path later will remove any CPU that does not
+		 * attach to the sink, or if we have not found a sink.
+		 */
+		if (!sink)
+			sink = coresight_find_default_sink(csdev);
+
 		/*
 		 * Building a path doesn't enable it, it simply builds a
 		 * list of devices from source to sink that can be
@@ -267,6 +274,10 @@ static void *etm_setup_aux(struct perf_event *event, void **pages,
 		*etm_event_cpu_path_ptr(event_data, cpu) = path;
 	}
 
+	/* no sink found for any CPU - cannot trace */
+	if (!sink)
+		goto err;
+
 	/* If we don't have any CPUs ready for tracing, abort */
 	cpu = cpumask_first(mask);
 	if (cpu >= nr_cpu_ids)
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* Re: [PATCH RFCv2 4/9] kvm/arm64: Detach ESR operator from vCPU struct
From: Mark Rutland @ 2020-05-26 10:51 UTC (permalink / raw)
  To: Gavin Shan
  Cc: aarcange, drjones, suzuki.poulose, catalin.marinas, linux-kernel,
	eric.auger, james.morse, shan.gavin, maz, will, kvmarm,
	linux-arm-kernel
In-Reply-To: <20200508032919.52147-5-gshan@redhat.com>

On Fri, May 08, 2020 at 01:29:14PM +1000, Gavin Shan wrote:
> There are a set of inline functions defined in kvm_emulate.h. Those
> functions reads ESR from vCPU fault information struct and then operate
> on it. So it's tied with vCPU fault information and vCPU struct. It
> limits their usage scope.
> 
> This detaches these functions from the vCPU struct. With this, the
> caller has flexibility on where the ESR is read. It shouldn't cause
> any functional changes.
> 
> Signed-off-by: Gavin Shan <gshan@redhat.com>
> ---
>  arch/arm64/include/asm/kvm_emulate.h     | 83 +++++++++++-------------
>  arch/arm64/kvm/handle_exit.c             | 20 ++++--
>  arch/arm64/kvm/hyp/switch.c              | 24 ++++---
>  arch/arm64/kvm/hyp/vgic-v2-cpuif-proxy.c |  7 +-
>  arch/arm64/kvm/inject_fault.c            |  4 +-
>  arch/arm64/kvm/sys_regs.c                | 12 ++--
>  virt/kvm/arm/arm.c                       |  4 +-
>  virt/kvm/arm/hyp/aarch32.c               |  2 +-
>  virt/kvm/arm/hyp/vgic-v3-sr.c            |  5 +-
>  virt/kvm/arm/mmio.c                      | 27 ++++----
>  virt/kvm/arm/mmu.c                       | 22 ++++---
>  11 files changed, 112 insertions(+), 98 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h
> index bd1a69e7c104..2873bf6dc85e 100644
> --- a/arch/arm64/include/asm/kvm_emulate.h
> +++ b/arch/arm64/include/asm/kvm_emulate.h
> @@ -270,10 +270,8 @@ static __always_inline u32 kvm_vcpu_get_esr(const struct kvm_vcpu *vcpu)
>  	return vcpu->arch.fault.esr_el2;
>  }
>  
> -static __always_inline int kvm_vcpu_get_condition(const struct kvm_vcpu *vcpu)
> +static __always_inline int kvm_vcpu_get_condition(u32 esr)

Given the `vcpu` argument has been removed, it's odd to keep `vcpu` in the
name, rather than `esr`.

e.g. this would make more sense as something like esr_get_condition().

... and if we did something like that, we could move most of the
extraction functions into <asm/esr.h>, and share them with non-KVM code.

Otherwise, do you need to extract all of these for your use-case, or do
you only need a few of the helpers? If you only need a few, it might be
better to only factor those out for now, and keep the existing API in
place with wrappers, e.g. have:

| esr_get_condition(u32 esr) {
| 	... 
| }
| 
| kvm_vcpu_get_condition(const struct kvm_vcpu *vcpu)
| {
| 	return esr_get_condition(kvm_vcpu_get_esr(vcpu));
| }

Thanks,
Mark.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH v4 0/1] perf: cs_etm: Allow no sink on command line.
From: Mike Leach @ 2020-05-26 10:53 UTC (permalink / raw)
  To: linux-arm-kernel, coresight, linux-kernel, acme
  Cc: peterz, mingo, Mike Leach, mathieu.poirier, suzuki.poulose

Currently starting CoreSight tracing using perf requires a sink selection
on the command line:-

sudo ./perf record -e cs_etm/@tmc_etr0/ --per-thread uname -a

Not providing the @<sink> here results in an error and no trace produced.

After this set (alongside the CoreSight change set [1]) the infrastructure
will be able to select a default sink:-

sudo ./perf record -e cs_etm// --per-thread uname -a

This matches with the default operation provided with perf and intelpt.

This patch removes the check that a sink value is provided on the command
line with a NULL value passed to the CoreSight infrastructure if omitted.

Note: If this set is applied to a system without [1], then the effect is
benign as the existing CoreSight infrastructure will detect the error and
refuse to trace.

Applies to Linux coresight/next branch

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2020-May/734854.html

Changes since v3:
1) Removed RFC designation and distributed to wider audience.
2) Split set into perf user runtime (this set), and CoreSight driver code.


Mike Leach (1):
  perf: cs-etm: Allow no CoreSight sink to be specified on command line

 tools/perf/arch/arm/util/cs-etm.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH v4 1/1] perf: cs-etm: Allow no CoreSight sink to be specified on command line
From: Mike Leach @ 2020-05-26 10:53 UTC (permalink / raw)
  To: linux-arm-kernel, coresight, linux-kernel, acme
  Cc: peterz, mingo, Mike Leach, mathieu.poirier, suzuki.poulose
In-Reply-To: <20200526105310.9706-1-mike.leach@linaro.org>

Adjust the handling of the session sink selection to allow no sink to
be selected on the command line. This then forwards the sink selection to
the CoreSight infrastructure which will attempt to select a sink based
on the default sink select priorities.

Signed-off-by: Mike Leach <mike.leach@linaro.org>
---
 tools/perf/arch/arm/util/cs-etm.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/perf/arch/arm/util/cs-etm.c b/tools/perf/arch/arm/util/cs-etm.c
index 941f814820b8..ed9ea2c60f27 100644
--- a/tools/perf/arch/arm/util/cs-etm.c
+++ b/tools/perf/arch/arm/util/cs-etm.c
@@ -242,10 +242,10 @@ static int cs_etm_set_sink_attr(struct perf_pmu *pmu,
 	}
 
 	/*
-	 * No sink was provided on the command line - for _now_ treat
-	 * this as an error.
+	 * No sink was provided on the command line - allow the CoreSight
+	 * system to look for a default
 	 */
-	return ret;
+	return 0;
 }
 
 static int cs_etm_recording_options(struct auxtrace_record *itr,
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* Re: [PATCH RFCv2 6/9] kvm/arm64: Export kvm_handle_user_mem_abort() with prefault mode
From: Mark Rutland @ 2020-05-26 10:58 UTC (permalink / raw)
  To: Gavin Shan
  Cc: aarcange, drjones, suzuki.poulose, catalin.marinas, linux-kernel,
	eric.auger, james.morse, shan.gavin, maz, will, kvmarm,
	linux-arm-kernel
In-Reply-To: <20200508032919.52147-7-gshan@redhat.com>

On Fri, May 08, 2020 at 01:29:16PM +1000, Gavin Shan wrote:
> This renames user_mem_abort() to kvm_handle_user_mem_abort(), and
> then export it. The function will be used in asynchronous page fault
> to populate a page table entry once the corresponding page is populated
> from the backup device (e.g. swap partition):
> 
>    * Parameter @fault_status is replace by @esr.
>    * The parameters are reorder based on their importance.

It seems like multiple changes are going on here, and it would be
clearer with separate patches.

Passing the ESR rather than the extracted fault status seems fine, but
for clarirty it's be nicer to do this in its own patch.

Why is it necessary to re-order the function parameters? Does that align
with other function prototypes?

What exactly is the `prefault` parameter meant to do? It doesn't do
anything currently, so it'd be better to introduce it later when logic
using it is instroduced, or where callers will pass distinct values.

Thanks,
Mark.

> 
> This shouldn't cause any functional changes.
> 
> Signed-off-by: Gavin Shan <gshan@redhat.com>
> ---
>  arch/arm64/include/asm/kvm_host.h |  4 ++++
>  virt/kvm/arm/mmu.c                | 14 ++++++++------
>  2 files changed, 12 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index 32c8a675e5a4..f77c706777ec 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -437,6 +437,10 @@ int __kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu,
>  			      struct kvm_vcpu_events *events);
>  
>  #define KVM_ARCH_WANT_MMU_NOTIFIER
> +int kvm_handle_user_mem_abort(struct kvm_vcpu *vcpu, unsigned int esr,
> +			      struct kvm_memory_slot *memslot,
> +			      phys_addr_t fault_ipa, unsigned long hva,
> +			      bool prefault);
>  int kvm_unmap_hva_range(struct kvm *kvm,
>  			unsigned long start, unsigned long end);
>  int kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte);
> diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
> index e462e0368fd9..95aaabb2b1fc 100644
> --- a/virt/kvm/arm/mmu.c
> +++ b/virt/kvm/arm/mmu.c
> @@ -1656,12 +1656,12 @@ static bool fault_supports_stage2_huge_mapping(struct kvm_memory_slot *memslot,
>  	       (hva & ~(map_size - 1)) + map_size <= uaddr_end;
>  }
>  
> -static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> -			  struct kvm_memory_slot *memslot, unsigned long hva,
> -			  unsigned long fault_status)
> +int kvm_handle_user_mem_abort(struct kvm_vcpu *vcpu, unsigned int esr,
> +			      struct kvm_memory_slot *memslot,
> +			      phys_addr_t fault_ipa, unsigned long hva,
> +			      bool prefault)
>  {
> -	int ret;
> -	u32 esr = kvm_vcpu_get_esr(vcpu);
> +	unsigned int fault_status = kvm_vcpu_trap_get_fault_type(esr);
>  	bool write_fault, writable, force_pte = false;
>  	bool exec_fault, needs_exec;
>  	unsigned long mmu_seq;
> @@ -1674,6 +1674,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>  	pgprot_t mem_type = PAGE_S2;
>  	bool logging_active = memslot_is_logging(memslot);
>  	unsigned long vma_pagesize, flags = 0;
> +	int ret;
>  
>  	write_fault = kvm_is_write_fault(esr);
>  	exec_fault = kvm_vcpu_trap_is_iabt(esr);
> @@ -1995,7 +1996,8 @@ int kvm_handle_guest_abort(struct kvm_vcpu *vcpu, struct kvm_run *run)
>  		goto out_unlock;
>  	}
>  
> -	ret = user_mem_abort(vcpu, fault_ipa, memslot, hva, fault_status);
> +	ret = kvm_handle_user_mem_abort(vcpu, esr, memslot,
> +					fault_ipa, hva, false);
>  	if (ret == 0)
>  		ret = 1;
>  out:
> -- 
> 2.23.0
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox