On Thursday 17 December 2015 13:01:57 Wolfram Sang wrote:
> On Mon, Dec 14, 2015 at 11:27:22PM +0100, Arnd Bergmann wrote:
> > On Monday 14 December 2015 14:52:06 Wolfram Sang wrote:
> > > > > What about not ifdeffing the inline function and keep the build error
> &g
On Thursday 17 December 2015 20:40:17 Wolfram Sang wrote:
> > > My conclusion for now is:
> > >
> > > There needs something to be done surely, but currently I don't have the
> > > bandwidth to do it or even play around with it. I am not fully happy
> > > with your patches as well because
On Sunday 13 December 2015 10:09:59 Wolfram Sang wrote:
>
> What about not ifdeffing the inline function and keep the build error
> whenever someone uses it without I2C_SLAVE being selected?
The inline function is only added there for the case that I2C_SLAVE is
disabled, so that would be
On Monday 14 December 2015 14:52:06 Wolfram Sang wrote:
> > > What about not ifdeffing the inline function and keep the build error
> > > whenever someone uses it without I2C_SLAVE being selected?
> >
> > The inline function is only added there for the case that I2C_SLAVE is
> > disabled, so that
On Saturday 12 December 2015 17:20:57 Wolfram Sang wrote:
> Hi Arnd,
>
> thanks for looking into this, but I don't get your point yet.
>
> > The slave_cb callback function is supposed to set the 'value'
> > here,
>
> Only if a master wants to READ from us.
Right, and can this never fail?
> >
On Thursday 10 December 2015 14:34:46 Wolfram Sang wrote:
> On Thu, Dec 10, 2015 at 02:14:49PM +0100, Arnd Bergmann wrote:
> > The emev2 driver stopped compiling in today's linux-next kernel:
> >
> > drivers/i2c/busses/i2c-emev2.c: In function 'em_i2c_slave_irq':
> > d
-by: Arnd Bergmann <a...@arndb.de>
Fixes: c31d0a00021d ("i2c: emev2: add slave support")
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 69c46fe13777..1c8d53f34dd3 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -985,7 +985,6 @@ c
On Thursday 10 December 2015 22:54:25 kbuild test robot wrote:
>
>In file included from arch/x86/include/asm/realmode.h:5:0,
> from arch/x86/include/asm/acpi.h:33,
> from arch/x86/include/asm/fixmap.h:19,
> from
On Tuesday 24 November 2015 12:22:57 Andy Shevchenko wrote:
> +static struct property_entry uart_properties[] = {
> + PROPERTY_ENTRY_U32("reg-io-width", 4),
> + PROPERTY_ENTRY_U32("reg-shift", 2),
> + PROPERTY_ENTRY_U8("snps,uart-16550-compatible", 1),
> + { },
>
If I
On Tuesday 24 November 2015 12:22:46 Andy Shevchenko wrote:
> This series includes few logical sets that bring a support of non-ACPI
> platforms for Intel Skylake.
>
> First part is a refactoring of built-in device properties support:
> - keep single value inside the structure
> - provide
reference to `i2c_del_driver'
Signed-off-by: Arnd Bergmann <a...@arndb.de>
Fixes: 6bd03ce3c12a ("power: bq27xxx_battery: Remove unneeded dependency in
Kconfig")
---
The bug was originally found and fixed by Xiong Zhou, but Andrew Davis
broke it again by reverting the fix.
I found it
On Monday 09 November 2015 15:23:03 Andrew F. Davis wrote:
> Check if I2C core has been built as a module when BATTERY_BQ27XXX
> is built-in. If so disable I2C functionality.
>
> Fixes: 6bd03ce3c12a ("power: bq27xxx_battery: Remove unneeded dependency in
> Kconfig")
>
On Monday 09 November 2015 10:56:13 Andrew F. Davis wrote:
> On 11/09/2015 07:50 AM, Arnd Bergmann wrote:
> Nothing enabled by BATTERY_BQ27XXX depends on I2C, this workaround is not
> correct as it prevents BATTERY_BQ27XXX from being built-in when I2C is a
> module, there
accordingly.
Signed-off-by: Arnd Bergmann <a...@arndb.de>
Fixes: 6ad6fde3970c ("i2c: designware: Rename platform driver probe and PM
functions")
---
Found on ARM randconfig builds
diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c
b/drivers/i2c/busses/i2c-designware-platdrv.c
in
On Thursday 23 April 2015 11:07:08 Feng Kan wrote:
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id xgene_slimpro_i2c_acpi_ids[] = {
+ {PRP0001, 0},
+ {}
+};
+MODULE_DEVICE_TABLE(acpi, slimpro_acpi_ids);
+#endif
Sorry, but this is wrong: The PRP0001 name is meant for
On Friday 13 March 2015 11:59:58 Jayachandran C wrote:
+- compatible : should be netlogic,xlp9xx-i2c
Use a real model number here, not a wildcard.
Also, please send the binding as a separate patch from the driver.
Arnd
--
To unsubscribe from this list: send the line unsubscribe
On Tuesday 24 February 2015 22:32:57 Chen-Yu Tsai wrote:
On Tue, Feb 24, 2015 at 10:17 PM, Arnd Bergmann a...@arndb.de wrote:
On Tuesday 24 February 2015 22:01:26 Chen-Yu Tsai wrote:
On Tue, Feb 24, 2015 at 6:37 PM, Arnd Bergmann a...@arndb.de wrote:
On Tuesday 24 February 2015 18:29:02
On Tuesday 24 February 2015 18:29:02 Chen-Yu Tsai wrote:
+ rsb@01f03400 {
+ compatible = allwinner,sun8i-a23-rsb;
+ reg = 0x01f03400 0x400;
+ interrupts = 0 39 4;
+ clocks = apb0_gates 3;
+ clock-frequency =
On Tuesday 24 February 2015 22:01:26 Chen-Yu Tsai wrote:
On Tue, Feb 24, 2015 at 6:37 PM, Arnd Bergmann a...@arndb.de wrote:
On Tuesday 24 February 2015 18:29:02 Chen-Yu Tsai wrote:
+ rsb@01f03400 {
+ compatible = allwinner,sun8i-a23-rsb;
+ reg
On Friday 09 January 2015 10:56:51 Feng Kan wrote:
On Tue, Nov 11, 2014 at 1:51 PM, Arnd Bergmann a...@arndb.de wrote:
On Tuesday 07 October 2014 17:06:47 Feng Kan wrote:
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 2e45ae3..a03042c 100644
--- a/drivers/i2c
On Friday 21 November 2014 14:44:32 Ludovic Desroches wrote:
If dma controller is not probed, defer i2c probe.
Signed-off-by: Ludovic Desroches ludovic.desroc...@atmel.com
---
Reviewed-by: Arnd Bergmann a...@arndb.de
Arnd,
It's a combination of the first patch I sent and yours
probe case.
Signed-off-by: Arnd Bergmann a...@arndb.de
diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c
index 917d54588d95..534f4c07bfb6 100644
--- a/drivers/i2c/busses/i2c-at91.c
+++ b/drivers/i2c/busses/i2c-at91.c
@@ -72,8 +72,6 @@ struct at91_twi_pdata
On Tuesday 07 October 2014 17:06:48 Feng Kan wrote:
Add APM X-Gene platform SLIMpro I2C driver documentation.
Don't just repeat the subject line, explain what this is for.
Signed-off-by: Feng Kan f...@apm.com
Signed-off-by: Hieu Le h...@apm.com
---
On Tuesday 07 October 2014 17:06:47 Feng Kan wrote:
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 2e45ae3..a03042c 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -1009,6 +1009,15 @@ config I2C_CROS_EC_TUNNEL
connected there.
On Sunday 28 September 2014 12:22:09 Zhangfei Gao wrote:
+
+ i2c0: i2c@b1 {
+ compatible = hisilicon,hix5hd2-i2c;
+ reg = 0xb1 0x1000;
+ interrupts = 0 38 4;
+ clocks = clock
On Tuesday 30 September 2014 17:25:25 zhangfei wrote:
On 09/30/2014 05:01 PM, Arnd Bergmann wrote:
On Sunday 28 September 2014 12:22:07 Zhangfei Gao wrote:
+
+Required properties:
+- compatible: Must be hisilicon,hix5hd2-i2c
+ Specifically, the following versions of the chipset
On Wednesday 20 August 2014, Daniel Baluta wrote:
From: Octavian Purdila octavian.purd...@intel.com
This patch implements the USB part of the Diolan USB-I2C/SPI/GPIO
Master Adapter DLN-2. Details about the device can be found here:
https://www.diolan.com/i2c/i2c_interface.html.
On Wednesday 11 June 2014 09:52:52 Boris BREZILLON wrote:
You mean in my commit message ?
I thought it was already explaining the subtle differences between P2WI
and the SMBus protocols.
What would you like me to add to this explanation ?
Something about the I2C to P2WI initialization part
On Tuesday 10 June 2014 15:47:16 Boris BREZILLON wrote:
+config I2C_SUN6I_P2WI
+ tristate Allwinner sun6i internal P2WI controller
+ depends on ARCH_SUNXI
+ help
+ If you say yes to this option, support will be included for the
+ P2WI (Push/Pull 2 Wire
On Tuesday 10 June 2014 16:36:04 Maxime Ripard wrote:
On Tue, Jun 10, 2014 at 03:54:56PM +0200, Arnd Bergmann wrote:
On Tuesday 10 June 2014 15:47:16 Boris BREZILLON wrote:
+config I2C_SUN6I_P2WI
+ tristate Allwinner sun6i internal P2WI controller
+ depends
-by: Arnd Bergmann a...@arndb.de
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Linus Walleij linus.wall...@linaro.org
Cc: Wolfram Sang w...@the-dreams.de
diff --git a/drivers/i2c/muxes/Kconfig b/drivers/i2c/muxes/Kconfig
index f7f9865b..f6d313e 100644
--- a/drivers/i2c/muxes/Kconfig
On Thursday 05 June 2014 12:56:08 Laurent Pinchart wrote:
On Thursday 05 June 2014 12:44:47 Arnd Bergmann wrote:
commit 4807e8459bce (i2c: mux: pca954x: Use the descriptor-based GPIO
API) moved this driver over to the gpio descriptor API, which means
we now have a dependency on GPIOLIB
, although I do wonder whether we should just
remove it, as it has clearly never worked.
I agree with removing it since nobody showed interest in Arnd's fixup
patch.
Reported-by: Arnd Bergmann a...@arndb.de
Signed-off-by: Wolfram Sang w...@the-dreams.de
Cc: Wan ZongShun mcuos@gmail.org
On Wednesday 14 May 2014 18:27:25 Wolfram Sang wrote:
On Thu, May 08, 2014 at 04:56:22PM +0200, Arnd Bergmann wrote:
As far as I can tell, this driver must have produced this error
for as long as it has been merged into the mainline kernel, but
it was never part of the normal build tests
kernel. Please apply on the appropriate trees unless
there are objections.
Patch numbers are per subsystem, which I thought is less confusing
than numbering them 1-22 when they are all totall independent.
Arnd Bergmann (22):
mdio_bus: fix devm_mdiobus_alloc_size export
phy: kona2: use 'select
-off-by: Arnd Bergmann a...@arndb.de
Cc: Wolfram Sang w...@the-dreams.de
Cc: linux-i2c@vger.kernel.org
Cc: Wan ZongShun mcuos@gmail.org
Cc: Marek Vasut marek.va...@gmail.com
Cc: Baruch Siach bar...@tkos.co.il
---
drivers/i2c/busses/i2c-nuc900.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
On Friday 21 March 2014 20:17:39 Maxime Ripard wrote:
On Fri, Mar 21, 2014 at 11:49:59AM -0400, Paul Gortmaker wrote:
On Mon, Mar 10, 2014 at 7:29 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Mon, Mar 10, 2014 at 11:58:08AM +0100, Maxime Ripard wrote:
On Fri, Mar 07,
On Friday 14 February 2014 15:54:38 Jisheng Zhang wrote:
Hi all,
The writel/readl is too expensive especially on Cortex A9 w/ outer L2 cache.
This
introduce i2c read/write error on Marvell Berlin SoCs when there are L2 cache
maintenance operations at the same time.
In our internal
On Tuesday 07 January 2014, Gregory CLEMENT wrote:
static void __init armada_370_xp_dt_init(void)
{
+ i2c_quirk();
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
}
I'd prefer to enable the quirk only on machines that we know may be affected,
i.e.
On Tuesday 07 January 2014, Gregory CLEMENT wrote:
diff --git a/include/linux/mvebu-soc-id.h b/include/linux/mvebu-soc-id.h
new file mode 100644
index ..31654252fe35
--- /dev/null
+++ b/include/linux/mvebu-soc-id.h
+#ifdef CONFIG_ARCH_MVEBU
+int mvebu_get_soc_id(u32 *dev, u32
On Wednesday 08 January 2014 14:42:45 Gregory CLEMENT wrote:
You means something like the following code ?
static void __init armada_370_xp_dt_init(void)
{
+ if (of_machine_is_compatible(plathome,openblocks-ax3-4))
+ i2c_quirk();
of_platform_populate(NULL,
On Wednesday 08 January 2014 14:39:59 Wolfram Sang wrote:
However, when I first read this I thought it should be a -a0 specific
compatible string, not a 'offload-broken' property - any idea what the
DT consensus is here? I've seen both approach in use ..
I prefer the replacement of
be extend to also be used with dove,
kirkwood, orion5x and mv78x00 when there will be merged in mvebu and
even expose the SoC ID and revision to userspace.
Jason, do you still agree to take the series once Wolfram have given
his acked-by?
Whole series
Acked-by: Arnd Bergmann a...@arndb.de
On Wednesday 08 January 2014, Gregory CLEMENT wrote:
On 08/01/2014 16:21, Wolfram Sang wrote:
diff --git a/drivers/i2c/busses/i2c-mv64xxx.c
b/drivers/i2c/busses/i2c-mv64xxx.c
index 8be7e42aa4de..f424c0f89946 100644
--- a/drivers/i2c/busses/i2c-mv64xxx.c
+++
On Monday 06 January 2014, Gregory CLEMENT wrote:
Relying on the soc id patch for a stable bug fix seems a little
far-reaching to me. I would be happier to first try to do a local
detection based on the i2c bus device node itself. Do you know how
It was my first proposal in case adding
On Monday 06 January 2014, Andrew Lunn wrote:
That would be rather unfortunate and we should probably
try to merge the bindings eventually and make sure that either OS can
boot with any conforming DTB
It probably requires one of the DT maintainers to talk to FreeBSD
equivalents to get
On Tuesday 07 January 2014, Gregory CLEMENT wrote:
On 07/01/2014 10:03, Arnd Bergmann wrote:
On Monday 06 January 2014, Gregory CLEMENT wrote:
My main concern is that this patch is adding platform code that we'd
otherwise have to carry in the kernel indefinitely. I agree that
it's best
On Monday 06 January 2014, Andrew Lunn wrote:
This raises the question, should mainline try to support any random
dtb blob, or only those that have ever shipped with mainline?
It should support any dtb that conforms to the binding.
There are some older mainline DT blobs which won't have PCIe
On Friday 03 January 2014, Gregory CLEMENT wrote:
All the mvebu SoCs have information related to their variant and
revision that can be read from the PCI control register.
This patch adds support for Armada XP and Armada 370. This reading of
the revision and the ID are done before the PCI
On Friday 03 January 2014, 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
On Sunday 05 January 2014, Andrew Lunn wrote:
That would be rather odd. These nodes are in the top level SoC dtsi
file. When they are not used, they have status = disabled and are in
the dtb blob with this state.
The only reason i can think of them not being present at all is if
somebody
On Saturday 06 July 2013 14:01:12 Maxime Ripard wrote:
I'm not exactly sure on what happened to the previous mail that has been
sent empty, but anyway:
On Sat, Jul 06, 2013 at 11:18:00AM +0200, Arnd Bergmann wrote:
On Saturday 06 July 2013 10:28:04 Maxime Ripard wrote:
a) like
On Wednesday 03 July 2013, Christian Ruppert wrote:
On Wed, Jul 03, 2013 at 01:43:11PM +0200, Arnd Bergmann wrote:
On Wednesday 26 June 2013, Wolfram Sang wrote:
On Wed, Jun 26, 2013 at 10:55:06AM +0200, Christian Ruppert wrote:
This patch makes the SDA hold time configurable through
On Wednesday 03 July 2013, Christian Ruppert wrote:
On Wed, Jul 03, 2013 at 04:20:03PM +0200, Arnd Bergmann wrote:
On Wednesday 03 July 2013, Christian Ruppert wrote:
On Wed, Jul 03, 2013 at 01:43:11PM +0200, Arnd Bergmann wrote:
On Wednesday 26 June 2013, Wolfram Sang wrote
On Wednesday 03 July 2013, Christian Ruppert wrote:
On Wed, Jul 03, 2013 at 04:20:03PM +0200, Arnd Bergmann wrote:
On Wednesday 03 July 2013, Christian Ruppert wrote:
On Wed, Jul 03, 2013 at 01:43:11PM +0200, Arnd Bergmann wrote:
On Wednesday 26 June 2013, Wolfram Sang wrote
for the confusion on my part.
I thought you had used do_div() rather than div_u64().
Everything's fine then, feel free to add my
Acked-by: Arnd Bergmann a...@arndb.de
to your patch.
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord
On Wednesday 12 June 2013 10:07:09 Maxime Ripard wrote:
This patchset adds support for the I2C controller found on most of the
Allwinner SoCs, especially the already supported A10 and A13, and the
yet to come A31.
This driver leverages the Marvel mv64xxx i2c controller driver, that has
an
On Wednesday 12 June 2013, Maxime Ripard wrote:
The Marvell and Allwinner controllers share the exact same logic (which
is definitely not trivial), based on a finite state machine that
triggers interrupts at each change of state, each state being a state in
the I2C protocol (like address sent,
On Thursday 18 April 2013, Nicolas Ferre wrote:
Arnd,
Do you feel like giving your Acked-by to this patch? I think that you
were pretty in line with Ludovic's RFC, so it may be interesting to have
your support on this...
Yes, it's fine.
Acked-by: Arnd Bergmann a...@arndb.de
--
To unsubscribe
On Thursday 11 April 2013, Heiko Stübner wrote:
Am Donnerstag, 11. April 2013, 23:37:20 schrieb Arnd Bergmann:
No other file in the kernel besides i2c-s3c2410.c uses the current
plat/regs-iic.h, so we can simply move the header file to live in the
same directory as the driver
No other file in the kernel besides i2c-s3c2410.c uses the current
plat/regs-iic.h, so we can simply move the header file to live in the
same directory as the driver, as a preparation to multiplatform builds.
Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: linux-i2c@vger.kernel.org
Cc: Wolfram
subsystem maintainers: feel free to directly apply the patches
for your subsystem, there should be no dependencies between any of them,
aside from the last patch requiring all of the earlier ones to be applied
first. Getting an Ack is also fine so we can put the patches into arm-soc.
Arnd
Arnd
No other file in the kernel besides i2c-s3c2410.c uses the current
plat/regs-iic.h, so we can simply move the header file to live in the
same directory as the driver, as a preparation to multiplatform builds.
Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: linux-i2c@vger.kernel.org
Cc: Wolfram
As of commit 5f9296ba i2c: Add bus recovery infrastructure, there
is now a global function with the same name, which clashes with
the davinci specific one. The obvious solution is to rename the
function with a davinci prefix.
Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: Viresh Kumar viresh.ku
' declared inside parameter list [enabled by default]
Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: linux-i2c@vger.kernel.org
Cc: Wolfram Sang w.s...@pengutronix.de
Cc: Ben Dooks ben-li...@fluff.org
Cc: Kukjin Kim kgene@samsung.com
---
include/linux/platform_data/i2c-s3c2410.h | 2 ++
1 file changed
On Thursday 20 September 2012, Shawn Guo wrote:
Here is the second post, which should have addressed the comments that
reviewers put on v1.
It's available on branch below.
git://git.linaro.org/people/shawnguo/linux-2.6.git imx/multi-platform-v2
And it's based on the following
On Thursday 20 September 2012, Shawn Guo wrote:
On Thu, Sep 20, 2012 at 07:39:34AM +, Arnd Bergmann wrote:
The first five branches are scheduled to go through the arm-soc tree, so
I'm fine with that. For the sound/for-3.7 branch, I'd like to know when
to expect that hitting mainline
base.
I agree, this series is wonderful, I thought it would take much longer
to get this far.
Two small comments on the last two patches from me, but overall I really
love it.
Acked-by: Arnd Bergmann a...@arndb.de
--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body
On Monday 03 September 2012, Lee Jones wrote:
But if you are handling both, then I agree that platform_data should
override DT.
I do agree with this, but I haven't stumbled over such a use-case yet.
I have only provided; clock names, DMA settings and call-back information
via AUX_DATA()
On Monday 20 August 2012, Roland Stigge wrote:
On 08/20/2012 06:26 PM, Kevin Wells wrote:
I've never had my hands on a PNX4008 chip at NXP, but I do believe they
are the same IP. That specific I2C IP was used in a number of NXP/Phillips
chips besides the PNX4008/LPC32xx. I don't think there
drivers are protected by the MFD symbol.
Please add my
Reviewed-by: Arnd Bergmann a...@arndb.de
comment to these two patches as well.
Arnd
--
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
On Thursday 05 July 2012, Andrew Lunn wrote:
I think the latter one needs to be
+static int __initdata gpio1_irqs[4] = {
+ IRQ_DOVE_HIGH_GPIO,
+ IRQ_DOVE_HIGH_GPIO,
+ IRQ_DOVE_HIGH_GPIO,
+ IRQ_DOVE_HIGH_GPIO,
+};
so we register all four parts to the same
On Thursday 05 July 2012, Qiao Zhou wrote:
+
+static const struct i2c_device_id pm80x_id_table[] = {
+ {88PM800, CHIP_PM800},
+ {88PM805, CHIP_PM805},
+};
+MODULE_DEVICE_TABLE(i2c, pm80x_id_table);
The point of moving the table to the individual drivers was that the
right one can
On Tuesday 03 July 2012, Andrew Lunn wrote:
Both IRQ and GPIO controllers can now be represented in DT. The IRQ
controllers are setup first, and then the GPIO controllers. Interrupts
for GPIO lines are placed directly after the main interrupts in the
interrupt space.
Overall looks very good.
On Thursday 05 July 2012, Andrew Lunn wrote:
I'm wondering about this one. The other platforms usually put the secondary
interrupt controllers into the same match table, while you call
orion_gpio_of_init
from orion_add_irq_domain. Can you explain why you do this? Does it have
any
On Thursday 05 July 2012, Sebastian Hesselbarth wrote:
Andrew,
is it possible to group all gpio banks into one DT description?
For mach-dove it could be something like:
gpio: gpio-controller {
compatible = marvell, orion-gpio;
...
bank0@d0400 {
On Wednesday 04 July 2012, Qiao Zhou wrote:
88PM800 and 88PM805 are two discrete chips used for power management.
Hardware designer can use them together or only one of them according
to requirement.
88pm80x_i2c.c provides common i2c driver handling for both 800 and
805, such as i2c_driver
On Wednesday 04 July 2012, Qiao Zhou wrote:
+ ret = mfd_add_devices(chip-dev, 0, onkey_devs[0],
+ARRAY_SIZE(onkey_devs), onkey_resources[0],
+chip-irq_base);
According to what I discussed with Mark in the previous version, I think you
need
On Monday 02 July 2012, Qiao Zhou wrote:
On 07/02/2012 06:12 PM, Mark Brown wrote:
On Mon, Jul 02, 2012 at 06:09:57PM +0800, Qiao Zhou wrote:
On 07/02/2012 06:03 PM, Mark Brown wrote:
What do you mean by pages? regmap has paging support which just maps
everything into a single flat
On Monday 11 June 2012, Alessandro Rubini wrote:
The i2c-nomadik gateware is really a PrimeCell APB device. By hosting
the driver under the amba bus we can access it more easily, for
example using the generic pci-amba driver. The patch also fixes the
mach-ux500 users, so they register an amba
On Thursday 14 June 2012, Andrew Lunn wrote:
We either have auxdata and clean clock code, or no auxdata and messy
clock code with lots of aliases.
The auxdata is also not limited to the name of the clocks. It allows
me to diff the kernel log for a DT boot and a none DT boot of the same
box
On Thursday 14 June 2012, Andrew Lunn wrote:
I think if you compute the number of interrupts in the domain from the
number of
registers that are described in the device tree, call orion_irq_init()
based on those registers, and use irq domains for the gpio stuff as Rob
suggested,
this
On Sunday 10 June 2012, Andrew Lunn wrote:
@@ -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),
+
On Friday 11 May 2012, Linus Walleij wrote:
On Fri, May 11, 2012 at 7:32 AM, Shawn Guo shawn@linaro.org wrote:
pinctrl-mergebase-20120418 is not enough for me. I need mxs and dummy
states support. So if your devel branch will never be rebased, we can
simply ask Arnd and Olof to get
the prcmu driver already writes the same
output. The next step would be to remove all the {get,set}_register functions
from ab8500 and just call the prcmu directly.
Signed-off-by: Arnd Bergmann a...@arndb.de
---
drivers/mfd/ab8500-core.c | 72
On Monday 02 April 2012, Roland Stigge wrote:
The i2c bus driver i2c-pnx.c (used by mach-pnx4008 and mach-lpc32xx) was
updated to support device tree. In this process, the struct i2c_pnx_data was
eliminated. Therefore, the platform data of pnx4008 is adjusted with this
patch
to use default
On Monday 02 April 2012, Roland Stigge wrote:
--- /dev/null
+++ linux-2.6/Documentation/devicetree/bindings/i2c/pnx.txt
@@ -0,0 +1,36 @@
+* NXP PNX I2C Controller
+
+Required properties:
+
+ - reg: Offset and length of the register set for the device
+ - compatible: should be nxp,pnx-i2c
On Monday 02 April 2012, Roland Stigge wrote:
This is the first series of patches to introduce device tree support for the
LPC32xx SoC. This series includes patches for the various subsystems to
support
device tree to be used later by the machine's initialization.
The patches apply to
On Monday 02 April 2012, Roland Stigge wrote:
+ if (pdev-dev.of_node of_get_property(pdev-dev.of_node,
+use-iram, NULL))
+ pldat-use_iram = true;
+ else
+ pldat-use_iram = false;
+
One more thing I
to various subsystems:
* staging/iio/adc (1)
* rtc (1)
* net (1)
* wdt (1)
* i2c (4)
* arm-soc (i2c related in the former, to be merged via i2c, as suggested by
Arnd Bergmann)
Looks good, please add
Reviewed-by: Arnd Bergmann a...@arndb.de
for the entire series.
Arnd
On Thursday 24 November 2011, Voss, Nikolaus wrote:
+/*
+ * Calculate and set symmetric clock as stated in datasheet:
+ * twi_clk = F_MAIN / (2 * cdiv * (1 ckdiv) + 4)
+ */
+static void __devinit at91_set_twi_clock(struct at91_twi_dev *dev, int
twi_clk)
+{
+ const int
On Thursday 24 November 2011, Voss, Nikolaus wrote:
Aside from the flamewar in that thread, my impression is that in general
people (me certainly) prefer to have driver-local workarounds be expressed
in a driver specific way, not in a platform or architecture specific way
because that
On Tuesday 08 November 2011, Nikolaus Voss wrote:
+
+static unsigned at91_twi_read(struct at91_twi_dev *dev, unsigned reg)
+{
+ return __raw_readl(dev-base + reg);
+}
+
+static void at91_twi_write(struct at91_twi_dev *dev, unsigned reg, unsigned
val)
+{
+ __raw_writel(val,
On Tuesday 20 September 2011, Stephen Warren wrote:
Stephen Warren wrote at Tuesday, August 30, 2011 10:25 AM:
Ben, Arnd,
Could you please ack/nack the patch at the start of this thread for Colin;
see below.
Ben, can you please comment on the acceptability of this patch?
Or Arnd,
On Friday 02 September 2011, Stephen Warren wrote:
The idea was specifically to replace the need to call irq_to_gpio(i2c-irq).
If we did just rename it plain gpio and allow it to be used for anything,
then that does indeed start looking more like device-specific platform data.
I guess it
On Thursday 01 September 2011 10:52:37 Stephen Warren wrote:
Some devices use a single pin as both an IRQ and a GPIO. In that case,
irq_gpio is the GPIO ID for that pin. Not all drivers use this feature.
Where they do, and the use of this feature is optional, and the system
wishes to disable
On Tuesday 30 August 2011, Stephen Warren wrote:
Ben, Arnd,
Could you please ack/nack the patch at the start of this thread for Colin;
see below.
Sorry, I normally like to give my opinion on everything, but I really don't
have a clue what this one is about. I don't understand i2c or power
On Tuesday 16 August 2011 21:14:42 Geert Uytterhoeven wrote:
config I2C_ELEKTOR
tristate Elektor ISA card
- depends on ISA BROKEN_ON_SMP
+ depends on ISA HAS_IOPORT BROKEN_ON_SMP
select I2C_ALGOPCF
help
This supports the PCF8584 ISA bus I2C
On Thursday 23 June 2011 19:22:06 Prarit Bhargava wrote:
This new patchset reworks the existing DMI code into two separate layers. It
is
based off of the feedback I received previously when discussing the SMBIOS
version patch on LKML.
Hi Prarit,
No objections to the patches, but when you
On Wednesday 20 April 2011, Guenter Roeck wrote:
On Wed, Apr 20, 2011 at 12:44:30PM -0400, Arnd Bergmann wrote:
On Tuesday 19 April 2011, Guenter Roeck wrote:
This driver adds support for Si570, Si571, Si598, and Si599
programmable XO/VCXO.
Signed-off-by: Guenter Roeck guenter.ro
1 - 100 of 123 matches
Mail list logo
