Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/plat-omap/i2c.c between commit 49839dc93970 ("Revert "ARM: OMAP:
convert I2C driver to PM QoS for MPU latency constraints"") from the
i2c-embedded tree and various commits from the arm-soc tree.
I used the version
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/plat-omap/i2c.c between commit 49839dc93970 (Revert ARM: OMAP:
convert I2C driver to PM QoS for MPU latency constraints) from the
i2c-embedded tree and various commits from the arm-soc tree.
I used the version from
Hi Stephen,
On Thu, Sep 13, 2012 at 04:41:20PM +1000, Stephen Rothwell wrote:
> Today's linux-next merge of the arm-soc tree got a conflict in
> drivers/i2c/busses/i2c-omap.c between commit d9ebd04d3476 ("i2c: omap:
> switch to devm_* API") from the i2c-embedded tree and commit 07baca6f8fc2
>
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in
drivers/i2c/busses/i2c-omap.c between commit d9ebd04d3476 ("i2c: omap:
switch to devm_* API") from the i2c-embedded tree and commit 07baca6f8fc2
("i2c/i2c-omap: add a const qualifier") from the arm-soc tree.
I fixed it up
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in
drivers/i2c/busses/i2c-omap.c between commit d9ebd04d3476 (i2c: omap:
switch to devm_* API) from the i2c-embedded tree and commit 07baca6f8fc2
(i2c/i2c-omap: add a const qualifier) from the arm-soc tree.
I fixed it up (see
Hi Stephen,
On Thu, Sep 13, 2012 at 04:41:20PM +1000, Stephen Rothwell wrote:
Today's linux-next merge of the arm-soc tree got a conflict in
drivers/i2c/busses/i2c-omap.c between commit d9ebd04d3476 (i2c: omap:
switch to devm_* API) from the i2c-embedded tree and commit 07baca6f8fc2
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in
drivers/i2c/busses/i2c-nomadik.c between commit 235602146ec9
("i2c-nomadik: turn the platform driver to an amba driver") from the
i2c-embedded tree and commit 98582d9562b4 ("ARM: ux500: Remove unused i2c
platform_data
On 18/07/12 12:12, Mark Brown wrote:
On Wed, Jul 18, 2012 at 08:35:21AM +0100, Lee Jones wrote:
Fix your mailer to word wrap within paragraphs. I've reformatted your
mail for legibility.
Does it always do that, or was it just this time? It's setup to
word-wrap, for instance this paragraph
On Wed, Jul 18, 2012 at 08:35:21AM +0100, Lee Jones wrote:
Fix your mailer to word wrap within paragraphs. I've reformatted your
mail for legibility.
> I agree, but in this instance it really does stand to reason.
> 1. No unified bindings currently exist.
> 2. I don't have time to create them.
On 18/07/12 11:33, Mark Brown wrote:
On Wed, Jul 18, 2012 at 11:29:26AM +0100, Lee Jones wrote:
On 18/07/12 10:59, Mark Brown wrote:
It's not the using device tree bit that creates concern for me here,
it's the fact that the board and silicon aren't being separated.
What's the difference?
On Wed, Jul 18, 2012 at 11:29:26AM +0100, Lee Jones wrote:
> On 18/07/12 10:59, Mark Brown wrote:
> >It's not the using device tree bit that creates concern for me here,
> >it's the fact that the board and silicon aren't being separated.
> What's the difference?
> >+- db8500.dtsi //
On 18/07/12 10:59, Mark Brown wrote:
On Wed, Jul 18, 2012 at 01:33:42PM +0800, Shawn Guo wrote:
I have an IP block getting different FIFO size on different IMX SoCs.
We could introduce a new compatible string for driver to figure it out,
but I think the simpler way is just have the data
On Wed, Jul 18, 2012 at 01:33:42PM +0800, Shawn Guo wrote:
> I have an IP block getting different FIFO size on different IMX SoCs.
> We could introduce a new compatible string for driver to figure it out,
> but I think the simpler way is just have the data encoded in device
> tree. In any case
On 17/07/12 16:20, Mark Brown wrote:
> On Tue, Jul 17, 2012 at 03:52:10PM +0100, Lee Jones wrote:
>
>> I think it would be okay to take the 3 patches due for the v3.6
>> merge window, which target the nmk-i2c driver. If any consolidation
>> happens in the mean-time/future I will personally do the
On 17/07/12 16:20, Mark Brown wrote:
On Tue, Jul 17, 2012 at 03:52:10PM +0100, Lee Jones wrote:
I think it would be okay to take the 3 patches due for the v3.6
merge window, which target the nmk-i2c driver. If any consolidation
happens in the mean-time/future I will personally do the work to
On Wed, Jul 18, 2012 at 01:33:42PM +0800, Shawn Guo wrote:
I have an IP block getting different FIFO size on different IMX SoCs.
We could introduce a new compatible string for driver to figure it out,
but I think the simpler way is just have the data encoded in device
tree. In any case DT is
On 18/07/12 10:59, Mark Brown wrote:
On Wed, Jul 18, 2012 at 01:33:42PM +0800, Shawn Guo wrote:
I have an IP block getting different FIFO size on different IMX SoCs.
We could introduce a new compatible string for driver to figure it out,
but I think the simpler way is just have the data
On Wed, Jul 18, 2012 at 11:29:26AM +0100, Lee Jones wrote:
On 18/07/12 10:59, Mark Brown wrote:
It's not the using device tree bit that creates concern for me here,
it's the fact that the board and silicon aren't being separated.
What's the difference?
+- db8500.dtsi // silicon
\
On 18/07/12 11:33, Mark Brown wrote:
On Wed, Jul 18, 2012 at 11:29:26AM +0100, Lee Jones wrote:
On 18/07/12 10:59, Mark Brown wrote:
It's not the using device tree bit that creates concern for me here,
it's the fact that the board and silicon aren't being separated.
What's the difference?
On Wed, Jul 18, 2012 at 08:35:21AM +0100, Lee Jones wrote:
Fix your mailer to word wrap within paragraphs. I've reformatted your
mail for legibility.
I agree, but in this instance it really does stand to reason.
1. No unified bindings currently exist.
2. I don't have time to create them.
On 18/07/12 12:12, Mark Brown wrote:
On Wed, Jul 18, 2012 at 08:35:21AM +0100, Lee Jones wrote:
Fix your mailer to word wrap within paragraphs. I've reformatted your
mail for legibility.
Does it always do that, or was it just this time? It's setup to
word-wrap, for instance this paragraph
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in
drivers/i2c/busses/i2c-nomadik.c between commit 235602146ec9
(i2c-nomadik: turn the platform driver to an amba driver) from the
i2c-embedded tree and commit 98582d9562b4 (ARM: ux500: Remove unused i2c
platform_data
On Tue, Jul 17, 2012 at 04:20:01PM +0100, Mark Brown wrote:
> Looking at what's specified in the platform data in the current kernel
> it seems like there's a mixture of things in there that are board and
> silicon specific. We've got parameters like the the speed mode and
> timeout which are
On Tue, Jul 17, 2012 at 03:52:10PM +0100, Lee Jones wrote:
> I think it would be okay to take the 3 patches due for the v3.6
> merge window, which target the nmk-i2c driver. If any consolidation
> happens in the mean-time/future I will personally do the work to
> bring the nmk-i2c into line to
On 17/07/12 15:22, Mark Brown wrote:
On Tue, Jul 17, 2012 at 03:02:00PM +0100, Lee Jones wrote:
I'm sure sure this is relevant in the current case though, as the
i2c properties proposed here are platform specific. What we're
I've not seen the specific example (though fankly it seems quite
On Tue, Jul 17, 2012 at 03:02:00PM +0100, Lee Jones wrote:
> I'm sure sure this is relevant in the current case though, as the
> i2c properties proposed here are platform specific. What we're
I've not seen the specific example (though fankly it seems quite
surprising that there's anything other
On 17/07/12 14:35, Mark Brown wrote:
On Tue, Jul 17, 2012 at 02:30:01PM +0100, Lee Jones wrote:
On 17/07/12 14:06, Mark Brown wrote:
It's not just about having generic bindings, it's also about having
bindings which have some abstraction and hope of reusability. An awful
lot of bindings are
On Tue, Jul 17, 2012 at 02:30:01PM +0100, Lee Jones wrote:
> On 17/07/12 14:06, Mark Brown wrote:
> >It's not just about having generic bindings, it's also about having
> >bindings which have some abstraction and hope of reusability. An awful
> >lot of bindings are just straight dumps of Linux
On 17/07/12 14:06, Mark Brown wrote:
On Mon, Jul 16, 2012 at 12:31:08PM +0100, Lee Jones wrote:
I agree with what you say to some extent, but I believe that it is
more important to have a working solution now than to ensure that
each bindings are as unique as possible. After any suggestion of
On Mon, Jul 16, 2012 at 02:35:50PM +0200, Wolfram Sang wrote:
> I do know both sides. I easily agree that we have to find a balance
> somewhere to meet both interests. Though, currently my impressions from
> maintaining I2C are:
> a) it is not balanced, but too far on the "let's deploy stuff"
On Mon, Jul 16, 2012 at 12:31:08PM +0100, Lee Jones wrote:
> I agree with what you say to some extent, but I believe that it is
> more important to have a working solution now than to ensure that
> each bindings are as unique as possible. After any suggestion of
> consolidation, a move from
On Mon, Jul 16, 2012 at 12:31:08PM +0100, Lee Jones wrote:
I agree with what you say to some extent, but I believe that it is
more important to have a working solution now than to ensure that
each bindings are as unique as possible. After any suggestion of
consolidation, a move from vendor
On Mon, Jul 16, 2012 at 02:35:50PM +0200, Wolfram Sang wrote:
I do know both sides. I easily agree that we have to find a balance
somewhere to meet both interests. Though, currently my impressions from
maintaining I2C are:
a) it is not balanced, but too far on the let's deploy stuff side
b)
On 17/07/12 14:06, Mark Brown wrote:
On Mon, Jul 16, 2012 at 12:31:08PM +0100, Lee Jones wrote:
I agree with what you say to some extent, but I believe that it is
more important to have a working solution now than to ensure that
each bindings are as unique as possible. After any suggestion of
On Tue, Jul 17, 2012 at 02:30:01PM +0100, Lee Jones wrote:
On 17/07/12 14:06, Mark Brown wrote:
It's not just about having generic bindings, it's also about having
bindings which have some abstraction and hope of reusability. An awful
lot of bindings are just straight dumps of Linux data
On 17/07/12 14:35, Mark Brown wrote:
On Tue, Jul 17, 2012 at 02:30:01PM +0100, Lee Jones wrote:
On 17/07/12 14:06, Mark Brown wrote:
It's not just about having generic bindings, it's also about having
bindings which have some abstraction and hope of reusability. An awful
lot of bindings are
On Tue, Jul 17, 2012 at 03:02:00PM +0100, Lee Jones wrote:
I'm sure sure this is relevant in the current case though, as the
i2c properties proposed here are platform specific. What we're
I've not seen the specific example (though fankly it seems quite
surprising that there's anything other
On 17/07/12 15:22, Mark Brown wrote:
On Tue, Jul 17, 2012 at 03:02:00PM +0100, Lee Jones wrote:
I'm sure sure this is relevant in the current case though, as the
i2c properties proposed here are platform specific. What we're
I've not seen the specific example (though fankly it seems quite
On Tue, Jul 17, 2012 at 03:52:10PM +0100, Lee Jones wrote:
I think it would be okay to take the 3 patches due for the v3.6
merge window, which target the nmk-i2c driver. If any consolidation
happens in the mean-time/future I will personally do the work to
bring the nmk-i2c into line to use
On Tue, Jul 17, 2012 at 04:20:01PM +0100, Mark Brown wrote:
Looking at what's specified in the platform data in the current kernel
it seems like there's a mixture of things in there that are board and
silicon specific. We've got parameters like the the speed mode and
timeout which are
Hi,
On Mon, Jul 16 2012, Linus Walleij wrote:
>> Uhm, I seem to have missed that bindings are deemed more "flexible" as
>> long as they are coupled to in-kernel dts files? Is that discussed
>> somewhere? I do wonder about it...
>
> Well patches like this are sent out but not commented on from
>
On Mon, Jul 16, 2012 at 2:35 PM, Wolfram Sang wrote:
> Uhm, I seem to have missed that bindings are deemed more "flexible" as
> long as they are coupled to in-kernel dts files? Is that discussed
> somewhere? I do wonder about it...
Well patches like this are sent out but not commented on from
On 16/07/12 14:00, Wolfram Sang wrote:
What I am afraid of is: tentative solutions tend to stay, because the
need for a proper solution is reduced. Yet, finding proper generic
bindings might take some time which doesn't meet the high pressure
around DT at the moment.
I agree with what you say
> >What I am afraid of is: tentative solutions tend to stay, because the
> >need for a proper solution is reduced. Yet, finding proper generic
> >bindings might take some time which doesn't meet the high pressure
> >around DT at the moment.
>
> I agree with what you say to some extent, but I
On Mon, Jul 16, 2012 at 01:37:13PM +0200, Linus Walleij wrote:
> On Mon, Jul 16, 2012 at 12:17 PM, Wolfram Sang wrote:
>
> >> And about the perpetual nature of device tree bindings it
> >> appears to me that the modus operandi right now is to not
> >> regard any of these as written in stone
On Mon, Jul 16, 2012 at 12:17 PM, Wolfram Sang wrote:
>> And about the perpetual nature of device tree bindings it
>> appears to me that the modus operandi right now is to not
>> regard any of these as written in stone until they are removed
>> from the kernel tree. We have plenty of drivers
On 16/07/12 11:17, Wolfram Sang wrote:
Well I think I ACKed that from the point of view that it will work as
expected with ux500 with these bindings. What is best from the I2C
subsystem point of view is another question ...
Okay, thanks for clarifying.
Overall I think we have this general
> Well I think I ACKed that from the point of view that it will work as
> expected with ux500 with these bindings. What is best from the I2C
> subsystem point of view is another question ...
Okay, thanks for clarifying.
> Overall I think we have this general problem with a lot of DT
>
Well I think I ACKed that from the point of view that it will work as
expected with ux500 with these bindings. What is best from the I2C
subsystem point of view is another question ...
Okay, thanks for clarifying.
Overall I think we have this general problem with a lot of DT
conversion
On 16/07/12 11:17, Wolfram Sang wrote:
Well I think I ACKed that from the point of view that it will work as
expected with ux500 with these bindings. What is best from the I2C
subsystem point of view is another question ...
Okay, thanks for clarifying.
Overall I think we have this general
On Mon, Jul 16, 2012 at 12:17 PM, Wolfram Sang w.s...@pengutronix.de wrote:
And about the perpetual nature of device tree bindings it
appears to me that the modus operandi right now is to not
regard any of these as written in stone until they are removed
from the kernel tree. We have plenty
On Mon, Jul 16, 2012 at 01:37:13PM +0200, Linus Walleij wrote:
On Mon, Jul 16, 2012 at 12:17 PM, Wolfram Sang w.s...@pengutronix.de wrote:
And about the perpetual nature of device tree bindings it
appears to me that the modus operandi right now is to not
regard any of these as written in
What I am afraid of is: tentative solutions tend to stay, because the
need for a proper solution is reduced. Yet, finding proper generic
bindings might take some time which doesn't meet the high pressure
around DT at the moment.
I agree with what you say to some extent, but I believe that
On 16/07/12 14:00, Wolfram Sang wrote:
What I am afraid of is: tentative solutions tend to stay, because the
need for a proper solution is reduced. Yet, finding proper generic
bindings might take some time which doesn't meet the high pressure
around DT at the moment.
I agree with what you say
On Mon, Jul 16, 2012 at 2:35 PM, Wolfram Sang w.s...@pengutronix.de wrote:
Uhm, I seem to have missed that bindings are deemed more flexible as
long as they are coupled to in-kernel dts files? Is that discussed
somewhere? I do wonder about it...
Well patches like this are sent out but not
Hi,
On Mon, Jul 16 2012, Linus Walleij wrote:
Uhm, I seem to have missed that bindings are deemed more flexible as
long as they are coupled to in-kernel dts files? Is that discussed
somewhere? I do wonder about it...
Well patches like this are sent out but not commented on from
the
On Thu, Jul 12, 2012 at 3:12 PM, Wolfram Sang wrote:
> Arnd, since you committed the patches, can you please comment? I'd
> prefer to drop this DT conversion for now, otherwise we might have to
> support this possibly rushed bindings forever? LinusW, what do you
> think?
Well I think I ACKed
On Thu, Jul 12, 2012 at 3:12 PM, Wolfram Sang w.s...@pengutronix.de wrote:
Arnd, since you committed the patches, can you please comment? I'd
prefer to drop this DT conversion for now, otherwise we might have to
support this possibly rushed bindings forever? LinusW, what do you
think?
Well I
They look like they mostly export register settings which is usually
questionable since we might want to abstract bindings so they can be
useful for a number of drivers.
I'm not exactly sure what you mean by this. These bindings are specific
to the ST-Ericsson driver and are localised, hence
They look like they mostly export register settings which is usually
questionable since we might want to abstract bindings so they can be
useful for a number of drivers.
I'm not exactly sure what you mean by this. These bindings are specific
to the ST-Ericsson driver and are localised, hence
On Thursday 12 July 2012, Wolfram Sang wrote:
>
> > I fixed it up (I think - see below) and can carry the fix as necessary.
> > Please check this and talk to each other ...
>
> I also noticed the bindings today [1]. They came in via a seperate
> patch (suboptimal) which has no ack by a
> I fixed it up (I think - see below) and can carry the fix as necessary.
> Please check this and talk to each other ...
I also noticed the bindings today [1]. They came in via a seperate
patch (suboptimal) which has no ack by a devicetree maintainer which I'd
really like to see here, because
I fixed it up (I think - see below) and can carry the fix as necessary.
Please check this and talk to each other ...
I also noticed the bindings today [1]. They came in via a seperate
patch (suboptimal) which has no ack by a devicetree maintainer which I'd
really like to see here, because the
On Thursday 12 July 2012, Wolfram Sang wrote:
I fixed it up (I think - see below) and can carry the fix as necessary.
Please check this and talk to each other ...
I also noticed the bindings today [1]. They came in via a seperate
patch (suboptimal) which has no ack by a devicetree
On Tue, Jul 10, 2012 at 04:41:30PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the arm-soc tree got a conflict in
> drivers/i2c/busses/i2c-nomadik.c between commit af97bace2cca
> ("i2c-nomadik: move header to ") from
> the i2c-embedded tree and commits 32e42c687e0a
Hi all,
On Tue, 10 Jul 2012 16:41:30 +1000 Stephen Rothwell
wrote:
>
> Hi all,
>
> Today's linux-next merge of the arm-soc tree got a conflict in
> drivers/i2c/busses/i2c-nomadik.c between commit af97bace2cca
> ("i2c-nomadik: move header to ") from
Also commit 235602146ec9 ("i2c-nomadik: turn
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in
drivers/i2c/busses/i2c-nomadik.c between commit af97bace2cca
("i2c-nomadik: move header to ") from
the i2c-embedded tree and commits 32e42c687e0a ("ARM: ux500: Remove
unused i2c platform_data initialisation code") and
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in
drivers/i2c/busses/i2c-nomadik.c between commit af97bace2cca
(i2c-nomadik: move header to linux/platform_data/i2c-nomadik.h) from
the i2c-embedded tree and commits 32e42c687e0a (ARM: ux500: Remove
unused i2c platform_data
Hi all,
On Tue, 10 Jul 2012 16:41:30 +1000 Stephen Rothwell s...@canb.auug.org.au
wrote:
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in
drivers/i2c/busses/i2c-nomadik.c between commit af97bace2cca
(i2c-nomadik: move header to linux/platform_data/i2c-nomadik.h) from
On Tue, Jul 10, 2012 at 04:41:30PM +1000, Stephen Rothwell wrote:
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in
drivers/i2c/busses/i2c-nomadik.c between commit af97bace2cca
(i2c-nomadik: move header to linux/platform_data/i2c-nomadik.h) from
the i2c-embedded tree
70 matches
Mail list logo
