Re: [Regression] 3.18 black screen after boot (bisected)
On Sun, Dec 14, 2014 at 12:58:31PM +0100, Heinz Diehl wrote: > Hi, > > since kernel 3.18 I'm no longer able to run X on my machine. While > 3.17.6 is fine, 3.18 leaves me with a black screen when starting > X. Booting into runlevel 1/3 is fine. > > I did a "git bisect", and the offending commit is this one: > > [root@kiera linux-git]# git bisect bad > 83f45fc360c8e16a330474860ebda872d1384c8c is the first bad commit > commit 83f45fc360c8e16a330474860ebda872d1384c8c > Author: Daniel Vetter > Date: Wed Aug 6 09:10:18 2014 +0200 > > drm: Don't grab an fb reference for the idr > > [] > > I double-checked, and 3.18 is fine with this commit reverted. > > My machine is an Asus U45JC laptop, and the CPU is an Intel i450M > (Ironlake). Please contact me if I can help in any way (I'm subscribed > to lkml, but not to other X or kernel related lists). Can you please boot with drm.debug=0xf on both good and bad kernels and then grab dmesg from each? To make sure we don't forget this please file the above summary plus dmesg files as a new bug against dri -> drm(intel) on bugs.freedesktop.org. Please add "[ilk bisected]" to the bug summary so it shows up in all the right searches for us. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/6] Touchscreen performance related fixes
On Fri, Dec 12, 2014 at 4:16 PM, Griffis, Brad wrote: > How are you configuring ti,charge-delay in your dts? I've seen this behavior > on some custom boards where we were using a smaller charge delay (0x400) to > begin with, and by upping it to 0xb000 we resolved the issue. These patches > however already specified ti,charge-delay = 0xb000 by default so this would > surprise me that it's still seeing that issue. Was the touchscreen working > as expected before these new patches, or does it have issues both ways? Initially I had set the charge-delay to 0x400 and I was seeing many false pen-down/pen-up events With 0xb000, I was still getting many of them but less than with 0x400. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/7] slub: Fastpath optimization (especially for RT) V1
On Wed, Dec 10, 2014 at 10:30:17AM -0600, Christoph Lameter wrote: > We had to insert a preempt enable/disable in the fastpath a while ago. This > was mainly due to a lot of state that is kept to be allocating from the per > cpu freelist. In particular the page field is not covered by > this_cpu_cmpxchg used in the fastpath to do the necessary atomic state > change for fast path allocation and freeing. > > This patch removes the need for the page field to describe the state of the > per cpu list. The freelist pointer can be used to determine the page struct > address if necessary. > > However, currently this does not work for the termination value of a list > which is NULL and the same for all slab pages. If we use a valid pointer > into the page as well as set the last bit then all freelist pointers can > always be used to determine the address of the page struct and we will not > need the page field anymore in the per cpu are for a slab. Testing for the > end of the list is a test if the first bit is set. > > So the first patch changes the termination pointer for freelists to do just > that. The second removes the page field and then third can then remove the > preempt enable/disable. > > Removing the ->page field reduces the cache footprint of the fastpath so > hopefully overall > allocator effectiveness will increase further. Also RT uses full preemption > which means > that currently pretty expensive code has to be inserted into the fastpath. > This approach > allows the removal of that code and a corresponding performance increase. > > For V1 a number of changes were made to avoid the overhead of virt_to_page > and page_address from the RFC. > > Slab Benchmarks on a kernel with CONFIG_PREEMPT show an improvement of > 20%-50% of fastpath latency: > > Before: > > Single thread testing > 1. Kmalloc: Repeatedly allocate then free test > 1 times kmalloc(8) -> 68 cycles kfree -> 107 cycles > 1 times kmalloc(16) -> 69 cycles kfree -> 108 cycles > 1 times kmalloc(32) -> 78 cycles kfree -> 112 cycles > 1 times kmalloc(64) -> 97 cycles kfree -> 112 cycles > 1 times kmalloc(128) -> 111 cycles kfree -> 119 cycles > 1 times kmalloc(256) -> 114 cycles kfree -> 139 cycles > 1 times kmalloc(512) -> 110 cycles kfree -> 142 cycles > 1 times kmalloc(1024) -> 114 cycles kfree -> 156 cycles > 1 times kmalloc(2048) -> 155 cycles kfree -> 174 cycles > 1 times kmalloc(4096) -> 203 cycles kfree -> 209 cycles > 1 times kmalloc(8192) -> 361 cycles kfree -> 265 cycles > 1 times kmalloc(16384) -> 597 cycles kfree -> 286 cycles > > 2. Kmalloc: alloc/free test > 1 times kmalloc(8)/kfree -> 114 cycles > 1 times kmalloc(16)/kfree -> 115 cycles > 1 times kmalloc(32)/kfree -> 117 cycles > 1 times kmalloc(64)/kfree -> 115 cycles > 1 times kmalloc(128)/kfree -> 111 cycles > 1 times kmalloc(256)/kfree -> 116 cycles > 1 times kmalloc(512)/kfree -> 110 cycles > 1 times kmalloc(1024)/kfree -> 114 cycles > 1 times kmalloc(2048)/kfree -> 110 cycles > 1 times kmalloc(4096)/kfree -> 107 cycles > 1 times kmalloc(8192)/kfree -> 108 cycles > 1 times kmalloc(16384)/kfree -> 706 cycles > > > After: > > > Single thread testing > 1. Kmalloc: Repeatedly allocate then free test > 1 times kmalloc(8) -> 41 cycles kfree -> 81 cycles > 1 times kmalloc(16) -> 47 cycles kfree -> 88 cycles > 1 times kmalloc(32) -> 48 cycles kfree -> 93 cycles > 1 times kmalloc(64) -> 58 cycles kfree -> 89 cycles > 1 times kmalloc(128) -> 84 cycles kfree -> 104 cycles > 1 times kmalloc(256) -> 92 cycles kfree -> 125 cycles > 1 times kmalloc(512) -> 86 cycles kfree -> 129 cycles > 1 times kmalloc(1024) -> 88 cycles kfree -> 125 cycles > 1 times kmalloc(2048) -> 120 cycles kfree -> 159 cycles > 1 times kmalloc(4096) -> 176 cycles kfree -> 183 cycles > 1 times kmalloc(8192) -> 294 cycles kfree -> 233 cycles > 1 times kmalloc(16384) -> 585 cycles kfree -> 291 cycles > > 2. Kmalloc: alloc/free test > 1 times kmalloc(8)/kfree -> 100 cycles > 1 times kmalloc(16)/kfree -> 108 cycles > 1 times kmalloc(32)/kfree -> 101 cycles > 1 times kmalloc(64)/kfree -> 109 cycles > 1 times kmalloc(128)/kfree -> 125 cycles > 1 times kmalloc(256)/kfree -> 60 cycles > 1 times kmalloc(512)/kfree -> 60 cycles > 1 times kmalloc(1024)/kfree -> 67 cycles > 1 times kmalloc(2048)/kfree -> 60 cycles > 1 times kmalloc(4096)/kfree -> 65 cycles > 1 times kmalloc(8192)/kfree -> 60 cycles Hello, Christoph. I don't review in detail, but, at a glance, overall patchset looks good. But, above result looks odd. Improvement is beyond what we can expect. Do you have any idea why allocating object more than 256 bytes is so fast? Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at
Re: [PATCH] usb: host: max3421-hcd: use time_after()
Acked-by: David Mosberger
On Mon, Dec 15, 2014 at 8:22 AM, Asaf Vertz wrote:
> To be future-proof and for better readability the time comparisons are
> modified to use time_after() instead of plain, error-prone math.
>
> Signed-off-by: Asaf Vertz
> ---
> drivers/usb/host/max3421-hcd.c |3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/usb/host/max3421-hcd.c b/drivers/usb/host/max3421-hcd.c
> index 6234c75..aaaff94 100644
> --- a/drivers/usb/host/max3421-hcd.c
> +++ b/drivers/usb/host/max3421-hcd.c
> @@ -55,6 +55,7 @@
> * single thread (max3421_spi_thread).
> */
>
> +#include
> #include
> #include
> #include
> @@ -1291,7 +1292,7 @@ max3421_handle_irqs(struct usb_hcd *hcd)
> char sbuf[16 * 16], *dp, *end;
> int i;
>
> - if (jiffies - last_time > 5*HZ) {
> + if (time_after(jiffies, last_time + 5*HZ)) {
> dp = sbuf;
> end = sbuf + sizeof(sbuf);
> *dp = '\0';
> --
> 1.7.0.4
>
--
eGauge Systems LLC, http://egauge.net/, 1.877-EGAUGE1, fax 720.545.9768
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/3] mm: always steal split buddies in fallback allocations
On Fri, Dec 12, 2014 at 05:01:24PM +0100, Vlastimil Babka wrote:
> When allocation falls back to another migratetype, it will steal a page with
> highest available order, and (depending on this order and desired
> migratetype),
> it might also steal the rest of free pages from the same pageblock.
>
> Given the preference of highest available order, it is likely that it will be
> higher than the desired order, and result in the stolen buddy page being
> split.
> The remaining pages after split are currently stolen only when the rest of the
> free pages are stolen. This can however lead to situations where for MOVABLE
> allocations we split e.g. order-4 fallback UNMOVABLE page, but steal only
> order-0 page. Then on the next MOVABLE allocation (which may be batched to
> fill the pcplists) we split another order-3 or higher page, etc. By stealing
> all pages that we have split, we can avoid further stealing.
>
> This patch therefore adjusts the page stealing so that buddy pages created by
> split are always stolen. This has effect only on MOVABLE allocations, as
> RECLAIMABLE and UNMOVABLE allocations already always do that in addition to
> stealing the rest of free pages from the pageblock. The change also allows
> to simplify try_to_steal_freepages() and factor out CMA handling.
Maybe, this message should be fixed, because you reorder patches.
Thanks.
>
> According to Mel, it has been intended since the beginning that buddy pages
> after split would be stolen always, but it doesn't seem like it was ever the
> case until commit 47118af076f6 ("mm: mmzone: MIGRATE_CMA migration type
> added"). The commit has unintentionally introduced this behavior, but was
> reverted by commit 0cbef29a7821 ("mm: __rmqueue_fallback() should respect
> pageblock type"). Neither included evaluation.
>
> My evaluation with stress-highalloc from mmtests shows about 2.5x reduction
> of page stealing events for MOVABLE allocations, without affecting the page
> stealing events for other allocation migratetypes.
>
> Signed-off-by: Vlastimil Babka
> Acked-by: Mel Gorman
> Cc: Zhang Yanfei
> Acked-by: Minchan Kim
> Cc: David Rientjes
> Cc: Rik van Riel
> Cc: "Aneesh Kumar K.V"
> Cc: "Kirill A. Shutemov"
> Cc: Johannes Weiner
> Cc: Joonsoo Kim
> Cc: Michal Hocko
> Cc: KOSAKI Motohiro
> ---
> mm/page_alloc.c | 62
> +++--
> 1 file changed, 29 insertions(+), 33 deletions(-)
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index c32cb64..2cfd5d9 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1067,33 +1067,18 @@ static void change_pageblock_range(struct page
> *pageblock_page,
> /*
> * If breaking a large block of pages, move all free pages to the preferred
> * allocation list. If falling back for a reclaimable kernel allocation, be
> - * more aggressive about taking ownership of free pages.
> - *
> - * On the other hand, never change migration type of MIGRATE_CMA pageblocks
> - * nor move CMA pages to different free lists. We don't want unmovable pages
> - * to be allocated from MIGRATE_CMA areas.
> - *
> - * Returns the allocation migratetype if free pages were stolen, or the
> - * fallback migratetype if it was decided not to steal.
> + * more aggressive about taking ownership of free pages. If we claim more
> than
> + * half of the pageblock, change pageblock's migratetype as well.
> */
> -static int try_to_steal_freepages(struct zone *zone, struct page *page,
> +static void try_to_steal_freepages(struct zone *zone, struct page *page,
> int start_type, int fallback_type)
> {
> int current_order = page_order(page);
>
> - /*
> - * When borrowing from MIGRATE_CMA, we need to release the excess
> - * buddy pages to CMA itself. We also ensure the freepage_migratetype
> - * is set to CMA so it is returned to the correct freelist in case
> - * the page ends up being not actually allocated from the pcp lists.
> - */
> - if (is_migrate_cma(fallback_type))
> - return fallback_type;
> -
> /* Take ownership for orders >= pageblock_order */
> if (current_order >= pageblock_order) {
> change_pageblock_range(page, current_order, start_type);
> - return start_type;
> + return;
> }
>
> if (current_order >= pageblock_order / 2 ||
> @@ -1107,11 +1092,7 @@ static int try_to_steal_freepages(struct zone *zone,
> struct page *page,
> if (pages >= (1 << (pageblock_order-1)) ||
> page_group_by_mobility_disabled)
> set_pageblock_migratetype(page, start_type);
> -
> - return start_type;
> }
> -
> - return fallback_type;
> }
>
> /* Remove an element from the buddy allocator from the fallback list */
> @@ -1121,14 +1102,15 @@ __rmqueue_fallback(struct zone *zone, unsigned int
> order, int start_migratetype)
> struct
Re: [PATCH v2 0/3] page stealing tweaks
On Fri, Dec 12, 2014 at 05:01:22PM +0100, Vlastimil Babka wrote: > Changes since v1: > o Reorder patch 2 and 3, Cc stable for patch 1 > o Fix tracepoint in patch 1 (Joonsoo Kim) > o Cleanup in patch 2 (suggested by Minchan Kim) > o Improved comments and changelogs per Minchan and Mel. > o Considered /proc/pagetypeinfo in evaluation with 3.18 as baseline > > When studying page stealing, I noticed some weird looking decisions in > try_to_steal_freepages(). The first I assume is a bug (Patch 1), the following > two patches were driven by evaluation. > > Testing was done with stress-highalloc of mmtests, using the > mm_page_alloc_extfrag tracepoint and postprocessing to get counts of how often > page stealing occurs for individual migratetypes, and what migratetypes are > used for fallbacks. Arguably, the worst case of page stealing is when > UNMOVABLE allocation steals from MOVABLE pageblock. RECLAIMABLE allocation > stealing from MOVABLE allocation is also not ideal, so the goal is to minimize > these two cases. > > For some reason, the first patch increased the number of page stealing events > for MOVABLE allocations in the former evaluation with 3.17-rc7 + compaction > patches. In theory these events are not as bad, and the second patch does more > than just to correct this. In v2 evaluation based on 3.18, the weird result > was gone completely. > > In v2 I also checked if /proc/pagetypeinfo has shown an increase of the number > of unmovable/reclaimable pageblocks during and after the test, and it didn't. > The test was repeated 25 times with reboot only after each 5 to show > longer-term differences in the state of the system, which also wasn't the > case. > > Extfrag events summed over first iteration after reboot (5 repeats) > 3.183.18 > 3.183.18 >0-nothp-1 1-nothp-1 > 2-nothp-1 3-nothp-1 > Page alloc extfrag event4547160 4593415 > 2343438 2198189 > Extfrag fragmenting 4546361 4592610 > 2342595 2196611 > Extfrag fragmenting for unmovable 57259196 > 57201093 > Extfrag fragmenting unmovable placed with movable 38774091 > 1330 859 > Extfrag fragmenting for reclaimable 770 628 > 511 616 > Extfrag fragmenting reclaimable placed with movable 679 520 > 407 492 > Extfrag fragmenting for movable 4539866 4582786 > 2336364 2194902 > > Compared to v1 this looks like a regression for patch 1 wrt unmovable events, > but I blame noise and less repeats (it was 10 in v1). On the other hand, the > the mysterious increase in movable allocation events in v1 is gone (due to > different baseline?) Hmm... the result on patch 2 looks odd. Because you reorder patches, patch 2 have some effects on unmovable stealing and I expect that 'Extfrag fragmenting for unmovable' decreases. But, the result looks not. Is there any reason you think? And, could you share compaction success rate and allocation success rate on each iteration? In fact, reducing Extfrag event isn't our goal. It is natural result of this patchset because we steal pages more aggressively. Our utimate goal is to make the system less fragmented and to get more high order freepage, so I'd like to know this results. Thanks. > > Sum for second iterations since reboot: > 3.183.18 >3.183.18 > 0-nothp-2 1-nothp-2 > 2-nothp-2 3-nothp-2 > Page alloc extfrag event1960806 1682705 >868136 602097 > Extfrag fragmenting 1960268 1682153 >867624 601608 > Extfrag fragmenting for unmovable 14373 13973 > 122752158 > Extfrag fragmenting unmovable placed with movable 104657233 > 88141821 > Extfrag fragmenting for reclaimable22681244 > 11221284 > Extfrag fragmenting reclaimable placed with movable20921010 > 9401033 > Extfrag fragmenting for movable 1943627 1666936 >854227 598166 > > Running stress-highalloc again without reboot is indeed different, and worse > wrt unmovable allocations (also worse wrt high-order allocation success rates) > but the patches improve it as well. Similar trend can be observed for further > iterations after reboot. > > > > > > > > Vlastimil Babka (3): > mm: when stealing freepages, also take pages created by splitting > buddy page
Re: [Regression] 83f45fc turns machine's screen off
On Sun, Dec 14, 2014 at 02:07:19AM +0100, Emmanuel Benisty wrote: > Hi Daniel, > > > On Mon, Nov 10, 2014 at 10:19 PM, Daniel Vetter > > wrote: > >> Adding relevant mailing lists. > >> > >> > >> On Sat, Nov 8, 2014 at 7:34 PM, Emmanuel Benisty > >> wrote: > >>> Hi, > >>> > >>> The following commit permanently turns my screen off when x server is > >>> started (i3 330M Ironlake): > >>> > >>> [83f45fc360c8e16a330474860ebda872d1384c8c] drm: Don't grab an fb > >>> reference for the idr > >>> > >>> Reverting this commit fixed the issue. > >> > >> This is definitely unexpected. I think we need a bit more data to > >> figure out what's going on here: > >> - Please boot with drm.debug=0xe added to your kernel cmdline and grab > >> the dmesg right after boot-up for both a working or broken kernel. > > > > Please see attached files. > > > >> - Are you using any special i915 cmdline options? > > > > Nope. > > Is there anything else I could provide to help fixing this issue? It's > still in Linus' tree. Sorry for the delay. Absolutely no difference in the relevant parts of the log. There could be the chance that something is hidden somewhere, so can please grab a new set of logs but this time with drm.debug=0xe? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [V3 PATCH 4/4] scsi:stex.c Add S3/S4 support
On Mon, 2014-12-15 at 11:12 +0800, Charles Chiou wrote:
>
> On 12/10/2014 05:02 PM, Oliver Neukum wrote:
> > On Wed, 2014-12-10 at 09:38 +0800, Charles Chiou wrote:
> >> From 91868d4afe10533b8a4496075109e411100217bb Mon Sep 17 00:00:00 2001
> >> From: Charles Chiou
> >> Date: Fri, 7 Nov 2014 10:15:18 +0800
> >> Subject: [PATCH 4/4] scsi:stex.c Add S3/S4 support
> >>
> >> Add S3/S4 support, add .suspend and .resume function in pci_driver.
> >>
> >> Pegasus need 30~40 seconds to boot up. We don't want to OS wait
> >> in .resume function. Create a thread to handle device boot up.
> >>
> >
> >> +static int stex_resume(struct pci_dev *pdev)
> >> +{
> >> + struct st_hba *hba = pci_get_drvdata(pdev);
> >> + struct hba_handshake_workstruct *hswork;
> >> + int sts;
> >> +
> >> + hba->mu_status = MU_STATE_STARTING;
> >> + hswork = kzalloc(sizeof(struct hba_handshake_workstruct), GFP_KERNEL);
> >
> > The system is coming back from sleep. You cannot swap or page out
> > as disks may still be asleep. GFP_KERNEL is automatically changed
> > to GFP_NOIO. It would be nice to outright use GFP_NOIO.
> >
> >> + INIT_WORK(>handshake_work, resume_handshake);
> >
> > Memory allocations can fail.
> > I suggest you allocate the memory in suspend(). There you can just
> > return -ENOMEM in the error case.
> >
> >
> Hi Oliver, sorry for the late reply.
>
> Good point, could we move kzalloc function from suspend to probe and
> return -ENOMEM when allocation fail? We can avoid to allocate memory
> again and again in suspend/resume cycles.
Yes, that would work.
Regards
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [LKP] [mm] INFO: rcu_sched detected stalls on CPUs/tasks: { 1} (detected by 0, t=10002 jiffies, g=945, c=944, q=0)
On Mon, 2014-12-15 at 16:28 +0900, Joonsoo Kim wrote:
> On Thu, Dec 11, 2014 at 04:00:30PM +0800, Huang Ying wrote:
> > FYI, we noticed the below changes on
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git master
> > commit 6a7d22008b2294f1dacbc77632a26f2142f2d4b0 ("mm: Fix boot crash with
> > f7426b983a6a ("mm: cma: adjust address limit to avoid hitting low/high
> > memory boundary")")
> >
> > The original boot failures are fixed, but there are some boot hang now.
> > Sometimes because of OOM for trinity test.
>
> CCing relevant people.
>
> Hmm... My fix is just work-around to avoid validation when VA to PA
> conversion. So, it would be irrelevant to this problem. Blaming
> original patch makes more sense to me.
>
> Anyway, I looked at the original commit f7426b983a6a and found that
> it doesn't have any effect after reserving CMA region. Attached dmesg
> say that reservation is successful. So I wonder what cause this stall.
> Could you share your config to help debug?
The config is attached.
Best Regards,
Huang, Ying
> And, dmesg log also say that 16 MB is reserved for CMA. Is there any
> possibility this memory reservation cause this stall? Possibly, your
> OOM report is related to this reservation.
>
> Thanks.
>
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 3.18.0 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_PERF_EVENTS_INTEL_UNCORE=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
# CONFIG_ZONE_DMA32 is not set
# CONFIG_AUDIT_ARCH is not set
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_INTEL_MPX=y
CONFIG_X86_32_SMP=y
CONFIG_X86_HT=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-ecx -fcall-saved-edx"
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
CONFIG_KERNEL_XZ=y
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
# CONFIG_SYSVIPC is not set
# CONFIG_POSIX_MQUEUE is not set
CONFIG_CROSS_MEMORY_ATTACH=y
# CONFIG_FHANDLE is not set
CONFIG_USELIB=y
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
# CONFIG_AUDITSYSCALL is not set
#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_GENERIC_MSI_IRQ=y
CONFIG_GENERIC_MSI_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_DEBUG=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y
#
# Timers subsystem
#
CONFIG_HZ_PERIODIC=y
# CONFIG_NO_HZ_IDLE is not set
# CONFIG_NO_HZ is not set
# CONFIG_HIGH_RES_TIMERS is not set
#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_IRQ_TIME_ACCOUNTING is not set
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
# CONFIG_TASKS_RCU is not set
CONFIG_RCU_STALL_COMMON=y
CONFIG_RCU_FANOUT=32
CONFIG_RCU_FANOUT_LEAF=16
# CONFIG_RCU_FANOUT_EXACT is not set
# CONFIG_TREE_RCU_TRACE is not set
CONFIG_RCU_NOCB_CPU=y
# CONFIG_RCU_NOCB_CPU_NONE is not set
# CONFIG_RCU_NOCB_CPU_ZERO is not set
CONFIG_RCU_NOCB_CPU_ALL=y
CONFIG_BUILD_BIN2C=y
CONFIG_IKCONFIG=y
# CONFIG_IKCONFIG_PROC is not set
CONFIG_LOG_BUF_SHIFT=17
CONFIG_LOG_CPU_MAX_BUF_SHIFT=12
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_CGROUPS=y
# CONFIG_CGROUP_DEBUG is not set
CONFIG_CGROUP_FREEZER=y
CONFIG_CGROUP_DEVICE=y
# CONFIG_CPUSETS is not set
# CONFIG_CGROUP_CPUACCT is not set
# CONFIG_RESOURCE_COUNTERS is not
[PATCH 1/7] f2fs: remove checking dirty_exceed
We don't need to force to write dirty_exceeded for f2fs_balance_fs_bg.
This flag was only meaningful to write bypassing conditions.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/node.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
index f83326c..d6f073e 100644
--- a/fs/f2fs/node.c
+++ b/fs/f2fs/node.c
@@ -57,8 +57,6 @@ bool available_free_memory(struct f2fs_sb_info *sbi, int type)
} else if (type == INO_ENTRIES) {
int i;
- if (sbi->sb->s_bdi->dirty_exceeded)
- return false;
for (i = 0; i <= UPDATE_INO; i++)
mem_size += (sbi->im[i].ino_num *
sizeof(struct ino_entry)) >> PAGE_CACHE_SHIFT;
--
2.1.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/7] f2fs: change atomic and volatile write policies
This patch adds two new ioctls to release inmemory pages grabbed by atomic
writes.
o f2fs_ioc_abort_volatile_write
- If transaction was failed, all the grabbed pages and data should be written.
o f2fs_ioc_release_volatile_write
- This is to enhance the performance of PERSIST mode in sqlite.
In order to avoid huge memory consumption which causes OOM, this patch changes
volatile writes to use normal dirty pages, instead blocked flushing to the disk
as long as system does not suffer from memory pressure.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/data.c| 9 +--
fs/f2fs/f2fs.h| 8 ++
fs/f2fs/file.c| 77 +++
fs/f2fs/inode.c | 2 +-
fs/f2fs/node.c| 3 +++
fs/f2fs/node.h| 1 +
fs/f2fs/segment.c | 2 +-
7 files changed, 88 insertions(+), 14 deletions(-)
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 7ec697b..32264e3 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -814,6 +814,11 @@ static int f2fs_write_data_page(struct page *page,
write:
if (unlikely(sbi->por_doing))
goto redirty_out;
+ if (f2fs_is_drop_cache(inode))
+ goto out;
+ if (f2fs_is_volatile_file(inode) && !wbc->for_reclaim &&
+ available_free_memory(sbi, BASE_CHECK))
+ goto redirty_out;
/* Dentry blocks are controlled by checkpoint */
if (S_ISDIR(inode->i_mode)) {
@@ -1109,7 +1114,7 @@ static void f2fs_invalidate_data_page(struct page *page,
unsigned int offset,
if (offset % PAGE_CACHE_SIZE || length != PAGE_CACHE_SIZE)
return;
- if (f2fs_is_atomic_file(inode) || f2fs_is_volatile_file(inode))
+ if (f2fs_is_atomic_file(inode))
invalidate_inmem_page(inode, page);
if (PageDirty(page))
@@ -1132,7 +1137,7 @@ static int f2fs_set_data_page_dirty(struct page *page)
SetPageUptodate(page);
- if (f2fs_is_atomic_file(inode) || f2fs_is_volatile_file(inode)) {
+ if (f2fs_is_atomic_file(inode)) {
register_inmem_page(inode, page);
return 1;
}
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index ec58bb2..8c9bf3d 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -201,6 +201,8 @@ static inline bool __has_cursum_space(struct
f2fs_summary_block *sum, int size,
#define F2FS_IOC_START_ATOMIC_WRITE_IO(F2FS_IOCTL_MAGIC, 1)
#define F2FS_IOC_COMMIT_ATOMIC_WRITE _IO(F2FS_IOCTL_MAGIC, 2)
#define F2FS_IOC_START_VOLATILE_WRITE _IO(F2FS_IOCTL_MAGIC, 3)
+#define F2FS_IOC_RELEASE_VOLATILE_WRITE_IO(F2FS_IOCTL_MAGIC, 4)
+#define F2FS_IOC_ABORT_VOLATILE_WRITE _IO(F2FS_IOCTL_MAGIC, 5)
#if defined(__KERNEL__) && defined(CONFIG_COMPAT)
/*
@@ -1113,6 +1115,7 @@ enum {
FI_NEED_IPU,/* used for ipu per file */
FI_ATOMIC_FILE, /* indicate atomic file */
FI_VOLATILE_FILE, /* indicate volatile file */
+ FI_DROP_CACHE, /* drop dirty page cache */
FI_DATA_EXIST, /* indicate data exists */
};
@@ -1220,6 +1223,11 @@ static inline bool f2fs_is_volatile_file(struct inode
*inode)
return is_inode_flag_set(F2FS_I(inode), FI_VOLATILE_FILE);
}
+static inline bool f2fs_is_drop_cache(struct inode *inode)
+{
+ return is_inode_flag_set(F2FS_I(inode), FI_DROP_CACHE);
+}
+
static inline void *inline_data_addr(struct page *page)
{
struct f2fs_inode *ri = F2FS_INODE(page);
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index 3c27e0e..5139f90 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -836,6 +836,19 @@ static long f2fs_fallocate(struct file *file, int mode,
return ret;
}
+static int f2fs_release_file(struct inode *inode, struct file *filp)
+{
+ /* some remained atomic pages should discarded */
+ if (f2fs_is_atomic_file(inode))
+ commit_inmem_pages(inode, true);
+ if (f2fs_is_volatile_file(inode)) {
+ set_inode_flag(F2FS_I(inode), FI_DROP_CACHE);
+ filemap_fdatawrite(inode->i_mapping);
+ clear_inode_flag(F2FS_I(inode), FI_DROP_CACHE);
+ }
+ return 0;
+}
+
#define F2FS_REG_FLMASK(~(FS_DIRSYNC_FL | FS_TOPDIR_FL))
#define F2FS_OTHER_FLMASK (FS_NODUMP_FL | FS_NOATIME_FL)
@@ -909,26 +922,20 @@ out:
static int f2fs_ioc_start_atomic_write(struct file *filp)
{
struct inode *inode = file_inode(filp);
- struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
if (!inode_owner_or_capable(inode))
return -EACCES;
- f2fs_balance_fs(sbi);
+ f2fs_balance_fs(F2FS_I_SB(inode));
+
+ if (f2fs_is_atomic_file(inode))
+ return 0;
set_inode_flag(F2FS_I(inode), FI_ATOMIC_FILE);
return f2fs_convert_inline_inode(inode);
}
-static int f2fs_release_file(struct inode *inode, struct file *filp)
-{
- /* some remained atomic pages should discarded */
- if
[PATCH 3/7] f2fs: don't need to call lock_op and lock_page for abort
We don't need to call lock_op and lock_page at the aborting path.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/segment.c | 35 ---
1 file changed, 20 insertions(+), 15 deletions(-)
diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index 11e4b5c..3ce86c5 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -240,33 +240,38 @@ void commit_inmem_pages(struct inode *inode, bool abort)
* Otherwise, f2fs_gc in f2fs_balance_fs can wait forever until this
* inode becomes free by iget_locked in f2fs_iget.
*/
- if (!abort)
+ if (!abort) {
f2fs_balance_fs(sbi);
-
- f2fs_lock_op(sbi);
+ f2fs_lock_op(sbi);
+ }
mutex_lock(>inmem_lock);
list_for_each_entry_safe(cur, tmp, >inmem_pages, list) {
- lock_page(cur->page);
- if (!abort && cur->page->mapping == inode->i_mapping) {
- f2fs_wait_on_page_writeback(cur->page, DATA);
- if (clear_page_dirty_for_io(cur->page))
- inode_dec_dirty_pages(inode);
- do_write_data_page(cur->page, );
- submit_bio = true;
+ if (!abort) {
+ lock_page(cur->page);
+ if (cur->page->mapping == inode->i_mapping) {
+ f2fs_wait_on_page_writeback(cur->page, DATA);
+ if (clear_page_dirty_for_io(cur->page))
+ inode_dec_dirty_pages(inode);
+ do_write_data_page(cur->page, );
+ submit_bio = true;
+ }
+ f2fs_put_page(cur->page, 1);
+ } else {
+ put_page(cur->page);
}
radix_tree_delete(>inmem_root, cur->page->index);
- f2fs_put_page(cur->page, 1);
list_del(>list);
kmem_cache_free(inmem_entry_slab, cur);
dec_page_count(F2FS_I_SB(inode), F2FS_INMEM_PAGES);
}
- if (submit_bio)
- f2fs_submit_merged_bio(sbi, DATA, WRITE);
mutex_unlock(>inmem_lock);
- filemap_fdatawait_range(inode->i_mapping, 0, LLONG_MAX);
- f2fs_unlock_op(sbi);
+ if (!abort) {
+ f2fs_unlock_op(sbi);
+ if (submit_bio)
+ f2fs_submit_merged_bio(sbi, DATA, WRITE);
+ }
}
/*
--
2.1.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/7] f2fs: remove unnecessary call to invalidate inmemory pages
Now we use inmemory pages for atomic write only and provide abort procedure,
we don't need to truncate them explicitly.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/data.c| 3 ---
fs/f2fs/f2fs.h| 1 -
fs/f2fs/segment.c | 17 -
3 files changed, 21 deletions(-)
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 32264e3..caa08e4 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -1114,9 +1114,6 @@ static void f2fs_invalidate_data_page(struct page *page,
unsigned int offset,
if (offset % PAGE_CACHE_SIZE || length != PAGE_CACHE_SIZE)
return;
- if (f2fs_is_atomic_file(inode))
- invalidate_inmem_page(inode, page);
-
if (PageDirty(page))
inode_dec_dirty_pages(inode);
ClearPagePrivate(page);
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 8c9bf3d..d3699da 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -1397,7 +1397,6 @@ void destroy_node_manager_caches(void);
* segment.c
*/
void register_inmem_page(struct inode *, struct page *);
-void invalidate_inmem_page(struct inode *, struct page *);
void commit_inmem_pages(struct inode *, bool);
void f2fs_balance_fs(struct f2fs_sb_info *);
void f2fs_balance_fs_bg(struct f2fs_sb_info *);
diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index 335418c..3791fa9 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -205,23 +205,6 @@ retry:
mutex_unlock(>inmem_lock);
}
-void invalidate_inmem_page(struct inode *inode, struct page *page)
-{
- struct f2fs_inode_info *fi = F2FS_I(inode);
- struct inmem_pages *cur;
-
- mutex_lock(>inmem_lock);
- cur = radix_tree_lookup(>inmem_root, page->index);
- if (cur) {
- radix_tree_delete(>inmem_root, cur->page->index);
- f2fs_put_page(cur->page, 0);
- list_del(>list);
- kmem_cache_free(inmem_entry_slab, cur);
- dec_page_count(F2FS_I_SB(inode), F2FS_INMEM_PAGES);
- }
- mutex_unlock(>inmem_lock);
-}
-
void commit_inmem_pages(struct inode *inode, bool abort)
{
struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
--
2.1.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/7] f2fs: use missing the use of f2fs_kunmap_page
This patch calls f2fs_kunmap_page which I missed before. Signed-off-by: Jaegeuk Kim --- fs/f2fs/dir.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c index b1a7d57..b74097a 100644 --- a/fs/f2fs/dir.c +++ b/fs/f2fs/dir.c @@ -286,8 +286,7 @@ void f2fs_set_link(struct inode *dir, struct f2fs_dir_entry *de, f2fs_wait_on_page_writeback(page, type); de->ino = cpu_to_le32(inode->i_ino); set_de_type(de, inode); - if (!f2fs_has_inline_dentry(dir)) - kunmap(page); + f2fs_dentry_kunmap(dir, page); set_page_dirty(page); dir->i_mtime = dir->i_ctime = CURRENT_TIME; mark_inode_dirty(dir); -- 2.1.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/7] f2fs: fix small discards not to issue redundantly
The ckpt_valid_map and cur_valid_map are synced by seg_info_to_raw_sit.
In the case of small discards, the candidates are selected before sync,
while fitrim selects candidates after sync.
So, for small discards, we need to add candidates only just being obsoleted.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/segment.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index de9c070..335418c 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -525,7 +525,8 @@ static void add_discard_addrs(struct f2fs_sb_info *sbi,
struct cp_control *cpc)
bool force = (cpc->reason == CP_DISCARD);
int i;
- if (!force && !test_opt(sbi, DISCARD))
+ if (!force && (!test_opt(sbi, DISCARD) ||
+ SM_I(sbi)->nr_discards >= SM_I(sbi)->max_discards))
return;
if (force && !se->valid_blocks) {
@@ -553,7 +554,8 @@ static void add_discard_addrs(struct f2fs_sb_info *sbi,
struct cp_control *cpc)
/* SIT_VBLOCK_MAP_SIZE should be multiple of sizeof(unsigned long) */
for (i = 0; i < entries; i++)
- dmap[i] = ~(cur_map[i] | ckpt_map[i]);
+ dmap[i] = force ? ~ckpt_map[i] :
+ (cur_map[i] ^ ckpt_map[i]) & ckpt_map[i];
while (force || SM_I(sbi)->nr_discards <= SM_I(sbi)->max_discards) {
start = __find_rev_next_bit(dmap, max_blocks, end + 1);
@@ -1759,7 +1761,7 @@ void flush_sit_entries(struct f2fs_sb_info *sbi, struct
cp_control *cpc)
se = get_seg_entry(sbi, segno);
/* add discard candidates */
- if (SM_I(sbi)->nr_discards < SM_I(sbi)->max_discards) {
+ if (cpc->reason != CP_DISCARD) {
cpc->trim_start = segno;
add_discard_addrs(sbi, cpc);
}
--
2.1.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/7] f2fs: fix wrong condition check to trigger f2fs_sync_fs
If there is not enough available memory, we need to trigger f2fs_sync_fs. Signed-off-by: Jaegeuk Kim --- fs/f2fs/segment.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c index 42607a6..11e4b5c 100644 --- a/fs/f2fs/segment.c +++ b/fs/f2fs/segment.c @@ -290,7 +290,7 @@ void f2fs_balance_fs_bg(struct f2fs_sb_info *sbi) /* check the # of cached NAT entries and prefree segments */ if (try_to_free_nats(sbi, NAT_ENTRY_PER_BLOCK) || excess_prefree_segs(sbi) || - available_free_memory(sbi, INO_ENTRIES)) + !available_free_memory(sbi, INO_ENTRIES)) f2fs_sync_fs(sbi->sb, true); } -- 2.1.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [nohz] 2a16fc93d2c: kernel lockup on idle injection
Hi Viresh,
Let me explain why I think this is happening.
1. tick_nohz_irq_enter/exit() both get called *only if the cpu is idle*
and receives an interrupt.
2. Commit 2a16fc93d2c9568e1, cancels programming of tick_sched timer
in its handler, assuming that tick_nohz_irq_exit() will take care of
programming the clock event device appropriately, and hence it would
requeue or cancel the tick_sched timer.
3. But the intel_powerclamp driver injects an idle period only.
*The CPU however is not idle*. It has work on its runqueue and the
rq->curr != idle. This means that *tick_nohz_irq_enter()/exit() will not
get called on any interrupt*.
4. As a consequence, when we get a hrtimer interrupt during the period
that the powerclamp driver is mimicking idle, the exit path of the
interrupt never calls tick_nohz_irq_exit(). Hence the tick_sched timer
that would have got removed due to the above commit will not get
enqueued back on for any pending timers that there might be. Besides
this, *jiffies never gets updated*.
5. If you look at the code of the powerclamp driver, clamp_thread()
loops on jiffies getting updated. It continues to do so with preemption
disabled and no tick_sched timer to force a scheduler tick to update the
jiffies. Since this happens on cpus in a package, all of them get soft
lockedup.
Hope the above explanation makes sense.
Regards
Preeti U Murthy
On 12/12/2014 05:27 PM, Viresh Kumar wrote:
> Cc'ing Thomas as well..
>
> On 12 December 2014 at 01:12, Fengguang Wu wrote:
>> Hi Viresh,
>>
>> We noticed the below lockup regression on commit 2a16fc93d2c ("nohz:
>> Avoid tick's double reprogramming in highres mode").
>>
>> testbox/testcase/testparams: ivb42/idle-inject/60s-200%-10cp
>>
>> b5e995e671d8e4d7 2a16fc93d2c9568e16d45db77c
>> --
>>fail:runs %reproductionfail:runs
>>| | |
>>:5 100% 1:1 last_state.is_incomplete_run
>>:5 100% 1:1 last_state.running
>>
>> testbox/testcase/testparams: lkp-sb03/idle-inject/60s-200%-10cp
>>
>> b5e995e671d8e4d7 2a16fc93d2c9568e16d45db77c
>> --
>>:7 100% 1:1 last_state.is_incomplete_run
>>:7 100% 1:1 last_state.running
>>
>> Where test box ivb42 is Ivy Bridge-EP and lkp-sb03 is Sandy Bridge-EP.
>>
>> To reproduce:
>>
>> apt-get install ruby ruby-oj
>> git clone
>> git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
>> cd lkp-tests
>> bin/setup-local job.yaml # the job file attached in this email
>> bin/run-local job.yaml
>>
>> Basically what the test case does is to
>>
>> - find a Sandy Bridge or newer machine
>> - look for a cooling device with type “intel_powerclamp”
>> - set cur_state to 10
>> - run any CPU extensive workload
>>
>> Then expect soft lockup. It's very reproducible.
>
> Thanks Fengguang. Yes I am able to reproduce it, but don't know yet what
> went wrong..
>
> --
> viresh
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [LKP] [mm] INFO: rcu_sched detected stalls on CPUs/tasks: { 1} (detected by 0, t=10002 jiffies, g=945, c=944, q=0)
On Thu, Dec 11, 2014 at 04:00:30PM +0800, Huang Ying wrote:
> FYI, we noticed the below changes on
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git master
> commit 6a7d22008b2294f1dacbc77632a26f2142f2d4b0 ("mm: Fix boot crash with
> f7426b983a6a ("mm: cma: adjust address limit to avoid hitting low/high memory
> boundary")")
>
> The original boot failures are fixed, but there are some boot hang now.
> Sometimes because of OOM for trinity test.
CCing relevant people.
Hmm... My fix is just work-around to avoid validation when VA to PA
conversion. So, it would be irrelevant to this problem. Blaming
original patch makes more sense to me.
Anyway, I looked at the original commit f7426b983a6a and found that
it doesn't have any effect after reserving CMA region. Attached dmesg
say that reservation is successful. So I wonder what cause this stall.
Could you share your config to help debug?
And, dmesg log also say that 16 MB is reserved for CMA. Is there any
possibility this memory reservation cause this stall? Possibly, your
OOM report is related to this reservation.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] perf tools: fix type mismatch - long vs __statfs_word
On Tuesday 16 September 2014 08:46 PM, Alexey Brodkin wrote: > In case of compilation with "-Wextra" following breakage happens: > --->--- > fs.c: In function ‘fs__valid_mount’: > fs.c:76:24: error: comparison between signed and unsigned integer expressions > [-Werror=sign-compare] > else if (st_fs.f_type != magic) > ^ > cc1: all warnings being treated as errors > --->--- > > Note that now when fs.c is in "lib/api/fs" and in "tools/lib/api/Makefile" > CFLAGS has hard-coded "-Wextra" this is inevitable even if one builds "perf" > with "WERROR=0". > > Even though "debugfs.c" gets compiled successfully because DEBUGFS_MAGIC is > definitely positive (MSB bit is not set, so compiler doesn't care about > explisit cast to "long") it's good to cast "st_fs.f_type" to "long" as well. > > And here's an explanation of observed issue. > > Perf tools use libc headers instead of ones from kernel source tree. > This is because "perf" is just a user-space tool even thought its sources are > merged in Linux kernel source tree. > And so "statfs.h" comes from either uClibc, glibc or musl. > > In case of uClibc most of architectures use "legacy" version from here: > http://git.uclibc.org/uClibc/tree/libc/sysdeps/linux/common/bits/statfs.h > > New UAPI compliant architectures (looks like for now it's only ARC) uses UAPI > version of "statfs.h" from here: > http://git.uclibc.org/uClibc/tree/libc/sysdeps/linux/common-generic/bits/statfs.h > > In this particular situation most interesting difference is in data type used > for "struct statfs" member "f_type". > > In "legacy" version it's: > --->--- > __SWORD_TYPE f_type; > --->--- > > In UAPI version it's: > --->--- > __U32_TYPE f_type; > --->--- > > In its turn mentioned types are defined in > http://git.uclibc.org/uClibc/tree/libc/sysdeps/linux/common/bits/types.h > this way: > --->--- > ... > --->--- > > And for 32-bit architectures "int" is of the same length as "long" so compiler > is happy on data type check. > > But if "f_type" is "unsigned int" it's definitely not an unsigned "long". > > Essential fix is explicit casting of "f_type" to "long". > > Signed-off-by: Alexey Brodkin > > Cc: Vineet Gupta > Cc: Borislav Petkov > Cc: Jiri Olsa > Cc: Cody P Schafer > Cc: Arnaldo Carvalho de Melo > --- > > Changes in v2: > > * Added type cast to DEBUGFS_MAGIC in "debugfs.c" > * Added verbose explanation of root cause > > Thanks a lot to Arnaldo for mention of another instance of hidden missing > cast in "debugfs.c". > > --- > tools/lib/api/fs/debugfs.c | 2 +- > tools/lib/api/fs/fs.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/tools/lib/api/fs/debugfs.c b/tools/lib/api/fs/debugfs.c > index a74fba6..93aa4cd 100644 > --- a/tools/lib/api/fs/debugfs.c > +++ b/tools/lib/api/fs/debugfs.c > @@ -67,7 +67,7 @@ int debugfs_valid_mountpoint(const char *debugfs) > > if (statfs(debugfs, _fs) < 0) > return -ENOENT; > - else if (st_fs.f_type != (long) DEBUGFS_MAGIC) > + else if ((long) st_fs.f_type != (long) DEBUGFS_MAGIC) Hi Arnaldo, Does this fix look good to you. We need something like this to enable upstream ARC kernels to build perf. OTOH do we really need the cast on both sides for this 2nd hunk ? Thx, -Vineet > return -ENOENT; > > return 0; > diff --git a/tools/lib/api/fs/fs.c b/tools/lib/api/fs/fs.c > index c1b49c3..a9fd78b 100644 > --- a/tools/lib/api/fs/fs.c > +++ b/tools/lib/api/fs/fs.c > @@ -75,7 +75,7 @@ static int fs__valid_mount(const char *fs, long magic) > > if (statfs(fs, _fs) < 0) > return -ENOENT; > - else if (st_fs.f_type != magic) > + else if ((long) st_fs.f_type != magic) > return -ENOENT; > > return 0; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] usb: host: max3421-hcd: use time_after()
To be future-proof and for better readability the time comparisons are
modified to use time_after() instead of plain, error-prone math.
Signed-off-by: Asaf Vertz
---
drivers/usb/host/max3421-hcd.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/host/max3421-hcd.c b/drivers/usb/host/max3421-hcd.c
index 6234c75..aaaff94 100644
--- a/drivers/usb/host/max3421-hcd.c
+++ b/drivers/usb/host/max3421-hcd.c
@@ -55,6 +55,7 @@
* single thread (max3421_spi_thread).
*/
+#include
#include
#include
#include
@@ -1291,7 +1292,7 @@ max3421_handle_irqs(struct usb_hcd *hcd)
char sbuf[16 * 16], *dp, *end;
int i;
- if (jiffies - last_time > 5*HZ) {
+ if (time_after(jiffies, last_time + 5*HZ)) {
dp = sbuf;
end = sbuf + sizeof(sbuf);
*dp = '\0';
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC] clk: mxs: Fix invalid 32-bit access to frac registers
Hi, Am 14.12.2014 um 20:19 schrieb Marek Vasut: > On Sunday, December 14, 2014 at 06:16:17 PM, Stefan Wahren wrote: >>> [...] >>> >>> Also, it might be a good idea to zap the 0x3f mask and use HEX and DEC >>> numbers consistently, but this is an idea for another patch. >> Yes. >> >> Btw i hope this patch also fixes a SPI communication issue with our >> hardware which forces us to bypass ref_io1 for ssp2. >> But i will have access to that hardware tomorrow. > Which issue would that be please ? i've posted the issue in the Freescale Community [1]. > What are the symptoms ? Bits from the SPI slave are misinterpreted. BR Stefan [1] - https://community.freescale.com/thread/310434 > > Best regards, > Marek Vasut -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] pwm: kona: Fix incorrect enable, config, and disable procedures
On Wed, Dec 10, 2014 at 5:07 PM, Jonathan Richardson
wrote:
> If config is called when the pwm is disabled and there is nothing to do,
> the while loop to calculate duty cycle and period doesn't need to be
> done. The function now just returns if the pwm state is disabled.
It doesn't take long to figure out whether the duty and period are achievable.
If the caller specifies bad settings, why not return an error immediately?
> @@ -207,13 +240,23 @@ static void kona_pwmc_disable(struct pwm_chip *chip,
> struct pwm_device *pwm)
> {
> struct kona_pwmc *kp = to_kona_pwmc(chip);
> unsigned int chan = pwm->hwpwm;
> + unsigned int value = readl(kp->base + PWM_CONTROL_OFFSET);
> +
> + /* Set smooth type to 0 and disable */
> + value &= ~(1 << PWM_CONTROL_SMOOTH_SHIFT(chan));
> + value &= ~(1 << PWM_CONTROL_TRIGGER_SHIFT(chan));
> + writel(value, kp->base + PWM_CONTROL_OFFSET);
>
> /* Simulate a disable by configuring for zero duty */
> writel(0, kp->base + DUTY_CYCLE_HIGH_OFFSET(chan));
> - kona_pwmc_apply_settings(kp, chan);
> + writel(0, kp->base + PERIOD_COUNT_OFFSET(chan));
>
> - /* Wait for waveform to settle before gating off the clock */
> - ndelay(400);
> + /* Set prescale to 0 for this channel */
> + value = readl(kp->base + PRESCALE_OFFSET);
> + value &= ~PRESCALE_MASK(chan);
> + writel(value, kp->base + PRESCALE_OFFSET);
> +
> + kona_pwmc_apply_settings(kp, chan);
>
> clk_disable_unprepare(kp->clk);
> }
I've mentioned this before but I will say it again, when the smooth
and trigger bit are both low, the output is constant high.
If you look at the PWM output on a scope you will see it go high for
400 ns during your disable even if the duty prior to the disable was
zero.
How are you testing your proposed changes?
Thanks,
Tim Kryger
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Dec 15
Hi all, Please do not add any code destined for v3.20 to your linux-next included trees/branches until after v3.19-rc1 is released. Changes since 20141212: The tip tree gained a conflict against the pm tree. The rcu tree lost its build failure. The driver-core tree gained conflicts against Linus' and the watchdog trees. The staging tree gained a conflict against the vfs tree. The akpm-current tree gained a build failure due to a mismerge which I fixed up. The akpm tree lost several patches that turned up elsewhere. Non-merge commits (relative to Linus' tree): 4848 4434 files changed, 148881 insertions(+), 143746 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a multi_v7_defconfig for arm. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm defconfig. Below is a summary of the state of the merge. I am currently merging 231 trees (counting Linus' and 32 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (980f3c344ff1 Merge tag 'gpio-v3.19-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio) Merging fixes/master (b94d525e58dc Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging kbuild-current/rc-fixes (f114040e3ea6 Linux 3.18-rc1) Merging arc-current/for-curr (2ce7598c9a45 Linux 3.17-rc4) Merging arm-current/fixes (3f4aa45ceea5 ARM: 8226/1: cacheflush: get rid of restarting block) Merging m68k-current/for-linus (f0b99a643e96 m68k/mm: Eliminate memset after alloc_bootmem_pages) Merging metag-fixes/fixes (ffe6902b66aa asm-generic: remove _STK_LIM_MAX) Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5) Merging powerpc-merge/merge (31345e1a071e powerpc/pci: Remove unused force_32bit_msi quirk) Merging powerpc-merge-mpe/fixes (b2776bf7149b Linux 3.18) Merging sparc/master (f96fe225677b Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging net/master (f96fe225677b Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging ipsec/master (f855691975bb xfrm6: Fix the nexthdr offset in _decode_session6.) Merging sound-current/for-linus (0d3aba30b755 ALSA: oxfw: fix detect_loud_models() return value) Merging pci-current/for-linus (5106787a9e08 PCI: tegra: Use physical range for I/O mapping) Merging wireless/master (81c412600f94 Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless) Merging driver-core.current/driver-core-linus (206c5f60a3d9 Linux 3.18-rc4) Merging tty.current/tty-linus (009d0431c391 Linux 3.18-rc7) Merging usb.current/usb-linus (009d0431c391 Linux 3.18-rc7) Merging usb-gadget-fixes/fixes (520fe7633692 usb: dwc3: ep0: fix for dead code) Merging usb-serial-fixes/usb-linus (009d0431c391 Linux 3.18-rc7) Merging staging.current/staging-linus (009d0431c391 Linux 3.18-rc7) Merging char-misc.current/char-misc-linus (0df1f2487d2f Linux 3.18-rc3) Merging input-current/for-linus (a1f9a4072655 Input: xpad - use proper endpoint type) Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" stripe) Merging crypto-current/master (8606813a6c89 crypto: tcrypt - Allow speed testing of arbitrary hash functions) Merging ide/master (f96fe225677b Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff) Merging devicetree-current/devicetree/merge (094cb98179f1 of/fdt: memblock_reserve /memreserve/ regions in the case of partial overlap) Merging rr-fixes/fixes (3438cf549d2f param: fix crash on bad kernel arguments) Merging vfio-fixes/for-linus (239a87020b26 Merge branch 'for-joerg/arm-smmu/fixes' of
[git pull] drm for 3.19-rc1
Hi Linus, This is the main drm pull, as explained this was queued behind arm soc and iommu, the diffstat seems confused which worries me always, but I've git pull'ed this tree into yours and gotten a minor conflict in mm/hugetlb.c, which is easily solved. The -mm changes from the AMD HSA driver merge, all should be signed off properly. The rockchip iommu and some shmobile commits are in the stat below, but really shouldn't be, and I've pull the trees that I was told were stable, so hopefully its just git and not rebases. more info below, Dave. highlights: AMD KFD driver merge - this is the AMD HSA interface for exposing a lowlevel interface for GPGPU use. They have an open source userspace built on top of this interface, and the code looks as good as it was going to get out of tree. Initial atomic work, the need for an atomic modesetting interface to allow userspace to try and send a complete set of modesetting state to the driver has arisen, and been suffering from neglect this past year. No more, the start of the common code and changes for msm driver to use it are in this tree. Ongoing work to get the userspace ioctl finished and the code clean will probably wait until next kernel. DisplayID 1.3 and tiled monitor exposed to userspace. Tiled monitor property is now exposed for userspace to make use of. Rockchip drm driver merged. imx gpu driver moved out of staging Other stuff: core: panel - MIPI DSI + new panels. expose suggested x/y properties for virtual GPUs i915: Initial Skylake (SKL) support gen3/4 reset work start of dri1/ums removal infoframe tracking fixes for lots of things. nouveau: tegra k1 voltage support GM204 modesetting support GT21x memory reclocking work radeon: CI dpm fixes GPUVM improvements Initial DPM fan control rcar-du: HDMI support added removed some support for old boards slave encoder driver for Analog Devices adv7511 exynos: Exynos4415 SoC support msm: a4xx gpu support atomic helper conversion tegra: iommu support universal plane support ganged-mode DSI support sti: HDMI i2c improvements vmwgfx: some late fixes. qxl: use suggested x/y properties The following changes since commit b2776bf7149bddd1f4161f14f79520f17fc1d71d: Linux 3.18 (2014-12-07 14:21:05 -0800) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-next for you to fetch changes up to 4e0cd68115620bc3236ff4e58e4c073948629b41: drm: sti: fix module compilation issue (2014-12-15 17:07:57 +1000) Ajay Kumar (1): drm/panel: simple: Add AUO B116XW03 panel support Akash Goel (1): drm/i915/skl: Update in Gen9 multi-engine forcewake range Alex Deucher (33): drm/radeon/dpm: grab fan info from vbios drm/radeon: rework SI dpm thermal setup drm/radeon: rework CI dpm thermal setup drm/radeon: fix typo in CI dpm disable drm/radeon: export radeon_atombios_lookup_gpio drm/radeon: store the gpio shift as well drm/radeon/ci: handle gpio controlled dpm features properly drm/radeon: fix for memory training on bonaire 0x6649 drm/radeon: switch force state commands for CI drm/radeon: fix dram timing for certain hawaii boards drm/radeon: improve mclk param calcuations for ci dpm drm/radeon: fix activity settings for sclk and mclk for CI drm/radeon: fix sclk DS enablement drm/radeon: fix mclk vddc configuration for cards for hawaii drm/radeon: workaround a hw bug in bonaire pcie dpm drm/radeon: fix default dpm state setup drm/radeon: set bootup pcie level to max for ci dpm drm/radeon: fix dpm mc init for certain hawaii boards drm/radeon: powertune fixes for hawaii drm/radeon: set power control in ci dpm enable drm/radeon: work around a hw bug in MGCG on CIK drm/radeon/dpm: add smc fan control for SI (v2) drm/radeon/dpm: add smc fan control for CI (v2) drm/radeon/dpm: add thermal dpm support for CI drm/radeon: fix PCC debugging message for CI DPM drm/radeon/ci: apply disp voltage changes before clk changes drm/radeon/ci: use different smc command for pcie dpm drm/radeon/ci: force pcie level before sclk and mclk drm/radeon/ci: disable needless sclk changes drm/radeon: fix typo in new fan control registers for SI/CI drm/radeon: fix copy paste typos in fan control for si/ci drm/radeon: check the right ring in radeon_evict_flags() drm/radeon: enable smc fan control on CI Alexandre Courbot (9): drm/panel: ld9040: Update calls to gpiod_get*() drm/panel: s6e8aa0: Update calls to gpiod_get*() drm/panel: simple: Update calls to gpiod_get*() drm/nouveau: warn when moving a pinned object
[LKP] [genirq] c291ee62216:
]:/.tg_load_contrib 92 ± 42% +72.4%159 ± 19% sched_debug.cfs_rq[58]:/.blocked_load_avg 16297106 ± 4% +27.5% 20771822 ± 5% cpuidle.C1-NHM.time 453 ± 37% +47.9%670 ± 8% sched_debug.cfs_rq[31]:/.avg->runnable_avg_sum 8 ± 43% +54.3% 13 ± 8% sched_debug.cfs_rq[31]:/.tg_runnable_contrib 318 ± 10% +67.0%531 ± 42% sched_debug.cfs_rq[55]:/.exec_clock 1496 ± 14% +37.8% 2061 ± 13% sched_debug.cpu#37.sched_count 1466 ± 15% +37.8% 2019 ± 13% sched_debug.cpu#37.nr_switches 977 ± 14% +73.2% 1692 ± 49% sched_debug.cfs_rq[28]:/.exec_clock 830 ± 6% +22.0% 1013 ± 9% sched_debug.cpu#45.ttwu_count 613 ± 17% +42.8%876 ± 16% sched_debug.cpu#37.sched_goidle 8839 ± 7% -11.4% 7828 ± 10% sched_debug.cpu#3.ttwu_count 116654 ± 6% -12.7% 101799 ± 5% meminfo.DirectMap4k 1041 ± 6% +34.3% 1399 ± 27% sched_debug.cfs_rq[29]:/.exec_clock 6.66 ± 20%+175.2% 18.32 ± 2% time.system_time 16.79 ± 7% -48.0% 8.73 ± 1% time.user_time 7 ± 0% +17.9% 8 ± 5% time.percent_of_cpu_this_job_got 98436 ± 0% +1.6% 100045 ± 0% time.voluntary_context_switches lkp-nex04: Nehalem-EX Memory: 256G time.voluntary_context_switches 100500 ++-+ O OO O | | OO O | 10 ++ O O O O O O| |O O O O| | O | 99500 ++ | | | 99000 ++ | | | | | 98500 ++.*.*.. .*.. .*...*..*.. | *..*.*..*. *..*.*..*..*.*..*..*..*.*.**..* *.*..* | | 98000 ++-+ [*] bisect-good sample [O] bisect-bad sample To reproduce: apt-get install ruby ruby-oj git clone git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git cd lkp-tests bin/setup-local job.yaml # the job file attached in this email bin/run-local job.yaml Disclaimer: Results have been estimated based on internal Intel analysis and are provided for informational purposes only. Any difference in system hardware or software design or configuration may affect actual performance. Thanks, Fengguang --- testcase: netperf default_monitors: wait: pre-test uptime: iostat: vmstat: numa-numastat: numa-vmstat: numa-meminfo: proc-vmstat: proc-stat: meminfo: slabinfo: interrupts: lock_stat: latency_stats: softirqs: bdi_dev_mapping: diskstats: cpuidle: cpufreq: turbostat: sched_debug: interval: 10 pmeter: default_watchdogs: watch-oom: watchdog: cpufreq_governor: - performance commit: 057b16997d77a23a4dd2b8e8a9bd56656afac86d model: Nehalem-EX memory: 256G nr_ssd_partitions: 6 ssd_partitions: "/dev/disk/by-id/ata-INTEL_SSD*part1" swap_partitions: "/dev/disk/by-id/ata-WDC_WD10EARS-00Y5B1_WD-WCAV5F059074-part2" runtime: 300s nr_threads: - 200% perf-profile: freq: 800 netperf: test: - SCTP_STREAM testbox: lkp-nex04 tbox_group: lkp-nex04 kconfig: x86_64-rhel enqueue_time: 2014-12-14 00:52:11.886525322 +08:00 head_commit: 057b16997d77a23a4dd2b8e8a9bd56656afac86d base_commit: b2776bf7149bddd1f4161f14f79520f17fc1d71d branch: linux-devel/devel-hourly-2014121400 kernel: "/kernel/x86_64-rhel/057b16997d77a23a4dd2b8e8a9bd56656afac86d/vmlinuz-3.18.0-g057b169" user: lkp queue: cyclic rootfs: debian-x86_64.cgz result_root: "/result/lkp-nex04/netperf/performance-300s-200%-SCTP_STREAM/debian-x86_64.cgz/x86_64-rhel/057b16997d77a23a4dd2b8e8a9bd56656afac86d/0" job_file: "/lkp/scheduled/lkp-nex04/cyclic_netperf-performance-300s-200%-SCTP_STREAM-x86_64-rhel-HEAD-057b16997d77a23a4dd2b8e8a9bd56656afac86d-0.yaml" dequeue_time: 2014-12-14 08:50:11.387688351 +08:00 job_state: finished loadavg: 0.16 0.22 0.14 2/526 13068 start_time: '1418518283' end_time: '1418518586' version: "/lkp/lkp/.src-20141214-052354" echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor echo
Re: [v4,4/4] powernv: powerpc: Add winkle support for offline cpus
On Monday 15 December 2014 05:31 AM, Michael Ellerman wrote:
> On Sun, 2014-12-14 at 17:22 +0530, Shreyas B Prabhu wrote:
>> On Sunday 14 December 2014 03:35 PM, Michael Ellerman wrote:
diff --git a/arch/powerpc/platforms/powernv/subcore.h
b/arch/powerpc/platforms/powernv/subcore.h
index 148abc9..604eb40 100644
--- a/arch/powerpc/platforms/powernv/subcore.h
+++ b/arch/powerpc/platforms/powernv/subcore.h
@@ -15,4 +15,5 @@
#ifndef __ASSEMBLY__
void split_core_secondary_loop(u8 *state);
+extern void update_subcore_sibling_mask(void);
#endif
>>>
>>> subcore.c isn't built for CONFIG_SMP=n, resulting in:
>>>
>>> setup.c:(.init.text+0x34b0): undefined reference to
>>> `.update_subcore_sibling_mask'
>>>
>>> I needed to add:
>>>
>>> +#else
>>> +static inline void update_subcore_sibling_mask(void) { };
>>> +#endif /* CONFIG_SMP */
>
>> Sorry I missed that.
>
> No worries.
>
> Can you please do a quick test with a SMP=n kernel.
>
> It looks like it should work, but it would be good to test.
>
I successfully tested SMP=n kernel with your next branch.
Thanks,
Shreyas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: pxa: lubbock: use new cottula driver
On Mon, 15 Dec 2014 00:12:18 +0100, Robert Jarzmik wrote: > As the interrupt handling was transferred to the cottula driver, make > the switch in lubbock platform code. As the pxa25x itself is named Cotulla, the 'cottula' doesn't look like a good name for FPGA irq driver. > > Signed-off-by: Robert Jarzmik -- With best wishes Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH V3 1/1] Drivers: hv: vmbus: Fix a bug in vmbus_establish_gpadl()
> -Original Message- > From: Jeremiah Mahler [mailto:jmmah...@gmail.com] > Sent: Wednesday, December 10, 2014 6:10 PM > To: KY Srinivasan > Cc: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; > de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com; > jasow...@redhat.com; mc...@ipxe.org > Subject: Re: [PATCH V3 1/1] Drivers: hv: vmbus: Fix a bug in > vmbus_establish_gpadl() > > K. Y. Srinivasan, > > On Wed, Dec 10, 2014 at 05:13:00PM -0800, K. Y. Srinivasan wrote: > > Correctly compute the local (gpadl) handle. > > This description is still too sparse for me. How was it computed before and > why was this incorrect? Pretend like you are trying to explain your patch to > someone who has no idea what you did. > > > I would like to thank Michael Brown for seeing this bug. > > > > Signed-off-by: K. Y. Srinivasan > > Reported-by: Michael Brown > > --- > > Changes in V2: Added the Reported-by tag. > > Changes in V3: Cleaned up the commit log. > > > > drivers/hv/channel.c |4 ++-- > > 1 files changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c index > > 433f72a..c76ffbe 100644 > > --- a/drivers/hv/channel.c > > +++ b/drivers/hv/channel.c > > @@ -366,8 +366,8 @@ int vmbus_establish_gpadl(struct vmbus_channel > *channel, void *kbuffer, > > unsigned long flags; > > int ret = 0; > > > > - next_gpadl_handle = > atomic_read(_connection.next_gpadl_handle); > > - atomic_inc(_connection.next_gpadl_handle); > > + next_gpadl_handle = > > + > (atomic_inc_return(_connection.next_gpadl_handle) - 1); > > > Tell me if I understand this correctly. > > Before it read the handle and incremented it. > > y = x + 1 > > Now it reads the handle, increments it, then decrements it. > > y = (x + 1) - 1 = x This code can be executed concurrently on multiple CPUs. We want to ensure that each call to establish gpadl gets a unique local handle. The earlier code was buggy in that we would read the handle and then atomically increment it. Thus, multiple CPUs could read the identical current value which would be their local handle. What we want is the ability to atomically read and increment the value - this would ensure that each caller got a unique value even if they executed the code concurrently on multiple CPUs. The API atomic_inc_return(), atomically increments and returns the incremented value. We locally decrement this value to emulate the logic of "read the current value and atomically increment the value. Hope this helps, K. Y > > > ret = create_gpadl_header(kbuffer, size, , ); > > if (ret) > > -- > > 1.7.4.1 > > > > -- > > To unsubscribe from this list: send the line "unsubscribe > > linux-kernel" in the body of a message to majord...@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > Please read the FAQ at http://www.tux.org/lkml/ > > -- > - Jeremiah Mahler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[LKP] [sched] 05bfb65f52c: -5.2% thrulay.throughput
FYI, we noticed the below changes on
commit 05bfb65f52cbdabe26ebb629959416a6cffb034d ("sched: Remove a wake_affine()
condition")
testbox/testcase/testparams: ivb42/thrulay/performance-300s
afdeee0510db918b 05bfb65f52cbdabe26ebb62995
--
%stddev %change %stddev
\ |\
37071 ± 1% -5.2% 35155 ± 1% thrulay.throughput
9 ± 39%+294.4% 35 ± 45% sched_debug.cpu#41.cpu_load[4]
127 ± 43%+199.0%380 ± 33% sched_debug.cpu#30.curr->pid
89726 ± 35%+249.9% 313930 ± 40% sched_debug.cpu#12.sched_goidle
180377 ± 34%+248.9% 629297 ± 40% sched_debug.cpu#12.nr_switches
186401 ± 33%+239.4% 632605 ± 39% sched_debug.cpu#12.sched_count
467 ± 9% -51.9%224 ± 46%
sched_debug.cfs_rq[27]:/.tg_load_contrib
73 ± 13% -58.6% 30 ± 41% sched_debug.cpu#2.cpu_load[1]
97 ± 28% -59.1% 39 ± 47% sched_debug.cpu#11.load
30 ± 45% +86.1% 56 ± 26% sched_debug.cpu#9.cpu_load[2]
122 ± 37% -50.9% 60 ± 46% sched_debug.cpu#1.cpu_load[1]
16 ± 38%+100.0% 32 ± 31%
sched_debug.cfs_rq[41]:/.tg_runnable_contrib
782 ± 34% +93.8% 1517 ± 29%
sched_debug.cfs_rq[41]:/.avg->runnable_avg_sum
445 ± 31% -43.3%252 ± 35% sched_debug.cpu#11.curr->pid
5983 ± 11%+106.3% 12342 ± 12%
sched_debug.cfs_rq[12]:/.exec_clock
53 ± 24% -38.5% 32 ± 21% sched_debug.cpu#27.load
1636 ± 24% -42.9%934 ± 22% sched_debug.cpu#15.curr->pid
285 ± 48% -44.8%157 ± 33% sched_debug.cpu#26.curr->pid
8138 ± 9% +96.5% 15989 ± 11%
sched_debug.cfs_rq[12]:/.min_vruntime
174 ± 26% -46.4% 93 ± 25% sched_debug.cpu#15.load
55 ± 39% +49.8% 82 ± 28%
sched_debug.cfs_rq[35]:/.tg_load_contrib
47 ± 22% +82.1% 86 ± 28% sched_debug.cpu#6.cpu_load[2]
26 ± 22% -45.3% 14 ± 28% numa-numastat.node1.other_node
90 ± 24% -39.7% 54 ± 19% sched_debug.cpu#2.cpu_load[3]
24 ± 37% +76.5% 43 ± 6% sched_debug.cpu#32.cpu_load[4]
107188 ± 22% +46.3% 156809 ± 18% sched_debug.cpu#32.sched_count
409 ± 12% +54.5%633 ± 34% sched_debug.cpu#11.ttwu_local
131 ± 27% -43.5% 74 ± 39% sched_debug.cpu#1.cpu_load[2]
247 ± 32% +64.1%406 ± 29% sched_debug.cpu#2.curr->pid
89 ± 29% -55.3% 39 ± 47% sched_debug.cfs_rq[11]:/.load
83 ± 16% -50.7% 41 ± 26% sched_debug.cpu#2.cpu_load[2]
194662 ± 18% +49.5% 290986 ± 10% sched_debug.cpu#8.sched_count
24 ± 22% +75.5% 43 ± 25% sched_debug.cpu#31.cpu_load[1]
28 ± 46% +57.5% 44 ± 15% sched_debug.cpu#29.cpu_load[4]
70637 ± 23% +34.4% 94908 ± 17% sched_debug.cpu#27.ttwu_count
26 ± 40% +62.5% 42 ± 15% sched_debug.cpu#32.cpu_load[3]
65 ± 20% -30.2% 45 ± 19%
sched_debug.cfs_rq[26]:/.tg_runnable_contrib
3044 ± 20% -29.7% 2139 ± 19%
sched_debug.cfs_rq[26]:/.avg->runnable_avg_sum
28 ± 6% -33.0% 19 ± 16%
sched_debug.cfs_rq[39]:/.tg_runnable_contrib
1357 ± 6% -32.5%915 ± 17%
sched_debug.cfs_rq[39]:/.avg->runnable_avg_sum
277 ± 14% -38.6%170 ± 18%
sched_debug.cfs_rq[40]:/.runnable_load_avg
279 ± 14% -39.1%170 ± 18% sched_debug.cfs_rq[40]:/.load
575205 ± 11% +29.6% 745663 ± 10% sched_debug.cpu#11.avg_idle
151626 ± 19% +17.5% 178195 ± 13% sched_debug.cpu#3.ttwu_count
349553 ± 6% +33.4% 466210 ± 11% sched_debug.cpu#0.ttwu_count
133 ± 5% -29.6% 94 ± 26% sched_debug.cpu#40.cpu_load[3]
3767 ± 16% -28.8% 2680 ± 15% sched_debug.cpu#40.curr->pid
279 ± 14% -25.3%209 ± 9% sched_debug.cpu#40.load
39 ± 8% -24.7% 29 ± 7%
sched_debug.cfs_rq[15]:/.tg_runnable_contrib
1855 ± 7% -24.0% 1410 ± 6%
sched_debug.cfs_rq[15]:/.avg->runnable_avg_sum
309 ± 7% -32.9%207 ± 20% sched_debug.cpu#40.cpu_load[0]
213 ± 5% -32.4%144 ± 22% sched_debug.cpu#40.cpu_load[2]
602662 ± 11% +20.9% 728740 ± 7% sched_debug.cpu#30.avg_idle
84865 ± 16% +26.5% 107350 ± 8% sched_debug.cpu#26.ttwu_count
285 ± 6% -34.0%188 ± 20% sched_debug.cpu#40.cpu_load[1]
178498 ± 12% +21.2% 216368 ± 12% sched_debug.cpu#2.ttwu_count
5368 ± 9% +14.5% 6147 ± 9%
sched_debug.cfs_rq[28]:/.exec_clock
229046 ± 6% -10.9% 204016 ± 7% sched_debug.cpu#8.ttwu_count
716125 ± 9% +22.4% 876793 ± 4%
Re: linux-next: question about the commits in the vhost tree
On Mon, Dec 15, 2014 at 09:29:55AM +1100, Stephen Rothwell wrote: > Hi Michael, > > Just wondering if all those commits added to the vhost > (git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git#linux-next) > tree today are really destined for v3.19. Most of them fix static analysis warnings, so I thought they they should go there. If there are issues I'd like to know early. There is a new driver there that might not make it due to lack of testing: commit c9a04b96aa6af3a54b9b8d91782fb8f4415e2544 Author: Michael S. Tsirkin Date: Thu Dec 11 13:59:51 2014 +0200 virtio_pci: modern driver It compiles! Must be perfect. One thing *not* implemented here is separate mappings for descriptor/avail/used rings. That's nice to have, will be done later after we have core support. Signed-off-by: Michael S. Tsirkin and it's dependencies: commit fe13940bd8d00add4460c0a920d38d5f4385f0bb Author: Michael S. Tsirkin Date: Sun Dec 14 15:15:55 2014 +0200 virtio_pci: macros for PCI layout offsets. QEMU wants it, so why not? Trust, but verify. Signed-off-by: Rusty Russell commit 33028c00ddfb7bf433c9d020a7fd61f421daee76 Author: Rusty Russell Date: Wed May 29 11:52:22 2013 +0930 virtio-pci: define layout for virtio 1.0 Based on patches by Michael S. Tsirkin , but I found it hard to follow so changed to use structures which are more self-documenting. Signed-off-by: Rusty Russell Signed-off-by: Michael S. Tsirkin commit 772b824772ad7f015534671136addcd00082d246 Author: Michael S Tsirkin Date: Wed May 29 11:52:21 2013 +0930 s390: add pci_iomap_range Virtio drivers should map the part of the range they need, not necessarily all of it. To this end, support mapping ranges within BAR on s390. Since multiple ranges can now be mapped within a BAR, we keep track of the number of mappings created, and only clear out the mapping for a BAR when this number reaches 0. Signed-off-by: Michael S. Tsirkin commit 85f88e2d98c1bc6f34c3b625de2d9abfefdcde9d Author: Michael S Tsirkin Date: Wed May 29 11:52:21 2013 +0930 pci: add pci_iomap_range Virtio drivers should map the part of the BAR they need, not necessarily all of it. Signed-off-by: Michael S. Tsirkin Signed-off-by: Rusty Russell but they are well contained so I was hoping putting them in linux-next will not harm anyone and help more people test it. > -- > Cheers, > Stephen Rothwells...@canb.auug.org.au -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kernel: sysctl: use 'unsigned long' type for 'zero' variable
On 12/13/2014 11:51 PM, Manfred Spraul wrote:
> Hi,
>
> On 12/04/2014 12:25 AM, Andrew Morton wrote:
>> On Wed, 03 Dec 2014 15:41:21 +0300 Andrey Ryabinin
>> wrote:
>>
>>> Use the 'unsigned long' type for 'zero' variable to fix this.
>>> Changing type to 'unsigned long' shouldn't affect any other users
>>> of this variable.
>>>
>>> Reported-by: Dmitry Vyukov
>>> Fixes: ed4d4902ebdd ("mm, hugetlb: remove hugetlb_zero and
>>> hugetlb_infinity")
>>> Signed-off-by: Andrey Ryabinin
>>> ---
>>> kernel/sysctl.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/kernel/sysctl.c b/kernel/sysctl.c
>>> index 15f2511..45c45c9 100644
>>> --- a/kernel/sysctl.c
>>> +++ b/kernel/sysctl.c
>>> @@ -120,7 +120,7 @@ static int sixty = 60;
>>> static int __maybe_unused neg_one = -1;
>>> -static int zero;
>>> +static unsigned long zero;
>
> After some (useless) playing around (see the attached patch):
>
> Using
>>.extra1=zero,
> for proc_doulongvec_minmax doesn't make any sense:
>
> __do_proc_doulongvec_minmax() internally contains
>> if ((min && val < *min) || (max && val > *max))
>> continue;
>
> What about just deleting the offending .extra1=zero line?
> .extra1=NULL has the same effect as .extra1=
>
Agreed, I think this should work.
> --
> Manfred
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure
On Fri, Dec 12, 2014 at 09:41:11PM +0200, Laurent Pinchart wrote: > (Resend, as the message doesn't seem to have made it to the mailing lists) > > On Thursday 11 December 2014 01:16:31 Kuninori Morimoto wrote: > > > > On Mon, Dec 08, 2014 at 11:20:44PM +0530, Vinod Koul wrote: > > > > > On Mon, Dec 08, 2014 at 07:40:15PM +0200, Laurent Pinchart wrote: > > > > [GIT PULL FOR v3.19] R-Car DMA engine driver > > > > http://www.spinics.net/lists/linux-sh/msg37764.html > > > > >>> > > > > >>> And I dont seem to have this request in my Inbox :( > > > > >>> Yes I do see it in archieves, so not sure how this is not present, > > > > >>> not sure if the servers mangeled it!! > > > > >> > > > > >> I haven't CC'ed you, I'll make sure to do so next time. The mail > > > > >> should still have reached you through the mailing list though (I > > > > >> assume you're subscribed to dmaeng...@vger.kernel.org ;-)). > > > > > > > > > > Yes I am, so should have reached me even though i wasnt cced > > > > > I do see email reaching me from list without me being in CC, but then > > > > > it wont hit my inbox and go to ML folder :) > > > > > So generally its a good practice to CC relvant folks, lots of folks do > > > > > ask that if ML is high volume > > > > > > > > Hey Laurent, > > > > > > > > I see that the oddity in commitlogs with change since artifacts after > > > > SOB, can you please fix that up > > > > > > My bad. I've fixed the problem and pushed the result to the same branch > > > > > > git://linuxtv.org/pinchartl/fbdev.git dma/next > > > > > > The only difference lies in the commit logs. > > > > If my understanding was correct, we need to be based on Vinod's > > topic/slave_caps_device_control_fix > > Vinod, could you please comment on that ? To which kernel version do you plan > to push this series ? Do I need to rebase it ? Hi Laurent, I did a quick at the series, looks fine mostly. I have already sent by pull request to linus earlier last week and its merged, so we need to merge it for next one. So yes we need to fix and test this for caps and control API fix. Can you do that and I will pull and put in my next for 3.20 One more thing I saw in driver "dmaengine: rcar-dmac: Add Renesas R-Car Gen2 DMA Controller (DMAC) driver" is the CONFIG_ARCH_DMA_ADDR_T_64BIT code. Can you please explain a bit more on it, why do you need to modify addresses based on config option? -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: frequent lockups in 3.18rc4
On Sun, Dec 14, 2014 at 08:20:13PM -0500, Sasha Levin wrote:
> On 12/14/2014 07:11 PM, Paul E. McKenney wrote:
> >> Does it depend on anything not currently in -next? My build fails with
> >> >
> >> > kernel/rcu/tree.c: In function ‘rcu_report_qs_rdp’:
> >> > kernel/rcu/tree.c:2099:6: error: ‘struct rcu_data’ has no member named
> >> > ‘gpwrap’
> >> >rdp->gpwrap) {
> > Indeed it does. Please see below for a port to current mainline.
>
> With the patch:
>
>
> [ 620.340045] INFO: rcu_preempt detected stalls on CPUs/tasks:
> [ 620.341087] (detected by 22, t=8407 jiffies, g=10452, c=10451, q=3622)
> [ 620.342154] All QSes seen, last rcu_preempt kthread activity
> 4294990929/4294999330, jiffies_till_next_fqs=1
OK, 8401 jiffies since the grace-period kthread ran. This is without
the "Run grace-period kthreads at real-time priority" patch?
> [ 643.710049] INFO: rcu_preempt detected stalls on CPUs/tasks:
> [ 643.710073] INFO: rcu_sched detected stalls on CPUs/tasks:
> [ 643.710093] 0: (6 ticks this GP) idle=bd5/142/0
> softirq=12421/12421 fqs=0 last_accelerate: 5283/8643, nonlazy_posted: 643841,
> ..
> [ 643.710110] (detected by 1, t=2102 jiffies, g=-292, c=-293, q=0)
But this one is real.
> [ 643.710112] Task dump for CPU 0:
> [ 643.710129] kworker/0:1 R running task13016 628 2
> 0x10080008
> [ 643.710148] Workqueue: events vmstat_update
> [ 643.710156] b0301dc4 88006be15000 880060ba1c70
>
> [ 643.710161] 88006be10680 8800633efde8 a0461f1b
> 88006a776000
> [ 643.710166] 880060ba1cb8 880060ba1c78 880060ba1c80
> 880060ba1c90
> [ 643.710168] Call Trace:
> [ 643.710181] [] ? _raw_spin_unlock_irq+0x64/0x200
> [ 643.710191] [] ? process_one_work+0x5fb/0x1660
> [ 643.710197] [] ? worker_thread+0x5c5/0x1680
> [ 643.710205] [] ? __schedule+0xf6f/0x2fc0
> [ 643.710211] [] ? process_one_work+0x1660/0x1660
> [ 643.710216] [] ? kthread+0x1f2/0x2b0
> [ 643.710221] [] ? kthread_worker_fn+0x6a0/0x6a0
> [ 643.710226] [] ? ret_from_fork+0x7c/0xb0
> [ 643.710233] [] ? kthread_worker_fn+0x6a0/0x6a0
Which in theory should have been addressed by the "Make
cond_resched_rcu_qs() apply to normal RCU flavors" patch,
given that this is CPU 0, which should be taking scheduling
clock interrupts. Well, I guess that theory and practice
are only the same in theory. :-/
Will dig into it more.
Thanx, Paul
> [ 643.711486]
> [ 643.711486] (detected by 22, t=2104 jiffies, g=10453, c=10452, q=1570)
> [ 643.711486] All QSes seen, last rcu_preempt kthread activity
> 4294999565/4295001669, jiffies_till_next_fqs=1
>
>
> Thanks,
> Sasha
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v15 00/12] input: cyapa: instruction of cyapa patches
Jeremiah, Thanks for your review and comments. I have updated v15 based on your comments and suggestions. Could you help review again please. Thank you very much, Dudley > -Original Message- > From: linux-input-ow...@vger.kernel.org > [mailto:linux-input-ow...@vger.kernel.org] On Behalf Of Dudley Du > Sent: 2014?12?15? 14:23 > To: dmitry.torok...@gmail.com; rydb...@euromail.se > Cc: Dudley Du; ble...@google.com; David Solda; linux-in...@vger.kernel.org; > linux-kernel@vger.kernel.org > Subject: [PATCH v15 00/12] input: cyapa: instruction of cyapa patches > > V15 patches have below updates, details of other updates see history list: > 1) Fix all warning errors of sparse tool when running with "make C=1". > 2) Change variable name "unique_str" to "product_id" for clearer meanings. Also 3) Update cyapa_i2c_write function to return error directly when length > 31. > > > This patch series is aimed to re-design the cyapa driver to support > old gen3 trackpad devices and new gen5 trackpad devices in one > cyapa driver, it's for easily productions support based on > customers' requirements. And add sysfs functions and interfaces > supported that required by users and customers. > > Since the earlier gen3 and the latest gen5 trackpad devices using > two different chipsets, and have different protocols and interfaces, > so if supported these two type trackpad devices in two different drivers, > then it will be difficult to manage productions and later firmware updates. > e.g.: It will cause customer don't know which one trackpad device firmware > image to use and update when it has been used and integrated > in same one productions, so here we support these two trackpad > devices in same on driver. > > The new design cyapa driver contains: > cyapa.c - the core of the re-design, supply interfaces and > functions to system and read trackpad devices. > cyapa.h - header file including macros and data structure definitions. > cyapa_gen3.c - functions support for gen3 trackpad devices, > cyapa_gen5.c - functions support for gen5 trackpad devices. > > Beside this introduction patch, it has 12 patches listed as below. > For these patches, each one is patched based on previous one. > > patch 1/12: re-design cyapa driver with core functions and interface > to support multi-type trackpad devices. > > patch 2/12: add gen5 trackpad device basic functions supported into the > re-design cyapa driver. > > patch 3/12: add power management interfaces supported for the device. > > patch 4/12: add runtime power management interfaces supported for the device. > > patch 5/12: add sysfs interfaces supported in the cyapa driver. > Including read firmware version, get production ID, read baseline, > re-calibrate trackpad baselines and do trackpad firmware update. > > patch 6/12: add gen3 trackpad device's firmware update function supported. > > patch 7/12: add gen3 trackpad device's read baseline function supported. > > patch 8/12: add gen3 trackpad device's force re-calibrate function supported. > > patch 9/12: add gen5 trackpad device's firmware update function supported. > > patch 10/12: add gen5 trackpad device's read baseline function supported. > > patch 11/12: add gen5 trackpad device's force re-calibrate function. > > patch 12/12: add acpi device id supported. > > > History patch series modifications list: > V14 patches have below main updates compared with v13 patches: > 1) Correct 9 miss spelling issues of "bufferred" to "buffered". > 2) Fix the upgrade issue of removing MOUSE_CYAPA config when make oldconfig >by replase "depends on I2C && CRC_ITU_T" with > "depends on I2C" > "select CRC_ITU_T" >in patch 9. > > V13 patches have below main updates compared with v12 patches: > 1) Remove all debugfs interface, including read_fw and raw_data interfaces. > 2) This patches are made based linux next-20141208. > > V12 patches have below main updates compared with v11 patches: > 1) Add check that when TP is detected but not operational, do not exit driver >immediately, but wait and export the update_fw interface for recovering. > 2) Re-arrange the function codes, remove unnesseary protype definitions in >the header file. > > V11 patches have below main updates compared with v10 patches: > 1) Add add acpi device id supported for old gen3 and new gen5 trackpad > devices. > 2) Fix the unable to update firmware issue when cyapa_open is not called >which means the irq for firwmare update process is not enabled. This fix >by checking if the irq is enabled, if not then enable irq before start to >do firmware update. > > V10 patches have below main updates compared with v9 patches: > 1) Modify code to following kernel code style. >e.g.: correct to use error as return name when there is only error path, >and fix the checkpatch.sh wanting in the driver. > 2) Remove cyapa_remove method and use input open and close interface to >following device resouse management infrastructure. > 3) Modify
linux-next: build failure after merge of the akpm-current tree
Hi Andrew,
After merging the akpm-current tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
mm/oom_kill.c:257:20: error: redefinition of 'task_will_free_mem'
static inline bool task_will_free_mem(struct task_struct *task)
^
In file included from /scratch/sfr/next/mm/oom_kill.c:20:0:
include/linux/oom.h:90:20: note: previous definition of 'task_will_free_mem'
was here
static inline bool task_will_free_mem(struct task_struct *task)
^
Caused by commit 4bf284e597a4 ("oom: don't assume that a coredumping
thread will exit soon") from the akpm-current tree interacting with the
version that finally went into Linus' tree (commit d003f371b270 ("oom:
don't assume that a coredumping thread will exit soon")).
I removed the definition of task_will_free_mem() from the akpm-current
tree version.
Andrew: this sort of thing could be avoided if the actual set of
patches that you send to Linus were present in linux-next (even for a
day). :-(
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgp3a9Q55DxHM.pgp
Description: OpenPGP digital signature
Re: [PATCH v3 0/5] ARM64: Add kernel probes(Kprobes) support
On 12/12/14 18:10, Steve Capper wrote:
On 12 December 2014 at 22:42, David Long wrote:
On 12/10/14 11:38, Steve Capper wrote:
On Tue, Dec 09, 2014 at 09:27:18AM -0500, David Long wrote:
On 12/09/14 08:33, Steve Capper wrote:
On Thu, Dec 04, 2014 at 08:53:03PM +0900, Masami Hiramatsu wrote:
[...]
Not sure if this is helpful, but the following also caused a crash for
me:
echo "p:trace_event_buffer_lock_reserve trace_event_buffer_lock_reserve"
/sys/kernel/debug/tracing/kprobe_events
echo "p:memcpy memcpy" >> /sys/kernel/debug/tracing/kprobe_events
echo 1 > /sys/kernel/debug/tracing/events/kprobes/enable
[immediate crash]
The crash point for me is in the arm64 ASID allocator, it again looks
like the interrupts are in an unexpected state.
(check_and_switch_context goes down the irqs disabled code path, I
think incorrectly).
This occurred for me both with and without the proposed irq saving fix.
I will do some more digging.
Thanks, more information is good.
Hi,
Some good news, I think I've fixed the problem I've been experiencing.
Basically, I've torn out all the interrupt save/restore and have
narrowed the scope to just sandwich the instruction single-step. This
simplifies a lot of logic, and I've now been able to perf record a
kprobe on memcpy (and the trace_event_buffer_lock_reserve + memcpy
test) without any issues on a Juno platform.
I may have been somewhat over-zealous with the chainsaw, so please do
put this fix through its paces.
Cheers,
--
Steve
From d3f4d80ce19bec71bd03209beb2fbfd8084d6543 Mon Sep 17 00:00:00 2001
From: Steve Capper
Date: Mon, 1 Dec 2014 11:30:10 +
Subject: [PATCH] Fix the interrupt handling for kprobes
---
arch/arm64/kernel/kprobes.c | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git a/arch/arm64/kernel/kprobes.c b/arch/arm64/kernel/kprobes.c
index be7c330..d39d826 100644
--- a/arch/arm64/kernel/kprobes.c
+++ b/arch/arm64/kernel/kprobes.c
@@ -229,10 +229,6 @@ skip_singlestep_missed(struct kprobe_ctlblk *kcb,
struct pt_regs *regs)
{
/* set return addr to next pc to continue */
instruction_pointer(regs) += sizeof(kprobe_opcode_t);
-
- if (kcb->kprobe_status != KPROBE_REENTER)
- kprobes_restore_local_irqflag(regs);
-
}
static void __kprobes setup_singlestep(struct kprobe *p,
@@ -259,7 +255,7 @@ static void __kprobes setup_singlestep(struct kprobe
*p,
spsr_set_debug_flag(regs, 0);
/* IRQs and single stepping do not mix well. */
- local_irq_disable();
+ kprobes_save_local_irqflag(regs);
kernel_enable_single_step(regs);
instruction_pointer(regs) = slot;
} else {
@@ -326,7 +322,6 @@ post_kprobe_handler(struct kprobe_ctlblk *kcb, struct
pt_regs *regs)
}
reset_current_kprobe();
- kprobes_restore_local_irqflag(regs);
}
int __kprobes kprobe_fault_handler(struct pt_regs *regs, unsigned int
fsr)
@@ -380,8 +375,6 @@ int __kprobes kprobe_fault_handler(struct pt_regs
*regs, unsigned int fsr)
return 1;
break;
- default:
- break;
}
return 0;
}
@@ -446,7 +439,6 @@ void __kprobes kprobe_handler(struct pt_regs *regs)
* handling of this interrupt is appropriate.
* Return back to original instruction, and continue.
*/
- kprobes_restore_local_irqflag(regs);
return;
} else if (cur) {
/* We probably hit a jprobe. Call its break handler. */
@@ -459,7 +451,6 @@ void __kprobes kprobe_handler(struct pt_regs *regs)
/* breakpoint is removed, now in a race
* Return back to original instruction & continue.
*/
- kprobes_restore_local_irqflag(regs);
}
}
@@ -485,6 +476,7 @@ kprobe_single_step_handler(struct pt_regs *regs,
unsigned int esr)
retval = kprobe_ss_hit(kcb, instruction_pointer(regs));
if (retval == DBG_HOOK_HANDLED) {
+ kprobes_restore_local_irqflag(regs);
kernel_disable_single_step();
if (kcb->kprobe_status == KPROBE_REENTER)
@@ -499,7 +491,6 @@ kprobe_single_step_handler(struct pt_regs *regs,
unsigned int esr)
static int __kprobes
kprobe_breakpoint_handler(struct pt_regs *regs, unsigned int esr)
{
- kprobes_save_local_irqflag(regs);
kprobe_handler(regs);
return DBG_HOOK_HANDLED;
}
@@ -563,7 +554,6 @@ int __kprobes longjmp_break_handler(struct kprobe *p,
struct pt_regs *regs)
memcpy((void *)stack_addr, kcb->jprobes_stack,
MIN_STACK_SIZE(stack_addr));
preempt_enable_no_resched();
- kprobes_restore_local_irqflag(regs);
return 1;
}
return 0;
@@ -655,8 +645,6 @@
[PATCH v15 12/12] input: cyapa: add acpi device id supported
Add acpi device tree supported.
acpi device id "CYAP" is for old gen3 trackpad devices.
acpi device id "CYAP0001" is for new gen5 trackpad devices.
TEST=test on Chromebooks.
Signed-off-by: Dudley Du
---
drivers/input/mouse/cyapa.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/input/mouse/cyapa.c b/drivers/input/mouse/cyapa.c
index dac3996..9fb97e2 100644
--- a/drivers/input/mouse/cyapa.c
+++ b/drivers/input/mouse/cyapa.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include "cyapa.h"
@@ -1315,11 +1316,23 @@ static const struct i2c_device_id cyapa_id_table[] = {
};
MODULE_DEVICE_TABLE(i2c, cyapa_id_table);
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id cyapa_acpi_id[] = {
+ { "CYAP", 0 }, /* Gen3 trackpad with 0x67 I2C address. */
+ { "CYAP0001", 0 }, /* Gen5 trackpad with 0x24 I2C address. */
+ { }
+};
+MODULE_DEVICE_TABLE(acpi, cyapa_acpi_id);
+#endif
+
static struct i2c_driver cyapa_driver = {
.driver = {
.name = "cyapa",
.owner = THIS_MODULE,
.pm = _pm_ops,
+#ifdef CONFIG_ACPI
+ .acpi_match_table = ACPI_PTR(cyapa_acpi_id),
+#endif
},
.probe = cyapa_probe,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v15 07/12] input: cyapa: add gen3 trackpad device read baseline function support
Add read baseline function supported for gen3 trackpad device,
it can be used through sysfs baseline interface.
TEST=test on Chromebooks.
Signed-off-by: Dudley Du
---
drivers/input/mouse/cyapa_gen3.c | 71
1 file changed, 71 insertions(+)
diff --git a/drivers/input/mouse/cyapa_gen3.c b/drivers/input/mouse/cyapa_gen3.c
index 9851337..f42e008 100644
--- a/drivers/input/mouse/cyapa_gen3.c
+++ b/drivers/input/mouse/cyapa_gen3.c
@@ -754,6 +754,75 @@ static int cyapa_gen3_do_fw_update(struct cyapa *cyapa,
return 0;
}
+static ssize_t cyapa_gen3_show_baseline(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct cyapa *cyapa = dev_get_drvdata(dev);
+ int max_baseline, min_baseline;
+ int tries = 3;
+ int ret;
+
+ ret = cyapa_read_byte(cyapa, CYAPA_CMD_DEV_STATUS);
+ if (ret < 0) {
+ dev_err(dev, "Error reading dev status. err = %d\n", ret);
+ goto out;
+ }
+ if ((ret & CYAPA_DEV_NORMAL) != CYAPA_DEV_NORMAL) {
+ dev_warn(dev, "Trackpad device is busy. device state = 0x%x\n",
+ret);
+ ret = -EAGAIN;
+ goto out;
+ }
+
+ ret = cyapa_write_byte(cyapa, CYAPA_CMD_SOFT_RESET,
+ OP_REPORT_BASELINE_MASK);
+ if (ret < 0) {
+ dev_err(dev, "Failed to send report baseline command. %d\n",
+ ret);
+ goto out;
+ }
+
+ do {
+ usleep_range(1, 2);
+
+ ret = cyapa_read_byte(cyapa, CYAPA_CMD_DEV_STATUS);
+ if (ret < 0) {
+ dev_err(dev, "Error reading dev status. err = %d\n",
+ ret);
+ goto out;
+ }
+ if ((ret & CYAPA_DEV_NORMAL) == CYAPA_DEV_NORMAL)
+ break;
+ } while (--tries);
+
+ if (tries == 0) {
+ dev_err(dev, "Device timed out going to Normal state.\n");
+ ret = -ETIMEDOUT;
+ goto out;
+ }
+
+ ret = cyapa_read_byte(cyapa, CYAPA_CMD_MAX_BASELINE);
+ if (ret < 0) {
+ dev_err(dev, "Failed to read max baseline. err = %d\n", ret);
+ goto out;
+ }
+ max_baseline = ret;
+
+ ret = cyapa_read_byte(cyapa, CYAPA_CMD_MIN_BASELINE);
+ if (ret < 0) {
+ dev_err(dev, "Failed to read min baseline. err = %d\n", ret);
+ goto out;
+ }
+ min_baseline = ret;
+
+ dev_dbg(dev, "Baseline report successful. Max: %d Min: %d\n",
+ max_baseline, min_baseline);
+ ret = scnprintf(buf, PAGE_SIZE, "%d %d\n", max_baseline, min_baseline);
+
+out:
+ return ret;
+}
+
/*
* cyapa_get_wait_time_for_pwr_cmd
*
@@ -1067,6 +1136,8 @@ const struct cyapa_dev_ops cyapa_gen3_ops = {
.update_fw = cyapa_gen3_do_fw_update,
.bl_deactivate = cyapa_gen3_bl_deactivate,
+ .show_baseline = cyapa_gen3_show_baseline,
+
.state_parse = cyapa_gen3_state_parse,
.operational_check = cyapa_gen3_do_operational_check,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v15 10/12] input: cyapa: add gen5 trackpad device read baseline function support
Add read baseline function supported for gen5 trackpad device,
it can be used through sysfs baseline interface.
TEST=test on Chromebooks.
Signed-off-by: Dudley Du
---
drivers/input/mouse/cyapa.h | 2 +
drivers/input/mouse/cyapa_gen5.c | 621 +++
2 files changed, 623 insertions(+)
diff --git a/drivers/input/mouse/cyapa.h b/drivers/input/mouse/cyapa.h
index bf0bbd9..4f1fc89 100644
--- a/drivers/input/mouse/cyapa.h
+++ b/drivers/input/mouse/cyapa.h
@@ -285,6 +285,8 @@ struct cyapa {
u8 y_origin; /* Y Axis Origin: 0 = top; 1 = bottom. */
int electrodes_x; /* Number of electrodes on the X Axis*/
int electrodes_y; /* Number of electrodes on the Y Axis*/
+ int electrodes_rx; /* Number of Rx electrodes */
+ int algined_electrodes_rx; /* 4 aligned */
int max_z;
/*
diff --git a/drivers/input/mouse/cyapa_gen5.c b/drivers/input/mouse/cyapa_gen5.c
index e89a952..3c87ad4 100644
--- a/drivers/input/mouse/cyapa_gen5.c
+++ b/drivers/input/mouse/cyapa_gen5.c
@@ -1533,6 +1533,625 @@ static int cyapa_gen5_set_power_mode(struct cyapa
*cyapa,
return 0;
}
+static int cyapa_gen5_resume_scanning(struct cyapa *cyapa)
+{
+ u8 cmd[7] = { 0x04, 0x00, 0x05, 0x00, 0x2f, 0x00, 0x04 };
+ u8 resp_data[6];
+ int resp_len;
+ int error;
+
+ /* Try to dump all buffered data before doing command. */
+ cyapa_empty_pip_output_data(cyapa, NULL, NULL, NULL);
+
+ resp_len = 6;
+ error = cyapa_i2c_pip_cmd_irq_sync(cyapa,
+ cmd, 7,
+ resp_data, _len,
+ 500, cyapa_gen5_sort_tsg_pip_app_resp_data, true);
+ if (error || !VALID_CMD_RESP_HEADER(resp_data, 0x04))
+ return -EINVAL;
+
+ /* Try to dump all buffered data when resuming scanning. */
+ cyapa_empty_pip_output_data(cyapa, NULL, NULL, NULL);
+
+ return 0;
+}
+
+static int cyapa_gen5_suspend_scanning(struct cyapa *cyapa)
+{
+ u8 cmd[7] = { 0x04, 0x00, 0x05, 0x00, 0x2f, 0x00, 0x03 };
+ u8 resp_data[6];
+ int resp_len;
+ int error;
+
+ /* Try to dump all buffered data before doing command. */
+ cyapa_empty_pip_output_data(cyapa, NULL, NULL, NULL);
+
+ resp_len = 6;
+ error = cyapa_i2c_pip_cmd_irq_sync(cyapa,
+ cmd, 7,
+ resp_data, _len,
+ 500, cyapa_gen5_sort_tsg_pip_app_resp_data, true);
+ if (error || !VALID_CMD_RESP_HEADER(resp_data, 0x03))
+ return -EINVAL;
+
+ /* Try to dump all buffered data when suspending scanning. */
+ cyapa_empty_pip_output_data(cyapa, NULL, NULL, NULL);
+
+ return 0;
+}
+
+static s32 two_complement_to_s32(s32 value, int num_bits)
+{
+ if (value >> (num_bits - 1))
+ value |= -1 << num_bits;
+ return value;
+}
+
+static s32 cyapa_parse_structure_data(u8 data_format, u8 *buf, int buf_len)
+{
+ int data_size;
+ bool big_endian;
+ bool unsigned_type;
+ s32 value;
+
+ data_size = (data_format & 0x07);
+ big_endian = ((data_format & 0x10) == 0x00);
+ unsigned_type = ((data_format & 0x20) == 0x00);
+
+ if (buf_len < data_size)
+ return 0;
+
+ switch (data_size) {
+ case 1:
+ value = buf[0];
+ break;
+ case 2:
+ if (big_endian)
+ value = get_unaligned_be16(buf);
+ else
+ value = get_unaligned_le16(buf);
+ break;
+ case 4:
+ if (big_endian)
+ value = get_unaligned_be32(buf);
+ else
+ value = get_unaligned_le32(buf);
+ break;
+ default:
+ /* Should not happen, just as default case here. */
+ value = 0;
+ break;
+ }
+
+ if (!unsigned_type)
+ value = two_complement_to_s32(value, data_size * 8);
+
+ return value;
+}
+
+
+/*
+ * Read all the global mutual or self idac data or mutual or self local PWC
+ * data based on the @idac_data_type.
+ * If the input value of @data_size is 0, then means read global mutual or
+ * self idac data. For read global mutual idac data, @idac_max, @idac_min and
+ * @idac_ave are in order used to return the max value of global mutual idac
+ * data, the min value of global mutual idac and the average value of the
+ * global mutual idac data. For read global self idac data, @idac_max is used
+ * to return the global self cap idac data in Rx direction, @idac_min is used
+ * to return the global self cap idac data in Tx direction. @idac_ave is not
+ * used.
+ * If the input value of @data_size is not 0, than means read the mutual or
+ * self local PWC data. The @idac_max, @idac_min and @idac_ave are used to
+ * return the max, min and average value of the mutual or
[PATCH v15 11/12] input: cyapa: add gen5 trackpad device force re-calibrate function support
Add force re-calibrate function supported for gen5 trackpad device,
it can be used through sysfs calibrate interface.
TEST=test on Chromebooks.
Signed-off-by: Dudley Du
---
drivers/input/mouse/cyapa_gen5.c | 65
1 file changed, 65 insertions(+)
diff --git a/drivers/input/mouse/cyapa_gen5.c b/drivers/input/mouse/cyapa_gen5.c
index 3c87ad4..e16330d 100644
--- a/drivers/input/mouse/cyapa_gen5.c
+++ b/drivers/input/mouse/cyapa_gen5.c
@@ -1581,6 +1581,70 @@ static int cyapa_gen5_suspend_scanning(struct cyapa
*cyapa)
return 0;
}
+static int cyapa_gen5_calibrate_pwcs(struct cyapa *cyapa,
+ u8 calibrate_sensing_mode_type)
+{
+ u8 cmd[8];
+ u8 resp_data[6];
+ int resp_len;
+ int error;
+
+ /* Try to dump all buffered data before doing command. */
+ cyapa_empty_pip_output_data(cyapa, NULL, NULL, NULL);
+
+ cmd[0] = 0x04;
+ cmd[1] = 0x00;
+ cmd[2] = 0x06;
+ cmd[3] = 0x00;
+ cmd[4] = GEN5_APP_CMD_REPORT_ID;
+ cmd[5] = 0x00;
+ cmd[6] = GEN5_CMD_CALIBRATE;
+ cmd[7] = calibrate_sensing_mode_type;
+ resp_len = sizeof(resp_data);
+ error = cyapa_i2c_pip_cmd_irq_sync(cyapa,
+ cmd, sizeof(cmd),
+ resp_data, _len,
+ 5000, cyapa_gen5_sort_tsg_pip_app_resp_data, true);
+ if (error || !VALID_CMD_RESP_HEADER(resp_data, GEN5_CMD_CALIBRATE) ||
+ !GEN5_CMD_COMPLETE_SUCCESS(resp_data[5]))
+ return error < 0 ? error : -EAGAIN;
+
+ return 0;
+}
+
+static ssize_t cyapa_gen5_do_calibrate(struct device *dev,
+struct device_attribute *attr,
+const char *buf, size_t count)
+{
+ struct cyapa *cyapa = dev_get_drvdata(dev);
+ int error, calibrate_error;
+
+ /* 1. Suspend Scanning*/
+ error = cyapa_gen5_suspend_scanning(cyapa);
+ if (error)
+ return error;
+
+ /* 2. Do mutual capacitance fine calibrate. */
+ calibrate_error = cyapa_gen5_calibrate_pwcs(cyapa,
+ CYAPA_SENSING_MODE_MUTUAL_CAP_FINE);
+ if (calibrate_error)
+ goto resume_scanning;
+
+ /* 3. Do self capacitance calibrate. */
+ calibrate_error = cyapa_gen5_calibrate_pwcs(cyapa,
+ CYAPA_SENSING_MODE_SELF_CAP);
+ if (calibrate_error)
+ goto resume_scanning;
+
+resume_scanning:
+ /* 4. Resume Scanning*/
+ error = cyapa_gen5_resume_scanning(cyapa);
+ if (error || calibrate_error)
+ return error ? error : calibrate_error;
+
+ return count;
+}
+
static s32 two_complement_to_s32(s32 value, int num_bits)
{
if (value >> (num_bits - 1))
@@ -2558,6 +2622,7 @@ const struct cyapa_dev_ops cyapa_gen5_ops = {
.update_fw = cyapa_gen5_do_fw_update,
.show_baseline = cyapa_gen5_show_baseline,
+ .calibrate_store = cyapa_gen5_do_calibrate,
.initialize = cyapa_gen5_initialize,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v15 08/12] input: cyapa: add gen3 trackpad device force re-calibrate function support
Add force re-calibrate function supported for gen3 trackpad device,
it can be used through sysfs calibrate interface.
TEST=test on Chromebooks.
Signed-off-by: Dudley Du
---
drivers/input/mouse/cyapa_gen3.c | 58
1 file changed, 58 insertions(+)
diff --git a/drivers/input/mouse/cyapa_gen3.c b/drivers/input/mouse/cyapa_gen3.c
index f42e008..836a00b 100644
--- a/drivers/input/mouse/cyapa_gen3.c
+++ b/drivers/input/mouse/cyapa_gen3.c
@@ -754,6 +754,63 @@ static int cyapa_gen3_do_fw_update(struct cyapa *cyapa,
return 0;
}
+static ssize_t cyapa_gen3_do_calibrate(struct device *dev,
+struct device_attribute *attr,
+const char *buf, size_t count)
+{
+ struct cyapa *cyapa = dev_get_drvdata(dev);
+ int tries = 20; /* max recalibration timeout 2s. */
+ int ret;
+
+ ret = cyapa_read_byte(cyapa, CYAPA_CMD_DEV_STATUS);
+ if (ret < 0) {
+ dev_err(dev, "Error reading dev status: %d\n", ret);
+ goto out;
+ }
+ if ((ret & CYAPA_DEV_NORMAL) != CYAPA_DEV_NORMAL) {
+ dev_warn(dev, "Trackpad device is busy, device state: 0x%02x\n",
+ret);
+ ret = -EAGAIN;
+ goto out;
+ }
+
+ ret = cyapa_write_byte(cyapa, CYAPA_CMD_SOFT_RESET,
+ OP_RECALIBRATION_MASK);
+ if (ret < 0) {
+ dev_err(dev, "Failed to send calibrate command: %d\n",
+ ret);
+ goto out;
+ }
+
+ do {
+ /*
+* For this recalibration, the max time will not exceed 2s.
+* The average time is approximately 500 - 700 ms, and we
+* will check the status every 100 - 200ms.
+*/
+ usleep_range(10, 20);
+
+ ret = cyapa_read_byte(cyapa, CYAPA_CMD_DEV_STATUS);
+ if (ret < 0) {
+ dev_err(dev, "Error reading dev status: %d\n",
+ ret);
+ goto out;
+ }
+ if ((ret & CYAPA_DEV_NORMAL) == CYAPA_DEV_NORMAL)
+ break;
+ } while (--tries);
+
+ if (tries == 0) {
+ dev_err(dev, "Failed to calibrate. Timeout.\n");
+ ret = -ETIMEDOUT;
+ goto out;
+ }
+ dev_dbg(dev, "Calibration successful.\n");
+
+out:
+ return ret < 0 ? ret : count;
+}
+
static ssize_t cyapa_gen3_show_baseline(struct device *dev,
struct device_attribute *attr, char *buf)
{
@@ -1137,6 +1194,7 @@ const struct cyapa_dev_ops cyapa_gen3_ops = {
.bl_deactivate = cyapa_gen3_bl_deactivate,
.show_baseline = cyapa_gen3_show_baseline,
+ .calibrate_store = cyapa_gen3_do_calibrate,
.state_parse = cyapa_gen3_state_parse,
.operational_check = cyapa_gen3_do_operational_check,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v15 09/12] input: cyapa: add gen5 trackpad device firmware update function support
Add firmware image update function supported for gen5 trackpad device,
it can be used through sysfs update_fw interface.
TEST=test on Chromebooks.
Signed-off-by: Dudley Du
---
drivers/input/mouse/Kconfig | 1 +
drivers/input/mouse/cyapa_gen5.c | 292 ++-
2 files changed, 292 insertions(+), 1 deletion(-)
diff --git a/drivers/input/mouse/Kconfig b/drivers/input/mouse/Kconfig
index d8b46b0..728490e 100644
--- a/drivers/input/mouse/Kconfig
+++ b/drivers/input/mouse/Kconfig
@@ -206,6 +206,7 @@ config MOUSE_BCM5974
config MOUSE_CYAPA
tristate "Cypress APA I2C Trackpad support"
depends on I2C
+ select CRC_ITU_T
help
This driver adds support for Cypress All Points Addressable (APA)
I2C Trackpads, including the ones used in 2012 Samsung Chromebooks.
diff --git a/drivers/input/mouse/cyapa_gen5.c b/drivers/input/mouse/cyapa_gen5.c
index 1ac264d..e89a952 100644
--- a/drivers/input/mouse/cyapa_gen5.c
+++ b/drivers/input/mouse/cyapa_gen5.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include "cyapa.h"
@@ -911,7 +912,87 @@ static int cyapa_gen5_state_parse(struct cyapa *cyapa, u8
*reg_data, int len)
return -EAGAIN;
}
-bool cyapa_gen5_sort_bl_exit_data(struct cyapa *cyapa, u8 *buf, int len)
+static int cyapa_gen5_bl_initiate(struct cyapa *cyapa,
+ const struct firmware *fw)
+{
+ u16 length = 0;
+ u16 data_len = 0;
+ u16 meta_data_crc = 0;
+ u16 cmd_crc = 0;
+ u8 bl_gen5_activate[18 + CYAPA_TSG_FLASH_MAP_BLOCK_SIZE + 3];
+ int bl_gen5_activate_size = 0;
+ u8 resp_data[11];
+ int resp_len;
+ struct cyapa_tsg_bin_image *image;
+ int records_num;
+ u8 *data;
+ int error;
+
+ /* Try to dump all buffered report data before send any command. */
+ cyapa_empty_pip_output_data(cyapa, NULL, NULL, NULL);
+
+ bl_gen5_activate_size = sizeof(bl_gen5_activate);
+ memset(bl_gen5_activate, 0, bl_gen5_activate_size);
+
+ /* Output Report Register Address[15:0] = 0004h */
+ bl_gen5_activate[0] = 0x04;
+ bl_gen5_activate[1] = 0x00;
+
+ /* Total command length[15:0] */
+ length = bl_gen5_activate_size - 2;
+ put_unaligned_le16(length, _gen5_activate[2]);
+ bl_gen5_activate[4] = 0x40; /* Report ID = 40h */
+ bl_gen5_activate[5] = 0x00; /* RSVD = 00h */
+
+ bl_gen5_activate[6] = GEN5_SOP_KEY; /* SOP = 01h */
+ bl_gen5_activate[7] = 0x48; /* Command Code = 48h */
+
+ /* 8 Key bytes and block size */
+ data_len = CYAPA_TSG_BL_KEY_SIZE + CYAPA_TSG_FLASH_MAP_BLOCK_SIZE;
+ /* Data Length[15:0] */
+ put_unaligned_le16(data_len, _gen5_activate[8]);
+ bl_gen5_activate[10] = 0xa5; /* Key Byte 0 */
+ bl_gen5_activate[11] = 0x01;
+ bl_gen5_activate[12] = 0x02; /* . */
+ bl_gen5_activate[13] = 0x03; /* . */
+ bl_gen5_activate[14] = 0xff; /* . */
+ bl_gen5_activate[15] = 0xfe;
+ bl_gen5_activate[16] = 0xfd;
+ bl_gen5_activate[17] = 0x5a; /* Key Byte 7 */
+
+ /* Copy 60 bytes Meta Data Row Parameters */
+ image = (struct cyapa_tsg_bin_image *)fw->data;
+ records_num = (fw->size - sizeof(struct cyapa_tsg_bin_image_head)) /
+ sizeof(struct cyapa_tsg_bin_image_data_record);
+ /* APP_INTEGRITY row is always the last row block */
+ data = image->records[records_num - 1].record_data;
+ memcpy(_gen5_activate[18], data, CYAPA_TSG_FLASH_MAP_METADATA_SIZE);
+
+ meta_data_crc = crc_itu_t(0x, _gen5_activate[18],
+ CYAPA_TSG_FLASH_MAP_METADATA_SIZE);
+ /* Meta Data CRC[15:0] */
+ put_unaligned_le16(meta_data_crc,
+ _gen5_activate[18 + CYAPA_TSG_FLASH_MAP_METADATA_SIZE]);
+
+ cmd_crc = crc_itu_t(0x, _gen5_activate[6], 4 + data_len);
+ put_unaligned_le16(cmd_crc,
+ _gen5_activate[bl_gen5_activate_size - 3]); /* CRC[15:0] */
+ bl_gen5_activate[bl_gen5_activate_size - 1] = GEN5_EOP_KEY;
+
+ resp_len = sizeof(resp_data);
+ error = cyapa_i2c_pip_cmd_irq_sync(cyapa,
+ bl_gen5_activate, sizeof(bl_gen5_activate),
+ resp_data, _len, 12000,
+ cyapa_gen5_sort_tsg_pip_bl_resp_data, true);
+ if (error || resp_len != GEN5_BL_INITIATE_RESP_LEN ||
+ resp_data[2] != GEN5_BL_RESP_REPORT_ID ||
+ !GEN5_CMD_COMPLETE_SUCCESS(resp_data[5]))
+ return error ? error : -EAGAIN;
+
+ return 0;
+}
+
+static bool cyapa_gen5_sort_bl_exit_data(struct cyapa *cyapa, u8 *buf, int len)
{
if (buf == NULL || len < GEN5_RESP_LENGTH_SIZE)
return false;
@@ -960,6 +1041,210 @@ static int cyapa_gen5_bl_exit(struct cyapa *cyapa)
return -ENODEV;
}
+static int
[PATCH v15 04/12] input: cyapa: add runtime power management interfaces supported for the device
Add runtime_suspend_scanrate_ms power management interfaces in device's
power group, so users or applications can control the runtime power
management strategy of trackpad device as their requirements.
TEST=test on Chromebooks.
Signed-off-by: Dudley Du
---
drivers/input/mouse/cyapa.c | 171 +++-
drivers/input/mouse/cyapa.h | 4 ++
2 files changed, 174 insertions(+), 1 deletion(-)
diff --git a/drivers/input/mouse/cyapa.c b/drivers/input/mouse/cyapa.c
index 73f6817..3bcfce3 100644
--- a/drivers/input/mouse/cyapa.c
+++ b/drivers/input/mouse/cyapa.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include "cyapa.h"
@@ -327,6 +328,8 @@ static int cyapa_open(struct input_dev *input)
}
enable_irq(client->irq);
+ pm_runtime_set_active(>dev);
+ pm_runtime_enable(>dev);
out:
mutex_unlock(>state_sync_lock);
return error;
@@ -340,8 +343,10 @@ static void cyapa_close(struct input_dev *input)
mutex_lock(>state_sync_lock);
disable_irq(client->irq);
+ pm_runtime_disable(>dev);
if (!CYAPA_BOOTLOADER(cyapa) && cyapa->ops->set_power_mode)
cyapa->ops->set_power_mode(cyapa, PWR_MODE_OFF, 0);
+ pm_runtime_set_suspended(>dev);
mutex_unlock(>state_sync_lock);
}
@@ -542,6 +547,7 @@ static irqreturn_t cyapa_irq(int irq, void *dev_id)
struct device *dev = >client->dev;
bool cont;
+ pm_runtime_get_sync(dev);
if (device_may_wakeup(dev))
pm_wakeup_event(dev, 0);
@@ -572,6 +578,8 @@ static irqreturn_t cyapa_irq(int irq, void *dev_id)
}
out:
+ pm_runtime_mark_last_busy(dev);
+ pm_runtime_put_sync_autosuspend(dev);
return IRQ_HANDLED;
}
@@ -665,6 +673,116 @@ static void cyapa_remove_power_wakeup_group(void *data)
}
#endif /* CONFIG_PM_SLEEP */
+#ifdef CONFIG_PM_RUNTIME
+static ssize_t cyapa_show_rt_suspend_scanrate(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct cyapa *cyapa = dev_get_drvdata(dev);
+ u8 pwr_cmd;
+ u16 sleep_time;
+ int error;
+
+ error = mutex_lock_interruptible(>state_sync_lock);
+ if (error)
+ return error;
+ pwr_cmd = cyapa->runtime_suspend_power_mode;
+ sleep_time = cyapa->runtime_suspend_sleep_time;
+ mutex_unlock(>state_sync_lock);
+
+ if (cyapa->gen == CYAPA_GEN3)
+ return scnprintf(buf, PAGE_SIZE, "%u\n",
+ cyapa_pwr_cmd_to_sleep_time(pwr_cmd));
+ return scnprintf(buf, PAGE_SIZE, "%u\n", sleep_time);
+}
+
+static ssize_t cyapa_update_rt_suspend_scanrate(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct cyapa *cyapa = dev_get_drvdata(dev);
+ u16 time;
+ int error;
+
+ if (buf == NULL || count == 0 || kstrtou16(buf, 10, )) {
+ dev_err(dev, "invalid runtime suspend scanrate ms parameter\n");
+ return -EINVAL;
+ }
+
+ /*
+* When the suspend scanrate is changed, pm_runtime_get to resume
+* a potentially suspended device, update to the new pwr_cmd
+* and then pm_runtime_put to suspend into the new power mode.
+*/
+ pm_runtime_get_sync(dev);
+ error = mutex_lock_interruptible(>state_sync_lock);
+ if (error)
+ return error;
+ cyapa->runtime_suspend_sleep_time = max_t(u16, time, 1000);
+ cyapa->runtime_suspend_power_mode =
+ cyapa_sleep_time_to_pwr_cmd(cyapa->runtime_suspend_sleep_time);
+ mutex_unlock(>state_sync_lock);
+ pm_runtime_put_sync_autosuspend(dev);
+
+ return count;
+}
+
+static DEVICE_ATTR(runtime_suspend_scanrate_ms, S_IRUGO|S_IWUSR,
+ cyapa_show_rt_suspend_scanrate,
+ cyapa_update_rt_suspend_scanrate);
+
+static struct attribute *cyapa_power_runtime_entries[] = {
+ _attr_runtime_suspend_scanrate_ms.attr,
+ NULL,
+};
+
+static const struct attribute_group cyapa_power_runtime_group = {
+ .name = power_group_name,
+ .attrs = cyapa_power_runtime_entries,
+};
+
+static void cyapa_remove_power_runtime_group(void *data)
+{
+ struct cyapa *cyapa = data;
+
+ sysfs_unmerge_group(>client->dev.kobj,
+ _power_runtime_group);
+}
+
+static int cyapa_start_runtime(struct cyapa *cyapa)
+{
+ struct device *dev = >client->dev;
+ int error;
+
+ cyapa->runtime_suspend_power_mode = PWR_MODE_IDLE;
+ cyapa->runtime_suspend_sleep_time =
+ cyapa_pwr_cmd_to_sleep_time(cyapa->runtime_suspend_power_mode);
+
+ error = sysfs_merge_group(>kobj, _power_runtime_group);
+ if (error) {
+
[PATCH v15 06/12] input: cyapa: add gen3 trackpad device firmware update function support
Add firmware image update function supported for gen3 trackpad device,
it can be used through sysfs update_fw interface.
TEST=test on Chromebooks.
Signed-off-by: Dudley Du
---
drivers/input/mouse/cyapa_gen3.c | 284 +++
1 file changed, 284 insertions(+)
diff --git a/drivers/input/mouse/cyapa_gen3.c b/drivers/input/mouse/cyapa_gen3.c
index 433c5b1..9851337 100644
--- a/drivers/input/mouse/cyapa_gen3.c
+++ b/drivers/input/mouse/cyapa_gen3.c
@@ -416,6 +416,72 @@ static int cyapa_gen3_state_parse(struct cyapa *cyapa, u8
*reg_data, int len)
return -EAGAIN;
}
+/*
+ * Enter bootloader by soft resetting the device.
+ *
+ * If device is already in the bootloader, the function just returns.
+ * Otherwise, reset the device; after reset, device enters bootloader idle
+ * state immediately.
+ *
+ * Also, if device was unregister device from input core. Device will
+ * re-register after it is detected following resumption of operational mode.
+ *
+ * Returns:
+ * 0 on success
+ * -EAGAIN device was reset, but is not now in bootloader idle state
+ * < 0 if the device never responds within the timeout
+ */
+static int cyapa_gen3_bl_enter(struct cyapa *cyapa)
+{
+ int error;
+
+ error = cyapa_poll_state(cyapa, 500);
+ if (error)
+ return error;
+ if (cyapa->state == CYAPA_STATE_BL_IDLE) {
+ /* Already in BL_IDLE. Skipping reset. */
+ return 0;
+ }
+
+ if (cyapa->state != CYAPA_STATE_OP)
+ return -EAGAIN;
+
+ cyapa->state = CYAPA_STATE_NO_DEVICE;
+ error = cyapa_write_byte(cyapa, CYAPA_CMD_SOFT_RESET, 0x01);
+ if (error)
+ return -EIO;
+
+ usleep_range(25000, 5);
+ error = cyapa_poll_state(cyapa, 500);
+ if (error)
+ return error;
+ if ((cyapa->state != CYAPA_STATE_BL_IDLE) ||
+ (cyapa->status[REG_BL_STATUS] & BL_STATUS_WATCHDOG))
+ return -EAGAIN;
+
+ return 0;
+}
+
+static int cyapa_gen3_bl_activate(struct cyapa *cyapa)
+{
+ int error;
+
+ error = cyapa_i2c_reg_write_block(cyapa, 0, sizeof(bl_activate),
+ bl_activate);
+ if (error)
+ return error;
+
+ /* Wait for bootloader to activate; takes between 2 and 12 seconds */
+ msleep(2000);
+ error = cyapa_poll_state(cyapa, 11000);
+ if (error)
+ return error;
+ if (cyapa->state != CYAPA_STATE_BL_ACTIVE)
+ return -EAGAIN;
+
+ return 0;
+}
+
static int cyapa_gen3_bl_deactivate(struct cyapa *cyapa)
{
int error;
@@ -476,6 +542,218 @@ static int cyapa_gen3_bl_exit(struct cyapa *cyapa)
return 0;
}
+/* Used in gen3 bootloader commands. */
+static u16 cyapa_gen3_csum(const u8 *buf, size_t count)
+{
+ int i;
+ u16 csum = 0;
+
+ for (i = 0; i < count; i++)
+ csum += buf[i];
+
+ return csum;
+}
+
+/*
+ * Verify the integrity of a CYAPA firmware image file.
+ *
+ * The firmware image file is 30848 bytes, composed of 482 64-byte blocks.
+ *
+ * The first 2 blocks are the firmware header.
+ * The next 480 blocks are the firmware image.
+ *
+ * The first two bytes of the header hold the header checksum, computed by
+ * summing the other 126 bytes of the header.
+ * The last two bytes of the header hold the firmware image checksum, computed
+ * by summing the 30720 bytes of the image modulo 0x.
+ *
+ * Both checksums are stored little-endian.
+ */
+static int cyapa_gen3_check_fw(struct cyapa *cyapa, const struct firmware *fw)
+{
+ struct device *dev = >client->dev;
+ u16 csum;
+ u16 csum_expected;
+
+ /* Firmware must match exact 30848 bytes = 482 64-byte blocks. */
+ if (fw->size != CYAPA_FW_SIZE) {
+ dev_err(dev, "invalid firmware size = %zu, expected %u.\n",
+ fw->size, CYAPA_FW_SIZE);
+ return -EINVAL;
+ }
+
+ /* Verify header block */
+ csum_expected = (fw->data[0] << 8) | fw->data[1];
+ csum = cyapa_gen3_csum(>data[2], CYAPA_FW_HDR_SIZE - 2);
+ if (csum != csum_expected) {
+ dev_err(dev, "%s %04x, expected: %04x\n",
+ "invalid firmware header checksum = ",
+ csum, csum_expected);
+ return -EINVAL;
+ }
+
+ /* Verify firmware image */
+ csum_expected = (fw->data[CYAPA_FW_HDR_SIZE - 2] << 8) |
+fw->data[CYAPA_FW_HDR_SIZE - 1];
+ csum = cyapa_gen3_csum(>data[CYAPA_FW_HDR_SIZE],
+ CYAPA_FW_DATA_SIZE);
+ if (csum != csum_expected) {
+ dev_err(dev, "%s %04x, expected: %04x\n",
+ "invalid firmware header checksum = ",
+ csum, csum_expected);
+ return -EINVAL;
+ }
+ return 0;
+}
+
+/*
+ * Write a |len| byte
[PATCH v15 05/12] input: cyapa: add sysfs interfaces supported in the cyapa driver
Add device's basic control and features supported in cyapa driver through
sysfs file system interfaces. These interfaces are commonly used in
pre- and after production, for trackpad device state checking, managing
and firmware image updating.
These interfaces including mode, firmware_version and product_id interfaces
for reading firmware version and trackpad device product id values,
and including update_fw interface to command firmware image update
process. Also including baseline and calibrate interfaces for
reading and checking trackpad device's sensors states.
TEST=test on Chromebooks.
Signed-off-by: Dudley Du
---
drivers/input/mouse/cyapa.c | 327
1 file changed, 327 insertions(+)
diff --git a/drivers/input/mouse/cyapa.c b/drivers/input/mouse/cyapa.c
index 3bcfce3..dac3996 100644
--- a/drivers/input/mouse/cyapa.c
+++ b/drivers/input/mouse/cyapa.c
@@ -32,6 +32,8 @@
#define CYAPA_ADAPTER_FUNC_SMBUS 2
#define CYAPA_ADAPTER_FUNC_BOTH 3
+#define CYAPA_FW_NAME "cyapa.bin"
+
const char product_id[] = "CYTRA";
static int cyapa_reinitialize(struct cyapa *cyapa);
@@ -442,6 +444,29 @@ static int cyapa_create_input_dev(struct cyapa *cyapa)
return 0;
}
+static void cyapa_enable_irq_for_cmd(struct cyapa *cyapa)
+{
+ struct input_dev *input = cyapa->input;
+
+ if (!input || !input->users) {
+ if (!CYAPA_BOOTLOADER(cyapa) && cyapa->ops->set_power_mode)
+ cyapa->ops->set_power_mode(cyapa,
+ PWR_MODE_FULL_ACTIVE, 0);
+ enable_irq(cyapa->client->irq);
+ }
+}
+
+static void cyapa_disable_irq_for_cmd(struct cyapa *cyapa)
+{
+ struct input_dev *input = cyapa->input;
+
+ if (!input || !input->users) {
+ disable_irq(cyapa->client->irq);
+ if (!CYAPA_BOOTLOADER(cyapa) && cyapa->ops->set_power_mode)
+ cyapa->ops->set_power_mode(cyapa, PWR_MODE_OFF, 0);
+ }
+}
+
/*
* cyapa_sleep_time_to_pwr_cmd and cyapa_pwr_cmd_to_sleep_time
*
@@ -783,6 +808,295 @@ static int cyapa_start_runtime(struct cyapa *cyapa)
}
#endif /* CONFIG_PM_RUNTIME */
+static ssize_t cyapa_show_fm_ver(struct device *dev,
+struct device_attribute *attr, char *buf)
+{
+ int error;
+ struct cyapa *cyapa = dev_get_drvdata(dev);
+
+ error = mutex_lock_interruptible(>state_sync_lock);
+ if (error)
+ return error;
+ error = scnprintf(buf, PAGE_SIZE, "%d.%d\n", cyapa->fw_maj_ver,
+cyapa->fw_min_ver);
+ mutex_unlock(>state_sync_lock);
+ return error;
+}
+
+static ssize_t cyapa_show_product_id(struct device *dev,
+struct device_attribute *attr, char *buf)
+{
+ struct cyapa *cyapa = dev_get_drvdata(dev);
+ int size;
+ int error;
+
+ error = mutex_lock_interruptible(>state_sync_lock);
+ if (error)
+ return error;
+ size = scnprintf(buf, PAGE_SIZE, "%s\n", cyapa->product_id);
+ mutex_unlock(>state_sync_lock);
+ return size;
+}
+
+static int cyapa_firmware(struct cyapa *cyapa, const char *fw_name)
+{
+ struct device *dev = >client->dev;
+ const struct firmware *fw;
+ int error;
+
+ error = request_firmware(, fw_name, dev);
+ if (error) {
+ dev_err(dev, "Could not load firmware from %s: %d\n",
+ fw_name, error);
+ return error;
+ }
+
+ if (cyapa->ops->check_fw) {
+ error = cyapa->ops->check_fw(cyapa, fw);
+ if (error) {
+ dev_err(dev, "Invalid CYAPA firmware image: %s\n",
+ fw_name);
+ goto done;
+ }
+ } else {
+ dev_err(dev, "No valid device ops->check_fw handler set.\n");
+ error = -ENODEV;
+ goto done;
+ }
+
+ /*
+* Resume the potentially suspended device because doing FW
+* update on a device not in the FULL mode has a chance to
+* fail.
+*/
+ pm_runtime_get_sync(dev);
+
+ /* Require IRQ support for firmware update commands. */
+ cyapa_enable_irq_for_cmd(cyapa);
+
+ if (cyapa->ops->bl_enter) {
+ error = cyapa->ops->bl_enter(cyapa);
+ if (error) {
+ dev_err(dev, "bl_enter failed, %d\n", error);
+ goto err_detect;
+ }
+ }
+
+ if (cyapa->ops->bl_activate) {
+ error = cyapa->ops->bl_activate(cyapa);
+ if (error) {
+ dev_err(dev, "bl_activate failed, %d\n", error);
+ goto err_detect;
+ }
+ }
+
+ if (cyapa->ops->bl_initiate) {
+ error = cyapa->ops->bl_initiate(cyapa, fw);
+ if
[PATCH v15 03/12] input: cyapa: add power management interfaces supported for the device
Add suspend_scanrate_ms power management interfaces in device's
power group, so users or applications can control the power management
strategy of trackpad device as their requirements.
TEST=test on Chromebooks.
Signed-off-by: Dudley Du
---
drivers/input/mouse/cyapa.c | 111
1 file changed, 111 insertions(+)
diff --git a/drivers/input/mouse/cyapa.c b/drivers/input/mouse/cyapa.c
index d4560a3..73f6817 100644
--- a/drivers/input/mouse/cyapa.c
+++ b/drivers/input/mouse/cyapa.c
@@ -575,6 +575,96 @@ out:
return IRQ_HANDLED;
}
+/*
+ **
+ * sysfs interface
+ **
+*/
+#ifdef CONFIG_PM_SLEEP
+static ssize_t cyapa_show_suspend_scanrate(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct cyapa *cyapa = dev_get_drvdata(dev);
+ u8 pwr_cmd = cyapa->suspend_power_mode;
+ u16 sleep_time;
+ int len;
+ int error;
+
+ error = mutex_lock_interruptible(>state_sync_lock);
+ if (error)
+ return error;
+ pwr_cmd = cyapa->suspend_power_mode;
+ sleep_time = cyapa->suspend_sleep_time;
+ mutex_unlock(>state_sync_lock);
+
+ if (pwr_cmd == PWR_MODE_BTN_ONLY) {
+ len = scnprintf(buf, PAGE_SIZE, "%s\n", BTN_ONLY_MODE_NAME);
+ } else if (pwr_cmd == PWR_MODE_OFF) {
+ len = scnprintf(buf, PAGE_SIZE, "%s\n", OFF_MODE_NAME);
+ } else {
+ if (cyapa->gen == CYAPA_GEN3)
+ sleep_time = cyapa_pwr_cmd_to_sleep_time(pwr_cmd);
+ len = scnprintf(buf, PAGE_SIZE, "%u\n", sleep_time);
+ }
+
+ return len;
+}
+
+static ssize_t cyapa_update_suspend_scanrate(struct device *dev,
+struct device_attribute *attr,
+const char *buf, size_t count)
+{
+ struct cyapa *cyapa = dev_get_drvdata(dev);
+ u16 sleep_time;
+ int error;
+
+ error = mutex_lock_interruptible(>state_sync_lock);
+ if (error)
+ return error;
+
+ if (sysfs_streq(buf, BTN_ONLY_MODE_NAME)) {
+ cyapa->suspend_power_mode = PWR_MODE_BTN_ONLY;
+ } else if (sysfs_streq(buf, OFF_MODE_NAME)) {
+ cyapa->suspend_power_mode = PWR_MODE_OFF;
+ } else if (!kstrtou16(buf, 10, _time)) {
+ cyapa->suspend_sleep_time = max_t(u16, sleep_time, 1000);
+ cyapa->suspend_power_mode =
+ cyapa_sleep_time_to_pwr_cmd(cyapa->suspend_sleep_time);
+ } else {
+ count = 0;
+ }
+
+ mutex_unlock(>state_sync_lock);
+
+ if (!count)
+ dev_err(dev, "invalid suspend scanrate ms parameters\n");
+ return count ? count : -EINVAL;
+}
+
+static DEVICE_ATTR(suspend_scanrate_ms, S_IRUGO|S_IWUSR,
+ cyapa_show_suspend_scanrate,
+ cyapa_update_suspend_scanrate);
+
+static struct attribute *cyapa_power_wakeup_entries[] = {
+ _attr_suspend_scanrate_ms.attr,
+ NULL,
+};
+
+static const struct attribute_group cyapa_power_wakeup_group = {
+ .name = power_group_name,
+ .attrs = cyapa_power_wakeup_entries,
+};
+
+static void cyapa_remove_power_wakeup_group(void *data)
+{
+ struct cyapa *cyapa = data;
+
+ sysfs_unmerge_group(>client->dev.kobj,
+ _power_wakeup_group);
+}
+#endif /* CONFIG_PM_SLEEP */
+
static int cyapa_probe(struct i2c_client *client,
const struct i2c_device_id *dev_id)
{
@@ -614,6 +704,27 @@ static int cyapa_probe(struct i2c_client *client,
return error;
}
+#ifdef CONFIG_PM_SLEEP
+ if (device_can_wakeup(dev)) {
+ error = sysfs_merge_group(>dev.kobj,
+ _power_wakeup_group);
+ if (error) {
+ dev_err(dev, "failed to add power wakeup group: %d\n",
+ error);
+ return error;
+ }
+
+ error = devm_add_action(dev,
+ cyapa_remove_power_wakeup_group, cyapa);
+ if (error) {
+ cyapa_remove_power_wakeup_group(cyapa);
+ dev_err(dev, "failed to add power cleanup action: %d\n",
+ error);
+ return error;
+ }
+ }
+#endif /* CONFIG_PM_SLEEP */
+
error = devm_request_threaded_irq(dev, client->irq,
NULL, cyapa_irq,
IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
[PATCH v15 02/12] input: cyapa: add gen5 trackpad device basic functions support
Based on the cyapa core, add the gen5 trackpad device's basic functions
supported, so gen5 trackpad device can work with kernel input system.
And also based on the state parse interface, the cyapa driver can
automatically determine the attached is gen3 or gen5 protocol trackpad
device, then set the correct protocol to work with the attached
trackpad device.
TEST=test on Chromebooks.
Signed-off-by: Dudley Du
---
drivers/input/mouse/Makefile |2 +-
drivers/input/mouse/cyapa.c | 13 +
drivers/input/mouse/cyapa.h |1 +
drivers/input/mouse/cyapa_gen5.c | 1660 ++
4 files changed, 1675 insertions(+), 1 deletion(-)
create mode 100644 drivers/input/mouse/cyapa_gen5.c
diff --git a/drivers/input/mouse/Makefile b/drivers/input/mouse/Makefile
index 8bd950d..8a9c98e 100644
--- a/drivers/input/mouse/Makefile
+++ b/drivers/input/mouse/Makefile
@@ -24,7 +24,7 @@ obj-$(CONFIG_MOUSE_SYNAPTICS_I2C) += synaptics_i2c.o
obj-$(CONFIG_MOUSE_SYNAPTICS_USB) += synaptics_usb.o
obj-$(CONFIG_MOUSE_VSXXXAA)+= vsxxxaa.o
-cyapatp-objs := cyapa.o cyapa_gen3.o
+cyapatp-objs := cyapa.o cyapa_gen3.o cyapa_gen5.o
psmouse-objs := psmouse-base.o synaptics.o focaltech.o
psmouse-$(CONFIG_MOUSE_PS2_ALPS) += alps.o
diff --git a/drivers/input/mouse/cyapa.c b/drivers/input/mouse/cyapa.c
index ae1df15..d4560a3 100644
--- a/drivers/input/mouse/cyapa.c
+++ b/drivers/input/mouse/cyapa.c
@@ -157,6 +157,14 @@ static int cyapa_get_state(struct cyapa *cyapa)
if (!error)
goto out_detected;
}
+ if ((cyapa->gen == CYAPA_GEN_UNKNOWN ||
+ cyapa->gen == CYAPA_GEN5) &&
+ !smbus && even_addr) {
+ error = cyapa_gen5_ops.state_parse(cyapa,
+ status, BL_STATUS_SIZE);
+ if (!error)
+ goto out_detected;
+ }
/*
* Write 0x00 0x00 to trackpad device to force update its
@@ -240,6 +248,9 @@ static int cyapa_check_is_operational(struct cyapa *cyapa)
return error;
switch (cyapa->gen) {
+ case CYAPA_GEN5:
+ cyapa->ops = _gen5_ops;
+ break;
case CYAPA_GEN3:
cyapa->ops = _gen3_ops;
break;
@@ -476,6 +487,8 @@ static int cyapa_initialize(struct cyapa *cyapa)
if (cyapa_gen3_ops.initialize)
error = cyapa_gen3_ops.initialize(cyapa);
+ if (!error && cyapa_gen5_ops.initialize)
+ error = cyapa_gen5_ops.initialize(cyapa);
if (error)
return error;
diff --git a/drivers/input/mouse/cyapa.h b/drivers/input/mouse/cyapa.h
index 709ad47..d7d4f11 100644
--- a/drivers/input/mouse/cyapa.h
+++ b/drivers/input/mouse/cyapa.h
@@ -312,5 +312,6 @@ u16 cyapa_pwr_cmd_to_sleep_time(u8 pwr_mode);
extern const char product_id[];
extern const struct cyapa_dev_ops cyapa_gen3_ops;
+extern const struct cyapa_dev_ops cyapa_gen5_ops;
#endif
diff --git a/drivers/input/mouse/cyapa_gen5.c b/drivers/input/mouse/cyapa_gen5.c
new file mode 100644
index 000..1ac264d
--- /dev/null
+++ b/drivers/input/mouse/cyapa_gen5.c
@@ -0,0 +1,1660 @@
+/*
+ * Cypress APA trackpad with I2C interface
+ *
+ * Author: Dudley Du
+ *
+ * Copyright (C) 2014 Cypress Semiconductor, Inc.
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file COPYING in the main directory of this archive for
+ * more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "cyapa.h"
+
+
+/* Macro of Gen5 */
+#define RECORD_EVENT_NONE0
+#define RECORD_EVENT_TOUCHDOWN 1
+#define RECORD_EVENT_DISPLACE2
+#define RECORD_EVENT_LIFTOFF 3
+
+#define CYAPA_TSG_FLASH_MAP_BLOCK_SIZE 0x80
+#define CYAPA_TSG_IMG_FW_HDR_SIZE 13
+#define CYAPA_TSG_FW_ROW_SIZE (CYAPA_TSG_FLASH_MAP_BLOCK_SIZE)
+#define CYAPA_TSG_IMG_START_ROW_NUM 0x002e
+#define CYAPA_TSG_IMG_END_ROW_NUM 0x01fe
+#define CYAPA_TSG_IMG_APP_INTEGRITY_ROW_NUM 0x01ff
+#define CYAPA_TSG_IMG_MAX_RECORDS (CYAPA_TSG_IMG_END_ROW_NUM - \
+ CYAPA_TSG_IMG_START_ROW_NUM + 1 + 1)
+#define CYAPA_TSG_IMG_READ_SIZE (CYAPA_TSG_FLASH_MAP_BLOCK_SIZE /
2)
+#define CYAPA_TSG_START_OF_APPLICATION 0x1700
+#define CYAPA_TSG_APP_INTEGRITY_SIZE60
+#define CYAPA_TSG_FLASH_MAP_METADATA_SIZE 60
+#define CYAPA_TSG_BL_KEY_SIZE 8
+
+/* Macro definitions for Gen5 trackpad device. */
+#define GEN5_TOUCH_REPORT_HEAD_SIZE 7
+#define GEN5_TOUCH_REPORT_MAX_SIZE 127
+#define GEN5_BTN_REPORT_HEAD_SIZE 6
+#define GEN5_BTN_REPORT_MAX_SIZE14
+#define GEN5_WAKEUP_EVENT_SIZE 4
+#define
[PATCH v15 01/12] input: cyapa: re-design driver to support multi-trackpad in one driver
In order to support multiple different chipsets and communication protocols trackpad devices in one cyapa driver, the new cyapa driver is re-designed with one cyapa driver core and multiple device specific functions component. The cyapa driver core is contained in this patch, it supplies basic functions that working with kernel and input subsystem, and also supplies the interfaces that the specific devices' component can connect and work together with as one driver. TEST=test on Chromebooks. Signed-off-by: Dudley Du --- drivers/input/mouse/Makefile |3 +- drivers/input/mouse/cyapa.c | 1047 ++ drivers/input/mouse/cyapa.h | 316 drivers/input/mouse/cyapa_gen3.c | 793 + 4 files changed, 1493 insertions(+), 666 deletions(-) create mode 100644 drivers/input/mouse/cyapa.h create mode 100644 drivers/input/mouse/cyapa_gen3.c diff --git a/drivers/input/mouse/Makefile b/drivers/input/mouse/Makefile index 560003d..8bd950d 100644 --- a/drivers/input/mouse/Makefile +++ b/drivers/input/mouse/Makefile @@ -8,7 +8,7 @@ obj-$(CONFIG_MOUSE_AMIGA) += amimouse.o obj-$(CONFIG_MOUSE_APPLETOUCH) += appletouch.o obj-$(CONFIG_MOUSE_ATARI) += atarimouse.o obj-$(CONFIG_MOUSE_BCM5974)+= bcm5974.o -obj-$(CONFIG_MOUSE_CYAPA) += cyapa.o +obj-$(CONFIG_MOUSE_CYAPA) += cyapatp.o obj-$(CONFIG_MOUSE_ELAN_I2C) += elan_i2c.o obj-$(CONFIG_MOUSE_GPIO) += gpio_mouse.o obj-$(CONFIG_MOUSE_INPORT) += inport.o @@ -24,6 +24,7 @@ obj-$(CONFIG_MOUSE_SYNAPTICS_I2C) += synaptics_i2c.o obj-$(CONFIG_MOUSE_SYNAPTICS_USB) += synaptics_usb.o obj-$(CONFIG_MOUSE_VSXXXAA)+= vsxxxaa.o +cyapatp-objs := cyapa.o cyapa_gen3.o psmouse-objs := psmouse-base.o synaptics.o focaltech.o psmouse-$(CONFIG_MOUSE_PS2_ALPS) += alps.o diff --git a/drivers/input/mouse/cyapa.c b/drivers/input/mouse/cyapa.c index 1bece8c..ae1df15 100644 --- a/drivers/input/mouse/cyapa.c +++ b/drivers/input/mouse/cyapa.c @@ -20,408 +20,100 @@ #include #include #include +#include #include +#include +#include "cyapa.h" -/* APA trackpad firmware generation */ -#define CYAPA_GEN3 0x03 /* support MT-protocol B with tracking ID. */ - -#define CYAPA_NAME "Cypress APA Trackpad (cyapa)" - -/* commands for read/write registers of Cypress trackpad */ -#define CYAPA_CMD_SOFT_RESET 0x00 -#define CYAPA_CMD_POWER_MODE 0x01 -#define CYAPA_CMD_DEV_STATUS 0x02 -#define CYAPA_CMD_GROUP_DATA 0x03 -#define CYAPA_CMD_GROUP_CMD0x04 -#define CYAPA_CMD_GROUP_QUERY 0x05 -#define CYAPA_CMD_BL_STATUS0x06 -#define CYAPA_CMD_BL_HEAD 0x07 -#define CYAPA_CMD_BL_CMD 0x08 -#define CYAPA_CMD_BL_DATA 0x09 -#define CYAPA_CMD_BL_ALL 0x0a -#define CYAPA_CMD_BLK_PRODUCT_ID 0x0b -#define CYAPA_CMD_BLK_HEAD 0x0c - -/* report data start reg offset address. */ -#define DATA_REG_START_OFFSET 0x - -#define BL_HEAD_OFFSET 0x00 -#define BL_DATA_OFFSET 0x10 - -/* - * Operational Device Status Register - * - * bit 7: Valid interrupt source - * bit 6 - 4: Reserved - * bit 3 - 2: Power status - * bit 1 - 0: Device status - */ -#define REG_OP_STATUS 0x00 -#define OP_STATUS_SRC 0x80 -#define OP_STATUS_POWER 0x0c -#define OP_STATUS_DEV 0x03 -#define OP_STATUS_MASK (OP_STATUS_SRC | OP_STATUS_POWER | OP_STATUS_DEV) - -/* - * Operational Finger Count/Button Flags Register - * - * bit 7 - 4: Number of touched finger - * bit 3: Valid data - * bit 2: Middle Physical Button - * bit 1: Right Physical Button - * bit 0: Left physical Button - */ -#define REG_OP_DATA1 0x01 -#define OP_DATA_VALID 0x08 -#define OP_DATA_MIDDLE_BTN 0x04 -#define OP_DATA_RIGHT_BTN 0x02 -#define OP_DATA_LEFT_BTN 0x01 -#define OP_DATA_BTN_MASK (OP_DATA_MIDDLE_BTN | OP_DATA_RIGHT_BTN | \ - OP_DATA_LEFT_BTN) - -/* - * Bootloader Status Register - * - * bit 7: Busy - * bit 6 - 5: Reserved - * bit 4: Bootloader running - * bit 3 - 1: Reserved - * bit 0: Checksum valid - */ -#define REG_BL_STATUS0x01 -#define BL_STATUS_BUSY 0x80 -#define BL_STATUS_RUNNING0x10 -#define BL_STATUS_DATA_VALID 0x08 -#define BL_STATUS_CSUM_VALID 0x01 - -/* - * Bootloader Error Register - * - * bit 7: Invalid - * bit 6: Invalid security key - * bit 5: Bootloading - * bit 4: Command checksum - * bit 3: Flash protection error - * bit 2: Flash checksum error - * bit 1 - 0: Reserved - */ -#define REG_BL_ERROR 0x02 -#define BL_ERROR_INVALID 0x80 -#define BL_ERROR_INVALID_KEY 0x40 -#define BL_ERROR_BOOTLOADING 0x20 -#define BL_ERROR_CMD_CSUM0x10 -#define BL_ERROR_FLASH_PROT 0x08 -#define BL_ERROR_FLASH_CSUM 0x04 - -#define BL_STATUS_SIZE 3 /* length of bootloader status registers */ -#define BLK_HEAD_BYTES 32 - -#define PRODUCT_ID_SIZE 16 -#define QUERY_DATA_SIZE 27
[PATCH 1/1] Drivers: hv: vmbus: Use get_cpu() to get the current CPU
Replace calls for smp_processor_id() to get_cpu() to get the CPU ID of
the current CPU. In these instances, there is no correctness issue with
regards to preemption, we just need the current CPU ID.
Signed-off-by: K. Y. Srinivasan
---
drivers/hv/channel_mgmt.c |4 +++-
drivers/hv/connection.c |6 --
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index d36ce68..a205246 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -813,7 +813,7 @@ cleanup:
struct vmbus_channel *vmbus_get_outgoing_channel(struct vmbus_channel *primary)
{
struct list_head *cur, *tmp;
- int cur_cpu = hv_context.vp_index[smp_processor_id()];
+ int cur_cpu;
struct vmbus_channel *cur_channel;
struct vmbus_channel *outgoing_channel = primary;
int cpu_distance, new_cpu_distance;
@@ -821,6 +821,8 @@ struct vmbus_channel *vmbus_get_outgoing_channel(struct
vmbus_channel *primary)
if (list_empty(>sc_list))
return outgoing_channel;
+ cur_cpu = hv_context.vp_index[get_cpu()];
+ put_cpu();
list_for_each_safe(cur, tmp, >sc_list) {
cur_channel = list_entry(cur, struct vmbus_channel, sc_list);
if (cur_channel->state != CHANNEL_OPENED_STATE)
diff --git a/drivers/hv/connection.c b/drivers/hv/connection.c
index e206619..a63a795 100644
--- a/drivers/hv/connection.c
+++ b/drivers/hv/connection.c
@@ -80,8 +80,10 @@ static int vmbus_negotiate_version(struct
vmbus_channel_msginfo *msginfo,
msg->interrupt_page = virt_to_phys(vmbus_connection.int_page);
msg->monitor_page1 = virt_to_phys(vmbus_connection.monitor_pages[0]);
msg->monitor_page2 = virt_to_phys(vmbus_connection.monitor_pages[1]);
- if (version == VERSION_WIN8_1)
- msg->target_vcpu = hv_context.vp_index[smp_processor_id()];
+ if (version == VERSION_WIN8_1) {
+ msg->target_vcpu = hv_context.vp_index[get_cpu()];
+ put_cpu();
+ }
/*
* Add to list before we send the request since we may
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v15 00/12] input: cyapa: instruction of cyapa patches
V15 patches have below updates, details of other updates see history list: 1) Fix all warning errors of sparse tool when running with "make C=1". 2) Change variable name "unique_str" to "product_id" for clearer meanings. This patch series is aimed to re-design the cyapa driver to support old gen3 trackpad devices and new gen5 trackpad devices in one cyapa driver, it's for easily productions support based on customers' requirements. And add sysfs functions and interfaces supported that required by users and customers. Since the earlier gen3 and the latest gen5 trackpad devices using two different chipsets, and have different protocols and interfaces, so if supported these two type trackpad devices in two different drivers, then it will be difficult to manage productions and later firmware updates. e.g.: It will cause customer don't know which one trackpad device firmware image to use and update when it has been used and integrated in same one productions, so here we support these two trackpad devices in same on driver. The new design cyapa driver contains: cyapa.c - the core of the re-design, supply interfaces and functions to system and read trackpad devices. cyapa.h - header file including macros and data structure definitions. cyapa_gen3.c - functions support for gen3 trackpad devices, cyapa_gen5.c - functions support for gen5 trackpad devices. Beside this introduction patch, it has 12 patches listed as below. For these patches, each one is patched based on previous one. patch 1/12: re-design cyapa driver with core functions and interface to support multi-type trackpad devices. patch 2/12: add gen5 trackpad device basic functions supported into the re-design cyapa driver. patch 3/12: add power management interfaces supported for the device. patch 4/12: add runtime power management interfaces supported for the device. patch 5/12: add sysfs interfaces supported in the cyapa driver. Including read firmware version, get production ID, read baseline, re-calibrate trackpad baselines and do trackpad firmware update. patch 6/12: add gen3 trackpad device's firmware update function supported. patch 7/12: add gen3 trackpad device's read baseline function supported. patch 8/12: add gen3 trackpad device's force re-calibrate function supported. patch 9/12: add gen5 trackpad device's firmware update function supported. patch 10/12: add gen5 trackpad device's read baseline function supported. patch 11/12: add gen5 trackpad device's force re-calibrate function. patch 12/12: add acpi device id supported. History patch series modifications list: V14 patches have below main updates compared with v13 patches: 1) Correct 9 miss spelling issues of "bufferred" to "buffered". 2) Fix the upgrade issue of removing MOUSE_CYAPA config when make oldconfig by replase "depends on I2C && CRC_ITU_T" with "depends on I2C" "select CRC_ITU_T" in patch 9. V13 patches have below main updates compared with v12 patches: 1) Remove all debugfs interface, including read_fw and raw_data interfaces. 2) This patches are made based linux next-20141208. V12 patches have below main updates compared with v11 patches: 1) Add check that when TP is detected but not operational, do not exit driver immediately, but wait and export the update_fw interface for recovering. 2) Re-arrange the function codes, remove unnesseary protype definitions in the header file. V11 patches have below main updates compared with v10 patches: 1) Add add acpi device id supported for old gen3 and new gen5 trackpad devices. 2) Fix the unable to update firmware issue when cyapa_open is not called which means the irq for firwmare update process is not enabled. This fix by checking if the irq is enabled, if not then enable irq before start to do firmware update. V10 patches have below main updates compared with v9 patches: 1) Modify code to following kernel code style. e.g.: correct to use error as return name when there is only error path, and fix the checkpatch.sh wanting in the driver. 2) Remove cyapa_remove method and use input open and close interface to following device resouse management infrastructure. 3) Modify cyapa_detect method to return tristate issue to make the return value much more consistent and clear. 4) Use platform supplied functions as possible instead of driver specific rewritten version. V9 patches have below updates compared with v8 patches: 1) Removed all async thread stuff from the driver. 2) Split driver into 18 patches for each function change one patch. V8 patches have below updates compared with v7 patches: 1) [PATCH v8 01/13] - Remove the async thread for device detect in probe routine, now the device detect process is completely done within the device probe routine. 2) [PATCH v8 01/13] - Split the irq cmd hander function to separated function cyapa_default_irq_cmd_handler() and set it to interface cyapa_default_ops.irq_cmd_handler. 3) [PATCH v8 06/13] - Add
Re: [PATCH (resend)] mailbox: Add Altera mailbox driver
On Fri, Dec 12, 2014 at 10:38 PM, Dinh Nguyen wrote:
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>
> Alphabetize the headers.
Okay.
>> +static int altera_mbox_startup_sender(struct mbox_chan *chan)
>> +{
>> + int ret;
>> + struct altera_mbox *mbox = to_altera_mbox(chan);
>> +
>> + if (mbox->intr_mode) {
>> + ret = request_irq(mbox->irq, altera_mbox_tx_interrupt, 0,
>
> Use devm_request_irq, since you didn't have and don't need use free_irq
> in the shutdown function.
We want to free_irq when it shutdown. That means nobody requests for
that mailbox (or channel) and request_irq() again if someone requests
for a mailbox.
>
>> + DRIVER_NAME, chan);
>> + if (unlikely(ret)) {
>> + dev_err(mbox->dev,
>> + "failed to register mailbox interrupt:%d\n",
>> + ret);
>> + return ret;
>> + }
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static int altera_mbox_startup_receiver(struct mbox_chan *chan)
>> +{
>> + int ret;
>> + struct altera_mbox *mbox = to_altera_mbox(chan);
>> +
>> + if (mbox->intr_mode) {
>> + ret = request_irq(mbox->irq, altera_mbox_rx_interrupt, 0,
>> + DRIVER_NAME, chan);
>
> Use devm_request_irq
>
>
>> + if (unlikely(ret)) {
>> + dev_err(mbox->dev,
>> + "failed to register mailbox interrupt:%d\n",
>> + ret);
>> + return ret;
>> + }
>> + altera_mbox_rx_intmask(mbox, true);
>> + } else {
>> + /* Setup polling timer */
>> + setup_timer(>rxpoll_timer, altera_mbox_poll_rx,
>> + (unsigned long)chan);
>> + mod_timer(>rxpoll_timer,
>> + jiffies + msecs_to_jiffies(MBOX_POLLING_MS));
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static int altera_mbox_send_data(struct mbox_chan *chan, void *data)
>> +{
>> + struct altera_mbox *mbox = to_altera_mbox(chan);
>> + u32 *udata = (u32 *)data;
>> +
>> + if (!mbox || !data)
>> + return -EINVAL;
>> + if (!mbox->is_sender) {
>> + dev_warn(mbox->dev,
>> + "failed to send. This is receiver mailbox.\n");
>> + return -EINVAL;
>> + }
>> +
>> + if (altera_mbox_full(mbox))
>> + return -EBUSY;
>> +
>> + /* Enable interrupt before send */
>> + altera_mbox_tx_intmask(mbox, true);
>> +
>> + /* Pointer register must write before command register */
>> + __raw_writel(udata[MBOX_PTR], mbox->mbox_base + MAILBOX_PTR_REG);
>> + __raw_writel(udata[MBOX_CMD], mbox->mbox_base + MAILBOX_CMD_REG);
>> +
>> + return 0;
>> +}
>> +
>> +static bool altera_mbox_last_tx_done(struct mbox_chan *chan)
>> +{
>> + struct altera_mbox *mbox = to_altera_mbox(chan);
>> +
>> + if (WARN_ON(!mbox))
>> + return false;
>
> Are these checks necessary? Shouldn't the driver probe function have
> already failed?
Will removed.
>> +
>> + /* Return false if mailbox is full */
>> + return altera_mbox_full(mbox) ? false : true;
>> +}
>> +
>> +static bool altera_mbox_peek_data(struct mbox_chan *chan)
>> +{
>> + struct altera_mbox *mbox = to_altera_mbox(chan);
>> +
>> + if (WARN_ON(!mbox))
>> + return false;
>> +
>> + return altera_mbox_pending(mbox) ? true : false;
>> +}
>> +
>> +static int altera_mbox_startup(struct mbox_chan *chan)
>> +{
>> + struct altera_mbox *mbox = to_altera_mbox(chan);
>> + int ret = 0;
>> +
>> + if (!mbox)
>> + return -EINVAL;
>> +
>> + if (mbox->is_sender)
>> + ret = altera_mbox_startup_sender(chan);
>> + else
>> + ret = altera_mbox_startup_receiver(chan);
>> +
>> + return ret;
>> +}
>> +
>> +static void altera_mbox_shutdown(struct mbox_chan *chan)
>> +{
>> + struct altera_mbox *mbox = to_altera_mbox(chan);
>> +
>> + if (WARN_ON(!mbox))
>> + return;
>> +
>> + if (mbox->intr_mode) {
>> + /* Unmask all interrupt masks */
>> + __raw_writel(~0, mbox->mbox_base + MAILBOX_INTMASK_REG);
>> + free_irq(mbox->irq, chan);
>> + } else if (!mbox->is_sender)
>> + del_timer_sync(>rxpoll_timer);
>
> Need braces around the else as well.
Noted.
>
>> +}
>> +
>> +static struct mbox_chan_ops altera_mbox_ops = {
>> + .send_data = altera_mbox_send_data,
>> + .startup = altera_mbox_startup,
>> + .shutdown = altera_mbox_shutdown,
>> + .last_tx_done = altera_mbox_last_tx_done,
>> + .peek_data = altera_mbox_peek_data,
>> +};
>> +
>> +static int altera_mbox_probe(struct platform_device *pdev)
>> +{
>> + struct altera_mbox *mbox;
>> + struct mbox_chan *chans[1];
>
> It would be cleaner if you use
Re: [PATCH] usb: gadget: udc-core: call udc_stop() before gadget unbind
On Fri, Dec 12, 2014 at 02:17:28PM +0100, Robert Baldyga wrote: > As usb function drivers assumes that all usb request will be completed > before function unbind call, we should supply such behavior. In some > cases ep_disable() won't kill all request effectively, because some > IN requests can be in running state. In such situation it's possible > to have unbind function called before last request completion, which > can cause problems. Doesn't the function's disable/unbind should call usb_ep_dequeue to make sure the transfer has ended? .udc_stop may stop the controller, and .unbind may still visit hardware. > > For example unbinding f_ecm function while request on 'notify' endpoint > is not completed, ends up NULL pointer dereference in unbind() function. > > usb_gadget_udc_stop() call causes completion of all requests so if it's > called before gadget unbind there is no risk that some of requests will > stay uncompleted. > > Signed-off-by: Robert Baldyga > --- > drivers/usb/gadget/udc/udc-core.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/usb/gadget/udc/udc-core.c > b/drivers/usb/gadget/udc/udc-core.c > index e31d574..6f0d233 100644 > --- a/drivers/usb/gadget/udc/udc-core.c > +++ b/drivers/usb/gadget/udc/udc-core.c > @@ -331,8 +331,8 @@ static void usb_gadget_remove_driver(struct usb_udc *udc) > > usb_gadget_disconnect(udc->gadget); > udc->driver->disconnect(udc->gadget); > - udc->driver->unbind(udc->gadget); > usb_gadget_udc_stop(udc); > + udc->driver->unbind(udc->gadget); > > udc->driver = NULL; > udc->dev.driver = NULL; > -- > 1.9.1 > -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/8] nfs: don't dirty ITER_BVEC pages read through direct I/O
On Sun, Dec 14, 2014 at 09:27:00PM -0800, Omar Sandoval wrote: > As with the generic blockdev code, kernel pages shouldn't be dirtied by > the direct I/O path. This really asks for an inlined helper (iter_is_bvec(iter) or something like that) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/8] swap: don't add ITER_BVEC flag to direct_IO rw
On Sun, Dec 14, 2014 at 09:26:57PM -0800, Omar Sandoval wrote: > The rw argument to direct_IO has some ill-defined semantics. Some > filesystems (e.g., ext4, FAT) decide whether they're doing a write with > rw == WRITE, but others (e.g., XFS) check rw & WRITE. Let's set a good > example in the swap file code and say ITER_BVEC belongs in > iov_iter->flags but not in rw. This caters to the least common > denominator and avoids a sweeping change of every direct_IO > implementation for now. Frankly, this is bogus. If anything, let's just kill the first argument completely - ->direct_IO() can always pick it from iter->type. As for catering to the least common denominator... To hell with the lowest common denominator. How many instances of ->direct_IO() do we have, anyway? 24 in the mainline (and we don't give a flying fuck for out-of-tree code, as a matter of policy). Moreover, several are of "do nothing" variety. FWIW, 'rw' is a mess. We used to have this: READ: O_DIRECT read WRITE: O_DIRECT write KERNEL_WRITE: swapout These days KERNEL_WRITE got replaced with ITER_BVEC | WRITE. The thing is, we have a bunch of places where we explicitly checked for being _equal_ to WRITE. I.e. the checks that gave a negative on swapouts. I suspect that most of them are wrong and should trigger on all writes, including swapouts, but I really didn't want to dig into that pile of fun back then. That's the main reason why 'rw' argument has survived at all... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC 1/4] Documentation: Change policy on sending patches during merge window
Ask patch submitters to avoid sending non-critical patches when the merge window is open. This basically extends the net-next policy in netdev-FAQ.txt to the entire kernel. Suggested-by: Thomas Gleixner Signed-off-by: Kevin Cernekee --- Documentation/development-process/5.Posting | 9 + 1 file changed, 9 insertions(+) diff --git a/Documentation/development-process/5.Posting b/Documentation/development-process/5.Posting index 8a48c9b..14f8b01 100644 --- a/Documentation/development-process/5.Posting +++ b/Documentation/development-process/5.Posting @@ -26,6 +26,15 @@ which remains to be done and any known problems. Fewer people will look at patches which are known to be half-baked, but those who do will come in with the idea that they can help you drive the work in the right direction. +Some maintainers prefer to receive only urgent patches when the merge +window is open, so that critical fixes do not get lost in the noise during +times of peak activity. If you are posting an actual [PATCH] (not something +that is obviously low-priority such as an [RFC] or [RANT]) and you aren't sure +of your maintainer's stance, the safest thing to do is hold off until the +merge window has closed. You can visit https://www.kernel.org/ to check +the merge window status; it is closed if the "mainline:" entry shows a +version number containing "-rc", and open if a non-rc version number appears. + 5.2: BEFORE CREATING PATCHES -- 2.1.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC 4/4] Documentation: Provide suggestions on when to repost patches
Give submitters a rough idea of how long to wait before reposting, to help avoid situations where a series is reposted before the original submission is fully reviewed. Suggested-by: Thomas Gleixner Signed-off-by: Kevin Cernekee --- Documentation/development-process/6.Followthrough | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/Documentation/development-process/6.Followthrough b/Documentation/development-process/6.Followthrough index 41d324a..6cefb6c 100644 --- a/Documentation/development-process/6.Followthrough +++ b/Documentation/development-process/6.Followthrough @@ -74,7 +74,10 @@ around. One fatal mistake is to ignore review comments in the hope that they will go away. They will not go away. If you repost code without having responded to the comments you got the time before, you're likely to find -that your patches go nowhere. +that your patches go nowhere. On the flipside, reposting an updated patch +before the original has been fully reviewed can be a source of frustration +too, so consider giving the reviewers ~3-7 calendar days (depending on +patch complexity) before posting V2. Speaking of reposting code: please bear in mind that reviewers are not going to remember all the details of the code you posted the last time -- 2.1.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC 2/4] Documentation/SubmitChecklist: Remind submitters to check the merge window
Currently the checklist does not provide an indication of appropriate
times to send patches; add a brief note on the topic.
Signed-off-by: Kevin Cernekee
---
Documentation/SubmitChecklist | 5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/SubmitChecklist b/Documentation/SubmitChecklist
index 2b7e32d..8b23f9c 100644
--- a/Documentation/SubmitChecklist
+++ b/Documentation/SubmitChecklist
@@ -107,3 +107,8 @@ kernel patches.
CONFIG_SMP, CONFIG_SYSFS, CONFIG_PROC_FS, CONFIG_INPUT, CONFIG_PCI,
CONFIG_BLOCK, CONFIG_PM, CONFIG_MAGIC_SYSRQ,
CONFIG_NET, CONFIG_INET=n (but latter with CONFIG_NET=y)
+
+27: For patches which are not urgent fixes for bugs in the current tree,
+double-check https://www.kernel.org/ to make sure the merge window is
+CLOSED ("mainline:" showing an -rc kernel) before sending. For more
+information on the release cycle, see Documentation/development-process/.
--
2.1.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC 3/4] Documentation: Add cutoff periods for patch acceptance
This has been a recurring source of confusion for the new submitters who I've helped; let's see if adding a small illustration improves the situation. Signed-off-by: Kevin Cernekee --- Documentation/development-process/5.Posting | 16 1 file changed, 16 insertions(+) diff --git a/Documentation/development-process/5.Posting b/Documentation/development-process/5.Posting index 14f8b01..50cf4dc 100644 --- a/Documentation/development-process/5.Posting +++ b/Documentation/development-process/5.Posting @@ -35,6 +35,22 @@ merge window has closed. You can visit https://www.kernel.org/ to check the merge window status; it is closed if the "mainline:" entry shows a version number containing "-rc", and open if a non-rc version number appears. +In many cases, feature additions received and accepted somewhere in the range +of [N-rc1, N-rc5) will be merged into the -next tree targeting the (N+1) Linux +release. For example: + + kernel.org "mainline:" | Patch may appear + field when posted | in released kernel + + + 3.18-rc[1-4]| 3.19 + 3.18-rc[5-9]| 3.20 + 3.18| Merge window open - don't post + 3.19-rc[1-4]| 3.20 + 3.19-rc[5-9]| 3.21 + 3.19| Merge window open - don't post + +Bug fixes can typically be accepted at any time. + 5.2: BEFORE CREATING PATCHES -- 2.1.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC 0/4] Stop maintainer abuse
This patch series amends the kernel development process to reduce the load on key maintainers during peak periods, by discouraging the submission of non-urgent patches while the merge window is open. Original discussion here: https://lkml.org/lkml/2014/12/12/772 (As a non-subsystem-maintainer I don't really have a horse in this race, but if everyone else agrees that it's the right thing to do, we might as well make it the official policy and start teaching it to new developers.) Kevin Cernekee (4): Documentation: Change policy on sending patches during merge window Documentation/SubmitChecklist: Remind submitters to check the merge window Documentation: Add cutoff periods for patch acceptance Documentation: Provide suggestions on when to repost patches Documentation/SubmitChecklist | 5 + Documentation/development-process/5.Posting | 25 +++ Documentation/development-process/6.Followthrough | 5 - 3 files changed, 34 insertions(+), 1 deletion(-) -- 2.1.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Dear Webmail user
-- Attention User; Your email Quota is almost exceeded. Starting from December 15th, we are migrating to new email interface. So we are currently doing a maintenance on our server. Please, click the link below to Enter and update your account and avoid losing your inbox. http://www.jakkies.co.za/images/helpdesk/upgrade.php WEBMASTER Technical Team HELPDESK SERVICE @verification.edu.Security -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/5] ARM64: Add kernel probes(Kprobes) support
(2014/12/13 8:10), Steve Capper wrote:
> On 12 December 2014 at 22:42, David Long wrote:
>> On 12/10/14 11:38, Steve Capper wrote:
>>>
>>> On Tue, Dec 09, 2014 at 09:27:18AM -0500, David Long wrote:
On 12/09/14 08:33, Steve Capper wrote:
>
> On Thu, Dec 04, 2014 at 08:53:03PM +0900, Masami Hiramatsu wrote:
>>>
>>>
>>> [...]
>>>
>
> Not sure if this is helpful, but the following also caused a crash for
> me:
>
> echo "p:trace_event_buffer_lock_reserve trace_event_buffer_lock_reserve"
>> /sys/kernel/debug/tracing/kprobe_events
> echo "p:memcpy memcpy" >> /sys/kernel/debug/tracing/kprobe_events
> echo 1 > /sys/kernel/debug/tracing/events/kprobes/enable
>
> [immediate crash]
>
> The crash point for me is in the arm64 ASID allocator, it again looks
> like the interrupts are in an unexpected state.
> (check_and_switch_context goes down the irqs disabled code path, I
> think incorrectly).
>
> This occurred for me both with and without the proposed irq saving fix.
>
> I will do some more digging.
>
Thanks, more information is good.
>>>
>>> Hi,
>>>
>>> Some good news, I think I've fixed the problem I've been experiencing.
>>>
>>> Basically, I've torn out all the interrupt save/restore and have
>>> narrowed the scope to just sandwich the instruction single-step. This
>>> simplifies a lot of logic, and I've now been able to perf record a
>>> kprobe on memcpy (and the trace_event_buffer_lock_reserve + memcpy
>>> test) without any issues on a Juno platform.
>>>
>>> I may have been somewhat over-zealous with the chainsaw, so please do
>>> put this fix through its paces.
>>>
>>> Cheers,
>>> --
>>> Steve
>>>
>>>
>>> From d3f4d80ce19bec71bd03209beb2fbfd8084d6543 Mon Sep 17 00:00:00 2001
>>> From: Steve Capper
>>> Date: Mon, 1 Dec 2014 11:30:10 +
>>> Subject: [PATCH] Fix the interrupt handling for kprobes
>>>
>>> ---
>>> arch/arm64/kernel/kprobes.c | 16 ++--
>>> 1 file changed, 2 insertions(+), 14 deletions(-)
>>>
>>> diff --git a/arch/arm64/kernel/kprobes.c b/arch/arm64/kernel/kprobes.c
>>> index be7c330..d39d826 100644
>>> --- a/arch/arm64/kernel/kprobes.c
>>> +++ b/arch/arm64/kernel/kprobes.c
>>> @@ -229,10 +229,6 @@ skip_singlestep_missed(struct kprobe_ctlblk *kcb,
>>> struct pt_regs *regs)
>>> {
>>> /* set return addr to next pc to continue */
>>> instruction_pointer(regs) += sizeof(kprobe_opcode_t);
>>> -
>>> - if (kcb->kprobe_status != KPROBE_REENTER)
>>> - kprobes_restore_local_irqflag(regs);
>>> -
>>> }
>>>
>>> static void __kprobes setup_singlestep(struct kprobe *p,
>>> @@ -259,7 +255,7 @@ static void __kprobes setup_singlestep(struct kprobe
>>> *p,
>>> spsr_set_debug_flag(regs, 0);
>>>
>>> /* IRQs and single stepping do not mix well. */
>>> - local_irq_disable();
>>> + kprobes_save_local_irqflag(regs);
>>> kernel_enable_single_step(regs);
>>> instruction_pointer(regs) = slot;
>>> } else {
>>> @@ -326,7 +322,6 @@ post_kprobe_handler(struct kprobe_ctlblk *kcb, struct
>>> pt_regs *regs)
>>> }
>>>
>>> reset_current_kprobe();
>>> - kprobes_restore_local_irqflag(regs);
>>> }
>>>
>>> int __kprobes kprobe_fault_handler(struct pt_regs *regs, unsigned int
>>> fsr)
>>> @@ -380,8 +375,6 @@ int __kprobes kprobe_fault_handler(struct pt_regs
>>> *regs, unsigned int fsr)
>>> return 1;
>>>
>>> break;
>>> - default:
>>> - break;
>>> }
>>> return 0;
>>> }
>>> @@ -446,7 +439,6 @@ void __kprobes kprobe_handler(struct pt_regs *regs)
>>> * handling of this interrupt is appropriate.
>>> * Return back to original instruction, and continue.
>>> */
>>> - kprobes_restore_local_irqflag(regs);
>>> return;
>>> } else if (cur) {
>>> /* We probably hit a jprobe. Call its break handler. */
>>> @@ -459,7 +451,6 @@ void __kprobes kprobe_handler(struct pt_regs *regs)
>>> /* breakpoint is removed, now in a race
>>> * Return back to original instruction & continue.
>>> */
>>> - kprobes_restore_local_irqflag(regs);
>>> }
>>> }
>>>
>>> @@ -485,6 +476,7 @@ kprobe_single_step_handler(struct pt_regs *regs,
>>> unsigned int esr)
>>> retval = kprobe_ss_hit(kcb, instruction_pointer(regs));
>>>
>>> if (retval == DBG_HOOK_HANDLED) {
>>> + kprobes_restore_local_irqflag(regs);
>>> kernel_disable_single_step();
>>>
>>> if (kcb->kprobe_status == KPROBE_REENTER)
>>> @@ -499,7 +491,6 @@ kprobe_single_step_handler(struct pt_regs *regs,
>>> unsigned int esr)
>>> static int __kprobes
>>> kprobe_breakpoint_handler(struct pt_regs *regs, unsigned
Re: frequent lockups in 3.18rc4
On Sun, Dec 14, 2014 at 09:47:26PM -0800, Linus Torvalds wrote: > so it's always in __do_page_fault, but at sometimes it has gotten into > handle_mm_fault too. So it really really looks like it is taking an > endless stream of page faults on that "xsaveq" instruction. Presumably > the page faulting never actually makes any progress, even though it > *thinks* the page tables are fine. > > DaveJ - you've seen that "endless page faults" behavior before. You > had a few traces that showed it. That was in that whole "pipe/page > fault oddness." email thread, where you would get endless faults in > copy_page_to_iter() with an error_code=0x2. > > That was the one where I chased it down to "page table entry must be > marked with _PAGE_PROTNONE", but VM_WRITE in the vma, because your > machine was alive enough that you got traces out of the endless loop. We had a flashback to that old bug last month too. See this mail & your followup. : https://lkml.org/lkml/2014/11/25/1171 That was during a bisect though, so may have been something entirely different, but it is a spooky coincidence. Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] aio: changes for 3.19
On Sun, 14 Dec 2014 17:39:36 -0500 Benjamin LaHaise wrote:
> How about the documentation/comment updates below?
lgtm.
> ...
>
> +/* aio_ring_remap()
> + * Called when th aio event ring is being relocated within the process'
"the"
> + * address space. The primary purpose is to update the saved address of
> + * the aio event ring so that when the ioctx is detroyed, it gets removed
> + * from the correct userspace address. This is typically used when
> + * reloading a process back into memory by checkpoint-restore.
> + */
> static void aio_ring_remap(struct file *file, struct vm_area_struct *vma)
> {
> struct mm_struct *mm = vma->vm_mm;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: frequent lockups in 3.18rc4
On Sun, Dec 14, 2014 at 4:38 PM, Linus Torvalds wrote: > > Can anybody make sense of that backtrace, keeping in mind that we're > looking for some kind of endless loop where we don't make progress? So looking at all the backtraces, which is kind of messy because there's some missing data (presumably buffers overflowed from all the CPU's printing at the same time), it looks like: - CPU 0 is missing. No idea why. - CPU's 1-3 all have the same trace for int_signal -> do_notify_resume -> do_signal -> page_fault -> do_page_fault and "save_xstate_sig+0x81" shows up on all stacks, although only on CPU1 does it show up as a "guaranteed" part of the stack chain (ie it matches frame pointer data too). CPU1 also has that __clear_user show up (which is called from save_xstate_sig), but not other CPU's. CPU2 and CPU3 have "save_xstate_sig+0x98" in addition to that +0x81 thing. My guess is that "save_xstate_sig+0x81" is the instruction after the __clear_user call, and that CPU1 took the fault in __clear_user(), while CPU2 and CPU3 took the fault at "save_xstate_sig+0x98" instead, which I'd guess is the xsave64 (%rdi) and in fact, with CONFIG_FTRACE on, my own kernel build gives exactly those two offsets for those things in save_xstate_sig(). So I'm pretty certain that on all three CPU's, we had page faults for save_xstate_sig() accessing user space, with the only difference being that on CPU1 it happened from __clear_user, while on CPU's 2/3 it happened on the xsaveq instruction itself. That sounds like much more than coincidence. I have no idea where CPU0 is hiding, and all CPU's were at different stages of actually handling the fault, but that's to be expected if the page fault just keeps repeating. In fact, CPU2 shows up three different times, and the call trace changes in between, so it's "making progress", just never getting out of that loop. The traces are pagecache_get_page+0x0/0x220 ? lookup_swap_cache+0x2a/0x70 handle_mm_fault+0x401/0xe90 ? __do_page_fault+0x198/0x5c0 __do_page_fault+0x1fc/0x5c0 ? trace_hardirqs_on_thunk+0x3a/0x3f ? __do_softirq+0x1ed/0x310 ? retint_restore_args+0xe/0xe ? trace_hardirqs_off_thunk+0x3a/0x3c do_page_fault+0xc/0x10 page_fault+0x22/0x30 ? save_xstate_sig+0x98/0x220 ? save_xstate_sig+0x81/0x220 do_signal+0x5c7/0x740 ? _raw_spin_unlock_irq+0x30/0x40 do_notify_resume+0x65/0x80 ? trace_hardirqs_on_thunk+0x3a/0x3f int_signal+0x12/0x17 and ? __lock_acquire.isra.31+0x22c/0x9f0 ? lock_acquire+0xb4/0x120 ? __do_page_fault+0x198/0x5c0 down_read_trylock+0x5a/0x60 ? __do_page_fault+0x198/0x5c0 __do_page_fault+0x198/0x5c0 ? __do_softirq+0x1ed/0x310 ? retint_restore_args+0xe/0xe ? __do_page_fault+0xd8/0x5c0 ? trace_hardirqs_off_thunk+0x3a/0x3c do_page_fault+0xc/0x10 page_fault+0x22/0x30 ? save_xstate_sig+0x98/0x220 ? save_xstate_sig+0x81/0x220 do_signal+0x5c7/0x740 ? _raw_spin_unlock_irq+0x30/0x40 do_notify_resume+0x65/0x80 ? trace_hardirqs_on_thunk+0x3a/0x3f int_signal+0x12/0x17 and lock_acquire+0x40/0x120 down_read_trylock+0x5a/0x60 ? __do_page_fault+0x198/0x5c0 __do_page_fault+0x198/0x5c0 ? trace_hardirqs_on_thunk+0x3a/0x3f ? trace_hardirqs_on_thunk+0x3a/0x3f ? __do_softirq+0x1ed/0x310 ? retint_restore_args+0xe/0xe ? trace_hardirqs_off_thunk+0x3a/0x3c do_page_fault+0xc/0x10 page_fault+0x22/0x30 ? save_xstate_sig+0x98/0x220 ? save_xstate_sig+0x81/0x220 do_signal+0x5c7/0x740 ? _raw_spin_unlock_irq+0x30/0x40 do_notify_resume+0x65/0x80 ? trace_hardirqs_on_thunk+0x3a/0x3f int_signal+0x12/0x17 so it's always in __do_page_fault, but at sometimes it has gotten into handle_mm_fault too. So it really really looks like it is taking an endless stream of page faults on that "xsaveq" instruction. Presumably the page faulting never actually makes any progress, even though it *thinks* the page tables are fine. DaveJ - you've seen that "endless page faults" behavior before. You had a few traces that showed it. That was in that whole "pipe/page fault oddness." email thread, where you would get endless faults in copy_page_to_iter() with an error_code=0x2. That was the one where I chased it down to "page table entry must be marked with _PAGE_PROTNONE", but VM_WRITE in the vma, because your machine was alive enough that you got traces out of the endless loop. Very odd. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] workqueue: handle change in cpu-node relationship.
(2014/12/15 14:19), Lai Jiangshan wrote:
On 12/15/2014 12:04 PM, Kamezawa Hiroyuki wrote:
(2014/12/15 12:34), Lai Jiangshan wrote:
On 12/15/2014 10:55 AM, Kamezawa Hiroyuki wrote:
(2014/12/15 11:48), Lai Jiangshan wrote:
On 12/15/2014 10:20 AM, Kamezawa Hiroyuki wrote:
(2014/12/15 11:12), Lai Jiangshan wrote:
On 12/14/2014 12:38 AM, Kamezawa Hiroyuki wrote:
Although workqueue detects relationship between cpu<->node at boot,
it is finally determined in cpu_up().
This patch tries to update pool->node using online status of cpus.
1. When a node goes down, clear per-cpu pool's node attr.
2. When a cpu comes up, update per-cpu pool's node attr.
3. When a cpu comes up, update possinle node cpumask workqueue is using for
sched.
4. Detect the best node for unbound pool's cpumask using the latest info.
Signed-off-by: KAMEZAWA Hiroyuki
---
kernel/workqueue.c | 67
++
1 file changed, 53 insertions(+), 14 deletions(-)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 07b4eb5..259b3ba 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -266,7 +266,8 @@ struct workqueue_struct {
static struct kmem_cache *pwq_cache;
static cpumask_var_t *wq_numa_possible_cpumask;
-/* possible CPUs of each node */
+/* possible CPUs of each node initialized with possible info at boot.
+ but modified at cpu hotplug to be adjusted to real info. */
static bool wq_disable_numa;
module_param_named(disable_numa, wq_disable_numa, bool, 0444);
@@ -3449,6 +3450,31 @@ static void put_unbound_pool(struct worker_pool *pool)
call_rcu_sched(>rcu, rcu_free_pool);
}
+/*
+ * detect best node for given cpumask.
+ */
+static int pool_detect_best_node(const struct cpumask *cpumask)
+{
+int node, best, match, selected;
+static struct cpumask andmask; /* we're under mutex */
+
+/* Is any node okay ? */
+if (!wq_numa_enabled ||
+cpumask_subset(cpu_online_mask, cpumask))
+return NUMA_NO_NODE;
+best = 0;
+selected = NUMA_NO_NODE;
+/* select a node which contains the most cpu of cpumask */
+for_each_node_state(node, N_ONLINE) {
+cpumask_and(, cpumask, cpumask_of_node(node));
+match = cpumask_weight();
+if (match > best)
+selected = node;
+}
+return selected;
+}
+
+
/**
* get_unbound_pool - get a worker_pool with the specified attributes
* @attrs: the attributes of the worker_pool to get
@@ -3467,7 +3493,6 @@ static struct worker_pool *get_unbound_pool(const struct
workqueue_attrs *attrs)
{
u32 hash = wqattrs_hash(attrs);
struct worker_pool *pool;
-int node;
lockdep_assert_held(_pool_mutex);
@@ -3492,17 +3517,7 @@ static struct worker_pool *get_unbound_pool(const struct
workqueue_attrs *attrs)
* 'struct workqueue_attrs' comments for detail.
*/
pool->attrs->no_numa = false;
-
-/* if cpumask is contained inside a NUMA node, we belong to that node */
-if (wq_numa_enabled) {
-for_each_node(node) {
-if (cpumask_subset(pool->attrs->cpumask,
- wq_numa_possible_cpumask[node])) {
-pool->node = node;
-break;
-}
-}
-}
+pool->node = pool_detect_best_node(pool->attrs->cpumask);
if (worker_pool_assign_id(pool) < 0)
goto fail;
@@ -4567,7 +4582,7 @@ static int workqueue_cpu_up_callback(struct
notifier_block *nfb,
int cpu = (unsigned long)hcpu;
struct worker_pool *pool;
struct workqueue_struct *wq;
-int pi;
+int pi, node;
switch (action & ~CPU_TASKS_FROZEN) {
case CPU_UP_PREPARE:
@@ -4583,6 +4598,16 @@ static int workqueue_cpu_up_callback(struct
notifier_block *nfb,
case CPU_ONLINE:
mutex_lock(_pool_mutex);
+/* now cpu <-> node info is established, update the info. */
+if (!wq_disable_numa) {
+for_each_node_state(node, N_POSSIBLE)
+cpumask_clear_cpu(cpu,
+wq_numa_possible_cpumask[node]);
The wq code try to reuse the origin pwqs/pools when the node still have cpu
online.
these 3 lines of code will cause the origin pwqs/pools be on the road of dying,
and
create a new set of pwqs/pools.
because the result of wq_calc_node_cpumask() changes ?
Yes.
Do you mean some comment should be added here ? or explaination for your reply
for [3/4] ?
this fix [4/4] breaks the original design.
I'm sorry that I can't understand what this patch breaks.
the pwqs/pools should be kept if the node still have cpu online.
So, the fix's grand design should be
1. drop old pwq/pools only at node offline.
2. set proper pool->node based on online node info.
3. update pool->node of per-cpu-pool at cpu ONLINE.
Hm. (1) is done because cpumask_of_node() turns to be zero-filled
[PATCH 7/8] swap: use direct I/O for SWP_FILE swap_readpage
On Mon, Nov 17, 2014 at 07:48:17AM -0800, Christoph Hellwig wrote:
> With the new iov_iter infrastructure that supprots direct I/O to kernel
> pages please get rid of the ->readpage hack first. I'm still utterly
> disapoined that this crap ever got merged.
Signed-off-by: Omar Sandoval
---
mm/page_io.c | 25 +++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/mm/page_io.c b/mm/page_io.c
index 4741248..956307c 100644
--- a/mm/page_io.c
+++ b/mm/page_io.c
@@ -346,12 +346,33 @@ int swap_readpage(struct page *page)
}
if (sis->flags & SWP_FILE) {
+ struct kiocb kiocb;
struct file *swap_file = sis->swap_file;
struct address_space *mapping = swap_file->f_mapping;
+ struct iov_iter to;
+ struct bio_vec bv = {
+ .bv_page = page,
+ .bv_len = PAGE_SIZE,
+ .bv_offset = 0,
+ };
+
+ iov_iter_bvec(, ITER_BVEC | READ, , 1, PAGE_SIZE);
- ret = mapping->a_ops->readpage(swap_file, page);
- if (!ret)
+ init_sync_kiocb(, swap_file);
+ kiocb.ki_pos = page_file_offset(page);
+ kiocb.ki_nbytes = PAGE_SIZE;
+
+ ret = mapping->a_ops->direct_IO(READ, , ,
+ kiocb.ki_pos);
+ if (ret == PAGE_SIZE) {
+ SetPageUptodate(page);
count_vm_event(PSWPIN);
+ ret = 0;
+ } else {
+ ClearPageUptodate(page);
+ SetPageError(page);
+ }
+ unlock_page(page);
return ret;
}
--
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] vmcore: fix PT_NOTE n_namesz, n_descsz overflow issue
When updating PT_NOTE header size (ie. p_memsz), an overflow issue
happens with the following bogus note entry:
n_namesz = 0x
n_descsz = 0x0
n_type = 0x0
This kind of note entry should be dropped during updating p_memsz. But
because n_namesz is 32bit, after (n_namesz + 3) & (~3), it's overflow to
0x0, the note entry size looks sane and reserved.
When user space (eg. crash utility) is trying to access such bogus note,
it could lead to an unexpected behavior (eg. crash utility segment
fault because it's reading bogus address).
The source of bogus note hasn't been identified yet. At least we could
drop the bogus note so user space wouldn't be surprised.
Signed-off-by: WANG Chao
---
fs/proc/vmcore.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c
index a90d6d35..4e61388 100644
--- a/fs/proc/vmcore.c
+++ b/fs/proc/vmcore.c
@@ -546,8 +546,8 @@ static int __init update_note_header_size_elf64(const
Elf64_Ehdr *ehdr_ptr)
nhdr_ptr = notes_section;
while (nhdr_ptr->n_namesz != 0) {
sz = sizeof(Elf64_Nhdr) +
- ((nhdr_ptr->n_namesz + 3) & ~3) +
- ((nhdr_ptr->n_descsz + 3) & ~3);
+ (((u64)nhdr_ptr->n_namesz + 3) & ~3) +
+ (((u64)nhdr_ptr->n_descsz + 3) & ~3);
if ((real_sz + sz) > max_sz) {
pr_warn("Warning: Exceeded p_memsz, dropping
PT_NOTE entry n_namesz=0x%x, n_descsz=0x%x\n",
nhdr_ptr->n_namesz, nhdr_ptr->n_descsz);
@@ -732,8 +732,8 @@ static int __init update_note_header_size_elf32(const
Elf32_Ehdr *ehdr_ptr)
nhdr_ptr = notes_section;
while (nhdr_ptr->n_namesz != 0) {
sz = sizeof(Elf32_Nhdr) +
- ((nhdr_ptr->n_namesz + 3) & ~3) +
- ((nhdr_ptr->n_descsz + 3) & ~3);
+ (((u64)nhdr_ptr->n_namesz + 3) & ~3) +
+ (((u64)nhdr_ptr->n_descsz + 3) & ~3);
if ((real_sz + sz) > max_sz) {
pr_warn("Warning: Exceeded p_memsz, dropping
PT_NOTE entry n_namesz=0x%x, n_descsz=0x%x\n",
nhdr_ptr->n_namesz, nhdr_ptr->n_descsz);
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/8] swap: lock i_mutex for swap_writepage direct_IO
The generic write code locks i_mutex for a direct_IO. Swap-over-NFS
doesn't grab the mutex because nfs_direct_IO doesn't expect i_mutex to
be held, but most direct_IO implementations do.
Signed-off-by: Omar Sandoval
---
mm/page_io.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/mm/page_io.c b/mm/page_io.c
index 955db8b..1630ac0 100644
--- a/mm/page_io.c
+++ b/mm/page_io.c
@@ -263,6 +263,7 @@ int __swap_writepage(struct page *page, struct
writeback_control *wbc,
if (sis->flags & SWP_FILE) {
struct kiocb kiocb;
struct file *swap_file = sis->swap_file;
+ struct inode *inode = file_inode(swap_file);
struct address_space *mapping = swap_file->f_mapping;
struct bio_vec bv = {
.bv_page = page,
@@ -283,9 +284,11 @@ int __swap_writepage(struct page *page, struct
writeback_control *wbc,
set_page_writeback(page);
unlock_page(page);
+ mutex_lock(>i_mutex);
ret = mapping->a_ops->direct_IO(ITER_BVEC | WRITE,
, ,
kiocb.ki_pos);
+ mutex_unlock(>i_mutex);
if (ret == PAGE_SIZE) {
count_vm_event(PSWPOUT);
ret = 0;
--
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/8] nfs: don't dirty ITER_BVEC pages read through direct I/O
As with the generic blockdev code, kernel pages shouldn't be dirtied by
the direct I/O path.
Signed-off-by: Omar Sandoval
---
fs/nfs/direct.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/fs/nfs/direct.c b/fs/nfs/direct.c
index 9402b96..a502b3f 100644
--- a/fs/nfs/direct.c
+++ b/fs/nfs/direct.c
@@ -88,6 +88,7 @@ struct nfs_direct_req {
struct pnfs_ds_commit_info ds_cinfo;/* Storage for cinfo */
struct work_struct work;
int flags;
+ int should_dirty; /* should we mark read pages
dirty? */
#define NFS_ODIRECT_DO_COMMIT (1) /* an unstable reply was
received */
#define NFS_ODIRECT_RESCHED_WRITES (2) /* write verification failed */
struct nfs_writeverfverf; /* unstable write verifier */
@@ -370,7 +371,8 @@ static void nfs_direct_read_completion(struct
nfs_pgio_header *hdr)
struct nfs_page *req = nfs_list_entry(hdr->pages.next);
struct page *page = req->wb_page;
- if (!PageCompound(page) && bytes < hdr->good_bytes)
+ if (!PageCompound(page) && bytes < hdr->good_bytes &&
+ dreq->should_dirty)
set_page_dirty(page);
bytes += req->wb_bytes;
nfs_list_remove_request(req);
@@ -542,6 +544,7 @@ ssize_t nfs_file_direct_read(struct kiocb *iocb, struct
iov_iter *iter,
dreq->inode = inode;
dreq->bytes_left = count;
dreq->ctx = get_nfs_open_context(nfs_file_open_context(iocb->ki_filp));
+ dreq->should_dirty = !(iter->type & ITER_BVEC);
l_ctx = nfs_get_lock_context(dreq->ctx);
if (IS_ERR(l_ctx)) {
result = PTR_ERR(l_ctx);
--
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 8/8] vfs: update swap_{,de}activate documentation
Parameters were added to swap_activate in the same patch series that
introduced it without updating the documentation. Additionally, the
documentation claims that non-existent address space operations
swap_{in,out} are used for swap I/O, but it's (now) direct_IO.
Signed-off-by: Omar Sandoval
---
Documentation/filesystems/Locking | 7 ---
Documentation/filesystems/vfs.txt | 7 ---
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/Documentation/filesystems/Locking
b/Documentation/filesystems/Locking
index b30753c..e72b4c3 100644
--- a/Documentation/filesystems/Locking
+++ b/Documentation/filesystems/Locking
@@ -205,7 +205,8 @@ prototypes:
int (*launder_page)(struct page *);
int (*is_partially_uptodate)(struct page *, unsigned long, unsigned
long);
int (*error_remove_page)(struct address_space *, struct page *);
- int (*swap_activate)(struct file *);
+ int (*swap_activate)(struct swap_info_struct *, struct file *,
+sector_t *);
int (*swap_deactivate)(struct file *);
locking rules:
@@ -230,8 +231,8 @@ migratepage:yes (both)
launder_page: yes
is_partially_uptodate: yes
error_remove_page: yes
-swap_activate: no
-swap_deactivate: no
+swap_activate: yes
+swap_deactivate: no
->write_begin(), ->write_end(), ->sync_page() and ->readpage()
may be called from the request handler (/dev/loop).
diff --git a/Documentation/filesystems/vfs.txt
b/Documentation/filesystems/vfs.txt
index 43ce050..a7c7974 100644
--- a/Documentation/filesystems/vfs.txt
+++ b/Documentation/filesystems/vfs.txt
@@ -600,8 +600,9 @@ struct address_space_operations {
unsigned long);
void (*is_dirty_writeback) (struct page *, bool *, bool *);
int (*error_remove_page) (struct mapping *mapping, struct page *page);
- int (*swap_activate)(struct file *);
- int (*swap_deactivate)(struct file *);
+ int (*swap_activate)(struct swap_info_struct *, struct file *,
+sector_t *);
+ void (*swap_deactivate)(struct file *);
};
writepage: called by the VM to write a dirty page to backing store.
@@ -788,7 +789,7 @@ struct address_space_operations {
memory. A return value of zero indicates success,
in which case this file can be used to back swapspace. The
swapspace operations will be proxied to this address space's
- ->swap_{out,in} methods.
+ ->direct_IO method for both reads and writes.
swap_deactivate: Called during swapoff on files where swap_activate
was successful.
--
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/8] iov_iter: add iov_iter_bvec and convert callers
Signed-off-by: Omar Sandoval
---
fs/splice.c | 7 ++-
include/linux/uio.h | 2 ++
mm/iov_iter.c | 12
mm/page_io.c| 14 +-
4 files changed, 21 insertions(+), 14 deletions(-)
diff --git a/fs/splice.c b/fs/splice.c
index 75c6058..7c7176f 100644
--- a/fs/splice.c
+++ b/fs/splice.c
@@ -1006,11 +1006,8 @@ iter_file_splice_write(struct pipe_inode_info *pipe,
struct file *out,
}
/* ... iov_iter */
- from.type = ITER_BVEC | WRITE;
- from.bvec = array;
- from.nr_segs = n;
- from.count = sd.total_len - left;
- from.iov_offset = 0;
+ iov_iter_bvec(, ITER_BVEC | WRITE, array, n,
+ sd.total_len - left);
/* ... and iocb */
init_sync_kiocb(, out);
diff --git a/include/linux/uio.h b/include/linux/uio.h
index bd8569a..d1a34b4 100644
--- a/include/linux/uio.h
+++ b/include/linux/uio.h
@@ -90,6 +90,8 @@ void iov_iter_init(struct iov_iter *i, int direction, const
struct iovec *iov,
unsigned long nr_segs, size_t count);
void iov_iter_kvec(struct iov_iter *i, int direction, const struct kvec *iov,
unsigned long nr_segs, size_t count);
+void iov_iter_bvec(struct iov_iter *i, int direction, const struct bio_vec *bv,
+ unsigned long nr_segs, size_t count);
ssize_t iov_iter_get_pages(struct iov_iter *i, struct page **pages,
size_t maxsize, unsigned maxpages, size_t *start);
ssize_t iov_iter_get_pages_alloc(struct iov_iter *i, struct page ***pages,
diff --git a/mm/iov_iter.c b/mm/iov_iter.c
index a1599ca..c975bc4 100644
--- a/mm/iov_iter.c
+++ b/mm/iov_iter.c
@@ -513,6 +513,18 @@ void iov_iter_kvec(struct iov_iter *i, int direction,
}
EXPORT_SYMBOL(iov_iter_kvec);
+void iov_iter_bvec(struct iov_iter *i, int direction, const struct bio_vec *bv,
+ unsigned long nr_segs, size_t count)
+{
+ BUG_ON(!(direction & ITER_BVEC));
+ i->type = direction;
+ i->bvec = bv;
+ i->nr_segs = nr_segs;
+ i->iov_offset = 0;
+ i->count = count;
+}
+EXPORT_SYMBOL(iov_iter_bvec);
+
unsigned long iov_iter_alignment(const struct iov_iter *i)
{
unsigned long res = 0;
diff --git a/mm/page_io.c b/mm/page_io.c
index c229f88..4741248 100644
--- a/mm/page_io.c
+++ b/mm/page_io.c
@@ -265,18 +265,14 @@ int __swap_writepage(struct page *page, struct
writeback_control *wbc,
struct file *swap_file = sis->swap_file;
struct inode *inode = file_inode(swap_file);
struct address_space *mapping = swap_file->f_mapping;
+ struct iov_iter from;
struct bio_vec bv = {
.bv_page = page,
- .bv_len = PAGE_SIZE,
- .bv_offset = 0
+ .bv_len = PAGE_SIZE,
+ .bv_offset = 0,
};
- struct iov_iter from = {
- .type = ITER_BVEC | WRITE,
- .count = PAGE_SIZE,
- .iov_offset = 0,
- .nr_segs = 1,
- };
- from.bvec = /* older gcc versions are broken */
+
+ iov_iter_bvec(, ITER_BVEC | WRITE, , 1, PAGE_SIZE);
init_sync_kiocb(, swap_file);
kiocb.ki_pos = page_file_offset(page);
--
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/8] swap: don't add ITER_BVEC flag to direct_IO rw
The rw argument to direct_IO has some ill-defined semantics. Some
filesystems (e.g., ext4, FAT) decide whether they're doing a write with
rw == WRITE, but others (e.g., XFS) check rw & WRITE. Let's set a good
example in the swap file code and say ITER_BVEC belongs in
iov_iter->flags but not in rw. This caters to the least common
denominator and avoids a sweeping change of every direct_IO
implementation for now.
Signed-off-by: Omar Sandoval
---
mm/page_io.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/mm/page_io.c b/mm/page_io.c
index 1630ac0..c229f88 100644
--- a/mm/page_io.c
+++ b/mm/page_io.c
@@ -285,8 +285,7 @@ int __swap_writepage(struct page *page, struct
writeback_control *wbc,
set_page_writeback(page);
unlock_page(page);
mutex_lock(>i_mutex);
- ret = mapping->a_ops->direct_IO(ITER_BVEC | WRITE,
- , ,
+ ret = mapping->a_ops->direct_IO(WRITE, , ,
kiocb.ki_pos);
mutex_unlock(>i_mutex);
if (ret == PAGE_SIZE) {
--
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/8] clean up and generalize swap-over-NFS
Hi, everyone,
This patch series contains all of the non-BTRFS changes that I've made
as a part of implementing swap file support on BTRFS. The BTRFS parts of
that series (https://lkml.org/lkml/2014/12/9/718) are still undergoing
development, and the non-BTRFS changes now outnumber those within BTRFS,
so it'll probably work best to get these in separately.
Long story short, the generic swap file infrastructure introduced for
swap-over-NFS isn't quite ready for other clients without making some
changes.
Before I forget, this patch series was built against cbfe0de in Linus'
tree (to avoid conflicts with the recent iov_iter work).
Patches 1 and 2 fix an issue with NFS and the swap file infrastructure
not following the direct_IO locking conventions, leading to locking
issues for anyone else trying to use the interface (discussed here:
https://lkml.org/lkml/2014/12/12/677).
Patch 3 removes the ITER_BVEC flag from the rw argument passed to
direct_IO, as many, but not all, direct_IO implementations expect either
rw == READ or rw == WRITE. The lack of documentation about what's
correct here is probably going to break something at some point, but
that's another conversation.
Patch 4 adds iov_iter_bvec for swap_writepage, the upcoming
swap_readpage change, and splice.
Patches 5 and 6 are preparation for patch 7, teaching the VFS and NFS to
handle ITER_BVEC reads.
Patch 7 is the biggest change in the series: it changes swap_readpage to
proxy through ->direct_IO rather than ->readpage. Using readpage for a
swapcache page requires all sorts of messy workarounds (see here for
context: https://lkml.org/lkml/2014/11/19/46). Patch 8 updates the
documentation accordingly.
Thanks!
Omar Sandoval (8):
nfs: follow direct I/O write locking convention
swap: lock i_mutex for swap_writepage direct_IO
swap: don't add ITER_BVEC flag to direct_IO rw
iov_iter: add iov_iter_bvec and convert callers
direct-io: don't dirty ITER_BVEC pages on read
nfs: don't dirty ITER_BVEC pages read through direct I/O
swap: use direct I/O for SWP_FILE swap_readpage
vfs: update swap_{,de}activate documentation
Documentation/filesystems/Locking | 7 +++---
Documentation/filesystems/vfs.txt | 7 +++---
fs/direct-io.c| 8 ---
fs/nfs/direct.c | 17 ---
fs/nfs/file.c | 8 +--
fs/splice.c | 7 ++
include/linux/uio.h | 2 ++
mm/iov_iter.c | 12 +++
mm/page_io.c | 45 ---
9 files changed, 76 insertions(+), 37 deletions(-)
--
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/8] direct-io: don't dirty ITER_BVEC pages on read
Reads through the iov_iter infrastructure for kernel pages shouldn't be
dirtied by the direct I/O code.
This is based on Dave Kleikamp's and Ming Lei's previously posted
patches.
Cc: Ming Lei
Acked-by: Dave Kleikamp
Signed-off-by: Omar Sandoval
---
fs/direct-io.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/fs/direct-io.c b/fs/direct-io.c
index e181b6b..e542ce4 100644
--- a/fs/direct-io.c
+++ b/fs/direct-io.c
@@ -120,6 +120,7 @@ struct dio {
spinlock_t bio_lock;/* protects BIO fields below */
int page_errors;/* errno from get_user_pages() */
int is_async; /* is IO async ? */
+ int should_dirty; /* should we mark read pages dirty? */
bool defer_completion; /* defer AIO completion to workqueue? */
int io_error; /* IO error in completion path */
unsigned long refcount; /* direct_io_worker() and bios */
@@ -392,7 +393,7 @@ static inline void dio_bio_submit(struct dio *dio, struct
dio_submit *sdio)
dio->refcount++;
spin_unlock_irqrestore(>bio_lock, flags);
- if (dio->is_async && dio->rw == READ)
+ if (dio->is_async && dio->rw == READ && dio->should_dirty)
bio_set_pages_dirty(bio);
if (sdio->submit_io)
@@ -463,13 +464,13 @@ static int dio_bio_complete(struct dio *dio, struct bio
*bio)
if (!uptodate)
dio->io_error = -EIO;
- if (dio->is_async && dio->rw == READ) {
+ if (dio->is_async && dio->rw == READ && dio->should_dirty) {
bio_check_pages_dirty(bio); /* transfers ownership */
} else {
bio_for_each_segment_all(bvec, bio, i) {
struct page *page = bvec->bv_page;
- if (dio->rw == READ && !PageCompound(page))
+ if (dio->rw == READ && !PageCompound(page) &&
dio->should_dirty)
set_page_dirty_lock(page);
page_cache_release(page);
}
@@ -1177,6 +1178,7 @@ do_blockdev_direct_IO(int rw, struct kiocb *iocb, struct
inode *inode,
dio->inode = inode;
dio->rw = rw;
+ dio->should_dirty = !(iter->type & ITER_BVEC);
/*
* For AIO O_(D)SYNC writes we need to defer completions to a workqueue
--
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/8] nfs: follow direct I/O write locking convention
The generic callers of direct_IO lock i_mutex before doing a write. NFS
doesn't use the generic write code, so it doesn't follow this
convention. This is now a problem because the interface introduced for
swap-over-NFS calls direct_IO for a write without holding i_mutex, but
other implementations of direct_IO will expect to have it locked.
Signed-off-by: Omar Sandoval
---
fs/nfs/direct.c | 12 +---
fs/nfs/file.c | 8 ++--
2 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/fs/nfs/direct.c b/fs/nfs/direct.c
index 10bf072..9402b96 100644
--- a/fs/nfs/direct.c
+++ b/fs/nfs/direct.c
@@ -906,17 +906,15 @@ ssize_t nfs_file_direct_write(struct kiocb *iocb, struct
iov_iter *iter,
if (!count)
goto out;
- mutex_lock(>i_mutex);
-
result = nfs_sync_mapping(mapping);
if (result)
- goto out_unlock;
+ goto out;
if (mapping->nrpages) {
result = invalidate_inode_pages2_range(mapping,
pos >> PAGE_CACHE_SHIFT, end);
if (result)
- goto out_unlock;
+ goto out;
}
task_io_account_write(count);
@@ -924,7 +922,7 @@ ssize_t nfs_file_direct_write(struct kiocb *iocb, struct
iov_iter *iter,
result = -ENOMEM;
dreq = nfs_direct_req_alloc();
if (!dreq)
- goto out_unlock;
+ goto out;
dreq->inode = inode;
dreq->bytes_left = count;
@@ -960,12 +958,12 @@ ssize_t nfs_file_direct_write(struct kiocb *iocb, struct
iov_iter *iter,
}
}
nfs_direct_req_release(dreq);
+
+ mutex_lock(>i_mutex);
return result;
out_release:
nfs_direct_req_release(dreq);
-out_unlock:
- mutex_unlock(>i_mutex);
out:
return result;
}
diff --git a/fs/nfs/file.c b/fs/nfs/file.c
index 2ab6f00..8b80276 100644
--- a/fs/nfs/file.c
+++ b/fs/nfs/file.c
@@ -675,8 +675,12 @@ ssize_t nfs_file_write(struct kiocb *iocb, struct iov_iter
*from)
if (result)
return result;
- if (file->f_flags & O_DIRECT)
- return nfs_file_direct_write(iocb, from, pos);
+ if (file->f_flags & O_DIRECT) {
+ mutex_lock(>i_mutex);
+ result = nfs_file_direct_write(iocb, from, pos);
+ mutex_unlock(>i_mutex);
+ return result;
+ }
dprintk("NFS: write(%pD2, %zu@%Ld)\n",
file, count, (long long) pos);
--
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] workqueue: fix memory leak in wq_numa_init()
On 12/13/2014 01:12 AM, Tejun Heo wrote:
> On Fri, Dec 12, 2014 at 06:19:51PM +0800, Lai Jiangshan wrote:
>> wq_numa_init() will quit directly on some bonkers cases without freeing the
>> memory. Add the missing cleanup code.
>>
>> Cc: Tejun Heo
>> Cc: Yasuaki Ishimatsu
>> Cc: "Gu, Zheng"
>> Cc: tangchen
>> Cc: Hiroyuki KAMEZAWA
>> Signed-off-by: Lai Jiangshan
>> ---
>> kernel/workqueue.c |3 +++
>> 1 files changed, 3 insertions(+), 0 deletions(-)
>>
>> diff --git a/kernel/workqueue.c b/kernel/workqueue.c
>> index 09b685d..a6fd2b8 100644
>> --- a/kernel/workqueue.c
>> +++ b/kernel/workqueue.c
>> @@ -4811,6 +4811,9 @@ static void __init wq_numa_init(void)
>> if (WARN_ON(node == NUMA_NO_NODE)) {
>> pr_warn("workqueue: NUMA node mapping not available for
>> cpu%d, disabling NUMA support\n", cpu);
>> /* happens iff arch is bonkers, let's just proceed */
>> +for_each_node(node)
>> +free_cpumask_var(tbl[node]);
>> +kfree(tbl);
>
> The comment right up there says that this happens if and only if the
> arch code is seriously broken and it's consciously skipping exception
> handling. That's a condition where we might as well trigger BUG_ON().
> Just leave it alone.
cpu_to_node() can return NUMA_NO_NODE after system booted (when node offline)
currently.
so I don't think it is seriously broken if cpu_to_node() returns NUMA_NO_NODE
when booting.
See:
static void unmap_cpu_on_node(pg_data_t *pgdat)
{
#ifdef CONFIG_ACPI_NUMA
int cpu;
for_each_possible_cpu(cpu)
if (cpu_to_node(cpu) == pgdat->node_id)
numa_clear_node(cpu);
#endif
}
>
> Thanks.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] xen: build infrastructure for generating hypercall depending symbols
On 12/12/2014 11:48 PM, Boris Ostrovsky wrote:
On 12/11/2014 01:04 PM, Juergen Gross wrote:
diff --git a/scripts/xen-hypercalls.sh b/scripts/xen-hypercalls.sh
new file mode 100644
index 000..e6447b7
--- /dev/null
+++ b/scripts/xen-hypercalls.sh
@@ -0,0 +1,11 @@
+#!/bin/sh
+out="$1"
+shift
+in="$@"
+
+for i in $in; do
+eval $CPP $LINUXINCLUDE -dD -imacros "$i" -x c /dev/null
+done | \
+awk '$1 == "#define" && $2 ~ /__HYPERVISOR_[a-z][a-z_0-9]*/ { v[$3] =
$2 }
+END {for (i in v) if (!(v[i] in v))
+print "HYPERCALL("substr(v[i], 14)")"}' | sort -u >$out
Why do you 'sort -u'? Do you expect multiple definitions of the same
hypercall?
Paranoia related to the use of wildcards for files scanned:
$(srctree)/include/xen/interface/xen*.h
Juergen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [3.18+] Can't boot with commit bd809af1 ("x86: Enable PAT to use cache mode translation tables")
On 12/14/2014 06:07 AM, 허종만 wrote: > > Hi, > > My Linux virtual machine on (Windows) VMWare workstation 10 can't boot with > following commit. > > commit bd809af16e3ab1f8d55b3e2928c47c67e2a865d2 > Author: Juergen Gross > Date: Mon Nov 3 14:02:03 2014 +0100 > > x86: Enable PAT to use cache mode translation tables > > Unfortunately I can't see any console log. Hmm, weird. Could you provide some more information? Kernel config, hardware used, /proc/cpuinfo of working kernel? Anything you see with earlyprintk enabled? Juergen > Reverting the commit fixes my boot issue. git bisect log follows, > > $ git bisect log > git bisect start > # bad: [92a578b064d0227a3a7fbbdb9e29dbab7f8d400e] Merge tag > 'pm+acpi-3.19-rc1' of > git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm > git bisect bad 92a578b064d0227a3a7fbbdb9e29dbab7f8d400e > # good: [b2776bf7149bddd1f4161f14f79520f17fc1d71d] Linux 3.18 > git bisect good b2776bf7149bddd1f4161f14f79520f17fc1d71d > # good: [6da314122ddc11936c6f054753bbb956a499d020] Merge tag 'dt-for-linus' > of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc > git bisect good 6da314122ddc11936c6f054753bbb956a499d020 > # good: [482a3767e5087f6e6ad2486a6655aaa5f3d59301] exit: reparent: call > forget_original_parent() under tasklist_lock > git bisect good 482a3767e5087f6e6ad2486a6655aaa5f3d59301 > # bad: [cbfe0de303a55ed96d8831c2d5f56f8131cd6612] Merge branch 'for-linus' of > git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs > git bisect bad cbfe0de303a55ed96d8831c2d5f56f8131cd6612 > # bad: [a6b849578ef3e0b131b1ea4063473a4f935a65e9] Merge branch 'for-linus' of > git://git.samba.org/sfrench/cifs-2.6 > git bisect bad a6b849578ef3e0b131b1ea4063473a4f935a65e9 > # bad: [c9f861c77269bc9950c16c6404a9476062241671] Merge branch > 'x86-ras-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip > git bisect bad c9f861c77269bc9950c16c6404a9476062241671 > # good: [773fed910d41e443e495a6bfa9ab1c2b7b13e012] Merge branches > 'x86-platform-for-linus' and 'x86-uv-for-linus' of > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip > git bisect good 773fed910d41e443e495a6bfa9ab1c2b7b13e012 > # good: [773fed910d41e443e495a6bfa9ab1c2b7b13e012] Merge branches > 'x86-platform-for-linus' and 'x86-uv-for-linus' of > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip > git bisect good 773fed910d41e443e495a6bfa9ab1c2b7b13e012 > # good: [f439c429c320981943f8b64b2a4049d946cb492b] x86: Support PAT bit in > pagetable dump for lower levels > git bisect good f439c429c320981943f8b64b2a4049d946cb492b > # good: [e3480271f59253cb60d030aa5e615bf00b731fea] x86, mce, severity: Extend > the the mce_severity mechanism to handle UCNA/DEFERRED error > git bisect good e3480271f59253cb60d030aa5e615bf00b731fea > # bad: [0dbcae884779fdf7e2239a97ac7488877f0693d9] x86: mm: Move PAT only > functions to mm/pat.c > git bisect bad 0dbcae884779fdf7e2239a97ac7488877f0693d9 > # bad: [bd809af16e3ab1f8d55b3e2928c47c67e2a865d2] x86: Enable PAT to use > cache mode translation tables > git bisect bad bd809af16e3ab1f8d55b3e2928c47c67e2a865d2 > # good: [f5b2831d654167d77da8afbef4d2584897b12d0c] x86: Respect PAT bit when > copying pte values between large and normal pages > git bisect good f5b2831d654167d77da8afbef4d2584897b12d0c > # first bad commit: [bd809af16e3ab1f8d55b3e2928c47c67e2a865d2] x86: Enable > PAT to use cache mode translation tables > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] workqueue: handle change in cpu-node relationship.
On 12/15/2014 12:04 PM, Kamezawa Hiroyuki wrote:
> (2014/12/15 12:34), Lai Jiangshan wrote:
>> On 12/15/2014 10:55 AM, Kamezawa Hiroyuki wrote:
>>> (2014/12/15 11:48), Lai Jiangshan wrote:
On 12/15/2014 10:20 AM, Kamezawa Hiroyuki wrote:
> (2014/12/15 11:12), Lai Jiangshan wrote:
>> On 12/14/2014 12:38 AM, Kamezawa Hiroyuki wrote:
>>> Although workqueue detects relationship between cpu<->node at boot,
>>> it is finally determined in cpu_up().
>>> This patch tries to update pool->node using online status of cpus.
>>>
>>> 1. When a node goes down, clear per-cpu pool's node attr.
>>> 2. When a cpu comes up, update per-cpu pool's node attr.
>>> 3. When a cpu comes up, update possinle node cpumask workqueue is using
>>> for sched.
>>> 4. Detect the best node for unbound pool's cpumask using the latest
>>> info.
>>>
>>> Signed-off-by: KAMEZAWA Hiroyuki
>>> ---
>>> kernel/workqueue.c | 67
>>> ++
>>> 1 file changed, 53 insertions(+), 14 deletions(-)
>>>
>>> diff --git a/kernel/workqueue.c b/kernel/workqueue.c
>>> index 07b4eb5..259b3ba 100644
>>> --- a/kernel/workqueue.c
>>> +++ b/kernel/workqueue.c
>>> @@ -266,7 +266,8 @@ struct workqueue_struct {
>>> static struct kmem_cache *pwq_cache;
>>>
>>> static cpumask_var_t *wq_numa_possible_cpumask;
>>> -/* possible CPUs of each node */
>>> +/* possible CPUs of each node initialized with possible info at
>>> boot.
>>> + but modified at cpu hotplug to be adjusted to real info. */
>>>
>>> static bool wq_disable_numa;
>>> module_param_named(disable_numa, wq_disable_numa, bool, 0444);
>>> @@ -3449,6 +3450,31 @@ static void put_unbound_pool(struct worker_pool
>>> *pool)
>>> call_rcu_sched(>rcu, rcu_free_pool);
>>> }
>>>
>>> +/*
>>> + * detect best node for given cpumask.
>>> + */
>>> +static int pool_detect_best_node(const struct cpumask *cpumask)
>>> +{
>>> +int node, best, match, selected;
>>> +static struct cpumask andmask; /* we're under mutex */
>>> +
>>> +/* Is any node okay ? */
>>> +if (!wq_numa_enabled ||
>>> +cpumask_subset(cpu_online_mask, cpumask))
>>> +return NUMA_NO_NODE;
>>> +best = 0;
>>> +selected = NUMA_NO_NODE;
>>> +/* select a node which contains the most cpu of cpumask */
>>> +for_each_node_state(node, N_ONLINE) {
>>> +cpumask_and(, cpumask, cpumask_of_node(node));
>>> +match = cpumask_weight();
>>> +if (match > best)
>>> +selected = node;
>>> +}
>>> +return selected;
>>> +}
>>> +
>>> +
>>> /**
>>> * get_unbound_pool - get a worker_pool with the specified
>>> attributes
>>> * @attrs: the attributes of the worker_pool to get
>>> @@ -3467,7 +3493,6 @@ static struct worker_pool *get_unbound_pool(const
>>> struct workqueue_attrs *attrs)
>>> {
>>> u32 hash = wqattrs_hash(attrs);
>>> struct worker_pool *pool;
>>> -int node;
>>>
>>> lockdep_assert_held(_pool_mutex);
>>>
>>> @@ -3492,17 +3517,7 @@ static struct worker_pool
>>> *get_unbound_pool(const struct workqueue_attrs *attrs)
>>> * 'struct workqueue_attrs' comments for detail.
>>> */
>>> pool->attrs->no_numa = false;
>>> -
>>> -/* if cpumask is contained inside a NUMA node, we belong to that
>>> node */
>>> -if (wq_numa_enabled) {
>>> -for_each_node(node) {
>>> -if (cpumask_subset(pool->attrs->cpumask,
>>> - wq_numa_possible_cpumask[node])) {
>>> -pool->node = node;
>>> -break;
>>> -}
>>> -}
>>> -}
>>> +pool->node = pool_detect_best_node(pool->attrs->cpumask);
>>>
>>> if (worker_pool_assign_id(pool) < 0)
>>> goto fail;
>>> @@ -4567,7 +4582,7 @@ static int workqueue_cpu_up_callback(struct
>>> notifier_block *nfb,
>>> int cpu = (unsigned long)hcpu;
>>> struct worker_pool *pool;
>>> struct workqueue_struct *wq;
>>> -int pi;
>>> +int pi, node;
>>>
>>> switch (action & ~CPU_TASKS_FROZEN) {
>>> case CPU_UP_PREPARE:
>>> @@ -4583,6 +4598,16 @@ static int workqueue_cpu_up_callback(struct
>>> notifier_block *nfb,
>>> case CPU_ONLINE:
>>> mutex_lock(_pool_mutex);
>>>
>>> +/* now cpu <-> node info is established, update the info. */
>>> +if (!wq_disable_numa) {
>>
>>
>>
>>> +for_each_node_state(node, N_POSSIBLE)
>>> +
Re: linux-next: manual merge of the driver-core tree with the watchdog tree
Hi Greg, On Sun, 14 Dec 2014 20:35:06 -0800 Greg KH wrote: > > How is this happening, nothing has changed in my trees, did something > new get added to the watchdog tree? Yep. It would have been much easier on me (and maybe Linus) if those "drop owner assignment from platform_drivers" patches had gone via their respective maintainers ... just something to remember for next time. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgp7_ihQbYmEM.pgp Description: OpenPGP digital signature
[PATCH] irqchip: renesas-intc-irqpin: r8a7779 IRLM setup support
From: Magnus Damm
Add r8a7779 specific support for IRLM bit configuration
in the INTC-IRQPIN driver. Without this code we need
special workaround code in arch/arm/mach-shmobile.
The IRLM bit for the INTC hardware exists on various
older SH-based SoCs and is used to select between two
modes for the external interrupt pins IRQ0 to IRQ3:
IRLM = 0: (default from reset on r8a7779)
In this mode the pins IRQ0 to IRQ3 are used together
to give a value between 0 and 15 to the SoC. External
logic is required for masking. This mode is not
supported by the INTC-IRQPIN driver.
IRLM = 1: (needs this patch or configuration elsewhere)
In this mode IRQ0 to IRQ3 operate as 4 individual
external interrupt pins. In this mode the SMSC ethernet
chip can be used via IRQ1 on r8a7779 Marzen. This mode
is the only supported mode by the INTC-IRQPIN driver.
For this patch to work the r8a7779 DTS needs to pass
the ICR0 register as the last register bank.
Signed-off-by: Magnus Damm
---
Same version as sent on December 3rd.
Written against renesas-devel-20141202-v3.18-rc7 which is
basically v3.18-rc7 plus latest arch/arm/mach-shmobile code.
Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt
|5 +
drivers/irqchip/irq-renesas-intc-irqpin.c
| 50 --
2 files changed, 46 insertions(+), 9 deletions(-)
---
0001/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt
+++
work/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt
2014-12-03 20:25:13.0 +0900
@@ -9,6 +9,11 @@ Required properties:
- "renesas,intc-irqpin-r8a7778" (R-Car M1A)
- "renesas,intc-irqpin-r8a7779" (R-Car H1)
- "renesas,intc-irqpin-sh73a0" (SH-Mobile AG5)
+
+- reg: Base address and length of each register bank used by the external
+ IRQ pins driven by the interrupt controller hardware module. The base
+ addresses, length and number of required register banks varies with soctype.
+
- #interrupt-cells: has to be <2>: an interrupt index and flags, as defined in
interrupts.txt in this directory
--- 0001/drivers/irqchip/irq-renesas-intc-irqpin.c
+++ work/drivers/irqchip/irq-renesas-intc-irqpin.c 2014-12-03
20:32:59.0 +0900
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include
#include
@@ -40,7 +41,9 @@
#define INTC_IRQPIN_REG_SOURCE 2 /* INTREQnn */
#define INTC_IRQPIN_REG_MASK 3 /* INTMSKnn */
#define INTC_IRQPIN_REG_CLEAR 4 /* INTMSKCLRnn */
-#define INTC_IRQPIN_REG_NR 5
+#define INTC_IRQPIN_REG_NR_MANDATORY 5
+#define INTC_IRQPIN_REG_IRLM 5 /* ICR0 with IRLM bit (optional) */
+#define INTC_IRQPIN_REG_NR 6
/* INTC external IRQ PIN hardware register access:
*
@@ -82,6 +85,10 @@ struct intc_irqpin_priv {
u8 shared_irq_mask;
};
+struct intc_irqpin_irlm_config {
+ unsigned int irlm_bit;
+};
+
static unsigned long intc_irqpin_read32(void __iomem *iomem)
{
return ioread32(iomem);
@@ -345,10 +352,23 @@ static struct irq_domain_ops intc_irqpin
.xlate = irq_domain_xlate_twocell,
};
+static const struct intc_irqpin_irlm_config intc_irqpin_irlm_r8a7779 = {
+ .irlm_bit = 23, /* ICR0.IRLM0 */
+};
+
+static const struct of_device_id intc_irqpin_dt_ids[] = {
+ { .compatible = "renesas,intc-irqpin", },
+ { .compatible = "renesas,intc-irqpin-r8a7779",
+ .data = _irqpin_irlm_r8a7779 },
+ {},
+};
+MODULE_DEVICE_TABLE(of, intc_irqpin_dt_ids);
+
static int intc_irqpin_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
struct renesas_intc_irqpin_config *pdata = dev->platform_data;
+ const struct of_device_id *of_id;
struct intc_irqpin_priv *p;
struct intc_irqpin_iomem *i;
struct resource *io[INTC_IRQPIN_REG_NR];
@@ -391,10 +411,11 @@ static int intc_irqpin_probe(struct plat
pm_runtime_enable(dev);
pm_runtime_get_sync(dev);
- /* get hold of manadatory IOMEM */
+ /* get hold of register banks */
+ memset(io, 0, sizeof(io));
for (k = 0; k < INTC_IRQPIN_REG_NR; k++) {
io[k] = platform_get_resource(pdev, IORESOURCE_MEM, k);
- if (!io[k]) {
+ if (!io[k] && k < INTC_IRQPIN_REG_NR_MANDATORY) {
dev_err(dev, "not enough IOMEM resources\n");
ret = -EINVAL;
goto err0;
@@ -422,6 +443,10 @@ static int intc_irqpin_probe(struct plat
for (k = 0; k < INTC_IRQPIN_REG_NR; k++) {
i = >iomem[k];
+ /* handle optional registers */
+ if (!io[k])
+ continue;
+
switch (resource_size(io[k])) {
case 1:
i->width = 8;
@@ -448,6 +473,19 @@ static int intc_irqpin_probe(struct plat
}
}
+ /* configure "individual IRQ mode" where needed */
+ of_id =
Re: Possible regression with commit 52221610d
On Sat, Dec 13, 2014 at 11:22 PM, Bjorn Andersson wrote:
> On Tue, Nov 4, 2014 at 7:31 AM, Tim Kryger wrote:
>> On Tue, Nov 4, 2014 at 1:00 AM, Alexandre Courbot
>> wrote:
>>> Hi Tim, thanks for your reply!
>>>
>>> On 11/04/2014 02:28 PM, Tim Kryger wrote:
On Mon, Nov 3, 2014 at 7:05 PM, Alexandre Courbot
> [..]
> After bisecting I tracked commit 52221610dd84dc3e9196554f0292ca9e8ab3541d
> ("mmc: sdhci: Improve external VDD regulator support") as the one that
> introduced this issue, which seems somehow surprising to me since it has
> been around for a while and nobody else complained about this AFAICT.
>
> After some hunting it seems like the recent Qualcomm platforms are
> suffering from this as well.
>
> [..]
>> In a nutshell, the issue here is that the SDHCI spec demands that VMMC
>> be supplied by the controller itself with the specific voltage
>> configured using the SDHCI_POWER_CONTROL register but almost nobody
>> does this. Many SoCs omit this capability from their controllers and
>> instead rely upon external regulators. In such cases there isn't
>> normally any need to update the voltage bits of the power control
>> register. It sounds like you are saying this isn't true for the
>> Tegra114.
>
> Should one interpret your answer as that iff the SDHCI controller
> actually follows the specification (and provides the power control)
> then as of the introduction of 52221610dd vmmc should no longer be
> used for specifying the supply of power to the controller?
>
> Or simply; what is vmmc (in the code) supposed to represent?
Hi Bjorn,
VMMC is the supply that delivers power out to the SD card itself (aka VDD).
It is not the internal power rail/power domain of the host controller
within the SoC.
-Tim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the driver-core tree with the watchdog tree
On Mon, Dec 15, 2014 at 02:11:14PM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> Today's linux-next merge of the driver-core tree got a conflict in
> drivers/watchdog/imx2_wdt.c between commit 6dc21678dbd9 ("watchdog:
> imx2_wdt: Add power management support") from the watchdog tree and
> commit fa21a580dea4 ("watchdog: drop owner assignment from
> platform_drivers") from the driver-core tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
How is this happening, nothing has changed in my trees, did something
new get added to the watchdog tree?
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.18 00/19] 3.18.1-stable review
On Sun, Dec 14, 2014 at 07:33:12PM -0800, Guenter Roeck wrote: > On 12/14/2014 12:21 PM, Greg Kroah-Hartman wrote: > >This is the start of the stable review cycle for the 3.18.1 release. > >There are 19 patches in this series, all will be posted as a response > >to this one. If anyone has any issues with these being applied, please > >let me know. > > > >Responses should be made by Tue Dec 16 20:18:16 UTC 2014. > >Anything received after that time might be too late. > > > > Build results: > total: 133 pass: 133 fail: 0 > > Qemu tests: > total: 30 pass: 30 fail: 0 > > Details are available at http://server.roeck-us.net:8010/builders. Thanks for testing and letting me know about all of these. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: omap2plus_defconfig: use CONFIG_CPUFREQ_DT
On Fri, Dec 12, 2014 at 10:48 PM, Nishanth Menon wrote:
> CONFIG_GENERIC_CPUFREQ_CPU0 disappeared with commit bbcf071969b20f
> ("cpufreq: cpu0: rename driver and internals to 'cpufreq_dt'")
>
> Use the renamed CONFIG_CPUFREQ_DT generic driver. It looks like with
> v3.18-rc1, commit bbcf071969b20f and fdc509b15eb3eb came in via
> different trees causing the resultant v3.18-rc1 to be non-functional for
> cpufreq as default supported with omap2plus_defconfig.
>
> Fixes: fdc509b15eb3eb ("ARM: omap2plus_defconfig: Add cpufreq to defconfig")
> Signed-off-by: Nishanth Menon
Whomsoever applies it, please add:
Cc: # 3.18
> ---
>
> NOTE: as of v3.18 tag, The following still need to be fixed - I do not have
> all
> the platforms impacted to make a generic change, so CCying folks who might be
> interested
>
> arch/arm/configs/shmobile_defconfig:CONFIG_GENERIC_CPUFREQ_CPU0=y
> arch/arm/configs/multi_v7_defconfig:CONFIG_GENERIC_CPUFREQ_CPU0=y
I have fixed them now.
>
> arch/arm/configs/omap2plus_defconfig |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/configs/omap2plus_defconfig
> b/arch/arm/configs/omap2plus_defconfig
> index 3e09286..5fc0dbe 100644
> --- a/arch/arm/configs/omap2plus_defconfig
> +++ b/arch/arm/configs/omap2plus_defconfig
> @@ -68,7 +68,7 @@ CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
> CONFIG_CPU_FREQ_GOV_POWERSAVE=y
> CONFIG_CPU_FREQ_GOV_USERSPACE=y
> CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y
> -CONFIG_GENERIC_CPUFREQ_CPU0=y
> +CONFIG_CPUFREQ_DT=y
> # CONFIG_ARM_OMAP2PLUS_CPUFREQ is not set
> CONFIG_CPU_IDLE=y
> CONFIG_BINFMT_MISC=y
Acked-by: Viresh Kumar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] workqueue: handle change in cpu-node relationship.
(2014/12/15 12:34), Lai Jiangshan wrote:
On 12/15/2014 10:55 AM, Kamezawa Hiroyuki wrote:
(2014/12/15 11:48), Lai Jiangshan wrote:
On 12/15/2014 10:20 AM, Kamezawa Hiroyuki wrote:
(2014/12/15 11:12), Lai Jiangshan wrote:
On 12/14/2014 12:38 AM, Kamezawa Hiroyuki wrote:
Although workqueue detects relationship between cpu<->node at boot,
it is finally determined in cpu_up().
This patch tries to update pool->node using online status of cpus.
1. When a node goes down, clear per-cpu pool's node attr.
2. When a cpu comes up, update per-cpu pool's node attr.
3. When a cpu comes up, update possinle node cpumask workqueue is using for
sched.
4. Detect the best node for unbound pool's cpumask using the latest info.
Signed-off-by: KAMEZAWA Hiroyuki
---
kernel/workqueue.c | 67
++
1 file changed, 53 insertions(+), 14 deletions(-)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 07b4eb5..259b3ba 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -266,7 +266,8 @@ struct workqueue_struct {
static struct kmem_cache *pwq_cache;
static cpumask_var_t *wq_numa_possible_cpumask;
-/* possible CPUs of each node */
+/* possible CPUs of each node initialized with possible info at boot.
+ but modified at cpu hotplug to be adjusted to real info. */
static bool wq_disable_numa;
module_param_named(disable_numa, wq_disable_numa, bool, 0444);
@@ -3449,6 +3450,31 @@ static void put_unbound_pool(struct worker_pool *pool)
call_rcu_sched(>rcu, rcu_free_pool);
}
+/*
+ * detect best node for given cpumask.
+ */
+static int pool_detect_best_node(const struct cpumask *cpumask)
+{
+int node, best, match, selected;
+static struct cpumask andmask; /* we're under mutex */
+
+/* Is any node okay ? */
+if (!wq_numa_enabled ||
+cpumask_subset(cpu_online_mask, cpumask))
+return NUMA_NO_NODE;
+best = 0;
+selected = NUMA_NO_NODE;
+/* select a node which contains the most cpu of cpumask */
+for_each_node_state(node, N_ONLINE) {
+cpumask_and(, cpumask, cpumask_of_node(node));
+match = cpumask_weight();
+if (match > best)
+selected = node;
+}
+return selected;
+}
+
+
/**
* get_unbound_pool - get a worker_pool with the specified attributes
* @attrs: the attributes of the worker_pool to get
@@ -3467,7 +3493,6 @@ static struct worker_pool *get_unbound_pool(const struct
workqueue_attrs *attrs)
{
u32 hash = wqattrs_hash(attrs);
struct worker_pool *pool;
-int node;
lockdep_assert_held(_pool_mutex);
@@ -3492,17 +3517,7 @@ static struct worker_pool *get_unbound_pool(const struct
workqueue_attrs *attrs)
* 'struct workqueue_attrs' comments for detail.
*/
pool->attrs->no_numa = false;
-
-/* if cpumask is contained inside a NUMA node, we belong to that node */
-if (wq_numa_enabled) {
-for_each_node(node) {
-if (cpumask_subset(pool->attrs->cpumask,
- wq_numa_possible_cpumask[node])) {
-pool->node = node;
-break;
-}
-}
-}
+pool->node = pool_detect_best_node(pool->attrs->cpumask);
if (worker_pool_assign_id(pool) < 0)
goto fail;
@@ -4567,7 +4582,7 @@ static int workqueue_cpu_up_callback(struct
notifier_block *nfb,
int cpu = (unsigned long)hcpu;
struct worker_pool *pool;
struct workqueue_struct *wq;
-int pi;
+int pi, node;
switch (action & ~CPU_TASKS_FROZEN) {
case CPU_UP_PREPARE:
@@ -4583,6 +4598,16 @@ static int workqueue_cpu_up_callback(struct
notifier_block *nfb,
case CPU_ONLINE:
mutex_lock(_pool_mutex);
+/* now cpu <-> node info is established, update the info. */
+if (!wq_disable_numa) {
+for_each_node_state(node, N_POSSIBLE)
+cpumask_clear_cpu(cpu,
+wq_numa_possible_cpumask[node]);
The wq code try to reuse the origin pwqs/pools when the node still have cpu
online.
these 3 lines of code will cause the origin pwqs/pools be on the road of dying,
and
create a new set of pwqs/pools.
because the result of wq_calc_node_cpumask() changes ?
Yes.
Do you mean some comment should be added here ? or explaination for your reply
for [3/4] ?
this fix [4/4] breaks the original design.
I'm sorry that I can't understand what this patch breaks.
the pwqs/pools should be kept if the node still have cpu online.
So, the fix's grand design should be
1. drop old pwq/pools only at node offline.
2. set proper pool->node based on online node info.
3. update pool->node of per-cpu-pool at cpu ONLINE.
Hm. (1) is done because cpumask_of_node() turns to be zero-filled
after all cpus on a node offlined.
But, cpu-to-node relationship cannot be available until a cpu get onlined.
It changes
Re: UFS RPMB
As i know, SECURITY PROTOCOL IN/OUT are support RPMB access for UFS. On 12/14/14, Tomas Winkler wrote: > Hi, sorry fore a newbie question. > What is the current interface for accessing rpmb LUN in a UFS devices. > For emmc one need to issue a raw mmc ioctl command MMC_IOC_CMD. > > Thanks > Tomas > -- > To unsubscribe from this list: send the line "unsubscribe linux-scsi" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] ARM: SPEAr: dts: remove unused irq-trigger, id and block entries
On Sat, Dec 13, 2014 at 7:16 AM, Silvio Fricke wrote: > Signed-off-by: Silvio Fricke > CC: Thomas Gleixner > CC: Jason Cooper > CC: Marc Zyngier > --- > arch/arm/boot/dts/spear1310-evb.dts | 1 - > arch/arm/boot/dts/spear1340-evb.dts | 2 -- > arch/arm/boot/dts/spear320-hmi.dts | 3 --- > 3 files changed, 6 deletions(-) Acked-by: Viresh Kumar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the staging tree with the vfs tree
Hi Greg,
Today's linux-next merge of the staging tree got a conflict in
drivers/staging/lustre/lustre/llite/llite_lib.c between commit
6a661bd6ffba ("lustre: get rid of playing with ->fs") from the vfs tree
and commit 9c234f6cb4c4 ("drivers: staging: lustre: Fix "'foo* bar'
should be 'foo *bar'" errors") from the staging tree.
I fixed it up (the former removed te code changed by the latter) and
can carry the fix as necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpJ45HtBO6JQ.pgp
Description: OpenPGP digital signature
RE: [PATCH v14 01/12] input: cyapa: re-design driver to support multi-trackpad in one driver
Thanks for your remove and comments.
Dudley
> -Original Message-
> From: linux-input-ow...@vger.kernel.org
> [mailto:linux-input-ow...@vger.kernel.org] On Behalf Of Jeremiah Mahler
> Sent: 2014?12?13? 19:16
> To: Dudley Du
> Cc: dmitry.torok...@gmail.com; rydb...@euromail.se; ble...@google.com;
> linux-in...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v14 01/12] input: cyapa: re-design driver to support
> multi-trackpad in one driver
>
> Dudley,
>
> A few suggestions and questions below...
>
> On Fri, Dec 12, 2014 at 10:27:31AM +0800, Dudley Du wrote:
> > In order to support multiple different chipsets and communication protocols
> > trackpad devices in one cyapa driver, the new cyapa driver is re-designed
> > with one cyapa driver core and multiple device specific functions component.
> > The cyapa driver core is contained in this patch, it supplies basic
> > functions
> > that working with kernel and input subsystem, and also supplies the
> > interfaces
> > that the specific devices' component can connect and work together with as
> > one driver.
> > TEST=test on Chromebooks.
> >
> > Signed-off-by: Dudley Du
> > ---
> > drivers/input/mouse/Makefile |3 +-
> > drivers/input/mouse/cyapa.c | 1050
> > ++
> > drivers/input/mouse/cyapa.h | 316
> [...]
> > -{ REG_OFFSET_QUERY_BASE, QUERY_DATA_SIZE },
> > -{ BL_HEAD_OFFSET, 3 },
> > -{ BL_HEAD_OFFSET, 16 },
> > -{ BL_HEAD_OFFSET, 16 },
> > -{ BL_DATA_OFFSET, 16 },
> > -{ BL_HEAD_OFFSET, 32 },
> > -{ REG_OFFSET_QUERY_BASE, PRODUCT_ID_SIZE },
> > -{ REG_OFFSET_DATA_BASE, 32 }
> > -};
> > +const char unique_str[] = "CYTRA";
> >
> Since 'unique_str' is used to check the product id why not call it
> 'product_id'?
Thanks, I will rename it to product_id.
>
> [...]
> > +/**
> > + * cyapa_i2c_write - Execute i2c block data write operation
> > + * @cyapa: Handle to this driver
> > + * @ret: Offset of the data to written in the register map
> > + * @len: number of bytes to write
> > + * @values: Data to be written
> > *
> > - * Note:
> > - * In trackpad device, the memory block allocated for I2C register map
> > - * is 256 bytes, so the max read block for I2C bus is 256 bytes.
> > + * Return negative errno code on error; return zero when success.
> > */
> > -static ssize_t cyapa_smbus_read_block(struct cyapa *cyapa, u8 cmd, size_t
> > len,
> > - u8 *values)
> > +ssize_t cyapa_i2c_write(struct cyapa *cyapa, u8 reg,
> > + size_t len, const void *values)
> > {
> > -ssize_t ret;
> > -u8 index;
> > -u8 smbus_cmd;
> > -u8 *buf;
> > +int ret;
> > struct i2c_client *client = cyapa->client;
> > +char data[32], *buf;
> >
> > -if (!(SMBUS_BYTE_BLOCK_CMD_MASK & cmd))
> > -return -EINVAL;
> > -
> > -if (SMBUS_GROUP_BLOCK_CMD_MASK & cmd) {
> > -/* read specific block registers command. */
> > -smbus_cmd = SMBUS_ENCODE_RW(cmd, SMBUS_READ);
> > -ret = i2c_smbus_read_block_data(client, smbus_cmd, values);
> > -goto out;
> > -}
> > -
> > -ret = 0;
> > -for (index = 0; index * I2C_SMBUS_BLOCK_MAX < len; index++) {
> > -smbus_cmd = SMBUS_ENCODE_IDX(cmd, index);
> > -smbus_cmd = SMBUS_ENCODE_RW(smbus_cmd, SMBUS_READ);
> > -buf = values + I2C_SMBUS_BLOCK_MAX * index;
> > -ret = i2c_smbus_read_block_data(client, smbus_cmd, buf);
> > -if (ret < 0)
> > -goto out;
> > -}
> > -
> > -out:
> > -return ret > 0 ? len : ret;
> > -}
> > -
> > -static s32 cyapa_read_byte(struct cyapa *cyapa, u8 cmd_idx)
> > -{
> > -u8 cmd;
> > -
> > -if (cyapa->smbus) {
> > -cmd = cyapa_smbus_cmds[cmd_idx].cmd;
> > -cmd = SMBUS_ENCODE_RW(cmd, SMBUS_READ);
> > +if (len > 31) {
> > +buf = kzalloc(len + 1, GFP_KERNEL);
> > +if (!buf)
> > +return -ENOMEM;
> > } else {
> > -cmd = cyapa_i2c_cmds[cmd_idx].cmd;
> > +buf = data;
> > }
> > -return i2c_smbus_read_byte_data(cyapa->client, cmd);
> > -}
> >
> > -static s32 cyapa_write_byte(struct cyapa *cyapa, u8 cmd_idx, u8 value)
> > -{
> > -u8 cmd;
> > +buf[0] = reg;
> > +memcpy([1], values, len);
> > +ret = i2c_master_send(client, buf, len + 1);
> >
> > -if (cyapa->smbus) {
> > -cmd = cyapa_smbus_cmds[cmd_idx].cmd;
> > -cmd = SMBUS_ENCODE_RW(cmd, SMBUS_WRITE);
> > -} else {
> > -cmd = cyapa_i2c_cmds[cmd_idx].cmd;
> > -}
> > -return i2c_smbus_write_byte_data(cyapa->client, cmd, value);
> > +if (buf != data)
> > +kfree(buf);
> > +return (ret == (len + 1)) ? 0 : ((ret < 0) ? ret : -EIO);
> > }
> >
>
> Ugh. This is hard to read since diff replaced three functions with one,
> cyapa_i2c_write(). Nothing can be done about this, just a note for the
> other reviewers.
>
> The final cyapa_i2c_write() is shown below.
>
> /**
>* cyapa_i2c_write - Execute i2c block data write operation
>* @cyapa: Handle to this driver
>* @ret: Offset of the data to written in the register map
>* @len: number of bytes to write
>* @values: Data to be written
>*
>* Return negative errno code on error; return zero when success.
>*/
> ssize_t
[PATCH v5][resend v2] of: replace Asahi Kasei Corp vendor prefix
From: Kuninori Morimoto
Current vendor-prefixes.txt already has "ak" prefix for Asahi Kasei Corp
by ae8c4209af2c(of: Add vendor prefix for Asahi Kasei Corp.)
It went through the appropriate review process. But, almost all
Asahi Kasei chip drivers are using "asahi-kasei" prefix today.
(arch/arm/boot/dts/tegra20-seaboard.dts only is using "ak,ak8975",
but there are instances of "asahi-kasei,ak8975" in other dts files.
And drivers/iio/magnetometer/ak8975.c doesn't support "ak,ak8975" prefix)
So, we made a mistake there.
In addition, checkpatch.pl reports WARNING if it is using "asahi-kasei"
prerfix in DT file.
(DT compatible string vendor "asahi-kasei" appears un-documented)
Marking it deprecated and warning with checkpatch is certainly
preferable. So, this patch replace "ak" to "asahi-kasei" in
vendor-prefixes.txt. (and fixup tegra20-seaboard)
OTOH, Asahi Kasei is usually referred to as "AKM", but this patch
doesn't care about it. Because no DT is using that today.
Signed-off-by: Kuninori Morimoto
Acked-by: Thierry Reding
Acked-by: Alexandre Courbot
---
Rob, Mark
There is no response about this patch.
Mark, is it possible to care about this patch ?
It has relationship to ASoC.
.../devicetree/bindings/vendor-prefixes.txt|2 +-
arch/arm/boot/dts/tegra20-seaboard.dts |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 723999d..ddcb4cd 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -9,7 +9,6 @@ ad Avionic Design GmbH
adapteva Adapteva, Inc.
adiAnalog Devices, Inc.
aeroflexgaislerAeroflex Gaisler AB
-ak Asahi Kasei Corp.
allwinner Allwinner Technology Co., Ltd.
altr Altera Corp.
amcc Applied Micro Circuits Corporation (APM, formally AMCC)
@@ -20,6 +19,7 @@ amstaos AMS-Taos Inc.
apmApplied Micro Circuits Corporation (APM)
armARM Ltd.
armadeus ARMadeus Systems SARL
+asahi-kaseiAsahi Kasei Corp.
atmel Atmel Corporation
auoAU Optronics Corporation
avago Avago Technologies
diff --git a/arch/arm/boot/dts/tegra20-seaboard.dts
b/arch/arm/boot/dts/tegra20-seaboard.dts
index a1d4bf9..7f5cf80 100644
--- a/arch/arm/boot/dts/tegra20-seaboard.dts
+++ b/arch/arm/boot/dts/tegra20-seaboard.dts
@@ -405,7 +405,7 @@
clock-frequency = <40>;
magnetometer@c {
- compatible = "ak,ak8975";
+ compatible = "asahi-kasei,ak8975";
reg = <0xc>;
interrupt-parent = <>;
interrupts = ;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v14 00/12] input: cyapa: instruction of cyapa patches
Jeremiah, Thanks for your information. I will fix the space check warnning. Are there any other driver check tools that need to be run? Thanks. Dudley > -Original Message- > From: linux-input-ow...@vger.kernel.org > [mailto:linux-input-ow...@vger.kernel.org] On Behalf Of Jeremiah Mahler > Sent: 2014?12?13? 18:18 > To: Dudley Du > Cc: linux-in...@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: Re: [PATCH v14 00/12] input: cyapa: instruction of cyapa patches > > Dudley, > > On Fri, Dec 12, 2014 at 10:27:30AM +0800, Dudley Du wrote: > > V14 patches have below updates, details of other updates see history list: > > 1) Correct 9 miss spelling issues of "bufferred" to "buffered". > > 2) Fix the upgrade issue of removing MOUSE_CYAPA config when make oldconfig > >by replase "depends on I2C && CRC_ITU_T" with > > "depends on I2C" > > "select CRC_ITU_T" > >in patch 9. > > > [...] > > I found some sparse warnings that should be fixed. > > jeri@newt:~/linux-next$ touch drivers/input/mouse/*.c > jeri@newt:~/linux-next$ touch drivers/input/mouse/*.h > jeri@newt:~/linux-next$ make C=1 > CHK include/config/kernel.release > CHK include/generated/uapi/linux/version.h > CHK include/generated/utsrelease.h > CALLscripts/checksyscalls.sh > CHK include/generated/compile.h > CHK kernel/config_data.h > CHECK drivers/input/mouse/cyapa.c > drivers/input/mouse/cyapa.c:43:9: warning: symbol 'cyapa_i2c_read' was > not declared. Should it be static? > drivers/input/mouse/cyapa.c:80:9: warning: symbol 'cyapa_i2c_write' was > not declared. Should it be static? > drivers/input/mouse/cyapa.c:289:5: warning: symbol 'cyapa_detect' was > not declared. Should it be static? > CC [M] drivers/input/mouse/cyapa.o > CHECK drivers/input/mouse/cyapa_gen3.c > drivers/input/mouse/cyapa_gen3.c:299:5: warning: symbol > 'cyapa_read_byte' was not declared. Should it be static? > drivers/input/mouse/cyapa_gen3.c:312:5: warning: symbol > 'cyapa_write_byte' was not declared. Should it be static? > drivers/input/mouse/cyapa_gen3.c:331:9: warning: symbol > 'cyapa_i2c_reg_write_block' was not declared. Should it be static? > CC [M] drivers/input/mouse/cyapa_gen3.o > CHECK drivers/input/mouse/cyapa_gen5.c > drivers/input/mouse/cyapa_gen5.c:334:5: warning: symbol > 'cyapa_empty_pip_output_data' was not declared. Should it be static? > drivers/input/mouse/cyapa_gen5.c:553:6: warning: symbol > 'cyapa_gen5_sort_tsg_pip_bl_resp_data' was not declared. Should it be > static? > drivers/input/mouse/cyapa_gen5.c:568:6: warning: symbol > 'cyapa_gen5_sort_tsg_pip_app_resp_data' was not declared. Should it be > static? > drivers/input/mouse/cyapa_gen5.c:595:6: warning: symbol > 'cyapa_gen5_sort_application_launch_data' was not declared. Should it be > static? > drivers/input/mouse/cyapa_gen5.c:995:6: warning: symbol > 'cyapa_gen5_sort_bl_exit_data' was not declared. Should it be static? > drivers/input/mouse/cyapa_gen5.c:1112:72: warning: Using plain integer > as NULL pointer > CC [M] drivers/input/mouse/cyapa_gen5.o > LD [M] drivers/input/mouse/cyapatp.o > Kernel: arch/x86/boot/bzImage is ready (#127) > Building modules, stage 2. > MODPOST 187 modules > CC drivers/input/mouse/cyapatp.mod.o > LDFINAL [M] drivers/input/mouse/cyapatp.ko > jeri@newt:~/linux-next > > -- > - Jeremiah Mahler > -- > To unsubscribe from this list: send the line "unsubscribe linux-input" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html This message and any attachments may contain Cypress (or its subsidiaries) confidential information. If it has been received in error, please advise the sender and immediately delete this message. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] PM/ Domains: Export of_genpd_get_from_provider function.
This function looks up a PM domain form the provider. This will be
useful to add parent/child domain relationship from the SoC specific
code. The caller of the function must make sure that PM domain provider
is already registered.
Cc: Rafael J. Wysocki
Reviewed-by: Ulf Hansson
Signed-off-by: Amit Daniel Kachhap
---
Changes from v1:
* Added Ulf Hansson Reviewed by.
* Cc'd to linux-pm
This patch may solve the same purpose which is done by earlier posts
1) https://lkml.org/lkml/2014/11/24/319 - In this there were comments
for not using the PM domain name.
2) Ulf Hansson posted a patch
http://www.spinics.net/lists/linux-samsung-soc/msg39745.html which also solves
similar purpose but I feel this is slightly complex and involves changing
the genpd structure.
drivers/base/power/domain.c | 3 ++-
include/linux/pm_domain.h | 8
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 6a103a3..0d8780c 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -2088,7 +2088,7 @@ EXPORT_SYMBOL_GPL(of_genpd_del_provider);
* Returns a valid pointer to struct generic_pm_domain on success or ERR_PTR()
* on failure.
*/
-static struct generic_pm_domain *of_genpd_get_from_provider(
+struct generic_pm_domain *of_genpd_get_from_provider(
struct of_phandle_args *genpdspec)
{
struct generic_pm_domain *genpd = ERR_PTR(-ENOENT);
@@ -2108,6 +2108,7 @@ static struct generic_pm_domain
*of_genpd_get_from_provider(
return genpd;
}
+EXPORT_SYMBOL_GPL(of_genpd_get_from_provider);
/**
* genpd_dev_pm_detach - Detach a device from its PM domain.
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index 6cd20d5..a9edab2 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -271,6 +271,8 @@ typedef struct generic_pm_domain *(*genpd_xlate_t)(struct
of_phandle_args *args,
int __of_genpd_add_provider(struct device_node *np, genpd_xlate_t xlate,
void *data);
void of_genpd_del_provider(struct device_node *np);
+struct generic_pm_domain *of_genpd_get_from_provider(
+ struct of_phandle_args *genpdspec);
struct generic_pm_domain *__of_genpd_xlate_simple(
struct of_phandle_args *genpdspec,
@@ -288,6 +290,12 @@ static inline int __of_genpd_add_provider(struct
device_node *np,
}
static inline void of_genpd_del_provider(struct device_node *np) {}
+static inline struct generic_pm_domain *of_genpd_get_from_provider(
+ struct of_phandle_args *genpdspec)
+{
+ return NULL;
+}
+
#define __of_genpd_xlate_simpleNULL
#define __of_genpd_xlate_onecell NULL
--
2.2.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] watchdog: Add driver for Mediatek watchdog
Hi,
On Fri, 2014-12-12 at 15:50 +0100, Matthias Brugger wrote:
> This patch adds a driver for the Mediatek SoC integrated
> watchdog. This driver supports watchdog and software reset
> for mt65xx and mt81xx SoCs.
>
> Signed-off-by: Matthias Brugger
> +static int mtk_reset_handler(struct notifier_block *this, unsigned long mode,
> + void *cmd)
> +{
> + struct mtk_wdt_dev *mtk_wdt = container_of(this,
> +struct mtk_wdt_dev,
> +restart_handler);
> + void __iomem *wdt_base = mtk_wdt->wdt_base;
> + u32 reg;
> +
> + /* Reset system */
> + writel(WDT_SWRST_KEY, wdt_base + WDT_SWRST);
> +
> + while (1) {
> + mdelay(5);
> + writel(WDT_SWRST_KEY, wdt_base + WDT_SWRST);
> + }
> + return NOTIFY_DONE;
> +
> +}
Build warning
../drivers/watchdog/mtk_wdt.c:78:6: warning: unused variable
'reg' [-Wunused-variable]
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.18 00/19] 3.18.1-stable review
On 12/14/2014 12:21 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.18.1 release. There are 19 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Tue Dec 16 20:18:16 UTC 2014. Anything received after that time might be too late. Build results: total: 133 pass: 133 fail: 0 Qemu tests: total: 30 pass: 30 fail: 0 Details are available at http://server.roeck-us.net:8010/builders. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/3] ARM: at91: at91sam9n12ek/dt: use dt ids for wm8904
Using the device tree ids for wm8904 codec.
Signed-off-by: Bo Shen
---
Changes in v2: None
arch/arm/boot/dts/at91sam9n12ek.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/at91sam9n12ek.dts
b/arch/arm/boot/dts/at91sam9n12ek.dts
index 13bb24e..9575c0d 100644
--- a/arch/arm/boot/dts/at91sam9n12ek.dts
+++ b/arch/arm/boot/dts/at91sam9n12ek.dts
@@ -54,7 +54,7 @@
status = "okay";
wm8904: codec@1a {
- compatible = "wm8904";
+ compatible = "wlf,wm8904";
reg = <0x1a>;
clocks = <>;
clock-names = "mclk";
--
2.1.0.24.g4109c28
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 7/7] CXL: Unmap MMIO regions when detaching a context
Excerpts from Ian Munsie's message of 2014-12-08 19:18:01 +1100: > From: Ian Munsie > > If we need to force detach a context (e.g. due to EEH or simply force > unbinding the driver) we should prevent the userspace contexts from > being able to access the Problem State Area MMIO region further, which > they may have mapped with mmap(). > > This patch unmaps any mapped MMIO regions when detaching a userspace > context. Might want to drop this one for now - Philippe found that it sometimes causes an issue when multiple contexts are using the afu. Seems that unmap_mapping_range() unmapped a bit more than I expected. Cheers, -Ian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.17 00/47] 3.17.7-stable review
On 12/14/2014 12:20 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.17.7 release. There are 47 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Tue Dec 16 20:18:09 UTC 2014. Anything received after that time might be too late. Build results: total: 133 pass: 132 fail: 1 Failed builds: avr32:atngw100mkii_evklcd101_defconfig Qemu tests: total: 30 pass: 30 fail: 0 Details are available at http://server.roeck-us.net:8010/builders. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] workqueue: handle change in cpu-node relationship.
On 12/15/2014 10:55 AM, Kamezawa Hiroyuki wrote:
> (2014/12/15 11:48), Lai Jiangshan wrote:
>> On 12/15/2014 10:20 AM, Kamezawa Hiroyuki wrote:
>>> (2014/12/15 11:12), Lai Jiangshan wrote:
On 12/14/2014 12:38 AM, Kamezawa Hiroyuki wrote:
> Although workqueue detects relationship between cpu<->node at boot,
> it is finally determined in cpu_up().
> This patch tries to update pool->node using online status of cpus.
>
> 1. When a node goes down, clear per-cpu pool's node attr.
> 2. When a cpu comes up, update per-cpu pool's node attr.
> 3. When a cpu comes up, update possinle node cpumask workqueue is using
> for sched.
> 4. Detect the best node for unbound pool's cpumask using the latest info.
>
> Signed-off-by: KAMEZAWA Hiroyuki
> ---
>kernel/workqueue.c | 67
> ++
>1 file changed, 53 insertions(+), 14 deletions(-)
>
> diff --git a/kernel/workqueue.c b/kernel/workqueue.c
> index 07b4eb5..259b3ba 100644
> --- a/kernel/workqueue.c
> +++ b/kernel/workqueue.c
> @@ -266,7 +266,8 @@ struct workqueue_struct {
>static struct kmem_cache *pwq_cache;
>
>static cpumask_var_t *wq_numa_possible_cpumask;
> -/* possible CPUs of each node */
> +/* possible CPUs of each node initialized with possible info at boot.
> + but modified at cpu hotplug to be adjusted to real info. */
>
>static bool wq_disable_numa;
>module_param_named(disable_numa, wq_disable_numa, bool, 0444);
> @@ -3449,6 +3450,31 @@ static void put_unbound_pool(struct worker_pool
> *pool)
>call_rcu_sched(>rcu, rcu_free_pool);
>}
>
> +/*
> + * detect best node for given cpumask.
> + */
> +static int pool_detect_best_node(const struct cpumask *cpumask)
> +{
> +int node, best, match, selected;
> +static struct cpumask andmask; /* we're under mutex */
> +
> +/* Is any node okay ? */
> +if (!wq_numa_enabled ||
> +cpumask_subset(cpu_online_mask, cpumask))
> +return NUMA_NO_NODE;
> +best = 0;
> +selected = NUMA_NO_NODE;
> +/* select a node which contains the most cpu of cpumask */
> +for_each_node_state(node, N_ONLINE) {
> +cpumask_and(, cpumask, cpumask_of_node(node));
> +match = cpumask_weight();
> +if (match > best)
> +selected = node;
> +}
> +return selected;
> +}
> +
> +
>/**
> * get_unbound_pool - get a worker_pool with the specified attributes
> * @attrs: the attributes of the worker_pool to get
> @@ -3467,7 +3493,6 @@ static struct worker_pool *get_unbound_pool(const
> struct workqueue_attrs *attrs)
>{
>u32 hash = wqattrs_hash(attrs);
>struct worker_pool *pool;
> -int node;
>
>lockdep_assert_held(_pool_mutex);
>
> @@ -3492,17 +3517,7 @@ static struct worker_pool *get_unbound_pool(const
> struct workqueue_attrs *attrs)
> * 'struct workqueue_attrs' comments for detail.
> */
>pool->attrs->no_numa = false;
> -
> -/* if cpumask is contained inside a NUMA node, we belong to that
> node */
> -if (wq_numa_enabled) {
> -for_each_node(node) {
> -if (cpumask_subset(pool->attrs->cpumask,
> - wq_numa_possible_cpumask[node])) {
> -pool->node = node;
> -break;
> -}
> -}
> -}
> +pool->node = pool_detect_best_node(pool->attrs->cpumask);
>
>if (worker_pool_assign_id(pool) < 0)
>goto fail;
> @@ -4567,7 +4582,7 @@ static int workqueue_cpu_up_callback(struct
> notifier_block *nfb,
>int cpu = (unsigned long)hcpu;
>struct worker_pool *pool;
>struct workqueue_struct *wq;
> -int pi;
> +int pi, node;
>
>switch (action & ~CPU_TASKS_FROZEN) {
>case CPU_UP_PREPARE:
> @@ -4583,6 +4598,16 @@ static int workqueue_cpu_up_callback(struct
> notifier_block *nfb,
>case CPU_ONLINE:
>mutex_lock(_pool_mutex);
>
> +/* now cpu <-> node info is established, update the info. */
> +if (!wq_disable_numa) {
> +for_each_node_state(node, N_POSSIBLE)
> +cpumask_clear_cpu(cpu,
> +wq_numa_possible_cpumask[node]);
The wq code try to reuse the origin pwqs/pools when the node still have
cpu online.
these 3 lines of code will cause the origin pwqs/pools be on the road of
dying, and
create a new set of pwqs/pools.
>>>
>>> because the result of wq_calc_node_cpumask() changes ?
>>
[PATCH v2 2/3] ARM: at91: sama5d3xek/dt: use dt ids for wm8904
From: Alexander Morozov
Using the wm8904 device tree compatible string.
Signed-off-by: Alexander Morozov
Signed-off-by: Bo Shen
---
Changes in v2: None
arch/arm/boot/dts/sama5d3xmb.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sama5d3xmb.dtsi
b/arch/arm/boot/dts/sama5d3xmb.dtsi
index 49c10d3..2a1aa58 100644
--- a/arch/arm/boot/dts/sama5d3xmb.dtsi
+++ b/arch/arm/boot/dts/sama5d3xmb.dtsi
@@ -45,7 +45,7 @@
*/
i2c0: i2c@f0014000 {
wm8904: wm8904@1a {
- compatible = "wm8904";
+ compatible = "wlf,wm8904";
reg = <0x1a>;
clocks = <>;
clock-names = "mclk";
--
2.1.0.24.g4109c28
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
