* Re: [PATCH 3/3] drm/panel: simple: fix osd070t1718_19ts sync drive edge
From: Sam Ravnborg @ 2020-02-14 21:39 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: devicetree, Tony Lindgren, Jyri Sarha, Peter Ujfalusi,
Thierry Reding, dri-devel, Laurent Pinchart
In-Reply-To: <a9cf515c-dbdd-e70d-5a89-1211c1049d16@ti.com>
Hi Tomi.
On Mon, Feb 10, 2020 at 10:15:33AM +0200, Tomi Valkeinen wrote:
> Hi Thierry,
>
> On 02/12/2019 15:07, Laurent Pinchart wrote:
> > Hi Tomi,
> >
> > Thank you for the patch.
> >
> > On Thu, Nov 14, 2019 at 11:39:50AM +0200, Tomi Valkeinen wrote:
> > > The panel datasheet says that the panel samples at falling edge, but
> > > does not say anything about h/v sync signals. Testing shows that if the
> > > sync signals are driven on falling edge, the picture on the panel will
> > > be slightly shifted right.
> > >
> > > Setting sync drive edge to the same as data drive edge fixes this issue.
> > >
> > > Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> >
> > I don't have access to the documentation, but this makes sense, so
> >
> > Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> >
> > > ---
> > > drivers/gpu/drm/panel/panel-simple.c | 3 ++-
> > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> > > index 5d487686d25c..0784536ae6af 100644
> > > --- a/drivers/gpu/drm/panel/panel-simple.c
> > > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > > @@ -2397,7 +2397,8 @@ static const struct panel_desc osddisplays_osd070t1718_19ts = {
> > > .height = 91,
> > > },
> > > .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
> > > - .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE,
> > > + .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE |
> > > + DRM_BUS_FLAG_SYNC_DRIVE_POSEDGE,
> > > .connector_type = DRM_MODE_CONNECTOR_DPI,
> > > };
>
> Can this be merged?
I have lost the original mail.
Can you re-send or provide a patchwork pointer or similar.
Then I will apply.
PS. Mail had been stuck in my spam quarantine so did not get it until
now.
Sam
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 3/3] drm/panel: simple: fix osd070t1718_19ts sync drive edge
From: Sam Ravnborg @ 2020-02-14 21:39 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Thierry Reding, devicetree, Tony Lindgren, dri-devel, Jyri Sarha,
Peter Ujfalusi, Laurent Pinchart
In-Reply-To: <a9cf515c-dbdd-e70d-5a89-1211c1049d16@ti.com>
Hi Tomi.
On Mon, Feb 10, 2020 at 10:15:33AM +0200, Tomi Valkeinen wrote:
> Hi Thierry,
>
> On 02/12/2019 15:07, Laurent Pinchart wrote:
> > Hi Tomi,
> >
> > Thank you for the patch.
> >
> > On Thu, Nov 14, 2019 at 11:39:50AM +0200, Tomi Valkeinen wrote:
> > > The panel datasheet says that the panel samples at falling edge, but
> > > does not say anything about h/v sync signals. Testing shows that if the
> > > sync signals are driven on falling edge, the picture on the panel will
> > > be slightly shifted right.
> > >
> > > Setting sync drive edge to the same as data drive edge fixes this issue.
> > >
> > > Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> >
> > I don't have access to the documentation, but this makes sense, so
> >
> > Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> >
> > > ---
> > > drivers/gpu/drm/panel/panel-simple.c | 3 ++-
> > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> > > index 5d487686d25c..0784536ae6af 100644
> > > --- a/drivers/gpu/drm/panel/panel-simple.c
> > > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > > @@ -2397,7 +2397,8 @@ static const struct panel_desc osddisplays_osd070t1718_19ts = {
> > > .height = 91,
> > > },
> > > .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
> > > - .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE,
> > > + .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE |
> > > + DRM_BUS_FLAG_SYNC_DRIVE_POSEDGE,
> > > .connector_type = DRM_MODE_CONNECTOR_DPI,
> > > };
>
> Can this be merged?
I have lost the original mail.
Can you re-send or provide a patchwork pointer or similar.
Then I will apply.
PS. Mail had been stuck in my spam quarantine so did not get it until
now.
Sam
^ permalink raw reply
* Re: Feature Suggestion: Allow to enforce "rename" in git while committing
From: Junio C Hamano @ 2020-02-14 21:38 UTC (permalink / raw)
To: Bruno Macabeus; +Cc: git
In-Reply-To: <CANnkH-ViK9qySZGi=xbcE4YDiskhLxDsH21DMxTEHi6=X0EZuQ@mail.gmail.com>
Bruno Macabeus <bruno.macabeus@gmail.com> writes:
> I should not create one commit just renaming the file and on another
> commit updating its content, because the project won't build on the
> first commit (since the build steps is different on a .ts file). And I
> don't want to create a commit that the project can't be built on.
Even if you did the two-step renaming, comparing the end result
(i.e. HEAD) with the state before these two commits (i.e. HEAD~2,
before renaming and before editing) with "git diff HEAD~2 HEAD" will
not behave any differently if you did the renaming and modifying in
a single commit. So it does not make much sense to split it into
two artificial steps at all.
^ permalink raw reply
* Re: [PATCH v2 2/2] drm/bridge: anx7688: Add anx7688 bridge driver support
From: Vasily Khoruzhick @ 2020-02-14 21:36 UTC (permalink / raw)
To: Enric Balletbo i Serra
Cc: linux-kernel, Collabora Kernel ML, Andrzej Hajda, matthias.bgg,
drinkcat, hsinyi, Neil Armstrong, David Airlie, Jonas Karlman,
dri-devel, Maxime Ripard, Thomas Gleixner, Icenowy Zheng,
Jernej Skrabec, Torsten Duwe, Laurent Pinchart, Daniel Vetter
In-Reply-To: <20200213145416.890080-2-enric.balletbo@collabora.com>
On Thu, Feb 13, 2020 at 6:54 AM Enric Balletbo i Serra
<enric.balletbo@collabora.com> wrote:
>
> From: Nicolas Boichat <drinkcat@chromium.org>
>
> ANX7688 is a HDMI to DP converter (as well as USB-C port controller),
> that has an internal microcontroller.
>
> The only reason a Linux kernel driver is necessary is to reject
> resolutions that require more bandwidth than what is available on
> the DP side. DP bandwidth and lane count are reported by the bridge
> via 2 registers on I2C.
It is true only for your particular platform where usb-c part is
managed by firmware. Pinephone has the same anx7688 but linux will
need a driver that manages usb-c in addition to DP.
I'd suggest making it MFD driver from the beginning, or at least make
proper bindings so we don't have to rework it and introduce binding
incompatibilities in future.
> Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
> Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> ---
>
> Changes in v2:
> - Move driver to drivers/gpu/drm/bridge/analogix.
> - Make the driver OF only so we can reduce the ifdefs.
> - Update the Copyright to 2020.
> - Use probe_new so we can get rid of the i2c_device_id table.
>
> drivers/gpu/drm/bridge/analogix/Kconfig | 12 ++
> drivers/gpu/drm/bridge/analogix/Makefile | 1 +
> .../drm/bridge/analogix/analogix-anx7688.c | 188 ++++++++++++++++++
> 3 files changed, 201 insertions(+)
> create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-anx7688.c
>
> diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig b/drivers/gpu/drm/bridge/analogix/Kconfig
> index e1fa7d820373..af7c2939403c 100644
> --- a/drivers/gpu/drm/bridge/analogix/Kconfig
> +++ b/drivers/gpu/drm/bridge/analogix/Kconfig
> @@ -11,6 +11,18 @@ config DRM_ANALOGIX_ANX6345
> ANX6345 transforms the LVTTL RGB output of an
> application processor to eDP or DisplayPort.
>
> +config DRM_ANALOGIX_ANX7688
> + tristate "Analogix ANX7688 bridge"
> + depends on OF
> + select DRM_KMS_HELPER
> + select REGMAP_I2C
> + help
> + ANX7688 is an ultra-low power 4k Ultra-HD (4096x2160p60)
> + mobile HD transmitter designed for portable devices. The
> + ANX7688 converts HDMI 2.0 to DisplayPort 1.3 Ultra-HD
> + including an intelligent crosspoint switch to support
> + USB Type-C.
> +
> config DRM_ANALOGIX_ANX78XX
> tristate "Analogix ANX78XX bridge"
> select DRM_ANALOGIX_DP
> diff --git a/drivers/gpu/drm/bridge/analogix/Makefile b/drivers/gpu/drm/bridge/analogix/Makefile
> index 97669b374098..27cd73635c8c 100644
> --- a/drivers/gpu/drm/bridge/analogix/Makefile
> +++ b/drivers/gpu/drm/bridge/analogix/Makefile
> @@ -1,5 +1,6 @@
> # SPDX-License-Identifier: GPL-2.0-only
> analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o analogix-i2c-dptx.o
> obj-$(CONFIG_DRM_ANALOGIX_ANX6345) += analogix-anx6345.o
> +obj-$(CONFIG_DRM_ANALOGIX_ANX7688) += analogix-anx7688.o
> obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
> obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp.o
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx7688.c b/drivers/gpu/drm/bridge/analogix/analogix-anx7688.c
> new file mode 100644
> index 000000000000..10a7cd0f9126
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx7688.c
> @@ -0,0 +1,188 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * ANX7688 HDMI->DP bridge driver
> + *
> + * Copyright 2020 Google LLC
> + */
> +
> +#include <linux/i2c.h>
> +#include <linux/module.h>
> +#include <linux/regmap.h>
> +#include <drm/drm_bridge.h>
> +
> +/* Register addresses */
> +#define VENDOR_ID_REG 0x00
> +#define DEVICE_ID_REG 0x02
> +
> +#define FW_VERSION_REG 0x80
> +
> +#define DP_BANDWIDTH_REG 0x85
> +#define DP_LANE_COUNT_REG 0x86
> +
> +#define VENDOR_ID 0x1f29
> +#define DEVICE_ID 0x7688
> +
> +/* First supported firmware version (0.85) */
> +#define MINIMUM_FW_VERSION 0x0085
> +
> +struct anx7688 {
> + struct drm_bridge bridge;
> + struct i2c_client *client;
> + struct regmap *regmap;
> +
> + bool filter;
> +};
> +
> +static inline struct anx7688 *bridge_to_anx7688(struct drm_bridge *bridge)
> +{
> + return container_of(bridge, struct anx7688, bridge);
> +}
> +
> +static bool anx7688_bridge_mode_fixup(struct drm_bridge *bridge,
> + const struct drm_display_mode *mode,
> + struct drm_display_mode *adjusted_mode)
> +{
> + struct anx7688 *anx7688 = bridge_to_anx7688(bridge);
> + int totalbw, requiredbw;
> + u8 dpbw, lanecount;
> + u8 regs[2];
> + int ret;
> +
> + if (!anx7688->filter)
> + return true;
> +
> + /* Read both regs 0x85 (bandwidth) and 0x86 (lane count). */
> + ret = regmap_bulk_read(anx7688->regmap, DP_BANDWIDTH_REG, regs, 2);
> + if (ret < 0) {
> + dev_err(&anx7688->client->dev,
> + "Failed to read bandwidth/lane count\n");
> + return false;
> + }
> + dpbw = regs[0];
> + lanecount = regs[1];
> +
> + /* Maximum 0x19 bandwidth (6.75 Gbps Turbo mode), 2 lanes */
> + if (dpbw > 0x19 || lanecount > 2) {
> + dev_err(&anx7688->client->dev,
> + "Invalid bandwidth/lane count (%02x/%d)\n",
> + dpbw, lanecount);
> + return false;
> + }
> +
> + /* Compute available bandwidth (kHz) */
> + totalbw = dpbw * lanecount * 270000 * 8 / 10;
> +
> + /* Required bandwidth (8 bpc, kHz) */
> + requiredbw = mode->clock * 8 * 3;
> +
> + dev_dbg(&anx7688->client->dev,
> + "DP bandwidth: %d kHz (%02x/%d); mode requires %d Khz\n",
> + totalbw, dpbw, lanecount, requiredbw);
> +
> + if (totalbw == 0) {
> + dev_warn(&anx7688->client->dev,
> + "Bandwidth/lane count are 0, not rejecting modes\n");
> + return true;
> + }
> +
> + return totalbw >= requiredbw;
> +}
> +
> +static const struct drm_bridge_funcs anx7688_bridge_funcs = {
> + .mode_fixup = anx7688_bridge_mode_fixup,
> +};
> +
> +static const struct regmap_config anx7688_regmap_config = {
> + .reg_bits = 8,
> + .val_bits = 8,
> +};
> +
> +static int anx7688_i2c_probe(struct i2c_client *client)
> +{
> + struct device *dev = &client->dev;
> + struct anx7688 *anx7688;
> + u16 vendor, device;
> + u16 fwversion;
> + u8 buffer[4];
> + int ret;
> +
> + anx7688 = devm_kzalloc(dev, sizeof(*anx7688), GFP_KERNEL);
> + if (!anx7688)
> + return -ENOMEM;
> +
> + anx7688->bridge.of_node = dev->of_node;
> + anx7688->client = client;
> + i2c_set_clientdata(client, anx7688);
> +
> + anx7688->regmap = devm_regmap_init_i2c(client, &anx7688_regmap_config);
> +
> + /* Read both vendor and device id (4 bytes). */
> + ret = regmap_bulk_read(anx7688->regmap, VENDOR_ID_REG, buffer, 4);
> + if (ret) {
> + dev_err(dev, "Failed to read chip vendor/device id\n");
> + return ret;
> + }
> +
> + vendor = (u16)buffer[1] << 8 | buffer[0];
> + device = (u16)buffer[3] << 8 | buffer[2];
> + if (vendor != VENDOR_ID || device != DEVICE_ID) {
> + dev_err(dev, "Invalid vendor/device id %04x/%04x\n",
> + vendor, device);
> + return -ENODEV;
> + }
> +
> + ret = regmap_bulk_read(anx7688->regmap, FW_VERSION_REG, buffer, 2);
> + if (ret) {
> + dev_err(&client->dev, "Failed to read firmware version\n");
> + return ret;
> + }
> +
> + fwversion = (u16)buffer[0] << 8 | buffer[1];
> + dev_info(dev, "ANX7688 firwmare version %02x.%02x\n",
> + buffer[0], buffer[1]);
> +
> + /* FW version >= 0.85 supports bandwidth/lane count registers */
> + if (fwversion >= MINIMUM_FW_VERSION) {
> + anx7688->filter = true;
> + } else {
> + /* Warn, but not fail, for backwards compatibility. */
> + dev_warn(dev,
> + "Old ANX7688 FW version (%02x.%02x), not filtering\n",
> + buffer[0], buffer[1]);
> + }
> +
> + anx7688->bridge.funcs = &anx7688_bridge_funcs;
> + drm_bridge_add(&anx7688->bridge);
> +
> + return 0;
> +}
> +
> +static int anx7688_i2c_remove(struct i2c_client *client)
> +{
> + struct anx7688 *anx7688 = i2c_get_clientdata(client);
> +
> + drm_bridge_remove(&anx7688->bridge);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id anx7688_match_table[] = {
> + { .compatible = "analogix,anx7688", },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, anx7688_match_table);
> +
> +static struct i2c_driver anx7688_driver = {
> + .probe_new = anx7688_i2c_probe,
> + .remove = anx7688_i2c_remove,
> + .driver = {
> + .name = "anx7688",
> + .of_match_table = anx7688_match_table,
> + },
> +};
> +
> +module_i2c_driver(anx7688_driver);
> +
> +MODULE_DESCRIPTION("ANX7688 HDMI->DP bridge driver");
> +MODULE_AUTHOR("Nicolas Boichat <drinkcat@chromium.org>");
> +MODULE_LICENSE("GPL");
> --
> 2.25.0
>
^ permalink raw reply
* Re: [PATCH v2 2/2] drm/bridge: anx7688: Add anx7688 bridge driver support
From: Vasily Khoruzhick @ 2020-02-14 21:36 UTC (permalink / raw)
To: Enric Balletbo i Serra
Cc: Jernej Skrabec, drinkcat, Laurent Pinchart, Neil Armstrong,
David Airlie, Torsten Duwe, Jonas Karlman, linux-kernel,
dri-devel, Andrzej Hajda, Maxime Ripard, hsinyi, matthias.bgg,
Thomas Gleixner, Collabora Kernel ML, Icenowy Zheng
In-Reply-To: <20200213145416.890080-2-enric.balletbo@collabora.com>
On Thu, Feb 13, 2020 at 6:54 AM Enric Balletbo i Serra
<enric.balletbo@collabora.com> wrote:
>
> From: Nicolas Boichat <drinkcat@chromium.org>
>
> ANX7688 is a HDMI to DP converter (as well as USB-C port controller),
> that has an internal microcontroller.
>
> The only reason a Linux kernel driver is necessary is to reject
> resolutions that require more bandwidth than what is available on
> the DP side. DP bandwidth and lane count are reported by the bridge
> via 2 registers on I2C.
It is true only for your particular platform where usb-c part is
managed by firmware. Pinephone has the same anx7688 but linux will
need a driver that manages usb-c in addition to DP.
I'd suggest making it MFD driver from the beginning, or at least make
proper bindings so we don't have to rework it and introduce binding
incompatibilities in future.
> Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
> Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> ---
>
> Changes in v2:
> - Move driver to drivers/gpu/drm/bridge/analogix.
> - Make the driver OF only so we can reduce the ifdefs.
> - Update the Copyright to 2020.
> - Use probe_new so we can get rid of the i2c_device_id table.
>
> drivers/gpu/drm/bridge/analogix/Kconfig | 12 ++
> drivers/gpu/drm/bridge/analogix/Makefile | 1 +
> .../drm/bridge/analogix/analogix-anx7688.c | 188 ++++++++++++++++++
> 3 files changed, 201 insertions(+)
> create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-anx7688.c
>
> diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig b/drivers/gpu/drm/bridge/analogix/Kconfig
> index e1fa7d820373..af7c2939403c 100644
> --- a/drivers/gpu/drm/bridge/analogix/Kconfig
> +++ b/drivers/gpu/drm/bridge/analogix/Kconfig
> @@ -11,6 +11,18 @@ config DRM_ANALOGIX_ANX6345
> ANX6345 transforms the LVTTL RGB output of an
> application processor to eDP or DisplayPort.
>
> +config DRM_ANALOGIX_ANX7688
> + tristate "Analogix ANX7688 bridge"
> + depends on OF
> + select DRM_KMS_HELPER
> + select REGMAP_I2C
> + help
> + ANX7688 is an ultra-low power 4k Ultra-HD (4096x2160p60)
> + mobile HD transmitter designed for portable devices. The
> + ANX7688 converts HDMI 2.0 to DisplayPort 1.3 Ultra-HD
> + including an intelligent crosspoint switch to support
> + USB Type-C.
> +
> config DRM_ANALOGIX_ANX78XX
> tristate "Analogix ANX78XX bridge"
> select DRM_ANALOGIX_DP
> diff --git a/drivers/gpu/drm/bridge/analogix/Makefile b/drivers/gpu/drm/bridge/analogix/Makefile
> index 97669b374098..27cd73635c8c 100644
> --- a/drivers/gpu/drm/bridge/analogix/Makefile
> +++ b/drivers/gpu/drm/bridge/analogix/Makefile
> @@ -1,5 +1,6 @@
> # SPDX-License-Identifier: GPL-2.0-only
> analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o analogix-i2c-dptx.o
> obj-$(CONFIG_DRM_ANALOGIX_ANX6345) += analogix-anx6345.o
> +obj-$(CONFIG_DRM_ANALOGIX_ANX7688) += analogix-anx7688.o
> obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
> obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp.o
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx7688.c b/drivers/gpu/drm/bridge/analogix/analogix-anx7688.c
> new file mode 100644
> index 000000000000..10a7cd0f9126
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx7688.c
> @@ -0,0 +1,188 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * ANX7688 HDMI->DP bridge driver
> + *
> + * Copyright 2020 Google LLC
> + */
> +
> +#include <linux/i2c.h>
> +#include <linux/module.h>
> +#include <linux/regmap.h>
> +#include <drm/drm_bridge.h>
> +
> +/* Register addresses */
> +#define VENDOR_ID_REG 0x00
> +#define DEVICE_ID_REG 0x02
> +
> +#define FW_VERSION_REG 0x80
> +
> +#define DP_BANDWIDTH_REG 0x85
> +#define DP_LANE_COUNT_REG 0x86
> +
> +#define VENDOR_ID 0x1f29
> +#define DEVICE_ID 0x7688
> +
> +/* First supported firmware version (0.85) */
> +#define MINIMUM_FW_VERSION 0x0085
> +
> +struct anx7688 {
> + struct drm_bridge bridge;
> + struct i2c_client *client;
> + struct regmap *regmap;
> +
> + bool filter;
> +};
> +
> +static inline struct anx7688 *bridge_to_anx7688(struct drm_bridge *bridge)
> +{
> + return container_of(bridge, struct anx7688, bridge);
> +}
> +
> +static bool anx7688_bridge_mode_fixup(struct drm_bridge *bridge,
> + const struct drm_display_mode *mode,
> + struct drm_display_mode *adjusted_mode)
> +{
> + struct anx7688 *anx7688 = bridge_to_anx7688(bridge);
> + int totalbw, requiredbw;
> + u8 dpbw, lanecount;
> + u8 regs[2];
> + int ret;
> +
> + if (!anx7688->filter)
> + return true;
> +
> + /* Read both regs 0x85 (bandwidth) and 0x86 (lane count). */
> + ret = regmap_bulk_read(anx7688->regmap, DP_BANDWIDTH_REG, regs, 2);
> + if (ret < 0) {
> + dev_err(&anx7688->client->dev,
> + "Failed to read bandwidth/lane count\n");
> + return false;
> + }
> + dpbw = regs[0];
> + lanecount = regs[1];
> +
> + /* Maximum 0x19 bandwidth (6.75 Gbps Turbo mode), 2 lanes */
> + if (dpbw > 0x19 || lanecount > 2) {
> + dev_err(&anx7688->client->dev,
> + "Invalid bandwidth/lane count (%02x/%d)\n",
> + dpbw, lanecount);
> + return false;
> + }
> +
> + /* Compute available bandwidth (kHz) */
> + totalbw = dpbw * lanecount * 270000 * 8 / 10;
> +
> + /* Required bandwidth (8 bpc, kHz) */
> + requiredbw = mode->clock * 8 * 3;
> +
> + dev_dbg(&anx7688->client->dev,
> + "DP bandwidth: %d kHz (%02x/%d); mode requires %d Khz\n",
> + totalbw, dpbw, lanecount, requiredbw);
> +
> + if (totalbw == 0) {
> + dev_warn(&anx7688->client->dev,
> + "Bandwidth/lane count are 0, not rejecting modes\n");
> + return true;
> + }
> +
> + return totalbw >= requiredbw;
> +}
> +
> +static const struct drm_bridge_funcs anx7688_bridge_funcs = {
> + .mode_fixup = anx7688_bridge_mode_fixup,
> +};
> +
> +static const struct regmap_config anx7688_regmap_config = {
> + .reg_bits = 8,
> + .val_bits = 8,
> +};
> +
> +static int anx7688_i2c_probe(struct i2c_client *client)
> +{
> + struct device *dev = &client->dev;
> + struct anx7688 *anx7688;
> + u16 vendor, device;
> + u16 fwversion;
> + u8 buffer[4];
> + int ret;
> +
> + anx7688 = devm_kzalloc(dev, sizeof(*anx7688), GFP_KERNEL);
> + if (!anx7688)
> + return -ENOMEM;
> +
> + anx7688->bridge.of_node = dev->of_node;
> + anx7688->client = client;
> + i2c_set_clientdata(client, anx7688);
> +
> + anx7688->regmap = devm_regmap_init_i2c(client, &anx7688_regmap_config);
> +
> + /* Read both vendor and device id (4 bytes). */
> + ret = regmap_bulk_read(anx7688->regmap, VENDOR_ID_REG, buffer, 4);
> + if (ret) {
> + dev_err(dev, "Failed to read chip vendor/device id\n");
> + return ret;
> + }
> +
> + vendor = (u16)buffer[1] << 8 | buffer[0];
> + device = (u16)buffer[3] << 8 | buffer[2];
> + if (vendor != VENDOR_ID || device != DEVICE_ID) {
> + dev_err(dev, "Invalid vendor/device id %04x/%04x\n",
> + vendor, device);
> + return -ENODEV;
> + }
> +
> + ret = regmap_bulk_read(anx7688->regmap, FW_VERSION_REG, buffer, 2);
> + if (ret) {
> + dev_err(&client->dev, "Failed to read firmware version\n");
> + return ret;
> + }
> +
> + fwversion = (u16)buffer[0] << 8 | buffer[1];
> + dev_info(dev, "ANX7688 firwmare version %02x.%02x\n",
> + buffer[0], buffer[1]);
> +
> + /* FW version >= 0.85 supports bandwidth/lane count registers */
> + if (fwversion >= MINIMUM_FW_VERSION) {
> + anx7688->filter = true;
> + } else {
> + /* Warn, but not fail, for backwards compatibility. */
> + dev_warn(dev,
> + "Old ANX7688 FW version (%02x.%02x), not filtering\n",
> + buffer[0], buffer[1]);
> + }
> +
> + anx7688->bridge.funcs = &anx7688_bridge_funcs;
> + drm_bridge_add(&anx7688->bridge);
> +
> + return 0;
> +}
> +
> +static int anx7688_i2c_remove(struct i2c_client *client)
> +{
> + struct anx7688 *anx7688 = i2c_get_clientdata(client);
> +
> + drm_bridge_remove(&anx7688->bridge);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id anx7688_match_table[] = {
> + { .compatible = "analogix,anx7688", },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, anx7688_match_table);
> +
> +static struct i2c_driver anx7688_driver = {
> + .probe_new = anx7688_i2c_probe,
> + .remove = anx7688_i2c_remove,
> + .driver = {
> + .name = "anx7688",
> + .of_match_table = anx7688_match_table,
> + },
> +};
> +
> +module_i2c_driver(anx7688_driver);
> +
> +MODULE_DESCRIPTION("ANX7688 HDMI->DP bridge driver");
> +MODULE_AUTHOR("Nicolas Boichat <drinkcat@chromium.org>");
> +MODULE_LICENSE("GPL");
> --
> 2.25.0
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [GIT PULL] Please pull NFS client bugfixes for 5.6-rc2
From: Schumaker, Anna @ 2020-02-14 21:35 UTC (permalink / raw)
To: torvalds@linux-foundation.org
Cc: linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org
Hi Linus,
The following changes since commit bb6d3fb354c5ee8d6bde2d576eb7220ea09862b9:
Linux 5.6-rc1 (2020-02-09 16:08:48 -0800)
are available in the Git repository at:
git://git.linux-nfs.org/projects/anna/linux-nfs.git tags/nfs-for-5.6-2
for you to fetch changes up to 5d63944f8206a80636ae8cb4b9107d3b49f43d37:
NFSv4: Ensure the delegation cred is pinned when we call delegreturn (2020-02-
13 16:23:02 -0500)
----------------------------------------------------------------
The only stable fix this time is the DMA scatter-gather list bug fixed by Chuck.
The rest fix up races and refcounting issues that have been found during
testing.
Thanks,
Anna
----------------------------------------------------------------
Chuck Lever (1):
xprtrdma: Fix DMA scatter-gather list mapping imbalance
Olga Kornievskaia (1):
NFSv4.1 make cachethis=no for writes
Trond Myklebust (5):
NFS: Fix up directory verifier races
NFSv4: Fix races between open and dentry revalidation
NFSv4: Fix revalidation of dentries with delegations
NFSv4: Ensure the delegation is pinned in nfs_do_return_delegation()
NFSv4: Ensure the delegation cred is pinned when we call delegreturn
fs/nfs/delegation.c | 50 ++++++++++++++++++++++++++++++++++++++++
----------
fs/nfs/delegation.h | 1 +
fs/nfs/dir.c | 126
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++----------
fs/nfs/inode.c | 1 +
fs/nfs/nfs4file.c | 1 -
fs/nfs/nfs4proc.c | 20 +++++++++++++++++---
include/linux/nfs_fs.h | 26 ++++++--------------------
net/sunrpc/xprtrdma/frwr_ops.c | 13 +++++++------
8 files changed, 188 insertions(+), 50 deletions(-)
^ permalink raw reply
* Re: [PATCH v2] KVM: X86: Grab KVM's srcu lock when accessing hv assist page
From: Sean Christopherson @ 2020-02-14 21:33 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Wanpeng Li, LKML, kvm, Wanpeng Li, Vitaly Kuznetsov, Jim Mattson,
Joerg Roedel
In-Reply-To: <7171e537-27f9-c1e5-ae32-9305710be2c7@redhat.com>
The subject shoud be rewritten to simply states that the vmcs12->shadow
sync is being. The changelog can explain the motiviation, but a one-line
git log should clearly reveal that this affects the shadow VMCS.
Subsystem should also be "KVM: nVMX:"
On Fri, Feb 14, 2020 at 10:27:12AM +0100, Paolo Bonzini wrote:
> On 14/02/20 10:16, Wanpeng Li wrote:
> > From: wanpeng li <wanpengli@tencent.com>
> >
> > For the duration of mapping eVMCS, it derefences ->memslots without holding
> > ->srcu or ->slots_lock when accessing hv assist page. This patch fixes it by
> > moving nested_sync_vmcs12_to_shadow to prepare_guest_switch, where the SRCU
> > is already taken.
>
> Looks good, but I'd like an extra review from Sean or Vitaly.
>
> We also should add a WARN_ON_ONCE that replaces the previous location of
> the "if (vmx->nested.need_vmcs12_to_shadow_sync)", but I can do that myself.
>
> Thanks,
>
> Paolo
>
> > It can be reproduced by running kvm's evmcs_test selftest.
> >
> > =============================
> > warning: suspicious rcu usage
> > 5.6.0-rc1+ #53 tainted: g w ioe
> > -----------------------------
> > ./include/linux/kvm_host.h:623 suspicious rcu_dereference_check() usage!
> >
> > other info that might help us debug this:
> >
> > rcu_scheduler_active = 2, debug_locks = 1
> > 1 lock held by evmcs_test/8507:
> > #0: ffff9ddd156d00d0 (&vcpu->mutex){+.+.}, at:
> > kvm_vcpu_ioctl+0x85/0x680 [kvm]
> >
> > stack backtrace:
> > cpu: 6 pid: 8507 comm: evmcs_test tainted: g w ioe 5.6.0-rc1+ #53
> > hardware name: dell inc. optiplex 7040/0jctf8, bios 1.4.9 09/12/2016
> > call trace:
> > dump_stack+0x68/0x9b
> > kvm_read_guest_cached+0x11d/0x150 [kvm]
> > kvm_hv_get_assist_page+0x33/0x40 [kvm]
> > nested_enlightened_vmentry+0x2c/0x60 [kvm_intel]
> > nested_vmx_handle_enlightened_vmptrld.part.52+0x32/0x1c0 [kvm_intel]
> > nested_sync_vmcs12_to_shadow+0x439/0x680 [kvm_intel]
> > vmx_vcpu_run+0x67a/0xe60 [kvm_intel]
> > vcpu_enter_guest+0x35e/0x1bc0 [kvm]
> > kvm_arch_vcpu_ioctl_run+0x40b/0x670 [kvm]
> > kvm_vcpu_ioctl+0x370/0x680 [kvm]
> > ksys_ioctl+0x235/0x850
> > __x64_sys_ioctl+0x16/0x20
> > do_syscall_64+0x77/0x780
> > entry_syscall_64_after_hwframe+0x49/0xbe
> >
> > Signed-off-by: Wanpeng Li <wanpengli@tencent.com>
> > ---
> > arch/x86/kvm/vmx/vmx.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
> > index 9a66648..6bd6ca4 100644
> > --- a/arch/x86/kvm/vmx/vmx.c
> > +++ b/arch/x86/kvm/vmx/vmx.c
> > @@ -1214,6 +1214,9 @@ void vmx_prepare_switch_to_guest(struct kvm_vcpu *vcpu)
> >
> > vmx_set_host_fs_gs(host_state, fs_sel, gs_sel, fs_base, gs_base);
> > vmx->guest_state_loaded = true;
> > +
> > + if (vmx->nested.need_vmcs12_to_shadow_sync)
> > + nested_sync_vmcs12_to_shadow(vcpu);
This needs to be above the short circuit check on guest_state_loaded, e.g.:
if (vmx->nested.need_vmcs12_to_shadow_sync)
nested_sync_vmcs12_to_shadow(vcpu);
if (vmx->guest_state_loaded)
return;
> > }
> >
> > static void vmx_prepare_switch_to_host(struct vcpu_vmx *vmx)
> > @@ -6480,9 +6483,6 @@ static void vmx_vcpu_run(struct kvm_vcpu *vcpu)
> > vmcs_write32(PLE_WINDOW, vmx->ple_window);
> > }
> >
> > - if (vmx->nested.need_vmcs12_to_shadow_sync)
> > - nested_sync_vmcs12_to_shadow(vcpu);
> > -
> > if (kvm_register_is_dirty(vcpu, VCPU_REGS_RSP))
> > vmcs_writel(GUEST_RSP, vcpu->arch.regs[VCPU_REGS_RSP]);
> > if (kvm_register_is_dirty(vcpu, VCPU_REGS_RIP))
> > --
> > 2.7.4
> >
>
^ permalink raw reply
* [PATCH 0/2] Add boot interrupt quirk mechanism for Xeon chipsets
From: Sean V Kelley @ 2020-02-14 21:33 UTC (permalink / raw)
To: tglx, bhelgaas, corbet, mingo, bp
Cc: x86, linux-pci, linux-kernel, linux-doc, kar.hin.ong, sassmann,
Sean V Kelley
When IRQ lines on secondary or higher IO-APICs are masked (e.g.,
Real-Time threaded interrupts), many chipsets redirect IRQs on
this line to the legacy PCH and in turn the base IO-APIC in the
system. The unhandled interrupts on the base IO-APIC will be
identified by the Linux kernel as Spurious Interrupts and can
lead to disabled IRQ lines.
Disabling this legacy PCI interrupt routing is chipset-specific and
varies in mechanism between chipset vendors and across generations.
In some cases the mechanism is exposed to BIOS but not all BIOS
vendors choose to pick it up. With the increasing usage of RT as it
marches towards mainline, additional issues have been raised with
more recent Xeon chipsets.
This patchset disables the boot interrupt on these Xeon chipsets where
this is possible with an additional mechanism. In addition, this
patchset includes documentation covering the background of this quirk.
Sean V Kelley (2):
pci: Add boot interrupt quirk mechanism for Xeon chipsets
Documentation:PCI: Add background on Boot Interrupts
Documentation/PCI/boot-interrupts.rst | 153 ++++++++++++++++++++++++++
Documentation/PCI/index.rst | 1 +
drivers/pci/quirks.c | 80 ++++++++++++--
3 files changed, 227 insertions(+), 7 deletions(-)
create mode 100644 Documentation/PCI/boot-interrupts.rst
--
2.25.0
^ permalink raw reply
* [PATCH 1/2] pci: Add boot interrupt quirk mechanism for Xeon chipsets
From: Sean V Kelley @ 2020-02-14 21:33 UTC (permalink / raw)
To: tglx, bhelgaas, corbet, mingo, bp
Cc: x86, linux-pci, linux-kernel, linux-doc, kar.hin.ong, sassmann,
Sean V Kelley
In-Reply-To: <20200214213313.66622-1-sean.v.kelley@linux.intel.com>
The following was observed by Kar Hin Ong with RT patchset:
Backtrace:
irq 19: nobody cared (try booting with the "irqpoll" option)
CPU: 0 PID: 3329 Comm: irq/34-nipalk Tainted:4.14.87-rt49 #1
Hardware name: National Instruments NI PXIe-8880/NI PXIe-8880,
BIOS 2.1.5f1 01/09/2020
Call Trace:
<IRQ>
? dump_stack+0x46/0x5e
? __report_bad_irq+0x2e/0xb0
? note_interrupt+0x242/0x290
? nNIKAL100_memoryRead16+0x8/0x10 [nikal]
? handle_irq_event_percpu+0x55/0x70
? handle_irq_event+0x4f/0x80
? handle_fasteoi_irq+0x81/0x180
? handle_irq+0x1c/0x30
? do_IRQ+0x41/0xd0
? common_interrupt+0x84/0x84
</IRQ>
...
handlers:
[<ffffffffb3297200>] irq_default_primary_handler threaded
[<ffffffffb3669180>] usb_hcd_irq
Disabling IRQ #19
The problem being that this device is triggering boot interrupts
due to threaded interrupt handling and masking of the IO-APIC. These
boot interrupts are then forwarded on to the legacy PCH's PIRQ lines
where there is no handler present for the device.
Whenever a PCI device is firing interrupt (INTx) to Pin 20 of IOAPIC 2
(GSI 44); the kernel will receives 2 interrupts:
1. Interrupt from Pin 20 of IOAPIC 2 -> Expected
2. Interrupt from Pin 19 of IOAPIC 1 -> UNEXPECTED
Quirks for disabling boot interrupts (preferred) or rerouting the handler
exist but do not address these Xeon chipsets' mechanism:
https://lore.kernel.org/lkml/12131949181903-git-send-email-sassmann@suse.de/
This patch adds a new mechanism via PCI CFG for those chipsets supporting
CIPINTRC register's dis_intx_rout2ich bit.
Reported-by: Kar Hin Ong <kar.hin.ong@ni.com>
Tested-by: Kar Hin Ong <kar.hin.ong@ni.com>
Signed-off-by: Sean V Kelley <sean.v.kelley@linux.intel.com>
---
drivers/pci/quirks.c | 80 ++++++++++++++++++++++++++++++++++++++++----
1 file changed, 73 insertions(+), 7 deletions(-)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 29f473ebf20f..e8ee670877d1 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -1970,26 +1970,92 @@ DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_80332_1, quirk
/*
* IO-APIC1 on 6300ESB generates boot interrupts, see Intel order no
* 300641-004US, section 5.7.3.
+ *
+ * Core IO on Xeon E5 1600/2600/4600, see Intel order no 326509-003.
+ * Core IO on Xeon E5 v2, see Intel order no 329188-003.
+ * Core IO on Xeon E7 v2, see Intel order no 329595-002.
+ * Core IO on Xeon E5 v3, see Intel order no 330784-003.
+ * Core IO on Xeon E7 v3, see Intel order no 332315-001US.
+ * Core IO on Xeon E5 v4, see Intel order no 333810-002US.
+ * Core IO on Xeon E7 v4, see Intel order no 332315-001US.
+ * Core IO on Xeon D-1500, see Intel order no 332051-001.
+ * Core IO on Xeon Scalable, see Intel order no 610950.
*/
-#define INTEL_6300_IOAPIC_ABAR 0x40
+#define INTEL_6300_IOAPIC_ABAR 0x40 /* Bus 0, Dev 29, Func 5 */
#define INTEL_6300_DISABLE_BOOT_IRQ (1<<14)
+#define INTEL_CIPINTRC_CFG_OFFSET 0x14C /* Bus 0, Dev 5, Func 0 */
+#define INTEL_CIPINTRC_DIS_INTX_ICH (1<<25)
+
static void quirk_disable_intel_boot_interrupt(struct pci_dev *dev)
{
u16 pci_config_word;
+ u32 pci_config_dword;
if (noioapicquirk)
return;
- pci_read_config_word(dev, INTEL_6300_IOAPIC_ABAR, &pci_config_word);
- pci_config_word |= INTEL_6300_DISABLE_BOOT_IRQ;
- pci_write_config_word(dev, INTEL_6300_IOAPIC_ABAR, pci_config_word);
-
+ switch (dev->device) {
+ case PCI_DEVICE_ID_INTEL_ESB_10:
+ pci_read_config_word(dev, INTEL_6300_IOAPIC_ABAR,
+ &pci_config_word);
+ pci_config_word |= INTEL_6300_DISABLE_BOOT_IRQ;
+ pci_write_config_word(dev, INTEL_6300_IOAPIC_ABAR,
+ pci_config_word);
+ break;
+ case 0x3c28: /* Xeon E5 1600/2600/4600 */
+ case 0x0e28: /* Xeon E5/E7 V2 */
+ case 0x2f28: /* Xeon E5/E7 V3,V4 */
+ case 0x6f28: /* Xeon D-1500 */
+ case 0x2034: /* Xeon Scalable Family */
+ pci_read_config_dword(dev, INTEL_CIPINTRC_CFG_OFFSET,
+ &pci_config_dword);
+ pci_config_dword |= INTEL_CIPINTRC_DIS_INTX_ICH;
+ pci_write_config_dword(dev, INTEL_CIPINTRC_CFG_OFFSET,
+ pci_config_dword);
+ break;
+ default:
+ return;
+ }
pci_info(dev, "disabled boot interrupts on device [%04x:%04x]\n",
dev->vendor, dev->device);
}
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ESB_10, quirk_disable_intel_boot_interrupt);
-DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ESB_10, quirk_disable_intel_boot_interrupt);
+/*
+ * Device 29 Func 5 Device IDs of IOxAPIC
+ * containing ABAR—APIC1 Alternate Base Address Register
+ */
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ESB_10,
+ quirk_disable_intel_boot_interrupt);
+DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ESB_10,
+ quirk_disable_intel_boot_interrupt);
+
+/*
+ * Device 5 Func 0 Device IDs of IIO or Core modules/hubs
+ * containing Coherent Interface Protocol Interrupt Control
+ *
+ * Device IDs obtained from volume 2 datasheets of commented
+ * families above.
+ */
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x3c28,
+ quirk_disable_intel_boot_interrupt);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x0e28,
+ quirk_disable_intel_boot_interrupt);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x2f28,
+ quirk_disable_intel_boot_interrupt);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x6f28,
+ quirk_disable_intel_boot_interrupt);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x2034,
+ quirk_disable_intel_boot_interrupt);
+DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_INTEL, 0x3c28,
+ quirk_disable_intel_boot_interrupt);
+DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_INTEL, 0x0e28,
+ quirk_disable_intel_boot_interrupt);
+DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_INTEL, 0x2f28,
+ quirk_disable_intel_boot_interrupt);
+DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_INTEL, 0x6f28,
+ quirk_disable_intel_boot_interrupt);
+DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_INTEL, 0x2034,
+ quirk_disable_intel_boot_interrupt);
/* Disable boot interrupts on HT-1000 */
#define BC_HT1000_FEATURE_REG 0x64
--
2.25.0
^ permalink raw reply related
* [PATCH 2/2] Documentation:PCI: Add background on Boot Interrupts
From: Sean V Kelley @ 2020-02-14 21:33 UTC (permalink / raw)
To: tglx, bhelgaas, corbet, mingo, bp
Cc: x86, linux-pci, linux-kernel, linux-doc, kar.hin.ong, sassmann,
Sean V Kelley
In-Reply-To: <20200214213313.66622-1-sean.v.kelley@linux.intel.com>
Improve understanding of the PCI quirks for this legacy PCI interrupt
behavior to the benefit of developers and users alike.
Signed-off-by: Sean V Kelley <sean.v.kelley@linux.intel.com>
---
Documentation/PCI/boot-interrupts.rst | 153 ++++++++++++++++++++++++++
Documentation/PCI/index.rst | 1 +
2 files changed, 154 insertions(+)
create mode 100644 Documentation/PCI/boot-interrupts.rst
diff --git a/Documentation/PCI/boot-interrupts.rst b/Documentation/PCI/boot-interrupts.rst
new file mode 100644
index 000000000000..632c080994fc
--- /dev/null
+++ b/Documentation/PCI/boot-interrupts.rst
@@ -0,0 +1,153 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+===============
+Boot Interrupts
+===============
+
+:Author: - Sean V Kelley <sean.v.kelley@linux.intel.com>
+
+Overview
+========
+
+On PCI Express, interrupts are represented with either MSI or inbound interrupt
+messages (Assert_INTx/Deassert_INTx). The integrated IO-APIC in a given Core
+IO converts the legacy interrupt messages from PCI Express to MSI interrupts.
+If the IO-APIC is disabled (via the mask bits in the IO-APIC table entries),
+the messages are routed to the legacy PCH. This in-band interrupt mechanism was
+traditionally necessary for systems that did not support the IO-APIC and for
+boot. Intel in the past has used the term "boot interrupts" to describe this
+mechanism. Further, the PCI Express protocol describes this in-band legacy
+wire-interrupt INTx mechanism for I/O devices to signal PCI-style level
+interrupts. The subsequent paragraphs describe problems with the Core IO
+handling of INTx message routing to the PCH and mitigation within BIOS and
+the OS.
+
+
+Problem
+=======
+
+When in-band legacy INTx messages are forwarded to the PCH, they in turn
+trigger a new interrupt for which the OS likely lacks a handler. When an
+interrupt goes unhandled over time, they are tracked by the Linux kernel
+as Spurious Interrupts. The IRQ will be disabled by the Linux kernel after
+it reaches a specific count with the error "nobody cared". This disabled
+IRQ now prevents valid usage by an existing interrupt which may happen to
+share the IRQ line.
+
+irq 19: nobody cared (try booting with the "irqpoll" option)
+CPU: 0 PID: 2988 Comm: irq/34-nipalk Tainted: 4.14.87-rt49-02410-g4a640ec-dirty #1
+Hardware name: National Instruments NI PXIe-8880/NI PXIe-8880, BIOS 2.1.5f1 01/09/2020
+Call Trace:
+<IRQ>
+ ? dump_stack+0x46/0x5e
+ ? __report_bad_irq+0x2e/0xb0
+ ? note_interrupt+0x242/0x290
+ ? nNIKAL100_memoryRead16+0x8/0x10 [nikal]
+ ? handle_irq_event_percpu+0x55/0x70
+ ? handle_irq_event+0x4f/0x80
+ ? handle_fasteoi_irq+0x81/0x180
+ ? handle_irq+0x1c/0x30
+ ? do_IRQ+0x41/0xd0
+ ? common_interrupt+0x84/0x84
+</IRQ>
+
+handlers:
+irq_default_primary_handler threaded usb_hcd_irq
+Disabling IRQ #19
+
+
+Conditions
+==========
+
+The use of threaded interrupts is the most likely condition to trigger this
+problem today. Threaded interrupts may not be reenabled after the IRQ handler
+wakes. These "one shot" conditions mean that the threaded interrupt needs to
+keep the interrupt line masked until the threaded handler has run. Especially
+when dealing with high data rate interrupts, the thread needs to run to completion
+otherwise some handlers will end up in stack overflows since the interrupt
+of the issuing device is still active.
+
+Affected Chipsets
+=================
+
+The legacy interrupt forwarding mechansim exists today in a number of devices
+including but not limited to chipsets from AMD/ATI, Broadcom, and Intel. Changes
+made through the mitigations below have been applied to drivers/pci/quirks.c
+
+Starting with ICX there are no longer any IO-APICs in the Core IO's devices.
+IO-APIC is only in the PCH. Devices connected to the Core IO's PCIE Root Ports
+will use native MSI/MSI-X mechanisms.
+
+Mitigations
+===========
+
+The mitigations take the form of PCI quirks. The preference has been to first
+identify and make use of a means to disable the routing to the PCH. In such a
+case a quirk to disable boot interrupt generation can be added.[1]
+
+Intel® 6300ESB I/O Controller Hub
+Alternate Base Address Register:
+ BIE: Boot Interrupt Enable
+ 0 = Boot interrupt is enabled.
+ 1 = Boot interrupt is disabled.
+
+Intel® Sandy Bridge through Sky Lake based Xeon servers:
+Coherent Interface Protocol Interrupt Control
+ dis_intx_route2pch/dis_intx_route2ich/dis_intx_route2dmi2:
+ When this bit is set. Local INTx messages received from the
+ Intel® Quick Data DMA/PCI Express ports are not routed to legacy
+ PCH - they are either converted into MSI via the integrated IO-APIC
+ (if the IO-APIC mask bit is clear in the appropriate entries)
+ or cause no further action (when mask bit is set)
+
+In the absence of a way to directly disable the routing, another approach
+has been to make use of PCI Interrupt pin to INTx routing tables for purposes
+of redirecting the interrupt handler to the rerouted interrupt line by default.
+Therefore, on chipsets where this INTx routing cannot be disabled, the
+Linux kernel will reroute the valid interrupt to its legacy interrupt. This
+redirection of the handler will prevent the occurrence of the spurious
+interrupt detection which would ordinarily disable the IRQ line due to
+excessive unhandled counts.[2]
+
+The config option X86_REROUTE_FOR_BROKEN_BOOT_IRQS exists to enable
+(or disable) the redirection of the interrupt handler to the PCH interrupt
+line. The option can be overridden by either pci=ioapicreroute or
+pci=noioapicreroute.[3]
+
+
+More Documentation
+==================
+
+There is an overview of the legacy interrupt handling mentioned in several
+datasheets (6300ESB and 6700PXH below). While largely the same, it provides
+insight into the evolution of its handling with chipsets.
+
+Example of disabling of the boot interrupt
+------------------------------------------
+
+Intel® 6300ESB I/O Controller Hub (Document # 300641-004US)
+ 2.15.2 PCI Express Legacy INTx Support and Boot Interrupt
+ https://www.intel.com/content/dam/doc/datasheet/6300esb-io-controller-hub-datasheet.pdf
+
+Intel® Xeon® Processor E5-1600/2400/2600/4600 v3 Product Families
+Datasheet - Volume 2: Registers (Dcument # 330784-003)
+ 6.6.41 cipintrc Coherent Interface Protocol Interrupt Control
+ https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/xeon-e5-v3-datasheet-vol-2.pdf
+
+Example of handler rerouting
+----------------------------
+
+Intel® 6700PXH 64-bit PCI Hub (Document # 302628)
+ 2.15.2 PCI Express Legacy INTx Support and Boot Interrupt
+ https://www.intel.com/content/dam/doc/datasheet/6700pxh-64-bit-pci-hub-datasheet.pdf
+
+
+If you have any legacy PCI interrupt questions that aren't answered, email me.
+
+Cheers,
+ Sean V Kelley
+ sean.v.kelley@linux.intel.com
+
+[1] https://lore.kernel.org/lkml/12131949181903-git-send-email-sassmann@suse.de/
+[2] https://lore.kernel.org/lkml/12131949182094-git-send-email-sassmann@suse.de/
+[3] https://lore.kernel.org/lkml/487C8EA7.6020205@suse.de/
diff --git a/Documentation/PCI/index.rst b/Documentation/PCI/index.rst
index 6768305e4c26..8f66feaafd4f 100644
--- a/Documentation/PCI/index.rst
+++ b/Documentation/PCI/index.rst
@@ -16,3 +16,4 @@ Linux PCI Bus Subsystem
pci-error-recovery
pcieaer-howto
endpoint/index
+ boot-interrupts
--
2.25.0
^ permalink raw reply related
* [SPDK] Re: 128k sequential read / write (fio) performance with spdk+vpp is not as good as the one with "kernel TCP"
From: Jonathan Richardson @ 2020-02-14 21:33 UTC (permalink / raw)
To: spdk
[-- Attachment #1: Type: text/plain, Size: 3000 bytes --]
When I tuned vpp for our NIC's I found that the default vpp
configuration wasn't sufficient. Doesn't look like you're controlling
the worker threads. When vpp uses dpdk unless you control which cores
the workers use they'll compete with spdk cores and I found letting
them compete doesn't work well. Instead, assign vpp to dedicated cores
and control the spdk coremask so that it doesn't use the vpp cores. I
matched the vpp worker threads with a number of RSS queues from the
NIC. Other hindrances to performance were multi-seg and tx checksum
offload. You want to use tx cksum offload because the s/w overhead is
very high. This will depend on your h/w but are things to look at.
With this config I was able to get ~800k iops for 4k reads (to nvme
not null). Can't remember the numbers for other sized reads/writes. It
wasn't great but the kernel was worse.
cpu {
## Set logical CPU core where main thread runs, if main core is not set
## VPP will use core 1 if available
main-core 0
## Set logical CPU core(s) where worker threads are running
# corelist-workers 2-3,18-19
corelist-workers 1-3
## Specify a number of workers to be created
## Workers are pinned to N consecutive CPU cores while skipping
"skip-cores" CPU core(s)
## and main thread's CPU core
workers 3
}
dpdk {
dev default {
## Number of receive queues, enables RSS
## Default is 1
num-rx-queues 3
...
}
## Disable multi-segment buffers, improves performance but
## disables Jumbo MTU support
no-multi-seg
## Disables UDP / TCP TX checksum offload. Typically needed for use
## faster vector PMDs (together with no-multi-seg)
#no-tx-checksum-offload
}
On Thu, Feb 13, 2020 at 7:57 PM <sejun.kwon(a)samsung.com> wrote:
>
> Hello,
> I'm working on SPDK library + VPP, because some report said that VPP reduces the overhead of network.
> When I test with VPP (with mlx5 poll mode driver) and null device with spdk, 4k performance with VPP is much better than the default(kTCP).
> But, 128k write performance with VPP is 30 percent lower than the one with kTCP.
> The configuration when VPP starts is as below.
> Is there anyone why 128k write performance with VPP is not good as kernel ?
>
> I increase num-rx-desc and there is improvment, but it still lower than kernel.
> Thanks in advance.
>
> unix {
> nodaemon
> cli-listen /run/vpp/cli.sock
>
> # cli-listen localhost:5002
>
> full-coredump
>
>
> }
> session {
> evt_qs_memfd_seg
> }
> dpdk {
> dev 0000:03:00.0
> {
> }
>
> }
> socksvr {
> # socket-name /tmp/vpp-api.sock
> socket-name /run/vpp-api.sock
> }
> plugins {
> plugin default { disable }
> plugin dpdk_plugin.so { enable }
> }
> _______________________________________________
> SPDK mailing list -- spdk(a)lists.01.org
> To unsubscribe send an email to spdk-leave(a)lists.01.org
^ permalink raw reply
* Re: [PATCH v2 2/2] ARM: sun7i: dts: Add LVDS panel support on A20
From: Andrey Lebedev @ 2020-02-14 21:32 UTC (permalink / raw)
To: Maxime Ripard
Cc: airlied, linux-sunxi, linux-kernel, dri-devel, Andrey Lebedev,
wens, daniel, linux-arm-kernel
In-Reply-To: <20200214085351.2whnfyulrmyex2va@gilmour.lan>
On Fri, Feb 14, 2020 at 09:53:51AM +0100, Maxime Ripard wrote:
> On Fri, Feb 14, 2020 at 10:43:58AM +0200, Andrey Lebedev wrote:
> > On Fri, Feb 14, 2020 at 08:52:18AM +0100, Maxime Ripard wrote:
> > > > > This will create a spurious warning message for TCON1, since we
> > > > > adjusted the driver to tell it supports LVDS, but there's no LVDS
> > > > > reset line, so we need to make it finer grained.
> > > >
> > > > Yes, I can attribute two of the messages in my dmesg log [1] to this
> > > > ("Missing LVDS properties" and "LVDS output disabled". "sun4i-tcon
> > > > 1c0d000.lcd-controller" is indeed tcon1). And yes, I can see how they
> > > > can be confusing to someone.
> > > >
> > > > I'd need some pointers on how to deal with that though (if we want to do
> > > > it in this scope).
> > >
> > > Like I was mentionning, you could introduce a new compatible for each
> > > TCON (tcon0 and tcon1) and only set the support_lvds flag for tcon0
> >
> > Can you give me an idea how that compatible might look like?
> >
> > tcon0: lcd-controller@1c0c000 {
> > compatible = "allwinner,sun7i-a20-tcon", "allwinner,lvds";
> >
> > or
> >
> > tcon0: lcd-controller@1c0c000 {
> > compatible = "allwinner,sun7i-a20-tcon", "allwinner,tcon0";
> >
> > ? Or something completely different?
>
> Something like
>
> &tcon0 {
> compatible = "allwinner,sun7i-a20-tcon0", "allwinner,sun7i-a20-tcon";
> };
>
> &tcon1 {
> compatible = "allwinner,sun7i-a20-tcon1", "allwinner,sun7i-a20-tcon";
> };
>
Hi Maxime, here is what I came up with, please take a look. If the
approach is right, I'll split it up and include into the patch set.
From f3e45c958a9551a52ac26435785bdb572e54d8db Mon Sep 17 00:00:00 2001
From: Andrey Lebedev <andrey@lebedev.lt>
Date: Fri, 14 Feb 2020 23:21:59 +0200
Subject: [PATCH] Mark tcon0 to be the only tcon capable of LVDS on sun7i-a20
This allows to avoid warnings about reset line not provided for tcon1.
Signed-off-by: Andrey Lebedev <andrey@lebedev.lt>
---
arch/arm/boot/dts/sun7i-a20.dtsi | 2 +-
drivers/gpu/drm/sun4i/sun4i_tcon.c | 22 +++++++++++++++++++++-
drivers/gpu/drm/sun4i/sun4i_tcon.h | 2 ++
3 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 3b3c366a2bee..bab59fc4d9b1 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -405,7 +405,7 @@
};
tcon0: lcd-controller@1c0c000 {
- compatible = "allwinner,sun7i-a20-tcon";
+ compatible = "allwinner,sun7i-a20-tcon0", "allwinner,sun7i-a20-tcon";
reg = <0x01c0c000 0x1000>;
interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>;
resets = <&ccu RST_TCON0>, <&ccu RST_LVDS>;
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 800a9bd86112..cb2040aec436 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -1107,6 +1107,25 @@ static struct sunxi_engine *sun4i_tcon_find_engine(struct sun4i_drv *drv,
return sun4i_tcon_find_engine_traverse(drv, node, 0);
}
+/*
+ * Check if given tcon supports LVDS
+ *
+ * Some of the sunxi SoC variants contain several timing controllers, but only
+ * one of them can be used to drive LVDS screen. In this case such tcon is
+ * identified in respective quirks struct: lvds_compatible_tcon property will
+ * hold "compatible" string of the tcon, that supports LVDS.
+ *
+ * If lvds_compatible_tcon is not set, all tcons are considered capable of
+ * driving LVDS.
+ */
+static bool sun4i_tcon_lvds_compat(struct device *dev, struct sun4i_tcon *tcon)
+{
+ if (tcon->quirks->lvds_compatible_tcon == NULL)
+ return true;
+ return of_device_is_compatible(dev->of_node,
+ tcon->quirks->lvds_compatible_tcon);
+}
+
static int sun4i_tcon_bind(struct device *dev, struct device *master,
void *data)
{
@@ -1161,7 +1180,7 @@ static int sun4i_tcon_bind(struct device *dev, struct device *master,
return ret;
}
- if (tcon->quirks->supports_lvds) {
+ if (tcon->quirks->supports_lvds && sun4i_tcon_lvds_compat(dev, tcon)) {
/*
* This can only be made optional since we've had DT
* nodes without the LVDS reset properties.
@@ -1481,6 +1500,7 @@ static const struct sun4i_tcon_quirks sun6i_a31s_quirks = {
static const struct sun4i_tcon_quirks sun7i_a20_quirks = {
.supports_lvds = true,
+ .lvds_compatible_tcon = "allwinner,sun7i-a20-tcon0",
.has_channel_0 = true,
.has_channel_1 = true,
.dclk_min_div = 4,
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h b/drivers/gpu/drm/sun4i/sun4i_tcon.h
index cfbf4e6c1679..bc87d28ee341 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
@@ -235,6 +235,8 @@ struct sun4i_tcon_quirks {
bool needs_de_be_mux; /* sun6i needs mux to select backend */
bool needs_edp_reset; /* a80 edp reset needed for tcon0 access */
bool supports_lvds; /* Does the TCON support an LVDS output? */
+ /* "compatible" string of TCON that exclusively supports LVDS */
+ const char *lvds_compatible_tcon;
u8 dclk_min_div; /* minimum divider for TCON0 DCLK */
/* callback to handle tcon muxing options */
--
2.20.1
--
Andrey Lebedev aka -.- . -.. -.. . .-.
Software engineer
Homepage: http://lebedev.lt/
_______________________________________________
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 2/2] ARM: sun7i: dts: Add LVDS panel support on A20
From: Andrey Lebedev @ 2020-02-14 21:32 UTC (permalink / raw)
To: Maxime Ripard
Cc: wens, airlied, daniel, dri-devel, linux-arm-kernel, linux-kernel,
linux-sunxi, Andrey Lebedev
In-Reply-To: <20200214085351.2whnfyulrmyex2va@gilmour.lan>
On Fri, Feb 14, 2020 at 09:53:51AM +0100, Maxime Ripard wrote:
> On Fri, Feb 14, 2020 at 10:43:58AM +0200, Andrey Lebedev wrote:
> > On Fri, Feb 14, 2020 at 08:52:18AM +0100, Maxime Ripard wrote:
> > > > > This will create a spurious warning message for TCON1, since we
> > > > > adjusted the driver to tell it supports LVDS, but there's no LVDS
> > > > > reset line, so we need to make it finer grained.
> > > >
> > > > Yes, I can attribute two of the messages in my dmesg log [1] to this
> > > > ("Missing LVDS properties" and "LVDS output disabled". "sun4i-tcon
> > > > 1c0d000.lcd-controller" is indeed tcon1). And yes, I can see how they
> > > > can be confusing to someone.
> > > >
> > > > I'd need some pointers on how to deal with that though (if we want to do
> > > > it in this scope).
> > >
> > > Like I was mentionning, you could introduce a new compatible for each
> > > TCON (tcon0 and tcon1) and only set the support_lvds flag for tcon0
> >
> > Can you give me an idea how that compatible might look like?
> >
> > tcon0: lcd-controller@1c0c000 {
> > compatible = "allwinner,sun7i-a20-tcon", "allwinner,lvds";
> >
> > or
> >
> > tcon0: lcd-controller@1c0c000 {
> > compatible = "allwinner,sun7i-a20-tcon", "allwinner,tcon0";
> >
> > ? Or something completely different?
>
> Something like
>
> &tcon0 {
> compatible = "allwinner,sun7i-a20-tcon0", "allwinner,sun7i-a20-tcon";
> };
>
> &tcon1 {
> compatible = "allwinner,sun7i-a20-tcon1", "allwinner,sun7i-a20-tcon";
> };
>
Hi Maxime, here is what I came up with, please take a look. If the
approach is right, I'll split it up and include into the patch set.
From f3e45c958a9551a52ac26435785bdb572e54d8db Mon Sep 17 00:00:00 2001
From: Andrey Lebedev <andrey@lebedev.lt>
Date: Fri, 14 Feb 2020 23:21:59 +0200
Subject: [PATCH] Mark tcon0 to be the only tcon capable of LVDS on sun7i-a20
This allows to avoid warnings about reset line not provided for tcon1.
Signed-off-by: Andrey Lebedev <andrey@lebedev.lt>
---
arch/arm/boot/dts/sun7i-a20.dtsi | 2 +-
drivers/gpu/drm/sun4i/sun4i_tcon.c | 22 +++++++++++++++++++++-
drivers/gpu/drm/sun4i/sun4i_tcon.h | 2 ++
3 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 3b3c366a2bee..bab59fc4d9b1 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -405,7 +405,7 @@
};
tcon0: lcd-controller@1c0c000 {
- compatible = "allwinner,sun7i-a20-tcon";
+ compatible = "allwinner,sun7i-a20-tcon0", "allwinner,sun7i-a20-tcon";
reg = <0x01c0c000 0x1000>;
interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>;
resets = <&ccu RST_TCON0>, <&ccu RST_LVDS>;
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 800a9bd86112..cb2040aec436 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -1107,6 +1107,25 @@ static struct sunxi_engine *sun4i_tcon_find_engine(struct sun4i_drv *drv,
return sun4i_tcon_find_engine_traverse(drv, node, 0);
}
+/*
+ * Check if given tcon supports LVDS
+ *
+ * Some of the sunxi SoC variants contain several timing controllers, but only
+ * one of them can be used to drive LVDS screen. In this case such tcon is
+ * identified in respective quirks struct: lvds_compatible_tcon property will
+ * hold "compatible" string of the tcon, that supports LVDS.
+ *
+ * If lvds_compatible_tcon is not set, all tcons are considered capable of
+ * driving LVDS.
+ */
+static bool sun4i_tcon_lvds_compat(struct device *dev, struct sun4i_tcon *tcon)
+{
+ if (tcon->quirks->lvds_compatible_tcon == NULL)
+ return true;
+ return of_device_is_compatible(dev->of_node,
+ tcon->quirks->lvds_compatible_tcon);
+}
+
static int sun4i_tcon_bind(struct device *dev, struct device *master,
void *data)
{
@@ -1161,7 +1180,7 @@ static int sun4i_tcon_bind(struct device *dev, struct device *master,
return ret;
}
- if (tcon->quirks->supports_lvds) {
+ if (tcon->quirks->supports_lvds && sun4i_tcon_lvds_compat(dev, tcon)) {
/*
* This can only be made optional since we've had DT
* nodes without the LVDS reset properties.
@@ -1481,6 +1500,7 @@ static const struct sun4i_tcon_quirks sun6i_a31s_quirks = {
static const struct sun4i_tcon_quirks sun7i_a20_quirks = {
.supports_lvds = true,
+ .lvds_compatible_tcon = "allwinner,sun7i-a20-tcon0",
.has_channel_0 = true,
.has_channel_1 = true,
.dclk_min_div = 4,
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h b/drivers/gpu/drm/sun4i/sun4i_tcon.h
index cfbf4e6c1679..bc87d28ee341 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
@@ -235,6 +235,8 @@ struct sun4i_tcon_quirks {
bool needs_de_be_mux; /* sun6i needs mux to select backend */
bool needs_edp_reset; /* a80 edp reset needed for tcon0 access */
bool supports_lvds; /* Does the TCON support an LVDS output? */
+ /* "compatible" string of TCON that exclusively supports LVDS */
+ const char *lvds_compatible_tcon;
u8 dclk_min_div; /* minimum divider for TCON0 DCLK */
/* callback to handle tcon muxing options */
--
2.20.1
--
Andrey Lebedev aka -.- . -.. -.. . .-.
Software engineer
Homepage: http://lebedev.lt/
^ permalink raw reply related
* Re: [PATCH 2/2] watchdog: Add new arm_smc_wdt watchdog driver
From: Julius Werner @ 2020-02-14 21:32 UTC (permalink / raw)
To: Guenter Roeck
Cc: Rob Herring, Wim Van Sebroeck, linux-watchdog, Anson Huang,
Dinh Nguyen, Catalin Marinas, LKML, Shawn Guo, Bjorn Andersson,
Marcin Juszkiewicz, Olof Johansson, Greg Kroah-Hartman,
Clément Péron, Evan Benn, Jonathan Cameron,
Mauro Carvalho Chehab, Julius Werner, Leonard Crestez,
Will Deacon, David S. Miller, linux-arm-kernel
In-Reply-To: <804d3cc5-688d-7025-cb87-10b9616f4d9b@roeck-us.net>
> > with a Secure Monitor firmware to forward watchdog operations to
> > firmware via a Secure Monitor Call. This may be useful for platforms
> > using TrustZone that want the Secure Monitor firmware to have the final
> > control over the watchdog.
> >
>
> As written, one would assume this to work on all systems implementing
> ARM secure firmware, which is not the case. Please select a different
> name, and provide information about the systems where this is actually
> supported.
>
> If it happens to be standardized, we will need a reference to the standard
> supported. This needs to distinguish from IMX_SC_WDT, which also supports
> a secure monitor based watchdog (but doesn't claim to be generic).
Back when I wrote this I was hoping it could be something that other
platforms can pick up if they want to, but that hasn't happened yet
and the code on the Trusted Firmware side is still MediaTek-specific.
Unfortunately Arm doesn't make it easy to write generic SMC interfaces
and my attempts to change that haven't been very fruitful for now. So
yes, probably makes sense to treat this as MediaTek-specific for now,
we can still consider expanding it later if there's interest from
other platforms. (I would like to avoid every vendor writing their own
driver and SMC interface for this, although looking at that IMX driver
it seems that we're already there.)
_______________________________________________
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/2] watchdog: Add new arm_smc_wdt watchdog driver
From: Julius Werner @ 2020-02-14 21:32 UTC (permalink / raw)
To: Guenter Roeck
Cc: Evan Benn, LKML, Julius Werner, Bjorn Andersson,
Mauro Carvalho Chehab, Marcin Juszkiewicz, Catalin Marinas,
Olof Johansson, Leonard Crestez, Jonathan Cameron, Dinh Nguyen,
linux-arm-kernel, Greg Kroah-Hartman, Will Deacon, linux-watchdog,
Rob Herring, Wim Van Sebroeck, Clément Péron, Shawn Guo,
David S. Miller, Anson Huang
In-Reply-To: <804d3cc5-688d-7025-cb87-10b9616f4d9b@roeck-us.net>
> > with a Secure Monitor firmware to forward watchdog operations to
> > firmware via a Secure Monitor Call. This may be useful for platforms
> > using TrustZone that want the Secure Monitor firmware to have the final
> > control over the watchdog.
> >
>
> As written, one would assume this to work on all systems implementing
> ARM secure firmware, which is not the case. Please select a different
> name, and provide information about the systems where this is actually
> supported.
>
> If it happens to be standardized, we will need a reference to the standard
> supported. This needs to distinguish from IMX_SC_WDT, which also supports
> a secure monitor based watchdog (but doesn't claim to be generic).
Back when I wrote this I was hoping it could be something that other
platforms can pick up if they want to, but that hasn't happened yet
and the code on the Trusted Firmware side is still MediaTek-specific.
Unfortunately Arm doesn't make it easy to write generic SMC interfaces
and my attempts to change that haven't been very fruitful for now. So
yes, probably makes sense to treat this as MediaTek-specific for now,
we can still consider expanding it later if there's interest from
other platforms. (I would like to avoid every vendor writing their own
driver and SMC interface for this, although looking at that IMX driver
it seems that we're already there.)
^ permalink raw reply
* [LSF/MM TOPIC] Guest memory without struct page
From: Joao Martins @ 2020-02-14 21:32 UTC (permalink / raw)
To: lsf-pc; +Cc: linux-mm
All system RAM is tracked by a metadata structure called 'struct page' which
amounts to 64bytes and represents a certain page granualarity. On x86 (or
systems which PAGE_SIZE is 4K) this data structure represents a total of 1.5%
overhead of total capacity.
For hypervisors -- specially those without vhost/PV-devices, and just VFs --
persistent/volatile memory is largely assigned to userspace without kernel
taking part in any of it's I/O paths, except for VFIO. 1.5% may not seem like
much, but it is still a total of 16G per Tb just for struct page, which is a lot
considering the hypervisor won't need it and instead should be used to create
more guests (=Happy Users).
The RFC patches submitted here [0] approach this through device-dax given the
interface it provides already for VMMs and also given that this is too a source
of overhead for non-volatile memory assigned to guests. Essentially it extends
device-dax to create a PFNMAP vma with special pages (while adding support for
huge special pages). host memory would be limited through some form of mem=X,
efi_fake_mem=Y@X:0x40000 or memmap=Y@X-1+0xefffffff i.e. dedicate Y amount for
guests memory.
Should vhost-{net,scsi,etc} be used, we copy from/to guest memory (which works
today for vhost-net, and easily adjusted for vhost-scsi), or perhaps explore
dynamically creating/freeing struct pages on GUP temporary pinning.
This topic would be to brainstorm the idea/proposal and also discuss
alternatives/pitfalls/limitations/other-usecases(*).
Regards,
Joao
(*) To some extent there might be a similarity to '"Secret" memory userspace
APIs' subitem of this previously submitted topic[1] given that the guest memory
in the described topic isn't part of the direct map.
[0]
https://lore.kernel.org/linux-mm/20200110190313.17144-1-joao.m.martins@oracle.com/
[1] https://lore.kernel.org/linux-mm/20200206165900.GD17499@linux.ibm.com/
^ permalink raw reply
* [PATCH] vfs: fix boolreturn.cocci warnings
From: kbuild test robot @ 2020-02-14 21:30 UTC (permalink / raw)
To: Johannes Weiner
Cc: kbuild-all, linux-fsdevel, linux-mm, linux-kernel, Dave Chinner,
Yafang Shao, Michal Hocko, Roman Gushchin, Andrew Morton,
Linus Torvalds, Al Viro, kernel-team
In-Reply-To: <20200211175507.178100-1-hannes@cmpxchg.org>
From: kbuild test robot <lkp@intel.com>
mm/truncate.c:41:9-10: WARNING: return of 0/1 in function '__clear_shadow_entry' with return type bool
Return statements in functions returning bool should use
true/false instead of 1/0.
Generated by: scripts/coccinelle/misc/boolreturn.cocci
Fixes: 98e2565539a0 ("vfs: keep inodes with page cache off the inode shrinker LRU")
CC: Johannes Weiner <hannes@cmpxchg.org>
Signed-off-by: kbuild test robot <lkp@intel.com>
---
url: https://github.com/0day-ci/linux/commits/Johannes-Weiner/vfs-keep-inodes-with-page-cache-off-the-inode-shrinker-LRU/20200214-083756
base: https://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-next
truncate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/mm/truncate.c
+++ b/mm/truncate.c
@@ -38,7 +38,7 @@ static bool __must_check __clear_shadow_
xas_set_update(&xas, workingset_update_node);
if (xas_load(&xas) != entry)
- return 0;
+ return false;
xas_store(&xas, NULL);
mapping->nrexceptional--;
^ permalink raw reply
* Re: [PATCH] vfs: keep inodes with page cache off the inode shrinker LRU
From: kbuild test robot @ 2020-02-14 21:30 UTC (permalink / raw)
To: Johannes Weiner
Cc: kbuild-all, linux-fsdevel, linux-mm, linux-kernel, Dave Chinner,
Yafang Shao, Michal Hocko, Roman Gushchin, Andrew Morton,
Linus Torvalds, Al Viro, kernel-team
In-Reply-To: <20200211175507.178100-1-hannes@cmpxchg.org>
Hi Johannes,
I love your patch! Perhaps something to improve:
[auto build test WARNING on vfs/for-next]
[also build test WARNING on linux/master linus/master v5.6-rc1 next-20200214]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url: https://github.com/0day-ci/linux/commits/Johannes-Weiner/vfs-keep-inodes-with-page-cache-off-the-inode-shrinker-LRU/20200214-083756
base: https://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-next
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
coccinelle warnings: (new ones prefixed by >>)
>> mm/truncate.c:41:9-10: WARNING: return of 0/1 in function '__clear_shadow_entry' with return type bool
Please review and possibly fold the followup patch.
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [PATCH] vfs: fix boolreturn.cocci warnings
From: kbuild test robot @ 2020-02-14 21:30 UTC (permalink / raw)
To: kbuild-all
In-Reply-To: <20200211175507.178100-1-hannes@cmpxchg.org>
[-- Attachment #1: Type: text/plain, Size: 1048 bytes --]
From: kbuild test robot <lkp@intel.com>
mm/truncate.c:41:9-10: WARNING: return of 0/1 in function '__clear_shadow_entry' with return type bool
Return statements in functions returning bool should use
true/false instead of 1/0.
Generated by: scripts/coccinelle/misc/boolreturn.cocci
Fixes: 98e2565539a0 ("vfs: keep inodes with page cache off the inode shrinker LRU")
CC: Johannes Weiner <hannes@cmpxchg.org>
Signed-off-by: kbuild test robot <lkp@intel.com>
---
url: https://github.com/0day-ci/linux/commits/Johannes-Weiner/vfs-keep-inodes-with-page-cache-off-the-inode-shrinker-LRU/20200214-083756
base: https://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-next
truncate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/mm/truncate.c
+++ b/mm/truncate.c
@@ -38,7 +38,7 @@ static bool __must_check __clear_shadow_
xas_set_update(&xas, workingset_update_node);
if (xas_load(&xas) != entry)
- return 0;
+ return false;
xas_store(&xas, NULL);
mapping->nrexceptional--;
^ permalink raw reply
* Re: [PATCH] vfs: keep inodes with page cache off the inode shrinker LRU
From: kbuild test robot @ 2020-02-14 21:30 UTC (permalink / raw)
To: kbuild-all
In-Reply-To: <20200211175507.178100-1-hannes@cmpxchg.org>
[-- Attachment #1: Type: text/plain, Size: 1085 bytes --]
Hi Johannes,
I love your patch! Perhaps something to improve:
[auto build test WARNING on vfs/for-next]
[also build test WARNING on linux/master linus/master v5.6-rc1 next-20200214]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url: https://github.com/0day-ci/linux/commits/Johannes-Weiner/vfs-keep-inodes-with-page-cache-off-the-inode-shrinker-LRU/20200214-083756
base: https://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-next
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
coccinelle warnings: (new ones prefixed by >>)
>> mm/truncate.c:41:9-10: WARNING: return of 0/1 in function '__clear_shadow_entry' with return type bool
Please review and possibly fold the followup patch.
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org
^ permalink raw reply
* Re: [PATCH] x86/mce: Do not log spurious corrected mce errors
From: Prarit Bhargava @ 2020-02-14 21:29 UTC (permalink / raw)
To: Luck, Tony
Cc: linux-kernel, Alexander Krupp, Borislav Petkov, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, x86, linux-edac
In-Reply-To: <20200214173644.GA7913@agluck-desk2.amr.corp.intel.com>
On 2/14/20 12:36 PM, Luck, Tony wrote:
> On Fri, Feb 14, 2020 at 07:34:07AM -0500, Prarit Bhargava wrote:
>> #ifdef CONFIG_X86_MCE_AMD
>> extern bool amd_filter_mce(struct mce *m);
>> +extern bool intel_filter_mce(struct mce *m);
>> #else
>
> Something very weird is going on here. Why does
> CONFIG_X86_MCE_AMD have to be set to enable some
> *Intel* filter operation?
That's a mistake. I'll fix that in v2.
P.
>
> -Tony
>
^ permalink raw reply
* [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/selftests: Fix selftest_mocs for DGFX (rev2)
From: Patchwork @ 2020-02-14 21:28 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx
In-Reply-To: <20200213001418.5899-1-brian.welty@intel.com>
== Series Details ==
Series: drm/i915/selftests: Fix selftest_mocs for DGFX (rev2)
URL : https://patchwork.freedesktop.org/series/73387/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
9f9e214b4a7d drm/i915/selftests: Fix selftest_mocs for DGFX
-:19: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line)
#19:
> > The format has changed (been reduced?) for DGFX. drm_i915_mocs_entry.l3cc_value is what is still initialized/used.
-:26: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ chars of sha1> ("<title line>")' - ie: 'commit e6e2ac07118b ("drm/i915: do not set MOCS control values on dgfx")'
#26:
> commit e6e2ac07118b15f25683fcbd59ea1be73ec9465d
-:119: ERROR:MISSING_SIGN_OFF: Missing Signed-off-by: line(s)
total: 2 errors, 1 warnings, 0 checks, 64 lines checked
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* [hwmon:hwmon] BUILD SUCCESS 205447fa9e0a44cc42a74788eb2f6c96f91d5cd6
From: kbuild test robot @ 2020-02-14 21:28 UTC (permalink / raw)
To: Guenter Roeck; +Cc: linux-hwmon
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git hwmon
branch HEAD: 205447fa9e0a44cc42a74788eb2f6c96f91d5cd6 hwmon: (pmbus/xdpe12284) fix typo in compatible strings
elapsed time: 2885m
configs tested: 245
configs skipped: 0
The following configs have been built successfully.
More configs may be tested in the coming days.
arm allmodconfig
arm allnoconfig
arm allyesconfig
arm at91_dt_defconfig
arm efm32_defconfig
arm exynos_defconfig
arm multi_v5_defconfig
arm multi_v7_defconfig
arm shmobile_defconfig
arm sunxi_defconfig
arm64 allmodconfig
arm64 allnoconfig
arm64 allyesconfig
arm64 defconfig
sparc allyesconfig
nios2 10m50_defconfig
riscv allnoconfig
sh sh7785lcr_32bit_defconfig
c6x allyesconfig
xtensa iss_defconfig
powerpc allnoconfig
riscv defconfig
i386 defconfig
riscv allmodconfig
sparc defconfig
nds32 defconfig
riscv allyesconfig
s390 defconfig
sparc64 allmodconfig
s390 allmodconfig
s390 allnoconfig
riscv nommu_virt_defconfig
mips allyesconfig
arc allyesconfig
powerpc defconfig
i386 allyesconfig
mips malta_kvm_defconfig
mips allnoconfig
powerpc ppc64_defconfig
mips fuloong2e_defconfig
parisc b180_defconfig
sparc64 allnoconfig
nios2 3c120_defconfig
parisc allnoconfig
m68k m5475evb_defconfig
microblaze mmu_defconfig
ia64 defconfig
riscv rv32_defconfig
um i386_defconfig
openrisc simple_smp_defconfig
ia64 allnoconfig
csky defconfig
s390 allyesconfig
s390 debug_defconfig
ia64 allyesconfig
m68k multi_defconfig
s390 alldefconfig
alpha defconfig
sh titan_defconfig
i386 alldefconfig
i386 allnoconfig
ia64 alldefconfig
ia64 allmodconfig
c6x evmc6678_defconfig
openrisc or1ksim_defconfig
xtensa common_defconfig
nds32 allnoconfig
h8300 edosk2674_defconfig
h8300 h8300h-sim_defconfig
h8300 h8s-sim_defconfig
m68k allmodconfig
m68k sun3_defconfig
arc defconfig
microblaze nommu_defconfig
powerpc rhel-kconfig
mips 32r2_defconfig
mips 64r6el_defconfig
mips allmodconfig
parisc allyesconfig
parisc c3000_defconfig
parisc defconfig
x86_64 randconfig-a001-20200214
x86_64 randconfig-a002-20200214
x86_64 randconfig-a003-20200214
i386 randconfig-a001-20200214
i386 randconfig-a002-20200214
i386 randconfig-a003-20200214
x86_64 randconfig-a001-20200213
x86_64 randconfig-a002-20200213
x86_64 randconfig-a003-20200213
i386 randconfig-a001-20200213
i386 randconfig-a002-20200213
i386 randconfig-a003-20200213
x86_64 randconfig-a001-20200215
x86_64 randconfig-a002-20200215
x86_64 randconfig-a003-20200215
i386 randconfig-a001-20200215
i386 randconfig-a002-20200215
i386 randconfig-a003-20200215
alpha randconfig-a001-20200213
m68k randconfig-a001-20200213
mips randconfig-a001-20200213
nds32 randconfig-a001-20200213
parisc randconfig-a001-20200213
riscv randconfig-a001-20200213
alpha randconfig-a001-20200214
m68k randconfig-a001-20200214
mips randconfig-a001-20200214
nds32 randconfig-a001-20200214
parisc randconfig-a001-20200214
c6x randconfig-a001-20200213
h8300 randconfig-a001-20200213
microblaze randconfig-a001-20200213
nios2 randconfig-a001-20200213
sparc64 randconfig-a001-20200213
c6x randconfig-a001-20200214
h8300 randconfig-a001-20200214
microblaze randconfig-a001-20200214
nios2 randconfig-a001-20200214
sparc64 randconfig-a001-20200214
c6x randconfig-a001-20200215
h8300 randconfig-a001-20200215
microblaze randconfig-a001-20200215
nios2 randconfig-a001-20200215
sparc64 randconfig-a001-20200215
csky randconfig-a001-20200213
openrisc randconfig-a001-20200213
s390 randconfig-a001-20200213
sh randconfig-a001-20200213
xtensa randconfig-a001-20200213
csky randconfig-a001-20200214
openrisc randconfig-a001-20200214
s390 randconfig-a001-20200214
xtensa randconfig-a001-20200214
sh randconfig-a001-20200214
x86_64 randconfig-b001-20200213
x86_64 randconfig-b002-20200213
x86_64 randconfig-b003-20200213
i386 randconfig-b001-20200213
i386 randconfig-b002-20200213
i386 randconfig-b003-20200213
x86_64 randconfig-b001-20200214
x86_64 randconfig-b002-20200214
x86_64 randconfig-b003-20200214
i386 randconfig-b001-20200214
i386 randconfig-b002-20200214
i386 randconfig-b003-20200214
x86_64 randconfig-c001-20200213
x86_64 randconfig-c002-20200213
x86_64 randconfig-c003-20200213
i386 randconfig-c001-20200213
i386 randconfig-c002-20200213
i386 randconfig-c003-20200213
x86_64 randconfig-c001-20200214
x86_64 randconfig-c002-20200214
x86_64 randconfig-c003-20200214
i386 randconfig-c001-20200214
i386 randconfig-c002-20200214
i386 randconfig-c003-20200214
x86_64 randconfig-d001-20200213
x86_64 randconfig-d002-20200213
x86_64 randconfig-d003-20200213
i386 randconfig-d001-20200213
i386 randconfig-d002-20200213
i386 randconfig-d003-20200213
x86_64 randconfig-d001-20200214
x86_64 randconfig-d002-20200214
x86_64 randconfig-d003-20200214
i386 randconfig-d001-20200214
i386 randconfig-d002-20200214
i386 randconfig-d003-20200214
x86_64 randconfig-e001-20200213
x86_64 randconfig-e002-20200213
x86_64 randconfig-e003-20200213
i386 randconfig-e001-20200213
i386 randconfig-e002-20200213
i386 randconfig-e003-20200213
x86_64 randconfig-e001-20200214
x86_64 randconfig-e002-20200214
x86_64 randconfig-e003-20200214
i386 randconfig-e001-20200214
i386 randconfig-e002-20200214
i386 randconfig-e003-20200214
x86_64 randconfig-f001-20200213
x86_64 randconfig-f002-20200213
x86_64 randconfig-f003-20200213
i386 randconfig-f001-20200213
i386 randconfig-f002-20200213
i386 randconfig-f003-20200213
x86_64 randconfig-f001-20200214
x86_64 randconfig-f002-20200214
x86_64 randconfig-f003-20200214
i386 randconfig-f001-20200214
i386 randconfig-f002-20200214
i386 randconfig-f003-20200214
x86_64 randconfig-g001-20200213
x86_64 randconfig-g002-20200213
x86_64 randconfig-g003-20200213
i386 randconfig-g001-20200213
i386 randconfig-g002-20200213
i386 randconfig-g003-20200213
x86_64 randconfig-g001-20200214
x86_64 randconfig-g002-20200214
x86_64 randconfig-g003-20200214
i386 randconfig-g001-20200214
i386 randconfig-g002-20200214
i386 randconfig-g003-20200214
x86_64 randconfig-h001-20200214
x86_64 randconfig-h002-20200214
x86_64 randconfig-h003-20200214
i386 randconfig-h001-20200214
i386 randconfig-h002-20200214
i386 randconfig-h003-20200214
x86_64 randconfig-h001-20200213
x86_64 randconfig-h002-20200213
x86_64 randconfig-h003-20200213
i386 randconfig-h001-20200213
i386 randconfig-h002-20200213
i386 randconfig-h003-20200213
arc randconfig-a001-20200213
arm randconfig-a001-20200213
arm64 randconfig-a001-20200213
ia64 randconfig-a001-20200213
powerpc randconfig-a001-20200213
sparc randconfig-a001-20200213
arc randconfig-a001-20200214
arm randconfig-a001-20200214
arm64 randconfig-a001-20200214
ia64 randconfig-a001-20200214
powerpc randconfig-a001-20200214
sparc randconfig-a001-20200214
s390 zfcpdump_defconfig
sh allmodconfig
sh allnoconfig
sh rsk7269_defconfig
sparc64 allyesconfig
sparc64 defconfig
um defconfig
um x86_64_defconfig
x86_64 fedora-25
x86_64 kexec
x86_64 lkp
x86_64 rhel
x86_64 rhel-7.2-clear
x86_64 rhel-7.6
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: How do UEFI on Windows host
From: Laszlo Ersek @ 2020-02-14 21:24 UTC (permalink / raw)
To: Philippe Mathieu-Daudé, Jerry Geis; +Cc: Stefan Weil, qemu-devel
In-Reply-To: <6aad5b16-53c5-4485-381c-1cb990c8b766@redhat.com>
On 02/14/20 19:12, Philippe Mathieu-Daudé wrote:
> On 2/14/20 5:37 PM, Jerry Geis wrote:
>> I dont know how to get all files listing on windows. But, I cd
>> \program files\qemu
>> dir *.fd
>> edk2-x86_64-code.fd
>> edk2-x86_64-secure-code.fd
>>
>> It seems like from other posts these might be the files - but still
>> not sure how to do "boot" a command line for UEFI.
>
> I tested/added these files in commit e54ecc70c34:
>
> NSIS: Add missing firmware blobs
>
> Various firmwares has been added in the pc-bios/ directory:
>
> - CCW (since commit 0c1fecdd523)
> - skiboot (since commit bcad45de6a0)
> - EDK2 (since commit f7fa38b74c3)
>
> Stefan can you describe how you generate the binaries in
> https://qemu.weilnetz.de/w64/ ? Maybe the bunzip2 step is not called?
>
Thank you, Phil! The following line from your patch:
+ File "${BINDIR}\*.fd"
should hopefully cover everything that Jerry needs. So I guess the only
missing piece is the right QEMU command line.
Jerry:
(1) You will have to manage the virtual machine's private variable store
file manually.
You have to create the varstore manually first, from the varstore
template: copy "edk2-i386-vars.fd" to a new file; for example, to
"my-guest.vars.fd".
Then you have to treat "my-guest.vars.fd" like another data disk, for
the guest.
Never use the "edk2-i386-vars.fd" template file itself on any QEMU
command line.
(2) Next step, choose one of the following firmware binaries:
(2a) edk2-x86_64-code.fd
(2b) edk2-x86_64-secure-code.fd
The (2a) firmware binary runs on both the i440fx ("pc") machine type,
and the q35 machine type. It does not include the Secure Boot UEFI
feature. It also does not include the edk2 SMM stack. Use this binary if
you don't care about Secure Boot for your guest, or insist on using
"pc".
The (2b) firmware binary runs only on "q35". It's strongly recommended
to use the latest version of the "q35" machine type available in your
QEMU executable, with this firmware binary. This firmware binary
includes both the Secure Boot feature, and the edk2 SMM stack. (The
latter is used to protect the former, but that's not really important
now.) The "q35" machine type restriction actually comes from the SMM
stack. Use this firmware binary if you want the Secure Boot feature.
In case you pick (2b), note that the Secure Boot *operational mode* is
not automatically enabled in your guest. You will have to enroll SB keys
/ certificates manually. You can do that e.g. in the firmware setup TUI
in the guest. You can find resources about this on the net.
(3) Assuming you've picked your firmware binary, here are the
*additional* command line options for qemu-system-x86_64 (that is, these
options should be appended after your usual options):
- For (2a):
-machine pflash0=firmware-executable,pflash1=variable-store \
-blockdev node-name=firmware-executable,read-only=on,driver=file,filename=edk2-x86_64-code.fd \
-blockdev node-name=variable-store,read-only=off,driver=file,filename=my-guest.vars.fd \
- For (2b): everything you see under (2a), *plus*
-machine type=q35,smm=on \
-global driver=cfi.pflash01,property=secure,value=on \
(Don't forget to change the filename in the "firmware-executable"
blockdev, from "edk2-x86_64-code.fd" to "edk2-x86_64-secure-code.fd"!)
(4) If you'd like a progress bar (a bit of time) at the OVMF splash
screen, you can append (in either case):
-boot menu=on,splash-time=5000 \
(5) In order to capture the firmware debug log, append:
-global isa-debugcon.iobase=0x402 \
-debugcon file:ovmf_log.txt \
(6) Note that firmware-specific options that you may be used to with
SeaBIOS are not guaranteed to behave identically (or at all) with OVMF.
Some examples (not an exhaustive list):
- with the "-boot" option, only "menu" and "splash-time" are supported,
and they don't work identically to SeaBIOS
- "-boot strict=on" is always assumed
- to highlight boot order setting, "-boot order=..." does not (cannot)
work with UEFI; you have to use the device-specific "bootindex"
properties. For example, to place a virtio-scsi CD-ROM first in the
boot order, use:
-device virtio-scsi-pci,id=scsi0 \
-device scsi-cd,bus=scsi0.0,drive=BlockDevName,bootindex=0 \
^^^^^^^^^^^
If you specify at least one "bootindex" property, then you should
specify bootindex properties with *all* devices that you want to
attempt booting from. (See "strict" above.)
- Avoid switches like "-hda"; use the full-blown blockdev (backend) +
device (frontend) syntax.
(Note that libvirt would automate away almost all of the above for you.
But I'm unsure if you can, or are willing to, use libvirt on a Windows
host.)
(7) In the general case, you can't boot a 64-bit OS on a 32-bit UEFI
firmware, nor vice versa. The "bitnesses" must match. (People forget
this frequently.)
Hope this helps,
Laszlo
^ permalink raw reply
* [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Init lspcon after HPD in intel_dp_detect()
From: Patchwork @ 2020-02-14 21:24 UTC (permalink / raw)
To: Kai-Heng Feng; +Cc: intel-gfx
In-Reply-To: <20200214175646.25532-1-kai.heng.feng@canonical.com>
== Series Details ==
Series: drm/i915: Init lspcon after HPD in intel_dp_detect()
URL : https://patchwork.freedesktop.org/series/73480/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7942 -> Patchwork_16576
====================================================
Summary
-------
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16576/index.html
Known issues
------------
Here are the changes found in Patchwork_16576 that come from known issues:
### IGT changes ###
#### Possible fixes ####
* igt@gem_exec_parallel@contexts:
- fi-byt-n2820: [FAIL][1] ([i915#694]) -> [PASS][2]
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7942/fi-byt-n2820/igt@gem_exec_parallel@contexts.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16576/fi-byt-n2820/igt@gem_exec_parallel@contexts.html
* igt@gem_exec_parallel@fds:
- fi-byt-n2820: [TIMEOUT][3] ([fdo#112271] / [i915#1084]) -> [PASS][4]
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7942/fi-byt-n2820/igt@gem_exec_parallel@fds.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16576/fi-byt-n2820/igt@gem_exec_parallel@fds.html
* igt@i915_selftest@live_gem_contexts:
- fi-cfl-8700k: [INCOMPLETE][5] ([i915#424]) -> [PASS][6]
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7942/fi-cfl-8700k/igt@i915_selftest@live_gem_contexts.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16576/fi-cfl-8700k/igt@i915_selftest@live_gem_contexts.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#112271]: https://bugs.freedesktop.org/show_bug.cgi?id=112271
[i915#1084]: https://gitlab.freedesktop.org/drm/intel/issues/1084
[i915#424]: https://gitlab.freedesktop.org/drm/intel/issues/424
[i915#694]: https://gitlab.freedesktop.org/drm/intel/issues/694
[i915#937]: https://gitlab.freedesktop.org/drm/intel/issues/937
Participating hosts (47 -> 41)
------------------------------
Additional (4): fi-bsw-kefka fi-blb-e6850 fi-cfl-8109u fi-ilk-650
Missing (10): fi-ilk-m540 fi-bdw-5557u fi-hsw-4200u fi-hsw-peppy fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-icl-u3 fi-skl-lmem fi-bdw-samus
Build changes
-------------
* CI: CI-20190529 -> None
* Linux: CI_DRM_7942 -> Patchwork_16576
CI-20190529: 20190529
CI_DRM_7942: f4805f5a516d0a107438ff0f236c9f4187434819 @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_5442: 3f6080996885b997685f08ecb8b416b2dc485290 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_16576: b2ae75309a73a42403618e73da934af0caf97eec @ git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
b2ae75309a73 drm/i915: Init lspcon after HPD in intel_dp_detect()
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16576/index.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.