Re: [PATCH 0/1] ARM: OMAP: add external clock provider support
On 09/03/2014 10:28 PM, Mike Turquette wrote: Quoting Tero Kristo (2014-08-04 05:36:19) On 08/04/2014 02:37 PM, Peter Ujfalusi wrote: On 08/01/2014 04:15 PM, Tero Kristo wrote: Hi, This patch adds possibility to register external clocks (outside the main SoC) on TI boards through device tree. Clock sources as such include for example twl-6030 / twl-6040 chips and variants which can be used to clock for example audio / WLAN chips. Just one question to Mike and Tero: would it be possible to have generic binding for such an external clocks? We have the palmas clock driver already upstream which handles the 32K clocks from the PMIC. Palmas class of PMICs can be used with TI/nVidia(/Intel?) platforms. We use Palmas on omap5-uevm, DRA7-EVM also uses Palmas compatible PMIC and some nVidia platform also uses this class of devices (and they all need to have control over the 32K clock(s)). Other platforms initialize their clocks in different manner, they can use generic of_clk_init I believe. If they can't use that for some reason, then they need to implement something similar to this. Right. To answer Peter's question, we do have a generic binding, it is the clock binding ;-) Even the idea of having a "TI clock provider" isn't really a good way to do things. IP blocks that generate clocks are clock providers, not companies. As such if Palmas or Gaia or whatever generate clocks then we don't need any new infrastructure in the clock core to accomodate this. Those drivers simply need to include clk-provider.h and register their clocks with the framework. Some good examples of this are the omap3-isp.c driver, and qcom's hdmi phy driver (sorry, don't have the path handy) which both consume clocks generated by other clock providers, and they provide their own clocks which are generated within their own IP/module. A big part of the design of the ccf (and later, the DT bindings) is that we do not need a centralized place to store every piece of clock generation knowledge and clock routing knowledge. This patch is obsolete now, I posted the patch which changes the TI clock driver to use generic of_clk_init instead of a custom one. This now initializes all the external clocks also without any issues. The patch itself can potentially cause some problems with DPLL clocks though (as they use the retry init mechanism and this is overlooked in v1), so I am working on v2 atm. -Tero Regards, Mike -Tero This patch can be queued once someone has a use-case + patches that requires usage of such clocks. -Tero -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: dts: omap5.dtsi: add DSS RFBI node
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.
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>,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/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 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;
+ }
+
/* only a single device is supported per domain for now */
if (omap_domain->iommu_dev) {
dev_err(dev, "iommu domain is already attached\n");
--
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 0/2] OMAP IOMMU Fixes for DT-clients
Hi, Following are couple of minor fixes to the OMAP IOMMU driver for DT-based client devices. The first patch adds an additional check to detect invalid usage of IOMMU API for devices with no IOMMUs, and the second patch fixes the failure to attach to an OMAP IOMMU for properly configured DT devices. The kernel does not yet have any OMAP IOMMU users represented in DT, so this failure is not currently seen, but will be seen when users like OMAP3 ISP or OMAP4 remoteprocs are converted to DT. regards Suman 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 | 16 +++- 1 file changed, 15 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 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 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;
+ }
+
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
Re: [PATCH] arm: boot: dts: am4372: fix USB regs size
* Felipe Balbi [140903 14:28]:
> Size should be 64KiB instead of 92KiB.
>
> Signed-off-by: Felipe Balbi
> ---
> arch/arm/boot/dts/am4372.dtsi | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
> index 9b3d2ba..8689949 100644
> --- a/arch/arm/boot/dts/am4372.dtsi
> +++ b/arch/arm/boot/dts/am4372.dtsi
> @@ -804,7 +804,7 @@
>
> usb1: usb@4839 {
> compatible = "synopsys,dwc3";
> - reg = <0x4839 0x17000>;
> + reg = <0x4839 0x1>;
> interrupts = ;
> phys = <&usb2_phy1>;
> phy-names = "usb2-phy";
> @@ -826,7 +826,7 @@
>
> usb2: usb@483d {
> compatible = "synopsys,dwc3";
> - reg = <0x483d 0x17000>;
> + reg = <0x483d 0x1>;
> interrupts = ;
> phys = <&usb2_phy2>;
> phy-names = "usb2-phy";
> --
Applying into omap-for-v3.17/fixes-v2 thanks.
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: am437x-gp: switch i2c0 to 100KHz
* Nishanth Menon [140903 11:46]: > On the GP EVM, the ambient light sensor is limited to 100KHz on the > I2C bus. > > So use 100kHz for I2C on the GP EVM due to this limitation on the > ambient light sensor. > > Reported-by: Aparna Balasubramanian > Signed-off-by: Nishanth Menon Thanks applying into omap-for-v3.7/fixes-v2. 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] ARM: dts: am335x-bone*: Fix model name and update compatibility information
* Nishanth Menon [140903 09:03]: > Beaglebone white and beaglebone black differ in tiny little aspects. > This is the reason why we maintain seperate dts for these platforms. > However, there is no real way to decode from dtb which platform it is > since compatible and model name are the same for both platforms. > > Fix this so that beaglebone black and beaglebone are identifiable, > while maintaining compatibility for older zImages which might use old > beaglebone compatible flag for black as well. > > Reported-by: Tom Rini > Signed-off-by: Nishanth Menon Thanks applying into omap-for-v3.18/fixes-not-urgent. 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
* 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. 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/2] ARM: dts: dra7-evm: Fixes for 3.17
* Roger Quadros [140903 04:18]: > Hi Tony, > > These patches fix I2C3 bus pinmux and frequency as well as > NAND partition name on dra7-evm. > > cheers, > -roger > > --- > Roger Quadros (2): > ARM: dts: dra7-evm: Fix i2c3 pinmux and frequency > ARM: dts: dra7-evm: Fix 8th NAND partition's name > > arch/arm/boot/dts/dra7-evm.dts | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) Applying into omap-for-v3.17/fixes-v2 thanks. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] OMAP2+: GPMC: NAND fixes for 3.17
* 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. Tony > Patches are available at > g...@github.com:rogerq/linux.git > * [new branch] for-v3.17/gpmc-fixes > > cheers, > -roger > > Roger Quadros (6): > 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 > > arch/arm/boot/dts/am437x-gp-evm.dts | 4 +--- > arch/arm/boot/dts/am43x-epos-evm.dts | 9 - > arch/arm/mach-omap2/gpmc.c | 7 +++ > 3 files changed, 8 insertions(+), 12 deletions(-) > > -- > 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
Re: [GIT PULL] ARM: OMAP3: quick clock dts fix for 3.17-rc
* Tero Kristo [140903 01:18]: > Hi Tony, > > The following changes since commit 7d1311b93e58ed55f3a31cc8f94c4b8fe988a2b9: > > Linux 3.17-rc1 (2014-08-16 10:40:26 -0600) > > are available in the git repository at: > > g...@github.com:t-kristo/linux-pm.git for-v3.17-rc/ti-clk-dt > > for you to fetch changes up to adf5b4dcc0cf50715f74f49f3c7af0c80467f55f: > > ARM: dts: set 'ti,set-rate-parent' for dpll4_m5x2 clock (2014-08-21 > 18:01:35 +0300) > > > Stefan Herbrechtsmeier (1): > ARM: dts: set 'ti,set-rate-parent' for dpll4_m5x2 clock > > arch/arm/boot/dts/omap3xxx-clocks.dtsi |1 + > 1 file changed, 1 insertion(+) Thanks applying into omap-for-v3.17/fixes-v2. 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] ARM: dts: omap4-panda: Fix model and SoC family details
* Nishanth Menon [140828 13:45]:
> Currently we claim that omap4-panda and omap4-panda-es are essentially
> the same, but they are not since PandaBoard-ES uses OMAP4460 and
> PandaBoard uses OMAP4430.
>
> So, split the common definition and make the model name available.
>
> Signed-off-by: Nishanth Menon
> ---
> Based on v3.17-rc2
>
> Testing logs: (boot test):
> Before Patch(v3.17-rc2)
> 1: pandaboard-es: Boot PASS: http://slexy.org/raw/s209HfpVTs
> 2: pandaboard-vanilla: Boot PASS: http://slexy.org/raw/s21YNmOhQL
>
> After Patch
> 1: pandaboard-es: Boot PASS: http://slexy.org/raw/s20FH76BTn
> 2: pandaboard-vanilla: Boot PASS: http://slexy.org/raw/s2vFLcfkBu
Thanks applying into omap-for-v3.18/fixes-not-urgent.
> Note: 'ti,omap4-panda-es' is not documented in bindings, not entirely
> sure if we should be doing the same for every board compatibility.
That should probably be done on regular basis with some script
if we want to keep the documentation updated.
Regards,
Tony
> arch/arm/boot/dts/omap4-panda-common.dtsi |3 ---
> arch/arm/boot/dts/omap4-panda-es.dts |5 +
> arch/arm/boot/dts/omap4-panda.dts |5 +
> 3 files changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
> b/arch/arm/boot/dts/omap4-panda-common.dtsi
> index 8cfa3c8..1505135 100644
> --- a/arch/arm/boot/dts/omap4-panda-common.dtsi
> +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
> @@ -8,9 +8,6 @@
> #include "elpida_ecb240abacn.dtsi"
>
> / {
> - model = "TI OMAP4 PandaBoard";
> - compatible = "ti,omap4-panda", "ti,omap4430", "ti,omap4";
> -
> memory {
> device_type = "memory";
> reg = <0x8000 0x4000>; /* 1 GB */
> diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
> b/arch/arm/boot/dts/omap4-panda-es.dts
> index 816d1c9..2f1dabc 100644
> --- a/arch/arm/boot/dts/omap4-panda-es.dts
> +++ b/arch/arm/boot/dts/omap4-panda-es.dts
> @@ -10,6 +10,11 @@
> #include "omap4460.dtsi"
> #include "omap4-panda-common.dtsi"
>
> +/ {
> + model = "TI OMAP4 PandaBoard-ES";
> + compatible = "ti,omap4-panda-es", "ti,omap4-panda", "ti,omap4460",
> "ti,omap4430", "ti,omap4";
> +};
> +
> /* Audio routing is differnet between PandaBoard4430 and PandaBoardES */
> &sound {
> ti,model = "PandaBoardES";
> diff --git a/arch/arm/boot/dts/omap4-panda.dts
> b/arch/arm/boot/dts/omap4-panda.dts
> index 6189a8b..a0e28b2 100644
> --- a/arch/arm/boot/dts/omap4-panda.dts
> +++ b/arch/arm/boot/dts/omap4-panda.dts
> @@ -9,3 +9,8 @@
>
> #include "omap443x.dtsi"
> #include "omap4-panda-common.dtsi"
> +
> +/ {
> + model = "TI OMAP4 PandaBoard";
> + compatible = "ti,omap4-panda", "ti,omap4430", "ti,omap4";
> +};
> --
> 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] arm: boot: dts: am4372: fix USB regs size
Size should be 64KiB instead of 92KiB.
Signed-off-by: Felipe Balbi
---
arch/arm/boot/dts/am4372.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 9b3d2ba..8689949 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -804,7 +804,7 @@
usb1: usb@4839 {
compatible = "synopsys,dwc3";
- reg = <0x4839 0x17000>;
+ reg = <0x4839 0x1>;
interrupts = ;
phys = <&usb2_phy1>;
phy-names = "usb2-phy";
@@ -826,7 +826,7 @@
usb2: usb@483d {
compatible = "synopsys,dwc3";
- reg = <0x483d 0x17000>;
+ reg = <0x483d 0x1>;
interrupts = ;
phys = <&usb2_phy2>;
phy-names = "usb2-phy";
--
2.0.1.563.g66f467c
--
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] Documentation: devicetree: mfd: twl4030-power: Use the standard 'ti,system-power-controller' to mark power control
On Wed, Sep 3, 2014 at 2:53 PM, Sebastian Reichel wrote: > On Wed, Sep 03, 2014 at 02:06:47PM -0500, Nishanth Menon wrote: >> Optional properties: >> -- ti,use_poweroff: With this flag, the chip will initiates an ACTIVE-to-OFF >> or >> -SLEEP-to-OFF transition when the system poweroffs. >> + >> +- ti,system-power-controller OR ti,use_poweroff: This indicates that >> + TWL4030 is the power supply master of the system. With this flag, the >> + chip will initiates an ACTIVE-to-OFF or SLEEP-to-OFF transition when >> + the system poweroffs. > > I suggest the following wording: > > - ti,system-power-controller: This indicates that TWL4030 is the > power supply master of the system. With this flag, the chip will > initiates an ACTIVE-to-OFF or SLEEP-to-OFF transition when the > system poweroffs. > > - ti,use_poweroff: Deprecated name for ti,system-power-controller Yes, this does indeed sound better. if no one has a different opinion or further comments, will update this patch tomorrow. -- --- 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 v5 1/3] usb: dwc3: add ST dwc3 glue layer to manage dwc3 HC
Hi,
On Tue, Sep 02, 2014 at 06:08:47PM +0100, Peter Griffin wrote:
> +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);
you might want to use of_platform_depopulate() instead :-) Sorry I
didn't notice this earlier.
cheers
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 1/2] Documentation: devicetree: mfd: twl4030-power: Use the standard 'ti,system-power-controller' to mark power control
Hi, On Wed, Sep 03, 2014 at 02:06:47PM -0500, Nishanth Menon wrote: > ti,system-power-controller is more or less the standard way of > indicating that the PMIC is the system wide power controller and hence > may be used to switch off the system. Almost ALL TI PMIC drivers and > many Maxim PMIC drivers follow the same style. > > So support 'ti,system-power-controller' in addition to the usual > 'ti,use_poweroff' to indicate that the PMIC instance has control for > switching off the system. > > Signed-off-by: Nishanth Menon > --- > .../devicetree/bindings/mfd/twl4030-power.txt |7 +-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/mfd/twl4030-power.txt > b/Documentation/devicetree/bindings/mfd/twl4030-power.txt > index b9ee7b9..e1dff57 100644 > --- a/Documentation/devicetree/bindings/mfd/twl4030-power.txt > +++ b/Documentation/devicetree/bindings/mfd/twl4030-power.txt > @@ -23,8 +23,11 @@ down during off-idle. Note that this does not work on all > boards > depending on how the external oscillator is wired. > > Optional properties: > -- ti,use_poweroff: With this flag, the chip will initiates an ACTIVE-to-OFF > or > -SLEEP-to-OFF transition when the system poweroffs. > + > +- ti,system-power-controller OR ti,use_poweroff: This indicates that > + TWL4030 is the power supply master of the system. With this flag, the > + chip will initiates an ACTIVE-to-OFF or SLEEP-to-OFF transition when > + the system poweroffs. I suggest the following wording: - ti,system-power-controller: This indicates that TWL4030 is the power supply master of the system. With this flag, the chip will initiates an ACTIVE-to-OFF or SLEEP-to-OFF transition when the system poweroffs. - ti,use_poweroff: Deprecated name for ti,system-power-controller -- Sebastian signature.asc Description: Digital signature
Re: [PATCH 0/1] ARM: OMAP: add external clock provider support
Quoting Tero Kristo (2014-08-04 05:36:19) > On 08/04/2014 02:37 PM, Peter Ujfalusi wrote: > > On 08/01/2014 04:15 PM, Tero Kristo wrote: > >> Hi, > >> > >> This patch adds possibility to register external clocks (outside the main > >> SoC) on TI boards through device tree. Clock sources as such include for > >> example twl-6030 / twl-6040 chips and variants which can be used to clock > >> for example audio / WLAN chips. > > > > Just one question to Mike and Tero: > > would it be possible to have generic binding for such an external clocks? > > We have the palmas clock driver already upstream which handles the 32K > > clocks > > from the PMIC. Palmas class of PMICs can be used with TI/nVidia(/Intel?) > > platforms. We use Palmas on omap5-uevm, DRA7-EVM also uses Palmas compatible > > PMIC and some nVidia platform also uses this class of devices (and they all > > need to have control over the 32K clock(s)). > > Other platforms initialize their clocks in different manner, they can > use generic of_clk_init I believe. If they can't use that for some > reason, then they need to implement something similar to this. Right. To answer Peter's question, we do have a generic binding, it is the clock binding ;-) Even the idea of having a "TI clock provider" isn't really a good way to do things. IP blocks that generate clocks are clock providers, not companies. As such if Palmas or Gaia or whatever generate clocks then we don't need any new infrastructure in the clock core to accomodate this. Those drivers simply need to include clk-provider.h and register their clocks with the framework. Some good examples of this are the omap3-isp.c driver, and qcom's hdmi phy driver (sorry, don't have the path handy) which both consume clocks generated by other clock providers, and they provide their own clocks which are generated within their own IP/module. A big part of the design of the ccf (and later, the DT bindings) is that we do not need a centralized place to store every piece of clock generation knowledge and clock routing knowledge. Regards, Mike > > -Tero > > > > >> This patch can be queued once someone has a use-case + patches that > >> requires > >> usage of such clocks. > >> > >> -Tero > >> > > > > > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] clk: prevent erronous parsing of children during rate change
Quoting Tero Kristo (2014-08-21 06:47:45)
> In some cases, clocks can switch their parent with clk_set_rate, for
> example clk_mux can do this in some cases. Current implementation of
> clk_change_rate uses un-safe list iteration on the clock children, which
> will cause wrong clocks to be parsed in case any of the clock children
> change their parents during the change rate operation. Fixed by using
> the safe list iterator instead.
>
> The problem was detected due to some divide by zero errors generated
> by clock init on dra7-evm board, see discussion under
> http://article.gmane.org/gmane.linux.ports.arm.kernel/349180 for details.
>
> Signed-off-by: Tero Kristo
> To: Mike Turquette
> Reported-by: Nishanth Menon
Applied to clk-fixes.
Thanks!
Mike
> ---
> drivers/clk/clk.c |7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index b76fa69..bacc06f 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -1467,6 +1467,7 @@ static struct clk *clk_propagate_rate_change(struct clk
> *clk, unsigned long even
> static void clk_change_rate(struct clk *clk)
> {
> struct clk *child;
> + struct hlist_node *tmp;
> unsigned long old_rate;
> unsigned long best_parent_rate = 0;
> bool skip_set_rate = false;
> @@ -1502,7 +1503,11 @@ static void clk_change_rate(struct clk *clk)
> if (clk->notifier_count && old_rate != clk->rate)
> __clk_notify(clk, POST_RATE_CHANGE, old_rate, clk->rate);
>
> - hlist_for_each_entry(child, &clk->children, child_node) {
> + /*
> +* Use safe iteration, as change_rate can actually swap parents
> +* for certain clock types.
> +*/
> + hlist_for_each_entry_safe(child, tmp, &clk->children, child_node) {
> /* Skip children who will be reparented to another clock */
> if (child->new_parent && child->new_parent != clk)
> continue;
> --
> 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
Re: PROBLEM: bindings for drivers/mfd/twl4030-power.c
On Wed, Sep 3, 2014 at 2:02 PM, Tony Lindgren wrote: > * Nishanth Menon [140903 11:51]: >> On 09/03/2014 01:45 PM, Tony Lindgren wrote: >> > * Dr. H. Nikolaus Schaller [140901 09:54]: >> >> Hi, >> >> >> >> Am 25.08.2014 um 23:26 schrieb Tony Lindgren: >> >> >> >>> * Dr. H. Nikolaus Schaller [140817 08:46]: >> I am trying to make ti,use_poweroff work on 3.17-rc1 for the GTA04 >> board. >> Poweroff was broken for a while and I found that the driver isn't >> loaded at all. >> >> It appears to me that commit e7cd1d1eb16fcdf53001b926187a82f1f3e1a7e6 >> did rename the compatible entry from "ti,twl4030-power" to >> "ti,twl4030-power-reset" >> but this was not documented in the bindings and of course our DT does >> not >> match. >> >> Even your commit message talks about "ti,twl4030-power" although I >> can't find it >> in the code. >> >>> >> >>> Hmm sorry did I accidentally remove ti,twl4030-power? If so, that should >> >>> be added back for sure. Do you have a patch for that already? >> >> >> >> No, I have only updated our device tree because I don't know if it really >> >> should >> >> be added back or not. >> >> >> >> As you say the "ti,twl4030-power" does not configure anything. So what >> >> is it good for? >> > >> > Only for the poweroff if "ti,use_poweroff" is set. Care to do a patch >> > as you clearly have a use case to test it with? >> >> Tony, we were talking about supporting ti,system-power-controller as >> the standard way of stating poweroff control is by the PMIC. this >> seems to be standard in various SoCs. use_poweroff seems to predate >> that standardization. Should'nt we start using >> ti,system-power-controller instead? > > Sure we can add that. But need to keep also parsing "ti,use_poweroff" > as it's already in use. > Yep. https://patchwork.kernel.org/patch/4836381/ https://patchwork.kernel.org/patch/4836371/ Split documentation out (based on discussion in https://patchwork.kernel.org/patch/4743321/). -- --- 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 2/2] mfd: twl4030-power: use 'ti,system-power-controller' as alternative way to support system power off
ti,system-power-controller is more or less the standard way of indicating that the PMIC is the system wide power controller and hence may be used to switch off the system. Almost ALL TI PMIC drivers and many Maxim PMIC drivers follow the same style. So support 'ti,system-power-controller' in addition to the usual 'ti,use_poweroff' to indicate that the PMIC instance has control for switching off the system. Signed-off-by: Nishanth Menon --- drivers/mfd/twl4030-power.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c index 3bc969a..1c129ba 100644 --- a/drivers/mfd/twl4030-power.c +++ b/drivers/mfd/twl4030-power.c @@ -627,6 +627,9 @@ static bool twl4030_power_use_poweroff(const struct twl4030_power_data *pdata, if (pdata && pdata->use_poweroff) return true; + if (of_property_read_bool(node, "ti,system-power-controller")) + return true; + if (of_property_read_bool(node, "ti,use_poweroff")) return true; -- 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] mfd: twl4030-power: support ti,system-power-controller
This series adds ti,system-power-controller to Documentation and the driver seperately as per maintainer preference. Based on v3.17-rc1 Nishanth Menon (2): Documentation: devicetree: mfd: twl4030-power: Use the standard 'ti,system-power-controller' to mark power control mfd: twl4030-power: use 'ti,system-power-controller' as alternative way to support system power off .../devicetree/bindings/mfd/twl4030-power.txt |7 +-- drivers/mfd/twl4030-power.c|3 +++ 2 files changed, 8 insertions(+), 2 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 1/2] Documentation: devicetree: mfd: twl4030-power: Use the standard 'ti,system-power-controller' to mark power control
ti,system-power-controller is more or less the standard way of
indicating that the PMIC is the system wide power controller and hence
may be used to switch off the system. Almost ALL TI PMIC drivers and
many Maxim PMIC drivers follow the same style.
So support 'ti,system-power-controller' in addition to the usual
'ti,use_poweroff' to indicate that the PMIC instance has control for
switching off the system.
Signed-off-by: Nishanth Menon
---
.../devicetree/bindings/mfd/twl4030-power.txt |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/mfd/twl4030-power.txt
b/Documentation/devicetree/bindings/mfd/twl4030-power.txt
index b9ee7b9..e1dff57 100644
--- a/Documentation/devicetree/bindings/mfd/twl4030-power.txt
+++ b/Documentation/devicetree/bindings/mfd/twl4030-power.txt
@@ -23,8 +23,11 @@ down during off-idle. Note that this does not work on all
boards
depending on how the external oscillator is wired.
Optional properties:
-- ti,use_poweroff: With this flag, the chip will initiates an ACTIVE-to-OFF or
- SLEEP-to-OFF transition when the system poweroffs.
+
+- ti,system-power-controller OR ti,use_poweroff: This indicates that
+ TWL4030 is the power supply master of the system. With this flag, the
+ chip will initiates an ACTIVE-to-OFF or SLEEP-to-OFF transition when
+ the system poweroffs.
Example:
&i2c1 {
--
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
Re: PROBLEM: bindings for drivers/mfd/twl4030-power.c
* Nishanth Menon [140903 11:51]: > On 09/03/2014 01:45 PM, Tony Lindgren wrote: > > * Dr. H. Nikolaus Schaller [140901 09:54]: > >> Hi, > >> > >> Am 25.08.2014 um 23:26 schrieb Tony Lindgren: > >> > >>> * Dr. H. Nikolaus Schaller [140817 08:46]: > I am trying to make ti,use_poweroff work on 3.17-rc1 for the GTA04 board. > Poweroff was broken for a while and I found that the driver isn't loaded > at all. > > It appears to me that commit e7cd1d1eb16fcdf53001b926187a82f1f3e1a7e6 > did rename the compatible entry from "ti,twl4030-power" to > "ti,twl4030-power-reset" > but this was not documented in the bindings and of course our DT does not > match. > > Even your commit message talks about "ti,twl4030-power" although I can't > find it > in the code. > >>> > >>> Hmm sorry did I accidentally remove ti,twl4030-power? If so, that should > >>> be added back for sure. Do you have a patch for that already? > >> > >> No, I have only updated our device tree because I don't know if it really > >> should > >> be added back or not. > >> > >> As you say the "ti,twl4030-power" does not configure anything. So what > >> is it good for? > > > > Only for the poweroff if "ti,use_poweroff" is set. Care to do a patch > > as you clearly have a use case to test it with? > > Tony, we were talking about supporting ti,system-power-controller as > the standard way of stating poweroff control is by the PMIC. this > seems to be standard in various SoCs. use_poweroff seems to predate > that standardization. Should'nt we start using > ti,system-power-controller instead? Sure we can add that. But need to keep also parsing "ti,use_poweroff" as it's already in use. 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: PROBLEM: bindings for drivers/mfd/twl4030-power.c
On 09/03/2014 01:45 PM, Tony Lindgren wrote: > * Dr. H. Nikolaus Schaller [140901 09:54]: >> Hi, >> >> Am 25.08.2014 um 23:26 schrieb Tony Lindgren: >> >>> * Dr. H. Nikolaus Schaller [140817 08:46]: I am trying to make ti,use_poweroff work on 3.17-rc1 for the GTA04 board. Poweroff was broken for a while and I found that the driver isn't loaded at all. It appears to me that commit e7cd1d1eb16fcdf53001b926187a82f1f3e1a7e6 did rename the compatible entry from "ti,twl4030-power" to "ti,twl4030-power-reset" but this was not documented in the bindings and of course our DT does not match. Even your commit message talks about "ti,twl4030-power" although I can't find it in the code. >>> >>> Hmm sorry did I accidentally remove ti,twl4030-power? If so, that should >>> be added back for sure. Do you have a patch for that already? >> >> No, I have only updated our device tree because I don't know if it really >> should >> be added back or not. >> >> As you say the "ti,twl4030-power" does not configure anything. So what >> is it good for? > > Only for the poweroff if "ti,use_poweroff" is set. Care to do a patch > as you clearly have a use case to test it with? Tony, we were talking about supporting ti,system-power-controller as the standard way of stating poweroff control is by the PMIC. this seems to be standard in various SoCs. use_poweroff seems to predate that standardization. Should'nt we start using ti,system-power-controller instead? -- 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] ARM: dts: am437x-gp: switch i2c0 to 100KHz
On the GP EVM, the ambient light sensor is limited to 100KHz on the
I2C bus.
So use 100kHz for I2C on the GP EVM due to this limitation on the
ambient light sensor.
Reported-by: Aparna Balasubramanian
Signed-off-by: Nishanth Menon
---
based on v3.17-rc1
arch/arm/boot/dts/am437x-gp-evm.dts |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts
b/arch/arm/boot/dts/am437x-gp-evm.dts
index 646a6ea..9559c19 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -260,7 +260,7 @@
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&i2c0_pins>;
- clock-frequency = <40>;
+ clock-frequency = <10>;
tps65218: tps65218@24 {
reg = <0x24>;
--
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
Re: PROBLEM: bindings for drivers/mfd/twl4030-power.c
* Dr. H. Nikolaus Schaller [140901 09:54]: > Hi, > > Am 25.08.2014 um 23:26 schrieb Tony Lindgren: > > > * Dr. H. Nikolaus Schaller [140817 08:46]: > >> I am trying to make ti,use_poweroff work on 3.17-rc1 for the GTA04 board. > >> Poweroff was broken for a while and I found that the driver isn't loaded > >> at all. > >> > >> It appears to me that commit e7cd1d1eb16fcdf53001b926187a82f1f3e1a7e6 > >> did rename the compatible entry from "ti,twl4030-power" to > >> "ti,twl4030-power-reset" > >> but this was not documented in the bindings and of course our DT does not > >> match. > >> > >> Even your commit message talks about "ti,twl4030-power" although I can't > >> find it > >> in the code. > > > > Hmm sorry did I accidentally remove ti,twl4030-power? If so, that should > > be added back for sure. Do you have a patch for that already? > > No, I have only updated our device tree because I don't know if it really > should > be added back or not. > > As you say the "ti,twl4030-power" does not configure anything. So what > is it good for? Only for the poweroff if "ti,use_poweroff" is set. Care to do a patch as you clearly have a use case to test it with? > >> Are "ti,twl4030-power" and "ti,twl4030-power-reset" doing the same? > > > > No, they are separate where ti,twl4030-power does not configure the > > twl4030 in any way where ti,twl4030-power-reset configures the warm > > reset sequence. > > Yes, that is what I deduced because our old setting of "ti,twl4030-power" did > no longer configure the power-off and not even load the driver. > > > > > For gta04, what you really want is to use ti,twl4030-power-idle or > > even ti,twl4030-power-idle-osc-off if the board is wired to support > > cutting off the oscillator. > > Ok, I see (but must admit that I don't understand the details even after > reading the bindings.txt). Well the twl4030 has resources such as GPIO pins and regulators that can be configured to automatically change state for retention and off-idle. That's how we can cut off the core voltage for idle. > Currently we develop without taking care of suspend (the DT migration was > much more troublesome work than anticipated) but that should be changed soon. OK, yeah the PM features should be finally working now with mainline and DT :) > > And you probably also want to configure some wake-up interrupts at least > > for the the UARTs in the board specific .dts file, see for example the > > UART3 in the existing board files that have: > > > > interrupts-extended = <&intc 74 &omap3_pmx_core OMAP3_UART3_RX>; > > thanks for the hint! No problem. And FYI, the reason why we can't add that automatically is because there are alternate pins for UART3 pins depending on the packaging and which pin is actually wired up. 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] mfd: twl4030-power: Fix PM idle pin configuration to not conflict with regulators
* Sebastian Andrzej Siewior [140903 01:39]:
> On 09/03/2014 02:24 AM, Tony Lindgren wrote:
>
> > dump out the twl configuration in late_initcall and via sysfs
> > so maybe try that and see what the values are with working
> > and non-working case?
>
> 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?
> @@ -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
VDACVDAC_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.
Regards,
Tony
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -331,6 +331,18 @@
regulator-always-on;
};
+&vaux3 {
+ regulator-name = "cam_core";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-always-on;
+};
+
+&vdac {
+ regulator-name = "vdac_1v8";
+ regulator-always-on;
+};
+
&mcbsp2 {
status = "okay";
};
--
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 [140903 09:46]: > On 09/02/2014 10:15 PM, Tony Lindgren wrote: > >> - I see to face two kind of "deaths": > >> - the LED still goes on and off and the uart just does not respond > >> even if I tell the button print something on the screen (the button > >> also changes the frequency of the LED so I know that the button is > >> doing something). > >> Also from dumping the content of /proc/interrupts it seems that a > >> wake up is made, the uart should have restored the registers. > > > > OK yeah this is the case I was seeing too. So do you just set the > > LED triggers to none in sysfs to make it easier to reproduce? > > Yes. > > >> - one where the system is dead and the LED does not blink anymore. > >> Also my button is dead. > > > > This I don't think I've seen. This could also be the errata issue on > > your earlier rev beagleboard-xm with off-idle. > > might be. > > Your pstore hint gave me something. I tried that earlier but somehow > assumed that dram content was killed on init. But the content is even > there are pressing the reset button :) Yeah pstore is very nice for debugging mystery hangs :) > However, I was able to capture the case where the LED was not blinking: > The IIR register says 0xc6 (=> line status error). That is okay. At the > same time LSR register says 0xe0. This is not okay. It means that there > is some kind of error and at least one error bit is set in this > register which is not the case. Also those bits are cleared on read > which does not happen here. And we loop forever so the LED does blink > anymore. OK > The RX-count register says that it is empty which sense because bit 0 > is not set (in LSR). However I can read multiple times from the RX FIFO > until I get the "unhandled bus access" error which usually happens > right away if the empty FIFO is read on omap3 HW. In the last test I > mange to read 91 times before the crash. I hoped that this FIFO read > would make the interrupt go away but it did not. > > The HW seems to be in a strange state. It might be either the errata > or something else. I even took the resume routine from omap-serial in > case I did something wrong. In my last test it worked for 10minues > before the interrupt storm came. > > This is probably the same thing I see on the omap-serial driver where I > got from pstore: > > [ 32.659271] random: nonblocking pool is initialized > [ 212.170623] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! > [swapper:0] > > So I *guess* the interrupt routine is looping. This is problem one, no > idea what is going on (the register status captured on 8250-omap makes > no sense). See recent commit cc824534d4fe, and try commenting out the check for HWMOD_FORCE_MSTANDBY in omap_hwmod.c so _reconfigure_io_chain() is always called. If that changes something, we at least have some idea. It could be also the wake-up interrupt looping. So you may also want to try adding some printks (pstore only) into omap_prcm_irq_handler() and omap3xxx_prm_clear_mod_irqs() as that's handling the wake-up event interrupts. > Problem two, where the UART does not wakeup: > What I observed is that sometimes the UART does not wake up properly > i.e. it does not write anything on the console, even where it should. I > can't tell if the read is working properly, the write does not. > From my capture I see that the resume routine was running and the > register should have been written. That means the UART should be up and > running but nothing happens. This seems also be hinting to something needing _reconfigure_io_chain() to be called along the lines of commit cc824534d4fe. > It often works again after the system comes out of resume again (i.e. > RPM suspens and resumes the UART). So it is okay on the next wakeup. Or > the wakeup after next. > From the script: > > | while ((1)) > | do > | > | echo -n 409-chars >/dev/ttyUSB0 > | > | sleep 1 > | a=$(date) > | echo -e "\n#$a" >/dev/ttyUSB0 > | echo $a > | sleep 13; > | done > > I see that sometimes one or two sequential timestamps are missing. And > the it continues like nothing happened. OK. At least it's starting to now sound that the bugs are pretty much the same with 8250 and serial-omap :) 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 3/6] ARM: dts: am437x-gp-evm: Don't use read/write wait monitoring
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.
Also, on NAND there can be no read/write access except at page-level
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.
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.
I request you to fix this instead of disabling it completely,
as you should see significant NAND throughput increase once this
feature works correctly.
- chip->dev_ready in-case of OMAP NAND drivers is set in
drivers/mtd/nand/omap2.c during probe.
if (pdata->dev_ready) {
nand_chip->dev_ready = omap_dev_ready;
nand_chip->chip_delay = 0;
}
Problem is we don't set pdata->dev_ready correctly as part
of platform-data dring GPMC initialization. This was what my
earlier patch for wait-pin monitoring about. But it was a
quick fix for NAND devices.
So, I suggest to fix wait-pin monitoring instead of de-scoping
it from DTS as wait-pin monitoring should boast the NAND
performance significantly.
(please see if you can find an old mail thread which had some
good feedbacks from Ezequiel and Javier about wait-pin monitoring).
This is to get the device ready mechanism work and has nothing to do with
GPMC wait monitoring. Instead the WAIT pin is used to generate the GPMC
interrupt based on the WAIT pin polarity.
To monitor NAND device ready status
from TRM
"-Use software to poll the WAITnSTS bit (n = 0 to 1) of the GPMC_STS register.
OR
-Configure an interrupt that is generated on the WAIT signal change (through the
GPMC_IRQEN [11-8] bits)"
[...]
This patch also gets rid of the below warning when NAND is
accessed for the first time.
omap_l3_noc 4400.ocp: L3 application error: target 13 mod:1 (unclearable)
Can you debug this further.
This warning probably comes when driver tries to access some
"reserved" addresses. Or violate read/write bits.
It is caused because of incorrectly enabled the GPMC wait monitoring. Disabling
the
wait monitoring gets rid of this error. I don't understand what else I should
debug
I'm not sure how a NAND or GPMC feature can cause omap_l3_noc: L3
application error ?
But now as I re-read the text, its probably the L3 interconnect timeout
error due to no response from GPMC. The
Re: [PATCH 15/15] tty: serial: 8250: omap: add dma support
On 09/02/2014 10:15 PM, Tony Lindgren wrote: >> - I see to face two kind of "deaths": >> - the LED still goes on and off and the uart just does not respond >> even if I tell the button print something on the screen (the button >> also changes the frequency of the LED so I know that the button is >> doing something). >> Also from dumping the content of /proc/interrupts it seems that a >> wake up is made, the uart should have restored the registers. > > OK yeah this is the case I was seeing too. So do you just set the > LED triggers to none in sysfs to make it easier to reproduce? Yes. >> - one where the system is dead and the LED does not blink anymore. >> Also my button is dead. > > This I don't think I've seen. This could also be the errata issue on > your earlier rev beagleboard-xm with off-idle. might be. Your pstore hint gave me something. I tried that earlier but somehow assumed that dram content was killed on init. But the content is even there are pressing the reset button :) However, I was able to capture the case where the LED was not blinking: The IIR register says 0xc6 (=> line status error). That is okay. At the same time LSR register says 0xe0. This is not okay. It means that there is some kind of error and at least one error bit is set in this register which is not the case. Also those bits are cleared on read which does not happen here. And we loop forever so the LED does blink anymore. The RX-count register says that it is empty which sense because bit 0 is not set (in LSR). However I can read multiple times from the RX FIFO until I get the "unhandled bus access" error which usually happens right away if the empty FIFO is read on omap3 HW. In the last test I mange to read 91 times before the crash. I hoped that this FIFO read would make the interrupt go away but it did not. The HW seems to be in a strange state. It might be either the errata or something else. I even took the resume routine from omap-serial in case I did something wrong. In my last test it worked for 10minues before the interrupt storm came. This is probably the same thing I see on the omap-serial driver where I got from pstore: [ 32.659271] random: nonblocking pool is initialized [ 212.170623] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [swapper:0] So I *guess* the interrupt routine is looping. This is problem one, no idea what is going on (the register status captured on 8250-omap makes no sense). Problem two, where the UART does not wakeup: What I observed is that sometimes the UART does not wake up properly i.e. it does not write anything on the console, even where it should. I can't tell if the read is working properly, the write does not. >From my capture I see that the resume routine was running and the register should have been written. That means the UART should be up and running but nothing happens. It often works again after the system comes out of resume again (i.e. RPM suspens and resumes the UART). So it is okay on the next wakeup. Or the wakeup after next. >From the script: | while ((1)) | do | | echo -n 409-chars >/dev/ttyUSB0 | | sleep 1 | a=$(date) | echo -e "\n#$a" >/dev/ttyUSB0 | echo $a | sleep 13; | done I see that sometimes one or two sequential timestamps are missing. And the it continues like nothing happened. > 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
[PATCH] ARM: dts: am335x-bone*: Fix model name and update compatibility information
Beaglebone white and beaglebone black differ in tiny little aspects.
This is the reason why we maintain seperate dts for these platforms.
However, there is no real way to decode from dtb which platform it is
since compatible and model name are the same for both platforms.
Fix this so that beaglebone black and beaglebone are identifiable,
while maintaining compatibility for older zImages which might use old
beaglebone compatible flag for black as well.
Reported-by: Tom Rini
Signed-off-by: Nishanth Menon
---
Based on v3.17-rc1:
Before:
beaglebone-black: Boot PASS: http://paste.ubuntu.org.cn/1473558
beaglebone: Boot PASS: http://paste.ubuntu.org.cn/1473559
After:
beaglebone-black: Boot PASS: http://paste.ubuntu.org.cn/1473480
beaglebone: Boot PASS: http://paste.ubuntu.org.cn/1473481
Side notes: Sorry, new IT policies, new paste website needed :(
arch/arm/boot/dts/am335x-bone-common.dtsi |3 ---
arch/arm/boot/dts/am335x-bone.dts |5 +
arch/arm/boot/dts/am335x-boneblack.dts|5 +
3 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index bde1777..d9d9869 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -7,9 +7,6 @@
*/
/ {
- model = "TI AM335x BeagleBone";
- compatible = "ti,am335x-bone", "ti,am33xx";
-
cpus {
cpu@0 {
cpu0-supply = <&dcdc2_reg>;
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index 94ee427..83d40f7 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -10,6 +10,11 @@
#include "am33xx.dtsi"
#include "am335x-bone-common.dtsi"
+/ {
+ model = "TI AM335x BeagleBone";
+ compatible = "ti,am335x-bone", "ti,am33xx";
+};
+
&ldo3_reg {
regulator-min-microvolt = <180>;
regulator-max-microvolt = <330>;
diff --git a/arch/arm/boot/dts/am335x-boneblack.dts
b/arch/arm/boot/dts/am335x-boneblack.dts
index 305975d..901739f 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -10,6 +10,11 @@
#include "am33xx.dtsi"
#include "am335x-bone-common.dtsi"
+/ {
+ model = "TI AM335x BeagleBone Black";
+ compatible = "ti,am335x-bone-black", "ti,am335x-bone", "ti,am33xx";
+};
+
&ldo3_reg {
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
--
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
Re: [PATCH 5/5] phy: exynos5-usbdrd: Adding Kconfig dependency for Exynos7
On Wed, Sep 03, 2014 at 09:32:14AM +0530, Vivek Gautam wrote: > On Tue, Sep 2, 2014 at 8:07 PM, Felipe Balbi wrote: > > On Mon, Sep 01, 2014 at 01:30:21PM +0530, Vivek Gautam wrote: > >> On Thu, Aug 28, 2014 at 8:36 PM, Daniele Forsi wrote: > >> > 2014-08-28 10:02 GMT+02:00 Vivek Gautam: > >> > > >> >> This USB 3.0 PHY controller is also present on Exynos7 > >> >> platform, so adding the dependency on ARCH_EXYNOS7 for this driver. > >> > > >> >> +++ b/drivers/phy/Kconfig > >> >> @@ -186,7 +186,7 @@ config PHY_EXYNOS5250_USB2 > >> >> > >> >> config PHY_EXYNOS5_USBDRD > >> >> tristate "Exynos5 SoC series USB DRD PHY driver" > >> >> - depends on ARCH_EXYNOS5 && OF > >> >> + depends on (ARCH_EXYNOS5 || ARCH_EXYNOS7) && OF > >> > > >> > shouldn't that prompt and its help text be updated to mention also > >> > Exynos7? > >> > >> Right, even that has to be updated accordingly. Will update the same in > >> next > >> version of the patch. Thanks for pointing this. > > > > I would rather change that to ARCH_EXYNOS, unless Kishon doesn't like > > that idea. The thing is that this will likely need to be patches for > > exynos8, 9, 10, 11... > > Yes, after we have the 2nd version of Exynos7 support patches, it makes > more sense to keep dependency on ARCH_EXYNOS. thank you, that'll help new silicon wakeup; one less thing to patch :-p -- balbi signature.asc Description: Digital signature
Re: [PATCH 0/2] tlv320aic31xx PLL programming fix and cleanup
On Wed, Sep 03, 2014 at 03:52:32PM +0300, Jyri Sarha wrote: > The first patch is the fix and the second is only a cleanup. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH] drivers/rtc/rtc-ds1307.c: Support optional wakeup interrupt source
On 08/21/2014 11:12 AM, Nishanth Menon wrote:
> With the recent pinctrl-single changes, SoCs such as Texas
> Instrument's OMAP processors can treat wake-up events from deeper idle
> states as interrupts.
>
> 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.
>
> Finally, to pass the wake-up interrupt in the dts file,
> interrupts-extended property needs to be passed.
>
> This is similar in approach to commit 2a0b965cfb6e ("serial: omap: Add
> support for optional wake-up")
>
> Signed-off-by: Nishanth Menon
> ---
Hi,
Gentle Ping.
Regards,
Nishanth Menon
> drivers/rtc/rtc-ds1307.c | 57
> ++
> 1 file changed, 57 insertions(+)
>
> diff --git a/drivers/rtc/rtc-ds1307.c b/drivers/rtc/rtc-ds1307.c
> index f03d5ba..5feedfc 100644
> --- a/drivers/rtc/rtc-ds1307.c
> +++ b/drivers/rtc/rtc-ds1307.c
> @@ -15,6 +15,8 @@
> #include
> #include
> #include
> +#include
> +#include
> #include
> #include
> #include
> @@ -115,6 +117,7 @@ struct ds1307 {
> struct i2c_client *client;
> struct rtc_device *rtc;
> struct work_struct work;
> + int wakeirq;
> s32 (*read_block_data)(const struct i2c_client *client, u8 command,
> u8 length, u8 *values);
> s32 (*write_block_data)(const struct i2c_client *client, u8 command,
> @@ -835,6 +838,34 @@ ds1307_nvram_write(struct file *filp, struct kobject
> *kobj,
>
> /*--*/
>
> +static int ds1307_i2c_suspend(struct i2c_client *client, pm_message_t mesg)
> +{
> + struct ds1307 *ds1307 = i2c_get_clientdata(client);
> + struct device *dev = &client->dev;
> +
> + if (!ds1307->wakeirq)
> + return 0;
> +
> + if (device_may_wakeup(dev))
> + enable_irq(ds1307->wakeirq);
> +
> + return 0;
> +}
> +
> +static int ds1307_i2c_resume(struct i2c_client *client)
> +{
> + struct ds1307 *ds1307 = i2c_get_clientdata(client);
> + struct device *dev = &client->dev;
> +
> + if (!ds1307->wakeirq)
> + return 0;
> +
> + if (device_may_wakeup(dev))
> + disable_irq_nosync(ds1307->wakeirq);
> +
> + return 0;
> +}
> +
> static int ds1307_probe(struct i2c_client *client,
> const struct i2c_device_id *id)
> {
> @@ -1116,6 +1147,8 @@ read_rtc:
> }
>
> if (want_irq) {
> + struct device_node *node = client->dev.of_node;
> +
> err = request_irq(client->irq, ds1307_irq, IRQF_SHARED,
> ds1307->rtc->name, client);
> if (err) {
> @@ -1125,6 +1158,28 @@ read_rtc:
>
> set_bit(HAS_ALARM, &ds1307->flags);
> dev_dbg(&client->dev, "got IRQ %d\n", client->irq);
> + if (node)
> + ds1307->wakeirq = irq_of_parse_and_map(node, 1);
> +
> + if (ds1307->wakeirq <= 0)
> + ds1307->wakeirq = 0;
> + else
> + err = devm_request_irq(&client->dev,
> +ds1307->wakeirq,
> +ds1307_irq,
> +IRQF_ONESHOT,
> +ds1307->rtc->name,
> +client);
> + if (err) {
> + dev_err(&client->dev, "unable to get wakeIRQ
> %d\n",
> + err);
> + free_irq(client->irq, client);
> + goto exit;
> + }
> +
> + /* We enable the interrupt only during suspend path */
> + if (ds1307->wakeirq)
> + disable_irq_nosync(ds1307->wakeirq);
> }
> }
>
> @@ -1189,6 +1244,8 @@ static struct i2c_driver ds1307_driver = {
> },
> .probe = ds1307_probe,
> .remove = ds1307_remove,
> + .suspend= ds1307_i2c_suspend,
> + .resume = ds1307_i2c_resume,
> .id_table = ds1307_id,
> };
>
>
--
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] ARM: dts: DRA7: Add PMU nodes
On 08/19/2014 08:54 AM, Nishanth Menon wrote:
> From: Lucas Weaver
>
> DRA74x and DRA72x family of processors vary slightly in the number
> of CPUs. So, add different instances of PMU for each of these processor
> groups. Further, since the interrupts bypass crossbar and are directly
> connected to GIC, mark the dts nodes with relevant information.
>
> Tested with perf utility.
>
> Reviewed-by: Felipe Balbi
> Signed-off-by: Lucas Weaver
> Signed-off-by: Nishanth Menon
> ---
Hi,
Gentle ping..
Regards,
Nishanth Menon
> arch/arm/boot/dts/dra72x.dtsi |5 +
> arch/arm/boot/dts/dra74x.dtsi |6 ++
> 2 files changed, 11 insertions(+)
>
> diff --git a/arch/arm/boot/dts/dra72x.dtsi b/arch/arm/boot/dts/dra72x.dtsi
> index f1ec22f..e5a3d23 100644
> --- a/arch/arm/boot/dts/dra72x.dtsi
> +++ b/arch/arm/boot/dts/dra72x.dtsi
> @@ -22,4 +22,9 @@
> reg = <0>;
> };
> };
> +
> + pmu {
> + compatible = "arm,cortex-a15-pmu";
> + interrupts = ;
> + };
> };
> diff --git a/arch/arm/boot/dts/dra74x.dtsi b/arch/arm/boot/dts/dra74x.dtsi
> index a4e8bb9..3be544c 100644
> --- a/arch/arm/boot/dts/dra74x.dtsi
> +++ b/arch/arm/boot/dts/dra74x.dtsi
> @@ -38,4 +38,10 @@
> reg = <1>;
> };
> };
> +
> + pmu {
> + compatible = "arm,cortex-a15-pmu";
> + interrupts = ,
> + ;
> + };
> };
>
--
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] tlv320aic31xx PLL programming fix and cleanup
The first patch is the fix and the second is only a cleanup. Jyri Sarha (2): ASoC: tlv320aic31xx: Fix 24bit samples with I2S format and 12MHz mclk ASoC: tlv320aic31xx: Choose PLL p divider automatically sound/soc/codecs/tlv320aic31xx.c | 128 +++--- 1 file changed, 77 insertions(+), 51 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
Re: [PATCH 0/2] tlv320aic31xx PLL programming fix and cleanup
On 09/03/2014 03:52 PM, Jyri Sarha wrote: > The first patch is the fix and the second is only a cleanup. > > Jyri Sarha (2): > ASoC: tlv320aic31xx: Fix 24bit samples with I2S format and 12MHz mclk > ASoC: tlv320aic31xx: Choose PLL p divider automatically > > sound/soc/codecs/tlv320aic31xx.c | 128 > +++--- > 1 file changed, 77 insertions(+), 51 deletions(-) Tested-by: Peter Ujfalusi -- 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 00/26] genirq: fix use of irq_find_mapping outside of legal RCU context
On Tue, Aug 26, 2014 at 11:03:15AM +0100, Marc Zyngier wrote:
> A number of irqchip drivers are directly calling irq_find_mapping,
> which may use a rcu_read_lock call when walking the radix tree.
>
> Turns out that if you hit that point with CONFIG_PROVE_RCU enabled,
> the kernel will shout at you, as using RCU in this context may be
> illegal (specially if coming from the idle state, where RCU would be
> in a quiescent state).
>
> A possible fix would be to wrap calls to irq_find_mapping into a
> RCU_NONIDLE macro, but that really looks ugly.
>
> This patch series introduce another generic IRQ entry point
> (handle_domain_irq), which has the exact same behaviour as handle_IRQ
> (as defined on arm, arm64 and openrisc), except that it also takes a
> irq_domain pointer. This allows the logical IRQ lookup to be done
> inside the irq_{enter,exit} section, which contains a
> rcu_irq_{enter,exit}, making it safe.
>
> A number of irqchips are then converted to this new entry point. I've
> converted all the direct users of irq_find_mapping, except for the
> cases where it was used as a chained handler (chained_irq_{enter,exit}
> makes it safe). Users of irq_linear_revmap are safe as well. I've
> given it some light testing on arm64.
>
> The series is also available in my tree:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git
> handle_domain_irq
>
> From v1 [1]:
> - Made handle_domain_irq a generic function
> - Added OpenRISC to the list of affected architectures
> - Converted more interrupt controllers
> - Rebased on v3.17-rc1
>
> [1]: https://lkml.org/lkml/2014/7/8/381
>
> Marc Zyngier (26):
> genirq: add irq_domain-aware core IRQ handler
> arm64: convert handle_IRQ to use __handle_domain_irq
> ARM: convert handle_IRQ to use __handle_domain_irq
> openrisc: convert handle_IRQ to use __handle_domain_irq
> irqchip: GIC: convert to handle_domain_irq
> irqchip: armada-370-xp: convert to handle_domain_irq
> irqchip: clps711x: convert to handle_domain_irq
> irqchip: mmp: convert to handle_domain_irq
> irqchip: mxs: convert to handle_domain_irq
> irqchip: orion: convert to handle_domain_irq
> irqchip: s3c24xx: convert to handle_domain_irq
> irqchip: sirfsoc: convert to handle_domain_irq
> irqchip: sun4i: convert to handle_domain_irq
> irqchip: versatile-fpga: convert to handle_domain_irq
> irqchip: vic: convert to handle_domain_irq
> irqchip: vt8500: convert to handle_domain_irq
> irqchip: zevio: convert to handle_domain_irq
> irqchip: GICv3: convert to handle_domain_irq
> irqchip: atmel-aic: convert to handle_domain_irq
> irqchip: atmel-aic5: convert to handle_domain_irq
> irqchip: or1k-pic: convert to handle_domain_irq
> ARM: imx: avic: convert to handle_domain_irq
> ARM: imx: tzic: convert to handle_domain_irq
> ARM: omap2: irq: convert to handle_domain_irq
> arm64: get rid of handle_IRQ
> openrisc: get rid of handle_IRQ
>
> arch/arm/Kconfig | 1 +
> arch/arm/kernel/irq.c| 19 +---
> arch/arm/mach-imx/avic.c | 2 +-
> arch/arm/mach-imx/tzic.c | 3 +--
> arch/arm/mach-omap2/irq.c| 3 +--
> arch/arm64/Kconfig | 1 +
> arch/arm64/include/asm/hardirq.h | 2 --
> arch/arm64/kernel/irq.c | 27 ---
> arch/openrisc/Kconfig| 1 +
> arch/openrisc/include/asm/irq.h | 1 -
> arch/openrisc/kernel/irq.c | 12 ---
> drivers/irqchip/irq-armada-370-xp.c | 19
> drivers/irqchip/irq-atmel-aic.c | 4 +---
> drivers/irqchip/irq-atmel-aic5.c | 4 +---
> drivers/irqchip/irq-clps711x.c | 18 ++--
> drivers/irqchip/irq-gic-v3.c | 13 ++-
> drivers/irqchip/irq-gic.c| 3 +--
> drivers/irqchip/irq-mmp.c| 10 -
> drivers/irqchip/irq-mxs.c| 3 +--
> drivers/irqchip/irq-or1k-pic.c | 4 ++--
> drivers/irqchip/irq-orion.c | 5 ++---
> drivers/irqchip/irq-s3c24xx.c| 4 +---
> drivers/irqchip/irq-sirfsoc.c| 6 ++
> drivers/irqchip/irq-sun4i.c | 5 ++---
> drivers/irqchip/irq-versatile-fpga.c | 2 +-
> drivers/irqchip/irq-vic.c| 2 +-
> drivers/irqchip/irq-vt8500.c | 5 ++---
> drivers/irqchip/irq-zevio.c | 3 +--
> include/linux/irqdesc.h | 19
> kernel/irq/Kconfig | 3 +++
> kernel/irq/irqdesc.c | 42
>
> 31 files changed, 116 insertions(+), 130 deletions(-)
Whole series applied to irqchip/handle_domain with Acks applied and
subject line tweaked for capitalization. Turns out we have the openrisc
Ack from:
https://lkml.kernel.org/r/20140827170905.ga5...@chokladfabriken.org
I'll let this sit in -next for a few days and then merge it into
irqchip/core.
thx,
Jason.
--
To unsubscribe from th
[PATCH 1/2] ASoC: tlv320aic31xx: Fix 24bit samples with I2S format and 12MHz mclk
I2S format requires bitclock to have an exact amount of cycles in a
frame for audio to work cleanly. With dsp formats that is not so
important.
Updates aic31xx_setup_pll() to look for a line in aic31xx_divs table
that produces the best match for the bitclock and adds lines to
aic31xx_divs for 12MHz mclk and 24bit samples.
Signed-off-by: Jyri Sarha
---
sound/soc/codecs/tlv320aic31xx.c | 51 +-
1 file changed, 39 insertions(+), 12 deletions(-)
diff --git a/sound/soc/codecs/tlv320aic31xx.c b/sound/soc/codecs/tlv320aic31xx.c
index 0f64c78..aea9e1f 100644
--- a/sound/soc/codecs/tlv320aic31xx.c
+++ b/sound/soc/codecs/tlv320aic31xx.c
@@ -189,46 +189,57 @@ static const struct aic31xx_rate_divs aic31xx_divs[] = {
/* mclk rate pll: p j d dosr ndac mdac aors nadc madc */
/* 8k rate */
{1200, 8000, 1, 8, 1920, 128, 48, 2, 128, 48, 2},
+ {1200, 8000, 1, 8, 1920, 128, 32, 3, 128, 32, 3},
{2400, 8000, 2, 8, 1920, 128, 48, 2, 128, 48, 2},
{2500, 8000, 2, 7, 8643, 128, 48, 2, 128, 48, 2},
/* 11.025k rate */
{1200, 11025, 1, 7, 5264, 128, 32, 2, 128, 32, 2},
+ {1200, 11025, 1, 8, 4672, 128, 24, 3, 128, 24, 3},
{2400, 11025, 2, 7, 5264, 128, 32, 2, 128, 32, 2},
{2500, 11025, 2, 7, 2253, 128, 32, 2, 128, 32, 2},
/* 16k rate */
{1200, 16000, 1, 8, 1920, 128, 24, 2, 128, 24, 2},
+ {1200, 16000, 1, 8, 1920, 128, 16, 3, 128, 16, 3},
{2400, 16000, 2, 8, 1920, 128, 24, 2, 128, 24, 2},
{2500, 16000, 2, 7, 8643, 128, 24, 2, 128, 24, 2},
/* 22.05k rate */
{1200, 22050, 1, 7, 5264, 128, 16, 2, 128, 16, 2},
+ {1200, 22050, 1, 8, 4672, 128, 12, 3, 128, 12, 3},
{2400, 22050, 2, 7, 5264, 128, 16, 2, 128, 16, 2},
{2500, 22050, 2, 7, 2253, 128, 16, 2, 128, 16, 2},
/* 32k rate */
{1200, 32000, 1, 8, 1920, 128, 12, 2, 128, 12, 2},
+ {1200, 32000, 1, 8, 1920, 128, 8, 3, 128, 8, 3},
{2400, 32000, 2, 8, 1920, 128, 12, 2, 128, 12, 2},
{2500, 32000, 2, 7, 8643, 128, 12, 2, 128, 12, 2},
/* 44.1k rate */
{1200, 44100, 1, 7, 5264, 128, 8, 2, 128, 8, 2},
+ {1200, 44100, 1, 8, 4672, 128, 6, 3, 128, 6, 3},
{2400, 44100, 2, 7, 5264, 128, 8, 2, 128, 8, 2},
{2500, 44100, 2, 7, 2253, 128, 8, 2, 128, 8, 2},
/* 48k rate */
{1200, 48000, 1, 8, 1920, 128, 8, 2, 128, 8, 2},
+ {1200, 48000, 1, 7, 6800, 96, 5, 4,96, 5, 4},
{2400, 48000, 2, 8, 1920, 128, 8, 2, 128, 8, 2},
{2500, 48000, 2, 7, 8643, 128, 8, 2, 128, 8, 2},
/* 88.2k rate */
{1200, 88200, 1, 7, 5264, 64, 8, 2,64, 8, 2},
+ {1200, 88200, 1, 8, 4672, 64, 6, 3,64, 6, 3},
{2400, 88200, 2, 7, 5264, 64, 8, 2,64, 8, 2},
{2500, 88200, 2, 7, 2253, 64, 8, 2,64, 8, 2},
/* 96k rate */
{1200, 96000, 1, 8, 1920, 64, 8, 2,64, 8, 2},
+ {1200, 96000, 1, 7, 6800, 48, 5, 4,48, 5, 4},
{2400, 96000, 2, 8, 1920, 64, 8, 2,64, 8, 2},
{2500, 96000, 2, 7, 8643, 64, 8, 2,64, 8, 2},
/* 176.4k rate */
{1200, 176400, 1, 7, 5264, 32, 8, 2,32, 8, 2},
+ {1200, 176400, 1, 8, 4672, 32, 6, 3,32, 6, 3},
{2400, 176400, 2, 7, 5264, 32, 8, 2,32, 8, 2},
{2500, 176400, 2, 7, 2253, 32, 8, 2,32, 8, 2},
/* 192k rate */
{1200, 192000, 1, 8, 1920, 32, 8, 2,32, 8, 2},
+ {1200, 192000, 1, 7, 6800, 24, 5, 4,24, 5, 4},
{2400, 192000, 2, 8, 1920, 32, 8, 2,32, 8, 2},
{2500, 192000, 2, 7, 8643, 32, 8, 2,32, 8, 2},
};
@@ -680,7 +691,9 @@ static int aic31xx_setup_pll(struct snd_soc_codec *codec,
struct snd_pcm_hw_params *params)
{
struct aic31xx_priv *aic31xx = snd_soc_codec_get_drvdata(codec);
+ int bclk_score = snd_soc_params_to_frame_size(params);
int bclk_n = 0;
+ int match = -1;
int i;
/* Use PLL as CODEC_CLKIN and DAC_CLK as BDIV_CLKIN */
@@ -69
[PATCH 2/2] ASoC: tlv320aic31xx: Choose PLL p divider automatically
This simplifies aic31xx_divs table. There is no more need for p_val or
separate lines for 12 and 24 MHz mclks.
Signed-off-by: Jyri Sarha
---
sound/soc/codecs/tlv320aic31xx.c | 101 +++---
1 file changed, 50 insertions(+), 51 deletions(-)
diff --git a/sound/soc/codecs/tlv320aic31xx.c b/sound/soc/codecs/tlv320aic31xx.c
index aea9e1f..733da78 100644
--- a/sound/soc/codecs/tlv320aic31xx.c
+++ b/sound/soc/codecs/tlv320aic31xx.c
@@ -167,13 +167,13 @@ struct aic31xx_priv {
struct regulator_bulk_data supplies[AIC31XX_NUM_SUPPLIES];
struct aic31xx_disable_nb disable_nb[AIC31XX_NUM_SUPPLIES];
unsigned int sysclk;
+ u8 p_div;
int rate_div_line;
};
struct aic31xx_rate_divs {
- u32 mclk;
+ u32 mclk_p;
u32 rate;
- u8 p_val;
u8 pll_j;
u16 pll_d;
u16 dosr;
@@ -186,62 +186,51 @@ struct aic31xx_rate_divs {
/* ADC dividers can be disabled by cofiguring them to 0 */
static const struct aic31xx_rate_divs aic31xx_divs[] = {
- /* mclk rate pll: p j d dosr ndac mdac aors nadc madc */
+ /* mclk/prate pll: j ddosr ndac mdac aors nadc madc */
/* 8k rate */
- {1200, 8000, 1, 8, 1920, 128, 48, 2, 128, 48, 2},
- {1200, 8000, 1, 8, 1920, 128, 32, 3, 128, 32, 3},
- {2400, 8000, 2, 8, 1920, 128, 48, 2, 128, 48, 2},
- {2500, 8000, 2, 7, 8643, 128, 48, 2, 128, 48, 2},
+ {1200, 8000, 8, 1920,128, 48, 2, 128, 48, 2},
+ {1200, 8000, 8, 1920,128, 32, 3, 128, 32, 3},
+ {1250, 8000, 7, 8643,128, 48, 2, 128, 48, 2},
/* 11.025k rate */
- {1200, 11025, 1, 7, 5264, 128, 32, 2, 128, 32, 2},
- {1200, 11025, 1, 8, 4672, 128, 24, 3, 128, 24, 3},
- {2400, 11025, 2, 7, 5264, 128, 32, 2, 128, 32, 2},
- {2500, 11025, 2, 7, 2253, 128, 32, 2, 128, 32, 2},
+ {1200, 11025, 7, 5264,128, 32, 2, 128, 32, 2},
+ {1200, 11025, 8, 4672,128, 24, 3, 128, 24, 3},
+ {1250, 11025, 7, 2253,128, 32, 2, 128, 32, 2},
/* 16k rate */
- {1200, 16000, 1, 8, 1920, 128, 24, 2, 128, 24, 2},
- {1200, 16000, 1, 8, 1920, 128, 16, 3, 128, 16, 3},
- {2400, 16000, 2, 8, 1920, 128, 24, 2, 128, 24, 2},
- {2500, 16000, 2, 7, 8643, 128, 24, 2, 128, 24, 2},
+ {1200, 16000, 8, 1920,128, 24, 2, 128, 24, 2},
+ {1200, 16000, 8, 1920,128, 16, 3, 128, 16, 3},
+ {1250, 16000, 7, 8643,128, 24, 2, 128, 24, 2},
/* 22.05k rate */
- {1200, 22050, 1, 7, 5264, 128, 16, 2, 128, 16, 2},
- {1200, 22050, 1, 8, 4672, 128, 12, 3, 128, 12, 3},
- {2400, 22050, 2, 7, 5264, 128, 16, 2, 128, 16, 2},
- {2500, 22050, 2, 7, 2253, 128, 16, 2, 128, 16, 2},
+ {1200, 22050, 7, 5264,128, 16, 2, 128, 16, 2},
+ {1200, 22050, 8, 4672,128, 12, 3, 128, 12, 3},
+ {1250, 22050, 7, 2253,128, 16, 2, 128, 16, 2},
/* 32k rate */
- {1200, 32000, 1, 8, 1920, 128, 12, 2, 128, 12, 2},
- {1200, 32000, 1, 8, 1920, 128, 8, 3, 128, 8, 3},
- {2400, 32000, 2, 8, 1920, 128, 12, 2, 128, 12, 2},
- {2500, 32000, 2, 7, 8643, 128, 12, 2, 128, 12, 2},
+ {1200, 32000, 8, 1920,128, 12, 2, 128, 12, 2},
+ {1200, 32000, 8, 1920,128, 8, 3, 128, 8, 3},
+ {1250, 32000, 7, 8643,128, 12, 2, 128, 12, 2},
/* 44.1k rate */
- {1200, 44100, 1, 7, 5264, 128, 8, 2, 128, 8, 2},
- {1200, 44100, 1, 8, 4672, 128, 6, 3, 128, 6, 3},
- {2400, 44100, 2, 7, 5264, 128, 8, 2, 128, 8, 2},
- {2500, 44100, 2, 7, 2253, 128, 8, 2, 128, 8, 2},
+ {1200, 44100, 7, 5264,128, 8, 2, 128, 8, 2},
+ {1200, 44100, 8, 4672,128, 6, 3, 128, 6, 3},
+ {1250, 44100, 7, 2253,128, 8, 2, 128, 8, 2},
/* 48k rate */
- {1200, 48000, 1, 8, 1920, 128, 8, 2, 128, 8, 2},
- {1200, 48000, 1, 7, 6800, 96, 5, 4,96, 5, 4},
- {2400, 48000, 2, 8, 1920, 128, 8, 2, 128, 8, 2},
- {2500, 48000, 2, 7, 8643, 128, 8, 2,
Re: [PATCH v2 00/26] genirq: fix use of irq_find_mapping outside of legal RCU context
On 03/09/14 13:37, Jason Cooper wrote:
> On Wed, Sep 03, 2014 at 02:25:09PM +0200, Thomas Gleixner wrote:
>> On Wed, 3 Sep 2014, Marc Zyngier wrote:
>>> [Dropping li...@openrisc.net from the CC list]
>>>
>>> On 03/09/14 13:09, Thomas Gleixner wrote:
On Wed, 3 Sep 2014, Jason Cooper wrote:
> On Wed, Aug 27, 2014 at 10:33:44AM +0100, Marc Zyngier wrote:
>> Hi Thomas,
>>
>> On Tue, Aug 26 2014 at 10:34:51 pm BST, Thomas Gleixner
>> wrote:
>>> On Tue, 26 Aug 2014, Marc Zyngier wrote:
>>>
A number of irqchip drivers are directly calling irq_find_mapping,
which may use a rcu_read_lock call when walking the radix tree.
Turns out that if you hit that point with CONFIG_PROVE_RCU enabled,
the kernel will shout at you, as using RCU in this context may be
illegal (specially if coming from the idle state, where RCU would be
in a quiescent state).
A possible fix would be to wrap calls to irq_find_mapping into a
RCU_NONIDLE macro, but that really looks ugly.
This patch series introduce another generic IRQ entry point
(handle_domain_irq), which has the exact same behaviour as handle_IRQ
(as defined on arm, arm64 and openrisc), except that it also takes a
irq_domain pointer. This allows the logical IRQ lookup to be done
inside the irq_{enter,exit} section, which contains a
rcu_irq_{enter,exit}, making it safe.
>>>
>>> Looks good. Should this be routed to the genirq tree?
>>
>> I'm happy for you to take this series, provided the architecture
>> maintainers agree on it (I'm still to hear from the openrisc guys, and
>> their mailing-list seems to positively hate my guts).
>
> I think everyone's had a chance to look over it by now. Thomas, shall I
> take the series?
Yes please.
>>>
>>> Do you want a pull request? Or are you picking up the patches from the ML?
>>
>> Did you pick up the Acked/Reviewed/Ignored-by tags?
>
> Marc, unless you've already done it, I'll pull from the ml, since I need
> to apply the Acked-bys and tweak the subject lines.
If you're going to repaint the subject lines, then I'll leave you to it! ;-)
M.
--
Jazz is not dead. It just smells funny...
--
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 00/26] genirq: fix use of irq_find_mapping outside of legal RCU context
On 03/09/14 13:25, Thomas Gleixner wrote:
> On Wed, 3 Sep 2014, Marc Zyngier wrote:
>> [Dropping li...@openrisc.net from the CC list]
>>
>> On 03/09/14 13:09, Thomas Gleixner wrote:
>>> On Wed, 3 Sep 2014, Jason Cooper wrote:
>>>
On Wed, Aug 27, 2014 at 10:33:44AM +0100, Marc Zyngier wrote:
> Hi Thomas,
>
> On Tue, Aug 26 2014 at 10:34:51 pm BST, Thomas Gleixner
> wrote:
>> On Tue, 26 Aug 2014, Marc Zyngier wrote:
>>
>>> A number of irqchip drivers are directly calling irq_find_mapping,
>>> which may use a rcu_read_lock call when walking the radix tree.
>>>
>>> Turns out that if you hit that point with CONFIG_PROVE_RCU enabled,
>>> the kernel will shout at you, as using RCU in this context may be
>>> illegal (specially if coming from the idle state, where RCU would be
>>> in a quiescent state).
>>>
>>> A possible fix would be to wrap calls to irq_find_mapping into a
>>> RCU_NONIDLE macro, but that really looks ugly.
>>>
>>> This patch series introduce another generic IRQ entry point
>>> (handle_domain_irq), which has the exact same behaviour as handle_IRQ
>>> (as defined on arm, arm64 and openrisc), except that it also takes a
>>> irq_domain pointer. This allows the logical IRQ lookup to be done
>>> inside the irq_{enter,exit} section, which contains a
>>> rcu_irq_{enter,exit}, making it safe.
>>
>> Looks good. Should this be routed to the genirq tree?
>
> I'm happy for you to take this series, provided the architecture
> maintainers agree on it (I'm still to hear from the openrisc guys, and
> their mailing-list seems to positively hate my guts).
I think everyone's had a chance to look over it by now. Thomas, shall I
take the series?
>>>
>>> Yes please.
>>
>> Do you want a pull request? Or are you picking up the patches from the ML?
>
> Did you pick up the Acked/Reviewed/Ignored-by tags?
I have them in a separate branch that can be pushed out as required.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
--
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 00/26] genirq: fix use of irq_find_mapping outside of legal RCU context
On Wed, Sep 03, 2014 at 02:25:09PM +0200, Thomas Gleixner wrote:
> On Wed, 3 Sep 2014, Marc Zyngier wrote:
> > [Dropping li...@openrisc.net from the CC list]
> >
> > On 03/09/14 13:09, Thomas Gleixner wrote:
> > > On Wed, 3 Sep 2014, Jason Cooper wrote:
> > >
> > >> On Wed, Aug 27, 2014 at 10:33:44AM +0100, Marc Zyngier wrote:
> > >>> Hi Thomas,
> > >>>
> > >>> On Tue, Aug 26 2014 at 10:34:51 pm BST, Thomas Gleixner
> > >>> wrote:
> > On Tue, 26 Aug 2014, Marc Zyngier wrote:
> >
> > > A number of irqchip drivers are directly calling irq_find_mapping,
> > > which may use a rcu_read_lock call when walking the radix tree.
> > >
> > > Turns out that if you hit that point with CONFIG_PROVE_RCU enabled,
> > > the kernel will shout at you, as using RCU in this context may be
> > > illegal (specially if coming from the idle state, where RCU would be
> > > in a quiescent state).
> > >
> > > A possible fix would be to wrap calls to irq_find_mapping into a
> > > RCU_NONIDLE macro, but that really looks ugly.
> > >
> > > This patch series introduce another generic IRQ entry point
> > > (handle_domain_irq), which has the exact same behaviour as handle_IRQ
> > > (as defined on arm, arm64 and openrisc), except that it also takes a
> > > irq_domain pointer. This allows the logical IRQ lookup to be done
> > > inside the irq_{enter,exit} section, which contains a
> > > rcu_irq_{enter,exit}, making it safe.
> >
> > Looks good. Should this be routed to the genirq tree?
> > >>>
> > >>> I'm happy for you to take this series, provided the architecture
> > >>> maintainers agree on it (I'm still to hear from the openrisc guys, and
> > >>> their mailing-list seems to positively hate my guts).
> > >>
> > >> I think everyone's had a chance to look over it by now. Thomas, shall I
> > >> take the series?
> > >
> > > Yes please.
> >
> > Do you want a pull request? Or are you picking up the patches from the ML?
>
> Did you pick up the Acked/Reviewed/Ignored-by tags?
Marc, unless you've already done it, I'll pull from the ml, since I need
to apply the Acked-bys and tweak the subject lines.
thx,
Jason.
--
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 00/26] genirq: fix use of irq_find_mapping outside of legal RCU context
On Wed, 3 Sep 2014, Marc Zyngier wrote:
> [Dropping li...@openrisc.net from the CC list]
>
> On 03/09/14 13:09, Thomas Gleixner wrote:
> > On Wed, 3 Sep 2014, Jason Cooper wrote:
> >
> >> On Wed, Aug 27, 2014 at 10:33:44AM +0100, Marc Zyngier wrote:
> >>> Hi Thomas,
> >>>
> >>> On Tue, Aug 26 2014 at 10:34:51 pm BST, Thomas Gleixner
> >>> wrote:
> On Tue, 26 Aug 2014, Marc Zyngier wrote:
>
> > A number of irqchip drivers are directly calling irq_find_mapping,
> > which may use a rcu_read_lock call when walking the radix tree.
> >
> > Turns out that if you hit that point with CONFIG_PROVE_RCU enabled,
> > the kernel will shout at you, as using RCU in this context may be
> > illegal (specially if coming from the idle state, where RCU would be
> > in a quiescent state).
> >
> > A possible fix would be to wrap calls to irq_find_mapping into a
> > RCU_NONIDLE macro, but that really looks ugly.
> >
> > This patch series introduce another generic IRQ entry point
> > (handle_domain_irq), which has the exact same behaviour as handle_IRQ
> > (as defined on arm, arm64 and openrisc), except that it also takes a
> > irq_domain pointer. This allows the logical IRQ lookup to be done
> > inside the irq_{enter,exit} section, which contains a
> > rcu_irq_{enter,exit}, making it safe.
>
> Looks good. Should this be routed to the genirq tree?
> >>>
> >>> I'm happy for you to take this series, provided the architecture
> >>> maintainers agree on it (I'm still to hear from the openrisc guys, and
> >>> their mailing-list seems to positively hate my guts).
> >>
> >> I think everyone's had a chance to look over it by now. Thomas, shall I
> >> take the series?
> >
> > Yes please.
>
> Do you want a pull request? Or are you picking up the patches from the ML?
Did you pick up the Acked/Reviewed/Ignored-by tags?
--
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 00/26] genirq: fix use of irq_find_mapping outside of legal RCU context
[Dropping li...@openrisc.net from the CC list]
On 03/09/14 13:09, Thomas Gleixner wrote:
> On Wed, 3 Sep 2014, Jason Cooper wrote:
>
>> On Wed, Aug 27, 2014 at 10:33:44AM +0100, Marc Zyngier wrote:
>>> Hi Thomas,
>>>
>>> On Tue, Aug 26 2014 at 10:34:51 pm BST, Thomas Gleixner
>>> wrote:
On Tue, 26 Aug 2014, Marc Zyngier wrote:
> A number of irqchip drivers are directly calling irq_find_mapping,
> which may use a rcu_read_lock call when walking the radix tree.
>
> Turns out that if you hit that point with CONFIG_PROVE_RCU enabled,
> the kernel will shout at you, as using RCU in this context may be
> illegal (specially if coming from the idle state, where RCU would be
> in a quiescent state).
>
> A possible fix would be to wrap calls to irq_find_mapping into a
> RCU_NONIDLE macro, but that really looks ugly.
>
> This patch series introduce another generic IRQ entry point
> (handle_domain_irq), which has the exact same behaviour as handle_IRQ
> (as defined on arm, arm64 and openrisc), except that it also takes a
> irq_domain pointer. This allows the logical IRQ lookup to be done
> inside the irq_{enter,exit} section, which contains a
> rcu_irq_{enter,exit}, making it safe.
Looks good. Should this be routed to the genirq tree?
>>>
>>> I'm happy for you to take this series, provided the architecture
>>> maintainers agree on it (I'm still to hear from the openrisc guys, and
>>> their mailing-list seems to positively hate my guts).
>>
>> I think everyone's had a chance to look over it by now. Thomas, shall I
>> take the series?
>
> Yes please.
Do you want a pull request? Or are you picking up the patches from the ML?
Thanks,
M.
--
Jazz is not dead. It just smells funny...
--
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 00/26] genirq: fix use of irq_find_mapping outside of legal RCU context
On Wed, 3 Sep 2014, Jason Cooper wrote:
> On Wed, Aug 27, 2014 at 10:33:44AM +0100, Marc Zyngier wrote:
> > Hi Thomas,
> >
> > On Tue, Aug 26 2014 at 10:34:51 pm BST, Thomas Gleixner
> > wrote:
> > > On Tue, 26 Aug 2014, Marc Zyngier wrote:
> > >
> > >> A number of irqchip drivers are directly calling irq_find_mapping,
> > >> which may use a rcu_read_lock call when walking the radix tree.
> > >>
> > >> Turns out that if you hit that point with CONFIG_PROVE_RCU enabled,
> > >> the kernel will shout at you, as using RCU in this context may be
> > >> illegal (specially if coming from the idle state, where RCU would be
> > >> in a quiescent state).
> > >>
> > >> A possible fix would be to wrap calls to irq_find_mapping into a
> > >> RCU_NONIDLE macro, but that really looks ugly.
> > >>
> > >> This patch series introduce another generic IRQ entry point
> > >> (handle_domain_irq), which has the exact same behaviour as handle_IRQ
> > >> (as defined on arm, arm64 and openrisc), except that it also takes a
> > >> irq_domain pointer. This allows the logical IRQ lookup to be done
> > >> inside the irq_{enter,exit} section, which contains a
> > >> rcu_irq_{enter,exit}, making it safe.
> > >
> > > Looks good. Should this be routed to the genirq tree?
> >
> > I'm happy for you to take this series, provided the architecture
> > maintainers agree on it (I'm still to hear from the openrisc guys, and
> > their mailing-list seems to positively hate my guts).
>
> I think everyone's had a chance to look over it by now. Thomas, shall I
> take the series?
Yes please.
--
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 00/26] genirq: fix use of irq_find_mapping outside of legal RCU context
On Wed, Aug 27, 2014 at 10:33:44AM +0100, Marc Zyngier wrote:
> Hi Thomas,
>
> On Tue, Aug 26 2014 at 10:34:51 pm BST, Thomas Gleixner
> wrote:
> > On Tue, 26 Aug 2014, Marc Zyngier wrote:
> >
> >> A number of irqchip drivers are directly calling irq_find_mapping,
> >> which may use a rcu_read_lock call when walking the radix tree.
> >>
> >> Turns out that if you hit that point with CONFIG_PROVE_RCU enabled,
> >> the kernel will shout at you, as using RCU in this context may be
> >> illegal (specially if coming from the idle state, where RCU would be
> >> in a quiescent state).
> >>
> >> A possible fix would be to wrap calls to irq_find_mapping into a
> >> RCU_NONIDLE macro, but that really looks ugly.
> >>
> >> This patch series introduce another generic IRQ entry point
> >> (handle_domain_irq), which has the exact same behaviour as handle_IRQ
> >> (as defined on arm, arm64 and openrisc), except that it also takes a
> >> irq_domain pointer. This allows the logical IRQ lookup to be done
> >> inside the irq_{enter,exit} section, which contains a
> >> rcu_irq_{enter,exit}, making it safe.
> >
> > Looks good. Should this be routed to the genirq tree?
>
> I'm happy for you to take this series, provided the architecture
> maintainers agree on it (I'm still to hear from the openrisc guys, and
> their mailing-list seems to positively hate my guts).
I think everyone's had a chance to look over it by now. Thomas, shall I
take the series?
thx,
Jason.
--
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 3.17
Hi Tony, These patches fix I2C3 bus pinmux and frequency as well as NAND partition name on dra7-evm. cheers, -roger --- Roger Quadros (2): ARM: dts: dra7-evm: Fix i2c3 pinmux and frequency ARM: dts: dra7-evm: Fix 8th NAND partition's name arch/arm/boot/dts/dra7-evm.dts | 8 1 file changed, 4 insertions(+), 4 deletions(-) -- 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 2/2] ARM: dts: dra7-evm: Fix 8th NAND partition's name
The 8th NAND partition should be named "NAND.u-boot-env.backup1"
instead of "NAND.u-boot-env". This is to be consistent with other
TI boards as well as u-boot.
CC: Pekon Gupta
Signed-off-by: Roger Quadros
Signed-off-by: Sekhar Nori
---
arch/arm/boot/dts/dra7-evm.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 42f5bc9..990ee6a 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -483,7 +483,7 @@
reg = <0x001c 0x0002>;
};
partition@7 {
- label = "NAND.u-boot-env";
+ label = "NAND.u-boot-env.backup1";
reg = <0x001e 0x0002>;
};
partition@8 {
--
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 1/2] ARM: dts: dra7-evm: Fix i2c3 pinmux and frequency
The I2C3 pins are taken from pads E21 (GPIO6_14) and
F20 (GPIO6_15). Use the right pinmux register and mode.
Also set the I2C3 bus frequency to a safer 400KHz than
3.4Mhz.
CC: Peter Ujfalusi
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/dra7-evm.dts | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 50f8022..42f5bc9 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -43,8 +43,8 @@
i2c3_pins: pinmux_i2c3_pins {
pinctrl-single,pins = <
- 0x410 (PIN_INPUT | MUX_MODE0) /* i2c3_sda */
- 0x414 (PIN_INPUT | MUX_MODE0) /* i2c3_scl */
+ 0x288 (PIN_INPUT | MUX_MODE9) /* gpio6_14.i2c3_sda */
+ 0x28c (PIN_INPUT | MUX_MODE9) /* gpio6_15.i2c3_scl */
>;
};
@@ -284,7 +284,7 @@
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&i2c3_pins>;
- clock-frequency = <340>;
+ clock-frequency = <40>;
};
&mcspi1 {
--
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
Re: OMAP baseline test results for v3.17-rc3
Hi Paul, On 09/03/14 02:52, Paul Walmsley wrote: > > Here are some basic OMAP test results for Linux v3.17-rc3. > Logs and other details at: > > http://www.pwsan.com/omap/testlogs/test_v3.17-rc3/20140902165525/ > > > Test summary > [...] > Boot to userspace: > FAIL ( 2/15): 2430sdp, 5430es2sbct54 > skip ( 1/15): 5912osk > Pass (12/15): 2420n800, 3517evm, 3530es3beagle, 3730beaglexm, > 37xxevm, 4430es2panda, 4460pandaes, am335xbone, > am335xbonelt, cmt3517, 4460varsomom, 5430es2uevm [...] > A Compulab SBC-T54 (OMAP5432) has been added to the testbed, graciously > donated by Compulab and Igor Grinberg. It currently isn't booting to > userspace in the current mainline kernel, but if the 'ldo8' regulator is > modified to be always-on in the omap5-sbc-t54.dts file, it will. Thanks for the heads up! Yes, indeed ldo8 powers the serial port transceiver, led and touch screen controller. We intend to send fixes in a short while. -- Regards, Igor. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mfd: twl4030-power: Fix PM idle pin configuration to not conflict with regulators
On 09/03/2014 02:24 AM, Tony Lindgren wrote: > I assume you mean beagleboard-ab, not beaglebone-ab :) you assume correct. >> reverting this commit on top of -rc3 makes mmc0 work again. > > Again, I assume you're talking about reverting daebabd57, > not 43fef47f94a1. Anyways, here's a debug hack I used earlier to Yes, I reverted daebabd57 which was pointed to me by git bisect. > dump out the twl configuration in late_initcall and via sysfs > so maybe try that and see what the values are with working > and non-working case? 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 @@ -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 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 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 @@ -17,12 +17,8 @@ 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 > > 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 5/6] ARM: OMAP2+: gpmc: Don't complain if wait pin is used without r/w monitoring
On 09/02/2014 10:12 PM, pekon wrote: > On Tuesday 02 September 2014 07:27 PM, Roger Quadros wrote: >> For NAND read & write wait pin monitoring must be kept disabled as the >> wait pin is only used to indicate NAND device ready status and not to >> extend each read/write cycle. >> > I think this description, does not fit in this patch. It fits the description because it gives the reason why wait monitoring is optional. > And is incorrect as explained in previous patch review. It is correct. I've pointed you to the relevant TRM sections where it is said that GPMC read/write monitoring must be disabled for NAND case. cheers, -roger > > >> So don't print a warning if wait pin is specified while read/write >> monitoring is not in the device tree. >> >> Sanity check wait pin number irrespective if read/write monitoring is >> set or not. >> >> Signed-off-by: Roger Quadros >> --- > But below mentioned checks and clean-up makes sense. So > apart from first 3 lines of commit log .. > > 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/6] ARM: dts: am437x-gp-evm: Don't use read/write wait monitoring
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):
>
> - chip->dev_ready in-case of OMAP NAND drivers is set in
> drivers/mtd/nand/omap2.c during probe.
> if (pdata->dev_ready) {
> nand_chip->dev_ready = omap_dev_ready;
> nand_chip->chip_delay = 0;
> }
>
> Problem is we don't set pdata->dev_ready correctly as part
> of platform-data dring GPMC initialization. This was what my
> earlier patch for wait-pin monitoring about. But it was a
> quick fix for NAND devices.
>
> So, I suggest to fix wait-pin monitoring instead of de-scoping
> it from DTS as wait-pin monitoring should boast the NAND
> performance significantly.
> (please see if you can find an old mail thread which had some
> good feedbacks from Ezequiel and Javier about wait-pin monitoring).
This is to get the device ready mechanism work and has nothing to do with
GPMC wait monitoring. Instead the WAIT pin is used to generate the GPMC
interrupt based on the WAIT pin polarity.
To monitor NAND device ready status
from TRM
"-Use software to poll the WAITnSTS bit (n = 0 to 1) of the GPMC_STS register.
OR
-Configure an interrupt that is generated on the WAIT signal change (through
the GPMC_IRQEN [11-8] bits)"
>
> [...]
>
>> This patch also gets rid of the below warning when NAND is
>> accessed for the first time.
>>
>> omap_l3_noc 4400.ocp: L3 application error: target 13 mod:1 (unclearable)
>>
> Can you debug this further.
> This warning probably comes when driver tries to access some
> "reserved" addresses. Or violate read/write bits.
It is caused because of incorrectly enabled the GPMC wait monitoring. Disabling
the
wait monitoring gets rid of this error. I don't understand what else I should
debug and why.
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
[GIT PULL] ARM: OMAP3: quick clock dts fix for 3.17-rc
Hi Tony, The following changes since commit 7d1311b93e58ed55f3a31cc8f94c4b8fe988a2b9: Linux 3.17-rc1 (2014-08-16 10:40:26 -0600) are available in the git repository at: g...@github.com:t-kristo/linux-pm.git for-v3.17-rc/ti-clk-dt for you to fetch changes up to adf5b4dcc0cf50715f74f49f3c7af0c80467f55f: ARM: dts: set 'ti,set-rate-parent' for dpll4_m5x2 clock (2014-08-21 18:01:35 +0300) Stefan Herbrechtsmeier (1): ARM: dts: set 'ti,set-rate-parent' for dpll4_m5x2 clock arch/arm/boot/dts/omap3xxx-clocks.dtsi |1 + 1 file changed, 1 insertion(+) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] clk: ti: dra7xx: fixes for early 3.17-rc
Hi Mike, The following changes since commit 7d1311b93e58ed55f3a31cc8f94c4b8fe988a2b9: Linux 3.17-rc1 (2014-08-16 10:40:26 -0600) are available in the git repository at: g...@github.com:t-kristo/linux-pm.git for-v3.17-rc/ti-clk-driver for you to fetch changes up to 20411dad75ece9a613af715df4489e60990c4017: clk: ti: dra7-atl: Provide error check for incoming parameters in set_rate (2014-08-21 18:04:16 +0300) Just a couple of quick error check fixes for dra7 boards. Proper fix would be required for the generic clock driver as well (see https://www.mail-archive.com/linux-omap@vger.kernel.org/msg108454.html.) Nishanth Menon (2): clk: ti: divider: Provide error check for incoming parameters in set_rate clk: ti: dra7-atl: Provide error check for incoming parameters in set_rate drivers/clk/ti/clk-dra7-atl.c |6 +- drivers/clk/ti/divider.c |7 ++- 2 files changed, 11 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
