On Thu, Jan 03, 2008 at 09:54:45AM -0500, Jon Smirl wrote:
> On 1/2/08, David Gibson <[EMAIL PROTECTED]> wrote:
[snip]
> > Instantiating the fabric driver off any node is wrong, precisely
> > because it is an abstraction. The fabric driver should be
> > instantiated by the platform code.
>
> Inst
On 1/4/08, Timur Tabi <[EMAIL PROTECTED]> wrote:
> Grant Likely wrote:
> > Don't put
> > that burden on the dts author.
>
> As the DTS author in question, I hereby declare that such a requirement is not
> a burden in the slightest. Thank you.
Dude, you work for *Freescale*. The set of dts author
Grant Likely wrote:
> On 1/3/08, Scott Wood <[EMAIL PROTECTED]> wrote:
>> Grant Likely wrote:
>>> On 1/3/08, Timur Tabi <[EMAIL PROTECTED]> wrote:
Grant Likely wrote:
> Why not be a child of the i2c bus with a phandle to the ssi bus?
Because when I probe the SSI node, I want to k
On Thu, Jan 03, 2008 at 11:54:24AM -0600, Timur Tabi wrote:
> Jon Smirl wrote:
> > On 1/2/08, Timur Tabi <[EMAIL PROTECTED]> wrote:
> >> Jon Smirl wrote:
> >>> On 1/1/08, Jon Smirl <[EMAIL PROTECTED]> wrote:
> On 12/19/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
[snip]
> > Don't we want to follo
Grant Likely wrote:
> On 1/3/08, Scott Wood <[EMAIL PROTECTED]> wrote:
>> I'd just link in both directions, and let software follow it in
>> whichever direction it prefers.
>
> Gah! Don't do that! Then you need to maintain both directions in the
> dts file. Software is good at generating revers
On 1/3/08, Scott Wood <[EMAIL PROTECTED]> wrote:
> Grant Likely wrote:
> > On 1/3/08, Timur Tabi <[EMAIL PROTECTED]> wrote:
> >> Grant Likely wrote:
> >>
> >>> Why not be a child of the i2c bus with a phandle to the ssi bus?
> >> Because when I probe the SSI node, I want to know what the attached c
Grant Likely wrote:
> On 1/3/08, Timur Tabi <[EMAIL PROTECTED]> wrote:
>> Grant Likely wrote:
>>
>>> Why not be a child of the i2c bus with a phandle to the ssi bus?
>> Because when I probe the SSI node, I want to know what the attached codec is.
>> So if anything, I would need a pointer from the
On 1/3/08, Timur Tabi <[EMAIL PROTECTED]> wrote:
> Grant Likely wrote:
>
> > Make the compatible property tell you! :-) If it's connected to an
> > I2S codec, then it could be compatible = "fsl,mpc8610-ssi,i2s". Or
> > for AC7, compatible = "fsl,mpc8610-ssi,ac97"
>
> That won't work. There are
On 1/3/08, Timur Tabi <[EMAIL PROTECTED]> wrote:
> Grant Likely wrote:
>
> > The device tree is a description of the hardware; not software. It's
> > not a good idea to break with convention due to current driver
> > architecture.
>
> I believe that with ASoC V1, I'm stuck between a rock and a har
Grant Likely wrote:
> Make the compatible property tell you! :-) If it's connected to an
> I2S codec, then it could be compatible = "fsl,mpc8610-ssi,i2s". Or
> for AC7, compatible = "fsl,mpc8610-ssi,ac97"
That won't work. There are too many variations. I think a separate property
just makes
On 1/3/08, Timur Tabi <[EMAIL PROTECTED]> wrote:
> Grant Likely wrote:
>
> > Does that mean with ASoC V2 you can instantiate it with the board
> > specific platform code instead?
>
> I don't know. I haven't really looked at V2 yet. You'll have to ask Liam
> Girdwood.
>
> > This is one of the exam
Grant Likely wrote:
> The device tree is a description of the hardware; not software. It's
> not a good idea to break with convention due to current driver
> architecture.
I believe that with ASoC V1, I'm stuck between a rock and a hard place, and so
the only way to make this code work is to be
On 1/3/08, Timur Tabi <[EMAIL PROTECTED]> wrote:
> Grant Likely wrote:
>
> > Why not be a child of the i2c bus with a phandle to the ssi bus?
>
> Because when I probe the SSI node, I want to know what the attached codec is.
> So if anything, I would need a pointer from the SSI bus *to* the respec
David Gibson wrote:
> Instantiating the fabric driver off any node is wrong, precisely
> because it is an abstraction. The fabric driver should be
> instantiated by the platform code.
Can you tell me how to do that?
--
Timur Tabi
Linux Kernel Developer @ Freescale
On 1/3/08, Timur Tabi <[EMAIL PROTECTED]> wrote:
> Jon Smirl wrote:
> > Don't we want to follow the device tree policy of putting the device
> > on the controlling bus and then link it to the data bus?
>
> Normally, that sounds like a good idea, but the cs4270 is an I2S device first,
> and an I2C d
Grant Likely wrote:
> Does that mean with ASoC V2 you can instantiate it with the board
> specific platform code instead?
I don't know. I haven't really looked at V2 yet. You'll have to ask Liam
Girdwood.
> This is one of the examples of where the compatible properties are
> trying to be far
Grant Likely wrote:
> Why not be a child of the i2c bus with a phandle to the ssi bus?
Because when I probe the SSI node, I want to know what the attached codec is.
So if anything, I would need a pointer from the SSI bus *to* the respective
child on the I2C bus.
I know little about platform
Jon Smirl wrote:
> For this model to work you need to split your driver. fsl-ssi and
> mpc8610_hpcd need to be in two separate drivers.
They are two separate drivers. sound/soc/fsl/fsl_ssi.c and
sound/soc/fsl/mpc8610_hpcd.c
> fsl-ssi is easy
> enough to load since it has a device tree entr
Jon Smirl wrote:
> On 1/2/08, Timur Tabi <[EMAIL PROTECTED]> wrote:
>> Jon Smirl wrote:
>>> On 1/1/08, Jon Smirl <[EMAIL PROTECTED]> wrote:
On 12/19/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
> + [EMAIL PROTECTED] {
> + compatible = "fsl,ssi";
> +
On 1/2/08, David Gibson <[EMAIL PROTECTED]> wrote:
> On Wed, Jan 02, 2008 at 09:29:57AM -0600, Timur Tabi wrote:
> > Jon Smirl wrote:
> > > On 12/19/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
> > >> sound/soc/fsl/fsl_ssi.c | 614 +++
> > >> sound/soc/fsl/fsl_ss
On 1/2/08, David Gibson <[EMAIL PROTECTED]> wrote:
> On Wed, Jan 02, 2008 at 12:12:00PM -0500, Jon Smirl wrote:
> > On 1/2/08, Grant Likely <[EMAIL PROTECTED]> wrote:
> > > On 1/2/08, Jon Smirl <[EMAIL PROTECTED]> wrote:
> > > > On 1/2/08, Timur Tabi <[EMAIL PROTECTED]> wrote:
> > > > mpc8610_hpcd
On Wed, Jan 02, 2008 at 12:12:00PM -0500, Jon Smirl wrote:
> On 1/2/08, Grant Likely <[EMAIL PROTECTED]> wrote:
> > On 1/2/08, Jon Smirl <[EMAIL PROTECTED]> wrote:
> > > On 1/2/08, Timur Tabi <[EMAIL PROTECTED]> wrote:
> > > mpc8610_hpcd is the harder one to load since it doesn't have a device
> >
On Wed, Jan 02, 2008 at 09:29:57AM -0600, Timur Tabi wrote:
> Jon Smirl wrote:
> > On 12/19/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
> >> sound/soc/fsl/fsl_ssi.c | 614 +++
> >> sound/soc/fsl/fsl_ssi.h | 224 +++
> >
> > I'm confused
On 1/2/08, Grant Likely <[EMAIL PROTECTED]> wrote:
> On 1/2/08, Jon Smirl <[EMAIL PROTECTED]> wrote:
> > On 1/2/08, Grant Likely <[EMAIL PROTECTED]> wrote:
> > > > Alternatively, the best place for this device would be on the ASOC
> > > > bus, but the ASOC bus hasn't been created when the platform
On 1/2/08, Jon Smirl <[EMAIL PROTECTED]> wrote:
> On 1/2/08, Grant Likely <[EMAIL PROTECTED]> wrote:
> > > Alternatively, the best place for this device would be on the ASOC
> > > bus, but the ASOC bus hasn't been created when the platform code runs.
> > > Maybe I can figure out a place in the plat
On 1/2/08, Grant Likely <[EMAIL PROTECTED]> wrote:
> > Alternatively, the best place for this device would be on the ASOC
> > bus, but the ASOC bus hasn't been created when the platform code runs.
> > Maybe I can figure out a place in the platform code to create this
> > device after the ASOC drive
On Sat, Dec 22, 2007 at 08:58:21PM -0600, Timur Tabi wrote:
> Scott Wood wrote:
>
>>> None of the SOC nodes in any DTS have a "compatible" entry.
>>
>> Not quite true; ep88xc, mpc8272ads, and pq2fads have them.
>
> Ah ok. So what should the compatible entry for 8641 be?
>
> compatible = "fsl
On 1/2/08, Jon Smirl <[EMAIL PROTECTED]> wrote:
> On 1/2/08, Grant Likely <[EMAIL PROTECTED]> wrote:
> > On 1/2/08, Jon Smirl <[EMAIL PROTECTED]> wrote:
> > > On 1/2/08, Timur Tabi <[EMAIL PROTECTED]> wrote:
> > > mpc8610_hpcd is the harder one to load since it doesn't have a device
> > > tree entr
On 1/2/08, Grant Likely <[EMAIL PROTECTED]> wrote:
> On 1/2/08, Jon Smirl <[EMAIL PROTECTED]> wrote:
> > On 1/2/08, Timur Tabi <[EMAIL PROTECTED]> wrote:
> > mpc8610_hpcd is the harder one to load since it doesn't have a device
> > tree entry. What you want to do it match on the compatible field of
On 1/2/08, Jon Smirl <[EMAIL PROTECTED]> wrote:
> On 1/2/08, Timur Tabi <[EMAIL PROTECTED]> wrote:
> mpc8610_hpcd is the harder one to load since it doesn't have a device
> tree entry. What you want to do it match on the compatible field of
> the root node.
>
> static struct of_device_id fabric_of_
On 1/2/08, Timur Tabi <[EMAIL PROTECTED]> wrote:
> That's the best plan I came up with. This is apparently fixed in ASoC
> V2. From ASoC V1's perspective, the fabric driver must be the master.
> However, it doesn't make sense to have a node in the device tree for the
> fabric driver, because ther
On 1/2/08, Timur Tabi <[EMAIL PROTECTED]> wrote:
> Jon Smirl wrote:
> > If that's the case the cs4270 should be in the i2c bus node (missing
> > currently) and then a link from the SSI bus would point to it.
>
> The CS4270 is a child of both the I2C bus *and* the SSI bus. It needs
> to have two no
On 1/2/08, Timur Tabi <[EMAIL PROTECTED]> wrote:
> Are you saying that you want to use the same kernel on four different
> systems? If so, then you need to find a way to compile all fabric
> drivers together, and at boot time each fabric driver will decide
> whether it will do anything.
Yes, I ha
On 1/2/08, Timur Tabi <[EMAIL PROTECTED]> wrote:
> Jon Smirl wrote:
> > On 1/1/08, Jon Smirl <[EMAIL PROTECTED]> wrote:
> >> On 12/19/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
> >>> + [EMAIL PROTECTED] {
> >>> + compatible = "fsl,ssi";
> >>> +
Jon Smirl wrote:
> On 12/19/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
>> sound/soc/fsl/fsl_ssi.c | 614 +++
>> sound/soc/fsl/fsl_ssi.h | 224 +++
>
> I'm confused about this part. You built a driver for the mpc8610 ssi
> port. This p
Jon Smirl wrote:
> On 1/1/08, Jon Smirl <[EMAIL PROTECTED]> wrote:
>> On 12/19/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
>>> + [EMAIL PROTECTED] {
>>> + compatible = "fsl,ssi";
>>> + cell-index = <0>;
>>> + reg = <16000
Jon Smirl wrote:
> On 12/19/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
>> + [EMAIL PROTECTED] {
>> + compatible = "fsl,ssi";
>> + cell-index = <0>;
>> + reg = <16000 100>;
>> + interrupt-parent = <&
On 12/19/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
> sound/soc/fsl/fsl_ssi.c | 614 +++
> sound/soc/fsl/fsl_ssi.h | 224 +++
I'm confused about this part. You built a driver for the mpc8610 ssi
port. This port has a device tree entry
On Tue, Jan 01, 2008 at 12:25:32PM -0500, Jon Smirl wrote:
> On 12/19/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
> > + [EMAIL PROTECTED] {
> > + compatible = "fsl,ssi";
> > + cell-index = <0>;
> > + reg = <16000 100>;
>
On 1/1/08, Jon Smirl <[EMAIL PROTECTED]> wrote:
> On 12/19/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
> > + [EMAIL PROTECTED] {
> > + compatible = "fsl,ssi";
> > + cell-index = <0>;
> > + reg = <16000 100>;
> > +
On 12/19/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
> + [EMAIL PROTECTED] {
> + compatible = "fsl,ssi";
> + cell-index = <0>;
> + reg = <16000 100>;
> + interrupt-parent = <&mpic>;
> +
Scott Wood wrote:
>> None of the SOC nodes in any DTS have a "compatible" entry.
>
> Not quite true; ep88xc, mpc8272ads, and pq2fads have them.
Ah ok. So what should the compatible entry for 8641 be?
compatible = "fsl,mpc8641"
That looks a lot like what a compatible entry for the CPU
On Thu, Dec 20, 2007 at 06:13:31PM -0500, Jon Smirl wrote:
> On 12/20/07, Scott Wood <[EMAIL PROTECTED]> wrote:
> > Timur Tabi wrote:
> > > Jon Smirl wrote:
> > >
> > >> mpc5200 does it like this:
> > >> of_platform_bus_probe(NULL, NULL, NULL);
> > >
> > > I think that tells the OF base code to pro
On 12/20/07, Scott Wood <[EMAIL PROTECTED]> wrote:
> Timur Tabi wrote:
> > Jon Smirl wrote:
> >
> >> mpc5200 does it like this:
> >> of_platform_bus_probe(NULL, NULL, NULL);
> >
> > I think that tells the OF base code to probe everything in the device tree,
> > which is probably overkill. I think
Timur Tabi wrote:
> Jon Smirl wrote:
>
>> mpc5200 does it like this:
>> of_platform_bus_probe(NULL, NULL, NULL);
>
> I think that tells the OF base code to probe everything in the device tree,
> which is probably overkill. I think fsl_soc.c covers most of the device
> tree,
> but the SSI is n
Timur Tabi wrote:
> Olof Johansson wrote:
>
>>> I was just following the example from another board file. However, the
>>> 'soc'
>>> node in the device tree does not have a compatible property, so I don't how
>>> to
>>> change this.
>> Then add an appropriate compatible entry to it, please.
>
Jon Smirl wrote:
> mpc5200 does it like this:
> of_platform_bus_probe(NULL, NULL, NULL);
I think that tells the OF base code to probe everything in the device tree,
which is probably overkill. I think fsl_soc.c covers most of the device tree,
but the SSI is not defined in fsl_soc.c.
--
Timur
On 12/20/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
> Jon Smirl wrote:
>
> > How is of_platform_bus_probe() supposed to be called? mpc5200/virtex
> > call it with three NULLs. Is it necessary to name all of the buses in
> > a of_device_id? If it's not necessary to list the buses the
> > of_platform_
Olof Johansson wrote:
>> I was just following the example from another board file. However, the
>> 'soc'
>> node in the device tree does not have a compatible property, so I don't how
>> to
>> change this.
>
> Then add an appropriate compatible entry to it, please.
None of the SOC nodes in
On Thu, Dec 20, 2007 at 08:24:35AM -0600, Timur Tabi wrote:
> Olof Johansson wrote:
>
> >> +static struct of_device_id mpc8610_ids[] = {
> >> + { .type = "soc", },
> >> + {}
> >
> > Please scan based on compatible instead of device_type.
>
> I was just following the example from another board
Jon Smirl wrote:
> How is of_platform_bus_probe() supposed to be called? mpc5200/virtex
> call it with three NULLs. Is it necessary to name all of the buses in
> a of_device_id? If it's not necessary to list the buses the
> of_platform_bus_probe() call could be moved to common code.
I added the a
On 12/19/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
> +static struct of_device_id mpc8610_ids[] = {
> + { .type = "soc", },
> + {}
> +};
> +
> +static int __init mpc8610_declare_of_platform_devices(void)
> +{
> + if (!machine_is(mpc86xx_hpcd))
> + return 0;
> +
> +
Olof Johansson wrote:
>> +static struct of_device_id mpc8610_ids[] = {
>> +{ .type = "soc", },
>> +{}
>
> Please scan based on compatible instead of device_type.
I was just following the example from another board file. However, the 'soc'
node in the device tree does not have a compati
So, like, the other day Timur Tabi mumbled:
> diff --git a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
> b/arch/powerpc/platforms/86xx/mpc8610_hpc
> d.c
> index 6390895..6e1bde3 100644
> --- a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
> +++ b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
> @@ -34,9 +
Hi,
This is a fairly substantial driver to get through, but here are some
initial comments on some of the simpler stuff:
On Wed, Dec 19, 2007 at 06:03:09PM -0600, Timur Tabi wrote:
> This patch adds ALSA SoC device drivers for the Freescale MPC8610 SoC
> and the MPC8610-HPCD reference board.
[.
55 matches
Mail list logo
