[PATCH v2] ARM: dts: am335x-bone-common: enable aes and sham
Beaglebone Black doesn't have AES and SHAM enabled like the
original Beaglebone White dts. This breaks applications that
leverage the crypto blocks so fix this by enabling these nodes
in the am335x-bone-common.dtsi. With this change, enabling the
nodes in am335x-bone.dts is no longer required so remove them.
Signed-off-by: Matt Porter
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 8
arch/arm/boot/dts/am335x-bone.dts | 8
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index 6cc25ed..12cdb2b 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -300,3 +300,11 @@
cd-gpios = < 6 GPIO_ACTIVE_HIGH>;
cd-inverted;
};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index 83d40f7..6b849372 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -24,11 +24,3 @@
{
vmmc-supply = <_reg>;
};
-
- {
- status = "okay";
-};
-
- {
- status = "okay";
-};
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: dts: am335x-boneblack: enable aes and sham
On Wed, Feb 25, 2015 at 12:36:11PM -0600, Robert Nelson wrote:
> On Wed, Feb 25, 2015 at 11:07 AM, Matt Porter wrote:
> > Beaglebone Black doesn't have AES and SHAM enabled like the
> > original Beaglebone White dts. This breaks applications that
> > leverage the crypto blocks so fix this by enabling these nodes.
> >
> > Signed-off-by: Matt Porter
> > ---
> > arch/arm/boot/dts/am335x-boneblack.dts | 8
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/am335x-boneblack.dts
> > b/arch/arm/boot/dts/am335x-boneblack.dts
> > index 5c42d25..00853ff 100644
> > --- a/arch/arm/boot/dts/am335x-boneblack.dts
> > +++ b/arch/arm/boot/dts/am335x-boneblack.dts
> > @@ -33,6 +33,14 @@
> > status = "okay";
> > };
> >
> > + {
> > + status = "okay";
> > +};
> > +
> > + {
> > + status = "okay";
> > +};
> > +
> > _pinmux {
> > nxp_hdmi_bonelt_pins: nxp_hdmi_bonelt_pins {
> > pinctrl-single,pins = <
> > --
> > 1.8.4
>
> Shouldn't we just move these to: "am335x-bone-common.dtsi" ?
>
> (and then nuke the 6 lines in the am335x-bone.dts )
Good idea, v2 on the way.
-Matt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: dts: am335x-boneblack: enable aes and sham
Beaglebone Black doesn't have AES and SHAM enabled like the
original Beaglebone White dts. This breaks applications that
leverage the crypto blocks so fix this by enabling these nodes.
Signed-off-by: Matt Porter
---
arch/arm/boot/dts/am335x-boneblack.dts | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-boneblack.dts
b/arch/arm/boot/dts/am335x-boneblack.dts
index 5c42d25..00853ff 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -33,6 +33,14 @@
status = "okay";
};
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
_pinmux {
nxp_hdmi_bonelt_pins: nxp_hdmi_bonelt_pins {
pinctrl-single,pins = <
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: dts: am335x-boneblack: enable aes and sham
Beaglebone Black doesn't have AES and SHAM enabled like the
original Beaglebone White dts. This breaks applications that
leverage the crypto blocks so fix this by enabling these nodes.
Signed-off-by: Matt Porter mpor...@konsulko.com
---
arch/arm/boot/dts/am335x-boneblack.dts | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-boneblack.dts
b/arch/arm/boot/dts/am335x-boneblack.dts
index 5c42d25..00853ff 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -33,6 +33,14 @@
status = okay;
};
+sham {
+ status = okay;
+};
+
+aes {
+ status = okay;
+};
+
am33xx_pinmux {
nxp_hdmi_bonelt_pins: nxp_hdmi_bonelt_pins {
pinctrl-single,pins =
--
1.8.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: dts: am335x-boneblack: enable aes and sham
On Wed, Feb 25, 2015 at 12:36:11PM -0600, Robert Nelson wrote:
On Wed, Feb 25, 2015 at 11:07 AM, Matt Porter mpor...@konsulko.com wrote:
Beaglebone Black doesn't have AES and SHAM enabled like the
original Beaglebone White dts. This breaks applications that
leverage the crypto blocks so fix this by enabling these nodes.
Signed-off-by: Matt Porter mpor...@konsulko.com
---
arch/arm/boot/dts/am335x-boneblack.dts | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-boneblack.dts
b/arch/arm/boot/dts/am335x-boneblack.dts
index 5c42d25..00853ff 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -33,6 +33,14 @@
status = okay;
};
+sham {
+ status = okay;
+};
+
+aes {
+ status = okay;
+};
+
am33xx_pinmux {
nxp_hdmi_bonelt_pins: nxp_hdmi_bonelt_pins {
pinctrl-single,pins =
--
1.8.4
Shouldn't we just move these to: am335x-bone-common.dtsi ?
(and then nuke the 6 lines in the am335x-bone.dts )
Good idea, v2 on the way.
-Matt
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] ARM: dts: am335x-bone-common: enable aes and sham
Beaglebone Black doesn't have AES and SHAM enabled like the
original Beaglebone White dts. This breaks applications that
leverage the crypto blocks so fix this by enabling these nodes
in the am335x-bone-common.dtsi. With this change, enabling the
nodes in am335x-bone.dts is no longer required so remove them.
Signed-off-by: Matt Porter mpor...@konsulko.com
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 8
arch/arm/boot/dts/am335x-bone.dts | 8
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index 6cc25ed..12cdb2b 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -300,3 +300,11 @@
cd-gpios = gpio0 6 GPIO_ACTIVE_HIGH;
cd-inverted;
};
+
+aes {
+ status = okay;
+};
+
+sham {
+ status = okay;
+};
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index 83d40f7..6b849372 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -24,11 +24,3 @@
mmc1 {
vmmc-supply = ldo3_reg;
};
-
-sham {
- status = okay;
-};
-
-aes {
- status = okay;
-};
--
1.8.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] of: DT quirks infrastructure
On Wed, Feb 18, 2015 at 05:53:50PM +0200, Pantelis Antoniou wrote: > Hi Mark, > > > On Feb 18, 2015, at 17:41 , Mark Rutland wrote: > > > > Hi Pantelis, > > > > On Wed, Feb 18, 2015 at 02:59:34PM +, Pantelis Antoniou wrote: > >> Implement a method of applying DT quirks early in the boot sequence. > >> > >> A DT quirk is a subtree of the boot DT that can be applied to > >> a target in the base DT resulting in a modification of the live > >> tree. The format of the quirk nodes is that of a device tree overlay. > >> > >> For details please refer to Documentation/devicetree/quirks.txt > >> > >> Signed-off-by: Pantelis Antoniou > >> --- > >> Documentation/devicetree/quirks.txt | 101 ++ > >> drivers/of/dynamic.c| 358 > >> > >> include/linux/of.h | 16 ++ > >> 3 files changed, 475 insertions(+) > >> create mode 100644 Documentation/devicetree/quirks.txt > >> > >> diff --git a/Documentation/devicetree/quirks.txt > >> b/Documentation/devicetree/quirks.txt > >> new file mode 100644 > >> index 000..789319a > >> --- /dev/null > >> +++ b/Documentation/devicetree/quirks.txt > >> @@ -0,0 +1,101 @@ > >> +A Device Tree quirk is the way which allows modification of the > >> +boot device tree under the control of a per-platform specific method. > >> + > >> +Take for instance the case of a board family that comprises of a > >> +number of different board revisions, all being incremental changes > >> +after an initial release. > >> + > >> +Since all board revisions must be supported via a single software image > >> +the only way to support this scheme is by having a different DTB for each > >> +revision with the bootloader selecting which one to use at boot time. > > > > Not necessarily at boot time. The boards don't have to run the exact > > same FW/bootloader binary, so the relevant DTB could be programmed onto > > each board. > > > > That has not been the case in any kind of board I’ve worked with. > > A special firmware image that requires a different programming step at > the factory to select the correct DTB for each is always one more thing > that can go wrong. > > >> +While this may in theory work, in practice it is very cumbersome > >> +for the following reasons: > >> + > >> +1. The act of selecting a different boot device tree blob requires > >> +a reasonably advanced bootloader with some kind of configuration or > >> +scripting capabilities. Sadly this is not the case many times, the > >> +bootloader is extremely dumb and can only use a single dt blob. > > > > You can have several bootloader builds, or even a single build with > > something like appended DTB to get an appropriate DTB if the same binary > > will otherwise work across all variants of a board. > > > > No, the same DTB will not work across all the variants of a board. > > > So it's not necessarily true that you need a complex bootloader. > > > > >> +2. On many instances boot time is extremely critical; in some cases > >> +there are hard requirements like having working video feeds in under > >> +2 seconds from power-up. This leaves an extremely small time budget for > >> +boot-up, as low as 500ms to kernel entry. The sanest way to get there > >> +is by removing the standard bootloader from the normal boot sequence > >> +altogether by having a very small boot shim that loads the kernel and > >> +immediately jumps to kernel, like falcon-boot mode in u-boot does. > > > > Given my previous comments above I don't see why this is relevant. > > You're already passing _some_ DTB here, so if you can organise for the > > board to statically provide a sane DTB that's fine, or you can resort to > > appended DTB if it's not possible to update the board configuration. > > > > You’re missing the point. I can’t use the same DTB for each revision of the > board. Each board is similar but it’s not identical. > > >> +3. Having different DTBs/DTSs for different board revisions easily leads > >> to > >> +drift between versions. Since no developer is expected to have every > >> single > >> +board revision at hand, things are easy to get out of sync, with board > >> versions > >> +failing to boot even though the kernel is up to date. > > > > I'm not sure I follow. Surely if you don't have every board revision at > > hand you can't test quirks exhaustively either? > > > > It’s one less thing to worry about. For example in the current mainline kernel > already there is a drift between the beaglebone white and the beaglebone > black. > > Having the same DTS is just easier to keep things in sync. Absolutely, we have the problem in the dts files today where we have lots of duplicated bits. I know one case that I think you are alluding to is how BBW has the aes and sham enabled but BBB does not. That's with just two variants. :( This would definitely drive better organization of dtses and cure a lot of bitrot if they could share a common file. OTOH, some might
Re: [PATCH 2/4] of: DT quirks infrastructure
On Wed, Feb 18, 2015 at 05:53:50PM +0200, Pantelis Antoniou wrote: Hi Mark, On Feb 18, 2015, at 17:41 , Mark Rutland mark.rutl...@arm.com wrote: Hi Pantelis, On Wed, Feb 18, 2015 at 02:59:34PM +, Pantelis Antoniou wrote: Implement a method of applying DT quirks early in the boot sequence. A DT quirk is a subtree of the boot DT that can be applied to a target in the base DT resulting in a modification of the live tree. The format of the quirk nodes is that of a device tree overlay. For details please refer to Documentation/devicetree/quirks.txt Signed-off-by: Pantelis Antoniou pantelis.anton...@konsulko.com --- Documentation/devicetree/quirks.txt | 101 ++ drivers/of/dynamic.c| 358 include/linux/of.h | 16 ++ 3 files changed, 475 insertions(+) create mode 100644 Documentation/devicetree/quirks.txt diff --git a/Documentation/devicetree/quirks.txt b/Documentation/devicetree/quirks.txt new file mode 100644 index 000..789319a --- /dev/null +++ b/Documentation/devicetree/quirks.txt @@ -0,0 +1,101 @@ +A Device Tree quirk is the way which allows modification of the +boot device tree under the control of a per-platform specific method. + +Take for instance the case of a board family that comprises of a +number of different board revisions, all being incremental changes +after an initial release. + +Since all board revisions must be supported via a single software image +the only way to support this scheme is by having a different DTB for each +revision with the bootloader selecting which one to use at boot time. Not necessarily at boot time. The boards don't have to run the exact same FW/bootloader binary, so the relevant DTB could be programmed onto each board. That has not been the case in any kind of board I’ve worked with. A special firmware image that requires a different programming step at the factory to select the correct DTB for each is always one more thing that can go wrong. +While this may in theory work, in practice it is very cumbersome +for the following reasons: + +1. The act of selecting a different boot device tree blob requires +a reasonably advanced bootloader with some kind of configuration or +scripting capabilities. Sadly this is not the case many times, the +bootloader is extremely dumb and can only use a single dt blob. You can have several bootloader builds, or even a single build with something like appended DTB to get an appropriate DTB if the same binary will otherwise work across all variants of a board. No, the same DTB will not work across all the variants of a board. So it's not necessarily true that you need a complex bootloader. +2. On many instances boot time is extremely critical; in some cases +there are hard requirements like having working video feeds in under +2 seconds from power-up. This leaves an extremely small time budget for +boot-up, as low as 500ms to kernel entry. The sanest way to get there +is by removing the standard bootloader from the normal boot sequence +altogether by having a very small boot shim that loads the kernel and +immediately jumps to kernel, like falcon-boot mode in u-boot does. Given my previous comments above I don't see why this is relevant. You're already passing _some_ DTB here, so if you can organise for the board to statically provide a sane DTB that's fine, or you can resort to appended DTB if it's not possible to update the board configuration. You’re missing the point. I can’t use the same DTB for each revision of the board. Each board is similar but it’s not identical. +3. Having different DTBs/DTSs for different board revisions easily leads to +drift between versions. Since no developer is expected to have every single +board revision at hand, things are easy to get out of sync, with board versions +failing to boot even though the kernel is up to date. I'm not sure I follow. Surely if you don't have every board revision at hand you can't test quirks exhaustively either? It’s one less thing to worry about. For example in the current mainline kernel already there is a drift between the beaglebone white and the beaglebone black. Having the same DTS is just easier to keep things in sync. Absolutely, we have the problem in the dts files today where we have lots of duplicated bits. I know one case that I think you are alluding to is how BBW has the aes and sham enabled but BBB does not. That's with just two variants. :( This would definitely drive better organization of dtses and cure a lot of bitrot if they could share a common file. OTOH, some might argue that the bone common dtsi should just enable those nodes staticly for this case. -Matt -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to
[PATCH] MAINTAINERS: Remove self as ARM mach-bcm co-maintainer
Removing myself as a co-maintainer. Signed-off-by: Matt Porter --- MAINTAINERS | 1 - 1 file changed, 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 2ebb056..e21438b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2077,7 +2077,6 @@ F:drivers/net/ethernet/broadcom/bnx2x/ BROADCOM BCM281XX/BCM11XXX/BCM216XX ARM ARCHITECTURE M: Christian Daudt -M: Matt Porter M: Florian Fainelli L: bcm-kernel-feedback-l...@broadcom.com T: git git://github.com/broadcom/mach-bcm -- 1.8.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] MAINTAINERS: Remove self as ARM mach-bcm co-maintainer
Removing myself as a co-maintainer. Signed-off-by: Matt Porter mpor...@linaro.org --- MAINTAINERS | 1 - 1 file changed, 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 2ebb056..e21438b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2077,7 +2077,6 @@ F:drivers/net/ethernet/broadcom/bnx2x/ BROADCOM BCM281XX/BCM11XXX/BCM216XX ARM ARCHITECTURE M: Christian Daudt b...@fixthebug.org -M: Matt Porter mpor...@linaro.org M: Florian Fainelli f.faine...@gmail.com L: bcm-kernel-feedback-l...@broadcom.com T: git git://github.com/broadcom/mach-bcm -- 1.8.4 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] gpio, bcm-kona, LLVMLinux: Remove use of __initconst
On Tue, Sep 23, 2014 at 12:30:16PM -0700, beh...@converseincode.com wrote:
> From: Behan Webster
>
> The __initconst is in the wrong place, and when moved to the correct place
> it uncovers an error where the variable is used by non-init data structures.
>
> Instead merely make them const and put the const in the right spot.
>
> Signed-off-by: Behan Webster
> Reviewed-by: Mark Charlebois
> Acked-by: Arnd Bergmann
> ---
> drivers/gpio/gpio-bcm-kona.c | 2 +-
> drivers/mmc/host/sdhci-bcm-kona.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
As mentioned on IRC, Linus, Chris, and Ulf probably would like this
split to go into each respective tree.
-Matt
>
> diff --git a/drivers/gpio/gpio-bcm-kona.c b/drivers/gpio/gpio-bcm-kona.c
> index 3f6b33c..de0801e 100644
> --- a/drivers/gpio/gpio-bcm-kona.c
> +++ b/drivers/gpio/gpio-bcm-kona.c
> @@ -496,7 +496,7 @@ static struct irq_chip bcm_gpio_irq_chip = {
> .irq_release_resources = bcm_kona_gpio_irq_relres,
> };
>
> -static struct __initconst of_device_id bcm_kona_gpio_of_match[] = {
> +static struct of_device_id const bcm_kona_gpio_of_match[] = {
> { .compatible = "brcm,kona-gpio" },
> {}
> };
> diff --git a/drivers/mmc/host/sdhci-bcm-kona.c
> b/drivers/mmc/host/sdhci-bcm-kona.c
> index dd780c3..4bb06c8 100644
> --- a/drivers/mmc/host/sdhci-bcm-kona.c
> +++ b/drivers/mmc/host/sdhci-bcm-kona.c
> @@ -225,7 +225,7 @@ static struct sdhci_pltfm_data sdhci_pltfm_data_kona = {
> SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN,
> };
>
> -static struct __initconst of_device_id sdhci_bcm_kona_of_match[] = {
> +static struct of_device_id const sdhci_bcm_kona_of_match[] = {
> { .compatible = "brcm,kona-sdhci"},
> { .compatible = "bcm,kona-sdhci"}, /* deprecated name */
> {}
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] gpio, bcm-kona, LLVMLinux: Remove use of __initconst
On Tue, Sep 23, 2014 at 12:30:16PM -0700, beh...@converseincode.com wrote:
> From: Behan Webster
>
> The __initconst is in the wrong place, and when moved to the correct place
> it uncovers an error where the variable is used by non-init data structures.
>
> Instead merely make them const and put the const in the right spot.
>
> Signed-off-by: Behan Webster
> Reviewed-by: Mark Charlebois
> Acked-by: Arnd Bergmann
> ---
> drivers/gpio/gpio-bcm-kona.c | 2 +-
> drivers/mmc/host/sdhci-bcm-kona.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpio/gpio-bcm-kona.c b/drivers/gpio/gpio-bcm-kona.c
> index 3f6b33c..de0801e 100644
> --- a/drivers/gpio/gpio-bcm-kona.c
> +++ b/drivers/gpio/gpio-bcm-kona.c
> @@ -496,7 +496,7 @@ static struct irq_chip bcm_gpio_irq_chip = {
> .irq_release_resources = bcm_kona_gpio_irq_relres,
> };
>
> -static struct __initconst of_device_id bcm_kona_gpio_of_match[] = {
> +static struct of_device_id const bcm_kona_gpio_of_match[] = {
> { .compatible = "brcm,kona-gpio" },
> {}
> };
> diff --git a/drivers/mmc/host/sdhci-bcm-kona.c
> b/drivers/mmc/host/sdhci-bcm-kona.c
> index dd780c3..4bb06c8 100644
> --- a/drivers/mmc/host/sdhci-bcm-kona.c
> +++ b/drivers/mmc/host/sdhci-bcm-kona.c
> @@ -225,7 +225,7 @@ static struct sdhci_pltfm_data sdhci_pltfm_data_kona = {
> SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN,
> };
>
> -static struct __initconst of_device_id sdhci_bcm_kona_of_match[] = {
> +static struct of_device_id const sdhci_bcm_kona_of_match[] = {
> { .compatible = "brcm,kona-sdhci"},
> { .compatible = "bcm,kona-sdhci"}, /* deprecated name */
> {}
Acked-by: Matt Porter
-Matt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: mach-bcm: offer a new maintainer and process
On Tue, Sep 23, 2014 at 08:00:41AM -0700, Scott Branden wrote: > On 14-09-23 05:54 AM, Matt Porter wrote: > >On Mon, Sep 22, 2014 at 10:03:39PM -0700, Olof Johansson wrote: > >>On Fri, Sep 19, 2014 at 11:17:11AM -0700, Florian Fainelli wrote: > >>>Hi all, > >>> > >>>As some of you may have seen in the news, Broadcom has recently stopped > >>>its mobile SoC activities. Upstream support for Broadcom's Mobile SoCs > >>>was an effort initially started by Christian Daudt and his team, and then > >>>continued by Alex Eleder and Matter Porter assigned to a particular landing > >>>team within Linaro to help Broadcom doing so. > >>> > >>>As part of this effort, Christian and Matt volunteered for centralizing > >>>pull > >>>requests coming from the arch/arm/mach-bcm/* directory and as of today, > >>>they > >>>are still responsible for merging mach-bcm pull requests coming from > >>>brcmstb, > >>>bcm5301x, bcm2835 and bcm63xx, creating an intermediate layer to the > >>>arm-soc > >>>tree. > >>> > >>>Following the mobile group shut down, our group (in which Brian, Gregory, > >>>Marc, > >>>Kevin and myself are) inherited these mobile SoC platforms, although at > >>>this > >>>point we cannot comment on the future of mobile platforms, we know that our > >>>Linaro activities have been stopped. > >>> > >>>We have not heard much from Christian and Matt in a while, and some of our > >>>pull > >>>requests have been stalling as a result. We would like to offer both a new > >>>maintainer for the mobile platforms as well as reworking the pull request > >>>process: > >>> > >>>- our group has now full access to these platforms, putting us in the best > >>> position to support Mobile SoCs questions > >> > >>So, one question I have is whether it makes sense to keep the mobile > >>platforms in the kernel if the line of business is ending? > I guess one problem is that BCM_MOBILE is quite misnamed. It should > really be called BCM_KONA. bcm281xx was a successful product in the > mobile space. But mobile products have short lifespans as new > versions become available every year. In fact - there have already > been more products made with this chipset that are not mobile based > nor in the consumer space. The happen to be based on an older > kernel version but we are planning on moving to a newer kernel > version in the future. Variants of this chipset will continue to be > used in many non-mobile products for many years going forward. We > could also rename it BCM_IMMOBILE going forward if that helps > clarify things. > >> > >>While I truly do appreciate the work done by Matt and others, there's > >>also little chance that it'll see substantial use by anyone. The Capri > >>boards aren't common out in the wild and I'm not aware of any dev > >>boards or consumer products with these SoCs that might want to run > >>mainline? Critical things such as power management and graphics are > >>missing from the current platform support in the kernel, so nobody is > >>likely to want it on their Android phone, etc. > Yes, thanks for all the hard work in upstreaming this code. It will > be built upon and highly leveraged for other purposes beyond Android > phones and power management. > >> > >>Maybe the answer to this is "keep it for now, revisit sometime later", > >>which is perfectly sane -- it has practically no cost to keep it around > >>the way it's looking now. > > > >It won't hurt my feelings if it's decided that it has no value being in > >the kernel. :) All I can offer is that *maybe* somebody will have a root > >exploit for the bcm281xx Roku platforms (that lasts) and/or some of the > >capri and hawaii handsets out there and find it useful as a starting > >point to work from an Android vendor tree. I don't know if anybody cares > >about hacking those platforms or not. > > > >As mentioned in a followup, the VoIP parts (or some of them, at least) > >are part of the bcm281xx family and we were expecting them to submit an > >ethernet driver for the past year. There were repeated reminders that > >they really care about mainline so I would expect it would be premature > >to remove that support until we hear from them. > > > >-Matt > > > Yes, variants of this chipset will be developed in new products. > bcm281xx was also a poor choice of n
Re: [PATCH] ARM: mach-bcm: offer a new maintainer and process
On Mon, Sep 22, 2014 at 10:03:39PM -0700, Olof Johansson wrote: > On Fri, Sep 19, 2014 at 11:17:11AM -0700, Florian Fainelli wrote: > > Hi all, > > > > As some of you may have seen in the news, Broadcom has recently stopped > > its mobile SoC activities. Upstream support for Broadcom's Mobile SoCs > > was an effort initially started by Christian Daudt and his team, and then > > continued by Alex Eleder and Matter Porter assigned to a particular landing > > team within Linaro to help Broadcom doing so. > > > > As part of this effort, Christian and Matt volunteered for centralizing pull > > requests coming from the arch/arm/mach-bcm/* directory and as of today, they > > are still responsible for merging mach-bcm pull requests coming from > > brcmstb, > > bcm5301x, bcm2835 and bcm63xx, creating an intermediate layer to the arm-soc > > tree. > > > > Following the mobile group shut down, our group (in which Brian, Gregory, > > Marc, > > Kevin and myself are) inherited these mobile SoC platforms, although at this > > point we cannot comment on the future of mobile platforms, we know that our > > Linaro activities have been stopped. > > > > We have not heard much from Christian and Matt in a while, and some of our > > pull > > requests have been stalling as a result. We would like to offer both a new > > maintainer for the mobile platforms as well as reworking the pull request > > process: > > > > - our group has now full access to these platforms, putting us in the best > > position to support Mobile SoCs questions > > So, one question I have is whether it makes sense to keep the mobile > platforms in the kernel if the line of business is ending? > > While I truly do appreciate the work done by Matt and others, there's > also little chance that it'll see substantial use by anyone. The Capri > boards aren't common out in the wild and I'm not aware of any dev > boards or consumer products with these SoCs that might want to run > mainline? Critical things such as power management and graphics are > missing from the current platform support in the kernel, so nobody is > likely to want it on their Android phone, etc. > > Maybe the answer to this is "keep it for now, revisit sometime later", > which is perfectly sane -- it has practically no cost to keep it around > the way it's looking now. It won't hurt my feelings if it's decided that it has no value being in the kernel. :) All I can offer is that *maybe* somebody will have a root exploit for the bcm281xx Roku platforms (that lasts) and/or some of the capri and hawaii handsets out there and find it useful as a starting point to work from an Android vendor tree. I don't know if anybody cares about hacking those platforms or not. As mentioned in a followup, the VoIP parts (or some of them, at least) are part of the bcm281xx family and we were expecting them to submit an ethernet driver for the past year. There were repeated reminders that they really care about mainline so I would expect it would be premature to remove that support until we hear from them. -Matt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] MAINTAINERS: add a third maintainer to mach-bcm
On Fri, Sep 19, 2014 at 11:17:12AM -0700, Florian Fainelli wrote: > Add myself as a third maintainer to the mach-bcm code to increase the > chances the redundancy in the merging/reviewing process. > > Signed-off-by: Florian Fainelli Acked-by: Matt Porter Thanks for offering to take the lead on this. With my change in role at Linaro and lack of access to Broadcom documentation and tribal knowledge on Broadcom mobile parts I can't do this justice any longer. -Matt > --- > MAINTAINERS | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 809ecd680d88..e0762fea2d02 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -2004,6 +2004,7 @@ F: drivers/net/ethernet/broadcom/bnx2x/ > BROADCOM BCM281XX/BCM11XXX/BCM216XX ARM ARCHITECTURE > M: Christian Daudt > M: Matt Porter > +M: Florian Fainelli > L: bcm-kernel-feedback-l...@broadcom.com > T: git git://github.com/broadcom/mach-bcm > S: Maintained > -- > 1.9.1 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] MAINTAINERS: add a third maintainer to mach-bcm
On Fri, Sep 19, 2014 at 11:17:12AM -0700, Florian Fainelli wrote: Add myself as a third maintainer to the mach-bcm code to increase the chances the redundancy in the merging/reviewing process. Signed-off-by: Florian Fainelli f.faine...@gmail.com Acked-by: Matt Porter mpor...@linaro.org Thanks for offering to take the lead on this. With my change in role at Linaro and lack of access to Broadcom documentation and tribal knowledge on Broadcom mobile parts I can't do this justice any longer. -Matt --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 809ecd680d88..e0762fea2d02 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2004,6 +2004,7 @@ F: drivers/net/ethernet/broadcom/bnx2x/ BROADCOM BCM281XX/BCM11XXX/BCM216XX ARM ARCHITECTURE M: Christian Daudt b...@fixthebug.org M: Matt Porter mpor...@linaro.org +M: Florian Fainelli f.faine...@gmail.com L: bcm-kernel-feedback-l...@broadcom.com T: git git://github.com/broadcom/mach-bcm S: Maintained -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: mach-bcm: offer a new maintainer and process
On Mon, Sep 22, 2014 at 10:03:39PM -0700, Olof Johansson wrote: On Fri, Sep 19, 2014 at 11:17:11AM -0700, Florian Fainelli wrote: Hi all, As some of you may have seen in the news, Broadcom has recently stopped its mobile SoC activities. Upstream support for Broadcom's Mobile SoCs was an effort initially started by Christian Daudt and his team, and then continued by Alex Eleder and Matter Porter assigned to a particular landing team within Linaro to help Broadcom doing so. As part of this effort, Christian and Matt volunteered for centralizing pull requests coming from the arch/arm/mach-bcm/* directory and as of today, they are still responsible for merging mach-bcm pull requests coming from brcmstb, bcm5301x, bcm2835 and bcm63xx, creating an intermediate layer to the arm-soc tree. Following the mobile group shut down, our group (in which Brian, Gregory, Marc, Kevin and myself are) inherited these mobile SoC platforms, although at this point we cannot comment on the future of mobile platforms, we know that our Linaro activities have been stopped. We have not heard much from Christian and Matt in a while, and some of our pull requests have been stalling as a result. We would like to offer both a new maintainer for the mobile platforms as well as reworking the pull request process: - our group has now full access to these platforms, putting us in the best position to support Mobile SoCs questions So, one question I have is whether it makes sense to keep the mobile platforms in the kernel if the line of business is ending? While I truly do appreciate the work done by Matt and others, there's also little chance that it'll see substantial use by anyone. The Capri boards aren't common out in the wild and I'm not aware of any dev boards or consumer products with these SoCs that might want to run mainline? Critical things such as power management and graphics are missing from the current platform support in the kernel, so nobody is likely to want it on their Android phone, etc. Maybe the answer to this is keep it for now, revisit sometime later, which is perfectly sane -- it has practically no cost to keep it around the way it's looking now. It won't hurt my feelings if it's decided that it has no value being in the kernel. :) All I can offer is that *maybe* somebody will have a root exploit for the bcm281xx Roku platforms (that lasts) and/or some of the capri and hawaii handsets out there and find it useful as a starting point to work from an Android vendor tree. I don't know if anybody cares about hacking those platforms or not. As mentioned in a followup, the VoIP parts (or some of them, at least) are part of the bcm281xx family and we were expecting them to submit an ethernet driver for the past year. There were repeated reminders that they really care about mainline so I would expect it would be premature to remove that support until we hear from them. -Matt -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: mach-bcm: offer a new maintainer and process
On Tue, Sep 23, 2014 at 08:00:41AM -0700, Scott Branden wrote: On 14-09-23 05:54 AM, Matt Porter wrote: On Mon, Sep 22, 2014 at 10:03:39PM -0700, Olof Johansson wrote: On Fri, Sep 19, 2014 at 11:17:11AM -0700, Florian Fainelli wrote: Hi all, As some of you may have seen in the news, Broadcom has recently stopped its mobile SoC activities. Upstream support for Broadcom's Mobile SoCs was an effort initially started by Christian Daudt and his team, and then continued by Alex Eleder and Matter Porter assigned to a particular landing team within Linaro to help Broadcom doing so. As part of this effort, Christian and Matt volunteered for centralizing pull requests coming from the arch/arm/mach-bcm/* directory and as of today, they are still responsible for merging mach-bcm pull requests coming from brcmstb, bcm5301x, bcm2835 and bcm63xx, creating an intermediate layer to the arm-soc tree. Following the mobile group shut down, our group (in which Brian, Gregory, Marc, Kevin and myself are) inherited these mobile SoC platforms, although at this point we cannot comment on the future of mobile platforms, we know that our Linaro activities have been stopped. We have not heard much from Christian and Matt in a while, and some of our pull requests have been stalling as a result. We would like to offer both a new maintainer for the mobile platforms as well as reworking the pull request process: - our group has now full access to these platforms, putting us in the best position to support Mobile SoCs questions So, one question I have is whether it makes sense to keep the mobile platforms in the kernel if the line of business is ending? I guess one problem is that BCM_MOBILE is quite misnamed. It should really be called BCM_KONA. bcm281xx was a successful product in the mobile space. But mobile products have short lifespans as new versions become available every year. In fact - there have already been more products made with this chipset that are not mobile based nor in the consumer space. The happen to be based on an older kernel version but we are planning on moving to a newer kernel version in the future. Variants of this chipset will continue to be used in many non-mobile products for many years going forward. We could also rename it BCM_IMMOBILE going forward if that helps clarify things. While I truly do appreciate the work done by Matt and others, there's also little chance that it'll see substantial use by anyone. The Capri boards aren't common out in the wild and I'm not aware of any dev boards or consumer products with these SoCs that might want to run mainline? Critical things such as power management and graphics are missing from the current platform support in the kernel, so nobody is likely to want it on their Android phone, etc. Yes, thanks for all the hard work in upstreaming this code. It will be built upon and highly leveraged for other purposes beyond Android phones and power management. Maybe the answer to this is keep it for now, revisit sometime later, which is perfectly sane -- it has practically no cost to keep it around the way it's looking now. It won't hurt my feelings if it's decided that it has no value being in the kernel. :) All I can offer is that *maybe* somebody will have a root exploit for the bcm281xx Roku platforms (that lasts) and/or some of the capri and hawaii handsets out there and find it useful as a starting point to work from an Android vendor tree. I don't know if anybody cares about hacking those platforms or not. As mentioned in a followup, the VoIP parts (or some of them, at least) are part of the bcm281xx family and we were expecting them to submit an ethernet driver for the past year. There were repeated reminders that they really care about mainline so I would expect it would be premature to remove that support until we hear from them. -Matt Yes, variants of this chipset will be developed in new products. bcm281xx was also a poor choice of naming as well. Capri or Kona family would have been much more appropriate. This product is used in VoIP and other non-mobile markets. Understood, for some reason Broadcom chose that naming when first upstreaming the base code. We did manage to name the drivers with kona after that point. Be aware that bcm281xx/capri aren't the only parts in the kernel stuck with terrible legacy names. There's a ton of Davinci/OMAP code that suffers the same curse of initial naming not matching up to later or even current uses of the same IP. -Matt -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] gpio, bcm-kona, LLVMLinux: Remove use of __initconst
On Tue, Sep 23, 2014 at 12:30:16PM -0700, beh...@converseincode.com wrote:
From: Behan Webster beh...@converseincode.com
The __initconst is in the wrong place, and when moved to the correct place
it uncovers an error where the variable is used by non-init data structures.
Instead merely make them const and put the const in the right spot.
Signed-off-by: Behan Webster beh...@converseincode.com
Reviewed-by: Mark Charlebois charl...@gmail.com
Acked-by: Arnd Bergmann a...@arndb.de
---
drivers/gpio/gpio-bcm-kona.c | 2 +-
drivers/mmc/host/sdhci-bcm-kona.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpio/gpio-bcm-kona.c b/drivers/gpio/gpio-bcm-kona.c
index 3f6b33c..de0801e 100644
--- a/drivers/gpio/gpio-bcm-kona.c
+++ b/drivers/gpio/gpio-bcm-kona.c
@@ -496,7 +496,7 @@ static struct irq_chip bcm_gpio_irq_chip = {
.irq_release_resources = bcm_kona_gpio_irq_relres,
};
-static struct __initconst of_device_id bcm_kona_gpio_of_match[] = {
+static struct of_device_id const bcm_kona_gpio_of_match[] = {
{ .compatible = brcm,kona-gpio },
{}
};
diff --git a/drivers/mmc/host/sdhci-bcm-kona.c
b/drivers/mmc/host/sdhci-bcm-kona.c
index dd780c3..4bb06c8 100644
--- a/drivers/mmc/host/sdhci-bcm-kona.c
+++ b/drivers/mmc/host/sdhci-bcm-kona.c
@@ -225,7 +225,7 @@ static struct sdhci_pltfm_data sdhci_pltfm_data_kona = {
SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN,
};
-static struct __initconst of_device_id sdhci_bcm_kona_of_match[] = {
+static struct of_device_id const sdhci_bcm_kona_of_match[] = {
{ .compatible = brcm,kona-sdhci},
{ .compatible = bcm,kona-sdhci}, /* deprecated name */
{}
Acked-by: Matt Porter mpor...@linaro.org
-Matt
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] gpio, bcm-kona, LLVMLinux: Remove use of __initconst
On Tue, Sep 23, 2014 at 12:30:16PM -0700, beh...@converseincode.com wrote:
From: Behan Webster beh...@converseincode.com
The __initconst is in the wrong place, and when moved to the correct place
it uncovers an error where the variable is used by non-init data structures.
Instead merely make them const and put the const in the right spot.
Signed-off-by: Behan Webster beh...@converseincode.com
Reviewed-by: Mark Charlebois charl...@gmail.com
Acked-by: Arnd Bergmann a...@arndb.de
---
drivers/gpio/gpio-bcm-kona.c | 2 +-
drivers/mmc/host/sdhci-bcm-kona.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
As mentioned on IRC, Linus, Chris, and Ulf probably would like this
split to go into each respective tree.
-Matt
diff --git a/drivers/gpio/gpio-bcm-kona.c b/drivers/gpio/gpio-bcm-kona.c
index 3f6b33c..de0801e 100644
--- a/drivers/gpio/gpio-bcm-kona.c
+++ b/drivers/gpio/gpio-bcm-kona.c
@@ -496,7 +496,7 @@ static struct irq_chip bcm_gpio_irq_chip = {
.irq_release_resources = bcm_kona_gpio_irq_relres,
};
-static struct __initconst of_device_id bcm_kona_gpio_of_match[] = {
+static struct of_device_id const bcm_kona_gpio_of_match[] = {
{ .compatible = brcm,kona-gpio },
{}
};
diff --git a/drivers/mmc/host/sdhci-bcm-kona.c
b/drivers/mmc/host/sdhci-bcm-kona.c
index dd780c3..4bb06c8 100644
--- a/drivers/mmc/host/sdhci-bcm-kona.c
+++ b/drivers/mmc/host/sdhci-bcm-kona.c
@@ -225,7 +225,7 @@ static struct sdhci_pltfm_data sdhci_pltfm_data_kona = {
SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN,
};
-static struct __initconst of_device_id sdhci_bcm_kona_of_match[] = {
+static struct of_device_id const sdhci_bcm_kona_of_match[] = {
{ .compatible = brcm,kona-sdhci},
{ .compatible = bcm,kona-sdhci}, /* deprecated name */
{}
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 01/11] ARM: brcmstb: add infrastructure for ARM-based Broadcom STB SoCs
On Fri, Aug 01, 2014 at 12:29:11PM -0700, Florian Fainelli wrote: > Hello, > > 2014-08-01 7:33 GMT-07:00 Rob Herring : > > On Wed, Jul 30, 2014 at 9:23 PM, Brian Norris > > wrote: > >> Hi Rob, > >> > >> I appreciate your comments, but where were many of these 5 months ago on > >> the first 7 revisions? :) > > > > Sorry, but that is the nature of upstreaming. But given some of the > > issues, it is obvious the reviews were not sufficient. > > > >> On a practical note: v9 is already queued for 3.17. Should I send > >> patches for the 3.17 cycle (or later) to fixup some of these issues? Or > >> would you recommend pulling the patches out of Matt Porter's tree now, > >> and reintroducing for 3.18? (I would be much happier with the first.) > > > > Things can always be un-queued. I guess that's Matt's and arm-soc's > > decision. > > Does that mean we should get all those patches un-queued, because that > specific patch adding SMP support that needs to be reworked, or does > that mean that if we drop this specific patch we are good with the > remainder of the patch series? Well, keep in mind that there's no specific patch adding SMP support. The patch here contains *all* of the actual code that goes through mach-bcm. The rest will go through Russell. Given what was missed, if we drop just this patch, we're left with just the DT, Kconfig, and MAINTAINERS changes. It doesn't seem like there's time to fix the problems now. It might be better to drop the whole series from arm-soc since it won't be functional in 3.17 if we drop just this patch. I'd like to see what Arnd and Olof think. I think there's value in leaving all the DT bits for 3.17. -Matt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 01/11] ARM: brcmstb: add infrastructure for ARM-based Broadcom STB SoCs
On Fri, Aug 01, 2014 at 12:29:11PM -0700, Florian Fainelli wrote: Hello, 2014-08-01 7:33 GMT-07:00 Rob Herring robherri...@gmail.com: On Wed, Jul 30, 2014 at 9:23 PM, Brian Norris computersforpe...@gmail.com wrote: Hi Rob, I appreciate your comments, but where were many of these 5 months ago on the first 7 revisions? :) Sorry, but that is the nature of upstreaming. But given some of the issues, it is obvious the reviews were not sufficient. On a practical note: v9 is already queued for 3.17. Should I send patches for the 3.17 cycle (or later) to fixup some of these issues? Or would you recommend pulling the patches out of Matt Porter's tree now, and reintroducing for 3.18? (I would be much happier with the first.) Things can always be un-queued. I guess that's Matt's and arm-soc's decision. Does that mean we should get all those patches un-queued, because that specific patch adding SMP support that needs to be reworked, or does that mean that if we drop this specific patch we are good with the remainder of the patch series? Well, keep in mind that there's no specific patch adding SMP support. The patch here contains *all* of the actual code that goes through mach-bcm. The rest will go through Russell. Given what was missed, if we drop just this patch, we're left with just the DT, Kconfig, and MAINTAINERS changes. It doesn't seem like there's time to fix the problems now. It might be better to drop the whole series from arm-soc since it won't be functional in 3.17 if we drop just this patch. I'd like to see what Arnd and Olof think. I think there's value in leaving all the DT bits for 3.17. -Matt -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] devicetree: bindings: document Broadcom CPU enable method
On Mon, Jun 30, 2014 at 05:09:45PM -0500, Alex Elder wrote: > Broadcom mobile SoCs use a ROM-implemented holding pen for > controlled boot of secondary cores. A special register is > used to communicate to the ROM that a secondary core should > start executing kernel code. This enable method is currently > used for members of the bcm281xx and bcm21664 SoC families. > > The use of an enable method also allows the SMP operation vector to > be assigned as a result of device tree content for these SoCs. > > Signed-off-by: Alex Elder Applied to mach-bcm for-3.17/dt Thanks, Matt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 0/4] ARM: SMP: support Broadcom mobile SoCs
On Mon, Jun 30, 2014 at 05:15:36PM -0500, Alex Elder wrote: > This series adds SMP support for two Broadcom mobile SoC families. > It uses CPU_METHOD_OF_DECLARE() so that SMP operations are assigned > using device tree rather than adding it to a machine definition in a > board file. > > The enable method starts a secondary core by writing to a register > monitored by CPUs spinning in a ROM-based holding pen loop. The > address of this register is recorded as a property in the "cpus" > node of the device tree. > > -Alex Applied the series to mach-bcm for-3.17/[soc|dt] Thanks, Matt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 0/4] ARM: SMP: support Broadcom mobile SoCs
On Mon, Jun 30, 2014 at 05:15:36PM -0500, Alex Elder wrote: This series adds SMP support for two Broadcom mobile SoC families. It uses CPU_METHOD_OF_DECLARE() so that SMP operations are assigned using device tree rather than adding it to a machine definition in a board file. The enable method starts a secondary core by writing to a register monitored by CPUs spinning in a ROM-based holding pen loop. The address of this register is recorded as a property in the cpus node of the device tree. -Alex Applied the series to mach-bcm for-3.17/[soc|dt] Thanks, Matt -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] devicetree: bindings: document Broadcom CPU enable method
On Mon, Jun 30, 2014 at 05:09:45PM -0500, Alex Elder wrote: Broadcom mobile SoCs use a ROM-implemented holding pen for controlled boot of secondary cores. A special register is used to communicate to the ROM that a secondary core should start executing kernel code. This enable method is currently used for members of the bcm281xx and bcm21664 SoC families. The use of an enable method also allows the SMP operation vector to be assigned as a result of device tree content for these SoCs. Signed-off-by: Alex Elder el...@linaro.org Applied to mach-bcm for-3.17/dt Thanks, Matt -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 00/11] ARM: brcmstb: Add Broadcom STB SoC support
On Tue, Jul 22, 2014 at 10:57:17PM +0200, Arnd Bergmann wrote:
> On Tuesday 22 July 2014 13:44:31 Brian Norris wrote:
> > > For the platform changes in the first patch, I would prefer to have
> > > Matt pick up the first patch, but we can also apply it directly into
> > > arm-soc if he prefers that.
> >
> > That brings up a question related to PATCH 11 in the series (MAINTAINERS
> > update); who will be maintaining arch/arm/mach-bcm/*brcmstb*, and how
> > will code go upstream? It seems like Matt and Christian are officially
> > mach-bcm maintainers, although I don't know if Christian is still
> > involved.
>
> You have to solve that question together with Matt. From my perspective
> it would be easier if I only have to deal with one person for mach-bcm,
> but it's really up to you.
>
>
> > Also, BCM7xxx shares little in common with the rest of mach-bcm, except
> > a company name, so we'd really like at least the 'Maintainer' entries
> > for the CC. I was planning on a separate git tree too, although it could
> > have conflicts if we touch arch/arm/mach-bcm/{Makefile,Kconfig}.
> >
> > So would we send a separate arm-soc pull request for the arm-soc
> > targeted changes (and all future development)?
>
> You can definitely have the separate MAINTAINERS entry without necessarily
> becoming a maintainer at the same level. I know Matt is very responsive
> and can forward your patches to arm-soc if that works for you.
We had this discussion wrt Hauke's BCM5301x support. The situation is
basically the same. To date, every instance of a BCM ARM SoC shares
nothing more than the company name and in some rare cases a piece of
licensed IP like the Arasan sdhci or dwc2. I can't recall who asked
for it, but I think Olof asked to have one pull request for all of
mach-bcm to keep things simple. So we ended up with:
BROADCOM BCM5301X ARM ARCHICTURE
M: Hauke Mehrtens
L: linux-arm-ker...@lists.infradead.org
S: Maintained
F: arch/arm/mach-bcm/bcm_5301x.c
F: arch/arm/boot/dts/bcm5301x.dtsi
F: arch/arm/boot/dts/bcm470*
which could be a model for BCM7xxx maintainership and Christian and I
can aggregate this stuff in the mach-bcm tree for pull requests to the
arm-soc team as we are doing now. bcm2835 is an exception case since
that was living elsewhere before the new platforms colocated in
mach-bcm.
> > For the reset of mach-bcm stuff, I'll just send an arm-soc pull request
> > soon enough, unless Matt/Arnd/Olof object.
>
> I'll wait for Matt to comment before pulling it, otherwise that sounds
> fine.
I'm fine with it, but we were asked to have one request for bcm5301x to
make life easy for the arm-soc team. If we want each platform to do pull
requests directly with arm-soc we should advise Hauke to do the same as
well with bcm5301x. I think the chances of Kconfig/Makefile conflicts are
relatively low as there's a dwindling amount of code of interest in new
platform mach directories like ours.
I would like to see a consistent path for all BCM platform maintainers.
-Matt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 00/11] ARM: brcmstb: Add Broadcom STB SoC support
On Tue, Jul 22, 2014 at 10:57:17PM +0200, Arnd Bergmann wrote:
On Tuesday 22 July 2014 13:44:31 Brian Norris wrote:
For the platform changes in the first patch, I would prefer to have
Matt pick up the first patch, but we can also apply it directly into
arm-soc if he prefers that.
That brings up a question related to PATCH 11 in the series (MAINTAINERS
update); who will be maintaining arch/arm/mach-bcm/*brcmstb*, and how
will code go upstream? It seems like Matt and Christian are officially
mach-bcm maintainers, although I don't know if Christian is still
involved.
You have to solve that question together with Matt. From my perspective
it would be easier if I only have to deal with one person for mach-bcm,
but it's really up to you.
Also, BCM7xxx shares little in common with the rest of mach-bcm, except
a company name, so we'd really like at least the 'Maintainer' entries
for the CC. I was planning on a separate git tree too, although it could
have conflicts if we touch arch/arm/mach-bcm/{Makefile,Kconfig}.
So would we send a separate arm-soc pull request for the arm-soc
targeted changes (and all future development)?
You can definitely have the separate MAINTAINERS entry without necessarily
becoming a maintainer at the same level. I know Matt is very responsive
and can forward your patches to arm-soc if that works for you.
We had this discussion wrt Hauke's BCM5301x support. The situation is
basically the same. To date, every instance of a BCM ARM SoC shares
nothing more than the company name and in some rare cases a piece of
licensed IP like the Arasan sdhci or dwc2. I can't recall who asked
for it, but I think Olof asked to have one pull request for all of
mach-bcm to keep things simple. So we ended up with:
BROADCOM BCM5301X ARM ARCHICTURE
M: Hauke Mehrtens ha...@hauke-m.de
L: linux-arm-ker...@lists.infradead.org
S: Maintained
F: arch/arm/mach-bcm/bcm_5301x.c
F: arch/arm/boot/dts/bcm5301x.dtsi
F: arch/arm/boot/dts/bcm470*
which could be a model for BCM7xxx maintainership and Christian and I
can aggregate this stuff in the mach-bcm tree for pull requests to the
arm-soc team as we are doing now. bcm2835 is an exception case since
that was living elsewhere before the new platforms colocated in
mach-bcm.
For the reset of mach-bcm stuff, I'll just send an arm-soc pull request
soon enough, unless Matt/Arnd/Olof object.
I'll wait for Matt to comment before pulling it, otherwise that sounds
fine.
I'm fine with it, but we were asked to have one request for bcm5301x to
make life easy for the arm-soc team. If we want each platform to do pull
requests directly with arm-soc we should advise Hauke to do the same as
well with bcm5301x. I think the chances of Kconfig/Makefile conflicts are
relatively low as there's a dwindling amount of code of interest in new
platform mach directories like ours.
I would like to see a consistent path for all BCM platform maintainers.
-Matt
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv7 2/5] mailbox: Introduce framework for mailbox
On Fri, Jun 20, 2014 at 01:59:30AM +0530, Jassi Brar wrote:
> On 20 June 2014 00:33, Matt Porter wrote:
> > On Thu, Jun 19, 2014 at 07:17:11PM +0100, Sudeep Holla wrote:
> >
> >> >+ * After startup and before shutdown any data received on the chan
> >> >+ * is passed on to the API via atomic mbox_chan_received_data().
> >> >+ * The controller should ACK the RX only after this call returns.
> >>
> >> Does this mean we can't support asynchronous messages from the remote.
> >> One possible scenario I can think is if the remote system power controller
> >> has feature to configure the bounds for thermal sensors and it can send
> >> async interrupt when the bounds are crossed. We can't just block one
> >> channel
> >> for this always. Again this might have been discussed before and you might
> >> have
> >> solution, I could not gather it with my brief look at older discussions.
> >
> > The way I see it we are simply putting the burden on the client to
> > implement very little in the rx_callback. In my case, we will have a
> > single client which is the IPC layer. The controller driver will notify
> > the IPC client layer which will do as little as possible in the
> > rx_callback before returning. We'll handle asynchronous dispatch of
> > events within our IPC layer to the real client drivers rather than in
> > the controller driver.
> >
> Yes. So do I.
>
> >> >+/**
> >> >+ * mbox_client_peek_data - A way for client driver to pull data
> >> >+ * received from remote by the controller.
> >> >+ * @chan: Mailbox channel assigned to this client.
> >> >+ *
> >> >+ * A poke to controller driver for any received data.
> >> >+ * The data is actually passed onto client via the
> >> >+ * mbox_chan_received_data()
> >> >+ * The call can be made from atomic context, so the controller's
> >> >+ * implementation of peek_data() must not sleep.
> >> >+ *
> >> >+ * Return: True, if controller has, and is going to push after this,
> >> >+ * some data.
> >> >+ * False, if controller doesn't have any data to be read.
> >> >+ */
> >> >+bool mbox_client_peek_data(struct mbox_chan *chan)
> >> >+{
> >> >+ if (chan->mbox->ops->peek_data)
> >> >+ return chan->mbox->ops->peek_data(chan);
> >> >+
> >> >+ return false;
> >> >+}
> >> >+EXPORT_SYMBOL_GPL(mbox_client_peek_data);
> >>
> >> I am unable to understand how this API will be used. IIUC when the
> >> controller
> >> receives any data from remote, it calls mbox_chan_received_data to push
> >> data to
> >> client.
> >
> > Good question.
> >
> > That function is a no-op if your client chooses not to populate
> > rx_callback. It's not explicitly stated, but the implementation is a
> > no-op if rx_callback is NULL so rx_callback seems to be intended as an
> > optional field in the client data.
> >
> > I'm also not clear of the scenario where this could be used. I
> > originally thought .peek_data() was an alternative to the callback for
> > polling purposes except it clearly states it needs the callback to carry
> > the data.
> >
> > I probably missed earlier discussion that explains this.
> >
> peek_data is just a trigger for controller to flush out any buffered
> RX via mbox_chan_received_data() to upper layer. Intended usecase is
> irq-mitigation for QMTM driver, as Arnd pointed out a few months ago.
Ok, that makes much more sense now.
Thanks,
Matt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv7 2/5] mailbox: Introduce framework for mailbox
On Fri, Jun 20, 2014 at 01:59:30AM +0530, Jassi Brar wrote:
On 20 June 2014 00:33, Matt Porter mpor...@linaro.org wrote:
On Thu, Jun 19, 2014 at 07:17:11PM +0100, Sudeep Holla wrote:
+ * After startup and before shutdown any data received on the chan
+ * is passed on to the API via atomic mbox_chan_received_data().
+ * The controller should ACK the RX only after this call returns.
Does this mean we can't support asynchronous messages from the remote.
One possible scenario I can think is if the remote system power controller
has feature to configure the bounds for thermal sensors and it can send
async interrupt when the bounds are crossed. We can't just block one
channel
for this always. Again this might have been discussed before and you might
have
solution, I could not gather it with my brief look at older discussions.
The way I see it we are simply putting the burden on the client to
implement very little in the rx_callback. In my case, we will have a
single client which is the IPC layer. The controller driver will notify
the IPC client layer which will do as little as possible in the
rx_callback before returning. We'll handle asynchronous dispatch of
events within our IPC layer to the real client drivers rather than in
the controller driver.
Yes. So do I.
+/**
+ * mbox_client_peek_data - A way for client driver to pull data
+ * received from remote by the controller.
+ * @chan: Mailbox channel assigned to this client.
+ *
+ * A poke to controller driver for any received data.
+ * The data is actually passed onto client via the
+ * mbox_chan_received_data()
+ * The call can be made from atomic context, so the controller's
+ * implementation of peek_data() must not sleep.
+ *
+ * Return: True, if controller has, and is going to push after this,
+ * some data.
+ * False, if controller doesn't have any data to be read.
+ */
+bool mbox_client_peek_data(struct mbox_chan *chan)
+{
+ if (chan-mbox-ops-peek_data)
+ return chan-mbox-ops-peek_data(chan);
+
+ return false;
+}
+EXPORT_SYMBOL_GPL(mbox_client_peek_data);
I am unable to understand how this API will be used. IIUC when the
controller
receives any data from remote, it calls mbox_chan_received_data to push
data to
client.
Good question.
That function is a no-op if your client chooses not to populate
rx_callback. It's not explicitly stated, but the implementation is a
no-op if rx_callback is NULL so rx_callback seems to be intended as an
optional field in the client data.
I'm also not clear of the scenario where this could be used. I
originally thought .peek_data() was an alternative to the callback for
polling purposes except it clearly states it needs the callback to carry
the data.
I probably missed earlier discussion that explains this.
peek_data is just a trigger for controller to flush out any buffered
RX via mbox_chan_received_data() to upper layer. Intended usecase is
irq-mitigation for QMTM driver, as Arnd pointed out a few months ago.
Ok, that makes much more sense now.
Thanks,
Matt
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] regulator: bcm590xx: fix vbus name
On Wed, Jun 18, 2014 at 12:42:10PM -0700, Graham Williams wrote:
> The vbus regulator was not getting its name set. This results
> in the sysfs entry being empty. The lack of a bcm590xx_regs[]
> table entry also upsets Coverity runs. Add the table entry
> so the name gets set properly.
>
> Signed-off-by: Graham Williams
> ---
> drivers/regulator/bcm590xx-regulator.c |5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/regulator/bcm590xx-regulator.c
> b/drivers/regulator/bcm590xx-regulator.c
> index 57544e2..58ece59 100644
> --- a/drivers/regulator/bcm590xx-regulator.c
> +++ b/drivers/regulator/bcm590xx-regulator.c
> @@ -119,6 +119,10 @@ static const unsigned int ldo_c_table[] = {
> 290, 300, 330,
> };
>
> +static const unsigned int ldo_vbus[] = {
> + 500,
> +};
> +
> /* DCDC group CSR: supported voltages in microvolts */
> static const struct regulator_linear_range dcdc_csr_ranges[] = {
> REGULATOR_LINEAR_RANGE(86, 2, 50, 1),
> @@ -192,6 +196,7 @@ static struct bcm590xx_info bcm590xx_regs[] = {
> BCM590XX_REG_TABLE(gpldo4, ldo_a_table),
> BCM590XX_REG_TABLE(gpldo5, ldo_a_table),
> BCM590XX_REG_TABLE(gpldo6, ldo_a_table),
> + BCM590XX_REG_TABLE(vbus, ldo_vbus),
> };
Also fixes the functional problem for me on the Capri board, thanks.
Coverity should also be much happier now.
Acked-by: Matt Porter
Mark: can you pick this up for 3.16 fixes?
-Matt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] regulator: bcm590xx: fix vbus name
On Wed, Jun 18, 2014 at 12:42:10PM -0700, Graham Williams wrote:
The vbus regulator was not getting its name set. This results
in the sysfs entry being empty. The lack of a bcm590xx_regs[]
table entry also upsets Coverity runs. Add the table entry
so the name gets set properly.
Signed-off-by: Graham Williams graham.willi...@linaro.org
---
drivers/regulator/bcm590xx-regulator.c |5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/regulator/bcm590xx-regulator.c
b/drivers/regulator/bcm590xx-regulator.c
index 57544e2..58ece59 100644
--- a/drivers/regulator/bcm590xx-regulator.c
+++ b/drivers/regulator/bcm590xx-regulator.c
@@ -119,6 +119,10 @@ static const unsigned int ldo_c_table[] = {
290, 300, 330,
};
+static const unsigned int ldo_vbus[] = {
+ 500,
+};
+
/* DCDC group CSR: supported voltages in microvolts */
static const struct regulator_linear_range dcdc_csr_ranges[] = {
REGULATOR_LINEAR_RANGE(86, 2, 50, 1),
@@ -192,6 +196,7 @@ static struct bcm590xx_info bcm590xx_regs[] = {
BCM590XX_REG_TABLE(gpldo4, ldo_a_table),
BCM590XX_REG_TABLE(gpldo5, ldo_a_table),
BCM590XX_REG_TABLE(gpldo6, ldo_a_table),
+ BCM590XX_REG_TABLE(vbus, ldo_vbus),
};
Also fixes the functional problem for me on the Capri board, thanks.
Coverity should also be much happier now.
Acked-by: Matt Porter mpor...@linaro.org
Mark: can you pick this up for 3.16 fixes?
-Matt
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: regulator: bcm590xx: Add support for regulators on secondary I2C slave
On Mon, Jun 16, 2014 at 09:06:01AM +0100, Lee Jones wrote: > On Tue, 10 Jun 2014, Dave Jones wrote: > > On Tue, Jun 03, 2014 at 07:29:10PM +, Linux Kernel wrote: > > > Gitweb: > > http://git.kernel.org/linus/;a=commit;h=c6466950e917890be3050171f6745ccb9d91d35f > > > Commit: c6466950e917890be3050171f6745ccb9d91d35f > > > Parent: 9e1e726311830bc5b8b568d5178f6a52c357fb6e > > > Refname:refs/heads/next > > > Author: Matt Porter > > > AuthorDate: Wed Apr 23 19:21:32 2014 -0400 > > > Committer: Lee Jones > > > CommitDate: Wed May 21 10:40:16 2014 +0100 > > > > > > regulator: bcm590xx: Add support for regulators on secondary I2C > > slave > > > > > > The bcm590xx MFD driver now exposes a secondary regmap descriptor > > > making the registers for regulators on the secondary I2C slave > > address > > > available. Add support for GPLDO1-6 and VBUS regulators found within > > > this register range. > > > > > -#define BCM590XX_NUM_REGS 20 > > > +#define BCM590XX_NUM_REGS 27 > > > > Coverity picked up that this change has introduced a out of bounds read. > > The loop in bcm590xx_probe iterates from 0 to NUM_REGS, > > but the bcm590xx_regs struct it iterates over using the ptr 'info' is only > > 26 > > elements. > > Nice little tool. :) Indeed > Matt, I assume you'll fix this yourself? Yes, we actually found this from functional tests before Dave's coverity run found it. Graham Williams is going to post a patch that fixes this issue since he noticed it while working on some dwc2 support. -Matt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: regulator: bcm590xx: Add support for regulators on secondary I2C slave
On Mon, Jun 16, 2014 at 09:06:01AM +0100, Lee Jones wrote: On Tue, 10 Jun 2014, Dave Jones wrote: On Tue, Jun 03, 2014 at 07:29:10PM +, Linux Kernel wrote: Gitweb: http://git.kernel.org/linus/;a=commit;h=c6466950e917890be3050171f6745ccb9d91d35f Commit: c6466950e917890be3050171f6745ccb9d91d35f Parent: 9e1e726311830bc5b8b568d5178f6a52c357fb6e Refname:refs/heads/next Author: Matt Porter mpor...@linaro.org AuthorDate: Wed Apr 23 19:21:32 2014 -0400 Committer: Lee Jones lee.jo...@linaro.org CommitDate: Wed May 21 10:40:16 2014 +0100 regulator: bcm590xx: Add support for regulators on secondary I2C slave The bcm590xx MFD driver now exposes a secondary regmap descriptor making the registers for regulators on the secondary I2C slave address available. Add support for GPLDO1-6 and VBUS regulators found within this register range. -#define BCM590XX_NUM_REGS 20 +#define BCM590XX_NUM_REGS 27 Coverity picked up that this change has introduced a out of bounds read. The loop in bcm590xx_probe iterates from 0 to NUM_REGS, but the bcm590xx_regs struct it iterates over using the ptr 'info' is only 26 elements. Nice little tool. :) Indeed Matt, I assume you'll fix this yourself? Yes, we actually found this from functional tests before Dave's coverity run found it. Graham Williams is going to post a patch that fixes this issue since he noticed it while working on some dwc2 support. -Matt -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv5 2/4] mailbox: Introduce framework for mailbox
On Tue, Jun 03, 2014 at 03:51:55PM +0530, Jassi Brar wrote:
> On 3 June 2014 15:05, Sudeep Holla wrote:
> > Hi Jassi,
> >
> > On Mon, Jun 2, 2014 at 6:11 PM, Jassi Brar wrote:
> >> On Mon, Jun 2, 2014 at 8:44 PM, Matt Porter wrote:
> >>> On Fri, May 30, 2014 at 11:01:55AM +0530, Jassi Brar wrote:
> >>>
> >>>> Being more specific to your platform, I think you need some server
> >>>> code (mailbox's client) that every driver (like clock, pmu, pinmux
> >>>> etc) registers with to send messages to remote and receive commands
> >>>> from remote ... perhaps by registering some filter to sort out
> >>>> messages for each driver.
> >>>
> >>> Right, and here's where you hit on the problem. This server you mention
> >>> is not a piece of hardware, it would be a software construct. As such, it
> >>> doesn't fit into the DT binding as it exists. It's probably best to
> >>> illustrate in DT syntax.
> >>>
> >>> If I were to represent the hardware relationship in the DT binding now
> >>> it would look like this:
> >>>
> >>> ---
> >>> cpm: mailbox@deadbeef {
> >>> compatible = "brcm,bcm-cpm-mailbox";
> >>> reg = <...>;
> >>> #mbox-cells <1>;
> >>> interrupts = <...>;
> >>> };
> >>>
> >>> /* clock complex */
> >>> ccu {
> >>> compatible = "brcm,bcm-foo-ccu";
> >>> mbox = < CPM_SYSTEM_CHANNEL>;
> >>> mbox-names = "system";
> >>> /* leaving out other mailboxes for brevity */
> >>> #clock-cells <1>;
> >>> clock-output-names = "bar",
> >>> "baz";
> >>> };
> >>>
> >>> pmu {
> >>> compatible = "brcm,bcm-foo-pmu"
> >>> mbox = < CPM_SYSTEM_CHANNEL>;
> >>> mbox-names = "system";
> >>> };
> >>>
> >>> pinmux {
> >>> compatible = "brcm,bcm-foo-pinctrl";
> >>> mbox = < CPM_SYSTEM_CHANNEL>;
> >>> mbox-names = "system";
> >>> };
> >>> ---
> >> Yeah, I too don't think its a good idea.
> >>
> >>
> >>> What we would need to do is completely ignore this information in each
> >>> of the of the client drivers associated with the clock, pmu, and pinmux
> >>> devices. This IPC server would need to be instantiated and get the
> >>> mailbox information from some source. mbox_request_channel() only works
> >>> when the client has an of_node with the mbox-names property present.
> >>> Let's say we follow this model and represent it in DT:
> >>>
> >>> --
> >>> cpm: mailbox@deadbeef {
> >>> compatible = "brcm,bcm-cpm-mailbox";
> >>> reg = <...>;
> >>> #mbox-cells <1>;
> >>> interrupts = <...>;
> >>> };
> >>>
> >>> cpm_ipc {
> >>> compatible = "brcm,bcm-cpm-ipc";
> >>> mbox = < CPM_SYSTEM_CHANNEL>;
> >>> mbox-names = "system";
> >>> /* leaving out other mailboxes for brevity */
> >>> };
> >>> ---
> >>>
> >>> This would allow an ipc driver to exclusively own this system channel,
> >>> but now we've invented a binding that doesn't reflect the hardware at
> >>> all. It's describing software so I don't believe the DT maintainers will
> >>> allow this type of construct.
> >>>
> >> Must the server node specify MMIO and an IRQ, to be acceptable? Like ...
> >>
> >> cpm_ipc : cpm@deadbeef {
> >> compatible = "brcm,bcm-cpm-ipc";
> >>/* reg = <0xdeadbeef 0x100>; */
> >>/* interrupts = <0 123 4>; */
> >> mbox = < CPM_SYSTEM_CHANNEL>;
> >> mbox-names = "system";
> >> };
> >>
> >> cpm_ipc already specifies a hardware resource (mbox) that its driver
> >> needs, I think that should be enough reason. If it were some purely
> >> soft property for the driver like
> >> mode = "poll"; //
Re: [PATCHv6 2/3] mailbox: Introduce framework for mailbox
On Tue, Jun 03, 2014 at 12:01:24AM +0530, Jassi Brar wrote: > Introduce common framework for client/protocol drivers and > controller drivers of Inter-Processor-Communication (IPC). > > Client driver developers should have a look at > include/linux/mailbox_client.h to understand the part of > the API exposed to client drivers. > Similarly controller driver developers should have a look > at include/linux/mailbox_controller.h > > Signed-off-by: Jassi Brar > --- > .../devicetree/bindings/mailbox/mailbox.txt| 33 ++ > drivers/mailbox/Makefile | 4 + > drivers/mailbox/mailbox.c | 487 > + > include/linux/mailbox_client.h | 45 ++ > include/linux/mailbox_controller.h | 121 + Could you please include all the DT maintainers here? It's a generic binding that needs wider review and an ack. The binding should be separated as noted below. >From Documentations/devicetree/bindings/submitting-patches.txt: I. For patch submitters 0) Normal patch submission rules from Documentation/SubmittingPatches applies. 1) The Documentation/ portion of the patch should be a separate patch. 2) Submit the entire series to the devicetree mailinglist at devicet...@vger.kernel.org -Matt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv6 2/3] mailbox: Introduce framework for mailbox
On Tue, Jun 03, 2014 at 12:01:24AM +0530, Jassi Brar wrote: Introduce common framework for client/protocol drivers and controller drivers of Inter-Processor-Communication (IPC). Client driver developers should have a look at include/linux/mailbox_client.h to understand the part of the API exposed to client drivers. Similarly controller driver developers should have a look at include/linux/mailbox_controller.h Signed-off-by: Jassi Brar jaswinder.si...@linaro.org --- .../devicetree/bindings/mailbox/mailbox.txt| 33 ++ drivers/mailbox/Makefile | 4 + drivers/mailbox/mailbox.c | 487 + include/linux/mailbox_client.h | 45 ++ include/linux/mailbox_controller.h | 121 + Could you please include all the DT maintainers here? It's a generic binding that needs wider review and an ack. The binding should be separated as noted below. From Documentations/devicetree/bindings/submitting-patches.txt: I. For patch submitters 0) Normal patch submission rules from Documentation/SubmittingPatches applies. 1) The Documentation/ portion of the patch should be a separate patch. 2) Submit the entire series to the devicetree mailinglist at devicet...@vger.kernel.org -Matt -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv5 2/4] mailbox: Introduce framework for mailbox
On Tue, Jun 03, 2014 at 03:51:55PM +0530, Jassi Brar wrote:
On 3 June 2014 15:05, Sudeep Holla sudeep.ho...@arm.com wrote:
Hi Jassi,
On Mon, Jun 2, 2014 at 6:11 PM, Jassi Brar jassisinghb...@gmail.com wrote:
On Mon, Jun 2, 2014 at 8:44 PM, Matt Porter mpor...@linaro.org wrote:
On Fri, May 30, 2014 at 11:01:55AM +0530, Jassi Brar wrote:
Being more specific to your platform, I think you need some server
code (mailbox's client) that every driver (like clock, pmu, pinmux
etc) registers with to send messages to remote and receive commands
from remote ... perhaps by registering some filter to sort out
messages for each driver.
Right, and here's where you hit on the problem. This server you mention
is not a piece of hardware, it would be a software construct. As such, it
doesn't fit into the DT binding as it exists. It's probably best to
illustrate in DT syntax.
If I were to represent the hardware relationship in the DT binding now
it would look like this:
---
cpm: mailbox@deadbeef {
compatible = brcm,bcm-cpm-mailbox;
reg = ...;
#mbox-cells 1;
interrupts = ...;
};
/* clock complex */
ccu {
compatible = brcm,bcm-foo-ccu;
mbox = cpm CPM_SYSTEM_CHANNEL;
mbox-names = system;
/* leaving out other mailboxes for brevity */
#clock-cells 1;
clock-output-names = bar,
baz;
};
pmu {
compatible = brcm,bcm-foo-pmu
mbox = cpm CPM_SYSTEM_CHANNEL;
mbox-names = system;
};
pinmux {
compatible = brcm,bcm-foo-pinctrl;
mbox = cpm CPM_SYSTEM_CHANNEL;
mbox-names = system;
};
---
Yeah, I too don't think its a good idea.
What we would need to do is completely ignore this information in each
of the of the client drivers associated with the clock, pmu, and pinmux
devices. This IPC server would need to be instantiated and get the
mailbox information from some source. mbox_request_channel() only works
when the client has an of_node with the mbox-names property present.
Let's say we follow this model and represent it in DT:
--
cpm: mailbox@deadbeef {
compatible = brcm,bcm-cpm-mailbox;
reg = ...;
#mbox-cells 1;
interrupts = ...;
};
cpm_ipc {
compatible = brcm,bcm-cpm-ipc;
mbox = cpm CPM_SYSTEM_CHANNEL;
mbox-names = system;
/* leaving out other mailboxes for brevity */
};
---
This would allow an ipc driver to exclusively own this system channel,
but now we've invented a binding that doesn't reflect the hardware at
all. It's describing software so I don't believe the DT maintainers will
allow this type of construct.
Must the server node specify MMIO and an IRQ, to be acceptable? Like ...
cpm_ipc : cpm@deadbeef {
compatible = brcm,bcm-cpm-ipc;
/* reg = 0xdeadbeef 0x100; */
/* interrupts = 0 123 4; */
mbox = cpm CPM_SYSTEM_CHANNEL;
mbox-names = system;
};
cpm_ipc already specifies a hardware resource (mbox) that its driver
needs, I think that should be enough reason. If it were some purely
soft property for the driver like
mode = poll; //or irq
then the node wouldn't be justified because that is the job of a
build-time config or run-time module option.
Like Matt, I am also in similar situation where there's a lot of common
code necessary to construct/parse IPCs for each of the drivers using the
mailbox.
As per your suggestion if we have single DT node to specify both the
controller and the client, we might still have to pollute this node with
software specific compatibles.
I am afraid you misunderstood me. I don't suggest single node for
mailbox controller and client, and IIUC, neither did Matt. Please note
the controller is cpm and client is cpm_ipc.
Correct, I had separate controller and consumer nodes as written
above...to match the binding.
BTW, here we at least have a hardware resource to specify in the DT
node, there are examples in kernel where the DT nodes are purely
virtual. For ex, grep for linux,spdif-dit. So I think we should be
ok.
There's a bit of a difference between my concern over a virtual node and
this example you've cited. In the dummy spdif transmitter, it's defining
a virtual device that plugs in for a codec, a hardware concept well
defined in the audio bindings. I agree that there are many examples of
this type of virtual node, including dummy phys, but in all cases they
are stubbing out a real hardware concept.
I find it to be distinctly different to create a node that doesn't
represent the hardware's use of mailboxes. I'd be happy if a DT
maintainer could say that this is acceptable though. ;)
-Matt
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More
Re: [PATCH 1/3] regulator: bcm590xx: remove unnecessary OOM messages
On Mon, Jun 02, 2014 at 03:27:21PM +0900, Jingoo Han wrote:
> The site-specific OOM messages are unnecessary, because they
> duplicate the MM subsystem generic OOM message.
>
> Signed-off-by: Jingoo Han
> ---
> drivers/regulator/bcm590xx-regulator.c | 16
> 1 file changed, 4 insertions(+), 12 deletions(-)
Looks good, thanks.
Acked-by: Matt Porter
> diff --git a/drivers/regulator/bcm590xx-regulator.c
> b/drivers/regulator/bcm590xx-regulator.c
> index 57544e2..fb8c6f7 100644
> --- a/drivers/regulator/bcm590xx-regulator.c
> +++ b/drivers/regulator/bcm590xx-regulator.c
> @@ -326,10 +326,8 @@ static struct bcm590xx_board *bcm590xx_parse_dt_reg_data(
> }
>
> data = devm_kzalloc(>dev, sizeof(*data), GFP_KERNEL);
> - if (!data) {
> - dev_err(>dev, "failed to allocate regulator board
> data\n");
> + if (!data)
> return NULL;
> - }
>
> np = of_node_get(np);
> regulators = of_get_child_by_name(np, "regulators");
> @@ -374,10 +372,8 @@ static int bcm590xx_probe(struct platform_device *pdev)
> _reg_matches);
>
> pmu = devm_kzalloc(>dev, sizeof(*pmu), GFP_KERNEL);
> - if (!pmu) {
> - dev_err(>dev, "Memory allocation failed for pmu\n");
> + if (!pmu)
> return -ENOMEM;
> - }
>
> pmu->mfd = bcm590xx;
>
> @@ -385,17 +381,13 @@ static int bcm590xx_probe(struct platform_device *pdev)
>
> pmu->desc = devm_kzalloc(>dev, BCM590XX_NUM_REGS *
> sizeof(struct regulator_desc), GFP_KERNEL);
> - if (!pmu->desc) {
> - dev_err(>dev, "Memory alloc fails for desc\n");
> + if (!pmu->desc)
> return -ENOMEM;
> - }
>
> pmu->info = devm_kzalloc(>dev, BCM590XX_NUM_REGS *
> sizeof(struct bcm590xx_info *), GFP_KERNEL);
> - if (!pmu->info) {
> - dev_err(>dev, "Memory alloc fails for info\n");
> + if (!pmu->info)
> return -ENOMEM;
> - }
>
> info = bcm590xx_regs;
>
> --
> 1.7.10.4
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] regulator: bcm590xx: remove unnecessary OOM messages
On Mon, Jun 02, 2014 at 03:27:21PM +0900, Jingoo Han wrote:
The site-specific OOM messages are unnecessary, because they
duplicate the MM subsystem generic OOM message.
Signed-off-by: Jingoo Han jg1@samsung.com
---
drivers/regulator/bcm590xx-regulator.c | 16
1 file changed, 4 insertions(+), 12 deletions(-)
Looks good, thanks.
Acked-by: Matt Porter mpor...@linaro.org
diff --git a/drivers/regulator/bcm590xx-regulator.c
b/drivers/regulator/bcm590xx-regulator.c
index 57544e2..fb8c6f7 100644
--- a/drivers/regulator/bcm590xx-regulator.c
+++ b/drivers/regulator/bcm590xx-regulator.c
@@ -326,10 +326,8 @@ static struct bcm590xx_board *bcm590xx_parse_dt_reg_data(
}
data = devm_kzalloc(pdev-dev, sizeof(*data), GFP_KERNEL);
- if (!data) {
- dev_err(pdev-dev, failed to allocate regulator board
data\n);
+ if (!data)
return NULL;
- }
np = of_node_get(np);
regulators = of_get_child_by_name(np, regulators);
@@ -374,10 +372,8 @@ static int bcm590xx_probe(struct platform_device *pdev)
bcm590xx_reg_matches);
pmu = devm_kzalloc(pdev-dev, sizeof(*pmu), GFP_KERNEL);
- if (!pmu) {
- dev_err(pdev-dev, Memory allocation failed for pmu\n);
+ if (!pmu)
return -ENOMEM;
- }
pmu-mfd = bcm590xx;
@@ -385,17 +381,13 @@ static int bcm590xx_probe(struct platform_device *pdev)
pmu-desc = devm_kzalloc(pdev-dev, BCM590XX_NUM_REGS *
sizeof(struct regulator_desc), GFP_KERNEL);
- if (!pmu-desc) {
- dev_err(pdev-dev, Memory alloc fails for desc\n);
+ if (!pmu-desc)
return -ENOMEM;
- }
pmu-info = devm_kzalloc(pdev-dev, BCM590XX_NUM_REGS *
sizeof(struct bcm590xx_info *), GFP_KERNEL);
- if (!pmu-info) {
- dev_err(pdev-dev, Memory alloc fails for info\n);
+ if (!pmu-info)
return -ENOMEM;
- }
info = bcm590xx_regs;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv5 2/4] mailbox: Introduce framework for mailbox
[Adding devicetree list]
On Mon, Jun 02, 2014 at 10:41:44PM +0530, Jassi Brar wrote:
> On Mon, Jun 2, 2014 at 8:44 PM, Matt Porter wrote:
> > On Fri, May 30, 2014 at 11:01:55AM +0530, Jassi Brar wrote:
> >
> >> Being more specific to your platform, I think you need some server
> >> code (mailbox's client) that every driver (like clock, pmu, pinmux
> >> etc) registers with to send messages to remote and receive commands
> >> from remote ... perhaps by registering some filter to sort out
> >> messages for each driver.
> >
> > Right, and here's where you hit on the problem. This server you mention
> > is not a piece of hardware, it would be a software construct. As such, it
> > doesn't fit into the DT binding as it exists. It's probably best to
> > illustrate in DT syntax.
> >
> > If I were to represent the hardware relationship in the DT binding now
> > it would look like this:
> >
> > ---
> > cpm: mailbox@deadbeef {
> > compatible = "brcm,bcm-cpm-mailbox";
> > reg = <...>;
> > #mbox-cells <1>;
> > interrupts = <...>;
> > };
> >
> > /* clock complex */
> > ccu {
> > compatible = "brcm,bcm-foo-ccu";
> > mbox = < CPM_SYSTEM_CHANNEL>;
> > mbox-names = "system";
> > /* leaving out other mailboxes for brevity */
> > #clock-cells <1>;
> > clock-output-names = "bar",
> > "baz";
> > };
> >
> > pmu {
> > compatible = "brcm,bcm-foo-pmu"
> > mbox = < CPM_SYSTEM_CHANNEL>;
> > mbox-names = "system";
> > };
> >
> > pinmux {
> > compatible = "brcm,bcm-foo-pinctrl";
> > mbox = < CPM_SYSTEM_CHANNEL>;
> > mbox-names = "system";
> > };
> > ---
> Yeah, I too don't think its a good idea.
>
>
> > What we would need to do is completely ignore this information in each
> > of the of the client drivers associated with the clock, pmu, and pinmux
> > devices. This IPC server would need to be instantiated and get the
> > mailbox information from some source. mbox_request_channel() only works
> > when the client has an of_node with the mbox-names property present.
> > Let's say we follow this model and represent it in DT:
> >
> > --
> > cpm: mailbox@deadbeef {
> > compatible = "brcm,bcm-cpm-mailbox";
> > reg = <...>;
> > #mbox-cells <1>;
> > interrupts = <...>;
> > };
> >
> > cpm_ipc {
> > compatible = "brcm,bcm-cpm-ipc";
> > mbox = < CPM_SYSTEM_CHANNEL>;
> > mbox-names = "system";
> > /* leaving out other mailboxes for brevity */
> > };
> > ---
> >
> > This would allow an ipc driver to exclusively own this system channel,
> > but now we've invented a binding that doesn't reflect the hardware at
> > all. It's describing software so I don't believe the DT maintainers will
> > allow this type of construct.
> >
> Must the server node specify MMIO and an IRQ, to be acceptable? Like ...
My bad, that was a cut and paste typo..I intended to remove those
properties as you do below.
>
> cpm_ipc : cpm@deadbeef {
> compatible = "brcm,bcm-cpm-ipc";
>/* reg = <0xdeadbeef 0x100>; */
>/* interrupts = <0 123 4>; */
> mbox = < CPM_SYSTEM_CHANNEL>;
> mbox-names = "system";
> };
Correct, this should have been:
cpm_ipc {
compatible = "brcm,bcm-cpm-ipc";
mbox = < CPM_SYSTEM_CHANNEL>;
mbox-names = "system";
};
> cpm_ipc already specifies a hardware resource (mbox) that its driver
> needs, I think that should be enough reason. If it were some purely
> soft property for the driver like
> mode = "poll"; //or "irq"
> then the node wouldn't be justified because that is the job of a
> build-time config or run-time module option.
Hrm, this is where I'd like to hear from the DT maintainers since we
have to live with this generic binding. If they are ok with us creating
bindings for a virtual device that exists only to match with our ipc
driver then it will work. I'm not aware of other similar examples though.
-Matt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv5 2/4] mailbox: Introduce framework for mailbox
On Fri, May 30, 2014 at 11:01:55AM +0530, Jassi Brar wrote:
> On Thu, May 29, 2014 at 9:13 PM, Matt Porter wrote:
> > On Fri, May 16, 2014 at 07:03:25PM +0530, Jassi Brar wrote:
> >> On 15 May 2014 19:57, Arnd Bergmann wrote:
> >> > On Thursday 15 May 2014 11:41:00 Jassi Brar wrote:
> >
> > ...
> >
> >> >> +struct mbox_controller {
> >> >> + struct device *dev;
> >> >> + struct mbox_chan_ops *ops;
> >> >> + struct mbox_chan *chans;
> >> >> + int num_chans;
> >> >> + bool txdone_irq;
> >> >> + bool txdone_poll;
> >> >> + unsigned txpoll_period;
> >> >> + struct mbox_chan *(*of_xlate)(struct mbox_controller *mbox,
> >> >> + const struct of_phandle_args *sp);
> >> >> + /*
> >> >> + * If the controller supports only TXDONE_BY_POLL,
> >> >> + * this timer polls all the links for txdone.
> >> >> + */
> >> >> + struct timer_list poll;
> >> >> + unsigned period;
> >> >> + /* Hook to add to the global controller list */
> >> >> + struct list_head node;
> >> >> +} __aligned(32);
> >> >
> >> > What is the __aligned(32) for?
> >> >
> >> Attempt to align access to mailbox?
> >>
> >> I am still open to opinion about whether the mailbox ownership should
> >> be exclusive or shared among clients. Need to handle async messages
> >> from remote is one reason one might want more than one client to own a
> >> channel. Allowing for RX via notifiers might be one option but that
> >> breaks semantics of 'ownership' of a mailbox channel.
> >
> > This is the case we have on a new family of Broadcom SoCs. One mailbox
> > channel is the "system" channel and is shared amongst many clients for
> > reception of unsolicited events from the coprocessor. The same channel
> > is also used commonly in drivers for debug/inspection of the M0 state.
> > Functionality for clock, pmu, pinmux, and cpu idle/suspend is implemented
> > via IPC with the M0 so all of those drivers need to share one mailbox.
> >
> OK, so you have a single mailbox channel used for communication with
> the remote master.
Yes, specifically, single mailbox channel is shared by many clients
for interrupt events.
>
> > There's a lot of common code necessary to construct/parse IPCs for
> > each of the drivers. I suppose this IPC driver/api could be the
> > sole owner of that system channel. However, we'd need to develop some
> > binding to represent IPC resources that devices need to operate. Coming
> > into this late...I wonder if I missed something about where these vendor
> > specific IPC layers should live and how, if it makes sense, they should
> > be represented in DT. In our case, the IPC is an integral part of the
> > hardware as it's loaded from ROM.
> >
> Like other platforms, the IPC protocol is going to be very specific to
> Broadcom, even if the mailbox controller is some popular third party
> IP like PL320. So you/Broadcom have to implement parser code for IPC
> (client) above the mailbox common api and the controller driver below
> it. Any resource/feature specific to your client and your controller
> should be passed via some Broadcom specific DT bindings. The common
> mailbox api DT bindings provide only for channel-client mapping.
Agreed.
> Being more specific to your platform, I think you need some server
> code (mailbox's client) that every driver (like clock, pmu, pinmux
> etc) registers with to send messages to remote and receive commands
> from remote ... perhaps by registering some filter to sort out
> messages for each driver.
Right, and here's where you hit on the problem. This server you mention
is not a piece of hardware, it would be a software construct. As such, it
doesn't fit into the DT binding as it exists. It's probably best to
illustrate in DT syntax.
If I were to represent the hardware relationship in the DT binding now
it would look like this:
---
cpm: mailbox@deadbeef {
compatible = "brcm,bcm-cpm-mailbox";
reg = <...>;
#mbox-cells <1>;
interrupts = <...>;
};
/* clock complex */
ccu {
compatible = "brcm,bcm-foo-ccu";
mbox = < CPM_SYSTEM_CHANNEL>;
mbox-names = "system";
/* leaving out other mailboxes for brevity */
#clock-cells <1>;
clock-output-names = "bar",
"
Re: [PATCHv5 2/4] mailbox: Introduce framework for mailbox
On Fri, May 30, 2014 at 11:01:55AM +0530, Jassi Brar wrote:
On Thu, May 29, 2014 at 9:13 PM, Matt Porter mpor...@linaro.org wrote:
On Fri, May 16, 2014 at 07:03:25PM +0530, Jassi Brar wrote:
On 15 May 2014 19:57, Arnd Bergmann a...@arndb.de wrote:
On Thursday 15 May 2014 11:41:00 Jassi Brar wrote:
...
+struct mbox_controller {
+ struct device *dev;
+ struct mbox_chan_ops *ops;
+ struct mbox_chan *chans;
+ int num_chans;
+ bool txdone_irq;
+ bool txdone_poll;
+ unsigned txpoll_period;
+ struct mbox_chan *(*of_xlate)(struct mbox_controller *mbox,
+ const struct of_phandle_args *sp);
+ /*
+ * If the controller supports only TXDONE_BY_POLL,
+ * this timer polls all the links for txdone.
+ */
+ struct timer_list poll;
+ unsigned period;
+ /* Hook to add to the global controller list */
+ struct list_head node;
+} __aligned(32);
What is the __aligned(32) for?
Attempt to align access to mailbox?
I am still open to opinion about whether the mailbox ownership should
be exclusive or shared among clients. Need to handle async messages
from remote is one reason one might want more than one client to own a
channel. Allowing for RX via notifiers might be one option but that
breaks semantics of 'ownership' of a mailbox channel.
This is the case we have on a new family of Broadcom SoCs. One mailbox
channel is the system channel and is shared amongst many clients for
reception of unsolicited events from the coprocessor. The same channel
is also used commonly in drivers for debug/inspection of the M0 state.
Functionality for clock, pmu, pinmux, and cpu idle/suspend is implemented
via IPC with the M0 so all of those drivers need to share one mailbox.
OK, so you have a single mailbox channel used for communication with
the remote master.
Yes, specifically, single mailbox channel is shared by many clients
for interrupt events.
There's a lot of common code necessary to construct/parse IPCs for
each of the drivers. I suppose this IPC driver/api could be the
sole owner of that system channel. However, we'd need to develop some
binding to represent IPC resources that devices need to operate. Coming
into this late...I wonder if I missed something about where these vendor
specific IPC layers should live and how, if it makes sense, they should
be represented in DT. In our case, the IPC is an integral part of the
hardware as it's loaded from ROM.
Like other platforms, the IPC protocol is going to be very specific to
Broadcom, even if the mailbox controller is some popular third party
IP like PL320. So you/Broadcom have to implement parser code for IPC
(client) above the mailbox common api and the controller driver below
it. Any resource/feature specific to your client and your controller
should be passed via some Broadcom specific DT bindings. The common
mailbox api DT bindings provide only for channel-client mapping.
Agreed.
Being more specific to your platform, I think you need some server
code (mailbox's client) that every driver (like clock, pmu, pinmux
etc) registers with to send messages to remote and receive commands
from remote ... perhaps by registering some filter to sort out
messages for each driver.
Right, and here's where you hit on the problem. This server you mention
is not a piece of hardware, it would be a software construct. As such, it
doesn't fit into the DT binding as it exists. It's probably best to
illustrate in DT syntax.
If I were to represent the hardware relationship in the DT binding now
it would look like this:
---
cpm: mailbox@deadbeef {
compatible = brcm,bcm-cpm-mailbox;
reg = ...;
#mbox-cells 1;
interrupts = ...;
};
/* clock complex */
ccu {
compatible = brcm,bcm-foo-ccu;
mbox = cpm CPM_SYSTEM_CHANNEL;
mbox-names = system;
/* leaving out other mailboxes for brevity */
#clock-cells 1;
clock-output-names = bar,
baz;
};
pmu {
compatible = brcm,bcm-foo-pmu
mbox = cpm CPM_SYSTEM_CHANNEL;
mbox-names = system;
};
pinmux {
compatible = brcm,bcm-foo-pinctrl;
mbox = cpm CPM_SYSTEM_CHANNEL;
mbox-names = system;
};
---
What we would need to do is completely ignore this information in each
of the of the client drivers associated with the clock, pmu, and pinmux
devices. This IPC server would need to be instantiated and get the
mailbox information from some source. mbox_request_channel() only works
when the client has an of_node with the mbox-names property present.
Let's say we follow this model and represent it in DT:
--
cpm: mailbox@deadbeef {
compatible = brcm,bcm-cpm-mailbox;
reg = ...;
#mbox-cells 1;
interrupts = ...;
};
cpm_ipc {
compatible = brcm,bcm-cpm-ipc
Re: [PATCHv5 2/4] mailbox: Introduce framework for mailbox
[Adding devicetree list]
On Mon, Jun 02, 2014 at 10:41:44PM +0530, Jassi Brar wrote:
On Mon, Jun 2, 2014 at 8:44 PM, Matt Porter mpor...@linaro.org wrote:
On Fri, May 30, 2014 at 11:01:55AM +0530, Jassi Brar wrote:
Being more specific to your platform, I think you need some server
code (mailbox's client) that every driver (like clock, pmu, pinmux
etc) registers with to send messages to remote and receive commands
from remote ... perhaps by registering some filter to sort out
messages for each driver.
Right, and here's where you hit on the problem. This server you mention
is not a piece of hardware, it would be a software construct. As such, it
doesn't fit into the DT binding as it exists. It's probably best to
illustrate in DT syntax.
If I were to represent the hardware relationship in the DT binding now
it would look like this:
---
cpm: mailbox@deadbeef {
compatible = brcm,bcm-cpm-mailbox;
reg = ...;
#mbox-cells 1;
interrupts = ...;
};
/* clock complex */
ccu {
compatible = brcm,bcm-foo-ccu;
mbox = cpm CPM_SYSTEM_CHANNEL;
mbox-names = system;
/* leaving out other mailboxes for brevity */
#clock-cells 1;
clock-output-names = bar,
baz;
};
pmu {
compatible = brcm,bcm-foo-pmu
mbox = cpm CPM_SYSTEM_CHANNEL;
mbox-names = system;
};
pinmux {
compatible = brcm,bcm-foo-pinctrl;
mbox = cpm CPM_SYSTEM_CHANNEL;
mbox-names = system;
};
---
Yeah, I too don't think its a good idea.
What we would need to do is completely ignore this information in each
of the of the client drivers associated with the clock, pmu, and pinmux
devices. This IPC server would need to be instantiated and get the
mailbox information from some source. mbox_request_channel() only works
when the client has an of_node with the mbox-names property present.
Let's say we follow this model and represent it in DT:
--
cpm: mailbox@deadbeef {
compatible = brcm,bcm-cpm-mailbox;
reg = ...;
#mbox-cells 1;
interrupts = ...;
};
cpm_ipc {
compatible = brcm,bcm-cpm-ipc;
mbox = cpm CPM_SYSTEM_CHANNEL;
mbox-names = system;
/* leaving out other mailboxes for brevity */
};
---
This would allow an ipc driver to exclusively own this system channel,
but now we've invented a binding that doesn't reflect the hardware at
all. It's describing software so I don't believe the DT maintainers will
allow this type of construct.
Must the server node specify MMIO and an IRQ, to be acceptable? Like ...
My bad, that was a cut and paste typo..I intended to remove those
properties as you do below.
cpm_ipc : cpm@deadbeef {
compatible = brcm,bcm-cpm-ipc;
/* reg = 0xdeadbeef 0x100; */
/* interrupts = 0 123 4; */
mbox = cpm CPM_SYSTEM_CHANNEL;
mbox-names = system;
};
Correct, this should have been:
cpm_ipc {
compatible = brcm,bcm-cpm-ipc;
mbox = cpm CPM_SYSTEM_CHANNEL;
mbox-names = system;
};
cpm_ipc already specifies a hardware resource (mbox) that its driver
needs, I think that should be enough reason. If it were some purely
soft property for the driver like
mode = poll; //or irq
then the node wouldn't be justified because that is the job of a
build-time config or run-time module option.
Hrm, this is where I'd like to hear from the DT maintainers since we
have to live with this generic binding. If they are ok with us creating
bindings for a virtual device that exists only to match with our ipc
driver then it will work. I'm not aware of other similar examples though.
-Matt
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv5 2/4] mailbox: Introduce framework for mailbox
On Fri, May 16, 2014 at 07:03:25PM +0530, Jassi Brar wrote:
> On 15 May 2014 19:57, Arnd Bergmann wrote:
> > On Thursday 15 May 2014 11:41:00 Jassi Brar wrote:
...
> >> +struct mbox_controller {
> >> + struct device *dev;
> >> + struct mbox_chan_ops *ops;
> >> + struct mbox_chan *chans;
> >> + int num_chans;
> >> + bool txdone_irq;
> >> + bool txdone_poll;
> >> + unsigned txpoll_period;
> >> + struct mbox_chan *(*of_xlate)(struct mbox_controller *mbox,
> >> + const struct of_phandle_args *sp);
> >> + /*
> >> + * If the controller supports only TXDONE_BY_POLL,
> >> + * this timer polls all the links for txdone.
> >> + */
> >> + struct timer_list poll;
> >> + unsigned period;
> >> + /* Hook to add to the global controller list */
> >> + struct list_head node;
> >> +} __aligned(32);
> >
> > What is the __aligned(32) for?
> >
> Attempt to align access to mailbox?
>
> I am still open to opinion about whether the mailbox ownership should
> be exclusive or shared among clients. Need to handle async messages
> from remote is one reason one might want more than one client to own a
> channel. Allowing for RX via notifiers might be one option but that
> breaks semantics of 'ownership' of a mailbox channel.
This is the case we have on a new family of Broadcom SoCs. One mailbox
channel is the "system" channel and is shared amongst many clients for
reception of unsolicited events from the coprocessor. The same channel
is also used commonly in drivers for debug/inspection of the M0 state.
Functionality for clock, pmu, pinmux, and cpu idle/suspend is implemented
via IPC with the M0 so all of those drivers need to share one mailbox.
There's a lot of common code necessary to construct/parse IPCs for
each of the drivers. I suppose this IPC driver/api could be the
sole owner of that system channel. However, we'd need to develop some
binding to represent IPC resources that devices need to operate. Coming
into this late...I wonder if I missed something about where these vendor
specific IPC layers should live and how, if it makes sense, they should
be represented in DT. In our case, the IPC is an integral part of the
hardware as it's loaded from ROM.
-Matt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv5 2/4] mailbox: Introduce framework for mailbox
On Fri, May 16, 2014 at 07:03:25PM +0530, Jassi Brar wrote:
On 15 May 2014 19:57, Arnd Bergmann a...@arndb.de wrote:
On Thursday 15 May 2014 11:41:00 Jassi Brar wrote:
...
+struct mbox_controller {
+ struct device *dev;
+ struct mbox_chan_ops *ops;
+ struct mbox_chan *chans;
+ int num_chans;
+ bool txdone_irq;
+ bool txdone_poll;
+ unsigned txpoll_period;
+ struct mbox_chan *(*of_xlate)(struct mbox_controller *mbox,
+ const struct of_phandle_args *sp);
+ /*
+ * If the controller supports only TXDONE_BY_POLL,
+ * this timer polls all the links for txdone.
+ */
+ struct timer_list poll;
+ unsigned period;
+ /* Hook to add to the global controller list */
+ struct list_head node;
+} __aligned(32);
What is the __aligned(32) for?
Attempt to align access to mailbox?
I am still open to opinion about whether the mailbox ownership should
be exclusive or shared among clients. Need to handle async messages
from remote is one reason one might want more than one client to own a
channel. Allowing for RX via notifiers might be one option but that
breaks semantics of 'ownership' of a mailbox channel.
This is the case we have on a new family of Broadcom SoCs. One mailbox
channel is the system channel and is shared amongst many clients for
reception of unsolicited events from the coprocessor. The same channel
is also used commonly in drivers for debug/inspection of the M0 state.
Functionality for clock, pmu, pinmux, and cpu idle/suspend is implemented
via IPC with the M0 so all of those drivers need to share one mailbox.
There's a lot of common code necessary to construct/parse IPCs for
each of the drivers. I suppose this IPC driver/api could be the
sole owner of that system channel. However, we'd need to develop some
binding to represent IPC resources that devices need to operate. Coming
into this late...I wonder if I missed something about where these vendor
specific IPC layers should live and how, if it makes sense, they should
be represented in DT. In our case, the IPC is an integral part of the
hardware as it's loaded from ROM.
-Matt
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 4/4] ARM: dts: bcm590xx: add support for GPLDO and VBUS regulators
On Wed, Apr 23, 2014 at 07:21:33PM -0400, Matt Porter wrote:
> Adds additional nodes to support GPLDO1-6 and VBUS regulators which
> are now supported in the bcm590xx regulator driver.
Applied to mach-bcm for-3.16/dt
> arch/arm/boot/dts/bcm59056.dtsi | 21 +
> 1 file changed, 21 insertions(+)
>
> diff --git a/arch/arm/boot/dts/bcm59056.dtsi b/arch/arm/boot/dts/bcm59056.dtsi
> index dfadaaa..066adfb 100644
> --- a/arch/arm/boot/dts/bcm59056.dtsi
> +++ b/arch/arm/boot/dts/bcm59056.dtsi
> @@ -70,5 +70,26 @@
>
> vsr_reg: vsr {
> };
> +
> + gpldo1_reg: gpldo1 {
> + };
> +
> + gpldo2_reg: gpldo2 {
> + };
> +
> + gpldo3_reg: gpldo3 {
> + };
> +
> + gpldo4_reg: gpldo4 {
> + };
> +
> + gpldo5_reg: gpldo5 {
> + };
> +
> + gpldo6_reg: gpldo6 {
> + };
> +
> + vbus_reg: vbus {
> + };
> };
> };
> --
> 1.8.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 4/4] ARM: dts: bcm590xx: add support for GPLDO and VBUS regulators
On Wed, Apr 23, 2014 at 07:21:33PM -0400, Matt Porter wrote:
Adds additional nodes to support GPLDO1-6 and VBUS regulators which
are now supported in the bcm590xx regulator driver.
Applied to mach-bcm for-3.16/dt
arch/arm/boot/dts/bcm59056.dtsi | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/bcm59056.dtsi b/arch/arm/boot/dts/bcm59056.dtsi
index dfadaaa..066adfb 100644
--- a/arch/arm/boot/dts/bcm59056.dtsi
+++ b/arch/arm/boot/dts/bcm59056.dtsi
@@ -70,5 +70,26 @@
vsr_reg: vsr {
};
+
+ gpldo1_reg: gpldo1 {
+ };
+
+ gpldo2_reg: gpldo2 {
+ };
+
+ gpldo3_reg: gpldo3 {
+ };
+
+ gpldo4_reg: gpldo4 {
+ };
+
+ gpldo5_reg: gpldo5 {
+ };
+
+ gpldo6_reg: gpldo6 {
+ };
+
+ vbus_reg: vbus {
+ };
};
};
--
1.8.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 4/4] ARM: dts: bcm590xx: add support for GPLDO and VBUS regulators
On Wed, May 21, 2014 at 10:29:13AM +0100, Lee Jones wrote:
> > Adds additional nodes to support GPLDO1-6 and VBUS regulators which
> > are now supported in the bcm590xx regulator driver.
> >
> > Signed-off-by: Matt Porter
> > ---
> > arch/arm/boot/dts/bcm59056.dtsi | 21 +
> > 1 file changed, 21 insertions(+)
>
> I'm not going to apply this with the rest of the set. It will have to
> go in via your normal arch/arm route.
Ok
> > diff --git a/arch/arm/boot/dts/bcm59056.dtsi
> > b/arch/arm/boot/dts/bcm59056.dtsi
> > index dfadaaa..066adfb 100644
> > --- a/arch/arm/boot/dts/bcm59056.dtsi
> > +++ b/arch/arm/boot/dts/bcm59056.dtsi
> > @@ -70,5 +70,26 @@
> >
> > vsr_reg: vsr {
> > };
> > +
> > + gpldo1_reg: gpldo1 {
> > + };
>
> What do these empty nodes do in any case?
They instantiate regulators. The bcm590xx binding specifies the
allowable subnode names permitted here. This replaces the old method
of specifying an index or the deprecated regulator-compatible property.
The board-specific dts includes this dtsi and applies any board
constraints to a subset of regulators that need them. Unused regulators
are all disabled which is what we want.
> Don't you at least need a status property in there or something?
Not necessary for these subnodes.
-Matt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 4/4] ARM: dts: bcm590xx: add support for GPLDO and VBUS regulators
On Wed, May 21, 2014 at 10:29:13AM +0100, Lee Jones wrote:
Adds additional nodes to support GPLDO1-6 and VBUS regulators which
are now supported in the bcm590xx regulator driver.
Signed-off-by: Matt Porter mpor...@linaro.org
---
arch/arm/boot/dts/bcm59056.dtsi | 21 +
1 file changed, 21 insertions(+)
I'm not going to apply this with the rest of the set. It will have to
go in via your normal arch/arm route.
Ok
diff --git a/arch/arm/boot/dts/bcm59056.dtsi
b/arch/arm/boot/dts/bcm59056.dtsi
index dfadaaa..066adfb 100644
--- a/arch/arm/boot/dts/bcm59056.dtsi
+++ b/arch/arm/boot/dts/bcm59056.dtsi
@@ -70,5 +70,26 @@
vsr_reg: vsr {
};
+
+ gpldo1_reg: gpldo1 {
+ };
What do these empty nodes do in any case?
They instantiate regulators. The bcm590xx binding specifies the
allowable subnode names permitted here. This replaces the old method
of specifying an index or the deprecated regulator-compatible property.
The board-specific dts includes this dtsi and applies any board
constraints to a subset of regulators that need them. Unused regulators
are all disabled which is what we want.
Don't you at least need a status property in there or something?
Not necessary for these subnodes.
-Matt
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/4] mfd: bcm590xx: add support for secondary I2C slave address
On Tue, May 20, 2014 at 10:44:39PM +0100, Mark Brown wrote: > On Tue, May 20, 2014 at 04:29:23PM -0400, Matt Porter wrote: > > > Just resent the v2 series. > > I looked at that but it seems I already acked the regulator part of the > series and nothing else looked immediately relevant? The series has cross dependencies (shared header include) and thus needs to have both the mfd and regulator portions merged together. You had mentioned in the v1 version that you'd like to take it through the regulator tree and so Lee's comments earlier were with regard to you taking the mfd portions. -Matt signature.asc Description: Digital signature
Re: [PATCH v2 2/4] mfd: bcm590xx: add support for secondary I2C slave address
On Tue, May 20, 2014 at 08:00:55PM +0100, Mark Brown wrote: > On Tue, May 20, 2014 at 05:11:31PM +0100, Lee Jones wrote: > > > > > > drivers/mfd/bcm590xx.c | 60 > > > > > +--- > > > > > include/linux/mfd/bcm590xx.h | 9 --- > > > > > 2 files changed, 52 insertions(+), 17 deletions(-) > > > > There's cross-deps so the regulator driver will need to go with it. > > > Mark mentioned earlier in the thread that he wanted to merge through > > > the regulator tree though. > > > Still nothing. > > > Mark, > > Can I apply this set and supply you with a pull-request? > > Can someone please send me whatever it is you want me to look at, the > above diffstat doesn't look relevant. Given the frequency of respins > I'm not always paying a huge amount of attention to MFD serieses which > look like they're going to be resent. Just resent the v2 series. -Matt signature.asc Description: Digital signature
[PATCH RESEND v2 1/4] mfd: bcm590xx: update binding with additional BCM59056 regulators
The BCM59056 supports GPLDO1-6 and VBUS regulators in a secondary
I2C slave address space. Add these regulators to the list of valid
regulator node names for BCM59056.
Signed-off-by: Matt Porter
---
Documentation/devicetree/bindings/mfd/bcm590xx.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/mfd/bcm590xx.txt
b/Documentation/devicetree/bindings/mfd/bcm590xx.txt
index 1fe30e2..be51a15 100644
--- a/Documentation/devicetree/bindings/mfd/bcm590xx.txt
+++ b/Documentation/devicetree/bindings/mfd/bcm590xx.txt
@@ -19,7 +19,9 @@ Optional child nodes:
The valid regulator node names for BCM59056 are:
rfldo, camldo1, camldo2, simldo1, simldo2, sdldo, sdxldo,
mmcldo1, mmcldo2, audldo, micldo, usbldo, vibldo,
- csr, iosr1, iosr2, msr, sdsr1, sdsr2, vsr
+ csr, iosr1, iosr2, msr, sdsr1, sdsr2, vsr,
+ gpldo1, gpldo2, gpldo3, gpldo4, gpldo5, gpldo6,
+ vbus
Example:
pmu: bcm59056@8 {
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND v2 0/4] Support additional regulators on BCM590xx
Changes since v1: - Fix a several commit log typos and capitalization - Drop use of addmap[0|1] in favor of i2c_[pri|sec] - Replace regmap[0|1] with regmap_[pri|sec] This series enables support for 7 additional regulators on the BCM59056 PMU. These regulators are accessed via a secondary I2C slave address. The MFD driver exposes an additional regmap descriptor for the additional address space and the regulator implements support for GPLDO1-6 and VBUS regulators. Matt Porter (4): mfd: bcm590xx: update binding with additional BCM59056 regulators mfd: bcm590xx: add support for secondary I2C slave address regulator: bcm590xx: add support for regulators on secondary I2C slave ARM: dts: bcm590xx: add support for GPLDO and VBUS regulators Documentation/devicetree/bindings/mfd/bcm590xx.txt | 4 +- arch/arm/boot/dts/bcm59056.dtsi| 21 + drivers/mfd/bcm590xx.c | 60 ++ drivers/regulator/bcm590xx-regulator.c | 92 +++--- include/linux/mfd/bcm590xx.h | 9 ++- 5 files changed, 158 insertions(+), 28 deletions(-) -- 1.8.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND v2 4/4] ARM: dts: bcm590xx: add support for GPLDO and VBUS regulators
Adds additional nodes to support GPLDO1-6 and VBUS regulators which
are now supported in the bcm590xx regulator driver.
Signed-off-by: Matt Porter
---
arch/arm/boot/dts/bcm59056.dtsi | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/bcm59056.dtsi b/arch/arm/boot/dts/bcm59056.dtsi
index dfadaaa..066adfb 100644
--- a/arch/arm/boot/dts/bcm59056.dtsi
+++ b/arch/arm/boot/dts/bcm59056.dtsi
@@ -70,5 +70,26 @@
vsr_reg: vsr {
};
+
+ gpldo1_reg: gpldo1 {
+ };
+
+ gpldo2_reg: gpldo2 {
+ };
+
+ gpldo3_reg: gpldo3 {
+ };
+
+ gpldo4_reg: gpldo4 {
+ };
+
+ gpldo5_reg: gpldo5 {
+ };
+
+ gpldo6_reg: gpldo6 {
+ };
+
+ vbus_reg: vbus {
+ };
};
};
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND v2 2/4] mfd: bcm590xx: add support for secondary I2C slave address
BCM590xx utilizes a secondary I2C slave address to access additional
register space. Add support for the secondary address space by
instantiating a dummy I2C device with the appropriate secondary
I2C slave address. Also expose a secondary regmap register space so
that MFD drivers can access this secondary i2c slave address space.
Signed-off-by: Matt Porter
---
drivers/mfd/bcm590xx.c | 60 +---
include/linux/mfd/bcm590xx.h | 9 ---
2 files changed, 52 insertions(+), 17 deletions(-)
diff --git a/drivers/mfd/bcm590xx.c b/drivers/mfd/bcm590xx.c
index e9a33c7..43cba1a 100644
--- a/drivers/mfd/bcm590xx.c
+++ b/drivers/mfd/bcm590xx.c
@@ -28,39 +28,71 @@ static const struct mfd_cell bcm590xx_devs[] = {
},
};
-static const struct regmap_config bcm590xx_regmap_config = {
+static const struct regmap_config bcm590xx_regmap_config_pri = {
.reg_bits = 8,
.val_bits = 8,
- .max_register = BCM590XX_MAX_REGISTER,
+ .max_register = BCM590XX_MAX_REGISTER_PRI,
.cache_type = REGCACHE_RBTREE,
};
-static int bcm590xx_i2c_probe(struct i2c_client *i2c,
+static const struct regmap_config bcm590xx_regmap_config_sec = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .max_register = BCM590XX_MAX_REGISTER_SEC,
+ .cache_type = REGCACHE_RBTREE,
+};
+
+static int bcm590xx_i2c_probe(struct i2c_client *i2c_pri,
const struct i2c_device_id *id)
{
struct bcm590xx *bcm590xx;
int ret;
- bcm590xx = devm_kzalloc(>dev, sizeof(*bcm590xx), GFP_KERNEL);
+ bcm590xx = devm_kzalloc(_pri->dev, sizeof(*bcm590xx), GFP_KERNEL);
if (!bcm590xx)
return -ENOMEM;
- i2c_set_clientdata(i2c, bcm590xx);
- bcm590xx->dev = >dev;
- bcm590xx->i2c_client = i2c;
+ i2c_set_clientdata(i2c_pri, bcm590xx);
+ bcm590xx->dev = _pri->dev;
+ bcm590xx->i2c_pri = i2c_pri;
- bcm590xx->regmap = devm_regmap_init_i2c(i2c, _regmap_config);
- if (IS_ERR(bcm590xx->regmap)) {
- ret = PTR_ERR(bcm590xx->regmap);
- dev_err(>dev, "regmap initialization failed: %d\n", ret);
+ bcm590xx->regmap_pri = devm_regmap_init_i2c(i2c_pri,
+_regmap_config_pri);
+ if (IS_ERR(bcm590xx->regmap_pri)) {
+ ret = PTR_ERR(bcm590xx->regmap_pri);
+ dev_err(_pri->dev, "primary regmap init failed: %d\n", ret);
return ret;
}
- ret = mfd_add_devices(>dev, -1, bcm590xx_devs,
+ /* Secondary I2C slave address is the base address with A(2) asserted */
+ bcm590xx->i2c_sec = i2c_new_dummy(i2c_pri->adapter,
+ i2c_pri->addr | BIT(2));
+ if (IS_ERR_OR_NULL(bcm590xx->i2c_sec)) {
+ dev_err(_pri->dev, "failed to add secondary I2C device\n");
+ return -ENODEV;
+ }
+ i2c_set_clientdata(bcm590xx->i2c_sec, bcm590xx);
+
+ bcm590xx->regmap_sec = devm_regmap_init_i2c(bcm590xx->i2c_sec,
+ _regmap_config_sec);
+ if (IS_ERR(bcm590xx->regmap_sec)) {
+ ret = PTR_ERR(bcm590xx->regmap_sec);
+ dev_err(>i2c_sec->dev,
+ "secondary regmap init failed: %d\n", ret);
+ goto err;
+ }
+
+ ret = mfd_add_devices(_pri->dev, -1, bcm590xx_devs,
ARRAY_SIZE(bcm590xx_devs), NULL, 0, NULL);
- if (ret < 0)
- dev_err(>dev, "failed to add sub-devices: %d\n", ret);
+ if (ret < 0) {
+ dev_err(_pri->dev, "failed to add sub-devices: %d\n", ret);
+ goto err;
+ }
+
+ return 0;
+err:
+ i2c_unregister_device(bcm590xx->i2c_sec);
return ret;
}
diff --git a/include/linux/mfd/bcm590xx.h b/include/linux/mfd/bcm590xx.h
index 434df2d..267aede 100644
--- a/include/linux/mfd/bcm590xx.h
+++ b/include/linux/mfd/bcm590xx.h
@@ -19,12 +19,15 @@
#include
/* max register address */
-#define BCM590XX_MAX_REGISTER 0xe7
+#define BCM590XX_MAX_REGISTER_PRI 0xe7
+#define BCM590XX_MAX_REGISTER_SEC 0xf0
struct bcm590xx {
struct device *dev;
- struct i2c_client *i2c_client;
- struct regmap *regmap;
+ struct i2c_client *i2c_pri;
+ struct i2c_client *i2c_sec;
+ struct regmap *regmap_pri;
+ struct regmap *regmap_sec;
unsigned int id;
};
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND v2 3/4] regulator: bcm590xx: add support for regulators on secondary I2C slave
The bcm590xx MFD driver now exposes a secondary regmap descriptor
making the registers for regulators on the secondary I2C slave address
available. Add support for GPLDO1-6 and VBUS regulators found within
this register range.
Signed-off-by: Matt Porter
Acked-by: Mark Brown
---
drivers/regulator/bcm590xx-regulator.c | 92 ++
1 file changed, 82 insertions(+), 10 deletions(-)
diff --git a/drivers/regulator/bcm590xx-regulator.c
b/drivers/regulator/bcm590xx-regulator.c
index c3750c5..57544e2 100644
--- a/drivers/regulator/bcm590xx-regulator.c
+++ b/drivers/regulator/bcm590xx-regulator.c
@@ -22,7 +22,7 @@
#include
#include
-/* Register defs */
+/* I2C slave 0 registers */
#define BCM590XX_RFLDOPMCTRL1 0x60
#define BCM590XX_IOSR1PMCTRL1 0x7a
#define BCM590XX_IOSR2PMCTRL1 0x7c
@@ -31,13 +31,34 @@
#define BCM590XX_SDSR2PMCTRL1 0x86
#define BCM590XX_MSRPMCTRL10x8a
#define BCM590XX_VSRPMCTRL10x8e
-#define BCM590XX_REG_ENABLEBIT(7)
-
#define BCM590XX_RFLDOCTRL 0x96
#define BCM590XX_CSRVOUT1 0xc0
+
+/* I2C slave 1 registers */
+#define BCM590XX_GPLDO5PMCTRL1 0x16
+#define BCM590XX_GPLDO6PMCTRL1 0x18
+#define BCM590XX_GPLDO1CTRL0x1a
+#define BCM590XX_GPLDO2CTRL0x1b
+#define BCM590XX_GPLDO3CTRL0x1c
+#define BCM590XX_GPLDO4CTRL0x1d
+#define BCM590XX_GPLDO5CTRL0x1e
+#define BCM590XX_GPLDO6CTRL0x1f
+#define BCM590XX_OTG_CTRL 0x40
+#define BCM590XX_GPLDO1PMCTRL1 0x57
+#define BCM590XX_GPLDO2PMCTRL1 0x59
+#define BCM590XX_GPLDO3PMCTRL1 0x5b
+#define BCM590XX_GPLDO4PMCTRL1 0x5d
+
+#define BCM590XX_REG_ENABLEBIT(7)
+#define BCM590XX_VBUS_ENABLE BIT(2)
#define BCM590XX_LDO_VSEL_MASK GENMASK(5, 3)
#define BCM590XX_SR_VSEL_MASK GENMASK(5, 0)
+/*
+ * RFLDO to VSR regulators are
+ * accessed via I2C slave 0
+ */
+
/* LDO regulator IDs */
#define BCM590XX_REG_RFLDO 0
#define BCM590XX_REG_CAMLDO1 1
@@ -62,9 +83,25 @@
#define BCM590XX_REG_SDSR2 18
#define BCM590XX_REG_VSR 19
-#define BCM590XX_NUM_REGS 20
+/*
+ * GPLDO1 to VBUS regulators are
+ * accessed via I2C slave 1
+ */
+
+#define BCM590XX_REG_GPLDO120
+#define BCM590XX_REG_GPLDO221
+#define BCM590XX_REG_GPLDO322
+#define BCM590XX_REG_GPLDO423
+#define BCM590XX_REG_GPLDO524
+#define BCM590XX_REG_GPLDO625
+#define BCM590XX_REG_VBUS 26
+
+#define BCM590XX_NUM_REGS 27
#define BCM590XX_REG_IS_LDO(n) (n < BCM590XX_REG_CSR)
+#define BCM590XX_REG_IS_GPLDO(n) \
+ ((n > BCM590XX_REG_VSR) && (n < BCM590XX_REG_VBUS))
+#define BCM590XX_REG_IS_VBUS(n)(n == BCM590XX_REG_VBUS)
struct bcm590xx_board {
struct regulator_init_data *bcm590xx_pmu_init_data[BCM590XX_NUM_REGS];
@@ -149,6 +186,12 @@ static struct bcm590xx_info bcm590xx_regs[] = {
BCM590XX_REG_RANGES(sdsr1, dcdc_sdsr1_ranges),
BCM590XX_REG_RANGES(sdsr2, dcdc_iosr1_ranges),
BCM590XX_REG_RANGES(vsr, dcdc_iosr1_ranges),
+ BCM590XX_REG_TABLE(gpldo1, ldo_a_table),
+ BCM590XX_REG_TABLE(gpldo2, ldo_a_table),
+ BCM590XX_REG_TABLE(gpldo3, ldo_a_table),
+ BCM590XX_REG_TABLE(gpldo4, ldo_a_table),
+ BCM590XX_REG_TABLE(gpldo5, ldo_a_table),
+ BCM590XX_REG_TABLE(gpldo6, ldo_a_table),
};
struct bcm590xx_reg {
@@ -161,6 +204,8 @@ static int bcm590xx_get_vsel_register(int id)
{
if (BCM590XX_REG_IS_LDO(id))
return BCM590XX_RFLDOCTRL + id;
+ else if (BCM590XX_REG_IS_GPLDO(id))
+ return BCM590XX_GPLDO1CTRL + id;
else
return BCM590XX_CSRVOUT1 + (id - BCM590XX_REG_CSR) * 3;
}
@@ -171,6 +216,8 @@ static int bcm590xx_get_enable_register(int id)
if (BCM590XX_REG_IS_LDO(id))
reg = BCM590XX_RFLDOPMCTRL1 + id * 2;
+ else if (BCM590XX_REG_IS_GPLDO(id))
+ reg = BCM590XX_GPLDO1PMCTRL1 + id * 2;
else
switch (id) {
case BCM590XX_REG_CSR:
@@ -191,8 +238,11 @@ static int bcm590xx_get_enable_register(int id)
case BCM590XX_REG_SDSR2:
reg = BCM590XX_SDSR2PMCTRL1;
break;
+ case BCM590XX_REG_VBUS:
+ reg = BCM590XX_OTG_CTRL;
};
+
return reg;
}
@@ -216,6 +266,12 @@ static struct regulator_ops bcm590xx_ops_dcdc = {
.map_voltage= regulator_map_voltage_linear_range,
};
+static struct regulator_ops bcm590xx_ops_vbus = {
+ .is_enabled = regulator_is_enabled_regmap,
+ .enable = regulator_enable_regmap,
+ .disable= regulator_disable_regmap,
+};
+
#define BCM590XX_MATCH(_name, _id) \
{ \
.name = #_name, \
@@ -243,6 +299,13 @@ static struct of_regulator_match bcm590xx_matches[] = {
BCM590XX_MATCH(sdsr1, SDSR1),
BCM590XX_MATCH(sdsr2, SDSR2),
BCM590XX_MATCH(vsr, VSR),
+ BCM590XX_MAT
[PATCH RESEND v2 2/4] mfd: bcm590xx: add support for secondary I2C slave address
BCM590xx utilizes a secondary I2C slave address to access additional
register space. Add support for the secondary address space by
instantiating a dummy I2C device with the appropriate secondary
I2C slave address. Also expose a secondary regmap register space so
that MFD drivers can access this secondary i2c slave address space.
Signed-off-by: Matt Porter mpor...@linaro.org
---
drivers/mfd/bcm590xx.c | 60 +---
include/linux/mfd/bcm590xx.h | 9 ---
2 files changed, 52 insertions(+), 17 deletions(-)
diff --git a/drivers/mfd/bcm590xx.c b/drivers/mfd/bcm590xx.c
index e9a33c7..43cba1a 100644
--- a/drivers/mfd/bcm590xx.c
+++ b/drivers/mfd/bcm590xx.c
@@ -28,39 +28,71 @@ static const struct mfd_cell bcm590xx_devs[] = {
},
};
-static const struct regmap_config bcm590xx_regmap_config = {
+static const struct regmap_config bcm590xx_regmap_config_pri = {
.reg_bits = 8,
.val_bits = 8,
- .max_register = BCM590XX_MAX_REGISTER,
+ .max_register = BCM590XX_MAX_REGISTER_PRI,
.cache_type = REGCACHE_RBTREE,
};
-static int bcm590xx_i2c_probe(struct i2c_client *i2c,
+static const struct regmap_config bcm590xx_regmap_config_sec = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .max_register = BCM590XX_MAX_REGISTER_SEC,
+ .cache_type = REGCACHE_RBTREE,
+};
+
+static int bcm590xx_i2c_probe(struct i2c_client *i2c_pri,
const struct i2c_device_id *id)
{
struct bcm590xx *bcm590xx;
int ret;
- bcm590xx = devm_kzalloc(i2c-dev, sizeof(*bcm590xx), GFP_KERNEL);
+ bcm590xx = devm_kzalloc(i2c_pri-dev, sizeof(*bcm590xx), GFP_KERNEL);
if (!bcm590xx)
return -ENOMEM;
- i2c_set_clientdata(i2c, bcm590xx);
- bcm590xx-dev = i2c-dev;
- bcm590xx-i2c_client = i2c;
+ i2c_set_clientdata(i2c_pri, bcm590xx);
+ bcm590xx-dev = i2c_pri-dev;
+ bcm590xx-i2c_pri = i2c_pri;
- bcm590xx-regmap = devm_regmap_init_i2c(i2c, bcm590xx_regmap_config);
- if (IS_ERR(bcm590xx-regmap)) {
- ret = PTR_ERR(bcm590xx-regmap);
- dev_err(i2c-dev, regmap initialization failed: %d\n, ret);
+ bcm590xx-regmap_pri = devm_regmap_init_i2c(i2c_pri,
+bcm590xx_regmap_config_pri);
+ if (IS_ERR(bcm590xx-regmap_pri)) {
+ ret = PTR_ERR(bcm590xx-regmap_pri);
+ dev_err(i2c_pri-dev, primary regmap init failed: %d\n, ret);
return ret;
}
- ret = mfd_add_devices(i2c-dev, -1, bcm590xx_devs,
+ /* Secondary I2C slave address is the base address with A(2) asserted */
+ bcm590xx-i2c_sec = i2c_new_dummy(i2c_pri-adapter,
+ i2c_pri-addr | BIT(2));
+ if (IS_ERR_OR_NULL(bcm590xx-i2c_sec)) {
+ dev_err(i2c_pri-dev, failed to add secondary I2C device\n);
+ return -ENODEV;
+ }
+ i2c_set_clientdata(bcm590xx-i2c_sec, bcm590xx);
+
+ bcm590xx-regmap_sec = devm_regmap_init_i2c(bcm590xx-i2c_sec,
+ bcm590xx_regmap_config_sec);
+ if (IS_ERR(bcm590xx-regmap_sec)) {
+ ret = PTR_ERR(bcm590xx-regmap_sec);
+ dev_err(bcm590xx-i2c_sec-dev,
+ secondary regmap init failed: %d\n, ret);
+ goto err;
+ }
+
+ ret = mfd_add_devices(i2c_pri-dev, -1, bcm590xx_devs,
ARRAY_SIZE(bcm590xx_devs), NULL, 0, NULL);
- if (ret 0)
- dev_err(i2c-dev, failed to add sub-devices: %d\n, ret);
+ if (ret 0) {
+ dev_err(i2c_pri-dev, failed to add sub-devices: %d\n, ret);
+ goto err;
+ }
+
+ return 0;
+err:
+ i2c_unregister_device(bcm590xx-i2c_sec);
return ret;
}
diff --git a/include/linux/mfd/bcm590xx.h b/include/linux/mfd/bcm590xx.h
index 434df2d..267aede 100644
--- a/include/linux/mfd/bcm590xx.h
+++ b/include/linux/mfd/bcm590xx.h
@@ -19,12 +19,15 @@
#include linux/regmap.h
/* max register address */
-#define BCM590XX_MAX_REGISTER 0xe7
+#define BCM590XX_MAX_REGISTER_PRI 0xe7
+#define BCM590XX_MAX_REGISTER_SEC 0xf0
struct bcm590xx {
struct device *dev;
- struct i2c_client *i2c_client;
- struct regmap *regmap;
+ struct i2c_client *i2c_pri;
+ struct i2c_client *i2c_sec;
+ struct regmap *regmap_pri;
+ struct regmap *regmap_sec;
unsigned int id;
};
--
1.8.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND v2 3/4] regulator: bcm590xx: add support for regulators on secondary I2C slave
The bcm590xx MFD driver now exposes a secondary regmap descriptor
making the registers for regulators on the secondary I2C slave address
available. Add support for GPLDO1-6 and VBUS regulators found within
this register range.
Signed-off-by: Matt Porter mpor...@linaro.org
Acked-by: Mark Brown broo...@linaro.org
---
drivers/regulator/bcm590xx-regulator.c | 92 ++
1 file changed, 82 insertions(+), 10 deletions(-)
diff --git a/drivers/regulator/bcm590xx-regulator.c
b/drivers/regulator/bcm590xx-regulator.c
index c3750c5..57544e2 100644
--- a/drivers/regulator/bcm590xx-regulator.c
+++ b/drivers/regulator/bcm590xx-regulator.c
@@ -22,7 +22,7 @@
#include linux/regulator/of_regulator.h
#include linux/slab.h
-/* Register defs */
+/* I2C slave 0 registers */
#define BCM590XX_RFLDOPMCTRL1 0x60
#define BCM590XX_IOSR1PMCTRL1 0x7a
#define BCM590XX_IOSR2PMCTRL1 0x7c
@@ -31,13 +31,34 @@
#define BCM590XX_SDSR2PMCTRL1 0x86
#define BCM590XX_MSRPMCTRL10x8a
#define BCM590XX_VSRPMCTRL10x8e
-#define BCM590XX_REG_ENABLEBIT(7)
-
#define BCM590XX_RFLDOCTRL 0x96
#define BCM590XX_CSRVOUT1 0xc0
+
+/* I2C slave 1 registers */
+#define BCM590XX_GPLDO5PMCTRL1 0x16
+#define BCM590XX_GPLDO6PMCTRL1 0x18
+#define BCM590XX_GPLDO1CTRL0x1a
+#define BCM590XX_GPLDO2CTRL0x1b
+#define BCM590XX_GPLDO3CTRL0x1c
+#define BCM590XX_GPLDO4CTRL0x1d
+#define BCM590XX_GPLDO5CTRL0x1e
+#define BCM590XX_GPLDO6CTRL0x1f
+#define BCM590XX_OTG_CTRL 0x40
+#define BCM590XX_GPLDO1PMCTRL1 0x57
+#define BCM590XX_GPLDO2PMCTRL1 0x59
+#define BCM590XX_GPLDO3PMCTRL1 0x5b
+#define BCM590XX_GPLDO4PMCTRL1 0x5d
+
+#define BCM590XX_REG_ENABLEBIT(7)
+#define BCM590XX_VBUS_ENABLE BIT(2)
#define BCM590XX_LDO_VSEL_MASK GENMASK(5, 3)
#define BCM590XX_SR_VSEL_MASK GENMASK(5, 0)
+/*
+ * RFLDO to VSR regulators are
+ * accessed via I2C slave 0
+ */
+
/* LDO regulator IDs */
#define BCM590XX_REG_RFLDO 0
#define BCM590XX_REG_CAMLDO1 1
@@ -62,9 +83,25 @@
#define BCM590XX_REG_SDSR2 18
#define BCM590XX_REG_VSR 19
-#define BCM590XX_NUM_REGS 20
+/*
+ * GPLDO1 to VBUS regulators are
+ * accessed via I2C slave 1
+ */
+
+#define BCM590XX_REG_GPLDO120
+#define BCM590XX_REG_GPLDO221
+#define BCM590XX_REG_GPLDO322
+#define BCM590XX_REG_GPLDO423
+#define BCM590XX_REG_GPLDO524
+#define BCM590XX_REG_GPLDO625
+#define BCM590XX_REG_VBUS 26
+
+#define BCM590XX_NUM_REGS 27
#define BCM590XX_REG_IS_LDO(n) (n BCM590XX_REG_CSR)
+#define BCM590XX_REG_IS_GPLDO(n) \
+ ((n BCM590XX_REG_VSR) (n BCM590XX_REG_VBUS))
+#define BCM590XX_REG_IS_VBUS(n)(n == BCM590XX_REG_VBUS)
struct bcm590xx_board {
struct regulator_init_data *bcm590xx_pmu_init_data[BCM590XX_NUM_REGS];
@@ -149,6 +186,12 @@ static struct bcm590xx_info bcm590xx_regs[] = {
BCM590XX_REG_RANGES(sdsr1, dcdc_sdsr1_ranges),
BCM590XX_REG_RANGES(sdsr2, dcdc_iosr1_ranges),
BCM590XX_REG_RANGES(vsr, dcdc_iosr1_ranges),
+ BCM590XX_REG_TABLE(gpldo1, ldo_a_table),
+ BCM590XX_REG_TABLE(gpldo2, ldo_a_table),
+ BCM590XX_REG_TABLE(gpldo3, ldo_a_table),
+ BCM590XX_REG_TABLE(gpldo4, ldo_a_table),
+ BCM590XX_REG_TABLE(gpldo5, ldo_a_table),
+ BCM590XX_REG_TABLE(gpldo6, ldo_a_table),
};
struct bcm590xx_reg {
@@ -161,6 +204,8 @@ static int bcm590xx_get_vsel_register(int id)
{
if (BCM590XX_REG_IS_LDO(id))
return BCM590XX_RFLDOCTRL + id;
+ else if (BCM590XX_REG_IS_GPLDO(id))
+ return BCM590XX_GPLDO1CTRL + id;
else
return BCM590XX_CSRVOUT1 + (id - BCM590XX_REG_CSR) * 3;
}
@@ -171,6 +216,8 @@ static int bcm590xx_get_enable_register(int id)
if (BCM590XX_REG_IS_LDO(id))
reg = BCM590XX_RFLDOPMCTRL1 + id * 2;
+ else if (BCM590XX_REG_IS_GPLDO(id))
+ reg = BCM590XX_GPLDO1PMCTRL1 + id * 2;
else
switch (id) {
case BCM590XX_REG_CSR:
@@ -191,8 +238,11 @@ static int bcm590xx_get_enable_register(int id)
case BCM590XX_REG_SDSR2:
reg = BCM590XX_SDSR2PMCTRL1;
break;
+ case BCM590XX_REG_VBUS:
+ reg = BCM590XX_OTG_CTRL;
};
+
return reg;
}
@@ -216,6 +266,12 @@ static struct regulator_ops bcm590xx_ops_dcdc = {
.map_voltage= regulator_map_voltage_linear_range,
};
+static struct regulator_ops bcm590xx_ops_vbus = {
+ .is_enabled = regulator_is_enabled_regmap,
+ .enable = regulator_enable_regmap,
+ .disable= regulator_disable_regmap,
+};
+
#define BCM590XX_MATCH(_name, _id) \
{ \
.name = #_name, \
@@ -243,6 +299,13 @@ static struct of_regulator_match bcm590xx_matches[] = {
BCM590XX_MATCH(sdsr1, SDSR1),
BCM590XX_MATCH(sdsr2, SDSR2
[PATCH RESEND v2 4/4] ARM: dts: bcm590xx: add support for GPLDO and VBUS regulators
Adds additional nodes to support GPLDO1-6 and VBUS regulators which
are now supported in the bcm590xx regulator driver.
Signed-off-by: Matt Porter mpor...@linaro.org
---
arch/arm/boot/dts/bcm59056.dtsi | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/bcm59056.dtsi b/arch/arm/boot/dts/bcm59056.dtsi
index dfadaaa..066adfb 100644
--- a/arch/arm/boot/dts/bcm59056.dtsi
+++ b/arch/arm/boot/dts/bcm59056.dtsi
@@ -70,5 +70,26 @@
vsr_reg: vsr {
};
+
+ gpldo1_reg: gpldo1 {
+ };
+
+ gpldo2_reg: gpldo2 {
+ };
+
+ gpldo3_reg: gpldo3 {
+ };
+
+ gpldo4_reg: gpldo4 {
+ };
+
+ gpldo5_reg: gpldo5 {
+ };
+
+ gpldo6_reg: gpldo6 {
+ };
+
+ vbus_reg: vbus {
+ };
};
};
--
1.8.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND v2 0/4] Support additional regulators on BCM590xx
Changes since v1: - Fix a several commit log typos and capitalization - Drop use of addmap[0|1] in favor of i2c_[pri|sec] - Replace regmap[0|1] with regmap_[pri|sec] This series enables support for 7 additional regulators on the BCM59056 PMU. These regulators are accessed via a secondary I2C slave address. The MFD driver exposes an additional regmap descriptor for the additional address space and the regulator implements support for GPLDO1-6 and VBUS regulators. Matt Porter (4): mfd: bcm590xx: update binding with additional BCM59056 regulators mfd: bcm590xx: add support for secondary I2C slave address regulator: bcm590xx: add support for regulators on secondary I2C slave ARM: dts: bcm590xx: add support for GPLDO and VBUS regulators Documentation/devicetree/bindings/mfd/bcm590xx.txt | 4 +- arch/arm/boot/dts/bcm59056.dtsi| 21 + drivers/mfd/bcm590xx.c | 60 ++ drivers/regulator/bcm590xx-regulator.c | 92 +++--- include/linux/mfd/bcm590xx.h | 9 ++- 5 files changed, 158 insertions(+), 28 deletions(-) -- 1.8.4 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/4] mfd: bcm590xx: add support for secondary I2C slave address
On Tue, May 20, 2014 at 08:00:55PM +0100, Mark Brown wrote: On Tue, May 20, 2014 at 05:11:31PM +0100, Lee Jones wrote: drivers/mfd/bcm590xx.c | 60 +--- include/linux/mfd/bcm590xx.h | 9 --- 2 files changed, 52 insertions(+), 17 deletions(-) There's cross-deps so the regulator driver will need to go with it. Mark mentioned earlier in the thread that he wanted to merge through the regulator tree though. Still nothing. Mark, Can I apply this set and supply you with a pull-request? Can someone please send me whatever it is you want me to look at, the above diffstat doesn't look relevant. Given the frequency of respins I'm not always paying a huge amount of attention to MFD serieses which look like they're going to be resent. Just resent the v2 series. -Matt signature.asc Description: Digital signature
[PATCH RESEND v2 1/4] mfd: bcm590xx: update binding with additional BCM59056 regulators
The BCM59056 supports GPLDO1-6 and VBUS regulators in a secondary
I2C slave address space. Add these regulators to the list of valid
regulator node names for BCM59056.
Signed-off-by: Matt Porter mpor...@linaro.org
---
Documentation/devicetree/bindings/mfd/bcm590xx.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/mfd/bcm590xx.txt
b/Documentation/devicetree/bindings/mfd/bcm590xx.txt
index 1fe30e2..be51a15 100644
--- a/Documentation/devicetree/bindings/mfd/bcm590xx.txt
+++ b/Documentation/devicetree/bindings/mfd/bcm590xx.txt
@@ -19,7 +19,9 @@ Optional child nodes:
The valid regulator node names for BCM59056 are:
rfldo, camldo1, camldo2, simldo1, simldo2, sdldo, sdxldo,
mmcldo1, mmcldo2, audldo, micldo, usbldo, vibldo,
- csr, iosr1, iosr2, msr, sdsr1, sdsr2, vsr
+ csr, iosr1, iosr2, msr, sdsr1, sdsr2, vsr,
+ gpldo1, gpldo2, gpldo3, gpldo4, gpldo5, gpldo6,
+ vbus
Example:
pmu: bcm59056@8 {
--
1.8.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/4] mfd: bcm590xx: add support for secondary I2C slave address
On Tue, May 20, 2014 at 10:44:39PM +0100, Mark Brown wrote: On Tue, May 20, 2014 at 04:29:23PM -0400, Matt Porter wrote: Just resent the v2 series. I looked at that but it seems I already acked the regulator part of the series and nothing else looked immediately relevant? The series has cross dependencies (shared header include) and thus needs to have both the mfd and regulator portions merged together. You had mentioned in the v1 version that you'd like to take it through the regulator tree and so Lee's comments earlier were with regard to you taking the mfd portions. -Matt signature.asc Description: Digital signature
Re: [PATCH v3 RESEND 2/5] ARM: add SMP support for Broadcom mobile SoCs
On Thu, May 15, 2014 at 01:17:00PM -0500, Alex Elder wrote: > On 05/15/2014 01:03 PM, Florian Fainelli wrote: > > Hi Alex, > > > > 2014-05-15 10:58 GMT-07:00 Alex Elder : > >> This patch adds SMP support for BCM281XX and BCM21664 family SoCs. > >> > >> This feature is controlled with a distinct config option such that a > >> SMP-enabled multi-v7 binary can be configured to run these SoCs in > >> uniprocessor mode. Since this SMP functionality is used for > >> multiple Broadcom mobile chip families the config option is called > >> ARCH_BCM_MOBILE_SMP (for lack of a better name). > >> > >> On SoCs of this type, the secondary core is not held in reset on > >> power-on. Instead it loops in a ROM-based holding pen. To release > >> it, one must write into a special register a jump address whose > >> low-order bits have been replaced with a secondary core's id, then > >> trigger an event with SEV. On receipt of an event, the ROM code > >> will examine the register's contents, and if the low-order bits > >> match its cpu id, it will clear them and write the value back to the > >> register just prior to jumping to the address specified. > >> > >> The location of the special register is defined in the device tree > >> using a "secondary-boot-reg" property in a node whose "enable-method" > >> matches. > >> > >> Derived from code originally provided by Ray Jui > >> > >> Signed-off-by: Alex Elder > >> --- > >> arch/arm/mach-bcm/Kconfig | 18 +++- > >> arch/arm/mach-bcm/Makefile | 3 + > >> arch/arm/mach-bcm/platsmp.c | 201 > >> > > > > Could we make that name a little bit more specific to the mobile SoCs? > > Sure. I thought about that but naming stuff here has been a sort > of ongoing struggle... "Kona" made some sense, in some cases, > but it's not perfect. Simlar with "mobile." > > I'll propose "kona_smp.c". OK with you? Unless I get a better > suggestion I'll plan to go with that next time around. Works for me. -Matt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 RESEND 2/5] ARM: add SMP support for Broadcom mobile SoCs
On Thu, May 15, 2014 at 11:03:49AM -0700, Florian Fainelli wrote: > Hi Alex, > > 2014-05-15 10:58 GMT-07:00 Alex Elder : > > This patch adds SMP support for BCM281XX and BCM21664 family SoCs. > > > > This feature is controlled with a distinct config option such that a > > SMP-enabled multi-v7 binary can be configured to run these SoCs in > > uniprocessor mode. Since this SMP functionality is used for > > multiple Broadcom mobile chip families the config option is called > > ARCH_BCM_MOBILE_SMP (for lack of a better name). > > > > On SoCs of this type, the secondary core is not held in reset on > > power-on. Instead it loops in a ROM-based holding pen. To release > > it, one must write into a special register a jump address whose > > low-order bits have been replaced with a secondary core's id, then > > trigger an event with SEV. On receipt of an event, the ROM code > > will examine the register's contents, and if the low-order bits > > match its cpu id, it will clear them and write the value back to the > > register just prior to jumping to the address specified. > > > > The location of the special register is defined in the device tree > > using a "secondary-boot-reg" property in a node whose "enable-method" > > matches. > > > > Derived from code originally provided by Ray Jui > > > > Signed-off-by: Alex Elder > > --- > > arch/arm/mach-bcm/Kconfig | 18 +++- > > arch/arm/mach-bcm/Makefile | 3 + > > arch/arm/mach-bcm/platsmp.c | 201 > > > > Could we make that name a little bit more specific to the mobile SoCs? > There are other BCM SoCs either currently supported in this directory > (BCM5310X), or making their way to be supported (brcmstb, bcm63xx), > and those share nothing with the Mobile SoC SMP code. Right. > Maybe we should create another level directory within mach-bcm... Let's not go that far. The general direction we need to go is to work toward removing this code from mach-bcm/ completely. I don't really want to see us adding directories and encouraging burying a lot of new files in them. A unique name will be enough and then we can work toward moving things out to drivers/ over time. -Matt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 RESEND 2/5] ARM: add SMP support for Broadcom mobile SoCs
On Thu, May 15, 2014 at 11:03:49AM -0700, Florian Fainelli wrote: Hi Alex, 2014-05-15 10:58 GMT-07:00 Alex Elder el...@linaro.org: This patch adds SMP support for BCM281XX and BCM21664 family SoCs. This feature is controlled with a distinct config option such that a SMP-enabled multi-v7 binary can be configured to run these SoCs in uniprocessor mode. Since this SMP functionality is used for multiple Broadcom mobile chip families the config option is called ARCH_BCM_MOBILE_SMP (for lack of a better name). On SoCs of this type, the secondary core is not held in reset on power-on. Instead it loops in a ROM-based holding pen. To release it, one must write into a special register a jump address whose low-order bits have been replaced with a secondary core's id, then trigger an event with SEV. On receipt of an event, the ROM code will examine the register's contents, and if the low-order bits match its cpu id, it will clear them and write the value back to the register just prior to jumping to the address specified. The location of the special register is defined in the device tree using a secondary-boot-reg property in a node whose enable-method matches. Derived from code originally provided by Ray Jui r...@broadcom.com Signed-off-by: Alex Elder el...@linaro.org --- arch/arm/mach-bcm/Kconfig | 18 +++- arch/arm/mach-bcm/Makefile | 3 + arch/arm/mach-bcm/platsmp.c | 201 Could we make that name a little bit more specific to the mobile SoCs? There are other BCM SoCs either currently supported in this directory (BCM5310X), or making their way to be supported (brcmstb, bcm63xx), and those share nothing with the Mobile SoC SMP code. Right. Maybe we should create another level directory within mach-bcm... Let's not go that far. The general direction we need to go is to work toward removing this code from mach-bcm/ completely. I don't really want to see us adding directories and encouraging burying a lot of new files in them. A unique name will be enough and then we can work toward moving things out to drivers/ over time. -Matt -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 RESEND 2/5] ARM: add SMP support for Broadcom mobile SoCs
On Thu, May 15, 2014 at 01:17:00PM -0500, Alex Elder wrote: On 05/15/2014 01:03 PM, Florian Fainelli wrote: Hi Alex, 2014-05-15 10:58 GMT-07:00 Alex Elder el...@linaro.org: This patch adds SMP support for BCM281XX and BCM21664 family SoCs. This feature is controlled with a distinct config option such that a SMP-enabled multi-v7 binary can be configured to run these SoCs in uniprocessor mode. Since this SMP functionality is used for multiple Broadcom mobile chip families the config option is called ARCH_BCM_MOBILE_SMP (for lack of a better name). On SoCs of this type, the secondary core is not held in reset on power-on. Instead it loops in a ROM-based holding pen. To release it, one must write into a special register a jump address whose low-order bits have been replaced with a secondary core's id, then trigger an event with SEV. On receipt of an event, the ROM code will examine the register's contents, and if the low-order bits match its cpu id, it will clear them and write the value back to the register just prior to jumping to the address specified. The location of the special register is defined in the device tree using a secondary-boot-reg property in a node whose enable-method matches. Derived from code originally provided by Ray Jui r...@broadcom.com Signed-off-by: Alex Elder el...@linaro.org --- arch/arm/mach-bcm/Kconfig | 18 +++- arch/arm/mach-bcm/Makefile | 3 + arch/arm/mach-bcm/platsmp.c | 201 Could we make that name a little bit more specific to the mobile SoCs? Sure. I thought about that but naming stuff here has been a sort of ongoing struggle... Kona made some sense, in some cases, but it's not perfect. Simlar with mobile. I'll propose kona_smp.c. OK with you? Unless I get a better suggestion I'll plan to go with that next time around. Works for me. -Matt -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
On Tue, May 13, 2014 at 04:06:02PM +0200, Javier Martinez Canillas wrote:
> On Tue, May 13, 2014 at 2:53 PM, Tom Rini wrote:
> > On 05/12/2014 04:57 PM, Robert Nelson wrote:
> Either case if fine with me. As who knows when the dtc "overlay" will
> every truly make it mainline, as the capemgr was the only real kernel
> user of the i2c/at24 eeprom information.
> >>>
> >>> Sounds like we should keep it disabled though so u-boot can be used
> >>> to toggle it while waiting for the capemgr. That's because the board
> >>> has a header for pins, so it's not exactly limited to just the capes.
> >>>
> >>> Anybody working on enabling/disabling cape dtb configurations in u-boot?
> >>
> >> Well,
> >>
> >> Would Tom even approve of that in mainline u-boot? He didn't want my
> >> "invert" the gpio to enable the usb hub on the older beagle xm A/B..
> >>
> >> http://lists.denx.de/pipermail/u-boot/2014-January/172154.html
> >>
> >> http://lists.denx.de/pipermail/u-boot/2014-January/172274.html
>
> Using fdt set from the bootloader to use the same FDT for similar
> boards (like the example with Beagle xM variants) is kind of trying to
> replicate what we used to do from boards files where it was possible
> to manage a set of boards using the same platform code.
>
> But Device Trees are meant to describe hardware and thus should be
> static, if two board are almost identical but slightly different, then
> are two different hardware where each need its proper FDT that
> describes it.
>
> >
> > I would think that using the 'fdt' command in U-Boot to add all
> > properties of every cape found on a running system would drive someone
> > to madness quite quickly. Moving all of Pantelis' work for dynamic
> > device trees from the kernel to N bootloaders (U-Boot, barebox, UEFI,
> > etc) sounds like a step in the wrong direction.
> >
>
> Agreed. I think that until the device tree overlay and the cape
> manager find their way into mainline we should treat capes as if they
> were expansion boards attached to a Computer-on-Module. That is, a
> static based board which its own DTS including the BB{B,W} as an dtsi
> and not something that can be added on runtime.
It's far more complicated than a SOM plus carrier board. Consider that
you can have any 4 of these capes stacked on the BBB/BBW in any
combination (assuming no resource conflicts). Capturing all possible
combinations in static dtsis is not practical.
-Matt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
On Tue, May 13, 2014 at 04:06:02PM +0200, Javier Martinez Canillas wrote:
On Tue, May 13, 2014 at 2:53 PM, Tom Rini tr...@ti.com wrote:
On 05/12/2014 04:57 PM, Robert Nelson wrote:
Either case if fine with me. As who knows when the dtc overlay will
every truly make it mainline, as the capemgr was the only real kernel
user of the i2c/at24 eeprom information.
Sounds like we should keep it disabled though so u-boot can be used
to toggle it while waiting for the capemgr. That's because the board
has a header for pins, so it's not exactly limited to just the capes.
Anybody working on enabling/disabling cape dtb configurations in u-boot?
Well,
Would Tom even approve of that in mainline u-boot? He didn't want my
invert the gpio to enable the usb hub on the older beagle xm A/B..
http://lists.denx.de/pipermail/u-boot/2014-January/172154.html
http://lists.denx.de/pipermail/u-boot/2014-January/172274.html
Using fdt set from the bootloader to use the same FDT for similar
boards (like the example with Beagle xM variants) is kind of trying to
replicate what we used to do from boards files where it was possible
to manage a set of boards using the same platform code.
But Device Trees are meant to describe hardware and thus should be
static, if two board are almost identical but slightly different, then
are two different hardware where each need its proper FDT that
describes it.
I would think that using the 'fdt' command in U-Boot to add all
properties of every cape found on a running system would drive someone
to madness quite quickly. Moving all of Pantelis' work for dynamic
device trees from the kernel to N bootloaders (U-Boot, barebox, UEFI,
etc) sounds like a step in the wrong direction.
Agreed. I think that until the device tree overlay and the cape
manager find their way into mainline we should treat capes as if they
were expansion boards attached to a Computer-on-Module. That is, a
static based board which its own DTS including the BB{B,W} as an dtsi
and not something that can be added on runtime.
It's far more complicated than a SOM plus carrier board. Consider that
you can have any 4 of these capes stacked on the BBB/BBW in any
combination (assuming no resource conflicts). Capturing all possible
combinations in static dtsis is not practical.
-Matt
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 RESEND 0/5] Add Broadcom Kona PWM Support
On Mon, Apr 28, 2014 at 08:00:39AM -0700, Tim Kryger wrote: > On Mon, Apr 28, 2014 at 4:07 AM, Thierry Reding > wrote: > > On Fri, Apr 25, 2014 at 11:31:10AM -0700, Tim Kryger wrote: > >> This series introduces the driver for the Kona PWM controller found in > >> Broadcom mobile SoCs like bcm281xx and updates the device tree and the > >> defconfig to enable use of this hardware on the bcm28155 AP board. > >> > > >> Tim Kryger (5): > >> Documentation: dt: Add Kona PWM binding > >> pwm: kona: Introduce Kona PWM controller support > >> ARM: dts: Declare the PWM for bcm11351 (bcm281xx) > >> ARM: dts: Enable the PWM for bcm28155 AP board > >> ARM: bcm_defconfig: Enable PWM and Backlight > > > I've applied patches 1 and 2 (with two tiny whitespace cleanups) to my > > for-next branch. > > Sounds good. Thank you. > > Matt and Christian, are you okay taking patches 3-5 through your tree? Yes, I've now applied them to the appropropriate mach-bcm 3.16 branches. -Matt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: l2c: prima2: only call l2x0_of_init() on matching nodes
On Mon, Apr 28, 2014 at 09:29:51AM -0500, Felipe Balbi wrote:
> On Sun, Apr 27, 2014 at 08:27:40PM -0400, Matt Porter wrote:
> > l2x0_of_init() is executed unconditionally within the sirfsoc_l2x0_init()
> > early initcall. In a multi v7 kernel this causes bcm281xx and bcm21664
> > platform to fail boot since they have their own pre l2x0 init sequence
> > that is required. Fix this by checking that a matching OF ID is present
> > before calling l2x0_of_init().
> >
> > Reported-by: Kevin Hilman
> > Signed-off-by: Matt Porter
> > ---
> > Applies against next-20140424 to fix the issue introduced in
> > 50655e6 ARM: l2c: prima2: remove cache size override
> >
> > arch/arm/mach-prima2/l2x0.c | 16 +++-
> > 1 file changed, 15 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/mach-prima2/l2x0.c b/arch/arm/mach-prima2/l2x0.c
> > index 09f68f0..1c2ed15 100644
> > --- a/arch/arm/mach-prima2/l2x0.c
> > +++ b/arch/arm/mach-prima2/l2x0.c
> > @@ -8,10 +8,24 @@
> >
> > #include
> > #include
> > +#include
> > #include
> >
> > +static const struct of_device_id sirf_l2x0_ids[] __initconst = {
> > + { .compatible = "sirf,prima2-pl310-cache" },
> > + { .compatible = "sirf,marco-pl310-cache" },
>
> that same commit removed these two from DTS, did you test with old DTS,
> btw any chance ?
The "fix" is tested against bcm281xx and bcm21664 as that is what the
l2c cleanup breaks in -next. As mentioned, I don't have the sirfsoc h/w
so this first attempt at a fix also breaks their platform. It can be
addressed by adding those platform specific compatibles back to the dts,
of course.
I'd much prefer that the sirfsoc folks fix this...it's going to break
other platforms in a multi v7 build.
-Matt
signature.asc
Description: Digital signature
Re: [PATCH v2 2/4] mfd: bcm590xx: add support for secondary I2C slave address
On Mon, Apr 28, 2014 at 12:56:27PM +0100, Lee Jones wrote: > On Wed, 23 Apr 2014, Matt Porter wrote: > > > BCM590xx utilizes a secondary I2C slave address to access additional > > register space. Add support for the secondary address space by > > instantiating a dummy I2C device with the appropriate secondary > > I2C slave address. Also expose a secondary regmap register space so > > that MFD drivers can access this secondary i2c slave address space. > > > > Signed-off-by: Matt Porter > > --- > > drivers/mfd/bcm590xx.c | 60 > > +--- > > include/linux/mfd/bcm590xx.h | 9 --- > > 2 files changed, 52 insertions(+), 17 deletions(-) > > Nice, flows much better now. > > Can I just apply the two MFD patches, or are there cross-deps? There's cross-deps so the regulator driver will need to go with it. Mark mentioned earlier in the thread that he wanted to merge through the regulator tree though. -Matt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: l2c: prima2: only call l2x0_of_init() on matching nodes
On Mon, Apr 28, 2014 at 10:15:33AM +0100, Russell King wrote: > On Sun, Apr 27, 2014 at 08:27:40PM -0400, Matt Porter wrote: > > l2x0_of_init() is executed unconditionally within the sirfsoc_l2x0_init() > > early initcall. In a multi v7 kernel this causes bcm281xx and bcm21664 > > platform to fail boot since they have their own pre l2x0 init sequence > > that is required. Fix this by checking that a matching OF ID is present > > before calling l2x0_of_init(). > > > > Reported-by: Kevin Hilman > > Signed-off-by: Matt Porter > > --- > > Applies against next-20140424 to fix the issue introduced in > > 50655e6 ARM: l2c: prima2: remove cache size override > > Err, this only "fixes" it because it effectively disables the L2 cache > _entirely_ - in the above commit, I kill your private compatible strings. > > This doesn't make sense. If the cache is already enabled, then the L2C > code won't try to enable it again. Ok, please suggest an alternative. You merged this commit..it looks like it had no ack from the platform maintainer..and I don't have hardware. The commit is wrong, we can't have every platform executing sirfsoc's l2x0_of_init() call/parameters by having this stuff in an early initcall like that. It would be pretty straightforward to add those private compatibles back so the approach works. If not, we need to move this to .init_machine where it's guaranteed to only run on sirfsoc. -Matt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: l2c: prima2: only call l2x0_of_init() on matching nodes
On Mon, Apr 28, 2014 at 10:15:33AM +0100, Russell King wrote: On Sun, Apr 27, 2014 at 08:27:40PM -0400, Matt Porter wrote: l2x0_of_init() is executed unconditionally within the sirfsoc_l2x0_init() early initcall. In a multi v7 kernel this causes bcm281xx and bcm21664 platform to fail boot since they have their own pre l2x0 init sequence that is required. Fix this by checking that a matching OF ID is present before calling l2x0_of_init(). Reported-by: Kevin Hilman khil...@linaro.org Signed-off-by: Matt Porter mpor...@linaro.org --- Applies against next-20140424 to fix the issue introduced in 50655e6 ARM: l2c: prima2: remove cache size override Err, this only fixes it because it effectively disables the L2 cache _entirely_ - in the above commit, I kill your private compatible strings. This doesn't make sense. If the cache is already enabled, then the L2C code won't try to enable it again. Ok, please suggest an alternative. You merged this commit..it looks like it had no ack from the platform maintainer..and I don't have hardware. The commit is wrong, we can't have every platform executing sirfsoc's l2x0_of_init() call/parameters by having this stuff in an early initcall like that. It would be pretty straightforward to add those private compatibles back so the approach works. If not, we need to move this to .init_machine where it's guaranteed to only run on sirfsoc. -Matt -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/4] mfd: bcm590xx: add support for secondary I2C slave address
On Mon, Apr 28, 2014 at 12:56:27PM +0100, Lee Jones wrote: On Wed, 23 Apr 2014, Matt Porter wrote: BCM590xx utilizes a secondary I2C slave address to access additional register space. Add support for the secondary address space by instantiating a dummy I2C device with the appropriate secondary I2C slave address. Also expose a secondary regmap register space so that MFD drivers can access this secondary i2c slave address space. Signed-off-by: Matt Porter mpor...@linaro.org --- drivers/mfd/bcm590xx.c | 60 +--- include/linux/mfd/bcm590xx.h | 9 --- 2 files changed, 52 insertions(+), 17 deletions(-) Nice, flows much better now. Can I just apply the two MFD patches, or are there cross-deps? There's cross-deps so the regulator driver will need to go with it. Mark mentioned earlier in the thread that he wanted to merge through the regulator tree though. -Matt -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: l2c: prima2: only call l2x0_of_init() on matching nodes
On Mon, Apr 28, 2014 at 09:29:51AM -0500, Felipe Balbi wrote:
On Sun, Apr 27, 2014 at 08:27:40PM -0400, Matt Porter wrote:
l2x0_of_init() is executed unconditionally within the sirfsoc_l2x0_init()
early initcall. In a multi v7 kernel this causes bcm281xx and bcm21664
platform to fail boot since they have their own pre l2x0 init sequence
that is required. Fix this by checking that a matching OF ID is present
before calling l2x0_of_init().
Reported-by: Kevin Hilman khil...@linaro.org
Signed-off-by: Matt Porter mpor...@linaro.org
---
Applies against next-20140424 to fix the issue introduced in
50655e6 ARM: l2c: prima2: remove cache size override
arch/arm/mach-prima2/l2x0.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-prima2/l2x0.c b/arch/arm/mach-prima2/l2x0.c
index 09f68f0..1c2ed15 100644
--- a/arch/arm/mach-prima2/l2x0.c
+++ b/arch/arm/mach-prima2/l2x0.c
@@ -8,10 +8,24 @@
#include linux/init.h
#include linux/kernel.h
+#include linux/of.h
#include asm/hardware/cache-l2x0.h
+static const struct of_device_id sirf_l2x0_ids[] __initconst = {
+ { .compatible = sirf,prima2-pl310-cache },
+ { .compatible = sirf,marco-pl310-cache },
that same commit removed these two from DTS, did you test with old DTS,
btw any chance ?
The fix is tested against bcm281xx and bcm21664 as that is what the
l2c cleanup breaks in -next. As mentioned, I don't have the sirfsoc h/w
so this first attempt at a fix also breaks their platform. It can be
addressed by adding those platform specific compatibles back to the dts,
of course.
I'd much prefer that the sirfsoc folks fix this...it's going to break
other platforms in a multi v7 build.
-Matt
signature.asc
Description: Digital signature
Re: [PATCH v6 RESEND 0/5] Add Broadcom Kona PWM Support
On Mon, Apr 28, 2014 at 08:00:39AM -0700, Tim Kryger wrote: On Mon, Apr 28, 2014 at 4:07 AM, Thierry Reding thierry.red...@gmail.com wrote: On Fri, Apr 25, 2014 at 11:31:10AM -0700, Tim Kryger wrote: This series introduces the driver for the Kona PWM controller found in Broadcom mobile SoCs like bcm281xx and updates the device tree and the defconfig to enable use of this hardware on the bcm28155 AP board. Tim Kryger (5): Documentation: dt: Add Kona PWM binding pwm: kona: Introduce Kona PWM controller support ARM: dts: Declare the PWM for bcm11351 (bcm281xx) ARM: dts: Enable the PWM for bcm28155 AP board ARM: bcm_defconfig: Enable PWM and Backlight I've applied patches 1 and 2 (with two tiny whitespace cleanups) to my for-next branch. Sounds good. Thank you. Matt and Christian, are you okay taking patches 3-5 through your tree? Yes, I've now applied them to the appropropriate mach-bcm 3.16 branches. -Matt -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: l2c: prima2: only call l2x0_of_init() on matching nodes
l2x0_of_init() is executed unconditionally within the sirfsoc_l2x0_init()
early initcall. In a multi v7 kernel this causes bcm281xx and bcm21664
platform to fail boot since they have their own pre l2x0 init sequence
that is required. Fix this by checking that a matching OF ID is present
before calling l2x0_of_init().
Reported-by: Kevin Hilman
Signed-off-by: Matt Porter
---
Applies against next-20140424 to fix the issue introduced in
50655e6 ARM: l2c: prima2: remove cache size override
arch/arm/mach-prima2/l2x0.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-prima2/l2x0.c b/arch/arm/mach-prima2/l2x0.c
index 09f68f0..1c2ed15 100644
--- a/arch/arm/mach-prima2/l2x0.c
+++ b/arch/arm/mach-prima2/l2x0.c
@@ -8,10 +8,24 @@
#include
#include
+#include
#include
+static const struct of_device_id sirf_l2x0_ids[] __initconst = {
+ { .compatible = "sirf,prima2-pl310-cache" },
+ { .compatible = "sirf,marco-pl310-cache" },
+ {},
+};
+
static int __init sirfsoc_l2x0_init(void)
{
- return l2x0_of_init(0, ~0);
+ struct device_node *np;
+ int ret = -EINVAL;
+
+ np = of_find_matching_node(NULL, sirf_l2x0_ids);
+ if (np)
+ ret = l2x0_of_init(0, ~0);
+
+ return ret;
}
early_initcall(sirfsoc_l2x0_init);
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: l2c: prima2: only call l2x0_of_init() on matching nodes
l2x0_of_init() is executed unconditionally within the sirfsoc_l2x0_init()
early initcall. In a multi v7 kernel this causes bcm281xx and bcm21664
platform to fail boot since they have their own pre l2x0 init sequence
that is required. Fix this by checking that a matching OF ID is present
before calling l2x0_of_init().
Reported-by: Kevin Hilman khil...@linaro.org
Signed-off-by: Matt Porter mpor...@linaro.org
---
Applies against next-20140424 to fix the issue introduced in
50655e6 ARM: l2c: prima2: remove cache size override
arch/arm/mach-prima2/l2x0.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-prima2/l2x0.c b/arch/arm/mach-prima2/l2x0.c
index 09f68f0..1c2ed15 100644
--- a/arch/arm/mach-prima2/l2x0.c
+++ b/arch/arm/mach-prima2/l2x0.c
@@ -8,10 +8,24 @@
#include linux/init.h
#include linux/kernel.h
+#include linux/of.h
#include asm/hardware/cache-l2x0.h
+static const struct of_device_id sirf_l2x0_ids[] __initconst = {
+ { .compatible = sirf,prima2-pl310-cache },
+ { .compatible = sirf,marco-pl310-cache },
+ {},
+};
+
static int __init sirfsoc_l2x0_init(void)
{
- return l2x0_of_init(0, ~0);
+ struct device_node *np;
+ int ret = -EINVAL;
+
+ np = of_find_matching_node(NULL, sirf_l2x0_ids);
+ if (np)
+ ret = l2x0_of_init(0, ~0);
+
+ return ret;
}
early_initcall(sirfsoc_l2x0_init);
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 RESEND 0/5] clk: bcm21664: add common clock support
On Fri, Apr 25, 2014 at 05:09:15PM -0700, Mike Turquette wrote: > Quoting Alex Elder (2014-04-21 14:26:22) > > This is series has two parts. The first two patches are changes > > to the existing Broadcom Kona family clock code to prepare for the > > addition of support for another SoC, bcm21664. > > > > The remaining three define the binding and code for bcm21664, and > > replace the use of "fake" clocks in the device tree with the real > > ones. This ends up being a fairly straightforward definition of > > the clocks on this SoC; the rest of the clock code is shared with > > other SoCs that use the Kona style clock system. > > Hi Alex, > > I'm happy to take only the clk patches or I can take the DT stuff as > well if it gets some Acks. Let me know how you want it handled. Hi Mike, Since there's a strict ordering requirement in this series (due to shared use of a DT include by the driver and dts) I'd like it if you could take the entire series through your tree to keep these together. I've acked the dts patch. Thanks, Matt > > This series depends on the following patch, which has been taken > > into the clk-fixes tree: > > clk: bcm281xx: don't use unnamed structs or unions > > https://lkml.org/lkml/2014/4/7/322 > > > > In addition, it depends on the version 4 of the following series, > > just (re)posted for review: > > clk: bcm281xx: updates > > https://lkml.org/lkml/2014/4/8/485 > > > > The patches in this series--based on the current linus/master branch > > plus the patches mentioned above--are available here: > > http://git.linaro.org/git/landing-teams/working/broadcom/kernel.git > > Branch review/bcm21664-clock-v2 > > > > Alex Elder (5): > > clk: bcm281xx: move compatible string definitions > > ARM: dts: revise kona clock binding document > > ARM: dts: define clock binding for bcm21664 > > clk: bcm21664: use common clock framework > > ARM: dts: use real clocks for bcm21664 > > > > .../devicetree/bindings/clock/bcm-kona-clock.txt | 116 ++--- > > arch/arm/boot/dts/bcm21664.dtsi| 190 +- > > drivers/clk/bcm/Kconfig| 2 +- > > drivers/clk/bcm/Makefile | 1 + > > drivers/clk/bcm/clk-bcm21664.c | 290 > > + > > drivers/clk/bcm/clk-bcm281xx.c | 12 - > > include/dt-bindings/clock/bcm21664.h | 62 + > > include/dt-bindings/clock/bcm281xx.h | 12 + > > 8 files changed, 565 insertions(+), 120 deletions(-) > > create mode 100644 drivers/clk/bcm/clk-bcm21664.c > > create mode 100644 include/dt-bindings/clock/bcm21664.h > > > > -- > > 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 RESEND 5/5] ARM: dts: use real clocks for bcm21664
On Mon, Apr 21, 2014 at 04:26:27PM -0500, Alex Elder wrote:
> Replace the "fake" fixed-rate clocks used previously for the
> bcm21664 family with "real" ones.
>
> Signed-off-by: Alex Elder
Acked-by: Matt Porter
> ---
> arch/arm/boot/dts/bcm21664.dtsi | 190
> +---
> 1 file changed, 118 insertions(+), 72 deletions(-)
>
> diff --git a/arch/arm/boot/dts/bcm21664.dtsi b/arch/arm/boot/dts/bcm21664.dtsi
> index 08a44d4..8b36682 100644
> --- a/arch/arm/boot/dts/bcm21664.dtsi
> +++ b/arch/arm/boot/dts/bcm21664.dtsi
> @@ -14,6 +14,8 @@
> #include
> #include
>
> +#include "dt-bindings/clock/bcm21664.h"
> +
> #include "skeleton.dtsi"
>
> / {
> @@ -43,7 +45,7 @@
> compatible = "brcm,bcm21664-dw-apb-uart", "snps,dw-apb-uart";
> status = "disabled";
> reg = <0x3e00 0x118>;
> - clocks = <_clk>;
> + clocks = <_ccu BCM21664_SLAVE_CCU_UARTB>;
> interrupts = ;
> reg-shift = <2>;
> reg-io-width = <4>;
> @@ -53,7 +55,7 @@
> compatible = "brcm,bcm21664-dw-apb-uart", "snps,dw-apb-uart";
> status = "disabled";
> reg = <0x3e001000 0x118>;
> - clocks = <_clk>;
> + clocks = <_ccu BCM21664_SLAVE_CCU_UARTB2>;
> interrupts = ;
> reg-shift = <2>;
> reg-io-width = <4>;
> @@ -63,7 +65,7 @@
> compatible = "brcm,bcm21664-dw-apb-uart", "snps,dw-apb-uart";
> status = "disabled";
> reg = <0x3e002000 0x118>;
> - clocks = <_clk>;
> + clocks = <_ccu BCM21664_SLAVE_CCU_UARTB3>;
> interrupts = ;
> reg-shift = <2>;
> reg-io-width = <4>;
> @@ -85,7 +87,7 @@
> compatible = "brcm,kona-timer";
> reg = <0x35006000 0x1c>;
> interrupts = ;
> - clocks = <_timer_clk>;
> + clocks = <_ccu BCM21664_AON_CCU_HUB_TIMER>;
> };
>
> gpio: gpio@35003000 {
> @@ -106,7 +108,7 @@
> compatible = "brcm,kona-sdhci";
> reg = <0x3f18 0x801c>;
> interrupts = ;
> - clocks = <_clk>;
> + clocks = <_ccu BCM21664_MASTER_CCU_SDIO1>;
> status = "disabled";
> };
>
> @@ -114,7 +116,7 @@
> compatible = "brcm,kona-sdhci";
> reg = <0x3f19 0x801c>;
> interrupts = ;
> - clocks = <_clk>;
> + clocks = <_ccu BCM21664_MASTER_CCU_SDIO2>;
> status = "disabled";
> };
>
> @@ -122,7 +124,7 @@
> compatible = "brcm,kona-sdhci";
> reg = <0x3f1a 0x801c>;
> interrupts = ;
> - clocks = <_clk>;
> + clocks = <_ccu BCM21664_MASTER_CCU_SDIO3>;
> status = "disabled";
> };
>
> @@ -130,7 +132,7 @@
> compatible = "brcm,kona-sdhci";
> reg = <0x3f1b 0x801c>;
> interrupts = ;
> - clocks = <_clk>;
> + clocks = <_ccu BCM21664_MASTER_CCU_SDIO4>;
> status = "disabled";
> };
>
> @@ -140,7 +142,7 @@
> interrupts = ;
> #address-cells = <1>;
> #size-cells = <0>;
> - clocks = <_clk>;
> + clocks = <_ccu BCM21664_SLAVE_CCU_BSC1>;
> status = "disabled";
> };
>
> @@ -150,7 +152,7 @@
> interrupts = ;
> #address-cells = <1>;
> #size-cells = <0>;
> - clocks = <_clk>;
> + clocks = <_ccu BCM21664_SLAVE_CCU_BSC2>;
> status = "disabled";
> };
>
> @@ -160,7 +162,7 @@
> interrupts = ;
> #address-cells = <1>;
> #size-cells = <0>;
> - clocks = <_clk>;
> + clocks = <_ccu BCM21664_SLAVE_CCU_BSC3>;
> status = "disabled";
> };
>
> @@ -170,105 +172,149 @@
> interrupts = ;
> #address-c
Re: [PATCH v2 00/10] ARM: bcm: SCM and L2 cache code cleanup
On Mon, Apr 21, 2014 at 04:53:01PM -0500, Alex Elder wrote:
> This series cleans up a number of things in the code that issues
> secure monitor ("smc") requests for the bcm281xx and bcm21664 SoC
> families. This code is currently used only for enabling the level-2
> cache.
>
> There are some bug fixes and other improvements. An assembly
> language file containing a single function has been eliminated by
> re-implementing the code using inline assembly. Some comments have
> been expanded and clarified. Kernel configuration options allow
> finer-grained control over how this code gets built. Finally, the
> "kona.c" and "kona.h" files are renamed to reflect the fact that
> only contain code related to level-2 cache support.
Applied the series to mach-bcm for-3.16/cleanup
Thanks,
Matt
>
> This series is based on v3.15-rc2, and depends on one patch posted
> previously:
> [PATCH v4] mach-bcm: clean up config and build targets
> https://lkml.org/lkml/2014/4/15/303
>
> It is available here:
> http://git.linaro.org/landing-teams/working/broadcom/kernel.git
> Branch review/bcm-smc-cleanup-v2
>
> -Alex
>
> History:
> v2: - Followed two suggestions from Russell King. Rebased to v3.15-rc2
>
> Alex Elder (10):
> ARM: bcm: use memory accessors for ioremapped area
> ARM: bcm: err, don't BUG() on SMC init failures
> ARM: bcm: clean up SMC code
> ARM: bcm: have bcm_kona_smc() return request result
> ARM: bcm: don't special-case CPU 0 in bcm_kona_smc()
> ARM: bcm: config option for l2 cache support
> ARM: bcm: tidy up a few includes
> ARM: bcm: use inline assembly for "smc" request
> ARM: bcm: rewrite commentary for bcm_kona_do_smc()
> ARM: bcm: rename "kona.h" and "kona.c"
>
> arch/arm/mach-bcm/Kconfig | 12 ++-
> arch/arm/mach-bcm/Makefile| 10 +-
> arch/arm/mach-bcm/bcm_kona_smc.c | 136
> +++---
> arch/arm/mach-bcm/bcm_kona_smc.h | 52 +-
> arch/arm/mach-bcm/bcm_kona_smc_asm.S | 41
> arch/arm/mach-bcm/board_bcm21664.c| 5 +-
> arch/arm/mach-bcm/board_bcm281xx.c| 2 +-
> arch/arm/mach-bcm/{kona.c => kona_l2_cache.c} | 16 +--
> arch/arm/mach-bcm/{kona.h => kona_l2_cache.h} | 6 +-
> 9 files changed, 136 insertions(+), 144 deletions(-)
> delete mode 100644 arch/arm/mach-bcm/bcm_kona_smc_asm.S
> rename arch/arm/mach-bcm/{kona.c => kona_l2_cache.c} (80%)
> rename arch/arm/mach-bcm/{kona.h => kona_l2_cache.h} (80%)
>
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] mach-bcm: clean up config and build targets
On Tue, Apr 15, 2014 at 07:37:19AM -0500, Alex Elder wrote: > Currently CONFIG_ARCH_BCM_MOBILE is used to select all (both) > Broadcom mobile SoC families. Instead, use that only as a config > menu switch, and define specific symbols like ARCH_BCM_281XX to > select a particular SoC family. If ARCH_BCM_MOBILE is selected, all > of the SoCs will be selected by default, but this way each can be > disabled individually as well. > > Note that BCM281xx and BCM21664 both require the SMC and L2 cache > control code, so that code will be built based on ARCH_BCM_MOBILE. > > Signed-off-by: Alex Elder Applied to mach-bcm for-3.16/cleanup [added ARM: to patch title]. Thanks, Matt > --- > v4: Rebased on to of v3.15-rc1. Small tweak in Makefile. > v3: SMC and L2 cache code is needed by both SoC families. > v2: No longer uses Kbuild's $(-y) variable mechanism. > > The patch is available here: > http://git.linaro.org/landing-teams/working/broadcom/kernel.git > Branch review/mach-bcm-cleanup-v4 > > arch/arm/mach-bcm/Kconfig | 28 > arch/arm/mach-bcm/Makefile | 15 --- > 2 files changed, 36 insertions(+), 7 deletions(-) > > diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig > index 49c914c..5f5740f 100644 > --- a/arch/arm/mach-bcm/Kconfig > +++ b/arch/arm/mach-bcm/Kconfig > @@ -10,7 +10,7 @@ if ARCH_BCM > menu "Broadcom SoC Selection" > > config ARCH_BCM_MOBILE > - bool "Broadcom Mobile SoC" if ARCH_MULTI_V7 > + bool "Broadcom Mobile SoC Support" if ARCH_MULTI_V7 > depends on MMU > select ARCH_REQUIRE_GPIOLIB > select ARM_ERRATA_754322 > @@ -23,9 +23,29 @@ config ARCH_BCM_MOBILE > select PINCTRL > help > This enables support for systems based on Broadcom mobile SoCs. > - It currently supports the 'BCM281XX' family, which includes > - BCM11130, BCM11140, BCM11351, BCM28145 and > - BCM28155 variants. > + > +if ARCH_BCM_MOBILE > + > +menu "Broadcom Mobile SoC Selection" > + > +config ARCH_BCM_281XX > + bool "Broadcom BCM281XX SoC family" > + default y > + help > + Enable support for the the BCM281XX family, which includes > + BCM11130, BCM11140, BCM11351, BCM28145 and BCM28155 > + variants. > + > +config ARCH_BCM_21664 > + bool "Broadcom BCM21664 SoC family" > + default y > + help > + Enable support for the the BCM21664 family, which includes > + BCM21663 and BCM21664 variants. > + > +endmenu > + > +endif > > config ARCH_BCM2835 > bool "Broadcom BCM2835 family" if ARCH_MULTI_V6 > diff --git a/arch/arm/mach-bcm/Makefile b/arch/arm/mach-bcm/Makefile > index a326b28..7fb9b04 100644 > --- a/arch/arm/mach-bcm/Makefile > +++ b/arch/arm/mach-bcm/Makefile > @@ -10,10 +10,19 @@ > # of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > # GNU General Public License for more details. > > -obj-$(CONFIG_ARCH_BCM_MOBILE):= board_bcm281xx.o board_bcm21664.o \ > - bcm_kona_smc.o bcm_kona_smc_asm.o kona.o > -obj-$(CONFIG_ARCH_BCM2835) += board_bcm2835.o > +# BCM281XX > +obj-$(CONFIG_ARCH_BCM_281XX) += board_bcm281xx.o > > +# BCM21664 > +obj-$(CONFIG_ARCH_BCM_21664) += board_bcm21664.o > + > +# BCM281XX and BCM21664 L2 cache control > +obj-$(CONFIG_ARCH_BCM_MOBILE)+= bcm_kona_smc.o bcm_kona_smc_asm.o > kona.o > plus_sec := $(call as-instr,.arch_extension sec,+sec) > AFLAGS_bcm_kona_smc_asm.o:=-Wa,-march=armv7-a$(plus_sec) > + > +# BCM2835 > +obj-$(CONFIG_ARCH_BCM2835) += board_bcm2835.o > + > +# BCM5301X > obj-$(CONFIG_ARCH_BCM_5301X) += bcm_5301x.o > -- > 1.7.9.5 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] mach-bcm: clean up config and build targets
On Tue, Apr 15, 2014 at 07:37:19AM -0500, Alex Elder wrote: Currently CONFIG_ARCH_BCM_MOBILE is used to select all (both) Broadcom mobile SoC families. Instead, use that only as a config menu switch, and define specific symbols like ARCH_BCM_281XX to select a particular SoC family. If ARCH_BCM_MOBILE is selected, all of the SoCs will be selected by default, but this way each can be disabled individually as well. Note that BCM281xx and BCM21664 both require the SMC and L2 cache control code, so that code will be built based on ARCH_BCM_MOBILE. Signed-off-by: Alex Elder el...@linaro.org Applied to mach-bcm for-3.16/cleanup [added ARM: to patch title]. Thanks, Matt --- v4: Rebased on to of v3.15-rc1. Small tweak in Makefile. v3: SMC and L2 cache code is needed by both SoC families. v2: No longer uses Kbuild's $(modulename-y) variable mechanism. The patch is available here: http://git.linaro.org/landing-teams/working/broadcom/kernel.git Branch review/mach-bcm-cleanup-v4 arch/arm/mach-bcm/Kconfig | 28 arch/arm/mach-bcm/Makefile | 15 --- 2 files changed, 36 insertions(+), 7 deletions(-) diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig index 49c914c..5f5740f 100644 --- a/arch/arm/mach-bcm/Kconfig +++ b/arch/arm/mach-bcm/Kconfig @@ -10,7 +10,7 @@ if ARCH_BCM menu Broadcom SoC Selection config ARCH_BCM_MOBILE - bool Broadcom Mobile SoC if ARCH_MULTI_V7 + bool Broadcom Mobile SoC Support if ARCH_MULTI_V7 depends on MMU select ARCH_REQUIRE_GPIOLIB select ARM_ERRATA_754322 @@ -23,9 +23,29 @@ config ARCH_BCM_MOBILE select PINCTRL help This enables support for systems based on Broadcom mobile SoCs. - It currently supports the 'BCM281XX' family, which includes - BCM11130, BCM11140, BCM11351, BCM28145 and - BCM28155 variants. + +if ARCH_BCM_MOBILE + +menu Broadcom Mobile SoC Selection + +config ARCH_BCM_281XX + bool Broadcom BCM281XX SoC family + default y + help + Enable support for the the BCM281XX family, which includes + BCM11130, BCM11140, BCM11351, BCM28145 and BCM28155 + variants. + +config ARCH_BCM_21664 + bool Broadcom BCM21664 SoC family + default y + help + Enable support for the the BCM21664 family, which includes + BCM21663 and BCM21664 variants. + +endmenu + +endif config ARCH_BCM2835 bool Broadcom BCM2835 family if ARCH_MULTI_V6 diff --git a/arch/arm/mach-bcm/Makefile b/arch/arm/mach-bcm/Makefile index a326b28..7fb9b04 100644 --- a/arch/arm/mach-bcm/Makefile +++ b/arch/arm/mach-bcm/Makefile @@ -10,10 +10,19 @@ # of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. -obj-$(CONFIG_ARCH_BCM_MOBILE):= board_bcm281xx.o board_bcm21664.o \ - bcm_kona_smc.o bcm_kona_smc_asm.o kona.o -obj-$(CONFIG_ARCH_BCM2835) += board_bcm2835.o +# BCM281XX +obj-$(CONFIG_ARCH_BCM_281XX) += board_bcm281xx.o +# BCM21664 +obj-$(CONFIG_ARCH_BCM_21664) += board_bcm21664.o + +# BCM281XX and BCM21664 L2 cache control +obj-$(CONFIG_ARCH_BCM_MOBILE)+= bcm_kona_smc.o bcm_kona_smc_asm.o kona.o plus_sec := $(call as-instr,.arch_extension sec,+sec) AFLAGS_bcm_kona_smc_asm.o:=-Wa,-march=armv7-a$(plus_sec) + +# BCM2835 +obj-$(CONFIG_ARCH_BCM2835) += board_bcm2835.o + +# BCM5301X obj-$(CONFIG_ARCH_BCM_5301X) += bcm_5301x.o -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/10] ARM: bcm: SCM and L2 cache code cleanup
On Mon, Apr 21, 2014 at 04:53:01PM -0500, Alex Elder wrote:
This series cleans up a number of things in the code that issues
secure monitor (smc) requests for the bcm281xx and bcm21664 SoC
families. This code is currently used only for enabling the level-2
cache.
There are some bug fixes and other improvements. An assembly
language file containing a single function has been eliminated by
re-implementing the code using inline assembly. Some comments have
been expanded and clarified. Kernel configuration options allow
finer-grained control over how this code gets built. Finally, the
kona.c and kona.h files are renamed to reflect the fact that
only contain code related to level-2 cache support.
Applied the series to mach-bcm for-3.16/cleanup
Thanks,
Matt
This series is based on v3.15-rc2, and depends on one patch posted
previously:
[PATCH v4] mach-bcm: clean up config and build targets
https://lkml.org/lkml/2014/4/15/303
It is available here:
http://git.linaro.org/landing-teams/working/broadcom/kernel.git
Branch review/bcm-smc-cleanup-v2
-Alex
History:
v2: - Followed two suggestions from Russell King. Rebased to v3.15-rc2
Alex Elder (10):
ARM: bcm: use memory accessors for ioremapped area
ARM: bcm: err, don't BUG() on SMC init failures
ARM: bcm: clean up SMC code
ARM: bcm: have bcm_kona_smc() return request result
ARM: bcm: don't special-case CPU 0 in bcm_kona_smc()
ARM: bcm: config option for l2 cache support
ARM: bcm: tidy up a few includes
ARM: bcm: use inline assembly for smc request
ARM: bcm: rewrite commentary for bcm_kona_do_smc()
ARM: bcm: rename kona.h and kona.c
arch/arm/mach-bcm/Kconfig | 12 ++-
arch/arm/mach-bcm/Makefile| 10 +-
arch/arm/mach-bcm/bcm_kona_smc.c | 136
+++---
arch/arm/mach-bcm/bcm_kona_smc.h | 52 +-
arch/arm/mach-bcm/bcm_kona_smc_asm.S | 41
arch/arm/mach-bcm/board_bcm21664.c| 5 +-
arch/arm/mach-bcm/board_bcm281xx.c| 2 +-
arch/arm/mach-bcm/{kona.c = kona_l2_cache.c} | 16 +--
arch/arm/mach-bcm/{kona.h = kona_l2_cache.h} | 6 +-
9 files changed, 136 insertions(+), 144 deletions(-)
delete mode 100644 arch/arm/mach-bcm/bcm_kona_smc_asm.S
rename arch/arm/mach-bcm/{kona.c = kona_l2_cache.c} (80%)
rename arch/arm/mach-bcm/{kona.h = kona_l2_cache.h} (80%)
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 RESEND 5/5] ARM: dts: use real clocks for bcm21664
On Mon, Apr 21, 2014 at 04:26:27PM -0500, Alex Elder wrote:
Replace the fake fixed-rate clocks used previously for the
bcm21664 family with real ones.
Signed-off-by: Alex Elder el...@linaro.org
Acked-by: Matt Porter mpor...@linaro.org
---
arch/arm/boot/dts/bcm21664.dtsi | 190
+---
1 file changed, 118 insertions(+), 72 deletions(-)
diff --git a/arch/arm/boot/dts/bcm21664.dtsi b/arch/arm/boot/dts/bcm21664.dtsi
index 08a44d4..8b36682 100644
--- a/arch/arm/boot/dts/bcm21664.dtsi
+++ b/arch/arm/boot/dts/bcm21664.dtsi
@@ -14,6 +14,8 @@
#include dt-bindings/interrupt-controller/arm-gic.h
#include dt-bindings/interrupt-controller/irq.h
+#include dt-bindings/clock/bcm21664.h
+
#include skeleton.dtsi
/ {
@@ -43,7 +45,7 @@
compatible = brcm,bcm21664-dw-apb-uart, snps,dw-apb-uart;
status = disabled;
reg = 0x3e00 0x118;
- clocks = uartb_clk;
+ clocks = slave_ccu BCM21664_SLAVE_CCU_UARTB;
interrupts = GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH;
reg-shift = 2;
reg-io-width = 4;
@@ -53,7 +55,7 @@
compatible = brcm,bcm21664-dw-apb-uart, snps,dw-apb-uart;
status = disabled;
reg = 0x3e001000 0x118;
- clocks = uartb2_clk;
+ clocks = slave_ccu BCM21664_SLAVE_CCU_UARTB2;
interrupts = GIC_SPI 66 IRQ_TYPE_LEVEL_HIGH;
reg-shift = 2;
reg-io-width = 4;
@@ -63,7 +65,7 @@
compatible = brcm,bcm21664-dw-apb-uart, snps,dw-apb-uart;
status = disabled;
reg = 0x3e002000 0x118;
- clocks = uartb3_clk;
+ clocks = slave_ccu BCM21664_SLAVE_CCU_UARTB3;
interrupts = GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH;
reg-shift = 2;
reg-io-width = 4;
@@ -85,7 +87,7 @@
compatible = brcm,kona-timer;
reg = 0x35006000 0x1c;
interrupts = GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH;
- clocks = hub_timer_clk;
+ clocks = aon_ccu BCM21664_AON_CCU_HUB_TIMER;
};
gpio: gpio@35003000 {
@@ -106,7 +108,7 @@
compatible = brcm,kona-sdhci;
reg = 0x3f18 0x801c;
interrupts = GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH;
- clocks = sdio1_clk;
+ clocks = master_ccu BCM21664_MASTER_CCU_SDIO1;
status = disabled;
};
@@ -114,7 +116,7 @@
compatible = brcm,kona-sdhci;
reg = 0x3f19 0x801c;
interrupts = GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH;
- clocks = sdio2_clk;
+ clocks = master_ccu BCM21664_MASTER_CCU_SDIO2;
status = disabled;
};
@@ -122,7 +124,7 @@
compatible = brcm,kona-sdhci;
reg = 0x3f1a 0x801c;
interrupts = GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH;
- clocks = sdio3_clk;
+ clocks = master_ccu BCM21664_MASTER_CCU_SDIO3;
status = disabled;
};
@@ -130,7 +132,7 @@
compatible = brcm,kona-sdhci;
reg = 0x3f1b 0x801c;
interrupts = GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH;
- clocks = sdio4_clk;
+ clocks = master_ccu BCM21664_MASTER_CCU_SDIO4;
status = disabled;
};
@@ -140,7 +142,7 @@
interrupts = GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH;
#address-cells = 1;
#size-cells = 0;
- clocks = bsc1_clk;
+ clocks = slave_ccu BCM21664_SLAVE_CCU_BSC1;
status = disabled;
};
@@ -150,7 +152,7 @@
interrupts = GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH;
#address-cells = 1;
#size-cells = 0;
- clocks = bsc2_clk;
+ clocks = slave_ccu BCM21664_SLAVE_CCU_BSC2;
status = disabled;
};
@@ -160,7 +162,7 @@
interrupts = GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH;
#address-cells = 1;
#size-cells = 0;
- clocks = bsc3_clk;
+ clocks = slave_ccu BCM21664_SLAVE_CCU_BSC3;
status = disabled;
};
@@ -170,105 +172,149 @@
interrupts = GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH;
#address-cells = 1;
#size-cells = 0;
- clocks = bsc4_clk;
+ clocks = slave_ccu BCM21664_SLAVE_CCU_BSC4;
status = disabled;
};
clocks {
- bsc1_clk: bsc1 {
- compatible = fixed-clock;
- clock-frequency = 1300;
- #clock-cells = 0;
- };
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
- bsc2_clk: bsc2 {
- compatible
Re: [PATCH v2 RESEND 0/5] clk: bcm21664: add common clock support
On Fri, Apr 25, 2014 at 05:09:15PM -0700, Mike Turquette wrote: Quoting Alex Elder (2014-04-21 14:26:22) This is series has two parts. The first two patches are changes to the existing Broadcom Kona family clock code to prepare for the addition of support for another SoC, bcm21664. The remaining three define the binding and code for bcm21664, and replace the use of fake clocks in the device tree with the real ones. This ends up being a fairly straightforward definition of the clocks on this SoC; the rest of the clock code is shared with other SoCs that use the Kona style clock system. Hi Alex, I'm happy to take only the clk patches or I can take the DT stuff as well if it gets some Acks. Let me know how you want it handled. Hi Mike, Since there's a strict ordering requirement in this series (due to shared use of a DT include by the driver and dts) I'd like it if you could take the entire series through your tree to keep these together. I've acked the dts patch. Thanks, Matt This series depends on the following patch, which has been taken into the clk-fixes tree: clk: bcm281xx: don't use unnamed structs or unions https://lkml.org/lkml/2014/4/7/322 In addition, it depends on the version 4 of the following series, just (re)posted for review: clk: bcm281xx: updates https://lkml.org/lkml/2014/4/8/485 The patches in this series--based on the current linus/master branch plus the patches mentioned above--are available here: http://git.linaro.org/git/landing-teams/working/broadcom/kernel.git Branch review/bcm21664-clock-v2 Alex Elder (5): clk: bcm281xx: move compatible string definitions ARM: dts: revise kona clock binding document ARM: dts: define clock binding for bcm21664 clk: bcm21664: use common clock framework ARM: dts: use real clocks for bcm21664 .../devicetree/bindings/clock/bcm-kona-clock.txt | 116 ++--- arch/arm/boot/dts/bcm21664.dtsi| 190 +- drivers/clk/bcm/Kconfig| 2 +- drivers/clk/bcm/Makefile | 1 + drivers/clk/bcm/clk-bcm21664.c | 290 + drivers/clk/bcm/clk-bcm281xx.c | 12 - include/dt-bindings/clock/bcm21664.h | 62 + include/dt-bindings/clock/bcm281xx.h | 12 + 8 files changed, 565 insertions(+), 120 deletions(-) create mode 100644 drivers/clk/bcm/clk-bcm21664.c create mode 100644 include/dt-bindings/clock/bcm21664.h -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] dt: bindings: dwc2: fix required value for the phy-names property
"7408484 usb: gadget: s3c-hsotg: enable generic phy support" introduces generic phy support to the dwc2.txt binding and the s3c-hsotg driver which implements support for the binding. The binding documentation incorrectly states that the phy-names property will be "device". The binding example, driver, and one dts user all implement the phy-names property as requiring "usb2-phy". Fix the dwc2.txt binding documentation to correctly specify "usb2-phy" as the appropriate value for phy-names. Reported-by: Tomasz Figa Signed-off-by: Matt Porter --- Documentation/devicetree/bindings/usb/dwc2.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt b/Documentation/devicetree/bindings/usb/dwc2.txt index b8b6871..467ddd1 100644 --- a/Documentation/devicetree/bindings/usb/dwc2.txt +++ b/Documentation/devicetree/bindings/usb/dwc2.txt @@ -13,7 +13,7 @@ Refer to clk/clock-bindings.txt for generic clock consumer properties Optional properties: - phys: phy provider specifier -- phy-names: shall be "device" +- phy-names: shall be "usb2-phy" Refer to phy/phy-bindings.txt for generic phy consumer properties Example: -- 1.8.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] dt: bindings: dwc2: fix required value for the phy-names property
7408484 usb: gadget: s3c-hsotg: enable generic phy support introduces generic phy support to the dwc2.txt binding and the s3c-hsotg driver which implements support for the binding. The binding documentation incorrectly states that the phy-names property will be device. The binding example, driver, and one dts user all implement the phy-names property as requiring usb2-phy. Fix the dwc2.txt binding documentation to correctly specify usb2-phy as the appropriate value for phy-names. Reported-by: Tomasz Figa t.f...@samsung.com Signed-off-by: Matt Porter mpor...@linaro.org --- Documentation/devicetree/bindings/usb/dwc2.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt b/Documentation/devicetree/bindings/usb/dwc2.txt index b8b6871..467ddd1 100644 --- a/Documentation/devicetree/bindings/usb/dwc2.txt +++ b/Documentation/devicetree/bindings/usb/dwc2.txt @@ -13,7 +13,7 @@ Refer to clk/clock-bindings.txt for generic clock consumer properties Optional properties: - phys: phy provider specifier -- phy-names: shall be device +- phy-names: shall be usb2-phy Refer to phy/phy-bindings.txt for generic phy consumer properties Example: -- 1.8.4 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/4] Support additional regulators on BCM590xx
Changes since v1: - Fix a several commit log typos and capitalization - Drop use of addmap[0|1] in favor of i2c_[pri|sec] - Replace regmap[0|1] with regmap_[pri|sec] This series enables support for 7 additional regulators on the BCM59056 PMU. These regulators are accessed via a secondary I2C slave address. The MFD driver exposes an additional regmap descriptor for the additional address space and the regulator implements support for GPLDO1-6 and VBUS regulators. Matt Porter (4): mfd: bcm590xx: update binding with additional BCM59056 regulators mfd: bcm590xx: add support for secondary I2C slave address regulator: bcm590xx: add support for regulators on secondary I2C slave ARM: dts: bcm590xx: add support for GPLDO and VBUS regulators Documentation/devicetree/bindings/mfd/bcm590xx.txt | 4 +- arch/arm/boot/dts/bcm59056.dtsi| 21 + drivers/mfd/bcm590xx.c | 60 ++ drivers/regulator/bcm590xx-regulator.c | 92 +++--- include/linux/mfd/bcm590xx.h | 9 ++- 5 files changed, 158 insertions(+), 28 deletions(-) -- 1.8.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/4] mfd: bcm590xx: update binding with additional BCM59056 regulators
The BCM59056 supports GPLDO1-6 and VBUS regulators in a secondary
I2C slave address space. Add these regulators to the list of valid
regulator node names for BCM59056.
Signed-off-by: Matt Porter
---
Documentation/devicetree/bindings/mfd/bcm590xx.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/mfd/bcm590xx.txt
b/Documentation/devicetree/bindings/mfd/bcm590xx.txt
index 1fe30e2..be51a15 100644
--- a/Documentation/devicetree/bindings/mfd/bcm590xx.txt
+++ b/Documentation/devicetree/bindings/mfd/bcm590xx.txt
@@ -19,7 +19,9 @@ Optional child nodes:
The valid regulator node names for BCM59056 are:
rfldo, camldo1, camldo2, simldo1, simldo2, sdldo, sdxldo,
mmcldo1, mmcldo2, audldo, micldo, usbldo, vibldo,
- csr, iosr1, iosr2, msr, sdsr1, sdsr2, vsr
+ csr, iosr1, iosr2, msr, sdsr1, sdsr2, vsr,
+ gpldo1, gpldo2, gpldo3, gpldo4, gpldo5, gpldo6,
+ vbus
Example:
pmu: bcm59056@8 {
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/4] mfd: bcm590xx: add support for secondary I2C slave address
BCM590xx utilizes a secondary I2C slave address to access additional
register space. Add support for the secondary address space by
instantiating a dummy I2C device with the appropriate secondary
I2C slave address. Also expose a secondary regmap register space so
that MFD drivers can access this secondary i2c slave address space.
Signed-off-by: Matt Porter
---
drivers/mfd/bcm590xx.c | 60 +---
include/linux/mfd/bcm590xx.h | 9 ---
2 files changed, 52 insertions(+), 17 deletions(-)
diff --git a/drivers/mfd/bcm590xx.c b/drivers/mfd/bcm590xx.c
index e9a33c7..43cba1a 100644
--- a/drivers/mfd/bcm590xx.c
+++ b/drivers/mfd/bcm590xx.c
@@ -28,39 +28,71 @@ static const struct mfd_cell bcm590xx_devs[] = {
},
};
-static const struct regmap_config bcm590xx_regmap_config = {
+static const struct regmap_config bcm590xx_regmap_config_pri = {
.reg_bits = 8,
.val_bits = 8,
- .max_register = BCM590XX_MAX_REGISTER,
+ .max_register = BCM590XX_MAX_REGISTER_PRI,
.cache_type = REGCACHE_RBTREE,
};
-static int bcm590xx_i2c_probe(struct i2c_client *i2c,
+static const struct regmap_config bcm590xx_regmap_config_sec = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .max_register = BCM590XX_MAX_REGISTER_SEC,
+ .cache_type = REGCACHE_RBTREE,
+};
+
+static int bcm590xx_i2c_probe(struct i2c_client *i2c_pri,
const struct i2c_device_id *id)
{
struct bcm590xx *bcm590xx;
int ret;
- bcm590xx = devm_kzalloc(>dev, sizeof(*bcm590xx), GFP_KERNEL);
+ bcm590xx = devm_kzalloc(_pri->dev, sizeof(*bcm590xx), GFP_KERNEL);
if (!bcm590xx)
return -ENOMEM;
- i2c_set_clientdata(i2c, bcm590xx);
- bcm590xx->dev = >dev;
- bcm590xx->i2c_client = i2c;
+ i2c_set_clientdata(i2c_pri, bcm590xx);
+ bcm590xx->dev = _pri->dev;
+ bcm590xx->i2c_pri = i2c_pri;
- bcm590xx->regmap = devm_regmap_init_i2c(i2c, _regmap_config);
- if (IS_ERR(bcm590xx->regmap)) {
- ret = PTR_ERR(bcm590xx->regmap);
- dev_err(>dev, "regmap initialization failed: %d\n", ret);
+ bcm590xx->regmap_pri = devm_regmap_init_i2c(i2c_pri,
+_regmap_config_pri);
+ if (IS_ERR(bcm590xx->regmap_pri)) {
+ ret = PTR_ERR(bcm590xx->regmap_pri);
+ dev_err(_pri->dev, "primary regmap init failed: %d\n", ret);
return ret;
}
- ret = mfd_add_devices(>dev, -1, bcm590xx_devs,
+ /* Secondary I2C slave address is the base address with A(2) asserted */
+ bcm590xx->i2c_sec = i2c_new_dummy(i2c_pri->adapter,
+ i2c_pri->addr | BIT(2));
+ if (IS_ERR_OR_NULL(bcm590xx->i2c_sec)) {
+ dev_err(_pri->dev, "failed to add secondary I2C device\n");
+ return -ENODEV;
+ }
+ i2c_set_clientdata(bcm590xx->i2c_sec, bcm590xx);
+
+ bcm590xx->regmap_sec = devm_regmap_init_i2c(bcm590xx->i2c_sec,
+ _regmap_config_sec);
+ if (IS_ERR(bcm590xx->regmap_sec)) {
+ ret = PTR_ERR(bcm590xx->regmap_sec);
+ dev_err(>i2c_sec->dev,
+ "secondary regmap init failed: %d\n", ret);
+ goto err;
+ }
+
+ ret = mfd_add_devices(_pri->dev, -1, bcm590xx_devs,
ARRAY_SIZE(bcm590xx_devs), NULL, 0, NULL);
- if (ret < 0)
- dev_err(>dev, "failed to add sub-devices: %d\n", ret);
+ if (ret < 0) {
+ dev_err(_pri->dev, "failed to add sub-devices: %d\n", ret);
+ goto err;
+ }
+
+ return 0;
+err:
+ i2c_unregister_device(bcm590xx->i2c_sec);
return ret;
}
diff --git a/include/linux/mfd/bcm590xx.h b/include/linux/mfd/bcm590xx.h
index 434df2d..267aede 100644
--- a/include/linux/mfd/bcm590xx.h
+++ b/include/linux/mfd/bcm590xx.h
@@ -19,12 +19,15 @@
#include
/* max register address */
-#define BCM590XX_MAX_REGISTER 0xe7
+#define BCM590XX_MAX_REGISTER_PRI 0xe7
+#define BCM590XX_MAX_REGISTER_SEC 0xf0
struct bcm590xx {
struct device *dev;
- struct i2c_client *i2c_client;
- struct regmap *regmap;
+ struct i2c_client *i2c_pri;
+ struct i2c_client *i2c_sec;
+ struct regmap *regmap_pri;
+ struct regmap *regmap_sec;
unsigned int id;
};
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/4] regulator: bcm590xx: add support for regulators on secondary I2C slave
The bcm590xx MFD driver now exposes a secondary regmap descriptor
making the registers for regulators on the secondary I2C slave address
available. Add support for GPLDO1-6 and VBUS regulators found within
this register range.
Signed-off-by: Matt Porter
Acked-by: Mark Brown
---
drivers/regulator/bcm590xx-regulator.c | 92 ++
1 file changed, 82 insertions(+), 10 deletions(-)
diff --git a/drivers/regulator/bcm590xx-regulator.c
b/drivers/regulator/bcm590xx-regulator.c
index c3750c5..57544e2 100644
--- a/drivers/regulator/bcm590xx-regulator.c
+++ b/drivers/regulator/bcm590xx-regulator.c
@@ -22,7 +22,7 @@
#include
#include
-/* Register defs */
+/* I2C slave 0 registers */
#define BCM590XX_RFLDOPMCTRL1 0x60
#define BCM590XX_IOSR1PMCTRL1 0x7a
#define BCM590XX_IOSR2PMCTRL1 0x7c
@@ -31,13 +31,34 @@
#define BCM590XX_SDSR2PMCTRL1 0x86
#define BCM590XX_MSRPMCTRL10x8a
#define BCM590XX_VSRPMCTRL10x8e
-#define BCM590XX_REG_ENABLEBIT(7)
-
#define BCM590XX_RFLDOCTRL 0x96
#define BCM590XX_CSRVOUT1 0xc0
+
+/* I2C slave 1 registers */
+#define BCM590XX_GPLDO5PMCTRL1 0x16
+#define BCM590XX_GPLDO6PMCTRL1 0x18
+#define BCM590XX_GPLDO1CTRL0x1a
+#define BCM590XX_GPLDO2CTRL0x1b
+#define BCM590XX_GPLDO3CTRL0x1c
+#define BCM590XX_GPLDO4CTRL0x1d
+#define BCM590XX_GPLDO5CTRL0x1e
+#define BCM590XX_GPLDO6CTRL0x1f
+#define BCM590XX_OTG_CTRL 0x40
+#define BCM590XX_GPLDO1PMCTRL1 0x57
+#define BCM590XX_GPLDO2PMCTRL1 0x59
+#define BCM590XX_GPLDO3PMCTRL1 0x5b
+#define BCM590XX_GPLDO4PMCTRL1 0x5d
+
+#define BCM590XX_REG_ENABLEBIT(7)
+#define BCM590XX_VBUS_ENABLE BIT(2)
#define BCM590XX_LDO_VSEL_MASK GENMASK(5, 3)
#define BCM590XX_SR_VSEL_MASK GENMASK(5, 0)
+/*
+ * RFLDO to VSR regulators are
+ * accessed via I2C slave 0
+ */
+
/* LDO regulator IDs */
#define BCM590XX_REG_RFLDO 0
#define BCM590XX_REG_CAMLDO1 1
@@ -62,9 +83,25 @@
#define BCM590XX_REG_SDSR2 18
#define BCM590XX_REG_VSR 19
-#define BCM590XX_NUM_REGS 20
+/*
+ * GPLDO1 to VBUS regulators are
+ * accessed via I2C slave 1
+ */
+
+#define BCM590XX_REG_GPLDO120
+#define BCM590XX_REG_GPLDO221
+#define BCM590XX_REG_GPLDO322
+#define BCM590XX_REG_GPLDO423
+#define BCM590XX_REG_GPLDO524
+#define BCM590XX_REG_GPLDO625
+#define BCM590XX_REG_VBUS 26
+
+#define BCM590XX_NUM_REGS 27
#define BCM590XX_REG_IS_LDO(n) (n < BCM590XX_REG_CSR)
+#define BCM590XX_REG_IS_GPLDO(n) \
+ ((n > BCM590XX_REG_VSR) && (n < BCM590XX_REG_VBUS))
+#define BCM590XX_REG_IS_VBUS(n)(n == BCM590XX_REG_VBUS)
struct bcm590xx_board {
struct regulator_init_data *bcm590xx_pmu_init_data[BCM590XX_NUM_REGS];
@@ -149,6 +186,12 @@ static struct bcm590xx_info bcm590xx_regs[] = {
BCM590XX_REG_RANGES(sdsr1, dcdc_sdsr1_ranges),
BCM590XX_REG_RANGES(sdsr2, dcdc_iosr1_ranges),
BCM590XX_REG_RANGES(vsr, dcdc_iosr1_ranges),
+ BCM590XX_REG_TABLE(gpldo1, ldo_a_table),
+ BCM590XX_REG_TABLE(gpldo2, ldo_a_table),
+ BCM590XX_REG_TABLE(gpldo3, ldo_a_table),
+ BCM590XX_REG_TABLE(gpldo4, ldo_a_table),
+ BCM590XX_REG_TABLE(gpldo5, ldo_a_table),
+ BCM590XX_REG_TABLE(gpldo6, ldo_a_table),
};
struct bcm590xx_reg {
@@ -161,6 +204,8 @@ static int bcm590xx_get_vsel_register(int id)
{
if (BCM590XX_REG_IS_LDO(id))
return BCM590XX_RFLDOCTRL + id;
+ else if (BCM590XX_REG_IS_GPLDO(id))
+ return BCM590XX_GPLDO1CTRL + id;
else
return BCM590XX_CSRVOUT1 + (id - BCM590XX_REG_CSR) * 3;
}
@@ -171,6 +216,8 @@ static int bcm590xx_get_enable_register(int id)
if (BCM590XX_REG_IS_LDO(id))
reg = BCM590XX_RFLDOPMCTRL1 + id * 2;
+ else if (BCM590XX_REG_IS_GPLDO(id))
+ reg = BCM590XX_GPLDO1PMCTRL1 + id * 2;
else
switch (id) {
case BCM590XX_REG_CSR:
@@ -191,8 +238,11 @@ static int bcm590xx_get_enable_register(int id)
case BCM590XX_REG_SDSR2:
reg = BCM590XX_SDSR2PMCTRL1;
break;
+ case BCM590XX_REG_VBUS:
+ reg = BCM590XX_OTG_CTRL;
};
+
return reg;
}
@@ -216,6 +266,12 @@ static struct regulator_ops bcm590xx_ops_dcdc = {
.map_voltage= regulator_map_voltage_linear_range,
};
+static struct regulator_ops bcm590xx_ops_vbus = {
+ .is_enabled = regulator_is_enabled_regmap,
+ .enable = regulator_enable_regmap,
+ .disable= regulator_disable_regmap,
+};
+
#define BCM590XX_MATCH(_name, _id) \
{ \
.name = #_name, \
@@ -243,6 +299,13 @@ static struct of_regulator_match bcm590xx_matches[] = {
BCM590XX_MATCH(sdsr1, SDSR1),
BCM590XX_MATCH(sdsr2, SDSR2),
BCM590XX_MATCH(vsr, VSR),
+ BCM590XX_MAT
[PATCH v2 4/4] ARM: dts: bcm590xx: add support for GPLDO and VBUS regulators
Adds additional nodes to support GPLDO1-6 and VBUS regulators which
are now supported in the bcm590xx regulator driver.
Signed-off-by: Matt Porter
---
arch/arm/boot/dts/bcm59056.dtsi | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/bcm59056.dtsi b/arch/arm/boot/dts/bcm59056.dtsi
index dfadaaa..066adfb 100644
--- a/arch/arm/boot/dts/bcm59056.dtsi
+++ b/arch/arm/boot/dts/bcm59056.dtsi
@@ -70,5 +70,26 @@
vsr_reg: vsr {
};
+
+ gpldo1_reg: gpldo1 {
+ };
+
+ gpldo2_reg: gpldo2 {
+ };
+
+ gpldo3_reg: gpldo3 {
+ };
+
+ gpldo4_reg: gpldo4 {
+ };
+
+ gpldo5_reg: gpldo5 {
+ };
+
+ gpldo6_reg: gpldo6 {
+ };
+
+ vbus_reg: vbus {
+ };
};
};
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] mfd: bcm590xx: add support for second i2c slave address space
On Wed, Apr 23, 2014 at 06:01:26PM -0400, Matt Porter wrote:
> On Tue, Apr 22, 2014 at 09:21:39AM +0100, Lee Jones wrote:
> > > > > > s/regmap/Regmap
> > > > >
> > > > > It's consistently written regmap in all the documentation and so on :)
> > > >
> > > > Furry muff; but the comments still stand for the acronyms.
> > > >
> > > > > > addmap{0,1} doesn't quite sit right with me.
> > > > >
> > > > > > REVISIT: Ah, it's address-map, rather than add map. Okay, not as bad
> > > > > > as I first thought, but still, is there a better naming convention
> > > > > > you
> > > > > > could use?
> > > > >
> > > > > addrmap or something?
> > > >
> > > > Right, that was what I was thinking. However, I prefer something along
> > > > the lines of 'i2c' and 'i2c_sec' or 'client' and 'client_slv' etc.
> > >
> > > FWIW, the reason it's addmap{0,1} is that the datasheet has documents
> > > ADDMAP=0 and the first bank of registers and ADDMAP=1 as the second bank
> > > of registers. I adopted that to match the docs for the part.
> > >
> > > I guess we could do i2c and i2c_sec, I'll just have to put a comment
> > > correlating it to the h/w. Calling it 'slv' implies something else
> > > so we should avoid that here. The notion of a "secondary" i2c device
> > > is completely a Linux I2C subsystem fabrication which wouldn't exist
> > > if it allowed multiple slave addresses per device. From a h/w
> > > perspective there is really no primary and secondary relationship.
> > >
> > > I'm fine with i2c/i2c_sec or addrmap0/1 and I will just comment to
> > > correlate with the datasheet..pick one.
> >
> > Let's stick method fabricated by the I2C subsystem. It may seem strange
> > from a h/w perspective, but it is the way we (you) have coded it, as
> > the first parameter of i2c_new_dummy() is the 'managing' (primary,
> > parent, master, whatever) device, so '_sec' would suit as an
> > identifying appendage for the resultant device.
>
> That works, I'll also switch to addrmap_[pri|sec] which touches the
> regulator driver as well. That will keep the relationship between device
> and regmap clear.
Misspoke...I'm switching regmap[0|1] to regmap_[pri|sec] to keep that
synced with i2c_[pri|sec]
-Matt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] mfd: bcm590xx: add support for second i2c slave address space
On Tue, Apr 22, 2014 at 09:21:39AM +0100, Lee Jones wrote:
> > > > > s/regmap/Regmap
> > > >
> > > > It's consistently written regmap in all the documentation and so on :)
> > >
> > > Furry muff; but the comments still stand for the acronyms.
> > >
> > > > > addmap{0,1} doesn't quite sit right with me.
> > > >
> > > > > REVISIT: Ah, it's address-map, rather than add map. Okay, not as bad
> > > > > as I first thought, but still, is there a better naming convention you
> > > > > could use?
> > > >
> > > > addrmap or something?
> > >
> > > Right, that was what I was thinking. However, I prefer something along
> > > the lines of 'i2c' and 'i2c_sec' or 'client' and 'client_slv' etc.
> >
> > FWIW, the reason it's addmap{0,1} is that the datasheet has documents
> > ADDMAP=0 and the first bank of registers and ADDMAP=1 as the second bank
> > of registers. I adopted that to match the docs for the part.
> >
> > I guess we could do i2c and i2c_sec, I'll just have to put a comment
> > correlating it to the h/w. Calling it 'slv' implies something else
> > so we should avoid that here. The notion of a "secondary" i2c device
> > is completely a Linux I2C subsystem fabrication which wouldn't exist
> > if it allowed multiple slave addresses per device. From a h/w
> > perspective there is really no primary and secondary relationship.
> >
> > I'm fine with i2c/i2c_sec or addrmap0/1 and I will just comment to
> > correlate with the datasheet..pick one.
>
> Let's stick method fabricated by the I2C subsystem. It may seem strange
> from a h/w perspective, but it is the way we (you) have coded it, as
> the first parameter of i2c_new_dummy() is the 'managing' (primary,
> parent, master, whatever) device, so '_sec' would suit as an
> identifying appendage for the resultant device.
That works, I'll also switch to addrmap_[pri|sec] which touches the
regulator driver as well. That will keep the relationship between device
and regmap clear.
-Matt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] mfd: bcm590xx: add support for second i2c slave address space
On Tue, Apr 22, 2014 at 09:21:39AM +0100, Lee Jones wrote:
s/regmap/Regmap
It's consistently written regmap in all the documentation and so on :)
Furry muff; but the comments still stand for the acronyms.
addmap{0,1} doesn't quite sit right with me.
REVISIT: Ah, it's address-map, rather than add map. Okay, not as bad
as I first thought, but still, is there a better naming convention you
could use?
addrmap or something?
Right, that was what I was thinking. However, I prefer something along
the lines of 'i2c' and 'i2c_sec' or 'client' and 'client_slv' etc.
FWIW, the reason it's addmap{0,1} is that the datasheet has documents
ADDMAP=0 and the first bank of registers and ADDMAP=1 as the second bank
of registers. I adopted that to match the docs for the part.
I guess we could do i2c and i2c_sec, I'll just have to put a comment
correlating it to the h/w. Calling it 'slv' implies something else
so we should avoid that here. The notion of a secondary i2c device
is completely a Linux I2C subsystem fabrication which wouldn't exist
if it allowed multiple slave addresses per device. From a h/w
perspective there is really no primary and secondary relationship.
I'm fine with i2c/i2c_sec or addrmap0/1 and I will just comment to
correlate with the datasheet..pick one.
Let's stick method fabricated by the I2C subsystem. It may seem strange
from a h/w perspective, but it is the way we (you) have coded it, as
the first parameter of i2c_new_dummy() is the 'managing' (primary,
parent, master, whatever) device, so '_sec' would suit as an
identifying appendage for the resultant device.
That works, I'll also switch to addrmap_[pri|sec] which touches the
regulator driver as well. That will keep the relationship between device
and regmap clear.
-Matt
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] mfd: bcm590xx: add support for second i2c slave address space
On Wed, Apr 23, 2014 at 06:01:26PM -0400, Matt Porter wrote:
On Tue, Apr 22, 2014 at 09:21:39AM +0100, Lee Jones wrote:
s/regmap/Regmap
It's consistently written regmap in all the documentation and so on :)
Furry muff; but the comments still stand for the acronyms.
addmap{0,1} doesn't quite sit right with me.
REVISIT: Ah, it's address-map, rather than add map. Okay, not as bad
as I first thought, but still, is there a better naming convention
you
could use?
addrmap or something?
Right, that was what I was thinking. However, I prefer something along
the lines of 'i2c' and 'i2c_sec' or 'client' and 'client_slv' etc.
FWIW, the reason it's addmap{0,1} is that the datasheet has documents
ADDMAP=0 and the first bank of registers and ADDMAP=1 as the second bank
of registers. I adopted that to match the docs for the part.
I guess we could do i2c and i2c_sec, I'll just have to put a comment
correlating it to the h/w. Calling it 'slv' implies something else
so we should avoid that here. The notion of a secondary i2c device
is completely a Linux I2C subsystem fabrication which wouldn't exist
if it allowed multiple slave addresses per device. From a h/w
perspective there is really no primary and secondary relationship.
I'm fine with i2c/i2c_sec or addrmap0/1 and I will just comment to
correlate with the datasheet..pick one.
Let's stick method fabricated by the I2C subsystem. It may seem strange
from a h/w perspective, but it is the way we (you) have coded it, as
the first parameter of i2c_new_dummy() is the 'managing' (primary,
parent, master, whatever) device, so '_sec' would suit as an
identifying appendage for the resultant device.
That works, I'll also switch to addrmap_[pri|sec] which touches the
regulator driver as well. That will keep the relationship between device
and regmap clear.
Misspoke...I'm switching regmap[0|1] to regmap_[pri|sec] to keep that
synced with i2c_[pri|sec]
-Matt
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 4/4] ARM: dts: bcm590xx: add support for GPLDO and VBUS regulators
Adds additional nodes to support GPLDO1-6 and VBUS regulators which
are now supported in the bcm590xx regulator driver.
Signed-off-by: Matt Porter mpor...@linaro.org
---
arch/arm/boot/dts/bcm59056.dtsi | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/bcm59056.dtsi b/arch/arm/boot/dts/bcm59056.dtsi
index dfadaaa..066adfb 100644
--- a/arch/arm/boot/dts/bcm59056.dtsi
+++ b/arch/arm/boot/dts/bcm59056.dtsi
@@ -70,5 +70,26 @@
vsr_reg: vsr {
};
+
+ gpldo1_reg: gpldo1 {
+ };
+
+ gpldo2_reg: gpldo2 {
+ };
+
+ gpldo3_reg: gpldo3 {
+ };
+
+ gpldo4_reg: gpldo4 {
+ };
+
+ gpldo5_reg: gpldo5 {
+ };
+
+ gpldo6_reg: gpldo6 {
+ };
+
+ vbus_reg: vbus {
+ };
};
};
--
1.8.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
