linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: vm.rod25@gmail.com (Victor Rodriguez)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v8 4/9] davinci: McASP configuration for Omapl138-Hawkboard
Date: Fri, 19 Nov 2010 10:23:31 -0600	[thread overview]
Message-ID: <AANLkTimqiEjjJSRegjw8MsimoiPsaWRahVaN2NcUKk+m@mail.gmail.com> (raw)
In-Reply-To: <AANLkTimfu9-p6C8jZ1gZZvmw3tE0E7jGZkWGjDhnLfAR@mail.gmail.com>

On Thu, Nov 18, 2010 at 6:17 PM, Victor Rodriguez <vm.rod25@gmail.com> wrote:
> On Thu, Nov 18, 2010 at 5:57 PM, Kevin Hilman
> <khilman@deeprootsystems.com> wrote:
>> "Nori, Sekhar" <nsekhar@ti.com> writes:
>>
>>> Hi Michael,
>>>
>>> On Wed, Nov 17, 2010 at 02:12:53, Michael Williamson wrote:
>>>>
>>>> Help me out. ?Why do we need generic pin lists?
>>>>
>>>
>>> They might help in cases where all boards will use the same set of
>>> pins. For example, every one who uses I2C will most likely both the
>>> clock and data pins from the IP. For more complex peripherals with
>>> different pins options they serve a documentation purpose at best.
>>>
>>>> It seems to me that the "generic pin list" for da850.c isn't practical for most
>>>> (if not all) of the peripherals. ?They should be done using __initdata in
>>>> each board file.
>>>
>>> Yes, agreed.
>>>
>>>>
>>>> Just a cursory glance at what's in da850.c highlights several items being set
>>>> up for the EVM and not generically. ?For example:
>>>>
>>>> - da850_uart1_pins and da850_uart2_pins: I believe both have RTS/CTS pins which
>>>> ? for a generic definition should be included as for UART0, but would then
>>>> ? be unused as the EVM doesn't use these pins in this function.
>>>
>>> Yes, the generic pin list should have RTS and CTS pins defined for UART1
>>> and UART2. This needs fixing.
>>>
>>>>
>>>> - da850_mcasp_pins: if generic, must include all 16 AXR pins. ?I think you'd
>>>> ? be hard pressed to find a board configuration that would use all 16 AXR pins
>>>> ? for the McASP. ?I'm fairly sure the EVM uses the pins called out, and uses
>>>> ? other pins for other functions. ?So it's likely this structure wouldn't get used.
>>>
>>> Yes, the generic pin list should either be completed or removed
>>> altogether and the existing pin list da850_mcasp_pins should be
>>> copied into the board file and called da850_evm_mcasp_pins.
>>>
>>>>
>>>> - da850_mmcsd0_pins : includes 2 GPIO pins (specific to the EVM, though possible for
>>>> ? other boards) for the card detect and write protect signals. ?These pins are
>>>> ? completely arbitrary for that particular board design. I also believe that
>>>> ? the complete mmcsd0 port has 4 more data lines as part of it's peripheral, although
>>>> ? the driver doesn't support using them.
>>>
>>> This is incorrect again. The generic pin list should be completed
>>> (or removed) and the existing list should be copied into the EVM board
>>> file as da850_evm_mmcsd0_pins.
>>>
>>>>
>>>> - da850_emif25_pins interface doesn't include the generic pins for some of
>>>> ? the SDRAM functions.
>>>
>>> Yes, this should be completed (or removed). This list is unused anyway.
>>>
>>>>
>>>> - da850_cpgmac_pins defines both RMII and MII pins. ?I don't think any board
>>>> ? would want to configure both sets at the same time. ?Seems like this should
>>>> ? never get used...
>>>
>>> Agreed.
>>>
>>>>
>>>> It's also incomplete. ?What about the uPP pin list? ?Or the VPIF? ?Etc.
>>>
>>> These should be added as the drivers for these devices are
>>> supported.
>>>
>>>>
>>>> I think a board file author should be familiar enough with the SoC to understand
>>>> what peripheral pins he should be configuring for his/her particular hardware setup
>>>> and explicitly specify them in the board file.
>>>
>>> Agree.
>>>
>>>>
>>>> If you remove the common pin-mux lists and move them to a board file, then once you
>>>> configure your specific platform, is there any more memory used than with
>>>> the common scheme? ?Of course, there would be replication of pin-mux code in the board
>>>
>>> There is no memory wastage. All the pin lists are init data.
>>>
>>> I too prefer all generic pin lists which are most likely not
>>> going to be used at all to be removed. Unused stuff like this
>>> will only make code difficult to read.
>>
>> FWIW, I agree.
>>
>> Now, who wants to tackle it?
>>
>> Kevin
>>
>
> I could but I will need a little help and from all of you. :)
>
> Regards
>
> Victor Rodriguez
>

Hey I have sent the first patch in order to fix UARTs on da850. please
check if this is right

Regards

Victor Rodriguez

>> _______________________________________________
>> Davinci-linux-open-source mailing list
>> Davinci-linux-open-source at linux.davincidsp.com
>> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>>
>

  reply	other threads:[~2010-11-19 16:23 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1289601535-6746-1-git-send-email-vm.rod25@gmail.com>
2010-11-12 22:38 ` [PATCH v8 1/9] davinci: EMAC support for Omapl138-Hawkboard vm.rod25 at gmail.com
2010-11-12 22:38 ` [PATCH v8 2/9] davinci: EDMA " vm.rod25 at gmail.com
2010-11-12 22:38 ` [PATCH v8 4/9] davinci: McASP configuration " vm.rod25 at gmail.com
2010-11-15 11:10   ` Nori, Sekhar
2010-11-15 12:16     ` Sergei Shtylyov
2010-11-15 13:07       ` Nori, Sekhar
2010-11-15 14:31         ` Victor Rodriguez
2010-11-15 15:47         ` Sergei Shtylyov
2010-11-16 15:58           ` Victor Rodriguez
2010-11-16 16:04             ` Sergei Shtylyov
2010-11-16 16:37               ` Nori, Sekhar
2010-11-16 16:45                 ` Victor Rodriguez
2010-11-16 20:42                 ` Michael Williamson
2010-11-16 21:19                   ` Victor Rodriguez
2010-11-16 21:21                   ` Victor Rodriguez
2010-11-18 16:21                   ` Nori, Sekhar
2010-11-18 16:38                     ` Victor Rodriguez
2010-11-18 16:47                       ` Nori, Sekhar
2010-11-18 23:57                     ` Kevin Hilman
2010-11-19  0:17                       ` Victor Rodriguez
2010-11-19 16:23                         ` Victor Rodriguez [this message]
2010-12-01 13:32   ` Nori, Sekhar
2010-12-01 15:20     ` Victor Rodriguez
2010-12-01 16:04       ` Nori, Sekhar
2010-12-01 16:13         ` Victor Rodriguez
2010-12-01 16:32     ` Sergei Shtylyov
2010-12-01 16:41       ` Victor Rodriguez
2010-11-12 22:38 ` [PATCH v8 5/9] davinci: Audio support " vm.rod25 at gmail.com
2010-11-12 22:38 ` [PATCH v8 6/9] davinci: MMC/SD and USB-OHCI configuration " vm.rod25 at gmail.com
2010-11-12 22:38 ` [PATCH v8 7/9] davinci: MMC/SD support " vm.rod25 at gmail.com
2010-11-12 22:38 ` [PATCH v8 8/9] davinci: USB clocks " vm.rod25 at gmail.com
2010-11-12 22:38 ` [PATCH v8 9/9] davinci: USB1.1 support " vm.rod25 at gmail.com

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=AANLkTimqiEjjJSRegjw8MsimoiPsaWRahVaN2NcUKk+m@mail.gmail.com \
    --to=vm.rod25@gmail.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;
as well as URLs for NNTP newsgroup(s).