* [PATCH v3 2/8] clk: sunxi: update clock-output-names dt binding documentation
From: Emilio López @ 2014-01-17 2:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389257565-19797-3-git-send-email-wens@csie.org>
Hi,
El 09/01/14 05:52, Chen-Yu Tsai escribi?:
> clock-output-names is now required for most of sunxi clock nodes, to
> provide the name of the corresponding clock. Add the new requirements,
> exceptions, as well as examples.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> ---
> Documentation/devicetree/bindings/clock/sunxi.txt | 36 +++++++++++++++++++----
> 1 file changed, 31 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
> index 0c127cd..8a9147d 100644
> --- a/Documentation/devicetree/bindings/clock/sunxi.txt
> +++ b/Documentation/devicetree/bindings/clock/sunxi.txt
> @@ -44,10 +44,18 @@ Required properties for all clocks:
> multiplexed clocks, the list order must match the hardware
> programming order.
> - #clock-cells : from common clock binding; shall be set to 0 except for
> - "allwinner,*-gates-clk" where it shall be set to 1
> + "allwinner,*-gates-clk", "allwinner,sun4i-pll5-clk" and
> + "allwinner,sun4i-pll6-clk" where it shall be set to 1
>
> -Additionally, "allwinner,*-gates-clk" clocks require:
> -- clock-output-names : the corresponding gate names that the clock controls
> +Additionally, most clocks require "clock-output-names":
> +- "allwinner,*-gates-clk" : the corresponding gate names that the clock controls
> +- "allwinner,sun4i-pll5-clk" : "pll5_ddr", "pll5_mbus"
> +- "allwinner,sun4i-pll6-clk" : "pll6_sata", "pll6_other"
> +- "allwinner,sun4i-cpu-clk", "allwinner,sun4i-axi-clk",
> + "allwinner,sun4i-ahb-clk", "allwinner,sun4i-ahb-clk",
> + "allwinner,sun4i-apb1-mux-clk", "allwinner,sun4i-apb1-clk"
> + do not need "clock-output-names"
> +- all others clocks : the corresponding module name of that clock
As we discussed on IRC, I wonder if such verbosity is actually needed.
Maybe we should dictate that all clocks must list their corresponding
outputs on clock-output-names (with it being the module name if it only
has one output).
Cheers,
Emilio
^ permalink raw reply
* [PATCHv9 2/2] dma: Add Freescale eDMA engine driver support
From: Jingchang Lu @ 2014-01-17 2:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201401161202.49333.arnd@arndb.de>
> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> Sent: Thursday, January 16, 2014 7:03 PM
> To: Lu Jingchang-B35083
> Cc: vinod.koul at intel.com; dan.j.williams at intel.com; shawn.guo at linaro.org;
> pawel.moll at arm.com; mark.rutland at arm.com; swarren at wwwdotorg.org; linux-
> kernel at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
> devicetree at vger.kernel.org; Wang Huan-B18965
> Subject: Re: [PATCHv9 2/2] dma: Add Freescale eDMA engine driver support
>
> On Thursday 16 January 2014, Jingchang Lu wrote:
> > Add Freescale enhanced direct memory(eDMA) controller support.
> > This module can be found on Vybrid and LS-1 SoCs.
> >
> > Signed-off-by: Alison Wang <b18965@freescale.com>
> > Signed-off-by: Jingchang Lu <b35083@freescale.com>
>
> Very nice! All my previous comments have been addressed, so
>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
>
> One small comment still:
>
> > +
> > +static DEFINE_MUTEX(fsl_edma_mutex);
> > +
>
> I think this mutex should be part of struct fsl_edma_engine, not global.
Yes, it should be for each edma controller, I will define it in struct fsl_edma_engine. Thanks.
Best Regards,
Jingchang
^ permalink raw reply
* [PATCH V7 3/3] ARM: imx: add suspend in ocram support for i.mx6sl
From: Shawn Guo @ 2014-01-17 2:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389864907-4040-3-git-send-email-b20788@freescale.com>
On Thu, Jan 16, 2014 at 05:35:07PM +0800, Anson Huang wrote:
> @@ -63,6 +63,7 @@
> #define MX6Q_SRC_GPR1 0x20
> #define MX6Q_SRC_GPR2 0x24
> #define MX6Q_MMDC_MAPSR 0x404
> +#define MX6Q_MMDC_MPDGCTRL0 0x83c
> #define MX6Q_GPC_IMR1 0x08
> #define MX6Q_GPC_IMR2 0x0c
> #define MX6Q_GPC_IMR3 0x10
> @@ -107,14 +108,36 @@
> ldreq r11, [r0, #PM_INFO_MX6Q_MMDC_V_OFFSET]
> ldrne r11, [r0, #PM_INFO_MX6Q_MMDC_P_OFFSET]
>
> + cmp r3, #MXC_CPU_IMX6SL
> + bne 4f
> +
> + /* reset read FIFO, RST_RD_FIFO */
> + ldr r7, =MX6Q_MMDC_MPDGCTRL0
> + ldr r6, [r11, r7]
> + orr r6, r6, #(1 << 31)
> + str r6, [r11, r7]
> +2:
> + ldr r6, [r11, r7]
> + ands r6, r6, #(1 << 31)
> + bne 2b
> +
> + /* reset FIFO a second time */
> + ldr r6, [r11, r7]
> + orr r6, r6, #(1 << 31)
> + str r6, [r11, r7]
> +3:
> + ldr r6, [r11, r7]
> + ands r6, r6, #(1 << 31)
> + bne 3b
> +4:
> /* let DDR out of self-refresh */
> ldr r7, [r11, #MX6Q_MMDC_MAPSR]
> bic r7, r7, #(1 << 21)
> str r7, [r11, #MX6Q_MMDC_MAPSR]
> -2:
> +5:
> ldr r7, [r11, #MX6Q_MMDC_MAPSR]
> ands r7, r7, #(1 << 25)
> - bne 2b
> + bne 5b
>
> /* enable DDR auto power saving */
> ldr r7, [r11, #MX6Q_MMDC_MAPSR]
> @@ -282,6 +305,7 @@ resume:
> str r7, [r11, #MX6Q_SRC_GPR1]
> str r7, [r11, #MX6Q_SRC_GPR2]
>
> + ldr r3, [r0, #PM_INFO_CPU_TYPE_OFFSET]
> mov r5, #0x1
> resume_mmdc
The IMX6SL special handling in suspend/set_mmdc_lpm gets lost?
Shawn
>
> --
> 1.7.9.5
>
>
^ permalink raw reply
* [PATCH V7 1/3] ARM: imx: add suspend in ocram support for i.mx6q
From: Shawn Guo @ 2014-01-17 2:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389864907-4040-1-git-send-email-b20788@freescale.com>
On Thu, Jan 16, 2014 at 05:35:05PM +0800, Anson Huang wrote:
> +static const u32 imx6q_mmdc_io_offset[] = {
This can be __initconst?
Shawn
> + 0x5ac, 0x5b4, 0x528, 0x520, /* DQM0 ~ DQM3 */
> + 0x514, 0x510, 0x5bc, 0x5c4, /* DQM4 ~ DQM7 */
> + 0x56c, 0x578, 0x588, 0x594, /* CAS, RAS, SDCLK_0, SDCLK_1 */
> + 0x5a8, 0x5b0, 0x524, 0x51c, /* SDQS0 ~ SDQS3 */
> + 0x518, 0x50c, 0x5b8, 0x5c0, /* SDQS4 ~ SDQS7 */
> + 0x784, 0x788, 0x794, 0x79c, /* GPR_B0DS ~ GPR_B3DS */
> + 0x7a0, 0x7a4, 0x7a8, 0x748, /* GPR_B4DS ~ GPR_B7DS */
> + 0x59c, 0x5a0, 0x750, 0x774, /* SODT0, SODT1, MODE_CTL, MODE */
> + 0x74c, /* GPR_ADDS */
> +};
^ permalink raw reply
* [PATCH 3/3] ACPI: Introduce map_gic_id() to get apic id from MADT or _MAT method
From: Hanjun Guo @ 2014-01-17 2:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389924207-7360-1-git-send-email-hanjun.guo@linaro.org>
Get apic id from MADT or _MAT method is not implemented on arm/arm64,
and ACPI 5.0 introduces GIC Structure for it, so this patch introduces
map_gic_id() to get apic id followed the ACPI 5.0 spec.
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
drivers/acpi/processor_core.c | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/drivers/acpi/processor_core.c b/drivers/acpi/processor_core.c
index cd7b5fe..165eac7 100644
--- a/drivers/acpi/processor_core.c
+++ b/drivers/acpi/processor_core.c
@@ -90,6 +90,27 @@ static int map_lsapic_id(struct acpi_subtable_header *entry,
return 1;
}
+static int map_gic_id(struct acpi_subtable_header *entry,
+ int device_declaration, u32 acpi_id, int *apic_id)
+{
+ struct acpi_madt_generic_interrupt *gic =
+ (struct acpi_madt_generic_interrupt *)entry;
+
+ if (!(gic->flags & ACPI_MADT_ENABLED))
+ return 0;
+
+ /* In the GIC interrupt model, logical processors are
+ * required to have a Processor Device object in the DSDT,
+ * so we should check device_declaration here
+ */
+ if (device_declaration && (gic->uid == acpi_id)) {
+ *apic_id = gic->gic_id;
+ return 1;
+ }
+
+ return 0;
+}
+
static int map_madt_entry(int type, u32 acpi_id)
{
unsigned long madt_end, entry;
@@ -125,6 +146,9 @@ static int map_madt_entry(int type, u32 acpi_id)
} else if (header->type == ACPI_MADT_TYPE_LOCAL_SAPIC) {
if (map_lsapic_id(header, type, acpi_id, &apic_id))
break;
+ } else if (header->type == ACPI_MADT_TYPE_GENERIC_INTERRUPT) {
+ if (map_gic_id(header, type, acpi_id, &apic_id))
+ break;
}
entry += header->length;
}
@@ -155,6 +179,8 @@ static int map_mat_entry(acpi_handle handle, int type, u32 acpi_id)
map_lapic_id(header, acpi_id, &apic_id);
} else if (header->type == ACPI_MADT_TYPE_LOCAL_SAPIC) {
map_lsapic_id(header, type, acpi_id, &apic_id);
+ } else if (header->type == ACPI_MADT_TYPE_GENERIC_INTERRUPT) {
+ map_gic_id(header, type, acpi_id, &apic_id);
}
exit:
--
1.8.2.2
^ permalink raw reply related
* [PATCH 2/3] ACPI / processor_core: Rework _PDC related stuff to make it more arch-independent
From: Hanjun Guo @ 2014-01-17 2:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389924207-7360-1-git-send-email-hanjun.guo@linaro.org>
_PDC related stuff in processor_core.c is little bit X86/IA64 dependent,
rework the code to make it more arch-independent, no functional change
in this patch.
The return value of acpi_processor_eval_pdc() should be 'acpi_status' but
defined as 'int', fix it too.
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
---
arch/ia64/include/asm/acpi.h | 5 +----
arch/ia64/kernel/acpi.c | 17 +++++++++++++++++
arch/x86/include/asm/acpi.h | 19 +------------------
arch/x86/kernel/acpi/cstate.c | 31 +++++++++++++++++++++++++++++++
drivers/acpi/processor_core.c | 21 ++-------------------
5 files changed, 52 insertions(+), 41 deletions(-)
diff --git a/arch/ia64/include/asm/acpi.h b/arch/ia64/include/asm/acpi.h
index faa1bf0..3348d07 100644
--- a/arch/ia64/include/asm/acpi.h
+++ b/arch/ia64/include/asm/acpi.h
@@ -154,10 +154,7 @@ extern int __initdata nid_to_pxm_map[MAX_NUMNODES];
#endif
static inline bool arch_has_acpi_pdc(void) { return true; }
-static inline void arch_acpi_set_pdc_bits(u32 *buf)
-{
- buf[2] |= ACPI_PDC_EST_CAPABILITY_SMP;
-}
+extern void arch_acpi_set_pdc_bits(u32 *buf);
#define acpi_unlazy_tlb(x)
diff --git a/arch/ia64/kernel/acpi.c b/arch/ia64/kernel/acpi.c
index 59d52e3..d126f15 100644
--- a/arch/ia64/kernel/acpi.c
+++ b/arch/ia64/kernel/acpi.c
@@ -1018,3 +1018,20 @@ EXPORT_SYMBOL(acpi_unregister_ioapic);
* TBD when when IA64 starts to support suspend...
*/
int acpi_suspend_lowlevel(void) { return 0; }
+
+void arch_acpi_set_pdc_bits(u32 *buf)
+{
+ /* Enable coordination with firmware's _TSD info */
+ buf[2] |= ACPI_PDC_SMP_T_SWCOORD;
+ if (boot_option_idle_override == IDLE_NOMWAIT) {
+ /*
+ * If mwait is disabled for CPU C-states, the C2C3_FFH access
+ * mode will be disabled in the parameter of _PDC object.
+ * Of course C1_FFH access mode will also be disabled.
+ */
+ buf[2] &= ~(ACPI_PDC_C_C2C3_FFH | ACPI_PDC_C_C1_FFH);
+
+ }
+
+ buf[2] |= ACPI_PDC_EST_CAPABILITY_SMP;
+}
diff --git a/arch/x86/include/asm/acpi.h b/arch/x86/include/asm/acpi.h
index c8c1e70..e9f71bc 100644
--- a/arch/x86/include/asm/acpi.h
+++ b/arch/x86/include/asm/acpi.h
@@ -147,24 +147,7 @@ static inline bool arch_has_acpi_pdc(void)
c->x86_vendor == X86_VENDOR_CENTAUR);
}
-static inline void arch_acpi_set_pdc_bits(u32 *buf)
-{
- struct cpuinfo_x86 *c = &cpu_data(0);
-
- buf[2] |= ACPI_PDC_C_CAPABILITY_SMP;
-
- if (cpu_has(c, X86_FEATURE_EST))
- buf[2] |= ACPI_PDC_EST_CAPABILITY_SWSMP;
-
- if (cpu_has(c, X86_FEATURE_ACPI))
- buf[2] |= ACPI_PDC_T_FFH;
-
- /*
- * If mwait/monitor is unsupported, C2/C3_FFH will be disabled
- */
- if (!cpu_has(c, X86_FEATURE_MWAIT))
- buf[2] &= ~(ACPI_PDC_C_C2C3_FFH);
-}
+extern void arch_acpi_set_pdc_bits(u32 *buf);
#else /* !CONFIG_ACPI */
diff --git a/arch/x86/kernel/acpi/cstate.c b/arch/x86/kernel/acpi/cstate.c
index d2b7f27..b132748 100644
--- a/arch/x86/kernel/acpi/cstate.c
+++ b/arch/x86/kernel/acpi/cstate.c
@@ -16,6 +16,37 @@
#include <asm/mwait.h>
#include <asm/special_insns.h>
+void arch_acpi_set_pdc_bits(u32 *buf)
+{
+ struct cpuinfo_x86 *c = &cpu_data(0);
+
+ /* Enable coordination with firmware's _TSD info */
+ buf[2] |= ACPI_PDC_SMP_T_SWCOORD;
+ if (boot_option_idle_override == IDLE_NOMWAIT) {
+ /*
+ * If mwait is disabled for CPU C-states, the C2C3_FFH access
+ * mode will be disabled in the parameter of _PDC object.
+ * Of course C1_FFH access mode will also be disabled.
+ */
+ buf[2] &= ~(ACPI_PDC_C_C2C3_FFH | ACPI_PDC_C_C1_FFH);
+
+ }
+
+ buf[2] |= ACPI_PDC_C_CAPABILITY_SMP;
+
+ if (cpu_has(c, X86_FEATURE_EST))
+ buf[2] |= ACPI_PDC_EST_CAPABILITY_SWSMP;
+
+ if (cpu_has(c, X86_FEATURE_ACPI))
+ buf[2] |= ACPI_PDC_T_FFH;
+
+ /*
+ * If mwait/monitor is unsupported, C2/C3_FFH will be disabled
+ */
+ if (!cpu_has(c, X86_FEATURE_MWAIT))
+ buf[2] &= ~(ACPI_PDC_C_C2C3_FFH);
+}
+
/*
* Initialize bm_flags based on the CPU cache properties
* On SMP it depends on cache configuration
diff --git a/drivers/acpi/processor_core.c b/drivers/acpi/processor_core.c
index b3171f3..cd7b5fe 100644
--- a/drivers/acpi/processor_core.c
+++ b/drivers/acpi/processor_core.c
@@ -274,9 +274,6 @@ static void acpi_set_pdc_bits(u32 *buf)
buf[0] = ACPI_PDC_REVISION_ID;
buf[1] = 1;
- /* Enable coordination with firmware's _TSD info */
- buf[2] = ACPI_PDC_SMP_T_SWCOORD;
-
/* Twiddle arch-specific bits needed for _PDC */
arch_acpi_set_pdc_bits(buf);
}
@@ -301,7 +298,7 @@ static struct acpi_object_list *acpi_processor_alloc_pdc(void)
return NULL;
}
- buf = kmalloc(12, GFP_KERNEL);
+ buf = kzalloc(12, GFP_KERNEL);
if (!buf) {
printk(KERN_ERR "Memory allocation error\n");
kfree(obj);
@@ -324,25 +321,11 @@ static struct acpi_object_list *acpi_processor_alloc_pdc(void)
* _PDC is required for a BIOS-OS handshake for most of the newer
* ACPI processor features.
*/
-static int
+static acpi_status
acpi_processor_eval_pdc(acpi_handle handle, struct acpi_object_list *pdc_in)
{
acpi_status status = AE_OK;
- if (boot_option_idle_override == IDLE_NOMWAIT) {
- /*
- * If mwait is disabled for CPU C-states, the C2C3_FFH access
- * mode will be disabled in the parameter of _PDC object.
- * Of course C1_FFH access mode will also be disabled.
- */
- union acpi_object *obj;
- u32 *buffer = NULL;
-
- obj = pdc_in->pointer;
- buffer = (u32 *)(obj->buffer.pointer);
- buffer[2] &= ~(ACPI_PDC_C_C2C3_FFH | ACPI_PDC_C_C1_FFH);
-
- }
status = acpi_evaluate_object(handle, "_PDC", pdc_in, NULL);
if (ACPI_FAILURE(status))
--
1.8.2.2
^ permalink raw reply related
* [PATCH 1/3] ACPI / idle: Move idle_boot_override out of the arch directory
From: Hanjun Guo @ 2014-01-17 2:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389924207-7360-1-git-send-email-hanjun.guo@linaro.org>
Move idle_boot_override out of the arch directory to be a single enum
including both platforms values, this will make it rather easier to
avoid ifdefs around which definitions are for which processor in
generally used ACPI code.
IDLE_FORCE_MWAIT for IA64 is not used anywhere, so romove it.
No functional change in this patch.
Suggested-by: Alan <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
arch/ia64/include/asm/processor.h | 3 ---
arch/powerpc/include/asm/processor.h | 1 -
arch/x86/include/asm/processor.h | 3 ---
arch/x86/kernel/process.c | 1 +
include/linux/cpu.h | 8 ++++++++
5 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/arch/ia64/include/asm/processor.h b/arch/ia64/include/asm/processor.h
index 5a84b3a..ccd63a0 100644
--- a/arch/ia64/include/asm/processor.h
+++ b/arch/ia64/include/asm/processor.h
@@ -698,9 +698,6 @@ prefetchw (const void *x)
extern unsigned long boot_option_idle_override;
-enum idle_boot_override {IDLE_NO_OVERRIDE=0, IDLE_HALT, IDLE_FORCE_MWAIT,
- IDLE_NOMWAIT, IDLE_POLL};
-
void default_idle(void);
#define ia64_platform_is(x) (strcmp(x, ia64_platform_name) == 0)
diff --git a/arch/powerpc/include/asm/processor.h b/arch/powerpc/include/asm/processor.h
index fc14a38..06689c0 100644
--- a/arch/powerpc/include/asm/processor.h
+++ b/arch/powerpc/include/asm/processor.h
@@ -440,7 +440,6 @@ static inline unsigned long get_clean_sp(unsigned long sp, int is_32)
#endif
extern unsigned long cpuidle_disable;
-enum idle_boot_override {IDLE_NO_OVERRIDE = 0, IDLE_POWERSAVE_OFF};
extern int powersave_nap; /* set if nap mode can be used in idle loop */
extern void power7_nap(void);
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 7b034a4..4bee51a 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -729,9 +729,6 @@ extern void init_amd_e400_c1e_mask(void);
extern unsigned long boot_option_idle_override;
extern bool amd_e400_c1e_detected;
-enum idle_boot_override {IDLE_NO_OVERRIDE=0, IDLE_HALT, IDLE_NOMWAIT,
- IDLE_POLL};
-
extern void enable_sep_cpu(void);
extern int sysenter_setup(void);
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 3fb8d95..62764ff 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -17,6 +17,7 @@
#include <linux/stackprotector.h>
#include <linux/tick.h>
#include <linux/cpuidle.h>
+#include <linux/cpu.h>
#include <trace/events/power.h>
#include <linux/hw_breakpoint.h>
#include <asm/cpu.h>
diff --git a/include/linux/cpu.h b/include/linux/cpu.h
index 03e235ad..e324561 100644
--- a/include/linux/cpu.h
+++ b/include/linux/cpu.h
@@ -220,6 +220,14 @@ void cpu_idle(void);
void cpu_idle_poll_ctrl(bool enable);
+enum idle_boot_override {
+ IDLE_NO_OVERRIDE = 0,
+ IDLE_HALT,
+ IDLE_NOMWAIT,
+ IDLE_POLL,
+ IDLE_POWERSAVE_OFF
+};
+
void arch_cpu_idle(void);
void arch_cpu_idle_prepare(void);
void arch_cpu_idle_enter(void);
--
1.8.2.2
^ permalink raw reply related
* [PATCH 0/3] ACPI: Some patches to prepare for running ACPI on !x86 and !ia64
From: Hanjun Guo @ 2014-01-17 2:03 UTC (permalink / raw)
To: linux-arm-kernel
Some of the ACPI code is arch-dependent and make the code can't be
compiled on !x86 and !ia64, the first two patches just do some rework
on the idle_boot_override and _PDC related stuff to make the ACPI
code more arch-independent.
The third patch just introduce map_gic_id() for ACPI processor core
followed by the ACPI 5.0 spec.
These three patches are just ACPI related so I send them out as
a separate patch set.
I have compiled the kernel successful after appling this patch set
on x86, ia64 and powerpc(with cross compile tool).
Changes since last RFC version:
a) Remove the RFC tag;
b) Move idle_boot_override out of the arch directory suggested
by Alan;
c) Make these 3 patches as a separate patch set since there are
not not related to the ARM/ARM64 platform.
Hanjun Guo (3):
ACPI / idle: Move idle_boot_override out of the arch directory
ACPI / processor_core: Rework _PDC related stuff to make it more
arch-independent
ACPI: Introduce map_gic_id() to get apic id from MADT or _MAT method
arch/ia64/include/asm/acpi.h | 5 +---
arch/ia64/include/asm/processor.h | 3 ---
arch/ia64/kernel/acpi.c | 17 +++++++++++++
arch/powerpc/include/asm/processor.h | 1 -
arch/x86/include/asm/acpi.h | 19 +--------------
arch/x86/include/asm/processor.h | 3 ---
arch/x86/kernel/acpi/cstate.c | 31 ++++++++++++++++++++++++
arch/x86/kernel/process.c | 1 +
drivers/acpi/processor_core.c | 47 +++++++++++++++++++++---------------
include/linux/cpu.h | 8 ++++++
10 files changed, 87 insertions(+), 48 deletions(-)
--
1.8.2.2
^ permalink raw reply
* [PATCH v4 0/7] mtd: spi-nor: add a new framework for SPI NOR
From: Huang Shijie @ 2014-01-17 2:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD6G_RRNg-uRtKnnVgJYpUGPsKecAUm9mwETVJsCsaGSuL2eCw@mail.gmail.com>
On Thu, Jan 16, 2014 at 03:09:13PM +0530, Jagan Teki wrote:
> >>> After this patch, the layer is like:
> >>> MTD
> >>> ------------------------
> >>> spi-nor
> >>> ------------------------
> >>> m25p80
> >>> ------------------------
> >>> spi bus driver
> >>> ------------------------
> >>> SPI NOR chip
>
> Just for looking on your new framework, is that above link correct.
> I guess it should be MTD -- m25p80 -- spi-nor -- spi bus driver -- SPI NOR chip
I do not think so.
The spi-nor layer does not contact with the spi bus driver directly.
> >> 3) Can you explain your framework precisely take an example of like
> >> spi_controller_A with spi_flash_A
> >> and qspi_controller_B and qspi_flash_B - how will this new framework
> >> operates.
> >>
> > The framework is just cloned from the m25p80.c, and extract the common code,
> > and provides more
> > hooks such as
> >
> > @prepare/unpreare: used to do some work before or after the
> > read/write/erase/lock/unlock.
> > @read_xfer/write_xfer: We can use these two hooks to code all
> > the following hooks if the driver tries to implement them
> > by itself.
> > @read_reg: used to read the registers, such as read status register,
> > read configure register.
> > @write_reg: used to write the registers, such as write enable,
> > erase sector.
> > @read_id: read out the ID info.
> > @wait_till_ready: wait till the NOR becomes ready.
> > @read: read out the data from the NOR.
> > @write: write data to the NOR.
> > @erase: erase a sector of the NOR.
> >
>
> My basic question is like I have a qspi spi controller in my SOC and I
> designed two boards B1 and B2
okay.
> B1 with quad spi controller connected with non-flash as a slave and B2
> with quad spi controller connected
> with quad flash as a slave.
You can use the framework for B2. But for B1, you should not use the framework,
since this framework is just for the SPI-NOR. If you do not connected with
a NOR, i think it's better to code another driver for your controller.
thanks
Huang Shijie
^ permalink raw reply
* [PATCH v4 02/15] clk: Allow drivers to pass in a regmap
From: Saravana Kannan @ 2014-01-17 1:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140115093641.4167.83109@quantum>
On 01/15/2014 01:36 AM, Mike Turquette wrote:
> Quoting Saravana Kannan (2014-01-13 19:54:42)
>> On 01/08/2014 05:51 PM, Mike Turquette wrote:
>>> Quoting Stephen Boyd (2013-12-23 17:12:26)
>>>> Add support to the clock core so that drivers can pass in a
>>>> regmap. If no regmap is specified try to query the device that's
>>>> registering the clock for its regmap. This should allow drivers
>>>> to use the core regmap helpers. This is based on a similar design
>>>> in the regulator framework.
>>>>
>>>> Cc: Mark Brown <broonie@kernel.org>
>>>> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
>>>> ---
>>>> drivers/clk/clk.c | 8 ++++++++
>>>> include/linux/clk-provider.h | 7 +++++++
>>>> 2 files changed, 15 insertions(+)
>>>>
>>>> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
>>>> index 9ad7b71..5e71f5c 100644
>>>> --- a/drivers/clk/clk.c
>>>> +++ b/drivers/clk/clk.c
>>>> @@ -20,6 +20,7 @@
>>>> #include <linux/device.h>
>>>> #include <linux/init.h>
>>>> #include <linux/sched.h>
>>>> +#include <linux/regmap.h>
>>>>
>>>> static DEFINE_SPINLOCK(enable_lock);
>>>> static DEFINE_MUTEX(prepare_lock);
>>>> @@ -1834,6 +1835,13 @@ static int _clk_register(struct device *dev, struct clk_hw *hw, struct clk *clk)
>>>> clk->num_parents = hw->init->num_parents;
>>>> hw->clk = clk;
>>>>
>>>> + if (hw->init->regmap)
>>>> + hw->regmap = hw->init->regmap;
>>>
>>> Hi Stephen,
>>>
>>> The whole series looks good to me except for the placement of the regmap
>>> details inside struct clk_hw. That structure exists only to hide struct
>>> clk from the hardware-specific clock structure and I'd not like to set
>>> the precedent of shoving per-clock data into it.
>>>
>>> As an alternative, how about finding a way to put these per-clock regmap
>>> details into the hardware-specific clock structure? I understand that
>>> you want to make these ops available to others, which is why they are in
>>> the public struct clk_hw. I'm just wondering if that is the right way to
>>> do it...
>>>
>>> Patch #3 illustrates the sort of struct-member-creep that worries me.
>>> What is to stop someone from putting "unsigned int divider_reg" or
>>> "unsigned int mux_reg", and then the thing just keeps growing.
>>
>> I agree with Mike here. This definitely encourages struct field creep if
>> more people want to use it.
>>
>> I talked to Stephen is person and my recommendation is to not have any
>> new fields other than struct regmap in clk_hw and remove the above 2
>> lines of code.
>>
>>>> + else if (dev && dev_get_regmap(dev, NULL))
>>>> + hw->regmap = dev_get_regmap(dev, NULL);
>>
>> Move "struct regmap *regmap" into struct clk_hw (since it's truly
>> reusable across clock types and is technically purely HW related) and
>> update it from the device's regmap like above.
>
> Hi Saravana,
>
> Thanks for your comments. In the paragraph above you mean "struct
> clk_hw" or do you mean the hardware-specific structure(s) defined in a
> clock driver?
>
>>
>> We can then provide __clk_regmap_enable(regmap, offset, enable_mask)
>> helper functions. Then clock specific functions can use the helper. We
>> can even a simple macro to generate these wrappers.
>>
>> #define DEFINE_REGMAP_EN_DIS(clktype) \
>>
>> int clk_type##_enable(clktype *c, ....) { }
>> int clk_type##_disable(clktype *c, ....) { }
>>
>>
>> That to me seems like a reasonable compromise.
>
> Providing common functions for the basic case (e.g. read-modify-write on
> a register using a known mask) is reasonable. But that is exactly what
> the existing basic clock types do (sans regmap) and they have all become
> pretty ugly over time. And the clk-composite implementation just makes
> me a sad panda.
>
> I'm not opposed to providing public implementations of clk_ops callbacks
> that use regmap, but I will be very mindful of any feature creep in the
> future.
>
> I am still unconvinced that adding struct regmap to struct clk_hw is a
> good idea. The regmap data is a function of hardware-specific details
> and those details always have and always will belong in the clock
> driver
The details of the bits inside the register and how it's used would be
clock type specific. Meaning, a Vendor X clock gate might have a busy
bit and Vendor Y clock gate might not have a busy bit.
Regmap doesn't try to consolidate that. I'm not saying those clock gates
should not be consolidated, but that's not what regmap is trying to do.
Regmap is helpful to consolidate clocks that behave exactly the same
way, but differ in how the clock registers are accessed. Eg: mem-mapped
IO, I2C, CP15 read/writes. So, even with a MSM based board, just because
the way to access the registers are different, we could have to
implement 3 different clock gate types. Which I think would be the wrong
thing to do. Regmap cleanly consolidates this because the clock types
just need to store the offsets and operate on them as usual using regmap
APIs.
Since the regmap for the clock is assigned based on the device that's
registering the enable/disable code for a clock gate can be agnostic of
how the registers are accesses. Yes, regmap does provide helpers for
read/modify writes, but that's not the main reason for using it.
Btw, this is a very real case on MSMs. The CPU clocks are accesses thru
CP15 instructions, and the other clock trees are accessed through
mem-mapped IO. But they pretty much behave the same way. That's what reg
map is solving.
And I think this is a common problem for ANY clock type that one might
implement. Which is why I think it should be in some common clock
struct. The clock drivers will need access to the regmap. So, I picked
clk_hw (the struct defined by the clock framework) and not struct clk.
This also allows for the framework registration code to go populate the
regmap pointer for all clocks from the regmap of the device.
Thoughts?
Thanks,
Saravana
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* [PATCH] clocksource: timer-sun5i: Switch to sched_clock_register()
From: Stephen Boyd @ 2014-01-17 1:38 UTC (permalink / raw)
To: linux-arm-kernel
The 32 bit sched_clock interface supports 64 bits since 3.13-rc1.
Upgrade to the 64 bit function to allow us to remove the 32 bit
registration interface.
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
Cc'in Ingo because this is simple enough to probably just apply to timers/core
drivers/clocksource/timer-sun5i.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clocksource/timer-sun5i.c b/drivers/clocksource/timer-sun5i.c
index bddc52233d2a..deebcd6469fc 100644
--- a/drivers/clocksource/timer-sun5i.c
+++ b/drivers/clocksource/timer-sun5i.c
@@ -136,7 +136,7 @@ static struct irqaction sun5i_timer_irq = {
.dev_id = &sun5i_clockevent,
};
-static u32 sun5i_timer_sched_read(void)
+static u64 sun5i_timer_sched_read(void)
{
return ~readl(timer_base + TIMER_CNTVAL_LO_REG(1));
}
@@ -166,7 +166,7 @@ static void __init sun5i_timer_init(struct device_node *node)
writel(TIMER_CTL_ENABLE | TIMER_CTL_RELOAD,
timer_base + TIMER_CTL_REG(1));
- setup_sched_clock(sun5i_timer_sched_read, 32, rate);
+ sched_clock_register(sun5i_timer_sched_read, 32, rate);
clocksource_mmio_init(timer_base + TIMER_CNTVAL_LO_REG(1), node->name,
rate, 340, 32, clocksource_mmio_readl_down);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply related
* [PATCH v2] ACPI: introduce CONFIG_ACPI_REDUCED_HARDWARE_ONLY to enforce this ACPI mode
From: Rafael J. Wysocki @ 2014-01-17 1:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389897857-1790-1-git-send-email-al.stone@linaro.org>
On Thursday, January 16, 2014 11:44:17 AM al.stone at linaro.org wrote:
> From: Al Stone <al.stone@linaro.org>
>
> Hardware reduced mode, despite the name, exists primarily to allow
> newer platforms to use a much simpler form of ACPI that does not
> require supporting the legacy of previous versions of the specification.
> This mode was first introduced in the ACPI 5.0 specification, but because
> it is so much simpler and reduces the size of the object code needed to
> support ACPI, it is likely to be used more often in the near future.
>
> To enable the hardware reduced mode of ACPI on some platforms (such as
> ARM), we need to modify the kernel code and set ACPI_REDUCED_HARDWARE
> to TRUE in the ACPICA source. For ARM/ARM64, hardware reduced ACPI
> should be the only mode used; legacy mode would require modifications
> to SoCs in order to provide several x86-specific hardware features (e.g.,
> an NMI and SMI support).
>
> We set ACPI_REDUCED_HARDWARE to TRUE in the ACPICA source by introducing
> a kernel config item to enable/disable ACPI_REDUCED_HARDWARE. We can then
> change the kernel config instead of having to modify the kernel source
> directly to enable the reduced hardware mode of ACPI.
>
> Lv Zheng suggested that this configuration item does not belong in ACPICA,
> the upstream source for much of the ACPI internals, but rather to the
> Linux kernel itself. Hence, we introduce this flag so that we can make
> ACPI_REDUCED_HARDWARE configurable. For the details of the discussion,
> please refer to: http://www.spinics.net/lists/linux-acpi/msg46369.html
>
> Even though support for X86 in hardware reduced mode is possible, it
> is NOT enabled. Extensive effort has gone into the Linux kernel so that
> there is a single kernel image than can run on all x86 hardware; the kernel
> changes run-time behavior to adapt to the hardware being used. This is not
> currently possible with the existing ACPICA infrastructure but only presents
> a problem on achitectures supporting both hardware-reduced and legacy modes
> of ACPI -- i.e., on x86 only.
>
> The problem with the current ACPICA code base is that if one builds legacy
> ACPI (a proper superset of hardware-reduced), the kernel can run in hardware-
> reduced with the proper ACPI tables, but there is still ACPICA code that could
> be executed even though it is not allowed by the specification. If one builds
> a hardware-reduced only ACPI, the kernel cannot run with ACPI tables that are
> for legacy mode. To ensure compliance with ACPI, one must therefore build
> two separate kernels. Once this problem has been properly fixed, we can then
> enable x86 hardware-reduced mode and use a single kernel.
>
> Changes for v2:
> -- Changed test for EXPERT to avoid reported Kconfig warning
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Signed-off-by: Al Stone <al.stone@linaro.org>
While the patch itself is fine by me, please modify the changelog.
The reason why this is useful is for some architectures to avoud building
ACPICA code that they'll never use and that's the *only* reason AFAICS.
All of the above remarks about non-compliance are totally irrelevant in my
opinion (and some of them appear to be incorrect even).
Thanks!
> ---
> drivers/acpi/Kconfig | 13 +++++++++++++
> include/acpi/platform/aclinux.h | 6 ++++++
> 2 files changed, 19 insertions(+)
>
> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index 4770de5..9fd6a7a 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -343,6 +343,19 @@ config ACPI_BGRT
> data from the firmware boot splash. It will appear under
> /sys/firmware/acpi/bgrt/ .
>
> +config ACPI_REDUCED_HARDWARE_ONLY
> + bool "Hardware-reduced ACPI support only" if EXPERT
> + def_bool n
> + depends on ACPI
> + help
> + This config item changes the way the ACPI code is built. When this
> + option is selected, the kernel will use a specialized version of
> + ACPICA that ONLY supports the ACPI "reduced hardware" mode. The
> + resulting kernel will be smaller but it will also be restricted to
> + running in ACPI reduced hardware mode ONLY.
> +
> + If you are unsure what to do, do not enable this option.
> +
> source "drivers/acpi/apei/Kconfig"
>
> config ACPI_EXTLOG
> diff --git a/include/acpi/platform/aclinux.h b/include/acpi/platform/aclinux.h
> index 28f4f4d..7d71f08 100644
> --- a/include/acpi/platform/aclinux.h
> +++ b/include/acpi/platform/aclinux.h
> @@ -52,6 +52,12 @@
>
> #ifdef __KERNEL__
>
> +/* Compile for reduced hardware mode only with this kernel config */
> +
> +#ifdef CONFIG_ACPI_REDUCED_HARDWARE_ONLY
> +#define ACPI_REDUCED_HARDWARE 1
> +#endif
> +
> #include <linux/string.h>
> #include <linux/kernel.h>
> #include <linux/ctype.h>
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* [PATCH] ARM: footbridge: Switch to sched_clock_register()
From: Stephen Boyd @ 2014-01-17 1:30 UTC (permalink / raw)
To: linux-arm-kernel
The 32 bit sched_clock interface supports 64 bits since 3.13-rc1.
Upgrade to the 64 bit function to allow us to remove the 32 bit
registration interface.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
Based on rmk/for-next
| 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--git a/arch/arm/mach-footbridge/dc21285-timer.c b/arch/arm/mach-footbridge/dc21285-timer.c
index 3971104d32d4..5d2725fd878c 100644
--- a/arch/arm/mach-footbridge/dc21285-timer.c
+++ b/arch/arm/mach-footbridge/dc21285-timer.c
@@ -125,7 +125,7 @@ void __init footbridge_timer_init(void)
clockevents_config_and_register(ce, rate, 0x4, 0xffffff);
}
-static u32 notrace footbridge_read_sched_clock(void)
+static u64 notrace footbridge_read_sched_clock(void)
{
return ~*CSR_TIMER3_VALUE;
}
@@ -138,5 +138,5 @@ void __init footbridge_sched_clock(void)
*CSR_TIMER3_CLR = 0;
*CSR_TIMER3_CNTL = TIMER_CNTL_ENABLE | TIMER_CNTL_DIV16;
- setup_sched_clock(footbridge_read_sched_clock, 24, rate);
+ sched_clock_register(footbridge_read_sched_clock, 24, rate);
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply related
* [PATCH 2/2] ARM: msm_defconfig: Enable MSM clock drivers
From: Stephen Boyd @ 2014-01-17 1:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389921904-3777-1-git-send-email-sboyd@codeaurora.org>
This allows us to probe the clock controller devices and boot to a
serial console on all DT enabled MSM platforms.
Cc: David Brown <davidb@codeaurora.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
arch/arm/configs/msm_defconfig | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/configs/msm_defconfig b/arch/arm/configs/msm_defconfig
index 0219c65cefd5..c5858b9eb516 100644
--- a/arch/arm/configs/msm_defconfig
+++ b/arch/arm/configs/msm_defconfig
@@ -114,6 +114,10 @@ CONFIG_USB_GADGET_VBUS_DRAW=500
CONFIG_NEW_LEDS=y
CONFIG_RTC_CLASS=y
CONFIG_STAGING=y
+CONFIG_COMMON_CLK_QCOM=y
+CONFIG_MSM_GCC_8660=y
+CONFIG_MSM_MMCC_8960=y
+CONFIG_MSM_MMCC_8974=y
CONFIG_MSM_IOMMU=y
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply related
* [PATCH 1/2] ARM: dts: msm: Add clock controller nodes and hook into uart
From: Stephen Boyd @ 2014-01-17 1:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389921904-3777-1-git-send-email-sboyd@codeaurora.org>
Add the necessary DT nodes to probe the clock controllers on MSM
devices as well as hook up the uart nodes to the clock
controllers. This should allow us to boot to a serial console on
all DT enabled MSM platforms.
Cc: David Brown <davidb@codeaurora.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
arch/arm/boot/dts/qcom-msm8660-surf.dts | 11 +++++++++++
arch/arm/boot/dts/qcom-msm8960-cdp.dts | 18 ++++++++++++++++++
arch/arm/boot/dts/qcom-msm8974.dtsi | 24 ++++++++++++++++++++++++
3 files changed, 53 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-msm8660-surf.dts b/arch/arm/boot/dts/qcom-msm8660-surf.dts
index 1187185cf25b..68a72f5507b9 100644
--- a/arch/arm/boot/dts/qcom-msm8660-surf.dts
+++ b/arch/arm/boot/dts/qcom-msm8660-surf.dts
@@ -2,6 +2,8 @@
/include/ "skeleton.dtsi"
+#include <dt-bindings/clock/qcom,gcc-msm8660.h>
+
/ {
model = "Qualcomm MSM8660 SURF";
compatible = "qcom,msm8660-surf", "qcom,msm8660";
@@ -37,11 +39,20 @@
#interrupt-cells = <2>;
};
+ gcc: clock-controller at 900000 {
+ compatible = "qcom,gcc-msm8660";
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ reg = <0x900000 0x4000>;
+ };
+
serial at 19c40000 {
compatible = "qcom,msm-uartdm-v1.3", "qcom,msm-uartdm";
reg = <0x19c40000 0x1000>,
<0x19c00000 0x1000>;
interrupts = <0 195 0x0>;
+ clocks = <&gcc GSBI12_UART_CLK>, <&gcc GSBI12_H_CLK>;
+ clock-names = "core", "iface";
};
qcom,ssbi at 500000 {
diff --git a/arch/arm/boot/dts/qcom-msm8960-cdp.dts b/arch/arm/boot/dts/qcom-msm8960-cdp.dts
index 6ccbac77931e..7c30de4fa302 100644
--- a/arch/arm/boot/dts/qcom-msm8960-cdp.dts
+++ b/arch/arm/boot/dts/qcom-msm8960-cdp.dts
@@ -2,6 +2,8 @@
/include/ "skeleton.dtsi"
+#include <dt-bindings/clock/qcom,gcc-msm8960.h>
+
/ {
model = "Qualcomm MSM8960 CDP";
compatible = "qcom,msm8960-cdp", "qcom,msm8960";
@@ -37,11 +39,27 @@
reg = <0x800000 0x4000>;
};
+ gcc: clock-controller at 900000 {
+ compatible = "qcom,gcc-msm8960";
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ reg = <0x900000 0x4000>;
+ };
+
+ clock-controller at 4000000 {
+ compatible = "qcom,mmcc-msm8960";
+ reg = <0x4000000 0x1000>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
serial at 16440000 {
compatible = "qcom,msm-uartdm-v1.3", "qcom,msm-uartdm";
reg = <0x16440000 0x1000>,
<0x16400000 0x1000>;
interrupts = <0 154 0x0>;
+ clocks = <&gcc GSBI5_UART_CLK>, <&gcc GSBI5_H_CLK>;
+ clock-names = "core", "iface";
};
qcom,ssbi at 500000 {
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi b/arch/arm/boot/dts/qcom-msm8974.dtsi
index 6ac94967d2d3..9e5dadb101eb 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -2,6 +2,8 @@
#include "skeleton.dtsi"
+#include <dt-bindings/clock/qcom,gcc-msm8974.h>
+
/ {
model = "Qualcomm MSM8974";
compatible = "qcom,msm8974";
@@ -93,5 +95,27 @@
compatible = "qcom,pshold";
reg = <0xfc4ab000 0x4>;
};
+
+ gcc: clock-controller at fc400000 {
+ compatible = "qcom,gcc-msm8974";
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ reg = <0xfc400000 0x4000>;
+ };
+
+ mmcc: clock-controller at fd8c0000 {
+ compatible = "qcom,mmcc-msm8974";
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ reg = <0xfd8c0000 0x6000>;
+ };
+
+ serial at f991e000 {
+ compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
+ reg = <0xf991e000 0x1000>;
+ interrupts = <0 108 0x0>;
+ clocks = <&gcc GCC_BLSP1_UART2_APPS_CLK>, <&gcc GCC_BLSP1_AHB_CLK>;
+ clock-names = "core", "iface";
+ };
};
};
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply related
* [PATCH 0/2] Enable clock controllers on MSM
From: Stephen Boyd @ 2014-01-17 1:25 UTC (permalink / raw)
To: linux-arm-kernel
These patches add the clock controller nodes, enable the clock drivers
on MSM based platforms, and hook it up enough to get the serial console
working. This is based on the merge of Mike's clk-next branch with
linux-next-20140116. The changes need the clk-next branch because that's
where the DTS include files landed.
Perhaps this can be applied after 3.14-rc1 is out?
Stephen Boyd (2):
ARM: dts: msm: Add clock controller nodes and hook into uart
ARM: msm_defconfig: Enable MSM clock drivers
arch/arm/boot/dts/qcom-msm8660-surf.dts | 11 +++++++++++
arch/arm/boot/dts/qcom-msm8960-cdp.dts | 18 ++++++++++++++++++
arch/arm/boot/dts/qcom-msm8974.dtsi | 24 ++++++++++++++++++++++++
arch/arm/configs/msm_defconfig | 4 ++++
4 files changed, 57 insertions(+)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* [PATCH] cpuidle: don't use modular platform register in non-modular ARM drivers
From: Rafael J. Wysocki @ 2014-01-17 1:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389910767-4040-1-git-send-email-paul.gortmaker@windriver.com>
On Thursday, January 16, 2014 05:19:27 PM Paul Gortmaker wrote:
> These two drivers are configured with Kconfig options that are
> both declared as bool. Hence it is not possible for the code
> to be built as modular. However the code is currently using the
> module_platform_driver() macro for driver registration.
>
> While this currently works, we really don't want to be including
> the module.h header in non-modular code, which we'll be forced
> to do, pending some upcoming code relocation from init.h into
> module.h. So we fix it now by using the non-modular equivalent.
>
> With some macro detangulation, and a little help from cpp, we can
> see that module_platform_driver(calxeda_cpuidle_plat_driver) gets
> roughly translated into:
>
> static int __init calxeda_cpuidle_plat_driver_init(void)
> {
> return platform_driver_register(&calxeda_cpuidle_plat_driver);
> }
> module_init(calxeda_cpuidle_plat_driver_init);
>
> static void __exit calxeda_cpuidle_plat_driver_exit(void)
> {
> platform_driver_unregister(&calxeda_cpuidle_plat_driver);
> }
> module_exit(calxeda_cpuidle_plat_driver_exit);
>
> [and similarly for the other file, cpuidle-zynq.c]
>
> And since we've already established that the code is non-modular,
> we can completely drop any code relating to module_exit. For non
> modular code, module_init beomes __initcall. But direct use of
> __initcall is discouraged, vs. one of the priority categorized
> subgroups. As __initcall gets mapped onto device_initcall, our
> use of device_initcall directly in this change means that the
> runtime impact is zero -- they will remain at level 6 in the
> initcall ordering.
>
> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
> Cc: Michal Simek <michal.simek@xilinx.com>
> Cc: linux-pm at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
I'd appreciate some ACKs from the ARM people.
Thanks!
> diff --git a/drivers/cpuidle/cpuidle-calxeda.c b/drivers/cpuidle/cpuidle-calxeda.c
> index 6e51114057d0..631e2cd9bce6 100644
> --- a/drivers/cpuidle/cpuidle-calxeda.c
> +++ b/drivers/cpuidle/cpuidle-calxeda.c
> @@ -78,4 +78,8 @@ static struct platform_driver calxeda_cpuidle_plat_driver = {
> .probe = calxeda_cpuidle_probe,
> };
>
> -module_platform_driver(calxeda_cpuidle_plat_driver);
> +static int __init calxeda_cpuidle_plat_driver_init(void)
> +{
> + return platform_driver_register(&calxeda_cpuidle_plat_driver);
> +}
> +device_initcall(calxeda_cpuidle_plat_driver_init);
> diff --git a/drivers/cpuidle/cpuidle-zynq.c b/drivers/cpuidle/cpuidle-zynq.c
> index aded75928028..a1aae519a573 100644
> --- a/drivers/cpuidle/cpuidle-zynq.c
> +++ b/drivers/cpuidle/cpuidle-zynq.c
> @@ -85,4 +85,8 @@ static struct platform_driver zynq_cpuidle_driver = {
> .probe = zynq_cpuidle_probe,
> };
>
> -module_platform_driver(zynq_cpuidle_driver);
> +static int __init zynq_cpuidle_driver_init(void)
> +{
> + return platform_driver_register(&zynq_cpuidle_driver);
> +}
> +device_initcall(zynq_cpuidle_driver_init);
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* [RFC PATCH V2 3/4] dt-bindings: pci: xgene pcie device tree bindings
From: Tanmay Inamdar @ 2014-01-17 1:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201401151057.43044.arnd@arndb.de>
On Wed, Jan 15, 2014 at 1:57 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday 15 January 2014, Tanmay Inamdar wrote:
>> This patch adds the bindings for X-Gene PCIe driver. The driver resides
>> under 'drivers/pci/host/pci-xgene.c' file.
>>
>> Signed-off-by: Tanmay Inamdar <tinamdar@apm.com>
>> ---
>> .../devicetree/bindings/pci/xgene-pcie.txt | 45 ++++++++++++++++++++
>> 1 file changed, 45 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/pci/xgene-pcie.txt
>>
>> diff --git a/Documentation/devicetree/bindings/pci/xgene-pcie.txt b/Documentation/devicetree/bindings/pci/xgene-pcie.txt
>> new file mode 100644
>> index 0000000..19b9c28
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/pci/xgene-pcie.txt
>> @@ -0,0 +1,45 @@
>> +* AppliedMicro X-Gene PCIe interface
>> +
>> +Required properties:
>> +- status: Either "ok" or "disabled".
>
> "status" isn't normally a required property. The default interpretation is
> that a node without a status property is active.
ok. I will move 'status' under optional properties.
>
>> +- device_type: set to "pci"
>> +- compatible: should contain "xgene,pcie" to identify the core.
>> +- reg: base addresses and lengths of the pcie controller configuration
>> + space register.
>
> Doesn't match the code or example: You only list one area here, but
> you actually need to register sets.
ok. I will update
>
> Looks good otherwise now.
>
> Arnd
^ permalink raw reply
* [RFC PATCH V2 1/4] pci: APM X-Gene PCIe controller driver
From: Tanmay Inamdar @ 2014-01-17 1:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201401151339.58593.arnd@arndb.de>
On Wed, Jan 15, 2014 at 4:39 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday 15 January 2014, Tanmay Inamdar wrote:
>> This patch adds the AppliedMicro X-Gene SOC PCIe controller driver.
>> X-Gene PCIe controller supports maxmum upto 8 lanes and GEN3 speed.
>> X-Gene has maximum 5 PCIe ports supported.
>>
>> Signed-off-by: Tanmay Inamdar <tinamdar@apm.com>
>
> This already looks much better than the first version, but I have a more
> comments. Most importantly, it would help to know how the root ports
> are structured. Is this a standard root complex and multiple ports,
> multiple root complexes with one port each, or a nonstandard organization
> that is a mix of those two models?
This is multiple root complexes with one port each.
>
>> +
>> +/* When the address bit [17:16] is 2'b01, the Configuration access will be
>> + * treated as Type 1 and it will be forwarded to external PCIe device.
>> + */
>> +static void __iomem *xgene_pcie_get_cfg_base(struct pci_bus *bus)
>> +{
>> + struct xgene_pcie_port *port = xgene_pcie_bus_to_port(bus);
>> + u64 addr = (u64)port->cfg_base;
>> +
>> + if (bus->number >= (port->first_busno + 1))
>> + addr |= AXI_EP_CFG_ACCESS;
>> +
>> + return (void *)addr;
>> +}
>
> Wrong type, it should be 'void __iomem *'. Also you can't assume that
> bit operations work on virtual __iomem addresses, so it should be better
> to just add a constant integer to the pointer, which is a valid
> operation.
ok.
>
> I also wonder why you need to do this at all. If there isn't a global
> config space for all ports, but rather a separate type0/type1 config
> cycle based on the bus number, I see that as an indication that the
> ports are in fact separate domains and should each start with bus 0.
It is not a standard ECAM layout. We also have a separate RTDID
register as well to program bus, device, function. While accessing EP
config space, we have to set the bit 17:16 as 2b'01. The same config
space address is utilized for enabling a customized nonstandard PCIe
DMA feature. The bits are defined to differentiate the access purpose.
The feature is not supported in this driver yet.
Secondly I don't think it will matter if each port starts with bus 0.
As long as we set the correct BDF in RTDID and set correct bits in
config address, the config reads and writes would work. Right?
>
>> +static void xgene_pcie_setup_lanes(struct xgene_pcie_port *port)
>> +{
>> + void *csr_base = port->csr_base;
>> + u32 val;
>> +
>> + val = readl(csr_base + BRIDGE_8G_CFG_8);
>> + val = eq_pre_cursor_lane0_set(val, 0x7);
>> + val = eq_pre_cursor_lane1_set(val, 0x7);
>> + writel(val, csr_base + BRIDGE_8G_CFG_8);
>> +
>> + val = readl(csr_base + BRIDGE_8G_CFG_9);
>> + val = eq_pre_cursor_lane0_set(val, 0x7);
>> + val = eq_pre_cursor_lane1_set(val, 0x7);
>> + writel(val, csr_base + BRIDGE_8G_CFG_9);
>> +
>> + val = readl(csr_base + BRIDGE_8G_CFG_10);
>> + val = eq_pre_cursor_lane0_set(val, 0x7);
>> + val = eq_pre_cursor_lane1_set(val, 0x7);
>> + writel(val, csr_base + BRIDGE_8G_CFG_10);
>> +
>> + val = readl(csr_base + BRIDGE_8G_CFG_11);
>> + val = eq_pre_cursor_lane0_set(val, 0x7);
>> + val = eq_pre_cursor_lane1_set(val, 0x7);
>> + writel(val, csr_base + BRIDGE_8G_CFG_11);
>> +
>> + val = readl(csr_base + BRIDGE_8G_CFG_4);
>> + val = (val & ~0x30) | (1 << 4);
>> + writel(val, csr_base + BRIDGE_8G_CFG_4);
>> +}
>
> Please document what you are actually setting here. If the configuration
> of the lanes is always the same, why do you have to set it here. If not,
> why do you set constant values?
Good point. Let me check if these values should be constant or tune-able.
>
>> +static void xgene_pcie_setup_link(struct xgene_pcie_port *port)
>> +{
>> + void *csr_base = port->csr_base;
>> + u32 val;
>> +
>> + val = readl(csr_base + BRIDGE_CFG_14);
>> + val |= DIRECT_TO_8GTS_MASK;
>> + val |= SUPPORT_5GTS_MASK;
>> + val |= SUPPORT_8GTS_MASK;
>> + val |= DIRECT_TO_5GTS_MASK;
>> + writel(val, csr_base + BRIDGE_CFG_14);
>> +
>> + val = readl(csr_base + BRIDGE_CFG_14);
>> + val &= ~ADVT_INFINITE_CREDITS;
>> + writel(val, csr_base + BRIDGE_CFG_14);
>> +
>> + val = readl(csr_base + BRIDGE_8G_CFG_0);
>> + val |= (val & ~0xf) | 7;
>> + val |= (val & ~0xf00) | ((7 << 8) & 0xf00);
>> + writel(val, csr_base + BRIDGE_8G_CFG_0);
>> +
>> + val = readl(csr_base + BRIDGE_8G_CFG_0);
>> + val |= DWNSTRM_EQ_SKP_PHS_2_3;
>> + writel(val, csr_base + BRIDGE_8G_CFG_0);
>> +}
>
> Same here.
>
>> +static void xgene_pcie_program_core(void *csr_base)
>> +{
>> + u32 val;
>> +
>> + val = readl(csr_base + BRIDGE_CFG_0);
>> + val |= AER_OPTIONAL_ERROR_EN;
>> + writel(val, csr_base + BRIDGE_CFG_0);
>> + writel(0x0, csr_base + INTXSTATUSMASK);
>> + val = readl(csr_base + BRIDGE_CTRL_1);
>> + val = (val & ~0xffff) | XGENE_PCIE_DEV_CTRL;
>> + writel(val, csr_base + BRIDGE_CTRL_1);
>> +}
>
> 'program_core'?
Some of the PCIe core related misc configurations.
>
>> +static void xgene_pcie_poll_linkup(struct xgene_pcie_port *port, u32 *lanes)
>> +{
>> + void *csr_base = port->csr_base;
>> + u32 val32;
>> + u64 start_time, time;
>> +
>> + /*
>> + * A component enters the LTSSM Detect state within
>> + * 20ms of the end of fundamental core reset.
>> + */
>> + msleep(XGENE_LTSSM_DETECT_WAIT);
>> + port->link_up = 0;
>> + start_time = jiffies;
>> + do {
>> + val32 = readl(csr_base + PCIECORE_CTLANDSTATUS);
>> + if (val32 & LINK_UP_MASK) {
>> + port->link_up = 1;
>> + port->link_speed = PIPE_PHY_RATE_RD(val32);
>> + val32 = readl(csr_base + BRIDGE_STATUS_0);
>> + *lanes = val32 >> 26;
>> + }
>> + time = jiffies_to_msecs(jiffies - start_time);
>> + } while ((!port->link_up) || (time <= XGENE_LTSSM_L0_WAIT));
>> +}
>
> Maybe another msleep() in the loop? It seems weird to first do an
> unconditional sleep but then busy-wait for the result.
ok.
>
>> +static void xgene_pcie_setup_primary_bus(struct xgene_pcie_port *port,
>> + u32 first_busno, u32 last_busno)
>> +{
>> + u32 val;
>> + void *cfg_addr = port->cfg_base;
>> +
>> + val = readl(cfg_addr + PCI_PRIMARY_BUS);
>> + val &= ~PCI_PRIMARY_BUS_MASK;
>> + val |= (last_busno << 16) | ((first_busno + 1) << 8) | (first_busno);
>> + writel(val, cfg_addr + PCI_PRIMARY_BUS);
>> +}
>
> Please explain what you are doing here. As mentioned above, I would expect
> that each domain has visibility of all 255 buses. You shouldn't need any hacks
> where you try to artificially squeeze the ports into a single domain when
> they are separate in hardware.
ok. I will check and get back.
>
>> +/*
>> + * read configuration values from DTS
>> + */
>> +static int xgene_pcie_read_dts_config(struct xgene_pcie_port *port)
>
> The comment and function name don't seem to match what the function
> does. The main purpose of this function seems to be to ioremap
> the resources, which have nothing to with configuration.
ok.
>
>> +{
>> + struct device_node *np = port->node;
>> + struct resource csr_res;
>> + struct resource cfg_res;
>> +
>> + /* Get CSR space registers address */
>> + if (of_address_to_resource(np, 0, &csr_res))
>> + return -EINVAL;
>> +
>> + port->csr_base = devm_ioremap_nocache(port->dev, csr_res.start,
>> + resource_size(&csr_res));
>
> You can also use platform_get_resource() to access the resource
> that is already there, rather than creating another one.
ok.
>
>> +static void xgene_pcie_setup_ob_reg(struct xgene_pcie_port *port,
>> + u32 addr, u32 restype)
>> +{
>> + struct resource *res = NULL;
>> + void *base = port->csr_base + addr;
>> + resource_size_t size;
>> + u64 cpu_addr = 0;
>> + u64 pci_addr = 0;
>> + u64 mask = 0;
>> + u32 min_size = 0;
>
> A general note: don't initialize local variables to a bogus valus (e.g. 0)
> in their declaration. It prevents the compiler from warning about
> incorrect uses.
ok.
>
>> + u32 flag = EN_REG;
>
> This one on the other hand is ok, because you are actually going to
> use that value.
>
>> + switch (restype) {
>> + case IORESOURCE_MEM:
>> + res = &port->mem.res;
>> + pci_addr = port->mem.pci_addr;
>> + min_size = SZ_128M;
>> + break;
>> + case IORESOURCE_IO:
>> + res = &port->io.res;
>> + pci_addr = port->io.pci_addr;
>> + min_size = 128;
>> + flag |= OB_LO_IO;
>> + break;
>> + }
>
> I assume this works ok, but seems wrong in one detail: If the resource
> is marked IORESOURCE_IO, res->start is supposed to be in I/O space, not
> in memory space, which would make it the wrong number to program
> into the hardware registers.
Yes for using ioport resource. However we have decided to defer using
it since 'pci_ioremap_io' is not yet supported from arm64 side.
>From HW point of view, for memory mapped IO space, it is nothing but a
piece taken out of the ranges in address map for outbound accesses. So
while configuring registers from SOC side, it should take the CPU
address which is address from SOC address map. Right?
Later on we can have a separate io resource like 'realio' similar to
what pci-mvebu.c does.
>
>> +static int xgene_pcie_parse_map_ranges(struct xgene_pcie_port *port)
>> +{
>> + struct device_node *np = port->node;
>> + struct of_pci_range range;
>> + struct of_pci_range_parser parser;
>> + struct device *dev = port->dev;
>> +
>> + if (of_pci_range_parser_init(&parser, np)) {
>> + dev_err(dev, "missing ranges property\n");
>> + return -EINVAL;
>> + }
>> +
>> + /* Get the I/O, memory, config ranges from DT */
>
> The comment needs updating now that you don't read config space here any more.
ok.
>
>> +/* X-Gene PCIe support maximum 3 inbound memory regions
>> + * This function helps to select a region based on size of region
>> + */
>> +static int xgene_pcie_select_ib_reg(u64 size)
>> +{
>> + static u8 ib_reg_mask;
>> +
>> + if ((size > 4) && (size < SZ_16M) && !(ib_reg_mask & (1 << 1))) {
>> + ib_reg_mask |= (1 << 1);
>> + return 1;
>> + }
>> +
>> + if ((size > SZ_1K) && (size < SZ_1T) && !(ib_reg_mask & (1 << 0))) {
>> + ib_reg_mask |= (1 << 0);
>> + return 0;
>> + }
>> +
>> + if ((size > SZ_1M) && (size < SZ_1T) && !(ib_reg_mask & (1 << 2))) {
>> + ib_reg_mask |= (1 << 2);
>> + return 2;
>> + }
>> + return -EINVAL;
>> +}
>
> Shouldn't the ib_reg_mask variable be per host bridge? Static variables
> are dangerous if you ever get multiple instances of the hardware in one
> system.
Yes. You are right. Thanks.
>
>> +static int xgene_pcie_parse_map_dma_ranges(struct xgene_pcie_port *port)
>> +{
>> + struct device_node *np = port->node;
>> + struct of_pci_range range;
>> + struct of_pci_range_parser parser;
>> + struct device *dev = port->dev;
>> + int region;
>> +
>> + if (pci_dma_range_parser_init(&parser, np)) {
>> + dev_err(dev, "missing dma-ranges property\n");
>> + return -EINVAL;
>> + }
>> +
>> + /* Get the dma-ranges from DT */
>> + for_each_of_pci_range(&parser, &range) {
>> + u64 restype = range.flags & IORESOURCE_TYPE_BITS;
>> + u64 end = range.cpu_addr + range.size - 1;
>> + dev_dbg(port->dev, "0x%08x 0x%016llx..0x%016llx -> 0x%016llx\n",
>> + range.flags, range.cpu_addr, end, range.pci_addr);
>> + region = xgene_pcie_select_ib_reg(range.size);
>> + if (region == -EINVAL) {
>> + dev_warn(port->dev, "invalid pcie dma-range config\n");
>> + continue;
>> + }
>> + xgene_pcie_setup_ib_reg(port, &range, restype, region);
>> + }
>> + return 0;
>> +}
>
> I guess is could even be a local variable in this function, which you pass
> by reference.
>
>> +
>> +static int xgene_pcie_setup(int nr, struct pci_sys_data *sys)
>> +{
>> + struct xgene_pcie_port *pp = xgene_pcie_sys_to_port(sys);
>> +
>> + if (pp == NULL)
>> + return 0;
>> +
>> + sys->mem_offset = pp->mem.res.start - pp->mem.pci_addr;
>> + pci_add_resource_offset(&sys->resources, &pp->mem.res,
>> + sys->mem_offset);
>> + return 1;
>> +}
>
> Please follow the regular error handling conventions, which are to
> pass a negative errno value on error and zero on success.
ok.
>
> Also, what would be a reason for the port to be zero here? If
> it's something that can't happen in practice, don't try to handle
> it gracefully. You can use BUG_ON() for fatal conditions that
> are supposed to be impossible to reach.
This function is a hook to upper layer. We register nr_controllers in
hw_pci structure as MAX_PORTS we support. It can happen that number of
ports actually enabled from device tree are less than the number in
nr_controllers.
>
>> +static struct pci_bus __init *xgene_pcie_scan_bus(int nr,
>> + struct pci_sys_data *sys)
>> +{
>> + struct xgene_pcie_port *pp = xgene_pcie_sys_to_port(sys);
>> +
>> + pp->first_busno = sys->busnr;
>> + xgene_pcie_setup_primary_bus(pp, sys->busnr, 0xff);
>> + return pci_scan_root_bus(NULL, sys->busnr, &xgene_pcie_ops,
>> + sys, &sys->resources);
>> +}
>
> You have a number of helper functions that don't seem to gain
> much at all. Just move the call to pci_scan_root_bus() into
> xgene_pcie_setup_primary_bus() here, and use that as the .scan
> callback.
>
I can do that if I can get rid of setup_primary_bus api. Let me check.
>
>> + if (!port->link_up)
>> + dev_info(port->dev, "(rc) link down\n");
>> + else
>> + dev_info(port->dev, "(rc) x%d gen-%d link up\n",
>> + lanes, port->link_speed + 1);
>> +#ifdef CONFIG_PCI_DOMAINS
>> + xgene_pcie_hw.domain++;
>> +#endif
>> + xgene_pcie_hw.private_data[index++] = port;
>> + platform_set_drvdata(pdev, port);
>> + return 0;
>> +}
>
> Do you have multiple domains or not? I don't see how it can work if you
> make the domain setup conditional on a kernel configuration option.
> If you in fact have multiple domains, make sure in Kconfig that
> CONFIG_PCI_DOMAINS is enabled. Otherwise don't mess with the domain
> number...
It is enabled in Kconfig.
>
>> +static const struct of_device_id xgene_pcie_match_table[] __initconst = {
>> + {.compatible = "apm,xgene-pcie",},
>> + {},
>> +};
>
> Another general note: Your "compatible" strings are rather unspecific.
> Do you have a version number for this IP block? I suppose that it's related
> to one that has been used in other chips before, or will be used in future
> chips, if it's not actually licensed from some other company.
I will have to check this.
>
>> +static int __init xgene_pcie_init(void)
>> +{
>> + void *private;
>> + int ret;
>> +
>> + pr_info("X-Gene: PCIe driver\n");
>> +
>> + /* allocate private data to keep xgene_pcie_port information */
>> + private = kzalloc((XGENE_PCIE_MAX_PORTS * sizeof(void *)), GFP_KERNEL);
>
> This should not be done unconditionally: There is no point in printing
> a message or allocating memory if you don't actually run on a system
> with this device.
I am doing this here because I have one instance of hw_pci structure
with multiple pcie controllers. I can't do it from probe since it will
be called once per instance in device tree.
>
>> + if (private == NULL)
>> + return -ENOMEM;
>
> Style: if you are testing for an object, just write 'if (private)' or
> 'if (!private)', but don't compare against NULL.
ok.
>
>> + xgene_pcie_hw.private_data = private;
>> + ret = platform_driver_probe(&xgene_pcie_driver,
>> + xgene_pcie_probe_bridge);
>> + if (ret)
>> + return ret;
>> + pci_common_init(&xgene_pcie_hw);
>> + return 0;
>
> This seems wrong: You should not use platform_driver_probe() because
> that has issues with deferred probing.
I think 'platform_driver_probe' prevents the deferred probing.
'pci_common_init' needs to be called only once with current driver
structure. The probes for all pcie ports should be finished (ports
initialized) before 'pci_common_init' gets called.
>
> Arnd
^ permalink raw reply
* [PATCH v2 2/2] i2c: New bus driver for the QUP I2C controller
From: Stephen Boyd @ 2014-01-17 0:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140117001833.GL30911@sonymobile.com>
On 01/16, Bjorn Andersson wrote:
> On Wed 15 Jan 08:46 PST 2014, Stephen Boyd wrote:
>
> > On 01/13, Bjorn Andersson wrote:
> > > +
> > > +static int
> > > +qup_i2c_poll_state(struct qup_i2c_dev *qup, u32 req_state, bool only_valid)
> > > +{
> > > + int retries = 0;
> > > + u32 state;
> > > +
> > > + do {
> > > + state = readl(qup->base + QUP_STATE);
> > > +
> > > + /*
> > > + * If only valid bit needs to be checked, requested state is
> > > + * 'don't care'
> > > + */
> >
> > It looks like req_state == 0 means only_valid == true. Can we
> > drop the only_valid argument to this function?
> >
>
> In all cases but the reset in the beginning of qup_i2c_xfer, so it seems that
> it has to stay.
Oh that's because QUP_RESET_STATE is equal to 0? It looks like
bits 0 and 1 are the state field and bit 2 is a flag indicating
that bits 0 and 1 are valid. Why not OR in the QUP_STATE_VALID
flag into the macros that are passed to this function? Then the
logic would simply be looping looking for a match of the
req_state (which is really a mask now).
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* [PATCH v7 4/4] ARM: shmobile: genmai: Enable r7s72100-ether
From: Simon Horman @ 2014-01-17 0:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389918150-19058-1-git-send-email-horms+renesas@verge.net.au>
Signed-off-by: Simon Horman <horms@verge.net.au>
Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
Dave, I am planning to take this change through my tree.
v3 - v7
* No change
v2
* As suggested by Magnus Damm and Sergei Shtylyov
- r7s72100 ethernet is not gigabit so do not refer to it as such
* As suggested by Sergei Shtylyov
- set no_ether_link as there is no LINK signal documented
in the manual
---
arch/arm/mach-shmobile/board-genmai.c | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/arch/arm/mach-shmobile/board-genmai.c b/arch/arm/mach-shmobile/board-genmai.c
index 3e92e3c..a1f6fe1 100644
--- a/arch/arm/mach-shmobile/board-genmai.c
+++ b/arch/arm/mach-shmobile/board-genmai.c
@@ -20,15 +20,36 @@
#include <linux/kernel.h>
#include <linux/platform_device.h>
+#include <linux/sh_eth.h>
#include <mach/common.h>
+#include <mach/irqs.h>
#include <mach/r7s72100.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
+/* Ether */
+static const struct sh_eth_plat_data ether_pdata __initconst = {
+ .phy = 0x00, /* PD60610 */
+ .edmac_endian = EDMAC_LITTLE_ENDIAN,
+ .phy_interface = PHY_INTERFACE_MODE_MII,
+ .no_ether_link = 1
+};
+
+static const struct resource ether_resources[] __initconst = {
+ DEFINE_RES_MEM(0xe8203000, 0x800),
+ DEFINE_RES_MEM(0xe8204800, 0x200),
+ DEFINE_RES_IRQ(gic_iid(359)),
+};
+
static void __init genmai_add_standard_devices(void)
{
r7s72100_clock_init();
r7s72100_add_dt_devices();
+
+ platform_device_register_resndata(&platform_bus, "r7s72100-ether", -1,
+ ether_resources,
+ ARRAY_SIZE(ether_resources),
+ ðer_pdata, sizeof(ether_pdata));
}
static const char * const genmai_boards_compat_dt[] __initconst = {
--
1.8.4
^ permalink raw reply related
* [PATCH v7 3/4] ARM: shmobile: r7s72100: Add clock for r7s72100-ether
From: Simon Horman @ 2014-01-17 0:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389918150-19058-1-git-send-email-horms+renesas@verge.net.au>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
Dave, I am planning to take this change through my tree.
v6 - v7
* No change
v5
* Rebase
v3 - v4
* No change
v2
* As suggested by Sergei Shtylyov
- Add MSTP74 to beginning of enum on a line by itself
* As suggested by Magnus Damm
- r7s72100 ethernet is not gigabit so do not refer to it as such
---
arch/arm/mach-shmobile/clock-r7s72100.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/mach-shmobile/clock-r7s72100.c b/arch/arm/mach-shmobile/clock-r7s72100.c
index dd8ce87..0242ca5 100644
--- a/arch/arm/mach-shmobile/clock-r7s72100.c
+++ b/arch/arm/mach-shmobile/clock-r7s72100.c
@@ -27,6 +27,7 @@
#define FRQCR2 0xfcfe0014
#define STBCR3 0xfcfe0420
#define STBCR4 0xfcfe0424
+#define STBCR7 0xfcfe0430
#define STBCR9 0xfcfe0438
#define PLL_RATE 30
@@ -146,6 +147,7 @@ struct clk div4_clks[DIV4_NR] = {
};
enum { MSTP97, MSTP96, MSTP95, MSTP94,
+ MSTP74,
MSTP47, MSTP46, MSTP45, MSTP44, MSTP43, MSTP42, MSTP41, MSTP40,
MSTP33, MSTP_NR };
@@ -154,6 +156,7 @@ static struct clk mstp_clks[MSTP_NR] = {
[MSTP96] = SH_CLK_MSTP8(&peripheral0_clk, STBCR9, 6, 0), /* RIIC1 */
[MSTP95] = SH_CLK_MSTP8(&peripheral0_clk, STBCR9, 5, 0), /* RIIC2 */
[MSTP94] = SH_CLK_MSTP8(&peripheral0_clk, STBCR9, 4, 0), /* RIIC3 */
+ [MSTP74] = SH_CLK_MSTP8(&peripheral1_clk, STBCR7, 4, 0), /* Ether */
[MSTP47] = SH_CLK_MSTP8(&peripheral1_clk, STBCR4, 7, 0), /* SCIF0 */
[MSTP46] = SH_CLK_MSTP8(&peripheral1_clk, STBCR4, 6, 0), /* SCIF1 */
[MSTP45] = SH_CLK_MSTP8(&peripheral1_clk, STBCR4, 5, 0), /* SCIF2 */
@@ -180,6 +183,7 @@ static struct clk_lookup lookups[] = {
CLKDEV_DEV_ID("fcfee400.i2c", &mstp_clks[MSTP96]),
CLKDEV_DEV_ID("fcfee800.i2c", &mstp_clks[MSTP95]),
CLKDEV_DEV_ID("fcfeec00.i2c", &mstp_clks[MSTP94]),
+ CLKDEV_DEV_ID("r7s72100-ether", &mstp_clks[MSTP74]),
CLKDEV_CON_ID("mtu2_fck", &mstp_clks[MSTP33]),
/* ICK */
--
1.8.4
^ permalink raw reply related
* [PATCH v7 net-next 2/4] sh_eth: Add support for r7s72100
From: Simon Horman @ 2014-01-17 0:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389918150-19058-1-git-send-email-horms+renesas@verge.net.au>
The r7s72100 SoC includes a fast ethernet controller.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
Dave, please consider this for net-next.
v7
* No change
v6
* As suggested by Sergei Shtylyov
- Update changelog
- Position sh_eth_offset_fast_rz above sh_eth_offset_fast_rcar
- Place [TR]X[NA]LCR0 in a separate group in sh_eth_offset_fast_rz
- Simplify logic of sh_eth_is_rz_fast_ether
- Add comma after and in comment.
v5
* As suggested by Sergei Shtylyov
- Add the following missing registers to sh_eth_offset_fast_rz:
RFLR, [TR]X[NA]LCR0.
- Set the following in r7s72100_data: no_psr, no_ade, hw_crc.
- Use EDTRR_TRNS_GETHER instead of adding EDTRR_TRNS_RZ_ETHER.
- Position SH_ETH_REG_FAST_RZ before SH_ETH_REG_FAST_RCAR.
- Do not remove ',' from before 'and' in EDSR comment
v4
* As requested by David Miller
- Use a boolean for the return value of sh_eth_is_rz_fast_ether()
- Correct coding style in sh_eth_get_stats()
v3
* No change
v2
* As suggested by Magnus Damm and Sergei Shtylyov
- r7s72100 ethernet is not gigabit so do not refer to it as such
* As suggested by Magnus Damm
- As RZ specific register layout rather than using the gigabit layout
which includes registers that do not exist on this chip.
* As suggested by Sergei Shtylyov
- Do not use sh_eth_chip_reset_r8a7740 as it accesses non-existent
RMII registers. Instead use sh_eth_chip_reset.
- Do not use sh_eth_set_rate_gether as it accesses non-existent registers.
- Do not use reserved LCHNG bit of ECSR
- Do not use reserved LCHNGIP bit of ECSIPR
- Document that R8A779x also needs a 16 bit shift of the RFS bits
- Do not document that the R7S72100 has GECMR, it does not
---
drivers/net/ethernet/renesas/sh_eth.c | 124 ++++++++++++++++++++++++++++++++--
drivers/net/ethernet/renesas/sh_eth.h | 3 +-
2 files changed, 119 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/renesas/sh_eth.c b/drivers/net/ethernet/renesas/sh_eth.c
index f12a929..a21be4a 100644
--- a/drivers/net/ethernet/renesas/sh_eth.c
+++ b/drivers/net/ethernet/renesas/sh_eth.c
@@ -144,6 +144,65 @@ static const u16 sh_eth_offset_gigabit[SH_ETH_MAX_REGISTER_OFFSET] = {
[FWALCR1] = 0x00b4,
};
+static const u16 sh_eth_offset_fast_rz[SH_ETH_MAX_REGISTER_OFFSET] = {
+ [EDSR] = 0x0000,
+ [EDMR] = 0x0400,
+ [EDTRR] = 0x0408,
+ [EDRRR] = 0x0410,
+ [EESR] = 0x0428,
+ [EESIPR] = 0x0430,
+ [TDLAR] = 0x0010,
+ [TDFAR] = 0x0014,
+ [TDFXR] = 0x0018,
+ [TDFFR] = 0x001c,
+ [RDLAR] = 0x0030,
+ [RDFAR] = 0x0034,
+ [RDFXR] = 0x0038,
+ [RDFFR] = 0x003c,
+ [TRSCER] = 0x0438,
+ [RMFCR] = 0x0440,
+ [TFTR] = 0x0448,
+ [FDR] = 0x0450,
+ [RMCR] = 0x0458,
+ [RPADIR] = 0x0460,
+ [FCFTR] = 0x0468,
+ [CSMR] = 0x04E4,
+
+ [ECMR] = 0x0500,
+ [RFLR] = 0x0508,
+ [ECSR] = 0x0510,
+ [ECSIPR] = 0x0518,
+ [PIR] = 0x0520,
+ [APR] = 0x0554,
+ [MPR] = 0x0558,
+ [PFTCR] = 0x055c,
+ [PFRCR] = 0x0560,
+ [TPAUSER] = 0x0564,
+ [MAHR] = 0x05c0,
+ [MALR] = 0x05c8,
+ [CEFCR] = 0x0740,
+ [FRECR] = 0x0748,
+ [TSFRCR] = 0x0750,
+ [TLFRCR] = 0x0758,
+ [RFCR] = 0x0760,
+ [MAFCR] = 0x0778,
+
+ [ARSTR] = 0x0000,
+ [TSU_CTRST] = 0x0004,
+ [TSU_VTAG0] = 0x0058,
+ [TSU_ADSBSY] = 0x0060,
+ [TSU_TEN] = 0x0064,
+ [TSU_ADRH0] = 0x0100,
+ [TSU_ADRL0] = 0x0104,
+ [TSU_ADRH31] = 0x01f8,
+ [TSU_ADRL31] = 0x01fc,
+
+ [TXNLCR0] = 0x0080,
+ [TXALCR0] = 0x0084,
+ [RXNLCR0] = 0x0088,
+ [RXALCR0] = 0x008C,
+};
+
static const u16 sh_eth_offset_fast_rcar[SH_ETH_MAX_REGISTER_OFFSET] = {
[ECMR] = 0x0300,
[RFLR] = 0x0308,
@@ -315,6 +374,11 @@ static bool sh_eth_is_gether(struct sh_eth_private *mdp)
return mdp->reg_offset == sh_eth_offset_gigabit;
}
+static bool sh_eth_is_rz_fast_ether(struct sh_eth_private *mdp)
+{
+ return mdp->reg_offset == sh_eth_offset_fast_rz;
+}
+
static void sh_eth_select_mii(struct net_device *ndev)
{
u32 value = 0x0;
@@ -698,6 +762,38 @@ static struct sh_eth_cpu_data r8a7740_data = {
.shift_rd0 = 1,
};
+/* R7S72100 */
+static struct sh_eth_cpu_data r7s72100_data = {
+ .chip_reset = sh_eth_chip_reset,
+ .set_duplex = sh_eth_set_duplex,
+
+ .register_type = SH_ETH_REG_FAST_RZ,
+
+ .ecsr_value = ECSR_ICD,
+ .ecsipr_value = ECSIPR_ICDIP,
+ .eesipr_value = 0xff7f009f,
+
+ .tx_check = EESR_TC1 | EESR_FTC,
+ .eesr_err_check = EESR_TWB1 | EESR_TWB | EESR_TABT | EESR_RABT |
+ EESR_RFE | EESR_RDE | EESR_RFRMER | EESR_TFE |
+ EESR_TDE | EESR_ECI,
+ .fdr_value = 0x0000070f,
+ .rmcr_value = RMCR_RNC,
+
+ .no_psr = 1,
+ .apr = 1,
+ .mpr = 1,
+ .tpauser = 1,
+ .hw_swap = 1,
+ .rpadir = 1,
+ .rpadir_value = 2 << 16,
+ .no_trimd = 1,
+ .no_ade = 1,
+ .hw_crc = 1,
+ .tsu = 1,
+ .shift_rd0 = 1,
+};
+
static struct sh_eth_cpu_data sh7619_data = {
.register_type = SH_ETH_REG_FAST_SH3_SH2,
@@ -764,7 +860,7 @@ static int sh_eth_reset(struct net_device *ndev)
struct sh_eth_private *mdp = netdev_priv(ndev);
int ret = 0;
- if (sh_eth_is_gether(mdp)) {
+ if (sh_eth_is_gether(mdp) || sh_eth_is_rz_fast_ether(mdp)) {
sh_eth_write(ndev, EDSR_ENALL, EDSR);
sh_eth_write(ndev, sh_eth_read(ndev, EDMR) | EDMR_SRST_GETHER,
EDMR);
@@ -875,7 +971,7 @@ static void read_mac_address(struct net_device *ndev, unsigned char *mac)
static unsigned long sh_eth_get_edtrr_trns(struct sh_eth_private *mdp)
{
- if (sh_eth_is_gether(mdp))
+ if (sh_eth_is_gether(mdp) || sh_eth_is_rz_fast_ether(mdp))
return EDTRR_TRNS_GETHER;
else
return EDTRR_TRNS_ETHER;
@@ -1038,7 +1134,8 @@ static void sh_eth_ring_format(struct net_device *ndev)
/* Rx descriptor address set */
if (i == 0) {
sh_eth_write(ndev, mdp->rx_desc_dma, RDLAR);
- if (sh_eth_is_gether(mdp))
+ if (sh_eth_is_gether(mdp) ||
+ sh_eth_is_rz_fast_ether(mdp))
sh_eth_write(ndev, mdp->rx_desc_dma, RDFAR);
}
}
@@ -1059,7 +1156,8 @@ static void sh_eth_ring_format(struct net_device *ndev)
if (i == 0) {
/* Tx descriptor address set */
sh_eth_write(ndev, mdp->tx_desc_dma, TDLAR);
- if (sh_eth_is_gether(mdp))
+ if (sh_eth_is_gether(mdp) ||
+ sh_eth_is_rz_fast_ether(mdp))
sh_eth_write(ndev, mdp->tx_desc_dma, TDFAR);
}
}
@@ -1306,9 +1404,9 @@ static int sh_eth_rx(struct net_device *ndev, u32 intr_status, int *quota)
/* In case of almost all GETHER/ETHERs, the Receive Frame State
* (RFS) bits in the Receive Descriptor 0 are from bit 9 to
- * bit 0. However, in case of the R8A7740's GETHER, the RFS
- * bits are from bit 25 to bit 16. So, the driver needs right
- * shifting by 16.
+ * bit 0. However, in case of the R8A7740, R8A779x, and
+ * R7S72100 the RFS bits are from bit 25 to bit 16. So, the
+ * driver needs right shifting by 16.
*/
if (mdp->cd->shift_rd0)
desc_status >>= 16;
@@ -2058,6 +2156,9 @@ static struct net_device_stats *sh_eth_get_stats(struct net_device *ndev)
{
struct sh_eth_private *mdp = netdev_priv(ndev);
+ if (sh_eth_is_rz_fast_ether(mdp))
+ return &ndev->stats;
+
pm_runtime_get_sync(&mdp->pdev->dev);
ndev->stats.tx_dropped += sh_eth_read(ndev, TROCR);
@@ -2439,6 +2540,11 @@ static int sh_eth_vlan_rx_kill_vid(struct net_device *ndev,
/* SuperH's TSU register init function */
static void sh_eth_tsu_init(struct sh_eth_private *mdp)
{
+ if (sh_eth_is_rz_fast_ether(mdp)) {
+ sh_eth_tsu_write(mdp, 0, TSU_TEN); /* Disable all CAM entry */
+ return;
+ }
+
sh_eth_tsu_write(mdp, 0, TSU_FWEN0); /* Disable forward(0->1) */
sh_eth_tsu_write(mdp, 0, TSU_FWEN1); /* Disable forward(1->0) */
sh_eth_tsu_write(mdp, 0, TSU_FCM); /* forward fifo 3k-3k */
@@ -2558,6 +2664,9 @@ static const u16 *sh_eth_get_register_offset(int register_type)
case SH_ETH_REG_GIGABIT:
reg_offset = sh_eth_offset_gigabit;
break;
+ case SH_ETH_REG_FAST_RZ:
+ reg_offset = sh_eth_offset_fast_rz;
+ break;
case SH_ETH_REG_FAST_RCAR:
reg_offset = sh_eth_offset_fast_rcar;
break;
@@ -2796,6 +2905,7 @@ static struct platform_device_id sh_eth_id_table[] = {
{ "sh7757-ether", (kernel_ulong_t)&sh7757_data },
{ "sh7757-gether", (kernel_ulong_t)&sh7757_data_giga },
{ "sh7763-gether", (kernel_ulong_t)&sh7763_data },
+ { "r7s72100-ether", (kernel_ulong_t)&r7s72100_data },
{ "r8a7740-gether", (kernel_ulong_t)&r8a7740_data },
{ "r8a777x-ether", (kernel_ulong_t)&r8a777x_data },
{ "r8a7790-ether", (kernel_ulong_t)&r8a779x_data },
diff --git a/drivers/net/ethernet/renesas/sh_eth.h b/drivers/net/ethernet/renesas/sh_eth.h
index 0fe35b7..6075915 100644
--- a/drivers/net/ethernet/renesas/sh_eth.h
+++ b/drivers/net/ethernet/renesas/sh_eth.h
@@ -155,6 +155,7 @@ enum {
enum {
SH_ETH_REG_GIGABIT,
+ SH_ETH_REG_FAST_RZ,
SH_ETH_REG_FAST_RCAR,
SH_ETH_REG_FAST_SH4,
SH_ETH_REG_FAST_SH3_SH2
@@ -169,7 +170,7 @@ enum {
/* Register's bits
*/
-/* EDSR : sh7734, sh7757, sh7763, and r8a7740 only */
+/* EDSR : sh7734, sh7757, sh7763, r8a7740, and r7s72100 only */
enum EDSR_BIT {
EDSR_ENT = 0x01, EDSR_ENR = 0x02,
};
--
1.8.4
^ permalink raw reply related
* [PATCH v7 net-next 1/4] sh_eth: Use bool as return type of sh_eth_is_gether()
From: Simon Horman @ 2014-01-17 0:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389918150-19058-1-git-send-email-horms+renesas@verge.net.au>
Return a boolean from sh_eth_is_gether() and refactor it as a one-liner.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
Dave, please consider this for net-next.
v7
* Updated changelog
v6
* Simplify logic as suggested by Joe Perches
v5
* No change
v4
* First post
---
drivers/net/ethernet/renesas/sh_eth.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/renesas/sh_eth.c b/drivers/net/ethernet/renesas/sh_eth.c
index ba1f6c9..f12a929 100644
--- a/drivers/net/ethernet/renesas/sh_eth.c
+++ b/drivers/net/ethernet/renesas/sh_eth.c
@@ -310,12 +310,9 @@ static const u16 sh_eth_offset_fast_sh3_sh2[SH_ETH_MAX_REGISTER_OFFSET] = {
[TSU_ADRL31] = 0x01fc,
};
-static int sh_eth_is_gether(struct sh_eth_private *mdp)
+static bool sh_eth_is_gether(struct sh_eth_private *mdp)
{
- if (mdp->reg_offset == sh_eth_offset_gigabit)
- return 1;
- else
- return 0;
+ return mdp->reg_offset == sh_eth_offset_gigabit;
}
static void sh_eth_select_mii(struct net_device *ndev)
--
1.8.4
^ permalink raw reply related
* [PATCH v7 0/4] Add ethernet support for r7s72100
From: Simon Horman @ 2014-01-17 0:22 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
this series adds ethernet support to sh-pfc for the r7s72100 SoC.
This series is based on a merge of:
* The topic/r7s72100-v3.13-rc8-20140115 tag in my renesas tree
* net-next
- Head revision: 08c93cd99b2f31ba9
("Merge branch 'for-davem' of git://gitorious.org/linux-can/linux-can-next")
The first two patches, targeted at net-next, also applies cleanly there.
Changes since v6
* Update change log of:
- sh_eth: Use bool as return type of sh_eth_is_gether()
Changes since v5
* Address feedback from Joe Perches and Sergei Shtylyov as detailed
in the changelogs of:
- sh_eth: Use bool as return type of sh_eth_is_gether()
- sh_eth: Add support for r7s72100
Changes since v4
* Addressed feedback from Sergei Shtylyov as detailed in the changelog
of "sh_eth: Add support for r7s72100"
* Rebase
Changes since v3
* Use bool as return type of sh_eth_is_gether()
and sh_eth_is_rz_fast_ether()
* Correct coding style in sh_eth_get_stats()
Changes since v2
* Trivial rebase
* Dropped "RFC" from subject
Changes since v1 are noted in the changelog of each patch.
Simon Horman (4):
sh_eth: Use bool as return type of sh_eth_is_gether()
sh_eth: Add support for r7s72100
ARM: shmobile: r7s72100: Add clock for r7s72100-ether
ARM: shmobile: genmai: Enable r7s72100-ether
arch/arm/mach-shmobile/board-genmai.c | 21 +++++
arch/arm/mach-shmobile/clock-r7s72100.c | 4 +
drivers/net/ethernet/renesas/sh_eth.c | 131 +++++++++++++++++++++++++++++---
drivers/net/ethernet/renesas/sh_eth.h | 3 +-
4 files changed, 146 insertions(+), 13 deletions(-)
--
1.8.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