All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 1/2] platform: Fix device check for surfacepro3_button
From: Maximilian Luz @ 2019-06-20 11:50 UTC (permalink / raw)
  Cc: linux-kernel, linux-input, platform-driver-x86, Dmitry Torokhov,
	Hans de Goede, Chen Yu, Darren Hart, Andy Shevchenko,
	Benjamin Tissoires, Maximilian Luz
In-Reply-To: <20190620115056.4169-1-luzmaximilian@gmail.com>

Do not use the surfacepro3_button driver on newer Microsoft Surface
models, only use it on the Surface Pro 3 and 4. Newer models (5th, 6th
and possibly future generations) use the same device as the Surface Pro
4 to represent their volume and power buttons (MSHW0040), but their
acutal implementation is significantly different. This patch ensures
that the surfacepro3_button driver is only used on the Pro 3 and 4
models, allowing a different driver to bind on other models.

Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com>
---
 drivers/platform/x86/surfacepro3_button.c | 38 +++++++++++++++++++++++
 1 file changed, 38 insertions(+)

diff --git a/drivers/platform/x86/surfacepro3_button.c b/drivers/platform/x86/surfacepro3_button.c
index 47c6d000465a..0e2c7dfafd9f 100644
--- a/drivers/platform/x86/surfacepro3_button.c
+++ b/drivers/platform/x86/surfacepro3_button.c
@@ -20,6 +20,12 @@
 #define SURFACE_BUTTON_OBJ_NAME		"VGBI"
 #define SURFACE_BUTTON_DEVICE_NAME	"Surface Pro 3/4 Buttons"
 
+#define MSHW0040_DSM_REVISION		0x01
+#define MSHW0040_DSM_GET_OMPR		0x02	// get OEM Platform Revision
+static const guid_t MSHW0040_DSM_UUID =
+	GUID_INIT(0x6fd05c69, 0xcde3, 0x49f4, 0x95, 0xed, 0xab, 0x16, 0x65,
+		  0x49, 0x80, 0x35);
+
 #define SURFACE_BUTTON_NOTIFY_TABLET_MODE	0xc8
 
 #define SURFACE_BUTTON_NOTIFY_PRESS_POWER	0xc6
@@ -142,6 +148,34 @@ static int surface_button_resume(struct device *dev)
 }
 #endif
 
+/*
+ * Surface Pro 4 and Surface Book 2 / Surface Pro 2017 use the same device
+ * ID (MSHW0040) for the power/volume buttons. Make sure this is the right
+ * device by checking for the _DSM method and OEM Platform Revision.
+ */
+static int surface_button_check_MSHW0040(struct acpi_device *dev)
+{
+	acpi_handle handle = dev->handle;
+	union acpi_object *result;
+	u64 oem_platform_rev = 0;
+
+	// get OEM platform revision
+	result = acpi_evaluate_dsm_typed(handle, &MSHW0040_DSM_UUID,
+					 MSHW0040_DSM_REVISION,
+					 MSHW0040_DSM_GET_OMPR,
+					 NULL, ACPI_TYPE_INTEGER);
+
+	if (result) {
+		oem_platform_rev = result->integer.value;
+		ACPI_FREE(result);
+	}
+
+	dev_dbg(&dev->dev, "OEM Platform Revision %llu\n", oem_platform_rev);
+
+	return oem_platform_rev == 0 ? 0 : -ENODEV;
+}
+
+
 static int surface_button_add(struct acpi_device *device)
 {
 	struct surface_button *button;
@@ -154,6 +188,10 @@ static int surface_button_add(struct acpi_device *device)
 	    strlen(SURFACE_BUTTON_OBJ_NAME)))
 		return -ENODEV;
 
+	error = surface_button_check_MSHW0040(device);
+	if (error)
+		return error;
+
 	button = kzalloc(sizeof(struct surface_button), GFP_KERNEL);
 	if (!button)
 		return -ENOMEM;
-- 
2.22.0

^ permalink raw reply related

* [PATCH 0/2] Support for buttons on newer MS Surface devices
From: Maximilian Luz @ 2019-06-20 11:50 UTC (permalink / raw)
  Cc: linux-kernel, linux-input, platform-driver-x86, Dmitry Torokhov,
	Hans de Goede, Chen Yu, Darren Hart, Andy Shevchenko,
	Benjamin Tissoires, Maximilian Luz

This series adds suport for power and volume buttons on 5th and 6th
generation Microsoft Surface devices. Specifically, it adds support for
the power-button on the Surface Laptop 1 and Laptop 2, as well as
support for power- and (on-device) volume-buttons on the Surface Pro 5
(2017), Pro 6, and Book 2.

These devices use the same MSHW0040 device as on the Surface Pro 4,
however, whereas the Pro 4 uses an ACPI notify handler, the newer
devices use GPIO interrupts to signal these events.

The first patch of this series ensures that the surfacepro3_button
driver, used for MSHW0040 on the Pro 4, does not probe for the newer
devices. The second patch adapts soc_button_array to implement the
actual button support.

I think the changes to soc_button_array in the second patch warrant a
thorough review. I've tried to make things a bit more generic to be able
to integrate arbitrary ACPI GPIO power-/volume-button devices more
easily, I'm not sure if there may be reasons against this.

These patches have also been tested on various Surface devices via the
github.com/jakeday/linux-surface patchset.

Maximilian Luz (2):
  platform: Fix device check for surfacepro3_button
  input: soc_button_array for newer surface devices

 drivers/input/misc/soc_button_array.c     | 134 ++++++++++++++++++++--
 drivers/platform/x86/surfacepro3_button.c |  38 ++++++
 2 files changed, 160 insertions(+), 12 deletions(-)

-- 
2.22.0

^ permalink raw reply

* Re: [PATCH] drm/imx: correct order of crtc disable
From: Philipp Zabel @ 2019-06-20 11:50 UTC (permalink / raw)
  To: Robert Beckett, Daniel Vetter; +Cc: dri-devel
In-Reply-To: <4fceab36a9d800249b66bfd37114d63fc3386d29.camel@collabora.com>

Hi Robert, Daniel,

On Thu, 2019-06-20 at 12:12 +0100, Robert Beckett wrote:
> On Thu, 2019-06-20 at 10:50 +0200, Daniel Vetter wrote:
> > On Wed, Jun 19, 2019 at 11:40 AM Philipp Zabel <
> > p.zabel@pengutronix.de> wrote:
> > > 
> > > Hi Robert,
> > > 
> > > thank you for the patch.
> > > 
> > > On Tue, 2019-06-18 at 16:50 +0100, Robert Beckett wrote:
> > > > Notify drm core before sending pending events during crtc
> > > > disable.
> > > > This fixes the first event after disable having an old stale
> > > > timestamp
> > > > by having drm_crtc_vblank_off update the timestamp to now.
> > > > 
> > > > This was seen while debugging weston log message:
> > > > Warning: computed repaint delay is insane: -8212 msec
> > > > 
> > > 
> > > Would you say this
> > > Fixes: a474478642d5 ("drm/imx: fix crtc vblank state regression")
> > > ?
> > > 
> > > > Signed-off-by: Robert Beckett <bob.beckett@collabora.com>
> > > > ---
> > > >  drivers/gpu/drm/imx/ipuv3-crtc.c | 6 +++---
> > > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c
> > > > b/drivers/gpu/drm/imx/ipuv3-crtc.c
> > > > index 9cc1d678674f..c436a28d50e4 100644
> > > > --- a/drivers/gpu/drm/imx/ipuv3-crtc.c
> > > > +++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
> > > > @@ -91,14 +91,14 @@ static void ipu_crtc_atomic_disable(struct
> > > > drm_crtc *crtc,
> > > >       ipu_dc_disable(ipu);
> > > >       ipu_prg_disable(ipu);
> > > > 
> > > > +     drm_crtc_vblank_off(crtc);
> > > > +
> > > 
> > > This is explained in the commit message and aligns with the
> > > drm_crtc_state @event documentation.
> > 
> > This part here looks fishy. The drm_vblank.c code is supposed to do
> > the right thing, no matter where or when you ask it to generate an
> > event. It definitely shouldn't generate a timestamp that's a few
> > seconds too early. Bunch of options:
> > - there's a bug in drm_vblank.c and it's mixing up something and
> > generating a totally bogus value.
> > - there's a lie in your imx vblank code, which trips the drm_vblank.c
> > counter interpolation and results in a totally bogus value.
> > 
> > drm_vblank.c assumes that if you do claim to have a hw counter and
> > generate timestamps, that those are perfectly accurate. It only falls
> > back to guestimating using the system timer if that's not present.
> > 
> > Either way, this very much smells like papering over a bug if this
> > change indeed fixes your wrong vblank timestamps.

Thank you for chiming in, I can confirm that just moving the
drm_crtc_vblank_off around does not change anything.
I'll drop this patch and wait for v3.

> A quick explaination of where the dodgy timestamp came from:
> 1. driver starts up
> 2. fbcon comes along and restores fbdev, enabling vblank
> 3. vblank_disable_fn fires via timer disabling vblank, keeping vblank
> seq number and time set at current value
> (some time later)
> 4. weston starts and does a modeset
> 5. atomic commit disables crtc while it does the modeset
> 6. ipu_crtc_atomic_disable sends vblank with old seq number and time

It would be great to have this in the commit message for context.

> It turns out the actual fix for the old vblank is the next change,
> which stops it being sent at all during the crtc disable as it is is
> still active, it would then go through drm_crtc_vblank_off, reseting
> the timestamp, and get delivered during the vblank enable as part of
> the atomic commit.

Which means this patch isn't "Fixes: a474478642d5" after all.
The offending code has been there since commit 5f2f911578fb ("drm/imx:
atomic phase 3 step 1: Use atomic configuration").

> So, in theory, we could just have the following change to fix the
> specific issue of a stale timestamp.
>
> However, given the documentation for the event in
> include/drm/drm_crtc.h:
> 
>          *  - The event is for a CRTC which is being disabled through this
>          *    atomic commit. In that case the event can be send out any time
>          *    after the hardware has stopped scanning out the current 
>          *    framebuffers. It should contain the timestamp and counter for the
>          *    last vblank before the display pipeline was shut off. The simplest
>          *    way to achieve that is calling drm_crtc_send_vblank_event()
>          *    somewhen after drm_crtc_vblank_off() has been called.
> 
> This still seems like a sensible change for when the crtc is being
> disabled.

This is what had me confused as well. It doesn't really say, but it
seems to imply that drm_crtc_send_vblank_event must only be sent after
drm_crtc_vblank_off.
If this is not a hard requirement, maybe this could be mentioned here?

> > > >       spin_lock_irq(&crtc->dev->event_lock);
> > > > -     if (crtc->state->event)
> > > > {
> > > > +     if (crtc->state->event && !crtc->state->active) {
> > > 
> > > This is not mentioned though.
> > > 
> > > If the pending event is not sent here, I assume it will be picked
> > > up by
> > > .atomic_flush and will then be sent after the first EOF interrupt
> > > after
> > > the modeset is complete. Can you explain this in the commit
> > > message?
> > 
> > Yeah looks correct (you only want to generate the event here when the
> > crtc stays off), if it gets re-enabled the event should only be
> > generated later on once that's all finished. But separate bugfix.
> > -Daniel
> > 
> 
> It looks like this is actually the fix needed to avoid the bogus
> timestamp.
> 
> I can split this patch up in to 2 commits if desired?

Yes, please. The !state->active fix is stable material, moving
drm_crtc_vblank_off around apparently not so much.

regards
Philipp
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply

* [LTP] [PATCH v2] security: add missing PR_CAPBSET_READ/PR_CAPBSET_DROP check
From: Petr Vorel @ 2019-06-20 11:49 UTC (permalink / raw)
  To: ltp
In-Reply-To: <1557989579-3661-1-git-send-email-xuyang2018.jy@cn.fujitsu.com>

Hi Yang,

> PR_CAPBSET_READ/PR_CAPNSET_DROP was added since linux2.6.25,
> current ltp detected them in ltp-prctl.m4, but three places
> missed this check. So add it, fix possible compiler error
> on some old dirtros without PR_CAPBSET_READ/PR_CAPNSET_DROP flag.

Thanks for your patch, merged.

BTW these cap files would deserve converting into new API.

Kind regards,
Petr

^ permalink raw reply

* [thud/master][PATCH v2 3/3] glow: Add glow and demo-glow to packagegroups
From: Djordje Senicic @ 2019-06-20  6:38 UTC (permalink / raw)
  To: meta-arago; +Cc: Djordje Senicic
In-Reply-To: <20190620063815.18898-1-x0157990@ti.com>

- Add glow to nativesdk
- Add demo to target and src packagegroups
- Also include demo-glow to example-applications

Signed-off-by: Djordje Senicic <x0157990@ti.com>
---
 .../packagegroups/packagegroup-arago-tisdk-addons-sdk-host.bb | 3 +++
 .../packagegroup-arago-tisdk-addons-sdk-target.bb             | 3 +++
 .../packagegroups/packagegroup-arago-tisdk-addons.bb          | 3 +++
 .../recipes-tisdk/ti-tisdk-makefile/ti-tisdk-makefile_1.0.bb  | 4 ++++
 .../packagegroups/nativesdk-packagegroup-arago-tisdk-host.bb  | 1 +
 5 files changed, 14 insertions(+)

diff --git a/meta-arago-distro/recipes-core/packagegroups/packagegroup-arago-tisdk-addons-sdk-host.bb b/meta-arago-distro/recipes-core/packagegroups/packagegroup-arago-tisdk-addons-sdk-host.bb
index 3b734554..addb4818 100644
--- a/meta-arago-distro/recipes-core/packagegroups/packagegroup-arago-tisdk-addons-sdk-host.bb
+++ b/meta-arago-distro/recipes-core/packagegroups/packagegroup-arago-tisdk-addons-sdk-host.bb
@@ -90,14 +90,17 @@ EXTRA_PACKAGES = ""
 
 EXTRA_PACKAGES_append_omap-a15 = " \
     pdm-anomaly-detection-src \
+    demo-glow-src \
 "
 
 EXTRA_PACKAGES_append_ti33x = " \
     pdm-anomaly-detection-src \
+    demo-glow-src \
 "
 
 EXTRA_PACKAGES_append_ti43x = " \
     pdm-anomaly-detection-src \
+    demo-glow-src \
 "
 
 EXTRA_PACKAGES_append_k3 = " \
diff --git a/meta-arago-distro/recipes-core/packagegroups/packagegroup-arago-tisdk-addons-sdk-target.bb b/meta-arago-distro/recipes-core/packagegroups/packagegroup-arago-tisdk-addons-sdk-target.bb
index 8bce1756..d998a1eb 100644
--- a/meta-arago-distro/recipes-core/packagegroups/packagegroup-arago-tisdk-addons-sdk-target.bb
+++ b/meta-arago-distro/recipes-core/packagegroups/packagegroup-arago-tisdk-addons-sdk-target.bb
@@ -161,16 +161,19 @@ EXTRA_PACKAGES_append_ti33x = " voxelsdk-dev \
                                 arm-compute-library-dev \
                                 ${ARMNN_PACKAGES} \
                                 pdm-anomaly-detection-dev \
+                                demo-glow-dev \
 "
 EXTRA_PACKAGES_append_ti43x = " voxelsdk-dev \
                                 arm-compute-library-dev \
                                 ${ARMNN_PACKAGES} \
                                 pdm-anomaly-detection-dev \
+                                demo-glow-dev \
 "
 EXTRA_PACKAGES_append_omap-a15 = " voxelsdk-dev \
                                 arm-compute-library-dev \
                                 ${ARMNN_PACKAGES} \
                                 pdm-anomaly-detection-dev \
+                                demo-glow-dev \
 "
 EXTRA_PACKAGES_append_k3 = " arm-compute-library-dev \
                              ${ARMNN_PACKAGES} \
diff --git a/meta-arago-distro/recipes-core/packagegroups/packagegroup-arago-tisdk-addons.bb b/meta-arago-distro/recipes-core/packagegroups/packagegroup-arago-tisdk-addons.bb
index 6558a21a..38ec3065 100644
--- a/meta-arago-distro/recipes-core/packagegroups/packagegroup-arago-tisdk-addons.bb
+++ b/meta-arago-distro/recipes-core/packagegroups/packagegroup-arago-tisdk-addons.bb
@@ -152,12 +152,14 @@ EXTRA_PACKAGES_append_ti33x = " voxelsdk \
                                 arm-compute-library \
                                 ${ARMNN_PACKAGES} \
                                 pdm-anomaly-detection \
+                                demo-glow \
 "
 
 EXTRA_PACKAGES_append_ti43x = " voxelsdk \
                                 arm-compute-library \
                                 ${ARMNN_PACKAGES} \
                                 pdm-anomaly-detection \
+                                demo-glow \
 "
 
 EXTRA_PACKAGES_append_omap-a15 = " voxelsdk \
@@ -166,6 +168,7 @@ EXTRA_PACKAGES_append_omap-a15 = " voxelsdk \
                                    arm-compute-library \
                                    ${ARMNN_PACKAGES} \
                                    pdm-anomaly-detection \
+                                   demo-glow \
 "
 
 EXTRA_PACKAGES_append_k3 = " arm-compute-library \
diff --git a/meta-arago-distro/recipes-tisdk/ti-tisdk-makefile/ti-tisdk-makefile_1.0.bb b/meta-arago-distro/recipes-tisdk/ti-tisdk-makefile/ti-tisdk-makefile_1.0.bb
index e0d409a2..2200def1 100644
--- a/meta-arago-distro/recipes-tisdk/ti-tisdk-makefile/ti-tisdk-makefile_1.0.bb
+++ b/meta-arago-distro/recipes-tisdk/ti-tisdk-makefile/ti-tisdk-makefile_1.0.bb
@@ -52,6 +52,7 @@ SRC_URI = "\
     file://Makefile_sysfw-image \
     file://Makefile_mmwavegesture-hmi \
     file://Makefile_pdm-anomaly-detection \
+    file://Makefile_demo-glow \
 "
 
 PR = "r95"
@@ -98,6 +99,7 @@ MAKEFILES_append_ti33x = " u-boot-spl \
                            uio-module-drv \
 			   mmwavegesture-hmi \
                            pdm-anomaly-detection \
+                           demo-glow \
 "
 MAKEFILES_append_ti43x = " u-boot-spl \
                            ${QUICK_PLAYGROUND} \
@@ -113,6 +115,7 @@ MAKEFILES_append_ti43x = " u-boot-spl \
                            uio-module-drv \
 			   mmwavegesture-hmi \
                            pdm-anomaly-detection \
+                           demo-glow \
 "
 
 #                            debugss-module-drv 
@@ -136,6 +139,7 @@ MAKEFILES_append_omap-a15 = " u-boot-spl \
                               uio-module-drv \
 			      mmwavegesture-hmi \
                               pdm-anomaly-detection \
+                              demo-glow \
 "
 MAKEFILES_append_omapl138 = " linux-dtbs \
                               u-boot-spl \
diff --git a/meta-arago-extras/recipes-core/packagegroups/nativesdk-packagegroup-arago-tisdk-host.bb b/meta-arago-extras/recipes-core/packagegroups/nativesdk-packagegroup-arago-tisdk-host.bb
index ef54253d..28d817da 100644
--- a/meta-arago-extras/recipes-core/packagegroups/nativesdk-packagegroup-arago-tisdk-host.bb
+++ b/meta-arago-extras/recipes-core/packagegroups/nativesdk-packagegroup-arago-tisdk-host.bb
@@ -17,6 +17,7 @@ EXTRA_TI_TOOLS = " \
     nativesdk-tidl-viewer \
     nativesdk-tidl-utils \
     nativesdk-gcc-arm-none-eabi \
+    nativesdk-glow \
 "
 
 RDEPENDS_${PN} = "\
-- 
2.17.1



^ permalink raw reply related

* [thud/master][PATCH v2 2/3] demo-glow: Add mnist inference demo based on GLOW compiler
From: Djordje Senicic @ 2019-06-20  6:38 UTC (permalink / raw)
  To: meta-arago; +Cc: Djordje Senicic
In-Reply-To: <20190620063815.18898-1-x0157990@ti.com>

Signed-off-by: Djordje Senicic <x0157990@ti.com>
---
 .../recipes-apps/demo-glow/demo-glow.bb       | 46 +++++++++++++++++++
 .../files/0001-fix-missing-string.patch       | 10 ++++
 .../demo-glow/files/Makefile.build            | 18 ++++++++
 .../recipes-apps/demo-glow/files/makefile     | 13 ++++++
 4 files changed, 87 insertions(+)
 create mode 100644 meta-arago-extras/recipes-apps/demo-glow/demo-glow.bb
 create mode 100644 meta-arago-extras/recipes-apps/demo-glow/files/0001-fix-missing-string.patch
 create mode 100644 meta-arago-extras/recipes-apps/demo-glow/files/Makefile.build
 create mode 100644 meta-arago-extras/recipes-apps/demo-glow/files/makefile

diff --git a/meta-arago-extras/recipes-apps/demo-glow/demo-glow.bb b/meta-arago-extras/recipes-apps/demo-glow/demo-glow.bb
new file mode 100644
index 00000000..c7422948
--- /dev/null
+++ b/meta-arago-extras/recipes-apps/demo-glow/demo-glow.bb
@@ -0,0 +1,46 @@
+DESCRIPTION = "Demo application based on pytorch neural network compiler glow, using mnist model" 
+HOMEPAGE = "https://github.com/pytorch/glow/tree/master/examples/bundles/lenet_mnist"
+SECTION = "examples" 
+LICENSE = "Apache-2.0" 
+LIC_FILES_CHKSUM = "file://LICENSE;md5=86d3f3a95c324c9479bd8986968f4327"
+
+PV = "1.0"
+PR = "r1" 
+
+DEPENDS    = "glow-native libpng"
+
+SRC_URI = "https://raw.githubusercontent.com/pytorch/glow/1af031c9c040dd4ff843d9b50f83e71f6e605631/examples/bundles/lenet_mnist/main.cpp;name=lenet_mnist_main;subdir=src \
+           file://0001-fix-missing-string.patch \
+           file://makefile;subdir=src \
+           file://Makefile.build;subdir=src \
+           http://fb-glow-assets.s3.amazonaws.com/models/lenet_mnist.tar.gz;name=lenet_mnist;subdir=src \
+           https://raw.githubusercontent.com/pytorch/glow/1af031c9c040dd4ff843d9b50f83e71f6e605631/LICENSE;name=lenet_mnist_license;subdir=src \
+          "
+
+SRC_URI[lenet_mnist.md5sum] = "7aded5f273b3198795683c238492d1a9"
+SRC_URI[lenet_mnist_main.md5sum] = "e80ec7a97dec86828ff1a51026c237bc"
+SRC_URI[lenet_mnist_license.md5sum] = "86d3f3a95c324c9479bd8986968f4327"
+
+S = "${WORKDIR}/src"
+
+do_compile() {
+   install -d ${WORKDIR}/build
+   ${STAGING_DIR_NATIVE}/usr/share/glow/bin/image-classifier ${STAGING_DIR_NATIVE}/usr/share/glow/tests/images/mnist/1_1008.png -m=mnist.onnx -image-mode=0to1 -model-input-name=data_0 -emit-bundle ${WORKDIR}/build/ -cpu -target armv7l-unknown-linux-gnueabihf   -network-name="lenet_mnist"
+   ${CXX} ${S}/main.cpp ${WORKDIR}/build/lenet_mnist.o -lm -lpng -fpack-struct=8 -fpermissive -o ${WORKDIR}/build/infer_mnist
+}
+
+do_install () {
+   install -d ${D}${datadir}/glow/infer
+   install -d ${D}${datadir}/glow/tests
+   cp -Prf --preserve=mode,timestamps ${WORKDIR}/build/*.weights ${D}${datadir}/glow/infer
+   cp -Prf --preserve=mode,timestamps ${WORKDIR}/build/infer_mnist ${D}${datadir}/glow/infer
+   cp -Prf --preserve=mode,timestamps ${WORKDIR}/build/lenet_mnist.o ${D}${datadir}/glow/infer
+   cp -Prf --preserve=mode,timestamps ${WORKDIR}/src/makefile ${D}${datadir}/glow/infer
+   cp -Prf --preserve=mode,timestamps ${WORKDIR}/src/main.cpp ${D}${datadir}/glow/infer
+   cp -Prf --preserve=mode,timestamps ${STAGING_DIR_NATIVE}/usr/share/glow/tests/images/mnist/*.png ${D}${datadir}/glow/tests/.
+}
+
+FILES_${PN} += "${datadir}/glow"
+
+CREATE_SRCIPK = "1"
+SRCIPK_INSTALL_DIR = "example-applications/${PN}-${PV}"
diff --git a/meta-arago-extras/recipes-apps/demo-glow/files/0001-fix-missing-string.patch b/meta-arago-extras/recipes-apps/demo-glow/files/0001-fix-missing-string.patch
new file mode 100644
index 00000000..ba0533ab
--- /dev/null
+++ b/meta-arago-extras/recipes-apps/demo-glow/files/0001-fix-missing-string.patch
@@ -0,0 +1,10 @@
+--- ./main.cpp	2019-06-06 13:31:07.485528729 -0400
++++ ./main_mod.cpp	2019-06-06 13:30:50.333529003 -0400
+@@ -18,6 +18,7 @@
+ #include <png.h>
+ #include <stdio.h>
+ #include <stdlib.h>
++#include <string.h>
+ 
+ #include <string>
+ #include <vector>
diff --git a/meta-arago-extras/recipes-apps/demo-glow/files/Makefile.build b/meta-arago-extras/recipes-apps/demo-glow/files/Makefile.build
new file mode 100644
index 00000000..399cc3c0
--- /dev/null
+++ b/meta-arago-extras/recipes-apps/demo-glow/files/Makefile.build
@@ -0,0 +1,18 @@
+-include ../../Rules.make
+
+ENV_SETUP ?= ../../linux-devkit/environment-setup
+DESTDIR ?=
+
+all: release
+
+lenet_mnist:
+	${SDK_PATH_NATIVE}/usr/share/glow/bin/image-classifier ${SDK_PATH_NATIVE}/usr/share/glow/tests/images/mnist/1_1008.png -m=mnist.onnx -image-mode=0to1 -model-input-name=data_0 -emit-bundle ./ -cpu -target armv7l-unknown-linux-gnueabihf   -network-name="lenet_mnist"
+
+release: lenet_mnist
+	@. ${ENV_SETUP}; \
+	make
+
+clean:
+	@. ${ENV_SETUP}; \
+        make clean
+	rm lenet_mnist.*
diff --git a/meta-arago-extras/recipes-apps/demo-glow/files/makefile b/meta-arago-extras/recipes-apps/demo-glow/files/makefile
new file mode 100644
index 00000000..01b19c8c
--- /dev/null
+++ b/meta-arago-extras/recipes-apps/demo-glow/files/makefile
@@ -0,0 +1,13 @@
+PHONY: all
+
+all: infer_mnist
+LIBS = -lm -lpng
+
+infer_mnist: main.cpp lenet_mnist.o
+	$(CXX) main.cpp lenet_mnist.o -o infer_mnist $(LIBS) $(CXXFLAGS) -fpack-struct=8 -fpermissive
+
+clean:
+	rm -rf infer_mnist
+
+test:
+	./infer_mnist ../tests/0_1009.png
-- 
2.17.1



^ permalink raw reply related

* [thud/master][PATCH v2 1/3] glow: Add pytorch neural network compiler and dependencies
From: Djordje Senicic @ 2019-06-20  6:38 UTC (permalink / raw)
  To: meta-arago; +Cc: Djordje Senicic

- LLVM8 is added for GLOW compilation only (native package)
- glog and libunwind packages are also only used as native packages

Signed-off-by: Djordje Senicic <x0157990@ti.com>
---
 ...endencies-to-intermediate-executable.patch | 99 +++++++++++++++++++
 .../recipes-devtools/glow/glow_git.bb         | 63 ++++++++++++
 .../recipes-devtools/glow/llvm-glow_git.bb    | 24 +++++
 .../recipes-support/glog/glog_0.3.5.bbappend  |  3 +
 .../libunwind/libunwind_1.2.1.bbappend        |  3 +
 5 files changed, 192 insertions(+)
 create mode 100644 meta-arago-extras/recipes-devtools/glow/files/0001-Fix-path-and-dependencies-to-intermediate-executable.patch
 create mode 100644 meta-arago-extras/recipes-devtools/glow/glow_git.bb
 create mode 100644 meta-arago-extras/recipes-devtools/glow/llvm-glow_git.bb
 create mode 100644 meta-arago-extras/recipes-support/glog/glog_0.3.5.bbappend
 create mode 100644 meta-arago-extras/recipes-support/libunwind/libunwind_1.2.1.bbappend

diff --git a/meta-arago-extras/recipes-devtools/glow/files/0001-Fix-path-and-dependencies-to-intermediate-executable.patch b/meta-arago-extras/recipes-devtools/glow/files/0001-Fix-path-and-dependencies-to-intermediate-executable.patch
new file mode 100644
index 00000000..cdac2b63
--- /dev/null
+++ b/meta-arago-extras/recipes-devtools/glow/files/0001-Fix-path-and-dependencies-to-intermediate-executable.patch
@@ -0,0 +1,99 @@
+From 724ed36a3efc9d48baada931feef58d831bddd3e Mon Sep 17 00:00:00 2001
+From: Djordje Senicic <x0157990@ti.com>
+Date: Wed, 29 May 2019 03:51:13 -0400
+Subject: [PATCH] Fix path and dependencies to intermediate executables
+
+Signed-off-by: Djordje Senicic <x0157990@ti.com>
+---
+ lib/Backends/CPU/CMakeLists.txt    |  3 ++-
+ lib/Backends/OpenCL/CMakeLists.txt | 12 ++++++------
+ lib/Graph/CMakeLists.txt           |  4 ++--
+ lib/IR/CMakeLists.txt              |  4 ++--
+ 4 files changed, 12 insertions(+), 11 deletions(-)
+
+diff --git a/lib/Backends/CPU/CMakeLists.txt b/lib/Backends/CPU/CMakeLists.txt
+index 1e734539..5b79ee7d 100644
+--- a/lib/Backends/CPU/CMakeLists.txt
++++ b/lib/Backends/CPU/CMakeLists.txt
+@@ -53,8 +53,9 @@ add_custom_command(
+ file(MAKE_DIRECTORY ${CMAKE_BINARY_DIR}/glow/CPU)
+ add_custom_command(
+     OUTPUT ${CMAKE_BINARY_DIR}/glow/CPU/libjit_bc.inc
+-    COMMAND include-bin "${CMAKE_BINARY_DIR}/CPU/libjit.bc" "${CMAKE_BINARY_DIR}/glow/CPU/libjit_bc.inc"
++    COMMAND ${GLOW_BINARY_DIR}/bin/include-bin "${CMAKE_BINARY_DIR}/CPU/libjit.bc" "${CMAKE_BINARY_DIR}/glow/CPU/libjit_bc.inc"
+     DEPENDS ${GLOW_BINARY_DIR}/CPU/libjit.bc
++    DEPENDS ${GLOW_BINARY_DIR}/bin/include-bin
+     WORKING_DIRECTORY "${CMAKE_CURRENT_LIST_DIR}")
+ 
+ add_custom_target(CPURuntime
+diff --git a/lib/Backends/OpenCL/CMakeLists.txt b/lib/Backends/OpenCL/CMakeLists.txt
+index fd9f965c..e37b4b35 100644
+--- a/lib/Backends/OpenCL/CMakeLists.txt
++++ b/lib/Backends/OpenCL/CMakeLists.txt
+@@ -8,25 +8,25 @@ add_custom_target(make_opencl_dir
+ 
+ add_custom_command(
+   OUTPUT "${OpenCL_DIR}/kernels.cl.inc"
+-  COMMAND include-bin
++  COMMAND ${GLOW_BINARY_DIR}/bin/include-bin
+           "${CMAKE_CURRENT_SOURCE_DIR}/kernels.cl"
+           "${OpenCL_DIR}/kernels.cl.inc"
+-  DEPENDS make_opencl_dir include-bin "${CMAKE_CURRENT_SOURCE_DIR}/kernels.cl")
++  DEPENDS make_opencl_dir ${GLOW_BINARY_DIR}/bin/include-bin "${CMAKE_CURRENT_SOURCE_DIR}/kernels.cl")
+ 
+ add_custom_command(
+   OUTPUT "${OpenCL_DIR}/kernels_fwd_conv.cl.inc"
+-  COMMAND include-bin
++  COMMAND ${GLOW_BINARY_DIR}/bin/include-bin
+           "${CMAKE_CURRENT_SOURCE_DIR}/kernels_fwd_conv.cl"
+           "${OpenCL_DIR}/kernels_fwd_conv.cl.inc"
+-  DEPENDS make_opencl_dir include-bin
++  DEPENDS make_opencl_dir ${GLOW_BINARY_DIR}/bin/include-bin
+           "${CMAKE_CURRENT_SOURCE_DIR}/kernels_fwd_conv.cl")
+ 
+ add_custom_command(
+   OUTPUT "${OpenCL_DIR}/kernels_fwd_quantized_conv.cl.inc"
+-  COMMAND include-bin
++  COMMAND ${GLOW_BINARY_DIR}/bin/include-bin
+           "${CMAKE_CURRENT_SOURCE_DIR}/kernels_fwd_quantized_conv.cl"
+           "${OpenCL_DIR}/kernels_fwd_quantized_conv.cl.inc"
+-  DEPENDS make_opencl_dir include-bin
++  DEPENDS make_opencl_dir ${GLOW_BINARY_DIR}/bin/include-bin
+           "${CMAKE_CURRENT_SOURCE_DIR}/kernels_fwd_quantized_conv.cl")
+ 
+ add_library(OpenCLBackend
+diff --git a/lib/Graph/CMakeLists.txt b/lib/Graph/CMakeLists.txt
+index 84589761..02a92636 100644
+--- a/lib/Graph/CMakeLists.txt
++++ b/lib/Graph/CMakeLists.txt
+@@ -7,8 +7,8 @@ add_custom_command(OUTPUT
+                    "${NODES_HDR}"
+                    "${NODES_SRC}"
+                    "${NODES_DEF}"
+-                   COMMAND NodeGen ${NODES_HDR} ${NODES_SRC} ${NODES_DEF}
+-                   DEPENDS NodeGen
++                   COMMAND ${GLOW_BINARY_DIR}/bin/NodeGen ${NODES_HDR} ${NODES_SRC} ${NODES_DEF}
++                   DEPENDS ${GLOW_BINARY_DIR}/bin/NodeGen
+                    COMMENT "NodeGen: Generating nodes." VERBATIM)
+ add_custom_target(AutoGenNode
+                    DEPENDS
+diff --git a/lib/IR/CMakeLists.txt b/lib/IR/CMakeLists.txt
+index 7660308d..fb5302ce 100644
+--- a/lib/IR/CMakeLists.txt
++++ b/lib/IR/CMakeLists.txt
+@@ -13,10 +13,10 @@ add_custom_command(OUTPUT
+                     "${INSTR_BLD_HDR}"
+                     "${INSTR_BLD_SRC}"
+                     "${INSTR_IR_GEN}"
+-                    COMMAND InstrGen
++                    COMMAND ${GLOW_BINARY_DIR}/bin/InstrGen
+                       "${INSTR_HDR}" "${INSTR_SRC}" "${INSTR_DEF}"
+                       "${INSTR_BLD_HDR}" "${INSTR_BLD_SRC}" "${INSTR_IR_GEN}"
+-                    DEPENDS InstrGen
++                    DEPENDS ${GLOW_BINARY_DIR}/bin/InstrGen
+                     COMMENT "InstrGen: Generating instructions." VERBATIM)
+ add_custom_target(AutoGenInstr
+                    DEPENDS
+-- 
+2.17.1
+
diff --git a/meta-arago-extras/recipes-devtools/glow/glow_git.bb b/meta-arago-extras/recipes-devtools/glow/glow_git.bb
new file mode 100644
index 00000000..3aea4b14
--- /dev/null
+++ b/meta-arago-extras/recipes-devtools/glow/glow_git.bb
@@ -0,0 +1,63 @@
+DESCRIPTION = "Pytorch neural network compiler" 
+HOMEPAGE = "https://github.com/pytorch/glow"
+
+SECTION = "devel" 
+LICENSE = "Apache-2.0 & MIT" 
+LIC_FILES_CHKSUM = "file://LICENSE;md5=86d3f3a95c324c9479bd8986968f4327"
+PV = "0.1+git${SRCPV}"
+PR = "r0" 
+SRCREV_FORMAT = "glow"
+
+DEPENDS_class-native    = "zlib zlib-native llvm-glow-native ninja-native protobuf-native libpng-native protobuf-native protobuf-c-native gflags-native glog-native"
+DEPENDS_class-nativesdk = "ncurses protobuf libpng glow-native zlib llvm-glow-native ninja-native protobuf-native libpng-native protobuf-c-native gflags-native glog-native"
+
+RDEPENDS_${PN}_class-nativesdk = "libpng ncurses glog"
+
+SRC_URI = "git://github.com/pytorch/glow.git;protocol=https;destsuffix=git;name=glow \
+           file://0001-Fix-path-and-dependencies-to-intermediate-executable.patch  \
+           git://github.com/stp/OutputCheck.git;protocol=https;destsuffix=git/tests/OutputCheck;name=outcheck \
+           git://github.com/google/benchmark.git;protocol=https;destsuffix=git/tests/googlebenchmark;name=gbench \
+           git://github.com/google/googletest.git;protocol=https;destsuffix=git/tests/googletest;name=gtest \
+           git://github.com/houseroad/foxi.git;protocol=https;destsuffix=git/thirdparty/foxi;name=foxi \
+           git://github.com/Maratyszcza/FP16.git;protocol=https;destsuffix=git/thirdparty/fp16;name=fp16 \
+           git://github.com/onnx/onnx.git;protocol=https;destsuffix=git/thirdparty/onnx;name=onnx \
+           git://github.com/google/benchmark.git;protocol=https;destsuffix=git/thirdparty/onnx/third_party/benchmark;name=onnxbench \
+           git://github.com/pybind/pybind11.git;protocol=https;destsuffix=git/thirdparty/onnx/third_party/pybind11;name=onnxpybind11 \
+           git://github.com/wjakob/clang-cindex-python3.git;protocol=https;destsuffix=git/thirdparty/onnx/third_party/pybind11/tools/clang;name=onnxclang \
+          "
+
+SRCREV_glow = "ba8061367aea0b472b596448018107ca6e87929e"
+SRCREV_outcheck = "eab62a5dd5129f6a4ebfbe4bbe41d35611f7c48d"
+SRCREV_gbench = "090faecb454fbd6e6e17a75ef8146acb037118d4"
+SRCREV_gtest = "0c799d0436e1b6d867c1738f6ff58166d153cacc"
+SRCREV_foxi = "b2ec1a8041879b7be98d81387a14cae895f952f4"
+SRCREV_fp16 = "34d4bf01bbf7376f2baa71b8fa148b18524d45cf"
+SRCREV_onnx = "50dc186b50ea512d6888aa1f47414150fd782fa0"
+SRCREV_onnxbench = "e776aa0275e293707b6a0901e0e8d8a8a3679508"
+SRCREV_onnxpybind11 = "a1041190c8b8ff0cd9e2f0752248ad5e3789ea0c"
+SRCREV_onnxclang = "6a00cbc4a9b8e68b71caf7f774b3f9c753ae84d5"
+
+S = "${WORKDIR}/git"
+
+inherit pkgconfig cmake
+
+EXTRA_OECMAKE += " -DCMAKE_BUILD_TYPE=Release -DCMAKE_EXE_LINKER_FLAGS="-Wl,-dynamic-linker=/lib64/ld-linux-x86-64.so.2 " "
+
+do_compile() {
+   cmake_runcmake_build --target ${OECMAKE_TARGET_COMPILE}
+}
+
+do_install () {
+   install -d ${D}${datadir}/glow
+   install -d ${D}${datadir}/glow/tests/images
+   cp -Prf --preserve=mode,timestamps  ${WORKDIR}/build/bin ${D}${datadir}/glow
+   cp -Prf --preserve=mode,timestamps  ${WORKDIR}/build/tests/images/EmotionSampleImages ${D}${datadir}/glow/tests/images
+   cp -Prf --preserve=mode,timestamps  ${WORKDIR}/build/tests/images/imagenet ${D}${datadir}/glow/tests/images
+   cp -Prf --preserve=mode,timestamps  ${WORKDIR}/build/tests/images/imagenet_299 ${D}${datadir}/glow/tests/images
+   cp -Prf --preserve=mode,timestamps  ${WORKDIR}/build/tests/images/mnist ${D}${datadir}/glow/tests/images
+   cp -Prf --preserve=mode,timestamps  ${WORKDIR}/build/tests/images/other ${D}${datadir}/glow/tests/images
+}
+
+BBCLASSEXTEND = "native nativesdk"
+
+FILES_${PN} = "${datadir}"
diff --git a/meta-arago-extras/recipes-devtools/glow/llvm-glow_git.bb b/meta-arago-extras/recipes-devtools/glow/llvm-glow_git.bb
new file mode 100644
index 00000000..58d392b3
--- /dev/null
+++ b/meta-arago-extras/recipes-devtools/glow/llvm-glow_git.bb
@@ -0,0 +1,24 @@
+DESCRIPTION = "LLVM release suggested for pytorch glow neural network compiler"
+HOMEPAGE = "https://github.com/llvm-mirror/llvm"
+SECTION = "devel"
+LICENSE = "Apache-2.0"
+LIC_FILES_CHKSUM = "file://LICENSE.TXT;md5=c6b766a4e85dd28301eeed54a6684648"
+PV = "8.0"
+PR = "r0"
+
+DEPENDS = "ninja-native protobuf-native libpng-native protobuf-native protobuf-c-native gflags-native glog-native"
+
+SOLIBVER = "1"
+
+SRC_URI = "git://github.com/llvm-mirror/llvm.git;protocol=https;branch=release_80;rev=5563a6a769b48912b9c8052124520610966eda28;destsuffix=git/llvm \
+           git://github.com/llvm-mirror/clang.git;protocol=https;branch=release_80;rev=ccfe04576c13497b9c422ceef0b6efe99077a392;destsuffix=git/clang \
+           "
+
+
+S = "${WORKDIR}/git/llvm"
+
+EXTRA_OECMAKE = "-DCMAKE_BUILD_TYPE=Release -DLLVM_INSTALL_UTILS=ON -DLLVM_ENABLE_PROJECTS=clang"
+
+inherit pkgconfig cmake
+
+BBCLASSEXTEND = "native nativesdk"
diff --git a/meta-arago-extras/recipes-support/glog/glog_0.3.5.bbappend b/meta-arago-extras/recipes-support/glog/glog_0.3.5.bbappend
new file mode 100644
index 00000000..5e64501c
--- /dev/null
+++ b/meta-arago-extras/recipes-support/glog/glog_0.3.5.bbappend
@@ -0,0 +1,3 @@
+PR_append = ".arago0"
+
+BBCLASSEXTEND += "native nativesdk"
diff --git a/meta-arago-extras/recipes-support/libunwind/libunwind_1.2.1.bbappend b/meta-arago-extras/recipes-support/libunwind/libunwind_1.2.1.bbappend
new file mode 100644
index 00000000..4ad6ebc2
--- /dev/null
+++ b/meta-arago-extras/recipes-support/libunwind/libunwind_1.2.1.bbappend
@@ -0,0 +1,3 @@
+PR_append = ".arago0"
+
+BBCLASSEXTEND += "native nativesdk" 
-- 
2.17.1



^ permalink raw reply related

* [PATCH] ARM: multi_v7_defconfig: enable MMP2 platform
From: Lubomir Rintel @ 2019-06-20 11:48 UTC (permalink / raw)
  To: Olof Johansson
  Cc: Lubomir Rintel, Russell King, linux-arm-kernel, linux-kernel

Marvell MMP/PXA/MMP2 platforms seem to be excluded from the defconfig
for no good reasons. Enable the DT-based boards and the modules for
their peripherals.

Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
---
 arch/arm/configs/multi_v7_defconfig | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 6b748f214eae..ef91f41bd48a 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -51,6 +51,8 @@ CONFIG_ARCH_MEDIATEK=y
 CONFIG_ARCH_MESON=y
 CONFIG_ARCH_MILBEAUT=y
 CONFIG_ARCH_MILBEAUT_M10V=y
+CONFIG_ARCH_MMP=y
+CONFIG_MACH_MMP2_DT=y
 CONFIG_ARCH_MVEBU=y
 CONFIG_MACH_ARMADA_370=y
 CONFIG_MACH_ARMADA_375=y
@@ -278,6 +280,7 @@ CONFIG_INPUT_EVDEV=y
 CONFIG_KEYBOARD_QT1070=m
 CONFIG_KEYBOARD_GPIO=y
 CONFIG_KEYBOARD_TEGRA=y
+CONFIG_KEYBOARD_PXA27x=m
 CONFIG_KEYBOARD_SAMSUNG=m
 CONFIG_KEYBOARD_ST_KEYSCAN=y
 CONFIG_KEYBOARD_SPEAR=y
@@ -312,6 +315,7 @@ CONFIG_SERIAL_8250_EM=y
 CONFIG_SERIAL_8250_OMAP=y
 CONFIG_SERIAL_8250_MT6577=y
 CONFIG_SERIAL_8250_UNIPHIER=y
+CONFIG_SERIAL_8250_PXA=m
 CONFIG_SERIAL_OF_PLATFORM=y
 CONFIG_SERIAL_AMBA_PL011=y
 CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
@@ -589,6 +593,7 @@ CONFIG_VIDEO_V4L2_SUBDEV_API=y
 CONFIG_MEDIA_USB_SUPPORT=y
 CONFIG_USB_VIDEO_CLASS=m
 CONFIG_V4L_PLATFORM_DRIVERS=y
+CONFIG_VIDEO_MMP_CAMERA=m
 CONFIG_VIDEO_STM32_DCMI=m
 CONFIG_VIDEO_SAMSUNG_EXYNOS4_IS=m
 CONFIG_VIDEO_S5P_FIMC=m
@@ -681,6 +686,9 @@ CONFIG_SND_ATMEL_SOC_PDMIC=m
 CONFIG_SND_ATMEL_SOC_I2S=m
 CONFIG_SND_BCM2835_SOC_I2S=m
 CONFIG_SND_SOC_FSL_SAI=m
+CONFIG_SND_MMP_SOC=y
+CONFIG_SND_PXA_SOC_SSP=m
+CONFIG_SND_PXA910_SOC=m
 CONFIG_SND_SOC_ROCKCHIP=m
 CONFIG_SND_SOC_ROCKCHIP_SPDIF=m
 CONFIG_SND_SOC_ROCKCHIP_MAX98090=m
@@ -719,6 +727,7 @@ CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_EHCI_HCD_STI=y
 CONFIG_USB_EHCI_TEGRA=y
 CONFIG_USB_EHCI_EXYNOS=y
+CONFIG_USB_EHCI_MV=m
 CONFIG_USB_OHCI_HCD=y
 CONFIG_USB_OHCI_HCD_STI=y
 CONFIG_USB_OHCI_EXYNOS=m
@@ -788,6 +797,7 @@ CONFIG_MMC_SDHCI_DOVE=y
 CONFIG_MMC_SDHCI_TEGRA=y
 CONFIG_MMC_SDHCI_S3C=y
 CONFIG_MMC_SDHCI_PXAV3=y
+CONFIG_MMC_SDHCI_PXAV2=m
 CONFIG_MMC_SDHCI_SPEAR=y
 CONFIG_MMC_SDHCI_S3C_DMA=y
 CONFIG_MMC_SDHCI_BCM_KONA=y
@@ -853,6 +863,7 @@ CONFIG_RTC_DRV_DA9063=m
 CONFIG_RTC_DRV_EFI=m
 CONFIG_RTC_DRV_DIGICOLOR=m
 CONFIG_RTC_DRV_S3C=m
+CONFIG_RTC_DRV_SA1100=m
 CONFIG_RTC_DRV_PL031=y
 CONFIG_RTC_DRV_AT91RM9200=m
 CONFIG_RTC_DRV_AT91SAM9=m
-- 
2.21.0


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

^ permalink raw reply related

* [PATCH] ARM: multi_v7_defconfig: enable MMP2 platform
From: Lubomir Rintel @ 2019-06-20 11:48 UTC (permalink / raw)
  To: Olof Johansson
  Cc: Russell King, linux-arm-kernel, linux-kernel, Lubomir Rintel

Marvell MMP/PXA/MMP2 platforms seem to be excluded from the defconfig
for no good reasons. Enable the DT-based boards and the modules for
their peripherals.

Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
---
 arch/arm/configs/multi_v7_defconfig | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 6b748f214eae..ef91f41bd48a 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -51,6 +51,8 @@ CONFIG_ARCH_MEDIATEK=y
 CONFIG_ARCH_MESON=y
 CONFIG_ARCH_MILBEAUT=y
 CONFIG_ARCH_MILBEAUT_M10V=y
+CONFIG_ARCH_MMP=y
+CONFIG_MACH_MMP2_DT=y
 CONFIG_ARCH_MVEBU=y
 CONFIG_MACH_ARMADA_370=y
 CONFIG_MACH_ARMADA_375=y
@@ -278,6 +280,7 @@ CONFIG_INPUT_EVDEV=y
 CONFIG_KEYBOARD_QT1070=m
 CONFIG_KEYBOARD_GPIO=y
 CONFIG_KEYBOARD_TEGRA=y
+CONFIG_KEYBOARD_PXA27x=m
 CONFIG_KEYBOARD_SAMSUNG=m
 CONFIG_KEYBOARD_ST_KEYSCAN=y
 CONFIG_KEYBOARD_SPEAR=y
@@ -312,6 +315,7 @@ CONFIG_SERIAL_8250_EM=y
 CONFIG_SERIAL_8250_OMAP=y
 CONFIG_SERIAL_8250_MT6577=y
 CONFIG_SERIAL_8250_UNIPHIER=y
+CONFIG_SERIAL_8250_PXA=m
 CONFIG_SERIAL_OF_PLATFORM=y
 CONFIG_SERIAL_AMBA_PL011=y
 CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
@@ -589,6 +593,7 @@ CONFIG_VIDEO_V4L2_SUBDEV_API=y
 CONFIG_MEDIA_USB_SUPPORT=y
 CONFIG_USB_VIDEO_CLASS=m
 CONFIG_V4L_PLATFORM_DRIVERS=y
+CONFIG_VIDEO_MMP_CAMERA=m
 CONFIG_VIDEO_STM32_DCMI=m
 CONFIG_VIDEO_SAMSUNG_EXYNOS4_IS=m
 CONFIG_VIDEO_S5P_FIMC=m
@@ -681,6 +686,9 @@ CONFIG_SND_ATMEL_SOC_PDMIC=m
 CONFIG_SND_ATMEL_SOC_I2S=m
 CONFIG_SND_BCM2835_SOC_I2S=m
 CONFIG_SND_SOC_FSL_SAI=m
+CONFIG_SND_MMP_SOC=y
+CONFIG_SND_PXA_SOC_SSP=m
+CONFIG_SND_PXA910_SOC=m
 CONFIG_SND_SOC_ROCKCHIP=m
 CONFIG_SND_SOC_ROCKCHIP_SPDIF=m
 CONFIG_SND_SOC_ROCKCHIP_MAX98090=m
@@ -719,6 +727,7 @@ CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_EHCI_HCD_STI=y
 CONFIG_USB_EHCI_TEGRA=y
 CONFIG_USB_EHCI_EXYNOS=y
+CONFIG_USB_EHCI_MV=m
 CONFIG_USB_OHCI_HCD=y
 CONFIG_USB_OHCI_HCD_STI=y
 CONFIG_USB_OHCI_EXYNOS=m
@@ -788,6 +797,7 @@ CONFIG_MMC_SDHCI_DOVE=y
 CONFIG_MMC_SDHCI_TEGRA=y
 CONFIG_MMC_SDHCI_S3C=y
 CONFIG_MMC_SDHCI_PXAV3=y
+CONFIG_MMC_SDHCI_PXAV2=m
 CONFIG_MMC_SDHCI_SPEAR=y
 CONFIG_MMC_SDHCI_S3C_DMA=y
 CONFIG_MMC_SDHCI_BCM_KONA=y
@@ -853,6 +863,7 @@ CONFIG_RTC_DRV_DA9063=m
 CONFIG_RTC_DRV_EFI=m
 CONFIG_RTC_DRV_DIGICOLOR=m
 CONFIG_RTC_DRV_S3C=m
+CONFIG_RTC_DRV_SA1100=m
 CONFIG_RTC_DRV_PL031=y
 CONFIG_RTC_DRV_AT91RM9200=m
 CONFIG_RTC_DRV_AT91SAM9=m
-- 
2.21.0


^ permalink raw reply related

* Re: switch the remaining architectures to use generic GUP v3
From: Christoph Hellwig @ 2019-06-20 11:45 UTC (permalink / raw)
  To: Linus Torvalds, Andrew Morton, Paul Burton, James Hogan,
	Yoshinori Sato, Rich Felker, David S. Miller
  Cc: linux-sh, Andrey Konovalov, x86, linux-mips, Nicholas Piggin,
	linux-kernel, linux-mm, Khalid Aziz, Paul Mackerras, sparclinux,
	linuxppc-dev
In-Reply-To: <20190611144102.8848-1-hch@lst.de>

I just noticed I didn't have Andrew explicitly on the receipents
list, so adding him.

Is everyone happy enough to give this a spin in -mm and linux-next?

^ permalink raw reply

* [PATCH v2] dt-bindings: phy-pxa-usb: add bindings
From: Lubomir Rintel @ 2019-06-20 11:46 UTC (permalink / raw)
  To: Kishon Vijay Abraham I
  Cc: Rob Herring, Mark Rutland, linux-kernel, devicetree,
	Lubomir Rintel, Pavel Machek

This is the PHY chip for USB OTG on PXA platforms.

Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Acked-by: Pavel Machek <pavel@ucw.cz>

---
This remained unapplied, despite the driver being in already.

Changes since v1:
- Cosmetic and wording fixes

 .../devicetree/bindings/phy/phy-pxa-usb.txt    | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/phy-pxa-usb.txt

diff --git a/Documentation/devicetree/bindings/phy/phy-pxa-usb.txt b/Documentation/devicetree/bindings/phy/phy-pxa-usb.txt
new file mode 100644
index 000000000000..93fc09c12954
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-pxa-usb.txt
@@ -0,0 +1,18 @@
+Marvell PXA USB PHY
+-------------------
+
+Required properties:
+- compatible: one of: "marvell,mmp2-usb-phy", "marvell,pxa910-usb-phy",
+	"marvell,pxa168-usb-phy",
+- #phy-cells: must be 0
+
+Example:
+	usb-phy: usbphy@d4207000 {
+		compatible = "marvell,mmp2-usb-phy";
+		reg = <0xd4207000 0x40>;
+		#phy-cells = <0>;
+		status = "okay";
+	};
+
+This document explains the device tree binding. For general
+information about PHY subsystem refer to Documentation/phy.txt
-- 
2.21.0

^ permalink raw reply related

* [dpdk-dev] Your Bugzilla bug list needs attention.
From: bugzilla @ 2019-06-20 11:45 UTC (permalink / raw)
  To: dev

[This e-mail has been automatically generated.]

You have one or more bugs assigned to you in the Bugzilla bug tracking system (http://dpdk.space:8000/) that require
attention.

All of these bugs are in the CONFIRMED
state, and have not been touched in 7 days or more.
You need to take a look at them, and decide on an initial action.

Generally, this means one of three things:

(1) You decide this bug is really quick to deal with (like, it's INVALID),
    and so you get rid of it immediately.
(2) You decide the bug doesn't belong to you, and you reassign it to
    someone else. (Hint: if you don't know who to reassign it to, make
    sure that the Component field seems reasonable, and then use the
    "Reset Assignee to default" option.)
(3) You decide the bug belongs to you, but you can't solve it this moment.
    Accept the bug by setting the status to IN_PROGRESS.

To get a list of all CONFIRMED bugs, you can use this URL (bookmark
it if you like!):
http://dpdk.space:8000/buglist.cgi?bug_status=CONFIRMED&assigned_to=dev@dpdk.org

Or, you can use the general query page, at 
http://dpdk.space:8000/query.cgi

Appended below are the individual URLs to get to all of your CONFIRMED bugs
that haven't been touched for 7 days or more.

You will get this message once a day until you've dealt with these bugs!

 Green goal: power efficiency with all hardwares
    -> http://dpdk.space:8000/show_bug.cgi?id=1
 dpdk-pdump leads to ovs-vswitchd crash
    -> http://dpdk.space:8000/show_bug.cgi?id=6
 Kernel crash after "Detected Tx Unit Hang" report
    -> http://dpdk.space:8000/show_bug.cgi?id=15
 Does not cross-compile: buildtools/check-experimental-syms.sh assumes `objdump`
    -> http://dpdk.space:8000/show_bug.cgi?id=32
 "rte_eth_tx_queue_setup" will be failed if argument "tx_conf" not specified
    -> http://dpdk.space:8000/show_bug.cgi?id=43
 Reciprocal division: Fail [Crash]
    -> http://dpdk.space:8000/show_bug.cgi?id=46
 For RSS flow actions, e1000_ethdev.h uses IGB_MAX_RX_QUEUE_NUM instead of IGB_MAX_RX_QUEUE_NUM_82576
    -> http://dpdk.space:8000/show_bug.cgi?id=83
 rte_memcpy() moves data incorrectly on Ubuntu 18.04 on Intel Skylake
    -> http://dpdk.space:8000/show_bug.cgi?id=97
 axgbe driver does not support 1G Copper 1000BASE-T SFPs (Unsupported AN_CL37)
    -> http://dpdk.space:8000/show_bug.cgi?id=99
 Cannot create crypto_openssl after vdev_uninit
    -> http://dpdk.space:8000/show_bug.cgi?id=105
 pktgen -s option send pcap traffic once
    -> http://dpdk.space:8000/show_bug.cgi?id=113
 rte_rand() is not thread-safe but not documented as such
    -> http://dpdk.space:8000/show_bug.cgi?id=114
 conflicting information for 'Running DPDK Applications Without Root Privileges'
    -> http://dpdk.space:8000/show_bug.cgi?id=118
 configure rx queue for JUMBO frame returns warning as offload is 0x0, but eth_pcap_rx_jumbo is present
    -> http://dpdk.space:8000/show_bug.cgi?id=164
 DPDK on Azure using `intel-go/nff-go` fails using `hv_netvsc` driver
    -> http://dpdk.space:8000/show_bug.cgi?id=175
 secondary process cannot execute  iommu
    -> http://dpdk.space:8000/show_bug.cgi?id=176
 Problem using cloned rte_mbuf buffers with KNI interface
    -> http://dpdk.space:8000/show_bug.cgi?id=183
 PVP zero-loss performance degradation without --legacy-mem
    -> http://dpdk.space:8000/show_bug.cgi?id=185
 Merge linux and bsd eal_thread.c which are same
    -> http://dpdk.space:8000/show_bug.cgi?id=187
 ethdev API for firmware version request is not tested
    -> http://dpdk.space:8000/show_bug.cgi?id=225
 Flow control mode on mac Intel Corporation I350 Gigabit Network Connection (rev 01) issues
    -> http://dpdk.space:8000/show_bug.cgi?id=227
 Running test-build.sh Fails on ppc_64 fails due to hard-coded requirement for IXGBE_PMD in examples/vm_power_manager
    -> http://dpdk.space:8000/show_bug.cgi?id=237
 [tree-wide] enhance getopt_long usage
    -> http://dpdk.space:8000/show_bug.cgi?id=238
 ipsec-secgw fails to initialize when librte_ipsec is enabled
    -> http://dpdk.space:8000/show_bug.cgi?id=239
 QEMU (vIOMMU+virtio) crashes when DPDK exits
    -> http://dpdk.space:8000/show_bug.cgi?id=241
 Unable to run DPDK test with "make test" command
    -> http://dpdk.space:8000/show_bug.cgi?id=253
 Tap driver unnecessarily triggers timeout on failure
    -> http://dpdk.space:8000/show_bug.cgi?id=258
 Unaligned memory access when reading ipv6 header
    -> http://dpdk.space:8000/show_bug.cgi?id=279
 X710 PF Reset Issue with DPDK VF Driver
    -> http://dpdk.space:8000/show_bug.cgi?id=280
 Fix missing headers in FreeBSD CURRENT build
    -> http://dpdk.space:8000/show_bug.cgi?id=282
 BPF: array ins_chk is missing an entry
    -> http://dpdk.space:8000/show_bug.cgi?id=283
 netvsc PMD/dpdk/azure: Driver lockup with multi-queue configuration
    -> http://dpdk.space:8000/show_bug.cgi?id=287
 Target name recorded wrong when try to build dpdk with x86_64-native-linux-gcc
    -> http://dpdk.space:8000/show_bug.cgi?id=288
 mlx5: 100G interface capability not recognized
    -> http://dpdk.space:8000/show_bug.cgi?id=289
 FM10K dpdk driver - memory leak with KNI interface - interface up/down
    -> http://dpdk.space:8000/show_bug.cgi?id=291

^ permalink raw reply

* Re: switch the remaining architectures to use generic GUP v3
From: Christoph Hellwig @ 2019-06-20 11:45 UTC (permalink / raw)
  To: Linus Torvalds, Andrew Morton, Paul Burton, James Hogan,
	Yoshinori Sato, Rich Felker, David S. Miller
  Cc: Nicholas Piggin, Khalid Aziz, Andrey Konovalov,
	Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
	linux-mips, linux-sh, sparclinux, linuxppc-dev, linux-mm, x86,
	linux-kernel
In-Reply-To: <20190611144102.8848-1-hch@lst.de>

I just noticed I didn't have Andrew explicitly on the receipents
list, so adding him.

Is everyone happy enough to give this a spin in -mm and linux-next?

^ permalink raw reply

* Re: switch the remaining architectures to use generic GUP v3
From: Christoph Hellwig @ 2019-06-20 11:45 UTC (permalink / raw)
  To: Linus Torvalds, Andrew Morton, Paul Burton, James Hogan,
	Yoshinori Sato, Rich Felker, David S. Miller
  Cc: Nicholas Piggin, Khalid Aziz, Andrey Konovalov,
	Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
	linux-mips, linux-sh, sparclinux, linuxppc-dev, linux-mm, x86,
	linux-kernel
In-Reply-To: <20190611144102.8848-1-hch@lst.de>

I just noticed I didn't have Andrew explicitly on the receipents
list, so adding him.

Is everyone happy enough to give this a spin in -mm and linux-next?

^ permalink raw reply

* [PATCH] hdpvr: fix locking and a missing msleep
From: Hans Verkuil @ 2019-06-20 11:43 UTC (permalink / raw)
  To: Linux Media Mailing List; +Cc: Keith Pyle

This driver has three locking issues:

- The wait_event_interruptible() condition calls hdpvr_get_next_buffer(dev)
  which uses a mutex, which is not allowed. Rewrite with list_empty_careful()
  that doesn't need locking.

- In hdpvr_read() the call to hdpvr_stop_streaming() didn't lock io_mutex,
  but it should have since stop_streaming expects that.

- In hdpvr_device_release() io_mutex was locked when calling flush_work(),
  but there it shouldn't take that mutex since the work done by flush_work()
  also wants to lock that mutex.

There are also two other changes (suggested by Keith):

- msecs_to_jiffies(4000); (a NOP) should have been msleep(4000).
- Change v4l2_dbg to v4l2_info to always log if streaming had to be restarted.

Reported-by: Keith Pyle <kpyle@austin.rr.com>
Suggested-by: Keith Pyle <kpyle@austin.rr.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
---
diff --git a/drivers/media/usb/hdpvr/hdpvr-video.c b/drivers/media/usb/hdpvr/hdpvr-video.c
index 3786ddcc0d18..5b3e67b80627 100644
--- a/drivers/media/usb/hdpvr/hdpvr-video.c
+++ b/drivers/media/usb/hdpvr/hdpvr-video.c
@@ -435,7 +435,7 @@ static ssize_t hdpvr_read(struct file *file, char __user *buffer, size_t count,
 	/* wait for the first buffer */
 	if (!(file->f_flags & O_NONBLOCK)) {
 		if (wait_event_interruptible(dev->wait_data,
-					     hdpvr_get_next_buffer(dev)))
+					     !list_empty_careful(&dev->rec_buff_list)))
 			return -ERESTARTSYS;
 	}

@@ -461,10 +461,17 @@ static ssize_t hdpvr_read(struct file *file, char __user *buffer, size_t count,
 				goto err;
 			}
 			if (!err) {
-				v4l2_dbg(MSG_INFO, hdpvr_debug, &dev->v4l2_dev,
-					"timeout: restart streaming\n");
+				v4l2_info(&dev->v4l2_dev,
+					  "timeout: restart streaming\n");
+				mutex_lock(&dev->io_mutex);
 				hdpvr_stop_streaming(dev);
-				msecs_to_jiffies(4000);
+				mutex_unlock(&dev->io_mutex);
+				/*
+				 * The FW needs about 4 seconds after streaming
+				 * stopped before it is ready to restart
+				 * streaming.
+				 */
+				msleep(4000);
 				err = hdpvr_start_streaming(dev);
 				if (err) {
 					ret = err;
@@ -1124,9 +1131,7 @@ static void hdpvr_device_release(struct video_device *vdev)
 	struct hdpvr_device *dev = video_get_drvdata(vdev);

 	hdpvr_delete(dev);
-	mutex_lock(&dev->io_mutex);
 	flush_work(&dev->worker);
-	mutex_unlock(&dev->io_mutex);

 	v4l2_device_unregister(&dev->v4l2_dev);
 	v4l2_ctrl_handler_free(&dev->hdl);

^ permalink raw reply related

* Re: [GSoC][PATCH v5 4/5] cherry-pick/revert: add --skip option
From: Phillip Wood @ 2019-06-20 11:42 UTC (permalink / raw)
  To: Rohit Ashiwal
  Cc: git, gitster, jrnieder, martin.agren, newren, phillip.wood,
	t.gummerer
In-Reply-To: <20190620103401.29654-1-rohit.ashiwal265@gmail.com>

Hi Rohit

On 20/06/2019 11:34, Rohit Ashiwal wrote:
> Hi Phillip
> 
> On 2019-06-20 10:02 UTC Phillip Wood <phillip.wood123@gmail.com> wrote:
>>
>>> +test_expect_success 'allow skipping stopped cherry-pick because of untracked file modifications' '
>>> +	pristine_detach initial &&
>>> +	git rm --cached unrelated &&
>>> +	git commit -m "untrack unrelated" &&
>>> +	test_must_fail git cherry-pick initial base &&
>>> +	test_path_is_missing .git/CHERRY_PICK_HEAD &&
>>> +	git cherry-pick --skip
>>
>> If you change this to --continue rather than --skip the test also
>> passes! I think we could fix this by checking if HEAD has changed if
>> CHERRY_PICK_HEAD/REVERT_HEAD is missing and not dropping the last
>> command in the todo list in that case when we continue.
> 
> I don't think I fully understood this. At this point --skip is essentially
> --continue. How is checking unmoved HEAD and unchanged todo uniquely related
> to --skip flag (or for that matter any _flag_)?

My point is that --continue should reschedule the failed pick and try to 
pick it again - it should not silently skip a failed pick and  --skip 
should skip it.

Best Wishes

Phillip
> 
> Thanks
> Rohit
> 

^ permalink raw reply

* Re: [PATCH v6 5/7] [media] marvell-ccic/mmp: add devicetree support
From: Jacopo Mondi @ 2019-06-20 11:43 UTC (permalink / raw)
  To: Lubomir Rintel
  Cc: Sakari Ailus, Mauro Carvalho Chehab, Jonathan Corbet, linux-media,
	linux-kernel, Pavel Machek
In-Reply-To: <26d8ac51ff8c454a357028f267efd0d4cdd0ea84.camel@v3.sk>

[-- Attachment #1: Type: text/plain, Size: 819 bytes --]

Hi Lubomir, Sakari,

On Thu, Jun 20, 2019 at 01:37:53PM +0200, Lubomir Rintel wrote:
> On Thu, 2019-06-20 at 14:35 +0300, Sakari Ailus wrote:
> > Ping?
> >
> > Lubomir: I'm applying the set now, but please addres Jacopo's comment.
> > Thanks.
>
> Hi, I'm wondering if you could wait a couple of minutes?
>
> I've tested the patch set on my machine last night and I was about to
> submit the updated set just now.
>
> Alternatively, I can just address Jacopo's comment with a patch that
> applies on top of the set, but it would make slightly more sense if it
> came earlier.

Indeed, sorry for the late review. I also commented on patches which
are already in, so please consider if you would like to address issues
on top.

It's minor stuff though, nothing that seems a blocker to me.

Thanks
   j
>
> Thanks
> Lubo
>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply

* Re: [PATCH v1 5/5] coresight: etm4x: save/restore state across CPU low power states
From: Andrew Murray @ 2019-06-20 11:41 UTC (permalink / raw)
  To: Mathieu Poirier
  Cc: Al Grant, Suzuki K Poulose, Alexander Shishkin, Sudeep Holla,
	linux-arm-kernel, Mike Leach
In-Reply-To: <CANLsYkw-KhMVgTfyBSF4-uv4wxQBBQfzyvVbAnaFSqHhkgX6Mg@mail.gmail.com>

On Wed, Jun 19, 2019 at 10:22:58AM -0600, Mathieu Poirier wrote:
> On Wed, 19 Jun 2019 at 05:07, Sudeep Holla <sudeep.holla@arm.com> wrote:
> >
> > On Wed, Jun 19, 2019 at 11:38:12AM +0100, Suzuki K Poulose wrote:
> > > Cc: Al Grant, Mike Leach
> > >
> > > Hi Sudeep,
> > >
> > > On 18/06/2019 14:21, Sudeep Holla wrote:
> > > > On Tue, Jun 18, 2019 at 01:54:33PM +0100, Andrew Murray wrote:
> > > > > Some hardware will ignore bit TRCPDCR.PU which is used to signal
> > > > > to hardware that power should not be removed from the trace unit.
> > > >
> > > > So, how or can we identify or discover such system ? DT/ACPI ?
> > > >
> > >
> > > I don't think there is a mechanism at the moment to identify such
> > > systems. But if we really need to know this information, we could
> > > always think about it.
> > >
> >
> > I prefer that as we shouldn't systems that are not broken.
> >
> > > > > Let's mitigate against this by saving and restoring the trace
> > > > > unit state when the CPU enters low power states.
> > > > >
> > > >
> > > > I prefer to do this conditionally. It's unnecessary on systems which
> > > > don't ignore the TRCPDCR.PU and I really don't like them to be penalised
> > > > while we want to add this support for *broken* systems.
> > >
> > > It is conditional. i.e, you may disable the operation using a kernel/module
> > > parameter, which I think should be mentioned in the description here.
> > >
> >
> > Why should the user of coresight need to know if the corresponding
> > hardware module is broken or not. I prefer the firmware tell OS.
> 
> I think using ACPI/DT is the best and simplest solution.

I certainly agree that it feels wrong to have a default level of support
which is targeted at broken systems. However the penalty (latency) for doing so
doesn't seem high - seeing as this only effects users that are actively using
coresight (I assume self hosted mode is only used as a debug tool, rather than to
obtain metrics during normal use?).

Adding some broken tag in ACPI/DT seems like a good solution - assuming it will
get adopted and used in systems. The existing "disable_pm_save" module option
can be renamed to "enable_pm_save" for those that have less control of their
firmware.

Unless of course we think it's unlikely we'll ever see hardware that isn't
broken - I don't have enough knowledge of how likely or not this is.

Another solution might be to enable save/restore by default (as it is now),
and then on resume we read the hardware registers to determine if state was
lost. If it wasn't lost then we can disable the save/restore feature. (Though
is it possible for systems to be partly broken, e.g. working for some CPUs
but not others?). With this approach on good systems you only get penalised
once.

> 
> >
> > > >
> > > > This is generally most useful to debug CPU suspend/resume exercising
> > > > the code path completely with emulated CPU power on/off as most of the
> > > > systems have the trace unit and the CPUs in the same power domain.
> > >
> > > I understand, which is specifically why this comes with an option to handle
> > > such cases.
> > >
> >
> > OK

I'll update the cover letter and commit messages to reflect that this
option is present. (And likewise for conditionally saving/restoring the
registers only if coresight is in use).

> >
> > > >
> > > > Just curious if this reported on any platforms ?
> > > >
> > >
> > > I have heard people complaining about this, but not sure about the exact
> > > platform(s) affected.
> 
> Are you referring to platforms that ignore the TRCPDCR.PU bit?  If so
> Juno is the only one that does _not_ ignore it, hence the need to find
> another solution.
> 
> > >
> >
> > One we add mechanism in place, platform need to advertise that it's
> > broken in firmware(DT/ACPI). Or just have a blacklist if we don't
> > want to add anything extra to the firmware(DT/ACPI) ?
> >
> > > > I wounder if we can use TRCPDSR(Power Down Status Register) to check the
> > > > status. I know on Juno, it doesn't loose context rather the power down
> > > > is emulated and saving/restoring may not be needed at all. Have you
> > > > tested on Juno with and without these patches and seen any difference ?
> > >
> > > The problem is trace unit looses power the moment CPU goes to low power mode
> > > and if we try to read this register, it could cause unexpected side-effects.
> > >
> >
> > No I meant before CPU loose power i.e. in CPU_ENTER case. However I do
> > remember you/Andrew mentioning that even that may be bogus on broken
> > systems, so firmware is only way to avoid penalising all platforms IMO.
> 
> I wouldn't assume that anything is working properly.

Thanks,

Andrew Murray

> 
> >
> > Or other option is to stop the coresight tracing session like we do
> > for PMUs or not entering idle when there's any active coresight session
> > in progress on such platforms.
> >
> > --
> > Regards,
> > Sudeep

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

^ permalink raw reply

* Re: [PATCH v2 0/3] ceph: don't NULL terminate virtual xattr values
From: Jeff Layton @ 2019-06-20 11:41 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: linux-kernel, ceph-devel, idryomov, zyan, sage, agruenba, joe,
	pmladek, rostedt, geert+renesas
In-Reply-To: <20190620102410.GT9224@smile.fi.intel.com>

On Thu, 2019-06-20 at 13:24 +0300, Andy Shevchenko wrote:
> On Wed, Jun 19, 2019 at 12:45:25PM -0400, Jeff Layton wrote:
> > v2: drop bogus EXPORT_SYMBOL of static function
> > 
> > The only real difference between this set and the one I sent originally
> > is the removal of a spurious EXPORT_SYMBOL in the snprintf patch.
> > 
> > I'm mostly sending this with a wider cc list in an effort to get a
> > review from the maintainers of the printf code. Basically ceph needs a
> > snprintf variant that does not NULL terminate in order to handle its
> > virtual xattrs.
> > 
> > Joe Perches had expressed some concerns about stack usage in vsnprintf
> > with this, but I'm not sure I really understand the basis of that
> > concern. If it is problematic, then I could use suggestions as to how
> > best to fix that up.
> 
> It might be problematic, since vsnprintf() can be called recursively.
> 

So the concern is that we'd have extra call/ret activity in the stack?
That seems like a lot of hand-wringing over very little, but ok if so.

> > ----------------------------8<-----------------------------
> > 
> > kcephfs has several "virtual" xattrs that return strings that are
> > currently populated using snprintf(), which always NULL terminates the
> > string.
> > 
> > This leads to the string being truncated when we use a buffer length
> > acquired by calling getxattr with a 0 size first. The last character
> > of the string ends up being clobbered by the termination.
> 
> So, then don't use snprintf() for this, simple memcpy() designed for that kind
> of things.
> 

memcpy from what? For many of these xattrs, we need to format integer
data into strings. I could roll my own routine to do this formatting,
but that's sort of what sprintf and its variants are for and I'd rather
not reimplement all of it from scratch.

> > The convention with xattrs is to not store the termination with string
> > data, given that we have the length. This is how setfattr/getfattr
> > operate.
> 
> Fine.
> 
> > This patch makes ceph's virtual xattrs not include NULL termination
> > when formatting their values. In order to handle this, a new
> > snprintf_noterm function is added, and ceph is changed over to use
> > this to populate the xattr value buffer.
> 
> In terms of vsnprintf(), and actually compiler point of view, it's not a string
> anymore, it's a text-based data.
> 
> Personally, I don't see an advantage of a deep intrusion into vsnprintf().
> The wrapper can be made to achieve this w/o touching the generic code. Thus,
> you can quickly and cleanly fix the issue, while discussing this with wider
> audience.
> 

Sorry, if I'm being dense but I'm not sure I follow here.

Are you suggesting I should just copy/paste most of vsnprintf into a new
function that just leaves off the termination at the end, and leave the
original alone? That seems like a bit of a waste, but if that's the
consensus then ok.

> > Finally, we fix ceph to
> > return -ERANGE properly when the string didn't fit in the buffer.
> > 
> > Jeff Layton (3):
> >   lib/vsprintf: add snprintf_noterm
> >   ceph: don't NULL terminate virtual xattr strings
> >   ceph: return -ERANGE if virtual xattr value didn't fit in buffer
> > 
> >  fs/ceph/xattr.c        |  49 +++++++-------
> >  include/linux/kernel.h |   2 +
> >  lib/vsprintf.c         | 144 ++++++++++++++++++++++++++++-------------
> >  3 files changed, 129 insertions(+), 66 deletions(-)
> > 
> > -- 
> > 2.21.0
> > 

-- 
Jeff Layton <jlayton@kernel.org>

^ permalink raw reply

* Re: [dpdk-dev] [PATCH 1/3] net: new ipv6 header extension parsing function
From: Akhil Goyal @ 2019-06-20 11:40 UTC (permalink / raw)
  To: Marcin Smoczynski, marko.kovacevic@intel.com, orika@mellanox.com,
	bruce.richardson@intel.com, pablo.de.lara.guarch@intel.com,
	radu.nicolau@intel.com, tomasz.kantecki@intel.com,
	konstantin.ananyev@intel.com, bernard.iremonger@intel.com,
	olivier.matz@6wind.com
  Cc: dev@dpdk.org
In-Reply-To: <20190508104717.13448-1-marcinx.smoczynski@intel.com>

Hi Marcin,

> 
> Introduce new function for IPv6 header extension parsing able to
> determine extension length and next protocol number.
> 
> This function is helpful when implementing IPv6 header traversing.
> 
> Signed-off-by: Marcin Smoczynski <marcinx.smoczynski@intel.com>
> ---
>  lib/librte_net/rte_ip.h | 49 +++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 49 insertions(+)
> 
> diff --git a/lib/librte_net/rte_ip.h b/lib/librte_net/rte_ip.h
> index f9b909090..be64da662 100644
> --- a/lib/librte_net/rte_ip.h
> +++ b/lib/librte_net/rte_ip.h
> @@ -425,6 +425,55 @@ rte_ipv6_udptcp_cksum(const struct ipv6_hdr
> *ipv6_hdr, const void *l4_hdr)
>  	return (uint16_t)cksum;
>  }
> 
> +/* IPv6 fragmentation header size */
> +#define RTE_IPV6_FRAG_HDR_SIZE 8
> +
> +/**
> + * Parse next IPv6 header extension
> + *
> + * This function checks if proto number is an IPv6 extensions and parses its
> + * data if so, providing information on next header and extension length.
> + *
> + * @param p
> + *   Pointer to an extension raw data.
> + * @param proto
> + *   Protocol number extracted from the "next header" field from
> + *   the IPv6 header or the previous extension.
> + * @param ext_len
> + *   Extension data length.
> + * @return
> + *   next protocol number if proto is an IPv6 extension, -EINVAL otherwise
> + */
> +static inline int __rte_experimental


Rte_experimental may not be required for inline functions.


> +rte_ipv6_get_next_ext(uint8_t *p, int proto, size_t *ext_len)
> +{
> +	int next_proto;
> +
> +	switch (proto) {
> +	case IPPROTO_AH:
> +		next_proto = *p++;
> +		*ext_len = (*p + 2) * sizeof(uint32_t);
> +		break;
> +
> +	case IPPROTO_HOPOPTS:
> +	case IPPROTO_ROUTING:
> +	case IPPROTO_DSTOPTS:
> +		next_proto = *p++;
> +		*ext_len = (*p + 1) * sizeof(uint64_t);
> +		break;
> +
> +	case IPPROTO_FRAGMENT:
I see that there is some compilation issues with respect to IPPROTO_xxx fields. These are reported in patchworks if you need details.

Could you please fix these and send next rev.

Thanks,
Akhil

^ permalink raw reply

* Re: [PATCH v6 5/7] [media] marvell-ccic/mmp: add devicetree support
From: Sakari Ailus @ 2019-06-20 11:39 UTC (permalink / raw)
  To: Lubomir Rintel
  Cc: Jacopo Mondi, Mauro Carvalho Chehab, Jonathan Corbet, linux-media,
	linux-kernel, Pavel Machek
In-Reply-To: <26d8ac51ff8c454a357028f267efd0d4cdd0ea84.camel@v3.sk>

On Thu, Jun 20, 2019 at 01:37:53PM +0200, Lubomir Rintel wrote:
> On Thu, 2019-06-20 at 14:35 +0300, Sakari Ailus wrote:
> > Ping?
> > 
> > Lubomir: I'm applying the set now, but please addres Jacopo's comment.
> > Thanks.
> 
> Hi, I'm wondering if you could wait a couple of minutes?
> 
> I've tested the patch set on my machine last night and I was about to
> submit the updated set just now.
> 
> Alternatively, I can just address Jacopo's comment with a patch that
> applies on top of the set, but it would make slightly more sense if it
> came earlier.

I applied the patches but I can always replace them with new versions ---
Mauro will cherry-pick them anyway.

-- 
Sakari Ailus

^ permalink raw reply

* [Buildroot] [PATCH 2/3] package/busybox: convert S10mdev to the canonical init script format
From: Titouan Christophe @ 2019-06-20 11:39 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <7b16986f-60ed-c07a-5399-7550354086ec@railnova.eu>

Hi again,

On 6/20/19 12:44 PM, Titouan Christophe wrote:
> Hello Andy,
> 
> On 6/20/19 12:10 PM, Andy Shevchenko wrote:
>> On Wed, Jun 19, 2019 at 06:42:56PM +0200, Titouan Christophe wrote:
>>> Signed-off-by: Titouan Christophe <titouan.christophe@railnova.eu>
>>
>>> -??? find /sys/ -name modalias -print0 | xargs -0 sort -u | tr '\n' 
>>> '\0' | \
>>> -??????? xargs -0 modprobe -abq
>>
>>> +??? find /sys/ -name modalias -print0 | \
>>> +??????? xargs -0 sort -u | \
>>> +??????? tr '\n' '\0' | \
>>> +??????? xargs -0 modprobe -abq
>>
>> How this indentation change related to the topic?
>>
> 
> This is a preparatory patch to convert this script to the canonical init 
> script format, as suggested by Arnout (see 
> http://lists.busybox.net/pipermail/buildroot/2019-May/251199.html)


sorry I did not pay attention to the fact that you were only commenting 
on this particular hunk. I did reindent this command chain for better 
readability (in my opinion); I can rework that part to better suit the 
codestyle, if any.

Regards,

Titouan

^ permalink raw reply

* Re: [PATCH nf-next] netfilter: bridge: Fix non-untagged fragment packet
From: wenxu @ 2019-06-20 11:39 UTC (permalink / raw)
  To: Pablo Neira Ayuso; +Cc: fw, netfilter-devel, netdev
In-Reply-To: <20190620104804.cbbodvw2llnt6qcl@salvia>


在 2019/6/20 18:48, Pablo Neira Ayuso 写道:
> On Wed, Jun 19, 2019 at 10:35:07PM +0800, wenxu@ucloud.cn wrote:
> [...]
>> So if the first fragment packet don't contain vlan tag, all of the
>> remain should not contain vlan tag..
> If I understand correctly, the problem is this:
>
> * First fragment comes with no vlan tag.
> * Second fragment comes with vlan tag.
>
> If you have a vlan setup, you have to use ct zone to map the vlan id
> to the corresponding ct zone.
>
> nf_ct_br_defrag4() calls:
>
>         err = ip_defrag(state->net, skb,
>                                 IP_DEFRAG_CONNTRACK_BRIDGE_IN + zone_id);
>
> if ct zones are used, first fragment will go to defrag queue
> IP_DEFRAG_CONNTRACK_BRIDGE_IN + 0, while second fragment will go to
> IP_DEFRAG_CONNTRACK_BRIDGE_IN + zone_id.
>
> So they will go to different defrag queues.
>
It's not correct.

The problem is both the first and second fragment comes with vlan tag (It's make sense).

After the defrag(in fast mode), the two skb chains to a one skb.  When the packet send to the veth1 port which with flags "untagged". So the only the first skb clear the vlan tag, but the second one also contain vlan tag.  In the refrag which also in the fast mode only split the chian skb.  So it leads the first skb with no vlan tag which is correct. But the second skb wit vlan tag which is not correct





^ permalink raw reply

* [tip:x86/cpu] x86/cpufeatures: Enumerate the new AVX512 BFLOAT16 instructions
From: tip-bot for Fenghua Yu @ 2019-06-20 11:38 UTC (permalink / raw)
  To: linux-tip-commits
  Cc: fenghua.yu, bp, robert.hu, Thomas.Lendacky, chang.seok.bae,
	pasha.tatashin, linux-kernel, tglx, frederic, mpe, mingo, hpa,
	jannh, pfeiner, rafael.j.wysocki, sean.j.christopherson, x86,
	yamada.masahiro, mingo, pbonzini, ravi.v.shankar, namit, rkrcmar
In-Reply-To: <1560794416-217638-3-git-send-email-fenghua.yu@intel.com>

Commit-ID:  b302e4b176d00e1cbc80148c5d0aee36751f7480
Gitweb:     https://git.kernel.org/tip/b302e4b176d00e1cbc80148c5d0aee36751f7480
Author:     Fenghua Yu <fenghua.yu@intel.com>
AuthorDate: Mon, 17 Jun 2019 11:00:16 -0700
Committer:  Borislav Petkov <bp@suse.de>
CommitDate: Thu, 20 Jun 2019 12:38:49 +0200

x86/cpufeatures: Enumerate the new AVX512 BFLOAT16 instructions

AVX512 BFLOAT16 instructions support 16-bit BFLOAT16 floating-point
format (BF16) for deep learning optimization.

BF16 is a short version of 32-bit single-precision floating-point
format (FP32) and has several advantages over 16-bit half-precision
floating-point format (FP16). BF16 keeps FP32 accumulation after
multiplication without loss of precision, offers more than enough
range for deep learning training tasks, and doesn't need to handle
hardware exception.

AVX512 BFLOAT16 instructions are enumerated in CPUID.7.1:EAX[bit 5]
AVX512_BF16.

CPUID.7.1:EAX contains only feature bits. Reuse the currently empty
word 12 as a pure features word to hold the feature bits including
AVX512_BF16.

Detailed information of the CPUID bit and AVX512 BFLOAT16 instructions
can be found in the latest Intel Architecture Instruction Set Extensions
and Future Features Programming Reference.

 [ bp: Check CPUID(7) subleaf validity before accessing subleaf 1. ]

Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: "Chang S. Bae" <chang.seok.bae@intel.com>
Cc: Frederic Weisbecker <frederic@kernel.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jann Horn <jannh@google.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Nadav Amit <namit@vmware.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Pavel Tatashin <pasha.tatashin@oracle.com>
Cc: Peter Feiner <pfeiner@google.com>
Cc: Radim Krcmar <rkrcmar@redhat.com>
Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
Cc: "Ravi V Shankar" <ravi.v.shankar@intel.com>
Cc: Robert Hoo <robert.hu@linux.intel.com>
Cc: "Sean J Christopherson" <sean.j.christopherson@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Thomas Lendacky <Thomas.Lendacky@amd.com>
Cc: x86 <x86@kernel.org>
Link: https://lkml.kernel.org/r/1560794416-217638-3-git-send-email-fenghua.yu@intel.com
---
 arch/x86/include/asm/cpufeature.h  | 2 +-
 arch/x86/include/asm/cpufeatures.h | 3 +++
 arch/x86/kernel/cpu/common.c       | 6 ++++++
 arch/x86/kernel/cpu/cpuid-deps.c   | 1 +
 4 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/cpufeature.h b/arch/x86/include/asm/cpufeature.h
index 403f70c2e431..58acda503817 100644
--- a/arch/x86/include/asm/cpufeature.h
+++ b/arch/x86/include/asm/cpufeature.h
@@ -23,7 +23,7 @@ enum cpuid_leafs
 	CPUID_7_0_EBX,
 	CPUID_D_1_EAX,
 	CPUID_LNX_4,
-	CPUID_DUMMY,
+	CPUID_7_1_EAX,
 	CPUID_8000_0008_EBX,
 	CPUID_6_EAX,
 	CPUID_8000_000A_EDX,
diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
index be858b86023a..8ecd9fac97c3 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -282,6 +282,9 @@
 #define X86_FEATURE_CQM_MBM_TOTAL	(11*32+ 2) /* LLC Total MBM monitoring */
 #define X86_FEATURE_CQM_MBM_LOCAL	(11*32+ 3) /* LLC Local MBM monitoring */
 
+/* Intel-defined CPU features, CPUID level 0x00000007:1 (EAX), word 12 */
+#define X86_FEATURE_AVX512_BF16		(12*32+ 5) /* AVX512 BFLOAT16 instructions */
+
 /* AMD-defined CPU features, CPUID level 0x80000008 (EBX), word 13 */
 #define X86_FEATURE_CLZERO		(13*32+ 0) /* CLZERO instruction */
 #define X86_FEATURE_IRPERF		(13*32+ 1) /* Instructions Retired Count */
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index efb114298cfb..dad20bc891d5 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -847,6 +847,12 @@ void get_cpu_cap(struct cpuinfo_x86 *c)
 		c->x86_capability[CPUID_7_0_EBX] = ebx;
 		c->x86_capability[CPUID_7_ECX] = ecx;
 		c->x86_capability[CPUID_7_EDX] = edx;
+
+		/* Check valid sub-leaf index before accessing it */
+		if (eax >= 1) {
+			cpuid_count(0x00000007, 1, &eax, &ebx, &ecx, &edx);
+			c->x86_capability[CPUID_7_1_EAX] = eax;
+		}
 	}
 
 	/* Extended state features: level 0x0000000d */
diff --git a/arch/x86/kernel/cpu/cpuid-deps.c b/arch/x86/kernel/cpu/cpuid-deps.c
index fa07a224e7b9..a444028d8145 100644
--- a/arch/x86/kernel/cpu/cpuid-deps.c
+++ b/arch/x86/kernel/cpu/cpuid-deps.c
@@ -62,6 +62,7 @@ static const struct cpuid_dep cpuid_deps[] = {
 	{ X86_FEATURE_CQM_OCCUP_LLC,	X86_FEATURE_CQM_LLC   },
 	{ X86_FEATURE_CQM_MBM_TOTAL,	X86_FEATURE_CQM_LLC   },
 	{ X86_FEATURE_CQM_MBM_LOCAL,	X86_FEATURE_CQM_LLC   },
+	{ X86_FEATURE_AVX512_BF16,	X86_FEATURE_AVX512VL  },
 	{}
 };
 

^ permalink raw reply related

* Re: [GIT PULL] KVM/arm fixes for 5.2-rc6
From: Paolo Bonzini @ 2019-06-20 11:38 UTC (permalink / raw)
  To: Marc Zyngier, Radim Krčmář
  Cc: Andrew Jones, kvm, Suzuki K Poulose, Viresh Kumar, Julien Thierry,
	kvmarm, James Morse, Dave Martin, linux-arm-kernel
In-Reply-To: <20190620112301.138137-1-marc.zyngier@arm.com>

On 20/06/19 13:22, Marc Zyngier wrote:
>   git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git tags/kvmarm-fixes-for-5.2-2

Pulled, thanks.

Paolo

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

^ permalink raw reply


This is 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.