Re: [PATCH] mmc: block: Use the mmc host device index as the mmcblk device index
On 7 April 2016 at 09:57, Ulf Hansson wrote:
> Commit 520bd7a8b415 ("mmc: core: Optimize boot time by detecting cards
> simultaneously") causes regressions for some platforms.
>
> These platforms relies on fixed mmcblk device indexes, instead of
> deploying the defacto standard with UUID/PARTUUID. In other words their
> rootfs needs to be available at hardcoded paths, like /dev/mmcblk0p2.
>
> Such guarantees have never been made by the kernel, but clearly the above
> commit changes the behaviour. More precisely, because of that the order
> changes of how cards becomes detected, so do their corresponding mmcblk
> device indexes.
>
> As the above commit significantly improves boot time for some platforms
> (magnitude of seconds), let's avoid reverting this change but instead
> restore the behaviour of how mmcblk device indexes becomes picked.
>
> By using the same index for the mmcblk device as for the corresponding mmc
> host device, the probe order of mmc host devices decides the index we get
> for the mmcblk device.
>
> For those platforms that suffers from a regression, one could expect that
> this updated behaviour should be sufficient to meet their expectations of
> "fixed" mmcblk device indexes.
>
> Another side effect from this change, is that the same index is used for
> the mmc host device, the mmcblk device and the mmc block queue. That
> should clarify their relationship.
>
> Reported-by: Peter Hurley
> Reported-by: Laszlo Fiat
> Cc: Linus Torvalds
> Fixes: 520bd7a8b415 ("mmc: core: Optimize boot time by detecting cards
> simultaneously")
> Cc:
> Signed-off-by: Ulf Hansson
To get this more thoroughly tested in linux-next, I have applied this
for my next branch.
I will be monitoring test reports from kernelci, but of course I
appreciate also any other feedback on this.
Kind regards
Uffe
> ---
> drivers/mmc/card/block.c | 18 +-
> 1 file changed, 1 insertion(+), 17 deletions(-)
>
> diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
> index 3bdbe50..8a0147d 100644
> --- a/drivers/mmc/card/block.c
> +++ b/drivers/mmc/card/block.c
> @@ -86,7 +86,6 @@ static int max_devices;
>
> /* TODO: Replace these with struct ida */
> static DECLARE_BITMAP(dev_use, MAX_DEVICES);
> -static DECLARE_BITMAP(name_use, MAX_DEVICES);
>
> /*
> * There is one mmc_blk_data per slot.
> @@ -105,7 +104,6 @@ struct mmc_blk_data {
> unsigned intusage;
> unsigned intread_only;
> unsigned intpart_type;
> - unsigned intname_idx;
> unsigned intreset_done;
> #define MMC_BLK_READ BIT(0)
> #define MMC_BLK_WRITE BIT(1)
> @@ -2202,19 +2200,6 @@ static struct mmc_blk_data *mmc_blk_alloc_req(struct
> mmc_card *card,
> goto out;
> }
>
> - /*
> -* !subname implies we are creating main mmc_blk_data that will be
> -* associated with mmc_card with dev_set_drvdata. Due to device
> -* partitions, devidx will not coincide with a per-physical card
> -* index anymore so we keep track of a name index.
> -*/
> - if (!subname) {
> - md->name_idx = find_first_zero_bit(name_use, max_devices);
> - __set_bit(md->name_idx, name_use);
> - } else
> - md->name_idx = ((struct mmc_blk_data *)
> - dev_to_disk(parent)->private_data)->name_idx;
> -
> md->area_type = area_type;
>
> /*
> @@ -2264,7 +2249,7 @@ static struct mmc_blk_data *mmc_blk_alloc_req(struct
> mmc_card *card,
> */
>
> snprintf(md->disk->disk_name, sizeof(md->disk->disk_name),
> -"mmcblk%u%s", md->name_idx, subname ? subname : "");
> +"mmcblk%u%s", card->host->index, subname ? subname : "");
>
> if (mmc_card_mmc(card))
> blk_queue_logical_block_size(md->queue.queue,
> @@ -2418,7 +2403,6 @@ static void mmc_blk_remove_parts(struct mmc_card *card,
> struct list_head *pos, *q;
> struct mmc_blk_data *part_md;
>
> - __clear_bit(md->name_idx, name_use);
> list_for_each_safe(pos, q, &md->part) {
> part_md = list_entry(pos, struct mmc_blk_data, part);
> list_del(pos);
> --
> 1.9.1
>
Re: [PATCH] ARM: davinci: only use NVMEM when available
On Wednesday 16 March 2016 03:04 AM, Arnd Bergmann wrote:
> The davinci platform contains code that calls into the nvmem
> subsystem, but that might be a loadable module, causing a
> link error:
>
> arch/arm/mach-davinci/built-in.o: In function `davinci_get_mac_addr':
> :(.text+0x1088): undefined reference to `nvmem_device_read'
> arch/arm/mach-davinci/built-in.o: In function `read_factory_config':
> :(.text+0x214c): undefined reference to `nvmem_device_read'
>
> Also, when NVMEM is completely disabled, the functions fail with
> nonobvious error messages.
>
> This ensures we only call the API functions when the code is actually
> reachable from the board file, and otherwise prints a unique log
> message.
>
> Signed-off-by: Arnd Bergmann
> Fixes: bec3c11bad0e ("misc: at24: replace memory_accessor with
> nvmem_device_read")
> ---
>
> Hi Greg,
>
> The commit that introduced this is currently in the char-misc tree,
> please apply this fixup on top if you haven't already sent it to Linus.
I don't see this patch in Linus's tree still. I can send this fixup
through ARM-SoC since its all touching mach-davinci anyway. Let me know.
>
> arch/arm/mach-davinci/board-mityomapl138.c | 5 +
> arch/arm/mach-davinci/common.c | 5 +
> 2 files changed, 10 insertions(+)
Regards,
Sekhar
[PATCH] regulator: core: Fix locking of GPIO list on free
When we acquire a shareable enable GPIO on probe we do so with the regulator_list_mutex held. However when we release the GPIOs we do this immediately after dropping the mutex meaning that the list could become corrupted. Move the release into the locked region to avoid this. Signed-off-by: Mark Brown --- drivers/regulator/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index 85d3a746f58a..62ca85c20ff9 100644 --- a/drivers/regulator/core.c +++ b/drivers/regulator/core.c @@ -4066,8 +4066,8 @@ void regulator_unregister(struct regulator_dev *rdev) WARN_ON(rdev->open_count); unset_regulator_supplies(rdev); list_del(&rdev->list); - mutex_unlock(®ulator_list_mutex); regulator_ena_gpio_free(rdev); + mutex_unlock(®ulator_list_mutex); device_unregister(&rdev->dev); } EXPORT_SYMBOL_GPL(regulator_unregister); -- 2.8.0.rc3
Build regressions/improvements in v4.6-rc3
Below is the list of build error/warning regressions/improvements in v4.6-rc3[1] compared to v4.5[2]. Summarized: - build errors: +11/-7 - build warnings: +164/-154 JFYI, when comparing v4.6-rc3[1] to v4.6-rc2[3], the summaries are: - build errors: +5/-8 - build warnings: +65/-44 Note that there may be false regressions, as some logs are incomplete. Still, they're build errors/warnings. As I haven't mastered kup yet, there's no verbose summary at http://www.kernel.org/pub/linux/kernel/people/geert/linux-log/v4.6-rc3.summary.gz Happy fixing! ;-) Thanks to the linux-next team for providing the build service. [1] http://kisskb.ellerman.id.au/kisskb/head/10162/ (all 262 configs) [2] http://kisskb.ellerman.id.au/kisskb/head/10047/ (all 262 configs) [3] http://kisskb.ellerman.id.au/kisskb/head/10139/ (261 out of 262 configs) *** ERRORS *** 11 error regressions: + /home/kisskb/slave/src/fs/xfs/xfs_ondisk.h: error: call to '__compiletime_assert_79' declared with attribute error: XFS: sizeof(xfs_attr_shortform_t) is wrong, expected 8: => 79:2 + /tmp/cc6IUqGJ.s: Error: pcrel too far BFD_RELOC_BFIN_10: => 889 + error: hns_dsaf_gmac.c: relocation truncated to fit: R_PPC64_REL24 against symbol `.udelay' defined in .text section in arch/powerpc/kernel/built-in.o: => (.text+0x1ff84a8), (.text+0x1ff84e0) + error: hns_dsaf_gmac.c: relocation truncated to fit: R_PPC64_REL24 against symbol `_savegpr0_27' defined in .text.save.restore section in arch/powerpc/lib/built-in.o: => (.text+0x1ff7750) + error: hns_dsaf_gmac.c: relocation truncated to fit: R_PPC64_REL24 against symbol `_savegpr0_30' defined in .text.save.restore section in arch/powerpc/lib/built-in.o: => (.text+0x1ff83f8) + error: hns_dsaf_mac.c: relocation truncated to fit: R_PPC64_REL24 against symbol `._mcount' defined in .text section in arch/powerpc/kernel/entry_64.o: => (.text+0x1ff8994), (.text+0x1ff8740) + error: hns_dsaf_mac.c: relocation truncated to fit: R_PPC64_REL24 against symbol `.of_parse_phandle' defined in .text section in drivers/built-in.o: => (.text+0x1ff8a3c) + error: hns_dsaf_mac.c: relocation truncated to fit: R_PPC64_REL24 against symbol `_savegpr0_29' defined in .text.save.restore section in arch/powerpc/lib/built-in.o: => (.text+0x1ff872c) + error: hns_dsaf_mac.c: relocation truncated to fit: R_PPC64_REL24 against symbol `_savegpr0_30' defined in .text.save.restore section in arch/powerpc/lib/built-in.o: => (.text+0x1ff8984) + error: relocation truncated to fit: R_PPC64_REL24 against symbol `_savegpr0_29' defined in .text.save.restore section in arch/powerpc/lib/built-in.o: => (.text+0x1ff8560) + error: smp-shx3.c: undefined reference to `local_timer_setup': => .text+0xadec) 7 error improvements: - error: No rule to make target include/config/auto.conf: N/A => - error: hns_dsaf_xgmac.c: relocation truncated to fit: R_PPC64_REL24 against symbol `.udelay' defined in .text section in arch/powerpc/kernel/built-in.o: (.text+0x1ffb724), (.text+0x1ffb6e8), (.text+0x1ffb3e0), (.text+0x1ffb34c) => - error: hns_dsaf_xgmac.c: relocation truncated to fit: R_PPC64_REL24 against symbol `_restgpr0_30' defined in .text.save.restore section in arch/powerpc/lib/built-in.o: (.text+0x1ffaecc) => - error: hns_dsaf_xgmac.c: relocation truncated to fit: R_PPC64_REL24 against symbol `_savegpr0_27' defined in .text.save.restore section in arch/powerpc/lib/built-in.o: (.text+0x1ffb264) => - error: hns_dsaf_xgmac.c: relocation truncated to fit: R_PPC64_REL24 against symbol `_savegpr0_30' defined in .text.save.restore section in arch/powerpc/lib/built-in.o: (.text+0x1ffae7c) => - error: hns_enet.c: relocation truncated to fit: R_PPC64_REL24 against symbol `_restgpr0_30' defined in .text.save.restore section in arch/powerpc/lib/built-in.o: (.text+0x1ffba68) => - error: hns_enet.c: relocation truncated to fit: R_PPC64_REL24 against symbol `_savegpr0_30' defined in .text.save.restore section in arch/powerpc/lib/built-in.o: (.text+0x1ffba2c), (.text+0x1ffba70) => *** WARNINGS *** 164 warning regressions: + ./home/kisskb/slave/src/arch/sh/math-emu/math.c: warning: statement with no effect [-Wunused-value]: => 296:1 + /home/kisskb/slave/src/arch/arm/include/asm/irqflags.h: warning: 'flags' may be used uninitialized in this function [-Wuninitialized]: => 170:2 + /home/kisskb/slave/src/arch/ia64/sn/kernel/io_acpi_init.c: warning: unused variable 'addr' [-Wunused-variable]: => 429:16 + /home/kisskb/slave/src/arch/ia64/sn/kernel/io_init.c: warning: 'addr' may be used uninitialized in this function [-Wuninitialized]: => 189:19 + /home/kisskb/slave/src/arch/powerpc/boot/addnote.c: warning: right shift count >= width of type [enabled by default]: => 188:3, 206:3, 183:3, 211:3 + /home/kisskb/slave/src/arch/powerpc/net/bpf_jit_comp.c: warning: the frame size of 4416 bytes is larger than 2048 bytes [-Wframe-larger-than=]: => 552:1 + /home/kisskb/slave/s
Re: [PATCH 04/15] task_diag: add a new interface to get information about tasks (v4)
On Mon, Apr 11, 2016 at 04:35:44PM -0700, Andrey Vagin wrote:
...
> +static int __taskdiag_dumpit(struct task_iter *iter,
> + struct task_diag_cb *cb, struct task_struct
> **start)
> +{
> + struct user_namespace *userns = current_user_ns();
> + struct task_struct *task = *start;
> + int rc;
> +
> + for (; task; task = iter_next(iter)) {
> + if (!ptrace_may_access(task, PTRACE_MODE_READ_FSCREDS))
> + continue;
> +
> + rc = task_diag_fill(task, cb->resp, &iter->req,
> + cb, iter->ns, userns);
> + if (rc < 0) {
> + if (rc != -EMSGSIZE)
> + return rc;
> + break;
> + }
> + }
> + *start = task;
task = NULL always here?
> +
> + return 0;
> +}
Cyrill
Re: Build regressions/improvements in v4.6-rc3
On Tue, Apr 12, 2016 at 9:07 AM, Geert Uytterhoeven
wrote:
> JFYI, when comparing v4.6-rc3[1] to v4.6-rc2[3], the summaries are:
> - build errors: +5/-8
Nothing serious to report.
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 v5 1/4] leds: core: add generic support for RGB Color LED's
On 04/09/2016 06:01 PM, Pavel Machek wrote: Hi! What's tricky about patterns is that you need to control 3 (or more) leds at a time. Problem you are trying to solve here is ... control of 3 leds, at the same time. So let's solve them together. OK, now I've got your point. So we'd need to have a means for defining patterns. The interface could be located at /sys/class/leds/patterns. We'd need to have a flexible way for defining LED class devices involved in a pattern. Since we cannot guarantee no space in a LED class device name, then a single attribute containing space separated list is not an option. We'd have to create a predefined set of attributes that would contain LED class device name. Predefined implies that it would be a fixed number, i.e. either some attributes would always remain unused or, which is even worse, we could run out of free attributes for some use cases. There's a better solution: make pattern behave as a trigger for leds it controls. So we'd have /sys/class/leds/patterns/lp5523 then we'd have /sys/class/leds/lp5523::red/trigger = "lp5523:1" /sys/class/leds/lp5523::green/trigger = "lp5523:2" /sys/class/leds/lp5523::blue/trigger = "lp5523:3" (or something similar, I'd have to boot the n900 to see the exact names). How about implementing patterns as a specific typer of triggers? Let's say we have ledtrig-rgb-pattern: Well, we'd need ledtrig-rgb-pattern-1, ledtrig-rgb-pattern-2, ... , as we can have more than one rgb led. But yes. Triggers can have many listeners, i.e. led_trigger_event() sets brightness on all LED class devices registered on given trigger. We could have led_trigger_rgb_event() that would set brightness on all groups-of-three LEDs registered on given rgb-trigger. I agree that ledtrig-rgb-pattern-1, ledtrig-rgb-pattern-2, etc. would be also needed to add a capability of setting different colors on different LED devices. After setting a trigger following sysfs attribute would appear in a LED class device sysfs interface: $cat /sys/class/lp5523::red/rgb_color red green blue [none] $echo "red" > /sys/class/leds/lp5523::red/rgb_color and similarly $echo "green" > /sys/class/leds/lp5523::green/rgb_color $echo "blue" > /sys/class/leds/lp5523::blue/rgb_color Yes, that would work -- selecting channels from the pattern. Similar approach could be applied for blink patterns: There could be additional attributes provided for defining the position in a blink sequence, or/and blink period. For patterns, I'd suggest array of (r g b time) values. Pattern engines can do stuff like "slowly turn LED from off to red, then switch color to white, then slowly turn it to yellow, then turn it off at once" with defined speeds for "slowly" and option of either linear on non-linear brightness ramping. The last option might be a bit too much, but I believe we should support the rest. Yes, that's an interesting idea. It also turns out that trigger based patterns could be also used for defining generic patterns for a group of monochrome LEDs. -- Best regards, Jacek Anaszewski
Re: [PATCH] mfd: cros_ec: allow building for ARM64
On Mon, 11 Apr 2016, Javier Martinez Canillas wrote: > On 04/11/2016 12:42 PM, Brian Norris wrote: > > On Mon, Apr 11, 2016 at 09:48:49AM +0100, Lee Jones wrote: > >> When submitting patches, please use the format appropriate for the > >> subsystem. > >> > >> `git log --oneline -- ` helps with this. > > > > $ git log --oneline --no-merges drivers/mfd/cros_ec*.c | head -10 > > 8827a642a463 mfd: cros_ec_spi: Repair comparison ordering issue > > 2756db6c6366 mfd: cros_ec_i2c: Fix trivial 'tabs before spaces' > > whitespace issue. > > 6d6e44a95316 mfd: cros ec: Lock the SPI bus while holding chipselect > > 3821a065f567 spi: Drop owner assignment from spi_drivers > > 385c0012dfa0 mfd: cros_ec_i2c: Add OF match table > > a78ea195f77a mfd: cros_ec: spi: Add OF match table > > 0e777366fb0e mfd: Drop owner assignment from i2c_drivers > > cf649e00769a mfd: cros_ec: Staticise some newly introduced structures > > ff4378f4b813 mfd: cros_ec: spi: Add delay for asserting CS > > 57b33ff077be mfd: cros_ec: Support multiple EC in a system > > > > So...what's the problem with the subject? > > > > I also don't see what's wrong with the subject line... Then you're not looking hard enough. Every single patch description in the MFD subsystem starts with an uppercase character, just as you would any sentence. > >> Also please provide a commit log containing a short description of the > >> change. Are you enabling ARM64 becuase the driver is able to be used > >> on a new platform? If not, how did this work before? Etc. > > > > I can add a short description. But there's really not much more to it > > than the subject. We have ARM64 platforms we want to use this on. Some > > are already released, and some are in development. > > > > I think at least a short description is always welcomed. Even if the > patch is obvious, it should state why the change was introduced. +1 > >>> Signed-off-by: Brian Norris > >>> --- > >>> drivers/mfd/Kconfig | 2 +- > >>> 1 file changed, 1 insertion(+), 1 deletion(-) > >>> > >>> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig > >>> index eea61e349e26..1d63c5fb3f3c 100644 > >>> --- a/drivers/mfd/Kconfig > >>> +++ b/drivers/mfd/Kconfig > >>> @@ -134,7 +134,7 @@ config MFD_CROS_EC > >>> select MFD_CORE > >>> select CHROME_PLATFORMS > >>> select CROS_EC_PROTO > >>> - depends on X86 || ARM || COMPILE_TEST > >>> + depends on X86 || ARM || ARM64 || COMPILE_TEST > >>> help > >>> If you say Y here you get support for the ChromeOS Embedded > >>> Controller (EC) providing keyboard, battery and power services. > > Patch looks good to me, so after resending with a commit message: > > Reviewed-by: Javier Martinez Canillas > > Best regards, -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
[PATCH RT] tty: serial: 8250: don't take the trylock during oops
An oops with irqs off (panic() from irqsafe hrtimer like the watchdog timer) will lead to a lockdep warning on each invocation and as such never completes. Therefore we skip the trylock in the oops case. Signed-off-by: Sebastian Andrzej Siewior --- drivers/tty/serial/8250/8250_port.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c index 5568d70eee0c..138b1b985063 100644 --- a/drivers/tty/serial/8250/8250_port.c +++ b/drivers/tty/serial/8250/8250_port.c @@ -2850,9 +2850,9 @@ void serial8250_console_write(struct uart_8250_port *up, const char *s, serial8250_rpm_get(up); - if (port->sysrq) + if (port->sysrq || oops_in_progress) locked = 0; - else if (oops_in_progress || in_kdb_printk()) + else if (in_kdb_printk()) locked = spin_trylock_irqsave(&port->lock, flags); else spin_lock_irqsave(&port->lock, flags); -- 2.8.0.rc3
Re: [PATCH v2] mfd: cros_ec: allow building for ARM64
On Mon, 11 Apr 2016, Brian Norris wrote: > There are platforms using the ChromeOS embeded controller on ARM64 now, > so let's allow using this driver (without having to use COMPILE_TEST). > > Signed-off-by: Brian Norris > Reviewed-by: Javier Martinez Canillas > --- > v2: > * add Reviewed-by > * add short commit description > > drivers/mfd/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Fixed the subject line and applied, thanks. > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig > index eea61e349e26..1d63c5fb3f3c 100644 > --- a/drivers/mfd/Kconfig > +++ b/drivers/mfd/Kconfig > @@ -134,7 +134,7 @@ config MFD_CROS_EC > select MFD_CORE > select CHROME_PLATFORMS > select CROS_EC_PROTO > - depends on X86 || ARM || COMPILE_TEST > + depends on X86 || ARM || ARM64 || COMPILE_TEST > help > If you say Y here you get support for the ChromeOS Embedded > Controller (EC) providing keyboard, battery and power services. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
mmotm woes, mainly compaction
Michal, I'm sorry to say that I now find that I misinformed you.
You'll remember when we were chasing the order=2 OOMs on two of my
machines at the end of March (in private mail). And you sent me a
mail containing two patches, the second "Another thing to try ...
so this on top" doing a *migrate_mode++.
I answered you definitively that the first patch worked,
so "I haven't tried adding the one below at all".
Not true, I'm afraid. Although I had split the *migrate_mode++ one
off into a separate patch that I did not apply, I found looking back
today (when trying to work out why order=2 OOMs were still a problem
on mmotm 2016-04-06) that I never deleted that part from the end of
the first patch; so in fact what I'd been testing had included the
second; and now I find that _it_ was the effective solution.
Which is particularly sad because I think we were both a bit
uneasy about the *migrate_mode++ one: partly the style of it
incrementing the enum; but more seriously that it advances all the
way to MIGRATE_SYNC, when the first went only to MIGRATE_SYNC_LIGHT.
But without it, I am still stuck with the order=2 OOMs.
And worse: after establishing that that fixes the order=2 OOMs for
me on 4.6-rc2-mm1, I thought I'd better check that the three you
posted today (the 1/2 classzone_idx one, the 2/2 prevent looping
forever, and the "ction-abstract-compaction-feedback-to-helpers-fix";
but I'm too far behind to consider or try the RFC thp backoff one)
(a) did not surprisingly fix it on their own, and (b) worked well
with the *migrate_mode++ one added in.
(a) as you'd expect, they did not help on their own; and (b) they
worked fine together on the G5 (until it hit the powerpc swapping
sigsegv, which I think the powerpc guys are hoping is a figment of
my imagination); but (b) they did not work fine together on the
laptop, that combination now gives it order=1 OOMs. Despair.
And I'm sorry that it's taken me so long to report, but aside from
home distractions, I had quite a lot of troubles with 4.6-rc2-mm1 on
different machines, once I got down to trying it. But located Eric's
fix to an __inet_hash() crash in linux-next, and spotted Joonsoo's
setup_kmem_cache_node() slab bootup fix on lkml this morning.
With those out of the way, and forgetting the OOMs for now,
[PATCH mmotm] mm: fix several bugs in compaction
Fix three problems in the mmotm 2016-04-06-20-40 mm/compaction.c,
plus three minor tidyups there. Sorry, I'm now too tired to work
out which is a fix to what patch, and split them up appropriately:
better get these out quickly now.
1. Fix crash in release_pages() from compact_zone() from kcompactd_do_work():
kcompactd needs to INIT_LIST_HEAD on the new freepages_held list.
2. Fix crash in get_pfnblock_flags_mask() from suitable_migration_target()
from isolate_freepages(): there's a case when that "block_start_pfn -=
pageblock_nr_pages" loop can pass through 0 and end up trying to access
a pageblock before the start of the mem_map[]. (I have not worked out
why this never hit me before 4.6-rc2-mm1, it looks much older.)
3. /proc/sys/vm/stat_refresh warns nr_isolated_anon and nr_isolated_file
go increasingly negative under compaction: which would add delay when
should be none, or no delay when should delay. putback_movable_pages()
decrements the NR_ISOLATED counts which acct_isolated() increments,
so isolate_migratepages_block() needs to acct before putback in that
special case, and isolate_migratepages_range() can always do the acct
itself, leaving migratepages putback to caller like most other places.
4. Added VM_BUG_ONs to assert freepages_held is empty, matching those on
the other lists - though they're getting to look rather too much now.
5. It's easier to track the life of cc->migratepages if we don't assign
it to a migratelist variable.
6. Remove unused bool success from kcompactd_do_work().
Signed-off-by: Hugh Dickins
--- 4.6-rc2-mm1/mm/compaction.c 2016-04-10 09:43:20.314514944 -0700
+++ linux/mm/compaction.c 2016-04-11 11:35:08.536604712 -0700
@@ -638,7 +638,6 @@ isolate_migratepages_block(struct compac
{
struct zone *zone = cc->zone;
unsigned long nr_scanned = 0, nr_isolated = 0;
- struct list_head *migratelist = &cc->migratepages;
struct lruvec *lruvec;
unsigned long flags = 0;
bool locked = false;
@@ -817,7 +816,7 @@ isolate_migratepages_block(struct compac
del_page_from_lru_list(page, lruvec, page_lru(page));
isolate_success:
- list_add(&page->lru, migratelist);
+ list_add(&page->lru, &cc->migratepages);
cc->nr_migratepages++;
nr_isolated++;
@@ -851,9 +850,11 @@ isolate_fail:
spin_unlock_irqrestore(&zone->lru_lock, flags);
locked = false;
}
- putback_movable_pages(migratelist);
- nr_
Re: [PATCH v9 01/20] PM / devfreq: exynos: Add generic exynos bus frequency driver
On 04/11/2016 05:57 AM, Chanwoo Choi wrote: > This patch adds the generic exynos bus frequency driver for AMBA AXI bus > of sub-blocks in exynos SoC with DEVFREQ framework. The Samsung Exynos SoC > have the common architecture for bus between DRAM and sub-blocks in SoC. > This driver can support the generic bus frequency driver for Exynos SoCs. > > In devicetree, Each bus block has a bus clock, regulator, operation-point > and devfreq-event devices which measure the utilization of each bus block. > > Signed-off-by: Chanwoo Choi > [m.reichl and linux.amoon: Tested it on exynos4412-odroidu3 board] > Tested-by: Markus Reichl > Tested-by: Anand Moon > Signed-off-by: MyungJoo Ham > --- > drivers/devfreq/Kconfig | 15 ++ > drivers/devfreq/Makefile | 1 + > drivers/devfreq/exynos-bus.c | 443 > +++ > 3 files changed, 459 insertions(+) > create mode 100644 drivers/devfreq/exynos-bus.c Acked-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [PATCH 2/2] mm, oom, compaction: prevent from should_compact_retry looping for ever for costly orders
On 04/11/2016 08:45 AM, Michal Hocko wrote:
From: Michal Hocko
"mm: consider compaction feedback also for costly allocation" has
removed the upper bound for the reclaim/compaction retries based on the
number of reclaimed pages for costly orders. While this is desirable
the patch did miss a mis interaction between reclaim, compaction and the
retry logic. The direct reclaim tries to get zones over min watermark
while compaction backs off and returns COMPACT_SKIPPED when all zones
are below low watermark + 1<
It's probably worth testing whether low watermark makes sense there
instead of min watermark. I never noticed it myself, so thanks :)
shouldn't pull it into the generic retry logic while we should be able
to cope with such eventuality. The only place in should_compact_retry
where we retry without any upper bound is for compaction_withdrawn()
case.
Introduce compaction_zonelist_suitable function which checks the given
zonelist and returns true only if there is at least one zone which would
would unblock __compaction_suitable if more memory got reclaimed. In
this implementation it checks __compaction_suitable with NR_FREE_PAGES
plus part of the reclaimable memory as the target for the watermark check.
The reclaimable memory is reduced linearly by the allocation order. The
idea is that we do not want to reclaim all the remaining memory for a
single allocation request just unblock __compaction_suitable which
doesn't guarantee we will make a further progress.
The new helper is then used if compaction_withdrawn() feedback was
provided so we do not retry if there is no outlook for a further
progress. !costly requests shouldn't be affected much - e.g. order-2
pages would require to have at least 64kB on the reclaimable LRUs while
order-9 would need at least 32M which should be enough to not lock up.
Signed-off-by: Michal Hocko
It's a bit complicated, but I agree that something like this is needed
to prevent unexpected endless loops. Alternatively you could maybe just
extend compact_result to distinguish between COMPACT_SKIPPED (but
possible after reclaim) and COMPACT_IMPOSSIBLE (or some better name?).
Then compaction_withdrawn() would obviously be false for IMPOSSIBLE,
while compaction_failed() would be true? Then you shouldn't need
compaction_zonelist_suitable().
[...]
+bool compaction_zonelist_suitable(struct alloc_context *ac, int order,
+ int alloc_flags)
+{
+ struct zone *zone;
+ struct zoneref *z;
+
+ /*
+* Make sure at least one zone would pass __compaction_suitable if we
continue
+* retrying the reclaim.
+*/
+ for_each_zone_zonelist_nodemask(zone, z, ac->zonelist,
ac->classzone_idx,
I think here you should s/classzone_idx/high_zoneidx/
+ ac->nodemask) {
+ unsigned long available;
+ enum compact_result compact_result;
+
+ /*
+* Do not consider all the reclaimable memory because we do not
+* want to trash just for a single high order allocation which
+* is even not guaranteed to appear even if
__compaction_suitable
+* is happy about the watermark check.
+*/
+ available = zone_reclaimable_pages(zone) / order;
+ available += zone_page_state_snapshot(zone, NR_FREE_PAGES);
+ compact_result = __compaction_suitable(zone, order, alloc_flags,
+ ac->high_zoneidx, available);
And vice versa here.
Re: [PATCH v3] device property: don't bother the drivers with struct property_set
On Mon, 11 Apr 2016, Rafael J. Wysocki wrote: > On Mon, Apr 11, 2016 at 6:20 PM, Lee Jones wrote: > > On Mon, 11 Apr 2016, Rafael J. Wysocki wrote: > > > >> On Mon, Apr 11, 2016 at 4:05 PM, Lee Jones wrote: > >> > On Mon, 11 Apr 2016, Rafael J. Wysocki wrote: > >> > > >> >> On Mon, Apr 11, 2016 at 11:52 AM, Heikki Krogerus > >> >> wrote: > >> >> > On Mon, Apr 11, 2016 at 09:20:27AM +0100, Lee Jones wrote: > >> >> >> On Tue, 29 Mar 2016, Heikki Krogerus wrote: > >> >> >> > >> >> >> > Since device_add_property_set() now always takes a copy of > >> >> >> > the property_set, and also since the fwnode type is always > >> >> >> > hard coded to be FWNODE_PDATA, there is no need for the > >> >> >> > drivers to deliver the entire struct property_set. The > >> >> >> > function can just create the instance of it on its own and > >> >> >> > bind the properties from the drivers to it on the spot. > >> >> >> > > >> >> >> > This renames device_add_property_set() to > >> >> >> > device_add_properties(). The function now takes struct > >> >> >> > property_entry as its parameter instead of struct > >> >> >> > property_set. > >> >> >> > > >> >> >> > Reviewed-by: Andy Shevchenko > >> >> >> > Reviewed-by: Mika Westerberg > >> >> >> > Acked-by: Thierry Reding > >> >> >> > Acked-by: Lee Jones > >> >> >> > Signed-off-by: Heikki Krogerus > >> >> >> > --- > >> >> >> > arch/arm/mach-pxa/raumfeld.c | 12 > >> >> > > >> >> > Daniel, I think we just need your ACK for this one. > >> >> > > >> >> > Otherwise I think we are covered. > >> >> > > >> >> >> > arch/arm/mach-tegra/board-paz00.c | 6 +- > >> >> >> > drivers/base/platform.c | 19 ++- > >> >> >> > drivers/base/property.c | 34 > >> >> >> > +- > >> >> >> > drivers/mfd/intel-lpss-acpi.c | 12 ++-- > >> >> >> > drivers/mfd/intel-lpss-pci.c | 20 > >> >> >> > drivers/mfd/intel-lpss.c | 2 +- > >> >> >> > drivers/mfd/intel-lpss.h | 4 ++-- > >> >> >> > drivers/mfd/mfd-core.c| 4 ++-- > >> >> >> > include/linux/mfd/core.h | 4 ++-- > >> >> >> > include/linux/platform_device.h | 6 +++--- > >> >> >> > include/linux/property.h | 15 +++ > >> >> >> > 12 files changed, 55 insertions(+), 83 deletions(-) > >> >> >> > >> >> >> What's happening with this patch? I believe we're still missing > >> >> >> Acks. Once they are collected someone needs to create an immutable > >> >> >> branch and send out a pull-request. > >> >> > > >> >> > Rafael, have you had time to take a look at this? > >> >> > >> >> Yes, it's in my bleeding-edge branch now. I'm planning to move it to > >> >> linux-next this week > >> > > >> > Please ensure you send out the relevant pull-requests. Linus doesn't > >> > look his best when he's angry. > >> > >> I guess you mean I should expose by device-properties branch and > >> notify the relevant people about that, right? > > > > Exactly. And the easiest way to do that is by sending out a > > pull-request. > > I hoping that sending a message with the relevant information in a > reply to this one will be sufficient. Because of the nature of MFD, I end up doing this kind of thing a lot. Here's what I normally do. Normally in reply to the cover-letter (0/x): https://lkml.org/lkml/2015/8/12/138 -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v2 11/11] mm/slab: lockless decision to grow cache
On Tue, 12 Apr 2016 13:51:06 +0900 js1...@gmail.com wrote: > From: Joonsoo Kim > > To check whther free objects exist or not precisely, we need to grab a ^^ (spelling) > lock. But, accuracy isn't that important because race window would be > even small and if there is too much free object, cache reaper would reap > it. So, this patch makes the check for free object exisistence not to ^^^ (spelling) > hold a lock. This will reduce lock contention in heavily allocation case. > > Note that until now, n->shared can be freed during the processing by > writing slabinfo, but, with some trick in this patch, we can access it > freely within interrupt disabled period. > > Below is the result of concurrent allocation/free in slab allocation > benchmark made by Christoph a long time ago. I make the output simpler. > The number shows cycle count during alloc/free respectively so less is > better. I cannot figure out which if Christoph's tests you are using. And I even have a copy of his test here: https://github.com/netoptimizer/prototype-kernel/blob/master/kernel/mm/slab_test.c I think you need to describe the test a bit better... Looking a long time at the output on my own system, I guess you are showing results from the "Concurrent allocs". Then it would be relevant how many CPUs your system have. It would also be relevant to mention that N=1. And perhaps mention that it means, e.g all CPUs do N=1 alloc concurrently, synchronize before doing N free concurrently. > * Before > Kmalloc N*alloc N*free(32): Average=248/966 > Kmalloc N*alloc N*free(64): Average=261/949 > Kmalloc N*alloc N*free(128): Average=314/1016 > Kmalloc N*alloc N*free(256): Average=741/1061 > Kmalloc N*alloc N*free(512): Average=1246/1152 > Kmalloc N*alloc N*free(1024): Average=2437/1259 > Kmalloc N*alloc N*free(2048): Average=4980/1800 > Kmalloc N*alloc N*free(4096): Average=9000/2078 > > * After > Kmalloc N*alloc N*free(32): Average=344/792 > Kmalloc N*alloc N*free(64): Average=347/882 > Kmalloc N*alloc N*free(128): Average=390/959 > Kmalloc N*alloc N*free(256): Average=393/1067 > Kmalloc N*alloc N*free(512): Average=683/1229 > Kmalloc N*alloc N*free(1024): Average=1295/1325 > Kmalloc N*alloc N*free(2048): Average=2513/1664 > Kmalloc N*alloc N*free(4096): Average=4742/2172 > > It shows that allocation performance decreases for the object size up to > 128 and it may be due to extra checks in cache_alloc_refill(). But, with > considering improvement of free performance, net result looks the same. > Result for other size class looks very promising, roughly, 50% performance > improvement. Super nice performance boost. The numbers on my system are significantly smaller, but this is a before/after test and the absolute numbers are not that important. Oh, maybe this was because I ran the test with SLUB... recompiling with SLAB... and the results are comparable to your numbers (on my 8 core i7-4790K CPU @ 4.00GHz) -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat Author of http://www.iptv-analyzer.org LinkedIn: http://www.linkedin.com/in/brouer
Re: [PATCH v9 03/20] PM / devfreq: Add devfreq_get_devfreq_by_phandle()
On 04/11/2016 05:57 AM, Chanwoo Choi wrote:
> This patch adds the new devfreq_get_devfreq_by_phandle() OF helper function
> which can find the instance of devfreq device by using phandle ("devfreq").
>
> Signed-off-by: Chanwoo Choi
> Signed-off-by: MyungJoo Ham
> [m.reichl and linux.amoon: Tested it on exynos4412-odroidu3 board]
> Tested-by: Markus Reichl
> Tested-by: Anand Moon
> ---
> drivers/devfreq/devfreq.c | 44
> include/linux/devfreq.h | 9 +
> 2 files changed, 53 insertions(+)
>
Acked-by: Krzysztof Kozlowski
Best regards,
Krzysztof
Re: [PATCH v2 0/5] mailbox: A few fixes due for the v4.6 -rcs
On Wed, 23 Mar 2016, Lee Jones wrote: > Hi Jassi, > > Resending these with patches 1 and 2 merged, as requested. Jassi, Not heard anything from you in quite some time now. > Kind regards, > Lee > > v1 => v2: > - Patch 2 merged into patch > - No functional changes > > Lee Jones (5): > ARM: STi: stih407-family: Add nodes for Mailbox > ARM: STi: DT: STiH407: Enable Mailbox testing facility > mailbox: mailbox-test: Use more consistent format for calling > copy_from_user() > mailbox: mailbox-test: Prevent memory leak > mailbox: Stop using ENOSYS for anything other than unimplemented > syscalls > > arch/arm/boot/dts/stih407-family.dtsi | 39 > +++ > drivers/mailbox/mailbox-test.c| 16 +++--- > drivers/mailbox/mailbox.c | 4 ++-- > 3 files changed, 50 insertions(+), 9 deletions(-) > -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [RESEND 00/11] pwm: Add support for PWM Capture
On Wed, 02 Mar 2016, Lee Jones wrote: > The first part of this set extends the current PWM API to allow external > code to request a PWM Capture. Subsequent patches then make use of the > new API by providing a userspace offering via /sysfs. The final part of > the set supplies PWM Capture functionality into the already existing STi > PWM driver. > > This patch-set has been tested end to end via /sysfs. Hopefully you still have this set in your inbox. Please let me know if you wish me to resend it. > Lee Jones (11): > pwm: Add PWM Capture support > pwm: sysfs: Add PWM Capture support > pwm: sti: Reorganise register names in preparation for new > functionality > pwm: sti: Only request clock rate when you need to > pwm: sti: Supply PWM Capture register addresses and bit locations > pwm: sti: Supply PWM Capture clock handling > pwm: sti: Initialise PWM Capture channel data > pwm: sti: Add support for PWM Capture IRQs > pwm: sti: Add PWM Capture call-back > pwm: sti: Enable PWM Capture > pwm: sti: Take the opportunity to conduct a little house keeping > > drivers/pwm/core.c| 26 > drivers/pwm/pwm-sti.c | 384 > ++ > drivers/pwm/sysfs.c | 28 > include/linux/pwm.h | 13 ++ > 4 files changed, 392 insertions(+), 59 deletions(-) > -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
[PATCH] mtd: nand: s3c2410: fix bug in s3c2410_nand_correct_data()
From: Zhaoxiu Zeng If there is only one bit difference in the ECC, the function should return 1. The result of "diff0 & ~(1< --- drivers/mtd/nand/s3c2410.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/mtd/nand/s3c2410.c b/drivers/mtd/nand/s3c2410.c index 9c9397b..86ffb73 100644 --- a/drivers/mtd/nand/s3c2410.c +++ b/drivers/mtd/nand/s3c2410.c @@ -542,7 +542,8 @@ static int s3c2410_nand_correct_data(struct mtd_info *mtd, u_char *dat, diff0 |= (diff1 << 8); diff0 |= (diff2 << 16); - if ((diff0 & ~(1<
Re: [PATCH v2] module: fix noreturn attribute for __module_put_and_exit()
Jiri Kosina writes: > On Wed, 30 Mar 2016, Jiri Kosina wrote: > >> > __module_put_and_exit() is makred noreturn in module.h declaration, but is >> > lacking the attribute in the definition, which makes some tools (such as >> > sparse) unhappy. Amend the definition with the attribute as well (and >> > reformat the declaration so that it uses more common format). >> > >> > Signed-off-by: Jiri Kosina >> > --- >> > >> > v1 -> v2: use __noreturn instead of __attribute__((noreturn)) as requested >> > by Rusty >> >> Rusty, friendly ping on this one. > > Not seeing this in your tree, let me send another friendly ping :) Just pushed it into modules-next. Cheers, Rusty.
Re: [PATCH V4 0/7] Introduce ACPI world to ITS irqchip
Hi Marc, Bjorn, Rafael, Can you please have a look at this series? Thanks in advance. Tomasz On 04.04.2016 10:52, Tomasz Nowicki wrote: The following git branch contains submitted patches along with the useful patches from the test point of view (mainly ACPI ARM64 PCI support). https://github.com/semihalf-nowicki-tomasz/linux.git (its-acpi-v4) Series has been tested on Cavium ThunderX and Qualcomm QDF2xxx server. v3 -> v4 - rebased against v4.5 - add ACPI support for IRQ domain handling on a per-device basis - reorder domain setup step - improve error handling - code style improvements v2 -> v3 - rebased on top of 4.4 - fixes and improvements for redistributor init via GICC structures - fixes as per kbuild reports v1 -> v2 - rebased on top of 4.4-rc4 - use pci_msi_domain_get_msi_rid for requester ID to device ID translation Tomasz Nowicki (7): acpi, pci: Setup MSI domain on a per-devices basis. irqchip, GICv3, ITS: Cleanup for ITS domain initialization. irqchip, GICv3, ITS: Refator ITS DT init code to prepare for ACPI. ARM64, ACPI, PCI: I/O Remapping Table (IORT) initial support. irqchip, gicv3, its: Probe ITS in the ACPI way. its, pci, msi: Factor out code that might be reused for ACPI. acpi, gicv3, its: Use MADT ITS subtable to do PCI/MSI domain initialization. drivers/acpi/Kconfig | 3 + drivers/acpi/Makefile| 1 + drivers/acpi/iort.c | 335 +++ drivers/irqchip/Kconfig | 1 + drivers/irqchip/irq-gic-v3-its-pci-msi.c | 87 ++-- drivers/irqchip/irq-gic-v3-its.c | 188 - drivers/irqchip/irq-gic-v3.c | 7 +- drivers/pci/msi.c| 10 +- drivers/pci/pci-acpi.c | 77 +++ include/linux/iort.h | 31 +++ include/linux/irqchip/arm-gic-v3.h | 2 +- include/linux/pci.h | 11 + 12 files changed, 678 insertions(+), 75 deletions(-) create mode 100644 drivers/acpi/iort.c create mode 100644 include/linux/iort.h
Re: [PATCH] drm: rcar-du: Only unwindow as necessary on probe failure
Hi Sjoerd,
On Wed, Apr 6, 2016 at 11:45 AM, Sjoerd Simons
wrote:
> Simply calling rcar_du_remove on any error can cause unbalanced calls to
> various functions (e.g. drm_connector_register/unregister,
> drm_dev_register/drm_dev_unref).
>
> This can be seen at bootup of my Porter boards with current next:
>
> [2.789322] rcar-du feb0.display: failed to initialize DRM/KMS (-517)
> [2.796267] [ cut here ]
> [2.800996] WARNING: CPU: 1 PID: 1 at include/drm/drm_crtc.h:2623
> drm_connector_unregister_all+0x60/0x68
> [2.810689] CPU: 1 PID: 1 Comm: swapper/0 Not tainted
> 4.6.0-rc2-next-20160405-dirty #11
> [2.818864] Hardware name: Generic R8A7791 (Flattened Device Tree)
> [2.825174] Backtrace:
> [2.827699] [] (dump_backtrace) from []
> (show_stack+0x18/0x1c)
> [2.835430] r7:c042da78 r6:0009 r5:6013 r4:
> [2.841251] [] (show_stack) from []
> (dump_stack+0x84/0xa4)
> [2.848632] [] (dump_stack) from [] (__warn+0xd0/0x100)
> [2.855739] r5: r4:
> [2.859409] [] (__warn) from []
> (warn_slowpath_null+0x28/0x30)
> [2.867139] r9:0001 r8:ef1dc610 r7:ef114010 r6:ef1dc600 r5:ef114010
> r4:ef2f2400
> [2.875096] [] (warn_slowpath_null) from []
> (drm_connector_unregister_all+0x60/0x68)
> [2.884785] [] (drm_connector_unregister_all) from []
> (rcar_du_remove+0x1c/0x5c)
> [2.894111] r5:ef114010 r4:ef2f2400
> [2.897780] [] (rcar_du_remove) from []
> (rcar_du_probe+0x1d0/0x210)
> [2.905953] r5:ef2f2400 r4:fdfb
> [2.909625] [] (rcar_du_probe) from []
> (platform_drv_probe+0x58/0xa8)
> [2.917976] r9: r8:c0a1cca4 r7:c0a71a48 r6:c0a1cca4 r5:ef1dc610
> r4:c0440b80
>
> Adjust the code to only unwind as necessary on probe failures
>
> Signed-off-by: Sjoerd Simons
Thanks!
I can confirm your patch fixes the same warning on r8a7791/koelsch, so
I'll include it in today's renesas-drivers release.
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] ARM: dts: ls1021a: add SCFG MSI dts node
On Wed, Apr 06, 2016 at 07:02:07PM +0800, Minghuan Lian wrote: > Add SCFG MSI dts node and add msi-parent property to PCIe dts node > that points to the corresponding MSI node. > > Signed-off-by: Minghuan Lian Applied, thanks.
Re: [PATCH v3 02/16] mm/compaction: support non-lru movable page migration
On 2016년 03월 30일 16:12, Minchan Kim wrote:
We have allowed migration for only LRU pages until now and it was
enough to make high-order pages. But recently, embedded system(e.g.,
webOS, android) uses lots of non-movable pages(e.g., zram, GPU memory)
so we have seen several reports about troubles of small high-order
allocation. For fixing the problem, there were several efforts
(e,g,. enhance compaction algorithm, SLUB fallback to 0-order page,
reserved memory, vmalloc and so on) but if there are lots of
non-movable pages in system, their solutions are void in the long run.
So, this patch is to support facility to change non-movable pages
with movable. For the feature, this patch introduces functions related
to migration to address_space_operations as well as some page flags.
Basically, this patch supports two page-flags and two functions related
to page migration. The flag and page->mapping stability are protected
by PG_lock.
PG_movable
PG_isolated
bool (*isolate_page) (struct page *, isolate_mode_t);
void (*putback_page) (struct page *);
Duty of subsystem want to make their pages as migratable are
as follows:
1. It should register address_space to page->mapping then mark
the page as PG_movable via __SetPageMovable.
2. It should mark the page as PG_isolated via SetPageIsolated
if isolation is sucessful and return true.
3. If migration is successful, it should clear PG_isolated and
PG_movable of the page for free preparation then release the
reference of the page to free.
4. If migration fails, putback function of subsystem should
clear PG_isolated via ClearPageIsolated.
5. If a subsystem want to release isolated page, it should
clear PG_isolated but not PG_movable. Instead, VM will do it.
Cc: Vlastimil Babka
Cc: Mel Gorman
Cc: Hugh Dickins
Cc: dri-de...@lists.freedesktop.org
Cc: virtualizat...@lists.linux-foundation.org
Signed-off-by: Gioh Kim
Signed-off-by: Minchan Kim
---
Documentation/filesystems/Locking | 4 +
Documentation/filesystems/vfs.txt | 5 +
fs/proc/page.c | 3 +
include/linux/fs.h | 2 +
include/linux/migrate.h| 2 +
include/linux/page-flags.h | 31 ++
include/uapi/linux/kernel-page-flags.h | 1 +
mm/compaction.c| 14 ++-
mm/migrate.c | 174 +
9 files changed, 217 insertions(+), 19 deletions(-)
diff --git a/Documentation/filesystems/Locking
b/Documentation/filesystems/Locking
index 619af9bfdcb3..0bb79560abb3 100644
--- a/Documentation/filesystems/Locking
+++ b/Documentation/filesystems/Locking
@@ -195,7 +195,9 @@ unlocks and drops the reference.
int (*releasepage) (struct page *, int);
void (*freepage)(struct page *);
int (*direct_IO)(struct kiocb *, struct iov_iter *iter, loff_t offset);
+ bool (*isolate_page) (struct page *, isolate_mode_t);
int (*migratepage)(struct address_space *, struct page *, struct page
*);
+ void (*putback_page) (struct page *);
int (*launder_page)(struct page *);
int (*is_partially_uptodate)(struct page *, unsigned long, unsigned
long);
int (*error_remove_page)(struct address_space *, struct page *);
@@ -219,7 +221,9 @@ invalidatepage: yes
releasepage: yes
freepage: yes
direct_IO:
+isolate_page: yes
migratepage: yes (both)
+putback_page: yes
launder_page: yes
is_partially_uptodate:yes
error_remove_page:yes
diff --git a/Documentation/filesystems/vfs.txt
b/Documentation/filesystems/vfs.txt
index b02a7d598258..4c1b6c3b4bc8 100644
--- a/Documentation/filesystems/vfs.txt
+++ b/Documentation/filesystems/vfs.txt
@@ -592,9 +592,14 @@ struct address_space_operations {
int (*releasepage) (struct page *, int);
void (*freepage)(struct page *);
ssize_t (*direct_IO)(struct kiocb *, struct iov_iter *iter, loff_t
offset);
+ /* isolate a page for migration */
+ bool (*isolate_page) (struct page *, isolate_mode_t);
/* migrate the contents of a page to the specified target */
int (*migratepage) (struct page *, struct page *);
+ /* put the page back to right list */
+ void (*putback_page) (struct page *);
int (*launder_page) (struct page *);
+
int (*is_partially_uptodate) (struct page *, unsigned long,
unsigned long);
void (*is_dirty_writeback) (struct page *, bool *, bool *);
diff --git a/fs/proc/page.c b/fs/proc/page.c
index 3ecd445e830d..ce3d08a4ad8d 100644
--- a/fs/proc/page.c
+++ b/fs/proc/page.c
@@ -157,6 +157,9 @@ u64 stable_page_flags(struct page *page)
if (page_is_idle(page))
u |= 1 << KPF_IDLE;
+ if (PageMovable(page))
+ u |= 1 << KPF_MOVABLE;
+
u |= kpf_copy_bit(k, KPF_LOCKED,PG_locked)
Re: [lkp] [x86, ACPI, cpu] f962c29c2f: BUG: unable to handle kernel paging request at 0000000000001b00
Hi Rafael,
On 04/06/2016 11:21 PM, Rafael J. Wysocki wrote:
On 4/6/2016 2:43 AM, kernel test robot wrote:
FYI, we noticed the below changes on
https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git
linux-next
commit f962c29c2f5d80be28bd76e2c3fadf1ce97ccd76 ("x86, ACPI,
cpu-hotplug: Set persistent cpuid <-> nodeid mapping when booting")
Thanks for the report.
I've dropped the patch series that commit is part of from the
linux-next branch of linux-pm.git because of this problem.
I tried to reproduce this failure, but I failed.
I compiled linux-next branch source code of linux-pm.git with this
config, then I
used qemu to boot a guest with my compiled kernel, it worked well.
QEMU command line is:
./x86_64-softmmu/qemu-system-x86_64 -hda /home/fedora21.img \
-kernel /home/linux-pm/arch/x86_64/boot/bzImage \
-m 512,slots=100,maxmem=100G -smp 2,maxcpus=100 -serial stdio -enable-kvm \
-initrd /home/initramfs-4.6.0-rc2-00250-g8767898.img -append
"root=/dev/sda3 console=ttyS0
Anyone succeed?
Thanks,
Zhu
+--+++
| | 40d4d2e6c5 | f962c29c2f |
+--+++
| boot_successes | 12 | 4 |
| boot_failures| 0 | 8 |
| BUG:unable_to_handle_kernel | 0 | 8 |
| Oops | 0 | 8 |
| RIP:__alloc_pages_nodemask | 0 | 8 |
| Kernel_panic-not_syncing:Fatal_exception | 0 | 8 |
| backtrace:pcpu_balance_workfn| 0 | 8 |
+--+++
[ 10.413471] RAPL PMU: hw unit of domain pp0-core 2^-16 Joules
[ 10.419886] RAPL PMU: hw unit of domain package 2^-16 Joules
[ 10.426206] RAPL PMU: hw unit of domain dram 2^-16 Joules
[ 10.433905] BUG: unable to handle kernel paging request at
1b00
[ 10.441699] IP: []
__alloc_pages_nodemask+0x210/0xc10
[ 10.449097] PGD 0
[ 10.451350] Oops: [#1] SMP
[ 10.454972] Modules linked in:
[ 10.458390] CPU: 12 PID: 407 Comm: kworker/12:1 Not tainted
4.6.0-rc1-7-gf962c29 #1
[ 10.467326] Hardware name: Intel Corporation S2600WP/S2600WP, BIOS
SE5C600.86B.02.02.0002.122320131210 12/23/2013
[ 10.478776] Workqueue: events pcpu_balance_workfn
[ 10.484035] task: 88100d858000 ti: 88100d86 task.ti:
88100d86
[ 10.492381] RIP: 0010:[] []
__alloc_pages_nodemask+0x210/0xc10
[ 10.502491] RSP: :88100d863c28 EFLAGS: 00010286
[ 10.508419] RAX: RBX: RCX:
0004
[ 10.516383] RDX: 8000 RSI: 0d06 RDI:
81c9d430
[ 10.524348] RBP: 88100d863d40 R08: R09:
[ 10.532312] R10: 81ca1e87 R11: c9076000 R12:
0003
[ 10.540278] R13: 1b00 R14: R15:
88100d43e480
[ 10.548243] FS: () GS:88101340()
knlGS:
[ 10.557275] CS: 0010 DS: ES: CR0: 80050033
[ 10.563687] CR2: 1b00 CR3: 00103ee06000 CR4:
001406e0
[ 10.571652] Stack:
[ 10.573894] c9090fff c9091000 881013002008
0001
[ 10.582196] 8163 024082c2
0040
[ 10.590492] 001e 880ffe57c0c0 88100d863c88
811b7766
[ 10.598794] Call Trace:
[ 10.601527] [] ? map_vm_area+0x36/0x50
[ 10.607553] [] pcpu_populate_chunk+0xae/0x340
[ 10.614257] [] pcpu_balance_workfn+0x578/0x5b0
[ 10.621060] [] process_one_work+0x155/0x440
[ 10.627562] [] worker_thread+0x4e/0x4c0
[ 10.633687] [] ? __schedule+0x34b/0x8b0
[ 10.639809] [] ? rescuer_thread+0x350/0x350
[ 10.646319] [] ? rescuer_thread+0x350/0x350
[ 10.652831] [] kthread+0xd4/0xf0
[ 10.658276] [] ret_from_fork+0x22/0x40
[ 10.664302] [] ? kthread_park+0x60/0x60
[ 10.670423] Code: d0 49 8b 04 24 48 85 c0 75 e0 65 ff 0d 22 f0 e8
7e eb 8b 31 d2 be 06 0d 00 00 48 c7 c7 30 d4 c9 81 e8 35 2c f2 ff e8
50 40 77 00 <49> 83 7d 00 00 0f 85 7c fe ff ff 31 c0 e9 6d ff ff ff
0f 1f 44
[ 10.692137] RIP []
__alloc_pages_nodemask+0x210/0xc10
[ 10.699627] RSP
[ 10.703518] CR2: 1b00
[ 10.707220] ---[ end trace bc83ef9ded88f808 ]---
[ 10.712373] Kernel panic - not syncing: Fatal exception
Thanks,
Kernel Test Robot
.
Re: [PATCH v6 07/10] usb: dwc3: gadget: Fix suspend/resume during dual-role mode
Hi, Roger Quadros writes: > On 11/04/16 16:26, Felipe Balbi wrote: >> >> Hi, >> >> Roger Quadros writes: >>> On 11/04/16 15:23, Felipe Balbi wrote: Hi, Roger Quadros writes: > Gadget controller might not be always active during suspend/ > resume when we are operating in dual-role/otg mode. > Check if we're active and only if we are then perform > necessary actions during suspend/resume. I don't get this. If we're operating in OTG, we should have a gadget driver loaded, no ? >>> At boot gadget driver is not automatically loaded. We're still in OTG mode >>> but OTG state machine hasn't started. >>> System suspend/resume can still happen. >>> >>> User might also load/unload the gadget driver prior to system suspend. >> >> good point, this should go in the -rc too. >> > But there is no dual-role mode currently so it won't fix any bug yet :). this should be a problem even for device-only, right ? i) boot-up ii) modprobe dwc3 iii) echo mem > /sys/power/state -- balbi signature.asc Description: PGP signature
Re: mmotm woes, mainly compaction
On 04/12/2016 09:18 AM, Hugh Dickins wrote: > 2. Fix crash in get_pfnblock_flags_mask() from suitable_migration_target() > from isolate_freepages(): there's a case when that "block_start_pfn -= > pageblock_nr_pages" loop can pass through 0 and end up trying to access > a pageblock before the start of the mem_map[]. (I have not worked out > why this never hit me before 4.6-rc2-mm1, it looks much older.) This is actually my fresh mmotm bug, thanks for catching that! Fix for: mm-compaction-wrap-calculating-first-and-last-pfn-of-pageblock.patch 8< >From 45330dfb350d6b3bc72bcdaccc226bcc286e1236 Mon Sep 17 00:00:00 2001 From: Vlastimil Babka Date: Tue, 12 Apr 2016 09:54:33 +0200 Subject: [PATCH] mm, compaction: fix crash in get_pfnblock_flags_mask() from isolate_freepages(): In isolate_freepages(), low_pfn was mistakenly initialized to pageblock_start_pfn() instead of pageblock_end_pfn(), creating a possible underflow, as described by Hugh: There's a case when that "block_start_pfn -= pageblock_nr_pages" loop can pass through 0 and end up trying to access a pageblock before the start of the mem_map[]. Reported-by: Hugh Dickins Signed-off-by: Vlastimil Babka --- mm/compaction.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/compaction.c b/mm/compaction.c index 315e5d57e7e9..67f886ecd773 100644 --- a/mm/compaction.c +++ b/mm/compaction.c @@ -1012,7 +1012,7 @@ static void isolate_freepages(struct compact_control *cc) block_start_pfn = pageblock_start_pfn(cc->free_pfn); block_end_pfn = min(block_start_pfn + pageblock_nr_pages, zone_end_pfn(zone)); - low_pfn = pageblock_start_pfn(cc->migrate_pfn); + low_pfn = pageblock_end_pfn(cc->migrate_pfn); /* * Isolate free pages until enough are available to migrate the -- 2.8.1
Re: [PATCH v6 5/5] x86, acpi, cpu-hotplug: Set persistent cpuid <-> nodeid mapping when booting.
Hi Lorenzo,
Thanks for your test and detailed suggestions.
I will update those later.
Thanks,
Zhu
On 04/06/2016 10:29 PM, Lorenzo Pieralisi wrote:
[+Dennis since he reported ARM64 build breakage]
On Thu, Mar 17, 2016 at 09:32:40AM +0800, Zhu Guihua wrote:
From: Gu Zheng
The whole patch-set aims at making cpuid <-> nodeid mapping persistent. So that,
when node online/offline happens, cache based on cpuid <-> nodeid mapping such
as
wq_numa_possible_cpumask will not cause any problem.
It contains 4 steps:
1. Enable apic registeration flow to handle both enabled and disabled cpus.
2. Introduce a new array storing all possible cpuid <-> apicid mapping.
3. Enable _MAT and MADT relative apis to return non-presnet or disabled cpus'
apicid.
4. Establish all possible cpuid <-> nodeid mapping.
This patch finishes step 4.
And it breaks the build on ARM64.
drivers/acpi/processor_core.c: In function 'set_processor_node_mapping':
drivers/acpi/processor_core.c:316:2: error: implicit declaration of
function 'acpi_map_cpu2node' [-Werror=implicit-function-declaration]
[...]
diff --git a/arch/ia64/kernel/acpi.c b/arch/ia64/kernel/acpi.c
index b1698bc..7db5563 100644
--- a/arch/ia64/kernel/acpi.c
+++ b/arch/ia64/kernel/acpi.c
@@ -796,7 +796,7 @@ int acpi_isa_irq_to_gsi(unsigned isa_irq, u32 *gsi)
* ACPI based hotplug CPU support
*/
#ifdef CONFIG_ACPI_HOTPLUG_CPU
-static int acpi_map_cpu2node(acpi_handle handle, int cpu, int physid)
+int acpi_map_cpu2node(acpi_handle handle, int cpu, int physid)
Return value seems to be ignored on IA64 so you can get rid of it,
see below.
{
#ifdef CONFIG_ACPI_NUMA
/*
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 0ce06ee..7d45261 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -696,7 +696,7 @@ static void __init acpi_set_irq_model_ioapic(void)
#ifdef CONFIG_ACPI_HOTPLUG_CPU
#include
-static void acpi_map_cpu2node(acpi_handle handle, int cpu, int physid)
+void acpi_map_cpu2node(acpi_handle handle, int cpu, int physid)
{
#ifdef CONFIG_ACPI_NUMA
int nid;
diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 0e85678..215177a 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -1110,6 +1110,9 @@ static int __init acpi_init(void)
acpi_sleep_proc_init();
acpi_wakeup_device_init();
acpi_debugger_init();
+#ifdef CONFIG_ACPI_HOTPLUG_CPU
+ acpi_set_processor_mapping();
+#endif
return 0;
}
diff --git a/drivers/acpi/processor_core.c b/drivers/acpi/processor_core.c
index 824b98b..45580ff 100644
--- a/drivers/acpi/processor_core.c
+++ b/drivers/acpi/processor_core.c
@@ -261,6 +261,71 @@ int acpi_get_cpuid(acpi_handle handle, int type, u32
acpi_id)
}
EXPORT_SYMBOL_GPL(acpi_get_cpuid);
+#ifdef CONFIG_ACPI_HOTPLUG_CPU
+static bool map_processor(acpi_handle handle, int *phys_id, int *cpuid)
phys_id size is 64 bits (phys_cpuid_t) on ARM64, (phys_cpuid_t *phys_id) is
what you have to have here.
+{
+ int type;
+ u32 acpi_id;
+ acpi_status status;
+ acpi_object_type acpi_type;
+ unsigned long long tmp;
+ union acpi_object object = { 0 };
+ struct acpi_buffer buffer = { sizeof(union acpi_object), &object };
+
+ status = acpi_get_type(handle, &acpi_type);
+ if (ACPI_FAILURE(status))
+ return false;
+
+ switch (acpi_type) {
+ case ACPI_TYPE_PROCESSOR:
+ status = acpi_evaluate_object(handle, NULL, NULL, &buffer);
+ if (ACPI_FAILURE(status))
+ return false;
+ acpi_id = object.processor.proc_id;
+ break;
+ case ACPI_TYPE_DEVICE:
+ status = acpi_evaluate_integer(handle, "_UID", NULL, &tmp);
+ if (ACPI_FAILURE(status))
+ return false;
+ acpi_id = tmp;
+ break;
+ default:
+ return false;
+ }
+
+ type = (acpi_type == ACPI_TYPE_DEVICE) ? 1 : 0;
+
+ *phys_id = __acpi_get_phys_id(handle, type, acpi_id, false);
Wrong on ARM64, see above.
+ *cpuid = acpi_map_cpuid(*phys_id, acpi_id);
+ if (*cpuid == -1)
+ return false;
+
+ return true;
+}
+
+static acpi_status __init
+set_processor_node_mapping(acpi_handle handle, u32 lvl, void *context,
+ void **rv)
+{
+ u32 apic_id;
- You can't use u32 here see above
- This is generic code and on ARM64 I have no idea what apic_id means,
choose another variable name please (phys_id ?)
+ int cpu_id;
+
+ if (!map_processor(handle, &apic_id, &cpu_id))
+ return AE_ERROR;
+
+ acpi_map_cpu2node(handle, cpu_id, apic_id);
+ return AE_OK;
+}
+
+void __init acpi_set_processor_mapping(void)
+{
+ /* Set persistent cpu <-> node mapping for all processors. */
+ acpi_walk_namespace(ACPI_TYPE_PROCESSOR, ACPI_ROOT_OBJECT,
+
Re: [PATCH v2 0/5] mailbox: A few fixes due for the v4.6 -rcs
On Tue, Apr 12, 2016 at 12:57 PM, Lee Jones wrote: > On Wed, 23 Mar 2016, Lee Jones wrote: > >> Hi Jassi, >> >> Resending these with patches 1 and 2 merged, as requested. > > Jassi, > > Not heard anything from you in quite some time now. > Please feel free to call as soon as it goes beyond 2weeks. Patch-1 & 2 should not go via mailbox tree, as you know. 3,4&5 have been picked. Thanks.
RE: [PATCH] usb: dwc3: free dwc->regset on dwc3_debugfs_exit
Hi, "Du, Changbin" writes: > Hi, Balbi, > >> > Hmm, I agree from this point. I will combine this patch with other two >> patches >> > (due to their dependency). And I'd like remove the 'dwc->root=NULL' as >> well, >> >> you are creating a dependency that doesn't exist. Please stop that. You >> should have two separate branches based on v4.6-rc3 (or, if you prefer, >> one based on my testing/fixes and another based on my testing/next). On >> one branch you have *only* $subject and you fix *all* the memory >> leaks. On the other branch you have the other two patches. >> >> Ignore the fact that we might have a conflict, that's for git (and >> maintainers) to handle when they happen. >> >> Again, don't create dependencies between fixes for the -rc cycle and >> changes for the next merge window. >> > Thanks for dedicated explanation. I was concern about the conflict. yeah, no problem ;-) > Now it is very clear for me to handle such situation. good :-) glad we could sort it out. -- balbi signature.asc Description: PGP signature
Re: [PATCH 1/7] PM / devfreq: event: Add new Exynos NoC probe driver
On 04/08/2016 07:00 AM, Chanwoo Choi wrote:
> This patch adds NoC (Network on Chip) Probe driver which provides
> the primitive values to get the performance data. The packets that the Network
> on Chip (NoC) probes detects are transported over the network infrastructure.
> Exynos542x bus has multiple NoC probes to provide bandwidth information about
> behavior of the SoC that you can use while analyzing system performance.
>
> Signed-off-by: Chanwoo Choi
> ---
> .../bindings/devfreq/event/exynos-nocp.txt | 86 +++
> drivers/devfreq/event/Kconfig | 8 +
> drivers/devfreq/event/Makefile | 2 +
> drivers/devfreq/event/exynos-nocp.c| 247
> +
> drivers/devfreq/event/exynos-nocp.h| 78 +++
> 5 files changed, 421 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/devfreq/event/exynos-nocp.txt
> create mode 100644 drivers/devfreq/event/exynos-nocp.c
> create mode 100644 drivers/devfreq/event/exynos-nocp.h
>
> diff --git a/Documentation/devicetree/bindings/devfreq/event/exynos-nocp.txt
> b/Documentation/devicetree/bindings/devfreq/event/exynos-nocp.txt
> new file mode 100644
> index ..03b74fed034c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/devfreq/event/exynos-nocp.txt
> @@ -0,0 +1,86 @@
> +
> +* Samsung Exynos NoC (Network on Chip) Probe device
> +
> +The Samsung Exynos542x SoC has NoC (Network on Chip) Probe for NoC bus.
> +NoC provides the primitive values to get the performance data. The packets
> +that the Network on Chip (NoC) probes detects are transported over
> +the network infrastructure to observer units. You can configure probes to
> +capture packets with header or data on the data request response network,
> +or as traffic debug or statistic collectors. Exynos542x bus has multiple
> +NoC probes to provide bandwidth information about behavior of the SoC
> +that you can use while analyzing system performance.
> +
> +Required properties:
> +- compatible: Should be "samsung,exynos5420-nocp"
> +- reg: physical base address of each NoC Probe and length of memory mapped
> region.
> +
> +Optional properties:
> +- clock-names : the name of clock used by the NoC Probe, "nocp"
> +- clocks : phandles for clock specified in "clock-names" property
> +
> +Example1 : NoC Probe nodes in exynos5420.dtsi are listed below.
> +
> + nocp_mem0_0: nocp_mem0_0@10CA1000 {
> + compatible = "samsung,exynos5420-nocp";
> + reg = <0x10CA1000 0x200>;
> + status = "disabled";
> + };
> +
> + nocp_mem0_1: nocp_mem0_1@10CA1400 {
> + compatible = "samsung,exynos5420-nocp";
> + reg = <0x10CA1400 0x200>;
> + status = "disabled";
> + };
> +
> + nocp_mem0_2: nocp_mem0_2@10CA1800 {
> + compatible = "samsung,exynos5420-nocp";
> + reg = <0x10CA1800 0x200>;
> + status = "disabled";
> + };
> +
> + nocp_mem0_3: nocp_mem0_0@10CA1C00 {
> + compatible = "samsung,exynos5420-nocp";
> + reg = <0x10CA1C00 0x200>;
> + status = "disabled";
> + };
> +
> + nocp_g3d_0: nocp_g3d_0@11A51000 {
> + compatible = "samsung,exynos5420-nocp";
> + reg = <0x11A51000 0x200>;
> + status = "disabled";
> + };
> +
> + nocp_g3d_1: nocp_g3d_1@11A51400 {
> + compatible = "samsung,exynos5420-nocp";
> + reg = <0x11A51400 0x200>;
> + status = "disabled";
> + };
> +
> +
> +Example2 : Events of each NoC Probe node in exynos5422-odroidxu3-common.dtsi
> + are listed below.
> +
> +
> + &nocp_mem0_0 {
> + status = "okay";
> + };
> +
> + &nocp_mem0_1 {
> + status = "okay";
> + };
> +
> + &nocp_mem0_2 {
> + status = "okay";
> + };
> +
> + &nocp_mem0_3 {
> + status = "okay";
> + };
> +
> + &nocp_g3d_0 {
> + status = "okay";
> + };
> +
> + &nocp_g3d_1 {
> + status = "okay";
> + };
I think this split in documentation between DTSI and DTS is not needed
for example. Just add one example without the status and it should be
sufficient to get the idea.
> diff --git a/drivers/devfreq/event/Kconfig b/drivers/devfreq/event/Kconfig
> index a11720affc31..1e8b4f469f38 100644
> --- a/drivers/devfreq/event/Kconfig
> +++ b/drivers/devfreq/event/Kconfig
> @@ -13,6 +13,14 @@ menuconfig PM_DEVFREQ_EVENT
>
> if PM_DEVFREQ_EVENT
>
> +config DEVFREQ_EVENT_EXYNOS_NOCP
> + bool "EXYNOS NoC (Network On Chip) Probe DEVFREQ event Driver"
> + depends on ARCH_EXYNOS
> + select PM_OPP
> + help
> + This add the devfreq-event driver for Exynos SoC. It provides NoC
> + (Network on Chip) Probe counters to measure the bandwidth of AXI bus.
> +
> config DEVFREQ_EVENT_EXYNOS_PPMU
> bool "EXYNOS PPMU (Platform Performance Monitoring U
Re: [PATCH v9 06/20] PM / devfreq: exynos: Add support of bus frequency of sub-blocks using passive governor
On 04/11/2016 05:57 AM, Chanwoo Choi wrote: > This patch adds the support of bus frequency feature for sub-blocks which > share > the one power line. If each bus depends on the power line, each bus is not > able > to change the voltage by oneself. To optimize the power-consumption on > runtime, > some buses using the same power line should change the source clock and > regulator at the same time. So, this patch uses the passive governor to > support > the bus frequency for all buses which sharing the one power line. > > For example, > > Exynos3250 include the two power line for AXI buses as following: > : VDD_MIF : MIF (Memory Interface) provide the DMC (Dynamic Memory Controller) > with the power (regulator). > : VDD_INT : INT (Internal) provide the various sub-blocks with the power > (regulator). > > Each bus is included in as follwoing block. In the case of VDD_MIF, only DMC > bus > use the power line. So, there is no any depencency between buese. But, in the > case of VDD_INT, various buses share the one power line of VDD_INT. We need to > make the depenency between buses. When using passive governor, there is no > problem to support the bus frequency as DVFS for all buses. One bus should be > operated as the parent bus device which gathering the current load of INT > block > and then decides the new frequency with some governors except of passive > governor. After deciding the new frequency by the parent bus device, the rest > bus devices will change the each source clock according to new frequency of > the > parent bus device. > > - MIF (Memory Interface) block > : VDD_MIF |--- DMC > > - INT (Internal) block > : VDD_INT |--- LEFTBUS (parent) > |--- PERIL > |--- MFC > |--- G3D > |--- RIGHTBUS > |--- FSYS > |--- LCD0 > |--- PERIR > |--- ISP > |--- CAM > > Signed-off-by: Chanwoo Choi > [tjakobi: Reported debugfs error during booting and cw00.choi fix it.] > Reported-by: Tobias Jakobi > Signed-off-by: MyungJoo Ham > --- > drivers/devfreq/Kconfig | 1 + > drivers/devfreq/exynos-bus.c | 219 > ++- > 2 files changed, 174 insertions(+), 46 deletions(-) Acked-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [PATCH v9 05/20] PM / devfreq: Add new passive governor
On 04/11/2016 05:57 AM, Chanwoo Choi wrote: > This patch adds the new passive governor for DEVFREQ framework. The following > governors are already present and used for DVFS (Dynamic Voltage and Frequency > Scaling) drivers. The following governors are independently used for one > device > driver which don't give the influence to other device drviers and also don't > receive the effect from other device drivers. > - ondemand / performance / powersave / userspace > > The passive governor depends on operation of parent driver with specific > governos extremely and is not able to decide the new frequency by oneself. > According to the decided new frequency of parent driver with governor, > the passive governor uses it to decide the appropriate frequency for own > device driver. The passive governor must need the following information > from device tree: > - the source clock and OPP tables > - the instance of parent device > > For exameple, > there are one more devfreq device drivers which need to change their source > clock according to their utilization on runtime. But, they share the same > power line (e.g., regulator). So, specific device driver is operated as parent > with ondemand governor and then the rest device driver with passive governor > is influenced by parent device. > > Suggested-by: Myungjoo Ham > Signed-off-by: Chanwoo Choi > [tjakobi: Reported RCU locking issue and cw00.choi fix it] > Reported-by: Tobias Jakobi > [linux.amoon: Reported possible recursive locking and cw00.choi fix it] > Reported-by: Anand Moon > Signed-off-by: MyungJoo Ham > --- > drivers/devfreq/Kconfig| 8 ++ > drivers/devfreq/Makefile | 1 + > drivers/devfreq/governor_passive.c | 207 > + > include/linux/devfreq.h| 33 ++ > 4 files changed, 249 insertions(+) > create mode 100644 drivers/devfreq/governor_passive.c > Acked-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [PATCH v5 1/6] pwms: pwm-ti*: Get the clock from the PWMSS (parent)
On Monday 11 April 2016 06:15 PM, Rob Herring wrote: > On Mon, Apr 11, 2016 at 6:49 AM, Sekhar Nori wrote: >> On Monday 11 April 2016 02:21 AM, Paul Walmsley wrote: >>> On Tue, 5 Apr 2016, Franklin S Cooper Jr. wrote: On 04/05/2016 01:08 AM, Sekhar Nori wrote: > On Tuesday 08 March 2016 06:53 AM, Franklin S Cooper Jr wrote: >> The eCAP and ePWM doesn't have their own separate clocks. They simply >> utilize the clock provided directly by the PWMSS. Therefore, they simply >> need to grab a reference to their parent's clock. >> >> Signed-off-by: Franklin S Cooper Jr > > So this assumes that eCAP and eHRPWM are always under the PWMSS > umbrella. But on TI AM18x, thats not true. These IPs exist independently > and receive functional clock from PLL sysclk outputs. > >> --- >> drivers/pwm/pwm-tiecap.c | 2 +- >> drivers/pwm/pwm-tiehrpwm.c | 2 +- >> 2 files changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/pwm/pwm-tiecap.c b/drivers/pwm/pwm-tiecap.c >> index 616af76..9418159 100644 >> --- a/drivers/pwm/pwm-tiecap.c >> +++ b/drivers/pwm/pwm-tiecap.c >> @@ -212,7 +212,7 @@ static int ecap_pwm_probe(struct platform_device >> *pdev) >> if (!pc) >> return -ENOMEM; >> >> -clk = devm_clk_get(&pdev->dev, "fck"); >> +clk = devm_clk_get(pdev->dev.parent, "fck"); > > Even keeping the AM18x usecase aside, this seems to be pushing too much > platform information into the driver. The "fck" is a valid connection id > for the eCAP IP. Whether its valid for the parent device too is not > something this driver should need to know. > > So it looks like what you need is for the clock hierarchy for the > platform to have clocks for eHRPWM and eCAP derived out of PWMSS clock? So I believe this is a question on if we want to hide the minor delta between AM18 vs AM335x, AM437x and AM57x/DRA7 in the driver or within the DT. Note that handling this by defining new clocks in DT will then result in older DTBs not working. I don't think its worth breaking backwards compatibility for AM335x and AM437x DTBs for fixing support for AM18 based SOCs. Especially since those SOCs haven't worked with this driver for several years. By handling things within the driver rather than DT we can atleast insure that we can get everything working while avoiding breaking backwards compatibility. >>> >>> I agree with Sekhar that we shouldn't embed this parent clock quirk >>> into the driver. >>> >>> Can you just define a new compatibility string such that the driver can be >>> written with no embedded integration quirks? Then add a workaround in the >>> driver that will use pdev->dev.parent for the old (deprecated) >>> compatibility string and log a warning to the kernel console that the DT >>> needs to be updated. >> >> Thanks Paul! Although not sure if adding a new compatible for the IP is >> the best way (since that would denote a different version of the IP). >> How about checking for parent clock iff clk_get() on own device fails >> and of_machine_is_compatible() matches the platforms where backward >> compatibility needs to be maintained? > > New compatible strings are acceptable. Alright, thanks for clarifying that. Regards, Sekhar
Re: [ANNOUNCE] linux-stable security tree
On Mon, Apr 11, 2016 at 11:35:08PM -0700, Greg KH wrote: > On Tue, Apr 12, 2016 at 08:22:37AM +0200, Willy Tarreau wrote: > > I think we may have more of an issue educating our users than an issue > > with the code we distribute. > > I think that's the issue here, combined with users that just don't want > to upgrade as it's "hard" for them. There's nothing we can do about > making it easier than we already do, and really, taking 200 patches is > just the same work for them to take 100 patches in a release, so I > don't buy the "I only want a small subset of fixes" argument, as it > doesn't make any sense. I've already met people who used to estimate the need for each patch individually. In the end they face many more problems in production than any other user just because they drop the important ones or those that enable certain "security" fixes to work reliably. Most often it's a way for them to secure their job because nobody else can do this work around them. When they leave the team, their boss generally decides to go to regular distros with their simple update process in the end. > So I worry that this tree will give people a _false_ sense of security, > thinking that they have properly covered the needed fixes when really, > there are lots of fixes they didn't even know they needed that got > applied to the "normal" stable tree for issues they will hit. Also the stable tree gets fixed thanks to feedback from users. When we do something wrong it doesn't last long. > Also, people need to stop being afraid of the large numbers of stable > patches, and compare it to the overall % of changes, and realize that > what we take in stable releases is really a trivially small number of > the overall changes made to the kernel. Yep. As a rule of thumb, I'd rather recommend people who fear updates to always stay late by 2-3 versions and monitor the more recent changelogs for possible fixes for previous versions. That might possibly make them more comfortable. It's not a good practice but it's already better than not applying the required fixes at all. And let me restate it, most of us are our own users. We *are* careful. My company ships load balancers which achieve multi-year uptimes (when people don't reboot to apply fixes). We don't want to mess up with a faulty update there. Ben gets his work distributed to all debian users and certainly doesn't want to take risks either. Willy
Re: [PATCH v2 11/11] mm/slab: lockless decision to grow cache
On Tue, Apr 12, 2016 at 09:24:34AM +0200, Jesper Dangaard Brouer wrote: > On Tue, 12 Apr 2016 13:51:06 +0900 > js1...@gmail.com wrote: > > > From: Joonsoo Kim > > > > To check whther free objects exist or not precisely, we need to grab a >^^ > (spelling) Will fix. > > lock. But, accuracy isn't that important because race window would be > > even small and if there is too much free object, cache reaper would reap > > it. So, this patch makes the check for free object exisistence not to > ^^^ > (spelling) Ditto. > > > hold a lock. This will reduce lock contention in heavily allocation case. > > > > Note that until now, n->shared can be freed during the processing by > > writing slabinfo, but, with some trick in this patch, we can access it > > freely within interrupt disabled period. > > > > Below is the result of concurrent allocation/free in slab allocation > > benchmark made by Christoph a long time ago. I make the output simpler. > > The number shows cycle count during alloc/free respectively so less is > > better. > > I cannot figure out which if Christoph's tests you are using. And I > even have a copy of his test here: > > https://github.com/netoptimizer/prototype-kernel/blob/master/kernel/mm/slab_test.c I don't remember where I grab the source but it's same thing you have. But, my version has some modification for stable result. I do each test 50 times and get the average result. > I think you need to describe the test a bit better... Okay. I assume that relevant people (like as Christoph or you) can understand the result easily but it seems not. > Looking a long time at the output on my own system, I guess you are > showing results from the "Concurrent allocs". Then it would be > relevant how many CPUs your system have. Right. I'm doing the test with my 8 core i7-3770 CPU @ 3.40GHz. > It would also be relevant to mention that N=1. And perhaps mention > that it means, e.g all CPUs do N=1 alloc concurrently, synchronize > before doing N free concurrently. I'm doing the test with N=10. > > > * Before > > Kmalloc N*alloc N*free(32): Average=248/966 > > Kmalloc N*alloc N*free(64): Average=261/949 > > Kmalloc N*alloc N*free(128): Average=314/1016 > > Kmalloc N*alloc N*free(256): Average=741/1061 > > Kmalloc N*alloc N*free(512): Average=1246/1152 > > Kmalloc N*alloc N*free(1024): Average=2437/1259 > > Kmalloc N*alloc N*free(2048): Average=4980/1800 > > Kmalloc N*alloc N*free(4096): Average=9000/2078 > > > > * After > > Kmalloc N*alloc N*free(32): Average=344/792 > > Kmalloc N*alloc N*free(64): Average=347/882 > > Kmalloc N*alloc N*free(128): Average=390/959 > > Kmalloc N*alloc N*free(256): Average=393/1067 > > Kmalloc N*alloc N*free(512): Average=683/1229 > > Kmalloc N*alloc N*free(1024): Average=1295/1325 > > Kmalloc N*alloc N*free(2048): Average=2513/1664 > > Kmalloc N*alloc N*free(4096): Average=4742/2172 > > > > It shows that allocation performance decreases for the object size up to > > 128 and it may be due to extra checks in cache_alloc_refill(). But, with > > considering improvement of free performance, net result looks the same. > > Result for other size class looks very promising, roughly, 50% performance > > improvement. > > Super nice performance boost. The numbers on my system are Thanks! > significantly smaller, but this is a before/after test and the absolute > numbers are not that important. > > Oh, maybe this was because I ran the test with SLUB... recompiling with > SLAB... and the results are comparable to your numbers (on my 8 core > i7-4790K CPU @ 4.00GHz) Okay. Thanks.
Re: [PATCH v9 08/20] PM / devfreq: exynos: Add the detailed correlation between sub-blocks and power line
On 04/11/2016 05:57 AM, Chanwoo Choi wrote: > This patch adds the detailed corrleation between sub-blocks and power line s/corrleation/correlation/ > for Exynos3250, Exynos4210 and Exynos4x12. > > Signed-off-by: Chanwoo Choi > Acked-by: MyungJoo Ham > --- > .../devicetree/bindings/devfreq/exynos-bus.txt | 51 > ++ > 1 file changed, 51 insertions(+) Acked-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [PATCH 3/7] ARM: dts: Add NoC Probe dt node for Exynos542x SoC
On 04/08/2016 07:00 AM, Chanwoo Choi wrote:
> This patch adds the NoCP (Network on Chip Probe) Device Tree node
> to measure the bandwidth of memory and g3d in Exynos542x SoC.
>
> Signed-off-by: Chanwoo Choi
> ---
> arch/arm/boot/dts/exynos5420.dtsi | 36
> 1 file changed, 36 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5420.dtsi
> b/arch/arm/boot/dts/exynos5420.dtsi
> index 7b99cb58d82d..d80f3b66f017 100644
> --- a/arch/arm/boot/dts/exynos5420.dtsi
> +++ b/arch/arm/boot/dts/exynos5420.dtsi
> @@ -294,6 +294,42 @@
> };
> };
>
> + nocp_mem0_0: nocp_mem0_0@10CA1000 {
The node name should describe general class of device, so:
nocp_mem0_0: nocp@10CA1000 {
...
}
?
> + compatible = "samsung,exynos5420-nocp";
> + reg = <0x10CA1000 0x200>;
> + status = "disabled";
> + };
> +
> + nocp_mem0_1: nocp_mem0_1@10CA1400 {
> + compatible = "samsung,exynos5420-nocp";
> + reg = <0x10CA1400 0x200>;
> + status = "disabled";
> + };
> +
> + nocp_mem0_2: nocp_mem0_2@10CA1800 {
Shouldn't it be nocp_mem1_0?
> + compatible = "samsung,exynos5420-nocp";
> + reg = <0x10CA1800 0x200>;
> + status = "disabled";
> + };
> +
> + nocp_mem0_3: nocp_mem0_3@10CA1C00 {
Shouldn't it be nocp_mem1_1?
Best regards,
Krzysztof
Re: [PATCH v9 07/20] PM / devfreq: exynos: Update documentation for bus devices using passive governor
On 04/11/2016 05:57 AM, Chanwoo Choi wrote: > This patch updates the documentation for passive bus devices and adds the > detailed example of Exynos3250. > > Signed-off-by: Chanwoo Choi > Acked-by: MyungJoo Ham > --- > .../devicetree/bindings/devfreq/exynos-bus.txt | 250 > - > 1 file changed, 247 insertions(+), 3 deletions(-) > > diff --git a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt > b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt > index 78171b918e3f..03f13d38f1a1 100644 > --- a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt > +++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt > @@ -8,22 +8,46 @@ of the bus in runtime. To monitor the usage of each bus in > runtime, > the driver uses the PPMU (Platform Performance Monitoring Unit), which > is able to measure the current load of sub-blocks. > > +The Exynos SoC includes the various sub-blocks which have the each AXI bus. > +The each AXI bus has the owned source clock but, has not the only owned > +power line. The power line might be shared among one more sub-blocks. > +So, we can divide into two type of device as the role of each sub-block. > +There are two type of bus devices as following: > +- parent bus device > +- passive bus device > + > +Basically, parent and passive bus device share the same power line. > +The parent bus device can only change the voltage of shared power line > +and the rest bus devices (passive bus device) depend on the decision of > +the parent bus device. If there are three blocks which share the VDD_xxx > +power line, Only one block should be parent device and then the rest blocks > +should depend on the parent device as passive device. > + > + VDD_xxx |--- A block (parent) > + |--- B block (passive) > + |--- C block (passive) > + > There are a little different composition among Exynos SoC because each Exynos > SoC has different sub-blocks. Therefore, shch difference should be specified s/shch/such/ > in devicetree file instead of each device driver. In result, this driver > is able to support the bus frequency for all Exynos SoCs. > > -Required properties for bus device: > +Required properties for all bus devices: > - compatible: Should be "samsung,exynos-bus". > - clock-names : the name of clock used by the bus, "bus". > - clocks : phandles for clock specified in "clock-names" property. > - operating-points-v2: the OPP table including frequency/voltage information >to support DVFS (Dynamic Voltage/Frequency Scaling) feature. > + > +Required properties only for parent bus device: > - vdd-supply: the regulator to provide the buses with the voltage. > - devfreq-events: the devfreq-event device to monitor the current utilization >of buses. > > -Optional properties for bus device: > +Required properties only for passive bus device: > +- devfreq: the parent bus device. > + > +Optional properties only for parent bus device: > - exynos,saturation-ratio: the percentage value which is used to calibrate > the performance count against total cycle count. > - exynos,voltage-tolerance: the percentage value for bus voltage tolerance > @@ -34,7 +58,20 @@ Example1: > power line (regulator). The MIF (Memory Interface) AXI bus is used to > transfer data between DRAM and CPU and uses the VDD_MIF regualtor. s/regualtor/regulator/ Acked-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [PATCH v9 10/20] MAINTAINERS: Add samsung bus frequency driver entry
On 04/11/2016 05:57 AM, Chanwoo Choi wrote: > This patch adds the 'BUS FREQUENCY DRIVER FOR SAMSUNG EXYNOS' entry to review > the > patches as maintainer. I can access the all datasheet of Exynos SoC and test > it > on some Exynos-based board. Patches will be picked up by DEVFREQ maintainer > on devfreq git repository. > > Signed-off-by: Chanwoo Choi > --- > MAINTAINERS | 9 + > 1 file changed, 9 insertions(+) Acked-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [PATCH v9 08/20] PM / devfreq: exynos: Add the detailed correlation between sub-blocks and power line
On 2016년 04월 12일 16:35, Krzysztof Kozlowski wrote: > On 04/11/2016 05:57 AM, Chanwoo Choi wrote: >> This patch adds the detailed corrleation between sub-blocks and power line > > s/corrleation/correlation/ OK. I'll fix it. > > >> for Exynos3250, Exynos4210 and Exynos4x12. >> >> Signed-off-by: Chanwoo Choi >> Acked-by: MyungJoo Ham >> --- >> .../devicetree/bindings/devfreq/exynos-bus.txt | 51 >> ++ >> 1 file changed, 51 insertions(+) > > > Acked-by: Krzysztof Kozlowski > Best Regards, Chanwoo Choi
Re: [PATCH v9 07/20] PM / devfreq: exynos: Update documentation for bus devices using passive governor
On 2016년 04월 12일 16:34, Krzysztof Kozlowski wrote: > On 04/11/2016 05:57 AM, Chanwoo Choi wrote: >> This patch updates the documentation for passive bus devices and adds the >> detailed example of Exynos3250. >> >> Signed-off-by: Chanwoo Choi >> Acked-by: MyungJoo Ham >> --- >> .../devicetree/bindings/devfreq/exynos-bus.txt | 250 >> - >> 1 file changed, 247 insertions(+), 3 deletions(-) >> >> diff --git a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt >> b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt >> index 78171b918e3f..03f13d38f1a1 100644 >> --- a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt >> +++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt >> @@ -8,22 +8,46 @@ of the bus in runtime. To monitor the usage of each bus in >> runtime, >> the driver uses the PPMU (Platform Performance Monitoring Unit), which >> is able to measure the current load of sub-blocks. >> >> +The Exynos SoC includes the various sub-blocks which have the each AXI bus. >> +The each AXI bus has the owned source clock but, has not the only owned >> +power line. The power line might be shared among one more sub-blocks. >> +So, we can divide into two type of device as the role of each sub-block. >> +There are two type of bus devices as following: >> +- parent bus device >> +- passive bus device >> + >> +Basically, parent and passive bus device share the same power line. >> +The parent bus device can only change the voltage of shared power line >> +and the rest bus devices (passive bus device) depend on the decision of >> +the parent bus device. If there are three blocks which share the VDD_xxx >> +power line, Only one block should be parent device and then the rest blocks >> +should depend on the parent device as passive device. >> + >> +VDD_xxx |--- A block (parent) >> +|--- B block (passive) >> +|--- C block (passive) >> + >> There are a little different composition among Exynos SoC because each >> Exynos >> SoC has different sub-blocks. Therefore, shch difference should be specified > > s/shch/such/ I'll fix it on patch2 because this typo happen on patch2. > >> in devicetree file instead of each device driver. In result, this driver >> is able to support the bus frequency for all Exynos SoCs. >> >> -Required properties for bus device: >> +Required properties for all bus devices: >> - compatible: Should be "samsung,exynos-bus". >> - clock-names : the name of clock used by the bus, "bus". >> - clocks : phandles for clock specified in "clock-names" property. >> - operating-points-v2: the OPP table including frequency/voltage information >>to support DVFS (Dynamic Voltage/Frequency Scaling) feature. >> + >> +Required properties only for parent bus device: >> - vdd-supply: the regulator to provide the buses with the voltage. >> - devfreq-events: the devfreq-event device to monitor the current >> utilization >>of buses. >> >> -Optional properties for bus device: >> +Required properties only for passive bus device: >> +- devfreq: the parent bus device. >> + >> +Optional properties only for parent bus device: >> - exynos,saturation-ratio: the percentage value which is used to calibrate >> the performance count against total cycle count. >> - exynos,voltage-tolerance: the percentage value for bus voltage tolerance >> @@ -34,7 +58,20 @@ Example1: >> power line (regulator). The MIF (Memory Interface) AXI bus is used to >> transfer data between DRAM and CPU and uses the VDD_MIF regualtor. > > s/regualtor/regulator/ ditto. > > > Acked-by: Krzysztof Kozlowski Thanks for your review. Best Regards, Chanwoo Choi
Re: [PATCH 1/2] spi: Add DMA support for spi_flash_read()
On 04/12/2016 10:01 AM, Mark Brown wrote:
> On Tue, Apr 05, 2016 at 09:19:51AM +0530, Vignesh R wrote:
>
>> mutex_lock(&master->bus_lock_mutex);
>> +if (master->dma_rx) {
>> +rx_dev = master->dma_rx->device->dev;
>> +ret = spi_map_buf(master, rx_dev, &msg->rx_sg,
>> + msg->buf, msg->len,
>> + DMA_FROM_DEVICE);
>> +if (ret != 0)
>> +goto err;
>> +}
>
> This is unconditionally DMA mapping the buffer if DMA is supported.
> That's going to be common but I'm not sure it'll be universal, we need
> to think of something better here. I'm not immediately seeing what
> though. Possibly a flag...
>
Ok, I will introduced a flag along the lines of cur_msg_mapped currently
part of spi_message struct.
This reminds me the issue of possible kmap'd buffers(falling in
PKMAP_BASE - PAGE_OFFSET-1 region) that might be passed to
spi_map_buf() which are not currently being handled properly. Boris
attempted to fix this in generic way[1] but was rejected as it couldn't
handle all type of caches.
I was wondering whether you would accept a patch returning error when
kmap'd buffers are passed to spi_map_buf()? Or would it still make sense
to port changes from that series to handle kmap'd buffers to SPI core alone?
[1]https://lkml.org/lkml/2016/3/31/462
--
Regards
Vignesh
Re: [PATCH v9 10/20] MAINTAINERS: Add samsung bus frequency driver entry
On 2016년 04월 12일 16:46, Krzysztof Kozlowski wrote: > On 04/11/2016 05:57 AM, Chanwoo Choi wrote: >> This patch adds the 'BUS FREQUENCY DRIVER FOR SAMSUNG EXYNOS' entry to >> review the >> patches as maintainer. I can access the all datasheet of Exynos SoC and test >> it >> on some Exynos-based board. Patches will be picked up by DEVFREQ maintainer >> on devfreq git repository. >> >> Signed-off-by: Chanwoo Choi >> --- >> MAINTAINERS | 9 + >> 1 file changed, 9 insertions(+) > > > Acked-by: Krzysztof Kozlowski Thanks for your review. Best Regards, Chanwoo Choi
Re: [PATCH] thermal/intel_powerclamp: convert to smpboot thread
On Mon 2016-04-11 18:04:37, Sebastian Andrzej Siewior wrote: > On 04/11/2016 05:19 PM, Jacob Pan wrote: > I tried to convert it over to smpboot thread so we don't have that > CPU notifier stuff to fire the cpu threads during hotplug events. > > >>> there is another patchset to convert it to kthread worker. any > >>> advantage of smpboot thread? > >>> http://comments.gmane.org/gmane.linux.kernel.mm/144964 > >> > >> It partly does the same thing except you still have your hotplug > >> notifier which I wanted to get rid off. However it looks better than > >> before. > >> If you do prefer the kworker thingy then please switch from CPU_DEAD > >> to CPU_DOWN_PREPARE (and add CPU_DOWN_FAILED to CPU_ONLINE). > >> With those changes I should have no further problem with it :) > >> Any ETA for (either of those patches) upstream? It depends on some improvements of the kthread worker API. I hope that we are getting close. I would like to send another iteration later this week. Best Regards, Petr > > +Petr > > I do prefer not to keep track of CPU hotplug events. Let me do some > > testing. > Okay. Please keep me posted where you stand on this. If you go for the > kwork series then I will try to make a patch which replaces CPU_DEAD to > CPU_DOWN_PREPARE in order to make it symmetrical (and from what it > looks, there is no need to run at CPU_DEAD time).
Re: [PATCH 2/4] arm64: pmu: add fallback probe table
On Fri, Apr 08, 2016 at 04:57:05PM -0500, Jeremy Linton wrote:
> From: Mark Salter
>
> In preparation for ACPI support, add a pmu_probe_info table to
> the arm_pmu_device_probe() call. This table gets used when
> probing in the absence of a devicetree node for PMU.
>
> Signed-off-by: Mark Salter
> Signed-off-by: Jeremy Linton
> ---
> arch/arm64/kernel/perf_event.c | 10 +-
> include/linux/perf/arm_pmu.h | 3 +++
> 2 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
> index f419a7c..8f12eac 100644
> --- a/arch/arm64/kernel/perf_event.c
> +++ b/arch/arm64/kernel/perf_event.c
> @@ -867,9 +867,17 @@ static const struct of_device_id
> armv8_pmu_of_device_ids[] = {
> {},
> };
>
> +static const struct pmu_probe_info armv8_pmu_probe_table[] = {
> + ARMV8_PMU_PART_PROBE(ARM_CPU_PART_CORTEX_A53, armv8_a53_pmu_init),
> + ARMV8_PMU_PART_PROBE(ARM_CPU_PART_CORTEX_A57, armv8_a57_pmu_init),
> + PMU_PROBE(0, 0, armv8_pmuv3_init), /* if all else fails... */
> + { /* sentinel value */ }
> +};
> +
Hi Jeremy,
with 4.6 ThunderX PMU support was added, so I think above table is
missing a line like:
ARMV8_PMU_PART_PROBE(CAVIUM_CPU_PART_THUNDERX, armv8_thunder_pmu_init)
Thanks,
Jan
Re: [PATCH v6 07/10] usb: dwc3: gadget: Fix suspend/resume during dual-role mode
On 12/04/16 11:00, Felipe Balbi wrote: > > Hi, > > Roger Quadros writes: >> On 11/04/16 16:26, Felipe Balbi wrote: >>> >>> Hi, >>> >>> Roger Quadros writes: On 11/04/16 15:23, Felipe Balbi wrote: > > Hi, > > Roger Quadros writes: >> Gadget controller might not be always active during suspend/ >> resume when we are operating in dual-role/otg mode. >> Check if we're active and only if we are then perform >> necessary actions during suspend/resume. > > I don't get this. If we're operating in OTG, we should have a gadget > driver loaded, no ? > At boot gadget driver is not automatically loaded. We're still in OTG mode but OTG state machine hasn't started. System suspend/resume can still happen. User might also load/unload the gadget driver prior to system suspend. >>> >>> good point, this should go in the -rc too. >>> >> But there is no dual-role mode currently so it won't fix any bug yet :). > > this should be a problem even for device-only, right ? > > i) boot-up > ii) modprobe dwc3 > iii) echo mem > /sys/power/state > Indeed. It is applicable for device-only mode as well. I'll send this patch for rc then. cheers, -roger
[PATCH v2] usb: dwc3: fix memory leak of dwc->regset
From: "Du, Changbin"
dwc->regset is allocated on dwc3_debugfs_init, and should
be released on init failure or dwc3_debugfs_exit. Btw,
The line "dwc->root = NULL" is unnecessary, so remove it.
Signed-off-by: Du, Changbin
---
v2:
Title changed;
free dwc->regset on failure path.
---
drivers/usb/dwc3/debugfs.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/dwc3/debugfs.c b/drivers/usb/dwc3/debugfs.c
index 9ac37fe..abd8889 100644
--- a/drivers/usb/dwc3/debugfs.c
+++ b/drivers/usb/dwc3/debugfs.c
@@ -678,7 +678,8 @@ int dwc3_debugfs_init(struct dwc3 *dwc)
err1:
debugfs_remove_recursive(root);
-
+ if (!dwc->regset)
+ kfree(dwc->regset);
err0:
return ret;
}
@@ -686,5 +687,5 @@ err0:
void dwc3_debugfs_exit(struct dwc3 *dwc)
{
debugfs_remove_recursive(dwc->root);
- dwc->root = NULL;
+ kfree(dwc->regset);
}
--
2.5.0
Re: [PATCH v2] usb: dwc3: fix memory leak of dwc->regset
Hi, changbin...@intel.com writes: > From: "Du, Changbin" > > dwc->regset is allocated on dwc3_debugfs_init, and should > be released on init failure or dwc3_debugfs_exit. Btw, > The line "dwc->root = NULL" is unnecessary, so remove it. > > Signed-off-by: Du, Changbin > --- > v2: > Title changed; > free dwc->regset on failure path. > > --- > drivers/usb/dwc3/debugfs.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/drivers/usb/dwc3/debugfs.c b/drivers/usb/dwc3/debugfs.c > index 9ac37fe..abd8889 100644 > --- a/drivers/usb/dwc3/debugfs.c > +++ b/drivers/usb/dwc3/debugfs.c > @@ -678,7 +678,8 @@ int dwc3_debugfs_init(struct dwc3 *dwc) > > err1: > debugfs_remove_recursive(root); > - > + if (!dwc->regset) > + kfree(dwc->regset); IOW: if regset is NULL, free NULL. This check is wrong and unnecessary ;-) kfree(NULL) is safe. -- balbi signature.asc Description: PGP signature
Re: [PATCH 1/1] iio: adc: Add driver for the TI INA3221 Triple Current/Voltage Monitor
On 11.04.2016 16:48, Andrew F. Davis wrote: On 04/10/2016 06:57 AM, Jonathan Cameron wrote: On 08/04/16 19:19, Andrew F. Davis wrote: The INA3221 is a three-channel, high-side current and bus voltage monitor with an I2C and SMBUS compatible interface. Signed-off-by: Andrew F. Davis Hi Andrew, My immediate thought on this one is whether it would be better off in hwmon. I'm not convinced either way from a quick glance at the data sheet, but the question needs to be addressed. I was on the fence with this also, I was leaning towards hwmod until I looked onto how the ina2xx driver has been ported to iio. This is almost the same part but the ina3x has three monitors vs one. In addition it looks like NVIDIA has written a hwmod driver for this part (https://github.com/Bogdacutu/STLinux-Kernel/blob/master/drivers/hwmon/ina3221.c) but then also ported it over to IIO (although doesn't appear to be upstream ready or ever has been submitted for such) (https://github.com/SuperPichu/shield-tablet-kernel/blob/master/drivers/staging/iio/meter/ina3221.c) So I figured this was the way things are moving, but I have no problem working this as a hwmod driver. The IIO work is already done here, I'll write the hwmod version also but keep working this, I see no reason we cant have both if needed. (unless using this and just using iio_hwmod.c if needed is more acceptable?) It's not exactly a clean fit for the IIO ABI either at the moment though I think some elements of that could be easily sorted out. The key think in my mind is to look at what is actually being measured rather than assume all the external components will be as the datasheet assumes them to be... + where do the alert lines actually go? Jonathan --- .../ABI/testing/sysfs-bus-iio-adc-ina3221 | 23 ++ drivers/iio/adc/Kconfig| 7 + drivers/iio/adc/Makefile | 1 + drivers/iio/adc/ina3221.c | 417 + 4 files changed, 448 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-adc-ina3221 create mode 100644 drivers/iio/adc/ina3221.c diff --git a/Documentation/ABI/testing/sysfs-bus-iio-adc-ina3221 b/Documentation/ABI/testing/sysfs-bus-iio-adc-ina3221 new file mode 100644 index 000..bbe4f8c --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-iio-adc-ina3221 @@ -0,0 +1,23 @@ +What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_shunt_(raw|scale) +What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_bus_(raw|scale) +Date: April 2016 +KernelVersion: 4.7 +Contact: Andrew F. Davis +Description: + Shunt and Bus voltage for each channel. Units etc need specifying or at least a reference to the main in_voltageY_raw docs etc. These are really completely separate measurements be it differential measurements where the + on one is the - on the other (second is really a unipolar measurement as it's relative to 0). I wonder if we are better off supporting them as such so define this device as having the channels. in_voltage1-voltage0_raw (shunt voltage 1) in_voltage0_raw (bus voltage 1) in_voltage3-voltage2_raw (shunt voltage 2) in_voltage2_raw (bus voltage 2) in_voltage5-voltage4_raw (shunt voltage 3) in_voltage4_raw That I think reflects the actual measuring options, without applying assumptions on what is connected to them. Yes the datasheet says you should put a shunt between the first two connections and the load between the second connection and the 0 volt line, but I can't see anything preventing this being used differently... I feel this may become confusing to some, but I have no real objection to this. Guenter's point that the shunt measurements are really current measures may mean it makes more sense to handle these by allowing say device tree to provide the resistance values and then converting them to a direct current measure. + +What: /sys/bus/iio/devices/iio:deviceX/shunt_integration_time[_available] +What: /sys/bus/iio/devices/iio:deviceX/bus_integration_time[_available] +Date: April 2016 +KernelVersion: 4.7 +Contact: Andrew F. Davis +Description: + Shunt and Bus integration time for each channel. I'd keep these tightly associated with the channels as then they become standard abi elements, just for channels with extended names. The other option is to have each channel have an integration_time, but this may give the false impression that they are individually adjustable when they are actually all linked together, change one, they all change (of the same type (bus/shunt)). Hmm. It is a little fiddly as we don't support grouping by extended name like this. It's far from uncommon to have a set of channel parameters tied together and the ABI allows for this. Any parameter can change any other. I think I'd rather stay within the standard abi if at all possible. Perhaps this will al
[PATCH 3/3] usb: dwc3: gadget: Fix suspend/resume during device mode
Gadget controller might not be always active during system
suspend/resume as gadget driver might not have yet been loaded or
might have been unloaded prior to system suspend.
Check if we're active and only then perform
necessary actions during suspend/resume.
Signed-off-by: Roger Quadros
---
drivers/usb/dwc3/gadget.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 3ac170f..efbb801 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -2931,6 +2931,9 @@ void dwc3_gadget_exit(struct dwc3 *dwc)
int dwc3_gadget_suspend(struct dwc3 *dwc)
{
+ if (!dwc->gadget_driver)
+ return 0;
+
if (dwc->pullups_connected) {
dwc3_gadget_disable_irq(dwc);
dwc3_gadget_run_stop(dwc, true, true);
@@ -2949,6 +2952,9 @@ int dwc3_gadget_resume(struct dwc3 *dwc)
struct dwc3_ep *dep;
int ret;
+ if (!dwc->gadget_driver)
+ return 0;
+
/* Start with SuperSpeed Default */
dwc3_gadget_ep0_desc.wMaxPacketSize = cpu_to_le16(512);
--
2.5.0
Re: [PATCH 1/1] iio: adc: Add driver for the TI INA3221 Triple Current/Voltage Monitor
On 11.04.2016 19:08, Guenter Roeck wrote: On Mon, Apr 11, 2016 at 11:47:44AM -0500, Andrew F. Davis wrote: On 04/11/2016 11:38 AM, Guenter Roeck wrote: > On Mon, Apr 11, 2016 at 10:48:27AM -0500, Andrew F. Davis wrote: >> On 04/10/2016 06:57 AM, Jonathan Cameron wrote: >>> On 08/04/16 19:19, Andrew F. Davis wrote: The INA3221 is a three-channel, high-side current and bus voltage monitor with an I2C and SMBUS compatible interface. Signed-off-by: Andrew F. Davis >>> Hi Andrew, >>> >>> My immediate thought on this one is whether it would be better off in hwmon. >>> I'm not convinced either way from a quick glance at the data sheet, but the >>> question needs to be addressed. >>> >> >> I was on the fence with this also, I was leaning towards hwmod until I >> looked onto how the ina2xx driver has been ported to iio. This is almost >> the same part but the ina3x has three monitors vs one. In addition it >> looks like NVIDIA has written a hwmod driver for this part >> (https://github.com/Bogdacutu/STLinux-Kernel/blob/master/drivers/hwmon/ina3221.c) >> but then also ported it over to IIO (although doesn't appear to be >> upstream ready or ever has been submitted for such) >> (https://github.com/SuperPichu/shield-tablet-kernel/blob/master/drivers/staging/iio/meter/ina3221.c) >> So I figured this was the way things are moving, but I have no problem >> working this as a hwmod driver. The IIO work is already done here, I'll >> write the hwmod version also but keep working this, I see no reason we >> cant have both if needed. (unless using this and just using iio_hwmod.c >> if needed is more acceptable?) >> > > You can not have both since they would conflict with each other. > ina2xx has possibly created a bad precedent. I am not inclined to accept > a hwmon driver if an iio driver already exists. If you want an iio driver, > fine with me, but then you (and its users) will have to live with its > limitations when it comes to hardware monitoring. > Hmm, my plan was an MFD device core, that then could mediate the two sub-drivers, but I'm not sure about this yet. mfd is intended to separate multi-function devices, not multiple linux subsystems accessing the same logical functionality in a chip just because the subsystems don't have a means to communicate with each other. I don't think using mfd for this purpose is a good idea; someone would have to work hard to convince me that it is. > I don't really mind if things are going all towards iio if that is where > the community wants to go. However, if that is the case, I would suggest > that someone should spend the time to define a clear sense of 'limits' > as well as alert handling in iio, in a way that is exportable to other > subsystems (hwmon and thermal come into mind). > I agree. I think both frameworks offer useful interfaces, so I would hate to limit users to one, but for now I'll just post the hwmon version here in a bit and live with that until someone requests the IIO support. Ultimately it might make sense to create a hwmon->iio bridge in the hwmon core (just like it would make sense to create a hwmon->thermal bridge). This way drivers could be implemented whereever it is more convenient, and where the primary use case fits best. The basic idea would be for a hwmon driver to register with a flag such as "register with the iio subsystem as well". However, that would require substantial structural changes (or call it modernization) of the hwmon driver core API. Unfortunately, that is unlikely to happen anytime soon - I don't have the time, and no one else seems to show much interest in hwmon lately. So instead of doing that, people end up writing drivers for the same chip in multiple subsystems, and end up with limitations one way or another. ina2xx is a perfect example. The aim from the IIO side was to take a kind of different approach to this. Original suggest was Mark Brown's (I like to blame him whenever possible ;). His usecase was SoC ADCs where one single ADC is commonly used to do a whole load of parallel tasks. It's not uncommon to have one logic block doing, touchscreen, hwmon and general purpose ADC channels. Anyhow, what he brought up is that, as we were adding the ability to have other consumers of IIO data in the kernel we can separate the backend from the front end. The backend : * Handles the hardware providing any of: Guenter
[PATCH] Revert "soc: mediatek: SCPSYS: Fix double enabling of regulators"
This reverts commit cc8ed76938b5cf6a54ab3d60edabaf808dc960d1
("soc: mediatek: SCPSYS: Fix double enabling of regulators") [1].
This patch fixes mt8173-evb failing boot issue. With commit [1],
genpd state will not sync to real power domain state. So some
resources such as clocks and regulators may stay in a wrong state.
There is no regulator double enabling issue on mainline kernel, so
we can refert commit [1] safely.
Signed-off-by: James Liao
---
drivers/soc/mediatek/mtk-scpsys.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/soc/mediatek/mtk-scpsys.c
b/drivers/soc/mediatek/mtk-scpsys.c
index 57e781c..837effe 100644
--- a/drivers/soc/mediatek/mtk-scpsys.c
+++ b/drivers/soc/mediatek/mtk-scpsys.c
@@ -491,13 +491,14 @@ static int scpsys_probe(struct platform_device *pdev)
genpd->dev_ops.active_wakeup = scpsys_active_wakeup;
/*
-* With CONFIG_PM disabled turn on all domains to make the
-* hardware usable.
+* Initially turn on all domains to make the domains usable
+* with !CONFIG_PM and to get the hardware in sync with the
+* software. The unused domains will be switched off during
+* late_init time.
*/
- if (!IS_ENABLED(CONFIG_PM))
- genpd->power_on(genpd);
+ genpd->power_on(genpd);
- pm_genpd_init(genpd, NULL, true);
+ pm_genpd_init(genpd, NULL, false);
}
/*
--
1.9.1
RE: [PATCH 3/3] mfd: lpc_ich: Add support for Intel Apollo Lake GPIO pinctrl in non-ACPI system
> -Original Message-
> From: lkp
> Sent: Monday, April 11, 2016 12:35 PM
> To: Tan, Jui Nee
> Cc: kbuild-...@01.org; mika.westerb...@linux.intel.com;
> heikki.kroge...@linux.intel.com; andriy.shevche...@linux.intel.com;
> t...@linutronix.de; mi...@redhat.com; h...@zytor.com; x...@kernel.org;
> pty...@xes-inc.com; lee.jo...@linaro.org; linux-g...@vger.kernel.org;
> linux-kernel@vger.kernel.org; Tan, Jui Nee ; Yong,
> Jonathan ; Yu, Ong Hock
> ; Voon, Weifeng ; Wan
> Mohamad, Wan Ahmad Zainie
>
> Subject: Re: [PATCH 3/3] mfd: lpc_ich: Add support for Intel Apollo Lake GPIO
> pinctrl in non-ACPI system
>
> Hi Tan,
>
> [auto build test ERROR on tip/x86/core]
> [also build test ERROR on v4.6-rc3 next-20160408] [if your patch is applied to
> the wrong git tree, please drop us a note to help improving the system]
>
> url:https://github.com/0day-ci/linux/commits/Tan-Jui-Nee/pinctrl-
> broxton-enable-platform-device-in-the-absent-of-ACPI-
> enumeration/20160411-105542
> config: x86_64-randconfig-n0-0431 (attached as .config)
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=x86_64
>
> All error/warnings (new ones prefixed by >>):
>
>drivers/mfd/lpc_ich.c:204:22: error: invalid application of 'sizeof' to
> incomplete type 'struct pinctrl_pin_desc'
> .pdata_size = sizeof(apl_pinctrl_pdata),
> ^
>drivers/mfd/lpc_ich.c: In function 'lpc_ich_misc':
>drivers/mfd/lpc_ich.c:1146:4: error: invalid use of undefined type 'struct
> pinctrl_pin_desc'
>apl_pinctrl_pdata.name = kasprintf(GFP_KERNEL, "%u",
>^
>drivers/mfd/lpc_ich.c:1148:4: error: invalid use of undefined type 'struct
> pinctrl_pin_desc'
>if (apl_pinctrl_pdata.name)
>^
>drivers/mfd/lpc_ich.c:1148:4: error: invalid use of undefined type 'struct
> pinctrl_pin_desc'
>In file included from include/linux/linkage.h:4:0,
> from include/linux/kernel.h:6,
> from drivers/mfd/lpc_ich.c:63:
> >> include/linux/compiler.h:150:17: error: invalid use of undefined type
> 'struct pinctrl_pin_desc'
> static struct ftrace_branch_data \
> ^
>include/linux/compiler.h:145:23: note: in expansion of macro '__trace_if'
> #define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
> ^
> >> drivers/mfd/lpc_ich.c:1148:4: note: in expansion of macro 'if'
>if (apl_pinctrl_pdata.name)
>^
>drivers/mfd/lpc_ich.c:1158:7: error: invalid use of undefined type 'struct
> pinctrl_pin_desc'
> apl_pinctrl_pdata.name, ret);
> ^
>drivers/mfd/lpc_ich.c:1160:4: error: invalid use of undefined type 'struct
> pinctrl_pin_desc'
>kfree(apl_pinctrl_pdata.name);
>^
>
> vim +150 include/linux/compiler.h
>
> 2bcd521a Steven Rostedt 2008-11-21 144 */
> ab3c9c68 Linus Torvalds 2009-04-07 145 #define if(cond, ...) __trace_if(
> (cond , ## __VA_ARGS__) )
> ab3c9c68 Linus Torvalds 2009-04-07 146 #define __trace_if(cond) \
> ab3c9c68 Linus Torvalds 2009-04-07 147 if
> (__builtin_constant_p((cond)) ? !!(cond) :\
> 2bcd521a Steven Rostedt 2008-11-21 148 ({
> \
> 2bcd521a Steven Rostedt 2008-11-21 149 int __r;
> \
> 2bcd521a Steven Rostedt 2008-11-21 @150 static struct
> ftrace_branch_data\
> 2bcd521a Steven Rostedt 2008-11-21 151
> __attribute__((__aligned__(4))) \
> 2bcd521a Steven Rostedt 2008-11-21 152
> __attribute__((section("_ftrace_branch"))) \
> 2bcd521a Steven Rostedt 2008-11-21 153 __f = {
> \
>
> :: The code at line 150 was first introduced by commit
> :: 2bcd521a684cc94befbe2ce7d5b613c841b0d304 trace: profile all if
> conditionals
>
> :: TO: Steven Rostedt
> :: CC: Ingo Molnar
>
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
Hi Andy, I will send patch v2 that looks like:
+static int lpc_ich_misc(struct pci_dev *dev, enum lpc_chipsets chipset)
+{
...
+ const char *name;
...
+ /* Fill IRQ resource */
+ res->start = APL_GPIO_IRQ;
+ res->end = res->start;
+ res->flags = IORESOURCE_IRQ;
+
+ name = kasprintf(GFP_KERNEL, "%u", i + 1);
+ if (name)
+ ret = mfd_add_devices(&dev->dev, i,
+ &apl_gpio_devices, 1, NULL, 0, NULL);
+ else
+ ret = -ENOMEM;
+
+warn_continue:
+ if (ret)
+ dev_warn(&dev->dev,
+
[PATCH v3] usb: dwc3: fix memory leak of dwc->regset
From: "Du, Changbin"
dwc->regset is allocated on dwc3_debugfs_init, and should
be released on init failure or dwc3_debugfs_exit. Btw,
The line "dwc->root = NULL" is unnecessary, so remove it.
Signed-off-by: Du, Changbin
---
v3:
remove unnecessary if(!NULL) for free
v2:
Title changed;
free dwc->regset on failure path.
---
drivers/usb/dwc3/debugfs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/dwc3/debugfs.c b/drivers/usb/dwc3/debugfs.c
index 9ac37fe..07d99eb 100644
--- a/drivers/usb/dwc3/debugfs.c
+++ b/drivers/usb/dwc3/debugfs.c
@@ -678,7 +678,7 @@ int dwc3_debugfs_init(struct dwc3 *dwc)
err1:
debugfs_remove_recursive(root);
-
+ kfree(dwc->regset);
err0:
return ret;
}
@@ -686,5 +686,5 @@ err0:
void dwc3_debugfs_exit(struct dwc3 *dwc)
{
debugfs_remove_recursive(dwc->root);
- dwc->root = NULL;
+ kfree(dwc->regset);
}
--
2.5.0
Re: [PATCH v5 30/46] regulator: pwm: retrieve correct voltage
Hi Mark, On Tue, 12 Apr 2016 05:42:03 +0100 Mark Brown wrote: > On Thu, Apr 07, 2016 at 11:54:31PM +0200, Boris Brezillon wrote: > > > Is there any reason for calling set_machine_constraints() after > > device_register() in regulator_register()? > > I'm not sure there's a strong one, we don't really use the class device > for anything, but without doing a full audit I couldn't guarantee that. At first glance I don't see any problem (even the rdev_err/info/...() functions do not use dev_err/info/...()). The patch will be part of v6 (unless you want me to send it independently). Thanks, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
Re: Xen regression, Was: [PATCH] x86/irq: Probe for PIC presence before allocating descs for legacy IRQs
Stefano Stabellini writes:
> Hi all,
>
> Unfortunately this patch (now commit
> 8c058b0b9c34d8c8d7912880956543769323e2d8) causes a regression on Xen
> when running on top of QEMU: the number of PIT irqs get set to 0 by
> probe_8259A but actually there are 16.
>
How would one see the regression?
8c058b0b9c34d8c8d7912880956543769323e2d8 is present since 4.4 and HVM
guests seem to work.
Other than that, why does probe_8259A() lie?
> Any suggestions on how to fix this?
>
> 1) we could revert 8c058b0b9c34d8c8d7912880956543769323e2d8
This would re-introduce the original issue I was fixing.
> 2) we could introduce an 'if (!xen_domain())' in probe_8259A
> 3) suggestions welcome
I'd suggest we make probe_8259A() work. It can only return 0 if PIC
probe by outb()/inb() fails. Why does it fail on QEMU?
>
> On Mon, 2 Nov 2015, Vitaly Kuznetsov wrote:
>> Commit d32932d02e18 ("x86/irq: Convert IOAPIC to use hierarchical irqdomain
>> interfaces") brought a regression for Hyper-V Gen2 instances. These
>> instances don't have i8259 legacy PIC but they use legacy IRQs for serial
>> port, rtc, and acpi. With this commit included we end up with these IRQs
>> not initialized. Earlier, there was a special workaround for legacy IRQs
>> in mp_map_pin_to_irq() doing mp_irqdomain_map() without looking at
>> nr_legacy_irqs() and now we fail in __irq_domain_alloc_irqs() when
>> irq_domain_alloc_descs() returns -EEXIST.
>>
>> The essence of the issue seems to be that early_irq_init() calls
>> arch_probe_nr_irqs() to figure out the number of legacy IRQs before
>> we probe for i8259 and gets 16. Later when init_8259A() is called we switch
>> to NULL legacy PIC and nr_legacy_irqs() starts to return 0 but we already
>> have 16 descs allocated.
>>
>> Solve the issue by separating i8259 probe from init and calling it in
>> arch_probe_nr_irqs() before we actually use nr_legacy_irqs() information.
>>
>> Fixes: d32932d02e18 ("x86/irq: Convert IOAPIC to use hierarchical irqdomain
>> interfaces")
>> Signed-off-by: Vitaly Kuznetsov
>> ---
>> arch/x86/include/asm/i8259.h | 1 +
>> arch/x86/kernel/apic/vector.c | 3 +++
>> arch/x86/kernel/i8259.c | 24
>> 3 files changed, 20 insertions(+), 8 deletions(-)
>>
>> diff --git a/arch/x86/include/asm/i8259.h b/arch/x86/include/asm/i8259.h
>> index ccffa53..bd55a77 100644
>> --- a/arch/x86/include/asm/i8259.h
>> +++ b/arch/x86/include/asm/i8259.h
>> @@ -60,6 +60,7 @@ struct legacy_pic {
>> void (*mask_all)(void);
>> void (*restore_mask)(void);
>> void (*init)(int auto_eoi);
>> +void (*probe)(void);
>> int (*irq_pending)(unsigned int irq);
>> void (*make_irq)(unsigned int irq);
>> };
>> diff --git a/arch/x86/kernel/apic/vector.c b/arch/x86/kernel/apic/vector.c
>> index 836d11b..aadd7ae 100644
>> --- a/arch/x86/kernel/apic/vector.c
>> +++ b/arch/x86/kernel/apic/vector.c
>> @@ -361,6 +361,9 @@ int __init arch_probe_nr_irqs(void)
>> if (nr < nr_irqs)
>> nr_irqs = nr;
>>
>> +/* nr_legecy_irqs() depends on the PIC presence */
>> +legacy_pic->probe();
>> +
>> return nr_legacy_irqs();
>> }
>>
>> diff --git a/arch/x86/kernel/i8259.c b/arch/x86/kernel/i8259.c
>> index 16cb827..96f1562 100644
>> --- a/arch/x86/kernel/i8259.c
>> +++ b/arch/x86/kernel/i8259.c
>> @@ -295,16 +295,11 @@ static void unmask_8259A(void)
>> raw_spin_unlock_irqrestore(&i8259A_lock, flags);
>> }
>>
>> -static void init_8259A(int auto_eoi)
>> +static void probe_8259A(void)
>> {
>> unsigned long flags;
>> unsigned char probe_val = ~(1 << PIC_CASCADE_IR);
>> unsigned char new_val;
>> -
>> -i8259A_auto_eoi = auto_eoi;
>> -
>> -raw_spin_lock_irqsave(&i8259A_lock, flags);
>> -
>> /*
>> * Check to see if we have a PIC.
>> * Mask all except the cascade and read
>> @@ -312,16 +307,27 @@ static void init_8259A(int auto_eoi)
>> * have a PIC, we will read 0xff as opposed to the
>> * value we wrote.
>> */
>> +raw_spin_lock_irqsave(&i8259A_lock, flags);
>> +
>> outb(0xff, PIC_SLAVE_IMR); /* mask all of 8259A-2 */
>> outb(probe_val, PIC_MASTER_IMR);
>> new_val = inb(PIC_MASTER_IMR);
>> if (new_val != probe_val) {
>> printk(KERN_INFO "Using NULL legacy PIC\n");
>> legacy_pic = &null_legacy_pic;
>> -raw_spin_unlock_irqrestore(&i8259A_lock, flags);
>> -return;
>> }
>>
>> +raw_spin_unlock_irqrestore(&i8259A_lock, flags);
>> +}
>> +
>> +static void init_8259A(int auto_eoi)
>> +{
>> +unsigned long flags;
>> +
>> +i8259A_auto_eoi = auto_eoi;
>> +
>> +raw_spin_lock_irqsave(&i8259A_lock, flags);
>> +
>> outb(0xff, PIC_MASTER_IMR); /* mask all of 8259A-1 */
>>
>> /*
>> @@ -388,6 +394,7 @@ struct legacy_pic null_legacy_pic = {
>> .mask_all = legacy_pic_noop,
>> .restore_mask = legacy_pic_noop,
>> .init = legacy_pic_int_noop,
>> +.probe = legacy_pic_noop,
>>
[PATCH v2] clk: Add clk_composite_set_rate_and_parent
From: Finley Xiao
When changing the clock-rate, currently a new parent is set first and a
divider adapted thereafter. This may result in the clock-rate overflowing
its target rate for a short time if the new parent has a higher rate than
the old parent.
While this often doesn't produce negative effects, it can affect components
in a voltage-scaling environment, like the GPU on the rk3399 socs, where
the voltage than simply is to low for the temporarily to high clock rate.
For general clock hirarchies this may need more extensive adaptions to
the common clock-framework, but at least for composite clocks having
both parent and rate settings it is easy to create a short-term solution to
make sure the clock-rate does not overflow the target.
Signed-off-by: Finley Xiao
Reviewed-by: Heiko Stuebner
---
v1->v2:
- change the commit message
drivers/clk/clk-composite.c | 33 +
1 file changed, 33 insertions(+)
diff --git a/drivers/clk/clk-composite.c b/drivers/clk/clk-composite.c
index 1f903e1f8..4d4b5ab 100644
--- a/drivers/clk/clk-composite.c
+++ b/drivers/clk/clk-composite.c
@@ -151,6 +151,33 @@ static int clk_composite_set_rate(struct clk_hw *hw,
unsigned long rate,
return rate_ops->set_rate(rate_hw, rate, parent_rate);
}
+static int clk_composite_set_rate_and_parent(struct clk_hw *hw,
+unsigned long rate,
+unsigned long parent_rate,
+u8 index)
+{
+ struct clk_composite *composite = to_clk_composite(hw);
+ const struct clk_ops *rate_ops = composite->rate_ops;
+ const struct clk_ops *mux_ops = composite->mux_ops;
+ struct clk_hw *rate_hw = composite->rate_hw;
+ struct clk_hw *mux_hw = composite->mux_hw;
+ unsigned long temp_rate;
+
+ __clk_hw_set_clk(rate_hw, hw);
+ __clk_hw_set_clk(mux_hw, hw);
+
+ temp_rate = rate_ops->recalc_rate(rate_hw, parent_rate);
+ if (temp_rate > rate) {
+ rate_ops->set_rate(rate_hw, rate, parent_rate);
+ mux_ops->set_parent(mux_hw, index);
+ } else {
+ mux_ops->set_parent(mux_hw, index);
+ rate_ops->set_rate(rate_hw, rate, parent_rate);
+ }
+
+ return 0;
+}
+
static int clk_composite_is_enabled(struct clk_hw *hw)
{
struct clk_composite *composite = to_clk_composite(hw);
@@ -250,6 +277,12 @@ struct clk *clk_register_composite(struct device *dev,
const char *name,
composite->rate_ops = rate_ops;
}
+ if (mux_hw && mux_ops && rate_hw && rate_ops) {
+ if (mux_ops->set_parent && rate_ops->set_rate)
+ clk_composite_ops->set_rate_and_parent =
+ clk_composite_set_rate_and_parent;
+ }
+
if (gate_hw && gate_ops) {
if (!gate_ops->is_enabled || !gate_ops->enable ||
!gate_ops->disable) {
--
1.9.1
Re: [PATCH v2] thermal: consistently use int for trip temp
On 2016年03月14日 17:44, Wei Ni wrote: > > > On 2016年03月09日 05:09, Eduardo Valentin wrote: >> On Tue, Mar 08, 2016 at 11:24:39AM +0800, Wei Ni wrote: >>> >>> >>> On 2016年03月07日 16:23, Wei Ni wrote: There had a build error in previous patch. Fixed it in this version. Please review it. >>> >>> Add CC: linux...@vger.kernel.org >>> > > Hi Rui, > Will you take this patch? Rui, could you please take a look this patch? > Thanks. Wei. On 2016年03月03日 17:33, Wei Ni wrote: > The commit 17e8351a7739 consistently use int for temperature, > however it missed a few in trip temperature and thermal_core. > > In current codes, the trip->temperature used "unsigned long" > and zone->temperature used"int", if the temperature is negative > value, it will get wrong result when compare temperature with > trip temperature. > > This patch can fix it. > > Signed-off-by: Wei Ni >> >> Rui are you collecting this one? >> >> Acked-by: Eduardo Valentin >> > -- > To unsubscribe from this list: send the line "unsubscribe linux-pm" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
Re: [PATCH 04/15] irqchip/gic: WARN if setting the interrupt type fails
On 11/04/16 16:39, Marc Zyngier wrote: > On 11/04/16 16:31, Jon Hunter wrote: >> On 09/04/16 11:58, Marc Zyngier wrote: [snip] >>> I think we need to phase things. Let's start with warning people for a >>> few kernel releases. Actively maintained platforms will quickly address >>> the issue (fixing their DT). As I see it, this issue seems rather >>> widespread (even kvmtool outputs a DT with the wrong triggering >>> information). >>> >>> Once we've fixed the bulk of the platforms and virtual environments, we >>> can start thinking about making it fail harder. >> >> Ok, so are you OK with this patch as-is? If so, can I add your ACK? > > It depends where you plan to handle the error. Ideally, I'd keep on > returning the error (because that's the right thing to do), and move the > WARN_ON() into the core code. We'd keep on ignoring the error as we're > doing today, but we'd scream about it. > > After a couple of releases, we'd turn the WARN_ON into a hard fail. > > Thoughts? I agree that would be best/ideal, but looking at it, I don't believe it is possible and this is why I have not done that so far. If we were to add the WARN to the core code, then we would need to add a warning everywhere __irq_set_trigger() is called. One of the places it is called today is from __setup_irq() and today this does the right thing and handle any error returned. The problem is that in irq_create_fwspec_mapping() we have never checked the return code from irq_set_irq_type() (which calls __irq_set_trigger()) or attempted to handle any errors. So the problem is that depending on the path through which the type is programmed, errors may or may not be detected. This is the actual headache :-( Given that this problem so far only pertains to GIC PPI interrupts and that it is a not a catastrophic error (interrupts still work fine), I was thinking we add the warning to the GIC driver. May be a less severe change would be to only return an error if configuring an SPI fails and if it is a PPI then simply WARN and carry-on as we assume we cannot change it. I hope this summarises the issue a bit further. Cheers Jon
Re: [PATCH V9 RESEND 13/14] arm64: tegra: add soctherm node for Tegra210
Could anyone take a look this patch? On 2016年04月01日 15:01, Wei Ni wrote: > Patches 1 to 12 in this series were accepted by Eduardo. > Patches 13 and 14 need to go via platform or dt tree. > > Used get_maintainer.pl to get maintainers and open list, add them in To: and > Cc: > list. > > To: > Rob Herring > Pawel Moll > Mark Rutland > Ian Campbell > Kumar Gala > > Cc: > devicet...@vger.kernel.org > > On 2016年03月29日 23:16, Eduardo Valentin wrote: >> On Tue, Mar 29, 2016 at 06:29:23PM +0800, Wei Ni wrote: >>> Adds soctherm node for Tegra210, and add cpu, >>> gpu, mem, pllx as thermal-zones. Set critical >>> trip temperatures for them. >>> >>> Signed-off-by: Wei Ni >> >> Acked-by: Eduardo Valentin >> > -- > To unsubscribe from this list: send the line "unsubscribe linux-pm" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
Re: [PATCH 1/1] iio: adc: Add driver for the TI INA3221 Triple Current/Voltage Monitor
On 12.04.2016 09:34, ji...@jic23.retrosnub.co.uk wrote: On 11.04.2016 19:08, Guenter Roeck wrote: On Mon, Apr 11, 2016 at 11:47:44AM -0500, Andrew F. Davis wrote: On 04/11/2016 11:38 AM, Guenter Roeck wrote: > On Mon, Apr 11, 2016 at 10:48:27AM -0500, Andrew F. Davis wrote: >> On 04/10/2016 06:57 AM, Jonathan Cameron wrote: >>> On 08/04/16 19:19, Andrew F. Davis wrote: The INA3221 is a three-channel, high-side current and bus voltage monitor with an I2C and SMBUS compatible interface. Signed-off-by: Andrew F. Davis >>> Hi Andrew, >>> >>> My immediate thought on this one is whether it would be better off in hwmon. >>> I'm not convinced either way from a quick glance at the data sheet, but the >>> question needs to be addressed. >>> >> >> I was on the fence with this also, I was leaning towards hwmod until I >> looked onto how the ina2xx driver has been ported to iio. This is almost >> the same part but the ina3x has three monitors vs one. In addition it >> looks like NVIDIA has written a hwmod driver for this part >> (https://github.com/Bogdacutu/STLinux-Kernel/blob/master/drivers/hwmon/ina3221.c) >> but then also ported it over to IIO (although doesn't appear to be >> upstream ready or ever has been submitted for such) >> (https://github.com/SuperPichu/shield-tablet-kernel/blob/master/drivers/staging/iio/meter/ina3221.c) >> So I figured this was the way things are moving, but I have no problem >> working this as a hwmod driver. The IIO work is already done here, I'll >> write the hwmod version also but keep working this, I see no reason we >> cant have both if needed. (unless using this and just using iio_hwmod.c >> if needed is more acceptable?) >> > > You can not have both since they would conflict with each other. > ina2xx has possibly created a bad precedent. I am not inclined to accept > a hwmon driver if an iio driver already exists. If you want an iio driver, > fine with me, but then you (and its users) will have to live with its > limitations when it comes to hardware monitoring. > Hmm, my plan was an MFD device core, that then could mediate the two sub-drivers, but I'm not sure about this yet. mfd is intended to separate multi-function devices, not multiple linux subsystems accessing the same logical functionality in a chip just because the subsystems don't have a means to communicate with each other. I don't think using mfd for this purpose is a good idea; someone would have to work hard to convince me that it is. > I don't really mind if things are going all towards iio if that is where > the community wants to go. However, if that is the case, I would suggest > that someone should spend the time to define a clear sense of 'limits' > as well as alert handling in iio, in a way that is exportable to other > subsystems (hwmon and thermal come into mind). > I agree. I think both frameworks offer useful interfaces, so I would hate to limit users to one, but for now I'll just post the hwmon version here in a bit and live with that until someone requests the IIO support. Ultimately it might make sense to create a hwmon->iio bridge in the hwmon core (just like it would make sense to create a hwmon->thermal bridge). This way drivers could be implemented whereever it is more convenient, and where the primary use case fits best. The basic idea would be for a hwmon driver to register with a flag such as "register with the iio subsystem as well". However, that would require substantial structural changes (or call it modernization) of the hwmon driver core API. Unfortunately, that is unlikely to happen anytime soon - I don't have the time, and no one else seems to show much interest in hwmon lately. So instead of doing that, people end up writing drivers for the same chip in multiple subsystems, and end up with limitations one way or another. ina2xx is a perfect example. The aim from the IIO side was to take a kind of different approach to this. Original suggest was Mark Brown's (I like to blame him whenever possible ;). His usecase was SoC ADCs where one single ADC is commonly used to do a whole load of parallel tasks. It's not uncommon to have one logic block doing, touchscreen, hwmon and general purpose ADC channels. Anyhow, what he brought up is that, as we were adding the ability to have other consumers of IIO data in the kernel we can separate the backend from the front end. The backend : * Handles the hardware providing any of: - polled data access (possibly including faking this when the driver is in an exclusive push data mode - which is common) - pushed data access - demuxing to consumer drivers so they only see the channels they want. - events (not yet done) - demuxing included. * Doesn't provide any userspace interface at all - other than tools to create soft mappings of channel sets to client drivers. The frontend (IIO one) * Userspace side of things - including say kfifo's for pushing out data. - sysfs interfaces for
Re: [PATCH V9 RESEND 14/14] arm: tegra: set critical trips for Tegra124
Could anyone take a look at this patch? On 2016年04月01日 15:04, Wei Ni wrote: > To: > Rob Herring > Pawel Moll > Mark Rutland > Ian Campbell > Kumar Gala > > Cc: > devicet...@vger.kernel.org > > On 2016年03月29日 23:17, Eduardo Valentin wrote: >> On Tue, Mar 29, 2016 at 06:29:24PM +0800, Wei Ni wrote: >>> Set general "critical" trip temperatures for cpu, gpu, mem and pllx >>> thermal zones for all Tegra124 platform, these trips can trigger >>> shut down or reset. >>> Tegra124 Jetson TK1 was already set "critical" trips before, so it >>> can overwrite the general values. >>> >>> Signed-off-by: Wei Ni >> >> Acked-by: Eduardo Valentin >> > -- > To unsubscribe from this list: send the line "unsubscribe linux-pm" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
Re: [PATCH 14/15] dt-bindings: arm-gic: Drop 'clock-names' from binding document
Rob, Mark, Marc,
On 18/03/16 08:37, Jon Hunter wrote:
>
> On 17/03/16 20:14, Rob Herring wrote:
>> On Thu, Mar 17, 2016 at 9:19 AM, Jon Hunter wrote:
>>> Commit afbbd2338176 ("irqchip/gic: Document optional Clock and Power
>>> Domain properties") documented optional clock and power-dmoain properties
>>> for the ARM GIC. Currently, there are no users of these and for the
>>> Tegra210 Audio GIC (based upon the GIC-400) there are two clocks, a
>>> functional clock and interface clock, that need to be enabled.
>>>
>>> To allow flexibility, drop the 'clock-names' from the GIC binding and
>>> just provide a list of clocks which the driver can parse. It is assumed
>>> that any clocks that are listed, need to be enabled in order to access
>>> the GIC.
>>>
>>> Signed-off-by: Jon Hunter
>>>
>>> ---
>>>
>>> Please note that I am not sure if this will be popular, but I am trying
>>> to come up with a generic way to handle multiple clocks that may be
>>> required for accessing a GIC.
>>
>> It's not. :)
>>
>> We need to specify the number and order of clocks by compatible string
>> at a minimum. Sadly, ARM's GICs are well documented and include clock
>> names, so you can't just make up genericish names either which is
>> probably often the case.
>
> Do you have any suggestions then?
>
> I have had a look at the ARM TRMs and although I see that they do show
> the functional clock, there is no mention of whether there are any other
> clocks need in order to interface to the GIC (ie. bus clock). I know
> that for other SoCs such as OMAP it is common to have both a functional
> clock and interface clock. So I believe this is fairly common.
Any thoughts on how I should handle this for the Tegra AGIC?
Cheers
Jon
[PATCH] coresight: etm4x: modify q_support type
Because this operation exceed the range of boolean, so we should
modify q_support to unit32 bit.
drvdata->q_support = BMVAL(etmidr0, 15, 16)
Signed-off-by: Li Pengcheng
Signed-off-by: Li Zhong
---
drivers/hwtracing/coresight/coresight-etm4x.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwtracing/coresight/coresight-etm4x.h
b/drivers/hwtracing/coresight/coresight-etm4x.h
index c341002..305b29a 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x.h
+++ b/drivers/hwtracing/coresight/coresight-etm4x.h
@@ -330,7 +330,7 @@ struct etmv4_drvdata {
u32 ccctlr;
booltrcbb;
u32 bb_ctrl;
- boolq_support;
+ u32 q_support;
u32 vinst_ctrl;
u32 viiectlr;
u32 vissctlr;
--
1.8.3.2
Re: mmotm woes, mainly compaction
On 04/12/2016 09:18 AM, Hugh Dickins wrote:
> 3. /proc/sys/vm/stat_refresh warns nr_isolated_anon and nr_isolated_file
> go increasingly negative under compaction: which would add delay when
> should be none, or no delay when should delay. putback_movable_pages()
> decrements the NR_ISOLATED counts which acct_isolated() increments,
> so isolate_migratepages_block() needs to acct before putback in that
> special case, and isolate_migratepages_range() can always do the acct
> itself, leaving migratepages putback to caller like most other places.
The isolate_migratepages_block() part is mmotm-specific, so I'll split
it out in this patch. Thanks for catching it and the lack of reset for
cc->nr_migratepages which wasn't mentioned in changelog so I added it.
> 5. It's easier to track the life of cc->migratepages if we don't assign
> it to a migratelist variable.
This is also included here.
This is a -fix for:
mm-compaction-skip-blocks-where-isolation-fails-in-async-direct-compaction.patch
8<
>From 59a0075b6cf85045aa2dc5cee1f27797bcd0b3d2 Mon Sep 17 00:00:00 2001
From: Hugh Dickins
Date: Tue, 12 Apr 2016 10:51:20 +0200
Subject: [PATCH] mm, compaction: prevent nr_isolated_* from going negative
/proc/sys/vm/stat_refresh warns nr_isolated_anon and nr_isolated_file
go increasingly negative under compaction: which would add delay when
should be none, or no delay when should delay. putback_movable_pages()
decrements the NR_ISOLATED counts which acct_isolated() increments,
so isolate_migratepages_block() needs to acct before putback in that
special case. It's also useful to reset cc->nr_migratepages after putback
so we don't needlessly return too early on the COMPACT_CLUSTER_MAX check.
Also it's easier to track the life of cc->migratepages if we don't assign
it to a migratelist variable.
---
mm/compaction.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/mm/compaction.c b/mm/compaction.c
index 67f886ecd773..ab649fba3d88 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -638,7 +638,6 @@ isolate_migratepages_block(struct compact_control *cc,
unsigned long low_pfn,
{
struct zone *zone = cc->zone;
unsigned long nr_scanned = 0, nr_isolated = 0;
- struct list_head *migratelist = &cc->migratepages;
struct lruvec *lruvec;
unsigned long flags = 0;
bool locked = false;
@@ -817,7 +816,7 @@ isolate_migratepages_block(struct compact_control *cc,
unsigned long low_pfn,
del_page_from_lru_list(page, lruvec, page_lru(page));
isolate_success:
- list_add(&page->lru, migratelist);
+ list_add(&page->lru, &cc->migratepages);
cc->nr_migratepages++;
nr_isolated++;
@@ -851,9 +850,11 @@ isolate_migratepages_block(struct compact_control *cc,
unsigned long low_pfn,
spin_unlock_irqrestore(&zone->lru_lock, flags);
locked = false;
}
- putback_movable_pages(migratelist);
- nr_isolated = 0;
+ acct_isolated(zone, cc);
+ putback_movable_pages(&cc->migratepages);
+ cc->nr_migratepages = 0;
cc->last_migrated_pfn = 0;
+ nr_isolated = 0;
}
if (low_pfn < next_skip_pfn) {
--
2.8.1
[PATCH v2 2/2] perf tools: Fix kallsyms perf test on ppc64le
ppc64le functions have a Global Entry Point (GEP) and a Local Entry
Point (LEP). While placing a probe, we always prefer the LEP since it
catches function calls through both the GEP and the LEP. In order to do
this, we fixup the function entry points during elf symbol table lookup
to point to the LEPs. This works, but breaks 'perf test kallsyms' since
the symbols loaded from the symbol table (pointing to the LEP) do not
match the symbols in kallsyms.
To fix this, we do not adjust all the symbols during symbol table load.
Instead, we note down st_other in a newly introduced arch-specific
member of perf symbol structure, and later use this to adjust the probe
trace point.
Cc: Mark Wielaard
Cc: Thiago Jung Bauermann
Cc: Arnaldo Carvalho de Melo
Cc: Masami Hiramatsu
Cc: Balbir Singh
Acked-by: Ananth N Mavinakayanahalli
Reported-by: Michael Ellerman
Signed-off-by: Naveen N. Rao
---
v2: Added uprobes handling -- we modify the probe address, rather than
the offset.
tools/perf/arch/powerpc/util/sym-handling.c | 28
tools/perf/util/probe-event.c | 5 +++--
tools/perf/util/probe-event.h | 3 ++-
tools/perf/util/symbol-elf.c| 7 ---
tools/perf/util/symbol.h| 3 ++-
5 files changed, 31 insertions(+), 15 deletions(-)
diff --git a/tools/perf/arch/powerpc/util/sym-handling.c
b/tools/perf/arch/powerpc/util/sym-handling.c
index 6974ba0..c6d0f91 100644
--- a/tools/perf/arch/powerpc/util/sym-handling.c
+++ b/tools/perf/arch/powerpc/util/sym-handling.c
@@ -19,12 +19,6 @@ bool elf__needs_adjust_symbols(GElf_Ehdr ehdr)
ehdr.e_type == ET_DYN;
}
-#if defined(_CALL_ELF) && _CALL_ELF == 2
-void arch__elf_sym_adjust(GElf_Sym *sym)
-{
- sym->st_value += PPC64_LOCAL_ENTRY_OFFSET(sym->st_other);
-}
-#endif
#endif
#if !defined(_CALL_ELF) || _CALL_ELF != 2
@@ -65,11 +59,21 @@ bool arch__prefers_symtab(void)
return true;
}
+#ifdef HAVE_LIBELF_SUPPORT
+void arch__sym_update(struct symbol *s, GElf_Sym *sym)
+{
+ s->arch_sym = sym->st_other;
+}
+#endif
+
#define PPC64LE_LEP_OFFSET 8
void arch__fix_tev_from_maps(struct perf_probe_event *pev,
-struct probe_trace_event *tev, struct map *map)
+struct probe_trace_event *tev, struct map *map,
+struct symbol *sym)
{
+ int lep_offset;
+
/*
* When probing at a function entry point, we normally always want the
* LEP since that catches calls to the function through both the GEP and
@@ -82,10 +86,18 @@ void arch__fix_tev_from_maps(struct perf_probe_event *pev,
*
* In addition, we shouldn't specify an offset for kretprobes.
*/
- if (pev->point.offset || pev->point.retprobe || !map)
+ if (pev->point.offset || pev->point.retprobe || !map || !sym)
return;
+ lep_offset = PPC64_LOCAL_ENTRY_OFFSET(sym->arch_sym);
+
if (map->dso->symtab_type == DSO_BINARY_TYPE__KALLSYMS)
tev->point.offset += PPC64LE_LEP_OFFSET;
+ else if (lep_offset) {
+ if (pev->uprobes)
+ tev->point.address += lep_offset;
+ else
+ tev->point.offset += lep_offset;
+ }
}
#endif
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 8319fbb..d786a49 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -2498,7 +2498,8 @@ static int find_probe_functions(struct map *map, char
*name,
void __weak arch__fix_tev_from_maps(struct perf_probe_event *pev
__maybe_unused,
struct probe_trace_event *tev __maybe_unused,
- struct map *map __maybe_unused) { }
+ struct map *map __maybe_unused,
+ struct symbol *sym __maybe_unused) { }
/*
* Find probe function addresses from map.
@@ -2624,7 +2625,7 @@ static int find_probe_trace_events_from_map(struct
perf_probe_event *pev,
strdup_or_goto(pev->args[i].type,
nomem_out);
}
- arch__fix_tev_from_maps(pev, tev, map);
+ arch__fix_tev_from_maps(pev, tev, map, sym);
}
if (ret == skipped) {
ret = -ENOENT;
diff --git a/tools/perf/util/probe-event.h b/tools/perf/util/probe-event.h
index e54e7b0..9bbc0c1 100644
--- a/tools/perf/util/probe-event.h
+++ b/tools/perf/util/probe-event.h
@@ -154,7 +154,8 @@ int show_available_vars(struct perf_probe_event *pevs, int
npevs,
int show_available_funcs(const char *module, struct strfilter *filter, bool
user);
bool arch__prefers_symtab(void);
void arch__fix_tev_from_maps(struct perf_probe_event *pev,
-struct probe_trace_event *tev, struct map *map);
+
[PATCH v2 0/2] perf probe fixes for ppc64le
This patchset fixes three issues found with perf probe on ppc64le: 1. 'perf test kallsyms' failure on ppc64le (reported by Michael Ellerman). This was due to the symbols being fixed up during symbol table load. This is fixed in patch 2 by delaying symbol fixup until later. 2. perf probe function offset was being calculated from the local entry point (LEP), which does not match user expectation when trying to look at function disassembly output (reported by Ananth N). This is fixed for kallsyms in patch 1 and for symbol table in patch 2. 3. perf probe failure with kretprobe when using kallsyms. This was failing as we were specifying an offset. This is fixed in patch 1. A few examples demonstrating the issues and the fix: Example for issue (2): # objdump -d vmlinux | grep -A8 \<_do_fork\>: c00b6a00 <_do_fork>: c00b6a00: f7 00 4c 3c addis r2,r12,247 c00b6a04: 00 86 42 38 addir2,r2,-31232 c00b6a08: a6 02 08 7c mflrr0 c00b6a0c: d0 ff 41 fb std r26,-48(r1) c00b6a10: 26 80 90 7d mfocrf r12,8 c00b6a14: d8 ff 61 fb std r27,-40(r1) c00b6a18: e0 ff 81 fb std r28,-32(r1) c00b6a1c: e8 ff a1 fb std r29,-24(r1) # perf probe -v _do_fork+4 probe-definition(0): _do_fork+4 symbol:_do_fork file:(null) line:0 offset:4 return:0 lazy:(null) 0 arguments Looking at the vmlinux_path (8 entries long) Using /proc/kcore for kernel object code Using /proc/kallsyms for symbols Opening /sys/kernel/debug/tracing//kprobe_events write=1 Writing event: p:probe/_do_fork _text+748044 Added new event: probe:_do_fork (on _do_fork+4) You can now use it in all perf tools, such as: perf record -e probe:_do_fork -aR sleep 1 # printf "%x\n" 748044 b6a0c ^ This is offset from the LEP. With this, there is also no way to ever probe between the GEP and the LEP. With this patchset: # perf probe -v _do_fork+4 probe-definition(0): _do_fork+4 symbol:_do_fork file:(null) line:0 offset:4 return:0 lazy:(null) 0 arguments Looking at the vmlinux_path (8 entries long) Using /proc/kcore for kernel object code Using /proc/kallsyms for symbols Opening /sys/kernel/debug/tracing//kprobe_events write=1 Writing event: p:probe/_do_fork _text+748036 Added new event: probe:_do_fork (on _do_fork+4) You can now use it in all perf tools, such as: perf record -e probe:_do_fork -aR sleep 1 # perf probe -v _do_fork probe-definition(0): _do_fork symbol:_do_fork file:(null) line:0 offset:0 return:0 lazy:(null) 0 arguments Looking at the vmlinux_path (8 entries long) Using /proc/kcore for kernel object code Using /proc/kallsyms for symbols Opening /sys/kernel/debug/tracing//kprobe_events write=1 Writing event: p:probe/_do_fork _text+748040 Added new event: probe:_do_fork (on _do_fork) You can now use it in all perf tools, such as: perf record -e probe:_do_fork -aR sleep 1 We only offset to the LEP if function entry is specified, otherwise, we offset from the GEP. Example for issue (3): - Before patch: # perf probe -v _do_fork:%return probe-definition(0): _do_fork:%return symbol:_do_fork file:(null) line:0 offset:0 return:1 lazy:(null) 0 arguments Looking at the vmlinux_path (8 entries long) Using /proc/kcore for kernel object code Using /proc/kallsyms for symbols Opening /sys/kernel/debug/tracing//kprobe_events write=1 Writing event: r:probe/_do_fork _do_fork+8 Failed to write event: Invalid argument Error: Failed to add events. Reason: Invalid argument (Code: -22) After patch: # perf probe _do_fork:%return Added new event: probe:_do_fork (on _do_fork%return) You can now use it in all perf tools, such as: perf record -e probe:_do_fork -aR sleep 1 Concept Acked-by: Michael Ellerman Cc: Mark Wielaard Cc: Thiago Jung Bauermann Cc: Arnaldo Carvalho de Melo Cc: Masami Hiramatsu Cc: Michael Ellerman Cc: Balbir Singh Cc: Ananth N Mavinakayanahalli Naveen N. Rao (2): perf tools: Fix kprobe and kretprobe handling with kallsyms on ppc64le perf tools: Fix kallsyms perf test on ppc64le tools/perf/arch/powerpc/util/sym-handling.c | 43 + tools/perf/util/probe-event.c | 5 ++-- tools/perf/util/probe-event.h | 3 +- tools/perf/util/symbol-elf.c| 7 +++-- tools/perf/util/symbol.h| 3 +- 5 files changed, 43 insertions(+), 18 deletions(-) -- 2.7.4
[PATCH v2 1/2] perf tools: Fix kprobe and kretprobe handling with kallsyms on ppc64le
So far, we used to treat probe point offsets as being offset from the
LEP. However, userspace applications (objdump/readelf) always show
disassembly and offsets from the function GEP. This is confusing to the
user as we will end up probing at an address different from what the
user expects when looking at the function disassembly with
readelf/objdump. Fix this by changing how we modify probe address with
perf.
If only the function name is provided, we assume the user needs the LEP.
Otherwise, if an offset is specified, we assume that the user knows the
exact address to probe based on function disassembly, and so we just
place the probe from the GEP offset.
Finally, kretprobe was also broken with kallsyms as we were trying to
specify an offset. This patch also fixes that issue.
Cc: Mark Wielaard
Cc: Thiago Jung Bauermann
Cc: Arnaldo Carvalho de Melo
Cc: Masami Hiramatsu
Cc: Michael Ellerman
Cc: Balbir Singh
Reported-by: Ananth N Mavinakayanahalli
Signed-off-by: Naveen N. Rao
---
v2: Removed un-necessary check for uprobes
tools/perf/arch/powerpc/util/sym-handling.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/tools/perf/arch/powerpc/util/sym-handling.c
b/tools/perf/arch/powerpc/util/sym-handling.c
index bbc1a50..6974ba0 100644
--- a/tools/perf/arch/powerpc/util/sym-handling.c
+++ b/tools/perf/arch/powerpc/util/sym-handling.c
@@ -71,12 +71,21 @@ void arch__fix_tev_from_maps(struct perf_probe_event *pev,
struct probe_trace_event *tev, struct map *map)
{
/*
-* ppc64 ABIv2 local entry point is currently always 2 instructions
-* (8 bytes) after the global entry point.
+* When probing at a function entry point, we normally always want the
+* LEP since that catches calls to the function through both the GEP and
+* the LEP. Hence, we would like to probe at an offset of 8 bytes if
+* the user only specified the function entry.
+*
+* However, if the user specifies an offset, we fall back to using the
+* GEP since all userspace applications (objdump/readelf) show function
+* disassembly with offsets from the GEP.
+*
+* In addition, we shouldn't specify an offset for kretprobes.
*/
- if (!pev->uprobes && map->dso->symtab_type ==
DSO_BINARY_TYPE__KALLSYMS) {
- tev->point.address += PPC64LE_LEP_OFFSET;
+ if (pev->point.offset || pev->point.retprobe || !map)
+ return;
+
+ if (map->dso->symtab_type == DSO_BINARY_TYPE__KALLSYMS)
tev->point.offset += PPC64LE_LEP_OFFSET;
- }
}
#endif
--
2.7.4
Re: mmotm woes, mainly compaction
On 04/12/2016 11:03 AM, Vlastimil Babka wrote:
On 04/12/2016 09:18 AM, Hugh Dickins wrote:
3. /proc/sys/vm/stat_refresh warns nr_isolated_anon and nr_isolated_file
go increasingly negative under compaction: which would add delay when
should be none, or no delay when should delay. putback_movable_pages()
decrements the NR_ISOLATED counts which acct_isolated() increments,
so isolate_migratepages_block() needs to acct before putback in that
special case, and isolate_migratepages_range() can always do the acct
itself, leaving migratepages putback to caller like most other places.
The isolate_migratepages_block() part is mmotm-specific, so I'll split
it out in this patch. Thanks for catching it and the lack of reset for
cc->nr_migratepages which wasn't mentioned in changelog so I added it.
5. It's easier to track the life of cc->migratepages if we don't assign
it to a migratelist variable.
This is also included here.
This is a -fix for:
mm-compaction-skip-blocks-where-isolation-fails-in-async-direct-compaction.patch
8<
From 59a0075b6cf85045aa2dc5cee1f27797bcd0b3d2 Mon Sep 17 00:00:00 2001
From: Hugh Dickins
Date: Tue, 12 Apr 2016 10:51:20 +0200
Subject: [PATCH] mm, compaction: prevent nr_isolated_* from going negative
/proc/sys/vm/stat_refresh warns nr_isolated_anon and nr_isolated_file
go increasingly negative under compaction: which would add delay when
should be none, or no delay when should delay. putback_movable_pages()
decrements the NR_ISOLATED counts which acct_isolated() increments,
so isolate_migratepages_block() needs to acct before putback in that
special case. It's also useful to reset cc->nr_migratepages after putback
so we don't needlessly return too early on the COMPACT_CLUSTER_MAX check.
Also it's easier to track the life of cc->migratepages if we don't assign
it to a migratelist variable.
Forgot
Signed-off-by: Vlastimil Babka
---
mm/compaction.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/mm/compaction.c b/mm/compaction.c
index 67f886ecd773..ab649fba3d88 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -638,7 +638,6 @@ isolate_migratepages_block(struct compact_control *cc,
unsigned long low_pfn,
{
struct zone *zone = cc->zone;
unsigned long nr_scanned = 0, nr_isolated = 0;
- struct list_head *migratelist = &cc->migratepages;
struct lruvec *lruvec;
unsigned long flags = 0;
bool locked = false;
@@ -817,7 +816,7 @@ isolate_migratepages_block(struct compact_control *cc,
unsigned long low_pfn,
del_page_from_lru_list(page, lruvec, page_lru(page));
isolate_success:
- list_add(&page->lru, migratelist);
+ list_add(&page->lru, &cc->migratepages);
cc->nr_migratepages++;
nr_isolated++;
@@ -851,9 +850,11 @@ isolate_migratepages_block(struct compact_control *cc,
unsigned long low_pfn,
spin_unlock_irqrestore(&zone->lru_lock, flags);
locked = false;
}
- putback_movable_pages(migratelist);
- nr_isolated = 0;
+ acct_isolated(zone, cc);
+ putback_movable_pages(&cc->migratepages);
+ cc->nr_migratepages = 0;
cc->last_migrated_pfn = 0;
+ nr_isolated = 0;
}
if (low_pfn < next_skip_pfn) {
[PATCH 2/2 v5] arc: axs10x: Add DT bindings for I2S PLL Clock
Add device tree bindings for AXS10X I2S PLL Clock driver.
Signed-off-by: Jose Abreu
---
This patch was only introduced in v5.
arch/arc/boot/dts/axs10x_mb.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arc/boot/dts/axs10x_mb.dtsi b/arch/arc/boot/dts/axs10x_mb.dtsi
index ab5d570..227b215 100644
--- a/arch/arc/boot/dts/axs10x_mb.dtsi
+++ b/arch/arc/boot/dts/axs10x_mb.dtsi
@@ -16,6 +16,12 @@
ranges = <0x 0xe000 0x1000>;
interrupt-parent = <&mb_intc>;
+ i2sclk: i2sclk@100a0 {
+ compatible = "snps,axs10x-i2s-pll-clock";
+ reg = <0x100a0 0x10>;
+ #clock-cells = <0>;
+ };
+
clocks {
i2cclk: i2cclk {
compatible = "fixed-clock";
--
1.9.1
[PATCH 0/2 v5] Add AXS10X I2S PLL clock driver
The ARC SDP I2S clock can be programmed using a
specific PLL.
This patch series has the goal of adding a clock driver
that programs this PLL.
Changes v4 -> v5:
* Documentation update (as suggested by Alexey Brodkin)
* Changed compatible string to "snps,axs10x-i2s-pll-clock" (as suggested by
Alexey Brodkin)
* Added DT bindings
Changes v3 -> v4:
* Added binding document (as suggested by Stephen Boyd)
* Minor code style fixes (as suggested by Stephen Boyd)
* Use ioremap (as suggested by Stephen Boyd)
* Implement round_rate (as suggested by Stephen Boyd)
* Change to platform driver (as suggested by Stephen Boyd)
* Use {readl/writel}_relaxed (as suggested by Vineet Gupta)
Changes v2 -> v3:
* Implemented recalc_rate
Changes v1 -> v2:
* Renamed folder to axs10x (as suggested by Alexey Brodkin)
* Added more supported rates
Jose Abreu (2):
clk/axs10x: Add I2S PLL clock driver
arc: axs10x: Add DT bindings for I2S PLL Clock
.../bindings/clock/axs10x-i2s-pll-clock.txt| 17 ++
arch/arc/boot/dts/axs10x_mb.dtsi | 6 +
drivers/clk/Makefile | 1 +
drivers/clk/axs10x/Makefile| 1 +
drivers/clk/axs10x/i2s_pll_clock.c | 217 +
5 files changed, 242 insertions(+)
create mode 100644
Documentation/devicetree/bindings/clock/axs10x-i2s-pll-clock.txt
create mode 100644 drivers/clk/axs10x/Makefile
create mode 100644 drivers/clk/axs10x/i2s_pll_clock.c
--
1.9.1
[PATCH 1/2 v5] clk/axs10x: Add I2S PLL clock driver
The ARC SDP I2S clock can be programmed using a
specific PLL.
This patch has the goal of adding a clock driver
that programs this PLL.
At this moment the rate values are hardcoded in
a table but in the future it would be ideal to
use a function which determines the PLL values
given the desired rate.
Signed-off-by: Jose Abreu
---
Changes v4 -> v5:
* Documentation update (as suggested by Alexey Brodkin)
* Changed compatible string to "snps,axs10x-i2s-pll-clock" (as suggested by
Alexey Brodkin)
Changes v3 -> v4:
* Added binding document (as suggested by Stephen Boyd)
* Minor code style fixes (as suggested by Stephen Boyd)
* Use ioremap (as suggested by Stephen Boyd)
* Implement round_rate (as suggested by Stephen Boyd)
* Change to platform driver (as suggested by Stephen Boyd)
* Use {readl/writel}_relaxed (as suggested by Vineet Gupta)
Changes v2 -> v3:
* Implemented recalc_rate
Changes v1 -> v2:
* Renamed folder to axs10x (as suggested by Alexey Brodkin)
* Added more supported rates
.../bindings/clock/axs10x-i2s-pll-clock.txt| 17 ++
drivers/clk/Makefile | 1 +
drivers/clk/axs10x/Makefile| 1 +
drivers/clk/axs10x/i2s_pll_clock.c | 217 +
4 files changed, 236 insertions(+)
create mode 100644
Documentation/devicetree/bindings/clock/axs10x-i2s-pll-clock.txt
create mode 100644 drivers/clk/axs10x/Makefile
create mode 100644 drivers/clk/axs10x/i2s_pll_clock.c
diff --git a/Documentation/devicetree/bindings/clock/axs10x-i2s-pll-clock.txt
b/Documentation/devicetree/bindings/clock/axs10x-i2s-pll-clock.txt
new file mode 100644
index 000..6879e81
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/axs10x-i2s-pll-clock.txt
@@ -0,0 +1,17 @@
+Binding for the AXS10X I2S PLL clock
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible: shall be "snps,axs10x-i2s-pll-clock"
+- #clock-cells: from common clock binding; Should always be set to 0.
+- reg : Address and length of the I2S PLL register set.
+
+Example:
+ i2s_clock@100a0 {
+ compatible = "snps,axs10x-i2s-pll-clock";
+ reg = <0x100a0 0x10>;
+ #clock-cells = <0>;
+ };
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 46869d6..2ca62dc6 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -84,3 +84,4 @@ obj-$(CONFIG_X86) += x86/
obj-$(CONFIG_ARCH_ZX) += zte/
obj-$(CONFIG_ARCH_ZYNQ)+= zynq/
obj-$(CONFIG_H8300)+= h8300/
+obj-$(CONFIG_ARC_PLAT_AXS10X) += axs10x/
diff --git a/drivers/clk/axs10x/Makefile b/drivers/clk/axs10x/Makefile
new file mode 100644
index 000..01996b8
--- /dev/null
+++ b/drivers/clk/axs10x/Makefile
@@ -0,0 +1 @@
+obj-y += i2s_pll_clock.o
diff --git a/drivers/clk/axs10x/i2s_pll_clock.c
b/drivers/clk/axs10x/i2s_pll_clock.c
new file mode 100644
index 000..1267b5b
--- /dev/null
+++ b/drivers/clk/axs10x/i2s_pll_clock.c
@@ -0,0 +1,217 @@
+/*
+ * Synopsys AXS10X SDP I2S PLL clock driver
+ *
+ * Copyright (C) 2016 Synopsys
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* FPGA Version Info */
+#define FPGA_VER_INFO 0xE0011230
+#define FPGA_VER_27M 0x000FBED9
+
+/* PLL registers addresses */
+#define PLL_IDIV_REG 0x0
+#define PLL_FBDIV_REG 0x4
+#define PLL_ODIV0_REG 0x8
+#define PLL_ODIV1_REG 0xC
+
+struct i2s_pll_cfg {
+ unsigned int rate;
+ unsigned int idiv;
+ unsigned int fbdiv;
+ unsigned int odiv0;
+ unsigned int odiv1;
+};
+
+static const struct i2s_pll_cfg i2s_pll_cfg_27m[] = {
+ /* 27 Mhz */
+ { 1024000, 0x104, 0x451, 0x10E38, 0x2000 },
+ { 1411200, 0x104, 0x596, 0x10D35, 0x2000 },
+ { 1536000, 0x208, 0xA28, 0x10B2C, 0x2000 },
+ { 2048000, 0x82, 0x451, 0x10E38, 0x2000 },
+ { 2822400, 0x82, 0x596, 0x10D35, 0x2000 },
+ { 3072000, 0x104, 0xA28, 0x10B2C, 0x2000 },
+ { 2116800, 0x82, 0x3CF, 0x10C30, 0x2000 },
+ { 2304000, 0x104, 0x79E, 0x10B2C, 0x2000 },
+ { 0, 0, 0, 0, 0 },
+};
+
+static const struct i2s_pll_cfg i2s_pll_cfg_28m[] = {
+ /* 28.224 Mhz */
+ { 1024000, 0x82, 0x105, 0x107DF, 0x2000 },
+ { 1411200, 0x28A, 0x1, 0x10001, 0x2000 },
+ { 1536000, 0xA28, 0x187, 0x10042, 0x2000 },
+ { 2048000, 0x41, 0x105, 0x107DF, 0x2000 },
+ { 2822400, 0x145, 0x1, 0x10001, 0x2000 },
+ { 3072000, 0x514, 0x187, 0x10042, 0x2000 },
+ { 2116800, 0x514, 0x42, 0x10001, 0x2000 },
+ { 2304000, 0x619, 0x82, 0x10001, 0x2000 },
+ { 0, 0, 0, 0, 0 },
+};
+
+struct i2s_pll_clk {
+ void __i
Re: [PATCH v2 2/5] ARM: STi: DT: STiH407: Enable Mailbox testing facility
Hi Lee,
On 23/03/16 14:43, Lee Jones wrote:
This patch supplies a Client node to enable the Mailbox testing
facility. It will be used to send and receive messages from any
given co-processor in order to test the STi Mailbox Controller
driver.
Signed-off-by: Lee Jones
---
arch/arm/boot/dts/stih407-family.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/stih407-family.dtsi
b/arch/arm/boot/dts/stih407-family.dtsi
index e6e34b4..9376c38 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -695,6 +695,12 @@
status = "okay";
};
+ mailbox_test {
+ compatible = "mailbox_test";
IIRC, we changed this to "mailbox-text" ?
--
Regards,
Sudeep
Re: [PATCH v2 04/16] arm64: dts: Add Hi6220 gpio configuration nodes
On 4 April 2016 at 03:28, Linus Walleij wrote:
> On Sat, Apr 2, 2016 at 11:29 AM, Guodong Xu wrote:
>
>> From: Zhong Kaihua
>>
>> Add Hi6220 gpio configuration nodes
>>
>> Signed-off-by: Zhong Kaihua
>> Signed-off-by: Kong Xinwei
>>
>
> Get rid of that blank line.
Will fix.
Sorry missed that in v3.
>
>> Acked-by: Rob Herring
>> Signed-off-by: Wei Xu
>
>> +++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
>> @@ -249,5 +249,264 @@
>> clocks = <&ao_ctrl 27>;
>> clock-names = "apb_pclk";
>> };
>> +
>> + gpio0: gpio@f8011000 {
>> + compatible = "arm,pl061", "arm,primecell";
>> + reg = <0x0 0xf8011000 0x0 0x1000>;
>> + interrupts = <0 52 0x4>;
>> + gpio-controller;
>> + #gpio-cells = <2>;
>> + interrupt-controller;
>> + #interrupt-cells = <2>;
>> + clocks = <&ao_ctrl 2>;
>> + clock-names = "apb_pclk";
>> + status = "ok";
>> + };
>
> This part with all GPIO controllers looks nice.
>
>> new file mode 100644
>> index 000..09242f0
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/hisilicon/hikey-gpio.dtsi
>> @@ -0,0 +1,607 @@
>> +/ {
>> + gpio_rstout_n:gpio_rstout_n {
>> + gpios;
>> + };
>> + gpio_pmu_peri_en:gpio_pmu_peri_en {
>> + gpios;
>> + };
>> + gpio_sysclk0_en:gpio_sysclk0_en {
>> + gpios;
>> + };
>> + gpio_jtag_tdo:gpio_jtag_tdo {
>> + gpios;
>> + };
>> + /* LCB: PWR_HOLD_GPIO0_0 */
>> + gpio_pwr_hold:gpio_pwr_hold {
>> + gpios = <&gpio0 0 0>;
>> + };
>
> (...)
>
> I don't understand any stuff in this hikey-gpio.dtsi file.
>
> What does all this mean?
>
> If it has any practical use whatsoever then explain it in the
> commit message, but right now it just looks like a big list
> of placeholders with no use, but you can copy-paste them
> into device nodes the day you need them?
>
> If they are unused, just drop this file please.
I will drop this.
Sorry missed this in v2. I will fix this in next version.
-Guodong
>
> Yours,
> Linus Walleij
[PATCH] oom: consider multi-threaded tasks in task_will_free_mem
From: Michal Hocko
task_will_free_mem is a misnomer for a more complex PF_EXITING test
for early break out from the oom killer because it is believed that
such a task would release its memory shortly and so we do not have
to select an oom victim and perform a disruptive action.
Currently we make sure that the given task is not participating in the
core dumping because it might get blocked for a long time - see
d003f371b270 ("oom: don't assume that a coredumping thread will exit
soon").
The check can still do better though. We shouldn't consider the task
unless the whole thread group is going down. This is rather unlikely
but not impossible. A single exiting thread would surely leave all the
address space behind. If we are really unlucky it might get stuck on the
exit path and keep its TIF_MEMDIE and so block the oom killer.
Signed-off-by: Michal Hocko
---
Hi,
I hope I got it right but I would really appreciate if Oleg found some
time and double checked after me. The fix is more cosmetic than anything
else but I guess it is worth it.
Thanks!
include/linux/oom.h | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/include/linux/oom.h b/include/linux/oom.h
index 628a43242a34..b09c7dc523ff 100644
--- a/include/linux/oom.h
+++ b/include/linux/oom.h
@@ -102,13 +102,24 @@ extern struct task_struct *find_lock_task_mm(struct
task_struct *p);
static inline bool task_will_free_mem(struct task_struct *task)
{
+ struct signal_struct *sig = task->signal;
+
/*
* A coredumping process may sleep for an extended period in exit_mm(),
* so the oom killer cannot assume that the process will promptly exit
* and release memory.
*/
- return (task->flags & PF_EXITING) &&
- !(task->signal->flags & SIGNAL_GROUP_COREDUMP);
+ if (sig->flags & SIGNAL_GROUP_COREDUMP)
+ return false;
+
+ if (!(task->flags & PF_EXITING))
+ return false;
+
+ /* Make sure that the whole thread group is going down */
+ if (!thread_group_empty(task) && !(sig->flags & SIGNAL_GROUP_EXIT))
+ return false;
+
+ return true;
}
/* sysctls */
--
2.8.0.rc3
Re: Kernel docs: muddying the waters a bit
Hi Markus, On 04/08/16 17:12, Markus Heiser wrote: > Hi kernel-doc authors, > > motivated by this MT, I implemented a toolchain to migrate the kernel’s > DocBook XML documentation to reST markup. > > It converts 99% of the docs well ... to gain an impression how > kernel-docs could benefit from, visit my sphkerneldoc project page > on github: > > http://return42.github.io/sphkerneldoc/ > > The sources available at: > > https://github.com/return42/sphkerneldoc > > The work is underway, suggestions are welcome! I have to admit that this looks pretty good :-) My main remark based on my quick scan through the docs is that anything in typewriter font seems to be shown as red text with a rectangle around it. That's quite jarring for me and I think it should be just shown as normal text, just using a non-proportional font, just like in the original. I also noticed that the 'title' of tables ends with a '¶' character for some reason. See e.g. the struct v4l2_audioout table in http://return42.github.io/sphkerneldoc/books/linux_tv/media/v4l/vidioc-g-audioout.html Regards, Hans > > .. have a nice weekend .. > > --M-- > > > Am 13.03.2016 um 16:33 schrieb Markus Heiser : > >> >> Am 10.03.2016 um 16:21 schrieb Mauro Carvalho Chehab >> : >> >>> Em Thu, 10 Mar 2016 12:25:58 +0200 >>> Jani Nikula escreveu: >>> TL;DR? Skip to the last paragraph. On Wed, 09 Mar 2016, Mauro Carvalho Chehab wrote: > I guess the conversion to asciidoc format is now in good shape, > at least to demonstrate that it is possible to use this format for the > media docbook. Still, there are lots of broken references. Getting references right with asciidoc is a big problem in the kernel-doc side. As I wrote before, the proofs of concept only worked because everything was processed as one big file (via includes). The Asciidoctor inter-document references won't help, because we won't know the target document name while processing kernel-doc. >>> >>> I was able to produce chunked htmls here with: >>> >>> asciidoctor -b docbook45 media_api.adoc >>> xmlto -o html-dir html media_api.xml >>> >>> The results are at: >>> >>> https://mchehab.fedorapeople.org/media-kabi-docs-test/asciidoc_tests/chunked/ >>> >>> But yeah, all references seem to be broken there. It could be due to some >>> conversion issue (I didn't actually tried to check what's wrong there), >>> but I think that there's something not ok with docbook45 >>> output for multi-part documents (on both AsciiDoc and Asciidoctor). >>> Sphinx is massively better at handling cross references for kernel-doc. We can use domains (C language) and roles (e.g. functions, types, etc.) for the references, which provide kind of namespaces. Sphinx warns for referencing non-existing targets, but doesn't generate broken links in the result like Asciidoctor does. For example, in the documentation for a function that has struct foo as parameter or return type, a cross reference to struct foo is added automagically, but only if documentation for struct foo actually exists. In Asciidoctor, we would have to blindly generate the references ourselves, and try to resolve broken links ourselves by somehow post-processing the result. > Yet, from my side, if we're willing to get rid of DocBook, then > Asciidoctor seems to be the *only* alternative so far to parse the > complex media documents. I think you mean, "get rid of DocBook as source format", not altogether? I'm yet to be convinved we could rely on Asciidoctor's native formats. >>> >>> What I mean is that, right now, I see only two alternatives for the >>> media uAPI documentation: >>> 1) keep using DocBook; >>> 2) AsciiDoc/Asciidoctor. >>> >>> Sphinx doesn't have what's needed to support the complexity of the >>> media books, specially since cell span seems to be possible only >>> by using asciiArt formats. Writing a big table using asciiArt is >>> something that is a *real pain*. Also, as tested, if the table is >>> too big, it fails to parse such asciiArt tables. So, while Sphinx >>> doesn't have a decent way to describe tables, we can't use it. >> >> >> Huge tables and cell-spans are the *real pain* ;-) ... with sphinx-doc, >> (mostly) you have more then one choice .. e.g. import csv tables .. >> but this should be discussed by example ... >> >> >>> If it starts implementing it, then we can check if the other >>> features used by the media documentation are also supported. >>> Probably, multi-part books would be another pain with Sphinx. >>> We have actually 4 books inside a common body. A few chapters >>> (like book licensing, bibliography, error codes) are shared >>> by all 4 documents. >>> >>> But, so far, I can't see any way to port media books without >>> lots of lot of work to develop new features at the Sphinx code. >> >> >> may I can help you ... >> >>
Re: [PATCH RFT 2/2] macb: kill PHY reset code
Le 11/04/2016 04:28, Andrew Lunn a écrit :
> On Sat, Apr 09, 2016 at 01:25:03AM +0300, Sergei Shtylyov wrote:
>> With the 'phylib' now being aware of the "reset-gpios" PHY node property,
>> there should be no need to frob the PHY reset in this driver anymore...
>>
>> Signed-off-by: Sergei Shtylyov
>>
>> ---
>> drivers/net/ethernet/cadence/macb.c | 17 -
>> drivers/net/ethernet/cadence/macb.h |1 -
>> 2 files changed, 18 deletions(-)
>>
>> Index: net-next/drivers/net/ethernet/cadence/macb.c
>> ===
>> --- net-next.orig/drivers/net/ethernet/cadence/macb.c
>> +++ net-next/drivers/net/ethernet/cadence/macb.c
>> @@ -2884,7 +2884,6 @@ static int macb_probe(struct platform_de
>>= macb_clk_init;
>> int (*init)(struct platform_device *) = macb_init;
>> struct device_node *np = pdev->dev.of_node;
>> -struct device_node *phy_node;
>> const struct macb_config *macb_config = NULL;
>> struct clk *pclk, *hclk = NULL, *tx_clk = NULL;
>> unsigned int queue_mask, num_queues;
>> @@ -2977,18 +2976,6 @@ static int macb_probe(struct platform_de
>> else
>> macb_get_hwaddr(bp);
>>
>> -/* Power up the PHY if there is a GPIO reset */
>> -phy_node = of_get_next_available_child(np, NULL);
>> -if (phy_node) {
>> -int gpio = of_get_named_gpio(phy_node, "reset-gpios", 0);
>> -
>> -if (gpio_is_valid(gpio)) {
>> -bp->reset_gpio = gpio_to_desc(gpio);
>> -gpiod_direction_output(bp->reset_gpio, 1);
>
> Hi Sergei
>
> The code you are deleting would of ignored the flags in the gpio
I don't parse this.
The code deleted does take the flag into account. And the DT property
associated to it seems correct to me (I mean, with proper flag
specification).
> property, i.e. active low. The new code in the previous patch does
> however take the flags into account. Did you check if there are any
> device trees which have flags, which were never used, but are now
> going to be used and thus break...
Flag was used and you are saying that it's taken into account in new
code... So, what's the issue?
I see a difference in the way the "value" of gpiod_* functions is used.
There may be a misunderstanding here...
Bye,
--
Nicolas Ferre
Re: [PATCH RFT 2/2] macb: kill PHY reset code
Le 11/04/2016 20:51, Andrew Lunn a écrit : > On Mon, Apr 11, 2016 at 09:39:02PM +0300, Sergei Shtylyov wrote: >> Hello. >> >> On 04/11/2016 09:19 PM, Andrew Lunn wrote: >> > The code you are deleting would of ignored the flags in the gpio > property, i.e. active low. Hm, you're right -- I forgot about that... :-/ > The new code in the previous patch does > however take the flags into account. Did you check if there are any > device trees which have flags, which were never used, but are now > going to be used and thus break... Checked this now and found out arch/arm/boot/dts/ar91-vinco.dts. Looks like it needs to be fixed indeed... >>> And this is where it gets tricky. You are breaking backwards >>> compatibility by now respecting the flag. An old DT blob is not going >>> to work. >> >>Do we care that much about the DT blobs that are just *wrong*? > > Wrong, but currently works. > >>> You potentially need to add a new property and deprecate the old one. >> >>I would like to avoid that... > > You will need the agreement from the at91-vinco maintainer. If the at91-vinco has to be modified, you have my agreement that it can be modified. Bye, -- Nicolas Ferre
Re: [fuse-devel] Horrible mmap write performance (kernel writeback issue?)
On Tue, Apr 12, 2016 at 5:54 AM, Tejun Heo wrote: > Hello, > > On Mon, Apr 11, 2016 at 10:04:42AM +0200, Jakob Unterwurzacher wrote: >> What seems to be happening in the kernel is that the estimated device >> bandwith >> drops to zero. I'm not even sure how this works for FUSE, but that's what I >> gathered from some printk debugging. > > Yeah, writeback bw getting messed up is the most likely cause. Prolly > some silly bug. I can reproduce the problem. Looking into it. Probably you want to look into: https://lkml.org/lkml/2016/3/10/21 The patch mentioned above solves the issue for me. Thanks, Ashish > > Thanks. > > -- > tejun
Re: [PATCH v7 2/4] power: reset: add reboot mode driver
Hi Krzysztof:
On 2016年04月06日 09:00, Krzysztof Kozlowski wrote:
On 06.04.2016 09:50, Andy Yan wrote:
(...)
+return -ENOMEM;
+
+info->mode = kstrdup_const(prop->name + len, GFP_KERNEL);
+if (of_property_read_u32(np, prop->name, &info->magic)) {
+dev_err(dev, "reboot mode %s without magic number\n",
+info->mode);
+devm_kfree(dev, info);
+continue;
+}
+list_add_tail(&info->list, &reboot->head);
+}
+of_node_put(np);
If you of_node_put() here, there is no sense in getting it before. I
mentioned of_node_get() only because I am not sure about life-cycle of
nodes in case of DT overlays and you are storing the pointer to string
from DT.
The doubts I have are concerning only the case of freeing nodes from
overlay.
I don't know if of_node_get() is needed but of_node_get()+of_node_put()
seems useless.
I am also not sure about it. Maybe just drop of_node_get/put ?
OK, let's drop both get() and put().
(...)
+
+static const struct of_device_id syscon_reboot_mode_of_match[] = {
+{ .compatible = "syscon-reboot-mode" },
+{}
+};
+
+static struct platform_driver syscon_reboot_mode_driver = {
+.probe = syscon_reboot_mode_probe,
Cleanup needed. What will happen after device unbind? Memory will be
released (devm-*()) but reboot notifier won't thus leading to OOPS on
reboot.
From the kernel_restart_prepare function, the reboot notifier will
be called before device_shutdown. Is there any other case the device
unbind before reboot notifier
called?
This is a regular module platform driver so unbind can happen any time
initiated by user, either by unbind command or by module removal. User
can then re-bind device or not - probably does not matter. Anyway after
such first unbind, the restart will kaboom instead of do a restart.
I just need to do clean up in remove?
Beside that, you always should clean up, regardless of restart or not.
If you do not want unbind (thus no need of cleanup) then forbid it by
making it a non-module with suppressed bind.
Best regards,
Krzysztof
[PATCH 2/2] of: Add Inforce Computing to vendor prefix list
This patch adds Inforce Computing to vendor prefix list. This vendor makes boards like IFC6410, IFC6540 based on Qualcomm SOCs. Signed-off-by: Srinivas Kandagatla --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index f382061..7df3544 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -119,6 +119,7 @@ idt Integrated Device Technologies, Inc. ifiIngenieurburo Fur Ic-Technologie (I/F/I) iomIomega Corporation imgImagination Technologies Ltd. +inforceInforce Computing ingenicIngenic Semiconductor innoluxInnolux Corporation intel Intel Corporation -- 2.5.0
[PATCH 1/2] of: Add Arrow Electronics to vendor prefix list
This patch adds Arrow Electronics to vendor perfix list, as this vendor makes some of the Qualcomm SOC based 96boards like DB600c and DB410c. Signed-off-by: Srinivas Kandagatla --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 86740d4..f382061 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -27,6 +27,7 @@ aptinaAptina Imaging arasan Arasan Chip Systems armARM Ltd. armadeus ARMadeus Systems SARL +arrow Arrow Electronics artesynArtesyn Embedded Technologies Inc. asahi-kaseiAsahi Kasei Corp. atlas Atlas Scientific LLC -- 2.5.0
Re: mmotm woes, mainly compaction
On 04/12/2016 09:18 AM, Hugh Dickins wrote:
> 3. /proc/sys/vm/stat_refresh warns nr_isolated_anon and nr_isolated_file
> go increasingly negative under compaction: which would add delay when
> should be none, or no delay when should delay. putback_movable_pages()
> decrements the NR_ISOLATED counts which acct_isolated() increments,
> so isolate_migratepages_block() needs to acct before putback in that
> special case, and isolate_migratepages_range() can always do the acct
> itself, leaving migratepages putback to caller like most other places.
Sigh, looks like I notoriously suck at the nr_isolated_* accounting. The
isolate_migratepages_range() is also due to my 3.18 commit. Back then,
Joonsoo caught the problem for compaction side, but CMA issue remains.
Sorry and thanks.
8<
>From 8aa6e765d4f931718386e13290d43348e34f0e76 Mon Sep 17 00:00:00 2001
From: Hugh Dickins
Date: Tue, 12 Apr 2016 11:14:49 +0200
Subject: [PATCH] mm, cma: prevent nr_isolated_* counters from going negative
/proc/sys/vm/stat_refresh warns nr_isolated_anon and nr_isolated_file
go increasingly negative under compaction: which would add delay when
should be none, or no delay when should delay. The bug in compaction was
due to a recent mmotm patch, but much older instance of the bug was also
noticed in isolate_migratepages_range() which is used for CMA and
gigantic hugepage allocations.
The bug is caused by putback_movable_pages() in an error path decrementing
the isolated counters without them being previously incremented by
acct_isolated(). Fix isolate_migratepages_range() by removing the error-path
putback, thus reaching acct_isolated() with migratepages still isolated, and
leaving putback to caller like most other places do.
[vba...@suse.cz: expanded the changelog]
Fixes: edc2ca612496 ("mm, compaction: move pageblock checks up from
isolate_migratepages_range()")
Cc: sta...@vger.kernel.org #3.18+
Cc: Joonsoo Kim
Signed-off-by: Hugh Dickins
Signed-off-by: Vlastimil Babka
---
mm/compaction.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/mm/compaction.c b/mm/compaction.c
index ab649fba3d88..c0be38f634d3 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -930,16 +930,8 @@ isolate_migratepages_range(struct compact_control *cc,
unsigned long start_pfn,
pfn = isolate_migratepages_block(cc, pfn, block_end_pfn,
ISOLATE_UNEVICTABLE);
- /*
-* In case of fatal failure, release everything that might
-* have been isolated in the previous iteration, and signal
-* the failure back to caller.
-*/
- if (!pfn) {
- putback_movable_pages(&cc->migratepages);
- cc->nr_migratepages = 0;
+ if (!pfn)
break;
- }
if (cc->nr_migratepages == COMPACT_CLUSTER_MAX)
break;
--
2.8.1
Re: [RESEND PATCH v9] mtd: spi-nor: add hisilicon spi-nor flash controller driver
Hi Marek,
On 2016/4/12 3:21, Marek Vasut wrote:
> On 04/11/2016 03:28 AM, Jiancheng Xue wrote:
>> Hi,
>>
>> On 2016/4/8 18:04, Marek Vasut wrote:
>>> On 04/08/2016 10:26 AM, Jiancheng Xue wrote:
Hi,
On 2016/4/7 10:28, Marek Vasut wrote:
> On 04/07/2016 04:10 AM, Jiancheng Xue wrote:
>> Hi Brian,
>>Thank you very much for your comments. I'll fix these issues in next
>> version.
>> In addition, for easy understanding I'd like to rewrite
>> hisi_spi_nor_write and
>> hisi_spi_nor_read. Your comments on these modifications will be highly
>> appreciated.
>
> Would you please stop top-posting ? It rubs some people the wrong way.
>
I feel very sorry about that. I have read the etiquette and won't make the
same mistake again.
>> static int hisi_spi_nor_read(struct spi_nor *nor, loff_t from, size_t
>> len,
>> size_t *retlen, u_char *read_buf)
>> {
>> struct hifmc_priv *priv = nor->priv;
>> struct hifmc_host *host = priv->host;
>> int i;
>>
>> /* read all bytes in only one time */
>> if (len <= HIFMC_DMA_MAX_LEN) {
>> hisi_spi_nor_dma_transfer(nor, from, host->dma_buffer,
>> len, FMC_OP_READ);
>> memcpy(read_buf, host->buffer, len);
>
> Is all the ad-hoc memcpying necessary? I think you can use
> dma_map_single() and co to obtain DMAble memory for your
> controller's use and then you can probably get rid of most
> of this stuff.
>
Considering read_buf >= high_mem case, I think it is also complicated to
use dma_map_*
and the DMA buffer allocated by the driver is still needed. But I am not
sure about
this. Please let me know if I am wrong. Thank you!
>>>
>>> Does your controller/DMA have a limitation where it's buffers must be in
>>> the bottom 4GiB range ? The DMA framework should be able to take care of
>>> such platform limitations.
>>>
>> When read_buf is allocated by vmalloc, the underlying physical memory may be
>> not contiguous.
>> In this case, dma_map_single can't be used directly. I think inner DMA
>> buffer and memcpy are still
>> needed. Am I right?
>
> Take a look at drivers/spi/spi-mxs.c , look for "vmalloc" , does that
> solution help you in any way ?
>
No. I think this solution just processes the buffer within only one page.
I had referred to drivers/mtd/onenand/samsung.c and other files.
The corresponding code segment is as follows:
static int s5pc110_read_bufferram(struct mtd_info *mtd, int area,
unsigned char *buffer, int offset, size_t count)
{
void *buf = (void *) buffer;
dma_addr_t dma_src, dma_dst;
...
/* Handle vmalloc address */
if (buf >= high_memory) {
struct page *page;
if (((size_t) buf & PAGE_MASK) !=
((size_t) (buf + count - 1) & PAGE_MASK))
goto normal;
page = vmalloc_to_page(buf);
if (!page)
goto normal;
...
} else {
...
}
normal:
...
memcpy(buffer, p, count);
return 0;
}
I think memcpy in "normal" clause can't be removed. So I'd like to keep my
original
implementation if it is also OK. What's your opinion?
Regards,
Jiancheng
[PATCH v2 00/13] ARM: dts: Add DB600c support.
Hi Andy, This patchset adds support to DB600c which is based on APQ8064. With this patchset, except spi I was able to test all the below features on this board on top of v4.6-rc3. 1> i2c 2> spi 3> sd/mmc with card detect 4> eMMC 5> USB 6> SATA 7> on board Ethernet based on PCIE. 8> user and activity leds. 9> on board Magnetometer This patchset also has a fix to i2c/spi pinctrls which was not set correctly in my previous apq8064 patches, I have verified this patchset with eeprom and sensors on the board, you might want to take that patch in next rc. Changes since v1: - renamed the dts and compatible strings according to the discussion. - fixed/renamed led labels as suggeste by Rob, Nico and others. - Added Acks for Bjorn - Added Magnetometer support. - Split the pinconfs to seperate file as suggested by Bjorn - Remove activity leds default triggers, as it was not clear which trigger was correct according to 96boards specs. Can be added once we fix that. Thanks, srini Srinivas Kandagatla (13): ARM: dts: apq8064: fix the pinctrls for i2c and spi ARM: dts: apq8064: add support to gsbi1 uart ARM: dts: apq8064: add gsbi7 i2c support ARM: dts: db600c: add board support with serial ARM: dts: db600c: add pmic regulator supplies ARM: dts: db600c: Add eMMC and SD card support ARM: dts: db600c: add usb support ARM: dts: db600c: add pcie support ARM: dts: db600c: add on board sata support. ARM: dts: db600c: Add on board leds support ARM: dts: db600c: add i2c support ARM: dts: db600c: add spi support ARM: dts: db600c: add support to magnetometer arch/arm/boot/dts/Makefile | 1 + .../boot/dts/qcom-apq8064-arrow-db600c-pins.dtsi | 52 +++ arch/arm/boot/dts/qcom-apq8064-arrow-db600c.dts| 349 + arch/arm/boot/dts/qcom-apq8064-pins.dtsi | 39 +++ arch/arm/boot/dts/qcom-apq8064.dtsi| 41 ++- 5 files changed, 476 insertions(+), 6 deletions(-) create mode 100644 arch/arm/boot/dts/qcom-apq8064-arrow-db600c-pins.dtsi create mode 100644 arch/arm/boot/dts/qcom-apq8064-arrow-db600c.dts -- 2.5.0
[PATCH v2 03/13] ARM: dts: apq8064: add gsbi7 i2c support
This patch adds support to gsbi7 i2c which is used in some of the new
boards.
Signed-off-by: Srinivas Kandagatla
---
arch/arm/boot/dts/qcom-apq8064-pins.dtsi | 25 +
arch/arm/boot/dts/qcom-apq8064.dtsi | 13 +
2 files changed, 38 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-apq8064-pins.dtsi
b/arch/arm/boot/dts/qcom-apq8064-pins.dtsi
index 8bb5e5f..4102a98 100644
--- a/arch/arm/boot/dts/qcom-apq8064-pins.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064-pins.dtsi
@@ -219,4 +219,29 @@
function = "gsbi7";
};
};
+
+ i2c7_pins: i2c7 {
+ mux {
+ pins = "gpio84", "gpio85";
+ function = "gsbi7";
+ };
+
+ pinconf {
+ pins = "gpio84", "gpio85";
+ drive-strength = <16>;
+ bias-disable;
+ };
+ };
+
+ i2c7_pins_sleep: i2c7_pins_sleep {
+ mux {
+ pins = "gpio84", "gpio85";
+ function = "gpio";
+ };
+ pinconf {
+ pins = "gpio84", "gpio85";
+ drive-strength = <2>;
+ bias-disable = <0>;
+ };
+ };
};
diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi
b/arch/arm/boot/dts/qcom-apq8064.dtsi
index 81b4290..f064f59 100644
--- a/arch/arm/boot/dts/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -417,6 +417,19 @@
clock-names = "core", "iface";
status = "disabled";
};
+
+ gsbi7_i2c: i2c@1668 {
+ compatible = "qcom,i2c-qup-v1.1.1";
+ pinctrl-0 = <&i2c7_pins>;
+ pinctrl-1 = <&i2c7_pins_sleep>;
+ pinctrl-names = "default", "sleep";
+ reg = <0x1668 0x1000>;
+ interrupts = ;
+ clocks = <&gcc GSBI7_QUP_CLK>,
+<&gcc GSBI7_H_CLK>;
+ clock-names = "core", "iface";
+ status = "disabled";
+ };
};
rng@1a50 {
--
2.5.0
[PATCH v2 01/13] ARM: dts: apq8064: fix the pinctrls for i2c and spi
This patch fixes pinctrls for spi and i2c nodes whose default and sleep
states are together, which is incorrect.
Without this patch i2c/spi would not be functional.
Signed-off-by: Srinivas Kandagatla
Acked-by: Bjorn Andersson
---
arch/arm/boot/dts/qcom-apq8064.dtsi | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi
b/arch/arm/boot/dts/qcom-apq8064.dtsi
index 65d0e8d..c6ff8fc 100644
--- a/arch/arm/boot/dts/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -227,7 +227,8 @@
gsbi1_i2c: i2c@1246 {
compatible = "qcom,i2c-qup-v1.1.1";
- pinctrl-0 = <&i2c1_pins &i2c1_pins_sleep>;
+ pinctrl-0 = <&i2c1_pins>;
+ pinctrl-1 = <&i2c1_pins_sleep>;
pinctrl-names = "default", "sleep";
reg = <0x1246 0x1000>;
interrupts = <0 194 IRQ_TYPE_NONE>;
@@ -255,7 +256,8 @@
gsbi2_i2c: i2c@124a {
compatible = "qcom,i2c-qup-v1.1.1";
reg = <0x124a 0x1000>;
- pinctrl-0 = <&i2c2_pins &i2c2_pins_sleep>;
+ pinctrl-0 = <&i2c2_pins>;
+ pinctrl-1 = <&i2c2_pins_sleep>;
pinctrl-names = "default", "sleep";
interrupts = <0 196 IRQ_TYPE_NONE>;
clocks = <&gcc GSBI2_QUP_CLK>, <&gcc
GSBI2_H_CLK>;
@@ -277,7 +279,8 @@
ranges;
gsbi3_i2c: i2c@1628 {
compatible = "qcom,i2c-qup-v1.1.1";
- pinctrl-0 = <&i2c3_pins &i2c3_pins_sleep>;
+ pinctrl-0 = <&i2c3_pins>;
+ pinctrl-1 = <&i2c3_pins_sleep>;
pinctrl-names = "default", "sleep";
reg = <0x1628 0x1000>;
interrupts = ;
@@ -302,7 +305,8 @@
gsbi4_i2c: i2c@1638 {
compatible = "qcom,i2c-qup-v1.1.1";
- pinctrl-0 = <&i2c4_pins &i2c4_pins_sleep>;
+ pinctrl-0 = <&i2c4_pins>;
+ pinctrl-1 = <&i2c4_pins_sleep>;
pinctrl-names = "default", "sleep";
reg = <0x1638 0x1000>;
interrupts = ;
@@ -337,7 +341,8 @@
compatible = "qcom,spi-qup-v1.1.1";
reg = <0x1a28 0x1000>;
interrupts = <0 155 0>;
- pinctrl-0 = <&spi5_default &spi5_sleep>;
+ pinctrl-0 = <&spi5_default>;
+ pinctrl-1 = <&spi5_sleep>;
pinctrl-names = "default", "sleep";
clocks = <&gcc GSBI5_QUP_CLK>, <&gcc
GSBI5_H_CLK>;
clock-names = "core", "iface";
@@ -370,7 +375,8 @@
gsbi6_i2c: i2c@1658 {
compatible = "qcom,i2c-qup-v1.1.1";
- pinctrl-0 = <&i2c6_pins &i2c6_pins_sleep>;
+ pinctrl-0 = <&i2c6_pins>;
+ pinctrl-1 = <&i2c6_pins_sleep>;
pinctrl-names = "default", "sleep";
reg = <0x1658 0x1000>;
interrupts = ;
--
2.5.0
[PATCH v2 04/13] ARM: dts: db600c: add board support with serial
This patch adds support to DB600c with basic serial ports.
DB600c is based on APQ8064.
Signed-off-by: Srinivas Kandagatla
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/qcom-apq8064-arrow-db600c.dts | 36 +
2 files changed, 37 insertions(+)
create mode 100644 arch/arm/boot/dts/qcom-apq8064-arrow-db600c.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 95c1923..fef61b3 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -539,6 +539,7 @@ dtb-$(CONFIG_ARCH_ORION5X) += \
dtb-$(CONFIG_ARCH_PRIMA2) += \
prima2-evb.dtb
dtb-$(CONFIG_ARCH_QCOM) += \
+ qcom-apq8064-arrow-db600c.dtb \
qcom-apq8064-cm-qs600.dtb \
qcom-apq8064-ifc6410.dtb \
qcom-apq8064-sony-xperia-yuga.dtb \
diff --git a/arch/arm/boot/dts/qcom-apq8064-arrow-db600c.dts
b/arch/arm/boot/dts/qcom-apq8064-arrow-db600c.dts
new file mode 100644
index 000..57d4500
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-apq8064-arrow-db600c.dts
@@ -0,0 +1,36 @@
+#include "qcom-apq8064-v2.0.dtsi"
+
+/ {
+ model = "Arrow Electronics, APQ8064 DB600c";
+ compatible = "arrow,db600c", "qcom,apq8064";
+
+ aliases {
+ serial0 = &gsbi7_serial;
+ serial1 = &gsbi1_serial;
+ };
+
+ soc {
+ gsbi@1244 {
+ status = "okay";
+ qcom,mode = ;
+ serial@1245 {
+ label = "LS-UART1";
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&gsbi1_uart_4pins>;
+ };
+ };
+
+ /* DEBUG UART */
+ gsbi@1660 {
+ status = "okay";
+ qcom,mode = ;
+ serial@1664 {
+ label = "LS-UART0";
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&gsbi7_uart_2pins>;
+ };
+ };
+ };
+};
--
2.5.0
[PATCH v2 10/13] ARM: dts: db600c: Add on board leds support
This patch adds support to 4 user leds, wlan and bt led on board.
Signed-off-by: Srinivas Kandagatla
---
.../boot/dts/qcom-apq8064-arrow-db600c-pins.dtsi | 23 +++
arch/arm/boot/dts/qcom-apq8064-arrow-db600c.dts| 47 ++
2 files changed, 70 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-apq8064-arrow-db600c-pins.dtsi
b/arch/arm/boot/dts/qcom-apq8064-arrow-db600c-pins.dtsi
index 0610f00..3b55bb9 100644
--- a/arch/arm/boot/dts/qcom-apq8064-arrow-db600c-pins.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064-arrow-db600c-pins.dtsi
@@ -18,4 +18,27 @@
bias-disable;
};
};
+
+ user_leds: user-leds {
+ mux {
+ pins = "gpio3", "gpio7", "gpio10", "gpio11";
+ function = "gpio";
+ };
+
+ conf {
+ pins = "gpio3", "gpio7", "gpio10", "gpio11";
+ function = "gpio";
+ output-low;
+ };
+ };
+};
+
+&pm8921_mpps {
+ mpp_leds: mpp-leds {
+ pinconf {
+ pins = "mpp7", "mpp8";
+ function = "digital";
+ output-low;
+ };
+ };
};
diff --git a/arch/arm/boot/dts/qcom-apq8064-arrow-db600c.dts
b/arch/arm/boot/dts/qcom-apq8064-arrow-db600c.dts
index 6f97ddc..8c18a4b 100644
--- a/arch/arm/boot/dts/qcom-apq8064-arrow-db600c.dts
+++ b/arch/arm/boot/dts/qcom-apq8064-arrow-db600c.dts
@@ -153,6 +153,53 @@
};
};
+ leds {
+ pinctrl-names = "default";
+ pinctrl-0 = <&user_leds>, <&mpp_leds>;
+
+ compatible = "gpio-leds";
+
+ user-led0 {
+ label = "user0-led";
+ gpios = <&tlmm_pinmux 3 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ default-state = "off";
+ };
+
+ user-led1 {
+ label = "user1-led";
+ gpios = <&tlmm_pinmux 7 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "mmc0";
+ default-state = "off";
+ };
+
+ user-led2 {
+ label = "user2-led";
+ gpios = <&tlmm_pinmux 10 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "mmc1";
+ default-state = "off";
+ };
+
+ user-led3 {
+ label = "user3-led";
+ gpios = <&tlmm_pinmux 11 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "none";
+ default-state = "off";
+ };
+
+ wifi-led {
+ label = "WiFi-led";
+ gpios = <&pm8921_mpps 7 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ bt-led {
+ label = "BT-led";
+ gpios = <&pm8921_mpps 8 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+ };
+
pci@1b50 {
status = "okay";
vdda-supply = <&pm8921_s3>;
--
2.5.0
[PATCH v2 09/13] ARM: dts: db600c: add on board sata support.
This patch enables sata and regulators required to get on board sata
working.
Signed-off-by: Srinivas Kandagatla
Acked-by: Bjorn Andersson
---
arch/arm/boot/dts/qcom-apq8064-arrow-db600c.dts | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-apq8064-arrow-db600c.dts
b/arch/arm/boot/dts/qcom-apq8064-arrow-db600c.dts
index 4f2218c..6f97ddc 100644
--- a/arch/arm/boot/dts/qcom-apq8064-arrow-db600c.dts
+++ b/arch/arm/boot/dts/qcom-apq8064-arrow-db600c.dts
@@ -123,6 +123,10 @@
lvs6 {
bias-pull-down;
};
+
+ lvs7 {
+ bias-pull-down;
+ };
};
};
@@ -159,6 +163,15 @@
perst-gpio = <&tlmm_pinmux 27 GPIO_ACTIVE_LOW>;
};
+ phy@1b40 {
+ status = "okay";
+ };
+
+ sata@2900 {
+ status = "okay";
+ target-supply = <&pm8921_lvs7>;
+ };
+
/* OTG */
phy@1250 {
status = "okay";
--
2.5.0
[PATCH v2 13/13] ARM: dts: db600c: add support to magnetometer
This patch adds support to on board LIS3MDLTR magnetometer.
Signed-off-by: Srinivas Kandagatla
---
arch/arm/boot/dts/qcom-apq8064-arrow-db600c-pins.dtsi | 8
arch/arm/boot/dts/qcom-apq8064-arrow-db600c.dts | 13 +
2 files changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-apq8064-arrow-db600c-pins.dtsi
b/arch/arm/boot/dts/qcom-apq8064-arrow-db600c-pins.dtsi
index 3b55bb9..a3efb97 100644
--- a/arch/arm/boot/dts/qcom-apq8064-arrow-db600c-pins.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064-arrow-db600c-pins.dtsi
@@ -31,6 +31,14 @@
output-low;
};
};
+
+ magneto_pins: magneto-pins {
+ mux {
+ pins = "gpio31", "gpio48";
+ function = "gpio";
+ bias-disable;
+ };
+ };
};
&pm8921_mpps {
diff --git a/arch/arm/boot/dts/qcom-apq8064-arrow-db600c.dts
b/arch/arm/boot/dts/qcom-apq8064-arrow-db600c.dts
index 34bb415..e01b27e 100644
--- a/arch/arm/boot/dts/qcom-apq8064-arrow-db600c.dts
+++ b/arch/arm/boot/dts/qcom-apq8064-arrow-db600c.dts
@@ -153,6 +153,19 @@
/* On Low speed expansion and Sensors */
label = "LS-I2C0";
status = "okay";
+ lis3mdl_mag@1e {
+ compatible = "st,lis3mdl-magn";
+ reg = <0x1e>;
+ vdd-supply = <&vcc3v3>;
+ vddio-supply = <&pm8921_s4>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&magneto_pins>;
+ interrupt-parent = <&tlmm_pinmux>;
+
+ st,drdy-int-pin = <2>;
+ interrupts = <48 IRQ_TYPE_EDGE_RISING>,
/* DRDY line */
+<31 IRQ_TYPE_EDGE_RISING>;
/* INT */
+ };
};
};
--
2.5.0
[PATCH v2 12/13] ARM: dts: db600c: add spi support
This patch adds spi nodes required to provide spi bus support on LS
expansion.
Signed-off-by: Srinivas Kandagatla
---
arch/arm/boot/dts/qcom-apq8064-arrow-db600c.dts | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-apq8064-arrow-db600c.dts
b/arch/arm/boot/dts/qcom-apq8064-arrow-db600c.dts
index 2f0dfff..34bb415 100644
--- a/arch/arm/boot/dts/qcom-apq8064-arrow-db600c.dts
+++ b/arch/arm/boot/dts/qcom-apq8064-arrow-db600c.dts
@@ -13,6 +13,7 @@
i2c1 = &gsbi3_i2c;
i2c2 = &gsbi4_i2c;
i2c3 = &gsbi7_i2c;
+ spi0 = &gsbi5_spi;
};
regulators {
@@ -181,6 +182,15 @@
};
};
+ gsbi@1a20 {
+ status = "okay";
+ spi@1a28 {
+ /* On Low speed expansion */
+ label = "LS-SPI0";
+ status = "okay";
+ };
+ };
+
/* DEBUG UART */
gsbi@1660 {
status = "okay";
--
2.5.0
[PATCH v2 06/13] ARM: dts: db600c: Add eMMC and SD card support
This patch adds eMMC and SD card support with card detect and adding
required regulators.
Signed-off-by: Srinivas Kandagatla
Acked-by: Bjorn Andersson
---
.../boot/dts/qcom-apq8064-arrow-db600c-pins.dtsi | 9 ++
arch/arm/boot/dts/qcom-apq8064-arrow-db600c.dts| 34 ++
2 files changed, 43 insertions(+)
create mode 100644 arch/arm/boot/dts/qcom-apq8064-arrow-db600c-pins.dtsi
diff --git a/arch/arm/boot/dts/qcom-apq8064-arrow-db600c-pins.dtsi
b/arch/arm/boot/dts/qcom-apq8064-arrow-db600c-pins.dtsi
new file mode 100644
index 000..7339919
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-apq8064-arrow-db600c-pins.dtsi
@@ -0,0 +1,9 @@
+&tlmm_pinmux {
+ card_detect: card-detect {
+ mux {
+ pins = "gpio26";
+ function = "gpio";
+ bias-disable;
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/qcom-apq8064-arrow-db600c.dts
b/arch/arm/boot/dts/qcom-apq8064-arrow-db600c.dts
index 6695b00..d921424 100644
--- a/arch/arm/boot/dts/qcom-apq8064-arrow-db600c.dts
+++ b/arch/arm/boot/dts/qcom-apq8064-arrow-db600c.dts
@@ -1,4 +1,6 @@
#include "qcom-apq8064-v2.0.dtsi"
+#include "qcom-apq8064-arrow-db600c-pins.dtsi"
+#include
/ {
model = "Arrow Electronics, APQ8064 DB600c";
@@ -69,6 +71,20 @@
regulator-max-microvolt = <130>;
qcom,switch-mode-frequency = <320>;
};
+
+ l5 {
+ regulator-min-microvolt = <275>;
+ regulator-max-microvolt = <300>;
+ bias-pull-down;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ l6 {
+ regulator-min-microvolt = <295>;
+ regulator-max-microvolt = <295>;
+ bias-pull-down;
+ };
};
};
@@ -94,5 +110,23 @@
pinctrl-0 = <&gsbi7_uart_2pins>;
};
};
+
+ amba {
+ /* eMMC */
+ sdcc@1240 {
+ status = "okay";
+ vmmc-supply = <&pm8921_l5>;
+ vqmmc-supply = <&pm8921_s4>;
+ };
+
+ /* External micro SD card */
+ sdcc@1218 {
+ status = "okay";
+ vmmc-supply = <&pm8921_l6>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&card_detect>;
+ cd-gpios= <&tlmm_pinmux 26
GPIO_ACTIVE_HIGH>;
+ };
+ };
};
};
--
2.5.0
Re: [PATCH 0/11] introduce down_write_killable for rw_semaphore v3
Hi Ingo, Peter, do you plan to pull this into tip/locking or are you waiting for some more feedback or things to resolve? Thanks! -- Michal Hocko SUSE Labs
[PATCH v2 07/13] ARM: dts: db600c: add usb support
This patch adds usb host and otg support on board with required
regulators.
Signed-off-by: Srinivas Kandagatla
Acked-by: Bjorn Andersson
---
arch/arm/boot/dts/qcom-apq8064-arrow-db600c.dts | 64 +
1 file changed, 64 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-apq8064-arrow-db600c.dts
b/arch/arm/boot/dts/qcom-apq8064-arrow-db600c.dts
index d921424..2c563df 100644
--- a/arch/arm/boot/dts/qcom-apq8064-arrow-db600c.dts
+++ b/arch/arm/boot/dts/qcom-apq8064-arrow-db600c.dts
@@ -58,6 +58,12 @@
bias-pull-down;
};
+ s3 {
+ regulator-min-microvolt = <100>;
+ regulator-max-microvolt = <140>;
+ qcom,switch-mode-frequency = <480>;
+ };
+
s4 {
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
@@ -72,6 +78,18 @@
qcom,switch-mode-frequency = <320>;
};
+ l3 {
+ regulator-min-microvolt = <305>;
+ regulator-max-microvolt = <330>;
+ bias-pull-down;
+ };
+
+ l4 {
+ regulator-min-microvolt = <100>;
+ regulator-max-microvolt = <180>;
+ bias-pull-down;
+ };
+
l5 {
regulator-min-microvolt = <275>;
regulator-max-microvolt = <300>;
@@ -85,6 +103,12 @@
regulator-max-microvolt = <295>;
bias-pull-down;
};
+
+ l23 {
+ regulator-min-microvolt = <170>;
+ regulator-max-microvolt = <190>;
+ bias-pull-down;
+ };
};
};
@@ -111,6 +135,46 @@
};
};
+ /* OTG */
+ phy@1250 {
+ status = "okay";
+ dr_mode = "peripheral";
+ vddcx-supply= <&pm8921_s3>;
+ v3p3-supply = <&pm8921_l3>;
+ v1p8-supply = <&pm8921_l4>;
+ };
+
+ phy@1252 {
+ status = "okay";
+ vddcx-supply= <&pm8921_s3>;
+ v3p3-supply = <&pm8921_l3>;
+ v1p8-supply = <&pm8921_l23>;
+ };
+
+ phy@1253 {
+ status = "okay";
+ vddcx-supply= <&pm8921_s3>;
+ v3p3-supply = <&pm8921_l3>;
+ v1p8-supply = <&pm8921_l23>;
+ };
+
+ gadget@1250 {
+ status = "okay";
+ };
+
+ /* OTG */
+ usb@1250 {
+ status = "okay";
+ };
+
+ usb@1252 {
+ status = "okay";
+ };
+
+ usb@1253 {
+ status = "okay";
+ };
+
amba {
/* eMMC */
sdcc@1240 {
--
2.5.0
[PATCH v2 11/13] ARM: dts: db600c: add i2c support
This patch adds nodes required to enable 4 i2c buses on the board which
are connected to various sensors and eeprom.
Signed-off-by: Srinivas Kandagatla
---
arch/arm/boot/dts/qcom-apq8064-arrow-db600c.dts | 46 +
1 file changed, 46 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-apq8064-arrow-db600c.dts
b/arch/arm/boot/dts/qcom-apq8064-arrow-db600c.dts
index 8c18a4b..2f0dfff 100644
--- a/arch/arm/boot/dts/qcom-apq8064-arrow-db600c.dts
+++ b/arch/arm/boot/dts/qcom-apq8064-arrow-db600c.dts
@@ -9,6 +9,10 @@
aliases {
serial0 = &gsbi7_serial;
serial1 = &gsbi1_serial;
+ i2c0 = &gsbi2_i2c;
+ i2c1 = &gsbi3_i2c;
+ i2c2 = &gsbi4_i2c;
+ i2c3 = &gsbi7_i2c;
};
regulators {
@@ -141,6 +145,42 @@
};
};
+ gsbi@1248 {
+ status = "okay";
+ qcom,mode = ;
+ i2c@124a {
+ /* On Low speed expansion and Sensors */
+ label = "LS-I2C0";
+ status = "okay";
+ };
+ };
+
+ gsbi@1620 {
+ status = "okay";
+ qcom,mode = ;
+ i2c@1628 {
+ /* On Low speed expansion */
+ status = "okay";
+ label = "LS-I2C1";
+ clock-frequency = <20>;
+ eeprom@52 {
+ compatible = "atmel,24c128";
+ reg = <0x52>;
+ pagesize = <64>;
+ };
+ };
+ };
+
+ gsbi@1630 {
+ status = "okay";
+ qcom,mode = ;
+ i2c@1638 {
+ /* On High speed expansion */
+ label = "HS-CAM-I2C3";
+ status = "okay";
+ };
+ };
+
/* DEBUG UART */
gsbi@1660 {
status = "okay";
@@ -151,6 +191,12 @@
pinctrl-names = "default";
pinctrl-0 = <&gsbi7_uart_2pins>;
};
+
+ i2c@1668 {
+ /* On High speed expansion */
+ status = "okay";
+ label = "HS-CAM-I2C2";
+ };
};
leds {
--
2.5.0
[PATCH v2 05/13] ARM: dts: db600c: add pmic regulator supplies
This patch adds pmic regulator supplies connected on the board.
Rest of the invidual regulators would be added as and when required by
the devices.
Signed-off-by: Srinivas Kandagatla
Acked-by: Bjorn Andersson
---
arch/arm/boot/dts/qcom-apq8064-arrow-db600c.dts | 62 +
1 file changed, 62 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-apq8064-arrow-db600c.dts
b/arch/arm/boot/dts/qcom-apq8064-arrow-db600c.dts
index 57d4500..6695b00 100644
--- a/arch/arm/boot/dts/qcom-apq8064-arrow-db600c.dts
+++ b/arch/arm/boot/dts/qcom-apq8064-arrow-db600c.dts
@@ -9,7 +9,69 @@
serial1 = &gsbi1_serial;
};
+ regulators {
+ compatible = "simple-bus";
+ vph: regulator-fixed@1 {
+ compatible = "regulator-fixed";
+ regulator-min-microvolt = <450>;
+ regulator-max-microvolt = <450>;
+ regulator-name = "VPH";
+ regulator-type = "voltage";
+ regulator-boot-on;
+ };
+ };
+
soc {
+ rpm@108000 {
+ regulators {
+ vdd_s1-supply = <&vph>;
+ vdd_s2-supply = <&vph>;
+ vdd_s3-supply = <&vph>;
+ vdd_s4-supply = <&vph>;
+ vdd_s5-supply = <&vph>;
+ vdd_s6-supply = <&vph>;
+ vdd_s7-supply = <&vph>;
+ vdd_l1_l2_l12_l18-supply = <&pm8921_s4>;
+ vdd_l3_l15_l17-supply = <&vph>;
+ vdd_l4_l14-supply = <&vph>;
+ vdd_l5_l8_l16-supply = <&vph>;
+ vdd_l6_l7-supply = <&vph>;
+ vdd_l9_l11-supply = <&vph>;
+ vdd_l10_l22-supply = <&vph>;
+ vdd_l21_l23_l29-supply = <&vph>;
+ vdd_l24-supply = <&pm8921_s1>;
+ vdd_l25-supply = <&pm8921_s1>;
+ vdd_l26-supply = <&pm8921_s7>;
+ vdd_l27-supply = <&pm8921_s7>;
+ vdd_l28-supply = <&pm8921_s7>;
+ vin_lvs1_3_6-supply = <&pm8921_s4>;
+ vin_lvs2-supply = <&pm8921_s1>;
+ vin_lvs4_5_7-supply = <&pm8921_s4>;
+
+ s1 {
+ regulator-always-on;
+ regulator-min-microvolt = <1225000>;
+ regulator-max-microvolt = <1225000>;
+ qcom,switch-mode-frequency = <320>;
+ bias-pull-down;
+ };
+
+ s4 {
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ qcom,switch-mode-frequency = <320>;
+ bias-pull-down;
+ regulator-always-on;
+ };
+
+ s7 {
+ regulator-min-microvolt = <130>;
+ regulator-max-microvolt = <130>;
+ qcom,switch-mode-frequency = <320>;
+};
+ };
+ };
+
gsbi@1244 {
status = "okay";
qcom,mode = ;
--
2.5.0
[PATCH v2 08/13] ARM: dts: db600c: add pcie support
This patch adds pcie and regulators required to get on board ATL1C
ethernet working.
Signed-off-by: Srinivas Kandagatla
Acked-by: Bjorn Andersson
---
.../boot/dts/qcom-apq8064-arrow-db600c-pins.dtsi | 12 +++
arch/arm/boot/dts/qcom-apq8064-arrow-db600c.dts| 24 ++
2 files changed, 36 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-apq8064-arrow-db600c-pins.dtsi
b/arch/arm/boot/dts/qcom-apq8064-arrow-db600c-pins.dtsi
index 7339919..0610f00 100644
--- a/arch/arm/boot/dts/qcom-apq8064-arrow-db600c-pins.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064-arrow-db600c-pins.dtsi
@@ -6,4 +6,16 @@
bias-disable;
};
};
+
+ pcie_pins: pcie-pinmux {
+ mux {
+ pins = "gpio27";
+ function = "gpio";
+ };
+ conf {
+ pins = "gpio27";
+ drive-strength = <12>;
+ bias-disable;
+ };
+ };
};
diff --git a/arch/arm/boot/dts/qcom-apq8064-arrow-db600c.dts
b/arch/arm/boot/dts/qcom-apq8064-arrow-db600c.dts
index 2c563df..4f2218c 100644
--- a/arch/arm/boot/dts/qcom-apq8064-arrow-db600c.dts
+++ b/arch/arm/boot/dts/qcom-apq8064-arrow-db600c.dts
@@ -21,6 +21,16 @@
regulator-type = "voltage";
regulator-boot-on;
};
+
+ /* on board fixed 3.3v supply */
+ vcc3v3: vcc3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC3V3";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-always-on;
+ };
+
};
soc {
@@ -109,6 +119,10 @@
regulator-max-microvolt = <190>;
bias-pull-down;
};
+
+ lvs6 {
+ bias-pull-down;
+ };
};
};
@@ -135,6 +149,16 @@
};
};
+ pci@1b50 {
+ status = "okay";
+ vdda-supply = <&pm8921_s3>;
+ vdda_phy-supply = <&pm8921_lvs6>;
+ vdda_refclk-supply = <&vcc3v3>;
+ pinctrl-0 = <&pcie_pins>;
+ pinctrl-names = "default";
+ perst-gpio = <&tlmm_pinmux 27 GPIO_ACTIVE_LOW>;
+ };
+
/* OTG */
phy@1250 {
status = "okay";
--
2.5.0
[PATCH v2 02/13] ARM: dts: apq8064: add support to gsbi1 uart
This patch adds support to gsbi1 uart and its pinctrls nodes.
Signed-off-by: Srinivas Kandagatla
---
arch/arm/boot/dts/qcom-apq8064-pins.dtsi | 14 ++
arch/arm/boot/dts/qcom-apq8064.dtsi | 10 ++
2 files changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-apq8064-pins.dtsi
b/arch/arm/boot/dts/qcom-apq8064-pins.dtsi
index b57c59d..8bb5e5f 100644
--- a/arch/arm/boot/dts/qcom-apq8064-pins.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064-pins.dtsi
@@ -39,6 +39,20 @@
};
};
+ gsbi1_uart_2pins: gsbi1_uart_2pins {
+ mux {
+ pins = "gpio18", "gpio19";
+ function = "gsbi1";
+ };
+ };
+
+ gsbi1_uart_4pins: gsbi1_uart_4pins {
+ mux {
+ pins = "gpio18", "gpio19", "gpio20", "gpio21";
+ function = "gsbi1";
+ };
+ };
+
i2c2_pins: i2c2 {
mux {
pins = "gpio24", "gpio25";
diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi
b/arch/arm/boot/dts/qcom-apq8064.dtsi
index c6ff8fc..81b4290 100644
--- a/arch/arm/boot/dts/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -225,6 +225,16 @@
syscon-tcsr = <&tcsr>;
+ gsbi1_serial: serial@1245 {
+ compatible = "qcom,msm-uartdm-v1.3",
"qcom,msm-uartdm";
+ reg = <0x1245 0x100>,
+ <0x1240 0x03>;
+ interrupts = <0 193 0x0>;
+ clocks = <&gcc GSBI1_UART_CLK>, <&gcc
GSBI1_H_CLK>;
+ clock-names = "core", "iface";
+ status = "disabled";
+ };
+
gsbi1_i2c: i2c@1246 {
compatible = "qcom,i2c-qup-v1.1.1";
pinctrl-0 = <&i2c1_pins>;
--
2.5.0
