linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: grant.likely@secretlab.ca (Grant Likely)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/3] serial/imx: add device tree support
Date: Sun, 19 Jun 2011 12:44:34 -0600	[thread overview]
Message-ID: <BANLkTi=Ur1+FAHd2J_KGZgtuGTHrrtBb_g@mail.gmail.com> (raw)
In-Reply-To: <4DFE129E.1010800@gmail.com>

On Sun, Jun 19, 2011 at 9:15 AM, Rob Herring <robherring2@gmail.com> wrote:
> On 06/19/2011 10:05 AM, Grant Likely wrote:
>> On Sun, Jun 19, 2011 at 1:30 AM, Shawn Guo <shawn.guo@freescale.com> wrote:
>>> On Sat, Jun 18, 2011 at 10:19:34AM -0600, Grant Likely wrote:
>>>> On Sat, Jun 18, 2011 at 11:19:12PM +0800, Shawn Guo wrote:
>>>>> It adds device tree data parsing support for imx tty/serial driver.
>>>>>
>>>>> Signed-off-by: Jeremy Kerr <jeremy.kerr@canonical.com>
>>>>> Signed-off-by: Jason Liu <jason.hui@linaro.org>
>>>>> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
>>>>> Cc: Sascha Hauer <s.hauer@pengutronix.de>
>>>>> ---
>>>>> ?.../bindings/tty/serial/fsl-imx-uart.txt ? ? ? ? ? | ? 21 +++++
>>>>> ?drivers/tty/serial/imx.c ? ? ? ? ? ? ? ? ? ? ? ? ? | ? 81 +++++++++++++++++---
>>>>> ?2 files changed, 92 insertions(+), 10 deletions(-)
>>>>> ?create mode 100644 Documentation/devicetree/bindings/tty/serial/fsl-imx-uart.txt
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/tty/serial/fsl-imx-uart.txt b/Documentation/devicetree/bindings/tty/serial/fsl-imx-uart.txt
>>>>> new file mode 100644
>>>>> index 0000000..7648e17
>>>>> --- /dev/null
>>>>> +++ b/Documentation/devicetree/bindings/tty/serial/fsl-imx-uart.txt
>>>>> @@ -0,0 +1,21 @@
>>>>> +* Freescale i.MX Universal Asynchronous Receiver/Transmitter (UART)
>>>>> +
>>>>> +Required properties:
>>>>> +- compatible : should be "fsl,<soc>-uart", "fsl,imx-uart"
>>>>
>>>> I'd make this "fsl,<soc>-uart", "fsl,imx51-uart"
>>>>
>>>> It's better to anchor these things on real silicon, or a real ip block
>>>> specification rather than something pseudo-generic. ?Subsequent chips,
>>>> like the imx53, should simply claim compatibility with the older
>>>> fsl,imx51-uart.
>>>
>>> It is a real IP block on all imx silicons (except imx23 and imx28
>>> which are known as former stmp).
>>>
>>>>
>>>> (in essence, "fsl,imx51-uart" becomes the generic string without the
>>>> downside of having no obvious recourse when new silicon shows up that
>>>> is an imx part, but isn't compatible with the imx51 uart.
>>>>
>>> In this case, should imx1 the ancestor of imx family than imx51
>>> becomes part of that generic string? ?Claiming uart of imx1, imx21
>>> and imx31 (senior than imx51) compatible with the imx51 uart seems
>>> odd to me.
>>>
>>> That said, IMO, "fsl,imx-uart" stands a real IP block specification
>>> here and can be a perfect generic compatibility string to tell the
>>> recourse of any imx silicon using this IP.
>>
>> Yes, but which /version/ of the IP block? ?Hardware designers are
>> notorious for changing hardware designs for newer silicon, sometimes
>> to add features, sometimes to fix bugs. ?While I understand the
>> temptation to boil a compatible value down to a nice clean generic
>> string, doing so only works in a perfect world. ?In the real world,
>> you still need to have some information about the specific
>> implementation. ?I prefer this specifying it to the SoC name, but I've
>> been known to be convinced that specifying it to the ip-block name &
>> version in certain circumstances, like for IP blocks in an FPGA, or
>> some of the Freescale powerpc pXXXX SoCs which actually had an IP
>> block swapped out midway through the life of the chip.
>>
>
> There are definitely uart changes along the way with each generation.
>
>> Besides, encoding an soc or ip block version into the 'generic'
>> compatible values is not just good practice, it has *zero downside*.
>> That's the beauty of the compatible property semantics. ?Any node can
>> claim compatibility with an existing device. ?If no existing device
>> fits correctly, then the node simple does not claim compatibility.
>> Drivers can bind to any number of compatible strings, so it would be
>> just fine for the of_match_table list to include both "fsl,imx-21" and
>> "fsl,imx-51" (assuming that is the appropriate solution in this case).
>>
>
> Don't you need uart or serial in here somewhere.

you are of course correct.  The examples should be "fsl,imx21-uart" &
"fsl,imx51-uart".  I was just writing too quickly.

g.

  reply	other threads:[~2011-06-19 18:44 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-18 15:19 [PATCH 0/3] Add basic device support for imx51 babbage Shawn Guo
2011-06-18 15:19 ` [PATCH 1/3] serial/imx: add device tree support Shawn Guo
2011-06-18 16:19   ` Grant Likely
2011-06-19  7:02     ` Wolfram Sang
2011-06-19  7:30     ` Shawn Guo
2011-06-19 15:05       ` Grant Likely
2011-06-19 15:15         ` Rob Herring
2011-06-19 18:44           ` Grant Likely [this message]
2011-06-21 13:55       ` Shawn Guo
2011-06-21 18:32         ` Mitch Bradley
2011-06-21 18:42           ` Grant Likely
2011-06-21 18:53             ` Russell King - ARM Linux
2011-06-21 19:02               ` Grant Likely
2011-06-21 19:04             ` Mitch Bradley
2011-06-21 19:13         ` Grant Likely
2011-06-21 19:35           ` Mitch Bradley
2011-06-21 19:38             ` Grant Likely
2011-06-21 22:08               ` Mitch Bradley
2011-06-21 22:33                 ` Grant Likely
2011-06-21 22:52                   ` Segher Boessenkool
2011-06-21 22:58                     ` Grant Likely
2011-06-22 15:33           ` Shawn Guo
2011-06-22 15:52             ` Grant Likely
2011-06-23  0:12               ` Shawn Guo
2011-06-23  3:35                 ` Grant Likely
2011-06-23 18:38           ` Shawn Guo
2011-06-23 23:11             ` Grant Likely
2011-06-24  3:49               ` Shawn Guo
2011-06-24  4:05                 ` Grant Likely
2011-06-18 16:21   ` Arnd Bergmann
2011-06-18 16:26     ` Grant Likely
2011-06-18 18:11       ` Arnd Bergmann
2011-06-19  7:41       ` Shawn Guo
2011-06-19  7:40     ` Shawn Guo
2011-06-18 15:19 ` [PATCH 2/3] net/fec: " Shawn Guo
2011-06-18 16:22   ` Grant Likely
2011-06-19  7:46     ` Shawn Guo
2011-06-18 18:27   ` Arnd Bergmann
2011-06-19  0:24     ` Grant Likely
2011-06-19  7:55     ` Shawn Guo
2011-06-19 11:39   ` Greg Ungerer
2011-06-19 12:11     ` Arnd Bergmann
2011-06-19 15:09       ` Rob Herring
2011-06-19 18:43         ` Grant Likely
2011-06-20  0:05       ` Greg Ungerer
2011-06-18 15:19 ` [PATCH 3/3] ARM: mx5: add basic device tree support for imx51 babbage Shawn Guo
2011-06-18 16:24   ` Grant Likely
2011-06-18 16:29 ` [PATCH 0/3] Add basic device " Grant Likely

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='BANLkTi=Ur1+FAHd2J_KGZgtuGTHrrtBb_g@mail.gmail.com' \
    --to=grant.likely@secretlab.ca \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).