All of lore.kernel.org
 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 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.