* Re: [PATCH] powerpc: Add MPC837x PCIE controller RC mode support
From: Kumar Gala @ 2008-01-02 15:23 UTC (permalink / raw)
To: Li Li; +Cc: Wood Scott, linuxppc-dev, kim phillips
In-Reply-To: <1199272605.22416.8.camel@Guyver>
On Jan 2, 2008, at 5:16 AM, Li Li wrote:
> * The MPC837x PCIE controller hardware resources and SerDes are
> initiated in u-boot.
> * Merge the MPC837x PCIE code into arch/powerpc/sysdev/fsl_pci.c
> * The MPC837x PCIE controller`s configure address bit field is uniqe:
> bus number: bits 31-24
> device number: bits 23-19
> function number: bits 18-16
> ext reg number: bits 11-8
> reg number: bits 7-2
> * Add mpc837x_exclude_device to fixup a controller bug.
what is the bug that is being worked around?
- k
^ permalink raw reply
* Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Timur Tabi @ 2008-01-02 15:29 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <9e4733910801012027p4be16b92r43af773f4e5ae531@mail.gmail.com>
Jon Smirl wrote:
> On 12/19/07, Timur Tabi <timur@freescale.com> 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.
>
> + ssi@16000 {
> + compatible = "fsl,ssi";
> + cell-index = <0>;
> + reg = <16000 100>;
> + interrupt-parent = <&mpic>;
> + interrupts = <3e 2>;
> + fsl,mode = "i2s-slave";
> + codec {
> + compatible = "cirrus,cs4270";
> + /* MCLK source is a stand-alone oscillator */
> + bus-frequency = <bb8000>;
> + };
> + };
>
> But then you don't create an of_platform_driver for this device.
> Instead you create one for the fabric driver, struct
> of_platform_driver mpc8610_hpcd_of_driver, and directly link the SSI
> driver into it.
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 there is no such "device". The fabric driver is
an abstraction. So I need to chose some other node to probe the fabric
driver with. I chose the SSI, since each SSI can have only one codec.
>
> +static struct of_device_id mpc8610_hpcd_match[] = {
> + {
> + .compatible = "fsl,ssi",
> + },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, mpc8610_hpcd_match);
> +
> +static struct of_platform_driver mpc8610_hpcd_of_driver = {
> + .owner = THIS_MODULE,
> + .name = "mpc8610_hpcd",
> + .match_table = mpc8610_hpcd_match,
> + .probe = mpc8610_hpcd_probe,
> + .remove = mpc8610_hpcd_remove,
> +};
>
> static int mpc8610_hpcd_probe(struct of_device *ofdev,
> const struct of_device_id *match)
> {
> .....
> machine_data->dai.cpu_dai = fsl_ssi_create_dai(&ssi_info);
>
> Isn't this two separate drivers that have been combined into one
> driver? Or does the fsl_ssi channel only work on the mpc8610_hpcd?
Sorry, I don't understand your question.
> This is the problem of knowing how to load the fabric driver that I
> was talking about in the other threads.
Yes, and the decision I made on this topic is to have the fabric driver
probed on the SSI node.
For ASoC V1, I believe the problem is undefined and each driver should
be implemented in whatever way works best.
> A device that can occur on
> more than one chip ".compatible = "fsl,ssi"," is being used to pull in
> a platform specific fabric driver, "mpc8610_hpcd". You can use the
> kernel config system to select the right driver for ".compatible =
> "fsl,ssi"," that matches you hardware and compile it in.
Ok, I think I understand that.
> But that doesn't work in my environment. My generic channel is
> "fsl,i2s". I have four different systems booting off from a shared
> network drive. Each of these systems needs the common "fsl,i2s" driver
> but they all four need different fabric drivers.
That, I don't understand. fsl,ssi is pretty much the same thing as
fsl,i2s, since the SSI *is* an I2S device. It's also an AC97 device,
which is why I added the fsl,mode property.
The fabric driver is specific to the board. So you should be using
Kconfig to select the fabric driver. There is no node in the device
tree for fabric drivers. I thought that was the consensus.
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.
^ permalink raw reply
* Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Jon Smirl @ 2008-01-02 15:34 UTC (permalink / raw)
To: Timur Tabi, Liam Girdwood; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <477BAB67.4080003@freescale.com>
On 1/2/08, Timur Tabi <timur@freescale.com> wrote:
> Jon Smirl wrote:
> > On 1/1/08, Jon Smirl <jonsmirl@gmail.com> wrote:
> >> On 12/19/07, Timur Tabi <timur@freescale.com> wrote:
> >>> + ssi@16000 {
> >>> + compatible = "fsl,ssi";
> >>> + cell-index = <0>;
> >>> + reg = <16000 100>;
> >>> + interrupt-parent = <&mpic>;
> >>> + interrupts = <3e 2>;
> >>> + fsl,mode = "i2s-slave";
> >>> + codec {
> >>> + compatible = "cirrus,cs4270";
> >>> + /* MCLK source is a stand-alone oscillator */
> >>> + bus-frequency = <bb8000>;
> >>> + };
> >>> + };
> >> Does this need to be bus-frequency? It's always called MCLK in all of
> >> the literature.
> >>
> >> In my case the MCLK comes from a chip on the i2c bus that is
> >> programmable How would that be encoded?.
> >
> > Looking at the cs4270 codec driver it is controlled by i2c (supports
> > SPI too). What happened to the conversation about putting codecs on
> > the controlling bus and then linking them to the data bus?
>
> The current CS4270 driver doesn't support device trees. When I wrote
> it, the idea of putting I2C info in the device tree was not finalized,
> and since the driver is supposed to be cross-platform, I decided to do
> it the old-fashioned way. Before I update the code, however, I'm
> waiting for:
>
> 1) The current code to be accepted into the tree
> 2) ASoC is updated to V2
> 3) The current drivers are updated to support ASoC V2.
I've been trying to get the i2c code in for two months. Hopefully it
will go in soon, no one had made any comments on it recently. Have you
tried your code with it?
There is nothing stopping your from putting a node for the CS4270 on
the i2c bus today. It just won't trigger the loading of the driver.
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?
> I think ASoC V2 will make it easier to support device trees, but I'm not
> ready yet for that.
It makes it a little easier but it doesn't fix everything. We need to
start looking at it since none of the example driver for it are device
tree based. It still has problems with wanting 'struct
platform_device' when we have 'struct of_platform_device' pointers. It
also doesn't know how to dynamically load codecs based on device
trees.
Liam messed up all of my code when he refactored it in late December.
I've switched over to the current SOC code for the moment. The big
thing that v2 fixes is that SOC is changed to being a subsystem
instead of platform driver. Being a subsystem is the correct model.
It would be good if more pieces of v2 get push forward. Then we can
sort out the device tree issues in it.
>
> > 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 nodes, one under each. Your're right in that there needs to
> be a link, but until the code is updated to ASoC V2, I think it's
> premature to add that support.
Adding the second device tree node doesn't have anything to do with
ASOC v2. It's specific to powerpc and device trees.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH] powerpc: Add MPC837x PCIE controller RC mode support
From: Olof Johansson @ 2008-01-02 15:51 UTC (permalink / raw)
To: Li Li; +Cc: Wood Scott, linuxppc-dev, kim phillips
In-Reply-To: <1199272605.22416.8.camel@Guyver>
On Wed, Jan 02, 2008 at 07:16:45PM +0800, Li Li wrote:
> diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
> index 1ee009e..f84caa7 100644
> --- a/include/linux/pci_ids.h
> +++ b/include/linux/pci_ids.h
> @@ -2111,6 +2111,10 @@
> #define PCI_DEVICE_ID_TDI_EHCI 0x0101
>
> #define PCI_VENDOR_ID_FREESCALE 0x1957
> +#define PCI_DEVICE_ID_MPC8378E 0x00c4
> +#define PCI_DEVICE_ID_MPC8378 0x00c5
> +#define PCI_DEVICE_ID_MPC8377E 0x00c6
> +#define PCI_DEVICE_ID_MPC8377 0x00c7
> #define PCI_DEVICE_ID_MPC8548E 0x0012
> #define PCI_DEVICE_ID_MPC8548 0x0013
> #define PCI_DEVICE_ID_MPC8543E 0x0014
In general it's not needed to add device ID's to the global table,
especially when they're only used once or twice. Just use the hex constant
in the driver instead.
-Olof
^ permalink raw reply
* Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Jon Smirl @ 2008-01-02 15:56 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <477BADF5.9060003@freescale.com>
On 1/2/08, Timur Tabi <timur@freescale.com> 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 have four different but similar systems. They only differer in
the codec chips used. I want to make a single kernel image and then
use the device tree to dynamically load the correct codec driver from
initrd. That will let me ship a single kernel image that services all
four machines. The codecs implement different sound systems from low
end to high end.
The correct solution for this is to use kernel modules and trigger
their loading based on the device tree. This is the same mechanism
used by USB and PCI.
For this model to work you need to split your driver. fsl-ssi and
mpc8610_hpcd need to be in two separate drivers. fsl-ssi is easy
enough to load since it has a device tree entry.
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_match[] = {
{
.compatible = "fsl,MPC8610HPCD",
},
{},
};
But this doesn't work since the root is the device tree isn't passed
down into the device probe code. (Could this be fixed?)
Instead we could make the separated mpc8610_hpcd fabric driver attach
to fsl,ssi.
static struct of_device_id fabric_of_match[] = {
{
.compatible = "fsl,ssi",
},
{},
};
Then in it's probe code check for the right platform.
unsigned long node = of_get_flat_dt_root();
if (!of_flat_dt_is_compatible(node, "fsl,MPC8610HPCD"))
return 0;
.. activate the code ...
You also need a static flag to make sure you don't active the driver
more than once.
This isn't the best solution since my four fabric drivers will still
load and check what platform they are on before exiting but at least
it works.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Grant Likely @ 2008-01-02 16:12 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <477BAB67.4080003@freescale.com>
On 1/2/08, Timur Tabi <timur@freescale.com> 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 nodes, one under each. Your're right in that there needs to
> be a link, but until the code is updated to ASoC V2, I think it's
> premature to add that support.
Why not be a child of the i2c bus with a phandle to the ssi bus? That
is the direction we've gone with other multi attachment devices. (ie.
Ethernet PHYs. Child of the MDIO node, phandle to link the Ethernet
controller with the PHY)
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Grant Likely @ 2008-01-02 16:28 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <477BADF5.9060003@freescale.com>
On 1/2/08, Timur Tabi <timur@freescale.com> 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 there is no such "device". The fabric driver is
> an abstraction. So I need to chose some other node to probe the fabric
> driver with. I chose the SSI, since each SSI can have only one codec.
Does that mean with ASoC V2 you can instantiate it with the board
specific platform code instead? I think that is the consensus we were
leaning towards in the last discussion about this issue.
> > But that doesn't work in my environment. My generic channel is
> > "fsl,i2s". I have four different systems booting off from a shared
> > network drive. Each of these systems needs the common "fsl,i2s" driver
> > but they all four need different fabric drivers.
>
> That, I don't understand. fsl,ssi is pretty much the same thing as
> fsl,i2s, since the SSI *is* an I2S device. It's also an AC97 device,
> which is why I added the fsl,mode property.
This is one of the examples of where the compatible properties are
trying to be far to generic about what they are. How do you define
what "fsl,ssi" is? What happens when Freescale produces another
peripheral that can do ssi but isn't register level compatible?
In my opinion, it is far better to be specific in the device tree and
teach the driver about what versions it is able to bind against. In
this case, I would use "fsl,mpc8610-ssi" or maybe better yet:
"fsl,mpc8610-ssi,i2s" (MPC8610 SSI device in I2S mode).
I don't like the idea of a separate fsl,mode property to describe the
behaviour of multifunction peripherals. It makes probing more
difficult when there is a different driver for each mode.
>
> The fabric driver is specific to the board. So you should be using
> Kconfig to select the fabric driver. There is no node in the device
> tree for fabric drivers. I thought that was the consensus.
No, the desire is to go multiplatform in ppc. That means you cannot
use Kconfig to select the correct fabric driver.
> 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! That is exactly what we want to support in arch/powerpc. Use
platform code to select the correct fabric driver.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Grant Likely @ 2008-01-02 16:32 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, alsa-devel, Timur Tabi
In-Reply-To: <9e4733910801020756p18e12ce8o618b8eae5e7c5a53@mail.gmail.com>
On 1/2/08, Jon Smirl <jonsmirl@gmail.com> wrote:
> On 1/2/08, Timur Tabi <timur@freescale.com> 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_match[] = {
> {
> .compatible = "fsl,MPC8610HPCD",
> },
> {},
> };
>
> But this doesn't work since the root is the device tree isn't passed
> down into the device probe code. (Could this be fixed?)
The driver can always get the root node. But better yet, instantiate
the correct fabric device (probably as a platform_device) from the
platform code. Then the correct fabric driver can probe against it.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Jon Smirl @ 2008-01-02 17:12 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, alsa-devel, Timur Tabi
In-Reply-To: <fa686aa40801020832y373c091dn925bfe64afddcb81@mail.gmail.com>
On 1/2/08, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 1/2/08, Jon Smirl <jonsmirl@gmail.com> wrote:
> > On 1/2/08, Timur Tabi <timur@freescale.com> 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_match[] = {
> > {
> > .compatible = "fsl,MPC8610HPCD",
> > },
> > {},
> > };
> >
> > But this doesn't work since the root is the device tree isn't passed
> > down into the device probe code. (Could this be fixed?)
>
> The driver can always get the root node. But better yet, instantiate
> the correct fabric device (probably as a platform_device) from the
> platform code. Then the correct fabric driver can probe against it.
The meaning of this has finally sunk into my consciousness. The
platform code can create a device that isn't bound to a driver. So why
not make this an of_platform_device? This is basically a pseudo
device that isn't in the device tree.
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 driver has loaded and created the bus. Does the
platform code get control back after loading all of the device
drivers?
In the longer term I'd like to kill platform_bus on powerpc and only
use of_platform_bus. Platform_bus seems to be functioning like a
catch-all and collecting junk from lots of different platforms.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Grant Likely @ 2008-01-02 17:22 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, alsa-devel, Timur Tabi
In-Reply-To: <9e4733910801020912k50dceaebm11b59c1cee571e56@mail.gmail.com>
On 1/2/08, Jon Smirl <jonsmirl@gmail.com> wrote:
> On 1/2/08, Grant Likely <grant.likely@secretlab.ca> wrote:
> > On 1/2/08, Jon Smirl <jonsmirl@gmail.com> wrote:
> > > On 1/2/08, Timur Tabi <timur@freescale.com> 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_match[] = {
> > > {
> > > .compatible = "fsl,MPC8610HPCD",
> > > },
> > > {},
> > > };
> > >
> > > But this doesn't work since the root is the device tree isn't passed
> > > down into the device probe code. (Could this be fixed?)
> >
> > The driver can always get the root node. But better yet, instantiate
> > the correct fabric device (probably as a platform_device) from the
> > platform code. Then the correct fabric driver can probe against it.
>
> The meaning of this has finally sunk into my consciousness. The
> platform code can create a device that isn't bound to a driver. So why
> not make this an of_platform_device? This is basically a pseudo
> device that isn't in the device tree.
Simply because it doesn't have a device node. That's the prime
characteristc that differentiates platform_bus from of_platform_bus.
What do you bind against in of_platform_bus if you don't have a
specific node for it?
> 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 driver has loaded and created the bus. Does the
> platform code get control back after loading all of the device
> drivers?
Yes, but it requires the core ASoC code to not be a module. Then you
can use machine_device_initcall() to register the device at a later
time.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* [PATCH] [POWERPC] Sequoia: typo in calling machine_device_initcall()
From: Grant Likely @ 2008-01-02 17:23 UTC (permalink / raw)
To: jwboyer, linuxppc-dev
From: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
arch/powerpc/platforms/44x/sequoia.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/44x/sequoia.c b/arch/powerpc/platforms/44x/sequoia.c
index 374f8c7..d279db4 100644
--- a/arch/powerpc/platforms/44x/sequoia.c
+++ b/arch/powerpc/platforms/44x/sequoia.c
@@ -38,7 +38,7 @@ static int __init sequoia_device_probe(void)
return 0;
}
-machien_device_initcall(sequoia, sequoia_device_probe);
+machine_device_initcall(sequoia, sequoia_device_probe);
static int __init sequoia_probe(void)
{
^ permalink raw reply related
* Re: [PATCH] [POWERPC] Sequoia: typo in calling machine_device_initcall()
From: Josh Boyer @ 2008-01-02 17:37 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <20080102172356.26645.63895.stgit@trillian.secretlab.ca>
On Wed, 02 Jan 2008 10:23:56 -0700
Grant Likely <grant.likely@secretlab.ca> wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Oh, that's fun... my build scripts say this passed. Looking at
powerpc.sequoia_defconfig.log.passed shows it obviously failed. I hate
it when automated tools suck.
Thanks Grant. Applied to my for-2.6.25 branch
josh
> ---
>
> arch/powerpc/platforms/44x/sequoia.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/platforms/44x/sequoia.c b/arch/powerpc/platforms/44x/sequoia.c
> index 374f8c7..d279db4 100644
> --- a/arch/powerpc/platforms/44x/sequoia.c
> +++ b/arch/powerpc/platforms/44x/sequoia.c
> @@ -38,7 +38,7 @@ static int __init sequoia_device_probe(void)
>
> return 0;
> }
> -machien_device_initcall(sequoia, sequoia_device_probe);
> +machine_device_initcall(sequoia, sequoia_device_probe);
>
> static int __init sequoia_probe(void)
> {
>
^ permalink raw reply
* Re: [PATCH/RFC] Add support for freescale watchdog to CPM serial driver.
From: Scott Wood @ 2008-01-02 17:45 UTC (permalink / raw)
To: Jochen Friedrich; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <477513CC.3060109@scram.de>
On Fri, Dec 28, 2007 at 04:18:36PM +0100, Jochen Friedrich wrote:
> If a freescale watchdog device node is present, reset the watchdog
> while waiting for serial input.
Hmm... I don't like combining the watchdog and serial code together. What
if some other serial device is used with this watchdog? The serial driver
should only have to call an externally provided poke_watchdog() function.
-Scott
^ permalink raw reply
* Re: How to creat a .config file for a driver and How to use it in adevice driver?????
From: Sean MacLennan @ 2008-01-02 17:47 UTC (permalink / raw)
To: Misbah khan; +Cc: linuxppc-dev
In-Reply-To: <14576412.post@talk.nabble.com>
Misbah khan wrote:
> Hi all ...
>
> i am writing a device driver in which the default configuration for LCD
> display i need to keep it in a .config file so that as the system boots it
> take the value from this file and does the initial configuration in the init
> of the driver. If user changes the .config file content in the next boot the
> LCD driver should take the new default configuration
>
> There will also be a run time config which could be changed at the rum time
> but will not change the default configuration.
>
>
> i am writing a LCD driver for PPC arch i need to know that how should i
> creat a .config file and How should i use it my device driver. ??????
>
> If you had an exprience in this regard please do share with me ...
>
> ----Misbah <><
>
You don't. The safe way is to have sane defaults in the driver. Then
write a user mode app that reads the config file and configures the
driver properly, probably through ioctls.
Cheers,
Sean
^ permalink raw reply
* Re: [PATCH] mpc85xx_ads: add in missing of_node_put()
From: Paul Gortmaker @ 2008-01-02 17:50 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20071223095038.ce1ad7a5.sfr@canb.auug.org.au>
In message: Re: [PATCH] mpc85xx_ads: add in missing of_node_put()
on 23/12/2007 Stephen Rothwell wrote:
> On Fri, 21 Dec 2007 10:40:09 -0500 Paul Gortmaker <paul.gortmaker@windriver.com> wrote:
> >
> > cpm2_pic_init() does its own of_node_get() so we should do an of_node_put()
> > before calling it.
>
> The of_node_put() should really go after the call to cpm2_pic_init(), that
> way you retain a raised ref count at all times. Sorry fo not being
> entirely clear before.
No problem. Updated version below.
Thanks,
Paul.
>From eea2826182b4b732ded224240ef9dc89a881ce4b Mon Sep 17 00:00:00 2001
From: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Fri, 21 Dec 2007 10:12:38 -0500
Subject: [PATCH] mpc85xx_ads: add in missing of_node_put()
Add in missing of_node_put() after cpm2_pic_init(). This and other coding
style cleanups as suggested by Stephen Rothwell.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
arch/powerpc/platforms/85xx/mpc85xx_ads.c | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ads.c b/arch/powerpc/platforms/85xx/mpc85xx_ads.c
index bccdc25..91781a9 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_ads.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_ads.c
@@ -52,9 +52,9 @@ static void cpm2_cascade(unsigned int irq, struct irq_desc *desc)
{
int cascade_irq;
- while ((cascade_irq = cpm2_get_irq()) >= 0) {
+ while ((cascade_irq = cpm2_get_irq()) >= 0)
generic_handle_irq(cascade_irq);
- }
+
desc->chip->eoi(irq);
}
@@ -70,13 +70,12 @@ static void __init mpc85xx_ads_pic_init(void)
#endif
np = of_find_node_by_type(np, "open-pic");
-
- if (np == NULL) {
+ if (!np) {
printk(KERN_ERR "Could not find open-pic node\n");
return;
}
- if(of_address_to_resource(np, 0, &r)) {
+ if (of_address_to_resource(np, 0, &r)) {
printk(KERN_ERR "Could not map mpic register space\n");
of_node_put(np);
return;
@@ -100,6 +99,7 @@ static void __init mpc85xx_ads_pic_init(void)
irq = irq_of_parse_and_map(np, 0);
cpm2_pic_init(np);
+ of_node_put(np);
set_irq_chained_handler(irq, cpm2_cascade);
#endif
}
@@ -112,7 +112,7 @@ struct cpm_pin {
int port, pin, flags;
};
-static struct cpm_pin mpc8560_ads_pins[] = {
+static const struct cpm_pin mpc8560_ads_pins[] = {
/* SCC1 */
{3, 29, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
{3, 30, CPM_PIN_OUTPUT | CPM_PIN_SECONDARY},
--
1.5.0.rc1.gf4b6c
^ permalink raw reply related
* Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Mark Brown @ 2008-01-02 17:23 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <477BA974.8010308@freescale.com>
On Wed, Jan 02, 2008 at 09:10:44AM -0600, Timur Tabi wrote:
> Jon Smirl wrote:
> > Does this need to be bus-frequency? It's always called MCLK in all of
> > the literature.
> I'm trying to make this node as generic as possible. The fabric driver
> is the one that will parse this node and pass the data to the codec
> driver, so I can't use any codec-specific terms.
> The API from the fabric driver for passing clock information includes a
> clock ID, a direction, and a frequency. I can do something like this:
> clock1 = <0, bb8000>
> Would that be better?
To cover everything you'd need to be able to specify all the clocking
parameters, especially a PLL configuration, and also specify more than
one of each item. Even then you'd still have problems like...
> > In my case the MCLK comes from a chip on the i2c bus that is
> > programmable How would that be encoded?.
> I'm going under the assumption that MCLK does not change once the board
> is up and running. In your case, you'd need to do something quite
> different, because you're not reading the clock info from the device
> tree and passing it to the codec at initialization once. If you want to
> define an extension to the 'codec' child node that handles that, I'll
> add it to the documentation.
According to the documentation in your patch the bus frequency should
already be optional (though I don't immediately see that in the code,
but then I'm entirely unfamiliar with OpenFirmware device trees).
Boards that reconfigure the clocking at run time can then provide
code to set the clocking up at the appropriate times, which is probably
what they want anyway.
^ permalink raw reply
* Re: [2.6.24 patch] Fix Cell OProfile support
From: Mathieu Desnoyers @ 2008-01-02 17:47 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Randy Dunlap, phil.el, linux-kernel, linuxppc-dev, paulus,
oprofile-list, Adrian Bunk
In-Reply-To: <200712311710.08869.arnd@arndb.de>
* Arnd Bergmann (arnd@arndb.de) wrote:
> On Saturday 29 December 2007, Mathieu Desnoyers wrote:
> > This patch restores the Cell OProfile support that was killed by
> > commit 09cadedbdc01f1a4bea1f427d4fb4642eaa19da9.
> >
> > It puts it in arch/powerpc/Kconfig. Since I don't see any good reason to leave
> > this as a supplementary user-selectable option, it is now automatically enabled
> > whenever SPU_FS and OPROFILE are enabled.
>
> This one has already been superceded by the fix in
> aed3a8c9bb1a8623a618232087c5ff62718e3b9a, which made CONFIG_OPROFILE_CELL an
> automatically selected option, from arch/powerpc/platforms/cell/Kconfig.
>
Great, so my patch should be dropped. Thanks!
Mathieu
> Arnd <><
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
^ permalink raw reply
* Re: Differences between git tree
From: Jon Loeliger @ 2008-01-02 18:04 UTC (permalink / raw)
To: Bizhan Gholikhamseh (bgholikh); +Cc: linuxppc-embedded@ozlabs.org
In-Reply-To: <F795765B112E7344AF36AA911279641502D1A907@xmb-sjc-212.amer.cisco.com>
On Thu, 2007-12-20 at 07:11, Bizhan Gholikhamseh (bgholikh) wrote:
> Hi,
> Could someone let me know what is the each of these git tree are?
>
> http://opensource.freescale.com/pub/scm/linux-2.6-jdl.git
> AND
> http://www.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git
Hrm. I suppose I should answer that one...
Use Paul's tree from kernel.org.
My tree on opensource.freescale.com was my random patches
and crud, being published so others could get a hold of them.
Anything of value there has been moved or integrated into
Paul or Linus' tree by now.
HTH,
jdl
^ permalink raw reply
* Re: [PATCH/RFC] powerpc: DBox2 Board Support
From: Scott Wood @ 2008-01-02 18:06 UTC (permalink / raw)
To: Jochen Friedrich; +Cc: linuxppc-dev
In-Reply-To: <476D61DB.2090201@scram.de>
On Sat, Dec 22, 2007 at 08:13:31PM +0100, Jochen Friedrich wrote:
> + gtx@0 {
> + compatible = "c-cube,gtx";
> + reg = <400000 3000 0 200000>;
> + interrupts = <2 2>;
> + interrupt-parent = <&PIC>;
> + };
> +
> + fp@0 {
> + compatible = "betaresearch,dbox2-fp";
> + interrupts = <4 2>;
> + interrupt-parent = <&PIC>;
> + gpios = <0 e>;
> + gpio-parent = <&CPM1_PIO>;
> + };
> +
> + fe@0 {
> + compatible = "betaresearch,dbox2-fe";
> + interrupts = <e 2>;
> + interrupt-parent = <&PIC>;
> + };
These unit addresses look wrong.
> + cam@4000000 {
> + compatible = "betaresearch,dbox2-cam";
> + reg = <4000000 20000>;
> + interrupts = <6 2>;
> + interrupt-parent = <&PIC>;
> + gpios = <1 1c 1 1d 1 1e 1 1f>;
> + gpio-parent = <&CPM1_PIO>;
> + };
> +
> + cam@4040000 {
> + compatible = "betaresearch,dbox2-cam";
> + reg = <4040000 20000>;
> + interrupts = <6 2>;
> + interrupt-parent = <&PIC>;
> + gpios = <1 1c 1 1d 1 1e 1 1f>;
> + gpio-parent = <&CPM1_PIO>;
> + };
Maybe gpios should have a length field? Or maybe we should just
phandle to a separate node under the gpio controller node. What happens if
a device sits on two different gpio-parents?
> + flash@8000000 {
> + // Flash also has info about model needed by setup
> + compatible = "cfi-flash",
> + "betaresearch,dbox2-config";
What does dbox2-config mean?
> + ovpartition@20000 {
> + label = "Flash without bootloader";
> + reg = <20000 7e0000>;
> + };
> + ovpartition@0 {
> + label = "Complete Flash";
> + reg = <0 800000>;
> + read-only;
> + };
What is "ovpartition"?
> + wdt@0 {
> + device_type = "watchdog";
> + compatible = "fsl,mpc823-wdt",
> + "fsl,pq1-wdt";
> + reg = <0 10>;
> + };
No device_type.
> + cpm@9c0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> + reg = <9c0 40>;
> + command-proc = <9c0>;
command-proc is obsolete.
> + muram@2000 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 2000 2000>;
> +
> + data@0 {
> + compatible = "fsl,cpm-muram-data";
> + reg = <0 1c00>;
> + };
> + };
Should have compatible of fsl,cpm-muram on the muram node as well, even
though the current code doesn't use it.
> + // Port D is LCD exclusive. Don't export as GPIO
> + CPM1_PIO: pio@970 {
> + compatible = "fsl,cpm1-pario";
> + reg = <970 180>;
> + num-ports = <3>;
> + #gpio-cells = <2>;
> + };
Why are we doing things differently just because all of the pins on this
port happen to be directed to one device? If it's because the Linux GPIO
API sucks, then either fix the API, or work around the suckage in software,
not the device tree.
> + lcd@970 {
> + reg = <970 10>;
> + compatible = "samsung,ks0713";
> + };
So some driver that matches on samsung,ks0713 has to know the details of the
mpc8xx GPIO registers?
> + brg@9f0 {
> + compatible = "fsl,mpc823-brg",
> + "fsl,cpm1-brg",
> + "fsl,cpm-brg";
> + reg = <9f0 10>;
> + };
Should have clock-frequency in the brg node.
> + i2c@860 {
> + compatible = "fsl,mpc823-i2c",
> + "fsl,cpm1-i2c",
> + "fsl,cpm-i2c";
> + reg = <860 20 3c80 30>;
> + interrupts = <10 3>;
> + interrupt-parent = <&CPM_PIC>;
> + fsl,cpm-command = <0010>;
> + };
Should have #address-cells and #size-cells.
> +enum dbox2_mid dbox2_get_mid(void)
> +{
> + return dbox2_manuf_id;
> +}
> +EXPORT_SYMBOL_GPL(dbox2_get_mid);
Honestly, you're claiming derived-work status by calling a function that
returns an integer, that was read directly from hardware?
> + if (dbox2_manuf_id == DBOX2_MID_NOKIA)
> + np = of_find_node_by_path("/localbus@8000000/enx@0");
> + else
> + np = of_find_node_by_path("/localbus@8000000/gtx@0");
> +
> + if (np) {
> + of_detach_node(np);
> + of_node_put(np);
> + }
> +
> + if (dbox2_manuf_id == DBOX2_MID_PHILIPS)
> + np = of_find_node_by_path("/localbus@8000000/cam@4000000");
> + else
> + np = of_find_node_by_path("/localbus@8000000/cam@4040000");
> +
> + if (np) {
> + of_detach_node(np);
> + of_node_put(np);
> + }
> +}
I'd use separate device trees (I only did this kind of thing in mpc885ads
because it's dip-switchable), but whatever...
> diff --git a/include/asm-powerpc/mpc8xx.h b/include/asm-powerpc/mpc8xx.h
> index 2be014b..b6fd7d6 100644
> --- a/include/asm-powerpc/mpc8xx.h
> +++ b/include/asm-powerpc/mpc8xx.h
> @@ -23,6 +23,10 @@
> #include <platforms/8xx/mpc885ads.h>
> #endif
>
> +#if defined(CONFIG_DBOX2)
> +#include <platforms/8xx/dbox2.h>
> +#endif
This shouldn't be needed.
-Scott
^ permalink raw reply
* Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Scott Wood @ 2008-01-02 18:08 UTC (permalink / raw)
To: Timur Tabi; +Cc: Olof Johansson, linuxppc-dev, alsa-devel
In-Reply-To: <476DCECD.6040008@freescale.com>
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,mpc8641"
Yes.
> That looks a lot like what a compatible entry for the CPU should be.
I guess technically the cpu should list something like fsl,e600 (or
whatever suffix is relevant).
-Scott
^ permalink raw reply
* Re: [PATCH v2] ucc_uart: add support for Freescale QUICCEngine UART
From: Scott Wood @ 2008-01-02 18:12 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <4776C5EE.70004@freescale.com>
On Sat, Dec 29, 2007 at 04:10:54PM -0600, Timur Tabi wrote:
> Anton Vorontsov wrote:
>
> >> + ucc@2400 {
> >> + device_type = "serial";
> >> + compatible = "ucc_uart";
> >> + model = "UCC";
> >
> > model isn't used, is it needed at all?
>
> I have no idea, but all the other UCC nodes have it, so I'm going to
> keep it. Maybe one day we'll merge QE and CPM drivers, so this would be
> useful.
No, it wouldn't -- that's what compatible is for.
> >> +static struct of_platform_driver ucc_uart_of_driver = {
> >> + .owner = THIS_MODULE,
> >> + .name = "ucc_uart",
> >
> > Maybe better fsl,ucc_uart?
fsl,qe-uart is defined by Documentation/powerpc/booting-without-of.txt.
> The CPM serial driver uses "cpm_uart" and the QE ethernet driver uses
> "ucc_geth", so ucc_uart matches the pattern.
cpm_uart is a legacy match -- the current binding specifies
fsl,cpm1-smc-uart, fsl,cpm2-scc-uart, etc.
-Scott
^ permalink raw reply
* Re:
From: rsa @ 2008-01-02 18:16 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 6 bytes --]
What?
[-- Attachment #2: Original Message.B64 --]
[-- Type: application/x-msdownload, Size: 134041 bytes --]
^ permalink raw reply
* Outstanding DTC patches?
From: Jon Loeliger @ 2008-01-02 18:21 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
Folks,
I'd like to release a DTC 1.1 Real Soon Now!
However, I've been back-logged due to the holidays.
If you have any outstanding DTC or libfdt patches
that I have not yet applied and that you would like
in that release, please remind me by reposting it
and CC:'ing jdl@jdl.com!
Thanks!
jdl
^ permalink raw reply
* [PATCH] [POWERPC] pasemi: Fix NMI handling check
From: Olof Johansson @ 2008-01-02 18:45 UTC (permalink / raw)
To: linuxppc-dev
[POWERPC] pasemi: Fix NMI handling check
The logic that checks to see if a machine check is caused by an NMI will
always match when NMI hasn't been initialized, since the mpic routine
will return NO_IRQ (and that's what the nmi_virq value is as well).
Signed-off-by: Olof Johansson <olof@lixom.net>
diff --git a/arch/powerpc/platforms/pasemi/setup.c b/arch/powerpc/platforms/pasemi/setup.c
index 1940e67..a89d098 100644
--- a/arch/powerpc/platforms/pasemi/setup.c
+++ b/arch/powerpc/platforms/pasemi/setup.c
@@ -264,7 +264,7 @@ static int pas_machine_check_handler(struct pt_regs *regs)
srr0 = regs->nip;
srr1 = regs->msr;
- if (mpic_get_mcirq() == nmi_virq) {
+ if (nmi_virq != NO_IRQ && mpic_get_mcirq() == nmi_virq) {
printk(KERN_ERR "NMI delivered\n");
debugger(regs);
mpic_end_irq(nmi_virq);
^ permalink raw reply related
* Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Jon Smirl @ 2008-01-02 18:43 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, alsa-devel, Timur Tabi
In-Reply-To: <fa686aa40801020922q6fbda176l5fc7c80b5e61281f@mail.gmail.com>
On 1/2/08, Grant Likely <grant.likely@secretlab.ca> 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 driver has loaded and created the bus. Does the
> > platform code get control back after loading all of the device
> > drivers?
>
> Yes, but it requires the core ASoC code to not be a module. Then you
> can use machine_device_initcall() to register the device at a later
> time.
How about this for a simpler solution? My mpc5200-psc-ac97 and
mpc5200-psc-i2c drivers can create a device on the ASOC bus named
after the first entry in the compatible field of the root node. That
will cause the correct driver to get activated. I'm in the process of
making ASOC drivers dynamically loadable like the i2c ones.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox