On Mon, Nov 30, 2015 at 11:47 PM, Christophe Ricard
wrote:
> When a gpio is used as an interrupt, the irq_type was not available for
> device driver. It is not align with devicetree probing.
>
> Signed-off-by: Christophe Ricard
Acked-by: Linus Walleij
Rafael you can merge this i
trl) == -EPROBE_DEFER) {
This is one of the evils of deferred probe: you never know if
something will eventually turn up. It feels wrong to bail out
on deferred probe...
I have no better idea though.
Acked-by
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe l
On Thu, Oct 1, 2015 at 1:20 PM, Andy Shevchenko
wrote:
> This patch adds a support of the expandes found on Intel Galileo Gen2 board.
> The platform information comes from ACPI.
>
> Signed-off-by: Andy Shevchenko
Patch applied.
Yours,
Linus Walleij
--
To unsubscribe from this li
On Thu, Oct 1, 2015 at 1:20 PM, Andy Shevchenko
wrote:
> Instead of using id->driver_data directly we copied it to the internal
> structure. This will help to adapt driver for ACPI use.
>
> Signed-off-by: Andy Shevchenko
Patch applied.
Yours,
Linus Walleij
--
To unsubscribe
Is this correct?
In that case I will apply them.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Sep 22, 2015 at 3:10 AM, Andy Shevchenko
wrote:
> This patch adds a support of the expandes found on Intel Galileo Gen2 board.
> The platform information comes from ACPI.
>
> Signed-off-by: Andy Shevchenko
Paging Gregory, Grygorii, Graeme on this patch too.
Yours,
Linus W
ewing these
PCA patches for ACPI support?
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Sep 17, 2015 at 6:36 PM, Luis de Bethencourt
wrote:
> This platform driver has a OF device ID table but the OF module
> alias information is not created so module autoloading won't work.
>
> Signed-off-by: Luis de Bethencourt
Acked-by: Linus Walleij
Yours,
Li
hing extraordinary
after all.
I guess this means that you're using GPIO orthogonally to I2C,
and thus the pin controller does not have the .strict property
set. There should be a comment in the struct pinmux_ops of
the driver saying that this pin controller cannot be used as
strict. Ne
ed a separate pinctrl set
> for bitbanging instead of relying on the sleep state being the right
> thing to enable gpio functionality.
This sounds right but I need to see the two different code sets
to understand. Now my head is all fuzzy...
Yours,
Linus Walleij
--
To unsubscribe from this l
IO mode" in the data sheet
is irrelevant, because it is obviously not used for the generic
input/output but the specific I2C. The terminology should be
made familiar to whoever needs to go in and read the code later.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
is, state
and future directions. Wolfram is known to care deeply about the
problem with DT contracts.
> All in all, it's not impossible for another OS to work with the DT
> information that begins its life in Linux, but it's not really easy.
Let's maker this better.
Yours,
s that you
assume we know what hardware we will boot on at compile time. We
discarded that development path years ago. We have no clue, this
is resolved at runtime. Alas, people still create super-optimized
systems using exactly this knowledge, but it is not our main target
here, it is a special op
On Thu, Jun 11, 2015 at 6:40 PM, Alexander Holler wrote:
> Am 11.06.2015 um 14:30 schrieb Linus Walleij:
>> Certainly it is possible to create deadlocks in this scenario, but the
>> scope is not to create an ubreakable system.
>
> IAnd what happens if you run into a d
On Thu, Jun 11, 2015 at 12:17 PM, Alexander Holler wrote:
> Am 11.06.2015 um 10:12 schrieb Linus Walleij:
>> On Wed, Jun 10, 2015 at 10:28 AM, Alexander Holler
>> wrote:
>>> You would end up with the same problem of deadlocks as currently, and you
>>> would s
On Wed, Jun 10, 2015 at 12:19 PM, Tomeu Vizoso
wrote:
> On 10 June 2015 at 09:30, Linus Walleij wrote:
>> regulator_get(...) -> not available, so:
>> - identify target regulator provider - this will need instrumentation
>> - probe it
>>
>> It then turns ou
On Wed, Jun 10, 2015 at 10:28 AM, Alexander Holler wrote:
> Am 10.06.2015 um 09:30 schrieb Linus Walleij:
>> i2c host comes out, probes the regulator driver, regulator driver
>> probes and then the regulator_get() call returns.
>>
>> This requires instrumentation on an
On Tue, Jun 2, 2015 at 12:14 PM, Tomeu Vizoso
wrote:
> On 2 June 2015 at 10:48, Linus Walleij wrote:
>> This is what systemd is doing in userspace for starting services:
>> ask for your dependencies and wait for them if they are not
>> there. So drivers ask for resources
/* stop signal */
> + gpio_direction_output(pins_scl, 1);
> + udelay(5);
> + gpio_direction_output(pins_sda, 1);
> + udelay(5);
> +
> + gpio_free(pins_scl);
> + gpio_free(pins_sda);
gpiod_put(scl);
gpiod_put(sda);
> +err_out:
>
pts (!) and DMA channels for example.)
So if this should be solved it should be solved in an abstract way
in the device driver core available for all, then have calls calling
out to DT, ACPI, possibly even PCI or USB (as these
enumerate devices themselves) to obtain a certain
dependency.
Yo
uire
Acked-by: Linus Walleij
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, Feb 8, 2015 at 1:34 PM, Nicholas Mc Guire wrote:
> return type of read_i2c() is int not u32. As the assignments to status
> are consistent with int here its type is changed to int.
>
> Signed-off-by: Nicholas Mc Guire
Acked-by: Linus Walleij
Yours,
Linus Walleij
--
To
> +
> + buf = kzalloc(CY_DEVICE_CONFIG_SIZE, GFP_KERNEL);
> + if (buf == NULL)
> + return -ENOMEM;
> +
> + ret = cy_get_device_config(cyusbs, buf);
> + if (ret) {
> + dev_err(&cyusbs->usb_dev->dev,
> +
this can go through MFD alone from the GPIO side
of things.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ection 2.9 for the GPIO
> module commands and responses.
>
> [1] https://www.diolan.com/downloads/dln-api-manual.pdf
>
> Signed-off-by: Daniel Baluta
> Signed-off-by: Octavian Purdila
Looks good to me.
Acked-by: Linus Walleij
Yours,
Linus Walleij
--
To unsubscribe from this list: sen
On Thu, Oct 9, 2014 at 9:22 PM, Octavian Purdila
wrote:
> Some GPIO chips (e.g. the DLN2 USB adapter) have blocking get/set
> operation but do not need a threaded irq handler.
>
> Signed-off-by: Octavian Purdila
This is already upstream now. Rebase and you can drop this patch.
ry
> functionality in the 1st version ?
When you post a driver to the GPIO maintainers it is *NOT* tageted
at a consumer device, it is targeted at the kernel community and
upstream maintainers.
Of course you can deliver add-on patches out-of-tree to your
customers, it's generally a bad idea for the long term and maintenance
of your driver, but it's your pick.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
s, but
this seems very useful, so patch applied. I guess your driver will
appear on v3.19+ so then you can rely on this having been merged
for v3.18.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel
ection 2.9 for the GPIO
> module commands and responses.
>
> [1] https://www.diolan.com/downloads/dln-api-manual.pdf
>
> Signed-off-by: Daniel Baluta
> Signed-off-by: Octavian Purdila
I like this version. I assume you need to funnel it with the
rest of the patches through the MFD
B_IRQCHIP or grep the git
log to see how this works in practice.
You need to use some container_of() operations.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
emoval. Keep
> the
> DEPRECATED flag, so the core can inform users that the behaviour finally
> changed now. After another transition period, this flag can go, too.
>
> Signed-off-by: Wolfram Sang
Acked-by: Linus Walleij
Yours,
Linus Walleij
--
To unsubscribe from this list: send
> Signed-off-by: Wolfram Sang
Acked-by: Linus Walleij
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Jun 4, 2014 at 8:09 AM, Michael Lawnick wrote:
> Am 03.06.2014 13:18, schrieb Linus Walleij:
>> On Mon, Jun 2, 2014 at 4:29 PM, Michael Lawnick wrote:
>>>
>>> Am 02.06.2014 14:16, schrieb Linus Walleij:
>>
>>
>>>> Is this really so us
s
> make[3]: *** [drivers/i2c/muxes/i2c-mux-pca954x.o] Error 1
I've sent a patch for this to Wolfram and the i2c discuss list.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
explicit dependency.
Reported-by: Jim Davis
Signed-off-by: Linus Walleij
---
drivers/i2c/muxes/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/i2c/muxes/Kconfig b/drivers/i2c/muxes/Kconfig
index f7f9865b8b89..f6d313e528de 100644
--- a/drivers/i2c/muxes/Kconfig
+++ b/driver
a "reset-gpios" property and the driver that requests a "reset-gpio"
> property.
>
> Signed-off-by: Laurent Pinchart
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to
On Mon, Jun 2, 2014 at 4:29 PM, Michael Lawnick wrote:
> Am 02.06.2014 14:16, schrieb Linus Walleij:
>> Is this really so useful on embedded systems?
>>
>> I was under the impression that this method was something used
>> on say PC desktops with temperature monitors
a way forward then I guess... but passing a compatible
string to that same file is a bit arbitrarily ambigous. So we'd rather
add a new instatiation file named new_device_of_compatible or so?
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe l
tems?
I was under the impression that this method was something used
on say PC desktops with temperature monitors and EEPROMs
on some I2C link on the PCB, usage entirely optional and fun
for userspace hacks.
And when we say "people use it" do we mean "sensors-detect
uses it,
On Wed, May 7, 2014 at 6:29 AM, Jingoo Han wrote:
> The site-specific OOM messages are unnecessary, because they
> duplicate the MM subsystem generic OOM message.
>
> Signed-off-by: Jingoo Han
Acked-by: Linus Walleij
Yours,
Linus Walleij
--
To unsubscribe from this list: s
On Tue, May 6, 2014 at 11:32 AM, Ulf Hansson wrote:
> On 10 April 2014 16:19, Ulf Hansson wrote:
>> devm_ioremap() returns NULL on error, not an error.
>>
>> Cc: Alessandro Rubini
>> Cc: Linus Walleij
>> Signed-off-by: Ulf Hansson
>
> Linus, Wolfram -
ring system suspend, and thus when
> a transfer occurs during the early phases of system suspend the device
> will be kept active after the transfer.
>
> To handle both issues above, use pm_runtime_force_suspend|resume() from
> the system suspend|resume callbacks.
>
> Cc: Alessandr
On Mon, Feb 24, 2014 at 10:13 AM, Wolfram Sang wrote:
> On Mon, Feb 24, 2014 at 09:57:05AM +0100, Linus Walleij wrote:
>> I can easily fix that up ipso facto by modifying the device trees to
>> state 400kHz for them.
>
> Then lets do it this way.
After a check I see th
ons of the PL18x, as it depends on exploiting properties
on an assumed pin controller.
Systems that don't have such wakeup features on their pins are
unlikely to support deepsleep in any capacity, and if they do they are
ill-designed from the top level as this needs to be taken into account
w
hink this is done like this because all devices on all Nomadik variants
out there (Nomadik, Ux500) support 400kHz.
Buit change it if you prefer, nothing will break, it will just get slower :-)
I can easily fix that up ipso facto by modifying the device trees to
state 400kHz for them.
Yours,
Linus W
On Mon, Feb 3, 2014 at 11:27 AM, Linus Walleij wrote:
> Move the former platform data struct nmk_i2c_controller into the
> per-device state container struct i2c_nmk_client, and remove all
> the platform data probe path hacks.
>
> Cc: Lee Jones
> Signed-off-by: Linus Walleij
On Mon, Feb 10, 2014 at 11:04 AM, Wolfram Sang wrote:
> 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
> Cc: Alessandro Rubini
> Cc: Linus Walleij
> ---
>
>
On Mon, Feb 10, 2014 at 11:04 AM, Wolfram Sang wrote:
> 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
> Cc: Linus Walleij
> ---
>
> This patch is a suggestio
em
> handle the resources accordingly, including the clock.
>
> Cc: Alessandro Rubini
> Cc: Linus Walleij
> Cc: Wolfram Sang
> Signed-off-by: Ulf Hansson
Hm do I read it right as patch 13 breaks runtime PM by leaving
the device active after probe() and this patch
14 fixes
On Tue, Feb 4, 2014 at 4:58 PM, Ulf Hansson wrote:
> Use devm_* functions to simplify code and error handling.
>
> Cc: Alessandro Rubini
> Cc: Linus Walleij
> Cc: Wolfram Sang
> Signed-off-by: Ulf Hansson
Acked-by: Linus Walleij
However make sure this (and the rest) appl
On Tue, Feb 4, 2014 at 4:58 PM, Ulf Hansson wrote:
> The driver core is now taking care of putting our pins into default
> state at probe. Thus we can remove the redundant call for it in probe.
>
> Cc: Mark Brown
> Signed-off-by: Ulf Hansson
Acked-by: Linus Walleij
Yours
depend on
> PM_RUNTIME for platforms like this.
Isn't the typical Android platform using PM_SLEEP without using
PM_RUNTIME?
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordo
Move the former platform data struct nmk_i2c_controller into the
per-device state container struct i2c_nmk_client, and remove all
the platform data probe path hacks.
Cc: Lee Jones
Signed-off-by: Linus Walleij
---
ChangeLog v1->v2:
- Drop pointless check for np, as the device can only probe f
On Tue, Jan 21, 2014 at 3:55 AM, Alexandre Courbot wrote:
> On Sat, Jan 18, 2014 at 7:43 AM, Linus Walleij
> wrote:
>> 1. Today this OPEN_DRAIN flag is not even passed down to
>> the driver so how could it say anything about it :-( it's a pure gpiolib
>> intern
her with
such GPIO flag details) so is it better if we add a special call to
figure out if the input can be read? Like:
bool gpiod_input_always_valid(const struct gpio_desc *desc);
And leave it up to the core to look at flags, driver characteristics
etc and determine whether the input can be trusted?
Yo
;ll fix.
> Rest is looking good.
Does this mean that you applied patch 1/3 and 2/3?
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, Dec 14, 2013 at 1:20 AM, Linus Walleij wrote:
> On Thu, Nov 28, 2013 at 11:12 PM, Linus Walleij
> wrote:
>
>> Move the former platform data struct nmk_i2c_controller into the
>> per-device state container struct i2c_nmk_client, and remove all
>> the pla
On Sat, Dec 14, 2013 at 1:19 AM, Linus Walleij wrote:
> On Thu, Nov 28, 2013 at 11:11 PM, Linus Walleij
> wrote:
>
>> The Nomadik I2C controller needs to have the slave set-up time
>> configured based off the clock used to drive the I2C bus block.
>> Current
On Sat, Dec 14, 2013 at 1:19 AM, Linus Walleij wrote:
> On Thu, Nov 28, 2013 at 11:12 PM, Linus Walleij
> wrote:
>
>> The Nomadik I2C is now configured from the device tree on all platforms
>> using this controller. Delete the platform data header and move the
>> def
On Thu, Nov 28, 2013 at 11:12 PM, Linus Walleij
wrote:
> Move the former platform data struct nmk_i2c_controller into the
> per-device state container struct i2c_nmk_client, and remove all
> the platform data probe path hacks.
>
> Cc: Lee Jones
> Signed-off-by: Linus Walleij
On Thu, Nov 28, 2013 at 11:12 PM, Linus Walleij
wrote:
> The Nomadik I2C is now configured from the device tree on all platforms
> using this controller. Delete the platform data header and move the
> definitions into the driver so it is all contained in one single file.
>
>
On Thu, Nov 28, 2013 at 11:11 PM, Linus Walleij
wrote:
> The Nomadik I2C controller needs to have the slave set-up time
> configured based off the clock used to drive the I2C bus block.
> Currently this is done with static assignments assuming that the
> block is clocked 48MHz whi
Move the former platform data struct nmk_i2c_controller into the
per-device state container struct i2c_nmk_client, and remove all
the platform data probe path hacks.
Cc: Lee Jones
Signed-off-by: Linus Walleij
---
drivers/i2c/busses/i2c-nomadik.c | 116 +++
1
The Nomadik I2C is now configured from the device tree on all platforms
using this controller. Delete the platform data header and move the
definitions into the driver so it is all contained in one single file.
Cc: Lee Jones
Signed-off-by: Linus Walleij
---
drivers/i2c/busses/i2c-nomadik.c
in the datasheet
instead.
Cc: Lee Jones
Signed-off-by: Linus Walleij
---
drivers/i2c/busses/i2c-nomadik.c | 40 +--
include/linux/platform_data/i2c-nomadik.h | 5
2 files changed, 28 insertions(+), 17 deletions(-)
diff --git a/drivers/i2c/busses/i2c
o have that, so the
> devices it supports won't get lost in a deferred probe.
>
> Signed-off-by: Wolfram Sang
> Cc: Linus Walleij
Acked-by: Linus Walleij
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a messa
te to do all the
> conversions just to have it NAKed at the last minute.
With the direction we've discussed here atleast I won't be
doing any NACKing if it's of any help...
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the
On Mon, Sep 23, 2013 at 10:29 PM, Thierry Reding
wrote:
> On Mon, Sep 23, 2013 at 09:14:30PM +0200, Linus Walleij wrote:
>> I think it is better to first go over the call sites and make them
>> all handle negative return numbers rather than pushing the
>> obscure __interface
ard to spot, so we should keep an eye out for this
once this probing scheme is in place.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
k it's
really nasty.
Usually this is reserved for compiler- and linker related things,
like __packed; or __init.
I would prefer irq_of_parse_and_map_strict() or something
like that.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the b
se_and_map instead as they just
> pass in a NULL resource.
I second this comment.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
wrapper.
I second this and also don't want the first patch to use a wrapper.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ew archs+subsystems and it's just plain work.
So do that first.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
=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 h
x27;m happy to patch it if it disturbs anything, it is
*really* not important for this driver.
Do you guys need a low footprint? Else there is no
use to have platform_driver_probe() in there.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
ol drivers
and when they probe, and dependencies trying to take
a pinctrl handle before the pin controller is available
will be deferred. Even by those grabbed in the core
by drivers/base/pinctrl.c.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c&q
)
Acked-by: Linus Walleij
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
t Wolfram (the i2c maintainer) on the To: line.
> Tuomas Tynkkynen (2):
> mfd: tps65910: Fix crash in i2c_driver .probe
> regulator: tps62360: Fix crash in i2c_driver .probe
Nice :-)
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c&quo
On Tue, Jun 18, 2013 at 9:33 AM, Wolfram Sang wrote:
> On Mon, Jun 17, 2013 at 11:15:30PM +0100, Grant Likely wrote:
>> On Mon, Jun 17, 2013 at 5:33 PM, Linus Walleij
>> wrote:
>> > OK that works for me, I'm not in any hurry.
>>
>> Deferring by a mer
ld give enough time for everyone to get
> a heads-up on fixing any drivers with a similar problem, rather than
> trying to cram all that in immediately before the merge window.
OK that works for me, I'm not in any hurry.
Wolfram get to decide how to handle this...
Yours,
Linus Wallei
semantic effect on systems with only Nomadik I2C blocks
will be none - instead of increasing the number atomically
in the driver itself, it is done in the I2C core.
Signed-off-by: Linus Walleij
---
ChangeLog v1->v2:
- Drop the default assignment if -1 to adap->nt as we're now
using i2c_
ended up with ideas like
decorating the device tree representation and it was just ...
ouch.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
mments on this...
I cannot really see how it could be any different given
the way the FDT works :-/
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
semantic effect on systems with only Nomadik I2C blocks
will be none - instead of increasing the number atomically
in the driver itself, it is done in the I2C core.
Signed-off-by: Linus Walleij
---
drivers/i2c/busses/i2c-nomadik.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions
variant data in the same
manner as other PrimeCells, and switch code path depending
on version.
Tested on the S8815 Nomadik dongle.
Signed-off-by: Linus Walleij
---
drivers/i2c/busses/i2c-nomadik.c | 43 ++--
1 file changed, 41 insertions(+), 2 deletions(-)
diff
tates, but you may see even further...
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, May 22, 2013 at 9:56 AM, Linus Walleij wrote:
> On Mon, May 13, 2013 at 10:18 PM, Linus Walleij
> wrote:
>
>> This tries to address an issue found when writing an MFD driver
>> for the Nomadik STw481x PMICs: as the platform is using device
>> tree exclusively I
On Mon, May 13, 2013 at 10:18 PM, Linus Walleij
wrote:
> This tries to address an issue found when writing an MFD driver
> for the Nomadik STw481x PMICs: as the platform is using device
> tree exclusively I want to specify the driver matching like
> this:
(...)
> ---
> ChangeL
iver names as is
done in multiple cases today.
Cc: Rob Herring
Cc: Grant Likely
Signed-off-by: Linus Walleij
---
ChangeLog v1->v2:
- Use of_match_device() to determine if there is a DT match in
the probe code. If there is a match we pass NULL for the
id_table match parameter.
--
matching */
+ status = driver->probe(client, NULL);
+ else
+ /* Fall back to matching the id_table */
+ status = driver->probe(client,
i2c_match_id(driver->id_table, client));
If the device has an of_node it surely should not be using the
id_table and
iver names as is
done in multiple cases today.
Cc: Rob Herring
Cc: Grant Likely
Signed-off-by: Linus Walleij
---
I would need some device tree core people to confirm that I am
on the right track with this. I was s confused when I found
that .of_match_table could not be used with I2C devic
ice_data *pld;
>> > + uint16_tmask;
>>
>> Just u16?
>
> The specification allows 16 GPIOs for this device, therefore this seems
> to be the right size. Would it be better to use another type instead?
Ah, I was just asking you to use "u16" instead of
vers/gpio/gpio-kempld.h
(...)
> +struct kempld_gpio_data {
> + struct gpio_chipchip;
> + int irq;
> + struct kempld_device_data *pld;
> + uint16_t mask;
Just u16?
> +};
(...)
> dif
On Tue, Apr 9, 2013 at 6:41 PM, Guenter Roeck wrote:
> On Tue, Apr 09, 2013 at 10:46:15AM +0200, Linus Walleij wrote:
>> On Mon, Apr 8, 2013 at 7:15 PM, Kevin Strasser
>> wrote:
>>
>> > From: Michael Brunner
>> >
>> > Add gpio support for
ing bits in bytesized
registers.
Can you please attempt to use generic GPIO for this?
drivers/gpio/gpio-generic.c
See for example:
gpio-ep93xx.c, gpio-sodaville.c ...
Since you don't even have IRQ support in this it will be even simpler.
Yours,
Linus Walleij
--
To unsubscribe fro
On Wed, Mar 27, 2013 at 11:36 AM, Barry Song <21cn...@gmail.com> wrote:
> 2013/3/27 Linus Walleij :
>> You only need to fetch pinctrl handles in drivers if you're
>> using anything else than the default state.
>
> well. missed this recent commit.
&g
On Mon, Mar 18, 2013 at 8:22 AM, Barry Song wrote:
> From: Barry Song
>
> hardcode set i2c pin group to i2c function before, here we
> move to use standard pinctrl API to get pins of the group.
>
> Signed-off-by: Barry Song
> Cc: Linus Walleij
NAK.
This is done by
also removed.
>
> Signed-off-by: Thomas Abraham
Acked-by: Linus Walleij
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
robably won't
> forget anytime soon.
Hm, maybe I have come across as too harsh and then I feel bad about
that :-(
I really want spare-time contributors, they are often more valueable
in addition to the corporate ones since they provide an outside view
of things.
Yours,
Linus Walleij
--
T
e I ACKed that, then I was doing something stupid.)
> Still, all the platforms relying on the legacy DT GPIO support should have
> been already migrated to pin control, so ideally instead of "fixing" the
> drivers to continue supporting the deprecated method, such platforms
>
1 - 100 of 308 matches
Mail list logo
