* [PATCH 3/3] crypto: brcm: Add Broadcom SPU driver DT entry.
From: Rob (William) Rice @ 2016-12-14 15:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201612110810.BEVbRp0B%fengguang.wu@intel.com>
I will rebase to Herbert's latest when I submit v3 to address Mark
Rutland's DT comments (and any others that come in).
Rob
On 12/10/2016 7:14 PM, kbuild test robot wrote:
> Hi Rob,
>
> [auto build test ERROR on cryptodev/master]
> [also build test ERROR on v4.9-rc8]
> [cannot apply to next-20161209]
> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
>
> url: https://github.com/0day-ci/linux/commits/Rob-Rice/crypto-brcm-DT-documentation-for-Broadcom-SPU-driver/20161202-010038
> base: https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
> config: arm64-defconfig (attached as .config)
> compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
> reproduce:
> wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=arm64
>
> All errors (new ones prefixed by >>):
>
>>> ERROR: Input tree has errors, aborting (use -f to force output)
> ---
> 0-DAY kernel test infrastructure Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* [PATCHv6] support for AD5820 camera auto-focus coil
From: Tony Lindgren @ 2016-12-14 15:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201612141438.16603@pali>
* Pali Roh?r <pali.rohar@gmail.com> [161214 05:38]:
> On Monday 08 August 2016 23:41:32 Pavel Machek wrote:
> > On Mon 2016-08-08 11:09:56, Sakari Ailus wrote:
> > > On Fri, Aug 05, 2016 at 12:26:11PM +0200, Pavel Machek wrote:
> > > > This adds support for AD5820 autofocus coil, found for example in
> > > > Nokia N900 smartphone.
> > >
> > > Thanks, Pavel!
> > >
> > > Let's use V4L2_CID_FOCUS_ABSOLUTE, as is in the patch. If we get
> > > something better in the future, we'll switch to that then.
> > >
> > > I've applied this to ad5820 branch in my tree.
> >
> > Thanks. If I understands things correctly, both DTS patch and this
> > patch are waiting in your tree, so we should be good to go for 4.9
> > (unless some unexpected problems surface)?
> >
> > Best regards,
> > Pavel
>
> Was DTS patch merged into 4.9? At least I do not see updated that dts
> file omap3-n900.dts in linus tree...
If it's not in current mainline or next, it's off my radar so sounds
like I've somehow missed it and needs resending..
Tony
^ permalink raw reply
* partial bluetooth success on n900 [was Re: bluetooth/uart timeout handling]
From: Tony Lindgren @ 2016-12-14 15:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161214133158.mwvs574l4otbc7hf@earth>
* Sebastian Reichel <sre@kernel.org> [161214 05:32]:
> Hi Pali & Pavel,
>
> On Wed, Dec 14, 2016 at 01:53:23PM +0100, Pavel Machek wrote:
> > > > [ 220.248596] tty ttyO1: Radio packet sent
> > > > [ 220.249328] Bluetooth: hci0: Frame reassembly failed (-84)
> > > > [ 220.272949] tty ttyO1: wakeup received: 1 -> 0
> > > > [ 221.283477] tty ttyO1: radio packet timeout!
> > > > [ 221.283630] enqueue: hu c304cc80 skb cd4a9b40
> > > > [ 223.363372] Bluetooth: hci0 command 0xfc18 tx timeout
> > > > pavel at n900:~$
> > >
> > > In log are still some failures, but ... is bluetooth working now?
>
> I could scan for devices. The code is still racy, though. It's
> most likely related to the newly introduced idle code. (Without
> sending the BT module to correctly idle the bcm2048 does not
> work correctly at all)
>
> I was quite busy the last few weeks and did not manage to find
> much time for kernel work. Now I will first have to catch up
> with my power-supply tree.
>
> > It is... for Sebastian. I'm playing with camera now.
> >
> > > I see that you applied this patch:
> > > https://git.kernel.org/cgit/linux/kernel/git/pavel/linux-n900.git/commit/?id=051aa3fbf03ac770d8344690f5a936a7f04c6884
> > >
> > > Looks like that pinmux is in DTS file incorrect. Can somebody verify it?
> > > Maybe Tony?
> >
> > Yes, it is. Sebastian was pretty certain about that.
>
> Yes, I'm certain. The bootloader enables the pullup resistors.
> Note, that the wrong DTS entry is not in mainline. My bluetooth
> branch has a fixed DTS patch instead of a fixup patch on top of
> the broken one:
>
> https://git.kernel.org/cgit/linux/kernel/git/sre/linux-n900.git/commit/?h=nokia-bluetooth-dev&id=6b63c111a979d100cfbdd76cb4a6bbadace35216
Maybe send it so we can merge it as a fix during the early -rc
cycle?
Regards,
Tony
^ permalink raw reply
* [PATCH v2] ARM: dts: sunxi: Change node name for pwrseq pin on Olinuxino-lime2-emmc
From: Maxime Ripard @ 2016-12-14 15:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161214145724.42745-1-manu@bidouilliste.com>
On Wed, Dec 14, 2016 at 03:57:24PM +0100, Emmanuel Vadot wrote:
> The node name for the power seq pin is mmc2 at 0 like the mmc2_pins_a one.
> This makes the original node (mmc2_pins_a) scrapped out of the dtb and
> result in a unusable eMMC if U-Boot didn't configured the pins to the
> correct functions.
>
> Changes since v1:
> * Rename the node mmc2-rst-pin
That changelog should be after the ---. Removed it and applied.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161214/2918b004/attachment.sig>
^ permalink raw reply
* [PATCH v2 01/11] power: supply: axp20x_usb_power: use of_device_id data field instead of device_is_compatible
From: Chen-Yu Tsai @ 2016-12-14 15:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161209110419.28981-2-quentin.schulz@free-electrons.com>
On Fri, Dec 9, 2016 at 7:04 PM, Quentin Schulz
<quentin.schulz@free-electrons.com> wrote:
> This replaces calls to of_device_is_compatible to check data field of
> of_device_id matched when probing the driver.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
^ permalink raw reply
* [PATCH v2 02/11] mfd: axp20x: add volatile and writeable reg ranges for VBUS power supply driver
From: Chen-Yu Tsai @ 2016-12-14 15:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161209110419.28981-3-quentin.schulz@free-electrons.com>
On Fri, Dec 9, 2016 at 7:04 PM, Quentin Schulz
<quentin.schulz@free-electrons.com> wrote:
> The X-Powers AXP20X and AXP22X PMICs allow to choose the maximum voltage
> and minimum current delivered by the VBUS power supply.
>
> This adds the register used by the VBUS power supply driver to the range
> of volatile and writeable regs ranges.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
> ---
>
> added in v2
>
> drivers/mfd/axp20x.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
> index ba130be..6ee2cc6 100644
> --- a/drivers/mfd/axp20x.c
> +++ b/drivers/mfd/axp20x.c
> @@ -65,12 +65,14 @@ static const struct regmap_access_table axp152_volatile_table = {
>
> static const struct regmap_range axp20x_writeable_ranges[] = {
> regmap_reg_range(AXP20X_DATACACHE(0), AXP20X_IRQ5_STATE),
> + regmap_reg_range(AXP20X_VBUS_IPSOUT_MGMT, AXP20X_VBUS_IPSOUT_MGMT),
This is already covered by the previous entry.
> regmap_reg_range(AXP20X_DCDC_MODE, AXP20X_FG_RES),
> regmap_reg_range(AXP20X_RDC_H, AXP20X_OCV(AXP20X_OCV_MAX)),
> };
>
> static const struct regmap_range axp20x_volatile_ranges[] = {
> regmap_reg_range(AXP20X_PWR_INPUT_STATUS, AXP20X_USB_OTG_STATUS),
> + regmap_reg_range(AXP20X_VBUS_IPSOUT_MGMT, AXP20X_VBUS_IPSOUT_MGMT),
And I'm not sure why you specify it as volatile? The PMIC doesn't change any
of the bits in this register on its own.
Same for the AXP22x bits. So basically I think you don't need this patch.
ChenYu
> regmap_reg_range(AXP20X_CHRG_CTRL1, AXP20X_CHRG_CTRL2),
> regmap_reg_range(AXP20X_IRQ1_EN, AXP20X_IRQ5_STATE),
> regmap_reg_range(AXP20X_ACIN_V_ADC_H, AXP20X_IPSOUT_V_HIGH_L),
> @@ -91,11 +93,13 @@ static const struct regmap_access_table axp20x_volatile_table = {
> /* AXP22x ranges are shared with the AXP809, as they cover the same range */
> static const struct regmap_range axp22x_writeable_ranges[] = {
> regmap_reg_range(AXP20X_DATACACHE(0), AXP20X_IRQ5_STATE),
> + regmap_reg_range(AXP20X_VBUS_IPSOUT_MGMT, AXP20X_VBUS_IPSOUT_MGMT),
> regmap_reg_range(AXP20X_DCDC_MODE, AXP22X_BATLOW_THRES1),
> };
>
> static const struct regmap_range axp22x_volatile_ranges[] = {
> regmap_reg_range(AXP20X_PWR_INPUT_STATUS, AXP20X_PWR_OP_MODE),
> + regmap_reg_range(AXP20X_VBUS_IPSOUT_MGMT, AXP20X_VBUS_IPSOUT_MGMT),
> regmap_reg_range(AXP20X_IRQ1_EN, AXP20X_IRQ5_STATE),
> regmap_reg_range(AXP22X_GPIO_STATE, AXP22X_GPIO_STATE),
> regmap_reg_range(AXP20X_FG_RES, AXP20X_FG_RES),
> --
> 2.9.3
>
^ permalink raw reply
* [PATCH v2 03/11] power: supply: axp20x_usb_power: set min voltage and max current from sysfs
From: Chen-Yu Tsai @ 2016-12-14 15:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161209110419.28981-4-quentin.schulz@free-electrons.com>
On Fri, Dec 9, 2016 at 7:04 PM, Quentin Schulz
<quentin.schulz@free-electrons.com> wrote:
> AXP20X and AXP22X PMICs allow setting the min voltage and max current of
> VBUS power supply. This adds entries in sysfs to allow to do so.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
^ permalink raw reply
* partial bluetooth success on n900 [was Re: bluetooth/uart timeout handling]
From: Sebastian Reichel @ 2016-12-14 15:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161214151056.GX4920@atomide.com>
Hi Tony,
On Wed, Dec 14, 2016 at 07:10:56AM -0800, Tony Lindgren wrote:
> * Sebastian Reichel <sre@kernel.org> [161214 05:32]:
> > Hi Pali & Pavel,
> >
> > On Wed, Dec 14, 2016 at 01:53:23PM +0100, Pavel Machek wrote:
> > > > > [ 220.248596] tty ttyO1: Radio packet sent
> > > > > [ 220.249328] Bluetooth: hci0: Frame reassembly failed (-84)
> > > > > [ 220.272949] tty ttyO1: wakeup received: 1 -> 0
> > > > > [ 221.283477] tty ttyO1: radio packet timeout!
> > > > > [ 221.283630] enqueue: hu c304cc80 skb cd4a9b40
> > > > > [ 223.363372] Bluetooth: hci0 command 0xfc18 tx timeout
> > > > > pavel at n900:~$
> > > >
> > > > In log are still some failures, but ... is bluetooth working now?
> >
> > I could scan for devices. The code is still racy, though. It's
> > most likely related to the newly introduced idle code. (Without
> > sending the BT module to correctly idle the bcm2048 does not
> > work correctly at all)
> >
> > I was quite busy the last few weeks and did not manage to find
> > much time for kernel work. Now I will first have to catch up
> > with my power-supply tree.
> >
> > > It is... for Sebastian. I'm playing with camera now.
> > >
> > > > I see that you applied this patch:
> > > > https://git.kernel.org/cgit/linux/kernel/git/pavel/linux-n900.git/commit/?id=051aa3fbf03ac770d8344690f5a936a7f04c6884
> > > >
> > > > Looks like that pinmux is in DTS file incorrect. Can somebody verify it?
> > > > Maybe Tony?
> > >
> > > Yes, it is. Sebastian was pretty certain about that.
> >
> > Yes, I'm certain. The bootloader enables the pullup resistors.
> > Note, that the wrong DTS entry is not in mainline. My bluetooth
> > branch has a fixed DTS patch instead of a fixup patch on top of
> > the broken one:
> >
> > https://git.kernel.org/cgit/linux/kernel/git/sre/linux-n900.git/commit/?h=nokia-bluetooth-dev&id=6b63c111a979d100cfbdd76cb4a6bbadace35216
>
> Maybe send it so we can merge it as a fix during the early -rc
> cycle?
Sorry if I was not clear enough: mainline does *not* contain
incorrect DT information. My bluetooth RFC patches did. So
this can go into the kernel once the driver is there and
the binding got accepted.
Alternatively I can prepare a patch, which just adds the
cts/rts pinmux for the bluetooth UART, but it's not very
useful on its own.
-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161214/5d0c089d/attachment.sig>
^ permalink raw reply
* Linux crashes when trying to online secondary core
From: Mason @ 2016-12-14 16:01 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
I'm seeing Linux v4.9 crash (dereferencing NULL) when I try to online
the secondary core, after putting it offline.
Perhaps commit 00c1d17aab513d3b8117fb84644eba39434b33e4 is relevant?
You will find below:
1) the full boot log
2) the defconfig I used
Note #1: I added the following patch for debugging purpose:
diff --git a/arch/arm/mach-tango/platsmp.c b/arch/arm/mach-tango/platsmp.c
index 98c62a4a8623..c6865935f21b 100644
--- a/arch/arm/mach-tango/platsmp.c
+++ b/arch/arm/mach-tango/platsmp.c
@@ -5,8 +5,14 @@
static int tango_boot_secondary(unsigned int cpu, struct task_struct *idle)
{
+ int ret;
+ printk("%s from %pf\n", __func__, __builtin_return_address(0));
+ ret =
tango_set_aux_boot_addr(virt_to_phys(secondary_startup));
+ printk("tango_set_aux_boot_addr=%d\n", ret);
+ ret =
tango_start_aux_core(cpu);
+ printk("tango_start_aux_core=%d\n", ret);
return 0;
}
Note #2: Linux runs as untrusted OS (trustzone thing). Trusted OS
is called armor. Sometimes armor and Linux print to the console
at the same time, which explains some hard-to-read output.
## Booting kernel from Legacy Image at 84001000 ...
Image Name: Linux-4.9.0
Created: 2016-12-14 14:31:44 UTC
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 6903791 Bytes = 6.6 MiB
Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Starting kernel ...
SMC called with a0=0x00000000 a1=0x00000000 a2=0x00000000 a3=0x20100000 0x00000102
SMC called with a0=0x00000000 a1=0x00000000 a2=0x00000000 a3=0x00000064 0x00000102
SMC called with a0=0x00000001 a1=0x00000102 a2=0xd0804730 a3=0xc0119380 0x00000102
SMC called with a0=0x80101500 a1=0x00000105 a2=0x00000000 a3=0x00000000 0x00000105
SMC called with a0=0x00000001 a1=0x00000104 a2=0x00000000 a3=0x00000000 0x00000104
[0][flow/smc_handler.c:127] waking up CPU1
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 4.9.0 (me at misti.france.sdesigns.com) (gcc version 5.3.1 20160113 (Linaro GCC 5.3-2016.02) ) #143 SMP PREEMPT Wed Dec 14 15:31:39 CET 2016
[ 0.000000] CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c5387d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[ 0.000000] OF: fdt:Machine model: Sigma Designs SMP8758 Vantage-1172 Rev E1
[ 0.000000] Memory policy: Data cache writealloc
[ 0.000000] On node 0 totalpages: 65536
[ 0.000000] free_area_init_node: node 0, pgdat c0b20f00, node_mem_map cfdf9000
[ 0.000000] Normal zone: 512 pages used for memmap
[ 0.000000] Normal zone: 0 pages reserved
[ 0.000000] Normal zone: 65536 pages, LIFO batch:15
[ 0.000000] percpu: Embedded 14 pages/cpu @cfdd6000 s25728 r8192 d23424 u57344
[ 0.000000] pcpu-alloc: s25728 r8192 d23424 u57344 alloc=14*4096
[ 0.000000] pcpu-alloc: [0] 0 [0] 1
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024
[ 0.000000] Kernel command line: console=ttyS0,115200 mem=256M debug no_console_suspend
[ 0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[ 0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[ 0.000000] Memory: 249108K/262144K available (4096K kernel code, 134K rwdata, 872K rodata, 5120K init, 231K bss, 13036K reserved, 0K cma-reserved, 0K highmem)
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB)
[ 0.000000] fixmap : 0xffc00000 - 0xfff00000 (3072 kB)
[ 0.000000] vmalloc : 0xd0800000 - 0xff800000 ( 752 MB)
[ 0.000000] lowmem : 0xc0000000 - 0xd0000000 ( 256 MB)
[ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB)
[ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB)
[ 0.000000] .text : 0xc0008000 - 0xc0500000 (5088 kB)
[ 0.000000] .init : 0xc0600000 - 0xc0b00000 (5120 kB)
[ 0.000000] .data : 0xc0b00000 - 0xc0b21800 ( 134 kB)
[ 0.000000] .bss : 0xc0b21800 - 0xc0b5b680 ( 232 kB)
[ 0.000000] Preemptible hierarchical RCU implementation.
[ 0.000000] Build-time adjustment of leaf fanout to 32.
[ 0.000000] RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2.
[ 0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=32, nr_cpu_ids=2
[ 0.000000] NR_IRQS:16 nr_irqs:16 16
[ 0.000000] L2C-310 enabling early BRESP for Cortex-A9
[ 0.000000] L2C-310 ID prefetch enabled, offset 4 lines
[ 0.000000] L2C-310 dynamic clock gating enabled, standby mode enabled
[ 0.000000] L2C-310 cache controller enabled, 8 ways, 512 kB
[ 0.000000] L2C-310: CACHE_ID 0x410000c8, AUX_CTRL 0x72860401
[ 0.000000] clocksource: tango-xtal: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 70787423951 ns
[ 0.000004] sched_clock: 32 bits at 27MHz, resolution 37ns, wraps every 79536431085ns
[ 0.000012] Switching to timer-based delay loop, resolution 37ns
[ 0.000256] Console: colour dummy device 80x30
[ 0.000278] Calibrating delay loop (skipped), value calculated using timer frequency.. 54.25 BogoMIPS (lpj=90000)
[ 0.000289] pid_max: default: 32768 minimum: 301
[ 0.000393] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.000400] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.000896] CPU: Testing write buffer coherency: ok
[ 0.001133] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[ 0.001178] Setting up static identity map for 0x80100000 - 0x80100058
[ 0.056732] tango_boot_secondary from __cpu_up
[ 0.063938] tango_set_aux_boot_addr=0
[ 0.075101] tango_start_aux_core=0
[ 0.075229] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
[ 0.075319] Brought up 2 CPUs
[ 0.075330] SMP: Total of 2 processors activated (108.50 BogoMIPS).
[ 0.075337] CPU: All CPU(s) started in SVC mode.
[ 0.075951] devtmpfs: initialized
[ 0.077370] VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4
[ 0.077819] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 6370867519511994 ns
[ 0.078226] NET: Registered protocol family 16
[ 0.078999] DMA: preallocated 256 KiB pool for atomic coherent allocations
[ 0.080104] hw-breakpoint: found 5 (+1 reserved) breakpoint and 1 watchpoint registers.
[ 0.080116] hw-breakpoint: maximum watchpoint size is 4 bytes.
[ 0.094156] SCSI subsystem initialized
[ 0.094678] usbcore: registered new interface driver usbfs
[ 0.094788] usbcore: registered new interface driver hub
[ 0.094887] usbcore: registered new device driver usb
[ 0.096948] clocksource: Switched to clocksource tango-xtal
[ 0.110399] NET: Registered protocol family 2
[ 0.110923] TCP established hash table entries: 2048 (order: 1, 8192 bytes)
[ 0.110949] TCP bind hash table entries: 2048 (order: 2, 16384 bytes)
[ 0.110977] TCP: Hash tables configured (established 2048 bind 2048)
[ 0.111051] UDP hash table entries: 256 (order: 1, 8192 bytes)
[ 0.111082] UDP-Lite hash table entries: 256 (order: 1, 8192 bytes)
[ 0.111239] NET: Registered protocol family 1
[ 0.111623] RPC: Registered named UNIX socket transport module.
[ 0.111631] RPC: Registered udp transport module.
[ 0.111636] RPC: Registered tcp transport module.
[ 0.111641] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 0.310427] hw perfevents: enabled with armv7_cortex_a9 PMU driver, 7 counters available
[ 0.311930] futex hash table entries: 512 (order: 3, 32768 bytes)
[ 0.312759] workingset: timestamp_bits=30 max_order=16 bucket_order=0
[ 0.313862] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252)
[ 0.313883] io scheduler noop registered
[ 0.313891] io scheduler deadline registered
[ 0.313920] io scheduler cfq registered (default)
[ 0.315331] tangox-dma 290a0.dma: SMP86xx DMA with 2 channels, 1 slaves
[ 0.397789] Serial: 8250/16550 driver, 1 ports, IRQ sharing disabled
[ 0.399218] console [ttyS0] disabled
[ 0.399291] 10700.serial: ttyS0 at MMIO 0x10700 (irq = 20, base_baud = 460800) is a Palmchip BK-3103
[ 0.961466] console [ttyS0] enabled
[ 0.972296] loop: module loaded
[ 0.976476] libphy: Fixed MDIO Bus: probed
[ 0.990487] libphy: nb8800-mii: probed
[ 0.999534] nb8800 26000.ethernet eth0: MAC address 00:16:e8:43:2f:80
[ 1.006218] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 1.012991] usbcore: registered new interface driver usb-storage
[ 1.072811] ci_hdrc ci_hdrc.0: doesn't support gadget
[ 1.077917] ci_hdrc ci_hdrc.0: EHCI Host Controller
[ 1.082851] ci_hdrc ci_hdrc.0: new USB bus registered, assigned bus number 1
[ 1.100296] ci_hdrc ci_hdrc.0: USB 2.0 started, EHCI 1.00
[ 1.106586] hub 1-0:1.0: USB hub found
[ 1.110424] hub 1-0:1.0: 1 port detected
[ 1.169474] ci_hdrc ci_hdrc.1: doesn't support gadget
[ 1.174577] ci_hdrc ci_hdrc.1: EHCI Host Controller
[ 1.179510] ci_hdrc ci_hdrc.1: new USB bus registered, assigned bus number 2
[ 1.196962] ci_hdrc ci_hdrc.1: USB 2.0 started, EHCI 1.00
[ 1.203147] hub 2-0:1.0: USB hub found
[ 1.206980] hub 2-0:1.0: 1 port detected
[ 1.212967] tangox-wdt 1fd00.watchdog: SMP86xx/SMP87xx watchdog registered
[ 1.221059] sdhci: Secure Digital Host Controller Interface driver
[ 1.227316] sdhci: Copyright(c) Pierre Ossman
[ 1.231703] sdhci-pltfm: SDHCI platform and OF driver helper
[ 1.237845] usbcore: registered new interface driver usbhid
[ 1.243463] usbhid: USB HID core driver
[ 1.247645] NET: Registered protocol family 17
[ 1.252201] Registering SWP/SWPB emulation handler
[ 1.266305] Freeing unused kernel memory: 5120K (c0600000 - c0b00000)
Starting logging: OK
Initializing random number generator... [ 1.359367] random: dd: uninitialized urandom read (512 bytes read)
done.
Starting network: OK
Starting telnetd: OK
Welcome to Buildroot
buildroot login: root
#
# echo 0 > /sys/devices/system/cpu/cpu1/online
SMC called with a0=[0x00000001 a1=0x00000 121 a2=0x000 00005 a3 =0xc01193b4 70x000000121
[1][flow/suspend.c:39]. CPU 1 die:3 jumping to post-boot WFE4
4187] CPU1: shutdown
SMC called with a0=0x00000001 a1=0x00000122 a2=0x00000000 a3=0x00000000 0x00000122
[0][flow/suspend.c:82] Killing core1
armor+++ armor: core 1 booted, entering wfe...
#
# echo 1 > /sys/devices/system/cpu/cpu1/online
[ 86.924294] tango_boot_secondary from __cpu_up
SMC called with a0=0x80101500 a1=0x00000105 a2=0x00000000 a3=0x00000000 0x00000105
[ 86.936275] tango_set_aux_boot_addr=0
SMC called with a0=0x00000001 a1=0x00000104 a2=0x00000000 a3=0x00000000 0x00000104
[0][flow/smc_handler.c:127] waking up CPU1
[ 86.9[ 8516.92512662]2] U Unnaabbllee tto ho ahnandledle kerkernenell NULL pointer dereference at virtual address 00000000
[ 86.951266] pgd = c0004000
[ 86.951271] [00000000] *pgd=00000000
[ 86.951280] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
[ 86.951285] Modules linked in:
[ 86.951292] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.9.0 #143
[ 86.951294] Hardware name: Sigma Tango DT
[ 86.951297] task: cf85b140 task.stack: cf85e000
[ 86.951312] PC is at tick_broadcast_setup_oneshot+0x18/0x134
[ 86.951319] LR is at debug_smp_processor_id+0x20/0x24
[ 86.951324] pc : [<c0187394>] lr : [<c030f0a4>] psr: 200001d3
[ 86.951324] sp : cf85fe90 ip : cf85fe80 fp : cf85fecc
[ 86.951326] r10: 00000000 r9 : c05016d4 r8 : 400001d3
[ 86.951329] r7 : 00000000 r6 : cfde8f80 r5 : 00000000 r4 : 00000001
[ 86.951331] r3 : cf85e000 r2 : 00000002 r1 : c057d620 r0 : 00000001
[ 86.951335] Flags: nzCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment none
[ 86.951338] Control: 10c5387d Table: 8000404a DAC: 00000051
[ 86.951340] Process swapper/1 (pid: 0, stack limit = 0xcf85e210)
[ 86.951344] Stack: (0xcf85fe90 to 0xcf860000)
[ 86.951348] fe80: cf85fedc cf85fea0 c0b482dc 400001d3
[ 86.951354] fea0: cfde8f80 00000001 00000001 cfde8f80 00000000 400001d3 c05016d4 00000000
[ 86.951359] fec0: cf85fef4 cf85fed0 c01875f4 c0187388 cfde8f80 cfde78f0 00000001 00000000
[ 86.951364] fee0: 00000001 c05016d4 cf85ff2c cf85fef8 c0186318 c01874bc cf85ff14 cf85ff08
[ 86.951369] ff00: c0b0c150 cfde78f0 cfde8f80 00000001 00000000 a00001d3 00000001 00000000
[ 86.951374] ff20: cf85ff4c cf85ff30 c0186544 c01862bc c0b0c150 c0b0c150 c0b0c168 cfde8f80
[ 86.951379] ff40: cf85ff74 cf85ff50 c01852ec c018648c cfde4244 00000060 c0b07cf8 00000001
[ 86.951385] ff60: 0f3a5000 00000001 cf85ff84 cf85ff78 c03fcf10 c0185294 cf85ffb4 cf85ff88
[ 86.951390] ff80: c011c588 c03fceb4 00000000 cfde4244 00000060 00000001 c0a3f244 0f3a5000
[ 86.951395] ffa0: 413fc090 00000000 cf85ffdc cf85ffb8 c011e10c c011c53c c0b0d198 00000001
[ 86.951400] ffc0: 10c0387d c0b21ae8 8000406a 413fc090 cf85fff4 cf85ffe0 c010dd6c c011e0bc
[ 86.951405] ffe0: 8f84006a 00000051 00000000 cf85fff8 8010158c c010dc88 8f34eea9 0607fa8b
[ 86.951408] Backtrace:
[ 86.951417] [<c018737c>] (tick_broadcast_setup_oneshot) from [<c01875f4>] (tick_device_uses_broadcast+0x144/0x1a8)
[ 86.951423] r10:00000000 r9:c05016d4 r8:400001d3 r7:00000000 r6:cfde8f80 r5:00000001
[ 86.951425] r4:00000001
[ 86.951431] [<c01874b0>] (tick_device_uses_broadcast) from [<c0186318>] (tick_setup_device+0x68/0x110)
[ 86.951437] r9:c05016d4 r8:00000001 r7:00000000 r6:00000001 r5:cfde78f0 r4:cfde8f80
[ 86.951443] [<c01862b0>] (tick_setup_device) from [<c0186544>] (tick_check_new_device+0xc4/0xe8)
[ 86.951448] r10:00000000 r9:00000001 r8:a00001d3 r7:00000000 r6:00000001 r5:cfde8f80
[ 86.951450] r4:cfde78f0
[ 86.951457] [<c0186480>] (tick_check_new_device) from [<c01852ec>] (clockevents_register_device+0x64/0x11c)
[ 86.951461] r7:cfde8f80 r6:c0b0c168 r5:c0b0c150 r4:c0b0c150
[ 86.951472] [<c0185288>] (clockevents_register_device) from [<c03fcf10>] (dummy_timer_starting_cpu+0x68/0x70)
[ 86.951478] r9:00000001 r8:0f3a5000 r7:00000001 r6:c0b07cf8 r5:00000060 r4:cfde4244
[ 86.951490] [<c03fcea8>] (dummy_timer_starting_cpu) from [<c011c588>] (cpuhp_invoke_callback+0x58/0x120)
[ 86.951497] [<c011c530>] (cpuhp_invoke_callback) from [<c011e10c>] (notify_cpu_starting+0x5c/0x6c)
[ 86.951503] r10:00000000 r9:413fc090 r8:0f3a5000 r7:c0a3f244 r6:00000001 r5:00000060
[ 86.951505] r4:cfde4244 r3:00000000
[ 86.951511] [<c011e0b0>] (notify_cpu_starting) from [<c010dd6c>] (secondary_start_kernel+0xf0/0x164)
[ 86.951516] r9:413fc090 r8:8000406a r7:c0b21ae8 r6:10c0387d r5:00000001 r4:c0b0d198
[ 86.951524] [<c010dc7c>] (secondary_start_kernel) from [<8010158c>] (0x8010158c)
[ 86.951526] r5:00000051 r4:8f84006a
[ 86.951532] Code: e24cb004 e24dd014 e1a05000 eb061f3b (e5952000)
[ 86.951537] ---[ end trace b9e15a7104bf60a3 ]---
[ 86.951543] Kernel panic - not syncing: Attempted to kill the idle task!
[ 86.962632] CPU0: stopping
[ 86.962638] CPU: 0 PID: 928 Comm: sh Tainted: G D 4.9.0 #143
[ 86.962640] Hardware name: Sigma Tango DT
[ 86.962643] Backtrace:
[ 86.962659] [<c010b9c4>] (dump_backtrace) from [<c010bc80>] (show_stack+0x18/0x1c)
[ 86.962664] r7:60000193 r6:c0b10914 r5:00000000 r4:c0b10914
[ 86.962674] [<c010bc68>] (show_stack) from [<c02f574c>] (dump_stack+0x80/0x94)
[ 86.962680] [<c02f56cc>] (dump_stack) from [<c010e1f4>] (handle_IPI+0x1a0/0x1b4)
[ 86.962685] r7:00000000 r6:00000004 r5:00000000 r4:c0a42ec4
[ 86.962690] [<c010e054>] (handle_IPI) from [<c01014ec>] (gic_handle_irq+0x90/0x94)
[ 86.962695] r9:d0803100 r8:d0802100 r7:cfbb7bb8 r6:d080210c r5:c0b03348 r4:c0b10b70
[ 86.962700] [<c010145c>] (gic_handle_irq) from [<c010c7cc>] (__irq_svc+0x6c/0xa8)
[ 86.962703] Exception stack(0xcfbb7bb8 to 0xcfbb7c00)
[ 86.962706] 7ba0: 00000000 60000093
[ 86.962711] 7bc0: 00000000 60000013 c0b26880 c0b43ca0 00000000 00000026 00000000 00000073
[ 86.962717] 7be0: 00002248 cfbb7c74 cfbb7b40 cfbb7c08 c04dc3d0 c0163780 60000013 ffffffff
[ 86.962722] r9:cfbb6000 r8:00000000 r7:cfbb7bec r6:ffffffff r5:60000013 r4:c0163780
[ 86.962732] [<c0163490>] (console_unlock) from [<c0163d40>] (vprintk_emit+0x2ac/0x4a8)
[ 86.962738] r10:00000000 r9:c0b23d20 r8:c0b0b03c r7:00000004 r6:00000002 r5:00000000
[ 86.962740] r4:00000016
[ 86.962746] [<c0163a94>] (vprintk_emit) from [<c01640dc>] (vprintk_default+0x28/0x30)
[ 86.962751] r10:00000000 r9:00000001 r8:c0b21ae8 r7:cf85b140 r6:c05a7a54 r5:c01640b4
[ 86.962753] r4:cfbb7d14
[ 86.962764] [<c01640b4>] (vprintk_default) from [<c01a7df8>] (printk+0x74/0x7c)
[ 86.962772] [<c01a7d88>] (printk) from [<c011949c>] (tango_boot_secondary+0x68/0x70)
[ 86.962776] r3:60000500 r2:00000003 r1:00000000 r0:c057376c
[ 86.962779] r5:00000001 r4:00000001
[ 86.962784] [<c0119434>] (tango_boot_secondary) from [<c010d9bc>] (__cpu_up+0xb0/0x144)
[ 86.962787] r5:00000001 r4:c0b21af8
[ 86.962792] [<c010d90c>] (__cpu_up) from [<c011d128>] (bringup_cpu+0x28/0xa8)
[ 86.962797] r9:00000001 r8:00000030 r7:00000001 r6:c0b086a8 r5:00000001 r4:cf85b140
[ 86.962804] [<c011d100>] (bringup_cpu) from [<c011c588>] (cpuhp_invoke_callback+0x58/0x120)
[ 86.962806] r5:00000001 r4:cfde4244
[ 86.962813] [<c011c530>] (cpuhp_invoke_callback) from [<c011c784>] (cpuhp_up_callbacks+0x2c/0xdc)
[ 86.962819] r10:00000000 r9:cfde4244 r8:00000030 r7:00000000 r6:00000000 r5:00000001
[ 86.962821] r4:cfde4244 r3:00000000
[ 86.962827] [<c011c758>] (cpuhp_up_callbacks) from [<c011dd38>] (_cpu_up+0xb0/0x10c)
[ 86.962832] r9:cfde4244 r8:0f3a5000 r7:00000097 r6:00000000 r5:00000001 r4:c0a3f244
[ 86.962837] [<c011dc88>] (_cpu_up) from [<c011de0c>] (do_cpu_up+0x78/0xa0)
[ 86.962842] r9:00000000 r8:00000000 r7:cec32540 r6:cfde4044 r5:00000097 r4:00000001
[ 86.962847] [<c011dd94>] (do_cpu_up) from [<c011de48>] (cpu_up+0x14/0x18)
[ 86.962849] r5:cfde4010 r4:c036154c
[ 86.962862] [<c011de34>] (cpu_up) from [<c0361560>] (cpu_subsys_online+0x14/0x18)
[ 86.962869] [<c036154c>] (cpu_subsys_online) from [<c035cb14>] (device_online+0x6c/0x90)
[ 86.962874] [<c035caa8>] (device_online) from [<c035cba8>] (online_store+0x70/0x7c)
[ 86.962878] r7:cec32540 r6:cfbb7f80 r5:00000002 r4:cfde4010
[ 86.962883] [<c035cb38>] (online_store) from [<c035a3d4>] (dev_attr_store+0x20/0x2c)
[ 86.962886] r5:00000002 r4:c035cb38
[ 86.962894] [<c035a3b4>] (dev_attr_store) from [<c024ac2c>] (sysfs_kf_write+0x48/0x4c)
[ 86.962897] r5:00000002 r4:c035a3b4
[ 86.962903] [<c024abe4>] (sysfs_kf_write) from [<c024a3e8>] (kernfs_fop_write+0xf8/0x1f8)
[ 86.962905] r5:00000002 r4:cf9d2b80
[ 86.962916] [<c024a2f0>] (kernfs_fop_write) from [<c01e3bd4>] (__vfs_write+0x34/0x120)
[ 86.962922] r10:00000000 r9:cfbb6000 r8:c0107d64 r7:00000002 r6:cfbb7f80 r5:c024a2f0
[ 86.962924] r4:cf9cd780
[ 86.962930] [<c01e3ba0>] (__vfs_write) from [<c01e4a68>] (vfs_write+0xac/0x170)
[ 86.962936] r9:cfbb6000 r8:c0107d64 r7:cfbb7f80 r6:00e0a408 r5:cf9cd780 r4:00000002
[ 86.962942] [<c01e49bc>] (vfs_write) from [<c01e5868>] (SyS_write+0x4c/0xa8)
[ 86.962947] r9:cfbb6000 r8:c0107d64 r7:00000002 r6:00e0a408 r5:cf9cd780 r4:cf9cd780
[ 86.962955] [<c01e581c>] (SyS_write) from [<c0107ba0>] (ret_fast_syscall+0x0/0x3c)
[ 86.962959] r7:00000004 r6:b6effd60 r5:00e0a408 r4:00000002
[ 87.718648] ---[ end Kernel panic - not syncing: Attempted to kill the idle task!
CONFIG_CROSS_COMPILE="arm-linux-gnueabihf-"
# CONFIG_SWAP is not set
CONFIG_SYSVIPC=y
CONFIG_NO_HZ_IDLE=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_EMBEDDED=y
CONFIG_PERF_EVENTS=y
# CONFIG_COMPAT_BRK is not set
CONFIG_SLAB=y
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODVERSIONS=y
CONFIG_ARCH_TANGO=y
# CONFIG_ARM_ERRATA_643719 is not set
CONFIG_SMP=y
CONFIG_PREEMPT=y
CONFIG_HZ_300=y
CONFIG_AEABI=y
CONFIG_HIGHMEM=y
# CONFIG_COMPACTION is not set
# CONFIG_ATAGS is not set
CONFIG_ARM_APPENDED_DTB=y
CONFIG_ARM_ATAG_DTB_COMPAT=y
CONFIG_CMDLINE="console=ttyS0,115200 mem=256M"
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_GOV_ONDEMAND=y
CONFIG_CPUFREQ_DT=y
CONFIG_VFP=y
CONFIG_NEON=y
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
# CONFIG_INET_XFRM_MODE_TUNNEL is not set
# CONFIG_INET_XFRM_MODE_BEET is not set
# CONFIG_IPV6 is not set
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_DEVTMPFS=y
CONFIG_MTD=y
CONFIG_MTD_TESTS=m
CONFIG_MTD_NAND=y
CONFIG_MTD_NAND_TANGO=m
CONFIG_MTD_UBI=m
CONFIG_BLK_DEV_LOOP=y
CONFIG_SCSI=y
CONFIG_BLK_DEV_SD=y
CONFIG_NETDEVICES=y
CONFIG_NET_VENDOR_AURORA=y
CONFIG_AURORA_NB8800=y
CONFIG_AT803X_PHY=y
# CONFIG_USB_NET_DRIVERS is not set
# CONFIG_WLAN is not set
# CONFIG_INPUT_MOUSEDEV is not set
# CONFIG_INPUT_KEYBOARD is not set
# CONFIG_INPUT_MOUSE is not set
# CONFIG_SERIO is not set
CONFIG_SERIAL_8250=y
# CONFIG_SERIAL_8250_DEPRECATED_OPTIONS is not set
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_NR_UARTS=1
CONFIG_SERIAL_8250_RUNTIME_UARTS=1
CONFIG_SERIAL_8250_RT288X=y
CONFIG_SERIAL_OF_PLATFORM=y
# CONFIG_HW_RANDOM is not set
CONFIG_I2C=y
CONFIG_I2C_XLR=y
CONFIG_GPIOLIB=y
CONFIG_THERMAL=y
CONFIG_CPU_THERMAL=y
CONFIG_TANGO_THERMAL=y
CONFIG_WATCHDOG=y
CONFIG_TANGOX_WATCHDOG=y
CONFIG_FB=y
CONFIG_USB=y
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_STORAGE=y
CONFIG_USB_CHIPIDEA=y
CONFIG_USB_CHIPIDEA_HOST=y
CONFIG_MMC=y
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_PLTFM=y
CONFIG_MMC_SDHCI_OF_ARASAN=y
CONFIG_DMADEVICES=y
CONFIG_TANGO_DMA=y
CONFIG_PHY_TANGO_USB=y
CONFIG_EXT4_FS=y
CONFIG_FUSE_FS=m
CONFIG_VFAT_FS=m
CONFIG_TMPFS=y
CONFIG_UBIFS_FS=m
CONFIG_NFS_FS=y
# CONFIG_NFS_V2 is not set
CONFIG_ROOT_NFS=y
CONFIG_NLS_CODEPAGE_437=m
CONFIG_NLS_ISO8859_1=m
CONFIG_NLS_UTF8=m
CONFIG_PRINTK_TIME=y
# CONFIG_FTRACE is not set
# CONFIG_ARM_UNWIND is not set
# CONFIG_CRYPTO_ECHAINIV is not set
Regards.
^ permalink raw reply related
* partial bluetooth success on n900 [was Re: bluetooth/uart timeout handling]
From: Tony Lindgren @ 2016-12-14 16:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161214155208.ocs4vw77expduefr@earth>
* Sebastian Reichel <sre@kernel.org> [161214 07:52]:
> On Wed, Dec 14, 2016 at 07:10:56AM -0800, Tony Lindgren wrote:
> > Maybe send it so we can merge it as a fix during the early -rc
> > cycle?
>
> Sorry if I was not clear enough: mainline does *not* contain
> incorrect DT information. My bluetooth RFC patches did. So
> this can go into the kernel once the driver is there and
> the binding got accepted.
Oh OK good to hear.
> Alternatively I can prepare a patch, which just adds the
> cts/rts pinmux for the bluetooth UART, but it's not very
> useful on its own.
OK sounds like no rush until other pieces are ready.
Regards,
Tony
^ permalink raw reply
* [PATCH] ARM: dts: Add missing CPU frequencies for Exynos5422/5800
From: Bartlomiej Zolnierkiewicz @ 2016-12-14 16:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ee4321d6-dcc9-4de7-c376-6b169d160322@osg.samsung.com>
Hi,
On Wednesday, December 14, 2016 11:40:08 AM Javier Martinez Canillas wrote:
> Hello Bartlomiej,
>
> On 12/14/2016 11:25 AM, Bartlomiej Zolnierkiewicz wrote:
> >
> > Hi,
> >
> > On Wednesday, December 14, 2016 11:06:45 AM Javier Martinez Canillas wrote:
> >>
> >> Hello Bartlomiej,
> >>
> >> On 12/14/2016 10:28 AM, Bartlomiej Zolnierkiewicz wrote:
> >>>
> >>> On Tuesday, December 13, 2016 04:18:05 PM Javier Martinez Canillas wrote:
> >>>> Hello Bartlomiej,
> >>>
> >>> Hi,
> >>>
> >>>> On 12/13/2016 01:52 PM, Bartlomiej Zolnierkiewicz wrote:
> >>>>> Add missing 2000MHz & 1900MHz OPPs (for A15 cores) and 1400MHz OPP
> >>>>> (for A7 cores). Also update common Odroid-XU3 Lite/XU3/XU4 thermal
> >>>>> cooling maps to account for new OPPs.
> >>>>>
> >>>>> Since new OPPs are not available on all Exynos5422/5800 boards modify
> >>>>> dts files for Odroid-XU3 Lite (limited to 1.8 GHz / 1.3 GHz) & Peach
> >>>>> Pi (limited to 2.0 GHz / 1.3 GHz) accordingly.
> >>>>>
> >>>>> Tested on Odroid-XU3 and XU3 Lite.
> >>>>>
> >>>>> Cc: Doug Anderson <dianders@chromium.org>
> >>>>> Cc: Javier Martinez Canillas <javier@osg.samsung.com>
> >>>>> Cc: Andreas Faerber <afaerber@suse.de>
> >>>>> Cc: Thomas Abraham <thomas.ab@samsung.com>
> >>>>> Cc: Ben Gamari <ben@smart-cactus.org>
> >>>>> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> >>>>> ---
> >>>>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 14 +++++++-------
> >>>>> arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts | 17 +++++++++++++++++
> >>>>> arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 ++++
> >>>>> arch/arm/boot/dts/exynos5800.dtsi | 15 +++++++++++++++
> >>>>> 4 files changed, 43 insertions(+), 7 deletions(-)
> >>>>>
> >>>>> Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> >>>>> ===================================================================
> >>>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.779763261 +0100
> >>>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.775763261 +0100
> >>>>> @@ -118,7 +118,7 @@
> >>>>> /*
> >>>>> * When reaching cpu_alert3, reduce CPU
> >>>>> * by 2 steps. On Exynos5422/5800 that would
> >>>>> - * be: 1600 MHz and 1100 MHz.
> >>>>> + * (usually) be: 1800 MHz and 1200 MHz.
> >>>>> */
> >>>>> map3 {
> >>>>> trip = <&cpu_alert3>;
> >>>>> @@ -131,16 +131,16 @@
> >>>>>
> >>>>> /*
> >>>>> * When reaching cpu_alert4, reduce CPU
> >>>>> - * further, down to 600 MHz (11 steps for big,
> >>>>> - * 7 steps for LITTLE).
> >>>>> + * further, down to 600 MHz (13 steps for big,
> >>>>> + * 8 steps for LITTLE).
> >>>>> */
> >>>>> - map5 {
> >>>>> + cooling_map5: map5 {
> >>>>> trip = <&cpu_alert4>;
> >>>>> - cooling-device = <&cpu0 3 7>;
> >>>>> + cooling-device = <&cpu0 3 8>;
> >>>>> };
> >>>>> - map6 {
> >>>>> + cooling_map6: map6 {
> >>>>> trip = <&cpu_alert4>;
> >>>>> - cooling-device = <&cpu4 3 11>;
> >>>>> + cooling-device = <&cpu4 3 13>;
> >>>>> };
> >>>>> };
> >>>>> };
> >>>>> Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
> >>>>> ===================================================================
> >>>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.779763261 +0100
> >>>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.775763261 +0100
> >>>>> @@ -21,6 +21,23 @@
> >>>>> compatible = "hardkernel,odroid-xu3-lite", "samsung,exynos5800", "samsung,exynos5";
> >>>>> };
> >>>>>
> >>>>> +&cluster_a15_opp_table {
> >>>>> + /delete-node/opp at 2000000000;
> >>>>> + /delete-node/opp at 1900000000;
> >>>>> +};
> >>>>> +
> >>>>> +&cluster_a7_opp_table {
> >>>>> + /delete-node/opp at 1400000000;
> >>>>> +};
> >>>>> +
> >>>>
> >>>> I think that a comment in the DTS why these operating points aren't available
> >>>> in this board will make more clear why the nodes are being deleted.
> >>>
> >>> Ok, I will add these comments in the next patch revision.
> >>>
> >>>>> +&cooling_map5 {
> >>>>> + cooling-device = <&cpu0 3 7>;
> >>>>> +};
> >>>>> +
> >>>>> +&cooling_map6 {
> >>>>> + cooling-device = <&cpu4 3 11>;
> >>>>> +};
> >>>>> +
> >>>>> &pwm {
> >>>>> /*
> >>>>> * PWM 0 -- fan
> >>>>> Index: b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> >>>>> ===================================================================
> >>>>> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
> >>>>> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
> >>>>> @@ -146,6 +146,10 @@
> >>>>> vdd-supply = <&ldo9_reg>;
> >>>>> };
> >>>>>
> >>>>> +&cluster_a7_opp_table {
> >>>>> + /delete-property/opp at 1400000000;
> >>>>> +};
> >>>>> +
> >>>>> &cpu0 {
> >>>>> cpu-supply = <&buck2_reg>;
> >>>>> };
> >>>>> Index: b/arch/arm/boot/dts/exynos5800.dtsi
> >>>>> ===================================================================
> >>>>> --- a/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
> >>>>> +++ b/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
> >>>>> @@ -24,6 +24,16 @@
> >>>>> };
> >>>>>
> >>>>> &cluster_a15_opp_table {
> >>>>> + opp at 2000000000 {
> >>>>> + opp-hz = /bits/ 64 <2000000000>;
> >>>>> + opp-microvolt = <1250000>;
> >>>>> + clock-latency-ns = <140000>;
> >>>>> + };
> >>>>> + opp at 1900000000 {
> >>>>> + opp-hz = /bits/ 64 <1900000000>;
> >>>>> + opp-microvolt = <1250000>;
> >>>>> + clock-latency-ns = <140000>;
> >>>>> + };
> >>>>> opp at 1700000000 {
> >>>>> opp-microvolt = <1250000>;
> >>>>> };
> >>>>> @@ -85,6 +95,11 @@
> >>>>> };
> >>>>>
> >>>>
> >>>> AFAIK Thomas restricted the maximum OPP, because for A15 freqs > 1.8GHz the
> >>>> INT rail would need to be scaled up as well since there's a maximum voltage
> >>>> difference between the ARM and INT rails before the system becomes unstable:
> >>>>
> >>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/276766.html
> >>>> https://lkml.org/lkml/2014/5/2/419
> >>>>
> >>>> The ChromiumOS vendor tree uses a virtual regulator driver that makes sure
> >>>> the maximum voltage skew is between a limit. But that never made to mainline:
> >>>>
> >>>> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/arch/arm/boot/dts/exynos5420-peach-pit.dtsi#90
> >>>> https://lkml.org/lkml/2014/4/29/28
> >>>>
> >>>> Did that change and there's infrastructure in mainline now to cope with that?
> >>>> If that's the case, I think it would be good to mention in the commit message.
> >>>
> >>> I was not aware of this limitation and AFAIK mainline has currently
> >>> no code to handle it. I also cannot find any code to handle this in
> >>
> >> Yes, that's what I thought as well but maybe I was missing something.
> >>
> >>> Hardkernel's vendor kernel for Odroid-XU3 board.
> >>>
> >>> Do you know whether this problem exists also on Exynos5422/5800
> >>> SoCs or only on Exynos5420 one? I see that ChromiumOS uses virtual
> >>> regulator code also on Exynos5800 SoC based Peach Pi board but was
> >>> the problem actually present on this board?
> >>>
> >>
> >> My understanding is that this problem is present in 5420/5422/5800
> >> but I have no way to confirm this. I'm just guessing from the info
> >> in the ChromiumOS vendor tree.
> >>
> >> If you look at the commit that added the regulator-locker driver,
> >> the test says to be done in a Peach Pi so it seems the problem is
> >> not restricted to only Exynos5420:
> >>
> >> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/ba63620feace4eaed5572ac2e77d8d61754af704
> >>
> >>> [ I added Arjun to Cc:, maybe he can help in explaining this issue
> >>> (unfortunately Inderpal's email is no longer working). ]
> >>>
> >>
> >> Added Abhilash to cc list as well since he was involved in the Exynos ChromeOS tree.
> >
> > Abhilash's email is also no longer valid.. :(
> >
>
> Yes, I noticed that as well :(
>
> >>> Please also note that on Exynos5422/5800 SoCs the same ARM rail
> >>> voltage is used for 1.9 GHz & 2.0 GHz OPPs as for the 1.8 GHz one.
> >>> IOW if the problem exists it is already present in the mainline
> >>> kernel.
> >>>
> >>
> >> Ah, I only looked at your patch and I didn't compare the voltage levels
> >> in your 1.9 GHz and 2.0 GHz OPPs with the current 1.8 GHz in mainline.
> >>
> >> I wonder if the voltage levels in your patch are correct then, since the
> >> ChromiumOS tree uses a higher voltages for the 1.9 GHz and 2.0 GHz OPPs:
> >>
> >> /*
> >> * Default ASV table
> >> */
> >> static const unsigned int asv_voltage_5420[CPUFREQ_NUM_LEVELS] = {
> >> 1362500, /* L0 2100 */
> >> 1312500, /* L1 2000 */
> >> 1275000, /* L2 1900 */
> >> 1225000, /* L3 1800 */
> >> 1200000, /* L4 1700 */
> >>
> >> This is from https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/drivers/cpufreq/exynos5420-cpufreq.c#175
> >
> > I think that the above voltages are original ones for Exynos5420
> > (not for Exynos5422/5800).
> >
>
> In the ChromiumOS tree, the same CPUFreq driver is used for both the Peach
> Pit (Exynos5420) and Peach Pi (Exynos5800) Chromebooks.
This seems suboptimal (or maybe even incorrect as Exynos5422/5800
SoCs also use different clock divider values for clocks related to
CPU clock than Exynos5420 SoC).
Anyway, I can drop Peach Pi support from my patch for now if you want.
> > The voltages in my patch were taken from Hardkernel's kernel for
> > Odroid-XU3:
> >
> > /*
> > * ASV group voltage table
> > */
> > static const unsigned int asv_voltage_5422_CA15[CPUFREQ_LEVEL_END_CA15] = {
> > ...
> > 1250000, /* L4 2000 */
> > 1250000, /* L5 1900 */
> > 1250000, /* L6 1800 */
> > ...
> >
> > https://github.com/hardkernel/linux/blob/odroidxu3-3.10.y-android/drivers/cpufreq/exynos5422-eagle-cpufreq.c#L314
> >
>
> In general I prefer to use the ChromiumOS tree as a reference instead of the
> HardKernel one, since the former is in a much better shape IMHO.
I generally agree, OTOH Hardkernel's tree is based on Samsung's
vendor trees and additionally it contains all low-level hardware
details for Odroid-XU3 board (not present in ChromiumOS tree).
> I think is worth to check in a kernel tree in http://opensource.samsung.com/
> for a product that's Exynos5422/5800 based.
I've just checked kernel from SM-G900H_LL_Opensource.zip (for Galaxy
S5 which is Exynos5422 based) and it uses 50mV lower voltages for
1.6 GHz - 2.0 GHz OPPs, for the lower frequencies OPPs voltages are
identical to the ones used by HardKernel's tree,
drivers/cpufreq/exynos5422-eagle-cpufreq.c:
/*
* ASV group voltage table
*/
static const unsigned int asv_voltage_5422_CA15[CPUFREQ_LEVEL_END_CA15] = {
...
1200000, /* L4 2000 */
1200000, /* L5 1900 */
1200000, /* L6 1800 */
1200000, /* L7 1700 */
1200000, /* L8 1600 */
1100000, /* L9 1500 */
1100000, /* L10 1400 */
1100000, /* L11 1300 */
1000000, /* L12 1200 */
1000000, /* L13 1100 */
1000000, /* L14 1000 */
1000000, /* L15 900 */
900000, /* L16 800 */
900000, /* L17 700 */
900000, /* L18 600 */
900000, /* L19 500 */
900000, /* L20 400 */
900000, /* L22 300 */
900000, /* L22 200 */
};
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply
* [PATCH v2 04/11] Documentation: DT: binding: axp20x_usb_power: add axp223 compatible
From: Chen-Yu Tsai @ 2016-12-14 16:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161209110419.28981-5-quentin.schulz@free-electrons.com>
On Fri, Dec 9, 2016 at 7:04 PM, Quentin Schulz
<quentin.schulz@free-electrons.com> wrote:
> This adds the "x-powers,axp223-usb-power-supply" to the list of
> compatibles for AXP20X VBUS power supply driver.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
> ---
>
> v2:
> - adding small explanation on AXP223 variation compared to the AXP221,
>
> Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt b/Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt
> index f1d7bee..ba8d35f 100644
> --- a/Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt
> +++ b/Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt
> @@ -3,6 +3,11 @@ AXP20x USB power supply
> Required Properties:
> -compatible: One of: "x-powers,axp202-usb-power-supply"
> "x-powers,axp221-usb-power-supply"
> + "x-powers,axp223-usb-power-supply"
> +
> +The AXP223 PMIC shares most of its behaviour with the AXP221 but has slight
> +variations such as the former being able to set the VBUS power supply max
> +current to 100mA, unlike the latter.
I actually wanted this in the commit log, but this works too.
Acked-by: Chen-Yu Tsai <wens@csie.org>
>
> This node is a subnode of the axp20x PMIC.
>
> --
> 2.9.3
>
^ permalink raw reply
* [PATCH 1/1] arm64: Correcting format specifier for printing 64 bit addresses
From: Paolo Bonzini @ 2016-12-14 16:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206161116.GD4816@cbox>
On 06/12/2016 17:11, Christoffer Dall wrote:
> + kvm_err("Unsupported guest CP%d access at: %08lx\n",
> + cp, *vcpu_pc(vcpu));
> + else
> + kvm_err("Unsupported guest CP%d access at: %016lx\n",
> + cp, *vcpu_pc(vcpu));
>
> It feels a bit much to me to have an if-statement to differentiate the
> number of leading zeros, so if it's important to always have fixed
> widths then I would just use %016lx in both cases.
Really, this is just a debugging message. Just use "0x%lx" and let's
stop bikeshedding. :)
Paolo
^ permalink raw reply
* [PATCH 2/2] FPGA: Add TS-7300 FPGA manager
From: Hartley Sweeten @ 2016-12-14 16:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.10.1612120951520.3310@atull-730U3E-740U3E>
On Monday, December 12, 2016 9:02 AM, Alan Tull wrote:
> On Sun, 11 Dec 2016, Florian Fainelli wrote:
>> Add support for loading bitstreams on the Altera Cyclone II FPGA
>> populated on the TS-7300 board. This is done through the configuration
>> and data registers offered through a memory interface between the EP93xx
>> SoC and the FPGA.
>>
>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>
> Hi Florain,
>
> Thanks for submitting!
>
> How specific is this to the tx7300 board?
>
> I'm unclear about the programming method here. Are these registers
> exposed by the EP93xx? Is it possible that another cpu could access
> these two registers to configure the cyclone ii? Is this passive
> serial?
Alan,
>From the schematic, it appears that the Cyclone II FPGA is configured for
Fast AS programming. The glue chip (MAXII CLPD) on the board appears to
implement some kind of state machine to handle the FPGA programming
using two registers in the glue chip.
Hartley
^ permalink raw reply
* [PATCH v3 1/2] ARM: ep93xx: Register ts73xx-fpga manager driver for TS-7300
From: Hartley Sweeten @ 2016-12-14 16:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161214023553.9377-2-f.fainelli@gmail.com>
On Tuesday, December 13, 2016 7:36 PM, Florian Fainelli wrote:
>
> Register the TS-7300 FPGA manager device drivers which allows us to load
> bitstreams into the on-board Altera Cyclone II FPGA.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> arch/arm/mach-ep93xx/ts72xx.c | 26 ++++++++++++++++++++++++++
> 1 file changed, 26 insertions(+)
For the ep93xx core change:
Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com>
^ permalink raw reply
* [PATCH linux v1 0/4] Seven segment display support
From: Greg KH @ 2016-12-14 16:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ac324946-41da-c090-a0ca-78155611bb7e@baylibre.com>
On Wed, Dec 14, 2016 at 02:12:41PM +0100, Neil Armstrong wrote:
> On 12/14/2016 01:56 PM, Greg KH wrote:
> > On Wed, Dec 14, 2016 at 01:45:30PM +0100, Thomas Petazzoni wrote:
> >> Hello,
> >>
> >> On Tue, 13 Dec 2016 23:55:00 -0800, Jaghathiswari Rankappagounder
> >> Natarajan wrote:
> >>
> >>> Documentation for the binding which provides an interface for adding clock,
> >>> data and clear signal GPIO lines to control seven segment display.
> >>>
> >>> The platform device driver provides an API for displaying on two 7-segment
> >>> displays, and implements the required bit-banging. The hardware assumed is
> >>> 74HC164 wired to two 7-segment displays.
> >>>
> >>> The character device driver implements the user-space API for letting a user
> >>> write to two 7-segment displays including any conversion methods necessary
> >>> to map the user input to two 7-segment displays.
> >>>
> >>> Adding clock, data and clear signal GPIO lines in the devicetree to control
> >>> seven segment display on zaius platform.
> >>>
> >>> The platform driver matches on the device tree node; the platform driver also
> >>> initializes the character device.
> >>>
> >>> Tested that the seven segment display works properly by writing to the
> >>> character device file on a EVB AST2500 board which also has 74HC164 wired
> >>> to two 7-segment displays.
> >>
> >> FWIW, I proposed a driver for seven segment displays back in 2013:
> >>
> >> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-January/139986.html
> >>
> >> And the feedback from Greg KH was: we don't need a driver for that, do
> >> it from userspace. See:
> >>
> >> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-January/139992.html
> >>
> >> So: good luck :-)
> >
> > Did anyone ever write a library for this type of thing?
> >
> > Again, I don't want to see one-off drivers for random devices like this
> > that should be able to all be controlled from userspace in a common
> > manner. Much like we did for fingerprint readers a long long time
> > ago...
> >
> > thanks,
> >
> > greg k-h
>
> Hi Greg,
>
> Actually, it's more than a random interface, a lot of SoCs and boards actually have such displays
> and it's a pity to use UIO, sysfs gpio bitbanging and all sort of ugly stuff to only print a few
> characters a simple and clean driver could achieve.
Great, then let's make an API that all devices of this type could use,
and not just take individual drivers that all have a custom char or
sysfs interface which requires custom userspace code to be able to drive
all of the different devices in a common way (i.e. a library would have
to be written anyways...)
thanks,
greg k-h
^ permalink raw reply
* Linux crashes when trying to online secondary core
From: Thomas Gleixner @ 2016-12-14 17:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ef972981-3fb6-74a4-cd83-a6629d2dab2a@free.fr>
On Wed, 14 Dec 2016, Mason wrote:
> Hello,
>
> I'm seeing Linux v4.9 crash (dereferencing NULL) when I try to online
> the secondary core, after putting it offline.
Does the patch below fix the issue?
Thanks,
tglx
8<---------------
diff --git a/include/linux/cpuhotplug.h b/include/linux/cpuhotplug.h
index 22acee76cf4c..2594c287b078 100644
--- a/include/linux/cpuhotplug.h
+++ b/include/linux/cpuhotplug.h
@@ -101,7 +101,6 @@ enum cpuhp_state {
CPUHP_AP_ARM_L2X0_STARTING,
CPUHP_AP_ARM_ARCH_TIMER_STARTING,
CPUHP_AP_ARM_GLOBAL_TIMER_STARTING,
- CPUHP_AP_DUMMY_TIMER_STARTING,
CPUHP_AP_JCORE_TIMER_STARTING,
CPUHP_AP_EXYNOS4_MCT_TIMER_STARTING,
CPUHP_AP_ARM_TWD_STARTING,
@@ -111,6 +110,7 @@ enum cpuhp_state {
CPUHP_AP_MARCO_TIMER_STARTING,
CPUHP_AP_MIPS_GIC_TIMER_STARTING,
CPUHP_AP_ARC_TIMER_STARTING,
+ CPUHP_AP_DUMMY_TIMER_STARTING,
CPUHP_AP_KVM_STARTING,
CPUHP_AP_KVM_ARM_VGIC_INIT_STARTING,
CPUHP_AP_KVM_ARM_VGIC_STARTING,
^ permalink raw reply related
* [PATCH 0/2] xilinx_dma: Add external reset control
From: Ramiro Oliveira @ 2016-12-14 17:18 UTC (permalink / raw)
To: linux-arm-kernel
This patchset adds support for controlling an external reset line. Since
this reset line is optional it won't break compatibility.
Ramiro Oliveira (2):
xilinx_dma: Edit device tree bindings documentation
xilinx_dma: Add reset support
.../devicetree/bindings/dma/xilinx/xilinx_dma.txt | 6 ++++++
drivers/dma/xilinx/xilinx_dma.c | 23 ++++++++++++++++++++++
2 files changed, 29 insertions(+)
--
2.10.2
^ permalink raw reply
* [PATCH 1/2] xilinx_dma: Edit device tree bindings documentation
From: Ramiro Oliveira @ 2016-12-14 17:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1481735244.git.roliveir@synopsys.com>
Add reset property documentation for Xilinx DMA
Signed-off-by: Ramiro Oliveira <roliveir@synopsys.com>
---
Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
index a2b8bfa..7ebce72 100644
--- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
+++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
@@ -40,6 +40,10 @@ Required properties for VDMA:
Optional properties:
- xlnx,include-sg: Tells configured for Scatter-mode in
the hardware.
+- resets : Must contain an entry for each entry in reset-names.
+ See ../reset/reset.txt for details.
+- reset-names : Must include the following entries:
+ - reset
Optional properties for AXI DMA:
- xlnx,mcdma: Tells whether configured for multi-channel mode in the hardware.
Optional properties for VDMA:
@@ -83,6 +87,8 @@ axi_vdma_0: axivdma at 40030000 {
clocks = <&clk 0>, <&clk 1>, <&clk 2>, <&clk 3>, <&clk 4>;
clock-names = "s_axi_lite_aclk", "m_axi_mm2s_aclk", "m_axi_s2mm_aclk",
"m_axis_mm2s_aclk", "s_axis_s2mm_aclk";
+ resets = <&rst 2>;
+ reset-names = "reset";
dma-channel at 40030000 {
compatible = "xlnx,axi-vdma-mm2s-channel";
interrupts = < 0 54 4 >;
--
2.10.2
^ permalink raw reply related
* [PATCH 2/2] xilinx_dma: Add reset support
From: Ramiro Oliveira @ 2016-12-14 17:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1481735244.git.roliveir@synopsys.com>
Add a DT property to control an optional external reset line
Signed-off-by: Ramiro Oliveira <roliveir@synopsys.com>
---
drivers/dma/xilinx/xilinx_dma.c | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
index 5c9f11b..b845224 100644
--- a/drivers/dma/xilinx/xilinx_dma.c
+++ b/drivers/dma/xilinx/xilinx_dma.c
@@ -46,6 +46,7 @@
#include <linux/slab.h>
#include <linux/clk.h>
#include <linux/io-64-nonatomic-lo-hi.h>
+#include <linux/reset.h>
#include "../dmaengine.h"
@@ -409,6 +410,7 @@ struct xilinx_dma_device {
struct clk *rxs_clk;
u32 nr_channels;
u32 chan_id;
+ struct reset_control *rst;
};
/* Macros */
@@ -2543,6 +2545,27 @@ static int xilinx_dma_probe(struct platform_device *pdev)
if (IS_ERR(xdev->regs))
return PTR_ERR(xdev->regs);
+ xdev->rst = devm_reset_control_get_optional(&pdev->dev, "reset");
+ if (IS_ERR(xdev->rst)) {
+ err = PTR_ERR(xdev->rst);
+ switch (err) {
+ case -ENOENT:
+ case -ENOTSUPP:
+ xdev->rst = NULL;
+ break;
+ default:
+ dev_err(xdev->dev, "error getting reset %d\n", err);
+ return err;
+ }
+ } else {
+ err = reset_control_deassert(xdev->rst);
+ if (err) {
+ dev_err(xdev->dev, "failed to deassert reset: %d\n",
+ err);
+ return err;
+ }
+ }
+
/* Retrieve the DMA engine properties from the device tree */
xdev->has_sg = of_property_read_bool(node, "xlnx,include-sg");
if (xdev->dma_config->dmatype == XDMA_TYPE_AXIDMA)
--
2.10.2
^ permalink raw reply related
* [PATCH] ARM: dts: Add missing CPU frequencies for Exynos5422/5800
From: Javier Martinez Canillas @ 2016-12-14 17:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4861151.PfdUkXTZox@amdc3058>
Hello Bartlomiej,
On 12/14/2016 01:10 PM, Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> On Wednesday, December 14, 2016 11:40:08 AM Javier Martinez Canillas wrote:
>> Hello Bartlomiej,
>>
>> On 12/14/2016 11:25 AM, Bartlomiej Zolnierkiewicz wrote:
>>>
>>> Hi,
>>>
>>> On Wednesday, December 14, 2016 11:06:45 AM Javier Martinez Canillas wrote:
>>>>
>>>> Hello Bartlomiej,
>>>>
>>>> On 12/14/2016 10:28 AM, Bartlomiej Zolnierkiewicz wrote:
>>>>>
>>>>> On Tuesday, December 13, 2016 04:18:05 PM Javier Martinez Canillas wrote:
>>>>>> Hello Bartlomiej,
>>>>>
>>>>> Hi,
>>>>>
>>>>>> On 12/13/2016 01:52 PM, Bartlomiej Zolnierkiewicz wrote:
>>>>>>> Add missing 2000MHz & 1900MHz OPPs (for A15 cores) and 1400MHz OPP
>>>>>>> (for A7 cores). Also update common Odroid-XU3 Lite/XU3/XU4 thermal
>>>>>>> cooling maps to account for new OPPs.
>>>>>>>
>>>>>>> Since new OPPs are not available on all Exynos5422/5800 boards modify
>>>>>>> dts files for Odroid-XU3 Lite (limited to 1.8 GHz / 1.3 GHz) & Peach
>>>>>>> Pi (limited to 2.0 GHz / 1.3 GHz) accordingly.
>>>>>>>
>>>>>>> Tested on Odroid-XU3 and XU3 Lite.
>>>>>>>
>>>>>>> Cc: Doug Anderson <dianders@chromium.org>
>>>>>>> Cc: Javier Martinez Canillas <javier@osg.samsung.com>
>>>>>>> Cc: Andreas Faerber <afaerber@suse.de>
>>>>>>> Cc: Thomas Abraham <thomas.ab@samsung.com>
>>>>>>> Cc: Ben Gamari <ben@smart-cactus.org>
>>>>>>> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
>>>>>>> ---
>>>>>>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 14 +++++++-------
>>>>>>> arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts | 17 +++++++++++++++++
>>>>>>> arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 ++++
>>>>>>> arch/arm/boot/dts/exynos5800.dtsi | 15 +++++++++++++++
>>>>>>> 4 files changed, 43 insertions(+), 7 deletions(-)
>>>>>>>
>>>>>>> Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>>>>>> ===================================================================
>>>>>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.779763261 +0100
>>>>>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.775763261 +0100
>>>>>>> @@ -118,7 +118,7 @@
>>>>>>> /*
>>>>>>> * When reaching cpu_alert3, reduce CPU
>>>>>>> * by 2 steps. On Exynos5422/5800 that would
>>>>>>> - * be: 1600 MHz and 1100 MHz.
>>>>>>> + * (usually) be: 1800 MHz and 1200 MHz.
>>>>>>> */
>>>>>>> map3 {
>>>>>>> trip = <&cpu_alert3>;
>>>>>>> @@ -131,16 +131,16 @@
>>>>>>>
>>>>>>> /*
>>>>>>> * When reaching cpu_alert4, reduce CPU
>>>>>>> - * further, down to 600 MHz (11 steps for big,
>>>>>>> - * 7 steps for LITTLE).
>>>>>>> + * further, down to 600 MHz (13 steps for big,
>>>>>>> + * 8 steps for LITTLE).
>>>>>>> */
>>>>>>> - map5 {
>>>>>>> + cooling_map5: map5 {
>>>>>>> trip = <&cpu_alert4>;
>>>>>>> - cooling-device = <&cpu0 3 7>;
>>>>>>> + cooling-device = <&cpu0 3 8>;
>>>>>>> };
>>>>>>> - map6 {
>>>>>>> + cooling_map6: map6 {
>>>>>>> trip = <&cpu_alert4>;
>>>>>>> - cooling-device = <&cpu4 3 11>;
>>>>>>> + cooling-device = <&cpu4 3 13>;
>>>>>>> };
>>>>>>> };
>>>>>>> };
>>>>>>> Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
>>>>>>> ===================================================================
>>>>>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.779763261 +0100
>>>>>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.775763261 +0100
>>>>>>> @@ -21,6 +21,23 @@
>>>>>>> compatible = "hardkernel,odroid-xu3-lite", "samsung,exynos5800", "samsung,exynos5";
>>>>>>> };
>>>>>>>
>>>>>>> +&cluster_a15_opp_table {
>>>>>>> + /delete-node/opp at 2000000000;
>>>>>>> + /delete-node/opp at 1900000000;
>>>>>>> +};
>>>>>>> +
>>>>>>> +&cluster_a7_opp_table {
>>>>>>> + /delete-node/opp at 1400000000;
>>>>>>> +};
>>>>>>> +
>>>>>>
>>>>>> I think that a comment in the DTS why these operating points aren't available
>>>>>> in this board will make more clear why the nodes are being deleted.
>>>>>
>>>>> Ok, I will add these comments in the next patch revision.
>>>>>
>>>>>>> +&cooling_map5 {
>>>>>>> + cooling-device = <&cpu0 3 7>;
>>>>>>> +};
>>>>>>> +
>>>>>>> +&cooling_map6 {
>>>>>>> + cooling-device = <&cpu4 3 11>;
>>>>>>> +};
>>>>>>> +
>>>>>>> &pwm {
>>>>>>> /*
>>>>>>> * PWM 0 -- fan
>>>>>>> Index: b/arch/arm/boot/dts/exynos5800-peach-pi.dts
>>>>>>> ===================================================================
>>>>>>> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
>>>>>>> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
>>>>>>> @@ -146,6 +146,10 @@
>>>>>>> vdd-supply = <&ldo9_reg>;
>>>>>>> };
>>>>>>>
>>>>>>> +&cluster_a7_opp_table {
>>>>>>> + /delete-property/opp at 1400000000;
>>>>>>> +};
>>>>>>> +
>>>>>>> &cpu0 {
>>>>>>> cpu-supply = <&buck2_reg>;
>>>>>>> };
>>>>>>> Index: b/arch/arm/boot/dts/exynos5800.dtsi
>>>>>>> ===================================================================
>>>>>>> --- a/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
>>>>>>> +++ b/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
>>>>>>> @@ -24,6 +24,16 @@
>>>>>>> };
>>>>>>>
>>>>>>> &cluster_a15_opp_table {
>>>>>>> + opp at 2000000000 {
>>>>>>> + opp-hz = /bits/ 64 <2000000000>;
>>>>>>> + opp-microvolt = <1250000>;
>>>>>>> + clock-latency-ns = <140000>;
>>>>>>> + };
>>>>>>> + opp at 1900000000 {
>>>>>>> + opp-hz = /bits/ 64 <1900000000>;
>>>>>>> + opp-microvolt = <1250000>;
>>>>>>> + clock-latency-ns = <140000>;
>>>>>>> + };
>>>>>>> opp at 1700000000 {
>>>>>>> opp-microvolt = <1250000>;
>>>>>>> };
>>>>>>> @@ -85,6 +95,11 @@
>>>>>>> };
>>>>>>>
>>>>>>
>>>>>> AFAIK Thomas restricted the maximum OPP, because for A15 freqs > 1.8GHz the
>>>>>> INT rail would need to be scaled up as well since there's a maximum voltage
>>>>>> difference between the ARM and INT rails before the system becomes unstable:
>>>>>>
>>>>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/276766.html
>>>>>> https://lkml.org/lkml/2014/5/2/419
>>>>>>
>>>>>> The ChromiumOS vendor tree uses a virtual regulator driver that makes sure
>>>>>> the maximum voltage skew is between a limit. But that never made to mainline:
>>>>>>
>>>>>> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/arch/arm/boot/dts/exynos5420-peach-pit.dtsi#90
>>>>>> https://lkml.org/lkml/2014/4/29/28
>>>>>>
>>>>>> Did that change and there's infrastructure in mainline now to cope with that?
>>>>>> If that's the case, I think it would be good to mention in the commit message.
>>>>>
>>>>> I was not aware of this limitation and AFAIK mainline has currently
>>>>> no code to handle it. I also cannot find any code to handle this in
>>>>
>>>> Yes, that's what I thought as well but maybe I was missing something.
>>>>
>>>>> Hardkernel's vendor kernel for Odroid-XU3 board.
>>>>>
>>>>> Do you know whether this problem exists also on Exynos5422/5800
>>>>> SoCs or only on Exynos5420 one? I see that ChromiumOS uses virtual
>>>>> regulator code also on Exynos5800 SoC based Peach Pi board but was
>>>>> the problem actually present on this board?
>>>>>
>>>>
>>>> My understanding is that this problem is present in 5420/5422/5800
>>>> but I have no way to confirm this. I'm just guessing from the info
>>>> in the ChromiumOS vendor tree.
>>>>
>>>> If you look at the commit that added the regulator-locker driver,
>>>> the test says to be done in a Peach Pi so it seems the problem is
>>>> not restricted to only Exynos5420:
>>>>
>>>> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/ba63620feace4eaed5572ac2e77d8d61754af704
>>>>
>>>>> [ I added Arjun to Cc:, maybe he can help in explaining this issue
>>>>> (unfortunately Inderpal's email is no longer working). ]
>>>>>
>>>>
>>>> Added Abhilash to cc list as well since he was involved in the Exynos ChromeOS tree.
>>>
>>> Abhilash's email is also no longer valid.. :(
>>>
>>
>> Yes, I noticed that as well :(
>>
>>>>> Please also note that on Exynos5422/5800 SoCs the same ARM rail
>>>>> voltage is used for 1.9 GHz & 2.0 GHz OPPs as for the 1.8 GHz one.
>>>>> IOW if the problem exists it is already present in the mainline
>>>>> kernel.
>>>>>
>>>>
>>>> Ah, I only looked at your patch and I didn't compare the voltage levels
>>>> in your 1.9 GHz and 2.0 GHz OPPs with the current 1.8 GHz in mainline.
>>>>
>>>> I wonder if the voltage levels in your patch are correct then, since the
>>>> ChromiumOS tree uses a higher voltages for the 1.9 GHz and 2.0 GHz OPPs:
>>>>
>>>> /*
>>>> * Default ASV table
>>>> */
>>>> static const unsigned int asv_voltage_5420[CPUFREQ_NUM_LEVELS] = {
>>>> 1362500, /* L0 2100 */
>>>> 1312500, /* L1 2000 */
>>>> 1275000, /* L2 1900 */
>>>> 1225000, /* L3 1800 */
>>>> 1200000, /* L4 1700 */
>>>>
>>>> This is from https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/drivers/cpufreq/exynos5420-cpufreq.c#175
>>>
>>> I think that the above voltages are original ones for Exynos5420
>>> (not for Exynos5422/5800).
>>>
>>
>> In the ChromiumOS tree, the same CPUFreq driver is used for both the Peach
>> Pit (Exynos5420) and Peach Pi (Exynos5800) Chromebooks.
>
> This seems suboptimal (or maybe even incorrect as Exynos5422/5800
> SoCs also use different clock divider values for clocks related to
> CPU clock than Exynos5420 SoC).
>
Yes, I know. There's lot of if (soc_is_exynos5420()) and if (soc_is_exynos5422())
checks in the driver though so I guess those differences are taken into account.
I haven't reviewed that driver in detail though so maybe something is missing.
> Anyway, I can drop Peach Pi support from my patch for now if you want.
>
I'm not against adding all the missing operating points btw, I'm just trying to
make sure that's safe to do so in mainline.
>>> The voltages in my patch were taken from Hardkernel's kernel for
>>> Odroid-XU3:
>>>
>>> /*
>>> * ASV group voltage table
>>> */
>>> static const unsigned int asv_voltage_5422_CA15[CPUFREQ_LEVEL_END_CA15] = {
>>> ...
>>> 1250000, /* L4 2000 */
>>> 1250000, /* L5 1900 */
>>> 1250000, /* L6 1800 */
>>> ...
>>>
>>> https://github.com/hardkernel/linux/blob/odroidxu3-3.10.y-android/drivers/cpufreq/exynos5422-eagle-cpufreq.c#L314
>>>
>>
>> In general I prefer to use the ChromiumOS tree as a reference instead of the
>> HardKernel one, since the former is in a much better shape IMHO.
>
> I generally agree, OTOH Hardkernel's tree is based on Samsung's
> vendor trees and additionally it contains all low-level hardware
> details for Odroid-XU3 board (not present in ChromiumOS tree).
>
Fair enough.
>> I think is worth to check in a kernel tree in http://opensource.samsung.com/
>> for a product that's Exynos5422/5800 based.
>
> I've just checked kernel from SM-G900H_LL_Opensource.zip (for Galaxy
> S5 which is Exynos5422 based) and it uses 50mV lower voltages for
> 1.6 GHz - 2.0 GHz OPPs, for the lower frequencies OPPs voltages are
> identical to the ones used by HardKernel's tree,
>
Interesting, thanks a lot for checking. So if the voltage levels for 1.9 GHz
and 2.0 GHz are the same than 1.8 GHz, then I agree with you that either is
safe to add these OPPs in mainline or the problem is already present there.
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* [PATCH v2 2/2] mfd: axp20x: Fix AXP806 access errors on cold boot
From: Mark Brown @ 2016-12-14 17:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v66vggNNfFrAiNKKGXY0ayiG1qh5tcRok2NLTRkVHWKFeg@mail.gmail.com>
On Wed, Dec 14, 2016 at 09:52:31PM +0800, Chen-Yu Tsai wrote:
> What this patch does is make sure the registers match, to guarantee
> access, and then reinitialize the regmap cache to get rid of any
> stale data.
So what you're saying is that previous writes may have been ignored?
> > If the chip has been reset then you'd want to reset the cache too. I've
> > no idea if that's needed here or not though, it depends what happens to
> > the global state of the chip when this reconfiguration happens.
> It is not a reset in the general sense. I suppose a better way would
> be to do an explicit write to the register first, then initialize
> the regmap. I'd have to export the write function from the RSB bus
> driver first though.
Surely just doing a write immediately after initializing the regmap
would have the same effect? That'd ensure that the hardware has the
desired value before there are any other writes. But I might be missing
something here.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161214/082576db/attachment.sig>
^ permalink raw reply
* Linux crashes when trying to online secondary core
From: Mason @ 2016-12-14 17:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.20.1612141807410.3556@nanos>
On 14/12/2016 18:08, Thomas Gleixner wrote:
> On Wed, 14 Dec 2016, Mason wrote:
>
>> I'm seeing Linux v4.9 crash (dereferencing NULL) when I try to online
>> the secondary core, after putting it offline.
>
> Does the patch below fix the issue?
>
> Thanks,
>
> tglx
>
> 8<---------------
>
> diff --git a/include/linux/cpuhotplug.h b/include/linux/cpuhotplug.h
> index 22acee76cf4c..2594c287b078 100644
> --- a/include/linux/cpuhotplug.h
> +++ b/include/linux/cpuhotplug.h
> @@ -101,7 +101,6 @@ enum cpuhp_state {
> CPUHP_AP_ARM_L2X0_STARTING,
> CPUHP_AP_ARM_ARCH_TIMER_STARTING,
> CPUHP_AP_ARM_GLOBAL_TIMER_STARTING,
> - CPUHP_AP_DUMMY_TIMER_STARTING,
> CPUHP_AP_JCORE_TIMER_STARTING,
> CPUHP_AP_EXYNOS4_MCT_TIMER_STARTING,
> CPUHP_AP_ARM_TWD_STARTING,
> @@ -111,6 +110,7 @@ enum cpuhp_state {
> CPUHP_AP_MARCO_TIMER_STARTING,
> CPUHP_AP_MIPS_GIC_TIMER_STARTING,
> CPUHP_AP_ARC_TIMER_STARTING,
> + CPUHP_AP_DUMMY_TIMER_STARTING,
> CPUHP_AP_KVM_STARTING,
> CPUHP_AP_KVM_ARM_VGIC_INIT_STARTING,
> CPUHP_AP_KVM_ARM_VGIC_STARTING,
$ patch -p1 < tglx.patch
patching file include/linux/cpuhotplug.h
Hunk #1 succeeded at 80 (offset -21 lines).
Hunk #2 succeeded@89 (offset -21 lines).
It does seem to fix the problem:
# echo 0 > /sys/devices/system/cpu/cpu1/online
SMC called with a0=0x00[000001 a1=0x00000121 a2=0x00000005 a3 =0xc01189b4 0x00000121
[1][flow/suspend3.c:39] CPU 1 die: jumping6 to. post-boot WFE
402826] CPU1: shutdown
SMC called with a0=0x00000001 a1=0x00000122 a2=0x00000000 a3=0x00000000 0x00000122
[0][flow/suspend.c:82] Killing core1
armor+++ armor: core 1 booted, entering wfe...
# echo 1 > /sys/devices/system/cpu/cpu1/online
[ 215.692700] tango_boot_secondary from __cpu_up
SMC called with a0=0x80101500 a1=0x00000105 a2=0x00000000 a3=0x00000000 0x00000105
[ 215.704494] tango_set_aux_boot_addr=0
SMC called with a0=0x00000001 a1=0x00000104 a2=0x00000000 a3=0x00000000 0x00000104
[0][flow/smc_handler.c:127] waking up CPU1
[ 215.719308] tango_start_aux_core=0
I reverted your patch, and the kernel blows up again.
So what's the problem, and how does your patch solve it?
Regards.
^ permalink raw reply
* [PATCH] ARM: dts: Add missing CPU frequencies for Exynos5422/5800
From: Krzysztof Kozlowski @ 2016-12-14 18:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <26ffeee4-ff43-b3d3-3267-5fcbc50e2974@osg.samsung.com>
On Tue, Dec 13, 2016 at 04:18:05PM -0300, Javier Martinez Canillas wrote:
> Hello Bartlomiej,
>
> On 12/13/2016 01:52 PM, Bartlomiej Zolnierkiewicz wrote:
> > Add missing 2000MHz & 1900MHz OPPs (for A15 cores) and 1400MHz OPP
> > (for A7 cores). Also update common Odroid-XU3 Lite/XU3/XU4 thermal
> > cooling maps to account for new OPPs.
> >
> > Since new OPPs are not available on all Exynos5422/5800 boards modify
> > dts files for Odroid-XU3 Lite (limited to 1.8 GHz / 1.3 GHz) & Peach
> > Pi (limited to 2.0 GHz / 1.3 GHz) accordingly.
> >
> > Tested on Odroid-XU3 and XU3 Lite.
> >
> > Cc: Doug Anderson <dianders@chromium.org>
> > Cc: Javier Martinez Canillas <javier@osg.samsung.com>
> > Cc: Andreas Faerber <afaerber@suse.de>
> > Cc: Thomas Abraham <thomas.ab@samsung.com>
> > Cc: Ben Gamari <ben@smart-cactus.org>
> > Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> > ---
> > arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 14 +++++++-------
> > arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts | 17 +++++++++++++++++
> > arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 ++++
> > arch/arm/boot/dts/exynos5800.dtsi | 15 +++++++++++++++
> > 4 files changed, 43 insertions(+), 7 deletions(-)
> >
> > Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> > ===================================================================
> > --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.779763261 +0100
> > +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.775763261 +0100
> > @@ -118,7 +118,7 @@
> > /*
> > * When reaching cpu_alert3, reduce CPU
> > * by 2 steps. On Exynos5422/5800 that would
> > - * be: 1600 MHz and 1100 MHz.
> > + * (usually) be: 1800 MHz and 1200 MHz.
> > */
> > map3 {
> > trip = <&cpu_alert3>;
> > @@ -131,16 +131,16 @@
> >
> > /*
> > * When reaching cpu_alert4, reduce CPU
> > - * further, down to 600 MHz (11 steps for big,
> > - * 7 steps for LITTLE).
> > + * further, down to 600 MHz (13 steps for big,
> > + * 8 steps for LITTLE).
> > */
> > - map5 {
> > + cooling_map5: map5 {
> > trip = <&cpu_alert4>;
> > - cooling-device = <&cpu0 3 7>;
> > + cooling-device = <&cpu0 3 8>;
> > };
> > - map6 {
> > + cooling_map6: map6 {
> > trip = <&cpu_alert4>;
> > - cooling-device = <&cpu4 3 11>;
> > + cooling-device = <&cpu4 3 13>;
> > };
> > };
> > };
> > Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
> > ===================================================================
> > --- a/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.779763261 +0100
> > +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.775763261 +0100
> > @@ -21,6 +21,23 @@
> > compatible = "hardkernel,odroid-xu3-lite", "samsung,exynos5800", "samsung,exynos5";
> > };
> >
> > +&cluster_a15_opp_table {
> > + /delete-node/opp at 2000000000;
> > + /delete-node/opp at 1900000000;
> > +};
> > +
> > +&cluster_a7_opp_table {
> > + /delete-node/opp at 1400000000;
> > +};
> > +
>
> I think that a comment in the DTS why these operating points aren't available
> in this board will make more clear why the nodes are being deleted.
>
> > +&cooling_map5 {
> > + cooling-device = <&cpu0 3 7>;
> > +};
> > +
> > +&cooling_map6 {
> > + cooling-device = <&cpu4 3 11>;
> > +};
> > +
> > &pwm {
> > /*
> > * PWM 0 -- fan
> > Index: b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> > ===================================================================
> > --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
> > +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
> > @@ -146,6 +146,10 @@
> > vdd-supply = <&ldo9_reg>;
> > };
> >
> > +&cluster_a7_opp_table {
> > + /delete-property/opp at 1400000000;
> > +};
> > +
> > &cpu0 {
> > cpu-supply = <&buck2_reg>;
> > };
> > Index: b/arch/arm/boot/dts/exynos5800.dtsi
> > ===================================================================
> > --- a/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
> > +++ b/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
> > @@ -24,6 +24,16 @@
> > };
> >
> > &cluster_a15_opp_table {
> > + opp at 2000000000 {
> > + opp-hz = /bits/ 64 <2000000000>;
> > + opp-microvolt = <1250000>;
> > + clock-latency-ns = <140000>;
> > + };
> > + opp at 1900000000 {
> > + opp-hz = /bits/ 64 <1900000000>;
> > + opp-microvolt = <1250000>;
> > + clock-latency-ns = <140000>;
> > + };
> > opp at 1700000000 {
> > opp-microvolt = <1250000>;
> > };
> > @@ -85,6 +95,11 @@
> > };
> >
>
> AFAIK Thomas restricted the maximum OPP, because for A15 freqs > 1.8GHz the
> INT rail would need to be scaled up as well since there's a maximum voltage
> difference between the ARM and INT rails before the system becomes unstable:
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/276766.html
> https://lkml.org/lkml/2014/5/2/419
The choice of skipping > 1.8 GHz could be also made because of missing
ASV which is important to detect the BIN2 of Exynos5422. The BIN2 is
capped to 1.8/1.3.
Anyway this shouldn't be limiting us now because we have all data
statically coded in DTS - in mainline boards, only Odroid XU3-lite
uses BIN2.
Beside comments from Javier, I would be happy to see high frequencies
Tested-by on Peach Pi/Pit. AFAIR, we did not have these in SRPOL. :)
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v3 1/2] ARM: ep93xx: Register ts73xx-fpga manager driver for TS-7300
From: Florian Fainelli @ 2016-12-14 18:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAtXAHcO4bN2YmrEabiivnBJLXdU56j4rv4A12FL_XKuwc5Dxw@mail.gmail.com>
On 12/13/2016 10:14 PM, Moritz Fischer wrote:
> Hi Florian,
>
> On Tue, Dec 13, 2016 at 6:35 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
>> Register the TS-7300 FPGA manager device drivers which allows us to load
>> bitstreams into the on-board Altera Cyclone II FPGA.
>>
>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>> ---
>> arch/arm/mach-ep93xx/ts72xx.c | 26 ++++++++++++++++++++++++++
>> 1 file changed, 26 insertions(+)
>>
>> diff --git a/arch/arm/mach-ep93xx/ts72xx.c b/arch/arm/mach-ep93xx/ts72xx.c
>> index 3b39ea353d30..acf72ea670ef 100644
>> --- a/arch/arm/mach-ep93xx/ts72xx.c
>> +++ b/arch/arm/mach-ep93xx/ts72xx.c
>> @@ -230,6 +230,28 @@ static struct ep93xx_eth_data __initdata ts72xx_eth_data = {
>> .phy_id = 1,
>> };
>>
>> +#if IS_ENABLED(CONFIG_FPGA_MGR_TS73XX)
>> +
>> +/* Relative to EP93XX_CS1_PHYS_BASE */
>> +#define TS73XX_FPGA_LOADER_BASE 0x03c00000
>> +
>> +static struct resource ts73xx_fpga_resources[] = {
>> + {
>> + .start = EP93XX_CS1_PHYS_BASE + TS73XX_FPGA_LOADER_BASE,
>> + .end = EP93XX_CS1_PHYS_BASE + TS73XX_FPGA_LOADER_BASE + 1,
>> + .flags = IORESOURCE_MEM,
>> + },
>> +};
>> +
>> +static struct platform_device ts73xx_fpga_device = {
>> + .name = "ts73xx-fpga-mgr",
>> + .id = -1,
>> + .resource = ts73xx_fpga_resources,
>> + .num_resources = ARRAY_SIZE(ts73xx_fpga_resources),
>> +};
>> +
>> +#endif
>> +
>> static void __init ts72xx_init_machine(void)
>> {
>> ep93xx_init_devices();
>> @@ -238,6 +260,10 @@ static void __init ts72xx_init_machine(void)
>> platform_device_register(&ts72xx_wdt_device);
>>
>> ep93xx_register_eth(&ts72xx_eth_data, 1);
>> +#if IS_ENABLED(CONFIG_FPGA_MGR_TS73XX)
>> + if (board_is_ts7300())
>> + platform_device_register(&ts73xx_fpga_device);
>> +#endif
>> }
>>
>> MACHINE_START(TS72XX, "Technologic Systems TS-72xx SBC")
>> --
>> 2.9.3
>>
>
> I think this is backwards, shouldn't this be your [PATCH 2/2]?
> Otherwise you're using
> the driver before you added it.
I can definitively re-order the patches, although I don't think this
really makes a difference, a driver without device does nothing, and
vice versa.
--
Florian
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox