All of lore.kernel.org
 help / color / mirror / Atom feed
From: Valentin Longchamp <valentin.longchamp@keymile.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v2] spi/kirkwood: add weak functions board_spi_bus_claim/release
Date: Thu, 29 Mar 2012 16:49:58 +0200	[thread overview]
Message-ID: <4F747696.3040606@keymile.com> (raw)
In-Reply-To: <F766E4F80769BD478052FB6533FA745D1A2F6FA964@SC-VEXCH4.marvell.com>

On 03/29/2012 04:21 PM, Prafulla Wadaskar wrote:
>> On 03/28/2012 09:48 AM, Prafulla Wadaskar wrote:
>>>> On 03/26/2012 11:58 AM, Valentin Longchamp wrote:
>>>>> Some kirkwood based boards may need to implement such function due
>>
>> Correct, this is exactly our use case: we have the NAND Flash
>> Controller and the
>> SPI controller that share the same pins.
>>
>>>
>>> But this is not board specific whereas, it should be feature
>> enhancement for Kirkwood spi driver.
>>
>> This is correct for the mpp part of spi_claim_bus. If you look at the
>> actual
>> implementation that we do in our board specific function, there is an
>> additional
>> step that is needed by our board design.
>>
>>>
>>> You should add this support very similar to multiple CS pin
>> selection support added to the Kirkwood driver, no external (board
>> specific triggers needed)
>>>
>>> Here are my suggestions:
>>> 1. Configure these mpps in your board specific files as NF pins.
>>> 2. Populate below logic for claim/release bus feature in Kirkwood
>> spi driver.
>>> 2.a. When spi_claim_bus will be called, backup current mpps status
>> and reconfigure these mpps for SPI in Kirkwood_spi driver.
>>> 2.b. When spi_release_bus will be called, reconfigure with backed up
>> mfg as SPI pins
>>> 2.c. Add check for to avoid multiple claim for same bus
>>>
>>
>> OK, I agree with this, but I would add:
>> 2.d. call weak attribute functions boad_spi_claim/release_bus at the
>> end of
>> spi_claim/release_bus functions
> 
> With above logic, SPI driver will manage the show cleanly.
> Then, why do you need these weak attribute functions?
> 

Because this is in our case not sufficient: we have an external device that
takes care of "disabling" the the SPI bus from the "bus" when we do some NF
accesses (and vice-versa), so that the SPI devices do not try interpret the NF
signal toggling as SPI accesses. This external "mux" is driver by a GPIO and
that's what I want to put in these board weak attribute functions.

They belong to spi_claim/release_bus but really are specific to our
device/boards and that's why I would need such functions.

-- 
Valentin Longchamp
Embedded Software Engineer
Hardware and Chip Integration
______________________________________
KEYMILE AG
Schwarzenburgstr. 73
CH-3097 Liebefeld
Phone +41 31 377 1318
Fax   +41 31 377 1212
valentin.longchamp at keymile.com
www.keymile.com
______________________________________
KEYMILE: A Specialist as a Partner

  reply	other threads:[~2012-03-29 14:49 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-26  9:58 [U-Boot] [PATCH v2] spi/kirkwood: add weak functions board_spi_bus_claim/release Valentin Longchamp
2012-03-27 13:27 ` Valentin Longchamp
2012-03-28  7:48   ` Prafulla Wadaskar
2012-03-29 12:49     ` Valentin Longchamp
2012-03-29 14:21       ` Prafulla Wadaskar
2012-03-29 14:49         ` Valentin Longchamp [this message]
2012-03-29 15:44       ` Valentin Longchamp
2012-03-30 11:34         ` Prafulla Wadaskar
2012-03-30 12:14           ` Valentin Longchamp
2012-03-30 12:58             ` Prafulla Wadaskar
2012-04-02 13:37               ` Valentin Longchamp
2012-04-03  6:35                 ` Prafulla Wadaskar
2012-04-04  7:01                   ` Valentin Longchamp
2012-04-04  7:12                     ` Prafulla Wadaskar

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=4F747696.3040606@keymile.com \
    --to=valentin.longchamp@keymile.com \
    --cc=u-boot@lists.denx.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.