Re: [PATCH] i2c: mv64xxx: Fix locked bus when offload is selected but not used on a message
On Fri, Feb 07, 2014 at 11:55:54AM +0100, Gregory CLEMENT wrote: Offload can be used only on regular transactions and for 1 to byte transfers. In the other cases we switch back to usual work flow. In this case we need to call mv64xxx_i2c_prepare_for_io() as this function is not used when we try to use offloading. This commit adds this missing call when offloading have failed in the MV64XXX_I2C_ACTION_OFFLOAD_SEND_START case. This fix the timeout seen when the the i2c driver try to access an address where the device is absent on the Armada XP bases board. Cc: sta...@vger.kernel.org # v3.12+ Fixes: 930ab3d403ae (i2c: mv64xxx: Add I2C Transaction Generator support) Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com --- drivers/i2c/busses/i2c-mv64xxx.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) Acked-by: Jason Cooper ja...@lakedaemon.net 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: [PATCH] i2c: mv64xxx: Fix locked bus when offload is selected but not used on a message
On Fri, Feb 07, 2014 at 10:09:53AM -0800, Kevin Hilman wrote: Jason Cooper ja...@lakedaemon.net writes: On Fri, Feb 07, 2014 at 11:55:54AM +0100, Gregory CLEMENT wrote: Offload can be used only on regular transactions and for 1 to byte transfers. In the other cases we switch back to usual work flow. In this case we need to call mv64xxx_i2c_prepare_for_io() as this function is not used when we try to use offloading. This commit adds this missing call when offloading have failed in the MV64XXX_I2C_ACTION_OFFLOAD_SEND_START case. This fix the timeout seen when the the i2c driver try to access an address where the device is absent on the Armada XP bases board. Cc: sta...@vger.kernel.org # v3.12+ Fixes: 930ab3d403ae (i2c: mv64xxx: Add I2C Transaction Generator support) Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com --- drivers/i2c/busses/i2c-mv64xxx.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) I'd like to get a few tested-by's on this before this is pushed. We've had quite a bit of fixes this round :( Please test both multi_v7 and mvebu defconfigs. Kevin, I know you're busy with a lot more than us, but if you could confirm that this fixes the bus hangs you reported, that would be great. I applied this patch on top of next-20140207 and tested this on the armada-xp openblocks ax3, which is where I was seeing the I2C timeouts. I confirm it fixes the timeouts I was seeing. Tested-by: Kevin Hilman khil...@linaro.org Thanks, Kevin! 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: [PATCH] i2c: mv64xxx: Fix locked bus when offload is selected but not used on a message
On Fri, Feb 07, 2014 at 11:55:54AM +0100, Gregory CLEMENT wrote:
Offload can be used only on regular transactions and for 1 to byte
transfers. In the other cases we switch back to usual work flow.
In this case we need to call mv64xxx_i2c_prepare_for_io() as this
function is not used when we try to use offloading.
This commit adds this missing call when offloading have failed in the
MV64XXX_I2C_ACTION_OFFLOAD_SEND_START case.
This fix the timeout seen when the the i2c driver try to access an
address where the device is absent on the Armada XP bases board.
Cc: sta...@vger.kernel.org # v3.12+
Fixes: 930ab3d403ae (i2c: mv64xxx: Add I2C Transaction Generator support)
Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
drivers/i2c/busses/i2c-mv64xxx.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
I'd like to get a few tested-by's on this before this is pushed. We've
had quite a bit of fixes this round :( Please test both multi_v7 and
mvebu defconfigs.
Kevin, I know you're busy with a lot more than us, but if you could
confirm that this fixes the bus hangs you reported, that would be great.
thx,
Jason.
diff --git a/drivers/i2c/busses/i2c-mv64xxx.c
b/drivers/i2c/busses/i2c-mv64xxx.c
index b8c5187b9ee0..a1700c62d955 100644
--- a/drivers/i2c/busses/i2c-mv64xxx.c
+++ b/drivers/i2c/busses/i2c-mv64xxx.c
@@ -461,8 +461,15 @@ mv64xxx_i2c_do_action(struct mv64xxx_i2c_data *drv_data)
case MV64XXX_I2C_ACTION_OFFLOAD_SEND_START:
if (!mv64xxx_i2c_offload_msg(drv_data))
break;
- else
+ else {
drv_data-action = MV64XXX_I2C_ACTION_SEND_START;
+ /*
+ * Switch to the standard path, so we finally need to
+ * prepare the io that have not been done in
+ * mv64xxx_i2c_execute_msg
+ */
+ mv64xxx_i2c_prepare_for_io(drv_data, drv_data-msgs);
+ }
/* FALLTHRU */
case MV64XXX_I2C_ACTION_SEND_START:
writel(drv_data-cntl_bits | MV64XXX_I2C_REG_CONTROL_START,
--
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
Re: [PATCH v5 0/4] Fix i2c bus hang on A0 version of the Armada XP SoCs
On Mon, Jan 20, 2014 at 12:20:40PM +0100, Gregory CLEMENT wrote:
On 14/01/2014 09:46, Gregory CLEMENT wrote:
On 14/01/2014 03:14, Jason Cooper wrote:
Gregory,
On Wed, Jan 08, 2014 at 04:06:25PM +0100, Gregory CLEMENT wrote:
Hi,
Here come the 5th version of the series fixing 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 main change are the use of marvell,mv78230-a0-i2c and that the
function mvebu_get_soc_id() is now local to mach-mvebu.
The first patch add a mean to detect the SoCs version at run-time and
the second one use this feature in the driver.
The 3 first 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.
Ok, I've pulled this in by cherrypicking the commits. I needed to add
the 'Fixes: ...' and 'Cc: stable ...' language, so the commit ids were
going to change anyhow. I also added the note to the binding as we
discussed. I've also based this against v3.13-rc1 as there doesn't
appear to be any need to drag in everything up to -rc6.
I've pushed this to mvebu/fixes. Please take a look. If it all looks
good I'll send the pull request off tomorrow.
Hi Jason,
Everything looks perfect!
Thanks for having improved it,
Gregory
Hi Jason,
Eventually we didn't finish with it!
Ezequiel found an issue when we try to access pci_base if it have
not been properly mapped, in this case the kernel hang. Indeed the check
of the return of of_iomap was wrong.
The fix would be something like:
-o---o---o---o---o---o---o---o---o---o---o--
--- a/arch/arm/mach-mvebu/mvebu-soc-id.c
+++ b/arch/arm/mach-mvebu/mvebu-soc-id.c
@@ -88,7 +88,7 @@ static int __init mvebu_soc_id_init(void)
}
pci_base = of_iomap(child, 0);
- if (IS_ERR(pci_base)) {
+ if (pci_base == NULL) {
pr_err(cannot map registers\n);
ret = -ENOMEM;
goto res_ioremap;
-o---o---o---o---o---o---o---o---o---o---o--
How do you want we handle it?
Do you want a proper patch to amend?
A new series?
Something else?
submit a patch, please. We'll push it as a fix.
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: [PATCH v5 0/4] Fix i2c bus hang on A0 version of the Armada XP SoCs
Gregory, On Wed, Jan 08, 2014 at 04:06:25PM +0100, Gregory CLEMENT wrote: Hi, Here come the 5th version of the series fixing 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 main change are the use of marvell,mv78230-a0-i2c and that the function mvebu_get_soc_id() is now local to mach-mvebu. The first patch add a mean to detect the SoCs version at run-time and the second one use this feature in the driver. The 3 first 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. Ok, I've pulled this in by cherrypicking the commits. I needed to add the 'Fixes: ...' and 'Cc: stable ...' language, so the commit ids were going to change anyhow. I also added the note to the binding as we discussed. I've also based this against v3.13-rc1 as there doesn't appear to be any need to drag in everything up to -rc6. I've pushed this to mvebu/fixes. Please take a look. If it all looks good I'll send the pull request off tomorrow. 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: [PATCH v5 2/4] ARM: mvebu: Add quirk for i2c for the OpenBlocks AX3-4 board
Gregory, Arnd,
On Wed, Jan 08, 2014 at 04:06:27PM +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.
This commit add quirk in the mvebu platform code to check the SoC
version and then update the compatible string for the i2c controller
according to the revision of the SoC. Currently only some OpenBlocks
AX3-4 boards are known to use an A0 revision so the check is done only
for these boards.
Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
Cc: sta...@vger.kernel.org
---
arch/arm/mach-mvebu/armada-370-xp.c | 32
1 file changed, 32 insertions(+)
diff --git a/arch/arm/mach-mvebu/armada-370-xp.c
b/arch/arm/mach-mvebu/armada-370-xp.c
index e2acff98e750..0f61a4f22fb5 100644
--- a/arch/arm/mach-mvebu/armada-370-xp.c
+++ b/arch/arm/mach-mvebu/armada-370-xp.c
@@ -21,6 +21,7 @@
#include linux/clocksource.h
#include linux/dma-mapping.h
#include linux/mbus.h
+#include linux/slab.h
#include asm/hardware/cache-l2x0.h
#include asm/mach/arch.h
#include asm/mach/map.h
@@ -28,6 +29,7 @@
#include armada-370-xp.h
#include common.h
#include coherency.h
+#include mvebu-soc-id.h
static void __init armada_370_xp_map_io(void)
{
@@ -45,8 +47,38 @@ static void __init armada_370_xp_timer_and_clk_init(void)
#endif
}
+static void __init i2c_quirk(void)
+{
+ struct device_node *np;
+ u32 dev, rev;
+
+ /*
+ * Only revisons more recent than A0 support the offload
+ * mechanism. We can exit only if we are sure that we can
+ * get the SoC revision and it is more recent than A0.
+ */
+ if (mvebu_get_soc_id(rev, dev) == 0 dev MV78XX0_A0_REV)
+ return;
+
+ for_each_compatible_node(np, NULL, marvell,mv78230-i2c) {
+ struct property *new_compat;
+
+ new_compat = kzalloc(sizeof(*new_compat), GFP_KERNEL);
+
+ new_compat-name = kstrdup(compatible, GFP_KERNEL);
+ new_compat-length = sizeof(marvell,mv78230-a0-i2c);
+ new_compat-value = kstrdup(marvell,mv78230-a0-i2c,
+ GFP_KERNEL);
I'm still having some trouble with this compatible string choice... But
I have refined the problem :)
Do we create new compatible strings to indicate errata, or to indicate
'from this version forward there are new features'? The former would
indicate as Gregory has written '...-a0-i2c', the latter would warrant
'...-b0-i2c' and disabling offloading if we don't see '...-b0-i2c'.
I can see Gregory's approach if he were still using the property
'offload-broken', but I suspect the compatible strings should be handled
differently.
thx,
Jason.
+
+ of_update_property(np, new_compat);
+ }
+ return;
+}
+
static void __init armada_370_xp_dt_init(void)
{
+ if (of_machine_is_compatible(plathome,openblocks-ax3-4))
+ i2c_quirk();
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
}
--
1.8.1.2
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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 v5 2/4] ARM: mvebu: Add quirk for i2c for the OpenBlocks AX3-4 board
On Fri, Jan 10, 2014 at 12:05:21PM -0700, Jason Gunthorpe wrote: On Fri, Jan 10, 2014 at 01:22:40PM -0500, Jason Cooper wrote: Do we create new compatible strings to indicate errata, or to indicate 'from this version forward there are new features'? The former would indicate as Gregory has written '...-a0-i2c', the latter would warrant '...-b0-i2c' and disabling offloading if we don't see '...-b0-i2c'. s/-b0-i2c'./-b0-i2c' or newer./ IMHO the compatible string should represent a specific HW/SW ABI. So you need a unique compatible string for every variation of that ABI. My concern is that we tend to do things like marvell,orion-sata for the first version of the IP block we can work with. orion5x, kirkwood, dove, and armada 370/xp all use that compatible string to refer to that IP block. Given that we look at it as 'and newer', '...-a0-i2c' would mean no offloading until we introduce '-b0-i2c'. Or am I mis-understanding what you're saying? We already have a compatible string defined for the ABI that B0 presents. So 'mv78230-i2c' is newer than 'mv78230-a0-i2c', or are you referring to something else? 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: [PATCH v5 2/4] ARM: mvebu: Add quirk for i2c for the OpenBlocks AX3-4 board
On Fri, Jan 10, 2014 at 02:45:50PM -0500, Jason Cooper wrote: On Fri, Jan 10, 2014 at 12:05:21PM -0700, Jason Gunthorpe wrote: On Fri, Jan 10, 2014 at 01:22:40PM -0500, Jason Cooper wrote: Do we create new compatible strings to indicate errata, or to indicate 'from this version forward there are new features'? The former would indicate as Gregory has written '...-a0-i2c', the latter would warrant '...-b0-i2c' and disabling offloading if we don't see '...-b0-i2c'. s/-b0-i2c'./-b0-i2c' or newer./ IMHO the compatible string should represent a specific HW/SW ABI. So you need a unique compatible string for every variation of that ABI. My concern is that we tend to do things like marvell,orion-sata for the first version of the IP block we can work with. orion5x, kirkwood, dove, and armada 370/xp all use that compatible string to refer to that IP block. Given that we look at it as 'and newer', '...-a0-i2c' would mean no offloading until we introduce '-b0-i2c'. Or am I mis-understanding what you're saying? We already have a compatible string defined for the ABI that B0 presents. So 'mv78230-i2c' is newer than 'mv78230-a0-i2c', or are you referring to something else? I think the crux of it is: Is mv78230-i2c the first, or the default? 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: [PATCH v5 2/4] ARM: mvebu: Add quirk for i2c for the OpenBlocks AX3-4 board
On Fri, Jan 10, 2014 at 09:09:09PM +0100, Gregory CLEMENT wrote: Hi Jason, On 10/01/2014 20:45, Jason Cooper wrote: On Fri, Jan 10, 2014 at 12:05:21PM -0700, Jason Gunthorpe wrote: On Fri, Jan 10, 2014 at 01:22:40PM -0500, Jason Cooper wrote: Do we create new compatible strings to indicate errata, or to indicate 'from this version forward there are new features'? The former would indicate as Gregory has written '...-a0-i2c', the latter would warrant '...-b0-i2c' and disabling offloading if we don't see '...-b0-i2c'. s/-b0-i2c'./-b0-i2c' or newer./ IMHO the compatible string should represent a specific HW/SW ABI. So you need a unique compatible string for every variation of that ABI. My concern is that we tend to do things like marvell,orion-sata for the first version of the IP block we can work with. orion5x, kirkwood, dove, and armada 370/xp all use that compatible string to refer to that IP block. Given that we look at it as 'and newer', '...-a0-i2c' would mean no offloading until we introduce '-b0-i2c'. Or am I mis-understanding what you're saying? We already have a compatible string defined for the ABI that B0 presents. So 'mv78230-i2c' is newer than 'mv78230-a0-i2c', or are you referring to something else? I think you put too much attention in the name. Sure, I might be bikeshedding, but... There are just name referring a specific hardware. I don't think there is a consideration of order. For instance this driver also work with allwinner,sun4i-i2c, here we can clearly see that this compatible don't describe a newer or an older version of the device it just describe an other version. No one has said EPAPR requires compatible string heirarchies to be handled as such. Or, EPAPR doesn't specify, so we choose to treat them in such-and-such manner. The point I'm trying to highlight in this case is that we aren't clear on how we code compatible strings. Yes, we use the most specific compatible in the list, which is typically the first one. What we haven't cleared up is how to handle a newer IP with an older compatible string. eg: we boot an -a0 SoC, the dtb has the i2c node with most specific compatible string 'mv78230-a0-i2c'. Obviously, we disable offload. What do we do with an older DTB which only has 'mv78230-i2c'? [see 1] now we're running on a -b0 SoC. We boot with a DTB that has a node 'mv78230-i2c'. Is this an old DTB? Or is this a new DTB written with the understanding that -a0-i2c is an exception? You see? We aren't being definitive. The kernel really doesn't know for certain whether it should enable offloading in this case or not. [1] Yes, for Armada i2c, we can retrieve the CPU revision to wade out of this grey area. I'm just looking for clarification regarding the general DT handling of this scenario. I'm reluctant to push this series until I have an answer because the answer will change the meaning of 'mv78230-i2c'. Which *is* relevant to this series. Personally, I feel that since 'mv78230-i2c' has been used to refer to A0 revision of the IP, we should treat any nodes using it (as it's most specific string) as having broken offloading. Which implies that -b0-i2c should be used to indicate IPs with working offloading. I swear, I'm starting to feel like Russell... Maybe I'm just grumpy after crawling out from under my email backlog... About this whole series how do you plan to handle it? It was acked by Wolfram and even by Arnd. This series is for fixing a bug so it should be part of the stable kernels including the 3.13. However we are so close to the release of the 3.13, that it seems to be too late. Yes, it's a fix, and it'll get in. It might be too late for v3.13, but it'll get in to v3.13.1 (and the other appropriate stable kernels). I don't like to rush fixes just because of a pending merge window. thx, Jason. At least I hope it can be pushed to the arm-soc-next and be part of the 3.14-rc1. What do you think about it? Thanks, Gregory thx, Jason. -- 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: [PATCH v5 2/4] ARM: mvebu: Add quirk for i2c for the OpenBlocks AX3-4 board
On Fri, Jan 10, 2014 at 09:12:41PM +0100, Gregory CLEMENT wrote: Jason, On 10/01/2014 21:08, Jason Cooper wrote: On Fri, Jan 10, 2014 at 02:45:50PM -0500, Jason Cooper wrote: On Fri, Jan 10, 2014 at 12:05:21PM -0700, Jason Gunthorpe wrote: On Fri, Jan 10, 2014 at 01:22:40PM -0500, Jason Cooper wrote: Do we create new compatible strings to indicate errata, or to indicate 'from this version forward there are new features'? The former would indicate as Gregory has written '...-a0-i2c', the latter would warrant '...-b0-i2c' and disabling offloading if we don't see '...-b0-i2c'. s/-b0-i2c'./-b0-i2c' or newer./ IMHO the compatible string should represent a specific HW/SW ABI. So you need a unique compatible string for every variation of that ABI. My concern is that we tend to do things like marvell,orion-sata for the first version of the IP block we can work with. orion5x, kirkwood, dove, and armada 370/xp all use that compatible string to refer to that IP block. Given that we look at it as 'and newer', '...-a0-i2c' would mean no offloading until we introduce '-b0-i2c'. Or am I mis-understanding what you're saying? We already have a compatible string defined for the ABI that B0 presents. So 'mv78230-i2c' is newer than 'mv78230-a0-i2c', or are you referring to something else? I think the crux of it is: Is mv78230-i2c the first, or the default? Here it's clearly the default So we should default to no offloading when we see it? Since it has been deployed referring to -a0 revision i2c IP blocks? 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: [PATCH v5 2/4] ARM: mvebu: Add quirk for i2c for the OpenBlocks AX3-4 board
On Fri, Jan 10, 2014 at 02:06:34PM -0700, Jason Gunthorpe wrote: On Fri, Jan 10, 2014 at 02:45:50PM -0500, Jason Cooper wrote: IMHO the compatible string should represent a specific HW/SW ABI. So you need a unique compatible string for every variation of that ABI. My concern is that we tend to do things like marvell,orion-sata for the first version of the IP block we can work with. orion5x, kirkwood, dove, and armada 370/xp all use that compatible string to refer to that IP block. Right, absent guidance from the originators of the IP block that is sort of all we are left with. But something like 'marvell,orion-sata' is just a label to describe the ABI implemented by the HW on that particular chip. Given that we look at it as 'and newer', '...-a0-i2c' would mean no offloading until we introduce '-b0-i2c'. Or am I mis-understanding what you're saying? I would stop thinking of this in terms of 'is newer' / 'is older'. marvell,orion-sata means any HW that implements the same ABI as the orion chip. When we get a different chip that has a compatible, but extended ABI we introduce a new label: compatible = marvell,foobar-sata, marvell,orion-sata; And if we get one that has a very similar, but incompatible ABI, we still introduce a new label: compatible = marvell,foobar2-sata; And everything works properly. We already have a compatible string defined for the ABI that B0 presents. So 'mv78230-i2c' is newer than 'mv78230-a0-i2c', or are you referring to something else? 'mv78230-i2c' is the name that was picked to describe the ABI that works as-documented in the manual 'mv78230-a0-i2c' is the name that was picked to describe the ABI that works as-implemented in the A0 chip :) Ok, so my only outstanding concern is that 'mv78230-i2c' has been used to refer to the A0 revision of the i2c IP block (v3.12). If we now change the meaning to be as documented then we get broken systems. thx, Jason. There is no newer/older, they are just two different ABIs. I guess it turns out that 'mv78230-a0-i2c' is a strict compatible subset of 'mv78230-i2c' - but that doesn't really make a difference. The 'mv78230-i2c' driver is guarenteed avaialble in all places where the 'mv78230-a0-i2c' driver would be available. 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: [PATCH v5 2/4] ARM: mvebu: Add quirk for i2c for the OpenBlocks AX3-4 board
On Fri, Jan 10, 2014 at 10:21:29PM +0100, Gregory CLEMENT wrote: On 10/01/2014 22:14, Jason Cooper wrote: On Fri, Jan 10, 2014 at 09:12:41PM +0100, Gregory CLEMENT wrote: Jason, On 10/01/2014 21:08, Jason Cooper wrote: On Fri, Jan 10, 2014 at 02:45:50PM -0500, Jason Cooper wrote: On Fri, Jan 10, 2014 at 12:05:21PM -0700, Jason Gunthorpe wrote: On Fri, Jan 10, 2014 at 01:22:40PM -0500, Jason Cooper wrote: Do we create new compatible strings to indicate errata, or to indicate 'from this version forward there are new features'? The former would indicate as Gregory has written '...-a0-i2c', the latter would warrant '...-b0-i2c' and disabling offloading if we don't see '...-b0-i2c'. s/-b0-i2c'./-b0-i2c' or newer./ IMHO the compatible string should represent a specific HW/SW ABI. So you need a unique compatible string for every variation of that ABI. My concern is that we tend to do things like marvell,orion-sata for the first version of the IP block we can work with. orion5x, kirkwood, dove, and armada 370/xp all use that compatible string to refer to that IP block. Given that we look at it as 'and newer', '...-a0-i2c' would mean no offloading until we introduce '-b0-i2c'. Or am I mis-understanding what you're saying? We already have a compatible string defined for the ABI that B0 presents. So 'mv78230-i2c' is newer than 'mv78230-a0-i2c', or are you referring to something else? I think the crux of it is: Is mv78230-i2c the first, or the default? Here it's clearly the default So we should default to no offloading when we see it? Since it has been deployed referring to -a0 revision i2c IP blocks? But this assumption is wrong as I already wrote few days ago, mv78230-i2c has been deployed referring to -b0 revision i2c IP blocks since the begining. Ok, sorry. As I wrote on irc last week, I've been on travel and haven't been able to fully digest everything coming in. My re-read of all the threads regarding this this morning didn't catch it. It was developed on and for B0 version, and this compatible was created for this specific version. It was latter that we realized that it was not fully compatible with A0. But for sure: mv78230-i2c == I2C IP running on Armada XP B0 (or latter) Ok, this still feels counter-intuitive, and folks not familiar with the development process might assume the opposite. So I'll reply to 4/4 with a reword to make your above statement an explicit part of the binding documentation. No need to do another patch version. I'll fix it up when I pull it in if you're ok with it. 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: [PATCH v5 4/4] i2c: mv64xxx: Document the newly introduced Armada XP A0 compatible
Gregory, On Wed, Jan 08, 2014 at 04:06:29PM +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 ead to a kernel hang during boot. I'll fixup s/ead/lead/ here. The commit introduces a new the compatible string marvell,mv78230-a0-i2c for the i2c controller. Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com cc: devicet...@vger.kernel.org --- 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 If it's ok with you Gregory, I'll amend this hunk as follows: or marvell,mv78230-i2c or marvell,mv78230-a0-i2c Only use marvell,mv78230-a0-i2c for a very rare, initial version of the SoC which had broken offload support. Linux auto-detects this and sets it appropriately. thx, Jason. - interrupts : The interrupt number Optional properties : -- 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
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 gregory.clem...@free-electrons.com
---
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 linux/clk.h
#include linux/err.h
#include linux/delay.h
+#include linux/mvebu-soc-id.h
#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: [RFC PATCH 1/3] arm: mvebu: add new dts file for old variant of Openblocks AX3-4
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,
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 gregory.clem...@free-electrons.com
---
.../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 gregory.clem...@free-electrons.com
+ *
+ * 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, marvell,armadaxp-mv78260,
marvell,armadaxp, marvell,armada-370-xp;
+
+ chosen {
+ bootargs = console=ttyS0,115200 earlyprintk;
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0 0x 0 0xC000; /* 3 GB */
+ };
+
+ soc {
+
+ internal-regs {
+ i2c@11000 {
+ compatible = marvell,mv78230-a0-i2c,
marvell,mv64xxx-i2c;
+ };
+ i2c@11100 {
+ compatible = marvell,mv78230-a0-i2c,
marvell,mv64xxx-i2c;
+ };
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/armada-xp-common-openblocks-ax3-4.dtsi
b/arch/arm/boot/dts/armada-xp-common-openblocks-ax3-4.dtsi
new file mode 100644
index ..0d452b07baf5
--- /dev/null
+++ b/arch/arm/boot/dts/armada-xp-common-openblocks-ax3-4.dtsi
@@ -0,0 +1,177 @@
+/*
+ * Device Tree file for OpenBlocks AX3-4 board
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Thomas Petazzoni thomas.petazz...@free-electrons.com
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License
Re: [RFC PATCH 3/3] i2c: mv64xxx: Document the newly introduced Armada XP A0 compatible
On Tue, Dec 31, 2013 at 05:44:53PM +0100, Gregory CLEMENT wrote: Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com --- 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'. thx, Jason. - interrupts : The interrupt number Optional properties : -- 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
Re: [RFC PATCH 3/3] i2c: mv64xxx: Document the newly introduced Armada XP A0 compatible
[+ DT ml, Grant, Rob] On Tue, Dec 31, 2013 at 05:44:53PM +0100, Gregory CLEMENT wrote: Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com --- 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'. thx, Jason. - interrupts : The interrupt number Optional properties : -- 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
Re: Openblocks AX3-4 i2c bus lockup
On Tue, Dec 31, 2013 at 01:50:34PM +0100, Sebastian Hesselbarth wrote: On 12/31/2013 01:28 PM, Gregory CLEMENT wrote: First I wanted to be sure that there the issue was not introduce by a commit so reverted one by one the commits on the file drivers/i2c/busses/i2c-mv64xxx.c. I tested it on both version of the OpenBlock AX-4 (with CPU A0 and B0). After each commit the kernel continue to work on the B0 version as expected, but it was when I reverted the commit i2c: mv64xxx: Add I2C Transaction Generator support that it worked also on the A0 version. Then I had a look on the errata datasheet and I found issues that I missed when I worked on it. This issues were fixed in B0 version. The fix should be pretty simple: disabling the offload_enabled flag when an A0 version of the CPU is used. For this there are 2 solutions: introducing a new compatible string or trying to detect the CPU stepping at runtime. I would prefer the second solution and I am looking for a way to get this information. 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. Agreed. We could the same in drivers/pci/host/pci-mvebu.c, however it would add a dependency between PCIe and I2C for the mvebu SoCs. I can think of several options: 1. Using only a new compatible strings: mv78230-A0-i2c. The benefits of it are that it is very easy to implement and it don't touch anything else than the driver itself. The drawback is that we need to add an new dts file for the A0 variant of the AX3-4. If we decide to do this, it should be mv78230-i2c runs assuming it is on the A0 variant. mv78230-B0-i2c would permit offloading. I know that DT should describe HW, but at this point I tend to not fork off another dts. If it is probable, we should probe it. SoC revisions are really hard to see even from looking at the pcb, there is no way for users to determine the correct dts. In theory, this is something that could be tweaked at runtime by the bootloader. But the bootloaders aren't there yet, and requiring a bootloader upgrade isn't an option. However, this is something that should definitely be expressed in the DT. I have no problem with doing both. eg check for -B0-i2c, if that's missing, retrieve the CPU variant and then enable/disable offloading. 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: [PATCH v6 4/4] ARM: dts: mvebu: Update with the new compatible string for mv64xxx-i2c
On Mon, Sep 02, 2013 at 01:44:45PM +0200, Gregory CLEMENT wrote: Hi Jason, Unless I missed it I didn't see this patch in your last pull request. Wolfram took the 3 others patches and Mark Rutland agreed with the binding introduced in the patch 3. So I think we are fine to take this patch in mvebu. Ok, I had dropped it before until the dust settled. I've re-applied it and will be sending the last pull shortly. 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: [PATCH v6 4/4] ARM: dts: mvebu: Update with the new compatible string for mv64xxx-i2c
On Mon, Sep 02, 2013 at 01:44:45PM +0200, Gregory CLEMENT wrote: Hi Jason, Unless I missed it I didn't see this patch in your last pull request. Wolfram took the 3 others patches and Mark Rutland agreed with the binding introduced in the patch 3. So I think we are fine to take this patch in mvebu. Ahh, good. Thanks for keeping an eye on this. I'll submit a PR tonight or tomorrow. And for the couple of patches remaining in mvebu/fixes-non-critical... 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: [PATCH v5 3/3] ARM: dts: mvebu: Introduce a new compatible string for mv64xxx-i2c
Ezequiel,
On Fri, Aug 09, 2013 at 06:13:37AM -0300, Ezequiel Garcia wrote:
(Sending to devicetree)
As an FYI? I already responded to Mark Rutland's request for the
binding doc to be updated (that it was this patch, already merged into
mvebu/dt). I also asked him if everything looked ok to him and he said
yes.
Is there something else you're looking for with this patch?
confused,
Jason.
On Fri, Aug 09, 2013 at 11:05:58AM +0200, Gregory CLEMENT wrote:
The mv64xxx-i2c embedded in the Armada XP have a new feature to
offload i2c transaction. This new version of the IP come also with
some errata. This lead to the introduction to a another compatible
string.
This commit split the i2c information into armada-370.dtsi and
armada-xp.dtsi. Most of the data remains the same and stay in the
common file Armada-370-xp.dtsi. With this new feature the size of the
registers are bigger for Armada XP and the new compatible string is
used.
The Device Tree binding documentation is updated accordingly.
Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt | 13 -
arch/arm/boot/dts/armada-370-xp.dtsi | 2 --
arch/arm/boot/dts/armada-370.dtsi | 8
arch/arm/boot/dts/armada-xp.dtsi | 10 ++
4 files changed, 30 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt
b/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt
index a1ee681..c5dd952 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt
@@ -4,7 +4,8 @@
Required properties :
- reg : Offset and length of the register set for the device
- - compatible : Should be marvell,mv64xxx-i2c
+ - compatible : Should be marvell,mv64xxx-i2c and
marvell,mv7230-i2c
+for controller which support the I2C Transaction Generator
- interrupts : The interrupt number
Optional properties :
@@ -20,3 +21,13 @@ Examples:
interrupts = 29;
clock-frequency = 10;
};
+
+For a controller which support the I2C Transaction Generator:
+
+ i2c@11000 {
+ compatible = marvell,mv78230-i2c, marvell,mv64xxx-i2c;
+ reg = 0x11000 0x100;
+ compatible = marvell,mv64xxx-i2c;
+ interrupts = 29;
+ clock-frequency = 10;
+ };
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi
b/arch/arm/boot/dts/armada-370-xp.dtsi
index 90b1176..d8b24c9 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -121,7 +121,6 @@
i2c0: i2c@11000 {
compatible = marvell,mv64xxx-i2c;
- reg = 0x11000 0x20;
#address-cells = 1;
#size-cells = 0;
interrupts = 31;
@@ -132,7 +131,6 @@
i2c1: i2c@11100 {
compatible = marvell,mv64xxx-i2c;
- reg = 0x11100 0x20;
#address-cells = 1;
#size-cells = 0;
interrupts = 32;
diff --git a/arch/arm/boot/dts/armada-370.dtsi
b/arch/arm/boot/dts/armada-370.dtsi
index fa3dfc6..0e2eefa 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -155,6 +155,14 @@
};
};
+ i2c0: i2c@11000 {
+ reg = 0x11000 0x20;
+ };
+
+ i2c1: i2c@11100 {
+ reg = 0x11100 0x20;
+ };
+
usb@5 {
clocks = coreclk 0;
};
diff --git a/arch/arm/boot/dts/armada-xp.dtsi
b/arch/arm/boot/dts/armada-xp.dtsi
index 416eb94..e1f2547 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -138,6 +138,16 @@
};
};
+ i2c0: i2c@11000 {
+ compatible = marvell,mv78230-i2c,
marvell,mv64xxx-i2c;
+ reg = 0x11000 0x100;
+ };
+
+ i2c1: i2c@11100 {
+ compatible = marvell,mv78230-i2c,
marvell,mv64xxx-i2c;
+ reg = 0x11100 0x100;
+ };
+
usb@5 {
clocks = gateclk 18;
};
--
1.8.1.2
--
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
Re: [PATCH 1/3] i2c-mv64xxx: Add I2C Transaction Generator support
On Wed, Aug 07, 2013 at 04:35:46PM +0200, Wolfram Sang wrote: But we shouldn't use it alone: we should always use: compatible = marvell,mv78230-i2c, marvell,mv64xxx-i2c; From my point of view using marvell,mv78230-i2c alone is an error. Wolfram what is your opinion on it? It is not strictly an error, but risky. If you use an older Kernel version (or other OS) which only offers mv64xxx you will have no match. Although the driver theoretically could have basic support for all mv64xxx variants skipping all additional features of later IP revisions. I agree here. The driver is advertising what IP blocks it can handle, so it makes sense to add both strings since it can handle both. 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: [PATCH 3/3] ARM: dts: mvebu: Introduce a new compatible string for mv64xxx-i2c
On Mon, Jul 15, 2013 at 04:24:38PM +0200, Gregory CLEMENT wrote: The mv64xxx-i2c embedded in the Armada XP have a new feature to offload i2c transaction. This new version of the IP come also with some errata. This lead to the introduction to a another compatible string. This commit split the i2c information into armada-370.dtsi and armada-xp.dtsi. Most of the data remains the same and stay in the common file Armada-370-xp.dtsi. With this new feature the size of the registers are bigger for Armada XP and the new compatible string is used. The Device Tree binding documentation is updated accordingly. Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com --- Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt | 13 - arch/arm/boot/dts/armada-370-xp.dtsi | 2 -- arch/arm/boot/dts/armada-370.dtsi | 8 arch/arm/boot/dts/armada-xp.dtsi | 10 ++ 4 files changed, 30 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt b/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt index a1ee681..c5dd952 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt @@ -4,7 +4,8 @@ Required properties : - reg : Offset and length of the register set for the device - - compatible : Should be marvell,mv64xxx-i2c + - compatible : Should be marvell,mv64xxx-i2c and marvell,mv7230-i2c +for controller which support the I2C Transaction Generator - interrupts : The interrupt number As you've preserved backwards compatibility with the original compat string, Applied to mvebu/dt 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: [PATCH v3 4/4] ARM: dts: mvebu: Introduce a new compatible string for mv64xxx-i2c
On Fri, Jun 21, 2013 at 04:15:29PM +0200, Sebastian Hesselbarth wrote:
On 06/21/13 16:07, Jason Cooper wrote:
On Fri, Jun 21, 2013 at 03:32:09PM +0200, Gregory CLEMENT wrote:
The mv64xxx-i2c embedded in the Armada XP have a new feature to
offload i2c transaction. This new version of the IP come also with
some errata. This lead to the introduction to a another compatible
string.
This commit split the i2c information into armada-370.dtsi and
armada-xp.dtsi. Most of the data remains the same and stay in the
common file Armada-370-xp.dtsi. With this new feature the size of the
registers are bigger for Armada XP and the new compatible string is
used.
The Device Tree binding documentation is updated accordingly.
Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt | 13 -
arch/arm/boot/dts/armada-370-xp.dtsi | 2 --
arch/arm/boot/dts/armada-370.dtsi | 8
arch/arm/boot/dts/armada-xp.dtsi | 10 ++
4 files changed, 30 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt
b/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt
index a1ee681..ce7af6a 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt
@@ -4,7 +4,8 @@
Required properties :
- reg : Offset and length of the register set for the device
- - compatible : Should be marvell,mv64xxx-i2c
+ - compatible : Should be marvell,mv64xxx-i2c and
marvell,mv7230-i2c
+for controller which support the I2C Transaction Generator
Jason, Gregory,
Also, s/mv7230/mv78230/
noted.
from a quick check of the patch set (which you forgot to send to LKML)
I am wondering why you didn't update the of matches struct with the new
compatible for marvell,mv78230-i2c? This will save you from still
having marvell,mv64xxx-i2c as additional compatible to match device
and driver. With that the above should also be s/and/or/.
agreed, good point.
Gregory,
I'm sending the last PRs for mvebu today. I'll include this one with my
suggestion and Sebastian's if you're ok with it. That means you'll have
to respin the series for the i2c folks. Does that work for you?
thx,
Jason.
- interrupts : The interrupt number
Optional properties :
@@ -20,3 +21,13 @@ Examples:
interrupts = 29;
clock-frequency = 10;
};
+
+For a controller which support the I2C Transaction Generator:
+
+ i2c@11000 {
+ compatible = marvell,mv64xxx-i2c, marvell,mv78230-i2c;
+ reg = 0x11000 0x100;
+ compatible = marvell,mv64xxx-i2c;
extra compatible line. If there's nothing else, I'll fix this up when I
pull it in.
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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 4/4] ARM: dts: mvebu: Introduce a new compatible string for mv64xxx-i2c
On Fri, Jun 21, 2013 at 05:03:23PM +0200, Wolfram Sang wrote: from a quick check of the patch set (which you forgot to send to LKML) I am wondering why you didn't update the of matches struct with the new compatible for marvell,mv78230-i2c? This will save you from still having marvell,mv64xxx-i2c as additional compatible to match device and driver. With that the above should also be s/and/or/. agreed, good point. Gregory, I'm sending the last PRs for mvebu today. I'll include this one with my suggestion and Sebastian's if you're ok with it. That means you'll have to respin the series for the i2c folks. Does that work for you? No hurry, please. Most of the patches are 3.12 material anyhow, so we can as well just wait until the I2C patches are okay and then update the dts later. Ok, thanks for the heads up. I'll put this in my v3.12 stack. 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: [PATCH 2/2] ARM: dts: mvebu: Add the i2c-bridge capability to the mv64xxx-i2c
On Fri, Jun 07, 2013 at 05:42:23PM +0200, Gregory CLEMENT wrote: The mv64xxx-i2c embedded in the Armada XP have a new feature called i2c-bridge. This commit split the i2c information into armada-370.dtsi and armada-xp.dtsi. Most of the data remains the same and stay in the common file Armada-370-xp.dtsi. With this new feature the size of the registers are bigger for Armada XP and for this SoCs we add a new flag for the i2c-bridge capability. The Device Tree binding documentation is updated accordingly. Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com --- Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt | 6 ++ arch/arm/boot/dts/armada-370-xp.dtsi | 2 -- arch/arm/boot/dts/armada-370.dtsi | 8 arch/arm/boot/dts/armada-xp.dtsi | 10 ++ 4 files changed, 24 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt b/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt index f46d928..8ede3e7 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt @@ -8,6 +8,12 @@ Required properties : - interrupts : The interrupt number - clock-frequency : Desired I2C bus clock frequency in Hz. +Optional properties : + +- i2c,i2c-bridge : This flag indicate that the i2c controller have the + Transaction Generator support and we want to use it. Not all the + mv64xxx controller have this feature. Do you have a list of which controllers definitely do, or definitely don't? That would be helpful for folks adding new boards. + Examples: nit. should the example be updated? 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: [PATCH 5/9] ARM: kirkwood: use devicetree for orion-spi
On Tue, Jun 12, 2012 at 02:04:33PM +0200, Andrew Lunn wrote:
+ spi@10600 {
+ compatible = marvell,orion-spi;
+ #address-cells = 1;
+ #size-cells = 0;
+ cell-index = 0;
+ reg = 0x10600 0x28;
+ status = disabled;
+ };
+
index fa51586..0942139 100644
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-kirkwood/board-dt.c
@@ -26,6 +26,11 @@ static struct of_device_id kirkwood_dt_match_table[]
__initdata = {
{ }
};
+struct of_dev_auxdata kirkwood_auxdata_lookup[] __initdata = {
+ OF_DEV_AUXDATA(marvell,orion-spi, 0xf1010600, orion_spi.0, NULL),
Isn't this -^^ defined somewhere?
Yes, there is a #define for this. However, in this case, i think the
number actually tells you more. The dtsi file has the number, not some
symbolic representation. Also, some platforms, e.g. Dove, have more
than one spi controller. Having the number there makes it easier to
see the mapping between the node in DT and the name used in the
platform device. If we use the #define it means making an indirection
via kirkwood.h for a human to see the mapping.
However, i can change it...
Nope, good point. If no one else pipes up, leave it as is.
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: [PATCH 0/9] Kirkwood DT support For IRQ, SPI, I2C, GPIO
On Sun, Jun 10, 2012 at 12:31:52PM +0200, Andrew Lunn wrote: This patch set adds Device Tree support for IRQ, SPI, I2C and GPIO on Orion based drivers, and makes use of these for kirkwood devices. It also adds the ability to boot QNAP TS219 based systems using device tree. Andrew, thanks for the patch series. At first glance, things look good. I'll let this sit on the mailinglist for a few days and try to test it early this week. thx, Jason. The SPI DT patches are from Michael Walle, and have been previously posted. I've addressed the issues raised during the review. The SPI refactor to use the SPI framework was submitted for merge into 3.5, but due to dependency issues, which are now resolved, the patch was not accepted. This patch has been modified to remove two NOP functions, which the SPI framework no longer needs. Andrew Lunn (5): ARM: Kirkwood: Add interrupt controller support for DT boards SPI: Refactor spi-orion to use SPI framework queue. I2C: MV64XXX: Add Device Tree support ARM: Kirkwood: Add DT support for GPIO controllers Kirkwood: Add basic device tree support for QNAP TS219. Michael Walle (4): spi-orion: remove uneeded spi_info spi-orion: add device tree binding ARM: kirkwood: use devicetree for orion-spi ARM: kirkwood: use devicetree for SPI on dreamplug .../devicetree/bindings/arm/mrvl/intc.txt | 20 ++ .../devicetree/bindings/gpio/mrvl-gpio.txt | 25 +++ Documentation/devicetree/bindings/i2c/mrvl-i2c.txt | 35 ++- .../devicetree/bindings/spi/spi-orion.txt |5 + arch/arm/boot/dts/kirkwood-dreamplug.dts | 29 +++ arch/arm/boot/dts/kirkwood-ts219-6281.dts | 21 ++ arch/arm/boot/dts/kirkwood-ts219-6282.dts | 21 ++ arch/arm/boot/dts/kirkwood-ts219.dtsi | 73 +++ arch/arm/boot/dts/kirkwood.dtsi| 51 + arch/arm/mach-kirkwood/Kconfig | 15 ++ arch/arm/mach-kirkwood/Makefile|1 + arch/arm/mach-kirkwood/Makefile.boot |1 + arch/arm/mach-kirkwood/board-dreamplug.c | 41 arch/arm/mach-kirkwood/board-dt.c | 36 +++- arch/arm/mach-kirkwood/board-ts219.c | 86 arch/arm/mach-kirkwood/common.h|5 + arch/arm/mach-kirkwood/irq.c | 20 +- arch/arm/plat-orion/gpio.c | 68 +- arch/arm/plat-orion/include/plat/gpio.h|2 + drivers/i2c/busses/i2c-mv64xxx.c | 38 +++- drivers/spi/spi-orion.c| 223 ++-- 21 files changed, 605 insertions(+), 211 deletions(-) create mode 100644 Documentation/devicetree/bindings/spi/spi-orion.txt create mode 100644 arch/arm/boot/dts/kirkwood-ts219-6281.dts create mode 100644 arch/arm/boot/dts/kirkwood-ts219-6282.dts create mode 100644 arch/arm/boot/dts/kirkwood-ts219.dtsi create mode 100644 arch/arm/mach-kirkwood/board-ts219.c -- 1.7.10 -- 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 1/9] ARM: Kirkwood: Add interrupt controller support for DT boards
On Sun, Jun 10, 2012 at 12:31:53PM +0200, Andrew Lunn wrote:
Signed-off-by: Andrew Lunn and...@lunn.ch
---
.../devicetree/bindings/arm/mrvl/intc.txt | 20 ++
arch/arm/boot/dts/kirkwood.dtsi|9
arch/arm/mach-kirkwood/board-dt.c | 22
+++-
3 files changed, 50 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/arm/mrvl/intc.txt
b/Documentation/devicetree/bindings/arm/mrvl/intc.txt
index 80b9a94..612536e 100644
--- a/Documentation/devicetree/bindings/arm/mrvl/intc.txt
+++ b/Documentation/devicetree/bindings/arm/mrvl/intc.txt
@@ -38,3 +38,23 @@ Example:
reg-names = mux status, mux mask;
mrvl,intc-nr-irqs = 2;
};
+
+* Marvell Orion Interrupt controller
+
+Required properties
+- compatible : Should be marvell,orion-intc
+- #interrupt-cells: Specifies the number of cells needed to encode an
+ interrupt source. Supported value is 1
+- interrupt-controller : So that its clear its an interrupt controller.
nit. Declare this node to be an interrupt controller. If you end up
doing a v2 for other reasons, go ahead and add this. Otherwise, don't
worry about it.
+Optional properties
+- reg : Not used yet, but will contain the interrupt mask address
+
+Example:
+
+ intc: interrupt-controller {
+ compatible = marvell,orion-intc, marvell,intc;
+ interrupt-controller;
+ #interrupt-cells = 1;
+reg = 0xfed20204 0x04,
+ 0xfed20214 0x04;
+};
diff --git a/arch/arm/boot/dts/kirkwood.dtsi b/arch/arm/boot/dts/kirkwood.dtsi
index 926528b..8eab7c4 100644
--- a/arch/arm/boot/dts/kirkwood.dtsi
+++ b/arch/arm/boot/dts/kirkwood.dtsi
@@ -2,6 +2,15 @@
/ {
compatible = mrvl,kirkwood;
+ interrupt-parent = intc;
+
+ intc: interrupt-controller {
+ compatible = marvell,orion-intc, marvell,intc;
+ interrupt-controller;
+ #interrupt-cells = 1;
+reg = 0xfed20204 0x04,
+ 0xfed20214 0x04;
+};
ocp@f100 {
compatible = simple-bus;
diff --git a/arch/arm/mach-kirkwood/board-dt.c
b/arch/arm/mach-kirkwood/board-dt.c
index edc3f8a..fa51586 100644
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-kirkwood/board-dt.c
@@ -14,6 +14,7 @@
#include linux/init.h
#include linux/of.h
#include linux/of_platform.h
+#include linux/of_irq.h
#include linux/kexec.h
#include asm/mach/arch.h
#include asm/mach/map.h
@@ -80,11 +81,30 @@ static const char *kirkwood_dt_board_compat[] = {
NULL
};
+static int __init kirkwood_add_irq_domain(struct device_node *np,
+ struct device_node *interrupt_parent)
+{
+ kirkwood_init_irq();
+ irq_domain_add_legacy(np, 64, 0, 0, irq_domain_simple_ops, NULL);
+ return 0;
+}
+
+static const struct of_device_id kirkwood_irq_match[] = {
+ { .compatible = marvell,orion-intc,
+ .data = kirkwood_add_irq_domain, },
+ {},
+};
+
+static void __init kirkwood_dt_init_irq(void)
+{
+ of_irq_init(kirkwood_irq_match);
+}
+
DT_MACHINE_START(KIRKWOOD_DT, Marvell Kirkwood (Flattened Device Tree))
/* Maintainer: Jason Cooper ja...@lakedaemon.net */
.map_io = kirkwood_map_io,
.init_early = kirkwood_init_early,
- .init_irq = kirkwood_init_irq,
+ .init_irq = kirkwood_dt_init_irq,
.timer = kirkwood_timer,
.init_machine = kirkwood_dt_init,
.restart= kirkwood_restart,
--
1.7.10
Looks good.
Acked-by: Jason Cooper ja...@lakedaemon.net
I'll add Tested-by: once I get a chance.
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: [PATCH 4/9] spi-orion: add device tree binding
On Sun, Jun 10, 2012 at 12:31:56PM +0200, Andrew Lunn wrote:
From: Michael Walle mich...@walle.cc
Signed-off-by: Michael Walle mich...@walle.cc
Signed-off-by: Andrew Lunn and...@lunn.ch
Looks good.
Acked-by: Jason Cooper ja...@lakedaemon.net
---
Documentation/devicetree/bindings/spi/spi-orion.txt |5 +
drivers/spi/spi-orion.c |9 +
2 files changed, 14 insertions(+)
create mode 100644 Documentation/devicetree/bindings/spi/spi-orion.txt
diff --git a/Documentation/devicetree/bindings/spi/spi-orion.txt
b/Documentation/devicetree/bindings/spi/spi-orion.txt
new file mode 100644
index 000..e68597a
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/spi-orion.txt
@@ -0,0 +1,5 @@
+Marvell Orion SPI device
+
+Required properties:
+- compatible : should be marvell,orion-spi.
+- reg : offset and length of the register set for the device
diff --git a/drivers/spi/spi-orion.c b/drivers/spi/spi-orion.c
index 8c3d625..b16db3d 100644
--- a/drivers/spi/spi-orion.c
+++ b/drivers/spi/spi-orion.c
@@ -17,6 +17,7 @@
#include linux/io.h
#include linux/spi/spi.h
#include linux/module.h
+#include linux/of.h
#include linux/clk.h
#include asm/unaligned.h
@@ -429,6 +430,7 @@ static int __init orion_spi_probe(struct platform_device
*pdev)
if (orion_spi_reset(spi) 0)
goto out_rel_mem;
+ master-dev.of_node = pdev-dev.of_node;
status = spi_register_master(master);
if (status 0)
goto out_rel_mem;
@@ -468,10 +470,17 @@ static int __exit orion_spi_remove(struct
platform_device *pdev)
MODULE_ALIAS(platform: DRIVER_NAME);
+static const struct of_device_id orion_spi_of_match_table[] __devinitdata = {
+ { .compatible = marvell,orion-spi, },
+ {}
+};
+MODULE_DEVICE_TABLE(of, orion_spi_of_match_table);
+
static struct platform_driver orion_spi_driver = {
.driver = {
.name = DRIVER_NAME,
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(orion_spi_of_match_table),
},
.remove = __exit_p(orion_spi_remove),
};
--
1.7.10
--
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 5/9] ARM: kirkwood: use devicetree for orion-spi
On Sun, Jun 10, 2012 at 12:31:57PM +0200, Andrew Lunn wrote:
From: Michael Walle mich...@walle.cc
Populate the devices with auxdata to set the device names which are used by
clkdev to lookup the clocks.
Signed-off-by: Michael Walle mich...@walle.cc
Signed-off-by: Andrew Lunn and...@lunn.ch
---
arch/arm/boot/dts/kirkwood.dtsi |9 +
arch/arm/mach-kirkwood/board-dt.c |8 +++-
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/kirkwood.dtsi b/arch/arm/boot/dts/kirkwood.dtsi
index 8eab7c4..7d282ab 100644
--- a/arch/arm/boot/dts/kirkwood.dtsi
+++ b/arch/arm/boot/dts/kirkwood.dtsi
@@ -42,6 +42,15 @@
interrupts = 53;
};
+ spi@10600 {
+ compatible = marvell,orion-spi;
+ #address-cells = 1;
+ #size-cells = 0;
+ cell-index = 0;
+ reg = 0x10600 0x28;
+ status = disabled;
+ };
+
nand@300 {
#address-cells = 1;
#size-cells = 1;
diff --git a/arch/arm/mach-kirkwood/board-dt.c
b/arch/arm/mach-kirkwood/board-dt.c
index fa51586..0942139 100644
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-kirkwood/board-dt.c
@@ -26,6 +26,11 @@ static struct of_device_id kirkwood_dt_match_table[]
__initdata = {
{ }
};
+struct of_dev_auxdata kirkwood_auxdata_lookup[] __initdata = {
+ OF_DEV_AUXDATA(marvell,orion-spi, 0xf1010600, orion_spi.0, NULL),
Isn't this -^^ defined somewhere?
This is done about 1/4 of the time (56 / 187) in the kernel. But
honestly, I'd prefer it to be named.
Other than that,
Acked-by: Jason Cooper ja...@lakedaemon.net
+ {},
+};
+
static void __init kirkwood_dt_init(void)
{
pr_info(Kirkwood: %s, TCLK=%d.\n, kirkwood_id(), kirkwood_tclk);
@@ -69,7 +74,8 @@ static void __init kirkwood_dt_init(void)
if (of_machine_is_compatible(raidsonic,ib-nas62x0))
ib62x0_init();
- of_platform_populate(NULL, kirkwood_dt_match_table, NULL, NULL);
+ of_platform_populate(NULL, kirkwood_dt_match_table,
+ kirkwood_auxdata_lookup, NULL);
}
static const char *kirkwood_dt_board_compat[] = {
--
1.7.10
--
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 6/9] ARM: kirkwood: use devicetree for SPI on dreamplug
On Sun, Jun 10, 2012 at 12:31:58PM +0200, Andrew Lunn wrote:
From: Michael Walle mich...@walle.cc
Use the device tree for the SPI driver and partition layout.
Signed-off-by: Michael Walle mich...@walle.cc
Signed-off-by: Andrew Lunn and...@lunn.ch
Acked-by: Jason Cooper ja...@lakedaemon.net
---
arch/arm/boot/dts/kirkwood-dreamplug.dts | 29 +
arch/arm/mach-kirkwood/board-dreamplug.c | 41
--
2 files changed, 29 insertions(+), 41 deletions(-)
diff --git a/arch/arm/boot/dts/kirkwood-dreamplug.dts
b/arch/arm/boot/dts/kirkwood-dreamplug.dts
index a5376b8..d74d1ae 100644
--- a/arch/arm/boot/dts/kirkwood-dreamplug.dts
+++ b/arch/arm/boot/dts/kirkwood-dreamplug.dts
@@ -20,5 +20,34 @@
clock-frequency = 2;
status = ok;
};
+
+ spi@10600 {
+ status = okay;
+
+ m25p40@0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = mx25l1606e;
+ reg = 0;
+ spi-max-frequency = 5000;
+ mode = 0;
+
+ partition@0 {
+ reg = 0x0 0x8;
+ label = u-boot;
+ };
+
+ partition@10 {
+ reg = 0x10 0x1;
+ label = u-boot env;
+ };
+
+ partition@18 {
+ reg = 0x18 0x1;
+ label = dtb;
+ };
+ };
+ };
};
+
};
diff --git a/arch/arm/mach-kirkwood/board-dreamplug.c
b/arch/arm/mach-kirkwood/board-dreamplug.c
index 55e357a..eb0e4d5 100644
--- a/arch/arm/mach-kirkwood/board-dreamplug.c
+++ b/arch/arm/mach-kirkwood/board-dreamplug.c
@@ -14,7 +14,6 @@
#include linux/kernel.h
#include linux/init.h
#include linux/platform_device.h
-#include linux/mtd/partitions.h
#include linux/ata_platform.h
#include linux/mv643xx_eth.h
#include linux/of.h
@@ -36,42 +35,6 @@
#include common.h
#include mpp.h
-struct mtd_partition dreamplug_partitions[] = {
- {
- .name = u-boot,
- .size = SZ_512K,
- .offset = 0,
- },
- {
- .name = u-boot env,
- .size = SZ_64K,
- .offset = SZ_512K + SZ_512K,
- },
- {
- .name = dtb,
- .size = SZ_64K,
- .offset = SZ_512K + SZ_512K + SZ_512K,
- },
-};
-
-static const struct flash_platform_data dreamplug_spi_slave_data = {
- .type = mx25l1606e,
- .name = spi_flash,
- .parts = dreamplug_partitions,
- .nr_parts = ARRAY_SIZE(dreamplug_partitions),
-};
-
-static struct spi_board_info __initdata dreamplug_spi_slave_info[] = {
- {
- .modalias = m25p80,
- .platform_data = dreamplug_spi_slave_data,
- .irq= -1,
- .max_speed_hz = 5000,
- .bus_num= 0,
- .chip_select= 0,
- },
-};
-
static struct mv643xx_eth_platform_data dreamplug_ge00_data = {
.phy_addr = MV643XX_ETH_PHY_ADDR(0),
};
@@ -137,10 +100,6 @@ void __init dreamplug_init(void)
*/
kirkwood_mpp_conf(dreamplug_mpp_config);
- spi_register_board_info(dreamplug_spi_slave_info,
- ARRAY_SIZE(dreamplug_spi_slave_info));
- kirkwood_spi_init();
-
kirkwood_ehci_init();
kirkwood_ge00_init(dreamplug_ge00_data);
kirkwood_ge01_init(dreamplug_ge01_data);
--
1.7.10
--
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 8/9] ARM: Kirkwood: Add DT support for GPIO controllers
On Sun, Jun 10, 2012 at 12:32:00PM +0200, Andrew Lunn wrote:
The GPIO controllers can now be described in DT. Origionally GPIO
controllers were instantiated during IRQ setup. The origional none-DT
nit. non-DT
code has been split out, and is only called if no DT GPIO controllers
are found.
Signed-off-by: Andrew Lunn and...@lunn.ch
Acked-by: Jason Cooper ja...@lakedaemon.net
---
.../devicetree/bindings/gpio/mrvl-gpio.txt | 25 +++
arch/arm/boot/dts/kirkwood.dtsi| 20 ++
arch/arm/mach-kirkwood/irq.c | 20 --
arch/arm/plat-orion/gpio.c | 68
+++-
arch/arm/plat-orion/include/plat/gpio.h|2 +
5 files changed, 126 insertions(+), 9 deletions(-)
diff --git a/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt
b/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt
index 05428f3..d94ebc1 100644
--- a/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt
+++ b/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt
@@ -27,3 +27,28 @@ Example:
interrupt-controller;
#interrupt-cells = 1;
};
+
+* Marvell Orion GPIO Controller
+
+Required properties:
+- compatible : Should be marvell,orion-gpio
+- reg: Address and length of the register set for controller.
+- gpio-controller: So we know this is a gpio controller.
+- gpio-base : Number of first gpio pin.
+- ngpio : How many gpios this controller has.
+- secondary-irq-base : IRQ number base
+
+Optional properties:
+- mask-offset: For SMP Orions, offset for Nth CPU
+
+Example:
+
+ gpio0: gpio@10100 {
+ compatible = marvell,orion-gpio;
+ #gpio-cells = 2;
+ gpio-controller;
+ reg = 0x10100 0x40;
+ gpio-base = 0;
+ ngpio = 32;
+ secondary-irq-base = 64;
+ };
diff --git a/arch/arm/boot/dts/kirkwood.dtsi b/arch/arm/boot/dts/kirkwood.dtsi
index 3091c01..6de66dc 100644
--- a/arch/arm/boot/dts/kirkwood.dtsi
+++ b/arch/arm/boot/dts/kirkwood.dtsi
@@ -18,6 +18,26 @@
#address-cells = 1;
#size-cells = 1;
+ gpio0: gpio@10100 {
+ compatible = marvell,orion-gpio;
+ #gpio-cells = 2;
+ gpio-controller;
+ reg = 0x10100 0x40;
+ gpio-base = 0;
+ ngpio = 32;
+ secondary-irq-base = 64;
+ };
+
+ gpio1: gpio@10140 {
+ compatible = marvell,orion-gpio;
+ #gpio-cells = 2;
+ gpio-controller;
+ reg = 0x10140 0x40;
+ gpio-base = 32;
+ ngpio = 18;
+ secondary-irq-base = 96;
+ };
+
serial@12000 {
compatible = ns16550a;
reg = 0x12000 0x100;
diff --git a/arch/arm/mach-kirkwood/irq.c b/arch/arm/mach-kirkwood/irq.c
index c4c68e5..81340c2 100644
--- a/arch/arm/mach-kirkwood/irq.c
+++ b/arch/arm/mach-kirkwood/irq.c
@@ -24,25 +24,33 @@ static void gpio_irq_handler(unsigned int irq, struct
irq_desc *desc)
orion_gpio_irq_handler((irq - IRQ_KIRKWOOD_GPIO_LOW_0_7) 3);
}
-void __init kirkwood_init_irq(void)
+static void __init kirkwood_init_gpio(void)
{
- orion_irq_init(0, (void __iomem *)(IRQ_VIRT_BASE + IRQ_MASK_LOW_OFF));
- orion_irq_init(32, (void __iomem *)(IRQ_VIRT_BASE + IRQ_MASK_HIGH_OFF));
-
/*
* Initialize gpiolib for GPIOs 0-49.
*/
orion_gpio_init(0, 32, GPIO_LOW_VIRT_BASE, 0,
IRQ_KIRKWOOD_GPIO_START);
+ orion_gpio_init(32, 18, GPIO_HIGH_VIRT_BASE, 0,
+ IRQ_KIRKWOOD_GPIO_START + 32);
+}
+void __init kirkwood_init_irq(void)
+{
+ orion_irq_init(0, (void __iomem *)(IRQ_VIRT_BASE + IRQ_MASK_LOW_OFF));
+ orion_irq_init(32, (void __iomem *)(IRQ_VIRT_BASE + IRQ_MASK_HIGH_OFF));
+
irq_set_chained_handler(IRQ_KIRKWOOD_GPIO_LOW_0_7, gpio_irq_handler);
irq_set_chained_handler(IRQ_KIRKWOOD_GPIO_LOW_8_15, gpio_irq_handler);
irq_set_chained_handler(IRQ_KIRKWOOD_GPIO_LOW_16_23, gpio_irq_handler);
irq_set_chained_handler(IRQ_KIRKWOOD_GPIO_LOW_24_31, gpio_irq_handler);
- orion_gpio_init(32, 18, GPIO_HIGH_VIRT_BASE, 0,
- IRQ_KIRKWOOD_GPIO_START + 32);
irq_set_chained_handler(IRQ_KIRKWOOD_GPIO_HIGH_0_7, gpio_irq_handler);
irq_set_chained_handler(IRQ_KIRKWOOD_GPIO_HIGH_8_15, gpio_irq_handler);
irq_set_chained_handler(IRQ_KIRKWOOD_GPIO_HIGH_16_23,
gpio_irq_handler);
+
+ /* Try initializing the GPIO controllers via DT. If zero
+controllers are found, fall back to hard coded values
Re: [PATCH 9/9] Kirkwood: Add basic device tree support for QNAP TS219.
;
+ label = RootFS2;
+ };
+ partition@0004 {
+ reg = 0x0008 0x0004;
+ label = U-Boot Config;
+ };
+ partition@000c {
+ reg = 0x000c 0x0014;
+ label = NAS Config;
+ };
+ };
+ };
+ };
+};
diff --git a/arch/arm/mach-kirkwood/Kconfig b/arch/arm/mach-kirkwood/Kconfig
index 199764f..8c6a5cd 100644
--- a/arch/arm/mach-kirkwood/Kconfig
+++ b/arch/arm/mach-kirkwood/Kconfig
@@ -47,6 +47,7 @@ config MACH_GURUPLUG
config ARCH_KIRKWOOD_DT
bool Marvell Kirkwood Flattened Device Tree
select USE_OF
+ select SERIAL_OF_PLATFORM
Please remove as previously discussed. I'm in the process of updating
kirkwood_defconfig (it will include this). Thanks.
Other than that,
Acked-by: Jason Cooper ja...@lakedaemon.net
thx,
Jason.
help
Say 'Y' here if you want your kernel to support the
Marvell Kirkwood using flattened device tree.
@@ -80,6 +81,20 @@ config MACH_IB62X0_DT
RaidSonic IB-NAS6210 IB-NAS6220 devices, using
Flattened Device Tree.
+config MACH_TS219_DT
+ bool Device Tree for QNAP TS-110, TS-119, TS-119P+, TS-210, TS-219,
TS-219P and TS-219P+ Turbo NAS
+ select ARCH_KIRKWOOD_DT
+ select ARM_APPENDED_DTB
+ select ARM_ATAG_DTB_COMPAT
+ help
+ Say 'Y' here if you want your kernel to support the QNAP
+ TS-110, TS-119, TS-119P+, TS-210, TS-219, TS-219P and
+ TS-219P+ Turbo NAS devices using Fattened Device Tree.
+ There are two different Device Tree descriptions, depending
+ on if the device is based on an if the board uses the MV6281
+ or MV6282. If you have the wrong one, the buttons will not
+ work.
+
config MACH_TS219
bool QNAP TS-110, TS-119, TS-119P+, TS-210, TS-219, TS-219P and
TS-219P+ Turbo NAS
help
diff --git a/arch/arm/mach-kirkwood/Makefile b/arch/arm/mach-kirkwood/Makefile
index d2b0590..0468b23 100644
--- a/arch/arm/mach-kirkwood/Makefile
+++ b/arch/arm/mach-kirkwood/Makefile
@@ -25,3 +25,4 @@ obj-$(CONFIG_MACH_DREAMPLUG_DT) +=
board-dreamplug.o
obj-$(CONFIG_MACH_ICONNECT_DT) += board-iconnect.o
obj-$(CONFIG_MACH_DLINK_KIRKWOOD_DT) += board-dnskw.o
obj-$(CONFIG_MACH_IB62X0_DT) += board-ib62x0.o
+obj-$(CONFIG_MACH_TS219_DT) += board-ts219.o
diff --git a/arch/arm/mach-kirkwood/Makefile.boot
b/arch/arm/mach-kirkwood/Makefile.boot
index 02edbdf..4a1f66a 100644
--- a/arch/arm/mach-kirkwood/Makefile.boot
+++ b/arch/arm/mach-kirkwood/Makefile.boot
@@ -7,3 +7,4 @@ dtb-$(CONFIG_MACH_DLINK_KIRKWOOD_DT) += kirkwood-dns320.dtb
dtb-$(CONFIG_MACH_DLINK_KIRKWOOD_DT) += kirkwood-dns325.dtb
dtb-$(CONFIG_MACH_ICONNECT_DT) += kirkwood-iconnect.dtb
dtb-$(CONFIG_MACH_IB62X0_DT) += kirkwood-ib62x0.dtb
+dtb-$(CONFIG_MACH_TS219_DT) += kirkwood-qnap-ts219.dtb
diff --git a/arch/arm/mach-kirkwood/board-dt.c
b/arch/arm/mach-kirkwood/board-dt.c
index 5aa025d..5dfdfc3 100644
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-kirkwood/board-dt.c
@@ -76,6 +76,9 @@ static void __init kirkwood_dt_init(void)
if (of_machine_is_compatible(raidsonic,ib-nas62x0))
ib62x0_init();
+ if (of_machine_is_compatible(qnap,ts219))
+ qnap_dt_ts219_init();
+
of_platform_populate(NULL, kirkwood_dt_match_table,
kirkwood_auxdata_lookup, NULL);
}
@@ -86,6 +89,7 @@ static const char *kirkwood_dt_board_compat[] = {
dlink,dns-325,
iom,iconnect,
raidsonic,ib-nas62x0,
+ qnap,ts219,
NULL
};
diff --git a/arch/arm/mach-kirkwood/board-ts219.c
b/arch/arm/mach-kirkwood/board-ts219.c
new file mode 100644
index 000..0a70b77
--- /dev/null
+++ b/arch/arm/mach-kirkwood/board-ts219.c
@@ -0,0 +1,86 @@
+/*
+ *
+ * QNAP TS-11x/TS-21x Turbo NAS Board Setup via DT
+ *
+ * Copyright (C) 2012 Andrew Lunn and...@lunn.ch
+ *
+ * Based on the board file ts219-setup.c:
+ *
+ * Copyright (C) 2009 Martin Michlmayr t...@cyrius.com
+ * Copyright (C) 2008 Byron Bradley byron.bbrad...@gmail.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/platform_device.h
+#include linux/mv643xx_eth.h
+#include linux/ata_platform.h
+#include linux/gpio_keys.h
+#include linux/input.h
+#include asm/mach-types.h
+#include asm/mach/arch.h
+#include mach/kirkwood.h
+#include common.h
