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
next prev parent 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).