* [PATCH v13 7/8] clocksource/drivers/arm_arch_timer: Add GTDT support for memory-mapped timer
From: Fu Wei @ 2016-09-15 10:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473883781-9571-8-git-send-email-fu.wei@linaro.org>
HI
On 15 September 2016 at 04:09, <fu.wei@linaro.org> wrote:
> From: Fu Wei <fu.wei@linaro.org>
>
> The patch add memory-mapped timer register support by using the information
> provided by the new GTDT driver of ACPI.
> Also refactor original memory-mapped timer dt support for reusing some common
> code.
>
> Signed-off-by: Fu Wei <fu.wei@linaro.org>
> ---
> drivers/clocksource/arm_arch_timer.c | 238 +++++++++++++++++++++++++----------
> 1 file changed, 172 insertions(+), 66 deletions(-)
>
> diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
> index 0197ef9..ddca6e3 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -57,6 +57,7 @@
> static unsigned arch_timers_present __initdata;
>
> static void __iomem *arch_counter_base;
> +static void __iomem *cntctlbase __initdata;
>
> struct arch_timer {
> void __iomem *base;
> @@ -656,15 +657,56 @@ out:
> return err;
> }
>
> -static int __init arch_timer_mem_register(void __iomem *base, unsigned int irq)
> +static int __init arch_timer_mem_register(struct device_node *np, void *frame)
> {
> - int ret;
> - irq_handler_t func;
> + struct device_node *frame_node = NULL;
> + struct gt_timer_data *frame_data = NULL;
> struct arch_timer *t;
> + void __iomem *base;
> + irq_handler_t func;
> + unsigned int irq;
> + int ret;
> +
> + if (np) {
> + frame_node = (struct device_node *)frame;
> + base = of_iomap(frame_node, 0);
> + arch_timer_detect_rate(base, np);
> + if (arch_timer_mem_use_virtual)
> + irq = irq_of_parse_and_map(frame_node, VIRT_SPI);
> + else
> + irq = irq_of_parse_and_map(frame_node, PHYS_SPI);
> + } else {
> + frame_data = (struct gt_timer_data *)frame;
> + /*
> + * According to ARMv8 Architecture Reference Manual(ARM),
> + * the size of CNTBaseN frames of memory-mapped timer
> + * is SZ_4K(Offset 0x000 ? 0xFFF).
> + */
> + base = ioremap(frame_data->cntbase_phy, SZ_4K);
> + if (arch_timer_mem_use_virtual)
> + irq = frame_data->virtual_irq;
> + else
> + irq = frame_data->irq;
> + }
> +
> + if (!base) {
> + pr_err("Can't map frame's registers\n");
> + return -ENXIO;
> + }
> + if (!irq) {
> + pr_err("Frame missing %s irq",
> + arch_timer_mem_use_virtual ? "virt" : "phys");
> + ret = -EINVAL;
> + goto out;
> + }
> +
> + arch_counter_base = base;
>
> t = kzalloc(sizeof(*t), GFP_KERNEL);
> - if (!t)
> + if (!t) {
> return -ENOMEM;
^
my bad, it should be "ret = "
> + goto out;
> + }
>
> t->base = base;
> t->evt.irq = irq;
> @@ -676,11 +718,13 @@ static int __init arch_timer_mem_register(void __iomem *base, unsigned int irq)
> func = arch_timer_handler_phys_mem;
>
> ret = request_irq(irq, func, IRQF_TIMER, "arch_mem_timer", &t->evt);
> - if (ret) {
> - pr_err("Failed to request mem timer irq\n");
> - kfree(t);
> - }
> + if (!ret)
> + return 0;
>
> + pr_err("Failed to request mem timer irq\n");
> + kfree(t);
> +out:
> + iounmap(base);
> return ret;
> }
>
> @@ -769,7 +813,7 @@ static int __init arch_timer_init(void)
> return ret;
>
> arch_timer_kvm_info.virtual_irq = arch_timer_ppi[VIRT_PPI];
> -
> +
> return 0;
> }
>
> @@ -803,21 +847,56 @@ static int __init arch_timer_of_init(struct device_node *np)
> CLOCKSOURCE_OF_DECLARE(armv7_arch_timer, "arm,armv7-timer", arch_timer_of_init);
> CLOCKSOURCE_OF_DECLARE(armv8_arch_timer, "arm,armv8-timer", arch_timer_of_init);
>
> -static int __init arch_timer_mem_init(struct device_node *np)
> +static int __init get_cnttidr(struct device_node *np,
> + struct gt_block_data *gt_block, u32 *cnttidr)
> {
> - struct device_node *frame, *best_frame = NULL;
> - void __iomem *cntctlbase, *base;
> - unsigned int irq, ret = -EINVAL;
> - u32 cnttidr;
> + if (np)
> + cntctlbase = of_iomap(np, 0);
> + else
> + cntctlbase = ioremap(gt_block->cntctlbase_phy, SZ_4K);
> + /*
> + * According to ARMv8 Architecture Reference Manual(ARM),
> + * the size of CNTCTLBase frame of memory-mapped timer
> + * is SZ_4K(Offset 0x000 ? 0xFFF).
> + */
>
> - arch_timers_present |= ARCH_MEM_TIMER;
> - cntctlbase = of_iomap(np, 0);
> if (!cntctlbase) {
> pr_err("Can't find CNTCTLBase\n");
> return -ENXIO;
> }
>
> - cnttidr = readl_relaxed(cntctlbase + CNTTIDR);
> + *cnttidr = readl_relaxed(cntctlbase + CNTTIDR);
> + return 0;
> +}
> +
> +static bool __init is_best_frame(u32 cnttidr, int n)
> +{
> + u32 cntacr = CNTACR_RFRQ | CNTACR_RWPT | CNTACR_RPCT | CNTACR_RWVT |
> + CNTACR_RVOFF | CNTACR_RVCT;
> +
> + /* Try enabling everything, and see what sticks */
> + writel_relaxed(cntacr, cntctlbase + CNTACR(n));
> + cntacr = readl_relaxed(cntctlbase + CNTACR(n));
> +
> + if ((cnttidr & CNTTIDR_VIRT(n)) &&
> + !(~cntacr & (CNTACR_RWVT | CNTACR_RVCT)))
> + arch_timer_mem_use_virtual = true;
> + else if (~cntacr & (CNTACR_RWPT | CNTACR_RPCT))
> + return false;
> +
> + return true;
> +}
> +
> +static int __init arch_timer_mem_init(struct device_node *np)
> +{
> + struct device_node *frame, *best_frame = NULL;
> + unsigned int ret = -EINVAL;
> + u32 cnttidr;
> +
> + arch_timers_present |= ARCH_MEM_TIMER;
> +
> + if (get_cnttidr(np, NULL, &cnttidr))
> + return -ENXIO;
>
> /*
> * Try to find a virtual capable frame. Otherwise fall back to a
> @@ -825,60 +904,22 @@ static int __init arch_timer_mem_init(struct device_node *np)
> */
> for_each_available_child_of_node(np, frame) {
> int n;
> - u32 cntacr;
> -
> if (of_property_read_u32(frame, "frame-number", &n)) {
> - pr_err("Missing frame-number\n");
> + pr_err("Missing frame-number.\n");
> of_node_put(frame);
> goto out;
> }
> -
> - /* Try enabling everything, and see what sticks */
> - cntacr = CNTACR_RFRQ | CNTACR_RWPT | CNTACR_RPCT |
> - CNTACR_RWVT | CNTACR_RVOFF | CNTACR_RVCT;
> - writel_relaxed(cntacr, cntctlbase + CNTACR(n));
> - cntacr = readl_relaxed(cntctlbase + CNTACR(n));
> -
> - if ((cnttidr & CNTTIDR_VIRT(n)) &&
> - !(~cntacr & (CNTACR_RWVT | CNTACR_RVCT))) {
> + if (is_best_frame(cnttidr, n)) {
> of_node_put(best_frame);
> - best_frame = frame;
> - arch_timer_mem_use_virtual = true;
> - break;
> + best_frame = of_node_get(frame);
> + if (arch_timer_mem_use_virtual)
> + break;
> }
> -
> - if (~cntacr & (CNTACR_RWPT | CNTACR_RPCT))
> - continue;
> -
> - of_node_put(best_frame);
> - best_frame = of_node_get(frame);
> - }
> -
> - ret= -ENXIO;
> - base = arch_counter_base = of_iomap(best_frame, 0);
> - if (!base) {
> - pr_err("Can't map frame's registers\n");
> - goto out;
> - }
> -
> - if (arch_timer_mem_use_virtual)
> - irq = irq_of_parse_and_map(best_frame, VIRT_SPI);
> - else
> - irq = irq_of_parse_and_map(best_frame, PHYS_SPI);
> -
> - ret = -EINVAL;
> - if (!irq) {
> - pr_err("Frame missing %s irq",
> - arch_timer_mem_use_virtual ? "virt" : "phys");
> - goto out;
> }
>
> - arch_timer_detect_rate(base, np);
> - ret = arch_timer_mem_register(base, irq);
> - if (ret)
> - goto out;
> -
> - return arch_timer_common_init();
> + ret = arch_timer_mem_register(np, best_frame);
> + if (!ret)
> + ret = arch_timer_common_init();
> out:
> iounmap(cntctlbase);
> of_node_put(best_frame);
> @@ -888,7 +929,72 @@ CLOCKSOURCE_OF_DECLARE(armv7_arch_timer_mem, "arm,armv7-timer-mem",
> arch_timer_mem_init);
>
> #ifdef CONFIG_ACPI_GTDT
> -/* Initialize per-processor generic timer */
> +static struct gt_timer_data __init *arch_timer_mem_get_timer(
> + struct gt_block_data *gt_blocks)
> +{
> + struct gt_block_data *gt_block = gt_blocks;
> + struct gt_timer_data *best_frame = NULL;
> + u32 cnttidr;
> + int i;
> +
> + if (get_cnttidr(NULL, gt_block, &cnttidr))
> + return NULL;
> + /*
> + * Try to find a virtual capable frame. Otherwise fall back to a
> + * physical capable frame.
> + */
> + for (i = 0; i < gt_block->timer_count; i++) {
> + if (is_best_frame(cnttidr, gt_block->timer[i].frame_nr)) {
> + best_frame = >_block->timer[i];
> + if (arch_timer_mem_use_virtual)
> + break;
> + }
> + }
> + iounmap(cntctlbase);
> +
> + return best_frame;
> +}
> +
> +static int __init arch_timer_mem_acpi_init(size_t timer_count)
> +{
> + struct gt_block_data *gt_blocks;
> + struct gt_timer_data *gt_timer;
> + int ret = -EINVAL;
> +
> + /*
> + * If we don't have any Platform Timer Structures, just return.
> + */
> + if (!timer_count)
> + return 0;
> +
> + /*
> + * before really check all the Platform Timer Structures,
> + * we assume they are GT block, and allocate memory for them.
> + * We will free these memory once we finish the initialization.
> + */
> + gt_blocks = kcalloc(timer_count, sizeof(*gt_blocks), GFP_KERNEL);
> + if (!gt_blocks)
> + return -ENOMEM;
> +
> + if (gtdt_arch_timer_mem_init(gt_blocks) > 0) {
> + gt_timer = arch_timer_mem_get_timer(gt_blocks);
> + if (!gt_timer) {
> + pr_err("Failed to get mem timer info.\n");
> + goto error;
> + }
> + ret = arch_timer_mem_register(NULL, gt_timer);
> + if (ret) {
> + pr_err("Failed to register mem timer.\n");
> + goto error;
> + }
> + }
> + arch_timers_present |= ARCH_MEM_TIMER;
> +error:
> + kfree(gt_blocks);
> + return ret;
> +}
> +
> +/* Initialize per-processor generic timer and memory-mapped timer(if present) */
> static int __init arch_timer_acpi_init(struct acpi_table_header *table)
> {
> int timer_count;
> @@ -912,8 +1018,8 @@ static int __init arch_timer_acpi_init(struct acpi_table_header *table)
> /* Get the frequency from CNTFRQ */
> arch_timer_detect_rate(NULL, NULL);
>
> - if (timer_count < 0)
> - pr_err("Failed to get platform timer info.\n");
> + if (timer_count < 0 || arch_timer_mem_acpi_init((size_t)timer_count))
> + pr_err("Failed to initialize memory-mapped timer.\n");
>
> return arch_timer_init();
> }
> --
> 2.7.4
>
--
Best regards,
Fu Wei
Software Engineer
Red Hat
^ permalink raw reply
* [GIT PULL] Greybus driver subsystem for 4.9-rc1
From: Bryan O'Donoghue @ 2016-09-15 10:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473935756.10230.42.camel@nexus-software.ie>
On Thu, 2016-09-15 at 11:35 +0100, Bryan O'Donoghue wrote:
>
Here's a slightly better diagram.
PMIC -> refclk provided to each (timer) element below.
MSM8994(timer) -- > USB
WD8a
? ? ? ? ? ? ? ?APBridgeA (timer) -> UniPro bus
? ? ? ? ? ? ? ?WD8a
????????????????????????????????????????????-> Module(timer) with UART
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?WD1
????????????????????????????????????????????-> Module(timer) with GPIO
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?WD2
????????????????????????????????????????????-> Module(timer) with blah
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?WD3
??????????????????????????????-> SPI bus
????????????????????????????????????????????-> SVC(timer)
???????????????????????????????????????????????Owns FrameTime
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?GPIO {WD0...WDn}
So yes, each processor has it's own timer. We aren't trying to read the
MSM's FrameTime.
---
bod
^ permalink raw reply
* [PATCH 7/7] mfd: cros_ec_spi: Remove unused variable 'request'
From: Lee Jones @ 2016-09-15 10:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915104521.14286-1-lee.jones@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
drivers/mfd/cros_ec_spi.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/mfd/cros_ec_spi.c
index ebe9b94..a518832 100644
--- a/drivers/mfd/cros_ec_spi.c
+++ b/drivers/mfd/cros_ec_spi.c
@@ -366,7 +366,6 @@ static int cros_ec_spi_receive_response(struct cros_ec_device *ec_dev,
static int cros_ec_pkt_xfer_spi(struct cros_ec_device *ec_dev,
struct cros_ec_command *ec_msg)
{
- struct ec_host_request *request;
struct ec_host_response *response;
struct cros_ec_spi *ec_spi = ec_dev->priv;
struct spi_transfer trans, trans_delay;
@@ -378,7 +377,6 @@ static int cros_ec_pkt_xfer_spi(struct cros_ec_device *ec_dev,
int ret = 0, final_ret;
len = cros_ec_prepare_tx(ec_dev, ec_msg);
- request = (struct ec_host_request *)ec_dev->dout;
dev_dbg(ec_dev->dev, "prepared, len=%d\n", len);
/* If it's too soon to do another transaction, wait */
--
2.9.3
^ permalink raw reply related
* [PATCH 6/7] mfd: omap-usb-host: Return value is not 'const int'
From: Lee Jones @ 2016-09-15 10:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915104521.14286-1-lee.jones@linaro.org>
Change from 'const int' to just 'int'.
Cc: <robh+dt@kernel.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
drivers/mfd/omap-usb-host.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 1d924d1..7aab376 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -162,7 +162,7 @@ static const char * const port_modes[] = {
* provided port mode string as per the port_modes table.
* If no match is found it returns -ENODEV
*/
-static const int omap_usbhs_get_dt_port_mode(const char *mode)
+static int omap_usbhs_get_dt_port_mode(const char *mode)
{
int i;
--
2.9.3
^ permalink raw reply related
* [PATCH 5/7] mfd: ab8500-debugfs: Remove 'weak' function suspend_test_wake_cause_interrupt_is_mine()
From: Lee Jones @ 2016-09-15 10:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915104521.14286-1-lee.jones@linaro.org>
There are no other functions which can over-ride it.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
drivers/mfd/ab8500-debugfs.c | 10 +---------
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/drivers/mfd/ab8500-debugfs.c b/drivers/mfd/ab8500-debugfs.c
index b948088..acf6c00 100644
--- a/drivers/mfd/ab8500-debugfs.c
+++ b/drivers/mfd/ab8500-debugfs.c
@@ -1522,18 +1522,10 @@ static u32 num_interrupts[AB8500_MAX_NR_IRQS];
static u32 num_wake_interrupts[AB8500_MAX_NR_IRQS];
static int num_interrupt_lines;
-bool __attribute__((weak)) suspend_test_wake_cause_interrupt_is_mine(u32 my_int)
-{
- return false;
-}
-
void ab8500_debug_register_interrupt(int line)
{
- if (line < num_interrupt_lines) {
+ if (line < num_interrupt_lines)
num_interrupts[line]++;
- if (suspend_test_wake_cause_interrupt_is_mine(irq_ab8500))
- num_wake_interrupts[line]++;
- }
}
static int ab8500_interrupts_print(struct seq_file *s, void *p)
--
2.9.3
^ permalink raw reply related
* [PATCH 4/7] mfd: ab8500-debugfs: Remove ab8500_dump_all_banks_to_mem()
From: Lee Jones @ 2016-09-15 10:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915104521.14286-1-lee.jones@linaro.org>
Doesn't appear to be used. No call sites exist.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
drivers/mfd/ab8500-debugfs.c | 54 --------------------------------------------
1 file changed, 54 deletions(-)
diff --git a/drivers/mfd/ab8500-debugfs.c b/drivers/mfd/ab8500-debugfs.c
index 6c913c4..b948088 100644
--- a/drivers/mfd/ab8500-debugfs.c
+++ b/drivers/mfd/ab8500-debugfs.c
@@ -1374,60 +1374,6 @@ void ab8500_dump_all_banks(struct device *dev)
}
}
-/* Space for 500 registers. */
-#define DUMP_MAX_REGS 700
-static struct ab8500_register_dump
-{
- u8 bank;
- u8 reg;
- u8 value;
-} ab8500_complete_register_dump[DUMP_MAX_REGS];
-
-/* This shall only be called upon kernel panic! */
-void ab8500_dump_all_banks_to_mem(void)
-{
- int i, r = 0;
- u8 bank;
- int err = 0;
-
- pr_info("Saving all ABB registers for crash analysis.\n");
-
- for (bank = 0; bank < AB8500_NUM_BANKS; bank++) {
- for (i = 0; i < debug_ranges[bank].num_ranges; i++) {
- u8 reg;
-
- for (reg = debug_ranges[bank].range[i].first;
- reg <= debug_ranges[bank].range[i].last;
- reg++) {
- u8 value;
-
- err = prcmu_abb_read(bank, reg, &value, 1);
-
- if (err < 0)
- goto out;
-
- ab8500_complete_register_dump[r].bank = bank;
- ab8500_complete_register_dump[r].reg = reg;
- ab8500_complete_register_dump[r].value = value;
-
- r++;
-
- if (r >= DUMP_MAX_REGS) {
- pr_err("%s: too many register to dump!\n",
- __func__);
- err = -EINVAL;
- goto out;
- }
- }
- }
- }
-out:
- if (err >= 0)
- pr_info("Saved all ABB registers.\n");
- else
- pr_info("Failed to save all ABB registers.\n");
-}
-
static int ab8500_all_banks_open(struct inode *inode, struct file *file)
{
struct seq_file *s;
--
2.9.3
^ permalink raw reply related
* [PATCH 3/7] mfd: db8500-prcmu: Remove unused *prcmu_set_ddr_opp() calls
From: Lee Jones @ 2016-09-15 10:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915104521.14286-1-lee.jones@linaro.org>
There are no call sites for these functions. Strip them out.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
drivers/mfd/db8500-prcmu.c | 19 -------------------
include/linux/mfd/db8500-prcmu.h | 6 ------
include/linux/mfd/dbx500-prcmu.h | 9 ---------
3 files changed, 34 deletions(-)
diff --git a/drivers/mfd/db8500-prcmu.c b/drivers/mfd/db8500-prcmu.c
index 388e268..ca38a6a 100644
--- a/drivers/mfd/db8500-prcmu.c
+++ b/drivers/mfd/db8500-prcmu.c
@@ -938,25 +938,6 @@ int db8500_prcmu_get_ddr_opp(void)
return readb(PRCM_DDR_SUBSYS_APE_MINBW);
}
-/**
- * db8500_set_ddr_opp - set the appropriate DDR OPP
- * @opp: The new DDR operating point to which transition is to be made
- * Returns: 0 on success, non-zero on failure
- *
- * This function sets the operating point of the DDR.
- */
-static bool enable_set_ddr_opp;
-int db8500_prcmu_set_ddr_opp(u8 opp)
-{
- if (opp < DDR_100_OPP || opp > DDR_25_OPP)
- return -EINVAL;
- /* Changing the DDR OPP can hang the hardware pre-v21 */
- if (enable_set_ddr_opp)
- writeb(opp, PRCM_DDR_SUBSYS_APE_MINBW);
-
- return 0;
-}
-
/* Divide the frequency of certain clocks by 2 for APE_50_PARTLY_25_OPP. */
static void request_even_slower_clocks(bool enable)
{
diff --git a/include/linux/mfd/db8500-prcmu.h b/include/linux/mfd/db8500-prcmu.h
index 0bd6944..7ba67b5 100644
--- a/include/linux/mfd/db8500-prcmu.h
+++ b/include/linux/mfd/db8500-prcmu.h
@@ -538,7 +538,6 @@ int db8500_prcmu_get_arm_opp(void);
int db8500_prcmu_set_ape_opp(u8 opp);
int db8500_prcmu_get_ape_opp(void);
int db8500_prcmu_request_ape_opp_100_voltage(bool enable);
-int db8500_prcmu_set_ddr_opp(u8 opp);
int db8500_prcmu_get_ddr_opp(void);
u32 db8500_prcmu_read(unsigned int reg);
@@ -594,11 +593,6 @@ static inline int prcmu_release_usb_wakeup_state(void)
return 0;
}
-static inline int db8500_prcmu_set_ddr_opp(u8 opp)
-{
- return 0;
-}
-
static inline int db8500_prcmu_get_ddr_opp(void)
{
return DDR_100_OPP;
diff --git a/include/linux/mfd/dbx500-prcmu.h b/include/linux/mfd/dbx500-prcmu.h
index 5d37460..2e2c6a6 100644
--- a/include/linux/mfd/dbx500-prcmu.h
+++ b/include/linux/mfd/dbx500-prcmu.h
@@ -269,10 +269,6 @@ unsigned long prcmu_clock_rate(u8 clock);
long prcmu_round_clock_rate(u8 clock, unsigned long rate);
int prcmu_set_clock_rate(u8 clock, unsigned long rate);
-static inline int prcmu_set_ddr_opp(u8 opp)
-{
- return db8500_prcmu_set_ddr_opp(opp);
-}
static inline int prcmu_get_ddr_opp(void)
{
return db8500_prcmu_get_ddr_opp();
@@ -489,11 +485,6 @@ static inline int prcmu_get_arm_opp(void)
return ARM_100_OPP;
}
-static inline int prcmu_set_ddr_opp(u8 opp)
-{
- return 0;
-}
-
static inline int prcmu_get_ddr_opp(void)
{
return DDR_100_OPP;
--
2.9.3
^ permalink raw reply related
* [PATCH 2/7] mfd: ab8500-debugfs: Prevent initialised field from being over-written
From: Lee Jones @ 2016-09-15 10:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915104521.14286-1-lee.jones@linaro.org>
Due to the lack of parity in the way array fields have been named/
numbered, a mistake was made where more debug fields were declared
than actually existed. In doing so, 2 fields were added, which
although unclear, were already declared in the array. The result
was that the latter declarations trashed the former ones.
This patch places the array back in the correct order and removes
the offending NULL entries.
While we're at it, let's ensure this doesn't happen again by naming
each field properly and add a new *_LAST define to describe how
many fields there should be.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
drivers/mfd/ab8500-debugfs.c | 50 ++++++++++++++++-----------------------
include/linux/mfd/abx500/ab8500.h | 2 ++
2 files changed, 23 insertions(+), 29 deletions(-)
diff --git a/drivers/mfd/ab8500-debugfs.c b/drivers/mfd/ab8500-debugfs.c
index 0aecd7b..6c913c4 100644
--- a/drivers/mfd/ab8500-debugfs.c
+++ b/drivers/mfd/ab8500-debugfs.c
@@ -153,14 +153,14 @@ static struct hwreg_cfg hwreg_cfg = {
#define AB8500_NAME_STRING "ab8500"
#define AB8500_ADC_NAME_STRING "gpadc"
-#define AB8500_NUM_BANKS 24
+#define AB8500_NUM_BANKS AB8500_DEBUG_FIELD_LAST
#define AB8500_REV_REG 0x80
static struct ab8500_prcmu_ranges *debug_ranges;
static struct ab8500_prcmu_ranges ab8500_debug_ranges[AB8500_NUM_BANKS] = {
- [0x0] = {
+ [AB8500_M_FSM_RANK] = {
.num_ranges = 0,
.range = NULL,
},
@@ -315,7 +315,7 @@ static struct ab8500_prcmu_ranges ab8500_debug_ranges[AB8500_NUM_BANKS] = {
},
},
},
- [0x9] = {
+ [AB8500_RESERVED] = {
.num_ranges = 0,
.range = NULL,
},
@@ -386,24 +386,6 @@ static struct ab8500_prcmu_ranges ab8500_debug_ranges[AB8500_NUM_BANKS] = {
},
},
},
- [AB8500_DEVELOPMENT] = {
- .num_ranges = 1,
- .range = (struct ab8500_reg_range[]) {
- {
- .first = 0x00,
- .last = 0x00,
- },
- },
- },
- [AB8500_DEBUG] = {
- .num_ranges = 1,
- .range = (struct ab8500_reg_range[]) {
- {
- .first = 0x05,
- .last = 0x07,
- },
- },
- },
[AB8500_AUDIO] = {
.num_ranges = 1,
.range = (struct ab8500_reg_range[]) {
@@ -463,19 +445,29 @@ static struct ab8500_prcmu_ranges ab8500_debug_ranges[AB8500_NUM_BANKS] = {
},
},
},
- [0x11] = {
- .num_ranges = 0,
- .range = NULL,
+ [AB8500_DEVELOPMENT] = {
+ .num_ranges = 1,
+ .range = (struct ab8500_reg_range[]) {
+ {
+ .first = 0x00,
+ .last = 0x00,
+ },
+ },
},
- [0x12] = {
- .num_ranges = 0,
- .range = NULL,
+ [AB8500_DEBUG] = {
+ .num_ranges = 1,
+ .range = (struct ab8500_reg_range[]) {
+ {
+ .first = 0x05,
+ .last = 0x07,
+ },
+ },
},
- [0x13] = {
+ [AB8500_PROD_TEST] = {
.num_ranges = 0,
.range = NULL,
},
- [0x14] = {
+ [AB8500_STE_TEST] = {
.num_ranges = 0,
.range = NULL,
},
diff --git a/include/linux/mfd/abx500/ab8500.h b/include/linux/mfd/abx500/ab8500.h
index 9475fee..d33c245 100644
--- a/include/linux/mfd/abx500/ab8500.h
+++ b/include/linux/mfd/abx500/ab8500.h
@@ -63,6 +63,8 @@ enum ab8500_version {
#define AB8500_STE_TEST 0x14
#define AB8500_OTP_EMUL 0x15
+#define AB8500_DEBUG_FIELD_LAST 0x16
+
/*
* Interrupts
* Values used to index into array ab8500_irq_regoffset[] defined in
--
2.9.3
^ permalink raw reply related
* [PATCH 1/7] mfd: max8997-irq: 'inline' should be at the beginning of the declaration
From: Lee Jones @ 2016-09-15 10:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915104521.14286-1-lee.jones@linaro.org>
Reported by [-Wold-style-declaration].
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
drivers/mfd/max8997-irq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mfd/max8997-irq.c b/drivers/mfd/max8997-irq.c
index b95a46d7..326f17b 100644
--- a/drivers/mfd/max8997-irq.c
+++ b/drivers/mfd/max8997-irq.c
@@ -139,7 +139,7 @@ static void max8997_irq_sync_unlock(struct irq_data *data)
mutex_unlock(&max8997->irqlock);
}
-static const inline struct max8997_irq_data *
+inline static const struct max8997_irq_data *
irq_to_max8997_irq(struct max8997_dev *max8997, struct irq_data *data)
{
return &max8997_irqs[data->hwirq];
--
2.9.3
^ permalink raw reply related
* [PATCH 0/7] mfd: Fix all W=1 warnings
From: Lee Jones @ 2016-09-15 10:45 UTC (permalink / raw)
To: linux-arm-kernel
It really is as simple as it sounds!
Lee Jones (7):
mfd: max8997-irq: 'inline' should be at the beginning of the
declaration
mfd: ab8500-debugfs: Prevent initialised field from being over-written
mfd: db8500-prcmu: Remove unused *prcmu_set_ddr_opp() calls
mfd: ab8500-debugfs: Remove ab8500_dump_all_banks_to_mem()
mfd: ab8500-debugfs: Remove 'weak' function
suspend_test_wake_cause_interrupt_is_mine()
mfd: omap-usb-host: Return value is not 'const int'
mfd: cros_ec_spi: Remove unused variable 'request'
drivers/mfd/ab8500-debugfs.c | 114 ++++++++------------------------------
drivers/mfd/cros_ec_spi.c | 2 -
drivers/mfd/db8500-prcmu.c | 19 -------
drivers/mfd/max8997-irq.c | 2 +-
drivers/mfd/omap-usb-host.c | 2 +-
include/linux/mfd/abx500/ab8500.h | 2 +
include/linux/mfd/db8500-prcmu.h | 6 --
include/linux/mfd/dbx500-prcmu.h | 9 ---
8 files changed, 26 insertions(+), 130 deletions(-)
--
2.9.3
^ permalink raw reply
* [PATCH] soc: rockchip: power-domain: Handle errors from of_genpd_add_provider_onecell
From: Tomeu Vizoso @ 2016-09-15 10:43 UTC (permalink / raw)
To: linux-arm-kernel
It was a bit surprising that the device was reported to have probed just
fine, but the provider hadn't been registered.
So handle any errors when registering the provider and fail the probe
accordingly.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Cc: Caesar Wang <wxt@rock-chips.com>
---
drivers/soc/rockchip/pm_domains.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/soc/rockchip/pm_domains.c b/drivers/soc/rockchip/pm_domains.c
index 7acd1517dd37..57e920128cb2 100644
--- a/drivers/soc/rockchip/pm_domains.c
+++ b/drivers/soc/rockchip/pm_domains.c
@@ -627,7 +627,11 @@ static int rockchip_pm_domain_probe(struct platform_device *pdev)
goto err_out;
}
- of_genpd_add_provider_onecell(np, &pmu->genpd_data);
+ error = of_genpd_add_provider_onecell(np, &pmu->genpd_data);
+ if (error) {
+ dev_err(dev, "failed to add provider: %d\n", error);
+ goto err_out;
+ }
return 0;
--
2.7.4
^ permalink raw reply related
* [RESEND PATCH] arm64: kgdb: fix single stepping
From: Daniel Thompson @ 2016-09-15 10:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915075617.GJ16712@linaro.org>
On 15/09/16 08:56, AKASHI Takahiro wrote:
> On Wed, Sep 14, 2016 at 03:58:51PM +0100, Will Deacon wrote:
>> Hi Akashi,
>>
>> On Tue, Apr 21, 2015 at 02:13:13AM +0100, AKASHI Takahiro wrote:
>>> Could you please review my patch below?
>>> See also arm64 maintainer's comment:
>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/313712.html
>>
>> -ETIMEDOUT waiting for the kdgb folk to comment. Ppeople have reported
>> that this patch is required for kgdb to work correctly on arm64, so I'm
>> happy to merge it.
>
> I'm happy, too.
I'll keep an eye out and FWIW see if I can throw in a review. I'm not
really one of "kgdb folk" but did examine it fairly deeply in the early
stages of the FIQ/NMI work (and which has since stopped focussing on kgdb).
I have some equally elderly, albeit rather less critical, kdb patches
that I should have pushed harder for so I'm sympathetic here ;-)
Daniel.
>> However, as detailed in your comment log:
>>
>>> This patch
>>> (1) moves kgdb_disable_single_step() from 'c' command handling to single
>>> step handler.
>>> This makes sure that single stepping gets effective at every 's' command.
>>> Please note that, under the current implementation, single step bit in
>>> spsr, which is cleared by the first single stepping, will not be set
>>> again for the consecutive 's' commands because single step bit in mdscr
>>> is still kept on (that is, kernel_active_single_step() in
>>> kgdb_arch_handle_exception() is true).
>>> (2) re-implements kgdb_roundup_cpus() because the current implementation
>>> enabled interrupts naively. See below.
>>> (3) removes 'enable_dbg' in el1_dbg.
>>> Single step bit in mdscr is turned on in do_handle_exception()->
>>> kgdb_handle_expection() before returning to debugged context, and if
>>> debug exception is enabled in el1_dbg, we will see unexpected single-
>>> stepping in el1_dbg.
>>> Since v3.18, the following patch does the same:
>>> commit 1059c6bf8534 ("arm64: debug: don't re-enable debug exceptions
>>> on return from el1_dbg)
>>> (4) masks interrupts while single-stepping one instruction.
>>> If an interrupt is caught during processing a single-stepping, debug
>>> exception is unintentionally enabled by el1_irq's 'enable_dbg' before
>>> returning to debugged context.
>>> Thus, like in (2), we will see unexpected single-stepping in el1_irq.
>>
>> this patch is doing *far* too much in one go. Could you please repost it
>> as a series of self-contained fixes with clear commit messages, so I can
>> queue them and cc stable where appropriate?
>
> Sure, but I need to refresh my memory here.
>
> -Takahiro AKASHI
>
>> Thanks,
>>
>> Will
^ permalink raw reply
* [GIT PULL] Greybus driver subsystem for 4.9-rc1
From: Bryan O'Donoghue @ 2016-09-15 10:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915101330.GB6718@leverpostej>
On Thu, 2016-09-15 at 11:13 +0100, Mark Rutland wrote:
> On Thu, Sep 15, 2016 at 10:35:33AM +0100, Bryan O'Donoghue wrote:
> >?
> I don't think the history matters,
Your comment seemed to indicate you thought we were reading a
architectural timer directly - which we aren't.
> and I don't think that one can rely
> on get_cycles() in this manner outside of arch code.
I don't follow your meaning. What's wrong with get_cycles() ? You've
already said you don't think reading an architectural timer directly is
correct.
The objective is to read one of the free-running counters in MSM8994,
clocked by the PMIC. The refclk provided by PMIC is distributed to each
processor in the system.
> Looking at the
> state of the tree [1] as of the final commit [2] in the greybus
> branch,
> my points still stand:
>
> * The "google,greybus-frame-time-counter" node is superfluous. It
> does
> ? not describe a particular device,
It describes a timer running @ 19.2MHz, clocked by PMIC refclk.
> and duplicates information we have
> ? elsewhere.
Can you give an example ?
> It does not explicitly define the relationship with the
> ? underlying clocksource.
> * The clock-frequency property isn't necessary. The architected timer
> ? drivers know the frequency of the architected timers (MMIO or
> sysreg),
> ? and they should be queried as to the frequency.
OK so if I'm understanding you. You think get_cycles() is fine but that
instead of encoding a "greybus-frame-time-counter" the platform code
should interrogate the frequency provided - is that correct ?
> Beyond that, the fallback code using cpufreq and presumably an actual
> cycle counter will be broken in a number of cases
Of course the fallback will be broken... it's not supposed to work if
you don't have a timer that can be used - just compile, run and print a
complaint - i.e., this won't really do FrameTime on an x86... then
again since so much of the underlying greybus/unipro hardware -
requires a 19.2MHz refclk - if you were to try to do greybus on x86
you'd need to solve that problem.
>
> Per the comment at the top of the file, it looks like you want a
> system-wide stable clocksource. If you want that, you need to use a
> generic API that allows drivers and arch code to actually provide
> that,
> rather than building one yourself that doesn't work.
Hmm. The objective is to read one of the timers clocked by the PMIC
refclk input. refclk is provided to each processor in the system - and
on MSM8994 clocks the MMIO timers. It's used to drive the PLL on the
other processors - which in turn drive the timers that the Modules use
to read their own local counters. We want to read that counter on MSM
directly - get_cycles() has worked nicely so far.
>
> If you're trying to synchronise with other agents in the system that
> are
> reading from the MMIO arch timers,
No. The MMIO timers are useful only to the MSM. We don't have any type
of parallel (or serial) bus that can access that on-chip resource.
MSM8994 -- > USB
? ? ? ? ? ? ?APBridge (timer) -> UniPro bus
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? -> Module with a UART
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? -> Module with a GPIO
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? -> Module with an etc, etc
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? -> SPI bus
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? -> SVC
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Owns FrameTime
So the SVC owns FrameTime and diseminates that to other entities in the
system by way of a GPIO and greybus. It's up to the MSM8994 to select a
timer that works for it - the other processors in the system are
responsible for their own timers.
---
bod
^ permalink raw reply
* [PATCH v4 00/10] ARM: KVM: Support for vgic-v3
From: Vladimir Murzin @ 2016-09-15 10:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915091334.GB23629@cbox>
Hi Christoffer,
On 15/09/16 10:13, Christoffer Dall wrote:
> Hi Valdimir,
>
> On Mon, Sep 12, 2016 at 03:49:14PM +0100, Vladimir Murzin wrote:
>> Hi,
>>
>> This is an attempt to make use vgic-v3 under arch/arm since
>> save-restore functionality got re-written in C and can be shared
>> between arm/arm64 like it has already been done for vgic-v2 and timer.
>>
>> With this patches I'm able to get 32 core an AArch32 ARMv8 guest boot:
>>
>> ...
>> GICv3: CPU31: found redistributor 703 region 0:0x000000003ffd0000
>> CPU31: thread -1, cpu 3, socket 7, mpidr 80000703
>> Brought up 32 CPUs
>> SMP: Total of 32 processors activated (768.00 BogoMIPS).
>> CPU: All CPU(s) started in SVC mode.
>> ...
>>
>> Additionally, quite lightweight test based on Self IPI guest test[1]
>> has been run with up to 255 cpus.
>>
> I have applied this to kvmarm/queue, fixing up a few trivial conflicts,
> and I have changed the kvm_info message.
Great!
>
> If you could test the integrated branch with GICv3 on a 32-bit platform,
> that would be great.
I've just pulled kvmarm/queue and started testing.
>
> I'll give people a few days to give their acks to the non-KVM part of
> the series and will then put it in next.
>
Thanks!
Vladimir
> Thanks for the work,
> -Christoffer
>
>
^ permalink raw reply
* [PATCH] BUG: atmel_serial: Interrupts not disabled on close
From: Greg Kroah-Hartman @ 2016-09-15 10:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c98f5e6a-a971-aee1-cd9b-16a2ef36d9f8@atmel.com>
On Mon, Sep 12, 2016 at 05:22:58PM +0200, Nicolas Ferre wrote:
> Le 12/09/2016 ? 15:34, Richard Genoud a ?crit :
> > Since commit 18dfef9c7f87 ("serial: atmel: convert to irq handling
> > provided mctrl-gpio"), interrupts from GPIOs are not disabled any more
> > when the serial port is closed, leading to an oops when the one of the
> > input pin is toggled (CTS/DSR/DCD/RNG).
> >
> > This is only the case if those pins are used as GPIOs, i.e. declared
> > like that:
> > usart1: serial at f8020000 {
> > /* CTS and DTS will be handled by GPIO */
> > status = "okay";
> > rts-gpios = <&pioB 17 GPIO_ACTIVE_LOW>;
> > cts-gpios = <&pioB 16 GPIO_ACTIVE_LOW>;
> > dtr-gpios = <&pioB 14 GPIO_ACTIVE_LOW>;
> > dsr-gpios = <&pioC 31 GPIO_ACTIVE_LOW>;
> > rng-gpios = <&pioB 12 GPIO_ACTIVE_LOW>;
> > dcd-gpios = <&pioB 15 GPIO_ACTIVE_LOW>;
> > };
> >
> > That's because modem interrupts used to be freed in atmel_shutdown().
> > After commit 18dfef9c7f87 ("serial: atmel: convert to irq handling
> > provided mctrl-gpio"), this code was just removed.
> > Calling atmel_disable_ms() disables the interrupts and everything works
> > fine again.
> >
> > Tested on at91sam9g35-cm
> >
> > (This patch doesn't apply on -stable kernels, fixes for 4.4 and 4.7 will
> > be sent after this one is applied.)
> >
> > Signed-off-by: Richard Genoud <richard.genoud@gmail.com>
> > Fixes: 18dfef9c7f87 ("serial: atmel: convert to irq handling provided mctrl-gpio")
>
> I thinks it's a bit late for "4.8-fixes".
>
> Greg, tell me if you want that I add the Cc: stable tag to this patch
> (as advised by Uwe) and re-send?
I'll add it, no worries.
greg k-h
^ permalink raw reply
* [PATCH 4/7] phy: meson: add USB2 PHY support for Meson8b and GXBB
From: Philipp Zabel @ 2016-09-15 10:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFBinCDuj_nHtQ9xs0LMmqZT7Yr9SUw24_H2nAwULT7e9kRXag@mail.gmail.com>
Hi Martin,
Am Mittwoch, den 14.09.2016, 23:23 +0200 schrieb Martin Blumenstingl:
[...]
> > We could add a triggered flag or a counter to struct reset_control, and
> > have reset_control_reset_once do nothing if it is already set /
> > incremented. Since the reset_control goes away with the last consumer,
> > the shared reset line would get triggered again after unbinding both PHY
> > devices.
> I guess that'd do the trick for us:
> - we could use devm_reset_control_get_optional_shared() during probe
> - power_on would then call reset_control_reset()
> - the code in reset_control_reset would be changed: the if
> (WARN_ON(rstc->shared)) would be removed. then we return 0 if
> (rstc->shared && atomic_read(&rstc->shared_triggered)). otherwise we
> proceed with the old logic, except that we use
> atomic_set(&rstc->shared_triggerred, 1) in case of success (if an
> error was returned we leave it as "not triggered").
>
> Let me know if you want me to (at least try to) implement that and send an RFC.
Yes, please give it a try. reset_control_reset should still WARN if the
deassert count is set, and reset_(de)assert should do so if triggered is
set. Mixing the two won't work. And it should be documented that shared
reset_control_reset may do nothing if the reset was already triggered by
another consumer.
regards
Philipp
^ permalink raw reply
* [GIT PULL] Greybus driver subsystem for 4.9-rc1
From: Greg KH @ 2016-09-15 10:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqJtDs-DrPDN4=9ET=EdEDTKxP-gRDkMziimQAz4LG457A@mail.gmail.com>
On Wed, Sep 14, 2016 at 03:07:22PM -0500, Rob Herring wrote:
> On Wed, Sep 14, 2016 at 1:07 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> > On Wed, Sep 14, 2016 at 06:36:26PM +0100, Mark Rutland wrote:
> >> Hi Greg,
> >>
> >> On Wed, Sep 14, 2016 at 12:09:49PM +0200, Greg KH wrote:
> >> > Given that it's never a good idea to keep subsystems out of the mainline
> >> > kernel, I've put together this pull request that adds the greybus driver
> >> > layer to drivers/greybus/. Because this was 2 1/2 years of work, with
> >> > many many developers contributing, I didn't want to flatten all of their
> >> > effort into a few small patches, as that wouldn't be very fair. So I've
> >> > built a git tree with all of the changes going back to the first commit,
> >> > and merged it into the kernel tree, just like btrfs was merged into the
> >> > kernel.
> >>
> >> > Unless people point out some major problems with this, I'd like to get
> >> > it merged into 4.9-rc1.
> >>
> >> I'm extremely concerned that these patches have *never* seen upstream
> >> review, and this pull request gives no real opportunity for people to
> >> make a judgement regarding the code, as many relevant parties have not
> >> been Cc'd.
> >
> > As I said, I will send a set of simple patches, I wanted to get this out
> > as soon as possible and other things came up today. Will do it in the
> > morning, sorry.
> >
> >> From a quick scan of the git tree, I can see code (that isn't even
> >> placed under staging/) for which I have fundamental objections to as a
> >> maintainer, and has not been Cc'd to a relevant list.
> >>
> >> For example, I see commit 5a450477311fbfe2 ("greybus: timesync: Add
> >> timesync core driver"). This states that it directly accesses the ARMv7
> >> architected timer, though it's unclear as to precisely what it's doing
> >> since it introduces an (undocumented) compatible string, and what should
> >> be an unnecessary devicetree property.
> >>
> >> That's never gone to the linux-arm-kernel mainline list, myself or Marc
> >> (as maintainers of the arch timer driver), nor has the binding seen any
> >> review on the devicetree mailing list.
> >
> > Hm, odd, I thought we had Rob review all of the device tree bindings,
> > but maybe the timesync stuff missed him. And timesync is "odd" to say
> > the least, wait until you see the firmware side of it :)
>
> I have not. There weren't any when I was involved (other than SOC
> related bindings). Some like USB devices were discussed at least, but
> at the time there was no common definition of how to deal with
> soldered, on-board USB devices. And that was also what's good enough
> to move forward with development, not ready for mainline. There's a
> binding now for USB, but what's there for arche predates it IIRC. This
> is the first I've heard of timesync having a binding. I can't imagine
> why it needs one.
Ah, I'll let Bryan answer that one :)
> I was going to stay out of this, but now that I'm here...
>
> I'm not all that worried about the quality of the code, but do
> question whether this really makes sense to merge at this time. While
> I worked on Ara and would like to see all this code be used, I'm
> pretty doubtful it will be. Yes, Motorola is using a version of it,
> but they forked it some time back and changed who knows what. So what
> is upstream won't likely even work with any publicly available device.
> And how long that Motorola phone lasts is unknown. Sure it is self
> contained, but maintenance to keep it in tree is not 0.
We have people who are willing to maintain it (me and Johan) and others
on the cc: have expressed interest in doing things with it (Rui has
great ideas about extending gbsim in ways to make it easier to test and
use).
And there is never a restriction on accepting kernel code for "publicly
availble devices only", remember, we have ripped CPU code out of the
kernel for chips that never shipped. It just has to not affect others
in ways that would affect them.
I merge new driver subsystems to the kernel every release that are much
larger than this, and have almost no users out there, so this shouldn't
be a surprise to anyone (who here has a most-bus device? A unisys
visorbus device? MCB device? I can go on :)
And with gbsim, you can run this code today on your laptop, or directly
on a target system like a beagle bone black or minnowboard. There's a
talk about how to use greybus over IP at ELC in a few weeks, and someone
is working on porting the firmware side to an arduino to make it simper
to control the devices on such a target from a host computer using the
greybus protocol.
And getting Motorola to merge back in with this upstream code is a good
goal, having it upstream is a neutral place where everyone can work
together on it. Keeping it in a random github project makes forks
almost inevitable, as we all know.
> There's also things that never got solved. Like how do you describe
> devices on I2C, SPI, UART, etc. behind a greybus device? The plan was
> to use DT overlays, but that was never solved and brings a whole set
> of problems to solve upstream.
That is only an issue if you want to bind a kernel driver for an
existing i2c/spi chip to an i2c/spi greybus device. With the code we
have today, we do it for a specific SPI chip (for firmware download),
but rely on everything to be userspace-only accesses to make it simpler
at this point in time.
When DT overlays get more settled down, yes, I want to revisit this idea
of how to do it for greybus devices, but that's a long-term goal and is
not required at all right now to have a working system and devices.
thanks,
greg k-h
^ permalink raw reply
* [PATCH v7 00/22] Generic DT bindings for PCI IOMMUs and ARM SMMU
From: Robin Murphy @ 2016-09-15 10:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4d87d5f2-0350-b5f8-ffc3-4e9377cf1f87@redhat.com>
On 15/09/16 10:29, Auger Eric wrote:
> Hi Robin,
>
> On 14/09/2016 14:53, Robin Murphy wrote:
>> On 14/09/16 13:32, Auger Eric wrote:
>>> Hi,
>>> On 14/09/2016 12:35, Robin Murphy wrote:
>>>> On 14/09/16 09:41, Auger Eric wrote:
>>>>> Hi,
>>>>>
>>>>> On 12/09/2016 18:13, Robin Murphy wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> To any more confusing fixups and crazily numbered extra patches, here's
>>>>>> a quick v7 with everything rebased into the right order. The significant
>>>>>> change this time is to implement iommu_fwspec properly from the start,
>>>>>> which ends up being far simpler and more robust than faffing about
>>>>>> introducing it somewhere 'less intrusive' to move toward core code later.
>>>>>>
>>>>>> New branch in the logical place:
>>>>>>
>>>>>> git://linux-arm.org/linux-rm iommu/generic-v7
>>>>>
>>>>> For information, as discussed privately with Robin I experience some
>>>>> regressions with the former and now deprecated dt description.
>>>>>
>>>>> on my AMD Overdrive board and my old dt description I now only see a
>>>>> single group:
>>>>>
>>>>> /sys/kernel/iommu_groups/
>>>>> /sys/kernel/iommu_groups/0
>>>>> /sys/kernel/iommu_groups/0/devices
>>>>> /sys/kernel/iommu_groups/0/devices/e0700000.xgmac
>>>>>
>>>>> whereas I formerly see
>>>>>
>>>>> /sys/kernel/iommu_groups/
>>>>> /sys/kernel/iommu_groups/3
>>>>> /sys/kernel/iommu_groups/3/devices
>>>>> /sys/kernel/iommu_groups/3/devices/0000:00:00.0
>>>>> /sys/kernel/iommu_groups/1
>>>>> /sys/kernel/iommu_groups/1/devices
>>>>> /sys/kernel/iommu_groups/1/devices/e0700000.xgmac
>>>>> /sys/kernel/iommu_groups/4
>>>>> /sys/kernel/iommu_groups/4/devices
>>>>> /sys/kernel/iommu_groups/4/devices/0000:00:02.2
>>>>> /sys/kernel/iommu_groups/4/devices/0000:01:00.1
>>>>> /sys/kernel/iommu_groups/4/devices/0000:00:02.0
>>>>> /sys/kernel/iommu_groups/4/devices/0000:01:00.0
>>>>> /sys/kernel/iommu_groups/2
>>>>> /sys/kernel/iommu_groups/2/devices
>>>>> /sys/kernel/iommu_groups/2/devices/e0900000.xgmac
>>>>> /sys/kernel/iommu_groups/0
>>>>> /sys/kernel/iommu_groups/0/devices
>>>>> /sys/kernel/iommu_groups/0/devices/f0000000.pcie
>>>>>
>>>>> This is the group topology without ACS override. Applying the non
>>>>> upstreamed "pci: Enable overrides for missing ACS capabilities" I used
>>>>> to see separate groups for each PCIe components. Now I don't see any
>>>>> difference with and without ACS override.
>>>>
>>>> OK, having reproduced on my Juno, the problem looks to be that
>>>> of_for_each_phandle() leaves err set to -ENOENT after successfully
>>>> walking a phandle list, which makes __find_legacy_master_phandle()
>>>> always bail out after the first SMMU.
>>>>
>>>> Can you confirm that the following diff fixes things for you?
>>>
>>> Well it improves but there are still differences in the group topology.
>>> The PFs now are in group 0.
>>>
>>> root at trusty:~# lspci -nk
>>> 00:00.0 0600: 1022:1a00
>>> Subsystem: 1022:1a00
>>> 00:02.0 0600: 1022:1a01
>>> 00:02.2 0604: 1022:1a02
>>> Kernel driver in use: pcieport
>>> 01:00.0 0200: 8086:1521 (rev 01)
>>> Subsystem: 8086:0002
>>> Kernel driver in use: igb
>>> 01:00.1 0200: 8086:1521 (rev 01)
>>> Subsystem: 8086:0002
>>> Kernel driver in use: igb
>>>
>>>
>>> with your series + fix:
>>> /sys/kernel/iommu_groups/
>>> /sys/kernel/iommu_groups/3
>>> /sys/kernel/iommu_groups/3/devices
>>> /sys/kernel/iommu_groups/3/devices/0000:00:00.0
>>> /sys/kernel/iommu_groups/1
>>> /sys/kernel/iommu_groups/1/devices
>>> /sys/kernel/iommu_groups/1/devices/e0700000.xgmac
>>> /sys/kernel/iommu_groups/4
>>> /sys/kernel/iommu_groups/4/devices
>>> /sys/kernel/iommu_groups/4/devices/0000:00:02.2
>>> /sys/kernel/iommu_groups/4/devices/0000:00:02.0
>>> /sys/kernel/iommu_groups/2
>>> /sys/kernel/iommu_groups/2/devices
>>> /sys/kernel/iommu_groups/2/devices/e0900000.xgmac
>>> /sys/kernel/iommu_groups/0
>>> /sys/kernel/iommu_groups/0/devices
>>> /sys/kernel/iommu_groups/0/devices/0000:01:00.1
>>> /sys/kernel/iommu_groups/0/devices/f0000000.pcie
>>> /sys/kernel/iommu_groups/0/devices/0000:01:00.0
>>>
>>> Before (4.8-rc5):
>>>
>>> /sys/kernel/iommu_groups/
>>> /sys/kernel/iommu_groups/3
>>> /sys/kernel/iommu_groups/3/devices
>>> /sys/kernel/iommu_groups/3/devices/0000:00:00.0
>>> /sys/kernel/iommu_groups/1
>>> /sys/kernel/iommu_groups/1/devices
>>> /sys/kernel/iommu_groups/1/devices/e0700000.xgmac
>>> /sys/kernel/iommu_groups/4
>>> /sys/kernel/iommu_groups/4/devices
>>> /sys/kernel/iommu_groups/4/devices/0000:00:02.2
>>> /sys/kernel/iommu_groups/4/devices/0000:01:00.1
>>> /sys/kernel/iommu_groups/4/devices/0000:00:02.0
>>> /sys/kernel/iommu_groups/4/devices/0000:01:00.0
>>> /sys/kernel/iommu_groups/2
>>> /sys/kernel/iommu_groups/2/devices
>>> /sys/kernel/iommu_groups/2/devices/e0900000.xgmac
>>> /sys/kernel/iommu_groups/0
>>> /sys/kernel/iommu_groups/0/devices
>>> /sys/kernel/iommu_groups/0/devices/f0000000.pcie
>>
>> Your DT claims that f0000000.pcie (i.e. the "platform device" side of
>> the host controller) owns the IDs 0x100 0x101 0x102 0x103 0x200 0x201
>> 0x202 0x203 0x300 0x301 0x302 0x303 0x400 0x401 0x402 0x403. Thus when
>> new devices (the PCI PFs) come along *also* claiming those IDs (via the
>> RID-to-SID assumption), we now detect the aliasing and assign them to
>> the existing group.
>>
>> The only way that DT worked without SMR conflicts before is that
>> f0000000.pcie wasn't actually getting attached to a domain, thus wasn't
>> getting SMRs allocated (ISTR you _did_ get conflicts back when we first
>> tried to switch on default domains; that was probably the reason).
>
> Thanks for your explanations. meanwhile I converted the overdrive dt to
> the new syntax and it works properly.
Yay!
> However I noticed there are MSI frame iommu mapping although the
> device's domain is the default one. There is no check currently in
> 21/22. I guess this isn't needed?
Au contraire ;) With the generic binding, default domains are properly
implemented, i.e. they have translation, so anything not mapped will
fault. I *had* to write patch 21 as part of this series, since having
DMA ops for PCI devices at the cost of breaking all MSIs was clearly not
a viable solution. If you see mappings, then it's because someone is
using MSIs - so if you fancy, you can try rewinding back to patch 19 or
20 to watch them get stuck.
Robin.
^ permalink raw reply
* [GIT PULL] arm64: X-Gene platforms DTS changes queued for 4.9 - part1
From: Will Deacon @ 2016-09-15 10:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5104796.MOduSCrlzf@wuerfel>
On Thu, Sep 15, 2016 at 09:57:52AM +0200, Arnd Bergmann wrote:
> On Thursday, September 15, 2016 8:30:30 AM CEST Will Deacon wrote:
> > On Wed, Sep 14, 2016 at 06:57:59PM -0700, Duc Dang wrote:
> > > On Wed, Sep 14, 2016 at 7:59 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > > > On Friday, September 2, 2016 11:46:31 AM CEST Duc Dang wrote:
> > > > Please send this again as two pull requests, one for the dts changes, and
> > > > one for the rest (pmu driver, binding and MAINTAINERS file). Please
> > > > also include an explanation in the tag description about why this gets
> > > > merged through arm-soc. I see that Will suggested doing it that way,
> > > > but I don't see what the reason is. We normally don't touch that directory.
> > > Hi Arnd,
> > >
> > > I am not clear about the reason either. Probably we don't have a
> > > dedicated tree for SoC PMU?
> >
> > That's right, there isn't a dedicated tree for SoC PMUs. I tend to handle
> > the architected PMUs (e.g. the ones in the CPUs), but other PMUs have
> > been ad-hoc in the past. That said, Mark and I do tend to review PMU
> > drivers, because the internal perf interface is pretty easy to get wrong.
> >
> > Arnd -- what would you like to see here? I could collect SoC PMU patches
> > together and send you a pull request, or would you like me to take them via
> > the arm64 tree? It's worth noting that we have PMU drivers under drivers/bus
> > and drivers/hwtracing too, and I *think* arm-soc has handled those in the
> > past.
>
> I (and I suspect the same of Olof) don't understand enough about PMU drivers
> to be a good gatekeeper for PMU drivers, so I've had to rely on platform
> maintainers to know what they are doing when they sent me a driver in
> the past. I had not realized that we already have those drivers in multiple
> places, and that seems reason enough to get a maintainer for them who
> can review and apply the patches, as well as possibly consolidate them
> in once place.
>
> I don't mind forwarding the drivers to Linus in the next/drivers branch
> of arm-soc, like we do for drivers/reset which also has its own maintainer
> who picks up the patches to forward them to us.
>
> It would certainly help us if you can collect the changes and forward them,
> thanks a lot for the offer! Since I know you have a lot on your plate
> already, how about finding another co-maintainer who doesn't already
> own a subsystem but understands PMUs and could use some on-the-job
> training for this?
Well, I already have Mark as a Reviewer for the ARM perf stuff, so I could
change him to be a co-maintainer [patch below] and between us we'll send
pull requests your way. That also works out with the arm64 tree, where
Catalin and I take it in turns each release. Given that we're already
reviewing the PMU drivers, I don't think it should be too much extra work.
Of course, if somebody else starts reviewing on the list, then I'm more
than happy to get them involved too.
Finally, it would then be helpful if you keep an eye out for any PMU
patches coming in via other routes to arm-soc, so we can point people to
put their SoC PMU code under drivers/perf/ instead.
> For v4.9, I'd just take the pull request once Duc resends separate
> branches, and then we start a more formal procedure for v4.10 (or
> late if there are no PMU patches during that time).
Thanks,
Will
--->8
>From 436d3a7ad25517433fc8f563f44fdab3c4801666 Mon Sep 17 00:00:00 2001
From: Will Deacon <will.deacon@arm.com>
Date: Thu, 15 Sep 2016 10:14:41 +0100
Subject: [PATCH] MAINTAINERS: Update ARM PMU PROFILING AND DEBUGGING entry
There are an increasing number of ARM SoC PMU drivers appearing for
things like interconnects, memory controllers and cache controllers.
Rather than have these handled on an ad-hoc basis, where SoC maintainers
each send their PMU drivers directly to arm-soc, let's take these into
drivers/perf/ and send a single pull request to arm-soc instead, much
like other subsystems.
This patch amends the ARM PMU MAINTAINERS entry to include all of
drivers/perf/ (currently just the ARM CPU PMU), changes Mark Rutland
from Reviewer to Maintainer, so that he can help with the new tree and
adds the device-tree binding to the list of maintained files.
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
MAINTAINERS | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 6781a3febd59..090694e685ba 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -913,15 +913,16 @@ F: arch/arm/include/asm/floppy.h
ARM PMU PROFILING AND DEBUGGING
M: Will Deacon <will.deacon@arm.com>
-R: Mark Rutland <mark.rutland@arm.com>
+M: Mark Rutland <mark.rutland@arm.com>
S: Maintained
F: arch/arm*/kernel/perf_*
F: arch/arm/oprofile/common.c
F: arch/arm*/kernel/hw_breakpoint.c
F: arch/arm*/include/asm/hw_breakpoint.h
F: arch/arm*/include/asm/perf_event.h
-F: drivers/perf/arm_pmu.c
+F: drivers/perf/*
F: include/linux/perf/arm_pmu.h
+F: Documentation/devicetree/bindings/arm/pmu.txt
ARM PORT
M: Russell King <linux@armlinux.org.uk>
--
2.5.0
^ permalink raw reply related
* [GIT PULL] Greybus driver subsystem for 4.9-rc1
From: Mark Rutland @ 2016-09-15 10:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473932133.10230.25.camel@nexus-software.ie>
On Thu, Sep 15, 2016 at 10:35:33AM +0100, Bryan O'Donoghue wrote:
> On Wed, 2016-09-14 at 20:29 +0200, Greg KH wrote:
> > Bryan, any explanations you want to provide that would help in
> > clarifying Mark's issues?
>
> As Douglas Adams would say - "don't panic".
>
> If you look at the final state the code ends up in - we're doing
> get_cycles(); as opposed to reading an architectural timer directly.
>
> u64 gb_timesync_platform_get_counter(void)
> {
> ????????return (u64)get_cycles();
> }
I did in fact notice this, though my wording was somewhat unclear on
that part.
> You have the entire git history - from the early days where we were
> reading one of the unused ARMv8 timers the MSM8994 has to the later
> days where we just do get_cycles()...
>
> At the time when we first started writing the code it wasn't 100%
> clear if get_cycles() would do, so it was safer to allocate an unused
> architectural timer and read it directly. Later on and with some
> experimentation it was possible to switch to get_cycles().
I don't think the history matters, and I don't think that one can rely
on get_cycles() in this manner outside of arch code. Looking at the
state of the tree [1] as of the final commit [2] in the greybus branch,
my points still stand:
* The "google,greybus-frame-time-counter" node is superfluous. It does
not describe a particular device, and duplicates information we have
elsewhere. It does not explicitly define the relationship with the
underlying clocksource.
* The clock-frequency property isn't necessary. The architected timer
drivers know the frequency of the architected timers (MMIO or sysreg),
and they should be queried as to the frequency.
* In general, get_cycles() isn't guaranteed to be any clocksource or
cycle counter in particular, so even if the clock-frequency property
matches the architected timer, that doesn't help.
Beyond that, the fallback code using cpufreq and presumably an actual
cycle counter will be broken in a number of cases -- cycle counts will
not match across CPUs, and on CPUs whic gate clocks in WFI/WFE, they'll
drift randomly.
Per the comment at the top of the file, it looks like you want a
system-wide stable clocksource. If you want that, you need to use a
generic API that allows drivers and arch code to actually provide that,
rather than building one yourself that doesn't work.
If you're trying to synchronise with other agents in the system that are
reading from the MMIO arch timers, then that relationship should be
described explicitly in the DT.
Thanks,
Mark.
[1] https://git.kernel.org/cgit/linux/kernel/git/gregkh/char-misc.git/tree/drivers/greybus/timesync_platform.c?h=greybus&id=f86bfc90a401681838866b5f6826d86cc4c7010c
[2] https://git.kernel.org/cgit/linux/kernel/git/gregkh/char-misc.git/commit/?h=greybus&id=f86bfc90a401681838866b5f6826d86cc4c7010c
^ permalink raw reply
* [PATCH 1/1] ARM: imx5: Add clocks configuration
From: Fabien Lahoudere @ 2016-09-15 10:13 UTC (permalink / raw)
To: linux-arm-kernel
From: Kalle Kankare <kalle.kankare@vincit.fi>
Add clocks configuration for CSI, FIRI and IEEE1588.
Signed-off-by: Fabien Lahoudere <fabien.lahoudere@collabora.co.uk>
---
drivers/clk/imx/clk-imx51-imx53.c | 20 ++++++++++++++++++++
include/dt-bindings/clock/imx5-clock.h | 15 ++++++++++++++-
2 files changed, 34 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/imx/clk-imx51-imx53.c b/drivers/clk/imx/clk-imx51-imx53.c
index 29d4c44..1e3c9ea 100644
--- a/drivers/clk/imx/clk-imx51-imx53.c
+++ b/drivers/clk/imx/clk-imx51-imx53.c
@@ -126,6 +126,7 @@ static const char *spdif0_com_sel[] = { "spdif0_podf", "ssi1_root_gate", };
static const char *mx51_spdif1_com_sel[] = { "spdif1_podf", "ssi2_root_gate", };
static const char *step_sels[] = { "lp_apm", };
static const char *cpu_podf_sels[] = { "pll1_sw", "step_sel" };
+static const char *ieee1588_sels[] = { "pll3_sw", "pll4_sw", "dummy" /* usbphy2_clk */, "dummy" /* fec_phy_clk */ };
static struct clk *clk[IMX5_CLK_END];
static struct clk_onecell_data clk_data;
@@ -543,6 +544,25 @@ static void __init mx53_clocks_init(struct device_node *np)
clk[IMX5_CLK_I2C3_GATE] = imx_clk_gate2("i2c3_gate", "per_root", MXC_CCM_CCGR1, 22);
clk[IMX5_CLK_SATA_GATE] = imx_clk_gate2("sata_gate", "ipg", MXC_CCM_CCGR4, 2);
+ clk[IMX5_CLK_FIRI_SEL] = imx_clk_mux("firi_sel", MXC_CCM_CSCMR2, 12, 2,
+ standard_pll_sel, ARRAY_SIZE(standard_pll_sel));
+ clk[IMX5_CLK_FIRI_PRED] = imx_clk_divider("firi_pred", "firi_sel", MXC_CCM_CSCDR3, 6, 3);
+ clk[IMX5_CLK_FIRI_PODF] = imx_clk_divider("firi_podf", "firi_pred", MXC_CCM_CSCDR3, 0, 6);
+ clk[IMX5_CLK_FIRI_SERIAL_GATE] = imx_clk_gate2("firi_serial_gate", "firi_podf", MXC_CCM_CCGR1, 28);
+ clk[IMX5_CLK_FIRI_IPG_GATE] = imx_clk_gate2("firi_ipg_gate", "ipg", MXC_CCM_CCGR1, 26);
+
+ clk[IMX5_CLK_CSI0_MCLK1_SEL] = imx_clk_mux("csi0_mclk1_sel", MXC_CCM_CSCMR2, 22, 2,
+ standard_pll_sel, ARRAY_SIZE(standard_pll_sel));
+ clk[IMX5_CLK_CSI0_MCLK1_PRED] = imx_clk_divider("csi0_mclk1_pred", "csi0_mclk1_sel", MXC_CCM_CSCDR4, 6, 3);
+ clk[IMX5_CLK_CSI0_MCLK1_PODF] = imx_clk_divider("csi0_mclk1_podf", "csi0_mclk1_pred", MXC_CCM_CSCDR4, 0, 6);
+ clk[IMX5_CLK_CSI0_MCLK1_GATE] = imx_clk_gate2("csi0_mclk1_serial_gate", "csi0_mclk1_podf", MXC_CCM_CCGR6, 4);
+
+ clk[IMX5_CLK_IEEE1588_SEL] = imx_clk_mux("ieee1588_sel", MXC_CCM_CSCMR2, 14, 2,
+ ieee1588_sels, ARRAY_SIZE(ieee1588_sels));
+ clk[IMX5_CLK_IEEE1588_PRED] = imx_clk_divider("ieee1588_pred", "ieee1588_sel", MXC_CCM_CSCDR2, 6, 3);
+ clk[IMX5_CLK_IEEE1588_PODF] = imx_clk_divider("ieee1588_podf", "ieee1588_pred", MXC_CCM_CSCDR2, 0, 6);
+ clk[IMX5_CLK_IEEE1588_GATE] = imx_clk_gate2("ieee1588_serial_gate", "ieee1588_podf", MXC_CCM_CCGR7, 6);
+
clk[IMX5_CLK_CKO1_SEL] = imx_clk_mux("cko1_sel", MXC_CCM_CCOSR, 0, 4,
mx53_cko1_sel, ARRAY_SIZE(mx53_cko1_sel));
clk[IMX5_CLK_CKO1_PODF] = imx_clk_divider("cko1_podf", "cko1_sel", MXC_CCM_CCOSR, 4, 3);
diff --git a/include/dt-bindings/clock/imx5-clock.h b/include/dt-bindings/clock/imx5-clock.h
index f4b7478..d382fc7 100644
--- a/include/dt-bindings/clock/imx5-clock.h
+++ b/include/dt-bindings/clock/imx5-clock.h
@@ -201,6 +201,19 @@
#define IMX5_CLK_STEP_SEL 189
#define IMX5_CLK_CPU_PODF_SEL 190
#define IMX5_CLK_ARM 191
-#define IMX5_CLK_END 192
+#define IMX5_CLK_FIRI_PRED 192
+#define IMX5_CLK_FIRI_SEL 193
+#define IMX5_CLK_FIRI_PODF 194
+#define IMX5_CLK_FIRI_SERIAL_GATE 195
+#define IMX5_CLK_FIRI_IPG_GATE 196
+#define IMX5_CLK_CSI0_MCLK1_PRED 197
+#define IMX5_CLK_CSI0_MCLK1_SEL 198
+#define IMX5_CLK_CSI0_MCLK1_PODF 199
+#define IMX5_CLK_CSI0_MCLK1_GATE 200
+#define IMX5_CLK_IEEE1588_PRED 201
+#define IMX5_CLK_IEEE1588_SEL 202
+#define IMX5_CLK_IEEE1588_PODF 203
+#define IMX5_CLK_IEEE1588_GATE 204
+#define IMX5_CLK_END 205
#endif /* __DT_BINDINGS_CLOCK_IMX5_H */
--
2.1.4
^ permalink raw reply related
* [PATCH] arm64: Enable HIBERNATION in defconfig
From: Catalin Marinas @ 2016-09-15 10:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473932534-2710-1-git-send-email-catalin.marinas@arm.com>
On Thu, Sep 15, 2016 at 10:42:14AM +0100, Catalin Marinas wrote:
> This patch adds CONFIG_HIBERNATION to the arm64 defconfig.
>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> ---
> arch/arm64/configs/defconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index eadf4855ad2d..91a7592029e3 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -80,6 +80,7 @@ CONFIG_KEXEC=y
> # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
> CONFIG_COMPAT=y
> CONFIG_CPU_IDLE=y
> +CONFIG_HIBERNATION=y
> CONFIG_ARM_CPUIDLE=y
> CONFIG_CPU_FREQ=y
> CONFIG_ARM_BIG_LITTLE_CPUFREQ=y
Or maybe it could go through arm-soc as it seems Arnd has picked up a
few other defconfig patches.
Thanks.
--
Catalin
^ permalink raw reply
* [kernel-hardening] [PATCH v3 0/7] arm64: Privileged Access Never using TTBR0_EL1 switching
From: Catalin Marinas @ 2016-09-15 9:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160914205425.GA15021@davidb.org>
On Wed, Sep 14, 2016 at 02:54:25PM -0600, David Brown wrote:
> On Tue, Sep 13, 2016 at 06:46:30PM +0100, Catalin Marinas wrote:
>
> >This is the third version of the arm64 PAN emulation using TTBR0_EL1
> >switching. The series has not yet included the alternative nop patches
> >from Mark Rutland, nor the empty_zero_page from Ard B. This will be done
> >in a subsequent version once 4.9-rc1 is out (which will include Mark's
> >alternative nop patches).
>
> I've tested these with a bunch of reboots in both qemu and HiKey and
> have not seen the efi failure.
Thanks for testing. I'll defer adding your tested-by until I post the
hopefully final version after 4.9-rc1 (it's pretty late to merge these
patches now, I still need to do more testing on models with PAN or
PAN+UAO present).
--
Catalin
^ permalink raw reply
* [PATCH 1/1] ARM: keystone: defconfig: Fix USB configuration
From: Arnd Bergmann @ 2016-09-15 9:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <af658fe2-1555-e653-ad5e-54bec9bfd037@ti.com>
On Monday, September 12, 2016 2:33:57 PM CEST Roger Quadros wrote:
> On 25/08/16 19:39, Santosh Shilimkar wrote:
> > Ping !!
> >
> > On 8/17/2016 9:23 AM, Santosh Shilimkar wrote:
> >> Hi Arnd, Olof,
> >>
> >> Can you please pick-up the fix for 4.8-rcx ?
> >> Roger reported that USB ports are broken on Keystone2 boards
> >> since v4.8-rc1 because USB_HPY config option got dropped.
> >>
> >>
> >> On 8/17/2016 3:44 AM, Roger Quadros wrote:
> >>> Simply enabling CONFIG_KEYSTONE_USB_PHY doesn't work anymore
> >>> as it depends on CONFIG_NOP_USB_XCEIV. We need to enable
> >>> that as well.
> >>>
> >>> This fixes USB on Keystone boards from v4.8-rc1 onwards.
> >>>
> >>> Signed-off-by: Roger Quadros <rogerq@ti.com>
> >>> ---
> >> Acked-by: Santosh Shilimkar <ssantosh@kernel.org>
>
> Gentle reminder.
> This is still missing in v4.8-rc6.
>
>
Applied to the fixes branch now, sorry for missing the
previous reminder.
Arnd
^ permalink raw reply
* [PATCH v4 5/8] ARM: dts: am335x-boneblack: Add blue-and-red-wiring -property to LCDC node
From: Jyri Sarha @ 2016-09-15 9:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <fad833a6a4368196f4fc131a54d90f5b90169393.1472719892.git.jsarha@ti.com>
Tony,
The functional changes are now merged. But let's not merge this bbb dts
patch just yet, so we do not cause a conflict with the other bbb hdmi
audio dts change[1] that slipped into tda998x pull request. The patch
can very well wait until v4.10 if needed.
However, the other three dts patches[2] can be merged. Should I rebase
those on top of some branch and resend them?
Best regards,
Jyri
[1] https://lists.freedesktop.org/archives/dri-devel/2016-August/115269.html
[2]
https://lists.freedesktop.org/archives/dri-devel/2016-September/117282.html
https://lists.freedesktop.org/archives/dri-devel/2016-September/117283.html
https://lists.freedesktop.org/archives/dri-devel/2016-September/117284.html
On 09/01/16 12:09, Jyri Sarha wrote:
> Add blue-and-red-wiring -property to LCDC node. Also adds comments on
> how to get support 24 bit RGB mode. After this patch am335x-boneblack
> support RGB565, BGR888, and XBGR8888 color formats. See details in
> Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt.
>
> The BBB has straight color wiring from am335x to tda19988, however the
> tda19988 can be configured to cross the blue and red wires. The
> comments show how to do that with video-ports property of tda19988
> node and how to tell LCDC that blue and red wires are crossed, with
> blue-and-red-wiring LCDC node property. This changes supported color
> formats from 16 bit RGB and 24 bit BGR to 16 bit BGR and 24 bit RGB.
>
> Signed-off-by: Jyri Sarha <jsarha@ti.com>
> ---
> arch/arm/boot/dts/am335x-boneblack.dts | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/arch/arm/boot/dts/am335x-boneblack.dts b/arch/arm/boot/dts/am335x-boneblack.dts
> index 528559b..a32d73a 100644
> --- a/arch/arm/boot/dts/am335x-boneblack.dts
> +++ b/arch/arm/boot/dts/am335x-boneblack.dts
> @@ -90,6 +90,14 @@
>
> &lcdc {
> status = "okay";
> +
> + /* If you want to get 24 bit RGB and 16 BGR mode instead of
> + * current 16 bit RGB and 24 BGR modes, set the propety
> + * below to "crossed" and uncomment the video-ports -property
> + * in tda19988 node.
> + */
> + blue-and-red-wiring = "straight";
> +
> port {
> lcdc_0: endpoint at 0 {
> remote-endpoint = <&hdmi_0>;
> @@ -106,6 +114,9 @@
> pinctrl-0 = <&nxp_hdmi_bonelt_pins>;
> pinctrl-1 = <&nxp_hdmi_bonelt_off_pins>;
>
> + /* Convert 24bit BGR to RGB, e.g. cross red and blue wiring */
> + /* video-ports = <0x234501>; */
> +
> #sound-dai-cells = <0>;
> audio-ports = < TDA998x_I2S 0x03>;
>
>
^ 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