* [RFC PATCH] arm: vt8500: Convert irq.c for multiplatform integration
From: Arnd Bergmann @ 2012-10-10 18:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349891673.22215.2.camel@gitbox>
On Wednesday 10 October 2012, Tony Prisk wrote:
> I did have one bit I wasn't sure about:
>
> On Wed, 2012-10-10 at 21:08 +1300, Tony Prisk wrote:
> > This patch converts arch-vt8500/irq.c to MULTI_IRQ_HANDLER and
> > SPARSE_IRQ. IRQ domain is changed from legacy to linear.
> >
> > Also, remove legacy code in include/mach/entry-macro.S and
> > include/mach/irq.h to prepare for multiplatform.
> >
> > Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
> > ---
> > ...
> >
> > diff --git a/arch/arm/mach-vt8500/common.h b/arch/arm/mach-vt8500/common.h
> > index 2b24196..6f2b843 100644
> > --- a/arch/arm/mach-vt8500/common.h
> > +++ b/arch/arm/mach-vt8500/common.h
> > @@ -25,4 +25,7 @@ int __init vt8500_irq_init(struct device_node *node,
> > /* defined in drivers/clk/clk-vt8500.c */
> > void __init vtwm_clk_init(void __iomem *pmc_base);
> >
> > +/* defined in irq.c */
> > +asmlinkage void vt8500_handle_irq(struct pt_regs *regs);
>
> Should asmlinkage be used here in the header or is it unnecessary?
I think it's not technically needed because the function is not called
from C code anywhere, but IMHO it's better to have it here out of principle.
Arnd
^ permalink raw reply
* [PATCH 3.6.0- 0/6] ARM: use module_platform_driver macro
From: Paul Walmsley @ 2012-10-10 18:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349893796-6947-1-git-send-email-srinivas.kandagatla@st.com>
Hi
On Wed, 10 Oct 2012, Srinivas KANDAGATLA wrote:
> From: Srinivas Kandagatla <srinivas.kandagatla@st.com>
>
> Running below Coccinelle lookup pattern like below on the
> latest kernel showed about 52 hits. This patch series is a subset
> of those 52 patches, so that it will be easy for maintainers to review.
so the idea looks okay to me, but several of the patches aren't addressed
to the right people. You can use the MAINTAINERS file to figure out the
right place to send them.
The PXA patches need to go to the appropriate PXA people, who are
probably:
M: Eric Miao <eric.y.miao@gmail.com>
M: Russell King <linux@arm.linux.org.uk>
M: Haojian Zhuang <haojian.zhuang@gmail.com>
L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
The OMAP RNG patch needs to go to
M: Deepak Saxena <dsaxena@plexity.net>
M: Matt Mackall <mpm@selenic.com>
M: Herbert Xu <herbert@gondor.apana.org.au>
As far as the remaining three OMAP patches go, they look okay to me but
Tony Lindgren is the maintainer of these files and so he's the right
person to merge them.
> Hopefully these patches will get rid of some code duplication in kernel.
One other comment - the description on the patches isn't quite accurate.
The patches don't remove code duplication per se, they just replace some
boilerplate code with a macro.
- Paul
^ permalink raw reply
* [PATCH v2 00/14] KVM/ARM Implementation
From: Marcelo Tosatti @ 2012-10-10 18:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121001090945.49198.68950.stgit@ubuntu>
On Mon, Oct 01, 2012 at 05:09:59AM -0400, Christoffer Dall wrote:
> The following series implements KVM support for ARM processors,
> specifically on the Cortex A-15 platform. We feel this is ready to be
> merged.
>
> Work is done in collaboration between Columbia University, Virtual Open
> Systems and ARM/Linaro.
>
> The patch series applies to Linux 3.6 with a number of merges:
> 1. git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git
> branch: hyp-mode-boot-next (e5a04cb0b4a)
> 2. git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git
> branch: timers-next (437814c44c)
> 3. git://git.kernel.org/pub/scm/virt/kvm/kvm.git
> branch: next (1e08ec4a)
>
> This is Version 12 of the patch series, the first 10 versions were
> reviewed on the KVM/ARM and KVM mailing lists. Changes can also be
> pulled from:
> git://github.com/virtualopensystems/linux-kvm-arm.git
> branch: kvm-arm-v12
> branch: kvm-arm-v12-vgic
> branch: kvm-arm-v12-vgic-timers
>
> A non-flattened edition of the patch series, which can always be merged,
> can be found at:
> git://github.com/virtualopensystems/linux-kvm-arm.git kvm-arm-master
>
> This patch series requires QEMU compatibility. Use the branch
> git://github.com/virtualopensystems/qemu.git kvm-arm
>
> Following this patch series, which implements core KVM support are two
> other patch series implementing Virtual Generic Interrupt Controller
> (VGIC) support and Architected Generic Timers. All three patch series
> should be applied for full QEMU compatibility.
>
> The implementation is broken up into a logical set of patches, the first
> are preparatory patches:
> 1. ARM: Add page table defines for KVM
> 3. ARM: Section based HYP idmaps
> 3. ARM: Factor out cpuid implementor and part_number fields
>
> The main implementation is broken up into separate patches, the first
> containing a skeleton of files, makefile changes, the basic user space
> interface and KVM architecture specific stubs. Subsequent patches
> implement parts of the system as listed:
> 4. Skeleton and reset hooks
> 5. Hypervisor initialization
> 6. Memory virtualization setup (hyp mode mappings and 2nd stage)
> 7. Inject IRQs and FIQs from userspace
> 8. World-switch implementation and Hyp exception vectors
> 9. Emulation framework and coproc emulation
> 10. Coproc user space API
> 11. Demux multiplexed coproc registers
> 12. User spac API to get/set VFP registers
> 13. Handle guest user memory aborts
> 14. Handle guest MMIO aborts
>
> Testing:
> Tested on FAST Models and Versatile Express test-chip2. Tested by
> running three simultaenous VMs, all running SMP, on an SMP host, each
> VM running hackbench and cyclictest and with extreme memory pressure
> applied to the host with swapping enabled to provoke page eviction.
> Also tested KSM merging and GCC inside VMs. Fully boots both Ubuntu
> (user space Thumb-2) and Debian (user space ARM) guests.
>
> For a guide on how to set up a testing environment and try out these
> patches, see:
> http://www.virtualopensystems.com/media/pdf/kvm-arm-guide.pdf
>
> Changes since v11:
> - Memory setup and page table defines reworked
> - We do not export unused perf bitfields anymore
> - No module support anymore and following cleanup
> - Hide vcpu register accessors
> - Fix unmap range mmu notifier race condition
> - Factored out A15 coprocs in separate file
> - Factored out world-switch assembly macros to separate file
> - Add dmux of multiplexed coprocs to user space
> - Add VFP get/set interface to user space
> - Addressed various cleanup comments from reviewers
>
> Changes since v10:
> - Boot in Hyp mode and user HVC to initialize HVBAR
> - Support VGIC
> - Support Arch timers
> - Support Thumb-2 mmio instruction decoding
> - Transition to GET_ONE/SET_ONE register API
> - Added KVM_VCPU_GET_REG_LIST
> - New interrupt injection API
> - Don't pin guest pages anymore
> - Fix race condition in page fault handler
> - Cleanup guest instruction copying.
> - Fix race when copying SMP guest instructions
> - Inject data/prefetch aborts when guest does something strange
>
> Changes since v9:
> - Addressed reviewer comments (see mailing list archive)
> - Limit the user of .arch_extensiion sec/virt for compilers that need them
> - VFP/Neon Support (Antonios Motakis)
> - Run exit handling under preemption and still handle guest cache ops
> - Add support for IO mapping at Hyp level (VGIC prep)
> - Add support for IO mapping at Guest level (VGIC prep)
> - Remove backdoor call to irq_svc
> - Complete rework of CP15 handling and register reset (Rusty Russell)
> - Don't use HSTR for anything else than CR 15
> - New ioctl to set emulation target core (only A15 supported for now)
> - Support KVM_GET_MSRS / KVM_SET_MSRS
> - Add page accounting and page table eviction
> - Change pgd lock to spinlock and fix sleeping in atomic bugs
> - Check kvm_condition_valid for HVC traps of undefs
> - Added a naive implementation of kvm_unmap_hva_range
>
> Changes since v8:
> - Support cache maintenance on SMP through set/way
> - Hyp mode idmaps are now section based and happen at kernel init
> - Handle aborts in Hyp mode
> - Inject undefined exceptions into the guest on error
> - Kernel-side reset of all crucial registers
> - Specifically state which target CPU is being virtualized
> - Exit statistics in debugfs
> - Some L2CTLR cp15 emulation cleanups
> - Support spte_hva for MMU notifiers and take write faults
> - FIX: Race condition in VMID generation
> - BUG: Run exit handling code with disabled preemption
> - Save/Restore abort fault register during world switch
>
> Changes since v7:
> - Traps accesses to ACTLR
> - Do not trap WFE execution
> - Upgrade barriers and TLB operations to inner-shareable domain
> - Restrucure hyp_pgd related code to be more opaque
> - Random SMP fixes
> - Random BUG fixes
> - Improve commenting
> - Support module loading/unloading of KVM/ARM
> - Thumb-2 support for host kernel and KVM
> - Unaligned cross-page wide guest Thumb instruction fetching
> - Support ITSTATE fields in CPSR for Thumb guests
> - Document HCR settings
>
> Changes since v6:
> - Support for MMU notifiers to not pin user pages in memory
> - Suport build with log debugging
> - Bugfix: v6 clobbered r7 in init code
> - Simplify hyp code mapping
> - Cleanup of register access code
> - Table-based CP15 emulation from Rusty Russell
> - Various other bug fixes and cleanups
>
> Changes since v5:
> - General bugfixes and nit fixes from reviews
> - Implemented re-use of VMIDs
> - Cleaned up the Hyp-mapping code to be readable by non-mm hackers
> (including myself)
> - Integrated preliminary SMP support in base patches
> - Lock-less interrupt injection and WFI support
> - Fixed signal-handling in while in guest (increases overall stability)
>
> Changes since v4:
> - Addressed reviewer comments from v4
> * cleanup debug and trace code
> * remove printks
> * fixup kvm_arch_vcpu_ioctl_run
> * add trace details to mmio emulation
> - Fix from Marc Zyngier: Move kvm_guest_enter/exit into non-preemptible
> section (squashed into world-switch patch)
> - Cleanup create_hyp_mappings/remove_hyp_mappings from Marc Zyngier
> (squashed into hypervisor initialization patch)
> - Removed the remove_hyp_mappings feature. Removing hypervisor mappings
> could potentially unmap other important data shared in the same page.
> - Removed the arm_ prefix from the arch-specific files.
> - Initial SMP host/guest support
>
> Changes since v3:
> - v4 actually works, fully boots a guest
> - Support compiling as a module
> - Use static inlines instead of macros for vcpu_reg and friends
> - Optimize kvm_vcpu_reg function
> - Use Ftrace for trace capabilities
> - Updated documentation and commenting
> - Use KVM_IRQ_LINE instead of KVM_INTERRUPT
> - Emulates load/store instructions not supported through HSR
> syndrome information.
> - Frees 2nd stage translation tables on VM teardown
> - Handles IRQ/FIQ instructions
> - Handles more CP15 accesses
> - Support guest WFI calls
> - Uses debugfs instead of /proc
> - Support compiling in Thumb mode
>
> Changes since v2:
> - Performs world-switch code
> - Maps guest memory using 2nd stage translation
> - Emulates co-processor 15 instructions
> - Forwards I/O faults to QEMU.
>
> ---
>
> Christoffer Dall (13):
> ARM: Add page table and page defines needed by KVM
> ARM: Section based HYP idmap
> ARM: Factor out cpuid implementor and part number
> KVM: ARM: Initial skeleton to compile KVM support
> KVM: ARM: Hypervisor inititalization
> KVM: ARM: Memory virtualization setup
> KVM: ARM: Inject IRQs and FIQs from userspace
> KVM: ARM: World-switch implementation
> KVM: ARM: Emulation framework and CP15 emulation
> KVM: ARM: User space API for getting/setting co-proc registers
> KVM: ARM: Demux CCSIDR in the userspace API
> KVM: ARM: Handle guest faults in KVM
> KVM: ARM: Handle I/O aborts
>
> Rusty Russell (1):
> KVM: ARM: VFP userspace interface
>
>
> Documentation/virtual/kvm/api.txt | 133 +++
> arch/arm/Kconfig | 2
> arch/arm/Makefile | 1
> arch/arm/include/asm/cputype.h | 26 +
> arch/arm/include/asm/idmap.h | 5
> arch/arm/include/asm/kvm.h | 131 +++
> arch/arm/include/asm/kvm_arm.h | 191 +++++
> arch/arm/include/asm/kvm_asm.h | 84 ++
> arch/arm/include/asm/kvm_coproc.h | 47 +
> arch/arm/include/asm/kvm_emulate.h | 90 ++
> arch/arm/include/asm/kvm_host.h | 154 ++++
> arch/arm/include/asm/kvm_mmu.h | 49 +
> arch/arm/include/asm/pgtable-3level-hwdef.h | 5
> arch/arm/include/asm/pgtable-3level.h | 18
> arch/arm/include/asm/pgtable.h | 7
> arch/arm/kernel/asm-offsets.c | 24 +
> arch/arm/kernel/perf_event.c | 30 -
> arch/arm/kernel/vmlinux.lds.S | 6
> arch/arm/kvm/Kconfig | 45 +
> arch/arm/kvm/Makefile | 22 +
> arch/arm/kvm/arm.c | 964 +++++++++++++++++++++++++
> arch/arm/kvm/coproc.c | 1045 +++++++++++++++++++++++++++
> arch/arm/kvm/coproc.h | 153 ++++
> arch/arm/kvm/coproc_a15.c | 164 ++++
> arch/arm/kvm/emulate.c | 847 ++++++++++++++++++++++
> arch/arm/kvm/guest.c | 222 ++++++
> arch/arm/kvm/init.S | 126 +++
> arch/arm/kvm/interrupts.S | 537 ++++++++++++++
> arch/arm/kvm/interrupts_head.S | 293 ++++++++
> arch/arm/kvm/mmu.c | 1013 ++++++++++++++++++++++++++
> arch/arm/kvm/reset.c | 74 ++
> arch/arm/kvm/trace.h | 217 ++++++
> arch/arm/mm/idmap.c | 74 ++
> arch/arm/mm/mmu.c | 25 +
> include/linux/kvm.h | 3
> mm/memory.c | 2
> 36 files changed, 6793 insertions(+), 36 deletions(-)
> create mode 100644 arch/arm/include/asm/kvm.h
> create mode 100644 arch/arm/include/asm/kvm_arm.h
> create mode 100644 arch/arm/include/asm/kvm_asm.h
> create mode 100644 arch/arm/include/asm/kvm_coproc.h
> create mode 100644 arch/arm/include/asm/kvm_emulate.h
> create mode 100644 arch/arm/include/asm/kvm_host.h
> create mode 100644 arch/arm/include/asm/kvm_mmu.h
> create mode 100644 arch/arm/kvm/Kconfig
> create mode 100644 arch/arm/kvm/Makefile
> create mode 100644 arch/arm/kvm/arm.c
> create mode 100644 arch/arm/kvm/coproc.c
> create mode 100644 arch/arm/kvm/coproc.h
> create mode 100644 arch/arm/kvm/coproc_a15.c
> create mode 100644 arch/arm/kvm/emulate.c
> create mode 100644 arch/arm/kvm/guest.c
> create mode 100644 arch/arm/kvm/init.S
> create mode 100644 arch/arm/kvm/interrupts.S
> create mode 100644 arch/arm/kvm/interrupts_head.S
> create mode 100644 arch/arm/kvm/mmu.c
> create mode 100644 arch/arm/kvm/reset.c
> create mode 100644 arch/arm/kvm/trace.h
> --
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Reviewed-by: Marcelo Tosatti <mtosatti@redhat.com>
^ permalink raw reply
* [PATCH 3/6] ARM: ux500: Add support for ST-Ericsson's u9540 SoC
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-10-10 19:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349882335-6786-4-git-send-email-lee.jones@linaro.org>
On 16:18 Wed 10 Oct , Lee Jones wrote:
> First level board support for the u9540.
>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
> arch/arm/mach-ux500/cpu-db8500.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/arch/arm/mach-ux500/cpu-db8500.c b/arch/arm/mach-ux500/cpu-db8500.c
> index 3d8e321..6b7f970 100644
> --- a/arch/arm/mach-ux500/cpu-db8500.c
> +++ b/arch/arm/mach-ux500/cpu-db8500.c
> @@ -17,6 +17,7 @@
> #include <linux/platform_device.h>
> #include <linux/io.h>
> #include <linux/mfd/abx500/ab8500.h>
> +#include <linux/mfd/dbx500-prcmu.h>
> #include <linux/of.h>
> #include <linux/of_platform.h>
> #include <linux/regulator/machine.h>
> @@ -319,6 +320,8 @@ static void __init u8500_init_machine(void)
> snowball_pinmaps_init();
> else if (of_machine_is_compatible("st-ericsson,hrefv60+"))
> hrefv60_pinmaps_init();
> + else if (of_machine_is_compatible("st-ericsson,u9540")) {}
> + /* TODO: Add u9540 pinmaps. */
do you via DT no here
>
> /* TODO: Export SoC, USB, cpu-freq and DMA40 */
> parent = u8500_of_init_devices();
> @@ -331,6 +334,7 @@ static const char * u8500_dt_board_compat[] = {
> "calaosystems,snowball-a9500",
> "st-ericsson,hrefv60+",
> "st-ericsson,mop500",
> + "st-ericsson,u9540",
stop to add more compatible sue a more generic one
> NULL,
> };
>
> @@ -345,4 +349,14 @@ DT_MACHINE_START(U8500_DT, "ST-Ericsson U8500 platform (Device Tree Support)")
> .dt_compat = u8500_dt_board_compat,
> MACHINE_END
>
> +DT_MACHINE_START(U9540_DT, "ST-Ericsson 9540 platform (Device Tree Support)")
> + .map_io = u8500_map_io,
> + .init_irq = ux500_init_irq,
> + .timer = &ux500_timer,
> + .handle_irq = gic_handle_irq,
> + .init_machine = u8500_init_machine,
> + .init_late = NULL,
> + .dt_compat = u8500_dt_board_compat,
> +MACHINE_END
really?
no need drop it for a more generic on
Best Regards,
J.
^ permalink raw reply
* [PATCH 4/6] ARM: ux500: Add UART support to the u9540 Device Tree
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-10-10 19:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349882335-6786-5-git-send-email-lee.jones@linaro.org>
On 16:18 Wed 10 Oct , Lee Jones wrote:
> Add the 3 UART nodes required to enable serial ports on the u9540.
>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
> arch/arm/boot/dts/u9540.dts | 13 ++++++++++++-
dts? it's dtsi
it's the soc not the board
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/u9540.dts b/arch/arm/boot/dts/u9540.dts
> index 0a66f34..28efe20 100644
> --- a/arch/arm/boot/dts/u9540.dts
> +++ b/arch/arm/boot/dts/u9540.dts
> @@ -21,6 +21,17 @@
> };
>
> soc-u9500 {
> - };
>
> + uart at 80120000 {
> + status = "okay";
> + };
> +
> + uart at 80121000 {
> + status = "okay";
> + };
> +
> + uart at 80007000 {
> + status = "okay";
> + };
do not enable device by default in the soc
Best Regards,
J.
> + };
> };
> --
> 1.7.9.5
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 5/6] ARM: ux500: Enable SDI4 port on the u9540 when booting with Device Tree
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-10-10 19:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349882335-6786-6-git-send-email-lee.jones@linaro.org>
On 16:18 Wed 10 Oct , Lee Jones wrote:
> Here we add the device node for the SDI4 (MMC) port to the u9540
> Device Tree source file. This will allow successful probing of
> the internal MMC storage device when booting with DT enabled.
>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
> arch/arm/boot/dts/u9540.dts | 12 +++++++++++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/u9540.dts b/arch/arm/boot/dts/u9540.dts
> index 28efe20..2dade76 100644
> --- a/arch/arm/boot/dts/u9540.dts
> +++ b/arch/arm/boot/dts/u9540.dts
> @@ -21,7 +21,6 @@
> };
>
> soc-u9500 {
> -
why?
> uart at 80120000 {
> status = "okay";
> };
> @@ -33,5 +32,16 @@
> uart at 80007000 {
> status = "okay";
> };
> +
> + // On-board eMMC
no c++ comment
> + sdi4_per2 at 80114000 {
> + arm,primecell-periphid = <0x10480180>;
> + max-frequency = <50000000>;
> + bus-width = <8>;
> + mmc-cap-mmc-highspeed;
> + vmmc-supply = <&ab8500_ldo_aux2_reg>;
you need add the pinctrl here
Best Regards,
J.
^ permalink raw reply
* [PATCH v6] Enable USB peripheral mode on dm365 EVM
From: Sergei Shtylyov @ 2012-10-10 19:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349872412-22040-1-git-send-email-const@MakeLinux.com>
Hello.
On 10-10-2012 14:33, Constantine Shulyupin wrote:
> From: Constantine Shulyupin <const@MakeLinux.com>
>
> Sets USB PHY clock source to 24 MHz clock and call USB configuration from board initialization.
>
> Tested with OTG configuration, usb gadget g_zero on DM365 EVM connected to PC.
>
> References:
>
> Definition of USB_PHY_CTRL and PHYCLKFREQ:
> - http://www.makelinux.com/lib/ti/DM36x_ARM/doc-141
>
> Original patch by miguel.aguilar at ridgerun.com three years ago:
> - http://www.mail-archive.com/davinci-linux-open-source at linux.davincidsp.com/msg14741.html
>
> Signed-off-by: Constantine Shulyupin <const@MakeLinux.com>
> ---
>
> Note:
>
> Changelog
>
> Changes since v5 http://www.spinics.net/lists/kernel/msg1413120.html
> accordingy feedback of nsekhar at ti.com http://www.spinics.net/lists/kernel/msg1414914.html
> - phy configuration moved to drivers/usb/musb/davinci.c
> - USB_OTG configuration is submitted in separated patch: http://www.spinics.net/lists/kernel/msg1414964.html
> - Setting current limit to 1000 mA. Any way the current is limited to 510 mA in davinci_setup_usb.
>
> Changes since v4 http://www.spinics.net/lists/kernel/msg1412995.html
> - removed fix of dev_info in musb_init_controller
>
> Changes since v3 http://www.spinics.net/lists/kernel/msg1412544.html:
> - removed optional altering of pr_info
>
> Changes since v1 http://marc.info/?l=linux-kernel&m=130894150803661&w=2:
> - removed optional code and reordered
> - removed alternation of GPIO33, which is multiplexed with DRVVBUS, because is not need for peripheral USB
>
> This patch is based on code from projects Arago, Angstom and RidgeRun.
>
> ---
> arch/arm/mach-davinci/board-dm365-evm.c | 2 ++
> drivers/usb/musb/davinci.c | 3 +++
> drivers/usb/musb/davinci.h | 1 +
> 3 files changed, 6 insertions(+)
>
> diff --git a/arch/arm/mach-davinci/board-dm365-evm.c b/arch/arm/mach-davinci/board-dm365-evm.c
> index 688a9c5..ba5ffc1 100644
> --- a/arch/arm/mach-davinci/board-dm365-evm.c
> +++ b/arch/arm/mach-davinci/board-dm365-evm.c
> @@ -38,6 +38,7 @@
> #include <mach/mmc.h>
> #include <mach/nand.h>
> #include <mach/keyscan.h>
> +#include <mach/usb.h>
>
> #include <media/tvp514x.h>
>
> @@ -610,6 +611,7 @@ static __init void dm365_evm_init(void)
>
> dm365_init_spi0(BIT(0), dm365_evm_spi_info,
> ARRAY_SIZE(dm365_evm_spi_info));
> + davinci_setup_usb(1000, 8);
> }
>
> MACHINE_START(DAVINCI_DM365_EVM, "DaVinci DM365 EVM")
You need to split the patch at this point. Above part should be
applied to the DaVinci tree, below part to the MUSB tree.
> diff --git a/drivers/usb/musb/davinci.c b/drivers/usb/musb/davinci.c
> index 472c8b4..af09ebf 100644
> --- a/drivers/usb/musb/davinci.c
> +++ b/drivers/usb/musb/davinci.c
> @@ -428,6 +428,9 @@ static int davinci_musb_init(struct musb *musb)
> __raw_writel(deepsleep, DM355_DEEPSLEEP);
> }
>
> + if (machine_is_davinci_dm365_evm())
> + writel(readl(USB_PHY_CTRL) | USBPHY_CLKFREQ_24MHZ, USB_PHY_CTRL);
I'd put that to the board file instead, like in board-da830-evm.c....
WBR, Sergei
^ permalink raw reply
* [PATCH v6] Enable USB peripheral mode on dm365 EVM
From: Constantine Shulyupin @ 2012-10-10 19:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5075CC15.3040809@mvista.com>
Sekhar Nori: Looks like all PHY related configuration is currently happening in
drivers/usb/musb/davinci.c and the same register is also being written
to for other platforms. Can you move the code you have included in board
file to the driver? As we move towards DT, we need to avoid register
configurations from board files anyway.
>From http://www.spinics.net/lists/kernel/msg1414914.html
On Wed, Oct 10, 2012 at 9:27 PM, Sergei Shtylyov <sshtylyov@mvista.com> wrote:
> Hello.
>
>
> On 10-10-2012 14:33, Constantine Shulyupin wrote:
>
>> From: Constantine Shulyupin <const@MakeLinux.com>
>>
>> Sets USB PHY clock source to 24 MHz clock and call USB configuration from
>> board initialization.
>>
>> Tested with OTG configuration, usb gadget g_zero on DM365 EVM connected to
>> PC.
>>
>> References:
>>
>> Definition of USB_PHY_CTRL and PHYCLKFREQ:
>> - http://www.makelinux.com/lib/ti/DM36x_ARM/doc-141
>>
>> Original patch by miguel.aguilar at ridgerun.com three years ago:
>> -
>> http://www.mail-archive.com/davinci-linux-open-source at linux.davincidsp.com/msg14741.html
>>
>> Signed-off-by: Constantine Shulyupin <const@MakeLinux.com>
>> ---
>>
>> Note:
>>
>> Changelog
>>
>> Changes since v5 http://www.spinics.net/lists/kernel/msg1413120.html
>> accordingy feedback of nsekhar at ti.com
>> http://www.spinics.net/lists/kernel/msg1414914.html
>> - phy configuration moved to drivers/usb/musb/davinci.c
>> - USB_OTG configuration is submitted in separated patch:
>> http://www.spinics.net/lists/kernel/msg1414964.html
>> - Setting current limit to 1000 mA. Any way the current is limited to 510
>> mA in davinci_setup_usb.
>>
>> Changes since v4 http://www.spinics.net/lists/kernel/msg1412995.html
>> - removed fix of dev_info in musb_init_controller
>>
>> Changes since v3 http://www.spinics.net/lists/kernel/msg1412544.html:
>> - removed optional altering of pr_info
>>
>> Changes since v1 http://marc.info/?l=linux-kernel&m=130894150803661&w=2:
>> - removed optional code and reordered
>> - removed alternation of GPIO33, which is multiplexed with DRVVBUS,
>> because is not need for peripheral USB
>>
>> This patch is based on code from projects Arago, Angstom and RidgeRun.
>>
>> ---
>> arch/arm/mach-davinci/board-dm365-evm.c | 2 ++
>> drivers/usb/musb/davinci.c | 3 +++
>> drivers/usb/musb/davinci.h | 1 +
>> 3 files changed, 6 insertions(+)
>>
>> diff --git a/arch/arm/mach-davinci/board-dm365-evm.c
>> b/arch/arm/mach-davinci/board-dm365-evm.c
>> index 688a9c5..ba5ffc1 100644
>> --- a/arch/arm/mach-davinci/board-dm365-evm.c
>> +++ b/arch/arm/mach-davinci/board-dm365-evm.c
>> @@ -38,6 +38,7 @@
>> #include <mach/mmc.h>
>> #include <mach/nand.h>
>> #include <mach/keyscan.h>
>> +#include <mach/usb.h>
>> #include <media/tvp514x.h>
>> @@ -610,6 +611,7 @@ static __init void dm365_evm_init(void)
>> dm365_init_spi0(BIT(0), dm365_evm_spi_info,
>> ARRAY_SIZE(dm365_evm_spi_info));
>> + davinci_setup_usb(1000, 8);
>> }
>> MACHINE_START(DAVINCI_DM365_EVM, "DaVinci DM365 EVM")
>
>
> You need to split the patch at this point. Above part should be applied
> to the DaVinci tree, below part to the MUSB tree.
>
>
>> diff --git a/drivers/usb/musb/davinci.c b/drivers/usb/musb/davinci.c
>> index 472c8b4..af09ebf 100644
>> --- a/drivers/usb/musb/davinci.c
>> +++ b/drivers/usb/musb/davinci.c
>> @@ -428,6 +428,9 @@ static int davinci_musb_init(struct musb *musb)
>> __raw_writel(deepsleep, DM355_DEEPSLEEP);
>> }
>> + if (machine_is_davinci_dm365_evm())
>> + writel(readl(USB_PHY_CTRL) | USBPHY_CLKFREQ_24MHZ,
>> USB_PHY_CTRL);
>
>
> I'd put that to the board file instead, like in board-da830-evm.c....
>
> WBR, Sergei
>
--
Constantine Shulyupin
http://www.MakeLinux.com/
Embedded Linux Systems,
Device Drivers, TI DaVinci
^ permalink raw reply
* [PATCH 09/11] fsmc/nand:FIX: replace change_bit routine
From: Nicolas Pitre @ 2012-10-10 20:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdaot3DKCoJOBpUcJFVrJ89xRx2T58fDe4YKY_r4NFqEag@mail.gmail.com>
On Wed, 10 Oct 2012, Linus Walleij wrote:
> On Tue, Oct 9, 2012 at 12:44 PM, Vipin Kumar <vipin.kumar@st.com> wrote:
>
> > change_bit routine accepts only ulong pointers as buffer, so an unaligned char
> > pointer passed to change_bit may lead to a crash.
> >
> > Fix this bug by accessing the buffer as char pointer.
>
> Why not see if we can fix change_bit() instead?
> Since I suspect this is on ARM I bet Russell and Nico
> want to hear about this if there is a problem.
>
> Can the ARM change_bit() not be fixed, so that
> long arguments are the only option?
No. It is this code which is totally broken.
The change_bit() is defined to operate on long values, in the _native_
endian. Now imagine what this is going to do to your data buffer if
instead you are running on a big endian device.
And I doubt there is anything requiring atomic bit manipulation here
either.
> > if (err_idx[i] < chip->ecc.size * 8) {
> > - change_bit(err_idx[i], (unsigned long *)dat);
> > + uint8_t *p = dat + err_idx[i] / 8;
> > + *p = *p ^ (1 << (err_idx[i] % 8));
>
> I'm one of these people who would write >>3 and
> &7 rather than /8 or %8 but I guess we are all
> different. Atleast consider it if you stick with this...
Better yet:
dat[err_idx[i] / 8] ^= (1 << (err_idx[i] % 8));
The /8 and %8 will be changed into >>3 and &7 by the compiler anyway,
while the /8 and %8 form is possibly a bit less obscure.
Of course, this needs to be done over _all_ this driver, not only a few
cases.
Nicolas
^ permalink raw reply
* [PATCH 09/11] fsmc/nand:FIX: replace change_bit routine
From: Russell King - ARM Linux @ 2012-10-10 20:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdaot3DKCoJOBpUcJFVrJ89xRx2T58fDe4YKY_r4NFqEag@mail.gmail.com>
On Wed, Oct 10, 2012 at 07:22:04PM +0200, Linus Walleij wrote:
> On Tue, Oct 9, 2012 at 12:44 PM, Vipin Kumar <vipin.kumar@st.com> wrote:
>
> > change_bit routine accepts only ulong pointers as buffer, so an unaligned char
> > pointer passed to change_bit may lead to a crash.
> >
> > Fix this bug by accessing the buffer as char pointer.
>
> Why not see if we can fix change_bit() instead?
> Since I suspect this is on ARM I bet Russell and Nico
> want to hear about this if there is a problem.
Not particularly. There's a reason the argument to change_bit() is typed
'unsigned long' and that's not because it can take a void, char, or a
short. It's because it _expects_ the buffer to be aligned to an
"unsigned long" quantity.
That's because on many architectures, misaligned loads and stores are
not atomic operations - and in this case, load/store exclusive will
fail when they're misalighed.
So...
- change_bit(err_idx[i], (unsigned long *)dat);
is highly invalid code.
> Can the ARM change_bit() not be fixed, so that
> long arguments are the only option?
Spot the intentional cast:
> > - change_bit(err_idx[i], (unsigned long *)dat);
which tries to work around this. Remember my attitude towards casts:
if you're having to use a cast, you are _probably_ doing something
wrong. In this case, it's hiding a warning which was saying that
the code is doing something wrong, and then the result blows up.
By adding that cast, the wrong wire was cut... you get to keep the
remains. ;)
^ permalink raw reply
* [PATCH] ARM: tegra: rename the file of "sleep-tXX" to "sleep-tegraXX"
From: Olof Johansson @ 2012-10-10 20:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349691837-30488-1-git-send-email-josephl@nvidia.com>
On Mon, Oct 8, 2012 at 3:23 AM, Joseph Lo <josephl@nvidia.com> wrote:
> For the naming consistency under the mach-tegra, we re-name the file of
> "sleep-tXX" to "sleep-tegraXX" (e.g., sleep-t30 to sleep-tegra30).
>
> Signed-off-by: Joseph Lo <josephl@nvidia.com>
Why rename? It's just churn.
-Olof
^ permalink raw reply
* [PATCH] ARM: tegra: rename the file of "sleep-tXX" to "sleep-tegraXX"
From: Stephen Warren @ 2012-10-10 21:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMhnYZmEZPdpBDmQ+JYxgZRDXZ97O3Wizy91DwxHZFGWpw@mail.gmail.com>
On 10/10/2012 02:54 PM, Olof Johansson wrote:
> On Mon, Oct 8, 2012 at 3:23 AM, Joseph Lo <josephl@nvidia.com> wrote:
>> For the naming consistency under the mach-tegra, we re-name the file of
>> "sleep-tXX" to "sleep-tegraXX" (e.g., sleep-t30 to sleep-tegra30).
>>
>> Signed-off-by: Joseph Lo <josephl@nvidia.com>
>
> Why rename? It's just churn.
The CPUs are named TegraNN not TNN, so for consistency the files should
be named that way. This is almost the last instance; everything else got
renamed as a side-effect of adding splitting things up for Tegra30
support. Oh, except tegra2_emc.c which can be renamed whenever it's
moved to an appropriate drivers/ directory.
^ permalink raw reply
* [GIT PULL] ARM: SoC fixes
From: Olof Johansson @ 2012-10-10 21:48 UTC (permalink / raw)
To: linux-arm-kernel
Hi Linus,
The following changes since commit 0e51793e162ca432fc5f04178cf82b80a92c2659:
Merge branch 'for-linus' of git://git.linaro.org/people/rmk/linux-arm (2012-10-07 21:20:57 +0900)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/fixes
for you to fetch changes up to 6bd5dbda2adeabba69c969886511e501a65b6e3c:
Merge tag 'omap-for-v3.7-rc1/fixes-asoc-regression-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes (2012-10-09 15:00:58 -0700)
----------------------------------------------------------------
ARM: SoC fixes
A series of fixes (and in some cases, some cleanups):
Via Tony Lindgren:
- A collection of OMAP regression fixes, in particular because firmware
no longer sets up all pin states before starting the kernel.
- cpufreq fixes for OMAP (Rafael is on vacation and this was pre-agreed).
- A longer series of misc regression fixes and cleanups, warning removals,
etc for OMAP
>From Arnd Bergmann:
- A series of warning fixes for various platforms (defconfig builds)
Misc:
- A couple of tegra fixes, one for i.MX, some vt8500 fixes, etc.
----------------------------------------------------------------
Afzal Mohammed (1):
ARM: OMAP2+: gpmc: annotate exit sections properly
Arnd Bergmann (22):
ARM: shark: fix shark_pci_init return code
ARM: pxa: Wunused-result warning in viper board file
ARM: pxa: define palmte2_pxa_keys conditionally
ARM: pxa: remove sharpsl_fatal_check function
ARM: pxa: work around duplicate definition of GPIO24_SSP1_SFRM
ARM: at91: skip at91_io_desc definition for NOMMU
ARM: at91: unused variable in at91_pm_verify_clocks
ARM: s3c24xx: fix multiple section mismatch warnings
ARM: mv78xx0: mark mv78xx0_timer_init as __init_refok
ARM: iop13xx: mark iop13xx_scan_bus as __devinit
ARM: iop13xx: fix iq81340sc_atux_map_irq prototype
ARM: davinci: don't mark da850_register_cpufreq as __init
ARM: rpc: check device_register return code in ecard_probe
ARM: ks8695: __arch_virt_to_dma type handling
ARM: soc: dependency warnings for errata
ARM: footbridge: remove RTC_IRQ definition
ARM: mv78xx0: correct addr_map_cfg __initdata annotation
ARM: footbridge: nw_gpio_lock is raw_spin_lock
ARM: shmobile: mark shmobile_init_late as __init
ARM: assabet: fix bogus warning in get_assabet_scr (again)
ARM: integrator: use __iomem pointers for MMIO, part 2
ARM: pxa: armcore: fix PCI PIO warnings
Axel Lin (1):
ARM: OMAP: OMAP_DEBUG_LEDS needs to select LEDS_CLASS
Colin Cross (1):
ARM: OMAP: counter: add locking to read_persistent_clock
Jean Pihet (2):
ARM: OMAP: SmartReflex: select CONFIG_POWER_SUPPLY in Kconfig
ARM: OMAP: SmartReflex: fix error path in init function
Jon Hunter (2):
ARM: OMAP2+: hwmod data: Fix PMU interrupt definitions
ARM: OMAP3: fix workaround for EMU clockdomain
Kevin Hilman (4):
cpufreq: OMAP: ensure valid clock rate before scaling
cpufreq: OMAP: remove unused <plat/omap-pm.h>
cpufreq: OMAP: use get_cpu_device() instead of omap_device API
ARM: OMAP2+: PM: MPU DVFS: use generic CPU device for MPU-SS
Olof Johansson (10):
ARM: iop: fix mismerge of Kconfig
ARM: tegra: fix mismerges of header file inclusions
Merge branch 'late/fixes' into fixes
ARM: integrator_cp: fix build failure
Merge branch 'fixes2' into fixes
Merge tag 'omap-for-v3.7-rc1/fixes-signed' of git://git.kernel.org/.../tmlind/linux-omap into fixes
Merge tag 'omap-for-v3.7-rc1/fixes-hwmod-clock-signed-v3' of git://git.kernel.org/.../tmlind/linux-omap into fixes
Merge tag 'omap-for-v3.7-rc1/fixes-pm-signed' of git://git.kernel.org/.../tmlind/linux-omap into fixes
Merge tag 'omap-for-v3.7-rc1/fixes-cpufreq-signed' of git://git.kernel.org/.../tmlind/linux-omap into fixes
Merge tag 'omap-for-v3.7-rc1/fixes-asoc-regression-signed' of git://git.kernel.org/.../tmlind/linux-omap into fixes
Paul Walmsley (3):
ARM: OMAP: omap3evm: fix new sparse warning
cpufreq: OMAP: fix clock usage to be SoC independent, remove plat/ includes
ARM: OMAP4/AM335x: hwmod: fix disable_module regression in hardreset handling
Peter Senna Tschudin (3):
arch/arm/mach-omap1/devices.c: Remove unecessary semicolon
arch/arm/mach-omap2: Remove unecessary semicolon
arch/arm/plat-omap/omap-pm-noop.c: Remove unecessary semicolon
Peter Ujfalusi (9):
ARM: OMAP: board-4430-sdp: Pin mux configuration for audio needs
ARM: OMAP: board-omap4panda: Pin mux configuration for audio needs
ARM/dts: omap4-panda: Disable unused audio IPs
ARM/dts: omap4-sdp: Disable unused McBSP3
ARM/dts: omap5-evm: Disable unused McBSP3
ARM/dts: omap4-sdp: pinmux configuration for audio
ARM/dts: omap4-panda: pinmux configuration for audio
ARM/dts: Add pinctrl driver entries for omap5
ARM/dts: omap5-evm: pinmux configuration for audio
R Sricharan (1):
ARM: OMAP2+: Round of the carve out memory requested to section_size
Raphael Assenat (1):
AM35xx: Add missing hwmod entry for the HDQ/1-Wire present in AM3505/3517 CPUs.
Shawn Guo (1):
ARM: dts: remove redundant imx dtb targets from Makefile
Shubhrajyoti D (1):
ARM: OMAP: rx51: Fix a section mismatch warn
Stephen Warren (3):
ARM: tegra: fix invalid unit-address in tegra*.dtsi
ARM: tegra: remove "Tegra board type" comment from Kconfig
ARM: bcm2835: fix typos in DT binding documentation
Tony Lindgren (3):
Merge tag 'for_3.7-fixes-cpufreq' of git://git.kernel.org/.../khilman/linux-omap-pm into omap-for-v3.7-rc1/fixes-cpufreq
Merge tag 'for_3.7-fixes-pm' of git://git.kernel.org/.../khilman/linux-omap-pm into omap-for-v3.7-rc1/fixes-pm
Merge tag 'omap-fixes-a-for-pre3.7' of git://git.kernel.org/.../pjw/omap-pending into omap-for-v3.7-rc1/fixes-hwmod-clock
Tony Prisk (3):
dtb: Add arch-vt8500 board files to arch/arm/boot/dts/Makefile
vt8500: Fix build warning when no framebuffer selected
arm: vt8500: Fix build warning in uncompress.h
Vaibhav Hiremath (2):
ARM: am33xx: clk: Update clkdev table to add mcasp alias
ARM: OMAP2+: Add am335x evm and bone targets to common Makefile
Vikram Narayanan (1):
arm/omap: Replace board_ref_clock with enum values
Wei Yongjun (8):
ARM: OMAP: fix return value check in beagle_opp_init()
ARM: OMAP: omap_device: fix return value check in omap_device_build_ss()
ARM: OMAP2+: SmartReflex: fix return value check in sr_dev_init()
ARM: OMAP2+: PM: fix return value check in omap2_set_init_voltage()
OMAPDSS: fix return value check in create_dss_pdev()
ARM: OMAP: hsmmc: fix return value check in omap_hsmmc_init_one()
ARM: OMAP: fix return value check in realtime_counter_init()
ARM: OMAP2+: remove duplicated include from board-omap3stalker.c
Yegor Yefremov (1):
arm: increase FORCE_MAX_ZONEORDER for TI AM33XX
.../brcm,bcm2835-armctrl-ic.txt | 2 +-
.../bindings/timer/brcm,bcm2835-system-timer.txt | 2 +-
arch/arm/Kconfig | 3 +-
arch/arm/boot/dts/Makefile | 15 +++---
arch/arm/boot/dts/omap4-panda.dts | 47 ++++++++++++++++++
arch/arm/boot/dts/omap4-sdp.dts | 57 +++++++++++++++++++++
arch/arm/boot/dts/omap5-evm.dts | 58 ++++++++++++++++++++++
arch/arm/boot/dts/omap5.dtsi | 17 +++++++
arch/arm/boot/dts/tegra20-seaboard.dts | 2 +-
arch/arm/boot/dts/tegra20.dtsi | 4 +-
arch/arm/common/it8152.c | 12 +++--
arch/arm/mach-at91/pm.c | 5 +-
arch/arm/mach-at91/setup.c | 2 +-
arch/arm/mach-davinci/da850.c | 2 +-
arch/arm/mach-footbridge/include/mach/irqs.h | 2 -
arch/arm/mach-integrator/include/mach/cm.h | 2 +-
arch/arm/mach-integrator/include/mach/platform.h | 6 +--
arch/arm/mach-integrator/integrator_ap.c | 2 +-
arch/arm/mach-integrator/integrator_cp.c | 4 +-
arch/arm/mach-iop13xx/iq81340sc.c | 2 +-
arch/arm/mach-iop13xx/pci.c | 2 +-
arch/arm/mach-ks8695/include/mach/memory.h | 3 +-
arch/arm/mach-mv78xx0/addr-map.c | 2 +-
arch/arm/mach-mv78xx0/common.c | 2 +-
arch/arm/mach-omap1/devices.c | 2 +-
arch/arm/mach-omap2/board-4430sdp.c | 26 ++++++++++
arch/arm/mach-omap2/board-flash.c | 2 +-
arch/arm/mach-omap2/board-omap3beagle.c | 2 +-
arch/arm/mach-omap2/board-omap3evm.c | 3 +-
arch/arm/mach-omap2/board-omap3stalker.c | 5 --
arch/arm/mach-omap2/board-omap4panda.c | 18 ++++++-
arch/arm/mach-omap2/board-rx51-peripherals.c | 2 +-
arch/arm/mach-omap2/board-zoom-peripherals.c | 3 +-
arch/arm/mach-omap2/clkt_clksel.c | 2 +-
arch/arm/mach-omap2/clock33xx_data.c | 2 +
arch/arm/mach-omap2/clockdomain2xxx_3xxx.c | 44 ++++++++--------
arch/arm/mach-omap2/display.c | 2 +-
arch/arm/mach-omap2/gpmc.c | 4 +-
arch/arm/mach-omap2/hsmmc.c | 2 +-
arch/arm/mach-omap2/mux.c | 2 +-
arch/arm/mach-omap2/omap-secure.c | 4 +-
arch/arm/mach-omap2/omap_hwmod.c | 31 ++++++++++--
arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 2 +-
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 9 ++--
arch/arm/mach-omap2/opp.c | 23 ++++++---
arch/arm/mach-omap2/pm-debug.c | 2 +-
arch/arm/mach-omap2/pm.c | 13 ++++-
arch/arm/mach-omap2/sr_device.c | 2 +-
arch/arm/mach-omap2/timer.c | 2 +-
arch/arm/mach-omap2/twl-common.c | 2 +-
arch/arm/mach-pxa/cm-x2xx.c | 1 +
arch/arm/mach-pxa/palmte2.c | 2 +
arch/arm/mach-pxa/sharpsl_pm.c | 48 ------------------
arch/arm/mach-pxa/viper.c | 3 +-
arch/arm/mach-rpc/ecard.c | 4 +-
arch/arm/mach-s3c24xx/irq-s3c2416.c | 6 +--
arch/arm/mach-s3c24xx/irq-s3c2443.c | 4 +-
arch/arm/mach-s3c24xx/simtec-usb.c | 2 +-
arch/arm/mach-sa1100/assabet.c | 2 +-
arch/arm/mach-shark/pci.c | 2 +-
arch/arm/mach-shmobile/include/mach/common.h | 2 +-
arch/arm/mach-tegra/Kconfig | 6 +--
arch/arm/mach-ux500/Kconfig | 4 +-
arch/arm/mach-vt8500/include/mach/uncompress.h | 8 +--
arch/arm/mach-vt8500/vt8500.c | 5 +-
arch/arm/plat-omap/Kconfig | 2 +
arch/arm/plat-omap/counter_32k.c | 21 +++++---
arch/arm/plat-omap/omap-pm-noop.c | 8 +--
arch/arm/plat-omap/omap_device.c | 2 +-
drivers/char/ds1620.c | 8 +--
drivers/char/nwflash.c | 4 +-
drivers/cpufreq/omap-cpufreq.c | 36 +++++---------
drivers/mmc/host/sdhci-tegra.c | 1 -
drivers/power/avs/smartreflex.c | 8 +--
sound/oss/waveartist.c | 4 +-
75 files changed, 436 insertions(+), 223 deletions(-)
^ permalink raw reply
* [PATCH] Add forgotten mask in cache way unlock for PL310.
From: Christopher Kenna @ 2012-10-10 21:56 UTC (permalink / raw)
To: linux-arm-kernel
The part number should be masked out of the cache ID when detecting if
the cache controller is a PL310. Since this is done elsewhere, add a
macro for brevity.
Tested on a PandaBoard ES.
Signed-off-by: Christopher Kenna <cjk@cs.unc.edu>
---
arch/arm/mm/cache-l2x0.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 8a97e64..bdf2f66 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -27,6 +27,7 @@
#include <asm/hardware/cache-l2x0.h>
#define CACHE_LINE_SIZE 32
+#define CACHE_ID_PART(id) ((id) & L2X0_CACHE_ID_PART_MASK)
static void __iomem *l2x0_base;
static DEFINE_RAW_SPINLOCK(l2x0_lock);
@@ -292,7 +293,7 @@ static void l2x0_unlock(u32 cache_id)
int lockregs;
int i;
- if (cache_id == L2X0_CACHE_ID_PART_L310)
+ if (CACHE_ID_PART(cache_id) == L2X0_CACHE_ID_PART_L310)
lockregs = 8;
else
/* L210 and unknown types */
@@ -323,7 +324,7 @@ void __init l2x0_init(void __iomem *base, u32 aux_val, u32 aux_mask)
aux |= aux_val;
/* Determine the number of ways */
- switch (cache_id & L2X0_CACHE_ID_PART_MASK) {
+ switch (CACHE_ID_PART(cache_id)) {
case L2X0_CACHE_ID_PART_L310:
if (aux & (1 << 16))
ways = 16;
--
1.7.9.5
^ permalink raw reply related
* [PATCH] ARM: tegra: rename the file of "sleep-tXX" to "sleep-tegraXX"
From: Olof Johansson @ 2012-10-10 22:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5075E395.4070608@wwwdotorg.org>
On Wed, Oct 10, 2012 at 2:07 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 10/10/2012 02:54 PM, Olof Johansson wrote:
>> On Mon, Oct 8, 2012 at 3:23 AM, Joseph Lo <josephl@nvidia.com> wrote:
>>> For the naming consistency under the mach-tegra, we re-name the file of
>>> "sleep-tXX" to "sleep-tegraXX" (e.g., sleep-t30 to sleep-tegra30).
>>>
>>> Signed-off-by: Joseph Lo <josephl@nvidia.com>
>>
>> Why rename? It's just churn.
>
> The CPUs are named TegraNN not TNN, so for consistency the files should
> be named that way. This is almost the last instance; everything else got
> renamed as a side-effect of adding splitting things up for Tegra30
> support. Oh, except tegra2_emc.c which can be renamed whenever it's
> moved to an appropriate drivers/ directory.
Marketing names are irrelevant and tend to change over time. But ok,
if it's the last renames pending then I think we can be OK with it.
-Olof
^ permalink raw reply
* pm: add suspend_mem and suspend_standby support
From: Rafael J. Wysocki @ 2012-10-10 23:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5075210B.3020309@ti.com>
On Wednesday 10 of October 2012 12:47:31 Vaibhav Hiremath wrote:
>
> On 10/10/2012 3:42 AM, Rafael J. Wysocki wrote:
> > On Tuesday 09 of October 2012 17:17:04 Jean-Christophe PLAGNIOL-VILLARD wrote:
> >> On 07:58 Tue 09 Oct , Greg Kroah-Hartman wrote:
> >>> On Tue, Oct 09, 2012 at 01:46:33PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> >>>> On 22:02 Sun 07 Oct , Rafael J. Wysocki wrote:
> >>>>> On Sunday 07 of October 2012 15:12:01 Jean-Christophe PLAGNIOL-VILLARD wrote:
> >>>>>> On 00:18 Sun 07 Oct , Rafael J. Wysocki wrote:
> >>>>>>> On Saturday 06 of October 2012 18:14:29 Jean-Christophe PLAGNIOL-VILLARD wrote:
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> The following changes since commit 5f3d2f2e1a63679cf1c4a4210f2f1cc2f335bef6:
> >>>>>>>>
> >>>>>>>> Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc (2012-10-06 03:16:12 +0900)
> >>>>>>>>
> >>>>>>>> are available in the git repository at:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> git://git.jcrosoft.org/linux-2.6.git tags/pm_suspend_standby_mem
> >>>>>>>>
> >>>>>>>> for you to fetch changes up to b73c8f97aa8e720bd3b921159687d00626c99d63:
> >>>>>>>>
> >>>>>>>> arm: at91: drop at91_suspend_entering_slow_clock (2012-10-06 18:06:25 +0800)
> >>>>>>>>
> >>>>>>>> ----------------------------------------------------------------
> >>>>>>>> pm: add suspend_mem and suspend_standby support
> >>>>>>>>
> >>>>>>>> Today when we go to suspend we can not knwon at drivers level if we go in
> >>>>>>>> STANDBY or MEM. Fix this by introducing two new callback suspend_mem and
> >>>>>>>> suspend_standby.
> >>>>>>>
> >>>>>>> No way. Device drivers shouldn't be concerned about that.
> >>>>>> I do need it on at91 as we swith to slow_clock in MEM suspend and some ip
> >>>>>> need special handling when switching to slow_clock
> >>>>>
> >>>>> Well, my answer to that is: please fix your platform code instead of
> >>>>> hacking the PM core to work around its problems.
> >>>> how can I fix drivers pm issue when I no way to known at driver level the
> >>>> real suspend, the PM core is supposed to proivde the right information to the
> >>>> drivers so the driver can put it's in the right pm mode. If the pm core can not
> >>>> provide such inforation the PM core is broken as we will have to do dirty
> >>>> hack.
> >>>
> >>> Why do you need to know the difference in your driver? We used to
> >>> provide this information a long time ago, but it turned out to not be
> >>> needed at all and just caused problems.
> >> because on at91 I need to handle the mem standby at drviers level.
> >
> > This is not an answer. You're basically saying "it has to be done this way,
> > because it has to be done this way".
> >
> >> We do it today already by a hack in different drivers at91_udc (usb device),
> >> atmel_serail and at91_ohci. Those 3 IP have specifci handling when switching
> >> to mem pm. On at91 when switch to mem we shutdown everything and run form a slow
> >> clock - this is done at soc level - but those IP have issue and need specific
> >> care before doing so. Ohterwise when the SoC will wakeup but those IP will not
> >>
> >> in this patch series I send the update of those 3 drivers too
> >> and kill the hack
> >
> > Well, let's start over. What's the difference between "suspend to RAM" (mem)
> > and "standby" on your platform?
> >
> >>>> Any generic framework is supposed to evolve for real user need here I've one
> >>>> so I udpate the core to mach a need
> >
> > Yes, if there are more users needing a change. If there's only one, I think not
> > really.
> >
>
> We came across such a need while supporting various low-power modes in
> AM335x SoC. I also wanted to put similar proposal, its good that Jean
> submitted patches and we are having this discussion early.
>
> Let me try to describe the need and issue here,
>
> In case of AM33xx device, we have different low-power modes supported
> by HW, for this discussion I will just talk about DeepSleep-0 and
> StandBy mode supported by HW (few other modes also described in spec)-
>
> Below is the Spec definition of these two low-power modes,
>
> PowerMode Application state States
> ========================================================================
> DeepSleep0 Everything is preserved Master Oscillator = OFF
> including SDRAM. VDD_MPU = 0.95v
> VDD_CORE = 0.95v
> PD_WKUP = ON
> PD_MPU = OFF
> PD_PER = OFF
> PD_GFX = OFF
> All IOs & RTC supplies are ON
>
>
> Standby Everything is preserved Master Oscillator = ON
> including SDRAM. One PLL is ON
> Only required module clocks VDD_MPU = 0.95v
> are enabled rest are clock VDD_CORE = OPP50
> gated PD_WKUP = ON
> PD_MPU = ON
> PD_PER = ON
> PD_GFX = OFF
> All IOs & RTC supplies are ON
> If more PLLs /power domains/
> modules are required, the
> power will increase
> accordingly
>
>
>
> Now we have two major parameters here, Power Consumption and Latency
> (Sleep + Wakeup). Since DeepSleep-0 is as good as off state, it gives
> very less power consumption Vs huge Latency number, whereas, in case of
> standby the power consumption is more but the Latency is reduced.
>
> In addition to that, there are certain HW related parameters and issues
> contribute to these parameters. For example,
>
> In case of LCD driver the suspend/resume latency is in the range of
> 10msec, which can be reduced if driver knows that he is not entering or
> entered in DeepSleep-0 and choose not to do certain things.
> Another example would be, USB driver, we have seen Latency numbers in
> the range of 200msec, and of which 100 msec can simply be taken away if
> driver knows about the sleep state.
>
>
> I understand that, there is trade-off between power and latency numbers,
> but for certain use-cases latency is more important and it is not
> possible without telling driver about the low-power state.
I understand the problem at hand, but the question is who's going to tell
the driver about that.
Arguably, the PM core is not the right source of that information, because
if a driver is told "we're going into standby", it will have to ask the
platform about what "standby" actually means.
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* [PATCH 1/3] mfd: dbx500: Export prmcu_request_ape_opp_100_voltage
From: Mike Turquette @ 2012-10-11 0:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPDyKFr+Eb5=Cz5jHpyVmpX_-v9i8R6-qmK6ZfX75jw218S46g@mail.gmail.com>
Quoting Ulf Hansson (2012-10-04 05:03:05)
> Hi Sam and Linus,
>
> Do you see any issues with this patch? Can we advise Mike to merge it
> though his clock tree?
>
Thanks for the re-ping and gathering Ack's. I'll pull into my clk-next
as soon as I push out a new branch towards 3.8.
Regards,
Mike
> Kind regards
> Ulf Hansson
>
> On 24 September 2012 16:43, Ulf Hansson <ulf.hansson@stericsson.com> wrote:
> > From: Ulf Hansson <ulf.hansson@linaro.org>
> >
> > This function needs to be exported to let clients be able to
> > request the ape opp 100 voltage.
> >
> > Cc: Samuel Ortiz <sameo@linux.intel.com>
> > Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> > ---
> > drivers/mfd/db8500-prcmu.c | 4 ++--
> > include/linux/mfd/db8500-prcmu.h | 4 ++--
> > include/linux/mfd/dbx500-prcmu.h | 10 ++++++++++
> > 3 files changed, 14 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/mfd/db8500-prcmu.c b/drivers/mfd/db8500-prcmu.c
> > index e7f9539..0b8e0a0 100644
> > --- a/drivers/mfd/db8500-prcmu.c
> > +++ b/drivers/mfd/db8500-prcmu.c
> > @@ -1167,12 +1167,12 @@ int db8500_prcmu_get_ape_opp(void)
> > }
> >
> > /**
> > - * prcmu_request_ape_opp_100_voltage - Request APE OPP 100% voltage
> > + * db8500_prcmu_request_ape_opp_100_voltage - Request APE OPP 100% voltage
> > * @enable: true to request the higher voltage, false to drop a request.
> > *
> > * Calls to this function to enable and disable requests must be balanced.
> > */
> > -int prcmu_request_ape_opp_100_voltage(bool enable)
> > +int db8500_prcmu_request_ape_opp_100_voltage(bool enable)
> > {
> > int r = 0;
> > u8 header;
> > diff --git a/include/linux/mfd/db8500-prcmu.h b/include/linux/mfd/db8500-prcmu.h
> > index b82f6ee..6ee4247 100644
> > --- a/include/linux/mfd/db8500-prcmu.h
> > +++ b/include/linux/mfd/db8500-prcmu.h
> > @@ -515,7 +515,6 @@ enum romcode_read prcmu_get_rc_p2a(void);
> > enum ap_pwrst prcmu_get_xp70_current_state(void);
> > bool prcmu_has_arm_maxopp(void);
> > struct prcmu_fw_version *prcmu_get_fw_version(void);
> > -int prcmu_request_ape_opp_100_voltage(bool enable);
> > int prcmu_release_usb_wakeup_state(void);
> > void prcmu_configure_auto_pm(struct prcmu_auto_pm_config *sleep,
> > struct prcmu_auto_pm_config *idle);
> > @@ -564,6 +563,7 @@ int db8500_prcmu_set_arm_opp(u8 opp);
> > int db8500_prcmu_get_arm_opp(void);
> > int db8500_prcmu_set_ape_opp(u8 opp);
> > int db8500_prcmu_get_ape_opp(void);
> > +int db8500_prcmu_request_ape_opp_100_voltage(bool enable);
> > int db8500_prcmu_set_ddr_opp(u8 opp);
> > int db8500_prcmu_get_ddr_opp(void);
> >
> > @@ -610,7 +610,7 @@ static inline int db8500_prcmu_get_ape_opp(void)
> > return APE_100_OPP;
> > }
> >
> > -static inline int prcmu_request_ape_opp_100_voltage(bool enable)
> > +static inline int db8500_prcmu_request_ape_opp_100_voltage(bool enable)
> > {
> > return 0;
> > }
> > diff --git a/include/linux/mfd/dbx500-prcmu.h b/include/linux/mfd/dbx500-prcmu.h
> > index c410d99..c202d6c 100644
> > --- a/include/linux/mfd/dbx500-prcmu.h
> > +++ b/include/linux/mfd/dbx500-prcmu.h
> > @@ -336,6 +336,11 @@ static inline int prcmu_get_ape_opp(void)
> > return db8500_prcmu_get_ape_opp();
> > }
> >
> > +static inline int prcmu_request_ape_opp_100_voltage(bool enable)
> > +{
> > + return db8500_prcmu_request_ape_opp_100_voltage(enable);
> > +}
> > +
> > static inline void prcmu_system_reset(u16 reset_code)
> > {
> > return db8500_prcmu_system_reset(reset_code);
> > @@ -507,6 +512,11 @@ static inline int prcmu_get_ape_opp(void)
> > return APE_100_OPP;
> > }
> >
> > +static inline int prcmu_request_ape_opp_100_voltage(bool enable)
> > +{
> > + return 0;
> > +}
> > +
> > static inline int prcmu_set_arm_opp(u8 opp)
> > {
> > return 0;
> > --
> > 1.7.10
> >
^ permalink raw reply
* [PATCH v2 2/3] ARM: OMAP4: add _dev_attr_ to ocp2scp for representing usb_phy
From: Tony Lindgren @ 2012-10-11 0:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349675983-23803-3-git-send-email-kishon@ti.com>
Hi,
* Kishon Vijay Abraham I <kishon@ti.com> [121007 23:01]:
> In order to reflect devices(usb_phy) attached to ocp2scp bus, ocp2scp
> is assigned a device attribute to represent the attached devices.
...
> --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> @@ -21,6 +21,7 @@
> #include <linux/io.h>
> #include <linux/platform_data/gpio-omap.h>
> #include <linux/power/smartreflex.h>
> +#include <linux/platform_data/omap_ocp2scp.h>
>
> #include <plat/omap_hwmod.h>
> #include <plat/i2c.h>
> @@ -2681,6 +2682,32 @@ static struct omap_hwmod_class omap44xx_ocp2scp_hwmod_class = {
> .sysc = &omap44xx_ocp2scp_sysc,
> };
>
> +/* ocp2scp dev_attr */
> +static struct resource omap44xx_usb_phy_and_pll_addrs[] = {
> + {
> + .name = "usb_phy",
> + .start = 0x4a0ad080,
> + .end = 0x4a0ae000,
> + .flags = IORESOURCE_MEM,
> + },
> + {
> + /* XXX: Remove this once control module driver is in place */
> + .name = "ctrl_dev",
> + .start = 0x4a002300,
> + .end = 0x4a002303,
> + .flags = IORESOURCE_MEM,
> + },
> + { }
> +};
Why don't you set the CONTROL_DEV_CONF as a fixed regulator?
That way you can define the fixed regulator in mach-omap2/control.c
and the driver can just pick it up by name.
The 4470 TRM says that this register "power down entire USB
PHY" and "controls USB2PHYCORE.PD pin".
That way you can also get rid of the mysterious mdelay(200)
in omap_usb_phy_power() in omap-usb2.c driver.
However one thing needs to be checked first.
If CONTROL_DEV_CONF is not a regulator but is a signal mux,
then you can map the register with mux framework using the
pinctrl-single. See the pinctrl-single,bits binding that
was recently merged to mainline.
In the mux case you can set up the named states "default" and
"disabled" that the PHY driver can then manipulate with
pinctrl_select_state().
Note that for the mux case we don't have a non-device tree
pinctrl framework solution available, so you're probably
better off setting it up as a fixed regulator with comments
in case it really is a mux.
BTW, the reason I'm thinking CONTROL_DEV_CONF may be a mux
is because omap3 has registers named CONTROL_DEVCONF0 and
CONTROL_DEVCONF1 that mux signals for various devices.
But maybe that naming is just a coincidence.
Regards,
Tony
^ permalink raw reply
* alignment faults in 3.6
From: Jon Masters @ 2012-10-11 0:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <506EEFBB.3060705@gmail.com>
Hi everyone,
On 10/05/2012 10:33 AM, Rob Herring wrote:
> On 10/05/2012 09:05 AM, Russell King - ARM Linux wrote:
>> On Fri, Oct 05, 2012 at 07:24:44AM -0500, Rob Herring wrote:
>>> On 10/05/2012 03:24 AM, Russell King - ARM Linux wrote:
>>>> Does it matter? I'm just relaying the argument against adding __packed
>>>> which was used before we were forced (by the networking folk) to implement
>>>> the alignment fault handler.
>>>
>>> It doesn't really matter what will be accepted or not as adding __packed
>>> to struct iphdr doesn't fix the problem anyway. gcc still emits a ldm.
>>> The only way I've found to eliminate the alignment fault is adding a
>>> barrier between the 2 loads. That seems like a compiler issue to me if
>>> there is not a better fix.
>>
>> Even so, please test the patch I've sent you in the sub-thread - that
>> needs testing whether or not GCC is at fault. Will's patch to add the
>> warnings _has_ uncovered a potential issue with the use of __get_user()
>> in some parts of the ARM specific kernel, and I really need you to test
>> that while you're experiencing this problem.
>
> I've tested your patch and it appears to fix things. Thanks!
Ok. I'm looking for a short term solution in the Fedora kernel because
we've been bitten by this bug (I've been following this thread). I
considered just reverting Will's patch, but that only sweeps the issue
under the rug back to where we were in our 3.4 kernel. So, should we
pull in rmk's fix? It seems there are two problems here:
1). Missaligned access fault handling atomicity in general
2). Assumptions around struct alignment that turn out not to be true at
runtime due to the way that the structs are actually then aligned.
> Now on to getting rid of faults on practically every single received IP
> packet:
>
> Multi: 9871002
>
> RX packets:9872010 errors:0 dropped:0 overruns:0 frame:0
This will still be a problem, indeed. At least we can be aware we're
taking a large number of faults and hope for a netdev solution.
Jon.
^ permalink raw reply
* [PATCH 1/4] usb: phy: add a new driver for usb3 phy
From: Tony Lindgren @ 2012-10-11 0:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1348054229-27362-2-git-send-email-kishon@ti.com>
Hi,
* Kishon Vijay Abraham I <kishon@ti.com> [120919 04:32]:
> Added a driver for usb3 phy that handles the interaction between usb phy
> device and dwc3 controller.
>
> This also includes device tree support for usb3 phy driver and
> the documentation with device tree binding information is updated.
>
> Currently writing to control module register is taken care in this
> driver which will be removed once the control module driver is in place.
You may be able to set up the control module register with one
of the following Linux standard frameworks:
1. Fixed regulator defined in mach-omap2/control.c
In this case the PHY driver can pick up the regulator by name.
2. A mux mapped with pinctrl framework using pinctrl-single,bits
binding
And in this case the PHY driver can request the named pinctrl
states like "enabled" and "disabled".
> --- a/Documentation/devicetree/bindings/usb/usb-phy.txt
> +++ b/Documentation/devicetree/bindings/usb/usb-phy.txt
> @@ -15,3 +15,21 @@ usb2phy at 4a0ad080 {
> reg = <0x4a0ad080 0x58>,
> <0x4a002300 0x4>;
> };
The comments also apply to the omap_usb2.c driver for
0x4a002300 above.
> +
> +OMAP USB3 PHY
> +
> +Required properties:
> + - compatible: Should be "ti,omap-usb3"
> + - reg : Address and length of the register set for the device. Also
> +add the address of control module phy power register until a driver for
> +control module is added
> +
> +This is usually a subnode of ocp2scp to which it is connected.
> +
> +usb3phy at 4a084400 {
> + compatible = "ti,omap-usb3";
> + reg = <0x0x4a084400 0x80>,
> + <0x4a084800 0x64>,
> + <0x4a084c00 0x40>,
> + <0x4a002370 0x4>;
> +};
And register 0x4a002370 here. Care to post some info what the
0x4a002370 register bits do? Is that same as CONTROL_DEV_CONF
on omap4, or does it have other bits there too?
The advantage for using regulator fwk and pinctrl fwk is
that the regulator and mux can be children of the SCM
core driver when we have it. And no direct register tinkering
or omap specific custom exported functions are needed ;)
Regards,
Tony
^ permalink raw reply
* [PATCH 1/2] video: Add support for the Solomon SSD1307 OLED Controller
From: Florian Tobias Schandinat @ 2012-10-11 1:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50618242.2070302@free-electrons.com>
Hi Maxime,
On 09/25/2012 10:06 AM, Maxime Ripard wrote:
> Hello Florian,
>
> Le 21/09/2012 16:04, Maxime Ripard a ?crit :
>> Le 20/09/2012 18:33, Maxime Ripard a ?crit :
>>> This patch adds support for the Solomon SSD1307 OLED
>>> controller found on the Crystalfontz CFA10036 board.
>>>
>>> This controller can drive a display with a resolution up
>>> to 128x39 and can operate over I2C or SPI.
>>>
>>> The current driver has only been tested on the CFA-10036,
>>> that is using this controller over I2C to driver a 96x16
>>> OLED screen.
>>>
>>> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
>>> Cc: Brian Lilly <brian@crystalfontz.com>
>>
>> Would you consider merging this patch or review it?
>> It has been around for quite some time now and has not received any
>> comments for at least the 2 last versions, so I guess there is not much
>> left holding it back (unless, of course, if you have some comments to
>> address), and I really would like to have it in 3.7.
>
> I guess we missed the 3.7 merge here. That's no big deal, but I sent the
> patch series on a regular basis, starting 07/17 (sent new versions on
> 07/31, 08/23, 09/05 and 09/20), addressed all the issues that were
> raised, and never got any feedback from you, either positive or
> negative. The patches affecting the MX28 device trees have already been
> merged by Shawn Guo into its tree, so only the driver and the bindings
> remain to be merged. So I'm kind of lost on what should I do here?
>
> Is it because I have an obviously broken driver or you don't have enough
> time, or you don't want to merge drivers for such type of low resolution
> controllers, or any other reason?
I don't see any reason to not support low resolutions, might be a nice
status monitor for embedded devices.
It's not your fault. It's just that for the past two months writing my
thesis reduced my free time (and hence the time that I could potentially
use for reviewing patches) to approximately zero. While I managed to get
some smaller patches done, there really wasn't any time to process the
3-4 completely new things pending and some scarier patches which touch
the core infrastructure.
I think that it should be better soon, at least my thesis is now done,
but I also have to fix up the rest of my life that was neglected while
writing, including my paid jobs.
Best regards,
Florian Tobias Schandinat
^ permalink raw reply
* [PATCH] clk: fix return value check in bcm2835_init_clocks()
From: Mike Turquette @ 2012-10-11 1:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPgLHd-msJkHz5KxsxVhr0u8ainXU0t53XHeiwSeW2ShJkRbwg@mail.gmail.com>
Quoting Wei Yongjun (2012-10-08 19:44:47)
> On 10/09/2012 10:31 AM, Stephen Warren wrote:
> > On 10/07/2012 08:02 AM, Wei Yongjun wrote:
> >> From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
> >>
> >> In case of error, the function clk_register_fixed_rate() returns
> >> ERR_PTR() and never returns NULL. The NULL test in the return value
> >> check should be replaced with IS_ERR().
> >>
> >> dpatch engine is used to auto generate this patch.
> >> (https://github.com/weiyj/dpatch)
> > Acked-by: Stephen Warren <swarren@wwwdotorg.org>
> >
> > Mike, this driver was added through arm-soc; I assume it's simplest to
> > take this fixup through there too for 3.7-rc*? If so, Wei, could you
> > resend this patch with my ack to arm at kernel.org? Thanks.
>
> Will do, thanks.
Works for me.
Mike
^ permalink raw reply
* [kvmarm] [PATCH v2 12/14] KVM: ARM: VFP userspace interface
From: Rusty Russell @ 2012-10-11 1:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANM98qJDhHDBPq=XinLaXJG8e07-HhVBfd-2i3a68CumdXuFaw@mail.gmail.com>
Christoffer Dall <c.dall@virtualopensystems.com> writes:
> On Tue, Oct 9, 2012 at 2:11 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
>> On 1 October 2012 10:11, Christoffer Dall <c.dall@virtualopensystems.com> wrote:
>>> From: Rusty Russell <rusty.russell@linaro.org>
...
>>> +ARM 32-bit VFP control registers have the following id bit patterns:
>>> + 0x4002 0000 0012 1 <selector:3>
>>> +
>>> +ARM 64-bit FP registers have the following id bit patterns:
>>> + 0x4002 0000 0012 0 <selector:3>
>>> +
>>
>> In the other entries in this section, <foo:3> indicates a 3 bit field.
>> But I think for these two it's trying to indicate a 3 byte field.
...
> right you are, I'll modify this.
Thanks!
Rusty.
^ permalink raw reply
* [PATCH 1/3] dmaengine: sirf: fix a typo in dma_prep_interleaved
From: Barry Song @ 2012-10-11 1:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1348734938-20014-1-git-send-email-Barry.Song@csr.com>
ping
2012/9/27 Barry Song <Barry.Song@csr.com>:
> From: Barry Song <Baohua.Song@csr.com>
>
> either DEV_TO_MEM or MEM_TO_DEV is supported, so change
> OR to AND.
>
> Signed-off-by: Barry Song <Baohua.Song@csr.com>
> ---
> drivers/dma/sirf-dma.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/dma/sirf-dma.c b/drivers/dma/sirf-dma.c
> index 434ad31..35a329d 100644
> --- a/drivers/dma/sirf-dma.c
> +++ b/drivers/dma/sirf-dma.c
> @@ -428,7 +428,7 @@ static struct dma_async_tx_descriptor *sirfsoc_dma_prep_interleaved(
> unsigned long iflags;
> int ret;
>
> - if ((xt->dir != DMA_MEM_TO_DEV) || (xt->dir != DMA_DEV_TO_MEM)) {
> + if ((xt->dir != DMA_MEM_TO_DEV) && (xt->dir != DMA_DEV_TO_MEM)) {
> ret = -EINVAL;
> goto err_dir;
> }
> --
> 1.7.0.4
>
^ permalink raw reply
* alignment faults in 3.6
From: Måns Rullgård @ 2012-10-11 2:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <507619FA.6080001@jonmasters.org>
Jon Masters <jonathan@jonmasters.org> writes:
> Hi everyone,
>
> On 10/05/2012 10:33 AM, Rob Herring wrote:
>> On 10/05/2012 09:05 AM, Russell King - ARM Linux wrote:
>>> On Fri, Oct 05, 2012 at 07:24:44AM -0500, Rob Herring wrote:
>>>> On 10/05/2012 03:24 AM, Russell King - ARM Linux wrote:
>>>>> Does it matter? I'm just relaying the argument against adding __packed
>>>>> which was used before we were forced (by the networking folk) to implement
>>>>> the alignment fault handler.
>>>>
>>>> It doesn't really matter what will be accepted or not as adding __packed
>>>> to struct iphdr doesn't fix the problem anyway. gcc still emits a ldm.
>>>> The only way I've found to eliminate the alignment fault is adding a
>>>> barrier between the 2 loads. That seems like a compiler issue to me if
>>>> there is not a better fix.
This turns out to be caused by pointers being typecast to normal
(aligned) types.
>>> Even so, please test the patch I've sent you in the sub-thread - that
>>> needs testing whether or not GCC is at fault. Will's patch to add the
>>> warnings _has_ uncovered a potential issue with the use of __get_user()
>>> in some parts of the ARM specific kernel, and I really need you to test
>>> that while you're experiencing this problem.
>>
>> I've tested your patch and it appears to fix things. Thanks!
[...]
>> Now on to getting rid of faults on practically every single received IP
>> packet:
>>
>> Multi: 9871002
>>
>> RX packets:9872010 errors:0 dropped:0 overruns:0 frame:0
>
> This will still be a problem, indeed. At least we can be aware we're
> taking a large number of faults and hope for a netdev solution.
There are exactly two possible solutions:
1. Change the networking code so those structs are always aligned. This
might not be (easily) possible.
2. Mark the structs __packed and fix any typecasts like the ones seen in
this thread. This will have an adverse effect in cases where the
structs are in fact aligned.
Both solutions lie squarely in the networking code. It's time to
involve that list, or we'll never get anywhere.
--
M?ns Rullg?rd
mans at mansr.com
^ 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