* [PATCH v2 09/12] PCI: Remove ARCH_KIRKWOOD dependency
From: Bjorn Helgaas @ 2014-07-22 18:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405028192-9623-10-git-send-email-andrew@lunn.ch>
On Thu, Jul 10, 2014 at 11:36:29PM +0200, Andrew Lunn wrote:
> mach-kirkwood has been removed, now that kirkwood lives in mach-mvebu.
> ARCH_MVEBU is sufficient.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Applied with Jason's ack to pci/host-mvebu for v3.17, thanks!
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: linux-pci at vger.kernel.org
> ---
> drivers/pci/host/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> index 21df477be0c8..88f4862fa452 100644
> --- a/drivers/pci/host/Kconfig
> +++ b/drivers/pci/host/Kconfig
> @@ -3,7 +3,7 @@ menu "PCI host controller drivers"
>
> config PCI_MVEBU
> bool "Marvell EBU PCIe controller"
> - depends on ARCH_MVEBU || ARCH_DOVE || ARCH_KIRKWOOD
> + depends on ARCH_MVEBU || ARCH_DOVE
> depends on OF
>
> config PCIE_DW
> --
> 2.0.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] pinctrl: dra: dt-bindings: Fix pull enable/disable
From: Nishanth Menon @ 2014-07-22 18:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140722164752.GJ20588@saruman.home>
On 07/22/2014 11:47 AM, Felipe Balbi wrote:
> On Tue, Jul 22, 2014 at 10:39:54AM -0500, Nishanth Menon wrote:
>> The DRA74/72 control module pins have a weak pull up and pull down.
>> This is configured by bit offset 17. if BIT(17) is 1, a pull up is
>> selected, else a pull down is selected.
>>
>> However, this pull resisstor is applied based on BIT(16) -
>> PULLUDENABLE - if BIT(18) is *0*, then pull as defined in BIT(17) is
>> applied, else no weak pulls are applied. We defined this in reverse.
>>
>> Reference: Table 18-5 (Description of the pad configuration register
>> bits) in Technical Reference Manual Revision (DRA74x revision Q:
>> SPRUHI2Q Revised June 2014 and DRA72x revision F: SPRUHP2F - Revised
>> June 2014)
>>
>> Fixes: 6e58b8f1daaf1a ("ARM: dts: DRA7: Add the dts files for dra7 SoC and dra7-evm board")
>> Signed-off-by: Nishanth Menon <nm@ti.com>
>> ---
>
> Tested on an upcoming board.
>
> Tested-by: Felipe Balbi <balbi@ti.com>
> Acked-by: Felipe Balbi <balbi@ti.com>
>
>
Felipe,
Thanks.
Tony,
If you could consider this for the rc cycle it might be great(as well
as for stable). The pull direction error can cause all kinds of
Pull-down Vs Pull-Up contention with severe risk for certain IP
reliability.
--
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH v2] iio: exynos-adc: add experimental touchscreen support
From: Arnd Bergmann @ 2014-07-22 18:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140722180904.GB5489@core.coreip.homeip.net>
On Tuesday 22 July 2014 11:09:04 Dmitry Torokhov wrote:
> > @@ -565,6 +722,15 @@ static int exynos_adc_probe(struct platform_device *pdev)
> > if (info->data->init_hw)
> > info->data->init_hw(info);
> >
> > + /* leave out any TS related code if unreachable */
> > + if (IS_BUILTIN(CONFIG_INPUT) ||
> > + (IS_MODULE(CONFIG_INPUT) && config_enabled(MODULE)))
>
> This is ugly... We need IS_SUBSYSTEM_AVAILABLE() wrapper for this...
>
> Anyway,
>
> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>
>
I actually have a patch to introduce IS_REACHABLE() for this purpose,
but I haven't sent it out for review yet. The main user of this would
be drivers/media, which had the correct logic earlier until someone
tried to "simplify" it by replacing it all with IS_ENABLED()...
Arnd
^ permalink raw reply
* [PATCH] ARM: multi_v7_defconfig: major refresh
From: Arnd Bergmann @ 2014-07-22 18:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1406052070-6207-1-git-send-email-olof@lixom.net>
On Tuesday 22 July 2014 11:01:10 Olof Johansson wrote:
> This is a major refresh of the multi_v7_defconfig:
>
> - Bring over a bunch of Samsung drivers to make ODROID-U3 and Chromebooks usable
> * Enable big.LITTLE
> * MCPM
> * CYAPA touchpad
> * Samsung-related MTD/regulator/clk/pinmux drivers
> * Add some of the CrOS EC drivers
> - Turn on TPM, HW_RANDOM
> - OMAP_USB3 -> TI_PIPE3 option rename
> - Enable MCPM/b.L for VEXPRESS
> - Add new CONFIG_MTD_SPI_NOR since it otherwise masks off SPI NOR drivers
> - CONFIG_LOGO, because penguins.
>
> I took care to keep the new options that have been added for whose the
> drivers are not yet in our for-next branch. This was pretty awkward so
> we should sort out how to handle those better in the future.
Since you've already done all those, how about enabling THUMB2_KERNEL?
For the multi_v7_defconfig, it should actually give some benefits,
since it's rather large, and it would be good to have some more testing
with this option enabled.
I guess the first step would be to enable it and just see if your
boot farm survives the change.
Arnd
^ permalink raw reply
* [PATCH v2 1/5] i2c: Don't start transfers when suspended
From: Grygorii Strashko @ 2014-07-22 18:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405608520-5644-1-git-send-email-hechtb@gmail.com>
Hi
On 07/17/2014 05:48 PM, Bastian Hecht wrote:
> i2c transfer requests come in very uncontrolled, like from interrupt routines.
> We might be suspended when this happens. To avoid i2c timeouts caused by
> powered down busses we check for suspension.
>
> Several bus drivers handle this problem on their own. We can clean things up
> by moving the protection mechanism into the core.
I'm not sure, this optimization is safe (
Because, in many cases the access to PMIC IC needs to be allowed till late
stages of suspending (at least till suspend_noirq stage or even later).
For example, on some OMAP SoC Voltage management code need to use services
provided by PMIC IC, which is connected to I2C.
As result, it may cause regression and break PM functionality on some SoCs
if i2c-core will block I2c transfers unconditionally at device's
suspending stage.
May be it will be useful to add just "suspended" field in i2c adapter
structure and provide corresponding accessors.
>
> Signed-off-by: Bastian Hecht <hechtb@gmail.com>
> ---
> changelog v2:
>
> - commit message extended.
> - initialization added for adap->suspended
> - swapped branch for increased performance
>
>
> drivers/i2c/i2c-core.c | 25 ++++++++++++++++++++++++-
> include/linux/i2c.h | 1 +
> 2 files changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
> index 7c7f4b8..b15dc20 100644
> --- a/drivers/i2c/i2c-core.c
> +++ b/drivers/i2c/i2c-core.c
> @@ -343,6 +343,13 @@ static int i2c_legacy_resume(struct device *dev)
> static int i2c_device_pm_suspend(struct device *dev)
> {
> const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
> + struct i2c_adapter *adap = i2c_verify_adapter(dev);
> +
> + if (adap) {
> + i2c_lock_adapter(adap);
> + adap->suspended = true;
> + i2c_unlock_adapter(adap);
> + }
>
> if (pm)
> return pm_generic_suspend(dev);
> @@ -353,6 +360,13 @@ static int i2c_device_pm_suspend(struct device *dev)
> static int i2c_device_pm_resume(struct device *dev)
> {
> const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
> + struct i2c_adapter *adap = i2c_verify_adapter(dev);
> +
> + if (adap) {
> + i2c_lock_adapter(adap);
> + adap->suspended = false;
> + i2c_unlock_adapter(adap);
> + }
>
> if (pm)
> return pm_generic_resume(dev);
> @@ -1243,6 +1257,7 @@ static int i2c_register_adapter(struct i2c_adapter *adap)
> dev_set_name(&adap->dev, "i2c-%d", adap->nr);
> adap->dev.bus = &i2c_bus_type;
> adap->dev.type = &i2c_adapter_type;
> + adap->suspended = false;
> res = device_register(&adap->dev);
> if (res)
> goto out_list;
> @@ -1819,7 +1834,10 @@ int i2c_transfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num)
> i2c_lock_adapter(adap);
> }
>
> - ret = __i2c_transfer(adap, msgs, num);
> + if (!adap->suspended)
> + ret = __i2c_transfer(adap, msgs, num);
> + else
> + ret = -EIO;
> i2c_unlock_adapter(adap);
>
> return ret;
> @@ -2577,6 +2595,10 @@ s32 i2c_smbus_xfer(struct i2c_adapter *adapter, u16 addr, unsigned short flags,
>
> if (adapter->algo->smbus_xfer) {
> i2c_lock_adapter(adapter);
> + if (adapter->suspended) {
> + res = -EIO;
> + goto unlock;
> + }
>
> /* Retry automatically on arbitration loss */
> orig_jiffies = jiffies;
> @@ -2590,6 +2612,7 @@ s32 i2c_smbus_xfer(struct i2c_adapter *adapter, u16 addr, unsigned short flags,
> orig_jiffies + adapter->timeout))
> break;
> }
> +unlock:
> i2c_unlock_adapter(adapter);
>
> if (res != -EOPNOTSUPP || !adapter->algo->master_xfer)
> diff --git a/include/linux/i2c.h b/include/linux/i2c.h
> index b556e0a..af08c75 100644
> --- a/include/linux/i2c.h
> +++ b/include/linux/i2c.h
> @@ -434,6 +434,7 @@ struct i2c_adapter {
> int timeout; /* in jiffies */
> int retries;
> struct device dev; /* the adapter device */
> + unsigned int suspended:1;
>
> int nr;
> char name[48];
>
Regards,
- grygroii
^ permalink raw reply
* [v3 PATCH 2/6] dt: TI: Describe the ti reset DT entries
From: Suman Anna @ 2014-07-22 18:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405615531-15649-2-git-send-email-dmurphy@ti.com>
Hi Dan,
On 07/17/2014 11:45 AM, Murphy, Dan wrote:
> Describe the TI reset DT entries for TI SoC's.
The document definitely needs some cleanup. Here are comments from a
quick glance. In any case, I think this binding will change as you
address Tony's comments.
>
> Signed-off-by: Dan Murphy <dmurphy@ti.com>
> ---
>
> v3 - Changed Headline no other changes
>
> .../devicetree/bindings/reset/ti,reset.txt | 103 ++++++++++++++++++++
> 1 file changed, 103 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/reset/ti,reset.txt
>
> diff --git a/Documentation/devicetree/bindings/reset/ti,reset.txt b/Documentation/devicetree/bindings/reset/ti,reset.txt
> new file mode 100644
> index 0000000..9d5c29c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/reset/ti,reset.txt
> @@ -0,0 +1,103 @@
> +Texas Instruments Reset Controller
> +======================================
> +Please also refer to reset.txt in this directory for common reset
> +controller binding usage.
> +
> +Specifying the reset entries for the IP module
> +==============================================
> +Parent module:
> +This is the module node that contains the reset registers and bits.
> +
> +example:
> + prcm_resets: resets {
> + compatible = "ti,dra7-resets";
> + #reset-cells = <1>;
> + };
> +
> +Required parent properties:
> +- compatible : Should be one of,
> + "ti,omap4-prm" for OMAP4 PRM instances
> + "ti,omap5-prm" for OMAP5 PRM instances
> + "ti,dra7-prm" for DRA7xx PRM instances
> + "ti,am4-prcm" for AM43xx PRCM instances
> + "ti,am3-prcm" for AM33xx PRCM instances
I am not sure if this belongs to the reset driver bindings, as the PRM
and CM nodes are defined at the SoC level. This document should only be
describing the reset nodes bindings.
Also, please list all the required node properties first, before you can
give an example.
> +
> +Required child reset property:
> +- compatible : Should be
> + "resets" for All TI SoCs
There is no "compatible" child property. This should have been the name
of the node, right? Also, please list all the properties required under
this node like #address-cells, #reset-cells etc.
> +
> +example:
> + prm: prm at 4ae06000 {
> + compatible = "ti,omap5-prm";
> + reg = <0x4ae06000 0x3000>;
> +
> + prm_resets: resets {
> + #address-cells = <1>;
> + #size-cells = <1>;
This is wrong. You haven't corrected this from v2. The reg field is used
to give the offsets for control register and status register, and does
not use any size fields.
> + #reset-cells = <1>;
> + };
> + };
> +
> +
> +Reset node declaration
> +==============================================
> +The reset node is declared in a parent child relationship. The main parent
> +is the PRCM module which contains the base address. The first child within
> +the reset parent declares the target modules reset name. This is followed by
> +the control and status offsets.
This is not clear. This is the case with each child node, which is
describing a particular reset domain, and then the individual resets
themselves are defined as child nodes of this reset domain child node.
> +
> +Within the first reset child node is a secondary child node which declares the
> +reset signal of interest. Under this node the control and status bits
> +are declared. These bits declare the bit mask for the target reset.
> +
> +
> +Required properties:
> +reg - This is the register offset from the PRCM parent.
> + This must be declared as:
> +
> + reg = <control register offset>,
> + <status register offset>;
> +
> +control-bit - This is the bit within the register which controls the reset
> + of the target module. This is declared as a bit mask for the register.
> +status-bit - This is the bit within the register which contains the status of
> + the reset of the target module.
> + This is declared as a bit mask for the register.
> +
> +example:
> +&prm_resets {
> + dsp_rstctrl {
> + reg = <0x1c00>,
> + <0x1c04>;
I guess both these entries can be defined in one line.
> +
> + dsp_reset: dsp_reset {
> + control-bit = <0x01>;
> + status-bit = <0x01>;
> + };
> + };
> +};
> +
> +
> +
> +Client Node Declaration
> +==============================================
> +This is the consumer of the parent node to declare what resets this
> +particular module is interested in.
> +
> +example:
> + src: src at 55082000 {
> + resets = <&reset_src phandle>;
> + reset-names = "<reset_name>";
> + };
> +
> +Required Properties:
> +reset_src - This is the parent DT entry for the reset controller
> +phandle - This is the phandle of the specific reset to be used by the clien
> + driver.
> +reset-names - This is the reset name of module that the device driver
> + needs to be able to reset. This value must correspond to a value within
> + the reset controller array.
The reset-names is optional as per the reset.txt, so it is not clear if
this is mandatory for this binding.
regards
Suman
> +
> +example:
> +resets = <&prm_resets &dsp_mmu_reset>;
> +reset-names = "dsp_mmu_reset";
>
^ permalink raw reply
* [PATCH] ARM: imx6: fix SMP compilation again
From: Arnd Bergmann @ 2014-07-22 18:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140722145256.GA8537@dragon>
On Tuesday 22 July 2014 22:52:57 Shawn Guo wrote:
> On Tue, Jul 22, 2014 at 04:37:55PM +0200, Arnd Bergmann wrote:
> > On Tuesday 22 July 2014 21:48:16 Shawn Guo wrote:
> > > I tried both mainline and -next tree. I really need some help to
> > > reproduce the error first.
> >
> > My branch is at git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git
> > in the randconfig-next branch. Sorry for the inconvenience.
>
> Okay, I can see the error on your branch with the fixing patch reverted.
>
> >
> > > > arch/arm/mach-imx/built-in.o: In function `v7_secondary_startup':
> > > > :(.text+0x5124): undefined reference to `v7_invalidate_l1'
> > > >
> > > > This puts the code inside of an "ifdef CONFIG_SMP" to hopefully
> > >
> > > The code says "ifdef CONFIG_SOC_IMX6"?
> >
> > It seems I'm having a bad day. I'll fix it up.
>
> With that fixed up,
>
> Acked-by: Shawn Guo <shawn.guo@freescale.com>
>
> Or let me know if you expect me to handle the patch.
>
If you don't mind, just put it into your tree. I'm currently in the
middle of going through my older patches and don't want to lose this one.
Arnd
^ permalink raw reply
* [Re-send PATCH 1/1] arm: dra7xx: Add hwmod data for MDIO and CPSW
From: Paul Walmsley @ 2014-07-22 18:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140717075028.GG18374@atomide.com>
On Thu, 17 Jul 2014, Tony Lindgren wrote:
> * Paul Walmsley <paul@pwsan.com> [140716 11:59]:
> > On Wed, 16 Jul 2014, Sebastian Andrzej Siewior wrote:
> >
> > > On 2014-07-15 20:21:21 [+0000], Paul Walmsley wrote:
> > >
> > > > > Acked-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
> > > > >
> > > > > This is basically what Tony hasked me to do: No IRQ numbers & iomem.
> > > >
> > > > Sorry - I'm a bit confused - Sebastian, did you test this one? If so, is
> > > > it okay to add a Tested-by from you?
> > >
> > > Tested-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
> >
> > Thanks Sebastian.
> >
> > Mugunthan, next step would be for you to get a Reviewed-by: by someone who
> > has access to the (non-public) DRA7xx TRM, and can review for SoC
> > integration. Since Rajendra is no longer at TI, the right person is
> > probably Tony.
> >
> > Then this patch should be mergeable.
>
> Yeah took a look at it and acked it.
Thanks queued for 3.17.
- Paul
^ permalink raw reply
* [v3 PATCH 3/6] ARM: dts: am33xx: Add prcm_resets node
From: Suman Anna @ 2014-07-22 18:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405615531-15649-3-git-send-email-dmurphy@ti.com>
Hi Dan,
On 07/17/2014 11:45 AM, Murphy, Dan wrote:
> Add the prcm_resets node to the prcm parent node.
>
> Add the am33xx_resets file to define the
> am33xx reset lines that are handled by this reset
> framework.
>
> Signed-off-by: Dan Murphy <dmurphy@ti.com>
> ---
>
> v3 - No changes
>
> arch/arm/boot/dts/am33xx-resets.dtsi | 42 ++++++++++++++++++++++++++++++++++
> arch/arm/boot/dts/am33xx.dtsi | 7 ++++++
> 2 files changed, 49 insertions(+)
> create mode 100644 arch/arm/boot/dts/am33xx-resets.dtsi
>
> diff --git a/arch/arm/boot/dts/am33xx-resets.dtsi b/arch/arm/boot/dts/am33xx-resets.dtsi
> new file mode 100644
> index 0000000..9260626
> --- /dev/null
> +++ b/arch/arm/boot/dts/am33xx-resets.dtsi
> @@ -0,0 +1,42 @@
> +/*
> + * Device Tree Source for AM33XX reset data
> + *
> + * Copyright (C) 2014 Texas Instruments, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +&prcm_resets {
> + gfx_rstctrl {
> + reg = <0x1104>,
> + <0x1114>;
> +
> + gfx_reset: gfx_reset {
> + control-bit = <0x01>;
> + status-bit = <0x01>;
> + };
> + };
> +
> + per_rstctrl {
> + reg = <0xD00>,
> + <0xD0C>;
> +
> + iva_reset: iva_reset {
There is no IVA on AM33xx, this should be corrected to reflect the PRU_ICSS.
> + control-bit = <0x04>;
> + status-bit = <0x10>;
> + };
> + };
Not defining the WkupM3 reset control?
> +
> + device_rstctrl {
> + reg = <0xf00>,
> + <0xf08>;
> +
> + device_reset: device_reset {
> + control-bit = <0x01>;
> + status-bit = <0x01>;
> + };
> + };
> +
> +};
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index 4a4e02d..5cdc8f0 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -117,6 +117,12 @@
>
> prcm_clockdomains: clockdomains {
> };
> +
> + prcm_resets: resets {
> + #address-cells = <1>;
> + #size-cells = <1>;
Should be corrected as per comment on DT bindings.
regards
Suman
> + #reset-cells = <1>;
> + };
> };
>
> scrm: scrm at 44e10000 {
> @@ -834,3 +840,4 @@
> };
>
> /include/ "am33xx-clocks.dtsi"
> +/include/ "am33xx-resets.dtsi"
>
^ permalink raw reply
* [PATCH v6 4/5] PCI: add PCI controller for keystone PCIe h/w
From: Murali Karicheri @ 2014-07-22 18:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqJXb28RHhZG9=-NACwAr1ooGhfMOPjtsTGO2s3Dx7ayxQ@mail.gmail.com>
On 07/22/2014 11:41 AM, Rob Herring wrote:
> On Mon, Jul 21, 2014 at 11:39 AM, Murali Karicheri<m-karicheri2@ti.com> wrote:
>> On 07/20/2014 09:44 PM, Jingoo Han wrote:
>>> On Saturday, July 19, 2014 5:29 AM, Murali Karicheri wrote:
>>>> On 07/18/2014 03:31 PM, Rob Herring wrote:
>>>>> On Fri, Jul 18, 2014 at 10:14 AM, Murali Karicheri<m-karicheri2@ti.com>
>>>>> wrote:
>>>> --- Cut ---
>>>>>> +
>>>>>> +Optional properties:-
>>>>>> + phys: phandle to Generic Keystone SerDes phy for PCI
>>>>>> + phy-names: name of the Generic Keystine SerDes phy for PCI
>>>>>> + - If boot loader already does PCI link establishment, then
>>>>>> phys and
>>>>>> + phy-names shouldn't be present.
>>>>>> + ti,enable-linktrain - Enable Link training.
>>>>>> + - If boot loader already does PCI link establishment, then
>>>>>> this
>>>>>> + shouldn't be present.
>>>>>
>>>>> Can't you read from the h/w if the link is trained?
>>>
>>> I agree with Rob Herring's suggestion.
>>>
>>>> Yes.
>>>>
>>>> There are customers who use this driver with PCI Link setup done in the
>>>> boot loader. This property tells the driver to bypass Link setup
>>>> procedure in that case. Is this undesirable and if so. how other
>>>> platforms handle it? Check first if link is trained or start the link
>>>> setup procedure? Let me know. If this is fine, please provide your Ack.
>>>
>>> Please, check the following code of Exynos PCIe diver.
>>>
>>> ./drivers/pci/host/pci-exynos.c
>>>
>>> static int exynos_pcie_establish_link(struct pcie_port *pp)
>>> {
>>> struct exynos_pcie *exynos_pcie = to_exynos_pcie(pp);
>>> void __iomem *elbi_base = exynos_pcie->elbi_base;
>>> void __iomem *pmu_base = exynos_pcie->pmu_base;
>>>
>>> if (dw_pcie_link_up(pp)) {
>>> dev_err(pp->dev, "Link already up\n");
>>> return 0;
>>> }
>>> .....
>>>
>>> In the case of Exynos PCIe, the Exynos PCIe driver checks the
>>> h/w bit such as PCIE_ELBI_LTSSM_ENABLE bit of PCIE_ELBI_RDLH_LINKUP
>>> offset register.
>>>
>>> If the link is already set up by the boot loader or other reasons,
>>> the driver will skip some initialization codes.
>>>
>>> The first step is that you find such h/w bit for checking link up.
>>> If so, please add the code for skipping, when the link is already
>>> set up.
>>>
>> Rob, Jingoo,
>>
>> We have similar bit to check for Link status and I have removed the DT
>> property and skip Link retrain if PCIe Link is already Up. I will be
>> resending the series with Patch 4/5 updated.
> For both keystone and exynos, is this status bit in the phy? If so,
> sounds like this should be a standard phy function op.
>
> Rob
Rob,
There is phy bit as well as PCIe specific Link LTSSM state for Keystone.
Phy one is handled by the Phy driver and PCie driver care about LTSSM
state bit. I have removed the enable_link_train DT attribute from
patch 4/5. Can you ack it now?
Murali
^ permalink raw reply
* [PATCH v6 4/5] PCI: add PCI controller for keystone PCIe h/w
From: Murali Karicheri @ 2014-07-22 19:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqLrh_M0gTRezST9jX1X_5Eo98taNcHok6QX6vDMxeqkcw@mail.gmail.com>
On 07/22/2014 11:37 AM, Rob Herring wrote:
> On Fri, Jul 18, 2014 at 2:50 PM, Arnd Bergmann<arnd@arndb.de> wrote:
>> On Friday 18 July 2014 14:31:39 Rob Herring wrote:
>>>> +
>>>> + Example:
>>>> + pcie_msi_intc: msi-interrupt-controller {
>>>> + interrupt-controller;
>>>> + #interrupt-cells =<1>;
>>>> + interrupt-parent =<&gic>;
>>>> + interrupts =<GIC_SPI 30 IRQ_TYPE_EDGE_RISING>,
>>>> +<GIC_SPI 31 IRQ_TYPE_EDGE_RISING>,
>>>> +<GIC_SPI 32 IRQ_TYPE_EDGE_RISING>,
>>>> +<GIC_SPI 33 IRQ_TYPE_EDGE_RISING>,
>>>> +<GIC_SPI 34 IRQ_TYPE_EDGE_RISING>,
>>>> +<GIC_SPI 35 IRQ_TYPE_EDGE_RISING>,
>>>> +<GIC_SPI 36 IRQ_TYPE_EDGE_RISING>,
>>>> +<GIC_SPI 37 IRQ_TYPE_EDGE_RISING>;
>>>> + };
>>>> +
>>>> +pcie_intc: Interrupt controller device node for Legacy irq chip
>>>> + interrupt-cells: should be set to 1
>>>> + interrupt-parent: Parent interrupt controller phandle
>>>> + interrupts: GIC interrupt lines connected to PCI Legacy interrupt lines
>>>> +
>>>> + Example:
>>>> + pcie_intc: legacy-interrupt-controller {
>>>> + interrupt-controller;
>>>> + #interrupt-cells =<1>;
>>>> + interrupt-parent =<&gic>;
>>>> + interrupts =<GIC_SPI 26 IRQ_TYPE_EDGE_RISING>,
>>>> +<GIC_SPI 27 IRQ_TYPE_EDGE_RISING>,
>>>> +<GIC_SPI 28 IRQ_TYPE_EDGE_RISING>,
>>>> +<GIC_SPI 29 IRQ_TYPE_EDGE_RISING>;
>>>> + };
>>> This seems wrong. Legacy interrupts should be described with
>>> interrupt-map and then PCI child devices have a standard interrupt
>>> specifier.
>>>
>>> I'm not sure about MSIs, but I would think they would have a standard
>>> format too.
>>>
>> IIRC, it's actually the correct way to do this here: the problem is that
>> the PCI IRQs are not directly connected to the GIC, but instead there is
>> a nested irqchip that has each PCI IRQ routed to it and that requires
>> an extra EOI for each interrupt.
>>
>> The interrupt-map in the PCI host points to this special irqchip rather
>> than to the GIC.
> Okay, if there is still an interrupt-map property, then I agree. This
> wasn't clear in the example.
Rob,
There is and is described in designware DT documentation. This documentation
refers to that and also describe DT bindings specific to Keystone. Could you
Ack this based on this?
Murali
>
> Rob
^ permalink raw reply
* [v3 PATCH 4/6] ARM: dts: am4372: Add prcm_resets node
From: Suman Anna @ 2014-07-22 19:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405615531-15649-4-git-send-email-dmurphy@ti.com>
Hi Dan,
On 07/17/2014 11:45 AM, Murphy, Dan wrote:
> Add the prcm_resets node to the prcm parent node.
>
> Add the am34xx_resets file to define the
> am34xx reset lines that are handled by this reset
> framework.
>
> Signed-off-by: Dan Murphy <dmurphy@ti.com>
> ---
>
> v3 - No changes
>
> arch/arm/boot/dts/am4372.dtsi | 7 +++++
> arch/arm/boot/dts/am43xx-resets.dtsi | 52 ++++++++++++++++++++++++++++++++++
> 2 files changed, 59 insertions(+)
> create mode 100644 arch/arm/boot/dts/am43xx-resets.dtsi
>
> diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
> index 49fa596..d0aa9c9 100644
> --- a/arch/arm/boot/dts/am4372.dtsi
> +++ b/arch/arm/boot/dts/am4372.dtsi
> @@ -88,6 +88,12 @@
>
> prcm_clockdomains: clockdomains {
> };
> +
> + prcm_resets: resets {
> + #address-cells = <1>;
> + #size-cells = <1>;
Should be corrected as per comment on DT bindings.
> + #reset-cells = <1>;
> + };
> };
>
> scrm: scrm at 44e10000 {
> @@ -892,3 +898,4 @@
> };
>
> /include/ "am43xx-clocks.dtsi"
> +/include/ "am43xx-resets.dtsi"
> diff --git a/arch/arm/boot/dts/am43xx-resets.dtsi b/arch/arm/boot/dts/am43xx-resets.dtsi
> new file mode 100644
> index 0000000..ef338ba
> --- /dev/null
> +++ b/arch/arm/boot/dts/am43xx-resets.dtsi
> @@ -0,0 +1,52 @@
> +/*
> + * Device Tree Source for AM43XX reset data
> + *
> + * Copyright (C) 2014 Texas Instruments, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +&prcm_resets {
> + icss_rstctrl {
> + reg = <0x810>,
> + <0x814>;
> +
> + icss_reset: icss_reset {
> + control-bit = <0x01>;
> + status-bit = <0x01>;
> + };
> + };
> +
> + gfx_rstctrl {
> + reg = <0x410>,
> + <0x414>;
> +
> + gfx_reset: gfx_reset {
> + control-bit = <0x01>;
> + status-bit = <0x01>;
> + };
> + };
> +
> + per_rstctrl {
> + reg = <0x2010>,
> + <0x2014>;
> +
> + iva_reset: iva_reset {
> + control-bit = <0x01>;
> + status-bit = <0x01>;
> + };
There's no IVA on AM4372. Looking at the offset, it looks like you were
defining this for the WkupM3, in which case you got the initial node
name wrong. The PER rstctrl has the reset management for PRU-ICSS, so
you also need to correct the icss_rstctrl accordingly.
regards
Suman
> + };
> +
> + device_rstctrl {
> + reg = <0x4000>,
> + <0x4004>;
> +
> + device_reset: device_reset {
> + control-bit = <0x01>;
> + status-bit = <0x01>;
> + };
> + };
> +
> +};
>
^ permalink raw reply
* [v3 PATCH 5/6] ARM: dts: dra7: Add prm_resets node
From: Suman Anna @ 2014-07-22 19:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405615531-15649-5-git-send-email-dmurphy@ti.com>
Hi Dan,
On 07/17/2014 11:45 AM, Murphy, Dan wrote:
> Add the prcm_resets node to the prm parent node.
>
> Add the draxx_resets file to define the
> dra7xx reset lines that are handled by this reset
> framework.
>
> Signed-off-by: Dan Murphy <dmurphy@ti.com>
> ---
>
> v3 - No changes
>
> arch/arm/boot/dts/dra7.dtsi | 7 +++
> arch/arm/boot/dts/dra7xx-resets.dtsi | 82 ++++++++++++++++++++++++++++++++++
> 2 files changed, 89 insertions(+)
> create mode 100644 arch/arm/boot/dts/dra7xx-resets.dtsi
>
> diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
> index 8012763..f3a8819 100644
> --- a/arch/arm/boot/dts/dra7.dtsi
> +++ b/arch/arm/boot/dts/dra7.dtsi
> @@ -93,6 +93,12 @@
>
> prm_clockdomains: clockdomains {
> };
> +
> + prm_resets: resets {
> + #address-cells = <1>;
> + #size-cells = <1>;
Should be corrected as per comment on DT bindings.
> + #reset-cells = <1>;
> + };
> };
>
> cm_core_aon: cm_core_aon at 4a005000 {
> @@ -998,3 +1004,4 @@
> };
>
> /include/ "dra7xx-clocks.dtsi"
> +/include/ "dra7xx-resets.dtsi"
> diff --git a/arch/arm/boot/dts/dra7xx-resets.dtsi b/arch/arm/boot/dts/dra7xx-resets.dtsi
> new file mode 100644
> index 0000000..4c4966d
> --- /dev/null
> +++ b/arch/arm/boot/dts/dra7xx-resets.dtsi
> @@ -0,0 +1,82 @@
> +/*
> + * Device Tree Source for DRA7XX reset data
> + *
> + * Copyright (C) 2014 Texas Instruments, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +&prm_resets {
> + dsp_rstctrl {
> + reg = <0x410>,
> + <0x414>;
> +
> + dsp_reset: dsp_reset {
> + control-bit = <0x01>;
> + status-bit = <0x01>;
> + };
> +
> + dsp_mmu_reset: dsp_mmu_reset {
> + control-bit = <0x02>;
> + status-bit = <0x02>;
> + };
> + };
> +
> + ipu_rstctrl {
> + reg = <0x510>,
> + <0x514>;
> +
> + ipu_cpu0_reset: ipu_cpu0_reset {
> + control-bit = <0x01>;
> + status-bit = <0x01>;
> + };
> +
> + ipu_cpu1_reset: ipu_cpu1_reset {
> + control-bit = <0x02>;
> + status-bit = <0x02>;
> + };
> +
> + ipu_mmu_reset: ipu_mmu_reset {
> + control-bit = <0x04>;
> + status-bit = <0x04>;
> + };
> + };
There are two IPUs on DRA7. Which one is this node for? And please add
the other reset node for the other IPU as well.
> +
> + iva_rstctrl {
> + reg = <0xf10>,
> + <0xf14>;
> +
> + iva_reset: iva_reset {
> + control-bit = <0x01>;
> + status-bit = <0x01>;
> + };
IVA also has three resets, one for logic and two for the sequencers. You
are describing only one of them.
> + };
> +
> + pcie_rstctrl {
> + reg = <0x1310>,
> + <0x1314>;
> +
> + pcie1_reset: pcie1_reset {
> + control-bit = <0x01>;
> + status-bit = <0x01>;
> + };
> +
> + pcie2_reset: pcie2_reset {
> + control-bit = <0x01>;
> + status-bit = <0x01>;
> + };
Copy-paste error? Both pcie resets cannot have the same control and
status bits.
regards
Suman
> + };
> +
> + device_rstctrl {
> + reg = <0x1D00>,
> + <0x1D04>;
> +
> + device_reset: device_reset {
> + control-bit = <0x01>;
> + status-bit = <0x01>;
> + };
> + };
> +
> +};
>
^ permalink raw reply
* [v3 PATCH 6/6] ARM: dts: omap5: Add prm_resets node
From: Suman Anna @ 2014-07-22 19:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405615531-15649-6-git-send-email-dmurphy@ti.com>
Hi Dan,
On 07/17/2014 11:45 AM, Murphy, Dan wrote:
> Add the prm_resets node to the prm parent node.
>
> Add the omap54xx_resets file to define the
> omap5 reset lines that are handled by this reset
> framework.
>
> Signed-off-by: Dan Murphy <dmurphy@ti.com>
> ---
>
> v3 - No changes
>
> arch/arm/boot/dts/omap5.dtsi | 7 ++++
> arch/arm/boot/dts/omap54xx-resets.dtsi | 66 ++++++++++++++++++++++++++++++++
> 2 files changed, 73 insertions(+)
> create mode 100644 arch/arm/boot/dts/omap54xx-resets.dtsi
>
> diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
> index a4ed549..97bfef5 100644
> --- a/arch/arm/boot/dts/omap5.dtsi
> +++ b/arch/arm/boot/dts/omap5.dtsi
> @@ -139,6 +139,12 @@
>
> prm_clockdomains: clockdomains {
> };
> +
> + prm_resets: resets {
> + #address-cells = <1>;
> + #size-cells = <1>;
Should be corrected as per comment on DT bindings.
> + #reset-cells = <1>;
> + };
> };
>
> cm_core_aon: cm_core_aon at 4a004000 {
> @@ -989,3 +995,4 @@
> };
>
> /include/ "omap54xx-clocks.dtsi"
> +/include/ "omap54xx-resets.dtsi"
> diff --git a/arch/arm/boot/dts/omap54xx-resets.dtsi b/arch/arm/boot/dts/omap54xx-resets.dtsi
> new file mode 100644
> index 0000000..cba6f52
> --- /dev/null
> +++ b/arch/arm/boot/dts/omap54xx-resets.dtsi
> @@ -0,0 +1,66 @@
> +/*
> + * Device Tree Source for OMAP5 reset data
> + *
> + * Copyright (C) 2014 Texas Instruments, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +&prm_resets {
> + dsp_rstctrl {
> + reg = <0x1c00>,
> + <0x1c04>;
> +
> + dsp_reset: dsp_reset {
> + control-bit = <0x01>;
> + status-bit = <0x01>;
> + };
> +
> + dsp_mmu_reset: dsp_mmu_reset {
> + control-bit = <0x02>;
> + status-bit = <0x02>;
> + };
> + };
> +
> + ipu_rstctrl {
> + reg = <0x910>,
> + <0x914>;
> +
> + ipu_cpu0_reset: ipu_cpu0_reset {
> + control-bit = <0x01>;
> + status-bit = <0x01>;
> + };
> +
> + ipu_cpu1_reset: ipu_cpu1_reset {
> + control-bit = <0x02>;
> + status-bit = <0x02>;
> + };
> +
> + ipu_mmu_reset: ipu_mmu_reset {
> + control-bit = <0x04>;
> + status-bit = <0x04>;
> + };
> + };
Missing reset node for SGX/GFX?
> +
> + iva_rstctrl {
> + reg = <0x1210>,
> + <0x1214>;
> +
> + iva_reset: iva_reset {
> + control-bit = <0x01>;
> + status-bit = <0x01>;
> + };
IVA also has three resets, one for logic and two for the sequencers. You
are describing only one of them.
regards
Suman
> + };
> +
> + device_rstctrl {
> + reg = <0x1c00>,
> + <0x1c04>;
> +
> + device_reset: device_reset {
> + control-bit = <0x01>;
> + status-bit = <0x01>;
> + };
> + };
> +};
>
^ permalink raw reply
* [PATCH V2 1/2] ARM: DRA7: hwmod: Add data for RTC
From: Paul Walmsley @ 2014-07-22 19:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53CE3ABB.5010506@ti.com>
On Tue, 22 Jul 2014, Lokesh Vutla wrote:
> Hi Paul,
> On Wednesday 09 July 2014 02:05 PM, Lokesh Vutla wrote:
> > Add hwmod data for RTC
> >
> > Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
> > Signed-off-by: Sekhar Nori <nsekhar@ti.com>
> > Reviewed-by: Rajendra Nayak <rnayak@ti.com>
> Can you take this patch. I have submitted logs also.
Thanks, queued for 3.17. And thanks for running rtctest in your testlog -
that's helpful and gives some extra confidence.
- Paul
^ permalink raw reply
* [PATCH] efi/arm64: efistub: don't abort if base of DRAM is occupied
From: Mark Salter @ 2014-07-22 19:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140722170818.GD4179@bivouac.eciton.net>
On Tue, 2014-07-22 at 18:08 +0100, Leif Lindholm wrote:
> (Argh, late reply due to broken mail filters.)
>
> On Wed, Jul 16, 2014 at 09:13:48AM -0400, Mark Salter wrote:
> > > > > > > > > Is the spin table area really allocated as BOOT_SERVICES_*?
> > > > > > > >
> > > > > > > > No. It is EFI_RESERVED_TYPE. But if UEFI is allowed below the kernel,
> > > > > > > > then there could be BS code/data memory which we'd want to ignore.
> > > > > > >
> > > > > > > Well, if it is boot service code/data - then there is no need for us
> > > > > > > to keep it around after ExitBootServices().
> > > > > >
> > > > > > One would think, but EFI has proven to be less than strictly compliant
> > > > > > in that regard in the past. I'm inclined to keep the boot services
> > > > > > around until after SetVirtualAddressMap just in case.
> > > > >
> > > > > But the function you add this clause to will still throw away all boot
> > > > > services code/data regions - just with this modification it skips
> > > > > those that happen to lie lower in the address space than the kernel.
> > >
> > > Returning to the actual code we are discussing here:
> > > The hunk above has no bearing on whether boot services regions are
> > > generally unmapped or not. It only filters explicitly those boot
> > > services regions that happen to be lower in memory than the kernel,
> > > and keep them around for the duration of the system.
> >
> > It doesn't filter them to keep them around, it filters them to avoid
> > calling free_bootmem_late() with an invalid address. If there are UEFI
> > regions below the kernel, we don't want to call memblock_reserve() or
> > free_bootmem_late() for them.
>
> Then why not just flip things around and do like the arm port and only
> add the blocks we actually want to keep around to begin with?
I'd rather leave it as-is with everything which can be covered by the
normal kernel mem mapping.
>
> > > > > (And I do agree with Mark R here - let's not work around bugs that
> > > > > don't exist yet.)
> > > > >
> > > >
> > > > I'm not sure if they still exist or not, but on Foundation, I saw a
> > > > crash in SetVirtualAddressMap unless I kept BS regions around.
> > >
> > > For the topic of keeping boot services code around:
> > > I did also see issues with not keeping boot services regions on v7 -
> > > ages ago. I have not seen it this year, and I _really_ want to see if
> > > any such issues resurface.
> >
> > My view is that a problem has been seen in the past with tianocore for
> > arm64. There is no harm in delaying the freeing of BS regions.
>
> There is a huge harm.
huge? really?
>
> > The
> > memory becomes usable for general kernel use at early_initcall time.
> > This issue has also been seen with x86 firmware and some of those same
> > vendors will be providing arm64 firmware.
>
> This issue has been seen with x86 firmware because in the early days
> (last year) noone bothered validating anything other than CSM. They no
> longer have that luxury.
>
> The Linux kernel, currently being the most avid tester of existing
> arm64 UEFI firmware, falling over itself to cater for hypothetical
> broken implementations pretty much guarantees the situation will end
> up just as bad as it ever was on x86 - without us even having CSM.
It is hardly falling over itself. And if the problem is hypothetical,
why is this in the arm32 EFI patches:
+/*
+ * If you need to (temporarily) support buggy firmware, set to 0.
+ */
+#define DISCARD_BOOT_SERVICES_REGIONS 1
>
> > The problem isn't reproducible
> > now, but I'm not sure if there was a bug fix for it or if it just went
> > underground for some reason. Kernel boot may succeed by chance if some
> > needed BS memory isn't reused by kernel.
>
> And it may succeed by chance anyway.
> I'm not saying we won't see broken firmware - I'm saying that this is
> the window we have to try to _help_ people (and ourselves) by letting
> broken firmware fail - before it happens in the data centre.
In this particular case, we are removing a workaround to a problem
which has been seen in the past. So we would open a door to allow
this particular problem to reach the data center.
>
> > > So post-3.16 I would quite like to see the
> > > call to free_boot_services() moved earlier to flush out any such
> > > issues before we see large-scale deployments.
> > >
> >
> > You can just get rid of it altogether:
>
> Well, clearly, that would not be my preference :)
Why not? There's no point in keeping it if it isn't wanted/needed. Or at
least make it optional with a #define as in arm32. Anyway, my opinion is
known and I'm really not that attached to the code. So, if someone wants
to submit a patch to take it out, I'm not going to make a fuss over it.
^ permalink raw reply
* [PATCH v2 0/7] arm: dts: oma3-gta04: Various updates
From: Marek Belisko @ 2014-07-22 19:30 UTC (permalink / raw)
To: linux-arm-kernel
Following patchset add various improvements to gta04 devicetree.
Changes from v1:
- added description to all patches
Marek Belisko (7):
arm: dts: omap3-gta04: Add nand support
arm: dts: omap3-gta04: Fix magnetometer model
arm: dts: omap3-gta04: Add wifi reset node
arm: dts: omap3-gta04: Move spi gpio pins to pmx_core2
arm: dts: omap3-gta04: Add USB host support
arm: dts: omap3-gta04: Add display alias
arm: dts: omap3-gta04: Add twl4030 regulators parameters
arch/arm/boot/dts/omap3-gta04.dts | 150 ++++++++++++++++++++++++++++++++++++--
1 file changed, 145 insertions(+), 5 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH v2 1/7] arm: dts: omap3-gta04: Add nand support
From: Marek Belisko @ 2014-07-22 19:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1406057420-22269-1-git-send-email-marek@goldelico.com>
Add the needed sections to enable nand support on
gta04 board.
Add nand partitions information.
Signed-off-by: Marek Belisko <marek@goldelico.com>
---
arch/arm/boot/dts/omap3-gta04.dts | 54 +++++++++++++++++++++++++++++++++++++++
1 file changed, 54 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-gta04.dts b/arch/arm/boot/dts/omap3-gta04.dts
index 021311f..7d7ddd7 100644
--- a/arch/arm/boot/dts/omap3-gta04.dts
+++ b/arch/arm/boot/dts/omap3-gta04.dts
@@ -309,3 +309,57 @@
};
};
};
+
+&gpmc {
+ ranges = <0 0 0x30000000 0x04>; /* CS0: NAND */
+
+ nand at 0,0 {
+ reg = <0 0 0>; /* CS0, offset 0 */
+ nand-bus-width = <16>;
+ ti,nand-ecc-opt = "bch8";
+
+ gpmc,sync-clk-ps = <0>;
+ gpmc,cs-on-ns = <0>;
+ gpmc,cs-rd-off-ns = <44>;
+ gpmc,cs-wr-off-ns = <44>;
+ gpmc,adv-on-ns = <6>;
+ gpmc,adv-rd-off-ns = <34>;
+ gpmc,adv-wr-off-ns = <44>;
+ gpmc,we-off-ns = <40>;
+ gpmc,oe-off-ns = <54>;
+ gpmc,access-ns = <64>;
+ gpmc,rd-cycle-ns = <82>;
+ gpmc,wr-cycle-ns = <82>;
+ gpmc,wr-access-ns = <40>;
+ gpmc,wr-data-mux-bus-ns = <0>;
+ gpmc,device-width = <2>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ x-loader at 0 {
+ label = "X-Loader";
+ reg = <0 0x80000>;
+ };
+
+ bootloaders at 80000 {
+ label = "U-Boot";
+ reg = <0x80000 0x1e0000>;
+ };
+
+ bootloaders_env at 260000 {
+ label = "U-Boot Env";
+ reg = <0x260000 0x20000>;
+ };
+
+ kernel at 280000 {
+ label = "Kernel";
+ reg = <0x280000 0x400000>;
+ };
+
+ filesystem at 680000 {
+ label = "File System";
+ reg = <0x680000 0xf980000>;
+ };
+ };
+};
--
1.9.1
^ permalink raw reply related
* [PATCH v2 2/7] arm: dts: omap3-gta04: Fix magnetometer model
From: Marek Belisko @ 2014-07-22 19:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1406057420-22269-1-git-send-email-marek@goldelico.com>
gta04 is using hmc5843l not hmc5843 so fix wrong compatible
entry.
Signed-off-by: Marek Belisko <marek@goldelico.com>
---
arch/arm/boot/dts/omap3-gta04.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap3-gta04.dts b/arch/arm/boot/dts/omap3-gta04.dts
index 7d7ddd7..6d1a8d8 100644
--- a/arch/arm/boot/dts/omap3-gta04.dts
+++ b/arch/arm/boot/dts/omap3-gta04.dts
@@ -220,7 +220,7 @@
/* compass aka magnetometer */
hmc5843 at 1e {
- compatible = "honeywell,hmc5843";
+ compatible = "honeywell,hmc5843l";
reg = <0x1e>;
};
--
1.9.1
^ permalink raw reply related
* [PATCH v2 3/7] arm: dts: omap3-gta04: Add wifi reset node
From: Marek Belisko @ 2014-07-22 19:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1406057420-22269-1-git-send-email-marek@goldelico.com>
Define gpio node in tca6507 which will be used as
wifi reset pin.
Signed-off-by: Marek Belisko <marek@goldelico.com>
---
arch/arm/boot/dts/omap3-gta04.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-gta04.dts b/arch/arm/boot/dts/omap3-gta04.dts
index 6d1a8d8..5b08d93 100644
--- a/arch/arm/boot/dts/omap3-gta04.dts
+++ b/arch/arm/boot/dts/omap3-gta04.dts
@@ -196,6 +196,9 @@
#size-cells = <0>;
reg = <0x45>;
+ gpio-controller;
+ #gpio-cells = <2>;
+
gta04_led0: red_aux at 0 {
label = "gta04:red:aux";
reg = <0x0>;
@@ -216,6 +219,11 @@
label = "gta04:green:power";
reg = <0x4>;
};
+
+ wifi_reset: wifi_reset at 6 {
+ reg = <0x6>;
+ compatible = "gpio";
+ };
};
/* compass aka magnetometer */
--
1.9.1
^ permalink raw reply related
* [PATCH v2 4/7] arm: dts: omap3-gta04: Move spi gpio pins to pmx_core2
From: Marek Belisko @ 2014-07-22 19:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1406057420-22269-1-git-send-email-marek@goldelico.com>
Because of commit: 3d495383648a7cda3ea51a1e2fa5d288581479aa
spi_gpio_pins node isn't valid anymore. Move to pmx_core2 node.
Signed-off-by: Marek Belisko <marek@goldelico.com>
---
arch/arm/boot/dts/omap3-gta04.dts | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-gta04.dts b/arch/arm/boot/dts/omap3-gta04.dts
index 5b08d93..4ca1277 100644
--- a/arch/arm/boot/dts/omap3-gta04.dts
+++ b/arch/arm/boot/dts/omap3-gta04.dts
@@ -141,12 +141,15 @@
0x0da (PIN_OUTPUT | MUX_MODE0) /* dss_data23.dss_data23 */
>;
};
+};
+&omap3_pmx_core2 {
spi_gpio_pins: spi_gpio_pinmux {
- pinctrl-single,pins = <0x5a8 (PIN_OUTPUT | MUX_MODE4) /* clk */
- 0x5b6 (PIN_OUTPUT | MUX_MODE4) /* cs */
- 0x5b8 (PIN_OUTPUT | MUX_MODE4) /* tx */
- 0x5b4 (PIN_INPUT | MUX_MODE4) /* rx */
+ pinctrl-single,pins = <
+ OMAP3630_CORE2_IOPAD(0x25d8, PIN_OUTPUT | MUX_MODE4) /* clk */
+ OMAP3630_CORE2_IOPAD(0x25e6, PIN_OUTPUT | MUX_MODE4) /* cs */
+ OMAP3630_CORE2_IOPAD(0x25e8, PIN_OUTPUT | MUX_MODE4) /* tx */
+ OMAP3630_CORE2_IOPAD(0x25e4, PIN_INPUT | MUX_MODE4) /* rx */
>;
};
};
--
1.9.1
^ permalink raw reply related
* [PATCH v2 5/7] arm: dts: omap3-gta04: Add USB host support
From: Marek Belisko @ 2014-07-22 19:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1406057420-22269-1-git-send-email-marek@goldelico.com>
Define USB Host port mode and the PHY device.
Also provide pin multiplexer information for USB host
pins.
Signed-off-by: Marek Belisko <marek@goldelico.com>
---
arch/arm/boot/dts/omap3-gta04.dts | 45 +++++++++++++++++++++++++++++++++++++++
1 file changed, 45 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-gta04.dts b/arch/arm/boot/dts/omap3-gta04.dts
index 4ca1277..370c08b 100644
--- a/arch/arm/boot/dts/omap3-gta04.dts
+++ b/arch/arm/boot/dts/omap3-gta04.dts
@@ -74,9 +74,30 @@
};
};
};
+
+ hsusb2_phy: hsusb2_phy {
+ compatible = "usb-nop-xceiv";
+ reset-gpios = <&gpio6 14 GPIO_ACTIVE_LOW>;
+ };
};
&omap3_pmx_core {
+ pinctrl-names = "default";
+ pinctrl-0 = <
+ &hsusb2_pins
+ >;
+
+ hsusb2_pins: pinmux_hsusb2_pins {
+ pinctrl-single,pins = <
+ OMAP3_CORE1_IOPAD(0x21d4, PIN_INPUT_PULLDOWN | MUX_MODE3) /* mcspi1_cs3.hsusb2_data2 */
+ OMAP3_CORE1_IOPAD(0x21d6, PIN_INPUT_PULLDOWN | MUX_MODE3) /* mcspi2_clk.hsusb2_data7 */
+ OMAP3_CORE1_IOPAD(0x21d8, PIN_INPUT_PULLDOWN | MUX_MODE3) /* mcspi2_simo.hsusb2_data4 */
+ OMAP3_CORE1_IOPAD(0x21da, PIN_INPUT_PULLDOWN | MUX_MODE3) /* mcspi2_somi.hsusb2_data5 */
+ OMAP3_CORE1_IOPAD(0x21dc, PIN_INPUT_PULLDOWN | MUX_MODE3) /* mcspi2_cs0.hsusb2_data6 */
+ OMAP3_CORE1_IOPAD(0x21de, PIN_INPUT_PULLDOWN | MUX_MODE3) /* mcspi2_cs1.hsusb2_data3 */
+ >;
+ };
+
uart1_pins: pinmux_uart1_pins {
pinctrl-single,pins = <
0x152 (PIN_INPUT | MUX_MODE0) /* uart1_rx.uart1_rx */
@@ -144,6 +165,22 @@
};
&omap3_pmx_core2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <
+ &hsusb2_2_pins
+ >;
+
+ hsusb2_2_pins: pinmux_hsusb2_2_pins {
+ pinctrl-single,pins = <
+ OMAP3630_CORE2_IOPAD(0x25f0, PIN_OUTPUT | MUX_MODE3) /* etk_d10.hsusb2_clk */
+ OMAP3630_CORE2_IOPAD(0x25f2, PIN_OUTPUT | MUX_MODE3) /* etk_d11.hsusb2_stp */
+ OMAP3630_CORE2_IOPAD(0x25f4, PIN_INPUT_PULLDOWN | MUX_MODE3) /* etk_d12.hsusb2_dir */
+ OMAP3630_CORE2_IOPAD(0x25f6, PIN_INPUT_PULLDOWN | MUX_MODE3) /* etk_d13.hsusb2_nxt */
+ OMAP3630_CORE2_IOPAD(0x25f8, PIN_INPUT_PULLDOWN | MUX_MODE3) /* etk_d14.hsusb2_data0 */
+ OMAP3630_CORE2_IOPAD(0x25fa, PIN_INPUT_PULLDOWN | MUX_MODE3) /* etk_d15.hsusb2_data1 */
+ >;
+ };
+
spi_gpio_pins: spi_gpio_pinmux {
pinctrl-single,pins = <
OMAP3630_CORE2_IOPAD(0x25d8, PIN_OUTPUT | MUX_MODE4) /* clk */
@@ -259,6 +296,14 @@
power = <50>;
};
+&usbhshost {
+ port2-mode = "ehci-phy";
+};
+
+&usbhsehci {
+ phys = <0 &hsusb2_phy>;
+};
+
&mmc1 {
pinctrl-names = "default";
pinctrl-0 = <&mmc1_pins>;
--
1.9.1
^ permalink raw reply related
* [PATCH v2 6/7] arm: dts: omap3-gta04: Add display alias
From: Marek Belisko @ 2014-07-22 19:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1406057420-22269-1-git-send-email-marek@goldelico.com>
Define alias for lcd display present on gta04 board.
Signed-off-by: Marek Belisko <marek@goldelico.com>
---
arch/arm/boot/dts/omap3-gta04.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-gta04.dts b/arch/arm/boot/dts/omap3-gta04.dts
index 370c08b..05fd4d2 100644
--- a/arch/arm/boot/dts/omap3-gta04.dts
+++ b/arch/arm/boot/dts/omap3-gta04.dts
@@ -26,6 +26,10 @@
reg = <0x80000000 0x20000000>; /* 512 MB */
};
+ aliases {
+ display0 = &lcd;
+ };
+
gpio-keys {
compatible = "gpio-keys";
--
1.9.1
^ permalink raw reply related
* [PATCH v2 7/7] arm: dts: omap3-gta04: Add twl4030 regulators parameters
From: Marek Belisko @ 2014-07-22 19:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1406057420-22269-1-git-send-email-marek@goldelico.com>
Define voltages and properties for various twl4030
regulators used on gta04 board.
Signed-off-by: Marek Belisko <marek@goldelico.com>
---
arch/arm/boot/dts/omap3-gta04.dts | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-gta04.dts b/arch/arm/boot/dts/omap3-gta04.dts
index 05fd4d2..e39ede2 100644
--- a/arch/arm/boot/dts/omap3-gta04.dts
+++ b/arch/arm/boot/dts/omap3-gta04.dts
@@ -346,11 +346,37 @@
bb_uamp = <150>;
};
+/* spare */
+&vaux1 {
+ regulator-min-microvolt = <2500000>;
+ regulator-max-microvolt = <3000000>;
+};
+
+/* sensors */
+&vaux2 {
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ regulator-always-on;
+};
+
+/* camera */
+&vaux3 {
+ regulator-min-microvolt = <2500000>;
+ regulator-max-microvolt = <2500000>;
+};
+
+/* WLAN/BT */
&vaux4 {
regulator-min-microvolt = <2800000>;
regulator-max-microvolt = <3150000>;
};
+/* GPS LNA */
+&vsim {
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <3150000>;
+};
+
/* Needed to power the DPI pins */
&vpll2 {
regulator-always-on;
--
1.9.1
^ permalink raw reply related
* [PATCH 1/3] mmc: dw_mmc: use mmc_regulator_get_supply to handle regulators
From: Javier Martinez Canillas @ 2014-07-22 19:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD=FV=WhTdyinkmZFVW5VxK1m-1Z=gMmofBU1RC0t82oEDEZzA@mail.gmail.com>
Hello Yuvaraj,
On Sat, Jun 28, 2014 at 12:47 AM, Doug Anderson <dianders@chromium.org> wrote:
> On Fri, Jun 27, 2014 at 3:59 AM, Yuvaraj Kumar <yuvaraj.cd@gmail.com> wrote:
>>>> mmc_regulator_set_ocr() is failing as its a fixed-regulator.
>>>
>>> Can you explain more about what's failing? It sure looks like mmc
>>> core is supposed to handle this given comments below
>>>
>>> /*
>>> * If we're using a fixed/static regulator, don't call
>>> * regulator_set_voltage; it would fail.
>>> */
>> tps65090 driver does not register through fixed regulator framework.It
>> uses normal regulator framework and supports only
>> enable/disable/is_enabled callbacks.Also it lacks certain callbacks
>> for list_voltage, get_voltage ,set_voltage etc.
>> [ 2.306476] dwmmc_exynos 12220000.mmc: Failed getting OCR mask: -22
>> [ 2.393403] dwmmc_exynos 12220000.mmc: could not set regulator OCR (-22)
>> For the above reason,regulator framework treats fet4 as unused
>> regulator and disables the vmmc regulator.
>
> Ah. Perhaps tps65090 needs to be fixed then... I'm not sure any
> other drivers cared before so maybe that's why it was never caught?
>
I've been looking at this and as Doug and you said it seems that
nobody cared and since the tps65090 fets are actually just load
switches the driver only implementes the .enable and .disable
functions handlers. Also since their output voltage is just equal to
their input supply, that information was not present neither in the
driver nor in the Device Tree.
But when fet4 is used as the vmmc-supply phandle,
mmc_regulator_get_supply() calls mmc_regulator_get_ocrmask() [0] which
expects to fetch the regulator voltage count and current voltage as
you had explained so the function was failing.
Now I don't think that the driver needs to implement the
{get,set,list}_voltage callbacks. If a tps65090 regulator has both
regulator-min-microvolt and regulator-max-microvolt properties from
the generic regulator DT binding, and the value is the same, it can be
assumed that the regulator is fixed and the fixed_uV field can be set
to the output voltage and n_voltages to 1. That's everything that the
regulator core needs from a fixed regulator in order to make
regulator_get_voltage() to succeed:
static int _regulator_get_voltage(struct regulator_dev *rdev)
{
...
if (rdev->desc->ops->get_voltage_sel) {
sel = rdev->desc->ops->get_voltage_sel(rdev);
if (sel < 0)
return sel;
ret = rdev->desc->ops->list_voltage(rdev, sel);
} else if (rdev->desc->ops->get_voltage) {
ret = rdev->desc->ops->get_voltage(rdev);
} else if (rdev->desc->ops->list_voltage) {
ret = rdev->desc->ops->list_voltage(rdev, 0);
} else if (rdev->desc->fixed_uV && (rdev->desc->n_voltages == 1)) {
ret = rdev->desc->fixed_uV;
} else {
return -EINVAL;
}
...
}
What do you think about patch [1]?
So, with that patch mmc_regulator_get_supply() does not fail anymore
and also does not break DT backward compatibility since it only has
effect on the regulators that define their min and max voltage and not
in the ones that don't like is the case in old DTB.
Now, it is an RFC since I don't know if this is the correct solution.
Even though I've seen that min == max seems to imply that the
regulator is fixed, I wonder if is better to have an explicit generic
DT property (regulator-fixed-microvolt?) that is used to set fixed_uV
in of_get_regulation_constraints(). Since this seems to be a general
problem and not only related to the tps65090 device or the Peach
Pit/Pi use case. If you agree that it's a good solution then I can
post it as a proper patch.
I've also pushed this patch and the ones adding the needed DTS bits
for Peach Pit and Pi DTS to my personal repository so you can test it.
The branch is:
http://cgit.collabora.com/git/user/javier/linux.git/log/?h=tps65090-fixes
You also need to replace regulator_enable(mmc->supply.vmmc) and
regulator_disable(mmc->supply.vmmc) by mmc_regulator_set_ocr(mmc,
mmc->supply.vmmc, ios->vdd) and mmc_regulator_set_ocr(mmc,
mmc->supply.vmmc, 0) respectively in your original patch.
Best regards,
Javier
[0]: http://lxr.free-electrons.com/source/drivers/mmc/core/core.c#L1215
[1]:
>From 3d2e6079cc8c372da946d430d43d36af99e7a582 Mon Sep 17 00:00:00 2001
From: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Date: Tue, 22 Jul 2014 19:16:47 +0200
Subject: [RFC] regulator: tps65090: Allow regulators voltage to be
queried
The tps65090 device has some regulators with a fixed output
voltage and others with an adjustable output voltage. But the
regulators with adjustable output just provide the voltage of
their input supply so they really are fixed regulators within
a supported voltage range that depends on their input voltage.
That is why the driver only provides an .enable and .disable
function handlers and not a .{get,set,list}_voltage handlers.
But there is code in the kernel that expects to query the
output voltage for all regulators. For example the function
mmc_regulator_get_ocrmask() is executed if a regulator is
used as a vmmc supply and this functions tries to fetch the
number of voltages supported by the regulator and its current
voltage but fails since the driver does not provide this data.
The .{list,get}_voltage function handler are actually not even
needed for fixed regulators since in this case the regulator
core just need a fixed voltage and a single voltage selector.
So, let's allow output voltage to be defined using the generic
regulator-min-microvolt and regulator-max-microvolt properties
and use the same semantic for fixed regulator as explained in
Documentation/devicetree/bindings/regulator/fixed-regulator.txt.
Where having an equal value for min and max microvolt means that
the regulator is fixed and has a single voltage selector.
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
---
drivers/regulator/tps65090-regulator.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/drivers/regulator/tps65090-regulator.c
b/drivers/regulator/tps65090-regulator.c
index 2064b3f..673948d 100644
--- a/drivers/regulator/tps65090-regulator.c
+++ b/drivers/regulator/tps65090-regulator.c
@@ -408,6 +408,7 @@ static int tps65090_regulator_probe(struct
platform_device *pdev)
struct of_regulator_match *tps65090_reg_matches = NULL;
int num;
int ret;
+ int min_uV, max_uV;
dev_dbg(&pdev->dev, "Probing regulator\n");
@@ -435,6 +436,19 @@ static int tps65090_regulator_probe(struct
platform_device *pdev)
ri->overcurrent_wait_valid =
tps_pdata->overcurrent_wait_valid;
ri->overcurrent_wait = tps_pdata->overcurrent_wait;
+
+ min_uV = tps_pdata->reg_init_data->constraints.min_uV;
+ max_uV = tps_pdata->reg_init_data->constraints.max_uV;
+
+ /*
+ * A regulator whose regulator-min-microvolt and
+ * regulator-max-microvolt properties are the same
+ * is a fixed regulator and has a single voltage rail.
+ */
+ if (min_uV && max_uV && min_uV == max_uV) {
+ ri->desc->fixed_uV = min_uV;
+ ri->desc->n_voltages = 1;
+ }
}
/*
--
2.0.0.rc2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox