* Re: [PATCH 5/8] soc: ux500: Switch to use DEVICE_ATTR_RO()
From: Linus Walleij @ 2020-05-25 11:46 UTC (permalink / raw)
To: Sudeep Holla
Cc: Greg Kroah-Hartman, Arnd Bergmann, linux-kernel@vger.kernel.org,
Linux ARM
In-Reply-To: <20200523170859.50003-6-sudeep.holla@arm.com>
On Sat, May 23, 2020 at 7:09 PM Sudeep Holla <sudeep.holla@arm.com> wrote:
> Move device attributes to DEVICE_ATTR_RO() as that would make things
> a lot more "obvious" what is happening over the existing __ATTR usage.
>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
_______________________________________________
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/8] soc: integrator: Use custom soc attribute group instead of device_create_file
From: Linus Walleij @ 2020-05-25 11:46 UTC (permalink / raw)
To: Sudeep Holla
Cc: Greg Kroah-Hartman, Arnd Bergmann, linux-kernel@vger.kernel.org,
Linux ARM
In-Reply-To: <20200523170859.50003-5-sudeep.holla@arm.com>
On Sat, May 23, 2020 at 7:09 PM Sudeep Holla <sudeep.holla@arm.com> wrote:
> Commit c31e73121f4c ("base: soc: Handle custom soc information sysfs
> entries") introduced custom soc attribute group in soc_device_attribute
> structure but there are no users treewide. While trying to understand
> the motivation and tried to use it, it was found lot of existing custom
> attributes can moved to use it instead of device_create_file.
>
> Though most of these never remove/cleanup the custom attribute as they
> never call soc_device_unregister, using these custom attribute group
> eliminate the need for any cleanup as the driver infrastructure will
> take care of that.
>
> Let us remove device_create_file and start using the custom attribute
> group in soc_device_attribute.
>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
_______________________________________________
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/8] soc: integrator: Switch to use DEVICE_ATTR_RO()
From: Linus Walleij @ 2020-05-25 11:45 UTC (permalink / raw)
To: Sudeep Holla
Cc: Greg Kroah-Hartman, Arnd Bergmann, linux-kernel@vger.kernel.org,
Linux ARM
In-Reply-To: <20200523170859.50003-4-sudeep.holla@arm.com>
On Sat, May 23, 2020 at 7:09 PM Sudeep Holla <sudeep.holla@arm.com> wrote:
> Move device attributes to DEVICE_ATTR_RO() as that would make things
> a lot more "obvious" what is happening over the existing __ATTR usage.
>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
_______________________________________________
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 2/8] soc: realview: Use custom soc attribute group instead of device_create_file
From: Linus Walleij @ 2020-05-25 11:45 UTC (permalink / raw)
To: Sudeep Holla
Cc: Greg Kroah-Hartman, Arnd Bergmann, linux-kernel@vger.kernel.org,
Linux ARM
In-Reply-To: <20200523170859.50003-3-sudeep.holla@arm.com>
On Sat, May 23, 2020 at 7:09 PM Sudeep Holla <sudeep.holla@arm.com> wrote:
> Commit c31e73121f4c ("base: soc: Handle custom soc information sysfs
> entries") introduced custom soc attribute group in soc_device_attribute
> structure but there are no users treewide. While trying to understand
> the motivation and tried to use it, it was found lot of existing custom
> attributes can moved to use it instead of device_create_file.
>
> Though most of these never remove/cleanup the custom attribute as they
> never call soc_device_unregister, using these custom attribute group
> eliminate the need for any cleanup as the driver infrastructure will
> take care of that.
>
> Let us remove device_create_file and start using the custom attribute
> group in soc_device_attribute.
>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
_______________________________________________
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/8] soc: realview: Switch to use DEVICE_ATTR_RO()
From: Linus Walleij @ 2020-05-25 11:44 UTC (permalink / raw)
To: Sudeep Holla
Cc: Greg Kroah-Hartman, Arnd Bergmann, linux-kernel@vger.kernel.org,
Linux ARM
In-Reply-To: <20200523170859.50003-2-sudeep.holla@arm.com>
On Sat, May 23, 2020 at 7:09 PM Sudeep Holla <sudeep.holla@arm.com> wrote:
> Move device attributes to DEVICE_ATTR_RO() as that would make things
> a lot more "obvious" what is happening over the existing __ATTR usage.
>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
_______________________________________________
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 v4 3/8] spi: stm32: Add 'SPI_SIMPLEX_RX', 'SPI_3WIRE_RX' support for stm32f4
From: Mark Brown @ 2020-05-25 11:43 UTC (permalink / raw)
To: dillon min
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
p.zabel, Dave Airlie, Michael Turquette, linux-clk, linux-kernel,
open list:DRM PANEL DRIVERS, linux-spi, Stephen Boyd, Rob Herring,
thierry.reding, Maxime Coquelin, Daniel Vetter, Sam Ravnborg,
linux-stm32, Linux ARM, Alexandre Torgue
In-Reply-To: <CAL9mu0+E5R0mDUW3f+aKpfE_457VimS-ow2z_xVOmCfCAMnKuA@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 573 bytes --]
On Sat, May 23, 2020 at 09:35:06AM +0800, dillon min wrote:
> - if (ctlr->flags & (SPI_CONTROLLER_MUST_RX | SPI_CONTROLLER_MUST_TX)) {
> + if ((ctlr->flags & (SPI_CONTROLLER_MUST_RX | SPI_CONTROLLER_MUST_TX)) &&
> + !(msg->spi->mode & SPI_3WIRE)) {
> max_tx = 0;
> max_rx = 0;
> for my board, lcd panel ilitek ill9341 use 3wire mode, gyro l3gd20 use
> simplex rx mode.
> it's has benefits to l3gd20, no impact to ili9341.
> if it's fine to spi-core, i will include it to my next submits.
Yes, looks reasonable.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
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 07/15] PCI: v3: Use pci_host_probe() to register host
From: Linus Walleij @ 2020-05-25 11:38 UTC (permalink / raw)
To: Rob Herring; +Cc: Bjorn Helgaas, linux-pci, Lorenzo Pieralisi, Linux ARM
In-Reply-To: <20200522234832.954484-8-robh@kernel.org>
On Sat, May 23, 2020 at 1:48 AM Rob Herring <robh@kernel.org> wrote:
> The v3 host driver does the same host registration and bus scanning
> calls as pci_host_probe, so let's use it instead.
>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Rob Herring <robh@kernel.org>
Sweet!
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
_______________________________________________
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 20/21] drm/tv200: Use GEM CMA object functions
From: Linus Walleij @ 2020-05-25 11:36 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: Alexandre Belloni, linux-aspeed, Neil Armstrong, Dave Airlie,
Liviu Dudau, Stefan Agner, Philippe Cornu, Paul Cercueil,
Laurent Pinchart, Benjamin Gaignard, Mihail Atanassov,
Sam Ravnborg, Alexandre TORGUE, Marek Vasut, Fabio Estevam,
abrodkin, Ludovic Desroches, Xinliang Liu, k00278426,
Tomi Valkeinen, james.qian.wang, Joel Stanley, NXP Linux Team,
Philipp Zabel, Chenfeng (puck), Sascha Hauer, Alison Wang,
Maarten Lankhorst, Maxime Ripard, John Stultz, Jyri Sarha,
Chen-Yu Tsai, Vincent Abriou, Sascha Hauer, Linux ARM,
Maxime Coquelin, Noralf Trønnes, Boris Brezillon,
Andrew Jeffery, open list:DRM PANEL DRIVERS, Yannick Fertre,
Kieran Bingham, Daniel Vetter, Kevin Hilman, Rongrong Zou,
Shawn Guo, Brian Starkey
In-Reply-To: <20200522135246.10134-21-tzimmermann@suse.de>
On Fri, May 22, 2020 at 3:53 PM Thomas Zimmermann <tzimmermann@suse.de> wrote:
> The tve200 driver uses the default implementation for CMA functions. The
> DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver.
> All remaining operations are provided by CMA GEM object functions.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
_______________________________________________
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 12/21] drm/mcde: Use GEM CMA object functions
From: Linus Walleij @ 2020-05-25 11:36 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: Alexandre Belloni, linux-aspeed, Neil Armstrong, Dave Airlie,
Liviu Dudau, Stefan Agner, Philippe Cornu, Paul Cercueil,
Laurent Pinchart, Benjamin Gaignard, Mihail Atanassov,
Sam Ravnborg, Alexandre TORGUE, Marek Vasut, Fabio Estevam,
abrodkin, Ludovic Desroches, Xinliang Liu, k00278426,
Tomi Valkeinen, james.qian.wang, Joel Stanley, NXP Linux Team,
Philipp Zabel, Chenfeng (puck), Sascha Hauer, Alison Wang,
Maarten Lankhorst, Maxime Ripard, John Stultz, Jyri Sarha,
Chen-Yu Tsai, Vincent Abriou, Sascha Hauer, Linux ARM,
Maxime Coquelin, Noralf Trønnes, Boris Brezillon,
Andrew Jeffery, open list:DRM PANEL DRIVERS, Yannick Fertre,
Kieran Bingham, Daniel Vetter, Kevin Hilman, Rongrong Zou,
Shawn Guo, Brian Starkey
In-Reply-To: <20200522135246.10134-13-tzimmermann@suse.de>
On Fri, May 22, 2020 at 3:52 PM Thomas Zimmermann <tzimmermann@suse.de> wrote:
> The mcde driver uses the default implementation for CMA functions. The
> DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver.
> All remaining operations are provided by CMA GEM object functions.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
_______________________________________________
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] Use SMMU HTTU for DMA dirty page tracking
From: Xiang Zheng @ 2020-05-25 11:34 UTC (permalink / raw)
To: Jean-Philippe Brucker
Cc: alex.williamson, Yan Zhao, Suzuki K Poulose, maz, iommu,
Kirti Wankhede, wangzhou1, James Morse, julien.thierry.kdev,
prime.zeng, Wang Haibin, Will Deacon, kvmarm, linux-arm-kernel
In-Reply-To: <20200522171452.GC3453945@myrica>
[+cc Kirti, Yan, Alex]
On 2020/5/23 1:14, Jean-Philippe Brucker wrote:
> Hi,
>
> On Tue, May 19, 2020 at 05:42:55PM +0800, Xiang Zheng wrote:
>> Hi all,
>>
>> Is there any plan for enabling SMMU HTTU?
>
> Not outside of SVA, as far as I know.
>
>> I have seen the patch locates in the SVA series patch, which adds
>> support for HTTU:
>> https://www.spinics.net/lists/arm-kernel/msg798694.html
>>
>> HTTU reduces the number of access faults on SMMU fault queue
>> (permission faults also benifit from it).
>>
>> Besides reducing the faults, HTTU also helps to track dirty pages for
>> device DMA. Is it feasible to utilize HTTU to get dirty pages on device
>> DMA during VFIO live migration?
>
> As you know there is a VFIO interface for this under discussion:
> https://lore.kernel.org/kvm/1589781397-28368-1-git-send-email-kwankhede@nvidia.com/
> It doesn't implement an internal API to communicate with the IOMMU driver
> about dirty pages.
>
>> If SMMU can track dirty pages, devices are not required to implement
>> additional dirty pages tracking to support VFIO live migration.
>
> It seems feasible, though tracking it in the device might be more
> efficient. I might have misunderstood but I think for live migration of
> the Intel NIC they trap guest accesses to the device and introspect its
> state to figure out which pages it is accessing.
>
> With HTTU I suppose (without much knowledge about live migration) that
> you'd need several new interfaces to the IOMMU drivers:
>
> * A way for VFIO to query HTTU support in the SMMU. There are some
> discussions about communicating more IOMMU capabilities through VFIO but
> no implementation yet. When HTTU isn't supported the DIRTY_PAGES bitmap
> would report all pages as they do now.
>
> * VFIO_IOMMU_DIRTY_PAGES_FLAG_START/STOP would clear the dirty bit
> for all VFIO mappings (which is going to take some time). There is a
> walker in io-pgtable for iova_to_phys() which could be extended. I
> suppose it's also possible to atomically switch the HA and HD bits in
> context descriptors.
Maybe we need not switch HA and HD bits, just turn on them all the time?
>
> * VFIO_IOMMU_DIRTY_PAGES_FLAG_GET_BITMAP would query the dirty bit for all
> VFIO mappings.
>
I think we need to consider the case of IOMMU dirty pages logging. We want
to test Kirti's VFIO migration patches combined with SMMU HTTU, any suggestions?
--
Thanks,
Xiang
_______________________________________________
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/3] iio: remove iio_triggered_buffer_postenable()/iio_triggered_buffer_predisable()
From: Ardelean, Alexandru @ 2020-05-25 11:30 UTC (permalink / raw)
To: jic23@kernel.org
Cc: lars@metafoo.de, s.hauer@pengutronix.de, alexandre.torgue@st.com,
linux-iio@vger.kernel.org, linus.walleij@linaro.org,
linux-kernel@vger.kernel.org, songqiang1304521@gmail.com,
mcoquelin.stm32@gmail.com, lorenzo.bianconi83@gmail.com,
shawnguo@kernel.org, linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20200524143830.11c2d97e@archlinux>
On Sun, 2020-05-24 at 14:38 +0100, Jonathan Cameron wrote:
> [External]
>
> On Fri, 22 May 2020 13:46:32 +0300
> Alexandru Ardelean <alexandru.ardelean@analog.com> wrote:
>
> > From: Lars-Peter Clausen <lars@metafoo.de>
> >
> > This patch should be squashed into the first one, as the first one is
> > breaking the build (intentionally) to make the IIO core files easier to
> > review.
> >
> > Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
> > Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
>
> Yeah! Didn't realise you'd finally gotten to the end of your mammoth rework
> leading to this.
>
> A few really minor things inline to tidy up.
Will fix these and send a V2.
>
> Thanks,
>
> Jonathan
>
>
> > diff --git a/drivers/iio/accel/st_accel_buffer.c
> > b/drivers/iio/accel/st_accel_buffer.c
> > index b5c814ef1637..c87f9a7d2453 100644
> > --- a/drivers/iio/accel/st_accel_buffer.c
> > +++ b/drivers/iio/accel/st_accel_buffer.c
> > @@ -33,13 +33,9 @@ static int st_accel_buffer_postenable(struct iio_dev
> > *indio_dev)
> > {
> > int err;
> >
> > - err = iio_triggered_buffer_postenable(indio_dev);
> > - if (err < 0)
> > - return err;
> > -
> > err = st_sensors_set_axis_enable(indio_dev, indio_dev-
> > >active_scan_mask[0]);
> > if (err < 0)
> > - goto st_accel_buffer_predisable;
> > + return err;
> >
> > err = st_sensors_set_enable(indio_dev, true);
> > if (err < 0)
> > @@ -49,8 +45,6 @@ static int st_accel_buffer_postenable(struct iio_dev
> > *indio_dev)
> >
> > st_accel_buffer_enable_all_axis:
> > st_sensors_set_axis_enable(indio_dev, ST_SENSORS_ENABLE_ALL_AXIS);
> > -st_accel_buffer_predisable:
> > - iio_triggered_buffer_predisable(indio_dev);
> > return err;
> > }
> >
> > @@ -60,12 +54,10 @@ static int st_accel_buffer_predisable(struct iio_dev
> > *indio_dev)
> >
> > err = st_sensors_set_enable(indio_dev, false);
> > if (err < 0)
> > - goto st_accel_buffer_predisable;
> > -
> > - err = st_sensors_set_axis_enable(indio_dev, ST_SENSORS_ENABLE_ALL_AXIS);
> > + return err;
> >
> > -st_accel_buffer_predisable:
> > - err2 = iio_triggered_buffer_predisable(indio_dev);
> > + err2 = st_sensors_set_axis_enable(indio_dev,
> > + ST_SENSORS_ENABLE_ALL_AXIS);
> > if (!err)
> I don't think you can get here with err set.
> > err = err2;
> >
>
> ...
>
> > diff --git a/drivers/iio/gyro/st_gyro_buffer.c
> > b/drivers/iio/gyro/st_gyro_buffer.c
> > index 9c92ff7a82be..7b86502d5da3 100644
> > --- a/drivers/iio/gyro/st_gyro_buffer.c
> > +++ b/drivers/iio/gyro/st_gyro_buffer.c
> > @@ -33,13 +33,9 @@ static int st_gyro_buffer_postenable(struct iio_dev
> > *indio_dev)
> > {
> > int err;
> >
> > - err = iio_triggered_buffer_postenable(indio_dev);
> > - if (err < 0)
> > - return err;
> > -
> > err = st_sensors_set_axis_enable(indio_dev, indio_dev-
> > >active_scan_mask[0]);
> > if (err < 0)
> > - goto st_gyro_buffer_predisable;
> > + return err;
> >
> > err = st_sensors_set_enable(indio_dev, true);
> > if (err < 0)
> > @@ -49,8 +45,6 @@ static int st_gyro_buffer_postenable(struct iio_dev
> > *indio_dev)
> >
> > st_gyro_buffer_enable_all_axis:
> > st_sensors_set_axis_enable(indio_dev, ST_SENSORS_ENABLE_ALL_AXIS);
> > -st_gyro_buffer_predisable:
> > - iio_triggered_buffer_predisable(indio_dev);
> > return err;
> > }
> >
> > @@ -59,13 +53,8 @@ static int st_gyro_buffer_predisable(struct iio_dev
> > *indio_dev)
> > int err, err2;
> >
> > err = st_sensors_set_enable(indio_dev, false);
> > - if (err < 0)
> > - goto st_gyro_buffer_predisable;
>
> Previously we didn't bother trying to carry on if this failed. I don't think
> we
> should start doing so now.
>
> > -
> > - err = st_sensors_set_axis_enable(indio_dev, ST_SENSORS_ENABLE_ALL_AXIS);
> >
> > -st_gyro_buffer_predisable:
> > - err2 = iio_triggered_buffer_predisable(indio_dev);
> > + err2 = st_sensors_set_axis_enable(indio_dev,
> > ST_SENSORS_ENABLE_ALL_AXIS);
> > if (!err)
> > err = err2;
> >
>
> ...
>
> > diff --git a/drivers/iio/light/gp2ap020a00f.c
> > b/drivers/iio/light/gp2ap020a00f.c
> > index 070d4cd0cf54..29d7af33efa1 100644
> > --- a/drivers/iio/light/gp2ap020a00f.c
> > +++ b/drivers/iio/light/gp2ap020a00f.c
> > @@ -1390,12 +1390,6 @@ static int gp2ap020a00f_buffer_postenable(struct
> > iio_dev *indio_dev)
> >
> > mutex_lock(&data->lock);
> I guess it doesn't matter, but no idea why this was ever under the local lock!
>
> >
> > - err = iio_triggered_buffer_postenable(indio_dev);
> > - if (err < 0) {
> > - mutex_unlock(&data->lock);
> > - return err;
> > - }
> > -
> > /*
> > * Enable triggers according to the scan_mask. Enabling either
> > * LIGHT_CLEAR or LIGHT_IR scan mode results in enabling ALS
> > @@ -1430,8 +1424,6 @@ static int gp2ap020a00f_buffer_postenable(struct
> > iio_dev *indio_dev)
> > err = -ENOMEM;
> >
> > error_unlock:
> > - if (err < 0)
> > - iio_triggered_buffer_predisable(indio_dev);
> > mutex_unlock(&data->lock);
> >
> > return err;
> > @@ -1465,8 +1457,6 @@ static int gp2ap020a00f_buffer_predisable(struct
> > iio_dev *indio_dev)
> > if (err == 0)
> > kfree(data->buffer);
> >
> > - iio_triggered_buffer_predisable(indio_dev);
> > -
> > mutex_unlock(&data->lock);
> >
> > return err;
>
> ...
>
> > diff --git a/drivers/iio/light/vcnl4000.c b/drivers/iio/light/vcnl4000.c
> > index 2a4b3d331055..0fee767af026 100644
> > --- a/drivers/iio/light/vcnl4000.c
> > +++ b/drivers/iio/light/vcnl4000.c
> > @@ -957,29 +957,20 @@ static int vcnl4010_buffer_postenable(struct iio_dev
> > *indio_dev)
> > int ret;
> > int cmd;
> >
> > - ret = iio_triggered_buffer_postenable(indio_dev);
> > - if (ret)
> > - return ret;
> > -
> > /* Do not enable the buffer if we are already capturing events. */
> > - if (vcnl4010_is_in_periodic_mode(data)) {
> > - ret = -EBUSY;
> > - goto end;
> > - }
> > + if (vcnl4010_is_in_periodic_mode(data))
> > + return -EBUSY;
> >
> > ret = i2c_smbus_write_byte_data(data->client, VCNL4010_INT_CTRL,
> > VCNL4010_INT_PROX_EN);
> > if (ret < 0)
> > - goto end;
> > + return ret;
> >
> > cmd = VCNL4000_SELF_TIMED_EN | VCNL4000_PROX_EN;
> > +
> > ret = i2c_smbus_write_byte_data(data->client, VCNL4000_COMMAND, cmd);
> > if (ret < 0)
> > - goto end;
> > -
> > - return 0;
> > -end:
> > - iio_triggered_buffer_predisable(indio_dev);
> > + i2c_smbus_write_byte_data(data->client, VCNL4010_INT_CTRL, 0);
> >
> > return ret;
> > }
> > @@ -987,18 +978,14 @@ static int vcnl4010_buffer_postenable(struct iio_dev
> > *indio_dev)
> > static int vcnl4010_buffer_predisable(struct iio_dev *indio_dev)
> > {
> > struct vcnl4000_data *data = iio_priv(indio_dev);
> > - int ret, ret_disable;
> > + int ret, ret2;
> >
> > ret = i2c_smbus_write_byte_data(data->client, VCNL4010_INT_CTRL, 0);
> > - if (ret < 0)
> > - goto end;
> >
> > - ret = i2c_smbus_write_byte_data(data->client, VCNL4000_COMMAND, 0);
> > + ret2 = i2c_smbus_write_byte_data(data->client, VCNL4000_COMMAND, 0);
>
> hmm. This does change the flow a tiny bit. I wonder if we really
> care about carrying on if we get an error on the first write?
> We are device not responding territory at that point. Maybe just return
> immediately and avoid the dance with the two ret variables?
>
> >
> > -end:
> > - ret_disable = iio_triggered_buffer_predisable(indio_dev);
> > if (ret == 0)
> > - ret = ret_disable;
> > + ret = ret2;
> >
> > return ret;
> > }
>
> ...
>
> > static const struct iio_buffer_setup_ops st_press_buffer_setup_ops = {
> > diff --git a/drivers/iio/pressure/zpa2326.c b/drivers/iio/pressure/zpa2326.c
> > index 37fe851f89af..e082ad007b22 100644
> > --- a/drivers/iio/pressure/zpa2326.c
> > +++ b/drivers/iio/pressure/zpa2326.c
> > @@ -1240,12 +1240,7 @@ static int zpa2326_preenable_buffer(struct iio_dev
> > *indio_dev)
> > static int zpa2326_postenable_buffer(struct iio_dev *indio_dev)
> > {
> > const struct zpa2326_private *priv = iio_priv(indio_dev);
> > - int err;
> > -
> > - /* Plug our own trigger event handler. */
> > - err = iio_triggered_buffer_postenable(indio_dev);
> > - if (err)
> > - goto err;
> > + int err = 0;
> >
> > if (!priv->waken) {
> > /*
> > @@ -1254,7 +1249,7 @@ static int zpa2326_postenable_buffer(struct iio_dev
> > *indio_dev)
> > */
> > err = zpa2326_clear_fifo(indio_dev, 0);
> > if (err)
> > - goto err_buffer_predisable;
> > + goto out;
> > }
> >
> > if (!iio_trigger_using_own(indio_dev) && priv->waken) {
> > @@ -1264,14 +1259,10 @@ static int zpa2326_postenable_buffer(struct iio_dev
> > *indio_dev)
> > */
> > err = zpa2326_config_oneshot(indio_dev, priv->irq);
> > if (err)
> > - goto err_buffer_predisable;
> > + goto out;
> > }
> >
> > - return 0;
> > -
> > -err_buffer_predisable:
> > - iio_triggered_buffer_predisable(indio_dev);
> > -err:
> > +out:
> > zpa2326_err(indio_dev, "failed to enable buffering (%d)", err);
>
> Doesn't this now print the error in the good path?
>
> Probably still want the return 0. It's a bit messier but I'd
> just move the prints into the error paths and return directly from
> each. Will be cleaner code that this.
>
>
> >
> > return err;
> > @@ -1287,7 +1278,6 @@ static int zpa2326_postdisable_buffer(struct iio_dev
> > *indio_dev)
> > static const struct iio_buffer_setup_ops zpa2326_buffer_setup_ops = {
> > .preenable = zpa2326_preenable_buffer,
> > .postenable = zpa2326_postenable_buffer,
> > - .predisable = iio_triggered_buffer_predisable,
> > .postdisable = zpa2326_postdisable_buffer
> > };
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [RFC PATCH 3/7] KVM: arm64: Traverse page table entries when sync dirty log
From: Keqian Zhu @ 2020-05-25 11:24 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel, kvmarm, kvm
Cc: Suzuki K Poulose, Catalin Marinas, Keqian Zhu,
Sean Christopherson, Peng Liang, Alexios Zavras, zhengxiang9,
Mark Brown, James Morse, Marc Zyngier, wanghaibin.wang,
Thomas Gleixner, Will Deacon, Andrew Morton, Julien Thierry
In-Reply-To: <20200525112406.28224-1-zhukeqian1@huawei.com>
For hardware management of dirty state, dirty state is stored in
page table entries. We have to traverse page table entries when
sync dirty log.
Signed-off-by: Keqian Zhu <zhukeqian1@huawei.com>
Signed-off-by: Peng Liang <liangpeng10@huawei.com>
---
arch/arm64/include/asm/kvm_host.h | 1 +
virt/kvm/arm/arm.c | 6 +-
virt/kvm/arm/mmu.c | 127 ++++++++++++++++++++++++++++++
3 files changed, 133 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 32c8a675e5a4..916617d3fed6 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -480,6 +480,7 @@ u64 __kvm_call_hyp(void *hypfn, ...);
void force_vm_exit(const cpumask_t *mask);
void kvm_mmu_wp_memory_region(struct kvm *kvm, int slot);
+int kvm_mmu_sync_dirty_log(struct kvm *kvm, struct kvm_memory_slot *memslot);
int handle_exit(struct kvm_vcpu *vcpu, struct kvm_run *run,
int exception_index);
diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
index 48d0ec44ad77..975311fa3a27 100644
--- a/virt/kvm/arm/arm.c
+++ b/virt/kvm/arm/arm.c
@@ -1191,7 +1191,11 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
void kvm_arch_sync_dirty_log(struct kvm *kvm, struct kvm_memory_slot *memslot)
{
-
+#ifdef CONFIG_ARM64_HW_AFDBM
+ if (kvm_hw_dbm_enabled()) {
+ kvm_mmu_sync_dirty_log(kvm, memslot);
+ }
+#endif
}
void kvm_arch_flush_remote_tlbs_memslot(struct kvm *kvm,
diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
index dc97988eb2e0..ff8df9702e04 100644
--- a/virt/kvm/arm/mmu.c
+++ b/virt/kvm/arm/mmu.c
@@ -2266,6 +2266,133 @@ int kvm_mmu_init(void)
return err;
}
+#ifdef CONFIG_ARM64_HW_AFDBM
+/**
+ * stage2_sync_dirty_log_ptes() - synchronize dirty log from PMD range
+ * @kvm: The KVM pointer
+ * @pmd: pointer to pmd entry
+ * @addr: range start address
+ * @end: range end address
+ */
+static void stage2_sync_dirty_log_ptes(struct kvm *kvm, pmd_t *pmd,
+ phys_addr_t addr, phys_addr_t end)
+{
+ pte_t *pte;
+
+ pte = pte_offset_kernel(pmd, addr);
+ do {
+ if (!pte_none(*pte) && !kvm_s2pte_readonly(pte)) {
+ mark_page_dirty(kvm, addr >> PAGE_SHIFT);
+ }
+ } while (pte++, addr += PAGE_SIZE, addr != end);
+}
+
+/**
+ * stage2_sync_dirty_log_pmds() - synchronize dirty log from PUD range
+ * @kvm: The KVM pointer
+ * @pud: pointer to pud entry
+ * @addr: range start address
+ * @end: range end address
+ */
+static void stage2_sync_dirty_log_pmds(struct kvm *kvm, pud_t *pud,
+ phys_addr_t addr, phys_addr_t end)
+{
+ pmd_t *pmd;
+ phys_addr_t next;
+
+ pmd = stage2_pmd_offset(kvm, pud, addr);
+ do {
+ next = stage2_pmd_addr_end(kvm, addr, end);
+ if (!pmd_none(*pmd) && !pmd_thp_or_huge(*pmd)) {
+ stage2_sync_dirty_log_ptes(kvm, pmd, addr, next);
+ }
+ } while (pmd++, addr = next, addr != end);
+}
+
+/**
+ * stage2_sync_dirty_log_puds() - synchronize dirty log from PGD range
+ * @kvm: The KVM pointer
+ * @pgd: pointer to pgd entry
+ * @addr: range start address
+ * @end: range end address
+ */
+static void stage2_sync_dirty_log_puds(struct kvm *kvm, pgd_t *pgd,
+ phys_addr_t addr, phys_addr_t end)
+{
+ pud_t *pud;
+ phys_addr_t next;
+
+ pud = stage2_pud_offset(kvm, pgd, addr);
+ do {
+ next = stage2_pud_addr_end(kvm, addr, end);
+ if (!stage2_pud_none(kvm, *pud) && !stage2_pud_huge(kvm, *pud)) {
+ stage2_sync_dirty_log_pmds(kvm, pud, addr, next);
+ }
+ } while (pud++, addr = next, addr != end);
+}
+
+/**
+ * stage2_sync_dirty_log_range() - synchronize dirty log from stage2 memory
+ * region range
+ * @kvm: The KVM pointer
+ * @addr: Start address of range
+ * @end: End address of range
+ */
+static void stage2_sync_dirty_log_range(struct kvm *kvm, phys_addr_t addr,
+ phys_addr_t end)
+{
+ pgd_t *pgd;
+ phys_addr_t next;
+
+ pgd = kvm->arch.pgd + stage2_pgd_index(kvm, addr);
+ do {
+ /*
+ * Release kvm_mmu_lock periodically if the memory region is
+ * large. Otherwise, we may see kernel panics with
+ * CONFIG_DETECT_HUNG_TASK, CONFIG_LOCKUP_DETECTOR,
+ * CONFIG_LOCKDEP. Additionally, holding the lock too long
+ * will also starve other vCPUs. We have to also make sure
+ * that the page tables are not freed while we released
+ * the lock.
+ */
+ cond_resched_lock(&kvm->mmu_lock);
+ if (!READ_ONCE(kvm->arch.pgd))
+ break;
+ next = stage2_pgd_addr_end(kvm, addr, end);
+ if (stage2_pgd_present(kvm, *pgd))
+ stage2_sync_dirty_log_puds(kvm, pgd, addr, next);
+ } while (pgd++, addr = next, addr != end);
+}
+
+/**
+ * kvm_mmu_sync_dirty_log() - synchronize dirty log from stage2 entries for
+ * memory slot
+ * @kvm: The KVM pointer
+ * @slot: The memory slot to synchronize dirty log
+ *
+ * Called to synchronize dirty log (marked by hw) after memory region
+ * KVM_GET_DIRTY_LOG operation is called. After this function returns
+ * all dirty log information (for that hw will modify page tables during
+ * this routine, it is true only when guest is stopped, but it is OK
+ * because we won't miss dirty log finally.) are collected into memslot
+ * dirty_bitmap. Afterwards dirty_bitmap can be copied to userspace.
+ *
+ * Acquires kvm_mmu_lock. Called with kvm->slots_lock mutex acquired,
+ * serializing operations for VM memory regions.
+ */
+int kvm_mmu_sync_dirty_log(struct kvm *kvm, struct kvm_memory_slot *memslot)
+{
+ phys_addr_t start = memslot->base_gfn << PAGE_SHIFT;
+ phys_addr_t end = (memslot->base_gfn + memslot->npages) << PAGE_SHIFT;
+
+ spin_lock(&kvm->mmu_lock);
+ stage2_sync_dirty_log_range(kvm, start, end);
+ spin_unlock(&kvm->mmu_lock);
+
+ return 0;
+}
+#endif /* CONFIG_ARM64_HW_AFDBM */
+
void kvm_arch_commit_memory_region(struct kvm *kvm,
const struct kvm_userspace_memory_region *mem,
struct kvm_memory_slot *old,
--
2.19.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
* [RFC PATCH 2/7] KVM: arm64: Set DBM bit of PTEs if hw DBM enabled
From: Keqian Zhu @ 2020-05-25 11:24 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel, kvmarm, kvm
Cc: Suzuki K Poulose, Catalin Marinas, Keqian Zhu,
Sean Christopherson, Peng Liang, Alexios Zavras, zhengxiang9,
Mark Brown, James Morse, Marc Zyngier, wanghaibin.wang,
Thomas Gleixner, Will Deacon, Andrew Morton, Julien Thierry
In-Reply-To: <20200525112406.28224-1-zhukeqian1@huawei.com>
In user_mem_abort, for normal case (mem_type is PAGE_S2), set DBM bit
of PTEs if hw DBM enabled. We also check and set DBM bit during write
protect PTEs to make it works well if we miss some cases.
Signed-off-by: Keqian Zhu <zhukeqian1@huawei.com>
Signed-off-by: Peng Liang <liangpeng10@huawei.com>
---
arch/arm64/include/asm/pgtable-prot.h | 1 +
virt/kvm/arm/mmu.c | 14 +++++++++++++-
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/pgtable-prot.h b/arch/arm64/include/asm/pgtable-prot.h
index 1305e28225fc..f9910ba2afd8 100644
--- a/arch/arm64/include/asm/pgtable-prot.h
+++ b/arch/arm64/include/asm/pgtable-prot.h
@@ -79,6 +79,7 @@ extern bool arm64_use_ng_mappings;
})
#define PAGE_S2 __pgprot(_PROT_DEFAULT | PAGE_S2_MEMATTR(NORMAL) | PTE_S2_RDONLY | PAGE_S2_XN)
+#define PAGE_S2_DBM __pgprot(_PROT_DEFAULT | PAGE_S2_MEMATTR(NORMAL) | PTE_S2_RDONLY | PAGE_S2_XN | PTE_DBM)
#define PAGE_S2_DEVICE __pgprot(_PROT_DEFAULT | PAGE_S2_MEMATTR(DEVICE_nGnRE) | PTE_S2_RDONLY | PTE_S2_XN)
#define PAGE_NONE __pgprot(((_PAGE_DEFAULT) & ~PTE_VALID) | PTE_PROT_NONE | PTE_RDONLY | PTE_NG | PTE_PXN | PTE_UXN)
diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
index e3b9ee268823..dc97988eb2e0 100644
--- a/virt/kvm/arm/mmu.c
+++ b/virt/kvm/arm/mmu.c
@@ -1426,6 +1426,10 @@ static void stage2_wp_ptes(pmd_t *pmd, phys_addr_t addr, phys_addr_t end)
pte = pte_offset_kernel(pmd, addr);
do {
if (!pte_none(*pte)) {
+#ifdef CONFIG_ARM64_HW_AFDBM
+ if (kvm_hw_dbm_enabled() && !kvm_s2pte_dbm(pte))
+ kvm_set_s2pte_dbm(pte);
+#endif
if (!kvm_s2pte_readonly(pte))
kvm_set_s2pte_readonly(pte);
}
@@ -1827,7 +1831,15 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
ret = stage2_set_pmd_huge(kvm, memcache, fault_ipa, &new_pmd);
} else {
- pte_t new_pte = kvm_pfn_pte(pfn, mem_type);
+ pte_t new_pte;
+
+#ifdef CONFIG_ARM64_HW_AFDBM
+ if (kvm_hw_dbm_enabled() &&
+ pgprot_val(mem_type) == pgprot_val(PAGE_S2)) {
+ mem_type = PAGE_S2_DBM;
+ }
+#endif
+ new_pte = kvm_pfn_pte(pfn, mem_type);
if (writable) {
new_pte = kvm_s2pte_mkwrite(new_pte);
--
2.19.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
* [RFC PATCH 0/7] kvm: arm64: Support stage2 hardware DBM
From: Keqian Zhu @ 2020-05-25 11:23 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel, kvmarm, kvm
Cc: Suzuki K Poulose, Catalin Marinas, Keqian Zhu,
Sean Christopherson, Alexios Zavras, zhengxiang9, Mark Brown,
James Morse, Marc Zyngier, wanghaibin.wang, Thomas Gleixner,
Will Deacon, Andrew Morton, Julien Thierry
This patch series add support for stage2 hardware DBM, and it is only
used for dirty log for now.
It works well under some migration test cases, including VM with 4K
pages or 2M THP. I checked the SHA256 hash digest of all memory and
they keep same for source VM and destination VM, which means no dirty
pages is missed under hardware DBM.
However, there are some known issues not solved.
1. Some mechanisms that rely on "write permission fault" become invalid,
such as kvm_set_pfn_dirty and "mmap page sharing".
kvm_set_pfn_dirty is called in user_mem_abort when guest issues write
fault. This guarantees physical page will not be dropped directly when
host kernel recycle memory. After using hardware dirty management, we
have no chance to call kvm_set_pfn_dirty.
For "mmap page sharing" mechanism, host kernel will allocate a new
physical page when guest writes a page that is shared with other page
table entries. After using hardware dirty management, we have no chance
to do this too.
I need to do some survey on how stage1 hardware DBM solve these problems.
It helps if anyone can figure it out.
2. Page Table Modification Races: Though I have found and solved some data
races when kernel changes page table entries, I still doubt that there
are data races I am not aware of. It's great if anyone can figure them out.
3. Performance: Under Kunpeng 920 platform, for every 64GB memory, KVM
consumes about 40ms to traverse all PTEs to collect dirty log. It will
cause unbearable downtime for migration if memory size is too big. I will
try to solve this problem in Patch v1.
Keqian Zhu (7):
KVM: arm64: Add some basic functions for hw DBM
KVM: arm64: Set DBM bit of PTEs if hw DBM enabled
KVM: arm64: Traverse page table entries when sync dirty log
KVM: arm64: Steply write protect page table by mask bit
kvm: arm64: Modify stage2 young mechanism to support hw DBM
kvm: arm64: Save stage2 PTE dirty info if it is coverred
KVM: arm64: Enable stage2 hardware DBM
arch/arm64/include/asm/kvm_host.h | 1 +
arch/arm64/include/asm/kvm_mmu.h | 44 +++++-
arch/arm64/include/asm/pgtable-prot.h | 1 +
arch/arm64/include/asm/sysreg.h | 2 +
arch/arm64/kvm/reset.c | 9 +-
virt/kvm/arm/arm.c | 6 +-
virt/kvm/arm/mmu.c | 202 ++++++++++++++++++++++++--
7 files changed, 246 insertions(+), 19 deletions(-)
--
2.19.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [RFC PATCH 5/7] kvm: arm64: Modify stage2 young mechanism to support hw DBM
From: Keqian Zhu @ 2020-05-25 11:24 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel, kvmarm, kvm
Cc: Suzuki K Poulose, Catalin Marinas, Keqian Zhu,
Sean Christopherson, Alexios Zavras, zhengxiang9, Mark Brown,
James Morse, Marc Zyngier, wanghaibin.wang, Thomas Gleixner,
Will Deacon, Andrew Morton, Julien Thierry
In-Reply-To: <20200525112406.28224-1-zhukeqian1@huawei.com>
Making page table entries young (set AF bit) should be atomic to
avoid cover dirty info that is set by hardware.
Signed-off-by: Keqian Zhu <zhukeqian1@huawei.com>
---
arch/arm64/include/asm/kvm_mmu.h | 32 ++++++++++++++++++++++----------
virt/kvm/arm/mmu.c | 10 +++++-----
2 files changed, 27 insertions(+), 15 deletions(-)
diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
index 8df078f0ee67..a4620d87e456 100644
--- a/arch/arm64/include/asm/kvm_mmu.h
+++ b/arch/arm64/include/asm/kvm_mmu.h
@@ -235,6 +235,18 @@ static inline void kvm_set_s2pte_readonly(pte_t *ptep)
} while (pteval != old_pteval);
}
+static inline void kvm_set_s2pte_young(pte_t *ptep)
+{
+ pteval_t old_pteval, pteval;
+
+ pteval = READ_ONCE(pte_val(*ptep));
+ do {
+ old_pteval = pteval;
+ pteval |= PTE_AF;
+ pteval = cmpxchg_relaxed(&pte_val(*ptep), old_pteval, pteval);
+ } while (pteval != old_pteval);
+}
+
static inline bool kvm_s2pte_readonly(pte_t *ptep)
{
return (READ_ONCE(pte_val(*ptep)) & PTE_S2_RDWR) == PTE_S2_RDONLY;
@@ -250,6 +262,11 @@ static inline void kvm_set_s2pmd_readonly(pmd_t *pmdp)
kvm_set_s2pte_readonly((pte_t *)pmdp);
}
+static inline void kvm_set_s2pmd_young(pmd_t *pmdp)
+{
+ kvm_set_s2pte_young((pte_t *)pmdp);
+}
+
static inline bool kvm_s2pmd_readonly(pmd_t *pmdp)
{
return kvm_s2pte_readonly((pte_t *)pmdp);
@@ -265,6 +282,11 @@ static inline void kvm_set_s2pud_readonly(pud_t *pudp)
kvm_set_s2pte_readonly((pte_t *)pudp);
}
+static inline void kvm_set_s2pud_young(pud_t *pudp)
+{
+ kvm_set_s2pte_young((pte_t *)pudp);
+}
+
static inline bool kvm_s2pud_readonly(pud_t *pudp)
{
return kvm_s2pte_readonly((pte_t *)pudp);
@@ -275,16 +297,6 @@ static inline bool kvm_s2pud_exec(pud_t *pudp)
return !(READ_ONCE(pud_val(*pudp)) & PUD_S2_XN);
}
-static inline pud_t kvm_s2pud_mkyoung(pud_t pud)
-{
- return pud_mkyoung(pud);
-}
-
-static inline bool kvm_s2pud_young(pud_t pud)
-{
- return pud_young(pud);
-}
-
#ifdef CONFIG_ARM64_HW_AFDBM
static inline bool kvm_hw_dbm_enabled(void)
{
diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
index 779859b85d6d..e1d9e4b98cb6 100644
--- a/virt/kvm/arm/mmu.c
+++ b/virt/kvm/arm/mmu.c
@@ -1888,15 +1888,15 @@ static void handle_access_fault(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa)
goto out;
if (pud) { /* HugeTLB */
- *pud = kvm_s2pud_mkyoung(*pud);
+ kvm_set_s2pud_young(pud);
pfn = kvm_pud_pfn(*pud);
pfn_valid = true;
} else if (pmd) { /* THP, HugeTLB */
- *pmd = pmd_mkyoung(*pmd);
+ kvm_set_s2pmd_young(pmd);
pfn = pmd_pfn(*pmd);
pfn_valid = true;
- } else {
- *pte = pte_mkyoung(*pte); /* Just a page... */
+ } else { /* Just a page... */
+ kvm_set_s2pte_young(pte);
pfn = pte_pfn(*pte);
pfn_valid = true;
}
@@ -2141,7 +2141,7 @@ static int kvm_test_age_hva_handler(struct kvm *kvm, gpa_t gpa, u64 size, void *
return 0;
if (pud)
- return kvm_s2pud_young(*pud);
+ return pud_young(*pud);
else if (pmd)
return pmd_young(*pmd);
else
--
2.19.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
* [RFC PATCH 1/7] KVM: arm64: Add some basic functions for hw DBM
From: Keqian Zhu @ 2020-05-25 11:24 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel, kvmarm, kvm
Cc: Suzuki K Poulose, Catalin Marinas, Keqian Zhu,
Sean Christopherson, Peng Liang, Alexios Zavras, zhengxiang9,
Mark Brown, James Morse, Marc Zyngier, wanghaibin.wang,
Thomas Gleixner, Will Deacon, Andrew Morton, Julien Thierry
In-Reply-To: <20200525112406.28224-1-zhukeqian1@huawei.com>
Prepare some basic functions used by following patches to support
hardware DBM.
Signed-off-by: Keqian Zhu <zhukeqian1@huawei.com>
Signed-off-by: Peng Liang <liangpeng10@huawei.com>
---
arch/arm64/include/asm/kvm_mmu.h | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
index 30b0e8d6b895..8df078f0ee67 100644
--- a/arch/arm64/include/asm/kvm_mmu.h
+++ b/arch/arm64/include/asm/kvm_mmu.h
@@ -285,6 +285,30 @@ static inline bool kvm_s2pud_young(pud_t pud)
return pud_young(pud);
}
+#ifdef CONFIG_ARM64_HW_AFDBM
+static inline bool kvm_hw_dbm_enabled(void)
+{
+ return !!(read_sysreg(vtcr_el2) & VTCR_EL2_HD);
+}
+
+static inline void kvm_set_s2pte_dbm(pte_t *ptep)
+{
+ pteval_t old_pteval, pteval;
+
+ pteval = READ_ONCE(pte_val(*ptep));
+ do {
+ old_pteval = pteval;
+ pteval |= PTE_DBM;
+ pteval = cmpxchg_relaxed(&pte_val(*ptep), old_pteval, pteval);
+ } while (pteval != old_pteval);
+}
+
+static inline bool kvm_s2pte_dbm(pte_t *ptep)
+{
+ return !!(READ_ONCE(pte_val(*ptep)) & PTE_DBM);
+}
+#endif /* CONFIG_ARM64_HW_AFDBM */
+
#define hyp_pte_table_empty(ptep) kvm_page_empty(ptep)
#ifdef __PAGETABLE_PMD_FOLDED
--
2.19.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
* [RFC PATCH 6/7] kvm: arm64: Save stage2 PTE dirty info if it is coverred
From: Keqian Zhu @ 2020-05-25 11:24 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel, kvmarm, kvm
Cc: Suzuki K Poulose, Catalin Marinas, Keqian Zhu,
Sean Christopherson, Alexios Zavras, zhengxiang9, Mark Brown,
James Morse, Marc Zyngier, wanghaibin.wang, Thomas Gleixner,
Will Deacon, Andrew Morton, Julien Thierry
In-Reply-To: <20200525112406.28224-1-zhukeqian1@huawei.com>
kvm_set_pte is called to replace a target PTE with a desired one.
We always replace it, but if hw DBM is enalbled and dirty info is
coverred, should let caller know it. Caller can decide to whether
save the dirty info.
kvm_set_pmd and kvm_set_pud is not modified, because we only use
DBM in PTEs for now.
Signed-off-by: Keqian Zhu <zhukeqian1@huawei.com>
---
virt/kvm/arm/mmu.c | 39 +++++++++++++++++++++++++++++++++++----
1 file changed, 35 insertions(+), 4 deletions(-)
diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
index e1d9e4b98cb6..43d89c6333f0 100644
--- a/virt/kvm/arm/mmu.c
+++ b/virt/kvm/arm/mmu.c
@@ -185,10 +185,34 @@ static void clear_stage2_pmd_entry(struct kvm *kvm, pmd_t *pmd, phys_addr_t addr
put_page(virt_to_page(pmd));
}
-static inline void kvm_set_pte(pte_t *ptep, pte_t new_pte)
+/*
+ * @ret: true if dirty info is coverred.
+ */
+static inline bool kvm_set_pte(pte_t *ptep, pte_t new_pte)
{
+#ifdef CONFIG_ARM64_HW_AFDBM
+ pteval_t old_pteval, new_pteval, pteval;
+
+ if (!kvm_hw_dbm_enabled() || pte_none(*ptep) ||
+ !kvm_s2pte_readonly(&new_pte)) {
+ WRITE_ONCE(*ptep, new_pte);
+ dsb(ishst);
+ return false;
+ }
+
+ new_pteval = pte_val(new_pte);
+ pteval = READ_ONCE(pte_val(*ptep));
+ do {
+ old_pteval = pteval;
+ pteval = cmpxchg_relaxed(&pte_val(*ptep), old_pteval, new_pteval);
+ } while (pteval != old_pteval);
+
+ return !kvm_s2pte_readonly((pte_t *)&pteval);
+#else
WRITE_ONCE(*ptep, new_pte);
dsb(ishst);
+ return false;
+#endif
}
static inline void kvm_set_pmd(pmd_t *pmdp, pmd_t new_pmd)
@@ -249,7 +273,10 @@ static void unmap_stage2_ptes(struct kvm *kvm, pmd_t *pmd,
if (!pte_none(*pte)) {
pte_t old_pte = *pte;
- kvm_set_pte(pte, __pte(0));
+ if (kvm_set_pte(pte, __pte(0))) {
+ mark_page_dirty(kvm, addr >> PAGE_SHIFT);
+ }
+
kvm_tlb_flush_vmid_ipa(kvm, addr);
/* No need to invalidate the cache for device mappings */
@@ -1291,13 +1318,17 @@ static int stage2_set_pte(struct kvm *kvm, struct kvm_mmu_memory_cache *cache,
if (pte_val(old_pte) == pte_val(*new_pte))
return 0;
- kvm_set_pte(pte, __pte(0));
+ if (kvm_set_pte(pte, __pte(0))) {
+ mark_page_dirty(kvm, addr >> PAGE_SHIFT);
+ }
kvm_tlb_flush_vmid_ipa(kvm, addr);
} else {
get_page(virt_to_page(pte));
}
- kvm_set_pte(pte, *new_pte);
+ if (kvm_set_pte(pte, *new_pte)) {
+ mark_page_dirty(kvm, addr >> PAGE_SHIFT);
+ }
return 0;
}
--
2.19.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
* [RFC PATCH 4/7] KVM: arm64: Steply write protect page table by mask bit
From: Keqian Zhu @ 2020-05-25 11:24 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel, kvmarm, kvm
Cc: Suzuki K Poulose, Catalin Marinas, Keqian Zhu,
Sean Christopherson, Alexios Zavras, zhengxiang9, Mark Brown,
James Morse, Marc Zyngier, wanghaibin.wang, Thomas Gleixner,
Will Deacon, Andrew Morton, Julien Thierry
In-Reply-To: <20200525112406.28224-1-zhukeqian1@huawei.com>
During dirty log clear, page table entries are write protected
according to a mask. In the past we write protect all entries
corresponding to the mask from ffs to fls. Though there may be
zero bits between this range, we are holding the kvm mmu lock
so we won't write protect entries that we don't want to.
We are about to add support for hardware management of dirty state
to arm64, holding kvm mmu lock will be not enough. We should write
protect entries steply by mask bit.
Signed-off-by: Keqian Zhu <zhukeqian1@huawei.com>
---
virt/kvm/arm/mmu.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
index ff8df9702e04..779859b85d6d 100644
--- a/virt/kvm/arm/mmu.c
+++ b/virt/kvm/arm/mmu.c
@@ -1568,10 +1568,16 @@ static void kvm_mmu_write_protect_pt_masked(struct kvm *kvm,
gfn_t gfn_offset, unsigned long mask)
{
phys_addr_t base_gfn = slot->base_gfn + gfn_offset;
- phys_addr_t start = (base_gfn + __ffs(mask)) << PAGE_SHIFT;
- phys_addr_t end = (base_gfn + __fls(mask) + 1) << PAGE_SHIFT;
+ phys_addr_t start, end;
+ u32 i;
- stage2_wp_range(kvm, start, end);
+ for (i = __ffs(mask); i <= __fls(mask); i++) {
+ if (test_bit(i, &mask)) {
+ start = (base_gfn + i) << PAGE_SHIFT;
+ end = (base_gfn + i + 1) << PAGE_SHIFT;
+ stage2_wp_range(kvm, start, end);
+ }
+ }
}
/*
--
2.19.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
* [RFC PATCH 7/7] KVM: arm64: Enable stage2 hardware DBM
From: Keqian Zhu @ 2020-05-25 11:24 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel, kvmarm, kvm
Cc: Suzuki K Poulose, Catalin Marinas, Keqian Zhu,
Sean Christopherson, Peng Liang, Alexios Zavras, zhengxiang9,
Mark Brown, James Morse, Marc Zyngier, wanghaibin.wang,
Thomas Gleixner, Will Deacon, Andrew Morton, Julien Thierry
In-Reply-To: <20200525112406.28224-1-zhukeqian1@huawei.com>
We are ready to support hw management of dirty state, enable it if
hardware support it.
Signed-off-by: Keqian Zhu <zhukeqian1@huawei.com>
Signed-off-by: Peng Liang <liangpeng10@huawei.com>
---
arch/arm64/include/asm/sysreg.h | 2 ++
arch/arm64/kvm/reset.c | 9 ++++++++-
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index ebc622432831..371ea6d65c16 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -721,6 +721,8 @@
#define ID_AA64MMFR1_VMIDBITS_8 0
#define ID_AA64MMFR1_VMIDBITS_16 2
+#define ID_AA64MMFR1_HADBS_DBS 2
+
/* id_aa64mmfr2 */
#define ID_AA64MMFR2_E0PD_SHIFT 60
#define ID_AA64MMFR2_FWB_SHIFT 40
diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
index 30b7ea680f66..cb727e1fb581 100644
--- a/arch/arm64/kvm/reset.c
+++ b/arch/arm64/kvm/reset.c
@@ -392,7 +392,7 @@ int kvm_arm_setup_stage2(struct kvm *kvm, unsigned long type)
{
u64 vtcr = VTCR_EL2_FLAGS;
u32 parange, phys_shift;
- u8 lvls;
+ u8 lvls, hadbs;
if (type & ~KVM_VM_TYPE_ARM_IPA_SIZE_MASK)
return -EINVAL;
@@ -428,6 +428,13 @@ int kvm_arm_setup_stage2(struct kvm *kvm, unsigned long type)
*/
vtcr |= VTCR_EL2_HA;
+ hadbs = (read_sysreg(id_aa64mmfr1_el1) >>
+ ID_AA64MMFR1_HADBS_SHIFT) & 0xf;
+#ifdef CONFIG_ARM64_HW_AFDBM
+ if (hadbs == ID_AA64MMFR1_HADBS_DBS)
+ vtcr |= VTCR_EL2_HD;
+#endif
+
/* Set the vmid bits */
vtcr |= (kvm_get_vmid_bits() == 16) ?
VTCR_EL2_VS_16BIT :
--
2.19.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 v2 00/91] drm/vc4: Support BCM2711 Display Pipelin
From: Maxime Ripard @ 2020-05-25 11:11 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>
[-- Attachment #1.1: Type: text/plain, Size: 9081 bytes --]
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 today, and it seems that you also need arm_64bit=1 in the
config.txt, but then the communication with the firmware doesn't work anymore
and the kernel just falls apart.
I'll give it a try with U-boot
Maxime
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
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] arm64: dts: ls1028a: add one more thermal zone support
From: Daniel Lezcano @ 2020-05-25 11:08 UTC (permalink / raw)
To: Yuantian Tang, shawnguo, robh+dt, mark.rutland, catalin.marinas,
will.deacon
Cc: devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20200525073827.13272-1-andy.tang@nxp.com>
On 25/05/2020 09:38, Yuantian Tang wrote:
> There are 2 thermal zones in ls1028a soc. Current dts only
> includes one. This patch adds the other thermal zone node
> in dts to enable it.
For my personal information, is there a cooling device for the DDR?
> Signed-off-by: Yuantian Tang <andy.tang@nxp.com>
> ---
> .../arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 22 ++++++++++++++++++-
> 1 file changed, 21 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> index 055f114cf848..bc6f0c0f85da 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> @@ -129,11 +129,31 @@
> };
>
> thermal-zones {
> - core-cluster {
> + ddr-controller {
> polling-delay-passive = <1000>;
> polling-delay = <5000>;
> thermal-sensors = <&tmu 0>;
>
> + trips {
> + ddr-ctrler-alert {
> + temperature = <85000>;
> + hysteresis = <2000>;
> + type = "passive";
> + };
> +
> + ddr-ctrler-crit {
> + temperature = <95000>;
> + hysteresis = <2000>;
> + type = "critical";
> + };
> + };
> + };
> +
> + core-cluster {
> + polling-delay-passive = <1000>;
> + polling-delay = <5000>;
> + thermal-sensors = <&tmu 1>;
> +
> trips {
> core_cluster_alert: core-cluster-alert {
> temperature = <85000>;
>
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
_______________________________________________
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] thermal: imx8mm: Add get_trend ops
From: Daniel Lezcano @ 2020-05-25 11:04 UTC (permalink / raw)
To: Anson Huang, rui.zhang@intel.com, amit.kucheria@verdurent.com,
shawnguo@kernel.org, s.hauer@pengutronix.de,
kernel@pengutronix.de, festevam@gmail.com,
linux-pm@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: dl-linux-imx
In-Reply-To: <DB3PR0402MB39162E6A876BA54A80B0DCE2F5B30@DB3PR0402MB3916.eurprd04.prod.outlook.com>
On 25/05/2020 04:46, Anson Huang wrote:
> Hi, Daniel
[ ... ]
> I tried modifying the min/max to '2' in cooling map, it works that
> whenever cooling action is needed, the max cooling action will be
> applied. But I also noticed some behaviors which NOT as expected:
>
> 1. to easy the test, I enable the " CONFIG_THERMAL_WRITABLE_TRIPS",
> and just modify the passive trip threshold to trigger the cooling
> action, this is much more easy then putting the board into an oven to
> increase the SoC temperature or running many high loading test to
> increase the temperature, but when I modify the passive trip
> threshold to be lower than current temperature, the cooling action is
> NOT triggered immediately, it is because the default step_wise
> governor will NOT trigger the cooling action when the trend is
> THERMAL_TREND_STABLE. But what expected is, when the temperature is
> exceed the passive trip threshold, the cooling action can be
> triggered immediately no matter the trend is stable or raising.
You are right, what is expected is, when the temperature exceeds the
passive trip threshold, a cooling action happens, the trend is raising
in this case.
But in your test, it is not what is happening: the trip point is
changing, not the temperature.
Probably, the cpufreq driver is at its lowest OPP, so there is no room
for more cooling effect when changing the trip point.
IMO, the test is not right as the trip point is decreased to a
temperature where actually the SoC is not hot.
If you want to test it easily, I recommend to use dhrystone, something like:
dhrystone -t 6 -l 10000
That will make your board to heat immediately.
> That
> means we have to implement our own .get_trend callback?
From my POV it must disappear, because it has little meaning. The
governor is the one which should be dealing with that and call the
corresponding cooling index.
> 2. No margin for releasing the cooling action, for example, if
> cooling action is triggered, when the temperature drops below the
> passive trip threshold, the cooling action will be cancelled
> immediately, if SoC keeps running at full performance, the
> temperature will increase very soon, which may cause the SoC keep
> triggering/cancelling the cooling action around the passive trip
> threshold. If there is a margin, the situation will be much better.
>
> Do you have any idea/comment about them?
Yes, that is a good point. The hysteresis is supposed to do that. There
is a work done by Andrzej Pietrasiewicz to disable / enable the thermal
zones [1]. I think we should be able to fix that after the changes are done.
-- Daniel
[1] https://www.spinics.net/lists/netdev/msg644762.html
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] iio: at91-sama5d2_adc: remove usage of iio_priv_to_dev() helper
From: Alexandru Ardelean @ 2020-05-25 10:53 UTC (permalink / raw)
To: linux-iio, linux-arm-kernel, linux-kernel
Cc: alexandre.belloni, ludovic.desroches, eugen.hristev,
Alexandru Ardelean, jic23
We may want to get rid of the iio_priv_to_dev() helper. The reason is that
we will hide some of the members of the iio_dev structure (to prevent
drivers from accessing them directly), and that will also mean hiding the
implementation of the iio_priv_to_dev() helper inside the IIO core.
Hiding the implementation of iio_priv_to_dev() implies that some fast-paths
may not be fast anymore, so a general idea is to try to get rid of the
iio_priv_to_dev() altogether.
The iio_priv() helper won't be affected by the rework, as the iio_dev
struct will keep a reference to the private information.
For this driver, not using iio_priv_to_dev(), means reworking some paths to
pass the iio device and using iio_priv() to access the private information,
and also keeping a reference to the iio device for some quirky paths.
One [quirky] path is the at91_adc_workq_handler() which requires the IIO
device & the state struct to push to buffers.
Since this requires the back-ref to the IIO device, the
at91_adc_touch_pos() also uses it. This simplifies the patch a bit. The
information required in this function is mostly for debugging purposes.
Replacing it with a reference to the IIO device would have been a slightly
bigger change, which may not be worth it (for just the debugging purpose
and given that we need the back-ref to the IIO device anyway).
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
---
drivers/iio/adc/at91-sama5d2_adc.c | 30 +++++++++++++++++-------------
1 file changed, 17 insertions(+), 13 deletions(-)
diff --git a/drivers/iio/adc/at91-sama5d2_adc.c b/drivers/iio/adc/at91-sama5d2_adc.c
index 9abbbdcc7420..7bce18444430 100644
--- a/drivers/iio/adc/at91-sama5d2_adc.c
+++ b/drivers/iio/adc/at91-sama5d2_adc.c
@@ -402,6 +402,7 @@ struct at91_adc_state {
wait_queue_head_t wq_data_available;
struct at91_adc_dma dma_st;
struct at91_adc_touch touch_st;
+ struct iio_dev *indio_dev;
u16 buffer[AT91_BUFFER_MAX_HWORDS];
/*
* lock to prevent concurrent 'single conversion' requests through
@@ -642,13 +643,13 @@ static u16 at91_adc_touch_pos(struct at91_adc_state *st, int reg)
/* first half of register is the x or y, second half is the scale */
val = at91_adc_readl(st, reg);
if (!val)
- dev_dbg(&iio_priv_to_dev(st)->dev, "pos is 0\n");
+ dev_dbg(&st->indio_dev->dev, "pos is 0\n");
pos = val & AT91_SAMA5D2_XYZ_MASK;
result = (pos << AT91_SAMA5D2_MAX_POS_BITS) - pos;
scale = (val >> 16) & AT91_SAMA5D2_XYZ_MASK;
if (scale == 0) {
- dev_err(&iio_priv_to_dev(st)->dev, "scale is 0\n");
+ dev_err(&st->indio_dev->dev, "scale is 0\n");
return 0;
}
result /= scale;
@@ -1204,9 +1205,9 @@ static unsigned at91_adc_startup_time(unsigned startup_time_min,
return i;
}
-static void at91_adc_setup_samp_freq(struct at91_adc_state *st, unsigned freq)
+static void at91_adc_setup_samp_freq(struct iio_dev *indio_dev, unsigned freq)
{
- struct iio_dev *indio_dev = iio_priv_to_dev(st);
+ struct at91_adc_state *st = iio_priv(indio_dev);
unsigned f_per, prescal, startup, mr;
f_per = clk_get_rate(st->per_clk);
@@ -1275,9 +1276,9 @@ static void at91_adc_pen_detect_interrupt(struct at91_adc_state *st)
st->touch_st.touching = true;
}
-static void at91_adc_no_pen_detect_interrupt(struct at91_adc_state *st)
+static void at91_adc_no_pen_detect_interrupt(struct iio_dev *indio_dev)
{
- struct iio_dev *indio_dev = iio_priv_to_dev(st);
+ struct at91_adc_state *st = iio_priv(indio_dev);
at91_adc_writel(st, AT91_SAMA5D2_TRGR,
AT91_SAMA5D2_TRGR_TRGMOD_NO_TRIGGER);
@@ -1297,7 +1298,7 @@ static void at91_adc_workq_handler(struct work_struct *workq)
struct at91_adc_touch, workq);
struct at91_adc_state *st = container_of(touch_st,
struct at91_adc_state, touch_st);
- struct iio_dev *indio_dev = iio_priv_to_dev(st);
+ struct iio_dev *indio_dev = st->indio_dev;
iio_push_to_buffers(indio_dev, st->buffer);
}
@@ -1318,7 +1319,7 @@ static irqreturn_t at91_adc_interrupt(int irq, void *private)
at91_adc_pen_detect_interrupt(st);
} else if ((status & AT91_SAMA5D2_IER_NOPEN)) {
/* nopen detected IRQ */
- at91_adc_no_pen_detect_interrupt(st);
+ at91_adc_no_pen_detect_interrupt(indio);
} else if ((status & AT91_SAMA5D2_ISR_PENS) &&
((status & rdy_mask) == rdy_mask)) {
/* periodic trigger IRQ - during pen sense */
@@ -1486,7 +1487,7 @@ static int at91_adc_write_raw(struct iio_dev *indio_dev,
val > st->soc_info.max_sample_rate)
return -EINVAL;
- at91_adc_setup_samp_freq(st, val);
+ at91_adc_setup_samp_freq(indio_dev, val);
return 0;
default:
return -EINVAL;
@@ -1624,8 +1625,10 @@ static int at91_adc_update_scan_mode(struct iio_dev *indio_dev,
return 0;
}
-static void at91_adc_hw_init(struct at91_adc_state *st)
+static void at91_adc_hw_init(struct iio_dev *indio_dev)
{
+ struct at91_adc_state *st = iio_priv(indio_dev);
+
at91_adc_writel(st, AT91_SAMA5D2_CR, AT91_SAMA5D2_CR_SWRST);
at91_adc_writel(st, AT91_SAMA5D2_IDR, 0xffffffff);
/*
@@ -1635,7 +1638,7 @@ static void at91_adc_hw_init(struct at91_adc_state *st)
at91_adc_writel(st, AT91_SAMA5D2_MR,
AT91_SAMA5D2_MR_TRANSFER(2) | AT91_SAMA5D2_MR_ANACH);
- at91_adc_setup_samp_freq(st, st->soc_info.min_sample_rate);
+ at91_adc_setup_samp_freq(indio_dev, st->soc_info.min_sample_rate);
/* configure extended mode register */
at91_adc_config_emr(st);
@@ -1718,6 +1721,7 @@ static int at91_adc_probe(struct platform_device *pdev)
indio_dev->num_channels = ARRAY_SIZE(at91_adc_channels);
st = iio_priv(indio_dev);
+ st->indio_dev = indio_dev;
bitmap_set(&st->touch_st.channels_bitmask,
AT91_SAMA5D2_TOUCH_X_CHAN_IDX, 1);
@@ -1829,7 +1833,7 @@ static int at91_adc_probe(struct platform_device *pdev)
goto vref_disable;
}
- at91_adc_hw_init(st);
+ at91_adc_hw_init(indio_dev);
ret = clk_prepare_enable(st->per_clk);
if (ret)
@@ -1945,7 +1949,7 @@ static __maybe_unused int at91_adc_resume(struct device *dev)
if (ret)
goto vref_disable_resume;
- at91_adc_hw_init(st);
+ at91_adc_hw_init(indio_dev);
/* reconfiguring trigger hardware state */
if (!iio_buffer_enabled(indio_dev))
--
2.25.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 v5 09/13] soc: mediatek: cmdq: add write_s value function
From: Dennis-YC Hsieh @ 2020-05-25 10:38 UTC (permalink / raw)
To: Matthias Brugger
Cc: Mark Rutland, devicetree, Philipp Zabel, wsd_upstream,
David Airlie, Jassi Brar, linux-kernel, dri-devel, HS Liao,
Rob Herring, linux-mediatek, Houlong Wei, Daniel Vetter, CK Hu,
Bibby Hsieh, linux-arm-kernel
In-Reply-To: <68535bf6-9824-5077-4811-374c893cdc03@gmail.com>
On Mon, 2020-05-25 at 10:39 +0200, Matthias Brugger wrote:
>
> On 25/05/2020 04:27, Dennis-YC Hsieh wrote:
> >
> > On Sun, 2020-05-24 at 20:13 +0200, Matthias Brugger wrote:
> >>
> >> On 24/05/2020 19:31, Dennis-YC Hsieh wrote:
> >>> Hi Matthias,
> >>>
> >>> Thanks for your comment.
> >>>
> >>> On Sat, 2020-05-16 at 20:20 +0200, Matthias Brugger wrote:
> >>>>
> >>>> On 08/03/2020 11:52, Dennis YC Hsieh wrote:
> >>>>> add write_s function in cmdq helper functions which
> >>>>> writes a constant value to address with large dma
> >>>>> access support.
> >>>>>
> >>>>> Signed-off-by: Dennis YC Hsieh <dennis-yc.hsieh@mediatek.com>
> >>>>> Reviewed-by: CK Hu <ck.hu@mediatek.com>
> >>>>> ---
> >>>>> drivers/soc/mediatek/mtk-cmdq-helper.c | 26 ++++++++++++++++++++++++++
> >>>>> include/linux/soc/mediatek/mtk-cmdq.h | 14 ++++++++++++++
> >>>>> 2 files changed, 40 insertions(+)
> >>>>>
> >>>>> diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c
> >>>>> index 03c129230cd7..a9ebbabb7439 100644
> >>>>> --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> >>>>> +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> >>>>> @@ -269,6 +269,32 @@ int cmdq_pkt_write_s(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
> >>>>> }
> >>>>> EXPORT_SYMBOL(cmdq_pkt_write_s);
> >>>>>
> >>>>> +int cmdq_pkt_write_s_value(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
> >>>>> + u16 addr_low, u32 value, u32 mask)
> >>>>> +{
> >>>>> + struct cmdq_instruction inst = { {0} };
> >>>>> + int err;
> >>>>> +
> >>>>> + if (mask != U32_MAX) {
> >>>>> + inst.op = CMDQ_CODE_MASK;
> >>>>> + inst.mask = ~mask;
> >>>>> + err = cmdq_pkt_append_command(pkt, inst);
> >>>>> + if (err < 0)
> >>>>> + return err;
> >>>>> +
> >>>>> + inst.op = CMDQ_CODE_WRITE_S_MASK;
> >>>>> + } else {
> >>>>> + inst.op = CMDQ_CODE_WRITE_S;
> >>>>> + }
> >>>>> +
> >>>>> + inst.sop = high_addr_reg_idx;
> >>>>
> >>>> Writing u16 value in a 5 bit wide variable?
> >>>
> >>> We need only 5 bits in this case. I'll change high_addr_reg_idx
> >>> parameter to u8.
> >>>
> >>
> >> Ok, please make sure to mask the value, so that it's explicit in the code that
> >> we only use the lowest 5 bits of high_addr_reg_idx.
> >
> > Is it necessary to mask the value?
> > Since sop already defined as "u8 sop:5;", I thought it is explicit that
> > only use 5 bits and compiler should do the rest jobs.
>
> Yes but it makes the code more explicit if we have a
> inst.sop = high_addr_reg_idx & 0x1f;
>
> What do you think?
The value assign to sop will restrict by hardware spec. Clients call
this function will define constant value and use it as parameter. So I
think we don't worry about client call this api with wrong value.
Regards,
Dennis
>
> Regards,
> Matthias
>
> >
> >
> > Regards,
> > Dennis
> >
> >>
> >> Regards,
> >> Matthias
> >>
> >>>>
> >>>>> + inst.offset = addr_low;
> >>>>> + inst.value = value;
> >>>>> +
> >>>>> + return cmdq_pkt_append_command(pkt, inst);
> >>>>> +}
> >>>>> +EXPORT_SYMBOL(cmdq_pkt_write_s_value);
> >>>>> +
> >>>>> int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
> >>>>> {
> >>>>> struct cmdq_instruction inst = { {0} };
> >>>>> diff --git a/include/linux/soc/mediatek/mtk-cmdq.h b/include/linux/soc/mediatek/mtk-cmdq.h
> >>>>> index 01b4184af310..fec292aac83c 100644
> >>>>> --- a/include/linux/soc/mediatek/mtk-cmdq.h
> >>>>> +++ b/include/linux/soc/mediatek/mtk-cmdq.h
> >>>>> @@ -135,6 +135,20 @@ int cmdq_pkt_read_s(struct cmdq_pkt *pkt, u16 high_addr_reg_idx, u16 addr_low,
> >>>>> int cmdq_pkt_write_s(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
> >>>>> u16 addr_low, u16 src_reg_idx, u32 mask);
> >>>>>
> >>>>> +/**
> >>>>> + * cmdq_pkt_write_s_value() - append write_s command with mask to the CMDQ
> >>>>> + * packet which write value to a physical address
> >>>>> + * @pkt: the CMDQ packet
> >>>>> + * @high_addr_reg_idx: internal regisger ID which contains high address of pa
> >>>>
> >>>> register
> >>>
> >>> will fix
> >>>
> >>>
> >>> Regards,
> >>> Dennis
> >>>
> >>>>
> >>>>> + * @addr_low: low address of pa
> >>>>> + * @value: the specified target value
> >>>>> + * @mask: the specified target mask
> >>>>> + *
> >>>>> + * Return: 0 for success; else the error code is returned
> >>>>> + */
> >>>>> +int cmdq_pkt_write_s_value(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
> >>>>> + u16 addr_low, u32 value, u32 mask);
> >>>>> +
> >>>>> /**
> >>>>> * cmdq_pkt_wfe() - append wait for event command to the CMDQ packet
> >>>>> * @pkt: the CMDQ packet
> >>>>>
> >>>
> >
_______________________________________________
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 10/13] soc: mediatek: cmdq: export finalize function
From: Chun-Kuang Hu @ 2020-05-25 10:48 UTC (permalink / raw)
To: Matthias Brugger
Cc: Mark Rutland, Chun-Kuang Hu, Daniel Vetter, wsd_upstream,
devicetree, David Airlie, Jassi Brar, linux-kernel,
DRI Development, HS Liao, Dennis YC Hsieh, Rob Herring,
moderated list:ARM/Mediatek SoC support, Houlong Wei,
Philipp Zabel, Linux ARM
In-Reply-To: <e487573a-2252-cd52-3a3d-c271f67fcb9a@gmail.com>
Hi, Matthias:
Matthias Brugger <matthias.bgg@gmail.com> 於 2020年5月25日 週一 下午4:38寫道：
>
>
>
> On 25/05/2020 02:23, Chun-Kuang Hu wrote:
> > Hi, Matthias:
> >
> > Matthias Brugger <matthias.bgg@gmail.com> 於 2020年5月17日 週日 上午2:22寫道：
> >>
> >>
> >>
> >> On 08/03/2020 11:52, Dennis YC Hsieh wrote:
> >>> Export finalize function to client which helps append eoc and jump
> >>> command to pkt. Let client decide call finalize or not.
> >>>
> >>> Signed-off-by: Dennis YC Hsieh <dennis-yc.hsieh@mediatek.com>
> >>> Reviewed-by: CK Hu <ck.hu@mediatek.com>
> >>> ---
> >>> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 1 +
> >>> drivers/soc/mediatek/mtk-cmdq-helper.c | 7 ++-----
> >>> include/linux/soc/mediatek/mtk-cmdq.h | 8 ++++++++
> >>> 3 files changed, 11 insertions(+), 5 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> >>> index 0dfcd1787e65..7daaabc26eb1 100644
> >>> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> >>> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> >>> @@ -490,6 +490,7 @@ static void mtk_drm_crtc_hw_config(struct mtk_drm_crtc *mtk_crtc)
> >>> cmdq_pkt_clear_event(cmdq_handle, mtk_crtc->cmdq_event);
> >>> cmdq_pkt_wfe(cmdq_handle, mtk_crtc->cmdq_event);
> >>> mtk_crtc_ddp_config(crtc, cmdq_handle);
> >>> + cmdq_pkt_finalize(cmdq_handle);
> >>> cmdq_pkt_flush_async(cmdq_handle, ddp_cmdq_cb, cmdq_handle);
> >>> }
> >>> #endif
> >>
> >> This should be a independent patch.
> >> Other then that patch looks good.
> >
> > Apply only drm part or only cmdq helpr part, it would be abnormal.
>
> Right it would break DRM driver (if only applied to cmdq) or compilation if only
> applied to DRM.
>
> > Shall we seperate this patch?
>
> After thinking twice, I think we can leave it as it is. If you provide your
> Acked-by I can take it thorugh my tree, if that's OK for you.
This is OK for me, so
Acked-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
>
> Regards,
> Matthias
>
> > Or seperate it but make sure these two patches be in the same tree?
> >
> > Regards,
> > Chun-Kuang.
> >
> >>
> >>> diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c
> >>> index a9ebbabb7439..59bc1164b411 100644
> >>> --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> >>> +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> >>> @@ -372,7 +372,7 @@ int cmdq_pkt_assign(struct cmdq_pkt *pkt, u16 reg_idx, u32 value)
> >>> }
> >>> EXPORT_SYMBOL(cmdq_pkt_assign);
> >>>
> >>> -static int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
> >>> +int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
> >>> {
> >>> struct cmdq_instruction inst = { {0} };
> >>> int err;
> >>> @@ -392,6 +392,7 @@ static int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
> >>>
> >>> return err;
> >>> }
> >>> +EXPORT_SYMBOL(cmdq_pkt_finalize);
> >>>
> >>> static void cmdq_pkt_flush_async_cb(struct cmdq_cb_data data)
> >>> {
> >>> @@ -426,10 +427,6 @@ int cmdq_pkt_flush_async(struct cmdq_pkt *pkt, cmdq_async_flush_cb cb,
> >>> unsigned long flags = 0;
> >>> struct cmdq_client *client = (struct cmdq_client *)pkt->cl;
> >>>
> >>> - err = cmdq_pkt_finalize(pkt);
> >>> - if (err < 0)
> >>> - return err;
> >>> -
> >>> pkt->cb.cb = cb;
> >>> pkt->cb.data = data;
> >>> pkt->async_cb.cb = cmdq_pkt_flush_async_cb;
> >>> diff --git a/include/linux/soc/mediatek/mtk-cmdq.h b/include/linux/soc/mediatek/mtk-cmdq.h
> >>> index fec292aac83c..99e77155f967 100644
> >>> --- a/include/linux/soc/mediatek/mtk-cmdq.h
> >>> +++ b/include/linux/soc/mediatek/mtk-cmdq.h
> >>> @@ -213,6 +213,14 @@ int cmdq_pkt_poll_mask(struct cmdq_pkt *pkt, u8 subsys,
> >>> */
> >>> int cmdq_pkt_assign(struct cmdq_pkt *pkt, u16 reg_idx, u32 value);
> >>>
> >>> +/**
> >>> + * cmdq_pkt_finalize() - Append EOC and jump command to pkt.
> >>> + * @pkt: the CMDQ packet
> >>> + *
> >>> + * Return: 0 for success; else the error code is returned
> >>> + */
> >>> +int cmdq_pkt_finalize(struct cmdq_pkt *pkt);
> >>> +
> >>> /**
> >>> * cmdq_pkt_flush_async() - trigger CMDQ to asynchronously execute the CMDQ
> >>> * packet and call back at the end of done packet
> >>>
> >> _______________________________________________
> >> dri-devel mailing list
> >> dri-devel@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox