All of lore.kernel.org
 help / color / mirror / Atom feed
From: Igor Grinberg <grinberg@compulab.co.il>
To: Tony Lindgren <tony@atomide.com>
Cc: linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2] arm: omap3: cm-t35: add support for cm-t3730
Date: Mon, 13 Jun 2011 22:34:49 +0300	[thread overview]
Message-ID: <4DF66659.3070102@compulab.co.il> (raw)
In-Reply-To: <20110613133307.GC3352@atomide.com>

On 06/13/11 16:33, Tony Lindgren wrote:
> * Igor Grinberg <grinberg@compulab.co.il> [110603 06:33]:
>> I'm not sure I understand what are you trying to propose here...
>> If you look once again on the code, there is currently only one if (cpu_is_..) {} else {}
>> statement currently present.
>> (I can remove the "if (cpu_is_omap3630())" - it indeed has no value)
>>
>> Indeed, there will be some other differences...
>> Each time I submit a patch, I try to be as optimal as I can,
>> but again I'm open for suggestions...
>> (though I think it is optimal, e.g. 33 lines for a new running board...)
> What I meant is that maybe you should do the detection first in some
> get_revision function and populate the gpio pins there. Sort of like
> this recent beagle patch:
>
> https://patchwork.kernel.org/patch/859662/

Yes I've seen this patch (actually, I was one of the people who reviewed it).

> That way adding support for other differences will be easier.

OK, now I understand what you mean.
I think currently this is not optimal for cm-t35/3730 and will just complicate
things and introduce more l-o-c.

The situation on beagle board is much more complicated then on cm-t3x.
Beagle has quite a large number of revisions,
while cm-t35 has only one and cm-t3730 has only one.
Moreover, there is no difference in gpios - same numbers are used
for the same functionality.

In particular the only two differences (that s/w cares about) between the boards are:
1) mux of the DSS pins
2) no NAND on cm-t3730 (still not introduced by the patch in subj)

Nevertheless, I will try to come up with something,
so we can see and decide what is a better option.

I will base it on your devel-board branch
(correct me if you want it some other way).


-- 
Regards,
Igor.


WARNING: multiple messages have this Message-ID (diff)
From: grinberg@compulab.co.il (Igor Grinberg)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2] arm: omap3: cm-t35: add support for cm-t3730
Date: Mon, 13 Jun 2011 22:34:49 +0300	[thread overview]
Message-ID: <4DF66659.3070102@compulab.co.il> (raw)
In-Reply-To: <20110613133307.GC3352@atomide.com>

On 06/13/11 16:33, Tony Lindgren wrote:
> * Igor Grinberg <grinberg@compulab.co.il> [110603 06:33]:
>> I'm not sure I understand what are you trying to propose here...
>> If you look once again on the code, there is currently only one if (cpu_is_..) {} else {}
>> statement currently present.
>> (I can remove the "if (cpu_is_omap3630())" - it indeed has no value)
>>
>> Indeed, there will be some other differences...
>> Each time I submit a patch, I try to be as optimal as I can,
>> but again I'm open for suggestions...
>> (though I think it is optimal, e.g. 33 lines for a new running board...)
> What I meant is that maybe you should do the detection first in some
> get_revision function and populate the gpio pins there. Sort of like
> this recent beagle patch:
>
> https://patchwork.kernel.org/patch/859662/

Yes I've seen this patch (actually, I was one of the people who reviewed it).

> That way adding support for other differences will be easier.

OK, now I understand what you mean.
I think currently this is not optimal for cm-t35/3730 and will just complicate
things and introduce more l-o-c.

The situation on beagle board is much more complicated then on cm-t3x.
Beagle has quite a large number of revisions,
while cm-t35 has only one and cm-t3730 has only one.
Moreover, there is no difference in gpios - same numbers are used
for the same functionality.

In particular the only two differences (that s/w cares about) between the boards are:
1) mux of the DSS pins
2) no NAND on cm-t3730 (still not introduced by the patch in subj)

Nevertheless, I will try to come up with something,
so we can see and decide what is a better option.

I will base it on your devel-board branch
(correct me if you want it some other way).


-- 
Regards,
Igor.

  reply	other threads:[~2011-06-13 19:34 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-05  8:53 [PATCH] arm: omap3: cm-t35: add support for cm-t3730 Igor Grinberg
2011-05-05  8:53 ` Igor Grinberg
2011-05-05  9:51 ` Mike Rapoport
2011-05-05  9:51   ` Mike Rapoport
2011-05-08  7:20   ` [PATCH v2] " Igor Grinberg
2011-05-08  7:20     ` Igor Grinberg
2011-05-31 13:04     ` Tony Lindgren
2011-05-31 13:04       ` Tony Lindgren
2011-06-03 13:37       ` Igor Grinberg
2011-06-03 13:37         ` Igor Grinberg
2011-06-13 13:33         ` Tony Lindgren
2011-06-13 13:33           ` Tony Lindgren
2011-06-13 19:34           ` Igor Grinberg [this message]
2011-06-13 19:34             ` Igor Grinberg
2011-06-14  7:36             ` Tony Lindgren
2011-06-14  7:36               ` Tony Lindgren
2011-06-14 21:16               ` [PATCH 1/3] arm: omap3: cm-t35: minor comments fixes Igor Grinberg
2011-06-14 21:16                 ` Igor Grinberg
2011-06-14 21:16               ` [PATCH 2/3] arm: omap3: cm-t35: fix slow path warning Igor Grinberg
2011-06-14 21:16                 ` Igor Grinberg
2011-06-14 21:16               ` [PATCH v3 3/3] arm: omap3: cm-t35: add support for cm-t3730 Igor Grinberg
2011-06-14 21:16                 ` Igor Grinberg
2011-06-22 14:56                 ` Igor Grinberg
2011-06-22 14:56                   ` Igor Grinberg
2011-06-27  8:35                   ` Igor Grinberg
2011-06-27  8:35                     ` Igor Grinberg
2011-06-27 10:21                     ` Tony Lindgren
2011-06-27 10:21                       ` Tony Lindgren
2011-06-27 12:31                       ` Igor Grinberg
2011-06-27 12:31                         ` Igor Grinberg

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=4DF66659.3070102@compulab.co.il \
    --to=grinberg@compulab.co.il \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=tony@atomide.com \
    /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.