Re: [PATCH] irqchip: omap-intc: improve IRQ handler
Felipe,
* Tony Lindgren [150119 13:41]:
> * Felipe Balbi [150102 10:50]:
> > as it turns out the current IRQ number will
> > *always* be available from SIR register which
> > renders the reads of PENDING registers as plain
> > unnecessary overhead.
> >
> > In order to catch any situation where SIR reads
> > as zero, we're adding a WARN() to turn it into
> > a very verbose error and users actually report
> > it.
> >
> > With this patch average running time of
> > omap_intc_handle_irq() reduced from about 28.5us
> > to 19.8us as measured by the kernel function
> > profiler.
> >
> > Tested with BeagleBoneBlack Rev A5C.
> >
> > Signed-off-by: Felipe Balbi
>
> Jason, looks like this is not showing up in Linux next. The
> same for the changes I did for dm81xx.
Can you please resend this to Jason? Looks like this
is still not merged.
Regards,
Tony
> > Before applying, it would be very nice to get reports
> > from other folks on different platforms, specially OMAP2/3
> > ones which I don't have (easy) access.
> >
> > drivers/irqchip/irq-omap-intc.c | 35 +--
> > 1 file changed, 5 insertions(+), 30 deletions(-)
> >
> > diff --git a/drivers/irqchip/irq-omap-intc.c
> > b/drivers/irqchip/irq-omap-intc.c
> > index 28718d3..a2da6d5 100644
> > --- a/drivers/irqchip/irq-omap-intc.c
> > +++ b/drivers/irqchip/irq-omap-intc.c
> > @@ -315,37 +315,12 @@ static int __init omap_init_irq(u32 base, struct
> > device_node *node)
> > static asmlinkage void __exception_irq_entry
> > omap_intc_handle_irq(struct pt_regs *regs)
> > {
> > - u32 irqnr = 0;
> > - int handled_irq = 0;
> > - int i;
> > -
> > - do {
> > - for (i = 0; i < omap_nr_pending; i++) {
> > - irqnr = intc_readl(INTC_PENDING_IRQ0 + (0x20 * i));
> > - if (irqnr)
> > - goto out;
> > - }
> > -
> > -out:
> > - if (!irqnr)
> > - break;
> > -
> > - irqnr = intc_readl(INTC_SIR);
> > - irqnr &= ACTIVEIRQ_MASK;
> > + u32 irqnr;
> >
> > - if (irqnr) {
> > - handle_domain_irq(domain, irqnr, regs);
> > - handled_irq = 1;
> > - }
> > - } while (irqnr);
> > -
> > - /*
> > -* If an irq is masked or deasserted while active, we will
> > -* keep ending up here with no irq handled. So remove it from
> > -* the INTC with an ack.
> > -*/
> > - if (!handled_irq)
> > - omap_ack_irq(NULL);
> > + irqnr = intc_readl(INTC_SIR);
> > + irqnr &= ACTIVEIRQ_MASK;
> > + WARN(!irqnr, "Spuriour IRQ ?\n");
> > + handle_domain_irq(domain, irqnr, regs);
> > }
> >
> > void __init omap2_init_irq(void)
> > --
> > 2.2.0
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
remoteproc: wkup_m3: suspend/resume for am335x bbone
Hi, cat /sys/power/state is empty, should be 'mem' I applied these patches: https://lkml.org/lkml/2015/4/1/542 here suspend support in kernel-config (shall I append the full .config?) # # Power management options # CONFIG_SUSPEND=y CONFIG_SUSPEND_FREEZER=y # CONFIG_HIBERNATION is not set CONFIG_PM_SLEEP=y # CONFIG_PM_AUTOSLEEP is not set # CONFIG_PM_WAKELOCKS is not set CONFIG_PM=y CONFIG_PM_DEBUG=y # CONFIG_PM_ADVANCED_DEBUG is not set # CONFIG_PM_TEST_SUSPEND is not set CONFIG_PM_SLEEP_DEBUG=y # CONFIG_APM_EMULATION is not set CONFIG_PM_OPP=y CONFIG_PM_CLK=y # CONFIG_WQ_POWER_EFFICIENT_DEFAULT is not set CONFIG_CPU_PM=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ARM_CPU_SUSPEND=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_NET=y [1.642524] remoteproc0: wkup_m3 is available [1.647570] remoteproc0: Note: remoteproc is still under development and considered experimental. [1.657068] remoteproc0: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed. [1.668418] remoteproc0: unsupported resource 4 [1.673275] remoteproc0: unsupported resource 4 [1.685122] usbcore: registered new interface driver snd-usb-audio [1.691835] remoteproc0: unsupported resource 4 [1.696777] remoteproc0: unsupported resource 4 tip of m3 firmware git://arago-project.org/git/projects/am33x-cm3.git Sun Mar 9 23:52:27 2014 -0700 32cf44e CM3: AM43XX: Add Tamper swakeup settings Do I need to update my m3 firmware? kind regards, Andreas Fenkart -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: dts: dra7: arch timer sits in always-on power domain
On Mon, Jul 13, 2015 at 09:41:41PM +0100, Felipe Balbi wrote:
> According to DRA7x TRM section 4.3.5 Realtime Counter (Master Counter),
> the realtime counter sits in the Wakeup Always-On Power domain.
> Furthermore, the counter will automatically switch the 32K clock source
> when MPU goes into standby and automatically switch back to SYS_CLK or
> ABE_LP when MPU goes out of standby.
While the counter is in an always-on domain (the architecture mandates
this) I don't think that applies to the timers (i.e. the comparators
within a CPU), which are almost certainly not in an always-on domain.
I suspect that this is incorrect, and it will be very painful to debug
if it is...
Thanks,
Mark.
>
> Signed-off-by: Felipe Balbi
> ---
> arch/arm/boot/dts/dra7.dtsi | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
> index 8f1e25bcecbd..c1e6fd82485f 100644
> --- a/arch/arm/boot/dts/dra7.dtsi
> +++ b/arch/arm/boot/dts/dra7.dtsi
> @@ -50,6 +50,7 @@
> IRQ_TYPE_LEVEL_LOW)>,
> IRQ_TYPE_LEVEL_LOW)>;
> interrupt-parent = <&gic>;
> + always-on;
> };
>
> gic: interrupt-controller@48211000 {
> --
> 2.4.4
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: dts: dra7: arch timer sits in always-on power domain
* Mark Rutland [150715 02:27]: > On Mon, Jul 13, 2015 at 09:41:41PM +0100, Felipe Balbi wrote: > > According to DRA7x TRM section 4.3.5 Realtime Counter (Master Counter), > > the realtime counter sits in the Wakeup Always-On Power domain. > > Furthermore, the counter will automatically switch the 32K clock source > > when MPU goes into standby and automatically switch back to SYS_CLK or > > ABE_LP when MPU goes out of standby. > > While the counter is in an always-on domain (the architecture mandates > this) I don't think that applies to the timers (i.e. the comparators > within a CPU), which are almost certainly not in an always-on domain. > > I suspect that this is incorrect, and it will be very painful to debug > if it is... OK good point. And there would have to be some wake-up line wired to the IO chain or the PMIC in this case if the comparator was always on. Dropping this patch for now anyways. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] omap fixes against v4.2-rc2
The following changes since commit bc0195aad0daa2ad5b0d76cce22b167bc3435590: Linux 4.2-rc2 (2015-07-12 15:10:30 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v4.2/fixes-rc2-v2 for you to fetch changes up to 9908ac3daa3da2d236b5406b95d0865ddb8b29c4: ARM: dts: Correct audio input route & set mic bias for am335x-pepper (2015-07-15 03:03:01 -0700) Fixes for omaps, all dts changes except for one: - Fix up LCD panel name for overo boards - Three fixes for pepper board for regulators, freqeuncy scaling and audio input. Note that there is still one issue being worked on for booting with multi_v7_defconfig - Add missing #iommu-cells for omap4 and 5 - Add missing HAVE_ARM_SCU for am43xx Adam YH Lee (3): ARM: dts: omap3: overo: Update LCD panel names ARM: dts: configure regulators for Gumstix Pepper ARM: dts: Correct audio input route & set mic bias for am335x-pepper Arun Bharadwaj (1): ARM: dts: Fix frequency scaling on Gumstix Pepper Dave Gerlach (1): ARM: OMAP2+: Add HAVE_ARM_SCU for AM43XX Suman Anna (2): ARM: dts: OMAP4: Add #iommu-cells property to IOMMUs ARM: dts: OMAP5: Add #iommu-cells property to IOMMUs arch/arm/boot/dts/am335x-pepper.dts | 16 +--- arch/arm/boot/dts/omap3-overo-common-lcd35.dtsi | 2 +- arch/arm/boot/dts/omap3-overo-common-lcd43.dtsi | 2 +- arch/arm/boot/dts/omap4.dtsi| 2 ++ arch/arm/boot/dts/omap5.dtsi| 2 ++ arch/arm/mach-omap2/Kconfig | 1 + 6 files changed, 20 insertions(+), 5 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/3] ARM: dts: dra7: Add syscon-pllreset syscon to SATA PHY
Hi Roger, On Tuesday 02 June 2015 02:40 PM, Roger Quadros wrote: > This register is required to be passed to the SATA PHY driver > to workaround errata i783 (SATA Lockup After SATA DPLL Unlock/Relock). > > Signed-off-by: Roger Quadros > Signed-off-by: Sekhar Nori > --- > arch/arm/boot/dts/dra7.dtsi | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi > index f03a091..260f300 100644 > --- a/arch/arm/boot/dts/dra7.dtsi > +++ b/arch/arm/boot/dts/dra7.dtsi > @@ -1135,6 +1135,7 @@ > ctrl-module = <&omap_control_sata>; > clocks = <&sys_clkin1>, <&sata_ref_clk>; > clock-names = "sysclk", "refclk"; > + syscon-pllreset = <&dra7_ctrl_core 0x3fc>; I think all users of syscon should be made child node of scm_conf. Tony and Tero, is that right? If so, then we might have to modify the driver too. Cheers Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] clk: ti: clock driver code migration to drivers
On 07/14/2015 11:31 PM, Stephen Boyd wrote: On 07/14/2015 01:09 PM, Tero Kristo wrote: On 07/14/2015 10:29 PM, Stephen Boyd wrote: On 07/14/2015 01:54 AM, Tero Kristo wrote: The following changes since commit bc0195aad0daa2ad5b0d76cce22b167bc3435590: Linux 4.2-rc2 (2015-07-12 15:10:30 -0700) Why did this get rebased onto v4.2-rc2? I thought it was all ready to go based on v4.1-rc2? If possible leave it on v4.1-rc2 please. You mean 4.2-rc1 I guess...? Or do you really mean the old 4.1-rc2? Old 4.1-rc2 please Ok, posting a new one after this, this one can be ignored. -Tero -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] omap dts changes for v4.3, part 1
The following changes since commit bc0195aad0daa2ad5b0d76cce22b167bc3435590: Linux 4.2-rc2 (2015-07-12 15:10:30 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v4.3/dt-pt1 for you to fetch changes up to 80edaaead3687b47ba3760588306937439ebd7bd: ARM: dts: am335x-evm: Switch using simple-audio-card for audio support (2015-07-14 04:28:25 -0700) Omap dts changes for v4.3 merge window. There are also related changes for reemoteproc platform_data and audio options for omap2plus_defconfig to keep audio working when changing boards to use SIMPLE_CARD. The summary of changes is: - A large set of audio related changes for SIMPLE_CARD from Peter Ujfalusi for am335x and am437x - Pinctrl dts defines for dra7 virtual mode to configure timings - Change to use cpsw slave0 for dra7 Ethernet - Remove unconfigured and wrong l3-mux entry for dm816x - Add support for Gumstix Palo35 and TobiDuo boards, and Overo PoP NAND and McBSP2 - Start using new HDMI binding for tilcdc - Start using new sDMA crossbar for dra7 - Start using rproc for am335x and am437x M3 coprocessor Adam YH Lee (2): ARM: dts: overo: Enable McBSP2 for all Overo COMs ARM: dts: overo: Add device tree for Palo35 board Ash Charles (2): ARM: dts: Add DTS for Gumstix TobiDuo expansion board ARM: dts: overo: Support PoP NAND Dave Gerlach (1): ARM: OMAP2+: Use pdata-quirks for wkup_m3 reset management Jyri Sarha (1): ARM: dts: am335x-boneblack: Use new binding for HDMI Nishanth Menon (1): pinctrl: dra: dt-bindings: Add virtual mode configuration option Peter Ujfalusi (21): ARM: dts: dra7x: Integrate sDMA crossbar ARM: omap2plus_defconfig: Enable audio related config options ARM: dts: am437x-sk-evm: Add sleep pin settings for mcasp1 ARM: dts: am437x-sk-evm: Switch using simple-audio-card for audio support ARM: dts: am43xx-epos-evm: Add gpio-hog for configuring the display/audio mux ARM: dts: am43xx-epos-evm: Add regulator for VBAT and DCDC4 of tps65218 ARM: dts: am43xx-epos-evm: McASP1 node for audio support ARM: dts: am43xx-epos-evm: Add node for tlv320aic3111 audio codec ARM: dts: am43xx-epos-evm: Enable analog audio via simple-card ARM: dts: am437x-gp-evm: Add gpio-hog for configuring the display/audio mux ARM: dts: am437x-gp-evm: Rename fixed regulator vmmcsd_fixed to evm_v3_3d ARM: dts: am437x-gp-evm: Add node for tlv320aic3106 audio codec ARM: dts: am437x-gp-evm: McASP1 node for audio support ARM: dts: am437x-gp-evm: Enable analog audio via simple-card ARM: dts: am335x-evmsk: Fix mcasp1 node's indentation ARM: dts: am335x-evmsk: Add sleep pin settings for mcasp1 ARM: dts: am335x-evmsk: Switch using simple-audio-card for audio support ARM: dts: am335x-evm: Fix mcasp1 node's indentation ARM: dts: am335x-evm: Rename pinctrl section for McASP1 ARM: dts: am335x-evm: Add sleep pin settings for mcasp1 ARM: dts: am335x-evm: Switch using simple-audio-card for audio support Suman Anna (2): ARM: dts: AM33xx: Update and move wkup_m3 node to l4 node ARM: dts: AM4372: Add the wkupm3 rproc node Tony Lindgren (1): ARM: dts: Remove L3 compatible value for dm816x Vignesh R (1): ARM: dts: DRA72: switch to cpsw slave0 for ethernet arch/arm/boot/dts/Makefile| 4 + arch/arm/boot/dts/am335x-boneblack.dts| 20 +++- arch/arm/boot/dts/am335x-evm.dts | 69 arch/arm/boot/dts/am335x-evmsk.dts| 62 +++ arch/arm/boot/dts/am33xx.dtsi | 17 +-- arch/arm/boot/dts/am4372.dtsi | 9 ++ arch/arm/boot/dts/am437x-gp-evm.dts | 108 +++--- arch/arm/boot/dts/am437x-sk-evm.dts | 45 ++-- arch/arm/boot/dts/am43x-epos-evm.dts | 130 -- arch/arm/boot/dts/dm816x.dtsi | 2 +- arch/arm/boot/dts/dra7.dtsi | 57 ++ arch/arm/boot/dts/dra72-evm.dts | 10 +- arch/arm/boot/dts/omap3-overo-base.dtsi | 55 + arch/arm/boot/dts/omap3-overo-common-lcd35.dtsi | 3 +- arch/arm/boot/dts/omap3-overo-palo35-common.dtsi | 53 + arch/arm/boot/dts/omap3-overo-palo35.dts | 37 ++ arch/arm/boot/dts/omap3-overo-storm-palo35.dts| 37 ++ arch/arm/boot/dts/omap3-overo-storm-tobiduo.dts | 21 arch/arm/boot/dts/omap3-overo-tobiduo-common.dtsi | 65 +++ arch/arm/boot/dts/omap3-overo-tobiduo.dts | 21 arch/arm/boot/dts/omap3-overo.dtsi| 4 - arch/arm/configs/omap2plus_defconfig | 3 + arch/arm/mach-omap2/pda
[GIT PULL]
Hi Stephen, Mike, Here is the updated pull-request based on Stephen's request. This is on top of 4.1-rc2. The branch is force updated version of the one Stephen tried yesterday, the old one contained the minor build issues present on v3 of the patch set. I did a quick try of merging this branch on top of 4.2-rc2 and it works fine without any conflicts. -Tero The following changes since commit 5ebe6afaf0057ac3eaeb98defd5456894b446d22: Linux 4.1-rc2 (2015-05-03 19:22:23 -0700) are available in the git repository at: https://github.com/t-kristo/linux-pm.git for-4.2/ti-clk-move for you to fetch changes up to 989feafb84118a840ff21250a1e5f516f43e3dbb: clk: ti: move low-level access and init code under clock driver (2015-06-02 12:31:46 +0300) Tero Kristo (27): ARM: OMAP2+: clock: export driver API to setup/get clock features clk: ti: move generic OMAP DPLL implementation under drivers/clk clk: ti: move OMAP4+ DPLL implementation under drivers/clk clk: ti: move interface clock implementation under drivers/clk ARM: OMAP3: dpll3-m2: get rid of obsolete clksel access ARM: OMAP2+: clk: remove obsolete clksel support code ARM: OMAP2+: clock: remove clock_common_data.c file ARM: OMAP36xx: remove clock36xx.c/.h files clk: ti: autoidle: move generic autoidle handling code to clock driver clk: ti: move omap2_clk_enable_init_clocks under clock driver ARM: OMAP2+: clock: remove support for legacy mpurate command line param ARM: OMAP2+: clock: add support for clkdm ops to the low level clk ops ARM: OMAP2+: clock: add support for specific CM ops to ti_clk_ll_ops clk: ti: dpll: move omap3 DPLL functionality to clock driver ARM: OMAP3: clock: remove clock3xxx.c file ARM: OMAP2+: clock: remove clkdm_control static boolean from code clk: ti: dflt: move support for default gate clock to clock driver clk: ti: omap2430: move clock support code under clock driver clk: ti: clkdm: move clkdm gate clock support code to clock driver clk: ti: omap34xx: move omap34xx clock type support code to clock driver ARM: OMAP4: clock: remove clock44xx.h header clk: ti: am3517: move remaining am3517 clock support code to clock driver clk: ti: move some public definitions to private header ARM: OMAP2+: clock: remove dead definitions from the clock header file clk: ti: remove exported ll_ops struct, instead add an API for registration ARM: OMAP2+: clock: remove legacy omap2_clk_readl/writel APIs clk: ti: move low-level access and init code under clock driver arch/arm/mach-omap2/Makefile | 22 +- arch/arm/mach-omap2/clkt34xx_dpll3m2.c |7 +- arch/arm/mach-omap2/clkt_clksel.c | 466 -- arch/arm/mach-omap2/clkt_iclk.c| 68 -- arch/arm/mach-omap2/clock.c| 675 +--- arch/arm/mach-omap2/clock.h| 205 +- arch/arm/mach-omap2/clock2430.c| 57 -- arch/arm/mach-omap2/clock2xxx.c| 57 -- arch/arm/mach-omap2/clock34xx.c| 138 arch/arm/mach-omap2/clock34xx.h| 18 - arch/arm/mach-omap2/clock3517.c| 118 arch/arm/mach-omap2/clock3517.h| 14 - arch/arm/mach-omap2/clock36xx.c| 69 -- arch/arm/mach-omap2/clock36xx.h| 13 - arch/arm/mach-omap2/clock3xxx.c| 135 arch/arm/mach-omap2/clock44xx.h| 20 - arch/arm/mach-omap2/clock_common_data.c| 115 arch/arm/mach-omap2/io.c |3 +- drivers/clk/ti/Makefile| 17 +- drivers/clk/ti/apll.c |2 + drivers/clk/ti/autoidle.c | 121 +++- drivers/clk/ti/clk-2xxx.c |2 + drivers/clk/ti/clk-33xx.c |2 + drivers/clk/ti/clk-3xxx.c | 244 +++ drivers/clk/ti/clk-43xx.c |2 + drivers/clk/ti/clk-44xx.c |2 + drivers/clk/ti/clk-54xx.c |2 + drivers/clk/ti/clk-7xx.c |3 +- drivers/clk/ti/clk-816x.c |2 + drivers/clk/ti/clk.c | 145 - drivers/clk/ti/clkt_dflt.c | 316 + .../arm/mach-omap2 => drivers/clk/ti}/clkt_dpll.c | 27 +- drivers/clk/ti/clkt_iclk.c | 101 +++ drivers/clk/ti/clock.h | 113 drivers/clk/ti/clockdomain.c
Re: [PATCH v2 3/3] ARM: dts: dra7: Add syscon-pllreset syscon to SATA PHY
* Kishon Vijay Abraham I [150715 04:24]: > Hi Roger, > > On Tuesday 02 June 2015 02:40 PM, Roger Quadros wrote: > > This register is required to be passed to the SATA PHY driver > > to workaround errata i783 (SATA Lockup After SATA DPLL Unlock/Relock). > > > > Signed-off-by: Roger Quadros > > Signed-off-by: Sekhar Nori > > --- > > arch/arm/boot/dts/dra7.dtsi | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi > > index f03a091..260f300 100644 > > --- a/arch/arm/boot/dts/dra7.dtsi > > +++ b/arch/arm/boot/dts/dra7.dtsi > > @@ -1135,6 +1135,7 @@ > > ctrl-module = <&omap_control_sata>; > > clocks = <&sys_clkin1>, <&sata_ref_clk>; > > clock-names = "sysclk", "refclk"; > > + syscon-pllreset = <&dra7_ctrl_core 0x3fc>; > > I think all users of syscon should be made child node of scm_conf. Tony and > Tero, is that right? > > If so, then we might have to modify the driver too. Yeah there should not be much need to use syscon outside scm_conf area and for I2C devices. If there's some other misc register area in dra7 in addition to scm_conf then it might make sense to use it. But in general, for the SCM registers, just a normal loadable kernel driver module doing of_ioremap on a dedicated range of registers is always a better option :) Regrds, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] [input] tsc2005 cleanup
Hi, The following patches simplify and cleanup the tsc2005 touchscreen driver. Apart from making the driver more readable, the direct usage of SPI has been reduced to one function, so that tsc2004 support may be addable now (see [0]). The driver could be further simplified by making the vio regulator also mandatory for boardcode and switching boardcode from set_reset callback to GPIOD API. Since that would result in a patch touching the ARM and the input subsystem, I suggest to wait until the Nokia N900 boardcode is gone. [0] http://permalink.gmane.org/gmane.linux.kernel.input/37513 -- Sebastian Sebastian Reichel (4): Input: tsc2005 - improve readability of register defines Input: tsc2005 - convert to regmap Input: tsc2005 - simplify drvdata acquisition Input: tsc2005 - convert to gpiod drivers/input/touchscreen/tsc2005.c | 235 ++-- 1 file changed, 88 insertions(+), 147 deletions(-) -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] Input: tsc2005 - improve readability of register defines
Improve defines for first control byte by removing 0x00 prefix (the defines are for 8 bit values and not for 16 bit values) and expose register structure by exposing the shift. Signed-off-by: Sebastian Reichel --- drivers/input/touchscreen/tsc2005.c | 28 ++-- 1 file changed, 18 insertions(+), 10 deletions(-) diff --git a/drivers/input/touchscreen/tsc2005.c b/drivers/input/touchscreen/tsc2005.c index d8c025b..87038b2 100644 --- a/drivers/input/touchscreen/tsc2005.c +++ b/drivers/input/touchscreen/tsc2005.c @@ -61,16 +61,24 @@ #define TSC2005_CMD_12BIT 0x04 /* control byte 0 */ -#define TSC2005_REG_READ 0x0001 -#define TSC2005_REG_PND0 0x0002 -#define TSC2005_REG_X 0x -#define TSC2005_REG_Y 0x0008 -#define TSC2005_REG_Z1 0x0010 -#define TSC2005_REG_Z2 0x0018 -#define TSC2005_REG_TEMP_HIGH 0x0050 -#define TSC2005_REG_CFR0 0x0060 -#define TSC2005_REG_CFR1 0x0068 -#define TSC2005_REG_CFR2 0x0070 +#define TSC2005_REG_READ 0x01 /* R/W access */ +#define TSC2005_REG_PND0 0x02 /* Power Not Down Control */ +#define TSC2005_REG_X (0x0 << 3) +#define TSC2005_REG_Y (0x1 << 3) +#define TSC2005_REG_Z1 (0x2 << 3) +#define TSC2005_REG_Z2 (0x3 << 3) +#define TSC2005_REG_AUX(0x4 << 3) +#define TSC2005_REG_TEMP1 (0x5 << 3) +#define TSC2005_REG_TEMP2 (0x6 << 3) +#define TSC2005_REG_STATUS (0x7 << 3) +#define TSC2005_REG_AUX_HIGH (0x8 << 3) +#define TSC2005_REG_AUX_LOW(0x9 << 3) +#define TSC2005_REG_TEMP_HIGH (0xA << 3) +#define TSC2005_REG_TEMP_LOW (0xB << 3) +#define TSC2005_REG_CFR0 (0xC << 3) +#define TSC2005_REG_CFR1 (0xD << 3) +#define TSC2005_REG_CFR2 (0xE << 3) +#define TSC2005_REG_CONV_FUNC (0xF << 3) /* configuration register 0 */ #define TSC2005_CFR0_PRECHARGE_276US 0x0040 -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] Input: tsc2005 - convert to regmap
Convert driver, so that it uses regmap instead of directly
using spi_transfer for all register accesses.
Signed-off-by: Sebastian Reichel
---
drivers/input/touchscreen/tsc2005.c | 170
1 file changed, 58 insertions(+), 112 deletions(-)
diff --git a/drivers/input/touchscreen/tsc2005.c
b/drivers/input/touchscreen/tsc2005.c
index 87038b2..0aec45a 100644
--- a/drivers/input/touchscreen/tsc2005.c
+++ b/drivers/input/touchscreen/tsc2005.c
@@ -34,6 +34,7 @@
#include
#include
#include
+#include
/*
* The touchscreen interface operates as follows:
@@ -120,20 +121,36 @@
#define TSC2005_SPI_MAX_SPEED_HZ 1000
#define TSC2005_PENUP_TIME_MS 40
-struct tsc2005_spi_rd {
- struct spi_transfer spi_xfer;
- u32 spi_tx;
- u32 spi_rx;
+static const struct regmap_range tsc2005_writable_ranges[] = {
+ regmap_reg_range(TSC2005_REG_AUX_HIGH, TSC2005_REG_CFR2),
};
+static const struct regmap_access_table tsc2005_writable_table = {
+ .yes_ranges = tsc2005_writable_ranges,
+ .n_yes_ranges = ARRAY_SIZE(tsc2005_writable_ranges),
+};
+
+static struct regmap_config tsc2005_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 16,
+ .reg_stride = 0x08,
+ .max_register = 0x78,
+ .read_flag_mask = TSC2005_REG_READ,
+ .wr_table = &tsc2005_writable_table,
+ .use_single_rw = true,
+};
+
+struct tsc2005_data {
+ u16 x;
+ u16 y;
+ u16 z1;
+ u16 z2;
+} __packed;
+#define TSC2005_DATA_REGS 4
+
struct tsc2005 {
struct spi_device *spi;
-
- struct spi_message spi_read_msg;
- struct tsc2005_spi_rd spi_x;
- struct tsc2005_spi_rd spi_y;
- struct tsc2005_spi_rd spi_z1;
- struct tsc2005_spi_rd spi_z2;
+ struct regmap *regmap;
struct input_dev*idev;
charphys[32];
@@ -190,62 +207,6 @@ static int tsc2005_cmd(struct tsc2005 *ts, u8 cmd)
return 0;
}
-static int tsc2005_write(struct tsc2005 *ts, u8 reg, u16 value)
-{
- u32 tx = ((reg | TSC2005_REG_PND0) << 16) | value;
- struct spi_transfer xfer = {
- .tx_buf = &tx,
- .len= 4,
- .bits_per_word = 24,
- };
- struct spi_message msg;
- int error;
-
- spi_message_init(&msg);
- spi_message_add_tail(&xfer, &msg);
-
- error = spi_sync(ts->spi, &msg);
- if (error) {
- dev_err(&ts->spi->dev,
- "%s: failed, register: %x, value: %x, error: %d\n",
- __func__, reg, value, error);
- return error;
- }
-
- return 0;
-}
-
-static void tsc2005_setup_read(struct tsc2005_spi_rd *rd, u8 reg, bool last)
-{
- memset(rd, 0, sizeof(*rd));
-
- rd->spi_tx = (reg | TSC2005_REG_READ) << 16;
- rd->spi_xfer.tx_buf= &rd->spi_tx;
- rd->spi_xfer.rx_buf= &rd->spi_rx;
- rd->spi_xfer.len = 4;
- rd->spi_xfer.bits_per_word = 24;
- rd->spi_xfer.cs_change = !last;
-}
-
-static int tsc2005_read(struct tsc2005 *ts, u8 reg, u16 *value)
-{
- struct tsc2005_spi_rd spi_rd;
- struct spi_message msg;
- int error;
-
- tsc2005_setup_read(&spi_rd, reg, true);
-
- spi_message_init(&msg);
- spi_message_add_tail(&spi_rd.spi_xfer, &msg);
-
- error = spi_sync(ts->spi, &msg);
- if (error)
- return error;
-
- *value = spi_rd.spi_rx;
- return 0;
-}
-
static void tsc2005_update_pen_state(struct tsc2005 *ts,
int x, int y, int pressure)
{
@@ -274,26 +235,23 @@ static irqreturn_t tsc2005_irq_thread(int irq, void *_ts)
struct tsc2005 *ts = _ts;
unsigned long flags;
unsigned int pressure;
- u32 x, y;
- u32 z1, z2;
+ struct tsc2005_data tsdata;
int error;
/* read the coordinates */
- error = spi_sync(ts->spi, &ts->spi_read_msg);
+ error = regmap_bulk_read(ts->regmap, TSC2005_REG_X, &tsdata,
+TSC2005_DATA_REGS);
if (unlikely(error))
goto out;
- x = ts->spi_x.spi_rx;
- y = ts->spi_y.spi_rx;
- z1 = ts->spi_z1.spi_rx;
- z2 = ts->spi_z2.spi_rx;
-
/* validate position */
- if (unlikely(x > MAX_12BIT || y > MAX_12BIT))
+ if (unlikely(tsdata.x > MAX_12BIT || tsdata.y > MAX_12BIT))
goto out;
/* Skip reading if the pressure components are out of range */
- if (unlikely(z1 == 0 || z2 > MAX_12BIT || z1 >= z2))
+ if (unlikely(tsdata.z1 == 0 || tsdata.z2 > MAX_12BIT))
+ goto out;
+ if (unlikely(tsdata.z1 >= tsdata.z2))
goto out;
/*
@@ -301,8 +259,8 @@ static irqreturn_t tsc2005_irq_thread(int irq, voi
[PATCH 4/4] Input: tsc2005 - convert to gpiod
Convert driver to descriptor based GPIO API. Also
fix the after-probe reset GPIO state, so that the
device is not kept in reset state.
Signed-off-by: Sebastian Reichel
---
drivers/input/touchscreen/tsc2005.c | 25 -
1 file changed, 8 insertions(+), 17 deletions(-)
diff --git a/drivers/input/touchscreen/tsc2005.c
b/drivers/input/touchscreen/tsc2005.c
index 83508d8..cb08dc8 100644
--- a/drivers/input/touchscreen/tsc2005.c
+++ b/drivers/input/touchscreen/tsc2005.c
@@ -30,11 +30,11 @@
#include
#include
#include
-#include
#include
#include
#include
#include
+#include
/*
* The touchscreen interface operates as follows:
@@ -179,7 +179,7 @@ struct tsc2005 {
struct regulator*vio;
- int reset_gpio;
+ struct gpio_desc*reset_gpio;
void(*set_reset)(bool enable);
};
@@ -317,8 +317,8 @@ static void tsc2005_stop_scan(struct tsc2005 *ts)
static void tsc2005_set_reset(struct tsc2005 *ts, bool enable)
{
- if (ts->reset_gpio >= 0)
- gpio_set_value(ts->reset_gpio, enable);
+ if (ts->reset_gpio)
+ gpiod_set_value_cansleep(ts->reset_gpio, enable);
else if (ts->set_reset)
ts->set_reset(enable);
}
@@ -611,19 +611,11 @@ static int tsc2005_probe(struct spi_device *spi)
ts->esd_timeout = esd_timeout;
if (np) {
- ts->reset_gpio = of_get_named_gpio(np, "reset-gpios", 0);
- if (ts->reset_gpio == -EPROBE_DEFER)
- return ts->reset_gpio;
- if (ts->reset_gpio < 0) {
+ ts->reset_gpio = devm_gpiod_get(&spi->dev, "reset",
+ GPIOD_OUT_HIGH);
+ if (IS_ERR(ts->reset_gpio)) {
+ error = PTR_ERR(ts->reset_gpio);
dev_err(&spi->dev, "error acquiring reset gpio: %d\n",
- ts->reset_gpio);
- return ts->reset_gpio;
- }
-
- error = devm_gpio_request_one(&spi->dev, ts->reset_gpio, 0,
- "reset-gpios");
- if (error) {
- dev_err(&spi->dev, "error requesting reset gpio: %d\n",
error);
return error;
}
@@ -635,7 +627,6 @@ static int tsc2005_probe(struct spi_device *spi)
return error;
}
} else {
- ts->reset_gpio = -1;
ts->set_reset = pdata->set_reset;
}
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] Input: tsc2005 - simplify drvdata acquisition
Do not convert device to spi_device just for getting
the driver data, since spi_get_drvdata() just calls
dev_get_drvdata().
Signed-off-by: Sebastian Reichel
---
drivers/input/touchscreen/tsc2005.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/input/touchscreen/tsc2005.c
b/drivers/input/touchscreen/tsc2005.c
index 0aec45a..83508d8 100644
--- a/drivers/input/touchscreen/tsc2005.c
+++ b/drivers/input/touchscreen/tsc2005.c
@@ -354,8 +354,7 @@ static ssize_t tsc2005_selftest_show(struct device *dev,
struct device_attribute *attr,
char *buf)
{
- struct spi_device *spi = to_spi_device(dev);
- struct tsc2005 *ts = spi_get_drvdata(spi);
+ struct tsc2005 *ts = dev_get_drvdata(dev);
unsigned int temp_high;
unsigned int temp_high_orig;
unsigned int temp_high_test;
@@ -440,8 +439,7 @@ static umode_t tsc2005_attr_is_visible(struct kobject *kobj,
struct attribute *attr, int n)
{
struct device *dev = container_of(kobj, struct device, kobj);
- struct spi_device *spi = to_spi_device(dev);
- struct tsc2005 *ts = spi_get_drvdata(spi);
+ struct tsc2005 *ts = dev_get_drvdata(dev);
umode_t mode = attr->mode;
if (attr == &dev_attr_selftest.attr) {
@@ -729,8 +727,7 @@ static int tsc2005_remove(struct spi_device *spi)
static int __maybe_unused tsc2005_suspend(struct device *dev)
{
- struct spi_device *spi = to_spi_device(dev);
- struct tsc2005 *ts = spi_get_drvdata(spi);
+ struct tsc2005 *ts = dev_get_drvdata(dev);
mutex_lock(&ts->mutex);
@@ -746,8 +743,7 @@ static int __maybe_unused tsc2005_suspend(struct device
*dev)
static int __maybe_unused tsc2005_resume(struct device *dev)
{
- struct spi_device *spi = to_spi_device(dev);
- struct tsc2005 *ts = spi_get_drvdata(spi);
+ struct tsc2005 *ts = dev_get_drvdata(dev);
mutex_lock(&ts->mutex);
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] irqchip: omap-intc: improve IRQ handler
On Wed, 15 Jul 2015, Tony Lindgren wrote: > Felipe, > > * Tony Lindgren [150119 13:41]: > > * Felipe Balbi [150102 10:50]: > > > as it turns out the current IRQ number will > > > *always* be available from SIR register which > > > renders the reads of PENDING registers as plain > > > unnecessary overhead. > > > > > > In order to catch any situation where SIR reads > > > as zero, we're adding a WARN() to turn it into > > > a very verbose error and users actually report > > > it. > > > > > > With this patch average running time of > > > omap_intc_handle_irq() reduced from about 28.5us > > > to 19.8us as measured by the kernel function > > > profiler. > > > > > > Tested with BeagleBoneBlack Rev A5C. > > > > > > Signed-off-by: Felipe Balbi > > > > Jason, looks like this is not showing up in Linux next. The > > same for the changes I did for dm81xx. > > Can you please resend this to Jason? Looks like this > is still not merged. Please send it to me asap and please cc lkml on irqchip patches. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 00/11] USB: OTG/DRD Core functionality
On 13/07/15 16:04, Li Jun wrote: > On Mon, Jul 13, 2015 at 01:24:05PM +0300, Roger Quadros wrote: >> Hi, >> >> On 10/07/15 10:58, Li Jun wrote: >>> On Wed, Jul 08, 2015 at 01:19:26PM +0300, Roger Quadros wrote: Hi, This series centralizes OTG/Dual-role functionality in the kernel. As of now I've got Dual-role functionality working pretty reliably on dra7-evm and am437x-gp-evm. xhci side of things for OTG/DRD use are already in v4.2 >>> >>> Do you have any plan to implement OTG(HNP) on some of your platforms based >>> on >>> this OTG core? >> >> Not yet but Joao Pinto was interested to implement full OTG for dwc3 >> controllers. >> >> Would you be interested to try out one of your platforms so that we can >> address any issues early? >> >> cheers, >> -roger >> > > Yes, I am considering to try out OTG on chipidea driver for FSL i.mx6x > platform > , which will based on your OTG core and my previous gadget update patchset. Great :) > > I will comment your patchset if find any issues. Since there is still much > work > to do to complete OTG HNP/SRP, so I assume this will not be done in a short > time. Yes. My plan was to first get DRD working reliably and then add missing HNP/SRP stuff. The first user of HNP/SRP will know what issues are and what needs to be added. cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 00/11] USB: OTG/DRD Core functionality
Hi Andrew,
On 13/07/15 22:14, Andrew Bresticker wrote:
> Hi Roger,
>
> On Wed, Jul 8, 2015 at 3:19 AM, Roger Quadros wrote:
>> Usage model:
>> ---
>>
>> - The OTG controller device is assumed to be the parent of
>> the host and gadget controller. It must call usb_otg_register()
>> before populating the host and gadget devices so that the OTG
>> core is aware that it is an OTG device before the host & gadget
>> register. The OTG controller must provide struct otg_fsm_ops *
>> which will be called by the OTG core depending on OTG bus state.
>
> I'm wondering if the requirement that the OTG controller be the parent
> of the USB host/device-controllers makes sense. For some context, I'm
> working on adding dual-role support for Tegra210, specifically on a
> system with USB Type-C. On Tegra, the USB host-controller and USB
> device-controller are two separate IP blocks (XUSB host and XUSB
> device) with another, separate, IP block (XUSB padctl) for the USB PHY
> and OTG support. In the non-Type-C case, your OTG framework could
> work well, though it's debatable as to whether or not the XUSB padctl
> device should be a parent to the XUSB host/device-controller devices
> (currently it isn't - it's just a PHY provider). But in the Type-C
> case, it's an off-chip embedded controller that determines the
> dual-role status of the Type-C port, so the above requirement doesn't
> make sense at all.
>
> My idea was to have the OTG/DRD controller explicitly specify its host
> and device controllers, so in DT, something like:
>
> otg-controller {
> ...
> device-controller = <&usb_device>;
> host-controller = <&usb_host>;
> ...
> };
>
> usb_device: usb-device@ {
> ...
> };
>
> usb_host: usb-host@... {
> ...
> };
>
> What do you think?
I agree that we need to support your use case but how to do it
is not yet clear to me.
In your above example the otg controller knows what are the host
and gadget controllers but the host/gadget devices don't
know who is their otg controller.
So the problem is that when usb_otg_register_hcd/gadget() is called
we need to get a handle to the otg controller.
One solution I see is to iterate over the registered otg_controller_list
and check if we match the host/gadget controller in there.
Then there is also a possibility that host/gadget controllers get
registered before the OTG controller. Then we can't know for sure if
the host/gadget controller was meant for dual-role operation or not
and it will resort to single role operation.
Any idea to prevent the above situation?
Maybe we need to add some logic in host/gadget cores to check if the port
is meant for dual-role use and defer probe if OTG controller is not yet
registered?
cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 04/11] otg-fsm: move usb_bus_start_enum into otg-fsm->ops
On 14/07/15 03:34, Peter Chen wrote:
> On Mon, Jul 13, 2015 at 01:13:54PM +0300, Roger Quadros wrote:
>> Peter,
>>
>> On 13/07/15 04:58, Peter Chen wrote:
>>> On Wed, Jul 08, 2015 at 01:19:30PM +0300, Roger Quadros wrote:
This is to prevent missing symbol build error if OTG is
enabled (built-in) and HCD core (CONFIG_USB) is module.
>>>
>>> We may let the OTG-DRD/OTG-FSM depends on CONFIG_USB to fix it.
>>
>> CONFIG_OTG already depends on CONFIG_USB as it is a sub-option of
>> CONFIG_USB. It doesn't depend on CONFIG_USB_GADGET and that can
>> be fixed.
>>
>> But dependency is not the problem here. Symbols not available to
>> OTG driver when USB/GADGET is 'm' is the problem.
>>
>> e.g.
>> CONFIG_USB_OTG is always built-in.
>> we need to work if CONFIG_USB is 'm'/'y'
>> _and_ if CONFIG_USB_GADGET is 'm'/'y'
>>
>
> below should fix this issue, but we may need to make some
> changes for code which are defined by CONFIG_USB_OTG.
>
> diff --git a/drivers/usb/core/Kconfig b/drivers/usb/core/Kconfig
> index a99c89e..5e374ad 100644
> --- a/drivers/usb/core/Kconfig
> +++ b/drivers/usb/core/Kconfig
> @@ -42,8 +42,9 @@ config USB_DYNAMIC_MINORS
> If you are unsure about this, say N here.
>
> config USB_OTG
> - bool "OTG support"
> + tristate "OTG support"
> depends on PM
> + depends on USB && USB_GADGET
> default n
>help
> The most notable feature of
> USB OTG is support for a
With this USB_OTG will become 'm' when either USB or USB_GADGET is m
and will break if either USB or USB_GADGET is made y as all OTG core
API symbols won't be available. :)
cheers,
-roger
>>
>>>
>>> Peter
>>>
Signed-off-by: Roger Quadros
---
drivers/usb/common/usb-otg-fsm.c | 6 --
drivers/usb/phy/phy-fsl-usb.c| 2 ++
include/linux/usb/otg-fsm.h | 1 +
3 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/common/usb-otg-fsm.c
b/drivers/usb/common/usb-otg-fsm.c
index 1873eb3..156fd25 100644
--- a/drivers/usb/common/usb-otg-fsm.c
+++ b/drivers/usb/common/usb-otg-fsm.c
@@ -166,8 +166,10 @@ static int otg_set_state(struct otg_fsm *fsm, enum
usb_otg_state new_state)
otg_loc_conn(fsm, 0);
otg_loc_sof(fsm, 1);
otg_set_protocol(fsm, PROTO_HOST);
- usb_bus_start_enum(fsm->otg->host,
- fsm->otg->host->otg_port);
+ if (fsm->ops->start_enum) {
+ fsm->ops->start_enum(fsm->otg->host,
+ fsm->otg->host->otg_port);
+ }
break;
case OTG_STATE_A_IDLE:
otg_drv_vbus(fsm, 0);
diff --git a/drivers/usb/phy/phy-fsl-usb.c b/drivers/usb/phy/phy-fsl-usb.c
index ee3f2c2..19541ed 100644
--- a/drivers/usb/phy/phy-fsl-usb.c
+++ b/drivers/usb/phy/phy-fsl-usb.c
@@ -783,6 +783,8 @@ static struct otg_fsm_ops fsl_otg_ops = {
.start_host = fsl_otg_start_host,
.start_gadget = fsl_otg_start_gadget,
+
+ .start_enum = usb_bus_start_enum,
};
/* Initialize the global variable fsl_otg_dev and request IRQ for OTG */
diff --git a/include/linux/usb/otg-fsm.h b/include/linux/usb/otg-fsm.h
index c631dde..22d8baa 100644
--- a/include/linux/usb/otg-fsm.h
+++ b/include/linux/usb/otg-fsm.h
@@ -198,6 +198,7 @@ struct otg_fsm_ops {
void(*del_timer)(struct otg_fsm *fsm, enum otg_fsm_timer timer);
int (*start_host)(struct otg_fsm *fsm, int on);
int (*start_gadget)(struct otg_fsm *fsm, int on);
+ int (*start_enum)(struct usb_bus *bus, unsigned port_num);
};
--
2.1.4
>>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: DRA7: Provide proper IO map table
On 07/15/2015 01:26 AM, Tony Lindgren wrote:
> * Nishanth Menon [150622 08:14]:
>> DRA7 uses OMAP5 IO table at the moment. This is purely spurious since
>> the OMAP5 and DRA7 register maps are different in many aspects.
>>
>> AM57xx/DRA7 TRM Reference: http://www.ti.com/lit/ug/spruhz6/spruhz6.pdf
>>
>> NOTE: Most of the drivers are already doing ioremap, so, there should'nt
>> be any functional improvement involved here, other than making the
>> initial iotable more accurate.
>>
>> Fixes: a3a9384a1157 ("ARM: DRA7: Reuse io tables and add a new .init_early")
>> Signed-off-by: Nishanth Menon
>
> Is this needed for v4.2-rc or can this wait for v4.3 merge window?
It can wait till 4.3 for sure. there is no known functional issue traced
to this.
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/3] ARM: dts: dra7: Add syscon-pllreset syscon to SATA PHY
Hi, On 15/07/15 15:07, Tony Lindgren wrote: > * Kishon Vijay Abraham I [150715 04:24]: >> Hi Roger, >> >> On Tuesday 02 June 2015 02:40 PM, Roger Quadros wrote: >>> This register is required to be passed to the SATA PHY driver >>> to workaround errata i783 (SATA Lockup After SATA DPLL Unlock/Relock). >>> >>> Signed-off-by: Roger Quadros >>> Signed-off-by: Sekhar Nori >>> --- >>> arch/arm/boot/dts/dra7.dtsi | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi >>> index f03a091..260f300 100644 >>> --- a/arch/arm/boot/dts/dra7.dtsi >>> +++ b/arch/arm/boot/dts/dra7.dtsi >>> @@ -1135,6 +1135,7 @@ >>> ctrl-module = <&omap_control_sata>; >>> clocks = <&sys_clkin1>, <&sata_ref_clk>; >>> clock-names = "sysclk", "refclk"; >>> + syscon-pllreset = <&dra7_ctrl_core 0x3fc>; >> >> I think all users of syscon should be made child node of scm_conf. Tony and >> Tero, is that right? It can't be child of scm_conf as the address is outside it's range. Looks like I have to add a new child to scm node that maps beyond the dra7_pmx_core padconf address range. >> >> If so, then we might have to modify the driver too. > > Yeah there should not be much need to use syscon outside scm_conf > area and for I2C devices. If there's some other misc register area > in dra7 in addition to scm_conf then it might make sense to use it. > > But in general, for the SCM registers, just a normal loadable kernel > driver module doing of_ioremap on a dedicated range of registers is > always a better option :) > Lets take for example this register CTRL_CORE_SMA_SW_0. It has the SATA PLL_SOFT_RESET bit, EMIF1/2 gating control bits and ISOLATE bit. I don't see this fitting in any driver except the syscon approach. cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap dts changes for v4.3, part 1
On Wed, Jul 15, 2015 at 04:49:36AM -0700, Tony Lindgren wrote: > The following changes since commit bc0195aad0daa2ad5b0d76cce22b167bc3435590: > > Linux 4.2-rc2 (2015-07-12 15:10:30 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap > tags/omap-for-v4.3/dt-pt1 > > for you to fetch changes up to 80edaaead3687b47ba3760588306937439ebd7bd: > > ARM: dts: am335x-evm: Switch using simple-audio-card for audio support > (2015-07-14 04:28:25 -0700) Merged, thanks. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap fixes against v4.2-rc2
On Wed, Jul 15, 2015 at 03:50:53AM -0700, Tony Lindgren wrote: > The following changes since commit bc0195aad0daa2ad5b0d76cce22b167bc3435590: > > Linux 4.2-rc2 (2015-07-12 15:10:30 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap > tags/omap-for-v4.2/fixes-rc2-v2 > > for you to fetch changes up to 9908ac3daa3da2d236b5406b95d0865ddb8b29c4: > > ARM: dts: Correct audio input route & set mic bias for am335x-pepper > (2015-07-15 03:03:01 -0700) > > > Fixes for omaps, all dts changes except for one: > > - Fix up LCD panel name for overo boards > > - Three fixes for pepper board for regulators, freqeuncy > scaling and audio input. Note that there is still one > issue being worked on for booting with multi_v7_defconfig > > - Add missing #iommu-cells for omap4 and 5 > > - Add missing HAVE_ARM_SCU for am43xx Merged, thanks. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/3] ARM: dts: dra7: Add syscon-pllreset syscon to SATA PHY
On 07/15/2015 04:47 PM, Roger Quadros wrote: Hi, On 15/07/15 15:07, Tony Lindgren wrote: * Kishon Vijay Abraham I [150715 04:24]: Hi Roger, On Tuesday 02 June 2015 02:40 PM, Roger Quadros wrote: This register is required to be passed to the SATA PHY driver to workaround errata i783 (SATA Lockup After SATA DPLL Unlock/Relock). Signed-off-by: Roger Quadros Signed-off-by: Sekhar Nori --- arch/arm/boot/dts/dra7.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi index f03a091..260f300 100644 --- a/arch/arm/boot/dts/dra7.dtsi +++ b/arch/arm/boot/dts/dra7.dtsi @@ -1135,6 +1135,7 @@ ctrl-module = <&omap_control_sata>; clocks = <&sys_clkin1>, <&sata_ref_clk>; clock-names = "sysclk", "refclk"; + syscon-pllreset = <&dra7_ctrl_core 0x3fc>; I think all users of syscon should be made child node of scm_conf. Tony and Tero, is that right? It can't be child of scm_conf as the address is outside it's range. Looks like I have to add a new child to scm node that maps beyond the dra7_pmx_core padconf address range. If so, then we might have to modify the driver too. Yeah there should not be much need to use syscon outside scm_conf area and for I2C devices. If there's some other misc register area in dra7 in addition to scm_conf then it might make sense to use it. But in general, for the SCM registers, just a normal loadable kernel driver module doing of_ioremap on a dedicated range of registers is always a better option :) Lets take for example this register CTRL_CORE_SMA_SW_0. It has the SATA PLL_SOFT_RESET bit, EMIF1/2 gating control bits and ISOLATE bit. I don't see this fitting in any driver except the syscon approach. cheers, -roger Yea I think scm_conf can generally contain lots of weird registers that can have multiple users / use-cases. This is the junk-yard of SoC features the designers had no idea where to put them; so they put it under scm_conf. I'd say in some cases we are probably forced to map to it from other drivers, this is one of the reasons it is a syscon map in the first place, and generally speaking, they should not be children of scm_conf in the DT layout. You could probably add a "dummy" node under scm_conf which maps to the scm register, and which you would refer to from the sata driver. -Tero -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: remoteproc: wkup_m3: suspend/resume for am335x bbone
Hi, just realized that I need these patches patches as well: https://github.com/dgerlach/linux-pm/commits/pm-v4.1-rc4-amx3-suspend I tried to merge that branch into current v4.2-rc2, but I made quite a mess out of it. I'll try probably try cherry-picking next or will just wait for an update so ignore my previous mail, :-) 2015-07-15 11:23 GMT+02:00 Andreas Fenkart : > cat /sys/power/state is empty, should be 'mem' > > I applied these patches: > https://lkml.org/lkml/2015/4/1/542 > > here suspend support in kernel-config (shall I append the full .config?) > # > # Power management options > # > CONFIG_SUSPEND=y > CONFIG_SUSPEND_FREEZER=y > # CONFIG_HIBERNATION is not set > CONFIG_PM_SLEEP=y > # CONFIG_PM_AUTOSLEEP is not set > # CONFIG_PM_WAKELOCKS is not set > CONFIG_PM=y > CONFIG_PM_DEBUG=y > # CONFIG_PM_ADVANCED_DEBUG is not set > # CONFIG_PM_TEST_SUSPEND is not set > CONFIG_PM_SLEEP_DEBUG=y > # CONFIG_APM_EMULATION is not set > CONFIG_PM_OPP=y > CONFIG_PM_CLK=y > # CONFIG_WQ_POWER_EFFICIENT_DEFAULT is not set > CONFIG_CPU_PM=y > CONFIG_ARCH_SUSPEND_POSSIBLE=y > CONFIG_ARM_CPU_SUSPEND=y > CONFIG_ARCH_HIBERNATION_POSSIBLE=y > CONFIG_NET=y > > > [1.642524] remoteproc0: wkup_m3 is available > [1.647570] remoteproc0: Note: remoteproc is still under > development and considered experimental. > [1.657068] remoteproc0: THE BINARY FORMAT IS NOT YET FINALIZED, > and backward compatibility isn't yet guaranteed. > [1.668418] remoteproc0: unsupported resource 4 > [1.673275] remoteproc0: unsupported resource 4 > [1.685122] usbcore: registered new interface driver snd-usb-audio > [1.691835] remoteproc0: unsupported resource 4 > [1.696777] remoteproc0: unsupported resource 4 > > tip of m3 firmware > git://arago-project.org/git/projects/am33x-cm3.git > Sun Mar 9 23:52:27 2014 -0700 32cf44e CM3: AM43XX: Add Tamper swakeup settings > > Do I need to update my m3 firmware? > > kind regards, > Andreas Fenkart -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] ARM: move heavy barrier support out of line
The existing memory barrier macro causes a significant amount of code
to be inserted inline at every call site. For example, in
gpio_set_irq_type(), we have this for mb():
c0344c08: f57ff04edsb st
c0344c0c: e59f8190ldr r8, [pc, #400] ; c0344da4
c0344c10: e3590004cmp r9, #4
c0344c14: e5983014ldr r3, [r8, #20]
c0344c18: 0a54beq c0344d70
c0344c1c: e353cmp r3, #0
c0344c20: 0a04beq c0344c38
c0344c24: e50b2030str r2, [fp, #-48] ; 0xffd0
c0344c28: e50bc034str ip, [fp, #-52] ; 0xffcc
c0344c2c: e12fff33blx r3
c0344c30: e51bc034ldr ip, [fp, #-52] ; 0xffcc
c0344c34: e51b2030ldr r2, [fp, #-48] ; 0xffd0
c0344c38: e5963004ldr r3, [r6, #4]
Moving the outer_cache_sync() call out of line reduces the impact of
the barrier:
c0344968: f57ff04edsb st
c034496c: e35a0004cmp sl, #4
c0344970: e50b2030str r2, [fp, #-48] ; 0xffd0
c0344974: 0a44beq c0344a8c
c0344978: ebf363ddbl c001d8f4
c034497c: e5953004ldr r3, [r5, #4]
This should reduce the cache footprint of this code. Overall, this
results in a reduction of around 20K in the kernel size:
textdata bss dec hex filename
10773970 667392 10369656 21811018 14ccf4a ../build/imx6/vmlinux-old
10754219 667392 10369656 21791267 14c8223 ../build/imx6/vmlinux-new
Another advantage to this approach is that we can finally resolve the
issue of SoCs which have their own memory barrier requirements within
multiplatform kernels (such as OMAP.) Here, the bus interconnects
need additional handling to ensure that writes become visible in the
correct order (eg, between dma_map() operations, writes to DMA
coherent memory, and MMIO accesses.)
Signed-off-by: Russell King
---
arch/arm/include/asm/barrier.h| 12 +---
arch/arm/include/asm/outercache.h | 17 -
arch/arm/kernel/irq.c | 1 +
arch/arm/mach-prima2/pm.c | 1 +
arch/arm/mach-ux500/cache-l2x0.c | 1 +
arch/arm/mm/Kconfig | 4
arch/arm/mm/flush.c | 11 +++
7 files changed, 27 insertions(+), 20 deletions(-)
diff --git a/arch/arm/include/asm/barrier.h b/arch/arm/include/asm/barrier.h
index 6c2327e1c732..fea99b0e2087 100644
--- a/arch/arm/include/asm/barrier.h
+++ b/arch/arm/include/asm/barrier.h
@@ -2,7 +2,6 @@
#define __ASM_BARRIER_H
#ifndef __ASSEMBLY__
-#include
#define nop() __asm__ __volatile__("mov\tr0,r0\t@ nop\n\t");
@@ -37,12 +36,19 @@
#define dmb(x) __asm__ __volatile__ ("" : : : "memory")
#endif
+#ifdef CONFIG_ARM_HEAVY_MB
+extern void arm_heavy_mb(void);
+#define __arm_heavy_mb(x...) do { dsb(x); arm_heavy_mb(); } while (0)
+#else
+#define __arm_heavy_mb(x...) dsb(x)
+#endif
+
#ifdef CONFIG_ARCH_HAS_BARRIERS
#include
#elif defined(CONFIG_ARM_DMA_MEM_BUFFERABLE) || defined(CONFIG_SMP)
-#define mb() do { dsb(); outer_sync(); } while (0)
+#define mb() __arm_heavy_mb()
#define rmb() dsb()
-#define wmb() do { dsb(st); outer_sync(); } while (0)
+#define wmb() __arm_heavy_mb(st)
#define dma_rmb() dmb(osh)
#define dma_wmb() dmb(oshst)
#else
diff --git a/arch/arm/include/asm/outercache.h
b/arch/arm/include/asm/outercache.h
index 563b92fc2f41..c2bf24f40177 100644
--- a/arch/arm/include/asm/outercache.h
+++ b/arch/arm/include/asm/outercache.h
@@ -129,21 +129,4 @@ static inline void outer_resume(void) { }
#endif
-#ifdef CONFIG_OUTER_CACHE_SYNC
-/**
- * outer_sync - perform a sync point for outer cache
- *
- * Ensure that all outer cache operations are complete and any store
- * buffers are drained.
- */
-static inline void outer_sync(void)
-{
- if (outer_cache.sync)
- outer_cache.sync();
-}
-#else
-static inline void outer_sync(void)
-{ }
-#endif
-
#endif /* __ASM_OUTERCACHE_H */
diff --git a/arch/arm/kernel/irq.c b/arch/arm/kernel/irq.c
index 350f188c92d2..b96c8ed1723a 100644
--- a/arch/arm/kernel/irq.c
+++ b/arch/arm/kernel/irq.c
@@ -39,6 +39,7 @@
#include
#include
+#include
#include
#include
#include
diff --git a/arch/arm/mach-prima2/pm.c b/arch/arm/mach-prima2/pm.c
index d99d08eeb966..83e94c95e314 100644
--- a/arch/arm/mach-prima2/pm.c
+++ b/arch/arm/mach-prima2/pm.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include
diff --git a/arch/arm/mach-ux500/cache-l2x0.c b/arch/arm/mach-ux500/cache-l2x0.c
index 7557bede7ae6..780bd13cd7e3 100644
--- a/arch/arm/mach-ux500/cache-l2x0.c
+++ b/arch/arm/mach-ux500/cache-l2x0.c
@@ -8,6 +8,7 @@
#include
#include
+#include
#include
#include "db8500-regs.h"
diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index 7c6b976ab8d3..df7537f1246
[PATCH 3/4] Revert "ARM: OMAP4: remove dead kconfig option OMAP4_ERRATA_I688"
This reverts commit 606da4826b89b044b51e3a84958b802204cfe4c7.
We actually need this code for proper behaviour of OMAP4, and it needs
fixing a different way other than just removing the code. Disabling
code which is necessary in the hopes of persuing multiplatform kernels
is a stupid approach.
Signed-off-by: Russell King
---
arch/arm/mach-omap2/Kconfig| 21
arch/arm/mach-omap2/common.c | 1 +
arch/arm/mach-omap2/common.h | 3 ++
arch/arm/mach-omap2/io.c | 2 ++
arch/arm/mach-omap2/omap-secure.h | 7
arch/arm/mach-omap2/omap4-common.c | 69 ++
arch/arm/mach-omap2/sleep44xx.S| 2 ++
7 files changed, 105 insertions(+)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index ecc04ff13e95..2128441430ad 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -240,6 +240,27 @@ config OMAP3_SDRC_AC_TIMING
wish to say no. Selecting yes without understanding what is
going on could result in system crashes;
+config OMAP4_ERRATA_I688
+ bool "OMAP4 errata: Async Bridge Corruption"
+ depends on (ARCH_OMAP4 || SOC_OMAP5) && !ARCH_MULTIPLATFORM
+ select ARCH_HAS_BARRIERS
+ help
+ If a data is stalled inside asynchronous bridge because of back
+ pressure, it may be accepted multiple times, creating pointer
+ misalignment that will corrupt next transfers on that data path
+ until next reset of the system (No recovery procedure once the
+ issue is hit, the path remains consistently broken). Async bridge
+ can be found on path between MPU to EMIF and MPU to L3 interconnect.
+ This situation can happen only when the idle is initiated by a
+ Master Request Disconnection (which is trigged by software when
+ executing WFI on CPU).
+ The work-around for this errata needs all the initiators connected
+ through async bridge must ensure that data path is properly drained
+ before issuing WFI. This condition will be met if one Strongly ordered
+ access is performed to the target right before executing the WFI.
+ In MPU case, L3 T2ASYNC FIFO and DDR T2ASYNC FIFO needs to be drained.
+ IO barrier ensure that there is no synchronisation loss on initiators
+ operating on both interconnect port simultaneously.
endmenu
endif
diff --git a/arch/arm/mach-omap2/common.c b/arch/arm/mach-omap2/common.c
index eae6a0e87c90..484cdadfb187 100644
--- a/arch/arm/mach-omap2/common.c
+++ b/arch/arm/mach-omap2/common.c
@@ -30,4 +30,5 @@ int __weak omap_secure_ram_reserve_memblock(void)
void __init omap_reserve(void)
{
omap_secure_ram_reserve_memblock();
+ omap_barrier_reserve_memblock();
}
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index cf3cf22ecd42..46e24581d624 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -200,6 +200,9 @@ void __init omap4_map_io(void);
void __init omap5_map_io(void);
void __init ti81xx_map_io(void);
+/* omap_barriers_init() is OMAP4 only */
+void omap_barriers_init(void);
+
/**
* omap_test_timeout - busy-loop, testing a condition
* @cond: condition to test until it evaluates to true
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 820dde8b5b04..7743e3672f98 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -306,6 +306,7 @@ void __init am33xx_map_io(void)
void __init omap4_map_io(void)
{
iotable_init(omap44xx_io_desc, ARRAY_SIZE(omap44xx_io_desc));
+ omap_barriers_init();
}
#endif
@@ -313,6 +314,7 @@ void __init omap4_map_io(void)
void __init omap5_map_io(void)
{
iotable_init(omap54xx_io_desc, ARRAY_SIZE(omap54xx_io_desc));
+ omap_barriers_init();
}
#endif
/*
diff --git a/arch/arm/mach-omap2/omap-secure.h
b/arch/arm/mach-omap2/omap-secure.h
index af2851fbcdf0..dec2b05d184b 100644
--- a/arch/arm/mach-omap2/omap-secure.h
+++ b/arch/arm/mach-omap2/omap-secure.h
@@ -70,6 +70,13 @@ extern u32 rx51_secure_dispatcher(u32 idx, u32 process, u32
flag, u32 nargs,
extern u32 rx51_secure_update_aux_cr(u32 set_bits, u32 clear_bits);
extern u32 rx51_secure_rng_call(u32 ptr, u32 count, u32 flag);
+#ifdef CONFIG_OMAP4_ERRATA_I688
+extern int omap_barrier_reserve_memblock(void);
+#else
+static inline void omap_barrier_reserve_memblock(void)
+{ }
+#endif
+
#ifdef CONFIG_SOC_HAS_REALTIME_COUNTER
void set_cntfreq(void);
#else
diff --git a/arch/arm/mach-omap2/omap4-common.c
b/arch/arm/mach-omap2/omap4-common.c
index 16350eefa66c..7bb116a6f86f 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -51,6 +51,75 @@ static void __iomem *twd_base;
#define IRQ_LOCALTIMER 29
+#ifdef CONFIG_OMAP4_ERRATA_I688
+/* Used to implement memory barrier on DRAM path */
+#define OMAP4_DRAM_BARRIER_VA 0xfe60
+
+
[PATCH 0/4] Fix OMAP4 barrier support
OMAP4 (and other TI CPUs) allow for weak ordering of writes through different buses in their interconnects. In order to ensure that accesses are performed in the correct order, we need to extend some of the kernel barriers to ensure that the bus interconnects are correctly ordered. As an example, it is possible for the following code sequence: cpu = dma_alloc_coherent(dev, ..., &dma); *cpu = 1; writel(dma, dev_addr); Normal kernel semantics ensures that the write to "*cpu" will become visible at the ARM domain boundary before the write to dev_addr. However, because of the TI interconnects, it is possible for the write to dev_addr to hit the peripheral before the write to "*cpu" hits memory. Thus, if the write to the device causes the device to attempt to read from "*cpu" (which could be via a different path) the device won't see that write. Hence, we need to extend the barriers to ensure proper ordering further down the bus chain than we do already to the L2 cache. arch/arm/include/asm/barrier.h | 13 ++- arch/arm/include/asm/outercache.h | 17 arch/arm/kernel/irq.c | 1 + arch/arm/mach-omap2/Kconfig | 7 ++ arch/arm/mach-omap2/common.c| 1 + arch/arm/mach-omap2/common.h| 9 +++ arch/arm/mach-omap2/include/mach/barriers.h | 33 arch/arm/mach-omap2/io.c| 2 + arch/arm/mach-omap2/omap4-common.c | 121 arch/arm/mach-omap2/sleep44xx.S | 8 +- arch/arm/mach-prima2/pm.c | 1 + arch/arm/mach-ux500/cache-l2x0.c| 1 + arch/arm/mm/Kconfig | 4 + arch/arm/mm/flush.c | 15 14 files changed, 175 insertions(+), 58 deletions(-) -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] ARM: omap2: restore OMAP4 barrier behaviour
Restore the OMAP4 barrier behaviour using the new implementation which
allows multiplatform systems to hook into the mb() and wmb() ARM
implementations to perform any necessary additional barrier maintanence.
Signed-off-by: Russell King
---
arch/arm/mach-omap2/Kconfig | 28 +++--
arch/arm/mach-omap2/common.h| 12 +++-
arch/arm/mach-omap2/include/mach/barriers.h | 33 ---
arch/arm/mach-omap2/omap-secure.h | 7 ---
arch/arm/mach-omap2/omap4-common.c | 90 +++--
arch/arm/mach-omap2/sleep44xx.S | 10 +---
6 files changed, 90 insertions(+), 90 deletions(-)
delete mode 100644 arch/arm/mach-omap2/include/mach/barriers.h
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 2128441430ad..8427997e09c4 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -29,6 +29,7 @@ config ARCH_OMAP4
select HAVE_ARM_SCU if SMP
select HAVE_ARM_TWD if SMP
select OMAP_INTERCONNECT
+ select OMAP_INTERCONNECT_BARRIER
select PL310_ERRATA_588369 if CACHE_L2X0
select PL310_ERRATA_727915 if CACHE_L2X0
select PM_OPP if PM
@@ -46,6 +47,7 @@ config SOC_OMAP5
select HAVE_ARM_TWD if SMP
select HAVE_ARM_ARCH_TIMER
select ARM_ERRATA_798181 if SMP
+ select OMAP_INTERCONNECT_BARRIER
config SOC_AM33XX
bool "TI AM33XX"
@@ -70,6 +72,7 @@ config SOC_DRA7XX
select HAVE_ARM_ARCH_TIMER
select IRQ_CROSSBAR
select ARM_ERRATA_798181 if SMP
+ select OMAP_INTERCONNECT_BARRIER
config ARCH_OMAP2PLUS
bool
@@ -91,6 +94,10 @@ config ARCH_OMAP2PLUS
help
Systems based on OMAP2, OMAP3, OMAP4 or OMAP5
+config OMAP_INTERCONNECT_BARRIER
+ bool
+ select ARM_HEAVY_MB
+
if ARCH_OMAP2PLUS
@@ -240,27 +247,6 @@ config OMAP3_SDRC_AC_TIMING
wish to say no. Selecting yes without understanding what is
going on could result in system crashes;
-config OMAP4_ERRATA_I688
- bool "OMAP4 errata: Async Bridge Corruption"
- depends on (ARCH_OMAP4 || SOC_OMAP5) && !ARCH_MULTIPLATFORM
- select ARCH_HAS_BARRIERS
- help
- If a data is stalled inside asynchronous bridge because of back
- pressure, it may be accepted multiple times, creating pointer
- misalignment that will corrupt next transfers on that data path
- until next reset of the system (No recovery procedure once the
- issue is hit, the path remains consistently broken). Async bridge
- can be found on path between MPU to EMIF and MPU to L3 interconnect.
- This situation can happen only when the idle is initiated by a
- Master Request Disconnection (which is trigged by software when
- executing WFI on CPU).
- The work-around for this errata needs all the initiators connected
- through async bridge must ensure that data path is properly drained
- before issuing WFI. This condition will be met if one Strongly ordered
- access is performed to the target right before executing the WFI.
- In MPU case, L3 T2ASYNC FIFO and DDR T2ASYNC FIFO needs to be drained.
- IO barrier ensure that there is no synchronisation loss on initiators
- operating on both interconnect port simultaneously.
endmenu
endif
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 46e24581d624..82f88b4ec15f 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -189,6 +189,15 @@ static inline void omap44xx_restart(enum reboot_mode mode,
const char *cmd)
}
#endif
+#ifdef CONFIG_OMAP_INTERCONNECT_BARRIER
+void omap_barrier_reserve_memblock(void);
+void omap_barriers_init(void);
+#else
+static inline void omap_barrier_reserve_memblock(void)
+{
+}
+#endif
+
/* This gets called from mach-omap2/io.c, do not call this */
void __init omap2_set_globals_tap(u32 class, void __iomem *tap);
@@ -200,9 +209,6 @@ void __init omap4_map_io(void);
void __init omap5_map_io(void);
void __init ti81xx_map_io(void);
-/* omap_barriers_init() is OMAP4 only */
-void omap_barriers_init(void);
-
/**
* omap_test_timeout - busy-loop, testing a condition
* @cond: condition to test until it evaluates to true
diff --git a/arch/arm/mach-omap2/include/mach/barriers.h
b/arch/arm/mach-omap2/include/mach/barriers.h
deleted file mode 100644
index 1c582a8592b9..
--- a/arch/arm/mach-omap2/include/mach/barriers.h
+++ /dev/null
@@ -1,33 +0,0 @@
-/*
- * OMAP memory barrier header.
- *
- * Copyright (C) 2011 Texas Instruments, Inc.
- * Santosh Shilimkar
- * Richard Woodruff
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be usef
[PATCH 2/4] ARM: add soc memory barrier extension
Add an extension to the heavy barrier code to allow a SoC specific
memory barrier function to be provided. This is needed for platforms
where the interconnect has weak ordering, and thus needs assistance
to ensure that memory writes are properly visible in the correct order
to other parts of the system.
Signed-off-by: Russell King
---
arch/arm/include/asm/barrier.h | 1 +
arch/arm/mm/flush.c| 4
2 files changed, 5 insertions(+)
diff --git a/arch/arm/include/asm/barrier.h b/arch/arm/include/asm/barrier.h
index fea99b0e2087..3d8f1d3ad9a7 100644
--- a/arch/arm/include/asm/barrier.h
+++ b/arch/arm/include/asm/barrier.h
@@ -37,6 +37,7 @@
#endif
#ifdef CONFIG_ARM_HEAVY_MB
+extern void (*soc_mb)(void);
extern void arm_heavy_mb(void);
#define __arm_heavy_mb(x...) do { dsb(x); arm_heavy_mb(); } while (0)
#else
diff --git a/arch/arm/mm/flush.c b/arch/arm/mm/flush.c
index ce6c2960d5ac..1ec8e7590fc6 100644
--- a/arch/arm/mm/flush.c
+++ b/arch/arm/mm/flush.c
@@ -22,12 +22,16 @@
#include "mm.h"
#ifdef CONFIG_ARM_HEAVY_MB
+void (*soc_mb)(void);
+
void arm_heavy_mb(void)
{
#ifdef CONFIG_OUTER_CACHE_SYNC
if (outer_cache.sync)
outer_cache.sync();
#endif
+ if (soc_mb)
+ soc_mb();
}
EXPORT_SYMBOL(arm_heavy_mb);
#endif
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux 4.2-rc1 broken Nokia N900
Hi! > > Ok, so: > > > > 4.2-rc1 worked for me, IIRC. > > This does not make sense. > > Nothing has changed in drivers/spi between these versions. > Are you sure that 4.2-rc1 worked for you? Tested again: yes, I have 4.2-rc1 booted on the device... based on Linus' 1c4c7159ed2468f3ac4ce5a7f08d79663d381a93 . I can push the configs and trees to some public place. > > 4.2-rc2 oopses a lot. > > > > 4.2-rc2+ this patch oopses, too. I don't have serial console, so it is > > hard to tell if it is the same oops. But... I'm not sure I'm getting the same oops. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
OMAP baseline test results for v4.2-rc2
Here are some basic OMAP test results for Linux v4.2-rc2. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v4.2-rc2/20150714130012/ Test summary Build: uImage: Pass ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only Build: uImage+dtb: Pass (13/13): omap2plus_defconfig_am33xx_only/am335x-bone, omap2plus_defconfig/omap4-panda, omap2plus_defconfig/omap4-panda-es, omap2plus_defconfig/omap4-var-stk-om44, omap2plus_defconfig/omap3-evm-37xx, omap2plus_defconfig_n800_only_a/omap2420-n800, omap2plus_defconfig/omap2430-sdp, omap2plus_defconfig/am3517-evm, omap2plus_defconfig/omap3-beagle, omap2plus_defconfig/omap3-beagle-xm, omap2plus_defconfig/omap3-sbc-t3517, omap2plus_defconfig/omap5-uevm, omap2plus_defconfig/omap5-sbc-t54 Build: zImage: Pass (17/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, omap2plus_defconfig_n800_only_a, omap2plus_defconfig_n800_multi_omap2xxx, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, omap2plus_defconfig_omap5_only, omap2plus_defconfig_dra7xx_only, omap2plus_defconfig_am43xx_only, rmk_omap3430_ldp_oldconfig, rmk_omap3430_ldp_allnoconfig, rmk_omap4430_sdp_oldconfig, rmk_omap4430_sdp_allnoconfig, multi_v7_defconfig Build warnings from toolchain: uImage: (none) Build warnings from toolchain: uImage+dtb: (none) Build warnings from toolchain: zImage: FAIL (10/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, omap2plus_defconfig_omap5_only, omap2plus_defconfig_dra7xx_only, omap2plus_defconfig_am43xx_only Boot to userspace: FAIL ( 1/17): 2430sdp skip ( 3/17): 5912osk, 3517evm, 5430es2sbct54 Pass (13/17): am335xbonelt, am335xbone, 4430es2panda, 4460pandaes, 4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm, cmt3517, 5430es2uevm, 2420n800 Kernel warnings during boot to userspace: FAIL ( 2/17): 4430es2panda, cmt3517 PM: chip retention via suspend: FAIL ( 6/11): am335xbonelt, 4430es2panda, 4460varsomom, 37xxevm, 2430sdp, 5430es2uevm Pass ( 5/11): 4460pandaes, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip retention via dynamic idle: FAIL ( 6/11): am335xbonelt, 4430es2panda, 4460varsomom, 37xxevm, 2430sdp, 5430es2uevm Pass ( 5/11): 4460pandaes, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip off (except CORE, due to errata) via suspend: Pass ( 1/ 1): 3730beaglexm PM: chip off (except CORE, due to errata) via dynamic idle: Pass ( 1/ 1): 3730beaglexm PM: chip off via suspend: FAIL ( 1/ 4): 37xxevm Pass ( 3/ 4): 3530es3beagle, 3530es31beagle, 3730es12beaglexm PM: chip off via dynamic idle: FAIL ( 1/ 4): 37xxevm Pass ( 3/ 4): 3530es3beagle, 3530es31beagle, 3730es12beaglexm Kernel warnings during PM test: FAIL ( 1/17): 4430es2panda Obsolete Kconfig symbols: FAIL ( 1/20): multi_v7_defconfig vmlinux object size (delta in bytes from test_v4.2-rc1 (d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754)): text data bsstotal kernel +5700 +57 omap1_defconfig +6900 +69 omap1_defconfig_1510innovator_only +5700 +57 omap1_defconfig_5912osk_only +403 +4160 +819 multi_v7_defconfig +500 +5 omap2plus_defconfig +58500 +585 omap2plus_defconfig_2430sdp_only +10100 +101 omap2plus_defconfig_am33xx_only +10100 +101 omap2plus_defconfig_am43xx_only +410100+4101 omap2plus_defconfig_cpupm +419300+4193 omap2plus_defconfig_dra7xx_only +28900 +289 omap2plus_defconfig_n800_multi_omap2xxx +21300 +213 omap2plus_defconfig_n800_only_a +420500+4205 omap2plus_defconfig_no_pm +7700 +77 omap2plus_defconfig_omap2_4_only +2500 +25
Re: [PATCH v2 1/5] ARM: OMAP2+: DRA7: clockdomain: change l4per2_7xx_clkdm to SW_WKUP
On Wed, 3 Jun 2015, Vignesh R wrote:
> Legacy IPs like PWMSS, present under l4per2_7xx_clkdm, cannot support
> smart-idle when its clock domain is in HW_AUTO on DRA7 SoCs. Hence,
> program clock domain to SW_WKUP.
>
> Signed-off-by: Vignesh R
> ---
> arch/arm/mach-omap2/clockdomains7xx_data.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-omap2/clockdomains7xx_data.c
> b/arch/arm/mach-omap2/clockdomains7xx_data.c
> index 57d5df0c1fbd..7581e036bda6 100644
> --- a/arch/arm/mach-omap2/clockdomains7xx_data.c
> +++ b/arch/arm/mach-omap2/clockdomains7xx_data.c
> @@ -331,7 +331,7 @@ static struct clockdomain l4per2_7xx_clkdm = {
> .dep_bit = DRA7XX_L4PER2_STATDEP_SHIFT,
> .wkdep_srcs = l4per2_wkup_sleep_deps,
> .sleepdep_srcs= l4per2_wkup_sleep_deps,
> - .flags= CLKDM_CAN_HWSUP_SWSUP,
> + .flags= CLKDM_CAN_SWSUP,
> };
>
> static struct clockdomain mpu0_7xx_clkdm = {
Thanks, queued for v4.2-rc fixes. Note that I cannot test this, since I
don't have a DRA7xx board.
- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux 4.2-rc1 broken Nokia N900
On Wed, Jul 15, 2015 at 09:49:33PM +0200, Pavel Machek wrote: > Hi! > > > > Ok, so: > > > > > > 4.2-rc1 worked for me, IIRC. > > > > This does not make sense. > > > > Nothing has changed in drivers/spi between these versions. > > Are you sure that 4.2-rc1 worked for you? > > Tested again: yes, I have 4.2-rc1 booted on the device... based on > Linus' 1c4c7159ed2468f3ac4ce5a7f08d79663d381a93 . I can push the > configs and trees to some public place. > Interesting. Something very strange is happening here. Send me the links if you push your tree/config to a public repo. I would not hurt to have the same from Pali for comparison. > > > 4.2-rc2 oopses a lot. > > > > > > 4.2-rc2+ this patch oopses, too. I don't have serial console, so it is > > > hard to tell if it is the same oops. > > But... I'm not sure I'm getting the same oops. If the system is still booting, you could tell if the oopses were the same if your touchscreen and wifi do no work. > Pavel > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/5] ARM: OMAP2+: DRA7: clockdomain: change l4per2_7xx_clkdm to SW_WKUP
On Wed, 15 Jul 2015, Paul Walmsley wrote:
> On Wed, 3 Jun 2015, Vignesh R wrote:
>
> > Legacy IPs like PWMSS, present under l4per2_7xx_clkdm, cannot support
> > smart-idle when its clock domain is in HW_AUTO on DRA7 SoCs. Hence,
> > program clock domain to SW_WKUP.
> >
> > Signed-off-by: Vignesh R
> > ---
> > arch/arm/mach-omap2/clockdomains7xx_data.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/mach-omap2/clockdomains7xx_data.c
> > b/arch/arm/mach-omap2/clockdomains7xx_data.c
> > index 57d5df0c1fbd..7581e036bda6 100644
> > --- a/arch/arm/mach-omap2/clockdomains7xx_data.c
> > +++ b/arch/arm/mach-omap2/clockdomains7xx_data.c
> > @@ -331,7 +331,7 @@ static struct clockdomain l4per2_7xx_clkdm = {
> > .dep_bit = DRA7XX_L4PER2_STATDEP_SHIFT,
> > .wkdep_srcs = l4per2_wkup_sleep_deps,
> > .sleepdep_srcs= l4per2_wkup_sleep_deps,
> > - .flags= CLKDM_CAN_HWSUP_SWSUP,
> > + .flags= CLKDM_CAN_SWSUP,
> > };
> >
> > static struct clockdomain mpu0_7xx_clkdm = {
>
> Thanks, queued for v4.2-rc fixes. Note that I cannot test this, since I
> don't have a DRA7xx board.
You know, upon further thought, this doesn't make sense. If the bug
is with the PWMSS IP block specifically, why not just set
HWMOD_SWSUP_SIDLE on all the IP blocks where the hardware folks didn't
implement hardware smart-idle? At least that way, if those legacy IP
blocks aren't in use, the clockdomain can still enter hardware-supervised
idle?
This patch basically disables hardware-supervised/smart idle for all of
the IP blocks in that clockdomain?
- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL]
On 07/15, Tero Kristo wrote: > Hi Stephen, Mike, > > Here is the updated pull-request based on Stephen's request. This is > on top of 4.1-rc2. The branch is force updated version of the one > Stephen tried yesterday, the old one contained the minor build > issues present on v3 of the patch set. > > I did a quick try of merging this branch on top of 4.2-rc2 and it > works fine without any conflicts. > Thanks. Pulled into clk-next. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: remoteproc: wkup_m3: suspend/resume for am335x bbone
Andreas, On 07/15/2015 11:19 AM, Andreas Fenkart wrote: > Hi, > > just realized that I need these patches patches as well: > https://github.com/dgerlach/linux-pm/commits/pm-v4.1-rc4-amx3-suspend > > I tried to merge that branch into current v4.2-rc2, but I made quite a mess > out > of it. I'll try probably try cherry-picking next or will just wait for an > update Yes, there are some additional patches, wkup_m3_rproc is just part of the whole collection. However I did rebase my pm branch on v4.2-rc2 today in preparation of sending the next series so you can check that out here: https://github.com/dgerlach/linux-pm/tree/pm-v4.2-rc2-amx3-suspend. The firmware you need can be found here: https://git.ti.com/ti-cm3-pm-firmware/amx3-cm3/commits/next-upstream. Regards, Dave > > so ignore my previous mail, :-) > > > 2015-07-15 11:23 GMT+02:00 Andreas Fenkart : >> cat /sys/power/state is empty, should be 'mem' >> >> I applied these patches: >> https://lkml.org/lkml/2015/4/1/542 >> >> here suspend support in kernel-config (shall I append the full .config?) >> # >> # Power management options >> # >> CONFIG_SUSPEND=y >> CONFIG_SUSPEND_FREEZER=y >> # CONFIG_HIBERNATION is not set >> CONFIG_PM_SLEEP=y >> # CONFIG_PM_AUTOSLEEP is not set >> # CONFIG_PM_WAKELOCKS is not set >> CONFIG_PM=y >> CONFIG_PM_DEBUG=y >> # CONFIG_PM_ADVANCED_DEBUG is not set >> # CONFIG_PM_TEST_SUSPEND is not set >> CONFIG_PM_SLEEP_DEBUG=y >> # CONFIG_APM_EMULATION is not set >> CONFIG_PM_OPP=y >> CONFIG_PM_CLK=y >> # CONFIG_WQ_POWER_EFFICIENT_DEFAULT is not set >> CONFIG_CPU_PM=y >> CONFIG_ARCH_SUSPEND_POSSIBLE=y >> CONFIG_ARM_CPU_SUSPEND=y >> CONFIG_ARCH_HIBERNATION_POSSIBLE=y >> CONFIG_NET=y >> >> >> [1.642524] remoteproc0: wkup_m3 is available >> [1.647570] remoteproc0: Note: remoteproc is still under >> development and considered experimental. >> [1.657068] remoteproc0: THE BINARY FORMAT IS NOT YET FINALIZED, >> and backward compatibility isn't yet guaranteed. >> [1.668418] remoteproc0: unsupported resource 4 >> [1.673275] remoteproc0: unsupported resource 4 >> [1.685122] usbcore: registered new interface driver snd-usb-audio >> [1.691835] remoteproc0: unsupported resource 4 >> [1.696777] remoteproc0: unsupported resource 4 >> >> tip of m3 firmware >> git://arago-project.org/git/projects/am33x-cm3.git >> Sun Mar 9 23:52:27 2014 -0700 32cf44e CM3: AM43XX: Add Tamper swakeup >> settings >> >> Do I need to update my m3 firmware? >> >> kind regards, >> Andreas Fenkart -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] Input: tsc2005 - convert to regmap
Hi Sebastian,
On Wed, Jul 15, 2015 at 02:13:26PM +0200, Sebastian Reichel wrote:
> /* read the coordinates */
> - error = spi_sync(ts->spi, &ts->spi_read_msg);
> + error = regmap_bulk_read(ts->regmap, TSC2005_REG_X, &tsdata,
> + TSC2005_DATA_REGS);
> if (unlikely(error))
> goto out;
>
> - x = ts->spi_x.spi_rx;
> - y = ts->spi_y.spi_rx;
> - z1 = ts->spi_z1.spi_rx;
> - z2 = ts->spi_z2.spi_rx;
> -
> /* validate position */
> - if (unlikely(x > MAX_12BIT || y > MAX_12BIT))
> + if (unlikely(tsdata.x > MAX_12BIT || tsdata.y > MAX_12BIT))
> goto out;
>
> /* Skip reading if the pressure components are out of range */
> - if (unlikely(z1 == 0 || z2 > MAX_12BIT || z1 >= z2))
> + if (unlikely(tsdata.z1 == 0 || tsdata.z2 > MAX_12BIT))
> + goto out;
> + if (unlikely(tsdata.z1 >= tsdata.z2))
> goto out;
I guess that means that tsc2005 is (and was) endian-broken. We can't use
the data off the wire directly... So I'll drop bucnh of the changes in
this function so we can convert to CPU endianness before using.
I also got:
CC [M] drivers/input/touchscreen/tsc2005.o
Building modules, stage 2.
Kernel: arch/x86/boot/bzImage is ready (#1383)
MODPOST 1403 modules
ERROR: "devm_regmap_init_spi" [drivers/input/touchscreen/tsc2005.ko]
undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2
I guess we need "select REGMAP_SPI".
Thanks.
--
Dmitry
Input: tsc2005 - convert to regmap
From: Sebastian Reichel
Convert driver, so that it uses regmap instead of directly using
spi_transfer for all register accesses.
Signed-off-by: Sebastian Reichel
Signed-off-by: Dmitry Torokhov
---
drivers/input/touchscreen/Kconfig |9 +-
drivers/input/touchscreen/tsc2005.c | 149 ---
2 files changed, 55 insertions(+), 103 deletions(-)
diff --git a/drivers/input/touchscreen/Kconfig
b/drivers/input/touchscreen/Kconfig
index 9b3da52..c1acbbc 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -915,10 +915,11 @@ config TOUCHSCREEN_TSC_SERIO
module will be called tsc40.
config TOUCHSCREEN_TSC2005
-tristate "TSC2005 based touchscreens"
-depends on SPI_MASTER
-help
- Say Y here if you have a TSC2005 based touchscreen.
+ tristate "TSC2005 based touchscreens"
+ depends on SPI_MASTER
+ select REGMAP_SPI
+ help
+ Say Y here if you have a TSC2005 based touchscreen.
If unsure, say N.
diff --git a/drivers/input/touchscreen/tsc2005.c
b/drivers/input/touchscreen/tsc2005.c
index 2a27a1f..a04248e 100644
--- a/drivers/input/touchscreen/tsc2005.c
+++ b/drivers/input/touchscreen/tsc2005.c
@@ -34,6 +34,7 @@
#include
#include
#include
+#include
/*
* The touchscreen interface operates as follows:
@@ -120,20 +121,36 @@
#define TSC2005_SPI_MAX_SPEED_HZ 1000
#define TSC2005_PENUP_TIME_MS 40
-struct tsc2005_spi_rd {
- struct spi_transfer spi_xfer;
- u32 spi_tx;
- u32 spi_rx;
+static const struct regmap_range tsc2005_writable_ranges[] = {
+ regmap_reg_range(TSC2005_REG_AUX_HIGH, TSC2005_REG_CFR2),
};
+static const struct regmap_access_table tsc2005_writable_table = {
+ .yes_ranges = tsc2005_writable_ranges,
+ .n_yes_ranges = ARRAY_SIZE(tsc2005_writable_ranges),
+};
+
+static struct regmap_config tsc2005_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 16,
+ .reg_stride = 0x08,
+ .max_register = 0x78,
+ .read_flag_mask = TSC2005_REG_READ,
+ .wr_table = &tsc2005_writable_table,
+ .use_single_rw = true,
+};
+
+struct tsc2005_data {
+ u16 x;
+ u16 y;
+ u16 z1;
+ u16 z2;
+} __packed;
+#define TSC2005_DATA_REGS 4
+
struct tsc2005 {
struct spi_device *spi;
-
- struct spi_message spi_read_msg;
- struct tsc2005_spi_rd spi_x;
- struct tsc2005_spi_rd spi_y;
- struct tsc2005_spi_rd spi_z1;
- struct tsc2005_spi_rd spi_z2;
+ struct regmap *regmap;
struct input_dev*idev;
charphys[32];
@@ -190,62 +207,6 @@ static int tsc2005_cmd(struct tsc2005 *ts, u8 cmd)
return 0;
}
-static int tsc2005_write(struct tsc2005 *ts, u8 reg, u16 value)
-{
- u32 tx = ((reg | TSC2005_REG_PND0) << 16) | value;
- struct spi_transfer xfer = {
- .tx_buf = &tx,
- .len= 4,
- .bits_per_word = 24,
- };
- struct spi_message msg;
- int error;
-
- spi_message_init(&msg);
- spi_message_add_tail(&xfer, &msg);
-
- error = spi_sync(ts->spi, &msg);
- if (error) {
- dev_err(&ts->spi->dev,
- "%s: failed, register: %x, val
Re: [PATCH 3/4] Input: tsc2005 - simplify drvdata acquisition
On Wed, Jul 15, 2015 at 02:13:27PM +0200, Sebastian Reichel wrote: > Do not convert device to spi_device just for getting > the driver data, since spi_get_drvdata() just calls > dev_get_drvdata(). Even though at the moment they all share the same data I consider them logically different and so would prefer not to substityte one for another. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] Input: tsc2005 - convert to gpiod
On Wed, Jul 15, 2015 at 02:13:28PM +0200, Sebastian Reichel wrote:
> Convert driver to descriptor based GPIO API. Also
> fix the after-probe reset GPIO state, so that the
> device is not kept in reset state.
>
> Signed-off-by: Sebastian Reichel
> ---
> drivers/input/touchscreen/tsc2005.c | 25 -
> 1 file changed, 8 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/input/touchscreen/tsc2005.c
> b/drivers/input/touchscreen/tsc2005.c
> index 83508d8..cb08dc8 100644
> --- a/drivers/input/touchscreen/tsc2005.c
> +++ b/drivers/input/touchscreen/tsc2005.c
> @@ -30,11 +30,11 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
> #include
> +#include
>
> /*
> * The touchscreen interface operates as follows:
> @@ -179,7 +179,7 @@ struct tsc2005 {
>
> struct regulator*vio;
>
> - int reset_gpio;
> + struct gpio_desc*reset_gpio;
> void(*set_reset)(bool enable);
> };
>
> @@ -317,8 +317,8 @@ static void tsc2005_stop_scan(struct tsc2005 *ts)
>
> static void tsc2005_set_reset(struct tsc2005 *ts, bool enable)
> {
> - if (ts->reset_gpio >= 0)
> - gpio_set_value(ts->reset_gpio, enable);
> + if (ts->reset_gpio)
> + gpiod_set_value_cansleep(ts->reset_gpio, enable);
> else if (ts->set_reset)
> ts->set_reset(enable);
> }
> @@ -611,19 +611,11 @@ static int tsc2005_probe(struct spi_device *spi)
> ts->esd_timeout = esd_timeout;
>
> if (np) {
> - ts->reset_gpio = of_get_named_gpio(np, "reset-gpios", 0);
> - if (ts->reset_gpio == -EPROBE_DEFER)
> - return ts->reset_gpio;
> - if (ts->reset_gpio < 0) {
> + ts->reset_gpio = devm_gpiod_get(&spi->dev, "reset",
> + GPIOD_OUT_HIGH);
I think we should treat the gpio as optional and try to get the
descriptor event on non-OF boards.
> + if (IS_ERR(ts->reset_gpio)) {
> + error = PTR_ERR(ts->reset_gpio);
> dev_err(&spi->dev, "error acquiring reset gpio: %d\n",
> - ts->reset_gpio);
> - return ts->reset_gpio;
> - }
> -
> - error = devm_gpio_request_one(&spi->dev, ts->reset_gpio, 0,
> - "reset-gpios");
> - if (error) {
> - dev_err(&spi->dev, "error requesting reset gpio: %d\n",
> error);
> return error;
> }
> @@ -635,7 +627,6 @@ static int tsc2005_probe(struct spi_device *spi)
> return error;
> }
> } else {
> - ts->reset_gpio = -1;
> ts->set_reset = pdata->set_reset;
> }
>
> --
> 2.1.4
>
Thanks.
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] Input: tsc2005 - convert to regmap
On Wed, Jul 15, 2015 at 02:29:55PM -0700, Dmitry Torokhov wrote:
> Hi Sebastian,
>
> On Wed, Jul 15, 2015 at 02:13:26PM +0200, Sebastian Reichel wrote:
>
> > /* read the coordinates */
> > - error = spi_sync(ts->spi, &ts->spi_read_msg);
> > + error = regmap_bulk_read(ts->regmap, TSC2005_REG_X, &tsdata,
> > +TSC2005_DATA_REGS);
> > if (unlikely(error))
> > goto out;
> >
> > - x = ts->spi_x.spi_rx;
> > - y = ts->spi_y.spi_rx;
> > - z1 = ts->spi_z1.spi_rx;
> > - z2 = ts->spi_z2.spi_rx;
> > -
> > /* validate position */
> > - if (unlikely(x > MAX_12BIT || y > MAX_12BIT))
> > + if (unlikely(tsdata.x > MAX_12BIT || tsdata.y > MAX_12BIT))
> > goto out;
> >
> > /* Skip reading if the pressure components are out of range */
> > - if (unlikely(z1 == 0 || z2 > MAX_12BIT || z1 >= z2))
> > + if (unlikely(tsdata.z1 == 0 || tsdata.z2 > MAX_12BIT))
> > + goto out;
> > + if (unlikely(tsdata.z1 >= tsdata.z2))
> > goto out;
>
> I guess that means that tsc2005 is (and was) endian-broken. We can't use
> the data off the wire directly... So I'll drop bucnh of the changes in
> this function so we can convert to CPU endianness before using.
Ah, no, SPI transfers do convert to/from CPU endianness...
>
> I also got:
>
> CC [M] drivers/input/touchscreen/tsc2005.o
> Building modules, stage 2.
> Kernel: arch/x86/boot/bzImage is ready (#1383)
> MODPOST 1403 modules
> ERROR: "devm_regmap_init_spi" [drivers/input/touchscreen/tsc2005.ko]
> undefined!
> make[1]: *** [__modpost] Error 1
> make: *** [modules] Error 2
>
> I guess we need "select REGMAP_SPI".
>
> Thanks.
>
> --
> Dmitry
>
>
> Input: tsc2005 - convert to regmap
>
> From: Sebastian Reichel
>
> Convert driver, so that it uses regmap instead of directly using
> spi_transfer for all register accesses.
>
> Signed-off-by: Sebastian Reichel
> Signed-off-by: Dmitry Torokhov
> ---
> drivers/input/touchscreen/Kconfig |9 +-
> drivers/input/touchscreen/tsc2005.c | 149
> ---
> 2 files changed, 55 insertions(+), 103 deletions(-)
>
> diff --git a/drivers/input/touchscreen/Kconfig
> b/drivers/input/touchscreen/Kconfig
> index 9b3da52..c1acbbc 100644
> --- a/drivers/input/touchscreen/Kconfig
> +++ b/drivers/input/touchscreen/Kconfig
> @@ -915,10 +915,11 @@ config TOUCHSCREEN_TSC_SERIO
> module will be called tsc40.
>
> config TOUCHSCREEN_TSC2005
> -tristate "TSC2005 based touchscreens"
> -depends on SPI_MASTER
> -help
> - Say Y here if you have a TSC2005 based touchscreen.
> + tristate "TSC2005 based touchscreens"
> + depends on SPI_MASTER
> + select REGMAP_SPI
> + help
> + Say Y here if you have a TSC2005 based touchscreen.
>
> If unsure, say N.
>
> diff --git a/drivers/input/touchscreen/tsc2005.c
> b/drivers/input/touchscreen/tsc2005.c
> index 2a27a1f..a04248e 100644
> --- a/drivers/input/touchscreen/tsc2005.c
> +++ b/drivers/input/touchscreen/tsc2005.c
> @@ -34,6 +34,7 @@
> #include
> #include
> #include
> +#include
>
> /*
> * The touchscreen interface operates as follows:
> @@ -120,20 +121,36 @@
> #define TSC2005_SPI_MAX_SPEED_HZ 1000
> #define TSC2005_PENUP_TIME_MS40
>
> -struct tsc2005_spi_rd {
> - struct spi_transfer spi_xfer;
> - u32 spi_tx;
> - u32 spi_rx;
> +static const struct regmap_range tsc2005_writable_ranges[] = {
> + regmap_reg_range(TSC2005_REG_AUX_HIGH, TSC2005_REG_CFR2),
> };
>
> +static const struct regmap_access_table tsc2005_writable_table = {
> + .yes_ranges = tsc2005_writable_ranges,
> + .n_yes_ranges = ARRAY_SIZE(tsc2005_writable_ranges),
> +};
> +
> +static struct regmap_config tsc2005_regmap_config = {
> + .reg_bits = 8,
> + .val_bits = 16,
> + .reg_stride = 0x08,
> + .max_register = 0x78,
> + .read_flag_mask = TSC2005_REG_READ,
> + .wr_table = &tsc2005_writable_table,
> + .use_single_rw = true,
> +};
> +
> +struct tsc2005_data {
> + u16 x;
> + u16 y;
> + u16 z1;
> + u16 z2;
> +} __packed;
> +#define TSC2005_DATA_REGS 4
> +
> struct tsc2005 {
> struct spi_device *spi;
> -
> - struct spi_message spi_read_msg;
> - struct tsc2005_spi_rd spi_x;
> - struct tsc2005_spi_rd spi_y;
> - struct tsc2005_spi_rd spi_z1;
> - struct tsc2005_spi_rd spi_z2;
> + struct regmap *regmap;
>
> struct input_dev*idev;
> charphys[32];
> @@ -190,62 +207,6 @@ static int tsc2005_cmd(struct tsc2005 *ts, u8 cmd)
> return 0;
> }
>
> -static int tsc2005_write(struct tsc2005 *ts, u8 reg, u16 value)
> -{
> - u32 tx = ((reg | TSC2005_REG_PND0) << 16) | value;
> - struct spi_transfer xfer = {
> - .tx_buf = &tx,
> - .len= 4,
> -
Re: [PATCH v2 2/5] ARM: OMAP2+: DRA7: Add hwmod entries for PWMSS
Hi,
some comments.
On Wed, 3 Jun 2015, Vignesh R wrote:
> Add hwmod entries for the PWMSS on DRA7.
>
> Set l4_root_clk_div as the main_clk of PWMSS. It is fixed-factored clock
> equal to L4PER2_L3_GICLK/2(l3_iclk_div/2).
> As per AM57x TRM SPRUHZ6[1], October 2014, Section 29.1.3 Table 29-4,
> clock source to PWMSS is L4PER2_L3_GICLK. But it is actually
> L4PER2_L3_GICLK/2. The TRM does not show the division by 2.
Is the divide-by-two coming from PWMSS_EPWM.EPWM_TBCTL[HSPCLKDIV]? Or is
HSPCLKDIV a separate divider after the divide-by-2 you mention above?
> [1] www.ti.com/lit/ug/spruhz6/spruhz6.pdf
>
> Signed-off-by: Vignesh R
> ---
>
> v2:
> * add TRM references.
>
> arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 239
> ++
> 1 file changed, 239 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> index 0e64c2fac0b5..86a7ac9a3138 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> @@ -362,6 +362,149 @@ static struct omap_hwmod dra7xx_dcan2_hwmod = {
> },
> };
>
> +/* pwmss */
> +static struct omap_hwmod_class_sysconfig dra7xx_epwmss_sysc = {
> + .rev_offs = 0x0,
> + .sysc_offs = 0x4,
> + .sysc_flags = SYSC_HAS_SIDLEMODE | SYSC_HAS_RESET_STATUS,
This doesn't match SPRUHZ6 Table 29-13 "PWMSS_SYSCONFIG". There's no
RESETSTATUS bit. There is a SOFTRESET bit.
Could you please confirm whether this is intentional?
> + .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
> + .sysc_fields= &omap_hwmod_sysc_type2,
> +};
> +
> +struct omap_hwmod_class dra7xx_epwmss_hwmod_class = {
> + .name = "epwmss",
> + .sysc = &dra7xx_epwmss_sysc,
> +};
> +
> +static struct omap_hwmod_class dra7xx_ecap_hwmod_class = {
> + .name = "ecap",
> +};
> +
> +static struct omap_hwmod_class dra7xx_eqep_hwmod_class = {
> + .name = "eqep",
> +};
> +
> +struct omap_hwmod_class dra7xx_ehrpwm_hwmod_class = {
> + .name = "ehrpwm",
> +};
> +
> +/* epwmss0 */
> +struct omap_hwmod dra7xx_epwmss0_hwmod = {
> + .name = "epwmss0",
> + .class = &dra7xx_epwmss_hwmod_class,
> + .clkdm_name = "l4per2_clkdm",
> + .main_clk = "l4_root_clk_div",
> + .prcm = {
> + .omap4 = {
> + .modulemode = MODULEMODE_SWCTRL,
> + .clkctrl_offs =
> DRA7XX_CM_L4PER2_PWMSS1_CLKCTRL_OFFSET,
> + .context_offs =
> DRA7XX_RM_L4PER2_PWMSS1_CONTEXT_OFFSET,
> + },
> + },
Per my comment on the previous patch, sounds like it might be better to
mark this as HWMOD_SWSUP_SIDLE? Then again, see the next comment below
re: main_clk.
> +};
> +
> +/* ecap0 */
> +struct omap_hwmod dra7xx_ecap0_hwmod = {
> + .name = "ecap0",
> + .class = &dra7xx_ecap_hwmod_class,
> + .clkdm_name = "l4per2_clkdm",
> + .main_clk = "l4_root_clk_div",
Looking at SPRUHZ6 Section 29.1.4.2 "PWMSS Modules Local Clock Gating",
there appears to be a local "mini-PRCM" for the PWMSS which implements
clock gating and reports back on the status of what I'd guess is the local
clock gating FSM.
So from that point of view, you should probably create a clock driver that
manages both the clock gate request bit and the FSM status bit. It should
be something that can be reused for the other PWMSS IP blocks. Then
you'd create per-IP block clock nodes and set the main_clk to point to
that node.
> +};
> +
> +/* eqep0 */
> +struct omap_hwmod dra7xx_eqep0_hwmod = {
> + .name = "eqep0",
> + .class = &dra7xx_eqep_hwmod_class,
> + .clkdm_name = "l4per2_clkdm",
> + .main_clk = "l4_root_clk_div",
Same main_clk comments as for ecap0.
> +};
> +
> +/* ehrpwm0 */
> +struct omap_hwmod dra7xx_ehrpwm0_hwmod = {
> + .name = "ehrpwm0",
> + .class = &dra7xx_ehrpwm_hwmod_class,
> + .clkdm_name = "l4per2_clkdm",
> + .main_clk = "l4_root_clk_div",
Same main_clk comments as for ecap0.
> +};
> +
> +/* epwmss1 */
> +struct omap_hwmod dra7xx_epwmss1_hwmod = {
> + .name = "epwmss1",
> + .class = &dra7xx_epwmss_hwmod_class,
> + .clkdm_name = "l4per2_clkdm",
> + .main_clk = "l4_root_clk_div",
> + .prcm = {
> + .omap4 = {
> + .modulemode = MODULEMODE_SWCTRL,
> + .clkctrl_offs =
> DRA7XX_CM_L4PER2_PWMSS2_CLKCTRL_OFFSET,
> + .context_offs =
> DRA7XX_RM_L4PER2_PWMSS2_CONTEXT_OFFSET,
> + },
> + },
Same flags comment as for epwmss0.
> +};
> +
> +/* ecap1 */
> +struct omap_hwmod dra7xx_ecap1_hwmod = {
> + .name = "ecap1",
> + .class = &dra7xx_ecap_hwmod_class,
> + .clkdm_name =
Re: [PATCH 2/4] Input: tsc2005 - convert to regmap
Hi Dmitry, On Wed, Jul 15, 2015 at 02:29:55PM -0700, Dmitry Torokhov wrote: > I also got: > > CC [M] drivers/input/touchscreen/tsc2005.o > Building modules, stage 2. > Kernel: arch/x86/boot/bzImage is ready (#1383) > MODPOST 1403 modules > ERROR: "devm_regmap_init_spi" [drivers/input/touchscreen/tsc2005.ko] > undefined! > make[1]: *** [__modpost] Error 1 > make: *** [modules] Error 2 > > I guess we need "select REGMAP_SPI". Right. I will add this in PATCHv2. -- Sebastian signature.asc Description: Digital signature
Re: [PATCH 3/4] Input: tsc2005 - simplify drvdata acquisition
Hi, On Wed, Jul 15, 2015 at 02:31:07PM -0700, Dmitry Torokhov wrote: > On Wed, Jul 15, 2015 at 02:13:27PM +0200, Sebastian Reichel wrote: > > Do not convert device to spi_device just for getting > > the driver data, since spi_get_drvdata() just calls > > dev_get_drvdata(). > > Even though at the moment they all share the same data I consider them > logically different and so would prefer not to substityte one for > another. I guess your problem is with mixing spi_*_drvdata and dev_*_drvdata calls? In that case I will also change spi_set_drvdata to dev_set_drvdata, so that spi_*_drvdata is not used at all. This will still reduce lines of code and flatten the way for tsc2004 support (which is i2c based). -- Sebastian signature.asc Description: Digital signature
Re: [PATCH 4/4] Input: tsc2005 - convert to gpiod
Hi,
On Wed, Jul 15, 2015 at 02:34:04PM -0700, Dmitry Torokhov wrote:
> [...]
> > if (np) {
> > - ts->reset_gpio = of_get_named_gpio(np, "reset-gpios", 0);
> > - if (ts->reset_gpio == -EPROBE_DEFER)
> > - return ts->reset_gpio;
> > - if (ts->reset_gpio < 0) {
> > + ts->reset_gpio = devm_gpiod_get(&spi->dev, "reset",
> > + GPIOD_OUT_HIGH);
>
> I think we should treat the gpio as optional and try to get the
> descriptor event on non-OF boards.
As I wrote in the cover letter, I suggest to change this once the
Nokia N900 board code has been removed. At that point changing the
board code API is much easier, since it won't affect multiple trees.
> [...]
-- Sebastian
signature.asc
Description: Digital signature
Re: [PATCH v3 1/1] ARM: DRA7: hwmod: fix gpmc hwmod
On Wed, 8 Jul 2015, Roger Quadros wrote:
> GPMC smart idle is not really broken but it does not support
> smart idle with wakeup.
>
> Fixes: 556708fe8718 ("ARM: OMAP: DRA7: hwmod: Make gpmc software supervised
> as the smart idle is broken")
>
> Signed-off-by: Roger Quadros
Thanks Roger, queued for v4.2-rc fixes.
- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: OMAP2+: hwmod: add support for lock and unlock hooks
On Wed, 10 Jun 2015, Lokesh Vutla wrote: > Some IP blocks like RTC, needs an additional setting for writing to its > registers. This is to prevent any spurious writes from changing the > register values. > > This patch adds optional lock and unlock function pointers to > the IP block's hwmod data. These unlock and lock function pointers > are called by hwmod code before and after writing sysconfig registers. > > Signed-off-by: Lokesh Vutla Thanks, queued for v4.3. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] ARM: DRA: hwmod: RTC: Add lock and unlock functions
Hi,
some comments.
On Wed, 10 Jun 2015, Lokesh Vutla wrote:
> RTC IP have kicker feature which prevents spurious writes to its registers.
> In order to write into any of the RTC registers, KICK values has to be
> written to KICK registers.
>
> Introduce omap_hwmod_rtc_unlock/lock functions, which writes into these
> KICK registers inorder to lock and unlock RTC registers.
> Also hook these functions to RTC hwmod.
>
> Signed-off-by: Lokesh Vutla
> ---
> arch/arm/mach-omap2/omap_hwmod.h | 2 ++
> arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 2 ++
> arch/arm/mach-omap2/omap_hwmod_reset.c| 47
> +++
> 3 files changed, 51 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod.h
> b/arch/arm/mach-omap2/omap_hwmod.h
> index 44c7db9..04855ab 100644
> --- a/arch/arm/mach-omap2/omap_hwmod.h
> +++ b/arch/arm/mach-omap2/omap_hwmod.h
> @@ -742,6 +742,8 @@ const char *omap_hwmod_get_main_clk(struct omap_hwmod
> *oh);
> */
>
> extern int omap_hwmod_aess_preprogram(struct omap_hwmod *oh);
> +void omap_hwmod_rtc_unlock(struct omap_hwmod *oh);
> +void omap_hwmod_rtc_lock(struct omap_hwmod *oh);
>
> /*
> * Chip variant-specific hwmod init routines - XXX should be converted
> diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> index 0e64c2f..983042f 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> @@ -1548,6 +1548,8 @@ static struct omap_hwmod_class_sysconfig
> dra7xx_rtcss_sysc = {
> static struct omap_hwmod_class dra7xx_rtcss_hwmod_class = {
> .name = "rtcss",
> .sysc = &dra7xx_rtcss_sysc,
> + .unlock = &omap_hwmod_rtc_unlock,
> + .lock = &omap_hwmod_rtc_lock,
> };
>
> /* rtcss */
Is the DRA7xx the only chip that has this lock/unlock feature, or do other
OMAP chips use the same RTC IP block?
> diff --git a/arch/arm/mach-omap2/omap_hwmod_reset.c
> b/arch/arm/mach-omap2/omap_hwmod_reset.c
> index 65e186c..1fb106d 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_reset.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_reset.c
> @@ -25,11 +25,20 @@
> */
> #include
> #include
> +#include
>
> #include
>
> #include "omap_hwmod.h"
>
> +#define OMAP_RTC_STATUS_REG 0x44
> +#define OMAP_RTC_KICK0_REG 0x6c
> +#define OMAP_RTC_KICK1_REG 0x70
> +
> +#define OMAP_RTC_KICK0_VALUE 0x83E70B13
> +#define OMAP_RTC_KICK1_VALUE 0x95A4F1E0
> +#define OMAP_RTC_STATUS_BUSY BIT(0)
> +
> /**
> * omap_hwmod_aess_preprogram - enable AESS internal autogating
> * @oh: struct omap_hwmod *
> @@ -51,3 +60,41 @@ int omap_hwmod_aess_preprogram(struct omap_hwmod *oh)
>
> return 0;
> }
> +
> +static void omap_rtc_wait_not_busy(struct omap_hwmod *oh)
This function is missing kerneldoc and desperately needs it.
> +{
> + int count;
> + u8 status;
> +
> + /* BUSY may stay active for 1/32768 second (~30 usec) */
> + for (count = 0; count < 50; count++) {
OK, I give up. Where does 50 come from? This should be moved into a
macro with a comment, at the very least.
> + status = omap_hwmod_read(oh, OMAP_RTC_STATUS_REG);
> + if (!(status & OMAP_RTC_STATUS_BUSY))
> + break;
> + udelay(1);
> + }
> + /* now we have ~15 usec to read/write various registers */
> +}
> +
> +/**
> + * omap_hwmod_rtc_unlock - Reset and unlock the Kicker mechanism.
> + * @oh: struct omap_hwmod *
> + *
> + * RTC IP have kicker feature. This prevents spurious writes to its
> registers.
> + * In order to write into any of the RTC registers, KICK values has te be
> + * written in respective KICK registers. This is needed for hwmod to write
> into
> + * sysconfig register.
> + */
> +void omap_hwmod_rtc_unlock(struct omap_hwmod *oh)
> +{
> + omap_rtc_wait_not_busy(oh);
What prevents the CPU from context-switching away after the BUSY bit test
and not returning back here by the time the ~15 µs interval has ended?
Looks to me like this whole thing needs to run with interrupts disabled.
> + omap_hwmod_write(OMAP_RTC_KICK0_VALUE, oh, OMAP_RTC_KICK0_REG);
> + omap_hwmod_write(OMAP_RTC_KICK1_VALUE, oh, OMAP_RTC_KICK1_REG);
> +}
> +
> +void omap_hwmod_rtc_lock(struct omap_hwmod *oh)
> +{
> + omap_rtc_wait_not_busy(oh);
Same comment as the above.
> + omap_hwmod_write(0x0, oh, OMAP_RTC_KICK0_REG);
> + omap_hwmod_write(0x0, oh, OMAP_RTC_KICK1_REG);
> +}
> --
> 1.9.1
>
- Paul
Re: [PATCH 3/3] ARM: AMx3xx: hwmod: RTC: Add lock and unlock functions
Hi
On Wed, 10 Jun 2015, Lokesh Vutla wrote:
> RTC IP have kicker feature which prevents spurious writes to its registers.
> In order to write into any of the RTC registers, KICK values has to be
> written to KICK registers.
>
> omap_hwmod_rtc_unlock/lock functions writes into these KICK registers
> inorder to lock and unlock RTC registers.
> This patch hooks omap_hwmod_rtc_unlock/lock functions into RTC hwmod,
> so that SYSCONFIG register is updated properly.
>
> Signed-off-by: Lokesh Vutla
> ---
> arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
> b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
> index cabc569..2d92958 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
> @@ -904,6 +904,8 @@ static struct omap_hwmod_class_sysconfig am33xx_rtc_sysc
> = {
> static struct omap_hwmod_class am33xx_rtc_hwmod_class = {
> .name = "rtc",
> .sysc = &am33xx_rtc_sysc,
> + .unlock = &omap_hwmod_rtc_unlock,
> + .lock = &omap_hwmod_rtc_lock,
> };
>
> struct omap_hwmod am33xx_rtc_hwmod = {
The DRA7xx integration from the previous patch should either be combined
with this patch, or moved into a separate patch like this one (your
preference).
- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] ARM: OMAP2+: hwmod: RTC: Add lock and unlock hooks
On Tue, 14 Jul 2015, Tero Kristo wrote: > On 07/14/2015 01:09 PM, Lokesh Vutla wrote: > > Hi, > > On Wednesday 10 June 2015 02:56 PM, Lokesh Vutla wrote: > > > Some IP blocks like RTC, needs an additional unlocking mechanism for > > > writing to its registers. This patch adds optional lock and unlock > > > function pointers to the IP block's hwmod data which gets executed > > > before and after writing into IP sysconfig register. > > > And also hook lock and unlock functions to AMx3xx, DRA7 RTC hwmod data, > > > so that sysconfig registers are updated properly. > > ping on this series. > > > > Thanks and regards, > > Lokesh > [...] > It is also racy, as there is no locking in place to avoid concurrent access to > the lock/unlock registers across hwmod+driver. I don't see the race. Where is it? - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] Input: tsc2005 - simplify drvdata acquisition
On Thu, Jul 16, 2015 at 12:02:21AM +0200, Sebastian Reichel wrote: > Hi, > > On Wed, Jul 15, 2015 at 02:31:07PM -0700, Dmitry Torokhov wrote: > > On Wed, Jul 15, 2015 at 02:13:27PM +0200, Sebastian Reichel wrote: > > > Do not convert device to spi_device just for getting > > > the driver data, since spi_get_drvdata() just calls > > > dev_get_drvdata(). > > > > Even though at the moment they all share the same data I consider them > > logically different and so would prefer not to substityte one for > > another. > > I guess your problem is with mixing spi_*_drvdata and dev_*_drvdata > calls? In that case I will also change spi_set_drvdata to > dev_set_drvdata, so that spi_*_drvdata is not used at all. > > This will still reduce lines of code and flatten the way for tsc2004 > support (which is i2c based). OK, that will work. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] Input: tsc2005 - convert to gpiod
On Thu, Jul 16, 2015 at 12:09:41AM +0200, Sebastian Reichel wrote:
> Hi,
>
> On Wed, Jul 15, 2015 at 02:34:04PM -0700, Dmitry Torokhov wrote:
> > [...]
> > > if (np) {
> > > - ts->reset_gpio = of_get_named_gpio(np, "reset-gpios", 0);
> > > - if (ts->reset_gpio == -EPROBE_DEFER)
> > > - return ts->reset_gpio;
> > > - if (ts->reset_gpio < 0) {
> > > + ts->reset_gpio = devm_gpiod_get(&spi->dev, "reset",
> > > + GPIOD_OUT_HIGH);
> >
> > I think we should treat the gpio as optional and try to get the
> > descriptor event on non-OF boards.
>
> As I wrote in the cover letter, I suggest to change this once the
> Nokia N900 board code has been removed. At that point changing the
> board code API is much easier, since it won't affect multiple trees.
I do not see why it has be wait for Nokia board code. Just make it
devm_gpiod_get_optional() and call it unconditionally and fall back onto
custom reset function (if one is supplied).
Thanks.
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: OMAP2+: clockdomain: Add mechanism for disabling HW_AUTO
Hi
On Tue, 23 Jun 2015, Roger Quadros wrote:
> For some hwmods (e.g. DCAN on DRA7) we need the possibility to
> disable HW_AUTO for the clockdomain while the module is active.
>
> To achieve this there needs to be a refcounting mechanism to
> indicate whether any module in the clockdomain has requested
> to disable HW_AUTO. We keep track of this in 'noidlecount'.
>
> Hwmod code must use clkdm_hwmod_prevent_hwauto() to prevent
> HW_AUTO of the clockdomain in the future clkdm_hwmod_hwauto() calls.
>
> It must use clkdm_hwmod_allow_hwauto() to allow HW_AUTO in
> the future clkdm_hwmod_hwauto() calls.
>
> Hwmod code must use clkdm_hwmod_allow_hwauto() whenever it needs
> to request HW_AUTO of any clockdomain. (Typically after it has
> enabled the module).
How about just modifying clkdm_{allow,deny}_idle*() to do the
idle-block-counting? The default state would be to allow idle, assuming
that the clockdomain flags support that state, and then clkdm_deny_idle*()
would increment the idle-blocking count, clkdm_allow_idle*() would
decrement it. Then on the 0 -> 1 or 1 -> 0 transitions, the hardware
would be reprogrammed appropiately.
Anyway, seems like that would avoid races with any
clkdm_{allow,deny}_idle*() users.
A few other comments below:
>
> Signed-off-by: Roger Quadros
> ---
> arch/arm/mach-omap2/clockdomain.c | 71
> +++
> arch/arm/mach-omap2/clockdomain.h | 5 +++
> 2 files changed, 76 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/clockdomain.c
> b/arch/arm/mach-omap2/clockdomain.c
> index 2da3b5e..a7190d2 100644
> --- a/arch/arm/mach-omap2/clockdomain.c
> +++ b/arch/arm/mach-omap2/clockdomain.c
> @@ -1212,6 +1212,77 @@ ccd_exit:
> return 0;
> }
>
> +/*
> + * prevent future hwauto for this clkdm. If clkdm->usecount becomes hwauto
> isn't prevented.
> + * It will only prevnt future hwauto but not bring it out of hwauto.
> + */
If you modify clkdm_{allow,deny}_idle*(), this shouldn't be a major issue
- but all of the function comments should be fixed so that they are
understandable and follow kernel-doc-nano specs.
> +int clkdm_hwmod_prevent_hwauto(struct clockdomain *clkdm, struct omap_hwmod
> *oh)
> +{
> + /* The clkdm attribute does not exist yet prior OMAP4 */
> + if (cpu_is_omap24xx() || cpu_is_omap34xx())
> + return 0;
> +
> + if (!clkdm || !oh || !arch_clkdm || !arch_clkdm->clkdm_clk_disable)
> + return -EINVAL;
> +
> +
> + pwrdm_lock(clkdm->pwrdm.ptr);
> + clkdm->noidlecount++;
> + pwrdm_unlock(clkdm->pwrdm.ptr);
> +
> + return 0;
> +}
> +
> +/*
> + * allow future hwauto for this clkdm
> + * It won't put clkdm into hwauto. use clkdm_hwmod_hwauto() for that.
> + */
> +int clkdm_hwmod_allow_hwauto(struct clockdomain *clkdm, struct omap_hwmod
> *oh)
> +{
> + /* The clkdm attribute does not exist yet prior OMAP4 */
> + if (cpu_is_omap24xx() || cpu_is_omap34xx())
> + return 0;
> +
> + if (!clkdm || !oh || !arch_clkdm || !arch_clkdm->clkdm_clk_disable)
> + return -EINVAL;
> +
> +
> + pwrdm_lock(clkdm->pwrdm.ptr);
> +
> + if (clkdm->noidlecount == 0) {
> + pwrdm_unlock(clkdm->pwrdm.ptr);
> + WARN_ON(1); /* underflow */
> + return -ERANGE;
> + }
> +
> + clkdm->noidlecount--;
> + pwrdm_unlock(clkdm->pwrdm.ptr);
> +
> + return 0;
> +}
> +
> +/*
> + * put clkdm in hwauto if we can. checks noidlecount to see if we can.
> + */
> +int clkdm_hwmod_hwauto(struct clockdomain *clkdm, struct omap_hwmod *oh)
> +{
> + /* The clkdm attribute does not exist yet prior OMAP4 */
> + if (cpu_is_omap24xx() || cpu_is_omap34xx())
> + return 0;
> +
> + if (!clkdm || !oh || !arch_clkdm || !arch_clkdm->clkdm_clk_disable)
> + return -EINVAL;
> +
> +
> + pwrdm_lock(clkdm->pwrdm.ptr);
> + if (clkdm->noidlecount == 0)
> + clkdm_allow_idle_nolock(clkdm);
> +
> + pwrdm_unlock(clkdm->pwrdm.ptr);
> +
> + return 0;
> +}
> +
> /**
> * clkdm_hwmod_enable - add an enabled downstream hwmod to this clkdm
> * @clkdm: struct clockdomain *
> diff --git a/arch/arm/mach-omap2/clockdomain.h
> b/arch/arm/mach-omap2/clockdomain.h
> index 77bab5f..8c491be 100644
> --- a/arch/arm/mach-omap2/clockdomain.h
> +++ b/arch/arm/mach-omap2/clockdomain.h
> @@ -114,6 +114,7 @@ struct omap_hwmod;
> * @wkdep_srcs: Clockdomains that can be told to wake this powerdomain up
> * @sleepdep_srcs: Clockdomains that can be told to keep this clkdm from
> inact
> * @usecount: Usecount tracking
> + * @noidlecount: Noidle count tracking. Domain won't be auto idled this is >
> 0.
> * @node: list_head to link all clockdomains together
> *
> * @prcm_partition should be a macro from mach-omap2/prcm44xx.h (OMAP4 only)
> @@ -138,6 +139,7 @@ struct clockdomain {
> struct clkdm_dep *wkdep_srcs;
> struct clkdm_dep *sleepdep_srcs;
> int usecount;
> + int n
Re: [PATCH] ARM: OMAP2+: hwmod: Fix _wait_target_ready() for hwmods without sysc
Hi Roger On Mon, 13 Jul 2015, Roger Quadros wrote: > There are quite a few hwmods that don't have sysconfig register and so > _find_mpu_rt_port(oh) will return NULL thus preventing ready state check > on those modules after the module is enabled. > > This can potentially cause a bus access error if the module is accessed > before the module is ready. > > Get rid of the redundant _find_mpu_rt_port() check from the > _wait_target_ready() > funcion for all the SoCs. The following PRCM register access that checks the > module ready state has nothing to do with module's SYSCONFIG or mpu_rt_port. > > e.g. this fixes the below DCAN bus access error on AM437x-gp-evm. Could you update this patch to align with the discussion we had the last time this was posted in December? e.g., http://www.spinics.net/lists/arm-kernel/msg388002.html You can ignore the problems with the VAR-SOM-OM that were discussed; those were indeed due to an old DT file in use, as Suman suspected. Let me know if you have any questions about it - - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] clk: ti: clock driver code migration to drivers
On Tue, 14 Jul 2015, Tony Lindgren wrote: > * Tero Kristo [150714 03:34]: > > On 07/14/2015 12:54 PM, Tony Lindgren wrote: > > >* Tero Kristo [150714 01:56]: > > >> > > >>This pull request contains the TI clock driver set to move the clock > > >>implementations under clock driver. Some small portions of the clock > > >>driver > > >>code still remain under mach-omap2 after this, it should be decided > > >>whether > > >>this code is now obsolete and should be deleted or should someone try to > > >>fix > > >>it. > > > > > >Hmm care to clarify what is obsolete or broken after this series? > > > > Not after this series, was broken/obsolete already before. > > > > A couple of omap2/omap3 specific clock files still remain under mach-omap2, > > they are DVFS related. OMAP3 core dvfs support is currently completely > > unused (this could probably be removed, or shall we re-introduce the painful > > core dvfs at some point again?), and parts of the omap2 core dpll handling > > code should probably be re-written; or at least verified that it actually > > works properly. I can't test OMAP2 DVFS myself so don't dare to fiddle with > > it I could probably try to get some sort of DVFS test case to work on > > the board farm OMAP2 board I have access to though, I can investigate this. > > People seem to still want the 1 GiHz support, but I think that only > depends on the SmartReflex and some kind of replacement for > voltagedomains. So if the core DVFS support is unused, I doubt it's > very high on anybody's list right now. At least several years ago, basic CORE DVFS support was working on OMAP3. The clock source changed rate, DRAM parameters were changed on the SDRC, etc. What was not implemented was pre-rate-change and post-rate-change notifiers in many of the device drivers, because the infrastructure didn't exist at the time in the clock code. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/6] ARM: OMAP4: PRM: Remove hardcoding of PRM_IO_PMCTRL_OFFSET register
Hi
a few minor comments
On Wed, 8 Jul 2015, Keerthy wrote:
> PRM_IO_PMCTRL_OFFSET need not be same for all SOCs hence
> remove hardcoding and use the value provided by the omap_prcm_irq_setup
> structure.
Please mention here that the reason why you're making this change is to
support AM437x.
>
> Signed-off-by: Keerthy
> ---
> arch/arm/mach-omap2/prcm-common.h | 1 +
> arch/arm/mach-omap2/prm44xx.c | 11 ++-
> 2 files changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/prcm-common.h
> b/arch/arm/mach-omap2/prcm-common.h
> index 6ae0b3a..2e60406 100644
> --- a/arch/arm/mach-omap2/prcm-common.h
> +++ b/arch/arm/mach-omap2/prcm-common.h
> @@ -494,6 +494,7 @@ struct omap_prcm_irq {
> struct omap_prcm_irq_setup {
> u16 ack;
> u16 mask;
> + u16 pm_ctrl;
Please add a kerneldoc structure documentation line for this new field, to
match the existing documentation here.
> u8 nr_regs;
> u8 nr_irqs;
> const struct omap_prcm_irq *irqs;
> diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c
> index 4541700..8149e5a 100644
> --- a/arch/arm/mach-omap2/prm44xx.c
> +++ b/arch/arm/mach-omap2/prm44xx.c
> @@ -45,6 +45,7 @@ static const struct omap_prcm_irq omap4_prcm_irqs[] = {
> static struct omap_prcm_irq_setup omap4_prcm_irq_setup = {
> .ack= OMAP4_PRM_IRQSTATUS_MPU_OFFSET,
> .mask = OMAP4_PRM_IRQENABLE_MPU_OFFSET,
> + .pm_ctrl= OMAP4_PRM_IO_PMCTRL_OFFSET,
> .nr_regs= 2,
> .irqs = omap4_prcm_irqs,
> .nr_irqs= ARRAY_SIZE(omap4_prcm_irqs),
> @@ -306,10 +307,10 @@ static void omap44xx_prm_reconfigure_io_chain(void)
> omap4_prm_rmw_inst_reg_bits(OMAP4430_WUCLK_CTRL_MASK,
> OMAP4430_WUCLK_CTRL_MASK,
> inst,
> - OMAP4_PRM_IO_PMCTRL_OFFSET);
> + omap4_prcm_irq_setup.pm_ctrl);
> omap_test_timeout(
> (((omap4_prm_read_inst_reg(inst,
> -OMAP4_PRM_IO_PMCTRL_OFFSET) &
> +omap4_prcm_irq_setup.pm_ctrl) &
> OMAP4430_WUCLK_STATUS_MASK) >>
> OMAP4430_WUCLK_STATUS_SHIFT) == 1),
> MAX_IOPAD_LATCH_TIME, i);
> @@ -319,10 +320,10 @@ static void omap44xx_prm_reconfigure_io_chain(void)
> /* Trigger WUCLKIN disable */
> omap4_prm_rmw_inst_reg_bits(OMAP4430_WUCLK_CTRL_MASK, 0x0,
> inst,
> - OMAP4_PRM_IO_PMCTRL_OFFSET);
> + omap4_prcm_irq_setup.pm_ctrl);
> omap_test_timeout(
> (((omap4_prm_read_inst_reg(inst,
> -OMAP4_PRM_IO_PMCTRL_OFFSET) &
> +omap4_prcm_irq_setup.pm_ctrl) &
> OMAP4430_WUCLK_STATUS_MASK) >>
> OMAP4430_WUCLK_STATUS_SHIFT) == 0),
> MAX_IOPAD_LATCH_TIME, i);
> @@ -350,7 +351,7 @@ static void __init omap44xx_prm_enable_io_wakeup(void)
> omap4_prm_rmw_inst_reg_bits(OMAP4430_GLOBAL_WUEN_MASK,
> OMAP4430_GLOBAL_WUEN_MASK,
> inst,
> - OMAP4_PRM_IO_PMCTRL_OFFSET);
> + omap4_prcm_irq_setup.pm_ctrl);
> }
>
> /**
> --
> 1.9.1
>
- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 04/11] otg-fsm: move usb_bus_start_enum into otg-fsm->ops
On Wed, Jul 15, 2015 at 04:30:27PM +0300, Roger Quadros wrote: > On 14/07/15 03:34, Peter Chen wrote: > > On Mon, Jul 13, 2015 at 01:13:54PM +0300, Roger Quadros wrote: > >> Peter, > >> > >> On 13/07/15 04:58, Peter Chen wrote: > >>> On Wed, Jul 08, 2015 at 01:19:30PM +0300, Roger Quadros wrote: > This is to prevent missing symbol build error if OTG is > enabled (built-in) and HCD core (CONFIG_USB) is module. > > >>> > >>> We may let the OTG-DRD/OTG-FSM depends on CONFIG_USB to fix it. > >> > >> CONFIG_OTG already depends on CONFIG_USB as it is a sub-option of > >> CONFIG_USB. It doesn't depend on CONFIG_USB_GADGET and that can > >> be fixed. > >> > >> But dependency is not the problem here. Symbols not available to > >> OTG driver when USB/GADGET is 'm' is the problem. > >> > >> e.g. > >> CONFIG_USB_OTG is always built-in. > >> we need to work if CONFIG_USB is 'm'/'y' > >> _and_ if CONFIG_USB_GADGET is 'm'/'y' > >> > > > > below should fix this issue, but we may need to make some > > changes for code which are defined by CONFIG_USB_OTG. > > > > diff --git a/drivers/usb/core/Kconfig b/drivers/usb/core/Kconfig > > index a99c89e..5e374ad 100644 > > --- a/drivers/usb/core/Kconfig > > +++ b/drivers/usb/core/Kconfig > > @@ -42,8 +42,9 @@ config USB_DYNAMIC_MINORS > > If you are unsure about this, say N here. > > > > config USB_OTG > > - bool "OTG support" > > + tristate "OTG support" > > depends on PM > > + depends on USB && USB_GADGET > > default n > >help > > The most notable feature of > > USB OTG is support for a > > With this USB_OTG will become 'm' when either USB or USB_GADGET is m > and will break if either USB or USB_GADGET is made y as all OTG core > API symbols won't be available. :) > Ok, after thinking more, seems we can't handle properly if USB_OTG as 'm', your idea that using host/gadget/fsm->ops to call hcd/gadget API and the controller driver will defines these ops (due to it will use hcd/gadget function) is proper way currently. -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/6] ARM: AM43xx: Add the PRM IRQ register offsets
On Wed, 8 Jul 2015, Keerthy wrote: > Add the PRM IRQ register offsets. > > Signed-off-by: Keerthy Please add more detail to your commit messages so they conform to Documentation/SubmittingPatches: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches#n109 For example, this commit message should read something like: --- ARM: AM43xx: Add the PRM IRQ register offsets Add the PRM IRQ register offsets. This is needed to support PRM I/O wakeup on AM43xx. -- Basically, your patches need to provide context as to _why_ the change is needed. I've fixed the message for this patch, and queued it for v4.3, but please take care with this issue in the future. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/6] ARM: AM43xx: Add the PRM IRQ register offsets
On Thu, 16 Jul 2015, Paul Walmsley wrote: > On Wed, 8 Jul 2015, Keerthy wrote: > > > Add the PRM IRQ register offsets. > > > > Signed-off-by: Keerthy > > Please add more detail to your commit messages so they conform to > Documentation/SubmittingPatches: > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches#n109 > > For example, this commit message should read something like: > > --- > > ARM: AM43xx: Add the PRM IRQ register offsets > > Add the PRM IRQ register offsets. This is needed to support PRM I/O > wakeup on AM43xx. > > -- > > Basically, your patches need to provide context as to _why_ the change is > needed. > > I've fixed the message for this patch, and queued it for v4.3, but > please take care with this issue in the future. Also I've moved the AM43XX_PRM_IO_PMCTRL_OFFSET macro out of the AM43XX CM section, since it doesn't belong there. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/6] ARM: OMAP: PRM: Remove hardcoding of IRQENABLE_MPU_2 and IRQSTATUS_MPU_2 register offsets
On Wed, 8 Jul 2015, Keerthy wrote: > The register offsets of IRQENABLE_MPU_2 and IRQSTATUS_MPU_2 are hardcoded. > This makes it difficult to reuse the code for SoCs like AM437x that have > a single instance of IRQENABLE_MPU and IRQSTATUS_MPU registers. > Hence handling the case using offset of 4 to accommodate single set of IRQ* > registers generically. > > Signed-off-by: Keerthy Thanks, queued for v4.3. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 6/6] ARM: PRM: AM437x: Enable IO wakeup feature
Hi On Tue, 14 Jul 2015, Keerthy wrote: > Enable IO wakeup feature. > > Signed-off-by: Keerthy Per my comments on one of the previous patches, please add a short description in the commit message for what enabling I/O wakeup will do for a user. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/6] ARM: AM43xx: Add the PRM IRQ register offsets
On Thursday 16 July 2015 08:08 AM, Paul Walmsley wrote: On Thu, 16 Jul 2015, Paul Walmsley wrote: On Wed, 8 Jul 2015, Keerthy wrote: Add the PRM IRQ register offsets. Signed-off-by: Keerthy Please add more detail to your commit messages so they conform to Documentation/SubmittingPatches: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches#n109 For example, this commit message should read something like: --- ARM: AM43xx: Add the PRM IRQ register offsets Add the PRM IRQ register offsets. This is needed to support PRM I/O wakeup on AM43xx. -- Basically, your patches need to provide context as to _why_ the change is needed. I've fixed the message for this patch, and queued it for v4.3, but please take care with this issue in the future. Also I've moved the AM43XX_PRM_IO_PMCTRL_OFFSET macro out of the AM43XX CM section, since it doesn't belong there. Thanks Paul! - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/6] ARM: OMAP4: PRM: Remove hardcoding of PRM_IO_PMCTRL_OFFSET register
Paul,
Thanks for the review!
On Thursday 16 July 2015 07:24 AM, Paul Walmsley wrote:
Hi
a few minor comments
On Wed, 8 Jul 2015, Keerthy wrote:
PRM_IO_PMCTRL_OFFSET need not be same for all SOCs hence
remove hardcoding and use the value provided by the omap_prcm_irq_setup
structure.
Please mention here that the reason why you're making this change is to
support AM437x.
Sure. I will do that.
Signed-off-by: Keerthy
---
arch/arm/mach-omap2/prcm-common.h | 1 +
arch/arm/mach-omap2/prm44xx.c | 11 ++-
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/prcm-common.h
b/arch/arm/mach-omap2/prcm-common.h
index 6ae0b3a..2e60406 100644
--- a/arch/arm/mach-omap2/prcm-common.h
+++ b/arch/arm/mach-omap2/prcm-common.h
@@ -494,6 +494,7 @@ struct omap_prcm_irq {
struct omap_prcm_irq_setup {
u16 ack;
u16 mask;
+ u16 pm_ctrl;
Please add a kerneldoc structure documentation line for this new field, to
match the existing documentation here.
Okay.
u8 nr_regs;
u8 nr_irqs;
const struct omap_prcm_irq *irqs;
diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c
index 4541700..8149e5a 100644
--- a/arch/arm/mach-omap2/prm44xx.c
+++ b/arch/arm/mach-omap2/prm44xx.c
@@ -45,6 +45,7 @@ static const struct omap_prcm_irq omap4_prcm_irqs[] = {
static struct omap_prcm_irq_setup omap4_prcm_irq_setup = {
.ack= OMAP4_PRM_IRQSTATUS_MPU_OFFSET,
.mask = OMAP4_PRM_IRQENABLE_MPU_OFFSET,
+ .pm_ctrl= OMAP4_PRM_IO_PMCTRL_OFFSET,
.nr_regs= 2,
.irqs = omap4_prcm_irqs,
.nr_irqs= ARRAY_SIZE(omap4_prcm_irqs),
@@ -306,10 +307,10 @@ static void omap44xx_prm_reconfigure_io_chain(void)
omap4_prm_rmw_inst_reg_bits(OMAP4430_WUCLK_CTRL_MASK,
OMAP4430_WUCLK_CTRL_MASK,
inst,
- OMAP4_PRM_IO_PMCTRL_OFFSET);
+ omap4_prcm_irq_setup.pm_ctrl);
omap_test_timeout(
(((omap4_prm_read_inst_reg(inst,
- OMAP4_PRM_IO_PMCTRL_OFFSET) &
+ omap4_prcm_irq_setup.pm_ctrl) &
OMAP4430_WUCLK_STATUS_MASK) >>
OMAP4430_WUCLK_STATUS_SHIFT) == 1),
MAX_IOPAD_LATCH_TIME, i);
@@ -319,10 +320,10 @@ static void omap44xx_prm_reconfigure_io_chain(void)
/* Trigger WUCLKIN disable */
omap4_prm_rmw_inst_reg_bits(OMAP4430_WUCLK_CTRL_MASK, 0x0,
inst,
- OMAP4_PRM_IO_PMCTRL_OFFSET);
+ omap4_prcm_irq_setup.pm_ctrl);
omap_test_timeout(
(((omap4_prm_read_inst_reg(inst,
- OMAP4_PRM_IO_PMCTRL_OFFSET) &
+ omap4_prcm_irq_setup.pm_ctrl) &
OMAP4430_WUCLK_STATUS_MASK) >>
OMAP4430_WUCLK_STATUS_SHIFT) == 0),
MAX_IOPAD_LATCH_TIME, i);
@@ -350,7 +351,7 @@ static void __init omap44xx_prm_enable_io_wakeup(void)
omap4_prm_rmw_inst_reg_bits(OMAP4430_GLOBAL_WUEN_MASK,
OMAP4430_GLOBAL_WUEN_MASK,
inst,
- OMAP4_PRM_IO_PMCTRL_OFFSET);
+ omap4_prcm_irq_setup.pm_ctrl);
}
/**
--
1.9.1
- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 6/6] ARM: PRM: AM437x: Enable IO wakeup feature
On Thursday 16 July 2015 10:44 AM, Paul Walmsley wrote: Hi On Tue, 14 Jul 2015, Keerthy wrote: Enable IO wakeup feature. Signed-off-by: Keerthy Per my comments on one of the previous patches, please add a short description in the commit message for what enabling I/O wakeup will do for a user. Okay will do that. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: OMAP2+: sparse: add missing static declaration
On Sat, 11 Jul 2015, Sekhar Nori wrote: > Add missing static declaration for file local variables. > This fixes sparse warnings of type: > > arch/arm/mach-omap2/omap_hwmod_81xx_data.c:491:26: warning: symbol > 'dm81xx_alwon_l3_slow__gpmc' was not declared. Should it be static? > > Signed-off-by: Sekhar Nori Thanks, queued for v4.3. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: OMAP2+: sparse: add missing function declarations
On Sat, 11 Jul 2015, Sekhar Nori wrote: > omap3xxx_restart() and omap44xx_restart() are global > functions declared in common.h. Include this file > in omap3-restart.c and omap4-restart.c to prevent > sparse warnings of type: > > arch/arm/mach-omap2/omap4-restart.c:22:6: warning: symbol 'omap44xx_restart' > was not declared. Should it be static? > > Signed-off-by: Sekhar Nori Thanks, queued for v4.3. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2: Delete unnecessary checks before three function calls
Hello Markus
On Tue, 30 Jun 2015, SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Tue, 30 Jun 2015 14:00:16 +0200
>
> The functions clk_disable(), of_node_put() and omap_device_delete() test
> whether their argument is NULL and then return immediately.
> Thus the test around the call is not needed.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring
Thanks for the patch. I have to say, I am a bit leery about applying the
omap_device.c and omap_hwmod.c changes, since the called functions --
omap_device_delete() and clk_disable() -- don't explicitly document that
NULLs are allowed to be passed in. So there's no explicit contract that
callers can rely upon, to (at least in theory) prevent those internal NULL
pointer checks from being removed.
So I would suggest that those two functions' kerneldoc be patched first to
explicitly state that passing in a NULL pointer is allowed. Then I would
feel a bit more comfortable applying the omap_device.c and omap_hwmod.c
changes.
The kerneldoc for of_node_put() does explicitly allow NULLs to be passed
in. So I'll apply that change now for v4.3, touching up the commit
message accordingly.
regards,
- Paul
> ---
> arch/arm/mach-omap2/omap_device.c | 3 +--
> arch/arm/mach-omap2/omap_hwmod.c | 5 +
> arch/arm/mach-omap2/timer.c | 3 +--
> 3 files changed, 3 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_device.c
> b/arch/arm/mach-omap2/omap_device.c
> index 4cb8fd9..196366e 100644
> --- a/arch/arm/mach-omap2/omap_device.c
> +++ b/arch/arm/mach-omap2/omap_device.c
> @@ -193,8 +193,7 @@ static int _omap_device_notifier_call(struct
> notifier_block *nb,
>
> switch (event) {
> case BUS_NOTIFY_DEL_DEVICE:
> - if (pdev->archdata.od)
> - omap_device_delete(pdev->archdata.od);
> + omap_device_delete(pdev->archdata.od);
> break;
> case BUS_NOTIFY_ADD_DEVICE:
> if (pdev->dev.of_node)
> diff --git a/arch/arm/mach-omap2/omap_hwmod.c
> b/arch/arm/mach-omap2/omap_hwmod.c
> index d78c12e..1091ee7 100644
> --- a/arch/arm/mach-omap2/omap_hwmod.c
> +++ b/arch/arm/mach-omap2/omap_hwmod.c
> @@ -921,10 +921,7 @@ static int _disable_clocks(struct omap_hwmod *oh)
> int i = 0;
>
> pr_debug("omap_hwmod: %s: disabling clocks\n", oh->name);
> -
> - if (oh->_clk)
> - clk_disable(oh->_clk);
> -
> + clk_disable(oh->_clk);
> p = oh->slave_ports.next;
>
> while (i < oh->slaves_cnt) {
> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
> index cac46d8..15448221 100644
> --- a/arch/arm/mach-omap2/timer.c
> +++ b/arch/arm/mach-omap2/timer.c
> @@ -208,8 +208,7 @@ static void __init omap_dmtimer_init(void)
> /* If we are a secure device, remove any secure timer nodes */
> if ((omap_type() != OMAP2_DEVICE_TYPE_GP)) {
> np = omap_get_timer_dt(omap_timer_match, "ti,timer-secure");
> - if (np)
> - of_node_put(np);
> + of_node_put(np);
> }
> }
>
> --
> 2.4.5
>
- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] clk: ti: clock driver code migration to drivers
On 07/16/2015 04:51 AM, Paul Walmsley wrote: On Tue, 14 Jul 2015, Tony Lindgren wrote: * Tero Kristo [150714 03:34]: On 07/14/2015 12:54 PM, Tony Lindgren wrote: * Tero Kristo [150714 01:56]: This pull request contains the TI clock driver set to move the clock implementations under clock driver. Some small portions of the clock driver code still remain under mach-omap2 after this, it should be decided whether this code is now obsolete and should be deleted or should someone try to fix it. Hmm care to clarify what is obsolete or broken after this series? Not after this series, was broken/obsolete already before. A couple of omap2/omap3 specific clock files still remain under mach-omap2, they are DVFS related. OMAP3 core dvfs support is currently completely unused (this could probably be removed, or shall we re-introduce the painful core dvfs at some point again?), and parts of the omap2 core dpll handling code should probably be re-written; or at least verified that it actually works properly. I can't test OMAP2 DVFS myself so don't dare to fiddle with it I could probably try to get some sort of DVFS test case to work on the board farm OMAP2 board I have access to though, I can investigate this. People seem to still want the 1 GiHz support, but I think that only depends on the SmartReflex and some kind of replacement for voltagedomains. So if the core DVFS support is unused, I doubt it's very high on anybody's list right now. At least several years ago, basic CORE DVFS support was working on OMAP3. The clock source changed rate, DRAM parameters were changed on the SDRC, etc. What was not implemented was pre-rate-change and post-rate-change notifiers in many of the device drivers, because the infrastructure didn't exist at the time in the clock code. Yes this is true, Nokia did an internal implementation for the pre/post notifier stuff which was never accepted upstream. The core dvfs code is no longer used in kernel for anything, it is just built in. The usefulness of the whole feature can be debated also, the use cases where it actually gives power savings is rather limited. I'll post a patch to remove the 'dead' core-dvfs code to the list, we can debate the issue there. -Tero -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] add pwm capability to dm816x
Hello Brian,
On Mon, 15 Jun 2015, Brian Hutchinson wrote:
> Clocks 4-7 are capable of PWM output on dm816x.
>
> This adds the pwm capability to those timers.
>
> Cc: Paul Walmsley
> Cc: Tero Kristo
> Cc: Tony Lindgren
> Signed-off-by: Brian Hutchinson >
This patch seems to be corrupted. The above line doesn't look right;
there are some spurious newlines in the patch header, and tabs seem to
have been converted to whitespace. Some of these issues may be due to
mailer problems. Could you please fix and try again?
- Paul
>
> --- arch/arm/mach-omap2/omap_hwmod_81xx_data.c_orig 2015-06-15
> 13:20:43.174343431 -0400
> +++ arch/arm/mach-omap2/omap_hwmod_81xx_data.c 2015-06-15
> 13:34:51.770551392 -0400
> @@ -546,6 +546,14 @@ static struct omap_timer_capability_dev_
> .timer_capability = OMAP_TIMER_ALWON,
> };
>
> +/* pwm timers dev attribute.
> + * timers 4-7 may be used for PWM output - see datasheet timer terminal
> + * functions table
> + */
> +static struct omap_timer_capability_dev_attr capability_pwm_dev_attr = {
> + .timer_capability = OMAP_TIMER_ALWON | OMAP_TIMER_HAS_PWM,
> +};
> +
> static struct omap_hwmod dm816x_timer1_hwmod = {
> .name = "timer1",
> .clkdm_name = "alwon_l3s_clkdm",
> @@ -619,7 +627,7 @@ static struct omap_hwmod dm816x_timer4_h
> .modulemode = MODULEMODE_SWCTRL,
> },
> },
> - .dev_attr = &capability_alwon_dev_attr,
> + .dev_attr = &capability_pwm_dev_attr,
> .class = &dm816x_timer_hwmod_class,
> };
>
> @@ -640,7 +648,7 @@ static struct omap_hwmod dm816x_timer5_h
> .modulemode = MODULEMODE_SWCTRL,
> },
> },
> - .dev_attr = &capability_alwon_dev_attr,
> + .dev_attr = &capability_pwm_dev_attr,
> .class = &dm816x_timer_hwmod_class,
> };
>
> @@ -661,7 +669,7 @@ static struct omap_hwmod dm816x_timer6_h
> .modulemode = MODULEMODE_SWCTRL,
> },
> },
> - .dev_attr = &capability_alwon_dev_attr,
> + .dev_attr = &capability_pwm_dev_attr,
> .class = &dm816x_timer_hwmod_class,
> };
>
> @@ -682,7 +690,7 @@ static struct omap_hwmod dm816x_timer7_h
> .modulemode = MODULEMODE_SWCTRL,
> },
> },
> - .dev_attr = &capability_alwon_dev_attr,
> + .dev_attr = &capability_pwm_dev_attr,
> .class = &dm816x_timer_hwmod_class,
> };
>
- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2: Delete unnecessary checks before three function calls
* Paul Walmsley [150715 22:58]: > Hello Markus > > On Tue, 30 Jun 2015, SF Markus Elfring wrote: > > > From: Markus Elfring > > Date: Tue, 30 Jun 2015 14:00:16 +0200 > > > > The functions clk_disable(), of_node_put() and omap_device_delete() test > > whether their argument is NULL and then return immediately. > > Thus the test around the call is not needed. > > > > This issue was detected by using the Coccinelle software. > > > > Signed-off-by: Markus Elfring > > Thanks for the patch. I have to say, I am a bit leery about applying the > omap_device.c and omap_hwmod.c changes, since the called functions -- > omap_device_delete() and clk_disable() -- don't explicitly document that > NULLs are allowed to be passed in. So there's no explicit contract that > callers can rely upon, to (at least in theory) prevent those internal NULL > pointer checks from being removed. > > So I would suggest that those two functions' kerneldoc be patched first to > explicitly state that passing in a NULL pointer is allowed. Then I would > feel a bit more comfortable applying the omap_device.c and omap_hwmod.c > changes. > > The kerneldoc for of_node_put() does explicitly allow NULLs to be passed > in. So I'll apply that change now for v4.3, touching up the commit > message accordingly. I have them applied from a later thread already, but will drop both in my branch as I have not pushed them out yet. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] Input: tsc2005 - convert to regmap
On Wed, Jul 15, 2015 at 02:13:26PM +0200, Sebastian Reichel wrote:
> -static int tsc2005_write(struct tsc2005 *ts, u8 reg, u16 value)
> -{
> - u32 tx = ((reg | TSC2005_REG_PND0) << 16) | value;
> - struct spi_transfer xfer = {
> - .tx_buf = &tx,
> - .len= 4,
> - .bits_per_word = 24,
> - };
I wonder why the original code used 24 bit-sized-words for transfers...
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ARM: OMAP2: Delete unnecessary checks before three function calls
> I have to say, I am a bit leery about applying the omap_device.c and > omap_hwmod.c changes, since the called functions -- omap_device_delete() > and clk_disable() -- don't explicitly document that NULLs are allowed > to be passed in. How are the chances to improve documentation around such implementation details? > So there's no explicit contract that callers can rely upon, to (at least > in theory) prevent those internal NULL pointer checks from being removed. Are there any additional variations to consider for source files from different processor architectures? > So I would suggest that those two functions' kerneldoc be patched first to > explicitly state that passing in a NULL pointer is allowed. Should my static source code analysis approach help you any more to clarify further open issues? > So I'll apply that change now for v4.3, touching up the commit message > accordingly. Thanks for your constructive feedback. >> arch/arm/mach-omap2/omap_device.c | 3 +-- >> arch/arm/mach-omap2/omap_hwmod.c | 5 + >> arch/arm/mach-omap2/timer.c | 3 +-- Did Tony Lindgren pick a similar update suggestion up, too? https://lkml.org/lkml/2015/7/15/112 Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] ARM: omap2: restore OMAP4 barrier behaviour
Hi, * Russell King [150715 10:50]: > Restore the OMAP4 barrier behaviour using the new implementation which > allows multiplatform systems to hook into the mb() and wmb() ARM > implementations to perform any necessary additional barrier maintanence. I'm getthing this with omap2plus_defconfig with the last patch applied: arch/arm/mach-omap2/omap4-common.c: In function ‘omap4_sram_init’: arch/arm/mach-omap2/omap4-common.c:138:14: error: implicit declaration of function ‘of_get_named_gen_pool’ [-Werror=implicit-function-declaration] sram_pool = of_get_named_gen_pool(np, "sram", 0); ^ arch/arm/mach-omap2/omap4-common.c:138:12: warning: assignment makes pointer from integer without a cast [-Wint-conversion] sram_pool = of_get_named_gen_pool(np, "sram", 0); ^ Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
