[PATCH v2 0/7] Add cros_ec changes for newer boards

[PATCH v2 0/7] Add cros_ec changes for newer boards

[Doug Anderson]

This series adds the most critical cros_ec changes for newer boards
using cros_ec.  Specifically:
* Fixes timing/locking issues with the previously upstreamed (but
  never used upstream) cros_ec_spi driver.
* Updates the cros_ec header file to the latest version which allows
  us to use newer EC features like i2c tunneling.
* Adds an i2c tunnel driver to allow communication to the EC's i2c
  devices.

This _doesn't_ get the EC driver fully up to speed with what's in the
current Chromium OS trees.  There are a whole slew of cleanup patches
there, an addition of an LPC transport mode, and exports of functions
to userspace.  Once these patches land and we have functionality we
can continue to pick more cleanup patches.

Changes in v2:
- Update tunnel binding as per swarren
- Removed i2c20 alias for i2c tunnel

Bill Richardson (1):
  mfd: cros_ec: Sync to the latest cros_ec_commands.h from EC sources

David Hendricks (1):
  mfd: cros_ec: spi: calculate delay between transfers correctly

Doug Anderson (5):
  mfd: cros_ec: spi: Add mutex to cros_ec_spi
  mfd: cros_ec: spi: Make the cros_ec_spi timeout more reliable
  mfd: cros_ec: spi: Increase cros_ec_spi deadline from 5ms to 100ms
  i2c: ChromeOS EC tunnel driver
  ARM: tegra: Add the EC i2c tunnel to tegra124-venice2

 .../devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt |   39 +
 arch/arm/boot/dts/tegra124-venice2.dts             |   26 +
 drivers/i2c/busses/Kconfig                         |    9 +
 drivers/i2c/busses/Makefile                        |    1 +
 drivers/i2c/busses/i2c-cros-ec-tunnel.c            |  304 ++++++
 drivers/mfd/cros_ec.c                              |    7 +-
 drivers/mfd/cros_ec_spi.c                          |   67 +-
 include/linux/mfd/cros_ec.h                        |    4 +-
 include/linux/mfd/cros_ec_commands.h               | 1128 ++++++++++++++++++--
 9 files changed, 1493 insertions(+), 92 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt
 create mode 100644 drivers/i2c/busses/i2c-cros-ec-tunnel.c

-- 
1.9.1.423.g4596e3a

[PATCH v2 7/7] ARM: tegra: Add the EC i2c tunnel to tegra124-venice2

[Doug Anderson]

This adds the EC i2c tunnel (and devices under it) to the
tegra124-venice2 device tree.

Signed-off-by: Doug Anderson <dianders@chromium.org>
Tested-by: Andrew Bresticker <abrestic@chromium.org>
Tested-by: Stephen Warren <swarren@nvidia.com>
---
Changes in v2:
- Removed i2c20 alias for i2c tunnel

 arch/arm/boot/dts/tegra124-venice2.dts | 26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/arch/arm/boot/dts/tegra124-venice2.dts b/arch/arm/boot/dts/tegra124-venice2.dts
index c17283c..89cf776 100644
--- a/arch/arm/boot/dts/tegra124-venice2.dts
+++ b/arch/arm/boot/dts/tegra124-venice2.dts
@@ -813,6 +813,32 @@
 
 			google,cros-ec-spi-msg-delay = <2000>;
 
+			i2c-tunnel {
+				compatible = "google,cros-ec-i2c-tunnel";
+				#address-cells = <1>;
+				#size-cells = <0>;
+
+				google,remote-bus = <0>;
+
+				charger: bq24735 at 9 {
+					compatible = "ti,bq24735";
+					reg = <0x9>;
+					interrupt-parent = <&gpio>;
+					interrupts = <TEGRA_GPIO(J, 0)
+							GPIO_ACTIVE_HIGH>;
+					ti,ac-detect-gpios = <&gpio
+							TEGRA_GPIO(J, 0)
+							GPIO_ACTIVE_HIGH>;
+				};
+
+				battery: sbs-battery at b {
+					compatible = "sbs,sbs-battery";
+					reg = <0xb>;
+					sbs,i2c-retry-count = <2>;
+					sbs,poll-retry-count = <1>;
+				};
+			};
+
 			cros-ec-keyb {
 				compatible = "google,cros-ec-keyb";
 				keypad,num-rows = <8>;
-- 
1.9.1.423.g4596e3a

[PATCH v2 0/7] Add cros_ec changes for newer boards

[Lee Jones]

On Tue, 22 Apr 2014, Doug Anderson wrote:

> This series adds the most critical cros_ec changes for newer boards
> using cros_ec.  Specifically:
> * Fixes timing/locking issues with the previously upstreamed (but
>   never used upstream) cros_ec_spi driver.
> * Updates the cros_ec header file to the latest version which allows
>   us to use newer EC features like i2c tunneling.
> * Adds an i2c tunnel driver to allow communication to the EC's i2c
>   devices.
> 
> This _doesn't_ get the EC driver fully up to speed with what's in the
> current Chromium OS trees.  There are a whole slew of cleanup patches
> there, an addition of an LPC transport mode, and exports of functions
> to userspace.  Once these patches land and we have functionality we
> can continue to pick more cleanup patches.
> 
> Changes in v2:
> - Update tunnel binding as per swarren
> - Removed i2c20 alias for i2c tunnel
> 
> Bill Richardson (1):
>   mfd: cros_ec: Sync to the latest cros_ec_commands.h from EC sources
> 
> David Hendricks (1):
>   mfd: cros_ec: spi: calculate delay between transfers correctly
> 
> Doug Anderson (5):
>   mfd: cros_ec: spi: Add mutex to cros_ec_spi
>   mfd: cros_ec: spi: Make the cros_ec_spi timeout more reliable
>   mfd: cros_ec: spi: Increase cros_ec_spi deadline from 5ms to 100ms
>   i2c: ChromeOS EC tunnel driver
>   ARM: tegra: Add the EC i2c tunnel to tegra124-venice2
> 
>  .../devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt |   39 +
>  arch/arm/boot/dts/tegra124-venice2.dts             |   26 +
>  drivers/i2c/busses/Kconfig                         |    9 +
>  drivers/i2c/busses/Makefile                        |    1 +
>  drivers/i2c/busses/i2c-cros-ec-tunnel.c            |  304 ++++++
>  drivers/mfd/cros_ec.c                              |    7 +-
>  drivers/mfd/cros_ec_spi.c                          |   67 +-
>  include/linux/mfd/cros_ec.h                        |    4 +-
>  include/linux/mfd/cros_ec_commands.h               | 1128 ++++++++++++++++++--
>  9 files changed, 1493 insertions(+), 92 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt
>  create mode 100644 drivers/i2c/busses/i2c-cros-ec-tunnel.c

Need to wait for the ARM, DT and I2C guys to review, at which point
I'll be happy to take in and supply a branch for them to pull from if
required. If there are no _true_ dependencies and the MFD changes can
be added independently without fear of build breakages, let me know
and I'll apply them separately.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[PATCH v2 0/7] Add cros_ec changes for newer boards

[Stephen Warren]

On 04/23/2014 06:32 AM, Lee Jones wrote:
> On Tue, 22 Apr 2014, Doug Anderson wrote:
> 
>> This series adds the most critical cros_ec changes for newer boards
>> using cros_ec.  Specifically:
>> * Fixes timing/locking issues with the previously upstreamed (but
>>   never used upstream) cros_ec_spi driver.
>> * Updates the cros_ec header file to the latest version which allows
>>   us to use newer EC features like i2c tunneling.
>> * Adds an i2c tunnel driver to allow communication to the EC's i2c
>>   devices.
>>
>> This _doesn't_ get the EC driver fully up to speed with what's in the
>> current Chromium OS trees.  There are a whole slew of cleanup patches
>> there, an addition of an LPC transport mode, and exports of functions
>> to userspace.  Once these patches land and we have functionality we
>> can continue to pick more cleanup patches.
...
> Need to wait for the ARM, DT and I2C guys to review, at which point
> I'll be happy to take in and supply a branch for them to pull from if
> required. If there are no _true_ dependencies and the MFD changes can
> be added independently without fear of build breakages, let me know
> and I'll apply them separately.

I believe there aren't direct dependencies between the patches. So, the
MFD patches can be applied to the MFD tree and the DT patch applied to
the Tegra tree. I'm simply waiting for the MFD patches to be applied
before applying the DT patch so that I know the DT binding definition is
fully accepted before applying a patch that uses it.

[PATCH v2 0/7] Add cros_ec changes for newer boards

[Doug Anderson]

Hi,

On Wed, Apr 23, 2014 at 9:20 AM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 04/23/2014 06:32 AM, Lee Jones wrote:
>> On Tue, 22 Apr 2014, Doug Anderson wrote:
>>
>>> This series adds the most critical cros_ec changes for newer boards
>>> using cros_ec.  Specifically:
>>> * Fixes timing/locking issues with the previously upstreamed (but
>>>   never used upstream) cros_ec_spi driver.
>>> * Updates the cros_ec header file to the latest version which allows
>>>   us to use newer EC features like i2c tunneling.
>>> * Adds an i2c tunnel driver to allow communication to the EC's i2c
>>>   devices.
>>>
>>> This _doesn't_ get the EC driver fully up to speed with what's in the
>>> current Chromium OS trees.  There are a whole slew of cleanup patches
>>> there, an addition of an LPC transport mode, and exports of functions
>>> to userspace.  Once these patches land and we have functionality we
>>> can continue to pick more cleanup patches.
> ...
>> Need to wait for the ARM, DT and I2C guys to review, at which point
>> I'll be happy to take in and supply a branch for them to pull from if
>> required. If there are no _true_ dependencies and the MFD changes can
>> be added independently without fear of build breakages, let me know
>> and I'll apply them separately.
>
> I believe there aren't direct dependencies between the patches. So, the
> MFD patches can be applied to the MFD tree and the DT patch applied to
> the Tegra tree. I'm simply waiting for the MFD patches to be applied
> before applying the DT patch so that I know the DT binding definition is
> fully accepted before applying a patch that uses it.

All of the MFD patches are safe to apply and in pretty much arbitrary
order.  The strong dependencies in the chain are:

* We need patch #5 (mfd: cros_ec: Sync to the latest
cros_ec_commands.h from EC sources) before the i2c tunnel can compile.

* As Stephen says, he shouldn't apply the device tree until we're
confident that the bindings are right.  However there's no strong
dependency otherwise.

* Patches #1 #2 and #3 are simply reliability fixes.  Those could land
at any point in time and will improve other users of cros_ec_spi (like
the keyboard on tegra124-venice2).

* Patch #4 can apply any time with no issues.  Without it large i2c
tunnel transfers won't work, but that's not a terrible problem (all
normal transfers are small).

---

All that being said, I'd request that you merge patches #1-#4 as soon
as you can and make sure you can provide a way that Wolfram can pull
them (or at least patch #4) into his i2c tree to keep them applying
when he is ready to land #5.

-Doug

[PATCH v2 0/7] Add cros_ec changes for newer boards

[Doug Anderson]

Hi,

On Wed, Apr 23, 2014 at 9:32 AM, Doug Anderson <dianders@chromium.org> wrote:
> Hi,
>
> On Wed, Apr 23, 2014 at 9:20 AM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> On 04/23/2014 06:32 AM, Lee Jones wrote:
>>> On Tue, 22 Apr 2014, Doug Anderson wrote:
>>>
>>>> This series adds the most critical cros_ec changes for newer boards
>>>> using cros_ec.  Specifically:
>>>> * Fixes timing/locking issues with the previously upstreamed (but
>>>>   never used upstream) cros_ec_spi driver.
>>>> * Updates the cros_ec header file to the latest version which allows
>>>>   us to use newer EC features like i2c tunneling.
>>>> * Adds an i2c tunnel driver to allow communication to the EC's i2c
>>>>   devices.
>>>>
>>>> This _doesn't_ get the EC driver fully up to speed with what's in the
>>>> current Chromium OS trees.  There are a whole slew of cleanup patches
>>>> there, an addition of an LPC transport mode, and exports of functions
>>>> to userspace.  Once these patches land and we have functionality we
>>>> can continue to pick more cleanup patches.
>> ...
>>> Need to wait for the ARM, DT and I2C guys to review, at which point
>>> I'll be happy to take in and supply a branch for them to pull from if
>>> required. If there are no _true_ dependencies and the MFD changes can
>>> be added independently without fear of build breakages, let me know
>>> and I'll apply them separately.
>>
>> I believe there aren't direct dependencies between the patches. So, the
>> MFD patches can be applied to the MFD tree and the DT patch applied to
>> the Tegra tree. I'm simply waiting for the MFD patches to be applied
>> before applying the DT patch so that I know the DT binding definition is
>> fully accepted before applying a patch that uses it.
>
> All of the MFD patches are safe to apply and in pretty much arbitrary
> order.  The strong dependencies in the chain are:
>
> * We need patch #5 (mfd: cros_ec: Sync to the latest
> cros_ec_commands.h from EC sources) before the i2c tunnel can compile.
>
> * As Stephen says, he shouldn't apply the device tree until we're
> confident that the bindings are right.  However there's no strong
> dependency otherwise.
>
> * Patches #1 #2 and #3 are simply reliability fixes.  Those could land
> at any point in time and will improve other users of cros_ec_spi (like
> the keyboard on tegra124-venice2).
>
> * Patch #4 can apply any time with no issues.  Without it large i2c
> tunnel transfers won't work, but that's not a terrible problem (all
> normal transfers are small).
>
> ---
>
> All that being said, I'd request that you merge patches #1-#4 as soon
> as you can and make sure you can provide a way that Wolfram can pull
> them (or at least patch #4) into his i2c tree to keep them applying
> when he is ready to land #5.

Oops, I missed a patch.  Let me say that again.

Patch #5 (latest ec commands) can also apply at any time with no
issues, but it's needed for patch #6 (the tunnel) to compile.

All that being said, I'd request that you merge patches #1-#5 as soon
as you can and make sure you can provide a way that Wolfram can pull
them (or at least patch #5) into his i2c tree to keep them applying
when he is ready to land #6.

[PATCH v2 0/7] Add cros_ec changes for newer boards

[Lee Jones]

[...]

> >>> Need to wait for the ARM, DT and I2C guys to review, at which point
> >>> I'll be happy to take in and supply a branch for them to pull from if
> >>> required. If there are no _true_ dependencies and the MFD changes can
> >>> be added independently without fear of build breakages, let me know
> >>> and I'll apply them separately.
> >>
> >> I believe there aren't direct dependencies between the patches. So, the
> >> MFD patches can be applied to the MFD tree and the DT patch applied to
> >> the Tegra tree. I'm simply waiting for the MFD patches to be applied
> >> before applying the DT patch so that I know the DT binding definition is
> >> fully accepted before applying a patch that uses it.
> >
> > All of the MFD patches are safe to apply and in pretty much arbitrary
> > order.  The strong dependencies in the chain are:
> >
> > * We need patch #5 (mfd: cros_ec: Sync to the latest
> > cros_ec_commands.h from EC sources) before the i2c tunnel can compile.
> >
> > * As Stephen says, he shouldn't apply the device tree until we're
> > confident that the bindings are right.  However there's no strong
> > dependency otherwise.
> >
> > * Patches #1 #2 and #3 are simply reliability fixes.  Those could land
> > at any point in time and will improve other users of cros_ec_spi (like
> > the keyboard on tegra124-venice2).
> >
> > * Patch #4 can apply any time with no issues.  Without it large i2c
> > tunnel transfers won't work, but that's not a terrible problem (all
> > normal transfers are small).
> 
> Patch #5 (latest ec commands) can also apply at any time with no
> issues, but it's needed for patch #6 (the tunnel) to compile.
> 
> All that being said, I'd request that you merge patches #1-#5 as soon
> as you can and make sure you can provide a way that Wolfram can pull
> them (or at least patch #5) into his i2c tree to keep them applying
> when he is ready to land #6.

Very well. So if I can obtain Wolfram's Ack, I can apply the MFD
changes along with patch #6 and supply him with a branch.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[PATCH v2 0/7] Add cros_ec changes for newer boards

[Doug Anderson]

Lee,

On Mon, Apr 28, 2014 at 2:19 AM, Lee Jones <lee.jones@linaro.org> wrote:
> [...]
>
>> >>> Need to wait for the ARM, DT and I2C guys to review, at which point
>> >>> I'll be happy to take in and supply a branch for them to pull from if
>> >>> required. If there are no _true_ dependencies and the MFD changes can
>> >>> be added independently without fear of build breakages, let me know
>> >>> and I'll apply them separately.
>> >>
>> >> I believe there aren't direct dependencies between the patches. So, the
>> >> MFD patches can be applied to the MFD tree and the DT patch applied to
>> >> the Tegra tree. I'm simply waiting for the MFD patches to be applied
>> >> before applying the DT patch so that I know the DT binding definition is
>> >> fully accepted before applying a patch that uses it.
>> >
>> > All of the MFD patches are safe to apply and in pretty much arbitrary
>> > order.  The strong dependencies in the chain are:
>> >
>> > * We need patch #5 (mfd: cros_ec: Sync to the latest
>> > cros_ec_commands.h from EC sources) before the i2c tunnel can compile.
>> >
>> > * As Stephen says, he shouldn't apply the device tree until we're
>> > confident that the bindings are right.  However there's no strong
>> > dependency otherwise.
>> >
>> > * Patches #1 #2 and #3 are simply reliability fixes.  Those could land
>> > at any point in time and will improve other users of cros_ec_spi (like
>> > the keyboard on tegra124-venice2).
>> >
>> > * Patch #4 can apply any time with no issues.  Without it large i2c
>> > tunnel transfers won't work, but that's not a terrible problem (all
>> > normal transfers are small).
>>
>> Patch #5 (latest ec commands) can also apply at any time with no
>> issues, but it's needed for patch #6 (the tunnel) to compile.
>>
>> All that being said, I'd request that you merge patches #1-#5 as soon
>> as you can and make sure you can provide a way that Wolfram can pull
>> them (or at least patch #5) into his i2c tree to keep them applying
>> when he is ready to land #6.
>
> Very well. So if I can obtain Wolfram's Ack, I can apply the MFD
> changes along with patch #6 and supply him with a branch.

Can you explain the reason to wait for Wolfram's Ack before applying
#1 - #5?  I would think:

1. Create a topic branch.
2. Apply patches 1-5 to the topic branch
3. Merge the topic branch to your for-next branch

When Wolfram wants to take patch #6, he can either:
A. Pull your topic branch
B. If it's been long enough, patches will already be in ToT and no extra work.

If I understand correctly, using a topic branch and doing merges /
pulls means that you can provide Wolfram with stable git hashes when
he needs them and there will be no merge conflicts.

Patches #1 - #5 are bonafide bugfixes irrespective of the i2c tunnel.

-Doug

[PATCH v2 0/7] Add cros_ec changes for newer boards

[Lee Jones]

> >> >>> Need to wait for the ARM, DT and I2C guys to review, at which point
> >> >>> I'll be happy to take in and supply a branch for them to pull from if
> >> >>> required. If there are no _true_ dependencies and the MFD changes can
> >> >>> be added independently without fear of build breakages, let me know
> >> >>> and I'll apply them separately.
> >> >>
> >> >> I believe there aren't direct dependencies between the patches. So, the
> >> >> MFD patches can be applied to the MFD tree and the DT patch applied to
> >> >> the Tegra tree. I'm simply waiting for the MFD patches to be applied
> >> >> before applying the DT patch so that I know the DT binding definition is
> >> >> fully accepted before applying a patch that uses it.
> >> >
> >> > All of the MFD patches are safe to apply and in pretty much arbitrary
> >> > order.  The strong dependencies in the chain are:
> >> >
> >> > * We need patch #5 (mfd: cros_ec: Sync to the latest
> >> > cros_ec_commands.h from EC sources) before the i2c tunnel can compile.
> >> >
> >> > * As Stephen says, he shouldn't apply the device tree until we're
> >> > confident that the bindings are right.  However there's no strong
> >> > dependency otherwise.
> >> >
> >> > * Patches #1 #2 and #3 are simply reliability fixes.  Those could land
> >> > at any point in time and will improve other users of cros_ec_spi (like
> >> > the keyboard on tegra124-venice2).
> >> >
> >> > * Patch #4 can apply any time with no issues.  Without it large i2c
> >> > tunnel transfers won't work, but that's not a terrible problem (all
> >> > normal transfers are small).
> >>
> >> Patch #5 (latest ec commands) can also apply at any time with no
> >> issues, but it's needed for patch #6 (the tunnel) to compile.
> >>
> >> All that being said, I'd request that you merge patches #1-#5 as soon
> >> as you can and make sure you can provide a way that Wolfram can pull
> >> them (or at least patch #5) into his i2c tree to keep them applying
> >> when he is ready to land #6.
> >
> > Very well. So if I can obtain Wolfram's Ack, I can apply the MFD
> > changes along with patch #6 and supply him with a branch.
> 
> Can you explain the reason to wait for Wolfram's Ack before applying
> #1 - #5?  I would think:
> 
> 1. Create a topic branch.
> 2. Apply patches 1-5 to the topic branch
> 3. Merge the topic branch to your for-next branch
> 
> When Wolfram wants to take patch #6, he can either:
> A. Pull your topic branch
> B. If it's been long enough, patches will already be in ToT and no extra work.
> 
> If I understand correctly, using a topic branch and doing merges /
> pulls means that you can provide Wolfram with stable git hashes when
> he needs them and there will be no merge conflicts.

I don't use TBs for MFD yet, as I've never seen the need.  The current
WoW is to only create extra branches when I have patch{es, sets} to
share.  If I start using a more TB focused methodology it will be
insinuated that the branches are stable - I like the fact that this is
_not_ the case.  Currently I am able to rebase, rework and reorder the
repo as and when I see fit, and do regularly. Except the IBs of course.

> Patches #1 - #5 are bonafide bugfixes irrespective of the i2c tunnel.

I only want to create an IB if I know it's going to be used, else I'd
prefer the patches remain transient.  Why are you so keen to rush into
having these patches applied?  They _will_ make it into v3.15, whether
they are applied immediately or after a length of time (in the case
that Wolfram does not respond).

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[PATCH v2 0/7] Add cros_ec changes for newer boards

[Doug Anderson]

Lee,

On Tue, Apr 29, 2014 at 1:21 AM, Lee Jones <lee.jones@linaro.org> wrote:
> I don't use TBs for MFD yet, as I've never seen the need.  The current
> WoW is to only create extra branches when I have patch{es, sets} to
> share.  If I start using a more TB focused methodology it will be
> insinuated that the branches are stable - I like the fact that this is
> _not_ the case.  Currently I am able to rebase, rework and reorder the
> repo as and when I see fit, and do regularly. Except the IBs of course.

OK.

>> Patches #1 - #5 are bonafide bugfixes irrespective of the i2c tunnel.
>
> I only want to create an IB if I know it's going to be used, else I'd
> prefer the patches remain transient.  Why are you so keen to rush into
> having these patches applied?  They _will_ make it into v3.15, whether
> they are applied immediately or after a length of time (in the case
> that Wolfram does not respond).

No strong reason, and it's actually not even a huge deal if they make
it to 3.15 or in 3.16.  Having outstanding patches simply increases
the number of things that I need to keep track of / check up on.  If
patches are good to go and reviewed I like to get them landed.

Another reason I'd love to see patches landed sooner is that it will
unblock me sending the next set of patches up.  I collected all of the
most important patches in this series, but there are a bunch of other
patches in our tree that would be nice to eventually send up.  At the
moment I'm in a position where I can dedicate a reasonable amount of
time to upstreaming.  It's likely that before long I will get sucked
into tight deadlines and will have to squeeze upstreaming in among
other priorities.

I see a response from Wolfram now, so I'll spin a V2 in the next day
or two with changes to the tunnel driver.  I'm at ELC so my hacking
time may be limited.

-Doug