In current linux-next we have new driver i2c-designware. So, this is just
removal of old driver.
Andy Shevchenko (1):
i2c: remove i2c-intel-mid
drivers/i2c/busses/Kconfig | 10 -
drivers/i2c/busses/Makefile|1 -
drivers/i2c/busses/i2c-intel-mid.c | 1135
\n, err);
- kfree(at25);
return err;
I believe there is no harm to remove 'fail' branch.
--
With Best Regards,
Andy Shevchenko
--
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
i2c_client *client)
for (i = 1; i at24-num_addresses; i++)
i2c_unregister_device(at24-client[i]);
-
Ditto.
--
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
On Tue, May 28, 2013 at 11:00 PM, Nikolay Balandin
n.a.balan...@gmail.com wrote:
From: Nikolay Balandin nbalan...@dev.rtsoft.ru
Use devm_kzalloc to make cleanup paths simpler
Signed-off-by: Nikolay Balandin nbalan...@dev.rtsoft.ru
Reviewed-by: Andy Shevchenko andy.shevche...@gmail.com
On Tue, May 28, 2013 at 11:01 PM, Nikolay Balandin
n.a.balan...@gmail.com wrote:
From: Nikolay Balandin nbalan...@dev.rtsoft.ru
Use devm_kzalloc to make cleanup paths simpler
Signed-off-by: Nikolay Balandin nbalan...@dev.rtsoft.ru
Reviewed-by: Andy Shevchenko andy.shevche...@gmail.com
the plan to i2c-intel-mid driver?
Nevertheless, I'll resend removal patch after this message.
--
Andy Shevchenko andriy.shevche...@linux.intel.com
Intel Finland Oy
--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More majordomo
Moorestown support is removed from kernel and Medfield is supported by
i2c-designware-pci. But i2c-intel-mid is still in upstream and community
resources are wasted to maintain it.
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
---
drivers/i2c/busses/Kconfig | 10
by passing the client name.
Why ISP driver would like to register sensor drivers in the first place?
That seems the task of platform code, or DT, or ACPI5
Why do you need to re-register them at run time?
--
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line
transfer, be it successful or not.
This patch requires https://patchwork.kernel.org/patch/2601241/ to be
applied first.
What if you just move disabling code from i2c_dw_xfer_init() to the
top of i2c_dw_xfer() ?
Will it help?
--
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
---
drivers/i2c/busses/i2c-designware-core.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/i2c/busses/i2c-designware-core.c
b/drivers/i2c/busses/i2c-designware-core.c
index c41ca63
devm_ioremap_resource does sanity checks on the given resource. No need to
duplicate this in the driver.
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
---
drivers/i2c/busses/i2c-designware-platdrv.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git
think you have to talk to Sakari
about your issues.
On Thu, Jun 06, 2013 at 11:32:06PM +0300, Andy Shevchenko wrote:
On Thu, Jun 6, 2013 at 9:33 PM, Bin Gao bin@linux.intel.com wrote:
There is a requirement to get the i2c_client pointer dynamically without
knowing the bus and slave
product we do require some form of it for stability reasons.
I feel like a real fix is to add a memory barier to make changes in the
structure consistent. However, I have no clue where.
--
Andy Shevchenko andriy.shevche...@linux.intel.com
Intel Finland Oy
--
To unsubscribe from this list: send
patch everything around?
(Though I think better to think and create documents first and after
program accordingly)
--
With Best Regards,
Andy Shevchenko
--
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
can
use in ACPI case, I doubt we may apply all the ideas, probably some of
them, though I didn't get yet where to read about in details. What I
could say now is that the patch provided by Bin Gao is definitely no
go.
--
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send
the slaves are in place. Something like this should
probably be done here, too, instead of unregistering and re-registering.
Yes, seems right way to go.
I think ACPI case can use V4L2 async API somehow, though it has its
own event model.
I'll talk to Sakari Ailus to sync.
--
With Best Regards,
Andy
While here, fix few indentations issues across the code. There is no functional
change.
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
---
drivers/i2c/busses/i2c-designware-pcidrv.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c
for the delay.
There are actually few products based on Medfield reference board and
clovertrail+ as well uses medfield code. We need to keep the bus_num
there for these SFI platforms.
Wolfram, I remove this patch and re-do and resend the former 4/4.
--
Andy Shevchenko andriy.shevche
While here, fix few indentations issues across the code. There is no functional
change.
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
---
drivers/i2c/busses/i2c-designware-pcidrv.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses
The clk_khz field makes sense only if SS counters are not provided. Since we
provide them for Haswell and Baytrail explicitly we can omit the clk_khz
parameter.
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
---
drivers/i2c/busses/i2c-designware-pcidrv.c | 2 --
1 file changed
There is no need to duplicate same data for each controller. If we need
specific stuff for a certain controller in the future we may add it later. The
patch leaves one controller per platform.
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
---
drivers/i2c/busses/i2c-designware
?
For me it seems not. Here is error patch and we have already in error
recovery, so, intention to see if the semaphore becomes alive after
reset. Am I right, David?
--
Andy Shevchenko andriy.shevche...@intel.com
Intel Finland Oy
--
To unsubscribe from this list: send the line unsubscribe linux
-designware-baytrail.c:114:6: warning: symbol
'baytrail_i2c_release' was not declared. Should it be static?
While here, do few indentation fixes, remove i2c_dw_eval_lock_support() from
functions exported to the modules and redundant assignment of local sem
variable.
Signed-off-by: Andy Shevchenko
It seems the idea behind the cross-check is to prevent acquire semaphore when
there is no release callback and vice versa. Thus, patch fixes a typo.
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
---
drivers/i2c/busses/i2c-designware-baytrail.c | 2 +-
1 file changed, 1
This patch marks baytrail_i2c_acquire() that it might sleep. Also it chages
while-loop to do-while and, though it is matter of taste, gives a chance to
check one more time before report a timeout.
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
---
drivers/i2c/busses/i2c
It seems we have same message for different return values in get_sem() and
baytrail_i2c_acquire(). I suspect this is just a typo, so this patch fixes it.
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
---
drivers/i2c/busses/i2c-designware-baytrail.c | 4 ++--
1 file changed, 2
The patch converts hardcoded numerical constants to a named ones.
While here, align the variable name in get_sem() and reset_semaphore().
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
---
drivers/i2c/busses/i2c-designware-baytrail.c | 16 +---
1 file changed, 9
On Fri, 2015-01-23 at 14:48 +0200, Mika Westerberg wrote:
On Fri, Jan 23, 2015 at 01:41:55PM +0100, Wolfram Sang wrote:
On Fri, Jan 23, 2015 at 01:54:03PM +0200, Andy Shevchenko wrote:
There is no need to duplicate same data for each controller. If we need
specific stuff for a certain
The clk_khz field makes sense only if SS counters are not provided. Since we
provide them for Haswell and Baytrail explicitly we may omit the clk_khz
parameter.
Reviewed-by: Jarkko Nikula jarkko.nik...@linux.intel.com
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
---
drivers
The Moorestown support bits were removed few years ago. This is a follow up to
that changes.
Suggested-by: David Cohen david.a.co...@linux.intel.com
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
---
drivers/i2c/busses/i2c-designware-pcidrv.c | 29
While here, fix few indentations issues across the code. There is no functional
change.
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
---
drivers/i2c/busses/i2c-designware-pcidrv.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses
There is no need to duplicate same data for each controller. If we need
specific stuff for a certain controller in the future we may add it later. The
patch leaves one controller per platform.
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
---
drivers/i2c/busses/i2c-designware
meant Moorestown.
--
Andy Shevchenko andriy.shevche...@intel.com
Intel Finland Oy
--
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
was thinking even about some wrapper on top of platform_get_irq()
since it seems there are no messaging done inside platform.c, though
devm_* functions usually have it.
--
Andy Shevchenko andriy.shevche...@intel.com
Intel Finland Oy
--
To unsubscribe from this list: send the line unsubscribe linux-i2c
another one that needs to be fixed in
the future.
--
Andy Shevchenko andriy.shevche...@intel.com
Intel Finland Oy
--
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
?
Wolfram, do we agree on this as states in the patch? Maybe you have more
comments, questions?
Otherwise, should I rebase this on top of 4.0-rc1 or you will be okay
with current version?
--
Andy Shevchenko andriy.shevche...@intel.com
Intel Finland Oy
--
To unsubscribe from this list: send
with current version?
Well, if it needs rebasing, please do. If not, please say so, too :)
It applies clearly on top of current linux-next without any changes from
my side. So, no rebase is needed.
--
Andy Shevchenko andriy.shevche...@intel.com
Intel Finland Oy
--
To unsubscribe from
On Wed, 2015-07-08 at 13:15 +0300, Andy Shevchenko wrote:
The mentioned flag fixes a warning on Intel Edison board since one of
the I2C
controller shares IRQ line with watchdog timer.
Wolfram, do you have any comments on this?
Signed-off-by: Andy Shevchenko andriy.shevche
On Wed, 2015-10-07 at 13:18 +0300, Andy Shevchenko wrote:
> There is a board in the wild, i.e. Intel Galileo Gen2, that has ACPI
> enumerated
> devices behind I2C bus.
Lee, since Wolfram is going to apply patches 1 and 5, how could we
proceed with the rest? Patches are indeed build in
in ACPI
namespace. Here the _ADR values are provided.
Acked-by: Lee Jones <lee.jo...@linaro.org>
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/mfd/intel_quark_i2c_gpio.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a
Jones <lee.jo...@linaro.org>
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
Documentation/acpi/enumeration.txt | 11 +---
drivers/mfd/mfd-core.c | 52 ++
include/linux/mfd/core.h | 10 ++--
3 files chan
There is a 24c08 chip connected to i2c bus on Intel Galileo Gen2 board. Enable
it via ACPI ID INT3499.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/misc/eeprom/at24.c | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff
On Fri, 2015-10-23 at 14:38 +0200, Wolfram Sang wrote:
> > Wolfram, since Lee acknowledged patches 1-3, can you pull them to
> > your tree?
>
> So, I picked patches 1-4 to my for-next. Patch 5 is missing an ACK.
Right. Thanks!
--
Andy Shevchenko <andriy.shevche...@l
gested by Thierry)
Andy Shevchenko (5):
mfd: core: redo ACPI matching of the children devices
mfd: intel_quark_i2c_gpio: load gpio driver first
mfd: intel_quark_i2c_gpio: support devices behind i2c bus
at24: enable ACPI device found on Galileo Gen2
pwm-pca9685: enable ACPI device
org>
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/mfd/intel_quark_i2c_gpio.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/mfd/intel_quark_i2c_gpio.c
b/drivers/mfd/intel_quark_i2c_gpio.c
index 1ce1603..95
There is a chip connected to i2c bus on Intel Galileo Gen2 board. Enable it via
ACPI ID INT3492.
Cc: Thierry Reding <thierry.red...@gmail.com>
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/pwm/Kconfig | 2 +-
drivers/pwm/pwm-pc
On Fri, 2015-09-18 at 14:06 +0300, Andy Shevchenko wrote:
> There is a warning when compiling i2c-core.c
> drivers/i2c/i2c-core.c:2561:36: warning: dubious: x | !y
>
> Fix it by using a plain bitwise AND since I2C_M_RD is a bit 0 and
> thus we are
> on the safe side.
Wolf
On Fri, 2015-10-23 at 12:16 +0300, Andy Shevchenko wrote:
> There is a chip connected to i2c bus on Intel Galileo Gen2 board.
> Enable it via
> ACPI ID INT3492.
Thierry, ping?
>
> Cc: Thierry Reding <thierry.red...@gmail.com>
> Signed-off-by: Andy Shevchenko <andriy
; + msgs[0].addr == msgs[1].addr) {
Nitpick (optional):
((msgs[0].flags & msgs[1].flags) & I2C_M_RD)
?
> + i2c->auto_restart = 0;
> + }
> + }
--
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: se
ter Anvin <h...@zytor.com>
Cc: Wolfram Sang <w...@the-dreams.de>
Cc: Zhang Rui <rui.zh...@intel.com>
Cc: Eduardo Valentin <edubez...@gmail.com>
Cc: Hock Leong Kweh <hock.leong.k...@intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
ter Anvin <h...@zytor.com>
Cc: Wolfram Sang <w...@the-dreams.de>
Cc: Zhang Rui <rui.zh...@intel.com>
Cc: Eduardo Valentin <edubez...@gmail.com>
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
arch/x86/include/asm/iosf_mbi.h | 49
_main_adapters[0]);
> + if (retval < 0)
> + return retval;
> + }
>
> /* Check for auxiliary SMBus on some AMD chipsets */
> retval = -ENODEV;
> @@ -669,7 +784,13 @@ static void piix4_adap_remove(struct i2c_adapter
> *adap)
>
> if (adapdata-
o get this
> upstream
> finally.
One nitpick in one patch, though it looks okay for me:
Reviewed-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
>
> Eddi, Thomas, it would be great if you could verify the changes on
> your
> machines.
>
> Regards,
> Christian
tval = piix4_setup_sb800(dev, id, 0);
> - else
> + } else {
> retval = piix4_setup(dev, id);
> + }
>
> /* If no main SMBus found, give up */
> if (retval < 0)
> @@ -692,6 +700,9 @@ static void piix4_remove(struct pci_dev *dev)
>
tval = piix4_add_adapters_sb800(dev, retval);
> } else {
> retval = piix4_setup(dev, id);
> + if (retval < 0)
> + return retval;
> +
> + /* Try to register main SMBus adapter, give up if we
> can't */
> +
ired anymore since
commit 166c2ba398640278ae6037be4aa5562c03cf3d24
Author: Mika Westerberg <mika.westerb...@linux.intel.com>
Date: Wed Oct 7 13:18:44 2015 +0300
i2c / ACPI: Rework I2C device scanning
--
Andy Shevchenko <andriy.shevche...@linux.intel.com>
Intel Finland Oy
--
;= 0; port--) {
> + if (piix4_main_adapters[port]) {
> + piix4_adap_remove(piix4_main_adapters[port],
> + port == 0);
> + piix4_main_adapters[port] = NULL;
> + }
> }
Would it be
int port = PIIX4_MAX_ADA
ll be okay.
dev_err(>dev,
"SMBus base address index region 0x%x already in use!\n",
smba_idx);
> + return -EBUSY;
> + }
> + piix4_smb_idx_sb800 = smba_idx;
> +
> /* base address location etc changed in S
l < 0)
> return retval;
>
> - /* Try to register main SMBus adapter, give up if we can't
> */
> - retval = piix4_add_adapter(dev, retval,
> _main_adapters[0]);
> - if (retval < 0)
> - return retval;
> -
> /* Check for auxiliary SMBus on some AMD chipsets */
> retval = -ENODEV;
>
--
Andy Shevchenko <andriy.shevche...@linux.intel.com>
Intel Finland Oy
--
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
> ports better (for example in sensors output).
> +static const char *piix4_main_port_names_sb800[4] = {
Would it be constant you defined instead of magic number?
> + "SDA0", "SDA2", "SDA3", "SDA4"
> +};
> +static const char *pii
On Fri, Oct 30, 2015 at 8:54 PM, Lee Jones <lee.jo...@linaro.org> wrote:
> On Wed, 21 Oct 2015, Andy Shevchenko wrote:
>
>> On Wed, 2015-10-07 at 13:18 +0300, Andy Shevchenko wrote:
>> > There is a board in the wild, i.e. Intel Galileo Gen2, that has ACPI
>> >
On Wed, 2015-10-07 at 13:18 +0300, Andy Shevchenko wrote:
> There is a chip connected to i2c bus on Intel Galileo Gen2 board.
> Enable it via
> ACPI ID INT3492.
Thierry, can you Ack or take this one, please?
>
> Cc: Thierry Reding <thierry.red...@gmail.com>
> Signed
you may adjust the bus speed whenever
slave device is enumerated.
For PCI case you have still to have hardcoded values and it should be
maximum supported by the bus I think. When you have implemented above
algorithm you may do this safely. Am I missing something?
--
Andy Shevchenko <
On Thu, 2015-10-15 at 15:58 +0200, Wolfram Sang wrote:
> Those guys already have been helpful in the past and are actively
> working on this driver, unlike me.
>
> Signed-off-by: Wolfram Sang <w...@the-dreams.de>
> Acked-by: Jarkko Nikula <jarkko.nik...@linux.intel.co
gt; if (force_nr) {
> priv->adap.nr = force_nr;
> ret = i2c_add_numbered_adapter(>adap);
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index 51a96a8..66564f8 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/a
b/drivers/i2c/busses/i2c-designware-platdrv.c
> @@ -307,8 +307,8 @@ static void dw_i2c_plat_complete(struct device
> *dev)
> pm_request_resume(dev);
> }
> #else
> -#define dw_i2c_prepare NULL
> -#define dw_i2c_complete NULL
> +#define dw_i2c_plat_prepa
ss_lcnt;
> u16 fs_hcnt;
> u16 fs_lcnt;
> + u16 hs_hcnt;
> + u16 hs_lcnt;
> int (*acquire_lock)(struct dw_i2c_dev
> *dev);
>
,6 +250,9 @@ static int i2c_dw_pci_probe(struct pci_dev *pdev,
>
> dev->tx_fifo_depth = controller->tx_fifo_depth;
> dev->rx_fifo_depth = controller->rx_fifo_depth;
> +
> + i2c_dw_acpi_setup_speed(>dev, dev);
Don't see a relationship between PCI driver an
nt = cfg->fs_lcnt;
> > > + dev->hs_lcnt = cfg->hs_lcnt;
> > > dev->sda_hold_time = cfg->sda_hold;
> > > }
> > >
> > > @@ -246,6 +250,9 @@ static int i2c_dw_pci_probe(struct pci_dev
> > &
in ACPI
namespace. Here the _ADR values are provided.
Acked-by: Lee Jones <lee.jo...@linaro.org>
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/mfd/intel_quark_i2c_gpio.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a
patches (GPIO pca953x)
Changelog v2:
- append tags
- re-make patch 3 (suggested by Lee)
- improve patch 8 (suggested by Thierry)
Andy Shevchenko (5):
mfd: core: redo ACPI matching of the children devices
mfd: intel_quark_i2c_gpio: load gpio driver first
mfd: intel_quark_i2c_gpio: support
resent devices with valid I2cSerialBus() connection pointing to the host
controller in question.
Signed-off-by: Mika Westerberg <mika.westerb...@linux.intel.com>
Acked-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com&
There is at least one board on the market, i.e. Intel Galileo Gen2, that uses
_ADR to distinguish the devices under one actual device. Due to this we have to
improve the quirk in the MFD core to handle that board.
Acked-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
Signed-off-by
There is a 24c08 chip connected to i2c bus on Intel Galileo Gen2 board. Enable
it via ACPI ID INT3499.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/misc/eeprom/at24.c | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff
org>
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/mfd/intel_quark_i2c_gpio.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/mfd/intel_quark_i2c_gpio.c
b/drivers/mfd/intel_quark_i2c_gpio.c
index 1ce1603..95
There is a chip connected to i2c bus on Intel Galileo Gen2 board. Enable it via
ACPI ID INT3492.
Cc: Thierry Reding <thierry.red...@gmail.com>
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/pwm/Kconfig | 2 +-
drivers/pwm/pwm-pc
The mentioned flag fixes a warning on Intel Edison board since one of the I2C
controller shares IRQ line with watchdog timer.
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
---
drivers/i2c/busses/i2c-designware-pcidrv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions
+ if (kstrtou8(p + 1, 16, >byte))
> + return -EPROTO;
--
With Best Regards,
Andy Shevchenko
--
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
Propagate actual return code when requesting interrupt fails.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/i2c/busses/i2c-ismt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-ismt.c b/drivers/i2c/busses/i2c-
] https://www.kernel.org/doc/ols/2009/ols2009-pages-319-330.pdf
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/i2c/busses/i2c-ismt.c | 33 -
1 file changed, 33 deletions(-)
diff --git a/drivers/i2c/busses/i2c-ismt.c b/drive
Issue the warning in all error paths when unable to register MSI or its
handler.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/i2c/busses/i2c-ismt.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-is
There is a warning when compiling i2c-core.c
drivers/i2c/i2c-core.c:2561:36: warning: dubious: x | !y
Fix it by using ternary operator.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/i2c/i2c-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
ld start with the comment right now...
Please, update my patch accordingly, or ping me to update it.
Right now busy with something else.
--
Andy Shevchenko <andriy.shevche...@linux.intel.com>
Intel Finland Oy
--
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
There is at least one board on the market, i.e. Intel Galileo Gen2, that uses
_ADR to distinguish the devices under one actual device. Due to this we have to
improve the quirk in the MFD core to handle that board.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.
On Intel Galileo boards the GPIO expander is connected to i2c bus. Moreover it
is able to generate interrupt, but interrupt line is connected to GPIO. That's
why we have to have GPIO driver in place when we will probe i2c host with
device connected to it.
Signed-off-by: Andy Shevchenko
(gpio expanders) and me (at24).
Changelog v2:
- append tags
- re-make patch 3 (suggested by Lee)
- improve patch 8 (suggested by Thierry)
Andy Shevchenko (7):
mfd: core: redo ACPI matching of the children devices
mfd: intel_quark_i2c_gpio: load gpio driver first
mfd: intel_quark_i2c_gpio
in ACPI
namespace. Here the _ADR values are provided.
Acked-by: Lee Jones <lee.jo...@linaro.org>
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/mfd/intel_quark_i2c_gpio.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a
resent devices with valid I2cSerialBus() connection pointing to the host
controller in question.
Signed-off-by: Mika Westerberg <mika.westerb...@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/i
This patch adds a support of the expandes found on Intel Galileo Gen2 board.
The platform information comes from ACPI.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/gpio/gpio-pca953x.c | 21 -
1 file changed, 20 insertions(+), 1 de
Instead of using id->driver_data directly we copied it to the internal
structure. This will help to adapt driver for ACPI use.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/gpio/gpio-pca953x.c | 17 ++---
1 file changed, 10 insertions(+), 7
There is a chip connected to i2c bus on Intel Galileo Gen2 board. Enable it via
ACPI ID INT3492.
Cc: Thierry Reding <thierry.red...@gmail.com>
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/pwm/Kconfig | 2 +-
drivers/pwm/pwm-pc
There is a 24c08 chip connected to i2c bus on Intel Galileo Gen2 board. Enable
it via ACPI ID INT3499.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/misc/eeprom/at24.c | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff
On Mon, 2015-10-05 at 09:20 +0200, Linus Walleij wrote:
> On Thu, Oct 1, 2015 at 1:20 PM, Andy Shevchenko
> <andriy.shevche...@linux.intel.com> wrote:
>
> > The patches 7 and 8 are pretty independent, though they don't make
> > much sense
> > without previous
On Thu, 2015-10-01 at 15:54 +0100, Lee Jones wrote:
> On Thu, 01 Oct 2015, Andy Shevchenko wrote:
>
> > On Intel Galileo boards the GPIO expander is connected to i2c bus.
> > Moreover it
> > is able to generate interrupt, but interrupt line is connected to
> >
On Wed, 2015-09-16 at 17:23 +0300, Andy Shevchenko wrote:
> pcim_release() will release any requested region. There is no need to
> duplicate
> this effort in the driver.
Any comments on that clean up series?
>
> Signed-off-by: Andy Shevchenko <andriy.shevche.
On Tue, 2015-09-22 at 23:15 +0100, Lee Jones wrote:
> On Tue, 22 Sep 2015, Andy Shevchenko wrote:
>
> > There is at least one board on the market, i.e. Intel Galileo Gen2,
> > that uses
> > _ADR to distinguish the devices under one actual device. Due to
> > this we
On Wed, 2015-09-23 at 14:48 +0200, Thierry Reding wrote:
> > > >
> On Wed, Sep 23, 2015 at 11:41:26AM +0300, Andy Shevchenko wrote:
> > On Tue, 2015-09-22 at 16:37 +0200, Thierry Reding wrote:
> > > On Tue, Sep 22, 2015 at 01:10:19P
On Tue, 2015-09-22 at 16:37 +0200, Thierry Reding wrote:
> On Tue, Sep 22, 2015 at 01:10:19PM +0300, Andy Shevchenko wrote:
> > --- a/drivers/pwm/pwm-pca9685.c
> > +++ b/drivers/pwm/pwm-pca9685.c
> > @@ -26,6 +26,8 @@
> > #include
> > #include
> >
There is at least one board on the market, i.e. Intel Galileo Gen2, that uses
_ADR to distinguish the devices under one actual device. Due to this we have to
improve the quirk in the MFD core to handle that board.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.
in ACPI
namespace. Here the _ADR values are provided.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/mfd/intel_quark_i2c_gpio.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/mfd/intel_quark_i2c_gpio.c
b/drivers/mfd/intel_quark_i2c_
1 - 100 of 155 matches
Mail list logo
