* [RFC v2 8/8] iommu/arm-smmu: implement add_reserved_regions callback
From: Joerg Roedel @ 2016-11-14 15:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <634ac375-3507-6926-164f-e67f7c798c98@redhat.com>
Hi Eric,
On Fri, Nov 11, 2016 at 05:45:19PM +0100, Auger Eric wrote:
> On 11/11/2016 17:22, Joerg Roedel wrote:
> > So I think we need a way to tell userspace about the reserved regions
> > (per iommu-group) so that userspace knows where it can not map anything,
> Current plan is to expose that info through an iommu-group sysfs
> attribute, as you and Robin advised.
Great.
> > and VFIO can enforce that. But the right struct here is not an
> > iova-allocator rb-tree, a ordered linked list should be sufficient.
> I plan a linked list to store the reserved regions (P2P regions, MSI
> region, ...). get_dma_regions is called with a list local to a function
> for that. Might be needed to move that list head in the iommu_group to
> avoid calling the get_dm_regions again in the attribute show function?
You can re-use the get_dm_regions() call-back available in the iommu-ops
already. Just rename it and add a flag to it which tells the iommu-core
whether that region needs to be mapped or not.
> But to allocate the IOVAs within the MSI reserved region, I understand
> you don't want us to use the iova.c allocator, is that correct? We need
> an allocator though, even a very basic one based on bitmap or whatever.
> There potentially have several different physical MSI frame pages to map.
I don't get this, what do you need and address-allocator for?
Joerg
^ permalink raw reply
* Re: [RFC v2 8/8] iommu/arm-smmu: implement add_reserved_regions callback
From: Joerg Roedel @ 2016-11-14 15:31 UTC (permalink / raw)
To: Auger Eric
Cc: drjones, jason, kvm, marc.zyngier, punit.agrawal, will.deacon,
linux-kernel, iommu, diana.craciun, alex.williamson,
pranav.sawargaonkar, linux-arm-kernel, tglx, robin.murphy,
christoffer.dall, eric.auger.pro
In-Reply-To: <634ac375-3507-6926-164f-e67f7c798c98@redhat.com>
Hi Eric,
On Fri, Nov 11, 2016 at 05:45:19PM +0100, Auger Eric wrote:
> On 11/11/2016 17:22, Joerg Roedel wrote:
> > So I think we need a way to tell userspace about the reserved regions
> > (per iommu-group) so that userspace knows where it can not map anything,
> Current plan is to expose that info through an iommu-group sysfs
> attribute, as you and Robin advised.
Great.
> > and VFIO can enforce that. But the right struct here is not an
> > iova-allocator rb-tree, a ordered linked list should be sufficient.
> I plan a linked list to store the reserved regions (P2P regions, MSI
> region, ...). get_dma_regions is called with a list local to a function
> for that. Might be needed to move that list head in the iommu_group to
> avoid calling the get_dm_regions again in the attribute show function?
You can re-use the get_dm_regions() call-back available in the iommu-ops
already. Just rename it and add a flag to it which tells the iommu-core
whether that region needs to be mapped or not.
> But to allocate the IOVAs within the MSI reserved region, I understand
> you don't want us to use the iova.c allocator, is that correct? We need
> an allocator though, even a very basic one based on bitmap or whatever.
> There potentially have several different physical MSI frame pages to map.
I don't get this, what do you need and address-allocator for?
Joerg
^ permalink raw reply
* Re: [PATCH 1/2] Add Documentation for Media Device, Video Device, and Synopsys DW MIPI CSI-2 Host
From: Ramiro Oliveira @ 2016-11-14 15:31 UTC (permalink / raw)
To: Laurent Pinchart, 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: <9132828.vOiOHSy7z0@avalon>
Hi Laurent,
Thanks for the feedback.
On 11/14/2016 2:49 PM, Laurent Pinchart wrote:
> 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 ?
>
I can add a more detailed description. Also, here is a link to the
documentation, but I'm afraid you might have to register yourself to access it.
CSI-2 Host
https://www.synopsys.com/dw/doc.php/ds/c/dwc_csi2_controller.pdf
CSI-2 Host IPK
https://www.synopsys.com/dw/doc.php/ds/o/ip_prototyping_kit_mipi_csi2_host_arc.pdf
>> +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 ?
>
The max number is fixed at synthesis time, but you can configure it for lower
values. I added this option here because, although configurable, it's usually a
fixed value.
>> +- output-type : Core output to be used (IPI-> 0 or IDI->1 or BOTH->2)
>
> What are IPI and IDI ?
>
IPI is Image Pixel Interface and IDI Image Data Interface, these are the two
types of data output support by our CSI-2 Host controller
>> +- 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 ?
>
Our controller needs a PHY, in this case a MIPI DPHY, to interact with a CSI-2
receiver (usually a sensor).
>> +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.
>
Sure, I'll add more details to the descripton
>> +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.
>
I'll add an example of how we're using it.
>> 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.
>
I'm afraid I wasn't completely clear. This setup is fully functional. Actually
this sentence made sense in the past, but no longer does now.
>> +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.
>
You're right, I'll add a more detailed description.
>> +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.
>
Thanks once again,
Ramiro Oliveira
^ permalink raw reply
* [PATCH RESEND] spi: atmel: Fix scheduling while atomic
From: Alexandre Belloni @ 2016-11-14 15:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479136400-10285-1-git-send-email-ben.whitten@lairdtech.com>
On 14/11/2016 at 15:13:20 +0000, Ben Whitten wrote :
> A call to clk_get_rate appears to be called in the context of an interrupt,
> cache the bus clock for the frequency calculations in transmission.
>
> This fixes a 'BUG: scheduling while atomic' and
> 'WARNING: CPU: 0 PID: 777 at kernel/sched/core.c:2960 atmel_spi_unlock'
>
> Signed-off-by: Ben Whitten <ben.whitten@lairdtech.com>
> Signed-off-by: Steve deRosier <steve.derosier@lairdtech.com>
Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> ---
>
> Resending due to missing off the subsystem maintainer in initial submission,
> pointed out by Alexandre Belloni, thanks.
>
> ---
> drivers/spi/spi-atmel.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
> index 8feac59..c281d1a 100644
> --- a/drivers/spi/spi-atmel.c
> +++ b/drivers/spi/spi-atmel.c
> @@ -295,6 +295,7 @@ struct atmel_spi {
> int irq;
> struct clk *clk;
> struct platform_device *pdev;
> + unsigned long spi_clk;
>
> struct spi_transfer *current_transfer;
> int current_remaining_bytes;
> @@ -864,7 +865,7 @@ static int atmel_spi_set_xfer_speed(struct atmel_spi *as,
> unsigned long bus_hz;
>
> /* v1 chips start out at half the peripheral bus speed. */
> - bus_hz = clk_get_rate(as->clk);
> + bus_hz = as->spi_clk;
> if (!atmel_spi_is_v2(as))
> bus_hz /= 2;
>
> @@ -1606,6 +1607,9 @@ static int atmel_spi_probe(struct platform_device *pdev)
> ret = clk_prepare_enable(clk);
> if (ret)
> goto out_free_irq;
> +
> + as->spi_clk = clk_get_rate(clk);
> +
> spi_writel(as, CR, SPI_BIT(SWRST));
> spi_writel(as, CR, SPI_BIT(SWRST)); /* AT91SAM9263 Rev B workaround */
> if (as->caps.has_wdrbt) {
> --
> 2.7.4
>
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 1/2] Add Documentation for Media Device, Video Device, and Synopsys DW MIPI CSI-2 Host
From: Ramiro Oliveira @ 2016-11-14 15:31 UTC (permalink / raw)
To: Laurent Pinchart, 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: <9132828.vOiOHSy7z0@avalon>
Hi Laurent,
Thanks for the feedback.
On 11/14/2016 2:49 PM, Laurent Pinchart wrote:
> 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 ?
>
I can add a more detailed description. Also, here is a link to the
documentation, but I'm afraid you might have to register yourself to access it.
CSI-2 Host
https://www.synopsys.com/dw/doc.php/ds/c/dwc_csi2_controller.pdf
CSI-2 Host IPK
https://www.synopsys.com/dw/doc.php/ds/o/ip_prototyping_kit_mipi_csi2_host_arc.pdf
>> +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 ?
>
The max number is fixed at synthesis time, but you can configure it for lower
values. I added this option here because, although configurable, it's usually a
fixed value.
>> +- output-type : Core output to be used (IPI-> 0 or IDI->1 or BOTH->2)
>
> What are IPI and IDI ?
>
IPI is Image Pixel Interface and IDI Image Data Interface, these are the two
types of data output support by our CSI-2 Host controller
>> +- 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 ?
>
Our controller needs a PHY, in this case a MIPI DPHY, to interact with a CSI-2
receiver (usually a sensor).
>> +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.
>
Sure, I'll add more details to the descripton
>> +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.
>
I'll add an example of how we're using it.
>> 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.
>
I'm afraid I wasn't completely clear. This setup is fully functional. Actually
this sentence made sense in the past, but no longer does now.
>> +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.
>
You're right, I'll add a more detailed description.
>> +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.
>
Thanks once again,
Ramiro Oliveira
^ permalink raw reply
* Re: [RFC/PATCH 0/2] git diff <(command1) <(command2)
From: Michael J Gruber @ 2016-11-14 15:31 UTC (permalink / raw)
To: Johannes Schindelin, Jacob Keller
Cc: Junio C Hamano, Dennis Kaarsemaker, Git mailing list
In-Reply-To: <alpine.DEB.2.20.1611121106110.3746@virtualbox>
Johannes Schindelin venit, vidit, dixit 12.11.2016 11:08:
> Hi,
>
> On Fri, 11 Nov 2016, Jacob Keller wrote:
>
>> On Fri, Nov 11, 2016 at 1:27 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Dennis Kaarsemaker <dennis@kaarsemaker.net> writes:
>>>
>>>> No tests or documentation updates yet, and I'm not sure whether
>>>> --follow-symlinks in other modes than --no-index should be supported, ignored
>>>> (as it is now) or cause an error, but I'm leaning towards the third option.
>>>
>>> My knee-jerk reaction is:
>>>
>>> * The --no-index mode should default to your --follow-symlinks
>>> behaviour, without any option to turn it on or off.
>>>
>>
>> I agree. We shouldn't have to specify this for no-index.
>
> Ummm. *My* idea of --no-index was for it to behave as similar to the
> --index version as possible. For example when comparing directories
> containing symlinks. You seem intent on breaking this scenario.
*My* idea of --no-index was for it to behave as similar to the
--index-version as possible, regarding formatting etc., and to be a good
substitute for ordinary diff. The proposed patch achieves exactly that -
why should a *file* argument (which is not a pathspec in --no-index
mode) not be treated in the same way in which every other command treats
a file argument? The patch un-breaks the most natural expectation.
Michael
^ permalink raw reply
* [Bug 97403] AMDGPU/Iceland Strange warnings on drm-next-4.9-wip
From: bugzilla-daemon @ 2016-11-14 15:31 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-97403-502@http.bugs.freedesktop.org/>
[-- Attachment #1.1: Type: text/plain, Size: 214 bytes --]
https://bugs.freedesktop.org/show_bug.cgi?id=97403
--- Comment #4 from Armin K <krejzi@email.com> ---
It says "Adapter not found."
--
You are receiving this mail because:
You are the assignee for the bug.
[-- Attachment #1.2: Type: text/html, Size: 1001 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 3.2 009/152] ext4: check for extents that wrap around
From: Vegard Nossum @ 2016-11-14 15:29 UTC (permalink / raw)
To: Ben Hutchings, linux-kernel, stable, Greg Kroah-Hartman
Cc: akpm, Phil Turnbull, Eryu Guan, Theodore Ts'o
In-Reply-To: <lsq.1479082447.702293527@decadent.org.uk>
On 11/14/2016 01:14 AM, Ben Hutchings wrote:
> 3.2.84-rc1 review patch. If anyone has any objections, please let me know.
Just a general comment on stable review workflow, really:
It might be more useful to send the diff-of-diffs with the upstream
commit so I can easily see if you had any conflicts when cherry-picking
this and how they were resolved.
That's generally much more interesting than just the plain patch, where
I can't really tell if there were any changes at all (or conversely,
much more boring in case there were no changes, and thus easier to
review).
If you could push this commit to git before sending the review, you
could also include a command that I can use to quickly do the
diff-of-diffs myself without having to download and apply the patch (or
look for it), e.g. something like (using the 3.12 stable commit vs
upstream):
"""
diff -yw \
<(echo upstream; git log -p -W f70749c^..f70749c) \
<(echo 3.2; git log -p -W 33234c6^..33234c6)
"""
At least that would make it a lot easier for me (and I suspect other
casual stable contributors) to glance at a stable review email and tell
if the backport is correct or not. It should be pretty easy to script on
your end(s) for the benefit of everybody.
Just my 2 cents. Thanks,
Vegard
> ------------------
>
> From: Vegard Nossum <vegard.nossum@oracle.com>
>
> commit f70749ca42943faa4d4dcce46dfdcaadb1d0c4b6 upstream.
>
> An extent with lblock = 4294967295 and len = 1 will pass the
> ext4_valid_extent() test:
>
> ext4_lblk_t last = lblock + len - 1;
>
> if (len == 0 || lblock > last)
> return 0;
>
> since last = 4294967295 + 1 - 1 = 4294967295. This would later trigger
> the BUG_ON(es->es_lblk + es->es_len < es->es_lblk) in ext4_es_end().
>
> We can simplify it by removing the - 1 altogether and changing the test
> to use lblock + len <= lblock, since now if len = 0, then lblock + 0 ==
> lblock and it fails, and if len > 0 then lblock + len > lblock in order
> to pass (i.e. it doesn't overflow).
>
> Fixes: 5946d0893 ("ext4: check for overlapping extents in ext4_valid_extent_entries()")
> Fixes: 2f974865f ("ext4: check for zero length extent explicitly")
> Cc: Eryu Guan <guaneryu@gmail.com>
> Signed-off-by: Phil Turnbull <phil.turnbull@oracle.com>
> Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
> Signed-off-by: Theodore Ts'o <tytso@mit.edu>
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
> ---
> fs/ext4/extents.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> --- a/fs/ext4/extents.c
> +++ b/fs/ext4/extents.c
> @@ -319,9 +319,13 @@ static int ext4_valid_extent(struct inod
> ext4_fsblk_t block = ext4_ext_pblock(ext);
> int len = ext4_ext_get_actual_len(ext);
> ext4_lblk_t lblock = le32_to_cpu(ext->ee_block);
> - ext4_lblk_t last = lblock + len - 1;
>
> - if (len == 0 || lblock > last)
> + /*
> + * We allow neither:
> + * - zero length
> + * - overflow/wrap-around
> + */
> + if (lblock + len <= lblock)
> return 0;
> return ext4_data_block_valid(EXT4_SB(inode->i_sb), block, len);
> }
>
^ permalink raw reply
* Re: [Qemu-devel] [RFC 0/3] aio: experimental virtio-blk polling mode
From: Paolo Bonzini @ 2016-11-14 15:29 UTC (permalink / raw)
To: Stefan Hajnoczi, Karl Rister
Cc: Stefan Hajnoczi, qemu-devel, Andrew Theurer, Fam Zheng
In-Reply-To: <20161114152642.GE26198@stefanha-x1.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1079 bytes --]
On 14/11/2016 16:26, Stefan Hajnoczi wrote:
> On Fri, Nov 11, 2016 at 01:59:25PM -0600, Karl Rister wrote:
>> QEMU_AIO_POLL_MAX_NS IOPs
>> unset 31,383
>> 1 46,860
>> 2 46,440
>> 4 35,246
>> 8 34,973
>> 16 46,794
>> 32 46,729
>> 64 35,520
>> 128 45,902
>
> The environment variable is in nanoseconds. The range of values you
> tried are very small (all <1 usec). It would be interesting to try
> larger values in the ballpark of the latencies you have traced. For
> example 2000, 4000, 8000, 16000, and 32000 ns.
>
> Very interesting that QEMU_AIO_POLL_MAX_NS=1 performs so well without
> much CPU overhead.
That basically means "avoid a syscall if you already know there's
something to do", so in retrospect it's not that surprising. Still
interesting though, and it means that the feature is useful even if you
don't have CPU to waste.
Paolo
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* Re: Possible to prevent dom0 accessing guest memory?
From: Andy Smith @ 2016-11-14 15:29 UTC (permalink / raw)
To: xen-devel
In-Reply-To: <ff23faef-fdb1-0cb3-e0db-cfec532768d4@citrix.com>
Hi Andrew,
On Mon, Nov 14, 2016 at 03:06:12PM +0000, Andrew Cooper wrote:
> You have misunderstood a step.
>
> Dom0 can map all of guest memory. This is how `xl dump-core` is
> implemented, as well as how Qemu emulates devices for the guest.
Ah, okay, thanks. That is what I feared.
Due to details of the legal jurisdiction in which I operate, it
would actually be useful to me to disable xl dump-core and be able
to truthfully state that I do not know how to obtain a dump of a
guest's memory. As it stands I do know that xl dump-core exists and
I can be compelled to run it. I do not personally know how to write
a program to do what xl dump-core does and would have no interest in
finding out.
But I appreciate that the more general concern would be an attacker
who gains root access, and they could just run such a program, so I
guess Xen developers would see little point in offering a way to
disable dump-core.
Cheers,
Andy
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* RE: 答复: 答复: [PATCH] drm/amdgpu:impl vgt_flush for VI
From: Deucher, Alexander @ 2016-11-14 15:28 UTC (permalink / raw)
To: Liu, Monk, Christian König,
amd-gfx-CC+yJ3UmIYqDUpFQwHEjaQ@public.gmane.org
In-Reply-To: <DM5PR12MB13554FD685656621B92C043184BC0-2J9CzHegvk+AJwmwFrlwrgdYzm3356FpvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
> -----Original Message-----
> From: amd-gfx [mailto:amd-gfx-bounces@lists.freedesktop.org] On Behalf
> Of Liu, Monk
> Sent: Monday, November 14, 2016 6:40 AM
> To: Christian König; amd-gfx@freedesktop.org
> Subject: 答复: 答复: 答复: [PATCH] drm/amdgpu:impl vgt_flush for VI
>
> I have no strong opinion, I checked windows kmd and they separate vgt-
> flush and cntx-ctrl as well,
> Fine with your suggestion
Please also make sure you update the packet counts in the ring structure.
Alex
>
> BR Monk
>
> -----邮件原件-----
> 发件人: Christian König [mailto:deathsimple@vodafone.de]
> 发送时间: Monday, November 14, 2016 7:33 PM
> 收件人: Liu, Monk; amd-gfx@freedesktop.org
> 主题: Re: 答复: 答复: [PATCH] drm/amdgpu:impl vgt_flush for VI
>
> The callbacks are use case driven, so it doesn't matter what packets they use.
> I would really prefer not to add to many of them.
>
> Maybe rename the emit_cntxcntl callback to just emit_context_preamble or
> something like this to make it more clear what that is good for.
>
> Regards,
> Christian.
>
> Am 14.11.2016 um 11:01 schrieb Liu, Monk:
> > Although the effect is equal, but cntxcntl uses CONTEXT_CONTROL only,
> > while vgt-flush uses EVENT_WRITE on vgt_flush and vs_partial_flush only,
> And vgt flush only operate on tessellation category registers, I'd prefer it not
> mixed with CONTEXT_CONTROL package ...
> > I think Put them together seems not grace ...
> >
> > BR Monk
> >
> > -----邮件原件-----
> > 发件人: Christian König [mailto:deathsimple@vodafone.de]
> > 发送时间: Monday, November 14, 2016 5:46 PM
> > 收件人: Liu, Monk; amd-gfx@freedesktop.org
> > 主题: Re: 答复: [PATCH] drm/amdgpu:impl vgt_flush for VI
> >
> > Am 14.11.2016 um 04:17 schrieb Liu, Monk:
> >> Anyone review this patch ?
> > Looks good in general, but is there any reason not to put it into the existing
> emit_cntxcntl callback?
> >
> > Regards,
> > Christian.
> >
> >> This patch could fix tessellation bug when shadowing enabled, we
> >> should always insert vgt_flush when there is a context switch
> >>
> >> BR Monk
> >>
> >> -----邮件原件-----
> >> 发件人: Monk Liu [mailto:Monk.Liu@amd.com]
> >> 发送时间: Friday, November 11, 2016 6:32 PM
> >> 收件人: amd-gfx@freedesktop.org
> >> 抄送: Liu, Monk
> >> 主题: [PATCH] drm/amdgpu:impl vgt_flush for VI
> >>
> >> when hardware shadowing enabled, tesselation will trigger vm fault, the
> root cause is because VGT_FLUSH not introduced in kmd. this could fix
> tesselation crash issue.
> >>
> >> Change-Id: I77d87d93ce6580e559e734fb41d97ee8c59d245b
> >> Signed-off-by: Monk Liu <Monk.Liu@amd.com>
> >> ---
> >> drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 +
> >> drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 5 ++++-
> >> drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 1 +
> >> drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 13 +++++++++++++
> >> 4 files changed, 19 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> >> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> >> index 15015bc..f46e96b 100644
> >> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> >> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> >> @@ -1630,6 +1630,7 @@ amdgpu_get_sdma_instance(struct
> amdgpu_ring
> >> *ring) #define amdgpu_ring_emit_fence(r, addr, seq, flags)
> >> (r)->funcs->emit_fence((r), (addr), (seq), (flags)) #define
> >> amdgpu_ring_emit_gds_switch(r, v, db, ds, wb, ws, ab, as)
> >> (r)->funcs->emit_gds_switch((r), (v), (db), (ds), (wb), (ws), (ab),
> >> (as)) #define amdgpu_ring_emit_hdp_flush(r)
> >> (r)->funcs->emit_hdp_flush((r))
> >> +#define amdgpu_ring_emit_vgt_flush(r)
> >> +(r)->funcs->emit_vgt_flush((r))
> >> #define amdgpu_ring_emit_hdp_invalidate(r) (r)->funcs-
> >emit_hdp_invalidate((r))
> >> #define amdgpu_ring_emit_switch_buffer(r) (r)->funcs-
> >emit_switch_buffer((r))
> >> #define amdgpu_ring_emit_cntxcntl(r, d)
> >> (r)->funcs->emit_cntxcntl((r), (d)) diff --git
> >> a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
> >> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
> >> index acf48de..c039890 100644
> >> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
> >> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
> >> @@ -175,11 +175,14 @@ int amdgpu_ib_schedule(struct amdgpu_ring
> *ring, unsigned num_ibs,
> >> if (ring->funcs->emit_hdp_flush)
> >> amdgpu_ring_emit_hdp_flush(ring);
> >>
> >> + need_ctx_switch = ring->current_ctx != fence_ctx;
> >> + if (ring->funcs->emit_vgt_flush && need_ctx_switch)
> >> + amdgpu_ring_emit_vgt_flush(ring);
> >> +
> >> /* always set cond_exec_polling to CONTINUE */
> >> *ring->cond_exe_cpu_addr = 1;
> >>
> >> skip_preamble = ring->current_ctx == fence_ctx;
> >> - need_ctx_switch = ring->current_ctx != fence_ctx;
> >> if (job && ring->funcs->emit_cntxcntl) {
> >> if (need_ctx_switch)
> >> status |= AMDGPU_HAVE_CTX_SWITCH; diff --git
> >> a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
> >> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
> >> index 92bc89b..c3a7329 100644
> >> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
> >> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
> >> @@ -116,6 +116,7 @@ struct amdgpu_ring_funcs {
> >> void (*emit_vm_flush)(struct amdgpu_ring *ring, unsigned vm_id,
> >> uint64_t pd_addr);
> >> void (*emit_hdp_flush)(struct amdgpu_ring *ring);
> >> + void (*emit_vgt_flush)(struct amdgpu_ring *ring);
> >> void (*emit_hdp_invalidate)(struct amdgpu_ring *ring);
> >> void (*emit_gds_switch)(struct amdgpu_ring *ring, uint32_t vmid,
> >> uint32_t gds_base, uint32_t gds_size, diff --
> git
> >> a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> >> b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> >> index 9017803..1d407d76 100644
> >> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> >> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> >> @@ -6187,6 +6187,18 @@ static void
> gfx_v8_0_ring_emit_hdp_flush(struct amdgpu_ring *ring)
> >> amdgpu_ring_write(ring, 0x20); /* poll interval */ }
> >>
> >> +static void gfx_v8_0_ring_emit_vgt_flush(struct amdgpu_ring *ring) {
> >> + amdgpu_ring_write(ring, PACKET3(PACKET3_EVENT_WRITE, 0));
> >> + amdgpu_ring_write(ring, EVENT_TYPE(VS_PARTIAL_FLUSH) |
> >> + EVENT_INDEX(4));
> >> +
> >> + amdgpu_ring_write(ring, PACKET3(PACKET3_EVENT_WRITE, 0));
> >> + amdgpu_ring_write(ring, EVENT_TYPE(VGT_FLUSH) |
> >> + EVENT_INDEX(0));
> >> +}
> >> +
> >> +
> >> static void gfx_v8_0_ring_emit_hdp_invalidate(struct amdgpu_ring
> *ring) {
> >> amdgpu_ring_write(ring, PACKET3(PACKET3_WRITE_DATA, 3)); @@
> -6590,6 +6602,7 @@ static const struct amdgpu_ring_funcs
> gfx_v8_0_ring_funcs_gfx = {
> >> .pad_ib = amdgpu_ring_generic_pad_ib,
> >> .emit_switch_buffer = gfx_v8_ring_emit_sb,
> >> .emit_cntxcntl = gfx_v8_ring_emit_cntxcntl,
> >> + .emit_vgt_flush = gfx_v8_0_ring_emit_vgt_flush,
> >> };
> >>
> >> static const struct amdgpu_ring_funcs gfx_v8_0_ring_funcs_compute
> >> = {
> >> --
> >> 1.9.1
> >>
> >> _______________________________________________
> >> amd-gfx mailing list
> >> amd-gfx@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
> >
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply
* Re: [PATCH] net/phy: add trace events for mdio accesses
From: Steven Rostedt @ 2016-11-14 15:22 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: Florian Fainelli, Ingo Molnar, netdev
In-Reply-To: <20161114110335.27862-1-uwe@kleine-koenig.org>
On Mon, 14 Nov 2016 12:03:35 +0100
Uwe Kleine-König <uwe@kleine-koenig.org> wrote:
> Make it possible to generate trace events for mdio read and write accesses.
>
> Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
> ---
> drivers/net/phy/mdio_bus.c | 15 +++++++++++++++
> include/trace/events/mdio.h | 40 ++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 55 insertions(+)
> create mode 100644 include/trace/events/mdio.h
>
> diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
> index 09deef4bed09..0f3f207419f6 100644
> --- a/drivers/net/phy/mdio_bus.c
> +++ b/drivers/net/phy/mdio_bus.c
> @@ -38,6 +38,9 @@
>
> #include <asm/irq.h>
>
> +#define CREATE_TRACE_POINTS
> +#include <trace/events/mdio.h>
> +
> int mdiobus_register_device(struct mdio_device *mdiodev)
> {
> if (mdiodev->bus->mdio_map[mdiodev->addr])
> @@ -461,6 +464,9 @@ int mdiobus_read_nested(struct mii_bus *bus, int addr, u32 regnum)
> retval = bus->read(bus, addr, regnum);
> mutex_unlock(&bus->mdio_lock);
>
> + if (retval >= 0)
> + trace_mdio_access(bus, 1, addr, regnum, retval);
These cause branches to be taken when tracing is disabled, breaking the
zero overhead for disabled tracing guideline. As retval is passed to
the tracepoint, please look at TRACE_EVENT_CONDITION() and use that.
It will move the if statement into the enabling of the trace event and
keep the overhead to a minimum when the tracepoint is disabled.
Do the same for the below as well.
-- Steve
> +
> return retval;
> }
> EXPORT_SYMBOL(mdiobus_read_nested);
> @@ -485,6 +491,9 @@ int mdiobus_read(struct mii_bus *bus, int addr, u32 regnum)
> retval = bus->read(bus, addr, regnum);
> mutex_unlock(&bus->mdio_lock);
>
> + if (retval >= 0)
> + trace_mdio_access(bus, 1, addr, regnum, retval);
> +
> return retval;
> }
> EXPORT_SYMBOL(mdiobus_read);
> @@ -513,6 +522,9 @@ int mdiobus_write_nested(struct mii_bus *bus, int addr, u32 regnum, u16 val)
> err = bus->write(bus, addr, regnum, val);
> mutex_unlock(&bus->mdio_lock);
>
> + if (!err)
> + trace_mdio_access(bus, 0, addr, regnum, val);
> +
> return err;
> }
> EXPORT_SYMBOL(mdiobus_write_nested);
> @@ -538,6 +550,9 @@ int mdiobus_write(struct mii_bus *bus, int addr, u32 regnum, u16 val)
> err = bus->write(bus, addr, regnum, val);
> mutex_unlock(&bus->mdio_lock);
>
> + if (!err)
> + trace_mdio_access(bus, 0, addr, regnum, val);
> +
> return err;
> }
> EXPORT_SYMBOL(mdiobus_write);
> diff --git a/include/trace/events/mdio.h b/include/trace/events/mdio.h
> new file mode 100644
> index 000000000000..dcb2d456a346
> --- /dev/null
> +++ b/include/trace/events/mdio.h
> @@ -0,0 +1,40 @@
> +#undef TRACE_SYSTEM
> +#define TRACE_SYSTEM mdio
> +
> +#if !defined(_TRACE_MDIO_H) || defined(TRACE_HEADER_MULTI_READ)
> +#define _TRACE_MDIO_H
> +
> +#include <linux/tracepoint.h>
> +
> +TRACE_EVENT(mdio_access,
> +
> + TP_PROTO(struct mii_bus *bus, int read,
> + unsigned addr, unsigned regnum, u16 val),
> +
> + TP_ARGS(bus, read, addr, regnum, val),
> +
> + TP_STRUCT__entry(
> + __array(char, busid, MII_BUS_ID_SIZE)
> + __field(int, read)
> + __field(unsigned, addr)
> + __field(unsigned, regnum)
> + __field(u16, val)
> + ),
> +
> + TP_fast_assign(
> + strncpy(__entry->busid, bus->id, MII_BUS_ID_SIZE);
> + __entry->read = read;
> + __entry->addr = addr;
> + __entry->regnum = regnum;
> + __entry->val = val;
> + ),
> +
> + TP_printk("%s %-5s phy:0x%02x reg:0x%02x val:0x%04hx",
> + __entry->busid, __entry->read ? "read" : "write",
> + __entry->addr, __entry->regnum, __entry->val)
> +);
> +
> +#endif /* if !defined(_TRACE_MDIO_H) || defined(TRACE_HEADER_MULTI_READ) */
> +
> +/* This part must be outside protection */
> +#include <trace/define_trace.h>
^ permalink raw reply
* [Bug 141741] drm:radeon_get_bios [radeon]] *ERROR* Unable to locate a BIOS ROM
From: bugzilla-daemon @ 2016-11-14 15:28 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-141741-2300@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=141741
--- Comment #21 from Tero Roponen <tero.roponen@gmail.com> ---
(In reply to Lukas P from comment #19)
> I did a bisect and it reported the following commit as the first bad one:
> 30b5b8808c12bcd947dd474980482561b69c1bcb
>
> diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
> index a1f37db..209292e 100644
> --- a/drivers/pci/Kconfig
> +++ b/drivers/pci/Kconfig
> @@ -128,4 +128,5 @@ config PCI_HYPERV
> The PCI device frontend driver allows the kernel to import
> arbitrary
> PCI devices from a PCI backend to support PCI driver domains.
>
> +source "drivers/pci/hotplug/Kconfig"
> source "drivers/pci/host/Kconfig"
>
> If I remove the changed line in the source of v4.6 everything works normally.
I'm not an expert, but removing the inclusion of drivers/pci/hotplug/Kconfig
equals to disabling all the HOTPLUG_PCI_* options in the config ("Support for
PCI Hotplug" in menuconfig). You could try disabling those one by one to see
which one causes the problem.
--
You are receiving this mail because:
You are on the CC list for the bug.
You are watching the assignee of the bug.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v2 2/9] arm64: dts: rockchip: add pd_sd power node for rk3399
From: Heiko Stuebner @ 2016-11-14 15:27 UTC (permalink / raw)
To: Caesar Wang
Cc: eddie.cai, tfiga, zhangqing, 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-3-git-send-email-wxt@rock-chips.com>
Am Mittwoch, 9. November 2016, 21:21:54 CET schrieb Caesar Wang:
> From: zhangqing <zhangqing@rock-chips.com>
>
> 1.add pd node for RK3399 Soc
> 2.create power domain tree
> 3.add qos node for domain
> 4.add the pd_sd consumers node
>
> Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
> Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Applied to my dts64 branch after some tweaks to patch subject and commit
message.
Thanks
Heiko
^ permalink raw reply
* [PATCH v2 2/9] arm64: dts: rockchip: add pd_sd power node for rk3399
From: Heiko Stuebner @ 2016-11-14 15:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478697721-2323-3-git-send-email-wxt@rock-chips.com>
Am Mittwoch, 9. November 2016, 21:21:54 CET schrieb Caesar Wang:
> From: zhangqing <zhangqing@rock-chips.com>
>
> 1.add pd node for RK3399 Soc
> 2.create power domain tree
> 3.add qos node for domain
> 4.add the pd_sd consumers node
>
> Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
> Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Applied to my dts64 branch after some tweaks to patch subject and commit
message.
Thanks
Heiko
^ permalink raw reply
* Re: [PATCH v2 2/9] arm64: dts: rockchip: add pd_sd power node for rk3399
From: Heiko Stuebner @ 2016-11-14 15:27 UTC (permalink / raw)
To: Caesar Wang
Cc: eddie.cai-TNX95d0MmH7DzftRWevZcw, tfiga-F7+t8E8rja9g9hUCZPvPmw,
zhangqing, 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-3-git-send-email-wxt-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Am Mittwoch, 9. November 2016, 21:21:54 CET schrieb Caesar Wang:
> From: zhangqing <zhangqing-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
>
> 1.add pd node for RK3399 Soc
> 2.create power domain tree
> 3.add qos node for domain
> 4.add the pd_sd consumers node
>
> Signed-off-by: Elaine Zhang <zhangqing-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> Signed-off-by: Caesar Wang <wxt-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Applied to my dts64 branch after some tweaks to patch subject and commit
message.
Thanks
Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [Qemu-devel] [RFC 0/3] aio: experimental virtio-blk polling mode
From: Stefan Hajnoczi @ 2016-11-14 15:26 UTC (permalink / raw)
To: Karl Rister
Cc: Stefan Hajnoczi, qemu-devel, Andrew Theurer, Paolo Bonzini,
Fam Zheng
In-Reply-To: <5826231D.7070208@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 3836 bytes --]
On Fri, Nov 11, 2016 at 01:59:25PM -0600, Karl Rister wrote:
> On 11/09/2016 11:13 AM, Stefan Hajnoczi wrote:
> > Recent performance investigation work done by Karl Rister shows that the
> > guest->host notification takes around 20 us. This is more than the "overhead"
> > of QEMU itself (e.g. block layer).
> >
> > One way to avoid the costly exit is to use polling instead of notification.
> > The main drawback of polling is that it consumes CPU resources. In order to
> > benefit performance the host must have extra CPU cycles available on physical
> > CPUs that aren't used by the guest.
> >
> > This is an experimental AioContext polling implementation. It adds a polling
> > callback into the event loop. Polling functions are implemented for virtio-blk
> > virtqueue guest->host kick and Linux AIO completion.
> >
> > The QEMU_AIO_POLL_MAX_NS environment variable sets the number of nanoseconds to
> > poll before entering the usual blocking poll(2) syscall. Try setting this
> > variable to the time from old request completion to new virtqueue kick.
> >
> > By default no polling is done. The QEMU_AIO_POLL_MAX_NS must be set to get any
> > polling!
> >
> > Karl: I hope you can try this patch series with several QEMU_AIO_POLL_MAX_NS
> > values. If you don't find a good value we should double-check the tracing data
> > to see if this experimental code can be improved.
>
> Stefan
>
> I ran some quick tests with your patches and got some pretty good gains,
> but also some seemingly odd behavior.
>
> These results are for a 5 minute test doing sequential 4KB requests from
> fio using O_DIRECT, libaio, and IO depth of 1. The requests are
> performed directly against the virtio-blk device (no filesystem) which
> is backed by a 400GB NVme card.
>
> QEMU_AIO_POLL_MAX_NS IOPs
> unset 31,383
> 1 46,860
> 2 46,440
> 4 35,246
> 8 34,973
> 16 46,794
> 32 46,729
> 64 35,520
> 128 45,902
The environment variable is in nanoseconds. The range of values you
tried are very small (all <1 usec). It would be interesting to try
larger values in the ballpark of the latencies you have traced. For
example 2000, 4000, 8000, 16000, and 32000 ns.
Very interesting that QEMU_AIO_POLL_MAX_NS=1 performs so well without
much CPU overhead.
> I found the results for 4, 8, and 64 odd so I re-ran some tests to check
> for consistency. I used values of 2 and 4 and ran each 5 times. Here
> is what I got:
>
> Iteration QEMU_AIO_POLL_MAX_NS=2 QEMU_AIO_POLL_MAX_NS=4
> 1 46,972 35,434
> 2 46,939 35,719
> 3 47,005 35,584
> 4 47,016 35,615
> 5 47,267 35,474
>
> So the results seem consistent.
That is interesting. I don't have an explanation for the consistent
difference between 2 and 4 ns polling time. The time difference is so
small yet the IOPS difference is clear.
Comparing traces could shed light on the cause for this difference.
> I saw some discussion on the patches made which make me think you'll be
> making some changes, is that right? If so, I may wait for the updates
> and then we can run the much more exhaustive set of workloads
> (sequential read and write, random read and write) at various block
> sizes (4, 8, 16, 32, 64, 128, and 256) and multiple IO depths (1 and 32)
> that we were doing when we started looking at this.
I'll send an updated version of the patches.
Stefan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply
* [PATCH] arm64: dts: juno: fix cluster sleep state entry latency on all SoC versions
From: Sudeep Holla @ 2016-11-14 15:26 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Jon Medhurst (Tixy), devicetree, Lorenzo Pieralisi, Liviu Dudau,
Sudeep Holla
The core and the cluster sleep state entry latencies can't be same as
cluster sleep involves more work compared to core level e.g. shared
cache maintenance.
Experiments have shown on an average about 100us more latency for the
cluster sleep state compared to the core level sleep. This patch fixes
the entry latency for the cluster sleep state.
Fixes: 28e10a8f3a03 ("arm64: dts: juno: Add idle-states to device tree")
Cc: Liviu Dudau <liviu.dudau@arm.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: "Jon Medhurst (Tixy)" <tixy@linaro.org>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
arch/arm64/boot/dts/arm/juno-r1.dts | 2 +-
arch/arm64/boot/dts/arm/juno-r2.dts | 2 +-
arch/arm64/boot/dts/arm/juno.dts | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
Hi,
This was found recently when I found that core sleep was chosen when
entering suspend-to-idle state on Juno. Since the wakeup(entry+exit)
latency matched for the both states, cpu sleep state was chosen to enter
in suspend-to-idle.
Regards,
Sudeep
diff --git a/arch/arm64/boot/dts/arm/juno-r1.dts b/arch/arm64/boot/dts/arm/juno-r1.dts
index 3be8a3ef671c..eec37feee8fc 100644
--- a/arch/arm64/boot/dts/arm/juno-r1.dts
+++ b/arch/arm64/boot/dts/arm/juno-r1.dts
@@ -76,7 +76,7 @@
compatible = "arm,idle-state";
arm,psci-suspend-param = <0x1010000>;
local-timer-stop;
- entry-latency-us = <300>;
+ entry-latency-us = <400>;
exit-latency-us = <1200>;
min-residency-us = <2500>;
};
diff --git a/arch/arm64/boot/dts/arm/juno-r2.dts b/arch/arm64/boot/dts/arm/juno-r2.dts
index 614fc9227943..28f40ec44090 100644
--- a/arch/arm64/boot/dts/arm/juno-r2.dts
+++ b/arch/arm64/boot/dts/arm/juno-r2.dts
@@ -76,7 +76,7 @@
compatible = "arm,idle-state";
arm,psci-suspend-param = <0x1010000>;
local-timer-stop;
- entry-latency-us = <300>;
+ entry-latency-us = <400>;
exit-latency-us = <1200>;
min-residency-us = <2500>;
};
diff --git a/arch/arm64/boot/dts/arm/juno.dts b/arch/arm64/boot/dts/arm/juno.dts
index 6b4135e9cfe5..ac5ceb73f45f 100644
--- a/arch/arm64/boot/dts/arm/juno.dts
+++ b/arch/arm64/boot/dts/arm/juno.dts
@@ -76,7 +76,7 @@
compatible = "arm,idle-state";
arm,psci-suspend-param = <0x1010000>;
local-timer-stop;
- entry-latency-us = <300>;
+ entry-latency-us = <400>;
exit-latency-us = <1200>;
min-residency-us = <2500>;
};
--
2.7.4
^ permalink raw reply related
* [PATCH] arm64: dts: juno: fix cluster sleep state entry latency on all SoC versions
From: Sudeep Holla @ 2016-11-14 15:26 UTC (permalink / raw)
To: linux-arm-kernel
The core and the cluster sleep state entry latencies can't be same as
cluster sleep involves more work compared to core level e.g. shared
cache maintenance.
Experiments have shown on an average about 100us more latency for the
cluster sleep state compared to the core level sleep. This patch fixes
the entry latency for the cluster sleep state.
Fixes: 28e10a8f3a03 ("arm64: dts: juno: Add idle-states to device tree")
Cc: Liviu Dudau <liviu.dudau@arm.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: "Jon Medhurst (Tixy)" <tixy@linaro.org>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
arch/arm64/boot/dts/arm/juno-r1.dts | 2 +-
arch/arm64/boot/dts/arm/juno-r2.dts | 2 +-
arch/arm64/boot/dts/arm/juno.dts | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
Hi,
This was found recently when I found that core sleep was chosen when
entering suspend-to-idle state on Juno. Since the wakeup(entry+exit)
latency matched for the both states, cpu sleep state was chosen to enter
in suspend-to-idle.
Regards,
Sudeep
diff --git a/arch/arm64/boot/dts/arm/juno-r1.dts b/arch/arm64/boot/dts/arm/juno-r1.dts
index 3be8a3ef671c..eec37feee8fc 100644
--- a/arch/arm64/boot/dts/arm/juno-r1.dts
+++ b/arch/arm64/boot/dts/arm/juno-r1.dts
@@ -76,7 +76,7 @@
compatible = "arm,idle-state";
arm,psci-suspend-param = <0x1010000>;
local-timer-stop;
- entry-latency-us = <300>;
+ entry-latency-us = <400>;
exit-latency-us = <1200>;
min-residency-us = <2500>;
};
diff --git a/arch/arm64/boot/dts/arm/juno-r2.dts b/arch/arm64/boot/dts/arm/juno-r2.dts
index 614fc9227943..28f40ec44090 100644
--- a/arch/arm64/boot/dts/arm/juno-r2.dts
+++ b/arch/arm64/boot/dts/arm/juno-r2.dts
@@ -76,7 +76,7 @@
compatible = "arm,idle-state";
arm,psci-suspend-param = <0x1010000>;
local-timer-stop;
- entry-latency-us = <300>;
+ entry-latency-us = <400>;
exit-latency-us = <1200>;
min-residency-us = <2500>;
};
diff --git a/arch/arm64/boot/dts/arm/juno.dts b/arch/arm64/boot/dts/arm/juno.dts
index 6b4135e9cfe5..ac5ceb73f45f 100644
--- a/arch/arm64/boot/dts/arm/juno.dts
+++ b/arch/arm64/boot/dts/arm/juno.dts
@@ -76,7 +76,7 @@
compatible = "arm,idle-state";
arm,psci-suspend-param = <0x1010000>;
local-timer-stop;
- entry-latency-us = <300>;
+ entry-latency-us = <400>;
exit-latency-us = <1200>;
min-residency-us = <2500>;
};
--
2.7.4
^ permalink raw reply related
* Re: linux-next: unable to fetch the watchdog tree
From: Wim Van Sebroeck @ 2016-11-14 15:26 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel
In-Reply-To: <20161114093426.2000ff4c@canb.auug.org.au>
Hi Stephen,
This has been fixed. Thanks for notifying me about it.
Kind regards,
Wim.
> Hi Wim,
>
> For the past few days (nearly a week, sorry) fetching the watchdog tree
> (git://www.linux-watchdog.org/linux-watchdog-next.git#master) has
> resulted in a hung connection.
>
> --
> Cheers,
> Stephen Rothwell
^ permalink raw reply
* [PATCH v2 1/9] arm64: dts: rockchip: add eMMC's power domain support for rk3399
From: Heiko Stuebner @ 2016-11-14 15:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5829D1C7.9020105@rock-chips.com>
Am Montag, 14. November 2016, 23:01:27 CET schrieb Caesar Wang:
> On 2016?11?14? 22:45, Heiko Stuebner wrote:
> > 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.
>
> I believe the Elaine is the first author. Sorry for this kind of
> question to brother you again. :(
no problem :-) and thanks for the very fast reply.
Applied to my dts64 branch.
Thanks
Heiko
^ 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 15:26 UTC (permalink / raw)
To: Caesar Wang
Cc: Mark Rutland, devicetree, Elaine Zhang, Catalin Marinas,
Brian Norris, Ziyuan Xu, Will Deacon, Douglas Anderson,
Rob Herring, tfiga, open list:ARM/Rockchip SoC..., eddie.cai,
linux-arm-kernel, David Wu, Jianqun Xu, linux-kernel
In-Reply-To: <5829D1C7.9020105@rock-chips.com>
Am Montag, 14. November 2016, 23:01:27 CET schrieb Caesar Wang:
> On 2016年11月14日 22:45, Heiko Stuebner wrote:
> > 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.
>
> I believe the Elaine is the first author. Sorry for this kind of
> question to brother you again. :(
no problem :-) and thanks for the very fast reply.
Applied to my dts64 branch.
Thanks
Heiko
^ permalink raw reply
* [U-Boot] [PATCH 4/7] tools: sunxi: Add spl image builder
From: Tom Rini @ 2016-11-14 15:25 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20161114152049.wifmnwbptb5ive3h@lukather>
On Mon, Nov 14, 2016 at 04:20:49PM +0100, Maxime Ripard wrote:
> On Fri, Nov 11, 2016 at 11:20:47AM -0500, Tom Rini wrote:
> > On Tue, Nov 08, 2016 at 05:21:14PM +0100, Maxime Ripard wrote:
> >
> > > This program generates raw SPL images that can be flashed on the NAND with
> > > the ECC and randomizer properly set up.
> > >
> > > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> > [snip]
> > > +++ b/tools/sunxi-spl-image-builder.c
> > > @@ -0,0 +1,1113 @@
> > > +/*
> > > + * Generic binary BCH encoding/decoding library
> >
> > OK, but this is also lib/bch.c and re-using lib/ code for tools is a
> > normal best practice. I'd suggest re-factoring this code in sunxi-tools
> > sot that it too borrows lib/bch.c from the kernel (and can re-sync
> > bugfixes if needed). Thanks!
>
> I finally figured that out.
>
> It turns out that the driver was doing a modulo by 0. I guess gcc's
> and our libgcc don't have the same behaviour in this case, but in
> U-boot's case, the function was simply returning (which is kind of
> odd).
>
> I'll send a fix for the driver.
So it's something in how lib/bch.c and lib1funcs.S interact? Please CC
me on these when fixing whatever side of this it is in the kernel,
thanks!
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161114/68184623/attachment.sig>
^ permalink raw reply
* Re: [PATCH] wic: Fix rootfs_size variable not found error.
From: Burton, Ross @ 2016-11-14 15:24 UTC (permalink / raw)
To: Philip Balister; +Cc: OE-core
In-Reply-To: <1478886733-27782-1-git-send-email-philip@balister.org>
[-- Attachment #1: Type: text/plain, Size: 367 bytes --]
On 11 November 2016 at 17:52, Philip Balister <philip@balister.org> wrote:
> Commit 1ba6101ceaee354816e690d44bc9a5dd8dcf4011 introduced the runtime
> error. Thi scommit should fix it. Tested with an sd card build with
> an ext4 file system.
>
Already sent as "wic: use partition size when creating empty partition
files", should be in master soon.
Ross
[-- Attachment #2: Type: text/html, Size: 872 bytes --]
^ permalink raw reply
* [PATCH] driver: ublox: fix memory leak in release
From: Dragos Tatulea @ 2016-11-14 15:24 UTC (permalink / raw)
To: ofono
[-- Attachment #1: Type: text/plain, Size: 526 bytes --]
---
drivers/ubloxmodem/gprs-context.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/ubloxmodem/gprs-context.c b/drivers/ubloxmodem/gprs-context.c
index 7ef05b7..3069e88 100644
--- a/drivers/ubloxmodem/gprs-context.c
+++ b/drivers/ubloxmodem/gprs-context.c
@@ -442,6 +442,7 @@ static void ublox_gprs_context_remove(struct ofono_gprs_context *gc)
g_at_chat_unref(gcd->chat);
memset(gcd, 0, sizeof(*gcd));
+ g_free(gcd);
}
static struct ofono_gprs_context_driver driver = {
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.