* Re: [PATCH 0/6] BCM59056 PMU regulator support
From: Matt Porter @ 2014-02-04 14:34 UTC (permalink / raw)
To: Lee Jones
Cc: Wolfram Sang, Tim Kryger, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, Samuel Ortiz, Liam Girdwood, Mark Brown,
Christian Daudt, Devicetree List, Linux I2C List,
Linux ARM Kernel List, Linux Kernel Mailing List
In-Reply-To: <20140204134043.GG13529@lee--X1>
On Tue, Feb 04, 2014 at 01:40:43PM +0000, Lee Jones wrote:
> > The BCM59056 is a multi-function power management unit used with the
> > BCM281xx family of SoCs. This series adds an MFD and voltage regulator
> > driver to support the BCM59056. The bcm28155-ap DT support is updated
> > to enable use of regulators on the otg and sdhci peripherals.
> >
> > Matt Porter (6):
> > i2c: bcm-kona: register with subsys_initcall
> > regulator: add bcm59056 pmu DT binding
> > mfd: add bcm59056 pmu driver
> > regulator: add bcm59056 regulator driver
> > ARM: configs: bcm_defconfig: enable bcm59056 regulator support
> > ARM: dts: add bcm59056 pmu support and enable for bcm28155-ap
> >
> > .../devicetree/bindings/regulator/bcm59056.txt | 37 ++
> > arch/arm/boot/dts/bcm28155-ap.dts | 41 ++
> > arch/arm/boot/dts/bcm59056.dtsi | 158 ++++++++
> > arch/arm/configs/bcm_defconfig | 7 +
> > drivers/i2c/busses/i2c-bcm-kona.c | 14 +-
> > drivers/mfd/Kconfig | 8 +
> > drivers/mfd/Makefile | 1 +
> > drivers/mfd/bcm59056.c | 119 ++++++
> > drivers/regulator/Kconfig | 8 +
> > drivers/regulator/Makefile | 1 +
> > drivers/regulator/bcm59056-regulator.c | 445 +++++++++++++++++++++
> > include/linux/mfd/bcm59056.h | 35 ++
> > 12 files changed, 873 insertions(+), 1 deletion(-)
> > create mode 100644 Documentation/devicetree/bindings/regulator/bcm59056.txt
> > create mode 100644 arch/arm/boot/dts/bcm59056.dtsi
> > create mode 100644 drivers/mfd/bcm59056.c
> > create mode 100644 drivers/regulator/bcm59056-regulator.c
> > create mode 100644 include/linux/mfd/bcm59056.h
>
> FYI: Mark's email address is not correct. Not sure where you pulled
> this one up from, but he doesn't have access to it anymore.
Thanks, I already updated (it was a stale .mutt/aliases entry here) it
after the bounces.
-Matt
^ permalink raw reply
* Re: [PATCH v2] of: fix PCI bus match for PCIe slots
From: Grant Likely @ 2014-02-04 14:32 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: Benjamin Herrenschmidt, Brian King, Rob Herring,
Kleber Sacilotto de Souza
In-Reply-To: <1391441463-12461-1-git-send-email-klebers-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
On Mon, 3 Feb 2014 13:31:03 -0200, Kleber Sacilotto de Souza <klebers-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org> wrote:
> On IBM pseries systems the device_type device-tree property of a PCIe
> bridge contains the string "pciex". The of_bus_pci_match() function was
> looking only for "pci" on this property, so in such cases the bus
> matching code was falling back to the default bus, causing problems on
> functions that should be using "assigned-addresses" for region address
> translation. This patch fixes the problem by also looking for "pciex" on
> the PCI bus match function.
>
> v2: added comment
>
> Signed-off-by: Kleber Sacilotto de Souza <klebers-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
Applied, thanks.
g.
> ---
> drivers/of/address.c | 5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index d3dd41c..1a54f1f 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -99,11 +99,12 @@ static unsigned int of_bus_default_get_flags(const __be32 *addr)
> static int of_bus_pci_match(struct device_node *np)
> {
> /*
> + * "pciex" is PCI Express
> * "vci" is for the /chaos bridge on 1st-gen PCI powermacs
> * "ht" is hypertransport
> */
> - return !strcmp(np->type, "pci") || !strcmp(np->type, "vci") ||
> - !strcmp(np->type, "ht");
> + return !strcmp(np->type, "pci") || !strcmp(np->type, "pciex") ||
> + !strcmp(np->type, "vci") || !strcmp(np->type, "ht");
> }
>
> static void of_bus_pci_count_cells(struct device_node *np,
> --
> 1.7.1
>
--
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 3/6] mfd: add bcm59056 pmu driver
From: Matt Porter @ 2014-02-04 14:31 UTC (permalink / raw)
To: Lee Jones
Cc: Wolfram Sang, Tim Kryger, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, Samuel Ortiz, Liam Girdwood, Mark Brown,
Christian Daudt, Devicetree List, Linux I2C List,
Linux ARM Kernel List, Linux Kernel Mailing List
In-Reply-To: <20140204132951.GE13529@lee--X1>
On Tue, Feb 04, 2014 at 01:29:51PM +0000, Lee Jones wrote:
> > Add a driver for the BCM59056 PMU multi-function device. The driver
> > initially supports regmap initialization and instantiation of the
> > voltage regulator device function of the PMU.
> >
> > Signed-off-by: Matt Porter <mporter@linaro.org>
> > Reviewed-by: Tim Kryger <tim.kryger@linaro.org>
> > Reviewed-by: Markus Mayer <markus.mayer@linaro.org>
> > ---
> > drivers/mfd/Kconfig | 8 +++
> > drivers/mfd/Makefile | 1 +
> > drivers/mfd/bcm59056.c | 119 +++++++++++++++++++++++++++++++++++++++++++
> > include/linux/mfd/bcm59056.h | 35 +++++++++++++
> > 4 files changed, 163 insertions(+)
> > create mode 100644 drivers/mfd/bcm59056.c
> > create mode 100644 include/linux/mfd/bcm59056.h
>
> <snip>
>
> > +static struct mfd_cell bcm59056s[] = {
> > + {
> > + .name = "bcm59056-pmu",
>
> If you plan to use *->of_node in the PMU driver, which it looks like
> you do, you should set the compatible string here.
Ok. I missed that..I'll split bindings to reflect this as well. There's
an error in that the regulator properties are all defined in the base
compatible of brcm,bcm59056 atm and they'll need to be in
brcm,bcm59056-pmu's binding.
> > + },
> > +};
> > +
> > +static const struct regmap_config bcm59056_regmap_config = {
> > + .reg_bits = 8,
> > + .val_bits = 8,
> > + .max_register = BCM59056_MAX_REGISTER - 1,
>
> If you've just set this manually i.e. it's not part of an enum table,
> can't you set it a value you don't need to do math on? It's not used
> anywhere else is it?
Yes, I'll update this. It's not used elsewhere.
>
> > + .cache_type = REGCACHE_RBTREE,
> > +};
> > +
> > +static int bcm59056_i2c_probe(struct i2c_client *i2c,
> > + const struct i2c_device_id *id)
> > +{
> > + struct bcm59056 *bcm59056;
> > + int chip_id = id->driver_data;
>
> I thought this was a DT only driver? If so, you probably want to use
> of_match_device() instead.
Correct, I'll use of_match_device()
> > + int ret = 0;
> > +
> > + bcm59056 = devm_kzalloc(&i2c->dev, sizeof(*bcm59056), GFP_KERNEL);
> > + if (!bcm59056)
> > + return -ENOMEM;
> > +
> > + i2c_set_clientdata(i2c, bcm59056);
> > + bcm59056->dev = &i2c->dev;
> > + bcm59056->i2c_client = i2c;
> > + bcm59056->id = chip_id;
> > +
> > + bcm59056->regmap = devm_regmap_init_i2c(i2c, &bcm59056_regmap_config);
> > + if (IS_ERR(bcm59056->regmap)) {
> > + ret = PTR_ERR(bcm59056->regmap);
> > + dev_err(&i2c->dev, "regmap initialization failed: %d\n", ret);
> > + return ret;
> > + }
> > +
> > + ret = mfd_add_devices(bcm59056->dev, -1,
> > + bcm59056s, ARRAY_SIZE(bcm59056s),
> > + NULL, 0, NULL);
>
> Are you sure you need all of your #includes?
>
> I notice that irqdomain is there, but you don't actually have one?
Right, I'll do a sweep on them. In that particular case, I don't yet
have a need to implement interrupt support so it needs to go.
>
> > + if (ret < 0)
> > + dev_err(&i2c->dev, "mfd_add_devices failed: %d\n", ret);
>
> What if we change the name of the function? Probably better to say
> something like "device registration failed" or thelike.
Will do.
>
> > + return ret;
> > +}
> > +
> > +static int bcm59056_i2c_remove(struct i2c_client *i2c)
> > +{
> > + struct bcm59056 *bcm59056 = i2c_get_clientdata(i2c);
> > +
> > + mfd_remove_devices(bcm59056->dev);
> > +
> > + return 0;
> > +}
> > +
> > +static const struct of_device_id bcm59056_of_match[] = {
> > + { .compatible = "brcm,bcm59056", .data = (void *)BCM59056 },
>
> You've gone to the trouble of setting a device version here, but you
> don't seem to use it?
I'll drop the device version
> > + { }
> > +};
> > +
> > +static const struct i2c_device_id bcm59056_i2c_id[] = {
> > + { "bcm59056", BCM59056 },
> > + { }
> > +};
>
> Ah, I guess this is where id->driver comes from.
>
> It's pretty silly that the I2C subsystem demands the presence of this
> table, despite not using it if an of_device_id table is present.
It does make it very difficult to follow DT enabled I2C client drivers
:( I'll drop the BCM59056 too.
> > +MODULE_DEVICE_TABLE(i2c, bcm59056_i2c_id);
> > +
> > +static struct i2c_driver bcm59056_i2c_driver = {
> > + .driver = {
> > + .name = "bcm59056",
> > + .owner = THIS_MODULE,
> > + .of_match_table = of_match_ptr(bcm59056_of_match),
>
> No need to use of_match_ptr() here.
Will remove.
> > + },
> > + .probe = bcm59056_i2c_probe,
> > + .remove = bcm59056_i2c_remove,
> > + .id_table = bcm59056_i2c_id,
>
> *grumble*
:) Yes, unavoidable for now.
> > +};
> > +
> > +static int __init bcm59056_init(void)
> > +{
> > + return i2c_add_driver(&bcm59056_i2c_driver);
> > +}
> > +subsys_initcall(bcm59056_init);
>
> Really? :(
>
> Maybe you'll want to comment this, in case people do not know the back
> ground and attempts to clean it up.
I'll add a comment. This is the old problem of needing regulators really
early. It's exasperated by the fact that the USB gadget framework
drivers do not use driver probing. This means that they can not be
deferred after i2c/mfd/regulator init...the problem is particularly
noticeable when building in a gadget driver for nfsroot purposes.
Because of this I have the regulator, MFD, and i2c drivers all using
subsys_initcall() in this series. FWIW, there's some discussion about
how to resolve the USB gadget driver case but it's going to take a
while.
> > +static void __exit bcm59056_exit(void)
> > +{
> > + i2c_del_driver(&bcm59056_i2c_driver);
> > +}
> > +module_exit(bcm59056_exit);
>
> <snip>
>
> > +/* chip id */
> > +#define BCM59056 0
>
> Lonely, oh so lonely!
Understood. Will remove.
> > +/* max register address */
> > +#define BCM59056_MAX_REGISTER 0xe8
>
> Don't you have a table of registers which you care about?
I placed the register defs that I actually use in the regulator driver
itself since that is the only place they are used. I notice most MFD
drivers centralize this in linux/mfd/*.h. However, generally chunk
of register defs are only used in one subdriver and not shared. If
it's preferred to move all register defs centrally I can do that.
> > +/* bcm59056 chip access */
>
> Superfluous comment? Don't we all know what these containers do?
Indeed, will remove.
Thanks for reviewing.
-Matt
> > +struct bcm59056 {
> > + struct device *dev;
> > + struct i2c_client *i2c_client;
> > + struct regmap *regmap;
> > + unsigned int id;
> > +};
> > +
> > +#endif /* __LINUX_MFD_BCM59056_H */
>
> --
> Lee Jones
> Linaro STMicroelectronics Landing Team Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH] of: restructure for_each macros to fix compile warnings
From: Grant Likely @ 2014-02-04 14:27 UTC (permalink / raw)
To: Rob Herring, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: Geert Uytterhoeven, Rob Herring, David Howells
In-Reply-To: <1391469424-5245-1-git-send-email-robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Mon, 3 Feb 2014 17:17:04 -0600, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> From: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>
> Commit 00b2c76a6a "include/linux/of.h: make for_each_child_of_node()
> reference its args when CONFIG_OF=n" fixed warnings for unused
> variables, but introduced variable "used uninitialized" warnings.
> Simply initializing the variables would result in "set but not used"
> warnings with W=1.
>
> Fix both types of warnings by making all the for_each macros
> unconditional and rely on the dummy static inline functions to
> initialize and reference any variables.
>
> Reported-by: Geert Uytterhoeven <geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>
> Cc: David Howells <dhowells-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> Signed-off-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Acked-by: Grant Likely <grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> include/linux/of.h | 153 +++++++++++++++++++++++++++++------------------------
> 1 file changed, 84 insertions(+), 69 deletions(-)
>
> diff --git a/include/linux/of.h b/include/linux/of.h
> index 70c64ba..435cb99 100644
> --- a/include/linux/of.h
> +++ b/include/linux/of.h
> @@ -169,35 +169,15 @@ static inline const char *of_node_full_name(const struct device_node *np)
>
> extern struct device_node *of_find_node_by_name(struct device_node *from,
> const char *name);
> -#define for_each_node_by_name(dn, name) \
> - for (dn = of_find_node_by_name(NULL, name); dn; \
> - dn = of_find_node_by_name(dn, name))
> extern struct device_node *of_find_node_by_type(struct device_node *from,
> const char *type);
> -#define for_each_node_by_type(dn, type) \
> - for (dn = of_find_node_by_type(NULL, type); dn; \
> - dn = of_find_node_by_type(dn, type))
> extern struct device_node *of_find_compatible_node(struct device_node *from,
> const char *type, const char *compat);
> -#define for_each_compatible_node(dn, type, compatible) \
> - for (dn = of_find_compatible_node(NULL, type, compatible); dn; \
> - dn = of_find_compatible_node(dn, type, compatible))
> extern struct device_node *of_find_matching_node_and_match(
> struct device_node *from,
> const struct of_device_id *matches,
> const struct of_device_id **match);
> -static inline struct device_node *of_find_matching_node(
> - struct device_node *from,
> - const struct of_device_id *matches)
> -{
> - return of_find_matching_node_and_match(from, matches, NULL);
> -}
> -#define for_each_matching_node(dn, matches) \
> - for (dn = of_find_matching_node(NULL, matches); dn; \
> - dn = of_find_matching_node(dn, matches))
> -#define for_each_matching_node_and_match(dn, matches, match) \
> - for (dn = of_find_matching_node_and_match(NULL, matches, match); \
> - dn; dn = of_find_matching_node_and_match(dn, matches, match))
> +
> extern struct device_node *of_find_node_by_path(const char *path);
> extern struct device_node *of_find_node_by_phandle(phandle handle);
> extern struct device_node *of_get_parent(const struct device_node *node);
> @@ -209,43 +189,11 @@ extern struct device_node *of_get_next_available_child(
>
> extern struct device_node *of_get_child_by_name(const struct device_node *node,
> const char *name);
> -#define for_each_child_of_node(parent, child) \
> - for (child = of_get_next_child(parent, NULL); child != NULL; \
> - child = of_get_next_child(parent, child))
> -
> -#define for_each_available_child_of_node(parent, child) \
> - for (child = of_get_next_available_child(parent, NULL); child != NULL; \
> - child = of_get_next_available_child(parent, child))
> -
> -static inline int of_get_child_count(const struct device_node *np)
> -{
> - struct device_node *child;
> - int num = 0;
> -
> - for_each_child_of_node(np, child)
> - num++;
> -
> - return num;
> -}
> -
> -static inline int of_get_available_child_count(const struct device_node *np)
> -{
> - struct device_node *child;
> - int num = 0;
> -
> - for_each_available_child_of_node(np, child)
> - num++;
> -
> - return num;
> -}
>
> /* cache lookup */
> extern struct device_node *of_find_next_cache_node(const struct device_node *);
> extern struct device_node *of_find_node_with_property(
> struct device_node *from, const char *prop_name);
> -#define for_each_node_with_property(dn, prop_name) \
> - for (dn = of_find_node_with_property(NULL, prop_name); dn; \
> - dn = of_find_node_with_property(dn, prop_name))
>
> extern struct property *of_find_property(const struct device_node *np,
> const char *name,
> @@ -367,42 +315,53 @@ static inline struct device_node *of_find_node_by_name(struct device_node *from,
> return NULL;
> }
>
> -static inline struct device_node *of_get_parent(const struct device_node *node)
> +static inline struct device_node *of_find_node_by_type(struct device_node *from,
> + const char *type)
> {
> return NULL;
> }
>
> -static inline bool of_have_populated_dt(void)
> +static inline struct device_node *of_find_matching_node_and_match(
> + struct device_node *from,
> + const struct of_device_id *matches,
> + const struct of_device_id **match)
> {
> - return false;
> + return NULL;
> }
>
> -/* Kill an unused variable warning on a device_node pointer */
> -static inline void __of_use_dn(const struct device_node *np)
> +static inline struct device_node *of_get_parent(const struct device_node *node)
> {
> + return NULL;
> }
>
> -#define for_each_child_of_node(parent, child) \
> - while (__of_use_dn(parent), __of_use_dn(child), 0)
> +static inline struct device_node *of_get_next_child(
> + const struct device_node *node, struct device_node *prev)
> +{
> + return NULL;
> +}
>
> -#define for_each_available_child_of_node(parent, child) \
> - while (0)
> +static inline struct device_node *of_get_next_available_child(
> + const struct device_node *node, struct device_node *prev)
> +{
> + return NULL;
> +}
>
> -static inline struct device_node *of_get_child_by_name(
> - const struct device_node *node,
> - const char *name)
> +static inline struct device_node *of_find_node_with_property(
> + struct device_node *from, const char *prop_name)
> {
> return NULL;
> }
>
> -static inline int of_get_child_count(const struct device_node *np)
> +static inline bool of_have_populated_dt(void)
> {
> - return 0;
> + return false;
> }
>
> -static inline int of_get_available_child_count(const struct device_node *np)
> +static inline struct device_node *of_get_child_by_name(
> + const struct device_node *node,
> + const char *name)
> {
> - return 0;
> + return NULL;
> }
>
> static inline int of_device_is_compatible(const struct device_node *device,
> @@ -569,6 +528,13 @@ extern int of_node_to_nid(struct device_node *np);
> static inline int of_node_to_nid(struct device_node *device) { return 0; }
> #endif
>
> +static inline struct device_node *of_find_matching_node(
> + struct device_node *from,
> + const struct of_device_id *matches)
> +{
> + return of_find_matching_node_and_match(from, matches, NULL);
> +}
> +
> /**
> * of_property_read_bool - Findfrom a property
> * @np: device node from which the property value is to be read.
> @@ -618,6 +584,55 @@ static inline int of_property_read_u32(const struct device_node *np,
> s; \
> s = of_prop_next_string(prop, s))
>
> +#define for_each_node_by_name(dn, name) \
> + for (dn = of_find_node_by_name(NULL, name); dn; \
> + dn = of_find_node_by_name(dn, name))
> +#define for_each_node_by_type(dn, type) \
> + for (dn = of_find_node_by_type(NULL, type); dn; \
> + dn = of_find_node_by_type(dn, type))
> +#define for_each_compatible_node(dn, type, compatible) \
> + for (dn = of_find_compatible_node(NULL, type, compatible); dn; \
> + dn = of_find_compatible_node(dn, type, compatible))
> +#define for_each_matching_node(dn, matches) \
> + for (dn = of_find_matching_node(NULL, matches); dn; \
> + dn = of_find_matching_node(dn, matches))
> +#define for_each_matching_node_and_match(dn, matches, match) \
> + for (dn = of_find_matching_node_and_match(NULL, matches, match); \
> + dn; dn = of_find_matching_node_and_match(dn, matches, match))
> +
> +#define for_each_child_of_node(parent, child) \
> + for (child = of_get_next_child(parent, NULL); child != NULL; \
> + child = of_get_next_child(parent, child))
> +#define for_each_available_child_of_node(parent, child) \
> + for (child = of_get_next_available_child(parent, NULL); child != NULL; \
> + child = of_get_next_available_child(parent, child))
> +
> +#define for_each_node_with_property(dn, prop_name) \
> + for (dn = of_find_node_with_property(NULL, prop_name); dn; \
> + dn = of_find_node_with_property(dn, prop_name))
> +
> +static inline int of_get_child_count(const struct device_node *np)
> +{
> + struct device_node *child;
> + int num = 0;
> +
> + for_each_child_of_node(np, child)
> + num++;
> +
> + return num;
> +}
> +
> +static inline int of_get_available_child_count(const struct device_node *np)
> +{
> + struct device_node *child;
> + int num = 0;
> +
> + for_each_available_child_of_node(np, child)
> + num++;
> +
> + return num;
> +}
> +
> #if defined(CONFIG_PROC_FS) && defined(CONFIG_PROC_DEVICETREE)
> extern void proc_device_tree_add_node(struct device_node *, struct proc_dir_entry *);
> extern void proc_device_tree_add_prop(struct proc_dir_entry *pde, struct property *prop);
> --
> 1.8.3.2
>
--
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: [RFC] Culling traffic volume on devicetree mailing list
From: Grant Likely @ 2014-02-04 14:08 UTC (permalink / raw)
To: Rob Herring, Ian Campbell
Cc: Olof Johansson,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring
In-Reply-To: <CAL_JsqL7SHFB2Pg6u0+1ZdeDSRaBS5S_=K8gWGcjbq3MpgyvFw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, 23 Jan 2014 08:53:34 -0600, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Thu, Jan 23, 2014 at 5:03 AM, Ian Campbell <Ian.Campbell-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org> wrote:
> > On Wed, 2014-01-22 at 10:35 -0800, Olof Johansson wrote:
> >> > devicetree-spec: For discussing 'core' device tree bindings. ie.
> >> > anything that would be a candidate for putting into an ePAPR type
> >> > spec. Individual device bindings would continue to be posted to
> >> > devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, but anything affecting subsystems or
> >> > generic patterns should be posted to this new list.
> >>
> >> I predict that it will be hard for someone posting a patch to tell if
> >> they should send it to this list or some other list. It might be
> >> convenient for you guys to ignore the high-volume list and just focus
> >> on this one, but for the people who post patches it just makes it more
> >> complicated. IMHO.
> >
> > The issue with the current list is that it is too much of a firehose of
> > Linux patches for other non-Linux consumers of DTB e.g. BSD folks, me
> > with my Xen hat, see [0] for the intersection of those two which
> > prompted me to mention this on the call.
> >
> > The firehose means that these people don't subscribe and therefore lack
> > visibility into what is going on with the core bindings (e.g. BSD seems
> > to have a different binding for gic interrupts, mentioned in the linked
> > thread).
> >
> > I don't think the intention of the split was/should be that "core"
> > Linux/DTB people should only subscribe to -spec@, rather that it be a
> > more targeted list which non-Linux/DTB folks can be involved with to
> > discuss core binding issues and standardisation etc.
> >
> > It seems like devicetree@ would be the right default destination for any
> > patch and so should be what is listed in MAINTAINERS etc.
> >
> > Anyone who is doing actual core/spec work appropriate to -spec@ is
> > either going to be involved enough to know this themselves or can be
> > asked to CC the other list too as part of the first round of review. The
> > number of patches which would need to go to -spec should be a pretty
> > small fraction.
> >
>
> One approach would be to just try to reduce the firehose a bit.
>
> The list gets lots of patches which are not new bindings because we
> trigger on any dts change and any patch with of_get_property or
> of_match_table. I'm guessing the latter was mainly to catch missing
> documentation, but it is clear that we are failing at that as we are
> at about 50% documented compatible strings in a new kernel (hopefully
> my checkpatch addition will improve that).
>
> I think dts files are pretty well reviewed by platform maintainers and
> lots of changes are just new boards using existing bindings. There
> should be little for DT maintainers to review there. This was
> discussed and agreed to at the ARM summit.
>
> So something like this:
Acked-by: Grant Likely <grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
g.
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 6c20792..4e485c0 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6267,8 +6267,6 @@ S: Maintained
> F: drivers/of/
> F: include/linux/of*.h
> F: scripts/dtc/
> -K: of_get_property
> -K: of_match_table
>
> OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
> M: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> @@ -6279,7 +6277,6 @@ M: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> L: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> S: Maintained
> F: Documentation/devicetree/
> -F: arch/*/boot/dts/
> F: include/dt-bindings/
>
> OPENRISC ARCHITECTURE
--
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 2/2] Documentation: devicetree: Add boost-opp binding to list boost mode OPPs
From: Rob Herring @ 2014-02-04 14:02 UTC (permalink / raw)
To: Thomas Abraham
Cc: Nishanth Menon, devicetree@vger.kernel.org, Lukasz Majewski,
linux-samsung-soc@vger.kernel.org, Pawel Moll,
linux-pm@vger.kernel.org, Viresh Kumar, Tomasz Figa, Ian Campbell,
Rafael J. Wysocki, Rob Herring, Kukjin Kim, thomas.ab, Kumar Gala,
Mark Rutland, linux-arm-kernel@lists.infradead.org
In-Reply-To: <1391506890-7335-3-git-send-email-thomas.ab@samsung.com>
On Tue, Feb 4, 2014 at 3:41 AM, Thomas Abraham <ta.omasab@gmail.com> wrote:
> From: Thomas Abraham <thomas.ab@samsung.com>
>
> Certain CPUs or devices can support optional boost operating modes. Add a new
> binding to list OPPs to be additionally made available in boost operating modes.
>
> Cc: Nishanth Menon <nm@ti.com>
> Cc: Lukasz Majewski <l.majewski@samsung.com>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Pawel Moll <pawel.moll@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
> Cc: Kumar Gala <galak@codeaurora.org>
> Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
> ---
> Documentation/devicetree/bindings/power/opp.txt | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/power/opp.txt b/Documentation/devicetree/bindings/power/opp.txt
> index 74499e5..4df5cca 100644
> --- a/Documentation/devicetree/bindings/power/opp.txt
> +++ b/Documentation/devicetree/bindings/power/opp.txt
> @@ -10,6 +10,10 @@ Properties:
> freq: clock frequency in kHz
> vol: voltage in microvolt
>
> +Optional Properties:
> +- boost-opp: Similar to "operating-points" property but usable only in
> + optional boost operating modes.
> +
> Examples:
>
> cpu@0 {
> @@ -22,4 +26,9 @@ cpu@0 {
> 396000 950000
> 198000 850000
> >;
> + boost-opp = <
> + /* kHz uV */
> + 1500000 1350000
> + 1400000 1285000
> + >;
This looks like an example of needing to add more properties to the
OPP table. There are ongoing discussions on how to extend OPP table
and map to C states. This should be part of that discussion.
Rob
^ permalink raw reply
* [PATCH] ARM: dts: i.MX51 babbage: Support diagnostic LED
From: Liu Ying @ 2014-02-04 13:57 UTC (permalink / raw)
To: shawn.guo-QSEj5FYQhm4dnm+yROfE0A
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, kernel-bIcnvbaLZ9MEGnE8C9+IrQ
The D25 LED controlled by gpio on the i.MX51 babbage
board is a diagnostic LED according to the board design.
This patch adds the relevant device tree nodes to the
i.MX51 babbage device tree file to support this LED.
Signed-off-by: Liu Ying <Ying.Liu-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
---
arch/arm/boot/dts/imx51-babbage.dts | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/arch/arm/boot/dts/imx51-babbage.dts b/arch/arm/boot/dts/imx51-babbage.dts
index be1407c..8d6a74b 100644
--- a/arch/arm/boot/dts/imx51-babbage.dts
+++ b/arch/arm/boot/dts/imx51-babbage.dts
@@ -81,6 +81,17 @@
};
};
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&led_pin_gpio2_6>;
+
+ led-diagnostic {
+ label = "diagnostic";
+ gpios = <&gpio2 6 0>;
+ };
+ };
+
sound {
compatible = "fsl,imx51-babbage-sgtl5000",
"fsl,imx-audio-sgtl5000";
@@ -280,6 +291,12 @@
MX51_PAD_CSPI1_RDY__GPIO4_26 0x80000000
>;
};
+
+ led_pin_gpio2_6: led_gpio2_6 {
+ fsl,pins = <
+ MX51_PAD_EIM_D22__GPIO2_6 0x80000000
+ >;
+ };
};
};
--
1.7.9.5
--
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 related
* Re: [PATCH] arm64: Add architecture support for PCI
From: Rob Herring @ 2014-02-04 13:57 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Jason Gunthorpe, devicetree@vger.kernel.org,
linaro-kernel@lists.linaro.org, linux-pci, Liviu Dudau, LKML,
Catalin Marinas, Bjorn Helgaas, LAKML
In-Reply-To: <13031998.NR888KZWhk@wuerfel>
On Tue, Feb 4, 2014 at 3:44 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Monday 03 February 2014 16:31:37 Jason Gunthorpe wrote:
>> Specifying 'use EHCI, AHCI, etc' - which are all PCI based standards
>> without clearly specifying exactly how PCI is suppose to work is
>> completely bonkers.
>>
>> What is needed is a spec that says:
>> 1) Here is how you generate config TLPs. A MMIO region that
>> conforms to the already specified x86 ECAM would
>> be perfect
>> 2) Here is a dword by dword break down of the entire config space in
>> a SOC. Here is where a on-board AHCI controller must show up in
>> config space. Here is how an external PCI-E port must show
>> up. Etc. Most of this is already specified, but it clearly needs
>> to be layed out explicitly for ARM SOCs to actually follow it.
>> 3) Here is how you specify the aperture(s) associated with PCI BAR's
>> and bridge windows in config space. And yes: The CONFIG SPACE
>> BARS MUST WORK.
>> 4) Here is how MSI works, these are the values you put in the
>> address/data and here is how you collect the interrupt.
>> 5) Here is how Legacy INTx must be mapped into the GIC.
>>
>> This is what x86 does, and they have been doing it well for 10
>> years. If you want to play in the server game you have to properly
>> implement PCI.
>
> I'm pretty sure the authors of the SBSA actually thought that was
> what they wrote, by referring to external specifications (pci-3.0,
> ehci, ahci, ...). However, it seems they were either foolish enough
> to believe that hardware designers would follow these specs, or
> they were intentionally misled and got talked into putting ambiguous
> terminology in because there were already hardware designs that
> are not exactly in line with the spirit of the SBSA but can be
> argued to be conforming to the text for a lax interpretation.
>
> I think EHCI is a much better example than PCI here, because the
> spec has exactly one line to say about it, where it spends a whole
> chapter on PCI.
>
> Here is how a sane person would read SBSA to create a compliant
> implementation:
s/sane/software/
>
> I have to use EHCI version 1.1 to provide USB-2.0 support. EHCI
> is a PCI device, so I'll put it behind a PCIe port that complies
> to the PCIe section of the SBSA. Since EHCI by itself only provides
> high-speed USB, and USB-2.0 mandates I provide low-speed and
> full-speed as well, I have to add a USB hub device. It would have
> been easier to just use OHCI for these, but SBSA says I can't.
> Now I want to integrate the EHCI into my SoC and not waste one
> of my precious PCIe root ports, so I have to create another PCI
> domain with its own ECAM compliant config space to put it into.
> Fortunately SBSA lets me add an arbitrary number of PCI domains,
> as long as they are all strictly compliant. To software it will
> look exactly as if it was on an external card, I just have to
> ensure the boot loader correctly sets up the clocks and the phy
> before an SBSA compliant OS gets loaded, all runtime power
> management will get handled through the EHCI-1.1 energy-efficiency
> extensions.
>
> Here is how a crazy person would read the same sentence in the SBSA:
s/crazy/hardware/
>
> I have an IP block that implements the EHCI register set, that
> should be good enough. It's not a fast device, so I can put it
> on a non-coherent bus. Since the SoC will be used for networking,
> I'll put the registers into big-endian configuration to make it
> easier for the OS to access. I'm not allowed to have USB-1.1
> according to SBSA, so I can get away without a hub or an extra
> OHCI. I can't support MSI because it's not a PCI device, and
> the GIC is pretty full, so I'll just connect the IRQ line to
> the GPIO controller. In order to do better power management,
> I'll design a fancy PHY that the device driver will manage
> for implementing autosuspend. I should also give the OS
> fine-grained control over the clocks, but it will have to share
> the clock domain with the other devices on the same edge of the
> chip. The EHCI device is not part of PCI, which measn I don't
> have to use the standard SMMU. However, my EHCI implementation
> can only do 32-bit DMA, and I'll have to design my own IOMMU
> to let it access the entire memory range. USB-OTG is a great
> feature and we already paid for having this in our EHCI
> implementation, better make sure it comes up in endpoint mode
> after waking up from power saving.
My money is on the latter. I think non-PCI implementations of xHCI
interfaces will be common. This was certainly the case at Calxeda in
what was believed to be a SBSA compliant SOC. However, I think PCI
device or not is the least of the issues and all the other examples
you list are the difficult ones to deal with.
Rob
^ permalink raw reply
* Re: [PATCH 0/6] BCM59056 PMU regulator support
From: Lee Jones @ 2014-02-04 13:40 UTC (permalink / raw)
To: Matt Porter
Cc: Wolfram Sang, Tim Kryger, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, Samuel Ortiz, Liam Girdwood, Mark Brown,
Christian Daudt, Devicetree List, Linux I2C List,
Linux ARM Kernel List, Linux Kernel Mailing List
In-Reply-To: <1391516352-32359-1-git-send-email-mporter-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> The BCM59056 is a multi-function power management unit used with the
> BCM281xx family of SoCs. This series adds an MFD and voltage regulator
> driver to support the BCM59056. The bcm28155-ap DT support is updated
> to enable use of regulators on the otg and sdhci peripherals.
>
> Matt Porter (6):
> i2c: bcm-kona: register with subsys_initcall
> regulator: add bcm59056 pmu DT binding
> mfd: add bcm59056 pmu driver
> regulator: add bcm59056 regulator driver
> ARM: configs: bcm_defconfig: enable bcm59056 regulator support
> ARM: dts: add bcm59056 pmu support and enable for bcm28155-ap
>
> .../devicetree/bindings/regulator/bcm59056.txt | 37 ++
> arch/arm/boot/dts/bcm28155-ap.dts | 41 ++
> arch/arm/boot/dts/bcm59056.dtsi | 158 ++++++++
> arch/arm/configs/bcm_defconfig | 7 +
> drivers/i2c/busses/i2c-bcm-kona.c | 14 +-
> drivers/mfd/Kconfig | 8 +
> drivers/mfd/Makefile | 1 +
> drivers/mfd/bcm59056.c | 119 ++++++
> drivers/regulator/Kconfig | 8 +
> drivers/regulator/Makefile | 1 +
> drivers/regulator/bcm59056-regulator.c | 445 +++++++++++++++++++++
> include/linux/mfd/bcm59056.h | 35 ++
> 12 files changed, 873 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/devicetree/bindings/regulator/bcm59056.txt
> create mode 100644 arch/arm/boot/dts/bcm59056.dtsi
> create mode 100644 drivers/mfd/bcm59056.c
> create mode 100644 drivers/regulator/bcm59056-regulator.c
> create mode 100644 include/linux/mfd/bcm59056.h
FYI: Mark's email address is not correct. Not sure where you pulled
this one up from, but he doesn't have access to it anymore.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH 3/6] mfd: add bcm59056 pmu driver
From: Lee Jones @ 2014-02-04 13:29 UTC (permalink / raw)
To: Matt Porter
Cc: Wolfram Sang, Tim Kryger, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, Samuel Ortiz, Liam Girdwood, Mark Brown,
Christian Daudt, Devicetree List, Linux I2C List,
Linux ARM Kernel List, Linux Kernel Mailing List
In-Reply-To: <1391516352-32359-4-git-send-email-mporter@linaro.org>
> Add a driver for the BCM59056 PMU multi-function device. The driver
> initially supports regmap initialization and instantiation of the
> voltage regulator device function of the PMU.
>
> Signed-off-by: Matt Porter <mporter@linaro.org>
> Reviewed-by: Tim Kryger <tim.kryger@linaro.org>
> Reviewed-by: Markus Mayer <markus.mayer@linaro.org>
> ---
> drivers/mfd/Kconfig | 8 +++
> drivers/mfd/Makefile | 1 +
> drivers/mfd/bcm59056.c | 119 +++++++++++++++++++++++++++++++++++++++++++
> include/linux/mfd/bcm59056.h | 35 +++++++++++++
> 4 files changed, 163 insertions(+)
> create mode 100644 drivers/mfd/bcm59056.c
> create mode 100644 include/linux/mfd/bcm59056.h
<snip>
> +static struct mfd_cell bcm59056s[] = {
> + {
> + .name = "bcm59056-pmu",
If you plan to use *->of_node in the PMU driver, which it looks like
you do, you should set the compatible string here.
> + },
> +};
> +
> +static const struct regmap_config bcm59056_regmap_config = {
> + .reg_bits = 8,
> + .val_bits = 8,
> + .max_register = BCM59056_MAX_REGISTER - 1,
If you've just set this manually i.e. it's not part of an enum table,
can't you set it a value you don't need to do math on? It's not used
anywhere else is it?
> + .cache_type = REGCACHE_RBTREE,
> +};
> +
> +static int bcm59056_i2c_probe(struct i2c_client *i2c,
> + const struct i2c_device_id *id)
> +{
> + struct bcm59056 *bcm59056;
> + int chip_id = id->driver_data;
I thought this was a DT only driver? If so, you probably want to use
of_match_device() instead.
> + int ret = 0;
> +
> + bcm59056 = devm_kzalloc(&i2c->dev, sizeof(*bcm59056), GFP_KERNEL);
> + if (!bcm59056)
> + return -ENOMEM;
> +
> + i2c_set_clientdata(i2c, bcm59056);
> + bcm59056->dev = &i2c->dev;
> + bcm59056->i2c_client = i2c;
> + bcm59056->id = chip_id;
> +
> + bcm59056->regmap = devm_regmap_init_i2c(i2c, &bcm59056_regmap_config);
> + if (IS_ERR(bcm59056->regmap)) {
> + ret = PTR_ERR(bcm59056->regmap);
> + dev_err(&i2c->dev, "regmap initialization failed: %d\n", ret);
> + return ret;
> + }
> +
> + ret = mfd_add_devices(bcm59056->dev, -1,
> + bcm59056s, ARRAY_SIZE(bcm59056s),
> + NULL, 0, NULL);
Are you sure you need all of your #includes?
I notice that irqdomain is there, but you don't actually have one?
> + if (ret < 0)
> + dev_err(&i2c->dev, "mfd_add_devices failed: %d\n", ret);
What if we change the name of the function? Probably better to say
something like "device registration failed" or thelike.
> + return ret;
> +}
> +
> +static int bcm59056_i2c_remove(struct i2c_client *i2c)
> +{
> + struct bcm59056 *bcm59056 = i2c_get_clientdata(i2c);
> +
> + mfd_remove_devices(bcm59056->dev);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id bcm59056_of_match[] = {
> + { .compatible = "brcm,bcm59056", .data = (void *)BCM59056 },
You've gone to the trouble of setting a device version here, but you
don't seem to use it?
> + { }
> +};
> +
> +static const struct i2c_device_id bcm59056_i2c_id[] = {
> + { "bcm59056", BCM59056 },
> + { }
> +};
Ah, I guess this is where id->driver comes from.
It's pretty silly that the I2C subsystem demands the presence of this
table, despite not using it if an of_device_id table is present.
> +MODULE_DEVICE_TABLE(i2c, bcm59056_i2c_id);
> +
> +static struct i2c_driver bcm59056_i2c_driver = {
> + .driver = {
> + .name = "bcm59056",
> + .owner = THIS_MODULE,
> + .of_match_table = of_match_ptr(bcm59056_of_match),
No need to use of_match_ptr() here.
> + },
> + .probe = bcm59056_i2c_probe,
> + .remove = bcm59056_i2c_remove,
> + .id_table = bcm59056_i2c_id,
*grumble*
> +};
> +
> +static int __init bcm59056_init(void)
> +{
> + return i2c_add_driver(&bcm59056_i2c_driver);
> +}
> +subsys_initcall(bcm59056_init);
Really? :(
Maybe you'll want to comment this, in case people do not know the back
ground and attempts to clean it up.
> +static void __exit bcm59056_exit(void)
> +{
> + i2c_del_driver(&bcm59056_i2c_driver);
> +}
> +module_exit(bcm59056_exit);
<snip>
> +/* chip id */
> +#define BCM59056 0
Lonely, oh so lonely!
> +/* max register address */
> +#define BCM59056_MAX_REGISTER 0xe8
Don't you have a table of registers which you care about?
> +/* bcm59056 chip access */
Superfluous comment? Don't we all know what these containers do?
> +struct bcm59056 {
> + struct device *dev;
> + struct i2c_client *i2c_client;
> + struct regmap *regmap;
> + unsigned int id;
> +};
> +
> +#endif /* __LINUX_MFD_BCM59056_H */
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH] arm64: Add architecture support for PCI
From: Andrew Murray @ 2014-02-04 13:23 UTC (permalink / raw)
To: Andrew Murray, linux-pci, Bjorn Helgaas, Catalin Marinas,
Will Deacon, LKML, devicetree@vger.kernel.org, LAKML,
linaro-kernel, Arnd Bergmann
In-Reply-To: <20140204122951.GC27975@e106497-lin.cambridge.arm.com>
On 4 February 2014 12:29, Liviu Dudau <Liviu.Dudau@arm.com> wrote:
> On Mon, Feb 03, 2014 at 10:34:40PM +0000, Andrew Murray wrote:
>> On 3 February 2014 18:43, Liviu Dudau <Liviu.Dudau@arm.com> wrote:
>> > diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
>> > index 4cc813e..ce5bad2 100644
>> > --- a/arch/arm64/include/asm/io.h
>> > +++ b/arch/arm64/include/asm/io.h
>> > @@ -120,9 +120,13 @@ static inline u64 __raw_readq(const volatile void __iomem *addr)
>> > /*
>> > * I/O port access primitives.
>> > */
>> > +#define arch_has_dev_port() (0)
>> > #define IO_SPACE_LIMIT 0xffff
>> > #define PCI_IOBASE ((void __iomem *)(MODULES_VADDR - SZ_2M))
>> >
>> > +#define ioport_map(port, nr) (PCI_IOBASE + ((port) & IO_SPACE_LIMIT))
>> > +#define ioport_unmap(addr)
>>
>> I'm not sure that this will work. The in[bwl], out[bwl] macros in
>> arch/arm64/include/asm/io.h already add the PCI_IOBASE offset.
>>
>> Instead of these two #defines, why not just enforce that
>> GENERIC_PCI_IOMAP is enabled? Or at least wrap these defines with 'if
>> (!config_enabled(CONFIG_GENERIC_PCI_IOMAP))' or similar.
>
> GENERIC_PCI_IOMAP *is* enabled for AArch64. We have select GENERIC_IOMAP in
> arch/arm64/Kconfig which in turn selects GENERIC_PCI_IOMAP in lib/Kconfig.
Sorry, it was intent to suggest using the ioport_[map|unmap] functions
in lib/iomap.c instead of defining something similar here. I guess you
will also need to also define CONFIG_HAS_IOPORT for this to happen.
Andrew Murray
>
> Best regards,
> Liviu
>
>>
>> > +
>> > static inline u8 inb(unsigned long addr)
>> > {
>> > return readb(addr + PCI_IOBASE);
>>
>>
>> Andrew Murray
>>
>
> --
> ====================
> | I would like to |
> | fix the world, |
> | but they're not |
> | giving me the |
> \ source code! /
> ---------------
> ¯\_(ツ)_/¯
>
> -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
>
> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590
> ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
>
^ permalink raw reply
* Re: [PATCH v2 3/5] char: ti-usim: Add driver for USIM module on AM43xx
From: Roger Quadros @ 2014-02-04 13:19 UTC (permalink / raw)
To: Satish Patel, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
rob-VoJi6FS/r0vR7s880joybQ
In-Reply-To: <1390192434-19386-4-git-send-email-satish.patel-l0cyMroinI0@public.gmane.org>
Hi Satish,
On 01/20/2014 06:33 AM, Satish Patel wrote:
> TI-USIM driver is a platform driver that provides a character
> driver interface to user applications.
>
> It allows user applications to call IOCTL's to
> perform smart card operations.
>
> Driver currently supports
> - ATR
> - T=0 & T=1 protocol
> - clock stop mode
> - smart card clock configuration
> - Tx/Rx application data units (APDU) to smart card
> - Interface to PHY using DT & phy interface
>
> Validation is done with ACOS3 smart cards
>
> Signed-off-by: Satish Patel <satish.patel-l0cyMroinI0@public.gmane.org>
> ---
> .../devicetree/bindings/ti-usim/ti-usim.txt | 31 +
> drivers/char/Kconfig | 7 +
> drivers/char/Makefile | 1 +
> drivers/char/ti-usim-hw.h | 863 +++++++++
> drivers/char/ti-usim.c | 1859 ++++++++++++++++++++
ti-usim.c is a very large driver that does everything but looks like limited to TI hardware.
How about splitting it into generic stuff and hw specific glue logic so that most of the generic stuff
could be used by different hardware types.
> include/linux/ti-usim.h | 98 +
> 6 files changed, 2859 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/ti-usim/ti-usim.txt
> create mode 100644 drivers/char/ti-usim-hw.h
> create mode 100644 drivers/char/ti-usim.c
> create mode 100644 include/linux/ti-usim.h
>
cheers,
-roger
--
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 v8 0/3] mmc: sdhci-msm: Add support for Qualcomm chipsets
From: Christopher Covington @ 2014-02-04 13:19 UTC (permalink / raw)
To: Georgi Djakov
Cc: linux-mmc, cjb, devicetree, grant.likely, rob.herring, pawel.moll,
mark.rutland, swarren, ijc+devicetree, galak, rob, linux-doc,
linux-kernel, linux-arm-msm
In-Reply-To: <1391107507-17321-1-git-send-email-gdjakov@mm-sol.com>
Hi Georgi,
On 01/30/2014 01:45 PM, Georgi Djakov wrote:
> This patchset adds basic support of the Secure Digital Host Controller
> Interface compliant controller found in Qualcomm chipsets.
>
> Tested with eMMC and various micro SD cards on APQ8074 Dragonboard.
[...]
> .../devicetree/bindings/mmc/sdhci-msm.txt | 83 ++
> drivers/mmc/host/Kconfig | 13 +
> drivers/mmc/host/Makefile | 1 +
> drivers/mmc/host/sdhci-msm.c | 938 ++++++++++++++++++++
> 4 files changed, 1035 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mmc/sdhci-msm.txt
> create mode 100644 drivers/mmc/host/sdhci-msm.c
You must have added entries to the Dragonboard device tree source to test
these changes. Why not include them with this patchset? Is there a stand-alone
patch that I've overlooked?
Thanks,
Christopher
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.
^ permalink raw reply
* Re: [PATCH] ARM: dts: omap3-ldp: fix mmc configuration
From: Balaji T K @ 2014-02-04 12:46 UTC (permalink / raw)
To: Nishanth Menon
Cc: Benoît Cousson, Tony Lindgren, devicetree, linux-omap,
linux-arm-kernel
In-Reply-To: <1390260873-22354-1-git-send-email-nm@ti.com>
On Tuesday 21 January 2014 05:04 AM, Nishanth Menon wrote:
> MMC1 is the only MMC interface available on the platform. Further,
> since the platform is based on older revision of SoC which is not
> capable of doing multi-block writes, mark it so and add pinmux
s/writes/read
Thanks and Regards,
Balaji T K
> to ensure that all relevant pins are configured for non-MMC boot
> mode.
>
> Signed-off-by: Nishanth Menon <nm@ti.com>
> ---
> ti,erratum-2.1.1.128 introduced in https://patchwork.kernel.org/patch/3514851/
> hence depends on the same.
> arch/arm/boot/dts/omap3-ldp.dts | 22 ++++++++++++++++++++++
> 1 file changed, 22 insertions(+)
>
> diff --git a/arch/arm/boot/dts/omap3-ldp.dts b/arch/arm/boot/dts/omap3-ldp.dts
> index ddce0d8..bc0cc66 100644
> --- a/arch/arm/boot/dts/omap3-ldp.dts
> +++ b/arch/arm/boot/dts/omap3-ldp.dts
> @@ -176,6 +176,17 @@
> &mmc1 {
> vmmc-supply = <&vmmc1>;
> bus-width = <4>;
> + ti,erratum-2.1.1.128;
> + pinctrl-names = "default";
> + pinctrl-0 = <&mmc1_pins>;
> +};
> +
> +&mmc2 {
> + status="disabled";
> +};
> +
> +&mmc3 {
> + status="disabled";
> };
>
> &omap3_pmx_core {
> @@ -209,6 +220,17 @@
> 0x174 (PIN_OUTPUT | MUX_MODE0) /* hsusb0_stp.hsusb0_stp */
> >;
> };
> +
> + mmc1_pins: pinmux_mmc1_pins {
> + pinctrl-single,pins = <
> + OMAP3_CORE1_IOPAD(0x2144, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_clk.mmc1_clk */
> + OMAP3_CORE1_IOPAD(0x2146, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_cmd.mmc1_cmd */
> + OMAP3_CORE1_IOPAD(0x2148, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat0.mmc1_dat0 */
> + OMAP3_CORE1_IOPAD(0x214A, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat1.mmc1_dat1 */
> + OMAP3_CORE1_IOPAD(0x214C, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat2.mmc1_dat2 */
> + OMAP3_CORE1_IOPAD(0x214e, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat3.mmc1_dat3 */
> + >;
> + };
> };
>
> &usb_otg_hs {
>
^ permalink raw reply
* Re: [PATCH] mmc: omap_hsmmc: Add support for Erratum 2.1.1.128 in device tree boot
From: Balaji T K @ 2014-02-04 12:44 UTC (permalink / raw)
To: Nishanth Menon
Cc: Chris Ball, Tony Lindgren, devicetree, linux-mmc, linux-omap,
linux-arm-kernel
In-Reply-To: <1390260542-22213-1-git-send-email-nm@ti.com>
On Tuesday 21 January 2014 04:59 AM, Nishanth Menon wrote:
> 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.
>
> Handle this by providing a boolean flag to indicate to driver that it is
> working on a hardware with mentioned limitation.
>
> Signed-off-by: Nishanth Menon <nm@ti.com>
> ---
>
> This explains the logs I see:
> OMAP3430 LDP (ES2.2):
> uImage only boot: http://slexy.org/raw/s2YrbMAi7c
> uImage+dtb concatenated boot: http://slexy.org/raw/s20qVg17T0
>
> With the following flag set, device is now able to consistently boot with
> device tree supported uImage+dtb concat boot.
>
> .../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 2 ++
> drivers/mmc/host/omap_hsmmc.c | 3 +++
> 2 files changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
> index 8c8908a..ab36f8b 100644
> --- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
> +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
> @@ -26,6 +26,8 @@ specifier is required.
> dma-names: List of DMA request names. These strings correspond
> 1:1 with the DMA specifiers listed in dmas. The string naming is
> to be "rx" and "tx" for RX and TX DMA requests, respectively.
> +ti,erratum-2.1.1.128: boolean, for OMAP3430/OMAP35xx platforms with broken
> +multiblock reads
Rather than ti,errata.. specific property, something like
caps no/disable multiblock read is more readable in my opinion, Otherwise
Acked-by: Balaji T K <balajitk@ti.com>
>
> Examples:
>
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index 014bfe5..f2d5940 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -1730,6 +1730,9 @@ static struct omap_mmc_platform_data *of_get_hsmmc_pdata(struct device *dev)
> if (of_find_property(np, "ti,dual-volt", NULL))
> pdata->controller_flags |= OMAP_HSMMC_SUPPORTS_DUAL_VOLT;
>
> + if (of_find_property(np, "ti,erratum-2.1.1.128", NULL))
> + pdata->controller_flags |= OMAP_HSMMC_BROKEN_MULTIBLOCK_READ;
> +
> /* This driver only supports 1 slot */
> pdata->nr_slots = 1;
> pdata->slots[0].switch_pin = cd_gpio;
>
^ permalink raw reply
* [PATCH] kbuild: dtbs_install: new make target
From: Grant Likely @ 2014-02-04 12:41 UTC (permalink / raw)
To: devicetree, linux-kernel, linux-kbuild
Cc: Jason Cooper, Grant Likely, Michal Marek, Russell King,
Rob Herring
In-Reply-To: <20140110182923.GM19878@titan.lakedaemon.net>
From: Jason Cooper <jason@lakedaemon.net>
Unlike other build products in the Linux kernel, there is no 'make
*install' mechanism to put devicetree blobs in a standard place.
This commit adds a new 'dtbs_install' make target which copies all of
the dtbs into the INSTALL_DTBS_PATH directory. INSTALL_DTBS_PATH can be
set before calling make to change the default install directory. If not
set then it defaults to:
$INSTALL_PATH/dtbs/$KERNELRELEASE.
This is done to keep dtbs from different kernel versions separate until
things have settled down. Once the dtbs are stable, and not so strongly
linked to the kernel version, the devicetree files will most likely move
to their own repo. Users will need to upgrade install scripts at that
time.
v7: (reworked by Grant Likely)
- Moved rules from arch/arm/Makefile to arch/arm/boot/dts/Makefile so
that each dtb install could have a separate target and be reported as
part of the make output.
- Fixed dependency problem to ensure $KERNELRELEASE is calculated before
attempting to install
- Removed option to call external script. Copying the files should be
sufficient and a build system can post-process the install directory.
Despite the fact an external script is used for installing the kernel,
I don't think that is a pattern that should be encouraged. I would
rather see buildroot type tools post process the install directory to
rename or move dtb files after installing to a staging directory.
- Plus it is easy to add a hook after the fact without blocking the
rest of this feature.
- Move the helper targets into scripts/Makefile.lib with the rest of the
common dtb rules
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Grant Likely <grant.likely@linaro.org>
Cc: Michal Marek <mmarek@suse.cz>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Rob Herring <robh+dt@kernel.org>
---
Makefile | 7 +++++++
arch/arm/Makefile | 7 ++++---
arch/arm/boot/dts/Makefile | 4 +++-
scripts/Makefile.lib | 12 ++++++++++++
4 files changed, 26 insertions(+), 4 deletions(-)
diff --git a/Makefile b/Makefile
index 606ef7c4a544..90556da6959d 100644
--- a/Makefile
+++ b/Makefile
@@ -727,6 +727,13 @@ export KBUILD_IMAGE ?= vmlinux
export INSTALL_PATH ?= /boot
#
+# INSTALL_DTBS_PATH specifies a prefix for relocations required by build roots.
+# Like INSTALL_MOD_PATH, it isn't defined in the Makefile, but can be passed as
+# an argument if needed. Otherwise it defaults to the kernel install path
+#
+export INSTALL_DTBS_PATH ?= $(INSTALL_PATH)/dtbs/$(KERNELRELEASE)
+
+#
# INSTALL_MOD_PATH specifies a prefix to MODLIB for module directory
# relocations required by build roots. This is not defined in the
# makefile but the argument can be passed to make if needed.
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 08a9ef58d9c3..fddf4beaee45 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -310,9 +310,9 @@ $(INSTALL_TARGETS):
%.dtb: | scripts
$(Q)$(MAKE) $(build)=$(boot)/dts MACHINE=$(MACHINE) $(boot)/dts/$@
-PHONY += dtbs
-dtbs: scripts
- $(Q)$(MAKE) $(build)=$(boot)/dts MACHINE=$(MACHINE) dtbs
+PHONY += dtbs dtbs_install
+dtbs dtbs_install: prepare scripts
+ $(Q)$(MAKE) $(build)=$(boot)/dts MACHINE=$(MACHINE) $@
# We use MRPROPER_FILES and CLEAN_FILES now
archclean:
@@ -331,6 +331,7 @@ define archhelp
echo ' bootpImage - Combined zImage and initial RAM disk'
echo ' (supply initrd image via make variable INITRD=<path>)'
echo '* dtbs - Build device tree blobs for enabled boards'
+ echo ' dtbs_install - Install dtbs to $(INSTALL_DTBS_PATH)'
echo ' install - Install uncompressed kernel'
echo ' zinstall - Install compressed kernel'
echo ' uinstall - Install U-Boot wrapped compressed kernel'
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index b9d6a8b485e0..649c8e345ac5 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -321,7 +321,7 @@ dtb-$(CONFIG_ARCH_ZYNQ) += zynq-zc702.dtb \
zynq-zc706.dtb \
zynq-zed.dtb
-targets += dtbs
+targets += dtbs dtbs_install
targets += $(dtb-y)
endif
@@ -331,3 +331,5 @@ dtbs: $(addprefix $(obj)/, $(dtb-y))
$(Q)rm -f $(obj)/../*.dtb
clean-files := *.dtb
+
+dtbs_install: $(addsuffix _dtbinst_, $(dtb-y))
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 49392ecbef17..d0c17a55a2f5 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -273,6 +273,18 @@ $(obj)/%.dtb: $(src)/%.dts FORCE
dtc-tmp = $(subst $(comma),_,$(dot-target).dts.tmp)
+# Helper targets for Installing DTBs into the boot directory
+quiet_cmd_dtb_install = INSTALL $<
+ cmd_dtb_install = cp $< $(2)
+
+_dtbinst_pre_:
+ $(Q)if [ -d $(INSTALL_DTBS_PATH).old ]; then rm -rf $(INSTALL_DTBS_PATH).old; fi
+ $(Q)if [ -d $(INSTALL_DTBS_PATH) ]; then mv $(INSTALL_DTBS_PATH) $(INSTALL_DTBS_PATH).old; fi
+ $(Q)mkdir -p $(INSTALL_DTBS_PATH)
+
+%.dtb_dtbinst_: $(obj)/%.dtb _dtbinst_pre_
+ $(call cmd,dtb_install,$(INSTALL_DTBS_PATH))
+
# Bzip2
# ---------------------------------------------------------------------------
--
1.8.3.2
^ permalink raw reply related
* Re: [PATCH V6] kbuild: dtbs_install: new make target
From: Grant Likely @ 2014-02-04 12:40 UTC (permalink / raw)
To: Jason Cooper, Rob Herring, Pawel Moll, Mark Rutland,
Stephen Warren, Ian Campbell, Olof Johansson
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20140110182923.GM19878-u4khhh1J0LxI1Ri9qeTfzeTW4wlIGRCZ@public.gmane.org>
On Fri, 10 Jan 2014 13:29:23 -0500, Jason Cooper <jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org> wrote:
> Grant,
>
> On Sun, Dec 01, 2013 at 11:56:28PM +0000, Jason Cooper wrote:
> > Unlike other build products in the Linux kernel, there is no 'make
> > *install' mechanism to put devicetree blobs in a standard place.
> >
> > This patch is an attempt to fix this problem. Akin to 'make install',
> > this creates a new make target, dtbs_install. The script that gets
> > called defers to a distribution or user supplied installdtbs binary,
> > if found in the system. Otherwise, the default action is to install the
> > built dtbs into
> >
> > /lib/devicetrees/${kernel_version}/${dts_filename}.dtb
> >
> > This is done to keep dtbs from different kernel versions separate until
> > things have settled down. Once the dtbs are stable, and not so strongly
> > linked to the kernel version, the devicetree files will most likely move
> > to their own repo. Users will need to upgrade install scripts at that
> > time.
> >
> > /lib has been selected over /boot since /boot is often a FAT filesystem
> > and a majority of the dts filenames are longer than 8+3.
> >
> > Signed-off-by: Jason Cooper <jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org>
> > ---
>
> Is this good to go?
I took another look at it and did some rework. It bothered my that the
install script didnt' have any knowledge of the actual build targets and
just blindly copied the files it finds. I've reworked the patch to make
each file a separate target and also fixed a few bugs in the process.
I also removed the call out to an external script. I'm not convinced a
call out hook is the best approach when a buildroot tool can post
process the install directory. It wouldn't be hard to add back in, but I
don't want it to block this feature. I'll post my version in a minute.
g.
--
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] arm64: Add architecture support for PCI
From: Liviu Dudau @ 2014-02-04 12:29 UTC (permalink / raw)
To: Andrew Murray
Cc: linux-pci, Bjorn Helgaas, Catalin Marinas, Will Deacon, LKML,
devicetree@vger.kernel.org, LAKML, linaro-kernel, Arnd Bergmann
In-Reply-To: <CAPcvp5EF_=G=VwWLfbw6mwczErTHeq4AbVALYpuAzb3c5eb2rA@mail.gmail.com>
On Mon, Feb 03, 2014 at 10:34:40PM +0000, Andrew Murray wrote:
> On 3 February 2014 18:43, Liviu Dudau <Liviu.Dudau@arm.com> wrote:
> > diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
> > index 4cc813e..ce5bad2 100644
> > --- a/arch/arm64/include/asm/io.h
> > +++ b/arch/arm64/include/asm/io.h
> > @@ -120,9 +120,13 @@ static inline u64 __raw_readq(const volatile void __iomem *addr)
> > /*
> > * I/O port access primitives.
> > */
> > +#define arch_has_dev_port() (0)
> > #define IO_SPACE_LIMIT 0xffff
> > #define PCI_IOBASE ((void __iomem *)(MODULES_VADDR - SZ_2M))
> >
> > +#define ioport_map(port, nr) (PCI_IOBASE + ((port) & IO_SPACE_LIMIT))
> > +#define ioport_unmap(addr)
>
> I'm not sure that this will work. The in[bwl], out[bwl] macros in
> arch/arm64/include/asm/io.h already add the PCI_IOBASE offset.
>
> Instead of these two #defines, why not just enforce that
> GENERIC_PCI_IOMAP is enabled? Or at least wrap these defines with 'if
> (!config_enabled(CONFIG_GENERIC_PCI_IOMAP))' or similar.
GENERIC_PCI_IOMAP *is* enabled for AArch64. We have select GENERIC_IOMAP in
arch/arm64/Kconfig which in turn selects GENERIC_PCI_IOMAP in lib/Kconfig.
Best regards,
Liviu
>
> > +
> > static inline u8 inb(unsigned long addr)
> > {
> > return readb(addr + PCI_IOBASE);
>
>
> Andrew Murray
>
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
¯\_(ツ)_/¯
^ permalink raw reply
* [PATCH 6/6] ARM: dts: add bcm59056 pmu support and enable for bcm28155-ap
From: Matt Porter @ 2014-02-04 12:19 UTC (permalink / raw)
To: Wolfram Sang, Tim Kryger, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, Samuel Ortiz, Lee Jones, Liam Girdwood,
Mark Brown, Christian Daudt
Cc: Devicetree List, Linux I2C List, Linux ARM Kernel List,
Linux Kernel Mailing List
In-Reply-To: <1391516352-32359-1-git-send-email-mporter@linaro.org>
Add a dtsi to support the BCM59056 PMU used by the BCM281xx family
of SoCs. Enable regulators for use with the dwc2 and sdhci on
bcm28155-ap.
Signed-off-by: Tim Kryger <tim.kryger@linaro.org>
Signed-off-by: Matt Porter <mporter@linaro.org>
Reviewed-by: Markus Mayer <markus.mayer@linaro.org>
---
arch/arm/boot/dts/bcm28155-ap.dts | 41 ++++++++++
arch/arm/boot/dts/bcm59056.dtsi | 158 ++++++++++++++++++++++++++++++++++++++
2 files changed, 199 insertions(+)
create mode 100644 arch/arm/boot/dts/bcm59056.dtsi
diff --git a/arch/arm/boot/dts/bcm28155-ap.dts b/arch/arm/boot/dts/bcm28155-ap.dts
index 5ff2382..1240f42 100644
--- a/arch/arm/boot/dts/bcm28155-ap.dts
+++ b/arch/arm/boot/dts/bcm28155-ap.dts
@@ -47,6 +47,10 @@
i2c@3500d000 {
status="okay";
clock-frequency = <400000>;
+
+ pmu: pmu@8 {
+ reg = <0x08>;
+ };
};
sdio1: sdio@3f180000 {
@@ -57,16 +61,22 @@
sdio2: sdio@3f190000 {
non-removable;
max-frequency = <48000000>;
+ vmmc-supply = <&camldo1_reg>;
+ vqmmc-supply = <&iosr1_reg>;
status = "okay";
};
sdio4: sdio@3f1b0000 {
max-frequency = <48000000>;
cd-gpios = <&gpio 14 GPIO_ACTIVE_LOW>;
+ vmmc-supply = <&sdldo_reg>;
+ vqmmc-supply = <&sdxldo_reg>;
status = "okay";
};
usbotg: usb@3f120000 {
+ vusb_d-supply = <&usbldo_reg>;
+ vusb_a-supply = <&iosr1_reg>;
status = "okay";
};
@@ -74,3 +84,34 @@
status = "okay";
};
};
+
+#include "bcm59056.dtsi"
+
+&pmu {
+ interrupts = <GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH>;
+ status = "okay";
+
+ regulators {
+ camldo1_reg: regulator@1 {
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ sdldo_reg: regulator@5 {
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ };
+
+ usbldo_reg: regulator@11 {
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ iosr1_reg: regulator@14 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/bcm59056.dtsi b/arch/arm/boot/dts/bcm59056.dtsi
new file mode 100644
index 0000000..08ea3da
--- /dev/null
+++ b/arch/arm/boot/dts/bcm59056.dtsi
@@ -0,0 +1,158 @@
+/*
+ * Copyright 2014 Linaro Limited
+ * Author: Matt Porter <mporter@linaro.org>
+ *
+ * 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; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+&pmu {
+ compatible = "brcm,bcm59056";
+
+ regulators {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ rfldo_reg: regulator@0 {
+ reg = <0>;
+ regulator-compatible = "rfldo";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ camldo1_reg: regulator@1 {
+ reg = <1>;
+ regulator-compatible = "camldo1";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ camldo2_reg: regulator@2 {
+ reg = <2>;
+ regulator-compatible = "camldo2";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ simldo1_reg: regulator@3 {
+ reg = <3>;
+ regulator-compatible = "simldo1";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ simldo2_reg: regulator@4 {
+ reg = <4>;
+ regulator-compatible = "simldo2";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ sdldo_reg: regulator@5 {
+ reg = <5>;
+ regulator-compatible = "sdldo";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ sdxldo_reg: regulator@6 {
+ reg = <6>;
+ regulator-compatible = "sdxldo";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ mmcldo1_reg: regulator@7 {
+ reg = <7>;
+ regulator-compatible = "mmcldo1";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ mmcldo2_reg: regulator@8 {
+ reg = <8>;
+ regulator-compatible = "mmcldo2";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ audldo_reg: regulator@9 {
+ reg = <9>;
+ regulator-compatible = "audldo";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ micldo_reg: regulator@10 {
+ reg = <10>;
+ regulator-compatible = "micldo";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ usbldo_reg: regulator@11 {
+ reg = <11>;
+ regulator-compatible = "usbldo";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ vibldo_reg: regulator@12 {
+ reg = <12>;
+ regulator-compatible = "vibldo";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ csr_reg: regulator@13 {
+ reg = <13>;
+ regulator-compatible = "csr";
+ regulator-min-microvolt = <860000>;
+ regulator-max-microvolt = <1440000>;
+ };
+
+ iosr1_reg: regulator@14 {
+ reg = <14>;
+ regulator-compatible = "iosr1";
+ regulator-min-microvolt = <860000>;
+ regulator-max-microvolt = <1800000>;
+ };
+
+ iosr2_reg: regulator@15 {
+ reg = <15>;
+ regulator-compatible = "iosr2";
+ regulator-min-microvolt = <860000>;
+ regulator-max-microvolt = <1800000>;
+ };
+
+ msr_reg: regulator@16 {
+ reg = <16>;
+ regulator-compatible = "msr";
+ regulator-min-microvolt = <860000>;
+ regulator-max-microvolt = <1800000>;
+ };
+
+ sdsr1_reg: regulator@17 {
+ reg = <17>;
+ regulator-compatible = "sdsr1";
+ regulator-min-microvolt = <860000>;
+ regulator-max-microvolt = <1340000>;
+ };
+
+ sdsr2_reg: regulator@18 {
+ reg = <18>;
+ regulator-compatible = "sdsr2";
+ regulator-min-microvolt = <860000>;
+ regulator-max-microvolt = <1800000>;
+ };
+
+ vsr_reg: regulator@19 {
+ reg = <19>;
+ regulator-compatible = "vsr";
+ regulator-min-microvolt = <860000>;
+ regulator-max-microvolt = <1800000>;
+ };
+ };
+};
--
1.8.4
^ permalink raw reply related
* [PATCH 5/6] ARM: configs: bcm_defconfig: enable bcm59056 regulator support
From: Matt Porter @ 2014-02-04 12:19 UTC (permalink / raw)
To: Wolfram Sang, Tim Kryger, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, Samuel Ortiz, Lee Jones, Liam Girdwood,
Mark Brown, Christian Daudt
Cc: Devicetree List, Linux I2C List, Linux ARM Kernel List,
Linux Kernel Mailing List
In-Reply-To: <1391516352-32359-1-git-send-email-mporter-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Enable BCM59056 MFD and regulator drivers to manage voltage
regulators on BCM281xx platforms.
Signed-off-by: Tim Kryger <tim.kryger-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Signed-off-by: Matt Porter <mporter-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Reviewed-by: Markus Mayer <markus.mayer-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
arch/arm/configs/bcm_defconfig | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/configs/bcm_defconfig b/arch/arm/configs/bcm_defconfig
index 2519d6d..35752cc 100644
--- a/arch/arm/configs/bcm_defconfig
+++ b/arch/arm/configs/bcm_defconfig
@@ -79,6 +79,13 @@ CONFIG_HW_RANDOM=y
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=y
# CONFIG_HWMON is not set
+CONFIG_MFD_BCM59056=y
+CONFIG_REGULATOR=y
+CONFIG_REGULATOR_FIXED_VOLTAGE=y
+CONFIG_REGULATOR_VIRTUAL_CONSUMER=y
+CONFIG_REGULATOR_USERSPACE_CONSUMER=y
+CONFIG_REGULATOR_BCM59056=y
+
CONFIG_VIDEO_OUTPUT_CONTROL=y
CONFIG_FB=y
CONFIG_BACKLIGHT_LCD_SUPPORT=y
--
1.8.4
--
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 related
* [PATCH 4/6] regulator: add bcm59056 regulator driver
From: Matt Porter @ 2014-02-04 12:19 UTC (permalink / raw)
To: Wolfram Sang, Tim Kryger, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, Samuel Ortiz, Lee Jones, Liam Girdwood,
Mark Brown, Christian Daudt
Cc: Devicetree List, Linux I2C List, Linux ARM Kernel List,
Linux Kernel Mailing List
In-Reply-To: <1391516352-32359-1-git-send-email-mporter@linaro.org>
Add a regulator driver for the BCM59056 PMU voltage regulators.
The driver supports LDOs and DCDCs in normal mode only. There is
no support for low-power mode or power sequencing.
Signed-off-by: Matt Porter <mporter@linaro.org>
Reviewed-by: Tim Kryger <tim.kryger@linaro.org>
Reviewed-by: Markus Mayer <markus.mayer@linaro.org>
---
drivers/regulator/Kconfig | 8 +
drivers/regulator/Makefile | 1 +
drivers/regulator/bcm59056-regulator.c | 445 +++++++++++++++++++++++++++++++++
3 files changed, 454 insertions(+)
create mode 100644 drivers/regulator/bcm59056-regulator.c
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 6a79328..e09c9ea5 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -139,6 +139,14 @@ config REGULATOR_AS3722
AS3722 PMIC. This will enable support for all the software
controllable DCDC/LDO regulators.
+config REGULATOR_BCM59056
+ tristate "Broadcom BCM59056 PMU Regulators"
+ depends on MFD_BCM59056
+ help
+ This driver provides support for the voltage regulators on the
+ BCM59056 PMU. This will enable support for the software
+ controllable LDO/Switching regulators.
+
config REGULATOR_DA903X
tristate "Dialog Semiconductor DA9030/DA9034 regulators"
depends on PMIC_DA903X
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 979f9dd..bb65035 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_REGULATOR_ANATOP) += anatop-regulator.o
obj-$(CONFIG_REGULATOR_ARIZONA) += arizona-micsupp.o arizona-ldo1.o
obj-$(CONFIG_REGULATOR_AS3711) += as3711-regulator.o
obj-$(CONFIG_REGULATOR_AS3722) += as3722-regulator.o
+obj-$(CONFIG_REGULATOR_BCM59056) += bcm59056-regulator.o
obj-$(CONFIG_REGULATOR_DA903X) += da903x.o
obj-$(CONFIG_REGULATOR_DA9052) += da9052-regulator.o
obj-$(CONFIG_REGULATOR_DA9055) += da9055-regulator.o
diff --git a/drivers/regulator/bcm59056-regulator.c b/drivers/regulator/bcm59056-regulator.c
new file mode 100644
index 0000000..3fbc1d5
--- /dev/null
+++ b/drivers/regulator/bcm59056-regulator.c
@@ -0,0 +1,445 @@
+/*
+ * Broadcom BCM59056 regulator driver
+ *
+ * Copyright 2014 Linaro Limited
+ * Author: Matt Porter <mporter@linaro.org>
+ *
+ * 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; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include <linux/err.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/mfd/bcm59056.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/regulator/driver.h>
+#include <linux/regulator/machine.h>
+#include <linux/regulator/of_regulator.h>
+#include <linux/slab.h>
+
+/* Register defs */
+#define BCM59056_RFLDOPMCTRL1 0x60
+#define BCM59056_IOSR1PMCTRL1 0x7a
+#define BCM59056_IOSR2PMCTRL1 0x7c
+#define BCM59056_CSRPMCTRL1 0x7e
+#define BCM59056_SDSR1PMCTRL1 0x82
+#define BCM59056_SDSR2PMCTRL1 0x86
+#define BCM59056_MSRPMCTRL1 0x8a
+#define BCM59056_VSRPMCTRL1 0x8e
+#define BCM59056_REG_ENABLE BIT(7)
+
+#define BCM59056_RFLDOCTRL 0x96
+#define BCM59056_CSRVOUT1 0xc0
+#define BCM59056_LDO_VSEL_MASK GENMASK(5, 3)
+#define BCM59056_SR_VSEL_MASK GENMASK(5, 0)
+
+/* LDO regulator IDs */
+#define BCM59056_REG_RFLDO 0
+#define BCM59056_REG_CAMLDO1 1
+#define BCM59056_REG_CAMLDO2 2
+#define BCM59056_REG_SIMLDO1 3
+#define BCM59056_REG_SIMLDO2 4
+#define BCM59056_REG_SDLDO 5
+#define BCM59056_REG_SDXLDO 6
+#define BCM59056_REG_MMCLDO1 7
+#define BCM59056_REG_MMCLDO2 8
+#define BCM59056_REG_AUDLDO 9
+#define BCM59056_REG_MICLDO 10
+#define BCM59056_REG_USBLDO 11
+#define BCM59056_REG_VIBLDO 12
+
+/* DCDC regulator IDs */
+#define BCM59056_REG_CSR 13
+#define BCM59056_REG_IOSR1 14
+#define BCM59056_REG_IOSR2 15
+#define BCM59056_REG_MSR 16
+#define BCM59056_REG_SDSR1 17
+#define BCM59056_REG_SDSR2 18
+#define BCM59056_REG_VSR 19
+
+#define BCM59056_NUM_REGS 20
+
+#define BCM59056_REG_IS_LDO(n) (n < BCM59056_REG_CSR)
+
+struct bcm59056_board {
+ struct regulator_init_data *bcm59056_pmu_init_data[BCM59056_NUM_REGS];
+};
+
+/* LDO group A: supported voltages in microvolts */
+static const unsigned int ldo_a_table[] = {
+ 1200000, 1800000, 2500000, 2700000, 2800000,
+ 2900000, 3000000, 3300000,
+};
+
+/* LDO group C: supported voltages in microvolts */
+static const unsigned int ldo_c_table[] = {
+ 3100000, 1800000, 2500000, 2700000, 2800000,
+ 2900000, 3000000, 3300000,
+};
+
+/* DCDC group CSR: supported voltages in microvolts */
+static const struct regulator_linear_range dcdc_csr_ranges[] = {
+ REGULATOR_LINEAR_RANGE(860000, 2, 50, 10000),
+ REGULATOR_LINEAR_RANGE(1360000, 51, 55, 20000),
+ REGULATOR_LINEAR_RANGE(900000, 56, 63, 0),
+};
+
+/* DCDC group IOSR1: supported voltages in microvolts */
+static const struct regulator_linear_range dcdc_iosr1_ranges[] = {
+ REGULATOR_LINEAR_RANGE(860000, 2, 51, 10000),
+ REGULATOR_LINEAR_RANGE(1500000, 52, 52, 0),
+ REGULATOR_LINEAR_RANGE(1800000, 53, 53, 0),
+ REGULATOR_LINEAR_RANGE(900000, 54, 63, 0),
+};
+
+/* DCDC group SDSR1: supported voltages in microvolts */
+static const struct regulator_linear_range dcdc_sdsr1_ranges[] = {
+ REGULATOR_LINEAR_RANGE(860000, 2, 50, 10000),
+ REGULATOR_LINEAR_RANGE(1340000, 51, 51, 0),
+ REGULATOR_LINEAR_RANGE(900000, 52, 63, 0),
+};
+
+struct bcm59056_info {
+ const char *name;
+ const char *vin_name;
+ u8 n_voltages;
+ const unsigned int *volt_table;
+ u8 n_linear_ranges;
+ const struct regulator_linear_range *linear_ranges;
+};
+
+#define BCM59056_REG_TABLE(_name, _table) \
+ { \
+ .name = #_name, \
+ .n_voltages = ARRAY_SIZE(_table), \
+ .volt_table = _table, \
+ }
+
+#define BCM59056_REG_RANGES(_name, _ranges) \
+ { \
+ .name = #_name, \
+ .n_linear_ranges = ARRAY_SIZE(_ranges), \
+ .linear_ranges = _ranges, \
+ }
+
+static struct bcm59056_info bcm59056_regs[] = {
+ BCM59056_REG_TABLE(rfldo, ldo_a_table),
+ BCM59056_REG_TABLE(camldo1, ldo_c_table),
+ BCM59056_REG_TABLE(camldo2, ldo_c_table),
+ BCM59056_REG_TABLE(simldo1, ldo_a_table),
+ BCM59056_REG_TABLE(simldo2, ldo_a_table),
+ BCM59056_REG_TABLE(sdldo, ldo_c_table),
+ BCM59056_REG_TABLE(sdxldo, ldo_a_table),
+ BCM59056_REG_TABLE(mmcldo1, ldo_a_table),
+ BCM59056_REG_TABLE(mmcldo2, ldo_a_table),
+ BCM59056_REG_TABLE(audldo, ldo_a_table),
+ BCM59056_REG_TABLE(micldo, ldo_a_table),
+ BCM59056_REG_TABLE(usbldo, ldo_a_table),
+ BCM59056_REG_TABLE(vibldo, ldo_c_table),
+ BCM59056_REG_RANGES(csr, dcdc_csr_ranges),
+ BCM59056_REG_RANGES(iosr1, dcdc_iosr1_ranges),
+ BCM59056_REG_RANGES(iosr2, dcdc_iosr1_ranges),
+ BCM59056_REG_RANGES(msr, dcdc_iosr1_ranges),
+ BCM59056_REG_RANGES(sdsr1, dcdc_sdsr1_ranges),
+ BCM59056_REG_RANGES(sdsr2, dcdc_iosr1_ranges),
+ BCM59056_REG_RANGES(vsr, dcdc_iosr1_ranges),
+};
+
+struct bcm59056_reg {
+ struct regulator_desc *desc;
+ struct bcm59056 *mfd;
+ struct regulator_dev **rdev;
+ struct bcm59056_info **info;
+};
+
+static int bcm59056_get_vsel_register(int id)
+{
+ if (BCM59056_REG_IS_LDO(id))
+ return BCM59056_RFLDOCTRL + id;
+ else
+ return BCM59056_CSRVOUT1 + (id - BCM59056_REG_CSR) * 3;
+}
+
+static int bcm59056_get_enable_register(int id)
+{
+ int reg = 0;
+
+ if (BCM59056_REG_IS_LDO(id))
+ reg = BCM59056_RFLDOPMCTRL1 + id * 2;
+ else
+ switch (id) {
+ case BCM59056_REG_CSR:
+ reg = BCM59056_CSRPMCTRL1;
+ break;
+ case BCM59056_REG_IOSR1:
+ reg = BCM59056_IOSR1PMCTRL1;
+ break;
+ case BCM59056_REG_IOSR2:
+ reg = BCM59056_IOSR2PMCTRL1;
+ break;
+ case BCM59056_REG_MSR:
+ reg = BCM59056_MSRPMCTRL1;
+ break;
+ case BCM59056_REG_SDSR1:
+ reg = BCM59056_SDSR1PMCTRL1;
+ break;
+ case BCM59056_REG_SDSR2:
+ reg = BCM59056_SDSR2PMCTRL1;
+ break;
+ };
+
+ return reg;
+}
+
+static unsigned int bcm59056_get_mode(struct regulator_dev *dev)
+{
+ return REGULATOR_MODE_NORMAL;
+}
+
+static int bcm59056_set_mode(struct regulator_dev *dev, unsigned int mode)
+{
+ if (mode == REGULATOR_MODE_NORMAL)
+ return 0;
+ else
+ return -EINVAL;
+}
+
+static struct regulator_ops bcm59056_ops_ldo = {
+ .is_enabled = regulator_is_enabled_regmap,
+ .enable = regulator_enable_regmap,
+ .disable = regulator_disable_regmap,
+ .set_mode = bcm59056_set_mode,
+ .get_mode = bcm59056_get_mode,
+ .get_voltage_sel = regulator_get_voltage_sel_regmap,
+ .set_voltage_sel = regulator_set_voltage_sel_regmap,
+ .list_voltage = regulator_list_voltage_table,
+ .map_voltage = regulator_map_voltage_iterate,
+};
+
+static struct regulator_ops bcm59056_ops_dcdc = {
+ .is_enabled = regulator_is_enabled_regmap,
+ .enable = regulator_enable_regmap,
+ .disable = regulator_disable_regmap,
+ .set_mode = bcm59056_set_mode,
+ .get_mode = bcm59056_get_mode,
+ .get_voltage_sel = regulator_get_voltage_sel_regmap,
+ .set_voltage_sel = regulator_set_voltage_sel_regmap,
+ .list_voltage = regulator_list_voltage_linear_range,
+ .map_voltage = regulator_map_voltage_linear_range,
+};
+
+#define BCM59056_MATCH(_name, _id) \
+ { \
+ .name = #_name, \
+ .driver_data = (void *)&bcm59056_regs[BCM59056_REG_##_id], \
+ }
+
+static struct of_regulator_match bcm59056_matches[] = {
+ BCM59056_MATCH(rfldo, RFLDO),
+ BCM59056_MATCH(camldo1, CAMLDO1),
+ BCM59056_MATCH(camldo2, CAMLDO2),
+ BCM59056_MATCH(simldo1, SIMLDO1),
+ BCM59056_MATCH(simldo2, SIMLDO2),
+ BCM59056_MATCH(sdldo, SDLDO),
+ BCM59056_MATCH(sdxldo, SDXLDO),
+ BCM59056_MATCH(mmcldo1, MMCLDO1),
+ BCM59056_MATCH(mmcldo2, MMCLDO2),
+ BCM59056_MATCH(audldo, AUDLDO),
+ BCM59056_MATCH(micldo, MICLDO),
+ BCM59056_MATCH(usbldo, USBLDO),
+ BCM59056_MATCH(vibldo, VIBLDO),
+ BCM59056_MATCH(csr, CSR),
+ BCM59056_MATCH(iosr1, IOSR1),
+ BCM59056_MATCH(iosr2, IOSR2),
+ BCM59056_MATCH(msr, MSR),
+ BCM59056_MATCH(sdsr1, SDSR1),
+ BCM59056_MATCH(sdsr2, SDSR2),
+ BCM59056_MATCH(vsr, VSR),
+};
+
+static struct bcm59056_board *bcm59056_parse_dt_reg_data(
+ struct platform_device *pdev,
+ struct of_regulator_match **bcm59056_reg_matches)
+{
+ struct bcm59056_board *data;
+ struct device_node *np, *regulators;
+ struct of_regulator_match *matches = bcm59056_matches;
+ int count = ARRAY_SIZE(bcm59056_matches);
+ int idx = 0;
+ int ret;
+
+ data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
+ if (!data) {
+ dev_err(&pdev->dev, "failed to allocate regulator board data\n");
+ return NULL;
+ }
+
+ np = of_node_get(pdev->dev.parent->of_node);
+ regulators = of_get_child_by_name(np, "regulators");
+ if (!regulators) {
+ dev_err(&pdev->dev, "regulator node not found\n");
+ return NULL;
+ }
+
+ ret = of_regulator_match(&pdev->dev, regulators, matches, count);
+ of_node_put(regulators);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "Error parsing regulator init data: %d\n",
+ ret);
+ return NULL;
+ }
+
+ *bcm59056_reg_matches = matches;
+
+ for (idx = 0; idx < count; idx++) {
+ if (!matches[idx].init_data || !matches[idx].of_node)
+ continue;
+
+ data->bcm59056_pmu_init_data[idx] = matches[idx].init_data;
+ }
+
+ return data;
+}
+
+static int bcm59056_probe(struct platform_device *pdev)
+{
+ struct bcm59056 *bcm59056 = dev_get_drvdata(pdev->dev.parent);
+ struct bcm59056_board *pmu_data = NULL;
+ struct bcm59056_reg *pmu;
+ struct regulator_config config = { };
+ struct bcm59056_info *info;
+ struct regulator_init_data *reg_data;
+ struct regulator_dev *rdev;
+ struct of_regulator_match *bcm59056_reg_matches = NULL;
+ int i;
+
+ if (bcm59056->dev->of_node)
+ pmu_data = bcm59056_parse_dt_reg_data(pdev,
+ &bcm59056_reg_matches);
+
+ if (!pmu_data) {
+ dev_err(&pdev->dev, "Platform data not found\n");
+ return -EINVAL;
+ }
+
+ pmu = devm_kzalloc(&pdev->dev, sizeof(*pmu), GFP_KERNEL);
+ if (!pmu) {
+ dev_err(&pdev->dev, "Memory allocation failed for pmu\n");
+ return -ENOMEM;
+ }
+
+ pmu->mfd = bcm59056;
+
+ platform_set_drvdata(pdev, pmu);
+
+ pmu->desc = devm_kzalloc(&pdev->dev, BCM59056_NUM_REGS *
+ sizeof(struct regulator_desc), GFP_KERNEL);
+ if (!pmu->desc) {
+ dev_err(&pdev->dev, "Memory alloc fails for desc\n");
+ return -ENOMEM;
+ }
+
+ pmu->info = devm_kzalloc(&pdev->dev, BCM59056_NUM_REGS *
+ sizeof(struct bcm59056_info *), GFP_KERNEL);
+ if (!pmu->info) {
+ dev_err(&pdev->dev, "Memory alloc fails for info\n");
+ return -ENOMEM;
+ }
+
+ pmu->rdev = devm_kzalloc(&pdev->dev, BCM59056_NUM_REGS *
+ sizeof(struct regulator_dev *), GFP_KERNEL);
+ if (!pmu->rdev) {
+ dev_err(&pdev->dev, "Memory alloc fails for rdev\n");
+ return -ENOMEM;
+ }
+
+ info = bcm59056_regs;
+
+ for (i = 0; i < BCM59056_NUM_REGS; i++, info++) {
+ reg_data = pmu_data->bcm59056_pmu_init_data[i];
+
+ /*
+ * Regulator API handles empty constraints but not NULL
+ * constraints
+ */
+ if (!reg_data)
+ continue;
+
+ /* Register the regulators */
+ pmu->info[i] = info;
+
+ pmu->desc[i].name = info->name;
+ pmu->desc[i].supply_name = info->vin_name;
+ pmu->desc[i].id = i;
+ pmu->desc[i].volt_table = info->volt_table;
+ pmu->desc[i].n_voltages = info->n_voltages;
+ pmu->desc[i].linear_ranges = info->linear_ranges;
+ pmu->desc[i].n_linear_ranges = info->n_linear_ranges;
+
+ if (BCM59056_REG_IS_LDO(i)) {
+ pmu->desc[i].ops = &bcm59056_ops_ldo;
+ pmu->desc[i].vsel_mask = BCM59056_LDO_VSEL_MASK;
+ } else {
+ pmu->desc[i].ops = &bcm59056_ops_dcdc;
+ pmu->desc[i].vsel_mask = BCM59056_SR_VSEL_MASK;
+ }
+
+ pmu->desc[i].vsel_reg = bcm59056_get_vsel_register(i);
+ pmu->desc[i].enable_is_inverted = true;
+ pmu->desc[i].enable_mask = BCM59056_REG_ENABLE;
+ pmu->desc[i].enable_reg = bcm59056_get_enable_register(i);
+ pmu->desc[i].type = REGULATOR_VOLTAGE;
+ pmu->desc[i].owner = THIS_MODULE;
+
+ config.dev = bcm59056->dev;
+ config.init_data = reg_data;
+ config.driver_data = pmu;
+ config.regmap = bcm59056->regmap;
+
+ if (bcm59056_reg_matches)
+ config.of_node = bcm59056_reg_matches[i].of_node;
+
+ rdev = devm_regulator_register(&pdev->dev, &pmu->desc[i],
+ &config);
+ if (IS_ERR(rdev)) {
+ dev_err(bcm59056->dev,
+ "failed to register %s regulator\n",
+ pdev->name);
+ return PTR_ERR(rdev);
+ }
+
+ pmu->rdev[i] = rdev;
+ }
+
+ return 0;
+}
+
+static struct platform_driver bcm59056_regulator_driver = {
+ .driver = {
+ .name = "bcm59056-pmu",
+ .owner = THIS_MODULE,
+ },
+ .probe = bcm59056_probe,
+};
+
+static int __init bcm59056_regulator_init(void)
+{
+ return platform_driver_register(&bcm59056_regulator_driver);
+}
+subsys_initcall(bcm59056_regulator_init);
+
+static void __exit bcm59056_regulator_exit(void)
+{
+ platform_driver_unregister(&bcm59056_regulator_driver);
+}
+module_exit(bcm59056_regulator_exit);
+
+MODULE_AUTHOR("Matt Porter <mporter@linaro.org>");
+MODULE_DESCRIPTION("BCM59056 voltage regulator driver");
+MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform:bcm59056-regulator");
--
1.8.4
^ permalink raw reply related
* [PATCH 3/6] mfd: add bcm59056 pmu driver
From: Matt Porter @ 2014-02-04 12:19 UTC (permalink / raw)
To: Wolfram Sang, Tim Kryger, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, Samuel Ortiz, Lee Jones, Liam Girdwood,
Mark Brown, Christian Daudt
Cc: Devicetree List, Linux I2C List, Linux ARM Kernel List,
Linux Kernel Mailing List
In-Reply-To: <1391516352-32359-1-git-send-email-mporter@linaro.org>
Add a driver for the BCM59056 PMU multi-function device. The driver
initially supports regmap initialization and instantiation of the
voltage regulator device function of the PMU.
Signed-off-by: Matt Porter <mporter@linaro.org>
Reviewed-by: Tim Kryger <tim.kryger@linaro.org>
Reviewed-by: Markus Mayer <markus.mayer@linaro.org>
---
drivers/mfd/Kconfig | 8 +++
drivers/mfd/Makefile | 1 +
drivers/mfd/bcm59056.c | 119 +++++++++++++++++++++++++++++++++++++++++++
include/linux/mfd/bcm59056.h | 35 +++++++++++++
4 files changed, 163 insertions(+)
create mode 100644 drivers/mfd/bcm59056.c
create mode 100644 include/linux/mfd/bcm59056.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 49bb445..36e96c2 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -59,6 +59,14 @@ config MFD_AAT2870_CORE
additional drivers must be enabled in order to use the
functionality of the device.
+config MFD_BCM59056
+ bool "Broadcom BCM59056 PMU"
+ select MFD_CORE
+ select REGMAP_I2C
+ depends on I2C=y
+ help
+ Support for the BCM59056 PMU from Broadcom
+
config MFD_CROS_EC
tristate "ChromeOS Embedded Controller"
select MFD_CORE
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 5aea5ef..8d7e110 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_MFD_88PM800) += 88pm800.o 88pm80x.o
obj-$(CONFIG_MFD_88PM805) += 88pm805.o 88pm80x.o
obj-$(CONFIG_MFD_SM501) += sm501.o
obj-$(CONFIG_MFD_ASIC3) += asic3.o tmio_core.o
+obj-$(CONFIG_MFD_BCM59056) += bcm59056.o
obj-$(CONFIG_MFD_CROS_EC) += cros_ec.o
obj-$(CONFIG_MFD_CROS_EC_I2C) += cros_ec_i2c.o
obj-$(CONFIG_MFD_CROS_EC_SPI) += cros_ec_spi.o
diff --git a/drivers/mfd/bcm59056.c b/drivers/mfd/bcm59056.c
new file mode 100644
index 0000000..f193bfb
--- /dev/null
+++ b/drivers/mfd/bcm59056.c
@@ -0,0 +1,119 @@
+/*
+ * Broadcom BCM59056 PMU
+ *
+ * Copyright 2014 Linaro Limited
+ * Author: Matt Porter <mporter@linaro.org>
+ *
+ * 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; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include <linux/err.h>
+#include <linux/i2c.h>
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/irq.h>
+#include <linux/irqdomain.h>
+#include <linux/mfd/bcm59056.h>
+#include <linux/mfd/core.h>
+#include <linux/module.h>
+#include <linux/moduleparam.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/regmap.h>
+#include <linux/slab.h>
+
+static struct mfd_cell bcm59056s[] = {
+ {
+ .name = "bcm59056-pmu",
+ },
+};
+
+static const struct regmap_config bcm59056_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .max_register = BCM59056_MAX_REGISTER - 1,
+ .cache_type = REGCACHE_RBTREE,
+};
+
+static int bcm59056_i2c_probe(struct i2c_client *i2c,
+ const struct i2c_device_id *id)
+{
+ struct bcm59056 *bcm59056;
+ int chip_id = id->driver_data;
+ int ret = 0;
+
+ bcm59056 = devm_kzalloc(&i2c->dev, sizeof(*bcm59056), GFP_KERNEL);
+ if (!bcm59056)
+ return -ENOMEM;
+
+ i2c_set_clientdata(i2c, bcm59056);
+ bcm59056->dev = &i2c->dev;
+ bcm59056->i2c_client = i2c;
+ bcm59056->id = chip_id;
+
+ bcm59056->regmap = devm_regmap_init_i2c(i2c, &bcm59056_regmap_config);
+ if (IS_ERR(bcm59056->regmap)) {
+ ret = PTR_ERR(bcm59056->regmap);
+ dev_err(&i2c->dev, "regmap initialization failed: %d\n", ret);
+ return ret;
+ }
+
+ ret = mfd_add_devices(bcm59056->dev, -1,
+ bcm59056s, ARRAY_SIZE(bcm59056s),
+ NULL, 0, NULL);
+ if (ret < 0)
+ dev_err(&i2c->dev, "mfd_add_devices failed: %d\n", ret);
+
+ return ret;
+}
+
+static int bcm59056_i2c_remove(struct i2c_client *i2c)
+{
+ struct bcm59056 *bcm59056 = i2c_get_clientdata(i2c);
+
+ mfd_remove_devices(bcm59056->dev);
+
+ return 0;
+}
+
+static const struct of_device_id bcm59056_of_match[] = {
+ { .compatible = "brcm,bcm59056", .data = (void *)BCM59056 },
+ { }
+};
+
+static const struct i2c_device_id bcm59056_i2c_id[] = {
+ { "bcm59056", BCM59056 },
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, bcm59056_i2c_id);
+
+static struct i2c_driver bcm59056_i2c_driver = {
+ .driver = {
+ .name = "bcm59056",
+ .owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(bcm59056_of_match),
+ },
+ .probe = bcm59056_i2c_probe,
+ .remove = bcm59056_i2c_remove,
+ .id_table = bcm59056_i2c_id,
+};
+
+static int __init bcm59056_init(void)
+{
+ return i2c_add_driver(&bcm59056_i2c_driver);
+}
+subsys_initcall(bcm59056_init);
+
+static void __exit bcm59056_exit(void)
+{
+ i2c_del_driver(&bcm59056_i2c_driver);
+}
+module_exit(bcm59056_exit);
+
+MODULE_AUTHOR("Matt Porter <mporter@linaro.org>");
+MODULE_DESCRIPTION("BCM59056 multi-function driver");
+MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform:bcm59056");
diff --git a/include/linux/mfd/bcm59056.h b/include/linux/mfd/bcm59056.h
new file mode 100644
index 0000000..967395d
--- /dev/null
+++ b/include/linux/mfd/bcm59056.h
@@ -0,0 +1,35 @@
+/*
+ * Broadcom BCM59056 PMU
+ *
+ * Copyright 2014 Linaro Limited
+ * Author: Matt Porter <mporter@linaro.org>
+ *
+ * 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; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ */
+
+#ifndef __LINUX_MFD_BCM59056_H
+#define __LINUX_MFD_BCM59056_H
+
+#include <linux/device.h>
+#include <linux/i2c.h>
+#include <linux/regmap.h>
+
+/* chip id */
+#define BCM59056 0
+
+/* max register address */
+#define BCM59056_MAX_REGISTER 0xe8
+
+/* bcm59056 chip access */
+struct bcm59056 {
+ struct device *dev;
+ struct i2c_client *i2c_client;
+ struct regmap *regmap;
+ unsigned int id;
+};
+
+#endif /* __LINUX_MFD_BCM59056_H */
--
1.8.4
^ permalink raw reply related
* [PATCH 2/6] regulator: add bcm59056 pmu DT binding
From: Matt Porter @ 2014-02-04 12:19 UTC (permalink / raw)
To: Wolfram Sang, Tim Kryger, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, Samuel Ortiz, Lee Jones, Liam Girdwood,
Mark Brown, Christian Daudt
Cc: Devicetree List, Linux I2C List, Linux ARM Kernel List,
Linux Kernel Mailing List
In-Reply-To: <1391516352-32359-1-git-send-email-mporter@linaro.org>
Add a DT binding for the BCM59056 PMU. The binding inherits from
the generic regulator bindings.
Signed-off-by: Matt Porter <mporter@linaro.org>
Reviewed-by: Tim Kryger <tim.kryger@linaro.org>
Reviewed-by: Markus Mayer <markus.mayer@linaro.org>
---
.../devicetree/bindings/regulator/bcm59056.txt | 37 ++++++++++++++++++++++
1 file changed, 37 insertions(+)
create mode 100644 Documentation/devicetree/bindings/regulator/bcm59056.txt
diff --git a/Documentation/devicetree/bindings/regulator/bcm59056.txt b/Documentation/devicetree/bindings/regulator/bcm59056.txt
new file mode 100644
index 0000000..bf6b633
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/bcm59056.txt
@@ -0,0 +1,37 @@
+BCM59056 Power Management Unit
+
+Required properties:
+- compatible: "brcm,bcm59056"
+- reg: I2C slave address
+- interrupts: interrupt for the PMU. Generic interrupt client node bindings
+ are described in interrupt-controller/interrupts.txt
+- regulators: This is the list of child nodes that specify the regulator
+ initialization data for defined regulators. Generic regulator bindings
+ are described in regulator/regulator.txt.
+
+ The valid regulator-compatible values are:
+ rfldo, camldo1, camldo2, simldo1, simlso2, sdldo, sdxldo,
+ mmcldo1, mmcldo2, audldo, micldo, usbldo, vibldo,
+ csr, iosr1, iosr2, msr, sdsr1, sdsr2, vsr
+
+Example:
+ pmu: bcm59056@8 {
+ compatible = "brcm,bcm59056";
+ reg = <0x08>;
+ interrupts = <GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH>;
+ regulators {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ rfldo_reg: regulator@0 {
+ reg = <0>;
+ regulator-compatible = "rfldo";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ...
+ };
+ };
--
1.8.4
^ permalink raw reply related
* [PATCH 1/6] i2c: bcm-kona: register with subsys_initcall
From: Matt Porter @ 2014-02-04 12:19 UTC (permalink / raw)
To: Wolfram Sang, Tim Kryger, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, Samuel Ortiz, Lee Jones, Liam Girdwood,
Mark Brown, Christian Daudt
Cc: Devicetree List, Linux I2C List, Linux ARM Kernel List,
Linux Kernel Mailing List
In-Reply-To: <1391516352-32359-1-git-send-email-mporter-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Voltage regulators are needed very early due to deferred probe
being incompatible with built-in USB gadget drivers. In order to
have the PMU driver available before USB UDC, make i2c available
during subsys_initcall.
Signed-off-by: Matt Porter <mporter-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Reviewed-by: Tim Kryger <tim.kryger-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Reviewed-by: Markus Mayer <markus.mayer-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
drivers/i2c/busses/i2c-bcm-kona.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-bcm-kona.c b/drivers/i2c/busses/i2c-bcm-kona.c
index 18a74a6..bfd4056 100644
--- a/drivers/i2c/busses/i2c-bcm-kona.c
+++ b/drivers/i2c/busses/i2c-bcm-kona.c
@@ -901,7 +901,19 @@ static struct platform_driver bcm_kona_i2c_driver = {
.probe = bcm_kona_i2c_probe,
.remove = bcm_kona_i2c_remove,
};
-module_platform_driver(bcm_kona_i2c_driver);
+
+static int __init bcm_kona_i2c_init_driver(void)
+{
+ return platform_driver_register(&bcm_kona_i2c_driver);
+}
+/* PMU access is needed early so use subsys init */
+subsys_initcall(bcm_kona_i2c_init_driver);
+
+static void __exit bcm_kona_i2c_exit_driver(void)
+{
+ platform_driver_unregister(&bcm_kona_i2c_driver);
+}
+module_exit(bcm_kona_i2c_exit_driver);
MODULE_AUTHOR("Tim Kryger <tkryger-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>");
MODULE_DESCRIPTION("Broadcom Kona I2C Driver");
--
1.8.4
--
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 related
* [PATCH 0/6] BCM59056 PMU regulator support
From: Matt Porter @ 2014-02-04 12:19 UTC (permalink / raw)
To: Wolfram Sang, Tim Kryger, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, Samuel Ortiz, Lee Jones, Liam Girdwood,
Mark Brown, Christian Daudt
Cc: Devicetree List, Linux I2C List, Linux ARM Kernel List,
Linux Kernel Mailing List
The BCM59056 is a multi-function power management unit used with the
BCM281xx family of SoCs. This series adds an MFD and voltage regulator
driver to support the BCM59056. The bcm28155-ap DT support is updated
to enable use of regulators on the otg and sdhci peripherals.
Matt Porter (6):
i2c: bcm-kona: register with subsys_initcall
regulator: add bcm59056 pmu DT binding
mfd: add bcm59056 pmu driver
regulator: add bcm59056 regulator driver
ARM: configs: bcm_defconfig: enable bcm59056 regulator support
ARM: dts: add bcm59056 pmu support and enable for bcm28155-ap
.../devicetree/bindings/regulator/bcm59056.txt | 37 ++
arch/arm/boot/dts/bcm28155-ap.dts | 41 ++
arch/arm/boot/dts/bcm59056.dtsi | 158 ++++++++
arch/arm/configs/bcm_defconfig | 7 +
drivers/i2c/busses/i2c-bcm-kona.c | 14 +-
drivers/mfd/Kconfig | 8 +
drivers/mfd/Makefile | 1 +
drivers/mfd/bcm59056.c | 119 ++++++
drivers/regulator/Kconfig | 8 +
drivers/regulator/Makefile | 1 +
drivers/regulator/bcm59056-regulator.c | 445 +++++++++++++++++++++
include/linux/mfd/bcm59056.h | 35 ++
12 files changed, 873 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/regulator/bcm59056.txt
create mode 100644 arch/arm/boot/dts/bcm59056.dtsi
create mode 100644 drivers/mfd/bcm59056.c
create mode 100644 drivers/regulator/bcm59056-regulator.c
create mode 100644 include/linux/mfd/bcm59056.h
--
1.8.4
^ 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