Re: [PATCH 2/2] i2c: mv64xxx: Fix bus hang on A0 version of the Armada XP SoCs
On Thu, Jan 02, 2014 at 01:28:22PM -0500, Jason Cooper wrote:
> Wolfram,
>
> On Thu, Jan 02, 2014 at 05:01:16PM +0100, Gregory CLEMENT wrote:
> > The first variants of Armada XP SoCs (A0 stepping) have issues related
> > to the i2c controller which prevent to use the offload mechanism and
> > lead to a kernel hang during boot.
> >
> > The driver now check the revision of the SoC. If the revision is not
> > more recent than the A0 or if the driver can't get the SoC revision
> > then it disables the offload mechanism.
> >
> > Cc: sta...@vger.kernel.org
> > Signed-off-by: Gregory CLEMENT
> > ---
> > drivers/i2c/busses/i2c-mv64xxx.c | 11 ++-
> > 1 file changed, 10 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/i2c/busses/i2c-mv64xxx.c
> > b/drivers/i2c/busses/i2c-mv64xxx.c
> > index 8be7e42aa4de..089a3663ad86 100644
> > --- a/drivers/i2c/busses/i2c-mv64xxx.c
> > +++ b/drivers/i2c/busses/i2c-mv64xxx.c
> > @@ -24,6 +24,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #define MV64XXX_I2C_ADDR_ADDR(val) ((val & 0x7f) << 1)
> > #define MV64XXX_I2C_BAUD_DIV_N(val)(val & 0x7)
> > @@ -779,8 +780,16 @@ mv64xxx_of_config(struct mv64xxx_i2c_data *drv_data,
> > * Transaction Generator support and the errata fix.
> > */
> > if (of_device_is_compatible(np, "marvell,mv78230-i2c")) {
> > - drv_data->offload_enabled = true;
> > + u32 dev, rev;
> > +
> > drv_data->errata_delay = true;
> > + /*
> > +* Only revison more recent than A0 support offload
> > +* mechanism. In case we can't get the SoC revision
> > +* weplay safe and we don't enable it
> > +*/
> > + if (!mvebu_get_soc_id(&rev, &dev) && (dev > MV78XX0_A0_REV))
Very minor nits:
I'd prefer (mvebu_get_soc_id == 0) here, since !mvebu_get_soc_id can
easily be read as "if not get soc id" which leads to the assumption the
function failed. And the parantheses around the second comparison are
superfluous.
> > + drv_data->offload_enabled = true;
>
> Since this depends on arch-specific code in the previous patch, I'd like
> to keep the two of them together in a topic branch. Would you prefer to
> take both with my Ack, or vice-versa? I'm fine either way.
I'd think you better take it:
Acked-by: Wolfram Sang
signature.asc
Description: Digital signature
Re: [PATCH 2/2] i2c: mv64xxx: Fix bus hang on A0 version of the Armada XP SoCs
Wolfram,
On Thu, Jan 02, 2014 at 05:01:16PM +0100, Gregory CLEMENT wrote:
> The first variants of Armada XP SoCs (A0 stepping) have issues related
> to the i2c controller which prevent to use the offload mechanism and
> lead to a kernel hang during boot.
>
> The driver now check the revision of the SoC. If the revision is not
> more recent than the A0 or if the driver can't get the SoC revision
> then it disables the offload mechanism.
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Gregory CLEMENT
> ---
> drivers/i2c/busses/i2c-mv64xxx.c | 11 ++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/busses/i2c-mv64xxx.c
> b/drivers/i2c/busses/i2c-mv64xxx.c
> index 8be7e42aa4de..089a3663ad86 100644
> --- a/drivers/i2c/busses/i2c-mv64xxx.c
> +++ b/drivers/i2c/busses/i2c-mv64xxx.c
> @@ -24,6 +24,7 @@
> #include
> #include
> #include
> +#include
>
> #define MV64XXX_I2C_ADDR_ADDR(val) ((val & 0x7f) << 1)
> #define MV64XXX_I2C_BAUD_DIV_N(val) (val & 0x7)
> @@ -779,8 +780,16 @@ mv64xxx_of_config(struct mv64xxx_i2c_data *drv_data,
>* Transaction Generator support and the errata fix.
>*/
> if (of_device_is_compatible(np, "marvell,mv78230-i2c")) {
> - drv_data->offload_enabled = true;
> + u32 dev, rev;
> +
> drv_data->errata_delay = true;
> + /*
> + * Only revison more recent than A0 support offload
> + * mechanism. In case we can't get the SoC revision
> + * weplay safe and we don't enable it
> + */
> + if (!mvebu_get_soc_id(&rev, &dev) && (dev > MV78XX0_A0_REV))
> + drv_data->offload_enabled = true;
Since this depends on arch-specific code in the previous patch, I'd like
to keep the two of them together in a topic branch. Would you prefer to
take both with my Ack, or vice-versa? I'm fine either way.
thx,
Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Openblocks AX3-4 i2c bus lockup
Hi Andrew, On 31/12/2013 23:21, Andrew Lunn wrote: >>> We can have this information in the same way that it is currently done >>> by the other mvebu SoC: accessing the PCIE_DEV_REV_OFF register. In >>> arch/arm/plat-orion/pcie.c there were functions named >>> orion_pcie_dev_id() and orion_pcie_dev_id() to retrieve information >>> about the CPU variant and its version. >> >> Depending on running pcie when calling is tricky, as it can be clock >> gated. Maybe we should have some mach code to get the SoC revision >> early for all SoCs. That should look for a pcie controller node, >> enable the clock, store the revision once, and disable the clock >> again. The callback can then return the stored value. > > I think this is something we need, not just for this i2c problem, but > for other issues, in particular, helping userspace get the right DT > file. > > We already have kirkwood-ts219-6281.dts and kirkwood-ts219-6282.dts, > different QNAP 21X variants which differ by SoC. I will soon be adding > kirkwood-ts419-6281.dts and kirkwood-ts419-6282.dts, once testing is > complete. > > It would be nice if the Debian installer can figure out which variant > is needed. I don't think we currently reliably export this information > to user space. We do print it at boot time, but there is no guarantee > it will still be there later. lspci does not seem to show it, and that I also think it could be useful to have a way to know the SoC ID and its revision. But I don't know where to export it, in /proc/cpuinfo there is a filed named Revision but I think it refers the board itself. There is also the /sys/bus/platform/devices/soc.0/ directory which would be a good candidate to export the SoC ID and revision. > assumes PCIe devices are actually enabled in the DT, which for > ts219-6181 they are not. > > At the moment, PCI_MVEBU is a bool in Kconfig. It is either built in, > or not available. That helps a little, but not too much. It could be > the i2c driver gets probed before PCI. Also, for Dove, PCI is > optional, since things like CuBox does not have any use of PCI. > > So maybe some mach code would be best, which directly peeks the PCIe > registers, and twiddles the clocks as needed. We can hard code the > addresses, and use dt_compat to determine which set of addresses to > use, and do it from init_machine, so we don't need to worry about what > the PCIe and clock drivers are doing. I have just written something like that: http://www.spinics.net/lists/arm-kernel/msg297642.html Gregory -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 3/3] i2c: mv64xxx: Document the newly introduced Armada XP A0 compatible
On 01/01/2014 22:45, Jason Cooper wrote: > [+ DT ml, Grant, Rob] > > On Tue, Dec 31, 2013 at 05:44:53PM +0100, Gregory CLEMENT wrote: >> Signed-off-by: Gregory CLEMENT >> --- >> Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt >> b/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt >> index 82e8f6f17179..9410ed72ec45 100644 >> --- a/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt >> +++ b/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt >> @@ -5,7 +5,7 @@ Required properties : >> >> - reg : Offset and length of the register set for the device >> - compatible : Should be "marvell,mv64xxx-i2c" or >> "allwinner,sun4i-i2c" >> - or "marvell,mv78230-i2c" >> + or "marvell,mv78230-i2c" or "marvell,mv78230-a0-i2c" > > Once we nail down how we want to do this, Please add an explanation of > the differences between the compatibles. eg 'offloading broken'. > Just to keep the DT mailing list, Grant and Rob in touch: I have submitted an other series in which we don't have to use the device tree to know the SoC revision. So if everything turns well we won't have to apply this series. If at the end we still need it, then I will add the explanation in the next version. Gregory -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/3] Fix i2c bus hang on A0 version of the Armada XP SoCs
Hi Andrew, On 01/01/2014 20:28, Andrew Lunn wrote: > On Tue, Dec 31, 2013 at 05:44:50PM +0100, Gregory CLEMENT wrote: >> Hi, >> >> This series is an RFC to fix the i2c bus hang on A0 version of the >> Armada XP SoCs. It occured on the the eraly release of the OpenBlocks >> AX3-4 bords. Indeed the first variants of Armada XP SoCs (A0 stepping) >> have issues related to the i2c controller which prevent to use the >> offload mechanism and lead to a kernel hang during boot. >> >> The best solution will be to detect the SoCs version at runtime and >> use it in the driver, but I chosed to submit this version in case CPU >> version detection feature takes more time than expected (and we >> already reached the rc6 kernel). >> >> Thanks, >> >> Gregory > > Hi Gregory > > Thanks for these RFC patches. I can confirm they work on my Openblocks > device with an A0 stepping SoC. I can now access the RTC. > > You missed adding the new DTS file to the Makefile. Depending on how > the discussion goes about auto detecting stepping or not, i would of > used different filenames, probably: Thanks for your feedback. In case there will be a second version I will take them into account. However I hope we won't need it as I sent a new series to fix this bug by dynamically getting the SoC revision. > > armada-xp-openblocks-ax3-4.dts > armada-xp-openblocks-ax3-4-a0.dts > armada-xp-openblocks-ax3-4-common.dts you probably meant armada-xp-openblocks-ax3-4-common.dtsi, but I got the point and I agree. > > Keeps all the files together when listed alphabetically > -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/3] arm: mvebu: add new dts file for old variant of Openblocks AX3-4
Hi Jason,
I have just send a new series which I hope will supersede this one.
However I will answer on some points:
On 01/01/2014 22:41, Jason Cooper wrote:
> Gregory,
>
> Sorry, but we seem to have a fundamental mis-understanding here. First,
> whatever we end up deciding for the compatible strings needs to be
> documented. Which seems to have not made it into this series.
>
> Second, I'm having trouble explaining this (in my head), so I'm adding
> the DT ml so hopefully someone there can chime in.
>
> AFAICT, the marvell,mv78230-i2c compatible string, added in v3.12, refers
> to the IP block on the A0 revision of the SoC. Since we have set that,
Actually in v3.12 the marvell,mv78230-i2c refer to the B0 revision as I
only worked on it on board using this revision. That's why I proposed
to introduced the marvell,mv78230-a0-i2c compatible string. My concerns was
to not break the existing behavior.
Currently with the marvell,mv78230-i2c compatible string the kernel use
offload on B0 version and hang on A0 version.
If we introduce the marvell,mv78230-a0-i2c compatible string, then the new
kernel with the same dtb will have the same behavior. People using the A0
version are aware that there is a problem (the kernel hang) so they will
be willing to switch to marvell,mv78230-a0-i2c and to change their dtb.
If we introduce the marvell,mv78230-b0-i2c compatible string, then the new
kernel with the same dtb will have different behavior. People using the A0
will have a booting kernel, but I fear that people using B0 revision won't
be aware of the regression.
Gregory
> we've discovered that the A0 revision has an errata where offloading
> doesn't work. The B0 revision of the SoC has fixed offloading for i2c.
>
> In my mind, this means that we should create a fix for the driver to
> disable offloading unless it can determine it's running B0 or newer.
> This is easy once we nail down the compatible strings.
>
> The second thing we need to do is update the binding documentation so
> that the devicetree can describe the hardware accurately. I think we
> should keep 'marvell,mv78230-i2c' as it is (the driver fix mentioned
> above will disable offloading), and add a new compatible
> string, 'marvell,mv78230-b0-i2c'. The driver can then be updated to
> enable offloading when it sees this compatible string, or it can
> determine the SoC revision itself (via mach code).
>
> Third, we need to be able to differentiate between the two shipped
> AX3-4 boards by openblocks. I think this should follow the same pattern
> we decide for the i2c compatible string. So, if we go with my proposal,
> we would have plathome,openblocks-ax3-4 and
> plathome,openblocks-ax3-4-b0.
>
> Basically, I'm really uneasy about dropping marvell,mv78230-i2c and
> essentially re-defining it to marvell,mv78230-a0-i2c. It feels like
> it's breaking backwards compatibility. But I'm having trouble clearly
> describing how Gregory's proposed change exactly does break backwards
> compatibility. Can a DT maintainer explain it more clearly than I?
>
> thx,
>
> Jason.
>
> PS- Well, this ended up being a toppost. Oops. Sorry.
>
> On Tue, Dec 31, 2013 at 05:44:51PM +0100, Gregory CLEMENT wrote:
>> The first variants of Openblocks AX3-4 used the revision A0 of the
>> Armada XP SoCs. These early variants have issues related to the i2c
>> controller which prevent to use the offload mechanism and lead to a
>> kernel hang during boot.
>>
>> The new dts file uses the compatible string marvell,mv78230-a0-i2c for
>> the i2c controller, thanks to this the driver disable the offload
>> mechanism and the kernel no more hangs on these boards.
>>
>> Signed-off-by: Gregory CLEMENT
>> ---
>> .../arm/boot/dts/armada-xp-a0-openblocks-ax3-4.dts | 40 +
>> .../dts/armada-xp-common-openblocks-ax3-4.dtsi | 177
>> +
>> arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 164 +--
>> 3 files changed, 218 insertions(+), 163 deletions(-)
>> create mode 100644 arch/arm/boot/dts/armada-xp-a0-openblocks-ax3-4.dts
>> create mode 100644 arch/arm/boot/dts/armada-xp-common-openblocks-ax3-4.dtsi
>>
>> diff --git a/arch/arm/boot/dts/armada-xp-a0-openblocks-ax3-4.dts
>> b/arch/arm/boot/dts/armada-xp-a0-openblocks-ax3-4.dts
>> new file mode 100644
>> index ..b3ea65255c19
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/armada-xp-a0-openblocks-ax3-4.dts
>> @@ -0,0 +1,40 @@
>> +/*
>> + * Device Tree file for OpenBlocks AX3-4 board with A0 SoC
>> + *
>> + * Copyright (C) 2012 Marvell
>> + *
>> + * Gregory CLEMENT
>> + *
>> + * This file is licensed under the terms of the GNU General Public
>> + * License version 2. This program is licensed "as is" without any
>> + * warranty of any kind, whether express or implied.
>> + */
>> +
>> +/dts-v1/;
>> +#include "armada-xp-common-openblocks-ax3-4.dtsi"
>> +
>> +/ {
>> +model = "PlatHome OpenBlocks AX3-4 board (A0 SoC)";
>> +compatible = "plathome,openblocks-ax3-4
[PATCH 2/2] i2c: mv64xxx: Fix bus hang on A0 version of the Armada XP SoCs
The first variants of Armada XP SoCs (A0 stepping) have issues related
to the i2c controller which prevent to use the offload mechanism and
lead to a kernel hang during boot.
The driver now check the revision of the SoC. If the revision is not
more recent than the A0 or if the driver can't get the SoC revision
then it disables the offload mechanism.
Cc: sta...@vger.kernel.org
Signed-off-by: Gregory CLEMENT
---
drivers/i2c/busses/i2c-mv64xxx.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-mv64xxx.c b/drivers/i2c/busses/i2c-mv64xxx.c
index 8be7e42aa4de..089a3663ad86 100644
--- a/drivers/i2c/busses/i2c-mv64xxx.c
+++ b/drivers/i2c/busses/i2c-mv64xxx.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#define MV64XXX_I2C_ADDR_ADDR(val) ((val & 0x7f) << 1)
#define MV64XXX_I2C_BAUD_DIV_N(val)(val & 0x7)
@@ -779,8 +780,16 @@ mv64xxx_of_config(struct mv64xxx_i2c_data *drv_data,
* Transaction Generator support and the errata fix.
*/
if (of_device_is_compatible(np, "marvell,mv78230-i2c")) {
- drv_data->offload_enabled = true;
+ u32 dev, rev;
+
drv_data->errata_delay = true;
+ /*
+* Only revison more recent than A0 support offload
+* mechanism. In case we can't get the SoC revision
+* weplay safe and we don't enable it
+*/
+ if (!mvebu_get_soc_id(&rev, &dev) && (dev > MV78XX0_A0_REV))
+ drv_data->offload_enabled = true;
}
out:
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] Fix i2c bus hang on A0 version of the Armada XP SoCs
Hi, This series is a better approach to fix the i2c bus hang on A0 version of the Armada XP SoCs. It occurred on the early release of the OpenBlocks AX3-4 boards. Indeed the first variants of Armada XP SoCs (A0 stepping) have issues related to the i2c controller which prevent to use the offload mechanism and lead to a kernel hang during boot. The first patch add a mean to detect the SoCs version at run-time and the second one use this feature in the driver. These 2 patches should be applied on 3.13-rc and on stable kernel 3.12 as it fixes a regression introduce by the commit 930ab3d403ae "i2c: mv64xxx: Add I2C Transaction Generator support". The first patch could be latter be extend to also be used with dove, kirkwood, orion5x and mv78x00 when there will be merged in mvebu. Thanks, Gregory CLEMENT (2): ARM: mvebu: Add support to get the ID and the revision of a SoC i2c: mv64xxx: Fix bus hang on A0 version of the Armada XP SoCs arch/arm/mach-mvebu/Makefile | 2 +- arch/arm/mach-mvebu/mvebu-soc-id.c | 111 + drivers/i2c/busses/i2c-mv64xxx.c | 11 +++- include/linux/mvebu-soc-id.h | 32 +++ 4 files changed, 154 insertions(+), 2 deletions(-) create mode 100644 arch/arm/mach-mvebu/mvebu-soc-id.c create mode 100644 include/linux/mvebu-soc-id.h -- 1.8.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: mvebu: Add support to get the ID and the revision of a SoC
All the mvebu SoCs have information related to their variant and
revision that can be read from the PCI control register.
This patch adds support for Armada XP and Armada 370. This reading of
the revision and the ID are done before the PCI initialization to
avoid any conflicts. Once these data are retrieved, the resources are
freed to let the PCI subsystem use it.
Cc: sta...@vger.kernel.org
Signed-off-by: Gregory CLEMENT
---
arch/arm/mach-mvebu/Makefile | 2 +-
arch/arm/mach-mvebu/mvebu-soc-id.c | 111 +
include/linux/mvebu-soc-id.h | 32 +++
3 files changed, 144 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/mach-mvebu/mvebu-soc-id.c
create mode 100644 include/linux/mvebu-soc-id.h
diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile
index 2d04f0e21870..878aebe98dcc 100644
--- a/arch/arm/mach-mvebu/Makefile
+++ b/arch/arm/mach-mvebu/Makefile
@@ -3,7 +3,7 @@ ccflags-$(CONFIG_ARCH_MULTIPLATFORM) :=
-I$(srctree)/$(src)/include \
AFLAGS_coherency_ll.o := -Wa,-march=armv7-a
-obj-y += system-controller.o
+obj-y += system-controller.o mvebu-soc-id.o
obj-$(CONFIG_MACH_ARMADA_370_XP) += armada-370-xp.o
obj-$(CONFIG_ARCH_MVEBU)+= coherency.o coherency_ll.o pmsu.o
obj-$(CONFIG_SMP)+= platsmp.o headsmp.o
diff --git a/arch/arm/mach-mvebu/mvebu-soc-id.c
b/arch/arm/mach-mvebu/mvebu-soc-id.c
new file mode 100644
index ..86c901be284c
--- /dev/null
+++ b/arch/arm/mach-mvebu/mvebu-soc-id.c
@@ -0,0 +1,111 @@
+/*
+ * Variant and revision information for mvebu SoCs
+ *
+ * Copyright (C) 2014 Marvell
+ *
+ * Gregory CLEMENT
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ *
+ * All the mvebu SoCs have information related to their variant and
+ * revision that can be read from the PCI control register. This is
+ * done before the PCI initialization to avoid any conflict. Once the
+ * ID and revision are retrieved, the mapping is freed.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define PCIE_DEV_ID_OFF0x0
+#define PCIE_DEV_REV_OFF 0x8
+
+#define SOC_ID_MASK0x
+#define SOC_REV_MASK 0xFF
+
+static u32 soc_dev_id;
+static u32 soc_rev;
+static bool is_id_valid;
+
+static const struct of_device_id mvebu_pcie_of_match_table[] = {
+ { .compatible = "marvell,armada-xp-pcie", },
+ { .compatible = "marvell,armada-370-pcie", },
+ {},
+};
+
+int mvebu_get_soc_id(u32 *dev, u32 *rev)
+{
+ if (is_id_valid) {
+ *dev = soc_dev_id;
+ *rev = soc_rev;
+ return 0;
+ } else
+ return -1;
+}
+
+EXPORT_SYMBOL(mvebu_get_soc_id);
+
+static int __init mvebu_soc_id_init(void)
+{
+ struct device_node *np;
+ int ret = 0;
+
+ np = of_find_matching_node(NULL, mvebu_pcie_of_match_table);
+ if (np) {
+ void __iomem *pci_base;
+ struct clk *clk;
+ /*
+* ID and revision are available from any port, so we
+* just pick the first one
+*/
+ struct device_node *child = of_get_next_child(np, NULL);
+
+ clk = of_clk_get_by_name(child, NULL);
+ if (IS_ERR(clk)) {
+ pr_err("%s: cannot get clock\n", __func__);
+ ret = -ENOMEM;
+ goto clk_err;
+ }
+
+ ret = clk_prepare_enable(clk);
+ if (ret) {
+ pr_err("%s: cannot enable clock\n", __func__);
+ goto clk_err;
+ }
+
+ pci_base = of_iomap(child, 0);
+ if (IS_ERR(pci_base)) {
+ pr_err("%s: cannot map registers\n", __func__);
+ ret = -ENOMEM;
+ goto res_ioremap;
+ }
+
+ /* SoC ID */
+ soc_dev_id = __raw_readl(pci_base + PCIE_DEV_ID_OFF) >> 16;
+
+ /* SoC revision */
+ soc_rev = __raw_readl(pci_base + PCIE_DEV_REV_OFF)
+ & SOC_REV_MASK;
+
+ is_id_valid = true;
+
+ iounmap(pci_base);
+
+res_ioremap:
+ clk_disable_unprepare(clk);
+
+clk_err:
+ of_node_put(child);
+ of_node_put(np);
+ }
+
+ return ret;
+}
+arch_initcall(mvebu_soc_id_init);
+
diff --git a/include/linux/mvebu-soc-id.h b/include/linux/mvebu-soc-id.h
new file mode 100644
index ..602ce1c50d1d
--- /dev/null
+++ b/include/linux/mvebu-soc-id.h
@@ -0,0 +1,32 @@
+/*
+ * Marvell EBU SoC ID and revision definitions.
+ *
+ * Copyright (C) 2014 Marvell Semiconductor
+ *
+ * Th
Re: [PATCH 01/15] i2c: shmobile/rcar: Restrict non-COMPILE_TEST compilation
Hi Wolfram, On Wednesday 11 December 2013 13:47:34 Laurent Pinchart wrote: > Hi Wolfram, > > Could you please pick this patch up for v3.14 ? Ping ? > On Thursday 28 November 2013 16:36:21 Simon Horman wrote: > > On Wed, Nov 27, 2013 at 02:18:23AM +0100, Laurent Pinchart wrote: > > > Hardware supported by the i2c sh_mobile and rcar drivers is only found > > > on SUPERH or ARCH_SHMOBILE platforms. Restrict non-COMPILE_TEST > > > compilation to them. > > > > > > Cc: Wolfram Sang > > > Cc: linux-i2c@vger.kernel.org > > > Signed-off-by: Laurent Pinchart > > > > > > > Acked-by: Simon Horman > > > > > --- > > > > > > drivers/i2c/busses/Kconfig | 4 ++-- > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig > > > index 3b26129..92bdcf9 100644 > > > --- a/drivers/i2c/busses/Kconfig > > > +++ b/drivers/i2c/busses/Kconfig > > > @@ -683,7 +683,7 @@ config I2C_SH7760 > > > > > > config I2C_SH_MOBILE > > > > > > tristate "SuperH Mobile I2C Controller" > > > > > > - depends on SUPERH || ARM || COMPILE_TEST > > > + depends on SUPERH || ARCH_SHMOBILE || COMPILE_TEST > > > > > > help > > > > > > If you say yes to this option, support will be included for the > > > built-in I2C interface on the Renesas SH-Mobile processor. > > > > > > @@ -796,7 +796,7 @@ config I2C_XLR > > > > > > config I2C_RCAR > > > > > > tristate "Renesas R-Car I2C Controller" > > > > > > - depends on ARM || COMPILE_TEST > > > + depends on ARCH_SHMOBILE || COMPILE_TEST > > > > > > help > > > > > > If you say yes to this option, support will be included for the > > > R-Car I2C controller. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3] i2c: riic: add driver
On Fri, Dec 20, 2013 at 07:08:50PM +0100, Wolfram Sang wrote: > From: Wolfram Sang > > Tested with a r7s72100 genmai board acessing an eeprom. > > Signed-off-by: Wolfram Sang Applied to for-next, thanks! signature.asc Description: Digital signature
