* Re: [patch] spi: atmel: fix indenting in atmel_spi_gpio_cs()
From: Nicolas Ferre @ 2016-11-14 14:49 UTC (permalink / raw)
To: Dan Carpenter; +Cc: Mark Brown, linux-spi, kernel-janitors
In-Reply-To: <20161114142644.GA6179@mwanda>
Le 14/11/2016 à 15:26, Dan Carpenter a écrit :
> These lines were indented one extra tab.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Oh yes: sorry for that:
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Thanks, Dan. Best regards,
> diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
> index d3affa6..b293149 100644
> --- a/drivers/spi/spi-atmel.c
> +++ b/drivers/spi/spi-atmel.c
> @@ -1510,15 +1510,15 @@ static int atmel_spi_gpio_cs(struct platform_device *pdev)
> int cs_gpio = of_get_named_gpio(pdev->dev.of_node,
> "cs-gpios", i);
>
> - if (cs_gpio == -EPROBE_DEFER)
> - return cs_gpio;
> -
> - if (gpio_is_valid(cs_gpio)) {
> - ret = devm_gpio_request(&pdev->dev, cs_gpio,
> - dev_name(&pdev->dev));
> - if (ret)
> - return ret;
> - }
> + if (cs_gpio == -EPROBE_DEFER)
> + return cs_gpio;
> +
> + if (gpio_is_valid(cs_gpio)) {
> + ret = devm_gpio_request(&pdev->dev, cs_gpio,
> + dev_name(&pdev->dev));
> + if (ret)
> + return ret;
> + }
> }
>
> return 0;
>
--
Nicolas Ferre
^ permalink raw reply
* Re: [patch] spi: atmel: fix indenting in atmel_spi_gpio_cs()
From: Nicolas Ferre @ 2016-11-14 14:49 UTC (permalink / raw)
To: Dan Carpenter; +Cc: Mark Brown, linux-spi, kernel-janitors
In-Reply-To: <20161114142644.GA6179@mwanda>
Le 14/11/2016 à 15:26, Dan Carpenter a écrit :
> These lines were indented one extra tab.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Oh yes: sorry for that:
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Thanks, Dan. Best regards,
> diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
> index d3affa6..b293149 100644
> --- a/drivers/spi/spi-atmel.c
> +++ b/drivers/spi/spi-atmel.c
> @@ -1510,15 +1510,15 @@ static int atmel_spi_gpio_cs(struct platform_device *pdev)
> int cs_gpio = of_get_named_gpio(pdev->dev.of_node,
> "cs-gpios", i);
>
> - if (cs_gpio = -EPROBE_DEFER)
> - return cs_gpio;
> -
> - if (gpio_is_valid(cs_gpio)) {
> - ret = devm_gpio_request(&pdev->dev, cs_gpio,
> - dev_name(&pdev->dev));
> - if (ret)
> - return ret;
> - }
> + if (cs_gpio = -EPROBE_DEFER)
> + return cs_gpio;
> +
> + if (gpio_is_valid(cs_gpio)) {
> + ret = devm_gpio_request(&pdev->dev, cs_gpio,
> + dev_name(&pdev->dev));
> + if (ret)
> + return ret;
> + }
> }
>
> return 0;
>
--
Nicolas Ferre
--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" 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 v4 0/6] perf report: Show branch flags/cycles in --branch-history callgraph view
From: Andi Kleen @ 2016-11-14 14:49 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Andi Kleen, Jin Yao, jolsa, Linux-kernel, kan.liang
In-Reply-To: <20161114143056.GD27058@kernel.org>
On Mon, Nov 14, 2016 at 11:30:56AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Mon, Oct 31, 2016 at 09:19:48AM +0800, Jin Yao escreveu:
> > v4: Update according to Andi's comments. The requirement is not displaying
> > the number of removed loops. It needs to display the average number of
> > iterations. It computes out the number of iterations by counting
> > the removed loops.
> >
> > v3: 1. Display the count for tsx abort, remove the abort percentage.
> >
> > 2. Since the branch history code has a loop detection that removes
> > small loops in util/machine.c:remove_loops(). It would be nice to
> > note how many loops were removed. So it adds the note on some
> > callchain entries.
> >
> > v2: Just a rebase to Arnaldo's perf/core branch, no functional changes.
>
> Andi, are you ok with this now? Can I have your Acked-by or Tested-by?
Yes it looks good to me now.
Acked-by: Andi Kleen <ak@linux.intel.com>
-Andi
^ permalink raw reply
* Re: [PATCH 1/2] Add Documentation for Media Device, Video Device, and Synopsys DW MIPI CSI-2 Host
From: Laurent Pinchart @ 2016-11-14 14:49 UTC (permalink / raw)
To: Ramiro Oliveira
Cc: robh+dt, mark.rutland, mchehab, devicetree, linux-kernel,
linux-media, davem, gregkh, geert+renesas, akpm, linux, hverkuil,
laurent.pinchart+renesas, arnd, sudipm.mukherjee, tiffany.lin,
minghsiu.tsai, jean-christophe.trotin, andrew-ct.chen,
simon.horman, songjun.wu, bparrot, CARLOS.PALMINHA
In-Reply-To: <160acd0770e0685330ba8e7445423c1d6f34658e.1479132355.git.roliveir@synopsys.com>
Hi Ramiro,
Thank you for the patch.
On Monday 14 Nov 2016 14:20:22 Ramiro Oliveira wrote:
> Add documentation for Media and Video Device, as well as the DW MIPI CSI-2
> Host.
>
> Signed-off-by: Ramiro Oliveira <roliveir@synopsys.com>
> ---
> .../devicetree/bindings/media/snps,dw-mipi-csi.txt | 27 +++++++++++++++++++
> .../devicetree/bindings/media/snps,plat-ipk.txt | 9 ++++++++
> .../bindings/media/snps,video-device.txt | 12 ++++++++++
> 3 files changed, 48 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/media/snps,dw-mipi-csi.txt create mode
> 100644 Documentation/devicetree/bindings/media/snps,plat-ipk.txt create
> mode 100644 Documentation/devicetree/bindings/media/snps,video-device.txt
>
> diff --git a/Documentation/devicetree/bindings/media/snps,dw-mipi-csi.txt
> b/Documentation/devicetree/bindings/media/snps,dw-mipi-csi.txt new file
> mode 100644
> index 0000000..bec7441
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/snps,dw-mipi-csi.txt
> @@ -0,0 +1,27 @@
> +Synopsys DesignWare CSI-2 Host controller
> +
> +Description
> +-----------
> +
> +This HW block is used to receive image coming from an MIPI CSI-2 compatible
> +camera.
And what does it do after receiving the stream ? A more detailed description
would be useful. Is there any public documentation for this IP core ?
> +Required properties:
> +- compatible: shall be "snps,dw-mipi-csi"
> +- reg : physical base address and size of the device memory
mapped
> + registers;
> +- interrupts : CSI-2 Host interrupt
> +- data-lanes : Number of lanes to be used
Is that fixed at synthesis time or configurable at runtime ?
> +- output-type : Core output to be used (IPI-> 0 or IDI->1 or BOTH->2)
What are IPI and IDI ?
> +- phys, phy-names: List of one PHY specifier and identifier string (as
> defined
> + in Documentation/devicetree/bindings/phy/phy-bindings.txt).
A PHY for what ?
> +Optional properties(if in IPI mode):
> +- ipi-mode : Mode to be used when in IPI(Camera -> 0 or Automatic -> 1)
> +- ipi-color-mode: Color depth to be used in IPI (48 bits -> 0 or 16 bits ->
> 1)
> +- ipi-auto-flush: Data auto-flush (1 -> Yes or 0 -> No)
> +- virtual-channel: Virtual channel where data is present when in IPI
We need more details than that, this is impossible to review, sorry.
> +The per-board settings:
> + - port sub-node describing a single endpoint connected to the dw-mipi-csi
> + as described in video-interfaces.txt[1].
An example would be nice.
> diff --git a/Documentation/devicetree/bindings/media/snps,plat-ipk.txt
> b/Documentation/devicetree/bindings/media/snps,plat-ipk.txt new file mode
> 100644
> index 0000000..2d51541
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/snps,plat-ipk.txt
> @@ -0,0 +1,9 @@
> +Synopsys DesignWare CSI-2 Host IPK Media Device
> +
> +This Media Device at the moment is not totally functional, however it is a
> base
> +for the future.
Then let's add it later :-) We don't want to design incomplete transient DT
bindings.
> +Required properties:
> +
> +- compatible: Must be "snps,plat-ipk".
> +
> diff --git a/Documentation/devicetree/bindings/media/snps,video-device.txt
> b/Documentation/devicetree/bindings/media/snps,video-device.txt new file
> mode 100644
> index 0000000..d467092
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/snps,video-device.txt
> @@ -0,0 +1,12 @@
> +Synopsys DesignWare CSI-2 Host video device
> +
> +This driver handles all the video handling part of this platform.
This is a DT binding documentation, drivers are irrelevant. You should
describe the hardware only.
More information is needed, based on this document I can't tell what the
"CSI-2 host video device" is.
> +Required properties:
> +
> +- compatible: Must be "snps,video-device".
> +
> +- dmas, dma-names: List of one DMA specifier and identifier string (as
> defined
> + in Documentation/devicetree/bindings/dma/dma.txt) per port. Each port
> + requires a DMA channel with the identifier string set to "port" followed
> by
> + the port index.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [net-next:master 664/670] drivers/net/ethernet/amd/xgbe/xgbe-phy-v2.c:1421:7-9: WARNING: possible condition with no effect (if == else)
From: Tom Lendacky @ 2016-11-14 14:49 UTC (permalink / raw)
To: Julia Lawall; +Cc: netdev, kbuild-all
In-Reply-To: <alpine.DEB.2.20.1611131910380.1946@hadrien>
On 11/13/2016 12:12 PM, Julia Lawall wrote:
> It looks like the code on lines 1422 and 1424 is the same, so either the
> test may be unnecessary, or one of the branches is wrong.
I was trying to show that for a cable length of less than 5 meters I was
using a specific sub-command and that for anything longer I was falling
back to the 5 meter value. I can see how it doesn't look right and I'll
clean it up with a patch.
>
> Coccinelle is also comparing about a comparison on an unsigned value in
> line 1900, but the code for that is not listed in the report below.
Ok, good catch. I'll fix this up with a patch also.
Thanks,
Tom
>
> julia
>
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git master
> head: f7ad3d4b83e694347cddc96d956143068bef32c9
> commit: abf0a1c2b26ad964d19b143ce46735e1b0667f29 [664/670] amd-xgbe: Add support for SFP+ modules
> :::::: branch date: 16 minutes ago
> :::::: commit date: 12 hours ago
>
>>> drivers/net/ethernet/amd/xgbe/xgbe-phy-v2.c:1421:7-9: WARNING: possible condition with no effect (if == else)
> --
>>> drivers/net/ethernet/amd/xgbe/xgbe-phy-v2.c:1900:6-9: WARNING: Unsigned expression compared with zero: ret < 0
>
> git remote add net-next https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
> git remote update net-next
> git checkout abf0a1c2b26ad964d19b143ce46735e1b0667f29
> vim +1421 drivers/net/ethernet/amd/xgbe/xgbe-phy-v2.c
>
> abf0a1c2 Lendacky, Thomas 2016-11-10 1405 {
> abf0a1c2 Lendacky, Thomas 2016-11-10 1406 struct xgbe_phy_data *phy_data = pdata->phy_data;
> abf0a1c2 Lendacky, Thomas 2016-11-10 1407 unsigned int s0;
> abf0a1c2 Lendacky, Thomas 2016-11-10 1408
> abf0a1c2 Lendacky, Thomas 2016-11-10 1409 xgbe_phy_start_ratechange(pdata);
> abf0a1c2 Lendacky, Thomas 2016-11-10 1410
> abf0a1c2 Lendacky, Thomas 2016-11-10 1411 /* 10G/SFI */
> abf0a1c2 Lendacky, Thomas 2016-11-10 1412 s0 = 0;
> abf0a1c2 Lendacky, Thomas 2016-11-10 1413 XP_SET_BITS(s0, XP_DRIVER_SCRATCH_0, COMMAND, 3);
> abf0a1c2 Lendacky, Thomas 2016-11-10 1414 if (phy_data->sfp_cable != XGBE_SFP_CABLE_PASSIVE) {
> abf0a1c2 Lendacky, Thomas 2016-11-10 1415 XP_SET_BITS(s0, XP_DRIVER_SCRATCH_0, SUB_COMMAND, 0);
> abf0a1c2 Lendacky, Thomas 2016-11-10 1416 } else {
> abf0a1c2 Lendacky, Thomas 2016-11-10 1417 if (phy_data->sfp_cable_len <= 1)
> abf0a1c2 Lendacky, Thomas 2016-11-10 1418 XP_SET_BITS(s0, XP_DRIVER_SCRATCH_0, SUB_COMMAND, 1);
> abf0a1c2 Lendacky, Thomas 2016-11-10 1419 else if (phy_data->sfp_cable_len <= 3)
> abf0a1c2 Lendacky, Thomas 2016-11-10 1420 XP_SET_BITS(s0, XP_DRIVER_SCRATCH_0, SUB_COMMAND, 2);
> abf0a1c2 Lendacky, Thomas 2016-11-10 @1421 else if (phy_data->sfp_cable_len <= 5)
> abf0a1c2 Lendacky, Thomas 2016-11-10 1422 XP_SET_BITS(s0, XP_DRIVER_SCRATCH_0, SUB_COMMAND, 3);
> abf0a1c2 Lendacky, Thomas 2016-11-10 1423 else
> abf0a1c2 Lendacky, Thomas 2016-11-10 1424 XP_SET_BITS(s0, XP_DRIVER_SCRATCH_0, SUB_COMMAND, 3);
> abf0a1c2 Lendacky, Thomas 2016-11-10 1425 }
> abf0a1c2 Lendacky, Thomas 2016-11-10 1426
> abf0a1c2 Lendacky, Thomas 2016-11-10 1427 /* Call FW to make the change */
> abf0a1c2 Lendacky, Thomas 2016-11-10 1428 XP_IOWRITE(pdata, XP_DRIVER_SCRATCH_0, s0);
> abf0a1c2 Lendacky, Thomas 2016-11-10 1429 XP_IOWRITE(pdata, XP_DRIVER_SCRATCH_1, 0);
>
> ---
> 0-DAY kernel test infrastructure Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
>
^ permalink raw reply
* Re: [PATCH 0/2] Two cpp41 pm runtime found when testing with usb
From: Tony Lindgren @ 2016-11-14 14:49 UTC (permalink / raw)
To: Vinod Koul
Cc: Dan Williams, Bin Liu, Daniel Mack, Felipe Balbi, George Cherian,
Johan Hovold, Peter Ujfalusi, Sebastian Andrzej Siewior,
dmaengine-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161114052830.GA3000@localhost>
* Vinod Koul <vinod.koul-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> [161113 21:19]:
> On Wed, Nov 09, 2016 at 09:47:57AM -0700, Tony Lindgren wrote:
> > Hi,
> >
> > I found two pm runtime issues when testing with usb on beaglebone.
> >
> > In the am335x case cppi41 and two instances of musb controller share
> > the same interconnect wrapper module, so any pm issues with musb or
> > cppi41 will keep the interconnect wrapper module busy.
>
> Applied both. And as I have told you previously please use the correct
> subsystem tag. I have fixed them again!
Sorry about that. What do you prefer for future reference? We are using
both "dma: cppi41" and "dmaengine: cppi41" currently..
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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 v2] net: ioctl SIOCSIFADDR minor cleanup
From: yuan linyu @ 2016-11-14 14:48 UTC (permalink / raw)
To: netdev; +Cc: davem
From: yuan linyu <Linyu.Yuan@alcatel-sbell.com.cn>
1. set interface address label to ioctl request device name is enough
2. when address pass inet_abc_len check, prefixlen < 31 is always true
Signed-off-by: yuan linyu <Linyu.Yuan@alcatel-sbell.com.cn>
---
net/ipv4/devinet.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index 062a67c..d491a7a 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -1063,10 +1063,7 @@ int devinet_ioctl(struct net *net, unsigned int cmd, void __user *arg)
if (!ifa)
break;
INIT_HLIST_NODE(&ifa->hash);
- if (colon)
- memcpy(ifa->ifa_label, ifr.ifr_name, IFNAMSIZ);
- else
- memcpy(ifa->ifa_label, dev->name, IFNAMSIZ);
+ memcpy(ifa->ifa_label, ifr.ifr_name, IFNAMSIZ);
} else {
ret = 0;
if (ifa->ifa_local == sin->sin_addr.s_addr)
@@ -1081,8 +1078,7 @@ int devinet_ioctl(struct net *net, unsigned int cmd, void __user *arg)
if (!(dev->flags & IFF_POINTOPOINT)) {
ifa->ifa_prefixlen = inet_abc_len(ifa->ifa_address);
ifa->ifa_mask = inet_make_mask(ifa->ifa_prefixlen);
- if ((dev->flags & IFF_BROADCAST) &&
- ifa->ifa_prefixlen < 31)
+ if (dev->flags & IFF_BROADCAST)
ifa->ifa_broadcast = ifa->ifa_address |
~ifa->ifa_mask;
} else {
--
2.7.4
--
^ permalink raw reply related
* Re: pmdinfogen issues: cross compilation for ARM fails with older host compiler
From: Neil Horman @ 2016-11-14 14:48 UTC (permalink / raw)
To: Jerin Jacob
Cc: Hemant Agrawal, dev@dpdk.org, users@dpdk.org, Jacob, Jerin,
Jan Viktorin
In-Reply-To: <20161113205924.GA11392@localhost.localdomain>
On Mon, Nov 14, 2016 at 02:29:24AM +0530, Jerin Jacob wrote:
> On Fri, Nov 11, 2016 at 10:34:39AM +0000, Hemant Agrawal wrote:
> > Hi Neil,
> > Pmdinfogen compiles with host compiler. It usages rte_byteorder.h of the target platform.
> > However, if the host compiler is older than 4.8, it will be an issue during cross compilation for some platforms.
> > e.g. if we are compiling on x86 host for ARM, x86 host compiler will not understand the arm asm instructions.
> >
> > /* fix missing __builtin_bswap16 for gcc older then 4.8 */
> > #if !(__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 8))
> > static inline uint16_t rte_arch_bswap16(uint16_t _x)
> > {
> > register uint16_t x = _x;
> > asm volatile ("rev16 %0,%1"
> > : "=r" (x)
> > : "r" (x)
> > );
> > return x;
> > }
> > #endif
> >
> > One easy solution is that we add compiler platform check in this code section of rte_byteorder.h
> > e.g
> > #if !(defined __arm__ || defined __aarch64__)
> > static inline uint16_t rte_arch_bswap16(uint16_t _x)
> > {
> > return (_x >> 8) | ((_x << 8) & 0xff00);
> > }
> > #else ….
> >
> > Is there a better way to fix it?
>
> IMO, It is a HOST build infrastructure issue. If a host app is using the
> dpdk service then it should compile and link against HOST target(in this
> specific case, build/x86_64-native-linuxapp-gcc). I think, introducing the
> HOSTTARGET kind of scheme is a clean solution.
>
> /Jerin
>
>
That would be accurate. That is to say, pmdinfogen is a tool that should only
be run on the host doing the build, by the host doing the build, and so should
be compiled to run on the host, not on the target being built for.
Yeah, so what we need is a way to get to the host version of rte_byteorder.h
when building in a cross environment
Neil
^ permalink raw reply
* Re: [RFC] change mac80211_hwsim tx_rates to ieee80211_tx_rate
From: Benjamin Beichler @ 2016-11-14 14:48 UTC (permalink / raw)
To: Johannes Berg, linux-wireless
In-Reply-To: <1479132555.12007.6.camel@sipsolutions.net>
> I agree with that, but there exist also other code in hwsim, which is
>> tightly coupled with the mac80211 API, as e.g., the usage of
>> IEEE80211_TX_MAX_RATES, which already broke older versions of
>> wmediumd or similar implementations. Maybe a review regarding such
>> things would be good to decouple the userspace daemon from the
>> special kernel version.
> Agree. It'd be better if that were using nested attributes etc.
> Although then again, to really decouple this we should make hwsim
> behave towards wmediumd more like real hardware would, and have it pass
> just a single rate to userspace, with only success/fail indication
> coming back - if it fails, it could walk down the chain of rates
> itself. Right now we let wmediumd do this, which is why we have all
> these API internals exposed to it.
Mhh, I thought also some atheros drivers implement hardware multirate
retry changes, which maps to this struct. Only one rate per frame would
introduce a extreme additional communication overhead, which will make
testing with standard wmediumd impractical. I think we need to keep such
a structure, but we should align that with other mac80211 depended drivers.
>
>>>> but I think that will break up the communication to e.g. bob
>>>> copelands
>>>> wmediumd and similar simulations. I would like to have our
>>>> Implementation working with mainline kernels and therefore ask
>>>> how we
>>>> could achieve this easily.
>>>>
>>>> Obviously, we could define another field in the hwsim messages,
>>>> but
>>>> as bob copeland already stated, significantly more information
>>>> within
>>>> the netlink messages could intensify the timing overhead of
>>>> hwsim.
>>> I don't think we have any other choice but add the relevant fields
>>> as
>>> proper attributes.
>> I'm totally fine with that. Nonetheless, I would suggest to add the
>> flags to "struct hwsim_tx_rate", since the flags are also tightly
>> coupled to the rates and tries of a frame. To not break up things, we
>> could add the flags as a separate attribute in the struct and not as
>> part of the bitfield like in the original. This would be possible,
>> due
>> to the "__packed" flag, but I'm also unsure, whether this is a really
>> good idea for a userspace API/ABI.
> Changing the struct size itself would break ABI though?
You are totally right ... I was a bit absent. But the point is, without
the rates and tries, the flags are useless, so I think it is better to
put them together, but I'm also fine with another attribute ;-)
Benjamin
^ permalink raw reply
* Re: [PATCH] u-boot: mkimage: Fix build of u-boot-mkimage
From: Marek Vasut @ 2016-11-14 14:48 UTC (permalink / raw)
To: Burton, Ross; +Cc: OE-core
In-Reply-To: <CAJTo0LZVXqvWmRaYHCchxLJ-Bpb86d+EQk-49J3cUZUH07Q5NQ@mail.gmail.com>
On 11/14/2016 03:45 PM, Burton, Ross wrote:
>
> On 12 November 2016 at 18:31, Marek Vasut <marex@denx.de
> <mailto:marex@denx.de>> wrote:
>
> > Also the u-boot series went through a number of revisions, can you
> > verify that the patches in poky-contrib:ross/mut match what you expect
> > to see?
>
> Do you have a link for me ?
>
>
> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=ross/mut-broken&id=4f6dbc99950da645dc4d0e23e0065ff8245a0e74
>
> As the cleanups didn't really make sense standalone, I squashed the lot.
I prefer to keep the history, but OK. It looks like what I'd expect there.
--
Best regards,
Marek Vasut
^ permalink raw reply
* Re: [PATCH 6/7] MIPS: memcpy: Use a3/$7 for source end address
From: Maciej W. Rozycki @ 2016-11-14 14:47 UTC (permalink / raw)
To: Paul Burton; +Cc: linux-mips, Ralf Baechle
In-Reply-To: <20161107111802.12071-7-paul.burton@imgtec.com>
On Mon, 7 Nov 2016, Paul Burton wrote:
> Instead of using the at/$1 register (which does not form part of the
> typical calling convention) to provide the end of the source region to
> __copy_user* functions, use the a3/$7 register. This prepares us for
> being able to call __copy_user* with a standard function call.
>
> Signed-off-by: Paul Burton <paul.burton@imgtec.com>
> ---
>
> arch/mips/cavium-octeon/octeon-memcpy.S | 8 ++++----
> arch/mips/include/asm/uaccess.h | 21 ++++++++++++---------
> arch/mips/lib/memcpy.S | 8 ++++----
> 3 files changed, 20 insertions(+), 17 deletions(-)
>
[...]
> diff --git a/arch/mips/lib/memcpy.S b/arch/mips/lib/memcpy.S
> index 48684c4..5af9f03 100644
> --- a/arch/mips/lib/memcpy.S
> +++ b/arch/mips/lib/memcpy.S
> @@ -70,13 +70,13 @@
>
> /*
> * The exception handler for loads requires that:
> - * 1- AT contain the address of the byte just past the end of the source
> + * 1- a3 contain the address of the byte just past the end of the source
> * of the copy,
> - * 2- src_entry <= src < AT, and
> + * 2- src_entry <= src < a3, and
> * 3- (dst - src) == (dst_entry - src_entry),
> * The _entry suffix denotes values when __copy_user was called.
> *
> - * (1) is set up up by uaccess.h and maintained by not writing AT in copy_user
> + * (1) is set up up by uaccess.h and maintained by not writing a3 in copy_user
> * (2) is met by incrementing src by the number of bytes copied
> * (3) is met by not doing loads between a pair of increments of dst and src
> *
> @@ -549,7 +549,7 @@
> nop
> LOADK t0, THREAD_BUADDR(t0) # t0 is just past last good address
> nop
> - SUB len, AT, t0 # len number of uncopied bytes
> + SUB len, a3, t0 # len number of uncopied bytes
> bnez ta2, .Ldone\@ /* Skip the zeroing part if inatomic */
> /*
> * Here's where we rely on src and dst being incremented in tandem,
With the lone explicit use of $at gone from this code I think you can
remove `.set noat/at=v1' pseudo-ops across this source file as well.
I think it would be good actually to do both changes with a single patch
as it will ensure that whoever comes across them in the future in a look
through our repo history will know immediately that one is a direct
consequence of the other (i.e. that we only have those `.set noat/at=v1'
pseudo-ops because of the special use of $at in this code).
Thanks for doing these clean-ups; I actually have found this use of $at
here particularly irritating.
Maciej
^ permalink raw reply
* Re: [PATCH 6/7] MIPS: memcpy: Use a3/$7 for source end address
From: Maciej W. Rozycki @ 2016-11-14 14:47 UTC (permalink / raw)
To: Paul Burton; +Cc: linux-mips, Ralf Baechle
In-Reply-To: <20161107111802.12071-7-paul.burton@imgtec.com>
On Mon, 7 Nov 2016, Paul Burton wrote:
> Instead of using the at/$1 register (which does not form part of the
> typical calling convention) to provide the end of the source region to
> __copy_user* functions, use the a3/$7 register. This prepares us for
> being able to call __copy_user* with a standard function call.
>
> Signed-off-by: Paul Burton <paul.burton@imgtec.com>
> ---
>
> arch/mips/cavium-octeon/octeon-memcpy.S | 8 ++++----
> arch/mips/include/asm/uaccess.h | 21 ++++++++++++---------
> arch/mips/lib/memcpy.S | 8 ++++----
> 3 files changed, 20 insertions(+), 17 deletions(-)
>
[...]
> diff --git a/arch/mips/lib/memcpy.S b/arch/mips/lib/memcpy.S
> index 48684c4..5af9f03 100644
> --- a/arch/mips/lib/memcpy.S
> +++ b/arch/mips/lib/memcpy.S
> @@ -70,13 +70,13 @@
>
> /*
> * The exception handler for loads requires that:
> - * 1- AT contain the address of the byte just past the end of the source
> + * 1- a3 contain the address of the byte just past the end of the source
> * of the copy,
> - * 2- src_entry <= src < AT, and
> + * 2- src_entry <= src < a3, and
> * 3- (dst - src) == (dst_entry - src_entry),
> * The _entry suffix denotes values when __copy_user was called.
> *
> - * (1) is set up up by uaccess.h and maintained by not writing AT in copy_user
> + * (1) is set up up by uaccess.h and maintained by not writing a3 in copy_user
> * (2) is met by incrementing src by the number of bytes copied
> * (3) is met by not doing loads between a pair of increments of dst and src
> *
> @@ -549,7 +549,7 @@
> nop
> LOADK t0, THREAD_BUADDR(t0) # t0 is just past last good address
> nop
> - SUB len, AT, t0 # len number of uncopied bytes
> + SUB len, a3, t0 # len number of uncopied bytes
> bnez ta2, .Ldone\@ /* Skip the zeroing part if inatomic */
> /*
> * Here's where we rely on src and dst being incremented in tandem,
With the lone explicit use of $at gone from this code I think you can
remove `.set noat/at=v1' pseudo-ops across this source file as well.
I think it would be good actually to do both changes with a single patch
as it will ensure that whoever comes across them in the future in a look
through our repo history will know immediately that one is a direct
consequence of the other (i.e. that we only have those `.set noat/at=v1'
pseudo-ops because of the special use of $at in this code).
Thanks for doing these clean-ups; I actually have found this use of $at
here particularly irritating.
Maciej
^ permalink raw reply
* Re: [PATCH v3 01/14] drm/i915: Give each sw_fence its own lockclass
From: Joonas Lahtinen @ 2016-11-14 14:48 UTC (permalink / raw)
To: Chris Wilson, intel-gfx
In-Reply-To: <20161114085703.16540-1-chris@chris-wilson.co.uk>
On ma, 2016-11-14 at 08:56 +0000, Chris Wilson wrote:
> Localise the static struct lock_class_key to the caller of
> i915_sw_fence_init() so that we create a lock_class instance for each
> unique sw_fence rather than all sw_fences sharing the same
> lock_class. This eliminate some lockdep false positive when using fences
> from within fence callbacks.
>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
<SNIP>
> @@ -40,7 +40,16 @@ typedef int (*i915_sw_fence_notify_t)(struct i915_sw_fence *,
> enum i915_sw_fence_notify state);
> #define __i915_sw_fence_call __aligned(4)
>
> -void i915_sw_fence_init(struct i915_sw_fence *fence, i915_sw_fence_notify_t fn);
> +void __i915_sw_fence_init(struct i915_sw_fence *fence,
> + i915_sw_fence_notify_t fn,
> + const char *name,
> + struct lock_class_key *key);
> +#define i915_sw_fence_init(fence, fn) do { \
Gimme a (line) break here.
> + static struct lock_class_key __key; \
When lockdep is disabled, this becomes zero size. We might still get
rid of the #fence strings, with some #ifdef, did you measure the
impact? I remember some for_each_engine_masked cry over bytes.
> + \
> + __i915_sw_fence_init((fence), fn, #fence, &__key); \
> +} while (0)
> +
Above addressed, and assuming we're not compiling in extra;
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH] dma: cpp41: Fix handling of error path
From: Tony Lindgren @ 2016-11-14 14:47 UTC (permalink / raw)
To: Johan Hovold
Cc: Dan Williams, Vinod Koul, Bin Liu, Daniel Mack, Felipe Balbi,
George Cherian, Peter Ujfalusi, Sebastian Andrzej Siewior,
dmaengine-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161114143454.GQ14744@localhost>
Hi,
* Johan Hovold <johan-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> [161114 06:35]:
> On Fri, Nov 11, 2016 at 11:28:52AM -0800, Tony Lindgren wrote:
> > If we return early on pm_runtime_get() error, we need to also call
> > pm_runtime_put_noidle() as pointed out in a musb related thread
> > by Johan Hovold <johan-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>. This is to keep the PM runtime
> > use counts happy.
> >
> > Fixes: fdea2d09b997 ("dmaengine: cppi41: Add basic PM runtime support")
> > Cc: Johan Hovold <johan-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
> > ---
> > drivers/dma/cppi41.c | 11 +++++++++--
> > 1 file changed, 9 insertions(+), 2 deletions(-)
>
> > @@ -466,6 +472,7 @@ static void cppi41_dma_issue_pending(struct dma_chan *chan)
> >
> > error = pm_runtime_get(cdd->ddev.dev);
> > if ((error != -EINPROGRESS) && error < 0) {
> > + pm_runtime_put_noidle(cdd->ddev.dev);
> > dev_err(cdd->ddev.dev, "Failed to pm_runtime_get: %i\n",
> > error);
>
> Will this chunk not introduce rather than fix an imbalance, though? An
> error is never returned above, and the corresponding put is done
> unconditionally as far as I can tell.
There is already an early return in cppi41_dma_issue_pending() on
error.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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
* ✓ Fi.CI.BAT: success for Geminilake enabling (rev5)
From: Patchwork @ 2016-11-14 14:47 UTC (permalink / raw)
To: Ander Conselvan de Oliveira; +Cc: intel-gfx
In-Reply-To: <1478791400-21756-1-git-send-email-ander.conselvan.de.oliveira@intel.com>
== Series Details ==
Series: Geminilake enabling (rev5)
URL : https://patchwork.freedesktop.org/series/15118/
State : success
== Summary ==
Series 15118v5 Geminilake enabling
https://patchwork.freedesktop.org/api/1.0/series/15118/revisions/5/mbox/
fi-bdw-5557u total:244 pass:229 dwarn:0 dfail:0 fail:0 skip:15
fi-bsw-n3050 total:244 pass:204 dwarn:0 dfail:0 fail:0 skip:40
fi-bxt-t5700 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28
fi-byt-j1900 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28
fi-byt-n2820 total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32
fi-hsw-4770 total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20
fi-hsw-4770r total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20
fi-ilk-650 total:244 pass:191 dwarn:0 dfail:0 fail:0 skip:53
fi-ivb-3520m total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22
fi-ivb-3770 total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22
fi-kbl-7200u total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22
fi-skl-6260u total:244 pass:230 dwarn:0 dfail:0 fail:0 skip:14
fi-skl-6700hq total:244 pass:223 dwarn:0 dfail:0 fail:0 skip:21
fi-skl-6700k total:244 pass:222 dwarn:1 dfail:0 fail:0 skip:21
fi-skl-6770hq total:244 pass:230 dwarn:0 dfail:0 fail:0 skip:14
fi-snb-2520m total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32
fi-snb-2600 total:244 pass:211 dwarn:0 dfail:0 fail:0 skip:33
02b726586a8230ae7630d909a263776fc11c35ad drm-intel-nightly: 2016y-11m-14d-13h-35m-49s UTC integration manifest
08e030e drm/i915/glk: Add Geminilake PCI IDs
bbb3d12 drm/i915/glk: Introduce Geminilake platform definition
a5a27da drm/i915: Create a common GEN9_LP_FEATURE.
== Logs ==
For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_2983/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: kernel BUG at fs/ext4/inode.c:2428!
From: Nikolay Borisov @ 2016-11-14 14:46 UTC (permalink / raw)
To: Jan Kara; +Cc: linux-ext4, Theodore Ts'o, Jan Kara, Andreas Dilger
In-Reply-To: <20161114134929.GJ2524@quack2.suse.cz>
On 11/14/2016 03:49 PM, Jan Kara wrote:
> Hello,
>
> On Mon 14-11-16 12:15:16, Nikolay Borisov wrote:
>> So I hit the following BUG_ON on 3 separate servers:
>>
>> [1387898.597939] sh (14886): drop_caches: 3
>> [1387945.259613] ------------[ cut here ]------------
>> [1387945.259791] kernel BUG at fs/ext4/inode.c:2428!
>> [1387945.259964] invalid opcode: 0000 [#1] SMP
>> [1387945.263921] CPU: 9 PID: 8987 Comm: kworker/u24:23 Tainted: P O 4.4.26-clouder1 #3
>> [1387945.264213] Hardware name: Supermicro X9DRD-iF/LF/X9DRD-iF, BIOS 3.2 01/16/2015
>> [1387945.264512] Workqueue: writeback wb_workfn (flush-253:8)
>> [1387945.264780] task: ffff880287ca5280 ti: ffff8800064dc000 task.ti: ffff8800064dc000
>> [1387945.265073] RIP: 0010:[<ffffffff8122a3ac>] [<ffffffff8122a3ac>] mpage_prepare_extent_to_map+0x29c/0x2d0
>> [1387945.265426] RSP: 0018:ffff8800064df960 EFLAGS: 00010246
>> [1387945.265596] RAX: 02fffc0000030039 RBX: ffff8800064dfad0 RCX: 0000000000000537
>> [1387945.265881] RDX: 000000000000231b RSI: 0000000000000000 RDI: ffffffff81a052a6
>> [1387945.266165] RBP: ffff8800064dfa28 R08: 0000000000000000 R09: 0000000000000000
>> [1387945.266450] R10: 0000000000000001 R11: 0000000000000100 R12: ffff8800064df980
>> [1387945.266734] R13: 0000000000003400 R14: ffffffffffffffff R15: ffffea000686fbc0
>> [1387945.267024] FS: 0000000000000000(0000) GS:ffff88047fd20000(0000) knlGS:0000000000000000
>> [1387945.267315] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> [1387945.267487] CR2: ffffffffff600400 CR3: 00000004555ff000 CR4: 00000000000406e0
>> [1387945.267765] Stack:
>> [1387945.267925] 0000000000000000 ffff88015b3c2be0 ffff8800064df980 0000000000000538
>> [1387945.268386] 0000000000000001 0000000000000000 ffffea000686fbc0 ffff88046bce1800
>> [1387945.268850] ffff8800064df9e8 ffffffff81274777 ffffffff02400040 0fd000086bce6800
>> [1387945.269319] Call Trace:
>> [1387945.269489] [<ffffffff81274777>] ? jbd2__journal_start+0xe7/0x200
>> [1387945.269663] [<ffffffff8122e581>] ? ext4_writepages+0x3a1/0xcd0
>> [1387945.269839] [<ffffffff8125ba8d>] ? __ext4_journal_start_sb+0x6d/0x100
>> [1387945.270013] [<ffffffff8122e5b2>] ext4_writepages+0x3d2/0xcd0
>> [1387945.270207] [<ffffffffa07f878b>] ? leaf_space_used+0xcb/0x100 [btrfs]
>> [1387945.270382] [<ffffffff810823a1>] ? sched_clock_cpu+0xa1/0xb0
>> [1387945.270556] [<ffffffff8107beb4>] ? check_preempt_curr+0x54/0x90
>> [1387945.270730] [<ffffffff8107c07d>] ? ttwu_do_activate.constprop.92+0x5d/0x70
>> [1387945.270905] [<ffffffff8113735e>] do_writepages+0x1e/0x30
>> [1387945.271076] [<ffffffff811c6c85>] __writeback_single_inode+0x45/0x370
>> [1387945.271250] [<ffffffff811c74d2>] writeback_sb_inodes+0x252/0x570
>> [1387945.271423] [<ffffffff811c7879>] __writeback_inodes_wb+0x89/0xc0
>> [1387945.271596] [<ffffffff811c7bb8>] wb_writeback+0x268/0x300
>> [1387945.271766] [<ffffffff811c83e6>] wb_workfn+0x2d6/0x400
>> [1387945.271938] [<ffffffff81614ea8>] ? _raw_spin_lock_irqsave+0x18/0x50
>> [1387945.272112] [<ffffffff8106bf89>] process_one_work+0x159/0x450
>> [1387945.272285] [<ffffffff8106c639>] worker_thread+0x69/0x490
>> [1387945.272456] [<ffffffff8106c5d0>] ? rescuer_thread+0x350/0x350
>> [1387945.272630] [<ffffffff810717bf>] kthread+0xef/0x110
>> [1387945.272803] [<ffffffff810716d0>] ? kthread_park+0x60/0x60
>> [1387945.272975] [<ffffffff816156bf>] ret_from_fork+0x3f/0x70
>> [1387945.273146] [<ffffffff810716d0>] ? kthread_park+0x60/0x60
>> [1387945.273322] Code: d2 e4 ff e8 67 6f 3e 00 48 8b 85 50 ff ff ff 49 39 c6 0f 83 15 fe ff ff 31 c0 eb a7 4c 89 ff e8 3b e8 ef ff e9 b8 fe ff ff 0f 0b <0f> 0b 48 8d bd 58 ff ff ff 89 85 48 ff ff ff e8 50 f8 f0 ff 8b
>> [1387945.276751] RIP [<ffffffff8122a3ac>] mpage_prepare_extent_to_map+0x29c/0x2d0
>> [1387945.277089] RSP <ffff8800064df960>
>>
>> So a user triggers drop_caches and ext4 crashes due to it trying to
>> write a page that isn't fs-owned. ffffffff8122a3ac is : head = page_buffers(page);
>> which has this: BUG_ON(!PagePrivate(page));
>>
>> page.flags is flags = 216168384067469369 (in binary: 0000001011111111111111000000000000000000000000110000000000111001)
>> so the 11th bit (PG_private) is not set, triggering the BUG_ON. The flags are
>> (PG_LOCKED|PG_UPTODATE|PG_DIRTY|MAPPEDTODISK|PG_RECLAIM). Do these flags seem
>> corrupt - uptodate and dirty being set at the same time? Maybe the page struct
>> is being corrupted?
>>
>> page.private is actually NULL. The page does have an associated address_space
>> mapping. I've validated this since address_space.host is the same as the
>> inode member of the passed mpd.
>
> Interesting. I didn't see this yet. What mount options does the filesystem
> use? The file where this happened is a regular file I assume, right? What
> is blocksize and page size for the filesystem?
s_blocksize_bits = 12,
s_blocksize = 4096,
And this is x86_64 so pagesize is also 4k. Unfortunately I cannot
re-mount the file system since it has been converted to btrfs. However
here are the options: rw,relatime,discard,stripe=32,data=ordered, these
have been taken from an analogous mount. This is how it's supposed to
have been created: mkfs.ext4 -b 4096 -K -E nodiscard,lazy_itable_init=1
-O has_journal,large_file,resize_inode,sparse_super,uninit_bg
Since those values are from the system which supposedly created those,
here are the raw values form the ext4_sb_info->s_mount_opt* members:
s_mount_opt = 3892496400,
s_mount_opt2 = 2,
And from ext4_super_block->s_feature_*:
s_feature_compat = 0,
s_feature_incompat = 61267,
s_feature_ro_compat = 0,
> The page flags actually look rather consistent. The only thing that is
Why is UPTODATE and DIRTY set simultaneously. Don't they contradict each
other?
> strange is how a dirty page can be without buffers because whenever we
> write to a page we create buffers for the page and then mark (some of
> those) buffers dirty. ext4_releasepage() ends up calling
> try_to_free_buffers() which does not remove dirty buffers. But apparently
> the buffers attached to a page got somehow clean but the page remained
> dirty, then ext4_releasepage() removed those buffers and then we crashed
> when trying to write that page. If blocksize < pagesize, I could imagine
> some subtle bugs in our code e.g. for pages straddling EOF...
In this case blocksize == pagesize :(
>
> Honza
>
^ permalink raw reply
* [Buildroot] [PATCH] config: bump linux kernel to 4.8.6 in synopsys defconfigs
From: Alexey Brodkin @ 2016-11-14 14:46 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20161114154211.66ff86bf@free-electrons.com>
Hi Thomas,
On Mon, 2016-11-14 at 15:42 +0100, Thomas Petazzoni wrote:
> Hello,
>
> On Mon, 14 Nov 2016 14:34:01 +0000, Alexey Brodkin wrote:
>
> >
> > Obviously since we live in upstream everything that could not be applied to
> > stable branches (i.e. is not a trivial fix and longer than 200 lines) get
> > merged in newer kernels.
> >
> > In particular following commit was not accepted in
> > backports:
> >
> > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=840c054fd0efb048df6fceb0c46385ec5b66dfe6
> >
> > See discussion here?http://www.spinics.net/lists/stable/msg143544.html
> >
> > The problem is in GCC v6.x newer ABI is used for ARCv2 and so only kernels v4.8+
> > will work. I.e. existing 4.7 will fail to run user-space apps built with GCC 6.x.
> >
> > Indeed we may add mentioned off-the-tree patch in BR for 4.7 but I'd rather bump
> > kernel version here with which we get more fixes across the tree for our users.
>
> Since gcc 6.x is now used for ARC if I'm correct, this means that
> upgrading the defconfig to Linux 4.8 is mandatory to have them working.
> So it's actually a bug fix, which means the update can be applied to
> master.
True.
> Why hasn't this been explained in the commit log? The commit log is
> essential in deciding to apply in master or in next. Since the commit
> log was just "Let's bump to a newer kernel", I applied to the next
> branch. If the commit log had been "Since gcc 6.x is now the default on
> ARC, and gcc 6.x implements a newer ABI only supported by Linux 4.8
> onwards, we must bump the kernel version of the ARC defconfigs in order
> to have them work correctly".
Right, I should have asked Vlad to modify his commit log.
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.
Do you want v2 with modified log to be sent so you may apply it to master branch?
-Alexey
^ permalink raw reply
* Re: A VM with 6 volumes - hangs
From: M Ranga Swami Reddy @ 2016-11-14 14:46 UTC (permalink / raw)
To: ceph-users; +Cc: ceph-devel
In-Reply-To: <CANA9Uk7ZZzWZe7PdYaCd8r5B3bp+5grKrWcPRVH2sMNX2P5cmQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 419 bytes --]
+ceph-devel
On Fri, Nov 11, 2016 at 5:09 PM, M Ranga Swami Reddy <swamireddy-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> Hello,
> I am using the ceph volumes with a VM. Details are below:
>
> VM:
> OS: Ubuntu 14.0.4
> CPU: 12 Cores
> RAM: 40 GB
>
> Volumes:
> Size: 1 TB
> No: 6 Volumes
>
>
> With above, VM got hung without any read/write operation.
>
> Any suggestions..
>
> Thanks
> Swami
>
[-- Attachment #1.2: Type: text/html, Size: 1008 bytes --]
[-- Attachment #2: Type: text/plain, Size: 178 bytes --]
_______________________________________________
ceph-users mailing list
ceph-users-idqoXFIVOFJgJs9I8MT0rw@public.gmane.org
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
^ permalink raw reply
* Re: [PATCH 2/4] Staging: vme: Use BIT macro for bit field definitions.
From: Greg KH @ 2016-11-14 14:46 UTC (permalink / raw)
To: Dan Carpenter; +Cc: Anton Leshchenko, devel, linux-kernel
In-Reply-To: <20161110191723.GE28701@mwanda>
On Thu, Nov 10, 2016 at 10:17:23PM +0300, Dan Carpenter wrote:
> On Wed, Nov 02, 2016 at 01:27:09AM +0300, Anton Leshchenko wrote:
> > #define PIO2_CNTR_MODE0 0
> > -#define PIO2_CNTR_MODE1 (1 << 1)
> > -#define PIO2_CNTR_MODE2 (2 << 1)
> > -#define PIO2_CNTR_MODE3 (3 << 1)
> > -#define PIO2_CNTR_MODE4 (4 << 1)
> > -#define PIO2_CNTR_MODE5 (5 << 1)
> > +#define PIO2_CNTR_MODE1 BIT(1)
> > +#define PIO2_CNTR_MODE2 BIT(2)
> > +#define PIO2_CNTR_MODE3 (BIT(1) | BIT(2))
> > +#define PIO2_CNTR_MODE4 BIT(4)
>
> This should be BIT(3)
Ugh, there were other parts wrong with this now that I look closer.
I've now reverted it.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] u-boot: mkimage: Fix build of u-boot-mkimage
From: Burton, Ross @ 2016-11-14 14:45 UTC (permalink / raw)
To: Marek Vasut; +Cc: OE-core
In-Reply-To: <db0f1a76-ef02-c274-9dfd-1bb8808faebc@denx.de>
[-- Attachment #1: Type: text/plain, Size: 477 bytes --]
On 12 November 2016 at 18:31, Marek Vasut <marex@denx.de> wrote:
> > Also the u-boot series went through a number of revisions, can you
> > verify that the patches in poky-contrib:ross/mut match what you expect
> > to see?
>
> Do you have a link for me ?
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=ross/mut-broken&id=4f6dbc99950da645dc4d0e23e0065ff8245a0e74
As the cleanups didn't really make sense standalone, I squashed the lot.
Ross
[-- Attachment #2: Type: text/html, Size: 1141 bytes --]
^ permalink raw reply
* Re: [PATCH 0/5] Handle Link Training Failure during modeset
From: Cheng, Tony @ 2016-11-14 14:45 UTC (permalink / raw)
To: Daniel Vetter, Manasi Navare
Cc: Deucher, Alexander, intel-gfx@lists.freedesktop.org,
Wentland, Harry, Peres, Martin, dri-devel@lists.freedesktop.org
In-Reply-To: <20161114080406.oiwbvjifrxrvpm6z@phenom.ffwll.local>
I see. As long as amd can still just have kernel hiding unsupported mode by doing a pre-train I am okay with the proposal. Just to caution you the link training fallback we implemented on windows in old dal architecture is very painful to get right. Windows 7, 8.1 and 10 all behave differently. Not all apps handles mode change failure gracefully and worse case we get stuck in infinite mode set. This is why for future generations asic on windows we are also going to just hide unsupported mode by doing pre-train.
-----Original Message-----
From: Daniel Vetter [mailto:daniel.vetter@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Monday, November 14, 2016 3:04 AM
To: Manasi Navare <manasi.d.navare@intel.com>
Cc: Cheng, Tony <Tony.Cheng@amd.com>; intel-gfx@lists.freedesktop.org; Peres, Martin <martin.peres@intel.com>; dri-devel@lists.freedesktop.org; Deucher, Alexander <Alexander.Deucher@amd.com>; Wentland, Harry <Harry.Wentland@amd.com>
Subject: Re: [Intel-gfx] [PATCH 0/5] Handle Link Training Failure during modeset
On Sun, Nov 13, 2016 at 11:43:01PM -0800, Manasi Navare wrote:
> On Fri, Nov 11, 2016 at 07:42:16PM +0000, Cheng, Tony wrote:
> > In case of link training failure and requiring user space to set a lower mode, would full mode set address it? How do we make user mode select lower resolution?
> >
> > For example 4k@60Hz monitor, and link training at 4 lane HBR2 fails and fallback to 4 lanes HBR, 4k@60 is no longer doable. I would think preventing user mode from seeing 4K@60Hz from the start is a easier and more robust solution and requiring user mode to have logic to decide how to fallback.
> >
>
> Hi Tony,
>
> So in case of link training failure, we first call mode_valid that
> will use the lower link rate/lane count values based on the link
> training fallback to validate the modes and prune the modes that are
> higher than the available link. After this is done, then we send the uevent to userspace indicating that link status is BAD and it will redo a probe and trigger a modeset for next possible lower resolution.
Just in case it's not clear: This entire discussion here is only about the userspace-visible abi changes. And I think for the worst-case we need something like this (and Harry at least said on irc that on other os you do something similar already). It of course does not preclude at all that you do additional link-training/probe on initial hotplug. That part is entirely up to drivers (and we might get there on some platforms, but on others it's a real pain to get a link up&running unfortunately for training, since we need to steal a crtc and do a full modeset).
-Daniel
>
> Manasi
>
>
> > -----Original Message-----
> > From: Ville Syrjälä [mailto:ville.syrjala@linux.intel.com]
> > Sent: Friday, November 11, 2016 11:44 AM
> > To: Cheng, Tony <Tony.Cheng@amd.com>
> > Cc: Deucher, Alexander <Alexander.Deucher@amd.com>; 'Jani Nikula'
> > <jani.nikula@linux.intel.com>; Manasi Navare
> > <manasi.d.navare@intel.com>; dri-devel@lists.freedesktop.org;
> > intel-gfx@lists.freedesktop.org; Wentland, Harry
> > <Harry.Wentland@amd.com>; Peres, Martin <martin.peres@intel.com>
> > Subject: Re: [Intel-gfx] [PATCH 0/5] Handle Link Training Failure
> > during modeset
> >
> > On Fri, Nov 11, 2016 at 04:21:58PM +0000, Cheng, Tony wrote:
> > > For HDMI, you can yank the cable, plug back in, HDMI will light up without user mode or kernel mode doing anything.
> > >
> > > For DP this is not possible, someone will have to retrain the link when plugging back in or DP will not light up. We see that on Ubuntu if someone unplug display and plug it back into same connector, we do not get KMS so in this case. It appears there is some optimizations somewhere in user mode stack which I am not familiar with yet. dal added workaround to retrain the link to light it back up (after the test training at end of detection).
> >
> > The link should get retrained as the driver should check the link state on HPD and retrain if it's not good. At least that's what we do in i915. Of course if it's not the same display that got plugged back, the retraining might fail. The new property can help with that case as userspace would then attempt a full modeset after the failed link training.
> >
> > >
> > > >From user mode perspective I think it make sense to keep CRTC running, so vblank is still going so UMD isn't impacted. As regard to connector and encoder does it matter if kernel mode change state without user mode knowing? It seems to me those are more informational to UMD as UMD doesn't act on them.
> > >
> > > windows does not know link state and all link management is hidden behind kernel driver.
> >
> > If the user visible state doesn't change in any way, then the kernel could try to manage it all internally.
> >
> > >
> > > -----Original Message-----
> > > From: Ville Syrjälä [mailto:ville.syrjala@linux.intel.com]
> > > Sent: Friday, November 11, 2016 9:05 AM
> > > To: Cheng, Tony <Tony.Cheng@amd.com>
> > > Cc: Deucher, Alexander <Alexander.Deucher@amd.com>; 'Jani Nikula'
> > > <jani.nikula@linux.intel.com>; Manasi Navare
> > > <manasi.d.navare@intel.com>; dri-devel@lists.freedesktop.org;
> > > intel-gfx@lists.freedesktop.org; Wentland, Harry
> > > <Harry.Wentland@amd.com>; Peres, Martin <martin.peres@intel.com>
> > > Subject: Re: [Intel-gfx] [PATCH 0/5] Handle Link Training Failure
> > > during modeset
> > >
> > > On Thu, Nov 10, 2016 at 06:51:40PM +0000, Cheng, Tony wrote:
> > > > Amdgpu dal implementation will do a test link training at end of detection to verify we can achieve the capability reported in DPCD. We then report mode base on result of test training.
> > > >
> > > > AMD hardware (at least the generations supported by amdgpu) is able to link train without timing being setup (DP encoder and CRTC is decoupled). Do we have limitation from other vendors where you need timing to be there before you can link train?
> > >
> > > I can't recall the specifics for all of our supported platforms, but at least I have the recollection that it would be the case yes.
> > >
> > > The other problem wiyh this apporach is that even if you don't need the crtc, you still need the link itself. What happens if the link is still active since userspace just didn't bother to shut it down when the cable was yanked? Can you keep the crtc going but stop it from feeding the link in a way that userspace won't be able to notice? The kms design has always been pretty much that policy is in userspace, and thus the kernel shouldn't shut down crtcs unless explicitly asked to do so.
> > >
> > > >
> > > > We can also past DP1.2 link layer compliance with this approach.
> > > >
> > > > -----Original Message-----
> > > > From: Deucher, Alexander
> > > > Sent: Thursday, November 10, 2016 1:43 PM
> > > > To: 'Jani Nikula' <jani.nikula@linux.intel.com>; Manasi Navare
> > > > <manasi.d.navare@intel.com>; dri-devel@lists.freedesktop.org;
> > > > intel-gfx@lists.freedesktop.org; Wentland, Harry
> > > > <Harry.Wentland@amd.com>; Cheng, Tony <Tony.Cheng@amd.com>
> > > > Cc: Dave Airlie <airlied@gmail.com>; Peres, Martin
> > > > <martin.peres@intel.com>
> > > > Subject: RE: [Intel-gfx] [PATCH 0/5] Handle Link Training
> > > > Failure during modeset
> > > >
> > > > Adding Harry and Tony from our display team to review.
> > > >
> > > > > -----Original Message-----
> > > > > From: Jani Nikula [mailto:jani.nikula@linux.intel.com]
> > > > > Sent: Thursday, November 10, 2016 1:20 PM
> > > > > To: Manasi Navare; dri-devel@lists.freedesktop.org; intel-
> > > > > gfx@lists.freedesktop.org
> > > > > Cc: Dave Airlie; Peres, Martin; Deucher, Alexander
> > > > > Subject: Re: [Intel-gfx] [PATCH 0/5] Handle Link Training
> > > > > Failure during modeset
> > > > >
> > > > > On Thu, 10 Nov 2016, Manasi Navare <manasi.d.navare@intel.com> wrote:
> > > > > > Link training failure is handled by lowering the link rate
> > > > > > first until it reaches the minimum and keeping the lane
> > > > > > count maximum and then lowering the lane count until it
> > > > > > reaches minimim. These fallback values are saved and hotplug
> > > > > > uevent is sent to the userspace after setting the connector link status property to BAD.
> > > > > > Userspace should triiger another modeset on a uevent and if
> > > > > > link status property is BAD. This will retrain the link at fallback values.
> > > > > > This is repeated until the link is successfully trained.
> > > > > >
> > > > > > This has been validated to pass DP compliance.
> > > > >
> > > > > This cover letter and the commit messages do a good job of
> > > > > explaining what the patches do. However, you're lacking the
> > > > > crucial information of
> > > > > *why* we need userspace cooperation to handle link training
> > > > > failures on DP mode setting, and *why* a new connector
> > > > > property is a good solution for this.
> > > > >
> > > > > Here goes, including some alternative approaches we've
> > > > > considered (and even tried):
> > > > >
> > > > > At the time userspace does setcrtc, we've already promised the
> > > > > mode would work. The promise is based on the theoretical
> > > > > capabilities of the link, but it's possible we can't reach
> > > > > this in practice. The DP spec describes how the link should be
> > > > > reduced, but we can't reduce the link below the requirements of the mode. Black screen follows.
> > > > >
> > > > > One idea would be to have setcrtc return a failure. However,
> > > > > it is my understanding that it already should not fail as the
> > > > > atomic checks have passed [citation needed]. It would also
> > > > > conflict with the idea of making setcrtc asynchronous in the
> > > > > future, returning before the actual mode setting and link training.
> > > > >
> > > > > Another idea is to train the link "upfront" at hotplug time,
> > > > > before pruning the mode list, so that we can do the pruning
> > > > > based on practical not theoretical capabilities. However, the
> > > > > changes for link training are pretty drastic, all for the sake
> > > > > of error handling and DP compliance, when the most common
> > > > > happy day scenario is the current approach of link training at
> > > > > mode setting time, using the optimal parameters for the mode.
> > > > > It is also not certain all hardware could do this without the
> > > > > pipe on; not even all our hardware can do this. Some of this can be solved, but not trivially.
> > > > >
> > > > > Both of the above ideas also fail to address link degradation
> > > > > *during* operation.
> > > > >
> > > > > So the idea presented in these patches is to do this in a way
> > > > > that
> > > > > a) changes the current happy day scenario as little as
> > > > > possible, to avoid regressions, b) can be implemented the same
> > > > > way by all drm drivers, c) is still opt-in for the drivers and
> > > > > userspace, and opting out doesn't regress the user experience,
> > > > > d) doesn't prevent drivers from implementing better or
> > > > > alternate approaches, possibly without userspace involvement. And, of course, handles all the issues presented.
> > > > >
> > > > > The solution is to add a "link status" connector property. In
> > > > > the usual happy day scenario, this is always "good". If
> > > > > something fails during or after a mode set, the kernel driver
> > > > > can set the link status to "bad", prune the mode list based on
> > > > > new information as necessary, and send a hotplug uevent for
> > > > > userspace to have it re-check the valid modes through
> > > > > getconnector, and try again. If the theoretical capabilities of the link can't be reached, the mode list is trimmed based on that.
> > > > >
> > > > > If the userspace is not aware of the property, the user
> > > > > experience is the same as it currently is. If the userspace is
> > > > > aware of the property, it has a chance to improve user
> > > > > experience. If a drm driver does not modify the property (it
> > > > > stays "good"), the user experience is the same as it currently
> > > > > is. A drm driver can also choose to try to handle more of the
> > > > > failures in kernel, hardware not limiting, or it can choose to involve userspace more. Up to the drivers.
> > > > >
> > > > > The reason for adding the property is to handle link training
> > > > > failures, but it is not limited to DP or link training. For
> > > > > example, if we implement asynchronous setcrtc, we can use this
> > > > > to report any failures in that.
> > > > >
> > > > > Finally, while DP CTS compliance is advertized (which is
> > > > > great, and could be made to work similarly for all drm
> > > > > drivers), this can be used for the more important goal of
> > > > > improving user experience on link training failures, by avoiding black screens.
> > > > >
> > > > >
> > > > > BR,
> > > > > Jani.
> > > > >
> > > > >
> > > > > >
> > > > > > Manasi Navare (5):
> > > > > > drm: Add a new connector property for link status
> > > > > > drm/i915: Set link status property for DP connector
> > > > > > drm/i915: Update CRTC state if connector link status
> > > > > > property changed
> > > > > ^^^^^^^^
> > > > >
> > > > > This is really drm, not i915.
> > > > >
> > > > >
> > > > > > drm/i915: Find fallback link rate/lane count
> > > > > > drm/i915: Implement Link Rate fallback on Link training
> > > > > > failure
> > > > > >
> > > > > > drivers/gpu/drm/drm_atomic_helper.c | 7 ++
> > > > > > drivers/gpu/drm/drm_connector.c | 17 ++++
> > > > > > drivers/gpu/drm/i915/intel_ddi.c | 21 +++-
> > > > > > drivers/gpu/drm/i915/intel_dp.c | 138
> > > > > +++++++++++++++++++++++++-
> > > > > > drivers/gpu/drm/i915/intel_dp_link_training.c | 12 ++-
> > > > > > drivers/gpu/drm/i915/intel_drv.h | 12 ++-
> > > > > > include/drm/drm_connector.h | 7 +-
> > > > > > include/drm/drm_crtc.h | 5 +
> > > > > > include/uapi/drm/drm_mode.h | 4 +
> > > > > > 9 files changed, 214 insertions(+), 9 deletions(-)
> > > > >
> > > > > --
> > > > > Jani Nikula, Intel Open Source Technology Center
> > > > _______________________________________________
> > > > Intel-gfx mailing list
> > > > Intel-gfx@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > >
> > > --
> > > Ville Syrjälä
> > > Intel OTC
> >
> > --
> > Ville Syrjälä
> > Intel OTC
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH v2 1/9] arm64: dts: rockchip: add eMMC's power domain support for rk3399
From: Heiko Stuebner @ 2016-11-14 14:45 UTC (permalink / raw)
To: Caesar Wang
Cc: eddie.cai, tfiga, Ziyuan Xu, Elaine Zhang, Douglas Anderson,
David Wu, Jianqun Xu, Yakir Yang, Brian Norris, linux-kernel,
linux-rockchip, devicetree, Rob Herring, Will Deacon,
Mark Rutland, Catalin Marinas, linux-arm-kernel
In-Reply-To: <1478697721-2323-2-git-send-email-wxt@rock-chips.com>
Am Mittwoch, 9. November 2016, 21:21:53 CET schrieb Caesar Wang:
> From: Ziyuan Xu <xzy.xu@rock-chips.com>
>
> Control power domain for eMMC via genpd to reduce power consumption.
>
> Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
> Signed-off-by: Ziyuan Xu <xzy.xu@rock-chips.com>
> Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Authorship / Signed-off mismatch. From above suggest Ziyuan is the author
while first Signed-off-by indicates Elaine as author. Please clarify.
Thanks
Heiko
> ---
>
> Changes in v2:
> - Reviewed-on: https://chromium-review.googlesource.com/376558
> - Verified on ChromeOS kernel4.4
>
> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> b/arch/arm64/boot/dts/rockchip/rk3399.dtsi index cbb7f8b..b401176 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> @@ -269,6 +269,7 @@
> #clock-cells = <0>;
> phys = <&emmc_phy>;
> phy-names = "phy_arasan";
> + power-domains = <&power RK3399_PD_EMMC>;
> status = "disabled";
> };
>
> @@ -690,6 +691,11 @@
> status = "disabled";
> };
>
> + qos_emmc: qos@ffa58000 {
> + compatible = "syscon";
> + reg = <0x0 0xffa58000 0x0 0x20>;
> + };
> +
> qos_gmac: qos@ffa5c000 {
> compatible = "syscon";
> reg = <0x0 0xffa5c000 0x0 0x20>;
> @@ -823,6 +829,11 @@
> };
>
> /* These power domains are grouped by VD_LOGIC */
> + pd_emmc@RK3399_PD_EMMC {
> + reg = <RK3399_PD_EMMC>;
> + clocks = <&cru ACLK_EMMC>;
> + pm_qos = <&qos_emmc>;
> + };
> pd_gmac@RK3399_PD_GMAC {
> reg = <RK3399_PD_GMAC>;
> clocks = <&cru ACLK_GMAC>;
^ permalink raw reply
* Re: kvm: WARNING in kvm_arch_vcpu_ioctl_run
From: Paolo Bonzini @ 2016-11-14 14:45 UTC (permalink / raw)
To: Dmitry Vyukov, syzkaller
Cc: Radim Krčmář, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, x86@kernel.org, KVM list, LKML, Steve Rutherford
In-Reply-To: <CACT4Y+bBufzSAC3JvWgNxxWtMBFL6mkDDcxmxjbNoQtKNUdAaw@mail.gmail.com>
On 14/11/2016 15:09, Dmitry Vyukov wrote:
>
> I made dump_vmcs() no-op locally. You should see the warning
> regardless, but probably it is difficult to notice. Or maybe tons of
> output affect timings so that the warning does not happen.
I let it run for several minutes, and only got 50 splats out of several
thousand iterations. Reproducing is not going to help much anyway---if
we can get to the root cause, writing a reliable reproducer would be
easier anyway.
Paolo
^ permalink raw reply
* [PATCH v2 1/9] arm64: dts: rockchip: add eMMC's power domain support for rk3399
From: Heiko Stuebner @ 2016-11-14 14:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478697721-2323-2-git-send-email-wxt@rock-chips.com>
Am Mittwoch, 9. November 2016, 21:21:53 CET schrieb Caesar Wang:
> From: Ziyuan Xu <xzy.xu@rock-chips.com>
>
> Control power domain for eMMC via genpd to reduce power consumption.
>
> Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
> Signed-off-by: Ziyuan Xu <xzy.xu@rock-chips.com>
> Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Authorship / Signed-off mismatch. From above suggest Ziyuan is the author
while first Signed-off-by indicates Elaine as author. Please clarify.
Thanks
Heiko
> ---
>
> Changes in v2:
> - Reviewed-on: https://chromium-review.googlesource.com/376558
> - Verified on ChromeOS kernel4.4
>
> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> b/arch/arm64/boot/dts/rockchip/rk3399.dtsi index cbb7f8b..b401176 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> @@ -269,6 +269,7 @@
> #clock-cells = <0>;
> phys = <&emmc_phy>;
> phy-names = "phy_arasan";
> + power-domains = <&power RK3399_PD_EMMC>;
> status = "disabled";
> };
>
> @@ -690,6 +691,11 @@
> status = "disabled";
> };
>
> + qos_emmc: qos at ffa58000 {
> + compatible = "syscon";
> + reg = <0x0 0xffa58000 0x0 0x20>;
> + };
> +
> qos_gmac: qos at ffa5c000 {
> compatible = "syscon";
> reg = <0x0 0xffa5c000 0x0 0x20>;
> @@ -823,6 +829,11 @@
> };
>
> /* These power domains are grouped by VD_LOGIC */
> + pd_emmc at RK3399_PD_EMMC {
> + reg = <RK3399_PD_EMMC>;
> + clocks = <&cru ACLK_EMMC>;
> + pm_qos = <&qos_emmc>;
> + };
> pd_gmac at RK3399_PD_GMAC {
> reg = <RK3399_PD_GMAC>;
> clocks = <&cru ACLK_GMAC>;
^ permalink raw reply
* Re: [PATCH v2 1/9] arm64: dts: rockchip: add eMMC's power domain support for rk3399
From: Heiko Stuebner @ 2016-11-14 14:45 UTC (permalink / raw)
To: Caesar Wang
Cc: eddie.cai-TNX95d0MmH7DzftRWevZcw, tfiga-F7+t8E8rja9g9hUCZPvPmw,
Ziyuan Xu, Elaine Zhang, Douglas Anderson, David Wu, Jianqun Xu,
Yakir Yang, Brian Norris, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Will Deacon,
Mark Rutland, Catalin Marinas,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1478697721-2323-2-git-send-email-wxt-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Am Mittwoch, 9. November 2016, 21:21:53 CET schrieb Caesar Wang:
> From: Ziyuan Xu <xzy.xu-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
>
> Control power domain for eMMC via genpd to reduce power consumption.
>
> Signed-off-by: Elaine Zhang <zhangqing-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> Signed-off-by: Ziyuan Xu <xzy.xu-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> Signed-off-by: Caesar Wang <wxt-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Authorship / Signed-off mismatch. From above suggest Ziyuan is the author
while first Signed-off-by indicates Elaine as author. Please clarify.
Thanks
Heiko
> ---
>
> Changes in v2:
> - Reviewed-on: https://chromium-review.googlesource.com/376558
> - Verified on ChromeOS kernel4.4
>
> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> b/arch/arm64/boot/dts/rockchip/rk3399.dtsi index cbb7f8b..b401176 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> @@ -269,6 +269,7 @@
> #clock-cells = <0>;
> phys = <&emmc_phy>;
> phy-names = "phy_arasan";
> + power-domains = <&power RK3399_PD_EMMC>;
> status = "disabled";
> };
>
> @@ -690,6 +691,11 @@
> status = "disabled";
> };
>
> + qos_emmc: qos@ffa58000 {
> + compatible = "syscon";
> + reg = <0x0 0xffa58000 0x0 0x20>;
> + };
> +
> qos_gmac: qos@ffa5c000 {
> compatible = "syscon";
> reg = <0x0 0xffa5c000 0x0 0x20>;
> @@ -823,6 +829,11 @@
> };
>
> /* These power domains are grouped by VD_LOGIC */
> + pd_emmc@RK3399_PD_EMMC {
> + reg = <RK3399_PD_EMMC>;
> + clocks = <&cru ACLK_EMMC>;
> + pm_qos = <&qos_emmc>;
> + };
> pd_gmac@RK3399_PD_GMAC {
> reg = <RK3399_PD_GMAC>;
> clocks = <&cru ACLK_GMAC>;
--
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
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.