* Re: [PATCH] Handle SForced in storage_modifiers
From: Linus Torvalds @ 2016-11-14 20:17 UTC (permalink / raw)
To: Luc Van Oostenryck; +Cc: Jeff Layton, Sparse Mailing-list, Al Viro
In-Reply-To: <20161114200447.GA15866@macbook.local>
On Mon, Nov 14, 2016 at 12:04 PM, Luc Van Oostenryck
<luc.vanoostenryck@gmail.com> wrote:
>
> The array is statically initialized and never modified,
> your patch shouldn't change anything, and this regardless of
> the memory layout or compiler options.
The problem is the _size_ of the array. Without that initializer for
SForced case, it is one entry too small, and you get a random access
past the end of the array.
The patch is definitely correct.
Linus
^ permalink raw reply
* [GIT PULL FOR renesas-drivers] VSP Writeback prototype
From: Kieran Bingham @ 2016-11-14 20:17 UTC (permalink / raw)
To: Geert Uytterhoeven, linux-renesas-soc; +Cc: Kieran Bingham
From: Kieran Bingham <kieran.bingham@ideasonboard.com>
Hi Geert,
The following changes since commit 8bc55e5947b58dee3c8b126d7c303991ae0db130:
tty: serial_core: Fix serial console crash on port shutdown (2016-10-25 13:53:49 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git tags/vsp1/writeback/v2
for you to fetch changes up to 7ce3d143d5c287e5786b3471c32112363bcbdca2:
v4l: vsp1: Provide a writeback video device (2016-11-03 10:34:29 +0000)
This implementation of a writeback video node allows frames to be
captured from the display pipeline using standard V4L2 calls.
----------------------------------------------------------------
Kieran Bingham (2):
Revert "[media] v4l: vsp1: Supply frames to the DU continuously"
v4l: vsp1: Provide a writeback video device
drivers/media/platform/vsp1/vsp1.h | 1 +
drivers/media/platform/vsp1/vsp1_drm.c | 19 ++++
drivers/media/platform/vsp1/vsp1_drv.c | 5 +-
drivers/media/platform/vsp1/vsp1_rwpf.h | 1 +
drivers/media/platform/vsp1/vsp1_video.c | 161 ++++++++++++++++++++++++++++---
drivers/media/platform/vsp1/vsp1_video.h | 5 +
drivers/media/platform/vsp1/vsp1_wpf.c | 19 +++-
7 files changed, 193 insertions(+), 18 deletions(-)
^ permalink raw reply
* Re: [PATCH] audit: skip sessionid sentinel value when auto-incrementing
From: Paul Moore @ 2016-11-14 20:17 UTC (permalink / raw)
To: Richard Guy Briggs; +Cc: linux-audit, linux-kernel, containers
In-Reply-To: <2e99896c655ae31ea481240692a720e9701b0a76.1478758980.git.rgb@redhat.com>
On Thu, Nov 10, 2016 at 1:41 AM, Richard Guy Briggs <rgb@redhat.com> wrote:
> The value (unsigned int)-1 is used as a sentinel to indicate the
> sessionID is unset. Skip this value when the session_id value wraps.
>
> Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> ---
> kernel/auditsc.c | 5 ++++-
> 1 files changed, 4 insertions(+), 1 deletions(-)
Since we haven't merged the session ID kernel patches into audit#next
yet, why don't you just squash this patch in with the session ID patch
and resubmit upstream in one nice neat patch.
> diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> index 5abf1dc..e414dfa 100644
> --- a/kernel/auditsc.c
> +++ b/kernel/auditsc.c
> @@ -2025,8 +2025,11 @@ int audit_set_loginuid(kuid_t loginuid)
> goto out;
>
> /* are we setting or clearing? */
> - if (uid_valid(loginuid))
> + if (uid_valid(loginuid)) {
> sessionid = (unsigned int)atomic_inc_return(&session_id);
> + if (unlikely(sessionid == (unsigned int)-1))
> + sessionid = (unsigned int)atomic_inc_return(&session_id);
> + }
>
> task->sessionid = sessionid;
> task->loginuid = loginuid;
> --
> 1.7.1
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [PATCH] audit: skip sessionid sentinel value when auto-incrementing
From: Paul Moore @ 2016-11-14 20:17 UTC (permalink / raw)
To: Richard Guy Briggs
Cc: containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-audit-H+wXaHxf7aLQT0dZR+AlfA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <2e99896c655ae31ea481240692a720e9701b0a76.1478758980.git.rgb-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On Thu, Nov 10, 2016 at 1:41 AM, Richard Guy Briggs <rgb-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> The value (unsigned int)-1 is used as a sentinel to indicate the
> sessionID is unset. Skip this value when the session_id value wraps.
>
> Signed-off-by: Richard Guy Briggs <rgb-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> ---
> kernel/auditsc.c | 5 ++++-
> 1 files changed, 4 insertions(+), 1 deletions(-)
Since we haven't merged the session ID kernel patches into audit#next
yet, why don't you just squash this patch in with the session ID patch
and resubmit upstream in one nice neat patch.
> diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> index 5abf1dc..e414dfa 100644
> --- a/kernel/auditsc.c
> +++ b/kernel/auditsc.c
> @@ -2025,8 +2025,11 @@ int audit_set_loginuid(kuid_t loginuid)
> goto out;
>
> /* are we setting or clearing? */
> - if (uid_valid(loginuid))
> + if (uid_valid(loginuid)) {
> sessionid = (unsigned int)atomic_inc_return(&session_id);
> + if (unlikely(sessionid == (unsigned int)-1))
> + sessionid = (unsigned int)atomic_inc_return(&session_id);
> + }
>
> task->sessionid = sessionid;
> task->loginuid = loginuid;
> --
> 1.7.1
>
> --
> Linux-audit mailing list
> Linux-audit-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
> https://www.redhat.com/mailman/listinfo/linux-audit
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [PATCH] PCI: rockchip: correct the use of FTS mask
From: Bjorn Helgaas @ 2016-11-14 20:17 UTC (permalink / raw)
To: Brian Norris
Cc: Bjorn Helgaas, linux-kernel, Brian Norris, Shawn Lin, Wenrui Li,
Heiko Stuebner, linux-pci, linux-rockchip, Rajat Jain
In-Reply-To: <1476832384-10215-1-git-send-email-briannorris@chromium.org>
On Tue, Oct 18, 2016 at 04:13:04PM -0700, Brian Norris wrote:
> We're trying to mask out bits[23:8] while retaining [32:24, 7:0], but
> we're doing the inverse. That doesn't have too much effect, since we're
> setting all the [23:8] bits to 1, and the other bits are only relevant
> for modes we're currently not using. But we should get this right.
>
> Fixes: ca1989084054 ("PCI: rockchip: Fix wrong transmitted FTS count")
> Signed-off-by: Brian Norris <briannorris@chromium.org>
Applied with Shawn's ack to pci/host-rockchip, thanks!
> ---
> drivers/pci/host/pcie-rockchip.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
> index e0b22dab9b7a..5c2e3297a3ff 100644
> --- a/drivers/pci/host/pcie-rockchip.c
> +++ b/drivers/pci/host/pcie-rockchip.c
> @@ -492,7 +492,7 @@ static int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
>
> /* Fix the transmitted FTS count desired to exit from L0s. */
> status = rockchip_pcie_read(rockchip, PCIE_CORE_CTRL_PLC1);
> - status = (status & PCIE_CORE_CTRL_PLC1_FTS_MASK) |
> + status = (status & ~PCIE_CORE_CTRL_PLC1_FTS_MASK) |
> (PCIE_CORE_CTRL_PLC1_FTS_CNT << PCIE_CORE_CTRL_PLC1_FTS_SHIFT);
> rockchip_pcie_write(rockchip, status, PCIE_CORE_CTRL_PLC1);
>
> --
> 2.8.0.rc3.226.g39d4020
>
^ permalink raw reply
* [GIT PULL FOR renesas-drivers] VSP Partition algorithm improvements
From: Kieran Bingham @ 2016-11-14 20:17 UTC (permalink / raw)
To: Geert Uytterhoeven, linux-renesas-soc; +Cc: Kieran Bingham
From: Kieran Bingham <kieran.bingham@ideasonboard.com>
Hi Geert,
The following changes since commit 8bc55e5947b58dee3c8b126d7c303991ae0db130:
tty: serial_core: Fix serial console crash on port shutdown (2016-10-25 13:53:49 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git tags/vsp1/pa-improvements/v1
for you to fetch changes up to 97ec8cd22aae933399b84b1a84eedcc48ad35eb8:
v4l: vsp1: Remove redundant context variables (2016-11-14 18:49:57 +0000)
This tag contains some improvements to the performance of the partition
algorithm by moving the calculations to the stream on calls, instead of
calculating each partition in every frame during interrupt context.
----------------------------------------------------------------
Kieran Bingham (4):
v4l: vsp1: Implement partition algorithm restrictions
v4l: vsp1: Move vsp1_video_pipeline_setup_partitions() function
v4l: vsp1: Calculate partition sizes at stream start.
v4l: vsp1: Remove redundant context variables
drivers/media/platform/vsp1/vsp1_pipe.h | 10 ++-
drivers/media/platform/vsp1/vsp1_sru.c | 7 +-
drivers/media/platform/vsp1/vsp1_sru.h | 1 +
drivers/media/platform/vsp1/vsp1_video.c | 124 +++++++++++++++++++------------
4 files changed, 89 insertions(+), 53 deletions(-)
^ permalink raw reply
* [PATCH 1/3] staging: comedi: ni_mio_common: fix M Series ni_ai_insn_read() data mask
From: Ian Abbott @ 2016-11-14 20:16 UTC (permalink / raw)
To: devel
Cc: Greg Kroah-Hartman, Ian Abbott, H Hartley Sweeten, linux-kernel,
# 4 . 7+
In-Reply-To: <20161114201623.18161-1-abbotti@mev.co.uk>
For NI M Series cards, the Comedi `insn_read` handler for the AI
subdevice is broken due to ANDing the value read from the AI FIFO data
register with an incorrect mask. The incorrect mask clears all but the
most significant bit of the sample data. It should preserve all the
sample data bits. Correct it.
Fixes: 817144ae7fda ("staging: comedi: ni_mio_common: remove unnecessary use of 'board->adbits'")
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Cc: <stable@vger.kernel.org> # 4.7+
---
Needs backporting to stable kernels >= 3.17
---
drivers/staging/comedi/drivers/ni_mio_common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/comedi/drivers/ni_mio_common.c b/drivers/staging/comedi/drivers/ni_mio_common.c
index 9812508..9543539 100644
--- a/drivers/staging/comedi/drivers/ni_mio_common.c
+++ b/drivers/staging/comedi/drivers/ni_mio_common.c
@@ -1832,7 +1832,7 @@ static int ni_ai_insn_read(struct comedi_device *dev,
unsigned int *data)
{
struct ni_private *devpriv = dev->private;
- unsigned int mask = (s->maxdata + 1) >> 1;
+ unsigned int mask = s->maxdata;
int i, n;
unsigned int signbits;
unsigned int d;
--
2.10.2
^ permalink raw reply related
* [PATCH 2/3] staging: comedi: ni_mio_common: fix E series ni_ai_insn_read() data
From: Ian Abbott @ 2016-11-14 20:16 UTC (permalink / raw)
To: devel
Cc: Greg Kroah-Hartman, Ian Abbott, H Hartley Sweeten, linux-kernel,
# 4 . 7+
In-Reply-To: <20161114201623.18161-1-abbotti@mev.co.uk>
Commit 0557344e2149 ("staging: comedi: ni_mio_common: fix local var for
32-bit read") changed the type of local variable `d` from `unsigned
short` to `unsigned int` to fix a bug introduced in
commit 9c340ac934db ("staging: comedi: ni_stc.h: add read/write
callbacks to struct ni_private") when reading AI data for NI PCI-6110
and PCI-6111 cards. Unfortunately, other parts of the function rely on
the variable being `unsigned short` when an offset value in local
variable `signbits` is added to `d` before writing the value to the
`data` array:
d += signbits;
data[n] = d;
The `signbits` variable will be non-zero in bipolar mode, and is used to
convert the hardware's 2's complement, 16-bit numbers to Comedi's
straight binary sample format (with 0 representing the most negative
voltage). This breaks because `d` is now 32 bits wide instead of 16
bits wide, so after the addition of `signbits`, `data[n]` ends up being
set to values above 65536 for negative voltages. This affects all
supported "E series" cards except PCI-6143 (and PXI-6143). Fix it by
ANDing the value written to the `data[n]` with the mask 0xffff.
Fixes: 0557344e2149 ("staging: comedi: ni_mio_common: fix local var for 32-bit read")
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Cc: <stable@vger.kernel.org> # 4.7+
----
Needs backporting to stable kernels 3.18 onwards.
---
drivers/staging/comedi/drivers/ni_mio_common.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/comedi/drivers/ni_mio_common.c b/drivers/staging/comedi/drivers/ni_mio_common.c
index 9543539..a974ab7 100644
--- a/drivers/staging/comedi/drivers/ni_mio_common.c
+++ b/drivers/staging/comedi/drivers/ni_mio_common.c
@@ -1875,7 +1875,7 @@ static int ni_ai_insn_read(struct comedi_device *dev,
return -ETIME;
}
d += signbits;
- data[n] = d;
+ data[n] = d & 0xffff;
}
} else if (devpriv->is_6143) {
for (n = 0; n < insn->n; n++) {
@@ -1924,9 +1924,8 @@ static int ni_ai_insn_read(struct comedi_device *dev,
data[n] = dl;
} else {
d = ni_readw(dev, NI_E_AI_FIFO_DATA_REG);
- /* subtle: needs to be short addition */
d += signbits;
- data[n] = d;
+ data[n] = d & 0xffff;
}
}
}
--
2.10.2
^ permalink raw reply related
* Re: [PATCH] sd_zbc: Force use of READ16/WRITE16
From: Jens Axboe @ 2016-11-14 20:17 UTC (permalink / raw)
To: Damien Le Moal
Cc: linux-block, linux-scsi, Christoph Hellwig, Martin K . Petersen,
Hannes Reinecke, Shaun Tancheff
In-Reply-To: <1478843606-15647-1-git-send-email-damien.lemoal@wdc.com>
On 11/10/2016 10:53 PM, Damien Le Moal wrote:
> Normally, sd_read_capacity sets sdp->use_16_for_rw to 1 based on the
> disk capacity so that READ16/WRITE16 are used for large drives.
> However, for a zoned disk with RC_BASIS set to 0, the capacity reported
> through READ_CAPACITY may be very small, leading to use_16_for_rw not being
> set and READ10/WRITE10 commands being used, even after the actual zoned disk
> capacity is corrected in sd_zbc_read_zones. This causes LBA offset overflow for
> accesses beyond 2TB.
>
> As the ZBC standard makes it mandatory for ZBC drives to support
> the READ16/WRITE16 commands anyway, make sure that use_16_for_rw is set.
Added to the 4.10 branch, thanks.
--
Jens Axboe
^ permalink raw reply
* [Buildroot] [PATCH next v1] lcms2: bump version to 2.8
From: Peter Seiderer @ 2016-11-14 20:16 UTC (permalink / raw)
To: buildroot
For ChangeLog see [1].
[1] https://github.com/mm2/Little-CMS/blob/master/ChangeLog
Signed-off-by: Peter Seiderer <ps.report@gmx.net>
---
package/lcms2/lcms2.hash | 7 +++----
package/lcms2/lcms2.mk | 4 ++--
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/package/lcms2/lcms2.hash b/package/lcms2/lcms2.hash
index 908822f..1cf1017 100644
--- a/package/lcms2/lcms2.hash
+++ b/package/lcms2/lcms2.hash
@@ -1,5 +1,4 @@
-# From http://sourceforge.net/projects/lcms/files/lcms/2.7/
-sha1 625f0d74bad4a0f6f917120fd992437d26f754d2 lcms2-2.7.tar.gz
-md5 06c1626f625424a811fb4b5eb070839d lcms2-2.7.tar.gz
+# From https://sourceforge.net/projects/lcms/files/lcms/2.8
+sha1 e9535ec4a572b8fc7a1c405c35e6f4dc97714197 lcms2-2.8.tar.gz
# Locally computed:
-sha256 4524234ae7de185e6b6da5d31d6875085b2198bc63b1211f7dde6e2d197d6a53 lcms2-2.7.tar.gz
+sha256 66d02b229d2ea9474e62c2b6cd6720fde946155cd1d0d2bffdab829790a0fb22 lcms2-2.8.tar.gz
diff --git a/package/lcms2/lcms2.mk b/package/lcms2/lcms2.mk
index 265af29..8d0609e 100644
--- a/package/lcms2/lcms2.mk
+++ b/package/lcms2/lcms2.mk
@@ -4,8 +4,8 @@
#
################################################################################
-LCMS2_VERSION = 2.7
-LCMS2_SITE = http://downloads.sourceforge.net/lcms/lcms
+LCMS2_VERSION = 2.8
+LCMS2_SITE = http://downloads.sourceforge.net/project/lcms/lcms/$(LCMS2_VERSION)
LCMS2_LICENSE = MIT
LCMS2_LICENSE_FILES = COPYING
LCMS2_INSTALL_STAGING = YES
--
2.8.1
^ permalink raw reply related
* [PATCH 3/3] staging: comedi: ni_mio_common: remove variable 'dl' in ni_ai_insn_read()
From: Ian Abbott @ 2016-11-14 20:16 UTC (permalink / raw)
To: devel; +Cc: Greg Kroah-Hartman, Ian Abbott, H Hartley Sweeten, linux-kernel
In-Reply-To: <20161114201623.18161-1-abbotti@mev.co.uk>
In `ni_ai_insn_read()`, local variable `dl` is declared as `unsigned
long`, but `unsigned int` will do. Get rid of it and use local variable
`d` instead. (That used to be `unsigned short`, but has been `unsigned
int` since kernel version 3.18.)
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
---
drivers/staging/comedi/drivers/ni_mio_common.c | 15 +++++++--------
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/comedi/drivers/ni_mio_common.c b/drivers/staging/comedi/drivers/ni_mio_common.c
index a974ab7..b2e3828 100644
--- a/drivers/staging/comedi/drivers/ni_mio_common.c
+++ b/drivers/staging/comedi/drivers/ni_mio_common.c
@@ -1836,7 +1836,6 @@ static int ni_ai_insn_read(struct comedi_device *dev,
int i, n;
unsigned int signbits;
unsigned int d;
- unsigned long dl;
ni_load_channelgain_list(dev, s, 1, &insn->chanspec);
@@ -1887,15 +1886,15 @@ static int ni_ai_insn_read(struct comedi_device *dev,
* bit to move a single 16bit stranded sample into
* the FIFO.
*/
- dl = 0;
+ d = 0;
for (i = 0; i < NI_TIMEOUT; i++) {
if (ni_readl(dev, NI6143_AI_FIFO_STATUS_REG) &
0x01) {
/* Get stranded sample into FIFO */
ni_writel(dev, 0x01,
NI6143_AI_FIFO_CTRL_REG);
- dl = ni_readl(dev,
- NI6143_AI_FIFO_DATA_REG);
+ d = ni_readl(dev,
+ NI6143_AI_FIFO_DATA_REG);
break;
}
}
@@ -1903,7 +1902,7 @@ static int ni_ai_insn_read(struct comedi_device *dev,
dev_err(dev->class_dev, "timeout\n");
return -ETIME;
}
- data[n] = (((dl >> 16) & 0xFFFF) + signbits) & 0xFFFF;
+ data[n] = (((d >> 16) & 0xFFFF) + signbits) & 0xFFFF;
}
} else {
for (n = 0; n < insn->n; n++) {
@@ -1919,9 +1918,9 @@ static int ni_ai_insn_read(struct comedi_device *dev,
return -ETIME;
}
if (devpriv->is_m_series) {
- dl = ni_readl(dev, NI_M_AI_FIFO_DATA_REG);
- dl &= mask;
- data[n] = dl;
+ d = ni_readl(dev, NI_M_AI_FIFO_DATA_REG);
+ d &= mask;
+ data[n] = d;
} else {
d = ni_readw(dev, NI_E_AI_FIFO_DATA_REG);
d += signbits;
--
2.10.2
^ permalink raw reply related
* Re: [PATCH RFC] ARM: dts: add support for Turris Omnia
From: Uwe Kleine-König @ 2016-11-14 20:16 UTC (permalink / raw)
To: tomas.hlavacek-x+rMaJPWets
Cc: Jason Cooper, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
Martin Strbačka, Rob Herring, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
marex-ynQEQJNshbs
In-Reply-To: <1479126185.15557.5-TAvD023jEQEN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 6108 bytes --]
Hello Tomas,
On Mon, Nov 14, 2016 at 01:23:05PM +0100, tomas.hlavacek-x+rMaJPWets@public.gmane.org wrote:
> On Sat, Nov 5, 2016 at 9:38 PM, Uwe Kleine-König <uwe-rXY34ruvC2xidJT2blvkqNi2O/JbrIOy@public.gmane.org>
> wrote:
> > This machine is an open hardware router by cz.nic driven by a
> > Marvell Armada 385.
> >
> > Signed-off-by: Uwe Kleine-König <uwe-rXY34ruvC2xidJT2blvkqNi2O/JbrIOy@public.gmane.org>
> > ---
> >
> > Hello,
> >
> > the following components are working:
> >
> > - WAN port
> > - eMMC
>
> But I not not sure about DDR50 mode. At least with kernel 4.4, that we use
> in production, we had to limit to SDR50 to overcome I/O errors and
> communication instability, if I can remember it correctly. So it might need
> more testing with the current kernel.
I didn't test that extensively, but the eMMC serves my rootfs and I
didn't had any problems so far.
> > Still missing is support for the switch. Wireless fails to probe, didn't
> > debug this up to now. SFP is untested as is UART1.
>
> Actually SFP is connected to SGMII interface of eth1, which is routed
> through SERDES 5. The SGMII line is shared between the SFP and metallic PHY
> 88E1514. There is a autonomous high-speed switch connected to the SFPDET
> signal from SFP cage. It disconnects the metallic SFP and connects SGMII to
> SFP once the module is connected.
>
> The SFP is also connected to the I2C mux port 4 and to GPIO expander for
> reading/driving SFPDET, LOS, TXFLT, TXDIS signals:
>
> &i2c0 {
> pinctrl-names = "default";
> pinctrl-0 = <&i2c0_pins>;
> status = "okay";
> clock-frequency = <100000>;
>
> i2cmux@70 {
> compatible = "nxp,pca9547";
> #address-cells = <1>;
> #size-cells = <0>;
> reg = <0x70>;
> status = "okay";
>
> ...
>
> i2c@7 {
> /* SFP+ GPIO expander */
> #address-cells = <1>;
> #size-cells = <0>;
> reg = <7>;
>
> sfpgpio: gpio@71 {
> compatible = "nxp,pca9538";
> reg = <0x71>;
> interrupt-parent = <&gpio1>;
> interrupts = <14 IRQ_TYPE_LEVEL_LOW>;
> gpio-controller;
> #gpio-cells = <2>;
> };
I have authored a nearly identical snippet, mine looks as follows:
+ i2c@7 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <7>;
+
+ pcawan: gpio@71 {
+ compatible = "nxp,pca9538";
+ reg = <0x71>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pcawan_pins>;
+
+ interrupt-parent = <&gpio1>;
+ interrupts = <14 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+ };
The interrupt-controller part doesn't seem to work though, at least
+ interrupt-parent = <&pcawan>;
+ interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
in the phy node gives an error.
> };
> };
> };
>
> We have our proprietary support hacked onto mvneta driver for disconnecting
> PHY on the fly. It is a bit nasty, so I suggest to ignore SFP in this DTS
> altogether and let's wait till "phylink based SFP module support" or
> something alike hits upstream, so we can base the SFP support on solid code;
> unless somebody has a better idea, of course.
>
> >
> >
> > diff --git a/arch/arm/boot/dts/armada-385-turris-omnia.dts
> > b/arch/arm/boot/dts/armada-385-turris-omnia.dts
> > new file mode 100644
> > index 000000000000..d3cd8a4d713d
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/armada-385-turris-omnia.dts
> > @@ -0,0 +1,246 @@
> ...
> > +
> > + /* USB part of the eSATA/USB 2.0 port */
>
> This comment is perhaps some error inherited from my development DTS. We do
> not have any eSATA, perhaps PCIe/USB 2.0 slot.
oh right. I changed it for v3.
> >
> > + usb@58000 {
> > + status = "okay";
> > + };
> > +
> > +
> > +ð0 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&ge0_rgmii_pins>;
> > + status = "okay";
> > + phy-mode = "rgmii-id";
> > +
> > + fixed-link {
> > + speed = <1000>;
> > + full-duplex;
> > + };
> > +};
> > +
> > +ð1 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&ge1_rgmii_pins>;
> > + status = "okay";
> > + phy-mode = "rgmii-id";
> > +
> > + fixed-link {
> > + speed = <1000>;
> > + full-duplex;
> > + };
> > +};
> > +
>
> Actually eth0 and eth1 (both are RGMII) are connected to the 88E6176 switch.
> The problem is that from what I have read so far the switch can not operate
> in DSA mode with two CPU ports. We currently operate the switch in "normal
> mode" with the eth0 and eth1 set to fixed-link 1000/full and with
> proprietary driver (derived from OpenWRT switch drivers). I would say that
> these records for eth0 and eth1 are therefore redundant, because it does
> nothing without the switch support and it would most likely change once we
> have DSA driver (using only eth0).
Right. They do nothing currently. In my local tree I have a
specification for the switch which allows to read the phy registers of
the lan ports, but communication isn't possible yet. For this AFAIK I
need at least one of these. I mailed a few iterations with Andrew here,
but no success so far. Also dropping one cpu port from the definition
didn't help.
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply
* [PATCH RFC] ARM: dts: add support for Turris Omnia
From: Uwe Kleine-König @ 2016-11-14 20:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479126185.15557.5@smtp.gmail.com>
Hello Tomas,
On Mon, Nov 14, 2016 at 01:23:05PM +0100, tomas.hlavacek at nic.cz wrote:
> On Sat, Nov 5, 2016 at 9:38 PM, Uwe Kleine-K?nig <uwe@kleine-koenig.org>
> wrote:
> > This machine is an open hardware router by cz.nic driven by a
> > Marvell Armada 385.
> >
> > Signed-off-by: Uwe Kleine-K?nig <uwe@kleine-koenig.org>
> > ---
> >
> > Hello,
> >
> > the following components are working:
> >
> > - WAN port
> > - eMMC
>
> But I not not sure about DDR50 mode. At least with kernel 4.4, that we use
> in production, we had to limit to SDR50 to overcome I/O errors and
> communication instability, if I can remember it correctly. So it might need
> more testing with the current kernel.
I didn't test that extensively, but the eMMC serves my rootfs and I
didn't had any problems so far.
> > Still missing is support for the switch. Wireless fails to probe, didn't
> > debug this up to now. SFP is untested as is UART1.
>
> Actually SFP is connected to SGMII interface of eth1, which is routed
> through SERDES 5. The SGMII line is shared between the SFP and metallic PHY
> 88E1514. There is a autonomous high-speed switch connected to the SFPDET
> signal from SFP cage. It disconnects the metallic SFP and connects SGMII to
> SFP once the module is connected.
>
> The SFP is also connected to the I2C mux port 4 and to GPIO expander for
> reading/driving SFPDET, LOS, TXFLT, TXDIS signals:
>
> &i2c0 {
> pinctrl-names = "default";
> pinctrl-0 = <&i2c0_pins>;
> status = "okay";
> clock-frequency = <100000>;
>
> i2cmux at 70 {
> compatible = "nxp,pca9547";
> #address-cells = <1>;
> #size-cells = <0>;
> reg = <0x70>;
> status = "okay";
>
> ...
>
> i2c at 7 {
> /* SFP+ GPIO expander */
> #address-cells = <1>;
> #size-cells = <0>;
> reg = <7>;
>
> sfpgpio: gpio at 71 {
> compatible = "nxp,pca9538";
> reg = <0x71>;
> interrupt-parent = <&gpio1>;
> interrupts = <14 IRQ_TYPE_LEVEL_LOW>;
> gpio-controller;
> #gpio-cells = <2>;
> };
I have authored a nearly identical snippet, mine looks as follows:
+ i2c at 7 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <7>;
+
+ pcawan: gpio at 71 {
+ compatible = "nxp,pca9538";
+ reg = <0x71>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pcawan_pins>;
+
+ interrupt-parent = <&gpio1>;
+ interrupts = <14 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+ };
The interrupt-controller part doesn't seem to work though, at least
+ interrupt-parent = <&pcawan>;
+ interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
in the phy node gives an error.
> };
> };
> };
>
> We have our proprietary support hacked onto mvneta driver for disconnecting
> PHY on the fly. It is a bit nasty, so I suggest to ignore SFP in this DTS
> altogether and let's wait till "phylink based SFP module support" or
> something alike hits upstream, so we can base the SFP support on solid code;
> unless somebody has a better idea, of course.
>
> >
> >
> > diff --git a/arch/arm/boot/dts/armada-385-turris-omnia.dts
> > b/arch/arm/boot/dts/armada-385-turris-omnia.dts
> > new file mode 100644
> > index 000000000000..d3cd8a4d713d
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/armada-385-turris-omnia.dts
> > @@ -0,0 +1,246 @@
> ...
> > +
> > + /* USB part of the eSATA/USB 2.0 port */
>
> This comment is perhaps some error inherited from my development DTS. We do
> not have any eSATA, perhaps PCIe/USB 2.0 slot.
oh right. I changed it for v3.
> >
> > + usb at 58000 {
> > + status = "okay";
> > + };
> > +
> > +
> > +ð0 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&ge0_rgmii_pins>;
> > + status = "okay";
> > + phy-mode = "rgmii-id";
> > +
> > + fixed-link {
> > + speed = <1000>;
> > + full-duplex;
> > + };
> > +};
> > +
> > +ð1 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&ge1_rgmii_pins>;
> > + status = "okay";
> > + phy-mode = "rgmii-id";
> > +
> > + fixed-link {
> > + speed = <1000>;
> > + full-duplex;
> > + };
> > +};
> > +
>
> Actually eth0 and eth1 (both are RGMII) are connected to the 88E6176 switch.
> The problem is that from what I have read so far the switch can not operate
> in DSA mode with two CPU ports. We currently operate the switch in "normal
> mode" with the eth0 and eth1 set to fixed-link 1000/full and with
> proprietary driver (derived from OpenWRT switch drivers). I would say that
> these records for eth0 and eth1 are therefore redundant, because it does
> nothing without the switch support and it would most likely change once we
> have DSA driver (using only eth0).
Right. They do nothing currently. In my local tree I have a
specification for the switch which allows to read the phy registers of
the lan ports, but communication isn't possible yet. For this AFAIK I
need at least one of these. I mailed a few iterations with Andrew here,
but no success so far. Also dropping one cpu port from the definition
didn't help.
Best regards
Uwe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161114/a783ea53/attachment.sig>
^ permalink raw reply
* [PATCH 0/3] staging: comedi: ni_mio_common: ni_ai_insn_read() fixes
From: Ian Abbott @ 2016-11-14 20:16 UTC (permalink / raw)
To: devel; +Cc: Greg Kroah-Hartman, Ian Abbott, H Hartley Sweeten, linux-kernel
A couple of bug fixes for incorrect sample data read by
ni_ai_insn_read(), plus removal of an unnecessary variable.
1) staging: comedi: ni_mio_common: fix M Series ni_ai_insn_read() data
mask
2) staging: comedi: ni_mio_common: fix E series ni_ai_insn_read() data
3) staging: comedi: ni_mio_common: remove variable 'dl' in
ni_ai_insn_read()
The bug fix patches 1) and 2) apply cleanly to kernel version 4.7
onwards, but will need backporting to longterm kernels 3.18 onwards.
drivers/staging/comedi/drivers/ni_mio_common.c | 22 ++++++++++------------
1 file changed, 10 insertions(+), 12 deletions(-)
^ permalink raw reply
* [PATCH 2/2] tls: Don't fail if root CA present in received chain
From: Andrew Zaborowski @ 2016-11-14 20:16 UTC (permalink / raw)
To: ell
In-Reply-To: <1479154592-8116-1-git-send-email-andrew.zaborowski@intel.com>
[-- Attachment #1: Type: text/plain, Size: 2218 bytes --]
The certificate chain from the Server Certificate message may be a
complete chain from server's certificate to root CA. l_keyring_link
would fail if we tried to add the self-signed root CA to the ring,
this seems to be unrelated to that certificate being the same as the
one in the trusted ring.
In the early userspace tls_cert_verify_certchain implementation the
verification would succeed if any of the certificates in the chain
was trusted by the supplied CA + the trust chain was correct, but the
RFC implies this must be the root CA (see the comment in the code).
---
ell/tls.c | 21 +++++++++++++++++----
1 file changed, 17 insertions(+), 4 deletions(-)
diff --git a/ell/tls.c b/ell/tls.c
index 388efa7..06e3341 100644
--- a/ell/tls.c
+++ b/ell/tls.c
@@ -2469,13 +2469,26 @@ static void tls_key_cleanup(struct l_key **p)
l_key_free_norevoke(*p);
}
-static bool tls_cert_verify_with_keyring(struct tls_cert *cert,
- struct l_keyring *ring)
+static int tls_cert_verify_with_keyring(struct tls_cert *cert,
+ struct l_keyring *ring,
+ struct tls_cert *root)
{
if (!cert)
return true;
- if (tls_cert_verify_with_keyring(cert->issuer, ring)) {
+ /*
+ * RFC5246 7.4.2:
+ * "Because certificate validation requires that root keys be
+ * distributed independently, the self-signed certificate that
+ * specifies the root certificate authority MAY be omitted from
+ * the chain, under the assumption that the remote end must
+ * already possess it in order to validate it in any case."
+ */
+ if (!cert->issuer && root && cert->size == root->size &&
+ !memcmp(cert->asn1, root->asn1, root->size))
+ return true;
+
+ if (tls_cert_verify_with_keyring(cert->issuer, ring, root)) {
L_AUTO_CLEANUP_VAR(struct l_key *, key, tls_key_cleanup);
key = l_key_new(L_KEY_RSA, cert->asn1, cert->size);
@@ -2520,7 +2533,7 @@ bool tls_cert_verify_certchain(struct tls_cert *certchain,
if (!verify_ring)
return false;
- return tls_cert_verify_with_keyring(certchain, verify_ring);
+ return tls_cert_verify_with_keyring(certchain, verify_ring, ca_cert);
}
void tls_cert_free_certchain(struct tls_cert *cert)
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] tls: Fix CA certificate presence check
From: Andrew Zaborowski @ 2016-11-14 20:16 UTC (permalink / raw)
To: ell
[-- Attachment #1: Type: text/plain, Size: 483 bytes --]
---
ell/tls.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ell/tls.c b/ell/tls.c
index 3879b50..388efa7 100644
--- a/ell/tls.c
+++ b/ell/tls.c
@@ -1474,7 +1474,7 @@ static void tls_handle_certificate(struct l_tls *tls,
* against our CA if we have any.
*/
- if (ca_cert) {
+ if (tls->ca_cert_path) {
ca_cert = tls_cert_load_file(tls->ca_cert_path);
if (!ca_cert) {
tls_disconnect(tls, TLS_ALERT_INTERNAL_ERROR,
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v2] i2c: mux: fix up dependencies
From: Peter Rosin @ 2016-11-14 14:39 UTC (permalink / raw)
To: Linus Walleij, Wolfram Sang, linux-i2c; +Cc: stable, Jonathan Cameron
In-Reply-To: <1479134057-30653-1-git-send-email-linus.walleij@linaro.org>
On 2016-11-14 15:34, Linus Walleij wrote:
> We get the following build error from UM Linux after adding
> an entry to drivers/iio/gyro/Kconfig that issues "select I2C_MUX":
>
> ERROR: "devm_ioremap_resource"
> [drivers/i2c/muxes/i2c-mux-reg.ko] undefined!
> ERROR: "of_address_to_resource"
> [drivers/i2c/muxes/i2c-mux-reg.ko] undefined!
>
> It appears that the I2C mux core code depends on HAS_IOMEM
> for historical reasons, while CONFIG_I2C_MUX_REG does *not*
> have a direct dependency on HAS_IOMEM.
>
> This creates a situation where a allyesconfig or allmodconfig
> for UM Linux will select I2C_MUX, and will implicitly enable
> I2C_MUX_REG as well, and the compilation will fail for the
> register driver.
>
> Fix this up by making I2C_MUX_REG depend on HAS_IOMEM and
> removing the dependency from I2C_MUX.
>
> Cc: stable@vger.kernel.org
> Reported-by: kbuild test robot <fengguang.wu@intel.com>
> Reported-by: Jonathan Cameron <jic23@jic23.retrosnub.co.uk>
> Cc: Jonathan Cameron <jic23@jic23.retrosnub.co.uk>
> Cc: Peter Rosin <peda@axentia.se>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Peter Rosin <peda@axentia.se>
Thanks!
Cheers,
Peter
^ permalink raw reply
* Re: [PATCH] kbuild: Steal gcc's pie from the very beginning
From: Sebastian Andrzej Siewior @ 2016-11-14 20:14 UTC (permalink / raw)
To: Borislav Petkov; +Cc: linux-kbuild, Ben Hutchings, Michal Marek
In-Reply-To: <20161114185130.30641-1-bp@alien8.de>
On 2016-11-14 19:51:30 [+0100], Borislav Petkov wrote:
> From: Borislav Petkov <bp@suse.de>
>
> So Sebastian turned off the PIE for kernel builds but that was too late
> - Kbuild.include already uses KBUILD_CFLAGS and trying to disable gcc
> options with, say cc-disable-warning, fails:
>
> gcc -D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs
> ...
> -Wno-sign-compare -fno-asynchronous-unwind-tables -Wframe-address -c -x c /dev/null -o .31392.tmp
> /dev/null:1:0: error: code model kernel does not support PIC mode
>
> because that returns an error and we can't disable the warning. For
> example in this case:
>
> KBUILD_CFLAGS += $(call cc-disable-warning,frame-address,)
>
> which leads to gcc issuing all those warnings again.
This also means that all feature tests fail unless the -fno-PIE is
there.
Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
This thing gcc v3.4 only but I intend to update the min requirement to
alteast gcc v3.4 to cover this. As per hpa gcc v3.4 is the lowest
version should be used for x86…
Sebastian
^ permalink raw reply
* Re: [PATCH v5 04/21] acpi: Re-license ACPI builder files from GPLv2 to LGPLv2.1
From: Ken Lancaster @ 2016-11-14 20:13 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk, xen-devel@lists.xenproject.org,
boris.ostrovsky@oracle.com
Cc: andrew.cooper3@citrix.com, wei.liu2@citrix.com, jbeulich@suse.com,
lars.kurth@citrix.com
In-Reply-To: <20161114200503.GB25173@char.us.oracle.com>
ACK
-----Original Message-----
From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
Sent: Monday, November 14, 2016 3:05 PM
To: xen-devel@lists.xenproject.org; boris.ostrovsky@oracle.com
Cc: jbeulich@suse.com; andrew.cooper3@citrix.com; wei.liu2@citrix.com; lars.kurth@citrix.com; Ken Lancaster
Subject: Re: [PATCH v5 04/21] acpi: Re-license ACPI builder files from GPLv2 to LGPLv2.1
On Sat, Nov 12, 2016 at 01:02:08PM +0000, Ken Lancaster wrote:
> My apologies for the delay, this is approved.
>
> We approve the action to re-license http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=801d469ad8b2b88f669326327df03d03200efbfb under LGPLv2.1 as requested.
>
> Best,
>
> Ken Lancaster
>
>
..snip..
Heya!
Sending this email to xen-devel mailing list.
Ken,
Thank you so much for helping out with this!
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [PATCH kvm-unit-tests v2 02/17] libcflat: introduce is_power_of_2()
From: Peter Xu @ 2016-11-14 20:14 UTC (permalink / raw)
To: Andrew Jones; +Cc: kvm, rkrcmar, agordeev, jan.kiszka, pbonzini
In-Reply-To: <20161110182000.445ysavw7x2db4es@hawk.localdomain>
On Thu, Nov 10, 2016 at 07:20:00PM +0100, Andrew Jones wrote:
> On Wed, Nov 09, 2016 at 10:10:09AM -0500, Peter Xu wrote:
> > Suggested-by: Andrew Jones <drjones@redhat.com>
> > Signed-off-by: Peter Xu <peterx@redhat.com>
> > ---
> > lib/libcflat.h | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/lib/libcflat.h b/lib/libcflat.h
> > index 72b1bf9..19bd0c6 100644
> > --- a/lib/libcflat.h
> > +++ b/lib/libcflat.h
> > @@ -103,4 +103,9 @@ do { \
> > } \
> > } while (0)
> >
> > +static inline bool is_power_of_2(unsigned long n)
> > +{
> > + return (n && !(n & (n - 1)));
>
> nit: outer () are unnecessary
Will fix.
>
> > +}
> > +
> > #endif
>
> Reviewed-by: Andrew Jones <drjones@redhat.com>
Thanks,
-- peterx
^ permalink raw reply
* Re: [PATCH 0/5] Handle Link Training Failure during modeset
From: Cheng, Tony @ 2016-11-14 20:13 UTC (permalink / raw)
To: Manasi Navare
Cc: intel-gfx@lists.freedesktop.org, Peres, Martin,
dri-devel@lists.freedesktop.org, Deucher, Alexander,
Wentland, Harry
In-Reply-To: <20161114175143.GA26414@intel.com>
Acked-by: Tony Cheng <tony.cheng@amd.com>
-----Original Message-----
From: Manasi Navare [mailto:manasi.d.navare@intel.com]
Sent: Monday, November 14, 2016 12:52 PM
To: Cheng, Tony <Tony.Cheng@amd.com>
Cc: Daniel Vetter <daniel@ffwll.ch>; intel-gfx@lists.freedesktop.org; Peres, Martin <martin.peres@intel.com>; dri-devel@lists.freedesktop.org; Deucher, Alexander <Alexander.Deucher@amd.com>; Wentland, Harry <Harry.Wentland@amd.com>
Subject: Re: [Intel-gfx] [PATCH 0/5] Handle Link Training Failure during modeset
Yes driver can chose to have the pre train for kernel hiding unsupported mode, that is completely still possible for the amd driver and it would never use the link_status connector property and no interaction with userspace.
Could you please give your ACKs for the patches if you are okay with this porposal?
Regards
Manasi
On Mon, Nov 14, 2016 at 02:45:55PM +0000, Cheng, Tony wrote:
> I see. As long as amd can still just have kernel hiding unsupported mode by doing a pre-train I am okay with the proposal. Just to caution you the link training fallback we implemented on windows in old dal architecture is very painful to get right. Windows 7, 8.1 and 10 all behave differently. Not all apps handles mode change failure gracefully and worse case we get stuck in infinite mode set. This is why for future generations asic on windows we are also going to just hide unsupported mode by doing pre-train.
>
> -----Original Message-----
> From: Daniel Vetter [mailto:daniel.vetter@ffwll.ch] On Behalf Of
> Daniel Vetter
> Sent: Monday, November 14, 2016 3:04 AM
> To: Manasi Navare <manasi.d.navare@intel.com>
> Cc: Cheng, Tony <Tony.Cheng@amd.com>; intel-gfx@lists.freedesktop.org;
> Peres, Martin <martin.peres@intel.com>;
> dri-devel@lists.freedesktop.org; Deucher, Alexander
> <Alexander.Deucher@amd.com>; Wentland, Harry <Harry.Wentland@amd.com>
> Subject: Re: [Intel-gfx] [PATCH 0/5] Handle Link Training Failure
> during modeset
>
> On Sun, Nov 13, 2016 at 11:43:01PM -0800, Manasi Navare wrote:
> > On Fri, Nov 11, 2016 at 07:42:16PM +0000, Cheng, Tony wrote:
> > > In case of link training failure and requiring user space to set a lower mode, would full mode set address it? How do we make user mode select lower resolution?
> > >
> > > For example 4k@60Hz monitor, and link training at 4 lane HBR2 fails and fallback to 4 lanes HBR, 4k@60 is no longer doable. I would think preventing user mode from seeing 4K@60Hz from the start is a easier and more robust solution and requiring user mode to have logic to decide how to fallback.
> > >
> >
> > Hi Tony,
> >
> > So in case of link training failure, we first call mode_valid that
> > will use the lower link rate/lane count values based on the link
> > training fallback to validate the modes and prune the modes that are
> > higher than the available link. After this is done, then we send the uevent to userspace indicating that link status is BAD and it will redo a probe and trigger a modeset for next possible lower resolution.
>
> Just in case it's not clear: This entire discussion here is only about the userspace-visible abi changes. And I think for the worst-case we need something like this (and Harry at least said on irc that on other os you do something similar already). It of course does not preclude at all that you do additional link-training/probe on initial hotplug. That part is entirely up to drivers (and we might get there on some platforms, but on others it's a real pain to get a link up&running unfortunately for training, since we need to steal a crtc and do a full modeset).
> -Daniel
>
> >
> > Manasi
> >
> >
> > > -----Original Message-----
> > > From: Ville Syrjälä [mailto:ville.syrjala@linux.intel.com]
> > > Sent: Friday, November 11, 2016 11:44 AM
> > > To: Cheng, Tony <Tony.Cheng@amd.com>
> > > Cc: Deucher, Alexander <Alexander.Deucher@amd.com>; 'Jani Nikula'
> > > <jani.nikula@linux.intel.com>; Manasi Navare
> > > <manasi.d.navare@intel.com>; dri-devel@lists.freedesktop.org;
> > > intel-gfx@lists.freedesktop.org; Wentland, Harry
> > > <Harry.Wentland@amd.com>; Peres, Martin <martin.peres@intel.com>
> > > Subject: Re: [Intel-gfx] [PATCH 0/5] Handle Link Training Failure
> > > during modeset
> > >
> > > On Fri, Nov 11, 2016 at 04:21:58PM +0000, Cheng, Tony wrote:
> > > > For HDMI, you can yank the cable, plug back in, HDMI will light up without user mode or kernel mode doing anything.
> > > >
> > > > For DP this is not possible, someone will have to retrain the link when plugging back in or DP will not light up. We see that on Ubuntu if someone unplug display and plug it back into same connector, we do not get KMS so in this case. It appears there is some optimizations somewhere in user mode stack which I am not familiar with yet. dal added workaround to retrain the link to light it back up (after the test training at end of detection).
> > >
> > > The link should get retrained as the driver should check the link state on HPD and retrain if it's not good. At least that's what we do in i915. Of course if it's not the same display that got plugged back, the retraining might fail. The new property can help with that case as userspace would then attempt a full modeset after the failed link training.
> > >
> > > >
> > > > >From user mode perspective I think it make sense to keep CRTC running, so vblank is still going so UMD isn't impacted. As regard to connector and encoder does it matter if kernel mode change state without user mode knowing? It seems to me those are more informational to UMD as UMD doesn't act on them.
> > > >
> > > > windows does not know link state and all link management is hidden behind kernel driver.
> > >
> > > If the user visible state doesn't change in any way, then the kernel could try to manage it all internally.
> > >
> > > >
> > > > -----Original Message-----
> > > > From: Ville Syrjälä [mailto:ville.syrjala@linux.intel.com]
> > > > Sent: Friday, November 11, 2016 9:05 AM
> > > > To: Cheng, Tony <Tony.Cheng@amd.com>
> > > > Cc: Deucher, Alexander <Alexander.Deucher@amd.com>; 'Jani Nikula'
> > > > <jani.nikula@linux.intel.com>; Manasi Navare
> > > > <manasi.d.navare@intel.com>; dri-devel@lists.freedesktop.org;
> > > > intel-gfx@lists.freedesktop.org; Wentland, Harry
> > > > <Harry.Wentland@amd.com>; Peres, Martin <martin.peres@intel.com>
> > > > Subject: Re: [Intel-gfx] [PATCH 0/5] Handle Link Training
> > > > Failure during modeset
> > > >
> > > > On Thu, Nov 10, 2016 at 06:51:40PM +0000, Cheng, Tony wrote:
> > > > > Amdgpu dal implementation will do a test link training at end of detection to verify we can achieve the capability reported in DPCD. We then report mode base on result of test training.
> > > > >
> > > > > AMD hardware (at least the generations supported by amdgpu) is able to link train without timing being setup (DP encoder and CRTC is decoupled). Do we have limitation from other vendors where you need timing to be there before you can link train?
> > > >
> > > > I can't recall the specifics for all of our supported platforms, but at least I have the recollection that it would be the case yes.
> > > >
> > > > The other problem wiyh this apporach is that even if you don't need the crtc, you still need the link itself. What happens if the link is still active since userspace just didn't bother to shut it down when the cable was yanked? Can you keep the crtc going but stop it from feeding the link in a way that userspace won't be able to notice? The kms design has always been pretty much that policy is in userspace, and thus the kernel shouldn't shut down crtcs unless explicitly asked to do so.
> > > >
> > > > >
> > > > > We can also past DP1.2 link layer compliance with this approach.
> > > > >
> > > > > -----Original Message-----
> > > > > From: Deucher, Alexander
> > > > > Sent: Thursday, November 10, 2016 1:43 PM
> > > > > To: 'Jani Nikula' <jani.nikula@linux.intel.com>; Manasi Navare
> > > > > <manasi.d.navare@intel.com>; dri-devel@lists.freedesktop.org;
> > > > > intel-gfx@lists.freedesktop.org; Wentland, Harry
> > > > > <Harry.Wentland@amd.com>; Cheng, Tony <Tony.Cheng@amd.com>
> > > > > Cc: Dave Airlie <airlied@gmail.com>; Peres, Martin
> > > > > <martin.peres@intel.com>
> > > > > Subject: RE: [Intel-gfx] [PATCH 0/5] Handle Link Training
> > > > > Failure during modeset
> > > > >
> > > > > Adding Harry and Tony from our display team to review.
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Jani Nikula [mailto:jani.nikula@linux.intel.com]
> > > > > > Sent: Thursday, November 10, 2016 1:20 PM
> > > > > > To: Manasi Navare; dri-devel@lists.freedesktop.org; intel-
> > > > > > gfx@lists.freedesktop.org
> > > > > > Cc: Dave Airlie; Peres, Martin; Deucher, Alexander
> > > > > > Subject: Re: [Intel-gfx] [PATCH 0/5] Handle Link Training
> > > > > > Failure during modeset
> > > > > >
> > > > > > On Thu, 10 Nov 2016, Manasi Navare <manasi.d.navare@intel.com> wrote:
> > > > > > > Link training failure is handled by lowering the link rate
> > > > > > > first until it reaches the minimum and keeping the lane
> > > > > > > count maximum and then lowering the lane count until it
> > > > > > > reaches minimim. These fallback values are saved and
> > > > > > > hotplug uevent is sent to the userspace after setting the connector link status property to BAD.
> > > > > > > Userspace should triiger another modeset on a uevent and
> > > > > > > if link status property is BAD. This will retrain the link at fallback values.
> > > > > > > This is repeated until the link is successfully trained.
> > > > > > >
> > > > > > > This has been validated to pass DP compliance.
> > > > > >
> > > > > > This cover letter and the commit messages do a good job of
> > > > > > explaining what the patches do. However, you're lacking the
> > > > > > crucial information of
> > > > > > *why* we need userspace cooperation to handle link training
> > > > > > failures on DP mode setting, and *why* a new connector
> > > > > > property is a good solution for this.
> > > > > >
> > > > > > Here goes, including some alternative approaches we've
> > > > > > considered (and even tried):
> > > > > >
> > > > > > At the time userspace does setcrtc, we've already promised
> > > > > > the mode would work. The promise is based on the theoretical
> > > > > > capabilities of the link, but it's possible we can't reach
> > > > > > this in practice. The DP spec describes how the link should
> > > > > > be reduced, but we can't reduce the link below the requirements of the mode. Black screen follows.
> > > > > >
> > > > > > One idea would be to have setcrtc return a failure. However,
> > > > > > it is my understanding that it already should not fail as
> > > > > > the atomic checks have passed [citation needed]. It would
> > > > > > also conflict with the idea of making setcrtc asynchronous
> > > > > > in the future, returning before the actual mode setting and link training.
> > > > > >
> > > > > > Another idea is to train the link "upfront" at hotplug time,
> > > > > > before pruning the mode list, so that we can do the pruning
> > > > > > based on practical not theoretical capabilities. However,
> > > > > > the changes for link training are pretty drastic, all for
> > > > > > the sake of error handling and DP compliance, when the most
> > > > > > common happy day scenario is the current approach of link
> > > > > > training at mode setting time, using the optimal parameters for the mode.
> > > > > > It is also not certain all hardware could do this without
> > > > > > the pipe on; not even all our hardware can do this. Some of this can be solved, but not trivially.
> > > > > >
> > > > > > Both of the above ideas also fail to address link
> > > > > > degradation
> > > > > > *during* operation.
> > > > > >
> > > > > > So the idea presented in these patches is to do this in a
> > > > > > way that
> > > > > > a) changes the current happy day scenario as little as
> > > > > > possible, to avoid regressions, b) can be implemented the
> > > > > > same way by all drm drivers, c) is still opt-in for the
> > > > > > drivers and userspace, and opting out doesn't regress the
> > > > > > user experience,
> > > > > > d) doesn't prevent drivers from implementing better or
> > > > > > alternate approaches, possibly without userspace involvement. And, of course, handles all the issues presented.
> > > > > >
> > > > > > The solution is to add a "link status" connector property.
> > > > > > In the usual happy day scenario, this is always "good". If
> > > > > > something fails during or after a mode set, the kernel
> > > > > > driver can set the link status to "bad", prune the mode list
> > > > > > based on new information as necessary, and send a hotplug
> > > > > > uevent for userspace to have it re-check the valid modes
> > > > > > through getconnector, and try again. If the theoretical capabilities of the link can't be reached, the mode list is trimmed based on that.
> > > > > >
> > > > > > If the userspace is not aware of the property, the user
> > > > > > experience is the same as it currently is. If the userspace
> > > > > > is aware of the property, it has a chance to improve user
> > > > > > experience. If a drm driver does not modify the property (it
> > > > > > stays "good"), the user experience is the same as it
> > > > > > currently is. A drm driver can also choose to try to handle
> > > > > > more of the failures in kernel, hardware not limiting, or it can choose to involve userspace more. Up to the drivers.
> > > > > >
> > > > > > The reason for adding the property is to handle link
> > > > > > training failures, but it is not limited to DP or link
> > > > > > training. For example, if we implement asynchronous setcrtc,
> > > > > > we can use this to report any failures in that.
> > > > > >
> > > > > > Finally, while DP CTS compliance is advertized (which is
> > > > > > great, and could be made to work similarly for all drm
> > > > > > drivers), this can be used for the more important goal of
> > > > > > improving user experience on link training failures, by avoiding black screens.
> > > > > >
> > > > > >
> > > > > > BR,
> > > > > > Jani.
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > Manasi Navare (5):
> > > > > > > drm: Add a new connector property for link status
> > > > > > > drm/i915: Set link status property for DP connector
> > > > > > > drm/i915: Update CRTC state if connector link status
> > > > > > > property changed
> > > > > > ^^^^^^^^
> > > > > >
> > > > > > This is really drm, not i915.
> > > > > >
> > > > > >
> > > > > > > drm/i915: Find fallback link rate/lane count
> > > > > > > drm/i915: Implement Link Rate fallback on Link training
> > > > > > > failure
> > > > > > >
> > > > > > > drivers/gpu/drm/drm_atomic_helper.c | 7 ++
> > > > > > > drivers/gpu/drm/drm_connector.c | 17 ++++
> > > > > > > drivers/gpu/drm/i915/intel_ddi.c | 21 +++-
> > > > > > > drivers/gpu/drm/i915/intel_dp.c | 138
> > > > > > +++++++++++++++++++++++++-
> > > > > > > drivers/gpu/drm/i915/intel_dp_link_training.c | 12 ++-
> > > > > > > drivers/gpu/drm/i915/intel_drv.h | 12 ++-
> > > > > > > include/drm/drm_connector.h | 7 +-
> > > > > > > include/drm/drm_crtc.h | 5 +
> > > > > > > include/uapi/drm/drm_mode.h | 4 +
> > > > > > > 9 files changed, 214 insertions(+), 9 deletions(-)
> > > > > >
> > > > > > --
> > > > > > Jani Nikula, Intel Open Source Technology Center
> > > > > _______________________________________________
> > > > > Intel-gfx mailing list
> > > > > Intel-gfx@lists.freedesktop.org
> > > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > > >
> > > > --
> > > > Ville Syrjälä
> > > > Intel OTC
> > >
> > > --
> > > Ville Syrjälä
> > > Intel OTC
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: Xen ARM small task (WAS: Re: [Xen Question])
From: Julien Grall @ 2016-11-14 20:12 UTC (permalink / raw)
To: Stefano Stabellini
Cc: Edgar Iglesias (edgar.iglesias@xilinx.com), casionwoo, xen-devel
In-Reply-To: <alpine.DEB.2.10.1611111134170.6951@sstabellini-ThinkPad-X260>
Hi Stefano,
On 11/11/2016 13:55, Stefano Stabellini wrote:
> On Fri, 11 Nov 2016, Julien Grall wrote:
>> Hi Stefano,
>>
>> On 11/11/2016 02:24, Stefano Stabellini wrote:
>>> On Thu, 10 Nov 2016, Julien Grall wrote:
>>>> (CC Stefano and change the title)
>>>>
>>>> Hello,
>>>>
>>>> On 10/11/16 12:13, casionwoo wrote:
>>>>> I’m pleased about your reply and you have a lot of code to clean-up.
>>>>>
>>>>> As you mentioned, It’s really huge to digest at once. Thank you for
>>>>> understanding me.
>>>>>
>>>>> And that’s why i need a small fix up and todo list.
>>>>>
>>>>> I feel familiar with ARM and c language and there’s no specific area
>>>>> yet.
>>>>>
>>>>> I think that i can find interesting area with following up the codes.
>>>>>
>>>>> I’m looking forward to being stuck on Xen.
>>>>>
>>>>> Then it would be easier for me to understand about Xen on ARM.
>>>>>
>>>>> Please let me know the TODO and bug-fix lists.
>>>>
>>>> Stefano, before giving a list of code clean-up, do you have any small TODO
>>>> on
>>>> ARM in mind?
>>>
>>> A simple task we talked about recently is to enable the vuart
>>> (xen/arch/arm/vuart.c) for all guests. At the moment it is only emulated
>>> for Dom0, but some guests, in particular BareMetal guests
>>> (https://en.wikipedia.org/wiki/BareMetal), would benefit from it.
>>>
>>> It would be best to introduce an option in libxl to explicitly
>>> enable/disable the vuart for DomUs. Something like vuart=1 in the VM
>>> config file.
>>
>> The vuart has not been enabled for DomU because it the UART region may clash
>> with the guest memory layout (which is static).
>>
>> I don't think this option should be available until we allow the guest to use
>> the same memory layout as the host (see e820_host parameter for x86).
>
> Actually there is no reason for the vuart to use the same address as
> the physical uart on the platform, is there?
> In fact it doesn't even
> have to prentend to be the same uart as the one on the board, right?
> The vuart MMIO address could be completely configurable and independent
> from the one of the physical uart.
There is no reason to use the same information as the physical UART.
However, the vuart requires quite a few information (e.g base address,
offset of different register... see vuart_info structure in
include/xen/serial.h for more details) in order to fully work.
IHMO this is a lot of works for the user to configure. I would much
prefer to see a PL011 emulated at a specific base address and let the
user select whether he wants a UART to debug or not.
This would also be a start to be compliant with the VM System
Specification (see [1]) that mandates to emulate a PL011.
>
>
>>> BTW we should keep this up to date:
>>>
>>> https://wiki.xenproject.org/wiki/Xen_ARM_TODO
>>
>> You are right, although it might be better to use the bug tracker [1] to stay
>> aligned with the rest of the hypervisor.
>>
>> Note that I have got a list of TODO/bugs I track myself but never updated the
>> wiki.
>
> I agree that we should all use the same tool, but I didn't realize there
> has been a decision on using the bug tracker for this. In fact it
> doesn't seem to be much used at the moment.
The bug tracker might be easier to update the status of feature and keep
an history of the discussion.
>
> Maybe we should start a good old bikeshedding thread with other
> maintainers on what we should use.
I will let you kick a thread :).
Cheers,
[1]
http://www.linaro.org/app/resources/WhitePaper/VMSystemSpecificationForARM-v2.0.pdf
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [Qemu-devel] [RFC 0/3] aio: experimental virtio-blk polling mode
From: Karl Rister @ 2016-11-14 20:12 UTC (permalink / raw)
To: Stefan Hajnoczi
Cc: Stefan Hajnoczi, qemu-devel, Andrew Theurer, Paolo Bonzini,
Fam Zheng
In-Reply-To: <20161114152642.GE26198@stefanha-x1.localdomain>
On 11/14/2016 09:26 AM, Stefan Hajnoczi wrote:
> On Fri, Nov 11, 2016 at 01:59:25PM -0600, Karl Rister wrote:
>> On 11/09/2016 11:13 AM, Stefan Hajnoczi wrote:
>>> Recent performance investigation work done by Karl Rister shows that the
>>> guest->host notification takes around 20 us. This is more than the "overhead"
>>> of QEMU itself (e.g. block layer).
>>>
>>> One way to avoid the costly exit is to use polling instead of notification.
>>> The main drawback of polling is that it consumes CPU resources. In order to
>>> benefit performance the host must have extra CPU cycles available on physical
>>> CPUs that aren't used by the guest.
>>>
>>> This is an experimental AioContext polling implementation. It adds a polling
>>> callback into the event loop. Polling functions are implemented for virtio-blk
>>> virtqueue guest->host kick and Linux AIO completion.
>>>
>>> The QEMU_AIO_POLL_MAX_NS environment variable sets the number of nanoseconds to
>>> poll before entering the usual blocking poll(2) syscall. Try setting this
>>> variable to the time from old request completion to new virtqueue kick.
>>>
>>> By default no polling is done. The QEMU_AIO_POLL_MAX_NS must be set to get any
>>> polling!
>>>
>>> Karl: I hope you can try this patch series with several QEMU_AIO_POLL_MAX_NS
>>> values. If you don't find a good value we should double-check the tracing data
>>> to see if this experimental code can be improved.
>>
>> Stefan
>>
>> I ran some quick tests with your patches and got some pretty good gains,
>> but also some seemingly odd behavior.
>>
>> These results are for a 5 minute test doing sequential 4KB requests from
>> fio using O_DIRECT, libaio, and IO depth of 1. The requests are
>> performed directly against the virtio-blk device (no filesystem) which
>> is backed by a 400GB NVme card.
>>
>> QEMU_AIO_POLL_MAX_NS IOPs
>> unset 31,383
>> 1 46,860
>> 2 46,440
>> 4 35,246
>> 8 34,973
>> 16 46,794
>> 32 46,729
>> 64 35,520
>> 128 45,902
>
> The environment variable is in nanoseconds. The range of values you
> tried are very small (all <1 usec). It would be interesting to try
> larger values in the ballpark of the latencies you have traced. For
> example 2000, 4000, 8000, 16000, and 32000 ns.
Here are some more numbers with higher values. I continued the power of
2 values and added in your examples as well:
QEMU_AIO_POLL_MAX_NS IOPs
256 46,929
512 35,627
1,024 46,477
2,000 35,247
2,048 46,322
4,000 46,540
4,096 46,368
8,000 47,054
8,192 46,671
16,000 46,466
16,384 32,504
32,000 20,620
32,768 20,807
>
> Very interesting that QEMU_AIO_POLL_MAX_NS=1 performs so well without
> much CPU overhead.
>
>> I found the results for 4, 8, and 64 odd so I re-ran some tests to check
>> for consistency. I used values of 2 and 4 and ran each 5 times. Here
>> is what I got:
>>
>> Iteration QEMU_AIO_POLL_MAX_NS=2 QEMU_AIO_POLL_MAX_NS=4
>> 1 46,972 35,434
>> 2 46,939 35,719
>> 3 47,005 35,584
>> 4 47,016 35,615
>> 5 47,267 35,474
>>
>> So the results seem consistent.
>
> That is interesting. I don't have an explanation for the consistent
> difference between 2 and 4 ns polling time. The time difference is so
> small yet the IOPS difference is clear.
>
> Comparing traces could shed light on the cause for this difference.
>
>> I saw some discussion on the patches made which make me think you'll be
>> making some changes, is that right? If so, I may wait for the updates
>> and then we can run the much more exhaustive set of workloads
>> (sequential read and write, random read and write) at various block
>> sizes (4, 8, 16, 32, 64, 128, and 256) and multiple IO depths (1 and 32)
>> that we were doing when we started looking at this.
>
> I'll send an updated version of the patches.
>
> Stefan
>
--
Karl Rister <krister@redhat.com>
^ permalink raw reply
* RE: [PATCH 2/2] drm/amd/amdgpu: Tidy up formatting in si_enums.h
From: Deucher, Alexander @ 2016-11-14 20:12 UTC (permalink / raw)
To: 'Tom St Denis',
amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
Cc: StDenis, Tom
In-Reply-To: <20161114185746.18225-2-tom.stdenis-5C7GfCeVMHo@public.gmane.org>
> -----Original Message-----
> From: amd-gfx [mailto:amd-gfx-bounces@lists.freedesktop.org] On Behalf
> Of Tom St Denis
> Sent: Monday, November 14, 2016 1:58 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: StDenis, Tom
> Subject: [PATCH 2/2] drm/amd/amdgpu: Tidy up formatting in si_enums.h
>
> Clean up formatting/alignment in si_enums.h to make it
> more presentable.
>
> Signed-off-by: Tom St Denis <tom.stdenis@amd.com>
NACK on this one. It makes it harder to see which defines are related to which packets.
Alex
> ---
> drivers/gpu/drm/amd/amdgpu/si_enums.h | 241 +++++++++++++++++-----
> ------------
> 1 file changed, 121 insertions(+), 120 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/si_enums.h
> b/drivers/gpu/drm/amd/amdgpu/si_enums.h
> index fde2086246fa..8fd54f6cd4f0 100644
> --- a/drivers/gpu/drm/amd/amdgpu/si_enums.h
> +++ b/drivers/gpu/drm/amd/amdgpu/si_enums.h
> @@ -146,127 +146,128 @@
> #define VERDE_GB_ADDR_CONFIG_GOLDEN 0x12010002
> #define HAINAN_GB_ADDR_CONFIG_GOLDEN 0x02010001
>
> -#define PACKET3(op, n) ((RADEON_PACKET_TYPE3 << 30) | \
> - (((op) & 0xFF) << 8) | \
> +#define PACKET3(op, n) ((RADEON_PACKET_TYPE3 << 30) | \
> + (((op) & 0xFF) << 8) | \
> ((n) & 0x3FFF) << 16)
> +
> #define PACKET3_COMPUTE(op, n) (PACKET3(op, n) | 1 << 1)
> -#define PACKET3_NOP 0x10
> -#define PACKET3_SET_BASE 0x11
> -#define PACKET3_BASE_INDEX(x) ((x) << 0)
> -#define PACKET3_CLEAR_STATE 0x12
> -#define PACKET3_INDEX_BUFFER_SIZE 0x13
> -#define PACKET3_DISPATCH_DIRECT 0x15
> -#define PACKET3_DISPATCH_INDIRECT 0x16
> -#define PACKET3_ALLOC_GDS 0x1B
> -#define PACKET3_WRITE_GDS_RAM 0x1C
> -#define PACKET3_ATOMIC_GDS 0x1D
> -#define PACKET3_ATOMIC 0x1E
> -#define PACKET3_OCCLUSION_QUERY 0x1F
> -#define PACKET3_SET_PREDICATION 0x20
> -#define PACKET3_REG_RMW 0x21
> -#define PACKET3_COND_EXEC 0x22
> -#define PACKET3_PRED_EXEC 0x23
> -#define PACKET3_DRAW_INDIRECT 0x24
> -#define PACKET3_DRAW_INDEX_INDIRECT 0x25
> -#define PACKET3_INDEX_BASE 0x26
> -#define PACKET3_DRAW_INDEX_2 0x27
> -#define PACKET3_CONTEXT_CONTROL 0x28
> -#define PACKET3_INDEX_TYPE 0x2A
> -#define PACKET3_DRAW_INDIRECT_MULTI 0x2C
> -#define PACKET3_DRAW_INDEX_AUTO
> 0x2D
> -#define PACKET3_DRAW_INDEX_IMMD
> 0x2E
> -#define PACKET3_NUM_INSTANCES 0x2F
> -#define PACKET3_DRAW_INDEX_MULTI_AUTO
> 0x30
> -#define PACKET3_INDIRECT_BUFFER_CONST 0x31
> -#define PACKET3_INDIRECT_BUFFER 0x3F
> -#define PACKET3_STRMOUT_BUFFER_UPDATE 0x34
> -#define PACKET3_DRAW_INDEX_OFFSET_2 0x35
> -#define PACKET3_DRAW_INDEX_MULTI_ELEMENT 0x36
> -#define PACKET3_WRITE_DATA 0x37
> -#define PACKET3_DRAW_INDEX_INDIRECT_MULTI 0x38
> -#define PACKET3_MEM_SEMAPHORE 0x39
> -#define PACKET3_MPEG_INDEX 0x3A
> -#define PACKET3_COPY_DW 0x3B
> -#define PACKET3_WAIT_REG_MEM 0x3C
> -#define PACKET3_MEM_WRITE 0x3D
> -#define PACKET3_COPY_DATA 0x40
> -#define PACKET3_CP_DMA 0x41
> -# define PACKET3_CP_DMA_DST_SEL(x) ((x) << 20)
> -# define PACKET3_CP_DMA_ENGINE(x) ((x) << 27)
> -# define PACKET3_CP_DMA_SRC_SEL(x) ((x) << 29)
> -# define PACKET3_CP_DMA_CP_SYNC (1 << 31)
> -# define PACKET3_CP_DMA_DIS_WC (1 << 21)
> -# define PACKET3_CP_DMA_CMD_SRC_SWAP(x) ((x) << 22)
> -# define PACKET3_CP_DMA_CMD_DST_SWAP(x) ((x) << 24)
> -# define PACKET3_CP_DMA_CMD_SAS (1 << 26)
> -# define PACKET3_CP_DMA_CMD_DAS (1 << 27)
> -# define PACKET3_CP_DMA_CMD_SAIC (1 << 28)
> -# define PACKET3_CP_DMA_CMD_DAIC (1 << 29)
> -# define PACKET3_CP_DMA_CMD_RAW_WAIT (1 << 30)
> -#define PACKET3_PFP_SYNC_ME 0x42
> -#define PACKET3_SURFACE_SYNC 0x43
> -# define PACKET3_DEST_BASE_0_ENA (1 << 0)
> -# define PACKET3_DEST_BASE_1_ENA (1 << 1)
> -# define PACKET3_CB0_DEST_BASE_ENA (1 << 6)
> -# define PACKET3_CB1_DEST_BASE_ENA (1 << 7)
> -# define PACKET3_CB2_DEST_BASE_ENA (1 << 8)
> -# define PACKET3_CB3_DEST_BASE_ENA (1 << 9)
> -# define PACKET3_CB4_DEST_BASE_ENA (1 << 10)
> -# define PACKET3_CB5_DEST_BASE_ENA (1 << 11)
> -# define PACKET3_CB6_DEST_BASE_ENA (1 << 12)
> -# define PACKET3_CB7_DEST_BASE_ENA (1 << 13)
> -# define PACKET3_DB_DEST_BASE_ENA (1 << 14)
> -# define PACKET3_DEST_BASE_2_ENA (1 << 19)
> -# define PACKET3_DEST_BASE_3_ENA (1 << 21)
> -# define PACKET3_TCL1_ACTION_ENA (1 << 22)
> -# define PACKET3_TC_ACTION_ENA (1 << 23)
> -# define PACKET3_CB_ACTION_ENA (1 << 25)
> -# define PACKET3_DB_ACTION_ENA (1 << 26)
> -# define PACKET3_SH_KCACHE_ACTION_ENA (1 << 27)
> -# define PACKET3_SH_ICACHE_ACTION_ENA (1 << 29)
> -#define PACKET3_ME_INITIALIZE 0x44
> -#define PACKET3_ME_INITIALIZE_DEVICE_ID(x) ((x) << 16)
> -#define PACKET3_COND_WRITE 0x45
> -#define PACKET3_EVENT_WRITE 0x46
> -#define PACKET3_EVENT_WRITE_EOP 0x47
> -#define PACKET3_EVENT_WRITE_EOS 0x48
> -#define PACKET3_PREAMBLE_CNTL 0x4A
> -# define PACKET3_PREAMBLE_BEGIN_CLEAR_STATE (2 << 28)
> -# define PACKET3_PREAMBLE_END_CLEAR_STATE (3 << 28)
> -#define PACKET3_ONE_REG_WRITE 0x57
> -#define PACKET3_LOAD_CONFIG_REG 0x5F
> -#define PACKET3_LOAD_CONTEXT_REG 0x60
> -#define PACKET3_LOAD_SH_REG 0x61
> -#define PACKET3_SET_CONFIG_REG 0x68
> -#define PACKET3_SET_CONFIG_REG_START
> 0x00002000
> -#define PACKET3_SET_CONFIG_REG_END
> 0x00002c00
> -#define PACKET3_SET_CONTEXT_REG 0x69
> -#define PACKET3_SET_CONTEXT_REG_START
> 0x000a000
> -#define PACKET3_SET_CONTEXT_REG_END
> 0x000a400
> -#define PACKET3_SET_CONTEXT_REG_INDIRECT 0x73
> -#define PACKET3_SET_RESOURCE_INDIRECT 0x74
> -#define PACKET3_SET_SH_REG 0x76
> -#define PACKET3_SET_SH_REG_START
> 0x00002c00
> -#define PACKET3_SET_SH_REG_END
> 0x00003000
> -#define PACKET3_SET_SH_REG_OFFSET 0x77
> -#define PACKET3_ME_WRITE 0x7A
> -#define PACKET3_SCRATCH_RAM_WRITE 0x7D
> -#define PACKET3_SCRATCH_RAM_READ 0x7E
> -#define PACKET3_CE_WRITE 0x7F
> -#define PACKET3_LOAD_CONST_RAM 0x80
> -#define PACKET3_WRITE_CONST_RAM 0x81
> -#define PACKET3_WRITE_CONST_RAM_OFFSET
> 0x82
> -#define PACKET3_DUMP_CONST_RAM 0x83
> -#define PACKET3_INCREMENT_CE_COUNTER 0x84
> -#define PACKET3_INCREMENT_DE_COUNTER 0x85
> -#define PACKET3_WAIT_ON_CE_COUNTER 0x86
> -#define PACKET3_WAIT_ON_DE_COUNTER 0x87
> -#define PACKET3_WAIT_ON_DE_COUNTER_DIFF
> 0x88
> -#define PACKET3_SET_CE_DE_COUNTERS 0x89
> -#define PACKET3_WAIT_ON_AVAIL_BUFFER 0x8A
> -#define PACKET3_SWITCH_BUFFER 0x8B
> -#define PACKET3_SEM_WAIT_ON_SIGNAL (0x1 << 12)
> -#define PACKET3_SEM_SEL_SIGNAL (0x6 << 29)
> -#define PACKET3_SEM_SEL_WAIT (0x7 << 29)
> +#define PACKET3_NOP 0x10
> +#define PACKET3_SET_BASE 0x11
> +#define PACKET3_BASE_INDEX(x) ((x) << 0)
> +#define PACKET3_CLEAR_STATE 0x12
> +#define PACKET3_INDEX_BUFFER_SIZE 0x13
> +#define PACKET3_DISPATCH_DIRECT 0x15
> +#define PACKET3_DISPATCH_INDIRECT 0x16
> +#define PACKET3_ALLOC_GDS 0x1B
> +#define PACKET3_WRITE_GDS_RAM 0x1C
> +#define PACKET3_ATOMIC_GDS 0x1D
> +#define PACKET3_ATOMIC 0x1E
> +#define PACKET3_OCCLUSION_QUERY 0x1F
> +#define PACKET3_SET_PREDICATION 0x20
> +#define PACKET3_REG_RMW 0x21
> +#define PACKET3_COND_EXEC 0x22
> +#define PACKET3_PRED_EXEC 0x23
> +#define PACKET3_DRAW_INDIRECT 0x24
> +#define PACKET3_DRAW_INDEX_INDIRECT 0x25
> +#define PACKET3_INDEX_BASE 0x26
> +#define PACKET3_DRAW_INDEX_2 0x27
> +#define PACKET3_CONTEXT_CONTROL 0x28
> +#define PACKET3_INDEX_TYPE 0x2A
> +#define PACKET3_DRAW_INDIRECT_MULTI 0x2C
> +#define PACKET3_DRAW_INDEX_AUTO 0x2D
> +#define PACKET3_DRAW_INDEX_IMMD 0x2E
> +#define PACKET3_NUM_INSTANCES 0x2F
> +#define PACKET3_DRAW_INDEX_MULTI_AUTO 0x30
> +#define PACKET3_INDIRECT_BUFFER_CONST 0x31
> +#define PACKET3_INDIRECT_BUFFER 0x3F
> +#define PACKET3_STRMOUT_BUFFER_UPDATE 0x34
> +#define PACKET3_DRAW_INDEX_OFFSET_2 0x35
> +#define PACKET3_DRAW_INDEX_MULTI_ELEMENT 0x36
> +#define PACKET3_WRITE_DATA 0x37
> +#define PACKET3_DRAW_INDEX_INDIRECT_MULTI 0x38
> +#define PACKET3_MEM_SEMAPHORE 0x39
> +#define PACKET3_MPEG_INDEX 0x3A
> +#define PACKET3_COPY_DW 0x3B
> +#define PACKET3_WAIT_REG_MEM 0x3C
> +#define PACKET3_MEM_WRITE 0x3D
> +#define PACKET3_COPY_DATA 0x40
> +#define PACKET3_CP_DMA 0x41
> +#define PACKET3_CP_DMA_DST_SEL(x) ((x) << 20)
> +#define PACKET3_CP_DMA_ENGINE(x) ((x) << 27)
> +#define PACKET3_CP_DMA_SRC_SEL(x) ((x) << 29)
> +#define PACKET3_CP_DMA_CP_SYNC (1 << 31)
> +#define PACKET3_CP_DMA_DIS_WC (1 << 21)
> +#define PACKET3_CP_DMA_CMD_SRC_SWAP(x) ((x) << 22)
> +#define PACKET3_CP_DMA_CMD_DST_SWAP(x) ((x) << 24)
> +#define PACKET3_CP_DMA_CMD_SAS (1 << 26)
> +#define PACKET3_CP_DMA_CMD_DAS (1 << 27)
> +#define PACKET3_CP_DMA_CMD_SAIC (1 << 28)
> +#define PACKET3_CP_DMA_CMD_DAIC (1 << 29)
> +#define PACKET3_CP_DMA_CMD_RAW_WAIT (1 << 30)
> +#define PACKET3_PFP_SYNC_ME 0x42
> +#define PACKET3_SURFACE_SYNC 0x43
> +#define PACKET3_DEST_BASE_0_ENA (1 << 0)
> +#define PACKET3_DEST_BASE_1_ENA (1 << 1)
> +#define PACKET3_CB0_DEST_BASE_ENA (1 << 6)
> +#define PACKET3_CB1_DEST_BASE_ENA (1 << 7)
> +#define PACKET3_CB2_DEST_BASE_ENA (1 << 8)
> +#define PACKET3_CB3_DEST_BASE_ENA (1 << 9)
> +#define PACKET3_CB4_DEST_BASE_ENA (1 << 10)
> +#define PACKET3_CB5_DEST_BASE_ENA (1 << 11)
> +#define PACKET3_CB6_DEST_BASE_ENA (1 << 12)
> +#define PACKET3_CB7_DEST_BASE_ENA (1 << 13)
> +#define PACKET3_DB_DEST_BASE_ENA (1 << 14)
> +#define PACKET3_DEST_BASE_2_ENA (1 << 19)
> +#define PACKET3_DEST_BASE_3_ENA (1 << 21)
> +#define PACKET3_TCL1_ACTION_ENA (1 << 22)
> +#define PACKET3_TC_ACTION_ENA (1 << 23)
> +#define PACKET3_CB_ACTION_ENA (1 << 25)
> +#define PACKET3_DB_ACTION_ENA (1 << 26)
> +#define PACKET3_SH_KCACHE_ACTION_ENA (1 << 27)
> +#define PACKET3_SH_ICACHE_ACTION_ENA (1 << 29)
> +#define PACKET3_ME_INITIALIZE 0x44
> +#define PACKET3_ME_INITIALIZE_DEVICE_ID(x) ((x) << 16)
> +#define PACKET3_COND_WRITE 0x45
> +#define PACKET3_EVENT_WRITE 0x46
> +#define PACKET3_EVENT_WRITE_EOP 0x47
> +#define PACKET3_EVENT_WRITE_EOS 0x48
> +#define PACKET3_PREAMBLE_CNTL 0x4A
> +#define PACKET3_PREAMBLE_BEGIN_CLEAR_STATE (2 << 28)
> +#define PACKET3_PREAMBLE_END_CLEAR_STATE (3 << 28)
> +#define PACKET3_ONE_REG_WRITE 0x57
> +#define PACKET3_LOAD_CONFIG_REG 0x5F
> +#define PACKET3_LOAD_CONTEXT_REG 0x60
> +#define PACKET3_LOAD_SH_REG 0x61
> +#define PACKET3_SET_CONFIG_REG 0x68
> +#define PACKET3_SET_CONFIG_REG_START 0x00002000
> +#define PACKET3_SET_CONFIG_REG_END 0x00002c00
> +#define PACKET3_SET_CONTEXT_REG 0x69
> +#define PACKET3_SET_CONTEXT_REG_START 0x000a000
> +#define PACKET3_SET_CONTEXT_REG_END 0x000a400
> +#define PACKET3_SET_CONTEXT_REG_INDIRECT 0x73
> +#define PACKET3_SET_RESOURCE_INDIRECT 0x74
> +#define PACKET3_SET_SH_REG 0x76
> +#define PACKET3_SET_SH_REG_START 0x00002c00
> +#define PACKET3_SET_SH_REG_END 0x00003000
> +#define PACKET3_SET_SH_REG_OFFSET 0x77
> +#define PACKET3_ME_WRITE 0x7A
> +#define PACKET3_SCRATCH_RAM_WRITE 0x7D
> +#define PACKET3_SCRATCH_RAM_READ 0x7E
> +#define PACKET3_CE_WRITE 0x7F
> +#define PACKET3_LOAD_CONST_RAM 0x80
> +#define PACKET3_WRITE_CONST_RAM 0x81
> +#define PACKET3_WRITE_CONST_RAM_OFFSET 0x82
> +#define PACKET3_DUMP_CONST_RAM 0x83
> +#define PACKET3_INCREMENT_CE_COUNTER 0x84
> +#define PACKET3_INCREMENT_DE_COUNTER 0x85
> +#define PACKET3_WAIT_ON_CE_COUNTER 0x86
> +#define PACKET3_WAIT_ON_DE_COUNTER 0x87
> +#define PACKET3_WAIT_ON_DE_COUNTER_DIFF 0x88
> +#define PACKET3_SET_CE_DE_COUNTERS 0x89
> +#define PACKET3_WAIT_ON_AVAIL_BUFFER 0x8A
> +#define PACKET3_SWITCH_BUFFER 0x8B
> +#define PACKET3_SEM_WAIT_ON_SIGNAL (0x1 << 12)
> +#define PACKET3_SEM_SEL_SIGNAL (0x6 << 29)
> +#define PACKET3_SEM_SEL_WAIT (0x7 << 29)
>
> #endif
> --
> 2.10.0
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply
* [U-Boot] [PATCH RESEND 6/9] eeprom: Add DS2431 support
From: Maxime Ripard @ 2016-11-14 20:12 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20161114151457.GG27304@bill-the-cat>
On Mon, Nov 14, 2016 at 10:14:57AM -0500, Tom Rini wrote:
> On Mon, Nov 14, 2016 at 02:42:59PM +0100, Maxime Ripard wrote:
> > Hi,
> >
> > On Fri, Nov 11, 2016 at 11:16:39AM -0800, Moritz Fischer wrote:
> > > > +U_BOOT_DRIVER(ds2431) = {
> > > > + .name = "ds2431",
> > > > + .id = UCLASS_EEPROM,
> > > > + .ops = &ds2431_ops,
> > >
> > > Do you want to add a .flags = DM_UC_FLAG_SEQ_ALIAS here?
> >
> > I don't know. I was kind of wondering why U-Boot relies on aliases so
> > much, especially when the Linux DT maintainers are saying that aliases
> > should be avoided entirely, and we'll won't be able to upstream those
> > changes.
>
> Bah. Do you have a pointer to some discussion about this handy?
Rob said this multiple times, but here is an example:
http://lkml.iu.edu/hypermail/linux/kernel/1609.1/00653.html
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161114/a0ffdcc3/attachment.sig>
^ 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.