linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Segher Boessenkool <segher@kernel.crashing.org>
To: avorontsov@ru.mvista.com
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [RFC][PATCH] MPC832x_RDB: update dts to use spi, register mmc_spi stub
Date: Mon, 6 Aug 2007 20:18:47 +0200	[thread overview]
Message-ID: <d36303a31bb9cd2ab7cb38a09428e616@kernel.crashing.org> (raw)
In-Reply-To: <20070801132948.GB20200@localhost.localdomain>

>>>>>  		spi@4c0 {
>>>>>  			device_type = "spi";
>>>>> +			device-id = <1>;
>>>>
>>>> Can we just use the reg value for bus_num in the kernel.
>>>
>>> Sure, technically nothing prevents this. But, QE specs names
>>> SPIs by these ids.
>>
>> As a minimum the property name should start with "fsl," then.
>
> fsl,device-id = <1>;, correct?

Fine with me.  Someone more familiar with the FSL SoCs might
have a different opinion about polluting their namespace though.

>>> Plus, from the kernel side spi name will be
>>> not pretty, it will be spi1216.1.
>>
>> What, the kernel cannot implement a counter itself?
>
> Just counter is especially meaningless and confusing. It will
> work in that particular case, though. But then SPI bus number will
> depend on definition order in the dts file. This isn't how SPI
> bus numbers should be assigned. SPI bus numbers taken from specs,
> this is how people know which SPI is which.

Right, so the kernel platform code should number the SPI busses
based on their position in the device tree, etc.; that doesn't
mean you should put a Linux-specific "device name" property in
there.

>>>>> +				compatible = "mmc-spi";
>>
>> Needs to be more specific.
>
> Um.. for example? I can't imagine anything specific for this. ;-)

It should include a vendor name, a device name, and/or a board
name.  Something that uniquely defines the hardware programming
model for the device.

>>>>> +				pio-handle = <&mmc1pio>;
>>
>> What is this for?
>
> To set up output function of GPIO pin for MMC chip select.
>
> And well, I've just looked into par_io_of_config(), and I've found
> that pio-handle is mandatory (obviously), and thus let's back to:
>
>>>> we should do this in board code and not the device tree.
>>>
>>> Well, I've done this initially. But Vitaly hinted that this could
>>> be done in the DT instead, which made sense to me - mmc is the child
>>> device of SPI bus. Why do you think it shouldn't be in the DT? I'm
>>> not arguing, just want understand this.
>>
>> The hardware should be described in the device tree.  This isn't
>> the same as simply copying all your Linux code into it ;-)
>
> Ugh. SD/MMC slot is the hardware, isn't it? It have wired SPI pins,
> and chip select pin. To set up this pin, I need mmc node, which means
> that I can't completely move mmc definitions to the board file, as
> suggested by Kumar Gala.
>
> Advices?

You need to declare in the SPI node which GPIOs it uses for
what.  You shouldn't have the actual values to put into the
GPIO registers in the device tree; the kernel driver can
figure it out.

Hope this helps,


Segher

  reply	other threads:[~2007-08-06 18:18 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-26 13:57 [RFC][PATCH] MPC832x_RDB: update dts to use spi, register mmc_spi stub Anton Vorontsov
2007-07-26 15:36 ` Joakim Tjernlund
2007-07-26 15:47   ` Anton Vorontsov
2007-07-26 19:40     ` [RFC][PATCH] MPC832x_RDB: update dts to use spi, registermmc_spi stub Joakim Tjernlund
2007-07-27  7:55       ` Kumar Gala
2007-07-31 21:47       ` Segher Boessenkool
2007-07-27  8:14 ` [RFC][PATCH] MPC832x_RDB: update dts to use spi, register mmc_spi stub Kumar Gala
2007-07-27 11:45   ` Anton Vorontsov
2007-07-27 13:55     ` Kumar Gala
2007-07-27 16:40     ` Scott Wood
2007-07-31 22:00       ` Segher Boessenkool
2007-08-01 17:43         ` Scott Wood
2007-08-06 18:24           ` Segher Boessenkool
2007-07-31 22:06     ` Segher Boessenkool
2007-08-01 13:29       ` Anton Vorontsov
2007-08-06 18:18         ` Segher Boessenkool [this message]
2007-08-07 10:53           ` Anton Vorontsov
2007-08-07 16:11             ` Segher Boessenkool
2007-08-01 19:16       ` Kim Phillips
2007-08-06 18:25         ` Segher Boessenkool
2007-08-06 21:31           ` Kim Phillips
2007-08-06 22:08             ` Segher Boessenkool
2007-07-31 22:10 ` Segher Boessenkool
2007-08-01 12:34   ` Anton Vorontsov
2007-08-06 18:09     ` Segher Boessenkool
2007-08-06 18:50       ` Scott Wood

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=d36303a31bb9cd2ab7cb38a09428e616@kernel.crashing.org \
    --to=segher@kernel.crashing.org \
    --cc=avorontsov@ru.mvista.com \
    --cc=linuxppc-dev@ozlabs.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).