decisions, don't try to create
mechanisms that will half-guess things.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
to
do gpio_to_irq() on their pins instead of using the IRQ
directly.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
and
Tony's Tested-by, thanks!
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
is disabled then gpio
events occurring will not be latched/stored.
Signed-off-by: Andreas Fenkart andreas.fenk...@streamunlimited.com
Have to defer this to the next development cycle as no consensus
seem to have been reached with the maintainers of this driver.
Keep going.
Thanks,
Linus Walleij
on this, Loic, Ulf?
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Apr 26, 2013 at 11:25 PM, Jon Hunter jon-hun...@ti.com wrote:
On 04/26/2013 02:27 AM, Linus Walleij wrote:
You will just have to give the xlate function information about which
GPIOs are used as IRQs only, and only request the GPIO on these.
That should not be necessary. The xlate
be sending that fix upstream?
It fell out because of the other debacle during the merge window.
I'm more than overloaded (due to the ever increasing development pace
of the kernel I guess) so queueing fixes takes some time.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line
with null phandler.
Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com
Cc: Balaji T K balaj...@ti.com
Cc: Chris Ball c...@laptop.org
Cc: linux-...@vger.kernel.org
Cc: linux-omap@vger.kernel.org
This is perfectly correct.
Acked-by: Linus Walleij linus.wall...@linaro.org
As the PM code seems
On Tue, Jun 4, 2013 at 9:11 AM, Linus Walleij linus.wall...@linaro.org wrote:
On Fri, May 31, 2013 at 12:13 PM, Hebbar Gururaja
gururaja.heb...@ti.com wrote:
Amend the hsmmc controller to optionally take a pin control handle and
set the state of the pins to:
- default on boot, resume
and
sleep states, but you may see even further...
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Jun 6, 2013 at 10:50 AM, Mark Brown broo...@kernel.org wrote:
On Thu, Jun 06, 2013 at 11:29:39AM +0530, Mugunthan V N wrote:
On 6/6/2013 12:53 AM, Mark Brown wrote:
Linus Walleij posted some patches which factor the state setting code
out into generic functions earlier on today
api in another
series,
this patch has direct usage of pinctrl_select_state apis
http://marc.info/?l=linux-netdevm=137054250018667w=2
Linus Walleij
Please drop this patch series and take my other [atch set mentioned above
with David's Ack.
Sure I didn't see David ACK the new versions
On Thu, Jun 6, 2013 at 8:15 PM, Mugunthan V N mugunthan...@ti.com wrote:
This utilize the new pinctrl core PM helpers to transition
the driver to default and sleep states.
Signed-off-by: Mugunthan V N mugunthan...@ti.com
This version of the patch applied with DaveM:s ACK.
Yours,
Linus
On Thu, Jun 6, 2013 at 8:15 PM, Mugunthan V N mugunthan...@ti.com wrote:
This utilize the new pinctrl core PM helpers to transition
the driver to default and sleep states.
Signed-off-by: Mugunthan V N mugunthan...@ti.com
This version of the patch applied with DaveM:s ACK.
Yours,
Linus
to default (as this is the defined semantic
meaning of default from linux/pinctrl/pinctrl-state.h.
But maybe I'm not quite getting the subtle difference between
default and active here so enlighten me.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap
default
and active are the same thing. But it seems we need to
add your granularity to this.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
On Tue, Jun 11, 2013 at 11:25 PM, Grant Likely
grant.lik...@secretlab.ca wrote:
On Fri, 26 Apr 2013 16:31:24 -0500, Jon Hunter jon-hun...@ti.com wrote:
On 04/26/2013 02:31 AM, Linus Walleij wrote:
On Wed, Apr 17, 2013 at 2:41 AM, Javier Martinez Canillas
martinez.jav...@gmail.com wrote
be poked at
by the regulator world, not the pinctrl world. That the bits are
in the middle of pinctrl things does not really matter.
+ usleep_range(350, 400);
And the regulator framework supports power-on delays.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe
On Wed, Jun 12, 2013 at 4:37 PM, Tony Lindgren t...@atomide.com wrote:
Linus W may have some comments on this, although this is not the standard
muxing stuff.
It's in the wrong subsystem and needs to be rewritten IMO.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line
On Thu, Jun 13, 2013 at 11:53 AM, Tony Lindgren t...@atomide.com wrote:
* Linus Walleij linus.wall...@linaro.org [130613 02:42]:
On Thu, Jun 6, 2013 at 9:14 PM, Balaji T K balaj...@ti.com wrote:
+ /* 100ms delay required for PBIAS configuration */
+ msleep(100
* that is connected to a
pad becomes part of the pinctrl subsystem, then pinctrl-single
becomes some kind of hardware abstraction or BIOS, and that
is *not* the intent. It is only supposed to deal with the bits
there that are 100% related to what pinctrl does, nothing else.
Yours,
Linus Walleij
]
static void omap_gpio_init_context(struct gpio_bank *p) {}
^
The solution is to mark the stub function as 'static inline' so
it gets left out of the build when unused.
Signed-off-by: Arnd Bergmann a...@arndb.de
Patch applied with Tony's and Santosh's ACKs.
Yours,
Linus Walleij
the chip was just reset.
Explain what happens if you do *not* leave it as zero and what the
bits mean in that case.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
;
+
+ pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
This memory is never freed, is it?
Why should it, given it's allocated with devres?
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More
On Mon, Jun 17, 2013 at 1:46 PM, Archit Taneja arc...@ti.com wrote:
On Monday 17 June 2013 02:35 PM, Linus Walleij wrote:
Just a query, there is an example in gpio.txt in the gpio
bindings documentation which sets #gpio-cells as 1. Is this is a wrong
example, or are 1 cell gpio controllers
are trying to figure out the details of whether active
is necessary or not in a related thread I think.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
are just defining states to make nice figures or mental
maps and that is not helpful for drivers writers.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
with fuzzing :-(
Can you rebase them?
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
to Torvalds.
That will probably not work as it would cause even more conflicts
upstream, and now the merge window is open so no way can I
rebase the tree either.
Let's see if we can cram it in as part of a late v3.11 merge or
if we'll have to defer to v3.12.
Yours,
Linus Walleij
--
To unsubscribe
On Mon, Jul 1, 2013 at 1:01 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
On 01/07/2013, at 10:04, Linus Walleij linus.wall...@linaro.org wrote:
Let's see if we can cram it in as part of a late v3.11 merge or
if we'll have to defer to v3.12.
Ok no worries. Since
, and a second that includes the v3.10 merge and the OMAP
patches.
The first is already done :-D
I'll queue the OMAP stuff on a branch based off v3.10 sharp and
put into -next right now so we can propose it for fixes or as a
second pull request during the merge window.
Yours,
Linus Walleij
() and
forget
to do a built test for OMAP1.
Such things happen ...
I hope this patch can go as a fix for the v3.11-rc cycle.
Yeah I queued it on top of the others. Good thing I didn't rush the
other two out :-)
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux
. (And a point to object and suggest other ways
to do the same thing...)
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
convention and will not accept the active state.
Now it's time for patches :-)
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Jul 12, 2013 at 1:30 PM, Peter Ujfalusi peter.ujfal...@ti.com wrote:
TWL6040 is used only with OMAP4/5 SoCs and they can only boot in in DT mode.
The support for pdata/legacy boot can be removed.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
OK patch applied.
Yours,
Linus
need to
use gpio_request() in driver.
Please ask questions like this on the mailing lists and include
the OMAP GPIO maintainers (Santosh Kevin).
And the answer is yes, all GPIO lines you are using need to
be requested by the driver.
Yours,
Linus Walleij
--
To unsubscribe from this list: send
over northern Europe...
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
on ARM reference hardware
which is also multiplexing DMA signals. In that case we have done
platform-specific hooks and implemented this in the per-machine
platform code.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord
?
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
to you?
OK but I still need to look closer at them as well, so no guarantee
I will pull it...
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
On Fri, Jul 12, 2013 at 5:36 PM, Grygorii Strashko
grygorii.stras...@ti.com wrote:
On 07/10/2013 11:36 PM, Linus Walleij wrote:
I guess we need a patch set prepared which adds the active state
and helper function as the first patch, i.e. this:
http://marc.info/?l=linux-kernelm
we'd have to
establish keeping these commits immutable.
I see some issues with these patches ...
I will go back and review them.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info
() then that the irqchip portions of the GPIO drivers
can call down to so the pinctrl driver sets this bit if need be?
I think this needs some more thought, especially the latter
concern.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord
);
+ void (*disable)(const struct pcs_soc *soc, struct pcs_reg *r);
Then these quirks and sub-modules ...
Why can't the irqchip/GPIO driver call down to this driver
instead?
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord
, it will be routed up if and only
if it has been flagged as a wakeup from the irqchip layer.
The cross reference can be stored in struct pin_desc.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More
[] = {
+ { .compatible = ti,omap3-padconf, },
+ { .compatible = ti,omap4-padconf, },
+ { .compatible = ti,omap5-padconf, },
+ {}
+};
Goes into some binding document?
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body
...@wwwdotorg.org
Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
Aha that is how to do it. Stephen complained about it earlier
but I couldn't come up with a good enough refactoring.
Patch applied.
Yours,
Linus Walleij
--
To unsubscribe from
;
struct device *dev;
struct list_head states;
- struct pinctrl_state *state;
+ struct pinctrl_state *state[PINCTRL_NR_STATES];
struct list_head dt_maps;
struct kref users;
};
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe
configurations
can be an intrinsic detail of the pinctrl subsystem, by adding flags and
members to private structs like struct pinctrl itself in worst case.
So I'm not buying into this, it looks like it is making things complicated
for consumers outside the subsystem for no reason.
Yours,
Linus
am pretty convinced that if this dynamic muxing stuff shall be
implemented, it should be a pinctrl subsystem intrinsic optimization
detail and should not be exposed to the outside with all these extra
functions at all. It looks overly complicated to me.
Yours,
Linus Walleij
--
To unsubscribe from
...
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
is what is worst: having these three patches
there or reverting them?
Or should I simply revert *all* the TI GPIO stuff merged for v3.11
now that is seems like this is a can of worms? :-/
Tony, Kevin, Santosh, someone? What will make all happy?
Yours,
Linus Walleij
--
To unsubscribe from this list
On Sun, Jul 28, 2013 at 2:59 PM, Alexander Holler hol...@ahsoftware.de wrote:
Am 28.07.2013 13:14, schrieb Linus Walleij:
What shall we do with this mess now?
(...)
Hmm, maybe something which adds a mapping for a IRQ when gpio_to_irq()
is called would help.
I think this bug is pointing back
.
But the latter should be checked.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
drivers.
If things are working for the default DTS files in the
kernel then I am OK with it.
However moving forward to support the cases that
Alexander is highlighting, I really really thin we need
to put the information about taken GPIOs input-hogs
into the gpio DT node.
Yours,
Linus Walleij
On Sun, Jul 28, 2013 at 6:45 PM, Alexander Holler hol...@ahsoftware.de wrote:
Am 28.07.2013 18:25, schrieb Linus Walleij:
On Sun, Jul 28, 2013 at 4:25 PM, Alexander Holler hol...@ahsoftware.de
wrote:
By the way, if someone decides to touch omap_hsmmc, the driver wrongly
assumes that 0
answers to how they want to
proceed with this, and the issue with gpio_to_irq() *is* complex
so we shall indeed discuss it. Better to have the discussion
now and not when it gets deployed in a million systems.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap
:-)
I wish we already had the DTS schema parser and checks
in place. In that case I could just ask if the DTS is well-formed,
and you could say yes or no, and if it was no, it's just an
invalid DTS file.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap
into the core with a flag to enable the behaviour.
Signed-off-by: Mark Brown broo...@linaro.org
Acked-by: Linus Walleij linus.wall...@linaro.org
+ * @auto_runtime_pm: the core should ensure a runtime PM reference is held
+ * while the hardware is prepared
I'd mention here
On Sun, Jul 28, 2013 at 4:43 PM, Mark Brown broo...@kernel.org wrote:
From: Mark Brown broo...@linaro.org
Signed-off-by: Mark Brown broo...@linaro.org
Reviewed-by: Linus Walleij linus.wall...@linaro.org
Someone moaned about oneline commit messages in
the last LWN...
Yours,
Linus Walleij
-request on the GPIO lines that
will be used as IRQs only.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
, and this is because we should
use the if (!irq) design pattern and not if (irq == NO_IRQ).
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
-controller/irq.h
interrupt-parent = gpio6;
interrupts = 16 IRQ_TYPE_LEVEL_LOW;
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
drafting an RFC to indicate how I think this should
be solved.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
references to the GPIO
based interrupt-controller, and request each of these lines as
GPIO (i.e. hog them) in the gpiolib OF core.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info
PLAGNIOL-VILLARD plagn...@jcrosoft.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Kevin Hilman khil...@linaro.org
Cc: Balaji T K balaj...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Jon Hunter jgchun...@gmail.com
Signed-off-by: Linus Walleij linus.wall...@linaro.org
---
drivers/gpio/gpiolib
On Mon, Jul 29, 2013 at 2:40 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
On 29/07/2013, at 13:43, Linus Walleij linus.wall...@linaro.org wrote:
So I'm drafting an RFC to indicate how I think this should
be solved.
Great, I hope we can finally have a good solution
On Tue, Jul 30, 2013 at 6:30 AM, Grant Likely grant.lik...@linaro.org wrote:
On Mon, Jul 29, 2013 at 6:36 AM, Linus Walleij linus.wall...@linaro.org
wrote:
To solve this dilemma, perform an interrupt consistency check
when adding a GPIO chip: if the chip is both gpio-controller and
interrupt
to the driver -free() and -request()
callback pair.
or:
the pinctrl-single.c driver in it's callbacks like -enable()
-disable(), -request(), -free() internally short cuts from
its knowledge of such pin shortcuts and no other drivers
are affected (nor helped) by this optimization.
Yours,
Linus
simple crossbar
for reuse across subsystems.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Aug 15, 2013 at 10:26 PM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
On Thursday 15 August 2013 04:01 PM, Linus Walleij wrote:
On Tue, Aug 13, 2013 at 11:56 AM, Sricharan R r.sricha...@ti.com wrote:
Initially irqchip was discussed, but we also have a DMA crossbar
to map
when the code was restructured
a bit.
Kevin?
Yes, looks like a copy/paste error. The comma should simply be replaced
by a semi-colon.
So can I have a patch for this? Pretty please...
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body
there is the right patch, sorry for the noise.
Patch applied with Kevin's ACK.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Aug 15, 2013 at 11:14 PM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
On Thursday 15 August 2013 04:51 PM, Linus Walleij wrote:
(...)
Sorry I don't understand what thread that is... can you point me there?
My previous statement on this issue what this:
http://marc.info/?l=linux
On Tue, Aug 20, 2013 at 12:04 AM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
On Wednesday 31 July 2013 01:44:53 Linus Walleij wrote:
I don't see how sharing works here, or how another user, i.e. another one
than the user wanting to recieve the IRQ, can validly request
in a comment. From datasheet?
+ /* Reseting GDD */
+ __raw_writel(SSI_SWRESET, omap_ssi-gdd + SSI_GDD_GRST_REG);
+ /* Get FCK rate */
+ omap_ssi-fck_rate = ssi_get_clk_rate(ssi) / 1000; /* KHz */
DIV_ROUND_CLOSEST()? Or is this an integer divider?
Yours,
Linus Walleij
.
+1 on this.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
(i.e cross-bar IRQ line).
This will be the driver input as a IRQ line from DT. The cross-bar
driver needs to map any of the free list available on *request* only.
Right, the mapping can be done on request. That will be cleaner.
I like where this design is going now :-)
Yours,
Linus Walleij
in a follow
up patch
- n_latch description updated
The devicetree portions of this patch needs to be reviewed by
devicet...@vger.kernel.org, so please repost including that
list.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message
of whether an IRQ is mapped
or not.
Maybe Grant should have a look at this.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Aug 29, 2013 at 4:11 PM, George Cherian george.cher...@ti.com wrote:
On 8/29/2013 6:27 PM, Linus Walleij wrote:
int irq;/* real irq number */
+ int irq_mapped; /* mapped gpio irqs */
This seems like an u32
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
-off-by: Linus Walleij linus.wall...@linaro.org
---
arch/arm/mach-omap2/id.c | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 2dc62a2..fc03cc6 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -18,6
Reviewed-by: Kevin Hilman khil...@linaro.org
Signed-off-by: Linus Walleij linus.wall...@linaro.org
---
ChangeLog v1-v2:
- Use omap_device_initcall() to avoid calling on non-OMAPs.
---
arch/arm/mach-omap2/id.c | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/mach-omap2/id.c b/arch
due to the initialization of the nonblocking pool being
constant.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
to finalize his DT bindings on top
of your patches instead.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
with any explanation of why would it hang...
Bouncing the question to George, Laurent and Kuninori...
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
pin to line in the DT bindings documentation
- Renamed pins-initial-states DT property to lines-initial-states
I can't see any problem with this so patch applied.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord
and that it needs to be *fixed* at some point.
But in either case I want this to be tested on OMAP1 before
I apply it, as in a Tested-by tag.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More
if you coordinate with the ARM SoC folks:
Acked-by: Linus Walleij linus.wall...@linaro.org for these two.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
to wait until 3.13?
I've added it to my fixes branch for v3.12. Since linux-next is not available we
need some extensive build testing first to make sure that if something explodes
it explodes on OMAP only.
So will let this boil a few days and then send a pull request.
Yours,
Linus Walleij
the beginning but I was dead wrong, as pointed out
by tglx it is basically a hardware .map function, so its usecase will map
to the irqdomain .map/.unmap so to say.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord
, but let's discuss that
in the context of that patch.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
at the large picture here, for all of them.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Oct 7, 2013 at 7:35 PM, Tony Lindgren t...@atomide.com wrote:
Hi Linus W,
Any comments on the pinctrl patches 3 - 5 in this series?
Yes, after good explanations to my whimsical questions only this:
Acked-by: Linus Walleij linus.wall...@linaro.org
I guess you'll take these patches
_reconfigure_io_chain().
As an innocent bystander who has no clue what the _reconfigure_io_chain()
is about can you tell me what this is all about?
Is this another one of the OMAP forked paths where you must call back into
the machine with a special callback from each and every driver?
Yours,
Linus
On Thu, Oct 10, 2013 at 4:35 PM, Roger Quadros rog...@ti.com wrote:
On 10/10/2013 05:04 PM, Linus Walleij wrote:
As an innocent bystander who has no clue what the _reconfigure_io_chain()
is about can you tell me what this is all about?
The OMAP SoC has a mechanism to monitor and wakeup from
not collide ... especially if you want to do some of my
suggested follow-up moving the ioring handling down into
pinctrl-single on top of that.
I can also do a test merge with pinctrl/for-next also to make
sure there are no conflicts.
Sure, as long as that works you should be safe.
Yours,
Linus
-up interrupts continuously running on omap3 instead of just idle
modes.
If the rearm() function is calling this _reconfigure_io_chain my comments
on the fact that this is something that should be handled by the pin
control driver still apply I think
Yours,
Linus Walleij
--
To unsubscribe
201 - 300 of 426 matches
Mail list logo
