* Re: [Qemu-devel] [RFC 1/2] qom/cpu: move tlb_flush to cpu_common_reset
From: Richard Henderson @ 2016-11-14 19:25 UTC (permalink / raw)
To: Alex Bennée
Cc: qemu-devel, Peter Maydell, Edgar E. Iglesias, Paolo Bonzini,
Eduardo Habkost, Michael Walle, Laurent Vivier, Aurelien Jarno,
Yongbok Kim, Anthony Green, Jia Liu, David Gibson, Alexander Graf,
Mark Cave-Ayland, Artyom Tarasenko, Bastian Koppelmann,
open list:ARM, open list:PowerPC
In-Reply-To: <20161114174010.31040-2-alex.bennee@linaro.org>
On 11/14/2016 06:40 PM, Alex Bennée wrote:
> It is a common thing amongst the various cpu reset functions want to
> flush the SoftMMU's TLB entries. This is done either by calling
> tlb_flush directly or by way of a general memset of the CPU
> structure (sometimes both).
>
> This moves the tlb_flush call to the common reset function and
> additionally ensures it is only done for the CONFIG_SOFTMMU case and
> when tcg is enabled.
>
> In some target cases we add an empty end_of_reset_fields structure to the
> target vCPU structure so have a clear end point for any memset which
> is resetting value in the structure before CPU_COMMON (where the TLB
> structures are).
>
> While this is a nice clean-up in general it is also a precursor for
> changes coming to cputlb for MTTCG where the clearing of entries
> can't be done arbitrarily across vCPUs. Currently the cpu_reset
> function is usually called from the context of another vCPU as the
> architectural power up sequence is run. By using the cputlb API
> functions we can ensure the right behaviour in the future.
Reviewed-by: Richard Henderson <rth@twiddle.net>
r~
^ permalink raw reply
* Re: [PATCH] t0021, t5615: use $PWD instead of $(pwd) in PATH-like shell variables
From: Ramsay Jones @ 2016-11-14 19:45 UTC (permalink / raw)
To: Jeff King, Torsten Bögershausen
Cc: Lars Schneider, Junio C Hamano, Johannes Schindelin,
Johannes Sixt, git, pranit.bauva
In-Reply-To: <20161114170105.btnohk2777ddaiul@sigill.intra.peff.net>
On 14/11/16 17:01, Jeff King wrote:
> On Mon, Nov 14, 2016 at 05:35:56PM +0100, Torsten Bögershausen wrote:
>
>>> Git 'pu' does not compile on macOS right now:
>>> builtin/bisect--helper.c:299:6: error: variable 'good_syn' is used uninitialized
>>> whenever 'if' condition is true [-Werror,-Wsometimes-uninitialized]
>
> The next step is to make sure that the topic author is aware (in this
> case, one assumes it's pb/bisect).
[+cc Pranit]
Yep, I had a quick squint, and it looks like the compiler is correct.
It should be complaining about the 'bad_syn' variable for exactly the
same reason: namely, whenever the if condition is true, the only exit
from that block is via 'goto finish' which bypasses the initialisation
of 'good_syn' and 'bad_syn'.
> Better still is to make a patch that can either be applied on top, or
> squashed as appropriate.
No patch this time, but it simply requires those variables to be
initialised to NULL in their declarations. :-D
> I know that Ramsay Jones does this, for
> example, with some of his sparse-related checks, and I'm pretty sure
> from the turnaround-time that he runs it against "pu".
Yep, the idea being to catch these simple problems before the topic
reaches 'next'.
ATB,
Ramsay Jones
^ permalink raw reply
* Re: [PATCH 0/2] Salvator-X: Add GPIO keys support
From: Geert Uytterhoeven @ 2016-11-14 19:47 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: Laurent Pinchart, Linux-Renesas, Kieran Bingham
In-Reply-To: <3190171.WPEDSgjiKH@avalon>
Hi Laurent,
On Mon, Nov 14, 2016 at 5:44 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Monday 14 Nov 2016 14:47:00 Geert Uytterhoeven wrote:
>> On Mon, Nov 14, 2016 at 2:41 PM, Laurent Pinchart wrote:
>> > On Monday 14 Nov 2016 14:35:26 Geert Uytterhoeven wrote:
>> >> The main reason I haven't sent out a similar series yet is because the
>> >> GPIOs used for the 3 push buttons are shared with the 3 user LEDs. For
>> >> each of them, you have to choose at DT time if you want to use them as
>> >> buttons or as LEDs.
>> >>
>> >> On ULCB, the same issue is present. For those, we settled on 1 key and 2
>> >> LEDs...
>> >>
>> >> Looking forward to more comments...
>> >
>> > In theory the GPIOs could be shared by the gpio-keys and LED drivers in
>> > open- drain mode. I'm not sure the GPIO subsystem supports that though.
>>
>> Been there, done that, cfr. "[RFD] Sharing GPIOs for input (buttons) and
>> output (LEDs)". The result wasn't pretty...
>
> Wasn't it ? Linus basically told you to use open-drain GPIOs and fix the GPIO
> driver in case it can't read the value of GPIOs configured as output in open-
> drain mode. If didn't shoot the idea down.
If I'm not mistaken, the R-Car GPIO block does not support open-drain GPIO.
Even if it would support it, you cannot read the GPIO while actively
pulling it down.
Hence you have to time-multiplex the GPIO to use both LEDs and buttons,
through switching between pulling down and not pulling down (or between
output and input, which is what I did).
Apart from that, there's also the discrepancy between hardware description
(the GPIO is connected to both buttons and LEDs, hence it should be described
that way in DT) and user policy (the user wants to use e.g. the first GPIO as a
button, and the second GPIO as an LED).
If you have ideas to solve these 2 issues, I'm happy to hear your thoughts!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] fetch/push: document that private data can be leaked
From: Junio C Hamano @ 2016-11-14 19:47 UTC (permalink / raw)
To: Jeff King; +Cc: Matt McCutchen, git
In-Reply-To: <20161114190725.fxjymvztc2eiomv6@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> So I think the in-between answer is "it is OK to push to an
> untrustworthy place, but do not do it from a repo that may contain
> secret contents".
Yes, that sounds like a sensible piece of advice to give to the
readers.
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 07/13] virtio-scsi: always use dataplane path if ioeventfd is active
From: Alex Williamson @ 2016-11-14 19:48 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: cornelia.huck, famz, qemu-devel, stefanha, mst
In-Reply-To: <635f3da4-ce9f-5fe8-bbc7-e2fcf97bed63@redhat.com>
On Mon, 14 Nov 2016 20:33:32 +0100
Paolo Bonzini <pbonzini@redhat.com> wrote:
> On 14/11/2016 19:49, Alex Williamson wrote:
> > On Mon, 14 Nov 2016 19:10:54 +0100
> > Paolo Bonzini <pbonzini@redhat.com> wrote:
> >
> >> On 14/11/2016 18:09, Alex Williamson wrote:
> >>> Hmm, fixed yet not fixed. I get a nice shutdown and it even eliminates
> >>> a cpu spike shown in virt-manager at the end of shutdown that was
> >>> typical previously, but then I noticed dmesg showing me segfaults, so I
> >>> hooked up gdb and:
> >>
> >> Well, that I don't get the segfault already says something... Though
> >> it's not even clear from the backtrace what is causing the segfault.
> >> Let's try the same printf without the change.
> >
> > Log starting from virsh shutdown. The final line occurs just as the VM
> > starts spinning on all vcpus. Thanks,
>
> Ok, this could be a start. Just for information what is your virtio-win
> version?
Device manager shows:
Driver Date: 9/22/2015
Driver Version: 62.72.104.11000
^ permalink raw reply
* [U-Boot] [RFC 0/1] Add TEE loading support to FIT image
From: Andrew F. Davis @ 2016-11-14 19:49 UTC (permalink / raw)
To: u-boot
Hello all,
Internally[0] we use the a hook in the FIT loadable section to install
our trusted execution environment solution (OPTEE) which is packaged
in the FIT image with the rest of the platform's images. I would like
to get some feedback if this will be an acceptable solution?
This patch is the first step where we allow a platform to add a
custom hook for the "tee" type loadable. The rest of the work
is in the platform specific call and so not relevant to this RFC.
The resulting FIT .its looks something like this:
...
am57xx-evm.optee {
description = "OPTEE OS Image";
data = /incbin/("am57xx-evm.optee");
type = "tee";
arch = "arm";
compression = "none";
};
...
configurations {
am57xx-evm {
description = "Linux kernel, FDT blob, and OPTEE OS for the AM57xx EVM";
kernel = "kernel at 1";
fdt = "am57xx-evm.dtb";
loadables = "am57xx-evm.optee";
};
...
Thanks,
Andrew
[0] git://git.ti.com/ti-u-boot/ti-u-boot.git
Andrew F. Davis (1):
image: Add TEE loading to FIT loadable processing
Kconfig | 10 ++++++++++
common/image.c | 18 ++++++++++++++++++
include/image.h | 15 +++++++++++++++
3 files changed, 43 insertions(+)
--
2.10.1
^ permalink raw reply
* [U-Boot] [RFC 1/1] image: Add TEE loading to FIT loadable processing
From: Andrew F. Davis @ 2016-11-14 19:49 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20161114194925.17117-1-afd@ti.com>
To help automate the loading of a TEE image during the boot we add a new
FIT section type 'tee', when we see this type while loading the loadable
sections we automatically call the platforms TEE processing function on
this image section.
Signed-off-by: Andrew F. Davis <afd@ti.com>
---
Kconfig | 10 ++++++++++
common/image.c | 18 ++++++++++++++++++
include/image.h | 15 +++++++++++++++
3 files changed, 43 insertions(+)
diff --git a/Kconfig b/Kconfig
index 1263d0b..97cf7c8 100644
--- a/Kconfig
+++ b/Kconfig
@@ -291,6 +291,16 @@ config FIT_IMAGE_POST_PROCESS
injected into the FIT creation (i.e. the blobs would have been pre-
processed before being added to the FIT image).
+config FIT_IMAGE_TEE_PROCESS
+ bool "Enable processing of TEE images during FIT loading by U-Boot"
+ depends on FIT && TI_SECURE_DEVICE
+ help
+ Allows platforms to perform processing, such as authentication and
+ installation, on TEE images extracted from FIT images in a platform
+ or board specific way. In order to use this feature a platform or
+ board-specific implementation of board_tee_image_process() must be
+ provided.
+
config SPL_DFU_SUPPORT
bool "Enable SPL with DFU to load binaries to memory device"
depends on USB
diff --git a/common/image.c b/common/image.c
index 7604494..4552ca5 100644
--- a/common/image.c
+++ b/common/image.c
@@ -165,6 +165,7 @@ static const table_entry_t uimage_type[] = {
{ IH_TYPE_ZYNQIMAGE, "zynqimage", "Xilinx Zynq Boot Image" },
{ IH_TYPE_ZYNQMPIMAGE, "zynqmpimage", "Xilinx ZynqMP Boot Image" },
{ IH_TYPE_FPGA, "fpga", "FPGA Image" },
+ { IH_TYPE_TEE, "tee", "TEE OS Image",},
{ -1, "", "", },
};
@@ -1408,6 +1409,8 @@ int boot_get_loadable(int argc, char * const argv[], bootm_headers_t *images,
int fit_img_result;
const char *uname;
+ uint8_t img_type;
+
/* Check to see if the images struct has a FIT configuration */
if (!genimg_has_config(images)) {
debug("## FIT configuration was not specified\n");
@@ -1447,6 +1450,21 @@ int boot_get_loadable(int argc, char * const argv[], bootm_headers_t *images,
/* Something went wrong! */
return fit_img_result;
}
+
+ fit_img_result = fit_image_get_node(buf, uname);
+ if (fit_img_result < 0) {
+ /* Something went wrong! */
+ return fit_img_result;
+ }
+ fit_img_result = fit_image_get_type(buf, fit_img_result, &img_type);
+ if (fit_img_result < 0) {
+ /* Something went wrong! */
+ return fit_img_result;
+ }
+#if defined(CONFIG_FIT_IMAGE_TEE_PROCESS)
+ if (img_type == IH_TYPE_TEE)
+ board_tee_image_process(img_data, img_len);
+#endif
}
break;
default:
diff --git a/include/image.h b/include/image.h
index 2b1296c..57084c8 100644
--- a/include/image.h
+++ b/include/image.h
@@ -279,6 +279,7 @@ enum {
IH_TYPE_ZYNQMPIMAGE, /* Xilinx ZynqMP Boot Image */
IH_TYPE_FPGA, /* FPGA Image */
IH_TYPE_VYBRIDIMAGE, /* VYBRID .vyb Image */
+ IH_TYPE_TEE, /* Trusted Execution Environment OS Image */
IH_TYPE_COUNT, /* Number of image types */
};
@@ -1263,4 +1264,18 @@ int board_fit_config_name_match(const char *name);
void board_fit_image_post_process(void **p_image, size_t *p_size);
#endif /* CONFIG_SPL_FIT_IMAGE_POST_PROCESS */
+#ifdef CONFIG_FIT_IMAGE_TEE_PROCESS
+/**
+ * board_fit_tee_process() - Do any needed processing on a loaded TEE image
+ *
+ * This is used to verify, decrypt, and/or install a TEE in a platform or
+ * board specific way.
+ *
+ * @tee_image: pointer to the image
+ * @tee_size: the image size
+ * @return no return value (failure should be handled internally)
+ */
+void board_tee_image_process(void *tee_image, size_t tee_size);
+#endif /* CONFIG_FIT_IMAGE_TEE_PROCESS */
+
#endif /* __IMAGE_H__ */
--
2.10.1
^ permalink raw reply related
* Re: Announcing btrfs-dedupe
From: Zygo Blaxell @ 2016-11-14 19:51 UTC (permalink / raw)
To: Austin S. Hemmelgarn; +Cc: James Pharaoh, Mark Fasheh, linux-btrfs
In-Reply-To: <dfb1372d-8bff-93ff-1ba7-d636e6c7fe4d@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3014 bytes --]
On Mon, Nov 14, 2016 at 01:39:02PM -0500, Austin S. Hemmelgarn wrote:
> On 2016-11-14 13:22, James Pharaoh wrote:
> >One thing I am keen to understand is if BTRFS will automatically ignore
> >a request to deduplicate a file if it is already deduplicated? Given the
> >performance I see when doing a repeat deduplication, it seems to me that
> >it can't be doing so, although this could be caused by the CPU usage you
> >mention above.
> What's happening is that the dedupe ioctl does a byte-wise comparison of the
> ranges to make sure they're the same before linking them. This is actually
> what takes most of the time when calling the ioctl, and is part of why it
> takes longer the larger the range to deduplicate is. In essence, it's
> behaving like an OS should and not trusting userspace to make reasonable
> requests (which is also why there's a separate ioctl to clone a range from
> another file instead of deduplicating existing data).
Deduplicating an extent that may might be concurrently modified during the
dedup is a reasonable userspace request. In the general case there's
no way for userspace to ensure that it's not happening.
That said, some optimization is possible (although there are good reasons
not to bother with optimization in the kernel):
- VFS could recognize when it has two separate references to
the same physical extent and not re-read the same data twice
(but that requires teaching VFS how to do CoW in general, and is
hard for political reasons on top of the obvious technical ones).
- the extent-same ioctl could check to see which extents
are referenced by the src and dst ranges, and return success
immediately without reading data if they are the same (but
userspace should already know this, or it's wasting a huge amount
of time before it even calls the kernel).
> TBH, even though it's kind of annoying from a performance perspective, it's
> a rather nice safety net to have. For example, one of the cases where I do
> deduplication is a couple of directories where each directory is an
> overlapping partial subset of one large tree which I keep elsewhere. In
> this case, I can tell just by filename exactly what files might be
> duplicates, so the ioctl's check lets me just call the ioctl on all
> potential duplicates (after checking size, no point in wasting time if the
> files obviously aren't duplicates), and have it figure out whether or not
> they can be deduplicated.
> >
> >In any case, I'm considering some digging into the filesystem structures
> >to see if I can work this out myself before i do any deduplication. I'm
> >fairly sure this should be relatively simple to work out, at least well
> >enough for my purposes.
> Sadly, there's no way to avoid doing so right now.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH v7 13/17] ref-filter: add `:dir` and `:base` options for ref printing atoms
From: Junio C Hamano @ 2016-11-14 19:51 UTC (permalink / raw)
To: Karthik Nayak; +Cc: Jacob Keller, Git mailing list
In-Reply-To: <CAOLa=ZSFuq2+6xsrJ=CcXuOVbTnbDirbRtu7Fonfk+9EdRpbxg@mail.gmail.com>
Karthik Nayak <karthik.188@gmail.com> writes:
>> - More importantly, what do these do? I do not think of a good
>> description that generalizes "base of refs/foo/bar/boz is foo" to
>> explain your :base.
>
> $ ./git for-each-ref --format "%(refname)%(end) %(refname:dir)"
> refs/heads/master refs/heads
> refs/heads/ref-filter refs/heads
> refs/remotes/junio/va/i18n refs/remotes/junio/va
>
> $ ./git for-each-ref refs/heads --format
> "%(align:left,30)%(refname)%(end) %(refname:base)"
> refs/heads/master heads
> refs/heads/ref-filter heads
> refs/remotes/junio/va/i18n remotes
>
> I guess this should clear it up.
Hmph.
I would guess from these examples that :dir is an equivalent to
dirname(). But it is unclear how :base is defined. Is it the path
component that comes immediately after "refs/" that appears at the
beginning?
^ permalink raw reply
* Re: [PATCH] drm/i915: Only poll DW3_A when init DDI PHY for ports B and C.
From: Vivi, Rodrigo @ 2016-11-14 19:51 UTC (permalink / raw)
To: Deak, Imre; +Cc: Conselvan De Oliveira, Ander, intel-gfx@lists.freedesktop.org
In-Reply-To: <1478869753.1457.13.camel@intel.com>
On Fri, 2016-11-11 at 15:09 +0200, Imre Deak wrote:
> On to, 2016-11-10 at 17:03 -0800, Rodrigo Vivi wrote:
> > According to Bspec we need to
> > "Poll for PORT_REF_DW3_A grc_done == 1b"
> > only on ports B and C initialization sequence when
> > copying rcomp from port A.
> >
> > So let's follow the spec and only poll for that case
> > and not on every port A initialization.
> >
> > Cc: Imre Deak <imre.deak@intel.com>
> > Cc: Ander Conselvan de Oliveira
> > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
>
> The current code isn't against the spec, we just wait for the
> calibration to complete earlier. This way we also wait in case only
> port A is enabled which is imo safer to do before a subsequent modeset
> on port A. But yes, the spec suggests the HW will handle the wait for
> this - only port A - case internally, so we can move the wait later to
> reduce somewhat the init time:
>
> Reviewed-by: Imre Deak <imre.deak@intel.com>
Ops, actually I noticed later that I need to remove the warning block
with return false from is_phy_enabled if grc isn't done. otherwise it
will force a reprograming without this line there.
So, do you believe it is worth to do a v2 removing that block or better
to just ignore this patch?
>
> > ---
> > drivers/gpu/drm/i915/intel_dpio_phy.c | 7 +++----
> > 1 file changed, 3 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dpio_phy.c b/drivers/gpu/drm/i915/intel_dpio_phy.c
> > index 7a8e82d..277b1aa 100644
> > --- a/drivers/gpu/drm/i915/intel_dpio_phy.c
> > +++ b/drivers/gpu/drm/i915/intel_dpio_phy.c
> > @@ -367,6 +367,9 @@ static void _bxt_ddi_phy_init(struct drm_i915_private *dev_priv,
> >
> > if (phy_info->rcomp_phy != -1) {
> > uint32_t grc_code;
> > +
> > + bxt_phy_wait_grc_done(dev_priv, phy_info->rcomp_phy);
> > +
> > /*
> > * PHY0 isn't connected to an RCOMP resistor so copy over
> > * the corresponding calibrated value from PHY1, and disable
> > @@ -387,10 +390,6 @@ static void _bxt_ddi_phy_init(struct drm_i915_private *dev_priv,
> > val = I915_READ(BXT_PHY_CTL_FAMILY(phy));
> > val |= COMMON_RESET_DIS;
> > I915_WRITE(BXT_PHY_CTL_FAMILY(phy), val);
> > -
> > - if (phy_info->rcomp_phy == -1)
> > - bxt_phy_wait_grc_done(dev_priv, phy);
> > -
> > }
> >
> > void bxt_ddi_phy_uninit(struct drm_i915_private *dev_priv, enum dpio_phy phy)
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH 5/5] media: platform: rcar_drif: Add DRIF support
From: Rob Herring @ 2016-11-14 19:52 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Ramesh Shanmugasundaram, mark.rutland-5wv7dgnIgG8,
mchehab-DgEjT+Ai2ygdnm+yROfE0A, hverkuil-qWit8jRvyhVmR6Xm/wNWPw,
sakari.ailus-VuQAYsv1563Yd54FQh9/CA, crope-X3B1VOXEql0,
chris.paterson2-zM6kxYcvzFBBDgjK7y7TUQ,
geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ,
linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <2857106.83gIJRJqtY@avalon>
On Thu, Nov 10, 2016 at 11:22:20AM +0200, Laurent Pinchart wrote:
> Hi Ramesh,
>
> Thank you for the patch.
>
> On Wednesday 09 Nov 2016 15:44:44 Ramesh Shanmugasundaram wrote:
> > This patch adds Digital Radio Interface (DRIF) support to R-Car Gen3 SoCs.
> > The driver exposes each instance of DRIF as a V4L2 SDR device. A DRIF
> > device represents a channel and each channel can have one or two
> > sub-channels respectively depending on the target board.
> >
> > DRIF supports only Rx functionality. It receives samples from a RF
> > frontend tuner chip it is interfaced with. The combination of DRIF and the
> > tuner device, which is registered as a sub-device, determines the receive
> > sample rate and format.
> >
> > In order to be compliant as a V4L2 SDR device, DRIF needs to bind with
> > the tuner device, which can be provided by a third party vendor. DRIF acts
> > as a slave device and the tuner device acts as a master transmitting the
> > samples. The driver allows asynchronous binding of a tuner device that
> > is registered as a v4l2 sub-device. The driver can learn about the tuner
> > it is interfaced with based on port endpoint properties of the device in
> > device tree. The V4L2 SDR device inherits the controls exposed by the
> > tuner device.
> >
> > The device can also be configured to use either one or both of the data
> > pins at runtime based on the master (tuner) configuration.
> >
> > Signed-off-by: Ramesh Shanmugasundaram
> > <ramesh.shanmugasundaram-kTT6dE0pTRh9uiUsa/gSgQ@public.gmane.org> ---
> > .../devicetree/bindings/media/renesas,drif.txt | 136 ++
> > drivers/media/platform/Kconfig | 25 +
> > drivers/media/platform/Makefile | 1 +
> > drivers/media/platform/rcar_drif.c | 1574
> > ++++++++++++++++++++ 4 files changed, 1736 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/media/renesas,drif.txt
> > create mode 100644 drivers/media/platform/rcar_drif.c
> >
> > diff --git a/Documentation/devicetree/bindings/media/renesas,drif.txt
> > b/Documentation/devicetree/bindings/media/renesas,drif.txt new file mode
> > 100644
> > index 0000000..d65368a
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/renesas,drif.txt
> > @@ -0,0 +1,136 @@
> > +Renesas R-Car Gen3 Digital Radio Interface controller (DRIF)
> > +------------------------------------------------------------
> > +
> > +R-Car Gen3 DRIF is a serial slave device. It interfaces with a master
> > +device as shown below
> > +
> > ++---------------------+ +---------------------+
> > +| |-----SCK------->|CLK |
> > +| Master |-----SS-------->|SYNC DRIFn (slave) |
> > +| |-----SD0------->|D0 |
> > +| |-----SD1------->|D1 |
> > ++---------------------+ +---------------------+
> > +
> > +Each DRIF channel (drifn) consists of two sub-channels (drifn0 & drifn1).
> > +The sub-channels are like two individual channels in itself that share the
> > +common CLK & SYNC. Each sub-channel has it's own dedicated resources like
> > +irq, dma channels, address space & clock.
> > +
> > +The device tree model represents the channel and each of it's sub-channel
> > +as a separate node. The parent channel ties the sub-channels together with
> > +their phandles.
> > +
> > +Required properties of a sub-channel:
> > +-------------------------------------
> > +- compatible: "renesas,r8a7795-drif" if DRIF controller is a part of
> > R8A7795 SoC.
> > + "renesas,rcar-gen3-drif" for a generic R-Car Gen3 compatible
> > device.
> > + When compatible with the generic version, nodes must list the
> > + SoC-specific version corresponding to the platform first
> > + followed by the generic version.
> > +- reg: offset and length of that sub-channel.
> > +- interrupts: associated with that sub-channel.
> > +- clocks: phandle and clock specifier of that sub-channel.
> > +- clock-names: clock input name string: "fck".
> > +- dmas: phandles to the DMA channel of that sub-channel.
> > +- dma-names: names of the DMA channel: "rx".
> > +
> > +Optional properties of a sub-channel:
> > +-------------------------------------
> > +- power-domains: phandle to the respective power domain.
> > +
> > +Required properties of a channel:
> > +---------------------------------
> > +- pinctrl-0: pin control group to be used for this channel.
> > +- pinctrl-names: must be "default".
> > +- sub-channels : phandles to the two sub-channels.
> > +
> > +Optional properties of a channel:
> > +---------------------------------
> > +- port: child port node of a channel that defines the local and remote
> > + endpoints. The remote endpoint is assumed to be a tuner subdevice
> > + endpoint.
> > +- renesas,syncmd : sync mode
> > + 0 (Frame start sync pulse mode. 1-bit width pulse
> > + indicates start of a frame)
> > + 1 (L/R sync or I2S mode) (default)
> > +- renesas,lsb-first : empty property indicates lsb bit is received
> > first.
> > + When not defined msb bit is received first (default)
>
> Shouldn't those two properties be instead queried from the tuner at runtime
> through the V4L2 subdev API ?
>
> > +- renesas,syncac-pol-high : empty property indicates sync signal polarity.
> > + When defined, active high or high->low sync signal.
> > + When not defined, active low or low->high sync signal
> > + (default)
>
> This could be queried too, except that an inverter could be present on the
> board, so it has to be specified in DT. I would however try to standardize it
> the same way that hsync-active and vsync-active are standardized in
> Documentation/devicetree/bindings/media/video-interfaces.txt.
>
> > +- renesas,dtdl : delay between sync signal and start of reception.
>
> Are this and the next property meant to account for PCB traces delays ?
>
> > + Must contain one of the following values:
> > + 0 (no bit delay)
> > + 50 (0.5-clock-cycle delay)
> > + 100 (1-clock-cycle delay) (default)
> > + 150 (1.5-clock-cycle delay)
> > + 200 (2-clock-cycle delay)
>
> How about specifying the property in half clock cycle units, from 0 to 4 ?
>
> > +- renesas,syncdl : delay between end of reception and sync signal
> > edge.
> > + Must contain one of the following values:
> > + 0 (no bit delay) (default)
> > + 50 (0.5-clock-cycle delay)
> > + 100 (1-clock-cycle delay)
> > + 150 (1.5-clock-cycle delay)
> > + 200 (2-clock-cycle delay)
> > + 300 (3-clock-cycle delay)
> > +
> > +Example
> > +--------
> > +
> > +SoC common dtsi file
> > +
> > + drif00: rif@e6f40000 {
> > + compatible = "renesas,r8a7795-drif",
> > + "renesas,rcar-gen3-drif";
> > + reg = <0 0xe6f40000 0 0x64>;
> > + interrupts = <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&cpg CPG_MOD 515>;
> > + clock-names = "fck";
> > + dmas = <&dmac1 0x20>, <&dmac2 0x20>;
> > + dma-names = "rx", "rx";
rx, rx? That doesn't make sense. While we don't explicitly disallow
this, I'm thinking we should. I wonder if there's any case this is
valid. If not, then a dtc check for this could be added.
> > + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
> > + status = "disabled";
> > + };
> > +
> > + drif01: rif@e6f50000 {
> > + compatible = "renesas,r8a7795-drif",
> > + "renesas,rcar-gen3-drif";
> > + reg = <0 0xe6f50000 0 0x64>;
> > + interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&cpg CPG_MOD 514>;
> > + clock-names = "fck";
> > + dmas = <&dmac1 0x22>, <&dmac2 0x22>;
> > + dma-names = "rx", "rx";
> > + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
> > + status = "disabled";
> > + };
> > +
> > + drif0: rif@0 {
> > + compatible = "renesas,r8a7795-drif",
> > + "renesas,rcar-gen3-drif";
> > + sub-channels = <&drif00>, <&drif01>;
> > + status = "disabled";
> > + };
>
> I'm afraid this really hurts my eyes, especially using the same compatible
> string for both the channel and sub-channel nodes.
>
> We need to decide how to model the hardware in DT. Given that the two channels
> are mostly independent having separate DT nodes makes sense to me. However, as
> they share the clock and sync signals, somehow grouping them makes sense. I
> see three ways to do so, and there might be more.
>
> 1. Adding an extra DT node for the channels group, with phandles to the two
> channels. This is what you're proposing here.
>
> 2. Adding an extra DT node for the channels group, as a parent of the two
> channels.
>
> 3. Adding phandles to the channels, pointing to each other, or possibly a
> phandle from channel 0 pointing to channel 1.
>
> Neither of these options seem perfect to me. I don't like option 1 as the
> group DT node really doesn't describe a hardware block. If we want to use a DT
> node to convey group information, option 2 seems better to me. However, it
> somehow abuses the DT parent-child model that is supposed to describe
> relationships from a control bus point of view. Option 3 has the drawback of
> not scaling properly, at least with phandles in both channels pointing to the
> other one.
>
> Rob, Geert, tell me you have a fourth idea I haven't thought of that would
> solve all those problems :-)
What's the purpose/need for grouping them?
I'm fine with Option 2, though I want to make sure it is really needed.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 5/5] media: platform: rcar_drif: Add DRIF support
From: Rob Herring @ 2016-11-14 19:52 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Ramesh Shanmugasundaram, mark.rutland, mchehab, hverkuil,
sakari.ailus, crope, chris.paterson2, geert+renesas, linux-media,
devicetree, linux-renesas-soc
In-Reply-To: <2857106.83gIJRJqtY@avalon>
On Thu, Nov 10, 2016 at 11:22:20AM +0200, Laurent Pinchart wrote:
> Hi Ramesh,
>
> Thank you for the patch.
>
> On Wednesday 09 Nov 2016 15:44:44 Ramesh Shanmugasundaram wrote:
> > This patch adds Digital Radio Interface (DRIF) support to R-Car Gen3 SoCs.
> > The driver exposes each instance of DRIF as a V4L2 SDR device. A DRIF
> > device represents a channel and each channel can have one or two
> > sub-channels respectively depending on the target board.
> >
> > DRIF supports only Rx functionality. It receives samples from a RF
> > frontend tuner chip it is interfaced with. The combination of DRIF and the
> > tuner device, which is registered as a sub-device, determines the receive
> > sample rate and format.
> >
> > In order to be compliant as a V4L2 SDR device, DRIF needs to bind with
> > the tuner device, which can be provided by a third party vendor. DRIF acts
> > as a slave device and the tuner device acts as a master transmitting the
> > samples. The driver allows asynchronous binding of a tuner device that
> > is registered as a v4l2 sub-device. The driver can learn about the tuner
> > it is interfaced with based on port endpoint properties of the device in
> > device tree. The V4L2 SDR device inherits the controls exposed by the
> > tuner device.
> >
> > The device can also be configured to use either one or both of the data
> > pins at runtime based on the master (tuner) configuration.
> >
> > Signed-off-by: Ramesh Shanmugasundaram
> > <ramesh.shanmugasundaram@bp.renesas.com> ---
> > .../devicetree/bindings/media/renesas,drif.txt | 136 ++
> > drivers/media/platform/Kconfig | 25 +
> > drivers/media/platform/Makefile | 1 +
> > drivers/media/platform/rcar_drif.c | 1574
> > ++++++++++++++++++++ 4 files changed, 1736 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/media/renesas,drif.txt
> > create mode 100644 drivers/media/platform/rcar_drif.c
> >
> > diff --git a/Documentation/devicetree/bindings/media/renesas,drif.txt
> > b/Documentation/devicetree/bindings/media/renesas,drif.txt new file mode
> > 100644
> > index 0000000..d65368a
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/renesas,drif.txt
> > @@ -0,0 +1,136 @@
> > +Renesas R-Car Gen3 Digital Radio Interface controller (DRIF)
> > +------------------------------------------------------------
> > +
> > +R-Car Gen3 DRIF is a serial slave device. It interfaces with a master
> > +device as shown below
> > +
> > ++---------------------+ +---------------------+
> > +| |-----SCK------->|CLK |
> > +| Master |-----SS-------->|SYNC DRIFn (slave) |
> > +| |-----SD0------->|D0 |
> > +| |-----SD1------->|D1 |
> > ++---------------------+ +---------------------+
> > +
> > +Each DRIF channel (drifn) consists of two sub-channels (drifn0 & drifn1).
> > +The sub-channels are like two individual channels in itself that share the
> > +common CLK & SYNC. Each sub-channel has it's own dedicated resources like
> > +irq, dma channels, address space & clock.
> > +
> > +The device tree model represents the channel and each of it's sub-channel
> > +as a separate node. The parent channel ties the sub-channels together with
> > +their phandles.
> > +
> > +Required properties of a sub-channel:
> > +-------------------------------------
> > +- compatible: "renesas,r8a7795-drif" if DRIF controller is a part of
> > R8A7795 SoC.
> > + "renesas,rcar-gen3-drif" for a generic R-Car Gen3 compatible
> > device.
> > + When compatible with the generic version, nodes must list the
> > + SoC-specific version corresponding to the platform first
> > + followed by the generic version.
> > +- reg: offset and length of that sub-channel.
> > +- interrupts: associated with that sub-channel.
> > +- clocks: phandle and clock specifier of that sub-channel.
> > +- clock-names: clock input name string: "fck".
> > +- dmas: phandles to the DMA channel of that sub-channel.
> > +- dma-names: names of the DMA channel: "rx".
> > +
> > +Optional properties of a sub-channel:
> > +-------------------------------------
> > +- power-domains: phandle to the respective power domain.
> > +
> > +Required properties of a channel:
> > +---------------------------------
> > +- pinctrl-0: pin control group to be used for this channel.
> > +- pinctrl-names: must be "default".
> > +- sub-channels : phandles to the two sub-channels.
> > +
> > +Optional properties of a channel:
> > +---------------------------------
> > +- port: child port node of a channel that defines the local and remote
> > + endpoints. The remote endpoint is assumed to be a tuner subdevice
> > + endpoint.
> > +- renesas,syncmd : sync mode
> > + 0 (Frame start sync pulse mode. 1-bit width pulse
> > + indicates start of a frame)
> > + 1 (L/R sync or I2S mode) (default)
> > +- renesas,lsb-first : empty property indicates lsb bit is received
> > first.
> > + When not defined msb bit is received first (default)
>
> Shouldn't those two properties be instead queried from the tuner at runtime
> through the V4L2 subdev API ?
>
> > +- renesas,syncac-pol-high : empty property indicates sync signal polarity.
> > + When defined, active high or high->low sync signal.
> > + When not defined, active low or low->high sync signal
> > + (default)
>
> This could be queried too, except that an inverter could be present on the
> board, so it has to be specified in DT. I would however try to standardize it
> the same way that hsync-active and vsync-active are standardized in
> Documentation/devicetree/bindings/media/video-interfaces.txt.
>
> > +- renesas,dtdl : delay between sync signal and start of reception.
>
> Are this and the next property meant to account for PCB traces delays ?
>
> > + Must contain one of the following values:
> > + 0 (no bit delay)
> > + 50 (0.5-clock-cycle delay)
> > + 100 (1-clock-cycle delay) (default)
> > + 150 (1.5-clock-cycle delay)
> > + 200 (2-clock-cycle delay)
>
> How about specifying the property in half clock cycle units, from 0 to 4 ?
>
> > +- renesas,syncdl : delay between end of reception and sync signal
> > edge.
> > + Must contain one of the following values:
> > + 0 (no bit delay) (default)
> > + 50 (0.5-clock-cycle delay)
> > + 100 (1-clock-cycle delay)
> > + 150 (1.5-clock-cycle delay)
> > + 200 (2-clock-cycle delay)
> > + 300 (3-clock-cycle delay)
> > +
> > +Example
> > +--------
> > +
> > +SoC common dtsi file
> > +
> > + drif00: rif@e6f40000 {
> > + compatible = "renesas,r8a7795-drif",
> > + "renesas,rcar-gen3-drif";
> > + reg = <0 0xe6f40000 0 0x64>;
> > + interrupts = <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&cpg CPG_MOD 515>;
> > + clock-names = "fck";
> > + dmas = <&dmac1 0x20>, <&dmac2 0x20>;
> > + dma-names = "rx", "rx";
rx, rx? That doesn't make sense. While we don't explicitly disallow
this, I'm thinking we should. I wonder if there's any case this is
valid. If not, then a dtc check for this could be added.
> > + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
> > + status = "disabled";
> > + };
> > +
> > + drif01: rif@e6f50000 {
> > + compatible = "renesas,r8a7795-drif",
> > + "renesas,rcar-gen3-drif";
> > + reg = <0 0xe6f50000 0 0x64>;
> > + interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&cpg CPG_MOD 514>;
> > + clock-names = "fck";
> > + dmas = <&dmac1 0x22>, <&dmac2 0x22>;
> > + dma-names = "rx", "rx";
> > + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
> > + status = "disabled";
> > + };
> > +
> > + drif0: rif@0 {
> > + compatible = "renesas,r8a7795-drif",
> > + "renesas,rcar-gen3-drif";
> > + sub-channels = <&drif00>, <&drif01>;
> > + status = "disabled";
> > + };
>
> I'm afraid this really hurts my eyes, especially using the same compatible
> string for both the channel and sub-channel nodes.
>
> We need to decide how to model the hardware in DT. Given that the two channels
> are mostly independent having separate DT nodes makes sense to me. However, as
> they share the clock and sync signals, somehow grouping them makes sense. I
> see three ways to do so, and there might be more.
>
> 1. Adding an extra DT node for the channels group, with phandles to the two
> channels. This is what you're proposing here.
>
> 2. Adding an extra DT node for the channels group, as a parent of the two
> channels.
>
> 3. Adding phandles to the channels, pointing to each other, or possibly a
> phandle from channel 0 pointing to channel 1.
>
> Neither of these options seem perfect to me. I don't like option 1 as the
> group DT node really doesn't describe a hardware block. If we want to use a DT
> node to convey group information, option 2 seems better to me. However, it
> somehow abuses the DT parent-child model that is supposed to describe
> relationships from a control bus point of view. Option 3 has the drawback of
> not scaling properly, at least with phandles in both channels pointing to the
> other one.
>
> Rob, Geert, tell me you have a fourth idea I haven't thought of that would
> solve all those problems :-)
What's the purpose/need for grouping them?
I'm fine with Option 2, though I want to make sure it is really needed.
Rob
^ permalink raw reply
* Re: XFS_WANT_CORRUPTED_GOTO
From: Brian Foster @ 2016-11-14 19:53 UTC (permalink / raw)
To: Chris; +Cc: linux-xfs
In-Reply-To: <25b69ec53ba731ddd2f04d4e70341bdd.squirrel@mail2.postbox.xyz>
On Mon, Nov 14, 2016 at 07:39:03PM +0100, Chris wrote:
> Dear Brian,
>
> thank you for your detailed answer.
>
> Brian Foster wrote:
> > On Sat, Nov 12, 2016 at 11:52:02AM +0100, Chris wrote:
> >> I tried XFS-repair, but it couldn't find the first or second super block
> >> after four hours.
> >>
> >
> > That sounds like something more significant is going on either with the
> > fs, the storage or xfs_repair has been pointed in the wrong place. The
> > above issue should at worst require zeroing the log, dealing with the
> > resulting inconsistency and rebuilding the fs btrees accurately.
>
> Well, did it crash, because I called
>
> xfs_db -c "freespc -s" /dev/...
>
> while it was still in this unmount-loop?
>
I don't think that should affect anything. Not prevent repair from
finding superblocks, at least.
> > I suspect it's too late to inspect what's going on there if you have
> > already restored from backup. In the future, you can use xfs_metadump to
> > capture a metadata only image of a broken fs to share with us and help
> > us diagnose what might have gone wrong.
>
> OK.
>
> > I'd suggest to run "xfs_repair -n" on those as soon as possible to see
> > if they are affected by the same problem. It might also be a good idea
> > to run it against the fs you've restored from backup to see if it
> > returns and possibly get an idea on what might have caused the problem.
>
> On those filesystems, that aren't in use now, xfs_repair hasn't found any
> problems.
>
> Thanks again for your help. Next time, I'll do a metadump.
>
Sounds good.
Brian
> - Chris
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] ARM: dts: sun8i: replace enable-sdio-wakeup with wakeup-source for BananaPi M1+
From: Maxime Ripard @ 2016-11-14 19:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479138250-17780-4-git-send-email-sudeep.holla@arm.com>
On Mon, Nov 14, 2016 at 03:44:10PM +0000, Sudeep Holla wrote:
> Though the mmc core driver will continue to support the legacy
> "enable-sdio-wakeup" property to enable SDIO as the wakeup source,
> "wakeup-source" is the new standard binding.
>
> This patch replaces the legacy "enable-sdio-wakeup" with the unified
> "wakeup-source" property in order to avoid any further copy-paste
> duplication.
>
> Cc: Chen-Yu Tsai <wens@csie.org>
> Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Applied, thanks!
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.infradead.org/pipermail/linux-arm-kernel/attachments/20161114/a2450401/attachment.sig>
^ permalink raw reply
* Re: [PATCH] ARM: dts: sun8i: replace enable-sdio-wakeup with wakeup-source for BananaPi M1+
From: Maxime Ripard @ 2016-11-14 19:53 UTC (permalink / raw)
To: Sudeep Holla
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Chen-Yu Tsai
In-Reply-To: <1479138250-17780-4-git-send-email-sudeep.holla-5wv7dgnIgG8@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 762 bytes --]
On Mon, Nov 14, 2016 at 03:44:10PM +0000, Sudeep Holla wrote:
> Though the mmc core driver will continue to support the legacy
> "enable-sdio-wakeup" property to enable SDIO as the wakeup source,
> "wakeup-source" is the new standard binding.
>
> This patch replaces the legacy "enable-sdio-wakeup" with the unified
> "wakeup-source" property in order to avoid any further copy-paste
> duplication.
>
> Cc: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
> Cc: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> Signed-off-by: Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH v2 0/3] i2c: octeon: thunder: Fix i2c not working on Octeon
From: Steven J. Hill @ 2016-11-14 19:53 UTC (permalink / raw)
To: Jan Glauber, Wolfram Sang; +Cc: linux-i2c, linux-mips, Paul Burton, David Daney
In-Reply-To: <1479149445-4663-1-git-send-email-jglauber@cavium.com>
On 11/14/2016 12:50 PM, Jan Glauber wrote:
>
> Since time is running out for 4.9 (or might have already if you're not
> going to send another pull request) I'm going for the safe option
> to fix the Octeon i2c problems, which is:
>
> 1. Reverting the readq_poll_timeout patch since it is broken
> 2. Apply Patch #2 from Paul
> 3. Add a small fix for the recovery that makes Paul's patch
> work on ThunderX
>
> I'll try to come up with a better solution for 4.10. My plan is to get rid
> of the polling-around-interrupt thing completely, but for that we need more
> time to make it work on Octeon.
>
> Please consider for 4.9.
>
Hey Jan.
This does not work on Octeon 71xx platforms. I will look at it more
closely tomorrow.
Steve
^ permalink raw reply
* Re: [PATCH v2 0/3] i2c: octeon: thunder: Fix i2c not working on Octeon
From: Steven J. Hill @ 2016-11-14 19:53 UTC (permalink / raw)
To: Jan Glauber, Wolfram Sang; +Cc: linux-i2c, linux-mips, Paul Burton, David Daney
In-Reply-To: <1479149445-4663-1-git-send-email-jglauber@cavium.com>
On 11/14/2016 12:50 PM, Jan Glauber wrote:
>
> Since time is running out for 4.9 (or might have already if you're not
> going to send another pull request) I'm going for the safe option
> to fix the Octeon i2c problems, which is:
>
> 1. Reverting the readq_poll_timeout patch since it is broken
> 2. Apply Patch #2 from Paul
> 3. Add a small fix for the recovery that makes Paul's patch
> work on ThunderX
>
> I'll try to come up with a better solution for 4.10. My plan is to get rid
> of the polling-around-interrupt thing completely, but for that we need more
> time to make it work on Octeon.
>
> Please consider for 4.9.
>
Hey Jan.
This does not work on Octeon 71xx platforms. I will look at it more
closely tomorrow.
Steve
^ permalink raw reply
* Re: 6ea8c546f3655 breaks thermal management on thinkpad x60 and t40p
From: Rafael J. Wysocki @ 2016-11-14 19:54 UTC (permalink / raw)
To: Pavel Machek, Robert Moore
Cc: Pandruvada, Srinivas, acpi_power-processor, rankincj,
Srinivas Pandruvada, Len Brown, Lv, regressions,
linux-kernel@vger.kernel.org, Zhang, Rui,
linux-pm@vger.kernel.org, platform-driver-x86@vger.kernel.org,
rjw@rjwysocki.net, viresh.kumar@linaro.org,
ibm-acpi-devel@lists.sourceforge.net, ibm-acpi@hmh.eng.br,
linux-acpi@vger.kernel.org
In-Reply-To: <20161114190343.GB20770@amd>
On Mon, Nov 14, 2016 at 8:03 PM, Pavel Machek <pavel@ucw.cz> wrote:
> Hi!
>
> Bisection was not fun, but I've got the result:
>
> # first bad commit: [6ea8c546f3655a81f82672f24b66dad6095bdd07] ACPICA:
> FADT support cleanup
Bob?
> I've reverted the patch on top of 4.9-rc4, and thermal management now works.
>
> More details are in https://bugzilla.kernel.org/show_bug.cgi?id=187311
>
> As this breaks thermal management on both thinkpad X60 and T40p, can
> I ask for a revert?
>
> If you have other ideas, I can test them, but as this is just a
> cleanup, it can wait for 4.10...
Right.
Besides, we're in the -rc6 time frame now, so I'll queue up a revert.
Thanks,
Rafael
^ permalink raw reply
* Re: [PATCH] time: Avoid signed overflow in timekeeping_delta_to_ns()
From: John Stultz @ 2016-11-14 19:54 UTC (permalink / raw)
To: Chris Metcalf
Cc: Thomas Gleixner, Laurent Vivier, David Gibson,
Christopher S . Hall, lkml
In-Reply-To: <1479152569-16890-1-git-send-email-cmetcalf@mellanox.com>
On Mon, Nov 14, 2016 at 11:42 AM, Chris Metcalf <cmetcalf@mellanox.com> wrote:
> This bugfix was originally made in commit 35a4933a8959 ("time:
> Avoid signed overflow in timekeeping_get_ns()"). When the code was
> refactored in commit 6bd58f09e1d8 ("time: Add cycles to nanoseconds
> translation") the signed overflow fix was lost. Re-introduce it.
>
> Signed-off-by: Chris Metcalf <cmetcalf@mellanox.com>
> ---
> I happened to be looking for an unrelated fix, found this code,
> realized the tip code didn't match the fixed code, and
> backtracked to where it had gone away.
>
> kernel/time/timekeeping.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
> index 37dec7e3db43..57926bc7b7f3 100644
> --- a/kernel/time/timekeeping.c
> +++ b/kernel/time/timekeeping.c
> @@ -304,8 +304,7 @@ static inline s64 timekeeping_delta_to_ns(struct tk_read_base *tkr,
> {
> s64 nsec;
>
> - nsec = delta * tkr->mult + tkr->xtime_nsec;
> - nsec >>= tkr->shift;
> + nsec = (delta * tkr->mult + tkr->xtime_nsec) >> tkr->shift;
Ugh.
So... I think this proves the original fix was *far* too subtle to
maintain. So I think reintroducing it as-is doesn't protect us from
undoing it. If the problem is really using the signed intermediate
nsec value, we should get rid of that.
thanks
-john
^ permalink raw reply
* Re: Announcing btrfs-dedupe
From: Austin S. Hemmelgarn @ 2016-11-14 19:56 UTC (permalink / raw)
To: Zygo Blaxell; +Cc: James Pharaoh, Mark Fasheh, linux-btrfs
In-Reply-To: <20161114195102.GI21290@hungrycats.org>
On 2016-11-14 14:51, Zygo Blaxell wrote:
> On Mon, Nov 14, 2016 at 01:39:02PM -0500, Austin S. Hemmelgarn wrote:
>> On 2016-11-14 13:22, James Pharaoh wrote:
>>> One thing I am keen to understand is if BTRFS will automatically ignore
>>> a request to deduplicate a file if it is already deduplicated? Given the
>>> performance I see when doing a repeat deduplication, it seems to me that
>>> it can't be doing so, although this could be caused by the CPU usage you
>>> mention above.
>> What's happening is that the dedupe ioctl does a byte-wise comparison of the
>> ranges to make sure they're the same before linking them. This is actually
>> what takes most of the time when calling the ioctl, and is part of why it
>> takes longer the larger the range to deduplicate is. In essence, it's
>> behaving like an OS should and not trusting userspace to make reasonable
>> requests (which is also why there's a separate ioctl to clone a range from
>> another file instead of deduplicating existing data).
>
> Deduplicating an extent that may might be concurrently modified during the
> dedup is a reasonable userspace request. In the general case there's
> no way for userspace to ensure that it's not happening.
I'm not even talking about the locking, I'm talking about the data
comparison that the ioctl does to ensure they are the same before
deduplicating them, and specifically that protecting against userspace
just passing in two random extents that happen to be the same size but
not contain the same data (because deduplication _should_ reject such a
situation, that's what the clone ioctl is for).
The locking is perfectly reasonable and shouldn't contribute that much
to the overhead (unless you're being crazy and deduplicating thousands
of tiny blocks of data).
>
> That said, some optimization is possible (although there are good reasons
> not to bother with optimization in the kernel):
>
> - VFS could recognize when it has two separate references to
> the same physical extent and not re-read the same data twice
> (but that requires teaching VFS how to do CoW in general, and is
> hard for political reasons on top of the obvious technical ones).
>
> - the extent-same ioctl could check to see which extents
> are referenced by the src and dst ranges, and return success
> immediately without reading data if they are the same (but
> userspace should already know this, or it's wasting a huge amount
> of time before it even calls the kernel).
>
>> TBH, even though it's kind of annoying from a performance perspective, it's
>> a rather nice safety net to have. For example, one of the cases where I do
>> deduplication is a couple of directories where each directory is an
>> overlapping partial subset of one large tree which I keep elsewhere. In
>> this case, I can tell just by filename exactly what files might be
>> duplicates, so the ioctl's check lets me just call the ioctl on all
>> potential duplicates (after checking size, no point in wasting time if the
>> files obviously aren't duplicates), and have it figure out whether or not
>> they can be deduplicated.
>>>
>>> In any case, I'm considering some digging into the filesystem structures
>>> to see if I can work this out myself before i do any deduplication. I'm
>>> fairly sure this should be relatively simple to work out, at least well
>>> enough for my purposes.
>> Sadly, there's no way to avoid doing so right now.
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v7 14/14] sdhci: sdhci-msm: update dll configuration
From: Stephen Boyd @ 2016-11-14 19:57 UTC (permalink / raw)
To: Ritesh Harjani
Cc: ulf.hansson, linux-mmc, adrian.hunter, shawn.lin, andy.gross,
devicetree, linux-clk, david.brown, linux-arm-msm, georgi.djakov,
alex.lemberg, mateusz.nowak, Yuliy.Izrailov, asutoshd, kdorfman,
david.griego, stummala, venkatg, rnayak, pramod.gurav,
Krishna Konda
In-Reply-To: <1479103248-9491-15-git-send-email-riteshh@codeaurora.org>
On 11/14, Ritesh Harjani wrote:
> @@ -903,7 +998,33 @@ static void sdhci_msm_set_clock(struct sdhci_host *host, unsigned int clock)
> config |= CORE_HC_SELECT_IN_EN;
> writel_relaxed(config, host->ioaddr + CORE_VENDOR_SPEC);
> }
> + if (!msm_host->clk_rate && !msm_host->use_cdclp533) {
> + /*
> + * Poll on DLL_LOCK or DDR_DLL_LOCK bits in
> + * CORE_DLL_STATUS to be set. This should get set
> + * within 15 us at 200 MHz.
> + */
> + rc = readl_relaxed_poll_timeout(host->ioaddr +
> + CORE_DLL_STATUS,
> + dll_lock,
> + (dll_lock &
> + (CORE_DLL_LOCK |
> + CORE_DDR_DLL_LOCK)), 10,
> + 1000);
> + if (rc == -ETIMEDOUT)
> + pr_err("%s: Unable to get DLL_LOCK/DDR_DLL_LOCK, dll_status: 0x%08x\n",
> + mmc_hostname(host->mmc), dll_lock);
> + }
> } else {
> + if (!msm_host->use_cdclp533) {
> + /* set CORE_PWRSAVE_DLL bit in CORE_VENDOR_SPEC3 */
These types of comments are totally useless. The code says
exactly what is being done, and the comment is actually wrong in
this case. Please remove all these "set/clear bit X in register
Y" comments.
> + config = readl_relaxed(host->ioaddr +
> + CORE_VENDOR_SPEC3);
> + config &= ~CORE_PWRSAVE_DLL;
> + writel_relaxed(config, host->ioaddr +
> + CORE_VENDOR_SPEC3);
> + }
> +
> /* Select the default clock (free running MCLK) */
> config = readl_relaxed(host->ioaddr + CORE_VENDOR_SPEC);
> config &= ~CORE_HC_MCLK_SEL_MASK;
> @@ -1100,6 +1221,13 @@ static int sdhci_msm_probe(struct platform_device *pdev)
> msm_host->use_14lpp_dll_reset = true;
>
> /*
> + * SDCC 5 controller with major version 1, minor version 0x34 and later
> + * with HS 400 mode support will use CM DLL instead of CDC LP 533 DLL.
> + */
> + if ((core_major == 1) && (core_minor < 0x34))
Drop useless parenthesis please.
> + msm_host->use_cdclp533 = true;
> +
> + /*
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [Qemu-devel] [PULL 3/4] tests/test-vmstate.c: add array of pointer to struct
From: Juan Quintela @ 2016-11-14 19:57 UTC (permalink / raw)
To: qemu-devel; +Cc: amit.shah, dgilbert, Halil Pasic
In-Reply-To: <1479153474-2401-1-git-send-email-quintela@redhat.com>
From: Halil Pasic <pasic@linux.vnet.ibm.com>
Increase test coverage by adding tests for the macro
VMSTATE_ARRAY_OF_POINTER_TO_STRUCT.
Signed-off-by: Halil Pasic <pasic@linux.vnet.ibm.com>
Reviewed-by: Guenther Hutzl <hutzl@linux.vnet.ibm.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
---
tests/test-vmstate.c | 74 ++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 74 insertions(+)
diff --git a/tests/test-vmstate.c b/tests/test-vmstate.c
index d513dc6..d2f529b 100644
--- a/tests/test-vmstate.c
+++ b/tests/test-vmstate.c
@@ -474,6 +474,76 @@ static void test_load_skip(void)
qemu_fclose(loading);
}
+
+typedef struct {
+ int32_t i;
+} TestStructTriv;
+
+const VMStateDescription vmsd_tst = {
+ .name = "test/tst",
+ .version_id = 1,
+ .minimum_version_id = 1,
+ .fields = (VMStateField[]) {
+ VMSTATE_INT32(i, TestStructTriv),
+ VMSTATE_END_OF_LIST()
+ }
+};
+
+#define AR_SIZE 4
+
+typedef struct {
+ TestStructTriv *ar[AR_SIZE];
+} TestArrayOfPtrToStuct;
+
+const VMStateDescription vmsd_arps = {
+ .name = "test/arps",
+ .version_id = 1,
+ .minimum_version_id = 1,
+ .fields = (VMStateField[]) {
+ VMSTATE_ARRAY_OF_POINTER_TO_STRUCT(ar, TestArrayOfPtrToStuct,
+ AR_SIZE, 0, vmsd_tst, TestStructTriv),
+ VMSTATE_END_OF_LIST()
+ }
+};
+static void test_arr_ptr_str_no0_save(void)
+{
+ TestStructTriv ar[AR_SIZE] = {{.i = 0}, {.i = 1}, {.i = 2}, {.i = 3} };
+ TestArrayOfPtrToStuct sample = {.ar = {&ar[0], &ar[1], &ar[2], &ar[3]} };
+ uint8_t wire_sample[] = {
+ 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x01,
+ 0x00, 0x00, 0x00, 0x02,
+ 0x00, 0x00, 0x00, 0x03,
+ QEMU_VM_EOF
+ };
+
+ save_vmstate(&vmsd_arps, &sample);
+ compare_vmstate(wire_sample, sizeof(wire_sample));
+}
+
+static void test_arr_ptr_str_no0_load(void)
+{
+ TestStructTriv ar_gt[AR_SIZE] = {{.i = 0}, {.i = 1}, {.i = 2}, {.i = 3} };
+ TestStructTriv ar[AR_SIZE] = {};
+ TestArrayOfPtrToStuct obj = {.ar = {&ar[0], &ar[1], &ar[2], &ar[3]} };
+ int idx;
+ uint8_t wire_sample[] = {
+ 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x01,
+ 0x00, 0x00, 0x00, 0x02,
+ 0x00, 0x00, 0x00, 0x03,
+ QEMU_VM_EOF
+ };
+
+ save_buffer(wire_sample, sizeof(wire_sample));
+ SUCCESS(load_vmstate_one(&vmsd_arps, &obj, 1,
+ wire_sample, sizeof(wire_sample)));
+ for (idx = 0; idx < AR_SIZE; ++idx) {
+ /* compare the target array ar with the ground truth array ar_gt */
+ g_assert_cmpint(ar_gt[idx].i, ==, ar[idx].i);
+ }
+}
+
int main(int argc, char **argv)
{
temp_fd = mkstemp(temp_file);
@@ -488,6 +558,10 @@ int main(int argc, char **argv)
g_test_add_func("/vmstate/field_exists/load/skip", test_load_skip);
g_test_add_func("/vmstate/field_exists/save/noskip", test_save_noskip);
g_test_add_func("/vmstate/field_exists/save/skip", test_save_skip);
+ g_test_add_func("/vmstate/array/ptr/str/no0/save",
+ test_arr_ptr_str_no0_save);
+ g_test_add_func("/vmstate/array/ptr/str/no0/load",
+ test_arr_ptr_str_no0_load);
g_test_run();
close(temp_fd);
--
2.7.4
^ permalink raw reply related
* [Qemu-devel] [PULL 1/4] migration: fix missing assignment for has_x_checkpoint_delay
From: Juan Quintela @ 2016-11-14 19:57 UTC (permalink / raw)
To: qemu-devel; +Cc: amit.shah, dgilbert, zhanghailiang
In-Reply-To: <1479153474-2401-1-git-send-email-quintela@redhat.com>
From: zhanghailiang <zhang.zhanghailiang@huawei.com>
We forgot to assign true to params->has_x_checkpoint_delay parameter
in qmp_query_migrate_parameters.
Without this, qmp command 'query-migrate-parameters' doesn't show the
default value for x-checkpoint-delay option.
This also fixes the fact that HMP was relying on unspecified behavior by
reading x_checkpoint_delay without checking has_x_checkpoint_delay.
Signed-off-by: zhanghailiang <zhang.zhanghailiang@huawei.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
---
hmp.c | 1 +
migration/migration.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/hmp.c b/hmp.c
index b5e3f54..02103df 100644
--- a/hmp.c
+++ b/hmp.c
@@ -318,6 +318,7 @@ void hmp_info_migrate_parameters(Monitor *mon, const QDict *qdict)
monitor_printf(mon, " %s: %" PRId64 " milliseconds",
MigrationParameter_lookup[MIGRATION_PARAMETER_DOWNTIME_LIMIT],
params->downtime_limit);
+ assert(params->has_x_checkpoint_delay);
monitor_printf(mon, " %s: %" PRId64,
MigrationParameter_lookup[MIGRATION_PARAMETER_X_CHECKPOINT_DELAY],
params->x_checkpoint_delay);
diff --git a/migration/migration.c b/migration/migration.c
index e331f28..f498ab8 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -593,6 +593,7 @@ MigrationParameters *qmp_query_migrate_parameters(Error **errp)
params->max_bandwidth = s->parameters.max_bandwidth;
params->has_downtime_limit = true;
params->downtime_limit = s->parameters.downtime_limit;
+ params->has_x_checkpoint_delay = true;
params->x_checkpoint_delay = s->parameters.x_checkpoint_delay;
return params;
--
2.7.4
^ permalink raw reply related
* [Qemu-devel] [PULL 0/4] Migration pull
From: Juan Quintela @ 2016-11-14 19:57 UTC (permalink / raw)
To: qemu-devel; +Cc: amit.shah, dgilbert
The following changes since commit 83c83f9a5266ff113060f887f106a47920fa6974:
Merge remote-tracking branch 'bonzini/tags/for-upstream' into staging (2016-11-11 12:51:50 +0000)
are available in the git repository at:
git://github.com/juanquintela/qemu.git tags/migration/20161114
for you to fetch changes up to 5c90308f07335451a08c030dc40a9eed4698152b:
migration: Fix return code of ram_save_iterate() (2016-11-14 19:35:41 +0100)
----------------------------------------------------------------
migration/next for 20161114
Hi
In this pull:
- two more tests (halil)
- fix return code of ram_save_iterate (thomas)
- fix assignment for has_x_chackponit_delay (zhang)
Please apply, Juan.
----------------------------------------------------------------
Halil Pasic (2):
tests/test-vmstate.c: add save_buffer util func
tests/test-vmstate.c: add array of pointer to struct
Thomas Huth (1):
migration: Fix return code of ram_save_iterate()
zhanghailiang (1):
migration: fix missing assignment for has_x_checkpoint_delay
hmp.c | 1 +
migration/migration.c | 1 +
migration/ram.c | 6 ++--
tests/test-vmstate.c | 97 ++++++++++++++++++++++++++++++++++++++++++++-------
4 files changed, 90 insertions(+), 15 deletions(-)
^ permalink raw reply
* [Qemu-devel] [PULL 2/4] tests/test-vmstate.c: add save_buffer util func
From: Juan Quintela @ 2016-11-14 19:57 UTC (permalink / raw)
To: qemu-devel; +Cc: amit.shah, dgilbert, Halil Pasic
In-Reply-To: <1479153474-2401-1-git-send-email-quintela@redhat.com>
From: Halil Pasic <pasic@linux.vnet.ibm.com>
Let us de-duplicate some code by introducing an utility function for
saving a chunk of bytes (used when testing load based on wire).
Signed-off-by: Halil Pasic <pasic@linux.vnet.ibm.com>
Reviewed-by: Guenther Hutzl <hutzl@linux.vnet.ibm.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
---
tests/test-vmstate.c | 23 +++++++++++------------
1 file changed, 11 insertions(+), 12 deletions(-)
diff --git a/tests/test-vmstate.c b/tests/test-vmstate.c
index d8da26f..d513dc6 100644
--- a/tests/test-vmstate.c
+++ b/tests/test-vmstate.c
@@ -83,6 +83,13 @@ static void save_vmstate(const VMStateDescription *desc, void *obj)
qemu_fclose(f);
}
+static void save_buffer(const uint8_t *buf, size_t buf_size)
+{
+ QEMUFile *fsave = open_test_file(true);
+ qemu_put_buffer(fsave, buf, buf_size);
+ qemu_fclose(fsave);
+}
+
static void compare_vmstate(uint8_t *wire, size_t size)
{
QEMUFile *f = open_test_file(false);
@@ -309,15 +316,13 @@ static const VMStateDescription vmstate_versioned = {
static void test_load_v1(void)
{
- QEMUFile *fsave = open_test_file(true);
uint8_t buf[] = {
0, 0, 0, 10, /* a */
0, 0, 0, 30, /* c */
0, 0, 0, 0, 0, 0, 0, 40, /* d */
QEMU_VM_EOF, /* just to ensure we won't get EOF reported prematurely */
};
- qemu_put_buffer(fsave, buf, sizeof(buf));
- qemu_fclose(fsave);
+ save_buffer(buf, sizeof(buf));
QEMUFile *loading = open_test_file(false);
TestStruct obj = { .b = 200, .e = 500, .f = 600 };
@@ -334,7 +339,6 @@ static void test_load_v1(void)
static void test_load_v2(void)
{
- QEMUFile *fsave = open_test_file(true);
uint8_t buf[] = {
0, 0, 0, 10, /* a */
0, 0, 0, 20, /* b */
@@ -344,8 +348,7 @@ static void test_load_v2(void)
0, 0, 0, 0, 0, 0, 0, 60, /* f */
QEMU_VM_EOF, /* just to ensure we won't get EOF reported prematurely */
};
- qemu_put_buffer(fsave, buf, sizeof(buf));
- qemu_fclose(fsave);
+ save_buffer(buf, sizeof(buf));
QEMUFile *loading = open_test_file(false);
TestStruct obj;
@@ -423,7 +426,6 @@ static void test_save_skip(void)
static void test_load_noskip(void)
{
- QEMUFile *fsave = open_test_file(true);
uint8_t buf[] = {
0, 0, 0, 10, /* a */
0, 0, 0, 20, /* b */
@@ -433,8 +435,7 @@ static void test_load_noskip(void)
0, 0, 0, 0, 0, 0, 0, 60, /* f */
QEMU_VM_EOF, /* just to ensure we won't get EOF reported prematurely */
};
- qemu_put_buffer(fsave, buf, sizeof(buf));
- qemu_fclose(fsave);
+ save_buffer(buf, sizeof(buf));
QEMUFile *loading = open_test_file(false);
TestStruct obj = { .skip_c_e = false };
@@ -451,7 +452,6 @@ static void test_load_noskip(void)
static void test_load_skip(void)
{
- QEMUFile *fsave = open_test_file(true);
uint8_t buf[] = {
0, 0, 0, 10, /* a */
0, 0, 0, 20, /* b */
@@ -459,8 +459,7 @@ static void test_load_skip(void)
0, 0, 0, 0, 0, 0, 0, 60, /* f */
QEMU_VM_EOF, /* just to ensure we won't get EOF reported prematurely */
};
- qemu_put_buffer(fsave, buf, sizeof(buf));
- qemu_fclose(fsave);
+ save_buffer(buf, sizeof(buf));
QEMUFile *loading = open_test_file(false);
TestStruct obj = { .skip_c_e = true, .c = 300, .e = 500 };
--
2.7.4
^ permalink raw reply related
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.