Re: [PATCH] add hardware I2C support for ARM IMX23
On Wed, Nov 28, 2012 at 03:24:03PM +0100, sander van ginkel wrote: > The I2C hardware in the IMX233 is currently not supported, > however the i2c-mxs driver seems to be suitable. > To use the i2c-mxs driver it has to be added to the devicetree > for the IMX23. Have you tested it? There have been problems reported when using i2cdetect... -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
Re: [PATCH] add hardware I2C support for ARM IMX23
> I've tested it with multiple configs. Please specify a bit more what you tested and what configs mean. It is especially important to talk to slaves since this is where DMA problems occured. > i2cdetect -l gives me: > i2c-0 i2c MXS I2C adapter I2C adapter 'i2cdetect -r ...' would be more interesting to see communication with slaves happening :) Also, what kernel did you test? Thanks, Wolfram -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
Re: [PATCH] add hardware I2C support for ARM IMX23
Hi, (adding the i2c list) On Wed, Nov 28, 2012 at 05:44:49PM +0100, Sander van Ginkel wrote: > tested with: > CONFIG_I2C_MXS=m > CONFIG_I2C_MXS=y > > in combination with CONFIG_GPIO_MXS enabled and disabled > > used kernels: 3.6 and 3.7.0-rc6 > > My I2C slave is a PCF8575 i/o expander with some LEDs at the output. > These are controlled through sysfs. Thanks, this is useful info. > Just tested with "i2cdetc -y -r 0" that crashes with "BUG: soft > lockup - CPU#0 stuck for 22s!" > according to the docs (IMX23RM.pdf) the interrupts for I2C are 26 > and 27 that why I assigned these two in the dts. You might want to try my for-next branch or wait for 3.8-rc1, maybe the DMA termination patch helps? Also enabling I2C debug messages is probably worth it. Regards, Wolfram -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
Current I2C workflow
Hi, working on the transparency thing here regarding the current I2C workflow. I am currently on, well, let's call it something between holiday and retreat. I will work on (hopefully all) pending I2C patches half-time until Friday and then probably disappear for about 3 weeks again. Disappearing means I will lurk the list for urgent patches and handle them, but will pass the other ones for later handling. So, please make sure to emphasize urgent patches. For a few weeks now, the I2C list is monitored by patchwork [1] (Thanks, Jeremy!), which should make sure that no patches are forgotten. I do use the status field, so this list is a good place to check if you wonder what happened to your patch. I will send replies explaining my decisions, nonetheless. People reviewing patches from each other are much appreciated and will help the process. And to make clear after some email confusion: w...@the-dreams.de is the preferred email address for my kernel related stuff. Off to work, Wolfram [1] http://patchwork.ozlabs.org/project/linux-i2c/list/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] i2c: busses/i2c-pxa.c: fix potential null pointer dereference error
On Thu, Feb 14, 2013 at 12:28:18PM +0100, Cong Ding wrote:
> If it goes to eclk through line 1107, the variable res would be NULL. It will
> cause a null pointer dereference error if we call release_mem_region. The
> correct way should be using devm_kzalloc rather than kzalloc to allocate
> memory.
>
> Signed-off-by: Cong Ding
> ---
> drivers/i2c/busses/i2c-pxa.c | 22 --
> 1 file changed, 8 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
> index 1034d93..dd2d640 100644
> --- a/drivers/i2c/busses/i2c-pxa.c
> +++ b/drivers/i2c/busses/i2c-pxa.c
> @@ -1094,29 +1094,23 @@ static int i2c_pxa_probe(struct platform_device *dev)
> struct resource *res = NULL;
> int ret, irq;
>
> - i2c = kzalloc(sizeof(struct pxa_i2c), GFP_KERNEL);
> - if (!i2c) {
> - ret = -ENOMEM;
> - goto emalloc;
> - }
> + i2c = devm_kzalloc(sizeof(struct pxa_i2c), GFP_KERNEL);
You are using devm_kzalloc here but plain kfree is used later. This
won't work.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 2/2] i2c: pxa: Use i2c-core to get bus number now
On Fri, Mar 01, 2013 at 08:57:32AM -0800, Doug Anderson wrote: > The commit: "i2c-core: dt: Pick i2c bus number from i2c alias if > present" adds support for automatically picking the bus number based > on the alias ID. Remove the now unnecessary code from i2c-pxa that > did the same thing. > > Signed-off-by: Doug Anderson Thanks, applied for-next. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] MAINTAINERS: change my email and repos
Change to my private email, change to my shiny new kernel.org repos, and drop outdated entry from the former maintainer. Drop my PCA entry, too, since it belongs to the I2C realm anyhow. Signed-off-by: Wolfram Sang --- MAINTAINERS | 16 +++- 1 file changed, 3 insertions(+), 13 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 8ae709e..8c13cc8 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1303,7 +1303,7 @@ F:include/linux/dmaengine.h F: include/linux/async_tx.h AT24 EEPROM DRIVER -M: Wolfram Sang +M: Wolfram Sang L: linux-...@vger.kernel.org S: Maintained F: drivers/misc/eeprom/at24.c @@ -3757,12 +3757,11 @@ S: Maintained F: drivers/i2c/i2c-stub.c I2C SUBSYSTEM -M: Wolfram Sang +M: Wolfram Sang M: "Ben Dooks (embedded platforms)" L: linux-...@vger.kernel.org W: http://i2c.wiki.kernel.org/ -T: quilt kernel.org/pub/linux/kernel/people/jdelvare/linux-2.6/jdelvare-i2c/ -T: git git://git.pengutronix.de/git/wsa/linux.git +T: git git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git S: Maintained F: Documentation/i2c/ F: drivers/i2c/ @@ -5778,15 +5777,6 @@ L: linux-...@vger.kernel.org S: Maintained F: drivers/i2c/muxes/i2c-mux-pca9541.c -PCA9564/PCA9665 I2C BUS DRIVER -M: Wolfram Sang -L: linux-...@vger.kernel.org -S: Maintained -F: drivers/i2c/algos/i2c-algo-pca.c -F: drivers/i2c/busses/i2c-pca-* -F: include/linux/i2c-algo-pca.h -F: include/linux/i2c-pca-platform.h - PCDP - PRIMARY CONSOLE AND DEBUG PORT M: Khalid Aziz S: Maintained -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] i2c: convert to idr_alloc()
Hi,
thanks for doing this cleanup series. Looks very worthwhile!
> --- a/drivers/i2c/i2c-core.c
> +++ b/drivers/i2c/i2c-core.c
> @@ -935,25 +935,16 @@ out_list:
> */
> int i2c_add_adapter(struct i2c_adapter *adapter)
> {
> - int id, res = 0;
> -
> -retry:
> - if (idr_pre_get(&i2c_adapter_idr, GFP_KERNEL) == 0)
> - return -ENOMEM;
> + int res;
I'd vote for using 'id' as the variable name here. Feels more logical to
me and you are using 'id' in the other block, too.
> @@ -984,33 +975,19 @@ EXPORT_SYMBOL(i2c_add_adapter);
> int i2c_add_numbered_adapter(struct i2c_adapter *adap)
> {
> int id;
> - int status;
>
> if (adap->nr == -1) /* -1 means dynamically assign bus id */
> return i2c_add_adapter(adap);
> if (adap->nr & ~MAX_IDR_MASK)
> return -EINVAL;
>
> -retry:
> - if (idr_pre_get(&i2c_adapter_idr, GFP_KERNEL) == 0)
> - return -ENOMEM;
> -
> mutex_lock(&core_lock);
> - /* "above" here means "above or equal to", sigh;
> - * we need the "equal to" result to force the result
> - */
> - status = idr_get_new_above(&i2c_adapter_idr, adap, adap->nr, &id);
> - if (status == 0 && id != adap->nr) {
> - status = -EBUSY;
> - idr_remove(&i2c_adapter_idr, id);
> - }
> + id = idr_alloc(&i2c_adapter_idr, adap, adap->nr, adap->nr + 1,
> +GFP_KERNEL);
> mutex_unlock(&core_lock);
> - if (status == -EAGAIN)
> - goto retry;
> -
> - if (status == 0)
> - status = i2c_register_adapter(adap);
> - return status;
> + if (id < 0)
> + return id == -ENOSPC ? -EBUSY : id;
> + return i2c_register_adapter(adap);
Add an empty line before the return statement?
Thanks,
Wolfram
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/6] idr: remove MAX_IDR_MASK and move left MAX_IDR_* into idr.c
On Fri, Feb 08, 2013 at 01:01:49PM -0800, Tejun Heo wrote: > MAX_IDR_MASK is another weirdness in the idr interface. As idr covers > whole positive integer range, it's defined as 0x7fff or INT_MAX. > > Its usage in idr_find(), idr_replace() and idr_remove() is bizarre. > They basically mask off the sign bit and operate on the rest, so if > the caller, by accident, passes in a negative number, the sign bit > will be masked off and the remaining part will be used as if that was > the input, which is worse than crashing. > > The constant is visible in idr.h and there are several users in the > kernel. > > * drivers/i2c/i2c-core.c:i2c_add_numbered_adapter() > > Basically used to test if adap->nr is a negative number which isn't > -1 and returns -EINVAL if so. idr_alloc() already has negative > @start checking (w/ WARN_ON_ONCE), so this can go away. > > * drivers/infiniband/core/cm.c:cm_alloc_id() > drivers/infiniband/hw/mlx4/cm.c:id_map_alloc() > > Used to wrap cyclic @start. Can be replaced with max(next, 0). > Note that this type of cyclic allocation using idr is buggy. These > are prone to spurious -ENOSPC failure after the first wraparound. > > * fs/super.c:get_anon_bdev() > > The ID allocated from ida is masked off before being tested whether > it's inside valid range. ida allocated ID can never be a negative > number and the masking is unnecessary. > > Update idr_*() functions to fail with -EINVAL when negative @id is > specified and update other MAX_IDR_MASK users as described above. > > This leaves MAX_IDR_MASK without any user, remove it and relocate > other MAX_IDR_* constants to lib/idr.c. > > Signed-off-by: Tejun Heo For the i2c-part: Acked-by: Wolfram Sang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] i2c-core: dt: Pick i2c bus number from i2c alias if present
Hi Doug,
On Mon, Jan 14, 2013 at 10:53:21AM -0800, Doug Anderson wrote:
> This allows you to get the equivalent functionality of
> i2c_add_numbered_adapter() with all data in the device tree and no
> special case code in your driver. This is a common device tree
> technique.
>
> For quick reference, the FDT syntax for using an alias to provide an
> ID looks like:
> aliases {
> i2c0 = &i2c_0;
> i2c1 = &i2c_1;
> };
>
> Signed-off-by: Doug Anderson
> Acked-by: Haojian Zhuang
> ---
> Changes in v2: None
>
> drivers/i2c/i2c-core.c | 105
> +++-
> 1 files changed, 77 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
> index e388590..a60ed6d 100644
> --- a/drivers/i2c/i2c-core.c
> +++ b/drivers/i2c/i2c-core.c
> @@ -921,13 +921,81 @@ out_list:
> }
>
> /**
> + * i2c_get_number_from_dt - get the adapter number based on dt alias
> + * @adap: the adapter to look at
> + *
> + * Check whether there's an alias in the FDT that gives an ID for this i2c
> + * device. Use an alias like "i2c", like:
> + * aliases {
> + * i2c0 = &i2c_0;
> + * i2c1 = &i2c_1;
> + * };
> + *
> + * Returns the ID if found. If no alias is found returns -1.
> + */
> +static int i2c_get_number_from_dt(struct i2c_adapter *adap)
i2c_get_id_from_dt()?
> +{
> + struct device *dev = &adap->dev;
> + int id;
> +
> + if (!dev->of_node)
> + return -1;
-ESOMETHING?
> +
> + id = of_alias_get_id(dev->of_node, "i2c");
> + if (id < 0)
> + return -1;
> + return id;
Simply 'return of_alias_get_id(...)'? Even more, since this function
boils down to calling of_alias_get_id only and is only used once, I'd
think we can implement that directly and drop this function. That
shouldn't hurt readability.
> +}
> +
> +/**
> + * _i2c_add_numbered_adapter - i2c_add_numbered_adapter where nr is never -1
> + * @adap: the adapter to register (with adap->nr initialized)
> + * Context: can sleep
> + *
> + * See i2c_add_numbered_adapter() for details.
> + */
> +static int _i2c_add_numbered_adapter(struct i2c_adapter *adap)
All other internal functions are prefixed with '__'.
> +{
> + int id;
> + int status;
> +
> + /* Handled by wrappers */
> + BUG_ON(adap->nr == -1);
Is that a reason to halt the kernel? WARN and bailing out would do IMO.
> +
> + if (adap->nr & ~MAX_IDR_MASK)
> + return -EINVAL;
Note the idr-cleanup series from Tejun Heo. Given that his series is
scheduled for v3.9, I'd like to have your patches on top of his.
Thanks,
Wolfram
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC] misc/at24: distinguish between eeprom and fram chips
> what happend to this one ? It was a patch updating Kconfig help for at24. Do you know linux-next? Have a look there... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/5] i2c-i801: Add Device IDs for Intel Wellsburg PCH
> Seth recently sent a patch adding IDs for the Avoton: > http://marc.info/?l=linux-kernel&m=135959209218860&w=2 > > Your patch conflicts with his. Please rebase on top of Seth's patch, so > that both patches can be applied in sequence. Yes, please. > > --- a/drivers/i2c/busses/i2c-i801.c > > +++ b/drivers/i2c/busses/i2c-i801.c > > (...) > > @@ -165,6 +166,7 @@ > > #define PCI_DEVICE_ID_INTEL_DH89XXCC_SMBUS 0x2330 > > #define PCI_DEVICE_ID_INTEL_5_3400_SERIES_SMBUS0x3b30 > > #define PCI_DEVICE_ID_INTEL_LYNXPOINT_SMBUS0x8c22 > > +#define PCI_DEVICE_ID_INTEL_WELLSBURG_SMBUS0x8d22 > > #define PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_SMBUS 0x9c22 > > Please keep sorted by ID. Hum? This table looks sorted by numbers to me, so OK. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] i2c: exynos5: add High Speed I2C controller driver
On Fri, Feb 01, 2013 at 09:24:44PM +0530, Naveen Krishna Chatradhi wrote: > Adds support for High Speed I2C driver found in Exynos5 and later > SoCs from Samsung. This driver currently supports Auto mode. > > Driver only supports Device Tree method. > Note: Added debugfs support for registers view, not tested. > > Signed-off-by: Taekgyun Ko > Signed-off-by: Naveen Krishna Chatradhi > --- > Help please, > > Usual reads and writes are happening. But, when i try doing > i2cdetect -y 0 0x10 0x59; It throws me continous interrupts at 0x1a > i2cdetect -y 0 0x50 0x64; It throws me continous interrupts at 0x63 > > There are eeproms from 0x50 till 0x58 > wm8994 codec at 0x1a > > Kindly, can anyone explain this behaviour. You select I2C_FUNC_SMBUS_EMUL, but make sure your hardware really supports I2C_FUNC_SMBUS_QUICK. That would be my first guess. Also, which eeprom do you have? Check its datasheet, some in deed use 8 addresses. Regards, Wolfram -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
Re: [PATCH V2 0/4] i2c: s3c2410: Add devm_* apis and cleanup
On Fri, Nov 23, 2012 at 02:11:51PM +0530, Tushar Behera wrote: > This patchset cleans up the probe function of i2c-s3c2410 driver. > These have been tested on Exynos4210 based Origen board. > > Changes since V1: > * devm_request_mem_region and devm_ioremap calls were replaced by > devm_request_and_ioremap() call. > * All devm_* related modifications (earlier patches 2-5) were merged > to a single patch. > Patch series looks good. Can you rebase to 3.8-rc4? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC] misc/at24: distinguish between eeprom and fram chips
On Fri, Dec 07, 2012 at 11:14:28AM +0100, Lars Poeschel wrote: > > > > > I wanted to use a fm24c04 i2c fram chip with linux. I grepped the > > > > > source and found nothing. I later found that my chip can be handled > > > > > by at24 eeprom driver. It creates a sysfs file called eeprom to > > > > > read from and write to the chip. Userspace has no chance to > > > > > distinguish if it is writing an eeprom or a fram chip. > > > > > > > > Why should it? > > > > > > Because writes are much faster and it doesn't have to take care on erase > > > cycles. It could use other write strategies on such devices and update > > > informations that have to survive power downs more often. > > > > I agree. I think that a seperate attribute named e.g. 'page_size' would > > be more helpful than renaming the binary file to fram? > > Yes, this is a much better solution! Adding a seperate sysfs file page_size > and a file for the type of device which would read eeprom, fram, etc then. > If you also think this is the way to go, I would spent one of my next free > timeslots to this. Oops, this mail seems to have dropped off :( I am all for the 'page_size' attribute, but still not convinced what gain the 'type' attribute would allow. For FRAM, the page size will be large. Isn't this enough information? Regards, Wolfram -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers: i2c-nforce2: fix coding style issues
On Thu, Jan 10, 2013 at 03:07:42PM +0100, Laurent Navet wrote:
> avoid these checkpatch.pl issues :
> - ERROR: "foo * bar" should be "foo *bar"
> - ERROR: switch and case should be at the same indent
> - ERROR: "(foo*)" should be "(foo *)"
> - ERROR: do not use assignment in if condition
> - ERROR: space required before the open parenthesis '('
> - WARNING: suspect code indent for conditional statements
> - WARNING: quoted string split across lines
> - WARNING: space prohibited between function name and open parenthesis '('
> - WARNING: line over 80 characters
> also add spaces around some "+", "=", "*"
>
> Signed-off-by: Laurent Navet
Thanks, applied to for-next.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i2c: tegra: add support for Tegra114 SoC
On Sat, Jan 05, 2013 at 05:34:46PM +0530, Laxman Dewangan wrote: > NVIDIA's Tegra114 has following enhanced feature in i2c controller: > - Enable/disable control for per packet transfer complete interrupt. > Earlier SoCs could not disable this. > - Single clock source for standard/fast and HS mode clock speed. > The clock divisor for fast/standard mode is added into the i2c > controller to meet the HS and standard/fast mode of clock speed > from single source. > > Add support for the above feature to make it functional on T114 SOCs. Thanks, applied to next. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] i2c-designware: add Intel Lynxpoint support
On Thu, Jan 17, 2013 at 12:31:03PM +0200, Mika Westerberg wrote: > Hi all, > > This series adds support for the Intel Lynxpoint Low Power Subsystem I2C > controllers. They are compatible with the DesignWare I2C controller. > > Patches [1/4] and [2/4] are fixes that are necessary to get the driver > working on Lynxpoint. > > Patch [3/4] brings minimal runtime PM support for the designware platform > driver. This is useful if the PM subsystem/domain implements runtime PM, > like in case of ACPI. > > Patch [4/4] finally implements ACPI enumeration support for the designware > platform driver and adds Lynxpoint ACPI IDs. I can't tell much about ACPI usage, but rest looks good to me. Applied to next. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] i2c-core: Add gpio based bus arbitration implementation
Hi, On Sat, Dec 15, 2012 at 11:21:36PM +0900, Mark Brown wrote: > On Fri, Dec 14, 2012 at 09:06:49AM -0700, Stephen Warren wrote: > > On 12/13/2012 10:50 PM, Naveen Krishna Chatradhi wrote: > > > > +The first should be an output, and is used to claim the I2C bus, > > > +the second should be an input, and signals that the other side (Client) > > > +wants to claim the bus. This allows two masters to share the same I2C > > > bus. > > > I'm confused why this is even needed; the I2C protocol itself defines > > how multi-master is supposed to work, just using the regular SCL/SDA lines. > > Practically speaking essentially no systems actually do that - mostly > Linux will treat failure to get the bus as an error for example. It is true that Linux currently does not have proper multi-master support. It is worth a look what is missing and how far we can get with the I2C specified arbitration IMO. > also get things like read operations which appear as multiple > transactions on the I2C bus so require something higher level than what > multi-master provides. I don't get what you mean here. Can you elaborate? That being said. Grant's design was the most promising one. Thanks, Wolfram -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
Re: [PATCH 1/2] i2c-core: Add gpio based bus arbitration implementation
On Thu, Jan 24, 2013 at 07:18:47PM +0800, Mark Brown wrote: > On Thu, Jan 24, 2013 at 12:13:29PM +0100, Wolfram Sang wrote: > > On Sat, Dec 15, 2012 at 11:21:36PM +0900, Mark Brown wrote: > > > > also get things like read operations which appear as multiple > > > transactions on the I2C bus so require something higher level than what > > > multi-master provides. > > > I don't get what you mean here. Can you elaborate? > > A read is typically implemented as a write of the register address > followed by a read of the value, usually with the ability to free the > bus in between. If two devices attempt to access the register map > simultaneously this results in the address going wrong. Could happen. But in what situations will one not use repeated start here? Especially when designing a multi-master bus? -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
Re: [PATCH 1/2] i2c-s3c2410: Leave the bus disabled unless it is in use
On Thu, Nov 29, 2012 at 10:35:34AM +0530, Naveen Krishna Chatradhi wrote:
> From: Simon Glass
>
> There is a rather odd feature of the exynos i2c controller that if it
> is left enabled, it can lock itself up with the clk line held low.
> This makes the bus unusable.
>
> Unfortunately, the s3c24xx_i2c_set_master() function does not notice
> this, and reports a timeout. From then on the bus cannot be used until
> the AP is rebooted.
>
> The problem happens when any sort of interrupt occurs (e.g. due to a
> bus transition) when we are not in the middle of a transaction. We
> have seen many instances of this when U-Boot leaves the bus apparently
> happy, but Linux cannot access it.
>
> The current code is therefore pretty fragile.
>
> This fixes things by leaving the bus disabled unless we are actually
> in a transaction. We enable the bus at the start of the transaction and
> disable it at the end. That way we won't get interrupts and will not
> lock up the bus.
>
> It might be possible to clear pending interrupts on start-up, but this
> seems to be a more robust solution. We can't service interrupts when
> we are not in a transaction, and anyway would rather not lock up the
> bus while we try.
>
> Signed-off-by: Simon Glass
> Cc: Grant Grundler
> Signed-off-by: Naveen Krishna Chatradhi
So, I assume this patch is still needed despite the ongoing discussion
about arbitration?
> ---
> drivers/i2c/busses/i2c-s3c2410.c | 37 +
> 1 file changed, 33 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-s3c2410.c
> b/drivers/i2c/busses/i2c-s3c2410.c
> index e93e7d6..2fd346d 100644
> --- a/drivers/i2c/busses/i2c-s3c2410.c
> +++ b/drivers/i2c/busses/i2c-s3c2410.c
> @@ -186,6 +186,31 @@ static inline void s3c24xx_i2c_enable_irq(struct
> s3c24xx_i2c *i2c)
> writel(tmp | S3C2410_IICCON_IRQEN, i2c->regs + S3C2410_IICCON);
> }
>
> +/*
> + * Disable the bus so that we won't get any interrupts from now on, or try
> + * to drive any lines. This is the default state when we don't have
> + * anything to send/receive.
> + *
> + * If there is an event on the bus, or we have a pre-existing event at
Otherwise, if...
> + * kernel boot time, we may not notice the event and the I2C controller
> + * will lock the bus with the I2C clock line low indefinitely.
> + */
> +static inline void s3c24xx_i2c_disable_bus(struct s3c24xx_i2c *i2c)
> +{
> + unsigned long tmp;
> +
> + /* Stop driving the I2C pins */
> + tmp = readl(i2c->regs + S3C2410_IICSTAT);
> + tmp &= ~S3C2410_IICSTAT_TXRXEN;
> + writel(tmp, i2c->regs + S3C2410_IICSTAT);
> +
> + /* We don't expect any interrupts now, and don't want send acks */
> + tmp = readl(i2c->regs + S3C2410_IICCON);
> + tmp &= ~(S3C2410_IICCON_IRQEN | S3C2410_IICCON_IRQPEND |
> + S3C2410_IICCON_ACKEN);
> + writel(tmp, i2c->regs + S3C2410_IICCON);
> +}
> +
>
> /* s3c24xx_i2c_message_start
> *
> @@ -646,7 +671,11 @@ static int s3c24xx_i2c_doxfer(struct s3c24xx_i2c *i2c,
>
> s3c24xx_i2c_wait_idle(i2c);
>
> + s3c24xx_i2c_disable_bus(i2c);
> +
> out:
> + i2c->state = STATE_IDLE;
> +
Why is the state change after the label?
> return ret;
> }
>
> @@ -912,7 +941,6 @@ static void s3c24xx_i2c_dt_gpio_free(struct s3c24xx_i2c
> *i2c)
>
> static int s3c24xx_i2c_init(struct s3c24xx_i2c *i2c)
> {
> - unsigned long iicon = S3C2410_IICCON_IRQEN | S3C2410_IICCON_ACKEN;
> struct s3c2410_platform_i2c *pdata;
> unsigned int freq;
>
> @@ -926,12 +954,12 @@ static int s3c24xx_i2c_init(struct s3c24xx_i2c *i2c)
>
> dev_info(i2c->dev, "slave address 0x%02x\n", pdata->slave_addr);
>
> - writel(iicon, i2c->regs + S3C2410_IICCON);
> + writel(0, i2c->regs + S3C2410_IICCON);
> + writel(0, i2c->regs + S3C2410_IICSTAT);
>
> /* we need to work out the divisors for the clock... */
>
> if (s3c24xx_i2c_clockrate(i2c, &freq) != 0) {
> - writel(0, i2c->regs + S3C2410_IICCON);
> dev_err(i2c->dev, "cannot meet bus frequency required\n");
> return -EINVAL;
> }
> @@ -939,7 +967,8 @@ static int s3c24xx_i2c_init(struct s3c24xx_i2c *i2c)
> /* todo - check that the i2c lines aren't being dragged anywhere */
>
> dev_info(i2c->dev, "bus frequency set to %d KHz\n", freq);
> - dev_dbg(i2c->dev, "S3C2410_IICCON=0x%02lx\n", iicon);
> + dev_dbg(i2c->dev, "S3C2410_IICCON=0x%02x\n",
> + readl(i2c->regs + S3C2410_IICCON));
>
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang|
Industrial Linux Solutions | http://www.pengutronix.de/ |
signature.asc
Description: Digital signature
Re: question about drivers/i2c/busses/i2c-davinci.c
On Sun, Jan 06, 2013 at 09:00:59PM +0100, Julia Lawall wrote: > The function davinci_i2c_remove in drivers/i2c/busses/i2c-davinci.c > contains the following code: > > put_device(&pdev->dev); > > clk_disable_unprepare(dev->clk); > clk_put(dev->clk); > dev->clk = NULL; > > davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, 0); > free_irq(dev->irq, dev); > > Is there any danger in putting free_irq(dev->irq, dev); after > put_device(&pdev->dev);, because the interrupt handler > i2c_davinci_isr can eg refer to dev->dev. Not having a clock doesn't sound exactly thrilling either when servicing an interrupt. I've seen something like this in the remove path of another driver today as well. I assume a lot of drivers might have such issues. It is also one of the subtle issues with devm_request_irq. The remove path can already render the ISR unusable/oopsable but devm will free the interrupt only after remove has finished. Interrupts need to be properly masked out before. Regards, Wolfram -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
Re: [PATCH] at24: extend driver to allow writing via i2c_smbus_write_byte_data
On Wed, Dec 19, 2012 at 05:07:09PM +0100, Christian Gmeiner wrote:
> I have a at24 EEPROM connected via i2c bus provided by ISCH i2c
> bus driver. This bus driver does not support
> I2C_FUNC_SMBUS_WRITE_I2C_BLOCK and so I was looking for a way
> to be able to write the eeprom. This patch adds support for
> I2C_SMBUS_BYTE_DATA writing via i2c_smbus_write_byte_data.
> It is quite slow, but it works.
>
> Signed-off-by: Christian Gmeiner
> ---
> drivers/misc/eeprom/at24.c | 35 +--
> 1 file changed, 29 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
> index 2baeec5..723b411 100644
> --- a/drivers/misc/eeprom/at24.c
> +++ b/drivers/misc/eeprom/at24.c
> @@ -56,6 +56,7 @@ struct at24_data {
> struct at24_platform_data chip;
> struct memory_accessor macc;
> int use_smbus;
> + int use_smbuse_write;
Can't you use the same 'use_smbus' variable and do a similar switch-case
as in the read function?
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang|
Industrial Linux Solutions | http://www.pengutronix.de/ |
signature.asc
Description: Digital signature
Re: [PATCH 3/3] i2c-i801: SMBus patch for Intel Avoton DeviceIDs
> @@ -166,6 +167,7 @@ > #define PCI_DEVICE_ID_INTEL_5_3400_SERIES_SMBUS 0x3b30 > #define PCI_DEVICE_ID_INTEL_LYNXPOINT_SMBUS 0x8c22 > #define PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_SMBUS 0x9c22 > +#define PCI_DEVICE_ID_INTEL_AVOTON_SMBUS 0x1f3c This seems to be sorted, please stick to that. -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
[PULL REQUEST] i2c for 3.9
Linus, here are the changes for the i2c subsystem for 3.9. Highlights: * new drivers for Intel ismt & Broadcom bcm2835 * a number of drivers got support for more variants and mostly got cleaned up on the way (sis630, i801, at91, tegra, designware) * i2c got rid of all *_set_drvdata(..., NULL) on remove/probe failure * removed the i2c_smbus_process_call from the core since there are no users * mxs can now switch between PIO and DMA depending on the message size and the bus speed can now be arbitrary In addition, there is the usual bunch of fixes, cleanups, devm_* conversions, etc. Please pull. Thanks, Wolfram The following changes since commit 949db153b6466c6f7cad5a427ecea94985927311: Linux 3.8-rc5 (2013-01-25 11:57:28 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/for-next for you to fetch changes up to 55827f4aa6442ddd1d6a4e1e32f2f457eb113c22: i2c: Remove unneeded xxx_set_drvdata(..., NULL) calls (2013-02-22 00:25:50 +0100) Alexander Stein (1): i2c: isch: Add module parameter for backbone clock rate if divider is unset Amaury Decrême (6): i2c: sis630: Add SIS964 support i2c: sis630: clear sticky bits i2c: sis630: fix behavior after collision i2c: sis630: use hex to constants for SMBus commands i2c: sis630: display unsigned hex i2c: sis630: checkpatch cleanup Dmitry Torokhov (1): i2c: pxa: remove incorrect __exit annotations Doug Anderson (1): i2c: Remove unneeded xxx_set_drvdata(..., NULL) calls Giridhar Maruthy (1): i2c: s3c2410: Add quirk to exclude GPIO config for exynos5440 Guennadi Liakhovetski (4): i2c: sh_mobile: cosmetic: trivially simplify 2 functions i2c: sh_mobile: fix timeout error handling i2c: sh_mobile: eliminate an open-coded "goto" loop i2c: sh_mobile: don't send a stop condition by default inside transfers James Ralston (1): i2c: i801: Add Device IDs for Intel Wellsburg PCH Jayachandran C (1): i2c: ocores: Fix pointer to integer cast warning Joachim Eastwood (2): i2c: at91: add of_device_id entry for at91rm9200 i2c: at91: fix unsed variable warning when building with !CONFIG_OF Lars Poeschel (1): drivers: misc: at24: mention other supported types in Kconfig Laurent Navet (1): i2c: nforce2: fix coding style issues Laxman Dewangan (2): i2c: tegra: add support for Tegra114 SoC i2c: tegra: remove warning dump if timeout happen in transfer Marek Vasut (2): i2c: mxs: Add PIO and mixed-DMA support i2c: mxs: Implement arbitrary clock speed derivation algorithm Mika Westerberg (3): i2c-designware: always set the STOP bit after last byte i2c-designware: add minimal support for runtime PM i2c-designware: add support for Intel Lynxpoint Neil Horman (2): i2c: Adding support for Intel iSMT SMBus 2.0 host controller i2c: ismt: Add Seth and Myself as maintainers Patrice Chotard (1): i2c: nomadik: adopt pinctrl support Randy Dunlap (1): i2c: fix i2c-ismt.c printk format warning Seth Heasley (1): i2c: i801: SMBus patch for Intel Avoton DeviceIDs Stephen Warren (1): i2c: add bcm2835 driver Tushar Behera (5): i2c: core: Remove definition of i2c_smbus_process_call i2c: s3c2410: Remove unnecessary label err_noclk i2c: s3c2410: Convert to use devm_* APIs i2c: s3c2410: Move location of clk_prepare_enable() call in probe function i2c: s3c2410: Remove err_cpufreq label Wolfram Sang (1): i2c: nomadik: drop superfluous variable initialization .../devicetree/bindings/i2c/brcm,bcm2835-i2c.txt | 20 + .../devicetree/bindings/i2c/i2c-s3c2410.txt|2 + Documentation/i2c/busses/i2c-i801 |2 + Documentation/i2c/busses/i2c-ismt | 36 + Documentation/i2c/busses/i2c-sis630|9 + Documentation/i2c/smbus-protocol |4 +- Documentation/i2c/writing-clients |4 +- MAINTAINERS|7 + drivers/i2c/busses/Kconfig | 28 +- drivers/i2c/busses/Makefile|2 + drivers/i2c/busses/i2c-at91.c | 17 +- drivers/i2c/busses/i2c-au1550.c|1 - drivers/i2c/busses/i2c-bcm2835.c | 342 +++ drivers/i2c/busses/i2c-bfin-twi.c |2 - drivers/i2c/busses/i2c-cpm.c |2 - drivers/i2c/busses/i2c-davinci.c |2 - drivers/i2c/busses/i2c-designware-core.c | 16 +- drivers/i2c/busses/i2c-designware-pcidrv.c |2 - drivers/i2c/busses/i2c-designware-platdrv.c| 61 +- drivers/i2c/busses/i2c-eg20t.c |2 - drivers/i2c/busses/i2c-highlander.c
Re: I2C: Fix i2c fail problem when a process is terminated by a signal on octeon in 3.8
On Tue, Feb 26, 2013 at 11:02:17AM +0100, Jiri Kosina wrote: > On Fri, 22 Feb 2013, 송은봉 wrote: > > > > > > > > > I've been debugging the abnormal operation of i2c on octeon. > > If a process is terminated by signal in the middle of i2c operation, > > next i2c read operation which is done by another process was failed. > > So i changed to ignore signal in the middle of i2c operation. > > After that the problem was not reproduced. > > This is not really material directly for trivial.git. Adding maintainers > to CC. Yes, this should not go via trivial. Please resend to i2c list. Patch looks okay from a glimpse (and fixes an issue we have seen before and fixed the same way). Thanks, Wolfram -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] shmem: fix build regression
commit 6b4d0b27 (clean shmem_file_setup() a bit) broke allnoconfig since
this needs the NOMMU path where 'error' is still needed:
mm/shmem.c:2935:2: error: 'error' undeclared (first use in this function)
Signed-off-by: Wolfram Sang
Cc: Al Viro
---
mm/shmem.c |1 +
1 file changed, 1 insertion(+)
diff --git a/mm/shmem.c b/mm/shmem.c
index ed2befb..56ff7d7 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -2897,6 +2897,7 @@ static struct dentry_operations anon_ops = {
*/
struct file *shmem_file_setup(const char *name, loff_t size, unsigned long
flags)
{
+ int error;
struct file *res;
struct inode *inode;
struct path path;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/2] Add automatic bus number support for i2c busses with device tree
> > Doug Anderson (2): > > i2c-core: dt: Pick i2c bus number from i2c alias if present > > i2c: pxa: Use i2c-core to get bus number now > > > > drivers/i2c/busses/i2c-pxa.c | 20 > > drivers/i2c/i2c-core.c | 54 > > > > 2 files changed, 49 insertions(+), 25 deletions(-) > > Is there anything else needed for this patch series? It's been > hanging around for quite a while and it would be nice to see it land. > If you're waiting for additional acks or reviews I'll ask around and > see if I can get them... Regarding patch 1, I was waiting for the idr changes to hit mainline. They are mainline now, but since the removal of MAX_IDR_MASK your patch doesn't apply anymore :( Can you rebase and retest, please? I'd like to get it into 3.9, still. For patch 2, some Tested-by would be nice; but it will probably make it into my for-next somewhen after rc1 is out. Thanks, Wolfram -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] I2C: i2c-pxa - remove incorrect __exit annotations
On Wed, Feb 20, 2013 at 12:50:10AM -0800, Dmitry Torokhov wrote: > The remove() methods should not be marked __exit unless we are using > platform_driver_probe() which disables unbinding device from driver > via sysfs. > > Signed-off-by: Dmitry Torokhov Eeks, I broke this with my very first linux patch years ago :) Applied to -next, thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] i2c: nomadik: Add Device Tree support to the Nomadik I2C driver
On Thu, Aug 23, 2012 at 04:01:27PM +0100, Lee Jones wrote:
> Here we apply the bindings required for successful Device Tree
> probing of the i2c-nomadik driver.
>
> Cc: linux-...@vger.kernel.org
> Acked-by: srinidhi kasagar
Two acks? I'd think this cannot work for multiple reasons.
BTW, patch 2 and 3 should be merged. It is a lot easier to review the
code with the binding description together.
Is there some dependency other than updating the dts files? If not, I'd
like to pick up the patch via I2C.
> Signed-off-by: Lee Jones
> ---
> drivers/i2c/busses/i2c-nomadik.c | 28
> 1 file changed, 28 insertions(+)
>
> diff --git a/drivers/i2c/busses/i2c-nomadik.c
> b/drivers/i2c/busses/i2c-nomadik.c
> index 61b00ed..8168389 100644
> --- a/drivers/i2c/busses/i2c-nomadik.c
> +++ b/drivers/i2c/busses/i2c-nomadik.c
> @@ -25,6 +25,7 @@
> #include
> #include
> #include
> +#include
>
> #define DRIVER_NAME "nmk-i2c"
>
> @@ -920,15 +921,42 @@ static struct nmk_i2c_controller u8500_i2c = {
> .sm = I2C_FREQ_MODE_FAST,
> };
>
> +static void nmk_i2c_of_probe(struct device_node *np,
> + struct nmk_i2c_controller *pdata)
> +{
> + /* Provide the default configuration as a base. */
> + pdata = &u8500_i2c;
?? I wonder how that could work... have you tested the patch?
> +
> + of_property_read_u32(np, "clock-frequency", (u32*)&pdata->clk_freq);
Might be worth changing clk_freq to u32?
> +
> + /* This driver only supports 'standard' and 'fast' modes of operation.
> */
> + if (pdata->clk_freq <= 10)
> + pdata->sm = I2C_FREQ_MODE_STANDARD;
Is standard == 10 Hz?
> + else
> + pdata->sm = I2C_FREQ_MODE_FAST;
If those two are fixed frequencies, you should omit a warning if the
devicetree has a different frequency set and report which one is going
to be used actually.
> +}
> +
> static atomic_t adapter_id = ATOMIC_INIT(0);
>
> static int nmk_i2c_probe(struct amba_device *adev, const struct amba_id *id)
> {
> int ret = 0;
> struct nmk_i2c_controller *pdata = adev->dev.platform_data;
> + struct device_node *np = adev->dev.of_node;
> struct nmk_i2c_dev *dev;
> struct i2c_adapter *adap;
>
> + if (np) {
> + if (!pdata) {
> + pdata = devm_kzalloc(&adev->dev, sizeof(*pdata),
> GFP_KERNEL);
> + if (!pdata) {
> + ret = -ENOMEM;
> + goto err_no_mem;
> + }
> + }
> + nmk_i2c_of_probe(np, pdata);
> + }
> +
> if (!pdata)
> /* No i2c configuration found, using the default. */
> pdata = &u8500_i2c;
> --
> 1.7.9.5
>
--
Pengutronix e.K. | Wolfram Sang|
Industrial Linux Solutions | http://www.pengutronix.de/ |
signature.asc
Description: Digital signature
Re: [PATCH 3/3] i2c: nomadik: Add Device Tree support to the Nomadik I2C driver
On Mon, Sep 03, 2012 at 11:22:28AM +0200, Linus Walleij wrote:
> On Fri, Aug 31, 2012 at 2:23 PM, Lee Jones wrote:
>
> (...)
> > static int nmk_i2c_probe(struct amba_device *adev, const struct amba_id
> > *id)
> > {
> > int ret = 0;
> > struct nmk_i2c_controller *pdata = adev->dev.platform_data;
> > + struct device_node *np = adev->dev.of_node;
> > struct nmk_i2c_dev *dev;
> > struct i2c_adapter *adap;
> >
> > + if (np) {
> > + if (!pdata) {
>
> So, if no pdata is provided, we go on to allocate some ...
>
> > + pdata = devm_kzalloc(&adev->dev, sizeof(*pdata),
> > GFP_KERNEL);
> > + if (!pdata) {
> > + ret = -ENOMEM;
> > + goto err_no_mem;
> > + }
> > + }
> > + /* Provide the default configuration as a base. */
> > + pdata = &u8500_i2c;
>
> Then you just override that pointer with a pointer to the local config.
>
> > + nmk_i2c_of_probe(np, pdata);
> > + }
> > +
> > if (!pdata)
> > /* No i2c configuration found, using the default. */
> > pdata = &u8500_i2c;
>
> This in it's entirety does not look sound. I *think* this is what you
> want to do,
> replace all of the above codde (including the last if (!pdata) clause) with:
>
> if (!pdata) {
> /* If no platform data passed in, use the default configuration as
> a base. */
> pdata = &u8500_i2c;
> if (np)
> /* Further, if we have a DT node, override the default with this */
> nmk_i2c_of_probe(np, pdata);
> }
>
> This makes any passed pdata take precedence, else default pdata
> complemented with DT info. Which is what we want.
No. of_probe modifies pdata which in this case the default config which
might already be in use. So, you will get problems if you have two
instances with different configuration. So, we need to allocate memory
but copy the content of the default data. The patch above just copies
the pointer which is bogus.
--
Pengutronix e.K. | Wolfram Sang|
Industrial Linux Solutions | http://www.pengutronix.de/ |
signature.asc
Description: Digital signature
Re: [PATCH RESEND 1/2] i2c: pnx: Fix bit definitions
On Mon, Sep 03, 2012 at 10:16:22PM +0200, Roland Stigge wrote: > Hi Wolfram, > > On 20/08/12 19:55, Wolfram Sang 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 are any PNX4008's in the wild, and even working in > >> NXP, I can't find any non-marketing reference material for that > >> part (including the user manual). > > > > Thanks for the heads up. I'll apply both patches, then. > > Should I consider the two patches as applied now (where? > i2c-embedded?), or should I resend? ;-) I will apply them these days and then let them stay in linux-next for a few days. So, I'd think they should go in for rc6. -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
Re: [PATCH v11 3/4] drivers/i2c/busses/i2c-at91.c: add new driver
On Tue, Sep 11, 2012 at 10:26:39AM +0200, Nicolas Ferre wrote: > On 08/27/2012 04:29 PM, Voss, Nikolaus : > > ludovic.desroches wrote on Monday, August 27, 2012 4:00 PM : > >> For the moment, I don't have the necessary knowledge about the TWI > >> controller to take a decision. I would say it can be done in an other > >> patch in order to have your driver included in the mainline quickly > >> since it doesn't introduce a breakage. > > > > That would be the most pragmatic approach. > > Wolfram, is the anything left to do from my side? > > Wolfram, ping? > > Can we imagine to have this support and the device tree patches from > Ludovic in 3.7-final? Yes. I'd need your ack since it touches mach-specific stuff. Reviewed-by would be even better since you know the HW better than me :) -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
Re: [PATCH 12/19] i2c-nomadik: Register sub-devices when passed via Device Tree
On Mon, Sep 10, 2012 at 04:42:36AM -0700, Linus Walleij wrote: > On Fri, Sep 7, 2012 at 1:14 PM, Lee Jones wrote: > > > Each I2C device can be correctly probed already using Device Tree, > > but the sub-devices still have to be registered by calls to > > i2c_register_board_info(). After this patch, each sub-device can > > be registered directly from Device Tree instead, removing the > > requirement for the aforementioned calls from platform code. > > > > CC: linux-...@vger.kernel.org > > CC: Wolfram Sang > > Signed-off-by: Lee Jones > > The patch as such is fine. > Acked-by: Linus Walleij > > ...but there will be merge issues (of the type I'm > discussing with Arnd in another thread). > > > --- > > drivers/i2c/busses/i2c-nomadik.c |4 > > 1 file changed, 4 insertions(+) > > > > diff --git a/drivers/i2c/busses/i2c-nomadik.c > > b/drivers/i2c/busses/i2c-nomadik.c > > index 5d1a970..01231c2 100644 > > --- a/drivers/i2c/busses/i2c-nomadik.c > > +++ b/drivers/i2c/busses/i2c-nomadik.c > > @@ -26,6 +26,7 @@ > > #include > > #include > > #include > > +#include > > This is clearly dependent on the other patches to I2C to > be merged first (the include above is not yet there in > linux-next even), so this patch should go into Wolfram's > tree right? Else we have to rip out all the patches to the > I2C driver from his tree and funnel it all through ARM SoC. First, I'd like to have this patch squashed with "i2c: nomadik: Add Device Tree support to the Nomadik I2C driver". I wanted to do this on my own, but the patches do not apply to 3.6-rc5 (with or without regulator removal patch from Linus)? I can also take the I2C related changes to the devicetrees via my tree. This is not uncommon. Some people prefer to do this via their soc-trees, though. I don't care much since this is not really a hard dependency causing build failures or merge conflicts, but just needs a little extra time until the patches are all there... Thanks, Wolfram -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
[PATCH] MAINTAINERS: fix tree for current i2c-embedded development
Guide people to where their patches can be found these days. Signed-off-by: Wolfram Sang --- MAINTAINERS |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index fdc0119..53cc13c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3388,7 +3388,7 @@ M:"Wolfram Sang (embedded platforms)" L: linux-...@vger.kernel.org W: http://i2c.wiki.kernel.org/ T: quilt kernel.org/pub/linux/kernel/people/jdelvare/linux-2.6/jdelvare-i2c/ -T: git git://git.fluff.org/bjdooks/linux.git +T: git git://git.pengutronix.de/git/wsa/linux.git S: Maintained F: Documentation/i2c/ F: drivers/i2c/ -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i2c:clk: preparation for switch to common clock framework
On Thu, Aug 30, 2012 at 06:10:36PM -, m-kariche...@ti.com wrote: > As a first step towards migrating davinci platforms to use common clock > framework, replace all instances of clk_enable() with clk_prepare_enable() > and clk_disable() with clk_disable_unprepare(). Until the platform is > switched to use the CONFIG_HAVE_CLK_PREPARE Kconfig variable, this just > adds a might_sleep() call and would work without any issues. > > This will make it easy later to switch to common clk based implementation > of clk driver from DaVinci specific driver. > > Signed-off-by: Murali Karicheri Subject had "i2c:clk" where "i2c: davinci" would be more precise. Fixed that and pushed to -next. Thanks, Wolfram -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
Re: [PATCH 1/4] i2c: introduce i2c-cbus driver
On Mon, Sep 03, 2012 at 11:23:22PM +0300, Aaro Koskinen wrote: > Add i2c driver to enable access to devices behind CBUS on Nokia Internet > Tablets. > > The patch also adds CBUS I2C configuration for N8x0 which is one of the > users of this driver. > > Cc: linux-...@vger.kernel.org > Acked-by: Felipe Balbi > Acked-by: Tony Lindgren > Signed-off-by: Aaro Koskinen My main question is: what is CBUS? It doesn't look like an I2C/SMBUS host controller, but some bit-banging protocol? As such, it shouldn't go to i2c/busses/. And the protocol doesn't look much like I2C, neither. There is no ACK/NACK/START/STOP, so I wonder if it should be in i2c after all... Jean, maybe you want to have a glimpse on this as well? Regards, Wolfram -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
Re: [PATCH 12/19] i2c-nomadik: Register sub-devices when passed via Device Tree
Hi, > > First, I'd like to have this patch squashed with "i2c: nomadik: Add > > Device Tree support to the Nomadik I2C driver". I wanted to do this on > > my own, but the patches do not apply to 3.6-rc5 (with or without > > regulator removal patch from Linus)? > > I'm really not keen on squashing all my patches together. They are > clearly have very different purposes. If you think they are closely > related, then pull them in sequentially, but please don't squash > all my work into a single patch for no other reason than convenience. I can't follow this reasoning. I never asked you to squash all patches, only those two needed to get proper device tree support. Why would you want to let the device being detected via DT and not scan the child nodes immediately? > > I can also take the I2C related changes to the devicetrees via my tree. > > This is not uncommon. Some people prefer to do this via their soc-trees, > > though. I don't care much since this is not really a hard dependency > > causing build failures or merge conflicts, but just needs a little extra > > time until the patches are all there... > > It would be better for all the Device Tree changes go in as a single > patch-set. Again, I don't care where they go, so long as they go in > together. arm-soc seems like the most generic place for them to be > pulled into though. This reasoning I can follow, but how should I know you aimed for that? I only saw a patch [3/3] in one series making the driver probable via DT and a patch [12/19] in another series to scan the child nodes. That's all the infos I got. Some more context would have been helpful. Is there a branch somewhere with all the things collected? Regards, Wolfram -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
Re: [PATCH 12/19] i2c-nomadik: Register sub-devices when passed via Device Tree
> Ah, sorry. That's my fault for rushing though my ridiculously bloated post- > vacation inbox. :) > > all the infos I got. Some more context would have been helpful. Is there > > a branch somewhere with all the things collected? > > There will be. I'm currently just Ack collecting. > > In fact wait ... > > <3 mins pass> > > Now there is: > git://git.linaro.org/people/ljones/linux-3.0-ux500.git preview-for-next OK from having a glimpse, I'd prefer to squash (or have squashed) i2c: nomadik: Add Device Tree support to the Nomadik I2C driver Documentation: Device Tree binding information for i2c-nomadik driver (Documentation should go along with the code) i2c-nomadik: Register sub-devices when passed via Device Tree into one patch and take that via the I2C tree. This will allow me to resolve the merge conflict in my tree on my own. I don't see a strong reason to have those go via arm-soc (like prevented build-failures or easier merges), if I missed such a reason, please let me know. Regards, Wolfram -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
Re: [PATCH 1/4] i2c: introduce i2c-cbus driver
ERNEL);
> + if (!adapter) {
> + ret = -ENOMEM;
> + goto error;
> + }
> +
> + chost = kzalloc(sizeof(*chost), GFP_KERNEL);
> + if (!chost) {
> + ret = -ENOMEM;
> + goto error_mem;
> + }
> +
> + if (pdev->dev.of_node) {
> + struct device_node *dnode = pdev->dev.of_node;
> + if (of_gpio_count(dnode) != 3) {
> + ret = -ENODEV;
> + goto error_mem;
> + }
> + chost->clk_gpio = of_get_gpio(dnode, 0);
> + chost->dat_gpio = of_get_gpio(dnode, 1);
> + chost->sel_gpio = of_get_gpio(dnode, 2);
> + } else if (pdev->dev.platform_data) {
> + struct i2c_cbus_platform_data *pdata = pdev->dev.platform_data;
> + chost->clk_gpio = pdata->clk_gpio;
> + chost->dat_gpio = pdata->dat_gpio;
> + chost->sel_gpio = pdata->sel_gpio;
> + } else {
> + ret = -ENODEV;
> + goto error_mem;
> + }
> +
> + adapter->owner = THIS_MODULE;
> + adapter->class = I2C_CLASS_HWMON;
> + adapter->dev.parent = &pdev->dev;
> + adapter->nr = pdev->id;
> + adapter->timeout= HZ;
> + adapter->algo = &cbus_i2c_algo;
> + strlcpy(adapter->name, "CBUS I2C adapter", sizeof(adapter->name));
> +
> + spin_lock_init(&chost->lock);
> + chost->dev = &pdev->dev;
> +
> + gpios[0].gpio = chost->clk_gpio;
> + gpios[0].flags = GPIOF_OUT_INIT_LOW;
> + gpios[0].label = "CBUS clk";
> +
> + gpios[1].gpio = chost->dat_gpio;
> + gpios[1].flags = GPIOF_IN;
> + gpios[1].label = "CBUS data";
> +
> + gpios[2].gpio = chost->sel_gpio;
> + gpios[2].flags = GPIOF_OUT_INIT_HIGH;
> + gpios[2].label = "CBUS sel";
> +
> + ret = gpio_request_array(gpios, ARRAY_SIZE(gpios));
> + if (ret)
> + goto error_gpio;
> +
> + gpio_set_value(chost->clk_gpio, 1);
> + gpio_set_value(chost->clk_gpio, 0);
What is that pulse needed for?
> +
> + i2c_set_adapdata(adapter, chost);
> + platform_set_drvdata(pdev, adapter);
> +
> + ret = i2c_add_numbered_adapter(adapter);
> + if (ret)
> + goto error_i2c;
> +
> + return 0;
> +
> +error_i2c:
> + gpio_free_array(gpios, ARRAY_SIZE(gpios));
> +error_gpio:
> + kfree(chost);
> +error_mem:
> + kfree(adapter);
> +error:
> + return ret;
> +}
> +
> +#if defined(CONFIG_OF)
> +static const struct of_device_id i2c_cbus_dt_ids[] = {
> + { .compatible = "i2c-cbus", },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, i2c_cbus_dt_ids);
> +#endif
> +
> +static struct platform_driver cbus_i2c_driver = {
> + .probe = cbus_i2c_probe,
> + .remove = cbus_i2c_remove,
> + .driver = {
> + .owner = THIS_MODULE,
> + .name = "i2c-cbus",
> + },
> +};
> +module_platform_driver(cbus_i2c_driver);
> +
> +MODULE_ALIAS("platform:i2c-cbus");
> +MODULE_DESCRIPTION("CBUS I2C driver");
> +MODULE_AUTHOR("Juha Yrjölä");
> +MODULE_AUTHOR("David Weinehall");
> +MODULE_AUTHOR("Mikko Ylinen");
> +MODULE_AUTHOR("Felipe Balbi");
> +MODULE_AUTHOR("Aaro Koskinen ");
> +MODULE_LICENSE("GPL");
So much for now.
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang|
Industrial Linux Solutions | http://www.pengutronix.de/ |
signature.asc
Description: Digital signature
Re: [PATCH 12/19] i2c-nomadik: Register sub-devices when passed via Device Tree
> > Documentation: Device Tree binding information for i2c-nomadik driver > > (Documentation should go along with the code) > > I'm still not too sure about how this benefits anyone. You can ensure > the documentation is placed in an adjacent patch, so it's just as easy > to make reference to. It makes reviewing a lot easier if the documentation what is supposed to be coded and the actual code are in one place. It also prevents what happened in this case where the documentation never showed up on the i2c-list. -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
[PULL REQUEST] i2c-embedded for 3.6
Linus, please pull the last bunch of (typical) i2c-embedded driver fixes for 3.6. Also update the MAINTAINERS file to point to my tree since people keep asking where to find their patches. Thanks, Wolfram The following changes since commit 55d512e245bc7699a8800e23df1a24195dd08217: Linux 3.6-rc5 (2012-09-08 16:43:45 -0700) are available in the git repository at: git://git.pengutronix.de/git/wsa/linux.git i2c-embedded/for-current for you to fetch changes up to 5f71a3ef3753ac2068009637eee619e163f44b30: i2c: algo: pca: Fix mode selection for PCA9665 (2012-09-14 15:25:22 +0200) Roland Stigge (2): i2c: pnx: Fix bit definitions i2c: pnx: Fix read transactions of >= 2 bytes Thomas Kavanagh (1): i2c: algo: pca: Fix mode selection for PCA9665 Wolfram Sang (2): i2c: mxs: correctly setup speed for non devicetree MAINTAINERS: fix tree for current i2c-embedded development MAINTAINERS |2 +- drivers/i2c/algos/i2c-algo-pca.c |6 ++--- drivers/i2c/busses/i2c-mxs.c | 13 +- drivers/i2c/busses/i2c-pnx.c | 53 ++ include/linux/i2c-pnx.h |1 + 5 files changed, 42 insertions(+), 33 deletions(-) -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
Re: [PATCH REPOST] i2c: tegra: set irq name as device name
On Thu, Nov 01, 2012 at 10:08:14PM +0530, Laxman Dewangan wrote: > When watching the irqs name of tegra i2c, all instances > irq name shows as tegra_i2c. > > Passing the device name properly to have the irq names with > instance like tegra-i2c.0, tegra-i2c.1 etc. > > Signed-off-by: Laxman Dewangan > Acked-by: Jean Delvare Applied to for-current, thanks. -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
[PULL REQUEST] i2c-embedded for 3.7
Linus, please pull bugfixes for i2c-embedded. 2 patches are usual stuff. The bigger patch is needed to correct a wrong decision made in this merge window. We hoped to get the PIOQUEUE mode in the mxs driver working with DMA, but it turned out to be too broken (leading to data loss), so we now think it is best to remove it entirely and work only with DMA now. The patch should be in 3.7. IMO, so users never get the chance to use both modes in parallel. Thanks, Wolfram The following changes since commit 8f0d8163b50e01f398b14bcd4dc039ac5ab18d64: Linux 3.7-rc3 (2012-10-28 12:24:48 -0700) are available in the git repository at: git://git.pengutronix.de/git/wsa/linux.git i2c-embedded/for-current for you to fetch changes up to 91b370a0dbda5de92c2cf4c3bc0d18d6bf08f05f: i2c: tegra: set irq name as device name (2012-11-02 10:52:52 +0100) Laxman Dewangan (1): i2c: tegra: set irq name as device name Philippe Begnic (1): i2c-nomadik: Fixup clock handling Wolfram Sang (1): i2c: mxs: remove broken PIOQUEUE support drivers/i2c/busses/i2c-mxs.c | 186 +++--- drivers/i2c/busses/i2c-nomadik.c |9 +- drivers/i2c/busses/i2c-tegra.c |2 +- 3 files changed, 22 insertions(+), 175 deletions(-) -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
Re: [PATCH] MAINTAINERS: i2c: 7 years, this is it
Jean, > * Wolfram Sang, for joining the crew when it became clear that there > was more review work than Ben and myself could deal with. Thank you for guiding me when I entered the kernel space and again when you entrusted me to do maintainer work in i2c. > I hope I did not forget anyone, please forgive me if I did. > > Another big thank is due to Wolfram again, who quickly proposed to > take over as the main i2c subsystem maintainer. This will allow for a > smooth and fast transition. > > Note that I will keep maintaining all I2C/SMBus controller drivers for > PC systems as well as a few others. I am hereby updating MAINTAINERS > accordingly. I'll also keep maintaining user-space i2c-tools. > > Signed-off-by: Jean Delvare Acked-by: Wolfram Sang -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
[PULL REQUEST] i2c-embedded for 3.6
Linus, please pull the changes for the "embedded" part of the I2C subsystem: * lots of devicetree conversions of drivers (and preparations for that) * big cleanups for drivers for OMAP, Tegra, Nomadik, Blackfin * Rafael's struct dev_pm_ops conversion patches for I2C * usual driver cleanups and fixes All patches have been in linux-next for an apropriate time and all patches touching files outside of i2c-folders should have proper acks from the maintainers. Thanks, Wolfram The following changes since commit 6887a4131da3adaab011613776d865f4bcfb5678: Linux 3.5-rc5 (2012-06-30 16:08:57 -0700) are available in the git repository at: git://git.pengutronix.de/git/wsa/linux.git i2c-embedded/for-next for you to fetch changes up to 5db20c49e2d6581797c17057e068d89d6677aa24: Revert "i2c: tegra: convert normal suspend/resume to *_noirq" (2012-07-24 17:32:45 +0200) Alessandro Rubini (3): i2c-nomadik: move header to i2c-nomadik: turn the platform driver to an amba driver i2c-nomadik: depend on ARM_AMBA, not PLAT_NOMADIK Andrew Lunn (1): I2C: MV64XYZ: Add Device Tree support Fabio Estevam (1): i2c: i2c-imx: Adapt the clock name to the new clock framework Florian Fainelli (1): i2c-mv64: allow more than one driver instance Ganesan Ramalingam (2): i2c: i2c-ocores: Use reg-shift property i2c: i2c-ocores: support for 16bit and 32bit IO Jayachandran C (2): i2c: i2c-ocores: DT bindings and minor fixes. V4L/DVB: mfd: use reg_shift instead of regstep Jon Hunter (1): i2c: omap: Correct I2C revision for OMAP3 Karol Lewandowski (1): i2c: s3c2410: Fix pointer type passed to of_match_node() Laxman Dewangan (8): i2c: tegra: make sure register writes completes i2c: tegra: add PROTOCOL_MANGLING as supported functionality. i2c: tegra: support for I2C_M_NOSTART functionality i2c: tegra: make all resource allocation through devm_* i2c: tegra: remove unused member variable i2c: tegra: use clk_disable_unprepare in place of clk_disable i2c: tegra: use of_match_ptr() for match_table initialization i2c: tegra: convert normal suspend/resume to *_noirq Linus Walleij (2): i2c: stu300: use clk_prepare/unprepare i2c: stu300: use devm managed resources Marc Kleine-Budde (1): i2c: mxs: mxs_i2c_finish_read: mute flase positive uninitialized var Marek Vasut (1): i2c: mxs: Set I2C timing registers for mxs-i2c Mark Brown (1): i2c-s3c2410: Use plain pm_runtime_put() Michael Hennerich (1): i2c: i2c-bfin-twi: Illegal i2c bus lock upon certain transfer scenarios. Neil Brown (1): I2C: OMAP: Fix timeout problem during suspend. Rafael J. Wysocki (7): i2c-at91: Use struct dev_pm_ops for power management i2c-bfin-twi: Use struct dev_pm_ops for power management i2c-ocores: Use struct dev_pm_ops for power management i2c-pnx: Use struct dev_pm_ops for power management i2c-puv3: Use struct dev_pm_ops for power management i2c-stu300: Use struct dev_pm_ops for power management i2c-tegra: Use struct dev_pm_ops for power management Richard Zhao (1): i2c: imx: convert to use managed functions Shubhrajyoti D (12): I2C: OMAP: make omap_i2c_unidle/idle functions depend on CONFIG_PM_RUNTIME I2C: OMAP: Fix the mismatch of pm_runtime enable and disable I2C: OMAP: Fix the interrupt clearing in OMAP4 I2C: OMAP: Prevent the register access after pm_runtime_put in probe I2C: OMAP: Don't check if wait_for_completion_timeout() returns less than zero I2C: OMAP: Fix the crash in i2c remove I2C: OMAP: Handle error check for pm runtime I2C: OMAP: Do not set the XUDF(Transmit underflow) if the underflow is not reached I2C: OMAP: Rename the 1p153 to the erratum id i462 i2c: omap: Annotate the remove code i2c: omap: Use SET_RUNTIME_PM_OPS i2c: omap: Do not initialise the completion everytime Sonic Zhang (7): i2c: i2c-bfin-twi: Improve the patch for bug "Illegal i2c bus lock upon certain transfer scenarios". i2c: i2c-bfin-twi: Break dead waiting loop if i2c device misbehaves. i2c: i2c-bfin-twi: Tighten condition when failing I2C transfer if MEN bit is reset unexpectedly. i2c:i2c-bfin-twi: TWI fails to restart next transfer in high system load. i2c:i2c-bfin-twi: include twi head file i2c: i2c-bfin-twi: Move TWI peripheral pin request array to platform data. i2c: i2c-bfin-twi: Move blackfin TWI register access Macro to head file. Tasslehoff Kjappfot (1): I2C: OMAP: prevent the overwrite of the errata flags Virupax Sadashivpetimath (1): i2c-nomadik: Add 10-bit addressing support Wolfram Sang (4): devicetree: bindings: gpio-i2c belongs to i2c not gpio i2c: imx: make bitrate an u32 type i2c: mv64xx
Re: [PATCH v5] gpio: pcf857x: Add OF support
> The driver should support the same chip models reardless of whether it's used > with or without DT. If an entry in the OF table has no corresponding entry in > the I2C table I would consider that as a driver bug. Linus Walleij posted a patch to support DT only probing, but too many side-effects showed up. Some were fixable (probe regressions) and some need more work, if feasible at all. Most prominent is that runtime instantiation of i2c slaves currently needs an entry in the i2c table. signature.asc Description: Digital signature
Re: [PATCH v3 1/1 resend] i2c: rcar: modify I2C driver
On Tue, Aug 27, 2013 at 04:55:22PM +0900, Nguyen Viet Dung wrote:
> This patch modify I2C driver of rcar-H1 to usable on both rcar-H1 and rcar-H2.
>
> Signed-off-by: Nguyen Viet Dung
Yes, this is much better. Only minor things...
> + switch (priv->devtype) {
> + default:
> + case I2C_RCAR_H1:
> + cdf_width = 2;
> + break;
> + case I2C_RCAR_H2:
> + cdf_width = 3;
> + break;
> + }
> +
Please put the default case block at the end.
> @@ -632,6 +649,13 @@ static int rcar_i2c_probe(struct platform_device *pdev)
> bus_speed = 10; /* default 100 kHz */
> if (pdata && pdata->bus_speed)
> bus_speed = pdata->bus_speed;
> +
> + if (!pdev->id_entry) {
> + dev_err(&pdev->dev, "no entry\n");
> + return -ENODEV;
> + }
This cannot happen. Since you have 'i2c-rcar' in the id_table, the
driver core will always match against the id_table and there is always a
driver_data defined.
> + priv->devtype = pdev->id_entry->driver_data;
Basically the same, but please use
platform_get_device_id(pdev)->driver_data;
Otherwise good!
Thanks,
Wolfram
signature.asc
Description: Digital signature
Re: [PATCH v2 2/2] i2c-designware: get SDA hold time, HCNT and LCNT configuration from ACPI
On Mon, Aug 19, 2013 at 03:07:54PM +0300, Mika Westerberg wrote: > Some Intel LPSS I2C devices make the SDA hold time and *CNT parameters > available via SSCN (standard mode) and FMCN (fast mode) ACPI methods. > > Implement support for this so that we check whether an ACPI method exists > and if it does, fill in the SDA hold time and *CNT values to the device > private structure for core to use. > > Signed-off-by: Mika Westerberg Applied to for-next, thanks! signature.asc Description: Digital signature
Re: [PATCH v2 1/2] i2c-designware: make HCNT/LCNT values configurable
On Mon, Aug 19, 2013 at 03:07:53PM +0300, Mika Westerberg wrote: > The DesignWare I2C controller has high count (HCNT) and low count (LCNT) > registers for each of the I2C speed modes (standard and fast). These > registers are programmed based on the input clock speed in the driver. > > The current code calculates these values based on the input clock speed and > tries hard to meet the I2C bus timing requirements. This could result > non-optimal values with regarding to the bus speed. For example on Intel > BayTrail we get bus speed of 315.41kHz which is ~20% slower than we would > expect (400kHz) in fast mode (even though the timing requirements are met). > > This patch makes it possible for the platform code to pass more optimal > HCNT/LCNT values to the core driver if they are known beforehand. If these > are not set we use the calculated and more conservative values. > > Signed-off-by: Mika Westerberg Applied to for-next, thanks! signature.asc Description: Digital signature
Re: [RFC PATCH 1/2] i2c: prepare runtime PM support for I2C client devices
On Tue, Aug 20, 2013 at 05:03:35PM +0300, Mika Westerberg wrote:
> From: Aaron Lu
>
> This patch adds runtime PM support for the I2C bus in a similar way that
> has been done for PCI bus already. This means that the I2C bus core
> prepares runtime PM for a client device just before a driver is about to be
> bound to it. Devices that are not bound to any driver are not prepared for
> runtime PM.
>
> In order to take advantage of this runtime PM support, the client device
> driver needs drop the device runtime PM reference count by calling
> pm_runtime_put() in its ->probe() callback and possibly implement rest of
> the runtime PM callbacks.
>
> However, this does not yet make runtime PM happen for the device, it has to
> be explicitly allowed from userspace per each I2C client device. The
> reason for this is that things like HID over I2C might not work as smoothly
> when runtime PM is active. So we leave it to the user to balance between
> performance and power efficiency.
>
> User can allow runtime PM for the client device by running:
>
> # echo auto > /sys/bus/i2c/devices//power/control
>
> and it can be forbidden again by:
>
> # echo on > /sys/bus/i2c/devices//power/control
>
> Status of the device can be monitored by reading files under the device
> power directory.
>
> If the driver doesn't support runtime PM (like most of the existing I2C
> client drivers), the device in question is regarded as being runtime PM
> active and powered on.
>
> The patch adds also runtime PM support for the adapter device because it is
> needed to be able to runtime power manage the I2C controller device. The
> adapter device is handled along with the I2C controller device (it uses
> pm_runtime_no_callbacks()).
>
> Signed-off-by: Aaron Lu
> Signed-off-by: Mika Westerberg
CCing ALKML. Would appreciate comments/tags from the runtime-PM users of
the ARM world.
> ---
> drivers/i2c/i2c-core.c | 48 +++-
> 1 file changed, 47 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
> index 3d44292..8fad5ac 100644
> --- a/drivers/i2c/i2c-core.c
> +++ b/drivers/i2c/i2c-core.c
> @@ -254,11 +254,34 @@ static int i2c_device_probe(struct device *dev)
> client->flags & I2C_CLIENT_WAKE);
> dev_dbg(dev, "probe\n");
>
> + /* Make sure the adapter is active */
> + pm_runtime_get_sync(&client->adapter->dev);
> +
> + /*
> + * Enable runtime PM for the client device. If the client wants to
> + * participate on runtime PM it should call pm_runtime_put() in its
> + * probe() callback.
> + *
> + * User still needs to allow the PM runtime before it can actually
> + * happen.
> + */
> + pm_runtime_forbid(&client->dev);
> + pm_runtime_get_noresume(&client->dev);
> + pm_runtime_set_active(&client->dev);
> + pm_runtime_enable(&client->dev);
> +
> status = driver->probe(client, i2c_match_id(driver->id_table, client));
> if (status) {
> client->driver = NULL;
> i2c_set_clientdata(client, NULL);
> +
> + pm_runtime_disable(&client->dev);
> + pm_runtime_set_suspended(&client->dev);
> + pm_runtime_put_noidle(&client->dev);
> }
> +
> + pm_runtime_put(&client->adapter->dev);
> +
> return status;
> }
>
> @@ -271,6 +294,8 @@ static int i2c_device_remove(struct device *dev)
> if (!client || !dev->driver)
> return 0;
>
> + pm_runtime_get_sync(&client->adapter->dev);
> +
> driver = to_i2c_driver(dev->driver);
> if (driver->remove) {
> dev_dbg(dev, "remove\n");
> @@ -283,6 +308,13 @@ static int i2c_device_remove(struct device *dev)
> client->driver = NULL;
> i2c_set_clientdata(client, NULL);
> }
> +
> + /* Undo the runtime PM done in i2c_probe() */
> + pm_runtime_disable(&client->dev);
> + pm_runtime_set_suspended(&client->dev);
> + pm_runtime_put_noidle(&client->dev);
> +
> + pm_runtime_put(&client->adapter->dev);
> return status;
> }
>
> @@ -294,8 +326,11 @@ static void i2c_device_shutdown(struct device *dev)
> if (!client || !dev->driver)
> return;
> driver = to_i2c_driver(dev->driver);
> - if (driver->shutdown)
> + if (driver->shutdown) {
> + pm_runtime_get_sync(&client->adapter->dev);
> driver->shutdown(client);
> + pm_runtime_put(&client->adapter->dev);
> + }
> }
>
> #ifdef CONFIG_PM_SLEEP
> @@ -1263,6 +1298,15 @@ exit_recovery:
> bus_for_each_drv(&i2c_bus_type, NULL, adap, __process_new_adapter);
> mutex_unlock(&core_lock);
>
> + /*
> + * Make sure the adapter runtime PM follows the parent device (the
> + * host controller) so that we can suspend it once there aren't any
> + * active clients anymore.
> + */
> + pm_r
Re: [PATCH 1/4] i2c: busses: i2c-st: Add ST I2C controller
> >> +Optional properties : > >> +- i2c-min-scl-pulse-width-us : The minimum valid SCL pulse width that is > >> allowed > >> + through the deglitch circuit. In units of us. > >> +- i2c-min-sda-pulse-width-us : The minimum valid SDA pulse width that is > >> allowed > >> + through the deglitch circuit. In units of us. > > Are those properties specific to this binding, or intended to be > > generic? If specific to this binding, a vendor prefix should be present > > in the property name. If not, you probably want to document the > > properties in some common file. > Ok. > In last revision, I put this properties as specific to this binding. > Wolfram proposed to make this generic, but it looks like this IP is the > only one > needing such properties. > > Wolfram, what would you advise? It might be the only SoC now, but I could imagine that other will have something similar in the future. I am not perfectly sure, though. So, I asked for opinions from DT experts when I suggested those bindings. We could start with vendor specific bindings and generalize them later if similar ones appear. Yet my experience is that old drivers rarely get converted to the new bindings. > If you still prefer to make this properties generics, in which file should I > document it? I don't see any common i2c binding document for now. Yeah, it is missing sadly. That's on my todo-list, like many other things... Regards, Wolfram signature.asc Description: Digital signature
Re: [PATCH] misc: bh1780: probe from compatible string
On Wed, Oct 02, 2013 at 01:46:47PM +0200, Linus Walleij wrote: > Currently the BH1780GLI I2C driver relies on the device tree node > having the right name, but this is fragile. Use the compatible > string to probe the driver instead. > > Cc: Wolfram Sang > Signed-off-by: Linus Walleij Acked-by: Wolfram Sang signature.asc Description: Digital signature
Re: [PATCH 0/8] i2c: Remove redundant driver field from the i2c_client struct
On Sun, Sep 29, 2013 at 10:50:58AM +0200, Lars-Peter Clausen wrote: > Hi, > > This series removes the redundant driver field from the i2c_client struct. The > field is redundant since the same pointer can be accessed through > to_i2c_driver(client->dev.driver). The commit log suggests that the field has > been around since forever (since before v2.6.12-rc2) and it looks as if it was > simply forgotten to remove it during the conversion of the i2c framework to > the > generic device driver model. Applied to for-next with great pleasure, thanks! signature.asc Description: Digital signature
Re: [PATCH v2 3/3] i2c: xilinx: Use devm_* functions
> + i2c->base = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(i2c->base)) {
> + dev_err(&pdev->dev, "Could not allocate iomem\n");
devm_ioremap_resource already prints error messages.
> + ret = devm_request_irq(&pdev->dev, irq, xiic_isr, 0, pdev->name, i2c);
This is too early. Can you find out why?
> + pdata = (struct xiic_i2c_platform_data *)dev_get_platdata(&pdev->dev);
Casting a void pointer?
signature.asc
Description: Digital signature
Re: [PATCH v2 2/3] i2c: xilinx: Set tx direction in write operation
> + cr = xiic_getreg32(i2c, XIIC_CR_REG_OFFSET); > + cr |= XIIC_CR_DIR_IS_TX_MASK; > + xiic_setreg32(i2c, XIIC_CR_REG_OFFSET, cr); > + Is there no need to clear the bit again when receiving? And did transferring ever work if this bit was never set before? signature.asc Description: Digital signature
Re: [PATCH v2 2/3] i2c: xilinx: Set tx direction in write operation
On Fri, Oct 04, 2013 at 11:53:49AM +0200, Michal Simek wrote: > On 10/04/2013 07:46 AM, Wolfram Sang wrote: > > > >> + cr = xiic_getreg32(i2c, XIIC_CR_REG_OFFSET); > >> + cr |= XIIC_CR_DIR_IS_TX_MASK; > >> + xiic_setreg32(i2c, XIIC_CR_REG_OFFSET, cr); > >> + > > > > Is there no need to clear the bit again when receiving? > > This bit is cleared in xiic_xfer() -> xiic_start_xfer() ->xiic_reinit() > > xiic_setreg8(i2c, XIIC_CR_REG_OFFSET, XIIC_CR_TX_FIFO_RESET_MASK); A bit implicit, but OK. > > And did > > transferring ever work if this bit was never set before? > > I really don't know. We have switched from old driver to this new mainline one > and based on our eeprom testing we have found that this bit hasn't been setup > properly. > > It is described here. > http://www.xilinx.com/support/documentation/ip_documentation/axi_iic/v1_02_a/axi_iic_ds756.pdf > page 28 - step 3. > > IIC Master Transmitter with a Repeated Start > 1. Write the IIC device address to the TX_FIFO. > 2. Write data to TX_FIFO. > 3. Write to Control Register (CR) to set MSMS = 1 and TX = 1. > 4. Continue writing data to TX_FIFO. > 5. Wait for transmit FIFO empty interrupt. This implies the IIC has throttled > the bus. > 6. Write to CR to set RSTA = 1. Repeated start is not happening in the driver as well, or am I overlooking something? > 7. Write IIC device address to TX_FIFO. > 8. Write all data except last byte to TX_FIFO. > 9. Wait for transmit FIFO empty interrupt. This implies the IIC has throttled > the bus. > 10. Write to CR to set MSMS = 0. The IIC generates a stop condition at the > end of the last byte. > 11. Write last byte of data to TX_FIFO. CCing more people who worked on the driver in the past and might have experiences Thanks, Wolfram signature.asc Description: Digital signature
Re: [PATCH v2 3/3] i2c: xilinx: Use devm_* functions
On Fri, Oct 04, 2013 at 11:16:20AM +0200, Michal Simek wrote:
> On 10/04/2013 07:33 AM, Wolfram Sang wrote:
> >
> >> + i2c->base = devm_ioremap_resource(&pdev->dev, res);
> >> + if (IS_ERR(i2c->base)) {
> >> + dev_err(&pdev->dev, "Could not allocate iomem\n");
> >
> > devm_ioremap_resource already prints error messages.
>
> you are right.
>
> >
> >> + ret = devm_request_irq(&pdev->dev, irq, xiic_isr, 0, pdev->name, i2c);
> >
> > This is too early. Can you find out why?
>
> Why do you think that it is too early?
The ISR uses spinlocks which are not initialized by then.
> I am looking at origin code again and I think that the code
> is also problematic because in xiic_reinit() interrupts are enabled
> but they are requested later.
> Shouldn't be there a logic that interrupts should be enabled when
> interrupts are registered by the kernel?
First register the handler, then activate interrupts. You are right,
this needs to be fixed, too.
Regards,
Wolfram
signature.asc
Description: Digital signature
Re: [PATCH v2 3/3] i2c: xilinx: Use devm_* functions
> > First register the handler, then activate interrupts. You are right, > > this needs to be fixed, too. > > Do you want me to create separate patch just about moving request irq in > front of > xiic_reinit()? And then devm_ conversion? Yes, seperate, please. signature.asc Description: Digital signature
Re: [PATCH] scripts/coccinelle/api: remove devm_request_and_ioremap.cocci
On Thu, Aug 15, 2013 at 12:30:25PM +0200, Wolfram Sang wrote: > Use of this function is discouraged in favour of > devm_ioremap_resource(). Don't advertise it. > > Signed-off-by: Wolfram Sang Ping. signature.asc Description: Digital signature
[RFC 1/2] sched: replace INIT_COMPLETION with reinit_completion
For the casual device driver writer, it is hard to remember when to use
init_completion (to init a completion structure) or INIT_COMPLETION (to
*reinit* a completion structure). Furthermore, while all other completion
functions exepct a pointer as a parameter, INIT_COMPLETION does not. To make it
easier to remember which function to use and to make code more readable,
introduce a new inline function with the proper name and consistent argument
type. Update the kernel-doc for init_completion while we are here.
Signed-off-by: Wolfram Sang
Acked-by: Linus Walleij (personally at LCE13)
---
include/linux/completion.h | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/include/linux/completion.h b/include/linux/completion.h
index 3cd574d..7a1a587 100644
--- a/include/linux/completion.h
+++ b/include/linux/completion.h
@@ -65,7 +65,7 @@ struct completion {
/**
* init_completion - Initialize a dynamically allocated completion
- * @x: completion structure that is to be initialized
+ * @x: pointer to completion structure that is to be initialized
*
* This inline function will initialize a dynamically created completion
* structure.
@@ -76,6 +76,18 @@ static inline void init_completion(struct completion *x)
init_waitqueue_head(&x->wait);
}
+/**
+ * reinit_completion - reinitialize a completion structure
+ * @x: pointer to completion structure that is to be reinitialized
+ *
+ * This inline function should be used to reinitialize a completion structure
so it can
+ * be reused. This is especially important after complete_all() is used.
+ */
+static inline void reinit_completion(struct completion *x)
+{
+ x->done = 0;
+}
+
extern void wait_for_completion(struct completion *);
extern void wait_for_completion_io(struct completion *);
extern int wait_for_completion_interruptible(struct completion *x);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC 2/2] tree-wide: use reinit_completion instead of INIT_COMPLETION
Use this new function to make code more comprehensible, since we are reinitialzing the completion, not initializing. Signed-off-by: Wolfram Sang Acked-by: Linus Walleij (personally at LCE13) --- This is now a tree-wide patch for easier review. I can easily split it up later. arch/arm/mach-tegra/apbio.c |2 +- arch/powerpc/platforms/powermac/low_i2c.c|6 +++--- arch/powerpc/platforms/pseries/suspend.c |2 +- crypto/af_alg.c |2 +- crypto/tcrypt.c |4 ++-- crypto/testmgr.c | 12 ++-- drivers/ata/libata-eh.c |2 +- drivers/base/power/main.c|4 ++-- drivers/block/amiflop.c |2 +- drivers/block/cciss.c|4 ++-- drivers/char/hw_random/timeriomem-rng.c |2 +- drivers/crypto/tegra-aes.c |2 +- drivers/firewire/core-transaction.c |2 +- drivers/gpu/drm/gma500/oaktrail_hdmi_i2c.c |2 +- drivers/hwmon/jz4740-hwmon.c |2 +- drivers/i2c/busses/i2c-at91.c|2 +- drivers/i2c/busses/i2c-bcm2835.c |2 +- drivers/i2c/busses/i2c-davinci.c |2 +- drivers/i2c/busses/i2c-designware-core.c |2 +- drivers/i2c/busses/i2c-ismt.c|2 +- drivers/i2c/busses/i2c-mxs.c |2 +- drivers/i2c/busses/i2c-omap.c|2 +- drivers/i2c/busses/i2c-tegra.c |2 +- drivers/i2c/busses/i2c-wmt.c |4 ++-- drivers/iio/adc/ad_sigma_delta.c |6 +++--- drivers/input/touchscreen/cyttsp_core.c |2 +- drivers/md/dm-crypt.c|2 +- drivers/media/platform/blackfin/bfin_capture.c |2 +- drivers/media/platform/coda.c|2 +- drivers/media/radio/radio-wl1273.c | 10 +- drivers/media/radio/si470x/radio-si470x-common.c |4 ++-- drivers/media/rc/iguanair.c |2 +- drivers/memstick/core/memstick.c |2 +- drivers/memstick/host/r592.c |2 +- drivers/misc/ti-st/st_kim.c | 12 ++-- drivers/mtd/nand/mxc_nand.c |2 +- drivers/mtd/nand/r852.c |2 +- drivers/mtd/onenand/omap2.c | 10 +- drivers/net/ieee802154/at86rf230.c |2 +- drivers/net/ieee802154/mrf24j40.c|2 +- drivers/net/wireless/ath/carl9170/usb.c |2 +- drivers/net/wireless/ath/wil6210/main.c |2 +- drivers/net/wireless/brcm80211/brcmfmac/p2p.c|4 ++-- drivers/net/wireless/zd1211rw/zd_usb.c |2 +- drivers/parport/parport_ip32.c |4 ++-- drivers/platform/x86/apple-gmux.c|2 +- drivers/power/ab8500_fg.c|4 ++-- drivers/power/jz4740-battery.c |2 +- drivers/rtc/rtc-hid-sensor-time.c|2 +- drivers/spi/spi-bcm2835.c|2 +- drivers/spi/spi-clps711x.c |2 +- drivers/spi/spi-davinci.c|2 +- drivers/spi/spi-fsl-espi.c |2 +- drivers/spi/spi-fsl-spi.c|2 +- drivers/spi/spi-mpc512x-psc.c|2 +- drivers/spi/spi-mxs.c|2 +- drivers/spi/spi-s3c64xx.c|2 +- drivers/spi/spi-sh-msiof.c |2 +- drivers/spi/spi-sirf.c |2 +- drivers/spi/spi-tegra114.c |6 +++--- drivers/spi/spi-tegra20-sflash.c |2 +- drivers/spi/spi-tegra20-slink.c |6 +++--- drivers/spi/spi-xilinx.c |2 +- drivers/staging/iio/adc/mxs-lradc.c |2 +- drivers/staging/media/solo6x10/solo6x10-p2m.c|2 +- drivers/staging/tidspbridge/core/sync.c |4 ++-- drivers/staging/tidspbridge/rmgr/drv_interface.c |6 +++--- drivers/tty/metag_da.c |2 +- drivers/usb/c67x00/c67x00-sched.c|2 +- drivers/usb/gadget/f_fs.c|2 +- drivers/usb/serial/mos7720.c |2 +- drivers/video/exynos/exynos_mipi_dsi_common.c|4 ++-- fs/ecryptfs/crypto.c |4 ++-- fs/nfs/nfs4state.c |2 +- fs/ocfs2/dlmglue.c |4 ++-- sound/soc/samsung/ac97.c |6 +++--- 76 files changed, 118 insertions(+), 118 deletions(-) diff --git a/arch
[RFC 0/2] replace INIT_COMPLETION with reinit_completion
I had this on my mind for a bit of time now... Never liked INIT_COMPLETION because of inconsistencies. See patch 1 to see why I think a replacement is proper. I wonder what to do about the old INIT_COMPLETION, though. We could a) remove it right away (bad luck for out-of-tree users, still my favourite) b) keep it, but discourage its use (then we have cruft) c) convert it to an inline function and mark that deprecated and remove it later This series is based on linus-master as of today and I was able to compile test 60 out of 76 files, for the others I didn't have configs/compilers. Tested on an AT91 board. More testing welcome. Looking forward to opinions. If accepted, I'd think it is probably best if this gets in in one go via Linus directly? Thanks, Wolfram Wolfram Sang (2): sched: replace INIT_COMPLETION with reinit_completion tree-wide: use reinit_completion instead of INIT_COMPLETION arch/arm/mach-tegra/apbio.c |2 +- arch/powerpc/platforms/powermac/low_i2c.c|6 +++--- arch/powerpc/platforms/pseries/suspend.c |2 +- crypto/af_alg.c |2 +- crypto/tcrypt.c |4 ++-- crypto/testmgr.c | 12 ++-- drivers/ata/libata-eh.c |2 +- drivers/base/power/main.c|4 ++-- drivers/block/amiflop.c |2 +- drivers/block/cciss.c|4 ++-- drivers/char/hw_random/timeriomem-rng.c |2 +- drivers/crypto/tegra-aes.c |2 +- drivers/firewire/core-transaction.c |2 +- drivers/gpu/drm/gma500/oaktrail_hdmi_i2c.c |2 +- drivers/hwmon/jz4740-hwmon.c |2 +- drivers/i2c/busses/i2c-at91.c|2 +- drivers/i2c/busses/i2c-bcm2835.c |2 +- drivers/i2c/busses/i2c-davinci.c |2 +- drivers/i2c/busses/i2c-designware-core.c |2 +- drivers/i2c/busses/i2c-ismt.c|2 +- drivers/i2c/busses/i2c-mxs.c |2 +- drivers/i2c/busses/i2c-omap.c|2 +- drivers/i2c/busses/i2c-tegra.c |2 +- drivers/i2c/busses/i2c-wmt.c |4 ++-- drivers/iio/adc/ad_sigma_delta.c |6 +++--- drivers/input/touchscreen/cyttsp_core.c |2 +- drivers/md/dm-crypt.c|2 +- drivers/media/platform/blackfin/bfin_capture.c |2 +- drivers/media/platform/coda.c|2 +- drivers/media/radio/radio-wl1273.c | 10 +- drivers/media/radio/si470x/radio-si470x-common.c |4 ++-- drivers/media/rc/iguanair.c |2 +- drivers/memstick/core/memstick.c |2 +- drivers/memstick/host/r592.c |2 +- drivers/misc/ti-st/st_kim.c | 12 ++-- drivers/mtd/nand/mxc_nand.c |2 +- drivers/mtd/nand/r852.c |2 +- drivers/mtd/onenand/omap2.c | 10 +- drivers/net/ieee802154/at86rf230.c |2 +- drivers/net/ieee802154/mrf24j40.c|2 +- drivers/net/wireless/ath/carl9170/usb.c |2 +- drivers/net/wireless/ath/wil6210/main.c |2 +- drivers/net/wireless/brcm80211/brcmfmac/p2p.c|4 ++-- drivers/net/wireless/zd1211rw/zd_usb.c |2 +- drivers/parport/parport_ip32.c |4 ++-- drivers/platform/x86/apple-gmux.c|2 +- drivers/power/ab8500_fg.c|4 ++-- drivers/power/jz4740-battery.c |2 +- drivers/rtc/rtc-hid-sensor-time.c|2 +- drivers/spi/spi-bcm2835.c|2 +- drivers/spi/spi-clps711x.c |2 +- drivers/spi/spi-davinci.c|2 +- drivers/spi/spi-fsl-espi.c |2 +- drivers/spi/spi-fsl-spi.c|2 +- drivers/spi/spi-mpc512x-psc.c|2 +- drivers/spi/spi-mxs.c|2 +- drivers/spi/spi-s3c64xx.c|2 +- drivers/spi/spi-sh-msiof.c |2 +- drivers/spi/spi-sirf.c |2 +- drivers/spi/spi-tegra114.c |6 +++--- drivers/spi/spi-tegra20-sflash.c |2 +- drivers/spi/spi-tegra20-slink.c |6 +++--- drivers/spi/spi-xilinx.c |2 +- drivers/staging/iio/adc/mxs-lradc.c |2 +- drivers/staging/media/solo6x10/solo6x10-p2m.c|2 +- drivers/staging/tidspbridge/core/sync.c |4 ++-- drivers/staging/tidspbridge/rmgr/drv_i
[PATCH 08/12] drivers/net/ethernet/cadence: don't use devm_pinctrl_get_select_default() in probe
Since commit ab78029 (drivers/pinctrl: grab default handles from device core),
we can rely on device core for setting the default pins. Compile tested only.
Acked-by: Linus Walleij (personally at LCE13)
Signed-off-by: Wolfram Sang
---
drivers/net/ethernet/cadence/at91_ether.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/net/ethernet/cadence/at91_ether.c
b/drivers/net/ethernet/cadence/at91_ether.c
index 3f19571..bb5d63f 100644
--- a/drivers/net/ethernet/cadence/at91_ether.c
+++ b/drivers/net/ethernet/cadence/at91_ether.c
@@ -29,7 +29,6 @@
#include
#include
#include
-#include
#include "macb.h"
@@ -309,7 +308,6 @@ static int __init at91ether_probe(struct platform_device
*pdev)
struct resource *regs;
struct net_device *dev;
struct phy_device *phydev;
- struct pinctrl *pinctrl;
struct macb *lp;
int res;
u32 reg;
@@ -319,15 +317,6 @@ static int __init at91ether_probe(struct platform_device
*pdev)
if (!regs)
return -ENOENT;
- pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
- if (IS_ERR(pinctrl)) {
- res = PTR_ERR(pinctrl);
- if (res == -EPROBE_DEFER)
- return res;
-
- dev_warn(&pdev->dev, "No pinctrl provided\n");
- }
-
dev = alloc_etherdev(sizeof(struct macb));
if (!dev)
return -ENOMEM;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 12/12] drivers/video: don't use devm_pinctrl_get_select_default() in probe
Since commit ab78029 (drivers/pinctrl: grab default handles from device core),
we can rely on device core for setting the default pins. Compile tested only.
Acked-by: Linus Walleij (personally at LCE13)
Signed-off-by: Wolfram Sang
---
drivers/video/mxsfb.c |8
1 file changed, 8 deletions(-)
diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c
index 3ba3771..5861ba2 100644
--- a/drivers/video/mxsfb.c
+++ b/drivers/video/mxsfb.c
@@ -46,7 +46,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -877,7 +876,6 @@ static int mxsfb_probe(struct platform_device *pdev)
struct mxsfb_info *host;
struct fb_info *fb_info;
struct fb_modelist *modelist;
- struct pinctrl *pinctrl;
int ret;
if (of_id)
@@ -908,12 +906,6 @@ static int mxsfb_probe(struct platform_device *pdev)
host->devdata = &mxsfb_devdata[pdev->id_entry->driver_data];
- pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
- if (IS_ERR(pinctrl)) {
- ret = PTR_ERR(pinctrl);
- goto fb_release;
- }
-
host->clk = devm_clk_get(&host->pdev->dev, NULL);
if (IS_ERR(host->clk)) {
ret = PTR_ERR(host->clk);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 07/12] drivers/net/can/c_can: don't use devm_pinctrl_get_select_default() in probe
Since commit ab78029 (drivers/pinctrl: grab default handles from device core),
we can rely on device core for setting the default pins. Compile tested only.
Acked-by: Linus Walleij (personally at LCE13)
Signed-off-by: Wolfram Sang
---
drivers/net/can/c_can/c_can_platform.c |7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/net/can/c_can/c_can_platform.c
b/drivers/net/can/c_can/c_can_platform.c
index b918c73..c6f838d 100644
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -32,7 +32,6 @@
#include
#include
#include
-#include
#include
@@ -114,7 +113,6 @@ static int c_can_plat_probe(struct platform_device *pdev)
struct c_can_priv *priv;
const struct of_device_id *match;
const struct platform_device_id *id;
- struct pinctrl *pinctrl;
struct resource *mem, *res;
int irq;
struct clk *clk;
@@ -131,11 +129,6 @@ static int c_can_plat_probe(struct platform_device *pdev)
id = platform_get_device_id(pdev);
}
- pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
- if (IS_ERR(pinctrl))
- dev_warn(&pdev->dev,
- "failed to configure pins from driver\n");
-
/* get the appropriate clk */
clk = clk_get(&pdev->dev, NULL);
if (IS_ERR(clk)) {
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 09/12] drivers/net/ieee802154: don't use devm_pinctrl_get_select_default() in probe
Since commit ab78029 (drivers/pinctrl: grab default handles from device core), we can rely on device core for setting the default pins. Compile tested only. Acked-by: Linus Walleij (personally at LCE13) Signed-off-by: Wolfram Sang --- drivers/net/ieee802154/mrf24j40.c |7 --- 1 file changed, 7 deletions(-) diff --git a/drivers/net/ieee802154/mrf24j40.c b/drivers/net/ieee802154/mrf24j40.c index ede3ce4..42e6dee 100644 --- a/drivers/net/ieee802154/mrf24j40.c +++ b/drivers/net/ieee802154/mrf24j40.c @@ -22,7 +22,6 @@ #include #include #include -#include #include #include #include @@ -627,7 +626,6 @@ static int mrf24j40_probe(struct spi_device *spi) int ret = -ENOMEM; u8 val; struct mrf24j40 *devrec; - struct pinctrl *pinctrl; printk(KERN_INFO "mrf24j40: probe(). IRQ: %d\n", spi->irq); @@ -638,11 +636,6 @@ static int mrf24j40_probe(struct spi_device *spi) if (!devrec->buf) goto err_buf; - pinctrl = devm_pinctrl_get_select_default(&spi->dev); - if (IS_ERR(pinctrl)) - dev_warn(&spi->dev, - "pinctrl pins are not configured from the driver"); - spi->mode = SPI_MODE_0; /* TODO: Is this appropriate for right here? */ if (spi->max_speed_hz > MAX_SPI_SPEED_HZ) spi->max_speed_hz = MAX_SPI_SPEED_HZ; -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 05/12] drivers/mtd/nand: don't use devm_pinctrl_get_select_default() in probe
Since commit ab78029 (drivers/pinctrl: grab default handles from device core),
we can rely on device core for setting the default pins. Compile tested only.
Acked-by: Linus Walleij (personally at LCE13)
Signed-off-by: Wolfram Sang
---
drivers/mtd/nand/atmel_nand.c |9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
index 2d23d29..4653b64a 100644
--- a/drivers/mtd/nand/atmel_nand.c
+++ b/drivers/mtd/nand/atmel_nand.c
@@ -41,7 +41,6 @@
#include
#include
#include
-#include
#include
@@ -1470,7 +1469,6 @@ static int __init atmel_nand_probe(struct platform_device
*pdev)
struct resource *mem;
struct mtd_part_parser_data ppdata = {};
int res;
- struct pinctrl *pinctrl;
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!mem) {
@@ -1515,13 +1513,6 @@ static int __init atmel_nand_probe(struct
platform_device *pdev)
nand_chip->IO_ADDR_W = host->io_base;
nand_chip->cmd_ctrl = atmel_nand_cmd_ctrl;
- pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
- if (IS_ERR(pinctrl)) {
- dev_err(host->dev, "Failed to request pinctrl\n");
- res = PTR_ERR(pinctrl);
- goto err_ecc_ioremap;
- }
-
if (gpio_is_valid(host->board.rdy_pin)) {
res = gpio_request(host->board.rdy_pin, "nand_rdy");
if (res < 0) {
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 11/12] drivers/tty/serial: don't use devm_pinctrl_get_select_default() in probe
Since commit ab78029 (drivers/pinctrl: grab default handles from device core),
we can rely on device core for setting the default pins. Compile tested only.
Acked-by: Linus Walleij (personally at LCE13)
Signed-off-by: Wolfram Sang
---
drivers/tty/serial/atmel_serial.c |8
drivers/tty/serial/imx.c |9 -
drivers/tty/serial/mxs-auart.c|8
drivers/tty/serial/omap-serial.c |9 -
4 files changed, 34 deletions(-)
diff --git a/drivers/tty/serial/atmel_serial.c
b/drivers/tty/serial/atmel_serial.c
index 691265f..0e39fac 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -39,7 +39,6 @@
#include
#include
#include
-#include
#include
#include
@@ -1775,7 +1774,6 @@ static int atmel_serial_probe(struct platform_device
*pdev)
struct atmel_uart_data *pdata = pdev->dev.platform_data;
void *data;
int ret = -ENODEV;
- struct pinctrl *pinctrl;
BUILD_BUG_ON(ATMEL_SERIAL_RINGSIZE & (ATMEL_SERIAL_RINGSIZE - 1));
@@ -1809,12 +1807,6 @@ static int atmel_serial_probe(struct platform_device
*pdev)
if (ret)
goto err;
- pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
- if (IS_ERR(pinctrl)) {
- ret = PTR_ERR(pinctrl);
- goto err;
- }
-
if (!atmel_use_dma_rx(&port->uart)) {
ret = -ENOMEM;
data = kmalloc(sizeof(struct atmel_uart_char)
diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index 415cec6..2797e55 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -47,7 +47,6 @@
#include
#include
#include
-#include
#include
#include
@@ -1507,7 +1506,6 @@ static int serial_imx_probe(struct platform_device *pdev)
void __iomem *base;
int ret = 0;
struct resource *res;
- struct pinctrl *pinctrl;
sport = devm_kzalloc(&pdev->dev, sizeof(*sport), GFP_KERNEL);
if (!sport)
@@ -1543,13 +1541,6 @@ static int serial_imx_probe(struct platform_device *pdev)
sport->timer.function = imx_timeout;
sport->timer.data = (unsigned long)sport;
- pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
- if (IS_ERR(pinctrl)) {
- ret = PTR_ERR(pinctrl);
- dev_err(&pdev->dev, "failed to get default pinctrl: %d\n", ret);
- return ret;
- }
-
sport->clk_ipg = devm_clk_get(&pdev->dev, "ipg");
if (IS_ERR(sport->clk_ipg)) {
ret = PTR_ERR(sport->clk_ipg);
diff --git a/drivers/tty/serial/mxs-auart.c b/drivers/tty/serial/mxs-auart.c
index 4f5f161..a63a20e 100644
--- a/drivers/tty/serial/mxs-auart.c
+++ b/drivers/tty/serial/mxs-auart.c
@@ -32,7 +32,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -1015,7 +1014,6 @@ static int mxs_auart_probe(struct platform_device *pdev)
u32 version;
int ret = 0;
struct resource *r;
- struct pinctrl *pinctrl;
s = kzalloc(sizeof(struct mxs_auart_port), GFP_KERNEL);
if (!s) {
@@ -1029,12 +1027,6 @@ static int mxs_auart_probe(struct platform_device *pdev)
else if (ret < 0)
goto out_free;
- pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
- if (IS_ERR(pinctrl)) {
- ret = PTR_ERR(pinctrl);
- goto out_free;
- }
-
if (of_id) {
pdev->id_entry = of_id->data;
s->devtype = pdev->id_entry->driver_data;
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index b6d1728..eacb0de 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -40,7 +40,6 @@
#include
#include
#include
-#include
#include
#define OMAP_MAX_HSUART_PORTS 6
@@ -160,7 +159,6 @@ struct uart_omap_port {
u32 latency;
u32 calc_latency;
struct work_struct qos_work;
- struct pinctrl *pins;
boolis_suspending;
};
@@ -1468,13 +1466,6 @@ static int serial_omap_probe(struct platform_device
*pdev)
goto err_port_line;
}
- up->pins = devm_pinctrl_get_select_default(&pdev->dev);
- if (IS_ERR(up->pins)) {
- dev_warn(&pdev->dev, "did not get pins for uart%i error: %li\n",
-up->port.line, PTR_ERR(up->pins));
- up->pins = NULL;
- }
-
sprintf(up->name, "OMAP UART%d", up->port.line);
up->port.mapbase = mem->start;
up->port.membase = devm_ioremap(&pdev->dev, mem->start,
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 01/12] drivers/gpu/drm/tilcdc: don't use devm_pinctrl_get_select_default() in probe
Since commit ab78029 (drivers/pinctrl: grab default handles from device core),
we can rely on device core for setting the default pins. Compile tested only.
Acked-by: Linus Walleij (personally at LCE13)
Signed-off-by: Wolfram Sang
---
drivers/gpu/drm/tilcdc/tilcdc_panel.c |6 --
drivers/gpu/drm/tilcdc/tilcdc_slave.c |6 --
drivers/gpu/drm/tilcdc/tilcdc_tfp410.c |6 --
3 files changed, 18 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
index 86c6732..f0ff5f8 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
@@ -16,7 +16,6 @@
*/
#include
-#include
#include
#include
#include
@@ -358,7 +357,6 @@ static int panel_probe(struct platform_device *pdev)
struct device_node *node = pdev->dev.of_node;
struct panel_module *panel_mod;
struct tilcdc_module *mod;
- struct pinctrl *pinctrl;
int ret = -EINVAL;
@@ -376,10 +374,6 @@ static int panel_probe(struct platform_device *pdev)
tilcdc_module_init(mod, "panel", &panel_module_ops);
- pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
- if (IS_ERR(pinctrl))
- dev_warn(&pdev->dev, "pins are not configured\n");
-
panel_mod->timings = of_get_display_timings(node);
if (!panel_mod->timings) {
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_slave.c
b/drivers/gpu/drm/tilcdc/tilcdc_slave.c
index dfffaf0..2bdbe5e 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_slave.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_slave.c
@@ -18,7 +18,6 @@
#include
#include
#include
-#include
#include
#include "tilcdc_drv.h"
@@ -296,7 +295,6 @@ static int slave_probe(struct platform_device *pdev)
struct device_node *i2c_node;
struct slave_module *slave_mod;
struct tilcdc_module *mod;
- struct pinctrl *pinctrl;
uint32_t i2c_phandle;
struct i2c_adapter *slavei2c;
int ret = -EINVAL;
@@ -342,10 +340,6 @@ static int slave_probe(struct platform_device *pdev)
tilcdc_module_init(mod, "slave", &slave_module_ops);
- pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
- if (IS_ERR(pinctrl))
- dev_warn(&pdev->dev, "pins are not configured\n");
-
tilcdc_slave_probedefer(false);
return 0;
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
index 925c7cd..a38be60 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
@@ -20,7 +20,6 @@
#include
#include
#include
-#include
#include "tilcdc_drv.h"
@@ -327,7 +326,6 @@ static int tfp410_probe(struct platform_device *pdev)
struct device_node *i2c_node;
struct tfp410_module *tfp410_mod;
struct tilcdc_module *mod;
- struct pinctrl *pinctrl;
uint32_t i2c_phandle;
int ret = -EINVAL;
@@ -345,10 +343,6 @@ static int tfp410_probe(struct platform_device *pdev)
tilcdc_module_init(mod, "tfp410", &tfp410_module_ops);
- pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
- if (IS_ERR(pinctrl))
- dev_warn(&pdev->dev, "pins are not configured\n");
-
if (of_property_read_u32(node, "i2c", &i2c_phandle)) {
dev_err(&pdev->dev, "could not get i2c bus phandle\n");
goto fail;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 03/12] drivers/misc: don't use devm_pinctrl_get_select_default() in probe
Since commit ab78029 (drivers/pinctrl: grab default handles from device core),
we can rely on device core for setting the default pins. Compile tested only.
Acked-by: Linus Walleij (personally at LCE13)
Signed-off-by: Wolfram Sang
---
drivers/misc/atmel-ssc.c |8
1 file changed, 8 deletions(-)
diff --git a/drivers/misc/atmel-ssc.c b/drivers/misc/atmel-ssc.c
index f7b90661..551ddde 100644
--- a/drivers/misc/atmel-ssc.c
+++ b/drivers/misc/atmel-ssc.c
@@ -19,7 +19,6 @@
#include
#include
-#include
/* Serialize access to ssc_list and user count */
static DEFINE_SPINLOCK(user_lock);
@@ -132,13 +131,6 @@ static int ssc_probe(struct platform_device *pdev)
struct resource *regs;
struct ssc_device *ssc;
const struct atmel_ssc_platform_data *plat_dat;
- struct pinctrl *pinctrl;
-
- pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
- if (IS_ERR(pinctrl)) {
- dev_err(&pdev->dev, "Failed to request pinctrl\n");
- return PTR_ERR(pinctrl);
- }
ssc = devm_kzalloc(&pdev->dev, sizeof(struct ssc_device), GFP_KERNEL);
if (!ssc) {
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 10/12] drivers/pwm: don't use devm_pinctrl_get_select_default() in probe
Since commit ab78029 (drivers/pinctrl: grab default handles from device core),
we can rely on device core for setting the default pins. Compile tested only.
Acked-by: Linus Walleij (personally at LCE13)
Signed-off-by: Wolfram Sang
---
drivers/pwm/pwm-mxs.c |6 --
drivers/pwm/pwm-tiecap.c |6 --
drivers/pwm/pwm-tiehrpwm.c |6 --
3 files changed, 18 deletions(-)
diff --git a/drivers/pwm/pwm-mxs.c b/drivers/pwm/pwm-mxs.c
index 3febddd..6489a4b 100644
--- a/drivers/pwm/pwm-mxs.c
+++ b/drivers/pwm/pwm-mxs.c
@@ -16,7 +16,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -130,7 +129,6 @@ static int mxs_pwm_probe(struct platform_device *pdev)
struct device_node *np = pdev->dev.of_node;
struct mxs_pwm_chip *mxs;
struct resource *res;
- struct pinctrl *pinctrl;
int ret;
mxs = devm_kzalloc(&pdev->dev, sizeof(*mxs), GFP_KERNEL);
@@ -142,10 +140,6 @@ static int mxs_pwm_probe(struct platform_device *pdev)
if (IS_ERR(mxs->base))
return PTR_ERR(mxs->base);
- pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
- if (IS_ERR(pinctrl))
- return PTR_ERR(pinctrl);
-
mxs->clk = devm_clk_get(&pdev->dev, NULL);
if (IS_ERR(mxs->clk))
return PTR_ERR(mxs->clk);
diff --git a/drivers/pwm/pwm-tiecap.c b/drivers/pwm/pwm-tiecap.c
index 72ca42d..050abe1 100644
--- a/drivers/pwm/pwm-tiecap.c
+++ b/drivers/pwm/pwm-tiecap.c
@@ -26,7 +26,6 @@
#include
#include
#include
-#include
#include "pwm-tipwmss.h"
@@ -208,11 +207,6 @@ static int ecap_pwm_probe(struct platform_device *pdev)
struct clk *clk;
struct ecap_pwm_chip *pc;
u16 status;
- struct pinctrl *pinctrl;
-
- pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
- if (IS_ERR(pinctrl))
- dev_warn(&pdev->dev, "unable to select pin group\n");
pc = devm_kzalloc(&pdev->dev, sizeof(*pc), GFP_KERNEL);
if (!pc) {
diff --git a/drivers/pwm/pwm-tiehrpwm.c b/drivers/pwm/pwm-tiehrpwm.c
index 48a485c..5f7632d 100644
--- a/drivers/pwm/pwm-tiehrpwm.c
+++ b/drivers/pwm/pwm-tiehrpwm.c
@@ -26,7 +26,6 @@
#include
#include
#include
-#include
#include "pwm-tipwmss.h"
@@ -439,11 +438,6 @@ static int ehrpwm_pwm_probe(struct platform_device *pdev)
struct clk *clk;
struct ehrpwm_pwm_chip *pc;
u16 status;
- struct pinctrl *pinctrl;
-
- pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
- if (IS_ERR(pinctrl))
- dev_warn(&pdev->dev, "unable to select pin group\n");
pc = devm_kzalloc(&pdev->dev, sizeof(*pc), GFP_KERNEL);
if (!pc) {
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 06/12] drivers/mtd/nand/gpmi-nand: don't use devm_pinctrl_get_select_default() in probe
Since commit ab78029 (drivers/pinctrl: grab default handles from device core),
we can rely on device core for setting the default pins. Compile tested only.
Acked-by: Linus Walleij (personally at LCE13)
Signed-off-by: Wolfram Sang
---
drivers/mtd/nand/gpmi-nand/gpmi-nand.c |9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
index 25ecfa1..fd49464 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
@@ -26,7 +26,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -516,7 +515,6 @@ err_clock:
static int acquire_resources(struct gpmi_nand_data *this)
{
- struct pinctrl *pinctrl;
int ret;
ret = acquire_register_block(this, GPMI_NAND_GPMI_REGS_ADDR_RES_NAME);
@@ -535,19 +533,12 @@ static int acquire_resources(struct gpmi_nand_data *this)
if (ret)
goto exit_dma_channels;
- pinctrl = devm_pinctrl_get_select_default(&this->pdev->dev);
- if (IS_ERR(pinctrl)) {
- ret = PTR_ERR(pinctrl);
- goto exit_pin;
- }
-
ret = gpmi_get_clks(this);
if (ret)
goto exit_clock;
return 0;
exit_clock:
-exit_pin:
release_dma_channels(this);
exit_dma_channels:
release_bch_irq(this);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 04/12] drivers/mmc/host: don't use devm_pinctrl_get_select_default() in probe
Since commit ab78029 (drivers/pinctrl: grab default handles from device core),
we can rely on device core for setting the default pins. Compile tested only.
Acked-by: Linus Walleij (personally at LCE13)
Signed-off-by: Wolfram Sang
---
drivers/mmc/host/mvsdio.c |6 --
drivers/mmc/host/mxs-mmc.c |8
drivers/mmc/host/omap_hsmmc.c |7 ---
drivers/mmc/host/sdhci-esdhc-imx.c |8
drivers/mmc/host/sdhci-sirf.c |8
5 files changed, 37 deletions(-)
diff --git a/drivers/mmc/host/mvsdio.c b/drivers/mmc/host/mvsdio.c
index 8960fc8..ed5edc2 100644
--- a/drivers/mmc/host/mvsdio.c
+++ b/drivers/mmc/host/mvsdio.c
@@ -25,7 +25,6 @@
#include
#include
#include
-#include
#include
#include
@@ -686,7 +685,6 @@ static int __init mvsd_probe(struct platform_device *pdev)
struct resource *r;
int ret, irq;
int gpio_card_detect, gpio_write_protect;
- struct pinctrl *pinctrl;
r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
irq = platform_get_irq(pdev, 0);
@@ -703,10 +701,6 @@ static int __init mvsd_probe(struct platform_device *pdev)
host->mmc = mmc;
host->dev = &pdev->dev;
- pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
- if (IS_ERR(pinctrl))
- dev_warn(&pdev->dev, "no pins associated\n");
-
/*
* Some non-DT platforms do not pass a clock, and the clock
* frequency is passed through platform_data. On DT platforms,
diff --git a/drivers/mmc/host/mxs-mmc.c b/drivers/mmc/host/mxs-mmc.c
index 4278a17..1eb3224 100644
--- a/drivers/mmc/host/mxs-mmc.c
+++ b/drivers/mmc/host/mxs-mmc.c
@@ -41,7 +41,6 @@
#include
#include
#include
-#include
#include
#include
@@ -580,7 +579,6 @@ static int mxs_mmc_probe(struct platform_device *pdev)
struct mxs_mmc_host *host;
struct mmc_host *mmc;
struct resource *iores;
- struct pinctrl *pinctrl;
int ret = 0, irq_err;
struct regulator *reg_vmmc;
enum of_gpio_flags flags;
@@ -620,12 +618,6 @@ static int mxs_mmc_probe(struct platform_device *pdev)
}
}
- pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
- if (IS_ERR(pinctrl)) {
- ret = PTR_ERR(pinctrl);
- goto out_mmc_free;
- }
-
ssp->clk = clk_get(&pdev->dev, NULL);
if (IS_ERR(ssp->clk)) {
ret = PTR_ERR(ssp->clk);
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index eccedc7..332ce51 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -37,7 +37,6 @@
#include
#include
#include
-#include
#include
#include
@@ -1776,7 +1775,6 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
const struct of_device_id *match;
dma_cap_mask_t mask;
unsigned tx_req, rx_req;
- struct pinctrl *pinctrl;
match = of_match_device(of_match_ptr(omap_mmc_of_match), &pdev->dev);
if (match) {
@@ -1995,11 +1993,6 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
omap_hsmmc_disable_irq(host);
- pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
- if (IS_ERR(pinctrl))
- dev_warn(&pdev->dev,
- "pins are not configured from the driver\n");
-
omap_hsmmc_protect_card(host);
mmc_add_host(mmc);
diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c
b/drivers/mmc/host/sdhci-esdhc-imx.c
index d5f0d59..0880e3a 100644
--- a/drivers/mmc/host/sdhci-esdhc-imx.c
+++ b/drivers/mmc/host/sdhci-esdhc-imx.c
@@ -25,7 +25,6 @@
#include
#include
#include
-#include
#include
#include "sdhci-pltfm.h"
#include "sdhci-esdhc.h"
@@ -80,7 +79,6 @@ struct pltfm_imx_data {
int flags;
u32 scratchpad;
enum imx_esdhc_type devtype;
- struct pinctrl *pinctrl;
struct esdhc_platform_data boarddata;
struct clk *clk_ipg;
struct clk *clk_ahb;
@@ -544,12 +542,6 @@ static int sdhci_esdhc_imx_probe(struct platform_device
*pdev)
clk_prepare_enable(imx_data->clk_ipg);
clk_prepare_enable(imx_data->clk_ahb);
- imx_data->pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
- if (IS_ERR(imx_data->pinctrl)) {
- err = PTR_ERR(imx_data->pinctrl);
- goto disable_clk;
- }
-
host->quirks |= SDHCI_QUIRK_BROKEN_TIMEOUT_VAL;
if (is_imx25_esdhc(imx_data) || is_imx35_esdhc(imx_data))
diff --git a/drivers/mmc/host/sdhci-sirf.c b/drivers/mmc/host/sdhci-sirf.c
index 09805af..ccf12dd 100644
--- a/drivers/mmc/host/sdhci-sirf.c
+++ b/drivers/mmc/host/sdhci-sirf.c
@@ -13,7 +13,6 @@
#include
#include
#include
-#include
#include "sdhci-pltfm.h"
str
[PATCH 02/12] drivers/i2c/busses: don't use devm_pinctrl_get_select_default() in probe
Since commit ab78029 (drivers/pinctrl: grab default handles from device core),
we can rely on device core for setting the default pins. Compile tested only.
Acked-by: Linus Walleij (personally at LCE13)
Signed-off-by: Wolfram Sang
---
drivers/i2c/busses/i2c-omap.c | 13 -
1 file changed, 13 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 142b694d..d09512e 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -43,7 +43,6 @@
#include
#include
#include
-#include
/* I2C controller revisions */
#define OMAP_I2C_OMAP1_REV_2 0x20
@@ -216,8 +215,6 @@ struct omap_i2c_dev {
u16 syscstate;
u16 westate;
u16 errata;
-
- struct pinctrl *pins;
};
static const u8 reg_map_ip_v1[] = {
@@ -1120,16 +1117,6 @@ omap_i2c_probe(struct platform_device *pdev)
dev->set_mpu_wkup_lat = pdata->set_mpu_wkup_lat;
}
- dev->pins = devm_pinctrl_get_select_default(&pdev->dev);
- if (IS_ERR(dev->pins)) {
- if (PTR_ERR(dev->pins) == -EPROBE_DEFER)
- return -EPROBE_DEFER;
-
- dev_warn(&pdev->dev, "did not get pins for i2c error: %li\n",
-PTR_ERR(dev->pins));
- dev->pins = NULL;
- }
-
dev->dev = &pdev->dev;
dev->irq = irq;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: i2c: introduce i2c helper i2c_find_client_by_name()
> Briefly looking into ACPI tables we have and mechanisms that we 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. Laurent explained to me what V4L did and now does. It used to be the way tha V4L drivers did register I2C slaves according to platform_data. Now, with DT the slaves get instanciated earlier, so they now use notifiers to know when the slaves are in place. Something like this should probably be done here, too, instead of unregistering and re-registering. signature.asc Description: Digital signature
Re: [PATCH 1/4 v2] mfd: add STw481x driver
On Mon, Sep 16, 2013 at 02:51:18PM +0100, Mark Brown wrote:
> On Mon, Sep 16, 2013 at 02:44:35PM +0200, Linus Walleij wrote:
>
> > I've tried to fix this for DT-only I2C devices
> > and this very driver was the reason.
>
> > But a tiresome regression due to drivers relying on this
> > i2c_device_id not being NULL and inability to remove it from the I2C
> > core without refactoring the world ensued, see:
> > commit c80f52847c50109ca248c22efbf71ff10553dca4
>
> Oh, that was the change...
>
> > Reverted in:
> > commit 661f6c1cd926c6c973e03c6b5151d161f3a666ed
>
> > For this reason I think:
> > http://marc.info/?l=linux-next&m=137148411231784&w=2
>
> > I have tentatively given up getting pure DT I2C drivers
> > to probe, I don't think I have the whole picture, but
> > Wolfram has serious doubts about this and say we have
> > to be careful
>
> > Wolfram, do you have some ideas on how we should
> > proceed or ar you happy with merging this as-is?
>
> I'd have expected that it should be possible to change things such that
> the change in the core doesn't produce any change in behaviour for
> existing drivers. Can we not change the patch so that i2c_match_id()
> copes with getting a NULL id_table? Something like this:
I hacked something like this after Linus posted his approach. However, I
found out that run time instanciating ('new_device' file) needs an
id_table. I wasn't to keen on disabling the feature for dt-only drivers.
That's where I stopped, due to lack of time.
signature.asc
Description: Digital signature
Re: [PATCH 1/4 v2] mfd: add STw481x driver
> So in the mean time are you happy with this "dummy" approach? No. "dummy" is reserved for a dummy device in case an i2c slave needs more than one address. The proper solution would be if i2c_sysfs_new_device() could recognize the of_device_ids. signature.asc Description: Digital signature
Re: [PATCH v4 1/1 resend] i2c: rcar: modify I2C driver
On Tue, Sep 03, 2013 at 09:09:25AM +0900, Nguyen Viet Dung wrote: > This patch modify I2C driver of rcar-H1 to usable on both rcar-H1 and rcar-H2. > > Signed-off-by: Nguyen Viet Dung Applied to for-next, thanks! signature.asc Description: Digital signature
[PULL REQUEST] i2c for 3.12
Linus,
please pull the changes from the I2C subsystem for the 3.12 release. Highlights:
* OF and ACPI helpers are now included in the core, and not in external files
anymore.
This removes dependency problems for modules and is cleaner, in general.
* mv64xxx-driver gains fifo usage to support mv78230
* imx-driver overhaul to support VF610
* various cleanups, most notably related to devm_* and CONFIG_PM usage
* driver bugfixes and smaller feature additions
Thanks,
Wolfram
The following changes since commit c095ba7224d8edc71dcef0d655911399a8bd4a3f:
Linux 3.11-rc4 (2013-08-04 13:46:46 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/for-next
for you to fetch changes up to b720423a2627f045133bec39a31fe2bc0dab86f3:
i2c: rcar: add rcar-H2 support (2013-09-04 11:49:16 +0100)
Andy Lutomirski (1):
i2c: Improve logging on failure to probe for ->class devices
Chew, Chiau Ee (1):
i2c: designware: Manually set RESTART bit between messages
Fabio Estevam (2):
i2c: i2c-mxs: Use DMA mode even for small transfers
i2c: mxs: Check the return value from stmp_reset_block()
Gerhard Sittig (1):
i2c: mpc: cleanup clock API use
Gregory CLEMENT (2):
i2c: mv64xxx: Add I2C Transaction Generator support
i2c: mv64xxx: Fix timing issue on Armada XP (errata FE-8471889)
Grygorii Strashko (1):
i2c: omap: query STP always when NACK is received
Guenter Roeck (1):
i2c: mpc: Define unique I2C adapter names
Jingchang Lu (9):
i2c: imx: use struct representing i2c clk{div, val} pair
i2c: imx: enable clk before write to registers
i2c: imx: don't change platform device id_entry directly
i2c: imx: wrap registers read/write to inline function
i2c: imx: change register offset representation
i2c: imx: add INT flag and IEN bit operatation codes
i2c: imx: add struct to hold more configurable quirks
i2c: imx: Add Vybrid VF610 I2C controller support
i2c: imx: use exact SoC revision to document binding
Jingoo Han (8):
i2c: i2c-mpc: add CONFIG_PM_SLEEP to suspend/resume functions
i2c: designware: add CONFIG_PM_SLEEP to suspend/resume functions
i2c: ocores: add CONFIG_PM_SLEEP to suspend/resume functions
i2c: stu300: add CONFIG_PM_SLEEP to suspend/resume functions
i2c: pnx: add CONFIG_PM_SLEEP to suspend/resume functions
i2c: puv3: add CONFIG_PM_SLEEP to suspend function
i2c: i2c-bfin-twi: add CONFIG_PM_SLEEP to suspend/resume functions
i2c: use dev_get_platdata()
Julia Lawall (1):
drivers/i2c/busses/i2c-ocores.c: simplify use of devm_ioremap_resource
Jussi Kivilinna (1):
i2c: tiny-usb: do not use stack as URB transfer_buffer
Leilei Shang (1):
i2c: pxa: enable high speed mode for i2c bus
Lothar Waßmann (1):
i2c: mxs: fix broken timing calculation
Maxime Ripard (1):
i2c: mv64xxx: Document the newly introduced allwinner compatible
Michael Brunner (1):
i2c: Fix Kontron PLD prescaler calculation
Mika Westerberg (3):
i2c: move ACPI helpers into the core
i2c: designware: make HCNT/LCNT values configurable
i2c: designware: get SDA hold time, HCNT and LCNT configuration from ACPI
Nguyen Viet Dung (1):
i2c: rcar: add rcar-H2 support
Phil Carmody (1):
i2c: reduce parent checking to a NOOP in non-I2C_MUX case
Rudolf Marek (1):
i2c: piix4: Add support for secondary SMBus on AMD SB800 and AMD FCH
chipsets
Sachin Kamat (1):
Documentation: i2c: Fix example in instantiating-devices
Santosh Shilimkar (2):
i2c: davinci: remove useless mach/hardware include
i2c: davinci: Allow i2c driver available for keystone platforms
Sebastian Hesselbarth (1):
i2c: add sanity check to i2c_put_adapter
Wei Yongjun (1):
i2c: pnx: fix error return code in i2c_pnx_probe()
Wolfram Sang (6):
drivers/i2c/busses: don't use devm_pinctrl_get_select_default() in probe
drivers/i2c/busses: don't check resource with devm_ioremap_resource
i2c: powermac: fix return path on error
i2c: move OF helpers into the core
i2c: mv64xxx: fix typo in binding documentation
i2c: ismt: add error return code in probe()
Zhiwu Song (5):
i2c: sirf: reset i2c controller early after we get a noack
i2c: sirf: we need to wait I2C_RESET status in resume
i2c: sirf: fix the typo for setting bitrate to less than 100k
i2c: sirf: support reverse direction of address
i2c: sirf: retry 3 times as sometimes we get random noack and timeout
Documentation/acpi/enumeration.txt | 16 +-
Documentation/devicetree/bindings/i2c/i2c-imx.txt |5 +-
.../devicetree/bindings/i2c/i2c-mv64xxx.txt| 12 +-
Documentation/i2c/busses/i2c-piix4 |7 +-
Documentation/i2c/instantiating-devices
Re: [PATCH] i2c: exynos5: add High Speed I2C controller driver
On Wed, Aug 21, 2013 at 02:54:37PM +0530, Naveen Krishna Ch wrote:
> Adds support for High Speed I2C driver found in Exynos5 and
> later SoCs from Samsung.
>
> Highspeed mode is a minor change in the i2c protocol.
> Starts with
> 1. start condition,
> 2. 8-bit master ID code (1xxx)
> 3. followed by a NACK bit
> Once the above conditions are met, the bus is now operates in highspeed mode.
> The rest of the I2C protocol applies the same.
The description is correct, but it is not a change in the protocol. This
is fully specified in the I2C specs.
> Driver only supports Device Tree method.
>
> Changes since v1:
> 1. Added FIFO functionality
> 2. Added High speed mode functionality
> 3. Remove SMBUS_QUICK
> 4. Remove the debugfs functionality
> 5. Use devm_* functions where ever possible
> 6. Driver is free from GPIO configs
> 7. Use OF data string "clock-frequency" to get the bus operating frequencies
> 8. Split the clock divisor calculation function
> 9. Add resets for the failed transacton cases
> 10. Removed retries as core does retries if -EAGAIN is returned
> 11. Removed mode from device tree info (use speed to distinguish
> the mode of operation)
> 12. Use wait_for_completion_timeout as the interruptible case is not tested
> well
> 13. few other bug fixes and cosmetic changes
> 14. Removed the untested runtime_pm code
> 15. Removed the retries as core does that
> 16. Use adap.nr instead of alias
> 17. Added spinlocks around the irq code
> 18. Use i2c_add_numbered_adapter() instead of using aliases
Changes since v1 are irrelevant for the patch description.
>
> Signed-off-by: Taekgyun Ko
> Signed-off-by: Naveen Krishna Chatradhi
> Reviewed-by: Simon Glass
> Tested-by: Andrew Bresticker
> Signed-off-by: Yuvaraj Kumar C D
> Signed-off-by: Andrew Bresticker
>
> ---
> Wolfram and Thomas Figa thanks for reviewing the code.
>
> Changes since v10:
> 1. Remove the incomplete runtime_pm code
> 2. Correct the error checks as suggested by Thomas
> 3. Use i2c_add_numbered_adapter() as suggested
> 4. Modified the irq routine to handle the specific interrupts
> 5. Added spinlocks around the irq code
> 6. Remove the "mode" of operation field from device tree node and use the
>clock-frequency to decide the mode.
>
> .../devicetree/bindings/i2c/i2c-exynos5.txt| 44 ++
> drivers/i2c/busses/Kconfig |7 +
> drivers/i2c/busses/Makefile|1 +
> drivers/i2c/busses/i2c-exynos5.c | 799
>
> 4 files changed, 851 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
> create mode 100644 drivers/i2c/busses/i2c-exynos5.c
>
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
> b/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
> new file mode 100644
> index 000..805e018
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
> @@ -0,0 +1,44 @@
> +* Samsung's High Speed I2C controller
> +
> +The Samsung's High Speed I2C controller is used to interface with I2C devices
> +at various speeds ranging from 100khz to 3.4Mhz.
> +
> +Required properties:
> + - compatible: value should be.
> + -> "samsung,exynos5-hsi2c", for i2c compatible with exynos5 hsi2c.
> + - reg: physical base address of the controller and length of memory mapped
> +region.
> + - interrupts: interrupt number to the cpu.
> + - #address-cells: always 1 (for i2c addresses)
> + - #size-cells: always 0
> +
> + - Pinctrl:
> +- pinctrl-0: Pin control group to be used for this controller.
> +- pinctrl-names: Should contain only one value - "default".
> +
> +Optional properties:
> + - clock-frequency: Desired operating frequency in Hz of the bus.
> +-> If not specified, the default value is 100khz in fast-speed mode and
> + 1Mhz in high-speed mode.
Description doesn't match the current code.
> +-> If specified, The bus operates in high-speed mode only if the
> + clock-frequency is >= 1Mhz.
s/The/the/
...
> +/*
> + * exynos5_i2c_init: configures the controller for I2C functionality
> + * Programs I2C controller for Master mode operation
> + */
> +static void exynos5_i2c_init(struct exynos5_i2c *i2c)
> +{
> + u32 i2c_conf = readl(i2c->regs + HSI2C_CONF);
> + u32 i2c_timeout = readl(i2c->regs + HSI2C_TIMEOUT);
> +
> + /* Disable timeout */
> + i2c_timeout &= ~HSI2C_TIMEOUT_EN;
> + writel(i2c_timeout, i2c->regs + HSI2C_TIMEOUT);
Just curious: Can't you use HSI2C_TIMEOUT and wait_for_completion
instead of wait_for_completion_timeout? If so, it might save you a
little bit of overhead.
> +
> + writel((HSI2C_FUNC_MODE_I2C | HSI2C_MASTER),
> + i2c->regs + HSI2C_CTL);
> + writel(HSI2C_TRAILING_COUNT, i2c->regs + HSI2C_TRAILIG_CTL);
> +
> + if (i2c->speed_mode == HSI2C_HIGH_SPD) {
> + writel(HSI2C_MASTER_ID(MASTER_ID(i2c->adap.nr)),
> +
Re: [PATCH v2 8/9] spi: prepare runtime PM support for SPI devices
On Thu, Sep 12, 2013 at 01:04:55PM +0200, Rafael J. Wysocki wrote: > On Thursday, September 12, 2013 12:43:02 PM Mika Westerberg wrote: > > On Thu, Sep 12, 2013 at 10:31:45AM +0100, Mark Brown wrote: > > > On Thu, Sep 12, 2013 at 12:27:43PM +0300, Mika Westerberg wrote: > > > > On Wed, Sep 11, 2013 at 04:51:20PM +0100, Mark Brown wrote: > > > > > > > > I would be able to have this and the other patch in the SPI tree in > > > > > case > > > > > it overlaps with other work - I'm not sure what the plan will be for > > > > > merging this stuff but if there were a branch which I could merge into > > > > > the SPI tree that'd be good. > > > > > > > I think these two can go via your SPI tree as they shouldn't have > > > > dependencies to the I2C tree. > > > > > > There's all the driver changes though - it seems best to push the whole > > > series through one branch so there's fewer bisection problems. > > > > Ah, right. Then I suppose the right tree would be the I2C tree (as majority > > of the patches are I2C related)? > > > > Wolfram, are you OK with this? > > Alternatively, I can apply them too if everyone is OK with that. > > They are PM+ACPI changes after all ... I'd like to give at least an ACK. But I need to find some time for that. Is it urgent? Looks like 3.13 material to me... signature.asc Description: Digital signature
[PATCH 8/9] spi: spi-s3c64xx: replace platform_driver_probe to support deferred probing
Subsystems like pinctrl and gpio rightfully make use of deferred probing at
core level. Now, deferred drivers won't be retried if they don't have a .probe
function specified in the driver struct. Fix this driver to have that, so the
devices it supports won't get lost in a deferred probe.
Signed-off-by: Wolfram Sang
---
drivers/spi/spi-s3c64xx.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index 512b889..3df81c6 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -1633,6 +1633,7 @@ static struct platform_driver s3c64xx_spi_driver = {
.pm = &s3c64xx_spi_pm,
.of_match_table = of_match_ptr(s3c64xx_spi_dt_match),
},
+ .probe = s3c64xx_spi_probe,
.remove = s3c64xx_spi_remove,
.id_table = s3c64xx_spi_driver_ids,
};
@@ -1640,7 +1641,7 @@ MODULE_ALIAS("platform:s3c64xx-spi");
static int __init s3c64xx_spi_init(void)
{
- return platform_driver_probe(&s3c64xx_spi_driver, s3c64xx_spi_probe);
+ return platform_driver_register(&s3c64xx_spi_driver);
}
subsys_initcall(s3c64xx_spi_init);
--
1.8.4.rc3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 9/9] spi: spi-txx9: replace platform_driver_probe to support deferred probing
Subsystems like pinctrl and gpio rightfully make use of deferred probing at
core level. Now, deferred drivers won't be retried if they don't have a .probe
function specified in the driver struct. Fix this driver to have that, so the
devices it supports won't get lost in a deferred probe.
Signed-off-by: Wolfram Sang
---
drivers/spi/spi-txx9.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi-txx9.c b/drivers/spi/spi-txx9.c
index 7c6d157..c67a1b8 100644
--- a/drivers/spi/spi-txx9.c
+++ b/drivers/spi/spi-txx9.c
@@ -440,6 +440,7 @@ static int txx9spi_remove(struct platform_device *dev)
MODULE_ALIAS("platform:spi_txx9");
static struct platform_driver txx9spi_driver = {
+ .probe = txx9spi_probe,
.remove = txx9spi_remove,
.driver = {
.name = "spi_txx9",
@@ -449,7 +450,7 @@ static struct platform_driver txx9spi_driver = {
static int __init txx9spi_init(void)
{
- return platform_driver_probe(&txx9spi_driver, txx9spi_probe);
+ return platform_driver_register(&txx9spi_driver);
}
subsys_initcall(txx9spi_init);
--
1.8.4.rc3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/9] spi: spi-au1550: replace platform_driver_probe to support deferred probing
Subsystems like pinctrl and gpio rightfully make use of deferred probing at
core level. Now, deferred drivers won't be retried if they don't have a .probe
function specified in the driver struct. Fix this driver to have that, so the
devices it supports won't get lost in a deferred probe.
Signed-off-by: Wolfram Sang
---
drivers/spi/spi-au1550.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi-au1550.c b/drivers/spi/spi-au1550.c
index 1d00d9b3..313dd49 100644
--- a/drivers/spi/spi-au1550.c
+++ b/drivers/spi/spi-au1550.c
@@ -985,6 +985,7 @@ static int au1550_spi_remove(struct platform_device *pdev)
MODULE_ALIAS("platform:au1550-spi");
static struct platform_driver au1550_spi_drv = {
+ .probe = au1550_spi_probe,
.remove = au1550_spi_remove,
.driver = {
.name = "au1550-spi",
@@ -1004,7 +1005,7 @@ static int __init au1550_spi_init(void)
printk(KERN_ERR "au1550-spi: cannot add memory"
"dbdma device\n");
}
- return platform_driver_probe(&au1550_spi_drv, au1550_spi_probe);
+ return platform_driver_register(&au1550_spi_drv);
}
module_init(au1550_spi_init);
--
1.8.4.rc3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/9] spi: spi-omap-uwire: replace platform_driver_probe to support deferred probing
Subsystems like pinctrl and gpio rightfully make use of deferred probing at
core level. Now, deferred drivers won't be retried if they don't have a .probe
function specified in the driver struct. Fix this driver to have that, so the
devices it supports won't get lost in a deferred probe.
Signed-off-by: Wolfram Sang
---
drivers/spi/spi-omap-uwire.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-omap-uwire.c b/drivers/spi/spi-omap-uwire.c
index a6a8f09..9313fd3 100644
--- a/drivers/spi/spi-omap-uwire.c
+++ b/drivers/spi/spi-omap-uwire.c
@@ -557,7 +557,8 @@ static struct platform_driver uwire_driver = {
.name = "omap_uwire",
.owner = THIS_MODULE,
},
- .remove = uwire_remove,
+ .probe = uwire_probe,
+ .remove = uwire_remove,
// suspend ... unuse ck
// resume ... use ck
};
@@ -579,7 +580,7 @@ static int __init omap_uwire_init(void)
omap_writel(val | 0x00AAA000, OMAP7XX_IO_CONF_9);
}
- return platform_driver_probe(&uwire_driver, uwire_probe);
+ return platform_driver_register(&uwire_driver);
}
static void __exit omap_uwire_exit(void)
--
1.8.4.rc3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/9] spi: spi-bfin5xx: replace platform_driver_probe to support deferred probing
Subsystems like pinctrl and gpio rightfully make use of deferred probing at
core level. Now, deferred drivers won't be retried if they don't have a .probe
function specified in the driver struct. Fix this driver to have that, so the
devices it supports won't get lost in a deferred probe.
Signed-off-by: Wolfram Sang
---
drivers/spi/spi-bfin5xx.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-bfin5xx.c b/drivers/spi/spi-bfin5xx.c
index 45bdf73..a563bd5 100644
--- a/drivers/spi/spi-bfin5xx.c
+++ b/drivers/spi/spi-bfin5xx.c
@@ -1462,12 +1462,13 @@ static struct platform_driver bfin_spi_driver = {
},
.suspend= bfin_spi_suspend,
.resume = bfin_spi_resume,
- .remove = bfin_spi_remove,
+ .probe = bfin_spi_probe,
+ .remove = bfin_spi_remove,
};
static int __init bfin_spi_init(void)
{
- return platform_driver_probe(&bfin_spi_driver, bfin_spi_probe);
+ return platform_driver_register(&bfin_spi_driver);
}
subsys_initcall(bfin_spi_init);
--
1.8.4.rc3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/9] i2c: i2c-designware-platdrv: replace platform_driver_probe to support deferred probing
Subsystems like pinctrl and gpio rightfully make use of deferred probing at
core level. Now, deferred drivers won't be retried if they don't have a .probe
function specified in the driver struct. Fix this driver to have that, so the
devices it supports won't get lost in a deferred probe.
Signed-off-by: Wolfram Sang
Cc: Zhangfei Gao
---
drivers/i2c/busses/i2c-designware-platdrv.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c
b/drivers/i2c/busses/i2c-designware-platdrv.c
index 4c1b605..0aa0113 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -270,7 +270,8 @@ static SIMPLE_DEV_PM_OPS(dw_i2c_dev_pm_ops, dw_i2c_suspend,
dw_i2c_resume);
MODULE_ALIAS("platform:i2c_designware");
static struct platform_driver dw_i2c_driver = {
- .remove = dw_i2c_remove,
+ .probe = dw_i2c_probe,
+ .remove = dw_i2c_remove,
.driver = {
.name = "i2c_designware",
.owner = THIS_MODULE,
@@ -282,7 +283,7 @@ static struct platform_driver dw_i2c_driver = {
static int __init dw_i2c_init_driver(void)
{
- return platform_driver_probe(&dw_i2c_driver, dw_i2c_probe);
+ return platform_driver_register(&dw_i2c_driver);
}
subsys_initcall(dw_i2c_init_driver);
--
1.8.4.rc3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/9] fix deferred probing issue of platform_driver_probe
We had some issues with deferred probing in the I2C subsystem. This series attempts to fix a part of it. From the patch description: === Subsystems like pinctrl and gpio rightfully make use of deferred probing at core level. Now, deferred drivers won't be retried if they don't have a .probe function specified in the driver struct. Fix this driver to have that, so the devices it supports won't get lost in a deferred probe. === I think it makes sense to remove platform_driver_probe from bus masters like i2c and spi (especially since they are dependant on pinctrl these days). This is what this series does. I had a look at dma drivers as well, but there are more things to be considered, so delayed for now. Please comment. If no objections are raised, I'd like to bring at least the I2C patches into v3.12, so deferred devices will then be correctly probed. The series is based on 3.12-rc4 and was compile-tested. It is available at git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git platform_driver_probe_drop Regards, Wolfram Wolfram Sang (9): i2c: i2c-designware-platdrv: replace platform_driver_probe to support deferred probing i2c: i2c-imx: replace platform_driver_probe to support deferred probing i2c: i2c-mxs: replace platform_driver_probe to support deferred probing i2c: i2c-stu300: replace platform_driver_probe to support deferred probing spi: spi-au1550: replace platform_driver_probe to support deferred probing spi: spi-bfin5xx: replace platform_driver_probe to support deferred probing spi: spi-omap-uwire: replace platform_driver_probe to support deferred probing spi: spi-s3c64xx: replace platform_driver_probe to support deferred probing spi: spi-txx9: replace platform_driver_probe to support deferred probing drivers/i2c/busses/i2c-designware-platdrv.c | 5 +++-- drivers/i2c/busses/i2c-imx.c| 11 ++- drivers/i2c/busses/i2c-mxs.c| 3 ++- drivers/i2c/busses/i2c-stu300.c | 11 +-- drivers/spi/spi-au1550.c| 3 ++- drivers/spi/spi-bfin5xx.c | 5 +++-- drivers/spi/spi-omap-uwire.c| 5 +++-- drivers/spi/spi-s3c64xx.c | 3 ++- drivers/spi/spi-txx9.c | 3 ++- 9 files changed, 28 insertions(+), 21 deletions(-) -- 1.8.4.rc3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/9] i2c: i2c-stu300: replace platform_driver_probe to support deferred probing
Subsystems like pinctrl and gpio rightfully make use of deferred probing at
core level. Now, deferred drivers won't be retried if they don't have a .probe
function specified in the driver struct. Fix this driver to have that, so the
devices it supports won't get lost in a deferred probe.
Signed-off-by: Wolfram Sang
Cc: Linus Walleij
---
drivers/i2c/busses/i2c-stu300.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-stu300.c b/drivers/i2c/busses/i2c-stu300.c
index f8f6f2e..04a17b9 100644
--- a/drivers/i2c/busses/i2c-stu300.c
+++ b/drivers/i2c/busses/i2c-stu300.c
@@ -859,8 +859,7 @@ static const struct i2c_algorithm stu300_algo = {
.functionality = stu300_func,
};
-static int __init
-stu300_probe(struct platform_device *pdev)
+static int stu300_probe(struct platform_device *pdev)
{
struct stu300_dev *dev;
struct i2c_adapter *adap;
@@ -966,8 +965,7 @@ static SIMPLE_DEV_PM_OPS(stu300_pm, stu300_suspend,
stu300_resume);
#define STU300_I2C_PM NULL
#endif
-static int __exit
-stu300_remove(struct platform_device *pdev)
+static int stu300_remove(struct platform_device *pdev)
{
struct stu300_dev *dev = platform_get_drvdata(pdev);
@@ -989,13 +987,14 @@ static struct platform_driver stu300_i2c_driver = {
.pm = STU300_I2C_PM,
.of_match_table = stu300_dt_match,
},
- .remove = __exit_p(stu300_remove),
+ .probe = stu300_probe,
+ .remove = stu300_remove,
};
static int __init stu300_init(void)
{
- return platform_driver_probe(&stu300_i2c_driver, stu300_probe);
+ return platform_driver_register(&stu300_i2c_driver);
}
static void __exit stu300_exit(void)
--
1.8.4.rc3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/9] i2c: i2c-mxs: replace platform_driver_probe to support deferred probing
Subsystems like pinctrl and gpio rightfully make use of deferred probing at
core level. Now, deferred drivers won't be retried if they don't have a .probe
function specified in the driver struct. Fix this driver to have that, so the
devices it supports won't get lost in a deferred probe.
Signed-off-by: Wolfram Sang
Cc: Marek Vasut
---
drivers/i2c/busses/i2c-mxs.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-mxs.c b/drivers/i2c/busses/i2c-mxs.c
index f4a0167..b7c8577 100644
--- a/drivers/i2c/busses/i2c-mxs.c
+++ b/drivers/i2c/busses/i2c-mxs.c
@@ -780,12 +780,13 @@ static struct platform_driver mxs_i2c_driver = {
.owner = THIS_MODULE,
.of_match_table = mxs_i2c_dt_ids,
},
+ .probe = mxs_i2c_probe,
.remove = mxs_i2c_remove,
};
static int __init mxs_i2c_init(void)
{
- return platform_driver_probe(&mxs_i2c_driver, mxs_i2c_probe);
+ return platform_driver_register(&mxs_i2c_driver);
}
subsys_initcall(mxs_i2c_init);
--
1.8.4.rc3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/9] i2c: i2c-imx: replace platform_driver_probe to support deferred probing
Subsystems like pinctrl and gpio rightfully make use of deferred probing at
core level. Now, deferred drivers won't be retried if they don't have a .probe
function specified in the driver struct. Fix this driver to have that, so the
devices it supports won't get lost in a deferred probe.
Signed-off-by: Wolfram Sang
Cc: ker...@pengutronix.de
---
drivers/i2c/busses/i2c-imx.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
index ccf4665..1d7efa3 100644
--- a/drivers/i2c/busses/i2c-imx.c
+++ b/drivers/i2c/busses/i2c-imx.c
@@ -365,7 +365,7 @@ static void i2c_imx_stop(struct imx_i2c_struct *i2c_imx)
clk_disable_unprepare(i2c_imx->clk);
}
-static void __init i2c_imx_set_clk(struct imx_i2c_struct *i2c_imx,
+static void i2c_imx_set_clk(struct imx_i2c_struct *i2c_imx,
unsigned int rate)
{
struct imx_i2c_clk_pair *i2c_clk_div = i2c_imx->hwdata->clk_div;
@@ -589,7 +589,7 @@ static struct i2c_algorithm i2c_imx_algo = {
.functionality = i2c_imx_func,
};
-static int __init i2c_imx_probe(struct platform_device *pdev)
+static int i2c_imx_probe(struct platform_device *pdev)
{
const struct of_device_id *of_id = of_match_device(i2c_imx_dt_ids,
&pdev->dev);
@@ -697,7 +697,7 @@ static int __init i2c_imx_probe(struct platform_device
*pdev)
return 0; /* Return OK */
}
-static int __exit i2c_imx_remove(struct platform_device *pdev)
+static int i2c_imx_remove(struct platform_device *pdev)
{
struct imx_i2c_struct *i2c_imx = platform_get_drvdata(pdev);
@@ -715,7 +715,8 @@ static int __exit i2c_imx_remove(struct platform_device
*pdev)
}
static struct platform_driver i2c_imx_driver = {
- .remove = __exit_p(i2c_imx_remove),
+ .probe = i2c_imx_probe,
+ .remove = i2c_imx_remove,
.driver = {
.name = DRIVER_NAME,
.owner = THIS_MODULE,
@@ -726,7 +727,7 @@ static struct platform_driver i2c_imx_driver = {
static int __init i2c_adap_imx_init(void)
{
- return platform_driver_probe(&i2c_imx_driver, i2c_imx_probe);
+ return platform_driver_register(&i2c_imx_driver);
}
subsys_initcall(i2c_adap_imx_init);
--
1.8.4.rc3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] i2c-mux-gpio: use deferred probing with the device tree
On Tue, Oct 08, 2013 at 03:51:50PM +0200, Ionut Nicu wrote:
> If the i2c-parent bus driver is not loaded, returning
> -EINVAL will force people to unload and then reload the
> module again to get it working.
>
> Signed-off-by: Ionut Nicu
Doesn't the non-DT case need fixing, too?
> ---
> drivers/i2c/muxes/i2c-mux-gpio.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/i2c/muxes/i2c-mux-gpio.c
> b/drivers/i2c/muxes/i2c-mux-gpio.c
> index 5d4a99b..eb99f04 100644
> --- a/drivers/i2c/muxes/i2c-mux-gpio.c
> +++ b/drivers/i2c/muxes/i2c-mux-gpio.c
> @@ -79,7 +79,7 @@ static int i2c_mux_gpio_probe_dt(struct gpiomux *mux,
> adapter = of_find_i2c_adapter_by_node(adapter_np);
> if (!adapter) {
> dev_err(&pdev->dev, "Cannot find parent bus\n");
> - return -ENODEV;
> + return -EPROBE_DEFER;
> }
> mux->data.parent = i2c_adapter_id(adapter);
> put_device(&adapter->dev);
> --
> 1.7.1
signature.asc
Description: Digital signature
Re: [PATCH 1/2] i2c-mux-gpio: use deferred probing with the device tree
> > WS> Doesn't the non-DT case need fixing, too? > > > > Arguably yes. > > Yes, and it's also a one line fix. Should I do it in a separate > patch or should I change this one and resubmit? Resubmit please. signature.asc Description: Digital signature
Re: [PATCH] i2c: omap: Clear ARDY bit twice
On Mon, Oct 07, 2013 at 01:41:59PM +0300, Taras Kondratiuk wrote: > Initially commit cb527ede1bf6ff2008a025606f25344b8ed7b4ac > "i2c-omap: Double clear of ARDY status in IRQ handler" > added a workaround for undocumented errata ProDB0017052. > But then commit 1d7afc95946487945cc7f5019b41255b72224b70 > "i2c: omap: ack IRQ in parts" refactored code and missed > one of ARDY clearings. So current code violates errata. > It causes often i2c bus timeouts on my Pandaboard. > > This patch adds a second clearing in place. > > Signed-off-by: Grygorii Strashko > Signed-off-by: Taras Kondratiuk Applied to for-current with stable tag, thanks! signature.asc Description: Digital signature
Re: [PATCH 2/3] i2c: attach/detach I2C client device to the ACPI power domain
On Wed, Oct 09, 2013 at 05:04:20PM +0300, Mika Westerberg wrote: > From: Lv Zheng > > If the I2C client device is enumerated from ACPI namespace it might have > ACPI methods that needs to be called in order to transition the device to > different power states (such as _PSx). > > Implement this for I2C client devices by checking if the device has an ACPI > handle and if that's the case, attach it to the ACPI power domain. In > addition we make sure that the device is fully powered when its ->probe() > function gets called. > > For non-ACPI devices this patch is a no-op. > > Signed-off-by: Lv Zheng > Signed-off-by: Mika Westerberg > --- > drivers/i2c/i2c-core.c | 10 ++ > 1 file changed, 10 insertions(+) > > diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c > index 29d3f04..f25dee3 100644 > --- a/drivers/i2c/i2c-core.c > +++ b/drivers/i2c/i2c-core.c > @@ -254,10 +254,16 @@ static int i2c_device_probe(struct device *dev) > client->flags & I2C_CLIENT_WAKE); > dev_dbg(dev, "probe\n"); > > + if (ACPI_HANDLE(&client->dev)) > + acpi_dev_pm_attach(&client->dev, true); I'd prefer to drop the 'if's in case they are checked inside the acpi_* calls anyway. Not a show-stopper, though, so: Acked-by: Wolfram Sang signature.asc Description: Digital signature
Re: [PATCH 1/2] i2c-mux-gpio: test if the gpio can sleep
On Thu, Oct 10, 2013 at 10:39:32AM +0200, Ionut Nicu wrote:
> Some gpio chips may have get/set operations that
> can sleep. For this type of chips we must use the
> _cansleep() version of gpio_set_value.
>
> Signed-off-by: Ionut Nicu
> ---
> drivers/i2c/muxes/i2c-mux-gpio.c | 11 ---
> 1 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/i2c/muxes/i2c-mux-gpio.c
> b/drivers/i2c/muxes/i2c-mux-gpio.c
> index a764da7..b5f17ef 100644
> --- a/drivers/i2c/muxes/i2c-mux-gpio.c
> +++ b/drivers/i2c/muxes/i2c-mux-gpio.c
> @@ -27,11 +27,16 @@ struct gpiomux {
>
> static void i2c_mux_gpio_set(const struct gpiomux *mux, unsigned val)
> {
> + unsigned gpio;
> int i;
>
> - for (i = 0; i < mux->data.n_gpios; i++)
> - gpio_set_value(mux->gpio_base + mux->data.gpios[i],
> -val & (1 << i));
> + for (i = 0; i < mux->data.n_gpios; i++) {
> + gpio = mux->gpio_base + mux->data.gpios[i];
> + if (gpio_cansleep(gpio))
> + gpio_set_value_cansleep(gpio, val & (1 << i));
> + else
> + gpio_set_value(gpio, val & (1 << i));
> + }
There should be a wrapper for that in the gpio-subsystem IMO.
Adding linux-gpio to cc.
signature.asc
Description: Digital signature
Re: [PATCH v4 0/4] Add I2C support to ST SoCs
> > Changes since v3: > >- Switch back to vendor specific DT properties regarding the anti-glitch > > filter configuration, as this IP is the only one having such a filter. > Do you agree to keep these properties vendor-specifics? My preference is generic bindings. There are no other users right now, yet there might be in the future. At least with something similar enough that the bindings will apply. Was hoping for some additional input, though, but I am not depending on it. > If so, could you take this series for v3.13? Sure, if it passes the second review... signature.asc Description: Digital signature
Re: [PATCH 1/2] i2c-mux-gpio: test if the gpio can sleep
On Thu, Oct 10, 2013 at 10:46:41AM +0200, Lars-Peter Clausen wrote: > > + if (gpio_cansleep(gpio)) > > + gpio_set_value_cansleep(gpio, val & (1 << i)); > > + else > > + gpio_set_value(gpio, val & (1 << i)); > > The proper way to do this is just always use the _cansleep() version. > gpio_set_value() only works for chips which do not sleep, > gpio_set_value_cansleep() works for both those who do sleep and those who do > not. To the gpio-list: Has it been considered to have sth. like gpio_set_value and gpio_set_value_nosleep? I'd think it makes more sense to have the specific function have the specific name. Regards, Wolfram signature.asc Description: Digital signature
Re: [PATCH] i2c: i2c-dev: Create 'name' attribute automatically
Hi, > > What race condition? > > > > Userspace trying to access the name attribute before it is created. > See http://kroah.com/log/blog/2013/06/26/how-to-create-a-sysfs-file-correctly/ Thanks! > > Have you tried this with two instances? I don't think it will work since > > class_register modifies the class struct. > > > Half a dozen instances, actually. Unless I am missing something, seems to be My bad. Sorry for the noise. > Anyway, the patch is obsolete; one is supposed to use class->dev_groups now. Are you willing to update the patch? Thanks, Wolfram signature.asc Description: Digital signature
