* Re: [PATCH v2 5/7] ARM: of: introduce common routine for DMA configuration
From: Arnd Bergmann @ 2014-02-28 15:31 UTC (permalink / raw)
To: Santosh Shilimkar
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
magnus.damm-Re5JQEeQqe8AvxtiuMwx3w,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
grant.likely-QSEj5FYQhm4dnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, Grygorii Strashko, Russell King,
Olof Johansson
In-Reply-To: <5310A5F1.9070901-l0cyMroinI0@public.gmane.org>
On Friday 28 February 2014 10:06:25 Santosh Shilimkar wrote:
> I made that LPAE specific assuming the 32 machines anyway are
> happy with default as they are today. We can keep CONFIG_ARM
> and handle the special case in machine platform notifier.
I think all other machines that support LPAE can also run with
LPAE disabled and still use coherent DMA, they may just not
support all the available RAM.
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 v2 2/3] arm64: Extend the PCI I/O space to 16MB
From: Catalin Marinas @ 2014-02-28 15:27 UTC (permalink / raw)
To: Liviu Dudau
Cc: linux-pci, Bjorn Helgaas, Will Deacon, linaro-kernel, LKML,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, LAKML
In-Reply-To: <1393506599-11561-3-git-send-email-Liviu.Dudau-5wv7dgnIgG8@public.gmane.org>
On Thu, Feb 27, 2014 at 01:09:58PM +0000, Liviu Dudau wrote:
> From: Catalin Marinas <catalin.marinas-5wv7dgnIgG8@public.gmane.org>
>
> The patch moves the PCI I/O space (currently at 64K) before the
> earlyprintk mapping and extends it to 16MB.
>
> Signed-off-by: Catalin Marinas <catalin.marinas-5wv7dgnIgG8@public.gmane.org>
I'll push this into mainline for 3.15, no need to carry it.
--
Catalin
--
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] dma: of: Move the functions under CONFIG_OF_DMA instead of CONFIG_OF
From: Santosh Shilimkar @ 2014-02-28 15:25 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Grant Likely,
Rob Herring
In-Reply-To: <5164707.sdmWv7EuCX@wuerfel>
On Friday 28 February 2014 10:21 AM, Arnd Bergmann wrote:
> On Friday 28 February 2014 10:03:10 Santosh Shilimkar wrote:
>>> As of 5fa422c922c25 "dmaengine: move drivers/of/dma.c -> drivers/dma/of-dma.c"
>>>
>>> which seems to solve the problem already.
>>>
>>>> I am not sure but we added couple of functions for dma-ranges
>>>> and dma-coherent which gets called from generic code.
>>>
>>> These functions have nothing to do with the dmaengine code though,
>>> they should be in a different file.
>>>
>> Any suggestion on different file ?
>
> drivers/of/platform.c would be my first choice. Possibly a new
> drivers/of/dma-mapping.c.
>
'drivers/of/platform.c' sounds good.
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 v2 4/7] dma: of: introduce of_dma_is_coherent() helper
From: Arnd Bergmann @ 2014-02-28 15:24 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Russell King, Linus Walleij, Magnus Damm, Olof Johansson,
Rob Herring, Santosh Shilimkar, Grant Likely
In-Reply-To: <CAL_JsqL6-hoD4F7+adPhsOJXeM5f+wpEuBWg_6AWqj3k2v0NEw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Friday 28 February 2014 09:14:19 Rob Herring wrote:
>
> I know Will D was not a fan of this property. Primarily I believe
> because you may need to describe more than just a boolean in more
> complex bus topologies.
I can't think of any example where it's not per-device. Do you
think we can end up with a device that has multiple bus master
ports, only some of which are coherent, or is there a different
concern?
> Effectively, highbank is always coherent. It was only PCI that is
> non-coherent, but I can safely say PCI will never be enabled at this
> point. There are no designs with PCI beyond 1 or 2 validation boards
> (total boards, not designs), and getting PCI to work was quite hacky
> due to only a 1MB window. The other masters are programmable, but only
> the coherent path is used as the non-coherent path actually has some
> issues. I had expected the opposite believing the ACP port would
> actually have issues which is also why I made it configurable.
Ok, I see. I still expect that we will see systems that are only
partially coherent in the future, but it's good to know we don't really
have to deal with backwards-compatibility as long as we can just
hardcode highbank to be always coherent.
I'm especially thankful we don't have to deal with the PCI implementation.
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] dma: of: Move the functions under CONFIG_OF_DMA instead of CONFIG_OF
From: Arnd Bergmann @ 2014-02-28 15:21 UTC (permalink / raw)
To: Santosh Shilimkar
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Grant Likely,
Rob Herring
In-Reply-To: <5310A52E.90908-l0cyMroinI0@public.gmane.org>
On Friday 28 February 2014 10:03:10 Santosh Shilimkar wrote:
> > As of 5fa422c922c25 "dmaengine: move drivers/of/dma.c -> drivers/dma/of-dma.c"
> >
> > which seems to solve the problem already.
> >
> >> I am not sure but we added couple of functions for dma-ranges
> >> and dma-coherent which gets called from generic code.
> >
> > These functions have nothing to do with the dmaengine code though,
> > they should be in a different file.
> >
> Any suggestion on different file ?
drivers/of/platform.c would be my first choice. Possibly a new
drivers/of/dma-mapping.c.
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 v2 4/7] dma: of: introduce of_dma_is_coherent() helper
From: Santosh Shilimkar @ 2014-02-28 15:17 UTC (permalink / raw)
To: Rob Herring, Arnd Bergmann
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Magnus Damm,
Linus Walleij, Grant Likely, Rob Herring, Russell King,
Olof Johansson
In-Reply-To: <CAL_JsqL6-hoD4F7+adPhsOJXeM5f+wpEuBWg_6AWqj3k2v0NEw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Friday 28 February 2014 10:14 AM, Rob Herring wrote:
> On Fri, Feb 28, 2014 at 3:39 AM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
>> On Thursday 27 February 2014 16:17:49 Santosh Shilimkar wrote:
>>> +
>>> +/**
>>> + * of_dma_is_coherent - Check if device is coherent
>>> + * @np: device node
>>> + *
>>> + * It returns true if "dma-coherent" property was found
>>> + * for this device in DT.
>>> + */
>>> +bool of_dma_is_coherent(struct device_node *np)
>>> +{
>>> + struct device_node *node = np;
>>> +
>>> + while (node) {
>>> + if (of_property_read_bool(node, "dma-coherent")) {
>>> + of_node_put(node);
>>> + return true;
>>> + }
>>> + node = of_get_next_parent(node);
>>> + }
>>> + return false;
>>> +}
>>> +EXPORT_SYMBOL_GPL(of_dma_is_coherent);
>>>
>>
>> This won't work on architectures that are always coherent and
>> did not need 'dma-coherent' properties before, such as IBM
>> Power servers.
>>
>> That said, I think the property makes sense, and we already have
>> platforms using it (highbank is the one I'm aware of).
>>
>> We probably need ways to override this function in both ways:
>> "always coherent" (powerpc, x86), and "never coherent" (keystone
>> without LPAE) from platform code, and it would be nice to put
>> either option into DT in a global location as well. We may have
>> to go through a few iterations of this patch to get the best
>> algorithm, but I think the interface is good at least.
>
> I know Will D was not a fan of this property. Primarily I believe
> because you may need to describe more than just a boolean in more
> complex bus topologies.
>
> Effectively, highbank is always coherent. It was only PCI that is
> non-coherent, but I can safely say PCI will never be enabled at this
> point. There are no designs with PCI beyond 1 or 2 validation boards
> (total boards, not designs), and getting PCI to work was quite hacky
> due to only a 1MB window. The other masters are programmable, but only
> the coherent path is used as the non-coherent path actually has some
> issues. I had expected the opposite believing the ACP port would
> actually have issues which is also why I made it configurable.
>
I also like it to be configurable per device since you can handle
the broken masters if any. On Keystone we have one of the master
broken(non-PCI) and this helps to take care of that case.
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 v2 4/7] dma: of: introduce of_dma_is_coherent() helper
From: Rob Herring @ 2014-02-28 15:14 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Santosh Shilimkar,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Magnus Damm,
Linus Walleij, Grant Likely, Rob Herring, Russell King,
Olof Johansson
In-Reply-To: <10040083.PbPEQQPCjl@wuerfel>
On Fri, Feb 28, 2014 at 3:39 AM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> On Thursday 27 February 2014 16:17:49 Santosh Shilimkar wrote:
>> +
>> +/**
>> + * of_dma_is_coherent - Check if device is coherent
>> + * @np: device node
>> + *
>> + * It returns true if "dma-coherent" property was found
>> + * for this device in DT.
>> + */
>> +bool of_dma_is_coherent(struct device_node *np)
>> +{
>> + struct device_node *node = np;
>> +
>> + while (node) {
>> + if (of_property_read_bool(node, "dma-coherent")) {
>> + of_node_put(node);
>> + return true;
>> + }
>> + node = of_get_next_parent(node);
>> + }
>> + return false;
>> +}
>> +EXPORT_SYMBOL_GPL(of_dma_is_coherent);
>>
>
> This won't work on architectures that are always coherent and
> did not need 'dma-coherent' properties before, such as IBM
> Power servers.
>
> That said, I think the property makes sense, and we already have
> platforms using it (highbank is the one I'm aware of).
>
> We probably need ways to override this function in both ways:
> "always coherent" (powerpc, x86), and "never coherent" (keystone
> without LPAE) from platform code, and it would be nice to put
> either option into DT in a global location as well. We may have
> to go through a few iterations of this patch to get the best
> algorithm, but I think the interface is good at least.
I know Will D was not a fan of this property. Primarily I believe
because you may need to describe more than just a boolean in more
complex bus topologies.
Effectively, highbank is always coherent. It was only PCI that is
non-coherent, but I can safely say PCI will never be enabled at this
point. There are no designs with PCI beyond 1 or 2 validation boards
(total boards, not designs), and getting PCI to work was quite hacky
due to only a 1MB window. The other masters are programmable, but only
the coherent path is used as the non-coherent path actually has some
issues. I had expected the opposite believing the ACP port would
actually have issues which is also why I made it configurable.
Rob
--
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 1/2] mmc: omap_hsmmc: Add support for quirky omap3 hsmmc controller
From: Nishanth Menon @ 2014-02-28 15:09 UTC (permalink / raw)
To: Tony Lindgren, Chris Ball
Cc: devicetree, Balaji T K, linux-doc, linux-mmc, linux-kernel,
Felipe Balbi, linux-omap, linux-arm-kernel
In-Reply-To: <20140214163102.GA21592@atomide.com>
On 02/14/2014 10:31 AM, Tony Lindgren wrote:
> * Nishanth Menon <nm@ti.com> [140213 21:48]:
>> When device is booted using devicetree, platforms impacted by Erratum
>> 2.1.1.128 is not detected easily in the mmc driver. This erratum
>> indicates that the module cannot do multi-block transfers. Platforms
>> such as LDP which use OMAP3 ES revision prior to ES3.0 are impacted by
>> this.
>>
>> Provide a new compatible property "ti,omap3-pre-es3-hsmmc" to allow
>> driver to determine if driver needs to implement quirks associated
>> with the specific module version (primarily because the IP revision
>> information is not sufficient for the same).
>>
>> Signed-off-by: Nishanth Menon <nm@ti.com>
>
> Looks good to me, would be good to get this into the -rc cycle
> as LDP is one of the automated boot testing boards for us.
>
> If you guys want me to pick up both of the patches let me know,
> otherwise feel free to add my ack.
>
Chris,
would you be picking up the series that fixes LDP dt boot behavior or
should Tony pick it up?
https://patchwork.kernel.org/patch/3650061/
https://patchwork.kernel.org/patch/3650031/
--
Regards,
Nishanth Menon
^ permalink raw reply
* Re: [PATCH v2 5/7] ARM: of: introduce common routine for DMA configuration
From: Santosh Shilimkar @ 2014-02-28 15:06 UTC (permalink / raw)
To: Arnd Bergmann
Cc: devicetree, Grygorii Strashko, Russell King, linus.walleij,
magnus.damm, Olof Johansson, robh+dt, grant.likely,
linux-arm-kernel
In-Reply-To: <9618080.kpE3Kl6X8p@wuerfel>
On Friday 28 February 2014 05:00 AM, Arnd Bergmann wrote:
>> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
>> > index 404d1da..97d5533 100644
>> > --- a/drivers/of/platform.c
>> > +++ b/drivers/of/platform.c
>> > @@ -213,10 +213,13 @@ static struct platform_device *of_platform_device_create_pdata(
>> >
>> > #if defined(CONFIG_MICROBLAZE)
>> > dev->archdata.dma_mask = 0xffffffffUL;
>> > -#endif
>> > +#elif defined(CONFIG_ARM_LPAE)
>> > + arm_dt_dma_configure(&dev->dev);
>> > +#else
>> > dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
>> > if (!dev->dev.dma_mask)
>> > dev->dev.dma_mask = &dev->dev.coherent_dma_mask;
>> > +#endif
> The dependency on CONFIG_ARM_LPAE is not correct the general case,
> that would be a special case on keystone. I'd suggest using
> CONFIG_ARM here, and finding a different way to return false
> for dma_is_coherent() on keystone with LPAE disabled.
>
I made that LPAE specific assuming the 32 machines anyway are
happy with default as they are today. We can keep CONFIG_ARM
and handle the special case in machine platform notifier.
Regards,
Santosh
^ permalink raw reply
* Re: [PATCH] dma: of: Move the functions under CONFIG_OF_DMA instead of CONFIG_OF
From: Santosh Shilimkar @ 2014-02-28 15:03 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Grant Likely, devicetree@vger.kernel.org, Rob Herring,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <5615884.O4eVkOuQqe@wuerfel>
On Friday 28 February 2014 09:47 AM, Arnd Bergmann wrote:
> On Friday 28 February 2014 09:24:27 Santosh Shilimkar wrote:
>> So for ARM 'allnoconfig' build we have CONFIG_OF enabled but
>> CONFIG_DMA_OF disabled. With that the of-dma.c gets compiled
>> out leaving the functions from of-dma.h undefined. I noticed
>> this while adding couple of exports in of_dma.h
>
> Looking at current linux-next, I find
>
> Kconfig:
>
> menuconfig DMADEVICES
> bool "DMA Engine support"
> ...
> if DMADEVICES
>
> config DMA_OF
> def_bool y
> depends on OF
>
> endif
>
> This means that DMA_OF is disabled in 'allnoconfig' since DMADEVICES
> is also disabled, as you say. The Makefile looks like
>
> obj-$(CONFIG_DMA_OF) += of-dma.o
>
> As of 5fa422c922c25 "dmaengine: move drivers/of/dma.c -> drivers/dma/of-dma.c"
>
> which seems to solve the problem already.
>
>> I am not sure but we added couple of functions for dma-ranges
>> and dma-coherent which gets called from generic code.
>
> These functions have nothing to do with the dmaengine code though,
> they should be in a different file.
>
Any suggestion on different file ?
^ permalink raw reply
* Re: [PATCH v2 5/7] ARM: of: introduce common routine for DMA configuration
From: Rob Herring @ 2014-02-28 14:56 UTC (permalink / raw)
To: Santosh Shilimkar
Cc: Arnd Bergmann,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Magnus Damm,
Linus Walleij, Grant Likely, Rob Herring, Grygorii Strashko,
Russell King, Olof Johansson
In-Reply-To: <1393535872-20915-6-git-send-email-santosh.shilimkar-l0cyMroinI0@public.gmane.org>
On Thu, Feb 27, 2014 at 3:17 PM, Santosh Shilimkar
<santosh.shilimkar-l0cyMroinI0@public.gmane.org> wrote:
> From: Grygorii Strashko <grygorii.strashko-l0cyMroinI0@public.gmane.org>
>
> This patch introduces ARM specific function arm_dt_dma_configure()
> which intended to retrieve DMA configuration from DT and setup Platform
> device's DMA parameters.
>
> The DMA configuration in DT has to be specified using "dma-ranges"
> and "dam-coherent" properties if supported. The DMA configuration applied
s/dam/dma/
> by arm_dt_dma_configure() as following:
> - call of_get_dma_range() and get supported DMA range info
> (dma_addr, cpu_addr, dma_size);
> - if "not found" then fill dma_mask as DMA_BIT_MASK(32)
> (this is default behaviour);
> - if "failed" then clean up dma_mask (DMA not supported)
> - if ok then update devices DMA configuration:
> set dma_mask to (dma_addr + dma_size - 1)
> set dma_pfn_offset to PFN_DOWN(cpu_addr - dma_addr)
>
> Cc: Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
> Cc: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
> Cc: Olof Johansson <olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org>
> Cc: Grant Likely <grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Signed-off-by: Grygorii Strashko <grygorii.strashko-l0cyMroinI0@public.gmane.org>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar-l0cyMroinI0@public.gmane.org>
> ---
> arch/arm/include/asm/prom.h | 3 +++
> arch/arm/kernel/devtree.c | 61 +++++++++++++++++++++++++++++++++++++++++++
> drivers/of/platform.c | 5 +++-
> include/linux/of.h | 2 +-
> 4 files changed, 69 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/include/asm/prom.h b/arch/arm/include/asm/prom.h
> index b681575..1acb732 100644
> --- a/arch/arm/include/asm/prom.h
> +++ b/arch/arm/include/asm/prom.h
> @@ -11,11 +11,13 @@
> #ifndef __ASMARM_PROM_H
> #define __ASMARM_PROM_H
>
> +struct device;
> #ifdef CONFIG_OF
>
> extern const struct machine_desc *setup_machine_fdt(unsigned int dt_phys);
> extern void arm_dt_memblock_reserve(void);
> extern void __init arm_dt_init_cpu_maps(void);
> +extern void arm_dt_dma_configure(struct device *dev);
>
> #else /* CONFIG_OF */
>
> @@ -26,6 +28,7 @@ static inline const struct machine_desc *setup_machine_fdt(unsigned int dt_phys)
>
> static inline void arm_dt_memblock_reserve(void) { }
> static inline void arm_dt_init_cpu_maps(void) { }
> +static inline void arm_dt_dma_configure(struct device *dev) { }
>
> #endif /* CONFIG_OF */
> #endif /* ASMARM_PROM_H */
> diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
> index f751714..926b5dd 100644
> --- a/arch/arm/kernel/devtree.c
> +++ b/arch/arm/kernel/devtree.c
> @@ -18,6 +18,9 @@
> #include <linux/of_fdt.h>
> #include <linux/of_irq.h>
> #include <linux/of_platform.h>
> +#include <linux/of_dma.h>
> +#include <linux/dma-mapping.h>
> +#include <linux/slab.h>
>
> #include <asm/cputype.h>
> #include <asm/setup.h>
> @@ -235,3 +238,61 @@ const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
>
> return mdesc;
> }
> +
> +void arm_dt_dma_configure(struct device *dev)
The implementation may be ARM specific, but the need for the function
should not be.
> +{
> + dma_addr_t dma_addr;
> + phys_addr_t paddr, size;
> + dma_addr_t dma_mask;
> + int ret;
> +
> + /*
> + * if dma-ranges property doesn't exist - use 32 bits DMA mask
> + * by default and don't set skip archdata.dma_pfn_offset
> + */
> + ret = of_dma_get_range(dev->of_node, &dma_addr, &paddr, &size);
> + if (ret == -ENODEV) {
> + dev->coherent_dma_mask = DMA_BIT_MASK(32);
> + if (!dev->dma_mask)
> + dev->dma_mask = &dev->coherent_dma_mask;
> + return;
> + }
> +
> + /* if failed - disable DMA for device */
> + if (ret < 0) {
> + dev_err(dev, "failed to configure DMA\n");
> + return;
> + }
> +
> + /* DMA ranges found. Calculate and set dma_pfn_offset */
> + dev->archdata.dma_pfn_offset = PFN_DOWN(paddr - dma_addr);
> +
> + /* Configure DMA mask */
> + dev->dma_mask = kmalloc(sizeof(*dev->dma_mask), GFP_KERNEL);
I don't believe that any ARM platform needs dma_mask to be different
from coherent_dma_mask. I traced the history to when 2 masks were
defined and this was my conclusion. Russell has also recently stated
the same:
https://lkml.org/lkml/2013/8/9/205
> + if (!dev->dma_mask)
> + return;
> +
> + dma_mask = dma_addr + size - 1;
> +
> + ret = arm_dma_set_mask(dev, dma_mask);
> + if (ret < 0) {
> + dev_err(dev, "failed to set DMA mask %#08x\n", dma_mask);
> + kfree(dev->dma_mask);
> + dev->dma_mask = NULL;
> + return;
> + }
> +
> + dev_dbg(dev, "dma_pfn_offset(%#08lx) dma_mask(%#016llx)\n",
> + dev->archdata.dma_pfn_offset, *dev->dma_mask);
> +
> + if (of_dma_is_coherent(dev->of_node)) {
> + set_dma_ops(dev, &arm_coherent_dma_ops);
All but this line could be in a common function. So make an arm
version of the function that calls the common function and then does
this. Or perhaps a per arch "get dma ops" function is all that is
needed.
> + dev_dbg(dev, "device is dma coherent\n");
> + }
> +
> + ret = dma_set_coherent_mask(dev, dma_mask);
> + if (ret < 0) {
> + dev_err(dev, "failed to set coherent DMA mask %#08x\n",
> + dma_mask);
> + }
> +}
> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> index 404d1da..97d5533 100644
> --- a/drivers/of/platform.c
> +++ b/drivers/of/platform.c
> @@ -213,10 +213,13 @@ static struct platform_device *of_platform_device_create_pdata(
>
> #if defined(CONFIG_MICROBLAZE)
> dev->archdata.dma_mask = 0xffffffffUL;
This should be moved into a microblaze specific version of the function.
> -#endif
> +#elif defined(CONFIG_ARM_LPAE)
> + arm_dt_dma_configure(&dev->dev);
> +#else
> dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> if (!dev->dev.dma_mask)
> dev->dev.dma_mask = &dev->dev.coherent_dma_mask;
> +#endif
> dev->dev.bus = &platform_bus_type;
> dev->dev.platform_data = platform_data;
>
> diff --git a/include/linux/of.h b/include/linux/of.h
> index 70c64ba..a321058 100644
> --- a/include/linux/of.h
> +++ b/include/linux/of.h
> @@ -136,7 +136,7 @@ static inline unsigned long of_read_ulong(const __be32 *cell, int size)
> return of_read_number(cell, size);
> }
>
> -#if defined(CONFIG_SPARC)
> +#if defined(CONFIG_SPARC) || defined(CONFIG_ARM_LPAE)
> #include <asm/prom.h>
No. The idea here is to get rid of including prom.h.
Rob
--
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] dma: of: Move the functions under CONFIG_OF_DMA instead of CONFIG_OF
From: Arnd Bergmann @ 2014-02-28 14:47 UTC (permalink / raw)
To: Santosh Shilimkar
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Grant Likely,
Rob Herring
In-Reply-To: <53109C1B.2030606-l0cyMroinI0@public.gmane.org>
On Friday 28 February 2014 09:24:27 Santosh Shilimkar wrote:
> So for ARM 'allnoconfig' build we have CONFIG_OF enabled but
> CONFIG_DMA_OF disabled. With that the of-dma.c gets compiled
> out leaving the functions from of-dma.h undefined. I noticed
> this while adding couple of exports in of_dma.h
Looking at current linux-next, I find
Kconfig:
menuconfig DMADEVICES
bool "DMA Engine support"
...
if DMADEVICES
config DMA_OF
def_bool y
depends on OF
endif
This means that DMA_OF is disabled in 'allnoconfig' since DMADEVICES
is also disabled, as you say. The Makefile looks like
obj-$(CONFIG_DMA_OF) += of-dma.o
As of 5fa422c922c25 "dmaengine: move drivers/of/dma.c -> drivers/dma/of-dma.c"
which seems to solve the problem already.
> I am not sure but we added couple of functions for dma-ranges
> and dma-coherent which gets called from generic code.
These functions have nothing to do with the dmaengine code though,
they should be in a different file.
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 4/5] DMA: sun6i: Add driver for the Allwinner A31 DMA controller
From: Maxime Ripard @ 2014-02-28 14:27 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Emilio Lopez, Dan Williams, Vinod Koul, Mike Turquette,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
dmaengine-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <1393594391.28803.79.camel-XvqNBM/wLWRrdx17CPfAsdBPR1lH4CV8@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2726 bytes --]
On Fri, Feb 28, 2014 at 03:33:11PM +0200, Andy Shevchenko wrote:
> On Fri, 2014-02-28 at 11:36 +0100, Maxime Ripard wrote:
> > Hi Andy,
> >
> > On Tue, Feb 25, 2014 at 01:28:15PM +0200, Andy Shevchenko wrote:
> > > > +static irqreturn_t sun6i_dma_interrupt(int irq, void *dev_id)
> > > > +{
> > > > + struct sun6i_dma_dev *sdev = (struct sun6i_dma_dev *)dev_id;
> > > > + struct sun6i_vchan *vchan;
> > > > + struct sun6i_pchan *pchan;
> > > > + int i, j, ret = 0;
> > > > + u32 status;
> > > > +
> > > > + for (i = 0; i < 2; i++) {
> > > > + status = readl(sdev->base + DMA_IRQ_STAT(i));
> > > > + if (!status) {
> > > > + ret |= IRQ_NONE;
> > >
> > > Maybe move this to definition block.
> > >
> > > > + continue;
> > > > + }
> > > > +
> > > > + dev_dbg(sdev->slave.dev, "DMA irq status %s: 0x%x\n",
> > > > + i ? "high" : "low", status);
> > > > +
> > > > + writel(status, sdev->base + DMA_IRQ_STAT(i));
> > > > +
> > > > + for (j = 0; (j < 8) && status; j++) {
> > > > + if (status & DMA_IRQ_QUEUE) {
> > > > + pchan = sdev->pchans + j;
> > > > + vchan = pchan->vchan;
> > > > +
> > > > + if (vchan) {
> > > > + unsigned long flags;
> > > > +
> > > > + spin_lock_irqsave(&vchan->vc.lock,
> > > > + flags);
> > > > + vchan_cookie_complete(&pchan->desc->vd);
> > > > + pchan->done = pchan->desc;
> > > > + spin_unlock_irqrestore(&vchan->vc.lock,
> > > > + flags);
> > > > + }
> > > > + }
> > > > +
> > > > + status = status >> 4;
> > > > + }
> > > > +
> > > > + ret |= IRQ_HANDLED;
> > >
> > > In case one is handled, another is not, what you have to do?
> >
> > The interrupt status is split across two registers. In the case where
> > one of the two register reports an interrupt, we still have to handle
> > our interrupt, we actually did, so we have to return IRQ_HANDLED.
>
> You removed the code below this assignment, but if I remember correctly
> you check for exact value there.
>
> In case of one is not handled and the other is handled you will have ret
> = IRQ_HANDLED | IRQ_NONE. Thus, your following code will not be
> executed. Is it by design?
The code that got removed was
if (ret == IRQ_HANDLED)
tasklet_schedule()
return ret;
The only thing that wouldn't have been executed if we had no
interrupts to report was the tasklet_schedule.
This has lightly changed though in the v2, thanks to your comments.
I don't have the | anymore, and call tasklet_schedule directly in the
loop.
I'll send the v2 in a short while.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] dma: of: Move the functions under CONFIG_OF_DMA instead of CONFIG_OF
From: Santosh Shilimkar @ 2014-02-28 14:24 UTC (permalink / raw)
To: Arnd Bergmann, linux-arm-kernel@lists.infradead.org
Cc: Grant Likely, devicetree@vger.kernel.org, Rob Herring
In-Reply-To: <6287295.Q1WPJPjeZV@wuerfel>
On Friday 28 February 2014 04:23 AM, Arnd Bergmann wrote:
> On Thursday 27 February 2014 19:27:03 Santosh Shilimkar wrote:
>>
>> The of-dma.c is compiled out with !CONFIG_DMA_OF but the functions in
>> the header are kept under CONFIG_OF. Move them under CONFIG_OF_DMA
>> to avoid build errors with CONFIG_OFF && !CONFIG_DMA_OF
>>
>> Cc: Grant Likely <grant.likely@linaro.org>
>> Cc: Rob Herring <robh+dt@kernel.org>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>
> Sorry, but what is the problem you are seeing with this?
>
> CONFIG_DMA_OF is defined as 'OF && DMAENGINE', and this code
> should only be called from drivers that depend on DMAENGINE.
>
> I'm not saying your patch is wrong, but you shouldn't need it
> unless you do something very odd.
>
So for ARM 'allnoconfig' build we have CONFIG_OF enabled but
CONFIG_DMA_OF disabled. With that the of-dma.c gets compiled
out leaving the functions from of-dma.h undefined. I noticed
this while adding couple of exports in of_dma.h
I am not sure but we added couple of functions for dma-ranges
and dma-coherent which gets called from generic code.
In any case, the patch makes sense since the header and Makefile
are not consistent.
Regards,
Santosh
^ permalink raw reply
* Re: [PATCH v2 4/7] dma: of: introduce of_dma_is_coherent() helper
From: Santosh Shilimkar @ 2014-02-28 14:17 UTC (permalink / raw)
To: Arnd Bergmann
Cc: devicetree@vger.kernel.org, Russell King,
linus.walleij@linaro.org, magnus.damm@gmail.com, Olof Johansson,
robh+dt@kernel.org, grant.likely@linaro.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <10040083.PbPEQQPCjl@wuerfel>
On Friday 28 February 2014 04:39 AM, Arnd Bergmann wrote:
> On Thursday 27 February 2014 16:17:49 Santosh Shilimkar wrote:
>> +
>> +/**
>> + * of_dma_is_coherent - Check if device is coherent
>> + * @np: device node
>> + *
>> + * It returns true if "dma-coherent" property was found
>> + * for this device in DT.
>> + */
>> +bool of_dma_is_coherent(struct device_node *np)
>> +{
>> + struct device_node *node = np;
>> +
>> + while (node) {
>> + if (of_property_read_bool(node, "dma-coherent")) {
>> + of_node_put(node);
>> + return true;
>> + }
>> + node = of_get_next_parent(node);
>> + }
>> + return false;
>> +}
>> +EXPORT_SYMBOL_GPL(of_dma_is_coherent);
>>
>
> This won't work on architectures that are always coherent and
> did not need 'dma-coherent' properties before, such as IBM
> Power servers.
>
> That said, I think the property makes sense, and we already have
> platforms using it (highbank is the one I'm aware of).
>
> We probably need ways to override this function in both ways:
> "always coherent" (powerpc, x86), and "never coherent" (keystone
> without LPAE) from platform code, and it would be nice to put
> either option into DT in a global location as well. We may have
> to go through a few iterations of this patch to get the best
> algorithm, but I think the interface is good at least.
>
Probably we should discuss bit more next week at connect. The
current 'dma-coherent' is a per device property. For arch's
which are always coherent, the per device property doesn't make
sense.
BTW, the current users of this API is only ARM32 bit port
and if this satisfies the ARM platforms, we should get
this in kernel and then address other cases on need
basis.
Regards,
Santosh
^ permalink raw reply
* Re: [PATCH 0/9] Doc/DT: DT bindings for various display components
From: Sebastian Hesselbarth @ 2014-02-28 13:56 UTC (permalink / raw)
To: Philipp Zabel
Cc: Tomi Valkeinen, linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Laurent Pinchart, Russell King - ARM Linux, Sascha Hauer,
Rob Clark, Inki Dae, Andrzej Hajda, Tomasz Figa, Thierry Reding
In-Reply-To: <1393595264.3802.39.camel-+qGW7pzALmz7o/J7KWpOmN53zsg1cpMQ@public.gmane.org>
On 02/28/14 14:47, Philipp Zabel wrote:
> Am Freitag, den 28.02.2014, 13:57 +0100 schrieb Sebastian Hesselbarth:
>> On 02/28/14 13:20, Tomi Valkeinen wrote:
>>> This series is a re-send of
>>> http://article.gmane.org/gmane.linux.drivers.devicetree/61739
>>>
>> ...
>>> Shortly about the display components in the series, in the order of probable
>>> public interest:
>>>
>>> * Analog TV, DVI and HDMI Connectors represent a respective connector on the
>>> board. They don't do much, but they do mark the end of the video pipeline (from
>>> the board's pov), and they should also in the future offer ways to handle
>>> things like the +5V pin on DVI and HDMI connector and HPD pin.
>>>
>>> * MIPI DPI panel and MIPI DSI CM panels represent bindings for simple panels
>>> using the respective video bus.
>>>
>>> * Sony acx565akm is an SPI controlled panel using flatlink video bus.
>>>
>>> * TFP410 is a DPI to DVI encoder.
>>>
>>> * TPD12S015 is a HDMI companion chip, used on OMAP boards.
>>
>> Tomi,
>>
>> Out of curiosity, will there be DT nodes for pull-up resistors soon,
>> too? ;)
>>
>> Honestly, TPD12S015 is a level shifter, there is nothing in it that
>> would justify a DT node nor a driver.
>>
>> Above you already note, that connector nodes should offer HPD in the
>> future, but I guess the binding should represent that now already.
>> I will be a DT stub anyway, the corresponding video sink driver will
>> have to look it up.
>>
>> Looking through the bindings for DVI and HDMI, I guess HPD gpio is
>> better kept in those nodes. From the relevant (DT) properties DVI and
>> HDMI connectors are in no way different.
>
> I like the idea of adding actual connector nodes to the board device
> trees. A TV encoder driver for example could this way detect from the
> device tree whether it is connected to a VGA, Composite, or S-Video
> connector (or maybe to both Composite and S-Video connectors at the same
> time).
I agree that different connectors help providing a better
user-experienced view of board layout. But I doubt that besides the
differentiation (HDMI, DVI, VGA, SVideo, ...) and the endpoint there
should be anything more in that node.
Sebastian
--
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 v4 7/9] devicetree: bindings: Document PM8921/8058 keypads
From: Josh Cartwright @ 2014-02-28 13:55 UTC (permalink / raw)
To: Stephen Boyd
Cc: Dmitry Torokhov, linux-kernel, linux-arm-msm, linux-arm-kernel,
linux-input, devicetree
In-Reply-To: <1393552520-9068-8-git-send-email-sboyd@codeaurora.org>
On Thu, Feb 27, 2014 at 05:55:18PM -0800, Stephen Boyd wrote:
> Document the keypad device found on PM8921 and PM8058 PMICs.
[..]
> +++ b/Documentation/devicetree/bindings/input/qcom,pm8xxx-keypad.txt
> @@ -0,0 +1,72 @@
> +Qualcomm PM8xxx PMIC Keypad
> +
> +PROPERTIES
> +
> +- compatible:
> + Usage: required
> + Value type: <string>
> + Definition: must be one of:
> + "qcom,pm8058-keypad"
> + "qcom,pm8921-keypad"
> +- interrupts:
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: the first interrupt specifies the key sense interrupt
> + and the second interrupt specifies the key stuck interrupt.
> + The format of the specifier is defined by the binding
> + document describing the node's interrupt parent.
> +
> +- linux,keymap:
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: the linux keymap. More information can be found in
> + input/matrix-keymap.txt.
> +
> +- keypad,num-rows:
> + Usage: required
> + Value type: <u32>
> + Definition: number of rows in the keymap. More information can be found
> + in input/matrix-keymap.txt.
> +
> +- keypad,num-columns:
> + Usage: required
> + Value type: <u32>
> + Definition: number of columns in the keymap. More information can be
> + found in input/matrix-keymap.txt.
> +
> +- debounce:
> + Usage: optional
> + Value type: <u32>
> + Definition: time in microseconds that key must be pressed or release
> + for key sense interrupt to trigger.
> +
> +- scan-delay:
> + Usage: optional
> + Value type: <u32>
> + Definition: time in microseconds to pause between successive scans
> + of the matrix array.
> +
> +- row-hold:
> + Usage: optional
> + Value type: <u32>
> + Definition: time in nanoseconds to pause between scans of each row in
> + the matrix array.
- linux,wakeup?
- linux,no-auto-repeat?
> +
> +EXAMPLE
> +
> + keypad {
> + compatible = "qcom,pm8921-keypad";
> + interrupt-parent = <&pmicintc>;
> + interrupts = <74 1>, <75 1>;
> + linux,keymap = <
> + MATRIX_KEY(0, 0, KEY_VOLUMEUP)
> + MATRIX_KEY(0, 1, KEY_VOLUMEDOWN)
> + MATRIX_KEY(0, 2, KEY_CAMERA_FOCUS)
> + MATRIX_KEY(0, 3, KEY_CAMERA)
> + >;
> + keypad,num-rows = <1>;
> + keypad,num-columns = <5>;
> + debounce = <15>;
> + scan-delay = <32>;
> + row-hold = <91500>;
> + };
It odd to me that these newly created bindings don't have 'reg'
properties, even though the device clearly has a register region.
I suppose it makes sense from a "port over from platform data to DT"
perspective, as these drivers have just assumed the location of their
registers to be fixed; however I suspect things will need to be changed
if/when we hope to share these drivers with pm8841/pm8941 and beyond...
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* Re: [PATCH v0 12/15] ARM: STi: DT: STiH416: 416 DT Entry for clockgen B/C/D/E/F
From: Gabriel Fernandez @ 2014-02-28 13:53 UTC (permalink / raw)
To: Lee Jones
Cc: mturquette, robh+dt, pawel.moll, mark.rutland, ijc+devicetree,
galak, rob, linux, devicetree, linux-doc, linux-kernel,
linux-arm-kernel, Pankaj Dev
In-Reply-To: <20140227163643.GC24910@lee--X1>
[-- Attachment #1: Type: text/plain, Size: 3641 bytes --]
Hi Lee,
On 02/27/2014 05:36 PM, Lee Jones wrote:
>> Patch adds DT entries for clockgen B/C/D/E/F
>>
>> Signed-off-by: Pankaj Dev <pankaj.dev@st.com>
> You need to add your Signed-off-by too.
ok
>
>> ---
>> arch/arm/boot/dts/stih416-clock.dtsi | 170 +++++++++++++++++++++++++++++++++++
>> 1 file changed, 170 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/stih416-clock.dtsi b/arch/arm/boot/dts/stih416-clock.dtsi
>> index f63b0a1..6b2e387 100644
>> --- a/arch/arm/boot/dts/stih416-clock.dtsi
>> +++ b/arch/arm/boot/dts/stih416-clock.dtsi
>> @@ -503,5 +503,175 @@
>> /* Remaining outputs unused */
>> };
>> };
> This doesn't look right. Have you indented one tab too far?
ok i have reworked tabulation on this patch
>
>> + /*
>> + * Frequency synthesizers on the SASG2.
>> + *
>> + */
> Too many *'s
ok
>
> <snip>
>
>> + CLK_S_VCC_HD: CLK_S_VCC_HD {
>> + #clock-cells = <0>;
>> + compatible = "st,stih416-clkgenc-vcc-hd", "st,clkgen-mux";
>> + reg = <0xfe8308b8 4>; /* SYSCFG2558 */
> 0x4
ok
>
>> + /*
>> + * Add a dummy clock for the HDMI PHY for the VCC input mux
>> + */
>> + CLK_S_TMDS_FROMPHY: CLK_S_TMDS_FROMPHY {
>> + #clock-cells = <0>;
>> + compatible = "fixed-clock";
>> + clock-frequency = <0>;
> What happens when the clock frequency is 0?
Nothing, this poses no problem.
This input clock is not managed by the driver.
>> + };
>> +
>> + CLOCKGEN_C_VCC: CLOCKGEN_C_VCC {
>> + #clock-cells = <1>;
>> + compatible = "st,stih416-clkgenc", "st,clkgen-vcc";
>> + reg = <0xfe8308ac 12>; /* SYSCFG2555,2556,2557 */
> 0x12, or 0x0C, whichever is appropriate.
ok
>
>> + clocks = <&CLK_S_VCC_HD>, <&CLOCKGEN_C 1>,
>> + <&CLK_S_TMDS_FROMPHY>, <&CLOCKGEN_C 2>;
> One per line would probably be better, save confusing them for pairs.
ok
>
> <snip>
>
>> + /*
>> + * Frequency synthesizers on the MPE42
>> + */
> Alignment.
ok i transform into 1 line : /* Frequency synthesizers on the MPE42*/
>
> <snip>
>
>> + CLOCKGEN_F: CLOCKGEN_F {
>> + #clock-cells = <1>;
>> + compatible = "st,stih416-quadfs660-F", "st,quadfs";
>> + reg = <0xfd320878 0xF0>;
>> +
>> + clocks = <&CLK_SYSIN>;
>> + clock-output-names = "CLK_M_MAIN_VIDFS",
>> + "CLK_M_HVA_FS",
>> + "CLK_M_FVDP_VCPU",
>> + "CLK_M_FVDP_PROC_FS";
> Tabbing. Ensure you're using tabs (and not spaces) everywhere.
ok
>
> <snip>
>
>> + reg = <0xfd320910 4>; /* SYSCFG8580 */
> 0x...
>
> Do this for all of the below too.
ok
>
>
> <snip>
>
>> + clock-output-names =
>> + "CLK_M_PIX_MAIN_PIPE", "CLK_M_PIX_AUX_PIPE",
>> + "CLK_M_PIX_MAIN_CRU", "CLK_M_PIX_AUX_CRU",
>> + "CLK_M_XFER_BE_COMPO", "CLK_M_XFER_PIP_COMPO",
>> + "CLK_M_XFER_AUX_COMPO", "CLK_M_VSENS",
>> + "CLK_M_PIX_HDMIRX_0", "CLK_M_PIX_HDMIRX_1";
>> + };
>> };
>> };
ok
> Something strange going on with these.
>
[-- Attachment #2: Type: text/html, Size: 7211 bytes --]
^ permalink raw reply
* Re: [PATCH 0/9] Doc/DT: DT bindings for various display components
From: Sebastian Hesselbarth @ 2014-02-28 13:51 UTC (permalink / raw)
To: Tomi Valkeinen, linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Philipp Zabel, Laurent Pinchart, Russell King - ARM Linux,
Sascha Hauer, Rob Clark, Inki Dae, Andrzej Hajda, Tomasz Figa,
Thierry Reding
In-Reply-To: <53108B9C.5000006-l0cyMroinI0@public.gmane.org>
On 02/28/14 14:14, Tomi Valkeinen wrote:
> On 28/02/14 14:57, Sebastian Hesselbarth wrote:
>
>> Out of curiosity, will there be DT nodes for pull-up resistors soon,
>> too? ;)
>
> If they don't work automatically, yes, we need DT nodes and drivers for
> them.
>
>> Honestly, TPD12S015 is a level shifter, there is nothing in it that
>> would justify a DT node nor a driver.
>
> TPD requires a power. Who turns that on? It also has two GPIOs, LS_OE
> and CT_CP_HPD, which need to be controlled based on what the user wants
> and the state of the HPD line. Who controls those?
Strictly speaking TPD12S015 has _no_ GPIO but only buffers. It
translates one voltage to another. The controlling instance is
your "video card" that is really interested in the actual state
of HPD signal.
Also the same for power, TPD12S015 doesn't decide to be powered up
or down but the "video card" does. We have GPIO regulators that
deal with that situation already.
Consider the same board but replace TPD12S015 with another level-
shifter, you still want OMAP video driver work with that out-of-the-box,
don't you? Fact is, OMAP IP requires GPIOs to sense HPD status hence
that GPIO is a property of the corresponding OMAP node. How level-
translation happens is irrelevant here.
>> Above you already note, that connector nodes should offer HPD in the
>> future, but I guess the binding should represent that now already.
>
> I think it can be added when somebody uses it. I don't see why that
> would cause trouble later to those that don't use it.
Thinking about it again, HPD gpio shouldn't be a property of the
connector at all but again the controlling instance. The connector
cannot deal with the information provided by HPD nor can it determine
if anyone is listening to HPD events.
>> I will be a DT stub anyway, the corresponding video sink driver will
>> have to look it up.
>
> I'm not sure what you mean with that. Yes, it's not the most complex DT
> nodes out there.
>
>> Looking through the bindings for DVI and HDMI, I guess HPD gpio is
>> better kept in those nodes. From the relevant (DT) properties DVI and
>> HDMI connectors are in no way different.
>
> Well, I think the HPD gpio should be where it's most logical to have it.
Right, but this is usually the controlling instance and not the
consuming one. E.g. to detect presence of an MMC card by GPIO, you'd
put that into the MMC _controller_ not any card node.
> I mean, you could have a setup where you have the SoC HDMI encoder and
> and the HDMI connector, and the HPD pin goes directly to the HDMI
> encoder, which has HW support for it. In that case, the HDMI encoder
> node should contain the HPD, and the HDMI encoder should handle it.
I wonder, if in case of an dedicated HPD pin, you would ever expose that
in DT.
> Or, your HDMI encoder could not have any kind of support for HPD. In
> that case you could have the HDMI connector driver handle the hotplug
> event. You could of course make the HDMI encoder driver handle the HPD
> gpio, but I usually try to have the driver handle the hardware device in
> question.
Having a driver for a dumb connector seems to be a little exaggerated.
Consider your generic HDMI connector "driver" connected to dedicated HPD
case above. It is pretty useless then. OTOH video controllers with
dedicated HPD know very well they can control HPD themselves, video
controllers without dedicated HPD also know very well that they need
GPIO for it.
> In OMAP's case, we have the TPD chip between the HDMI encoder and the
> connector, and the logical place to handle HPD GPIO in that case is the
> TPD driver, as that's where the HPD is connected to and the TPD needs to
> be configured according to the state of the HPD.
Is it really the logical place to handle HPD? I'd have put it into the
HDMI encoder because it's the unit most interested in the state of HPD.
Please, don't get me wrong, I like all this to be baked into a binding -
just wondering if a level-shifter driver plus corresponding DT node
is too much detail in here.
Sebastian
--
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 5/5] ARM: dts: use real clocks for bcm21664
From: Alex Elder @ 2014-02-28 13:49 UTC (permalink / raw)
To: mturquette, bcm, mporter, devicetree
Cc: linux-doc, linux-arm-kernel, linux-kernel
In-Reply-To: <1393595371-3789-1-git-send-email-elder@linaro.org>
Replace the "fake" fixed-rate clocks used previously for the
bcm21664 family with "real" ones.
Signed-off-by: Alex Elder <elder@linaro.org>
---
arch/arm/boot/dts/bcm21664.dtsi | 190 ++++++++++++++++++++++++---------------
1 file changed, 118 insertions(+), 72 deletions(-)
diff --git a/arch/arm/boot/dts/bcm21664.dtsi b/arch/arm/boot/dts/bcm21664.dtsi
index 08a44d4..8b36682 100644
--- a/arch/arm/boot/dts/bcm21664.dtsi
+++ b/arch/arm/boot/dts/bcm21664.dtsi
@@ -14,6 +14,8 @@
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/interrupt-controller/irq.h>
+#include "dt-bindings/clock/bcm21664.h"
+
#include "skeleton.dtsi"
/ {
@@ -43,7 +45,7 @@
compatible = "brcm,bcm21664-dw-apb-uart", "snps,dw-apb-uart";
status = "disabled";
reg = <0x3e000000 0x118>;
- clocks = <&uartb_clk>;
+ clocks = <&slave_ccu BCM21664_SLAVE_CCU_UARTB>;
interrupts = <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>;
reg-shift = <2>;
reg-io-width = <4>;
@@ -53,7 +55,7 @@
compatible = "brcm,bcm21664-dw-apb-uart", "snps,dw-apb-uart";
status = "disabled";
reg = <0x3e001000 0x118>;
- clocks = <&uartb2_clk>;
+ clocks = <&slave_ccu BCM21664_SLAVE_CCU_UARTB2>;
interrupts = <GIC_SPI 66 IRQ_TYPE_LEVEL_HIGH>;
reg-shift = <2>;
reg-io-width = <4>;
@@ -63,7 +65,7 @@
compatible = "brcm,bcm21664-dw-apb-uart", "snps,dw-apb-uart";
status = "disabled";
reg = <0x3e002000 0x118>;
- clocks = <&uartb3_clk>;
+ clocks = <&slave_ccu BCM21664_SLAVE_CCU_UARTB3>;
interrupts = <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>;
reg-shift = <2>;
reg-io-width = <4>;
@@ -85,7 +87,7 @@
compatible = "brcm,kona-timer";
reg = <0x35006000 0x1c>;
interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&hub_timer_clk>;
+ clocks = <&aon_ccu BCM21664_AON_CCU_HUB_TIMER>;
};
gpio: gpio@35003000 {
@@ -106,7 +108,7 @@
compatible = "brcm,kona-sdhci";
reg = <0x3f180000 0x801c>;
interrupts = <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&sdio1_clk>;
+ clocks = <&master_ccu BCM21664_MASTER_CCU_SDIO1>;
status = "disabled";
};
@@ -114,7 +116,7 @@
compatible = "brcm,kona-sdhci";
reg = <0x3f190000 0x801c>;
interrupts = <GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&sdio2_clk>;
+ clocks = <&master_ccu BCM21664_MASTER_CCU_SDIO2>;
status = "disabled";
};
@@ -122,7 +124,7 @@
compatible = "brcm,kona-sdhci";
reg = <0x3f1a0000 0x801c>;
interrupts = <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&sdio3_clk>;
+ clocks = <&master_ccu BCM21664_MASTER_CCU_SDIO3>;
status = "disabled";
};
@@ -130,7 +132,7 @@
compatible = "brcm,kona-sdhci";
reg = <0x3f1b0000 0x801c>;
interrupts = <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&sdio4_clk>;
+ clocks = <&master_ccu BCM21664_MASTER_CCU_SDIO4>;
status = "disabled";
};
@@ -140,7 +142,7 @@
interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
- clocks = <&bsc1_clk>;
+ clocks = <&slave_ccu BCM21664_SLAVE_CCU_BSC1>;
status = "disabled";
};
@@ -150,7 +152,7 @@
interrupts = <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
- clocks = <&bsc2_clk>;
+ clocks = <&slave_ccu BCM21664_SLAVE_CCU_BSC2>;
status = "disabled";
};
@@ -160,7 +162,7 @@
interrupts = <GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
- clocks = <&bsc3_clk>;
+ clocks = <&slave_ccu BCM21664_SLAVE_CCU_BSC3>;
status = "disabled";
};
@@ -170,105 +172,149 @@
interrupts = <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
- clocks = <&bsc4_clk>;
+ clocks = <&slave_ccu BCM21664_SLAVE_CCU_BSC4>;
status = "disabled";
};
clocks {
- bsc1_clk: bsc1 {
- compatible = "fixed-clock";
- clock-frequency = <13000000>;
- #clock-cells = <0>;
- };
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
- bsc2_clk: bsc2 {
- compatible = "fixed-clock";
- clock-frequency = <13000000>;
+ /*
+ * Fixed clocks are defined before CCUs whose
+ * clocks may depend on them.
+ */
+
+ ref_32k_clk: ref_32k {
#clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <32768>;
};
- bsc3_clk: bsc3 {
- compatible = "fixed-clock";
- clock-frequency = <13000000>;
+ bbl_32k_clk: bbl_32k {
#clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <32768>;
};
- bsc4_clk: bsc4 {
+ ref_13m_clk: ref_13m {
+ #clock-cells = <0>;
compatible = "fixed-clock";
clock-frequency = <13000000>;
- #clock-cells = <0>;
};
- pmu_bsc_clk: pmu_bsc {
+ var_13m_clk: var_13m {
+ #clock-cells = <0>;
compatible = "fixed-clock";
clock-frequency = <13000000>;
- #clock-cells = <0>;
};
- hub_timer_clk: hub_timer {
- compatible = "fixed-clock";
- clock-frequency = <32768>;
+ dft_19_5m_clk: dft_19_5m {
#clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <19500000>;
};
- pwm_clk: pwm {
+ ref_crystal_clk: ref_crystal {
+ #clock-cells = <0>;
compatible = "fixed-clock";
clock-frequency = <26000000>;
- #clock-cells = <0>;
};
- sdio1_clk: sdio1 {
- compatible = "fixed-clock";
- clock-frequency = <48000000>;
+ ref_52m_clk: ref_52m {
#clock-cells = <0>;
- };
-
- sdio2_clk: sdio2 {
compatible = "fixed-clock";
- clock-frequency = <48000000>;
- #clock-cells = <0>;
+ clock-frequency = <52000000>;
};
- sdio3_clk: sdio3 {
- compatible = "fixed-clock";
- clock-frequency = <48000000>;
+ var_52m_clk: var_52m {
#clock-cells = <0>;
- };
-
- sdio4_clk: sdio4 {
- compatible = "fixed-clock";
- clock-frequency = <48000000>;
- #clock-cells = <0>;
- };
-
- tmon_1m_clk: tmon_1m {
compatible = "fixed-clock";
- clock-frequency = <1000000>;
- #clock-cells = <0>;
- };
-
- uartb_clk: uartb {
- compatible = "fixed-clock";
- clock-frequency = <13000000>;
- #clock-cells = <0>;
- };
-
- uartb2_clk: uartb2 {
- compatible = "fixed-clock";
- clock-frequency = <13000000>;
- #clock-cells = <0>;
- };
-
- uartb3_clk: uartb3 {
- compatible = "fixed-clock";
- clock-frequency = <13000000>;
- #clock-cells = <0>;
+ clock-frequency = <52000000>;
};
usb_otg_ahb_clk: usb_otg_ahb {
+ #clock-cells = <0>;
compatible = "fixed-clock";
clock-frequency = <52000000>;
+ };
+
+ ref_96m_clk: ref_96m {
#clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <96000000>;
+ };
+
+ var_96m_clk: var_96m {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <96000000>;
+ };
+
+ ref_104m_clk: ref_104m {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <104000000>;
+ };
+
+ var_104m_clk: var_104m {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <104000000>;
+ };
+
+ ref_156m_clk: ref_156m {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <156000000>;
+ };
+
+ var_156m_clk: var_156m {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <156000000>;
+ };
+
+ root_ccu: root_ccu {
+ compatible = BCM21664_DT_ROOT_CCU_COMPAT;
+ reg = <0x35001000 0x0f00>;
+ #clock-cells = <1>;
+ clock-output-names = "frac_1m";
+ };
+
+ aon_ccu: aon_ccu {
+ compatible = BCM21664_DT_AON_CCU_COMPAT;
+ reg = <0x35002000 0x0f00>;
+ #clock-cells = <1>;
+ clock-output-names = "hub_timer";
+ };
+
+ master_ccu: master_ccu {
+ compatible = BCM21664_DT_MASTER_CCU_COMPAT;
+ reg = <0x3f001000 0x0f00>;
+ #clock-cells = <1>;
+ clock-output-names = "sdio1",
+ "sdio2",
+ "sdio3",
+ "sdio4",
+ "sdio1_sleep",
+ "sdio2_sleep",
+ "sdio3_sleep",
+ "sdio4_sleep";
+ };
+
+ slave_ccu: slave_ccu {
+ compatible = BCM21664_DT_SLAVE_CCU_COMPAT;
+ reg = <0x3e011000 0x0f00>;
+ #clock-cells = <1>;
+ clock-output-names = "uartb",
+ "uartb2",
+ "uartb3",
+ "bsc1",
+ "bsc2",
+ "bsc3",
+ "bsc4";
};
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH 4/5] clk: bcm21664: use common clock framework
From: Alex Elder @ 2014-02-28 13:49 UTC (permalink / raw)
To: mturquette, bcm, mporter, devicetree
Cc: linux-doc, linux-arm-kernel, linux-kernel
In-Reply-To: <1393595371-3789-1-git-send-email-elder@linaro.org>
Define the set of CCUs and provided clocks sufficient to satisfy the
needs of all the existing clock references for BCM21664. Replace
the "fake" fixed-rate clocks used previously with "real" ones.
Note that only the minimal set of these clocks and CCUs is defined
here. More clock definitions will need to be added as required by
the addition of additional drivers.
Signed-off-by: Alex Elder <elder@linaro.org>
---
drivers/clk/bcm/Kconfig | 2 +-
drivers/clk/bcm/Makefile | 1 +
drivers/clk/bcm/clk-bcm21664.c | 290 ++++++++++++++++++++++++++++++++++
include/dt-bindings/clock/bcm21664.h | 62 ++++++++
4 files changed, 354 insertions(+), 1 deletion(-)
create mode 100644 drivers/clk/bcm/clk-bcm21664.c
create mode 100644 include/dt-bindings/clock/bcm21664.h
diff --git a/drivers/clk/bcm/Kconfig b/drivers/clk/bcm/Kconfig
index a7262fb..75506e5 100644
--- a/drivers/clk/bcm/Kconfig
+++ b/drivers/clk/bcm/Kconfig
@@ -6,4 +6,4 @@ config CLK_BCM_KONA
help
Enable common clock framework support for Broadcom SoCs
using "Kona" style clock control units, including those
- in the BCM281xx family.
+ in the BCM281xx and BCM21664 families.
diff --git a/drivers/clk/bcm/Makefile b/drivers/clk/bcm/Makefile
index cf93359..6297d05 100644
--- a/drivers/clk/bcm/Makefile
+++ b/drivers/clk/bcm/Makefile
@@ -1,3 +1,4 @@
obj-$(CONFIG_CLK_BCM_KONA) += clk-kona.o
obj-$(CONFIG_CLK_BCM_KONA) += clk-kona-setup.o
obj-$(CONFIG_CLK_BCM_KONA) += clk-bcm281xx.o
+obj-$(CONFIG_CLK_BCM_KONA) += clk-bcm21664.o
diff --git a/drivers/clk/bcm/clk-bcm21664.c b/drivers/clk/bcm/clk-bcm21664.c
new file mode 100644
index 0000000..eeae4ca
--- /dev/null
+++ b/drivers/clk/bcm/clk-bcm21664.c
@@ -0,0 +1,290 @@
+/*
+ * Copyright (C) 2014 Broadcom Corporation
+ * Copyright 2014 Linaro Limited
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include "clk-kona.h"
+#include "dt-bindings/clock/bcm21664.h"
+
+#define BCM21664_CCU_COMMON(_name, _capname) \
+ KONA_CCU_COMMON(BCM21664, _name, _capname)
+
+/* Root CCU */
+
+static struct peri_clk_data frac_1m_data = {
+ .gate = HW_SW_GATE(0x214, 16, 0, 1),
+ .clocks = CLOCKS("ref_crystal"),
+};
+
+static struct ccu_data root_ccu_data = {
+ BCM21664_CCU_COMMON(root, ROOT),
+ /* no policy control */
+ .kona_clks = {
+ [BCM21664_ROOT_CCU_FRAC_1M] =
+ KONA_CLK(root, frac_1m, peri),
+ [BCM21664_ROOT_CCU_CLOCK_COUNT] = LAST_KONA_CLK,
+ },
+};
+
+/* AON CCU */
+
+static struct peri_clk_data hub_timer_data = {
+ .gate = HW_SW_GATE(0x0414, 16, 0, 1),
+ .hyst = HYST(0x0414, 8, 9),
+ .clocks = CLOCKS("bbl_32k",
+ "frac_1m",
+ "dft_19_5m"),
+ .sel = SELECTOR(0x0a10, 0, 2),
+ .trig = TRIGGER(0x0a40, 4),
+};
+
+static struct ccu_data aon_ccu_data = {
+ BCM21664_CCU_COMMON(aon, AON),
+ .policy = {
+ .enable = CCU_LVM_EN(0x0034, 0),
+ .control = CCU_POLICY_CTL(0x000c, 0, 1, 2),
+ },
+ .kona_clks = {
+ [BCM21664_AON_CCU_HUB_TIMER] =
+ KONA_CLK(aon, hub_timer, peri),
+ [BCM21664_AON_CCU_CLOCK_COUNT] = LAST_KONA_CLK,
+ },
+};
+
+/* Master CCU */
+
+static struct peri_clk_data sdio1_data = {
+ .gate = HW_SW_GATE(0x0358, 18, 2, 3),
+ .clocks = CLOCKS("ref_crystal",
+ "var_52m",
+ "ref_52m",
+ "var_96m",
+ "ref_96m"),
+ .sel = SELECTOR(0x0a28, 0, 3),
+ .div = DIVIDER(0x0a28, 4, 14),
+ .trig = TRIGGER(0x0afc, 9),
+};
+
+static struct peri_clk_data sdio2_data = {
+ .gate = HW_SW_GATE(0x035c, 18, 2, 3),
+ .clocks = CLOCKS("ref_crystal",
+ "var_52m",
+ "ref_52m",
+ "var_96m",
+ "ref_96m"),
+ .sel = SELECTOR(0x0a2c, 0, 3),
+ .div = DIVIDER(0x0a2c, 4, 14),
+ .trig = TRIGGER(0x0afc, 10),
+};
+
+static struct peri_clk_data sdio3_data = {
+ .gate = HW_SW_GATE(0x0364, 18, 2, 3),
+ .clocks = CLOCKS("ref_crystal",
+ "var_52m",
+ "ref_52m",
+ "var_96m",
+ "ref_96m"),
+ .sel = SELECTOR(0x0a34, 0, 3),
+ .div = DIVIDER(0x0a34, 4, 14),
+ .trig = TRIGGER(0x0afc, 12),
+};
+
+static struct peri_clk_data sdio4_data = {
+ .gate = HW_SW_GATE(0x0360, 18, 2, 3),
+ .clocks = CLOCKS("ref_crystal",
+ "var_52m",
+ "ref_52m",
+ "var_96m",
+ "ref_96m"),
+ .sel = SELECTOR(0x0a30, 0, 3),
+ .div = DIVIDER(0x0a30, 4, 14),
+ .trig = TRIGGER(0x0afc, 11),
+};
+
+static struct peri_clk_data sdio1_sleep_data = {
+ .clocks = CLOCKS("ref_32k"), /* Verify */
+ .gate = HW_SW_GATE(0x0358, 18, 2, 3),
+};
+
+static struct peri_clk_data sdio2_sleep_data = {
+ .clocks = CLOCKS("ref_32k"), /* Verify */
+ .gate = HW_SW_GATE(0x035c, 18, 2, 3),
+};
+
+static struct peri_clk_data sdio3_sleep_data = {
+ .clocks = CLOCKS("ref_32k"), /* Verify */
+ .gate = HW_SW_GATE(0x0364, 18, 2, 3),
+};
+
+static struct peri_clk_data sdio4_sleep_data = {
+ .clocks = CLOCKS("ref_32k"), /* Verify */
+ .gate = HW_SW_GATE(0x0360, 18, 2, 3),
+};
+
+static struct ccu_data master_ccu_data = {
+ BCM21664_CCU_COMMON(master, MASTER),
+ .policy = {
+ .enable = CCU_LVM_EN(0x0034, 0),
+ .control = CCU_POLICY_CTL(0x000c, 0, 1, 2),
+ },
+ .kona_clks = {
+ [BCM21664_MASTER_CCU_SDIO1] =
+ KONA_CLK(master, sdio1, peri),
+ [BCM21664_MASTER_CCU_SDIO2] =
+ KONA_CLK(master, sdio2, peri),
+ [BCM21664_MASTER_CCU_SDIO3] =
+ KONA_CLK(master, sdio3, peri),
+ [BCM21664_MASTER_CCU_SDIO4] =
+ KONA_CLK(master, sdio4, peri),
+ [BCM21664_MASTER_CCU_SDIO1_SLEEP] =
+ KONA_CLK(master, sdio1_sleep, peri),
+ [BCM21664_MASTER_CCU_SDIO2_SLEEP] =
+ KONA_CLK(master, sdio2_sleep, peri),
+ [BCM21664_MASTER_CCU_SDIO3_SLEEP] =
+ KONA_CLK(master, sdio3_sleep, peri),
+ [BCM21664_MASTER_CCU_SDIO4_SLEEP] =
+ KONA_CLK(master, sdio4_sleep, peri),
+ [BCM21664_MASTER_CCU_CLOCK_COUNT] = LAST_KONA_CLK,
+ },
+};
+
+/* Slave CCU */
+
+static struct peri_clk_data uartb_data = {
+ .gate = HW_SW_GATE(0x0400, 18, 2, 3),
+ .clocks = CLOCKS("ref_crystal",
+ "var_156m",
+ "ref_156m"),
+ .sel = SELECTOR(0x0a10, 0, 2),
+ .div = FRAC_DIVIDER(0x0a10, 4, 12, 8),
+ .trig = TRIGGER(0x0afc, 2),
+};
+
+static struct peri_clk_data uartb2_data = {
+ .gate = HW_SW_GATE(0x0404, 18, 2, 3),
+ .clocks = CLOCKS("ref_crystal",
+ "var_156m",
+ "ref_156m"),
+ .sel = SELECTOR(0x0a14, 0, 2),
+ .div = FRAC_DIVIDER(0x0a14, 4, 12, 8),
+ .trig = TRIGGER(0x0afc, 3),
+};
+
+static struct peri_clk_data uartb3_data = {
+ .gate = HW_SW_GATE(0x0408, 18, 2, 3),
+ .clocks = CLOCKS("ref_crystal",
+ "var_156m",
+ "ref_156m"),
+ .sel = SELECTOR(0x0a18, 0, 2),
+ .div = FRAC_DIVIDER(0x0a18, 4, 12, 8),
+ .trig = TRIGGER(0x0afc, 4),
+};
+
+static struct peri_clk_data bsc1_data = {
+ .gate = HW_SW_GATE(0x0458, 18, 2, 3),
+ .clocks = CLOCKS("ref_crystal",
+ "var_104m",
+ "ref_104m",
+ "var_13m",
+ "ref_13m"),
+ .sel = SELECTOR(0x0a64, 0, 3),
+ .trig = TRIGGER(0x0afc, 23),
+};
+
+static struct peri_clk_data bsc2_data = {
+ .gate = HW_SW_GATE(0x045c, 18, 2, 3),
+ .clocks = CLOCKS("ref_crystal",
+ "var_104m",
+ "ref_104m",
+ "var_13m",
+ "ref_13m"),
+ .sel = SELECTOR(0x0a68, 0, 3),
+ .trig = TRIGGER(0x0afc, 24),
+};
+
+static struct peri_clk_data bsc3_data = {
+ .gate = HW_SW_GATE(0x0470, 18, 2, 3),
+ .clocks = CLOCKS("ref_crystal",
+ "var_104m",
+ "ref_104m",
+ "var_13m",
+ "ref_13m"),
+ .sel = SELECTOR(0x0a7c, 0, 3),
+ .trig = TRIGGER(0x0afc, 18),
+};
+
+static struct peri_clk_data bsc4_data = {
+ .gate = HW_SW_GATE(0x0474, 18, 2, 3),
+ .clocks = CLOCKS("ref_crystal",
+ "var_104m",
+ "ref_104m",
+ "var_13m",
+ "ref_13m"),
+ .sel = SELECTOR(0x0a80, 0, 3),
+ .trig = TRIGGER(0x0afc, 19),
+};
+
+static struct ccu_data slave_ccu_data = {
+ BCM21664_CCU_COMMON(slave, SLAVE),
+ .policy = {
+ .enable = CCU_LVM_EN(0x0034, 0),
+ .control = CCU_POLICY_CTL(0x000c, 0, 1, 2),
+ },
+ .kona_clks = {
+ [BCM21664_SLAVE_CCU_UARTB] =
+ KONA_CLK(slave, uartb, peri),
+ [BCM21664_SLAVE_CCU_UARTB2] =
+ KONA_CLK(slave, uartb2, peri),
+ [BCM21664_SLAVE_CCU_UARTB3] =
+ KONA_CLK(slave, uartb3, peri),
+ [BCM21664_SLAVE_CCU_BSC1] =
+ KONA_CLK(slave, bsc1, peri),
+ [BCM21664_SLAVE_CCU_BSC2] =
+ KONA_CLK(slave, bsc2, peri),
+ [BCM21664_SLAVE_CCU_BSC3] =
+ KONA_CLK(slave, bsc3, peri),
+ [BCM21664_SLAVE_CCU_BSC4] =
+ KONA_CLK(slave, bsc4, peri),
+ [BCM21664_SLAVE_CCU_CLOCK_COUNT] = LAST_KONA_CLK,
+ },
+};
+
+/* Device tree match table callback functions */
+
+static void __init kona_dt_root_ccu_setup(struct device_node *node)
+{
+ kona_dt_ccu_setup(&root_ccu_data, node);
+}
+
+static void __init kona_dt_aon_ccu_setup(struct device_node *node)
+{
+ kona_dt_ccu_setup(&aon_ccu_data, node);
+}
+
+static void __init kona_dt_master_ccu_setup(struct device_node *node)
+{
+ kona_dt_ccu_setup(&master_ccu_data, node);
+}
+
+static void __init kona_dt_slave_ccu_setup(struct device_node *node)
+{
+ kona_dt_ccu_setup(&slave_ccu_data, node);
+}
+
+CLK_OF_DECLARE(bcm21664_root_ccu, BCM21664_DT_ROOT_CCU_COMPAT,
+ kona_dt_root_ccu_setup);
+CLK_OF_DECLARE(bcm21664_aon_ccu, BCM21664_DT_AON_CCU_COMPAT,
+ kona_dt_aon_ccu_setup);
+CLK_OF_DECLARE(bcm21664_master_ccu, BCM21664_DT_MASTER_CCU_COMPAT,
+ kona_dt_master_ccu_setup);
+CLK_OF_DECLARE(bcm21664_slave_ccu, BCM21664_DT_SLAVE_CCU_COMPAT,
+ kona_dt_slave_ccu_setup);
diff --git a/include/dt-bindings/clock/bcm21664.h b/include/dt-bindings/clock/bcm21664.h
new file mode 100644
index 0000000..5a7f0e4
--- /dev/null
+++ b/include/dt-bindings/clock/bcm21664.h
@@ -0,0 +1,62 @@
+/*
+ * Copyright (C) 2013 Broadcom Corporation
+ * Copyright 2013 Linaro Limited
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef _CLOCK_BCM21664_H
+#define _CLOCK_BCM21664_H
+
+/*
+ * This file defines the values used to specify clocks provided by
+ * the clock control units (CCUs) on Broadcom BCM21664 family SoCs.
+ */
+
+/* bcm21664 CCU device tree "compatible" strings */
+#define BCM21664_DT_ROOT_CCU_COMPAT "brcm,bcm21664-root-ccu"
+#define BCM21664_DT_AON_CCU_COMPAT "brcm,bcm21664-aon-ccu"
+#define BCM21664_DT_MASTER_CCU_COMPAT "brcm,bcm21664-master-ccu"
+#define BCM21664_DT_SLAVE_CCU_COMPAT "brcm,bcm21664-slave-ccu"
+
+/* root CCU clock ids */
+
+#define BCM21664_ROOT_CCU_FRAC_1M 0
+#define BCM21664_ROOT_CCU_CLOCK_COUNT 1
+
+/* aon CCU clock ids */
+
+#define BCM21664_AON_CCU_HUB_TIMER 0
+#define BCM21664_AON_CCU_CLOCK_COUNT 1
+
+/* master CCU clock ids */
+
+#define BCM21664_MASTER_CCU_SDIO1 0
+#define BCM21664_MASTER_CCU_SDIO2 1
+#define BCM21664_MASTER_CCU_SDIO3 2
+#define BCM21664_MASTER_CCU_SDIO4 3
+#define BCM21664_MASTER_CCU_SDIO1_SLEEP 4
+#define BCM21664_MASTER_CCU_SDIO2_SLEEP 5
+#define BCM21664_MASTER_CCU_SDIO3_SLEEP 6
+#define BCM21664_MASTER_CCU_SDIO4_SLEEP 7
+#define BCM21664_MASTER_CCU_CLOCK_COUNT 8
+
+/* slave CCU clock ids */
+
+#define BCM21664_SLAVE_CCU_UARTB 0
+#define BCM21664_SLAVE_CCU_UARTB2 1
+#define BCM21664_SLAVE_CCU_UARTB3 2
+#define BCM21664_SLAVE_CCU_BSC1 3
+#define BCM21664_SLAVE_CCU_BSC2 4
+#define BCM21664_SLAVE_CCU_BSC3 5
+#define BCM21664_SLAVE_CCU_BSC4 6
+#define BCM21664_SLAVE_CCU_CLOCK_COUNT 7
+
+#endif /* _CLOCK_BCM21664_H */
--
1.7.9.5
^ permalink raw reply related
* [PATCH 3/5] ARM: dts: define clock binding for bcm21664
From: Alex Elder @ 2014-02-28 13:49 UTC (permalink / raw)
To: mturquette, bcm, mporter, devicetree
Cc: linux-doc, linux-arm-kernel, linux-kernel
In-Reply-To: <1393595371-3789-1-git-send-email-elder@linaro.org>
Document the device tree binding for Broadcom BCM28164 clock control
units and clocks. This SoC uses Kona CCUs, similar to the BCM281XX
SoC family.
Signed-off-by: Alex Elder <elder@linaro.org>
---
.../devicetree/bindings/clock/bcm-kona-clock.txt | 39 ++++++++++++++++++++
1 file changed, 39 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/bcm-kona-clock.txt b/Documentation/devicetree/bindings/clock/bcm-kona-clock.txt
index ebe3ab6..5286e26 100644
--- a/Documentation/devicetree/bindings/clock/bcm-kona-clock.txt
+++ b/Documentation/devicetree/bindings/clock/bcm-kona-clock.txt
@@ -98,3 +98,42 @@ be used. These specifiers are defined in:
slave bsc2 peri 7 BCM281XX_SLAVE_CCU_BSC2
slave bsc3 peri 8 BCM281XX_SLAVE_CCU_BSC3
slave pwm peri 9 BCM281XX_SLAVE_CCU_PWM
+
+
+BCM21664 family
+---------------
+CCU compatible string values for SoCs in the BCM21664 family are:
+ "brcm,bcm21664-root-ccu"
+ "brcm,bcm21664-aon-ccu"
+ "brcm,bcm21664-master-ccu"
+ "brcm,bcm21664-slave-ccu"
+
+The following table defines the set of CCUs and clock specifiers for
+BCM21664 family clocks. When a clock consumer references a clocks,
+its symbolic specifier (rather than its numeric index value) should
+be used. These specifiers are defined in:
+ "include/dt-bindings/clock/bcm21664.h"
+
+ CCU Clock Type Index Specifier
+ --- ----- ---- ----- ---------
+ root frac_1m peri 0 BCM21664_ROOT_CCU_FRAC_1M
+
+ aon hub_timer peri 0 BCM21664_AON_CCU_HUB_TIMER
+
+ master sdio1 peri 0 BCM21664_MASTER_CCU_SDIO1
+ master sdio2 peri 1 BCM21664_MASTER_CCU_SDIO2
+ master sdio3 peri 2 BCM21664_MASTER_CCU_SDIO3
+ master sdio4 peri 3 BCM21664_MASTER_CCU_SDIO4
+ master sdio1_sleep peri 4 BCM21664_MASTER_CCU_SDIO1_SLEEP
+ master sdio2_sleep peri 5 BCM21664_MASTER_CCU_SDIO2_SLEEP
+ master sdio3_sleep peri 6 BCM21664_MASTER_CCU_SDIO3_SLEEP
+ master sdio4_sleep peri 7 BCM21664_MASTER_CCU_SDIO4_SLEEP
+
+ slave uartb peri 0 BCM21664_SLAVE_CCU_UARTB
+ slave uartb2 peri 1 BCM21664_SLAVE_CCU_UARTB2
+ slave uartb3 peri 2 BCM21664_SLAVE_CCU_UARTB3
+ slave uartb4 peri 3 BCM21664_SLAVE_CCU_UARTB4
+ slave bsc1 peri 4 BCM21664_SLAVE_CCU_BSC1
+ slave bsc2 peri 5 BCM21664_SLAVE_CCU_BSC2
+ slave bsc3 peri 6 BCM21664_SLAVE_CCU_BSC3
+ slave bsc4 peri 7 BCM21664_SLAVE_CCU_BSC4
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/5] ARM: dts: revise kona clock binding document
From: Alex Elder @ 2014-02-28 13:49 UTC (permalink / raw)
To: mturquette, bcm, mporter, devicetree
Cc: linux-doc, linux-arm-kernel, linux-kernel
In-Reply-To: <1393595371-3789-1-git-send-email-elder@linaro.org>
The next patch defines a binding for a new Broadcom SoC that uses
Kona style CCUs for its clocks. Update the generic Kona clock
binding document so it's more natural to accomodate the definitions
of additional SoC families.
Specifically:
- Define the compatible string values generically, referring
to specific per-model values later in the document.
- Put the device tree example immediately after the required
properties listing, before the tables of SoC-specific values.
- Clearly identify the start of the section defining specific
values related to the BCM281XX family
- Add a list of the specific BCM281XX family compatible strings.
- Reword the description of the table slightly.
Signed-off-by: Alex Elder <elder@linaro.org>
---
.../devicetree/bindings/clock/bcm-kona-clock.txt | 87 +++++++++++---------
1 file changed, 47 insertions(+), 40 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/bcm-kona-clock.txt b/Documentation/devicetree/bindings/clock/bcm-kona-clock.txt
index 56d1f49..ebe3ab6 100644
--- a/Documentation/devicetree/bindings/clock/bcm-kona-clock.txt
+++ b/Documentation/devicetree/bindings/clock/bcm-kona-clock.txt
@@ -10,12 +10,12 @@ This binding uses the common clock binding:
Required properties:
- compatible
- Shall have one of the following values:
- - "brcm,bcm11351-root-ccu"
- - "brcm,bcm11351-aon-ccu"
- - "brcm,bcm11351-hub-ccu"
- - "brcm,bcm11351-master-ccu"
- - "brcm,bcm11351-slave-ccu"
+ Shall have a value of the form "brcm,<model>-<which>-ccu",
+ where <model> is a Broadcom SoC model number and <which> is
+ the name of a defined CCU. For example:
+ "brcm,bcm11351-root-ccu"
+ The compatible strings used for each supported SoC family
+ are defined below.
- reg
Shall define the base and range of the address space
containing clock control registers
@@ -26,12 +26,48 @@ Required properties:
Shall be an ordered list of strings defining the names of
the clocks provided by the CCU.
+Device tree example:
-BCM281XX family SoCs use Kona CCUs. The following table defines
-the set of CCUs and clock specifiers for BCM281XX clocks. When
-a clock consumer references a clocks, its symbolic specifier
-(rather than its numeric index value) should be used. These
-specifiers are defined in "include/dt-bindings/clock/bcm281xx.h".
+ slave_ccu: slave_ccu {
+ compatible = "brcm,bcm11351-slave-ccu";
+ reg = <0x3e011000 0x0f00>;
+ #clock-cells = <1>;
+ clock-output-names = "uartb",
+ "uartb2",
+ "uartb3",
+ "uartb4";
+ };
+
+ ref_crystal_clk: ref_crystal {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <26000000>;
+ };
+
+ uart@3e002000 {
+ compatible = "brcm,bcm11351-dw-apb-uart", "snps,dw-apb-uart";
+ status = "disabled";
+ reg = <0x3e002000 0x1000>;
+ clocks = <&slave_ccu BCM281XX_SLAVE_CCU_UARTB3>;
+ interrupts = <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ };
+
+BCM281XX family
+---------------
+CCU compatible string values for SoCs in the BCM281XX family are:
+ "brcm,bcm11351-root-ccu"
+ "brcm,bcm11351-aon-ccu"
+ "brcm,bcm11351-hub-ccu"
+ "brcm,bcm11351-master-ccu"
+ "brcm,bcm11351-slave-ccu"
+
+The following table defines the set of CCUs and clock specifiers for
+BCM281XX family clocks. When a clock consumer references a clocks,
+its symbolic specifier (rather than its numeric index value) should
+be used. These specifiers are defined in:
+ "include/dt-bindings/clock/bcm281xx.h"
CCU Clock Type Index Specifier
--- ----- ---- ----- ---------
@@ -62,32 +98,3 @@ specifiers are defined in "include/dt-bindings/clock/bcm281xx.h".
slave bsc2 peri 7 BCM281XX_SLAVE_CCU_BSC2
slave bsc3 peri 8 BCM281XX_SLAVE_CCU_BSC3
slave pwm peri 9 BCM281XX_SLAVE_CCU_PWM
-
-
-Device tree example:
-
- slave_ccu: slave_ccu {
- compatible = "brcm,bcm11351-slave-ccu";
- reg = <0x3e011000 0x0f00>;
- #clock-cells = <1>;
- clock-output-names = "uartb",
- "uartb2",
- "uartb3",
- "uartb4";
- };
-
- ref_crystal_clk: ref_crystal {
- #clock-cells = <0>;
- compatible = "fixed-clock";
- clock-frequency = <26000000>;
- };
-
- uart@3e002000 {
- compatible = "brcm,bcm11351-dw-apb-uart", "snps,dw-apb-uart";
- status = "disabled";
- reg = <0x3e002000 0x1000>;
- clocks = <&slave_ccu BCM281XX_SLAVE_CCU_UARTB3>;
- interrupts = <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>;
- reg-shift = <2>;
- reg-io-width = <4>;
- };
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/5] clk: bcm281xx: move compatible string definitions
From: Alex Elder @ 2014-02-28 13:49 UTC (permalink / raw)
To: mturquette, bcm, mporter, devicetree
Cc: linux-doc, linux-arm-kernel, linux-kernel
In-Reply-To: <1393595371-3789-1-git-send-email-elder@linaro.org>
The Broadcom 281xx clock code uses a #define for the compatible
string for it's clock control units (CCUs). Rather than defining
those in the C source file, define them in the header file that's
shared by both the code and the device tree source file (along with
all the clock ids).
Signed-off-by: Alex Elder <elder@linaro.org>
---
drivers/clk/bcm/clk-bcm281xx.c | 12 ------------
include/dt-bindings/clock/bcm281xx.h | 12 ++++++++++++
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/clk/bcm/clk-bcm281xx.c b/drivers/clk/bcm/clk-bcm281xx.c
index d0d3dde..b937fc9 100644
--- a/drivers/clk/bcm/clk-bcm281xx.c
+++ b/drivers/clk/bcm/clk-bcm281xx.c
@@ -18,18 +18,6 @@
#define BCM281XX_CCU_COMMON(_name, _ucase_name) \
KONA_CCU_COMMON(BCM281XX, _name, _ucase_name)
-/*
- * These are the bcm281xx CCU device tree "compatible" strings.
- * We're stuck with using "bcm11351" in the string because wild
- * cards aren't allowed, and that name was the first one defined
- * in this family of devices.
- */
-#define BCM281XX_DT_ROOT_CCU_COMPAT "brcm,bcm11351-root-ccu"
-#define BCM281XX_DT_AON_CCU_COMPAT "brcm,bcm11351-aon-ccu"
-#define BCM281XX_DT_HUB_CCU_COMPAT "brcm,bcm11351-hub-ccu"
-#define BCM281XX_DT_MASTER_CCU_COMPAT "brcm,bcm11351-master-ccu"
-#define BCM281XX_DT_SLAVE_CCU_COMPAT "brcm,bcm11351-slave-ccu"
-
/* Root CCU */
static struct peri_clk_data frac_1m_data = {
diff --git a/include/dt-bindings/clock/bcm281xx.h b/include/dt-bindings/clock/bcm281xx.h
index 57591b1..99f4aad 100644
--- a/include/dt-bindings/clock/bcm281xx.h
+++ b/include/dt-bindings/clock/bcm281xx.h
@@ -20,6 +20,18 @@
* the clock control units (CCUs) on Broadcom BCM281XX family SoCs.
*/
+/*
+ * These are the bcm281xx CCU device tree "compatible" strings.
+ * We're stuck with using "bcm11351" in the string because wild
+ * cards aren't allowed, and that name was the first one defined
+ * in this family of devices.
+ */
+#define BCM281XX_DT_ROOT_CCU_COMPAT "brcm,bcm11351-root-ccu"
+#define BCM281XX_DT_AON_CCU_COMPAT "brcm,bcm11351-aon-ccu"
+#define BCM281XX_DT_HUB_CCU_COMPAT "brcm,bcm11351-hub-ccu"
+#define BCM281XX_DT_MASTER_CCU_COMPAT "brcm,bcm11351-master-ccu"
+#define BCM281XX_DT_SLAVE_CCU_COMPAT "brcm,bcm11351-slave-ccu"
+
/* root CCU clock ids */
#define BCM281XX_ROOT_CCU_FRAC_1M 0
--
1.7.9.5
^ permalink raw reply related
* [PATCH 0/5] clk: bcm21664: add common clock support
From: Alex Elder @ 2014-02-28 13:49 UTC (permalink / raw)
To: mturquette, bcm, mporter, devicetree
Cc: linux-doc, linux-arm-kernel, linux-kernel
This is series has two parts. The first two patches are changes
to the existing Broadcom Kona family clock code to prepare for the
addition of support for another SoC bcm21664.
The remaining three define the binding and code for bcm21664, and
replace the use of "fake" clocks in the device tree with the real
ones. This ends up being a fairly straightforward definition of
the clocks on this SoC; the rest of the clock code is shared with
other SoCs that use the Kona style clock system.
This series depends on a number of other things that are
currently queued for Linux 3.15 or have already been sent
out for review:
- Clock support for bcm281xx (code and DT file, queued for 3.15)
https://github.com/broadcom/mach-bcm/
armsoc/for-3.15/drivers
armsoc/for-3.15/dt
- Additional fixes and features for bcm281xx (out for review)
https://lkml.org/lkml/2014/2/25/614
- Initial BCM21664 support (from Markus Mayer, out for review)
https://lkml.org/lkml/2014/2/27/615
This prerequisite code appears in the branch (below) as merges from
other publicly-available git branches.
This code is available in the "review/bcm21664-clock" branch of
the git repository here:
http://git.linaro.org/git/landing-teams/working/broadcom/kernel.git
-Alex
Alex Elder (5):
clk: bcm281xx: move compatible string definitions
ARM: dts: revise kona clock binding document
Cleanup and prepare existing code for addition of new SoC.
ARM: dts: define clock binding for bcm21664
clk: bcm21664: use common clock framework
ARM: dts: use real clocks for bcm21664
Add support for the bcm21664 SoC.
.../devicetree/bindings/clock/bcm-kona-clock.txt | 116 +++++---
arch/arm/boot/dts/bcm21664.dtsi | 190 ++++++++-----
drivers/clk/bcm/Kconfig | 2 +-
drivers/clk/bcm/Makefile | 1 +
drivers/clk/bcm/clk-bcm21664.c | 290 ++++++++++++++++++++
drivers/clk/bcm/clk-bcm281xx.c | 12 -
include/dt-bindings/clock/bcm21664.h | 62 +++++
include/dt-bindings/clock/bcm281xx.h | 12 +
8 files changed, 565 insertions(+), 120 deletions(-)
create mode 100644 drivers/clk/bcm/clk-bcm21664.c
create mode 100644 include/dt-bindings/clock/bcm21664.h
--
1.7.9.5
^ permalink raw reply
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