On Mon, 03 Nov 2014 16:06:03 +0100
, Arnd Bergmann
wrote:
> On Friday 31 October 2014 23:53:28 Rafael J. Wysocki wrote:
> > On Saturday, November 01, 2014 05:13:45 AM Rob Herring wrote:
> > > On Fri, Oct 31, 2014 at 6:59 AM, Gilad Avidov
> > > wrote:
> > > >
> > > > Device-Tree compact API
> >
On Mon, 08 Sep 2014 13:22:44 -0700, Stephen Boyd wrote:
> Adding Mark Brown who finished off introducing IORESOURCE_REG.
>
> On 09/08/14 07:52, Grant Likely wrote:
> > On Tue, 2 Sep 2014 18:45:00 +0300, Stanimir Varbanov
> > wrote:
> >> +
> >>
On Tue, 2 Sep 2014 18:45:00 +0300, Stanimir Varbanov
wrote:
> Hi Grant,
>
> I came down to this. Could you review? Is that
> implementation closer to the suggestion made by you.
>
> ---
> drivers/of/address.c | 49
>
> drivers/of/platform.
On Fri, Aug 15, 2014 at 5:38 PM, Rob Herring wrote:
> Adding Greg...
>
> On Tue, Aug 12, 2014 at 9:30 PM, Stepan Moskovchenko
> wrote:
>> When we parse the device tree and allocate platform
>> devices, the 'name' of the newly-created platform_device
>> is set to point to the 'name' field of the '
On Fri, Aug 15, 2014 at 11:52 AM, Grant Likely wrote:
> On Fri, Aug 15, 2014 at 11:45 AM, Grant Likely
> wrote:
>> On Tue, 12 Aug 2014 18:46:36 -0700, Stephen Boyd
>> wrote:
>>> On 08/12/14 17:57, Stepan Moskovchenko wrote:
>>> > diff --git a/dr
On Fri, Aug 15, 2014 at 11:45 AM, Grant Likely wrote:
> On Tue, 12 Aug 2014 18:46:36 -0700, Stephen Boyd wrote:
>> On 08/12/14 17:57, Stepan Moskovchenko wrote:
>> > diff --git a/drivers/of/device.c b/drivers/of/device.c
>> > index f685e55..3e116f6 100644
>
On Tue, 12 Aug 2014 18:46:36 -0700, Stephen Boyd wrote:
> On 08/12/14 17:57, Stepan Moskovchenko wrote:
> > diff --git a/drivers/of/device.c b/drivers/of/device.c
> > index f685e55..3e116f6 100644
> > --- a/drivers/of/device.c
> > +++ b/drivers/of/device.c
> > @@ -54,7 +54,7 @@ int of_device_add(s
On Fri, 18 Jul 2014 19:13:52 +0300, Stanimir Varbanov
wrote:
> On 07/18/2014 02:10 AM, Stephen Boyd wrote:
> > On 07/17/14 09:17, Stanimir Varbanov wrote:
> >> Hello everyone,
> >>
> >> Here is the continuation of patch sets sent recently about Qualcomm
> >> QPNP SPMI PMICs.
> >>
> >> The previou
On Tue, 29 Jul 2014 17:06:42 +0300, Stanimir Varbanov
wrote:
> Arnd, thanks for the comments.
>
> On 07/29/2014 03:00 PM, Arnd Bergmann wrote:
> > On Tuesday 29 July 2014 14:42:31 Stanimir Varbanov wrote:
> >> taddr = of_translate_address(dev, addrp);
> >> - if (taddr == OF_BAD_ADD
On Tue, 1 Jul 2014 22:02:31 +0530, Viresh Kumar
wrote:
> Create a new routine of_clk_shared_by_cpus() that finds if clock lines are
> shared between two CPUs. This is verified by comparing "clocks" property from
> CPU's DT node.
>
> Returns 1 if clock line is shared between them, 0 if clock isn
On Tue, 03 Jun 2014 11:21:10 +0200, Arnd Bergmann wrote:
> On Tuesday 03 June 2014 09:44:59 Grant Likely wrote:
> > > The reason I think allow an ECAM makes sense in ranges is because it
> > > allows for a direct IO read/write to CFG space (w/o any mapping) similar
>
On Mon, 2 Jun 2014 13:09:08 -0500, Kumar Gala wrote:
>
> On Jun 2, 2014, at 11:23 AM, Grant Likely wrote:
>
> > On Mon, 2 Jun 2014 10:40:30 -0500, Kumar Gala wrote:
> >>
> >> On Jun 2, 2014, at 10:09 AM, Grant Likely wrote:
> >>
> >>
On Mon, 2 Jun 2014 10:40:30 -0500, Kumar Gala wrote:
>
> On Jun 2, 2014, at 10:09 AM, Grant Likely wrote:
>
> > On Sat, 31 May 2014 20:41:04 +0200, Arnd Bergmann wrote:
> >> On Saturday 31 May 2014 01:36:40 Liviu Dudau wrote:
> >>> We would like to be abl
On Sat, 31 May 2014 20:41:04 +0200, Arnd Bergmann wrote:
> On Saturday 31 May 2014 01:36:40 Liviu Dudau wrote:
> > We would like to be able to describe PCIe ECAM resources as
> > IORESOURCE_MEM blocks while distinguish them from standard
> > memory resources. Add an IORESOURCE_BIT entry for this c
t;
> Change-Id: I9d04e636f43bf939e13b4934dc23da0c076811d2
> Acked-by: Jason Cooper
> Acked-by: Catalin Marinas
> Acked-by: Santosh Shilimkar
> Tested-by: Leif Lindholm
> Signed-off-by: Laura Abbott
Tested-by: Grant Likely
Tiny nit-picking comment below, but this patch looks
On Wed, Feb 5, 2014 at 12:02 AM, Laura Abbott wrote:
> memblock is now fully integrated into the kernel and is the prefered
> method for tracking memory. Rather than reinvent the wheel with
> meminfo, migrate to using memblock directly instead of meminfo as
> an intermediate.
>
> Signed-off-by: La
On Fri, 25 Oct 2013 15:24:03 -0500, Andy Gross wrote:
> Add device tree probe support for the MSM BAM DMA driver.
>
> Signed-off-by: Andy Gross
> ---
> .../devicetree/bindings/dma/msm_bam_dma.txt| 49
>
> 1 file changed, 49 insertions(+)
> create mode 100644 Doc
On Fri, 26 Apr 2013 16:17:52 -0700, Stepan Moskovchenko
wrote:
>
> Hello. I am creating a DTS file for an ARM (Qualcomm MSM) target which
> supports LPAE, meaning that the target is capable of addressing memory
> beyond the standard 4GB boundary. To account for the fact that the
> memory node
good to me. Go ahead and take it through the same tree as patches
1/3 and 2/3 with my ack since it appears that the patches need to be
applied together.
Acked-by: Grant Likely
g.
> ---
> .../devicetree/bindings/gpio/gpio-msm.txt | 26 +++
> arch/arm/boot/dts/msm8660-surf.dt
On Sun, 02 Jun 2013 19:31:33 -0700, Rohit Vaswani
wrote:
> On 6/1/2013 1:09 AM, Grant Likely wrote:
> > On Sat, Jun 1, 2013 at 1:22 AM, Rohit Vaswani
> > wrote:
> >> This cleans up the gpio-msm-v2 driver of all the global define usage.
> >> The number of gp
On Sat, Jun 1, 2013 at 1:22 AM, Rohit Vaswani wrote:
> This cleans up the gpio-msm-v2 driver of all the global define usage.
> The number of gpios are now defined in the device tree. This enables
> adding irqdomain support as well.
>
> Signed-off-by: Rohit Vaswani
> ---
> .../devicetree/bindings
On Fri, May 31, 2013 at 9:01 PM, Andy Shevchenko
wrote:
> On Thu, May 23, 2013 at 3:29 AM, Rohit Vaswani
> wrote:
>> This cleans up the gpio-msm-v2 driver of all the global define usage.
>> The number of gpios are now defined in the device tree. This enables
>> adding irqdomain support as well.
+ { .compatible = "qcom,msm-gpio", },
> + { },
> +};
> +
> static int msm_gpio_remove(struct platform_device *dev)
> {
> int ret = gpiochip_remove(&msm_gpio.gpio_chip);
> @@ -392,36 +465,11 @@ static struct platform_driver msm_gpio_driver = {
> .driver = {
> .name = "msmgpio",
> .owner = THIS_MODULE,
> + .of_match_table = of_match_ptr(msm_gpio_of_match),
You don't need the of_match_ptr() macro if msm_gpio_of_match[] is
unconditionally present (which in this patch it is)
> },
> };
>
> -static struct platform_device msm_device_gpio = {
> - .name = "msmgpio",
> - .id = -1,
> -};
> -
> -static int __init msm_gpio_init(void)
> -{
> - int rc;
> -
> - rc = platform_driver_register(&msm_gpio_driver);
> - if (!rc) {
> - rc = platform_device_register(&msm_device_gpio);
> - if (rc)
> - platform_driver_unregister(&msm_gpio_driver);
> - }
> -
> - return rc;
> -}
> -
> -static void __exit msm_gpio_exit(void)
> -{
> - platform_device_unregister(&msm_device_gpio);
> - platform_driver_unregister(&msm_gpio_driver);
> -}
> -
> -postcore_initcall(msm_gpio_init);
> -module_exit(msm_gpio_exit);
> +module_platform_driver(msm_gpio_driver)
>
> MODULE_AUTHOR("Gregory Bean ");
> MODULE_DESCRIPTION("Driver for Qualcomm MSM TLMMv2 SoC GPIOs");
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation
>
--
Grant Likely, B.Sc, P.Eng.
Secret Lab Technologies, Ltd.
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, May 9, 2013 at 5:52 PM, Saravana Kannan wrote:
> On 05/09/2013 04:50 AM, Grant Likely wrote:
>>
>> On Thu, May 9, 2013 at 11:07 AM, Ming Lei wrote:
>>>
>>> On Thu, May 9, 2013 at 1:18 PM, Saravana Kannan
>>> wrote:
>>>>
>>&
On Thu, May 9, 2013 at 3:14 PM, Russell King - ARM Linux
wrote:
> On Thu, May 09, 2013 at 02:50:17PM +0100, Mark Brown wrote:
>> On Thu, May 09, 2013 at 12:50:46PM +0100, Grant Likely wrote:
>>
>> > However, if a device that shuts down resources after init has
>> &g
On Thu, May 9, 2013 at 11:07 AM, Ming Lei wrote:
> On Thu, May 9, 2013 at 1:18 PM, Saravana Kannan
> wrote:
>>
>> The most obvious fallback of using late_initcall_sync() also doesn't work
>> since the deferred probing work initated during late_initcall() is done in
>> a workqueue. So, frameworks
On Thu, 6 Dec 2012 14:55:41 -0800, Stepan Moskovchenko
wrote:
> In some situations, userspace may want to resolve a
> device by function and logical number (ie, "serial0")
> rather than by the base address or full device path. Being
> able to resolve a device by alias frees userspace from the
>
On Wed, 5 Dec 2012 23:49:25 -0800, Stepan Moskovchenko
wrote:
> In some situations, userspace may want to resolve a
> device by function and logical number (ie, "serial0")
> rather than by the base address or full device path. Being
> able to resolve a device by alias frees userspace from the
>
t_modalias(struct device *dev,
> char *str, ssize_t len);
>
> extern void of_device_uevent(struct device *dev, struct kobj_uevent_env
> *env);
> +extern void of_device_uevent_aliases(struct device_node *node,
> +
On Fri, 16 Nov 2012 19:29:09 -0800, Stepan Moskovchenko
wrote:
> On 11/15/2012 8:10 AM, Grant Likely wrote:
> > On Mon, 12 Nov 2012 18:48:43 -0800, Stepan Moskovchenko
> > wrote:
> >
> > Well, why exactly do you want to control the names of devices? Is it so
> >
On Mon, 12 Nov 2012 18:48:43 -0800, Stepan Moskovchenko
wrote:
> On 11/11/2012 5:45 PM, Stepan Moskovchenko wrote:
> >
> >> On Sun, Nov 11, 2012 at 2:32 AM, Rob Herring
> >> wrote:
> >>> On 11/09/2012 06:48 PM, Stepan Moskovchenko wrote:
> Use the cell-index property to construct names for
On Sun, Nov 11, 2012 at 2:32 AM, Rob Herring wrote:
> On 11/09/2012 06:48 PM, Stepan Moskovchenko wrote:
>> Use the cell-index property to construct names for platform
>> devices, falling back on the existing scheme of using the
>> device register address if cell-index is not specified.
>>
>> The
On Mon, Apr 23, 2012 at 4:47 PM, David Brown wrote:
> As of
>
> commit 75294957be1dee7d22dd7d90bd31334ba410e836
> Author: Grant Likely
> Date: Tue Feb 14 14:06:57 2012 -0700
>
> irq_domain: Remove 'new' irq_domain in favour of the ppc one
>
&g
On Fri, 6 Apr 2012 08:16:10 -0700, David Brown wrote:
> On Thu, Apr 05, 2012 at 01:08:29PM -0700, David Brown wrote:
> > On Thu, Apr 05, 2012 at 01:23:46PM -0600, Stephen Warren wrote:
> > > On 04/05/2012 12:15 PM, David Brown wrote:
> > > > Some MSM SoCs have a small serial-type "bus" that is use
On Wed, Dec 07, 2011 at 11:37:58PM +0100, Wolfram Sang wrote:
> On Mon, Nov 14, 2011 at 02:58:27PM -0700, Harini Jayaraman wrote:
> > This bus driver supports the QUP SPI hardware controller in the Qualcomm
> > MSM SOCs. The Qualcomm Universal Peripheral Engine (QUP) is a general
> > purpose data p
On Thu, Jan 19, 2012 at 04:29:43PM -0800, Michael Bohan wrote:
> On 1/19/2012 3:04 PM, Rob Herring wrote:
> >No doubt that arch_probe_nr_irqs is doing the wrong thing on ARM, but no
> >pre-allocation is not what we want either. We ultimately want
> >arch_probe_nr_irqs to return NR_IRQS_LEGACY (16)
On Mon, Jan 16, 2012 at 8:42 PM, Benjamin Herrenschmidt
wrote:
> On Mon, 2012-01-16 at 18:43 -0800, Michael Bohan wrote:
>>
>> I was planning on sending these patches out, but it seems like with
>> Grant's patches, they may no longer be up to date. I was curious if any
>> thought was given to supp
On Fri, Nov 4, 2011 at 1:46 PM, Pavan Kondeti wrote:
> On 11/4/2011 10:15 PM, Grant Likely wrote:
>> The host controller node names as "usb@" as you have here is
>> exactly right. The driver doesn't care and will only look at the
>> compatible list. OTG co
On Fri, Nov 4, 2011 at 4:25 AM, Pavan Kondeti wrote:
> Hi
>
> I am working on adding USB device tree support for MSM platform. One of
> our chip set has 2 hsusb cores. The first core is configured as otg and
> the other core is configured in host only mode (EHCI compliant). Are the
> below device
On Fri, Nov 4, 2011 at 12:08 PM, Grant Likely wrote:
> On Fri, Nov 4, 2011 at 11:43 AM, Greg KH wrote:
>> On Fri, Nov 04, 2011 at 01:55:09PM +0530, Pavan Kondeti wrote:
>>> Hi
>>>
>>> I am working on adding USB device tree support for MSM platform. One of
>
On Fri, Nov 4, 2011 at 11:43 AM, Greg KH wrote:
> On Fri, Nov 04, 2011 at 01:55:09PM +0530, Pavan Kondeti wrote:
>> Hi
>>
>> I am working on adding USB device tree support for MSM platform. One of
>> our chip set has 2 hsusb cores. The first core is configured as otg and
>> the other core is conf
On Tue, Aug 09, 2011 at 10:32:30PM +0100, Russell King - ARM Linux wrote:
> On Tue, Aug 09, 2011 at 03:00:55PM -0600, Grant Likely wrote:
> > On Tue, Aug 09, 2011 at 09:04:12AM +0100, Russell King - ARM Linux wrote:
> > > This is a preliminary posting of my gpio patch set.
>
On Tue, Aug 09, 2011 at 09:04:12AM +0100, Russell King - ARM Linux wrote:
> This is a preliminary posting of my gpio patch set.
>
> This patch series moves the trivial gpiolib implementations out of
> mach/gpio.h and into asm/gpio.h.
>
> As a side effect of that, most of this patch series is abou
On Thu, Aug 4, 2011 at 5:56 PM, Scott Wood wrote:
>> +#ifndef SPARC
>> +extern void __iomem *of_iomap_nocache(struct device_node *device, int
>> index);
>> +#else
>> +static inline void __iomem *of_iomap_nocache(struct device_node *device,
>> + int index)
>> +{
>> + return of_i
On Thu, Aug 4, 2011 at 12:51 PM, David Miller wrote:
> From: David Brown
> Date: Thu, 4 Aug 2011 03:36:36 -0700
>
>> Add uncached mappings from devicetree nodes similar to regular io
>> mappings.
>>
>> SPARC is coherent, so there this call is the same as regular of_iomap.
>>
>> Cc: David Miller
On Fri, Jun 03, 2011 at 03:44:19PM -0700, David Brown wrote:
> Migrate the driver for the v7-based MSM chips into drivers/gpio. The
> driver is unchanged, only moved.
>
> Signed-off-by: David Brown
> Acked-by: Linus Walleij
> Acked-by: Nicolas Pitre
Similar to patch 6, some comments below.
>
On Fri, Jun 03, 2011 at 03:44:18PM -0700, David Brown wrote:
> Migrate the driver for the v6-based MSM chips into drivers/gpio. The
> driver is unchanged, only moved.
>
> Signed-off-by: David Brown
> Acked-by: Linus Walleij
> Acked-by: Nicolas Pitre
Hi David,
Comments below. When you repost
On Wed, May 18, 2011 at 02:50:46PM -0700, David Brown wrote:
> This patch series moves the Qualcomm MSM gpio device drivers into the
> drivers/gpio directory.
>
> The MSM's have two flavors of gpio driver. The one for the newer
> v7-based chips is a bit cleaner, and can just be moved. The one fo
On Tue, Apr 26, 2011 at 11:18:47PM -0700, Abhijeet Dharmapurikar wrote:
> From: David Collins
>
> Add support for multi-purpose pins (MPPs) on Qualcomm PM8xxx
> PMIC chips.
>
> PM8xxx MPPs can be configured as digital or analog inputs or
> outputs, current sinks, or buffers.
>
> Note that mpp p
, and not until
there is some semblance of an alternative (not your fault, I know.
You're patch just happens to have my attention).
Some minor comments below. If they are fixed up, then Samuel can pick
it up with my:
Acked-by: Grant Likely
> ---
> drivers/gpio/Kconfig
On Thu, Mar 17, 2011 at 01:27:22PM -0700, Abhijeet Dharmapurikar wrote:
> Grant Likely wrote:
> >On Wed, Mar 16, 2011 at 07:23:58PM -0700, adhar...@codeaurora.org wrote:
> >>Add support for GPIO on Qualcomm PM8xxx PMIC chips.
> >>
> >>Signed-off-by: Abhijee
On Wed, Mar 16, 2011 at 07:23:58PM -0700, adhar...@codeaurora.org wrote:
> Add support for GPIO on Qualcomm PM8xxx PMIC chips.
>
> Signed-off-by: Abhijeet Dharmapurikar
Minor points below, but otherwise:
Acked-by: Grant Likely
> ---
> drivers/gpio/Kconfig |
On Wed, Mar 16, 2011 at 07:56:32PM +, Mark Brown wrote:
> On Wed, Mar 16, 2011 at 01:54:44PM -0600, Grant Likely wrote:
>
> > Yes, remove the comment. I'll probably also remove the comment for
> > MODULbus and AC97.
>
> In theory there should be more AC'97
On Wed, Mar 16, 2011 at 11:55:19AM -0700, Abhijeet Dharmapurikar wrote:
>
> >>
> >>diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> >>index 664660e..c5e6f51 100644
> >>--- a/drivers/gpio/Kconfig
> >>+++ b/drivers/gpio/Kconfig
> >>@@ -411,4 +411,14 @@ config GPIO_JANZ_TTL
> >> This d
On Mon, Mar 07, 2011 at 10:09:47PM -0800, adhar...@codeaurora.org wrote:
> From: Abhijeet Dharmapurikar
>
> Add support for GPIO on Qualcomm PM8xxx PMIC chips.
>
>
> Signed-off-by: Abhijeet Dharmapurikar
> ---
Hi Abhijeet,
comments below, but mostly looks good to me.
g.
> drivers/gpio/Kco
On Fri, Aug 20, 2010 at 6:10 PM, Kevin Hilman
wrote:
> Grant Likely writes:
>
> [...]
>
>>>>
>>>> My fears on this point may very well be unfounded. This isn't the
>>>> hill I'm going to die on either. Show me an implementati
On Fri, Aug 20, 2010 at 12:51 PM, Kevin Hilman
wrote:
> Grant Likely writes:
>
> [...]
>
>>> One of the primary goals of this (at least for me and it seems Magnus also)
>>> is to keep drivers ignorant of their bus type, and any bus-type-specific
>>&
; platform_bus. We've been using that in OMAP for a while now and have
> not seen any need to for the drivers to know if they are on the vanilla
> platform_bus or the customized one.
>
> I'm very curious to hear what type of impact you expect to the drivers.
My fears on this poin
_device msm_bus = {
.name = "msm_sample_bus",
};
struct platform_device msm_device_uart1 = {
.name = "msm_serial",
.id = 1,
.num_resources = ARRAY_SIZE(resource_uart3),
.resource = resources_uart3,
.dev = {
.parent = &msm_bus.dev,
},
};
Then look at the effect on the system. Data like topology can and
should be defined in a static manor; either like the above, or as I
prefer, in a flattened device tree file.
Hmmm, I've written a lot. I should summarize. On the topology front,
it is a separate issue, and can be solved right now without a new bus
type.
On the new bus_type front, I'm still not convinced. However,
supporting PM operations is the most likely line of argument that
would sway me. I've got to reply to Kevin's email and I'll elaborate
there. I'm particularly concerned about the concept of sharing device
driver instances between bus_types.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
rq NULL
> +#define platform_pm_restore_noirq NULL
> +#endif /* !CONFIG_HIBERNATION */
> +
> +#ifdef CONFIG_PM_RUNTIME
> +extern int __weak platform_pm_runtime_suspend(struct device *dev);
> +extern int __weak platform_pm_runtime_resume(struct device *dev);
> +extern int __weak platform_pm_runtime_idle(struct device *dev);
> +#else /* !CONFIG_PM_RUNTIME */
> +#define platform_pm_runtime_suspend NULL
> +#define platform_pm_runtime_resume NULL
> +#define platform_pm_runtime_idle NULL
> +#endif /* !CONFIG_PM_RUNTIME */
> +
> +extern const struct dev_pm_ops platform_dev_pm_ops;
> +
> +#define PLATFORM_BUS_TEMPLATE \
> + .name = "XXX_OVERRIDEME_XXX", \
> + .dev_attrs = platform_dev_attrs, \
> + .match = platform_match, \
> + .uevent = platform_uevent, \
> + .pm = &platform_dev_pm_ops
> +
> +#define PLATFORM_PM_OPS_TEMPLATE \
> + .prepare = platform_pm_prepare, \
> + .complete = platform_pm_complete, \
> + .suspend = platform_pm_suspend, \
> + .resume = platform_pm_resume, \
> + .freeze = platform_pm_freeze, \
> + .thaw = platform_pm_thaw, \
> + .poweroff = platform_pm_poweroff, \
> + .restore = platform_pm_restore, \
> + .suspend_noirq = platform_pm_suspend_noirq, \
> + .resume_noirq = platform_pm_resume_noirq, \
> + .freeze_noirq = platform_pm_freeze_noirq, \
> + .thaw_noirq = platform_pm_thaw_noirq, \
> + .poweroff_noirq = platform_pm_poweroff_noirq, \
> + .restore_noirq = platform_pm_restore_noirq, \
> + .runtime_suspend = platform_pm_runtime_suspend, \
> + .runtime_resume = platform_pm_runtime_resume, \
> + .runtime_idle = platform_pm_runtime_idle
> +
> /* early platform driver interface */
> struct early_platform_driver {
> const char *class_str;
> --
> 1.7.2.1
>
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
obe, &msm_driver_register);
> +}
> +
> +static int __init msm_bus_init(void)
> +{
> + int error;
> +
> + error = bus_register(&msm_bus_type);
> + if (error)
> + return error;
> +
> + error = msm_device_register(&msm_apps_bus);
> +
On Mon, Aug 16, 2010 at 12:47 PM, Patrick Pannuto
wrote:
> On 08/13/2010 03:05 PM, Grant Likely wrote:
>>> @@ -1017,6 +1022,87 @@ struct bus_type platform_bus_type = {
>>> };
>>> EXPORT_SYMBOL_GPL(platform_bus_type);
>>>
>>> +/** pseudo_platform
"Moffett, Kyle D" wrote:
>On Aug 10, 2010, at 19:49, Patrick Pannuto wrote:
>> As SOCs become more popular, the desire to quickly define a simple,
>> but functional, bus type with only a few unique properties becomes
>> desirable. As they become more complicated, the ability to nest these
>> simp
it platform_bus_init(void)
> {
> int error;
> diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h
> index 5417944..5ec827c 100644
> --- a/include/linux/platform_device.h
> +++ b/include/linux/platform_device.h
> @@ -79,6 +79,9 @@ extern int platform_driver_probe(struct platform_driver
>
On Sat, Aug 7, 2010 at 12:35 AM, Grant Likely wrote:
> On Fri, Aug 6, 2010 at 5:46 PM, Greg KH wrote:
>> That would be nice, but take your "standard" PC today:
>> > ls /sys/devices/platform/
>> Fixed MDIO bus.0 i8042 pcspkr power serial8250 u
On Thu, Aug 5, 2010 at 7:25 PM, Patrick Pannuto wrote:
> On 08/05/2010 04:16 PM, Grant Likely wrote:
>> The relevant question before going down this path is, "Is the
>> omap/sh/other-soc behaviour something fundamentally different from the
>> platform bus? Or is it so
On Fri, Aug 6, 2010 at 5:46 PM, Greg KH wrote:
> On Fri, Aug 06, 2010 at 09:12:27AM -0600, Grant Likely wrote:
>> On Fri, Aug 6, 2010 at 8:27 AM, Greg KH wrote:
>> > On Thu, Aug 05, 2010 at 04:59:35PM -0600, Grant Likely wrote:
>> >> (On that point Greg, what is
On Fri, Aug 6, 2010 at 8:27 AM, Greg KH wrote:
> On Thu, Aug 05, 2010 at 04:59:35PM -0600, Grant Likely wrote:
>> (On that point Greg, what is the reason for even having the
>> /sys/devices/platform/ parent? Why not just let the platform devices
>> sit at the root of the de
On Thu, Aug 5, 2010 at 9:57 AM, Kevin Hilman
wrote:
> Patrick Pannuto writes:
>
>> On 08/04/2010 05:16 PM, Kevin Hilman wrote:
>>> Patrick Pannuto writes:
>>>
Inspiration for this comes from:
http://www.mail-archive.com/linux-o...@vger.kernel.org/msg31161.html
>>>
>>> Also, later in th
On Tue, Aug 3, 2010 at 5:56 PM, Greg KH wrote:
> On Tue, Aug 03, 2010 at 04:35:06PM -0700, Patrick Pannuto wrote:
>> @@ -539,12 +541,12 @@ int __init_or_module platform_driver_probe(struct
>> platform_driver *drv,
>> * if the probe was successful, and make sure any forced probes of
>>
ee? Devices of different types can often be siblings at the same
device layer. (note: not *always* true. PCI busses for instance
always expect to only host pci_devices and visa-versa, but for simple
platform-like busses it may be true).
Now, having gone on this whole long tirade, it looks like havi
2010/7/13 Uwe Kleine-König :
> Hi
>
> On Mon, Jul 12, 2010 at 01:50:47PM -0600, Grant Likely wrote:
>> On Mon, Jul 12, 2010 at 1:34 PM, Linus Torvalds
>> wrote:
>> > On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre wrote:
>> >> I think Uwe could provid
On Mon, Jul 12, 2010 at 1:34 PM, Linus Torvalds
wrote:
> On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre wrote:
>> I think Uwe could provide his script and add it to the kernel tree.
>> Then all architectures could benefit from it. Having the defconfig
>> files contain only those options which a
73 matches
Mail list logo
