[GIT PULL] omap fixes against v3.17-rc3
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. Felipe Balbi (1): ARM: dts: am4372: fix USB regs size Lokesh Vutla (1): ARM: dts: dra7-evm: Add vtt regulator support Nishanth Menon (2): ARM: dts: am437x-gp: switch i2c0 to 100KHz ARM: dts: dra7-evm: Fix spi1 mux documentation Roger Quadros (8): ARM: dts: dra7-evm: Fix i2c3 pinmux and frequency ARM: dts: dra7-evm: Fix 8th NAND partition's name ARM: dts: am43x-epos-evm: Use BCH16 ECC scheme instead of BCH8 ARM: dts: am437x-gp-evm: Use BCH16 ECC scheme instead of BCH8 ARM: dts: am437x-gp-evm: Don't use read/write wait monitoring ARM: dts: am43xx-epos-evm: Don't use read/write wait monitoring ARM: OMAP2+: gpmc: Don't complain if wait pin is used without r/w monitoring ARM: dts: am43x-epos-evm: Disable QSPI to prevent conflict with GPMC-NAND Stefan Herbrechtsmeier (1): ARM: dts: set 'ti,set-rate-parent' for dpll4_m5x2 clock Tony Lindgren (1): Merge branch 'for-v3.17-rc/ti-clk-dt' of github.com:t-kristo/linux-pm into fixes-rc3 arch/arm/boot/dts/am4372.dtsi | 4 +-- arch/arm/boot/dts/am437x-gp-evm.dts| 6 ++--- arch/arm/boot/dts/am43x-epos-evm.dts | 9 +++ arch/arm/boot/dts/dra7-evm.dts | 47 ++ arch/arm/boot/dts/omap3xxx-clocks.dtsi | 1 + arch/arm/mach-omap2/gpmc.c | 7 +++-- 6 files changed, 48 insertions(+), 26 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
[PATCHv2 1/2] iommu/omap: Check for valid archdata in attach_dev
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
---
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 */
--
2.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 2/2] iommu/omap: Fix iommu archdata name for DT-based devices
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
---
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
#include
#include
+#include
#include
@@ -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);
--
2.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 0/2] OMAP IOMMU Fixes for DT-clients
Hi, This is an updated series addressing Laurent's review comments on Patch1. Patch2 is unchanged from the previous series. Patches are based on 3.17-rc3. v1: http://marc.info/?l=linux-omap&m=140978874026176&w=2 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(-) -- 2.0.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 1/2] usb: rename phy to usb_phy in HCD
From: Antoine Tenart
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
[Sergei: added missing 'drivers/usb/misc/lvstest.c' file, resolved rejects
caused by patch reordering, updated changelog.]
Signed-off-by: Sergei Shtylyov
Acked-by: Alan Stern
---
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 usb_hcd_fsl_probe(const struc
if (pdata->operating_mode == FSL_USB2_DR_OTG) {
struct ehci_hcd *ehci = hcd_to_ehci(hcd);
-
[PATCH v5 0/2] Add generic PHY support to USB HCD
Hello. This patchset is against the usb-next' branch of Greg KH's 'usb.git' repo. Here I add support for the generic PHY to the 'struct usb_hcd' (having to rename the existing 'phy' field to 'usb_phy' beforehand). This was mainly intended to be used with the PCI OHCI/EHCI drivers and also xHCI driver; however there are several more dependent patchsets now posted to 'linux-usb'. Greg, if you want links to these patchsets and the device tree patches using this patchset in order to link the PCI OHCI/EHCI devices to the PHY, just ask (I have already posted the previously but will probably have to repost them again)... [1/2] usb: rename phy to usb_phy in HCD [2/2] usb: hcd: add generic PHY support WBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] iommu/omap: Fix iommu archdata name for DT-based devices
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
>> ---
>> 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
>> #include
>> #include
>> +#include
>>
>> #include
>>
>> @@ -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. 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-kernel&m=140968072117851&w=2?
regards
Suman
>
>> +
>> 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);
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] ARM: dts: dra7-evm: fixes for mux and VTT control
* Nishanth Menon [140904 06:24]: > Hi, > > The following series was inspired in part by > http://marc.info/?l=linux-omap&m=140974309205295&w=2 > causing me to try and do an audit of pinctrl configurations on the platform. > > Further, failures on latest board updates in the automated farm also > caused identification of a fix which was yet to be send to upstream > from product kernel. Slightly unrelated patches in this series. > > So here they are.. > based on v3.17-rc1: > before-dra7xx-evm: Boot FAIL: http://paste.ubuntu.org.cn/1477597 > (fails can be at different times though.. random crashes without VTT is > usual).. > after-dra7xx-evm: Boot PASS: http://paste.ubuntu.org.cn/1477596 Thanks applying both into omap-for-v3.17/fixes-v2. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] OMAP2+: GPMC: NAND fixes for 3.17
* pekon [140904 12:01]: > Hi Tony, > > On Thursday 04 September 2014 03:12 AM, Tony Lindgren wrote: > >* Tony Lindgren [140903 14:41]: > >>* Roger Quadros [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 OK thanks will apply all into omap-for-v3.17/fixes-v2. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] iommu/omap: Check for valid archdata in attach_dev
Hi Laurent,
> On Wednesday 03 September 2014 18:58:31 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 non-NULL 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
>> ---
>> drivers/iommu/omap-iommu.c | 6 ++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
>> index 02ef0ac..f245d51 100644
>> --- a/drivers/iommu/omap-iommu.c
>> +++ b/drivers/iommu/omap-iommu.c
>> @@ -1092,6 +1092,12 @@ omap_iommu_attach_dev(struct iommu_domain *domain,
>> struct device *dev)
>>
>> spin_lock(&omap_domain->lock);
>>
>> +if (!arch_data) {
>> +dev_err(dev, "device doesn't have an associated iommu\n");
>> +ret = -EINVAL;
>> +goto out;
>> +}
>
> You can move this check outside of the spinlock-protected section. With that
> change,
Thanks, will fix this in the next revision, will also add the check for
the name field.
regards
Suman
>
> Acked-by: Laurent Pinchart
>
>> +
>> /* only a single device is supported per domain for now */
>> if (omap_domain->iommu_dev) {
>> dev_err(dev, "iommu domain is already attached\n");
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] ARM: dts: am437x-gp-evm: Don't use read/write wait monitoring
On Thursday 04 September 2014 03:16 PM, Roger Quadros wrote: [...] This patch is for the 3.17 bug fix cycle. Implementing NAND device ready mechanism is a new feature (for DT case) and I will work on it for future versions. Also I'm not de-scoping wait-pin (or more correctly device ready) mechanism for NAND. The dts file still contains "wait-pin = <0>" property. This will be used to monitor the NAND device ready status via GPMC status or GPMC interrupt. But this is not for 3.17 bug fix cycle. Ok Thanks, that good to know. So for this whole series Reviewed-by: Pekon Gupta with regards, pekon Powered by BigRock.com -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] OMAP2+: GPMC: NAND fixes for 3.17
Hi Tony, On Thursday 04 September 2014 03:12 AM, Tony Lindgren wrote: * Tony Lindgren [140903 14:41]: * Roger Quadros [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 with regards, pekon Powered by BigRock.com -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] usb: phy: twl4030-usb: Move code from twl4030_phy_power to the runtime PM calls
* Kishon Vijay Abraham I [140904 06:51]: > Hi Tony, > > On Thursday 28 August 2014 04:58 AM, Tony Lindgren wrote: > > We don't need twl4030_phy_power() any longer now that we have > > the runtime PM calls. Let's get rid of it as it's confusing. > > No functional changes, just move the code and use res instead > > of ret as we are not returning that value. > > Now that you are doing pm_runtime_get_sync in twl4030_phy_init, won't it power > on the phy even before initializing it (since runtime_resume will be invoked > even before doing phy_init)? Yes. The logic being that it should not matter as we are not configuring the phy until in twl4030_phy_power_on(). Maybe we should add code to make sure the phy is deconfigured initially though :) In twl4030_phy_init() we just want to check the ID pin state to get things right initially. In the twl4030-usb case the I2C chip is always on, but let's try to get the runtime PM set up like any standard Linux driver would do it to avoid confusion. > Even if pm_runtime_get_sync in not done in twl4030_phy_init, phy-core itself > does pm_runtime_get_sync in phy_init(). Hmm OK. Looking at that, looks like we don't neeed any of these custom exports though: $ git grep phy_pm_runtime | grep EXPORT_SYMBOL drivers/phy/phy-core.c:EXPORT_SYMBOL_GPL(phy_pm_runtime_get); drivers/phy/phy-core.c:EXPORT_SYMBOL_GPL(phy_pm_runtime_get_sync); drivers/phy/phy-core.c:EXPORT_SYMBOL_GPL(phy_pm_runtime_put); drivers/phy/phy-core.c:EXPORT_SYMBOL_GPL(phy_pm_runtime_put_sync); drivers/phy/phy-core.c:EXPORT_SYMBOL_GPL(phy_pm_runtime_allow); drivers/phy/phy-core.c:EXPORT_SYMBOL_GPL(phy_pm_runtime_forbid); The reasons why I think we don't need the above at all is: 1. We already have a framework for that in Linux runtime PM and we can follow the standard Linux runtime PM calls and not proxy them in phy-core.c 2. We can allow idling the phy properly on the bus it's connected to, in this case I2C, even if USB driver is not loaded. We eventually should idle the phy even if usb_add_phy_dev() failed 3. There's no actual need for phy-core.c to proxy the runtime PM calls So we can and should just let the phy drivers do their own runtime PM as needed based on just the phy init, power_on and power_off calls. Probably the same goes for the regulator_enable in phy-core.c. That should be handled in the phy driver as phy-core is already unable to handle it properly. For example, for phy-twl4030-usb.c we have three regulators to deal with and the phy framework won't have any idea how to deal with those. And the phy-core won't be able to deal with the phy driver interrupts anyways, so any attempt of doing finer grained runtime PM in phy-core or handling of separate wake-up interrupts will be doomed to fail. I think the changes above would simplify the phy handling quite a bit, what do you think? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] mfd: ti_am335x_tscadc: Update logic in CTRL register for 5-wire TS
From: Jeff Lance
The logic in AFE_Pen_Ctrl bitmask in the CTRL register is different for five
wire versus four or eight wire touschscreens. This patch should fix this for
five-wire touch screens. There should be no change needed here for four and
eight wire tousch screens.
Signed-off-by: Jeff Lance
[bigeasy: keep the change mfd only]
Signed-off-by: Sebastian Andrzej Siewior
---
I've been looking at moving this piece and the idle mode setting into the
TSC driver. Kinda odd that I have to patch within the MFD driver for this
TSC related change.
Anyone disagrees?
drivers/mfd/ti_am335x_tscadc.c | 30 +-
include/linux/mfd/ti_am335x_tscadc.h | 1 +
2 files changed, 18 insertions(+), 13 deletions(-)
diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c
index dd4bf5816221..6c9cfb8c1d01 100644
--- a/drivers/mfd/ti_am335x_tscadc.c
+++ b/drivers/mfd/ti_am335x_tscadc.c
@@ -241,18 +241,20 @@ staticint ti_tscadc_probe(struct platform_device
*pdev)
tscadc_writel(tscadc, REG_CLKDIV, tscadc->clk_div);
/* Set the control register bits */
- ctrl = CNTRLREG_STEPCONFIGWRT |
- CNTRLREG_STEPID;
- if (tsc_wires > 0)
- ctrl |= CNTRLREG_4WIRE | CNTRLREG_TSCENB;
+ ctrl = CNTRLREG_STEPCONFIGWRT | CNTRLREG_STEPID;
tscadc_writel(tscadc, REG_CTRL, ctrl);
/* Set register bits for Idle Config Mode */
- if (tsc_wires > 0)
+ if (tsc_wires > 0) {
+ tscadc->tsc_wires = tsc_wires;
+ if (tsc_wires == 5)
+ ctrl |= CNTRLREG_5WIRE | CNTRLREG_TSCENB;
+ else
+ ctrl |= CNTRLREG_4WIRE | CNTRLREG_TSCENB;
tscadc_idle_config(tscadc);
+ }
/* Enable the TSC module enable bit */
- ctrl = tscadc_readl(tscadc, REG_CTRL);
ctrl |= CNTRLREG_TSCSSENB;
tscadc_writel(tscadc, REG_CTRL, ctrl);
@@ -324,21 +326,23 @@ static int tscadc_suspend(struct device *dev)
static int tscadc_resume(struct device *dev)
{
struct ti_tscadc_dev*tscadc_dev = dev_get_drvdata(dev);
- unsigned int restore, ctrl;
+ u32 ctrl;
pm_runtime_get_sync(dev);
/* context restore */
ctrl = CNTRLREG_STEPCONFIGWRT | CNTRLREG_STEPID;
- if (tscadc_dev->tsc_cell != -1)
- ctrl |= CNTRLREG_TSCENB | CNTRLREG_4WIRE;
tscadc_writel(tscadc_dev, REG_CTRL, ctrl);
- if (tscadc_dev->tsc_cell != -1)
+ if (tscadc_dev->tsc_cell != -1) {
+ if (tscadc_dev->tsc_wires == 5)
+ ctrl |= CNTRLREG_5WIRE | CNTRLREG_TSCENB;
+ else
+ ctrl |= CNTRLREG_4WIRE | CNTRLREG_TSCENB;
tscadc_idle_config(tscadc_dev);
- restore = tscadc_readl(tscadc_dev, REG_CTRL);
- tscadc_writel(tscadc_dev, REG_CTRL,
- (restore | CNTRLREG_TSCSSENB));
+ }
+ ctrl |= CNTRLREG_TSCSSENB;
+ tscadc_writel(tscadc_dev, REG_CTRL, ctrl);
tscadc_writel(tscadc_dev, REG_CLKDIV, tscadc_dev->clk_div);
diff --git a/include/linux/mfd/ti_am335x_tscadc.h
b/include/linux/mfd/ti_am335x_tscadc.h
index fb96c84dada5..e2e70053470e 100644
--- a/include/linux/mfd/ti_am335x_tscadc.h
+++ b/include/linux/mfd/ti_am335x_tscadc.h
@@ -155,6 +155,7 @@ struct ti_tscadc_dev {
void __iomem *tscadc_base;
int irq;
int used_cells; /* 1-2 */
+ int tsc_wires;
int tsc_cell; /* -1 if not used */
int adc_cell; /* -1 if not used */
struct mfd_cell cells[TSCADC_CELLS];
--
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] mfd: twl4030-power: Fix PM idle pin configuration to not conflict with regulators
* Sebastian Andrzej Siewior [140904 01:46]: > On 09/03/2014 08:39 PM, Tony Lindgren wrote: > >> good.txt and bad.txt are from the late_initcall. > >> > >> $ diff -u good.txt bad.txt > >> --- good.txt2014-09-03 10:29:58.920317368 +0200 > >> +++ bad.txt 2014-09-03 10:28:57.064313222 +0200 > > > > Hmm can you check that you have good.txt and bad.txt the > > right way? I'd assume you need VAUX2 or VAUX3 enabled > > not disabled for the MMC to work? > > No, it was correct. If you look at the complete file you will notice > the - which removes the mmc detect/mount in the bad case and + which > adds the -110 error ... > With that patch it seems it is a little harder to trigger. It is > usually every other boot that fails. Here a diff between two that > worked (say good-v1 vs good-v2): ... > It took mmc a little longer to detect but it worked. And the content of > the three registers seem not to matter _or_ it was dumped before MMC > got active. ... > I didn't change a thing, I just pressed reset. As you see the content > of the TWL registers don't seem to be that important since it was the > same at the time of the dump. And the mmc didn't came back. OK. I guess that means that it's most likely some timing related issue, or an issue with some regulator not being ready by the time the MMC probes. Or it's a bug somewhere that I'm not figuring out. Looking at the twl-regulator.c, twl4030reg_enable just sets the group bit and we're not checking any status and don't have startup-delay-us for them. At least phy-twl4030-usb.c has twl4030_i2c_write_u8_verify(), I wonder if adding a read back of the register to twl-regulator.c would help? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 15/15] tty: serial: 8250: omap: add dma support
* Sebastian Andrzej Siewior [140904 07:56]: > On 09/04/2014 04:52 PM, Tony Lindgren wrote: > > Yeah makes sense to me. Thanks for ensuring the bug > > compability :) > > Thanks. What about the ttyOx vs ttySx. Do you want me to add kernel > line fixup somewhere arch/arm or we ignore this for now? Greg didn't > say anything… I suggest we have both drivers just available first and then attempt to deal with the removal of most of omap-serial later on. If both drivers are present, we should try to ensure 8250 gets probed first which I believe it already does based on the Makefile order. Once the 8250 based driver is known to work, it might make sense to remove most of the functions in omap-serial and have it use the 8250 functions too to remove duplicate code. That might be already enough and no proxying is needed and we get rid of the duplicate code :) Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: dts: cm-t54: fix serial console power supply.
On Thu, 4 Sep 2014, Dmitry Lifshitz wrote:
> LDO8 regulator is used for act led and serial cosole power supply.
>
> Its DT status is declared as "disabled", however the serial console was
> functional until Commit 318dbb02b ("regulator: palmas: Fix SMPS
> enable/disable/is_enabled") wich properly turns off LDO8 on boot.
>
> Fix serial cosole power supply (and act led) on boot by turning LDO8 on.
>
> Signed-off-by: Dmitry Lifshitz
Tested-by: Paul Walmsley
- 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 15/15] tty: serial: 8250: omap: add dma support
On 09/04/2014 04:52 PM, Tony Lindgren wrote: > Yeah makes sense to me. Thanks for ensuring the bug > compability :) Thanks. What about the ttyOx vs ttySx. Do you want me to add kernel line fixup somewhere arch/arm or we ignore this for now? Greg didn't say anything… > > Regards, > > Tony > 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
Re: [PATCH 15/15] tty: serial: 8250: omap: add dma support
* Sebastian Andrzej Siewior [140904 06:46]: > On 09/03/2014 07:48 PM, Tony Lindgren wrote: > > I will check this upper part of this email soon… > > > OK. At least it's starting to now sound that the bugs are pretty much > > the same with 8250 and serial-omap :) > > Do you see a reason for not posting the entire series again since now I > am bug compatible in the pm-runtime part? We have -rc3 and I would like > to get this merge the series I have now and this seems to be the only > problem I am aware of. Yeah makes sense to me. Thanks for ensuring the bug compability :) Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] input: ti_am335x_tsc: Remove DT wire-config parameter
From: Jeff Lance
With the touschscreen in am335x, you do not have the option to mux the
analog input lines. You must connect the analog input to the corresponding
touchscreen terminal.
This patch removes the code that is parsing the ti,wire-config and uses
the "default" parameters instead.
In short,
inp_xp => STEPCONFIG_INP(0)
inp_xn => STEPCONFIG_INP(1)
inp_yp => STEPCONFIG_INP(2)
inp_yn => STEPCONFIG_INP(3)
bit_xp => STEPCONFIG_XPP
bit_xn => STEPCONFIG_XNN
bit_yp => STEPCONFIG_YPP
bit_yn => STEPCONFIG_YNN
Cc: "Benoît Cousson"
Cc: Tony Lindgren
Signed-off-by: Jeff Lance
[bigeasy: refresh, drop AIN defines.]
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/input/touchscreen/ti_am335x_tsc.c | 109 +-
1 file changed, 16 insertions(+), 93 deletions(-)
diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c
b/drivers/input/touchscreen/ti_am335x_tsc.c
index 092fa8b31c67..92fb473621b0 100644
--- a/drivers/input/touchscreen/ti_am335x_tsc.c
+++ b/drivers/input/touchscreen/ti_am335x_tsc.c
@@ -33,13 +33,6 @@
#define SEQ_SETTLE 275
#define MAX_12BIT ((1 << 12) - 1)
-static const int config_pins[] = {
- STEPCONFIG_XPP,
- STEPCONFIG_XNN,
- STEPCONFIG_YPP,
- STEPCONFIG_YNN,
-};
-
struct titsc {
struct input_dev*input;
struct ti_tscadc_dev*mfd_tscadc;
@@ -48,9 +41,6 @@ struct titsc {
unsigned intx_plate_resistance;
boolpen_down;
int coordinate_readouts;
- u32 config_inp[4];
- u32 bit_xp, bit_xn, bit_yp, bit_yn;
- u32 inp_xp, inp_xn, inp_yp, inp_yn;
u32 step_mask;
};
@@ -65,58 +55,6 @@ static void titsc_writel(struct titsc *tsc, unsigned int reg,
writel(val, tsc->mfd_tscadc->tscadc_base + reg);
}
-static int titsc_config_wires(struct titsc *ts_dev)
-{
- u32 analog_line[4];
- u32 wire_order[4];
- int i, bit_cfg;
-
- for (i = 0; i < 4; i++) {
- /*
-* Get the order in which TSC wires are attached
-* w.r.t. each of the analog input lines on the EVM.
-*/
- analog_line[i] = (ts_dev->config_inp[i] & 0xF0) >> 4;
- wire_order[i] = ts_dev->config_inp[i] & 0x0F;
- if (WARN_ON(analog_line[i] > 7))
- return -EINVAL;
- if (WARN_ON(wire_order[i] > ARRAY_SIZE(config_pins)))
- return -EINVAL;
- }
-
- for (i = 0; i < 4; i++) {
- int an_line;
- int wi_order;
-
- an_line = analog_line[i];
- wi_order = wire_order[i];
- bit_cfg = config_pins[wi_order];
- if (bit_cfg == 0)
- return -EINVAL;
- switch (wi_order) {
- case 0:
- ts_dev->bit_xp = bit_cfg;
- ts_dev->inp_xp = an_line;
- break;
-
- case 1:
- ts_dev->bit_xn = bit_cfg;
- ts_dev->inp_xn = an_line;
- break;
-
- case 2:
- ts_dev->bit_yp = bit_cfg;
- ts_dev->inp_yp = an_line;
- break;
- case 3:
- ts_dev->bit_yn = bit_cfg;
- ts_dev->inp_yn = an_line;
- break;
- }
- }
- return 0;
-}
-
static void titsc_step_config(struct titsc *ts_dev)
{
unsigned intconfig;
@@ -124,19 +62,17 @@ static void titsc_step_config(struct titsc *ts_dev)
int end_step;
u32 stepenable;
- config = STEPCONFIG_MODE_HWSYNC |
- STEPCONFIG_AVG_16 | ts_dev->bit_xp;
+ config = STEPCONFIG_MODE_HWSYNC | STEPCONFIG_AVG_16 | STEPCONFIG_XPP;
switch (ts_dev->wires) {
case 4:
- config |= STEPCONFIG_INP(ts_dev->inp_yp) | ts_dev->bit_xn;
+ config |= STEPCONFIG_INP(2) | STEPCONFIG_XNN;
break;
case 5:
- config |= ts_dev->bit_yn |
- STEPCONFIG_INP_AN4 | ts_dev->bit_xn |
- ts_dev->bit_yp;
+ config |= STEPCONFIG_YNN | STEPCONFIG_INP_AN4 | STEPCONFIG_XNN |
+ STEPCONFIG_YPP;
break;
case 8:
- config |= STEPCONFIG_INP(ts_dev->inp_yp) | ts_dev->bit_xn;
+ config |= STEPCONFIG_INP(2) | STEPCONFIG_XNN;
break;
}
@@ -147,20 +83,18 @@ static void titsc_step_config(struct titsc *ts_dev)
titsc_writel(ts_dev, REG_STEPDELAY(i), STEPCONFIG_OPENDLY);
}
- config = 0;
- conf
[PATCH 3/3] ARM: DTS: AM335x: Drop TSC's wire-config parameters
From: Jeff Lance
The TSC driver is beeing updated, the parameter is not used anymore. The
AIN lines can not be muxed. All boards use the same value.
This patch updates the Documentation and dts files.
Cc: "Benoît Cousson"
Cc: Tony Lindgren
Cc: devicet...@vger.kernel.org
Signed-off-by: Jeff Lance
[bigeasy: split, add .dts files to the removal]
Signed-off-by: Sebastian Andrzej Siewior
---
.../devicetree/bindings/input/touchscreen/ti-tsc-adc.txt | 10 --
arch/arm/boot/dts/am335x-evm.dts | 1 -
arch/arm/boot/dts/am335x-evmsk.dts | 1 -
arch/arm/boot/dts/am335x-pepper.dts| 1 -
4 files changed, 13 deletions(-)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
index 878549ba814d..eeaf065563c9 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
@@ -15,15 +15,6 @@
Y and 2 for Z (always). This utilises 12
of the 16 software steps available. The
remaining 4 can be used by the ADC.
- ti,wire-config: Different boards could have a different order for
- connecting wires on touchscreen. We need to provide an
- 8 bit number where in the 1st four bits represent the
- analog lines and the next 4 bits represent positive/
- negative terminal on that input line. Notations to
- represent the input lines and terminals resoectively
- is as follows:
- AIN0 = 0, AIN1 = 1 and so on till AIN7 = 7.
- XP = 0, XN = 1, YP = 2, YN = 3.
- child "adc"
ti,adc-channels: List of analog inputs available for ADC.
AIN0 = 0, AIN1 = 1 and so on till AIN7 = 7.
@@ -35,7 +26,6 @@
ti,wires = <4>;
ti,x-plate-resistance = <200>;
ti,coordiante-readouts = <5>;
- ti,wire-config = <0x00 0x11 0x22 0x33>;
};
adc {
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index e2156a583de7..4c0a5eab5ef2 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -640,7 +640,6 @@
ti,wires = <4>;
ti,x-plate-resistance = <200>;
ti,coordinate-readouts = <5>;
- ti,wire-config = <0x00 0x11 0x22 0x33>;
};
adc {
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index df5fee6b6b4b..88d83b25089a 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -671,7 +671,6 @@
ti,wires = <4>;
ti,x-plate-resistance = <200>;
ti,coordinate-readouts = <5>;
- ti,wire-config = <0x00 0x11 0x22 0x33>;
};
};
diff --git a/arch/arm/boot/dts/am335x-pepper.dts
b/arch/arm/boot/dts/am335x-pepper.dts
index 0d35ab64641c..0939ded7eea5 100644
--- a/arch/arm/boot/dts/am335x-pepper.dts
+++ b/arch/arm/boot/dts/am335x-pepper.dts
@@ -502,7 +502,6 @@
ti,wires = <4>;
ti,x-plate-resistance = <200>;
ti,coordinate-readouts = <5>;
- ti,wire-config = <0x00 0x11 0x22 0x33>;
};
adc {
--
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 1/3] Input: ti_am335x_tsc: Fix incorrect step config 5 wire touschscreen
From: Jeff Lance
The step config setting for a 5 wire touchscreen is incorrectly sets the
Y coordinates.
It was broken while we moved to DT. If you look close, the change was:
|- STEPCONFIG_XNP | STEPCONFIG_YPN;
|+ ts_dev->bit_xn | ts_dev->bit_yp;
while bit_xn = STEPCONFIG_XNN and bit_yp = STEPCONFIG_YNN. Not quite the
same :)
Fixes: bb76dc09ddfc ("input: ti_am33x_tsc: Order of TSC wires, made
configurable")
Signed-off-by: Jeff Lance
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/input/touchscreen/ti_am335x_tsc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c
b/drivers/input/touchscreen/ti_am335x_tsc.c
index 2ce649520fe0..092fa8b31c67 100644
--- a/drivers/input/touchscreen/ti_am335x_tsc.c
+++ b/drivers/input/touchscreen/ti_am335x_tsc.c
@@ -157,7 +157,7 @@ static void titsc_step_config(struct titsc *ts_dev)
break;
case 5:
config |= ts_dev->bit_xp | STEPCONFIG_INP_AN4 |
- ts_dev->bit_xn | ts_dev->bit_yp;
+ STEPCONFIG_XNP | STEPCONFIG_YPN;
break;
case 8:
config |= ts_dev->bit_yp | STEPCONFIG_INP(ts_dev->inp_xp);
--
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 3/5] usb: phy: twl4030-usb: Move code from twl4030_phy_power to the runtime PM calls
Hi Tony, On Thursday 28 August 2014 04:58 AM, Tony Lindgren wrote: > We don't need twl4030_phy_power() any longer now that we have > the runtime PM calls. Let's get rid of it as it's confusing. > No functional changes, just move the code and use res instead > of ret as we are not returning that value. Now that you are doing pm_runtime_get_sync in twl4030_phy_init, won't it power on the phy even before initializing it (since runtime_resume will be invoked even before doing phy_init)? Even if pm_runtime_get_sync in not done in twl4030_phy_init, phy-core itself does pm_runtime_get_sync in phy_init(). Thanks Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 15/15] tty: serial: 8250: omap: add dma support
On 09/03/2014 07:48 PM, Tony Lindgren wrote: I will check this upper part of this email soon… > OK. At least it's starting to now sound that the bugs are pretty much > the same with 8250 and serial-omap :) Do you see a reason for not posting the entire series again since now I am bug compatible in the pm-runtime part? We have -rc3 and I would like to get this merge the series I have now and this seems to be the only problem I am aware of. > > Regards, > > Tony 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
Re: [PATCH] ARM: dts: omap5.dtsi: add DSS RFBI node
$subject: ARM: dts: OMAP5: Add DSS RFBI node
On 09/04/2014 01:28 AM, Tomi Valkeinen wrote:
> The RFBI node for OMAP DSS was left out when adding the rest of the DSS
> nodes, because it was not clear how to set up the clocks for the RFBI.
>
> However, it seems that if there is a HWMOD for a device, we also need a
> DT node for it. Otherwise, at boot, we get:
>
> WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2542
> _init+0x464/0x4e0()
> omap_hwmod: dss_rfbi: doesn't have mpu register target base
>
> Now that v3.17-rc3 contains a fix
> (8fd46439e1f5a7f86d76a08733459b74debd9468) for the L3 ICLK required by
> the RFBI, let's add the RFBI node to get rid of the warning.
The usual style is to use the following style:
Commit 8fd46439e1f5 ("ARM: dts: omap54xx-clocks: Fix the l3 and l4
clock rates")
>
> Signed-off-by: Tomi Valkeinen
> ---
> arch/arm/boot/dts/omap5.dtsi | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
> index fc8df1739f39..1e6ff61a7f12 100644
> --- a/arch/arm/boot/dts/omap5.dtsi
> +++ b/arch/arm/boot/dts/omap5.dtsi
> @@ -945,6 +945,15 @@
> clock-names = "fck";
> };
>
> + rfbi: encoder@58002000 {
> + compatible = "ti,omap5-rfbi";
> + reg = <0x58002000 0x100>;
> + status = "disabled";
> + ti,hwmods = "dss_rfbi";
> + clocks = <&dss_dss_clk>, <&l3_iclk_div>;
> + clock-names = "fck", "ick";
> + };
> +
> dsi1: encoder@58004000 {
> compatible = "ti,omap5-dsi";
> reg = <0x58004000 0x200>,
>
before-omap5-evm: http://paste.ubuntu.org.cn/1477659
after-omap5-evm: http://paste.ubuntu.org.cn/1477658
So, yep, no more warning.
--
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 1/2] ARM: dts: dra7-evm: Fix spi1 mux documentation
On 08:23-20140904, Nishanth Menon wrote:
> While auditing the various pin ctrl configurations using the following
> command:
> grep PIN_ arch/arm/boot/dts/dra7-evm.dts|(while read line;
> do
> v=`echo "$line" | sed -e "s/\s\s*/|/g" | cut -d '|' -f1 |
> cut -d 'x' -f2|tr [a-z] [A-Z]`;
> HEX=`echo "obase=16;ibase=16;4A003400+$v"| bc`;
> echo "$HEX ===> $line";
> done)
> against DRA75x/74x NDA TRM revision S(SPRUHI2S August 2014),
> documentation errors were found for spi1 pinctrl. Fix the same.
>
> Fixes: 6e58b8f1daaf1af340fb9309907e5ffa473c7aff ("ARM: dts: DRA7: Add
> the dts files for dra7 SoC and dra7-evm board")
^^^ uggh... apologies.. checkpatch slipped this one.. updated rev below
(wont repost unless requested), Apologies on the spam..
8<
>From db595b941663f634f5f5106cf0092c7c8e998bb4 Mon Sep 17 00:00:00 2001
From: Nishanth Menon
Date: Thu, 4 Sep 2014 08:06:27 -0500
Subject: [PATCH V2 1/2] ARM: dts: dra7-evm: Fix spi1 mux documentation
While auditing the various pin ctrl configurations using the following
command:
grep PIN_ arch/arm/boot/dts/dra7-evm.dts|(while read line;
do
v=`echo "$line" | sed -e "s/\s\s*/|/g" | cut -d '|' -f1 |
cut -d 'x' -f2|tr [a-z] [A-Z]`;
HEX=`echo "obase=16;ibase=16;4A003400+$v"| bc`;
echo "$HEX ===> $line";
done)
against DRA75x/74x NDA TRM revision S(SPRUHI2S August 2014),
documentation errors were found for spi1 pinctrl. Fix the same.
Fixes: 6e58b8f1daaf1af ("ARM: dts: DRA7: Add the dts files for dra7 SoC and
dra7-evm board")
Signed-off-by: Nishanth Menon
---
arch/arm/boot/dts/dra7-evm.dts | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 50f8022..e120fca 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -50,13 +50,13 @@
mcspi1_pins: pinmux_mcspi1_pins {
pinctrl-single,pins = <
- 0x3a4 (PIN_INPUT | MUX_MODE0) /* spi2_clk */
- 0x3a8 (PIN_INPUT | MUX_MODE0) /* spi2_d1 */
- 0x3ac (PIN_INPUT | MUX_MODE0) /* spi2_d0 */
- 0x3b0 (PIN_INPUT_SLEW | MUX_MODE0) /* spi2_cs0 */
- 0x3b4 (PIN_INPUT_SLEW | MUX_MODE0) /* spi2_cs1 */
- 0x3b8 (PIN_INPUT_SLEW | MUX_MODE6) /* spi2_cs2 */
- 0x3bc (PIN_INPUT_SLEW | MUX_MODE6) /* spi2_cs3 */
+ 0x3a4 (PIN_INPUT | MUX_MODE0) /* spi1_sclk */
+ 0x3a8 (PIN_INPUT | MUX_MODE0) /* spi1_d1 */
+ 0x3ac (PIN_INPUT | MUX_MODE0) /* spi1_d0 */
+ 0x3b0 (PIN_INPUT_SLEW | MUX_MODE0) /* spi1_cs0 */
+ 0x3b4 (PIN_INPUT_SLEW | MUX_MODE0) /* spi1_cs1 */
+ 0x3b8 (PIN_INPUT_SLEW | MUX_MODE6) /*
spi1_cs2.hdmi1_hpd */
+ 0x3bc (PIN_INPUT_SLEW | MUX_MODE6) /*
spi1_cs3.hdmi1_cec */
>;
};
--
1.7.9.5
--
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 0/2] ARM: dts: dra7-evm: fixes for mux and VTT control
Hi, The following series was inspired in part by http://marc.info/?l=linux-omap&m=140974309205295&w=2 causing me to try and do an audit of pinctrl configurations on the platform. Further, failures on latest board updates in the automated farm also caused identification of a fix which was yet to be send to upstream from product kernel. Slightly unrelated patches in this series. So here they are.. based on v3.17-rc1: before-dra7xx-evm: Boot FAIL: http://paste.ubuntu.org.cn/1477597 (fails can be at different times though.. random crashes without VTT is usual).. after-dra7xx-evm: Boot PASS: http://paste.ubuntu.org.cn/1477596 Lokesh Vutla (1): ARM: dts: dra7-evm: Add vtt regulator support Nishanth Menon (1): ARM: dts: dra7-evm: Fix spi1 mux documentation arch/arm/boot/dts/dra7-evm.dts | 39 --- 1 file changed, 32 insertions(+), 7 deletions(-) -- 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 2/2] ARM: dts: dra7-evm: Add vtt regulator support
From: Lokesh Vutla
DRA7 evm REV G and later boards uses a vtt regulator for DDR3
termination and this is controlled by gpio7_11. This gpio is
configured in boot loader. gpio7_11, which is only available only on
Pad A22, in previous boards, is connected only to an unused pad on
expansion connector EXP_P3 and is safe to be muxed as GPIO on all
DRA7-evm versions (without a need to spin off another dts file).
Since gpio7_11 is used to control VTT and should not be reset or kept
in idle state during boot up else VTT will be disconnected and DDR
gets corrupted. So, as part of this change, mark gpio7 as no-reset and
no-idle on init.
Signed-off-by: Lokesh Vutla
Signed-off-by: Nishanth Menon
---
arch/arm/boot/dts/dra7-evm.dts | 27 ++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index e120fca..71f0f10 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -8,6 +8,7 @@
/dts-v1/;
#include "dra74x.dtsi"
+#include
/ {
model = "TI DRA742";
@@ -24,9 +25,29 @@
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
};
+
+ vtt_fixed: fixedregulator-vtt {
+ compatible = "regulator-fixed";
+ regulator-name = "vtt_fixed";
+ regulator-min-microvolt = <135>;
+ regulator-max-microvolt = <135>;
+ regulator-always-on;
+ regulator-boot-on;
+ enable-active-high;
+ gpio = <&gpio7 11 GPIO_ACTIVE_HIGH>;
+ };
};
&dra7_pmx_core {
+ pinctrl-names = "default";
+ pinctrl-0 = <&vtt_pin>;
+
+ vtt_pin: pinmux_vtt_pin {
+ pinctrl-single,pins = <
+ 0x3b4 (PIN_OUTPUT | MUX_MODE14) /* spi1_cs1.gpio7_11 */
+ >;
+ };
+
i2c1_pins: pinmux_i2c1_pins {
pinctrl-single,pins = <
0x400 (PIN_INPUT | MUX_MODE0) /* i2c1_sda */
@@ -54,7 +75,6 @@
0x3a8 (PIN_INPUT | MUX_MODE0) /* spi1_d1 */
0x3ac (PIN_INPUT | MUX_MODE0) /* spi1_d0 */
0x3b0 (PIN_INPUT_SLEW | MUX_MODE0) /* spi1_cs0 */
- 0x3b4 (PIN_INPUT_SLEW | MUX_MODE0) /* spi1_cs1 */
0x3b8 (PIN_INPUT_SLEW | MUX_MODE6) /*
spi1_cs2.hdmi1_hpd */
0x3bc (PIN_INPUT_SLEW | MUX_MODE6) /*
spi1_cs3.hdmi1_cec */
>;
@@ -504,3 +524,8 @@
&usb2_phy2 {
phy-supply = <&ldousb_reg>;
};
+
+&gpio7 {
+ ti,no-reset-on-init;
+ ti,no-idle-on-init;
+};
--
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 1/2] ARM: dts: dra7-evm: Fix spi1 mux documentation
While auditing the various pin ctrl configurations using the following
command:
grep PIN_ arch/arm/boot/dts/dra7-evm.dts|(while read line;
do
v=`echo "$line" | sed -e "s/\s\s*/|/g" | cut -d '|' -f1 |
cut -d 'x' -f2|tr [a-z] [A-Z]`;
HEX=`echo "obase=16;ibase=16;4A003400+$v"| bc`;
echo "$HEX ===> $line";
done)
against DRA75x/74x NDA TRM revision S(SPRUHI2S August 2014),
documentation errors were found for spi1 pinctrl. Fix the same.
Fixes: 6e58b8f1daaf1af340fb9309907e5ffa473c7aff ("ARM: dts: DRA7: Add
the dts files for dra7 SoC and dra7-evm board")
Signed-off-by: Nishanth Menon
---
arch/arm/boot/dts/dra7-evm.dts | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 50f8022..e120fca 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -50,13 +50,13 @@
mcspi1_pins: pinmux_mcspi1_pins {
pinctrl-single,pins = <
- 0x3a4 (PIN_INPUT | MUX_MODE0) /* spi2_clk */
- 0x3a8 (PIN_INPUT | MUX_MODE0) /* spi2_d1 */
- 0x3ac (PIN_INPUT | MUX_MODE0) /* spi2_d0 */
- 0x3b0 (PIN_INPUT_SLEW | MUX_MODE0) /* spi2_cs0 */
- 0x3b4 (PIN_INPUT_SLEW | MUX_MODE0) /* spi2_cs1 */
- 0x3b8 (PIN_INPUT_SLEW | MUX_MODE6) /* spi2_cs2 */
- 0x3bc (PIN_INPUT_SLEW | MUX_MODE6) /* spi2_cs3 */
+ 0x3a4 (PIN_INPUT | MUX_MODE0) /* spi1_sclk */
+ 0x3a8 (PIN_INPUT | MUX_MODE0) /* spi1_d1 */
+ 0x3ac (PIN_INPUT | MUX_MODE0) /* spi1_d0 */
+ 0x3b0 (PIN_INPUT_SLEW | MUX_MODE0) /* spi1_cs0 */
+ 0x3b4 (PIN_INPUT_SLEW | MUX_MODE0) /* spi1_cs1 */
+ 0x3b8 (PIN_INPUT_SLEW | MUX_MODE6) /*
spi1_cs2.hdmi1_hpd */
+ 0x3bc (PIN_INPUT_SLEW | MUX_MODE6) /*
spi1_cs3.hdmi1_cec */
>;
};
--
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 0/2] fix cm-t54 serial console power supply
Essential fix of CM-T54 serial console power supply and minor update of SBC-T54 DT model property. Dmitry Lifshitz (2): ARM: dts: cm-t54: fix serial console power supply. ARM: dts: sbc-t54: fix model property arch/arm/boot/dts/omap5-cm-t54.dts |5 ++--- arch/arm/boot/dts/omap5-sbc-t54.dts |4 ++-- 2 files changed, 4 insertions(+), 5 deletions(-) -- 1.7.5.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: dts: cm-t54: fix serial console power supply.
LDO8 regulator is used for act led and serial cosole power supply.
Its DT status is declared as "disabled", however the serial console was
functional until Commit 318dbb02b ("regulator: palmas: Fix SMPS
enable/disable/is_enabled") wich properly turns off LDO8 on boot.
Fix serial cosole power supply (and act led) on boot by turning LDO8 on.
Signed-off-by: Dmitry Lifshitz
---
arch/arm/boot/dts/omap5-cm-t54.dts |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-cm-t54.dts
b/arch/arm/boot/dts/omap5-cm-t54.dts
index b8698ca..429471a 100644
--- a/arch/arm/boot/dts/omap5-cm-t54.dts
+++ b/arch/arm/boot/dts/omap5-cm-t54.dts
@@ -353,13 +353,12 @@
};
ldo8_reg: ldo8 {
- /* VDD_3v0: Does not go anywhere */
+ /* VDD_3V_GP: act led/serial console */
regulator-name = "ldo8";
regulator-min-microvolt = <300>;
regulator-max-microvolt = <300>;
+ regulator-always-on;
regulator-boot-on;
- /* Unused */
- status = "disabled";
};
ldo9_reg: ldo9 {
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] ARM: dts: sbc-t54: fix model property
CM-T54 CoM can be used with various custom baseboards, other
than SB-T54 (supplied with SBC-T54 single board computer).
Update model property of SBC-T54 DT to clarify this.
Signed-off-by: Dmitry Lifshitz
---
arch/arm/boot/dts/omap5-sbc-t54.dts |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-sbc-t54.dts
b/arch/arm/boot/dts/omap5-sbc-t54.dts
index aa98fea..8e89793 100644
--- a/arch/arm/boot/dts/omap5-sbc-t54.dts
+++ b/arch/arm/boot/dts/omap5-sbc-t54.dts
@@ -1,11 +1,11 @@
/*
- * Suppport for CompuLab SBC-T54 with CM-T54
+ * Suppport for CompuLab CM-T54 on SB-T54 baseboard
*/
#include "omap5-cm-t54.dts"
/ {
- model = "CompuLab SBC-T54 with CM-T54";
+ model = "CompuLab CM-T54 on SB-T54";
compatible = "compulab,omap5-sbc-t54", "compulab,omap5-cm-t54",
"ti,omap5";
};
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] ARM: dts: am437x-gp-evm: Don't use read/write wait monitoring
+ Sekhar. Hi Pekon, On 09/03/2014 08:29 PM, pekon wrote: > Hi Roger, > > On Wednesday 03 September 2014 02:02 PM, Roger Quadros wrote: >> Hi Pekon, >> >> On 09/02/2014 10:02 PM, pekon wrote: >>> Hi Roger, >>> >>> >>> On Tuesday 02 September 2014 07:27 PM, Roger Quadros wrote: NAND uses wait pin only to indicate device readiness after a block/page operation. It is not use to extend individual read/write cycle and so read/write wait pin monitoring must be disabled for NAND. >>> I think this is incorrect assumption. NAND framework allows >>> wait-pin monitoring at end of each read/write cycle. Please >>> refer following code in drivers/mtd/nand/nand_base.c >>> @@ void nand_wait_ready(...) >>> >>> - nand_wait_ready() calls controller-driver specific call-back >>>for chip->dev_ready(). >> >> It is important to note that this NAND device ready mechanism is different >> from >> GPMC inter cycle wait state mechanism controlled by the read/write monitoring >> bits. The same WAIT pin is used in both the cases. >> >> For more details about NAND use case refer to >> >> AM437x TRM: >> Section: 9.1.3.3.12.2 NAND Device-Ready Pin >> >> below excerpt from there >> "To avoid a time-out caused by a block/page opening delay in NAND flash, >> disable the wait pin monitoring >> for read and write accesses (that is, set the GPMC_CONFIG1_i[[21] >> WAITWRITEMONITORING and >> GPMC_CONFIG1_i[[22] WAITREADMONITORING bits to 0): >> > > I re-read the AM437x TRM, and the section you mentioned above. > > - > *9.1.3.3.12.2 NAND Device-Ready Pin* > The NAND memory device provides a ready pin to indicate data availability > after a block/page opening and to indicate that data programming is complete. > The ready pin can be connected to one of the WAIT GPMC input pins; data read > accesses must not be tried when the ready pin is sampled inactive (device is > not ready) even if the associated chip-select WAITREADMONITORING bit field is > set. The duration of the NAND device busy state after the block/page opening > is so long (up to 50 μs) that accesses occurring when the ready pin is > sampled inactive can stall GPMC access and eventually cause a system time-out. > If a read access to a NAND flash is done using the wait monitoring mode, the > device is blocked during a page opening, and so is the GPMC. If the correct > settings are used, other chip-selects can be used while > the memory processes the page opening command. > ... > - > > It's clearly written that wait-pin monitoring is used for read/write > (programs) access, and GPMC is blocked till wait signal is asserted during > reads. And you cut out the most important part where it says keep read/write wait monitoring disabled for NAND. pasting again here. "To avoid a time-out caused by a block/page opening delay in NAND flash, disable the wait pin monitoring for read and write accesses (that is, set the GPMC_CONFIG1_i[[21] WAITWRITEMONITORING and GPMC_CONFIG1_i[[22] WAITREADMONITORING bits to 0 and use one of the following methods instead: •Use software to poll the WAITnSTS bit (n = 0 to 1) of the GPMC_STS register. •Configure an interrupt that is generated on the WAIT signal change (through the GPMC_IRQEN [11-8] bits). Even if the READWAITMONITORING bit is not set, the external memory nR/B pinstatus is captured in the programmed WAIT bit in the GPMC_STS register. The READWAITMONITORING bit method must be used for other memories than NAND flash, if they require the use of a WAIT signal." > Also, on NAND there can be no read/write access except at page-level And how are command/address inputs sent? ;) > so wait-pin monitoring is implicitly related to read/write accesses. > However, whether you use it or not is purely user's choice, but it > has performance impact. I don't know what you are talking about. I have tried to explain many times but you fail to understand. Nand device ready pin is not same as the wait pin used on other memories where it is used to extend each read/write cycle (by inserting wait state). It is only used to indicate that the NAND device is busy during a block/page operation, so that new commands won't be sent to it by the host processor. This is different from TI GPMC wait monitoring. You have to monitor this device ready pin out of band like polling the status bit or using GPMC interrupt on wait pin transition. Looks like you are getting confused because the same WAIT pin on the SoC is used to get this device ready pin status into the SoC. > > You are probably seeing timeout condition when enabling wait-pin > monitoring, and this can be due to multiple reasons like; > (1) incorrect pin-mux configuration (like directions, pull-up etc) > (2) incorrect board-level pull-up > (3) incorrect driver setting, like though wait-pin is enabled but > wrong wait-pin is being monitored. No for all the 3. > > I request you to fix this instead of disabling it com
Re: [PATCH] mfd: twl4030-power: Fix PM idle pin configuration to not conflict with regulators
On 09/03/2014 08:39 PM, Tony Lindgren wrote: >> good.txt and bad.txt are from the late_initcall. >> >> $ diff -u good.txt bad.txt >> --- good.txt2014-09-03 10:29:58.920317368 +0200 >> +++ bad.txt 2014-09-03 10:28:57.064313222 +0200 > > Hmm can you check that you have good.txt and bad.txt the > right way? I'd assume you need VAUX2 or VAUX3 enabled > not disabled for the MMC to work? No, it was correct. If you look at the complete file you will notice the - which removes the mmc detect/mount in the bad case and + which adds the -110 error >> @@ -1,13 +1,13 @@ >> 1: addr: 0x0017 grp: 0x type: 0x remap: 0x0008 >> - 2: addr: 0x001b grp: 0x type: 0x remap: 0x0008 >> - 3: addr: 0x001f grp: 0x type: 0x remap: 0x0008 >> + 2: addr: 0x001b grp: 0x002e type: 0x remap: 0x0008 >> + 3: addr: 0x001f grp: 0x002e type: 0x remap: 0x0008 > > OK so looking at res_config_addrs[], we have RES_VAUX2 at > 0x1b and RES_VAUX3 at 0x1f. The value for the group register > 0x2e means that bit5 is set and it's used by the p1 device > group. So when the group register is 0x2e, the resource is > enabled. Those got most likely enabled by twl-regulator.c > as twl4030-power.c has TWL4030_RESCONFIG_UNDEF for VAUX2 and > VAUX3. > >> 4: addr: 0x0023 grp: 0x type: 0x remap: 0x0008 >> 5: addr: 0x0027 grp: 0x002e type: 0x remap: 0x0008 >> 6: addr: 0x002b grp: 0x type: 0x remap: 0x0008 >> 7: addr: 0x002f grp: 0x002e type: 0x000b remap: 0x >> 8: addr: 0x0033 grp: 0x002e type: 0x remap: 0x0008 >> 9: addr: 0x0037 grp: 0x002e type: 0x remap: 0x0008 >> -10: addr: 0x003b grp: 0x type: 0x remap: 0x0008 >> +10: addr: 0x003b grp: 0x002e type: 0x remap: 0x0008 > > And that's RES_VDAC at 0x3b with the same story, it's also > marked TWL4030_RESCONFIG_UNDEF and only modified by the > twl4030-power.c. > > I think the use on beaglboard for these are: > > VAUX2 USB_1V8 > VAUX3 CAM_CORE > VDAC VDAC_1V8 > > Not quite seeing the connection.. But I'm assuming you have > good.txt and bad.txt the wrong way around, and you need > VAUX2, VAUX3 or VDAC _enabled_ to get MMC working :) > > So this seems to hint we have issue in one of these: > > 1. We are not claiming VAUX2, VAUX3 or VDAC for beagleboard, >and there's now a timing issue where the regulator >framework disables the unused regulators before MMC. > > 2. We may have a bug that causes register access to >DEV_GRP_OFFSET in twl4030-power.c even with those >resources marked as TWL4030_RESCONFIG_UNDEF. > > 3. There's a I2C race somewhere accessing twl registers. > > Guessing #1 above, maybe give the following patch a try > and see if that helps? If that works, try commenting out > vaux3 or vdac and see which one is needed. I'm guessing > it's the vdac. With that patch it seems it is a little harder to trigger. It is usually every other boot that fails. Here a diff between two that worked (say good-v1 vs good-v2): @@ -151,19 +151,15 @@ Btrfs loaded hsusb2_vbus: 3300 mV 1: addr: 0x0017 grp: 0x type: 0x remap: 0x0008 -2: addr: 0x001b grp: 0x002e type: 0x remap: 0x0008 -3: addr: 0x001f grp: 0x002e type: 0x remap: 0x0008 +2: addr: 0x001b grp: 0x type: 0x remap: 0x0008 +3: addr: 0x001f grp: 0x type: 0x remap: 0x0008 4: addr: 0x0023 grp: 0x type: 0x remap: 0x0008 5: addr: 0x0027 grp: 0x002e type: 0x remap: 0x0008 6: addr: 0x002b grp: 0x type: 0x remap: 0x0008 7: addr: 0x002f grp: 0x002e type: 0x000b remap: 0x 8: addr: 0x0033 grp: 0x002e type: 0x remap: 0x0008 -mmc0: host does not support reading read-only switch. assuming write-enable. 9: addr: 0x0037 grp: 0x002e type: 0x remap: 0x0008 -mmc0: new high speed SDHC card at address 1234 -mmcblk0: mmc0:1234 SA04G 3.63 GiB -10: addr: 0x003b grp: 0x002e type: 0x remap: 0x0008 - mmcblk0: p1 p2 p3 +10: addr: 0x003b grp: 0x type: 0x remap: 0x0008 11: addr: 0x003f grp: 0x00ef type: 0x0011 remap: 0x0008 12: addr: 0x0043 grp: 0x00ef type: 0x0010 remap: 0x0008 13: addr: 0x0047 grp: 0x00ef type: 0x0011 remap: 0x0008 @@ -173,8 +169,12 @@ 17: addr: 0x0071 grp: 0x type: 0x remap: 0x0008 18: addr: 0x0074 grp: 0x type: 0x remap: 0x0008 19: addr: 0x0077 grp: 0x00ef type: 0x remap: 0x0008 +mmc0: host does not support reading read-only switch. assuming write-enable. 20: addr: 0x007a grp: 0x type: 0x remap: 0x +mmc0: new high speed SDHC card at address 1234 +mmcblk0: mmc0:1234 SA04G 3.63 GiB 21: addr: 0x007f grp: 0x00ef type: 0x000a remap: 0x0008 + mmcblk0: p1 p2 p3 22: addr: 0x0082 grp: 0x00ee type: 0x0008 remap: 0x0008 23: addr: 0x0085 grp: 0x00af type: 0x0013 remap: 0x 24: addr: 0x0088 grp: 0x00ef type: 0x000e remap: 0x0008 It took mmc a little longer to detect but it worked. And the content of the three registers seem not to matter _or_ it was dumped before MMC got active. Now a diff of good v1 vs bad: @@ -158,12 +158,8 @@ 6: addr:
Re: [PATCH 2/2] iommu/omap: Fix iommu archdata name for DT-based devices
Hi Suman,
Thank you for the patch.
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
> ---
> 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
> #include
> #include
> +#include
>
> #include
>
> @@ -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 :-/
Will Deacon has posted patches that rework the IOMMU core for better DT
integration, have you seen them ?
> +
> 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
Re: [PATCH 1/2] iommu/omap: Check for valid archdata in attach_dev
Hi Suman,
Thank you for the patch.
On Wednesday 03 September 2014 18:58:31 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 non-NULL 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
> ---
> drivers/iommu/omap-iommu.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
> index 02ef0ac..f245d51 100644
> --- a/drivers/iommu/omap-iommu.c
> +++ b/drivers/iommu/omap-iommu.c
> @@ -1092,6 +1092,12 @@ omap_iommu_attach_dev(struct iommu_domain *domain,
> struct device *dev)
>
> spin_lock(&omap_domain->lock);
>
> + if (!arch_data) {
> + dev_err(dev, "device doesn't have an associated iommu\n");
> + ret = -EINVAL;
> + goto out;
> + }
You can move this check outside of the spinlock-protected section. With that
change,
Acked-by: Laurent Pinchart
> +
> /* only a single device is supported per domain for now */
> if (omap_domain->iommu_dev) {
> dev_err(dev, "iommu domain is already attached\n");
--
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
