* [PATCH CFT] arm: netx: Migrate DEBUG_LL macros to shared directory
From: Daniel Thompson @ 2014-07-23 9:41 UTC (permalink / raw)
To: linux-arm-kernel
As part of the migration we introduce DEBUG_UART_PHYS/DEBUG_UART_VIRT
which default to UART1 but allow a user to configure UART2 or UART3.
We also introduce symbolic names for the registers and flags.
Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Arnd Bergmann <arnd.bergmann@linaro.org>
Cc: linux-arm-kernel at lists.infradead.org
---
arch/arm/Kconfig.debug | 17 +++++++++++++++--
.../mach/debug-macro.S => include/debug/netx.S} | 22 +++++++++++-----------
2 files changed, 26 insertions(+), 13 deletions(-)
rename arch/arm/{mach-netx/include/mach/debug-macro.S => include/debug/netx.S} (62%)
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 762b3ed..c7e05b7 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -439,6 +439,14 @@ choice
Say Y here if you want kernel low-level debugging support
on Vybrid based platforms.
+ config DEBUG_NETX_UART
+ bool "Kernel low-level debugging messages via NetX UART"
+ depends on ARCH_NETX
+ select DEBUG_UART_NETX
+ help
+ Say Y here if you want kernel low-level debugging support
+ on Hilscher NetX based platforms.
+
config DEBUG_NOMADIK_UART
bool "Kernel low-level debugging messages via NOMADIK UART"
depends on ARCH_NOMADIK
@@ -1063,6 +1071,7 @@ config DEBUG_LL_INCLUDE
DEBUG_IMX6SX_UART
default "debug/ks8695.S" if DEBUG_KS8695_UART
default "debug/msm.S" if DEBUG_MSM_UART || DEBUG_QCOM_UARTDM
+ default "debug/netx.S" if DEBUG_NETX_UART
default "debug/omap2plus.S" if DEBUG_OMAP2PLUS_UART
default "debug/s3c24xx.S" if DEBUG_S3C24XX_UART
default "debug/sirf.S" if DEBUG_SIRFPRIMA2_UART1 || DEBUG_SIRFMARCO_UART1
@@ -1094,6 +1103,7 @@ config DEBUG_UART_8250
config DEBUG_UART_PHYS
hex "Physical base address of debug UART"
+ default 0x00100a00 if DEBUG_NETX_UART
default 0x01c20000 if DEBUG_DAVINCI_DMx_UART0
default 0x01c28000 if DEBUG_SUNXI_UART0
default 0x01c28400 if DEBUG_SUNXI_UART1
@@ -1162,10 +1172,12 @@ config DEBUG_UART_PHYS
depends on DEBUG_LL_UART_8250 || DEBUG_LL_UART_PL01X || \
DEBUG_LL_UART_EFM32 || \
DEBUG_UART_8250 || DEBUG_UART_PL01X || \
- DEBUG_MSM_UART || DEBUG_QCOM_UARTDM || DEBUG_S3C24XX_UART
+ DEBUG_MSM_UART || DEBUG_NETX_UART || DEBUG_QCOM_UARTDM || \
+ DEBUG_S3C24XX_UART
config DEBUG_UART_VIRT
hex "Virtual base address of debug UART"
+ default 0xe0000a00 if DEBUG_NETX_UART
default 0xe0010fe0 if ARCH_RPC
default 0xe1000000 if DEBUG_MSM_UART
default 0xf0000be0 if ARCH_EBSA110
@@ -1232,7 +1244,8 @@ config DEBUG_UART_VIRT
default DEBUG_UART_PHYS if !MMU
depends on DEBUG_LL_UART_8250 || DEBUG_LL_UART_PL01X || \
DEBUG_UART_8250 || DEBUG_UART_PL01X || \
- DEBUG_MSM_UART || DEBUG_QCOM_UARTDM || DEBUG_S3C24XX_UART
+ DEBUG_MSM_UART || DEBUG_NETX_UART || DEBUG_QCOM_UARTDM || \
+ DEBUG_S3C24XX_UART
config DEBUG_UART_8250_SHIFT
int "Register offset shift for the 8250 debug UART"
diff --git a/arch/arm/mach-netx/include/mach/debug-macro.S b/arch/arm/include/debug/netx.S
similarity index 62%
rename from arch/arm/mach-netx/include/mach/debug-macro.S
rename to arch/arm/include/debug/netx.S
index 247781e..cf7522a 100644
--- a/arch/arm/mach-netx/include/mach/debug-macro.S
+++ b/arch/arm/include/debug/netx.S
@@ -1,5 +1,4 @@
-/* arch/arm/mach-netx/include/mach/debug-macro.S
- *
+/*
* Debugging macro include header
*
* Copyright (C) 1994-1999 Russell King
@@ -11,26 +10,27 @@
*
*/
-#include "hardware.h"
+#define UART_DATA 0
+#define UART_FLAG 0x18
+#define UART_FLAG_BUSY (1 << 3)
.macro addruart, rp, rv, tmp
- mov \rp, #0x00000a00
- orr \rv, \rp, #io_p2v(0x00100000) @ virtual
- orr \rp, \rp, #0x00100000 @ physical
+ ldr \rp, =CONFIG_DEBUG_UART_PHYS
+ ldr \rp, =CONFIG_DEBUG_UART_VIRT
.endm
.macro senduart,rd,rx
- str \rd, [\rx, #0]
+ str \rd, [\rx, #UART_DATA]
.endm
.macro busyuart,rd,rx
-1002: ldr \rd, [\rx, #0x18]
- tst \rd, #(1 << 3)
+1002: ldr \rd, [\rx, #UART_FLAG]
+ tst \rd, #UART_FLAG_BUSY
bne 1002b
.endm
.macro waituart,rd,rx
-1001: ldr \rd, [\rx, #0x18]
- tst \rd, #(1 << 3)
+1001: ldr \rd, [\rx, #UART_FLAG]
+ tst \rd, #UART_FLAG_BUSY
bne 1001b
.endm
--
1.9.3
^ permalink raw reply related
* [RFC PATCH 09/10] arm64/efi: enable minimal UEFI Runtime Services for big endian
From: Mark Rutland @ 2014-07-23 9:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405955785-13477-10-git-send-email-ard.biesheuvel@linaro.org>
Hi Ard,
This is certainly a neat feature, and I definitely want to be able to
boot BE kernels via UEFI.
However, I'm wary of calling EFI in a physical (i.e. idmap with dcaches
off) context. I'm not sure anyone else does that, and I'm not sure
whether that's going to work (both because of the cache maintenance
requirements and the expectations of a given UEFI implementation w.r.t.
memory cacheability).
I'd hoped we'd be able to use a LE EL0 context to call the runtime
services in, but I'm not sure that's possible by the spec :(
As I understand it, we shouldn't need these runtime services to simply
boot a BE kernel.
On Mon, Jul 21, 2014 at 04:16:24PM +0100, Ard Biesheuvel wrote:
> This enables the UEFI Runtime Services needed to manipulate the
> non-volatile variable store when running under a BE kernel.
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> arch/arm64/include/asm/efi.h | 2 +
> arch/arm64/kernel/efi-be-call.S | 55 ++++++++++++++++++++
> arch/arm64/kernel/efi-be-runtime.c | 104 +++++++++++++++++++++++++++++++++++++
> arch/arm64/kernel/efi.c | 15 ++++++
> 4 files changed, 176 insertions(+)
> create mode 100644 arch/arm64/kernel/efi-be-call.S
> create mode 100644 arch/arm64/kernel/efi-be-runtime.c
>
> diff --git a/arch/arm64/include/asm/efi.h b/arch/arm64/include/asm/efi.h
> index a34fd3b12e2b..44e642b6ab61 100644
> --- a/arch/arm64/include/asm/efi.h
> +++ b/arch/arm64/include/asm/efi.h
> @@ -44,4 +44,6 @@ extern void efi_idmap_init(void);
>
> #define efi_call_early(f, ...) sys_table_arg->boottime->f(__VA_ARGS__)
>
> +extern void efi_be_runtime_setup(void);
> +
> #endif /* _ASM_EFI_H */
> diff --git a/arch/arm64/kernel/efi-be-call.S b/arch/arm64/kernel/efi-be-call.S
> new file mode 100644
> index 000000000000..24c92a4c352b
> --- /dev/null
> +++ b/arch/arm64/kernel/efi-be-call.S
> @@ -0,0 +1,55 @@
> +
> +#include <linux/linkage.h>
> +
> + .text
> + .align 3
> +ENTRY(efi_be_phys_call)
> + /*
> + * Entered at physical address with 1:1 mapping enabled.
> + */
> + stp x29, x30, [sp, #-96]!
> + mov x29, sp
> + str x27, [sp, #16]
> +
> + ldr x8, =efi_be_phys_call // virt address of this function
> + adr x9, efi_be_phys_call // phys address of this function
> + sub x9, x8, x9 // calculate virt to phys offset in x9
> +
> + /* preserve all inputs */
> + stp x0, x1, [sp, #32]
> + stp x2, x3, [sp, #48]
> + stp x4, x5, [sp, #64]
> + stp x6, x7, [sp, #80]
> +
> + /* get phys address of stack */
> + sub sp, sp, x9
> +
> + /* switch to LE, disable MMU and D-cache but leave I-cache enabled */
> + mrs x27, sctlr_el1
> + bic x8, x27, #1 << 2 // clear SCTLR.C
> + msr sctlr_el1, x8
> +
> + bl flush_cache_all
What is the cache flush for?
The only thing that flush_cache_all can do is empty the local
architected caches, and it can only do that when said caches are
disabled. Any other use is unsafe; we have no guarantee that the cache
is empty (or even clean), and we have no guarantee that prior writes
have made it to the PoC.
Even when the caches are disabled, flush_cache_all can only guarantee
that the local architected caches are empty. There is no guarantee that
the dirty data made it to the PoC.
> +
> + /* restore inputs but rotated by 1 register */
> + ldp x7, x0, [sp, #32]
> + ldp x1, x2, [sp, #48]
> + ldp x3, x4, [sp, #64]
> + ldp x5, x6, [sp, #80]
> +
> + bic x8, x27, #1 << 2 // clear SCTLR.C
> + bic x8, x8, #1 << 0 // clear SCTLR.M
> + bic x8, x8, #1 << 25 // clear SCTLR.EE
> + msr sctlr_el1, x8
> + isb
> +
> + blr x7
Is it safe to call EFI functions with the D-cache disabled?
Do the functions not care about the memory attributes for their own sue
(e.g. for exclusives)?
Do they not care about IO? If IO to/from storage for variables is
cache-coherent EFI and the device won't have a coherent view of memory.
> +
> + /* switch back to BE and reenable MMU and D-cache */
> + msr sctlr_el1, x27
> +
Missing ISB?
> + mov sp, x29
> + ldr x27, [sp, #16]
> + ldp x29, x30, [sp], #96
> + ret
> +ENDPROC(efi_be_phys_call)
> diff --git a/arch/arm64/kernel/efi-be-runtime.c b/arch/arm64/kernel/efi-be-runtime.c
> new file mode 100644
> index 000000000000..62e6c441b77b
> --- /dev/null
> +++ b/arch/arm64/kernel/efi-be-runtime.c
> @@ -0,0 +1,104 @@
> +
> +#include <linux/efi.h>
> +#include <linux/spinlock.h>
> +#include <asm/efi.h>
> +#include <asm/neon.h>
> +#include <asm/tlbflush.h>
> +
> +static efi_runtime_services_t *runtime;
> +static efi_status_t (*efi_be_call)(phys_addr_t func, ...);
> +
> +static DEFINE_SPINLOCK(efi_be_rt_lock);
> +
> +static unsigned long efi_be_call_pre(void)
> +{
> + unsigned long flags;
> +
> + kernel_neon_begin();
> + spin_lock_irqsave(&efi_be_rt_lock, flags);
At this point we might still have DA_F unmasked, and I don't think we
expect to be able to handle any of those when the CPU is in the wrong
endianness for the kernel.
> + cpu_switch_mm(idmap_pg_dir, &init_mm);
> + flush_tlb_all();
> + return flags;
> +}
> +
> +static void efi_be_call_post(unsigned long flags)
> +{
> + cpu_switch_mm(current, current->active_mm);
> + flush_tlb_all();
> + spin_unlock_irqrestore(&efi_be_rt_lock, flags);
> + kernel_neon_end();
> +}
> +
> +static efi_status_t efi_be_get_variable(efi_char16_t *name,
> + efi_guid_t *vendor,
> + u32 *attr,
> + unsigned long *data_size,
> + void *data)
> +{
> + unsigned long flags;
> + efi_status_t status;
> +
> + *data_size = cpu_to_le64(*data_size);
> + flags = efi_be_call_pre();
> + status = efi_be_call(le64_to_cpu(runtime->get_variable),
> + virt_to_phys(name), virt_to_phys(vendor),
> + virt_to_phys(attr), virt_to_phys(data_size),
> + virt_to_phys(data));
> + efi_be_call_post(flags);
> + *attr = le32_to_cpu(*attr);
> + *data_size = le64_to_cpu(*data_size);
> + return status;
No cache maintenance? EFI Could have written to a physical mapping which
could be shadowed by old cache entries. Similarly any buffers that we
pass to UEFI aren't guaranteed to have been hit the PoC, so UEFI might
read stale data.
I think that's true for all of the efi_be_* calls below.
> +}
> +
> +static efi_status_t efi_be_get_next_variable(unsigned long *name_size,
> + efi_char16_t *name,
> + efi_guid_t *vendor)
> +{
> + unsigned long flags;
> + efi_status_t status;
> +
> + *name_size = cpu_to_le64(*name_size);
> + flags = efi_be_call_pre();
> + status = efi_be_call(le64_to_cpu(runtime->get_next_variable),
> + virt_to_phys(name_size), virt_to_phys(name),
> + virt_to_phys(vendor));
> + efi_be_call_post(flags);
> + *name_size = le64_to_cpu(*name_size);
> + return status;
> +}
> +
> +static efi_status_t efi_be_set_variable(efi_char16_t *name,
> + efi_guid_t *vendor,
> + u32 attr,
> + unsigned long data_size,
> + void *data)
> +{
> + unsigned long flags;
> + efi_status_t status;
> +
> + flags = efi_be_call_pre();
> + status = efi_be_call(le64_to_cpu(runtime->set_variable),
> + virt_to_phys(name), virt_to_phys(vendor),
> + cpu_to_le32(attr), cpu_to_le64(data_size),
> + virt_to_phys(data));
> + efi_be_call_post(flags);
> + return status;
> +}
> +
> +void efi_be_runtime_setup(void)
> +{
> + extern u8 efi_be_phys_call[];
> +
> + runtime = ioremap_cache(le64_to_cpu(efi.systab->runtime),
> + sizeof(efi_runtime_services_t));
> + if (!runtime) {
> + pr_err("Failed to set up BE wrappers for UEFI Runtime Services!\n");
> + return;
> + }
Might it be worth propagating the error code?
> +
> + efi_be_call = (void *)virt_to_phys(efi_be_phys_call);
> +
> + efi.get_variable = efi_be_get_variable;
> + efi.get_next_variable = efi_be_get_next_variable;
> + efi.set_variable = efi_be_set_variable;
> +}
> diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
> index 96df58824189..21e98810c5dd 100644
> --- a/arch/arm64/kernel/efi.c
> +++ b/arch/arm64/kernel/efi.c
> @@ -406,6 +406,21 @@ static int __init arm64_enter_virtual_mode(void)
>
> efi.memmap = &memmap;
>
> + if (IS_ENABLED(CONFIG_CPU_BIG_ENDIAN)) {
> + efi.systab = ioremap_cache(efi_system_table,
> + sizeof(efi_system_table_t));
> + if (!efi.systab) {
> + pr_err("Failed to remap EFI system table!\n");
> + return -1;
> + }
> + free_boot_services();
> + efi_be_runtime_setup();
We can fail here, but we'll still set the bits below, which doesn't seem
right.
> +
> + set_bit(EFI_SYSTEM_TABLES, &efi.flags);
> + set_bit(EFI_RUNTIME_SERVICES, &efi.flags);
> + return 0;
> + }
> +
> /* Map the runtime regions */
> virtmap = kmalloc(mapsize, GFP_KERNEL);
> if (!virtmap) {
> --
> 1.8.3.2
Cheers,
Mark.
^ permalink raw reply
* [PATCHv2 06/10] ARM: DRA7: hwmod_data: Add mailbox hwmod data
From: Tony Lindgren @ 2014-07-23 9:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140716070708.GC2605@atomide.com>
* Tony Lindgren <tony@atomide.com> [140716 00:10]:
> * Suman Anna <s-anna@ti.com> [140715 09:59]:
> > Hi Tony,
> >
> > On 07/15/2014 08:30 AM, Tony Lindgren wrote:
> > > * Suman Anna <s-anna@ti.com> [140711 14:47]:
> > >> Add the hwmod data for the 13 instances of the system mailbox
> > >> IP in DRA7 SoC. The patch is needed for performing a soft-reset
> > >> while configuring the respective mailbox instance, otherwise is
> > >> a non-essential change for functionality. The modules are smart
> > >> idled on reset, and the IP module mode is hardware controlled.
> > >>
> > >> Cc: Rajendra Nayak <rnayak@ti.com>
> > >> Cc: Paul Walmsley <paul@pwsan.com>
> > >> Signed-off-by: Suman Anna <s-anna@ti.com>
> > >> ---
> > >> arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 305 ++++++++++++++++++++++++++++++
> > >> 1 file changed, 305 insertions(+)
> > >>
> > >> diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> > >> index 20b4398..e35f5b1 100644
> > >> --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> > >> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> > >> @@ -939,6 +939,194 @@ static struct omap_hwmod dra7xx_i2c5_hwmod = {
> > >> };
> > >>
> > >> /*
> > >> + * 'mailbox' class
> > >> + *
> > >> + */
> > >> +
> > >> +static struct omap_hwmod_class_sysconfig dra7xx_mailbox_sysc = {
> > >> + .rev_offs = 0x0000,
> > >> + .sysc_offs = 0x0010,
> > >> + .sysc_flags = (SYSC_HAS_RESET_STATUS | SYSC_HAS_SIDLEMODE |
> > >> + SYSC_HAS_SOFTRESET),
> > >> + .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
> > >> + .sysc_fields = &omap_hwmod_sysc_type2,
> > >> +};
> > >> +
> > >> +static struct omap_hwmod_class dra7xx_mailbox_hwmod_class = {
> > >> + .name = "mailbox",
> > >> + .sysc = &dra7xx_mailbox_sysc,
> > >> +};
> > >
> > > Hmm I'm seeing just the following MAILBOX_SYSCONFIG in at least
> > > am57xx TRM:
> > >
> > > 31:4 RESERVED
> > > 3:2 SIDLEMODE 0 = force-idle 1 = no-idle, 2 = smart-idle, 3 = reserved
> > > 1 RESERVED
> > > 0 SOFTRESET
> > >
> > > So it seems that SYSC_HAS_RESET_STATUS above is wrong? Can you guys
> > > please check.
> >
> > The same SOFTRESET bit is used for both triggering the softreset and
> > reading the reset done status. Once you write a 1 to trigger a reset,
> > the bit will be cleared once the reset is done. This is no different
> > from OMAP4. The logic in _wait_softreset_complete in omap_hwmod.c was
> > already designed to work with this properly.
>
> Oh OK, I guess I got it confused with SYSS_HAS_RESET_STATUS. Paul,
> want to ack this one if no other issues? I can then set this series
> into a branch against -rc1 that we can all merge in as needed as
> it seems that the driver changes may need this branch as a base too.
I have applied these into omap-for-v3.17/mailbox and merged also
into omap-for-v3.17/soc.
Regards,
Tony
^ permalink raw reply
* [PATCH V2 1/2] power: twl4030_charger: detect battery presence prior to enabling charger
From: Tony Lindgren @ 2014-07-23 9:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1401313610-14252-2-git-send-email-nm@ti.com>
* Nishanth Menon <nm@ti.com> [140528 14:48]:
> TWL4030's Battery Charger seems to be designed for non-hotpluggable
> batteries.
>
> If battery is not present in the system, BATSTS is always set with the
> expectation that software will take actions to move to a required safe
> state (could be power down or disable various charger paths).
>
> It does not seem possible even by manipulating the edge detection
> of the event (using BCIEDR2 register) to have a consistent hotplug
> handling. This seems to be the result of BATSTS interrupt generated
> when the thermistor of the battery pack is disconnected from the
> dedicated ADIN1 pin. Clearing the status just results in the status
> being regenerated by the monitoring ADC(MADC) and disabling the
> edges of event just makes hotplug no longer function. The only
> other option is to disable the detection of the MADC by disabling
> BCIMFEN4::BATSTSMCHGEN (battery presence detector) - but then, we can
> never again detect battery reconnection.
>
> So, detect battery presence based on precharge(which is hardware
> automatic state) or default main charger configuration at the time of
> probe and enable charger logic only if battery was present.
>
> Reported-by: Russell King <linux@arm.linux.org.uk>
> Tested-by: Tony Lindgren <tony@atomide.com>
> Signed-off-by: Nishanth Menon <nm@ti.com>
Dmitry, can we please get this first patch merged? This is needed
on some omap3 platforms for DT based booting when no battery is
present.
Only the second patch in this series is still being discussed AFAIK.
Regards,
Tony
> ---
> V2: just a rebase, picked up tony's tested-by, minor formatting fix
> V1: https://patchwork.kernel.org/patch/4124751/
> drivers/power/twl4030_charger.c | 44 ++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 43 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/power/twl4030_charger.c b/drivers/power/twl4030_charger.c
> index f141088..2598c58 100644
> --- a/drivers/power/twl4030_charger.c
> +++ b/drivers/power/twl4030_charger.c
> @@ -28,10 +28,13 @@
> #define TWL4030_BCIICHG 0x08
> #define TWL4030_BCIVAC 0x0a
> #define TWL4030_BCIVBUS 0x0c
> +#define TWL4030_BCIMFSTS3 0x0F
> #define TWL4030_BCIMFSTS4 0x10
> #define TWL4030_BCICTL1 0x23
> #define TWL4030_BB_CFG 0x12
>
> +#define TWL4030_BCIMFSTS1 0x01
> +
> #define TWL4030_BCIAUTOWEN BIT(5)
> #define TWL4030_CONFIG_DONE BIT(4)
> #define TWL4030_BCIAUTOUSB BIT(1)
> @@ -52,6 +55,9 @@
> #define TWL4030_BBISEL_500uA 0x02
> #define TWL4030_BBISEL_1000uA 0x03
>
> +#define TWL4030_BATSTSPCHG BIT(2)
> +#define TWL4030_BATSTSMCHG BIT(6)
> +
> /* BCI interrupts */
> #define TWL4030_WOVF BIT(0) /* Watchdog overflow */
> #define TWL4030_TMOVF BIT(1) /* Timer overflow */
> @@ -145,6 +151,35 @@ static int twl4030bci_read_adc_val(u8 reg)
> }
>
> /*
> + * Check if Battery Pack was present
> + */
> +static int twl4030_is_battery_present(struct twl4030_bci *bci)
> +{
> + int ret;
> + u8 val = 0;
> +
> + /* Battery presence in Main charge? */
> + ret = twl_i2c_read_u8(TWL_MODULE_MAIN_CHARGE, &val, TWL4030_BCIMFSTS3);
> + if (ret)
> + return ret;
> + if (val & TWL4030_BATSTSMCHG)
> + return 0;
> +
> + /*
> + * OK, It could be that bootloader did not enable main charger,
> + * pre-charge is h/w auto. So, Battery presence in Pre-charge?
> + */
> + ret = twl_i2c_read_u8(TWL4030_MODULE_PRECHARGE, &val,
> + TWL4030_BCIMFSTS1);
> + if (ret)
> + return ret;
> + if (val & TWL4030_BATSTSPCHG)
> + return 0;
> +
> + return -ENODEV;
> +}
> +
> +/*
> * Check if VBUS power is present
> */
> static int twl4030_bci_have_vbus(struct twl4030_bci *bci)
> @@ -541,8 +576,14 @@ static int __init twl4030_bci_probe(struct platform_device *pdev)
> bci->irq_chg = platform_get_irq(pdev, 0);
> bci->irq_bci = platform_get_irq(pdev, 1);
>
> - platform_set_drvdata(pdev, bci);
> + /* Only proceed further *IF* battery is physically present */
> + ret = twl4030_is_battery_present(bci);
> + if (ret) {
> + dev_crit(&pdev->dev, "Battery was not detected:%d\n", ret);
> + goto fail_no_battery;
> + }
>
> + platform_set_drvdata(pdev, bci);
> bci->ac.name = "twl4030_ac";
> bci->ac.type = POWER_SUPPLY_TYPE_MAINS;
> bci->ac.properties = twl4030_charger_props;
> @@ -633,6 +674,7 @@ fail_chg_irq:
> fail_register_usb:
> power_supply_unregister(&bci->ac);
> fail_register_ac:
> +fail_no_battery:
> kfree(bci);
>
> return ret;
> --
> 1.7.9.5
>
^ permalink raw reply
* [PATCH] ARM: OMAP: generic: add call to of_clk_init()
From: Daniel Mack @ 2014-07-23 9:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140723085444.GC22006@atomide.com>
Hi Tony,
On 07/23/2014 10:54 AM, Tony Lindgren wrote:
> * Daniel Mack <zonque@gmail.com> [140712 03:57]:
>> This is needed to instanciate fixed clocks in the DT.
>
> Makes sense to me. Does this fix some regression or hang
> that's needed for the -rc series?
No, it's a feature addition. No need to hurry :)
> Also would like to get an ack from Tero on this as the other
> clocks are initialized elsewhere.
Ok, thanks. I'm open to alternative ways of course.
Thanks,
Daniel
^ permalink raw reply
* [RFC V2] devicetree: Dialog Semiconductor consolidate existing vendor prefixes to standardise on 'dlg'
From: Opensource [Steve Twiss] @ 2014-07-23 9:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140722070927.GC28529@lee--X1>
On 22 July 2014 08:09, Lee Jones wrote:
>-----Original Message-----
>From: Lee Jones [mailto:lee.jones at linaro.org]
>> From: Opensource [Steve Twiss] <stwiss.opensource@diasemi.com>
>>
>> This patch series updates the device tree vendor prefix for
>> Dialog Semiconductor.
>>
>> Various methods are currently used throughout the kernel: 'diasemi',
>> 'dialog' and 'dlg'. Others have also been suggested.
>>
>> This patch set aims to consolidate the usage of the vendor prefix to
>> use a common standard. The prefix 'dlg' is used.
>>
>> Here is my working for justifying this change:
>>
>> ./arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi
>> Has the following entry:
>> compatible = "dialog,da9063";
>> However the DA9063 driver does not support device tree yet so
>> it would be safe to rename this.
>>
>> ./arch/arm/boot/dts/imx53-smd.dts
>> Has the following entry:
>> compatible = "dialog,da9053", "dialog,da9052";
>> However, the existing driver files for DA9053 define a different
>> compatible string with the "dlg" prefix. See the entries below.
>> None of these would have allowed the "dialog" prefix.
>> { .compatible = "dlg,da9052", .data = &da9052_i2c_id[0] },
>> { .compatible = "dlg,da9053-aa", .data = &da9052_i2c_id[1] },
>> { .compatible = "dlg,da9053-ba", .data = &da9052_i2c_id[2] },
>> { .compatible = "dlg,da9053-bb", .data = &da9052_i2c_id[3] },
>> { .compatible = "dlg,da9053-bc", .data = &da9052_i2c_id[4] },
>> In this particular case the change for DA9053 did not match up
>> with the expected compatibility strings and therefore I have
>> retained the more general "dlg,da9053" because I do not know
>> which silicon variant (-aa, -ba, -bb, or -bc) is the correct
>> one to use.
>>
>> ./devicetree/bindings/i2c/trivial-devices.txt
>> Has the following entry:
>> dialog,da9053 DA9053: flexible system level PMIC with multicore support
>> Instead of depreciating this "dialog" line I am just replacing it
>> with a "dlg" because the existing driver DA9053 does not support
>> the dialog keyword.
>>
>> ./drivers/mfd/da9055-core.c
>> Has the following entries for the mfd cells
>> .of_compatible = "dialog,da9055-gpio", etc...
>> In this case, the driver does not actually pass in any platform data
>> to any of the mfd cells and so they are not actually used
>> yet in the driver. Nobody else references this information.
>>
>> ./devicetree/bindings/regulator/da9210.txt
>> Has the following two entries in the binding file:
>> - compatible: must be "diasemi,da9210"
>> compatible = "diasemi,da9210";
>> However the DA9210 driver does not support device tree.
>>
>> ./arch/arm/boot/dts/r8a7790-lager.dts
>> ./arch/arm/boot/dts/r8a7791-koelsch.dts
>> These two files have the following entries:
>> compatible = "diasemi,da9210";
>> These both reference the "diasemi,da9210" but the device
>> driver does not support device tree
>>
>> The remaining files in the kernel I have found correctly references
>> the driver files compatibility information and so did not need to
>> be changed.
>>
>> ./devicetree/bindings/mfd/da9052-i2c.txt
>> - compatible : Should be "dlg,da9052", "dlg,da9053-aa",
>> "dlg,da9053-ab", or "dlg,da9053-bb"
>>
>> ./devicetree/bindings/mfd/da9055.txt
>> compatible = "dlg,da9055-pmic";
>>
>> ./arch/arm/boot/dts/imx53-voipac-dmm-668.dtsi
>> compatible = "dlg,da9053-aa", "dlg,da9052";
>>
>> ./arch/arm/boot/dts/imx53-qsb.dts
>> compatible = "dlg,da9053-aa", "dlg,da9052";
>>
>> ./devicetree/bindings/sound/da9055.txt
>> - compatible: "dlg,da9055-codec"
>> compatible = "dlg,da9055-codec";
>>
>>
>> Signed-off-by: Opensource [Steve Twiss] <stwiss.opensource@diasemi.com>
>> ---
>> Checks performed with linux-next/next-20140715/scripts/checkpatch.pl
>> trivial-devices.txt total: 0 errors, 0 warnings, 89 lines checked
>> da9210.txt total: 0 errors, 0 warnings, 21 lines checked
>> vendor-prefixes.txt total: 0 errors, 0 warnings, 149 lines checked
>> imx53-smd.dts total: 0 errors, 2 warnings, 279 lines checked
>> imx6qdl-phytec-pfla02.dtsi total: 0 errors, 2 warnings, 357 lines checked
>> r8a7790-lager.dts total: 0 errors, 3 warnings, 403 lines checked
>> r8a7791-koelsch.dts total: 0 errors, 4 warnings, 461 lines checked
>> da9055-core.c total: 0 errors, 0 warnings, 428 lines checked
>>
>> This e-mail is in response to the previous threads here:
>> https://lkml.org/lkml/2014/6/11/262
>> http://comments.gmane.org/gmane.linux.ports.arm.kernel/341358
>>
>> Changes since RFC V1
>> - addition of changes to DTS files referencing "diasemi,da9210"
>> arch/arm/boot/dts/r8a7790-lager.dts
>> arch/arm/boot/dts/r8a7791-koelsch.dts
>>
>> This RFC V2 does not answer the response to RFC V1 from Mark Brown:
>> http://www.spinics.net/lists/arm-kernel/msg347615.html
>>
>> This patch applies against linux-next and next-20140715
>>
>> Regards,
>> Steve Twiss, Dialog Semiconductor Ltd.
>>
>>
>>
>> .../devicetree/bindings/i2c/trivial-devices.txt | 2 +-
>> .../devicetree/bindings/regulator/da9210.txt | 4 ++--
>> .../devicetree/bindings/vendor-prefixes.txt | 1 +
>> arch/arm/boot/dts/imx53-smd.dts | 2 +-
>> arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi | 2 +-
>> arch/arm/boot/dts/r8a7790-lager.dts | 2 +-
>> arch/arm/boot/dts/r8a7791-koelsch.dts | 2 +-
>> drivers/mfd/da9055-core.c | 26 ++++++++++----------
>
>For the MFD changes:
>
> Acked-by: Lee Jones <lee.jones@linaro.org>
>
>Which tree is this patch going into? Do you want me to take it and
>supply an IB for the other Maintainers to pull from?
Hi Lee,
I'm not sure if this question was for me directly, but I do not have any
preference who takes this change or how it gets pulled. Thank you.
There was a request from Rob Herring
http://www.spinics.net/lists/arm-kernel/msg349289.html
to reformat the original e-mail content and also to drop the annoying
"Opensource" and square brackets from my Signed-off-by:
signature. So, the decision is to take the patch into an immutable branch
and you need me to re-format the e-mail content -- I will resend
with those changes.
Regards,
Steve
>
>> 8 files changed, 21 insertions(+), 20 deletions(-)
^ permalink raw reply
* [PATCH v5 1/3] arm64: ptrace: reload a syscall number after ptrace operations
From: AKASHI Takahiro @ 2014-07-23 9:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140723082505.GB27260@arm.com>
On 07/23/2014 05:25 PM, Will Deacon wrote:
> On Wed, Jul 23, 2014 at 08:03:47AM +0100, AKASHI Takahiro wrote:
>> On 07/23/2014 05:15 AM, Kees Cook wrote:
>>> On Tue, Jul 22, 2014 at 2:14 AM, AKASHI Takahiro
>>> <takahiro.akashi@linaro.org> wrote:
>>>> asmlinkage int syscall_trace_enter(struct pt_regs *regs)
>>>> {
>>>> + unsigned long saved_x0, saved_x8;
>>>> +
>>>> + saved_x0 = regs->regs[0];
>>>> + saved_x8 = regs->regs[8];
>>>> +
>>>> if (test_thread_flag(TIF_SYSCALL_TRACE))
>>>> tracehook_report_syscall(regs, PTRACE_SYSCALL_ENTER);
>>>>
>>>> + regs->syscallno = regs->regs[8];
>>>> + if ((long)regs->syscallno == ~0UL) { /* skip this syscall */
>>>> + regs->regs[8] = saved_x8;
>>>> + if (regs->regs[0] == saved_x0) /* not changed by user */
>>>> + regs->regs[0] = -ENOSYS;
>>>
>>> I'm not sure this is right compared to other architectures. Generally
>>> when a tracer performs a syscall skip, it's up to them to also adjust
>>> the return value. They may want to be faking a syscall, and what if
>>> the value they want to return happens to be what x0 was going into the
>>> tracer? It would have no way to avoid this -ENOSYS case. I think
>>> things are fine without this test.
>>
>> Yeah, I know this issue, but was not sure that setting a return value
>> is mandatory. (x86 seems to return -ENOSYS by default if not explicitly
>> specified.)
>> Is "fake a system call" a more appropriate word than "skip"?
>>
>> I will defer to Will.
>
> I agree with Kees -- iirc, I only suggested restoring x8.
OK.
-Takahiro AKASHI
> Will
>
^ permalink raw reply
* [PATCH v2 0/7] arm: dts: oma3-gta04: Various updates
From: Tony Lindgren @ 2014-07-23 9:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1406057420-22269-1-git-send-email-marek@goldelico.com>
* Marek Belisko <marek@goldelico.com> [140722 12:32]:
> Following patchset add various improvements to gta04 devicetree.
>
> Changes from v1:
> - added description to all patches
>
> Marek Belisko (7):
> arm: dts: omap3-gta04: Add nand support
> arm: dts: omap3-gta04: Fix magnetometer model
> arm: dts: omap3-gta04: Add wifi reset node
> arm: dts: omap3-gta04: Move spi gpio pins to pmx_core2
> arm: dts: omap3-gta04: Add USB host support
> arm: dts: omap3-gta04: Add display alias
> arm: dts: omap3-gta04: Add twl4030 regulators parameters
>
> arch/arm/boot/dts/omap3-gta04.dts | 150 ++++++++++++++++++++++++++++++++++++--
> 1 file changed, 145 insertions(+), 5 deletions(-)
Applying into omap-for-v3.17/dt thanks.
Tony
^ permalink raw reply
* [PATCH v3 0/2] usb: fix controller-PHY binding for OMAP3 platform
From: Kishon Vijay Abraham I @ 2014-07-23 8:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140721151557.GH6852@saruman.home>
Hi Felipe,
On Monday 21 July 2014 08:45 PM, Felipe Balbi wrote:
> Hi,
>
> On Mon, Jul 21, 2014 at 05:04:57PM +0200, Laurent Pinchart wrote:
>> Hi Felipe,
>>
>> What happened to these two patches ?
>
> looks like I lost them.
>
>> On Monday 16 December 2013 17:48:29 Felipe Balbi wrote:
>>> On Mon, Dec 16, 2013 at 02:38:27PM -0800, Tony Lindgren wrote:
>>>> * Felipe Balbi <balbi@ti.com> [131216 13:31]:
>>>>> On Mon, Dec 16, 2013 at 09:23:43PM +0530, Kishon Vijay Abraham I wrote:
>>>>>> After the platform devices are created using PLATFORM_DEVID_AUTO, the
>>>>>> device names given in usb_bind_phy (in board file) does not match with
>>>>>> the actual device name causing the USB PHY library not to return the
>>>>>> PHY reference when the MUSB controller request for the PHY in the
>>>>>> non-dt boot case.
>>>>>> So removed creating platform devices using PLATFORM_DEVID_AUTO in
>>>>>> omap2430.c.
>>>>>>
>>>>>> Did enumeration testing in omap3 beagle.
>>>>>>
>>>>>> Changes from v2:
>>>>>> * Fixed the commit log
>>>>>>
>>>>>> Changes from v1:
>>>>>> * refreshed to the latested mainline kernel
>>>>>> * added musb_put_id from omap2430 remove.
>>>>>
>>>>> Tony, how do you want to handle this ? You want me to provide you a
>>>>> branch which we both merge ?
>>>>
>>>> Yes that would be great thanks. For the mach-omap2 touching parts:
>>>>
>>>> Acked-by: Tony Lindgren <tony@atomide.com>
>>>
>>> Here it is, let me know if you prefer a signed tag:
>>>
>>> The following changes since commit 6ce4eac1f600b34f2f7f58f9cd8f0503d79e42ae:
>>>
>>> Linux 3.13-rc1 (2013-11-22 11:30:55 -0800)
>>>
>>> are available in the git repository at:
>>>
>>> git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git
>>> usb-phy-binding-omap3
>>>
>>> for you to fetch changes up to 23ada3130cf4e56acb86fdff4c26113188d52d18:
>>>
>>> arm: omap: remove *.auto* from device names given in usb_bind_phy
>>> (2013-12-16 17:44:43 -0600)
>>>
>>> ----------------------------------------------------------------
>>> Kishon Vijay Abraham I (2):
>>> usb: musb: omap: remove using PLATFORM_DEVID_AUTO in omap2430.c
>>> arm: omap: remove *.auto* from device names given in usb_bind_phy
>
> Kishon, are these still valid ?
Looks like board-2430sdp.c got removed. Apart from that the reset of the patch
series is still applicable for non-dt boot.
Thanks
Kishon
^ permalink raw reply
* [PATCH] ARM: OMAP: generic: add call to of_clk_init()
From: Tony Lindgren @ 2014-07-23 8:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405162508-9835-1-git-send-email-zonque@gmail.com>
* Daniel Mack <zonque@gmail.com> [140712 03:57]:
> This is needed to instanciate fixed clocks in the DT.
Makes sense to me. Does this fix some regression or hang
that's needed for the -rc series?
Also would like to get an ack from Tero on this as the other
clocks are initialized elsewhere.
Regards,
Tony
> Signed-off-by: Daniel Mack <zonque@gmail.com>
> ---
> arch/arm/mach-omap2/board-generic.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
> index 5606fa2..39f154a 100644
> --- a/arch/arm/mach-omap2/board-generic.c
> +++ b/arch/arm/mach-omap2/board-generic.c
> @@ -15,6 +15,7 @@
> #include <linux/of_irq.h>
> #include <linux/of_platform.h>
> #include <linux/irqdomain.h>
> +#include <linux/clk-provider.h>
>
> #include <asm/mach/arch.h>
>
> @@ -33,6 +34,11 @@ static struct of_device_id omap_dt_match_table[] __initdata = {
> { }
> };
>
> +static struct of_device_id clk_match[] __initdata = {
> + { .compatible = "fixed-clock", .data = of_fixed_clk_setup, },
> + { }
> +};
> +
> static void __init omap_generic_init(void)
> {
> omapdss_early_init_of();
> @@ -40,6 +46,8 @@ static void __init omap_generic_init(void)
> pdata_quirks_init(omap_dt_match_table);
>
> omapdss_init_of();
> +
> + of_clk_init(clk_match);
> }
>
> #ifdef CONFIG_SOC_OMAP2420
> --
> 1.9.3
>
^ permalink raw reply
* OMAP2+: gpmc: fix gpmc_hwecc_bch_capable()
From: Tony Lindgren @ 2014-07-23 8:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20980858CB6D3A4BAE95CA194937D5E73EB02569@DBDE04.ent.ti.com>
* Gupta, Pekon <pekon@ti.com> [140713 22:43]:
> >From: Christoph Fritz [mailto:chf.fritz at googlemail.com]
> >
> >This patch adds bch8 ecc software fallback which is mostly used by
> >omap3s because they lack hardware elm support.
> >
> >Fixes: 0611c41934ab35ce84dea34ab291897ad3cbc7be (ARM: OMAP2+: gpmc:
> >update gpmc_hwecc_bch_capable() for new platforms and ECC schemes)
> >Cc: <stable@vger.kernel.org> # 3.15.x+
> >Signed-off-by: Christoph Fritz <chf.fritz@googlemail.com>
> >---
> > arch/arm/mach-omap2/gpmc-nand.c | 18 ++++++++++--------
> > 1 file changed, 10 insertions(+), 8 deletions(-)
> >
> >diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
> >index 17cd393..93914d2 100644
> >--- a/arch/arm/mach-omap2/gpmc-nand.c
> >+++ b/arch/arm/mach-omap2/gpmc-nand.c
> >@@ -50,6 +50,16 @@ static bool gpmc_hwecc_bch_capable(enum omap_ecc ecc_opt)
> > soc_is_omap54xx() || soc_is_dra7xx())
> > return 1;
> >
> >+ if (ecc_opt == OMAP_ECC_BCH4_CODE_HW_DETECTION_SW ||
> >+ ecc_opt == OMAP_ECC_BCH8_CODE_HW_DETECTION_SW) {
> >+ if (cpu_is_omap24xx())
> >+ return 0;
> >+ else if (cpu_is_omap3630() && (GET_OMAP_REVISION() == 0))
> >+ return 0;
> >+ else
> >+ return 1;
> >+ }
> >+
> > /* OMAP3xxx do not have ELM engine, so cannot support ECC schemes
> > * which require H/W based ECC error detection */
> > if ((cpu_is_omap34xx() || cpu_is_omap3630()) &&
> >@@ -57,14 +67,6 @@ static bool gpmc_hwecc_bch_capable(enum omap_ecc ecc_opt)
> > (ecc_opt == OMAP_ECC_BCH8_CODE_HW)))
> > return 0;
> >
> >- /*
> >- * For now, assume 4-bit mode is only supported on OMAP3630 ES1.x, x>=1
> >- * and AM33xx derivates. Other chips may be added if confirmed to work.
> >- */
> >- if ((ecc_opt == OMAP_ECC_BCH4_CODE_HW_DETECTION_SW) &&
> >- (!cpu_is_omap3630() || (GET_OMAP_REVISION() == 0)))
> >- return 0;
> >-
> > /* legacy platforms support only HAM1 (1-bit Hamming) ECC scheme */
> > if (ecc_opt == OMAP_ECC_HAM1_CODE_HW)
> > return 1;
> >--
> >1.7.10.4
> >
> Thanks much for this fix.
> Reviewed-by: Pekon Gupta <pekon@ti.com>
Applying into omap-for-v3.16/fixes thanks.
Tony
^ permalink raw reply
* [PATCH v2] cpufreq: tests: Providing cpufreq regression test
From: Viresh Kumar @ 2014-07-23 8:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140723093824.5e51918f@amdc2363>
On 23 July 2014 13:08, Lukasz Majewski <l.majewski@samsung.com> wrote:
> Do you want to say that we have enough tests and we don't need more ?
No. We don't have any tests at all :)
> I always thought that we shall have as much regression tests as
> possible.
Yeah, tests are welcomed but the question is where should they get added.
Don't know if its common to add tests directly to kernel.
And also if the test is really good, not discouraging your work.
>> On 21 July 2014 12:32, Lukasz Majewski <l.majewski@samsung.com> wrote:
>> > This commit adds first regression test "cpufreq_freq_test.sh" for
>> > the cpufreq subsystem.
>>
>> That's not enough, Tell us why we should continue reading this mail..
>
> Hmm... If "regression" and "test" don't catch the attention of a
> diligent maintainer, then I cannot do much more to encourage him to
> read the whole e-mail :-)
What I meant to say was, your subject and body must be good enough
to answer most of the things. You don't have to tell much about the
implementation but other things should be pretty clear from logs.
Your current logs are quite short for something that's not a normal practice.
> I can imagine that maintainers are very busy, therefore I've prepared
> README file with detailed description of the script operation.
Yeah, a README is welcomed and would be useful for users as well..
>> I couldn't make out the purpose of this test and why we need it. How
>> do we ensure that "cpufreq attributes exported by sysfs are exposing
>> correct values"?
>
> First of all the cpufreq attributes are part of the subsystem API.
> There are systems which actually depend on them, so we would be better
> off to test if they work as intended.
>
> Secondly, the test takes those values and then with use of other
> attribute enforce the value, which is then read via cat'ing
> cpufreq_cur_freq. If any of the attributes is wrong then we will spot
> the error immediately.
Shouldn't you use userspace governor then instead of performance?
And then we don't need the gzip stuff at all. We can just set it to the
right freq and get current freq to see if it matches?
And now that we are starting to get tests added into the kernel (will still
wait to see what Rafael has to advice), we better think of the way these
are going to get added. Probably a single script with parameters like
what to test?
>> And actually what do we mean by this statement even? What kind of
>> errors can be there in exposing these values.
>
> Errors with cpufreq and CCF cooperation - especially when some parts of
> cpufreq code uses direct write to MUX, DIV or PLL SoC registers.
>
> Also, one can check if permutations of changing all available
> frequencies are working properly.
Yeah, that would be fine. Probably need to think more about scripts name.
^ permalink raw reply
* [PATCH] pinctrl: dra: dt-bindings: Fix pull enable/disable
From: Tony Lindgren @ 2014-07-23 8:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53CEAE0F.9080901@ti.com>
* Nishanth Menon <nm@ti.com> [140722 11:34]:
> On 07/22/2014 11:47 AM, Felipe Balbi wrote:
> > On Tue, Jul 22, 2014 at 10:39:54AM -0500, Nishanth Menon wrote:
> >> The DRA74/72 control module pins have a weak pull up and pull down.
> >> This is configured by bit offset 17. if BIT(17) is 1, a pull up is
> >> selected, else a pull down is selected.
> >>
> >> However, this pull resisstor is applied based on BIT(16) -
> >> PULLUDENABLE - if BIT(18) is *0*, then pull as defined in BIT(17) is
> >> applied, else no weak pulls are applied. We defined this in reverse.
> >>
> >> Reference: Table 18-5 (Description of the pad configuration register
> >> bits) in Technical Reference Manual Revision (DRA74x revision Q:
> >> SPRUHI2Q Revised June 2014 and DRA72x revision F: SPRUHP2F - Revised
> >> June 2014)
> >>
> >> Fixes: 6e58b8f1daaf1a ("ARM: dts: DRA7: Add the dts files for dra7 SoC and dra7-evm board")
> >> Signed-off-by: Nishanth Menon <nm@ti.com>
> >> ---
> >
> > Tested on an upcoming board.
> >
> > Tested-by: Felipe Balbi <balbi@ti.com>
> > Acked-by: Felipe Balbi <balbi@ti.com>
> >
> >
> Felipe,
> Thanks.
>
> Tony,
>
> If you could consider this for the rc cycle it might be great(as well
> as for stable). The pull direction error can cause all kinds of
> Pull-down Vs Pull-Up contention with severe risk for certain IP
> reliability.
Yes this is a good one for the -rc cycle, applying into
omap-for-v3.16/fixes.
Regards,
Tony
^ permalink raw reply
* [PATCH 3/3] pinctrl: Introduce pinctrl driver for Qualcomm pm8xxx
From: Linus Walleij @ 2014-07-23 8:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJAp7Ojgf6iuSKtRnvyTCOxj5AwDA6W4eOeCpsfRqGAxcMPM1w@mail.gmail.com>
On Tue, Jul 15, 2014 at 12:48 AM, Bjorn Andersson <bjorn@kryo.se> wrote:
> On Wed, Jul 9, 2014 at 2:32 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
>> On Tue, Jul 8, 2014 at 3:26 AM, Bjorn Andersson
> [...]
>> "direction" also seems a bit bool ... even "output_value".
>>
>
> "direction" is 2 bits that can be both be set, unfortunately it's not entirely
> clear to me what's expected when setting both; so I've copied the logic as good
> as possible from the codeaurora driver.
Oh, can you do this?
u8 foo:2;
?
Yours,
Linus Walleij
^ permalink raw reply
* [GIT PULL] ARM: OMAP2+: first set of hwmod data patches for v3.17
From: Tony Lindgren @ 2014-07-23 8:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.02.1407222120460.25593@utopia.booyaka.com>
* Paul Walmsley <paul@pwsan.com> [140722 14:24]:
> Hi Tony
>
> The following changes since commit a497c3ba1d97fc69c1e78e7b96435ba8c2cb42ee:
>
> Linux 3.16-rc2 (2014-06-21 19:02:54 -1000)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/for-v3.17/omap-hwmod-a
>
> for you to fetch changes up to c913c8a15a02e91c1f0302d68bebf66838a9689d:
>
> ARM: DRA7: hwmod: Add data for RTC (2014-07-22 14:35:06 -0600)
>
> ----------------------------------------------------------------
> OMAP hwmod data additions for v3.17. Most of these are DRA7xx-related,
> although one patch adds DSS hwmods for AM43xx.
>
> Basic build, boot, and PM test results are available here:
>
> http://www.pwsan.com/omap/testlogs/hwmod-a-v3.17/20140722143514/
Thanks pulling into omap-for-v3.17/soc.
Tony
^ permalink raw reply
* [PATCH v2 14/16] cpufreq: Add cpufreq driver for Tegra124
From: Viresh Kumar @ 2014-07-23 8:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140723072442.GC15759@ulmo.nvidia.com>
On 23 July 2014 12:54, Thierry Reding <thierry.reding@gmail.com> wrote:
> ARM_TEGRA_CPUFREQ is still optional, so the select only applies when the
> Tegra cpufreq driver is enabled. This is mostly just out of convenience,
> though. The Tegra cpufreq driver uses the generic CPU0 cpufreq driver so
> a select will automatically pull in the necessary dependency. With a
Not necessarily. cpufreq-cpu0 can have few unmet dependency. And so
there are chances that tegra driver is compiled but cpufreq-cpu0 isn't as
we didn't mention it as a *hard* dependency.
And so at boot, there wouldn't be any cpufreq support even when tegra's
cpufreq driver is available.
Though, menuconfig may give some warnings no such situations.
> "depends on" the Tegra cpufreq driver only becomes available after
> you've selected GENERIC_CPUFREQ_CPU0, which is somewhat unintuitive.
>
> To illustrate with an example: as a user, I want to enable CPU frequency
> scaling on Tegra. So I use menuconfig to navigate to the "CPU Frequency
> scaling" menu (enable it if not available yet) and look for an entry
> that says "Tegra". But I can't find it because it's hidden due to the
> lack of GENERIC_CPUFREQ_CPU0. That the Tegra CPU frequency driver uses a
> generic driver is an implementation detail that users shouldn't have to
> be aware of.
Don't know, the guy compiling out stuff should be knowledgeable enough to
have a look why tegra cpufreq entry isn't shown in menu. As, probably the
above problem I mentioned looks to be of more significance than this one,
atleast to me :)
And, another thing to mention is that CONFIG_TEGRA_CPUFREQ is valid
for earlier platforms as well and so a select/depends wouldn't be valid for
earlier platforms. We probably need another Kconfig entry here.
> But we're using cpu_dev->of_node, so we need to make sure cpu_dev
> doesn't go away suddenly. Simply keeping a reference to ->of_node
> won't ensure that.
Oh, yeah I completely agree, but don't see that as a normal code style
people follow. Probably they take cpu for granted, which doesn't look
right :)
> I guess technically it would be better if get_cpu_device() already
> incremented the reference count on the returned struct device. Currently
> it would theoretically still be possible for the device to disappear
> between the call to get_cpu_device() and a call to get_device().
I agree again.
^ permalink raw reply
* [PATCH v5 1/3] arm64: ptrace: reload a syscall number after ptrace operations
From: Will Deacon @ 2014-07-23 8:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53CF5E53.3060409@linaro.org>
On Wed, Jul 23, 2014 at 08:03:47AM +0100, AKASHI Takahiro wrote:
> On 07/23/2014 05:15 AM, Kees Cook wrote:
> > On Tue, Jul 22, 2014 at 2:14 AM, AKASHI Takahiro
> > <takahiro.akashi@linaro.org> wrote:
> >> asmlinkage int syscall_trace_enter(struct pt_regs *regs)
> >> {
> >> + unsigned long saved_x0, saved_x8;
> >> +
> >> + saved_x0 = regs->regs[0];
> >> + saved_x8 = regs->regs[8];
> >> +
> >> if (test_thread_flag(TIF_SYSCALL_TRACE))
> >> tracehook_report_syscall(regs, PTRACE_SYSCALL_ENTER);
> >>
> >> + regs->syscallno = regs->regs[8];
> >> + if ((long)regs->syscallno == ~0UL) { /* skip this syscall */
> >> + regs->regs[8] = saved_x8;
> >> + if (regs->regs[0] == saved_x0) /* not changed by user */
> >> + regs->regs[0] = -ENOSYS;
> >
> > I'm not sure this is right compared to other architectures. Generally
> > when a tracer performs a syscall skip, it's up to them to also adjust
> > the return value. They may want to be faking a syscall, and what if
> > the value they want to return happens to be what x0 was going into the
> > tracer? It would have no way to avoid this -ENOSYS case. I think
> > things are fine without this test.
>
> Yeah, I know this issue, but was not sure that setting a return value
> is mandatory. (x86 seems to return -ENOSYS by default if not explicitly
> specified.)
> Is "fake a system call" a more appropriate word than "skip"?
>
> I will defer to Will.
I agree with Kees -- iirc, I only suggested restoring x8.
Will
^ permalink raw reply
* [PATCH v5 2/2] Documentation:add DMA support for freescale i2c driver
From: Yuan Yao @ 2014-07-23 8:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1406103883-3572-1-git-send-email-yao.yuan@freescale.com>
Add i2c dts node properties for eDMA support, them depend on the eDMA driver.
Signed-off-by: Yuan Yao <yao.yuan@freescale.com>
---
Documentation/devicetree/bindings/i2c/i2c-imx.txt | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-imx.txt b/Documentation/devicetree/bindings/i2c/i2c-imx.txt
index 4a8513e..52d37fd 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-imx.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-imx.txt
@@ -11,6 +11,8 @@ Required properties:
Optional properties:
- clock-frequency : Constains desired I2C/HS-I2C bus clock frequency in Hz.
The absence of the propoerty indicates the default frequency 100 kHz.
+- dmas: A list of two dma specifiers, one for each entry in dma-names.
+- dma-names: should contain "tx" and "rx".
Examples:
@@ -26,3 +28,12 @@ i2c at 70038000 { /* HS-I2C on i.MX51 */
interrupts = <64>;
clock-frequency = <400000>;
};
+
+i2c0: i2c at 40066000 { /* i2c0 on vf610 */
+ compatible = "fsl,vf610-i2c";
+ reg = <0x40066000 0x1000>;
+ interrupts =<0 71 0x04>;
+ dmas = <&edma0 0 50>,
+ <&edma0 0 51>;
+ dma-names = "rx","tx";
+};
--
1.8.4
^ permalink raw reply related
* [PATCH v5 1/2] i2c: add DMA support for freescale i2c driver
From: Yuan Yao @ 2014-07-23 8:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1406103883-3572-1-git-send-email-yao.yuan@freescale.com>
Add dma support for i2c. This function depend on DMA driver.
You can turn on it by write both the dmas and dma-name properties in dts node.
Signed-off-by: Yuan Yao <yao.yuan@freescale.com>
---
drivers/i2c/busses/i2c-imx.c | 377 +++++++++++++++++++++++++++++++++++++------
1 file changed, 324 insertions(+), 53 deletions(-)
diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
index 1d7efa3..a9893c3 100644
--- a/drivers/i2c/busses/i2c-imx.c
+++ b/drivers/i2c/busses/i2c-imx.c
@@ -37,22 +37,27 @@
/** Includes *******************************************************************
*******************************************************************************/
-#include <linux/init.h>
-#include <linux/kernel.h>
-#include <linux/module.h>
+#include <linux/clk.h>
+#include <linux/completion.h>
+#include <linux/delay.h>
+#include <linux/dma-mapping.h>
+#include <linux/dmaengine.h>
+#include <linux/dmapool.h>
#include <linux/errno.h>
#include <linux/err.h>
#include <linux/interrupt.h>
-#include <linux/delay.h>
#include <linux/i2c.h>
+#include <linux/init.h>
#include <linux/io.h>
-#include <linux/sched.h>
-#include <linux/platform_device.h>
-#include <linux/clk.h>
-#include <linux/slab.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
#include <linux/of.h>
#include <linux/of_device.h>
+#include <linux/of_dma.h>
#include <linux/platform_data/i2c-imx.h>
+#include <linux/platform_device.h>
+#include <linux/sched.h>
+#include <linux/slab.h>
/** Defines ********************************************************************
*******************************************************************************/
@@ -63,6 +68,10 @@
/* Default value */
#define IMX_I2C_BIT_RATE 100000 /* 100kHz */
+/* enable DMA if transfer byte size is bigger than this threshold */
+#define IMX_I2C_DMA_THRESHOLD 16
+#define IMX_I2C_DMA_TIMEOUT 1000
+
/* IMX I2C registers:
* the I2C register offset is different between SoCs,
* to provid support for all these chips, split the
@@ -88,6 +97,7 @@
#define I2SR_IBB 0x20
#define I2SR_IAAS 0x40
#define I2SR_ICF 0x80
+#define I2CR_DMAEN 0x02
#define I2CR_RSTA 0x04
#define I2CR_TXAK 0x08
#define I2CR_MTX 0x10
@@ -174,6 +184,17 @@ struct imx_i2c_hwdata {
unsigned i2cr_ien_opcode;
};
+struct imx_i2c_dma {
+ struct dma_chan *chan_tx;
+ struct dma_chan *chan_rx;
+ struct dma_chan *chan_using;
+ struct completion cmd_complete;
+ dma_addr_t dma_buf;
+ unsigned int dma_len;
+ unsigned int dma_transfer_dir;
+ unsigned int dma_data_dir;
+};
+
struct imx_i2c_struct {
struct i2c_adapter adapter;
struct clk *clk;
@@ -184,6 +205,8 @@ struct imx_i2c_struct {
int stopped;
unsigned int ifdr; /* IMX_I2C_IFDR */
const struct imx_i2c_hwdata *hwdata;
+
+ struct imx_i2c_dma *dma;
};
static const struct imx_i2c_hwdata imx1_i2c_hwdata = {
@@ -254,6 +277,133 @@ static inline unsigned char imx_i2c_read_reg(struct imx_i2c_struct *i2c_imx,
return readb(i2c_imx->base + (reg << i2c_imx->hwdata->regshift));
}
+/* Functions for DMA support */
+static int i2c_imx_dma_request(struct imx_i2c_struct *i2c_imx,
+ dma_addr_t phy_addr)
+{
+ struct imx_i2c_dma *dma;
+ struct dma_slave_config dma_sconfig;
+ struct device *dev = &i2c_imx->adapter.dev;
+ int ret;
+
+ dma = devm_kzalloc(dev, sizeof(struct imx_i2c_dma), GFP_KERNEL);
+ if (!dma) {
+ dev_info(dev, "can't allocate DMA struct\n");
+ return -ENOMEM;
+ }
+
+ dma->chan_tx = dma_request_slave_channel(dev, "tx");
+
+ if (!dma->chan_tx) {
+ dev_info(dev, "DMA tx channel request failed\n");
+ ret = -ENODEV;
+ goto fail_al;
+ }
+
+ dma_sconfig.dst_addr = phy_addr +
+ (IMX_I2C_I2DR << i2c_imx->hwdata->regshift);
+ dma_sconfig.dst_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
+ dma_sconfig.dst_maxburst = 1;
+ dma_sconfig.direction = DMA_MEM_TO_DEV;
+ ret = dmaengine_slave_config(dma->chan_tx, &dma_sconfig);
+ if (ret < 0) {
+ dev_info(dev, "DMA slave config failed, err = %d\n", ret);
+ goto fail_tx;
+ }
+
+ dma->chan_rx = dma_request_slave_channel(dev, "rx");
+ if (!dma->chan_rx) {
+ dev_info(dev, "DMA rx channel request failed\n");
+ ret = -ENODEV;
+ goto fail_tx;
+ }
+
+ dma_sconfig.src_addr = phy_addr +
+ (IMX_I2C_I2DR << i2c_imx->hwdata->regshift);
+ dma_sconfig.src_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
+ dma_sconfig.src_maxburst = 1;
+ dma_sconfig.direction = DMA_DEV_TO_MEM;
+ ret = dmaengine_slave_config(dma->chan_rx, &dma_sconfig);
+ if (ret < 0) {
+ dev_info(dev, "DMA slave config failed, err = %d\n", ret);
+ goto fail_rx;
+ }
+
+ i2c_imx->dma = dma;
+
+ init_completion(&dma->cmd_complete);
+
+ return 0;
+
+fail_rx:
+ dma_release_channel(dma->chan_rx);
+fail_tx:
+ dma_release_channel(dma->chan_tx);
+fail_al:
+ devm_kfree(dev, dma);
+
+ return ret;
+}
+
+static void i2c_imx_dma_callback(void *arg)
+{
+ struct imx_i2c_struct *i2c_imx = (struct imx_i2c_struct *)arg;
+ struct imx_i2c_dma *dma = i2c_imx->dma;
+
+ dma_unmap_single(dma->chan_using->device->dev, dma->dma_buf,
+ dma->dma_len, dma->dma_data_dir);
+ complete(&dma->cmd_complete);
+}
+
+static int i2c_imx_dma_xfer(struct imx_i2c_struct *i2c_imx,
+ struct i2c_msg *msgs)
+{
+ struct imx_i2c_dma *dma = i2c_imx->dma;
+ struct dma_async_tx_descriptor *txdesc;
+ struct device *dev = &i2c_imx->adapter.dev;
+ struct device *chan_dev = dma->chan_using->device->dev;
+
+ dma->dma_buf = dma_map_single(chan_dev, msgs->buf,
+ dma->dma_len, dma->dma_data_dir);
+ if (dma_mapping_error(chan_dev, dma->dma_buf)) {
+ dev_err(dev, "DMA mapping failed\n");
+ return -EINVAL;
+ }
+
+ txdesc = dmaengine_prep_slave_single(dma->chan_using, dma->dma_buf,
+ dma->dma_len, dma->dma_transfer_dir,
+ DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+ if (!txdesc) {
+ dev_err(dev, "Not able to get desc for DMA xfer\n");
+ dma_unmap_single(chan_dev, dma->dma_buf,
+ dma->dma_len, dma->dma_data_dir);
+ return -EINVAL;
+ }
+
+ txdesc->callback = i2c_imx_dma_callback;
+ txdesc->callback_param = i2c_imx;
+ dmaengine_submit(txdesc);
+ dma_async_issue_pending(dma->chan_using);
+
+ return 0;
+}
+
+static void i2c_imx_dma_free(struct imx_i2c_struct *i2c_imx)
+{
+ struct imx_i2c_dma *dma = i2c_imx->dma;
+
+ dma->dma_buf = 0;
+ dma->dma_len = 0;
+
+ dma_release_channel(dma->chan_tx);
+ dma->chan_tx = NULL;
+
+ dma_release_channel(dma->chan_rx);
+ dma->chan_rx = NULL;
+
+ dma->chan_using = NULL;
+}
+
/** Functions for IMX I2C adapter driver ***************************************
*******************************************************************************/
@@ -332,6 +482,11 @@ static int i2c_imx_start(struct imx_i2c_struct *i2c_imx)
temp |= I2CR_IIEN | I2CR_MTX | I2CR_TXAK;
imx_i2c_write_reg(temp, i2c_imx, IMX_I2C_I2CR);
+
+ temp = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2CR);
+ temp &= ~I2CR_DMAEN;
+ imx_i2c_write_reg(temp, i2c_imx, IMX_I2C_I2CR);
+
return result;
}
@@ -425,44 +580,104 @@ static irqreturn_t i2c_imx_isr(int irq, void *dev_id)
static int i2c_imx_write(struct imx_i2c_struct *i2c_imx, struct i2c_msg *msgs)
{
- int i, result;
+ int i, result, timeout = IMX_I2C_DMA_TIMEOUT;
+ unsigned int temp = 0;
+ struct imx_i2c_dma *dma = i2c_imx->dma;
+ struct device *dev = &i2c_imx->adapter.dev;
- dev_dbg(&i2c_imx->adapter.dev, "<%s> write slave address: addr=0x%x\n",
+ dev_dbg(dev, "<%s> write slave address: addr=0x%x\n",
__func__, msgs->addr << 1);
+ if (dma && msgs->len >= IMX_I2C_DMA_THRESHOLD) {
+ reinit_completion(&i2c_imx->dma->cmd_complete);
+ dma->chan_using = dma->chan_tx;
+ dma->dma_transfer_dir = DMA_MEM_TO_DEV;
+ dma->dma_data_dir = DMA_TO_DEVICE;
+ dma->dma_len = msgs->len - 1;
+ result = i2c_imx_dma_xfer(i2c_imx, msgs);
+ if (result)
+ return result;
- /* write slave address */
- imx_i2c_write_reg(msgs->addr << 1, i2c_imx, IMX_I2C_I2DR);
- result = i2c_imx_trx_complete(i2c_imx);
- if (result)
- return result;
- result = i2c_imx_acked(i2c_imx);
- if (result)
- return result;
- dev_dbg(&i2c_imx->adapter.dev, "<%s> write data\n", __func__);
+ temp = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2CR);
+ temp |= I2CR_DMAEN;
+ imx_i2c_write_reg(temp, i2c_imx, IMX_I2C_I2CR);
- /* write data */
- for (i = 0; i < msgs->len; i++) {
- dev_dbg(&i2c_imx->adapter.dev,
- "<%s> write byte: B%d=0x%X\n",
- __func__, i, msgs->buf[i]);
- imx_i2c_write_reg(msgs->buf[i], i2c_imx, IMX_I2C_I2DR);
+ /*
+ * Write slave address.
+ * The first byte muse be transmitted by the CPU.
+ */
+ imx_i2c_write_reg(msgs->addr << 1, i2c_imx, IMX_I2C_I2DR);
+ result = wait_for_completion_interruptible_timeout(
+ &i2c_imx->dma->cmd_complete,
+ msecs_to_jiffies(IMX_I2C_DMA_TIMEOUT));
+ if (result <= 0) {
+ dmaengine_terminate_all(dma->chan_using);
+ if (result)
+ return result;
+ else
+ return -ETIMEDOUT;
+ }
+
+ /* Waiting for Transfer complete. */
+ while (timeout--) {
+ temp = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2SR);
+ if (temp & I2SR_ICF)
+ break;
+ udelay(10);
+ }
+
+ if (!timeout)
+ return -ETIMEDOUT;
+ temp = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2CR);
+ temp &= ~I2CR_DMAEN;
+ imx_i2c_write_reg(temp, i2c_imx, IMX_I2C_I2CR);
+
+ /* The last data byte must be transferred by the CPU. */
+ imx_i2c_write_reg(msgs->buf[msgs->len-1],
+ i2c_imx, IMX_I2C_I2DR);
result = i2c_imx_trx_complete(i2c_imx);
if (result)
return result;
+
result = i2c_imx_acked(i2c_imx);
if (result)
return result;
+ } else {
+ /* write slave address */
+ imx_i2c_write_reg(msgs->addr << 1, i2c_imx, IMX_I2C_I2DR);
+ result = i2c_imx_trx_complete(i2c_imx);
+ if (result)
+ return result;
+
+ result = i2c_imx_acked(i2c_imx);
+ if (result)
+ return result;
+
+ dev_dbg(dev, "<%s> write data\n", __func__);
+
+ /* write data */
+ for (i = 0; i < msgs->len; i++) {
+ dev_dbg(dev, "<%s> write byte: B%d=0x%X\n",
+ __func__, i, msgs->buf[i]);
+ imx_i2c_write_reg(msgs->buf[i], i2c_imx, IMX_I2C_I2DR);
+ result = i2c_imx_trx_complete(i2c_imx);
+ if (result)
+ return result;
+ result = i2c_imx_acked(i2c_imx);
+ if (result)
+ return result;
+ }
}
return 0;
}
static int i2c_imx_read(struct imx_i2c_struct *i2c_imx, struct i2c_msg *msgs)
{
- int i, result;
+ int i, result, timeout = IMX_I2C_DMA_TIMEOUT;
unsigned int temp;
+ struct imx_i2c_dma *dma = i2c_imx->dma;
+ struct device *dev = &i2c_imx->adapter.dev;
- dev_dbg(&i2c_imx->adapter.dev,
- "<%s> write slave address: addr=0x%x\n",
+ dev_dbg(dev, "<%s> write slave address: addr=0x%x\n",
__func__, (msgs->addr << 1) | 0x01);
/* write slave address */
@@ -474,7 +689,7 @@ static int i2c_imx_read(struct imx_i2c_struct *i2c_imx, struct i2c_msg *msgs)
if (result)
return result;
- dev_dbg(&i2c_imx->adapter.dev, "<%s> setup bus\n", __func__);
+ dev_dbg(dev, "<%s> setup bus\n", __func__);
/* setup bus to read data */
temp = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2CR);
@@ -484,35 +699,82 @@ static int i2c_imx_read(struct imx_i2c_struct *i2c_imx, struct i2c_msg *msgs)
imx_i2c_write_reg(temp, i2c_imx, IMX_I2C_I2CR);
imx_i2c_read_reg(i2c_imx, IMX_I2C_I2DR); /* dummy read */
- dev_dbg(&i2c_imx->adapter.dev, "<%s> read data\n", __func__);
+ dev_dbg(dev, "<%s> read data\n", __func__);
- /* read data */
- for (i = 0; i < msgs->len; i++) {
- result = i2c_imx_trx_complete(i2c_imx);
+ if (dma && msgs->len >= IMX_I2C_DMA_THRESHOLD) {
+ temp = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2CR);
+ temp |= I2CR_DMAEN;
+ imx_i2c_write_reg(temp, i2c_imx, IMX_I2C_I2CR);
+
+ reinit_completion(&i2c_imx->dma->cmd_complete);
+ dma->chan_using = dma->chan_rx;
+ dma->dma_transfer_dir = DMA_DEV_TO_MEM;
+ dma->dma_data_dir = DMA_FROM_DEVICE;
+ /* The last two data bytes must be transferred by the CPU. */
+ dma->dma_len = msgs->len - 2;
+ result = i2c_imx_dma_xfer(i2c_imx, msgs);
if (result)
return result;
- if (i == (msgs->len - 1)) {
- /* It must generate STOP before read I2DR to prevent
- controller from generating another clock cycle */
- dev_dbg(&i2c_imx->adapter.dev,
- "<%s> clear MSTA\n", __func__);
- temp = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2CR);
- temp &= ~(I2CR_MSTA | I2CR_MTX);
- imx_i2c_write_reg(temp, i2c_imx, IMX_I2C_I2CR);
- i2c_imx_bus_busy(i2c_imx, 0);
- i2c_imx->stopped = 1;
- } else if (i == (msgs->len - 2)) {
- dev_dbg(&i2c_imx->adapter.dev,
- "<%s> set TXAK\n", __func__);
- temp = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2CR);
- temp |= I2CR_TXAK;
- imx_i2c_write_reg(temp, i2c_imx, IMX_I2C_I2CR);
+
+ result = wait_for_completion_interruptible_timeout(
+ &i2c_imx->dma->cmd_complete,
+ msecs_to_jiffies(IMX_I2C_DMA_TIMEOUT));
+ if (result <= 0) {
+ dmaengine_terminate_all(dma->chan_using);
+ if (result)
+ return result;
+ else
+ return -ETIMEDOUT;
}
- msgs->buf[i] = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2DR);
- dev_dbg(&i2c_imx->adapter.dev,
- "<%s> read byte: B%d=0x%X\n",
- __func__, i, msgs->buf[i]);
+
+ /* waiting for Transfer complete. */
+ while (timeout--) {
+ temp = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2SR);
+ if (temp & I2SR_ICF)
+ break;
+ udelay(10);
+ }
+
+ if (!timeout)
+ return -ETIMEDOUT;
+ temp = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2CR);
+ temp &= ~I2CR_DMAEN;
+ imx_i2c_write_reg(temp, i2c_imx, IMX_I2C_I2CR);
+ } else {
+ /* read data */
+ for (i = 0; i < msgs->len - 2; i++) {
+ result = i2c_imx_trx_complete(i2c_imx);
+ if (result)
+ return result;
+ msgs->buf[i] = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2DR);
+ dev_dbg(dev, "<%s> read byte: B%d=0x%X\n",
+ __func__, i, msgs->buf[i]);
+ }
+ result = i2c_imx_trx_complete(i2c_imx);
}
+
+ /* read n-1 byte data */
+ temp = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2CR);
+ temp |= I2CR_TXAK;
+ imx_i2c_write_reg(temp, i2c_imx, IMX_I2C_I2CR);
+
+ msgs->buf[msgs->len-2] = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2DR);
+ /* read n byte data */
+ result = i2c_imx_trx_complete(i2c_imx);
+ if (result)
+ return result;
+
+ /*
+ * It must generate STOP before read I2DR to prevent
+ * controller from generating another clock cycle
+ */
+ temp = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2CR);
+ temp &= ~(I2CR_MSTA | I2CR_MTX);
+ imx_i2c_write_reg(temp, i2c_imx, IMX_I2C_I2CR);
+ i2c_imx_bus_busy(i2c_imx, 0);
+ i2c_imx->stopped = 1;
+ msgs->buf[msgs->len-1] = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2DR);
+
return 0;
}
@@ -599,6 +861,7 @@ static int i2c_imx_probe(struct platform_device *pdev)
void __iomem *base;
int irq, ret;
u32 bitrate;
+ u32 phy_addr;
dev_dbg(&pdev->dev, "<%s>\n", __func__);
@@ -609,6 +872,7 @@ static int i2c_imx_probe(struct platform_device *pdev)
}
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ phy_addr = res->start;
base = devm_ioremap_resource(&pdev->dev, res);
if (IS_ERR(base))
return PTR_ERR(base);
@@ -694,6 +958,10 @@ static int i2c_imx_probe(struct platform_device *pdev)
i2c_imx->adapter.name);
dev_info(&i2c_imx->adapter.dev, "IMX I2C adapter registered\n");
+ /* Init DMA config if support*/
+ if (i2c_imx_dma_request(i2c_imx, (dma_addr_t)phy_addr))
+ dev_warn(&pdev->dev, "can't request DMA\n");
+
return 0; /* Return OK */
}
@@ -705,6 +973,9 @@ static int i2c_imx_remove(struct platform_device *pdev)
dev_dbg(&i2c_imx->adapter.dev, "adapter removed\n");
i2c_del_adapter(&i2c_imx->adapter);
+ if (i2c_imx->dma)
+ i2c_imx_dma_free(i2c_imx);
+
/* setup chip registers to defaults */
imx_i2c_write_reg(0, i2c_imx, IMX_I2C_IADR);
imx_i2c_write_reg(0, i2c_imx, IMX_I2C_IFDR);
--
1.8.4
^ permalink raw reply related
* [PATCH v5 0/2] i2c: add DMA support for freescale i2c driver
From: Yuan Yao @ 2014-07-23 8:24 UTC (permalink / raw)
To: linux-arm-kernel
Changed in v5:
- add "*chan_dev = dma->chan_using->device->dev" for reduce the call time.
- add the test logs.
Changed in v4:
- cancelled "i2c_imx->use_dma".
- changed "Dma" to "DMA".
- add Timeout handling for Transfer complete.
Changed in v3:
- fix a bug when request the dma faild.
- some minor fixes for coding style.
- other minor fixes.
Changed in v2:
- remove has_dma_support property
- unify i2c_imx_dma_rx and i2c_imx_dma_tx
- unify i2c_imx_dma_read and i2c_imx_pio_read
- unify i2c_imx_dma_write and i2c_imx_pio_write
Added in v1:
- Enable dma if it's support dma and transfer size bigger than the threshold.
- Add device tree bindings for i2c eDMA support.
- Add eDMA support for i2c driver.
The test log:(one EEPROM on I2C2, use i2cdump tools)
U-Boot 2014.01-00634-g22b2f38-dirty (Jul 17 2014 - 17:16:37)
CPU: Freescale LayerScape SLS1020, Version: 1.0, (0x87080010)
Clock Configuration:
CPU0(ARMV7):1000 MHz,
Bus:300 MHz, DDR:800 MHz (1600 MT/s data rate), Reset Configuration Word (RCW):
00000000: 0608000a 00000000 00000000 00000000
00000010: 20000000 00407900 e0025a00 21046000
00000020: 00000000 00000000 00000000 00038000
00000030: 00000000 881b7540 00000000 00000000
Board: LS1021ATWR
CPLD: V1.1
PCBA: V2.0
VBank: 1
I2C: ready
DRAM: PGTABLE_SIZE 4000, gd->relocaddr c0000000
gd->relocaddr bfffc000
gd->relocaddr bfff0000
TLB table from bfff0000 to bfff4000
1 GiB
Using SERDES1 Protocol: 32 (0x20)
Flash: 128 MiB
MMC: FSL_SDHC: 0
EEPROM: ret 1 0
ret 2 0
ID: NXID v16777216
SN:
Errata:
Build date: 2014/07/17 12:12:12
Eth0: 00:04:9f:ef:00:00
Eth1: 00:04:9f:ef:01:01
Eth2: 00:04:9f:ef:02:02
Eth3: 00:04:9f:ef:03:03
CRC: bf83b86a
NXID v16777216
In: serial
Out: serial
Err: serial
Net: eTSEC1 is in sgmii mode.
eTSEC2 is in sgmii mode.
eTSEC1 [PRIME], eTSEC2, eTSEC3
=> run yyboot
Speed: 1000, full duplex
BOOTP broadcast 1
BOOTP broadcast 2
*** Unhandled DHCP Option in OFFER/ACK: 44
*** Unhandled DHCP Option in OFFER/ACK: 46
*** Unhandled DHCP Option in OFFER/ACK: 44
*** Unhandled DHCP Option in OFFER/ACK: 46 DHCP client bound to address 10.193.20.30 Using eTSEC1 device TFTP from server 10.193.20.35; our IP address is 10.193.20.30 Filename 'twr/uImage.ls1'.
Load address: 0x82000000
Loading: #################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
###################################
2.7 MiB/s
done
Bytes transferred = 6236192 (5f2820 hex)
Speed: 1000, full duplex
Using eTSEC1 device
TFTP from server 10.193.20.35; our IP address is 10.193.20.30 Filename 'twr/ls1021a-twr.dtb'.
Load address: 0x8f000000
Loading: ##
229.5 KiB/s
done
Bytes transferred = 19995 (4e1b hex)
Speed: 1000, full duplex
Using eTSEC1 device
TFTP from server 10.193.20.35; our IP address is 10.193.20.30 Filename 'twr/Ramdisk.uboot'.
Load address: 0x88000000
Loading: #################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#####
2.9 MiB/s
done
Bytes transferred = 19156457 (1244de9 hex) ## Booting kernel from Legacy Image at 82000000 ...
Image Name: Linux Kernel
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 6236128 Bytes = 5.9 MiB
Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 88000000 ...
Image Name: fsl-image-core-ls1021atwr-201406
Image Type: ARM Linux RAMDisk Image (gzip compressed)
Data Size: 19156393 Bytes = 18.3 MiB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## Flattened Device Tree blob at 8f000000
Booting using the fdt blob at 0x8f000000
Loading Kernel Image ... OK
Using Device Tree in place at 8f000000, end 8f007e1a
Starting kernel ...
Booting Linux on physical CPU 0xf00
Linux version 3.12.0+ (b46683 at rock) (gcc version 4.8.3 20131202 (prerelease) (cr osstool-NG linaro-1.13.1-4.8-2013.12 - Linaro GCC 2013.11) ) #190 SMP Fri Jul 18 14:24:11 CST 2014
CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=30c73c7d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine: Freescale Layerscape LS1021A, model: LS1021A TWR Board Memory policy: ECC disabled, Data cache writealloc
PERCPU: Embedded 7 pages/cpu @89a56000 s7680 r8192 d12800 u32768 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 260096 Kernel command line: root=/dev/ram0 rw console=ttyS0,115200 PID hash table entries: 4096 (order: 2, 16384 bytes) Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 1014380K/1048576K available (4367K kernel code, 241K rwdata, 1288K rodat a, 191K init, 215K bss, 34196K reserved, 0K highmem)
Virtual kernel memory layout:
vector : 0xffff0000 - 0xffff1000 ( 4 kB)
fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
vmalloc : 0xc0800000 - 0xff000000 (1000 MB)
lowmem : 0x80000000 - 0xc0000000 (1024 MB)
pkmap : 0x7fe00000 - 0x80000000 ( 2 MB)
modules : 0x7f000000 - 0x7fe00000 ( 14 MB)
.text : 0x80008000 - 0x8058df74 (5656 kB)
.init : 0x8058e000 - 0x805bde00 ( 192 kB)
.data : 0x805be000 - 0x805fa7d8 ( 242 kB)
.bss : 0x805fa7e0 - 0x806305a8 ( 216 kB)
SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1 Hierarchical RCU implementation.
RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2.
NR_IRQS:16 nr_irqs:16 16
Architected cp15 timer(s) running at 12.50MHz (phys).
Switching to timer-based delay loop
sched_clock: ARM arch timer >56 bits at 12500kHz, resolution 80ns
sched_clock: 32 bits at 100 Hz, resolution 10000000ns, wraps every 4294967286ms
Console: colour dummy device 80x30
Calibrating delay loop (skipped), value calculated using timer frequency.. 25.00 BogoMIPS (lpj=125000)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
CPU0: update cpu_power 1024
CPU0: thread -1, cpu 0, socket 15, mpidr 80000f00 Setting up static identity map for 0x8044a3c0 - 0x8044a3f4
CPU1: Booted secondary processor
CPU1: update cpu_power 1024
CPU1: thread -1, cpu 1, socket 15, mpidr 80000f01 Brought up 2 CPUs
SMP: Total of 2 processors activated.
CPU: All CPU(s) started in HYP mode.
CPU: Virtualization extensions available.
devtmpfs: initialized
VFP support v0.3: implementor 41 architecture 2 part 30 variant 7 rev 5
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
cpuidle: using governor ladder
cpuidle: using governor menu
OF: no ranges; cannot translate
OF: no ranges; cannot translate
bio: create slab <bio-0> at 0
vgaarb: loaded
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb i2c i2c-0: IMX I2C adapter registered i2c i2c-1: IMX I2C adapter registered
pps_core: LinuxPPS API ver. 1 registered
pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@l inux.it>
PTP clock support registered
fsl-ifc 1530000.ifc: Freescale Integrated Flash Controller Switched to clocksource arch_sys_counter
NET: Registered protocol family 2
TCP established hash table entries: 8192 (order: 4, 65536 bytes) TCP bind hash table entries: 8192 (order: 5, 163840 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP: reno registered
UDP hash table entries: 512 (order: 2, 24576 bytes) UDP-Lite hash table entries: 512 (order: 2, 24576 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
Trying to unpack rootfs image as initramfs...
rootfs image is not initramfs (no cpio magic); looks like an initrd Freeing initrd memory: 18700K (88001000 - 89244000)
NFS: Registering the id_resolver key type Key type id_resolver registered Key type id_legacy registered
jffs2: version 2.2. (NAND) ? 2001-2006 Red Hat, Inc.
msgmni has been set to 2017
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
21c0500.serial: ttyS0 at MMIO 0x21c0500 (irq = 118, base_baud = 9375000) is a 16 550A
console [ttyS0] enabled
21c0600.serial: ttyS1 at MMIO 0x21c0600 (irq = 118, base_baud = 9375000) is a 16 550A
serial: Freescale lpuart driver
2950000.serial: ttyLP0 at MMIO 0x2950000 (irq = 112, base_baud = 6250000) is a F SL_LPUART
brd: module loaded
loop: module loaded
60000000.nor: Found 1 x16 devices at 0x0 in 16-bit bank. Manufacturer ID 0x00008 9 Chip ID 0x00227e
Amd/Fujitsu Extended Query Table at 0x0040
Amd/Fujitsu Extended Query version 1.3.
number of CFI chips: 1
4 ofpart partitions found on MTD device 60000000.nor Creating 4 MTD partitions on "60000000.nor":
0x000000000000-0x000000020000 : "NOR RCW Image"
0x000000020000-0x000000120000 : "NOR DTB Image"
0x000000120000-0x000000920000 : "NOR Linux Kernel Image"
0x000000920000-0x000003b20000 : "NOR Ramdisk Root File System"
6Freescale DSPI master initialized
CAN device driver interface
flexcan 2a70000.can: no ipg clock defined
flexcan: probe of 2a70000.can failed with error -2 flexcan 2a80000.can: no ipg clock defined
flexcan: probe of 2a80000.can failed with error -2
libphy: Freescale PowerQUICC MII Bus: probed mdio_bus mdio at 2d24000: cannot get PHY at address 8 fsl-gianfar ethernet.6: enabled errata workarounds, flags: 0x4 fsl-gianfar ethernet.6 eth0: mac: 00:04:9f:ef:00:00 fsl-gianfar ethernet.6 eth0: Running with NAPI enabled fsl-gianfar ethernet.6 eth0: RX BD ring size for Q[0]: 256 fsl-gianfar ethernet.6 eth0: TX BD ring size for Q[0]: 256 fsl-gianfar ethernet.7: enabled errata workarounds, flags: 0x4 fsl-gianfar ethernet.7 eth1: mac: 00:04:9f:ef:01:01 fsl-gianfar ethernet.7 eth1: Running with NAPI enabled fsl-gianfar ethernet.7 eth1: RX BD ring size for Q[0]: 256 fsl-gianfar ethernet.7 eth1: TX BD ring size for Q[0]: 256 fsl-gianfar ethernet.8: enabled errata workarounds, flags: 0x4 fsl-gianfar ethernet.8 eth2: mac: 00:04:9f:ef:02:02 fsl-gianfar ethernet.8 eth2: Running with NAPI enabled fsl-gianfar ethernet.8 eth2: RX BD ring size for Q[0]: 256 fsl-gianfar ethernet.8 eth2: TX BD ring size for Q[0]: 256
e1000: Intel(R) PRO/1000 Network Driver - version 7.3.21-k8-NAPI
e1000: Copyright (c) 1999-2006 Intel Corporation.
e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k
e1000e: Copyright(c) 1999 - 2013 Intel Corporation.
xhci-hcd xhci-hcd.0.auto: xHCI Host Controller xhci-hcd xhci-hcd.0.auto: new USB bus registered, assigned bus number 1 xhci-hcd xhci-hcd.0.auto: irq 125, io mem 0x03100000 hub 1-0:1.0: USB hub found hub 1-0:1.0: 1 port detected xhci-hcd xhci-hcd.0.auto: xHCI Host Controller xhci-hcd xhci-hcd.0.auto: new USB bus registered, assigned bus number 2 hub 2-0:1.0: USB hub found hub 2-0:1.0: 1 port detected
usbcore: registered new interface driver usb-storage
mousedev: PS/2 mouse device common for all mice i2c /dev entries driver
sdhci: Secure Digital Host Controller Interface driver
sdhci: Copyright(c) Pierre Ossman
sdhci-pltfm: SDHCI platform and OF driver helper
mmc0: SDHCI controller on 1560000.esdhc [1560000.esdhc] using ADMA Value in jrstart addr c0c0005c, value prev 0 new f caam 1700000.crypto: Instantiated RNG4 SH0 caam 1700000.crypto: Instantiated RNG4 SH1 caam 1700000.crypto: device ID = 0x0a140300 (Era 67108864) caam 1700000.crypto: job rings = 4, qi = 0 caam algorithms registered in /proc/crypto caam_jr 1710000.jr: registering rng-caam
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
TCP: cubic registered
Initializing XFRM netlink socket
NET: Registered protocol family 10
sit: IPv6 over IPv4 tunneling driver
NET: Registered protocol family 17
NET: Registered protocol family 15
can: controller area network core (rev 20120528 abi 9)
NET: Registered protocol family 29
can: raw protocol (rev 20120528)
Key type dns_resolver registered
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
RAMDISK: gzip image found at block 0
usb 1-1: new high-speed USB device number 2 using xhci-hcd hub 1-1:1.0: USB hub found hub 1-1:1.0: 4 ports detected usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd
usb 2-1: Parent hub missing LPM exit latency info. Power management will be imp acted.
hub 2-1:1.0: USB hub found
hub 2-1:1.0: 4 ports detected
VFS: Mounted root (ext2 filesystem) on device 1:0.
devtmpfs: mounted
Freeing unused kernel memory: 188K (8058e000 - 805bd000)
INIT: version 2.88 booting
Starting udev
udevd[108]: starting version 182
Starting Bootlog daemon: bootlogd.
Populating dev cache
Configuring network interfaces... IPv6: ADDRCONF(NETDEV_UP): eth0: link is not r eady
udhcpc (v1.21.1) started
Sending discover...
libphy: mdio at 2d24000:02 - Link is Down
Sending discover...
libphy: mdio at 2d24000:02 - Link is Up - 1000/Full
IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready Sending discover...
Sending select for 10.193.20.30...
Lease of 10.193.20.30 obtained, lease time 14400
/etc/udhcpc.d/50default: Adding DNS 10.192.130.201
/etc/udhcpc.d/50default: Adding DNS 10.211.0.3
/etc/udhcpc.d/50default: Adding DNS 10.196.51.200 done.
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.rp_filter = 1
hwclock: can't open '/dev/misc/rtc': No such file or directory Wed Jun 25 11:59:00 UTC 2014
hwclock: can't open '/dev/misc/rtc': No such file or directory Running postinst /etc/rpm-postinsts/100-sysvinit-inittab...
Running postinst /etc/rpm-postinsts/101-debianutils...
update-rc.d: /etc/init.d/run-postinsts exists during rc.d purge (continuing) Removing any system startup links for run-postinsts ...
/etc/rcS.d/S99run-postinsts
INIT: Entering runlevel: 5
Starting OpenBSD Secure Shell server: sshd
generating ssh RSA key...
generating ssh ECDSA key...
generating ssh DSA key...
done.
hwclock: can't open '/dev/misc/rtc': No such file or directory Starting network benchmark server: netserver.
Starting system log daemon...0
Starting kernel log daemon...0
Starting internet superserver: xinetd.
Stopping Bootlog daemon: bootlogd.
Poky (Yocto Project Reference Distro) 1.5 ls1021atwr /dev/ttyS0
ls1021atwr login: root
root at ls1021atwr:~# i2cset -f -y 1 0x52 0x30 0xb0 0xb1 0xb2 0xb3 0xb4 0xb5 0xb6 0xb7 0xb8 0xb9 0xba 0xbb 0xbc 0xbd 0xbe 0xbf i
root at ls1021atwr:~# i2cset -f -y 1 0x52 0x30 0xb0 0xb1 0xb2 0xb3 0xb4 0xb5 0xb6 0xb7 0xb8 0xb9 0xba 0xbb 0xbc 0xbd 0xbe 0xbf i
root at ls1021atwr:~# i2cset -f -y 1 0x52 0x30 0xb0 0xb1 0xb2 0xb3 0xb4 0xb5 0xb6 0xb7 0xb8 0xb9 0xba 0xbb 0xbc 0xbd 0xbe 0xbf i
root at ls1021atwr:~# i2cdump -y 1 0x52 i
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 10 11 12 13 14 15 16 17 17 38 0a 0b 0c 0d 0e 0f ?????????8??????
10: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f ????????????????
20: 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f .???????????????
30: b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 ba bb bc bd be bf ????????????????
40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
root at ls1021atwr:~# i2cdump -y 1 0x52 i
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 10 11 12 13 14 15 16 17 17 38 0a 0b 0c 0d 0e 0f ?????????8??????
10: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f ????????????????
20: 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f .???????????????
30: b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 ba bb bc bd be bf ????????????????
40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
root at ls1021atwr:~# i2cdump -y 1 0x52 i
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 10 11 12 13 14 15 16 17 17 38 0a 0b 0c 0d 0e 0f ?????????8??????
10: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f ????????????????
20: 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f .???????????????
30: b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 ba bb bc bd be bf ????????????????
40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
root at ls1021atwr:~# i2cdump -y 1 0x52 i
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 10 11 12 13 14 15 16 17 17 38 0a 0b 0c 0d 0e 0f ?????????8??????
10: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f ????????????????
20: 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f .???????????????
30: b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 ba bb bc bd be bf ????????????????
40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
root at ls1021atwr:~#
^ permalink raw reply
* [GIT PULL 4/5] Samsung exynos_mct update for v3.17
From: Daniel Lezcano @ 2014-07-23 8:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53CEF4BC.1050105@samsung.com>
On 07/23/2014 01:33 AM, Kukjin Kim wrote:
> On 07/23/14 02:32, Daniel Lezcano wrote:
>> On 07/22/2014 12:59 PM, Kukjin Kim wrote:
>>> Daniel Lezcano wrote:
>>>>
>>>> On 07/20/2014 12:06 AM, Olof Johansson wrote:
>>>>> On Sat, Jul 19, 2014 at 09:52:52AM +0900, Kukjin Kim wrote:
>>>>>> Note that this is also based on 3.16-rc5 because of dependency with
>>>>>> previous samsung fixes including exynos_mct already merged in
>>>>>> mainline during -rc.
>>>>>>
>>>>>> The following changes since commit
>>>>>> 1795cd9b3a91d4b5473c97f491d63892442212ab:
>>>>>>
>>>>>> Linux 3.16-rc5 (2014-07-13 14:04:33 -0700)
>>>>>>
>>>>>> are available in the git repository at:
>>>>>>
>>>>>
>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
>>>>>> tags/exynos-mct
>>>>>>
>>>>>> for you to fetch changes up to
>>>>>> 1a631118c1d085fe162f3b6d44f710c72206ef2d:
>>>>>>
>>>>>> clocksource: exynos_mct: Only use 32-bits where possible
>>>>>> (2014-07-19 03:07:52 +0900)
>>>>>>
>>>>>> ----------------------------------------------------------------
>>>>>> exynos_mct update for v3.17
>>>>>> - only use 32-bit access for performance benefits on exynos
>>>>>> 32-bit system and this means ARCH timer should be supported
>>>>>> on exynos 64-bit system instead of current MCT.
>>>>>> - use readl_relaxed/writel_relaxed to consistently use the
>>>>>> proper functions in exynos_mct.
>>>>>
>>>>> There's no reason for these to go through arm-soc, is there? They
>>>>> should
>>>>> go through the clocksource tree (Daniel Lezcano / Thomas Gleixner).
>>>>> They
>>>>> also lack acks from them if they for some reason need to go through
>>>>> arm-soc.
>>>>
>>> Olof, you're right. The branch has no dependency with arm-soc so I
>>> agreed.
>>>
>>>> Yes, that's right. Furthermore I have been discussing with Doug about
>>>> these patches before.
>>>>
>>>> Kukjin, is there any dependency on these patches ?
>>>>
>>> Yeah, Daniel, it should be handled in the clocksource tree so how
>>> should I do
>>> for it?
>>
>> I can pull your branch v3.17-next/mct-exynos and you drop the merge from
>> this branch in your master ?
>>
> Yes please and I did drop the merge in my -next just now.
Ok, thanks.
The patches are applied in my branch for 3.17.
-- Daniel
--
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* [PATCH] Input: s3c2410_ts: Move to clk_prepare_enable/clk_disable_unprepare
From: Vasily Khoruzhick @ 2014-07-23 7:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140723060913.GD25004@core.coreip.homeip.net>
On 22 July 2014 23:09:14 Dmitry Torokhov wrote:
> Hi Vasily,
>
> On Wed, Jul 09, 2014 at 12:13:41PM +0300, Vasily Khoruzhick wrote:
> > On 8 July 2014 18:00:49 Dmitry Torokhov wrote:
> >
> > Hi Dmitry,
> >
> > > > - clk_disable(ts.clock);
> > > > + clk_disable_unprepare(ts.clock);
> > >
> > > Do we really need to unprepare on suspend? Why simply disabling is not
> > > enough here?
> >
> > You're right, disabling should be enough here. I'll resend a patch after
> > testing on a hardware.
>
> I ended up cutting out suspend/resume parts and applying.
Ah, I was about to send v2. I've tested a version with clk_disable/clk_enable
in suspend/resume parts, and it works OK for me.
Thanks!
Regards,
Vasily
>
> Thanks.
^ permalink raw reply
* [PATCH 2/6] net/macb: add scatter-gather hw feature
From: Cyrille Pitchen @ 2014-07-23 7:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140720.211337.211665722122921773.davem@davemloft.net>
Le 21/07/2014 06:13, David Miller a ?crit :
> From: Cyrille Pitchen <cyrille.pitchen@atmel.com>
> Date: Fri, 18 Jul 2014 16:21:14 +0200
>
>> + if (tx_skb->mapped_as_page) {
>> + dma_unmap_page(&bp->pdev->dev, tx_skb->mapping,
>> + tx_skb->size, DMA_TO_DEVICE);
>> + } else {
>> + dma_unmap_single(&bp->pdev->dev, tx_skb->mapping,
>> + tx_skb->size, DMA_TO_DEVICE);
>> + }
>
> Please do not use curly braces for basic block composed of a single statement.
>
Hi David,
thanks for your review, I'll fix it in the next series of patch.
Regards,
Cyrille
^ permalink raw reply
* omap-wakeupgen.c: Remove function for fix me
From: Tony Lindgren @ 2014-07-23 7:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPDOMVinWFVKY=mMOA1f6pd4orOgcKh1kE01MPVaLZi0Z_tMmg@mail.gmail.com>
* Nick Krause <xerofoify@gmail.com> [140722 14:12]:
> static void __init irq_pm_init(void)
> 382 {
> 383 /* FIXME: Remove this when MPU OSWR support is added */
> 384 if (!soc_is_omap54xx())
> 385 cpu_pm_register_notifier(&irq_notifier_block);
> 386 }
> I am wondering is this omap supported now if it is can I remove it?
Does REVISIT cause issues for you with cscope? It may be easier to
replace the cscope bugging FIXME statements with just REVISIT unless
a real fix is provided.
Regards,
Tony
^ permalink raw reply
* [PATCH v2] cpufreq: tests: Providing cpufreq regression test
From: Lukasz Majewski @ 2014-07-23 7:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKohpondk7Cty8MhTcjyzZW8Z0o4AVupYE0rRnG4YJf+SmDyjg@mail.gmail.com>
Hi Viresh,
> Hi Lukasz,
>
> I haven't replied yet as I wanted to see what the general feed of
> Rafael is going to be :)
>
> As this is something new and wasn't sure if we really want this..
Do you want to say that we have enough tests and we don't need more ?
I always thought that we shall have as much regression tests as
possible.
>
> On 21 July 2014 12:32, Lukasz Majewski <l.majewski@samsung.com> wrote:
> > This commit adds first regression test "cpufreq_freq_test.sh" for
> > the cpufreq subsystem.
>
> That's not enough, Tell us why we should continue reading this mail..
Hmm... If "regression" and "test" don't catch the attention of a
diligent maintainer, then I cannot do much more to encourage him to
read the whole e-mail :-)
I can imagine that maintainers are very busy, therefore I've prepared
README file with detailed description of the script operation.
>
> > Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
> >
> > ---
> > Changes for v2:
> > - Replace *_PATCH with *_PATH for variables names
> > - Corrected mistakes in the README file
> > - Providing detailed explanation of the patch in the README file
> > ---
> > drivers/cpufreq/tests/README | 33 +++++++
> > drivers/cpufreq/tests/cpufreq_freq_test.sh | 149
> > +++++++++++++++++++++++++++++
>
> Probably a better place would be tools/power/cpufreq/
>
> @Rafael?
Rafael, I'm open for suggestions.
>
> > 2 files changed, 182 insertions(+)
> > create mode 100644 drivers/cpufreq/tests/README
> > create mode 100755 drivers/cpufreq/tests/cpufreq_freq_test.sh
> >
> > diff --git a/drivers/cpufreq/tests/README
> > b/drivers/cpufreq/tests/README new file mode 100644
> > index 0000000..3e9cd80
> > --- /dev/null
> > +++ b/drivers/cpufreq/tests/README
> > @@ -0,0 +1,33 @@
> > +This file contains list of cpufreq's available regression tests
> > with a short +usage description.
> > +
> > +1. cpufreq_freq_test.sh
> > +
> > +Description:
> > +------------
> > +This script is supposed to test if cpufreq attributes exported by
> > sysfs are +exposing correct values.
> > +
> > +To achieve this goal it saves the current governor and changes it
> > to +"performance". Afterwards, it reads the
> > "scaling_available_frequencies" +property. With the list of
> > supported frequencies it is able to enforce each of +them by
> > writing to "scaling_max_freq" attribute. To make the test more
> > reliable +a superfluous load with gzip is created to be sure that
> > we are running with +highest possible frequency. This high load is
> > regulated with the 'sleep' +duration. After this time the
> > "cpufreq_cur_freq" is read and compared with the +original value.
> > As the last step the original governor is restored.
>
> I couldn't make out the purpose of this test and why we need it. How
> do we ensure that "cpufreq attributes exported by sysfs are exposing
> correct values"?
First of all the cpufreq attributes are part of the subsystem API.
There are systems which actually depend on them, so we would be better
off to test if they work as intended.
Secondly, the test takes those values and then with use of other
attribute enforce the value, which is then read via cat'ing
cpufreq_cur_freq. If any of the attributes is wrong then we will spot
the error immediately.
>
> And actually what do we mean by this statement even? What kind of
> errors can be there in exposing these values.
Errors with cpufreq and CCF cooperation - especially when some parts of
cpufreq code uses direct write to MUX, DIV or PLL SoC registers.
Also, one can check if permutations of changing all available
frequencies are working properly.
This script allowed me to find at least two bugs at Exynos cpufreq
subsystem in the past. And those fixes are already applied to mainline.
>
> I want to understand the purpose of this script very clearly first
> and then only will look at the details.
There is a clean shell script code to go through it, the README file
with detailed description of the script purpose and operation.
What else shall I write?
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
^ 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