Re: [PATCHv3 08/35] clk: ti: fix ti_clk_get_reg_addr error handling
On 03/18/2015 07:02 PM, Tony Lindgren wrote: * Tero Kristo t-kri...@ti.com [150318 00:06]: On 03/17/2015 08:38 PM, Tony Lindgren wrote: * Mike Turquette mturque...@linaro.org [150306 11:18]: Quoting Tero Kristo (2015-02-25 11:04:18) There is a case where NULL can be a valid return value for ti_clk_get_reg_addr, specifically the case where both the provider index and register offsets are zero. In this case, the current error checking against a NULL pointer will fail. Thus, change the API to return a ERR_PTR value in an error case, and change all the users of this API to check against IS_ERR instead. Signed-off-by: Tero Kristo t-kri...@ti.com Cc: Michael Turquette mturque...@linaro.org Looks good to me. ... --- drivers/clk/ti/apll.c |5 +++-- drivers/clk/ti/autoidle.c |2 +- drivers/clk/ti/clk.c |7 --- drivers/clk/ti/divider.c |4 ++-- drivers/clk/ti/dpll.c |6 +++--- drivers/clk/ti/gate.c |4 ++-- drivers/clk/ti/interface.c |2 +- drivers/clk/ti/mux.c |4 ++-- 8 files changed, 18 insertions(+), 16 deletions(-) Can this patch be queued separately by Mike or is there some dependency to this series? Without this patch, patch #10 in the set causes a boot failure on omap3, because the specific NULL value is returned for iva2_ck and the clock register fails. This in turn breaks hwmod registration because iva2_ck is missing. Oh OK. I would just queue this patch as part of this series to avoid any trouble. Can this patch be applied separately before this series or does it cause other problems? If it can be separated, Mike can maybe put it into an immutable branch that I can merge in too. Yea, that works also if Mike is okay with it. -Tero Other than wondering about the above and the dts related comments, this series works for me with PM tests. I hope to post a series with the dts related comments fixed later today. Yes I'll take a look, thanks for doing that. 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: [PATCHv4 23/35] ARM: OMAP2+: id: cache omap_type value
On 03/18/2015 08:24 PM, Sergei Shtylyov wrote:
Hello.
On 03/18/2015 05:44 PM, Tero Kristo wrote:
There is no need to read the register with every invocation of the
function,
as the value is constant. Thus, cache the value in a static variable.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/id.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 2a2f4d5..1f5949f 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -52,7 +52,10 @@ EXPORT_SYMBOL(omap_rev);
int omap_type(void)
{
-u32 val = 0;
+static u32 val = OMAP2_DEVICETYPE_MASK + 1;
+
+if (val OMAP2_DEVICETYPE_MASK)
=, perhaps?
Hmm right, there is something fishy with this patch. Basically either
comparison works as the MASK is a shifted value which is always several
magnitudes larger than the resulting omap_type value itself. The +1 part
in the init value is completely unnecessary though.
-Tero
+return val;
[...]
WBR, Sergei
--
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/8] gpio: omap: cleanup: get rid of system GPIO - GPIO offset converseations
* grygorii.stras...@linaro.org grygorii.stras...@linaro.org [150319 10:26]: From: Grygorii Strashko grygorii.stras...@linaro.org Now in TI OMAP GPIO driver there are a lot of places where System GPIO number calculated and then converted to GPIO offset. What is worse is that in many place such conversation performed twice or even three times. But actually, we don't need to do that at all, because - gpiolib always passes GPIO offset to GPIO controller - OMAP GPIO driver converted to use IRQ domain, so struct irq_data-hwirq contains GPIO offset Hence, it is safe to convert all GPIO OMAP functions to use GPIO offset instead of system GPIO numbers. Also, this allows to remove unneeded conversations routines #define GPIO_INDEX(bank, gpio) #define GPIO_BIT(bank, gpio) int omap_irq_to_gpio() Right on! This is excellent news. I've tested this set on top of -rc4 plus the patch mentioned below, and I'm not seeing regressions on the platforms I tested with. Wake up to smsc911x ping with off-idle still works on omap3. I only briefly tested on omap1 (osk5912), so I'like to wait for Aaro's ack before this gets merged. I found one build error, other than that, for the whole series please feel free to add: Tested-by: Tony Lindgren t...@atomide.com Tested on dra7-evm. Last two patches have to be tested on OMAP1: - gpio: omap: get rid of omap_irq_to_gpio() - gpio: omap: get rid of GPIO_INDEX() macro Based on top of Linux 4.0-rc4 plus patch '[PATCH 1/2] gpio: omap: irq_shutdown: remove unnecessary call of gpiochip_unlock_as_irq' http://www.spinics.net/lists/linux-omap/msg116482.html Grygorii Strashko (8): gpio: omap: convert omap_gpio_is_input() to use gpio offset gpio: omap: simplify omap_set_gpio_dataout_x() gpio: omap: convert debounce functions switch to use gpio offset gpio: omap: drop 'gpio' param from omap_gpio_init_irq() gpio: omap: convert gpio irq functions to use GPIO offset gpio: omap: get rid of GPIO_BIT() macro gpio: omap: get rid of omap_irq_to_gpio() gpio: omap: get rid of GPIO_INDEX() macro drivers/gpio/gpio-omap.c | 130 --- 1 file changed, 55 insertions(+), 75 deletions(-) -- 1.9.1 -- 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
[GIT PULL 1/3] omap device tree changes for v4.1, part1
The following changes since commit 13a7a6ac0a11197edcd0f756a035f472b42cdf8b: Linux 4.0-rc2 (2015-03-03 09:04:59 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/v4.1-dt for you to fetch changes up to 10709c0858d89716b10b7bbf6d825044f2f59602: ARM: dts: Update Nanobone dts file (2015-03-19 10:59:28 -0700) Device tree related changes for omaps: - Add support for ChiliSOM - Add support for OpenPandora - Add support for BeagleBoard NAND - Enable crypto devices for omap3 devices - Add bindings for omap3 camera support - Updates for am437x and dra7x and dm816x SoCs Felipe Balbi (1): ARM: dts: am437x-idk: enable i2c2 H. Nikolaus Schaller (3): ARM: dts: omap3-pandora: add common device tree ARM: dts: omap3-pandora: add OMAP3530 600 MHz version ARM: dts: omap3-pandora: add DM3730 1 GHz version Marek Belisko (2): ARM: dts: omap3: Remove all references to ti,codec property Documentation: omap-twl4030: Move ti,codec property to optional Mark Jackson (1): ARM: dts: Update Nanobone dts file Matt Porter (1): Documentation: DT: omap_serial: document missing properties and add an example Pali Rohár (4): ARM: dts: n9/n950: Enable omap crypto support ARM: dts: n900: Enable omap sham and include directly omap34xx.dtsi ARM: dts: omap3-tao3530: Include directly omap34xx.dtsi ARM: dts: Remove files omap34xx-hs.dtsi and omap36xx-hs.dtsi Peter Ujfalusi (2): ARM: dts: dra7xx-clocks: Add gate clock for CLKOUT2 ARM: dts: am57xx-beagle-x15: Do not include the atl header Roger Quadros (2): ARM: dts: omap3-beagle: Add NAND device ARM: dts: dra7x-evm: beagle-x15: Fix USB Peripheral Rostislav Lisovy (3): ARM: dts: Add vendor prefix for Grinn ARM: dts: am335x: Add DTS for ChiliSOM module ARM: dts: am335x: Add Chiliboard DTS Sakari Ailus (3): Documentation: DT: Add bindings for omap3isp ARM: dts: omap3: Add DT entries for OMAP 3 ISP ARM: dts: n950, n9: Add primary camera support Suman Anna (1): ARM: dts: DRA7: Remove ti,timer-dsp and ti,timer-pwm properties Tony Lindgren (3): ARM: dts: Fix typo for dm816x usb0_pins ARM: dts: Add cppi41 support for dm816x MUSB ARM: dts: Remove PIN_INPUT for dm816x McSPI Vignesh R (1): ARM: dts: AM4372: update hdq compatible property .../devicetree/bindings/media/ti,omap3isp.txt | 71 +++ .../devicetree/bindings/serial/omap_serial.txt | 20 + .../devicetree/bindings/sound/omap-twl4030.txt | 3 +- .../devicetree/bindings/vendor-prefixes.txt| 1 + MAINTAINERS| 1 + arch/arm/boot/dts/Makefile | 5 +- arch/arm/boot/dts/am335x-chiliboard.dts| 112 arch/arm/boot/dts/am335x-chilisom.dtsi | 239 arch/arm/boot/dts/am335x-nano.dts | 18 +- arch/arm/boot/dts/am4372.dtsi | 2 +- arch/arm/boot/dts/am437x-idk-evm.dts | 22 + arch/arm/boot/dts/am57xx-beagle-x15.dts| 9 +- arch/arm/boot/dts/dm8168-evm.dts | 14 +- arch/arm/boot/dts/dm816x.dtsi | 60 ++ arch/arm/boot/dts/dra7-evm.dts | 8 + arch/arm/boot/dts/dra7.dtsi| 7 - arch/arm/boot/dts/dra72-evm.dts| 8 + arch/arm/boot/dts/dra7xx-clocks.dtsi | 8 + arch/arm/boot/dts/omap3-beagle-xm.dts | 1 - arch/arm/boot/dts/omap3-beagle.dts | 53 +- arch/arm/boot/dts/omap3-cm-t3x30.dtsi | 1 - arch/arm/boot/dts/omap3-devkit8000.dts | 1 - arch/arm/boot/dts/omap3-gta04.dtsi | 1 - arch/arm/boot/dts/omap3-igep.dtsi | 1 - arch/arm/boot/dts/omap3-lilly-a83x.dtsi| 1 - arch/arm/boot/dts/omap3-n9.dts | 37 ++ arch/arm/boot/dts/omap3-n900.dts | 16 +- arch/arm/boot/dts/omap3-n950-n9.dtsi | 2 +- arch/arm/boot/dts/omap3-n950.dts | 37 ++ arch/arm/boot/dts/omap3-overo-base.dtsi| 1 - arch/arm/boot/dts/omap3-pandora-1ghz.dts | 70 +++ arch/arm/boot/dts/omap3-pandora-600mhz.dts | 65 +++ arch/arm/boot/dts/omap3-pandora-common.dtsi| 640 + arch/arm/boot/dts/omap3-tao3530.dtsi | 12 +- arch/arm/boot/dts/omap34xx-hs.dtsi | 16 - arch/arm/boot/dts/omap34xx.dtsi| 17 + arch/arm/boot/dts/omap36xx-hs.dtsi | 16 - arch/arm/boot/dts/omap36xx.dtsi| 17 + include/dt-bindings/media/omap3-isp.h | 22 + 39 files changed, 1565 insertions(+), 70
[GIT PULL 2/3] omap defconfig changes for v4.1
The following changes since commit c517d838eb7d07bbe9507871fab3931deccff539: Linux 4.0-rc1 (2015-02-22 18:21:14 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/v4.1-defconfig for you to fetch changes up to 1fd6d08cbd4bd8984241c7cef2f7c5cb67fce1aa: ARM: omap2plus_defconfig: Enable n900 modem as loadable modules (2015-03-16 12:48:44 -0700) Few omap2plus_defconfig updates to add commonly used drivers as loadable modules. Note that I'll do patches for armv7_defconfig for these at some point too once we're happy with omap2plus_defconfig to avoid extra churn on the defconfig files. Felipe Balbi (1): arm: config: omap2plus_defconfig: switch over to LZMA compression Paul Walmsley (1): ARM: omap1_defconfig: drop obsolete Kconfig symbols Roger Quadros (1): ARM: omap2plus_defconfig: Enable EXTCON_GPIO_USB Tony Lindgren (3): ARM: omap2plus_defconfig: Enable leds-pwm ARM: omap2plus_defconfig: Update bluetooth options ARM: omap2plus_defconfig: Enable n900 modem as loadable modules arch/arm/configs/omap1_defconfig | 16 arch/arm/configs/omap2plus_defconfig | 27 +++ 2 files changed, 27 insertions(+), 16 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
[GIT PULL 3/3] omap legacy boot clean-up for v4.1
The following changes since commit c517d838eb7d07bbe9507871fab3931deccff539: Linux 4.0-rc1 (2015-02-22 18:21:14 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/v4.1-legacy for you to fetch changes up to 01ea0d4247bb3a224a66007e0a1291232c15d61a: ARM: OMAP2+: Remove legacy support for omap3 TouchBook (2015-03-16 17:07:26 -0700) Drop three omap3 legacy board-*.c files We want to get omap3 moved over to device tree only based booting. These three board-*.c files seem to be inactive, so let's attempt to drop them now rather than later. With these dropped, we have omap3 device tree conversion status in a known state. Then we know that we have .dts support for the remaining omap3 board-*.c files, or it's being worked on. By dropping these files now, we can simply revert them if really needed for the next few merge cycles if we run into suprises. Reverting things later on will not be so easily done. Tony Lindgren (3): ARM: OMAP3: Remove legacy support for EMA-Tech Stalker board ARM: OMAP3: Remove legacy support for devkit8000 ARM: OMAP2+: Remove legacy support for omap3 TouchBook arch/arm/mach-omap2/Kconfig| 18 - arch/arm/mach-omap2/Makefile | 4 - arch/arm/mach-omap2/board-devkit8000.c | 654 - arch/arm/mach-omap2/board-omap3stalker.c | 433 --- arch/arm/mach-omap2/board-omap3touchbook.c | 395 - 5 files changed, 1504 deletions(-) delete mode 100644 arch/arm/mach-omap2/board-devkit8000.c delete mode 100644 arch/arm/mach-omap2/board-omap3stalker.c delete mode 100644 arch/arm/mach-omap2/board-omap3touchbook.c -- 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 v3] phy: Add a driver for dm816x USB PHY
Add a minimal driver for dm816x USB. This makes USB work on dm816x
without any other changes needed as it can use the existing musb_dsps
glue layer for the USB controller.
Note that this phy is different from dm814x and am335x.
Cc: Bin Liu binml...@gmail.com
Cc: Brian Hutchinson b.hutch...@gmail.com
Cc: Felipe Balbi ba...@ti.com
Cc: Matthijs van Duin matthijsvand...@gmail.com
Cc: Paul Bolle pebo...@tiscali.nl
Cc: Rusty Russell ru...@rustcorp.com.au
Signed-off-by: Tony Lindgren t...@atomide.com
---
.../devicetree/bindings/phy/dm816x-phy.txt | 24 ++
drivers/phy/Kconfig| 7 +
drivers/phy/Makefile | 1 +
drivers/phy/phy-dm816x-usb.c | 290 +
4 files changed, 322 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/dm816x-phy.txt
create mode 100644 drivers/phy/phy-dm816x-usb.c
diff --git a/Documentation/devicetree/bindings/phy/dm816x-phy.txt
b/Documentation/devicetree/bindings/phy/dm816x-phy.txt
new file mode 100644
index 000..2fe3d11
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/dm816x-phy.txt
@@ -0,0 +1,24 @@
+Device tree binding documentation for am816x USB PHY
+=
+
+Required properties:
+- compatible : should be ti,dm816x-usb-phy
+- reg : offset and length of the PHY register set.
+- reg-names : name for the phy registers
+- clocks : phandle to the clock
+- clock-names : name of the clock
+- syscon: phandle for the syscon node to access misc registers
+- #phy-cells : from the generic PHY bindings, must be 1
+- syscon: phandle for the syscon node to access misc registers
+
+Example:
+
+usb_phy0: usb-phy@20 {
+ compatible = ti,dm8168-usb-phy;
+ reg = 0x20 0x8;
+ reg-names = phy;
+ clocks = main_fapll 6;
+ clock-names = refclk;
+ #phy-cells = 0;
+ syscon = scm_conf;
+};
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 2962de2..08269ea 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -35,6 +35,13 @@ config ARMADA375_USBCLUSTER_PHY
depends on OF
select GENERIC_PHY
+config PHY_DM816X_USB
+ tristate TI dm816x USB PHY driver
+ depends on ARCH_OMAP2PLUS
+ select GENERIC_PHY
+ help
+ Enable this for dm81xx USB to work.
+
config PHY_EXYNOS_MIPI_VIDEO
tristate S5P/EXYNOS SoC series MIPI CSI-2/DSI PHY driver
depends on HAS_IOMEM
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index f080e1b..dab6665 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -5,6 +5,7 @@
obj-$(CONFIG_GENERIC_PHY) += phy-core.o
obj-$(CONFIG_PHY_BERLIN_USB) += phy-berlin-usb.o
obj-$(CONFIG_PHY_BERLIN_SATA) += phy-berlin-sata.o
+obj-$(CONFIG_PHY_DM816X_USB) += phy-dm816x-usb.o
obj-$(CONFIG_ARMADA375_USBCLUSTER_PHY) += phy-armada375-usb2.o
obj-$(CONFIG_BCM_KONA_USB2_PHY)+= phy-bcm-kona-usb2.o
obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO) += phy-exynos-dp-video.o
diff --git a/drivers/phy/phy-dm816x-usb.c b/drivers/phy/phy-dm816x-usb.c
new file mode 100644
index 000..7b42555
--- /dev/null
+++ b/drivers/phy/phy-dm816x-usb.c
@@ -0,0 +1,290 @@
+/*
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/regmap.h
+
+#include linux/slab.h
+#include linux/of.h
+#include linux/io.h
+#include linux/usb/phy_companion.h
+#include linux/clk.h
+#include linux/err.h
+#include linux/pm_runtime.h
+#include linux/delay.h
+#include linux/phy/phy.h
+#include linux/of_platform.h
+
+#include linux/mfd/syscon.h
+
+/*
+ * TRM has two sets of USB_CTRL registers.. The correct register bits
+ * are in TRM section 24.9.8.2 USB_CTRL Register. The TRM documents the
+ * phy as being SR70LX Synopsys USB 2.0 OTG nanoPHY. It also seems at
+ * least dm816x rev c ignores writes to USB_CTRL register, but the TI
+ * kernel is writing to those so it's possible that later revisions
+ * have worknig USB_CTRL register.
+ *
+ * Also note that At least USB_CTRL register seems to be dm816x specific
+ * according to the TRM. It's possible that USBPHY_CTRL is more generic,
+ * but that would have to be checked against the SR70LX documentation
+ * which does not seem to be publicly available.
+ *
+ * Finally, the phy on dm814x and am335x is different from dm816x.
+ */
+#define DM816X_USB_CTRL_PHYCLKSRC BIT(8) /* 1 = PLL ref clock */
+#define DM816X_USB_CTRL_PHYSLEEP1 BIT(1) /* Enable the first phy */
+#define
Re: [PATCH 5/8] gpio: omap: convert gpio irq functions to use GPIO offset
* grygorii.stras...@linaro.org grygorii.stras...@linaro.org [150319 10:26]:
From: Grygorii Strashko grygorii.stras...@linaro.org
Convert GPIO IRQ functions to use GPIO offset instead of system
GPIO numbers. This allows to drop unneeded conversations between
system GPIO - GPIO offset which are done in many places and
many times.
It is safe to do now because:
- gpiolib always passes GPIO offset to GPIO controller
- OMAP GPIO driver converted to use IRQ domain, so
struct irq_data-hwirq contains GPIO offset
This is preparation step before removing:
#define GPIO_INDEX(bank, gpio)
#define GPIO_BIT(bank, gpio)
int omap_irq_to_gpio()
...
static void omap_gpio_unmask_irq(struct irq_data *d)
{
struct gpio_bank *bank = omap_irq_data_get_bank(d);
- unsigned int gpio = omap_irq_to_gpio(bank, d-hwirq);
+ unsigned offset = d-hwirq;
unsigned int irq_mask = GPIO_BIT(bank, gpio);
u32 trigger = irqd_get_trigger_type(d);
unsigned long flags;
This series up to this patch produces a build error that
would break git bisect:
drivers/gpio/gpio-omap.c: In function ‘omap_gpio_unmask_irq’:
drivers/gpio/gpio-omap.c:866:37: error: ‘gpio’ undeclared (first use in this
function)
unsigned int irq_mask = GPIO_BIT(bank, gpio);
Applying the following patch makes things build again.
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: [RFC/RFT PATCH 2/2] gpio: omap: ensure that runtime pm will disable unused gpio banks
* Tony Lindgren t...@atomide.com [150307 00:08]: * grygorii.stras...@linaro.org grygorii.stras...@linaro.org [150306 11:27]: From: Grygorii Strashko grygorii.stras...@linaro.org Now there are two points related to Runtime PM usage: 1) bank state doesn't need to be checked in places where Rintime PM is used, bacause Runtime PM maintains its own usage counter: if (!BANK_USED(bank)) pm_runtime_get_sync(bank-dev); so, it's safe to drop such checks. 2) There is a call of pm_runtime_get_sync() in omap_gpio_irq_type(), but no corresponding put. As result, GPIO devices could be powered on forever if at least one GPIO was used as IRQ. Hence, allow powering off GPIO banks by adding missed pm_runtime_put(bank-dev) at the end of omap_gpio_irq_type(). Nice to see this happening, but I think before merging this we need to test to be sure that the pm_runtime calls actually match.. I'm not convinced right now.. We may still have uninitialized entry points similar to 3d009c8c61f9 (gpio: omap: Fix bad device access with setup_irq()). OK so I finally got around testing this along with your bank removal set. Looks like this patch causes a regression at least with n900 keyboard LEDs with off-idle. The LED won't come back on after restore from off-idle. Anyways, now we have something reproducable :) So I'll try to debug it further at some point, might be few days before I get to it. Regards, Tony Signed-off-by: Grygorii Strashko grygorii.stras...@linaro.org --- drivers/gpio/gpio-omap.c | 17 +++-- 1 file changed, 7 insertions(+), 10 deletions(-) diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c index 2b2fc4b..b1176c5 100644 --- a/drivers/gpio/gpio-omap.c +++ b/drivers/gpio/gpio-omap.c @@ -497,8 +497,7 @@ static int omap_gpio_irq_type(struct irq_data *d, unsigned type) unsigned long flags; unsigned offset; - if (!BANK_USED(bank)) - pm_runtime_get_sync(bank-dev); + pm_runtime_get_sync(bank-dev); #ifdef CONFIG_ARCH_OMAP1 if (d-irq IH_MPUIO_BASE) @@ -530,6 +529,8 @@ static int omap_gpio_irq_type(struct irq_data *d, unsigned type) else if (type (IRQ_TYPE_EDGE_FALLING | IRQ_TYPE_EDGE_RISING)) __irq_set_handler_locked(d-irq, handle_edge_irq); + pm_runtime_put(bank-dev); + return retval; } @@ -680,8 +681,7 @@ static int omap_gpio_request(struct gpio_chip *chip, unsigned offset) * If this is the first gpio_request for the bank, * enable the bank module. */ - if (!BANK_USED(bank)) - pm_runtime_get_sync(bank-dev); + pm_runtime_get_sync(bank-dev); spin_lock_irqsave(bank-lock, flags); /* Set trigger to none. You need to enable the desired trigger with @@ -713,8 +713,7 @@ static void omap_gpio_free(struct gpio_chip *chip, unsigned offset) * If this is the last gpio to be freed in the bank, * disable the bank module. */ - if (!BANK_USED(bank)) - pm_runtime_put(bank-dev); + pm_runtime_put(bank-dev); } /* @@ -807,8 +806,7 @@ static unsigned int omap_gpio_irq_startup(struct irq_data *d) unsigned long flags; unsigned offset = GPIO_INDEX(bank, gpio); - if (!BANK_USED(bank)) - pm_runtime_get_sync(bank-dev); + pm_runtime_get_sync(bank-dev); spin_lock_irqsave(bank-lock, flags); omap_gpio_init_irq(bank, gpio, offset); @@ -835,8 +833,7 @@ static void omap_gpio_irq_shutdown(struct irq_data *d) * If this is the last IRQ to be freed in the bank, * disable the bank module. */ - if (!BANK_USED(bank)) - pm_runtime_put(bank-dev); + pm_runtime_put(bank-dev); } static void omap_gpio_ack_irq(struct irq_data *d) -- 1.9.1 -- 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
[PATCH v2] usb: musb: Fix fifo reads for dm816x with musb_dsps
Looks like dm81xx can only do 32-bit fifo reads like am35x. Let's set
up musb-dsps with a custom read_fifo function based on the compatible
flag.
Otherwise we can get the following errors when starting dhclient on a
asix USB Ethernet adapter:
asix 2-1:1.0 eth2: asix_rx_fixup() Bad Header Length 0x003c, offset 4
While at it, let's also remove pointless cast of the driver data.
Cc: Bin Liu binml...@gmail.com
Cc: Brian Hutchinson b.hutch...@gmail.com
Cc: George Cherian george.cher...@ti.com
Cc: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
drivers/usb/musb/musb_dsps.c | 25 -
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index a900c98..2c0750e 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -655,6 +655,24 @@ static int dsps_musb_reset(struct musb *musb)
return !session_restart;
}
+/* Similar to am35x, dm81xx support only 32-bit read operation */
+static void dsps_read_fifo32(struct musb_hw_ep *hw_ep, u16 len, u8 *dst)
+{
+ void __iomem *fifo = hw_ep-fifo;
+
+ if (len = 4) {
+ readsl(fifo, dst, len 2);
+ dst += len ~0x03;
+ len = 0x03;
+ }
+
+ /* Read any remaining 1 to 3 bytes */
+ if (len 0) {
+ u32 val = musb_readl(fifo, 0);
+ memcpy(dst, val, len);
+ }
+}
+
static struct musb_platform_ops dsps_ops = {
.quirks = MUSB_INDEXED_EP,
.init = dsps_musb_init,
@@ -802,6 +820,9 @@ static int dsps_probe(struct platform_device *pdev)
}
wrp = match-data;
+ if (of_device_is_compatible(pdev-dev.of_node, ti,musb-dm816))
+ dsps_ops.read_fifo = dsps_read_fifo32;
+
/* allocate glue */
glue = devm_kzalloc(pdev-dev, sizeof(*glue), GFP_KERNEL);
if (!glue)
@@ -878,7 +899,9 @@ static const struct dsps_musb_wrapper am33xx_driver_data = {
static const struct of_device_id musb_dsps_of_match[] = {
{ .compatible = ti,musb-am33xx,
- .data = (void *) am33xx_driver_data, },
+ .data = am33xx_driver_data, },
+ { .compatible = ti,musb-dm816,
+ .data = am33xx_driver_data, },
{ },
};
MODULE_DEVICE_TABLE(of, musb_dsps_of_match);
--
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 to parameterize DMA_MIN_BYTES for omap2-mcspi
On Thu, Mar 19, 2015 at 01:05:01AM -0400, Greg Knight wrote: What is the process for getting this upstreamed? Please submit the patch following the process in Documentation/SubmittingPatches. signature.asc Description: Digital signature
Re: [PATCH 06/15] omap3isp: Refactor device configuration structs for Device Tree
On 03/16/15 02:26, Sakari Ailus wrote: Make omap3isp configuration data structures more suitable for consumption by the DT by separating the I2C bus information of all the sub-devices in a group and the ISP bus information from each other. The ISP bus information is made a pointer instead of being directly embedded in the struct. In the case of the DT only the sensor specific information on the ISP bus configuration is retained. The structs are renamed to reflect that. After this change the structs needed to describe device configuration can be allocated and accessed separately without those needed only in the case of platform data. The platform data related structs can be later removed once the support for platform data can be removed. Signed-off-by: Sakari Ailus sakari.ai...@iki.fi Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Cc: Igor Grinberg grinb...@compulab.co.il For cm-t35 stuff: Acked-by: Igor Grinberg grinb...@compulab.co.il -- Regards, Igor. -- 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 v2] ASoC: davinci-mcasp: Set rule constraints if implicit BCLK divider is used
Set rule constraints to allow only combinations of sample-rate,
sample-bits, and channels that can be played/captured with reasonable
sample-rate accuracy.
The logic with tdm-slots and serializers (=i2s data wires) goes like
this: The first wire will take all channels up to number of tdm-slots,
before following wires (if any) are used. If the first wire is used
fully, the remaining wires share the same clocks and the divider can
be calculated for the first wire.
Also, takes the number of tdm-slots into account when implicitly
selecting the BLCK divider.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
I hope the logic with tdm-slots and serializers is now correct. I do
not have HW to test multiple serializers case, so please review
davinci_mcasp_hw_rule_channels() extra carefully.
Best regards,
Jyri
sound/soc/davinci/davinci-mcasp.c | 195 --
1 file changed, 185 insertions(+), 10 deletions(-)
diff --git a/sound/soc/davinci/davinci-mcasp.c
b/sound/soc/davinci/davinci-mcasp.c
index de3b155..3b2fb56 100644
--- a/sound/soc/davinci/davinci-mcasp.c
+++ b/sound/soc/davinci/davinci-mcasp.c
@@ -26,6 +26,7 @@
#include linux/of.h
#include linux/of_platform.h
#include linux/of_device.h
+#include linux/math64.h
#include sound/asoundef.h
#include sound/core.h
@@ -64,6 +65,11 @@ struct davinci_mcasp_context {
u32 *xrsr_regs; /* for serializer configuration */
};
+struct davinci_mcasp_ruledata {
+ struct davinci_mcasp *mcasp;
+ int serializers;
+};
+
struct davinci_mcasp {
struct davinci_pcm_dma_params dma_params[2];
struct snd_dmaengine_dai_dma_data dma_data[2];
@@ -98,6 +104,8 @@ struct davinci_mcasp {
#ifdef CONFIG_PM_SLEEP
struct davinci_mcasp_context context;
#endif
+
+ struct davinci_mcasp_ruledata ruledata[2];
};
static inline void mcasp_set_bits(struct davinci_mcasp *mcasp, u32 offset,
@@ -855,6 +863,30 @@ static int mcasp_dit_hw_param(struct davinci_mcasp *mcasp,
return 0;
}
+static int davinci_mcasp_calc_clk_div(struct davinci_mcasp *mcasp,
+ unsigned int bclk_freq,
+ int *error_ppm)
+{
+ int div = mcasp-sysclk_freq / bclk_freq;
+ int rem = mcasp-sysclk_freq % bclk_freq;
+
+ if (rem != 0) {
+ if (div == 0 ||
+ ((mcasp-sysclk_freq / div) - bclk_freq)
+ (bclk_freq - (mcasp-sysclk_freq / (div+1 {
+ div++;
+ rem = rem - bclk_freq;
+ }
+ }
+ if (error_ppm)
+ *error_ppm =
+ (div*100 + (int)div64_long(100LL*rem,
+ (int)bclk_freq))
+ /div - 100;
+
+ return div;
+}
+
static int davinci_mcasp_hw_params(struct snd_pcm_substream *substream,
struct snd_pcm_hw_params *params,
struct snd_soc_dai *cpu_dai)
@@ -872,16 +904,20 @@ static int davinci_mcasp_hw_params(struct
snd_pcm_substream *substream,
* the machine driver, we need to calculate the ratio.
*/
if (mcasp-bclk_master mcasp-bclk_div == 0 mcasp-sysclk_freq) {
- unsigned int bclk_freq = snd_soc_params_to_bclk(params);
- unsigned int div = mcasp-sysclk_freq / bclk_freq;
- if (mcasp-sysclk_freq % bclk_freq != 0) {
- if (((mcasp-sysclk_freq / div) - bclk_freq)
- (bclk_freq - (mcasp-sysclk_freq / (div+1
- div++;
- dev_warn(mcasp-dev,
-Inaccurate BCLK: %u Hz / %u != %u Hz\n,
-mcasp-sysclk_freq, div, bclk_freq);
- }
+ int channels = params_channels(params);
+ int rate = params_rate(params);
+ int sbits = params_width(params);
+ int ppm, div;
+
+ if (channels mcasp-tdm_slots)
+ channels = mcasp-tdm_slots;
+
+ div = davinci_mcasp_calc_clk_div(mcasp, rate*sbits*channels,
+ppm);
+ if (ppm)
+ dev_info(mcasp-dev, Sample-rate is off by %d PPM\n,
+ppm);
+
__davinci_mcasp_set_clkdiv(cpu_dai, 1, div, 0);
}
@@ -973,6 +1009,108 @@ static int davinci_mcasp_trigger(struct
snd_pcm_substream *substream,
return ret;
}
+static const unsigned int davinci_mcasp_dai_rates[] = {
+ 8000, 11025, 16000, 22050, 32000, 44100, 48000, 64000,
+ 88200, 96000, 176400, 192000,
+};
+
+#define DAVINCI_MAX_RATE_ERROR_PPM 1000
+
+static int davinci_mcasp_hw_rule_rate(struct snd_pcm_hw_params *params,
+ struct snd_pcm_hw_rule
Re: [PATCH v2] ASoC: davinci-mcasp: Set rule constraints if implicit BCLK divider is used
On Thu, Mar 19, 2015 at 10:51:09AM +0200, Jyri Sarha wrote: Set rule constraints to allow only combinations of sample-rate, sample-bits, and channels that can be played/captured with reasonable sample-rate accuracy. This doesn't apply against current code, please check and resend. signature.asc Description: Digital signature
Re: [PATCH v2] ASoC: davinci-mcasp: Set rule constraints if implicit BCLK divider is used
On 03/19/2015 10:51 AM, Jyri Sarha wrote:
Set rule constraints to allow only combinations of sample-rate,
sample-bits, and channels that can be played/captured with reasonable
sample-rate accuracy.
The logic with tdm-slots and serializers (=i2s data wires) goes like
this: The first wire will take all channels up to number of tdm-slots,
before following wires (if any) are used. If the first wire is used
fully, the remaining wires share the same clocks and the divider can
be calculated for the first wire.
Also, takes the number of tdm-slots into account when implicitly
selecting the BLCK divider.
Looks good, thanks.
Acked-by: Peter Ujfalusi peter.ujfal...@ti.com
Signed-off-by: Jyri Sarha jsa...@ti.com
---
I hope the logic with tdm-slots and serializers is now correct. I do
not have HW to test multiple serializers case, so please review
davinci_mcasp_hw_rule_channels() extra carefully.
Best regards,
Jyri
sound/soc/davinci/davinci-mcasp.c | 195
--
1 file changed, 185 insertions(+), 10 deletions(-)
diff --git a/sound/soc/davinci/davinci-mcasp.c
b/sound/soc/davinci/davinci-mcasp.c
index de3b155..3b2fb56 100644
--- a/sound/soc/davinci/davinci-mcasp.c
+++ b/sound/soc/davinci/davinci-mcasp.c
@@ -26,6 +26,7 @@
#include linux/of.h
#include linux/of_platform.h
#include linux/of_device.h
+#include linux/math64.h
#include sound/asoundef.h
#include sound/core.h
@@ -64,6 +65,11 @@ struct davinci_mcasp_context {
u32 *xrsr_regs; /* for serializer configuration */
};
+struct davinci_mcasp_ruledata {
+ struct davinci_mcasp *mcasp;
+ int serializers;
+};
+
struct davinci_mcasp {
struct davinci_pcm_dma_params dma_params[2];
struct snd_dmaengine_dai_dma_data dma_data[2];
@@ -98,6 +104,8 @@ struct davinci_mcasp {
#ifdef CONFIG_PM_SLEEP
struct davinci_mcasp_context context;
#endif
+
+ struct davinci_mcasp_ruledata ruledata[2];
};
static inline void mcasp_set_bits(struct davinci_mcasp *mcasp, u32 offset,
@@ -855,6 +863,30 @@ static int mcasp_dit_hw_param(struct davinci_mcasp
*mcasp,
return 0;
}
+static int davinci_mcasp_calc_clk_div(struct davinci_mcasp *mcasp,
+ unsigned int bclk_freq,
+ int *error_ppm)
+{
+ int div = mcasp-sysclk_freq / bclk_freq;
+ int rem = mcasp-sysclk_freq % bclk_freq;
+
+ if (rem != 0) {
+ if (div == 0 ||
+ ((mcasp-sysclk_freq / div) - bclk_freq)
+ (bclk_freq - (mcasp-sysclk_freq / (div+1 {
+ div++;
+ rem = rem - bclk_freq;
+ }
+ }
+ if (error_ppm)
+ *error_ppm =
+ (div*100 + (int)div64_long(100LL*rem,
+(int)bclk_freq))
+ /div - 100;
+
+ return div;
+}
+
static int davinci_mcasp_hw_params(struct snd_pcm_substream *substream,
struct snd_pcm_hw_params *params,
struct snd_soc_dai *cpu_dai)
@@ -872,16 +904,20 @@ static int davinci_mcasp_hw_params(struct
snd_pcm_substream *substream,
* the machine driver, we need to calculate the ratio.
*/
if (mcasp-bclk_master mcasp-bclk_div == 0 mcasp-sysclk_freq) {
- unsigned int bclk_freq = snd_soc_params_to_bclk(params);
- unsigned int div = mcasp-sysclk_freq / bclk_freq;
- if (mcasp-sysclk_freq % bclk_freq != 0) {
- if (((mcasp-sysclk_freq / div) - bclk_freq)
- (bclk_freq - (mcasp-sysclk_freq / (div+1
- div++;
- dev_warn(mcasp-dev,
- Inaccurate BCLK: %u Hz / %u != %u Hz\n,
- mcasp-sysclk_freq, div, bclk_freq);
- }
+ int channels = params_channels(params);
+ int rate = params_rate(params);
+ int sbits = params_width(params);
+ int ppm, div;
+
+ if (channels mcasp-tdm_slots)
+ channels = mcasp-tdm_slots;
+
+ div = davinci_mcasp_calc_clk_div(mcasp, rate*sbits*channels,
+ ppm);
+ if (ppm)
+ dev_info(mcasp-dev, Sample-rate is off by %d PPM\n,
+ ppm);
+
__davinci_mcasp_set_clkdiv(cpu_dai, 1, div, 0);
}
@@ -973,6 +1009,108 @@ static int davinci_mcasp_trigger(struct
snd_pcm_substream *substream,
return ret;
}
+static const unsigned int davinci_mcasp_dai_rates[] = {
+ 8000, 11025, 16000, 22050, 32000, 44100, 48000, 64000,
+ 88200, 96000, 176400, 192000,
+};
+
+#define DAVINCI_MAX_RATE_ERROR_PPM 1000
Re: [RFC][PATCH 3/9] usb: otg: add OTG core
On 19/03/15 05:40, Peter Chen wrote:
On Wed, Mar 18, 2015 at 03:55:57PM +0200, Roger Quadros wrote:
The OTG core instantiates the OTG Finite State Machine
per OTG controller and manages starting/stopping the
host and gadget controllers based on the bus state.
It provides APIs for the following tasks
- Registering an OTG capable controller
- Registering Host and Gadget controllers to OTG core
- Providing inputs to and kicking the OTG state machine
TODO:
- sysfs interface to allow application inputs to OTG state machine
- otg class?
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/usb/Makefile | 1 +
drivers/usb/common/Makefile | 1 +
drivers/usb/common/usb-otg.c | 732
+++
drivers/usb/common/usb-otg.h | 71 +
drivers/usb/core/Kconfig | 8 +
include/linux/usb/usb-otg.h | 86 +
6 files changed, 899 insertions(+)
create mode 100644 drivers/usb/common/usb-otg.c
create mode 100644 drivers/usb/common/usb-otg.h
create mode 100644 include/linux/usb/usb-otg.h
diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
index 2f1e2aa..07f59a5 100644
--- a/drivers/usb/Makefile
+++ b/drivers/usb/Makefile
@@ -60,5 +60,6 @@ obj-$(CONFIG_USB_RENESAS_USBHS)+= renesas_usbhs/
obj-$(CONFIG_USB_GADGET)+= gadget/
obj-$(CONFIG_USB_COMMON)+= common/
+obj-$(CONFIG_USB_OTG_CORE) += common/
obj-$(CONFIG_USBIP_CORE)+= usbip/
diff --git a/drivers/usb/common/Makefile b/drivers/usb/common/Makefile
index ca2f8bd..573fc75 100644
--- a/drivers/usb/common/Makefile
+++ b/drivers/usb/common/Makefile
@@ -7,3 +7,4 @@ usb-common-y += common.o
usb-common-$(CONFIG_USB_LED_TRIG) += led.o
obj-$(CONFIG_USB_OTG_FSM) += usb-otg-fsm.o
+obj-$(CONFIG_USB_OTG_CORE) += usb-otg.o
diff --git a/drivers/usb/common/usb-otg.c b/drivers/usb/common/usb-otg.c
new file mode 100644
index 000..1433fc9
--- /dev/null
+++ b/drivers/usb/common/usb-otg.c
@@ -0,0 +1,732 @@
+/**
+ * drivers/usb/common/usb-otg.c - USB OTG core
+ *
+ * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com
+ * Author: Roger Quadros rog...@ti.com
+ *
+ * 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 useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/kernel.h
+#include linux/list.h
+#include linux/timer.h
+#include linux/usb/otg.h
+#include linux/usb/phy.h /* enum usb_otg_state */
+#include linux/usb/gadget.h
+#include linux/usb/usb-otg.h
+#include linux/workqueue.h
+
+#include usb-otg.h
+
+/* to link timer with callback data */
+struct otg_timer {
+struct timer_list timer;
+/* callback data */
+int *timeout_bit;
+struct otg_data *otgd;
+};
+
+struct otg_data {
+struct device *dev; /* HCD GCD's parent device */
+
+struct otg_fsm fsm;
+/* HCD, GCD and usb_otg_state are present in otg_fsm-otg
+ * HCD is bus_to_hcd(fsm-otg-host)
+ * GCD is fsm-otg-gadget
+ */
+struct otg_fsm_ops fsm_ops; /* private copy for override */
+struct usb_otg otg;
+struct usb_hcd *shared_hcd; /* if shared HCD registered */
+
+/* saved hooks to OTG device */
+int (*start_host)(struct otg_fsm *fsm, int on);
+int (*start_gadget)(struct otg_fsm *fsm, int on);
+
+struct list_head list;
+
+struct work_struct work;/* OTG FSM work */
+struct workqueue_struct *wq;
+
+struct otg_timer timers[NUM_OTG_FSM_TIMERS];
+
+bool fsm_running;
+bool gadget_can_start; /* OTG FSM says gadget can start */
+bool host_can_start;/* OTG FSM says host can start */
+
+/* use otg-fsm.lock for serializing access */
+};
What's the relationship between struct usb_otg otg and this one?
Did you mean why struct usb_otg otg is there in struct otg_data?
Just for easy allocation. fsm_ops only contains the pointer to struct usb_otg.
+
+/* OTG device list */
+LIST_HEAD(otg_list);
+static DEFINE_MUTEX(otg_list_mutex);
+
+/**
+ * check if device is in our OTG list and return
+ * otg_data, else NULL.
+ *
+ * otg_list_mutex must be held.
+ */
+static struct otg_data *usb_otg_device_get_otgd(struct device *parent_dev)
+{
+struct otg_data *otgd;
+
+list_for_each_entry(otgd, otg_list, list) {
+if (otgd-dev == parent_dev)
+return otgd;
+}
+
+return NULL;
+}
+
+/**
+ * timer callback to set timeout bit and kick FSM
+ */
+static void set_tmout(unsigned long data)
+{
+struct otg_timer *tmr_data;
+
+tmr_data = (struct otg_timer
Re: [RFC][PATCH 0/9] USB: OTG Core functionality
On 18/03/15 19:37, Tony Lindgren wrote: * Roger Quadros rog...@ti.com [150318 07:00]: Hi, [NOTE: RFC only. Not for merge yet.] This is an attempt to centralize OTG functionality in the kernel. Still work in progress but I wanted to get an early feedback to avoid major rework. :) Why?: Most of the OTG drivers have been dealing with the OTG state machine themselves and there is a scope for code re-use. This has been partly addressed by the usb/common/usb-otg-fsm.c but it still leaves the instantiation of the state machine and OTG timers to the controller drivers. We re-use usb-otg-fsm.c but go one step further by instantiating the state machine and timers thus making it easier for drivers to implement OTG functionality. Newer OTG cores support standard host interface (e.g. xHCI?) so host and gadget functionality are no longer closely knit like older cores. There needs to be a way to co-ordinate the operation of the host and gadget in OTG mode. i.e. to stop and start them from a central location. This central location should be the USB OTG core. Host and gadget controllers might be sharing resources and can't be always running. One has to be stopped for the other to run. This can't be done as of now and can be done from the OTG core. What?: - The OTG core instantiates the OTG Finite State Machine per OTG controller and manages starting/stopping the host and gadget controllers based on the bus state. It provides APIs for the following - Registering an OTG capable controller struct otg_fsm *usb_otg_register(struct device *parent_dev, struct otg_fsm_ops *fsm_ops); int usb_otg_unregister(struct device *parent_dev); - Registering Host controllers to OTG core (used by hcd-core) int usb_otg_register_hcd(struct usb_hcd *hcd); int usb_otg_unregister_hcd(struct usb_hcd *hcd); - Registering Gadget controllers to OTG core (used by udc-core) int usb_otg_register_gadget(struct usb_gadget *gadget); int usb_otg_unregister_gadget(struct usb_gadget *gadget); - Providing inputs to and kicking the OTG state machine void usb_otg_sync_inputs(struct otg_fsm *fsm); int usb_otg_kick_fsm(struct device *hcd_gcd_device); 'struct otg_fsm' is the interface to the OTG state machine. It contains inputs to the fsm, status of the fsm and operations for the OTG controller driver. Sounds good to me. I take you're also planning to provide some common /sys/kernel/debug/otg type interfaces for OTG validation tests? For things like SRP etc. Yes that's the plan. cheers, -roger Regards, Tony 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. - The host/gadget core stacks are modified to inform the OTG core whenever a new host/gadget device is added. The OTG core then checks if the host/gadget is part of the OTG controller and if yes then prevents the host/gadget from starting till both host and gadget are registered, OTG state machine is running and the USB bus state is appropriate to start host/gadget. For this APIs have been added to host/gadget stacks to start/stop the controllers from the OTG core. - No modification is needed for the host/gadget controller drivers. They must ensure that their start/stop methods can be called repeatedly and any shared resources between host gadget are properly managed. The OTG core ensures that both are not started simultaneously. - The OTG core instantiates one OTG state machine per OTG controller and the necessary OTG timers to manage OTG state timeouts. The state machine is started when both host gadget register and stopped when either of them unregisters. The controllers are started and stopped depending on bus state. - During the lifetime of the OTG state machine, inputs can be provided to it by modifying the appropriate members of 'struct otg_fsm' and calling usb_otg_sync_inputs(). This is typically done by the OTG controller driver that called usb_otg_register() since it is the only external component that has the 'struct otg_fsm' handle. Pending items: - We probably need a otg class. - sysfs interface for application OTG inputs and OTG status information - resolve symbol dependency for module use. - otg driver for dwc3 core to get dual-role working on dra7-evm. cheers, -roger Roger Quadros (9): usb: hcd: Introduce usb_start/stop_hcd() usb: gadget: add usb_gadget_start/stop() usb: otg: add OTG core usb: otg: hub: Notify OTG fsm when A device sets b_hnp_enable usb: hcd: adapt to OTG usb: gadget: udc: adapt to OTG usb: dwc3: adapt to OTG core usb: otg-fsm: Remove
Re: [RFC][PATCH 3/9] usb: otg: add OTG core
On 19/03/15 10:26, Li Jun wrote:
On Wed, Mar 18, 2015 at 03:55:57PM +0200, Roger Quadros wrote:
The OTG core instantiates the OTG Finite State Machine
per OTG controller and manages starting/stopping the
host and gadget controllers based on the bus state.
It provides APIs for the following tasks
- Registering an OTG capable controller
- Registering Host and Gadget controllers to OTG core
- Providing inputs to and kicking the OTG state machine
TODO:
- sysfs interface to allow application inputs to OTG state machine
- otg class?
Signed-off-by: Roger Quadros rog...@ti.com
---
+struct otg_data {
+struct device *dev; /* HCD GCD's parent device */
+
+struct otg_fsm fsm;
+/* HCD, GCD and usb_otg_state are present in otg_fsm-otg
+ * HCD is bus_to_hcd(fsm-otg-host)
+ * GCD is fsm-otg-gadget
+ */
+struct otg_fsm_ops fsm_ops; /* private copy for override */
+struct usb_otg otg;
+struct usb_hcd *shared_hcd; /* if shared HCD registered */
+
+/* saved hooks to OTG device */
+int (*start_host)(struct otg_fsm *fsm, int on);
+int (*start_gadget)(struct otg_fsm *fsm, int on);
+
+struct list_head list;
+
+struct work_struct work;/* OTG FSM work */
+struct workqueue_struct *wq;
+
+struct otg_timer timers[NUM_OTG_FSM_TIMERS];
+
+bool fsm_running;
+bool gadget_can_start; /* OTG FSM says gadget can start */
+bool host_can_start;/* OTG FSM says host can start */
Do not understand above 2 *_can_start flags from the patch, which are set
only when you really start host/gadget, to prevent host/gadget driver to
start it out of otg fsm control?
host_can_start is used only by this driver in the following _unlikely_ condition
and could probably be got rid of.
- Primary HCD and gadget registers
- OTG FSM signals host to start but it can't start as shared HCD isn't yet
registered.
so we set this flag.
- when shared HCD registers, we check the flag and explicitly start both the
host controllers.
gadget_can_start is used by the gadget driver through the
usb_otg_gadget_can_start() API.
This is needed because gadget might start at a later time depending on either
- gadget function driver loads
- userspace enables softconnect.
Li Jun
+
+/* use otg-fsm.lock for serializing access */
+};
+
+ * Can be called in IRQ context.
+ */
+void usb_otg_sync_inputs(struct otg_fsm *fsm)
+{
+struct otg_data *otgd = container_of(fsm, struct otg_data, fsm);
+
+/* Don't kick FSM till it has started */
+if (!otgd-fsm_running)
+return;
+
+/* Kick FSM */
+queue_work(otgd-wq, otgd-work);
+}
+EXPORT_SYMBOL_GPL(usb_otg_sync_inputs);
+
+/**
+ * usb_otg_kick_fsm - Kick the OTG state machine
+ * @hcd_gcd_device: Host/Gadget controller device
+ *
+ * Used by USB host/device stack to sync OTG related
+ * events to the OTG state machine.
+ * e.g. change in host_bus-b_hnp_enable, gadget-b_hnp_enable
+ *
There are quite a few otg fsm variables which should be updated when
events/interrupts(b_conn, a_srp_det, ...) occur, how is your plan to
update them? Still rely on specific controller driver irq handler to
capture all those events and update them?
Yes, my plan was that the OTG controller driver will handle those
interrupts, update otg_fsm members and call usb_otg_sync_inputs() to
notify the OTG FSM.
cheers,
-roger
Li Jun
+ * Returns: 0 on success, error value otherwise.
+ */
+int usb_otg_kick_fsm(struct device *hcd_gcd_device)
+{
+struct otg_data *otgd;
+
+mutex_lock(otg_list_mutex);
+otgd = usb_otg_device_get_otgd(hcd_gcd_device-parent);
+if (!otgd) {
+dev_err(hcd_gcd_device, %s: invalid host/gadget device\n,
+__func__);
+mutex_unlock(otg_list_mutex);
+return -ENODEV;
+}
+
+mutex_unlock(otg_list_mutex);
+usb_otg_sync_inputs(otgd-fsm);
+
+return 0;
+}
+EXPORT_SYMBOL_GPL(usb_otg_kick_fsm);
--
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: [RFC][PATCH 8/9] usb: otg-fsm: Remove unused members in struct otg_fsm
On 19/03/15 05:46, Peter Chen wrote:
On Wed, Mar 18, 2015 at 03:56:02PM +0200, Roger Quadros wrote:
These members are not used anywhere so remove them.
Signed-off-by: Roger Quadros rog...@ti.com
---
include/linux/usb/otg-fsm.h | 5 -
1 file changed, 5 deletions(-)
diff --git a/include/linux/usb/otg-fsm.h b/include/linux/usb/otg-fsm.h
index b6ba1bf..176c4fc 100644
--- a/include/linux/usb/otg-fsm.h
+++ b/include/linux/usb/otg-fsm.h
@@ -95,11 +95,6 @@ struct otg_fsm {
int b_hnp_enable;
int a_clr_err;
-/* Informative variables */
-int a_bus_drop_inf;
-int a_bus_req_inf;
-int a_clr_err_inf;
-int b_bus_req_inf;
/* Auxilary informative variables */
int a_suspend_req_inf;
But the above are defined at: ch 7.4.4, On-The-Go and Embedded Host
Supplement to the USB Revision 2.0 Specification
I can leave them there then but just add a note saying that they are
not yet used by the OTG FSM.
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: [PATCHv4 00/35] ARM: OMAP2+: PRCM / SCM cleanups against 4.0-rc1
On 03/19/2015 12:07 AM, Tony Lindgren wrote:
* Tero Kristo t-kri...@ti.com [150318 07:45]:
Hi,
Changes in this set compared to v3:
- Changed the SCM module DT node layout based on comments from Tony;
basically the wkup / core are split into their own nodes now. This
applies for omap3, omap4, omap5 and dra7, rest of the SoCs have their
control module integrated as one instance (Patch 26, 30, 33, 34)
- Changed the tisyscon node name to scm_conf. This name is more
descriptive for the purpose being used, scm_conf was already used
as an alias (Patch 24, 25, 27, 29)
- Rest of the patches have no changes compared to v3.
Testing done:
- am335x-evm : boot
- am335x-evmsk: boot
- am3517-evm : boot
- am43x-epos-evm : boot
- am437x-gp-evm : boot
- omap3-beagle-xm : boot
- omap3-beagle: boot, suspend-resume (ret/off), cpuidle (ret/off)
- am335x-boneblack: boot
- am335x-bone : boot
- dra7xx-evm : boot
- omap3-n900 : boot
- omap5-uevm : boot
- omap4-panda-es : boot, suspend-resume (ret), cpuidle (ret)
- omap4-panda : boot
- omap2430-sdp: boot
- omap3430-sdp: boot
- omap4-sdp-es23plus: boot
Test branch pushed at:
- tree: https://github.com/t-kristo/linux-pm.git
- branch: 4.0-rc1-prcm-cleanup-v4
Boots for me also for 2430-sdp.
But for dm8168-evm, it fails early on, see below.
Yea seems I forgot to add dm81x support properly. Try this diff:
diff --git a/arch/arm/mach-omap2/cm_common.c
b/arch/arm/mach-omap2/cm_common.c
index 2582651..23559aa 100644
--- a/arch/arm/mach-omap2/cm_common.c
+++ b/arch/arm/mach-omap2/cm_common.c
@@ -271,6 +271,8 @@ static const struct of_device_id
omap_cm_dt_match_table[] __initconst = {
{ .compatible = ti,dra7-cm-core, .data = cm2_data },
{ .compatible = ti,am3-prcm, .data = am3_prcm_data },
{ .compatible = ti,am4-prcm, .data = am4_prcm_data },
+ { .compatible = ti,dm814-prcm, .data = am3_prcm_data },
+ { .compatible = ti,dm816-prcm, .data = am3_prcm_data },
{ }
};
Regards,
Tony
[0.00] TI816X ES1.1 (neon )
[0.00] Unable to handle kernel NULL pointer dereference at virtual
address 0514
[0.00] pgd = c0004000
[0.00] [0514] *pgd=
[0.00] Internal error: Oops: 5 [#1] SMP ARM
[0.00] Modules linked in:
[0.00] CPU: 0 PID: 0 Comm: swapper Not tainted
4.0.0-rc4-next-20150318-00040-gc5b9bf4 #291
[0.00] Hardware name: Generic ti816x (Flattened Device Tree)
[0.00] task: c08c2048 ti: c08bc000 task.ti: c08bc000
[0.00] PC is at am33xx_clkdm_wakeup+0x18/0x3c
[0.00] LR is at clkdm_wakeup_nolock+0x48/0x68
[0.00] pc : [c0030f4c]lr : [c0033918]psr: a193
[0.00] sp : c08bdf30 ip : c094f528 fp : c076d94c
[0.00] r10: 8200 r9 : c08c38dc r8 : c08c38dc
[0.00] r7 : c112d444 r6 : c094f69c r5 : c08cdba8 r4 : c08cf1c8
[0.00] r3 : 0014 r2 : 0514 r1 : 0514 r0 : c08cf1c8
[0.00] Flags: NzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment
kernel
[0.00] Control: 10c5387d Table: 80004019 DAC: 0015
[0.00] Process swapper (pid: 0, stack limit = 0xc08bc218)
[0.00] Stack: (0xc08bdf30 to 0xc08be000)
[0.00] df20: c08c2048 c08cf1c8
c08cdba8 c0033950
[0.00] df40: 0003 c08cf1c8 c08cdba8 c0033b18 c089df40 2f80
c08c1d0c c0859fb8
[0.00] df60: c0859f8c c08544a8 c08bdf78 c08bdf88 c094e8c0 ef7fce80
[0.00] df80: c094e780 c076bdb0 c08bdfb4
[0.00] dfa0: c094e780 c08be8c0 0001 c094e780
c085094c
[0.00] dfc0: c089f778
c094e994 c08be96c
[0.00] dfe0: c089f774 c08c3a04 80004059 413fc082 80008074
[0.00] [c0030f4c] (am33xx_clkdm_wakeup) from [c0033918]
(clkdm_wakeup_nolock+0x48/0x68)
[0.00] [c0033918] (clkdm_wakeup_nolock) from [c0033950]
(clkdm_wakeup+0x18/0x2c)
[0.00] [c0033950] (clkdm_wakeup) from [c0033b18]
(clkdm_complete_init+0xb4/0xf8)
[0.00] [c0033b18] (clkdm_complete_init) from [c0859fb8]
(ti816x_init_early+0x2c/0x64)
[0.00] [c0859fb8] (ti816x_init_early) from [c08544a8]
(setup_arch+0x8d4/0x9b8)
[0.00] [c08544a8] (setup_arch) from [c085094c]
(start_kernel+0x98/0x3e8)
[0.00] [c085094c] (start_kernel) from [80008074] (0x80008074)
[0.00] Code: e1d010be e59c2000 e0831001 e0822001 (e5923000)
[0.00] ---[ end trace cb88537fdc8fa200 ]---
[0.00] Kernel panic - not syncing: Attempted to kill the idle task!
[0.00] ---[ end Kernel panic - not syncing: Attempted to kill the idle
task!
--
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
Re: [PATCHv4 00/35] ARM: OMAP2+: PRCM / SCM cleanups against 4.0-rc1
On 03/19/2015 02:00 AM, Sakari Ailus wrote: Hi Tero, On Wed, Mar 18, 2015 at 04:43:45PM +0200, Tero Kristo wrote: Hi, Changes in this set compared to v3: - Changed the SCM module DT node layout based on comments from Tony; basically the wkup / core are split into their own nodes now. This applies for omap3, omap4, omap5 and dra7, rest of the SoCs have their control module integrated as one instance (Patch 26, 30, 33, 34) - Changed the tisyscon node name to scm_conf. This name is more descriptive for the purpose being used, scm_conf was already used as an alias (Patch 24, 25, 27, 29) - Rest of the patches have no changes compared to v3. Testing done: - am335x-evm : boot - am335x-evmsk: boot - am3517-evm : boot - am43x-epos-evm : boot - am437x-gp-evm : boot - omap3-beagle-xm : boot - omap3-beagle: boot, suspend-resume (ret/off), cpuidle (ret/off) - am335x-boneblack: boot - am335x-bone : boot - dra7xx-evm : boot - omap3-n900 : boot - omap5-uevm : boot - omap4-panda-es : boot, suspend-resume (ret), cpuidle (ret) - omap4-panda : boot - omap2430-sdp: boot - omap3430-sdp: boot - omap4-sdp-es23plus: boot Test branch pushed at: - tree: https://github.com/t-kristo/linux-pm.git - branch: 4.0-rc1-prcm-cleanup-v4 I tried compiling this, but I get a few linker errors: Right, I always forget about silly people who do things like OMAP3 only builds or something Shall be fixed. -Tero arch/arm/mach-omap2/built-in.o:(.init.data+0x47d8): undefined reference to `am33xx_prm_init' arch/arm/mach-omap2/built-in.o:(.init.data+0x47f0): undefined reference to `omap44xx_prm_init' arch/arm/mach-omap2/built-in.o:(.init.data+0x4808): undefined reference to `omap2xxx_prm_init' arch/arm/mach-omap2/built-in.o:(.init.data+0x4838): undefined reference to `omap44xx_prm_init' arch/arm/mach-omap2/built-in.o:(.init.data+0x4868): undefined reference to `omap44xx_prm_init' arch/arm/mach-omap2/built-in.o:(.init.data+0x4880): undefined reference to `omap44xx_prm_init' arch/arm/mach-omap2/built-in.o:(.init.data+0x4898): undefined reference to `omap2xxx_cm_init' arch/arm/mach-omap2/built-in.o:(.init.data+0x48c8): undefined reference to `omap4_cm_init' arch/arm/mach-omap2/built-in.o:(.init.data+0x48e0): undefined reference to `omap4_cm_init' arch/arm/mach-omap2/built-in.o:(.init.data+0x48f8): undefined reference to `am33xx_cm_init' arch/arm/mach-omap2/built-in.o:(.init.data+0x4910): undefined reference to `omap4_cm_init' .config attached. -- 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: [RFC][PATCH 3/9] usb: otg: add OTG core
On Wed, Mar 18, 2015 at 03:55:57PM +0200, Roger Quadros wrote:
The OTG core instantiates the OTG Finite State Machine
per OTG controller and manages starting/stopping the
host and gadget controllers based on the bus state.
It provides APIs for the following tasks
- Registering an OTG capable controller
- Registering Host and Gadget controllers to OTG core
- Providing inputs to and kicking the OTG state machine
TODO:
- sysfs interface to allow application inputs to OTG state machine
- otg class?
Signed-off-by: Roger Quadros rog...@ti.com
---
+struct otg_data {
+ struct device *dev; /* HCD GCD's parent device */
+
+ struct otg_fsm fsm;
+ /* HCD, GCD and usb_otg_state are present in otg_fsm-otg
+ * HCD is bus_to_hcd(fsm-otg-host)
+ * GCD is fsm-otg-gadget
+ */
+ struct otg_fsm_ops fsm_ops; /* private copy for override */
+ struct usb_otg otg;
+ struct usb_hcd *shared_hcd; /* if shared HCD registered */
+
+ /* saved hooks to OTG device */
+ int (*start_host)(struct otg_fsm *fsm, int on);
+ int (*start_gadget)(struct otg_fsm *fsm, int on);
+
+ struct list_head list;
+
+ struct work_struct work;/* OTG FSM work */
+ struct workqueue_struct *wq;
+
+ struct otg_timer timers[NUM_OTG_FSM_TIMERS];
+
+ bool fsm_running;
+ bool gadget_can_start; /* OTG FSM says gadget can start */
+ bool host_can_start;/* OTG FSM says host can start */
Do not understand above 2 *_can_start flags from the patch, which are set
only when you really start host/gadget, to prevent host/gadget driver to
start it out of otg fsm control?
Li Jun
+
+ /* use otg-fsm.lock for serializing access */
+};
+
+ * Can be called in IRQ context.
+ */
+void usb_otg_sync_inputs(struct otg_fsm *fsm)
+{
+ struct otg_data *otgd = container_of(fsm, struct otg_data, fsm);
+
+ /* Don't kick FSM till it has started */
+ if (!otgd-fsm_running)
+ return;
+
+ /* Kick FSM */
+ queue_work(otgd-wq, otgd-work);
+}
+EXPORT_SYMBOL_GPL(usb_otg_sync_inputs);
+
+/**
+ * usb_otg_kick_fsm - Kick the OTG state machine
+ * @hcd_gcd_device: Host/Gadget controller device
+ *
+ * Used by USB host/device stack to sync OTG related
+ * events to the OTG state machine.
+ * e.g. change in host_bus-b_hnp_enable, gadget-b_hnp_enable
+ *
There are quite a few otg fsm variables which should be updated when
events/interrupts(b_conn, a_srp_det, ...) occur, how is your plan to
update them? Still rely on specific controller driver irq handler to
capture all those events and update them?
Li Jun
+ * Returns: 0 on success, error value otherwise.
+ */
+int usb_otg_kick_fsm(struct device *hcd_gcd_device)
+{
+ struct otg_data *otgd;
+
+ mutex_lock(otg_list_mutex);
+ otgd = usb_otg_device_get_otgd(hcd_gcd_device-parent);
+ if (!otgd) {
+ dev_err(hcd_gcd_device, %s: invalid host/gadget device\n,
+ __func__);
+ mutex_unlock(otg_list_mutex);
+ return -ENODEV;
+ }
+
+ mutex_unlock(otg_list_mutex);
+ usb_otg_sync_inputs(otgd-fsm);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(usb_otg_kick_fsm);
--
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: [RFC][PATCH 2/9] usb: gadget: add usb_gadget_start/stop()
On 19/03/15 05:30, Peter Chen wrote:
On Wed, Mar 18, 2015 at 03:55:56PM +0200, Roger Quadros wrote:
The OTG state machine needs a mechanism to start and
stop the gadget controller. Add usb_gadget_start()
and usb_gadget_stop().
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/usb/gadget/udc/udc-core.c | 166
+++---
include/linux/usb/gadget.h| 3 +
2 files changed, 158 insertions(+), 11 deletions(-)
diff --git a/drivers/usb/gadget/udc/udc-core.c
b/drivers/usb/gadget/udc/udc-core.c
index 5a81cb0..69b4123 100644
--- a/drivers/usb/gadget/udc/udc-core.c
+++ b/drivers/usb/gadget/udc/udc-core.c
@@ -35,6 +35,8 @@
* @dev - the child device to the actual controller
* @gadget - the gadget. For use by the class code
* @list - for use by the udc class driver
+ * @running - udc is running
Doesn't OTG FSM should know it?
Not really, as the gadget driver might not have been loaded yet or userspace
might
have disabled softconnect when the OTG FSM wants UDC to start.
So only UDC knows if it has really started or not based on this flag.
cheers,
-roger
Peter
+ * @softconnect - sysfs softconnect says OK to connect
*
* This represents the internal data structure which is used by the
UDC-class
* to hold information about udc driver and gadget together.
@@ -44,6 +46,8 @@ struct usb_udc {
struct usb_gadget *gadget;
struct device dev;
struct list_headlist;
+boolrunning;
+boolsoftconnect;
};
static struct class *udc_class;
@@ -187,7 +191,14 @@ EXPORT_SYMBOL_GPL(usb_gadget_udc_reset);
*/
static inline int usb_gadget_udc_start(struct usb_udc *udc)
{
-return udc-gadget-ops-udc_start(udc-gadget, udc-driver);
+int ret;
+
+dev_dbg(udc-dev, %s\n, __func__);
+ret = udc-gadget-ops-udc_start(udc-gadget, udc-driver);
+if (!ret)
+udc-running = 1;
+
+return ret;
}
/**
@@ -204,10 +215,140 @@ static inline int usb_gadget_udc_start(struct usb_udc
*udc)
*/
static inline void usb_gadget_udc_stop(struct usb_udc *udc)
{
+dev_dbg(udc-dev, %s\n, __func__);
udc-gadget-ops-udc_stop(udc-gadget);
+udc-running = 0;
}
/**
+ * usb_udc_start - Start the usb device controller only if conditions met
+ * @udc: The UDC to be started
+ *
+ * Start the UDC and connect to bus (enable pull) only if the
+ * following conditions are met
+ * - UDC is not already running
+ * - gadget function driver is loaded
+ * - userspace softconnect says OK to connect
+ *
+ * NOTE: udc_lock must be held by caller.
+ *
+ * Returs 0 on success or not ready to start, else negative errno.
+ */
+static int usb_udc_start(struct usb_udc *udc)
+{
+int ret;
+
+if (udc-running) {
+dev_err(udc-dev, %s: not starting as already running\n,
+__func__);
+return -EBUSY;
+}
+
+if (udc-driver udc-softconnect) {
+ret = usb_gadget_udc_start(udc);
+if (ret)
+return ret;
+
+usb_gadget_connect(udc-gadget);
+}
+
+return 0;
+}
+
+/**
+ * usb_udc_stop - Stop the usb device controller
+ * @udc: The UDC to be stopped
+ *
+ * Disconnect from bus (disable pull) and stop the UDC.
+ *
+ * NOTE: udc_lock must be held by caller.
+ *
+ * Returs 0 on success, else negative errno.
+ */
+static int usb_udc_stop(struct usb_udc *udc)
+{
+if (!udc-running) {
+dev_err(udc-dev, %s: not stopping as already halted\n,
+__func__);
+return -EBUSY;
+}
+
+usb_gadget_disconnect(udc-gadget);
+udc-driver-disconnect(udc-gadget);
+usb_gadget_udc_stop(udc);
+
+return 0;
+}
+
+/**
+ * usb_gadget_start - start the usb gadget controller
+ * @gadget: the gadget device to start
+ *
+ * This is external API for use by OTG core.
+ *
+ * Start the usb device controller and connect to bus (enable pull).
+ * There is no guarantee that the controller is started
+ * as we might be missing some dependencies
+ * i.e. gadget function driver not loaded or softconnect disabled.
+ */
+int usb_gadget_start(struct usb_gadget *gadget)
+{
+int ret;
+struct usb_udc *udc = NULL;
+
+dev_dbg(gadget-dev, %s\n, __func__);
+mutex_lock(udc_lock);
+list_for_each_entry(udc, udc_list, list)
+if (udc-gadget == gadget)
+goto found;
+
+dev_err(gadget-dev.parent, %s: gadget not registered.\n,
+__func__);
+mutex_unlock(udc_lock);
+return -EINVAL;
+
+found:
+ret = usb_udc_start(udc);
+mutex_unlock(udc_lock);
+
+return ret;
+}
+EXPORT_SYMBOL_GPL(usb_gadget_start);
+
+/**
+ * usb_gadget_stop - stop the usb gadget
+ * @gadget: The gadget device we want to stop
+ *
+ * This is
Re: Patches to bind the SGTL5000 chip to AM33XX McASP
On Thu, Mar 19, 2015 at 01:07:39AM -0400, Greg Knight wrote: These patches are based off of 3.14.31-ti-r49. What is the process for getting these merged? Please submit patches using the process in SubmittingPatches, you need to work against current development versions of the kernel rather than an old vendor kernel. signature.asc Description: Digital signature
Re: [RFC][PATCH 1/9] usb: hcd: Introduce usb_start/stop_hcd()
On 18/03/15 21:49, Alan Stern wrote:
On Wed, 18 Mar 2015, Roger Quadros wrote:
To support OTG we want a mechanism to start and stop
the HCD from the OTG state machine. Add usb_start_hcd()
and usb_stop_hcd().
Signed-off-by: Roger Quadros rog...@ti.com
There are a few problems in this proposed patch.
+int usb_start_hcd(struct usb_hcd *hcd)
+{
+int retval;
+struct usb_device *rhdev = hcd-self.root_hub;
+
+if (hcd-state != HC_STATE_HALT) {
+dev_err(hcd-self.controller, not starting a running HCD\n);
+return -EINVAL;
+}
+
+hcd-state = HC_STATE_RUNNING;
+retval = hcd-driver-start(hcd);
+if (retval 0) {
+dev_err(hcd-self.controller, startup error %d\n, retval);
+hcd-state = HC_STATE_HALT;
+return retval;
+}
+
+/* starting here, usbcore will pay attention to this root hub */
+if ((retval = register_root_hub(hcd)) != 0)
+goto err_register_root_hub;
If the host controller is started more than once, you will end up
unregistering and re-registering the root hub. The device core does
not allow this. Once a device has been unregistered, you must not try
to register it again -- you have to allocate a new device and register
it instead.
Understood.
Also, although you call the driver's -start method multiple times, the
-reset method is called only once, when the controller is first
probed. It's not clear that this will work in a situation where the HC
and the UDC share hardware state; after the UDC is stopped it may be
necessary to reset the HC before it can run again.
Yes, good point.
It might be possible to make this work, but I suspect quite a few
drivers would need rewriting first. As another example of the problems
you face, consider how stopping a host controller will interact with
the driver's PM support (both system suspend and runtime suspend).
Right. This needs more work than I thought.
It would be a lot simpler to unbind the host controller driver
completely when switching to device mode and rebind it when switching
back. I guess that is the sort of heavy-duty approach you want to
avoid, but it may be the only practical way forward.
So you mean directly calling usb_add/remove_hcd() from the OTG core?
I don't see any issues with that other than it being a heavy-duty operation
like you said and hope that it doesn't violate the OTG spec timing.
Looking at Figure 5-3: HNP Sequence of Events (FS) of the OTG 2.0 spec
we have about 150ms (X10) to switch from B-Device detected A connect
(b_wait_acon state)
to driving bus reset (b_host state). I don't think this should be an issue in
modern SoCs
but I'm not very sure.
In any case I can migrate to the add/remove hcd approach to simplify things.
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] phy: Add a driver for dm816x USB PHY
On 17 March 2015 at 03:19, Tony Lindgren t...@atomide.com wrote: Yes so it seem here too, this is dm816x rev c, what do you have? jtag ID reads 0x1b81e02f, so that would be rev 1.1 / rev A. Anyways, I'll add a note that at least rev c does not seems to do anything with USB_CTRL but that we follow what the TI tree is doing in case some other revisions of the hardware use it. Another idea would be to check if it's nonzero and if so, yell loudly in the kernel log that they should mail the linux-omap list ;-) Matthijs -- 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 to parameterize DMA_MIN_BYTES for omap2-mcspi
On 03/19/2015 07:05 AM, Greg Knight wrote: Hi, Mark, I've attached a patch which adds a device-tree field ti,dma-min-bytes which replaces the macro DMA_MIN_BYTES. Adjusting this field addresses issues we've had where, in our particular use case, the usleep() in the SPI worker thread eats a full 20% of our CPU (AM3359). I opted to implement it as a device-tree parameter and keep the original value (160) as the default, in order to avoid impacting anyone else. The patch is attached. Patches 1-2 are an unrelated McASP change (see my other message). What is the process for getting this upstreamed? Please follow the guidelines in Documentation/SubmittingPatches. Patches as attachments are not preferred since it makes replying/commenting on the patches hard. Strictly speaking the dma-min-bytes should not be in DT, it is a software parameter for the Linux SPI driver implementation. Also, when changing DT bindings, please update the documentation as well (and CC the relevant lists with that). This threshold of 160 bytes in the omap2-mcspi driver is artificial anyways it is changed from 8 to 160 by this commit: 8b66c13474e16 spi/omap2_mcspi: change default DMA_MIN_BYTES value to 160 It has been changed because of wl1271, but I'm not sure if banging bytes over the bus when the transfer is less then 160bytes is that great thing. I would guess that the sweet spot is at around the low tens. But if it is really like this that different devices perform better with different threshold for choosing between PIO or DMA transfer then this setting should come from the slave device and should only affect the transfer setup when communicating with that device. Probably adding a parameter (optional) to spi_device struct, so drivers can pass dma_over_poi_threshold? If it is not set, than just use whatever is the default. But I don't think this setting should be in the DT. -- Péter -- 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: Patches to bind the SGTL5000 chip to AM33XX McASP
On 03/19/2015 07:07 AM, Greg Knight wrote: Hi, Mark, Jaroslav, I've attached a couple patches to provide support for the Freescale SGTL5000 chip when using the McASP on the AM3359. It is more correct to say that this is needed in a custom hardware which uses McASP and SGTL5000 codec. This adds an optional hack, clock-to-talk to the McASP subsystem which can start AHCLKX/AHCLKR prior to initializing the codec. This is needed on the SGTL5000, which depends on AHCLKX for its master clock. SO is it so that the codec's MCLK is coming from McASP AHCLKX (or R) and this clock need to be present all the time? W/o the MCLK the registers are not accessible? These patches are based off of 3.14.31-ti-r49. What is the process for getting these merged? First off, please send the patches with git send-email so people can comment on them. This will not work in mainline kernel. The McASP is turned off when it is not in use (no audio activity) so the AHCLKX/R is not going to be there on the ball output. How do you configure the frequency of the AHCLKX/R, this hack only enables it, so you are going to have _some_ clock going out. You should be using set_clkdiv and set_sysclk calls from the machine driver to configure the AHCLKX (we do not have AHCLKR supported in the driver ATM). -- Péter -- 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] Update Nanobone dts file
Update dts file to reflect:-
(1) new flash memory layout
(2) add missing phy-mode property
Signed-off-by: Mark Jackson m...@newflow.co.uk
---
arch/arm/boot/dts/am335x-nano.dts | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-nano.dts
b/arch/arm/boot/dts/am335x-nano.dts
index a346645..dfa610f 100644
--- a/arch/arm/boot/dts/am335x-nano.dts
+++ b/arch/arm/boot/dts/am335x-nano.dts
@@ -297,8 +297,8 @@
||--0x004F- Kernel end
||--0x0050- File system start
||
- ||--0x014F- File system end
- ||--0x0150- User data start
+ ||--0x01FF- File system end
+ ||--0x0200- User data start
||
||--0x03FF- User data end
||--0x0400- Data storage start
@@ -327,12 +327,12 @@
partition@4 {
label = rootfs;
- reg = 0x0050 0x0100; /* 16MB */
+ reg = 0x0050 0x01b0; /* 27MB */
};
partition@5 {
label = user;
- reg = 0x0150 0x02b0; /* 43MB */
+ reg = 0x0200 0x0200; /* 32MB */
};
partition@6 {
@@ -353,11 +353,13 @@
cpsw_emac0 {
phy_id = davinci_mdio, 0;
+ phy-mode = mii;
dual_emac_res_vlan = 1;
};
cpsw_emac1 {
phy_id = davinci_mdio, 1;
+ phy-mode = mii;
dual_emac_res_vlan = 2;
};
--
1.9.1
--
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: omap voltage management
We currently are missing dm8148 support from mainline, dm8168 does have basic support now. Adding dm8148 will hopefully happen too with time permitting :) Hi Tony, What is exactly the voltage driver capability ? Does it mean that it does not support AVS (feature for power saving) ? Regards, Ran -- 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/3] w1: masters: omap_hdq: Add support for 1-wire mode
Gentle Ping
On Monday 02 March 2015 04:19 PM, Vignesh R wrote:
This patches makes following changes to omap_hdq driver
- Enable 1-wire mode.
- Implement w1_triplet callback to facilitate search rom
procedure and auto detection of 1-wire slaves.
- Proper enabling and disabling of interrupt.
- Cleanups (formatting and return value checks).
HDQ mode remains unchanged.
Signed-off-by: Vignesh R vigne...@ti.com
---
Change log:
v2:
* Change compatible to ti,am4372-hdq as Arnd suggested.
Documentation/devicetree/bindings/w1/omap-hdq.txt | 7 +-
Documentation/w1/masters/omap-hdq | 6 +
drivers/w1/masters/omap_hdq.c | 209
++
3 files changed, 188 insertions(+), 34 deletions(-)
diff --git a/Documentation/devicetree/bindings/w1/omap-hdq.txt
b/Documentation/devicetree/bindings/w1/omap-hdq.txt
index fef794741bd1..913c5f91a0f9 100644
--- a/Documentation/devicetree/bindings/w1/omap-hdq.txt
+++ b/Documentation/devicetree/bindings/w1/omap-hdq.txt
@@ -1,11 +1,15 @@
* OMAP HDQ One wire bus master controller
Required properties:
-- compatible : should be ti,omap3-1w
+- compatible : should be ti,omap3-1w or ti,am4372-hdq
- reg : Address and length of the register set for the device
- interrupts : interrupt line.
- ti,hwmods : hdq1w
+Optional properties:
+- ti,mode: should be hdq: HDQ mode 1w: one-wire mode.
+If not specified HDQ mode is implied.
+
Example:
- From omap3.dtsi
@@ -14,4 +18,5 @@ Example:
reg = 0x480b2000 0x1000;
interrupts = 58;
ti,hwmods = hdq1w;
+ ti,mode = hdq;
};
diff --git a/Documentation/w1/masters/omap-hdq
b/Documentation/w1/masters/omap-hdq
index 884dc284b215..234522709a5f 100644
--- a/Documentation/w1/masters/omap-hdq
+++ b/Documentation/w1/masters/omap-hdq
@@ -44,3 +44,9 @@ e.g:
insmod omap_hdq.ko W1_ID=2
inamod w1_bq27000.ko F_ID=2
+The driver also supports 1-wire mode. In this mode, there is no need to
+pass slave ID as parameter. The driver will auto-detect slaves connected
+to the bus using SEARCH_ROM procedure. 1-wire mode can be selected by
+setting ti,mode property to 1w in DT (see
+Documentation/devicetree/bindings/w1/omap-hdq.txt for more details).
+By default driver is in HDQ mode.
diff --git a/drivers/w1/masters/omap_hdq.c b/drivers/w1/masters/omap_hdq.c
index 03321d6a2684..325b46905657 100644
--- a/drivers/w1/masters/omap_hdq.c
+++ b/drivers/w1/masters/omap_hdq.c
@@ -17,6 +17,7 @@
#include linux/io.h
#include linux/sched.h
#include linux/pm_runtime.h
+#include linux/of.h
#include ../w1.h
#include ../w1_int.h
@@ -27,21 +28,23 @@
#define OMAP_HDQ_TX_DATA 0x04
#define OMAP_HDQ_RX_DATA 0x08
#define OMAP_HDQ_CTRL_STATUS 0x0c
-#define OMAP_HDQ_CTRL_STATUS_INTERRUPTMASK (16)
-#define OMAP_HDQ_CTRL_STATUS_CLOCKENABLE (15)
-#define OMAP_HDQ_CTRL_STATUS_GO (14)
-#define OMAP_HDQ_CTRL_STATUS_INITIALIZATION (12)
-#define OMAP_HDQ_CTRL_STATUS_DIR (11)
-#define OMAP_HDQ_CTRL_STATUS_MODE(10)
+#define OMAP_HDQ_CTRL_STATUS_SINGLE BIT(7)
+#define OMAP_HDQ_CTRL_STATUS_INTERRUPTMASK BIT(6)
+#define OMAP_HDQ_CTRL_STATUS_CLOCKENABLE BIT(5)
+#define OMAP_HDQ_CTRL_STATUS_GO BIT(4)
+#define OMAP_HDQ_CTRL_STATUS_PRESENCEBIT(3)
+#define OMAP_HDQ_CTRL_STATUS_INITIALIZATION BIT(2)
+#define OMAP_HDQ_CTRL_STATUS_DIR BIT(1)
#define OMAP_HDQ_INT_STATUS 0x10
-#define OMAP_HDQ_INT_STATUS_TXCOMPLETE (12)
-#define OMAP_HDQ_INT_STATUS_RXCOMPLETE (11)
-#define OMAP_HDQ_INT_STATUS_TIMEOUT (10)
+#define OMAP_HDQ_INT_STATUS_TXCOMPLETE BIT(2)
+#define OMAP_HDQ_INT_STATUS_RXCOMPLETE BIT(1)
+#define OMAP_HDQ_INT_STATUS_TIMEOUT BIT(0)
#define OMAP_HDQ_SYSCONFIG 0x14
-#define OMAP_HDQ_SYSCONFIG_SOFTRESET (11)
-#define OMAP_HDQ_SYSCONFIG_AUTOIDLE (10)
+#define OMAP_HDQ_SYSCONFIG_SOFTRESET BIT(1)
+#define OMAP_HDQ_SYSCONFIG_AUTOIDLE BIT(0)
+#define OMAP_HDQ_SYSCONFIG_NOIDLEBIT(0)
#define OMAP_HDQ_SYSSTATUS 0x18
-#define OMAP_HDQ_SYSSTATUS_RESETDONE (10)
+#define OMAP_HDQ_SYSSTATUS_RESETDONE BIT(0)
#define OMAP_HDQ_FLAG_CLEAR 0
#define OMAP_HDQ_FLAG_SET1
@@ -67,6 +70,10 @@ struct hdq_data {
* the data wrire or read.
*/
int init_trans;
+ int rrw;
+ /* mode: 0-HDQ 1-W1 */
+ int mode;
+
};
static int omap_hdq_probe(struct platform_device *pdev);
@@ -74,6 +81,7 @@ static int omap_hdq_remove(struct platform_device *pdev);
static struct of_device_id omap_hdq_dt_ids[] = {
{ .compatible
[PATCH 6/8] gpio: omap: get rid of GPIO_BIT() macro
From: Grygorii Strashko grygorii.stras...@linaro.org
Now OMAP GPIO driver prepared for GPIO_BIT() macro removing.
Do it ;)
Signed-off-by: Grygorii Strashko grygorii.stras...@linaro.org
---
drivers/gpio/gpio-omap.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index b39faa8..dd7934a 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -82,7 +82,6 @@ struct gpio_bank {
};
#define GPIO_INDEX(bank, gpio) (gpio % bank-width)
-#define GPIO_BIT(bank, gpio) (BIT(GPIO_INDEX(bank, gpio)))
#define GPIO_MOD_CTRL_BIT BIT(0)
#define BANK_USED(bank) (bank-mod_usage || bank-irq_usage)
@@ -863,7 +862,6 @@ static void omap_gpio_unmask_irq(struct irq_data *d)
{
struct gpio_bank *bank = omap_irq_data_get_bank(d);
unsigned offset = d-hwirq;
- unsigned int irq_mask = GPIO_BIT(bank, gpio);
u32 trigger = irqd_get_trigger_type(d);
unsigned long flags;
@@ -873,7 +871,7 @@ static void omap_gpio_unmask_irq(struct irq_data *d)
/* For level-triggered GPIOs, the clearing must be done after
* the HW source is cleared, thus after the handler has run */
- if (bank-level_mask irq_mask) {
+ if (bank-level_mask BIT(offset)) {
omap_set_gpio_irqenable(bank, offset, 0);
omap_clear_gpio_irqstatus(bank, offset);
}
--
1.9.1
--
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 0/3] OMAP 3 ISP (and N9/N950 primary camera support) dts changes
* Sakari Ailus sakari.ai...@iki.fi [150318 16:51]: Hi folks, Since v1, I've rebased the set on Tero Kristo's PRCM / SCM cleanup patchset here: URL:http://www.spinics.net/lists/linux-omap/msg116949.html v1 can be found here: URL:http://www.spinics.net/lists/linux-omap/msg116753.html Changes since v1: - Fixed phy reference (number to name) in the example, - Dropped the first patch. This is already done by Tero's patch ARM: dts: omap3: merge control module features under scrm node. Applying these into omap-for-v4.1/dt thanks. 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: Patches to bind the SGTL5000 chip to AM33XX McASP
For a codec such as the SGTL5000 I would connect a clock, which is running all the time. If you take a look at the driver, it enables the clock at probe and leaves it running as long as the driver is loaded. Speaking briefly to my electrical colleague, he's a bit concerned about the extra power load that a crystal oscillator might incur, while I'm concerned about audio quality from a source like CLKOUT2. Is there a straightforward way we could enable the clock on-demand - when we're communicating with the codec/mixer or actually using the audio subsystem - while keeping it disabled when not in use? We don't expect to be using the audio subsystem frequently. Worst-case we can set up a GPIO and enable/disable it as needed in user-space - acceptable, if annoying, for our application. Thanks, Greg -- 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: [alsa-devel] Patches to bind the SGTL5000 chip to AM33XX McASP
Hi Peter, On 03/19/2015 06:07 PM, Peter Ujfalusi wrote: On 03/19/2015 04:34 PM, Greg Knight wrote: SO is it so that the codec's MCLK is coming from McASP AHCLKX (or R) and this clock need to be present all the time? W/o the MCLK the registers are not accessible? Correct, the SGTL5000's I2C registers are not accessible without MCLK. Yeah, according to the datasheet, it needs MCLK in order to communicate with it. Slight clarification here - I can't find any such reference in the SGTL5000 datasheet where it's explicitly written that the I2C bus *requires* the MCLK running. Unfortunately, all of us found this obscure dependency empirically. One more thing - the codec's I2C works with any supported MCLK (8-27 MHz), you can even change the clock on the fly (not highly recommended, but it works). From my testing, the clock need only be present when the audio chip is in use. When not in use, the chip appears perfectly happy to not be clocked. If you change audio controls while you don't have audio activity, you will still need to have the MCLK running. Correct. And this is a big issue. As far as I know, the kernel drivers control separately the clock domains, and separately i2c devices, so the basic expectation on the kernel side is that there's no connection between these 2. In this specific case, because of the SGTL5000's implementation, there's a dependency. Right now as I see it, there are several ways to resolve it: 1. Run the reference clock all the time, so the SGTL5000 codec is happy, and DAPM widgets can work as-is. We've been doing this all the time - the reference clocks are routinely configured either in the bootloader, or in the DTS iomuxc node. While this can work in some cases (or until someone touches the same clock or one of its parents :D), there are other cases (like battery-powered devices) where people would want more aggressive power management, which means controlling the reference clock at runtime (see #2). 2. Add hacks in the DAPM widgets that add control to the codec's reference clocks. While this seems the preferred route to many, the general feeling is that such approach is not very welcome in upstream. 3. Add explicit support in the kernel's audio subsystem for dependencies between i2c devices and clocks, maybe via DAPM clock widget or something like this. Provided that the DAPM graphs are defined properly, this will work out-of-the-box for all use cases, without the hacks (until we see even more twisted cases). Kind regards, Nikolay -- 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 voltage management
Hello, I am using DM8148 and I get error message in boot that voltage management driver is not added. Is it supported in DM8148. If not - why ? Thank you, Ran -- 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 to parameterize DMA_MIN_BYTES for omap2-mcspi
Will refer to that documentation and update the SPI docs before resubmitting. Re; Threshold of 160 is artificial: Believe me, I am more than aware of this. SPI runs in any speed from low kHz to multi MHz. The only reason I can fathom for having such a high DMA_MIN_BYTES is to facilitate high-speed low-volume communication (eg read one byte at a time from userspace without buffering.) The reason I'm looking at this at all is because we're doing low-speed low-volume communication, for which the burn in PIO mode causes severe performance degradation. Internally we'd changed it to 20, but I might try 8. I originally tried 0, but observed poor behavior for our use cases. DMA_MIN_BYTES at 8 would be sensible for our application, but at 160 it is not. The current solution is for everybody who needs to change their device settings to churn that macro, just as 8b66c1474e16 did. Changing that values incurs significant risk of excess CPU load (if increased) or timing slop (if decreased) to all hardware using the McSPI. Moving the param to DT allows those of us working on custom boards to modify the value for some hardware without risking the entire ecosystem. Let's please not keep a bad solution just because no perfect solution exists... I think the proper location for this patch might actually be in the spidev nodes in DT, rather than at the mcspi level - but I don't understand why this does not belong in DT. DT is, after all, where one would normally describe the rest of the slave device bindings. A sensible value for DMA_MIN_BYTES requires the user to know the CPU clock speed alongside the SPI bus speed, and estimate acceptable levels of slop in timing. I don't think userspace should need to do these computations to avoid excess CPU load; could do it in kernel space, or leave it up to DT or kernel parameters. How about moving the speed to the spidev DT nodes? Regards, Greg On Thu, Mar 19, 2015 at 8:34 AM, Peter Ujfalusi peter.ujfal...@ti.com wrote: On 03/19/2015 07:05 AM, Greg Knight wrote: Hi, Mark, I've attached a patch which adds a device-tree field ti,dma-min-bytes which replaces the macro DMA_MIN_BYTES. Adjusting this field addresses issues we've had where, in our particular use case, the usleep() in the SPI worker thread eats a full 20% of our CPU (AM3359). I opted to implement it as a device-tree parameter and keep the original value (160) as the default, in order to avoid impacting anyone else. The patch is attached. Patches 1-2 are an unrelated McASP change (see my other message). What is the process for getting this upstreamed? Please follow the guidelines in Documentation/SubmittingPatches. Patches as attachments are not preferred since it makes replying/commenting on the patches hard. Strictly speaking the dma-min-bytes should not be in DT, it is a software parameter for the Linux SPI driver implementation. Also, when changing DT bindings, please update the documentation as well (and CC the relevant lists with that). This threshold of 160 bytes in the omap2-mcspi driver is artificial anyways it is changed from 8 to 160 by this commit: 8b66c13474e16 spi/omap2_mcspi: change default DMA_MIN_BYTES value to 160 It has been changed because of wl1271, but I'm not sure if banging bytes over the bus when the transfer is less then 160bytes is that great thing. I would guess that the sweet spot is at around the low tens. But if it is really like this that different devices perform better with different threshold for choosing between PIO or DMA transfer then this setting should come from the slave device and should only affect the transfer setup when communicating with that device. Probably adding a parameter (optional) to spi_device struct, so drivers can pass dma_over_poi_threshold? If it is not set, than just use whatever is the default. But I don't think this setting should be in the DT. -- Péter -- 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] usb: musb: Fix fifo reads for dm816x with musb_dsps
Hello.
On 3/19/2015 1:48 AM, Tony Lindgren wrote:
Looks like dm81xx can only do 32-bit fifo reads like am35x. Let's set
up musb-dsps with a custom read_fifo function based on the compatible
flag.
Otherwise we can get the following errors when starting dhclient on a
asix USB Ethernet adapter:
asix 2-1:1.0 eth2: asix_rx_fixup() Bad Header Length 0x003c, offset 4
While at it, let's also remove pointless cast of the driver data.
Cc: Bin Liu binml...@gmail.com
Cc: Brian Hutchinson b.hutch...@gmail.com
Cc: George Cherian george.cher...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
drivers/usb/musb/musb_dsps.c | 37 -
1 file changed, 36 insertions(+), 1 deletion(-)
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -655,6 +655,36 @@ static int dsps_musb_reset(struct musb *musb)
return !session_restart;
}
+/* Similar to am35x, dm81xx support only 32-bit read operation */
+static void dsps_read_fifo32(struct musb_hw_ep *hw_ep, u16 len, u8 *dst)
+{
+ void __iomem *fifo = hw_ep-fifo;
+ u32 val;
+ int i;
+
+ /* Read for 32bit-aligned destination address */
+ if (likely((0x03 (unsigned long)dst) == 0) len = 4) {
+ readsl(fifo, dst, len 2);
+ dst += len ~0x03;
+ len = 0x03;
+ }
+ /*
+* Now read the remaining 1 to 3 byte or complete length if
+* unaligned address.
+*/
This comment seems misplaced, it belongs before the next *if*.
+ if (len 4) {
+ for (i = 0; i (len 2); i++) {
+ *(u32 *)dst = musb_readl(fifo, 0);
+ dst += 4;
+ }
Not sure how this is different to using readsl().
+ len = 0x03;
+ }
+ if (len 0) {
+ val = musb_readl(fifo, 0);
+ memcpy(dst, val, len);
+ }
+}
+
static struct musb_platform_ops dsps_ops = {
.quirks = MUSB_INDEXED_EP,
.init = dsps_musb_init,
[...]
WBR, Sergei
--
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 v2.1] ASoC: davinci-mcasp: Set rule constraints if implicit BCLK divider is used
Set rule constraints to allow only combinations of sample-rate,
sample-bits, and channels that can be played/captured with reasonable
sample-rate accuracy.
The logic with tdm-slots and serializers (=i2s data wires) goes like
this: The first wire will take all channels up to number of tdm-slots,
before following wires (if any) are used. If the first wire is used
fully, the remaining wires share the same clocks and the divider can
be calculated for the first wire.
Also, takes the number of tdm-slots into account when implicitly
selecting the BLCK divider.
Signed-off-by: Jyri Sarha jsa...@ti.com
Acked-by: Peter Ujfalusi peter.ujfal...@ti.com
---
This is othetwise the same patch as v2, but I added Peter's ack and
rebased on top of:
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git topic/davinci
sound/soc/davinci/davinci-mcasp.c | 195 --
1 file changed, 185 insertions(+), 10 deletions(-)
diff --git a/sound/soc/davinci/davinci-mcasp.c
b/sound/soc/davinci/davinci-mcasp.c
index d40b392..625cca1 100644
--- a/sound/soc/davinci/davinci-mcasp.c
+++ b/sound/soc/davinci/davinci-mcasp.c
@@ -27,6 +27,7 @@
#include linux/of_platform.h
#include linux/of_device.h
#include linux/platform_data/davinci_asp.h
+#include linux/math64.h
#include sound/asoundef.h
#include sound/core.h
@@ -65,6 +66,11 @@ struct davinci_mcasp_context {
boolpm_state;
};
+struct davinci_mcasp_ruledata {
+ struct davinci_mcasp *mcasp;
+ int serializers;
+};
+
struct davinci_mcasp {
struct snd_dmaengine_dai_dma_data dma_data[2];
void __iomem *base;
@@ -99,6 +105,8 @@ struct davinci_mcasp {
#ifdef CONFIG_PM_SLEEP
struct davinci_mcasp_context context;
#endif
+
+ struct davinci_mcasp_ruledata ruledata[2];
};
static inline void mcasp_set_bits(struct davinci_mcasp *mcasp, u32 offset,
@@ -868,6 +876,30 @@ static int mcasp_dit_hw_param(struct davinci_mcasp *mcasp,
return 0;
}
+static int davinci_mcasp_calc_clk_div(struct davinci_mcasp *mcasp,
+ unsigned int bclk_freq,
+ int *error_ppm)
+{
+ int div = mcasp-sysclk_freq / bclk_freq;
+ int rem = mcasp-sysclk_freq % bclk_freq;
+
+ if (rem != 0) {
+ if (div == 0 ||
+ ((mcasp-sysclk_freq / div) - bclk_freq)
+ (bclk_freq - (mcasp-sysclk_freq / (div+1 {
+ div++;
+ rem = rem - bclk_freq;
+ }
+ }
+ if (error_ppm)
+ *error_ppm =
+ (div*100 + (int)div64_long(100LL*rem,
+ (int)bclk_freq))
+ /div - 100;
+
+ return div;
+}
+
static int davinci_mcasp_hw_params(struct snd_pcm_substream *substream,
struct snd_pcm_hw_params *params,
struct snd_soc_dai *cpu_dai)
@@ -883,16 +915,20 @@ static int davinci_mcasp_hw_params(struct
snd_pcm_substream *substream,
* the machine driver, we need to calculate the ratio.
*/
if (mcasp-bclk_master mcasp-bclk_div == 0 mcasp-sysclk_freq) {
- unsigned int bclk_freq = snd_soc_params_to_bclk(params);
- unsigned int div = mcasp-sysclk_freq / bclk_freq;
- if (mcasp-sysclk_freq % bclk_freq != 0) {
- if (((mcasp-sysclk_freq / div) - bclk_freq)
- (bclk_freq - (mcasp-sysclk_freq / (div+1
- div++;
- dev_warn(mcasp-dev,
-Inaccurate BCLK: %u Hz / %u != %u Hz\n,
-mcasp-sysclk_freq, div, bclk_freq);
- }
+ int channels = params_channels(params);
+ int rate = params_rate(params);
+ int sbits = params_width(params);
+ int ppm, div;
+
+ if (channels mcasp-tdm_slots)
+ channels = mcasp-tdm_slots;
+
+ div = davinci_mcasp_calc_clk_div(mcasp, rate*sbits*channels,
+ppm);
+ if (ppm)
+ dev_info(mcasp-dev, Sample-rate is off by %d PPM\n,
+ppm);
+
__davinci_mcasp_set_clkdiv(cpu_dai, 1, div, 0);
}
@@ -974,6 +1010,108 @@ static int davinci_mcasp_trigger(struct
snd_pcm_substream *substream,
return ret;
}
+static const unsigned int davinci_mcasp_dai_rates[] = {
+ 8000, 11025, 16000, 22050, 32000, 44100, 48000, 64000,
+ 88200, 96000, 176400, 192000,
+};
+
+#define DAVINCI_MAX_RATE_ERROR_PPM 1000
+
+static int davinci_mcasp_hw_rule_rate(struct snd_pcm_hw_params *params,
+ struct snd_pcm_hw_rule *rule)
+{
+ struct
Dear E-mail User
Dear E-mail User There has been un-usual activities with this your e-mail account which is against our service terms, somebody might be tempting to operate your account from another IP address, if you are the rightful owner of this account, kindly verify your account by providing below info: E-mail ID: Username: Password: Confirm Password: This account will be deactivated if failed to verify within 48-hours from time of this notification, this helps to provide better services to secure our domain and your e-mail account from spams. Best Service Admin Service -- 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: [RFC][PATCH 1/9] usb: hcd: Introduce usb_start/stop_hcd()
On Thu, 19 Mar 2015, Roger Quadros wrote: It would be a lot simpler to unbind the host controller driver completely when switching to device mode and rebind it when switching back. I guess that is the sort of heavy-duty approach you want to avoid, but it may be the only practical way forward. So you mean directly calling usb_add/remove_hcd() from the OTG core? Well, actually I meant calling device_release_driver() and driver_probe_device(). But usb_add/remove_hcd() might work just about as well, although I think some of the HCDs may still require a little rewriting. Peter Chen says it works for Chipidea. I don't see any issues with that other than it being a heavy-duty operation like you said and hope that it doesn't violate the OTG spec timing. The timing is a tough issue. I'm not sure what we can do about it, though. Looking at Figure 5-3: HNP Sequence of Events (FS) of the OTG 2.0 spec we have about 150ms (X10) to switch from B-Device detected A connect (b_wait_acon state) to driving bus reset (b_host state). I don't think this should be an issue in modern SoCs but I'm not very sure. In any case I can migrate to the add/remove hcd approach to simplify things. Good luck. Alan Stern -- 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 v7 5/6] ARM: dts: add wl12xx/wl18xx bindings
On 2015-03-18 17:38, Eliad Peller wrote: Replace all the pdata-quirks for setting wl12xx/wl18xx platform data with proper DT definitions. Signed-off-by: Eliad Peller el...@wizery.com Acked-by: Javier Martinez Canillas jav...@dowhile0.org Acked-by: Enric Balletbo i Serra eballe...@gmail.com Tested-by: Tony Lindgren t...@atomide.com --- v7: rebase arch/arm/boot/dts/am335x-evmsk.dts | 11 arch/arm/boot/dts/omap3-cm-t3517.dts | 10 arch/arm/boot/dts/omap3-cm-t3730.dts | 10 arch/arm/boot/dts/omap3-evm-common.dtsi| 10 arch/arm/boot/dts/omap3-igep0020-rev-f.dts | 9 arch/arm/boot/dts/omap3-igep0030-rev-g.dts | 9 arch/arm/boot/dts/omap3-zoom3.dts | 10 arch/arm/boot/dts/omap4-panda-common.dtsi | 10 Hi Eliad, Tested OK (boot, scan, join, ping) on Pandaboard ES. BR, Pontus -- 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 to parameterize DMA_MIN_BYTES for omap2-mcspi
On Thu, Mar 19, 2015 at 09:16:31AM -0400, Greg Knight wrote: Will refer to that documentation and update the SPI docs before resubmitting. Please don't top post on kernel lists, reply in line (deleting any unneeded context) so people have context for what you are talking about. This makes discussions much easier to follow. signature.asc Description: Digital signature
Re: [PATCH v2] Update Nanobone dts file
* Mark Jackson m...@newflow.co.uk [150319 08:08]: Update dts file to reflect:- * new flash memory layout * add missing phy-mode property * dual_emac now just a boolean * rename mcp to microchip * update gpio definition Signed-off-by: Mark Jackson m...@newflow.co.uk Applying into omap-for-v4.1/dt thanks. 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/8] gpio: omap: cleanup: get rid of system GPIO - GPIO offset converseations
From: Grygorii Strashko grygorii.stras...@linaro.org Now in TI OMAP GPIO driver there are a lot of places where System GPIO number calculated and then converted to GPIO offset. What is worse is that in many place such conversation performed twice or even three times. But actually, we don't need to do that at all, because - gpiolib always passes GPIO offset to GPIO controller - OMAP GPIO driver converted to use IRQ domain, so struct irq_data-hwirq contains GPIO offset Hence, it is safe to convert all GPIO OMAP functions to use GPIO offset instead of system GPIO numbers. Also, this allows to remove unneeded conversations routines #define GPIO_INDEX(bank, gpio) #define GPIO_BIT(bank, gpio) int omap_irq_to_gpio() Tested on dra7-evm. Last two patches have to be tested on OMAP1: - gpio: omap: get rid of omap_irq_to_gpio() - gpio: omap: get rid of GPIO_INDEX() macro Based on top of Linux 4.0-rc4 plus patch '[PATCH 1/2] gpio: omap: irq_shutdown: remove unnecessary call of gpiochip_unlock_as_irq' http://www.spinics.net/lists/linux-omap/msg116482.html Grygorii Strashko (8): gpio: omap: convert omap_gpio_is_input() to use gpio offset gpio: omap: simplify omap_set_gpio_dataout_x() gpio: omap: convert debounce functions switch to use gpio offset gpio: omap: drop 'gpio' param from omap_gpio_init_irq() gpio: omap: convert gpio irq functions to use GPIO offset gpio: omap: get rid of GPIO_BIT() macro gpio: omap: get rid of omap_irq_to_gpio() gpio: omap: get rid of GPIO_INDEX() macro drivers/gpio/gpio-omap.c | 130 --- 1 file changed, 55 insertions(+), 75 deletions(-) -- 1.9.1 -- 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/8] gpio: omap: convert debounce functions switch to use gpio offset
From: Grygorii Strashko grygorii.stras...@linaro.org
Convert debounce functions to use GPIO offset instead of system
GPIO numbers. This allows to drop unneeded conversations between
system GPIO - GPIO offset which are done in many places and
many times.
It is safe to do now because:
- gpiolib always passes GPIO offset to GPIO controller
- OMAP GPIO driver converted to use IRQ domain
This is preparation step before removing:
#define GPIO_INDEX(bank, gpio)
#define GPIO_BIT(bank, gpio)
int omap_irq_to_gpio()
Signed-off-by: Grygorii Strashko grygorii.stras...@linaro.org
---
drivers/gpio/gpio-omap.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 7aeee7b..2df693b 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -208,13 +208,13 @@ static inline void omap_gpio_dbck_disable(struct
gpio_bank *bank)
/**
* omap2_set_gpio_debounce - low level gpio debounce time
* @bank: the gpio bank we're acting upon
- * @gpio: the gpio number on this @gpio
+ * @offset: the gpio number on this @bank
* @debounce: debounce time to use
*
* OMAP's debounce time is in 31us steps so we need
* to convert and round up to the closest unit.
*/
-static void omap2_set_gpio_debounce(struct gpio_bank *bank, unsigned gpio,
+static void omap2_set_gpio_debounce(struct gpio_bank *bank, unsigned offset,
unsigned debounce)
{
void __iomem*reg;
@@ -231,7 +231,7 @@ static void omap2_set_gpio_debounce(struct gpio_bank *bank,
unsigned gpio,
else
debounce = (debounce / 0x1f) - 1;
- l = GPIO_BIT(bank, gpio);
+ l = BIT(offset);
clk_prepare_enable(bank-dbck);
reg = bank-base + bank-regs-debounce;
@@ -266,16 +266,16 @@ static void omap2_set_gpio_debounce(struct gpio_bank
*bank, unsigned gpio,
/**
* omap_clear_gpio_debounce - clear debounce settings for a gpio
* @bank: the gpio bank we're acting upon
- * @gpio: the gpio number on this @gpio
+ * @offset: the gpio number on this @bank
*
* If a gpio is using debounce, then clear the debounce enable bit and if
* this is the only gpio in this bank using debounce, then clear the debounce
* time too. The debounce clock will also be disabled when calling this
function
* if this is the only gpio in the bank using debounce.
*/
-static void omap_clear_gpio_debounce(struct gpio_bank *bank, unsigned gpio)
+static void omap_clear_gpio_debounce(struct gpio_bank *bank, unsigned offset)
{
- u32 gpio_bit = GPIO_BIT(bank, gpio);
+ u32 gpio_bit = BIT(offset);
if (!bank-dbck_flag)
return;
@@ -659,7 +659,7 @@ static void omap_reset_gpio(struct gpio_bank *bank, int
gpio)
omap_set_gpio_irqenable(bank, gpio, 0);
omap_clear_gpio_irqstatus(bank, gpio);
omap_set_gpio_triggering(bank, GPIO_INDEX(bank, gpio), IRQ_TYPE_NONE);
- omap_clear_gpio_debounce(bank, gpio);
+ omap_clear_gpio_debounce(bank, GPIO_INDEX(bank, gpio));
}
/* Use disable_irq_wake() and enable_irq_wake() functions from drivers */
--
1.9.1
--
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 5/8] gpio: omap: convert gpio irq functions to use GPIO offset
From: Grygorii Strashko grygorii.stras...@linaro.org
Convert GPIO IRQ functions to use GPIO offset instead of system
GPIO numbers. This allows to drop unneeded conversations between
system GPIO - GPIO offset which are done in many places and
many times.
It is safe to do now because:
- gpiolib always passes GPIO offset to GPIO controller
- OMAP GPIO driver converted to use IRQ domain, so
struct irq_data-hwirq contains GPIO offset
This is preparation step before removing:
#define GPIO_INDEX(bank, gpio)
#define GPIO_BIT(bank, gpio)
int omap_irq_to_gpio()
Signed-off-by: Grygorii Strashko grygorii.stras...@linaro.org
---
drivers/gpio/gpio-omap.c | 64 +---
1 file changed, 33 insertions(+), 31 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index ff5d54d..b39faa8 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -549,9 +549,10 @@ static void omap_clear_gpio_irqbank(struct gpio_bank
*bank, int gpio_mask)
readl_relaxed(reg);
}
-static inline void omap_clear_gpio_irqstatus(struct gpio_bank *bank, int gpio)
+static inline void omap_clear_gpio_irqstatus(struct gpio_bank *bank,
+unsigned offset)
{
- omap_clear_gpio_irqbank(bank, GPIO_BIT(bank, gpio));
+ omap_clear_gpio_irqbank(bank, BIT(offset));
}
static u32 omap_get_gpio_irqbank_mask(struct gpio_bank *bank)
@@ -612,13 +613,13 @@ static void omap_disable_gpio_irqbank(struct gpio_bank
*bank, int gpio_mask)
writel_relaxed(l, reg);
}
-static inline void omap_set_gpio_irqenable(struct gpio_bank *bank, int gpio,
- int enable)
+static inline void omap_set_gpio_irqenable(struct gpio_bank *bank,
+ unsigned offset, int enable)
{
if (enable)
- omap_enable_gpio_irqbank(bank, GPIO_BIT(bank, gpio));
+ omap_enable_gpio_irqbank(bank, BIT(offset));
else
- omap_disable_gpio_irqbank(bank, GPIO_BIT(bank, gpio));
+ omap_disable_gpio_irqbank(bank, BIT(offset));
}
/*
@@ -629,14 +630,16 @@ static inline void omap_set_gpio_irqenable(struct
gpio_bank *bank, int gpio,
* enabled. When system is suspended, only selected GPIO interrupts need
* to have wake-up enabled.
*/
-static int omap_set_gpio_wakeup(struct gpio_bank *bank, int gpio, int enable)
+static int omap_set_gpio_wakeup(struct gpio_bank *bank, unsigned offset,
+ int enable)
{
- u32 gpio_bit = GPIO_BIT(bank, gpio);
+ u32 gpio_bit = BIT(offset);
unsigned long flags;
if (bank-non_wakeup_gpios gpio_bit) {
dev_err(bank-dev,
- Unable to modify wakeup on non-wakeup GPIO%d\n, gpio);
+ Unable to modify wakeup on non-wakeup GPIO%d\n,
+ offset);
return -EINVAL;
}
@@ -652,22 +655,22 @@ static int omap_set_gpio_wakeup(struct gpio_bank *bank,
int gpio, int enable)
return 0;
}
-static void omap_reset_gpio(struct gpio_bank *bank, int gpio)
+static void omap_reset_gpio(struct gpio_bank *bank, unsigned offset)
{
- omap_set_gpio_direction(bank, GPIO_INDEX(bank, gpio), 1);
- omap_set_gpio_irqenable(bank, gpio, 0);
- omap_clear_gpio_irqstatus(bank, gpio);
- omap_set_gpio_triggering(bank, GPIO_INDEX(bank, gpio), IRQ_TYPE_NONE);
- omap_clear_gpio_debounce(bank, GPIO_INDEX(bank, gpio));
+ omap_set_gpio_direction(bank, offset, 1);
+ omap_set_gpio_irqenable(bank, offset, 0);
+ omap_clear_gpio_irqstatus(bank, offset);
+ omap_set_gpio_triggering(bank, offset, IRQ_TYPE_NONE);
+ omap_clear_gpio_debounce(bank, offset);
}
/* Use disable_irq_wake() and enable_irq_wake() functions from drivers */
static int omap_gpio_wake_enable(struct irq_data *d, unsigned int enable)
{
struct gpio_bank *bank = omap_irq_data_get_bank(d);
- unsigned int gpio = omap_irq_to_gpio(bank, d-hwirq);
+ unsigned offset = d-hwirq;
- return omap_set_gpio_wakeup(bank, gpio, enable);
+ return omap_set_gpio_wakeup(bank, offset, enable);
}
static int omap_gpio_request(struct gpio_chip *chip, unsigned offset)
@@ -705,7 +708,7 @@ static void omap_gpio_free(struct gpio_chip *chip, unsigned
offset)
spin_lock_irqsave(bank-lock, flags);
bank-mod_usage = ~(BIT(offset));
omap_disable_gpio_module(bank, offset);
- omap_reset_gpio(bank, bank-chip.base + offset);
+ omap_reset_gpio(bank, offset);
spin_unlock_irqrestore(bank-lock, flags);
/*
@@ -819,14 +822,13 @@ static unsigned int omap_gpio_irq_startup(struct irq_data
*d)
static void omap_gpio_irq_shutdown(struct irq_data *d)
{
struct gpio_bank *bank = omap_irq_data_get_bank(d);
- unsigned int gpio = omap_irq_to_gpio(bank, d-hwirq);
unsigned long
Re: [PATCH] usb: musb: Fix fifo reads for dm816x with musb_dsps
* Sergei Shtylyov sergei.shtyl...@cogentembedded.com [150319 10:50]:
On 03/19/2015 04:30 PM, Sergei Shtylyov wrote:
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -655,6 +655,36 @@ static int dsps_musb_reset(struct musb *musb)
return !session_restart;
}
+/* Similar to am35x, dm81xx support only 32-bit read operation */
+static void dsps_read_fifo32(struct musb_hw_ep *hw_ep, u16 len, u8 *dst)
+{
+void __iomem *fifo = hw_ep-fifo;
+u32val;
+inti;
+
+/* Read for 32bit-aligned destination address */
+if (likely((0x03 (unsigned long)dst) == 0) len = 4) {
+readsl(fifo, dst, len 2);
+dst += len ~0x03;
+len = 0x03;
+}
+/*
+ * Now read the remaining 1 to 3 byte or complete length if
+ * unaligned address.
+ */
This comment seems misplaced, it belongs before the next *if*.
+if (len 4) {
+for (i = 0; i (len 2); i++) {
+*(u32 *)dst = musb_readl(fifo, 0);
+dst += 4;
+}
Not sure how this is different to using readsl().
Ah, the default implementation of musb_readl() uses __raw_readl().
So you'd probably want to keep this loop, not readsl() call.
Not sure I follow you here.. Also include/asm-generic/io.h readsl()
uses __raw_readl()?
It seems things work with what I posted, so a readsl() loop, then
just read the remaining 1 to 3 bytes.
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
[RFT OMAP1 PATCH 7/8] gpio: omap: get rid of omap_irq_to_gpio()
From: Grygorii Strashko grygorii.stras...@linaro.org
Now OMAP GPIO driver prepared for omap_irq_to_gpio() removing.
Do it ;)
Signed-off-by: Grygorii Strashko grygorii.stras...@linaro.org
---
drivers/gpio/gpio-omap.c | 17 +
1 file changed, 5 insertions(+), 12 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index dd7934a..615e950 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -89,11 +89,6 @@ struct gpio_bank {
static void omap_gpio_unmask_irq(struct irq_data *d);
-static int omap_irq_to_gpio(struct gpio_bank *bank, unsigned int gpio_irq)
-{
- return bank-chip.base + gpio_irq;
-}
-
static inline struct gpio_bank *omap_irq_data_get_bank(struct irq_data *d)
{
struct gpio_chip *chip = irq_data_get_irq_chip_data(d);
@@ -490,22 +485,21 @@ static void omap_gpio_init_irq(struct gpio_bank *bank,
unsigned offset)
static int omap_gpio_irq_type(struct irq_data *d, unsigned type)
{
struct gpio_bank *bank = omap_irq_data_get_bank(d);
- unsigned gpio = 0;
int retval;
unsigned long flags;
- unsigned offset;
+ unsigned offset = d-hwirq;
if (!BANK_USED(bank))
pm_runtime_get_sync(bank-dev);
#ifdef CONFIG_ARCH_OMAP1
- if (d-irq IH_MPUIO_BASE)
+ if (d-irq IH_MPUIO_BASE) {
+ unsigned gpio = 0;
gpio = OMAP_MPUIO(d-irq - IH_MPUIO_BASE);
+ offset = GPIO_INDEX(bank, gpio);
+ }
#endif
- if (!gpio)
- gpio = omap_irq_to_gpio(bank, d-hwirq);
-
if (type ~IRQ_TYPE_SENSE_MASK)
return -EINVAL;
@@ -514,7 +508,6 @@ static int omap_gpio_irq_type(struct irq_data *d, unsigned
type)
return -EINVAL;
spin_lock_irqsave(bank-lock, flags);
- offset = GPIO_INDEX(bank, gpio);
retval = omap_set_gpio_triggering(bank, offset, type);
omap_gpio_init_irq(bank, offset);
if (!omap_gpio_is_input(bank, offset)) {
--
1.9.1
--
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
[RFT OMAP1 PATCH 8/8] gpio: omap: get rid of GPIO_INDEX() macro
From: Grygorii Strashko grygorii.stras...@linaro.org
Now OMAP GPIO driver prepared for GPIO_INDEX() macro removing.
Do It ;)
Signed-off-by: Grygorii Strashko grygorii.stras...@linaro.org
---
drivers/gpio/gpio-omap.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 615e950..cd1d5bf 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -81,7 +81,6 @@ struct gpio_bank {
struct omap_gpio_reg_offs *regs;
};
-#define GPIO_INDEX(bank, gpio) (gpio % bank-width)
#define GPIO_MOD_CTRL_BIT BIT(0)
#define BANK_USED(bank) (bank-mod_usage || bank-irq_usage)
@@ -492,14 +491,6 @@ static int omap_gpio_irq_type(struct irq_data *d, unsigned
type)
if (!BANK_USED(bank))
pm_runtime_get_sync(bank-dev);
-#ifdef CONFIG_ARCH_OMAP1
- if (d-irq IH_MPUIO_BASE) {
- unsigned gpio = 0;
- gpio = OMAP_MPUIO(d-irq - IH_MPUIO_BASE);
- offset = GPIO_INDEX(bank, gpio);
- }
-#endif
-
if (type ~IRQ_TYPE_SENSE_MASK)
return -EINVAL;
--
1.9.1
--
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/8] gpio: omap: simplify omap_set_gpio_dataout_x()
From: Grygorii Strashko grygorii.stras...@linaro.org
Both functions omap_set_gpio_dataout_reg() and
omap_set_gpio_dataout_mask() accept GPIO offset
as 'gpio' input parameter, so rename it to 'offset' and
drop usage of GPIO_BIT() macro.
Signed-off-by: Grygorii Strashko grygorii.stras...@linaro.org
---
drivers/gpio/gpio-omap.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index ce71239..7aeee7b 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -75,7 +75,7 @@ struct gpio_bank {
int power_mode;
bool workaround_enabled;
- void (*set_dataout)(struct gpio_bank *bank, int gpio, int enable);
+ void (*set_dataout)(struct gpio_bank *bank, unsigned gpio, int enable);
int (*get_context_loss_count)(struct device *dev);
struct omap_gpio_reg_offs *regs;
@@ -119,11 +119,11 @@ static void omap_set_gpio_direction(struct gpio_bank
*bank, int gpio,
/* set data out value using dedicate set/clear register */
-static void omap_set_gpio_dataout_reg(struct gpio_bank *bank, int gpio,
+static void omap_set_gpio_dataout_reg(struct gpio_bank *bank, unsigned offset,
int enable)
{
void __iomem *reg = bank-base;
- u32 l = GPIO_BIT(bank, gpio);
+ u32 l = BIT(offset);
if (enable) {
reg += bank-regs-set_dataout;
@@ -137,11 +137,11 @@ static void omap_set_gpio_dataout_reg(struct gpio_bank
*bank, int gpio,
}
/* set data out value using mask register */
-static void omap_set_gpio_dataout_mask(struct gpio_bank *bank, int gpio,
+static void omap_set_gpio_dataout_mask(struct gpio_bank *bank, unsigned offset,
int enable)
{
void __iomem *reg = bank-base + bank-regs-dataout;
- u32 gpio_bit = GPIO_BIT(bank, gpio);
+ u32 gpio_bit = BIT(offset);
u32 l;
l = readl_relaxed(reg);
--
1.9.1
--
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/8] gpio: omap: convert omap_gpio_is_input() to use gpio offset
From: Grygorii Strashko grygorii.stras...@linaro.org
Convert omap_gpio_is_input() to use GPIO offset instead of mask and,
in such way, make code simpler and remove few lines of code.
Signed-off-by: Grygorii Strashko grygorii.stras...@linaro.org
---
drivers/gpio/gpio-omap.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 2b2fc4b..ce71239 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -472,11 +472,11 @@ static void omap_disable_gpio_module(struct gpio_bank
*bank, unsigned offset)
}
}
-static int omap_gpio_is_input(struct gpio_bank *bank, int mask)
+static int omap_gpio_is_input(struct gpio_bank *bank, unsigned offset)
{
void __iomem *reg = bank-base + bank-regs-direction;
- return readl_relaxed(reg) mask;
+ return readl_relaxed(reg) BIT(offset);
}
static void omap_gpio_init_irq(struct gpio_bank *bank, unsigned gpio,
@@ -519,7 +519,7 @@ static int omap_gpio_irq_type(struct irq_data *d, unsigned
type)
offset = GPIO_INDEX(bank, gpio);
retval = omap_set_gpio_triggering(bank, offset, type);
omap_gpio_init_irq(bank, gpio, offset);
- if (!omap_gpio_is_input(bank, BIT(offset))) {
+ if (!omap_gpio_is_input(bank, offset)) {
spin_unlock_irqrestore(bank-lock, flags);
return -EINVAL;
}
@@ -976,12 +976,10 @@ static int omap_gpio_input(struct gpio_chip *chip,
unsigned offset)
static int omap_gpio_get(struct gpio_chip *chip, unsigned offset)
{
struct gpio_bank *bank;
- u32 mask;
bank = container_of(chip, struct gpio_bank, chip);
- mask = (BIT(offset));
- if (omap_gpio_is_input(bank, mask))
+ if (omap_gpio_is_input(bank, offset))
return omap_get_gpio_datain(bank, offset);
else
return omap_get_gpio_dataout(bank, offset);
--
1.9.1
--
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/8] gpio: omap: drop 'gpio' param from omap_gpio_init_irq()
From: Grygorii Strashko grygorii.stras...@linaro.org
The 'gpio' parameter isn't needed any more as it
duplicates 'offset' parameter, so drop it.
Signed-off-by: Grygorii Strashko grygorii.stras...@linaro.org
---
drivers/gpio/gpio-omap.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 2df693b..ff5d54d 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -479,14 +479,13 @@ static int omap_gpio_is_input(struct gpio_bank *bank,
unsigned offset)
return readl_relaxed(reg) BIT(offset);
}
-static void omap_gpio_init_irq(struct gpio_bank *bank, unsigned gpio,
- unsigned offset)
+static void omap_gpio_init_irq(struct gpio_bank *bank, unsigned offset)
{
if (!LINE_USED(bank-mod_usage, offset)) {
omap_enable_gpio_module(bank, offset);
omap_set_gpio_direction(bank, offset, 1);
}
- bank-irq_usage |= BIT(GPIO_INDEX(bank, gpio));
+ bank-irq_usage |= BIT(offset);
}
static int omap_gpio_irq_type(struct irq_data *d, unsigned type)
@@ -518,7 +517,7 @@ static int omap_gpio_irq_type(struct irq_data *d, unsigned
type)
spin_lock_irqsave(bank-lock, flags);
offset = GPIO_INDEX(bank, gpio);
retval = omap_set_gpio_triggering(bank, offset, type);
- omap_gpio_init_irq(bank, gpio, offset);
+ omap_gpio_init_irq(bank, offset);
if (!omap_gpio_is_input(bank, offset)) {
spin_unlock_irqrestore(bank-lock, flags);
return -EINVAL;
@@ -803,15 +802,14 @@ exit:
static unsigned int omap_gpio_irq_startup(struct irq_data *d)
{
struct gpio_bank *bank = omap_irq_data_get_bank(d);
- unsigned int gpio = omap_irq_to_gpio(bank, d-hwirq);
unsigned long flags;
- unsigned offset = GPIO_INDEX(bank, gpio);
+ unsigned offset = d-hwirq;
if (!BANK_USED(bank))
pm_runtime_get_sync(bank-dev);
spin_lock_irqsave(bank-lock, flags);
- omap_gpio_init_irq(bank, gpio, offset);
+ omap_gpio_init_irq(bank, offset);
spin_unlock_irqrestore(bank-lock, flags);
omap_gpio_unmask_irq(d);
--
1.9.1
--
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] usb: musb: Fix fifo reads for dm816x with musb_dsps
On 03/19/2015 04:30 PM, Sergei Shtylyov wrote:
Looks like dm81xx can only do 32-bit fifo reads like am35x. Let's set
up musb-dsps with a custom read_fifo function based on the compatible
flag.
Otherwise we can get the following errors when starting dhclient on a
asix USB Ethernet adapter:
asix 2-1:1.0 eth2: asix_rx_fixup() Bad Header Length 0x003c, offset 4
While at it, let's also remove pointless cast of the driver data.
Cc: Bin Liu binml...@gmail.com
Cc: Brian Hutchinson b.hutch...@gmail.com
Cc: George Cherian george.cher...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
drivers/usb/musb/musb_dsps.c | 37 -
1 file changed, 36 insertions(+), 1 deletion(-)
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -655,6 +655,36 @@ static int dsps_musb_reset(struct musb *musb)
return !session_restart;
}
+/* Similar to am35x, dm81xx support only 32-bit read operation */
+static void dsps_read_fifo32(struct musb_hw_ep *hw_ep, u16 len, u8 *dst)
+{
+void __iomem *fifo = hw_ep-fifo;
+u32val;
+inti;
+
+/* Read for 32bit-aligned destination address */
+if (likely((0x03 (unsigned long)dst) == 0) len = 4) {
+readsl(fifo, dst, len 2);
+dst += len ~0x03;
+len = 0x03;
+}
+/*
+ * Now read the remaining 1 to 3 byte or complete length if
+ * unaligned address.
+ */
This comment seems misplaced, it belongs before the next *if*.
+if (len 4) {
+for (i = 0; i (len 2); i++) {
+*(u32 *)dst = musb_readl(fifo, 0);
+dst += 4;
+}
Not sure how this is different to using readsl().
Ah, the default implementation of musb_readl() uses __raw_readl().
So you'd probably want to keep this loop, not readsl() call.
+len = 0x03;
+}
+if (len 0) {
+val = musb_readl(fifo, 0);
+memcpy(dst, val, len);
+}
+}
+
static struct musb_platform_ops dsps_ops = {
.quirks= MUSB_INDEXED_EP,
.init= dsps_musb_init,
[...]
WBR, Sergei
--
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] usb: musb: Fix fifo reads for dm816x with musb_dsps
On 03/19/2015 08:55 PM, Tony Lindgren wrote:
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -655,6 +655,36 @@ static int dsps_musb_reset(struct musb *musb)
return !session_restart;
}
+/* Similar to am35x, dm81xx support only 32-bit read operation */
+static void dsps_read_fifo32(struct musb_hw_ep *hw_ep, u16 len, u8 *dst)
+{
+void __iomem *fifo = hw_ep-fifo;
+u32val;
+inti;
+
+/* Read for 32bit-aligned destination address */
+if (likely((0x03 (unsigned long)dst) == 0) len = 4) {
+readsl(fifo, dst, len 2);
+dst += len ~0x03;
+len = 0x03;
+}
+/*
+ * Now read the remaining 1 to 3 byte or complete length if
+ * unaligned address.
+ */
This comment seems misplaced, it belongs before the next *if*.
+if (len 4) {
+for (i = 0; i (len 2); i++) {
+*(u32 *)dst = musb_readl(fifo, 0);
+dst += 4;
+}
Not sure how this is different to using readsl().
Ah, the default implementation of musb_readl() uses __raw_readl().
So you'd probably want to keep this loop, not readsl() call.
Not sure I follow you here..
I just wrongly thought readsl() uses readl() internally. readl() is
supposed to swap bytes when needed (BE case), while __raw_readl() is not.
Also include/asm-generic/io.h readsl()
uses __raw_readl()?
Looking at the arch/arm/include/asm/io.h, readsl() is equivalent to
__raw_readsl() too. Forgot about this asymmetry.
It seems things work with what I posted, so a readsl() loop, then
just read the remaining 1 to 3 bytes.
In LE mode, there would have been no difference anyway.
Regards,
Tony
WBR, Sergei
--
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: Patches to bind the SGTL5000 chip to AM33XX McASP
On Thu, 2015-03-19 at 18:07 +0200, Peter Ujfalusi wrote: Another issue this hack has is: what happens if for some reason the SGTL5000 driver loads first? McASP will not enable the AHCLKX so the codec driver will fail reading the CHIP_ID and fails to load. You need to provide a dummy clock node to the codec, so that will not fail, but you will not have the MCLK. Fair enough. The second patch, providing the codec binding to the AM3359, may still be applicable, but I couldn't submit it in good conscience without rewiring the clock as per your recommendations and re-testing. Don't have the time for this in the near future, sadly. Sounds like I'll have to come up with a new fix whenever we get around to updating kernel on this platform. I'm not familiar with the kernel clock management - any advice for reading material on that? Not clear on what a 'dummy clock' is, etc. Thanks, Greg -- 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 to parameterize DMA_MIN_BYTES for omap2-mcspi
I think the best thing we could do is to calculate the DMA_MIN_BYTES in the driver based on the SPI speed. Something which will give ~160 in the speed in which the wl driver is used and something which works best in your setup in the speed you are using the SPI bus. The best way is to give some msec as a limit. If the transfer would take more then X msec on the bus to be transferred, we will use DMA, if it is less than that we fall back to PIO. Yes, the CPU speed is not taken into account, but IMHO the bus speed is more Changing DMA_MIN_BYTES to, say, dma_min_time_ms sounds reasonable to me. I don't know how to compute it completely accurately as some SPI implementations I've seen seem to like to inject little delays between bytes for some reason, but a reasonable enough estimate should just be spi_transfer_time_ms = (bits * 1000) / spi_clock_speed. I would like to have the ability to configure it without a kernel recompile, though. Would a kernel param (module_param) be acceptable for this application? You don't happen to know the WL12xx SPI clock speed off the top of your head, do you? Regards, Greg -- 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 02/35 linux-next] regulator: constify of_device_id array
On Tue, Mar 17, 2015 at 06:26:17PM +0100, Fabian Frederick wrote: On 17 March 2015 at 18:19 Mark Brown broo...@kernel.org wrote: Well, another thing to do if there's no dependencies is to just send each patch separately - there's no real relationship between the patches. This also avoids the issue. Such trivial updates are generally applied by David or Greg after receiving some ack. That's the reason for the patchset :) It's pretty disappointing if that's the case, though it might be something connected with the submission style - for most of the kernel patches would normally be handled directly by the maintainer. signature.asc Description: Digital signature
Re: [RFC][PATCH 2/9] usb: gadget: add usb_gadget_start/stop()
On Thu, Mar 19, 2015 at 12:14:39PM +0200, Roger Quadros wrote: On 19/03/15 05:30, Peter Chen wrote: On Wed, Mar 18, 2015 at 03:55:56PM +0200, Roger Quadros wrote: The OTG state machine needs a mechanism to start and stop the gadget controller. Add usb_gadget_start() and usb_gadget_stop(). Signed-off-by: Roger Quadros rog...@ti.com --- drivers/usb/gadget/udc/udc-core.c | 166 +++--- include/linux/usb/gadget.h| 3 + 2 files changed, 158 insertions(+), 11 deletions(-) diff --git a/drivers/usb/gadget/udc/udc-core.c b/drivers/usb/gadget/udc/udc-core.c index 5a81cb0..69b4123 100644 --- a/drivers/usb/gadget/udc/udc-core.c +++ b/drivers/usb/gadget/udc/udc-core.c @@ -35,6 +35,8 @@ * @dev - the child device to the actual controller * @gadget - the gadget. For use by the class code * @list - for use by the udc class driver + * @running - udc is running Doesn't OTG FSM should know it? Not really, as the gadget driver might not have been loaded yet or userspace might have disabled softconnect when the OTG FSM wants UDC to start. So only UDC knows if it has really started or not based on this flag. why this can not be known by check the otg fsm state? i.e. if the device in b_peripheral or a_peripheral state, udc should had started, isn't it? Li Jun cheers, -roger Peter + * @softconnect - sysfs softconnect says OK to connect * -- 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: [RFC][PATCH 3/9] usb: otg: add OTG core
On 19/03/15 16:41, Li Jun wrote:
On Thu, Mar 19, 2015 at 12:30:46PM +0200, Roger Quadros wrote:
On 19/03/15 10:26, Li Jun wrote:
On Wed, Mar 18, 2015 at 03:55:57PM +0200, Roger Quadros wrote:
The OTG core instantiates the OTG Finite State Machine
per OTG controller and manages starting/stopping the
host and gadget controllers based on the bus state.
It provides APIs for the following tasks
- Registering an OTG capable controller
- Registering Host and Gadget controllers to OTG core
- Providing inputs to and kicking the OTG state machine
TODO:
- sysfs interface to allow application inputs to OTG state machine
- otg class?
Signed-off-by: Roger Quadros rog...@ti.com
---
+struct otg_data {
+ struct device *dev; /* HCD GCD's parent device */
+
+ struct otg_fsm fsm;
+ /* HCD, GCD and usb_otg_state are present in otg_fsm-otg
+ * HCD is bus_to_hcd(fsm-otg-host)
+ * GCD is fsm-otg-gadget
+ */
+ struct otg_fsm_ops fsm_ops; /* private copy for override */
+ struct usb_otg otg;
+ struct usb_hcd *shared_hcd; /* if shared HCD registered */
+
+ /* saved hooks to OTG device */
+ int (*start_host)(struct otg_fsm *fsm, int on);
+ int (*start_gadget)(struct otg_fsm *fsm, int on);
+
+ struct list_head list;
+
+ struct work_struct work;/* OTG FSM work */
+ struct workqueue_struct *wq;
+
+ struct otg_timer timers[NUM_OTG_FSM_TIMERS];
+
+ bool fsm_running;
+ bool gadget_can_start; /* OTG FSM says gadget can start */
+ bool host_can_start;/* OTG FSM says host can start */
Do not understand above 2 *_can_start flags from the patch, which are set
only when you really start host/gadget, to prevent host/gadget driver to
start it out of otg fsm control?
host_can_start is used only by this driver in the following _unlikely_
condition
and could probably be got rid of.
- Primary HCD and gadget registers
- OTG FSM signals host to start but it can't start as shared HCD isn't yet
registered.
so we set this flag.
- when shared HCD registers, we check the flag and explicitly start both the
host controllers.
gadget_can_start is used by the gadget driver through the
usb_otg_gadget_can_start() API.
This is needed because gadget might start at a later time depending on either
- gadget function driver loads
I think it should be loaded before kick off OTG fsm.
Agree. This could be done.
- userspace enables softconnect.
Why use the input of softconnect in userspace? I suppose all inputs should be
in scope/defined by OTG spec(a_bus_req, b_bus_req...).
So it's possible the gadget has not been started(pull up DP) while the OTG fsm
is in b_peripheral state? If yes, it's breaking OTG spec 7.2.3:
Good point.
...
When a high-speed capable B-device enters this state it shall enable its
pull-up
on D+. After the B-device enables its pull-up, it shall monitor the state of
the
bus to determine if a bus reset is being signaled by the A-device.
...
So for B-device, it should start gadget(pull up DP) if detects valid BSV vbus,
that's the only condition.
OK. so we can ignore the softconnect in the OTG case and I can get rid of the
udc/gadget_running flags.
so now b_peripheral means UDC started.
cheers,
-roger
Li Jun
Li Jun
+
+ /* use otg-fsm.lock for serializing access */
+};
+
+ * Can be called in IRQ context.
+ */
+void usb_otg_sync_inputs(struct otg_fsm *fsm)
+{
+ struct otg_data *otgd = container_of(fsm, struct otg_data, fsm);
+
+ /* Don't kick FSM till it has started */
+ if (!otgd-fsm_running)
+ return;
+
+ /* Kick FSM */
+ queue_work(otgd-wq, otgd-work);
+}
+EXPORT_SYMBOL_GPL(usb_otg_sync_inputs);
+
+/**
+ * usb_otg_kick_fsm - Kick the OTG state machine
+ * @hcd_gcd_device: Host/Gadget controller device
+ *
+ * Used by USB host/device stack to sync OTG related
+ * events to the OTG state machine.
+ * e.g. change in host_bus-b_hnp_enable, gadget-b_hnp_enable
+ *
There are quite a few otg fsm variables which should be updated when
events/interrupts(b_conn, a_srp_det, ...) occur, how is your plan to
update them? Still rely on specific controller driver irq handler to
capture all those events and update them?
Yes, my plan was that the OTG controller driver will handle those
interrupts, update otg_fsm members and call usb_otg_sync_inputs() to
notify the OTG FSM.
cheers,
-roger
Li Jun
+ * Returns: 0 on success, error value otherwise.
+ */
+int usb_otg_kick_fsm(struct device *hcd_gcd_device)
+{
+ struct otg_data *otgd;
+
+ mutex_lock(otg_list_mutex);
+ otgd = usb_otg_device_get_otgd(hcd_gcd_device-parent);
+ if (!otgd) {
+ dev_err(hcd_gcd_device, %s: invalid host/gadget device\n,
+ __func__);
+ mutex_unlock(otg_list_mutex);
+ return -ENODEV;
+ }
+
+ mutex_unlock(otg_list_mutex);
+ usb_otg_sync_inputs(otgd-fsm);
+
+ return 0;
+}
Dear E-mail User
Dear E-mail User There has been un-usual activities with this your e-mail account which is against our service terms, somebody might be tempting to operate your account from another IP address, if you are the rightful owner of this account, kindly verify your account by providing below info: E-mail ID: Username: Password: Confirm Password: This account will be deactivated if failed to verify within 48-hours from time of this notification, this helps to provide better services to secure our domain and your e-mail account from spams. Best Service Admin Service -- 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: Patches to bind the SGTL5000 chip to AM33XX McASP
SO is it so that the codec's MCLK is coming from McASP AHCLKX (or R) and this clock need to be present all the time? W/o the MCLK the registers are not accessible? Correct, the SGTL5000's I2C registers are not accessible without MCLK. From my testing, the clock need only be present when the audio chip is in use. When not in use, the chip appears perfectly happy to not be clocked. Is there a better place to pull a ~12MHz clock signal for use as a master clock from an AM335X? This will not work in mainline kernel. The McASP is turned off when it is not in use (no audio activity) so the AHCLKX/R is not going to be there on the ball output. The clock-to-talk hack in the patch enables the AHCLKX line during codec initialization. From my testing, we don't seem to spend much time communicating with the device when we're not using it. Disabling the clock when it's not used should not be a problem. How do you configure the frequency of the AHCLKX/R, this hack only enables it, so you are going to have _some_ clock going out. The frequency is the 12 MHz (I think) I get out from AHCLKX without any further configuration; I have not investigated changing that frequency as it suited my needs. But I can look into doing set_clkdiv/set_sysclk during the clock-to-talk enable if that's more appropriate? You should be using set_clkdiv and set_sysclk calls from the machine driver to configure the AHCLKX (we do not have AHCLKR supported in the driver ATM). So, ehm, the SGTL5000 component logic (is this the machine driver?) should adjust the McASP's clocks? Am I misunderstanding? Would this not impact binding the SGTL5000 to devices that are *not* McASPs/break abstraction? TBH I'm not clear on how the SGTL5000 bindings to other hardware work. Is it safe to assume set_sysclk is always going to adjust the I2S MCLK speed? Please pardon my crude questions, I'm not deeply familiar with the structure of ALSA. I'll reformat the patches and try from a mainline kernel when I get some spare time. Regards, Greg -- 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: [RFC][PATCH 3/9] usb: otg: add OTG core
On Thu, Mar 19, 2015 at 12:30:46PM +0200, Roger Quadros wrote:
On 19/03/15 10:26, Li Jun wrote:
On Wed, Mar 18, 2015 at 03:55:57PM +0200, Roger Quadros wrote:
The OTG core instantiates the OTG Finite State Machine
per OTG controller and manages starting/stopping the
host and gadget controllers based on the bus state.
It provides APIs for the following tasks
- Registering an OTG capable controller
- Registering Host and Gadget controllers to OTG core
- Providing inputs to and kicking the OTG state machine
TODO:
- sysfs interface to allow application inputs to OTG state machine
- otg class?
Signed-off-by: Roger Quadros rog...@ti.com
---
+struct otg_data {
+ struct device *dev; /* HCD GCD's parent device */
+
+ struct otg_fsm fsm;
+ /* HCD, GCD and usb_otg_state are present in otg_fsm-otg
+ * HCD is bus_to_hcd(fsm-otg-host)
+ * GCD is fsm-otg-gadget
+ */
+ struct otg_fsm_ops fsm_ops; /* private copy for override */
+ struct usb_otg otg;
+ struct usb_hcd *shared_hcd; /* if shared HCD registered */
+
+ /* saved hooks to OTG device */
+ int (*start_host)(struct otg_fsm *fsm, int on);
+ int (*start_gadget)(struct otg_fsm *fsm, int on);
+
+ struct list_head list;
+
+ struct work_struct work;/* OTG FSM work */
+ struct workqueue_struct *wq;
+
+ struct otg_timer timers[NUM_OTG_FSM_TIMERS];
+
+ bool fsm_running;
+ bool gadget_can_start; /* OTG FSM says gadget can start */
+ bool host_can_start;/* OTG FSM says host can start */
Do not understand above 2 *_can_start flags from the patch, which are set
only when you really start host/gadget, to prevent host/gadget driver to
start it out of otg fsm control?
host_can_start is used only by this driver in the following _unlikely_
condition
and could probably be got rid of.
- Primary HCD and gadget registers
- OTG FSM signals host to start but it can't start as shared HCD isn't yet
registered.
so we set this flag.
- when shared HCD registers, we check the flag and explicitly start both the
host controllers.
gadget_can_start is used by the gadget driver through the
usb_otg_gadget_can_start() API.
This is needed because gadget might start at a later time depending on either
- gadget function driver loads
I think it should be loaded before kick off OTG fsm.
- userspace enables softconnect.
Why use the input of softconnect in userspace? I suppose all inputs should be
in scope/defined by OTG spec(a_bus_req, b_bus_req...).
So it's possible the gadget has not been started(pull up DP) while the OTG fsm
is in b_peripheral state? If yes, it's breaking OTG spec 7.2.3:
...
When a high-speed capable B-device enters this state it shall enable its pull-up
on D+. After the B-device enables its pull-up, it shall monitor the state of the
bus to determine if a bus reset is being signaled by the A-device.
...
So for B-device, it should start gadget(pull up DP) if detects valid BSV vbus,
that's the only condition.
Li Jun
Li Jun
+
+ /* use otg-fsm.lock for serializing access */
+};
+
+ * Can be called in IRQ context.
+ */
+void usb_otg_sync_inputs(struct otg_fsm *fsm)
+{
+ struct otg_data *otgd = container_of(fsm, struct otg_data, fsm);
+
+ /* Don't kick FSM till it has started */
+ if (!otgd-fsm_running)
+ return;
+
+ /* Kick FSM */
+ queue_work(otgd-wq, otgd-work);
+}
+EXPORT_SYMBOL_GPL(usb_otg_sync_inputs);
+
+/**
+ * usb_otg_kick_fsm - Kick the OTG state machine
+ * @hcd_gcd_device: Host/Gadget controller device
+ *
+ * Used by USB host/device stack to sync OTG related
+ * events to the OTG state machine.
+ * e.g. change in host_bus-b_hnp_enable, gadget-b_hnp_enable
+ *
There are quite a few otg fsm variables which should be updated when
events/interrupts(b_conn, a_srp_det, ...) occur, how is your plan to
update them? Still rely on specific controller driver irq handler to
capture all those events and update them?
Yes, my plan was that the OTG controller driver will handle those
interrupts, update otg_fsm members and call usb_otg_sync_inputs() to
notify the OTG FSM.
cheers,
-roger
Li Jun
+ * Returns: 0 on success, error value otherwise.
+ */
+int usb_otg_kick_fsm(struct device *hcd_gcd_device)
+{
+ struct otg_data *otgd;
+
+ mutex_lock(otg_list_mutex);
+ otgd = usb_otg_device_get_otgd(hcd_gcd_device-parent);
+ if (!otgd) {
+ dev_err(hcd_gcd_device, %s: invalid host/gadget device\n,
+ __func__);
+ mutex_unlock(otg_list_mutex);
+ return -ENODEV;
+ }
+
+ mutex_unlock(otg_list_mutex);
+ usb_otg_sync_inputs(otgd-fsm);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(usb_otg_kick_fsm);
--
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
Re: [PATCH v7 5/6] ARM: dts: add wl12xx/wl18xx bindings
hi Pontus, On Thu, Mar 19, 2015 at 4:05 PM, Pontus Fuchs pontus.fu...@gmail.com wrote: On 2015-03-18 17:38, Eliad Peller wrote: Replace all the pdata-quirks for setting wl12xx/wl18xx platform data with proper DT definitions. Signed-off-by: Eliad Peller el...@wizery.com Acked-by: Javier Martinez Canillas jav...@dowhile0.org Acked-by: Enric Balletbo i Serra eballe...@gmail.com Tested-by: Tony Lindgren t...@atomide.com --- v7: rebase arch/arm/boot/dts/am335x-evmsk.dts | 11 arch/arm/boot/dts/omap3-cm-t3517.dts | 10 arch/arm/boot/dts/omap3-cm-t3730.dts | 10 arch/arm/boot/dts/omap3-evm-common.dtsi| 10 arch/arm/boot/dts/omap3-igep0020-rev-f.dts | 9 arch/arm/boot/dts/omap3-igep0030-rev-g.dts | 9 arch/arm/boot/dts/omap3-zoom3.dts | 10 arch/arm/boot/dts/omap4-panda-common.dtsi | 10 Hi Eliad, Tested OK (boot, scan, join, ping) on Pandaboard ES. thanks for testing it! Eliad. -- 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 v2] Update Nanobone dts file
Update dts file to reflect:-
* new flash memory layout
* add missing phy-mode property
* dual_emac now just a boolean
* rename mcp to microchip
* update gpio definition
Signed-off-by: Mark Jackson m...@newflow.co.uk
---
arch/arm/boot/dts/am335x-nano.dts | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-nano.dts
b/arch/arm/boot/dts/am335x-nano.dts
index a346645..5ed4ca6 100644
--- a/arch/arm/boot/dts/am335x-nano.dts
+++ b/arch/arm/boot/dts/am335x-nano.dts
@@ -213,7 +213,9 @@
pinctrl-0 = i2c0_pins;
gpio@20 {
- compatible = mcp,mcp23017;
+ compatible = microchip,mcp23017;
+ gpio-controller;
+ #gpio-cells = 2;
reg = 0x20;
};
@@ -222,7 +224,7 @@
};
eeprom@53 {
- compatible = mcp,24c02;
+ compatible = microchip,24c02;
reg = 0x53;
pagesize = 8;
};
@@ -297,8 +299,8 @@
||--0x004F- Kernel end
||--0x0050- File system start
||
- ||--0x014F- File system end
- ||--0x0150- User data start
+ ||--0x01FF- File system end
+ ||--0x0200- User data start
||
||--0x03FF- User data end
||--0x0400- Data storage start
@@ -327,12 +329,12 @@
partition@4 {
label = rootfs;
- reg = 0x0050 0x0100; /* 16MB */
+ reg = 0x0050 0x01b0; /* 27MB */
};
partition@5 {
label = user;
- reg = 0x0150 0x02b0; /* 43MB */
+ reg = 0x0200 0x0200; /* 32MB */
};
partition@6 {
@@ -343,7 +345,7 @@
};
mac {
- dual_emac = 1;
+ dual_emac;
status = okay;
};
@@ -353,11 +355,13 @@
cpsw_emac0 {
phy_id = davinci_mdio, 0;
+ phy-mode = mii;
dual_emac_res_vlan = 1;
};
cpsw_emac1 {
phy_id = davinci_mdio, 1;
+ phy-mode = mii;
dual_emac_res_vlan = 2;
};
--
1.9.1
--
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: [RFC][PATCH 2/9] usb: gadget: add usb_gadget_start/stop()
On 19/03/15 16:09, Li Jun wrote: On Thu, Mar 19, 2015 at 12:14:39PM +0200, Roger Quadros wrote: On 19/03/15 05:30, Peter Chen wrote: On Wed, Mar 18, 2015 at 03:55:56PM +0200, Roger Quadros wrote: The OTG state machine needs a mechanism to start and stop the gadget controller. Add usb_gadget_start() and usb_gadget_stop(). Signed-off-by: Roger Quadros rog...@ti.com --- drivers/usb/gadget/udc/udc-core.c | 166 +++--- include/linux/usb/gadget.h| 3 + 2 files changed, 158 insertions(+), 11 deletions(-) diff --git a/drivers/usb/gadget/udc/udc-core.c b/drivers/usb/gadget/udc/udc-core.c index 5a81cb0..69b4123 100644 --- a/drivers/usb/gadget/udc/udc-core.c +++ b/drivers/usb/gadget/udc/udc-core.c @@ -35,6 +35,8 @@ * @dev - the child device to the actual controller * @gadget - the gadget. For use by the class code * @list - for use by the udc class driver + * @running - udc is running Doesn't OTG FSM should know it? Not really, as the gadget driver might not have been loaded yet or userspace might have disabled softconnect when the OTG FSM wants UDC to start. So only UDC knows if it has really started or not based on this flag. why this can not be known by check the otg fsm state? i.e. if the device in b_peripheral or a_peripheral state, udc should had started, isn't it? If gadget function driver (which is different from UDC driver) is not yet loaded then we can't start UDC even if otg fsm is in b_peripheral. Also, if userspace has disabled softconnect we can't start UDC. So, b_peripheral != UDC_started. I've tried to address this issue by adding the checks in usb_gadget_start(). 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 2/2] ARM: dts: dra7: remove ti,hwmod property from pcie phy
On Wed, 18 Mar 2015, grygorii.stras...@linaro.org wrote: On 03/18/2015 06:57 PM, Tony Lindgren wrote: * Grygorii Strashko grygorii.stras...@ti.com [150318 09:37]: As I can see Patch 1 from this series was merged in 4.0-rc4, but this patch wasn't. As result, I can see below warning all the time during boot now: [0.594591] platform 4a094000.pciephy: Cannot lookup hwmod 'pcie1-phy' OK. Is this needed as a fix for the v4.0-rc series, or can this wait for v4.1? I think, Yes. These two patches should go all together, because they are interrelated. Does the warning result in a functional problem, or is it just a warning? - 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 to parameterize DMA_MIN_BYTES for omap2-mcspi
On Thu, Mar 19, 2015 at 01:28:00PM -0400, Greg Knight wrote: Changing DMA_MIN_BYTES to, say, dma_min_time_ms sounds reasonable to me. I don't know how to compute it completely accurately as some SPI You probably need both - there's often a hard limit where the FIFO size in the hardware becomes a limit for DMA as well as a soft limit on top of that for performance reasons. implementations I've seen seem to like to inject little delays between bytes for some reason, but a reasonable enough estimate should just be spi_transfer_time_ms = (bits * 1000) / spi_clock_speed. I would like to have the ability to configure it without a kernel recompile, though. Would a kernel param (module_param) be acceptable for this application? Exposing it as a sysfs or debugfs file might make more sense if you were going to do this. Is that required after merge though? It seems like this is something where we've perhaps been tuning the wrong parameter (transfer size instead of runtime), or need to investigate dynamic tuning. signature.asc Description: Digital signature
Re: omap voltage management
* Ran Shalit ransha...@gmail.com [150319 13:05]: Hello, I am using DM8148 and I get error message in boot that voltage management driver is not added. Is it supported in DM8148. If not - why ? We currently are missing dm8148 support from mainline, dm8168 does have basic support now. Adding dm8148 will hopefully happen too with time permitting :) 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 for v4.0-rc cycle
The following changes since commit 5b7610f235627878617648a99dd1442997f1c889: ARM: OMAP2+: Fix wl12xx on dm3730-evm with mainline u-boot (2015-03-06 10:37:34 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/fixes-v4.0-rc4 for you to fetch changes up to 599c376c49323127c9bdbb0fa61a3d4743819bc2: ARM: dts: Fix gpio interrupts for dm816x (2015-03-18 13:41:34 -0700) Fixes for omaps for the -rc cycle: - Fix a device tree based booting vs legacy booting regression for omap3 crypto hardware by adding the missing DMA channels. - Fix /sys/bus/soc/devices/soc0/family for am33xx devices. - Fix two timer issues that can cause hangs if the timer related hwmod data is missing like it often initially is for new SoCs. - Remove pcie hwmods entry from dts as that causes runtime PM to fail for the PHYs. - A paper bag type dts configuration fix for dm816x GPIO interrupts that I just noticed. This is most of the changes diffstat wise, but as it's a basic feature for connecting devices and things work otherwise, it should be fixed. Kishon Vijay Abraham I (1): ARM: dts: dra7: remove ti,hwmod property from pcie phy Pali Rohár (1): ARM: dts: omap3: Add missing dmas for crypto Suman Anna (3): ARM: OMAP2+: Fix socbus family info for AM33xx devices ARM: OMAP: dmtimer: check for pm_runtime_get_sync() failure ARM: OMAP: dmtimer: disable pm runtime on remove Tony Lindgren (1): ARM: dts: Fix gpio interrupts for dm816x arch/arm/boot/dts/dm8168-evm.dts | 19 +++ arch/arm/boot/dts/dm816x.dtsi| 18 ++ arch/arm/boot/dts/dra7.dtsi | 2 -- arch/arm/boot/dts/omap3.dtsi | 4 arch/arm/mach-omap2/id.c | 2 ++ arch/arm/plat-omap/dmtimer.c | 15 ++- 6 files changed, 53 insertions(+), 7 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: [PATCHv4 30/35] ARM: dts: omap4: add system control module node
* Tony Lindgren t...@atomide.com [150318 14:35]:
* Tero Kristo t-kri...@ti.com [150318 07:45]:
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -167,36 +167,65 @@
+ scm: scm@4a002000 {
+ compatible = ti,omap4-ctrl, simple-bus;
+ reg = 0x4a002000 0x1000,
+ 0x4a10 0x1000;
+ #address-cells = 2;
+ #size-cells = 1;
+ ranges = 0 0 0x4a002000 0x1000,
+1 0 0x4a10 0x1000;
Oops I still have a bit of an issue with this, sorry I should have
been more clear last time.
Now it's hard to figure out which children belong to l4_cfg and which
ones to l4_wkup. I suggest we set them up as completely separate blocks
as that's what they are.
Below is an example of what I think things should look like for omap4,
maybe take a look at that and see if that makes sense for you?
It may need to be patched in separate parts to keep the patches readable
though :)
The example I posted has some l4_cfg vs SCM confusion as pointed out by
Tero while we chatted about it. Also l4_wkup is a child of l4_cfg on
omap4, while on omap5 they are separate.
Below are some examples of what we came up with that now follows omap4460
TRM Figure 2-1. Interconnect Overview and Table 2-3. L4_CFG Memory
Space Mapping. Also an example for omap3 is included.
Tero, maybe just do the minimal changes for now as we don't need to move
all of it at once?
Regards,
Tony
Example for omap4.dtsi, which ocp being the l3 interconnect:
ocp {
compatible = ti,omap4-l3-noc, simple-bus;
#address-cells = 1;
#size-cells = 1;
ranges;
ti,hwmods = l3_main_1, l3_main_2, l3_main_3;
reg = 0x4400 0x1000,
0x4480 0x2000,
0x4500 0x1000;
interrupts = GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH,
GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH;
l4_cfg: l4@4a00 {
compatible = ti,omap4-l4-cfg, simple-bus;
#address-cells = 1;
#size-cells = 1;
ranges = 0 0x4a00 0x100;
cm1: cm1@4000 {
compatible = ti,omap4-cm1;
reg = 0x4000 0x2000;
cm1_clocks: clocks {
#address-cells = 1;
#size-cells = 0;
};
cm1_clockdomains: clockdomains {
};
};
cm2: cm2@8000 {
compatible = ti,omap4-cm2;
reg = 0x8000 0x3000;
cm2_clocks: clocks {
#address-cells = 1;
#size-cells = 0;
};
cm2_clockdomains: clockdomains {
};
};
omap4_scm_core: scm@10 {
compatible = ti,omap4-scm-core, simple-bus;
#address-cells = 1;
#size-cells = 1;
ranges = 0 0x10 0x1000;
omap4_pmx_core: pinmux@40 {
compatible = ti,omap4-padconf,
pinctrl-single;
reg = 0x40 0x0196;
#address-cells = 1;
#size-cells = 0;
#interrupt-cells = 1;
interrupt-controller;
pinctrl-single,register-width = 16;
pinctrl-single,function-mask = 0x7fff;
};
omap4_padconf_global: tisyscon@5a0 {
compatible = syscon;
reg = 0x5a0 0x170;
#address-cells = 1;
#size-cells = 1;
pbias_regulator: pbias_regulator {
compatible = ti,pbias-omap;
reg = 0x60 0x4;
syscon =
omap4_padconf_global;
pbias_mmc_reg: pbias_mmc_omap4 {
regulator-name =
Re: [PATCH v7 5/6] ARM: dts: add wl12xx/wl18xx bindings
* Eliad Peller el...@wizery.com [150319 07:43]: hi Pontus, On Thu, Mar 19, 2015 at 4:05 PM, Pontus Fuchs pontus.fu...@gmail.com wrote: On 2015-03-18 17:38, Eliad Peller wrote: Replace all the pdata-quirks for setting wl12xx/wl18xx platform data with proper DT definitions. Signed-off-by: Eliad Peller el...@wizery.com Acked-by: Javier Martinez Canillas jav...@dowhile0.org Acked-by: Enric Balletbo i Serra eballe...@gmail.com Tested-by: Tony Lindgren t...@atomide.com --- v7: rebase arch/arm/boot/dts/am335x-evmsk.dts | 11 arch/arm/boot/dts/omap3-cm-t3517.dts | 10 arch/arm/boot/dts/omap3-cm-t3730.dts | 10 arch/arm/boot/dts/omap3-evm-common.dtsi| 10 arch/arm/boot/dts/omap3-igep0020-rev-f.dts | 9 arch/arm/boot/dts/omap3-igep0030-rev-g.dts | 9 arch/arm/boot/dts/omap3-zoom3.dts | 10 arch/arm/boot/dts/omap4-panda-common.dtsi | 10 Hi Eliad, Tested OK (boot, scan, join, ping) on Pandaboard ES. thanks for testing it! Great. As suggested by Kalle, I'll apply all these into omap-for-v4.1/wl12xx branch and send a pull request for the arm-soc probably on Friday if no issues are found. 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/2] ARM: dts: dra7: remove ti,hwmod property from pcie phy
On 03/19/2015 05:45 PM, Paul Walmsley wrote: On Thu, 19 Mar 2015, grygorii.stras...@linaro.org wrote: On 03/19/2015 04:55 PM, Paul Walmsley wrote: On Wed, 18 Mar 2015, grygorii.stras...@linaro.org wrote: On 03/18/2015 06:57 PM, Tony Lindgren wrote: * Grygorii Strashko grygorii.stras...@ti.com [150318 09:37]: As I can see Patch 1 from this series was merged in 4.0-rc4, but this patch wasn't. As result, I can see below warning all the time during boot now: [0.594591] platform 4a094000.pciephy: Cannot lookup hwmod 'pcie1-phy' OK. Is this needed as a fix for the v4.0-rc series, or can this wait for v4.1? I think, Yes. These two patches should go all together, because they are interrelated. Does the warning result in a functional problem, or is it just a warning? PCE1 PHY device is not registered any more. How does the second patch fix that? I've re-checked it - sorry for disinfo. PHY devices are created, but omap_device_fail_pm_domain is assigned to them. As result Runtime PM is not working any more. [0.592501] platform 4a094000.pciephy: Cannot lookup hwmod 'pcie1-phy' [0.597510] pinctrl-single 4a003400.pinmux: 281 pins at pa fc003400 size 1124 [0.602794] ti-pipe3 4a094000.pciephy: _od_fail_runtime_resume: FIXME: missing hwmod/omap_dev info When ti,hwmods is not present PCI PHY will be added as regular Platform device and Runtime PM will work again. -- regards, -grygorii -- 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 to parameterize DMA_MIN_BYTES for omap2-mcspi
On 03/19/2015 03:16 PM, Greg Knight wrote: Will refer to that documentation and update the SPI docs before resubmitting. Re; Threshold of 160 is artificial: Believe me, I am more than aware of this. SPI runs in any speed from low kHz to multi MHz. The only reason I can fathom for having such a high DMA_MIN_BYTES is to facilitate high-speed low-volume communication (eg read one byte at a time from userspace without buffering.) The reason I'm looking at this at all is because we're doing low-speed low-volume communication, for which the burn in PIO mode causes severe performance degradation. Internally we'd changed it to 20, but I might try 8. I originally tried 0, but observed poor behavior for our use cases. DMA_MIN_BYTES at 8 would be sensible for our application, but at 160 it is not. How about moving the speed to the spidev DT nodes? The issue is that: The device tree is a data structure for describing hardware DMA_MIN_BYTES is a software parameter. To be specific, it is Linux software parameter applicable only to spi-omap2-mcspi.c driver. I think the best thing we could do is to calculate the DMA_MIN_BYTES in the driver based on the SPI speed. Something which will give ~160 in the speed in which the wl driver is used and something which works best in your setup in the speed you are using the SPI bus. The best way is to give some msec as a limit. If the transfer would take more then X msec on the bus to be transferred, we will use DMA, if it is less than that we fall back to PIO. Yes, the CPU speed is not taken into account, but IMHO the bus speed is more important. What do you think? Will this work for you? -- Péter -- 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] phy: Add a driver for dm816x USB PHY
* Matthijs van Duin matthijsvand...@gmail.com [150319 04:20]: On 17 March 2015 at 03:19, Tony Lindgren t...@atomide.com wrote: Yes so it seem here too, this is dm816x rev c, what do you have? jtag ID reads 0x1b81e02f, so that would be rev 1.1 / rev A. Anyways, I'll add a note that at least rev c does not seems to do anything with USB_CTRL but that we follow what the TI tree is doing in case some other revisions of the hardware use it. Another idea would be to check if it's nonzero and if so, yell loudly in the kernel log that they should mail the linux-omap list ;-) Sure I'll add that to the phy start up code :) 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: Patches to bind the SGTL5000 chip to AM33XX McASP
On 03/19/2015 04:34 PM, Greg Knight wrote: SO is it so that the codec's MCLK is coming from McASP AHCLKX (or R) and this clock need to be present all the time? W/o the MCLK the registers are not accessible? Correct, the SGTL5000's I2C registers are not accessible without MCLK. Yeah, according to the datasheet, it needs MCLK in order to communicate with it. From my testing, the clock need only be present when the audio chip is in use. When not in use, the chip appears perfectly happy to not be clocked. If you change audio controls while you don't have audio activity, you will still need to have the MCLK running. Is there a better place to pull a ~12MHz clock signal for use as a master clock from an AM335X? For a codec such as the SGTL5000 I would connect a clock, which is running all the time. If you take a look at the driver, it enables the clock at probe and leaves it running as long as the driver is loaded. But AM335x has CLKOUT1,2 outputs as well. They are not high quality clocks, but can be enabled/disabled. This will not work in mainline kernel. The McASP is turned off when it is not in use (no audio activity) so the AHCLKX/R is not going to be there on the ball output. The clock-to-talk hack in the patch enables the AHCLKX line during codec initialization. From my testing, we don't seem to spend much time communicating with the device when we're not using it. Disabling the clock when it's not used should not be a problem. As I said, this is not going to work in upstream kernel. The McASP is not even powered up during probe time anymore. It is only powered up when it is needed, this means that you will not have clocks for the codec coming from McASP pin. The driver is not designed to support such a use case, when you use one of it's clock as a master clock for external chip. In other words the McASP driver is not a clock driver. It might be possible to create a clock driver on top of the McASP driver as child, but it is really something which should not be supported. How do you configure the frequency of the AHCLKX/R, this hack only enables it, so you are going to have _some_ clock going out. The frequency is the 12 MHz (I think) I get out from AHCLKX without any further configuration; I have not investigated changing that frequency as it suited my needs. But I can look into doing set_clkdiv/set_sysclk during the clock-to-talk enable if that's more appropriate? You should be using set_clkdiv and set_sysclk calls from the machine driver to configure the AHCLKX (we do not have AHCLKR supported in the driver ATM). So, ehm, the SGTL5000 component logic (is this the machine driver?) should adjust the McASP's clocks? Am I misunderstanding? Would this not impact binding the SGTL5000 to devices that are *not* McASPs/break abstraction? TBH I'm not clear on how the SGTL5000 bindings to other hardware work. It works in other HW because the designers connected the SGTL5000's MCLK to a clock source which can be controlled or it is running all the time. In your case the designers chosen a clock line, which is not working as 'normal' clock. Is it safe to assume set_sysclk is always going to adjust the I2S MCLK speed? Please pardon my crude questions, I'm not deeply familiar with the structure of ALSA. With the setclkdiv/sysclk you can configure the AHCLKX direction and configure the divider to be used to generate the clock which goes out, or to divide down the clock which is coming in. Another issue this hack has is: what happens if for some reason the SGTL5000 driver loads first? McASP will not enable the AHCLKX so the codec driver will fail reading the CHIP_ID and fails to load. You need to provide a dummy clock node to the codec, so that will not fail, but you will not have the MCLK. I'll reformat the patches and try from a mainline kernel when I get some spare time. I'm not sure if this can be accepted, sorry. It is really a hack and there are too many corner cases where the system can fail. -- Péter -- 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: dts: dra7: remove ti,hwmod property from pcie phy
* Paul Walmsley p...@pwsan.com [150319 08:46]: On Thu, 19 Mar 2015, grygorii.stras...@linaro.org wrote: On 03/19/2015 04:55 PM, Paul Walmsley wrote: On Wed, 18 Mar 2015, grygorii.stras...@linaro.org wrote: On 03/18/2015 06:57 PM, Tony Lindgren wrote: * Grygorii Strashko grygorii.stras...@ti.com [150318 09:37]: As I can see Patch 1 from this series was merged in 4.0-rc4, but this patch wasn't. As result, I can see below warning all the time during boot now: [0.594591] platform 4a094000.pciephy: Cannot lookup hwmod 'pcie1-phy' OK. Is this needed as a fix for the v4.0-rc series, or can this wait for v4.1? I think, Yes. These two patches should go all together, because they are interrelated. Does the warning result in a functional problem, or is it just a warning? PCE1 PHY device is not registered any more. How does the second patch fix that? It seems it should be just a warning fix if the pciephy hwmod entries are now gone? Anyways, I'm planning to send a pull request for omap-for-v4.0/fixes today. Please let me know ASAP if the $subject patch should be dropped, otherwise I'll send it as it fixes a boot time warning and is already applied. 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/2] ARM: dts: dra7: remove ti,hwmod property from pcie phy
On 03/19/2015 04:55 PM, Paul Walmsley wrote: On Wed, 18 Mar 2015, grygorii.stras...@linaro.org wrote: On 03/18/2015 06:57 PM, Tony Lindgren wrote: * Grygorii Strashko grygorii.stras...@ti.com [150318 09:37]: As I can see Patch 1 from this series was merged in 4.0-rc4, but this patch wasn't. As result, I can see below warning all the time during boot now: [0.594591] platform 4a094000.pciephy: Cannot lookup hwmod 'pcie1-phy' OK. Is this needed as a fix for the v4.0-rc series, or can this wait for v4.1? I think, Yes. These two patches should go all together, because they are interrelated. Does the warning result in a functional problem, or is it just a warning? PCE1 PHY device is not registered any more. -- regards, -grygorii -- 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] ASoC: davinci-mcasp: Set rule constraints if implicit BCLK divider is used
Please don't take this yet. The SNDRV_PCM_HW_PARAM_SAMPLE_BITS rule does
not appear to work as it should. I'll mail a new patch with a mask based
constraints for sample formats shortly.
Best regards,
Jyri
On 03/19/15 15:11, Jyri Sarha wrote:
Set rule constraints to allow only combinations of sample-rate,
sample-bits, and channels that can be played/captured with reasonable
sample-rate accuracy.
The logic with tdm-slots and serializers (=i2s data wires) goes like
this: The first wire will take all channels up to number of tdm-slots,
before following wires (if any) are used. If the first wire is used
fully, the remaining wires share the same clocks and the divider can
be calculated for the first wire.
Also, takes the number of tdm-slots into account when implicitly
selecting the BLCK divider.
Signed-off-by: Jyri Sarha jsa...@ti.com
Acked-by: Peter Ujfalusi peter.ujfal...@ti.com
---
This is othetwise the same patch as v2, but I added Peter's ack and
rebased on top of:
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git topic/davinci
sound/soc/davinci/davinci-mcasp.c | 195 --
1 file changed, 185 insertions(+), 10 deletions(-)
diff --git a/sound/soc/davinci/davinci-mcasp.c
b/sound/soc/davinci/davinci-mcasp.c
index d40b392..625cca1 100644
--- a/sound/soc/davinci/davinci-mcasp.c
+++ b/sound/soc/davinci/davinci-mcasp.c
@@ -27,6 +27,7 @@
#include linux/of_platform.h
#include linux/of_device.h
#include linux/platform_data/davinci_asp.h
+#include linux/math64.h
#include sound/asoundef.h
#include sound/core.h
@@ -65,6 +66,11 @@ struct davinci_mcasp_context {
boolpm_state;
};
+struct davinci_mcasp_ruledata {
+ struct davinci_mcasp *mcasp;
+ int serializers;
+};
+
struct davinci_mcasp {
struct snd_dmaengine_dai_dma_data dma_data[2];
void __iomem *base;
@@ -99,6 +105,8 @@ struct davinci_mcasp {
#ifdef CONFIG_PM_SLEEP
struct davinci_mcasp_context context;
#endif
+
+ struct davinci_mcasp_ruledata ruledata[2];
};
static inline void mcasp_set_bits(struct davinci_mcasp *mcasp, u32 offset,
@@ -868,6 +876,30 @@ static int mcasp_dit_hw_param(struct davinci_mcasp *mcasp,
return 0;
}
+static int davinci_mcasp_calc_clk_div(struct davinci_mcasp *mcasp,
+ unsigned int bclk_freq,
+ int *error_ppm)
+{
+ int div = mcasp-sysclk_freq / bclk_freq;
+ int rem = mcasp-sysclk_freq % bclk_freq;
+
+ if (rem != 0) {
+ if (div == 0 ||
+ ((mcasp-sysclk_freq / div) - bclk_freq)
+ (bclk_freq - (mcasp-sysclk_freq / (div+1 {
+ div++;
+ rem = rem - bclk_freq;
+ }
+ }
+ if (error_ppm)
+ *error_ppm =
+ (div*100 + (int)div64_long(100LL*rem,
+ (int)bclk_freq))
+ /div - 100;
+
+ return div;
+}
+
static int davinci_mcasp_hw_params(struct snd_pcm_substream *substream,
struct snd_pcm_hw_params *params,
struct snd_soc_dai *cpu_dai)
@@ -883,16 +915,20 @@ static int davinci_mcasp_hw_params(struct
snd_pcm_substream *substream,
* the machine driver, we need to calculate the ratio.
*/
if (mcasp-bclk_master mcasp-bclk_div == 0 mcasp-sysclk_freq) {
- unsigned int bclk_freq = snd_soc_params_to_bclk(params);
- unsigned int div = mcasp-sysclk_freq / bclk_freq;
- if (mcasp-sysclk_freq % bclk_freq != 0) {
- if (((mcasp-sysclk_freq / div) - bclk_freq)
- (bclk_freq - (mcasp-sysclk_freq / (div+1
- div++;
- dev_warn(mcasp-dev,
-Inaccurate BCLK: %u Hz / %u != %u Hz\n,
-mcasp-sysclk_freq, div, bclk_freq);
- }
+ int channels = params_channels(params);
+ int rate = params_rate(params);
+ int sbits = params_width(params);
+ int ppm, div;
+
+ if (channels mcasp-tdm_slots)
+ channels = mcasp-tdm_slots;
+
+ div = davinci_mcasp_calc_clk_div(mcasp, rate*sbits*channels,
+ppm);
+ if (ppm)
+ dev_info(mcasp-dev, Sample-rate is off by %d PPM\n,
+ppm);
+
__davinci_mcasp_set_clkdiv(cpu_dai, 1, div, 0);
}
@@ -974,6 +1010,108 @@ static int davinci_mcasp_trigger(struct
snd_pcm_substream *substream,
return ret;
}
+static const unsigned int davinci_mcasp_dai_rates[] = {
+ 8000, 11025, 16000, 22050, 32000, 44100, 48000,
Re: [PATCHv4 00/35] ARM: OMAP2+: PRCM / SCM cleanups against 4.0-rc1
* Tero Kristo t-kri...@ti.com [150319 00:48]:
On 03/19/2015 12:07 AM, Tony Lindgren wrote:
But for dm8168-evm, it fails early on, see below.
Yea seems I forgot to add dm81x support properly. Try this diff:
diff --git a/arch/arm/mach-omap2/cm_common.c
b/arch/arm/mach-omap2/cm_common.c
index 2582651..23559aa 100644
--- a/arch/arm/mach-omap2/cm_common.c
+++ b/arch/arm/mach-omap2/cm_common.c
@@ -271,6 +271,8 @@ static const struct of_device_id
omap_cm_dt_match_table[] __initconst = {
{ .compatible = ti,dra7-cm-core, .data = cm2_data },
{ .compatible = ti,am3-prcm, .data = am3_prcm_data },
{ .compatible = ti,am4-prcm, .data = am4_prcm_data },
+ { .compatible = ti,dm814-prcm, .data = am3_prcm_data },
+ { .compatible = ti,dm816-prcm, .data = am3_prcm_data },
{ }
};
Boots a bit further now with that, but then produces:
...
[0.278020] omap_hwmod: tptc0 using broken dt data from edma
[0.284133] omap_hwmod: tptc1 using broken dt data from edma
[0.290207] omap_hwmod: tptc2 using broken dt data from edma
[0.296307] omap_hwmod: tptc3 using broken dt data from edma
[0.305359] clocksource jiffies: mask: 0x max_cycles: 0x,
max_idle_ns: 1911260446275 ns
[0.317206] pinctrl core: initialized pinctrl subsystem
[0.339667] NET: Registered protocol family 16
[0.349174] DMA: preallocated 256 KiB pool for atomic coherent allocations
[0.358130] cpuidle: using governor ladder
[0.362433] cpuidle: using governor menu
[0.366948] Unable to handle kernel NULL pointer dereference at virtual
address 0040
[0.375364] pgd = c0004000
[0.378223] [0040] *pgd=
[0.381983] Internal error: Oops: 5 [#1] SMP ARM
[0.386803] Modules linked in:
[0.390026] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
4.0.0-rc4-next-20150318-00040-gc5b9bf4-dirty #305
[0.399743] Hardware name: Generic ti816x (Flattened Device Tree)
[0.406078] task: ed894b80 ti: ed896000 task.ti: ed896000
[0.411704] PC is at omap_ctrl_readl+0x48/0x58
[0.416347] LR is at omap_type.part.0+0x7c/0xd8
[0.421078] pc : [c0023d60]lr : [c0023bd4]psr: 6113
[0.421078] sp : ed897eb0 ip : fp : c089f574
[0.433022] r10: c0850598 r9 : c089f588 r8 :
[0.438466] r7 : c08537ac r6 : ed902c00 r5 : r4 : c094f03c
[0.445246] r3 : 0040 r2 : c094ebcc r1 : r0 : 0040
[0.452025] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment
kernel
[0.459605] Control: 10c5387d Table: 80004019 DAC: 0015
[0.465581] Process swapper/0 (pid: 1, stack limit = 0xed896218)
[0.471825] Stack: (0xed897eb0 to 0xed898000)
[0.476379] 7ea0: c08c4540 c085ea18
c089df40
[0.484854] 7ec0: ed902c00 c08537ac c085a208 c089df40 c08a6500
c08b04c4 c0862fdc
[0.493327] 7ee0: c089df40 c08c1e30 c08c1e30 c0862c78 c089df40 c08537c8
c0008b84
[0.501801] 7f00: ed894b80 c08fc494 ed894b80 ed895100 0004
0006
[0.510278] 7f20: c008a2bc c0850598 ef7fc9d0 ef7fc9cb c005c784
c076c0a0 ef7fc9da
[0.518753] 7f40: 0003 0003 c08b5f18 c08b5f20 0003
c094e780 0093
[0.527226] 7f60: c094e780 c0850598 c089f574 c0850ea0 0003 0003
c0850598
[0.535699] 7f80: c05d2ca8
[0.544174] 7fa0: c05d2cb0 c000e910
[0.552649] 7fc0:
[0.561122] 7fe0: 0013
[0.569598] [c0023d60] (omap_ctrl_readl) from [] ( (null))
[0.576471] Code: e28dd00c e49df004 e5921000 e0813003 (e593)
[0.582860] ---[ end trace 00a172dd2625b740 ]---
[0.587757] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x000b
[0.587757]
[0.597310] ---[ end Kernel panic - not syncing: Attempted to kill init!
exitcode=0x000b
[0.597310]
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/2] ARM: dts: dra7: remove ti,hwmod property from pcie phy
On Thu, 19 Mar 2015, grygorii.stras...@linaro.org wrote: On 03/19/2015 04:55 PM, Paul Walmsley wrote: On Wed, 18 Mar 2015, grygorii.stras...@linaro.org wrote: On 03/18/2015 06:57 PM, Tony Lindgren wrote: * Grygorii Strashko grygorii.stras...@ti.com [150318 09:37]: As I can see Patch 1 from this series was merged in 4.0-rc4, but this patch wasn't. As result, I can see below warning all the time during boot now: [0.594591] platform 4a094000.pciephy: Cannot lookup hwmod 'pcie1-phy' OK. Is this needed as a fix for the v4.0-rc series, or can this wait for v4.1? I think, Yes. These two patches should go all together, because they are interrelated. Does the warning result in a functional problem, or is it just a warning? PCE1 PHY device is not registered any more. How does the second patch fix 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] usb: musb: Fix fifo reads for dm816x with musb_dsps
* Sergei Shtylyov sergei.shtyl...@cogentembedded.com [150319 06:30]:
On 3/19/2015 1:48 AM, Tony Lindgren wrote:
Looks like dm81xx can only do 32-bit fifo reads like am35x. Let's set
up musb-dsps with a custom read_fifo function based on the compatible
flag.
...
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
+/* Similar to am35x, dm81xx support only 32-bit read operation */
+static void dsps_read_fifo32(struct musb_hw_ep *hw_ep, u16 len, u8 *dst)
+{
+void __iomem *fifo = hw_ep-fifo;
+u32 val;
+int i;
+
+/* Read for 32bit-aligned destination address */
+if (likely((0x03 (unsigned long)dst) == 0) len = 4) {
+readsl(fifo, dst, len 2);
+dst += len ~0x03;
+len = 0x03;
+}
+/*
+ * Now read the remaining 1 to 3 byte or complete length if
+ * unaligned address.
+ */
This comment seems misplaced, it belongs before the next *if*.
+if (len 4) {
+for (i = 0; i (len 2); i++) {
+*(u32 *)dst = musb_readl(fifo, 0);
+dst += 4;
+}
Not sure how this is different to using readsl().
+len = 0x03;
+}
+if (len 0) {
+val = musb_readl(fifo, 0);
+memcpy(dst, val, len);
+}
+}
Indeed, thanks for looking at it. That function in the TI kernel probably
had something else for the 32-bit aligned case that got swapped to use
readsl().
Looks like the following works just fine for me with a USB Ethernet
and variable size ping test:
static void dsps_read_fifo32(struct musb_hw_ep *hw_ep, u16 len, u8 *dst)
{
void __iomem *fifo = hw_ep-fifo;
if (len = 4) {
readsl(fifo, dst, len 2);
dst += len ~0x03;
len = 0x03;
}
/* Read any remaining 1 to 3 bytes */
if (len 0) {
u32 val = musb_readl(fifo, 0);
memcpy(dst, val, len);
}
}
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/2] ARM: dts: dra7: remove ti,hwmod property from pcie phy
On Thu, 19 Mar 2015, Tony Lindgren wrote: * Paul Walmsley p...@pwsan.com [150319 08:46]: On Thu, 19 Mar 2015, grygorii.stras...@linaro.org wrote: On 03/19/2015 04:55 PM, Paul Walmsley wrote: On Wed, 18 Mar 2015, grygorii.stras...@linaro.org wrote: On 03/18/2015 06:57 PM, Tony Lindgren wrote: * Grygorii Strashko grygorii.stras...@ti.com [150318 09:37]: As I can see Patch 1 from this series was merged in 4.0-rc4, but this patch wasn't. As result, I can see below warning all the time during boot now: [0.594591] platform 4a094000.pciephy: Cannot lookup hwmod 'pcie1-phy' OK. Is this needed as a fix for the v4.0-rc series, or can this wait for v4.1? I think, Yes. These two patches should go all together, because they are interrelated. Does the warning result in a functional problem, or is it just a warning? PCE1 PHY device is not registered any more. How does the second patch fix that? It seems it should be just a warning fix if the pciephy hwmod entries are now gone? Anyways, I'm planning to send a pull request for omap-for-v4.0/fixes today. Please let me know ASAP if the $subject patch should be dropped, otherwise I'll send it as it fixes a boot time warning and is already applied. If you want to send it up as a fix, that's fine with me. But I don't see how that second patch will cause any changes in device registration, as stated. - 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 07/10] ARM: dts: n9/n950: Enable omap crypto support
* Pavel Machek pa...@ucw.cz [150228 08:45]: On Thu 2015-02-26 14:49:57, Pali Rohár wrote: Harmattan system on Nokia N9 and N950 devices uses omap crypto support. Bootloader on those devices is known that it enables HW crypto support. This patch just include omap36xx.dtsi directly, so aes and sham is enabled. Signed-off-by: Pali Rohár pali.ro...@gmail.com Acked-by: Pavel Machek pa...@ucw.cz I'm picking patches 7 - 10 into omap-for-v4.1/dt branch thanks. 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/2] ARM: dts: dra7: remove ti,hwmod property from pcie phy
On Thu, 19 Mar 2015, grygorii.stras...@linaro.org wrote: On 03/19/2015 05:45 PM, Paul Walmsley wrote: On Thu, 19 Mar 2015, grygorii.stras...@linaro.org wrote: On 03/19/2015 04:55 PM, Paul Walmsley wrote: On Wed, 18 Mar 2015, grygorii.stras...@linaro.org wrote: On 03/18/2015 06:57 PM, Tony Lindgren wrote: * Grygorii Strashko grygorii.stras...@ti.com [150318 09:37]: As I can see Patch 1 from this series was merged in 4.0-rc4, but this patch wasn't. As result, I can see below warning all the time during boot now: [0.594591] platform 4a094000.pciephy: Cannot lookup hwmod 'pcie1-phy' OK. Is this needed as a fix for the v4.0-rc series, or can this wait for v4.1? I think, Yes. These two patches should go all together, because they are interrelated. Does the warning result in a functional problem, or is it just a warning? PCE1 PHY device is not registered any more. How does the second patch fix that? I've re-checked it - sorry for disinfo. PHY devices are created, but omap_device_fail_pm_domain is assigned to them. As result Runtime PM is not working any more. [0.592501] platform 4a094000.pciephy: Cannot lookup hwmod 'pcie1-phy' [0.597510] pinctrl-single 4a003400.pinmux: 281 pins at pa fc003400 size 1124 [0.602794] ti-pipe3 4a094000.pciephy: _od_fail_runtime_resume: FIXME: missing hwmod/omap_dev info When ti,hwmods is not present PCI PHY will be added as regular Platform device and Runtime PM will work again. OK then it should definitely go up as a fix. Kishon, for future references, those two patches should have been combined into a single patch. As it stands now, if someone bisects down to that first patch, it sounds like PM will be at least partially broken. Too bad I don't have a DRA7xx board where things like this can be tested before being sent upstream. - 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
