* Re: [PATCH] arm: document "mach-virt" platform.
From: Christopher Covington @ 2014-01-30 16:54 UTC (permalink / raw)
To: Ian Campbell
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA, Pawel Moll, Stefano Stabellini,
Marc Zyngier, Will Deacon, Rob Herring, Arnd Bergmann, Kumar Gala,
Olof Johansson, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1391098262-15944-1-git-send-email-ian.campbell-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org>
Hi Ian,
On 01/30/2014 11:11 AM, Ian Campbell wrote:
> mach-virt has existed for a while but it is not written down what it actually
> consists of. Although it seems a bit unusual to document a binding for an
> entire platform since mach-virt is entirely virtual it is helpful to have
> something to refer to in the absence of a single concrete implementation.
>
> I've done my best to capture the requirements based on the git log and my
> memory/understanding.
>
> While here remove the xenvm dts example, the Xen tools will now build a
> suitable mach-virt compatible dts when launching the guest.
[...]
> +++ b/Documentation/devicetree/bindings/arm/mach-virt.txt
> @@ -0,0 +1,32 @@
> +* Mach-virt "Dummy Virtual Machine" platform
> +
> +"mach-virt" is the smallest, dumbest platform possible, to be used as
> +a guest for Xen, KVM and other hypervisors.
The platform is also useful to, and used by, simulators like QEMU in TCG mode.
> It has no
> +properties/functionality of its own and is driven entirely by device
> +tree.
I find this wording confusing. I read it as saying the platform has no
properties or functionality. Perhaps you could phrase it slightly differently,
such as having no properties or functionality beyond what's described in the
device tree.
> +This document defines the requirements for such a platform.
> +
> +* Required properties:
> +
> +- compatible: should be one of:
> + "linux,dummy-virt"
> + "xen,xenvm"
> +
> +In addition to the standard nodes (chosen, cpus, memory etc) the
> +platform is required to provide certain other basic functionality
> +which must be described in the device tree:
> +
> + The platform must provide an ARM Generic Interrupt Controller
> + (GIC), defined in Documentation/devicetree/bindings/arm/gic.txt.
> +
> + The platform must provide ARM architected timer, defined in
> + Documentation/devicetree/bindings/arm/arch_timer.txt.
> +
> + If the platform is SMP then it must provide the Power State
> + Coordination Interface (PSCI) described in
> + Documentation/devicetree/bindings/arm/psci.txt.
> +
> +The platform may also provide hypervisor specific functionality
> +(e.g. PV I/O), if it does so then this functionality must be
> +discoverable (directly or indirectly) via device tree.
I think it would be informative to provide pointers here to commonly used
paravirtualized devices, especially VirtIO PCI/MMIO.
Thanks,
Christopher
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v7 1/2] mmc: sdhci-msm: Initial SDHCI MSM driver documentation
From: Georgi Djakov @ 2014-01-30 17:07 UTC (permalink / raw)
To: Mark Rutland
Cc: linux-mmc@vger.kernel.org, cjb@laptop.org,
devicetree@vger.kernel.org, grant.likely@linaro.org,
rob.herring@calxeda.com, Pawel Moll, swarren@wwwdotorg.org,
ijc+devicetree@hellion.org.uk, galak@codeaurora.org,
rob@landley.net, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
subhashj@codeaurora.org
In-Reply-To: <20131209093843.GB28379@e106331-lin.cambridge.arm.com>
Hi,
Apologies for the delayed reply.
On 12/09/2013 11:38 AM, Mark Rutland wrote:
> On Fri, Dec 06, 2013 at 11:59:46AM +0000, Georgi Djakov wrote:
>> On 12/05/2013 11:52 AM, Mark Rutland wrote:
[...]
>
>>>> +
>>>> +- qcom,{vdd,vdd-io}-lpm-sup - specifies whether the supply can be kept in low power mode.
>>>
>>> Boolean? Please specify types on properties.
>>
>> Yes, it is boolean. I'll note it in the documentation. Thanks!
>>
>>>
>>> Can you elaborate on what this means? When can a supply not be kept in
>>> low power mode?
>>
>> The vdd-io for example is a regulator that is always-on and may be
>> shared with multiple other peripherals as well. It should not be
>> disabled by the driver, but instead put in low power mode when unused.
>
> The fact that the regulator is driving other peripherals doesn't seem
> like a property of the SDHCI to me. What are these other peripherals?
>
Agree! I'll drop this property.
> When you say should not be disabled by the driver, do you mean that
> another peripheral's driver shouldn't be able to disable the regulator
> feeding the SDHCI, or the SDHCI driver shouldn't be able to disable a
> regulator in use by another peripheral?
>
The regulator will not be disabled in any case as it will be marked as
always-on.
> When in low power mode, is the SDHCI functional?
>
>>>
>>>> +- qcom,{vdd,vdd-io}-voltage-level - specifies voltage levels for the supply.
>>>> + Should be specified in pairs (min, max), units uV.
>>>> +- qcom,{vdd,vdd-io}-current-level - specifies load levels for the supply in lpm
>>>> + or high power mode (hpm). Should be specified in pairs (lpm, hpm), units uA.
>>>
>>> Can you not query these from the regulator framework?
>>>
>>> If these are configuration, why are they necessary?
>>>
>>
>> As some regulators are shared and can have multiple consumers, these
>> properties can be used for voltage and load current aggregation.
>> The voltage-level is the "supported voltage" by the controller, that
>> also (at least on my platform) matches the corresponding regulator
>> voltage. I probably can drop the voltage-level property and get voltage
>> via the regulator framework helper functions, but the load current
>> values are different for each sdhc.
>> From the very limited documentation that i have, i think this is
>> describing the hardware configuration and should be in the device-tree.
>
> If these are the voltages / currents supported by the SDHCI, then that
> seems like it makes sense to have in DT, if they're likely to be
> variable in practice. How variable do you expect these to be?
>
The voltages vary depending on the function. For example the vdd-io for
eMMC is 1.2 - 1.8v, for SD cards 1.8 - 2.95v and for SDIO 1.8v.
So, one way is using -min/-max suffixes and the other can be introducing
a for ex. "function" property (emmc/card/sdio) and moving the voltage
range definitions into the driver.
> Also, I'd recommend splitting them in to separate -min and -max
> properties, it makes it far clearer what they're actually for.
>
Thanks,
Georgi
^ permalink raw reply
* Re: [PATCH] ARM: keystone: dts: disable "msmcsram" clock
From: Ivan Khoronzhuk @ 2014-01-30 17:09 UTC (permalink / raw)
To: Santosh Shilimkar
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org,
pawel.moll-5wv7dgnIgG8@public.gmane.org,
mark.rutland-5wv7dgnIgG8@public.gmane.org,
ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org,
linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <52EA6228.8030008-l0cyMroinI0@public.gmane.org>
Thanks, I will send v2
On 01/30/2014 04:31 PM, Santosh Shilimkar wrote:
> On Thursday 30 January 2014 08:58 AM, Ivan Khoronzhuk wrote:
>> Ok. I will delete node for this clock from DT and send v1
>>
> Sorry for the html reply first of all. That node should never have
> been actually added since the clock is not suppose to be touched even
> in low power states. Change log should say something like this ...
>
> "MSMC is the coherency interconnect and all the coherent masters are
> connected to it including devices which are not under Linux OS control.
> MSMC clock should not be toched even in low power states."
>
> So drop the clock node o.w without 'clk_ignore_unused' will disable
> the clock leading to system stall.
>
> I wil try get these in rc's since its a bug fix
>
> Regards,
> Santosh
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] arm: document "mach-virt" platform.
From: Stefano Stabellini @ 2014-01-30 17:12 UTC (permalink / raw)
To: Christopher Covington
Cc: Ian Campbell, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA, Pawel Moll, Stefano Stabellini,
Marc Zyngier, Will Deacon, Rob Herring, Arnd Bergmann, Kumar Gala,
Olof Johansson, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <52EA83D6.9050506-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
On Thu, 30 Jan 2014, Christopher Covington wrote:
> Hi Ian,
>
> On 01/30/2014 11:11 AM, Ian Campbell wrote:
> > mach-virt has existed for a while but it is not written down what it actually
> > consists of. Although it seems a bit unusual to document a binding for an
> > entire platform since mach-virt is entirely virtual it is helpful to have
> > something to refer to in the absence of a single concrete implementation.
> >
> > I've done my best to capture the requirements based on the git log and my
> > memory/understanding.
> >
> > While here remove the xenvm dts example, the Xen tools will now build a
> > suitable mach-virt compatible dts when launching the guest.
>
> [...]
>
> > +++ b/Documentation/devicetree/bindings/arm/mach-virt.txt
> > @@ -0,0 +1,32 @@
> > +* Mach-virt "Dummy Virtual Machine" platform
> > +
> > +"mach-virt" is the smallest, dumbest platform possible, to be used as
> > +a guest for Xen, KVM and other hypervisors.
>
> The platform is also useful to, and used by, simulators like QEMU in TCG mode.
>
> > It has no
> > +properties/functionality of its own and is driven entirely by device
> > +tree.
>
> I find this wording confusing. I read it as saying the platform has no
> properties or functionality. Perhaps you could phrase it slightly differently,
> such as having no properties or functionality beyond what's described in the
> device tree.
Right, something like making no assumptions on the presence of devices
or hardware interfaces beyond what is described on device tree.
> > +This document defines the requirements for such a platform.
> > +
> > +* Required properties:
> > +
> > +- compatible: should be one of:
> > + "linux,dummy-virt"
> > + "xen,xenvm"
> > +
> > +In addition to the standard nodes (chosen, cpus, memory etc) the
> > +platform is required to provide certain other basic functionality
> > +which must be described in the device tree:
> > +
> > + The platform must provide an ARM Generic Interrupt Controller
> > + (GIC), defined in Documentation/devicetree/bindings/arm/gic.txt.
> > +
> > + The platform must provide ARM architected timer, defined in
> > + Documentation/devicetree/bindings/arm/arch_timer.txt.
> > +
> > + If the platform is SMP then it must provide the Power State
> > + Coordination Interface (PSCI) described in
> > + Documentation/devicetree/bindings/arm/psci.txt.
> > +
> > +The platform may also provide hypervisor specific functionality
> > +(e.g. PV I/O), if it does so then this functionality must be
> > +discoverable (directly or indirectly) via device tree.
>
> I think it would be informative to provide pointers here to commonly used
> paravirtualized devices, especially VirtIO PCI/MMIO.
In that case I would appreciate a link to the Xen hypervisor node:
Documentation/devicetree/bindings/arm/xen.txt
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v7 2/2] mmc: sdhci-msm: Initial support for MSM chipsets
From: Georgi Djakov @ 2014-01-30 17:13 UTC (permalink / raw)
To: Mark Rutland
Cc: linux-mmc@vger.kernel.org, cjb@laptop.org,
devicetree@vger.kernel.org, grant.likely@linaro.org,
rob.herring@calxeda.com, Pawel Moll, swarren@wwwdotorg.org,
ijc+devicetree@hellion.org.uk, galak@codeaurora.org,
rob@landley.net, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
subhashj@codeaurora.org
In-Reply-To: <20131209094644.GC28379@e106331-lin.cambridge.arm.com>
On 12/09/2013 11:46 AM, Mark Rutland wrote:
>>> [...]
>>>
>>>> + /*
>>>> + * CORE_SW_RST above may trigger power irq if previous status of PWRCTL
>>>> + * was either BUS_ON or IO_HIGH_V. So before we enable the power irq
>>>> + * interrupt in GIC (by registering the interrupt handler), we need to
>>>> + * ensure that any pending power irq interrupt status is acknowledged
>>>> + * otherwise power irq interrupt handler would be fired prematurely.
>>>> + */
>>>> + irq_status = readl_relaxed(msm_host->core_mem + CORE_PWRCTL_STATUS);
>>>> + writel_relaxed(irq_status, (msm_host->core_mem + CORE_PWRCTL_CLEAR));
>>>> + irq_ctl = readl_relaxed(msm_host->core_mem + CORE_PWRCTL_CTL);
>>>> + if (irq_status & (CORE_PWRCTL_BUS_ON | CORE_PWRCTL_BUS_OFF))
>>>> + irq_ctl |= CORE_PWRCTL_BUS_SUCCESS;
>>>> + if (irq_status & (CORE_PWRCTL_IO_HIGH | CORE_PWRCTL_IO_LOW))
>>>> + irq_ctl |= CORE_PWRCTL_IO_SUCCESS;
>>>> + writel_relaxed(irq_ctl, (msm_host->core_mem + CORE_PWRCTL_CTL));
>>>> + /*
>>>> + * Ensure that above writes are propogated before interrupt enablement
>>>> + * in GIC.
>>>> + */
>>>> + mb();
>>>
>>> Does this guarantee that the device has finished responding to the write
>>> and deasserted the interrupt line (i.e. does the device only acknowledge
>>> the write once that is true)?
>>>
>>
>> I am not sure that i understand your concern. The write to
>> CORE_PWRCTL_CTL should acknowledge and deassert the interrupt.
>
> The mb() ensures that the write has reached the device, and the device's
> slave interface has acknowledged the write. On some devices this
> acknowledgement of the write can be asynchronous with respect to the
> device changing state in response to the write (i.e. the interrupt might
> get deasserted a short time after the write completes). Typically there
> is a register that should be polled to see whether the state change has
> completed.
>
> Does the acknowledgement of the write only occur once the device has
> changed state? Or might it change state in the background?
>
Thanks for clarifying this. All this is correct, but it will be
difficult to answer, because i don't have documentation and i can only
be guessing how exactly the hardware behaves internally.
I can remove this fragment from the initial version to keep it more
simple. Meanwhile i can do some tests reading/polling the status
register to see how and when exactly it changes.
Thanks,
Georgi
^ permalink raw reply
* Re: [PATCH] arm: document "mach-virt" platform.
From: Marc Zyngier @ 2014-01-30 17:13 UTC (permalink / raw)
To: Ian Campbell
Cc: linux-kernel@vger.kernel.org, Rob Herring, Pawel Moll,
Mark Rutland, Kumar Gala, Olof Johansson, Arnd Bergmann,
Will Deacon, Stefano Stabellini, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1391098262-15944-1-git-send-email-ian.campbell@citrix.com>
Hi Ian,
On 30/01/14 16:11, Ian Campbell wrote:
> mach-virt has existed for a while but it is not written down what it actually
> consists of. Although it seems a bit unusual to document a binding for an
> entire platform since mach-virt is entirely virtual it is helpful to have
> something to refer to in the absence of a single concrete implementation.
>
> I've done my best to capture the requirements based on the git log and my
> memory/understanding.
>
> While here remove the xenvm dts example, the Xen tools will now build a
> suitable mach-virt compatible dts when launching the guest.
>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Pawel Moll <pawel.moll@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Kumar Gala <galak@codeaurora.org>
> Cc: Olof Johansson <olof@lixom.net>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Cc: devicetree@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> ---
> I'm not sure which tree this sort of thing should go though, sorry for the
> huge Cc.
> ---
> .../devicetree/bindings/arm/mach-virt.txt | 32 ++++++++
> arch/arm/boot/dts/xenvm-4.2.dts | 81 --------------------
> 2 files changed, 32 insertions(+), 81 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/arm/mach-virt.txt
> delete mode 100644 arch/arm/boot/dts/xenvm-4.2.dts
>
> diff --git a/Documentation/devicetree/bindings/arm/mach-virt.txt b/Documentation/devicetree/bindings/arm/mach-virt.txt
> new file mode 100644
> index 0000000..562bcda
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/mach-virt.txt
> @@ -0,0 +1,32 @@
> +* Mach-virt "Dummy Virtual Machine" platform
> +
> +"mach-virt" is the smallest, dumbest platform possible, to be used as
> +a guest for Xen, KVM and other hypervisors. It has no
> +properties/functionality of its own and is driven entirely by device
> +tree.
> +
> +This document defines the requirements for such a platform.
> +
> +* Required properties:
> +
> +- compatible: should be one of:
> + "linux,dummy-virt"
> + "xen,xenvm"
> +
> +In addition to the standard nodes (chosen, cpus, memory etc) the
> +platform is required to provide certain other basic functionality
> +which must be described in the device tree:
> +
> + The platform must provide an ARM Generic Interrupt Controller
> + (GIC), defined in Documentation/devicetree/bindings/arm/gic.txt.
> +
> + The platform must provide ARM architected timer, defined in
> + Documentation/devicetree/bindings/arm/arch_timer.txt.
> +
> + If the platform is SMP then it must provide the Power State
> + Coordination Interface (PSCI) described in
> + Documentation/devicetree/bindings/arm/psci.txt.
I'm afraid I disagree with most of the above. The whole point of
mach-virt is to provide a shell for DT platforms. None of this hardware
is mandated. Instead, all the necessary information should be described
in DT.
Actually, mach-virt doesn't really stand for Virtual Machine. It stands
for virtual mach-* directory! Eventually, mach-virt should become the
default platform, the one we use when we don't match anything else in
the kernel
What you've described here are requirements for a hypervisor like Xen or
KVM. mach-virt itself shouldn't have any of that.
Cheers,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* Re: [PATCH] arm: document "mach-virt" platform.
From: Ian Campbell @ 2014-01-30 17:15 UTC (permalink / raw)
To: Christopher Covington
Cc: linux-kernel, Mark Rutland, devicetree, Pawel Moll,
Stefano Stabellini, Marc Zyngier, Will Deacon, Rob Herring,
Arnd Bergmann, Kumar Gala, Olof Johansson, linux-arm-kernel
In-Reply-To: <52EA83D6.9050506@codeaurora.org>
On Thu, 2014-01-30 at 11:54 -0500, Christopher Covington wrote:
> > +++ b/Documentation/devicetree/bindings/arm/mach-virt.txt
> > @@ -0,0 +1,32 @@
> > +* Mach-virt "Dummy Virtual Machine" platform
> > +
> > +"mach-virt" is the smallest, dumbest platform possible, to be used as
> > +a guest for Xen, KVM and other hypervisors.
>
> The platform is also useful to, and used by, simulators like QEMU in TCG mode.
I can mention this, although I don't think the list needs to be
exhaustive.
It has no
> > +properties/functionality of its own and is driven entirely by device
> > +tree.
>
> I find this wording confusing. I read it as saying the platform has no
> properties or functionality. Perhaps you could phrase it slightly differently,
> such as having no properties or functionality beyond what's described in the
> device tree.
Yes, this is what I was trying to say, I'll update with something along
those lines.
> > +The platform may also provide hypervisor specific functionality
> > +(e.g. PV I/O), if it does so then this functionality must be
> > +discoverable (directly or indirectly) via device tree.
>
> I think it would be informative to provide pointers here to commonly used
> paravirtualized devices, especially VirtIO PCI/MMIO.
Under what criteria would something be eligible/appropriate to be
listed? I was trying to avoid "advocating" any particular type of PV
devices. We already have something of a problem with people incorrectly
assuming that mach-virt == virtio, which is not the case.
If we did want to include an explicit list here at a minimum I would
also want to include the Xen PV devices as well and surely there would
be others which ought to be included too.
Ian.
^ permalink raw reply
* Re: [PATCH v7 2/2] mmc: sdhci-msm: Initial support for MSM chipsets
From: Georgi Djakov @ 2014-01-30 17:21 UTC (permalink / raw)
To: Courtney Cavin
Cc: linux-mmc@vger.kernel.org, cjb@laptop.org,
devicetree@vger.kernel.org, grant.likely@linaro.org,
rob.herring@calxeda.com, pawel.moll@arm.com, mark.rutland@arm.com,
swarren@wwwdotorg.org, ijc+devicetree@hellion.org.uk,
galak@codeaurora.org, rob@landley.net, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
subhashj@codeaurora.org
In-Reply-To: <20131209170002.GA15223@sonymobile.com>
Hi,
Apologies for the delayed reply.
On 12/09/2013 07:00 PM, Courtney Cavin wrote:
> On Wed, Nov 06, 2013 at 04:56:45PM +0100, Georgi Djakov wrote:
>> This platform driver adds the initial support of Secure
>> Digital Host Controller Interface compliant controller
>> found in Qualcomm MSM chipsets.
>>
>> Signed-off-by: Georgi Djakov <gdjakov@mm-sol.com>
> [...]
>> +static int sdhci_msm_probe(struct platform_device *pdev)
>> +{
>> + struct sdhci_host *host;
>> + struct sdhci_pltfm_host *pltfm_host;
>> + struct sdhci_msm_host *msm_host;
>> + struct resource *core_memres = NULL;
>> + int ret, dead;
>> + u16 host_version;
>> + u32 irq_status, irq_ctl;
>> +
>> + if (!pdev->dev.of_node) {
>> + dev_err(&pdev->dev, "No device tree data\n");
>> + return -ENOENT;
>> + }
>> +
>> + msm_host = devm_kzalloc(&pdev->dev, sizeof(*msm_host), GFP_KERNEL);
>> + if (!msm_host)
>> + return -ENOMEM;
>> +
>> + msm_host->sdhci_msm_pdata.ops = &sdhci_msm_ops;
>> + host = sdhci_pltfm_init(pdev, &msm_host->sdhci_msm_pdata, 0);
>> + if (IS_ERR(host)) {
>> + dev_err(mmc_dev(host->mmc), "sdhci_pltfm_init error\n");
>> + return PTR_ERR(host);
>> + }
>> +
>> + pltfm_host = sdhci_priv(host);
>> + pltfm_host->priv = msm_host;
>> + msm_host->mmc = host->mmc;
>> + msm_host->pdev = pdev;
>> +
>> + ret = mmc_of_parse(host->mmc);
>
> Can we please add a call to sdhci_get_of_property(pdev) somewhere around
> here too?
>
Thanks, I have added it to v8.
>> + if (ret) {
>> + dev_err(&pdev->dev, "failed parsing mmc device tree\n");
>> + goto pltfm_free;
>> + }
>> +
>> + ret = sdhci_msm_populate_pdata(&pdev->dev, &msm_host->pdata);
>> + if (ret) {
>> + dev_err(&pdev->dev, "DT parsing error\n");
>> + goto pltfm_free;
>> + }
>> +
>> + /* Setup SDCC bus voter clock. */
>> + msm_host->bus_clk = devm_clk_get(&pdev->dev, "bus");
>> + if (!IS_ERR(msm_host->bus_clk)) {
>> + /* Vote for max. clk rate for max. performance */
>> + ret = clk_set_rate(msm_host->bus_clk, INT_MAX);
>> + if (ret)
>> + goto pltfm_free;
>> + ret = clk_prepare_enable(msm_host->bus_clk);
>> + if (ret)
>> + goto pltfm_free;
>> + }
>> +
>> + /* Setup main peripheral bus clock */
>> + msm_host->pclk = devm_clk_get(&pdev->dev, "iface");
>> + if (!IS_ERR(msm_host->pclk)) {
>> + ret = clk_prepare_enable(msm_host->pclk);
>> + if (ret) {
>> + dev_err(&pdev->dev,
>> + "Main peripheral clock setup fail (%d)\n",
>> + ret);
>> + goto bus_clk_disable;
>> + }
>> + }
>> +
>> + /* Setup SDC MMC clock */
>> + msm_host->clk = devm_clk_get(&pdev->dev, "core");
>> + if (IS_ERR(msm_host->clk)) {
>> + ret = PTR_ERR(msm_host->clk);
>> + dev_err(&pdev->dev, "SDC MMC clock setup fail (%d)\n", ret);
>> + goto pclk_disable;
>> + }
>> +
>> + ret = clk_prepare_enable(msm_host->clk);
>> + if (ret)
>> + goto pclk_disable;
>> +
>> + /* Setup regulators */
>> + ret = sdhci_msm_vreg_init(&pdev->dev, &msm_host->pdata);
>> + if (ret) {
>> + if (ret != -EPROBE_DEFER)
>> + dev_err(&pdev->dev, "Regulator setup fail (%d)\n", ret);
>> + goto clk_disable;
>> + }
>> +
>> + core_memres = platform_get_resource_byname(pdev,
>> + IORESOURCE_MEM, "core_mem");
>> + msm_host->core_mem = devm_ioremap_resource(&pdev->dev, core_memres);
>> +
>> + if (IS_ERR(msm_host->core_mem)) {
>> + dev_err(&pdev->dev, "Failed to remap registers\n");
>> + ret = PTR_ERR(msm_host->core_mem);
>> + goto vreg_disable;
>> + }
>> +
>> + /* Reset the core and Enable SDHC mode */
>> + writel_relaxed(readl_relaxed(msm_host->core_mem + CORE_POWER) |
>> + CORE_SW_RST, msm_host->core_mem + CORE_POWER);
>> +
>> + /* SW reset can take upto 10HCLK + 15MCLK cycles. (min 40us) */
>> + usleep_range(1000, 5000);
>> + if (readl(msm_host->core_mem + CORE_POWER) & CORE_SW_RST) {
>> + dev_err(&pdev->dev, "Stuck in reset\n");
>> + ret = -ETIMEDOUT;
>> + goto vreg_disable;
>> + }
>> +
>> + /* Set HC_MODE_EN bit in HC_MODE register */
>> + writel_relaxed(HC_MODE_EN, (msm_host->core_mem + CORE_HC_MODE));
>> +
>> + /*
>> + * CORE_SW_RST above may trigger power irq if previous status of PWRCTL
>> + * was either BUS_ON or IO_HIGH_V. So before we enable the power irq
>> + * interrupt in GIC (by registering the interrupt handler), we need to
>> + * ensure that any pending power irq interrupt status is acknowledged
>> + * otherwise power irq interrupt handler would be fired prematurely.
>> + */
>> + irq_status = readl_relaxed(msm_host->core_mem + CORE_PWRCTL_STATUS);
>> + writel_relaxed(irq_status, (msm_host->core_mem + CORE_PWRCTL_CLEAR));
>> + irq_ctl = readl_relaxed(msm_host->core_mem + CORE_PWRCTL_CTL);
>> + if (irq_status & (CORE_PWRCTL_BUS_ON | CORE_PWRCTL_BUS_OFF))
>> + irq_ctl |= CORE_PWRCTL_BUS_SUCCESS;
>> + if (irq_status & (CORE_PWRCTL_IO_HIGH | CORE_PWRCTL_IO_LOW))
>> + irq_ctl |= CORE_PWRCTL_IO_SUCCESS;
>> + writel_relaxed(irq_ctl, (msm_host->core_mem + CORE_PWRCTL_CTL));
>> + /*
>> + * Ensure that above writes are propogated before interrupt enablement
>> + * in GIC.
>> + */
>> + mb();
>> +
>> + /*
>> + * Following are the deviations from SDHC spec v3.0 -
>> + * 1. Card detection is handled using separate GPIO.
>> + * 2. Bus power control is handled by interacting with PMIC.
>> + */
>> + host->quirks |= SDHCI_QUIRK_BROKEN_CARD_DETECTION;
>> + host->quirks |= SDHCI_QUIRK_SINGLE_POWER_WRITE;
>
> I couldn't get v6 running without the 5 quirks you submitted in [1].
> Aren't these also attributes of the controller itself? If so, shouldn't they
> be part of this patch series, and included here?
>
Most of the quirks are for older hardware revisions. On what board/chip
are you trying to run it? I will post v8 shortly. Could you try with it
please?
Thanks,
Georgi
^ permalink raw reply
* Re: [PATCH] arm: document "mach-virt" platform.
From: Ian Campbell @ 2014-01-30 17:21 UTC (permalink / raw)
To: Marc Zyngier
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring,
Pawel Moll, Mark Rutland, Kumar Gala, Olof Johansson,
Arnd Bergmann, Will Deacon, Stefano Stabellini,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <52EA8853.8080709-5wv7dgnIgG8@public.gmane.org>
On Thu, 2014-01-30 at 17:13 +0000, Marc Zyngier wrote:
> Hi Ian,
>
> On 30/01/14 16:11, Ian Campbell wrote:
> > mach-virt has existed for a while but it is not written down what it actually
> > consists of. Although it seems a bit unusual to document a binding for an
> > entire platform since mach-virt is entirely virtual it is helpful to have
> > something to refer to in the absence of a single concrete implementation.
> >
> > I've done my best to capture the requirements based on the git log and my
> > memory/understanding.
> >
> > While here remove the xenvm dts example, the Xen tools will now build a
> > suitable mach-virt compatible dts when launching the guest.
> >
> > Signed-off-by: Ian Campbell <ian.campbell-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org>
> > Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > Cc: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
> > Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
> > Cc: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> > Cc: Olof Johansson <olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org>
> > Cc: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
> > Cc: Marc Zyngier <marc.zyngier-5wv7dgnIgG8@public.gmane.org>
> > Cc: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>
> > Cc: Stefano Stabellini <stefano.stabellini-mvvWK6WmYclDPfheJLI6IQ@public.gmane.org>
> > Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> > ---
> > I'm not sure which tree this sort of thing should go though, sorry for the
> > huge Cc.
> > ---
> > .../devicetree/bindings/arm/mach-virt.txt | 32 ++++++++
> > arch/arm/boot/dts/xenvm-4.2.dts | 81 --------------------
> > 2 files changed, 32 insertions(+), 81 deletions(-)
> > create mode 100644 Documentation/devicetree/bindings/arm/mach-virt.txt
> > delete mode 100644 arch/arm/boot/dts/xenvm-4.2.dts
> >
> > diff --git a/Documentation/devicetree/bindings/arm/mach-virt.txt b/Documentation/devicetree/bindings/arm/mach-virt.txt
> > new file mode 100644
> > index 0000000..562bcda
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/arm/mach-virt.txt
> > @@ -0,0 +1,32 @@
> > +* Mach-virt "Dummy Virtual Machine" platform
> > +
> > +"mach-virt" is the smallest, dumbest platform possible, to be used as
> > +a guest for Xen, KVM and other hypervisors. It has no
> > +properties/functionality of its own and is driven entirely by device
> > +tree.
> > +
> > +This document defines the requirements for such a platform.
> > +
> > +* Required properties:
> > +
> > +- compatible: should be one of:
> > + "linux,dummy-virt"
> > + "xen,xenvm"
> > +
> > +In addition to the standard nodes (chosen, cpus, memory etc) the
> > +platform is required to provide certain other basic functionality
> > +which must be described in the device tree:
> > +
> > + The platform must provide an ARM Generic Interrupt Controller
> > + (GIC), defined in Documentation/devicetree/bindings/arm/gic.txt.
> > +
> > + The platform must provide ARM architected timer, defined in
> > + Documentation/devicetree/bindings/arm/arch_timer.txt.
> > +
> > + If the platform is SMP then it must provide the Power State
> > + Coordination Interface (PSCI) described in
> > + Documentation/devicetree/bindings/arm/psci.txt.
>
> I'm afraid I disagree with most of the above. The whole point of
> mach-virt is to provide a shell for DT platforms. None of this hardware
> is mandated. Instead, all the necessary information should be described
> in DT.
"Add support for the smallest, dumbest possible platform, to be
used as a guest for KVM or other hypervisors.
It only mandates a GIC and architected timers"
(your original commit message :-P)
> Actually, mach-virt doesn't really stand for Virtual Machine. It stands
> for virtual mach-* directory! Eventually, mach-virt should become the
> default platform, the one we use when we don't match anything else in
> the kernel
I can word it more like that for sure, along with the alternative
wording suggested by Christopher/Stefano to clarify the intent that
everything comes from DTB and removal of the specific requirements for
GIC/timer/PSCI I think that suit the (new) intention better?
> What you've described here are requirements for a hypervisor like Xen or
> KVM. mach-virt itself shouldn't have any of that.
>
> Cheers,
>
> M.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] arm: document "mach-virt" platform.
From: Marc Zyngier @ 2014-01-30 17:24 UTC (permalink / raw)
To: Ian Campbell
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring,
Pawel Moll, Mark Rutland, Kumar Gala, Olof Johansson,
Arnd Bergmann, Will Deacon, Stefano Stabellini,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <1391102475.9495.44.camel-ommiHX4a84BXesXXhkcM7miJhflN2719@public.gmane.org>
On 30/01/14 17:21, Ian Campbell wrote:
> On Thu, 2014-01-30 at 17:13 +0000, Marc Zyngier wrote:
>> Hi Ian,
>>
>> On 30/01/14 16:11, Ian Campbell wrote:
>>> mach-virt has existed for a while but it is not written down what it actually
>>> consists of. Although it seems a bit unusual to document a binding for an
>>> entire platform since mach-virt is entirely virtual it is helpful to have
>>> something to refer to in the absence of a single concrete implementation.
>>>
>>> I've done my best to capture the requirements based on the git log and my
>>> memory/understanding.
>>>
>>> While here remove the xenvm dts example, the Xen tools will now build a
>>> suitable mach-virt compatible dts when launching the guest.
>>>
>>> Signed-off-by: Ian Campbell <ian.campbell-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org>
>>> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>> Cc: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
>>> Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
>>> Cc: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>>> Cc: Olof Johansson <olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org>
>>> Cc: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
>>> Cc: Marc Zyngier <marc.zyngier-5wv7dgnIgG8@public.gmane.org>
>>> Cc: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>
>>> Cc: Stefano Stabellini <stefano.stabellini-mvvWK6WmYclDPfheJLI6IQ@public.gmane.org>
>>> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>>> Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>>> Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
>>> ---
>>> I'm not sure which tree this sort of thing should go though, sorry for the
>>> huge Cc.
>>> ---
>>> .../devicetree/bindings/arm/mach-virt.txt | 32 ++++++++
>>> arch/arm/boot/dts/xenvm-4.2.dts | 81 --------------------
>>> 2 files changed, 32 insertions(+), 81 deletions(-)
>>> create mode 100644 Documentation/devicetree/bindings/arm/mach-virt.txt
>>> delete mode 100644 arch/arm/boot/dts/xenvm-4.2.dts
>>>
>>> diff --git a/Documentation/devicetree/bindings/arm/mach-virt.txt b/Documentation/devicetree/bindings/arm/mach-virt.txt
>>> new file mode 100644
>>> index 0000000..562bcda
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/arm/mach-virt.txt
>>> @@ -0,0 +1,32 @@
>>> +* Mach-virt "Dummy Virtual Machine" platform
>>> +
>>> +"mach-virt" is the smallest, dumbest platform possible, to be used as
>>> +a guest for Xen, KVM and other hypervisors. It has no
>>> +properties/functionality of its own and is driven entirely by device
>>> +tree.
>>> +
>>> +This document defines the requirements for such a platform.
>>> +
>>> +* Required properties:
>>> +
>>> +- compatible: should be one of:
>>> + "linux,dummy-virt"
>>> + "xen,xenvm"
>>> +
>>> +In addition to the standard nodes (chosen, cpus, memory etc) the
>>> +platform is required to provide certain other basic functionality
>>> +which must be described in the device tree:
>>> +
>>> + The platform must provide an ARM Generic Interrupt Controller
>>> + (GIC), defined in Documentation/devicetree/bindings/arm/gic.txt.
>>> +
>>> + The platform must provide ARM architected timer, defined in
>>> + Documentation/devicetree/bindings/arm/arch_timer.txt.
>>> +
>>> + If the platform is SMP then it must provide the Power State
>>> + Coordination Interface (PSCI) described in
>>> + Documentation/devicetree/bindings/arm/psci.txt.
>>
>> I'm afraid I disagree with most of the above. The whole point of
>> mach-virt is to provide a shell for DT platforms. None of this hardware
>> is mandated. Instead, all the necessary information should be described
>> in DT.
>
> "Add support for the smallest, dumbest possible platform, to be
> used as a guest for KVM or other hypervisors.
>
> It only mandates a GIC and architected timers"
>
> (your original commit message :-P)
Right. 1984, here we come. I'll disappear for a while, rewriting the
history. More seriously, that was just me scheming to get it merged,
hiding my cunning plan for mach-virt world domination!
>> Actually, mach-virt doesn't really stand for Virtual Machine. It stands
>> for virtual mach-* directory! Eventually, mach-virt should become the
>> default platform, the one we use when we don't match anything else in
>> the kernel
>
> I can word it more like that for sure, along with the alternative
> wording suggested by Christopher/Stefano to clarify the intent that
> everything comes from DTB and removal of the specific requirements for
> GIC/timer/PSCI I think that suit the (new) intention better?
Yes, please! :-)
M.
--
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] arm: document "mach-virt" platform.
From: Arnd Bergmann @ 2014-01-30 17:28 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Ian Campbell, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA, Pawel Moll, Stefano Stabellini,
Marc Zyngier, Will Deacon, Rob Herring, Kumar Gala,
Olof Johansson
In-Reply-To: <1391098262-15944-1-git-send-email-ian.campbell-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org>
On Thursday 30 January 2014, Ian Campbell wrote:
> mach-virt has existed for a while but it is not written down what it actually
> consists of. Although it seems a bit unusual to document a binding for an
> entire platform since mach-virt is entirely virtual it is helpful to have
> something to refer to in the absence of a single concrete implementation.
>
> I've done my best to capture the requirements based on the git log and my
> memory/understanding.
>
> While here remove the xenvm dts example, the Xen tools will now build a
> suitable mach-virt compatible dts when launching the guest.
It might be worth noting in the changeset comment that the 'compatible'
string is actually no longer needed on newer kernels: All the members
of the machine descriptor are now the defaults (we should remove the
virt_init() function as well), and the fallback machine descriptor should
work just fine if any other string gets passed.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] arm: document "mach-virt" platform.
From: Ian Campbell @ 2014-01-30 17:29 UTC (permalink / raw)
To: Marc Zyngier
Cc: linux-kernel@vger.kernel.org, Rob Herring, Pawel Moll,
Mark Rutland, Kumar Gala, Olof Johansson, Arnd Bergmann,
Will Deacon, Stefano Stabellini, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <52EA8AD3.8080904@arm.com>
On Thu, 2014-01-30 at 17:24 +0000, Marc Zyngier wrote:
> >> I'm afraid I disagree with most of the above. The whole point of
> >> mach-virt is to provide a shell for DT platforms. None of this hardware
> >> is mandated. Instead, all the necessary information should be described
> >> in DT.
> >
> > "Add support for the smallest, dumbest possible platform, to be
> > used as a guest for KVM or other hypervisors.
> >
> > It only mandates a GIC and architected timers"
> >
> > (your original commit message :-P)
>
> Right. 1984, here we come. I'll disappear for a while, rewriting the
> history. More seriously, that was just me scheming to get it merged,
> hiding my cunning plan for mach-virt world domination!
:-)
> >> Actually, mach-virt doesn't really stand for Virtual Machine. It stands
> >> for virtual mach-* directory! Eventually, mach-virt should become the
> >> default platform, the one we use when we don't match anything else in
> >> the kernel
> >
> > I can word it more like that for sure, along with the alternative
> > wording suggested by Christopher/Stefano to clarify the intent that
> > everything comes from DTB and removal of the specific requirements for
> > GIC/timer/PSCI I think that suit the (new) intention better?
>
> Yes, please! :-)
OK, I'll come up with an updated version.
Cheers,
Ian.
^ permalink raw reply
* Re: [PATCH] arm: document "mach-virt" platform.
From: Marc Zyngier @ 2014-01-30 17:33 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Ian Campbell,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Pawel Moll, Stefano Stabellini, Will Deacon, Rob Herring,
Kumar Gala, Olof Johansson
In-Reply-To: <201401301828.59294.arnd-r2nGTMty4D4@public.gmane.org>
On 30/01/14 17:28, Arnd Bergmann wrote:
> On Thursday 30 January 2014, Ian Campbell wrote:
>> mach-virt has existed for a while but it is not written down what it actually
>> consists of. Although it seems a bit unusual to document a binding for an
>> entire platform since mach-virt is entirely virtual it is helpful to have
>> something to refer to in the absence of a single concrete implementation.
>>
>> I've done my best to capture the requirements based on the git log and my
>> memory/understanding.
>>
>> While here remove the xenvm dts example, the Xen tools will now build a
>> suitable mach-virt compatible dts when launching the guest.
>
> It might be worth noting in the changeset comment that the 'compatible'
> string is actually no longer needed on newer kernels: All the members
> of the machine descriptor are now the defaults (we should remove the
> virt_init() function as well), and the fallback machine descriptor should
> work just fine if any other string gets passed.
I will ack the patch that removes the mach-virt directory altogether!
M.
--
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] arm: document "mach-virt" platform.
From: Ian Campbell @ 2014-01-30 17:33 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, linux-kernel, Mark Rutland, devicetree,
Pawel Moll, Stefano Stabellini, Marc Zyngier, Will Deacon,
Rob Herring, Kumar Gala, Olof Johansson
In-Reply-To: <201401301828.59294.arnd@arndb.de>
On Thu, 2014-01-30 at 18:28 +0100, Arnd Bergmann wrote:
> On Thursday 30 January 2014, Ian Campbell wrote:
> > mach-virt has existed for a while but it is not written down what it actually
> > consists of. Although it seems a bit unusual to document a binding for an
> > entire platform since mach-virt is entirely virtual it is helpful to have
> > something to refer to in the absence of a single concrete implementation.
> >
> > I've done my best to capture the requirements based on the git log and my
> > memory/understanding.
> >
> > While here remove the xenvm dts example, the Xen tools will now build a
> > suitable mach-virt compatible dts when launching the guest.
>
> It might be worth noting in the changeset comment that the 'compatible'
> string is actually no longer needed on newer kernels: All the members
> of the machine descriptor are now the defaults (we should remove the
> virt_init() function as well), and the fallback machine descriptor should
> work just fine if any other string gets passed.
So Marc's plan has actually happened. Neat. In that case is there even
any point in listing explicit compatiblity strings (except perhaps as a
historical note) -- I can just say that this is the fallback/default
machine?
I'll leave the virt_init change to a separate patch if that's ok.
Ian.
^ permalink raw reply
* Re: [PATCH] arm: document "mach-virt" platform.
From: Christopher Covington @ 2014-01-30 17:43 UTC (permalink / raw)
To: Ian Campbell
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA, Pawel Moll, Stefano Stabellini,
Marc Zyngier, Will Deacon, Rob Herring, Arnd Bergmann, Kumar Gala,
Olof Johansson, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1391102149.9495.39.camel-ommiHX4a84BXesXXhkcM7miJhflN2719@public.gmane.org>
Hi Ian,
On 01/30/2014 12:15 PM, Ian Campbell wrote:
> On Thu, 2014-01-30 at 11:54 -0500, Christopher Covington wrote:
>>> +++ b/Documentation/devicetree/bindings/arm/mach-virt.txt
>>> @@ -0,0 +1,32 @@
>>> +* Mach-virt "Dummy Virtual Machine" platform
>>> +
>>> +"mach-virt" is the smallest, dumbest platform possible, to be used as
>>> +a guest for Xen, KVM and other hypervisors.
>>
>> The platform is also useful to, and used by, simulators like QEMU in TCG mode.
>
> I can mention this, although I don't think the list needs to be
> exhaustive.
Cool, thanks. Agreed, but I thought it'd be nice to list the simulator class.
> It has no
>>> +properties/functionality of its own and is driven entirely by device
>>> +tree.
>>
>> I find this wording confusing. I read it as saying the platform has no
>> properties or functionality. Perhaps you could phrase it slightly differently,
>> such as having no properties or functionality beyond what's described in the
>> device tree.
>
> Yes, this is what I was trying to say, I'll update with something along
> those lines.
>
>>> +The platform may also provide hypervisor specific functionality
>>> +(e.g. PV I/O), if it does so then this functionality must be
>>> +discoverable (directly or indirectly) via device tree.
>>
>> I think it would be informative to provide pointers here to commonly used
>> paravirtualized devices, especially VirtIO PCI/MMIO.
>
> Under what criteria would something be eligible/appropriate to be
> listed? I was trying to avoid "advocating" any particular type of PV
> devices. We already have something of a problem with people incorrectly
> assuming that mach-virt == virtio, which is not the case.
This isn't particularly scientific, but maybe a practical criteria could be
that it's mentioned in this thread? I think if we word the introduction to the
list clearly, readers will know that that these are just a few examples known
to be in use when the binding was written and by no means required. I think
that providing more information is more likely to fix the incorrect assumption
than providing less information.
> If we did want to include an explicit list here at a minimum I would
> also want to include the Xen PV devices as well and surely there would
> be others which ought to be included too.
Yes, I assumed you would include Xen. I'm not aware of any others*, but
perhaps those who do could speak up about them?
(*I do use Angel semihosting and DCC from time to time, but I've never seen
devicetree bindings for these facilities. I'm not sure whether they count in
this context.)
Thanks,
Christopher
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 08/11] of: Increase MAX_PHANDLE_ARGS
From: Andreas Herrmann @ 2014-01-30 17:45 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Will Deacon,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
Rob Herring, Grant Likely,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <52E939CB.1020705-5C7GfCeVMHo@public.gmane.org>
On Wed, Jan 29, 2014 at 12:26:35PM -0500, Suravee Suthikulanit wrote:
> On 1/29/2014 11:16 AM, Andreas Herrmann wrote:
> > On Wed, Jan 29, 2014 at 11:59:12AM -0500, Suravee Suthikulanit wrote:
> >> On 1/29/2014 10:57 AM, Rob Herring wrote:
> >>>>> diff --git a/include/linux/of.h b/include/linux/of.h
> >>>>>>> index 276c546..24e1b28 100644
> >>>>>>> --- a/include/linux/of.h
> >>>>>>> +++ b/include/linux/of.h
> >>>>>>> @@ -67,7 +67,7 @@ struct device_node {
> >>>>>>> #endif
> >>>>>>> };
> >>>>>>>
> >>>>>>> -#define MAX_PHANDLE_ARGS 8
> >>>>>>> +#define MAX_PHANDLE_ARGS 16
> >>>>>
> >>>>>
> >>>>> Since the MMU-500 specify "Number of SMRs" upto 128 registers, shouldn't
> >>>>> this be changed to be able to support 128 StreamIDs as well? Although I am
> >>>>> not sure if this would be too big to have on the stack per Rob's comment in
> >>>>> the previous patch set.
> >>> Do you actually need 128 now? If not, then we can deal with that when
> >>> we get there. There are lots of things in spec's that are not actually
> >>> implemented or supported.
> >>
> >> Actually, we are using 32 on the AMD system. So, do you think we can set
> >> this to 32 instead?
> >
> > I think that's ok.
> >
> > But are we really talking about number of SMRs or number of StreamIDs
> > per master device here? Ie. are you just having 32 SMRs for an SMMU on
> > your AMD system or do you have master devices which have 32 StreamIDs?
> >
> > If it's just number of SMRs we don't need to modify this macro.
> I am referring to the case where each mmu-master can have upto 32 streamID.
Rob,
Do you agree on increasing MAX_PHANDLE_ARGS to 32?
Or should this be done when someone (e.g. Suravee) submits a DTS
update with an SMMU node description containing more than 16 stream
IDs for a master device?
Andreas
^ permalink raw reply
* Re: [RFC PATCH V3 0/4] APM X-Gene PCIe controller
From: Bjorn Helgaas @ 2014-01-30 18:06 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Tanmay Inamdar, Dann Frazier, Jason Gunthorpe, Grant Likely,
Rob Herring, Catalin Marinas, Rob Landley,
linux-pci@vger.kernel.org, devicetree@vger.kernel.org, linux-arm,
linux-doc, linux-kernel@vger.kernel.org, patches, Jon Masters
In-Reply-To: <201401301521.11665.arnd@arndb.de>
On Thu, Jan 30, 2014 at 7:21 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday 30 January 2014, Tanmay Inamdar wrote:
>> >
>> > When you repost, please make sure you fix whatever problem is
>> > preventing your email from appearing on the vger mailing lists. I
>> > won't apply things that haven't appeared on the linux-pci list,
>> > because that list is the opportunity for other people to review them.
>> >
>> You are absolutely right. If the patches are not reaching mailing
>> list, they should not appear on archive list as well. However I am
>> seeing my patches recorded on archives. So I am not sure if they are
>> actually getting dropped on linux-pci or any other mailing list.
>>
>> http://www.spinics.net/lists/linux-pci/msg28198.html
>> http://article.gmane.org/gmane.linux.kernel.pci/28442/match=tanmay+inamdar
>
> Very strange. I can also confirm that I received the patches through
> the linux-arm-kernel and devicetree mailing lists without problems.
Sorry, the problem was on my end. I must have mistakenly marked one
of those messages as spam, and gmail thought all the rest were spam,
too. Sorry about that.
Bjorn
^ permalink raw reply
* [PATCH] ARM: dts: msm: split out msm8660 and msm8960 soc into dts include
From: Kumar Gala @ 2014-01-30 18:08 UTC (permalink / raw)
To: linux-arm-msm; +Cc: Kumar Gala, devicetree, linux-arm-kernel
Pull the SoC device tree bits into their own files so other boards based
on these SoCs can include them and reduce duplication across a number of
boards.
Signed-off-by: Kumar Gala <galak@codeaurora.org>
---
arch/arm/boot/dts/qcom-msm8660-surf.dts | 59 +--------------------------
arch/arm/boot/dts/qcom-msm8660.dtsi | 63 +++++++++++++++++++++++++++++
arch/arm/boot/dts/qcom-msm8960-cdp.dts | 66 +------------------------------
arch/arm/boot/dts/qcom-msm8960.dtsi | 70 +++++++++++++++++++++++++++++++++
4 files changed, 135 insertions(+), 123 deletions(-)
create mode 100644 arch/arm/boot/dts/qcom-msm8660.dtsi
create mode 100644 arch/arm/boot/dts/qcom-msm8960.dtsi
diff --git a/arch/arm/boot/dts/qcom-msm8660-surf.dts b/arch/arm/boot/dts/qcom-msm8660-surf.dts
index 68a72f5..169bad9 100644
--- a/arch/arm/boot/dts/qcom-msm8660-surf.dts
+++ b/arch/arm/boot/dts/qcom-msm8660-surf.dts
@@ -1,63 +1,6 @@
-/dts-v1/;
-
-/include/ "skeleton.dtsi"
-
-#include <dt-bindings/clock/qcom,gcc-msm8660.h>
+#include "qcom-msm8660.dtsi"
/ {
model = "Qualcomm MSM8660 SURF";
compatible = "qcom,msm8660-surf", "qcom,msm8660";
- interrupt-parent = <&intc>;
-
- intc: interrupt-controller@2080000 {
- compatible = "qcom,msm-8660-qgic";
- interrupt-controller;
- #interrupt-cells = <3>;
- reg = < 0x02080000 0x1000 >,
- < 0x02081000 0x1000 >;
- };
-
- timer@2000000 {
- compatible = "qcom,scss-timer", "qcom,msm-timer";
- interrupts = <1 0 0x301>,
- <1 1 0x301>,
- <1 2 0x301>;
- reg = <0x02000000 0x100>;
- clock-frequency = <27000000>,
- <32768>;
- cpu-offset = <0x40000>;
- };
-
- msmgpio: gpio@800000 {
- compatible = "qcom,msm-gpio";
- reg = <0x00800000 0x4000>;
- gpio-controller;
- #gpio-cells = <2>;
- ngpio = <173>;
- interrupts = <0 16 0x4>;
- interrupt-controller;
- #interrupt-cells = <2>;
- };
-
- gcc: clock-controller@900000 {
- compatible = "qcom,gcc-msm8660";
- #clock-cells = <1>;
- #reset-cells = <1>;
- reg = <0x900000 0x4000>;
- };
-
- serial@19c40000 {
- compatible = "qcom,msm-uartdm-v1.3", "qcom,msm-uartdm";
- reg = <0x19c40000 0x1000>,
- <0x19c00000 0x1000>;
- interrupts = <0 195 0x0>;
- clocks = <&gcc GSBI12_UART_CLK>, <&gcc GSBI12_H_CLK>;
- clock-names = "core", "iface";
- };
-
- qcom,ssbi@500000 {
- compatible = "qcom,ssbi";
- reg = <0x500000 0x1000>;
- qcom,controller-type = "pmic-arbiter";
- };
};
diff --git a/arch/arm/boot/dts/qcom-msm8660.dtsi b/arch/arm/boot/dts/qcom-msm8660.dtsi
new file mode 100644
index 0000000..69d6c4e
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-msm8660.dtsi
@@ -0,0 +1,63 @@
+/dts-v1/;
+
+/include/ "skeleton.dtsi"
+
+#include <dt-bindings/clock/qcom,gcc-msm8660.h>
+
+/ {
+ model = "Qualcomm MSM8660";
+ compatible = "qcom,msm8660";
+ interrupt-parent = <&intc>;
+
+ intc: interrupt-controller@2080000 {
+ compatible = "qcom,msm-8660-qgic";
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ reg = < 0x02080000 0x1000 >,
+ < 0x02081000 0x1000 >;
+ };
+
+ timer@2000000 {
+ compatible = "qcom,scss-timer", "qcom,msm-timer";
+ interrupts = <1 0 0x301>,
+ <1 1 0x301>,
+ <1 2 0x301>;
+ reg = <0x02000000 0x100>;
+ clock-frequency = <27000000>,
+ <32768>;
+ cpu-offset = <0x40000>;
+ };
+
+ msmgpio: gpio@800000 {
+ compatible = "qcom,msm-gpio";
+ reg = <0x00800000 0x4000>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ ngpio = <173>;
+ interrupts = <0 16 0x4>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gcc: clock-controller@900000 {
+ compatible = "qcom,gcc-msm8660";
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ reg = <0x900000 0x4000>;
+ };
+
+ serial@19c40000 {
+ compatible = "qcom,msm-uartdm-v1.3", "qcom,msm-uartdm";
+ reg = <0x19c40000 0x1000>,
+ <0x19c00000 0x1000>;
+ interrupts = <0 195 0x0>;
+ clocks = <&gcc GSBI12_UART_CLK>, <&gcc GSBI12_H_CLK>;
+ clock-names = "core", "iface";
+ };
+
+ qcom,ssbi@500000 {
+ compatible = "qcom,ssbi";
+ reg = <0x500000 0x1000>;
+ qcom,controller-type = "pmic-arbiter";
+ };
+};
diff --git a/arch/arm/boot/dts/qcom-msm8960-cdp.dts b/arch/arm/boot/dts/qcom-msm8960-cdp.dts
index 7c30de4..a58fb88 100644
--- a/arch/arm/boot/dts/qcom-msm8960-cdp.dts
+++ b/arch/arm/boot/dts/qcom-msm8960-cdp.dts
@@ -1,70 +1,6 @@
-/dts-v1/;
-
-/include/ "skeleton.dtsi"
-
-#include <dt-bindings/clock/qcom,gcc-msm8960.h>
+#include "qcom-msm8960.dtsi"
/ {
model = "Qualcomm MSM8960 CDP";
compatible = "qcom,msm8960-cdp", "qcom,msm8960";
- interrupt-parent = <&intc>;
-
- intc: interrupt-controller@2000000 {
- compatible = "qcom,msm-qgic2";
- interrupt-controller;
- #interrupt-cells = <3>;
- reg = < 0x02000000 0x1000 >,
- < 0x02002000 0x1000 >;
- };
-
- timer@200a000 {
- compatible = "qcom,kpss-timer", "qcom,msm-timer";
- interrupts = <1 1 0x301>,
- <1 2 0x301>,
- <1 3 0x301>;
- reg = <0x0200a000 0x100>;
- clock-frequency = <27000000>,
- <32768>;
- cpu-offset = <0x80000>;
- };
-
- msmgpio: gpio@800000 {
- compatible = "qcom,msm-gpio";
- gpio-controller;
- #gpio-cells = <2>;
- ngpio = <150>;
- interrupts = <0 16 0x4>;
- interrupt-controller;
- #interrupt-cells = <2>;
- reg = <0x800000 0x4000>;
- };
-
- gcc: clock-controller@900000 {
- compatible = "qcom,gcc-msm8960";
- #clock-cells = <1>;
- #reset-cells = <1>;
- reg = <0x900000 0x4000>;
- };
-
- clock-controller@4000000 {
- compatible = "qcom,mmcc-msm8960";
- reg = <0x4000000 0x1000>;
- #clock-cells = <1>;
- #reset-cells = <1>;
- };
-
- serial@16440000 {
- compatible = "qcom,msm-uartdm-v1.3", "qcom,msm-uartdm";
- reg = <0x16440000 0x1000>,
- <0x16400000 0x1000>;
- interrupts = <0 154 0x0>;
- clocks = <&gcc GSBI5_UART_CLK>, <&gcc GSBI5_H_CLK>;
- clock-names = "core", "iface";
- };
-
- qcom,ssbi@500000 {
- compatible = "qcom,ssbi";
- reg = <0x500000 0x1000>;
- qcom,controller-type = "pmic-arbiter";
- };
};
diff --git a/arch/arm/boot/dts/qcom-msm8960.dtsi b/arch/arm/boot/dts/qcom-msm8960.dtsi
new file mode 100644
index 0000000..ff00282
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-msm8960.dtsi
@@ -0,0 +1,70 @@
+/dts-v1/;
+
+/include/ "skeleton.dtsi"
+
+#include <dt-bindings/clock/qcom,gcc-msm8960.h>
+
+/ {
+ model = "Qualcomm MSM8960";
+ compatible = "qcom,msm8960";
+ interrupt-parent = <&intc>;
+
+ intc: interrupt-controller@2000000 {
+ compatible = "qcom,msm-qgic2";
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ reg = < 0x02000000 0x1000 >,
+ < 0x02002000 0x1000 >;
+ };
+
+ timer@200a000 {
+ compatible = "qcom,kpss-timer", "qcom,msm-timer";
+ interrupts = <1 1 0x301>,
+ <1 2 0x301>,
+ <1 3 0x301>;
+ reg = <0x0200a000 0x100>;
+ clock-frequency = <27000000>,
+ <32768>;
+ cpu-offset = <0x80000>;
+ };
+
+ msmgpio: gpio@800000 {
+ compatible = "qcom,msm-gpio";
+ gpio-controller;
+ #gpio-cells = <2>;
+ ngpio = <150>;
+ interrupts = <0 16 0x4>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ reg = <0x800000 0x4000>;
+ };
+
+ gcc: clock-controller@900000 {
+ compatible = "qcom,gcc-msm8960";
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ reg = <0x900000 0x4000>;
+ };
+
+ clock-controller@4000000 {
+ compatible = "qcom,mmcc-msm8960";
+ reg = <0x4000000 0x1000>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
+ serial@16440000 {
+ compatible = "qcom,msm-uartdm-v1.3", "qcom,msm-uartdm";
+ reg = <0x16440000 0x1000>,
+ <0x16400000 0x1000>;
+ interrupts = <0 154 0x0>;
+ clocks = <&gcc GSBI5_UART_CLK>, <&gcc GSBI5_H_CLK>;
+ clock-names = "core", "iface";
+ };
+
+ qcom,ssbi@500000 {
+ compatible = "qcom,ssbi";
+ reg = <0x500000 0x1000>;
+ qcom,controller-type = "pmic-arbiter";
+ };
+};
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply related
* [PATCH v2] ARM: keystone: dts: drop "msmcsram" clock node
From: Ivan Khoronzhuk @ 2014-01-30 18:10 UTC (permalink / raw)
To: robh+dt, galak
Cc: mark.rutland, devicetree, linux, pawel.moll, ijc+devicetree,
linux-kernel, santosh.shilimkar, Ivan Khoronzhuk,
linux-arm-kernel
At late init all unused clocks are disabled. So clocks that were not
get before will be gated. In Keysone 2 SoC we have at least one
necessary clock that is not used by any driver - "msmcsram". This
clock is necessary, because it supplies the Multicore Shared Memory
Controller (MSMC). MSMC is the coherency interconnect and all the
coherent masters are connected to it including devices which are not
under Linux OS control. MSMC clock should not be touched even in low
power states.
So drop the clock node, otherwise 'clk_ignore_unused' parameter will
disable the clock leading to system stall.
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
---
Based on
git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git
keystone/master
v1..v2:
- dropped "msmcsram" clock node, instead disabling
- updated comment message
arch/arm/boot/dts/keystone-clocks.dtsi | 10 ----------
1 file changed, 10 deletions(-)
diff --git a/arch/arm/boot/dts/keystone-clocks.dtsi b/arch/arm/boot/dts/keystone-clocks.dtsi
index 2363593..98ad488 100644
--- a/arch/arm/boot/dts/keystone-clocks.dtsi
+++ b/arch/arm/boot/dts/keystone-clocks.dtsi
@@ -327,16 +327,6 @@ clocks {
domain-id = <6>;
};
- clkmsmcsram: clkmsmcsram {
- #clock-cells = <0>;
- compatible = "ti,keystone,psc-clock";
- clocks = <&chipclk1>;
- clock-output-names = "msmcsram";
- reg = <0x02350038 0xb00>, <0x0235001c 0x400>;
- reg-names = "control", "domain";
- domain-id = <7>;
- };
-
clkgem0: clkgem0 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
--
1.8.3.2
^ permalink raw reply related
* Re: [PATCH v2 00/21] pinctrl: mvebu: restructure and remove hardcoded addresses from Dove pinctrl
From: Andrew Lunn @ 2014-01-30 18:29 UTC (permalink / raw)
To: Sebastian Hesselbarth
Cc: Jason Cooper, Andrew Lunn, Gregory Clement, Thomas Petazzoni,
Russell King, Linus Walleij, devicetree, linux-doc,
linux-arm-kernel, linux-kernel
In-Reply-To: <1390869573-27624-1-git-send-email-sebastian.hesselbarth@gmail.com>
On Tue, Jan 28, 2014 at 01:39:12AM +0100, Sebastian Hesselbarth wrote:
> This patch set is one required step for Dove to hop into mach-mvebu.
> Until now, pinctrl-dove was hardcoding some registers that do not
> directly belong to MPP core registers. This is not compatible with
> what we want for mach-mvebu.
Hi Sebastian
I think there might be something wrong here....
/debug/pinctrl/f1010000.pinctrl/pinconf-groups used to contain:
Pin config settings per pin group
Format: group (name): configs
0 (mpp0):current: spi(cs), available = [ gpio(io) nand(io2) ]
1 (mpp1):current: spi(mosi), available = [ gpo(o) nand(io3) ]
2 (mpp2):current: spi(sck), available = [ gpo(o) nand(io4) ]
3 (mpp3):current: spi(miso), available = [ gpo(o) nand(io5) ]
4 (mpp4):current: sata1(act), available = [ gpio(io) nand(io6) uart0(rxd) lcd(hsync) ]
5 (mpp5):current: sata0(act), available = [ gpo(o) nand(io7) uart0(txd) lcd(vsync) ]
6 (mpp6):current: sysrst(out), available = [ spi(mosi) ]
...
It now has:
Pin config settings per pin group
Format: group (name): configs
0 (mpp0):current: gpio(io), available = [ nand(io2) spi(cs) ]
1 (mpp1):current: gpo(o), available = [ nand(io3) spi(mosi) ]
2 (mpp2):current: gpo(o), available = [ nand(io4) spi(sck) ]
3 (mpp3):current: gpo(o), available = [ nand(io5) spi(miso) ]
4 (mpp4):current: gpio(io), available = [ nand(io6) uart0(rxd) sata1(act) lcd(hsync) ]
5 (mpp5):current: gpo(o), available = [ nand(io7) uart0(txd) sata0(act) lcd(vsync) ]
6 (mpp6):current: UNKNOWN, available = [ sysrst(out) spi(mosi) ]
The device i'm testing on does use spi and sata, so i would say the
old contents was correct and the new is wrong.
Andrew
^ permalink raw reply
* Re: [PATCH 1/4] ARM: STi: add stid127 soc support
From: Arnd Bergmann @ 2014-01-30 18:35 UTC (permalink / raw)
To: linux-arm-kernel
Cc: devicetree, Russell King, kernel, Srinivas Kandagatla,
Linus Walleij, Patrice CHOTARD, linux-kernel, Stuart Menefy,
Rob Herring, Grant Likely, Giuseppe Cavallaro, maxime.coquelin,
alexandre.torgue
In-Reply-To: <1391093744-19905-2-git-send-email-patrice.chotard@st.com>
On Thursday 30 January 2014, Patrice CHOTARD wrote:
> From: Alexandre TORGUE <alexandre.torgue@st.com>
>
> This patch adds support to STiD127 SoC.
> The main adaptation is the L2 cache way size compare to STiH41x SoCs.
>
> Signed-off-by: alexandre torgue <alexandre.torgue@st.com>
> Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
> ---
> arch/arm/mach-sti/board-dt.c | 6 ++++++
> 1 file changed, 6 insertions(+)
Wouldn't it be better to read this value from the l2 cache
controller node? I'd assume there might be more SoCs that
will need a similar change, so it's better to come up with
a solution that doesn't involve changing the kernel every
time.
Arnd
^ permalink raw reply
* Re: [PATCH 1/4] ARM: STi: add stid127 soc support
From: Arnd Bergmann @ 2014-01-30 18:39 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Russell King,
kernel-F5mvAk5X5gdBDgjK7y7TUQ, Srinivas Kandagatla, Linus Walleij,
Patrice CHOTARD, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
Stuart Menefy, Rob Herring, Grant Likely, Giuseppe Cavallaro,
maxime.coquelin-qxv4g6HH51o, alexandre.torgue-qxv4g6HH51o
In-Reply-To: <201401301935.16463.arnd-r2nGTMty4D4@public.gmane.org>
On Thursday 30 January 2014, Arnd Bergmann wrote:
> On Thursday 30 January 2014, Patrice CHOTARD wrote:
> > From: Alexandre TORGUE <alexandre.torgue-qxv4g6HH51o@public.gmane.org>
> >
> > This patch adds support to STiD127 SoC.
> > The main adaptation is the L2 cache way size compare to STiH41x SoCs.
> >
> > Signed-off-by: alexandre torgue <alexandre.torgue-qxv4g6HH51o@public.gmane.org>
> > Signed-off-by: Patrice Chotard <patrice.chotard-qxv4g6HH51o@public.gmane.org>
> > ---
> > arch/arm/mach-sti/board-dt.c | 6 ++++++
> > 1 file changed, 6 insertions(+)
>
> Wouldn't it be better to read this value from the l2 cache
> controller node? I'd assume there might be more SoCs that
> will need a similar change, so it's better to come up with
> a solution that doesn't involve changing the kernel every
> time.
Actually reading the code in this file shows that the L2 cache
initialization is the only nonstandard thing in there. We should
really find a way to get rid of the entire function.
Sorry if I missed the initial review, but can you explain
why this is needed to start with?
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v8 0/3] mmc: sdhci-msm: Add support for Qualcomm chipsets
From: Georgi Djakov @ 2014-01-30 18:45 UTC (permalink / raw)
To: linux-mmc, cjb, devicetree, grant.likely, rob.herring, pawel.moll,
mark.rutland, swarren, ijc+devicetree, galak, rob, linux-doc,
linux-kernel
Cc: linux-arm-msm, Georgi Djakov
This patchset adds basic support of the Secure Digital Host Controller
Interface compliant controller found in Qualcomm chipsets.
Tested with eMMC and various micro SD cards on APQ8074 Dragonboard.
Changes from v7:
- Added call to sdhci_get_of_property().
- Refactored sdhci_msm_dt_parse_vreg_info().
- Fixed possible ERR_PTR() dereferencing.
- Updated DT binding documentation.
- Removed lpm and currents from DT.
- Removed bus-speed-mode from DT.
- Updated and moved the sanity checks.
- Various typo and coding style fixes.
- Added platform_execute_tunning implementation.
Changes from v6:
- Fixed wrong pointer in sdhci_msm_pwr_irq().
- Added platform_execute_tuning() callback as the MSM SDHC does not
support tuning as in SDHC 3.0 spec and will need custom implementation
in order to support SDR104, HS200 and HS400.
- Removed the always-on devicetree property - if the regulator is
configured as always-on, it will not be disabled anyway.
- Removed devm_pinctrl_get_select_default() - the default pins are
already set from the device core.
- Removed wrapper function sdhci_msm_set_vdd_io_vol() and enum
vdd_io_level and now calling regulator_set_voltage() directly.
- Converted #defines to use BIT() macro.
- Added IS_ERR(vreg->reg) check at the beginning of sdhci_msm_vreg
functions.
- Do not print errors when regulators init return -EPROBE_DEFER as the
deffered init is not an actual error.
- Handle each power irq status bit separately in sdhci_msm_pwr_irq().
- Ensure that any pending power irq is acknowledged before enabling it,
otherwise the irq handler will be fired prematurely.
- Minor changes.
Changes from v5:
- Driver is split into multiple patches
- Do not initialize variables that are assigned later in code
- Remove some useless comments
- Use shorter variable names
- Change pr_err() to dev_err()
- Optimized sdhci_msm_setup_vreg()
- Some code alignment fixes
- Improved DT values sanity check
- Added dev_dbg print for sdhci controller version in probe()
- Added usleep_range() after SW reset - it can take some time
- Added SDHCI_QUIRK_SINGLE_POWER_WRITE - power handled by PMIC
- Renamed DT property vdd-io to vddio
Changes from v4:
- Simplified sdhci_msm_vreg_disable() and sdhci_msm_set_vdd_io_vol()
- Use devm_ioremap_resource() instead of devm_ioremap()
- Converted IS_ERR_OR_NULL to IS_ERR
- Disable regulators in sdhci_msm_remove()
- Check for DT node at the beginning in sdhci_msm_probe()
- Removed more redundant code
- Changes in some error messages
- Minor fixes
Changes from v3:
- Allocate memory for all required structs at once
- Added termination entry in sdhci_msm_dt_match[]
- Fixed a missing sdhci_pltfm_free() in probe()
- Removed redundant of_match_ptr
- Removed the unneeded function sdhci_msm_vreg_reset()
Changes from v2:
- Added DT bindings for clocks
- Moved voltage regulators data to platform data
- Removed unneeded includes
- Removed obsolete and wrapper functions
- Removed error checking where unnecessary
- Removed redundant _clk suffix from clock names
- Just return instead of goto where possible
- Minor fixes
Georgi Djakov (3):
mmc: sdhci-msm: Qualcomm SDHCI binding documentation
mmc: sdhci-msm: Initial support for Qualcomm chipsets
mmc: sdhci-msm: Add platform_execute_tunning implementation
.../devicetree/bindings/mmc/sdhci-msm.txt | 83 ++
drivers/mmc/host/Kconfig | 13 +
drivers/mmc/host/Makefile | 1 +
drivers/mmc/host/sdhci-msm.c | 938 ++++++++++++++++++++
4 files changed, 1035 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mmc/sdhci-msm.txt
create mode 100644 drivers/mmc/host/sdhci-msm.c
--
1.7.9.5
^ permalink raw reply
* [PATCH v8 1/3] mmc: sdhci-msm: Qualcomm SDHCI binding documentation
From: Georgi Djakov @ 2014-01-30 18:45 UTC (permalink / raw)
To: linux-mmc, cjb, devicetree, grant.likely, rob.herring, pawel.moll,
mark.rutland, swarren, ijc+devicetree, galak, rob, linux-doc,
linux-kernel
Cc: linux-arm-msm, Georgi Djakov
In-Reply-To: <1391107507-17321-1-git-send-email-gdjakov@mm-sol.com>
This patch adds the device-tree binding documentation for
Qualcomm SDHCI driver. It contains the differences between
the core properties in mmc.txt and the properties used by
the sdhci-msm driver.
Signed-off-by: Georgi Djakov <gdjakov@mm-sol.com>
---
.../devicetree/bindings/mmc/sdhci-msm.txt | 83 ++++++++++++++++++++
1 file changed, 83 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mmc/sdhci-msm.txt
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
new file mode 100644
index 0000000..c26d335
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
@@ -0,0 +1,83 @@
+* Qualcomm SDHCI controller (sdhci-msm)
+
+This file documents differences between the core properties in mmc.txt
+and the properties used by the sdhci-msm driver.
+
+Required properties:
+- compatible: Should contain "qcom,sdhci-msm".
+- reg: Base address and length of the register set listed in reg-names.
+- reg-names: Should contain the following:
+ "hc_mem" - Host controller register map
+ "core_mem" - SD Core register map
+- interrupts: Should contain an interrupt-specifiers for the interrupts listed in interrupt-names.
+- interrupt-names: Should contain the following:
+ "hc_irq" - Host controller interrupt
+ "pwr_irq" - PMIC interrupt
+- vdd-supply: Phandle to the regulator for the vdd (core voltage) supply.
+- vdd-io-supply: Phandle to the regulator for the vdd-io (i/o voltage) supply.
+- pinctrl-names: Should contain only one value - "default".
+- pinctrl-0: Should specify pin control groups used for this controller.
+- clocks: A list of phandle + clock-specifier pairs for the clocks listed in clock-names.
+- clock-names: Should contain the following:
+ "iface" - Main peripheral bus clock (PCLK/HCLK - AHB Bus clock) (required)
+ "core" - SDC MMC clock (MCLK) (required)
+ "bus" - SDCC bus voter clock (optional)
+
+Optional properties:
+
+- qcom,vdd-voltage-min - Specifies the minimum core voltage supported by the device in microvolts.
+- qcom,vdd-voltage-max - Specifies the maximum core voltage supported by the device in microvolts.
+- qcom,vdd-io-voltage-min - Specifies the minimum i/o voltage supported by the device in microvolts.
+- qcom,vdd-io-voltage-max - Specifies the maximum i/o voltage supported by the device in microvolts.
+
+Example:
+
+ sdhc_1: sdhci@f9824900 {
+ compatible = "qcom,sdhci-msm";
+ reg = <0xf9824900 0x11c>, <0xf9824000 0x800>;
+ reg-names = "hc_mem", "core_mem";
+ interrupts = <0 123 0>, <0 138 0>;
+ interrupt-names = "hc_irq", "pwr_irq";
+ bus-width = <8>;
+ non-removable;
+
+ vdd-supply = <&pm8941_l20>;
+ vdd-io-supply = <&pm8941_s3>;
+
+ qcom,vdd-voltage-min = <2950000>;
+ qcom,vdd-voltage-max = <2950000>;
+ qcom,vdd-io-voltage-min = <1800000>;
+ qcom,vdd-io-voltage-max = <1800000>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdc1_clk &sdc1_cmd &sdc1_data>;
+
+ clocks = <&gcc GCC_SDCC1_APPS_CLK>, <&gcc GCC_SDCC1_AHB_CLK>;
+ clock-names = "core", "iface";
+ };
+
+ sdhc_2: sdhci@f98a4900 {
+ compatible = "qcom,sdhci-msm";
+ reg = <0xf98a4900 0x11c>, <0xf98a4000 0x800>;
+ reg-names = "hc_mem", "core_mem";
+ interrupts = <0 1 2>;
+ #interrupt-cells = <1>;
+ interrupt-map = <0 &intc 0 125 0
+ 1 &intc 0 221 0>;
+ interrupt-names = "hc_irq", "pwr_irq";
+ bus-width = <4>;
+
+ vdd-supply = <&pm8941_l21>;
+ vdd-io-supply = <&pm8941_l13>;
+
+ qcom,vdd-voltage-min = <2950000>;
+ qcom,vdd-voltage-max = <2950000>;
+ qcom,vdd-io-voltage-min = <1800000>;
+ qcom,vdd-io-voltage-max = <2950000>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdc2_clk &sdc2_cmd &sdc2_data>;
+
+ clocks = <&gcc GCC_SDCC2_APPS_CLK>, <&gcc GCC_SDCC2_AHB_CLK>;
+ clock-names = "core", "iface";
+ };
--
1.7.9.5
^ permalink raw reply related
* [PATCH v8 2/3] mmc: sdhci-msm: Initial support for Qualcomm chipsets
From: Georgi Djakov @ 2014-01-30 18:45 UTC (permalink / raw)
To: linux-mmc, cjb, devicetree, grant.likely, rob.herring, pawel.moll,
mark.rutland, swarren, ijc+devicetree, galak, rob, linux-doc,
linux-kernel
Cc: linux-arm-msm, Georgi Djakov
In-Reply-To: <1391107507-17321-1-git-send-email-gdjakov@mm-sol.com>
This platform driver adds the initial support of Secure
Digital Host Controller Interface compliant controller
found in Qualcomm chipsets.
Signed-off-by: Georgi Djakov <gdjakov@mm-sol.com>
---
drivers/mmc/host/Kconfig | 13 ++
drivers/mmc/host/Makefile | 1 +
drivers/mmc/host/sdhci-msm.c | 531 ++++++++++++++++++++++++++++++++++++++++++
3 files changed, 545 insertions(+)
create mode 100644 drivers/mmc/host/sdhci-msm.c
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 1384f67..c32d092 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -334,6 +334,19 @@ config MMC_ATMELMCI
If unsure, say N.
+config MMC_SDHCI_MSM
+ tristate "Qualcomm SDHCI Controller Support"
+ depends on ARCH_MSM
+ depends on MMC_SDHCI_PLTFM
+ help
+ This selects the Secure Digital Host Controller Interface (SDHCI)
+ support present in MSM SOCs from Qualcomm. The controller
+ supports SD/MMC/SDIO devices.
+
+ If you have a controller with this interface, say Y or M here.
+
+ If unsure, say N.
+
config MMC_MSM
tristate "Qualcomm SDCC Controller Support"
depends on MMC && (ARCH_MSM7X00A || ARCH_MSM7X30 || ARCH_QSD8X50)
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index 3483b6b..bbc8445 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -64,6 +64,7 @@ obj-$(CONFIG_MMC_SDHCI_OF_ESDHC) += sdhci-of-esdhc.o
obj-$(CONFIG_MMC_SDHCI_OF_HLWD) += sdhci-of-hlwd.o
obj-$(CONFIG_MMC_SDHCI_BCM_KONA) += sdhci-bcm-kona.o
obj-$(CONFIG_MMC_SDHCI_BCM2835) += sdhci-bcm2835.o
+obj-$(CONFIG_MMC_SDHCI_MSM) += sdhci-msm.o
ifeq ($(CONFIG_CB710_DEBUG),y)
CFLAGS-cb710-mmc += -DDEBUG
diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
new file mode 100644
index 0000000..900e813
--- /dev/null
+++ b/drivers/mmc/host/sdhci-msm.c
@@ -0,0 +1,531 @@
+/*
+ * drivers/mmc/host/sdhci-msm.c - Qualcomm MSM SDHCI Platform
+ * driver source file
+ *
+ * Copyright (c) 2013-2014, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/regulator/consumer.h>
+#include <linux/delay.h>
+
+#include "sdhci-pltfm.h"
+
+#define CORE_HC_MODE 0x78
+#define HC_MODE_EN 0x1
+
+#define CORE_POWER 0x0
+#define CORE_SW_RST BIT(7)
+
+#define CORE_PWRCTL_STATUS 0xdc
+#define CORE_PWRCTL_MASK 0xe0
+#define CORE_PWRCTL_CLEAR 0xe4
+#define CORE_PWRCTL_CTL 0xe8
+
+#define CORE_PWRCTL_BUS_OFF BIT(0)
+#define CORE_PWRCTL_BUS_ON BIT(1)
+#define CORE_PWRCTL_IO_LOW BIT(2)
+#define CORE_PWRCTL_IO_HIGH BIT(3)
+
+#define CORE_PWRCTL_BUS_SUCCESS BIT(0)
+#define CORE_PWRCTL_BUS_FAIL BIT(1)
+#define CORE_PWRCTL_IO_SUCCESS BIT(2)
+#define CORE_PWRCTL_IO_FAIL BIT(3)
+
+#define INT_MASK 0xf
+
+
+/* This structure keeps information per regulator */
+struct sdhci_msm_reg_data {
+ struct regulator *reg;
+ const char *name;
+ /* Voltage level values */
+ u32 low_vol_level;
+ u32 high_vol_level;
+};
+
+struct sdhci_msm_pltfm_data {
+ u32 caps; /* Supported UHS-I Modes */
+ u32 caps2; /* More capabilities */
+ struct sdhci_msm_reg_data vdd; /* VDD/VCC regulator info */
+ struct sdhci_msm_reg_data vdd_io; /* VDD IO regulator info */
+};
+
+struct sdhci_msm_host {
+ struct platform_device *pdev;
+ void __iomem *core_mem; /* MSM SDCC mapped address */
+ int pwr_irq; /* power irq */
+ struct clk *clk; /* main SD/MMC bus clock */
+ struct clk *pclk; /* SDHC peripheral bus clock */
+ struct clk *bus_clk; /* SDHC bus voter clock */
+ struct sdhci_msm_pltfm_data pdata;
+ struct mmc_host *mmc;
+ struct sdhci_pltfm_data sdhci_msm_pdata;
+};
+
+/* MSM platform specific tuning */
+int sdhci_msm_execute_tuning(struct sdhci_host *host, u32 opcode)
+{
+ /*
+ * Tuning is required for SDR104, HS200 and HS400 cards and if the clock
+ * frequency greater than 100MHz in those modes. The standard tuning
+ * procedure should not be executed, but a custom implementation will be
+ * added here instead.
+ */
+ return 0;
+}
+
+#define MAX_PROP_SIZE 32
+static int sdhci_msm_dt_parse_vreg_info(struct device *dev,
+ struct sdhci_msm_reg_data *vreg, const char *vreg_name)
+{
+ char prop_name[MAX_PROP_SIZE];
+ struct device_node *np = dev->of_node;
+
+ vreg->name = vreg_name;
+
+ snprintf(prop_name, MAX_PROP_SIZE, "qcom,%s-voltage-min", vreg_name);
+ of_property_read_u32(np, prop_name, &vreg->low_vol_level);
+ snprintf(prop_name, MAX_PROP_SIZE, "qcom,%s-voltage-max", vreg_name);
+ of_property_read_u32(np, prop_name, &vreg->high_vol_level);
+
+ /* sanity check */
+ if (vreg->low_vol_level > vreg->high_vol_level) {
+ dev_err(dev, "%s invalid constraints specified\n", vreg->name);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+/* Parse devicetree data */
+static int sdhci_msm_populate_pdata(struct device *dev,
+ struct sdhci_msm_pltfm_data *pdata)
+{
+ if (sdhci_msm_dt_parse_vreg_info(dev, &pdata->vdd, "vdd")) {
+ dev_err(dev, "failed parsing vdd data\n");
+ return -EINVAL;
+ }
+
+ if (sdhci_msm_dt_parse_vreg_info(dev, &pdata->vdd_io, "vdd-io")) {
+ dev_err(dev, "failed parsing vdd-io data\n");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int sdhci_msm_vreg_enable(struct device *dev,
+ struct sdhci_msm_reg_data *vreg)
+{
+ int ret = 0;
+
+ if (!regulator_is_enabled(vreg->reg)) {
+ /* Set voltage level */
+ ret = regulator_set_voltage(vreg->reg, vreg->high_vol_level,
+ vreg->high_vol_level);
+ if (ret)
+ return ret;
+ }
+
+ ret = regulator_enable(vreg->reg);
+ if (ret) {
+ dev_err(dev, "regulator_enable(%s) fail (%d)\n",
+ vreg->name, ret);
+ }
+
+ return ret;
+}
+
+static int sdhci_msm_vreg_disable(struct device *dev,
+ struct sdhci_msm_reg_data *vreg)
+{
+ int ret = 0;
+
+ if (!regulator_is_enabled(vreg->reg))
+ return ret;
+
+ /* Set min. voltage to 0 */
+ ret = regulator_set_voltage(vreg->reg, 0, vreg->high_vol_level);
+ if (ret)
+ return ret;
+
+ ret = regulator_disable(vreg->reg);
+ if (ret) {
+ dev_err(dev, "regulator_disable(%s) fail (%d)\n",
+ vreg->name, ret);
+ }
+
+ return ret;
+}
+
+static int sdhci_msm_setup_vreg(struct sdhci_msm_host *msm_host, bool enable)
+{
+ int ret, i;
+ struct sdhci_msm_reg_data *vreg_table[2];
+
+ vreg_table[0] = &msm_host->pdata.vdd;
+ vreg_table[1] = &msm_host->pdata.vdd_io;
+
+ for (i = 0; i < ARRAY_SIZE(vreg_table); i++) {
+ if (enable)
+ ret = sdhci_msm_vreg_enable(&msm_host->pdev->dev,
+ vreg_table[i]);
+ else
+ ret = sdhci_msm_vreg_disable(&msm_host->pdev->dev,
+ vreg_table[i]);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
+/* This init function should be called only once for each SDHC slot */
+static int sdhci_msm_vreg_init(struct device *dev,
+ struct sdhci_msm_pltfm_data *pdata)
+{
+ struct sdhci_msm_reg_data *vdd_reg = &pdata->vdd;
+ struct sdhci_msm_reg_data *vdd_io_reg = &pdata->vdd_io;
+
+ vdd_reg->reg = devm_regulator_get(dev, vdd_reg->name);
+ if (IS_ERR(vdd_reg->reg))
+ return PTR_ERR(vdd_reg->reg);
+
+ vdd_io_reg->reg = devm_regulator_get(dev, vdd_io_reg->name);
+ if (IS_ERR(vdd_io_reg->reg))
+ return PTR_ERR(vdd_io_reg->reg);
+
+ return 0;
+}
+
+static irqreturn_t sdhci_msm_pwr_irq(int irq, void *data)
+{
+ struct sdhci_host *host = (struct sdhci_host *)data;
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+ struct sdhci_msm_host *msm_host = pltfm_host->priv;
+ u8 irq_status;
+ u8 irq_ack = 0;
+ int ret = 0;
+
+ irq_status = readb_relaxed(msm_host->core_mem + CORE_PWRCTL_STATUS);
+ dev_dbg(mmc_dev(msm_host->mmc), "%s: Received IRQ(%d), status=0x%x\n",
+ mmc_hostname(msm_host->mmc), irq, irq_status);
+
+ /* Clear the interrupt */
+ writeb_relaxed(irq_status, (msm_host->core_mem + CORE_PWRCTL_CLEAR));
+ /*
+ * SDHC has core_mem and hc_mem device memory and these memory
+ * addresses do not fall within 1KB region. Hence, any update to
+ * core_mem address space would require an mb() to ensure this gets
+ * completed before its next update to registers within hc_mem.
+ */
+ mb();
+
+ /* Handle BUS ON/OFF */
+ if (irq_status & CORE_PWRCTL_BUS_ON) {
+ ret = sdhci_msm_setup_vreg(msm_host, true);
+ if (!ret)
+ ret = regulator_set_voltage(msm_host->pdata.vdd_io.reg,
+ msm_host->pdata.
+ vdd_io.high_vol_level,
+ msm_host->pdata.
+ vdd_io.high_vol_level);
+ if (ret)
+ irq_ack |= CORE_PWRCTL_BUS_FAIL;
+ else
+ irq_ack |= CORE_PWRCTL_BUS_SUCCESS;
+ }
+
+ if (irq_status & CORE_PWRCTL_BUS_OFF) {
+ ret = sdhci_msm_setup_vreg(msm_host, false);
+ if (!ret)
+ ret = regulator_set_voltage(msm_host->pdata.vdd_io.reg,
+ msm_host->pdata.
+ vdd_io.low_vol_level,
+ msm_host->pdata.
+ vdd_io.low_vol_level);
+ if (ret)
+ irq_ack |= CORE_PWRCTL_BUS_FAIL;
+ else
+ irq_ack |= CORE_PWRCTL_BUS_SUCCESS;
+ }
+
+ /* Handle IO LOW/HIGH */
+ if (irq_status & CORE_PWRCTL_IO_LOW) {
+ ret = regulator_set_voltage(msm_host->pdata.vdd_io.reg,
+ msm_host->pdata.
+ vdd_io.low_vol_level,
+ msm_host->pdata.
+ vdd_io.low_vol_level);
+ if (ret)
+ irq_ack |= CORE_PWRCTL_IO_FAIL;
+ else
+ irq_ack |= CORE_PWRCTL_IO_SUCCESS;
+ }
+
+ if (irq_status & CORE_PWRCTL_IO_HIGH) {
+ ret = regulator_set_voltage(msm_host->pdata.vdd_io.reg,
+ msm_host->pdata.
+ vdd_io.high_vol_level,
+ msm_host->pdata.
+ vdd_io.high_vol_level);
+ if (ret)
+ irq_ack |= CORE_PWRCTL_IO_FAIL;
+ else
+ irq_ack |= CORE_PWRCTL_IO_SUCCESS;
+ }
+
+ /* ACK status to the core */
+ writeb_relaxed(irq_ack, (msm_host->core_mem + CORE_PWRCTL_CTL));
+ /*
+ * SDHC has core_mem and hc_mem device memory and these memory
+ * addresses do not fall within 1KB region. Hence, any update to
+ * core_mem address space would require an mb() to ensure this gets
+ * completed before its next update to registers within hc_mem.
+ */
+ mb();
+
+ dev_dbg(mmc_dev(msm_host->mmc), "%s: Handled IRQ(%d), ret=%d, ack=0x%x\n",
+ mmc_hostname(msm_host->mmc), irq, ret, irq_ack);
+ return IRQ_HANDLED;
+}
+
+static const struct of_device_id sdhci_msm_dt_match[] = {
+ { .compatible = "qcom,sdhci-msm" },
+ {},
+};
+
+MODULE_DEVICE_TABLE(of, sdhci_msm_dt_match);
+
+static struct sdhci_ops sdhci_msm_ops = {
+ .platform_execute_tuning = sdhci_msm_execute_tuning,
+};
+
+static int sdhci_msm_probe(struct platform_device *pdev)
+{
+ struct sdhci_host *host;
+ struct sdhci_pltfm_host *pltfm_host;
+ struct sdhci_msm_host *msm_host;
+ struct resource *core_memres = NULL;
+ int ret, dead;
+ u16 host_version;
+
+ if (!pdev->dev.of_node) {
+ dev_err(&pdev->dev, "No device tree data\n");
+ return -ENOENT;
+ }
+
+ msm_host = devm_kzalloc(&pdev->dev, sizeof(*msm_host), GFP_KERNEL);
+ if (!msm_host)
+ return -ENOMEM;
+
+ msm_host->sdhci_msm_pdata.ops = &sdhci_msm_ops;
+ host = sdhci_pltfm_init(pdev, &msm_host->sdhci_msm_pdata, 0);
+ if (IS_ERR(host)) {
+ dev_err(&pdev->dev, "sdhci_pltfm_init error\n");
+ return PTR_ERR(host);
+ }
+
+ pltfm_host = sdhci_priv(host);
+ pltfm_host->priv = msm_host;
+ msm_host->mmc = host->mmc;
+ msm_host->pdev = pdev;
+
+ ret = mmc_of_parse(host->mmc);
+ if (ret) {
+ dev_err(&pdev->dev, "failed parsing mmc device tree\n");
+ goto pltfm_free;
+ }
+
+ sdhci_get_of_property(pdev);
+
+ ret = sdhci_msm_populate_pdata(&pdev->dev, &msm_host->pdata);
+ if (ret) {
+ dev_err(&pdev->dev, "DT parsing error\n");
+ goto pltfm_free;
+ }
+
+ /* Setup SDCC bus voter clock. */
+ msm_host->bus_clk = devm_clk_get(&pdev->dev, "bus");
+ if (!IS_ERR(msm_host->bus_clk)) {
+ /* Vote for max. clk rate for max. performance */
+ ret = clk_set_rate(msm_host->bus_clk, INT_MAX);
+ if (ret)
+ goto pltfm_free;
+ ret = clk_prepare_enable(msm_host->bus_clk);
+ if (ret)
+ goto pltfm_free;
+ }
+
+ /* Setup main peripheral bus clock */
+ msm_host->pclk = devm_clk_get(&pdev->dev, "iface");
+ if (!IS_ERR(msm_host->pclk)) {
+ ret = clk_prepare_enable(msm_host->pclk);
+ if (ret) {
+ dev_err(&pdev->dev,
+ "Main peripheral clock setup fail (%d)\n", ret);
+ goto bus_clk_disable;
+ }
+ }
+
+ /* Setup SDC MMC clock */
+ msm_host->clk = devm_clk_get(&pdev->dev, "core");
+ if (IS_ERR(msm_host->clk)) {
+ ret = PTR_ERR(msm_host->clk);
+ dev_err(&pdev->dev, "SDC MMC clock setup fail (%d)\n", ret);
+ goto pclk_disable;
+ }
+
+ ret = clk_prepare_enable(msm_host->clk);
+ if (ret)
+ goto pclk_disable;
+
+ /* Setup regulators */
+ ret = sdhci_msm_vreg_init(&pdev->dev, &msm_host->pdata);
+ if (ret) {
+ if (ret != -EPROBE_DEFER)
+ dev_err(&pdev->dev, "Regulator setup fail (%d)\n", ret);
+ goto clk_disable;
+ }
+
+ core_memres = platform_get_resource_byname(pdev,
+ IORESOURCE_MEM, "core_mem");
+ msm_host->core_mem = devm_ioremap_resource(&pdev->dev, core_memres);
+
+ if (IS_ERR(msm_host->core_mem)) {
+ dev_err(&pdev->dev, "Failed to remap registers\n");
+ ret = PTR_ERR(msm_host->core_mem);
+ goto vreg_disable;
+ }
+
+ /* Reset the core and Enable SDHC mode */
+ writel_relaxed(readl_relaxed(msm_host->core_mem + CORE_POWER) |
+ CORE_SW_RST, msm_host->core_mem + CORE_POWER);
+
+ /* SW reset can take upto 10HCLK + 15MCLK cycles. (min 40us) */
+ usleep_range(1000, 5000);
+ if (readl(msm_host->core_mem + CORE_POWER) & CORE_SW_RST) {
+ dev_err(&pdev->dev, "Stuck in reset\n");
+ ret = -ETIMEDOUT;
+ goto vreg_disable;
+ }
+
+ /* Set HC_MODE_EN bit in HC_MODE register */
+ writel_relaxed(HC_MODE_EN, (msm_host->core_mem + CORE_HC_MODE));
+
+ /*
+ * Following are the deviations from SDHC spec v3.0 -
+ * 1. Card detection is handled using separate GPIO.
+ * 2. Bus power control is handled by interacting with PMIC.
+ */
+ host->quirks |= SDHCI_QUIRK_BROKEN_CARD_DETECTION;
+ host->quirks |= SDHCI_QUIRK_SINGLE_POWER_WRITE;
+
+ host_version = readw_relaxed((host->ioaddr + SDHCI_HOST_VERSION));
+ dev_dbg(&pdev->dev, "Host Version: 0x%x Vendor Version 0x%x\n",
+ host_version, ((host_version & SDHCI_VENDOR_VER_MASK) >>
+ SDHCI_VENDOR_VER_SHIFT));
+
+ /* Setup PWRCTL irq */
+ msm_host->pwr_irq = platform_get_irq_byname(pdev, "pwr_irq");
+ if (msm_host->pwr_irq < 0) {
+ dev_err(&pdev->dev, "Failed to get pwr_irq by name (%d)\n",
+ msm_host->pwr_irq);
+ goto vreg_disable;
+ }
+ ret = devm_request_threaded_irq(&pdev->dev, msm_host->pwr_irq, NULL,
+ sdhci_msm_pwr_irq, IRQF_ONESHOT,
+ dev_name(&pdev->dev), host);
+ if (ret) {
+ dev_err(&pdev->dev, "Request threaded irq(%d) fail (%d)\n",
+ msm_host->pwr_irq, ret);
+ goto vreg_disable;
+ }
+
+ /* Enable pwr irq interrupts */
+ writel_relaxed(INT_MASK, (msm_host->core_mem + CORE_PWRCTL_MASK));
+
+ msm_host->mmc->caps |= msm_host->pdata.caps;
+ msm_host->mmc->caps2 |= msm_host->pdata.caps2;
+
+ ret = sdhci_add_host(host);
+ if (ret) {
+ dev_err(&pdev->dev, "Add host fail (%d)\n", ret);
+ goto vreg_disable;
+ }
+
+ ret = clk_set_rate(msm_host->clk, host->max_clk);
+ if (ret) {
+ dev_err(&pdev->dev, "MClk rate set fail (%d)\n", ret);
+ goto remove_host;
+ }
+
+ return 0;
+
+remove_host:
+ dead = (readl_relaxed(host->ioaddr + SDHCI_INT_STATUS) == 0xffffffff);
+ sdhci_remove_host(host, dead);
+vreg_disable:
+ if (!IS_ERR(msm_host->pdata.vdd.reg))
+ sdhci_msm_vreg_disable(&pdev->dev, &msm_host->pdata.vdd);
+ if (!IS_ERR(msm_host->pdata.vdd_io.reg))
+ sdhci_msm_vreg_disable(&pdev->dev, &msm_host->pdata.vdd_io);
+clk_disable:
+ if (!IS_ERR(msm_host->clk))
+ clk_disable_unprepare(msm_host->clk);
+pclk_disable:
+ if (!IS_ERR(msm_host->pclk))
+ clk_disable_unprepare(msm_host->pclk);
+bus_clk_disable:
+ if (!IS_ERR(msm_host->bus_clk))
+ clk_disable_unprepare(msm_host->bus_clk);
+pltfm_free:
+ sdhci_pltfm_free(pdev);
+ return ret;
+}
+
+static int sdhci_msm_remove(struct platform_device *pdev)
+{
+ struct sdhci_host *host = platform_get_drvdata(pdev);
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+ struct sdhci_msm_host *msm_host = pltfm_host->priv;
+ int dead = (readl_relaxed(host->ioaddr + SDHCI_INT_STATUS) ==
+ 0xffffffff);
+
+ sdhci_remove_host(host, dead);
+ sdhci_pltfm_free(pdev);
+ sdhci_msm_vreg_disable(&pdev->dev, &msm_host->pdata.vdd);
+ sdhci_msm_vreg_disable(&pdev->dev, &msm_host->pdata.vdd_io);
+ clk_disable_unprepare(msm_host->clk);
+ clk_disable_unprepare(msm_host->pclk);
+ if (!IS_ERR(msm_host->bus_clk))
+ clk_disable_unprepare(msm_host->bus_clk);
+ return 0;
+}
+
+static struct platform_driver sdhci_msm_driver = {
+ .probe = sdhci_msm_probe,
+ .remove = sdhci_msm_remove,
+ .driver = {
+ .name = "sdhci_msm",
+ .owner = THIS_MODULE,
+ .of_match_table = sdhci_msm_dt_match,
+ },
+};
+
+module_platform_driver(sdhci_msm_driver);
+
+MODULE_DESCRIPTION("Qualcomm Secure Digital Host Controller Interface driver");
+MODULE_LICENSE("GPL v2");
--
1.7.9.5
^ 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