[RFC] Increase Minimal GNU Make version for Linux Kernel from 3.80 to 3.81
Hello Linus and Kbuild developers. Documentation/process/changes.rst says the minimal version of GNU Make is 3.80, but actually building the kernel with this version has been broken for a long time. Specifically, it got broken by commit c8589d1e9e01 (i.e. Linux 3.18). Sorry, it's me who broke it. Here is my excuse: - It is almost 3 years since then, but nobody complained about it. - GNU Make 3.80 is almost 15 years old. (Even GNU Make 3.81 was released in 2006.) - People seldom test their makefiles on such old GNU Make version, so they often use some features that are not supported by version 3.80. We would have to make efforts if we wanted to get back availability of GNU Make 3.80. [1] multi_depend in scripts/Makefile.lib does not work on GNU Make 3.80 I fiddled with it for a while, but I could not find a workaround, except reverting the following 4 commits: 221ecca6cafe 022af62d0190 97e3226e6e98 c8589d1e9e01 I do not want to revert them because we would lose many cleanups. [2] "else ifeq" is not supported by GNU Make 3.80 'make help' on GNU Make 3.80 reports error: ./Documentation/Makefile.sphinx:25: Extraneous text after `else' directive ./Documentation/Makefile.sphinx:31: *** only one `else' per conditional. Stop. make: *** [help] Error 2 We could rewrite the makefile, but nested if directives would make the code unreadable. [3] $(realpath ...) and $(abspath ...) are not supported by GNU Make 3.80 These two functions are only supported by 3.81 or later, but they are already used here and there. [4] semi-colon (;) is treated differently in $(warning ...) by GNU Make 3.80 'make ARCH=arm64 defconfig' does not work on GNU Make 3.80 $ make ARCH=arm64 defconfig arch/arm64/Makefile:43: *** unterminated call to function `warning': missing `)'. Stop. I could not find a solution to make it work for both 3.80 and 3.81 (or later). We would not be able to use a semi-colon in $(warning ...). >From the above, I'd like to propose to increase the minimal version of GNU Make to 3.81. Comments are appreciated. -- Best Regards Masahiro Yamada
Re: [RESENT PATCH] x86/mem: fix the offset overflow when read/write mem
On 2017/5/3 4:54, David Rientjes wrote: > On Thu, 27 Apr 2017, zhongjiang wrote: > >> From: zhong jiang >> >> Recently, I found the following issue, it will result in the panic. >> >> [ 168.739152] mmap1: Corrupted page table at address 7f3e6275a002 >> [ 168.745039] PGD 61f4a1067 >> [ 168.745040] PUD 61ab19067 >> [ 168.747730] PMD 61fb8b067 >> [ 168.750418] PTE 80001225 >> [ 168.753109] >> [ 168.757795] Bad pagetable: 000d [#1] SMP >> [ 168.761696] Modules linked in: intel_powerclamp coretemp kvm_intel kvm >> irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel >> crypto_simd iTCO_wdt glue_helper cryptd sg iTCO_vendor_support i7core_edac >> edac_core shpchp lpc_ich i2c_i801 pcspkr mfd_core acpi_cpufreq ip_tables xfs >> libcrc32c sd_mod igb ata_generic ptp pata_acpi pps_core mptsas ata_piix >> scsi_transport_sas i2c_algo_bit libata mptscsih i2c_core serio_raw >> crc32c_intel bnx2 mptbase dca dm_mirror dm_region_hash dm_log dm_mod >> [ 168.805983] CPU: 15 PID: 10369 Comm: mmap1 Not tainted >> 4.11.0-rc2-327.28.3.53.x86_64+ #345 >> [ 168.814202] Hardware name: Huawei Technologies Co., Ltd. Tecal RH2285 >> /BC11BTSA , BIOS CTSAV036 04/27/2011 >> [ 168.825704] task: 8806207d5200 task.stack: c9000c34 >> [ 168.831592] RIP: 0033:0x7f3e622c5360 >> [ 168.835147] RSP: 002b:7ffe2bb7a098 EFLAGS: 00010203 >> [ 168.840344] RAX: 7ffe2bb7a0c0 RBX: RCX: >> 7f3e6275a000 >> [ 168.847439] RDX: 7f3e622c5360 RSI: 7f3e6275a000 RDI: >> 7ffe2bb7a0c0 >> [ 168.854535] RBP: 7ffe2bb7a4e0 R08: 7f3e621c3d58 R09: >> 002d >> [ 168.861632] R10: 7ffe2bb79e20 R11: 7f3e622fbcb0 R12: >> 004005d0 >> [ 168.868728] R13: 7ffe2bb7a5c0 R14: R15: >> >> [ 168.875825] FS: 7f3e62752740() GS:880627bc() >> knlGS: >> [ 168.883870] CS: 0010 DS: ES: CR0: 80050033 >> [ 168.889583] CR2: 7f3e6275a002 CR3: 000622845000 CR4: >> 06e0 >> [ 168.896680] RIP: 0x7f3e622c5360 RSP: 7ffe2bb7a098 >> [ 168.901713] ---[ end trace ef98fa9f2a01cbc6 ]--- >> [ 168.90630 arch/x86/kernel/smp.c:127 native_smp_send_reschedule+0x3f/0x50 >> [ 168.935410] Modules linked in: intel_powerclamp coretemp kvm_intel kvm >> irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel >> crypto_simd iTCO_wdt glue_helper cryptd sg iTCO_vendor_support i7core_edac >> edac_core shpchp lpc_ich i2c_i801 pcspkr mfd_core acpi_cpufreq ip_tables xfs >> libcrc32c sd_mod igb ata_generic ptp pata_acpi pps_core mptsas ata_piix >> scsi_transport_sas i2c_algo_bit libata mptscsih i2c_core serio_raw >> crc32c_intel bnx2 mptbase dca dm_mirror dm_region_hash dm_log dm_mod >> [ 168.979686] CPU: 15 PID: 10369 Comm: mmap1 Tainted: G D >> 4.11.0-rc2-327.28.3.53.x86_64+ #345 >> [ 168.989114] Hardware name: Huawei Technologies Co., Ltd. Tecal RH2285 >> /BC11BTSA , BIOS CTSAV036 04/27/2011 >> [ 169.000616] Call Trace: >> [ 169.003049] >> [ 169.005050] dump_stack+0x63/0x84 >> [ 169.008348] __warn+0xd1/0xf0 >> [ 169.011297] warn_slowpath_null+0x1d/0x20 >> [ 169.015282] native_smp_send_reschedule+0x3f/0x50 >> [ 169.019961] resched_curr+0xa1/0xc0 >> [ 169.023428] check_preempt_curr+0x70/0x90 >> [ 169.027415] ttwu_do_wakeup+0x1e/0x160 >> [ 169.031142] ttwu_do_activate+0x77/0x80 >> [ 169.034956] try_to_wake_up+0x1c3/0x430 >> [ 169.038771] default_wake_function+0x12/0x20 >> [ 169.043019] __wake_up_common+0x55/0x90 >> [ 169.046833] __wake_up_locked+0x13/0x20 >> [ 169.050649] ep_poll_callback+0xbb/0x240 >> [ 169.054550] __wake_up_common+0x55/0x90 >> [ 169.058363] __wake_up+0x39/0x50 >> [ 169.061574] wake_up_klogd_work_func+0x40/0x60 >> [ 169.065994] irq_work_run_list+0x4d/0x70 >> [ 169.069895] irq_work_tick+0x40/0x50 >> [ 169.073452] update_process_times+0x42/0x60 >> [ 169.077612] tick_periodic+0x2b/0x80 >> [ 169.081166] tick_handle_periodic+0x25/0x70 >> [ 169.085326] local_apic_timer_interrupt+0x35/0x60 >> [ 169.090004] smp_apic_timer_interrupt+0x38/0x50 >> [ 169.094507] apic_timer_interrupt+0x93/0xa0 >> [ 169.098667] RIP: 0010:panic+0x1f5/0x239 >> [ 169.102480] RSP: :c9000c343dd8 EFLAGS: 0246 ORIG_RAX: >> ff10 >> [ 169.110010] RAX: 0034 RBX: RCX: >> 0006 >> [ 169.117106] RDX: RSI: 0086 RDI: >> 880627bcdfe0 >> [ 169.124201] RBP: c9000c343e48 R08: fffe R09: >> 0395 >> [ 169.131298] R10: 0005 R11: 0394 R12: >> 81a0c475 >> [ 169.138395] R13: R14: R15: >> 000d >> [ 169.145491] >> [ 169.147578] ? panic+0x1f1/0x239 >> [ 169.150789] oops_end+0xb8/0xd0 >> [ 169.153910] pgtable_bad+0x8a/0x95 >> [ 169.157294]
Re: [RFC PATCH 0/4] PM / Domains: Add support for explicit control of PM domains
Hi Ulf,
On Wed, Apr 26, 2017 at 11:55 AM, Ulf Hansson wrote:
> On 26 April 2017 at 11:17, Geert Uytterhoeven wrote:
>> On Wed, Apr 26, 2017 at 11:04 AM, Ulf Hansson wrote:
>>> On 26 April 2017 at 10:06, Geert Uytterhoeven wrote:
On Tue, Apr 25, 2017 at 9:34 PM, Ulf Hansson
wrote:
> However, we currently know about at least two different SoCs that need
> this. Perhaps we can extend the below list to justify adding a new
> framework/APIs. Something along the lines what you propose in $subject
> patchset.
>
> 1) Nvidia; to solve the USB super-speed host/device problem.
> 2) QCOM, which has pointed to several cases where the PM topology is
> laid out like devices having two PM domains..
> 3?) I don't fully remember - but I think Geert also pointed to some
> examples where a device could reside in a clock domain but also in
> power domain for a Renesas SoC!?
> 4) ?
Most Renesas SoCs have module clocks, which we model as a clock domain.
Some Renesas SoCs have power domains for CPUs, others have them for
devices as well.
As we always provide a virtual "always-on" power domain in the power domain
controller, all devices can refer to it using "power-domains" properties,
and the driver for the power domain controller can just forward the clock
domain operations to the clock driver.
>>>
>>> Okay, thanks for clarifying this.
>>>
>>> Thinking about this as bit more, when I realized that *if* we would
>>> add a new PM domain framework for explicit control of PM domains, that
>>> would mean you need to deploy support for that in the drivers.
>>
>> Correct. And we have to update DT bindings and DTS.
>>
>>> On the other hand, as you anyway would need to change the drivers, you
>>> could instead deploy clock support in the drivers, which would avoid
>>> using the clock domain. In that way, you could still stay with one PM
>>> domain pointer per device, used to control the power domains instead.
>>> Right? Or would that have other implications?
>>
>> That's exactly what we're doing already.
>
> No really, but perhaps I was not clear enough.
>
> Currently you deploy only runtime PM support in the driver and don't
> do any clk_get() etc. Then you have a PM domain (genpd) attached to
> the device and makes use of genpd's device specific callbacks, in
> struct gpd_dev_ops ->start|stop(), which allows you to control clocks
> for each device. Of course this is perfectly okay.
OK.
> So then my question is/was; does there exist cases when these devices
> (already attached to a PM domain) would needed to be attach to yet
> another separate PM domain? From the nicely detailed description
> below, I find the answer to be *no*!?
Apart from the SYSC power areas and the CPG/MSSR clock domain
we don't have a use case for multiple power domains.
>> Which means that if you allow multiple entries in power-domains, we
>> have to change drivers, DT bindings, and DTS again (which we may
>> decide not to do ;-)
>>
>> On SH/R-Mobile, we always did it that way, as the user manual had an
>> explicit "always-on" power domain.
>>
>> On R-Car Gen2, the power domains contain CPU and L2 and GPU only,
>> so devices had their power-domains pointing to the clock controller.
>>
>> On R-Car Gen3, some devices were moved into power domains, so we
>> generalized this by creating a virtual "always-on" power domain, and
>> letting all devices point their power-domains properties to the power
>> domain controller, which forwards clock handling to the clock controller.
>> For consistency, this was applied to R-Car Gen2 as well.
>>
>> Cfr. some late relics fixed in e.g. commit 24b2d930a50662c1
>> ('ARM: dts: r8a7794: Use SYSC "always-on" PM Domain for sound'),
>> but technically the fix was not needed, as it worked fine without.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 09/13] lightnvm/pblk-read: use bio_clone_fast()
> On 2 May 2017, at 23.51, NeilBrown wrote: > >> >> Hi Neil, >> >> Looks good. Thanks for fixing this. I did not know that bio_clone_bioset >> was not supposed to be used on drivers. > > Prior to my patchset, using bio_clone_bioset() wasn't wrong in drivers, > though it was a waste when bio_clone_fast() would to just as well as is > more efficient. > After my patchset, using it can be problematic. I'm wondering what I > should do to encourage those problems to be more visible so that if > people to us it, they'll get a warning or something. > > Thanks, > NeilBrown > Thanks for the explanation Neil. In my opinion a comment on top of bio_clone_bioset() would be hellful, as Ming suggested. But a warning might make sense too. Javier signature.asc Description: Message signed with OpenPGP
Re: [PATCH] mm, vmalloc: properly track vmalloc users
On Wed 03-05-17 08:52:01, kbuild test robot wrote:
> Hi Michal,
>
> [auto build test ERROR on mmotm/master]
> [also build test ERROR on next-20170502]
> [cannot apply to v4.11]
> [if your patch is applied to the wrong git tree, please drop us a note to
> help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Michal-Hocko/mm-vmalloc-properly-track-vmalloc-users/20170503-065022
> base: git://git.cmpxchg.org/linux-mmotm.git master
> config: m68k-m5475evb_defconfig (attached as .config)
> compiler: m68k-linux-gcc (GCC) 4.9.0
> reproduce:
> wget
> https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=m68k
>
> All error/warnings (new ones prefixed by >>):
>
>In file included from arch/m68k/include/asm/pgtable_mm.h:145:0,
> from arch/m68k/include/asm/pgtable.h:4,
> from include/linux/vmalloc.h:9,
> from arch/m68k/kernel/module.c:9:
OK, I was little bit worried to pull pgtable.h include in, but my cross
compile build test battery didn't show any issues. I do not have m68k
there though. So let's just do this differently. The following updated
patch hasn't passed the full build test battery but it should just work.
Thanks for your testing.
---
>From 33a6239135cb444654f48d5e942e7f34898e24ea Mon Sep 17 00:00:00 2001
From: Michal Hocko
Date: Tue, 2 May 2017 11:18:29 +0200
Subject: [PATCH] mm, vmalloc: properly track vmalloc users
__vmalloc_node_flags used to be static inline but this has changed by
"mm: introduce kv[mz]alloc helpers" because kvmalloc_node needs to use
it as well and the code is outside of the vmalloc proper. I haven't
realized that changing this will lead to a subtle bug though. The
function is responsible to track the caller as well. This caller is
then printed by /proc/vmallocinfo. If __vmalloc_node_flags is not inline
then we would get only direct users of __vmalloc_node_flags as callers
(e.g. v[mz]alloc) which reduces usefulness of this debugging feature
considerably. It simply doesn't help to see that the given range belongs
to vmalloc as a caller:
0xc90002c79000-0xc90002c7d000 16384 vmalloc+0x16/0x18 pages=3 vmalloc
N0=3
0xc90002c81000-0xc90002c85000 16384 vmalloc+0x16/0x18 pages=3 vmalloc
N1=3
0xc90002c8d000-0xc90002c91000 16384 vmalloc+0x16/0x18 pages=3 vmalloc
N1=3
0xc90002c95000-0xc90002c99000 16384 vmalloc+0x16/0x18 pages=3 vmalloc
N1=3
We really want to catch the _caller_ of the vmalloc function. Fix this
issue by making __vmalloc_node_flags static inline again and export
__vmalloc_node_flags_caller for kvmalloc_node().
Signed-off-by: Michal Hocko
---
include/linux/vmalloc.h | 16 +++-
mm/util.c | 3 ++-
mm/vmalloc.c| 8 +++-
3 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h
index 46991ad3ddd5..4a0fabeb1e92 100644
--- a/include/linux/vmalloc.h
+++ b/include/linux/vmalloc.h
@@ -80,7 +80,21 @@ extern void *__vmalloc_node_range(unsigned long size,
unsigned long align,
unsigned long start, unsigned long end, gfp_t gfp_mask,
pgprot_t prot, unsigned long vm_flags, int node,
const void *caller);
-extern void *__vmalloc_node_flags(unsigned long size, int node, gfp_t flags);
+#ifndef CONFIG_MMU
+extern void *__vmalloc_node_flags_caller(unsigned long size, int node, gfp_t
flags);
+static inline void *__vmalloc_node_flags_caller(unsigned long size, int node,
gfp_t flags, void* caller)
+{
+ return __vmalloc_node_flags(size, node, flags);
+}
+#else
+/*
+ * We really want to have this inlined due to caller tracking. This
+ * function is used by the highlevel vmalloc apis and so we want to track
+ * their callers and inlining will achieve that.
+ */
+extern void *__vmalloc_node_flags_caller(unsigned long size,
+ int node, gfp_t flags, void* caller);
+#endif
extern void vfree(const void *addr);
extern void vfree_atomic(const void *addr);
diff --git a/mm/util.c b/mm/util.c
index 3022051da938..c35e5870921d 100644
--- a/mm/util.c
+++ b/mm/util.c
@@ -380,7 +380,8 @@ void *kvmalloc_node(size_t size, gfp_t flags, int node)
if (ret || size <= PAGE_SIZE)
return ret;
- return __vmalloc_node_flags(size, node, flags);
+ return __vmalloc_node_flags_caller(size, node, flags,
+ __builtin_return_address(0));
}
EXPORT_SYMBOL(kvmalloc_node);
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 65912eb93a2c..1a97d4a31406 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -1809,13 +1809,19 @@ void *__
Re:
With profound love in my heart, I Kindly Oblige your interest to very important proposal.. It is Truly Divine and require your utmost attention.. S hlubokou láskou v mém srdci, Laskave jsem prinutit svuj zájem k návrhu .. Je velmi duležité, skutecne Divine a vyžadují vaši nejvyšší pozornost. Kontaktujte me prímo pres: helenarobert...@gmail.com pro úplné podrobnosti.complete. HELINA .A ROBERTS --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: [PATCH] platform/x86: Make SILEAD_DMI depend on TOUCHSCREEN_SILEAD
On Fri, 28 Apr 2017 14:00:19 -0700, Darren Hart (VMware) wrote: > SILEAD_DMI provides platform specific data for the TOUCHSCREEN_SILEAD > driver. Make this explicitly clear in the Kconfig depends. > > Signed-off-by: Darren Hart (VMware) > Cc: Hans de Goede > Cc: Andy Shevchenko > Cc: Jean Delvare > Cc: Dmitry Torokhov > --- > drivers/platform/x86/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig > index 9e5b2c2..5690664 100644 > --- a/drivers/platform/x86/Kconfig > +++ b/drivers/platform/x86/Kconfig > @@ -1101,7 +1101,7 @@ config INTEL_TURBO_MAX_3 > > config SILEAD_DMI > bool "Tablets with Silead touchscreens" > - depends on ACPI && DMI && I2C=y && INPUT > + depends on ACPI && DMI && I2C=y && INPUT && TOUCHSCREEN_SILEAD > ---help--- > Certain ACPI based tablets with Silead touchscreens do not have > enough data in ACPI tables for the touchscreen driver to handle Reviewed-by: Jean Delvare Thanks Darren, -- Jean Delvare SUSE L3 Support
Re: [PATCH] printk: Add best-effort printk() buffering.
Joe Perches wrote:
> On Sun, 2017-04-30 at 22:54 +0900, Tetsuo Handa wrote:
> > Sometimes we want to printk() multiple lines in a group without being
> > disturbed by concurrent printk() from interrupts and/or other threads.
> > For example, mixed printk() output of multiple thread's dump makes it
> > hard to interpret.
> >
> > This patch introduces fixed-sized statically allocated buffers for
> > buffering printk() output for each thread/context in best effort
> > (i.e. up to PAGE_SIZE bytes, up to 16 concurrent printk() users).
> []
> > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> []
> > +#define MAX_PRINTK_BUFFERS 16
> > +static struct printk_buffer {
> > + unsigned long context; /* printk_context() */
> > + unsigned int nested;
> > + unsigned int used; /* Valid bytes in buf[]. */
> > + char buf[PAGE_SIZE];
> > +} printk_buffers[MAX_PRINTK_BUFFERS];
>
> Perhaps these buffers could be acquired by
> alloc_page rather than be static structures and
> the sizeof buf[PAGE_SIZE] should be reduced by
> sizeof(unsigned long) +
> sizeof(unsigned int) +
> sizeof(unsigned int)
> so that struct printk_buffers is exactly
> PAGE_SIZE.
When should the buffers be allocated? If upon boot, there will be little
difference. If the first time each buffer is needed, we introduce a risk
of failing to allocate memory using alloc_page(GFP_ATOMIC | __GFP_NOWARN)
and a risk of stack overflow during alloc_page() because printk() has to be
prepared for being called from stack-tight situation.
Also, while dynamic allocation can allow linked list of the buffer, we
will need to introduce a lock for traversing the list, which might become
more expensive than walking fixed-sized array of the buffer.
We could avoid list traversal by passing "struct printk_buffer" argument,
but since there are so many functions which expect pr_cont() behavior,
scattering "struct printk_buffer" argument is a big patch.
We could avoid list traversal by storing "struct printk_buffer[3]" inside
"struct task_struct" (for hard IRQ context, soft IRQ context, task context),
but occupying sizeof(struct printk_buffer *) * 3 bytes only for buffers
which will be used only for a moment is not smart.
Thus, I think fixed-sized statically allocated buffers is the most
reasonable choice. Using a CONFIG_ option for controlling how many pages
should be allocated for "struct printk_buffer" might make sense for systems
with little RAM.
Tetsuo Handa wrote:
> +void get_printk_buffer(void)
> +{
> + const unsigned long context = printk_context();
> + int i;
> +
> + /* No-op if called from NMI context. */
> + if ((context & 3) == 3)
> + return;
> + for (i = 0; i < MAX_PRINTK_BUFFERS; i++) {
> + struct printk_buffer *ptr = &printk_buffers[i];
> +
> + if (ptr->context != context) {
> + if (ptr->context ||
> + cmpxchg(&ptr->context, 0, context))
> + continue;
> + ptr->nested = 0;
> + ptr->used = 0;
> + } else {
> + ptr->nested++;
> + }
> + break;
> + }
> +}
Oops, I over-optimized here. We should not reserve ptr->context == 0 slot
before checking ptr->context != 0 slots, or we may race with nested calls.
void get_printk_buffer(void)
{
const unsigned long context = printk_context();
struct printk_buffer *ptr;
int i;
/* No-op if called from NMI context. */
if ((context & 3) == 3)
return;
ptr = find_printk_buffer();
if (ptr) {
ptr->nested++;
return;
}
for (i = 0; i < MAX_PRINTK_BUFFERS; i++) {
ptr = &printk_buffers[i];
if (ptr->context || cmpxchg(&ptr->context, 0, context))
continue;
ptr->nested = 0;
ptr->used = 0;
break;
}
}
> int vprintk_default(const char *fmt, va_list args)
> {
> + struct printk_buffer *ptr;
> + va_list args2;
> + unsigned int i;
> int r;
>
> #ifdef CONFIG_KGDB_KDB
> @@ -1806,6 +1960,43 @@ int vprintk_default(const char *fmt, va_list args)
> return r;
> }
> #endif
> + ptr = find_printk_buffer();
> + if (!ptr)
> + goto use_unbuffered;
> + /*
> + * Try to store to printk_buffer first. If it fails, flush completed
> + * lines in printk_buffer, and then try to store to printk_buffer
> + * again. If it still fails, flush incomplete line in printk_buffer
> + * and use unbuffered printing.
> + *
> + * Since printk_buffer is identified by current thread and interrupt
> + * context and same level of context does not recurse, we don't need
> + * logbuf_lock_irqsave()/logbuf_unlock_irqrestore() here except
> + * __flush_printk_buffer().
> + */
Before I con
Re: [PATCH 1/2] drm: Introduce crtc->mode_valid() callback
On Tue, May 2, 2017 at 11:29 AM, Jose Abreu wrote: > On 02-05-2017 09:48, Daniel Vetter wrote: >> On Wed, Apr 26, 2017 at 11:48:34AM +0100, Jose Abreu wrote: >>> Some crtc's may have restrictions in the mode they can display. In >>> this patch a new callback (crtc->mode_valid()) is introduced that >>> is called at the same stage of connector->mode_valid() callback. >>> >>> This shall be implemented if the crtc has some sort of restriction >>> so that we don't probe modes that will fail in the commit() stage. >>> For example: A given crtc may be responsible to set a clock value. >>> If the clock can not produce all the values for the available >>> modes then this callback can be used to restrict the number of >>> probbed modes to only the ones that can be displayed. >>> >>> If the crtc does not implement the callback then the behaviour will >>> remain the same. Also, for a given set of crtcs that can be bound to >>> the connector, if at least one can display the mode then the mode >>> will be probbed. >>> >>> Signed-off-by: Jose Abreu >>> Cc: Carlos Palminha >>> Cc: Alexey Brodkin >>> Cc: Ville Syrjälä >>> Cc: Daniel Vetter >>> Cc: Dave Airlie >> Not sure this is useful, since you still have to duplicate the exact same >> check into your ->mode_fixup hook. That seems to make things even more >> confusing. > > Yeah, in arcpgu I had to duplicate the code in ->atomic_check. > >> >> Also this doesn't update the various kerneldoc comments. For the existing >> hooks. Since this topic causes so much confusion, I don't think a >> half-solution will help, but has some good potential to make things worse. > > I only documented the callback in drm_modeset_helper_vtables.h. > > Despite all of this, I think it doesn't makes sense delivering > modes to userspace which can never be used. > > This is really annoying in arcpgu. Imagine: I try to use mpv to > play a video, the full set of modes from EDID were probed so if I > just start mpv it will pick the native mode of the TV instead of > the one that is supported, so mpv will fail to play. I know the > value of clock which will work (so I know what mode shall be > used), but a normal user which is not aware of the HW will have > to cycle through the list of modes and try them all until it hits > one that works. Its really boring. > > For the modes that user specifies manually there is nothing we > can do, but we should not trick users into thinking that a given > mode is supported when it will always fail at commit. Yes, you are supposed to filter these out in ->mode_valid. But my stance is that only adding a half-baked support for a new callback to the core isn't going to make life easier for drivers, it will just add to the confusion. There's already piles of docs for both @mode_valid and @mode_fixup hooks explaining this, I don't want to make the documentation even more complex. And half-baked crtc checking is _much_ easier to implement in the driver directly (e.g. i915 checks for crtc constraints since forever, as do the other big x86 drivers). So all taken together, if we add a ->mode_valid to crtcs, then imo we should do it right and actually make life easier for drivers. A good proof would be if your patch would allow us to drop a lot of the lenghty language from the @mode_valid hooks. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
Re: [PATCH 1/2] drm: Introduce crtc->mode_valid() callback
On Tue, May 2, 2017 at 11:29 AM, Jose Abreu wrote: > On 02-05-2017 09:48, Daniel Vetter wrote: >> On Wed, Apr 26, 2017 at 11:48:34AM +0100, Jose Abreu wrote: >>> Some crtc's may have restrictions in the mode they can display. In >>> this patch a new callback (crtc->mode_valid()) is introduced that >>> is called at the same stage of connector->mode_valid() callback. >>> >>> This shall be implemented if the crtc has some sort of restriction >>> so that we don't probe modes that will fail in the commit() stage. >>> For example: A given crtc may be responsible to set a clock value. >>> If the clock can not produce all the values for the available >>> modes then this callback can be used to restrict the number of >>> probbed modes to only the ones that can be displayed. >>> >>> If the crtc does not implement the callback then the behaviour will >>> remain the same. Also, for a given set of crtcs that can be bound to >>> the connector, if at least one can display the mode then the mode >>> will be probbed. >>> >>> Signed-off-by: Jose Abreu >>> Cc: Carlos Palminha >>> Cc: Alexey Brodkin >>> Cc: Ville Syrjälä >>> Cc: Daniel Vetter >>> Cc: Dave Airlie >> Not sure this is useful, since you still have to duplicate the exact same >> check into your ->mode_fixup hook. That seems to make things even more >> confusing. > > Yeah, in arcpgu I had to duplicate the code in ->atomic_check. > >> >> Also this doesn't update the various kerneldoc comments. For the existing >> hooks. Since this topic causes so much confusion, I don't think a >> half-solution will help, but has some good potential to make things worse. > > I only documented the callback in drm_modeset_helper_vtables.h. > > Despite all of this, I think it doesn't makes sense delivering > modes to userspace which can never be used. > > This is really annoying in arcpgu. Imagine: I try to use mpv to > play a video, the full set of modes from EDID were probed so if I > just start mpv it will pick the native mode of the TV instead of > the one that is supported, so mpv will fail to play. I know the > value of clock which will work (so I know what mode shall be > used), but a normal user which is not aware of the HW will have > to cycle through the list of modes and try them all until it hits > one that works. Its really boring. > > For the modes that user specifies manually there is nothing we > can do, but we should not trick users into thinking that a given > mode is supported when it will always fail at commit. Yes, you are supposed to filter these out in ->mode_valid. But my stance is that only adding a half-baked support for a new callback to the core isn't going to make life easier for drivers, it will just add to the confusion. There's already piles of docs for both @mode_valid and @mode_fixup hooks explaining this, I don't want to make the documentation even more complex. And half-baked crtc checking is _much_ easier to implement in the driver directly (e.g. i915 checks for crtc constraints since forever, as do the other big x86 drivers). So all taken together, if we add a ->mode_valid to crtcs, then imo we should do it right and actually make life easier for drivers. A good proof would be if your patch would allow us to drop a lot of the lenghty language from the @mode_valid hooks. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
Re: [patch v2] mm, vmscan: avoid thrashing anon lru when free + file is low
On Tue 02-05-17 13:41:23, David Rientjes wrote:
> On Tue, 2 May 2017, Michal Hocko wrote:
>
> > I have already asked and my questions were ignored. So let me ask again
> > and hopefuly not get ignored this time. So Why do we need a different
> > criterion on anon pages than file pages?
>
> The preference in get_scan_count() as already implemented is to reclaim
> from file pages if there is enough memory on the inactive list to reclaim.
> That is unchanged with this patch.
My fault, I was too vague. My question was basically why should we use
a different criterion to SCAN_ANON than SCAN_FILE.
> > I do agree that blindly
> > scanning anon pages when file pages are low is very suboptimal but this
> > adds yet another heuristic without _any_ numbers. Why cannot we simply
> > treat anon and file pages equally? Something like the following
> >
> > if (pgdatfile + pgdatanon + pgdatfree > 2*total_high_wmark) {
> > scan_balance = SCAN_FILE;
> > if (pgdatfile < pgdatanon)
> > scan_balance = SCAN_ANON;
> > goto out;
> > }
> >
>
> This would be substantially worse than the current code because it
> thrashes the anon lru when anon out numbers file pages rather than at the
> point we fall under the high watermarks for all eligible zones. If you
> tested your suggestion, you could see gigabytes of memory left untouched
> on the file lru. Anonymous memory is more probable to be part of the
> working set.
This was supposed to be more an example of a direction I was thinking,
definitely not a final patch. I will think more to come up with a
more complete proposal.
> > Also it would help to describe the workload which can trigger this
> > behavior so that we can compare numbers before and after this patch.
>
> Any workload that fills system RAM with anonymous memory that cannot be
> reclaimed will thrash the anon lru without this patch.
I have already asked, but I do not understand why this anon memory
couldn't be reclaimed. Who is pinning it? Why cannot it be swapped out?
If it is mlocked it should be moved to unevictable LRU. What am I
missing?
--
Michal Hocko
SUSE Labs
[PATCH 3/3] target: Don't force session reset if queue_depth does not change
From: Nicholas Bellinger Keeping in the idempotent nature of target_core_fabric_configfs.c, if a queue_depth value is set and it's the same as the existing value, don't attempt to force session reinstatement. Reported-by: Raghu Krishnamurthy Cc: Raghu Krishnamurthy Tested-by: Gary Guo Cc: Gary Guo Signed-off-by: Nicholas Bellinger --- drivers/target/target_core_tpg.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/target/target_core_tpg.c b/drivers/target/target_core_tpg.c index dfaef4d..310d9e5 100644 --- a/drivers/target/target_core_tpg.c +++ b/drivers/target/target_core_tpg.c @@ -398,6 +398,13 @@ int core_tpg_set_initiator_node_queue_depth( struct se_portal_group *tpg = acl->se_tpg; /* +* Allow the setting of se_node_acl queue_depth to be idempotent, +* and not force a session shutdown event if the value is not +* changing. +*/ + if (acl->queue_depth == queue_depth) + return 0; + /* * User has requested to change the queue depth for a Initiator Node. * Change the value in the Node's struct se_node_acl, and call * target_set_nacl_queue_depth() to set the new queue depth. -- 1.9.1
[PATCH 0/3] target: Fixes for v4.12-rc1
From: Nicholas Bellinger Hi all, Here are a couple of fixes from the last weeks testing while continuing longevity and scale out workloads on v4.x target code. This series contains three patches. The first is to address a COMPARE_AND_WRITE se_cmd reference leak where the READ phase hits a non GOOD status, observed with ESX VAAI hosts when outstanding READ I/O reaches a point where non SAM_STAT_GOOD status completions start to happen. The second addresses a hung task bug observed with iscsi-target ports while explicitly changing the active per se_node_acl queue_depth via the existing configfs attribute, if a new iscsi login was already forcing session reinstatement. And the third to is avoid forcing an session reinstatement if queue_depth is changed via configfs, but the value itself has not changed. The series has been verified on v4.1.y by DATERA Q/A and automation teams. Thank you, --nab Nicholas Bellinger (3): target: Fix compare_and_write_callback handling for non GOOD status iscsi-target: Set session_fall_back_to_erl0 when forcing reinstatement target: Don't force session reset if queue_depth does not change drivers/target/iscsi/iscsi_target.c | 1 + drivers/target/iscsi/iscsi_target_configfs.c | 1 + drivers/target/iscsi/iscsi_target_login.c| 1 + drivers/target/target_core_sbc.c | 5 - drivers/target/target_core_tpg.c | 7 +++ 5 files changed, 14 insertions(+), 1 deletion(-) -- 1.9.1
[PATCH 1/3] target: Fix compare_and_write_callback handling for non GOOD status
From: Nicholas Bellinger
Following the bugfix for handling non SAM_STAT_GOOD COMPARE_AND_WRITE
status during COMMIT phase in commit 9b2792c3da1, the same bug exists
for the READ phase as well.
This would manifest first as a lost SCSI response, and eventual
hung task during fabric driver logout or re-login, as existing
shutdown logic waited for the COMPARE_AND_WRITE se_cmd->cmd_kref
to reach zero.
To address this bug, compare_and_write_callback() has been changed
to set post_ret = 1 and return TCM_LOGICAL_UNIT_COMMUNICATION_FAILURE
as necessary to signal failure status.
Reported-by: Bill Borsari
Cc: Bill Borsari
Tested-by: Gary Guo
Cc: Gary Guo
Signed-off-by: Nicholas Bellinger
---
drivers/target/target_core_sbc.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/target/target_core_sbc.c b/drivers/target/target_core_sbc.c
index f9250b3..a0ad618 100644
--- a/drivers/target/target_core_sbc.c
+++ b/drivers/target/target_core_sbc.c
@@ -507,8 +507,11 @@ static sense_reason_t compare_and_write_callback(struct
se_cmd *cmd, bool succes
* been failed with a non-zero SCSI status.
*/
if (cmd->scsi_status) {
- pr_err("compare_and_write_callback: non zero scsi_status:"
+ pr_debug("compare_and_write_callback: non zero scsi_status:"
" 0x%02x\n", cmd->scsi_status);
+ *post_ret = 1;
+ if (cmd->scsi_status == SAM_STAT_CHECK_CONDITION)
+ ret = TCM_LOGICAL_UNIT_COMMUNICATION_FAILURE;
goto out;
}
--
1.9.1
[PATCH 2/3] iscsi-target: Set session_fall_back_to_erl0 when forcing reinstatement
From: Nicholas Bellinger
While testing modification of per se_node_acl queue_depth forcing
session reinstatement via lio_target_nacl_cmdsn_depth_store() ->
core_tpg_set_initiator_node_queue_depth(), a hung task bug triggered
when changing cmdsn_depth invoked session reinstatement while an iscsi
login was already waiting for session reinstatement to complete.
This can happen when an outstanding se_cmd descriptor is taking a
long time to complete, and session reinstatement from iscsi login
or cmdsn_depth change occurs concurrently.
To address this bug, explicitly set session_fall_back_to_erl0 = 1
when forcing session reinstatement, so session reinstatement is
not attempted if an active session is already being shutdown.
This patch has been tested with two scenarios. The first when
iscsi login is blocked waiting for iscsi session reinstatement
to complete followed by queue_depth change via configfs, and
second when queue_depth change via configfs us blocked followed
by a iscsi login driven session reinstatement.
Note this patch depends on commit d36ad77f702 to handle multiple
sessions per se_node_acl when changing cmdsn_depth, and for
pre v4.5 kernels will need to be included for stable as well.
Reported-by: Gary Guo
Tested-by: Gary Guo
Cc: Gary Guo
Signed-off-by: Nicholas Bellinger
---
drivers/target/iscsi/iscsi_target.c | 1 +
drivers/target/iscsi/iscsi_target_configfs.c | 1 +
drivers/target/iscsi/iscsi_target_login.c| 1 +
3 files changed, 3 insertions(+)
diff --git a/drivers/target/iscsi/iscsi_target.c
b/drivers/target/iscsi/iscsi_target.c
index 0f7ade0..26a9bcd 100644
--- a/drivers/target/iscsi/iscsi_target.c
+++ b/drivers/target/iscsi/iscsi_target.c
@@ -4663,6 +4663,7 @@ int iscsit_release_sessions_for_tpg(struct
iscsi_portal_group *tpg, int force)
continue;
}
atomic_set(&sess->session_reinstatement, 1);
+ atomic_set(&sess->session_fall_back_to_erl0, 1);
spin_unlock(&sess->conn_lock);
list_move_tail(&se_sess->sess_list, &free_list);
diff --git a/drivers/target/iscsi/iscsi_target_configfs.c
b/drivers/target/iscsi/iscsi_target_configfs.c
index 344e844..96d9c73 100644
--- a/drivers/target/iscsi/iscsi_target_configfs.c
+++ b/drivers/target/iscsi/iscsi_target_configfs.c
@@ -1528,6 +1528,7 @@ static void lio_tpg_close_session(struct se_session
*se_sess)
return;
}
atomic_set(&sess->session_reinstatement, 1);
+ atomic_set(&sess->session_fall_back_to_erl0, 1);
spin_unlock(&sess->conn_lock);
iscsit_stop_time2retain_timer(sess);
diff --git a/drivers/target/iscsi/iscsi_target_login.c
b/drivers/target/iscsi/iscsi_target_login.c
index ad8f301..6623847 100644
--- a/drivers/target/iscsi/iscsi_target_login.c
+++ b/drivers/target/iscsi/iscsi_target_login.c
@@ -208,6 +208,7 @@ int iscsi_check_for_session_reinstatement(struct iscsi_conn
*conn)
initiatorname_param->value) &&
(sess_p->sess_ops->SessionType == sessiontype))) {
atomic_set(&sess_p->session_reinstatement, 1);
+ atomic_set(&sess_p->session_fall_back_to_erl0, 1);
spin_unlock(&sess_p->conn_lock);
iscsit_inc_session_usage_count(sess_p);
iscsit_stop_time2retain_timer(sess_p);
--
1.9.1
Re: [PATCH] RTC: Add functionality to read/write rtc scratch registers
On Tuesday 18 April 2017 10:50 AM, Keerthy wrote:
> From: Russ Dill
>
> Many RTCs provide scratch registers that are maintained so long as the RTC
> has power. Provide a generic method to access these registers.
>
A gentle ping on this
> Signed-off-by: Russ Dill
> Signed-off-by: Keerthy
> ---
> drivers/rtc/interface.c | 50
> +
> drivers/rtc/rtc-omap.c | 35 ++
> include/linux/rtc.h | 7 +++
> 3 files changed, 92 insertions(+)
>
> diff --git a/drivers/rtc/interface.c b/drivers/rtc/interface.c
> index fc0fa75..facde06 100644
> --- a/drivers/rtc/interface.c
> +++ b/drivers/rtc/interface.c
> @@ -1016,3 +1016,53 @@ int rtc_set_offset(struct rtc_device *rtc, long offset)
> mutex_unlock(&rtc->ops_lock);
> return ret;
> }
> +
> +/* rtc_read_scratch - Read from RTC scratch register
> + * @ rtc: rtc device to be used
> + * @ index: index of scratch register
> + * @ value: returned value read
> + *
> + * Kernel interface read from an RTC scratch register
> + */
> +int rtc_read_scratch(struct rtc_device *rtc, unsigned int index, u32 *value)
> +{
> + int err;
> +
> + mutex_lock(&rtc->ops_lock);
> + if (!rtc->ops)
> + err = -ENODEV;
> + else if (index >= rtc->ops->scratch_size || !rtc->ops->read_scratch)
> + err = -EINVAL;
> + else
> + err = rtc->ops->read_scratch(rtc->dev.parent, index, value);
> + mutex_unlock(&rtc->ops_lock);
> + return err;
> +}
> +EXPORT_SYMBOL_GPL(rtc_read_scratch);
> +
> +/* rtc_write_scratch - Write to RTC scratch register
> + * @ rtc: rtc device to be used
> + * @ index: index of scratch register
> + * @ value: value to write
> + *
> + * Kernel interface write to an RTC scratch register
> + */
> +int rtc_write_scratch(struct rtc_device *rtc, unsigned int index, u32 value)
> +{
> + int err;
> +
> + mutex_lock(&rtc->ops_lock);
> +
> + if (!rtc->ops)
> + err = -ENODEV;
> + else if (index >= rtc->ops->scratch_size ||
> + !rtc->ops->write_scratch)
> + err = -EINVAL;
> + else
> + err = rtc->ops->write_scratch(rtc->dev.parent, index, value);
> +
> + mutex_unlock(&rtc->ops_lock);
> +
> + return err;
> +}
> +EXPORT_SYMBOL_GPL(rtc_write_scratch);
> diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
> index 13f7cd1..c90d93e 100644
> --- a/drivers/rtc/rtc-omap.c
> +++ b/drivers/rtc/rtc-omap.c
> @@ -70,6 +70,10 @@
> #define OMAP_RTC_COMP_MSB_REG0x50
> #define OMAP_RTC_OSC_REG 0x54
>
> +#define OMAP_RTC_SCRATCH0_REG0x60
> +#define OMAP_RTC_SCRATCH1_REG0x64
> +#define OMAP_RTC_SCRATCH2_REG0x68
> +
> #define OMAP_RTC_KICK0_REG 0x6c
> #define OMAP_RTC_KICK1_REG 0x70
>
> @@ -414,6 +418,34 @@ static int omap_rtc_set_alarm(struct device *dev, struct
> rtc_wkalrm *alm)
>
> static struct omap_rtc *omap_rtc_power_off_rtc;
>
> +static const u32 omap_rtc_scratch_regs[] = {
> + OMAP_RTC_SCRATCH0_REG,
> + OMAP_RTC_SCRATCH1_REG,
> + OMAP_RTC_SCRATCH2_REG,
> +};
> +
> +static int omap_rtc_read_scratch(struct device *dev, unsigned int index,
> + u32 *value)
> +{
> + *value = readl(omap_rtc_power_off_rtc->base +
> +omap_rtc_scratch_regs[index]);
> +
> + return 0;
> +}
> +
> +static int omap_rtc_write_scratch(struct device *dev, unsigned int index,
> + u32 value)
> +{
> + struct omap_rtc *rtc = dev_get_drvdata(dev);
> +
> + rtc->type->unlock(rtc);
> + writel(value, omap_rtc_power_off_rtc->base +
> +omap_rtc_scratch_regs[index]);
> + rtc->type->lock(rtc);
> +
> + return 0;
> +}
> +
> /*
> * omap_rtc_poweroff: RTC-controlled power off
> *
> @@ -484,6 +516,9 @@ static void omap_rtc_power_off(void)
> .read_alarm = omap_rtc_read_alarm,
> .set_alarm = omap_rtc_set_alarm,
> .alarm_irq_enable = omap_rtc_alarm_irq_enable,
> + .read_scratch = omap_rtc_read_scratch,
> + .write_scratch = omap_rtc_write_scratch,
> + .scratch_size = ARRAY_SIZE(omap_rtc_scratch_regs),
> };
>
> static const struct omap_rtc_device_type omap_rtc_default_type = {
> diff --git a/include/linux/rtc.h b/include/linux/rtc.h
> index b693ada..da5e003 100644
> --- a/include/linux/rtc.h
> +++ b/include/linux/rtc.h
> @@ -91,6 +91,10 @@ struct rtc_class_ops {
> int (*alarm_irq_enable)(struct device *, unsigned int enabled);
> int (*read_offset)(struct device *, long *offset);
> int (*set_offset)(struct device *, long offset);
> + int (*read_scratch)(struct device *, unsigned int, u32*);
> + int (*write_scratch)(struct device *, unsigned int, u32);
> +
> + unsigned int scratch_size;
> };
>
> #define RTC_DEVICE_NAME_SIZE 20
> @@ -214,6 +218,9 @@ int rtc_timer_start(struct rtc_device *rtc, s
Re: [PATCH] vmscan: scan pages until it founds eligible pages
On Wed 03-05-17 13:48:09, Minchan Kim wrote: > On Tue, May 02, 2017 at 05:14:36PM +0200, Michal Hocko wrote: > > On Tue 02-05-17 23:51:50, Minchan Kim wrote: > > > Hi Michal, > > > > > > On Tue, May 02, 2017 at 09:54:32AM +0200, Michal Hocko wrote: > > > > On Tue 02-05-17 14:14:52, Minchan Kim wrote: > > > > > Oops, forgot to add lkml and linux-mm. > > > > > Sorry for that. > > > > > Send it again. > > > > > > > > > > >From 8ddf1c8aa15baf085bc6e8c62ce705459d57ea4c Mon Sep 17 00:00:00 > > > > > >2001 > > > > > From: Minchan Kim > > > > > Date: Tue, 2 May 2017 12:34:05 +0900 > > > > > Subject: [PATCH] vmscan: scan pages until it founds eligible pages > > > > > > > > > > On Tue, May 02, 2017 at 01:40:38PM +0900, Minchan Kim wrote: > > > > > There are premature OOM happening. Although there are a ton of free > > > > > swap and anonymous LRU list of elgible zones, OOM happened. > > > > > > > > > > With investigation, skipping page of isolate_lru_pages makes reclaim > > > > > void because it returns zero nr_taken easily so LRU shrinking is > > > > > effectively nothing and just increases priority aggressively. > > > > > Finally, OOM happens. > > > > > > > > I am not really sure I understand the problem you are facing. Could you > > > > be more specific please? What is your configuration etc... > > > > > > Sure, KVM guest on x86_64, It has 2G memory and 1G swap and configured > > > movablecore=1G to simulate highmem zone. > > > Workload is a process consumes 2.2G memory and then random touch the > > > address space so it makes lots of swap in/out. > > > > > > > > > > > > balloon invoked oom-killer: > > > > > gfp_mask=0x17080c0(GFP_KERNEL_ACCOUNT|__GFP_ZERO|__GFP_NOTRACK), > > > > > nodemask=(null), order=0, oom_score_adj=0 > > > > [...] > > > > > Node 0 active_anon:1698864kB inactive_anon:261256kB active_file:208kB > > > > > inactive_file:184kB unevictable:0kB isolated(anon):0kB > > > > > isolated(file):0kB mapped:532kB dirty:108kB writeback:0kB shmem:172kB > > > > > writeback_tmp:0kB unstable:0kB all_unreclaimable? no > > > > > DMA free:7316kB min:32kB low:44kB high:56kB active_anon:8064kB > > > > > inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB > > > > > writepending:0kB present:15992kB managed:15908kB mlocked:0kB > > > > > slab_reclaimable:464kB slab_unreclaimable:40kB kernel_stack:0kB > > > > > pagetables:24kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB > > > > > lowmem_reserve[]: 0 992 992 1952 > > > > > DMA32 free:9088kB min:2048kB low:3064kB high:4080kB > > > > > active_anon:952176kB inactive_anon:0kB active_file:36kB > > > > > inactive_file:0kB unevictable:0kB writepending:88kB present:1032192kB > > > > > managed:1019388kB mlocked:0kB slab_reclaimable:13532kB > > > > > slab_unreclaimable:16460kB kernel_stack:3552kB pagetables:6672kB > > > > > bounce:0kB free_pcp:56kB local_pcp:24kB free_cma:0kB > > > > > lowmem_reserve[]: 0 0 0 959 > > > > > > > > Hmm DMA32 has sufficient free memory to allow this order-0 request. > > > > Inactive anon lru is basically empty. Why do not we rotate a really > > > > large active anon list? Isn't this the primary problem? > > > > > > It's a side effect by skipping page logic in isolate_lru_pages > > > I mentioned above in changelog. > > > > > > The problem is a lot of anonymous memory in movable zone(ie, highmem) > > > and non-small memory in DMA32 zone. > > > > Such a configuration is questionable on its own. But let't keep this > > part alone. > > It seems you are misunderstood. It's really common on 32bit. Yes, I am not arguing about 32b systems. It is quite common to see issues which are inherent to the highmem zone. > Think of 2G DRAM system on 32bit. Normally, it's 1G normal:1G highmem. > It's almost same with one I configured. > > > > > > In heavy memory pressure, > > > requesting a page in GFP_KERNEL triggers reclaim. VM knows inactive list > > > is low so it tries to deactivate pages. For it, first of all, it tries > > > to isolate pages from active list but there are lots of anonymous pages > > > from movable zone so skipping logic in isolate_lru_pages works. With > > > the result, isolate_lru_pages cannot isolate any eligible pages so > > > reclaim trial is effectively void. It continues to meet OOM. > > > > But skipped pages should be rotated and we should eventually hit pages > > from the right zone(s). Moreover we should scan the full LRU at priority > > 0 so why exactly we hit the OOM killer? > > Yes, full scan in priority 0 but keep it in mind that the number of full > LRU pages to scan is one of eligible pages, not all pages of the node. I have hard time understanding what you are trying to say here. > And isolate_lru_pages have accounted skipped pages as scan count so that > VM cannot isolate any pages of eligible pages in LRU if non-eligible pages > are a lot in the LRU. > > > > > Anyway [1] has changed this behavior. Are you seeing the issue with this > > patch dropped? > > Good point. Be
[PATCH] staging : rtl8188eu : remove void function return
kernel coding style doesn't allow the return statement in void function. Signed-off-by: Surender Polsani --- Changes for v2: corrected subject line as suggested Changes for v3: modified from line as suggested by Greg KH placed a semicolon in label for fixing build error --- drivers/staging/rtl8188eu/hal/rtl8188e_dm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/rtl8188eu/hal/rtl8188e_dm.c b/drivers/staging/rtl8188eu/hal/rtl8188e_dm.c index d04b7fb..428996e 100644 --- a/drivers/staging/rtl8188eu/hal/rtl8188e_dm.c +++ b/drivers/staging/rtl8188eu/hal/rtl8188e_dm.c @@ -165,7 +165,7 @@ void rtw_hal_dm_watchdog(struct adapter *Adapter) skip_dm: /* Check GPIO to determine current RF on/off and Pbc status. */ /* Check Hardware Radio ON/OFF or not */ - return; + ; } void rtw_hal_dm_init(struct adapter *Adapter) -- 1.9.1
linux-next: Tree for May 3
Hi all, Please do not add any v4.13 destined material in your linux-next included branches until after v4.12-rc1 has been released. Changes since 20170502: The kbuild tree gained a conflict against Linus' tree. The metag tree gained a conflict against Linus' tree. The nfs tree gained a conflict against Linus' tree. The net-next tree gained a conflict against Linus' tree. I added a supplied build fix patch to the merge of the iommu tree. Non-merge commits (relative to Linus' tree): 10894 9725 files changed, 1182075 insertions(+), 200900 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 (with CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. Below is a summary of the state of the merge. I am currently merging 258 trees (counting Linus' and 37 trees of bug fix patches pending for the current merge release). 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 Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (204f144c9fca Merge branch 'work.compat' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs) Merging fixes/master (97da3854c526 Linux 4.11-rc3) Merging kbuild-current/fixes (9be3213b14d4 gconfig: remove misleading parentheses around a condition) Merging arc-current/for-curr (36b5a5152119 arc: axs10x: Fix ARC PGU default clock frequency) Merging arm-current/fixes (6d8059493691 ARM: 8670/1: V7M: Do not corrupt vector table around v7m_invalidate_l1 call) Merging m68k-current/for-linus (f6ab4d59a5fe nubus: Add MVC and VSC video card definitions) Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups) Merging powerpc-fixes/fixes (be5c5e843c4a powerpc/64: Fix HMI exception on LE with CONFIG_RELOCATABLE=y) Merging sparc/master (f83246089ca0 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc) Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and linking special files) Merging net/master (0060e79a1f52 Merge tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux) Merging ipsec/master (cfcf99f987ba xfrm: fix GRO for !CONFIG_NETFILTER) Merging netfilter/master (1519fccb3437 netfilter: update MAINTAINERS file) Merging ipvs/master (c8d6c6b496dc ipvs: SNAT packet replies only for NATed connections) Merging wireless-drivers/master (d77facb88448 brcmfmac: use local iftype avoiding use-after-free of virtual interface) Merging mac80211/master (a351e9b9fc24 Linux 4.11) Merging sound-current/for-linus (a5c3b32a1146 Merge tag 'asoc-v4.12' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus) Merging pci-current/for-linus (b9c1153f7a9c PCI: hisi: Fix DT binding (hisi-pcie-almost-ecam)) Merging driver-core.current/driver-core-linus (39da7c509acf Linux 4.11-rc6) Merging tty.current/tty-linus (4f7d029b9bf0 Linux 4.11-rc7) Merging usb.current/usb-linus (a71c9a1c779f Linux 4.11-rc5) Merging usb-gadget-fixes/fixes (25cd9721c2b1 usb: gadget: f_hid: fix: Don't access hidg->req without spinlock held) Merging usb-serial-fixes/usb-linus (c02ed2e75ef4 Linux 4.11-rc4) Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move the lock initialization to core file) Merging phy/fixes (1a09b6a7c10e phy: qcom-usb-hs: Add depends on EXTCON) Merging staging.current/staging-linus (39da7c509acf Linux 4.11-rc6) Merging char-misc.current/char-misc-linus (c02ed2e75ef4 Linux 4.11-rc4) Merging input-current/for-linus (0337966d121e Merge branch 'next' into for-linus) CONFLICT (content): Merge conflict in Documentation/in
Re: linux-next: build warning after merge of the devicetree tree
Hi Rob,
On Fri, 28 Apr 2017 12:45:03 +1000 Stephen Rothwell
wrote:
>
> After merging the devicetree tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
>
> drivers/of/unittest.c: In function 'of_unittest':
> drivers/of/unittest.c:2199:25: warning: 'last_sibling' may be used
> uninitialized in this function [-Wmaybe-uninitialized]
>last_sibling->sibling = overlay_base_root->child;
> ^
> drivers/of/unittest.c:2122:22: note: 'last_sibling' was declared here
> struct device_node *last_sibling;
> ^
>
> Introduced by commit
>
> 81d0848fc8d2 ("of: Add unit tests for applying overlays")
Ping?
--
Cheers,
Stephen Rothwell
Re: [RFC PATCH 8/9] debugfs: defer debugfs_fsdata allocation to first usage
On Tue, 2017-05-02 at 22:05 +0200, Nicolai Stange wrote: > > So either you could return some valid ops (perhaps > > debugfs_noop_file_operations although those don't have .name or > > .poll, so it doesn't cover everything), or you can just BUG_ON() > > here directly, saving the incomprehensible crash later. > > The purpose of that WARN_ON() there was to turn a potentially > incomprehensible crash into a comprehensible one ;) > > In order to avoid a new BUG_ON(), what about keeping the WARN_ON() as > is and returning NULL instead of the garbage? That would crash > current on first access and the earlier warning would hopefully give > some clue? Yeah, I guess that might work. Probably less harmful to the system than a BUG_ON(), but I still operate under the assumption that there might actually be something mapped at NULL - not sure if that's still true. johannes
Re: [PATCH v2] iio: adc: Add support for TI ADC1x8s102
On 2017-05-02 22:53, Andy Shevchenko wrote:
> On Tue, May 2, 2017 at 11:02 PM, Jan Kiszka wrote:
>> This is an upstream port of an IIO driver for the TI ADC108S102 and
>> ADC128S102. The former can be found on the Intel Galileo Gen2 and the
>> Siemens SIMATIC IOT2000. For those boards, ACPI-based enumeration is
>> included.
>>
>> Original author: Bogdan Pricop
>> Ported from Intel Galileo Gen2 BSP to Intel Yocto kernel:
>> Todor Minchev .
>
> There are several nitpicks, and one concern about regulator.
> After addressing at least the latter
>
> Reviewed-by: Andy Shevchenko
>
>> +#include
>
>> +#include
>
> Redundant I beleive.
>
>> +static int adc108s102_update_scan_mode(struct iio_dev *indio_dev,
>> + unsigned long const *active_scan_mask)
>> +{
>> + struct adc108s102_state *st;
>> + unsigned int bit, cmds;
>
>> +
>> + st = iio_priv(indio_dev);
>> +
>
> I think it's a quite good pattern to assign such variables above at
> definition block.
> This also would be done in several functions below (except ->probe() call)
>
>> + /*
>> +* Fill in the first x shorts of tx_buf with the number of channels
>> +* enabled for sampling by the triggered buffer
>> +*/
>
> Usually in multiline comments even for one sentence we use period at the end.
>
>> + cmds = 0;
>> + for_each_set_bit(bit, active_scan_mask, ADC108S102_MAX_CHANNELS)
>> + st->tx_buf[cmds++] = cpu_to_be16(ADC108S102_CMD(bit));
>> +
>> + /* One dummy command added, to clock in the last response */
>> + st->tx_buf[cmds++] = 0x00;
>> +
>> + /* build SPI ring message */
>
>> + st->ring_xfer.tx_buf = &st->tx_buf[0];
>> + st->ring_xfer.rx_buf = &st->rx_buf[0];
>
> &pointer[0] -> pointer
This is following patterns in other drivers, expressing you want the
first element here. I'll keep it.
>
>> + st->ring_xfer.len = cmds * sizeof(st->tx_buf[0]);
>> +
>> + spi_message_init_with_transfers(&st->ring_msg, &st->ring_xfer, 1);
>> +
>> + return 0;
>> +}
>> +
>> +static irqreturn_t adc108s102_trigger_handler(int irq, void *p)
>> +{
>> + struct iio_poll_func *pf = p;
>> + struct iio_dev *indio_dev;
>> + struct adc108s102_state *st;
>> + int ret;
>> +
>
>> + indio_dev = pf->indio_dev;
>> + st = iio_priv(indio_dev);
>
> Assign them above.
>
>> +out:
>
> I would name it out_notify.
>
>> + iio_trigger_notify_done(indio_dev->trig);
>> +
>> + return IRQ_HANDLED;
>> +}
>
>> +static int adc108s102_read_raw(struct iio_dev *indio_dev,
>> + struct iio_chan_spec const *chan,
>> + int *val, int *val2, long m)
>> +{
>
>> + int ret;
>> + struct adc108s102_state *st;
>
> Reversed tree order.
>
>> +
>> + st = iio_priv(indio_dev);
>> +
>
> Assign it above.
>
>> + switch (m) {
>> + case IIO_CHAN_INFO_RAW:
>> + ret = iio_device_claim_direct_mode(indio_dev);
>> + if (ret)
>> + return ret;
>> +
>> + ret = adc108s102_scan_direct(st, chan->address);
>> +
>> + iio_device_release_direct_mode(indio_dev);
>> +
>> + if (ret < 0)
>> + return ret;
>> +
>> + *val = ADC108S102_RES_DATA(ret);
>> +
>> + return IIO_VAL_INT;
>> + case IIO_CHAN_INFO_SCALE:
>> + switch (chan->type) {
>> + case IIO_VOLTAGE:
>> + if (st->reg)
>> + *val = regulator_get_voltage(st->reg) / 1000;
>> + else
>> + *val = st->ext_vin_mv;
>> +
>> + *val2 = chan->scan_type.realbits;
>> + return IIO_VAL_FRACTIONAL_LOG2;
>
>> + default:
>> + return -EINVAL;
>
> Switch-case for one case? Are you expecting more in the future?
> Here I have no strong opinion, so, leave what you / maintainers prefer.
I've no expectations on the code as I didn't write it in the first
place. There are both patterns around, but let's got for the more
compact if-else.
>
>> + }
>> + default:
>> + return -EINVAL;
>> + }
>> +}
>
>> +static int adc108s102_probe(struct spi_device *spi)
>> +{
>> + struct adc108s102_state *st;
>> + struct iio_dev *indio_dev;
>> + u32 val;
>> + int ret;
>> +
>> + indio_dev = devm_iio_device_alloc(&spi->dev, sizeof(*st));
>> + if (!indio_dev)
>> + return -ENOMEM;
>> +
>> + st = iio_priv(indio_dev);
>> +
>
>> + ret = device_property_read_u32(&spi->dev, "ext-vin-microvolt", &val);
>
> Why not to read u16 here?
>
Can I read a property with arbitrary width? Then this would simplify
things. Or do I have to follow how it was defined in the ACPI or device
tree world?
>
>> + if (r
[PATCH v3 3/4] soc: qcom: Add device tree binding for GLINK RPM
Add device tree binding documentation for the Qualcomm GLINK RPM, used
for communication with the Resource Power Management subsystem in
various Qualcomm SoCs.
Signed-off-by: Bjorn Andersson
---
Changes since v2:
- Replace qcom,ipc syscon with a "doorbell"
Changes since v1:
- None
.../devicetree/bindings/soc/qcom/qcom,glink.txt| 73 ++
1 file changed, 73 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt
b/Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt
new file mode 100644
index ..4c8983f0dcb0
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt
@@ -0,0 +1,73 @@
+Qualcomm RPM GLINK binding
+
+This binding describes the Qualcomm RPM GLINK, a fifo based mechanism for
+communication with the Resource Power Management system on various Qualcomm
+platforms.
+
+- compatible:
+ Usage: required
+ Value type:
+ Definition: must be "qcom,glink-rpm"
+
+- interrupts:
+ Usage: required
+ Value type:
+ Definition: should specify the IRQ used by the remote processor to
+ signal this processor about communication related events
+
+- qcom,rpm-msg-ram:
+ Usage: required
+ Value type:
+ Definition: handle to RPM message memory resource
+
+- doorbells:
+ Usage: required
+ Value type:
+ Definition: reference to the "rpm_hlos" doorbell in APCS, as described
+ in doorbell.txt
+
+= GLINK DEVICES
+Each subnode of the GLINK node represent function tied to a virtual
+communication channel. The name of the nodes are not important. The properties
+of these nodes are defined by the individual bindings for the specific function
+- but must contain the following property:
+
+- qcom,glink-channels:
+ Usage: required
+ Value type:
+ Definition: a list of channels tied to this function, used for matching
+ the function to a set of virtual channels
+
+= EXAMPLE
+The following example represents the GLINK RPM node on a MSM8996 device, with
+the function for the "rpm_request" channel defined, which is used for
+regualtors and root clocks.
+
+ apcs_glb: apcs-glb@982 {
+ compatible = "qcom,msm8996-apcs-hmss-global";
+ reg = <0x982 0x1000>;
+
+ #doorbell-cells = <1>;
+ };
+
+ rpm_msg_ram: memory@68000 {
+ compatible = "qcom,rpm-msg-ram";
+ reg = <0x68000 0x6000>;
+ };
+
+rpm-glink {
+ compatible = "qcom,glink-rpm";
+
+ interrupts = ;
+
+ qcom,rpm-msg-ram = <&rpm_msg_ram>;
+
+ doorbells = <&apcs_glb 0>;
+
+ rpm-requests {
+ compatible = "qcom,rpm-msm8996";
+ qcom,glink-channels = "rpm_requests";
+
+ ...
+ };
+ };
--
2.12.0
[PATCH v3 4/4] rpmsg: Introduce Qualcomm RPM glink driver
This introduces a basic driver for communicating over "native glink"
with the RPM found in Qualcomm platforms.
Signed-off-by: Bjorn Andersson
---
Changes since v2:
- Replace syscon with apcs_ipc doorbell implementation
Changes since v1:
- Depend on HAS_IOMEM, for UM build failure
- Wrap read/write indices on >= size, to keep the values valid when message
aligns with end of fifo.
drivers/rpmsg/Kconfig | 10 +
drivers/rpmsg/Makefile |1 +
drivers/rpmsg/qcom_glink_rpm.c | 1225
3 files changed, 1236 insertions(+)
create mode 100644 drivers/rpmsg/qcom_glink_rpm.c
diff --git a/drivers/rpmsg/Kconfig b/drivers/rpmsg/Kconfig
index f12ac0b28263..449d43511c92 100644
--- a/drivers/rpmsg/Kconfig
+++ b/drivers/rpmsg/Kconfig
@@ -13,6 +13,16 @@ config RPMSG_CHAR
in /dev. They make it possible for user-space programs to send and
receive rpmsg packets.
+config RPMSG_QCOM_GLINK_RPM
+ tristate "Qualcomm RPM Glink driver"
+ select RPMSG
+ depends on HAS_IOMEM
+ depends on QCOM_APCS_IPC
+ help
+ Say y here to enable support for the GLINK RPM communication driver,
+ which serves as a channel for communication with the RPM in GLINK
+ enabled systems.
+
config RPMSG_QCOM_SMD
tristate "Qualcomm Shared Memory Driver (SMD)"
depends on QCOM_SMEM
diff --git a/drivers/rpmsg/Makefile b/drivers/rpmsg/Makefile
index fae9a6d548fb..28cc19088cc0 100644
--- a/drivers/rpmsg/Makefile
+++ b/drivers/rpmsg/Makefile
@@ -1,4 +1,5 @@
obj-$(CONFIG_RPMSG)+= rpmsg_core.o
obj-$(CONFIG_RPMSG_CHAR) += rpmsg_char.o
+obj-$(CONFIG_RPMSG_QCOM_GLINK_RPM) += qcom_glink_rpm.o
obj-$(CONFIG_RPMSG_QCOM_SMD) += qcom_smd.o
obj-$(CONFIG_RPMSG_VIRTIO) += virtio_rpmsg_bus.o
diff --git a/drivers/rpmsg/qcom_glink_rpm.c b/drivers/rpmsg/qcom_glink_rpm.c
new file mode 100644
index ..d3a4951e0b78
--- /dev/null
+++ b/drivers/rpmsg/qcom_glink_rpm.c
@@ -0,0 +1,1225 @@
+/*
+ * Copyright (c) 2016-2017, Linaro Ltd
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "rpmsg_internal.h"
+
+#define RPM_TOC_SIZE 256
+#define RPM_TOC_MAGIC 0x67727430 /* grt0 */
+#define RPM_TOC_MAX_ENTRIES((RPM_TOC_SIZE - sizeof(struct rpm_toc)) / \
+sizeof(struct rpm_toc_entry))
+
+#define RPM_TX_FIFO_ID 0x61703272 /* ap2r */
+#define RPM_RX_FIFO_ID 0x72326170 /* r2ap */
+
+#define GLINK_NAME_SIZE32
+
+#define RPM_GLINK_CID_MIN 1
+#define RPM_GLINK_CID_MAX 65536
+
+struct rpm_toc_entry {
+ __le32 id;
+ __le32 offset;
+ __le32 size;
+} __packed;
+
+struct rpm_toc {
+ __le32 magic;
+ __le32 count;
+
+ struct rpm_toc_entry entries[];
+} __packed;
+
+struct glink_msg {
+ __le16 cmd;
+ __le16 param1;
+ __le32 param2;
+ u8 data[];
+} __packed;
+
+struct glink_rpm_pipe {
+ void __iomem *tail;
+ void __iomem *head;
+
+ void __iomem *fifo;
+
+ size_t length;
+};
+
+/**
+ * struct glink_defer_cmd - deferred incoming control message
+ * @node: list node
+ * @msg: message header
+ * data: payload of the message
+ *
+ * Copy of a received control message, to be added to @rx_queue and processed
+ * by @rx_work of @glink_rpm.
+ */
+struct glink_defer_cmd {
+ struct list_head node;
+
+ struct glink_msg msg;
+ u8 data[];
+};
+
+/**
+ * struct glink_rpm - driver context, relates to one remote subsystem
+ * @dev: reference to the associated struct device
+ * @doorbell: "rpm_hlos" ipc doorbell
+ * @rx_pipe: pipe object for receive FIFO
+ * @tx_pipe: pipe object for transmit FIFO
+ * @irq: IRQ for signaling incoming events
+ * @rx_work: worker for handling received control messages
+ * @rx_lock: protects the @rx_queue
+ * @rx_queue: queue of received control messages to be processed in @rx_work
+ * @tx_lock: synchronizes operations on the tx fifo
+ * @idr_lock: synchronizes @lcids and @rcids modifications
+ * @lcids: idr of all channels with a known local channel id
+ * @rcids: idr of all channels with a known remote channel id
+ */
+struct glink_rpm {
+ struct device *dev;
+
+ struct qcom_apcs_ipc_bell *doorbell;
+
+ struct glink_rpm_pipe rx_pipe;
+ struct glink_rpm_pipe tx_pi
[PATCH v3 2/4] soc: qcom: Introduce APCS IPC driver
This implements a driver that exposes the IPC bits found in the APCS
Global block in various Qualcomm platforms. The bits are used to signal
inter-processor communication signals from the application CPU to other
masters.
The driver implements the "doorbell" binding and could be used as basis
for a new Linux framework, if found useful outside Qualcomm.
Signed-off-by: Bjorn Andersson
---
Changes since v2:
- New driver
drivers/soc/qcom/Kconfig | 8 ++
drivers/soc/qcom/Makefile | 1 +
drivers/soc/qcom/apcs-ipc.c | 182 ++
include/linux/soc/qcom/apcs_ipc.h | 26 ++
4 files changed, 217 insertions(+)
create mode 100644 drivers/soc/qcom/apcs-ipc.c
create mode 100644 include/linux/soc/qcom/apcs_ipc.h
diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index 78b1bb7bcf20..4113da81d18b 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -1,6 +1,14 @@
#
# QCOM Soc drivers
#
+config QCOM_APCS_IPC
+ tristate "Qualcomm APCS IPC driver"
+ depends on ARCH_QCOM
+ help
+ Say y here to enable support for the APCS IPC doorbell driver,
+ providing an interface for invoking the inter-process communication
+ signals from the application processor to other masters.
+
config QCOM_GSBI
tristate "QCOM General Serial Bus Interface"
depends on ARCH_QCOM
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index 1f30260b06b8..e15b33e5a630 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -1,3 +1,4 @@
+obj-$(CONFIG_QCOM_APCS_IPC) += apcs-ipc.o
obj-$(CONFIG_QCOM_GSBI)+= qcom_gsbi.o
obj-$(CONFIG_QCOM_MDT_LOADER) += mdt_loader.o
obj-$(CONFIG_QCOM_PM) += spm.o
diff --git a/drivers/soc/qcom/apcs-ipc.c b/drivers/soc/qcom/apcs-ipc.c
new file mode 100644
index ..ea835cb08657
--- /dev/null
+++ b/drivers/soc/qcom/apcs-ipc.c
@@ -0,0 +1,182 @@
+/*
+ * Copyright (c) 2017, Linaro Ltd
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static struct platform_driver qcom_apcs_ipc_driver;
+
+struct qcom_apcs_ipc {
+ struct device *dev;
+
+ void __iomem *base;
+ unsigned long offset;
+};
+
+struct qcom_apcs_ipc_bell {
+ struct qcom_apcs_ipc *apcs;
+ unsigned int bit;
+};
+
+static void qcom_apcs_ipc_release(struct device *dev, void *res)
+{
+ struct qcom_apcs_ipc_bell *bell = res;
+ struct qcom_apcs_ipc *apcs = bell->apcs;
+
+ put_device(apcs->dev);
+}
+
+/**
+ * qcom_apcs_ipc_get() - acquire a handle to a doorbell
+ * @dev: client device handle
+ * @id:identifier of the doorbell
+ *
+ * Returns a doorbell reference, or negative errno on failure.
+ */
+struct qcom_apcs_ipc_bell *devm_qcom_apcs_ipc_get(struct device *dev,
+ const char *id)
+{
+ struct qcom_apcs_ipc_bell *bell;
+ struct platform_device *pdev;
+ struct of_phandle_args args;
+ int index = 0;
+ int ret;
+
+ if (id) {
+ index = of_property_match_string(dev->of_node,
+"doorbell-names", id);
+ if (index < 0)
+ return ERR_PTR(index);
+ }
+
+ ret = of_parse_phandle_with_args(dev->of_node, "doorbells",
+"#doorbell-cells", index, &args);
+ if (ret) {
+ dev_err(dev, "unable to resolve doorbell\n");
+ return ERR_PTR(-ENODEV);
+ }
+
+ pdev = of_find_device_by_node(args.np);
+ of_node_put(args.np);
+
+ if (!pdev)
+ return ERR_PTR(-EPROBE_DEFER);
+
+ if (args.args[0] >= 32) {
+ dev_err(dev, "invalid doorbell requested\n");
+ ret = -EINVAL;
+ goto release_device;
+ }
+
+ if (pdev->dev.driver != &qcom_apcs_ipc_driver.driver) {
+ dev_err(dev, "failed to acquire apcs ipc driver\n");
+ ret = -EINVAL;
+ goto release_device;
+ }
+
+ bell = devres_alloc(qcom_apcs_ipc_release, sizeof(*bell), GFP_KERNEL);
+ if (!bell) {
+ ret = -ENOMEM;
+ goto release_device;
+ }
+
+ bell->apcs = platform_get_drvdata(pdev);
+ bell->bit = args.args[0];
+
+ devres_add(dev, bell);
+
+ return bell;
+
+release_device:
+ put_device(&pdev->dev);
+
+
[PATCH v3 1/4] dt-bindings: Introduce doorbell binding
Introduce the generic doorbell binding as well as a binding for the
Qualcomm APCS Global block. This is used to expose doorbell-like devices
in the system.
Signed-off-by: Bjorn Andersson
---
Changes since v2:
- New binding
.../devicetree/bindings/doorbell/doorbell.txt | 31 +++
.../bindings/doorbell/qcom,apcs-kpss-global.txt| 45 ++
2 files changed, 76 insertions(+)
create mode 100644 Documentation/devicetree/bindings/doorbell/doorbell.txt
create mode 100644
Documentation/devicetree/bindings/doorbell/qcom,apcs-kpss-global.txt
diff --git a/Documentation/devicetree/bindings/doorbell/doorbell.txt
b/Documentation/devicetree/bindings/doorbell/doorbell.txt
new file mode 100644
index ..8fd814898c3f
--- /dev/null
+++ b/Documentation/devicetree/bindings/doorbell/doorbell.txt
@@ -0,0 +1,31 @@
+Doorbell binding
+
+
+The doorbell binding is used to describe a set of doorbells for client blocks
+to ring.
+
+1) Doorbell controller
+--
+
+A doorbell controller is a device that exposes a number of doorbells, that can
+client devices can ring to signal some event to some piece of hardware.
+
+- #doorbell-cells:
+ Usage: required
+ Value type:
+ Definition: should be 0 for single-doorbell controllers and 1 for
+ multi-doorbell controllers
+
+2) Doorbell user
+
+
+- doorbells:
+ Usage: required
+ Value type:
+ Definition: list of doorbell references
+
+- doorbell-names:
+ Usage: optional
+ Value type:
+ Definition: list of strings identifying each entry in the doorbells
+ property
diff --git
a/Documentation/devicetree/bindings/doorbell/qcom,apcs-kpss-global.txt
b/Documentation/devicetree/bindings/doorbell/qcom,apcs-kpss-global.txt
new file mode 100644
index ..6320e1a355cb
--- /dev/null
+++ b/Documentation/devicetree/bindings/doorbell/qcom,apcs-kpss-global.txt
@@ -0,0 +1,45 @@
+Binding for the Qualcomm APCS global block
+==
+
+This binding describes the APCS "global" block found in various Qualcomm
+platforms.
+
+- compatible:
+ Usage: required
+ Value type:
+ Definition: must be one of:
+ "qcom,msm8916-apcs-kpss-global",
+ "qcom,msm8996-apcs-hmss-global"
+
+- reg:
+ Usage: required
+ Value type:
+ Definition: must specify the base address and size of the global block
+
+- #doorbell-cells:
+ Usage: required
+ Value type:
+ Definition: as described in doorbell.txt, must be 1
+
+
+= EXAMPLE
+The following example describes the APCS HMSS found in MSM8996 and part of the
+GLINK RPM referencing the "rpm_hlos" doorbell therein.
+
+ apcs_glb: apcs-glb@982 {
+ compatible = "qcom,msm8996-apcs-hmss-global";
+ reg = <0x982 0x1000>;
+
+ #doorbell-cells = <1>;
+ };
+
+rpm-glink {
+compatible = "qcom,glink-rpm";
+
+interrupts = ;
+
+qcom,rpm-msg-ram = <&rpm_msg_ram>;
+
+ doorbells = <&apcs_glb 0>;
+ };
+
--
2.12.0
Re: [PATCH] ia64: beatify build log for gate.so and gate-syms.o
2017-04-12 8:36 GMT+09:00 Masahiro Yamada : > Currently, the object path is not aligned in the build log: > > LDS arch/ia64/kernel/gate.lds > AS arch/ia64/kernel/gate.o > GATE arch/ia64/kernel/gate.so > AS arch/ia64/kernel/gate-data.o > > Signed-off-by: Masahiro Yamada > --- > > arch/ia64/kernel/Makefile.gate | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/ia64/kernel/Makefile.gate b/arch/ia64/kernel/Makefile.gate > index ceeffc5..a32903a 100644 > --- a/arch/ia64/kernel/Makefile.gate > +++ b/arch/ia64/kernel/Makefile.gate > @@ -6,7 +6,7 @@ extra-y += gate.so gate-syms.o gate.lds gate.o > > CPPFLAGS_gate.lds := -P -C -U$(ARCH) > > -quiet_cmd_gate = GATE $@ > +quiet_cmd_gate = GATE$@ >cmd_gate = $(CC) -nostdlib $(GATECFLAGS_$(@F)) -Wl,-T,$(filter-out > FORCE,$^) -o $@ > > GATECFLAGS_gate.so = -shared -s -Wl,-soname=linux-gate.so.1 \ > -- > 2.7.4 > I got no response from the ia64 maintainers, but this patch is trivial enough to be applied to kbuild tree. Applied to linux-kbuild/kbuild. -- Best Regards Masahiro Yamada
Re: [PATCH 0/3] alpha: improvements of arch/alpha/lib/Makefile
2016-09-11 16:42 GMT+09:00 Masahiro Yamada : > While building for Alpha architecture, I noticed ugly long log > for division routines. So, I took a look at the Makefile. > Here is a series of build rule cleanups. > > > Masahiro Yamada (3): > alpha: add $(src)/ rather than $(obj)/ to make source file path > alpha: merge build rules of division routines > alpha: make short build log available for division routines > > arch/alpha/lib/Makefile | 11 +++ > 1 file changed, 3 insertions(+), 8 deletions(-) > No response for a long time (probably because the maintainer status is Odd Fixes.) Applied to linux-kbuild. -- Best Regards Masahiro Yamada
Re: [PATCH] hexagon: Use raw_copy_to_user
On Tue, May 02, 2017 at 08:52:48PM -0700, Guenter Roeck wrote:
> Commit ac4691fac8ad ("hexagon: switch to RAW_COPY_USER") replaced
> __copy_to_user_hexagon() with raw_copy_to_user(), but did not catch
> all callers, resulting in the following build error.
>
> arch/hexagon/mm/uaccess.c: In function '__clear_user_hexagon':
> arch/hexagon/mm/uaccess.c:40:3: error:
> implicit declaration of function '__copy_to_user_hexagon'
>
> Fixes: ac4691fac8ad ("hexagon: switch to RAW_COPY_USER")
> Cc: Al Viro
> Signed-off-by: Guenter Roeck
Acked-by: Al Viro
Re: [PATCH v6 0/4] Broadcom SBA RAID support
On Wed, May 3, 2017 at 10:29 AM, Vinod Koul wrote: > On Wed, May 03, 2017 at 09:15:20AM +0530, Anup Patel wrote: >> Hi Vinod, >> >> The Broadcom FlexRM patchset have been >> merged in v4.11. >> >> I think you now can take this patchset in next >> merge window. Right?? > > Sure, please rebase and resend after -rc1 is out Sure, I will do that. Regards, Anup
Re: [PATCH 3/3] PCI/of fix of_dma_get_range; get PCI specific dma-ranges
I will send v2 after removing GERRIT details from commit message. My apologies for the noise. Regards, Oza
Re: [PATCH 1/3] of/pci/dma: fix DMA configuration for PCI masters
I will send v2 after removing GERRIT details from commit message. My apologies for the noise. Regards, Oza
Re: [PATCH 2/3] iommu/pci: reserve iova for PCI masters
I will send v2 after removing GERRIT details from commit message. My apologies for the noise. Regards, Oza
Re: [PATCH v6 0/4] Broadcom SBA RAID support
On Wed, May 03, 2017 at 09:15:20AM +0530, Anup Patel wrote: > Hi Vinod, > > The Broadcom FlexRM patchset have been > merged in v4.11. > > I think you now can take this patchset in next > merge window. Right?? Sure, please rebase and resend after -rc1 is out -- ~Vinod
Re: I'd like to donate a MacBook Pro
2017-05-01 3:03 GMT-06:00 Lukas Wunner : > On Mon, 1 May 2017 00:27:41 -0600, Alex Henrie wrote: >> I am confident that this is a common problem because I have found >> various other users complaining about it: >> >> https://bbs.archlinux.org/viewtopic.php?pid=1613363#p1613363 >> https://bbs.archlinux.org/viewtopic.php?pid=1451053#p1451053 >> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1668105 >> https://bugzilla.kernel.org/show_bug.cgi?id=115741 > > Briefly looking over those links I notice some people are reporting > the same issue on macOS. This could indicate an EFI firmware bug > or hardware issue. Have you tried updating the firmware? Has this > issue always been present? Everything worked fine when I first installed Linux last October. I updated the firmware immediately before installing Linux. I think it was a couple of months before the boot problems showed up. 2017-05-01 4:06 GMT-06:00 Greg KH : > You are not saying what kernel version you are using here, newer ones > have fixed issues like this. Have you tried 4.10? 4.11? I am currently using 4.10. I tried 4.11 yesterday and the keyboard did not work at all. The error messages changed to: [0.453518] ACPI Error: Needed type [Reference], found [Integer] 88045bce 3798 (20170119/exresop-103) [0.453525] ACPI Exception: AE_AML_OPERAND_TYPE, While resolving operands for [OpcodeName unavailable] (20170119/dswexec-461) [0.453530] ACPI Error: Method parse/execution failed [\_PR.CPU0._PDC] (Node 88045e0ee320), AE_AML_OPERAND_TYPE (20170119/psparse-543) starting version 232 A password is required to access the cryptroot volume: Enter passphrase for /dev/sda4: [7.950202] xhci_hcd :00:14.0: Command completion event does not match command [ 10.290329] usb 2-3: device not accepting address 2, error -62 [ 20.537740] xhci_hcd :00:14:0: Command completion event does not match command [ 35.045403] xhci_hcd :00:14.0: Error while assigning device slot ID [ 35.045659] xhci_hcd :00:14.0: Max number of devices this xHCI host supports is 32. [ 35.045934] usb usb2-port3: couldn't allocate usb_device [ 47.419601] usb 1-3: hub failed to enable device, error -62 [ 59.793777] xhci_hcd :00:14.0: Error while assigning device slot ID [ 59.794032] xhci_hcd :00:14.0: Max number of devices this xHCI host supports is 32. [ 59.794307] usb usb1-port3: couldn't allocate usb_device [ 72.167966] xhci_hcd :00:14.0: Error while assigning device slot ID [ 72.168218] xhci_hcd :00:14.0: Max number of devices this xHCI host supports is 32. [ 72.168493] usb usb1-port5: couldn't allocate usb_device Today I ran a regression test to determine which commit made the keyboard stop working entirely. The last commit that worked for me was c09e22d5370739e16463c113525df51b5980b1d5. After that, there is a long series of commits where the screen stays black, and after that, I start getting errors like the one above. Thanks for the information you've sent so far. Any ideas on how to fix this new and serious problem with 4.11? -Alex
Re: [RFC PATH] of/pci/dma: fix DMA configruation for PCI masters
On Mon, Apr 24, 2017 at 7:50 PM, Rob Herring wrote:
> On Sat, Apr 22, 2017 at 3:08 AM, Oza Pawandeep wrote:
>> current device frmework and of framework integration assumes dma-ranges
>> in a way where memory-mapped devices define their dma-ranges.
>> dma-ranges: (child-bus-address, parent-bus-address, length).
>>
>> but iproc based SOCs and other SOCs(suc as rcar) have PCI world dma-ranges.
>> dma-ranges = <0x4300 0x00 0x00 0x00 0x00 0x80 0x00>;
>>
>> of_dma_configure is specifically witten to take care of memory mapped
>> devices.
>> but no implementation exists for pci to take care of pcie based memory
>> ranges.
>> in fact pci world doesnt seem to define standard dma-ranges
>>
>> this patch served following purposes
>>
>> 1) exposes intrface to the pci host driver for thir inbound memory ranges
>>
>> 2) provide an interface to callers such as of_dma_get_ranges.
>> so then the returned size get best possible (largest) dma_mask.
>> for e.g.
>> dma-ranges = <0x4300 0x00 0x00 0x00 0x00 0x80 0x00>;
>> we should get dev->coherent_dma_mask=0x7f.
>>
>> 3) this patch handles multiple inbound windows and dma-ranges.
>> it is left to the caller, how it wants to use them.
>> the new function returns the resources in a standard and unform way
>>
>> 4) this way the callers of of_dma_get_ranges does not need to change.
>> and
>>
>> 5) leaves scope of adding PCI flag handling for inbound memory
>> by the new function.
>>
>> Signed-off-by: Oza Pawandeep
>>
>> diff --git a/drivers/of/address.c b/drivers/of/address.c
>> index 02b2903..ec21191 100644
>> --- a/drivers/of/address.c
>> +++ b/drivers/of/address.c
>> @@ -6,6 +6,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #include
>> @@ -829,10 +830,30 @@ int of_dma_get_range(struct device_node *np, u64
>> *dma_addr, u64 *paddr, u64 *siz
>> int len, naddr, nsize, pna;
>> int ret = 0;
>> u64 dmaaddr;
>> + struct resource_entry *window;
>> + LIST_HEAD(res);
>>
>> if (!node)
>> return -EINVAL;
>>
>> + if (strcmp(np->name, "pci")) {
>
> Using the name is not reliable though I did recently add a dtc check
> for this. Of course, 'pcie' is valid too (and probably should be used
> for what you are testing). type is what you want to use here. We
> already have bus matching function and bus specific handlers in
> address.c. Whatever solution you come up with should be integrated
> with the existing bus specific handlers.
>
> Rob
Hi Rob,
I have addressed your comments.
now I have pushed 3 patchsets, which completely solves the problem for our SOC.
[PATCH 1/3] of/pci/dma: fix DMA configuration for PCI masters.
Regards,
Oza.
Re: [PATCH] Makefile: evaluate LDFLAGS_BUILD_ID only once
2017-05-01 1:16 GMT+09:00 Rabin Vincent : > Evaluate LDFLAGS_BUILD_ID (which involves invoking the compiler) only > once instead of over and over. > > This provides a ~20% reduction in null build time with x86 allnoconfig: > > $ make allnoconfig && make -j8 > $ perf stat -r5 -e sched:sched_process_exec make -j8 > - 2 119 sched:sched_process_exec > + 1 878 sched:sched_process_exec > > - 1,238817018 seconds time elapsed > + 0,971020553 seconds time elapsed > > Signed-off-by: Rabin Vincent Applied to linux-kbuild/kbuild. Thanks! -- Best Regards Masahiro Yamada
Re: [PATCH] vmscan: scan pages until it founds eligible pages
On Tue, May 02, 2017 at 05:14:36PM +0200, Michal Hocko wrote: > On Tue 02-05-17 23:51:50, Minchan Kim wrote: > > Hi Michal, > > > > On Tue, May 02, 2017 at 09:54:32AM +0200, Michal Hocko wrote: > > > On Tue 02-05-17 14:14:52, Minchan Kim wrote: > > > > Oops, forgot to add lkml and linux-mm. > > > > Sorry for that. > > > > Send it again. > > > > > > > > >From 8ddf1c8aa15baf085bc6e8c62ce705459d57ea4c Mon Sep 17 00:00:00 2001 > > > > From: Minchan Kim > > > > Date: Tue, 2 May 2017 12:34:05 +0900 > > > > Subject: [PATCH] vmscan: scan pages until it founds eligible pages > > > > > > > > On Tue, May 02, 2017 at 01:40:38PM +0900, Minchan Kim wrote: > > > > There are premature OOM happening. Although there are a ton of free > > > > swap and anonymous LRU list of elgible zones, OOM happened. > > > > > > > > With investigation, skipping page of isolate_lru_pages makes reclaim > > > > void because it returns zero nr_taken easily so LRU shrinking is > > > > effectively nothing and just increases priority aggressively. > > > > Finally, OOM happens. > > > > > > I am not really sure I understand the problem you are facing. Could you > > > be more specific please? What is your configuration etc... > > > > Sure, KVM guest on x86_64, It has 2G memory and 1G swap and configured > > movablecore=1G to simulate highmem zone. > > Workload is a process consumes 2.2G memory and then random touch the > > address space so it makes lots of swap in/out. > > > > > > > > > balloon invoked oom-killer: > > > > gfp_mask=0x17080c0(GFP_KERNEL_ACCOUNT|__GFP_ZERO|__GFP_NOTRACK), > > > > nodemask=(null), order=0, oom_score_adj=0 > > > [...] > > > > Node 0 active_anon:1698864kB inactive_anon:261256kB active_file:208kB > > > > inactive_file:184kB unevictable:0kB isolated(anon):0kB > > > > isolated(file):0kB mapped:532kB dirty:108kB writeback:0kB shmem:172kB > > > > writeback_tmp:0kB unstable:0kB all_unreclaimable? no > > > > DMA free:7316kB min:32kB low:44kB high:56kB active_anon:8064kB > > > > inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB > > > > writepending:0kB present:15992kB managed:15908kB mlocked:0kB > > > > slab_reclaimable:464kB slab_unreclaimable:40kB kernel_stack:0kB > > > > pagetables:24kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB > > > > lowmem_reserve[]: 0 992 992 1952 > > > > DMA32 free:9088kB min:2048kB low:3064kB high:4080kB > > > > active_anon:952176kB inactive_anon:0kB active_file:36kB > > > > inactive_file:0kB unevictable:0kB writepending:88kB present:1032192kB > > > > managed:1019388kB mlocked:0kB slab_reclaimable:13532kB > > > > slab_unreclaimable:16460kB kernel_stack:3552kB pagetables:6672kB > > > > bounce:0kB free_pcp:56kB local_pcp:24kB free_cma:0kB > > > > lowmem_reserve[]: 0 0 0 959 > > > > > > Hmm DMA32 has sufficient free memory to allow this order-0 request. > > > Inactive anon lru is basically empty. Why do not we rotate a really > > > large active anon list? Isn't this the primary problem? > > > > It's a side effect by skipping page logic in isolate_lru_pages > > I mentioned above in changelog. > > > > The problem is a lot of anonymous memory in movable zone(ie, highmem) > > and non-small memory in DMA32 zone. > > Such a configuration is questionable on its own. But let't keep this > part alone. It seems you are misunderstood. It's really common on 32bit. Think of 2G DRAM system on 32bit. Normally, it's 1G normal:1G highmem. It's almost same with one I configured. > > > In heavy memory pressure, > > requesting a page in GFP_KERNEL triggers reclaim. VM knows inactive list > > is low so it tries to deactivate pages. For it, first of all, it tries > > to isolate pages from active list but there are lots of anonymous pages > > from movable zone so skipping logic in isolate_lru_pages works. With > > the result, isolate_lru_pages cannot isolate any eligible pages so > > reclaim trial is effectively void. It continues to meet OOM. > > But skipped pages should be rotated and we should eventually hit pages > from the right zone(s). Moreover we should scan the full LRU at priority > 0 so why exactly we hit the OOM killer? Yes, full scan in priority 0 but keep it in mind that the number of full LRU pages to scan is one of eligible pages, not all pages of the node. And isolate_lru_pages have accounted skipped pages as scan count so that VM cannot isolate any pages of eligible pages in LRU if non-eligible pages are a lot in the LRU. > > Anyway [1] has changed this behavior. Are you seeing the issue with this > patch dropped? Good point. Before the patch, it didn't increase scan count with skipped pages so with reverting [1], I guess it might work but worry about isolating lots of skipped pages into temporal pages_skipped list which might causes premate OOM. Anyway, I will test it when I returns at office after vacation. Thanks. > > [1] > http://www.ozlabs.org/~akpm/mmotm/broken-out/revert-mm-vmscan-account-for-skipped-pages-as-a-partial-scan.patch > -- > Mi
Re: [PATCH] xen: Move xen_have_vector_callback definition to enlighten.c
On 02/05/17 19:23, Boris Ostrovsky wrote:
> Commit 84d582d236dc ("xen: Revert commits da72ff5bfcb0 and
> 72a9b186292d") defined xen_have_vector_callback in enlighten_hvm.c.
> Since guest-type-neutral code refers to this variable this causes
> build failures when CONFIG_XEN_PVHVM is not defined.
>
> Moving xen_have_vector_callback definition to enlighten.c resolves
> this issue.
>
> Signed-off-by: Boris Ostrovsky
> Reported-by: Randy Dunlap
Pushed to xen/tip for-linus-4.12b
Thanks,
Juergen
[PATCH 2/3] iommu/pci: reserve iova for PCI masters
this patch reserves the iova for PCI masters.
ARM64 based SOCs may have scattered memory banks.
such as iproc based SOC has
<0x 0x8000 0x0 0x8000>, /* 2G @ 2G */
<0x0008 0x8000 0x3 0x8000>, /* 14G @ 34G */
<0x0090 0x 0x4 0x>, /* 16G @ 576G */
<0x00a0 0x 0x4 0x>; /* 16G @ 640G */
but incoming PCI transcation addressing capability is limited
by host bridge, for example if max incoming window capability
is 512 GB, then 0x0090 and 0x00a0 will fall beyond it.
to address this problem, iommu has to avoid allocating iovas which
are reserved. which inturn does not allocate iova if it falls into hole.
Bug: SOC-5216
Change-Id: Icbfc99a045d730be143fef427098c937b9d46353
Signed-off-by: Oza Pawandeep
Reviewed-on: http://gerrit-ccxsw.broadcom.net/40760
Reviewed-by: vpx_checkpatch status
Reviewed-by: CCXSW
Tested-by: vpx_autobuild status
Tested-by: vpx_smoketest status
Tested-by: CCXSW
Reviewed-by: Scott Branden
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 48d36ce..08764b0 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -171,8 +172,12 @@ static void iova_reserve_pci_windows(struct pci_dev *dev,
struct iova_domain *iovad)
{
struct pci_host_bridge *bridge = pci_find_host_bridge(dev->bus);
+ struct device_node *np = bridge->dev.parent->of_node;
struct resource_entry *window;
unsigned long lo, hi;
+ int ret;
+ dma_addr_t tmp_dma_addr = 0, dma_addr;
+ LIST_HEAD(res);
resource_list_for_each_entry(window, &bridge->windows) {
if (resource_type(window->res) != IORESOURCE_MEM &&
@@ -183,6 +188,36 @@ static void iova_reserve_pci_windows(struct pci_dev *dev,
hi = iova_pfn(iovad, window->res->end - window->offset);
reserve_iova(iovad, lo, hi);
}
+
+ /* PCI inbound memory reservation. */
+ ret = of_pci_get_dma_ranges(np, &res);
+ if (!ret) {
+ resource_list_for_each_entry(window, &res) {
+ struct resource *res_dma = window->res;
+
+ dma_addr = res_dma->start - window->offset;
+ if (tmp_dma_addr > dma_addr) {
+ pr_warn("PCI: failed to reserve iovas; ranges
should be sorted\n");
+ return;
+ }
+ if (tmp_dma_addr != dma_addr) {
+ lo = iova_pfn(iovad, tmp_dma_addr);
+ hi = iova_pfn(iovad, dma_addr - 1);
+ reserve_iova(iovad, lo, hi);
+ }
+ tmp_dma_addr = window->res->end - window->offset;
+ }
+ /*
+* the last dma-range should honour based on the
+* 32/64-bit dma addresses.
+*/
+ if (tmp_dma_addr < DMA_BIT_MASK(sizeof(dma_addr_t) * 8)) {
+ lo = iova_pfn(iovad, tmp_dma_addr);
+ hi = iova_pfn(iovad,
+ DMA_BIT_MASK(sizeof(dma_addr_t) * 8) - 1);
+ reserve_iova(iovad, lo, hi);
+ }
+ }
}
/**
--
1.9.1
[PATCH 3/3] PCI/of fix of_dma_get_range; get PCI specific dma-ranges
current device framework and of framework integration assumes
dma-ranges in a way where memory-mapped devices define their
dma-ranges. (child-bus-address, parent-bus-address, length).
of_dma_configure is specifically written to take care of memory
mapped devices. but no implementation exists for pci to take
care of pcie based memory ranges.
for e.g. iproc based SOCs and other SOCs(suc as rcar) have PCI
world dma-ranges.
dma-ranges = <0x4300 0x00 0x00 0x00 0x00 0x80 0x00>;
this patch fixes this patch fixes the bug in of_dma_get_range,
which with as is, parses the PCI memory ranges and return wrong
size as 0.
in order to get largest possible dma_mask. this patch also
retuns the largest possible size based on dma-ranges,
for e.g.
dma-ranges = <0x4300 0x00 0x00 0x00 0x00 0x80 0x00>;
we should get dev->coherent_dma_mask=0x7f.
based on which iova allocation space will honour PCI host
bridge limitations.
Bug: SOC-5216
Change-Id: I4c534bdd17e70c6b27327d39d1656e8ed0cf56d6
Signed-off-by: Oza Pawandeep
Reviewed-on: http://gerrit-ccxsw.broadcom.net/40762
Reviewed-by: vpx_checkpatch status
Reviewed-by: CCXSW
Reviewed-by: Scott Branden
Tested-by: vpx_autobuild status
Tested-by: vpx_smoketest status
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 02b2903..f7734fc 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -6,6 +6,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -830,6 +831,54 @@ int of_dma_get_range(struct device_node *np, u64
*dma_addr, u64 *paddr, u64 *siz
int ret = 0;
u64 dmaaddr;
+#ifdef CONFIG_PCI
+ struct resource_entry *window;
+ LIST_HEAD(res);
+
+ if (!node)
+ return -EINVAL;
+
+ if (of_bus_pci_match(np)) {
+ *size = 0;
+ /*
+* PCI dma-ranges is not mandatory property.
+* many devices do no need to have it, since
+* host bridge does not require inbound memory
+* configuration or rather have design limitations.
+* so we look for dma-ranges, if missing we
+* just return the caller full size, and also
+* no dma-ranges suggests that, host bridge allows
+* whatever comes in, so we set dma_addr to 0.
+*/
+ ret = of_pci_get_dma_ranges(np, &res);
+ if (!ret) {
+ resource_list_for_each_entry(window, &res) {
+ struct resource *res_dma = window->res;
+
+ if (*size < resource_size(res_dma)) {
+ *dma_addr = res_dma->start - window->offset;
+ *paddr = res_dma->start;
+ *size = resource_size(res_dma);
+ }
+ }
+ }
+ pci_free_resource_list(&res);
+
+ /* ignore the empty ranges. */
+ if (*size == 0) {
+ pr_debug("empty/zero size dma-ranges found for
node(%s)\n",
+ np->full_name);
+ *size = DMA_BIT_MASK(sizeof(dma_addr_t) * 8);
+ *dma_addr = *paddr = 0;
+ ret = 0;
+ }
+
+ pr_err("dma_addr(%llx) cpu_addr(%llx) size(%llx)\n",
+*dma_addr, *paddr, *size);
+ goto out;
+ }
+#endif
+
if (!node)
return -EINVAL;
--
1.9.1
[PATCH 1/3] of/pci/dma: fix DMA configuration for PCI masters
current device framework and of framework integration assumes
dma-ranges in a way where memory-mapped devices define their
dma-ranges. (child-bus-address, parent-bus-address, length).
of_dma_configure is specifically written to take care of memory
mapped devices. but no implementation exists for pci to take
care of pcie based memory ranges.
for e.g. iproc based SOCs and other SOCs(suc as rcar) have PCI
world dma-ranges.
dma-ranges = <0x4300 0x00 0x00 0x00 0x00 0x80 0x00>;
this patch serves following:
1) exposes interface to the pci host driver for their
inbound memory ranges
2) provide an interface to callers such as of_dma_get_ranges.
so then the returned size get best possible (largest) dma_mask.
because PCI RC drivers do not call APIs such as
dma_set_coherent_mask() and hence rather it shows its addressing
capabilities based on dma-ranges.
for e.g.
dma-ranges = <0x4300 0x00 0x00 0x00 0x00 0x80 0x00>;
we should get dev->coherent_dma_mask=0x7f.
3) this patch handles multiple inbound windows and dma-ranges.
it is left to the caller, how it wants to use them.
the new function returns the resources in a standard and unform way
4) this way the callers of for e.g. of_dma_get_ranges
does not need to change.
5) leaves scope of adding PCI flag handling for inbound memory
by the new function.
Bug: SOC-5216
Change-Id: Ie045386df91e1e0587846bb147ae40d96f6d7d2e
Signed-off-by: Oza Pawandeep
Reviewed-on: http://gerrit-ccxsw.broadcom.net/40428
Reviewed-by: vpx_checkpatch status
Reviewed-by: CCXSW
Reviewed-by: Ray Jui
Tested-by: vpx_autobuild status
Tested-by: vpx_smoketest status
Tested-by: CCXSW
Reviewed-by: Scott Branden
diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 0ee42c3..ed6e69a 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -283,6 +283,83 @@ int of_pci_get_host_bridge_resources(struct device_node
*dev,
return err;
}
EXPORT_SYMBOL_GPL(of_pci_get_host_bridge_resources);
+
+/**
+ * of_pci_get_dma_ranges - Parse PCI host bridge inbound resources from DT
+ * @np: device node of the host bridge having the dma-ranges property
+ * @resources: list where the range of resources will be added after DT parsing
+ *
+ * It is the caller's job to free the @resources list.
+ *
+ * This function will parse the "dma-ranges" property of a
+ * PCI host bridge device node and setup the resource mapping based
+ * on its content.
+ *
+ * It returns zero if the range parsing has been successful or a standard error
+ * value if it failed.
+ */
+
+int of_pci_get_dma_ranges(struct device_node *np, struct list_head *resources)
+{
+ struct device_node *node = of_node_get(np);
+ int rlen;
+ int ret = 0;
+ const int na = 3, ns = 2;
+ struct resource *res;
+ struct of_pci_range_parser parser;
+ struct of_pci_range range;
+
+ if (!node)
+ return -EINVAL;
+
+ parser.node = node;
+ parser.pna = of_n_addr_cells(node);
+ parser.np = parser.pna + na + ns;
+
+ parser.range = of_get_property(node, "dma-ranges", &rlen);
+
+ if (!parser.range) {
+ pr_debug("pcie device has no dma-ranges defined for node(%s)\n",
+ np->full_name);
+ ret = -EINVAL;
+ goto out;
+ }
+
+ parser.end = parser.range + rlen / sizeof(__be32);
+
+ for_each_of_pci_range(&parser, &range) {
+ /*
+* If we failed translation or got a zero-sized region
+* then skip this range
+*/
+ if (range.cpu_addr == OF_BAD_ADDR || range.size == 0)
+ continue;
+
+ res = kzalloc(sizeof(struct resource), GFP_KERNEL);
+ if (!res) {
+ ret = -ENOMEM;
+ goto parse_failed;
+ }
+
+ ret = of_pci_range_to_resource(&range, np, res);
+ if (ret) {
+ kfree(res);
+ continue;
+ }
+
+ pci_add_resource_offset(resources, res,
+ res->start - range.pci_addr);
+ }
+
+ return ret;
+
+parse_failed:
+ pci_free_resource_list(resources);
+out:
+ of_node_put(node);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(of_pci_get_dma_ranges);
#endif /* CONFIG_OF_ADDRESS */
#ifdef CONFIG_PCI_MSI
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index 0e0974e..617b90d 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -76,6 +76,7 @@ static inline void of_pci_check_probe_only(void) { }
int of_pci_get_host_bridge_resources(struct device_node *dev,
unsigned char busno, unsigned char bus_max,
struct list_head *resources, resource_size_t *io_base);
+int of_pci_get_dma_ranges(struct device_node *np, struct list_head *resources);
#else
static inline int of_pci_get_host_bridge_resource
Re: [PATCH 1/1] objtool: make it visible in make V=1 output
2017-04-22 0:16 GMT+09:00 Jiri Slaby : > It is currently impossible to see what is going on with objtool when > building, so call echo-cmd to see the actions: > gcc -Wp,-MD,arch/x86/entry/.entry_64.o.d -nostdinc -isystem ... > ./tools/objtool/objtool check "arch/x86/entry/entry_64.o"; > > Signed-off-by: Jiri Slaby > Cc: Masahiro Yamada > Cc: Michal Marek > Cc: linux-kbu...@vger.kernel.org > Cc: Josh Poimboeuf > --- Applied to linux-kbuild/kbuild. Thanks! -- Best Regards Masahiro Yamada
Re: [PATCH 1/2] kbuild: cleanup signing keys with mrproper
+CC David Woodhouse +CC David Howells 2017-04-15 6:54 GMT+09:00 Stephen Hemminger : > When 'make mrproper' is run it was supposed to remove the signing > keys in the certs directory, but only the filename is given > rather than the pathanme which is necessary to cause cleanup. > > Signed-off-by: Stephen Hemminger > --- > Makefile | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/Makefile b/Makefile > index efa267a92ba6..04ca211552f7 100644 > --- a/Makefile > +++ b/Makefile > @@ -1274,9 +1274,9 @@ MRPROPER_DIRS += include/config usr/include > include/generated \ > arch/*/include/generated .tmp_objdiff > MRPROPER_FILES += .config .config.old .version .old_version \ > Module.symvers tags TAGS cscope* GPATH GTAGS GRTAGS GSYMS \ > - signing_key.pem signing_key.priv signing_key.x509 \ > - x509.genkey extra_certificates signing_key.x509.keyid \ > - signing_key.x509.signer vmlinux-gdb.py > + certs/signing_key.pem certs/signing_key.priv > certs/signing_key.x509 \ > + certs/x509.genkey certs/extra_certificates > certs/signing_key.x509.keyid \ > + certs/signing_key.x509.signer vmlinux-gdb.py > The logic seems quite simple, but I am not quite sure which file is still valid? [1] signing_key.pem - OK, this should be certs/signing_key.pem and removed by 'make mrproper' [2] signing_key.priv - deprecated by commit fb1179499134 ? [3] signing_key.x509 - OK, this should be certs/signing_key.x509 and removed by 'make mrproper' [4] x509.genkey - this is an intermediate file for generating signing_key.pem, but unneeded for installing external modules. Does it make more sense to delete this by 'make clean'? [5] extra_certificates - I am not sure where this is generated, and used [6] siging_key.x509.keyid - same as [5] [7] signing_key.x509.signer - same as [5] -- Best Regards Masahiro Yamada
Re: [PATCH 2/2] kbuild: remove initramfs cpio with mrproper
Hi Stephen, 2017-04-15 6:54 GMT+09:00 Stephen Hemminger : > When 'make mrproper' is done, it should also remove the initramfs cpio > file. I ran into this while doing test build on one machine, followed > by make mrproper and rsync to a target machine. The build on the target > machine would succeed but be unbootable because of the bad initramfs. I think initramfs_data.cpio.* is unneeded for external modules. So, shouldn't it removed by 'make clean', instead of 'make mrproper'? > Signed-off-by: Stephen Hemminger > --- > Makefile | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/Makefile b/Makefile > index 04ca211552f7..954292695bf6 100644 > --- a/Makefile > +++ b/Makefile > @@ -1276,7 +1276,8 @@ MRPROPER_FILES += .config .config.old .version > .old_version \ > Module.symvers tags TAGS cscope* GPATH GTAGS GRTAGS GSYMS \ > certs/signing_key.pem certs/signing_key.priv > certs/signing_key.x509 \ > certs/x509.genkey certs/extra_certificates > certs/signing_key.x509.keyid \ > - certs/signing_key.x509.signer vmlinux-gdb.py > + certs/signing_key.x509.signer vmlinux-gdb.py \ > + usr/initramfs_data.cpio.gz > As you see usr/Makefile, datafile_y = initramfs_data.cpio$(suffix_y) The suffix could be .gz, .bz2, .xz, etc. Why only initramfs_data.cpio.gz? -- Best Regards Masahiro Yamada
Re: linux-next: manual merge of the net-next tree with Linus' tree
From: Stephen Rothwell
Date: Wed, 3 May 2017 11:07:03 +1000
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
> arch/avr32/include/uapi/asm/socket.h
>
> between commit:
>
> 26202873bb51 ("avr32: remove support for AVR32 architecture")
>
> from Linus' tree and commits:
>
> a2d133b1d465 ("sock: introduce SO_MEMINFO getsockopt")
> 6d4339028b35 ("net: Introduce SO_INCOMING_NAPI_ID"
> 5daab9db7b65 ("New getsockopt option to get socket cookie")
>
> from the net-next tree.
>
> I fixed it up (I removed the file) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging. You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.
Duly noted in the pull request I sent to Linus, and now that he took
net-next in it is resolved in his tree.
Thanks!
Re: [PATCH 2/7] perf config: Check list empty before showing configs
Hi Arnaldo, On 05/03/2017 12:12 AM, Arnaldo Carvalho de Melo wrote: Em Wed, Apr 26, 2017 at 09:21:03PM +0900, Taeung Song escreveu: If existent config files contains nothing, the sections list in config_set can be empty. So check not only NULL pointer of config_set but also the list in config_set. +++ b/tools/perf/builtin-config.c @@ -75,7 +75,7 @@ static int show_spec_config(struct perf_config_set *set, const char *var) struct perf_config_section *section; struct perf_config_item *item; - if (set == NULL) + if (set == NULL || list_empty(&set->sections)) return -1; But should we consider an error to have an empty config file? I don't think so :-\ - Arnaldo I think if we do, when a config file is not only not exist but also empty, user can see the error message (e.g. "Nothing configured, please check your ~/.perfconfig"). And IMHO, it seems better. But if you don't think so, I got it. Thanks, Taeung
[PATCH] drivers/crypto/ccp: return NULL instead of 0
This change is to handle sparse warning. Return type of function is a pointer to the structure and it returns 0. Instead it should return NULL. Signed-off-by: Pushkar Jambhlekar --- drivers/crypto/ccp/ccp-platform.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/crypto/ccp/ccp-platform.c b/drivers/crypto/ccp/ccp-platform.c index 351f28d8..e26969e 100644 --- a/drivers/crypto/ccp/ccp-platform.c +++ b/drivers/crypto/ccp/ccp-platform.c @@ -44,7 +44,7 @@ static struct ccp_vdata *ccp_get_of_version(struct platform_device *pdev) if (match && match->data) return (struct ccp_vdata *)match->data; #endif - return 0; + return NULL; } static struct ccp_vdata *ccp_get_acpi_version(struct platform_device *pdev) @@ -56,7 +56,7 @@ static struct ccp_vdata *ccp_get_acpi_version(struct platform_device *pdev) if (match && match->driver_data) return (struct ccp_vdata *)match->driver_data; #endif - return 0; + return NULL; } static int ccp_get_irq(struct ccp_device *ccp) -- 2.7.4
Re: [PATCH] xen: Move xen_have_vector_callback definition to enlighten.c
On 02/05/17 19:23, Boris Ostrovsky wrote:
> Commit 84d582d236dc ("xen: Revert commits da72ff5bfcb0 and
> 72a9b186292d") defined xen_have_vector_callback in enlighten_hvm.c.
> Since guest-type-neutral code refers to this variable this causes
> build failures when CONFIG_XEN_PVHVM is not defined.
>
> Moving xen_have_vector_callback definition to enlighten.c resolves
> this issue.
>
> Signed-off-by: Boris Ostrovsky
> Reported-by: Randy Dunlap
Reviewed-by: Juergen Gross
Thanks,
Juergen
[PATCH] hexagon: Use raw_copy_to_user
Commit ac4691fac8ad ("hexagon: switch to RAW_COPY_USER") replaced
__copy_to_user_hexagon() with raw_copy_to_user(), but did not catch
all callers, resulting in the following build error.
arch/hexagon/mm/uaccess.c: In function '__clear_user_hexagon':
arch/hexagon/mm/uaccess.c:40:3: error:
implicit declaration of function '__copy_to_user_hexagon'
Fixes: ac4691fac8ad ("hexagon: switch to RAW_COPY_USER")
Cc: Al Viro
Signed-off-by: Guenter Roeck
---
arch/hexagon/mm/uaccess.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/hexagon/mm/uaccess.c b/arch/hexagon/mm/uaccess.c
index ec90afdb3ad0..c599eb126c9e 100644
--- a/arch/hexagon/mm/uaccess.c
+++ b/arch/hexagon/mm/uaccess.c
@@ -37,15 +37,14 @@ __kernel_size_t __clear_user_hexagon(void __user *dest,
unsigned long count)
long uncleared;
while (count > PAGE_SIZE) {
- uncleared = __copy_to_user_hexagon(dest, &empty_zero_page,
- PAGE_SIZE);
+ uncleared = raw_copy_to_user(dest, &empty_zero_page, PAGE_SIZE);
if (uncleared)
return count - (PAGE_SIZE - uncleared);
count -= PAGE_SIZE;
dest += PAGE_SIZE;
}
if (count)
- count = __copy_to_user_hexagon(dest, &empty_zero_page, count);
+ count = raw_copy_to_user(dest, &empty_zero_page, count);
return count;
}
--
2.7.4
RE: [PATCH] ARM: imx_v6_v7_defconfig: Enable cpufreq governors
> -Original Message- > From: Leonard Crestez [mailto:leonard.cres...@nxp.com] > Sent: Tuesday, May 02, 2017 10:46 PM > To: Shawn Guo > Cc: Leonard Crestez; Sascha Hauer; Jagan Teki; Fabio Estevam; Dong Aisheng; > linux-arm-ker...@lists.infradead.org; linux...@vger.kernel.org; linux- > ker...@vger.kernel.org > Subject: [PATCH] ARM: imx_v6_v7_defconfig: Enable cpufreq governors > > Enable more common cpufreq governors in imx defconfig because this is very > useful for testing. In particular you can't use cpufreq-set -f $FREQ > without explicitly defining CONFIG_CPU_FREQ_GOV_USERSPACE=y. > > Signed-off-by: Leonard Crestez Well, I think we do need this. So: Acked-by: Dong Aisheng Regards Dong Aisheng > > --- > > It might make sense for all governors to be enabled by default from > drivers/cpufreq/Kconfig and allow defconfigs to be shorter. > Right now the descriptions for some of them includes a line that says "If > in doubt, say Y" but the config options don't have actually have a default > value defined and they effectively default to N. > > Cycling via savedefconfig on shawnguo/for-next also generates some > reordering for some newly added options CONFIG_TOUCHSCREEN_MAX11801=y and > CONFIG_HID_MULTITOUCH=y. Those were not included but it's strange that > this happens. Maybe those options were inserted manually, or otherwise > there is an annoying bug in kconfig? > > arch/arm/configs/imx_v6_v7_defconfig | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/arch/arm/configs/imx_v6_v7_defconfig > b/arch/arm/configs/imx_v6_v7_defconfig > index bb6fa56..bf1e7e3 100644 > --- a/arch/arm/configs/imx_v6_v7_defconfig > +++ b/arch/arm/configs/imx_v6_v7_defconfig > @@ -55,6 +55,9 @@ CONFIG_CMDLINE="noinitrd console=ttymxc0,115200" > CONFIG_KEXEC=y > CONFIG_CPU_FREQ=y > 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_ARM_IMX6Q_CPUFREQ=y > CONFIG_CPU_IDLE=y > CONFIG_VFP=y > -- > 2.7.4
Re: [PATCH v6 0/4] Broadcom SBA RAID support
Hi Vinod, The Broadcom FlexRM patchset have been merged in v4.11. I think you now can take this patchset in next merge window. Right?? Regards, Anup
Re: [PATCH] tcmu: Recalculate the tcmu_cmd size to save cmd area memories
On Tue, 2017-05-02 at 21:06 -0500, Mike Christie wrote: > On 05/02/2017 02:54 AM, lixi...@cmss.chinamobile.com wrote: > > From: Xiubo Li > > > > For the "struct tcmu_cmd_entry" in cmd area, the minimum size > > will be sizeof(struct tcmu_cmd_entry) == 112 Bytes. And it could > > fill about (sizeof(struct rsp) - sizeof(struct req)) / > > sizeof(struct iovec) == 68 / 16 ~= 4 data regions(iov[4]) by > > default. > > > > For most tcmu_cmds, the data block indexes allocated from the > > data area will be continuous. And for the continuous blocks they > > will be merged into the same region using only one iovec. For > > the current code, it will always allocates the same number of > > iovecs with blocks for each tcmu_cmd, and it will wastes much > > memories. > > > > For example, when the block size is 4K and the DATA_OUT buffer > > size is 64K, and the regions needed is less than 5(on my > > environment is almost 99.7%). The current code will allocate > > about 16 iovecs, and there will be (16 - 4) * sizeof(struct > > iovec) = 192 Bytes cmd area memories wasted. > > > > Here adds two helpers to calculate the base size and full size > > of the tcmu_cmd. And will recalculate them again when it make sure > > how many iovs is needed before insert it to cmd area. > > > > Signed-off-by: Xiubo Li > > Looks ok to me. Thanks. > > Acked-by: Mike Christie Applied. Thanks Xiubo + MNC.
Re: [PATCH] x86/intel_rdt: Fix two typos in Documentation
Sorry, please ignore this patch.
The first typo in this patch has been already fixed by:
a9cad3d4f046 ("Documentation, x86: Intel Memory bandwidth allocation")
A new patch is submitted to address the other typo left over:
https://lkml.org/lkml/2017/5/2/595
Best regards
Xiaochen Shen
On 2017/4/7 1:09, Xiaochen Shen wrote:
> Both typos are in example 3.
>
> Because cache id 0 is the only cache id, the ";" is redundant in
> "# echo "L3:0=ffc00;" > p0/schemata".
>
> And "C0" in "# echo C0 > p0/cpus" is wrong because it specifies core
> 6-7 instead of wanted core 4-7.
>
> Correct the typos to avoid confusion.
>
> Signed-off-by: Xiaochen Shen
> Signed-off-by: Fenghua Yu
> ---
> Documentation/x86/intel_rdt_ui.txt | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/x86/intel_rdt_ui.txt
> b/Documentation/x86/intel_rdt_ui.txt
> index 51cf6fa..cd752c1 100644
> --- a/Documentation/x86/intel_rdt_ui.txt
> +++ b/Documentation/x86/intel_rdt_ui.txt
> @@ -206,12 +206,12 @@ Next we make a resource group for our real time cores
> and give
> it access to the "top" 50% of the cache on socket 0.
>
> # mkdir p0
> -# echo "L3:0=ffc00;" > p0/schemata
> +# echo "L3:0=ffc00" > p0/schemata
>
> Finally we move core 4-7 over to the new group and make sure that the
> kernel and the tasks running there get 50% of the cache.
>
> -# echo C0 > p0/cpus
> +# echo F0 > p0/cpus
>
> 4) Locking between applications
>
[PATCH] staging: unisys: Solve sparse warning
The following commit fixes the following sparse report: drivers/staging//unisys/visorhba/visorhba_main.c:660:29: warning: cast to restricted __le64 by casting readq (which is unsigned long on x86) to u64, as expected by the seq_printf call. Signed-off-by: Marcos Paulo de Souza --- Just compiled tested on x86_64. drivers/staging/unisys/visorhba/visorhba_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/unisys/visorhba/visorhba_main.c b/drivers/staging/unisys/visorhba/visorhba_main.c index 6997b16..46d33e6 100644 --- a/drivers/staging/unisys/visorhba/visorhba_main.c +++ b/drivers/staging/unisys/visorhba/visorhba_main.c @@ -657,7 +657,7 @@ static int info_debugfs_show(struct seq_file *seq, void *v) seq_printf(seq, "phys_flags_addr = 0x%016llx\n", phys_flags_addr); seq_printf(seq, "FeatureFlags = %llu\n", - (__le64)readq(devdata->flags_addr)); + (u64)readq(devdata->flags_addr)); } seq_printf(seq, "acquire_failed_cnt = %llu\n", devdata->acquire_failed_cnt); -- 2.9.3
Re: [PATCH 6/15] dt-bindings: display: sun4i: Add HDMI display bindings
On Tue, Mar 7, 2017 at 4:56 PM, Maxime Ripard wrote: > One of the possible output of the display pipeline, on the SoCs that have > it, is the HDMI controller. > > Add a binding for it. > > Signed-off-by: Maxime Ripard > --- > Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 21 +++- > 1 file changed, 21 insertions(+), 0 deletions(-) > > diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > index b82c00449468..4b280672658e 100644 > --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > @@ -4,6 +4,27 @@ Allwinner A10 Display Pipeline > The Allwinner A10 Display pipeline is composed of several components > that are going to be documented below: > > +HDMI Encoder > + > + > +The HDMI Encoder supports the HDMI video and audio outputs, and does > +CEC. It is one end of the pipeline. > + > +Required properties: > + - compatible: value must be one of: > +* allwinner,sun5i-a10s-hdmi > + - reg: base address and size of memory-mapped region > + - clocks: phandles to the clocks feeding the HDMI encoder > +* ahb: the HDMI interface clock > +* mod: the HDMI module clock > +* pll-0: the first video PLL > +* pll-1: the second video PLL > + - clock-names: the clock names mentioned above The audio part needs a DMA handle. May we add this from day one? Thanks ChenYu > + > + - ports: A ports node with endpoint definitions as defined in > +Documentation/devicetree/bindings/media/video-interfaces.txt. The > +first port should be the input endpoint. > + > TV Encoder > -- > > -- > git-series 0.8.11
Re: [PATCH 03/13 V2] blk: make the bioset rescue_workqueue optional.
On Wed, May 3, 2017 at 6:34 AM, NeilBrown wrote: > From 09017acf74ec4df674b78ca66f0924187f10d8a4 Mon Sep 17 00:00:00 2001 > From: NeilBrown > Date: Fri, 10 Mar 2017 13:59:50 +1100 > Subject: [PATCH] blk: make the bioset rescue_workqueue optional. > > This patch converts bioset_create() to not create a workqueue by > default, so alloctions will never trigger punt_bios_to_rescuer(). It > also introduces a new flag BIOSET_NEED_RESCUER() which tells > bioset_create() to preserve the old behavior. > > All callers of bioset_create() that are inside block device drivers, > are given the BIOSET_NEED_RESCUER(). > > biosets used by filesystems or other top-level users do not > need rescuing as the bio can never be queued behind other > bios. This includes fs_bio_set, blkdev_dio_pool, > btrfs_bioset, xfs_ioend_bioset, and one allocated by > target_core_iblock.c. > > biosets used by md/raid do not need rescuing as > their usage was recently audited and revised to never > risk deadlock. > > It is hoped that most, if not all, of the remaining biosets > can end up being the non-rescued version. > > Reviewed-by: Christoph Hellwig > Credit-to: Ming Lei (minor fixes) > Signed-off-by: NeilBrown Reviewed-by: Ming Lei Thanks, Ming
[PATCH] powerpc/powernv: Fix TCE kill on NVLink2
Commit 616badd2fb49 ("powerpc/powernv: Use OPAL call for TCE kill on
NVLink2") forced all TCE kills to go via the OPAL call for
NVLink2. However the PHB3 implementation of TCE kill was still being
called directly from some functions which in some circumstances caused
a machine check.
This patch adds an equivalent IODA2 version of the function which uses
the correct invalidation method depending on PHB model and changes all
external callers to use it instead.
Fixes: 616badd2fb49 ("powerpc/powernv: Use OPAL call for TCE kill on NVLink2")
Signed-off-by: Alistair Popple
Cc: sta...@vger.kernel.org
---
arch/powerpc/platforms/powernv/npu-dma.c | 8
arch/powerpc/platforms/powernv/pci-ioda.c | 10 +-
arch/powerpc/platforms/powernv/pci.h | 2 +-
3 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/npu-dma.c
b/arch/powerpc/platforms/powernv/npu-dma.c
index 4c88c3e..067defe 100644
--- a/arch/powerpc/platforms/powernv/npu-dma.c
+++ b/arch/powerpc/platforms/powernv/npu-dma.c
@@ -203,7 +203,7 @@ long pnv_npu_set_window(struct pnv_ioda_pe *npe, int num,
pe_err(npe, "Failed to configure TCE table, err %lld\n", rc);
return rc;
}
- pnv_pci_phb3_tce_invalidate_entire(phb, false);
+ pnv_pci_ioda2_tce_invalidate_entire(phb, false);
/* Add the table to the list so its TCE cache will get invalidated */
pnv_pci_link_table_and_group(phb->hose->node, num,
@@ -227,7 +227,7 @@ long pnv_npu_unset_window(struct pnv_ioda_pe *npe, int num)
pe_err(npe, "Unmapping failed, ret = %lld\n", rc);
return rc;
}
- pnv_pci_phb3_tce_invalidate_entire(phb, false);
+ pnv_pci_ioda2_tce_invalidate_entire(phb, false);
pnv_pci_unlink_table_and_group(npe->table_group.tables[num],
&npe->table_group);
@@ -293,7 +293,7 @@ static int pnv_npu_dma_set_bypass(struct pnv_ioda_pe *npe)
0 /* bypass base */, top);
if (rc == OPAL_SUCCESS)
- pnv_pci_phb3_tce_invalidate_entire(phb, false);
+ pnv_pci_ioda2_tce_invalidate_entire(phb, false);
return rc;
}
@@ -357,7 +357,7 @@ void pnv_npu_take_ownership(struct pnv_ioda_pe *npe)
pe_err(npe, "Failed to disable bypass, err %lld\n", rc);
return;
}
- pnv_pci_phb3_tce_invalidate_entire(npe->phb, false);
+ pnv_pci_ioda2_tce_invalidate_entire(npe->phb, false);
}
struct pnv_ioda_pe *pnv_pci_npu_setup_iommu(struct pnv_ioda_pe *npe)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index 93ce3f9..dfbc94a 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -1895,7 +1895,7 @@ static struct iommu_table_ops pnv_ioda1_iommu_ops = {
#define PHB3_TCE_KILL_INVAL_PE PPC_BIT(1)
#define PHB3_TCE_KILL_INVAL_ONEPPC_BIT(2)
-void pnv_pci_phb3_tce_invalidate_entire(struct pnv_phb *phb, bool rm)
+static void pnv_pci_phb3_tce_invalidate_entire(struct pnv_phb *phb, bool rm)
{
__be64 __iomem *invalidate = pnv_ioda_get_inval_reg(phb, rm);
const unsigned long val = PHB3_TCE_KILL_INVAL_ALL;
@@ -1991,6 +1991,14 @@ static void pnv_pci_ioda2_tce_invalidate(struct
iommu_table *tbl,
}
}
+void pnv_pci_ioda2_tce_invalidate_entire(struct pnv_phb *phb, bool rm)
+{
+ if (phb->model == PNV_PHB_MODEL_NPU || phb->model == PNV_PHB_MODEL_PHB3)
+ pnv_pci_phb3_tce_invalidate_entire(phb, rm);
+ else
+ opal_pci_tce_kill(phb->opal_id, OPAL_PCI_TCE_KILL, 0, 0, 0, 0);
+}
+
static int pnv_ioda2_tce_build(struct iommu_table *tbl, long index,
long npages, unsigned long uaddr,
enum dma_data_direction direction,
diff --git a/arch/powerpc/platforms/powernv/pci.h
b/arch/powerpc/platforms/powernv/pci.h
index 4eab713..18c8a2f 100644
--- a/arch/powerpc/platforms/powernv/pci.h
+++ b/arch/powerpc/platforms/powernv/pci.h
@@ -242,7 +242,7 @@ extern void pe_level_printk(const struct pnv_ioda_pe *pe,
const char *level,
/* Nvlink functions */
extern void pnv_npu_try_dma_set_bypass(struct pci_dev *gpdev, bool bypass);
-extern void pnv_pci_phb3_tce_invalidate_entire(struct pnv_phb *phb, bool rm);
+extern void pnv_pci_ioda2_tce_invalidate_entire(struct pnv_phb *phb, bool rm);
extern struct pnv_ioda_pe *pnv_pci_npu_setup_iommu(struct pnv_ioda_pe *npe);
extern long pnv_npu_set_window(struct pnv_ioda_pe *npe, int num,
struct iommu_table *tbl);
--
2.1.4
[PATCH v2 6/8] ARM: sun8i: a83t: Add CCU device nodes
Now that we have support for the A83T CCU, add a device node for it,
and replace any existing placeholder clock phandles with the correct
ones.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun8i-a83t.dtsi | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi
b/arch/arm/boot/dts/sun8i-a83t.dtsi
index c0a1e4f74b89..c9a5d07b2ada 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -162,13 +162,23 @@
#size-cells = <1>;
ranges;
+ ccu: clock@1c2 {
+ compatible = "allwinner,sun8i-a83t-ccu";
+ reg = <0x01c2 0x400>;
+ clocks = <&osc24M>, <&osc16Md512>;
+ clock-names = "hosc", "losc";
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
pio: pinctrl@1c20800 {
compatible = "allwinner,sun8i-a83t-pinctrl";
interrupts = ,
,
;
reg = <0x01c20800 0x400>;
- clocks = <&osc24M>;
+ clocks = <&ccu 45>, <&osc24M>, <&osc16Md512>;
+ clock-names = "apb", "hosc", "losc";
gpio-controller;
interrupt-controller;
#interrupt-cells = <3>;
@@ -214,7 +224,8 @@
interrupts = ;
reg-shift = <2>;
reg-io-width = <4>;
- clocks = <&osc24M>;
+ clocks = <&ccu 53>;
+ resets = <&ccu 40>;
status = "disabled";
};
--
2.11.0
[PATCH v2 1/8] dt-bindings: clock: sunxi-ccu: Add compatible string for A83T CCU
The A83T clock control unit is a hybrid of some new style clock designs from the A80, and old style layout from the other Allwinner SoCs. Like the A80, the SoC does not have a low speed 32.768 kHz oscillator. Unlike the A80, there is no clock input either. The only low speed clock available is the internal oscillator which runs at around 16 MHz, divided by 512, yielding a low speed clock around 31.250 kHz. Signed-off-by: Chen-Yu Tsai --- Documentation/devicetree/bindings/clock/sunxi-ccu.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/clock/sunxi-ccu.txt b/Documentation/devicetree/bindings/clock/sunxi-ccu.txt index e9c5a1d9834a..34b2a9249a94 100644 --- a/Documentation/devicetree/bindings/clock/sunxi-ccu.txt +++ b/Documentation/devicetree/bindings/clock/sunxi-ccu.txt @@ -6,6 +6,7 @@ Required properties : - "allwinner,sun6i-a31-ccu" - "allwinner,sun8i-a23-ccu" - "allwinner,sun8i-a33-ccu" + - "allwinner,sun8i-a83t-ccu" - "allwinner,sun8i-h3-ccu" - "allwinner,sun8i-h3-r-ccu" - "allwinner,sun8i-v3s-ccu" @@ -18,6 +19,7 @@ Required properties : - clocks: phandle to the oscillators feeding the CCU. Two are needed: - "hosc": the high frequency oscillator (usually at 24MHz) - "losc": the low frequency oscillator (usually at 32kHz) + On the A83T, this is the internal 16MHz oscillator divided by 512 - clock-names: Must contain the clock names described just above - #clock-cells : must contain 1 - #reset-cells : must contain 1 -- 2.11.0
Re: [PATCH 0/6] mailbox: arm_mhu: add support for subchannels
Hi Sudeep, On Tue, May 2, 2017 at 7:25 PM, Sudeep Holla wrote: > Hi Jassi, > > This series adds subchannel support to ARM MHU mailbox controller > driver. Since SCPI never used second slot, we were able to use the > existing driver as is. However, that's changing soon and the new > SCMI protocol under development needs subchannel support. If you > recall when you initially added this driver, I was pushing for some > of these changes like threaded irq. This patch series adds support > for the subchannels on ARM MHU controllers. > There are really no "sub-channels" in the ARM MHU controller. There are exactly three channels that work on 32bit registers. The SET/CLEAR registers are there to prevent races between local and remote firmware, and not to emulate virtual channels operating on single bits. Please remember all 32-bits work together to generate one signal. You arrived at the "sub-channel" idea only because your protocol uses 1-bit messages. This patchset seems rather regressive - reduce from 2^32 possible signals to mere 32, by bloating the MHU driver. If it's difficult to see how your protocol can be implemented over existing controller driver, please let me know. Thanks.
[PATCH v2 8/8] ARM: sun8i: a83t: Switch to CCU device tree binding macros
Now that the CCU device tree binding headers have been merged, we can
use the properly named macros in the device tree, instead of raw
numbers.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun8i-a83t.dtsi | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi
b/arch/arm/boot/dts/sun8i-a83t.dtsi
index e12dd7170b8f..050d3e347740 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -44,6 +44,9 @@
#include
+#include
+#include
+
/ {
interrupt-parent = <&gic>;
#address-cells = <1>;
@@ -178,7 +181,7 @@
,
;
reg = <0x01c20800 0x400>;
- clocks = <&ccu 45>, <&osc24M>, <&osc16Md512>;
+ clocks = <&ccu CLK_BUS_PIO>, <&osc24M>, <&osc16Md512>;
clock-names = "apb", "hosc", "losc";
gpio-controller;
interrupt-controller;
@@ -225,8 +228,8 @@
interrupts = ;
reg-shift = <2>;
reg-io-width = <4>;
- clocks = <&ccu 53>;
- resets = <&ccu 40>;
+ clocks = <&ccu CLK_BUS_UART0>;
+ resets = <&ccu RST_BUS_UART0>;
status = "disabled";
};
--
2.11.0
[PATCH v2 7/8] ARM: sun8i: a83t: Set clock accuracy for 24MHz oscillator
The datasheets for Allwinner SoCs set strict requirements on the stability of the external crystal oscillators. Add the accuracy for the main 24MHz oscillator to the device tree. Signed-off-by: Chen-Yu Tsai --- arch/arm/boot/dts/sun8i-a83t.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi b/arch/arm/boot/dts/sun8i-a83t.dtsi index c9a5d07b2ada..e12dd7170b8f 100644 --- a/arch/arm/boot/dts/sun8i-a83t.dtsi +++ b/arch/arm/boot/dts/sun8i-a83t.dtsi @@ -126,6 +126,7 @@ #clock-cells = <0>; compatible = "fixed-clock"; clock-frequency = <2400>; + clock-accuracy = <5>; clock-output-names = "osc24M"; }; -- 2.11.0
[PATCH v2 5/8] clk: sunxi-ng: Add driver for A83T CCU
The A83T clock control unit is a hybrid of some new style clock designs
from the A80, and old style layout from the other Allwinner SoCs.
Like the A80, the SoC does not have a low speed 32.768 kHz oscillator.
Unlike the A80, there is no clock input either. The only low speed clock
available is the internal oscillator which runs at around 16 MHz,
divided by 512, yielding a low speed clock around 31.250 kHz.
Also, the MMC2 module clock supports switching to a "new timing" mode.
This mode divides the clock output by half, and disables the CCU based
clock delays. The MMC controller must be configure to the same mode,
and then use its internal clock delays.
This driver does not support runtime switching of the timing modes.
Instead, the new timing mode is enforced at probe time. Consumers can
check which mode is active by trying to get the current phase delay
of the MMC2 phase clocks, which will return -ENOTSUPP if the new
timing mode is active.
Signed-off-by: Chen-Yu Tsai
---
drivers/clk/sunxi-ng/Kconfig | 10 +
drivers/clk/sunxi-ng/Makefile | 1 +
drivers/clk/sunxi-ng/ccu-sun8i-a83t.c | 911 +
drivers/clk/sunxi-ng/ccu-sun8i-a83t.h | 64 ++
include/dt-bindings/clock/sun8i-a83t-ccu.h | 140 +
include/dt-bindings/reset/sun8i-a83t-ccu.h | 98
6 files changed, 1224 insertions(+)
create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-a83t.c
create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-a83t.h
create mode 100644 include/dt-bindings/clock/sun8i-a83t-ccu.h
create mode 100644 include/dt-bindings/reset/sun8i-a83t-ccu.h
diff --git a/drivers/clk/sunxi-ng/Kconfig b/drivers/clk/sunxi-ng/Kconfig
index 64088e599404..8bee22563909 100644
--- a/drivers/clk/sunxi-ng/Kconfig
+++ b/drivers/clk/sunxi-ng/Kconfig
@@ -116,6 +116,16 @@ config SUN8I_A33_CCU
default MACH_SUN8I
depends on MACH_SUN8I || COMPILE_TEST
+config SUN8I_A83T_CCU
+ bool "Support for the Allwinner A83T CCU"
+ select SUNXI_CCU_DIV
+ select SUNXI_CCU_GATE
+ select SUNXI_CCU_NKMP
+ select SUNXI_CCU_NM
+ select SUNXI_CCU_MP
+ select SUNXI_CCU_PHASE
+ default MACH_SUN8I
+
config SUN8I_H3_CCU
bool "Support for the Allwinner H3 CCU"
select SUNXI_CCU_DIV
diff --git a/drivers/clk/sunxi-ng/Makefile b/drivers/clk/sunxi-ng/Makefile
index 0ec02fe14c50..78028c8f5fa9 100644
--- a/drivers/clk/sunxi-ng/Makefile
+++ b/drivers/clk/sunxi-ng/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_SUN5I_CCU) += ccu-sun5i.o
obj-$(CONFIG_SUN6I_A31_CCU)+= ccu-sun6i-a31.o
obj-$(CONFIG_SUN8I_A23_CCU)+= ccu-sun8i-a23.o
obj-$(CONFIG_SUN8I_A33_CCU)+= ccu-sun8i-a33.o
+obj-$(CONFIG_SUN8I_A83T_CCU) += ccu-sun8i-a83t.o
obj-$(CONFIG_SUN8I_H3_CCU) += ccu-sun8i-h3.o
obj-$(CONFIG_SUN8I_V3S_CCU)+= ccu-sun8i-v3s.o
obj-$(CONFIG_SUN8I_R_CCU) += ccu-sun8i-r.o
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-a83t.c
b/drivers/clk/sunxi-ng/ccu-sun8i-a83t.c
new file mode 100644
index ..e32ef2cac568
--- /dev/null
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-a83t.c
@@ -0,0 +1,911 @@
+/*
+ * Copyright (c) 2017 Chen-Yu Tsai. All rights reserved.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+
+#include "ccu_common.h"
+#include "ccu_reset.h"
+
+#include "ccu_div.h"
+#include "ccu_gate.h"
+#include "ccu_mp.h"
+#include "ccu_nkmp.h"
+#include "ccu_nm.h"
+#include "ccu_phase.h"
+
+#include "ccu-sun8i-a83t.h"
+
+#define CCU_SUN8I_A83T_LOCK_REG0x208
+
+static struct clk_div_table pll_cpux_p_div_table[] = {
+ { .val = 0, .div = 1 },
+ { .val = 1, .div = 4 },
+ { /* Sentinel */ },
+};
+
+/*
+ * The CPU PLLs are actually NP clocks, but P is /1 or /4, so here we
+ * use the NM clocks with a divider table for M.
+ */
+static struct ccu_nm pll_c0cpux_clk = {
+ .enable = BIT(31),
+ .lock = BIT(0),
+ .n = _SUNXI_CCU_MULT_OFFSET_MIN_MAX(8, 8, 0, 12, 0),
+ .m = _SUNXI_CCU_DIV_TABLE(16, 1, pll_cpux_p_div_table),
+ .common = {
+ .reg= 0x000,
+ .lock_reg = CCU_SUN8I_A83T_LOCK_REG,
+ .features = CCU_FEATURE_LOCK_REG,
+ .hw.init= CLK_HW_INIT("pll-c0cpux", "osc24M",
+ &ccu_nm_ops, CLK_SET_RATE_UNGATE),
+ },
+};
+
+static struct ccu_nm pll_c1cpux_clk = {
+ .enable = BIT(31),
+ .lock = BIT(1),
+ .n
[PATCH v2 4/8] clk: sunxi-ng: Support multiple variable pre-dividers
On the A83T, the AHB1 clock has a shared pre-divider on the two
PLL-PERIPH clock parents. To support such instances of shared
pre-dividers, this patch extends the mux clock type to support
multiple variable pre-dividers.
As the pre-dividers are only used to calculate the rate, but
do not participate in the factorization process, this is fairly
straightforward.
Signed-off-by: Chen-Yu Tsai
---
drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 10 +-
drivers/clk/sunxi-ng/ccu-sun6i-a31.c | 10 +-
drivers/clk/sunxi-ng/ccu-sun8i-a23.c | 10 +-
drivers/clk/sunxi-ng/ccu-sun8i-a33.c | 10 +-
drivers/clk/sunxi-ng/ccu-sun8i-h3.c | 10 +-
drivers/clk/sunxi-ng/ccu-sun8i-r.c| 10 +-
drivers/clk/sunxi-ng/ccu-sun8i-v3s.c | 10 +-
drivers/clk/sunxi-ng/ccu_mux.c| 15 ---
drivers/clk/sunxi-ng/ccu_mux.h| 13 -
9 files changed, 51 insertions(+), 47 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
index f54114c607df..2bb4cabf802f 100644
--- a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
+++ b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
@@ -211,6 +211,9 @@ static SUNXI_CCU_M(axi_clk, "axi", "cpux", 0x050, 0, 2, 0);
static const char * const ahb1_parents[] = { "osc32k", "osc24M",
"axi", "pll-periph0" };
+static const struct ccu_mux_var_prediv ahb1_predivs[] = {
+ { .index = 3, .shift = 6, .width = 2 },
+};
static struct ccu_div ahb1_clk = {
.div= _SUNXI_CCU_DIV_FLAGS(4, 2, CLK_DIVIDER_POWER_OF_TWO),
@@ -218,11 +221,8 @@ static struct ccu_div ahb1_clk = {
.shift = 12,
.width = 2,
- .variable_prediv= {
- .index = 3,
- .shift = 6,
- .width = 2,
- },
+ .var_predivs= ahb1_predivs,
+ .n_var_predivs = ARRAY_SIZE(ahb1_predivs),
},
.common = {
diff --git a/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
b/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
index 89e68d29bf45..bc9f2ca19233 100644
--- a/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
+++ b/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
@@ -195,6 +195,9 @@ static SUNXI_CCU_DIV_TABLE(axi_clk, "axi", "cpu",
static const char * const ahb1_parents[] = { "osc32k", "osc24M",
"axi", "pll-periph" };
+static const struct ccu_mux_var_prediv ahb1_predivs[] = {
+ { .index = 3, .shift = 6, .width = 2 },
+};
static struct ccu_div ahb1_clk = {
.div= _SUNXI_CCU_DIV_FLAGS(4, 2, CLK_DIVIDER_POWER_OF_TWO),
@@ -203,11 +206,8 @@ static struct ccu_div ahb1_clk = {
.shift = 12,
.width = 2,
- .variable_prediv= {
- .index = 3,
- .shift = 6,
- .width = 2,
- },
+ .var_predivs= ahb1_predivs,
+ .n_var_predivs = ARRAY_SIZE(ahb1_predivs),
},
.common = {
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-a23.c
b/drivers/clk/sunxi-ng/ccu-sun8i-a23.c
index 5c6d37bdf247..8a753ed0426d 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-a23.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-a23.c
@@ -169,6 +169,9 @@ static SUNXI_CCU_M(axi_clk, "axi", "cpux", 0x050, 0, 2, 0);
static const char * const ahb1_parents[] = { "osc32k", "osc24M",
"axi" , "pll-periph" };
+static const struct ccu_mux_var_prediv ahb1_predivs[] = {
+ { .index = 3, .shift = 6, .width = 2 },
+};
static struct ccu_div ahb1_clk = {
.div= _SUNXI_CCU_DIV_FLAGS(4, 2, CLK_DIVIDER_POWER_OF_TWO),
@@ -176,11 +179,8 @@ static struct ccu_div ahb1_clk = {
.shift = 12,
.width = 2,
- .variable_prediv= {
- .index = 3,
- .shift = 6,
- .width = 2,
- },
+ .var_predivs= ahb1_predivs,
+ .n_var_predivs = ARRAY_SIZE(ahb1_predivs),
},
.common = {
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-a33.c
b/drivers/clk/sunxi-ng/ccu-sun8i-a33.c
index 8d38e6510e29..10b38dc46f75 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-a33.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-a33.c
@@ -180,6 +180,9 @@ static SUNXI_CCU_M(axi_clk, "axi", "cpux", 0x050, 0, 2, 0);
static const char * const ahb1_parents[] = { "osc32k", "osc24M",
"axi" , "pll-periph" };
+static const struct ccu_mux_var_prediv ahb1_predivs[] = {
+ { .index = 3, .shift = 6, .width = 2 },
+};
static struct ccu_div ahb1_clk = {
.div= _SUNXI_CCU_DIV_FLAGS(4, 2, CLK_DIVIDER_POWER_OF_TWO),
@@ -187,11 +190,8 @@ static struct ccu_div ahb1_clk = {
.shift = 12
[PATCH v2 3/8] clk: sunxi-ng: Add class of phase clocks supporting MMC new timing modes
The MMC clocks on newer SoCs, such as the A83T and H3, support the
"new timing mode". Under this mode, the output of the clock is divided
by 2, and the clock delays no longer apply.
Due to how the clock tree is modeled and setup, we need to model
this function in two places, the master mmc clock and the two
child phase clocks. In the mmc clock, we can easily model the
mode bit as an extra variable post-divider. In the phase clocks,
we check the bit and return -ENOTSUPP if the bit is set, signaling
that the phase clocks are not to be used.
This patch introduces a class of phase clocks that checks the
timing mode bit.
Signed-off-by: Chen-Yu Tsai
---
drivers/clk/sunxi-ng/ccu_phase.c | 47
drivers/clk/sunxi-ng/ccu_phase.h | 16 ++
2 files changed, 63 insertions(+)
diff --git a/drivers/clk/sunxi-ng/ccu_phase.c b/drivers/clk/sunxi-ng/ccu_phase.c
index 400c58ad72fd..e6ff7551c855 100644
--- a/drivers/clk/sunxi-ng/ccu_phase.c
+++ b/drivers/clk/sunxi-ng/ccu_phase.c
@@ -8,6 +8,7 @@
* the License, or (at your option) any later version.
*/
+#include
#include
#include
@@ -124,3 +125,49 @@ const struct clk_ops ccu_phase_ops = {
.get_phase = ccu_phase_get_phase,
.set_phase = ccu_phase_set_phase,
};
+
+/*
+ * The MMC clocks on newer SoCs support the "new timing mode". Under
+ * this mode, the output of the clock is divided by 2, and the clock
+ * delays no longer apply.
+ *
+ * Due to how the clock tree is modeled and setup, we need to model
+ * this function in two places, the master mmc clock and the two
+ * child phase clocks. In the mmc clock, we can easily model the
+ * mode bit as an extra variable post-divider. In the phase clocks,
+ * we check the bit and return -ENOTSUPP if the bit is set, signaling
+ * that the phase clocks are not to be used.
+ *
+ * We do not support runtime configuration of the modes. Instead a
+ * mode is enforced at CCU probe time.
+ */
+#define CCU_MMC_NEW_TIMING_MODEBIT(30)
+
+static int ccu_phase_mmc_new_timing_get_phase(struct clk_hw *hw)
+{
+ struct ccu_phase *phase = hw_to_ccu_phase(hw);
+ u32 reg;
+
+ reg = readl(phase->common.base + phase->common.reg);
+ if (reg & CCU_MMC_NEW_TIMING_MODE)
+ return -ENOTSUPP;
+
+ return ccu_phase_get_phase(hw);
+}
+
+static int ccu_phase_mmc_new_timing_set_phase(struct clk_hw *hw, int degrees)
+{
+ struct ccu_phase *phase = hw_to_ccu_phase(hw);
+ u32 reg;
+
+ reg = readl(phase->common.base + phase->common.reg);
+ if (reg & CCU_MMC_NEW_TIMING_MODE)
+ return -ENOTSUPP;
+
+ return ccu_phase_set_phase(hw, degrees);
+}
+
+const struct clk_ops ccu_phase_mmc_new_timing_ops = {
+ .get_phase = ccu_phase_mmc_new_timing_get_phase,
+ .set_phase = ccu_phase_mmc_new_timing_set_phase,
+};
diff --git a/drivers/clk/sunxi-ng/ccu_phase.h b/drivers/clk/sunxi-ng/ccu_phase.h
index 75a091a4c565..c514d1798cdd 100644
--- a/drivers/clk/sunxi-ng/ccu_phase.h
+++ b/drivers/clk/sunxi-ng/ccu_phase.h
@@ -38,6 +38,20 @@ struct ccu_phase {
} \
}
+#define SUNXI_CCU_PHASE_MMC_NEW_TIMING(_struct, _name, _parent, _reg, \
+ _shift, _width, _flags) \
+ struct ccu_phase _struct = {\
+ .shift = _shift, \
+ .width = _width, \
+ .common = { \
+ .reg= _reg, \
+ .hw.init= CLK_HW_INIT(_name,\
+ _parent, \
+
&ccu_phase_mmc_new_timing_ops, \
+ _flags), \
+ } \
+ }
+
static inline struct ccu_phase *hw_to_ccu_phase(struct clk_hw *hw)
{
struct ccu_common *common = hw_to_ccu_common(hw);
@@ -47,4 +61,6 @@ static inline struct ccu_phase *hw_to_ccu_phase(struct clk_hw
*hw)
extern const struct clk_ops ccu_phase_ops;
+extern const struct clk_ops ccu_phase_mmc_new_timing_ops;
+
#endif /* _CCU_PHASE_H_ */
--
2.11.0
[PATCH v2 2/8] clk: Provide option to query hardware for clk phase
On some hardware, the clk phase is tied to the parent clk's rate and some clk delay programmed into the hardware. As the parent clk rate changes, so does the clk phase. Add a clk flag specifying not to use the cached clk phase, but always query the hardware for it. Signed-off-by: Chen-Yu Tsai --- drivers/clk/clk.c| 6 +- include/linux/clk-provider.h | 1 + 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c index 67201f67a14a..05e2481c1340 100644 --- a/drivers/clk/clk.c +++ b/drivers/clk/clk.c @@ -1929,7 +1929,11 @@ static int clk_core_get_phase(struct clk_core *core) int ret; clk_prepare_lock(); - ret = core->phase; + if (core && (core->flags & CLK_GET_PHASE_NOCACHE) && + core->ops->get_phase) + ret = core->ops->get_phase(core->hw); + else + ret = core->phase; clk_prepare_unlock(); return ret; diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h index a428aec36ace..e2e856b1a81f 100644 --- a/include/linux/clk-provider.h +++ b/include/linux/clk-provider.h @@ -35,6 +35,7 @@ #define CLK_IS_CRITICALBIT(11) /* do not gate, ever */ /* parents need enable during gate/ungate, set rate and re-parent */ #define CLK_OPS_PARENT_ENABLE BIT(12) +#define CLK_GET_PHASE_NOCACHE BIT(13) /* do not use the cached clk phase */ struct clk; struct clk_hw; -- 2.11.0
[PATCH v2 0/8] clk: sunxi-ng: Add support for A83T CCU
Hi everyone, (Resent with devicetree mailing list CC-ed.) This is v2 of my A83T CCU series. This is for 4.13. Changes since v1: - Dropped two patches that were merged - Added clk core flag to disable caching of clock phases - Added support for multiple variable pre-dividers - Merged "pll-periph-ahb1" pre-divider clock into "ahb1" clock with multiple variable pre-dividers - Introduced new class of phase clocks that return -ENOTSUPP when the clock is in new timing mode - Force mmc2 clock to new timing mode - Added back mmc2 output and sample clocks - Fixed bit ops for forcing audio PLL configuration - Added requirement for "losc" clock in device tree binding - Stripped leading 0 in device node name - Updated subject prefixes for various patches Patch 1 adds a compatible string for the A83T CCU to the sunxi-ccu bindings. Patch 2 adds a CLK_GET_PHASE_NOCACHE flag to the clk core, asking it not to cache clock phase values. This is similar to CLK_GET_RATE_NOCACHE. Patch 5 has a compile time dependency on this patch, for the flag value. Patch 3 adds a new class of phase clocks that check the new timing mode bit, and returns an error if it is set, which indicates the phase delays no longer apply. This is a clean way to signal which timing mode the mmc clock is in, without using any custom functions or callbacks. We don't support runtime switching of modes. Patch 4 adds support for multiple variable pre-dividers to the sunxi-ng mux class. Patch 5 adds the driver for the A83T CCU. Patch 6 adds the CCU device nodes, and fixes up any existing clock phandles in the dtsi, without using the macros. Patch 7 sets the clock accuracy for the main oscillator. Patch 8 is for the next -rc2, switch the clock indices from raw numbers to macros we introduced with the driver. This will be updated if more peripherals are introduced in the same cycle. Let me know what you think. Cover letter excerpt from v1: This is yet another series that adds support for the A83T CCU. The A83T CCU has a mix of new styled (like the A80) clocks at old (like A3x) offsets. Some differences include: - D1/D2 style PLL clocks - divisible audio module clocks - new timing mode for mmc2 module clock Regards ChenYu Chen-Yu Tsai (8): dt-bindings: clock: sunxi-ccu: Add compatible string for A83T CCU clk: Provide option to query hardware for clk phase clk: sunxi-ng: Add class of phase clocks supporting MMC new timing modes clk: sunxi-ng: Support multiple variable pre-dividers clk: sunxi-ng: Add driver for A83T CCU ARM: sun8i: a83t: Add CCU device nodes ARM: sun8i: a83t: Set clock accuracy for 24MHz oscillator ARM: sun8i: a83t: Switch to CCU device tree binding macros .../devicetree/bindings/clock/sunxi-ccu.txt| 2 + arch/arm/boot/dts/sun8i-a83t.dtsi | 19 +- drivers/clk/clk.c | 6 +- drivers/clk/sunxi-ng/Kconfig | 10 + drivers/clk/sunxi-ng/Makefile | 1 + drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 10 +- drivers/clk/sunxi-ng/ccu-sun6i-a31.c | 10 +- drivers/clk/sunxi-ng/ccu-sun8i-a23.c | 10 +- drivers/clk/sunxi-ng/ccu-sun8i-a33.c | 10 +- drivers/clk/sunxi-ng/ccu-sun8i-a83t.c | 911 + drivers/clk/sunxi-ng/ccu-sun8i-a83t.h | 64 ++ drivers/clk/sunxi-ng/ccu-sun8i-h3.c| 10 +- drivers/clk/sunxi-ng/ccu-sun8i-r.c | 10 +- drivers/clk/sunxi-ng/ccu-sun8i-v3s.c | 10 +- drivers/clk/sunxi-ng/ccu_mux.c | 15 +- drivers/clk/sunxi-ng/ccu_mux.h | 13 +- drivers/clk/sunxi-ng/ccu_phase.c | 47 ++ drivers/clk/sunxi-ng/ccu_phase.h | 16 + include/dt-bindings/clock/sun8i-a83t-ccu.h | 140 include/dt-bindings/reset/sun8i-a83t-ccu.h | 98 +++ include/linux/clk-provider.h | 1 + 21 files changed, 1363 insertions(+), 50 deletions(-) create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-a83t.c create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-a83t.h create mode 100644 include/dt-bindings/clock/sun8i-a83t-ccu.h create mode 100644 include/dt-bindings/reset/sun8i-a83t-ccu.h -- 2.11.0
[PATCH v2 6/8] ARM: sun8i: a83t: Add CCU device nodes
Now that we have support for the A83T CCU, add a device node for it,
and replace any existing placeholder clock phandles with the correct
ones.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun8i-a83t.dtsi | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi
b/arch/arm/boot/dts/sun8i-a83t.dtsi
index c0a1e4f74b89..c9a5d07b2ada 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -162,13 +162,23 @@
#size-cells = <1>;
ranges;
+ ccu: clock@1c2 {
+ compatible = "allwinner,sun8i-a83t-ccu";
+ reg = <0x01c2 0x400>;
+ clocks = <&osc24M>, <&osc16Md512>;
+ clock-names = "hosc", "losc";
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
pio: pinctrl@1c20800 {
compatible = "allwinner,sun8i-a83t-pinctrl";
interrupts = ,
,
;
reg = <0x01c20800 0x400>;
- clocks = <&osc24M>;
+ clocks = <&ccu 45>, <&osc24M>, <&osc16Md512>;
+ clock-names = "apb", "hosc", "losc";
gpio-controller;
interrupt-controller;
#interrupt-cells = <3>;
@@ -214,7 +224,8 @@
interrupts = ;
reg-shift = <2>;
reg-io-width = <4>;
- clocks = <&osc24M>;
+ clocks = <&ccu 53>;
+ resets = <&ccu 40>;
status = "disabled";
};
--
2.11.0
[PATCH v2 8/8] ARM: sun8i: a83t: Switch to CCU device tree binding macros
Now that the CCU device tree binding headers have been merged, we can
use the properly named macros in the device tree, instead of raw
numbers.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun8i-a83t.dtsi | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi
b/arch/arm/boot/dts/sun8i-a83t.dtsi
index e12dd7170b8f..050d3e347740 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -44,6 +44,9 @@
#include
+#include
+#include
+
/ {
interrupt-parent = <&gic>;
#address-cells = <1>;
@@ -178,7 +181,7 @@
,
;
reg = <0x01c20800 0x400>;
- clocks = <&ccu 45>, <&osc24M>, <&osc16Md512>;
+ clocks = <&ccu CLK_BUS_PIO>, <&osc24M>, <&osc16Md512>;
clock-names = "apb", "hosc", "losc";
gpio-controller;
interrupt-controller;
@@ -225,8 +228,8 @@
interrupts = ;
reg-shift = <2>;
reg-io-width = <4>;
- clocks = <&ccu 53>;
- resets = <&ccu 40>;
+ clocks = <&ccu CLK_BUS_UART0>;
+ resets = <&ccu RST_BUS_UART0>;
status = "disabled";
};
--
2.11.0
[PATCH v2 5/8] clk: sunxi-ng: Add driver for A83T CCU
The A83T clock control unit is a hybrid of some new style clock designs
from the A80, and old style layout from the other Allwinner SoCs.
Like the A80, the SoC does not have a low speed 32.768 kHz oscillator.
Unlike the A80, there is no clock input either. The only low speed clock
available is the internal oscillator which runs at around 16 MHz,
divided by 512, yielding a low speed clock around 31.250 kHz.
Also, the MMC2 module clock supports switching to a "new timing" mode.
This mode divides the clock output by half, and disables the CCU based
clock delays. The MMC controller must be configure to the same mode,
and then use its internal clock delays.
This driver does not support runtime switching of the timing modes.
Instead, the new timing mode is enforced at probe time. Consumers can
check which mode is active by trying to get the current phase delay
of the MMC2 phase clocks, which will return -ENOTSUPP if the new
timing mode is active.
Signed-off-by: Chen-Yu Tsai
---
drivers/clk/sunxi-ng/Kconfig | 10 +
drivers/clk/sunxi-ng/Makefile | 1 +
drivers/clk/sunxi-ng/ccu-sun8i-a83t.c | 911 +
drivers/clk/sunxi-ng/ccu-sun8i-a83t.h | 64 ++
include/dt-bindings/clock/sun8i-a83t-ccu.h | 140 +
include/dt-bindings/reset/sun8i-a83t-ccu.h | 98
6 files changed, 1224 insertions(+)
create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-a83t.c
create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-a83t.h
create mode 100644 include/dt-bindings/clock/sun8i-a83t-ccu.h
create mode 100644 include/dt-bindings/reset/sun8i-a83t-ccu.h
diff --git a/drivers/clk/sunxi-ng/Kconfig b/drivers/clk/sunxi-ng/Kconfig
index 64088e599404..8bee22563909 100644
--- a/drivers/clk/sunxi-ng/Kconfig
+++ b/drivers/clk/sunxi-ng/Kconfig
@@ -116,6 +116,16 @@ config SUN8I_A33_CCU
default MACH_SUN8I
depends on MACH_SUN8I || COMPILE_TEST
+config SUN8I_A83T_CCU
+ bool "Support for the Allwinner A83T CCU"
+ select SUNXI_CCU_DIV
+ select SUNXI_CCU_GATE
+ select SUNXI_CCU_NKMP
+ select SUNXI_CCU_NM
+ select SUNXI_CCU_MP
+ select SUNXI_CCU_PHASE
+ default MACH_SUN8I
+
config SUN8I_H3_CCU
bool "Support for the Allwinner H3 CCU"
select SUNXI_CCU_DIV
diff --git a/drivers/clk/sunxi-ng/Makefile b/drivers/clk/sunxi-ng/Makefile
index 0ec02fe14c50..78028c8f5fa9 100644
--- a/drivers/clk/sunxi-ng/Makefile
+++ b/drivers/clk/sunxi-ng/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_SUN5I_CCU) += ccu-sun5i.o
obj-$(CONFIG_SUN6I_A31_CCU)+= ccu-sun6i-a31.o
obj-$(CONFIG_SUN8I_A23_CCU)+= ccu-sun8i-a23.o
obj-$(CONFIG_SUN8I_A33_CCU)+= ccu-sun8i-a33.o
+obj-$(CONFIG_SUN8I_A83T_CCU) += ccu-sun8i-a83t.o
obj-$(CONFIG_SUN8I_H3_CCU) += ccu-sun8i-h3.o
obj-$(CONFIG_SUN8I_V3S_CCU)+= ccu-sun8i-v3s.o
obj-$(CONFIG_SUN8I_R_CCU) += ccu-sun8i-r.o
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-a83t.c
b/drivers/clk/sunxi-ng/ccu-sun8i-a83t.c
new file mode 100644
index ..e32ef2cac568
--- /dev/null
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-a83t.c
@@ -0,0 +1,911 @@
+/*
+ * Copyright (c) 2017 Chen-Yu Tsai. All rights reserved.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+
+#include "ccu_common.h"
+#include "ccu_reset.h"
+
+#include "ccu_div.h"
+#include "ccu_gate.h"
+#include "ccu_mp.h"
+#include "ccu_nkmp.h"
+#include "ccu_nm.h"
+#include "ccu_phase.h"
+
+#include "ccu-sun8i-a83t.h"
+
+#define CCU_SUN8I_A83T_LOCK_REG0x208
+
+static struct clk_div_table pll_cpux_p_div_table[] = {
+ { .val = 0, .div = 1 },
+ { .val = 1, .div = 4 },
+ { /* Sentinel */ },
+};
+
+/*
+ * The CPU PLLs are actually NP clocks, but P is /1 or /4, so here we
+ * use the NM clocks with a divider table for M.
+ */
+static struct ccu_nm pll_c0cpux_clk = {
+ .enable = BIT(31),
+ .lock = BIT(0),
+ .n = _SUNXI_CCU_MULT_OFFSET_MIN_MAX(8, 8, 0, 12, 0),
+ .m = _SUNXI_CCU_DIV_TABLE(16, 1, pll_cpux_p_div_table),
+ .common = {
+ .reg= 0x000,
+ .lock_reg = CCU_SUN8I_A83T_LOCK_REG,
+ .features = CCU_FEATURE_LOCK_REG,
+ .hw.init= CLK_HW_INIT("pll-c0cpux", "osc24M",
+ &ccu_nm_ops, CLK_SET_RATE_UNGATE),
+ },
+};
+
+static struct ccu_nm pll_c1cpux_clk = {
+ .enable = BIT(31),
+ .lock = BIT(1),
+ .n
[PATCH v2 7/8] ARM: sun8i: a83t: Set clock accuracy for 24MHz oscillator
The datasheets for Allwinner SoCs set strict requirements on the stability of the external crystal oscillators. Add the accuracy for the main 24MHz oscillator to the device tree. Signed-off-by: Chen-Yu Tsai --- arch/arm/boot/dts/sun8i-a83t.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi b/arch/arm/boot/dts/sun8i-a83t.dtsi index c9a5d07b2ada..e12dd7170b8f 100644 --- a/arch/arm/boot/dts/sun8i-a83t.dtsi +++ b/arch/arm/boot/dts/sun8i-a83t.dtsi @@ -126,6 +126,7 @@ #clock-cells = <0>; compatible = "fixed-clock"; clock-frequency = <2400>; + clock-accuracy = <5>; clock-output-names = "osc24M"; }; -- 2.11.0
[PATCH v2 3/8] clk: sunxi-ng: Add class of phase clocks supporting MMC new timing modes
The MMC clocks on newer SoCs, such as the A83T and H3, support the
"new timing mode". Under this mode, the output of the clock is divided
by 2, and the clock delays no longer apply.
Due to how the clock tree is modeled and setup, we need to model
this function in two places, the master mmc clock and the two
child phase clocks. In the mmc clock, we can easily model the
mode bit as an extra variable post-divider. In the phase clocks,
we check the bit and return -ENOTSUPP if the bit is set, signaling
that the phase clocks are not to be used.
This patch introduces a class of phase clocks that checks the
timing mode bit.
Signed-off-by: Chen-Yu Tsai
---
drivers/clk/sunxi-ng/ccu_phase.c | 47
drivers/clk/sunxi-ng/ccu_phase.h | 16 ++
2 files changed, 63 insertions(+)
diff --git a/drivers/clk/sunxi-ng/ccu_phase.c b/drivers/clk/sunxi-ng/ccu_phase.c
index 400c58ad72fd..e6ff7551c855 100644
--- a/drivers/clk/sunxi-ng/ccu_phase.c
+++ b/drivers/clk/sunxi-ng/ccu_phase.c
@@ -8,6 +8,7 @@
* the License, or (at your option) any later version.
*/
+#include
#include
#include
@@ -124,3 +125,49 @@ const struct clk_ops ccu_phase_ops = {
.get_phase = ccu_phase_get_phase,
.set_phase = ccu_phase_set_phase,
};
+
+/*
+ * The MMC clocks on newer SoCs support the "new timing mode". Under
+ * this mode, the output of the clock is divided by 2, and the clock
+ * delays no longer apply.
+ *
+ * Due to how the clock tree is modeled and setup, we need to model
+ * this function in two places, the master mmc clock and the two
+ * child phase clocks. In the mmc clock, we can easily model the
+ * mode bit as an extra variable post-divider. In the phase clocks,
+ * we check the bit and return -ENOTSUPP if the bit is set, signaling
+ * that the phase clocks are not to be used.
+ *
+ * We do not support runtime configuration of the modes. Instead a
+ * mode is enforced at CCU probe time.
+ */
+#define CCU_MMC_NEW_TIMING_MODEBIT(30)
+
+static int ccu_phase_mmc_new_timing_get_phase(struct clk_hw *hw)
+{
+ struct ccu_phase *phase = hw_to_ccu_phase(hw);
+ u32 reg;
+
+ reg = readl(phase->common.base + phase->common.reg);
+ if (reg & CCU_MMC_NEW_TIMING_MODE)
+ return -ENOTSUPP;
+
+ return ccu_phase_get_phase(hw);
+}
+
+static int ccu_phase_mmc_new_timing_set_phase(struct clk_hw *hw, int degrees)
+{
+ struct ccu_phase *phase = hw_to_ccu_phase(hw);
+ u32 reg;
+
+ reg = readl(phase->common.base + phase->common.reg);
+ if (reg & CCU_MMC_NEW_TIMING_MODE)
+ return -ENOTSUPP;
+
+ return ccu_phase_set_phase(hw, degrees);
+}
+
+const struct clk_ops ccu_phase_mmc_new_timing_ops = {
+ .get_phase = ccu_phase_mmc_new_timing_get_phase,
+ .set_phase = ccu_phase_mmc_new_timing_set_phase,
+};
diff --git a/drivers/clk/sunxi-ng/ccu_phase.h b/drivers/clk/sunxi-ng/ccu_phase.h
index 75a091a4c565..c514d1798cdd 100644
--- a/drivers/clk/sunxi-ng/ccu_phase.h
+++ b/drivers/clk/sunxi-ng/ccu_phase.h
@@ -38,6 +38,20 @@ struct ccu_phase {
} \
}
+#define SUNXI_CCU_PHASE_MMC_NEW_TIMING(_struct, _name, _parent, _reg, \
+ _shift, _width, _flags) \
+ struct ccu_phase _struct = {\
+ .shift = _shift, \
+ .width = _width, \
+ .common = { \
+ .reg= _reg, \
+ .hw.init= CLK_HW_INIT(_name,\
+ _parent, \
+
&ccu_phase_mmc_new_timing_ops, \
+ _flags), \
+ } \
+ }
+
static inline struct ccu_phase *hw_to_ccu_phase(struct clk_hw *hw)
{
struct ccu_common *common = hw_to_ccu_common(hw);
@@ -47,4 +61,6 @@ static inline struct ccu_phase *hw_to_ccu_phase(struct clk_hw
*hw)
extern const struct clk_ops ccu_phase_ops;
+extern const struct clk_ops ccu_phase_mmc_new_timing_ops;
+
#endif /* _CCU_PHASE_H_ */
--
2.11.0
[PATCH v2 4/8] clk: sunxi-ng: Support multiple variable pre-dividers
On the A83T, the AHB1 clock has a shared pre-divider on the two
PLL-PERIPH clock parents. To support such instances of shared
pre-dividers, this patch extends the mux clock type to support
multiple variable pre-dividers.
As the pre-dividers are only used to calculate the rate, but
do not participate in the factorization process, this is fairly
straightforward.
Signed-off-by: Chen-Yu Tsai
---
drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 10 +-
drivers/clk/sunxi-ng/ccu-sun6i-a31.c | 10 +-
drivers/clk/sunxi-ng/ccu-sun8i-a23.c | 10 +-
drivers/clk/sunxi-ng/ccu-sun8i-a33.c | 10 +-
drivers/clk/sunxi-ng/ccu-sun8i-h3.c | 10 +-
drivers/clk/sunxi-ng/ccu-sun8i-r.c| 10 +-
drivers/clk/sunxi-ng/ccu-sun8i-v3s.c | 10 +-
drivers/clk/sunxi-ng/ccu_mux.c| 15 ---
drivers/clk/sunxi-ng/ccu_mux.h| 13 -
9 files changed, 51 insertions(+), 47 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
index f54114c607df..2bb4cabf802f 100644
--- a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
+++ b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
@@ -211,6 +211,9 @@ static SUNXI_CCU_M(axi_clk, "axi", "cpux", 0x050, 0, 2, 0);
static const char * const ahb1_parents[] = { "osc32k", "osc24M",
"axi", "pll-periph0" };
+static const struct ccu_mux_var_prediv ahb1_predivs[] = {
+ { .index = 3, .shift = 6, .width = 2 },
+};
static struct ccu_div ahb1_clk = {
.div= _SUNXI_CCU_DIV_FLAGS(4, 2, CLK_DIVIDER_POWER_OF_TWO),
@@ -218,11 +221,8 @@ static struct ccu_div ahb1_clk = {
.shift = 12,
.width = 2,
- .variable_prediv= {
- .index = 3,
- .shift = 6,
- .width = 2,
- },
+ .var_predivs= ahb1_predivs,
+ .n_var_predivs = ARRAY_SIZE(ahb1_predivs),
},
.common = {
diff --git a/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
b/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
index 89e68d29bf45..bc9f2ca19233 100644
--- a/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
+++ b/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
@@ -195,6 +195,9 @@ static SUNXI_CCU_DIV_TABLE(axi_clk, "axi", "cpu",
static const char * const ahb1_parents[] = { "osc32k", "osc24M",
"axi", "pll-periph" };
+static const struct ccu_mux_var_prediv ahb1_predivs[] = {
+ { .index = 3, .shift = 6, .width = 2 },
+};
static struct ccu_div ahb1_clk = {
.div= _SUNXI_CCU_DIV_FLAGS(4, 2, CLK_DIVIDER_POWER_OF_TWO),
@@ -203,11 +206,8 @@ static struct ccu_div ahb1_clk = {
.shift = 12,
.width = 2,
- .variable_prediv= {
- .index = 3,
- .shift = 6,
- .width = 2,
- },
+ .var_predivs= ahb1_predivs,
+ .n_var_predivs = ARRAY_SIZE(ahb1_predivs),
},
.common = {
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-a23.c
b/drivers/clk/sunxi-ng/ccu-sun8i-a23.c
index 5c6d37bdf247..8a753ed0426d 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-a23.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-a23.c
@@ -169,6 +169,9 @@ static SUNXI_CCU_M(axi_clk, "axi", "cpux", 0x050, 0, 2, 0);
static const char * const ahb1_parents[] = { "osc32k", "osc24M",
"axi" , "pll-periph" };
+static const struct ccu_mux_var_prediv ahb1_predivs[] = {
+ { .index = 3, .shift = 6, .width = 2 },
+};
static struct ccu_div ahb1_clk = {
.div= _SUNXI_CCU_DIV_FLAGS(4, 2, CLK_DIVIDER_POWER_OF_TWO),
@@ -176,11 +179,8 @@ static struct ccu_div ahb1_clk = {
.shift = 12,
.width = 2,
- .variable_prediv= {
- .index = 3,
- .shift = 6,
- .width = 2,
- },
+ .var_predivs= ahb1_predivs,
+ .n_var_predivs = ARRAY_SIZE(ahb1_predivs),
},
.common = {
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-a33.c
b/drivers/clk/sunxi-ng/ccu-sun8i-a33.c
index 8d38e6510e29..10b38dc46f75 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-a33.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-a33.c
@@ -180,6 +180,9 @@ static SUNXI_CCU_M(axi_clk, "axi", "cpux", 0x050, 0, 2, 0);
static const char * const ahb1_parents[] = { "osc32k", "osc24M",
"axi" , "pll-periph" };
+static const struct ccu_mux_var_prediv ahb1_predivs[] = {
+ { .index = 3, .shift = 6, .width = 2 },
+};
static struct ccu_div ahb1_clk = {
.div= _SUNXI_CCU_DIV_FLAGS(4, 2, CLK_DIVIDER_POWER_OF_TWO),
@@ -187,11 +190,8 @@ static struct ccu_div ahb1_clk = {
.shift = 12
[PATCH v2 2/8] clk: Provide option to query hardware for clk phase
On some hardware, the clk phase is tied to the parent clk's rate and some clk delay programmed into the hardware. As the parent clk rate changes, so does the clk phase. Add a clk flag specifying not to use the cached clk phase, but always query the hardware for it. Signed-off-by: Chen-Yu Tsai --- drivers/clk/clk.c| 6 +- include/linux/clk-provider.h | 1 + 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c index 67201f67a14a..05e2481c1340 100644 --- a/drivers/clk/clk.c +++ b/drivers/clk/clk.c @@ -1929,7 +1929,11 @@ static int clk_core_get_phase(struct clk_core *core) int ret; clk_prepare_lock(); - ret = core->phase; + if (core && (core->flags & CLK_GET_PHASE_NOCACHE) && + core->ops->get_phase) + ret = core->ops->get_phase(core->hw); + else + ret = core->phase; clk_prepare_unlock(); return ret; diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h index a428aec36ace..e2e856b1a81f 100644 --- a/include/linux/clk-provider.h +++ b/include/linux/clk-provider.h @@ -35,6 +35,7 @@ #define CLK_IS_CRITICALBIT(11) /* do not gate, ever */ /* parents need enable during gate/ungate, set rate and re-parent */ #define CLK_OPS_PARENT_ENABLE BIT(12) +#define CLK_GET_PHASE_NOCACHE BIT(13) /* do not use the cached clk phase */ struct clk; struct clk_hw; -- 2.11.0
[PATCH v2 1/8] dt-bindings: clock: sunxi-ccu: Add compatible string for A83T CCU
The A83T clock control unit is a hybrid of some new style clock designs from the A80, and old style layout from the other Allwinner SoCs. Like the A80, the SoC does not have a low speed 32.768 kHz oscillator. Unlike the A80, there is no clock input either. The only low speed clock available is the internal oscillator which runs at around 16 MHz, divided by 512, yielding a low speed clock around 31.250 kHz. Signed-off-by: Chen-Yu Tsai --- Documentation/devicetree/bindings/clock/sunxi-ccu.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/clock/sunxi-ccu.txt b/Documentation/devicetree/bindings/clock/sunxi-ccu.txt index e9c5a1d9834a..34b2a9249a94 100644 --- a/Documentation/devicetree/bindings/clock/sunxi-ccu.txt +++ b/Documentation/devicetree/bindings/clock/sunxi-ccu.txt @@ -6,6 +6,7 @@ Required properties : - "allwinner,sun6i-a31-ccu" - "allwinner,sun8i-a23-ccu" - "allwinner,sun8i-a33-ccu" + - "allwinner,sun8i-a83t-ccu" - "allwinner,sun8i-h3-ccu" - "allwinner,sun8i-h3-r-ccu" - "allwinner,sun8i-v3s-ccu" @@ -18,6 +19,7 @@ Required properties : - clocks: phandle to the oscillators feeding the CCU. Two are needed: - "hosc": the high frequency oscillator (usually at 24MHz) - "losc": the low frequency oscillator (usually at 32kHz) + On the A83T, this is the internal 16MHz oscillator divided by 512 - clock-names: Must contain the clock names described just above - #clock-cells : must contain 1 - #reset-cells : must contain 1 -- 2.11.0
[PATCH v2 0/8] clk: sunxi-ng: Add support for A83T CCU
Hi everyone, This is v2 of my A83T CCU series. This is for 4.13. Changes since v1: - Dropped two patches that were merged - Added clk core flag to disable caching of clock phases - Added support for multiple variable pre-dividers - Merged "pll-periph-ahb1" pre-divider clock into "ahb1" clock with multiple variable pre-dividers - Introduced new class of phase clocks that return -ENOTSUPP when the clock is in new timing mode - Force mmc2 clock to new timing mode - Added back mmc2 output and sample clocks - Fixed bit ops for forcing audio PLL configuration - Added requirement for "losc" clock in device tree binding - Stripped leading 0 in device node name - Updated subject prefixes for various patches Patch 1 adds a compatible string for the A83T CCU to the sunxi-ccu bindings. Patch 2 adds a CLK_GET_PHASE_NOCACHE flag to the clk core, asking it not to cache clock phase values. This is similar to CLK_GET_RATE_NOCACHE. Patch 5 has a compile time dependency on this patch, for the flag value. Patch 3 adds a new class of phase clocks that check the new timing mode bit, and returns an error if it is set, which indicates the phase delays no longer apply. This is a clean way to signal which timing mode the mmc clock is in, without using any custom functions or callbacks. We don't support runtime switching of modes. Patch 4 adds support for multiple variable pre-dividers to the sunxi-ng mux class. Patch 5 adds the driver for the A83T CCU. Patch 6 adds the CCU device nodes, and fixes up any existing clock phandles in the dtsi, without using the macros. Patch 7 sets the clock accuracy for the main oscillator. Patch 8 is for the next -rc2, switch the clock indices from raw numbers to macros we introduced with the driver. This will be updated if more peripherals are introduced in the same cycle. Let me know what you think. Cover letter excerpt from v1: This is yet another series that adds support for the A83T CCU. The A83T CCU has a mix of new styled (like the A80) clocks at old (like A3x) offsets. Some differences include: - D1/D2 style PLL clocks - divisible audio module clocks - new timing mode for mmc2 module clock Regards ChenYu Chen-Yu Tsai (8): dt-bindings: clock: sunxi-ccu: Add compatible string for A83T CCU clk: Provide option to query hardware for clk phase clk: sunxi-ng: Add class of phase clocks supporting MMC new timing modes clk: sunxi-ng: Support multiple variable pre-dividers clk: sunxi-ng: Add driver for A83T CCU ARM: sun8i: a83t: Add CCU device nodes ARM: sun8i: a83t: Set clock accuracy for 24MHz oscillator ARM: sun8i: a83t: Switch to CCU device tree binding macros .../devicetree/bindings/clock/sunxi-ccu.txt| 2 + arch/arm/boot/dts/sun8i-a83t.dtsi | 19 +- drivers/clk/clk.c | 6 +- drivers/clk/sunxi-ng/Kconfig | 10 + drivers/clk/sunxi-ng/Makefile | 1 + drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 10 +- drivers/clk/sunxi-ng/ccu-sun6i-a31.c | 10 +- drivers/clk/sunxi-ng/ccu-sun8i-a23.c | 10 +- drivers/clk/sunxi-ng/ccu-sun8i-a33.c | 10 +- drivers/clk/sunxi-ng/ccu-sun8i-a83t.c | 911 + drivers/clk/sunxi-ng/ccu-sun8i-a83t.h | 64 ++ drivers/clk/sunxi-ng/ccu-sun8i-h3.c| 10 +- drivers/clk/sunxi-ng/ccu-sun8i-r.c | 10 +- drivers/clk/sunxi-ng/ccu-sun8i-v3s.c | 10 +- drivers/clk/sunxi-ng/ccu_mux.c | 15 +- drivers/clk/sunxi-ng/ccu_mux.h | 13 +- drivers/clk/sunxi-ng/ccu_phase.c | 47 ++ drivers/clk/sunxi-ng/ccu_phase.h | 16 + include/dt-bindings/clock/sun8i-a83t-ccu.h | 140 include/dt-bindings/reset/sun8i-a83t-ccu.h | 98 +++ include/linux/clk-provider.h | 1 + 21 files changed, 1363 insertions(+), 50 deletions(-) create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-a83t.c create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-a83t.h create mode 100644 include/dt-bindings/clock/sun8i-a83t-ccu.h create mode 100644 include/dt-bindings/reset/sun8i-a83t-ccu.h -- 2.11.0
Re: [PATCH 1/3] drm: fourcc byteorder: drop DRM_FORMAT_BIG_ENDIAN
On 03/05/17 12:06 AM, Gerd Hoffmann wrote: > >> Removing the definition also removes the possibility to describe a lot >> of pixel formats, so that should definitely be mentioned. I think it >> would also be good to have some kind of justified claim that no >> hardware actually needs the pixel formats this is removing (e.g. RGB565 >> BE). > > That and RGB2101010 BE are the only candidates I can think of. > > Dealing with those in none-native byteorder is a PITA though. Display > hardware is little endian (pci byte order) for quite a while already. Maybe by default, but not exclusively. > radeon looks differently on pre-R600 and R600+ hardware. > > pre-R600 can byteswap on cpu access, so the cpu view is bigendian > whereas things are actually stored on little endian byte order. > Hardware supports both 16bit and 32bit swaps. Used for fbdev emulation > (probably 32bit swaps, but not fully sure). 32-bit swaps for 32 bpp, 16-bit swaps for 16 bpp. > R600+ supports bigendian framebuffer formats, so no byteswapping on > access is needed. Not sure whenever that includes 16bpp formats or > whenever this is limited to the 8 bit-per-color formats [...] It includes 16bpp. Looking at drivers/gpu/drm/radeon/atombios_crtc.c:dce4_crtc_do_set_base(), it sets up byte-swapping for all multi-byte formats, so it effectively treats all those formats as if they had DRM_FORMAT_BIG_ENDIAN set. If the radeon (and amdgpu) driver were to be changed to use drm_mode_legacy_fb_format_he for >= R600, that must also handle 16 bpp, which requires DRM_FORMAT_BIG_ENDIAN. So I still don't see how that can be removed or even deprecated. >From Ilia's followup it sounds like there's a similar situation with nouveau. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
[PATCH] x86/intel_rdt: Fix a typo in Documentation
The typo is in example 3. "C0" in "# echo C0 > p0/cpus" is wrong because it specifies core 6-7 instead of wanted core 4-7. Correct this typo to avoid confusion. Signed-off-by: Xiaochen Shen Signed-off-by: Fenghua Yu --- Documentation/x86/intel_rdt_ui.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/x86/intel_rdt_ui.txt b/Documentation/x86/intel_rdt_ui.txt index 0f6d847..c491a1b 100644 --- a/Documentation/x86/intel_rdt_ui.txt +++ b/Documentation/x86/intel_rdt_ui.txt @@ -295,7 +295,7 @@ kernel and the tasks running there get 50% of the cache. They should also get 50% of memory bandwidth assuming that the cores 4-7 are SMT siblings and only the real time threads are scheduled on the cores 4-7. -# echo C0 > p0/cpus +# echo F0 > p0/cpus 4) Locking between applications -- 1.8.3.1
Re: Asmedia USB 1343 crashes
On Tuesday, May 2, 2017 8:04:28 PM MDT Thomas Fjellstrom wrote: > On Monday, May 1, 2017 12:08:55 PM MDT Thomas Fjellstrom wrote: > > On Monday, May 1, 2017 1:57:53 PM MDT Alan Stern wrote: > > > On Mon, 1 May 2017, Thomas Fjellstrom wrote: > > > > On Monday, May 1, 2017 10:54:12 AM MDT Alan Stern wrote: > > > > > On Mon, 1 May 2017, Thomas Fjellstrom wrote: > > > > > > I've got a 970 Pro gaming aura motherboard with an Asmedia 1343 Usb > > > [snip] > > > > > [lots of resets and warnings cut out] > > > > > > Well, this answers one question: The program not claiming interface 0 > > > is ThreadWeaver::T, whatever that is. This isn't really an error, but > > > it is sloppy programming. You could report it to the maintainers of > > > that program. > > > > > > The log shows a more or less constant series of warnings and resets as > > > long as the Android device is plugged in. This would explain any > > > unresponsiveness, although it doesn't explain eventual crashes. > > > > > > If you know what that ThreadWeaver program is, and if you don't need > > > it, you could try disabling or removing it to see if the situation > > > improves. > > > > I'm not sure what program that comes from either, I'll look it up. > > > > Something to note is that things work fine if suspend is disabled or using > > the regular usb 2 ports on my motherboard instead of the usb 3 ports. > > > > I also saw different error messages, much more severe ones that caused the > > xhci host to lock up completely and it didn't seem to need me to plug phones > > in to cause it. I'll follow up after i get it to happen again. > > I just had a brief lockup, desktop stopped responding, other usb devices not > on the usb3 controller. Two android devices were in the process of restarting. > > It doesn't seem to matter what android devices it is. > [snip log] The usb 3.1 controller seems to be inaccessible. It'll probably need a reboot to get working again. > > > > Alan Stern > > > -- Thomas Fjellstrom tho...@fjellstrom.ca
[PATCH v2] staging: rtl8723bs: Fix coding style issues
checkpatch.pl reported errors for use of extra whitespaces in the function prototypes. Removed extra spaces to meet the coding standards. Signed-off-by: Adheer Chandravanshi --- drivers/staging/rtl8723bs/include/rtl8192c_rf.h | 23 ++- 1 file changed, 10 insertions(+), 13 deletions(-) diff --git a/drivers/staging/rtl8723bs/include/rtl8192c_rf.h b/drivers/staging/rtl8723bs/include/rtl8192c_rf.h index 0dbee56..97900a3 100644 --- a/drivers/staging/rtl8723bs/include/rtl8192c_rf.h +++ b/drivers/staging/rtl8723bs/include/rtl8192c_rf.h @@ -19,19 +19,16 @@ /* */ /* RF RL6052 Series API */ /* */ -void rtl8192c_RF_ChangeTxPath(struct adapter *Adapter, - u16 DataRate); -void rtl8192c_PHY_RF6052SetBandwidth( - struct adapter *Adapter, - enum CHANNEL_WIDTH Bandwidth); -void rtl8192c_PHY_RF6052SetCckTxPower( - struct adapter *Adapter, - u8* pPowerlevel); -void rtl8192c_PHY_RF6052SetOFDMTxPower( - struct adapter *Adapter, - u8* pPowerLevel, - u8 Channel); -intPHY_RF6052_Config8192C(struct adapter * Adapter ); +void rtl8192c_RF_ChangeTxPath(struct adapter *Adapter, + u16 DataRate); +void rtl8192c_PHY_RF6052SetBandwidth(struct adapter *Adapter, +enum CHANNEL_WIDTH Bandwidth); +void rtl8192c_PHY_RF6052SetCckTxPower(struct adapter *Adapter, + u8 *pPowerlevel); +void rtl8192c_PHY_RF6052SetOFDMTxPower(struct adapter *Adapter, + u8 *pPowerLevel, + u8 Channel); +int PHY_RF6052_Config8192C(struct adapter *Adapter); /*--Exported Function prototype-*/ -- 1.9.1
[PATCH v2] Fix coding style issues
Patch v2 addresses review comments from Greg KH. Following is a single patch with only one type of coding style issues fixed. Adheer Chandravanshi (1): staging: rtl8723bs: Fix coding style issues drivers/staging/rtl8723bs/include/rtl8192c_rf.h | 23 ++- 1 file changed, 10 insertions(+), 13 deletions(-) -- 1.9.1
Re: [PATCH 1/2] remoteproc: Introduce rproc_{start,stop}() functions
On 05/02/2017 05:02 PM, Bjorn Andersson wrote:
On Tue 02 May 13:59 PDT 2017, Sarangdhar Joshi wrote:
In the context of recovering from crash,
rproc_trigger_recovery() does rproc_shutdown() followed
by rproc_boot(). The remoteproc resources are cleaned up
in rproc_shutdown() and immediately reallocated in
rproc_boot() which is an unnecessary overhead.
Furthermore, we want the memory regions to be accessible
after stopping the remote processor, to be able to extract
the memory content for a coredump.
The current patch factors out the code in rproc_boot() and
"This patch factors..."
rproc_shutdown() path and introduces rproc_{start,stop}()
in order to avoid resource allocation overhead.
I think the result of the two patches looks good.
But I would prefer if you splice them differently. If I read the patches
correctly you should be able to introduce rproc_start()/stop() and move
rproc_boot()/shutdown() over to use these in one patch and then in a
second patch modify the behavior of the recovery.
That way if one bisects any issues to either one we know if it was the
refactoring or the modification of the recovery behavior.
Yes, got your point. I will split it into two separate patches.
Regards,
Sarang
Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH] tcmu: Recalculate the tcmu_cmd size to save cmd area memories
On 05/02/2017 02:54 AM, lixi...@cmss.chinamobile.com wrote: > From: Xiubo Li > > For the "struct tcmu_cmd_entry" in cmd area, the minimum size > will be sizeof(struct tcmu_cmd_entry) == 112 Bytes. And it could > fill about (sizeof(struct rsp) - sizeof(struct req)) / > sizeof(struct iovec) == 68 / 16 ~= 4 data regions(iov[4]) by > default. > > For most tcmu_cmds, the data block indexes allocated from the > data area will be continuous. And for the continuous blocks they > will be merged into the same region using only one iovec. For > the current code, it will always allocates the same number of > iovecs with blocks for each tcmu_cmd, and it will wastes much > memories. > > For example, when the block size is 4K and the DATA_OUT buffer > size is 64K, and the regions needed is less than 5(on my > environment is almost 99.7%). The current code will allocate > about 16 iovecs, and there will be (16 - 4) * sizeof(struct > iovec) = 192 Bytes cmd area memories wasted. > > Here adds two helpers to calculate the base size and full size > of the tcmu_cmd. And will recalculate them again when it make sure > how many iovs is needed before insert it to cmd area. > > Signed-off-by: Xiubo Li Looks ok to me. Thanks. Acked-by: Mike Christie
Re: Asmedia USB 1343 crashes
On Monday, May 1, 2017 12:08:55 PM MDT Thomas Fjellstrom wrote: > On Monday, May 1, 2017 1:57:53 PM MDT Alan Stern wrote: > > On Mon, 1 May 2017, Thomas Fjellstrom wrote: > > > On Monday, May 1, 2017 10:54:12 AM MDT Alan Stern wrote: > > > > On Mon, 1 May 2017, Thomas Fjellstrom wrote: > > > > > I've got a 970 Pro gaming aura motherboard with an Asmedia 1343 Usb > [snip] > > > [lots of resets and warnings cut out] > > > > Well, this answers one question: The program not claiming interface 0 > > is ThreadWeaver::T, whatever that is. This isn't really an error, but > > it is sloppy programming. You could report it to the maintainers of > > that program. > > > > The log shows a more or less constant series of warnings and resets as > > long as the Android device is plugged in. This would explain any > > unresponsiveness, although it doesn't explain eventual crashes. > > > > If you know what that ThreadWeaver program is, and if you don't need > > it, you could try disabling or removing it to see if the situation > > improves. > > I'm not sure what program that comes from either, I'll look it up. > > Something to note is that things work fine if suspend is disabled or using > the regular usb 2 ports on my motherboard instead of the usb 3 ports. > > I also saw different error messages, much more severe ones that caused the > xhci host to lock up completely and it didn't seem to need me to plug phones > in to cause it. I'll follow up after i get it to happen again. I just had a brief lockup, desktop stopped responding, other usb devices not on the usb3 controller. Two android devices were in the process of restarting. It doesn't seem to matter what android devices it is. [294503.849350] [ cut here ] [294503.849362] WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:316 dev_watchdog+0x223/0x230 [294503.849365] NETDEV WATCHDOG: enp4s0 (igb): transmit queue 0 timed out [294503.849367] Modules linked in: sr_mod cdrom ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 xt_addrtype xt_conntrack nf_nat nf_conntrack br_netfilter overlay ebtable_filter ebtables ip6table_filter ip6_tables nfsv3 nfs_acl nfs lockd grace iptable_filter bridge stp llc amdgpu mfd_core fuse vfat fat eeepc_wmi asus_wmi rfkill edac_mce_amd edac_core pcspkr sg amdkfd radeon ttm sunrpc k10temp it87 hwmon_vid fam15h_power efivarfs ip_tables ipv6 autofs4 crc32c_intel i2c_piix4 [294503.849407] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.11.0-rc7 #8 [294503.849410] Hardware name: To be filled by O.E.M. To be filled by O.E.M./970 PRO GAMING/AURA, BIOS 0901 11/07/2016 [294503.849413] Call Trace: [294503.849417] [294503.849422] dump_stack+0x4d/0x63 [294503.849426] __warn+0xc6/0xe0 [294503.849430] warn_slowpath_fmt+0x46/0x50 [294503.849434] dev_watchdog+0x223/0x230 [294503.849438] ? qdisc_rcu_free+0x40/0x40 [294503.849442] call_timer_fn+0x30/0x160 [294503.849445] ? qdisc_rcu_free+0x40/0x40 [294503.849448] run_timer_softirq+0x1e1/0x440 [294503.849453] ? lapic_next_event+0x18/0x20 [294503.849456] ? sched_clock_cpu+0x11/0xd0 [294503.849459] __do_softirq+0x101/0x2f0 [294503.849463] irq_exit+0xb9/0xc0 [294503.849466] smp_apic_timer_interrupt+0x38/0x50 [294503.849470] apic_timer_interrupt+0x86/0x90 [294503.849474] RIP: 0010:acpi_idle_do_entry+0x2c/0x40 [294503.849476] RSP: 0018:b2a03d90 EFLAGS: 0246 ORIG_RAX: ff10 [294503.849480] RAX: RBX: 884d1a966c00 RCX: 0034 [294503.849483] RDX: 4ec4ec4ec4ec4ec5 RSI: 0001 RDI: 884d1a966c64 [294503.849485] RBP: b2a03dd0 R08: 03e3 R09: 0018 [294503.849487] R10: 03c1 R11: 03d4 R12: 884d1a966c64 [294503.849490] R13: 0001 R14: 0001 R15: 0001 [294503.849492] [294503.849497] ? acpi_idle_enter+0xd7/0x290 [294503.849502] cpuidle_enter_state+0xed/0x2e0 [294503.849506] cpuidle_enter+0x12/0x20 [294503.849509] call_cpuidle+0x1e/0x30 [294503.849512] do_idle+0x179/0x1d0 [294503.849515] cpu_startup_entry+0x5d/0x60 [294503.849518] rest_init+0x7f/0x90 [294503.849522] start_kernel+0x405/0x412 [294503.849525] x86_64_start_reservations+0x24/0x26 [294503.849528] x86_64_start_kernel+0x182/0x193 [294503.849531] start_cpu+0x14/0x14 [294503.849534] ? start_cpu+0x14/0x14 [294503.849537] ---[ end trace 12db587e781d6e4f ]--- [294503.849558] igb :04:00.0 enp4s0: Reset adapter [294504.576629] xhci_hcd :02:00.0: Stop command ring failed, maybe the host is dead [294504.576656] xhci_hcd :02:00.0: Abort command ring failed [294504.576799] xhci_hcd :02:00.0: xHCI host not responding to stop endpoint command. [294504.576805] xhci_hcd :02:00.0: Assuming host is dying, halting host. [294504.576817] br0: port 1(enp4s0) entered disabled state [294504.576858] xhci_hcd :02:00.0: HC died; cleaning up [294504.576909] xhci_hcd :02:00.0: Timeout while w
Re: 4.11.0-rc8+/x86_64 desktop lockup until applications closed
Michal Hocko wrote on 02/05/17 17:01: [92311.93] swap_info_get: Bad swap offset entry 000d [92311.99] swap_info_get: Bad swap offset entry 000e [92311.944451] swap_info_get: Bad swap offset entry 000f Pte swap entry seem to be clobbered. That suggests a deeper problem and a memory corruption. Thanks again for the feedback. I've gone with 4.11.0+ git head kernels and last night rather than a lock-up I saw: [40050.937161] mmap: chromium (6060): VmData 2148573184 exceed data ulimit 2147483647. Update limits or use boot option ignore_rlimit_data. [40051.183213] traps: chromium[6060] trap int3 ip:5642ccce7996 sp:7ffe0a563ac0 error:0 and the desktop session remained responsive. The 2 GiB ulimit is preferable for me than having to rely on the OOM killer, but I can run tests with ignore_rlimit_data later on to check that the OOM killer still works rather than hitting some unforeseen error on swap exhaustion. Arthur.
RE: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf
>-Original Message-
>From: Gerd Hoffmann [mailto:kra...@redhat.com]
>Sent: Tuesday, May 02, 2017 5:51 PM
>To: Chen, Xiaoguang
>Cc: alex.william...@redhat.com; intel-...@lists.freedesktop.org; intel-gvt-
>d...@lists.freedesktop.org; Wang, Zhi A ;
>zhen...@linux.intel.com; linux-kernel@vger.kernel.org; Lv, Zhiyuan
>; Tian, Kevin
>Subject: Re: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf
>
>On Fr, 2017-04-28 at 17:35 +0800, Xiaoguang Chen wrote:
>> +static size_t intel_vgpu_reg_rw_gvtg(struct intel_vgpu *vgpu, char
>> *buf,
>> + size_t count, loff_t *ppos, bool iswrite) {
>> + unsigned int i = VFIO_PCI_OFFSET_TO_INDEX(*ppos) -
>> + VFIO_PCI_NUM_REGIONS;
>> + loff_t pos = *ppos & VFIO_PCI_OFFSET_MASK;
>> + int fd;
>> +
>> + if (pos >= vgpu->vdev.region[i].size || iswrite) {
>> + gvt_vgpu_err("invalid op or offset for Intel vgpu fd
>> region\n");
>> + return -EINVAL;
>> + }
>> +
>> + fd = anon_inode_getfd("gvtg", &intel_vgpu_gvtg_ops, vgpu,
>> + O_RDWR | O_CLOEXEC);
>> + if (fd < 0) {
>> + gvt_vgpu_err("create intel vgpu fd failed:%d\n", fd);
>> + return -EINVAL;
>> + }
>> +
>> + count = min(count, (size_t)(vgpu->vdev.region[i].size - pos));
>> + memcpy(buf, &fd, count);
>> +
>> + return count;
>> +}
>
>Hmm, that looks like a rather strange way to return a file descriptor.
>
>What is the reason to not use ioctls on the vfio file handle, like older
>version of
>these patches did?
If I understood correctly that Alex prefer not to change the ioctls on the vfio
file handle like the old version.
So I used this way the smallest change to general vfio framework only adding a
subregion definition.
>
>cheers,
> Gerd
RE: [Intel-wired-lan] [PATCH] igb: make a few local functions static
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On > Behalf Of Colin King > Sent: Thursday, April 27, 2017 10:59 AM > To: Kirsher, Jeffrey T ; intel-wired- > l...@lists.osuosl.org; net...@vger.kernel.org > Cc: kernel-janit...@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: [Intel-wired-lan] [PATCH] igb: make a few local functions static > > From: Colin Ian King > > clean up a few sparse warnings, these following > functions can be made static: > > drivers/net/ethernet/intel/igb/igb_main.c: warning: symbol > 'igb_add_mac_filter' was not declared. Should it be static? > drivers/net/ethernet/intel/igb/igb_main.c: warning: symbol > 'igb_del_mac_filter' was not declared. Should it be static? > drivers/net/ethernet/intel/igb/igb_main.c: warning: symbol > 'igb_set_vf_mac_filter' was not declared. Should it be static? > > Signed-off-by: Colin Ian King > --- > drivers/net/ethernet/intel/igb/igb_main.c | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) Tested-by: Aaron Brown
RE: [Intel-wired-lan] [PATCH net-next] igb: mark PM functions as __maybe_unused
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On
> Behalf Of Arnd Bergmann
> Sent: Thursday, April 27, 2017 12:10 PM
> To: Kirsher, Jeffrey T
> Cc: Arnd Bergmann ; net...@vger.kernel.org; linux-
> ker...@vger.kernel.org; intel-wired-...@lists.osuosl.org; David S. Miller
>
> Subject: [Intel-wired-lan] [PATCH net-next] igb: mark PM functions as
> __maybe_unused
>
> The new wake function is only used by the suspend/resume handlers that
> are defined in inside of an #ifdef, which can cause this harmless
> warning:
>
> drivers/net/ethernet/intel/igb/igb_main.c:7988:13: warning:
> 'igb_deliver_wake_packet' defined but not used [-Wunused-function]
>
> Removing the #ifdef, instead using a __maybe_unused annotation
> simplifies the code and avoids the warning.
>
> Fixes: b90fa8763560 ("igb: Enable reading of wake up packet")
> Signed-off-by: Arnd Bergmann
> ---
> drivers/net/ethernet/intel/igb/igb_main.c | 18 +-
> 1 file changed, 5 insertions(+), 13 deletions(-)
Tested-by: Aaron Brown
Re: RFC: i2c designware gpio recovery
G'day Tim, On 1/05/2017 21:31, Tim Sander wrote: Good Day Phil Am Montag, 1. Mai 2017, 09:57:35 CEST schrieb Phil Reid: So i took a look into the device tree file socfpga.dtsi and found that the reset lines where not defined (although available in the corresponding reset manager). Is there a reason for this? Other components are connected. There's a few thing like that where the bootloader has been expected to setup the resets etc. Yes, but if the resets are not connected in the device tree, the linux drivers are not going to use them? Yes, so they should be added. I don't think we should assume the bootloader sets things up. But that doesn't seem to have been the assumption with the Alter SOC's. However with the patch below my previously sent patch works! If there is interest in would cleanup the patch and send it in for mainlining. I think the most unacceptable part would be this line: + ret = gpio_request_one(bri->scl_gpio, //GPIOF_OPEN_DRAIN | My gpio drivers refuse to work as output as they have no open drain mode. So i wonder how to get this solved in a clean manner. I thought the gpio system would emulate open drain by switching the pin between an input and output driven low in this case. How are you configuring the GPIO's in the FPGA? I don't switch to GPIO mode. As the I2C logic is only pulling active low, i only do a wired and with the gpio (implemented in the fpga) port output on the output enable line for the SCL output. SDA is only an additional input for the second in fpga gpio port. A picture should make it a clearer: gpio scl--\ i2c scl --&---i2c mode output pin (configured as fpga loan) In my case the original i2c pins where occupied by some other logic conflicting so the i2c pins had to be shifted to some other pins using fpga logic. So it was just a matter of adding a two port gpio port. I think I understand. What soft core gpio controller are you using? Given a couple of days I can test this on some flack i2c hardware I have with a Cyclone-V SOC. I'm interested in the functionality as well. Sounds good. If you need some further input how i have configured the fpga drop me a line. For i2c that are connected to the dedicated HPS pins it should be possible to reconfigure the pin mux controller (see system manager) in the HPS to avoid the need to go thru the fpga to get direct control. The docs say this is "unsupport" but I've done some test and it does seem to work. As far as i know the internal jtag chain is only used in the bootloader and there is no linux driver? But it shouldn't be a too big problem to port it to linux. What i am unsure about is the fact that the internal jtag chain which controls the pinmuxing might wreak havoc on other pin states if you reconfigure it? Have a look at the Cyclone V handbook "pin mux control Group REgister Descriptions" From what I can see the chain is used to configure IO standards and drive strength. But not the actual muxes I'm guess the no support is in a similar vain to the emac ptp FPGA interface couldn't be used when the HPS pin where used. But that got changed when the user's proved otherwise. There's just no pin ctrl driver yet to manage it. I am interested in this ptp solution too. Is there anything on the way to mainline? This was working the last time I tried it. I submitted a couple of minor patches for it a while ago. My hardware has a DSA switch attached to the ethernet port and so far I haven't figured out how to enable ptp when using the virtual lan ports on the DSA. But it worked fine when directly connected to a phy. -- Regards Phil Reid
Re: [PATCH] mm, vmalloc: properly track vmalloc users
Hi Michal,
[auto build test ERROR on mmotm/master]
[also build test ERROR on next-20170502]
[cannot apply to v4.11]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Michal-Hocko/mm-vmalloc-properly-track-vmalloc-users/20170503-065022
base: git://git.cmpxchg.org/linux-mmotm.git master
config: m68k-multi_defconfig (attached as .config)
compiler: m68k-linux-gcc (GCC) 4.9.0
reproduce:
wget
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=m68k
All errors (new ones prefixed by >>):
In file included from arch/m68k/include/asm/pgtable_mm.h:147:0,
from arch/m68k/include/asm/pgtable.h:4,
from include/linux/vmalloc.h:9,
from fs/nfsd/nfscache.c:12:
arch/m68k/include/asm/motorola_pgtable.h: In function 'pgd_offset':
>> arch/m68k/include/asm/motorola_pgtable.h:198:11: error: dereferencing
>> pointer to incomplete type
return mm->pgd + pgd_index(address);
^
vim +198 arch/m68k/include/asm/motorola_pgtable.h
^1da177e include/asm-m68k/motorola_pgtable.h Linus Torvalds 2005-04-16 182
}
^1da177e include/asm-m68k/motorola_pgtable.h Linus Torvalds 2005-04-16 183
static inline pte_t pte_mkcache(pte_t pte)
^1da177e include/asm-m68k/motorola_pgtable.h Linus Torvalds 2005-04-16 184
{
^1da177e include/asm-m68k/motorola_pgtable.h Linus Torvalds 2005-04-16 185
pte_val(pte) = (pte_val(pte) & _CACHEMASK040) |
m68k_supervisor_cachemode;
^1da177e include/asm-m68k/motorola_pgtable.h Linus Torvalds 2005-04-16 186
return pte;
^1da177e include/asm-m68k/motorola_pgtable.h Linus Torvalds 2005-04-16 187
}
7e675137 include/asm-m68k/motorola_pgtable.h Nick Piggin2008-04-28 188
static inline pte_t pte_mkspecial(pte_t pte) { return pte; }
^1da177e include/asm-m68k/motorola_pgtable.h Linus Torvalds 2005-04-16 189
^1da177e include/asm-m68k/motorola_pgtable.h Linus Torvalds 2005-04-16 190
#define PAGE_DIR_OFFSET(tsk,address) pgd_offset((tsk),(address))
^1da177e include/asm-m68k/motorola_pgtable.h Linus Torvalds 2005-04-16 191
^1da177e include/asm-m68k/motorola_pgtable.h Linus Torvalds 2005-04-16 192
#define pgd_index(address) ((address) >> PGDIR_SHIFT)
^1da177e include/asm-m68k/motorola_pgtable.h Linus Torvalds 2005-04-16 193
^1da177e include/asm-m68k/motorola_pgtable.h Linus Torvalds 2005-04-16 194
/* to find an entry in a page-table-directory */
5b808a59 include/asm-m68k/motorola_pgtable.h Geert Uytterhoeven 2008-02-07 195
static inline pgd_t *pgd_offset(const struct mm_struct *mm,
5b808a59 include/asm-m68k/motorola_pgtable.h Geert Uytterhoeven 2008-02-07 196
unsigned long address)
^1da177e include/asm-m68k/motorola_pgtable.h Linus Torvalds 2005-04-16 197
{
^1da177e include/asm-m68k/motorola_pgtable.h Linus Torvalds 2005-04-16 @198
return mm->pgd + pgd_index(address);
^1da177e include/asm-m68k/motorola_pgtable.h Linus Torvalds 2005-04-16 199
}
^1da177e include/asm-m68k/motorola_pgtable.h Linus Torvalds 2005-04-16 200
^1da177e include/asm-m68k/motorola_pgtable.h Linus Torvalds 2005-04-16 201
#define swapper_pg_dir kernel_pg_dir
^1da177e include/asm-m68k/motorola_pgtable.h Linus Torvalds 2005-04-16 202
extern pgd_t kernel_pg_dir[128];
^1da177e include/asm-m68k/motorola_pgtable.h Linus Torvalds 2005-04-16 203
^1da177e include/asm-m68k/motorola_pgtable.h Linus Torvalds 2005-04-16 204
static inline pgd_t *pgd_offset_k(unsigned long address)
^1da177e include/asm-m68k/motorola_pgtable.h Linus Torvalds 2005-04-16 205
{
^1da177e include/asm-m68k/motorola_pgtable.h Linus Torvalds 2005-04-16 206
return kernel_pg_dir + (address >> PGDIR_SHIFT);
:: The code at line 198 was first introduced by commit
:: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 Linux-2.6.12-rc2
:: TO: Linus Torvalds
:: CC: Linus Torvalds
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH] bitops.h: use BITS_PER_LONG to simplify BITS_TO_LONGS
On Wed, May 03, 2017 at 07:45:12AM +1000, NeilBrown wrote: >On Tue, May 02 2017, Wei Yang wrote: > >> Hi, masters >> >> Not sure this one is acceptable? > >You'd have better luck getting a response if you post things like this >to akpm - he tends to collect miscellaneous bits and pieces. >I don't think the patch makes more that a tiny improvement and I >wouldn't bother with it, but maybe Andrew will. > >NeilBrown > Yep, thanks for your comment :-) -- Wei Yang Help you, Help me signature.asc Description: PGP signature
linux-next: manual merge of the net-next tree with Linus' tree
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
arch/avr32/include/uapi/asm/socket.h
between commit:
26202873bb51 ("avr32: remove support for AVR32 architecture")
from Linus' tree and commits:
a2d133b1d465 ("sock: introduce SO_MEMINFO getsockopt")
6d4339028b35 ("net: Introduce SO_INCOMING_NAPI_ID"
5daab9db7b65 ("New getsockopt option to get socket cookie")
from the net-next tree.
I fixed it up (I removed the file) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
Re: [PATCH] mm, vmalloc: properly track vmalloc users
Hi Michal,
[auto build test ERROR on mmotm/master]
[also build test ERROR on next-20170502]
[cannot apply to v4.11]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Michal-Hocko/mm-vmalloc-properly-track-vmalloc-users/20170503-065022
base: git://git.cmpxchg.org/linux-mmotm.git master
config: m68k-m5475evb_defconfig (attached as .config)
compiler: m68k-linux-gcc (GCC) 4.9.0
reproduce:
wget
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=m68k
All error/warnings (new ones prefixed by >>):
In file included from arch/m68k/include/asm/pgtable_mm.h:145:0,
from arch/m68k/include/asm/pgtable.h:4,
from include/linux/vmalloc.h:9,
from arch/m68k/kernel/module.c:9:
arch/m68k/include/asm/mcf_pgtable.h: In function 'nocache_page':
>> arch/m68k/include/asm/mcf_pgtable.h:339:43: error: 'init_mm' undeclared
>> (first use in this function)
#define pgd_offset_k(address) pgd_offset(&init_mm, address)
^
arch/m68k/include/asm/mcf_pgtable.h:334:35: note: in definition of macro
'pgd_offset'
#define pgd_offset(mm, address) ((mm)->pgd + pgd_index(address))
^
>> arch/m68k/include/asm/mcf_pgtable.h:366:8: note: in expansion of macro
>> 'pgd_offset_k'
dir = pgd_offset_k(addr);
^
arch/m68k/include/asm/mcf_pgtable.h:339:43: note: each undeclared identifier
is reported only once for each function it appears in
#define pgd_offset_k(address) pgd_offset(&init_mm, address)
^
arch/m68k/include/asm/mcf_pgtable.h:334:35: note: in definition of macro
'pgd_offset'
#define pgd_offset(mm, address) ((mm)->pgd + pgd_index(address))
^
>> arch/m68k/include/asm/mcf_pgtable.h:366:8: note: in expansion of macro
>> 'pgd_offset_k'
dir = pgd_offset_k(addr);
^
arch/m68k/include/asm/mcf_pgtable.h: In function 'cache_page':
>> arch/m68k/include/asm/mcf_pgtable.h:339:43: error: 'init_mm' undeclared
>> (first use in this function)
#define pgd_offset_k(address) pgd_offset(&init_mm, address)
^
arch/m68k/include/asm/mcf_pgtable.h:334:35: note: in definition of macro
'pgd_offset'
#define pgd_offset(mm, address) ((mm)->pgd + pgd_index(address))
^
arch/m68k/include/asm/mcf_pgtable.h:382:8: note: in expansion of macro
'pgd_offset_k'
dir = pgd_offset_k(addr);
^
vim +/init_mm +339 arch/m68k/include/asm/mcf_pgtable.h
91521c2e Greg Ungerer 2011-10-14 333 #define pgd_index(address)
((address) >> PGDIR_SHIFT)
91521c2e Greg Ungerer 2011-10-14 334 #define pgd_offset(mm, address)
((mm)->pgd + pgd_index(address))
91521c2e Greg Ungerer 2011-10-14 335
91521c2e Greg Ungerer 2011-10-14 336 /*
91521c2e Greg Ungerer 2011-10-14 337 * Find an entry in a kernel pagetable
directory.
91521c2e Greg Ungerer 2011-10-14 338 */
91521c2e Greg Ungerer 2011-10-14 @339 #define pgd_offset_k(address)
pgd_offset(&init_mm, address)
91521c2e Greg Ungerer 2011-10-14 340
91521c2e Greg Ungerer 2011-10-14 341 /*
91521c2e Greg Ungerer 2011-10-14 342 * Find an entry in the second-level
pagetable.
91521c2e Greg Ungerer 2011-10-14 343 */
91521c2e Greg Ungerer 2011-10-14 344 static inline pmd_t *pmd_offset(pgd_t
*pgd, unsigned long address)
91521c2e Greg Ungerer 2011-10-14 345 {
91521c2e Greg Ungerer 2011-10-14 346 return (pmd_t *) pgd;
91521c2e Greg Ungerer 2011-10-14 347 }
91521c2e Greg Ungerer 2011-10-14 348
91521c2e Greg Ungerer 2011-10-14 349 /*
91521c2e Greg Ungerer 2011-10-14 350 * Find an entry in the third-level
pagetable.
91521c2e Greg Ungerer 2011-10-14 351 */
91521c2e Greg Ungerer 2011-10-14 352 #define __pte_offset(address)
((address >> PAGE_SHIFT) & (PTRS_PER_PTE - 1))
91521c2e Greg Ungerer 2011-10-14 353 #define pte_offset_kernel(dir, address) \
91521c2e Greg Ungerer 2011-10-14 354 ((pte_t *) __pmd_page(*(dir)) +
__pte_offset(address))
91521c2e Greg Ungerer 2011-10-14 355
91521c2e Greg Ungerer 2011-10-14 356 /*
91521c2e Greg Ungerer 2011-10-14 357 * Disable caching for page at given
kernel virtual address.
91521c2e Greg Ungerer 2011-10-14 358 */
91521c2e Greg Ungerer 2011-10-14 359 static inline void nocache_page(void
*vaddr)
91521c2e Greg Ungerer 2011-10-14 360 {
91521c2e Greg Ungerer 2011-10-14 361 pgd_t *dir;
91521c2e Greg
Re: [PATCH] staging: rtl8192u: ieee80211: rtl819x_TSProc: Fixed coding style issue
On Tue, 2017-05-02 at 20:24 -0400, Fabrizio Perria wrote:
> Fixed checkpatch.pl issue
> ERROR: that open brace { should be on the previous line
[]
> diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c
> b/drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c
[]
> @@ -338,8 +338,7 @@ bool GetTs(
> else
> {
> // In WMM case: we use 4 TID only
> - if (!IsACValid(TID))
> - {
> + if (!IsACValid(TID)) {
> IEEE80211_DEBUG(IEEE80211_DL_ERR, " in %s(), TID(%d) is
> not valid\n", __func__, TID);
> return false;
> }
Why fix only one of these?
$ ./scripts/checkpatch.pl --show-types --strict
--types=else_after_brace,open_brace,braces --terse \
-f drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c
drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c:39: ERROR:OPEN_BRACE: that
open brace { should be on the previous line
drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c:42: ERROR:OPEN_BRACE: that
open brace { should be on the previous line
drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c:48: ERROR:OPEN_BRACE: that
open brace { should be on the previous line
drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c:62: ERROR:OPEN_BRACE: that
open brace { should be on the previous line
drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c:62: ERROR:ELSE_AFTER_BRACE:
else should follow close brace '}'
drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c:70: ERROR:OPEN_BRACE: that
open brace { should be on the previous line
drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c:84: ERROR:OPEN_BRACE: that
open brace { should be on the previous line
drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c:150: ERROR:OPEN_BRACE: that
open brace { should be on the previous line
drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c:175: ERROR:OPEN_BRACE: that
open brace { should be on the previous line
drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c:194: ERROR:OPEN_BRACE: that
open brace { should be on the previous line
drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c:203: CHECK:BRACES: Blank
lines aren't necessary before a close brace '}'
drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c:226: ERROR:OPEN_BRACE: that
open brace { should be on the previous line
drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c:228: ERROR:OPEN_BRACE: that
open brace { should be on the previous line
drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c:233: ERROR:OPEN_BRACE: that
open brace { should be on the previous line
drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c:233:
ERROR:ELSE_AFTER_BRACE: else should follow close brace '}'
drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c:239: ERROR:OPEN_BRACE: that
open brace { should be on the previous line
drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c:239:
ERROR:ELSE_AFTER_BRACE: else should follow close brace '}'
drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c:246: ERROR:OPEN_BRACE: that
open brace { should be on the previous line
drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c:246:
ERROR:ELSE_AFTER_BRACE: else should follow close brace '}'
drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c:248: ERROR:OPEN_BRACE: that
open brace { should be on the previous line
drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c:254: ERROR:OPEN_BRACE: that
open brace { should be on the previous line
drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c:254:
ERROR:ELSE_AFTER_BRACE: else should follow close brace '}'
drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c:268: ERROR:OPEN_BRACE: that
open brace { should be on the previous line
drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c:276: ERROR:OPEN_BRACE: that
open brace { should be on the previous line
drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c:282: CHECK:BRACES: Blank
lines aren't necessary before a close brace '}'
drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c:287: WARNING:BRACES: braces
{} are not necessary for any arm of this statement
drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c:290:
ERROR:ELSE_AFTER_BRACE: else should follow close brace '}'
drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c:330: ERROR:OPEN_BRACE: that
open brace { should be on the previous line
drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c:338: ERROR:OPEN_BRACE: that
open brace { should be on the previous line
drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c:341: ERROR:OPEN_BRACE: that
open brace { should be on the previous line
drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c:347: ERROR:OPEN_BRACE: that
open brace { should be on the previous line
drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c:376: ERROR:OPEN_BRACE: that
open brace { should be on the previous line
drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c:380: ERROR:OPEN_BRACE: that
open brace { should be on the previous line
drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c:380:
ERROR:ELSE_AFTER_BRACE: else
[RFC PATCH v2 2/3] hwmon: (adt7475) fan stall prevention
By default adt7475 will stop the fans (pwm duty cycle 0%) when the
temperature drops past Tmin - hysteresis. Some systems want to keep the
fans moving even when the temperature drops so add new sysfs attributes
that configure the enhanced acoustics min 1-3 which allows the fans to
run at the minimum configure pwm duty cycle.
Signed-off-by: Chris Packham
---
Changes in v2:
- use pwmN_stall_dis as the attribute name. I think this describes the purpose
pretty well. I went with a new attribute instead of overloading
pwmN_auto_point1_pwm so this doesn't affect existing users.
Documentation/hwmon/adt7475 | 5 +
drivers/hwmon/adt7475.c | 50 +
2 files changed, 55 insertions(+)
diff --git a/Documentation/hwmon/adt7475 b/Documentation/hwmon/adt7475
index 0502f2b464e1..63507402cd4f 100644
--- a/Documentation/hwmon/adt7475
+++ b/Documentation/hwmon/adt7475
@@ -109,6 +109,11 @@ fan speed) is applied. PWM values range from 0 (off) to
255 (full speed).
Fan speed may be set to maximum when the temperature sensor associated with
the PWM control exceeds temp#_max.
+At Tmin - hysteresis the PWM output can either be off (0% duty cycle) or at the
+minimum (i.e. auto_point1_pwm). This behaviour be configured using the
+pwm[1-*]_stall_dis sysfs attribute. A value of 0 means the fans will shut off.
+A value of 1 means the fans will run at auto_point1_pwm.
+
Notes
-
diff --git a/drivers/hwmon/adt7475.c b/drivers/hwmon/adt7475.c
index ec0c43fbcdce..85957324cd85 100644
--- a/drivers/hwmon/adt7475.c
+++ b/drivers/hwmon/adt7475.c
@@ -79,6 +79,9 @@
#define REG_TEMP_TRANGE_BASE 0x5F
+#define REG_ENHANCE_ACOUSTICS1 0x62
+#define REG_ENHANCE_ACOUSTICS2 0x63
+
#define REG_PWM_MIN_BASE 0x64
#define REG_TEMP_TMIN_BASE 0x67
@@ -209,6 +212,7 @@ struct adt7475_data {
u8 range[3];
u8 pwmctl[3];
u8 pwmchan[3];
+ u8 enh_acou[2];
u8 vid;
u8 vrm;
@@ -700,6 +704,43 @@ static ssize_t set_pwm(struct device *dev, struct
device_attribute *attr,
data->pwm[sattr->nr][sattr->index] = clamp_val(val, 0, 0xFF);
i2c_smbus_write_byte_data(client, reg,
data->pwm[sattr->nr][sattr->index]);
+ mutex_unlock(&data->lock);
+
+ return count;
+}
+
+
+static ssize_t show_stall_dis(struct device *dev, struct device_attribute
*attr,
+ char *buf)
+{
+ struct sensor_device_attribute_2 *sattr = to_sensor_dev_attr_2(attr);
+ struct i2c_client *client = to_i2c_client(dev);
+ struct adt7475_data *data = i2c_get_clientdata(client);
+ u8 mask = BIT(5 + sattr->index);
+
+ return sprintf(buf, "%d\n", !!(data->enh_acou[0] & mask));
+}
+
+static ssize_t set_stall_dis(struct device *dev, struct device_attribute *attr,
+const char *buf, size_t count)
+{
+ struct sensor_device_attribute_2 *sattr = to_sensor_dev_attr_2(attr);
+ struct i2c_client *client = to_i2c_client(dev);
+ struct adt7475_data *data = i2c_get_clientdata(client);
+ long val;
+ u8 mask = BIT(5 + sattr->index);
+
+ if (kstrtol(buf, 10, &val))
+ return -EINVAL;
+
+ mutex_lock(&data->lock);
+
+ data->enh_acou[0] &= ~mask;
+ if (val)
+ data->enh_acou[0] |= mask;
+
+ i2c_smbus_write_byte_data(client, REG_ENHANCE_ACOUSTICS1,
+ data->enh_acou[0]);
mutex_unlock(&data->lock);
@@ -1028,6 +1069,8 @@ static SENSOR_DEVICE_ATTR_2(pwm1_auto_point1_pwm, S_IRUGO
| S_IWUSR, show_pwm,
set_pwm, MIN, 0);
static SENSOR_DEVICE_ATTR_2(pwm1_auto_point2_pwm, S_IRUGO | S_IWUSR, show_pwm,
set_pwm, MAX, 0);
+static SENSOR_DEVICE_ATTR_2(pwm1_stall_dis, S_IRUGO | S_IWUSR, show_stall_dis,
+ set_stall_dis, 0, 0);
static SENSOR_DEVICE_ATTR_2(pwm2, S_IRUGO | S_IWUSR, show_pwm, set_pwm, INPUT,
1);
static SENSOR_DEVICE_ATTR_2(pwm2_freq, S_IRUGO | S_IWUSR, show_pwmfreq,
@@ -1040,6 +1083,8 @@ static SENSOR_DEVICE_ATTR_2(pwm2_auto_point1_pwm, S_IRUGO
| S_IWUSR, show_pwm,
set_pwm, MIN, 1);
static SENSOR_DEVICE_ATTR_2(pwm2_auto_point2_pwm, S_IRUGO | S_IWUSR, show_pwm,
set_pwm, MAX, 1);
+static SENSOR_DEVICE_ATTR_2(pwm2_stall_dis, S_IRUGO | S_IWUSR, show_stall_dis,
+ set_stall_dis, 0, 1);
static SENSOR_DEVICE_ATTR_2(pwm3, S_IRUGO | S_IWUSR, show_pwm, set_pwm, INPUT,
2);
static SENSOR_DEVICE_ATTR_2(pwm3_freq, S_IRUGO | S_IWUSR, show_pwmfreq,
@@ -1052,6 +1097,8 @@ static SENSOR_DEVICE_ATTR_2(pwm3_auto_point1_pwm, S_IRUGO
| S_IWUSR, show_pwm,
set_pwm, MIN, 2);
static SENSOR_DEVICE_ATTR_2(pwm3_auto_point2_pwm, S_IRUGO | S_IWUSR, show_pwm,
set_pwm, MAX, 2);
+static SENS
[RFC PATCH v2 1/3] hwmon: (adt7475) replace find_nearest() with find_closest()
The adt7475 has had find_nearest() since it's creation in 2009. Since
then find_closest() has been introduced and several drivers have been
updated to use it. Update the adt7475 to use find_closest() and remove
the now unused find_nearest().
Signed-off-by: Chris Packham
---
drivers/hwmon/adt7475.c | 34 +++---
1 file changed, 3 insertions(+), 31 deletions(-)
diff --git a/drivers/hwmon/adt7475.c b/drivers/hwmon/adt7475.c
index c803e3c5fcd4..ec0c43fbcdce 100644
--- a/drivers/hwmon/adt7475.c
+++ b/drivers/hwmon/adt7475.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
/* Indexes for the sysfs hooks */
@@ -314,35 +315,6 @@ static void adt7475_write_word(struct i2c_client *client,
int reg, u16 val)
i2c_smbus_write_byte_data(client, reg, val & 0xFF);
}
-/*
- * Find the nearest value in a table - used for pwm frequency and
- * auto temp range
- */
-static int find_nearest(long val, const int *array, int size)
-{
- int i;
-
- if (val < array[0])
- return 0;
-
- if (val > array[size - 1])
- return size - 1;
-
- for (i = 0; i < size - 1; i++) {
- int a, b;
-
- if (val > array[i + 1])
- continue;
-
- a = val - array[i];
- b = array[i + 1] - val;
-
- return (a <= b) ? i : i + 1;
- }
-
- return 0;
-}
-
static ssize_t show_voltage(struct device *dev, struct device_attribute *attr,
char *buf)
{
@@ -606,7 +578,7 @@ static ssize_t set_point2(struct device *dev, struct
device_attribute *attr,
val -= temp;
/* Find the nearest table entry to what the user wrote */
- val = find_nearest(val, autorange_table, ARRAY_SIZE(autorange_table));
+ val = find_closest(val, autorange_table, ARRAY_SIZE(autorange_table));
data->range[sattr->index] &= ~0xF0;
data->range[sattr->index] |= val << 4;
@@ -864,7 +836,7 @@ static ssize_t set_pwmfreq(struct device *dev, struct
device_attribute *attr,
if (kstrtol(buf, 10, &val))
return -EINVAL;
- out = find_nearest(val, pwmfreq_table, ARRAY_SIZE(pwmfreq_table));
+ out = find_closest(val, pwmfreq_table, ARRAY_SIZE(pwmfreq_table));
mutex_lock(&data->lock);
--
2.11.0.24.ge6920cf
[RFC PATCH v2 3/3] hwmon: (adt7475) temperature smoothing
When enabled temperature smoothing allows ramping the fan speed over a
configurable period of time instead of jumping to the new speed
instantaneously.
Signed-off-by: Chris Packham
---
Changes in v2:
- use a single tempN_smoothing attribute
Documentation/hwmon/adt7475 | 4 ++
drivers/hwmon/adt7475.c | 99 +
2 files changed, 103 insertions(+)
diff --git a/Documentation/hwmon/adt7475 b/Documentation/hwmon/adt7475
index 63507402cd4f..dd6433d819d0 100644
--- a/Documentation/hwmon/adt7475
+++ b/Documentation/hwmon/adt7475
@@ -114,6 +114,10 @@ minimum (i.e. auto_point1_pwm). This behaviour be
configured using the
pwm[1-*]_stall_dis sysfs attribute. A value of 0 means the fans will shut off.
A value of 1 means the fans will run at auto_point1_pwm.
+The responsiveness of the ADT747x to temperature changes can be configured.
+This allows smoothing of the fan speed transition. To set the transition time
+set the value in ms in the temp[1-*]_smoothing sysfs attribute.
+
Notes
-
diff --git a/drivers/hwmon/adt7475.c b/drivers/hwmon/adt7475.c
index 85957324cd85..41342de6e20c 100644
--- a/drivers/hwmon/adt7475.c
+++ b/drivers/hwmon/adt7475.c
@@ -526,6 +526,96 @@ static ssize_t set_temp(struct device *dev, struct
device_attribute *attr,
return count;
}
+/* Assuming CONFIG6[SLOW] is 0 */
+static const int ad7475_st_map[] = {
+ 37500, 18800, 12500, 7500, 4700, 3100, 1600, 800,
+};
+
+static ssize_t show_temp_st(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ struct sensor_device_attribute_2 *sattr = to_sensor_dev_attr_2(attr);
+ struct i2c_client *client = to_i2c_client(dev);
+ struct adt7475_data *data = i2c_get_clientdata(client);
+ int shift, idx;
+ long val;
+
+ switch (sattr->index) {
+ case 0:
+ shift = 0;
+ idx = 0;
+ break;
+ case 1:
+ shift = 4;
+ idx = 1;
+ break;
+ case 2:
+ shift = 0;
+ idx = 1;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ val = data->enh_acou[idx] >> shift;
+ if (val & 0x8) {
+ return sprintf(buf, "%d\n", ad7475_st_map[val & 0x7]);
+ } else {
+ return sprintf(buf, "0\n");
+ }
+}
+
+static ssize_t set_temp_st(struct device *dev, struct device_attribute *attr,
+const char *buf, size_t count)
+{
+ struct sensor_device_attribute_2 *sattr = to_sensor_dev_attr_2(attr);
+ struct i2c_client *client = to_i2c_client(dev);
+ struct adt7475_data *data = i2c_get_clientdata(client);
+ unsigned char reg;
+ int shift, idx;
+ ulong val;
+
+ if (kstrtoul(buf, 10, &val))
+ return -EINVAL;
+
+ switch (sattr->index) {
+ case 0:
+ reg = REG_ENHANCE_ACOUSTICS1;
+ shift = 0;
+ idx = 0;
+ break;
+ case 1:
+ reg = REG_ENHANCE_ACOUSTICS2;
+ shift = 4;
+ idx = 1;
+ break;
+ case 2:
+ reg = REG_ENHANCE_ACOUSTICS2;
+ shift = 0;
+ idx = 1;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ if (val > 0) {
+ val = find_closest_descending(val, ad7475_st_map,
+ ARRAY_SIZE(ad7475_st_map));
+ val |= 0x8;
+ }
+
+ mutex_lock(&data->lock);
+
+ data->enh_acou[idx] &= ~(0xf << shift);
+ data->enh_acou[idx] |= (val << shift);
+
+ i2c_smbus_write_byte_data(client, reg, data->enh_acou[idx]);
+
+ mutex_unlock(&data->lock);
+
+ return count;
+}
+
/*
* Table of autorange values - the user will write the value in millidegrees,
* and we'll convert it
@@ -1008,6 +1098,8 @@ static SENSOR_DEVICE_ATTR_2(temp1_crit, S_IRUGO |
S_IWUSR, show_temp, set_temp,
THERM, 0);
static SENSOR_DEVICE_ATTR_2(temp1_crit_hyst, S_IRUGO | S_IWUSR, show_temp,
set_temp, HYSTERSIS, 0);
+static SENSOR_DEVICE_ATTR_2(temp1_smoothing, S_IRUGO | S_IWUSR, show_temp_st,
+ set_temp_st, 0, 0);
static SENSOR_DEVICE_ATTR_2(temp2_input, S_IRUGO, show_temp, NULL, INPUT, 1);
static SENSOR_DEVICE_ATTR_2(temp2_alarm, S_IRUGO, show_temp, NULL, ALARM, 1);
static SENSOR_DEVICE_ATTR_2(temp2_max, S_IRUGO | S_IWUSR, show_temp, set_temp,
@@ -1024,6 +1116,8 @@ static SENSOR_DEVICE_ATTR_2(temp2_crit, S_IRUGO |
S_IWUSR, show_temp, set_temp,
THERM, 1);
static SENSOR_DEVICE_ATTR_2(temp2_crit_hyst, S_IRUGO | S_IWUSR, show_temp,
set_temp, HYSTERSIS, 1);
+static SENSOR_DEVICE_ATTR_2(temp2_smoothing, S_IRUGO | S_IWUSR, show_temp_st,
+
[PATCH] staging: rtl8192u: ieee80211: rtl819x_TSProc: Fixed coding style issue
Fixed checkpatch.pl issue
ERROR: that open brace { should be on the previous line
Signed-off-by: Fabrizio Perria
---
drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c
b/drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c
index b4c13ff..d4d53fb 100644
--- a/drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c
+++ b/drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c
@@ -338,8 +338,7 @@ bool GetTs(
else
{
// In WMM case: we use 4 TID only
- if (!IsACValid(TID))
- {
+ if (!IsACValid(TID)) {
IEEE80211_DEBUG(IEEE80211_DL_ERR, " in %s(), TID(%d) is
not valid\n", __func__, TID);
return false;
}
--
1.9.1
Re: [PATCH] xen: Move xen_have_vector_callback definition to enlighten.c
On 05/02/17 10:23, Boris Ostrovsky wrote:
> Commit 84d582d236dc ("xen: Revert commits da72ff5bfcb0 and
> 72a9b186292d") defined xen_have_vector_callback in enlighten_hvm.c.
> Since guest-type-neutral code refers to this variable this causes
> build failures when CONFIG_XEN_PVHVM is not defined.
>
> Moving xen_have_vector_callback definition to enlighten.c resolves
> this issue.
>
> Signed-off-by: Boris Ostrovsky
> Reported-by: Randy Dunlap
Works for me. Thanks.
Acked-by: Randy Dunlap
> ---
> arch/x86/xen/enlighten.c | 3 +++
> arch/x86/xen/enlighten_hvm.c | 3 ---
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index 41d324c..a5ffcbb 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -57,6 +57,9 @@ EXPORT_SYMBOL_GPL(xen_start_info);
>
> struct shared_info xen_dummy_shared_info;
>
> +__read_mostly int xen_have_vector_callback;
> +EXPORT_SYMBOL_GPL(xen_have_vector_callback);
> +
> /*
> * Point at some empty memory to start with. We map the real shared_info
> * page as soon as fixmap is up and running.
> diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c
> index 078c512..a6d014f 100644
> --- a/arch/x86/xen/enlighten_hvm.c
> +++ b/arch/x86/xen/enlighten_hvm.c
> @@ -18,9 +18,6 @@
> #include "mmu.h"
> #include "smp.h"
>
> -__read_mostly int xen_have_vector_callback;
> -EXPORT_SYMBOL_GPL(xen_have_vector_callback);
> -
> void __ref xen_hvm_init_shared_info(void)
> {
> int cpu;
>
--
~Randy
