* Creating 'wic' image
From: Mike Looijmans @ 2016-11-14 15:23 UTC (permalink / raw)
To: OE-core
In order to make life easier for people, I was looking into creating images
with the "wic" tool.
There's just one big piece of documentation lacking: What's the format it
wants my rootfs and boot files?
http://www.yoctoproject.org/docs/2.2/mega-manual/mega-manual.html
Basically I want an SD card with a FAT boot partition and an ext4 rootfs, and
"sdimage-bootpart" is pretty close to that.
Without "wic", I build a tar of the rootfs and copy the boot files using a bit
of shell scripting.
Adding "wic" to IMAGE_FSTYPES just results in an error that I should set
WKS_FILE but I have no clue as to what file that should point to.
Running wic manually just results in more missing variables that I can't find
what to specify in them...
Kind regards,
Mike Looijmans
System Expert
TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijmans@topicproducts.com
Website: www.topicproducts.com
Please consider the environment before printing this e-mail
^ permalink raw reply
* Re: [Qemu-devel] [PULL 0/1] UUID test fix patch for 2.8
From: Stefan Hajnoczi @ 2016-11-14 15:38 UTC (permalink / raw)
To: Fam Zheng; +Cc: qemu-devel, stefanha
In-Reply-To: <1478869302-2559-1-git-send-email-famz@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 901 bytes --]
On Fri, Nov 11, 2016 at 09:01:41PM +0800, Fam Zheng wrote:
> The following changes since commit 6bbcb76301a72dc80c8d29af13d40bb9a759c9c6:
>
> MAINTAINERS: Remove obsolete stable branches (2016-11-10 15:29:59 +0000)
>
> are available in the git repository at:
>
> git@github.com:famz/qemu tags/for-upstream
>
> for you to fetch changes up to d9c05e507f7a6647cd7b106c8784f1f15a0e4f5c:
>
> test-uuid: fix leak (2016-11-11 20:53:23 +0800)
>
> ----------------------------------------------------------------
>
> This is the memory leak fix for uuid test.
>
> ----------------------------------------------------------------
>
> Marc-André Lureau (1):
> test-uuid: fix leak
>
> tests/test-uuid.c | 1 +
> 1 file changed, 1 insertion(+)
>
> --
> 2.7.4
>
>
Thanks, applied to my staging tree:
https://github.com/stefanha/qemu/commits/staging
Stefan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply
* Re: [PATCH 4/4] sanity.bbclass: fix check_connectivity() for BB_NO_NETWORK = "0"
From: Robert Yang @ 2016-11-14 15:37 UTC (permalink / raw)
To: Christopher Larson; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <CABcZANn7+CW65pS-fV8d=0ju9v5YjAY64=b3=qZLnZ8C+uz+hg@mail.gmail.com>
On 11/14/2016 11:03 PM, Christopher Larson wrote:
>
> On Mon, Nov 14, 2016 at 7:34 AM, Robert Yang <liezhi.yang@windriver.com
> <mailto:liezhi.yang@windriver.com>> wrote:
>
> The old code:
> network_enabled = not d.getVar('BB_NO_NETWORK', True)
>
> It is True only when BB_NO_NETWORK is not set (None),
> but BB_NO_NETWORK = "0" should also be True while "1" means no network,
> "0" means need network in a normal case.
>
> Signed-off-by: Robert Yang <liezhi.yang@windriver.com
> <mailto:liezhi.yang@windriver.com>>
> ---
> meta/classes/sanity.bbclass | 14 +++++++++-----
> 1 file changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass
> index 7e383f9..c5e3809 100644
> --- a/meta/classes/sanity.bbclass
> +++ b/meta/classes/sanity.bbclass
> @@ -363,15 +363,19 @@ def check_connectivity(d):
> test_uris = (d.getVar('CONNECTIVITY_CHECK_URIS', True) or "").split()
> retval = ""
>
> + bbn = d.getVar('BB_NO_NETWORK', True)
> + if bbn not in (None, '0', '1'):
> + return 'BB_NO_NETWORK should be "0" or "1", but it is "%s"' % bbn
>
>
> Does this mirror the same logic used in bitbake? What’s the behavior if it’s
> set, but to the empty string?
bitbake only checks whether it equals "1" or not. Without this patch, an empty
string is the same as not set since it doesn't equal to "1". But if it is
set to "0", bitbake uses it as enable network, sanity.bbclass uses it
as disable netowrk, which are conflicted. We can add checking for empty string,
but do we have to ? Limit it to "0" or "1" makes things clear.
// Robert
> --
> Christopher Larson
> clarson at kergoth dot com
> Founder - BitBake, OpenEmbedded, OpenZaurus
> Maintainer - Tslib
> Senior Software Engineer, Mentor Graphics
^ permalink raw reply
* Re: [PATCH] dma-buf: Use fence_get_rcu_safe() for retrieving the exclusive fence
From: Christian König @ 2016-11-14 15:37 UTC (permalink / raw)
To: Chris Wilson, dri-devel; +Cc: intel-gfx
In-Reply-To: <20161114115540.31155-1-chris@chris-wilson.co.uk>
Am 14.11.2016 um 12:55 schrieb Chris Wilson:
> The current code is subject to a race where we may try to acquire a
> reference on a stale fence:
>
> [13703.335118] WARNING: CPU: 1 PID: 14975 at ./include/linux/kref.h:46 i915_gem_object_wait+0x1a3/0x1c0
> [13703.335184] Modules linked in:
> [13703.335202] CPU: 1 PID: 14975 Comm: gem_concurrent_ Not tainted 4.9.0-rc4+ #26
> [13703.335216] Hardware name: / , BIOS PYBSWCEL.86A.0027.2015.0507.1758 05/07/2015
> [13703.335233] ffffc90002f5bcc8 ffffffff812807de 0000000000000000 0000000000000000
> [13703.335257] ffffc90002f5bd08 ffffffff81073811 0000002e80000000 ffff88026bf7c780
> [13703.335279] 7fffffffffffffff 0000000000000001 ffff88027045a550 ffff88026bf7c780
> [13703.335301] Call Trace:
> [13703.335316] [<ffffffff812807de>] dump_stack+0x4d/0x6f
> [13703.335331] [<ffffffff81073811>] __warn+0xc1/0xe0
> [13703.335343] [<ffffffff810738e8>] warn_slowpath_null+0x18/0x20
> [13703.335355] [<ffffffff813ac443>] i915_gem_object_wait+0x1a3/0x1c0
> [13703.335367] [<ffffffff813ae8ec>] i915_gem_set_domain_ioctl+0xcc/0x330
> [13703.335386] [<ffffffff813534ab>] drm_ioctl+0x1cb/0x410
> [13703.335400] [<ffffffff813ae820>] ? i915_gem_obj_prepare_shmem_write+0x1d0/0x1d0
> [13703.335416] [<ffffffff8135359b>] ? drm_ioctl+0x2bb/0x410
> [13703.335429] [<ffffffff8117d32f>] do_vfs_ioctl+0x8f/0x5c0
> [13703.335442] [<ffffffff8117d89c>] SyS_ioctl+0x3c/0x70
> [13703.335456] [<ffffffff815a07a4>] entry_SYSCALL_64_fastpath+0x17/0x98
> [13703.335558] ---[ end trace fd24176416ba6981 ]---
> [13703.382778] general protection fault: 0000 [#1] SMP
> [13703.382802] Modules linked in:
> [13703.382816] CPU: 1 PID: 14967 Comm: gem_concurrent_ Tainted: G W 4.9.0-rc4+ #26
> [13703.382828] Hardware name: / , BIOS PYBSWCEL.86A.0027.2015.0507.1758 05/07/2015
> [13703.382841] task: ffff880275458000 task.stack: ffffc90002f18000
> [13703.382849] RIP: 0010:[<ffffffff813b3534>] [<ffffffff813b3534>] i915_gem_request_retire+0x2b4/0x320
> [13703.382870] RSP: 0018:ffffc90002f1bbc8 EFLAGS: 00010293
> [13703.382878] RAX: dead000000000200 RBX: ffff88026bf7dce8 RCX: dead000000000100
> [13703.382887] RDX: dead000000000100 RSI: ffff88026bf7c930 RDI: ffff88026bf7dd00
> [13703.382897] RBP: ffffc90002f1bbf8 R08: 00000000ffffffff R09: ffff88026b89a000
> [13703.382905] R10: 0000000000000001 R11: ffff88026bbe8fe0 R12: ffff88026bf7c000
> [13703.382913] R13: ffff880275af8000 R14: ffff88026bf7c180 R15: dead000000000200
> [13703.382922] FS: 00007f89e787d740(0000) GS:ffff88027fd00000(0000) knlGS:0000000000000000
> [13703.382934] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [13703.382942] CR2: 00007f9053d2e000 CR3: 000000026d414000 CR4: 00000000001006e0
> [13703.382951] Stack:
> [13703.382958] ffff880275413000 ffffc90002f1bde8 ffff880275af8000 ffff880274e8a600
> [13703.382976] ffff880276a06000 ffffc90002f1bde8 ffffc90002f1bc38 ffffffff813b48c5
> [13703.382995] ffffc90002f1bc00 ffffc90002f1bde8 ffff88026972a440 0000000000000000
> [13703.383021] Call Trace:
> [13703.383032] [<ffffffff813b48c5>] i915_gem_request_alloc+0xa5/0x350
> [13703.383043] [<ffffffff813a17c3>] i915_gem_do_execbuffer.isra.41+0x7b3/0x18b0
> [13703.383055] [<ffffffff813b144c>] ? i915_gem_object_get_sg+0x25c/0x2b0
> [13703.383065] [<ffffffff813b1d4d>] ? i915_gem_object_get_page+0x1d/0x50
> [13703.383076] [<ffffffff813b28cc>] ? i915_gem_pwrite_ioctl+0x66c/0x6d0
> [13703.383086] [<ffffffff813a2c25>] i915_gem_execbuffer2+0x95/0x1e0
> [13703.383096] [<ffffffff813534ab>] drm_ioctl+0x1cb/0x410
> [13703.383105] [<ffffffff813a2b90>] ? i915_gem_execbuffer+0x2d0/0x2d0
> [13703.383117] [<ffffffff810c3df0>] ? hrtimer_start_range_ns+0x1a0/0x310
> [13703.383128] [<ffffffff8117d32f>] do_vfs_ioctl+0x8f/0x5c0
> [13703.383140] [<ffffffff810c60e8>] ? SyS_timer_settime+0x118/0x1a0
> [13703.383150] [<ffffffff8117d89c>] SyS_ioctl+0x3c/0x70
> [13703.383162] [<ffffffff815a07a4>] entry_SYSCALL_64_fastpath+0x17/0x98
> [13703.383172] Code: 49 39 c6 48 8d 70 e8 48 8d 5f e8 75 16 eb 47 48 8d 43 18 48 8b 53 18 48 89 de 49 39 c6 48 8d 5a e8 74 33 48 8b 56 08 48 8b 46 10 <48> 89 42 08 48 89 10 f6 46 38 01 48 89 4e 08 4c 89 7e 10 74 cf
> [13703.383557] RIP [<ffffffff813b3534>] i915_gem_request_retire+0x2b4/0x320
> [13703.383570] RSP <ffffc90002f1bbc8>
> [13703.383586] ---[ end trace fd24176416ba6982 ]---
>
> This is fixed by using the kref_get_unless_zero() as a full memory
> barrier to validate the fence is still the current exclusive fence before
> returning it back to the caller. (Note the fix only requires using
> dma_fence_get_rcu() and correct handling, but we may as well use the
> helper rather than inline equivalent code.)
>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Sumit Semwal <sumit.semwal@linaro.org
Reviewed-by: Christian König <christian.koenig@amd.com>.
> ---
> include/linux/reservation.h | 15 ++++++---------
> 1 file changed, 6 insertions(+), 9 deletions(-)
>
> diff --git a/include/linux/reservation.h b/include/linux/reservation.h
> index 2e313cca08f0..d9706a6f5ae2 100644
> --- a/include/linux/reservation.h
> +++ b/include/linux/reservation.h
> @@ -177,17 +177,14 @@ static inline struct dma_fence *
> reservation_object_get_excl_rcu(struct reservation_object *obj)
> {
> struct dma_fence *fence;
> - unsigned seq;
> -retry:
> - seq = read_seqcount_begin(&obj->seq);
> +
> + if (!rcu_access_pointer(obj->fence_excl))
> + return NULL;
> +
> rcu_read_lock();
> - fence = rcu_dereference(obj->fence_excl);
> - if (read_seqcount_retry(&obj->seq, seq)) {
> - rcu_read_unlock();
> - goto retry;
> - }
> - fence = dma_fence_get(fence);
> + fence = dma_fence_get_rcu_safe(&obj->fence_excl);
> rcu_read_unlock();
> +
> return fence;
> }
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v11 11/22] vfio iommu: Add blocking notifier to notify DMA_UNMAP
From: Alex Williamson @ 2016-11-14 15:37 UTC (permalink / raw)
To: Kirti Wankhede
Cc: pbonzini, kraxel, cjia, qemu-devel, kvm, kevin.tian, jike.song,
bjsdjshi, linux-kernel
In-Reply-To: <6f8c77c4-2155-d3ae-75ad-931364fba16b@nvidia.com>
On Mon, 14 Nov 2016 13:22:08 +0530
Kirti Wankhede <kwankhede@nvidia.com> wrote:
> On 11/9/2016 2:58 AM, Alex Williamson wrote:
> > On Wed, 9 Nov 2016 01:29:19 +0530
> > Kirti Wankhede <kwankhede@nvidia.com> wrote:
> >
> >> On 11/8/2016 11:16 PM, Alex Williamson wrote:
> >>> On Tue, 8 Nov 2016 21:56:29 +0530
> >>> Kirti Wankhede <kwankhede@nvidia.com> wrote:
> >>>
> >>>> On 11/8/2016 5:15 AM, Alex Williamson wrote:
> >>>>> On Sat, 5 Nov 2016 02:40:45 +0530
> >>>>> Kirti Wankhede <kwankhede@nvidia.com> wrote:
> >>>>>
> >>>> ...
> >>>>>>
> >>>>>> +int vfio_register_notifier(struct device *dev, struct notifier_block *nb)
> >>>>>
> >>>>> Is the expectation here that this is a generic notifier for all
> >>>>> vfio->mdev signaling? That should probably be made clear in the mdev
> >>>>> API to avoid vendor drivers assuming their notifier callback only
> >>>>> occurs for unmaps, even if that's currently the case.
> >>>>>
> >>>>
> >>>> Ok. Adding comment about notifier callback in mdev_device which is part
> >>>> of next patch.
> >>>>
> >>>> ...
> >>>>
> >>>>>> mutex_lock(&iommu->lock);
> >>>>>>
> >>>>>> - if (!iommu->external_domain) {
> >>>>>> + /* Fail if notifier list is empty */
> >>>>>> + if ((!iommu->external_domain) || (!iommu->notifier.head)) {
> >>>>>> ret = -EINVAL;
> >>>>>> goto pin_done;
> >>>>>> }
> >>>>>> @@ -867,6 +870,11 @@ unlock:
> >>>>>> /* Report how much was unmapped */
> >>>>>> unmap->size = unmapped;
> >>>>>>
> >>>>>> + if (unmapped && iommu->external_domain)
> >>>>>> + blocking_notifier_call_chain(&iommu->notifier,
> >>>>>> + VFIO_IOMMU_NOTIFY_DMA_UNMAP,
> >>>>>> + unmap);
> >>>>>
> >>>>> This is after the fact, there's already a gap here where pages are
> >>>>> unpinned and the mdev device is still running.
> >>>>
> >>>> Oh, there is a bug here, now unpin_pages() take user_pfn as argument and
> >>>> find vfio_dma. If its not found, it doesn't unpin pages. We have to call
> >>>> this notifier before vfio_remove_dma(). But if we call this before
> >>>> vfio_remove_dma() there will be deadlock since iommu->lock is already
> >>>> held here and vfio_iommu_type1_unpin_pages() will also try to hold
> >>>> iommu->lock.
> >>>> If we want to call blocking_notifier_call_chain() before
> >>>> vfio_remove_dma(), sequence should be:
> >>>>
> >>>> unmapped += dma->size;
> >>>> mutex_unlock(&iommu->lock);
> >>>> if (iommu->external_domain)) {
> >>>> struct vfio_iommu_type1_dma_unmap nb_unmap;
> >>>>
> >>>> nb_unmap.iova = dma->iova;
> >>>> nb_unmap.size = dma->size;
> >>>> blocking_notifier_call_chain(&iommu->notifier,
> >>>> VFIO_IOMMU_NOTIFY_DMA_UNMAP,
> >>>> &nb_unmap);
> >>>> }
> >>>> mutex_lock(&iommu->lock);
> >>>> vfio_remove_dma(iommu, dma);
> >>>
> >>> It seems like it would be worthwhile to have the rb-tree rooted in the
> >>> vfio-dma, then we only need to call the notifier if there are pages
> >>> pinned within that vfio-dma (ie. the rb-tree is not empty). We can
> >>> then release the lock call the notifier, re-acquire the lock, and
> >>> BUG_ON if the rb-tree still is not empty. We might get duplicate pfns
> >>> between separate vfio_dma structs, but as I mentioned in other replies,
> >>> that seems like an exception that we don't need to optimize for.
> >>>
> >>
> >> If we don't optimize for the case where iova from different vfio_dma are
> >> mapped to same pfn and we would not consider this case for page
> >> accounting then:
> >
> > Just to clarify, the current code (not handling mdevs) will pin and do
> > page accounting per iova, regardless of whether the iova translates to a
> > unique pfn. As long as we do no worse than that, I'm ok.
> >
> >> - have rb tree of pinned iova, where key would be iova, in each vfio_dma
> >> structure.
> >> - iova tracking structure would have iova and ref_count only.
> >> - page accounting would only count number of iova's in rb_tree, case
> >> where different iova could map to same pfn would not be considered in
> >> this implementation for now.
> >> - vfio_unpin_pages() would have user_pfn and pfn as input, we would
> >> validate that iova exist in rb tree and trust vendor driver that
> >> corresponding pfn is correct, there is no validation of pfn. If want
> >> validate pfn, call GUP, verify pfn and call put_pfn().
> >> - In .release() or .detach_group() path, if there are entries in this rb
> >> tree, call GUP again using that iova, get pfn and then call
> >> put_pfn(pfn) for ref_count+1 times. This is because we are not keeping
> >> pfn in our tracking logic.
> >
> > Wait a sec, if we detach a group from the container and it's not the
> > last group in the container (which would trigger a release), we can't
> > assume anything about which vfio_dma entries were associated with that
> > device. The vendor driver, through the release of the device(s) within
> > that group, needs to unpin. In a container release, we need to send a
> > notifier to the vendor driver(s) to cause an unpin. This is the only
> > mechanism we have to ensure that vendor drivers are not leaking
> > references. If during the release, after the notifier, if any
> > vfio_pfns remain, we need to BUG_ON, just like we need to do for any
> > other DMA_UNMAP.
> >
> > Also, I'll say it again, I also don't like this API of passing around
> > potentially giant arrays, and especially the API of relying on the
> > vendor driver to tell us an arbitrary pfn to unpin. If we make the
> > assumption that vendor drivers do not pin lots and lots of memory,
> > perhaps we could use a struct vfio_pfn as:
> >
> > struct vfio_pfn {
> > struct rb_node node;
> > dma_addr_t iova; /* key */
> > unsigned long pfn;
> > atomic_t ref_count;
> > };
> >
> > This puts us at 44-bytes per pfn, which isn't great, but I think it
> > puts us in a better position with the API that we could make use of a
> > page-table or sparse array in the future that would eliminate the
> > rb_node and make the iova implicit in the location of the data
> > structure. That would leave only the pfn and ref_count, which could
> > potentially be combined into a single 8-byte field if we had per
> > vfio_dma (or higher) locking to avoid the atomic_t (and we're happy that
> > the reference count is always less than PAGE_SIZE, ie. we could fail
> > pinning if we get to that point).
> >
>
> Ok.
> - I'll have above structure to track pinned pfn for now and a rb-tree in
> vfio_dma structure that would keep track of pages pinned in that range,
> dma->iova to dma->iova + dma->size.
> - Key for pfn_list rb-tree would be iova, instead of pfn.
> - Removing address space structure. vfio_dma keeps task structure, which
> would be used to get mm structure (using get_task_mm(task) and
> mmput(mm)) for pin/unpin and page accounting.
> - vfio_unpin_pages() would have array of user_pfns as input argument,
> instead of array of pfns.
> - On vfio_pin_pages(), pinning would happen once. On later call to
> vfio_pin_pages() with same user_pfn, if iova is found in pfn_list, only
> ref_count would be incremented.
> - In vfio_unpin_pages(), ref_count is decremented and page will be
> unpinned when ref_count is 0.
> - For vfio_pin_pages() and vfio_unpin_pages() input array, number of
> elements in array should be less that PAGE_SIZE. If vendor driver wants
> to use for more pages, array should be split it in chunks of PAGE_SIZE.
Yes, this is what we discussed offline, the size of the arrays should
never exceed PAGE_SIZE, therefore the number of entries should never
exceed PAGE_SIZE/sizeof(pfn). The iommu driver should fault with -E2BIG
if the vendor driver attempts to exceed this.
> - Updating page accounting logic with above changes.
Thanks,
Alex
^ permalink raw reply
* Re: [PATCH v2] ARM: at91/dt: add dts file for sama5d36ek CMP board
From: Nicolas Ferre @ 2016-11-14 15:36 UTC (permalink / raw)
To: Wenyou Yang, Alexandre Belloni, Russell King, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala
Cc: linux-kernel, Wenyou Yang, devicetree, linux-arm-kernel
In-Reply-To: <1478055958-8463-1-git-send-email-wenyou.yang@atmel.com>
Le 02/11/2016 à 04:05, Wenyou Yang a écrit :
> The sama5d36ek CMP board is the variant of sama5d3xek board.
> It is equipped with the low-power DDR2 SDRAM, PMIC ACT8865 and
> some power rail. Its main purpose is used to measure the power
> consumption.
> The difference of the sama5d36ek CMP dts from sama5d36ek dts
> is listed as below.
> 1. The USB host nodes are removed, that is, the USB host is disabled.
> 2. The gpio_keys node is added to wake up from the sleep.
> 3. The LCD isn't supported due to the pins for LCD are conflicted
> with gpio_keys.
> 4. The adc0 node support the pinctrl sleep state to fix the over
> consumption on VDDANA.
>
> As said in errata, "When the USB host ports are used in high speed
> mode (EHCI), it is not possible to suspend the ports if no device is
> attached on each port. This leads to increased power consumption even
> if the system is in a low power mode." That is why the the USB host
> is disabled.
>
> Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com>
> ---
>
> Changes in v2:
> - Add the pinctrl sleep state for adc0 node to fix the over
> consumption on VDDANA.
> - Improve the commit log.
>
> arch/arm/boot/dts/sama5d36ek_cmp.dts | 51 +++++++
> arch/arm/boot/dts/sama5d3xcm_cmp.dtsi | 166 +++++++++++++++++++++
> arch/arm/boot/dts/sama5d3xmb_cmp.dtsi | 265 ++++++++++++++++++++++++++++++++++
> 3 files changed, 482 insertions(+)
> create mode 100644 arch/arm/boot/dts/sama5d36ek_cmp.dts
> create mode 100644 arch/arm/boot/dts/sama5d3xcm_cmp.dtsi
> create mode 100644 arch/arm/boot/dts/sama5d3xmb_cmp.dtsi
>
> diff --git a/arch/arm/boot/dts/sama5d36ek_cmp.dts b/arch/arm/boot/dts/sama5d36ek_cmp.dts
> new file mode 100644
> index 0000000..fd6bcd6
> --- /dev/null
> +++ b/arch/arm/boot/dts/sama5d36ek_cmp.dts
> @@ -0,0 +1,51 @@
> +/*
> + * sama5d36ek_cmp.dts - Device Tree file for SAMA5D36-EK CMP board
> + *
> + * Copyright (C) 2016 Atmel,
> + *
> + * Licensed under GPLv2 or later.
No, in fact we now use a dual license scheme for DT files. Please have a
look at the recent board that we posted to take the header from them.
> + */
> +/dts-v1/;
> +#include "sama5d36.dtsi"
> +#include "sama5d3xmb_cmp.dtsi"
> +
> +/ {
> + model = "Atmel SAMA5D36-EK";
> + compatible = "atmel,sama5d36ek", "atmel,sama5d3xmb", "atmel,sama5d3xcm", "atmel,sama5d36", "atmel,sama5d3", "atmel,sama5";
I don't think the model name nor the compatible string reflect the
nature of this new "CMP" board.
> +
> + ahb {
> + apb {
> + spi0: spi@f0004000 {
> + status = "okay";
> + };
> +
> + ssc0: ssc@f0008000 {
> + status = "okay";
> + };
> +
> + can0: can@f000c000 {
> + status = "okay";
> + };
> +
> + i2c0: i2c@f0014000 {
> + status = "okay";
> + };
> +
> + i2c1: i2c@f0018000 {
> + status = "okay";
> + };
> +
> + macb0: ethernet@f0028000 {
> + status = "okay";
> + };
> +
> + macb1: ethernet@f802c000 {
> + status = "okay";
> + };
> + };
> + };
> +
> + sound {
> + status = "okay";
> + };
> +};
> diff --git a/arch/arm/boot/dts/sama5d3xcm_cmp.dtsi b/arch/arm/boot/dts/sama5d3xcm_cmp.dtsi
> new file mode 100644
> index 0000000..77638c3
> --- /dev/null
> +++ b/arch/arm/boot/dts/sama5d3xcm_cmp.dtsi
> @@ -0,0 +1,166 @@
> +/*
> + * sama5d3xcm_cmp.dtsi - Device Tree Include file for SAMA5D36 CMP CPU Module
> + *
> + * Copyright (C) 2016 Atmel,
> + *
> + * Licensed under GPLv2 or later.
Ditto.
> + */
> +
> +/ {
> + compatible = "atmel,sama5d3xcm", "atmel,sama5d3", "atmel,sama5";
Ditto.
> +
> + chosen {
> + bootargs = "rootfstype=ubifs ubi.mtd=5 root=ubi0:rootfs";
Remove bootargs.
> + stdout-path = "serial0:115200n8";
> + };
> +
> + memory {
> + reg = <0x20000000 0x20000000>;
> + };
> +
> + clocks {
> + slow_xtal {
> + clock-frequency = <32768>;
> + };
> +
> + main_xtal {
> + clock-frequency = <12000000>;
> + };
> + };
> +
> + ahb {
> + apb {
> + spi0: spi@f0004000 {
> + cs-gpios = <&pioD 13 0>, <0>, <0>, <0>;
> + };
> +
> + macb0: ethernet@f0028000 {
> + phy-mode = "rgmii";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ethernet-phy@1 {
> + reg = <0x1>;
> + interrupt-parent = <&pioB>;
> + interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
> + txen-skew-ps = <800>;
> + txc-skew-ps = <3000>;
> + rxdv-skew-ps = <400>;
> + rxc-skew-ps = <3000>;
> + rxd0-skew-ps = <400>;
> + rxd1-skew-ps = <400>;
> + rxd2-skew-ps = <400>;
> + rxd3-skew-ps = <400>;
> + };
> +
> + ethernet-phy@7 {
> + reg = <0x7>;
> + interrupt-parent = <&pioB>;
> + interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
> + txen-skew-ps = <800>;
> + txc-skew-ps = <3000>;
> + rxdv-skew-ps = <400>;
> + rxc-skew-ps = <3000>;
> + rxd0-skew-ps = <400>;
> + rxd1-skew-ps = <400>;
> + rxd2-skew-ps = <400>;
> + rxd3-skew-ps = <400>;
> + };
> + };
> +
> + i2c1: i2c@f0018000 {
> + pmic: act8865@5b {
> + compatible = "active-semi,act8865";
> + reg = <0x5b>;
> + status = "disabled";
> +
> + regulators {
> + vcc_1v8_reg: DCDC_REG1 {
> + regulator-name = "VCC_1V8";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-always-on;
> + };
> +
> + vcc_1v2_reg: DCDC_REG2 {
> + regulator-name = "VCC_1V2";
> + regulator-min-microvolt = <1100000>;
> + regulator-max-microvolt = <1300000>;
> + regulator-always-on;
> + };
> +
> + vcc_3v3_reg: DCDC_REG3 {
> + regulator-name = "VCC_3V3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-always-on;
> + };
> +
> + vddana_reg: LDO_REG1 {
> + regulator-name = "VDDANA";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-always-on;
> + };
> +
> + vddfuse_reg: LDO_REG2 {
> + regulator-name = "FUSE_2V5";
> + regulator-min-microvolt = <2500000>;
> + regulator-max-microvolt = <2500000>;
> + };
> + };
> + };
> + };
> + };
> +
> + nand0: nand@60000000 {
> + nand-bus-width = <8>;
> + nand-ecc-mode = "hw";
> + atmel,has-pmecc;
> + atmel,pmecc-cap = <4>;
> + atmel,pmecc-sector-size = <512>;
> + nand-on-flash-bbt;
> + status = "okay";
> +
> + at91bootstrap@0 {
> + label = "at91bootstrap";
> + reg = <0x0 0x40000>;
> + };
> +
> + bootloader@40000 {
> + label = "bootloader";
> + reg = <0x40000 0x80000>;
> + };
> +
> + bootloaderenv@c0000 {
> + label = "bootloader env";
> + reg = <0xc0000 0xc0000>;
> + };
> +
> + dtb@180000 {
> + label = "device tree";
> + reg = <0x180000 0x80000>;
> + };
> +
> + kernel@200000 {
> + label = "kernel";
> + reg = <0x200000 0x600000>;
> + };
> +
> + rootfs@800000 {
> + label = "rootfs";
> + reg = <0x800000 0x0f800000>;
> + };
> + };
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + d2 {
> + label = "d2";
> + gpios = <&pioE 25 GPIO_ACTIVE_LOW>; /* PE25, conflicts with A25, RXD2 */
> + linux,default-trigger = "heartbeat";
> + };
> + };
> +};
> diff --git a/arch/arm/boot/dts/sama5d3xmb_cmp.dtsi b/arch/arm/boot/dts/sama5d3xmb_cmp.dtsi
> new file mode 100644
> index 0000000..62c6230
> --- /dev/null
> +++ b/arch/arm/boot/dts/sama5d3xmb_cmp.dtsi
> @@ -0,0 +1,265 @@
> +/*
> + * sama5d3xmb_cmp.dts - Device Tree file for SAMA5D3x CMP mother board
> + *
> + * Copyright (C) 2016 Atmel,
> + *
> + * Licensed under GPLv2 or later.
Ditto.
> + */
> +#include "sama5d3xcm_cmp.dtsi"
> +
> +/ {
> + compatible = "atmel,sama5d3xmb", "atmel,sama5d3xcm", "atmel,sama5d3", "atmel,sama5";
Ditto.
> +
> + ahb {
> + apb {
> + mmc0: mmc@f0000000 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_mmc0_clk_cmd_dat0 &pinctrl_mmc0_dat1_3 &pinctrl_mmc0_cd>;
> + status = "okay";
> + slot@0 {
> + reg = <0>;
> + bus-width = <4>;
> + cd-gpios = <&pioD 17 GPIO_ACTIVE_HIGH>;
> + };
> + };
> +
> + spi0: spi@f0004000 {
> + dmas = <0>, <0>; /* Do not use DMA for spi0 */
> +
> + m25p80@0 {
> + compatible = "atmel,at25df321a";
> + spi-max-frequency = <50000000>;
> + reg = <0>;
> + };
> + };
> +
> + ssc0: ssc@f0008000 {
> + atmel,clk-from-rk-pin;
> + };
> +
> + /*
> + * i2c0 conflicts with ISI:
> + * disable it to allow the use of ISI
> + * can not enable audio when i2c0 disabled
> + */
> + i2c0: i2c@f0014000 {
> + wm8904: wm8904@1a {
> + compatible = "wlf,wm8904";
> + reg = <0x1a>;
> + clocks = <&pck0>;
> + clock-names = "mclk";
> + };
> + };
> +
> + i2c1: i2c@f0018000 {
> + ov2640: camera@0x30 {
> + compatible = "ovti,ov2640";
> + reg = <0x30>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_pck1_as_isi_mck &pinctrl_sensor_power &pinctrl_sensor_reset>;
> + resetb-gpios = <&pioE 24 GPIO_ACTIVE_LOW>;
> + pwdn-gpios = <&pioE 29 GPIO_ACTIVE_HIGH>;
> + /* use pck1 for the master clock of ov2640 */
> + clocks = <&pck1>;
> + clock-names = "xvclk";
> + assigned-clocks = <&pck1>;
> + assigned-clock-rates = <25000000>;
> +
> + port {
> + ov2640_0: endpoint {
> + remote-endpoint = <&isi_0>;
> + bus-width = <8>;
> + };
> + };
> + };
> + };
> +
> + usart1: serial@f0020000 {
> + dmas = <0>, <0>; /* Do not use DMA for usart1 */
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usart1 &pinctrl_usart1_rts_cts>;
> + status = "okay";
> + };
> +
> + isi: isi@f0034000 {
> + port {
> + isi_0: endpoint {
> + remote-endpoint = <&ov2640_0>;
> + bus-width = <8>;
> + vsync-active = <1>;
> + hsync-active = <1>;
> + };
> + };
> + };
> +
> + mmc1: mmc@f8000000 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_mmc1_clk_cmd_dat0 &pinctrl_mmc1_dat1_3 &pinctrl_mmc1_cd>;
> + status = "okay";
> + slot@0 {
> + reg = <0>;
> + bus-width = <4>;
> + cd-gpios = <&pioD 18 GPIO_ACTIVE_HIGH>;
> + };
> + };
> +
> + adc0: adc@f8018000 {
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <
> + &pinctrl_adc0_adtrg
> + &pinctrl_adc0_ad0
> + &pinctrl_adc0_ad1
> + &pinctrl_adc0_ad2
> + &pinctrl_adc0_ad3
> + &pinctrl_adc0_ad4
> + >;
> + pinctrl-1 = <
> + &pinctrl_adc0_adtrg_sleep
> + &pinctrl_adc0_ad0_sleep
> + &pinctrl_adc0_ad1_sleep
> + &pinctrl_adc0_ad2_sleep
> + &pinctrl_adc0_ad3_sleep
> + &pinctrl_adc0_ad4_sleep
> + >;
> + status = "okay";
> + };
> +
> + macb1: ethernet@f802c000 {
> + phy-mode = "rmii";
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> + phy0: ethernet-phy@1 {
> + /*interrupt-parent = <&pioE>;*/
> + /*interrupts = <30 IRQ_TYPE_EDGE_FALLING>;*/
> + reg = <1>;
> + };
> + };
> +
> + pinctrl@fffff200 {
> + adc0 {
> + pinctrl_adc0_adtrg_sleep: adc0_adtrg_1 {
> + atmel,pins =
> + <AT91_PIOD 19 AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(0))>; /* PD19 GPIO output 0 */
> + };
> + pinctrl_adc0_ad0_sleep: adc0_ad0_1 {
> + atmel,pins =
> + <AT91_PIOD 20 AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(0))>; /* PD20 GPIO output 0 */
> + };
> + pinctrl_adc0_ad1_sleep: adc0_ad1_1 {
> + atmel,pins =
> + <AT91_PIOD 21 AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(0))>; /* PD21 GPIO output 0 */
> + };
> + pinctrl_adc0_ad2_sleep: adc0_ad2_1 {
> + atmel,pins =
> + <AT91_PIOD 22 AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(0))>; /* PD22 GPIO output 0 */
> + };
> + pinctrl_adc0_ad3_sleep: adc0_ad3_1 {
> + atmel,pins =
> + <AT91_PIOD 23 AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(0))>; /* PD23 GPIO output 0 */
> + };
> + pinctrl_adc0_ad4_sleep: adc0_ad4_1 {
> + atmel,pins =
> + <AT91_PIOD 24 AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(0))>; /* PD24 GPIO output 0 */
Please remove all these comments. The binding is good enough to
understand easily.
> + };
> + };
> +
> + board {
> + pinctrl_gpio_keys: gpio_keys {
> + atmel,pins =
> + <AT91_PIOE 27 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP>;
> + };
> +
> + pinctrl_mmc0_cd: mmc0_cd {
> + atmel,pins =
> + <AT91_PIOD 17 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP_DEGLITCH>; /* PD17 GPIO with pullup deglitch */
> + };
> +
> + pinctrl_mmc1_cd: mmc1_cd {
> + atmel,pins =
> + <AT91_PIOD 18 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP_DEGLITCH>; /* PD18 GPIO with pullup deglitch */
> + };
> +
> + pinctrl_pck0_as_audio_mck: pck0_as_audio_mck {
> + atmel,pins =
> + <AT91_PIOD 30 AT91_PERIPH_B AT91_PINCTRL_NONE>; /* PD30 periph B */
> + };
> +
> + pinctrl_pck1_as_isi_mck: pck1_as_isi_mck-0 {
> + atmel,pins =
> + <AT91_PIOD 31 AT91_PERIPH_B AT91_PINCTRL_NONE>; /* PD31 periph B ISI_MCK */
> + };
> +
> + pinctrl_sensor_reset: sensor_reset-0 {
> + atmel,pins =
> + <AT91_PIOE 24 AT91_PERIPH_GPIO AT91_PINCTRL_NONE>; /* PE24 gpio */
> + };
> +
> + pinctrl_sensor_power: sensor_power-0 {
> + atmel,pins =
> + <AT91_PIOE 29 AT91_PERIPH_GPIO AT91_PINCTRL_NONE>; /* PE29 gpio */
> + };
> +
> + pinctrl_usba_vbus: usba_vbus {
> + atmel,pins =
> + <AT91_PIOD 29 AT91_PERIPH_GPIO AT91_PINCTRL_DEGLITCH>; /* PD29 GPIO with deglitch */
Here again, all comments are not or great use: remove them.
> + };
> + };
> + };
> +
> + dbgu: serial@ffffee00 {
> + dmas = <0>, <0>; /* Do not use DMA for dbgu */
> + status = "okay";
> + };
> +
> + watchdog@fffffe40 {
> + status = "okay";
> + };
> + };
> +
> + usb0: gadget@00500000 {
> + atmel,vbus-gpio = <&pioD 29 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usba_vbus>;
> + status = "okay";
> + };
> + };
> +
> + sound {
> + compatible = "atmel,asoc-wm8904";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_pck0_as_audio_mck>;
> +
> + atmel,model = "wm8904 @ SAMA5D3EK";
> + atmel,audio-routing =
> + "Headphone Jack", "HPOUTL",
> + "Headphone Jack", "HPOUTR",
> + "IN2L", "Line In Jack",
> + "IN2R", "Line In Jack",
> + "Mic", "MICBIAS",
> + "IN1L", "Mic";
> +
> + atmel,ssc-controller = <&ssc0>;
> + atmel,audio-codec = <&wm8904>;
> +
> + status = "disabled";
> + };
> +
> + /* Conflict with LCD pins */
> + gpio_keys {
> + compatible = "gpio-keys";
> + status = "okay";
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_gpio_keys>;
> +
> + pb_user1 {
> + label = "pb_user1";
> + gpios = <&pioE 27 GPIO_ACTIVE_HIGH>;
> + linux,code = <0x100>;
> + gpio-key,wakeup;
> + };
> + };
> +};
>
--
Nicolas Ferre
^ permalink raw reply
* Re: [PATCH v11 11/22] vfio iommu: Add blocking notifier to notify DMA_UNMAP
From: Alex Williamson @ 2016-11-14 15:37 UTC (permalink / raw)
To: Kirti Wankhede
Cc: pbonzini, kraxel, cjia, qemu-devel, kvm, kevin.tian, jike.song,
bjsdjshi, linux-kernel
In-Reply-To: <6f8c77c4-2155-d3ae-75ad-931364fba16b@nvidia.com>
On Mon, 14 Nov 2016 13:22:08 +0530
Kirti Wankhede <kwankhede@nvidia.com> wrote:
> On 11/9/2016 2:58 AM, Alex Williamson wrote:
> > On Wed, 9 Nov 2016 01:29:19 +0530
> > Kirti Wankhede <kwankhede@nvidia.com> wrote:
> >
> >> On 11/8/2016 11:16 PM, Alex Williamson wrote:
> >>> On Tue, 8 Nov 2016 21:56:29 +0530
> >>> Kirti Wankhede <kwankhede@nvidia.com> wrote:
> >>>
> >>>> On 11/8/2016 5:15 AM, Alex Williamson wrote:
> >>>>> On Sat, 5 Nov 2016 02:40:45 +0530
> >>>>> Kirti Wankhede <kwankhede@nvidia.com> wrote:
> >>>>>
> >>>> ...
> >>>>>>
> >>>>>> +int vfio_register_notifier(struct device *dev, struct notifier_block *nb)
> >>>>>
> >>>>> Is the expectation here that this is a generic notifier for all
> >>>>> vfio->mdev signaling? That should probably be made clear in the mdev
> >>>>> API to avoid vendor drivers assuming their notifier callback only
> >>>>> occurs for unmaps, even if that's currently the case.
> >>>>>
> >>>>
> >>>> Ok. Adding comment about notifier callback in mdev_device which is part
> >>>> of next patch.
> >>>>
> >>>> ...
> >>>>
> >>>>>> mutex_lock(&iommu->lock);
> >>>>>>
> >>>>>> - if (!iommu->external_domain) {
> >>>>>> + /* Fail if notifier list is empty */
> >>>>>> + if ((!iommu->external_domain) || (!iommu->notifier.head)) {
> >>>>>> ret = -EINVAL;
> >>>>>> goto pin_done;
> >>>>>> }
> >>>>>> @@ -867,6 +870,11 @@ unlock:
> >>>>>> /* Report how much was unmapped */
> >>>>>> unmap->size = unmapped;
> >>>>>>
> >>>>>> + if (unmapped && iommu->external_domain)
> >>>>>> + blocking_notifier_call_chain(&iommu->notifier,
> >>>>>> + VFIO_IOMMU_NOTIFY_DMA_UNMAP,
> >>>>>> + unmap);
> >>>>>
> >>>>> This is after the fact, there's already a gap here where pages are
> >>>>> unpinned and the mdev device is still running.
> >>>>
> >>>> Oh, there is a bug here, now unpin_pages() take user_pfn as argument and
> >>>> find vfio_dma. If its not found, it doesn't unpin pages. We have to call
> >>>> this notifier before vfio_remove_dma(). But if we call this before
> >>>> vfio_remove_dma() there will be deadlock since iommu->lock is already
> >>>> held here and vfio_iommu_type1_unpin_pages() will also try to hold
> >>>> iommu->lock.
> >>>> If we want to call blocking_notifier_call_chain() before
> >>>> vfio_remove_dma(), sequence should be:
> >>>>
> >>>> unmapped += dma->size;
> >>>> mutex_unlock(&iommu->lock);
> >>>> if (iommu->external_domain)) {
> >>>> struct vfio_iommu_type1_dma_unmap nb_unmap;
> >>>>
> >>>> nb_unmap.iova = dma->iova;
> >>>> nb_unmap.size = dma->size;
> >>>> blocking_notifier_call_chain(&iommu->notifier,
> >>>> VFIO_IOMMU_NOTIFY_DMA_UNMAP,
> >>>> &nb_unmap);
> >>>> }
> >>>> mutex_lock(&iommu->lock);
> >>>> vfio_remove_dma(iommu, dma);
> >>>
> >>> It seems like it would be worthwhile to have the rb-tree rooted in the
> >>> vfio-dma, then we only need to call the notifier if there are pages
> >>> pinned within that vfio-dma (ie. the rb-tree is not empty). We can
> >>> then release the lock call the notifier, re-acquire the lock, and
> >>> BUG_ON if the rb-tree still is not empty. We might get duplicate pfns
> >>> between separate vfio_dma structs, but as I mentioned in other replies,
> >>> that seems like an exception that we don't need to optimize for.
> >>>
> >>
> >> If we don't optimize for the case where iova from different vfio_dma are
> >> mapped to same pfn and we would not consider this case for page
> >> accounting then:
> >
> > Just to clarify, the current code (not handling mdevs) will pin and do
> > page accounting per iova, regardless of whether the iova translates to a
> > unique pfn. As long as we do no worse than that, I'm ok.
> >
> >> - have rb tree of pinned iova, where key would be iova, in each vfio_dma
> >> structure.
> >> - iova tracking structure would have iova and ref_count only.
> >> - page accounting would only count number of iova's in rb_tree, case
> >> where different iova could map to same pfn would not be considered in
> >> this implementation for now.
> >> - vfio_unpin_pages() would have user_pfn and pfn as input, we would
> >> validate that iova exist in rb tree and trust vendor driver that
> >> corresponding pfn is correct, there is no validation of pfn. If want
> >> validate pfn, call GUP, verify pfn and call put_pfn().
> >> - In .release() or .detach_group() path, if there are entries in this rb
> >> tree, call GUP again using that iova, get pfn and then call
> >> put_pfn(pfn) for ref_count+1 times. This is because we are not keeping
> >> pfn in our tracking logic.
> >
> > Wait a sec, if we detach a group from the container and it's not the
> > last group in the container (which would trigger a release), we can't
> > assume anything about which vfio_dma entries were associated with that
> > device. The vendor driver, through the release of the device(s) within
> > that group, needs to unpin. In a container release, we need to send a
> > notifier to the vendor driver(s) to cause an unpin. This is the only
> > mechanism we have to ensure that vendor drivers are not leaking
> > references. If during the release, after the notifier, if any
> > vfio_pfns remain, we need to BUG_ON, just like we need to do for any
> > other DMA_UNMAP.
> >
> > Also, I'll say it again, I also don't like this API of passing around
> > potentially giant arrays, and especially the API of relying on the
> > vendor driver to tell us an arbitrary pfn to unpin. If we make the
> > assumption that vendor drivers do not pin lots and lots of memory,
> > perhaps we could use a struct vfio_pfn as:
> >
> > struct vfio_pfn {
> > struct rb_node node;
> > dma_addr_t iova; /* key */
> > unsigned long pfn;
> > atomic_t ref_count;
> > };
> >
> > This puts us at 44-bytes per pfn, which isn't great, but I think it
> > puts us in a better position with the API that we could make use of a
> > page-table or sparse array in the future that would eliminate the
> > rb_node and make the iova implicit in the location of the data
> > structure. That would leave only the pfn and ref_count, which could
> > potentially be combined into a single 8-byte field if we had per
> > vfio_dma (or higher) locking to avoid the atomic_t (and we're happy that
> > the reference count is always less than PAGE_SIZE, ie. we could fail
> > pinning if we get to that point).
> >
>
> Ok.
> - I'll have above structure to track pinned pfn for now and a rb-tree in
> vfio_dma structure that would keep track of pages pinned in that range,
> dma->iova to dma->iova + dma->size.
> - Key for pfn_list rb-tree would be iova, instead of pfn.
> - Removing address space structure. vfio_dma keeps task structure, which
> would be used to get mm structure (using get_task_mm(task) and
> mmput(mm)) for pin/unpin and page accounting.
> - vfio_unpin_pages() would have array of user_pfns as input argument,
> instead of array of pfns.
> - On vfio_pin_pages(), pinning would happen once. On later call to
> vfio_pin_pages() with same user_pfn, if iova is found in pfn_list, only
> ref_count would be incremented.
> - In vfio_unpin_pages(), ref_count is decremented and page will be
> unpinned when ref_count is 0.
> - For vfio_pin_pages() and vfio_unpin_pages() input array, number of
> elements in array should be less that PAGE_SIZE. If vendor driver wants
> to use for more pages, array should be split it in chunks of PAGE_SIZE.
Yes, this is what we discussed offline, the size of the arrays should
never exceed PAGE_SIZE, therefore the number of entries should never
exceed PAGE_SIZE/sizeof(pfn). The iommu driver should fault with -E2BIG
if the vendor driver attempts to exceed this.
> - Updating page accounting logic with above changes.
Thanks,
Alex
^ permalink raw reply
* Re: [PATCH v2] sunrpc: svc_age_temp_xprts_now should not call setsockopt non-tcp transports
From: J. Bruce Fields @ 2016-11-14 15:36 UTC (permalink / raw)
To: Chuck Lever; +Cc: Scott Mayhew, Jeff Layton, Linux NFS Mailing List
In-Reply-To: <A0EDEA31-A820-435D-B95F-A68B74F6EEC2@oracle.com>
On Fri, Nov 11, 2016 at 02:38:54PM -0500, Chuck Lever wrote:
>
> > On Nov 11, 2016, at 1:16 PM, Scott Mayhew <smayhew@redhat.com> wrote:
> >
> > This fixes the following panic that can occur with NFSoRDMA.
> >
> > general protection fault: 0000 [#1] SMP
> > Modules linked in: rpcrdma ib_isert iscsi_target_mod ib_iser libiscsi
> > scsi_transport_iscsi ib_srpt target_core_mod ib_srp scsi_transport_srp
> > scsi_tgt ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm iw_cm
> > mlx5_ib ib_core intel_powerclamp coretemp kvm_intel kvm sg ioatdma
> > ipmi_devintf ipmi_ssif dcdbas iTCO_wdt iTCO_vendor_support pcspkr
> > irqbypass sb_edac shpchp dca crc32_pclmul ghash_clmulni_intel edac_core
> > lpc_ich aesni_intel lrw gf128mul glue_helper ablk_helper mei_me mei
> > ipmi_si cryptd wmi ipmi_msghandler acpi_pad acpi_power_meter nfsd
> > auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs libcrc32c sd_mod
> > crc_t10dif crct10dif_generic mgag200 i2c_algo_bit drm_kms_helper
> > syscopyarea sysfillrect sysimgblt ahci fb_sys_fops ttm libahci mlx5_core
> > tg3 crct10dif_pclmul drm crct10dif_common
> > ptp i2c_core libata crc32c_intel pps_core fjes dm_mirror dm_region_hash
> > dm_log dm_mod
> > CPU: 1 PID: 120 Comm: kworker/1:1 Not tainted 3.10.0-514.el7.x86_64 #1
> > Hardware name: Dell Inc. PowerEdge R320/0KM5PX, BIOS 2.4.2 01/29/2015
> > Workqueue: events check_lifetime
> > task: ffff88031f506dd0 ti: ffff88031f584000 task.ti: ffff88031f584000
> > RIP: 0010:[<ffffffff8168d847>] [<ffffffff8168d847>]
> > _raw_spin_lock_bh+0x17/0x50
> > RSP: 0018:ffff88031f587ba8 EFLAGS: 00010206
> > RAX: 0000000000020000 RBX: 20041fac02080072 RCX: ffff88031f587fd8
> > RDX: 0000000000000000 RSI: 0000000000000000 RDI: 20041fac02080072
> > RBP: ffff88031f587bb0 R08: 0000000000000008 R09: ffffffff8155be77
> > R10: ffff880322a59b00 R11: ffffea000bf39f00 R12: 20041fac02080072
> > R13: 000000000000000d R14: ffff8800c4fbd800 R15: 0000000000000001
> > FS: 0000000000000000(0000) GS:ffff880322a40000(0000)
> > knlGS:0000000000000000
> > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > CR2: 00007f3c52d4547e CR3: 00000000019ba000 CR4: 00000000001407e0
> > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> > Stack:
> > 20041fac02080002 ffff88031f587bd0 ffffffff81557830 20041fac02080002
> > ffff88031f587c78 ffff88031f587c40 ffffffff8155ae08 000000010157df32
> > 0000000800000001 ffff88031f587c20 ffffffff81096acb ffffffff81aa37d0
> > Call Trace:
> > [<ffffffff81557830>] lock_sock_nested+0x20/0x50
> > [<ffffffff8155ae08>] sock_setsockopt+0x78/0x940
> > [<ffffffff81096acb>] ? lock_timer_base.isra.33+0x2b/0x50
> > [<ffffffff8155397d>] kernel_setsockopt+0x4d/0x50
> > [<ffffffffa0386284>] svc_age_temp_xprts_now+0x174/0x1e0 [sunrpc]
> > [<ffffffffa03b681d>] nfsd_inetaddr_event+0x9d/0xd0 [nfsd]
> > [<ffffffff81691ebc>] notifier_call_chain+0x4c/0x70
> > [<ffffffff810b687d>] __blocking_notifier_call_chain+0x4d/0x70
> > [<ffffffff810b68b6>] blocking_notifier_call_chain+0x16/0x20
> > [<ffffffff815e8538>] __inet_del_ifa+0x168/0x2d0
> > [<ffffffff815e8cef>] check_lifetime+0x25f/0x270
> > [<ffffffff810a7f3b>] process_one_work+0x17b/0x470
> > [<ffffffff810a8d76>] worker_thread+0x126/0x410
> > [<ffffffff810a8c50>] ? rescuer_thread+0x460/0x460
> > [<ffffffff810b052f>] kthread+0xcf/0xe0
> > [<ffffffff810b0460>] ? kthread_create_on_node+0x140/0x140
> > [<ffffffff81696418>] ret_from_fork+0x58/0x90
> > [<ffffffff810b0460>] ? kthread_create_on_node+0x140/0x140
> > Code: ca 75 f1 5d c3 0f 1f 80 00 00 00 00 eb d9 66 0f 1f 44 00 00 0f 1f
> > 44 00 00 55 48 89 e5 53 48 89 fb e8 7e 04 a0 ff b8 00 00 02 00 <f0> 0f
> > c1 03 89 c2 c1 ea 10 66 39 c2 75 03 5b 5d c3 83 e2 fe 0f
> > RIP [<ffffffff8168d847>] _raw_spin_lock_bh+0x17/0x50
> > RSP <ffff88031f587ba8>
> >
> > Signed-off-by: Scott Mayhew <smayhew@redhat.com>
> > Fixes: c3d4879e ("sunrpc: Add a function to close temporary transports immediately")
>
> Thanks, Scott. That's what I had in mind.
>
> Reviewed-by: Chuck Lever <chuck.lever@oracle.com>
Thanks! Queuing up for 4.9.
--b.
>
>
> > ---
> > include/linux/sunrpc/svc_xprt.h | 1 +
> > net/sunrpc/svc_xprt.c | 11 +----------
> > net/sunrpc/svcsock.c | 21 +++++++++++++++++++++
> > net/sunrpc/xprtrdma/svc_rdma_transport.c | 6 ++++++
> > 4 files changed, 29 insertions(+), 10 deletions(-)
> >
> > diff --git a/include/linux/sunrpc/svc_xprt.h b/include/linux/sunrpc/svc_xprt.h
> > index ab02a45..e5d1934 100644
> > --- a/include/linux/sunrpc/svc_xprt.h
> > +++ b/include/linux/sunrpc/svc_xprt.h
> > @@ -25,6 +25,7 @@ struct svc_xprt_ops {
> > void (*xpo_detach)(struct svc_xprt *);
> > void (*xpo_free)(struct svc_xprt *);
> > int (*xpo_secure_port)(struct svc_rqst *);
> > + void (*xpo_kill_temp_xprt)(struct svc_xprt *);
> > };
> >
> > struct svc_xprt_class {
> > diff --git a/net/sunrpc/svc_xprt.c b/net/sunrpc/svc_xprt.c
> > index c3f6523..3bc1d61 100644
> > --- a/net/sunrpc/svc_xprt.c
> > +++ b/net/sunrpc/svc_xprt.c
> > @@ -1002,14 +1002,8 @@ static void svc_age_temp_xprts(unsigned long closure)
> > void svc_age_temp_xprts_now(struct svc_serv *serv, struct sockaddr *server_addr)
> > {
> > struct svc_xprt *xprt;
> > - struct svc_sock *svsk;
> > - struct socket *sock;
> > struct list_head *le, *next;
> > LIST_HEAD(to_be_closed);
> > - struct linger no_linger = {
> > - .l_onoff = 1,
> > - .l_linger = 0,
> > - };
> >
> > spin_lock_bh(&serv->sv_lock);
> > list_for_each_safe(le, next, &serv->sv_tempsocks) {
> > @@ -1027,10 +1021,7 @@ void svc_age_temp_xprts_now(struct svc_serv *serv, struct sockaddr *server_addr)
> > list_del_init(le);
> > xprt = list_entry(le, struct svc_xprt, xpt_list);
> > dprintk("svc_age_temp_xprts_now: closing %p\n", xprt);
> > - svsk = container_of(xprt, struct svc_sock, sk_xprt);
> > - sock = svsk->sk_sock;
> > - kernel_setsockopt(sock, SOL_SOCKET, SO_LINGER,
> > - (char *)&no_linger, sizeof(no_linger));
> > + xprt->xpt_ops->xpo_kill_temp_xprt(xprt);
> > svc_close_xprt(xprt);
> > }
> > }
> > diff --git a/net/sunrpc/svcsock.c b/net/sunrpc/svcsock.c
> > index 57625f6..a4bc982 100644
> > --- a/net/sunrpc/svcsock.c
> > +++ b/net/sunrpc/svcsock.c
> > @@ -438,6 +438,21 @@ static int svc_tcp_has_wspace(struct svc_xprt *xprt)
> > return !test_bit(SOCK_NOSPACE, &svsk->sk_sock->flags);
> > }
> >
> > +static void svc_tcp_kill_temp_xprt(struct svc_xprt *xprt)
> > +{
> > + struct svc_sock *svsk;
> > + struct socket *sock;
> > + struct linger no_linger = {
> > + .l_onoff = 1,
> > + .l_linger = 0,
> > + };
> > +
> > + svsk = container_of(xprt, struct svc_sock, sk_xprt);
> > + sock = svsk->sk_sock;
> > + kernel_setsockopt(sock, SOL_SOCKET, SO_LINGER,
> > + (char *)&no_linger, sizeof(no_linger));
> > +}
> > +
> > /*
> > * See net/ipv6/ip_sockglue.c : ip_cmsg_recv_pktinfo
> > */
> > @@ -648,6 +663,10 @@ static struct svc_xprt *svc_udp_accept(struct svc_xprt *xprt)
> > return NULL;
> > }
> >
> > +static void svc_udp_kill_temp_xprt(struct svc_xprt *xprt)
> > +{
> > +}
> > +
> > static struct svc_xprt *svc_udp_create(struct svc_serv *serv,
> > struct net *net,
> > struct sockaddr *sa, int salen,
> > @@ -667,6 +686,7 @@ static struct svc_xprt_ops svc_udp_ops = {
> > .xpo_has_wspace = svc_udp_has_wspace,
> > .xpo_accept = svc_udp_accept,
> > .xpo_secure_port = svc_sock_secure_port,
> > + .xpo_kill_temp_xprt = svc_udp_kill_temp_xprt,
> > };
> >
> > static struct svc_xprt_class svc_udp_class = {
> > @@ -1242,6 +1262,7 @@ static struct svc_xprt_ops svc_tcp_ops = {
> > .xpo_has_wspace = svc_tcp_has_wspace,
> > .xpo_accept = svc_tcp_accept,
> > .xpo_secure_port = svc_sock_secure_port,
> > + .xpo_kill_temp_xprt = svc_tcp_kill_temp_xprt,
> > };
> >
> > static struct svc_xprt_class svc_tcp_class = {
> > diff --git a/net/sunrpc/xprtrdma/svc_rdma_transport.c b/net/sunrpc/xprtrdma/svc_rdma_transport.c
> > index 6864fb9..1334de2 100644
> > --- a/net/sunrpc/xprtrdma/svc_rdma_transport.c
> > +++ b/net/sunrpc/xprtrdma/svc_rdma_transport.c
> > @@ -67,6 +67,7 @@ static void svc_rdma_detach(struct svc_xprt *xprt);
> > static void svc_rdma_free(struct svc_xprt *xprt);
> > static int svc_rdma_has_wspace(struct svc_xprt *xprt);
> > static int svc_rdma_secure_port(struct svc_rqst *);
> > +static void svc_rdma_kill_temp_xprt(struct svc_xprt *);
> >
> > static struct svc_xprt_ops svc_rdma_ops = {
> > .xpo_create = svc_rdma_create,
> > @@ -79,6 +80,7 @@ static struct svc_xprt_ops svc_rdma_ops = {
> > .xpo_has_wspace = svc_rdma_has_wspace,
> > .xpo_accept = svc_rdma_accept,
> > .xpo_secure_port = svc_rdma_secure_port,
> > + .xpo_kill_temp_xprt = svc_rdma_kill_temp_xprt,
> > };
> >
> > struct svc_xprt_class svc_rdma_class = {
> > @@ -1317,6 +1319,10 @@ static int svc_rdma_secure_port(struct svc_rqst *rqstp)
> > return 1;
> > }
> >
> > +static void svc_rdma_kill_temp_xprt(struct svc_xprt *xprt)
> > +{
> > +}
> > +
> > int svc_rdma_send(struct svcxprt_rdma *xprt, struct ib_send_wr *wr)
> > {
> > struct ib_send_wr *bad_wr, *n_wr;
> > --
> > 2.4.11
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> --
> Chuck Lever
>
>
^ permalink raw reply
* Re: [Qemu-devel] [RFC 0/3] aio: experimental virtio-blk polling mode
From: Karl Rister @ 2016-11-14 15:36 UTC (permalink / raw)
To: Stefan Hajnoczi
Cc: Stefan Hajnoczi, qemu-devel, Andrew Theurer, Paolo Bonzini,
Fam Zheng
In-Reply-To: <20161114152642.GE26198@stefanha-x1.localdomain>
On 11/14/2016 09:26 AM, Stefan Hajnoczi wrote:
> 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.
Agreed. As I alluded to in another post, I decided to start at 1 and
double the values until I saw a difference with the expectation that it
would have to get quite large before that happened. The results went in
a different direction, and then I got distracted by the variation at
certain points. I figured that by itself the fact that noticeable
improvements were possible with such low values was interesting.
I will definitely continue the progression and capture some larger values.
>
> 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
>
--
Karl Rister <krister@redhat.com>
^ permalink raw reply
* RE: [PATCH 1/2] drm/amdgpu: cleanup unused iterator members for sdma v3
From: Deucher, Alexander @ 2016-11-14 15:36 UTC (permalink / raw)
To: amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
Koenig, Christian
Cc: Huang, Ray
In-Reply-To: <1479127619-23643-1-git-send-email-ray.huang-5C7GfCeVMHo@public.gmane.org>
> -----Original Message-----
> From: amd-gfx [mailto:amd-gfx-bounces@lists.freedesktop.org] On Behalf
> Of Huang Rui
> Sent: Monday, November 14, 2016 7:47 AM
> To: amd-gfx@lists.freedesktop.org; Deucher, Alexander; Koenig, Christian
> Cc: Huang, Ray
> Subject: [PATCH 1/2] drm/amdgpu: cleanup unused iterator members for
> sdma v3
>
> Signed-off-by: Huang Rui <ray.huang@amd.com>
Series is:
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
> ---
> drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c
> b/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c
> index c5719a1..373ae70 100644
> --- a/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c
> @@ -987,7 +987,7 @@ static void sdma_v3_0_vm_write_pte(struct
> amdgpu_ib *ib, uint64_t pe,
> ib->ptr[ib->length_dw++] = lower_32_bits(pe);
> ib->ptr[ib->length_dw++] = upper_32_bits(pe);
> ib->ptr[ib->length_dw++] = ndw;
> - for (; ndw > 0; ndw -= 2, --count, pe += 8) {
> + for (; ndw > 0; ndw -= 2) {
> ib->ptr[ib->length_dw++] = lower_32_bits(value);
> ib->ptr[ib->length_dw++] = upper_32_bits(value);
> value += incr;
> --
> 2.7.4
>
> _______________________________________________
> 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
* [PATCH RFC 3/2] ARM: improve arch_irq_work_has_interrupt()
From: Russell King - ARM Linux @ 2016-11-14 15:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1c6GpW-0008DO-BD@rmk-PC.armlinux.org.uk>
Following on from the previous patch, I think this makes more sense to
determine whether we can support IRQ work interrupts.
Whether we can support them or not depends on two things:
(a) whether the kernel has support for receiving IPIs
(b) whether it's possible to send an IPI to CPUs including the raising CPU.
(a) is a function of how the kernel is built - and in the case of ARM, it
depends whether the kernel is built with SMP enabled or not.
(b) is a property of the interrupt controller.
It hasn't ever been a function of the CPU or architecture.
Commit 059e232089e4 ("irqchip/gic: Allow self-SGIs for SMP on UP
configurations") changes the GIC IPI code such that we can raise
SGIs on uniprocessor systems running on a SMP kernel, which means
we can support IRQ work interrupts here as well.
So, we shouldn't be using cpu_smp() (or its previous is_smp() here
at all. Use a flag to indicate whether we can IPI and use that to
indicate whether we support irq work interrupts.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
arch/arm/include/asm/irq_work.h | 11 +++++++++--
arch/arm/kernel/irq.c | 0
arch/arm/kernel/smp.c | 3 +++
drivers/irqchip/irq-gic.c | 17 +++++++++++++----
4 files changed, 25 insertions(+), 6 deletions(-)
diff --git a/arch/arm/include/asm/irq_work.h b/arch/arm/include/asm/irq_work.h
index 2dc8d7995b48..d7262a3c2f2e 100644
--- a/arch/arm/include/asm/irq_work.h
+++ b/arch/arm/include/asm/irq_work.h
@@ -1,11 +1,18 @@
#ifndef __ASM_ARM_IRQ_WORK_H
#define __ASM_ARM_IRQ_WORK_H
-#include <asm/smp_plat.h>
+extern bool irq_controller_can_ipi;
+#define irq_controller_can_ipi irq_controller_can_ipi
static inline bool arch_irq_work_has_interrupt(void)
{
- return cpu_smp();
+#ifdef CONFIG_SMP
+ /* This depends on the IRQ controller */
+ return irq_controller_can_ipi;
+#else
+ /* The kernel is not built to support IPIs */
+ return false;
+#endif
}
#endif /* _ASM_ARM_IRQ_WORK_H */
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index 7dd14e8395e6..1fa9412cc4aa 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -473,6 +473,9 @@ void __init set_smp_cross_call(void (*fn)(const struct cpumask *, unsigned int))
__smp_cross_call = fn;
}
+/* This indicates whether the IRQ controller can IPI (including self-IPI) */
+bool irq_controller_can_ipi;
+
static const char *ipi_types[NR_IPI] __tracepoint_string = {
#define S(x,s) [x] = s
S(IPI_WAKEUP, "CPU wakeup interrupts"),
diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index d6c404b3584d..abe8d5807c0f 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -1187,9 +1187,6 @@ static int __init __gic_init_bases(struct gic_chip_data *gic,
*/
for (i = 0; i < NR_GIC_CPU_IF; i++)
gic_cpu_map[i] = 0xff;
-#ifdef CONFIG_SMP
- set_smp_cross_call(gic_raise_softirq);
-#endif
cpuhp_setup_state_nocalls(CPUHP_AP_IRQ_GIC_STARTING,
"AP_IRQ_GIC_STARTING",
gic_starting_cpu, NULL);
@@ -1207,8 +1204,20 @@ static int __init __gic_init_bases(struct gic_chip_data *gic,
}
ret = gic_init_bases(gic, irq_start, handle);
- if (ret)
+ if (ret) {
kfree(name);
+ return ret;
+ }
+
+ if (gic == &gic_data[0]) {
+#ifdef CONFIG_SMP
+ set_smp_cross_call(gic_raise_softirq);
+#ifdef irq_controller_can_ipi
+ if (nr_cpu_ids == 1 || hweight8(gic_cpu_map[0]) == 1)
+ irq_controller_can_ipi = true;
+#endif
+#endif
+ }
return ret;
}
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently@9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply related
* Re: Tracing sched_switch events for client application when process is switched back in
From: Arnaldo Carvalho de Melo @ 2016-11-14 15:36 UTC (permalink / raw)
To: Milian Wolff; +Cc: linux-perf-users
In-Reply-To: <9863268.pt3viFMpJL@milian-kdab2>
Em Mon, Nov 14, 2016 at 03:10:26PM +0100, Milian Wolff escreveu:
> On Monday, October 10, 2016 9:36:55 PM CET Arnaldo Carvalho de Melo wrote:
> > Em Thu, Oct 06, 2016 at 06:38:28PM +0200, Milian Wolff escreveu:
> > > only find 7, whereas tracing sched_switch finds all 100 that actually take
> > > place?
> Hey there,
> long delay but I looked at this again today.
> > This is looking only for the sched switches for the monitored workload,
> > which in this case is 'sleep 1', this wasn't a system wide session.
> > add -a and you'll get those other switches, if I got what you described.
> I've used the sources of the simple C application I showed in the first email
> of this thread (still quoted above). Then I try:
> perf record --switch-events -a ./a.out
> And indeed, I get all switch events. But I now also profile all applications
> on the machine, which is not what I want. I want to combine the following
So you remove that '-a' from that command line and gets just the context
switches for that ./a.out app, no?
Lets see:
[root@jouet ~]# perf record --switch-events sleep 1
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.020 MB perf.data (7 samples) ]
[root@jouet ~]#
[root@jouet ~]# perf script --show-switch-events
perf 29395 176148.426824: 1 cycles:ppp: ffffffffae1ad256 perf_event_exec+0x146 (/usr/lib/debug/lib/modules/4.8.6-201.fc24.x86_64/vmlinux
perf 29395 176148.426827: 1 cycles:ppp: ffffffffae00ca1b intel_pmu_handle_irq+0x21b (/usr/lib/debug/lib/modules/4.8.6-201.fc24.x86_64/vm
perf 29395 176148.426829: 10 cycles:ppp: ffffffffae02fd93 native_sched_clock+0x33 (/usr/lib/debug/lib/modules/4.8.6-201.fc24.x86_64/vmlin
perf 29395 176148.426830: 221 cycles:ppp: ffffffffae02fd93 native_sched_clock+0x33 (/usr/lib/debug/lib/modules/4.8.6-201.fc24.x86_64/vmlin
perf 29395 176148.426831: 5213 cycles:ppp: ffffffffae02fe79 sched_clock+0x9 (/usr/lib/debug/lib/modules/4.8.6-201.fc24.x86_64/vmlinux)
sleep 29395 176148.426834: 120344 cycles:ppp: ffffffffae36b0cf selinux_inode_permission+0x11f (/usr/lib/debug/lib/modules/4.8.6-201.fc24.x86_6
sleep 29395 176148.426873: 1717973 cycles:ppp: ffffffffae259e3b free_pipe_info+0x4b (/usr/lib/debug/lib/modules/4.8.6-201.fc24.x86_64/vmlinux)
sleep 29395 176148.427182: PERF_RECORD_SWITCH OUT
sleep 29395 176149.427366: PERF_RECORD_SWITCH IN
And if you use something that generates more switches, say:
[root@jouet ~]# perf record --switch-events ping -c 5 localhost
PING localhost.localdomain (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=1 ttl=64 time=0.043 ms
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=2 ttl=64 time=0.040 ms
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=3 ttl=64 time=0.038 ms
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=4 ttl=64 time=0.038 ms
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=5 ttl=64 time=0.036 ms
--- localhost.localdomain ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4077ms
rtt min/avg/max/mdev = 0.036/0.039/0.043/0.002 ms
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.021 MB perf.data (9 samples) ]
[root@jouet ~]# perf script --show-switch-events
perf 29429 176239.731333: 1 cycles:ppp: ffffffffae1ad250 perf_event_exec+0x140 (/usr/lib/debug/lib/modules/4.8.6-201.fc24.x86_64/vmlinux
perf 29429 176239.731336: 1 cycles:ppp: ffffffffae00ca1b intel_pmu_handle_irq+0x21b (/usr/lib/debug/lib/modules/4.8.6-201.fc24.x86_64/vm
perf 29429 176239.731338: 9 cycles:ppp: ffffffffae02fd93 native_sched_clock+0x33 (/usr/lib/debug/lib/modules/4.8.6-201.fc24.x86_64/vmlin
perf 29429 176239.731339: 198 cycles:ppp: ffffffffae02fd93 native_sched_clock+0x33 (/usr/lib/debug/lib/modules/4.8.6-201.fc24.x86_64/vmlin
perf 29429 176239.731340: 4667 cycles:ppp: ffffffffae02fe7c sched_clock+0xc (/usr/lib/debug/lib/modules/4.8.6-201.fc24.x86_64/vmlinux)
ping 29429 176239.731343: 108407 cycles:ppp: ffffffffae258d09 setup_new_exec+0x109 (/usr/lib/debug/lib/modules/4.8.6-201.fc24.x86_64/vmlinux)
ping 29429 176239.731378: 1645300 cycles:ppp: ffffffffae240c29 mem_cgroup_try_charge+0x19 (/usr/lib/debug/lib/modules/4.8.6-201.fc24.x86_64/vm
ping 29429 176239.731951: 2594316 cycles:ppp: ffffffffae0e46fc __wake_up_bit+0x1c (/usr/lib/debug/lib/modules/4.8.6-201.fc24.x86_64/vmlinux)
ping 29429 176239.732833: 2411373 cycles:ppp: ffffffffae756ec0 icmpv4_xrlim_allow.isra.17+0x60 (/usr/lib/debug/lib/modules/4.8.6-201.fc24.x86_
ping 29429 176239.732872: PERF_RECORD_SWITCH OUT
ping 29429 176240.738063: PERF_RECORD_SWITCH IN
ping 29429 176240.738139: PERF_RECORD_SWITCH OUT
ping 29429 176241.762048: PERF_RECORD_SWITCH IN
ping 29429 176241.762119: PERF_RECORD_SWITCH OUT
ping 29429 176242.786143: PERF_RECORD_SWITCH IN
ping 29429 176242.786221: PERF_RECORD_SWITCH OUT
ping 29429 176243.810099: PERF_RECORD_SWITCH IN
ping 29429 176243.810182: PERF_RECORD_SWITCH OUT
ping 29429 176243.810190: PERF_RECORD_SWITCH IN
5 out, 5 in, in a lightly loaded machine, plenty of CPUs, looks about right, no?
But...
> features:
>
> - sample CPU events for a given application with backtraces
> perf record --call-graph dwarf ./foo
> - record switch-out events with backtraces (`-e sched:sched_switch/fp=dwarf/`)
> - somehow record the switch-in events, which are associated with a different
> process and thus currently discarded
You want the backtraces with that, and since this is a meta-event... Humm, for
the switch in would the above be sufficient? What value would be in knowing the
backtrace in that case?
So something like would do? Try not looking at the "PERF_RECORD_SWITCH OUT"
lines, they are generated by the kernel _after_ the corresponding
sched:sched_switch is registered:
[root@jouet ~]# perf record --call-graph=dwarf --switch-events -e sched:sched_switch ping -c 5 localhost
PING localhost.localdomain (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=1 ttl=64 time=0.043 ms
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=2 ttl=64 time=0.039 ms
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=3 ttl=64 time=0.043 ms
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=4 ttl=64 time=0.041 ms
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=5 ttl=64 time=0.039 ms
--- localhost.localdomain ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4074ms
rtt min/avg/max/mdev = 0.039/0.041/0.043/0.002 ms
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.069 MB perf.data (5 samples) ]
[root@jouet ~]# ^C
[root@jouet ~]# perf script --show-switch-events
ping 29565 [001] 176667.912276: sched:sched_switch: ping:29565 [120] S ==> swapper/1:0 [120]
9fd994 __schedule+0xa4200354 (/usr/lib/debug/lib/modules/4.8.6-201.fc24.x86_64/vmlinux)
9fdde5 schedule+0xa4200035 (/usr/lib/debug/lib/modules/4.8.6-201.fc24.x86_64/vmlinux)
a01259 schedule_timeout+0xa4200219 (/usr/lib/debug/lib/modules/4.8.6-201.fc24.x86_64/vmlinux)
8cb431 __skb_wait_for_more_packets+0xa4200111 (/usr/lib/debug/lib/modules/4.8.6-201.fc24.x86_64/vmlinux)
8cb796 __skb_recv_datagram+0xa4200066 (/usr/lib/debug/lib/modules/4.8.6-201.fc24.x86_64/vmlinux)
8cb82f skb_recv_datagram+0xa420003f (/usr/lib/debug/lib/modules/4.8.6-201.fc24.x86_64/vmlinux)
94d197 raw_recvmsg+0xa4200097 (/usr/lib/debug/lib/modules/4.8.6-201.fc24.x86_64/vmlinux)
95daee inet_recvmsg+0xa420007e (/usr/lib/debug/lib/modules/4.8.6-201.fc24.x86_64/vmlinux)
8bb61d sock_recvmsg+0xa420003d (/usr/lib/debug/lib/modules/4.8.6-201.fc24.x86_64/vmlinux)
8bc667 ___sys_recvmsg+0xa42000d7 (/usr/lib/debug/lib/modules/4.8.6-201.fc24.x86_64/vmlinux)
8bd191 __sys_recvmsg+0xa4200051 (/usr/lib/debug/lib/modules/4.8.6-201.fc24.x86_64/vmlinux)
8bd1e2 sys_recvmsg+0xa4200012 (/usr/lib/debug/lib/modules/4.8.6-201.fc24.x86_64/vmlinux)
a02572 entry_SYSCALL_64_fastpath+0xa420001a (/usr/lib/debug/lib/modules/4.8.6-201.fc24.x86_64/vmlinux)
104050 __GI___libc_recvmsg+0xffff0206e8e70010 (/usr/lib64/libc-2.23.so)
7b5a _init+0xffff5455e66f3ab2 (/usr/bin/ping)
3b34 _init+0xffff5455e66efa8c (/usr/bin/ping)
2d9f _init+0xffff5455e66eecf7 (/usr/bin/ping)
20731 __libc_start_main+0xffff0206e8e700f1 (/usr/lib64/libc-2.23.so)
30a9 _init+0xffff5455e66ef001 (/usr/bin/ping)
ping 29565 [001] 176667.912281: PERF_RECORD_SWITCH OUT
ping 29565 [001] 176668.915107: PERF_RECORD_SWITCH IN
ping 29565 [001] 176668.915114: sched:sched_switch: ping:29565 [120] R ==> kworker/1:179:28142 [120]
9fd994 __schedule+0xa4200354 (/usr/lib/debug/lib/modules/4.8.6-201.fc24.x86_64/vmlinux)
9fdde5 schedule+0xa4200035 (/usr/lib/debug/lib/modules/4.8.6-201.fc24.x86_64/vmlinux)
203282 exit_to_usermode_loop+0xa4200072 (/usr/lib/debug/lib/modules/4.8.6-201.fc24.x86_64/vmlinux)
203be1 syscall_return_slowpath+0xa42000a1 (/usr/lib/debug/lib/modules/4.8.6-201.fc24.x86_64/vmlinux)
a025fa entry_SYSCALL_64_fastpath+0xa42000a2 (/usr/lib/debug/lib/modules/4.8.6-201.fc24.x86_64/vmlinux)
104050 __GI___libc_recvmsg+0xffff0206e8e70010 (/usr/lib64/libc-2.23.so)
7b5a _init+0xffff5455e66f3ab2 (/usr/bin/ping)
3b34 _init+0xffff5455e66efa8c (/usr/bin/ping)
2d9f _init+0xffff5455e66eecf7 (/usr/bin/ping)
20731 __libc_start_main+0xffff0206e8e700f1 (/usr/lib64/libc-2.23.so)
30a9 _init+0xffff5455e66ef001 (/usr/bin/ping)
ping 29565 [001] 176668.915121: PERF_RECORD_SWITCH OUT
ping 29565 [001] 176668.915126: PERF_RECORD_SWITCH IN
ping 29565 [001] 176668.915197: sched:sched_switch: ping:29565 [120] S ==> swapper/1:0 [120]
9fd994 __schedule+0xa4200354 (/usr/lib/debug/lib/modules/4.8.6-201.fc24.x86_64/vmlinux)
9fdde5 schedule+0xa4200035 (/usr/lib/debug/lib/modules/4.8.6-201.fc24.x86_64/vmlinux)
[root@jouet ~]#
Just to check that the backtrace for ping is ok, I did a 'dnf debuginfo-install
iputils', looks sensible:
ping 29619 [001] 176793.486584: sched:sched_switch: ping:29619 [120] S ==> swapper/1:0 [120]
9fd994 __schedule+0xa4200354 (/usr/lib/debug/lib/modules/4.8.6-201.fc24.x86_64/vmlinux)
9fdde5 schedule+0xa4200035 (/usr/lib/debug/lib/modules/4.8.6-201.fc24.x86_64/vmlinux)
a01259 schedule_timeout+0xa4200219 (/usr/lib/debug/lib/modules/4.8.6-201.fc24.x86_64/vmlinux)
8cb431 __skb_wait_for_more_packets+0xa4200111 (/usr/lib/debug/lib/modules/4.8.6-201.fc24.x86_64/vmlinux)
8cb796 __skb_recv_datagram+0xa4200066 (/usr/lib/debug/lib/modules/4.8.6-201.fc24.x86_64/vmlinux)
8cb82f skb_recv_datagram+0xa420003f (/usr/lib/debug/lib/modules/4.8.6-201.fc24.x86_64/vmlinux)
94d197 raw_recvmsg+0xa4200097 (/usr/lib/debug/lib/modules/4.8.6-201.fc24.x86_64/vmlinux)
95daee inet_recvmsg+0xa420007e (/usr/lib/debug/lib/modules/4.8.6-201.fc24.x86_64/vmlinux)
8bb61d sock_recvmsg+0xa420003d (/usr/lib/debug/lib/modules/4.8.6-201.fc24.x86_64/vmlinux)
8bc667 ___sys_recvmsg+0xa42000d7 (/usr/lib/debug/lib/modules/4.8.6-201.fc24.x86_64/vmlinux)
8bd191 __sys_recvmsg+0xa4200051 (/usr/lib/debug/lib/modules/4.8.6-201.fc24.x86_64/vmlinux)
8bd1e2 sys_recvmsg+0xa4200012 (/usr/lib/debug/lib/modules/4.8.6-201.fc24.x86_64/vmlinux)
a02572 entry_SYSCALL_64_fastpath+0xa420001a (/usr/lib/debug/lib/modules/4.8.6-201.fc24.x86_64/vmlinux)
104050 __GI___libc_recvmsg+0xffff020805e62010 (/usr/lib64/libc-2.23.so)
7b5a main_loop+0xffff550a5a4dc1fa (/usr/bin/ping)
3b34 ping4_run+0xffff550a5a4dc534 (/usr/bin/ping)
2d9f main+0xffff550a5a4dc98f (/usr/bin/ping)
20731 __libc_start_main+0xffff020805e620f1 (/usr/lib64/libc-2.23.so)
30a9 _start+0xffff550a5a4dc029 (/usr/bin/ping)
> Any advise on where to look for the filtering? Not discarding the sched_switch
> of a different process based on matching next_tid can't be that hard, or is
> it?
>
> Cheers
>
> --
> Milian Wolff | milian.wolff@kdab.com | Software Engineer
> KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
> Tel: +49-30-521325470
> KDAB - The Qt Experts
^ permalink raw reply
* Re: [PATCH v2] ARM: at91/dt: add dts file for sama5d36ek CMP board
From: Nicolas Ferre @ 2016-11-14 15:36 UTC (permalink / raw)
To: Wenyou Yang, Alexandre Belloni, Russell King, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala
Cc: linux-kernel, Wenyou Yang, devicetree, linux-arm-kernel
In-Reply-To: <1478055958-8463-1-git-send-email-wenyou.yang@atmel.com>
Le 02/11/2016 à 04:05, Wenyou Yang a écrit :
> The sama5d36ek CMP board is the variant of sama5d3xek board.
> It is equipped with the low-power DDR2 SDRAM, PMIC ACT8865 and
> some power rail. Its main purpose is used to measure the power
> consumption.
> The difference of the sama5d36ek CMP dts from sama5d36ek dts
> is listed as below.
> 1. The USB host nodes are removed, that is, the USB host is disabled.
> 2. The gpio_keys node is added to wake up from the sleep.
> 3. The LCD isn't supported due to the pins for LCD are conflicted
> with gpio_keys.
> 4. The adc0 node support the pinctrl sleep state to fix the over
> consumption on VDDANA.
>
> As said in errata, "When the USB host ports are used in high speed
> mode (EHCI), it is not possible to suspend the ports if no device is
> attached on each port. This leads to increased power consumption even
> if the system is in a low power mode." That is why the the USB host
> is disabled.
>
> Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com>
> ---
>
> Changes in v2:
> - Add the pinctrl sleep state for adc0 node to fix the over
> consumption on VDDANA.
> - Improve the commit log.
>
> arch/arm/boot/dts/sama5d36ek_cmp.dts | 51 +++++++
> arch/arm/boot/dts/sama5d3xcm_cmp.dtsi | 166 +++++++++++++++++++++
> arch/arm/boot/dts/sama5d3xmb_cmp.dtsi | 265 ++++++++++++++++++++++++++++++++++
> 3 files changed, 482 insertions(+)
> create mode 100644 arch/arm/boot/dts/sama5d36ek_cmp.dts
> create mode 100644 arch/arm/boot/dts/sama5d3xcm_cmp.dtsi
> create mode 100644 arch/arm/boot/dts/sama5d3xmb_cmp.dtsi
>
> diff --git a/arch/arm/boot/dts/sama5d36ek_cmp.dts b/arch/arm/boot/dts/sama5d36ek_cmp.dts
> new file mode 100644
> index 0000000..fd6bcd6
> --- /dev/null
> +++ b/arch/arm/boot/dts/sama5d36ek_cmp.dts
> @@ -0,0 +1,51 @@
> +/*
> + * sama5d36ek_cmp.dts - Device Tree file for SAMA5D36-EK CMP board
> + *
> + * Copyright (C) 2016 Atmel,
> + *
> + * Licensed under GPLv2 or later.
No, in fact we now use a dual license scheme for DT files. Please have a
look at the recent board that we posted to take the header from them.
> + */
> +/dts-v1/;
> +#include "sama5d36.dtsi"
> +#include "sama5d3xmb_cmp.dtsi"
> +
> +/ {
> + model = "Atmel SAMA5D36-EK";
> + compatible = "atmel,sama5d36ek", "atmel,sama5d3xmb", "atmel,sama5d3xcm", "atmel,sama5d36", "atmel,sama5d3", "atmel,sama5";
I don't think the model name nor the compatible string reflect the
nature of this new "CMP" board.
> +
> + ahb {
> + apb {
> + spi0: spi@f0004000 {
> + status = "okay";
> + };
> +
> + ssc0: ssc@f0008000 {
> + status = "okay";
> + };
> +
> + can0: can@f000c000 {
> + status = "okay";
> + };
> +
> + i2c0: i2c@f0014000 {
> + status = "okay";
> + };
> +
> + i2c1: i2c@f0018000 {
> + status = "okay";
> + };
> +
> + macb0: ethernet@f0028000 {
> + status = "okay";
> + };
> +
> + macb1: ethernet@f802c000 {
> + status = "okay";
> + };
> + };
> + };
> +
> + sound {
> + status = "okay";
> + };
> +};
> diff --git a/arch/arm/boot/dts/sama5d3xcm_cmp.dtsi b/arch/arm/boot/dts/sama5d3xcm_cmp.dtsi
> new file mode 100644
> index 0000000..77638c3
> --- /dev/null
> +++ b/arch/arm/boot/dts/sama5d3xcm_cmp.dtsi
> @@ -0,0 +1,166 @@
> +/*
> + * sama5d3xcm_cmp.dtsi - Device Tree Include file for SAMA5D36 CMP CPU Module
> + *
> + * Copyright (C) 2016 Atmel,
> + *
> + * Licensed under GPLv2 or later.
Ditto.
> + */
> +
> +/ {
> + compatible = "atmel,sama5d3xcm", "atmel,sama5d3", "atmel,sama5";
Ditto.
> +
> + chosen {
> + bootargs = "rootfstype=ubifs ubi.mtd=5 root=ubi0:rootfs";
Remove bootargs.
> + stdout-path = "serial0:115200n8";
> + };
> +
> + memory {
> + reg = <0x20000000 0x20000000>;
> + };
> +
> + clocks {
> + slow_xtal {
> + clock-frequency = <32768>;
> + };
> +
> + main_xtal {
> + clock-frequency = <12000000>;
> + };
> + };
> +
> + ahb {
> + apb {
> + spi0: spi@f0004000 {
> + cs-gpios = <&pioD 13 0>, <0>, <0>, <0>;
> + };
> +
> + macb0: ethernet@f0028000 {
> + phy-mode = "rgmii";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ethernet-phy@1 {
> + reg = <0x1>;
> + interrupt-parent = <&pioB>;
> + interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
> + txen-skew-ps = <800>;
> + txc-skew-ps = <3000>;
> + rxdv-skew-ps = <400>;
> + rxc-skew-ps = <3000>;
> + rxd0-skew-ps = <400>;
> + rxd1-skew-ps = <400>;
> + rxd2-skew-ps = <400>;
> + rxd3-skew-ps = <400>;
> + };
> +
> + ethernet-phy@7 {
> + reg = <0x7>;
> + interrupt-parent = <&pioB>;
> + interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
> + txen-skew-ps = <800>;
> + txc-skew-ps = <3000>;
> + rxdv-skew-ps = <400>;
> + rxc-skew-ps = <3000>;
> + rxd0-skew-ps = <400>;
> + rxd1-skew-ps = <400>;
> + rxd2-skew-ps = <400>;
> + rxd3-skew-ps = <400>;
> + };
> + };
> +
> + i2c1: i2c@f0018000 {
> + pmic: act8865@5b {
> + compatible = "active-semi,act8865";
> + reg = <0x5b>;
> + status = "disabled";
> +
> + regulators {
> + vcc_1v8_reg: DCDC_REG1 {
> + regulator-name = "VCC_1V8";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-always-on;
> + };
> +
> + vcc_1v2_reg: DCDC_REG2 {
> + regulator-name = "VCC_1V2";
> + regulator-min-microvolt = <1100000>;
> + regulator-max-microvolt = <1300000>;
> + regulator-always-on;
> + };
> +
> + vcc_3v3_reg: DCDC_REG3 {
> + regulator-name = "VCC_3V3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-always-on;
> + };
> +
> + vddana_reg: LDO_REG1 {
> + regulator-name = "VDDANA";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-always-on;
> + };
> +
> + vddfuse_reg: LDO_REG2 {
> + regulator-name = "FUSE_2V5";
> + regulator-min-microvolt = <2500000>;
> + regulator-max-microvolt = <2500000>;
> + };
> + };
> + };
> + };
> + };
> +
> + nand0: nand@60000000 {
> + nand-bus-width = <8>;
> + nand-ecc-mode = "hw";
> + atmel,has-pmecc;
> + atmel,pmecc-cap = <4>;
> + atmel,pmecc-sector-size = <512>;
> + nand-on-flash-bbt;
> + status = "okay";
> +
> + at91bootstrap@0 {
> + label = "at91bootstrap";
> + reg = <0x0 0x40000>;
> + };
> +
> + bootloader@40000 {
> + label = "bootloader";
> + reg = <0x40000 0x80000>;
> + };
> +
> + bootloaderenv@c0000 {
> + label = "bootloader env";
> + reg = <0xc0000 0xc0000>;
> + };
> +
> + dtb@180000 {
> + label = "device tree";
> + reg = <0x180000 0x80000>;
> + };
> +
> + kernel@200000 {
> + label = "kernel";
> + reg = <0x200000 0x600000>;
> + };
> +
> + rootfs@800000 {
> + label = "rootfs";
> + reg = <0x800000 0x0f800000>;
> + };
> + };
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + d2 {
> + label = "d2";
> + gpios = <&pioE 25 GPIO_ACTIVE_LOW>; /* PE25, conflicts with A25, RXD2 */
> + linux,default-trigger = "heartbeat";
> + };
> + };
> +};
> diff --git a/arch/arm/boot/dts/sama5d3xmb_cmp.dtsi b/arch/arm/boot/dts/sama5d3xmb_cmp.dtsi
> new file mode 100644
> index 0000000..62c6230
> --- /dev/null
> +++ b/arch/arm/boot/dts/sama5d3xmb_cmp.dtsi
> @@ -0,0 +1,265 @@
> +/*
> + * sama5d3xmb_cmp.dts - Device Tree file for SAMA5D3x CMP mother board
> + *
> + * Copyright (C) 2016 Atmel,
> + *
> + * Licensed under GPLv2 or later.
Ditto.
> + */
> +#include "sama5d3xcm_cmp.dtsi"
> +
> +/ {
> + compatible = "atmel,sama5d3xmb", "atmel,sama5d3xcm", "atmel,sama5d3", "atmel,sama5";
Ditto.
> +
> + ahb {
> + apb {
> + mmc0: mmc@f0000000 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_mmc0_clk_cmd_dat0 &pinctrl_mmc0_dat1_3 &pinctrl_mmc0_cd>;
> + status = "okay";
> + slot@0 {
> + reg = <0>;
> + bus-width = <4>;
> + cd-gpios = <&pioD 17 GPIO_ACTIVE_HIGH>;
> + };
> + };
> +
> + spi0: spi@f0004000 {
> + dmas = <0>, <0>; /* Do not use DMA for spi0 */
> +
> + m25p80@0 {
> + compatible = "atmel,at25df321a";
> + spi-max-frequency = <50000000>;
> + reg = <0>;
> + };
> + };
> +
> + ssc0: ssc@f0008000 {
> + atmel,clk-from-rk-pin;
> + };
> +
> + /*
> + * i2c0 conflicts with ISI:
> + * disable it to allow the use of ISI
> + * can not enable audio when i2c0 disabled
> + */
> + i2c0: i2c@f0014000 {
> + wm8904: wm8904@1a {
> + compatible = "wlf,wm8904";
> + reg = <0x1a>;
> + clocks = <&pck0>;
> + clock-names = "mclk";
> + };
> + };
> +
> + i2c1: i2c@f0018000 {
> + ov2640: camera@0x30 {
> + compatible = "ovti,ov2640";
> + reg = <0x30>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_pck1_as_isi_mck &pinctrl_sensor_power &pinctrl_sensor_reset>;
> + resetb-gpios = <&pioE 24 GPIO_ACTIVE_LOW>;
> + pwdn-gpios = <&pioE 29 GPIO_ACTIVE_HIGH>;
> + /* use pck1 for the master clock of ov2640 */
> + clocks = <&pck1>;
> + clock-names = "xvclk";
> + assigned-clocks = <&pck1>;
> + assigned-clock-rates = <25000000>;
> +
> + port {
> + ov2640_0: endpoint {
> + remote-endpoint = <&isi_0>;
> + bus-width = <8>;
> + };
> + };
> + };
> + };
> +
> + usart1: serial@f0020000 {
> + dmas = <0>, <0>; /* Do not use DMA for usart1 */
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usart1 &pinctrl_usart1_rts_cts>;
> + status = "okay";
> + };
> +
> + isi: isi@f0034000 {
> + port {
> + isi_0: endpoint {
> + remote-endpoint = <&ov2640_0>;
> + bus-width = <8>;
> + vsync-active = <1>;
> + hsync-active = <1>;
> + };
> + };
> + };
> +
> + mmc1: mmc@f8000000 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_mmc1_clk_cmd_dat0 &pinctrl_mmc1_dat1_3 &pinctrl_mmc1_cd>;
> + status = "okay";
> + slot@0 {
> + reg = <0>;
> + bus-width = <4>;
> + cd-gpios = <&pioD 18 GPIO_ACTIVE_HIGH>;
> + };
> + };
> +
> + adc0: adc@f8018000 {
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <
> + &pinctrl_adc0_adtrg
> + &pinctrl_adc0_ad0
> + &pinctrl_adc0_ad1
> + &pinctrl_adc0_ad2
> + &pinctrl_adc0_ad3
> + &pinctrl_adc0_ad4
> + >;
> + pinctrl-1 = <
> + &pinctrl_adc0_adtrg_sleep
> + &pinctrl_adc0_ad0_sleep
> + &pinctrl_adc0_ad1_sleep
> + &pinctrl_adc0_ad2_sleep
> + &pinctrl_adc0_ad3_sleep
> + &pinctrl_adc0_ad4_sleep
> + >;
> + status = "okay";
> + };
> +
> + macb1: ethernet@f802c000 {
> + phy-mode = "rmii";
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> + phy0: ethernet-phy@1 {
> + /*interrupt-parent = <&pioE>;*/
> + /*interrupts = <30 IRQ_TYPE_EDGE_FALLING>;*/
> + reg = <1>;
> + };
> + };
> +
> + pinctrl@fffff200 {
> + adc0 {
> + pinctrl_adc0_adtrg_sleep: adc0_adtrg_1 {
> + atmel,pins =
> + <AT91_PIOD 19 AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(0))>; /* PD19 GPIO output 0 */
> + };
> + pinctrl_adc0_ad0_sleep: adc0_ad0_1 {
> + atmel,pins =
> + <AT91_PIOD 20 AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(0))>; /* PD20 GPIO output 0 */
> + };
> + pinctrl_adc0_ad1_sleep: adc0_ad1_1 {
> + atmel,pins =
> + <AT91_PIOD 21 AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(0))>; /* PD21 GPIO output 0 */
> + };
> + pinctrl_adc0_ad2_sleep: adc0_ad2_1 {
> + atmel,pins =
> + <AT91_PIOD 22 AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(0))>; /* PD22 GPIO output 0 */
> + };
> + pinctrl_adc0_ad3_sleep: adc0_ad3_1 {
> + atmel,pins =
> + <AT91_PIOD 23 AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(0))>; /* PD23 GPIO output 0 */
> + };
> + pinctrl_adc0_ad4_sleep: adc0_ad4_1 {
> + atmel,pins =
> + <AT91_PIOD 24 AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(0))>; /* PD24 GPIO output 0 */
Please remove all these comments. The binding is good enough to
understand easily.
> + };
> + };
> +
> + board {
> + pinctrl_gpio_keys: gpio_keys {
> + atmel,pins =
> + <AT91_PIOE 27 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP>;
> + };
> +
> + pinctrl_mmc0_cd: mmc0_cd {
> + atmel,pins =
> + <AT91_PIOD 17 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP_DEGLITCH>; /* PD17 GPIO with pullup deglitch */
> + };
> +
> + pinctrl_mmc1_cd: mmc1_cd {
> + atmel,pins =
> + <AT91_PIOD 18 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP_DEGLITCH>; /* PD18 GPIO with pullup deglitch */
> + };
> +
> + pinctrl_pck0_as_audio_mck: pck0_as_audio_mck {
> + atmel,pins =
> + <AT91_PIOD 30 AT91_PERIPH_B AT91_PINCTRL_NONE>; /* PD30 periph B */
> + };
> +
> + pinctrl_pck1_as_isi_mck: pck1_as_isi_mck-0 {
> + atmel,pins =
> + <AT91_PIOD 31 AT91_PERIPH_B AT91_PINCTRL_NONE>; /* PD31 periph B ISI_MCK */
> + };
> +
> + pinctrl_sensor_reset: sensor_reset-0 {
> + atmel,pins =
> + <AT91_PIOE 24 AT91_PERIPH_GPIO AT91_PINCTRL_NONE>; /* PE24 gpio */
> + };
> +
> + pinctrl_sensor_power: sensor_power-0 {
> + atmel,pins =
> + <AT91_PIOE 29 AT91_PERIPH_GPIO AT91_PINCTRL_NONE>; /* PE29 gpio */
> + };
> +
> + pinctrl_usba_vbus: usba_vbus {
> + atmel,pins =
> + <AT91_PIOD 29 AT91_PERIPH_GPIO AT91_PINCTRL_DEGLITCH>; /* PD29 GPIO with deglitch */
Here again, all comments are not or great use: remove them.
> + };
> + };
> + };
> +
> + dbgu: serial@ffffee00 {
> + dmas = <0>, <0>; /* Do not use DMA for dbgu */
> + status = "okay";
> + };
> +
> + watchdog@fffffe40 {
> + status = "okay";
> + };
> + };
> +
> + usb0: gadget@00500000 {
> + atmel,vbus-gpio = <&pioD 29 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usba_vbus>;
> + status = "okay";
> + };
> + };
> +
> + sound {
> + compatible = "atmel,asoc-wm8904";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_pck0_as_audio_mck>;
> +
> + atmel,model = "wm8904 @ SAMA5D3EK";
> + atmel,audio-routing =
> + "Headphone Jack", "HPOUTL",
> + "Headphone Jack", "HPOUTR",
> + "IN2L", "Line In Jack",
> + "IN2R", "Line In Jack",
> + "Mic", "MICBIAS",
> + "IN1L", "Mic";
> +
> + atmel,ssc-controller = <&ssc0>;
> + atmel,audio-codec = <&wm8904>;
> +
> + status = "disabled";
> + };
> +
> + /* Conflict with LCD pins */
> + gpio_keys {
> + compatible = "gpio-keys";
> + status = "okay";
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_gpio_keys>;
> +
> + pb_user1 {
> + label = "pb_user1";
> + gpios = <&pioE 27 GPIO_ACTIVE_HIGH>;
> + linux,code = <0x100>;
> + gpio-key,wakeup;
> + };
> + };
> +};
>
--
Nicolas Ferre
^ permalink raw reply
* [PATCH v2] ARM: at91/dt: add dts file for sama5d36ek CMP board
From: Nicolas Ferre @ 2016-11-14 15:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478055958-8463-1-git-send-email-wenyou.yang@atmel.com>
Le 02/11/2016 ? 04:05, Wenyou Yang a ?crit :
> The sama5d36ek CMP board is the variant of sama5d3xek board.
> It is equipped with the low-power DDR2 SDRAM, PMIC ACT8865 and
> some power rail. Its main purpose is used to measure the power
> consumption.
> The difference of the sama5d36ek CMP dts from sama5d36ek dts
> is listed as below.
> 1. The USB host nodes are removed, that is, the USB host is disabled.
> 2. The gpio_keys node is added to wake up from the sleep.
> 3. The LCD isn't supported due to the pins for LCD are conflicted
> with gpio_keys.
> 4. The adc0 node support the pinctrl sleep state to fix the over
> consumption on VDDANA.
>
> As said in errata, "When the USB host ports are used in high speed
> mode (EHCI), it is not possible to suspend the ports if no device is
> attached on each port. This leads to increased power consumption even
> if the system is in a low power mode." That is why the the USB host
> is disabled.
>
> Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com>
> ---
>
> Changes in v2:
> - Add the pinctrl sleep state for adc0 node to fix the over
> consumption on VDDANA.
> - Improve the commit log.
>
> arch/arm/boot/dts/sama5d36ek_cmp.dts | 51 +++++++
> arch/arm/boot/dts/sama5d3xcm_cmp.dtsi | 166 +++++++++++++++++++++
> arch/arm/boot/dts/sama5d3xmb_cmp.dtsi | 265 ++++++++++++++++++++++++++++++++++
> 3 files changed, 482 insertions(+)
> create mode 100644 arch/arm/boot/dts/sama5d36ek_cmp.dts
> create mode 100644 arch/arm/boot/dts/sama5d3xcm_cmp.dtsi
> create mode 100644 arch/arm/boot/dts/sama5d3xmb_cmp.dtsi
>
> diff --git a/arch/arm/boot/dts/sama5d36ek_cmp.dts b/arch/arm/boot/dts/sama5d36ek_cmp.dts
> new file mode 100644
> index 0000000..fd6bcd6
> --- /dev/null
> +++ b/arch/arm/boot/dts/sama5d36ek_cmp.dts
> @@ -0,0 +1,51 @@
> +/*
> + * sama5d36ek_cmp.dts - Device Tree file for SAMA5D36-EK CMP board
> + *
> + * Copyright (C) 2016 Atmel,
> + *
> + * Licensed under GPLv2 or later.
No, in fact we now use a dual license scheme for DT files. Please have a
look at the recent board that we posted to take the header from them.
> + */
> +/dts-v1/;
> +#include "sama5d36.dtsi"
> +#include "sama5d3xmb_cmp.dtsi"
> +
> +/ {
> + model = "Atmel SAMA5D36-EK";
> + compatible = "atmel,sama5d36ek", "atmel,sama5d3xmb", "atmel,sama5d3xcm", "atmel,sama5d36", "atmel,sama5d3", "atmel,sama5";
I don't think the model name nor the compatible string reflect the
nature of this new "CMP" board.
> +
> + ahb {
> + apb {
> + spi0: spi at f0004000 {
> + status = "okay";
> + };
> +
> + ssc0: ssc at f0008000 {
> + status = "okay";
> + };
> +
> + can0: can at f000c000 {
> + status = "okay";
> + };
> +
> + i2c0: i2c at f0014000 {
> + status = "okay";
> + };
> +
> + i2c1: i2c at f0018000 {
> + status = "okay";
> + };
> +
> + macb0: ethernet at f0028000 {
> + status = "okay";
> + };
> +
> + macb1: ethernet at f802c000 {
> + status = "okay";
> + };
> + };
> + };
> +
> + sound {
> + status = "okay";
> + };
> +};
> diff --git a/arch/arm/boot/dts/sama5d3xcm_cmp.dtsi b/arch/arm/boot/dts/sama5d3xcm_cmp.dtsi
> new file mode 100644
> index 0000000..77638c3
> --- /dev/null
> +++ b/arch/arm/boot/dts/sama5d3xcm_cmp.dtsi
> @@ -0,0 +1,166 @@
> +/*
> + * sama5d3xcm_cmp.dtsi - Device Tree Include file for SAMA5D36 CMP CPU Module
> + *
> + * Copyright (C) 2016 Atmel,
> + *
> + * Licensed under GPLv2 or later.
Ditto.
> + */
> +
> +/ {
> + compatible = "atmel,sama5d3xcm", "atmel,sama5d3", "atmel,sama5";
Ditto.
> +
> + chosen {
> + bootargs = "rootfstype=ubifs ubi.mtd=5 root=ubi0:rootfs";
Remove bootargs.
> + stdout-path = "serial0:115200n8";
> + };
> +
> + memory {
> + reg = <0x20000000 0x20000000>;
> + };
> +
> + clocks {
> + slow_xtal {
> + clock-frequency = <32768>;
> + };
> +
> + main_xtal {
> + clock-frequency = <12000000>;
> + };
> + };
> +
> + ahb {
> + apb {
> + spi0: spi at f0004000 {
> + cs-gpios = <&pioD 13 0>, <0>, <0>, <0>;
> + };
> +
> + macb0: ethernet at f0028000 {
> + phy-mode = "rgmii";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ethernet-phy at 1 {
> + reg = <0x1>;
> + interrupt-parent = <&pioB>;
> + interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
> + txen-skew-ps = <800>;
> + txc-skew-ps = <3000>;
> + rxdv-skew-ps = <400>;
> + rxc-skew-ps = <3000>;
> + rxd0-skew-ps = <400>;
> + rxd1-skew-ps = <400>;
> + rxd2-skew-ps = <400>;
> + rxd3-skew-ps = <400>;
> + };
> +
> + ethernet-phy at 7 {
> + reg = <0x7>;
> + interrupt-parent = <&pioB>;
> + interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
> + txen-skew-ps = <800>;
> + txc-skew-ps = <3000>;
> + rxdv-skew-ps = <400>;
> + rxc-skew-ps = <3000>;
> + rxd0-skew-ps = <400>;
> + rxd1-skew-ps = <400>;
> + rxd2-skew-ps = <400>;
> + rxd3-skew-ps = <400>;
> + };
> + };
> +
> + i2c1: i2c at f0018000 {
> + pmic: act8865 at 5b {
> + compatible = "active-semi,act8865";
> + reg = <0x5b>;
> + status = "disabled";
> +
> + regulators {
> + vcc_1v8_reg: DCDC_REG1 {
> + regulator-name = "VCC_1V8";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-always-on;
> + };
> +
> + vcc_1v2_reg: DCDC_REG2 {
> + regulator-name = "VCC_1V2";
> + regulator-min-microvolt = <1100000>;
> + regulator-max-microvolt = <1300000>;
> + regulator-always-on;
> + };
> +
> + vcc_3v3_reg: DCDC_REG3 {
> + regulator-name = "VCC_3V3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-always-on;
> + };
> +
> + vddana_reg: LDO_REG1 {
> + regulator-name = "VDDANA";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-always-on;
> + };
> +
> + vddfuse_reg: LDO_REG2 {
> + regulator-name = "FUSE_2V5";
> + regulator-min-microvolt = <2500000>;
> + regulator-max-microvolt = <2500000>;
> + };
> + };
> + };
> + };
> + };
> +
> + nand0: nand at 60000000 {
> + nand-bus-width = <8>;
> + nand-ecc-mode = "hw";
> + atmel,has-pmecc;
> + atmel,pmecc-cap = <4>;
> + atmel,pmecc-sector-size = <512>;
> + nand-on-flash-bbt;
> + status = "okay";
> +
> + at91bootstrap at 0 {
> + label = "at91bootstrap";
> + reg = <0x0 0x40000>;
> + };
> +
> + bootloader at 40000 {
> + label = "bootloader";
> + reg = <0x40000 0x80000>;
> + };
> +
> + bootloaderenv at c0000 {
> + label = "bootloader env";
> + reg = <0xc0000 0xc0000>;
> + };
> +
> + dtb at 180000 {
> + label = "device tree";
> + reg = <0x180000 0x80000>;
> + };
> +
> + kernel at 200000 {
> + label = "kernel";
> + reg = <0x200000 0x600000>;
> + };
> +
> + rootfs at 800000 {
> + label = "rootfs";
> + reg = <0x800000 0x0f800000>;
> + };
> + };
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + d2 {
> + label = "d2";
> + gpios = <&pioE 25 GPIO_ACTIVE_LOW>; /* PE25, conflicts with A25, RXD2 */
> + linux,default-trigger = "heartbeat";
> + };
> + };
> +};
> diff --git a/arch/arm/boot/dts/sama5d3xmb_cmp.dtsi b/arch/arm/boot/dts/sama5d3xmb_cmp.dtsi
> new file mode 100644
> index 0000000..62c6230
> --- /dev/null
> +++ b/arch/arm/boot/dts/sama5d3xmb_cmp.dtsi
> @@ -0,0 +1,265 @@
> +/*
> + * sama5d3xmb_cmp.dts - Device Tree file for SAMA5D3x CMP mother board
> + *
> + * Copyright (C) 2016 Atmel,
> + *
> + * Licensed under GPLv2 or later.
Ditto.
> + */
> +#include "sama5d3xcm_cmp.dtsi"
> +
> +/ {
> + compatible = "atmel,sama5d3xmb", "atmel,sama5d3xcm", "atmel,sama5d3", "atmel,sama5";
Ditto.
> +
> + ahb {
> + apb {
> + mmc0: mmc at f0000000 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_mmc0_clk_cmd_dat0 &pinctrl_mmc0_dat1_3 &pinctrl_mmc0_cd>;
> + status = "okay";
> + slot at 0 {
> + reg = <0>;
> + bus-width = <4>;
> + cd-gpios = <&pioD 17 GPIO_ACTIVE_HIGH>;
> + };
> + };
> +
> + spi0: spi at f0004000 {
> + dmas = <0>, <0>; /* Do not use DMA for spi0 */
> +
> + m25p80 at 0 {
> + compatible = "atmel,at25df321a";
> + spi-max-frequency = <50000000>;
> + reg = <0>;
> + };
> + };
> +
> + ssc0: ssc at f0008000 {
> + atmel,clk-from-rk-pin;
> + };
> +
> + /*
> + * i2c0 conflicts with ISI:
> + * disable it to allow the use of ISI
> + * can not enable audio when i2c0 disabled
> + */
> + i2c0: i2c at f0014000 {
> + wm8904: wm8904 at 1a {
> + compatible = "wlf,wm8904";
> + reg = <0x1a>;
> + clocks = <&pck0>;
> + clock-names = "mclk";
> + };
> + };
> +
> + i2c1: i2c at f0018000 {
> + ov2640: camera at 0x30 {
> + compatible = "ovti,ov2640";
> + reg = <0x30>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_pck1_as_isi_mck &pinctrl_sensor_power &pinctrl_sensor_reset>;
> + resetb-gpios = <&pioE 24 GPIO_ACTIVE_LOW>;
> + pwdn-gpios = <&pioE 29 GPIO_ACTIVE_HIGH>;
> + /* use pck1 for the master clock of ov2640 */
> + clocks = <&pck1>;
> + clock-names = "xvclk";
> + assigned-clocks = <&pck1>;
> + assigned-clock-rates = <25000000>;
> +
> + port {
> + ov2640_0: endpoint {
> + remote-endpoint = <&isi_0>;
> + bus-width = <8>;
> + };
> + };
> + };
> + };
> +
> + usart1: serial at f0020000 {
> + dmas = <0>, <0>; /* Do not use DMA for usart1 */
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usart1 &pinctrl_usart1_rts_cts>;
> + status = "okay";
> + };
> +
> + isi: isi at f0034000 {
> + port {
> + isi_0: endpoint {
> + remote-endpoint = <&ov2640_0>;
> + bus-width = <8>;
> + vsync-active = <1>;
> + hsync-active = <1>;
> + };
> + };
> + };
> +
> + mmc1: mmc at f8000000 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_mmc1_clk_cmd_dat0 &pinctrl_mmc1_dat1_3 &pinctrl_mmc1_cd>;
> + status = "okay";
> + slot at 0 {
> + reg = <0>;
> + bus-width = <4>;
> + cd-gpios = <&pioD 18 GPIO_ACTIVE_HIGH>;
> + };
> + };
> +
> + adc0: adc at f8018000 {
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <
> + &pinctrl_adc0_adtrg
> + &pinctrl_adc0_ad0
> + &pinctrl_adc0_ad1
> + &pinctrl_adc0_ad2
> + &pinctrl_adc0_ad3
> + &pinctrl_adc0_ad4
> + >;
> + pinctrl-1 = <
> + &pinctrl_adc0_adtrg_sleep
> + &pinctrl_adc0_ad0_sleep
> + &pinctrl_adc0_ad1_sleep
> + &pinctrl_adc0_ad2_sleep
> + &pinctrl_adc0_ad3_sleep
> + &pinctrl_adc0_ad4_sleep
> + >;
> + status = "okay";
> + };
> +
> + macb1: ethernet at f802c000 {
> + phy-mode = "rmii";
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> + phy0: ethernet-phy at 1 {
> + /*interrupt-parent = <&pioE>;*/
> + /*interrupts = <30 IRQ_TYPE_EDGE_FALLING>;*/
> + reg = <1>;
> + };
> + };
> +
> + pinctrl at fffff200 {
> + adc0 {
> + pinctrl_adc0_adtrg_sleep: adc0_adtrg_1 {
> + atmel,pins =
> + <AT91_PIOD 19 AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(0))>; /* PD19 GPIO output 0 */
> + };
> + pinctrl_adc0_ad0_sleep: adc0_ad0_1 {
> + atmel,pins =
> + <AT91_PIOD 20 AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(0))>; /* PD20 GPIO output 0 */
> + };
> + pinctrl_adc0_ad1_sleep: adc0_ad1_1 {
> + atmel,pins =
> + <AT91_PIOD 21 AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(0))>; /* PD21 GPIO output 0 */
> + };
> + pinctrl_adc0_ad2_sleep: adc0_ad2_1 {
> + atmel,pins =
> + <AT91_PIOD 22 AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(0))>; /* PD22 GPIO output 0 */
> + };
> + pinctrl_adc0_ad3_sleep: adc0_ad3_1 {
> + atmel,pins =
> + <AT91_PIOD 23 AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(0))>; /* PD23 GPIO output 0 */
> + };
> + pinctrl_adc0_ad4_sleep: adc0_ad4_1 {
> + atmel,pins =
> + <AT91_PIOD 24 AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(0))>; /* PD24 GPIO output 0 */
Please remove all these comments. The binding is good enough to
understand easily.
> + };
> + };
> +
> + board {
> + pinctrl_gpio_keys: gpio_keys {
> + atmel,pins =
> + <AT91_PIOE 27 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP>;
> + };
> +
> + pinctrl_mmc0_cd: mmc0_cd {
> + atmel,pins =
> + <AT91_PIOD 17 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP_DEGLITCH>; /* PD17 GPIO with pullup deglitch */
> + };
> +
> + pinctrl_mmc1_cd: mmc1_cd {
> + atmel,pins =
> + <AT91_PIOD 18 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP_DEGLITCH>; /* PD18 GPIO with pullup deglitch */
> + };
> +
> + pinctrl_pck0_as_audio_mck: pck0_as_audio_mck {
> + atmel,pins =
> + <AT91_PIOD 30 AT91_PERIPH_B AT91_PINCTRL_NONE>; /* PD30 periph B */
> + };
> +
> + pinctrl_pck1_as_isi_mck: pck1_as_isi_mck-0 {
> + atmel,pins =
> + <AT91_PIOD 31 AT91_PERIPH_B AT91_PINCTRL_NONE>; /* PD31 periph B ISI_MCK */
> + };
> +
> + pinctrl_sensor_reset: sensor_reset-0 {
> + atmel,pins =
> + <AT91_PIOE 24 AT91_PERIPH_GPIO AT91_PINCTRL_NONE>; /* PE24 gpio */
> + };
> +
> + pinctrl_sensor_power: sensor_power-0 {
> + atmel,pins =
> + <AT91_PIOE 29 AT91_PERIPH_GPIO AT91_PINCTRL_NONE>; /* PE29 gpio */
> + };
> +
> + pinctrl_usba_vbus: usba_vbus {
> + atmel,pins =
> + <AT91_PIOD 29 AT91_PERIPH_GPIO AT91_PINCTRL_DEGLITCH>; /* PD29 GPIO with deglitch */
Here again, all comments are not or great use: remove them.
> + };
> + };
> + };
> +
> + dbgu: serial at ffffee00 {
> + dmas = <0>, <0>; /* Do not use DMA for dbgu */
> + status = "okay";
> + };
> +
> + watchdog at fffffe40 {
> + status = "okay";
> + };
> + };
> +
> + usb0: gadget at 00500000 {
> + atmel,vbus-gpio = <&pioD 29 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usba_vbus>;
> + status = "okay";
> + };
> + };
> +
> + sound {
> + compatible = "atmel,asoc-wm8904";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_pck0_as_audio_mck>;
> +
> + atmel,model = "wm8904 @ SAMA5D3EK";
> + atmel,audio-routing =
> + "Headphone Jack", "HPOUTL",
> + "Headphone Jack", "HPOUTR",
> + "IN2L", "Line In Jack",
> + "IN2R", "Line In Jack",
> + "Mic", "MICBIAS",
> + "IN1L", "Mic";
> +
> + atmel,ssc-controller = <&ssc0>;
> + atmel,audio-codec = <&wm8904>;
> +
> + status = "disabled";
> + };
> +
> + /* Conflict with LCD pins */
> + gpio_keys {
> + compatible = "gpio-keys";
> + status = "okay";
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_gpio_keys>;
> +
> + pb_user1 {
> + label = "pb_user1";
> + gpios = <&pioE 27 GPIO_ACTIVE_HIGH>;
> + linux,code = <0x100>;
> + gpio-key,wakeup;
> + };
> + };
> +};
>
--
Nicolas Ferre
^ permalink raw reply
* Re: [PATCH 6/6] drm: drm_irq.h header cleanup
From: Alex Deucher @ 2016-11-14 15:35 UTC (permalink / raw)
To: Daniel Vetter; +Cc: Daniel Vetter, DRI Development
In-Reply-To: <20161114090255.31595-6-daniel.vetter@ffwll.ch>
On Mon, Nov 14, 2016 at 4:02 AM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> - Drop extern for functions, it's noise.
> - Move&consolidate drm.ko internal parts into drm-internal.h.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
For the series:
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
> ---
> drivers/gpu/drm/drm_internal.h | 8 +++---
> include/drm/drm_irq.h | 60 ++++++++++++++++++++----------------------
> 2 files changed, 34 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
> index abd209863ef4..1e29cbc556d5 100644
> --- a/drivers/gpu/drm/drm_internal.h
> +++ b/drivers/gpu/drm/drm_internal.h
> @@ -24,9 +24,6 @@
> #define DRM_IF_MAJOR 1
> #define DRM_IF_MINOR 4
>
> -/* drm_irq.c */
> -extern unsigned int drm_timestamp_monotonic;
> -
> /* drm_fops.c */
> extern struct mutex drm_global_mutex;
> void drm_lastclose(struct drm_device *dev);
> @@ -52,6 +49,11 @@ int drm_clients_info(struct seq_file *m, void* data);
> int drm_gem_name_info(struct seq_file *m, void *data);
>
> /* drm_irq.c */
> +extern unsigned int drm_timestamp_monotonic;
> +
> +/* IOCTLS */
> +int drm_wait_vblank(struct drm_device *dev, void *data,
> + struct drm_file *filp);
> int drm_control(struct drm_device *dev, void *data,
> struct drm_file *file_priv);
> int drm_modeset_ctl(struct drm_device *dev, void *data,
> diff --git a/include/drm/drm_irq.h b/include/drm/drm_irq.h
> index 92e59d0a5ddb..293d08caab60 100644
> --- a/include/drm/drm_irq.h
> +++ b/include/drm/drm_irq.h
> @@ -130,39 +130,37 @@ struct drm_vblank_crtc {
> bool enabled;
> };
>
> -extern int drm_irq_install(struct drm_device *dev, int irq);
> -extern int drm_irq_uninstall(struct drm_device *dev);
> +int drm_irq_install(struct drm_device *dev, int irq);
> +int drm_irq_uninstall(struct drm_device *dev);
>
> -extern int drm_vblank_init(struct drm_device *dev, unsigned int num_crtcs);
> -extern int drm_wait_vblank(struct drm_device *dev, void *data,
> - struct drm_file *filp);
> -extern u32 drm_crtc_vblank_count(struct drm_crtc *crtc);
> -extern u32 drm_crtc_vblank_count_and_time(struct drm_crtc *crtc,
> - struct timeval *vblanktime);
> -extern void drm_crtc_send_vblank_event(struct drm_crtc *crtc,
> - struct drm_pending_vblank_event *e);
> -extern void drm_crtc_arm_vblank_event(struct drm_crtc *crtc,
> - struct drm_pending_vblank_event *e);
> -extern bool drm_handle_vblank(struct drm_device *dev, unsigned int pipe);
> -extern bool drm_crtc_handle_vblank(struct drm_crtc *crtc);
> -extern int drm_crtc_vblank_get(struct drm_crtc *crtc);
> -extern void drm_crtc_vblank_put(struct drm_crtc *crtc);
> -extern void drm_wait_one_vblank(struct drm_device *dev, unsigned int pipe);
> -extern void drm_crtc_wait_one_vblank(struct drm_crtc *crtc);
> -extern void drm_crtc_vblank_off(struct drm_crtc *crtc);
> -extern void drm_crtc_vblank_reset(struct drm_crtc *crtc);
> -extern void drm_crtc_vblank_on(struct drm_crtc *crtc);
> -extern void drm_vblank_cleanup(struct drm_device *dev);
> -extern u32 drm_accurate_vblank_count(struct drm_crtc *crtc);
> -extern u32 drm_vblank_no_hw_counter(struct drm_device *dev, unsigned int pipe);
> +int drm_vblank_init(struct drm_device *dev, unsigned int num_crtcs);
> +u32 drm_crtc_vblank_count(struct drm_crtc *crtc);
> +u32 drm_crtc_vblank_count_and_time(struct drm_crtc *crtc,
> + struct timeval *vblanktime);
> +void drm_crtc_send_vblank_event(struct drm_crtc *crtc,
> + struct drm_pending_vblank_event *e);
> +void drm_crtc_arm_vblank_event(struct drm_crtc *crtc,
> + struct drm_pending_vblank_event *e);
> +bool drm_handle_vblank(struct drm_device *dev, unsigned int pipe);
> +bool drm_crtc_handle_vblank(struct drm_crtc *crtc);
> +int drm_crtc_vblank_get(struct drm_crtc *crtc);
> +void drm_crtc_vblank_put(struct drm_crtc *crtc);
> +void drm_wait_one_vblank(struct drm_device *dev, unsigned int pipe);
> +void drm_crtc_wait_one_vblank(struct drm_crtc *crtc);
> +void drm_crtc_vblank_off(struct drm_crtc *crtc);
> +void drm_crtc_vblank_reset(struct drm_crtc *crtc);
> +void drm_crtc_vblank_on(struct drm_crtc *crtc);
> +void drm_vblank_cleanup(struct drm_device *dev);
> +u32 drm_accurate_vblank_count(struct drm_crtc *crtc);
> +u32 drm_vblank_no_hw_counter(struct drm_device *dev, unsigned int pipe);
>
> -extern int drm_calc_vbltimestamp_from_scanoutpos(struct drm_device *dev,
> - unsigned int pipe, int *max_error,
> - struct timeval *vblank_time,
> - unsigned flags,
> - const struct drm_display_mode *mode);
> -extern void drm_calc_timestamping_constants(struct drm_crtc *crtc,
> - const struct drm_display_mode *mode);
> +int drm_calc_vbltimestamp_from_scanoutpos(struct drm_device *dev,
> + unsigned int pipe, int *max_error,
> + struct timeval *vblank_time,
> + unsigned flags,
> + const struct drm_display_mode *mode);
> +void drm_calc_timestamping_constants(struct drm_crtc *crtc,
> + const struct drm_display_mode *mode);
>
> /**
> * drm_crtc_vblank_waitqueue - get vblank waitqueue for the CRTC
> --
> 2.10.2
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: dm-cache issue
From: Zdenek Kabelac @ 2016-11-14 15:34 UTC (permalink / raw)
To: Alexander Pashaliyski, dm-devel
In-Reply-To: <CAJV2nOTJoWWc=N80e6WCpZUh6ZRxvCW8Wt=aZWTyYSKso+kQ5Q@mail.gmail.com>
Dne 14.11.2016 v 16:02 Alexander Pashaliyski napsal(a):
> Hi guys,
>
>
> I am in a process of evaluating dm-cache for our backup system.
>
> Currently I have an issue when restart the backup server. The server is
> booting for hours, because of IO load. It seems is triggered a flush from SSD
> disk (that is used for a cache device) to the raid controllers (they are with
> slow SATA disks).
> I have 10 cached logical volumes in *writethrough mode*, each with 2T of data
> over 2 raid controllers. I use a single SSD disk for the cache.
> The backup system is with lvm2-2.02.164-1 & kernel 4.4.30.
>
>
> Do you have any ideas why such flush is triggered? In writethrough cache mode
> we shouldn't have dirty blocks in the cache.
>
Hi
Have you ensured there was proper shutdown ?
Cache needs to be properly deactivated - if it's just turned off,
all metadata are marked dirty.
Regards
Zdenek
^ permalink raw reply
* Re: [Intel-gfx] [PATCH] drm/i915: Assuming non-DP++ port if dvo_port is HDMI and there's no AUX ch specified in the VBT
From: Ville Syrjälä @ 2016-11-14 15:34 UTC (permalink / raw)
To: Daniel Vetter; +Cc: intel-gfx, Daniel Otero, stable
In-Reply-To: <20161114071556.vzik7ri3arcse2iw@phenom.ffwll.local>
On Mon, Nov 14, 2016 at 08:15:56AM +0100, Daniel Vetter wrote:
> On Fri, Nov 11, 2016 at 07:14:24PM +0200, ville.syrjala@linux.intel.com wrote:
> > From: Ville Syrj�l� <ville.syrjala@linux.intel.com>
> >
> > My heuristic for detecting type 1 DVI DP++ adaptors based on the VBT
> > port information apparently didn't survive the reality of buggy VBTs.
> > In this particular case we have a machine with a natice HDMI port, but
> > the VBT telsl us it's a DP++ port based on its capabilities.
> >
> > The dvo_port information in VBT does claim that we're dealing with a
> > HDMI port though, but we have other machines which do the same even
> > when they actually have DP++ ports. So that piece of information alone
> > isn't sufficient to tell the two apart.
> >
> > After staring at a bunch of VBTs from various machines, I have to
> > conclude that the only other semi-reliable clue we can use is the
> > presence of the AUX channel in the VBT. On this particular machine
> > AUX channel is specified as zero, whereas on some of the other machines
> > which listed the DP++ port as HDMI have a non-zero AUX channel.
> >
> > I've also seen VBTs which have dvo_port a DP but have a zero AUX
> > channel. I believe those we need to treat as DP ports, so we'll limit
> > the AUX channel check to just the cases where dvo_port is HDMI.
> >
> > If we encounter any more serious failures with this heuristic I think
> > we'll have to have to throw it out entirely. But that could mean that
> > there is a risk of type 1 DVI dongle users getting greeted by a
> > black screen, so I'd rather not go there unless absolutely necessary.
> >
> > Cc: Daniel Otero <daniel.otero@outlook.com>
> > Cc: stable@vger.kernel.org
> > Tested-by: Daniel Otero <daniel.otero@outlook.com>
> > Fixes: d61992565bd3 ("drm/i915: Determine DP++ type 1 DVI adaptor presence based on VBT")
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97994
> > Signed-off-by: Ville Syrj�l� <ville.syrjala@linux.intel.com>
> > ---
> > drivers/gpu/drm/i915/intel_bios.c | 32 ++++++++++++++++++++++++--------
> > drivers/gpu/drm/i915/intel_vbt_defs.h | 3 ++-
> > 2 files changed, 26 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_bios.c b/drivers/gpu/drm/i915/intel_bios.c
> > index 5ab646ef8c9f..33ed05186810 100644
> > --- a/drivers/gpu/drm/i915/intel_bios.c
> > +++ b/drivers/gpu/drm/i915/intel_bios.c
> > @@ -1147,7 +1147,7 @@ static void parse_ddi_port(struct drm_i915_private *dev_priv, enum port port,
> > if (!child)
> > return;
> >
> > - aux_channel = child->raw[25];
> > + aux_channel = child->common.aux_channel;
> > ddc_pin = child->common.ddc_pin;
> >
> > is_dvi = child->common.device_type & DEVICE_TYPE_TMDS_DVI_SIGNALING;
> > @@ -1677,7 +1677,8 @@ bool intel_bios_is_port_edp(struct drm_i915_private *dev_priv, enum port port)
> > return false;
> > }
> >
> > -bool intel_bios_is_port_dp_dual_mode(struct drm_i915_private *dev_priv, enum port port)
> > +static bool child_dev_is_dp_dual_mode(const union child_device_config *p_child,
> > + enum port port)
> > {
> > static const struct {
> > u16 dp, hdmi;
> > @@ -1691,22 +1692,37 @@ bool intel_bios_is_port_dp_dual_mode(struct drm_i915_private *dev_priv, enum por
> > [PORT_D] = { DVO_PORT_DPD, DVO_PORT_HDMID, },
> > [PORT_E] = { DVO_PORT_DPE, DVO_PORT_HDMIE, },
> > };
> > - int i;
> >
> > if (port == PORT_A || port >= ARRAY_SIZE(port_mapping))
> > return false;
> >
> > - if (!dev_priv->vbt.child_dev_num)
> > + if ((p_child->common.device_type & DEVICE_TYPE_DP_DUAL_MODE_BITS) !=
> > + (DEVICE_TYPE_DP_DUAL_MODE & DEVICE_TYPE_DP_DUAL_MODE_BITS))
> > + return false;
> > +
> > + if (p_child->common.dvo_port == port_mapping[port].dp)
> > + return true;
> > +
> > + /* Only accept a HDMI dvo_port as DP++ if it has an AUX channel */
> > + if (p_child->common.dvo_port == port_mapping[port].hdmi &&
> > + p_child->common.aux_channel != 0)
> > + return true;
> > +
> > + return false;
> > +}
> > +
> > +bool intel_bios_is_port_dp_dual_mode(struct drm_i915_private *dev_priv, enum port port)
> > +{
> > + int i;
> > +
> > + if (port == PORT_A)
> > return false;
>
> We check for PORT_A twice now. Otherwise contains what it says on the tin,
> but no idea whether this is the perfect solution either. Also need to
> check vbt docs for the right bit, but assuming that checks out (I'll
> report on irc), and with the above nitpick fixed:
>
> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11:34 < danvet> vsyrjala, vbt seems to check out too
v2: Remove the duplicate PORT_A check (Daniel)
Fix some typos in the commit message
Pushed to dinq. Thanks for the review.
>
> >
> > for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
> > const union child_device_config *p_child =
> > &dev_priv->vbt.child_dev[i];
> >
> > - if ((p_child->common.dvo_port == port_mapping[port].dp ||
> > - p_child->common.dvo_port == port_mapping[port].hdmi) &&
> > - (p_child->common.device_type & DEVICE_TYPE_DP_DUAL_MODE_BITS) ==
> > - (DEVICE_TYPE_DP_DUAL_MODE & DEVICE_TYPE_DP_DUAL_MODE_BITS))
> > + if (child_dev_is_dp_dual_mode(p_child, port))
> > return true;
> > }
> >
> > diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h b/drivers/gpu/drm/i915/intel_vbt_defs.h
> > index 68db9621f1f0..8886cab19f98 100644
> > --- a/drivers/gpu/drm/i915/intel_vbt_defs.h
> > +++ b/drivers/gpu/drm/i915/intel_vbt_defs.h
> > @@ -280,7 +280,8 @@ struct common_child_dev_config {
> > u8 dp_support:1;
> > u8 tmds_support:1;
> > u8 support_reserved:5;
> > - u8 not_common3[12];
> > + u8 aux_channel;
> > + u8 not_common3[11];
> > u8 iboost_level;
> > } __packed;
> >
> > --
> > 2.7.4
> >
> > _______________________________________________
> > 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
--
Ville Syrj�l�
Intel OTC
^ permalink raw reply
* Re: [Intel-gfx] [PATCH] drm/i915: Assuming non-DP++ port if dvo_port is HDMI and there's no AUX ch specified in the VBT
From: Ville Syrjälä @ 2016-11-14 15:34 UTC (permalink / raw)
To: Daniel Vetter; +Cc: intel-gfx, Daniel Otero, stable
In-Reply-To: <20161114071556.vzik7ri3arcse2iw@phenom.ffwll.local>
On Mon, Nov 14, 2016 at 08:15:56AM +0100, Daniel Vetter wrote:
> On Fri, Nov 11, 2016 at 07:14:24PM +0200, ville.syrjala@linux.intel.com wrote:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > My heuristic for detecting type 1 DVI DP++ adaptors based on the VBT
> > port information apparently didn't survive the reality of buggy VBTs.
> > In this particular case we have a machine with a natice HDMI port, but
> > the VBT telsl us it's a DP++ port based on its capabilities.
> >
> > The dvo_port information in VBT does claim that we're dealing with a
> > HDMI port though, but we have other machines which do the same even
> > when they actually have DP++ ports. So that piece of information alone
> > isn't sufficient to tell the two apart.
> >
> > After staring at a bunch of VBTs from various machines, I have to
> > conclude that the only other semi-reliable clue we can use is the
> > presence of the AUX channel in the VBT. On this particular machine
> > AUX channel is specified as zero, whereas on some of the other machines
> > which listed the DP++ port as HDMI have a non-zero AUX channel.
> >
> > I've also seen VBTs which have dvo_port a DP but have a zero AUX
> > channel. I believe those we need to treat as DP ports, so we'll limit
> > the AUX channel check to just the cases where dvo_port is HDMI.
> >
> > If we encounter any more serious failures with this heuristic I think
> > we'll have to have to throw it out entirely. But that could mean that
> > there is a risk of type 1 DVI dongle users getting greeted by a
> > black screen, so I'd rather not go there unless absolutely necessary.
> >
> > Cc: Daniel Otero <daniel.otero@outlook.com>
> > Cc: stable@vger.kernel.org
> > Tested-by: Daniel Otero <daniel.otero@outlook.com>
> > Fixes: d61992565bd3 ("drm/i915: Determine DP++ type 1 DVI adaptor presence based on VBT")
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97994
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > ---
> > drivers/gpu/drm/i915/intel_bios.c | 32 ++++++++++++++++++++++++--------
> > drivers/gpu/drm/i915/intel_vbt_defs.h | 3 ++-
> > 2 files changed, 26 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_bios.c b/drivers/gpu/drm/i915/intel_bios.c
> > index 5ab646ef8c9f..33ed05186810 100644
> > --- a/drivers/gpu/drm/i915/intel_bios.c
> > +++ b/drivers/gpu/drm/i915/intel_bios.c
> > @@ -1147,7 +1147,7 @@ static void parse_ddi_port(struct drm_i915_private *dev_priv, enum port port,
> > if (!child)
> > return;
> >
> > - aux_channel = child->raw[25];
> > + aux_channel = child->common.aux_channel;
> > ddc_pin = child->common.ddc_pin;
> >
> > is_dvi = child->common.device_type & DEVICE_TYPE_TMDS_DVI_SIGNALING;
> > @@ -1677,7 +1677,8 @@ bool intel_bios_is_port_edp(struct drm_i915_private *dev_priv, enum port port)
> > return false;
> > }
> >
> > -bool intel_bios_is_port_dp_dual_mode(struct drm_i915_private *dev_priv, enum port port)
> > +static bool child_dev_is_dp_dual_mode(const union child_device_config *p_child,
> > + enum port port)
> > {
> > static const struct {
> > u16 dp, hdmi;
> > @@ -1691,22 +1692,37 @@ bool intel_bios_is_port_dp_dual_mode(struct drm_i915_private *dev_priv, enum por
> > [PORT_D] = { DVO_PORT_DPD, DVO_PORT_HDMID, },
> > [PORT_E] = { DVO_PORT_DPE, DVO_PORT_HDMIE, },
> > };
> > - int i;
> >
> > if (port == PORT_A || port >= ARRAY_SIZE(port_mapping))
> > return false;
> >
> > - if (!dev_priv->vbt.child_dev_num)
> > + if ((p_child->common.device_type & DEVICE_TYPE_DP_DUAL_MODE_BITS) !=
> > + (DEVICE_TYPE_DP_DUAL_MODE & DEVICE_TYPE_DP_DUAL_MODE_BITS))
> > + return false;
> > +
> > + if (p_child->common.dvo_port == port_mapping[port].dp)
> > + return true;
> > +
> > + /* Only accept a HDMI dvo_port as DP++ if it has an AUX channel */
> > + if (p_child->common.dvo_port == port_mapping[port].hdmi &&
> > + p_child->common.aux_channel != 0)
> > + return true;
> > +
> > + return false;
> > +}
> > +
> > +bool intel_bios_is_port_dp_dual_mode(struct drm_i915_private *dev_priv, enum port port)
> > +{
> > + int i;
> > +
> > + if (port == PORT_A)
> > return false;
>
> We check for PORT_A twice now. Otherwise contains what it says on the tin,
> but no idea whether this is the perfect solution either. Also need to
> check vbt docs for the right bit, but assuming that checks out (I'll
> report on irc), and with the above nitpick fixed:
>
> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11:34 < danvet> vsyrjala, vbt seems to check out too
v2: Remove the duplicate PORT_A check (Daniel)
Fix some typos in the commit message
Pushed to dinq. Thanks for the review.
>
> >
> > for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
> > const union child_device_config *p_child =
> > &dev_priv->vbt.child_dev[i];
> >
> > - if ((p_child->common.dvo_port == port_mapping[port].dp ||
> > - p_child->common.dvo_port == port_mapping[port].hdmi) &&
> > - (p_child->common.device_type & DEVICE_TYPE_DP_DUAL_MODE_BITS) ==
> > - (DEVICE_TYPE_DP_DUAL_MODE & DEVICE_TYPE_DP_DUAL_MODE_BITS))
> > + if (child_dev_is_dp_dual_mode(p_child, port))
> > return true;
> > }
> >
> > diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h b/drivers/gpu/drm/i915/intel_vbt_defs.h
> > index 68db9621f1f0..8886cab19f98 100644
> > --- a/drivers/gpu/drm/i915/intel_vbt_defs.h
> > +++ b/drivers/gpu/drm/i915/intel_vbt_defs.h
> > @@ -280,7 +280,8 @@ struct common_child_dev_config {
> > u8 dp_support:1;
> > u8 tmds_support:1;
> > u8 support_reserved:5;
> > - u8 not_common3[12];
> > + u8 aux_channel;
> > + u8 not_common3[11];
> > u8 iboost_level;
> > } __packed;
> >
> > --
> > 2.7.4
> >
> > _______________________________________________
> > 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
--
Ville Syrjälä
Intel OTC
^ permalink raw reply
* Re: Debugging Ethernet issues
From: Mason @ 2016-11-14 15:33 UTC (permalink / raw)
To: Andrew Lunn
Cc: Florian Fainelli, netdev, Mans Rullgard, Sergei Shtylyov,
Tom Lendacky, Zach Brown, Shaohui Xie, Tim Beale, Brian Hill,
Vince Bridgers, Balakumaran Kannan, David S. Miller,
Sebastian Frias, Kirill Kapranov
In-Reply-To: <5829D10F.30206@free.fr>
On 14/11/2016 15:58, Mason wrote:
> nb8800 26000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
> vs
> nb8800 26000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off
>
> I'm not sure whether "flow control" is relevant...
Based on phy_print_status()
phydev->pause ? "rx/tx" : "off"
I added the following patch.
diff --git a/drivers/net/ethernet/aurora/nb8800.c b/drivers/net/ethernet/aurora/nb8800.c
index defc22a15f67..4e758c1cfa4e 100644
--- a/drivers/net/ethernet/aurora/nb8800.c
+++ b/drivers/net/ethernet/aurora/nb8800.c
@@ -667,6 +667,8 @@ static void nb8800_link_reconfigure(struct net_device *dev)
struct phy_device *phydev = priv->phydev;
int change = 0;
+ printk("%s from %pf\n", __func__, __builtin_return_address(0));
+
if (phydev->link) {
if (phydev->speed != priv->speed) {
priv->speed = phydev->speed;
@@ -1274,9 +1276,9 @@ static int nb8800_hw_init(struct net_device *dev)
nb8800_writeb(priv, NB8800_PQ2, val & 0xff);
/* Auto-negotiate by default */
- priv->pause_aneg = true;
- priv->pause_rx = true;
- priv->pause_tx = true;
+ priv->pause_aneg = false;
+ priv->pause_rx = false;
+ priv->pause_tx = false;
nb8800_mc_init(dev, 0);
Connected to 1000 Mbps switch:
# time udhcpc | while read LINE; do date; echo $LINE; done
Thu Jan 1 00:00:22 UTC 1970
udhcpc (v1.22.1) started
Thu Jan 1 00:00:22 UTC 1970
Sending discover...
[ 24.565346] nb8800_link_reconfigure from phy_state_machine
Thu Jan 1 00:00:25 UTC 1970
Sending discover...
[ 26.575402] nb8800_link_reconfigure from phy_state_machine
[ 26.580972] nb8800 26000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
Thu Jan 1 00:00:28 UTC 1970
Sending discover...
Thu Jan 1 00:00:29 UTC 1970
Sending select for 172.27.64.58...
Thu Jan 1 00:00:29 UTC 1970
Lease of 172.27.64.58 obtained, lease time 604800
Thu Jan 1 00:00:29 UTC 1970
deleting routers
Thu Jan 1 00:00:29 UTC 1970
adding dns 172.27.0.17
real 0m7.388s
user 0m0.040s
sys 0m0.090s
Connected to 100 Mbps switch:
# time udhcpc | while read LINE; do date; echo $LINE; done
Thu Jan 1 00:00:14 UTC 1970
udhcpc (v1.22.1) started
Thu Jan 1 00:00:15 UTC 1970
Sending discover...
[ 16.968621] nb8800_link_reconfigure from phy_state_machine
[ 17.975359] nb8800_link_reconfigure from phy_state_machine
[ 17.980923] nb8800 26000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
Thu Jan 1 00:00:18 UTC 1970
Sending discover...
Thu Jan 1 00:00:19 UTC 1970
Sending select for 172.27.64.58...
Thu Jan 1 00:00:19 UTC 1970
Lease of 172.27.64.58 obtained, lease time 604800
Thu Jan 1 00:00:19 UTC 1970
deleting routers
Thu Jan 1 00:00:19 UTC 1970
adding dns 172.27.0.17
real 0m4.355s
user 0m0.043s
sys 0m0.083s
OK, so now it works (by accident?) even on 100 Mbps switch, but it still
prints "flow control rx/tx"...
# ethtool -a eth0
Pause parameters for eth0:
Autonegotiate: off
RX: off
TX: off
These values make sense considering my changes in the driver.
Are 100 Mbps switches supposed to support these pause features,
and are they supposed to be able to auto-negotiate them?
Regards.
^ permalink raw reply related
* [PATCH 1/2] pinctrl: bcm2835: Fix ints for GPIOs 28-31 & 46-53
From: Stefan Wahren @ 2016-11-14 15:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479126206-20482-1-git-send-email-linus.walleij@linaro.org>
Hi Linus,
Am 14.11.2016 um 13:23 schrieb Linus Walleij:
> From: Phil Elwell <phil@raspberrypi.org>
>
> Contrary to the documentation, the BCM2835 GPIO controller actually
> has four interrupt lines - one each for the three IRQ groups and one
> common. Confusingly, the GPIO interrupt groups don't correspond
> directly with the GPIO control banks. Instead, GPIOs 0-27 generate IRQ
> GPIO0, 28-45 IRQ GPIO1 and 46-53 IRQ GPIO2.
>
> Awkwardly, the GPIOs for IRQ GPIO1 straddle two 32-entry GPIO banks,
> so split out a function to process the interrupts for a single GPIO
> bank.
>
> Cc: Stefan Wahren <stefan.wahren@i2se.com>
> Cc: Eric Anholt <eric@anholt.net>
> Cc: Stephen Warren <swarren@wwwdotorg.org>
> Signed-off-by: Phil Elwell <phil@raspberrypi.org>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> I want to apply this to cater for my GPIOLIB_IRQCHIP
> refactorings.
> ---
> drivers/pinctrl/bcm/pinctrl-bcm2835.c | 51 ++++++++++++++++++++++++++---------
> 1 file changed, 39 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/pinctrl/bcm/pinctrl-bcm2835.c b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
> index b2dd278f18b1..1d8fc104e26b 100644
> --- a/drivers/pinctrl/bcm/pinctrl-bcm2835.c
> +++ b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
>
...
> @@ -1076,6 +1102,7 @@ static struct platform_driver bcm2835_pinctrl_driver = {
> .remove = bcm2835_pinctrl_remove,
> .driver = {
> .name = MODULE_NAME,
> + .owner = THIS_MODULE,
this is unnecessary. Please remove it.
Thanks for submitting these patches
Stefan
> .of_match_table = bcm2835_pinctrl_match,
> },
> };
^ permalink raw reply
* Re: [PATCH 1/2] pinctrl: bcm2835: Fix ints for GPIOs 28-31 & 46-53
From: Stefan Wahren @ 2016-11-14 15:32 UTC (permalink / raw)
To: Linus Walleij, linux-kernel, linux-arm-kernel
Cc: linux-gpio, Phil Elwell, Eric Anholt, Stephen Warren
In-Reply-To: <1479126206-20482-1-git-send-email-linus.walleij@linaro.org>
Hi Linus,
Am 14.11.2016 um 13:23 schrieb Linus Walleij:
> From: Phil Elwell <phil@raspberrypi.org>
>
> Contrary to the documentation, the BCM2835 GPIO controller actually
> has four interrupt lines - one each for the three IRQ groups and one
> common. Confusingly, the GPIO interrupt groups don't correspond
> directly with the GPIO control banks. Instead, GPIOs 0-27 generate IRQ
> GPIO0, 28-45 IRQ GPIO1 and 46-53 IRQ GPIO2.
>
> Awkwardly, the GPIOs for IRQ GPIO1 straddle two 32-entry GPIO banks,
> so split out a function to process the interrupts for a single GPIO
> bank.
>
> Cc: Stefan Wahren <stefan.wahren@i2se.com>
> Cc: Eric Anholt <eric@anholt.net>
> Cc: Stephen Warren <swarren@wwwdotorg.org>
> Signed-off-by: Phil Elwell <phil@raspberrypi.org>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> I want to apply this to cater for my GPIOLIB_IRQCHIP
> refactorings.
> ---
> drivers/pinctrl/bcm/pinctrl-bcm2835.c | 51 ++++++++++++++++++++++++++---------
> 1 file changed, 39 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/pinctrl/bcm/pinctrl-bcm2835.c b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
> index b2dd278f18b1..1d8fc104e26b 100644
> --- a/drivers/pinctrl/bcm/pinctrl-bcm2835.c
> +++ b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
>
...
> @@ -1076,6 +1102,7 @@ static struct platform_driver bcm2835_pinctrl_driver = {
> .remove = bcm2835_pinctrl_remove,
> .driver = {
> .name = MODULE_NAME,
> + .owner = THIS_MODULE,
this is unnecessary. Please remove it.
Thanks for submitting these patches
Stefan
> .of_match_table = bcm2835_pinctrl_match,
> },
> };
^ permalink raw reply
* Re: [PATCH 0/2] Honey, I shrunk the EFI stub
From: Lukas Wunner @ 2016-11-14 15:32 UTC (permalink / raw)
To: Matt Fleming; +Cc: linux-efi-u79uwXL29TY76Z2rM5mHXA, Ard Biesheuvel
In-Reply-To: <20161114111906.GA9938-JFq808J9C/izQB+pC5nmwQ@public.gmane.org>
On Mon, Nov 14, 2016 at 12:19:06PM +0100, Lukas Wunner wrote:
> On Sat, Nov 12, 2016 at 08:55:14PM +0000, Matt Fleming wrote:
> > On Mon, 07 Nov, at 12:17:00PM, Lukas Wunner wrote:
> > > Another oddity is that info_sz is declared u32 in __file_size32(),
> > > yet the spec says that the third argument to EFI_FILE_PROTOCOL.GetInfo()
> > > is of type UINTN, which I assume is 64 bit regardless of mixed-mode,
> > > or am I missing something? Patch [1/2] uses an unsigned long instead.
> >
> > UINTN is an unsigned value of native width as seen by the firmware. On
> > 32-bit firmware that's 32-bits and 64-bit firmware 64-bits.
> >
> > Using 'u32' in __file_size32() is correct, unsigned long is not.
>
> Okay since this is all little endian, it should be okay to have a
> 64 bit wide variable on the stack whose address is passed to GetInfo()
> as BufferSize argument. But I guess I need to initialize it to 0
> upon declaration so that the upper 32 bit are zeroed out in mixed mode,
> right? That would be a bug in patch [1/2] then.
Oh the info_sz variable *is* already initialized to 0 before the first
invocation of GetInfo(). So the patch should be fine, reviewed it
once more with the explanations in mind that you provided and couldn't
see anything else that would cause issues in mixed-mode.
Thanks,
Lukas
^ permalink raw reply
* Re: [RFC 02/14] SoundWire: Add SoundWire stream documentation
From: Charles Keepax @ 2016-11-14 15:31 UTC (permalink / raw)
To: Hardik Shah
Cc: alsa-devel, linux-kernel, tiwai, pierre-louis.bossart, broonie,
lgirdwood, plai, patches.audio, Sanyog Kale
In-Reply-To: <1477053673-16021-3-git-send-email-hardik.t.shah@intel.com>
On Fri, Oct 21, 2016 at 06:11:00PM +0530, Hardik Shah wrote:
> This patch adds stream documentation describing SoundWire stream and
> stream states.
>
> Signed-off-by: Hardik Shah <hardik.t.shah@intel.com>
> Signed-off-by: Sanyog Kale <sanyog.r.kale@intel.com>
> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
> ---
> Documentation/sound/alsa/sdw/stream.txt | 346 +++++++++++++++++++++++++++++++
> 1 file changed, 346 insertions(+)
> create mode 100644 Documentation/sound/alsa/sdw/stream.txt
>
> diff --git a/Documentation/sound/alsa/sdw/stream.txt b/Documentation/sound/alsa/sdw/stream.txt
> new file mode 100644
> index 0000000..a1a2ed0
> --- /dev/null
> +++ b/Documentation/sound/alsa/sdw/stream.txt
> @@ -0,0 +1,346 @@
<snip>
> +
> +SoundWire stream states
> +=======================
> +Below figure shows the SoundWire stream states and possible state
> +transition diagram.
> +
> +|--------------| |-------------| |--------------| |--------------|
> +| ALLOC |---->| CONFIG |---->| PREPARE |---->| ENABLE |
> +| STATE | | STATE | | STATE | | STATE |
> +|--------------| |-------------| |--------------| |--------------|
> + ^ |
> + | |
> + | |
> + | |
> + | \/
> + |--------------| |--------------| |--------------|
> + | RELEASE |<--------------------| DEPREPARE |<----| DISABLE |
> + | STATE | | STATE | | STATE |
> + |--------------| |--------------| |--------------|
> +
One minor comment, this looks very similar to the clock
frameworks state model, but the clock framework calls it
unprepare would there be some milage in aligning to?
> +
> +SoundWire Stream State Operations
> +==================================
> +Below section explains the operations done by the bus driver on
> +Master(s) and Slave(s) as part of stream state transitions.
> +
> +SDW_STATE_STRM_ALLOC: Allocation state for stream. This is the entry
> +state of the stream. Operations performed before entering in this
> +state:
> +1. An unique stream tag is assigned to stream. This stream tag is used
A unique
> +as a reference for all the operations performed on stream.
> +
> +2. The resources required for holding stream runtime information are
> +allocated and initialized. This holds all stream related information
> +such as stream type (PCM/PDM) and parameters, Master and Slave interface
> +associated with the stream, reference counting, stream state etc.
> +
> +After all above operations are successful, stream state is set to
> +SDW_STATE_STRM_ALLOC.
> +
> +
> +SDW_STATE_STRM_CONFIG: Configuration state of stream. Operations
> +performed before entering in this state:
> +1. The resources allocated for stream information in
> +SDW_STATE_STRM_ALLOC state are updated. This includes stream parameters,
> +Masters and Slaves runtime information associated with the stream.
> +
> +2. All the Masters and Slaves associated with the stream updates the
> +port configuration to bus driver. This includes port numbers allocated
> +by Master(s) and Slave(s) for this stream.
> +
> +After all above operations are successful, stream state is set to
> +SDW_STATE_STRM_CONFIG.
> +
> +
> +SDW_STATE_STRM_PREPARE: Prepare state of stream. Operations performed
> +before entering in this state:
> +1. Bus parameters such as bandwidth, frame shape, clock frequency, SSP
> +interval are computed based on current stream as well as already active
> +streams on bus. Re-computation is required to accommodate current stream
> +on the bus.
> +
> +2. Transport parameters of all Master and Slave ports are computed for
> +the current as well as already active stream based on above calculated
> +frame shape and clock frequency.
> +
> +3. Computed bus and transport parameters are programmed in Master and
> +Slave registers. The banked registers programming is done on the
> +alternate bank (bank currently unused). Port channels are enabled for
> +the already active streams on the alternate bank (bank currently
> +unused). This is done in order to not to disrupt already active
> +stream(s).
> +
> +4. Once all the new values are programmed, bus initiates switch to
> +alternate bank. Once switch is successful, the port channels enabled on
> +previous bank for already active streams are disabled.
> +
> +5. Ports of Master and Slave for current stream are prepared.
> +
> +After all above operations are successful, stream state is set to
> +SDW_STATE_STRM_PREPARE.
> +
> +
> +SDW_STATE_STRM_ENABLE: Enable state of stream. Operations performed
> +before entering in this state:
> +1. All the values computed in SDW_STATE_STRM_PREPARE state are
> +programmed in alternate bank (bank currently unused). It includes
> +programming of already active streams as well.
> +
> +2. All the Master and Slave port channels for the current stream are
> +enabled on alternate bank (bank currently unused).
> +
This could probably use a little more explaination to show how it
differs from step 3/4 in PREPARE, as it looks like all the
computed values where applied there. I imagine this is just my lack
of understanding rather than an actual issue but even looking at
the code I am having a little difficulty tying up these two.
sdw_prepare_op
- sdw_compute_params (prepare step 1/2)
- sdw_program_params (prepare step 3)
- sdw_update_bus_params (prepare step 4)
sdw_enable_op
- sdw_program_params (enable step 1)
- sdw_update_bus_params (enable step 2)
It looks like the params are still basically the same as they
were when we called sdw_program_params in prepare.
> +3. Once all the new values are programmed, bus initiates switch to
> +alternate bank. Once the switch is successful, the port channels enabled
> +on previous bank for already active streams are disabled.
> +
> +After all above operations are successful, stream state is set to
> +SDW_STATE_STRM_ENABLE.
> +
> +
Thanks,
Charles
^ permalink raw reply
* Re: [RFC 02/14] SoundWire: Add SoundWire stream documentation
From: Charles Keepax @ 2016-11-14 15:31 UTC (permalink / raw)
To: Hardik Shah
Cc: alsa-devel, linux-kernel, tiwai, pierre-louis.bossart, broonie,
lgirdwood, plai, patches.audio, Sanyog Kale
In-Reply-To: <1477053673-16021-3-git-send-email-hardik.t.shah@intel.com>
On Fri, Oct 21, 2016 at 06:11:00PM +0530, Hardik Shah wrote:
> This patch adds stream documentation describing SoundWire stream and
> stream states.
>
> Signed-off-by: Hardik Shah <hardik.t.shah@intel.com>
> Signed-off-by: Sanyog Kale <sanyog.r.kale@intel.com>
> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
> ---
> Documentation/sound/alsa/sdw/stream.txt | 346 +++++++++++++++++++++++++++++++
> 1 file changed, 346 insertions(+)
> create mode 100644 Documentation/sound/alsa/sdw/stream.txt
>
> diff --git a/Documentation/sound/alsa/sdw/stream.txt b/Documentation/sound/alsa/sdw/stream.txt
> new file mode 100644
> index 0000000..a1a2ed0
> --- /dev/null
> +++ b/Documentation/sound/alsa/sdw/stream.txt
> @@ -0,0 +1,346 @@
<snip>
> +
> +SoundWire stream states
> +=======================
> +Below figure shows the SoundWire stream states and possible state
> +transition diagram.
> +
> +|--------------| |-------------| |--------------| |--------------|
> +| ALLOC |---->| CONFIG |---->| PREPARE |---->| ENABLE |
> +| STATE | | STATE | | STATE | | STATE |
> +|--------------| |-------------| |--------------| |--------------|
> + ^ |
> + | |
> + | |
> + | |
> + | \/
> + |--------------| |--------------| |--------------|
> + | RELEASE |<--------------------| DEPREPARE |<----| DISABLE |
> + | STATE | | STATE | | STATE |
> + |--------------| |--------------| |--------------|
> +
One minor comment, this looks very similar to the clock
frameworks state model, but the clock framework calls it
unprepare would there be some milage in aligning to?
> +
> +SoundWire Stream State Operations
> +==================================
> +Below section explains the operations done by the bus driver on
> +Master(s) and Slave(s) as part of stream state transitions.
> +
> +SDW_STATE_STRM_ALLOC: Allocation state for stream. This is the entry
> +state of the stream. Operations performed before entering in this
> +state:
> +1. An unique stream tag is assigned to stream. This stream tag is used
A unique
> +as a reference for all the operations performed on stream.
> +
> +2. The resources required for holding stream runtime information are
> +allocated and initialized. This holds all stream related information
> +such as stream type (PCM/PDM) and parameters, Master and Slave interface
> +associated with the stream, reference counting, stream state etc.
> +
> +After all above operations are successful, stream state is set to
> +SDW_STATE_STRM_ALLOC.
> +
> +
> +SDW_STATE_STRM_CONFIG: Configuration state of stream. Operations
> +performed before entering in this state:
> +1. The resources allocated for stream information in
> +SDW_STATE_STRM_ALLOC state are updated. This includes stream parameters,
> +Masters and Slaves runtime information associated with the stream.
> +
> +2. All the Masters and Slaves associated with the stream updates the
> +port configuration to bus driver. This includes port numbers allocated
> +by Master(s) and Slave(s) for this stream.
> +
> +After all above operations are successful, stream state is set to
> +SDW_STATE_STRM_CONFIG.
> +
> +
> +SDW_STATE_STRM_PREPARE: Prepare state of stream. Operations performed
> +before entering in this state:
> +1. Bus parameters such as bandwidth, frame shape, clock frequency, SSP
> +interval are computed based on current stream as well as already active
> +streams on bus. Re-computation is required to accommodate current stream
> +on the bus.
> +
> +2. Transport parameters of all Master and Slave ports are computed for
> +the current as well as already active stream based on above calculated
> +frame shape and clock frequency.
> +
> +3. Computed bus and transport parameters are programmed in Master and
> +Slave registers. The banked registers programming is done on the
> +alternate bank (bank currently unused). Port channels are enabled for
> +the already active streams on the alternate bank (bank currently
> +unused). This is done in order to not to disrupt already active
> +stream(s).
> +
> +4. Once all the new values are programmed, bus initiates switch to
> +alternate bank. Once switch is successful, the port channels enabled on
> +previous bank for already active streams are disabled.
> +
> +5. Ports of Master and Slave for current stream are prepared.
> +
> +After all above operations are successful, stream state is set to
> +SDW_STATE_STRM_PREPARE.
> +
> +
> +SDW_STATE_STRM_ENABLE: Enable state of stream. Operations performed
> +before entering in this state:
> +1. All the values computed in SDW_STATE_STRM_PREPARE state are
> +programmed in alternate bank (bank currently unused). It includes
> +programming of already active streams as well.
> +
> +2. All the Master and Slave port channels for the current stream are
> +enabled on alternate bank (bank currently unused).
> +
This could probably use a little more explaination to show how it
differs from step 3/4 in PREPARE, as it looks like all the
computed values where applied there. I imagine this is just my lack
of understanding rather than an actual issue but even looking at
the code I am having a little difficulty tying up these two.
sdw_prepare_op
- sdw_compute_params (prepare step 1/2)
- sdw_program_params (prepare step 3)
- sdw_update_bus_params (prepare step 4)
sdw_enable_op
- sdw_program_params (enable step 1)
- sdw_update_bus_params (enable step 2)
It looks like the params are still basically the same as they
were when we called sdw_program_params in prepare.
> +3. Once all the new values are programmed, bus initiates switch to
> +alternate bank. Once the switch is successful, the port channels enabled
> +on previous bank for already active streams are disabled.
> +
> +After all above operations are successful, stream state is set to
> +SDW_STATE_STRM_ENABLE.
> +
> +
Thanks,
Charles
^ permalink raw reply
* [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
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.