* [GIT PULL] arm64: dts: juno: updates for v4.10
From: Sudeep Holla @ 2016-10-28 11:31 UTC (permalink / raw)
To: linux-arm-kernel
Hi ARM SoC Team,
Please pull.
--
Regards,
Sudeep
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git tags/juno-dt-4.10
for you to fetch changes up to c1ab65b24065ab04bdb0bc4e89d88784d38dc644:
arm64: dts: juno: add cpu capacity-dmips-mhz information to R2 boards (2016-10-17 17:43:22 +0100)
----------------------------------------------------------------
ARMv8 Vexpress/Juno DT updates for v4.10
1. Addition of SMMU(MMU-401) device nodes mainly to assist other
developments and testing
2. Addition of CPU dmips/capacity information on all the Juno boards
----------------------------------------------------------------
Juri Lelli (3):
arm64: dts: juno: add cpu capacity-dmips-mhz information to R0 boards
arm64: dts: juno: add cpu capacity-dmips-mhz information to R1 boards
arm64: dts: juno: add cpu capacity-dmips-mhz information to R2 boards
Robin Murphy (1):
arm64: dts: juno: Add SMMUs device nodes
arch/arm64/boot/dts/arm/juno-base.dtsi | 80 ++++++++++++++++++++++++++++++++++
arch/arm64/boot/dts/arm/juno-r1.dts | 6 +++
arch/arm64/boot/dts/arm/juno-r2.dts | 6 +++
arch/arm64/boot/dts/arm/juno.dts | 6 +++
4 files changed, 98 insertions(+)
^ permalink raw reply
* [PATCH 1/1] ARM: dts: imx6ul-14x14-evk: add USB dual-role support
From: Fabio Estevam @ 2016-10-28 11:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1470128903-942-1-git-send-email-peter.chen@nxp.com>
On Tue, Aug 2, 2016 at 6:08 AM, Peter Chen <peter.chen@nxp.com> wrote:
> With commit 851ce932242d ("usb: chipidea: otg: don't wait vbus
> drops below BSV when starts host"), the driver can support
> enabling vbus output without software control, so this board
> (control vbus output through ID pin) can support dual-role now.
>
> Signed-off-by: Peter Chen <peter.chen@nxp.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
^ permalink raw reply
* [PATCH v3 1/2] clk: imx: fix integer overflow in AV PLL round rate
From: Fabio Estevam @ 2016-10-28 11:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161028014127.GD16026@codeaurora.org>
Hi Stephen,
On Thu, Oct 27, 2016 at 11:41 PM, Stephen Boyd <sboyd@codeaurora.org> wrote:
> On 10/12, Emil Lundmark wrote:
>> Since 'parent_rate * mfn' may overflow 32 bits, the result should be
>> stored using 64 bits.
>>
>> The problem was discovered when trying to set the rate of the audio PLL
>> (pll4_post_div) on an i.MX6Q. The desired rate was 196.608 MHz, but
>> the actual rate returned was 192.000570 MHz. The round rate function should
>> have been able to return 196.608 MHz, i.e., the desired rate.
>>
>> Fixes: ba7f4f557eb6 ("clk: imx: correct AV PLL rate formula")
>> Cc: Anson Huang <b20788@freescale.com>
>> Signed-off-by: Emil Lundmark <emil@limesaudio.com>
>> ---
>
> Applied to clk-next
This one fixes a regression caused by ba7f4f557eb6 ("clk: imx: correct
AV PLL rate formula").
So it should go to clk-fixes instead with the stable tag:
Cc: <stable@vger.kernel.org> # 4.8.x
Thanks
^ permalink raw reply
* [PATCHv4 4/4] arm64: dump: Add checking for writable and exectuable pages
From: Ard Biesheuvel @ 2016-10-28 11:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477585654-8908-5-git-send-email-labbott@redhat.com>
On 27 October 2016 at 17:27, Laura Abbott <labbott@redhat.com> wrote:
>
> Page mappings with full RWX permissions are a security risk. x86
> has an option to walk the page tables and dump any bad pages.
> (See e1a58320a38d ("x86/mm: Warn on W^X mappings")). Add a similar
> implementation for arm64.
>
> Reviewed-by: Kees Cook <keescook@chromium.org>
> Reviewed-by: Mark Rutland <mark.rutland@arm.com>
> Tested-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Laura Abbott <labbott@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> v4: Changed pr_info -> pr_warn. Added a separate count variable for uxn to avoid
> double counting.
> ---
> arch/arm64/Kconfig.debug | 29 ++++++++++++++++++++++
> arch/arm64/include/asm/ptdump.h | 8 +++++++
> arch/arm64/mm/dump.c | 53 +++++++++++++++++++++++++++++++++++++++++
> arch/arm64/mm/mmu.c | 2 ++
> 4 files changed, 92 insertions(+)
>
> diff --git a/arch/arm64/Kconfig.debug b/arch/arm64/Kconfig.debug
> index 21a5b74..d1ebd46 100644
> --- a/arch/arm64/Kconfig.debug
> +++ b/arch/arm64/Kconfig.debug
> @@ -42,6 +42,35 @@ config ARM64_RANDOMIZE_TEXT_OFFSET
> of TEXT_OFFSET and platforms must not require a specific
> value.
>
> +config DEBUG_WX
> + bool "Warn on W+X mappings at boot"
> + select ARM64_PTDUMP_CORE
> + ---help---
> + Generate a warning if any W+X mappings are found at boot.
> +
> + This is useful for discovering cases where the kernel is leaving
> + W+X mappings after applying NX, as such mappings are a security risk.
> + This check also includes UXN, which should be set on all kernel
> + mappings.
> +
> + Look for a message in dmesg output like this:
> +
> + arm64/mm: Checked W+X mappings: passed, no W+X pages found.
> +
> + or like this, if the check failed:
> +
> + arm64/mm: Checked W+X mappings: FAILED, <N> W+X pages found.
> +
> + Note that even if the check fails, your kernel is possibly
> + still fine, as W+X mappings are not a security hole in
> + themselves, what they do is that they make the exploitation
> + of other unfixed kernel bugs easier.
> +
> + There is no runtime or memory usage effect of this option
> + once the kernel has booted up - it's a one time check.
> +
> + If in doubt, say "Y".
> +
> config DEBUG_SET_MODULE_RONX
> bool "Set loadable kernel module data as NX and text as RO"
> depends on MODULES
> diff --git a/arch/arm64/include/asm/ptdump.h b/arch/arm64/include/asm/ptdump.h
> index f72ee69..6afd847 100644
> --- a/arch/arm64/include/asm/ptdump.h
> +++ b/arch/arm64/include/asm/ptdump.h
> @@ -42,5 +42,13 @@ static inline int ptdump_debugfs_register(struct ptdump_info *info,
> return 0;
> }
> #endif
> +void ptdump_check_wx(void);
> #endif /* CONFIG_ARM64_PTDUMP_CORE */
> +
> +#ifdef CONFIG_DEBUG_WX
> +#define debug_checkwx() ptdump_check_wx()
> +#else
> +#define debug_checkwx() do { } while (0)
> +#endif
> +
> #endif /* __ASM_PTDUMP_H */
> diff --git a/arch/arm64/mm/dump.c b/arch/arm64/mm/dump.c
> index bb36649..ef8aca8 100644
> --- a/arch/arm64/mm/dump.c
> +++ b/arch/arm64/mm/dump.c
> @@ -74,6 +74,9 @@ struct pg_state {
> unsigned long start_address;
> unsigned level;
> u64 current_prot;
> + bool check_wx;
> + unsigned long wx_pages;
> + unsigned long uxn_pages;
> };
>
> struct prot_bits {
> @@ -202,6 +205,35 @@ static void dump_prot(struct pg_state *st, const struct prot_bits *bits,
> }
> }
>
> +static void note_prot_uxn(struct pg_state *st, unsigned long addr)
> +{
> + if (!st->check_wx)
> + return;
> +
> + if ((st->current_prot & PTE_UXN) == PTE_UXN)
> + return;
> +
> + WARN_ONCE(1, "arm64/mm: Found non-UXN mapping at address %p/%pS\n",
> + (void *)st->start_address, (void *)st->start_address);
> +
> + st->uxn_pages += (addr - st->start_address) / PAGE_SIZE;
> +}
> +
> +static void note_prot_wx(struct pg_state *st, unsigned long addr)
> +{
> + if (!st->check_wx)
> + return;
> + if ((st->current_prot & PTE_RDONLY) == PTE_RDONLY)
> + return;
> + if ((st->current_prot & PTE_PXN) == PTE_PXN)
> + return;
> +
> + WARN_ONCE(1, "arm64/mm: Found insecure W+X mapping at address %p/%pS\n",
> + (void *)st->start_address, (void *)st->start_address);
> +
> + st->wx_pages += (addr - st->start_address) / PAGE_SIZE;
> +}
> +
> static void note_page(struct pg_state *st, unsigned long addr, unsigned level,
> u64 val)
> {
> @@ -219,6 +251,8 @@ static void note_page(struct pg_state *st, unsigned long addr, unsigned level,
> unsigned long delta;
>
> if (st->current_prot) {
> + note_prot_uxn(st, addr);
> + note_prot_wx(st, addr);
> pt_dump_seq_printf(st->seq, "0x%016lx-0x%016lx ",
> st->start_address, addr);
>
> @@ -344,6 +378,25 @@ static struct ptdump_info kernel_ptdump_info = {
> .base_addr = VA_START,
> };
>
> +void ptdump_check_wx(void)
> +{
> + struct pg_state st = {
> + .seq = NULL,
> + .marker = (struct addr_marker[]) {
> + { -1, NULL},
> + },
> + .check_wx = true,
> + };
> +
> + walk_pgd(&st, &init_mm, 0);
> + note_page(&st, 0, 0, 0);
> + if (st.wx_pages || st.uxn_pages)
> + pr_warn("Checked W+X mappings: FAILED, %lu W+X pages found, %lu non-UXN pages found\n",
> + st.wx_pages, st.uxn_pages);
> + else
> + pr_info("Checked W+X mappings: passed, no W+X pages found\n");
> +}
> +
> static int ptdump_init(void)
> {
> ptdump_initialize();
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index 05615a3..2cbe2fe 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -42,6 +42,7 @@
> #include <asm/tlb.h>
> #include <asm/memblock.h>
> #include <asm/mmu_context.h>
> +#include <asm/ptdump.h>
>
> u64 idmap_t0sz = TCR_T0SZ(VA_BITS);
>
> @@ -396,6 +397,7 @@ void mark_rodata_ro(void)
> section_size = (unsigned long)__init_begin - (unsigned long)__start_rodata;
> create_mapping_late(__pa(__start_rodata), (unsigned long)__start_rodata,
> section_size, PAGE_KERNEL_RO);
> + debug_checkwx();
> }
>
> static void __init map_kernel_segment(pgd_t *pgd, void *va_start, void *va_end,
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH v2 2/2] arm64: dts: hi6220: add resets property into dwmmc nodes
From: Jaehoon Chung @ 2016-10-28 11:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161028101919.GA25564@leoy-linaro>
Hi,
On 10/28/2016 07:19 PM, Leo Yan wrote:
> On Fri, Oct 28, 2016 at 06:54:58PM +0900, Jaehoon Chung wrote:
>
> [...]
>
>>>>> Could you share the log? Is there any log about failure?
>>>>
>>>> Sure, please see below log:
>>>
>>> It's related with -EPROBE_DEFER..I'm not sure but if CONFIG_RESET_CONTROLLER is enabled, it's searching for reset controller.
>>> Maybe hi6220 has handled the reset controller(?)...
>>>
>>> I'm checking devm_reset_control_xxx...It's possible to occur the other boards which enabled RESET_CONTROLLER..
>>
>> Could you check the below thing..
>>
>> /* find reset controller when exist */
>> - pdata->rstc = devm_reset_control_get_optional(dev, NULL);
>> + pdata->rstc = devm_reset_control_get_optional(dev, "dwmci-reset");
>> if (IS_ERR(pdata->rstc)) {
>> if (PTR_ERR(pdata->rstc) == -EPROBE_DEFER)
>> return ERR_PTR(-EPROBE_DEFER);
>
> Confirmed with this fixing, the kernel can bootup successfully.
>
> Thanks for this.
Thanks for checking this..If this approach is not bad, i will send the patch.
Or if there are other good approaches, let me know, plz.
Best Regards,
Jaehoon Chung
>
>> To prevent the wrong controlling, how about adding "#reset-names" for dwmmc controller?
>>
>>
>> Best Regards,
>> Jaehoon Chung
>
>
>
^ permalink raw reply
* [PATCH] ARM: davinci: enable PM for DT boot
From: Sekhar Nori @ 2016-10-28 12:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161025214738.27744-1-khilman@baylibre.com>
Hi Kevin,
On Wednesday 26 October 2016 03:17 AM, Kevin Hilman wrote:
> Currently system PM is only enabled for legacy (non-DT) boot. Enable
> for DT boot also.
>
> Tested on da850-lcdk using "rtcwake -m mem -s5 -d rtc0".
>
> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
> ---
> arch/arm/mach-davinci/da8xx-dt.c | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
> index c9f7e9274aa8..a8089fa40d86 100644
> --- a/arch/arm/mach-davinci/da8xx-dt.c
> +++ b/arch/arm/mach-davinci/da8xx-dt.c
> @@ -43,8 +43,26 @@ static struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
>
> #ifdef CONFIG_ARCH_DAVINCI_DA850
>
> +static struct davinci_pm_config da850_pm_pdata = {
> + .sleepcount = 128,
> +};
> +
> +static struct platform_device da850_pm_device = {
> + .name = "pm-davinci",
> + .dev = {
> + .platform_data = &da850_pm_pdata,
> + },
> + .id = -1,
> +};
> +
> static void __init da850_init_machine(void)
> {
> + int ret;
> +
> + ret = da850_register_pm(&da850_pm_device);
I am not sure if it makes sense to keep the "pm device" around anymore.
I think for both DT and non-DT boot, we can get rid of the fake PM
device and combine da850_register_pm() and davinci_pm_probe() into a
single davinci_init_suspend() function which can then be called both for
DT and non-DT boot.
This was we can also avoid replication of the platform data and platform
device structures.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v6] tty/serial: at91: fix hardware handshake on Atmel platforms
From: Greg Kroah-Hartman @ 2016-10-28 12:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACQ1gAjX6fVghjxf=o_WNUDYFW6Sc_HF_3G6gxrSma5F3qjpbQ@mail.gmail.com>
On Fri, Oct 28, 2016 at 12:56:09PM +0200, Richard Genoud wrote:
> 2016-10-28 11:51 GMT+02:00 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>:
> > On Fri, Oct 28, 2016 at 01:13:31AM +0200, Alexandre Belloni wrote:
> >> On 27/10/2016 at 20:02:29 +0200, Uwe Kleine-K?nig wrote :
> >> > Hello Richard,
> >> >
> >> > On Thu, Oct 27, 2016 at 06:04:06PM +0200, Richard Genoud wrote:
> >> > > diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
> >> > > index fd8aa1f4ba78..168b10cad47b 100644
> >> > > --- a/drivers/tty/serial/atmel_serial.c
> >> > > +++ b/drivers/tty/serial/atmel_serial.c
> >> > > @@ -2132,11 +2132,29 @@ static void atmel_set_termios(struct uart_port *port, struct ktermios *termios,
> >> > > mode |= ATMEL_US_USMODE_RS485;
> >> > > } else if (termios->c_cflag & CRTSCTS) {
> >> > > /* RS232 with hardware handshake (RTS/CTS) */
> >> > > - if (atmel_use_dma_rx(port) && !atmel_use_fifo(port)) {
> >> > > - dev_info(port->dev, "not enabling hardware flow control because DMA is used");
> >> > > - termios->c_cflag &= ~CRTSCTS;
> >> > > - } else {
> >> > > + if (atmel_use_fifo(port) &&
> >> > > + !mctrl_gpio_to_gpiod(atmel_port->gpios, UART_GPIO_CTS)) {
> >> > > + /*
> >> > > + * with ATMEL_US_USMODE_HWHS set, the controller will
> >> > > + * be able to drive the RTS pin high/low when the RX
> >> > > + * FIFO is above RXFTHRES/below RXFTHRES2.
> >> > > + * It will also disable the transmitter when the CTS
> >> > > + * pin is high.
> >> > > + * This mode is not activated if CTS pin is a GPIO
> >> > > + * because in this case, the transmitter is always
> >> > > + * disabled (there must be an internal pull-up
> >> > > + * responsible for this behaviour).
> >> > > + * If the RTS pin is a GPIO, the controller won't be
> >> > > + * able to drive it according to the FIFO thresholds,
> >> > > + * but it will be handled by the driver.
> >> > > + */
> >> > > mode |= ATMEL_US_USMODE_HWHS;
> >> >
> >> > You use
> >> >
> >> > !mctrl_gpio_to_gpiod(atmel_port->gpios, UART_GPIO_CTS)
> >> >
> >> > as indicator that the cts mode of the respective pin is used. Is this
> >> > reliable? (It's not if there are machines that don't use CTS, neither as
> >> > gpio nor using the hardware function.) Maybe this needs a dt property to
> >> > indicate that there is no (hw)handshaking available?
> >> >
> >>
> >> We had a call today were we agreed that this should be added in a future
> >> patch. Let's fix the regression for now.
> >
> > A machine without CTS (neither gpio nor hw function) used to work fine
> > before the breaking commit, right? So this case is part of the
> > regression and needs a fix?
> Actually, a machine with a FIFO and without CTS didn't even exist at the
> time of the breaking commit (v4.0), the FIFO handling was introduced later,
> so it's not even a regression !
>
> > Anyhow, this probably shouldn't stop the commit entering mainline
> > because there are probably very few such machines (if any).
> >
> > So:
> > Acked-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
> >
> > Best regards
> > Uwe
>
>
> Thanks !
>
> Greg, could you take this in your tree ?
Now applied, thanks for working through all of this.
greg k-h
^ permalink raw reply
* [PATCH] Revert "gpio/mvebu: convert to use irq_domain_add_simple()"
From: Linus Walleij @ 2016-10-28 12:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87twbyb65j.fsf@free-electrons.com>
On Thu, Oct 27, 2016 at 9:30 AM, Gregory CLEMENT
<gregory.clement@free-electrons.com> wrote:
> On lun., oct. 24 2016, Linus Walleij <linus.walleij@linaro.org> wrote:
>> On Wed, Oct 19, 2016 at 11:03 PM, Jason Gunthorpe
>> <jgunthorpe@obsidianresearch.com> wrote:
>>
>>> From 7566f05ac445b652ba7607cc1899fed10fea1c76 Mon Sep 17 00:00:00 2001
>>> From: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
>>> Date: Wed, 19 Oct 2016 14:57:45 -0600
>>> Subject: [PATCH] gpio/mvebu: Use irq_domain_add_linear
>>>
>>> This fixes the irq allocation in this driver to not print:
>>> irq: Cannot allocate irq_descs @ IRQ34, assuming pre-allocated
>>> irq: Cannot allocate irq_descs @ IRQ66, assuming pre-allocated
>>>
>>> Which happens because the driver already called irq_alloc_descs()
>>> and so the change to use irq_domain_add_simple resulted in calling
>>> irq_alloc_descs() twice.
>>>
>>> Modernize the irq allocation in this driver to use the
>>> irq_domain_add_linear flow directly and eliminate the use of
>>> irq_domain_add_simple/legacy
>>>
>>> Fixes: ce931f571b6d ("gpio/mvebu: convert to use irq_domain_add_simple()")
>>> Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
>>
>> So can I just apply this?
>> Gregory?
>
> For me it's OK.
APplied this inline version.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2 2/2] arm64: dts: hi6220: add resets property into dwmmc nodes
From: Leo Yan @ 2016-10-28 12:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f5dfafbb-39df-4edb-03b8-57c0e34c912f@samsung.com>
On Fri, Oct 28, 2016 at 08:52:49PM +0900, Jaehoon Chung wrote:
[...]
> >> Could you check the below thing..
> >>
> >> /* find reset controller when exist */
> >> - pdata->rstc = devm_reset_control_get_optional(dev, NULL);
> >> + pdata->rstc = devm_reset_control_get_optional(dev, "dwmci-reset");
> >> if (IS_ERR(pdata->rstc)) {
> >> if (PTR_ERR(pdata->rstc) == -EPROBE_DEFER)
> >> return ERR_PTR(-EPROBE_DEFER);
> >
> > Confirmed with this fixing, the kernel can bootup successfully.
> >
> > Thanks for this.
>
> Thanks for checking this..If this approach is not bad, i will send the patch.
> Or if there are other good approaches, let me know, plz.
I'd like Guodong and John to confirm for Hikey specific. I have no
knowledge for this so cannot answer.
Thanks,
Leo Yan
^ permalink raw reply
* [PATCH v2 0/8] Support TPS65217 PMIC interrupt in DT
From: Milo Kim @ 2016-10-28 12:36 UTC (permalink / raw)
To: linux-arm-kernel
TPS65217 interrupt events include push button pressed/released, USB and AC
voltage status change. AM335x bone based boards (like BB, BBB, BBG) have
common PMIC interrupt pin (named NMI) of AM335x core.
This patchset support interrupts in device tree file.
v2:
Add missing a dt-binding header
Use #defines instead of enum type for interrupt numbers
Milo Kim (8):
ARM: dts: tps65217: Specify the interrupt controller
ARM: dts: tps65217: Add the charger device
ARM: dts: tps65217: Add the power button device
ARM: dts: am335x: Support the PMIC interrupt
dt-bindings: mfd: Provide human readable defines for TPS65217
interrupts
ARM: dts: am335x: Add the charger interrupt
ARM: dts: am335x: Add the power button interrupt
mfd: tps65217: Fix mismatched interrupt number
arch/arm/boot/dts/am335x-bone-common.dtsi | 17 +++++++++++++++++
arch/arm/boot/dts/tps65217.dtsi | 12 ++++++++++++
include/dt-bindings/mfd/tps65217.h | 26 ++++++++++++++++++++++++++
include/linux/mfd/tps65217.h | 11 +++++------
4 files changed, 60 insertions(+), 6 deletions(-)
create mode 100644 include/dt-bindings/mfd/tps65217.h
--
2.9.3
^ permalink raw reply
* [PATCH v2 1/8] ARM: dts: tps65217: Specify the interrupt controller
From: Milo Kim @ 2016-10-28 12:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161028123702.21849-1-woogyom.kim@gmail.com>
TPS65217 MFD driver supports the IRQ domain to handle the charger input
interrupts and push button status event. The interrupt controller enables
corresponding IRQ handling in the charger[*] and power button driver[**].
[*] drivers/power/supply/tps65217_charger.c
[**] drivers/input/misc/tps65218-pwrbutton.c
Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
---
arch/arm/boot/dts/tps65217.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/tps65217.dtsi b/arch/arm/boot/dts/tps65217.dtsi
index a632724..27935f8 100644
--- a/arch/arm/boot/dts/tps65217.dtsi
+++ b/arch/arm/boot/dts/tps65217.dtsi
@@ -13,6 +13,8 @@
&tps {
compatible = "ti,tps65217";
+ interrupt-controller;
+ #interrupt-cells = <1>;
regulators {
#address-cells = <1>;
--
2.9.3
^ permalink raw reply related
* [PATCH v2 2/8] ARM: dts: tps65217: Add the charger device
From: Milo Kim @ 2016-10-28 12:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161028123702.21849-1-woogyom.kim@gmail.com>
Support the charger driver and disable it by default.
Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
---
arch/arm/boot/dts/tps65217.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/tps65217.dtsi b/arch/arm/boot/dts/tps65217.dtsi
index 27935f8..8f77d0d 100644
--- a/arch/arm/boot/dts/tps65217.dtsi
+++ b/arch/arm/boot/dts/tps65217.dtsi
@@ -16,6 +16,11 @@
interrupt-controller;
#interrupt-cells = <1>;
+ charger {
+ compatible = "ti,tps65217-charger";
+ status = "disabled";
+ };
+
regulators {
#address-cells = <1>;
#size-cells = <0>;
--
2.9.3
^ permalink raw reply related
* [PATCH v2 3/8] ARM: dts: tps65217: Add the power button device
From: Milo Kim @ 2016-10-28 12:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161028123702.21849-1-woogyom.kim@gmail.com>
Support the power button driver and disable it by default.
Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
---
arch/arm/boot/dts/tps65217.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/tps65217.dtsi b/arch/arm/boot/dts/tps65217.dtsi
index 8f77d0d..02de56b 100644
--- a/arch/arm/boot/dts/tps65217.dtsi
+++ b/arch/arm/boot/dts/tps65217.dtsi
@@ -21,6 +21,11 @@
status = "disabled";
};
+ pwrbutton {
+ compatible = "ti,tps65217-pwrbutton";
+ status = "disabled";
+ };
+
regulators {
#address-cells = <1>;
#size-cells = <0>;
--
2.9.3
^ permalink raw reply related
* [PATCH v2 4/8] ARM: dts: am335x: Support the PMIC interrupt
From: Milo Kim @ 2016-10-28 12:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161028123702.21849-1-woogyom.kim@gmail.com>
AM335x bone based boards have the PMIC interrupt named NMI which is
connected to TPS65217 device. AM335x main interrupt controller provides it
and the number is 7.
Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi b/arch/arm/boot/dts/am335x-bone-common.dtsi
index 007b5e5..25303d9 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -310,6 +310,10 @@
* by the hardware problems. (Tip: double-check by performing a current
* measurement after shutdown: it should be less than 1 mA.)
*/
+
+ interrupts = <7>; /* NMI */
+ interrupt-parent = <&intc>;
+
ti,pmic-shutdown-controller;
regulators {
--
2.9.3
^ permalink raw reply related
* [PATCH v2 5/8] dt-bindings: mfd: Provide human readable defines for TPS65217 interrupts
From: Milo Kim @ 2016-10-28 12:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161028123702.21849-1-woogyom.kim@gmail.com>
TPS65217 supports three interrupt sources. This patch enables assigning
each IRQ number in the charger and power button node. Then corresponding
IRQ will be requested by each driver.
Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
---
include/dt-bindings/mfd/tps65217.h | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
create mode 100644 include/dt-bindings/mfd/tps65217.h
diff --git a/include/dt-bindings/mfd/tps65217.h b/include/dt-bindings/mfd/tps65217.h
new file mode 100644
index 0000000..cafb9e6
--- /dev/null
+++ b/include/dt-bindings/mfd/tps65217.h
@@ -0,0 +1,26 @@
+/*
+ * This header provides macros for TI TPS65217 DT bindings.
+ *
+ * Copyright (C) 2016 Texas Instruments
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef __DT_BINDINGS_TPS65217_H__
+#define __DT_BINDINGS_TPS65217_H__
+
+#define TPS65217_IRQ_USB 0
+#define TPS65217_IRQ_AC 1
+#define TPS65217_IRQ_PB 2
+
+#endif
--
2.9.3
^ permalink raw reply related
* [PATCH v2 6/8] ARM: dts: am335x: Add the charger interrupt
From: Milo Kim @ 2016-10-28 12:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161028123702.21849-1-woogyom.kim@gmail.com>
This enables the charger driver gets corresponding IRQ number by using
platform_get_irq_byname() helper.
Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi b/arch/arm/boot/dts/am335x-bone-common.dtsi
index 25303d9..cec9d91 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -6,6 +6,8 @@
* published by the Free Software Foundation.
*/
+#include <dt-bindings/mfd/tps65217.h>
+
/ {
cpus {
cpu at 0 {
@@ -316,6 +318,12 @@
ti,pmic-shutdown-controller;
+ charger {
+ interrupts = <TPS65217_IRQ_AC>, <TPS65217_IRQ_USB>;
+ interrupts-names = "AC", "USB";
+ status = "okay";
+ };
+
regulators {
dcdc1_reg: regulator at 0 {
regulator-name = "vdds_dpr";
--
2.9.3
^ permalink raw reply related
* [PATCH v2 7/8] ARM: dts: am335x: Add the power button interrupt
From: Milo Kim @ 2016-10-28 12:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161028123702.21849-1-woogyom.kim@gmail.com>
This enables the power button driver gets corresponding IRQ number by
using platform_get_irq().
Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi b/arch/arm/boot/dts/am335x-bone-common.dtsi
index cec9d91..0c0a90c 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -324,6 +324,11 @@
status = "okay";
};
+ pwrbutton {
+ interrupts = <TPS65217_IRQ_PB>;
+ status = "okay";
+ };
+
regulators {
dcdc1_reg: regulator at 0 {
regulator-name = "vdds_dpr";
--
2.9.3
^ permalink raw reply related
* [PATCH v2 8/8] mfd: tps65217: Fix mismatched interrupt number
From: Milo Kim @ 2016-10-28 12:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161028123702.21849-1-woogyom.kim@gmail.com>
Enum value of 'tps65217_irq_type' is not matched with DT parsed hwirq
number[*].
The MFD driver gets the IRQ data by referencing hwirq, but the value is
different. So, irq_to_tps65217_irq() returns mismatched IRQ data.
Eventually, the power button driver enables not PB but USB interrupt
when it is probed.
According to the TPS65217 register map[**], USB interrupt is the LSB.
This patch defines synchronized IRQ value.
[*] include/dt-bindings/mfd/tps65217.h
[**] http://www.ti.com/lit/ds/symlink/tps65217.pdf
Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
---
include/linux/mfd/tps65217.h | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/include/linux/mfd/tps65217.h b/include/linux/mfd/tps65217.h
index 4ccda89..3cbec4b 100644
--- a/include/linux/mfd/tps65217.h
+++ b/include/linux/mfd/tps65217.h
@@ -234,12 +234,11 @@ struct tps65217_bl_pdata {
int dft_brightness;
};
-enum tps65217_irq_type {
- TPS65217_IRQ_PB,
- TPS65217_IRQ_AC,
- TPS65217_IRQ_USB,
- TPS65217_NUM_IRQ
-};
+/* Interrupt numbers */
+#define TPS65217_IRQ_USB 0
+#define TPS65217_IRQ_AC 1
+#define TPS65217_IRQ_PB 2
+#define TPS65217_NUM_IRQ 3
/**
* struct tps65217_board - packages regulator init data
--
2.9.3
^ permalink raw reply related
* [PATCH] nvmem: sunxi-sid: SID content is not a valid source of randomness
From: LABBE Corentin @ 2016-10-28 12:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161025090634.3dae9ad52ae8382dde6af4c8@free.fr>
On Tue, Oct 25, 2016 at 09:06:34AM +0200, Jean-Francois Moine wrote:
> On Tue, 25 Oct 2016 07:38:55 +0200
> LABBE Corentin <clabbe.montjoie@gmail.com> wrote:
>
> > > On Sat, Oct 22, 2016 at 03:53:28PM +0200, Corentin Labbe wrote:
> > > > Since SID's content is constant over reboot,
> > >
> > > That's not true, at least not across all the Allwinner SoCs, and
> > > especially not on the A10 and A20 that this driver supports.
> > >
> >
> > On my cubieboard2 (A20)
> > hexdump -C /sys/devices/platform/soc\@01c00000/1c23800.eeprom/sunxi-sid0/nvmem
> > 00000000 16 51 66 83 80 48 50 72 56 54 48 48 03 c2 75 72 |.Qf..HPrVTHH..ur|
> > 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> > *
> > 00000100 16 51 66 83 80 48 50 72 56 54 48 48 03 c2 75 72 |.Qf..HPrVTHH..ur|
> > 00000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> > *
> > 00000200
> > cubiedev ~ # reboot
> > cubiedev ~ # hexdump -C /sys/devices/platform/soc\@01c00000/1c23800.eeprom/sunxi-sid0/nvmem
> > 00000000 16 51 66 83 80 48 50 72 56 54 48 48 03 c2 75 72 |.Qf..HPrVTHH..ur|
> > 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> > *
> > 00000100 16 51 66 83 80 48 50 72 56 54 48 48 03 c2 75 72 |.Qf..HPrVTHH..ur|
> > 00000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> > *
> > 00000200
> >
> > So clearly for me its constant.
>
> Even after power off/power on?
Yes, even after remove of any power supply.
^ permalink raw reply
* ILP32 for ARM64 - testing with lmbench
From: Yury Norov @ 2016-10-28 12:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477081997-4770-1-git-send-email-ynorov@caviumnetworks.com>
[Add Steve Ellcey, thanks for testing on ThunderX]
Lmbench-3.0-a9 testing is performed on ThunderX machine to check that
ILP32 series does not add performance regressions for LP64. Test
summary is in the table below. Our measurements doesn't show
significant performance regression of LP64 if ILP32 code is merged,
both enabled or disabled.
ILP32 enabled ILP32 disabled Standard Kernel
null syscall 0.1066 0.1121 0.1121
95.09% 100.00%
stat 1.3947 1.3814 1.3864
100.60% 99.64%
fstat 0.4459 0.4344 0.4524
98.56% 96.02%
open/close 4.0606 4.0411 4.0453
100.38% 99.90%
read 0.4819 0.5014 0.5014
96.11% 100.00%
Tested with linux 4.8 because 4.9-rc1 is not fixed yet for ThunderX.
Other system details below.
Yury.
ubuntu at crb6:~$ uname -a
Linux crb6 4.8.0+ #3 SMP Thu Oct 27 11:01:32 PDT 2016 aarch64 aarch64 aarch64 GNU/Linux
ubuntu at crb6:~$ cat /proc/meminfo
MemTotal:???????132011948 kB
MemFree:????????131442672 kB
MemAvailable:???130695764 kB
Buffers:???????????15696 kB
Cached:????????????88088 kB
SwapCached:????????????0 kB
Active:????????????82760 kB
Inactive:??????????41336 kB
Active(anon):??????20880 kB
Inactive(anon):?????8576 kB
Active(file):??????61880 kB
Inactive(file):????32760 kB
Unevictable:???????????0 kB
Mlocked:???????????????0 kB
SwapTotal:??????128920572 kB
SwapFree:???????128920572 kB
Dirty:?????????????????0 kB
Writeback:?????????????0 kB
AnonPages:?????????20544 kB
Mapped:????????????19780 kB
Shmem:??????????????9060 kB
Slab:??????????????78804 kB
SReclaimable:??????27372 kB
SUnreclaim:????????51432 kB
KernelStack:????????8336 kB
PageTables:??????????820 kB
NFS_Unstable:??????????0 kB
Bounce:????????????????0 kB
WritebackTmp:??????????0 kB
CommitLimit:????194926544 kB
Committed_AS:?????256324 kB
VmallocTotal:???135290290112 kB
VmallocUsed:???????????0 kB
VmallocChunk:??????????0 kB
AnonHugePages:?????????0 kB
ShmemHugePages:????????0 kB
ShmemPmdMapped:????????0 kB
CmaTotal:??????????????0 kB
CmaFree:???????????????0 kB
HugePages_Total:???????0
HugePages_Free:????????0
HugePages_Rsvd:????????0
HugePages_Surp:????????0
Hugepagesize:???????2048 kB
ubuntu at crb6:~$ cat /proc/cpuinfo
processor : 0
BogoMIPS : 200.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
CPU implementer : 0x43
CPU architecture: 8
CPU variant : 0x1
CPU part : 0x0a1
CPU revision : 0
processor : 1
BogoMIPS : 200.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
CPU implementer : 0x43
CPU architecture: 8
CPU variant : 0x1
CPU part : 0x0a1
CPU revision : 0
processor : 2
BogoMIPS : 200.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
CPU implementer : 0x43
CPU architecture: 8
CPU variant : 0x1
CPU part : 0x0a1
CPU revision : 0
processor : 3
BogoMIPS : 200.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
CPU implementer : 0x43
CPU architecture: 8
CPU variant : 0x1
CPU part : 0x0a1
CPU revision : 0
processor : 4
BogoMIPS : 200.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
CPU implementer : 0x43
CPU architecture: 8
CPU variant : 0x1
CPU part : 0x0a1
CPU revision : 0
processor : 5
BogoMIPS : 200.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
CPU implementer : 0x43
CPU architecture: 8
CPU variant : 0x1
CPU part : 0x0a1
CPU revision : 0
processor : 6
BogoMIPS : 200.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
CPU implementer : 0x43
CPU architecture: 8
CPU variant : 0x1
CPU part : 0x0a1
CPU revision : 0
processor : 7
BogoMIPS : 200.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
CPU implementer : 0x43
CPU architecture: 8
CPU variant : 0x1
CPU part : 0x0a1
CPU revision : 0
processor : 8
BogoMIPS : 200.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
CPU implementer : 0x43
CPU architecture: 8
CPU variant : 0x1
CPU part : 0x0a1
CPU revision : 0
processor : 9
BogoMIPS : 200.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
CPU implementer : 0x43
CPU architecture: 8
CPU variant : 0x1
CPU part : 0x0a1
CPU revision : 0
processor : 10
BogoMIPS : 200.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
CPU implementer : 0x43
CPU architecture: 8
CPU variant : 0x1
CPU part : 0x0a1
CPU revision : 0
processor : 11
BogoMIPS : 200.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
CPU implementer : 0x43
CPU architecture: 8
CPU variant : 0x1
CPU part : 0x0a1
CPU revision : 0
processor : 12
BogoMIPS : 200.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
CPU implementer : 0x43
CPU architecture: 8
CPU variant : 0x1
CPU part : 0x0a1
CPU revision : 0
processor : 13
BogoMIPS : 200.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
CPU implementer : 0x43
CPU architecture: 8
CPU variant : 0x1
CPU part : 0x0a1
CPU revision : 0
processor : 14
BogoMIPS : 200.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
CPU implementer : 0x43
CPU architecture: 8
CPU variant : 0x1
CPU part : 0x0a1
CPU revision : 0
processor : 15
BogoMIPS : 200.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
CPU implementer : 0x43
CPU architecture: 8
CPU variant : 0x1
CPU part : 0x0a1
CPU revision : 0
processor : 16
BogoMIPS : 200.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
CPU implementer : 0x43
CPU architecture: 8
CPU variant : 0x1
CPU part : 0x0a1
CPU revision : 0
processor : 17
BogoMIPS : 200.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
CPU implementer : 0x43
CPU architecture: 8
CPU variant : 0x1
CPU part : 0x0a1
CPU revision : 0
processor : 18
BogoMIPS : 200.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
CPU implementer : 0x43
CPU architecture: 8
CPU variant : 0x1
CPU part : 0x0a1
CPU revision : 0
processor : 19
BogoMIPS : 200.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
CPU implementer : 0x43
CPU architecture: 8
CPU variant : 0x1
CPU part : 0x0a1
CPU revision : 0
processor : 20
BogoMIPS : 200.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
CPU implementer : 0x43
CPU architecture: 8
CPU variant : 0x1
CPU part : 0x0a1
CPU revision : 0
processor : 21
BogoMIPS : 200.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
CPU implementer : 0x43
CPU architecture: 8
CPU variant : 0x1
CPU part : 0x0a1
CPU revision : 0
processor : 22
BogoMIPS : 200.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
CPU implementer : 0x43
CPU architecture: 8
CPU variant : 0x1
CPU part : 0x0a1
CPU revision : 0
processor : 23
BogoMIPS : 200.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
CPU implementer : 0x43
CPU architecture: 8
CPU variant : 0x1
CPU part : 0x0a1
CPU revision : 0
processor : 24
BogoMIPS : 200.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
CPU implementer : 0x43
CPU architecture: 8
CPU variant : 0x1
CPU part : 0x0a1
CPU revision : 0
processor : 25
BogoMIPS : 200.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
CPU implementer : 0x43
CPU architecture: 8
CPU variant : 0x1
CPU part : 0x0a1
CPU revision : 0
processor : 26
BogoMIPS : 200.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
CPU implementer : 0x43
CPU architecture: 8
CPU variant : 0x1
CPU part : 0x0a1
CPU revision : 0
processor : 27
BogoMIPS : 200.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
CPU implementer : 0x43
CPU architecture: 8
CPU variant : 0x1
CPU part : 0x0a1
CPU revision : 0
processor : 28
BogoMIPS : 200.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
CPU implementer : 0x43
CPU architecture: 8
CPU variant : 0x1
CPU part : 0x0a1
CPU revision : 0
processor : 29
BogoMIPS : 200.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
CPU implementer : 0x43
CPU architecture: 8
CPU variant : 0x1
CPU part : 0x0a1
CPU revision : 0
processor : 30
BogoMIPS : 200.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
CPU implementer : 0x43
CPU architecture: 8
CPU variant : 0x1
CPU part : 0x0a1
CPU revision : 0
processor : 31
BogoMIPS : 200.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
CPU implementer : 0x43
CPU architecture: 8
CPU variant : 0x1
CPU part : 0x0a1
CPU revision : 0
processor : 32
BogoMIPS : 200.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
CPU implementer : 0x43
CPU architecture: 8
CPU variant : 0x1
CPU part : 0x0a1
CPU revision : 0
processor : 33
BogoMIPS : 200.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
CPU implementer : 0x43
CPU architecture: 8
CPU variant : 0x1
CPU part : 0x0a1
CPU revision : 0
processor : 34
BogoMIPS : 200.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
CPU implementer : 0x43
CPU architecture: 8
CPU variant : 0x1
CPU part : 0x0a1
CPU revision : 0
processor : 35
BogoMIPS : 200.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
CPU implementer : 0x43
CPU architecture: 8
CPU variant : 0x1
CPU part : 0x0a1
CPU revision : 0
processor : 36
BogoMIPS : 200.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
CPU implementer : 0x43
CPU architecture: 8
CPU variant : 0x1
CPU part : 0x0a1
CPU revision : 0
processor : 37
BogoMIPS : 200.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
CPU implementer : 0x43
CPU architecture: 8
CPU variant : 0x1
CPU part : 0x0a1
CPU revision : 0
processor : 38
BogoMIPS : 200.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
CPU implementer : 0x43
CPU architecture: 8
CPU variant : 0x1
CPU part : 0x0a1
CPU revision : 0
processor : 39
BogoMIPS : 200.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
CPU implementer : 0x43
CPU architecture: 8
CPU variant : 0x1
CPU part : 0x0a1
CPU revision : 0
processor : 40
BogoMIPS : 200.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
CPU implementer : 0x43
CPU architecture: 8
CPU variant : 0x1
CPU part : 0x0a1
CPU revision : 0
processor : 41
BogoMIPS : 200.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
CPU implementer : 0x43
CPU architecture: 8
CPU variant : 0x1
CPU part : 0x0a1
CPU revision : 0
processor : 42
BogoMIPS : 200.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
CPU implementer : 0x43
CPU architecture: 8
CPU variant : 0x1
CPU part : 0x0a1
CPU revision : 0
processor : 43
BogoMIPS : 200.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
CPU implementer : 0x43
CPU architecture: 8
CPU variant : 0x1
CPU part : 0x0a1
CPU revision : 0
processor : 44
BogoMIPS : 200.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
CPU implementer : 0x43
CPU architecture: 8
CPU variant : 0x1
CPU part : 0x0a1
CPU revision : 0
processor : 45
BogoMIPS : 200.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
CPU implementer : 0x43
CPU architecture: 8
CPU variant : 0x1
CPU part : 0x0a1
CPU revision : 0
processor : 46
BogoMIPS : 200.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
CPU implementer : 0x43
CPU architecture: 8
CPU variant : 0x1
CPU part : 0x0a1
CPU revision : 0
processor : 47
BogoMIPS : 200.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics
CPU implementer : 0x43
CPU architecture: 8
CPU variant : 0x1
CPU part : 0x0a1
CPU revision : 0
^ permalink raw reply
* [PATCHv4 11/15] clk: ti: clockdomain: add clock provider support to clockdomains
From: Tony Lindgren @ 2016-10-28 12:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cd32a554-ba0a-33cd-c15c-121524ce679b@ti.com>
* Tero Kristo <t-kristo@ti.com> [161028 00:43]:
> On 28/10/16 03:50, Stephen Boyd wrote:
> > I suppose a PRCM is
> > like an MFD that has clocks and resets under it? On other
> > platforms we've combined that all into one node and just had
> > #clock-cells and #reset-cells in that node. Is there any reason
> > we can't do that here?
>
> For OMAPs, there are typically multiple instances of the PRCM around; OMAP4
> for example has:
>
> cm1 @ 0x4a004000 (clocks + clockdomains)
> cm2 @ 0x4a008000 (clocks + clockdomains)
> prm @ 0x4a306000 (few clocks + resets + power state handling)
> scrm @ 0x4a30a000 (few external clocks + plenty of misc stuff)
>
> These instances are also under different power/voltage domains which means
> their PM behavior is different.
>
> The idea behind having a clockdomain as a provider was mostly to have the
> topology visible : prcm-instance -> clockdomain -> clocks
Yeah that's needed to get the interconnect hierarchy right for
genpd :)
> ... but basically I think it would be possible to drop the clockdomain
> representation and just mark the prcm-instance as a clock provider. Tony,
> any thoughts on that?
No let's not drop the clockdomains as those will be needed when we
move things into proper hierarchy within the interconnect instances.
This will then help with getting things right with genpd.
In the long run we just want to specify clockdomain and the offset of
the clock instance within the clockdomain in the dts files.
Regards,
Tony
^ permalink raw reply
* [PATCH v2 3/3] reset: Add the TI SCI reset driver
From: Nishanth Menon @ 2016-10-28 13:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477647364.3010.28.camel@pengutronix.de>
On Fri, Oct 28, 2016 at 4:36 AM, Philipp Zabel <p.zabel@pengutronix.de> wrote:
> Hi Andrew,
>
> is there (going to be) as stable branch I can base these on, or should I
> just wait until the prerequisite patches appear in arm-soc/for-next?
>
TISCI is still to be merged.
http://marc.info/?l=linux-arm-kernel&m=147756439730680&w=2 pull
request for 4.10 was send out recently.
---
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH 1/3] ARM: dts: exynos: Document eMMC/SD/SDIO devices in Exynos5250 Snow board
From: Krzysztof Kozlowski @ 2016-10-28 13:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477588303-13681-1-git-send-email-javier@osg.samsung.com>
On Thu, Oct 27, 2016 at 02:11:41PM -0300, Javier Martinez Canillas wrote:
> There's a cognitive load to figure out which mmc device node corresponds
> to the eMMC flash, uSD card and WiFI SDIO module on the Snow boards.
>
> So it's better to have comments in the DTS to make this more clear.
>
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
> ---
>
> arch/arm/boot/dts/exynos5250-snow-common.dtsi | 4 ++++
> 1 file changed, 4 insertions(+)
Thanks, applied after squashing three into one. These are only comments,
so no impact on the code, and meaning/goal of them is exactly same.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 1/3] ARM: dts: exynos: Document eMMC/SD/SDIO devices in Exynos5250 Snow board
From: Javier Martinez Canillas @ 2016-10-28 13:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161028133424.GA5646@kozik-lap>
Hello Krzysztof,
On 10/28/2016 10:34 AM, Krzysztof Kozlowski wrote:
> On Thu, Oct 27, 2016 at 02:11:41PM -0300, Javier Martinez Canillas wrote:
>> There's a cognitive load to figure out which mmc device node corresponds
>> to the eMMC flash, uSD card and WiFI SDIO module on the Snow boards.
>>
>> So it's better to have comments in the DTS to make this more clear.
>>
>> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
>> ---
>>
>> arch/arm/boot/dts/exynos5250-snow-common.dtsi | 4 ++++
>> 1 file changed, 4 insertions(+)
>
> Thanks, applied after squashing three into one. These are only comments,
> so no impact on the code, and meaning/goal of them is exactly same.
>
Ok, sounds good to me. Thanks!
> Best regards,
> Krzysztof
>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* [PATCH 1/2] ARM: dts: exynos: Use macro for PWM signal polarity in Exynos4 boards
From: Krzysztof Kozlowski @ 2016-10-28 13:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477590438-18095-1-git-send-email-javier@osg.samsung.com>
On Thu, Oct 27, 2016 at 02:47:17PM -0300, Javier Martinez Canillas wrote:
> Using the PWM_POLARITY_INVERTED macro instead of the hardcoded number
> 0 makes the DTS easier to read.
Eeee.... PWM_POLARITY_INVERTED = 1 << 0 = 1.
And you are replacing 0 with 1. Hm? This is not described@all in
commit message...
Best regards,
Krzysztof
>
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
> ---
>
> arch/arm/boot/dts/exynos4412-odroidu3.dts | 3 ++-
> arch/arm/boot/dts/exynos4412-trats2.dts | 3 ++-
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts b/arch/arm/boot/dts/exynos4412-odroidu3.dts
> index 99634c54dca9..480a80624b77 100644
> --- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
> +++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
> @@ -12,6 +12,7 @@
> */
>
> /dts-v1/;
> +#include <dt-bindings/pwm/pwm.h>
> #include "exynos4412-odroid-common.dtsi"
>
> / {
> @@ -35,7 +36,7 @@
>
> fan0: pwm-fan {
> compatible = "pwm-fan";
> - pwms = <&pwm 0 10000 0>;
> + pwms = <&pwm 0 10000 PWM_POLARITY_INVERTED>;
> cooling-min-state = <0>;
> cooling-max-state = <3>;
> #cooling-cells = <2>;
> diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts b/arch/arm/boot/dts/exynos4412-trats2.dts
> index 41ecd6d465a7..63ad30507d4f 100644
> --- a/arch/arm/boot/dts/exynos4412-trats2.dts
> +++ b/arch/arm/boot/dts/exynos4412-trats2.dts
> @@ -18,6 +18,7 @@
> #include <dt-bindings/gpio/gpio.h>
> #include <dt-bindings/interrupt-controller/irq.h>
> #include <dt-bindings/clock/maxim,max77686.h>
> +#include <dt-bindings/pwm/pwm.h>
>
> / {
> model = "Samsung Trats 2 based on Exynos4412";
> @@ -164,7 +165,7 @@
> max77693_haptic {
> compatible = "maxim,max77693-haptic";
> haptic-supply = <&ldo26_reg>;
> - pwms = <&pwm 0 38022 0>;
> + pwms = <&pwm 0 38022 PWM_POLARITY_INVERTED>;
> };
>
> charger {
> --
> 2.7.4
>
^ 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