All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roland Stigge <stigge@antcom.de>
To: Wolfram Sang <w.sang@pengutronix.de>
Cc: srinivas.bakki@nxp.com, vitalywool@gmail.com,
	devicetree-discuss@lists.ozlabs.org,
	linux-kernel@vger.kernel.org, rob.herring@calxeda.com,
	Grant Likely <grant.likely@secretlab.ca>,
	arm@kernel.org, linux-i2c@vger.kernel.org, ben-linux@fluff.org,
	khali@linux-fr.org, kevin.wells@nxp.com,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v4] i2c: Add device tree support to i2c-pnx.c
Date: Thu, 19 Apr 2012 23:18:39 +0200	[thread overview]
Message-ID: <4F90812F.5090106@antcom.de> (raw)
In-Reply-To: <20120419203915.GB28005@pengutronix.de>

Hi!

On 19/04/12 22:39, Wolfram Sang wrote:
>> If we have a solution soon, I will prepare a new version of the 
>> patch, of course, in the next days.
> 
> Thanks. One question, though: Will it really block dt-conversion? 
> The whole conversion should not be depending on the i2c-driver?

Technically, it would certainly be possible to convert some drivers
and leave others. But I would highly prefer to convert i2c also. With
LPC32xx, there are typically many I2C clients depending on DT on a
reasonable DT enabled mach.

I'm fine with "timeout" also, when you accept it into pnx-i2c.c and
will certainly provide a "timeout" patch update so you can pick the
version which suits best.

Another solution would be to not use timeout with the dt enabled
i2c-pnx for now (using the hard coded default timeout as the current
i2c-pnx.c does) and possibly introduce the (anyway optional) "timeout"
later.

Actually, that would be my favour.

What do you think?

>>> Did you change this, too? Timeouts are better readable in dec
>>> :)
>> 
>> Right. But even when removing the "0x" in the timeout line
>> above, it's still hex, see 
>> Documentation/devicetree/booting-without-of.txt
>> 
>> Or did I get sth. wrong?
> 
> I think the document is probably outdated :( "clock-frequency" is 
> also without 0x and dec.

Interesting! When the documentation is outdated - how does the parser
actually decide between hex (e.g. regs/addresses) and dec (e.g.
clock-frequency) in the absence of "0x"?

Thanks in advance,

Roland

WARNING: multiple messages have this Message-ID (diff)
From: stigge@antcom.de (Roland Stigge)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4] i2c: Add device tree support to i2c-pnx.c
Date: Thu, 19 Apr 2012 23:18:39 +0200	[thread overview]
Message-ID: <4F90812F.5090106@antcom.de> (raw)
In-Reply-To: <20120419203915.GB28005@pengutronix.de>

Hi!

On 19/04/12 22:39, Wolfram Sang wrote:
>> If we have a solution soon, I will prepare a new version of the 
>> patch, of course, in the next days.
> 
> Thanks. One question, though: Will it really block dt-conversion? 
> The whole conversion should not be depending on the i2c-driver?

Technically, it would certainly be possible to convert some drivers
and leave others. But I would highly prefer to convert i2c also. With
LPC32xx, there are typically many I2C clients depending on DT on a
reasonable DT enabled mach.

I'm fine with "timeout" also, when you accept it into pnx-i2c.c and
will certainly provide a "timeout" patch update so you can pick the
version which suits best.

Another solution would be to not use timeout with the dt enabled
i2c-pnx for now (using the hard coded default timeout as the current
i2c-pnx.c does) and possibly introduce the (anyway optional) "timeout"
later.

Actually, that would be my favour.

What do you think?

>>> Did you change this, too? Timeouts are better readable in dec
>>> :)
>> 
>> Right. But even when removing the "0x" in the timeout line
>> above, it's still hex, see 
>> Documentation/devicetree/booting-without-of.txt
>> 
>> Or did I get sth. wrong?
> 
> I think the document is probably outdated :( "clock-frequency" is 
> also without 0x and dec.

Interesting! When the documentation is outdated - how does the parser
actually decide between hex (e.g. regs/addresses) and dec (e.g.
clock-frequency) in the absence of "0x"?

Thanks in advance,

Roland

WARNING: multiple messages have this Message-ID (diff)
From: Roland Stigge <stigge@antcom.de>
To: Wolfram Sang <w.sang@pengutronix.de>
Cc: Grant Likely <grant.likely@secretlab.ca>,
	Rob Herring <robherring2@gmail.com>,
	vitalywool@gmail.com, khali@linux-fr.org, ben-linux@fluff.org,
	rob.herring@calxeda.com, linux-i2c@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	devicetree-discuss@lists.ozlabs.org, arm@kernel.org,
	linux-arm-kernel@lists.infradead.org, kevin.wells@nxp.com,
	srinivas.bakki@nxp.com
Subject: Re: [PATCH v4] i2c: Add device tree support to i2c-pnx.c
Date: Thu, 19 Apr 2012 23:18:39 +0200	[thread overview]
Message-ID: <4F90812F.5090106@antcom.de> (raw)
In-Reply-To: <20120419203915.GB28005@pengutronix.de>

Hi!

On 19/04/12 22:39, Wolfram Sang wrote:
>> If we have a solution soon, I will prepare a new version of the 
>> patch, of course, in the next days.
> 
> Thanks. One question, though: Will it really block dt-conversion? 
> The whole conversion should not be depending on the i2c-driver?

Technically, it would certainly be possible to convert some drivers
and leave others. But I would highly prefer to convert i2c also. With
LPC32xx, there are typically many I2C clients depending on DT on a
reasonable DT enabled mach.

I'm fine with "timeout" also, when you accept it into pnx-i2c.c and
will certainly provide a "timeout" patch update so you can pick the
version which suits best.

Another solution would be to not use timeout with the dt enabled
i2c-pnx for now (using the hard coded default timeout as the current
i2c-pnx.c does) and possibly introduce the (anyway optional) "timeout"
later.

Actually, that would be my favour.

What do you think?

>>> Did you change this, too? Timeouts are better readable in dec
>>> :)
>> 
>> Right. But even when removing the "0x" in the timeout line
>> above, it's still hex, see 
>> Documentation/devicetree/booting-without-of.txt
>> 
>> Or did I get sth. wrong?
> 
> I think the document is probably outdated :( "clock-frequency" is 
> also without 0x and dec.

Interesting! When the documentation is outdated - how does the parser
actually decide between hex (e.g. regs/addresses) and dec (e.g.
clock-frequency) in the absence of "0x"?

Thanks in advance,

Roland

  reply	other threads:[~2012-04-19 21:18 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-19 15:50 [PATCH v4] i2c: Add device tree support to i2c-pnx.c Roland Stigge
2012-04-19 15:50 ` Roland Stigge
     [not found] ` <1334850612-24151-1-git-send-email-stigge-uj/7R2tJ6VmzQB+pC5nmwQ@public.gmane.org>
2012-04-19 16:07   ` Wolfram Sang
2012-04-19 16:07     ` Wolfram Sang
2012-04-19 16:07     ` Wolfram Sang
     [not found]     ` <20120419160715.GD24987-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2012-04-19 16:32       ` Roland Stigge
2012-04-19 16:32         ` Roland Stigge
2012-04-19 16:32         ` Roland Stigge
     [not found]         ` <4F903E0C.6010604-uj/7R2tJ6VmzQB+pC5nmwQ@public.gmane.org>
2012-04-19 20:39           ` Wolfram Sang
2012-04-19 20:39             ` Wolfram Sang
2012-04-19 20:39             ` Wolfram Sang
2012-04-19 21:18             ` Roland Stigge [this message]
2012-04-19 21:18               ` Roland Stigge
2012-04-19 21:18               ` Roland Stigge
     [not found]               ` <4F90812F.5090106-uj/7R2tJ6VmzQB+pC5nmwQ@public.gmane.org>
2012-04-20  7:28                 ` Wolfram Sang
2012-04-20  7:28                   ` Wolfram Sang
2012-04-20  7:28                   ` Wolfram Sang
     [not found]                   ` <20120420072811.GA9769-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2012-04-20  7:53                     ` Roland Stigge
2012-04-20  7:53                       ` Roland Stigge
2012-04-20  7:53                       ` Roland Stigge

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F90812F.5090106@antcom.de \
    --to=stigge@antcom.de \
    --cc=arm@kernel.org \
    --cc=ben-linux@fluff.org \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=grant.likely@secretlab.ca \
    --cc=kevin.wells@nxp.com \
    --cc=khali@linux-fr.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rob.herring@calxeda.com \
    --cc=srinivas.bakki@nxp.com \
    --cc=vitalywool@gmail.com \
    --cc=w.sang@pengutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.