public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: michael.williamson@criticallink.com (Michael Williamson)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] davinci: Initial support for MityDSP-L138/MityARM-1808
Date: Mon, 30 Aug 2010 09:29:22 -0400	[thread overview]
Message-ID: <4C7BB232.80502@criticallink.com> (raw)
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB59301F6615555@dbde02.ent.ti.com>

 Hi Sekhar,

On 8/30/2010 7:58 AM, Nori, Sekhar wrote:
> Hi Michael,
>
> On Sat, Aug 28, 2010 at 17:29:34, Michael Williamson wrote:
>> This patch adds initial support for the MityDSP-L138 and MityDSP-1808 system
>> on Module (SOM) under the machine name "mityomapl138".  These SOMs are based
>> on the da850 davinci CPU architecture.  Information on these SOMs may be
>> found at http://www.mitydsp.com.
>>
>> Basic support for the console UART, NAND, and EMAC (MII interface) is
>> included in this patch.
>>
>> Signed-off-by: Michael Williamson <michael.williamson@criticallink.com>
>> ---
>> Notes:
>>   1) Patch is against 0a50e05b20f3c6af67656303bdb3661a2541ce03 of Kevin's
>>      tree (2.6.36-rc2).
>>   2) I did not include a defconfig update in this patch.  Until the regulator
>>      support is added back in (planned subsequent patch), it cannot be added
>>      to da8xx_omapl_defconfig as the CONFIG_REGULATOR option doesn't play
>>      nice with platforms not defining a regulator.  If a defconfig support
> What is the issue you are facing? I have seen in the past that enabling
> CONFIG_REGULATOR_DUMMY helped overcome an aic3x codec initialization issue
> when the aic3x probe expects a few regulators to be present in the system
> if CONFIG_REGULATOR is on.
>
Enabling CONFIG_REGULATOR_DUMMY will remove the error message for this SOM. 
This brings up a couple of questions I've wanted to ask:  Are there ground
rules are for adding options to defconfig files that cover more than one
architecture/board?  Is a defconfig required for new boards?

Is it OK that I add CONFIG_REGULATOR_DUMMY to the da8xx_omapl_defconfig file? 
Or should there be a critical warning as currently defined if there
is no regulator found for the other da8xx platforms? 

Can I add the other options to support booting from NAND in this as well?
If the answer is "sure", then I can update the da8xx_omapl_defconfig and submit
that as a separate patch or resubmit this one.

Thank you for any insight.

-Mike
  

  reply	other threads:[~2010-08-30 13:29 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-28 11:59 [PATCH] davinci: Initial support for MityDSP-L138/MityARM-1808 Michael Williamson
2010-08-30 11:58 ` Nori, Sekhar
2010-08-30 13:29   ` Michael Williamson [this message]
2010-08-30 15:05 ` Kevin Hilman
2010-08-30 15:35   ` Michael Williamson
2010-08-30 16:21     ` Kevin Hilman

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=4C7BB232.80502@criticallink.com \
    --to=michael.williamson@criticallink.com \
    --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