Re: [PATCH 0/6] OMAP2+: GPMC: NAND fixes for 3.17
On 09/04/2014 10:00 PM, pekon wrote: Hi Tony, On Thursday 04 September 2014 03:12 AM, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [140903 14:41]: * Roger Quadros rog...@ti.com [140902 06:57]: Hi Tony, These are some of the issues I found while testing v3.17-rc3. - Wrong ECC scheme used for am43x GP and EPOS evm. We need to use BCH16 instead of BCH8. - Wrong read/write wait pin monitoring setting used for NAND resulting in L3 application error debug message on console. - Pin conflict issue on am43x EPOS evm with QSPI and NAND. Thanks applying into omap-for-v3.17/fixes-v2. Sorry replied to the wrong thread, this series still seems to have some pending comments so not applying this one. Only [Patch 3/6] had some pending comments, but after Roger's clarification there are no further comments from me. So for entire series .. Reviewed-by: Pekon Gupta pe...@pek-sem.com Thanks for the review Pekon. 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] iommu/omap: Fix iommu archdata name for DT-based devices
Hi Suman,
On Thursday 04 September 2014 16:17:53 Suman Anna wrote:
Hi Laurent,
On Wednesday 03 September 2014 18:58:32 Suman Anna wrote:
A device is tied to an iommu through its archdata field. The archdata
is allocated on the fly for DT-based devices automatically through the
.add_device iommu ops. The current logic incorrectly assigned the name
of the IOMMU user device, instead of the name of the IOMMU device as
required by the attach logic. Fix this issue so that DT-based devices
can attach successfully to an IOMMU domain.
Signed-off-by: Suman Anna s-a...@ti.com
---
drivers/iommu/omap-iommu.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index f245d51..f47ac03 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -26,6 +26,7 @@
#include linux/of.h
#include linux/of_iommu.h
#include linux/of_irq.h
+#include linux/of_platform.h
#include asm/cacheflush.h
@@ -1244,6 +1245,7 @@ static int omap_iommu_add_device(struct device
*dev)
{
struct omap_iommu_arch_data *arch_data;
struct device_node *np;
+ struct platform_device *pdev;
/*
* Allocate the archdata iommu structure for DT-based devices.
@@ -1258,13 +1260,19 @@ static int omap_iommu_add_device(struct device
*dev)
if (!np)
return 0;
+ pdev = of_find_device_by_node(np);
+ if (WARN_ON(!pdev)) {
+ of_node_put(np);
+ return -EINVAL;
+ }
I might be wrong, but I don't think there's a guarantee at this point that
the IOMMU device is already instantiated :-/
The omap_iommu_init which registers the iommu_ops is a subsys_initcall,
so the platform devices are guaranteed to be created by this point.
OK, no worries then.
My test on OMAP4 in fact has the dsp node created before the IOMMU node,
and this is not an issue. I have added the WARN_ON in case some one has
the IOMMU node disabled, but try to use it.
Will Deacon has posted patches that rework the IOMMU core for better DT
integration, have you seen them ?
Can you point out the thread? Are you talking about
http://marc.info/?l=linux-arm-kernelm=140968072117851w=2?
Yes that's the one.
--
Regards,
Laurent Pinchart
--
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: [PATCHv2 1/2] iommu/omap: Check for valid archdata in attach_dev
Hi Suman,
Thank you for the patch.
On Thursday 04 September 2014 17:27:29 Suman Anna wrote:
Any device requiring to be attached to an iommu_domain must have
valid archdata containing the necessary iommu information, which
is SoC-specific. Add a check in the omap_iommu_attach_dev to make
sure that the device has valid archdata before accessing
different SoC-specific fields of the archdata. This prevents a
NULL pointer dereference on any misconfigured devices.
Signed-off-by: Suman Anna s-a...@ti.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/iommu/omap-iommu.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 02ef0ac..ea6e59d 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -1090,6 +1090,11 @@ omap_iommu_attach_dev(struct iommu_domain *domain,
struct device *dev) struct omap_iommu_arch_data *arch_data =
dev-archdata.iommu;
int ret = 0;
+ if (!arch_data || !arch_data-name) {
+ dev_err(dev, device doesn't have an associated iommu\n);
+ return -EINVAL;
+ }
+
spin_lock(omap_domain-lock);
/* only a single device is supported per domain for now */
--
Regards,
Laurent Pinchart
--
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: [PATCHv2 2/2] iommu/omap: Fix iommu archdata name for DT-based devices
Hi Suman,
Thank you for the patch.
On Thursday 04 September 2014 17:27:30 Suman Anna wrote:
A device is tied to an iommu through its archdata field. The archdata
is allocated on the fly for DT-based devices automatically through the
.add_device iommu ops. The current logic incorrectly assigned the name
of the IOMMU user device, instead of the name of the IOMMU device as
required by the attach logic. Fix this issue so that DT-based devices
can attach successfully to an IOMMU domain.
Signed-off-by: Suman Anna s-a...@ti.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/iommu/omap-iommu.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index ea6e59d..8cf8bf1 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -26,6 +26,7 @@
#include linux/of.h
#include linux/of_iommu.h
#include linux/of_irq.h
+#include linux/of_platform.h
#include asm/cacheflush.h
@@ -1243,6 +1244,7 @@ static int omap_iommu_add_device(struct device *dev)
{
struct omap_iommu_arch_data *arch_data;
struct device_node *np;
+ struct platform_device *pdev;
/*
* Allocate the archdata iommu structure for DT-based devices.
@@ -1257,13 +1259,19 @@ static int omap_iommu_add_device(struct device *dev)
if (!np)
return 0;
+ pdev = of_find_device_by_node(np);
+ if (WARN_ON(!pdev)) {
+ of_node_put(np);
+ return -EINVAL;
+ }
+
arch_data = kzalloc(sizeof(*arch_data), GFP_KERNEL);
if (!arch_data) {
of_node_put(np);
return -ENOMEM;
}
- arch_data-name = kstrdup(dev_name(dev), GFP_KERNEL);
+ arch_data-name = kstrdup(dev_name(pdev-dev), GFP_KERNEL);
dev-archdata.iommu = arch_data;
of_node_put(np);
--
Regards,
Laurent Pinchart
--
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] ARM: dts: dra7-evm: Fix NAND GPMC timings
The nand timings were scaled down by 2 to account for the 2x rate returned by clk_get_rate(gpmc_fclk). As the clock data got fixed by [1], revert back to actual timings (i.e. scale them up by 2). Without this NAND doesn't work on dra7-evm. [1] - commit dd94324b983afe114ba9e7ee3649313b451f63ce ARM: dts: dra7xx-clocks: Fix the l3 and l4 clock rates Fixes: ff66a3c86e00 (ARM: dts: dra7: add support for parallel NAND flash) Cc: sta...@vger.kernel.org[3.16] Signed-off-by: Roger Quadros rog...@ti.com --- arch/arm/boot/dts/dra7-evm.dts | 27 --- 1 file changed, 12 insertions(+), 15 deletions(-) diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts index 990ee6a..a120d8f 100644 --- a/arch/arm/boot/dts/dra7-evm.dts +++ b/arch/arm/boot/dts/dra7-evm.dts @@ -427,22 +427,19 @@ gpmc,device-width = 2; gpmc,sync-clk-ps = 0; gpmc,cs-on-ns = 0; - gpmc,cs-rd-off-ns = 40; - gpmc,cs-wr-off-ns = 40; + gpmc,cs-rd-off-ns = 80; + gpmc,cs-wr-off-ns = 80; gpmc,adv-on-ns = 0; - gpmc,adv-rd-off-ns = 30; - gpmc,adv-wr-off-ns = 30; - gpmc,we-on-ns = 5; - gpmc,we-off-ns = 25; - gpmc,oe-on-ns = 2; - gpmc,oe-off-ns = 20; - gpmc,access-ns = 20; - gpmc,wr-access-ns = 40; - gpmc,rd-cycle-ns = 40; - gpmc,wr-cycle-ns = 40; - gpmc,wait-pin = 0; - gpmc,wait-on-read; - gpmc,wait-on-write; + gpmc,adv-rd-off-ns = 60; + gpmc,adv-wr-off-ns = 60; + gpmc,we-on-ns = 10; + gpmc,we-off-ns = 50; + gpmc,oe-on-ns = 4; + gpmc,oe-off-ns = 40; + gpmc,access-ns = 40; + gpmc,wr-access-ns = 80; + gpmc,rd-cycle-ns = 80; + gpmc,wr-cycle-ns = 80; gpmc,bus-turnaround-ns = 0; gpmc,cycle2cycle-delay-ns = 0; gpmc,clk-activation-ns = 0; -- 1.8.3.2 -- 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] clk: add gpio gated clock
The added gpio-gate-clock is a basic clock that can be enabled and
disabled trough a gpio output. The DT binding document for the clock
is also added. For EPROBE_DEFER handling the registering of the clock
has to be delayed until of_clk_get() call time.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
This is my final attempt to get this generic gpio controlled basic
clock into mainline. Of course I gladly fix any issues that the patch
may have. However, if there is no response, I give up and move it to TI
specific clocks.
I've been sending this patch as a part of Beaglebone-Black HDMI audio
patch series since last autumn. Since the previous version I have done
some minor cleanups and changed the clock's compatible property from
gpio-clock to gpio-gate-clock. All the file names, comments,
etc. have also been changed accordingly.
Best regards,
Jyri
.../devicetree/bindings/clock/gpio-gate-clock.txt | 21 ++
drivers/clk/Makefile |1 +
drivers/clk/clk-gpio-gate.c| 204
include/linux/clk-provider.h | 22 +++
4 files changed, 248 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/gpio-gate-clock.txt
create mode 100644 drivers/clk/clk-gpio-gate.c
diff --git a/Documentation/devicetree/bindings/clock/gpio-gate-clock.txt
b/Documentation/devicetree/bindings/clock/gpio-gate-clock.txt
new file mode 100644
index 000..d3379ff
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/gpio-gate-clock.txt
@@ -0,0 +1,21 @@
+Binding for simple gpio gated clock.
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : shall be gpio-gate-clock.
+- #clock-cells : from common clock binding; shall be set to 0.
+- enable-gpios : GPIO reference for enabling and disabling the clock.
+
+Optional properties:
+- clocks: Maximum of one parent clock is supported.
+
+Example:
+ clock {
+ compatible = gpio-gate-clock;
+ clocks = parentclk;
+ #clock-cells = 0;
+ enable-gpios = gpio 1 GPIO_ACTIVE_HIGH;
+ };
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index f537a0b..5d78710 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_COMMON_CLK)+= clk-gate.o
obj-$(CONFIG_COMMON_CLK) += clk-mux.o
obj-$(CONFIG_COMMON_CLK) += clk-composite.o
obj-$(CONFIG_COMMON_CLK) += clk-fractional-divider.o
+obj-$(CONFIG_COMMON_CLK) += clk-gpio-gate.o
ifeq ($(CONFIG_OF), y)
obj-$(CONFIG_COMMON_CLK) += clk-conf.o
endif
diff --git a/drivers/clk/clk-gpio-gate.c b/drivers/clk/clk-gpio-gate.c
new file mode 100644
index 000..9dde885
--- /dev/null
+++ b/drivers/clk/clk-gpio-gate.c
@@ -0,0 +1,204 @@
+/*
+ * Copyright (C) 2013 - 2014 Texas Instruments Incorporated - http://www.ti.com
+ * Author: Jyri Sarha jsa...@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.
+ *
+ * Gpio gated clock implementation
+ */
+
+#include linux/clk-provider.h
+#include linux/module.h
+#include linux/slab.h
+#include linux/gpio.h
+#include linux/of_gpio.h
+#include linux/err.h
+#include linux/device.h
+
+/**
+ * DOC: basic gpio gated clock which can be enabled and disabled
+ * with gpio output
+ * Traits of this clock:
+ * prepare - clk_(un)prepare only ensures parent is (un)prepared
+ * enable - clk_enable and clk_disable are functional control gpio
+ * rate - inherits rate from parent. No clk_set_rate support
+ * parent - fixed parent. No clk_set_parent support
+ */
+
+#define to_clk_gpio(_hw) container_of(_hw, struct clk_gpio, hw)
+
+static int clk_gpio_gate_enable(struct clk_hw *hw)
+{
+ struct clk_gpio *clk = to_clk_gpio(hw);
+
+ gpiod_set_value(clk-gpiod, 1);
+
+ return 0;
+}
+
+static void clk_gpio_gate_disable(struct clk_hw *hw)
+{
+ struct clk_gpio *clk = to_clk_gpio(hw);
+
+ gpiod_set_value(clk-gpiod, 0);
+}
+
+static int clk_gpio_gate_is_enabled(struct clk_hw *hw)
+{
+ struct clk_gpio *clk = to_clk_gpio(hw);
+
+ return gpiod_get_value(clk-gpiod);
+}
+
+const struct clk_ops clk_gpio_gate_ops = {
+ .enable = clk_gpio_gate_enable,
+ .disable = clk_gpio_gate_disable,
+ .is_enabled = clk_gpio_gate_is_enabled,
+};
+EXPORT_SYMBOL_GPL(clk_gpio_gate_ops);
+
+/**
+ * clk_register_gpio - register a gpip clock with the clock framework
+ * @dev: device that is registering this clock
+ * @name: name of this clock
+ * @parent_name: name of this clock's parent
+ * @gpiod: gpio descriptor to gate this clock
+ */
+struct clk *clk_register_gpio_gate(struct device *dev, const char *name,
+ const char *parent_name, struct gpio_desc *gpiod,
+ unsigned long flags)
+{
+
Re: [PATCHv2 0/2] OMAP IOMMU Fixes for DT-clients
On Thu, Sep 04, 2014 at 05:27:28PM -0500, Suman Anna wrote: Suman Anna (2): iommu/omap: Check for valid archdata in attach_dev iommu/omap: Fix iommu archdata name for DT-based devices drivers/iommu/omap-iommu.c | 15 ++- 1 file changed, 14 insertions(+), 1 deletion(-) Applied, thanks. -- 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 v5 1/2] usb: rename phy to usb_phy in HCD
On Fri, Sep 05, 2014 at 01:42:09AM +0400, Sergei Shtylyov wrote:
From: Antoine Tenart antoine.ten...@free-electrons.com
The USB PHY member of the HCD structure is renamed to 'usb_phy' and
modifications are done in all drivers accessing it.
This is in preparation to adding the generic PHY support.
Signed-off-by: Antoine Tenart antoine.ten...@free-electrons.com
[Sergei: added missing 'drivers/usb/misc/lvstest.c' file, resolved rejects
caused by patch reordering, updated changelog.]
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
Acked-by: Alan Stern st...@rowland.harvard.edu
Acked-by: Felipe Balbi ba...@ti.com
---
Changes in version 5:
- imported the patch from Antoine Tenart's series;
- added missing 'drivers/usb/misc/lvstest.c' file;
- resolved rejects caused by patch reordering;
- refreshed patch;
- updated changelog.
drivers/usb/chipidea/host.c |2 +-
drivers/usb/core/hcd.c| 20 ++--
drivers/usb/core/hub.c|8
drivers/usb/host/ehci-fsl.c | 16
drivers/usb/host/ehci-hub.c |2 +-
drivers/usb/host/ehci-msm.c |4 ++--
drivers/usb/host/ehci-tegra.c | 16
drivers/usb/host/ohci-omap.c | 20 ++--
drivers/usb/misc/lvstest.c|8
include/linux/usb/hcd.h |2 +-
10 files changed, 49 insertions(+), 49 deletions(-)
Index: usb/drivers/usb/chipidea/host.c
===
--- usb.orig/drivers/usb/chipidea/host.c
+++ usb/drivers/usb/chipidea/host.c
@@ -59,7 +59,7 @@ static int host_start(struct ci_hdrc *ci
hcd-has_tt = 1;
hcd-power_budget = ci-platdata-power_budget;
- hcd-phy = ci-transceiver;
+ hcd-usb_phy = ci-transceiver;
ehci = hcd_to_ehci(hcd);
ehci-caps = ci-hw_bank.cap;
Index: usb/drivers/usb/core/hcd.c
===
--- usb.orig/drivers/usb/core/hcd.c
+++ usb/drivers/usb/core/hcd.c
@@ -2627,7 +2627,7 @@ int usb_add_hcd(struct usb_hcd *hcd,
int retval;
struct usb_device *rhdev;
- if (IS_ENABLED(CONFIG_USB_PHY) !hcd-phy) {
+ if (IS_ENABLED(CONFIG_USB_PHY) !hcd-usb_phy) {
struct usb_phy *phy = usb_get_phy_dev(hcd-self.controller, 0);
if (IS_ERR(phy)) {
@@ -2640,7 +2640,7 @@ int usb_add_hcd(struct usb_hcd *hcd,
usb_put_phy(phy);
return retval;
}
- hcd-phy = phy;
+ hcd-usb_phy = phy;
hcd-remove_phy = 1;
}
}
@@ -2788,10 +2788,10 @@ err_allocate_root_hub:
err_register_bus:
hcd_buffer_destroy(hcd);
err_remove_phy:
- if (hcd-remove_phy hcd-phy) {
- usb_phy_shutdown(hcd-phy);
- usb_put_phy(hcd-phy);
- hcd-phy = NULL;
+ if (hcd-remove_phy hcd-usb_phy) {
+ usb_phy_shutdown(hcd-usb_phy);
+ usb_put_phy(hcd-usb_phy);
+ hcd-usb_phy = NULL;
}
return retval;
}
@@ -2864,10 +2864,10 @@ void usb_remove_hcd(struct usb_hcd *hcd)
usb_deregister_bus(hcd-self);
hcd_buffer_destroy(hcd);
- if (hcd-remove_phy hcd-phy) {
- usb_phy_shutdown(hcd-phy);
- usb_put_phy(hcd-phy);
- hcd-phy = NULL;
+ if (hcd-remove_phy hcd-usb_phy) {
+ usb_phy_shutdown(hcd-usb_phy);
+ usb_put_phy(hcd-usb_phy);
+ hcd-usb_phy = NULL;
}
usb_put_invalidate_rhdev(hcd);
Index: usb/drivers/usb/core/hub.c
===
--- usb.orig/drivers/usb/core/hub.c
+++ usb/drivers/usb/core/hub.c
@@ -4461,8 +4461,8 @@ hub_port_init (struct usb_hub *hub, stru
if (retval)
goto fail;
- if (hcd-phy !hdev-parent)
- usb_phy_notify_connect(hcd-phy, udev-speed);
+ if (hcd-usb_phy !hdev-parent)
+ usb_phy_notify_connect(hcd-usb_phy, udev-speed);
/*
* Some superspeed devices have finished the link training process
@@ -4617,9 +4617,9 @@ static void hub_port_connect(struct usb_
/* Disconnect any existing devices under this port */
if (udev) {
- if (hcd-phy !hdev-parent
+ if (hcd-usb_phy !hdev-parent
!(portstatus USB_PORT_STAT_CONNECTION))
- usb_phy_notify_disconnect(hcd-phy, udev-speed);
+ usb_phy_notify_disconnect(hcd-usb_phy, udev-speed);
usb_disconnect(port_dev-child);
}
Index: usb/drivers/usb/host/ehci-fsl.c
===
--- usb.orig/drivers/usb/host/ehci-fsl.c
+++ usb/drivers/usb/host/ehci-fsl.c
@@ -136,15 +136,15 @@ static int
Re: [GIT PULL] omap fixes against v3.17-rc3
Tony Lindgren t...@atomide.com writes: The following changes since commit 69e273c0b0a3c337a521d083374c918dc52c666f: Linux 3.17-rc3 (2014-08-31 18:23:04 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-fixes-against-v3.17-rc3 for you to fetch changes up to c7cc9ba11f8c09a4d12af0fc4aa9f9b026cdd354: ARM: dts: dra7-evm: Add vtt regulator support (2014-09-04 12:49:22 -0700) Few fixes for omaps mostly for various devices to get them working properly on the new am437x and dra7 hardware for several devices such as I2C, NAND, DDR3 and USB. There's also a clock fix for omap3. And also included are two minor cosmetic fixes that are not stictly fixes for the new hardware support added recently to downgrade a GPMC warning into a debug statement, and fix the confusing comments for dra7-evm spi1 mux. Note that these are all .dts changes except for a GPMC change. Applied to fixes, Kevin -- 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 v6 0/3] Add ST dwc3 glue layer driver
This series adds support for the ST glue logic which wraps the DWC3 controller on STiH407 SoC family chipsets. Changes since v5 - Use of_platform_depopulate Changes since v4 - Fix bug with setting bits in usb control register - Remove superflous '\n' - Change default Kconfig to make default same as other platforms - Update dt doc example so that both usb2 and usb3 phys are using generic drivers/phy instead of drivers/usb/phy - Reconfigure ST glue logic regs in resume callback Changes since v3 - Various formating nits Changes since v2 - Use dr_mode for host/device static configuration - Manage shared reset signal to usbss to avoid hang if probing before usb3 phy - Remove DT checks and make driver depend on OF - Change some #define to use BIT macro - Make some comments clearer - Use kerneldoc for struct documentation - Remove udelay - Let DT create platform_devices, and remove legacy alloc - Change some logging levels to dev_dbg - Various whitespace and formatting cleanup - Use SIMPLE_DEV_PM_OPS() - Add const to of_device struct - Reorder header files alphabetically - Use devm_ioremap_resource instead of devm_request_and_ioremap - Remove of_match_ptr() Changes since v1 - Fix Kconfig mistake Peter Griffin (3): usb: dwc3: add ST dwc3 glue layer to manage dwc3 HC usb: dwc3: dwc3-st: Add st-dwc3 devicetree bindings documentation MAINTAINERS: Add dwc3-st.c file to ARCH/STI architecture Documentation/devicetree/bindings/usb/dwc3-st.txt | 68 MAINTAINERS | 1 + drivers/usb/dwc3/Kconfig | 9 + drivers/usb/dwc3/Makefile | 1 + drivers/usb/dwc3/dwc3-st.c| 377 ++ 5 files changed, 456 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/dwc3-st.txt create mode 100644 drivers/usb/dwc3/dwc3-st.c -- 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 v6 3/3] MAINTAINERS: Add dwc3-st.c file to ARCH/STI architecture
This patch adds the new dwc3-st.c glue driver found on STMicroelectronics stih407 consumer electronics SoC's into the STI arch section of the maintainers file. Signed-off-by: Peter Griffin peter.grif...@linaro.org Acked-by: Lee Jones lee.jo...@linaro.org --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index cf24bb5..55381955 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1398,6 +1398,7 @@ F:drivers/media/rc/st_rc.c F: drivers/i2c/busses/i2c-st.c F: drivers/tty/serial/st-asc.c F: drivers/mmc/host/sdhci-st.c +F: drivers/usb/dwc3/dwc3-st.c ARM/TECHNOLOGIC SYSTEMS TS7250 MACHINE SUPPORT M: Lennert Buytenhek ker...@wantstofly.org -- 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 v6 1/3] usb: dwc3: add ST dwc3 glue layer to manage dwc3 HC
This patch adds the ST glue logic to manage the DWC3 HC
on STiH407 SoC family. It manages the powerdown signal,
and configures the internal glue logic and syscfg registers.
Signed-off-by: Giuseppe Cavallaro peppe.cavall...@st.com
Signed-off-by: Peter Griffin peter.grif...@linaro.org
Acked-by: Lee Jones lee.jo...@linaro.org
---
drivers/usb/dwc3/Kconfig | 9 ++
drivers/usb/dwc3/Makefile | 1 +
drivers/usb/dwc3/dwc3-st.c | 377 +
3 files changed, 387 insertions(+)
create mode 100644 drivers/usb/dwc3/dwc3-st.c
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index 785510a..5238251 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -80,6 +80,15 @@ config USB_DWC3_KEYSTONE
Support of USB2/3 functionality in TI Keystone2 platforms.
Say 'Y' or 'M' here if you have one such device
+config USB_DWC3_ST
+ tristate STMicroelectronics Platforms
+ depends on ARCH_STI OF
+ default USB_DWC3
+ help
+ STMicroelectronics SoCs with one DesignWare Core USB3 IP
+ inside (i.e. STiH407).
+ Say 'Y' or 'M' if you have one such device.
+
comment Debugging features
config USB_DWC3_DEBUG
diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
index 10ac3e7..11c9f54 100644
--- a/drivers/usb/dwc3/Makefile
+++ b/drivers/usb/dwc3/Makefile
@@ -33,3 +33,4 @@ obj-$(CONFIG_USB_DWC3_OMAP) += dwc3-omap.o
obj-$(CONFIG_USB_DWC3_EXYNOS) += dwc3-exynos.o
obj-$(CONFIG_USB_DWC3_PCI) += dwc3-pci.o
obj-$(CONFIG_USB_DWC3_KEYSTONE)+= dwc3-keystone.o
+obj-$(CONFIG_USB_DWC3_ST) += dwc3-st.o
diff --git a/drivers/usb/dwc3/dwc3-st.c b/drivers/usb/dwc3/dwc3-st.c
new file mode 100644
index 000..c4c1717
--- /dev/null
+++ b/drivers/usb/dwc3/dwc3-st.c
@@ -0,0 +1,377 @@
+/**
+ * dwc3-st.c Support for dwc3 platform devices on ST Microelectronics platforms
+ *
+ * This is a small driver for the dwc3 to provide the glue logic
+ * to configure the controller. Tested on STi platforms.
+ *
+ * Copyright (C) 2014 Stmicroelectronics
+ *
+ * Author: Giuseppe Cavallaro peppe.cavall...@st.com
+ * Contributors: Aymen Bouattay aymen.bouat...@st.com
+ * Peter Griffin peter.grif...@linaro.org
+ *
+ * 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; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Inspired by dwc3-omap.c and dwc3-exynos.c.
+ */
+
+#include linux/delay.h
+#include linux/interrupt.h
+#include linux/io.h
+#include linux/ioport.h
+#include linux/kernel.h
+#include linux/mfd/syscon.h
+#include linux/module.h
+#include linux/of.h
+#include linux/of_platform.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/regmap.h
+#include linux/reset.h
+#include linux/usb/of.h
+
+#include core.h
+#include io.h
+
+/* glue registers */
+#define CLKRST_CTRL0x00
+#define AUX_CLK_EN BIT(0)
+#define SW_PIPEW_RESET_N BIT(4)
+#define EXT_CFG_RESET_NBIT(8)
+/*
+ * 1'b0 : The host controller complies with the xHCI revision 0.96
+ * 1'b1 : The host controller complies with the xHCI revision 1.0
+ */
+#define XHCI_REVISION BIT(12)
+
+#define USB2_VBUS_MNGMNT_SEL1 0x2C
+/*
+ * For all fields in USB2_VBUS_MNGMNT_SEL1
+ * 2’b00 : Override value from Reg 0x30 is selected
+ * 2’b01 : utmiotg_signal_name from usb3_top is selected
+ * 2’b10 : pipew_signal_name from PIPEW instance is selected
+ * 2’b11 : value is 1'b0
+ */
+#define USB2_VBUS_REG300x0
+#define USB2_VBUS_UTMIOTG 0x1
+#define USB2_VBUS_PIPEW0x2
+#define USB2_VBUS_ZERO 0x3
+
+#define SEL_OVERRIDE_VBUSVALID(n) (n 0)
+#define SEL_OVERRIDE_POWERPRESENT(n) (n 4)
+#define SEL_OVERRIDE_BVALID(n) (n 8)
+
+/* Static DRD configuration */
+#define USB3_CONTROL_MASK 0xf77
+
+#define USB3_DEVICE_NOT_HOST BIT(0)
+#define USB3_FORCE_VBUSVALID BIT(1)
+#define USB3_DELAY_VBUSVALID BIT(2)
+#define USB3_SEL_FORCE_OPMODE BIT(4)
+#define USB3_FORCE_OPMODE(n) (n 5)
+#define USB3_SEL_FORCE_DPPULLDOWN2 BIT(8)
+#define USB3_FORCE_DPPULLDOWN2 BIT(9)
+#define USB3_SEL_FORCE_DMPULLDOWN2 BIT(10)
+#define USB3_FORCE_DMPULLDOWN2 BIT(11)
+
+/**
+ * struct st_dwc3 - dwc3-st driver private structure
+ * @dev: device pointer
+ * @glue_base: ioaddr for the glue registers
+ * @regmap:regmap pointer for getting syscfg
+ * @syscfg_reg_off:usb syscfg control offset
+ * @dr_mode: drd static host/device config
+ * @rstc_pwrdn:rest controller for powerdown signal
+ * @rstc_rst: reset controller for softreset signal
+ */
+
+struct st_dwc3 {
+ struct device *dev;
+
[PATCH v6 2/3] usb: dwc3: dwc3-st: Add st-dwc3 devicetree bindings documentation
This patch documents the device tree documentation required for
the ST usb3 controller glue layer found in STiH407 devices.
Signed-off-by: Giuseppe Cavallaro peppe.cavall...@st.com
Signed-off-by: Peter Griffin peter.grif...@linaro.org
Acked-by: Lee Jones lee.jo...@linaro.org
---
Documentation/devicetree/bindings/usb/dwc3-st.txt | 68 +++
1 file changed, 68 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/dwc3-st.txt
diff --git a/Documentation/devicetree/bindings/usb/dwc3-st.txt
b/Documentation/devicetree/bindings/usb/dwc3-st.txt
new file mode 100644
index 000..f9d7025
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/dwc3-st.txt
@@ -0,0 +1,68 @@
+ST DWC3 glue logic
+
+This file documents the parameters for the dwc3-st driver.
+This driver controls the glue logic used to configure the dwc3 core on
+STiH407 based platforms.
+
+Required properties:
+ - compatible : must be st,stih407-dwc3
+ - reg : glue logic base address and USB syscfg ctrl register offset
+ - reg-names : should be reg-glue and syscfg-reg
+ - st,syscon : should be phandle to system configuration node which
+ encompasses the glue registers
+ - resets : list of phandle and reset specifier pairs. There should be
two entries, one
+ for the powerdown and softreset lines of the usb3 IP
+ - reset-names : list of reset signal names. Names should be powerdown and
softreset
+See: Documentation/devicetree/bindings/reset/st,sti-powerdown.txt
+See: Documentation/devicetree/bindings/reset/reset.txt
+
+ - #address-cells, #size-cells : should be '1' if the device has sub-nodes
+ with 'reg' property
+
+ - pinctl-names: A pinctrl state named default must be defined
+See: Documentation/devicetree/bindings/pinctrl/pinctrl-binding.txt
+
+ - pinctrl-0 : Pin control group
+See: Documentation/devicetree/bindings/pinctrl/pinctrl-binding.txt
+
+ - ranges : allows valid 1:1 translation between child's address space and
+ parent's address space
+
+Sub-nodes:
+The dwc3 core should be added as subnode to ST DWC3 glue as shown in the
+example below. The DT binding details of dwc3 can be found in:
+Documentation/devicetree/bindings/usb/dwc3.txt
+
+NB: The dr_mode property described in [1] is NOT optional for this driver, as
the default value
+is otg, which isn't supported by this SoC. Valid dr_mode values for dwc3-st
are either host
+or device.
+
+[1] Documentation/devicetree/bindings/usb/generic.txt
+
+Example:
+
+st_dwc3: dwc3@8f94000 {
+ status = disabled;
+ compatible = st,stih407-dwc3;
+ reg = 0x08f94000 0x1000, 0x110 0x4;
+ reg-names = reg-glue, syscfg-reg;
+ st,syscfg = syscfg_core;
+ resets = powerdown STIH407_USB3_POWERDOWN,
+ softreset STIH407_MIPHY2_SOFTRESET;
+ reset-names = powerdown,
+ softreset;
+ #address-cells = 1;
+ #size-cells = 1;
+ pinctrl-names = default;
+ pinctrl-0 = pinctrl_usb3;
+ ranges;
+
+ dwc3: dwc3@990 {
+ compatible = snps,dwc3;
+ reg = 0x0990 0x10;
+ interrupts = GIC_SPI 155 IRQ_TYPE_NONE;
+ dr_mode = host;
+ phys-names = usb2-phy, usb3-phy;
+ phys= usb2_picophy2, phy_port2 MIPHY_TYPE_USB;
+ };
+};
--
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 v6 1/3] usb: dwc3: add ST dwc3 glue layer to manage dwc3 HC
Hi,
On Fri, Sep 05, 2014 at 04:36:30PM +0100, Peter Griffin wrote:
+static int st_dwc3_remove_child(struct device *dev, void *c)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+
+ of_device_unregister(pdev);
+
+ return 0;
+}
+
+static int st_dwc3_remove(struct platform_device *pdev)
+{
+ struct st_dwc3 *dwc3_data = platform_get_drvdata(pdev);
+
+ device_for_each_child(pdev-dev, NULL, st_dwc3_remove_child);
same as before, of_platform_depopulate(). I can fix this one myself this
time.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v6 1/3] usb: dwc3: add ST dwc3 glue layer to manage dwc3 HC
On Fri, Sep 05, 2014 at 10:47:01AM -0500, Felipe Balbi wrote:
Hi,
On Fri, Sep 05, 2014 at 04:36:30PM +0100, Peter Griffin wrote:
+static int st_dwc3_remove_child(struct device *dev, void *c)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+
+ of_device_unregister(pdev);
+
+ return 0;
+}
+
+static int st_dwc3_remove(struct platform_device *pdev)
+{
+ struct st_dwc3 *dwc3_data = platform_get_drvdata(pdev);
+
+ device_for_each_child(pdev-dev, NULL, st_dwc3_remove_child);
same as before, of_platform_depopulate(). I can fix this one myself this
time.
it's in my testign/next branch, please make sure it looks alright.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v6 1/3] usb: dwc3: add ST dwc3 glue layer to manage dwc3 HC
Hi Felipe, On Fri, 05 Sep 2014, Felipe Balbi wrote: + + device_for_each_child(pdev-dev, NULL, st_dwc3_remove_child); same as before, of_platform_depopulate(). I can fix this one myself this time. Oh sorry, not sure what happened there, thanks for fixing it up:-) it's in my testign/next branch, please make sure it looks alright. Just checked and it looks good. regards, Peter. -- 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 v6 1/3] usb: dwc3: add ST dwc3 glue layer to manage dwc3 HC
On Fri, Sep 05, 2014 at 05:55:20PM +0100, Peter Griffin wrote: Hi Felipe, On Fri, 05 Sep 2014, Felipe Balbi wrote: + + device_for_each_child(pdev-dev, NULL, st_dwc3_remove_child); same as before, of_platform_depopulate(). I can fix this one myself this time. Oh sorry, not sure what happened there, thanks for fixing it up:-) no problem, it was small enough it's in my testign/next branch, please make sure it looks alright. Just checked and it looks good. cool thanks, I'll run some extra build testing and move it to next soonish. -- balbi signature.asc Description: Digital signature
[PATCH] ARM: dts: omap3-overo: Fix UART wake-up events
Compared to legacy booting, we don't have wake-up events enabled
for device tree based booting. This means that if deeper idle
states are enabled, the device won't wake up to UART events and
seems like it has hung.
Let's fix that by adding the wake-up interrupt. Note that we
don't need to set the PIN_OFF_WAKEUPENABLE any longer, that's
handled by the wake-up interrupt when the serial driver does
request_irq on it.
Tested with the following on omap3-overo-summit that has the
ES2.1 omap:
#!/bin/bash
uarts=$(find /sys/class/tty/ttyO*/device/power/ -type d)
for uart in $uarts; do
echo 3000 $uart/autosuspend_delay_ms
done
uarts=$(find /sys/class/tty/ttyO*/power/ -type d)
for uart in $uarts; do
echo enabled $uart/wakeup
echo auto $uart/control
done
echo 1 /sys/kernel/debug/pm_debug/enable_off_mode
# grep -i uart /proc/interrupts
90: 1085 INTC 74 OMAP UART2
338: 5 pinctrl 366 OMAP UART2
# grep ^core_pwrdm /sys/kernel/debug/pm_debug/count
core_pwrdm (ON),OFF:1654,RET:131,INA:39,ON:1825...
Signed-off-by: Tony Lindgren t...@atomide.com
--- a/arch/arm/boot/dts/omap3-overo-common-peripherals.dtsi
+++ b/arch/arm/boot/dts/omap3-overo-common-peripherals.dtsi
@@ -36,8 +36,8 @@
uart3_pins: pinmux_uart3_pins {
pinctrl-single,pins =
- OMAP3_CORE1_IOPAD(0x219e, PIN_INPUT |
PIN_OFF_WAKEUPENABLE | MUX_MODE0) /* uart3_rx_irrx.uart3_rx_irrx */
- OMAP3_CORE1_IOPAD(0x21a0, PIN_OUTPUT | MUX_MODE0)
/* uart3_tx_irtx.uart3_tx_irtx */
+ OMAP3_CORE1_IOPAD(0x219e, PIN_INPUT | MUX_MODE0)
/* uart3_rx_irrx.uart3_rx_irrx */
+ OMAP3_CORE1_IOPAD(0x21a0, PIN_OUTPUT | MUX_MODE0)
/* uart3_tx_irtx.uart3_tx_irtx */
;
};
};
@@ -88,6 +88,7 @@
};
uart3 {
+ interrupts-extended = intc 74 omap3_pmx_core OMAP3_UART3_RX;
pinctrl-names = default;
pinctrl-0 = uart3_pins;
};
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: OMAP2+: DRA72x/DRA74x basic support
Hello Olof, Sorry for the confusion, and thanks for the clarification. TI folks: no new platform support will be accepted through me for any future -rc series patchsets. - Paul On Sun, 31 Aug 2014, Olof Johansson wrote: This one clearly falls into the category of new platform support, not bugfixes. But it's pretty small so I'll pick it up this time. -Olof On Thu, Aug 28, 2014 at 10:02 AM, Tony Lindgren t...@atomide.com wrote: Arnd Olof, Can you please pick this one up for the -rc cycle so the TI guys can boot test dra7 with mainline properly? Regards, Tony * Paul Walmsley p...@pwsan.com [140827 23:18]: Hi Tony, The following changes since commit 52addcf9d6669fa439387610bc65c92fa0980cef: Linux 3.17-rc2 (2014-08-25 15:36:20 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/for-v3.17-rc/omap-dra72x-d74x-support-a for you to fetch changes up to f7f7a29bf0cf25af23f37e5b5bf1368b85705286: ARM: DRA7: hwmod: Add dra74x and dra72x specific ocp interface lists (2014-08-27 19:38:23 -0600) Add basic subarchitecture support for the DRA72x and DRA74x. These are OMAP2+ derivative SoCs. This should be low-risk to existing OMAP platforms. Basic build, boot, and PM test logs are available here: http://www.pwsan.com/omap/testlogs/hwmod-a-early-v3.17-rc/20140827194314/ Rajendra Nayak (2): ARM: DRA7: Add support for soc_is_dra74x() and soc_is_dra72x() variants ARM: DRA7: hwmod: Add dra74x and dra72x specific ocp interface lists arch/arm/mach-omap2/omap_hwmod.c | 3 +++ arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 22 -- arch/arm/mach-omap2/soc.h | 6 ++ 3 files changed, 29 insertions(+), 2 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 - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] ARM: DRA7: Add support for soc_is_dra74x() and soc_is_dra72x() variants
On Thu, 28 Aug 2014, Nishanth Menon wrote: On Thu, Aug 28, 2014 at 1:19 AM, Paul Walmsley p...@pwsan.com wrote: On Wed, 27 Aug 2014, Nishanth Menon wrote: On Mon, Jul 28, 2014 at 12:34 AM, Lokesh Vutla lokeshvu...@ti.com wrote: On Monday 28 July 2014 10:59 AM, Paul Walmsley wrote: On Mon, 28 Jul 2014, Lokesh Vutla wrote: From: Rajendra Nayak rna...@ti.com Use the corresponding compatibles to identify the devices. Signed-off-by: Rajendra Nayak rna...@ti.com Signed-off-by: Lokesh Vutla lokeshvu...@ti.com Acked-by: Nishanth Menon n...@ti.com Tested-by: Nishanth Menon n...@ti.com Thanks, queued for (hopefully) early v3.17-rc. Thanks Paul. Paul, Tony, we are at 3.17-rc2 today, unfortunately.. http://slexy.org/view/s20MbRgipa dra72-evm is still broken due to this. Needs: https://patchwork.kernel.org/patch/4632161/ and https://patchwork.kernel.org/patch/4632171/ What can we do to help speed this along? A simple reminder, like this one, is good. Also providing boards and documentation generally helps, so the patches can be tested and reviewed. TI is working diligently towards a public TRM and potentially a related platform as well for all. Unfortunately, I am not yet aware of a official finalized release date.. hopefully this year.. OK In the meanwhile, we will try to provide test logs that you may desire for at least the platforms we have functioning and access to. please feel free to request specific test vectors if you feel our coverage is not good enough. Thanks. You've been showing a lot of great leadership in proactively posting test logs. What I'd suggest doing is to keep that up, and if possible, post one of the test reports for each patch series that's posted, if possible. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] ARM: DRA7: Add support for soc_is_dra74x() and soc_is_dra72x() variants
On 09/05/2014 01:08 PM, Paul Walmsley wrote: [...] In the meanwhile, we will try to provide test logs that you may desire for at least the platforms we have functioning and access to. please feel free to request specific test vectors if you feel our coverage is not good enough. Thanks. You've been showing a lot of great leadership in proactively posting test logs. What I'd suggest doing is to keep that up, and if possible, post one of the test reports for each patch series that's posted, if possible. I do have automated scripts verifying various defconfigs on a daily basis for linux-next and master tags.. https://github.com/nmenon/kernel-test-logs/ (based on each tag). Every TI engineer does have access to these platforms as well as I do. Realistically, few platforms do go offline and online as time goes on. we will try to post test reports for each series as much as our TI policies let us. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 00/18] 8250-core based serial driver for OMAP + DMA
This is my complete queue fo the omap serial driver based on the 8250 core code. I played with it on beagle bone, am335x-evm and dra7xx including DMA. The runtime-pm pieces look now bug-compatible with the omap-serial driver. Besides the runtime-om improvement I also fixed a few corner cases for the TX-DMA problem. The DMA fixes (in edma and omap-dma) were dropped and the problem has been in 8250-dma via patch #13. The whole queue is available at git://git.breakpoint.cc/bigeasy/linux.git uart_v8 Sebastian -- 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 02/18] tty: serial: 8250_core: allow to overwrite export serial8250_startup()
The OMAP version of the 8250 can actually use 1:1 serial8250_startup().
However it needs to be extended by a wake up irq which should to be
requested enabled at -startup() time and disabled at -shutdown() time.
v2…v3: properly copy callbacks
v1…v2: add shutdown callback
Acked-by: Alan Cox a...@linux.intel.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/tty/serial/8250/8250_core.c | 25 +++--
include/linux/serial_8250.h | 2 ++
include/linux/serial_core.h | 2 ++
3 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_core.c
b/drivers/tty/serial/8250/8250_core.c
index e2ad13a9aea4..54fd42f0e6f0 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -1929,7 +1929,7 @@ static void serial8250_put_poll_char(struct uart_port
*port,
#endif /* CONFIG_CONSOLE_POLL */
-static int serial8250_startup(struct uart_port *port)
+int serial8250_do_startup(struct uart_port *port)
{
struct uart_8250_port *up = up_to_u8250p(port);
unsigned long flags;
@@ -2180,8 +2180,16 @@ static int serial8250_startup(struct uart_port *port)
return 0;
}
+EXPORT_SYMBOL_GPL(serial8250_do_startup);
-static void serial8250_shutdown(struct uart_port *port)
+static int serial8250_startup(struct uart_port *port)
+{
+ if (port-startup)
+ return port-startup(port);
+ return serial8250_do_startup(port);
+}
+
+void serial8250_do_shutdown(struct uart_port *port)
{
struct uart_8250_port *up = up_to_u8250p(port);
unsigned long flags;
@@ -2231,6 +2239,15 @@ static void serial8250_shutdown(struct uart_port *port)
if (port-irq)
serial_unlink_irq_chain(up);
}
+EXPORT_SYMBOL_GPL(serial8250_do_shutdown);
+
+static void serial8250_shutdown(struct uart_port *port)
+{
+ if (port-shutdown)
+ port-shutdown(port);
+ else
+ serial8250_do_shutdown(port);
+}
static unsigned int serial8250_get_divisor(struct uart_port *port, unsigned
int baud)
{
@@ -3428,6 +3445,10 @@ int serial8250_register_8250_port(struct uart_8250_port
*up)
/* Possibly override set_termios call */
if (up-port.set_termios)
uart-port.set_termios = up-port.set_termios;
+ if (up-port.startup)
+ uart-port.startup = up-port.startup;
+ if (up-port.shutdown)
+ uart-port.shutdown = up-port.shutdown;
if (up-port.pm)
uart-port.pm = up-port.pm;
if (up-port.handle_break)
diff --git a/include/linux/serial_8250.h b/include/linux/serial_8250.h
index f93649e22c43..c3aa0040c72e 100644
--- a/include/linux/serial_8250.h
+++ b/include/linux/serial_8250.h
@@ -121,6 +121,8 @@ extern void serial8250_early_out(struct uart_port *port,
int offset, int value);
extern int setup_early_serial8250_console(char *cmdline);
extern void serial8250_do_set_termios(struct uart_port *port,
struct ktermios *termios, struct ktermios *old);
+extern int serial8250_do_startup(struct uart_port *port);
+extern void serial8250_do_shutdown(struct uart_port *port);
extern void serial8250_do_pm(struct uart_port *port, unsigned int state,
unsigned int oldstate);
extern int fsl8250_handle_irq(struct uart_port *port);
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index cf3a1e789bf5..f3ea5312d89f 100644
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -122,6 +122,8 @@ struct uart_port {
void(*set_termios)(struct uart_port *,
struct ktermios *new,
struct ktermios *old);
+ int (*startup)(struct uart_port *port);
+ void(*shutdown)(struct uart_port *port);
int (*handle_irq)(struct uart_port *);
void(*pm)(struct uart_port *, unsigned int state,
unsigned int old);
--
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
[PATCH 08/18] tty: serial: Add 8250-core based omap driver
This patch provides a 8250-core based UART driver for the internal OMAP UART. The long term goal is to provide the same functionality as the current OMAP uart driver and DMA support. I tried to merge omap-serial code together with the 8250-core code. There should should be hardly a noticable difference. The trigger levels are different compared to omap-serial: - omap serial TX: Interrupt comes after TX FIFO has room for 16 bytes. TX of 4096 bytes in one go results in 256 interrupts RX: Interrupt comes after there is on byte in the FIFO. RX of 4096 bytes results in 4096 interrupts. - this driver TX: Interrupt comes once the TX FIFO is empty. TX of 4096 bytes results in 65 interrupts. That means there will be gaps on the line while the driver reloads the FIFO. RX: Interrupt comes once there are 48 bytes in the FIFO or less over longer time frame. We have 1 / 11520 * 10^3 * 16 = 1.38… ms 1.38ms to react and purge the FIFO on 115200,8N1. Since the other driver fired after each byte it had ~5.47ms time to react. This _may_ cause problems if one relies on no missing bytes and has no flow control. On the other hand we get only 85 interrupts for the same amount of data. It has been only tested as console UART on am335x-evm, dra7-evm and beagle bone. I also did some longer raw-transfers to meassure the load. The device name is ttyS based instead of ttyO. If a ttyO based node name is required please ask udev for it. If both driver are activated (this and omap-serial) then this serial driver will take control over the device due to the link order v7…v8: - redo the register write. There is now one function for that which is used from set_termios() and runtime-resume. - drop PORT_OMAP_16750 and move the setup to the omap file. We have our own set termios function anyway (Heikki Krogerus) - use MEM instead of MEM32. TRM of AM/DM37x says that 32bit access on THR might result in data abort. We only need 32bit access in the errata function which is before we use 8250's read function so it doesn't matter. v4…v7: - change trigger levels after some tests with raw transfers. v3…v4: - drop RS485 support - wire up -throttle / -unthrottle v2…v3: - wire up startup shutdown for wakeup-irq handling. - RS485 handling (well the core does). v1…v2: - added runtime PM. Could somebody could please double check this? - added omap_8250_set_termios() Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de --- drivers/tty/serial/8250/8250_omap.c | 905 drivers/tty/serial/8250/Kconfig | 9 + drivers/tty/serial/8250/Makefile| 1 + 3 files changed, 915 insertions(+) create mode 100644 drivers/tty/serial/8250/8250_omap.c diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c new file mode 100644 index ..4128bbc35089 --- /dev/null +++ b/drivers/tty/serial/8250/8250_omap.c @@ -0,0 +1,905 @@ +/* + * 8250-core based driver for the OMAP internal UART + * + * Copyright (C) 2014 Sebastian Andrzej Siewior + * + */ + +#include linux/device.h +#include linux/io.h +#include linux/module.h +#include linux/serial_8250.h +#include linux/serial_core.h +#include linux/serial_reg.h +#include linux/platform_device.h +#include linux/slab.h +#include linux/of.h +#include linux/of_gpio.h +#include linux/of_irq.h +#include linux/delay.h +#include linux/pm_runtime.h +#include linux/console.h +#include linux/pm_qos.h + +#include 8250.h + +#define UART_DLL_EM 9 +#define UART_DLM_EM 10 + +#define DEFAULT_CLK_SPEED 4800 /* 48 Mhz*/ + +#define UART_ERRATA_i202_MDR1_ACCESS (1 0) +#define OMAP_UART_WER_HAS_TX_WAKEUP(1 1) + +#define OMAP_UART_FCR_RX_TRIG 6 +#define OMAP_UART_FCR_TX_TRIG 4 + +/* SCR register bitmasks */ +#define OMAP_UART_SCR_RX_TRIG_GRANU1_MASK (1 7) +#define OMAP_UART_SCR_TX_TRIG_GRANU1_MASK (1 6) +#define OMAP_UART_SCR_TX_EMPTY (1 3) +#define OMAP_UART_SCR_DMAMODE_MASK (3 1) +#define OMAP_UART_SCR_DMAMODE_1(1 1) +#define OMAP_UART_SCR_DMAMODE_CTL (1 0) + +/* MVR register bitmasks */ +#define OMAP_UART_MVR_SCHEME_SHIFT 30 +#define OMAP_UART_LEGACY_MVR_MAJ_MASK 0xf0 +#define OMAP_UART_LEGACY_MVR_MAJ_SHIFT 4 +#define OMAP_UART_LEGACY_MVR_MIN_MASK 0x0f +#define OMAP_UART_MVR_MAJ_MASK 0x700 +#define OMAP_UART_MVR_MAJ_SHIFT8 +#define OMAP_UART_MVR_MIN_MASK 0x3f + +#define UART_TI752_TLR_TX 0 +#define UART_TI752_TLR_RX 4 + +#define TRIGGER_TLR_MASK(x)((x 0x3c) 2) +#define TRIGGER_FCR_MASK(x)(x 3) + +/* Enable XON/XOFF flow control on output */ +#define OMAP_UART_SW_TX0x08 +/* Enable XON/XOFF flow control on input */ +#define OMAP_UART_SW_RX
[PATCH 01/18] tty: serial: 8250_core: provide a function to export uart_8250_port
There is no way to access a struct uart_8250_port for a specific
line. This is only required outside of the 8250/uart callbacks like for
devices' suspend remove callbacks. For those the 8250-core provides a
wrapper like serial8250_unregister_port() which passes the struct
to the proper function based on the line argument.
For run time suspend I need access to this struct not only to make
serial_out() work but also to properly restore up-ier and up-mcr.
Acked-by: Alan Cox a...@linux.intel.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/tty/serial/8250/8250.h | 2 ++
drivers/tty/serial/8250/8250_core.c | 18 ++
2 files changed, 20 insertions(+)
diff --git a/drivers/tty/serial/8250/8250.h b/drivers/tty/serial/8250/8250.h
index 1b08c918cd51..85bfec58d77c 100644
--- a/drivers/tty/serial/8250/8250.h
+++ b/drivers/tty/serial/8250/8250.h
@@ -112,6 +112,8 @@ static inline void serial_dl_write(struct uart_8250_port
*up, int value)
up-dl_write(up, value);
}
+struct uart_8250_port *serial8250_get_port(int line);
+
#if defined(__alpha__) !defined(CONFIG_PCI)
/*
* Digital did something really horribly wrong with the OUT1 and OUT2
diff --git a/drivers/tty/serial/8250/8250_core.c
b/drivers/tty/serial/8250/8250_core.c
index 1d42dba6121d..e2ad13a9aea4 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -2880,6 +2880,24 @@ static struct uart_ops serial8250_pops = {
static struct uart_8250_port serial8250_ports[UART_NR];
+/**
+ * serial8250_get_port - retrieve struct uart_8250_port
+ * @line: serial line number
+ *
+ * This function retrieves struct uart_8250_port for the specific line.
+ * This struct *must* *not* be used to perform a 8250 or serial core operation
+ * which is not accessible otherwise. Its only purpose is to make the struct
+ * accessible to the runtime-pm callbacks for context suspend/restore.
+ * The lock assumption made here is none because runtime-pm suspend/resume
+ * callbacks should not be invoked if there is any operation performed on the
+ * port.
+ */
+struct uart_8250_port *serial8250_get_port(int line)
+{
+ return serial8250_ports[line];
+}
+EXPORT_SYMBOL_GPL(serial8250_get_port);
+
static void (*serial8250_isa_config)(int port, struct uart_port *up,
unsigned short *capabilities);
--
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
[PATCH 09/18] tty: serial: 8250_dma: handle error on TX submit
Right now it is possible that serial8250_tx_dma() fails and returns
-EBUSY. The caller (serial8250_start_tx()) will then enable
UART_IER_THRI which will generate an interrupt once the TX FIFO is
empty.
In serial8250_handle_irq() nothing will happen because up-dma is set
and so serial8250_tx_chars() won't be invoked. We end up with plenty of
interrupts and some too much work for irq output.
This patch introduces dma_tx_err in struct uart_8250_port to signal that
the last invocation of serial8250_tx_dma() failed so we can fill the TX
FIFO manually. Should the next invocation of serial8250_start_tx()
succeed then the dma_tx_err flag along with the THRI bit is removed and
DMA only usage may continue.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/tty/serial/8250/8250.h | 1 +
drivers/tty/serial/8250/8250_core.c | 4 +++-
drivers/tty/serial/8250/8250_dma.c | 30 +-
3 files changed, 29 insertions(+), 6 deletions(-)
diff --git a/drivers/tty/serial/8250/8250.h b/drivers/tty/serial/8250/8250.h
index 1bcb4b2141a6..a63d198f8d03 100644
--- a/drivers/tty/serial/8250/8250.h
+++ b/drivers/tty/serial/8250/8250.h
@@ -41,6 +41,7 @@ struct uart_8250_dma {
size_t tx_size;
unsigned char tx_running:1;
+ unsigned char tx_err: 1;
};
struct old_serial_port {
diff --git a/drivers/tty/serial/8250/8250_core.c
b/drivers/tty/serial/8250/8250_core.c
index e8df7cd85ba7..2101134e5031 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -1592,8 +1592,10 @@ int serial8250_handle_irq(struct uart_port *port,
unsigned int iir)
status = serial8250_rx_chars(up, status);
}
serial8250_modem_status(up);
- if (!up-dma (status UART_LSR_THRE))
+ if ((!up-dma || (up-dma up-dma-tx_err))
+ (status UART_LSR_THRE)) {
serial8250_tx_chars(up);
+ }
spin_unlock_irqrestore(port-lock, flags);
return 1;
diff --git a/drivers/tty/serial/8250/8250_dma.c
b/drivers/tty/serial/8250/8250_dma.c
index 148ffe4c232f..69e54abb6e71 100644
--- a/drivers/tty/serial/8250/8250_dma.c
+++ b/drivers/tty/serial/8250/8250_dma.c
@@ -36,8 +36,16 @@ static void __dma_tx_complete(void *param)
if (uart_circ_chars_pending(xmit) WAKEUP_CHARS)
uart_write_wakeup(p-port);
- if (!uart_circ_empty(xmit) !uart_tx_stopped(p-port))
- serial8250_tx_dma(p);
+ if (!uart_circ_empty(xmit) !uart_tx_stopped(p-port)) {
+ int ret;
+
+ ret = serial8250_tx_dma(p);
+ if (ret) {
+ dma-tx_err = 1;
+ p-ier |= UART_IER_THRI;
+ serial_port_out(p-port, UART_IER, p-ier);
+ }
+ }
spin_unlock_irqrestore(p-port.lock, flags);
}
@@ -69,6 +77,7 @@ int serial8250_tx_dma(struct uart_8250_port *p)
struct uart_8250_dma*dma = p-dma;
struct circ_buf *xmit = p-port.state-xmit;
struct dma_async_tx_descriptor *desc;
+ int ret;
if (uart_tx_stopped(p-port) || dma-tx_running ||
uart_circ_empty(xmit))
@@ -80,8 +89,10 @@ int serial8250_tx_dma(struct uart_8250_port *p)
dma-tx_addr + xmit-tail,
dma-tx_size, DMA_MEM_TO_DEV,
DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
- if (!desc)
- return -EBUSY;
+ if (!desc) {
+ ret = -EBUSY;
+ goto err;
+ }
dma-tx_running = 1;
@@ -94,8 +105,17 @@ int serial8250_tx_dma(struct uart_8250_port *p)
UART_XMIT_SIZE, DMA_TO_DEVICE);
dma_async_issue_pending(dma-txchan);
-
+ if (dma-tx_err) {
+ dma-tx_err = 0;
+ if (p-ier UART_IER_THRI) {
+ p-ier = ~UART_IER_THRI;
+ serial_out(p, UART_IER, p-ier);
+ }
+ }
return 0;
+err:
+ dma-tx_err = 1;
+ return ret;
}
EXPORT_SYMBOL_GPL(serial8250_tx_dma);
--
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
[PATCH 03/18] tty: serial: 8250_core: allow to set -throttle / -unthrottle callbacks
The OMAP UART provides support for HW assisted flow control. What is
missing is the support to throttle / unthrottle callbacks which are used
by the omap-serial driver at the moment.
This patch adds the callbacks. It should be safe to add them since they
are only invoked from the serial_core (uart_throttle()) if the feature
flags are set.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/tty/serial/8250/8250_core.c | 14 ++
include/linux/serial_core.h | 2 ++
2 files changed, 16 insertions(+)
diff --git a/drivers/tty/serial/8250/8250_core.c
b/drivers/tty/serial/8250/8250_core.c
index 54fd42f0e6f0..e2703e8d4b87 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -1318,6 +1318,16 @@ static void serial8250_start_tx(struct uart_port *port)
}
}
+static void serial8250_throttle(struct uart_port *port)
+{
+ port-throttle(port);
+}
+
+static void serial8250_unthrottle(struct uart_port *port)
+{
+ port-unthrottle(port);
+}
+
static void serial8250_stop_rx(struct uart_port *port)
{
struct uart_8250_port *up = up_to_u8250p(port);
@@ -2876,6 +2886,8 @@ static struct uart_ops serial8250_pops = {
.get_mctrl = serial8250_get_mctrl,
.stop_tx= serial8250_stop_tx,
.start_tx = serial8250_start_tx,
+ .throttle = serial8250_throttle,
+ .unthrottle = serial8250_unthrottle,
.stop_rx= serial8250_stop_rx,
.enable_ms = serial8250_enable_ms,
.break_ctl = serial8250_break_ctl,
@@ -3423,6 +3435,8 @@ int serial8250_register_8250_port(struct uart_8250_port
*up)
uart-port.fifosize = up-port.fifosize;
uart-tx_loadsz = up-tx_loadsz;
uart-capabilities = up-capabilities;
+ uart-port.throttle = up-port.throttle;
+ uart-port.unthrottle = up-port.unthrottle;
/* Take tx_loadsz from fifosize if it wasn't set separately */
if (uart-port.fifosize !uart-tx_loadsz)
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index f3ea5312d89f..ed036c0b 100644
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -124,6 +124,8 @@ struct uart_port {
struct ktermios *old);
int (*startup)(struct uart_port *port);
void(*shutdown)(struct uart_port *port);
+ void(*throttle)(struct uart_port *port);
+ void(*unthrottle)(struct uart_port *port);
int (*handle_irq)(struct uart_port *);
void(*pm)(struct uart_port *, unsigned int state,
unsigned int old);
--
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
[PATCH 07/18] tty: serial: 8250_core: remove UART_IER_RDI in serial8250_stop_rx()
serial8250_do_startup() adds UART_IER_RDI and UART_IER_RLSI to ier. serial8250_stop_rx() should remove both. This is what the serial-omap driver has been doing and is now moved to the 8250-core since it does no look to be *that* omap specific. Cc: heikki.kroge...@linux.intel.com Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de --- drivers/tty/serial/8250/8250_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/serial/8250/8250_core.c b/drivers/tty/serial/8250/8250_core.c index 8f5fb81d5fad..e8df7cd85ba7 100644 --- a/drivers/tty/serial/8250/8250_core.c +++ b/drivers/tty/serial/8250/8250_core.c @@ -1389,7 +1389,7 @@ static void serial8250_stop_rx(struct uart_port *port) serial8250_rpm_get(up); - up-ier = ~UART_IER_RLSI; + up-ier = ~(UART_IER_RLSI | UART_IER_RDI); up-port.read_status_mask = ~UART_LSR_DR; serial_port_out(port, UART_IER, up-ier); -- 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
[PATCH 05/18] tty: serial: 8250_core: read only RX if there is something in the FIFO
The serial8250_do_startup() function unconditionally clears the interrupts and for that it reads from the RX-FIFO without checking if there is a byte in the FIFO or not. This works fine on OMAP4+ HW like AM335x or DRA7. OMAP3630 ES1.1 (which means probably all OMAP3 and earlier) does not like this: |Unhandled fault: external abort on non-linefetch (0x1028) at 0xfb02 |Internal error: : 1028 [#1] ARM |Modules linked in: |CPU: 0 PID: 1 Comm: swapper Not tainted 3.16.0-00022-g7edcb57-dirty #1213 |task: de0572c0 ti: de058000 task.ti: de058000 |PC is at mem32_serial_in+0xc/0x1c |LR is at serial8250_do_startup+0x220/0x85c |Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel |Control: 10c5387d Table: 80004019 DAC: 0015 |[c03051d4] (mem32_serial_in) from [c0307fe8] (serial8250_do_startup+0x220/0x85c) |[c0307fe8] (serial8250_do_startup) from [c0309e00] (omap_8250_startup+0x5c/0xe0) |[c0309e00] (omap_8250_startup) from [c030863c] (serial8250_startup+0x18/0x2c) |[c030863c] (serial8250_startup) from [c030394c] (uart_startup+0x78/0x1d8) |[c030394c] (uart_startup) from [c0304678] (uart_open+0xe8/0x114) |[c0304678] (uart_open) from [c02e9e10] (tty_open+0x1a8/0x5a4) Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de --- drivers/tty/serial/8250/8250_core.c | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/drivers/tty/serial/8250/8250_core.c b/drivers/tty/serial/8250/8250_core.c index f9dd20ebab52..eaab8974a456 100644 --- a/drivers/tty/serial/8250/8250_core.c +++ b/drivers/tty/serial/8250/8250_core.c @@ -2086,8 +2086,8 @@ int serial8250_do_startup(struct uart_port *port) /* * Clear the interrupt registers. */ - serial_port_in(port, UART_LSR); - serial_port_in(port, UART_RX); + if (serial_port_in(port, UART_LSR) UART_LSR_DR) + serial_port_in(port, UART_RX); serial_port_in(port, UART_IIR); serial_port_in(port, UART_MSR); @@ -2248,8 +2248,8 @@ int serial8250_do_startup(struct uart_port *port) * saved flags to avoid getting false values from polling * routines or the previous session. */ - serial_port_in(port, UART_LSR); - serial_port_in(port, UART_RX); + if (serial_port_in(port, UART_LSR) UART_LSR_DR) + serial_port_in(port, UART_RX); serial_port_in(port, UART_IIR); serial_port_in(port, UART_MSR); up-lsr_saved_flags = 0; @@ -2342,7 +2342,8 @@ void serial8250_do_shutdown(struct uart_port *port) * Read data port to reset things, and then unlink from * the IRQ chain. */ - serial_port_in(port, UART_RX); + if (serial_port_in(port, UART_LSR) UART_LSR_DR) + serial_port_in(port, UART_RX); serial8250_rpm_put(up); del_timer_sync(up-timer); -- 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
[PATCH 04/18] tty: serial: 8250_core: add run time pm
While comparing the OMAP-serial and the 8250 part of this I noticed that
the latter does not use run time-pm. Here are the pieces. It is
basically a get before first register access and a last_busy + put after
last access. This has to be enabled from userland _and_ UART_CAP_RPM is
required for this.
The runtime PM can usually work transparently in the background however
there is one exception to this: After serial8250_tx_chars() completes
there still may be unsent bytes in the FIFO (depending on CPU speed vs
baud rate + flow control). Even if the TTY-buffer is empty we do not
want RPM to disable the device because it won't send the remaining
bytes. Instead we leave serial8250_tx_chars() with RPM enabled and wait
for the FIFO empty interrupt. Once we enter serial8250_tx_chars() with
an empty buffer we know that the FIFO is empty and since we are not going
to send anything, we can disable the device.
That xchg() is to ensure that serial8250_tx_chars() can be called
multiple times and only the first invocation will actually invoke the
runtime PM function. So that the last invocation of __stop_tx() will
disable runtime pm.
NOTE: do not enable RPM on the device unless you know what you do! If
the device goes idle, it won't be woken up by incomming RX data _unless_
there is a wakeup irq configured which is usually the RX pin configure
for wakeup via the reset module. The RX activity will then wake up the
device from idle. However the first character is garbage and lost. The
following bytes will be received once the device is up in time. On the
beagle board xm (omap3) it takes approx 13ms from the first wakeup byte
until the first byte that is received properly if the device was in
core-off.
v5…v8:
- drop RPM from serial8250_set_mctrl() it will be used in
restore path which already has RPM active and holds
dev-power.lock
v4…v5:
- add a wrapper around rpm function and introduce UART_CAP_RPM
to ensure RPM put is invoked after the TX FIFO is empty.
v3…v4:
- added runtime to the console code
- removed device_may_wakeup() from serial8250_set_sleep()
Cc: mika.westerb...@linux.intel.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/tty/serial/8250/8250.h | 1 +
drivers/tty/serial/8250/8250_core.c | 133
include/linux/serial_8250.h | 1 +
3 files changed, 122 insertions(+), 13 deletions(-)
diff --git a/drivers/tty/serial/8250/8250.h b/drivers/tty/serial/8250/8250.h
index 85bfec58d77c..1bcb4b2141a6 100644
--- a/drivers/tty/serial/8250/8250.h
+++ b/drivers/tty/serial/8250/8250.h
@@ -72,6 +72,7 @@ struct serial8250_config {
#define UART_CAP_UUE (1 12) /* UART needs IER bit 6 set (Xscale) */
#define UART_CAP_RTOIE (1 13) /* UART needs IER bit 4 set (Xscale,
Tegra) */
#define UART_CAP_HFIFO (1 14) /* UART has a hidden FIFO */
+#define UART_CAP_RPM (1 15) /* Runtime PM is active while idle */
#define UART_BUG_QUOT (1 0)/* UART has buggy quot LSB */
#define UART_BUG_TXEN (1 1)/* UART has buggy TX IIR status */
diff --git a/drivers/tty/serial/8250/8250_core.c
b/drivers/tty/serial/8250/8250_core.c
index e2703e8d4b87..f9dd20ebab52 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -37,6 +37,7 @@
#include linux/nmi.h
#include linux/mutex.h
#include linux/slab.h
+#include linux/pm_runtime.h
#ifdef CONFIG_SPARC
#include linux/sunserialcore.h
#endif
@@ -539,6 +540,53 @@ void serial8250_clear_and_reinit_fifos(struct
uart_8250_port *p)
}
EXPORT_SYMBOL_GPL(serial8250_clear_and_reinit_fifos);
+static void serial8250_rpm_get(struct uart_8250_port *p)
+{
+ if (!(p-capabilities UART_CAP_RPM))
+ return;
+ pm_runtime_get_sync(p-port.dev);
+}
+
+static void serial8250_rpm_put(struct uart_8250_port *p)
+{
+ if (!(p-capabilities UART_CAP_RPM))
+ return;
+ pm_runtime_mark_last_busy(p-port.dev);
+ pm_runtime_put_autosuspend(p-port.dev);
+}
+
+/*
+ * This two wrapper ensure, that enable_runtime_pm_tx() can be called more than
+ * once and disable_runtime_pm_tx() will still disable RPM because the fifo is
+ * empty and the HW can idle again.
+ */
+static void serial8250_rpm_get_tx(struct uart_8250_port *p)
+{
+ unsigned char rpm_active;
+
+ if (!(p-capabilities UART_CAP_RPM))
+ return;
+
+ rpm_active = xchg(p-rpm_tx_active, 1);
+ if (rpm_active)
+ return;
+ pm_runtime_get_sync(p-port.dev);
+}
+
+static void serial8250_rpm_put_tx(struct uart_8250_port *p)
+{
+ unsigned char rpm_active;
+
+ if (!(p-capabilities UART_CAP_RPM))
+ return;
+
+ rpm_active = xchg(p-rpm_tx_active, 0);
+ if (!rpm_active)
+ return;
+ pm_runtime_mark_last_busy(p-port.dev);
+ pm_runtime_put_autosuspend(p-port.dev);
+}
+
/*
* IER sleep
[PATCH 06/18] tty: serial: 8250_core: user the -line argument as a hint in serial8250_find_match_or_unused()
Tony noticed that the old omap-serial driver picked the uart number based on the hint given from device tree or platform device's id. The 8250 based omap driver doesn't do this because the core code does not honour the -line argument which is passed by the driver. This patch aims to keep the same behaviour as with omap-serial. The function will first try to use the line suggested -line argument and then fallback to the old strategy in case the port is taken. That means the the third uart will always be ttyS2 even if the previous two have not been enabled in DT. Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de --- drivers/tty/serial/8250/8250_core.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/tty/serial/8250/8250_core.c b/drivers/tty/serial/8250/8250_core.c index eaab8974a456..8f5fb81d5fad 100644 --- a/drivers/tty/serial/8250/8250_core.c +++ b/drivers/tty/serial/8250/8250_core.c @@ -3479,6 +3479,11 @@ static struct uart_8250_port *serial8250_find_match_or_unused(struct uart_port * if (uart_match_port(serial8250_ports[i].port, port)) return serial8250_ports[i]; + /* try line number first if still available */ + i = port-line; + if (i nr_uarts serial8250_ports[i].port.type == PORT_UNKNOWN + serial8250_ports[i].port.iobase == 0) + return serial8250_ports[i]; /* * We didn't find a matching entry, so look for the first * free entry. We look for one which hasn't been previously -- 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
[PATCH 18/18] tty: serial: 8250: omap: add dma support
This patch adds the required pieces to 8250-OMAP UART driver for DMA
support. The TX burst size is set to 1 so we can send an arbitrary
amount of bytes.
The RX burst is currently set to 48 which means we receive an DMA
interrupt every 48 bytes and have to reprogram everything. Less bytes in
the RX-FIFO mean that no DMA transfer will happen and the UART will send a
RX-timeout _or_ RDI event at which point the FIFO will be manually purged.
There is a workaround for TX-DMA on AM33xx where we put the first byte
into the FIFO to kick start the DMA process. Haven't seen this problem on
AM375x (beagle bone) or DRA7xx.
On AM375x there is Usage Note 2.7: UART: Cannot Acknowledge Idle
Requests in Smartidle Mode When Configured for DMA Operations in the
errata document. This problem persists even after disabling DMA in the
UART and will be addressed in the HWMOD.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/tty/serial/8250/8250_omap.c | 49 +
1 file changed, 49 insertions(+)
diff --git a/drivers/tty/serial/8250/8250_omap.c
b/drivers/tty/serial/8250/8250_omap.c
index 4128bbc35089..7e98dd413203 100644
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -360,6 +360,10 @@ static void omap_8250_set_termios(struct uart_port *port,
priv-scr = OMAP_UART_SCR_RX_TRIG_GRANU1_MASK | OMAP_UART_SCR_TX_EMPTY |
OMAP_UART_SCR_TX_TRIG_GRANU1_MASK;
+ if (up-dma)
+ priv-scr |= OMAP_UART_SCR_DMAMODE_1 |
+ OMAP_UART_SCR_DMAMODE_CTL;
+
priv-xon = termios-c_cc[VSTART];
priv-xoff = termios-c_cc[VSTOP];
@@ -542,6 +546,11 @@ static int omap_8250_startup(struct uart_port *port)
priv-wer |= OMAP_UART_TX_WAKEUP_EN;
serial_out(up, UART_OMAP_WER, priv-wer);
+ if (up-dma) {
+ serial8250_rx_dma(up, 0);
+ priv-dma_active = true;
+ }
+
pm_runtime_mark_last_busy(port-dev);
pm_runtime_put_autosuspend(port-dev);
return 0;
@@ -560,6 +569,10 @@ static void omap_8250_shutdown(struct uart_port *port)
struct omap8250_priv *priv = port-private_data;
flush_work(priv-qos_work);
+ if (up-dma) {
+ serial8250_rx_dma(up, UART_IIR_RX_TIMEOUT);
+ priv-dma_active = false;
+ }
pm_runtime_get_sync(port-dev);
@@ -607,6 +620,13 @@ static void omap_8250_unthrottle(struct uart_port *port)
pm_runtime_put_autosuspend(port-dev);
}
+#ifdef CONFIG_SERIAL_8250_DMA
+static bool the_no_dma_filter_fn(struct dma_chan *chan, void *param)
+{
+ return false;
+}
+#endif
+
static int omap8250_probe(struct platform_device *pdev)
{
struct resource *regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -706,6 +726,30 @@ static int omap8250_probe(struct platform_device *pdev)
pm_runtime_get_sync(pdev-dev);
omap_serial_fill_features_erratas(up, priv);
+#ifdef CONFIG_SERIAL_8250_DMA
+ if (pdev-dev.of_node) {
+ /*
+* Oh DMA support. If there are no DMA properties in the DT then
+* we will fall back to a generic DMA channel which does not
+* really work here. To ensure that we do not get a generic DMA
+* channel assigned, we have the the_no_dma_filter_fn() here.
+* To avoid failed to request DMA messages we check for DMA
+* properties in DT.
+*/
+ ret = of_property_count_strings(pdev-dev.of_node, dma-names);
+ if (ret == 2) {
+ up.dma = priv-omap8250_dma;
+ priv-omap8250_dma.fn = the_no_dma_filter_fn;
+ priv-omap8250_dma.rx_size = RX_TRIGGER;
+ priv-omap8250_dma.rxconf.src_maxburst = RX_TRIGGER;
+ priv-omap8250_dma.txconf.dst_maxburst = TX_TRIGGER;
+
+ if (of_machine_is_compatible(ti,am33xx))
+ up.bugs |= UART_BUG_DMA_TX;
+ up.bugs |= UART_BUG_DMA_RX;
+ }
+ }
+#endif
ret = serial8250_register_8250_port(up);
if (ret 0) {
dev_err(pdev-dev, unable to register 8250 port\n);
@@ -842,6 +886,8 @@ static int omap8250_runtime_suspend(struct device *dev)
}
omap8250_enable_wakeup(priv, true);
+ if (priv-dma_active)
+ serial8250_rx_dma(up, UART_IIR_RX_TIMEOUT);
priv-latency = PM_QOS_CPU_DMA_LAT_DEFAULT_VALUE;
schedule_work(priv-qos_work);
@@ -866,6 +912,9 @@ static int omap8250_runtime_resume(struct device *dev)
if (loss_cntx)
omap8250_restore_regs(up);
+ if (priv-dma_active)
+ serial8250_rx_dma(up, 0);
+
priv-latency = priv-calc_latency;
schedule_work(priv-qos_work);
return 0;
--
2.1.0
--
To
[PATCH 16/18] arm: dts: am33xx: add DMA properties for UART
Cc: devicet...@vger.kernel.org
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
arch/arm/boot/dts/am33xx.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 3a0a161342ba..078a760a4a21 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -200,6 +200,8 @@
reg = 0x44e09000 0x2000;
interrupts = 72;
status = disabled;
+ dmas = edma 26, edma 27;
+ dma-names = tx, rx;
};
uart1: serial@48022000 {
@@ -209,6 +211,8 @@
reg = 0x48022000 0x2000;
interrupts = 73;
status = disabled;
+ dmas = edma 28, edma 29;
+ dma-names = tx, rx;
};
uart2: serial@48024000 {
@@ -218,6 +222,8 @@
reg = 0x48024000 0x2000;
interrupts = 74;
status = disabled;
+ dmas = edma 30, edma 31;
+ dma-names = tx, rx;
};
uart3: serial@481a6000 {
--
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
[PATCH 15/18] tty: serial: 8250_dma: add pm runtime
There is nothing to do for RPM in the RX path. If the HW goes off then it
won't assert the DMA line and the transfer won't happen. So we hope that
the HW does not go off for RX to work (DMA or PIO makes no difference
here).
For TX the situation is slightly different. RPM is enabled on
start_tx(). We can't disable RPM on DMA complete callback because there
is still data in the FIFO which is being sent. We have to wait until
the FIFO is empty before we disable it.
For this to happen we fake a TX sent error and enable THRI. Once the
FIFO is empty we receive an interrupt and since the TTY-buffer is still
empty we put RPM via __stop_tx(). Should it been filed then in the
start_tx() path we should program the DMA transfer and remove the error
flag and the THRI bit.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/tty/serial/8250/8250_dma.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_dma.c
b/drivers/tty/serial/8250/8250_dma.c
index f0fce8236279..1b4a8e02e844 100644
--- a/drivers/tty/serial/8250/8250_dma.c
+++ b/drivers/tty/serial/8250/8250_dma.c
@@ -21,6 +21,7 @@ static void __dma_tx_complete(void *param)
struct uart_8250_dma*dma = p-dma;
struct circ_buf *xmit = p-port.state-xmit;
unsigned long flags;
+ bool en_thri = false;
dma_sync_single_for_cpu(dma-txchan-device-dev, dma-tx_addr,
UART_XMIT_SIZE, DMA_TO_DEVICE);
@@ -40,11 +41,16 @@ static void __dma_tx_complete(void *param)
int ret;
ret = serial8250_tx_dma(p);
- if (ret) {
- dma-tx_err = 1;
- p-ier |= UART_IER_THRI;
- serial_port_out(p-port, UART_IER, p-ier);
- }
+ if (ret)
+ en_thri = true;
+
+ } else if (p-capabilities UART_CAP_RPM)
+ en_thri = true;
+
+ if (en_thri) {
+ dma-tx_err = 1;
+ p-ier |= UART_IER_THRI;
+ serial_port_out(p-port, UART_IER, p-ier);
}
spin_unlock_irqrestore(p-port.lock, flags);
--
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
[PATCH 17/18] arm: dts: dra7: add DMA properties for UART
Cc: devicet...@vger.kernel.org
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
arch/arm/boot/dts/dra7.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index d678152db4cb..f273e3811f75 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -332,6 +332,8 @@
ti,hwmods = uart1;
clock-frequency = 4800;
status = disabled;
+ dmas = sdma 49, sdma 50;
+ dma-names = tx, rx;
};
uart2: serial@4806c000 {
@@ -341,6 +343,8 @@
ti,hwmods = uart2;
clock-frequency = 4800;
status = disabled;
+ dmas = sdma 51, sdma 52;
+ dma-names = tx, rx;
};
uart3: serial@4802 {
@@ -350,6 +354,8 @@
ti,hwmods = uart3;
clock-frequency = 4800;
status = disabled;
+ dmas = sdma 53, sdma 54;
+ dma-names = tx, rx;
};
uart4: serial@4806e000 {
@@ -359,6 +365,8 @@
ti,hwmods = uart4;
clock-frequency = 4800;
status = disabled;
+ dmas = sdma 55, sdma 56;
+ dma-names = tx, rx;
};
uart5: serial@48066000 {
@@ -368,6 +376,8 @@
ti,hwmods = uart5;
clock-frequency = 4800;
status = disabled;
+ dmas = sdma 63, sdma 64;
+ dma-names = tx, rx;
};
uart6: serial@48068000 {
@@ -377,6 +387,8 @@
ti,hwmods = uart6;
clock-frequency = 4800;
status = disabled;
+ dmas = sdma 79, sdma 80;
+ dma-names = tx, rx;
};
uart7: serial@4842 {
--
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
[PATCH 12/18] tty: serial: 8250_dma: optimize the xmit path due to UART_BUG_DMA_TX
Due to UART_BUG_DMA_TX the am335x has to put the first one byte into the
TX FIFO to get things going. If we get to serial8250_tx_dma() via
__dma_tx_complete() then the DMA engine just finished and the FIFO is
full and we can't put the first byte into the TX FIFO as kick start so
we leave with THRI enabled.
The result is that we end up manually filling the FIFO. We could be a
little better at this and try DMA once again. If it works, it works and
if not we do it manually.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/tty/serial/8250/8250_core.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_core.c
b/drivers/tty/serial/8250/8250_core.c
index 079048db8c81..7111b22de000 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -1597,9 +1597,21 @@ int serial8250_handle_irq(struct uart_port *port,
unsigned int iir)
serial8250_modem_status(up);
if ((!up-dma || (up-dma up-dma-tx_err))
(status UART_LSR_THRE)) {
- serial8250_tx_chars(up);
- }
+ if (!up-dma) {
+ serial8250_tx_chars(up);
+ } else {
+ if (uart_tx_stopped(up-port) ||
+ uart_circ_empty(up-port.state-xmit)) {
+ serial8250_tx_chars(up);
+ } else {
+ /* try again due to UART_BUG_DMA_TX+full fifo */
+ dma_err = serial8250_tx_dma(up);
+ if (dma_err)
+ serial8250_tx_chars(up);
+ }
+ }
+ }
spin_unlock_irqrestore(port-lock, flags);
return 1;
}
--
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
[PATCH 13/18] tty: serial: 8250_dma: keep own book keeping about RX transfers
After dmaengine_terminate_all() has been invoked then both DMA drivers
(edma and omap-dma) do not invoke dma_cookie_complete() to mark the
transfer as complete. This dma_cookie_complete() is performed by the
Synopsys DesignWare driver which is probably the only one that is used
by omap8250-dma and hence don't see following problem…
…which is that once a RX transfer has been terminated then following
query of channel status reports DMA_IN_PROGRESS (again: the actual
transfer has been canceled, there is nothing going on anymore).
This means that serial8250_rx_dma() never enqueues another DMA transfer
because it (wrongly) assumes that there is a transer already pending.
Vinod Koul refuses to accept a patch which adds this
dma_cookie_complete() to both drivers and so dmaengine_tx_status() would
report DMA_COMPLETE instead (and behave like the Synopsys DesignWare
driver already does). He argues that I am not allowed to use the cookie
to query the status and that the driver already cleaned everything up after
the invokation of dmaengine_terminate_all().
To end this I add a bookkeeping whether or not a RX-transfer has been
started to the 8250-dma code. It has already been done for the TX side.
*Now* we learn about the RX status based on our bookkeeping and don't
need dmaengine_tx_status() for this anymore.
Cc: vinod.k...@intel.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/tty/serial/8250/8250.h | 1 +
drivers/tty/serial/8250/8250_dma.c | 14 --
2 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/tty/serial/8250/8250.h b/drivers/tty/serial/8250/8250.h
index 09489b391568..a7581b37f264 100644
--- a/drivers/tty/serial/8250/8250.h
+++ b/drivers/tty/serial/8250/8250.h
@@ -42,6 +42,7 @@ struct uart_8250_dma {
unsigned char tx_running:1;
unsigned char tx_err: 1;
+ unsigned char rx_running:1;
};
struct old_serial_port {
diff --git a/drivers/tty/serial/8250/8250_dma.c
b/drivers/tty/serial/8250/8250_dma.c
index 48dc57aad0dd..6cd8a4db609a 100644
--- a/drivers/tty/serial/8250/8250_dma.c
+++ b/drivers/tty/serial/8250/8250_dma.c
@@ -60,6 +60,7 @@ static void __dma_rx_do_complete(struct uart_8250_port *p,
bool error)
dma_sync_single_for_cpu(dma-rxchan-device-dev, dma-rx_addr,
dma-rx_size, DMA_FROM_DEVICE);
+ dma-rx_running = 0;
dmaengine_tx_status(dma-rxchan, dma-rx_cookie, state);
dmaengine_terminate_all(dma-rxchan);
@@ -162,21 +163,21 @@ int serial8250_rx_dma(struct uart_8250_port *p, unsigned
int iir)
{
struct uart_8250_dma*dma = p-dma;
struct dma_async_tx_descriptor *desc;
- struct dma_tx_state state;
- int dma_status;
-
- dma_status = dmaengine_tx_status(dma-rxchan, dma-rx_cookie, state);
switch (iir 0x3f) {
case UART_IIR_RLSI:
/* 8250_core handles errors and break interrupts */
+ if (dma-rx_running) {
+ dmaengine_pause(dma-rxchan);
+ __dma_rx_do_complete(p, true);
+ }
return -EIO;
case UART_IIR_RX_TIMEOUT:
/*
* If RCVR FIFO trigger level was not reached, complete the
* transfer and let 8250_core copy the remaining data.
*/
- if (dma_status == DMA_IN_PROGRESS) {
+ if (dma-rx_running) {
dmaengine_pause(dma-rxchan);
__dma_rx_do_complete(p, true);
}
@@ -185,7 +186,7 @@ int serial8250_rx_dma(struct uart_8250_port *p, unsigned
int iir)
break;
}
- if (dma_status)
+ if (dma-rx_running)
return 0;
desc = dmaengine_prep_slave_single(dma-rxchan, dma-rx_addr,
@@ -194,6 +195,7 @@ int serial8250_rx_dma(struct uart_8250_port *p, unsigned
int iir)
if (!desc)
return -EBUSY;
+ dma-rx_running = 1;
desc-callback = __dma_rx_complete;
desc-callback_param = p;
--
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
[PATCH 11/18] tty: serial: 8250_dma: Add a TX trigger workaround for AM33xx
At least on AM335x the following problem exists: Even if the TX FIFO is
empty and a TX transfer is programmed (and started) the UART does not
trigger the DMA transfer.
After $TRESHOLD number of bytes have been written to the FIFO manually the
UART reevaluates the whole situation and decides that now there is enough
room in the FIFO and so the transfer begins.
This problem has not been seen on DRA7 or beaglebone (OMAP3). I am not
sure if this is UART-IP core specific or DMA engine.
The workaround is to use a threshold of one byte, program the DMA
transfer minus one byte and then to put the first byte into the FIFO to
kick start the transfer.
v7…v8:
- fix the problem when get invoked and the FIFO is full.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/tty/serial/8250/8250.h | 3 +++
drivers/tty/serial/8250/8250_dma.c | 39 +++---
include/uapi/linux/serial_reg.h| 1 +
3 files changed, 40 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/8250/8250.h b/drivers/tty/serial/8250/8250.h
index fbed1636e9c4..09489b391568 100644
--- a/drivers/tty/serial/8250/8250.h
+++ b/drivers/tty/serial/8250/8250.h
@@ -82,6 +82,9 @@ struct serial8250_config {
#define UART_BUG_PARITY(1 4)/* UART mishandles parity if
FIFO enabled */
#define UART_BUG_DMA_RX(1 5)/* UART needs DMA RX req before
there is
data in FIFO */
+#define UART_BUG_DMA_TX(1 6)/* UART needs one byte in FIFO
for
+ kickstart */
+
#define PROBE_RSA (1 0)
#define PROBE_ANY (~0)
diff --git a/drivers/tty/serial/8250/8250_dma.c
b/drivers/tty/serial/8250/8250_dma.c
index 3674900a1f14..48dc57aad0dd 100644
--- a/drivers/tty/serial/8250/8250_dma.c
+++ b/drivers/tty/serial/8250/8250_dma.c
@@ -83,6 +83,7 @@ int serial8250_tx_dma(struct uart_8250_port *p)
struct uart_8250_dma*dma = p-dma;
struct circ_buf *xmit = p-port.state-xmit;
struct dma_async_tx_descriptor *desc;
+ unsigned intskip_byte = 0;
int ret;
if (uart_tx_stopped(p-port) || dma-tx_running ||
@@ -91,10 +92,40 @@ int serial8250_tx_dma(struct uart_8250_port *p)
dma-tx_size = CIRC_CNT_TO_END(xmit-head, xmit-tail, UART_XMIT_SIZE);
+ if (p-bugs UART_BUG_DMA_TX) {
+ u8 tx_lvl;
+
+ /*
+* We need to put the first byte into the FIFO in order to start
+* the DMA transfer. For transfers smaller than four bytes we
+* don't bother doing DMA at all. It seem not matter if there
+* are still bytes in the FIFO from the last transfer (in case
+* we got here directly from __dma_tx_complete()). Bytes leaving
+* the FIFO seem not to trigger the DMA transfer. It is really
+* the byte that we put into the FIFO.
+* If the FIFO is already full then we most likely got here from
+* __dma_tx_complete(). And this means the DMA engine just
+* completed its work. We don't have to wait the complete 86us
+* at 115200,8n1 but around 60us (not to mention lower
+* baudrates). So in that case we take the interrupt and try
+* again with an empty FIFO.
+*/
+ tx_lvl = serial_in(p, UART_OMAP_TX_LVL);
+ if (tx_lvl == p-tx_loadsz) {
+ ret = -EBUSY;
+ goto err;
+ }
+ if (dma-tx_size 4) {
+ ret = -EINVAL;
+ goto err;
+ }
+ skip_byte = 1;
+ }
+
desc = dmaengine_prep_slave_single(dma-txchan,
- dma-tx_addr + xmit-tail,
- dma-tx_size, DMA_MEM_TO_DEV,
- DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+ dma-tx_addr + xmit-tail + skip_byte,
+ dma-tx_size - skip_byte, DMA_MEM_TO_DEV,
+ DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
if (!desc) {
ret = -EBUSY;
goto err;
@@ -118,6 +149,8 @@ int serial8250_tx_dma(struct uart_8250_port *p)
serial_out(p, UART_IER, p-ier);
}
}
+ if (skip_byte)
+ serial_out(p, UART_TX, xmit-buf[xmit-tail]);
return 0;
err:
dma-tx_err = 1;
diff --git a/include/uapi/linux/serial_reg.h b/include/uapi/linux/serial_reg.h
index df6c9ab6b0cd..53af3b790129 100644
--- a/include/uapi/linux/serial_reg.h
+++ b/include/uapi/linux/serial_reg.h
@@ -359,6 +359,7 @@
#define UART_OMAP_SYSC 0x15/* System configuration register */
#define UART_OMAP_SYSS 0x16/*
[PATCH 10/18] tty: serial: 8250_dma: enqueue RX dma again on completion.
The omap needs a DMA request pending right away. If it is enqueued once
the bytes are in the FIFO then nothing will happen and the FIFO will be
later purged via RX-timeout interrupt.
This patch enqueues RX-DMA request on completion but not if it was
aborted on error. The first enqueue will happen in the driver in
startup.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/tty/serial/8250/8250.h | 3 ++-
drivers/tty/serial/8250/8250_core.c | 3 +++
drivers/tty/serial/8250/8250_dma.c | 12 +---
3 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/serial/8250/8250.h b/drivers/tty/serial/8250/8250.h
index a63d198f8d03..fbed1636e9c4 100644
--- a/drivers/tty/serial/8250/8250.h
+++ b/drivers/tty/serial/8250/8250.h
@@ -80,7 +80,8 @@ struct serial8250_config {
#define UART_BUG_NOMSR (1 2)/* UART has buggy MSR status bits
(Au1x00) */
#define UART_BUG_THRE (1 3)/* UART has buggy THRE reassertion */
#define UART_BUG_PARITY(1 4)/* UART mishandles parity if
FIFO enabled */
-
+#define UART_BUG_DMA_RX(1 5)/* UART needs DMA RX req before
there is
+ data in FIFO */
#define PROBE_RSA (1 0)
#define PROBE_ANY (~0)
diff --git a/drivers/tty/serial/8250/8250_core.c
b/drivers/tty/serial/8250/8250_core.c
index 2101134e5031..079048db8c81 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -1590,6 +1590,9 @@ int serial8250_handle_irq(struct uart_port *port,
unsigned int iir)
if (!up-dma || dma_err)
status = serial8250_rx_chars(up, status);
+
+ if (dma_err up-bugs UART_BUG_DMA_RX)
+ serial8250_rx_dma(up, 0);
}
serial8250_modem_status(up);
if ((!up-dma || (up-dma up-dma-tx_err))
diff --git a/drivers/tty/serial/8250/8250_dma.c
b/drivers/tty/serial/8250/8250_dma.c
index 69e54abb6e71..3674900a1f14 100644
--- a/drivers/tty/serial/8250/8250_dma.c
+++ b/drivers/tty/serial/8250/8250_dma.c
@@ -50,9 +50,8 @@ static void __dma_tx_complete(void *param)
spin_unlock_irqrestore(p-port.lock, flags);
}
-static void __dma_rx_complete(void *param)
+static void __dma_rx_do_complete(struct uart_8250_port *p, bool error)
{
- struct uart_8250_port *p = param;
struct uart_8250_dma*dma = p-dma;
struct tty_port *tty_port = p-port.state-port;
struct dma_tx_state state;
@@ -68,10 +67,17 @@ static void __dma_rx_complete(void *param)
tty_insert_flip_string(tty_port, dma-rx_buf, count);
p-port.icount.rx += count;
+ if (!error p-bugs UART_BUG_DMA_RX)
+ serial8250_rx_dma(p, 0);
tty_flip_buffer_push(tty_port);
}
+static void __dma_rx_complete(void *param)
+{
+ __dma_rx_do_complete(param, false);
+}
+
int serial8250_tx_dma(struct uart_8250_port *p)
{
struct uart_8250_dma*dma = p-dma;
@@ -139,7 +145,7 @@ int serial8250_rx_dma(struct uart_8250_port *p, unsigned
int iir)
*/
if (dma_status == DMA_IN_PROGRESS) {
dmaengine_pause(dma-rxchan);
- __dma_rx_complete(p);
+ __dma_rx_do_complete(p, true);
}
return -ETIMEDOUT;
default:
--
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
[RESEND PATCH] gpio: omap: Fix interrupt names
When viewing the /proc/interrupts, there is no information about which
GPIO bank a specific gpio interrupt is hooked on to. This is more than a
bit irritating as such information can esily be provided back to the
user and at times, can be crucial for debug.
So, instead of displaying something like:
31: 0 0 GPIO 0 palmas
32: 0 0 GPIO 27 mmc0
Display the following with appropriate device name:
31: 0 0 4ae1.gpio 0 palmas
32: 0 0 4805d000.gpio 27 mmc0
This requires that we create irq_chip instance specific for each GPIO
bank which is trivial to achieve.
Signed-off-by: Nishanth Menon n...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Acked-by: Kevin Hilman khil...@linaro.org
---
Requested to be resend by Javier with linux-gpio maintainers in CC.
Original V1 of the patch: https://patchwork.kernel.org/patch/4757891/
Probably belongs to 3.18 kernel series at this point in time.
Changes since v1: just picked up Acks.
V1: https://patchwork.kernel.org/patch/4757891/
based on v3.17-rc1
drivers/gpio/gpio-omap.c | 31 +--
1 file changed, 17 insertions(+), 14 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 1749321..aee25fa 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -857,16 +857,6 @@ static void omap_gpio_unmask_irq(struct irq_data *d)
spin_unlock_irqrestore(bank-lock, flags);
}
-static struct irq_chip gpio_irq_chip = {
- .name = GPIO,
- .irq_shutdown = omap_gpio_irq_shutdown,
- .irq_ack= omap_gpio_ack_irq,
- .irq_mask = omap_gpio_mask_irq,
- .irq_unmask = omap_gpio_unmask_irq,
- .irq_set_type = omap_gpio_irq_type,
- .irq_set_wake = omap_gpio_wake_enable,
-};
-
/*-*/
static int omap_mpuio_suspend_noirq(struct device *dev)
@@ -1088,7 +1078,7 @@ omap_mpuio_alloc_gc(struct gpio_bank *bank, unsigned int
irq_start,
IRQ_NOREQUEST | IRQ_NOPROBE, 0);
}
-static int omap_gpio_chip_init(struct gpio_bank *bank)
+static int omap_gpio_chip_init(struct gpio_bank *bank, struct irq_chip *irqc)
{
int j;
static int gpio;
@@ -1137,7 +1127,7 @@ static int omap_gpio_chip_init(struct gpio_bank *bank)
}
#endif
- ret = gpiochip_irqchip_add(bank-chip, gpio_irq_chip,
+ ret = gpiochip_irqchip_add(bank-chip, irqc,
irq_base, omap_gpio_irq_handler,
IRQ_TYPE_NONE);
@@ -1147,7 +1137,7 @@ static int omap_gpio_chip_init(struct gpio_bank *bank)
return -ENODEV;
}
- gpiochip_set_chained_irqchip(bank-chip, gpio_irq_chip,
+ gpiochip_set_chained_irqchip(bank-chip, irqc,
bank-irq, omap_gpio_irq_handler);
for (j = 0; j bank-width; j++) {
@@ -1172,6 +1162,7 @@ static int omap_gpio_probe(struct platform_device *pdev)
const struct omap_gpio_platform_data *pdata;
struct resource *res;
struct gpio_bank *bank;
+ struct irq_chip *irqc;
int ret;
match = of_match_device(of_match_ptr(omap_gpio_match), dev);
@@ -1186,6 +1177,18 @@ static int omap_gpio_probe(struct platform_device *pdev)
return -ENOMEM;
}
+ irqc = devm_kzalloc(dev, sizeof(*irqc), GFP_KERNEL);
+ if (!irqc)
+ return -ENOMEM;
+
+ irqc-irq_shutdown = omap_gpio_irq_shutdown,
+ irqc-irq_ack = omap_gpio_ack_irq,
+ irqc-irq_mask = omap_gpio_mask_irq,
+ irqc-irq_unmask = omap_gpio_unmask_irq,
+ irqc-irq_set_type = omap_gpio_irq_type,
+ irqc-irq_set_wake = omap_gpio_wake_enable,
+ irqc-name = dev_name(pdev-dev);
+
res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
if (unlikely(!res)) {
dev_err(dev, Invalid IRQ resource\n);
@@ -1241,7 +1244,7 @@ static int omap_gpio_probe(struct platform_device *pdev)
omap_gpio_mod_init(bank);
- ret = omap_gpio_chip_init(bank);
+ ret = omap_gpio_chip_init(bank, irqc);
if (ret)
return ret;
--
1.7.9.5
--
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 2/3] Documentation: dt-bindings: mfd: palmas: document optional wakeup IRQ
With the recent pinctrl-single changes, SoCs such as OMAP family can
treat wake-up events from deeper low power states as interrupts.
This is usable when the wakeup from deeper low power states is
triggered by a different hardware mechanism tied to pinctrl compared
to the routine interrupt handling generating the reqular interrupt
events. This is usually done on SoCs where the routine interrupt
sources such as GPIO need to be disabled to be actually achieve low
power state and wakeup is triggered from pinctrl interrupt source.
Provide documentation example for the case where the system needs two
interrupt sources when SoC is in deep sleep(1 to exit from deep sleep,
and other from the module handling the actual event).
Signed-off-by: Nishanth Menon n...@ti.com
---
Documentation/devicetree/bindings/mfd/palmas.txt | 20
1 file changed, 20 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/palmas.txt
b/Documentation/devicetree/bindings/mfd/palmas.txt
index d193859..1c821d6 100644
--- a/Documentation/devicetree/bindings/mfd/palmas.txt
+++ b/Documentation/devicetree/bindings/mfd/palmas.txt
@@ -51,3 +51,23 @@ palmas@48 {
};
}
+
+Example: With interrupts extended
+ See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
+ Use pinmux 0x418 as wakeup interrupt and gpio1_0 as interrupt source
+
+palmas@48 {
+ compatible = ti,twl6035, ti,palmas;
+ reg = 0x48
+ interrupt-parent = intc;
+ interrupt-controller;
+ #interrupt-cells = 2;
+ #address-cells = 1;
+ #size-cells = 0;
+ interrupts-extended = gpio1 0 IRQ_TYPE_LEVEL_HIGH,
+ pinmux 0x418;
+ pmic {
+ compatible = ti,twl6035-pmic, ti,palmas-pmic;
+
+ };
+}
--
1.7.9.5
--
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/3] Documentation: dt-bindings: mfd: palmas: Fix example style of i2c peripheral
Use device@address as name for device nodes.
Suggested-by: Lee Jones lee.jo...@linaro.org
Signed-off-by: Nishanth Menon n...@ti.com
---
Documentation/devicetree/bindings/mfd/palmas.txt |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/mfd/palmas.txt
b/Documentation/devicetree/bindings/mfd/palmas.txt
index eda8989..d193859 100644
--- a/Documentation/devicetree/bindings/mfd/palmas.txt
+++ b/Documentation/devicetree/bindings/mfd/palmas.txt
@@ -33,7 +33,7 @@ Optional properties:
Example:
-palmas {
+palmas@48 {
compatible = ti,twl6035, ti,palmas;
reg = 0x48
interrupt-parent = intc;
--
1.7.9.5
--
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 0/3] mfd: palmas: add optional wakeup irq
Hi, V2 of the series based on review conclusion in https://patchwork.kernel.org/patch/4743321/ based on v3.17-rc1 Wakeup irq is a interrupt path which is provided by the pinctrl hardware of certain SoCs such as TI's OMAP family of processors that generates an interrupt for waking up from deep power saving modes. Nishanth Menon (3): Documentation: dt-bindings: mfd: palmas: Fix example style of i2c peripheral Documentation: dt-bindings: mfd: palmas: document optional wakeup IRQ mfd: palmas: Add support for optional wakeup Documentation/devicetree/bindings/mfd/palmas.txt | 22 +++- drivers/mfd/palmas.c | 59 ++ include/linux/mfd/palmas.h |2 + 3 files changed, 82 insertions(+), 1 deletion(-) Regards, Nishanth Menon -- 1.7.9.5 -- 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 3/3] mfd: palmas: Add support for optional wakeup
With the recent pinctrl-single changes, omaps can treat wake-up events
from deeper power states as interrupts.
This is to handle the case where the system needs two interrupt
sources when SoC is in deep sleep(1 to exit from deep power mode such
as sleep, and other from the module handling the actual event during
system active state). This is not the same as threaded interrupts as the
wakeup interrupt source is used only as part of deeper power saving
mode.
Let's add support for the optional second interrupt for wake-up
events. And then SoC can wakeup and handle the event using it's
regular handler.
This is similar in approach to commit 2a0b965cfb6e (serial: omap: Add
support for optional wake-up)
Signed-off-by: Nishanth Menon n...@ti.com
---
drivers/mfd/palmas.c | 59
include/linux/mfd/palmas.h |2 ++
2 files changed, 61 insertions(+)
diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c
index 28cb048..11186ab 100644
--- a/drivers/mfd/palmas.c
+++ b/drivers/mfd/palmas.c
@@ -24,6 +24,7 @@
#include linux/mfd/core.h
#include linux/mfd/palmas.h
#include linux/of_device.h
+#include linux/of_irq.h
static const struct regmap_config palmas_regmap_config[PALMAS_NUM_CLIENTS] = {
{
@@ -326,6 +327,16 @@ static struct regmap_irq_chip tps65917_irq_chip = {
PALMAS_INT1_MASK),
};
+static irqreturn_t palmas_wake_irq(int irq, void *_palmas)
+{
+ /*
+* Return Not handled so that interrupt is disabled.
+* Level event ensures that the event is eventually handled
+* by the appropriate chip handler already registered
+*/
+ return IRQ_NONE;
+}
+
int palmas_ext_control_req_config(struct palmas *palmas,
enum palmas_external_requestor_id id, int ext_ctrl, bool enable)
{
@@ -409,6 +420,7 @@ static void palmas_dt_to_pdata(struct i2c_client *i2c,
pdata-mux_from_pdata = 1;
pdata-pad2 = prop;
}
+ pdata-wakeirq = irq_of_parse_and_map(node, 1);
/* The default for this register is all masked */
ret = of_property_read_u32(node, ti,power-ctrl, prop);
@@ -521,6 +533,7 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
i2c_set_clientdata(i2c, palmas);
palmas-dev = i2c-dev;
palmas-irq = i2c-irq;
+ palmas-wakeirq = pdata-wakeirq;
match = of_match_device(of_palmas_match_tbl, i2c-dev);
@@ -587,6 +600,22 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
if (ret 0)
goto err_i2c;
+ if (!palmas-wakeirq)
+ goto no_wake_irq;
+
+ ret = devm_request_irq(palmas-dev, palmas-wakeirq,
+ palmas_wake_irq,
+ IRQF_ONESHOT | pdata-irq_flags,
+ dev_name(palmas-dev),
+ palmas);
+ if (ret 0)
+ goto err_i2c;
+
+ /* We use wakeirq only during suspend-resume path */
+ device_set_wakeup_capable(palmas-dev, true);
+ disable_irq_nosync(palmas-wakeirq);
+
+no_wake_irq:
no_irq:
slave = PALMAS_BASE_TO_SLAVE(PALMAS_PU_PD_OD_BASE);
addr = PALMAS_BASE_TO_REG(PALMAS_PU_PD_OD_BASE,
@@ -706,6 +735,34 @@ static int palmas_i2c_remove(struct i2c_client *i2c)
return 0;
}
+static int palmas_i2c_suspend(struct i2c_client *i2c, pm_message_t mesg)
+{
+ struct palmas *palmas = i2c_get_clientdata(i2c);
+ struct device *dev = i2c-dev;
+
+ if (!palmas-wakeirq)
+ return 0;
+
+ if (device_may_wakeup(dev))
+ enable_irq(palmas-wakeirq);
+
+ return 0;
+}
+
+static int palmas_i2c_resume(struct i2c_client *i2c)
+{
+ struct palmas *palmas = i2c_get_clientdata(i2c);
+ struct device *dev = i2c-dev;
+
+ if (!palmas-wakeirq)
+ return 0;
+
+ if (device_may_wakeup(dev))
+ disable_irq_nosync(palmas-wakeirq);
+
+ return 0;
+}
+
static const struct i2c_device_id palmas_i2c_id[] = {
{ palmas, },
{ twl6035, },
@@ -721,6 +778,8 @@ static struct i2c_driver palmas_i2c_driver = {
.of_match_table = of_palmas_match_tbl,
.owner = THIS_MODULE,
},
+ .suspend = palmas_i2c_suspend,
+ .resume = palmas_i2c_resume,
.probe = palmas_i2c_probe,
.remove = palmas_i2c_remove,
.id_table = palmas_i2c_id,
diff --git a/include/linux/mfd/palmas.h b/include/linux/mfd/palmas.h
index fb0390a..e8cf4c2 100644
--- a/include/linux/mfd/palmas.h
+++ b/include/linux/mfd/palmas.h
@@ -75,6 +75,7 @@ struct palmas {
/* IRQ Data */
int irq;
u32 irq_mask;
+ int wakeirq;
struct mutex irq_lock;
struct regmap_irq_chip_data *irq_data;
@@ -377,6 +378,7 @@ struct palmas_clk_platform_data {
struct palmas_platform_data {
int irq_flags;
+ int wakeirq;
int gpio_base;
[PATCH] ARM: dts: am335x-boneblack: Add names for remaining regulators
Add regulator-name properties for the regulators that don't have them,
allowing the kernel to display the name from the schematic rather than
the name of the regulator on the PMIC in order to improve diagnostics.
Signed-off-by: Mark Brown broo...@kernel.org
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index bde1777b62be..fe983d204b2b 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -227,6 +227,7 @@
tps {
regulators {
dcdc1_reg: regulator@0 {
+ regulator-name = vdds_dpr;
regulator-always-on;
};
@@ -249,18 +250,22 @@
};
ldo1_reg: regulator@3 {
+ regulator-name = vio,vrtc,vdds;
regulator-always-on;
};
ldo2_reg: regulator@4 {
+ regulator-name = vdd_3v3aux;
regulator-always-on;
};
ldo3_reg: regulator@5 {
+ regulator-name = vdd_1v8;
regulator-always-on;
};
ldo4_reg: regulator@6 {
+ regulator-name = vdd_3v3a;
regulator-always-on;
};
};
--
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: [PATCH V2 3/3] mfd: palmas: Add support for optional wakeup
On Fri, 5 Sep 2014, Nishanth Menon wrote: + if (!palmas-wakeirq) + goto no_wake_irq; + + ret = devm_request_irq(palmas-dev, palmas-wakeirq, +palmas_wake_irq, +IRQF_ONESHOT | pdata-irq_flags, Why is this marked IRQF_ONESHOT? +dev_name(palmas-dev), +palmas); + if (ret 0) + goto err_i2c; Why err and not doing the obvious clearing of palmas-wakeirq and keep at least the i2c functional? Thanks, tglx -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/10] ARM: OMAP5 / DRA7: Enable CPU RET on suspend
On 14:45-20140827, Nishanth Menon wrote:
On 08/27/2014 02:43 PM, Santosh Shilimkar wrote:
On Wednesday 27 August 2014 03:41 PM, Tony Lindgren wrote:
* Nishanth Menon n...@ti.com [140827 12:05]:
On 08/27/2014 01:58 PM, Kevin Hilman wrote:
Nishanth Menon n...@ti.com writes:
From: Rajendra Nayak rna...@ti.com
On OMAP5 / DRA7, prevent a CPU powerdomain OFF and resulting MPU OSWR
and instead attempt a CPU RET and side effect, MPU RET in suspend.
Signed-off-by: Rajendra Nayak rna...@ti.com
[n...@ti.com: update to do save_state only on DRA7]
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/omap-mpuss-lowpower.c |4
arch/arm/mach-omap2/omap-wakeupgen.c |2 +-
arch/arm/mach-omap2/pm44xx.c |9 +++--
3 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 207fce2..0d640eb 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -242,6 +242,10 @@ int omap4_enter_lowpower(unsigned int cpu,
unsigned int power_state)
save_state = 1;
break;
case PWRDM_POWER_RET:
+ if (soc_is_omap54xx() || soc_is_dra7xx()) {
Aren't we trying to get away from these soc_* checks for anything other
than init code?
I would expect that to take place in stages as part of which the next
level of cleanup is to move PRM into drivers. Currently our wakeupgen,
prm code does have quiet a few needs of dealing with soc_is checks
primarily from having to re-architect code in two different directions
- we want to move into just one direction eventually - to prm drivers
and as less code in mach-omap2 which is already in the works.
Why don't you just set some flag at init time based on the
soc_is check and then test that here? That limits the use of
soc_is to init code only which makes it easier to phase it
out completely eventually.
Indeed. Infact the version of the code I tried posting last year was
using a flag which was initialised during init. Same can be
done her.
OK. will try something along that line in the next rev.
Hi,
Updated patch below:
Do let me know if this is ok with folks.
---8
From 1b9e11834dac2bd75c396aa7495c806b027653fe Mon Sep 17 00:00:00 2001
From: Rajendra Nayak rna...@ti.com
Date: Mon, 27 May 2013 15:46:44 +0530
Subject: [PATCH V2 7/10] ARM: OMAP5 / DRA7: Enable CPU RET on suspend
On OMAP5 / DRA7, prevent a CPU powerdomain OFF and resulting MPU OSWR
and instead attempt a CPU RET and side effect, MPU RET in suspend.
NOTE: the hardware was originally designed to be capable of achieving
deep power states such as OFF and OSWR, however due to various issues
and risks, deepest valid state was determined to be CSWR - hence we use
the errata framework to handle this case.
Signed-off-by: Rajendra Nayak rna...@ti.com
[n...@ti.com: updates]
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/omap-mpuss-lowpower.c |4
arch/arm/mach-omap2/omap-wakeupgen.c |3 ++-
arch/arm/mach-omap2/pm.h |1 +
arch/arm/mach-omap2/pm44xx.c | 12 ++--
4 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 207fce2..297352f 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -242,6 +242,10 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int
power_state)
save_state = 1;
break;
case PWRDM_POWER_RET:
+ if (IS_PM44XX_ERRATUM(PM_OMAP4_CPU_OSWR_DISABLE)) {
+ save_state = 0;
+ break;
+ }
default:
/*
* CPUx CSWR is invalid hardware state. Also CPUx OSWR
diff --git a/arch/arm/mach-omap2/omap-wakeupgen.c
b/arch/arm/mach-omap2/omap-wakeupgen.c
index e844e16..f961c46 100644
--- a/arch/arm/mach-omap2/omap-wakeupgen.c
+++ b/arch/arm/mach-omap2/omap-wakeupgen.c
@@ -32,6 +32,7 @@
#include soc.h
#include omap4-sar-layout.h
#include common.h
+#include pm.h
#define AM43XX_NR_REG_BANKS7
#define AM43XX_IRQS224
@@ -381,7 +382,7 @@ static struct notifier_block irq_notifier_block = {
static void __init irq_pm_init(void)
{
/* FIXME: Remove this when MPU OSWR support is added */
- if (!soc_is_omap54xx())
+ if (!IS_PM44XX_ERRATUM(PM_OMAP4_CPU_OSWR_DISABLE))
cpu_pm_register_notifier(irq_notifier_block);
}
#else
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index e150102..425bfcd 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -101,6 +101,7 @@ static inline void
enable_omap3630_toggle_l2_on_restore(void) { }
#endif /*
Re: [PATCH 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support
Daniel,
On 13:22-20140827, Kevin Hilman wrote:
Santosh Shilimkar santosh.shilim...@ti.com writes:
On Wednesday 27 August 2014 03:35 PM, Nishanth Menon wrote:
On Wed, Aug 27, 2014 at 2:13 PM, Kevin Hilman
khil...@deeprootsystems.com wrote:
+ Daniel (cpuidle maintainer)
[...]
+static int omap_enter_idle_smp(struct cpuidle_device *dev,
+struct cpuidle_driver *drv,
+int index)
+{
+ struct idle_statedata *cx = state_ptr + index;
+ unsigned long flag;
+
+ raw_spin_lock_irqsave(mpu_lock, flag);
+ cx-mpu_state_vote++;
+ if (cx-mpu_state_vote == num_online_cpus()) {
+ pwrdm_set_logic_retst(mpu_pd, cx-mpu_logic_state);
+ omap_set_pwrdm_state(mpu_pd, cx-mpu_state);
+ }
+ raw_spin_unlock_irqrestore(mpu_lock, flag);
+
+ omap4_enter_lowpower(dev-cpu, cx-cpu_state);
+
+ raw_spin_lock_irqsave(mpu_lock, flag);
+ if (cx-mpu_state_vote == num_online_cpus())
+ omap_set_pwrdm_state(mpu_pd, PWRDM_POWER_ON);
+ cx-mpu_state_vote--;
+ raw_spin_unlock_irqrestore(mpu_lock, flag);
+
+ return index;
+}
Hmm, maybe OMAP5/DRA7 CPUidle driver should be a new one based on MCPM?
Trying to understand benefit of MCPM here - at least without a deeper
understanding of mcpm infrastructure benefits (first look seemed a
little heavy for OMAP5/DRA7 needs).
Neither DRA7/OMAP5 are multi-cluster, the SoCs are not targetted for
OFF of CPU1/0, we have mercury hardware to help with context and
sync issues.
Being able to reuse most of existing OMAP4 infrastructure code is
useful as well to leave the existing omap4 framework as being lighter
in complexity -esp in a cpuidle like hot path?
The spin_lock is only for the programming of MPU power domain in a
consistent manner - I suppose might have been the trigger for
proposing mcpm?
Mostly not
I think this is coming because last time Nicolas Pitre tried to convert
the OMAP CPUIdle into MCPM but because of various ordering requirements,
OMAP wasn't suitable and then the plan was dropped later.
Just to make clear, OMAP OMAP5/DRA7 as well the ordering requirement
remains the same for deeper states. Its just the mercury retention state
which we are able to enter without ordering requirements and hence
the voting scheme.
Ah, OK. This is the part that I'm missing. So for deeper states you'll
need to be using omap_enter_idle_coupled()
Hope this clarifies to you as well as Kevin just in case he missed the
part of the deeper C-states requirements.
Yes, thanks for clarifying.
That being said, I think MCPM can now do essentially what the coupled
states code is doing. Even so, that's probably not a reason to hold up
this patch, but Daniel gets to make that call.
Gentle ping.. You can find the discussion and the patch here:
https://patchwork.kernel.org/patch/4764661/
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/10] ARM: OMAP5 / DRA7: Enable CPU RET on suspend
* Nishanth Menon n...@ti.com [140905 14:16]:
On 14:45-20140827, Nishanth Menon wrote:
On 08/27/2014 02:43 PM, Santosh Shilimkar wrote:
On Wednesday 27 August 2014 03:41 PM, Tony Lindgren wrote:
* Nishanth Menon n...@ti.com [140827 12:05]:
On 08/27/2014 01:58 PM, Kevin Hilman wrote:
Nishanth Menon n...@ti.com writes:
From: Rajendra Nayak rna...@ti.com
On OMAP5 / DRA7, prevent a CPU powerdomain OFF and resulting MPU OSWR
and instead attempt a CPU RET and side effect, MPU RET in suspend.
Signed-off-by: Rajendra Nayak rna...@ti.com
[n...@ti.com: update to do save_state only on DRA7]
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/omap-mpuss-lowpower.c |4
arch/arm/mach-omap2/omap-wakeupgen.c |2 +-
arch/arm/mach-omap2/pm44xx.c |9 +++--
3 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 207fce2..0d640eb 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -242,6 +242,10 @@ int omap4_enter_lowpower(unsigned int cpu,
unsigned int power_state)
save_state = 1;
break;
case PWRDM_POWER_RET:
+ if (soc_is_omap54xx() || soc_is_dra7xx()) {
Aren't we trying to get away from these soc_* checks for anything other
than init code?
I would expect that to take place in stages as part of which the next
level of cleanup is to move PRM into drivers. Currently our wakeupgen,
prm code does have quiet a few needs of dealing with soc_is checks
primarily from having to re-architect code in two different directions
- we want to move into just one direction eventually - to prm drivers
and as less code in mach-omap2 which is already in the works.
Why don't you just set some flag at init time based on the
soc_is check and then test that here? That limits the use of
soc_is to init code only which makes it easier to phase it
out completely eventually.
Indeed. Infact the version of the code I tried posting last year was
using a flag which was initialised during init. Same can be
done her.
OK. will try something along that line in the next rev.
Hi,
Updated patch below:
Looks OK to me 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
