* Tegra baseline test results for v4.11-rc8
From: Jon Hunter @ 2017-04-25 12:06 UTC (permalink / raw)
To: linux-arm-kernel
Here are some basic Tegra test results for Linux v4.11-rc8.
Logs and other details at:
https://nvtb.github.io//linux/test_v4.11-rc8/20170423173102/
Test summary
------------
Build: zImage:
Pass: ( 2/ 2): multi_v7_defconfig, tegra_defconfig
Build: Image:
Pass: ( 1/ 1): defconfig
Boot to userspace: defconfig:
Pass: ( 4/ 4): qemu-vexpress64, tegra132-norrin,
tegra210-p2371-0000, tegra210-smaug
Boot to userspace: multi_v7_defconfig:
Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
Boot to userspace: tegra_defconfig:
Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
PM: System suspend: multi_v7_defconfig:
Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
PM: System suspend: tegra_defconfig:
Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
vmlinux object size
(delta in bytes from test_v4.11-rc7 (4f7d029b9bf009fbee76bb10c0c4351a1870d2f3)):
text data bss total kernel
-268 +264 0 -4 defconfig
+896 +64 0 +960 multi_v7_defconfig
+428 0 0 +428 tegra_defconfig
Boot-time memory difference
(delta in bytes from test_v4.11-rc7 (4f7d029b9bf009fbee76bb10c0c4351a1870d2f3))
avail rsrvd high freed board kconfig dtb
. . . . qemu-vexpress64 defconfig __internal
. . . . tegra114-dalmore-a04 multi_v7_defconfig tegra114-dalmore
. . . . tegra114-dalmore-a04 tegra_defconfig tegra114-dalmore
. . . . tegra124-jetson-tk1 multi_v7_defconfig tegra124-jetson-tk1
. . . . tegra124-jetson-tk1 tegra_defconfig tegra124-jetson-tk1
. . . . tegra124-nyan-big multi_v7_defconfig tegra124-nyan-big
. . . . tegra124-nyan-big tegra_defconfig tegra124-nyan-big
. . . . tegra132-norrin defconfig tegra132-norrin
. . . . tegra20-trimslice multi_v7_defconfig tegra20-trimslice
. . . . tegra20-trimslice tegra_defconfig tegra20-trimslice
. . . . tegra210-p2371-0000 defconfig tegra210-p2371-0000
. . . . tegra210-smaug defconfig tegra210-smaug
. . . . tegra30-beaver multi_v7_defconfig tegra30-beaver
. . . . tegra30-beaver tegra_defconfig tegra30-beaver
--
nvpublic
^ permalink raw reply
* Tegra baseline test results for v4.11-rc7
From: Jon Hunter @ 2017-04-25 12:05 UTC (permalink / raw)
To: linux-arm-kernel
Here are some basic Tegra test results for Linux v4.11-rc7.
Logs and other details at:
https://nvtb.github.io//linux/test_v4.11-rc7/20170416133103/
Test summary
------------
Build: zImage:
Pass: ( 2/ 2): multi_v7_defconfig, tegra_defconfig
Build: Image:
Pass: ( 1/ 1): defconfig
Boot to userspace: defconfig:
Pass: ( 4/ 4): qemu-vexpress64, tegra132-norrin,
tegra210-p2371-0000, tegra210-smaug
Boot to userspace: multi_v7_defconfig:
Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
Boot to userspace: tegra_defconfig:
Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
PM: System suspend: multi_v7_defconfig:
Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
PM: System suspend: tegra_defconfig:
Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
vmlinux object size
(delta in bytes from test_v4.11-rc6 (39da7c509acff13fc8cb12ec1bb20337c988ed36)):
text data bss total kernel
+7674 +560 0 +8234 defconfig
+3046 0 0 +3046 multi_v7_defconfig
+1378 0 0 +1378 tegra_defconfig
Boot-time memory difference
(delta in bytes from test_v4.11-rc6 (39da7c509acff13fc8cb12ec1bb20337c988ed36))
avail rsrvd high freed board kconfig dtb
. . . . qemu-vexpress64 defconfig __internal
. . . . tegra114-dalmore-a04 multi_v7_defconfig tegra114-dalmore
. . . . tegra114-dalmore-a04 tegra_defconfig tegra114-dalmore
. . . . tegra124-jetson-tk1 multi_v7_defconfig tegra124-jetson-tk1
. . . . tegra124-jetson-tk1 tegra_defconfig tegra124-jetson-tk1
. . . . tegra124-nyan-big multi_v7_defconfig tegra124-nyan-big
. . . . tegra124-nyan-big tegra_defconfig tegra124-nyan-big
. . . . tegra132-norrin defconfig tegra132-norrin
. . . . tegra20-trimslice multi_v7_defconfig tegra20-trimslice
. . . . tegra20-trimslice tegra_defconfig tegra20-trimslice
. . . . tegra210-p2371-0000 defconfig tegra210-p2371-0000
. . . . tegra210-smaug defconfig tegra210-smaug
. . . . tegra30-beaver multi_v7_defconfig tegra30-beaver
. . . . tegra30-beaver tegra_defconfig tegra30-beaver
--
nvpublic
^ permalink raw reply
* Tegra baseline test results for v4.11-rc6
From: Jon Hunter @ 2017-04-25 12:03 UTC (permalink / raw)
To: linux-arm-kernel
Here are some basic Tegra test results for Linux v4.11-rc6.
Logs and other details at:
https://nvtb.github.io//linux/test_v4.11-rc6/20170411053103/
Test summary
------------
Build: zImage:
Pass: ( 2/ 2): multi_v7_defconfig, tegra_defconfig
Build: Image:
Pass: ( 1/ 1): defconfig
Boot to userspace: defconfig:
Pass: ( 4/ 4): qemu-vexpress64, tegra132-norrin,
tegra210-p2371-0000, tegra210-smaug
Boot to userspace: multi_v7_defconfig:
Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
Boot to userspace: tegra_defconfig:
Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
PM: System suspend: multi_v7_defconfig:
Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
PM: System suspend: tegra_defconfig:
FAIL: ( 1/ 5): tegra124-nyan-big
Pass: ( 4/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra20-trimslice, tegra30-beaver
vmlinux object size
(delta in bytes from test_v4.11-rc5 (a71c9a1c779f2499fb2afc0553e543f18aff6edf)):
text data bss total kernel
-2667 +952 -128 -1843 defconfig
-647 0 0 -647 multi_v7_defconfig
-791 +64 0 -727 tegra_defconfig
Boot-time memory difference
(delta in bytes from test_v4.11-rc5 (a71c9a1c779f2499fb2afc0553e543f18aff6edf))
avail rsrvd high freed board kconfig dtb
. . . . qemu-vexpress64 defconfig __internal
. . . . tegra114-dalmore-a04 multi_v7_defconfig tegra114-dalmore
. . . . tegra114-dalmore-a04 tegra_defconfig tegra114-dalmore
. . . . tegra124-jetson-tk1 multi_v7_defconfig tegra124-jetson-tk1
. . . . tegra124-jetson-tk1 tegra_defconfig tegra124-jetson-tk1
. . . . tegra124-nyan-big multi_v7_defconfig tegra124-nyan-big
. . . . tegra124-nyan-big tegra_defconfig tegra124-nyan-big
. . . . tegra132-norrin defconfig tegra132-norrin
. . . . tegra20-trimslice multi_v7_defconfig tegra20-trimslice
. . . . tegra20-trimslice tegra_defconfig tegra20-trimslice
. . . . tegra210-p2371-0000 defconfig tegra210-p2371-0000
. . . . tegra210-smaug defconfig tegra210-smaug
. . . . tegra30-beaver multi_v7_defconfig tegra30-beaver
. . . . tegra30-beaver tegra_defconfig tegra30-beaver
--
nvpublic
^ permalink raw reply
* support autofocus / autogain in libv4l2
From: Pali Rohár @ 2017-04-25 11:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170425112330.GB7926@amd>
On Tuesday 25 April 2017 13:23:30 Pavel Machek wrote:
> Hi!
> On Tue 2017-04-25 10:08:15, Pali Roh?r wrote:
> > On Tuesday 25 April 2017 10:05:38 Pavel Machek wrote:
> > > > > It would be nice if more than one application could be accessing the
> > > > > camera at the same time... (I.e. something graphical running preview
> > > > > then using command line tool to grab a picture.) This one is
> > > > > definitely not solveable inside a library...
> > > >
> > > > Someone once suggested to have something like pulseaudio for V4L.
> > > > For such usage, a server would be interesting. Yet, I would code it
> > > > in a way that applications using libv4l will talk with such daemon
> > > > in a transparent way.
> > >
> > > Yes, we need something like pulseaudio for V4L. And yes, we should
> > > make it transparent for applications using libv4l.
> >
> > IIRC there is already some effort in writing such "video" server which
> > would support accessing more application into webcam video, like
> > pulseaudio server for accessing more applications to microphone input.
>
> Do you have project name / url / something?
Pinos (renamed from PulseVideo)
https://blogs.gnome.org/uraeus/2015/06/30/introducing-pulse-video/
https://cgit.freedesktop.org/~wtay/pinos/
But from git history it looks like it is probably dead now...
--
Pali Roh?r
pali.rohar at gmail.com
^ permalink raw reply
* support autofocus / autogain in libv4l2
From: Pavel Machek @ 2017-04-25 11:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170425080815.GD30553@pali>
Hi!
On Tue 2017-04-25 10:08:15, Pali Roh?r wrote:
> On Tuesday 25 April 2017 10:05:38 Pavel Machek wrote:
> > > > It would be nice if more than one application could be accessing the
> > > > camera at the same time... (I.e. something graphical running preview
> > > > then using command line tool to grab a picture.) This one is
> > > > definitely not solveable inside a library...
> > >
> > > Someone once suggested to have something like pulseaudio for V4L.
> > > For such usage, a server would be interesting. Yet, I would code it
> > > in a way that applications using libv4l will talk with such daemon
> > > in a transparent way.
> >
> > Yes, we need something like pulseaudio for V4L. And yes, we should
> > make it transparent for applications using libv4l.
>
> IIRC there is already some effort in writing such "video" server which
> would support accessing more application into webcam video, like
> pulseaudio server for accessing more applications to microphone input.
Do you have project name / url / something?
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170425/b6562bbd/attachment.sig>
^ permalink raw reply
* support autofocus / autogain in libv4l2
From: Pavel Machek @ 2017-04-25 11:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424225731.7532e368@vento.lan>
Hi!
> > Umm, and it looks like libv4l can not automatically convert from
> > GRBG10.. and if it could, going through RGB24 would probably be too
> > slow on this device :-(.
>
> I suspect it shouldn't be hard to add support for GRBG10. It already
> supports 8 and 16 bits Bayer formats, at lib/libv4lconvert/bayer.c
> (to both RGB and YUV formats).
Proper format for 16 bit bayer would be tricky, AFAICT. Anyway, does
this look reasonable? It does not work too well here, since omap3isp
driver does not seem to support ENUM_FMT. (And I get just half of the
vertical image, strange. Interlacing?)
Best regards,
Pavel
diff --git a/lib/libv4lconvert/libv4lconvert.c b/lib/libv4lconvert/libv4lconvert.c
index d3d8936..2a469b2 100644
--- a/lib/libv4lconvert/libv4lconvert.c
+++ b/lib/libv4lconvert/libv4lconvert.c
@@ -123,6 +126,8 @@ static const struct v4lconvert_pixfmt supported_src_pixfmts[] = {
{ V4L2_PIX_FMT_SGRBG8, 8, 8, 8, 1 },
{ V4L2_PIX_FMT_SRGGB8, 8, 8, 8, 1 },
{ V4L2_PIX_FMT_STV0680, 8, 8, 8, 1 },
+
+ { V4L2_PIX_FMT_SGRBG10, 16, 8, 8, 1 },
/* compressed bayer */
{ V4L2_PIX_FMT_SPCA561, 0, 9, 9, 1 },
{ V4L2_PIX_FMT_SN9C10X, 0, 9, 9, 1 },
@@ -668,6 +680,7 @@ static int v4lconvert_processing_needs_double_conversion(
case V4L2_PIX_FMT_SGRBG8:
case V4L2_PIX_FMT_SRGGB8:
case V4L2_PIX_FMT_STV0680:
+ case V4L2_PIX_FMT_SGRBG10:
return 0;
}
switch (dest_pix_fmt) {
@@ -694,6 +707,17 @@ unsigned char *v4lconvert_alloc_buffer(int needed,
return *buf;
}
+static void v4lconvert_10to8(void *_src, unsigned char *dst, int width, int height)
+{
+ int i;
+ uint16_t *src = _src;
+
+ printf("sizes %d x %d\n", width, height);
+ for (i=0; i<width*height; i++) {
+ dst[i] = src[i] >> 2;
+ }
+}
+
int v4lconvert_oom_error(struct v4lconvert_data *data)
{
V4LCONVERT_ERR("could not allocate memory\n");
@@ -867,7 +893,8 @@ static int v4lconvert_convert_pixfmt(struct v4lconvert_data *data,
#endif
case V4L2_PIX_FMT_SN9C2028:
case V4L2_PIX_FMT_SQ905C:
- case V4L2_PIX_FMT_STV0680: { /* Not compressed but needs some shuffling */
+ case V4L2_PIX_FMT_STV0680:
+ case V4L2_PIX_FMT_SGRBG10: { /* Not compressed but needs some shuffling */
unsigned char *tmpbuf;
struct v4l2_format tmpfmt = *fmt;
@@ -877,6 +904,11 @@ static int v4lconvert_convert_pixfmt(struct v4lconvert_data *data,
return v4lconvert_oom_error(data);
switch (src_pix_fmt) {
+ case V4L2_PIX_FMT_SGRBG10:
+ v4lconvert_10to8(src, tmpbuf, width, height);
+
+ tmpfmt.fmt.pix.pixelformat = V4L2_PIX_FMT_SGRBG8;
+ break;
case V4L2_PIX_FMT_SPCA561:
v4lconvert_decode_spca561(src, tmpbuf, width, height);
tmpfmt.fmt.pix.pixelformat = V4L2_PIX_FMT_SGBRG8;
@@ -949,6 +981,7 @@ static int v4lconvert_convert_pixfmt(struct v4lconvert_data *data,
V4LCONVERT_ERR("short raw bayer data frame\n");
errno = EPIPE;
result = -1;
+ /* FIXME: but then we proceed anyway?! */
}
switch (dest_pix_fmt) {
case V4L2_PIX_FMT_RGB24:
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170425/a03b799f/attachment-0001.sig>
^ permalink raw reply related
* Touchscreen failure with CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND
From: Viresh Kumar @ 2017-04-25 11:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5BgjgxGhJ7zGV-gjs0QHmJMgkNryFqTYA=vGPz8KWDijg@mail.gmail.com>
On 25-04-17, 08:09, Fabio Estevam wrote:
> Hi Viresh,
>
> On Tue, Apr 25, 2017 at 2:06 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
>
> > Honestly, I don't have a clue on how can we fix it for you now :)
> >
> > @Rafael: Any idea apart from running at max all the time?
> >
> > what touchscreen driver are you using btw? Just curious to see if there is any
> > bug in there. Handling touchscreen events shouldn't require us to run at max
> > freq.
>
> imx6q-sabresd board uses a drivers/input/touchscreen/egalax_ts.c touchscreen.
>
> >
> > @shawn: Saw something similar ever ?
>
> I do not see the problem with the NXP kernel, but was not able to
> identify what makes the touchscreen not to fail at 396MHz in their
> kernel.
@Shawn/Sascha: Can you guys help here? This looks to be some imx
specific stuff now.
--
viresh
^ permalink raw reply
* [RFC] usb: chipidea: set dma_ops for the created ci_hdrc platform_device
From: Arnd Bergmann @ 2017-04-25 11:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170425180151.0f03ca0e@xhacker>
On Tue, Apr 25, 2017 at 12:01 PM, Jisheng Zhang <jszhang@marvell.com> wrote:
> Hi all,
>
> After commit 1dccb598df549 ("arm64: simplify dma_get_ops"), the chipidea
> driver can't work any more on Marvell Berlin arm64 platforms, the reason
> is the created ci_hdrc platform_device's dma_ops is dummy_dma_ops, so all
> dma related operations will fail. The fix I can think of would be something
> as below:
>
> And I noticed that dwc3 has the same issue[1], and as pointed out in its
> discussion, the patch can't fix None-DT platforms, so could you please
> guide me what's the proper fix which can be mainlined?
I think the right solution is:
- Set the "sysdev" pointer tin the USB device o the device structure that
was created by DT or the legacy board file and remove the manual
setting of dma_mask, parms and the dma_configure. This should
make everything work as expected in case of DT
- For any legacy board files, set the mask/parms and map_ops at
the point where the device originally created.
Arnd
^ permalink raw reply
* Touchscreen failure with CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND
From: Fabio Estevam @ 2017-04-25 11:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170425050633.GV26900@vireshk-i7>
Hi Viresh,
On Tue, Apr 25, 2017 at 2:06 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> Honestly, I don't have a clue on how can we fix it for you now :)
>
> @Rafael: Any idea apart from running at max all the time?
>
> what touchscreen driver are you using btw? Just curious to see if there is any
> bug in there. Handling touchscreen events shouldn't require us to run at max
> freq.
imx6q-sabresd board uses a drivers/input/touchscreen/egalax_ts.c touchscreen.
>
> @shawn: Saw something similar ever ?
I do not see the problem with the NXP kernel, but was not able to
identify what makes the touchscreen not to fail at 396MHz in their
kernel.
Thanks
^ permalink raw reply
* [PATCH] arm64: pmuv3: handle pmuv3+
From: Mark Rutland @ 2017-04-25 11:08 UTC (permalink / raw)
To: linux-arm-kernel
Commit f1b36dcb5c316c27 ("arm64: pmuv3: handle !PMUv3 when probing") is
a little too restrictive, and prevents the use of of backwards
compatible PMUv3 extenstions, which have a PMUver value other than 1.
For instance, ARMv8.1 PMU extensions (as implemented by ThunderX2) are
reported with PMUver value 4.
Per the usual ID register principles, at least 0x1-0x7 imply a
PMUv3-compatible PMU. It's not currently clear whether 0x8-0xe imply the
same.
For the time being, treat the value as signed, and with 0x1-0x7 treated
as meaning PMUv3 is implemented. This may be relaxed by future patches.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Reported-by: Jayachandran C <jnair@caviumnetworks.com>
Cc: Will Deacon <will.deacon@arm.com>
---
arch/arm64/kernel/perf_event.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
Will, would you be happy to queue this fixup for v4.12?
Thanks,
Mark.
diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
index 98c7493..5f64d19 100644
--- a/arch/arm64/kernel/perf_event.c
+++ b/arch/arm64/kernel/perf_event.c
@@ -966,13 +966,14 @@ static void __armv8pmu_probe_pmu(void *info)
{
struct armv8pmu_probe_info *probe = info;
struct arm_pmu *cpu_pmu = probe->pmu;
- u64 dfr0, pmuver;
+ u64 dfr0;
u32 pmceid[2];
+ int pmuver;
dfr0 = read_sysreg(id_aa64dfr0_el1);
- pmuver = cpuid_feature_extract_unsigned_field(dfr0,
+ pmuver = cpuid_feature_extract_signed_field(dfr0,
ID_AA64DFR0_PMUVER_SHIFT);
- if (pmuver != 1)
+ if (pmuver < 1)
return;
probe->present = true;
--
1.9.1
^ permalink raw reply related
* [PATCH v5 02/22] KVM: arm/arm64: Add GICV3 pending table save API documentation
From: Peter Maydell @ 2017-04-25 10:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492164934-988-3-git-send-email-eric.auger@redhat.com>
On 14 April 2017 at 11:15, Eric Auger <eric.auger@redhat.com> wrote:
> Add description for how to save GICV3 LPI pending bit into
> guest RAM pending tables.
>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>
> ---
> v5: creation
> ---
> Documentation/virtual/kvm/devices/arm-vgic-v3.txt | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/virtual/kvm/devices/arm-vgic-v3.txt b/Documentation/virtual/kvm/devices/arm-vgic-v3.txt
> index c1a2461..9293b45 100644
> --- a/Documentation/virtual/kvm/devices/arm-vgic-v3.txt
> +++ b/Documentation/virtual/kvm/devices/arm-vgic-v3.txt
> @@ -167,11 +167,17 @@ Groups:
> KVM_DEV_ARM_VGIC_CTRL_INIT
> request the initialization of the VGIC, no additional parameter in
> kvm_device_attr.addr.
> + KVM_DEV_ARM_VGIC_SAVE_PENDING_TABLES
> + save all LPI pending bits into guest RAM pending tables.
> +
> + The first kB of the pending table is not altered by this operation.
> Errors:
> -ENXIO: VGIC not properly configured as required prior to calling
> this attribute
> -ENODEV: no online VCPU
> -ENOMEM: memory shortage when allocating vgic internal data
> + -EFAULT: Invalid guest ram access
> + -EBUSY: One or more VCPUS are running
>
>
> KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO
> --
> 2.5.5
When does the -EFAULT return happen? (if the guest points GITS_BASER<n>
etc at invalid memory, presumably?) How does the QEMU migration code
handle this case? Failing migration because the guest has done something
silly doesn't seem too palatable, but trying to avoid that could be
more effort than an obscure corner case really merits.
thanks
-- PMM
^ permalink raw reply
* [PATCH v5 01/22] KVM: arm/arm64: Add ITS save/restore API documentation
From: Peter Maydell @ 2017-04-25 10:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492164934-988-2-git-send-email-eric.auger@redhat.com>
On 14 April 2017 at 11:15, Eric Auger <eric.auger@redhat.com> wrote:
> Add description for how to access ITS registers and how to save/restore
> ITS tables into/from memory.
>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>
Acked-by: Peter Maydell <peter.maydell@linaro.org>
thanks
-- PMM
^ permalink raw reply
* [PATCH RFC 0/5] *** SPI Slave mode support ***
From: Mark Brown @ 2017-04-25 10:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdXa_O6RsqUciiNWQ0Zp6dniS47AUmPN9UWAWitP0csx=Q@mail.gmail.com>
On Mon, Apr 24, 2017 at 12:55:21PM +0200, Geert Uytterhoeven wrote:
> On Fri, Apr 14, 2017 at 7:39 AM, Jiada Wang <jiada_wang@mentor.com> wrote:
> > Our use case is to use spidev as an interface to communicate with external
> > SPI master devices.
> > meanwhile the SPI bus controller can also act as master device to send data
> > to other
> > SPI slave devices on the board.
> That sounds a bit hackish to me. SPI was never meant to be a multi-master bus.
> While it can be done, you will need external synchronization (signals) to
> avoid conflicts between the SPI masters.
> > I found in your implementation, SPI bus controller is limited to either work
> > in master mode or
> > slave mode, is there any reasoning to not configure SPI mode based on SPI
> > devices use case?
> If you really need both master and slave support, you can use 2 subnodes
> in DT, the first representing the master, the second the slave.
> Mark, what's your opinion about this?
That sounds like a mess... we *could* put the slave flag on the device
rather than the controller I guess but there's also going to need to be
something representing whatever avoids collisions on the bus somewhere.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170425/6c1fbd80/attachment.sig>
^ permalink raw reply
* [PATCH V9 1/3] irq: Allow to pass the IRQF_TIMER flag with percpu irq request
From: Christoffer Dall @ 2017-04-25 10:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170425094927.GB16888@mai>
On Tue, Apr 25, 2017 at 11:49:27AM +0200, Daniel Lezcano wrote:
[...]
> >
> > The idle code is very much *not* aware of anything concerning that guest
> > timer.
>
> Just for my own curiosity, if there are two VM (VM1 and VM2). VM1 sets a timer1
> at <time> and exits, VM2 runs and sets a timer2 at <time+delta>.
>
> The timer1 for VM1 is supposed to expire while VM2 is running. IIUC the virtual
> timer is under control of VM2 and will expire at <time+delta>.
>
> Is the host wake up with the SW timer and switch in VM1 which in turn restores
> the timer and jump in the virtual timer irq handler?
>
The thing that may be missing here is that a VCPU thread (more of which
in a collection is a VM) is just a thread from the point of view of
Linux, and whether or not a guest schedules a timer, should not effect
the scheduler's decision to run a given thread, if the thread is
runnable.
Whenever we run a VCPU thread, we look at its timer state (in software)
and calculate if the guest should see a timer interrupt and inject such
a one (the hardware arch timer is not involved in this process at all).
We use timers in exactly two scenarios:
1. The hardware arch timers are used to force an exit to the host when
the guest programmed the timer, so we can do the calculation in
software I mentioned above and inject a virtual software-generated
interrupt when the guest expects to see one.
2. The guest goes to sleep (WFI) but has programmed a timer to be woken
up at some point. KVM handles a WFI by blocking the VCPU thread,
which basically means making the thread interruptible and putting it
on a waitqueue. In this case we schedule a software timer to make
the thread runnable again when the software timer fires (and the
scheduler runs that thread when it wants to after that).
If you have a VCPU thread from VM1 blocked, and you run a VCPU thread
from VM2, then the VCPU thread from VM2 will program the hardware arch
timer with the context of the VM2 VCPU thread while running, and this
has nothing to do with the VCPU thread from VM1 at this point, because
it relies on the host Linux time keeping infrastructure to become
runnable some time in the future, and running a guest naturally doesn't
mess with the host's time keeping.
Hope this helps,
-Christoffer
^ permalink raw reply
* [PATCH V9 1/3] irq: Allow to pass the IRQF_TIMER flag with percpu irq request
From: Marc Zyngier @ 2017-04-25 10:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170425094927.GB16888@mai>
On 25/04/17 10:49, Daniel Lezcano wrote:
> On Tue, Apr 25, 2017 at 10:10:12AM +0100, Marc Zyngier wrote:
[...]
>>> +static inline void setup_timings(struct irq_desc *desc, struct irqaction *act)
>>> +{
>>> + /*
>>> + * We don't need the measurement because the idle code already
>>> + * knows the next expiry event.
>>> + */
>>> + if (act->flags & __IRQF_TIMER)
>>> + return;
>>
>> And that's where this is really wrong for the KVM guest timer. As I
>> said, this timer is under complete control of the guest, and the rest of
>> the system doesn't know about it. KVM itself will only find out when the
>> vcpu does a VM exit for a reason or another, and will just save/restore
>> the state in order to be able to give the timer to another guest.
>>
>> The idle code is very much *not* aware of anything concerning that guest
>> timer.
>
> Just for my own curiosity, if there are two VM (VM1 and VM2). VM1 sets a timer1
> at <time> and exits, VM2 runs and sets a timer2 at <time+delta>.
>
> The timer1 for VM1 is supposed to expire while VM2 is running. IIUC the virtual
> timer is under control of VM2 and will expire at <time+delta>.
>
> Is the host wake up with the SW timer and switch in VM1 which in turn restores
> the timer and jump in the virtual timer irq handler?
Indeed. The SW timer causes VM1 to wake-up, either on the same CPU
(preempting VM2) or on another. The timer is then restored with the
pending virtual interrupt injected, and the guest does what it has to
with it.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [RFC] usb: chipidea: set dma_ops for the created ci_hdrc platform_device
From: Jisheng Zhang @ 2017-04-25 10:01 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
After commit 1dccb598df549 ("arm64: simplify dma_get_ops"), the chipidea
driver can't work any more on Marvell Berlin arm64 platforms, the reason
is the created ci_hdrc platform_device's dma_ops is dummy_dma_ops, so all
dma related operations will fail. The fix I can think of would be something
as below:
And I noticed that dwc3 has the same issue[1], and as pointed out in its
discussion, the patch can't fix None-DT platforms, so could you please
guide me what's the proper fix which can be mainlined?
Any suggestion is appreciated!
Thanks,
Jisheng
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-April/425079.html
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 047afdbb7049..acb80457603c 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -62,6 +62,7 @@
#include <linux/usb/chipidea.h>
#include <linux/usb/of.h>
#include <linux/of.h>
+#include <linux/of_device.h>
#include <linux/regulator/consumer.h>
#include <linux/usb/ehci_def.h>
@@ -786,6 +787,7 @@ struct platform_device *ci_hdrc_add_device(struct device *dev,
pdev->dev.dma_mask = dev->dma_mask;
pdev->dev.dma_parms = dev->dma_parms;
dma_set_coherent_mask(&pdev->dev, dev->coherent_dma_mask);
+ of_dma_configure(&pdev->dev, dev->of_node);
ret = platform_device_add_resources(pdev, res, nres);
if (ret)
^ permalink raw reply related
* [PATCH v2] iommu/arm-smmu: Return IOVA in iova_to_phys when SMMU is bypassed
From: sunil.kovvuri at gmail.com @ 2017-04-25 9:57 UTC (permalink / raw)
To: linux-arm-kernel
From: Sunil Goutham <sgoutham@cavium.com>
For software initiated address translation, when domain type is
IOMMU_DOMAIN_IDENTITY i.e SMMU is bypassed, mimic HW behavior
i.e return the same IOVA as translated address.
This patch is an extension to Will Deacon's patchset
"Implement SMMU passthrough using the default domain".
Signed-off-by: Sunil Goutham <sgoutham@cavium.com>
---
V2
- As per Will's suggestion applied fix to SMMUv3 driver as well.
drivers/iommu/arm-smmu-v3.c | 3 +++
drivers/iommu/arm-smmu.c | 3 +++
2 files changed, 6 insertions(+)
diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index 05b4592..d412bdd 100644
--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c
@@ -1714,6 +1714,9 @@ arm_smmu_iova_to_phys(struct iommu_domain *domain, dma_addr_t iova)
struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
struct io_pgtable_ops *ops = smmu_domain->pgtbl_ops;
+ if (domain->type == IOMMU_DOMAIN_IDENTITY)
+ return iova;
+
if (!ops)
return 0;
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index bfab4f7..81088cd 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -1459,6 +1459,9 @@ static phys_addr_t arm_smmu_iova_to_phys(struct iommu_domain *domain,
struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
struct io_pgtable_ops *ops= smmu_domain->pgtbl_ops;
+ if (domain->type == IOMMU_DOMAIN_IDENTITY)
+ return iova;
+
if (!ops)
return 0;
--
2.7.4
^ permalink raw reply related
* [PATCH V9 1/3] irq: Allow to pass the IRQF_TIMER flag with percpu irq request
From: Daniel Lezcano @ 2017-04-25 9:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f840e9d2-8aac-dc1d-6468-44f7658b55b1@arm.com>
On Tue, Apr 25, 2017 at 10:10:12AM +0100, Marc Zyngier wrote:
[?... ]
> >>>> Maybe you could explain why you think this interrupt is relevant to what
> >>>> you're trying to achieve?
> >>>
> >>> If this interrupt does not happen on the host, we don't care.
> >>
> >> All interrupts happen on the host. There is no such thing as a HW
> >> interrupt being directly delivered to a guest (at least so far). The
> >> timer is under control of the guest, which uses as it sees fit. When
> >> the HW timer expires, the interrupt fires on the host, which re-inject
> >> the interrupt in the guest.
> >
> > Ah, thanks for the clarification. Interesting.
> >
> > How can the host know which guest to re-inject the interrupt?
>
> The timer can only fire when the vcpu is running. If it is not running,
> a software timer is queued, with a pointer to the vcpu struct.
I see, thanks.
> >>> The flag IRQF_TIMER is used by the spurious irq handler in the try_one_irq()
> >>> function. However the per cpu timer interrupt will be discarded in the function
> >>> before because it is per cpu.
> >>
> >> Right. That's not because this is a timer, but because it is per-cpu.
> >> So why do we need this IRQF_TIMER flag, instead of fixing try_one_irq()?
> >
> > When a timer is not per cpu, (eg. request_irq), we need this flag, no?
>
> Sure, but in this series, they all seem to be per-cpu.
I think I was unclear. We need to tag an interrupt with IRQS_TIMINGS to record
their occurences but discarding the timers interrupt. That is done by checking
against IRQF_TIMER when setting up an interrupt.
request_irq() has a flag parameter which has IRQF_TIMER set in case of the
timers. request_percpu_irq has no flag parameter, so it is not possible to
discard these interrupts as the IRQS_TIMINGS will be set.
I don't understand how this is related to the the try_one_irq() fix you are
proposing. Am I missing something?
Regarding your description below, the host has no control at all on the virtual
timer and is not able to know the next expiration time, so I don't see the
point to add the IRQF_TIMER flag to the virtual timer.
I will resend a new version without this change on the virtual timer.
> >>> IMO, for consistency reason, adding the IRQF_TIMER makes sense. Other than
> >>> that, as the interrupt is not happening on the host, this flag won't be used.
> >>>
> >>> Do you want to drop this change?
> >>
> >> No, I'd like to understand the above. Why isn't the following patch
> >> doing the right thing?
> >
> > Actually, the explanation is in the next patch of the series (2/3)
> >
> > [ ... ]
> >
> > +static inline void setup_timings(struct irq_desc *desc, struct irqaction *act)
> > +{
> > + /*
> > + * We don't need the measurement because the idle code already
> > + * knows the next expiry event.
> > + */
> > + if (act->flags & __IRQF_TIMER)
> > + return;
>
> And that's where this is really wrong for the KVM guest timer. As I
> said, this timer is under complete control of the guest, and the rest of
> the system doesn't know about it. KVM itself will only find out when the
> vcpu does a VM exit for a reason or another, and will just save/restore
> the state in order to be able to give the timer to another guest.
>
> The idle code is very much *not* aware of anything concerning that guest
> timer.
Just for my own curiosity, if there are two VM (VM1 and VM2). VM1 sets a timer1
at <time> and exits, VM2 runs and sets a timer2 at <time+delta>.
The timer1 for VM1 is supposed to expire while VM2 is running. IIUC the virtual
timer is under control of VM2 and will expire at <time+delta>.
Is the host wake up with the SW timer and switch in VM1 which in turn restores
the timer and jump in the virtual timer irq handler?
> > +
> > + desc->istate |= IRQS_TIMINGS;
> > +}
> >
> > [ ... ]
> >
> > +/*
> > + * The function record_irq_time is only called in one place in the
> > + * interrupts handler. We want this function always inline so the code
> > + * inside is embedded in the function and the static key branching
> > + * code can act at the higher level. Without the explicit
> > + * __always_inline we can end up with a function call and a small
> > + * overhead in the hotpath for nothing.
> > + */
> > +static __always_inline void record_irq_time(struct irq_desc *desc)
> > +{
> > + if (!static_branch_likely(&irq_timing_enabled))
> > + return;
> > +
> > + if (desc->istate & IRQS_TIMINGS) {
> > + struct irq_timings *timings = this_cpu_ptr(&irq_timings);
> > +
> > + timings->values[timings->count & IRQ_TIMINGS_MASK] =
> > + irq_timing_encode(local_clock(),
> > + irq_desc_get_irq(desc));
> > +
> > + timings->count++;
> > + }
> > +}
> >
> > [ ... ]
> >
> > The purpose is to predict the next event interrupts on the system which are
> > source of wake up. For now, this patchset is focused on interrupts (discarding
> > timer interrupts).
> >
> > The following article gives more details: https://lwn.net/Articles/673641/
> >
> > When the interrupt is setup, we tag it except if it is a timer. So with this
> > patch there is another usage of the IRQF_TIMER where we will be ignoring
> > interrupt coming from a timer.
> >
> > As the timer interrupt is delivered to the host, we should not measure it as it
> > is a timer and set this flag.
> >
> > The needed information is: "what is the earliest VM timer?". If this
> > information is already available then there is nothing more to do, otherwise we
> > should add it in the future.
>
> This information is not readily available. You can only find it when it
> is too late (timer has already fired) or when it is not relevant anymore
> (guest is sleeping and we've queued a SW timer for it).
>
> Thanks,
>
> M.
> --
> Jazz is not dead. It just smells funny...
--
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* [PATCH] usb: chipidea: properly handle host or gadget initialization failure
From: Jisheng Zhang @ 2017-04-25 9:43 UTC (permalink / raw)
To: linux-arm-kernel
If ci_hdrc_host_init() or ci_hdrc_gadget_init() returns error and the
error != -ENXIO, as Peter pointed out, "it stands for initialization
for host or gadget has failed", so we'd better return failure rather
continue.
Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
---
drivers/usb/chipidea/core.c | 25 +++++++++++++++++++------
1 file changed, 19 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 79ad8e91632e..047afdbb7049 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -930,20 +930,28 @@ static int ci_hdrc_probe(struct platform_device *pdev)
/* initialize role(s) before the interrupt is requested */
if (dr_mode == USB_DR_MODE_OTG || dr_mode == USB_DR_MODE_HOST) {
ret = ci_hdrc_host_init(ci);
- if (ret)
- dev_info(dev, "doesn't support host\n");
+ if (ret) {
+ if (ret == -ENXIO)
+ dev_info(dev, "doesn't support host\n");
+ else
+ goto deinit_phy;
+ }
}
if (dr_mode == USB_DR_MODE_OTG || dr_mode == USB_DR_MODE_PERIPHERAL) {
ret = ci_hdrc_gadget_init(ci);
- if (ret)
- dev_info(dev, "doesn't support gadget\n");
+ if (ret) {
+ if (ret == -ENXIO)
+ dev_info(dev, "doesn't support gadget\n");
+ else
+ goto deinit_host;
+ }
}
if (!ci->roles[CI_ROLE_HOST] && !ci->roles[CI_ROLE_GADGET]) {
dev_err(dev, "no supported roles\n");
ret = -ENODEV;
- goto deinit_phy;
+ goto deinit_gadget;
}
if (ci->is_otg && ci->roles[CI_ROLE_GADGET]) {
@@ -1013,7 +1021,12 @@ static int ci_hdrc_probe(struct platform_device *pdev)
return 0;
stop:
- ci_role_destroy(ci);
+ if (ci->is_otg)
+ ci_hdrc_otg_destroy(ci);
+deinit_gadget:
+ ci_hdrc_gadget_destroy(ci);
+deinit_host:
+ ci_hdrc_host_destroy(ci);
deinit_phy:
ci_usb_phy_exit(ci);
ulpi_exit:
--
2.11.0
^ permalink raw reply related
* [PATCH 2/2] ARM: dts: Add the ethernet and ethernet PHY to the cygnus core DT.
From: Sergei Shtylyov @ 2017-04-25 9:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424215022.30382-3-eric@anholt.net>
On 4/25/2017 12:50 AM, Eric Anholt wrote:
> Cygnus has a single amac controller connected to the B53 switch with 2
> PHYs. On the BCM911360_EP platform, those two PHYs are connected to
> the external ethernet jacks.
>
> Signed-off-by: Eric Anholt <eric@anholt.net>
> ---
> arch/arm/boot/dts/bcm-cygnus.dtsi | 60 ++++++++++++++++++++++++++++++++++
> arch/arm/boot/dts/bcm911360_entphn.dts | 8 +++++
> 2 files changed, 68 insertions(+)
>
> diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi b/arch/arm/boot/dts/bcm-cygnus.dtsi
> index 009f1346b817..318899df9972 100644
> --- a/arch/arm/boot/dts/bcm-cygnus.dtsi
> +++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
[...]
> @@ -295,6 +345,16 @@
> status = "disabled";
> };
>
> + eth0: enet at 18042000 {
Oh, and this one should be named "ethernet", according to the DT spec.
> + compatible = "brcm,amac";
> + reg = <0x18042000 0x1000>,
> + <0x18110000 0x1000>;
> + reg-names = "amac_base", "idm_base";
> + interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>;
> + max-speed = <1000>;
> + status = "disabled";
> + };
> +
> nand: nand at 18046000 {
> compatible = "brcm,nand-iproc", "brcm,brcmnand-v6.1";
> reg = <0x18046000 0x600>, <0xf8105408 0x600>,
[...]
MBR, Sergei
^ permalink raw reply
* [PATCH 2/2] ARM: dts: Add the ethernet and ethernet PHY to the cygnus core DT.
From: Sergei Shtylyov @ 2017-04-25 9:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424215022.30382-3-eric@anholt.net>
Hello.
On 4/25/2017 12:50 AM, Eric Anholt wrote:
> Cygnus has a single amac controller connected to the B53 switch with 2
> PHYs. On the BCM911360_EP platform, those two PHYs are connected to
> the external ethernet jacks.
My spell checker trips on "amac" and "ethernet" -- perhaps they need
capitalization?
> Signed-off-by: Eric Anholt <eric@anholt.net>
> ---
> arch/arm/boot/dts/bcm-cygnus.dtsi | 60 ++++++++++++++++++++++++++++++++++
> arch/arm/boot/dts/bcm911360_entphn.dts | 8 +++++
> 2 files changed, 68 insertions(+)
>
> diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi b/arch/arm/boot/dts/bcm-cygnus.dtsi
> index 009f1346b817..318899df9972 100644
> --- a/arch/arm/boot/dts/bcm-cygnus.dtsi
> +++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
> @@ -142,6 +142,56 @@
> interrupts = <0>;
> };
>
> + mdio: mdio at 18002000 {
> + compatible = "brcm,iproc-mdio";
> + reg = <0x18002000 0x8>;
> + #size-cells = <1>;
> + #address-cells = <0>;
> +
> + gphy0: eth-gphy at 0 {
The node anmes must be generic, the DT spec has standardized
"ethernet-phy" name for this case.
> + reg = <0>;
> + max-speed = <1000>;
> + };
> +
> + gphy1: eth-gphy at 1 {
> + reg = <1>;
> + max-speed = <1000>;
> + };
> + };
[...]
> @@ -295,6 +345,16 @@
> status = "disabled";
> };
>
> + eth0: enet at 18042000 {
> + compatible = "brcm,amac";
> + reg = <0x18042000 0x1000>,
> + <0x18110000 0x1000>;
> + reg-names = "amac_base", "idm_base";
I don't think "_base" suffixes are necessary here.
[...]
MBR, Sergei
^ permalink raw reply
* [PATCH 1/2] net: dsa: b53: Add compatible strings for the Cygnus-family BCM11360.
From: Sergei Shtylyov @ 2017-04-25 9:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424215022.30382-2-eric@anholt.net>
Hello!
On 4/25/2017 12:50 AM, Eric Anholt wrote:
> Cygnus is a small family of SoCs, of which we currently have
> devicetree for BCM11360 and BCM58300. The 11360's B53 is mostly the
> same as 58xx, just requiring a tiny bit of setup that was previously
> missing.
>
> Signed-off-by: Eric Anholt <eric@anholt.net>
> ---
> Documentation/devicetree/bindings/net/dsa/b53.txt | 3 +++
> drivers/net/dsa/b53/b53_srab.c | 2 ++
> 2 files changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/dsa/b53.txt b/Documentation/devicetree/bindings/net/dsa/b53.txt
> index d6c6e41648d4..49c93d3c0839 100644
> --- a/Documentation/devicetree/bindings/net/dsa/b53.txt
> +++ b/Documentation/devicetree/bindings/net/dsa/b53.txt
> @@ -29,6 +29,9 @@ Required properties:
> "brcm,bcm58625-srab"
> "brcm,bcm88312-srab" and the mandatory "brcm,nsp-srab string
>
> + For the BCM11360 SoC, must be:
> + "brcm,bcm11360-srab" and the mandatory "brcm,cygnus-srab string
Missing closing quote here and above?
[...]
MBR, Sergei
^ permalink raw reply
* [linux-sunxi] [PATCH v4 09/10] arm64: allwinner: a64: enable AXP803 regulators for Pine64
From: Icenowy Zheng @ 2017-04-25 9:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8c7864f1-a0d7-b87f-f9d6-5201cc773609@arm.com>
? 2017?4?25? GMT+08:00 ??5:24:13, Andre Przywara <andre.przywara@arm.com> ??:
>Hi,
>
>On 24/04/17 17:01, Icenowy Zheng wrote:
>> Add support of AXP803 regulators in the Pine64 device tree, in order
>to
>> enable many future functionalities, e.g. Wi-Fi.
>
>In general that's quite some code to just achieve some device power
>plane switching, but that's another discussion, I guess ;-)
>
>To me this patch here like a lot of churn to be duplicated in each
>board's DT.
>Can't we provide some sane defaults, either in axp803.dtsi or in an
>extra file (allwinner-ref-axp803.dtsi?), and only overwrite them in a
>board's DT if a board deviates?
For critical regulators you're right, however, peripherals' power seems to vary a lot, e.g. Wi-Fi and HDMI.
The DLDO1 for HDMI and DLDO4 for Wi-Fi design is only adopted by Pine64; according to BPi M64 schematics, Wi-Fi is DLDO2 and Wi-Fi IO voltage is DLDO4 (on Pine64 it's ELDO1 which is forced to be 1.8v because it's connected to CPVDD); on Orange Pi Win {,Plus} Wi-Fi is ALDO1, Wi-Fi IO is DLDO4 and HDMI is DLDO3.
>Because it seems like many boards are actually based on some Allwinner
>reference design and use very similar, if not identical settings.
>
>Also one thing below ...
>
>>
>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>> ---
>> .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 109
>+++++++++++++++++++++
>> 1 file changed, 109 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>> index 3e1b44292534..abc1879e91f2 100644
>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>> @@ -106,6 +106,115 @@
>> };
>> };
>>
>> +#include "axp803.dtsi"
>> +
>> +®_aldo1 {
>> + regulator-min-microvolt = <2800000>;
>> + regulator-max-microvolt = <2800000>;
>> + regulator-name = "vcc-csi";
>> +};
>> +
>> +®_aldo2 {
>> + regulator-always-on;
>> + regulator-min-microvolt = <1800000>;
>> + regulator-max-microvolt = <3300000>;
>> + regulator-name = "vcc-pl";
>> +};
>> +
>> +®_aldo3 {
>> + regulator-always-on;
>> + regulator-min-microvolt = <2700000>;
>> + regulator-max-microvolt = <3300000>;
>> + regulator-name = "vcc-pll-avcc";
>> +};
>> +
>> +®_dc1sw {
>> + regulator-name = "vcc-phy";
>> +};
>> +
>> +®_dcdc1 {
>> + regulator-always-on;
>> + regulator-min-microvolt = <3300000>;
>> + regulator-max-microvolt = <3300000>;
>> + regulator-name = "vcc-3v3";
>> +};
>> +
>> +®_dcdc2 {
>> + regulator-always-on;
>> + regulator-min-microvolt = <1000000>;
>> + regulator-max-microvolt = <1300000>;
>> + regulator-name = "vdd-cpux";
>> +};
>> +
>> +/* DCDC3 is polyphased with DCDC2 */
>> +
>> +®_dcdc5 {
>> + regulator-always-on;
>> + regulator-min-microvolt = <1500000>;
>> + regulator-max-microvolt = <1500000>;
>
>On the Pine64 there is DDR3L DRAM, running at 1.35V.
>
>Cheers,
>Andre.
>
>
>> + regulator-name = "vcc-dram";
>> +};
>> +
>> +®_dcdc6 {
>> + regulator-always-on;
>> + regulator-min-microvolt = <1100000>;
>> + regulator-max-microvolt = <1100000>;
>> + regulator-name = "vdd-sys";
>> +};
>> +
>> +®_dldo1 {
>> + regulator-min-microvolt = <3300000>;
>> + regulator-max-microvolt = <3300000>;
>> + regulator-name = "vcc-hdmi";
>> +};
>> +
>> +®_dldo2 {
>> + regulator-min-microvolt = <3300000>;
>> + regulator-max-microvolt = <3300000>;
>> + regulator-name = "vcc-mipi";
>> +};
>> +
>> +®_dldo3 {
>> + regulator-min-microvolt = <3300000>;
>> + regulator-max-microvolt = <3300000>;
>> + regulator-name = "avdd-csi";
>> +};
>> +
>> +®_dldo4 {
>> + regulator-min-microvolt = <3300000>;
>> + regulator-max-microvolt = <3300000>;
>> + regulator-name = "vcc-wifi";
>> +};
>> +
>> +®_eldo1 {
>> + regulator-min-microvolt = <1800000>;
>> + regulator-max-microvolt = <1800000>;
>> + regulator-name = "cpvdd";
>> +};
>> +
>> +®_eldo3 {
>> + regulator-min-microvolt = <1800000>;
>> + regulator-max-microvolt = <1800000>;
>> + regulator-name = "vdd-1v8-csi";
>> +};
>> +
>> +®_fldo1 {
>> + regulator-min-microvolt = <1200000>;
>> + regulator-max-microvolt = <1200000>;
>> + regulator-name = "vcc-1v2-hsic";
>> +};
>> +
>> +®_fldo2 {
>> + regulator-always-on;
>> + regulator-min-microvolt = <1100000>;
>> + regulator-max-microvolt = <1100000>;
>> + regulator-name = "vdd-cpus";
>> +};
>> +
>> +®_rtc_ldo {
>> + regulator-name = "vcc-rtc";
>> +};
>> +
>> &uart0 {
>> pinctrl-names = "default";
>> pinctrl-0 = <&uart0_pins_a>;
>>
^ permalink raw reply
* [linux-sunxi] [PATCH v4 09/10] arm64: allwinner: a64: enable AXP803 regulators for Pine64
From: Andre Przywara @ 2017-04-25 9:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424160103.9447-10-icenowy@aosc.io>
Hi,
On 24/04/17 17:01, Icenowy Zheng wrote:
> Add support of AXP803 regulators in the Pine64 device tree, in order to
> enable many future functionalities, e.g. Wi-Fi.
In general that's quite some code to just achieve some device power
plane switching, but that's another discussion, I guess ;-)
To me this patch here like a lot of churn to be duplicated in each
board's DT.
Can't we provide some sane defaults, either in axp803.dtsi or in an
extra file (allwinner-ref-axp803.dtsi?), and only overwrite them in a
board's DT if a board deviates?
Because it seems like many boards are actually based on some Allwinner
reference design and use very similar, if not identical settings.
Also one thing below ...
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> ---
> .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 109 +++++++++++++++++++++
> 1 file changed, 109 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> index 3e1b44292534..abc1879e91f2 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> @@ -106,6 +106,115 @@
> };
> };
>
> +#include "axp803.dtsi"
> +
> +®_aldo1 {
> + regulator-min-microvolt = <2800000>;
> + regulator-max-microvolt = <2800000>;
> + regulator-name = "vcc-csi";
> +};
> +
> +®_aldo2 {
> + regulator-always-on;
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-name = "vcc-pl";
> +};
> +
> +®_aldo3 {
> + regulator-always-on;
> + regulator-min-microvolt = <2700000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-name = "vcc-pll-avcc";
> +};
> +
> +®_dc1sw {
> + regulator-name = "vcc-phy";
> +};
> +
> +®_dcdc1 {
> + regulator-always-on;
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-name = "vcc-3v3";
> +};
> +
> +®_dcdc2 {
> + regulator-always-on;
> + regulator-min-microvolt = <1000000>;
> + regulator-max-microvolt = <1300000>;
> + regulator-name = "vdd-cpux";
> +};
> +
> +/* DCDC3 is polyphased with DCDC2 */
> +
> +®_dcdc5 {
> + regulator-always-on;
> + regulator-min-microvolt = <1500000>;
> + regulator-max-microvolt = <1500000>;
On the Pine64 there is DDR3L DRAM, running at 1.35V.
Cheers,
Andre.
> + regulator-name = "vcc-dram";
> +};
> +
> +®_dcdc6 {
> + regulator-always-on;
> + regulator-min-microvolt = <1100000>;
> + regulator-max-microvolt = <1100000>;
> + regulator-name = "vdd-sys";
> +};
> +
> +®_dldo1 {
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-name = "vcc-hdmi";
> +};
> +
> +®_dldo2 {
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-name = "vcc-mipi";
> +};
> +
> +®_dldo3 {
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-name = "avdd-csi";
> +};
> +
> +®_dldo4 {
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-name = "vcc-wifi";
> +};
> +
> +®_eldo1 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-name = "cpvdd";
> +};
> +
> +®_eldo3 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-name = "vdd-1v8-csi";
> +};
> +
> +®_fldo1 {
> + regulator-min-microvolt = <1200000>;
> + regulator-max-microvolt = <1200000>;
> + regulator-name = "vcc-1v2-hsic";
> +};
> +
> +®_fldo2 {
> + regulator-always-on;
> + regulator-min-microvolt = <1100000>;
> + regulator-max-microvolt = <1100000>;
> + regulator-name = "vdd-cpus";
> +};
> +
> +®_rtc_ldo {
> + regulator-name = "vcc-rtc";
> +};
> +
> &uart0 {
> pinctrl-names = "default";
> pinctrl-0 = <&uart0_pins_a>;
>
^ permalink raw reply
* [RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6?
From: Suzuki K Poulose @ 2017-04-25 9:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGXu5jLPRYi+HK=07Zndc8szEKD4mZCqaHJFnHmmoYr7tA1xPw@mail.gmail.com>
On 16/04/17 20:52, Kees Cook wrote:
> Was there a conclusion to this discussion? I didn't see anything
> definitive in the thread...
>
> Notes below...
>
> On Fri, Dec 16, 2016 at 3:14 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> [Fixed linux-arm-kernel mailing list address, sorry for the duplicate,
>> I'm not reposting all the ugly patches though, unless someone really
>> wants them, https://lkml.org/lkml/2016/12/16/174 has a copy]
>>
>> On Friday, December 16, 2016 11:56:21 AM CET Arnd Bergmann wrote:
>>> I had some fun doing build testing with older gcc versions, building
>>> every release from 4.0 through 7.0 and running that on my randconfig
>>> setup to see what comes out.
>>>
>>> First of all, gcc-4.9 and higher is basically warning-free everywhere,
>>> although gcc-7 introduces some interesting new warnings (I have started
>>> doing patches for those as well). gcc-4.8 is probably good, too, and
>>> gcc-4.6 and 4.7 at least don't produce build failures in general, though
>>> the level of false-positive warnings increases (we could decide to turn
>>> those off for older compilers for build test purposes).
>>>
>>> In gcc-4.5 and below, dead code elimination is not as good as later,
>>> causing a couple of link errors, and some of them have no good workaround
>>> (see patch 1). It would be nice to declare that version too old, but
>>> several older distros that are still in wide use ship with compilers
>>> earlier than 4.6:
>>>
>>> RHEL6: gcc-4.4
>
> This appears to have support until July 31, 2018. (Though it's using a
> 2.6 kernel.)
>
>>> Debian 6: gcc-4.4
>
> This went fully unsupported on Feb 29, 2016.
>
>>> Ubuntu 10.04: gcc-4.4
>
> This went fully unsupported on Apr 30, 2015.
>
>>> SLES11: gcc-4.3
>
> General support ends Mar 31 2019, fully unsupported 31 Mar 2022. (And
> like RHEL6 is using a 2.6 kernel.)
fyi, SLES11 upgraded to kernel 3.0, in SP2.
https://www.novell.com/support/kb/doc.php?id=3594951
Cheers
Suzuki
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox