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 fro
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
> ("i2
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 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 initialis
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 sh
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 // silico
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 encoded
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
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 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 reas
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 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
sur
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 t
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 j
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 dat
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
c
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" sid
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
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
> th
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
th
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 t
> >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 belie
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 until
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 patc
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 p
> 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 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 tha
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 th
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
> 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 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 ("A
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 8214fd238
35 matches
Mail list logo
