On Wed, Jul 29, 2015 at 12:27:30PM +0200, Jan Lübbe wrote:
On Di, 2015-07-14 at 14:12 +0200, Wolfram Sang wrote:
On Tue, Jul 14, 2015 at 03:10:01PM +0300, Grygorii Strashko wrote:
Hi Wolfram,
On 07/14/2015 02:10 PM, Wolfram Sang wrote:
On Wed, Jul 08, 2015 at 04:35:27PM +0200, Jan
On Wed, Jul 08, 2015 at 04:35:27PM +0200, Jan Luebbe wrote:
At least on the AM335x, enabling OMAP_I2C_SYSTEST_ST_EN is not enough to
allow direct access to the SCL and SDA pins. In addition to ST_EN, we
need to set the TMODE to 0b11 (Loop back SDA/SCL IO mode select).
Also, as the reset
On Wed, Jul 08, 2015 at 04:35:06PM +0200, Jan Luebbe wrote:
Using set_scl may be ineffective before calling the driver specific
prepare_recovery callback, which might change into a test mode. So
instead of setting SCL in i2c_generic_scl_recovery, move it to
i2c_generic_recovery (after the
On Tue, Jul 14, 2015 at 02:10:47PM +0200, Wolfram Sang wrote:
Patch i2c: omap: abolish variable name confusion triggered a
coccinelle warning which we fix here:
drivers/i2c/busses/i2c-omap.c:1333:5-24: pm_runtime_get_sync returns 0 as
error. Unecessary IS_ERR_VALUE at line 1334
Signed
On Mon, Jul 13, 2015 at 03:38:02PM -0500, Felipe Balbi wrote:
there's no need to fetch the platform_device
in order to dereference it back to the dev
pointer to access drvdata, we can use
dev_get_drvdata() instead.
Signed-off-by: Felipe Balbi ba...@ti.com
All patches applied to for-next,
On Wed, Jul 08, 2015 at 04:35:27PM +0200, Jan Luebbe wrote:
At least on the AM335x, enabling OMAP_I2C_SYSTEST_ST_EN is not enough to
Felipe: it seems you did not need this; is this AM335x specific?
allow direct access to the SCL and SDA pins. In addition to ST_EN, we
need to set the TMODE to
Patch i2c: omap: abolish variable name confusion triggered a
coccinelle warning which we fix here:
drivers/i2c/busses/i2c-omap.c:1333:5-24: pm_runtime_get_sync returns 0 as
error. Unecessary IS_ERR_VALUE at line 1334
Signed-off-by: Wolfram Sang w...@the-dreams.de
---
drivers/i2c/busses/i2c
On Tue, Jul 14, 2015 at 03:10:01PM +0300, Grygorii Strashko wrote:
Hi Wolfram,
On 07/14/2015 02:10 PM, Wolfram Sang wrote:
On Wed, Jul 08, 2015 at 04:35:27PM +0200, Jan Luebbe wrote:
At least on the AM335x, enabling OMAP_I2C_SYSTEST_ST_EN is not enough to
Felipe: it seems you did
60 s sounds way too much and actually I simply don't believe this is
the root cause. If I take a look into the driver, then I see, that
I agree, this is just a workaround.
the design is not really the best. The whole IRQ handling could be
actually performed in hard IRQ handler, without
On Thu, Jun 25, 2015 at 02:34:48PM -0500, Felipe Balbi wrote:
there's no need to fetch the platform_device
in order to dereference it back to the dev
pointer to access drvdata, we can use
dev_get_drvdata() instead.
Signed-off-by: Felipe Balbi ba...@ti.com
Applied to for-next, thanks!
On Thu, Jun 25, 2015 at 02:34:49PM -0500, Felipe Balbi wrote:
struct device pointers are usually called
dev. Calling our struct omap_i2c_dev pointers
also dev has caused enough confusion.
This is the result of a few simple sed rules
to convert all struct omap_i2c_dev pointers
to be called
On Thu, Jun 18, 2015 at 12:25:58PM -0500, Felipe Balbi wrote:
On Thu, Jun 18, 2015 at 10:09:59AM +0200, Alexander Sverdlin wrote:
Hello Felipe,
On 17/06/15 21:31, ext Felipe Balbi wrote:
With this patch we try to be as close to 50%
duty cycle as possible. The reason for this
is
On Wed, Apr 22, 2015 at 12:49:02PM +0200, Pascal Huerst wrote:
On 22.04.2015 12:28, Wolfram Sang wrote:
I assume you have a different kernel config where something is enabled
which includes the pinctrl-stuff in another include which is included
by these drivers. Although, my .config
On Fri, Apr 17, 2015 at 05:07:57PM +0200, pascal.hue...@gmail.com wrote:
From: Pascal Huerst pascal.hue...@gmail.com
This adds calls to pinctrl subsystem in order to switch pin states
on suspend/resume if you provide a sleep state in DT.
Signed-off-by: Pascal Huerst pascal.hue...@gmail.com
You are right, the include is missing. I just reapplied the patch,
compiled and interestingly enough, I don't get any compile errors. (?)
I assume you have a different kernel config where something is enabled
which includes the pinctrl-stuff in another include which is included
by these
On Thu, Feb 19, 2015 at 12:06:49PM -0600, Felipe Balbi wrote:
If either SCL or SDA are stuck low, we need to
recover the bus using the procedure described
on section 3.1.16 of the I2C specification.
Note that we're trying to implement the procedure
exactly as described by that section.
On Wed, Mar 11, 2015 at 03:47:53PM +0200, Grygorii Strashko wrote:
Hi Felipe,
On 03/11/2015 03:50 AM, Felipe Balbi wrote:
On Mon, Mar 09, 2015 at 11:39:17AM -0500, Felipe Balbi wrote:
On Thu, Feb 19, 2015 at 12:06:49PM -0600, Felipe Balbi wrote:
If either SCL or SDA are stuck low, we need
On Wed, Dec 03, 2014 at 06:33:57PM +0400, Alexander Kochetkov wrote:
This pacth series intended for fixing problem reported
by Tony Lindgren t...@atomide.com here[1]
One of first four patched could fix the problem.
Last patch provide event trace so I could resolve problem.
It could be
On Sun, Nov 30, 2014 at 01:00:01AM +0400, Alexander Kochetkov wrote:
The first patch fix i2c-omap driver for omap2420, found by code review and
later reported by Tony Lindgren t...@atomide.com here[1].
Candidate for stable?
The second patch unhide the reson of system lockup.
The patch is
This platform_driver does not need to set an owner, it will be populated by the
driver core.
Signed-off-by: Wolfram Sang w...@the-dreams.de
---
Generated with coccinelle. SmPL file is in the introductory msg. The big
cleanup was pulled in this merge window. This series catches the bits fallen
on
the way :)
Wolfram Sang (28):
ARM: mach-exynos: drop owner assignment from platform_drivers
mips: lantiq: xway: drop owner assignment from platform_drivers
mips: pci: drop owner assignment from platform_drivers
char: ipmi: drop owner assignment from platform_drivers
cpufreq: drop
).
Please let me know if it is OK to take this one into linux-pm.
From my side, yes:
Acked-by: Wolfram Sang w...@the-dreams.de
Might be worth waiting a day for an ack from someone at TI. They usually
keep a good eye on their drivers.
signature.asc
Description: Digital signature
On Tue, Nov 25, 2014 at 02:20:55AM +0400, Alexander Kochetkov wrote:
Commit 903c3859f77f9b0aace551da03267ef7a211dbc4 (i2c: omap: implement
workaround for handling invalid BB-bit values) introduce the error result
in boot test fault on OMAP3530 boards
The patch fix the error (disable i2c bus
On Mon, Nov 24, 2014 at 01:10:23PM -0600, Felipe Balbi wrote:
On Mon, Nov 24, 2014 at 11:08:48AM -0800, Kevin Hilman wrote:
On Sat, Nov 22, 2014 at 11:47 AM, Alexander Kochetkov
al.koc...@gmail.com wrote:
In a multimaster environment, after IP software reset, BB-bit value
doesn't
Can you comment on this ? As of today i2c-based drivers will probe with
DT-based boot if DT's compatible is set to the same id as in struct
i2c_device_id. No i2c driver with of_device_id can autoprobe using OF
ids.
Long standing problem. Last one to tackle this was Lee Jones:
On Fri, Nov 21, 2014 at 10:08:08AM -0600, Felipe Balbi wrote:
On Fri, Nov 21, 2014 at 01:28:43AM +0400, Alexander Kochetkov wrote:
In a multimaster environment, after IP software reset, BB-bit value doesn't
correspond to the current bus state. It may happen what BB-bit will be 0,
while the
On Sat, Nov 22, 2014 at 05:06:10PM +0300, Alexander Kochetkov wrote:
22 нояб. 2014 г., в 16:23, Wolfram Sang w...@the-dreams.de написал(а):
Huh, I can't apply this one? Which kernel version is this based on?
v.3.13-rc8
Wow, that's old. Can you please rebase the series on top of 3.18-rc4
On Sat, Nov 22, 2014 at 11:47:10PM +0400, Alexander Kochetkov wrote:
Here is the patch series intended to improve stability of
i2c-omap driver in the i2c multimaster environments.
Tested on Beagleboard XM C.
For now all fine. No controller timeouts, no data corruptions.
Also impelemented
On Fri, Nov 21, 2014 at 04:16:51AM +0400, Alexander Kochetkov wrote:
commit 6d9939f651419a63e091105663821f9c7d3fec37 (i2c: omap: split out [XR]DR
and [XR]RDY) changed the way how errata i207 (I2C: RDR Flag May Be Incorrectly
Set) get handled. 6d9939f6514 code doesn't correspond to workaround
Guys, I really appreciate you help.
So much testing and review.
I could not have done one.
Thank you!
Well, thank YOU, for your hard work in verifying this controller at
low-level and in corner-cases. This is very much appreciated. Plus, you
have been very responsive to comments. Really good
On Fri, Nov 21, 2014 at 01:28:44AM +0400, Alexander Kochetkov wrote:
Arbitration Lost is a expected situation in a multimaster environment.
IP correctly detect it.
The only reason for reseting IP in the AL case is to be sure to
avoid advisory 1.94 (omap3) and errata i595 (omap4):
I2C: After
Hi,
thanks for the list!
latest, v3 (same as v2, fixed subject line):
https://patchwork.ozlabs.org/patch/412095/
Yes, I have an eye on this one. Only waiting for the test results from
older platforms by Aaro.
Sorry, for making so much noise.
No problem, this is part of the process. Still,
Tested on Beagleboard XM C.
Signed-off-by: Alexander Kochetkov al.koc...@gmail.com
Cc: sta...@vger.kernel.org # v3.7+
This is good, but subject is wrong. That fixes line should not be the
subject, it should be here after Cc :-)
I'll take this as an Ack unless you protest.
On Tue, Nov 18, 2014 at 09:00:58PM +0400, Alexander Kochetkov wrote:
commit 1d7afc95946487945cc7f5019b41255b72224b70 (i2c: omap: ack IRQ in parts)
changed the interrupt handler to complete transfers without clearing
XRDY (AL case) and ARDY (NACK case) flags. XRDY or ARDY interrupts will be
right, Linux doesn't support being the slave. That's also a missing
feature, not a bug.
This is going to change. I sent out RFC patches for slave support [1]
and will send V1 this week. This won't affect your driver, though,
unless you implement the backend into it.
Just to
submit write request to General Call Address. In that case ISR could
not correctly handle RDR (or XRDY, ARDY, or that ever). Thats becase
i2c-omap driver doesn't correctly handle i2c-controller's slave mode.
right, Linux doesn't support being the slave. That's also a missing
feature,
On Fri, Nov 14, 2014 at 10:25:55AM +0100, Marc Kleine-Budde wrote:
On 11/13/2014 05:06 PM, Wolfram Sang wrote:
On Fri, Nov 07, 2014 at 04:49:22PM +0200, Roger Quadros wrote:
AM3352 SoC has 2 DCAN modules. Add compatible id and
raminit driver data for am3352 DCAN.
Signed-off-by: Roger
the mail that I disagreed with the dcan_0/1
compatible-properties of V3. The second parameter to syscon here is much
better!
Acked-by: Wolfram Sang w...@the-dreams.de
signature.asc
Description: Digital signature
On Fri, Nov 07, 2014 at 04:49:22PM +0200, Roger Quadros wrote:
AM3352 SoC has 2 DCAN modules. Add compatible id and
raminit driver data for am3352 DCAN.
Signed-off-by: Roger Quadros rog...@ti.com
Acked-by: Wolfram Sang w...@the-dreams.de
signature.asc
Description: Digital signature
Unfortunately it is 5 ;)
We have display IP related bit in between 3 and 5 :P
What on earth were the HW engineers thinking
Let's test my RNG on the bit-placement of this register :)
...if we just have the instance parameter in the syscon phandle, we have
to put the mapping
Is it OK to create a new platform_data structure for CAN and put the type and
raminit start/stop
bits there?
I'd say yes, don't see a reason not to.
signature.asc
Description: Digital signature
On Tue, Sep 09, 2014 at 05:31:09PM +0300, Roger Quadros wrote:
Some TI SoCs like DRA7 have a RAMINIT register specification
different from the other AMxx SoCs and as expected by the
existing driver.
To add more insanity, this register is shared with other
IPs like DSS, PCIe and PWM.
As just TI is using this out of band RAMINIT mechanism, should it be
ti,syscon or just syscon?
Yes, only TI uses this out-of-band RAMINIT (currently, at least). So, we
need an (optional) way to describe that. However, accessing syscon
registers in general is not TI specific and a generic way
+- ti,raminit-syscon : Handle to system control region that contains
the
+RAMINIT register. If specified, the second memory
resource
+in the reg property must index into the RAMINIT
+register within the syscon region
On Tue, Sep 30, 2014 at 04:22:08PM +0200, Marc Kleine-Budde wrote:
On 09/30/2014 04:19 PM, Wolfram Sang wrote:
As just TI is using this out of band RAMINIT mechanism, should it be
ti,syscon or just syscon?
Yes, only TI uses this out-of-band RAMINIT (currently, at least). So, we
Yes, but syscon_regmap_lookup_by_phandle() doesn't need any support for
additional parameters. Have a look at:
drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
First get the regmap, then the 1st argument is the offset in the regmap,
the 2nd and 3rd could be the bits.
So, for one
diff --git a/drivers/net/ethernet/ti/Makefile
b/drivers/net/ethernet/ti/Makefile
index 9cfaab8152be..5a31c2b322ee 100644
--- a/drivers/net/ethernet/ti/Makefile
+++ b/drivers/net/ethernet/ti/Makefile
@@ -8,5 +8,6 @@ obj-$(CONFIG_TI_DAVINCI_EMAC) += davinci_emac.o
+ mac_addr[5] = (macid_lo 8) 0xff;
+ mac_addr[4] = macid_lo 0xff;
+ mac_addr[3] = (macid_hi 24) 0xff;
+ mac_addr[2] = (macid_hi 16) 0xff;
+ mac_addr[1] = (macid_hi 8) 0xff;
+ mac_addr[0] = macid_hi 0xff;
That looks twisted, but I assume that you tested it
are for am33xx.dtsi to actually enable this feature.
Minor comments, but in general, looks good to me:
Reviewed-by: Wolfram Sang w...@the-dreams.de
Tests on real HW need to wait another 9 days...
signature.asc
Description: Digital signature
On Thu, Jul 10, 2014 at 01:46:20PM +0200, Wolfram Sang wrote:
Some drivers were flagged to remove class based instantiation soon to improve
boot-up time. Originally, I was planning for a longer deprecation time so
users
could switch over to some other kind of instantiation. However
that the behaviour finally
changed now. After another transition period, this flag can go, too.
Signed-off-by: Wolfram Sang w...@the-dreams.de
---
drivers/i2c/busses/i2c-omap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index
Wolfram Sang (16):
i2c: add debug info when class instantiation was dropped
i2c: i2c-at91: Drop class based scanning to improve bootup time
i2c: i2c-bcm2835: Drop class based scanning to improve bootup time
i2c: i2c-bfin-twi: Drop class based scanning to improve bootup time
i2c: i2c-davinci
+ /* Warn that the adapter lost class based instantiation */
+ if (adapter-class == I2C_CLASS_DEPRECATED) {
+ dev_dbg(adapter-dev,
+ This adapter dropped support for I2C classes and
+ won't auto-detect %s devices anymore. If you need
From: Wolfram Sang w...@sang-engineering.com
In the comments, LCD pins 16-23 were numbered in the wrong order.
Fix this and use proper pinmux constants for all entries while we are
Signed-off-by: Wolfram Sang w...@sang-engineering.com
Cc: Benoit Parrot bpar...@ti.com
---
arch/arm/boot/dts
The same mistake is also in my EVMSK LCD enabling patch that is floating
around on this list at the moment. I will fix that and resend it.
BeagleBone Black only uses the first 16 LCD pins so the dts for that is
correct.
Well, even in the TI-based-3.2-kernel I originally got with the custom
determined to offer the
lowest power solution vs leaving the pins configured in LCD
mode.
Signed-off-by: Darren Etheridge detheri...@ti.com
In general:
Acked-by: Wolfram Sang w...@sang-engineering.com
+ lcd_pins_sleep: lcd_pins_sleep {
+ pinctrl-single,pins
I also get this message printed for the d_can driver with am335x; they
have two entries in drivers/clk/ti/clk-33xx.c. Probably as a workaround
to match the desired clock name for the d_can driver? Didn't really
investigate yet.
That's pretty weird. I wonder where the second fck
...@suse.de
[wsa: ported to top-of-tree]
Signed-off-by: Wolfram Sang w...@sang-engineering.com
What devices and hwmods cause this warning on AM335x? Ideally, there
should only be one hwmod per device. Usually when multiple hwmods are
stacked up for a device, it means that something isn't
On Wed, Apr 09, 2014 at 04:06:48PM +0530, Sourav Poddar wrote:
I2c core supports defualt probing functionality for devices not registered
through
dt/board files. If there are any client driver registered, i2c core will try
to
check if there is any device present corresponding to the address
Wrong documentation in pinmux description can be especially confusing.
Keep it proper.
Signed-off-by: Wolfram Sang w...@the-dreams.de
---
arch/arm/boot/dts/am335x-evm.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts
On Mon, Feb 10, 2014 at 11:03:54AM +0100, Wolfram Sang wrote:
With I2C, class based instantiation means if a master driver has e.g.
I2C_CLASS_HWMON set, all slave drivers with this class will try to probe a
device using an array of possible addresses and some heuristics. That creates
traffic
: ported to top-of-tree]
Signed-off-by: Wolfram Sang w...@sang-engineering.com
---
Digged this out from the net and think this makes sense. I am going to use it
with an AM335x based board. Based on v3.14-rc8.
arch/arm/mach-omap2/omap_device.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions
On Thu, Mar 27, 2014 at 11:18:33AM -0500, Nishanth Menon wrote:
we use IS_ERR_VALUE to check for error values of pm_runtime_get_sync,
when the value can only be 0 in the case of err. Replace the
check with a simpler 0 check.
This fixes the coccicheck warnings:
Warn users that class based instantiation is going away soon in favour
of more robust probing and faster bootup times.
Signed-off-by: Wolfram Sang w...@the-dreams.de
Cc: Jean Delvare kh...@linux-fr.org
---
drivers/i2c/busses/i2c-omap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
adding the new DEPRECATED flag.
The series can also be found here:
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/deprecated_class
Thanks,
Wolfram
Wolfram Sang (17):
Documentation: i2c: describe devicetree method for instantiating
devices
i2c: add deprecation
devm_ioremap_resource does sanity checks on the given resource. No need to
duplicate this in the driver.
Signed-off-by: Wolfram Sang w...@the-dreams.de
---
Should go via subsystem tree
drivers/usb/dwc3/dwc3-omap.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3
@@ -1142,7 +1142,7 @@ omap_i2c_probe(struct platform_device *pdev)
* Also since the omap_i2c_read_reg uses reg_map_ip_* a
* raw_readw is done.
*/
- rev = __raw_readw(dev-base + 0x04);
+ rev = readw_relaxed(dev-base + 0x04);
dev-scheme =
When building a kernel without OMAP3 support but only AM335x, we can't
activate the needed MTD_NAND_OMAP_BCH symbol.
Signed-off-by: Wolfram Sang w...@the-dreams.de
---
Actually, I wonder if this is fix will scale. Maybe someone with more insight
about TI SoCs could find a better expression
A similar patch has been already merged and you can pick it from l2-mtd
next branch:
http://git.infradead.org/l2-mtd.git/commitdiff/1900cdf03057030497e967614c4b19296b6ac460
Great, thanks!
signature.asc
Description: Digital signature
On Thu, Nov 14, 2013 at 03:08:42PM -0800, Tony Lindgren wrote:
Looks like we're missing two lines needed to make it
work properly with device tree.
Cc: linux-...@vger.kernel.org
Cc: Aaro Koskinen aaro.koski...@iki.fi
Cc: Wolfram Sang w...@the-dreams.de
Signed-off-by: Tony Lindgren t
script as --cc-cmd with git:
#! /bin/sh
#
# cocci_cc - send cover letter to all mailing lists referenced in a patch series
# done by Wolfram Sang in 2012 - WTFPLv2
name=${1##*/}
num=${name%%-*}
if [ $num = ]; then
dir=${1%/*}
for f in $dir/*; do
patchname=${f
On Wed, Nov 13, 2013 at 06:35:33PM -0800, Tony Lindgren wrote:
As we claim to support device tree for mach-omap2, we
should have the necessary flags in the driver to make it
usable.
Cc: Wolfram Sang w...@the-dreams.de
Cc: linux-...@vger.kernel.org
Signed-off-by: Tony Lindgren t
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 linus.wall...@linaro.org (personally at LCE13)
Signed-off-by: Wolfram Sang w...@the-dreams.de
---
drivers/mmc/host
The core does this automatically, no need to do this explicitly in drivers.
Those patchces should go via the respective subtrees. Thanks!
Wolfram Sang (4):
drivers/gpu/drm/tilcdc: don't use devm_pinctrl_get_select_default() in
probe
drivers/mmc/host: don't use
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
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
On Thu, Aug 22, 2013 at 06:00:14PM +0200, Wolfram Sang wrote:
I2C of helpers used to live in of_i2c.c but experience (from SPI) shows
that it is much cleaner to have this in the core. This also removes a
circular dependency between the helpers and the core, and so we can
finally register child
. So, fix the drivers and documentation, too.
Acked-by: Rob Herring rob.herr...@calxeda.com
Reviewed-by: Felipe Balbi ba...@ti.com
Acked-by: Rafael J. Wysocki rafael.j.wyso...@intel.com
Tested-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Wolfram Sang w...@the-dreams.de
---
V2-V3
. So, fix the drivers and documentation, too.
Acked-by: Sylwester Nawrocki s.nawro...@amsung.com
Acked-by: Rob Herring rob.herr...@calxeda.com
Reviewed-by: Felipe Balbi ba...@ti.com
Acked-by: Rafael J. Wysocki rafael.j.wyso...@intel.com
Signed-off-by: Wolfram Sang w...@the-dreams.de
---
V1 - V2
Hi,
Which means your original patch starts to make a lot more sense. I
wonder is this is really what we should be doing though - breaking out
of the loop, I mean.
Yup, that is fine. I applied the old patch with Acks from Hein and
Felipe to -next. Thanks!
It looks like TI's i2c-davinci
On Mon, Aug 19, 2013 at 08:57:02AM -0500, Felipe Balbi wrote:
On Mon, Aug 19, 2013 at 02:11:23PM +0200, Wolfram Sang wrote:
Hi,
Which means your original patch starts to make a lot more sense. I
wonder is this is really what we should be doing though - breaking out
of the loop, I
. So, fix the drivers and documentation, too.
Signed-off-by: Wolfram Sang w...@the-dreams.de
---
Sigh, hitting the CC threshold on vger again. So resending to the lists only.
BTW this patch is based on -rc4 and was tested on an AT91 board. More tests
very welcome. Thanks!
Documentation/acpi
However this patch fails to apply onto either v3.11-rc4 or v3.11-rc6:
Argh, did not drop the MPC patch before rebasing :( So either pick the
patch i2c: powermac: fix return path on error before, pull the branch
[1], or force me to resend ;)
Thanks!
[1]
On Mon, Aug 19, 2013 at 09:46:04PM +0200, Thierry Reding wrote:
On Mon, Aug 19, 2013 at 07:59:40PM +0200, Wolfram Sang wrote:
[...]
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
[...]
+#if IS_ENABLED(CONFIG_OF)
+static void of_i2c_register_devices(struct i2c_adapter *adap
On Wed, Jul 10, 2013 at 04:57:37PM +0100, Wolfram Sang wrote:
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 linus.wall...@linaro.org (personally at LCE13
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 linus.wall...@linaro.org (personally at LCE13)
Signed-off-by: Wolfram Sang w...@the-dreams.de
---
drivers/mmc/host
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 linus.wall...@linaro.org (personally at LCE13)
Signed-off-by: Wolfram Sang w...@the-dreams.de
---
drivers/i2c
Hi,
Sorry, for delayed reply - I've had problems with my e-mail.
You still have. This message has unwanted linebreaks.
I've tested this patch on our TI K3.4 product kernel with additional
change below:
Thanks.
[0.662567] (null): This adapter will soon drop class based
instantiation
On Mon, Jun 03, 2013 at 10:37:20AM +0300, Oleksandr Dmytryshyn wrote:
We've been lucky not to have any interrupts fire during the suspend
path, otherwise we would have unpredictable behaviour in the kernel.
Based on the logic of the kernel code interrupts from i2c should be
prohibited during
On Fri, Jun 07, 2013 at 11:09:26AM +0200, Wolfram Sang wrote:
Class based instantiation can cause huge delays when booting. This
mechanism was used when it was not possible to describe slaves on I2C
busses. We now have other mechanisms, so most embedded I2C will not need
classes
On Mon, Jun 03, 2013 at 10:37:20AM +0300, Oleksandr Dmytryshyn wrote:
We've been lucky not to have any interrupts fire during the suspend
path, otherwise we would have unpredictable behaviour in the kernel.
Based on the logic of the kernel code interrupts from i2c should be
prohibited during
3) Thinking about Mainline: To reach the same target - no I2C
detection - and taking
into account above assumption No changes in default behavior
the following will need to be done:
- change i2c-omap/i2c-gpio DT bindings and add parameter which will
allow to change
.class value for
for drivers who want to disable class based in the
near future to gain boot-up time, so users relying on this technique can
switch to something better. They really should.
Signed-off-by: Wolfram Sang w...@the-dreams.de
---
drivers/i2c/busses/i2c-omap.c |2 +-
drivers/i2c/i2c-core.c|6
That sounds good to me - I can prepare patch for i2c-omap.c.
But, there is still an open question regarding *i2c-gpio.c* which,
actually, a source of biggest part of delay.
Why should the DEPRECATED flag not work with i2c-gpio?
signature.asc
Description: Digital signature
The similar patch already exists:
https://patchwork.kernel.org/patch/2448251/ - [v2,1/2] RTC: rtc-twl:
Fix rtc_reg_map initialization
from Peter Ujfalusi
So, I think it is best if you resend this patch after all the fixes it
needs are applied or you resend the series with all patches it
On Tue, Jun 04, 2013 at 08:33:42PM +0300, Grygorii Strashko wrote:
Currently the I2C devices instantiation Method 3 Probe an I2C bus for
certain devices (see Documentation/i2c/instantiating-devices) is always
enabled for all platforms (boards) and can't be disabled.
Not true. Set .class = 0
The comment already got copypasted around and is not really useful.
Remove it.
Signed-off-by: Wolfram Sang w...@the-dreams.de
---
drivers/i2c/busses/i2c-davinci.c|1 -
drivers/i2c/busses/i2c-designware-platdrv.c |1 -
drivers/i2c/busses/i2c-omap.c |1 -
3
devm_ioremap_resource does sanity checks on the given resource. No need to
duplicate this in the driver.
Signed-off-by: Wolfram Sang w...@the-dreams.de
---
drivers/video/omap2/dss/hdmi.c |4
1 file changed, 4 deletions(-)
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video
devm_ioremap_resource does sanity checks on the given resource. No need to
duplicate this in the driver.
Signed-off-by: Wolfram Sang w...@the-dreams.de
---
drivers/video/omap2/vrfb.c |5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/video/omap2/vrfb.c b/drivers/video/omap2
devm_ioremap_resource does sanity checks on the given resource. No need to
duplicate this in the driver.
Signed-off-by: Wolfram Sang w...@the-dreams.de
---
arch/arm/plat-omap/dmtimer.c |7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b
1 - 100 of 171 matches
Mail list logo
