* [Buildroot] [PATCH] config: bump linux kernel to 4.8.6 in synopsys defconfigs
From: Alexey Brodkin @ 2016-11-14 17:26 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20161114171516.GB3399@free.fr>
Hi Yann,
On Mon, 2016-11-14 at 18:15 +0100, Yann E. MORIN wrote:
> Alexey, All,
>
> On 2016-11-14 14:46 +0000, Alexey Brodkin spake thusly:
> [--SNIP--]
> >
> > The point is we were sitting on the patch for quite some time and when we saw
> > RC1 was cut (as always unexpectedly :)) simply sent out what we had in our tree.
>
> "Unexpectedly" is a bit of untrue: we've been doing releases every three
> months since February 2009, 7 years ago, with a one-month freeze before
> the release.
>
> So, anything that comes on-or-after the first day of the release month is
> not guaranteed to go in master, unless it is a fix.
>
> This is far from "unexpected". ;-)
I think you understood my sarcasm.
Frankly on my first submission of defconfigs for ARC boards I intentionally left
kernel version unspecified, i.e. the most recent kernel in BR was used
implicitly there. The reason was to stick to latest because all development
for ARC happens upstream and there's really no reason to use anything except
latest stable.
Well I may foresee very rare situations when latest stable is broken for us and so we
will urgently change version... but usually that's not the case.
Instead now we have to bump kernel version either every month so users of BR from
its master branch use latest kernel or at least right before RC1 so we have latest
in the release... IMHO that's a bit of overhead.
I'm not sure if described approach makes sense for many defconfigs in BR,
probably this is only ARC issue but I'd prefer it to be solved in some
"automated" way instead of following:
?a) Bumps in stable repo and then
?b) Bumps of default kernel version in BR
Any thoughts?
-Alexey
^ permalink raw reply
* [PATCH v2 7/9] arm64: dts: rockchip: add pd_edp node for rk3399
From: Doug Anderson @ 2016-11-14 17:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478697721-2323-8-git-send-email-wxt@rock-chips.com>
Caesar,
On Wed, Nov 9, 2016 at 5:21 AM, Caesar Wang <wxt@rock-chips.com> wrote:
> From: zhangqing <zhangqing@rock-chips.com>
>
> 1. add pd node for RK3399 Soc
> 2. create power domain tree
> 3. add qos node for domain
No step #3 since there doesn't appear to be a qos node for eDP. Your
patch doesn't add one and I can't find one in the TRM.
> 4. add the pd support for edp
>
> Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
> Signed-off-by: Caesar Wang <wxt@rock-chips.com>
> ---
>
> Changes in v2: None
>
> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> index 74deb44..09ebf4e 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> @@ -835,6 +835,10 @@
> };
>
> /* These power domains are grouped by VD_LOGIC */
> + pd_edp at RK3399_PD_EDP {
> + reg = <RK3399_PD_EDP>;
> + clocks = <&cru PCLK_EDP_CTRL>;
Are you sure that PCLK_EDP isn't needed as well? After the super
hard-to-debug problems we just faced with the missing GMAC clock in
the power domains, I figure it's at least worth a check. ;)
> + };
> pd_emmc at RK3399_PD_EMMC {
> reg = <RK3399_PD_EMMC>;
> clocks = <&cru ACLK_EMMC>;
> @@ -1364,6 +1368,7 @@
> status = "disabled";
> pinctrl-names = "default";
> pinctrl-0 = <&edp_hpd>;
> + power-domains = <&power RK3399_PD_EDP>;
>
> ports {
> #address-cells = <1>;
Other than the question about the clock and the nits about the commit
message, this all looks fine to me. Feel free to add my Reviewed-by
if you fix those things.
-Doug
^ permalink raw reply
* Re: [PATCH v2 7/9] arm64: dts: rockchip: add pd_edp node for rk3399
From: Doug Anderson @ 2016-11-14 17:26 UTC (permalink / raw)
To: Caesar Wang
Cc: Heiko Stuebner, Eddie Cai, Tomasz Figa, zhangqing, David Wu,
Jianqun Xu, Yakir Yang, Brian Norris,
linux-kernel@vger.kernel.org, open list:ARM/Rockchip SoC...,
devicetree@vger.kernel.org, Rob Herring, Will Deacon,
Mark Rutland, Catalin Marinas,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1478697721-2323-8-git-send-email-wxt@rock-chips.com>
Caesar,
On Wed, Nov 9, 2016 at 5:21 AM, Caesar Wang <wxt@rock-chips.com> wrote:
> From: zhangqing <zhangqing@rock-chips.com>
>
> 1. add pd node for RK3399 Soc
> 2. create power domain tree
> 3. add qos node for domain
No step #3 since there doesn't appear to be a qos node for eDP. Your
patch doesn't add one and I can't find one in the TRM.
> 4. add the pd support for edp
>
> Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
> Signed-off-by: Caesar Wang <wxt@rock-chips.com>
> ---
>
> Changes in v2: None
>
> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> index 74deb44..09ebf4e 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> @@ -835,6 +835,10 @@
> };
>
> /* These power domains are grouped by VD_LOGIC */
> + pd_edp@RK3399_PD_EDP {
> + reg = <RK3399_PD_EDP>;
> + clocks = <&cru PCLK_EDP_CTRL>;
Are you sure that PCLK_EDP isn't needed as well? After the super
hard-to-debug problems we just faced with the missing GMAC clock in
the power domains, I figure it's at least worth a check. ;)
> + };
> pd_emmc@RK3399_PD_EMMC {
> reg = <RK3399_PD_EMMC>;
> clocks = <&cru ACLK_EMMC>;
> @@ -1364,6 +1368,7 @@
> status = "disabled";
> pinctrl-names = "default";
> pinctrl-0 = <&edp_hpd>;
> + power-domains = <&power RK3399_PD_EDP>;
>
> ports {
> #address-cells = <1>;
Other than the question about the clock and the nits about the commit
message, this all looks fine to me. Feel free to add my Reviewed-by
if you fix those things.
-Doug
^ permalink raw reply
* [Buildroot] [PATCH 3/3] configs/warp7: Bump to U-Boot 2016.11
From: Fabio Estevam @ 2016-11-14 17:26 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1479144385-27214-1-git-send-email-festevam@gmail.com>
Signed-off-by: Fabio Estevam <festevam@gmail.com>
---
configs/warp7_defconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configs/warp7_defconfig b/configs/warp7_defconfig
index a55a504..fca7a1d 100644
--- a/configs/warp7_defconfig
+++ b/configs/warp7_defconfig
@@ -25,7 +25,7 @@ BR2_LINUX_KERNEL_INTREE_DTS_NAME="imx7s-warp"
BR2_TARGET_UBOOT=y
BR2_TARGET_UBOOT_BOARDNAME="warp7_secure"
BR2_TARGET_UBOOT_CUSTOM_VERSION=y
-BR2_TARGET_UBOOT_CUSTOM_VERSION_VALUE="2016.09.01"
+BR2_TARGET_UBOOT_CUSTOM_VERSION_VALUE="2016.11"
BR2_TARGET_UBOOT_FORMAT_IMX=y
# wifi firmware for brcm43430
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 3/5] net: thunderx: Fix configuration of L3/L4 length checking
From: Sunil Kovvuri @ 2016-11-14 17:26 UTC (permalink / raw)
To: Corentin Labbe; +Cc: Linux Netdev List, Sunil Goutham, LKML, LAKML
In-Reply-To: <20161114123350.GA2449@Red>
>>You could use the BIT() macro here
Thanks, will change and resubmit.
Sunil.
^ permalink raw reply
* Re: [PATCH 1/2] staging: iio: ad7606: replace range/range_available with corresponding scale
From: Jonathan Cameron @ 2016-11-14 17:26 UTC (permalink / raw)
To: Lars-Peter Clausen, Jonathan Cameron, Eva Rachel Retuya,
linux-iio, linux-kernel
Cc: Michael.Hennerich, knaack.h, pmeerw, gregkh, Linus Walleij
In-Reply-To: <9765154f-78df-eb0e-9723-28e1057149bf@metafoo.de>
On 14 November 2016 10:30:50 GMT+00:00, Lars-Peter Clausen <lars@metafoo.de> wrote:
>On 11/12/2016 03:24 PM, Jonathan Cameron wrote:
>> On 11/11/16 14:18, Lars-Peter Clausen wrote:
>>> On 11/11/2016 07:34 AM, Eva Rachel Retuya wrote:
>>>> Eliminate the non-standard attribute in_voltage_range and move its
>>>> functionality under the scale attribute. read_raw() has been taken
>care
>>>> of previously so only write_raw() is handled here.
>>>>
>>>> Additionally, rename the attribute in_voltage_range_available into
>>>> in_voltage_scale_available.
>>>>
>>>> Suggested-by: Lars-Peter Clausen <lars@metafoo.de>
>>>> Signed-off-by: Eva Rachel Retuya <eraretuya@gmail.com>
>>>
>>> Hi,
>>>
>>> Thanks for the patch. Unfortunately this is not quite this straight
>forward.
>>>
>>> The scale is what you multiply the raw with to get the value in the
>standard
>>> IIO unit. Range as implemented in this driver is the maximum output
>voltage.
>>>
>>> To get the scale we need to look at the transfer function of the ADC
>[1].
>>> The transfer function tells us that 1 LSB is 305uV for the 10V range
>and
>>> 152uV for the 5V range.
>>>
>>> More specifically this is $RANGE*2/2**16 (times two since the ADC is
>bipolar).
>>>
>>> Since the default unit for IIO is mV for voltages we need to
>multiply this
>>> by 1000.
>>>
>>> The other thing we need to handle is the case where the RANGE pin is
>not
>>> connected to a GPIO but either hardwired to 1 or 0. Which we need to
>handle
>>> somehow.
>> Is it just me who thought, we need a fixed GPI like a fixed
>regulator?
>> Would allow this sort of fixed wiring to be simply defined.
>>
>> Linus, worth exploring?
>>
>> I doubt this will be the last case of this particular problem
>> (not exactly unusual to hard wire control lines like these as which
>range
>> makes sense is often a feature of the device).
>>
>> Would be a pain to have to add code to every driver to cover the
>fixed
>> case.
>
>We still have to add code to every driver to cover the fixed case since
>the
>mode of operation is inherently different. But it would be nice to have
>a
>coherent way of doing so with a standardized interface rather than
>having
>every device come up with its own code and bindings.
Agreed. Not totally obvious how to do it but definitely don't want to work around it by custom bindings all over the place.
A simple is_gpo_fixed or similar would get the driver the info it needs. Could do it with errors
but that would perhaps be ugly!
The other flags related to type of input/output can be emulated so there doesn't seem to be anything similar...
>
>This could either be handled directly by the GPIO API or by a small set
>of
>helper functions on top of it.
>
>I think the most important part for now is to agree on a standard
>binding to
>describe hardwired GPIOs. We can still rework the kernel API later on,
>but
>the DT bindings will be set in stone.
Agreed. Some magic gpio description or a fake gpio chip similar to fixed regs?
Jonathan
>--
>To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
^ permalink raw reply
* [Buildroot] [PATCH 2/3] uboot-tools: bump to version 2016.11
From: Fabio Estevam @ 2016-11-14 17:26 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1479144385-27214-1-git-send-email-festevam@gmail.com>
Signed-off-by: Fabio Estevam <festevam@gmail.com>
---
package/uboot-tools/uboot-tools.hash | 2 +-
package/uboot-tools/uboot-tools.mk | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/package/uboot-tools/uboot-tools.hash b/package/uboot-tools/uboot-tools.hash
index db60dab..5b2c3bf 100644
--- a/package/uboot-tools/uboot-tools.hash
+++ b/package/uboot-tools/uboot-tools.hash
@@ -1,2 +1,2 @@
# Locally computed:
-sha256 95728e89dd476d17428f94080752ab48884be477b6a678941582aeef618b70bb u-boot-2016.09.01.tar.bz2
+sha256 45813e6565dcc0436abe6752624324cdbf5f3ac106570d76d32b46ec529bcdc8 u-boot-2016.11.tar.bz2
diff --git a/package/uboot-tools/uboot-tools.mk b/package/uboot-tools/uboot-tools.mk
index a3335a5..bb0cba8 100644
--- a/package/uboot-tools/uboot-tools.mk
+++ b/package/uboot-tools/uboot-tools.mk
@@ -4,7 +4,7 @@
#
################################################################################
-UBOOT_TOOLS_VERSION = 2016.09.01
+UBOOT_TOOLS_VERSION = 2016.11
UBOOT_TOOLS_SOURCE = u-boot-$(UBOOT_TOOLS_VERSION).tar.bz2
UBOOT_TOOLS_SITE = ftp://ftp.denx.de/pub/u-boot
UBOOT_TOOLS_LICENSE = GPLv2+
--
2.7.4
^ permalink raw reply related
* [Buildroot] [PATCH 1/3] boot/uboot: bump to version 2016.11
From: Fabio Estevam @ 2016-11-14 17:26 UTC (permalink / raw)
To: buildroot
Signed-off-by: Fabio Estevam <festevam@gmail.com>
---
boot/uboot/Config.in | 4 ++--
boot/uboot/uboot.hash | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/boot/uboot/Config.in b/boot/uboot/Config.in
index fabf27d..3b4bfac 100644
--- a/boot/uboot/Config.in
+++ b/boot/uboot/Config.in
@@ -38,7 +38,7 @@ choice
Select the specific U-Boot version you want to use
config BR2_TARGET_UBOOT_LATEST_VERSION
- bool "2016.09.01"
+ bool "2016.11"
config BR2_TARGET_UBOOT_CUSTOM_VERSION
bool "Custom version"
@@ -86,7 +86,7 @@ endif
config BR2_TARGET_UBOOT_VERSION
string
- default "2016.09.01" if BR2_TARGET_UBOOT_LATEST_VERSION
+ default "2016.11" if BR2_TARGET_UBOOT_LATEST_VERSION
default BR2_TARGET_UBOOT_CUSTOM_VERSION_VALUE \
if BR2_TARGET_UBOOT_CUSTOM_VERSION
default "custom" if BR2_TARGET_UBOOT_CUSTOM_TARBALL
diff --git a/boot/uboot/uboot.hash b/boot/uboot/uboot.hash
index db60dab..5b2c3bf 100644
--- a/boot/uboot/uboot.hash
+++ b/boot/uboot/uboot.hash
@@ -1,2 +1,2 @@
# Locally computed:
-sha256 95728e89dd476d17428f94080752ab48884be477b6a678941582aeef618b70bb u-boot-2016.09.01.tar.bz2
+sha256 45813e6565dcc0436abe6752624324cdbf5f3ac106570d76d32b46ec529bcdc8 u-boot-2016.11.tar.bz2
--
2.7.4
^ permalink raw reply related
* [PATCH 3/5] net: thunderx: Fix configuration of L3/L4 length checking
From: Sunil Kovvuri @ 2016-11-14 17:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114123350.GA2449@Red>
>>You could use the BIT() macro here
Thanks, will change and resubmit.
Sunil.
^ permalink raw reply
* Re: [RFC PATCH v3 02/20] x86: Set the write-protect cache mode for full PAT support
From: Tom Lendacky @ 2016-11-14 16:51 UTC (permalink / raw)
To: Kani, Toshimitsu, bp@alien8.de
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
dvyukov@google.com, corbet@lwn.net, arnd@arndb.de,
matt@codeblueprint.co.uk, linux-mm@kvack.org,
aryabinin@virtuozzo.com, tglx@linutronix.de,
konrad.wilk@oracle.com, kasan-dev@googlegroups.com,
x86@kernel.org, iommu@lists.linux-foundation.org, riel@redhat.com,
lwoodman@redhat.com, mingo@redhat.com, joro@8bytes.org,
linux-efi@vger.kernel.org, pbonzini@redhat.com, hpa@zytor.com,
luto@kernel.org, glider@google.com, linux-arch@vger.kernel.org,
linux-doc@vger.kernel.org, rkrcmar@redhat.com
In-Reply-To: <1478827480.20881.142.camel@hpe.com>
On 11/10/2016 07:26 PM, Kani, Toshimitsu wrote:
> On Thu, 2016-11-10 at 14:14 +0100, Borislav Petkov wrote:
>> + Toshi.
>>
>> On Wed, Nov 09, 2016 at 06:34:48PM -0600, Tom Lendacky wrote:
>>>
>>> For processors that support PAT, set the write-protect cache mode
>>> (_PAGE_CACHE_MODE_WP) entry to the actual write-protect value
>>> (x05).
>
> Using slot 6 may be more cautious (for the same reason slot 7 was used
> for WT), but I do not have a strong opinion for it.
>
> set_page_memtype() cannot track the use of WP type since there is no
> extra-bit available for WP, but WP is only supported by
> early_memremap_xx() interfaces in this series. So, I think we should
> just document that WP is only intended for temporary mappings at boot-
> time until this issue is resolved. Also, we need to make sure that
> this early_memremap for WP is only called after pat_init() is done.
Sounds good, I'll add documentation to cover these points.
>
> A nit - please add WP to the function header comment below.
> "This function initializes PAT MSR and PAT table with an OS-defined
> value to enable additional cache attributes, WC and WT."
Will do.
Thanks,
Tom
>
> Thanks,
> -Toshi
>
^ permalink raw reply
* Re: [PATCH tip/core/rcu 6/7] rcu: Make expedited grace periods recheck dyntick idle state
From: Josh Triplett @ 2016-11-14 17:25 UTC (permalink / raw)
To: Paul E. McKenney
Cc: linux-kernel, mingo, jiangshanlai, dipankar, akpm,
mathieu.desnoyers, tglx, peterz, rostedt, dhowells, edumazet,
dvhart, fweisbec, oleg, bobby.prani
In-Reply-To: <1479142633-15315-6-git-send-email-paulmck@linux.vnet.ibm.com>
On Mon, Nov 14, 2016 at 08:57:12AM -0800, Paul E. McKenney wrote:
> Expedited grace periods check dyntick-idle state, and avoid sending
> IPIs to idle CPUs, including those running guest OSes, and, on NOHZ_FULL
> kernels, nohz_full CPUs. However, the kernel has been observed checking
> a CPU while it was non-idle, but sending the IPI after it has gone
> idle. This commit therefore rechecks idle state immediately before
> sending the IPI, refraining from IPIing CPUs that have since gone idle.
>
> Reported-by: Rik van Riel <riel@redhat.com>
> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
atomic_add_return(0, ...) seems odd. Do you actually want that, rather
than atomic_read(...)? If so, can you please document exactly why?
> kernel/rcu/tree.h | 1 +
> kernel/rcu/tree_exp.h | 12 +++++++++++-
> 2 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/rcu/tree.h b/kernel/rcu/tree.h
> index e99a5234d9ed..fe98dd24adf8 100644
> --- a/kernel/rcu/tree.h
> +++ b/kernel/rcu/tree.h
> @@ -404,6 +404,7 @@ struct rcu_data {
> atomic_long_t exp_workdone1; /* # done by others #1. */
> atomic_long_t exp_workdone2; /* # done by others #2. */
> atomic_long_t exp_workdone3; /* # done by others #3. */
> + int exp_dynticks_snap; /* Double-check need for IPI. */
>
> /* 7) Callback offloading. */
> #ifdef CONFIG_RCU_NOCB_CPU
> diff --git a/kernel/rcu/tree_exp.h b/kernel/rcu/tree_exp.h
> index 24343eb87b58..d3053e99fdb6 100644
> --- a/kernel/rcu/tree_exp.h
> +++ b/kernel/rcu/tree_exp.h
> @@ -358,8 +358,10 @@ static void sync_rcu_exp_select_cpus(struct rcu_state *rsp,
> struct rcu_data *rdp = per_cpu_ptr(rsp->rda, cpu);
> struct rcu_dynticks *rdtp = &per_cpu(rcu_dynticks, cpu);
>
> + rdp->exp_dynticks_snap =
> + atomic_add_return(0, &rdtp->dynticks);
> if (raw_smp_processor_id() == cpu ||
> - !(atomic_add_return(0, &rdtp->dynticks) & 0x1) ||
> + !(rdp->exp_dynticks_snap & 0x1) ||
> !(rnp->qsmaskinitnext & rdp->grpmask))
> mask_ofl_test |= rdp->grpmask;
> }
> @@ -377,9 +379,17 @@ static void sync_rcu_exp_select_cpus(struct rcu_state *rsp,
> /* IPI the remaining CPUs for expedited quiescent state. */
> for_each_leaf_node_possible_cpu(rnp, cpu) {
> unsigned long mask = leaf_node_cpu_bit(rnp, cpu);
> + struct rcu_data *rdp = per_cpu_ptr(rsp->rda, cpu);
> + struct rcu_dynticks *rdtp = &per_cpu(rcu_dynticks, cpu);
> +
> if (!(mask_ofl_ipi & mask))
> continue;
> retry_ipi:
> + if (atomic_add_return(0, &rdtp->dynticks) !=
> + rdp->exp_dynticks_snap) {
> + mask_ofl_test |= mask;
> + continue;
> + }
> ret = smp_call_function_single(cpu, func, rsp, 0);
> if (!ret) {
> mask_ofl_ipi &= ~mask;
> --
> 2.5.2
>
^ permalink raw reply
* [OpenRISC] Nexys4DDR and OpenRISC
From: Marcus Swift @ 2016-11-14 17:25 UTC (permalink / raw)
To: openrisc
In-Reply-To: <62626c02-f6d5-acfa-9fb6-751d9fec76b5@wallentowitz.de>
Hi Stefan,
Thanks for your reply, my apologies for taking so long to get back to you.
I have been trying to apply your advice, but still have some questions!
My goal is to create a Vivado project which can generate a bitstream of the
OpenRISC SOC. This will then give me a starting point so that I can
hopefully modify and add to the SOC. From examining your 'optimsoc'
repository my understanding is that this is not the route you take. You
manage to create a SOC for the Nexys4DDR in some other way that does not
use the traditional 'fusesoc build (system)' command, and no vivado project
file is produced.
***** My Question*****
Is there any way I could create a Vivado project which contains all of the
necessary components for an OpenRISC SOC on the Nexys4DDR from your
'optimsoc' repository?
-or-
How would I create a fusesoc system which generates a OpenRISC SOC on the
Nexys4DDR Vivado project?
*************************
My attempt at answering this questions is:
- Use 'andrzej-r' fusesoc system description as before.
- Replace the xilinx cores he generates using fusesoc, with cores I
generate manually in vivado as you did.
-- This will require me to implement your 'axi2wb' adapter
If this is the best way to create a Nexys4DDR system:
- How must I edit the system top core file (
https://github.com/andrzej-r/orpsoc-cores/blob/nexys4ddr/systems/nexys4ddr/nexys4ddr_top/nexys4ddr_top.core
)
- Which Cores will I need to replace with new Cores I generate in Vivado
myself? ("nexys4ddr_clkgen", "nexys4ddr_ddr2_wb", "nexys4ddr_xadc_wb" and
"xilinx_mii_to_rmii")?
- How would I implement the "axi2wb" adapter? Can I add this to the fusesoc
system?
Please let me know if I am on the right track here! Any advice you have for
me would be very helpful! Looking forward to getting a system up and
working!
Thanks,
Marcus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.librecores.org/pipermail/openrisc/attachments/20161114/1def366d/attachment.html>
^ permalink raw reply
* [PATCH] acpi: Use NULL from <linux/stddef.h>
From: Bart Van Assche @ 2016-11-14 16:50 UTC (permalink / raw)
To: Rafael J. Wysocki, Len Brown; +Cc: linux-acpi@vger.kernel.org
Use the definition of NULL from <linux/stddef.h> instead of
redefining NULL. Additionally, change (void *)NULL into NULL.
Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Len Brown <lenb@kernel.org>
Cc: linux-acpi@vger.kernel.org
---
include/acpi/actypes.h | 12 +++++-------
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/include/acpi/actypes.h b/include/acpi/actypes.h
index 1d798ab..f019641 100644
--- a/include/acpi/actypes.h
+++ b/include/acpi/actypes.h
@@ -44,6 +44,8 @@
#ifndef __ACTYPES_H__
#define __ACTYPES_H__
+#include <linux/stddef.h> /* NULL */
+
/* acpisrc:struct_defs -- for acpisrc conversion */
/*
@@ -437,10 +439,6 @@ typedef u64 acpi_physical_address;
#endif
#define TRUE (1 == 1)
-#ifndef NULL
-#define NULL (void *) 0
-#endif
-
/*
* Miscellaneous types
*/
@@ -530,9 +528,9 @@ typedef u64 acpi_integer;
/* Pointer/Integer type conversions */
-#define ACPI_TO_POINTER(i) ACPI_ADD_PTR (void, (void *) NULL,(acpi_size) i)
-#define ACPI_TO_INTEGER(p) ACPI_PTR_DIFF (p, (void *) NULL)
-#define ACPI_OFFSET(d, f) ACPI_PTR_DIFF (&(((d *) 0)->f), (void *) NULL)
+#define ACPI_TO_POINTER(i) ACPI_ADD_PTR(void, NULL, (acpi_size) i)
+#define ACPI_TO_INTEGER(p) ACPI_PTR_DIFF(p, NULL)
+#define ACPI_OFFSET(d, f) ACPI_PTR_DIFF(&(((d *) 0)->f), NULL)
#define ACPI_PHYSADDR_TO_PTR(i) ACPI_TO_POINTER(i)
#define ACPI_PTR_TO_PHYSADDR(i) ACPI_TO_INTEGER(i)
--
2.10.1
^ permalink raw reply related
* Re: [PATCH v2] i2c: mux: fix up dependencies
From: Wolfram Sang @ 2016-11-14 17:24 UTC (permalink / raw)
To: Linus Walleij; +Cc: linux-i2c, stable, Jonathan Cameron, Peter Rosin
In-Reply-To: <1479134057-30653-1-git-send-email-linus.walleij@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 1209 bytes --]
On Mon, Nov 14, 2016 at 03:34:17PM +0100, Linus Walleij wrote:
> We get the following build error from UM Linux after adding
> an entry to drivers/iio/gyro/Kconfig that issues "select I2C_MUX":
>
> ERROR: "devm_ioremap_resource"
> [drivers/i2c/muxes/i2c-mux-reg.ko] undefined!
> ERROR: "of_address_to_resource"
> [drivers/i2c/muxes/i2c-mux-reg.ko] undefined!
>
> It appears that the I2C mux core code depends on HAS_IOMEM
> for historical reasons, while CONFIG_I2C_MUX_REG does *not*
> have a direct dependency on HAS_IOMEM.
>
> This creates a situation where a allyesconfig or allmodconfig
> for UM Linux will select I2C_MUX, and will implicitly enable
> I2C_MUX_REG as well, and the compilation will fail for the
> register driver.
>
> Fix this up by making I2C_MUX_REG depend on HAS_IOMEM and
> removing the dependency from I2C_MUX.
>
> Cc: stable@vger.kernel.org
> Reported-by: kbuild test robot <fengguang.wu@intel.com>
> Reported-by: Jonathan Cameron <jic23@jic23.retrosnub.co.uk>
> Cc: Jonathan Cameron <jic23@jic23.retrosnub.co.uk>
> Cc: Peter Rosin <peda@axentia.se>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Applied to for-current, thanks!
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: Change call ABI on PA-RISC
From: Carlos O'Donell @ 2016-11-14 17:23 UTC (permalink / raw)
To: Helge Deller; +Cc: John David Anglin, Jeff Law, linux-parisc@vger.kernel.org
In-Reply-To: <491e8502-17a3-f203-0c9a-273a988ee0ee@gmx.de>
On Mon, Nov 14, 2016 at 11:24 AM, Helge Deller <deller@gmx.de> wrote:
> What I want to archieve is to modify the return pointer, in order
> to be able to track when the function returns to his caller.
> The kernel ftracer uses this then to generate call stacks and to
> time the function.
> Looking at the above code, it should then be possible for me
> to modify -10(r3), but is there a guarantee that it's always at
> -10(r3) and that r3 is used?
> That's the reason I asked if we could modify mcount to
> give the address (in the stack) of the return pointer, but maybe
> it's just overkill for this use case ?
Why do you need to modify the value?
AFAICT ftrace uses these values heuristically e.g.
HAVE_FUNCTION_GRAPH_FP_TEST, HAVE_FUNCTION_GRAPH_RET_ADDR_PTR?
For example the only uses I see are in ftrace_pop_return_trace() and
they are purely heuristic.
Cheers,
Carlos.
^ permalink raw reply
* Re: [PATCH 2/6] dt-bindings: phy: Add documentation for NSP USB3 PHY
From: Rob Herring @ 2016-11-14 17:23 UTC (permalink / raw)
To: Yendapally Reddy Dhananjaya Reddy
Cc: Mark Rutland, Russell King, Ray Jui, Scott Branden, Jon Mason,
Florian Fainelli, Kishon Vijay Abraham I,
bcm-kernel-feedback-list, netdev, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <1478683994-12008-3-git-send-email-yendapally.reddy@broadcom.com>
On Wed, Nov 09, 2016 at 04:33:10AM -0500, Yendapally Reddy Dhananjaya Reddy wrote:
> Add documentation for USB3 PHY available in Northstar plus SoC
>
> Signed-off-by: Yendapally Reddy Dhananjaya Reddy <yendapally.reddy@broadcom.com>
> ---
> .../devicetree/bindings/phy/brcm,nsp-usb3-phy.txt | 39 ++++++++++++++++++++++
> 1 file changed, 39 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/phy/brcm,nsp-usb3-phy.txt
>
> diff --git a/Documentation/devicetree/bindings/phy/brcm,nsp-usb3-phy.txt b/Documentation/devicetree/bindings/phy/brcm,nsp-usb3-phy.txt
> new file mode 100644
> index 0000000..30cf4b9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/brcm,nsp-usb3-phy.txt
> @@ -0,0 +1,39 @@
> +Broadcom USB3 phy binding northstar plus SoC
> +This is a child bus node of "brcm,mdio-mux-nsp" node.
> +
> +Required mdio bus properties:
> +- reg: MDIO Bus number for the MDIO interface
> +- #address-cells: must be 1
> +- #size-cells: must be 0
> +
> +Required PHY properties:
> +- compatible: should be "brcm,nsp-usb3-phy"
> +- reg: Phy address in the MDIO interface
> +- usb3-ctrl-syscon: handler of syscon node defining physical address
> + of usb3 control register.
> +- #phy-cells: must be 0
> +
> +Required usb3 control properties:
> +- compatible: should be "brcm,nsp-usb3-ctrl"
> +- reg: offset and length of the control registers
> +
> +Example:
> +
> + mdio@0 {
> + reg = <0x0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + usb3_phy: usb3-phy@10 {
Just 'usb-phy@10'. With that,
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 2/6] dt-bindings: phy: Add documentation for NSP USB3 PHY
From: Rob Herring @ 2016-11-14 17:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478683994-12008-3-git-send-email-yendapally.reddy@broadcom.com>
On Wed, Nov 09, 2016 at 04:33:10AM -0500, Yendapally Reddy Dhananjaya Reddy wrote:
> Add documentation for USB3 PHY available in Northstar plus SoC
>
> Signed-off-by: Yendapally Reddy Dhananjaya Reddy <yendapally.reddy@broadcom.com>
> ---
> .../devicetree/bindings/phy/brcm,nsp-usb3-phy.txt | 39 ++++++++++++++++++++++
> 1 file changed, 39 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/phy/brcm,nsp-usb3-phy.txt
>
> diff --git a/Documentation/devicetree/bindings/phy/brcm,nsp-usb3-phy.txt b/Documentation/devicetree/bindings/phy/brcm,nsp-usb3-phy.txt
> new file mode 100644
> index 0000000..30cf4b9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/brcm,nsp-usb3-phy.txt
> @@ -0,0 +1,39 @@
> +Broadcom USB3 phy binding northstar plus SoC
> +This is a child bus node of "brcm,mdio-mux-nsp" node.
> +
> +Required mdio bus properties:
> +- reg: MDIO Bus number for the MDIO interface
> +- #address-cells: must be 1
> +- #size-cells: must be 0
> +
> +Required PHY properties:
> +- compatible: should be "brcm,nsp-usb3-phy"
> +- reg: Phy address in the MDIO interface
> +- usb3-ctrl-syscon: handler of syscon node defining physical address
> + of usb3 control register.
> +- #phy-cells: must be 0
> +
> +Required usb3 control properties:
> +- compatible: should be "brcm,nsp-usb3-ctrl"
> +- reg: offset and length of the control registers
> +
> +Example:
> +
> + mdio at 0 {
> + reg = <0x0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + usb3_phy: usb3-phy at 10 {
Just 'usb-phy at 10'. With that,
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 1/6] dt-bindings: mdio-mux: Add documentation for mdio mux for NSP SoC
From: Rob Herring @ 2016-11-14 17:22 UTC (permalink / raw)
To: Yendapally Reddy Dhananjaya Reddy
Cc: Mark Rutland, Russell King, Ray Jui, Scott Branden, Jon Mason,
Florian Fainelli, Kishon Vijay Abraham I,
bcm-kernel-feedback-list, netdev, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <1478683994-12008-2-git-send-email-yendapally.reddy@broadcom.com>
On Wed, Nov 09, 2016 at 04:33:09AM -0500, Yendapally Reddy Dhananjaya Reddy wrote:
> Add documentation for mdio mux available in Broadcom NSP SoC
>
> Signed-off-by: Yendapally Reddy Dhananjaya Reddy <yendapally.reddy@broadcom.com>
> ---
> .../devicetree/bindings/net/brcm,mdio-mux-nsp.txt | 57 ++++++++++++++++++++++
> 1 file changed, 57 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/brcm,mdio-mux-nsp.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 1/6] dt-bindings: mdio-mux: Add documentation for mdio mux for NSP SoC
From: Rob Herring @ 2016-11-14 17:22 UTC (permalink / raw)
To: Yendapally Reddy Dhananjaya Reddy
Cc: Mark Rutland, Russell King, Ray Jui, Scott Branden, Jon Mason,
Florian Fainelli, Kishon Vijay Abraham I,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1478683994-12008-2-git-send-email-yendapally.reddy-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
On Wed, Nov 09, 2016 at 04:33:09AM -0500, Yendapally Reddy Dhananjaya Reddy wrote:
> Add documentation for mdio mux available in Broadcom NSP SoC
>
> Signed-off-by: Yendapally Reddy Dhananjaya Reddy <yendapally.reddy-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> ---
> .../devicetree/bindings/net/brcm,mdio-mux-nsp.txt | 57 ++++++++++++++++++++++
> 1 file changed, 57 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/brcm,mdio-mux-nsp.txt
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
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
* [PATCH 1/6] dt-bindings: mdio-mux: Add documentation for mdio mux for NSP SoC
From: Rob Herring @ 2016-11-14 17:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478683994-12008-2-git-send-email-yendapally.reddy@broadcom.com>
On Wed, Nov 09, 2016 at 04:33:09AM -0500, Yendapally Reddy Dhananjaya Reddy wrote:
> Add documentation for mdio mux available in Broadcom NSP SoC
>
> Signed-off-by: Yendapally Reddy Dhananjaya Reddy <yendapally.reddy@broadcom.com>
> ---
> .../devicetree/bindings/net/brcm,mdio-mux-nsp.txt | 57 ++++++++++++++++++++++
> 1 file changed, 57 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/brcm,mdio-mux-nsp.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH] t0021, t5615: use $PWD instead of $(pwd) in PATH-like shell variables
From: Junio C Hamano @ 2016-11-14 17:21 UTC (permalink / raw)
To: Lars Schneider; +Cc: Johannes Schindelin, Johannes Sixt, git, Jeff King
In-Reply-To: <0BEC2674-20B5-4AD1-851A-97CA34C0CE7F@gmail.com>
Lars Schneider <larsxschneider@gmail.com> writes:
>> On 13 Nov 2016, at 02:13, Junio C Hamano <gitster@pobox.com> wrote:
>> ...
>> Earlier you said 'pu' did even not build, but do we know where this
>> "still times out" comes from? As long as I don't merge anything
>> prematurely, which I need to be careful about, it shouldn't impact
>> the upcoming release, but we'd need to figure it out before moving
>> things forward post release.
>
> What is the goal for 'pu'?
>
> (1) Builds clean on all platforms + passes all tests
> (2) Builds clean on all platforms
> (3) Builds clean on Linux
> (4) Just makes new topics easily available to a broader audience
>
> My understanding was always (4) but the discussion above sounds
> more like (1) or (2)?
The purpose of 'pu' is none of the above, but its intended effect
for people other than me is (4). It is primarily meant as a way for
me to avoid having to go back to the mailing list archive to find
topics that I felt that were potentially interesting but not yet
ready and may want to get commented on later. When queued on 'pu',
it is not unusual that I haven't really looked at the patches yet,
and it is not surprising if it does not build on any platform.
When queued to 'pu', the reason of the initial "not yet ready"
assessment may not have anything to do with the quality of the
patches but based on the phase of the development (e.g. during a
feature-freeze, it is less efficient use of our time to take new
topics to 'next'), so what was queued on 'pu' may get merged to
'next' without any update, after getting looked at by me or by
other people and deemed to be worth trying out.
Dscho's mention of 'still times out' may be an indiciation that
something unspecified on 'pu' is not ready to be merged to 'next',
but blocking all of 'pu' with a blanket statement is not useful,
and that was where my response comes from. We need to know more
to say "this particular topic is not ready", so that we can unblock
other innocent topics.
^ permalink raw reply
* Re: [PATCH tip/core/rcu 5/7] torture: Trace long read-side delays
From: Josh Triplett @ 2016-11-14 17:21 UTC (permalink / raw)
To: Paul E. McKenney
Cc: linux-kernel, mingo, jiangshanlai, dipankar, akpm,
mathieu.desnoyers, tglx, peterz, rostedt, dhowells, edumazet,
dvhart, fweisbec, oleg, bobby.prani
In-Reply-To: <1479142633-15315-5-git-send-email-paulmck@linux.vnet.ibm.com>
On Mon, Nov 14, 2016 at 08:57:11AM -0800, Paul E. McKenney wrote:
> Although rcutorture will occasionally do a 50-millisecond grace-period
> delay, these delays are quite rare. And rightly so, because otherwise
> the read rate would be quite low. Thie means that it can be important
> to identify whether or not a given run contained a long-delay read.
> This commit therefore inserts a trace_rcu_torture_read() event to flag
> runs containing long delays.
>
> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
A couple of apparent typos below. With those fixed:
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
> include/trace/events/rcu.h | 5 ++++-
> kernel/rcu/rcutorture.c | 11 ++++++++++-
> 2 files changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/include/trace/events/rcu.h b/include/trace/events/rcu.h
> index d3e756539d44..b31e05bc8e26 100644
> --- a/include/trace/events/rcu.h
> +++ b/include/trace/events/rcu.h
> @@ -698,7 +698,10 @@ TRACE_EVENT(rcu_batch_end,
> /*
> * Tracepoint for rcutorture readers. The first argument is the name
> * of the RCU flavor from rcutorture's viewpoint and the second argument
> - * is the callback address.
> + * is the callback address. The third callback is the start time in
> + * seconds, and the last two arguments are the grace period numbers
> + * and the beginning and end of the read, respectively. Note that the
> + * callback address can be NULL.
s/third callback/third argument/?
Also, s/and the beginning/of the beginning/?
> TRACE_EVENT(rcu_torture_read,
>
> diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
> index bf08fee53dc7..87c51225ceec 100644
> --- a/kernel/rcu/rcutorture.c
> +++ b/kernel/rcu/rcutorture.c
> @@ -289,15 +289,24 @@ static int rcu_torture_read_lock(void) __acquires(RCU)
>
> static void rcu_read_delay(struct torture_random_state *rrsp)
> {
> + unsigned long started;
> + unsigned long completed;
> const unsigned long shortdelay_us = 200;
> const unsigned long longdelay_ms = 50;
> + unsigned long long ts;
>
> /* We want a short delay sometimes to make a reader delay the grace
> * period, and we want a long delay occasionally to trigger
> * force_quiescent_state. */
>
> - if (!(torture_random(rrsp) % (nrealreaders * 2000 * longdelay_ms)))
> + if (!(torture_random(rrsp) % (nrealreaders * 2000 * longdelay_ms))) {
> + started = cur_ops->completed();
> + ts = rcu_trace_clock_local();
> mdelay(longdelay_ms);
> + completed = cur_ops->completed();
> + do_trace_rcu_torture_read(cur_ops->name, NULL, ts,
> + started, completed);
> + }
> if (!(torture_random(rrsp) % (nrealreaders * 2 * shortdelay_us)))
> udelay(shortdelay_us);
> #ifdef CONFIG_PREEMPT
> --
> 2.5.2
>
^ permalink raw reply
* [lustre-devel] [PATCH v4] staging: lustre: mdc: manage number of modify RPCs in flight
From: Greg Kroah-Hartman @ 2016-11-14 17:20 UTC (permalink / raw)
To: James Simmons
Cc: devel, Andreas Dilger, Linux Kernel Mailing List, Gregoire Pichon,
Oleg Drokin, Lustre Development List
In-Reply-To: <alpine.LFD.2.20.1611141656220.29600@casper.infradead.org>
On Mon, Nov 14, 2016 at 04:59:48PM +0000, James Simmons wrote:
>
> > On Thu, Nov 10, 2016 at 10:51:13AM -0500, James Simmons wrote:
> > > From: Gregoire Pichon <gregoire.pichon@bull.net>
> > >
> > > This patch is the main client part of a new feature that supports
> > > multiple modify metadata RPCs in parallel. Its goal is to improve
> > > metadata operations performance of a single client, while maintening
> > > the consistency of MDT reply reconstruction and MDT recovery
> > > mechanisms.
> > >
> > > It allows to manage the number of modify RPCs in flight within
> > > the client obd structure and to assign a virtual index (the tag) to
> > > each modify RPC to help server side cleaning of reply data.
> > >
> > > The mdc component uses this feature to send multiple modify RPCs
> > > in parallel.
> >
> > Is this a new feature? Why should we take this now and not just wait
> > until the code is out of staging?
>
> Yes on the server side. So the problem on our meta data servers couldn't
> handle writing mulitiple bits of data to the back end disk at ths same
> time.
>
> One client side the issue was the metadata operations were being
> serialized by a mutex in the MDC layer. That is what this patch fixed.
> So for the client it would be a performance improvement patch.
So, it's a "performance" patch, which isn't functionality, so why should
we merge this to staging now? Why aren't people working on the known
coding issues to get this out of staging instead of working on
performance stuff?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v2] PCI: create revision file in sysfs
From: Bjorn Helgaas @ 2016-11-14 17:20 UTC (permalink / raw)
To: Emil Velikov; +Cc: Greg KH, ML dri-devel, Bjorn Helgaas, Linux PCI
In-Reply-To: <CACvgo50V+wcibUHkpdsFJa_q+K2=k1T2UzsJ2gmdc3NGo+7qUQ@mail.gmail.com>
On Fri, Nov 11, 2016 at 06:56:51PM +0000, Emil Velikov wrote:
> Hi Bjorn,
>
> On 11 November 2016 at 14:49, Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Fri, Nov 11, 2016 at 12:31:47AM +0000, Emil Velikov wrote:
> >> On 10 November 2016 at 23:59, Bjorn Helgaas <helgaas@kernel.org> wrote:
> >> > Hi Emil,
> >> >
> >> > On Thu, Nov 10, 2016 at 01:14:35PM +0000, Emil Velikov wrote:
> >> >> On 10 November 2016 at 07:13, Greg KH <gregkh@linuxfoundation.org> wrote:
> >> >> > On Wed, Nov 09, 2016 at 04:56:07PM +0000, Emil Velikov wrote:
> >> >> >> From: Emil Velikov <emil.velikov@collabora.com>
> >> >> >>
> >> >> >> Currently the revision isn't available via sysfs/libudev thus if one
> >> >> >> wants to know the value they need to read through the config file.
> >> >> >>
> >> >> >> This in itself wakes/powers up the device, causing unwanted delays.
> >> >> >>
> >> >> >> There are at least two userspace components which could make use the new
> >> >> >> file - libpciaccess and libdrm. At the moment the former will wake up
> >> >> >> _every_ PCI device for simple invocation of glxinfo [when using Mesa
> >> >> >> 10.0+ drivers]. While the latter [in association with Mesa 13.0] can
> >> >> >> lead to 2-3 second delays while starting firefox, thunderbird or
> >> >> >> chromium.
> >> >
> >> > I agree, these unwanted delays are completely unacceptable. My
> >> > question is whether we should fix them by exporting more information
> >> > from the kernel, or by changing the way the userspace components work.
> >> >
> >> > It should not take anywhere near 2 seconds to wake up a PCI device.
> >> > That makes me think there's a more serious problem than just a lack of
> >> > caching for the revision field, e.g., maybe we're looking at far more
> >> > PCI devices than we need to, or we're doing it many times to the same
> >> > device, or ...
> >> >
> >> > If I understand correctly, the delay was bisected to
> >> > https://cgit.freedesktop.org/mesa/mesa/commit/?id=be239326aa4f, which
> >> > removed a bunch of code that looked up the vendor and device IDs, and
> >> > replaced it with drmGetDevice(). And apparently drmGetDevice(), in
> >> > this path:
> >> >
> >> > drmGetDevice
> >> > drmProcessPciDevice
> >> > drmParsePciDeviceInfo
> >> >
> >> > is a little more thorough in that it looks up the *revision* in
> >> > addition to the vendor and device IDs. So we pay the cost for the
> >> > revision even though in this instance we don't care about the revision
> >> > at all.
> >> >
> >> Above all, apologies for all the "lovely" code that you had to go
> >> through for these.
> >> And yes, you've got it spot on.
> >>
> >> > drmParsePciDeviceInfo() currently reads the whole config header from
> >> > sysfs (https://cgit.freedesktop.org/drm/libdrm/tree/xf86drm.c#n2949),
> >> > but I think you're extending that to try the vendor, device,
> >> > subsystem_vendor, subsystem_device, and (if present) revision sysfs
> >> > files first (http://www.spinics.net/lists/dri-devel/msg122319.html).
> >> >
> >> Yes, making the revision file optional and "faking it" was my first
> >> thought, esp. since we don't have any users of it (yet).
> >> Although people are not too keen on it, so we'll likely opt for
> >> revision-less API.
> >>
> >> > Bottom line, I guess I'm not super opposed to this, but I do feel like
> >> > we're making a kernel change to cover up a userspace problem, and I
> >> > think it would be better to push on that userspace problem a little
> >> > more.
> >> >
> >> Yes, definitely we can beat some sense into userspace. Yet that
> >> shouldn't be a deterrent for exposing the revision.
> >
> > Maybe. If we speed things up by extending this kernel ABI, there's
> > much less incentive to optimize the userspace stuff. I feel a little
> > bit like an enabler for undesirable userspace behavior :)
> >
> Yes, fixing userspace to not do silly things is the goal. But at the
> same time even if userspace is perfect, there is no reason to power on
> the device just to get the revision field, is it ?
> Especially since everything else is readily available.
>
> >> As hinted before the other prominent user libpciaccess wakes up probes
> >> _every_ pci device.
> >
> > Is it really necessary to probe *every* PCI device? That doesn't
> > sound like a scalable design.
> >
> > As you can tell, the argument that "we should add this kernel ABI to
> > make suboptimal userspace algorithms go faster" doesn't feel very
> > compelling to me.
> >
> "Don't shoot the messenger" comes to mind. I'm just the stupid^Wnice
> person who's trying to untangle unfortunate design decisions - don't
> force me to rewrite more than a dozen pieces of software, please ?
> Even then, I wonder how long it'll take for those to hit end users.
Pre-be239326aa4f, you had:
int libudev_get_pci_id_for_fd(int fd, int *vendor_id, int *chip_id)
int sysfs_get_pci_id_for_fd(int fd, int *vendor_id, int *chip_id)
int drm_get_pci_id_for_fd(int fd, int *vendor_id, int *chip_id)
None of them returned the revision. There was some duplicated code,
but it was apparently functional and fast.
be239326aa4f removed libudev_get_pci_id_for_fd() and
sysfs_get_pci_id_for_fd(), which made the code prettier. It also
changed drm_get_pci_id_for_fd() to use drmGetDevice() instead of the
awful hard-coding of vendor/device IDs based on drmGetVersion()->name.
But drmGetDevice() also returns the revision, which we don't need.
If you applied http://www.spinics.net/lists/dri-devel/msg122319.html,
you'd have code that's fast but unreliable (as you pointed out, it
returns the revision on new kernels, but 0 on old kernels, with no
hint to the caller about whether the revision is accurate).
If the caller can say "I don't care about the revision", e.g.,
http://www.spinics.net/lists/dri-devel/msg123013.html, you can make
drm_get_pci_id_for_fd() fast again. But it will be fast and
functional even if the kernel doesn't export a "revision" sysfs file.
So what's the benefit of adding it? This seems like a long circular
chain of making things simpler in one area but having to add new
complications in another to compensate.
Bjorn
^ permalink raw reply
* Re: [Qemu-devel] [qemu patch 2/2] kvmclock: reduce kvmclock difference on migration
From: Paolo Bonzini @ 2016-11-14 17:20 UTC (permalink / raw)
To: Marcelo Tosatti
Cc: kvm, qemu-devel, Dr. David Alan Gilbert, Juan Quintela,
Radim Krcmar, Eduardo Habkost
In-Reply-To: <20161114171318.GA6336@amt.cnet>
On 14/11/2016 18:13, Marcelo Tosatti wrote:
> On Mon, Nov 14, 2016 at 05:43:33PM +0100, Paolo Bonzini wrote:
>>
>>
>> On 14/11/2016 16:40, Marcelo Tosatti wrote:
>>> static bool kvmclock_src_use_reliable_get_clock(void *opaque)
>>> {
>>> KVMClockState *s = opaque;
>>>
>>> /*
>>> * On machine types that support reliable KVM_GET_CLOCK,
>>> * if host kernel does provide reliable KVM_GET_CLOCK,
>>> * set src_use_reliable_get_clock=true so that destination
>>> * avoids reading kvmclock from memory.
>>> */
>>> if (s->mach_use_reliable_get_clock && kvm_has_adjust_clock_stable())
>>> {
>>> s->src_use_reliable_get_clock = true;
>>> }
>>>
>>> return s->mach_use_reliable_get_clock;
>>> }
>>>
>>>
>>> Ah, OK, done.
>>
>> s->src_use_reliable_get_clock should not be set with
>> KVM_CHECK_EXTENSION, but rather from the flags returned by KVM_GET_CLOCK.
>
> Well, thats not right: What matters is the presence of get_kvmclock_ns
> which returns a value that the guest sees.
>
> get_kernel_monotonic_clock() + kvmclock_offset +
> (rdtsc() - tsc_timestamp)
>
> IOW what the guest sees. And you changed that in
>
> commit 108b249c453dd7132599ab6dc7e435a7036c193f
> Author: Paolo Bonzini <pbonzini@redhat.com>
> Date: Thu Sep 1 14:21:03 2016 +0200
>
> KVM: x86: introduce get_kvmclock_ns
>
> And the correct behaviour (once KVM_GET_CLOCK is fixed per
> previous message to return rdtsc - tsc_timestamp for the
> non masterclock case) depends on this commit above,
> not on masterclock.
This commit in turn only gets the correct behavior if
"vcpu->arch.hv_clock.flags & PVCLOCK_TSC_STABLE_BIT" (and it will be
changed soon to ka->use_masterclock). KVM_CHECK_EXTENSION can still
return KVM_CLOCK_TSC_STABLE even if the masterclock is disabled,
because KVM_CHECK_EXTENSION only tells you which flags are known for
this version of the KVM module.
To see if the masterclock is enabled _now_, you need to check what
KVM_GET_CLOCK sets in the flags. From the KVM_CLOCK_TSC_STABLE patch:
user_ns.flags = kvm->arch.use_master_clock ? KVM_CLOCK_TSC_STABLE : 0;
Thanks,
Paolo
>>> So s->src_use_reliable_get_clock is only used to indicate
>>> to the destination that: "you can use KVM_GET_CLOCK value,
>>> its safe".
>>
>> Yes, we agree. I was listing all the points, not just those where we
>> disagree. Actually I'm not sure where we disagree, except on using
>> flags from KVM_CHECK_EXTENSION vs. flags from KVM_GET_CLOCK...
>>
>> Paolo
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.