* Re: [patch v4 0/4] Cypress c67x00 (EZ-Host/EZ-OTG) support
From: Peter Korsgaard @ 2008-01-21 21:13 UTC (permalink / raw)
To: Grant Likely; +Cc: David Brownell, linuxppc-dev, linux-usb
In-Reply-To: <fa686aa40801211214u31581036m2ea2cf11d82c3f75@mail.gmail.com>
>>>>> "Grant" == Grant Likely <grant.likely@secretlab.ca> writes:
Hi,
Grant> My v1, v2 and v3 postings were based on Peter's work from about a year
Grant> ago. I picked up the driver because Peter didn't have any time to
Grant> work on it.
Ack.
Grant> Peter told me last week that this series merges the v3 patches with
Grant> work that he's done recently now that he has some time to do so again.
Grant> However, I don't know what the diff is between v3 and this new
Grant> series. I've also not done a full review, so I cannot make any
Grant> comment at this time.
I would be grateful if you would find a bit of time to skim over it -
I'll post a diff between v3 and v4-without-the-gadget-part in a
moment.
Grant> Personally, I'd prefer to see the v3 series picked up now (as I
Grant> believe all outstanding comments from the list have been addressed)
Grant> and have new patches build on top of that, but that's just my
Grant> preference.
That's understandable; I would ofcause prefer to see v4 selected instead
to get the cleanups and fixes and because the in-progress gadget work
is based on it.
But anyway, that's details - Most of all I would like to see c67x00
support in mainline, one way or another. Most of the work has been
sitting on my hard drive gathering dust since spring 2006.
--
Bye, Peter Korsgaard
^ permalink raw reply
* [PATCH] mpc i2c driver, compare to NO_IRQ instead of zero
From: Jon Smirl @ 2008-01-21 20:07 UTC (permalink / raw)
To: i2c, linuxppc-dev
Alter the mpc i2c driver to use the NO_IRQ symbol instead of the constant zero when checking for valid interrupts. NO_IRQ=-1 on ppc and NO_IRQ=0 on powerpc so the checks against zero are not correct.
Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
---
drivers/i2c/busses/i2c-mpc.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index bbe787b..d20959d 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -99,7 +99,7 @@ static int i2c_wait(struct mpc_i2c *i2c, unsigned timeout, int writing)
u32 x;
int result = 0;
- if (i2c->irq == 0)
+ if (i2c->irq == NO_IRQ)
{
while (!(readb(i2c->base + MPC_I2C_SR) & CSR_MIF)) {
schedule();
@@ -329,7 +329,7 @@ static int fsl_i2c_probe(struct platform_device *pdev)
return -ENOMEM;
i2c->irq = platform_get_irq(pdev, 0);
- if (i2c->irq < 0) {
+ if (i2c->irq < NO_IRQ) {
result = -ENXIO;
goto fail_get_irq;
}
@@ -344,7 +344,7 @@ static int fsl_i2c_probe(struct platform_device *pdev)
goto fail_map;
}
- if (i2c->irq != 0)
+ if (i2c->irq != NO_IRQ)
if ((result = request_irq(i2c->irq, mpc_i2c_isr,
IRQF_SHARED, "i2c-mpc", i2c)) < 0) {
printk(KERN_ERR
@@ -367,7 +367,7 @@ static int fsl_i2c_probe(struct platform_device *pdev)
return result;
fail_add:
- if (i2c->irq != 0)
+ if (i2c->irq != NO_IRQ)
free_irq(i2c->irq, i2c);
fail_irq:
iounmap(i2c->base);
@@ -384,7 +384,7 @@ static int fsl_i2c_remove(struct platform_device *pdev)
i2c_del_adapter(&i2c->adap);
platform_set_drvdata(pdev, NULL);
- if (i2c->irq != 0)
+ if (i2c->irq != NO_IRQ)
free_irq(i2c->irq, i2c);
iounmap(i2c->base);
^ permalink raw reply related
* Re: [patch v4 0/4] Cypress c67x00 (EZ-Host/EZ-OTG) support
From: Peter Korsgaard @ 2008-01-21 21:08 UTC (permalink / raw)
To: David Brownell; +Cc: linuxppc-dev, linux-usb
In-Reply-To: <200801211201.41142.david-b@pacbell.net>
>>>>> "David" == David Brownell <david-b@pacbell.net> writes:
Hi,
David> How does this relate to the "v3" patches posted 8-Jan by Grant Likely?
David> Is that the "v3" you were referring to?
Yes - Sorry, I should have been more clear about that.
David> It's confusing to see two different people submit two sets of
David> patches for the same driver, without any evident
David> coordination...
True. The story behind it is that I posted the original patch series
back in Spring '06, but real life got in way of me following up on
pushing it to mainline (some development was still done on it, and
we've shipped it in products).
Then Grant picked it up (which I'm grateful for) and posted his v1..v3
series. I have now taken his v3 series and merged it with my
development.
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [patch v4 0/4] Cypress c67x00 (EZ-Host/EZ-OTG) support
From: Grant Likely @ 2008-01-21 20:53 UTC (permalink / raw)
To: David Brownell; +Cc: linux-usb, linuxppc-dev
In-Reply-To: <200801211251.02288.david-b@pacbell.net>
On 1/21/08, David Brownell <david-b@pacbell.net> wrote:
> On Monday 21 January 2008, Peter Korsgaard wrote:
> > Sure, http://peter.korsgaard.com/c67x00-v3-v4.patch (not posting as
> > it's more than 100k)
>
> I like this bit:
>
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -3832,6 +3832,12 @@ L: linux-usb@vger.kernel.org
> > S: Maintained
> > W: http://www.kroah.com/linux-usb/
> >
> > +USB CYPRESS C67X00 DRIVER
> > +P: Peter Korsgaard
> > +M: jacmet@sunsite.dk
> > +L: linux-usb@vger.kernel.org
> > +S: Maintained
> > +
> > USB DAVICOM DM9601 DRIVER
> > P: Peter Korsgaard
> > M: jacmet@sunsite.dk
>
> :)
>
> Grant, please let us know if you see anything to object to in
> this "v4" patch (parts 1..3 only). At a quick glance, I didn't
> see any ... other than stuff associated with peripheral mode
> support, which isn't yet proposed for merging. So for the
> moment it looks like v4 is the one to review (and maybe merge).
np. Hopefully in the next day or so I'll get to spend some quality
time with this diff.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [patch v4 0/4] Cypress c67x00 (EZ-Host/EZ-OTG) support
From: David Brownell @ 2008-01-21 20:51 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: linuxppc-dev, linux-usb
In-Reply-To: <87zluz0w9g.fsf@macbook.be.48ers.dk>
On Monday 21 January 2008, Peter Korsgaard wrote:
> Sure, http://peter.korsgaard.com/c67x00-v3-v4.patch (not posting as
> it's more than 100k)
I like this bit:
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3832,6 +3832,12 @@ L: linux-usb@vger.kernel.org
> S: Maintained
> W: http://www.kroah.com/linux-usb/
>
> +USB CYPRESS C67X00 DRIVER
> +P: Peter Korsgaard
> +M: jacmet@sunsite.dk
> +L: linux-usb@vger.kernel.org
> +S: Maintained
> +
> USB DAVICOM DM9601 DRIVER
> P: Peter Korsgaard
> M: jacmet@sunsite.dk
:)
Grant, please let us know if you see anything to object to in
this "v4" patch (parts 1..3 only). At a quick glance, I didn't
see any ... other than stuff associated with peripheral mode
support, which isn't yet proposed for merging. So for the
moment it looks like v4 is the one to review (and maybe merge).
- Dave
^ permalink raw reply
* [PATCH] [NET] cpmac: convert to new Fixed PHY infrastructure (was: Re: fixed phy support (warning related to FIXED_MII_100_FDX))
From: Anton Vorontsov @ 2008-01-21 20:49 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list, Eugene Konev, Jeff Garzik, netdev
In-Reply-To: <416B8C5D-109C-4C03-807D-7EBB0AA9C366@kernel.crashing.org>
On Mon, Jan 21, 2008 at 01:19:41PM -0600, Kumar Gala wrote:
> Anton,
>
> it looks like the "TI AR7 CPMAC Ethernet support" uses FIXED_PHY and
> was selecting FIXED_MII_100_FDX which is gone.
>
> Can you look into this. I get the following warning now:
>
> scripts/kconfig/conf -s arch/powerpc/Kconfig
> drivers/net/Kconfig:1713:warning: 'select' used by config symbol
> 'CPMAC' refers to undefined symbol 'FIXED_MII_100_FDX'
Wow. I thought there were no Fixed PHY users. :-)
Jeff, as you've already Acked Fixed PHY rework to go through powerpc
tree, would you please Ack this patch in addition? I hope cpmac
maintainer will fix remaining issues as time goes by.
Thanks!
- - - -
From: Anton Vorontsov <avorontsov@ru.mvista.com>
Subject: [PATCH] [NET] cpmac: convert to new Fixed PHY infrastructure
This patch converts cpmac to the new Fixed PHY infrastructure, though it
doesn't fix all the problems with that driver. I didn't even bother to
test this patch to compile, because cpmac driver is broken in several ways:
1. This driver won't compile by itself because lack of its header describing
platform data;
2. It assumes that fixed PHYs should be created by the ethernet driver.
It is wrong assumption: fixed PHYs creation is platform code authority,
driver must blindly accept bus_id and phy_id platform data variables
instead.
Also, it seem that that driver doesn't have actual in-tree users, so
nothing to fix further.
The main purpose of that patch is to get rid of the following Kconfig
warning:
scripts/kconfig/conf -s arch/powerpc/Kconfig
drivers/net/Kconfig:1713:warning: 'select' used by config symbol
'CPMAC' refers to undefined symbol 'FIXED_MII_100_FDX'
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/net/Kconfig | 4 +--
drivers/net/cpmac.c | 55 ++++++++++++++++----------------------------------
2 files changed, 19 insertions(+), 40 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 114771a..5380ff9 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -1707,10 +1707,8 @@ config SC92031
config CPMAC
tristate "TI AR7 CPMAC Ethernet support (EXPERIMENTAL)"
- depends on NET_ETHERNET && EXPERIMENTAL && AR7
+ depends on NET_ETHERNET && EXPERIMENTAL && AR7 && BROKEN
select PHYLIB
- select FIXED_PHY
- select FIXED_MII_100_FDX
help
TI AR7 CPMAC Ethernet support
diff --git a/drivers/net/cpmac.c b/drivers/net/cpmac.c
index 6fd95a2..88eeb1d 100644
--- a/drivers/net/cpmac.c
+++ b/drivers/net/cpmac.c
@@ -848,15 +848,6 @@ static void cpmac_adjust_link(struct net_device *dev)
spin_unlock(&priv->lock);
}
-static int cpmac_link_update(struct net_device *dev,
- struct fixed_phy_status *status)
-{
- status->link = 1;
- status->speed = 100;
- status->duplex = 1;
- return 0;
-}
-
static int cpmac_open(struct net_device *dev)
{
int i, size, res;
@@ -999,11 +990,11 @@ static int external_switch;
static int __devinit cpmac_probe(struct platform_device *pdev)
{
int rc, phy_id, i;
+ int mdio_bus_id = cpmac_mii.id;
struct resource *mem;
struct cpmac_priv *priv;
struct net_device *dev;
struct plat_cpmac_data *pdata;
- struct fixed_info *fixed_phy;
DECLARE_MAC_BUF(mac);
pdata = pdev->dev.platform_data;
@@ -1017,9 +1008,23 @@ static int __devinit cpmac_probe(struct platform_device *pdev)
}
if (phy_id == PHY_MAX_ADDR) {
- if (external_switch || dumb_switch)
+ if (external_switch || dumb_switch) {
+ struct fixed_phy_status status = {};
+
+ mdio_bus_id = 0;
+
+ /*
+ * FIXME: this should be in the platform code!
+ * Since there is not platform code at all (that is,
+ * no mainline users of that driver), place it here
+ * for now.
+ */
phy_id = 0;
- else {
+ status.link = 1;
+ status.duplex = 1;
+ status.speed = 100;
+ fixed_phy_add(PHY_POLL, phy_id, &status);
+ } else {
printk(KERN_ERR "cpmac: no PHY present\n");
return -ENODEV;
}
@@ -1063,32 +1068,8 @@ static int __devinit cpmac_probe(struct platform_device *pdev)
priv->msg_enable = netif_msg_init(debug_level, 0xff);
memcpy(dev->dev_addr, pdata->dev_addr, sizeof(dev->dev_addr));
- if (phy_id == 31) {
- snprintf(priv->phy_name, BUS_ID_SIZE, PHY_ID_FMT, cpmac_mii.id,
- phy_id);
- } else {
- /* Let's try to get a free fixed phy... */
- for (i = 0; i < MAX_PHY_AMNT; i++) {
- fixed_phy = fixed_mdio_get_phydev(i);
- if (!fixed_phy)
- continue;
- if (!fixed_phy->phydev->attached_dev) {
- strncpy(priv->phy_name,
- fixed_phy->phydev->dev.bus_id,
- BUS_ID_SIZE);
- fixed_mdio_set_link_update(fixed_phy->phydev,
- &cpmac_link_update);
- goto phy_found;
- }
- }
- if (netif_msg_drv(priv))
- printk(KERN_ERR "%s: Could not find fixed PHY\n",
- dev->name);
- rc = -ENODEV;
- goto fail;
- }
+ snprintf(priv->phy_name, BUS_ID_SIZE, PHY_ID_FMT, mdio_bus_id, phy_id);
-phy_found:
priv->phy = phy_connect(dev, priv->phy_name, &cpmac_adjust_link, 0,
PHY_INTERFACE_MODE_MII);
if (IS_ERR(priv->phy)) {
--
1.5.2.2
^ permalink raw reply related
* Re: [PATCH] autodetect serial console on efika
From: Grant Likely @ 2008-01-21 20:38 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, Paul Mackeras
In-Reply-To: <20080121203459.GA9967@aepfle.de>
On 1/21/08, Olaf Hering <olaf@aepfle.de> wrote:
> On Mon, Jan 21, Grant Likely wrote:
>
> > On 1/21/08, Olaf Hering <olaf@aepfle.de> wrote:
> > >
> > > Efika boards have to be booted with console=ttyPSC0 unless there is a
> > > graphics card plugged in. Detect if the firmware stdout is the serial
> > > connector.
> > >
> > > Signed-off-by: Olaf Hering <olaf@aepfle.de>
> >
> > Hrrrum; I think this is a good idea, but I'm not thrilled with the
> > approach. Here are my concerns:
> >
> > - Determining that linux,stdout-path points to a PSC should should be
> > done in common code. It's useful for all 5200 boards, not just the
> > Efika. (However, if 'failsafe' processing is efika specific, then it
> > can stay in efika.c). This might be best done within the PSC driver
> > itself, but I'm not sure.
> > - Recognizing a psc node should be done by inspecting the compatible
> > property, not by device_type and model properties.
>
> I dont have any other 5200 hardware to test a different patch.
> Please improve my version and submit it for inclusion.
Heh; that's okay, I and others can test on other hardware; but it's
still appropriate for you to move the matching code into the PSC
driver proper. Otherwise, getting it in to mainline for 2.6.25
depends on how much time I get free in the next 2 weeks.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] autodetect serial console on efika
From: Olaf Hering @ 2008-01-21 20:34 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Paul Mackeras
In-Reply-To: <fa686aa40801211045w7644cfc5tf11024bd0010b308@mail.gmail.com>
On Mon, Jan 21, Grant Likely wrote:
> On 1/21/08, Olaf Hering <olaf@aepfle.de> wrote:
> >
> > Efika boards have to be booted with console=ttyPSC0 unless there is a
> > graphics card plugged in. Detect if the firmware stdout is the serial
> > connector.
> >
> > Signed-off-by: Olaf Hering <olaf@aepfle.de>
>
> Hrrrum; I think this is a good idea, but I'm not thrilled with the
> approach. Here are my concerns:
>
> - Determining that linux,stdout-path points to a PSC should should be
> done in common code. It's useful for all 5200 boards, not just the
> Efika. (However, if 'failsafe' processing is efika specific, then it
> can stay in efika.c). This might be best done within the PSC driver
> itself, but I'm not sure.
> - Recognizing a psc node should be done by inspecting the compatible
> property, not by device_type and model properties.
I dont have any other 5200 hardware to test a different patch.
Please improve my version and submit it for inclusion.
^ permalink raw reply
* Re: [patch v4 0/4] Cypress c67x00 (EZ-Host/EZ-OTG) support
From: Peter Korsgaard @ 2008-01-21 20:16 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, dbrownell, linux-usb
In-Reply-To: <fa686aa40801210911q4ce90816tebafa46e68a3f980@mail.gmail.com>
>>>>> "Grant" == Grant Likely <grant.likely@secretlab.ca> writes:
Hi,
>> Changes since v3:
>> - Lots of cleanups: checkpatch, interrupt handling, c67x00_ prefixes, ..
>> - The dummy platform_device's created per serial engine are gone.
>> - Gadget driver (WIP)
Grant> Can you please post/publish the diff between v3 and this series?
Sure, http://peter.korsgaard.com/c67x00-v3-v4.patch (not posting as
it's more than 100k)
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [patch v4 0/4] Cypress c67x00 (EZ-Host/EZ-OTG) support
From: Grant Likely @ 2008-01-21 20:14 UTC (permalink / raw)
To: David Brownell; +Cc: linux-usb, linuxppc-dev
In-Reply-To: <200801211201.41142.david-b@pacbell.net>
On 1/21/08, David Brownell <david-b@pacbell.net> wrote:
> On Monday 21 January 2008, Peter Korsgaard wrote:
> > The Cypress c67x00 (EZ-Host/EZ-OTG) controllers are multi-role low/fullspeed
> > USB controllers. This patch series implements a HCD driver and shows the
> > work-in-progress status of a gadget driver.
> >
> > I believe patch 1..3 are ready, and I would like to see queued up for 2.6.25.
> >
> > Changes since v3:
> > - Lots of cleanups: checkpatch, interrupt handling, c67x00_ prefixes, ..
> > - The dummy platform_device's created per serial engine are gone.
> > - Gadget driver (WIP)
> >
> > Comments are very much appreciated.
>
> How does this relate to the "v3" patches posted 8-Jan by Grant Likely?
> Is that the "v3" you were referring to?
My v1, v2 and v3 postings were based on Peter's work from about a year
ago. I picked up the driver because Peter didn't have any time to
work on it.
Peter told me last week that this series merges the v3 patches with
work that he's done recently now that he has some time to do so again.
However, I don't know what the diff is between v3 and this new
series. I've also not done a full review, so I cannot make any
comment at this time.
Personally, I'd prefer to see the v3 series picked up now (as I
believe all outstanding comments from the list have been addressed)
and have new patches build on top of that, but that's just my
preference.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH] Convert pfc8563 i2c driver from old style to new style
From: Jon Smirl @ 2008-01-21 20:09 UTC (permalink / raw)
To: i2c, linuxppc-dev
Convert pfc8563 i2c driver from old style to new style.
Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
---
drivers/rtc/rtc-pcf8563.c | 107 +++++++++++----------------------------------
1 files changed, 27 insertions(+), 80 deletions(-)
diff --git a/drivers/rtc/rtc-pcf8563.c b/drivers/rtc/rtc-pcf8563.c
index b3317fc..8eff549 100644
--- a/drivers/rtc/rtc-pcf8563.c
+++ b/drivers/rtc/rtc-pcf8563.c
@@ -25,10 +25,6 @@
* located at 0x51 will pass the validation routine due to
* the way the registers are implemented.
*/
-static const unsigned short normal_i2c[] = { I2C_CLIENT_END };
-
-/* Module parameters */
-I2C_CLIENT_INSMOD;
#define PCF8563_REG_ST1 0x00 /* status */
#define PCF8563_REG_ST2 0x01
@@ -72,9 +68,6 @@ struct pcf8563 {
int c_polarity; /* 0: MO_C=1 means 19xx, otherwise MO_C=1 means 20xx */
};
-static int pcf8563_probe(struct i2c_adapter *adapter, int address, int kind);
-static int pcf8563_detach(struct i2c_client *client);
-
/*
* In the routines that deal directly with the pcf8563 hardware, we use
* rtc_time -- month 0-11, hour 0-23, yr = calendar year-epoch.
@@ -257,98 +250,52 @@ static const struct rtc_class_ops pcf8563_rtc_ops = {
.set_time = pcf8563_rtc_set_time,
};
-static int pcf8563_attach(struct i2c_adapter *adapter)
+static int pcf8563_remove(struct i2c_client *client)
{
- return i2c_probe(adapter, &addr_data, pcf8563_probe);
+ struct rtc_device *rtc = i2c_get_clientdata(client);
+
+ if (rtc)
+ rtc_device_unregister(rtc);
+
+ return 0;
}
+static struct i2c_device_id pcf8563_id[] = {
+ {"pcf8563", 0},
+ {"rtc8564", 0},
+ {},
+};
+MODULE_DEVICE_TABLE(i2c, pcf8563_id);
+
+static int pcf8563_probe(struct i2c_client *client, const struct i2c_device_id *id);
+
static struct i2c_driver pcf8563_driver = {
.driver = {
- .name = "pcf8563",
+ .name = "rtc-pcf8563",
},
.id = I2C_DRIVERID_PCF8563,
- .attach_adapter = &pcf8563_attach,
- .detach_client = &pcf8563_detach,
+ .probe = &pcf8563_probe,
+ .remove = &pcf8563_remove,
+ .id_table = pcf8563_id,
};
-static int pcf8563_probe(struct i2c_adapter *adapter, int address, int kind)
+static int pcf8563_probe(struct i2c_client *client, const struct i2c_device_id *id)
{
- struct pcf8563 *pcf8563;
- struct i2c_client *client;
+ int result;
struct rtc_device *rtc;
- int err = 0;
-
- dev_dbg(&adapter->dev, "%s\n", __FUNCTION__);
-
- if (!i2c_check_functionality(adapter, I2C_FUNC_I2C)) {
- err = -ENODEV;
- goto exit;
- }
-
- if (!(pcf8563 = kzalloc(sizeof(struct pcf8563), GFP_KERNEL))) {
- err = -ENOMEM;
- goto exit;
- }
-
- client = &pcf8563->client;
- client->addr = address;
- client->driver = &pcf8563_driver;
- client->adapter = adapter;
-
- strlcpy(client->name, pcf8563_driver.driver.name, I2C_NAME_SIZE);
-
- /* Verify the chip is really an PCF8563 */
- if (kind < 0) {
- if (pcf8563_validate_client(client) < 0) {
- err = -ENODEV;
- goto exit_kfree;
- }
- }
-
- /* Inform the i2c layer */
- if ((err = i2c_attach_client(client)))
- goto exit_kfree;
-
- dev_info(&client->dev, "chip found, driver version " DRV_VERSION "\n");
+ result = pcf8563_validate_client(client);
+ if (result)
+ return result;
rtc = rtc_device_register(pcf8563_driver.driver.name, &client->dev,
&pcf8563_rtc_ops, THIS_MODULE);
-
- if (IS_ERR(rtc)) {
- err = PTR_ERR(rtc);
- goto exit_detach;
- }
+ if (IS_ERR(rtc))
+ return PTR_ERR(rtc);
i2c_set_clientdata(client, rtc);
return 0;
-
-exit_detach:
- i2c_detach_client(client);
-
-exit_kfree:
- kfree(pcf8563);
-
-exit:
- return err;
-}
-
-static int pcf8563_detach(struct i2c_client *client)
-{
- struct pcf8563 *pcf8563 = container_of(client, struct pcf8563, client);
- int err;
- struct rtc_device *rtc = i2c_get_clientdata(client);
-
- if (rtc)
- rtc_device_unregister(rtc);
-
- if ((err = i2c_detach_client(client)))
- return err;
-
- kfree(pcf8563);
-
- return 0;
}
static int __init pcf8563_init(void)
^ permalink raw reply related
* Re: [patch v4 0/4] Cypress c67x00 (EZ-Host/EZ-OTG) support
From: David Brownell @ 2008-01-21 20:01 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: linuxppc-dev, linux-usb
In-Reply-To: <20080121103434.397382000@sunsite.dk>
On Monday 21 January 2008, Peter Korsgaard wrote:
> The Cypress c67x00 (EZ-Host/EZ-OTG) controllers are multi-role low/fullspeed
> USB controllers. This patch series implements a HCD driver and shows the
> work-in-progress status of a gadget driver.
>
> I believe patch 1..3 are ready, and I would like to see queued up for 2.6.25.
>
> Changes since v3:
> - Lots of cleanups: checkpatch, interrupt handling, c67x00_ prefixes, ..
> - The dummy platform_device's created per serial engine are gone.
> - Gadget driver (WIP)
>
> Comments are very much appreciated.
How does this relate to the "v3" patches posted 8-Jan by Grant Likely?
Is that the "v3" you were referring to?
It's confusing to see two different people submit two sets of patches
for the same driver, without any evident coordination...
- Dave
^ permalink raw reply
* Re: Early driver development resources
From: Frank Bennett @ 2008-01-21 19:25 UTC (permalink / raw)
To: Benedict, Michael; +Cc: linuxppc-embedded
In-Reply-To: <BAF8B1E0BB28024A90895E746A3B610D1C2F01@twx-exch01.twacs.local>
[-- Attachment #1: Type: text/plain, Size: 1682 bytes --]
Benedict, Michael wrote:
> Hello,
> I wrote a driver for a 4 segment digital display device. I have
> a requirement that this device be used as early as possible to report
> kernel bootup state. The driver itself is pretty simple, just using
> in/out_be32() and udelay(). The problem is that I don't know how to use
> hardware resources in the early stages of booting, before I can call
> request_mem_region() and friends.
> Can anyone recommend a book / documentation / reference code /
> anything that demonstrates this, or at least could improve my
> understanding enough to accomplish this?
>
u-boot for embedded (or OpenBios) documentation, source code.
Look for splash screen code although you will want to make
multiple calls for various boot states. In the ISA days and now
PCI there are cards that display a two hex-digit POST progress
code which is a single x86, 8bit output instruction to port 0x80.
This may still be supported in closed source BIOS distributions.
Not sure what they do now with PCIe since it will take more than
a single, simple processor instruction.
-Frank Bennett
> Many thanks,
> Michael
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
--
*/Frank Bennett
President/*
Mathegraphics,LLC
613 Bentley Pl
Fort Collins,CO 80526
970-229-9269 (hm) 970-402-9269 (cell)
www.mathegraphics.com <http://www.mathegraphics.com>
bennett78@lpbroadband.net <mailto:bennett78@lpbroadband.net>
"I think there's a world market for about five computers."
-- attr. Thomas J. Watson (Chairman of the Board, IBM), 1943
[-- Attachment #2: Type: text/html, Size: 3106 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] [POWERPC] 8xxx and embedded6xx: Use machine_*_initcall() hooks in platform code
From: Kumar Gala @ 2008-01-21 19:40 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40801211136u7f25bc38u3ef99b5cc750d850@mail.gmail.com>
On Jan 21, 2008, at 1:36 PM, Grant Likely wrote:
> On 1/21/08, Grant Likely <grant.likely@secretlab.ca> wrote:
>> On 1/21/08, Kumar Gala <galak@kernel.crashing.org> wrote:
>>>
>>> On Jan 21, 2008, at 12:58 PM, Grant Likely wrote:
>>>
>>>> From: Grant Likely <grant.likely@secretlab.ca>
>>>>
>>>> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
>>>> ---
>>>>
>>>> arch/powerpc/platforms/82xx/mpc8272_ads.c | 5 +----
>>>> arch/powerpc/platforms/82xx/pq2fads.c | 5 +----
>>>> arch/powerpc/platforms/83xx/mpc832x_mds.c | 5 +----
>>>> arch/powerpc/platforms/83xx/mpc832x_rdb.c | 11 ++---------
>>>> arch/powerpc/platforms/83xx/mpc834x_mds.c | 5 +----
>>>> arch/powerpc/platforms/83xx/mpc836x_mds.c | 5 +----
>>>> arch/powerpc/platforms/83xx/mpc837x_mds.c | 5 +----
>>>> arch/powerpc/platforms/85xx/mpc85xx_ads.c | 5 +----
>>>> arch/powerpc/platforms/85xx/mpc85xx_cds.c | 6 +-----
>>>> arch/powerpc/platforms/85xx/mpc85xx_mds.c | 5 +----
>>>> arch/powerpc/platforms/embedded6xx/ls_uart.c | 5 +----
>>>
>>> I believe I got the 83xx and 85xx already. look at my tree.
>>
>> Okay, I can drop those and repost.
>
> Actually, that's too much work... I'll wait until paulus pulls your
> tree, rebase and then repost.
that's fine.
- k
^ permalink raw reply
* Re: [PATCH 2/2] [POWERPC] 8xxx and embedded6xx: Use machine_*_initcall() hooks in platform code
From: Grant Likely @ 2008-01-21 19:36 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40801211135r5cde9f6t9b6ee323a48bc44c@mail.gmail.com>
On 1/21/08, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 1/21/08, Kumar Gala <galak@kernel.crashing.org> wrote:
> >
> > On Jan 21, 2008, at 12:58 PM, Grant Likely wrote:
> >
> > > From: Grant Likely <grant.likely@secretlab.ca>
> > >
> > > Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> > > ---
> > >
> > > arch/powerpc/platforms/82xx/mpc8272_ads.c | 5 +----
> > > arch/powerpc/platforms/82xx/pq2fads.c | 5 +----
> > > arch/powerpc/platforms/83xx/mpc832x_mds.c | 5 +----
> > > arch/powerpc/platforms/83xx/mpc832x_rdb.c | 11 ++---------
> > > arch/powerpc/platforms/83xx/mpc834x_mds.c | 5 +----
> > > arch/powerpc/platforms/83xx/mpc836x_mds.c | 5 +----
> > > arch/powerpc/platforms/83xx/mpc837x_mds.c | 5 +----
> > > arch/powerpc/platforms/85xx/mpc85xx_ads.c | 5 +----
> > > arch/powerpc/platforms/85xx/mpc85xx_cds.c | 6 +-----
> > > arch/powerpc/platforms/85xx/mpc85xx_mds.c | 5 +----
> > > arch/powerpc/platforms/embedded6xx/ls_uart.c | 5 +----
> >
> > I believe I got the 83xx and 85xx already. look at my tree.
>
> Okay, I can drop those and repost.
Actually, that's too much work... I'll wait until paulus pulls your
tree, rebase and then repost.
/me is lazy.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 2/2] [POWERPC] 8xxx and embedded6xx: Use machine_*_initcall() hooks in platform code
From: Grant Likely @ 2008-01-21 19:35 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <6FA7C7C0-172D-4AD4-BDAF-A1E3845A63FE@kernel.crashing.org>
On 1/21/08, Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Jan 21, 2008, at 12:58 PM, Grant Likely wrote:
>
> > From: Grant Likely <grant.likely@secretlab.ca>
> >
> > Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> > ---
> >
> > arch/powerpc/platforms/82xx/mpc8272_ads.c | 5 +----
> > arch/powerpc/platforms/82xx/pq2fads.c | 5 +----
> > arch/powerpc/platforms/83xx/mpc832x_mds.c | 5 +----
> > arch/powerpc/platforms/83xx/mpc832x_rdb.c | 11 ++---------
> > arch/powerpc/platforms/83xx/mpc834x_mds.c | 5 +----
> > arch/powerpc/platforms/83xx/mpc836x_mds.c | 5 +----
> > arch/powerpc/platforms/83xx/mpc837x_mds.c | 5 +----
> > arch/powerpc/platforms/85xx/mpc85xx_ads.c | 5 +----
> > arch/powerpc/platforms/85xx/mpc85xx_cds.c | 6 +-----
> > arch/powerpc/platforms/85xx/mpc85xx_mds.c | 5 +----
> > arch/powerpc/platforms/embedded6xx/ls_uart.c | 5 +----
>
> I believe I got the 83xx and 85xx already. look at my tree.
Okay, I can drop those and repost.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 2/2] [POWERPC] 8xxx and embedded6xx: Use machine_*_initcall() hooks in platform code
From: Kumar Gala @ 2008-01-21 19:27 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <20080121185812.13486.68032.stgit@trillian.secretlab.ca>
On Jan 21, 2008, at 12:58 PM, Grant Likely wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> ---
>
> arch/powerpc/platforms/82xx/mpc8272_ads.c | 5 +----
> arch/powerpc/platforms/82xx/pq2fads.c | 5 +----
> arch/powerpc/platforms/83xx/mpc832x_mds.c | 5 +----
> arch/powerpc/platforms/83xx/mpc832x_rdb.c | 11 ++---------
> arch/powerpc/platforms/83xx/mpc834x_mds.c | 5 +----
> arch/powerpc/platforms/83xx/mpc836x_mds.c | 5 +----
> arch/powerpc/platforms/83xx/mpc837x_mds.c | 5 +----
> arch/powerpc/platforms/85xx/mpc85xx_ads.c | 5 +----
> arch/powerpc/platforms/85xx/mpc85xx_cds.c | 6 +-----
> arch/powerpc/platforms/85xx/mpc85xx_mds.c | 5 +----
> arch/powerpc/platforms/embedded6xx/ls_uart.c | 5 +----
I believe I got the 83xx and 85xx already. look at my tree.
- k
^ permalink raw reply
* fixed phy support (warning related to FIXED_MII_100_FDX)
From: Kumar Gala @ 2008-01-21 19:19 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev list
Anton,
it looks like the "TI AR7 CPMAC Ethernet support" uses FIXED_PHY and
was selecting FIXED_MII_100_FDX which is gone.
Can you look into this. I get the following warning now:
scripts/kconfig/conf -s arch/powerpc/Kconfig
drivers/net/Kconfig:1713:warning: 'select' used by config symbol
'CPMAC' refers to undefined symbol 'FIXED_MII_100_FDX'
- k
^ permalink raw reply
* [PATCH 1/2] [POWERPC] 8xx: Use machine_*_initcall() hooks in platform code
From: Grant Likely @ 2008-01-21 18:58 UTC (permalink / raw)
To: galak, linuxppc-dev
From: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
arch/powerpc/platforms/8xx/ep88xc.c | 5 ++---
arch/powerpc/platforms/8xx/mpc86xads_setup.c | 5 ++---
arch/powerpc/platforms/8xx/mpc885ads_setup.c | 5 ++---
3 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/platforms/8xx/ep88xc.c b/arch/powerpc/platforms/8xx/ep88xc.c
index c518b6c..88afa35 100644
--- a/arch/powerpc/platforms/8xx/ep88xc.c
+++ b/arch/powerpc/platforms/8xx/ep88xc.c
@@ -155,12 +155,11 @@ static struct of_device_id __initdata of_bus_ids[] = {
static int __init declare_of_platform_devices(void)
{
/* Publish the QE devices */
- if (machine_is(ep88xc))
- of_platform_bus_probe(NULL, of_bus_ids, NULL);
+ of_platform_bus_probe(NULL, of_bus_ids, NULL);
return 0;
}
-device_initcall(declare_of_platform_devices);
+machine_device_initcall(ep88xc, declare_of_platform_devices);
define_machine(ep88xc) {
.name = "Embedded Planet EP88xC",
diff --git a/arch/powerpc/platforms/8xx/mpc86xads_setup.c b/arch/powerpc/platforms/8xx/mpc86xads_setup.c
index d2927a4..d7965f8 100644
--- a/arch/powerpc/platforms/8xx/mpc86xads_setup.c
+++ b/arch/powerpc/platforms/8xx/mpc86xads_setup.c
@@ -128,12 +128,11 @@ static struct of_device_id __initdata of_bus_ids[] = {
static int __init declare_of_platform_devices(void)
{
- if (machine_is(mpc86x_ads))
- of_platform_bus_probe(NULL, of_bus_ids, NULL);
+ of_platform_bus_probe(NULL, of_bus_ids, NULL);
return 0;
}
-device_initcall(declare_of_platform_devices);
+machine_device_initcall(mpc86x_ads, declare_of_platform_devices);
define_machine(mpc86x_ads) {
.name = "MPC86x ADS",
diff --git a/arch/powerpc/platforms/8xx/mpc885ads_setup.c b/arch/powerpc/platforms/8xx/mpc885ads_setup.c
index 2cf1b6a..6ef8e9e 100644
--- a/arch/powerpc/platforms/8xx/mpc885ads_setup.c
+++ b/arch/powerpc/platforms/8xx/mpc885ads_setup.c
@@ -264,12 +264,11 @@ static struct of_device_id __initdata of_bus_ids[] = {
static int __init declare_of_platform_devices(void)
{
/* Publish the QE devices */
- if (machine_is(mpc885_ads))
- of_platform_bus_probe(NULL, of_bus_ids, NULL);
+ of_platform_bus_probe(NULL, of_bus_ids, NULL);
return 0;
}
-device_initcall(declare_of_platform_devices);
+machine_device_initcall(mpc885_ads, declare_of_platform_devices);
define_machine(mpc885_ads) {
.name = "Freescale MPC885 ADS",
^ permalink raw reply related
* [PATCH 2/2] [POWERPC] 8xxx and embedded6xx: Use machine_*_initcall() hooks in platform code
From: Grant Likely @ 2008-01-21 18:58 UTC (permalink / raw)
To: galak, linuxppc-dev
In-Reply-To: <20080121185806.13486.56429.stgit@trillian.secretlab.ca>
From: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
arch/powerpc/platforms/82xx/mpc8272_ads.c | 5 +----
arch/powerpc/platforms/82xx/pq2fads.c | 5 +----
arch/powerpc/platforms/83xx/mpc832x_mds.c | 5 +----
arch/powerpc/platforms/83xx/mpc832x_rdb.c | 11 ++---------
arch/powerpc/platforms/83xx/mpc834x_mds.c | 5 +----
arch/powerpc/platforms/83xx/mpc836x_mds.c | 5 +----
arch/powerpc/platforms/83xx/mpc837x_mds.c | 5 +----
arch/powerpc/platforms/85xx/mpc85xx_ads.c | 5 +----
arch/powerpc/platforms/85xx/mpc85xx_cds.c | 6 +-----
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 5 +----
arch/powerpc/platforms/embedded6xx/ls_uart.c | 5 +----
11 files changed, 12 insertions(+), 50 deletions(-)
diff --git a/arch/powerpc/platforms/82xx/mpc8272_ads.c b/arch/powerpc/platforms/82xx/mpc8272_ads.c
index fd83440..3fce6b3 100644
--- a/arch/powerpc/platforms/82xx/mpc8272_ads.c
+++ b/arch/powerpc/platforms/82xx/mpc8272_ads.c
@@ -165,14 +165,11 @@ static struct of_device_id __initdata of_bus_ids[] = {
static int __init declare_of_platform_devices(void)
{
- if (!machine_is(mpc8272_ads))
- return 0;
-
/* Publish the QE devices */
of_platform_bus_probe(NULL, of_bus_ids, NULL);
return 0;
}
-device_initcall(declare_of_platform_devices);
+machine_device_initcall(mpc8272_ads, declare_of_platform_devices);
/*
* Called very early, device-tree isn't unflattened
diff --git a/arch/powerpc/platforms/82xx/pq2fads.c b/arch/powerpc/platforms/82xx/pq2fads.c
index 1be5005..68196e3 100644
--- a/arch/powerpc/platforms/82xx/pq2fads.c
+++ b/arch/powerpc/platforms/82xx/pq2fads.c
@@ -176,14 +176,11 @@ static struct of_device_id __initdata of_bus_ids[] = {
static int __init declare_of_platform_devices(void)
{
- if (!machine_is(pq2fads))
- return 0;
-
/* Publish the QE devices */
of_platform_bus_probe(NULL, of_bus_ids, NULL);
return 0;
}
-device_initcall(declare_of_platform_devices);
+machine_device_initcall(pq2fads, declare_of_platform_devices);
define_machine(pq2fads)
{
diff --git a/arch/powerpc/platforms/83xx/mpc832x_mds.c b/arch/powerpc/platforms/83xx/mpc832x_mds.c
index 1e570bb..dbdd4ad 100644
--- a/arch/powerpc/platforms/83xx/mpc832x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc832x_mds.c
@@ -110,15 +110,12 @@ static struct of_device_id mpc832x_ids[] = {
static int __init mpc832x_declare_of_platform_devices(void)
{
- if (!machine_is(mpc832x_mds))
- return 0;
-
/* Publish the QE devices */
of_platform_bus_probe(NULL, mpc832x_ids, NULL);
return 0;
}
-device_initcall(mpc832x_declare_of_platform_devices);
+machine_device_initcall(mpc832x_mds, mpc832x_declare_of_platform_devices);
static void __init mpc832x_sys_init_IRQ(void)
{
diff --git a/arch/powerpc/platforms/83xx/mpc832x_rdb.c b/arch/powerpc/platforms/83xx/mpc832x_rdb.c
index ffb2e93..1b57028 100644
--- a/arch/powerpc/platforms/83xx/mpc832x_rdb.c
+++ b/arch/powerpc/platforms/83xx/mpc832x_rdb.c
@@ -63,9 +63,6 @@ static struct spi_board_info mpc832x_spi_boardinfo = {
static int __init mpc832x_spi_init(void)
{
- if (!machine_is(mpc832x_rdb))
- return 0;
-
par_io_config_pin(3, 0, 3, 0, 1, 0); /* SPI1 MOSI, I/O */
par_io_config_pin(3, 1, 3, 0, 1, 0); /* SPI1 MISO, I/O */
par_io_config_pin(3, 2, 3, 0, 1, 0); /* SPI1 CLK, I/O */
@@ -79,8 +76,7 @@ static int __init mpc832x_spi_init(void)
mpc83xx_spi_activate_cs,
mpc83xx_spi_deactivate_cs);
}
-
-device_initcall(mpc832x_spi_init);
+machine_device_initcall(mpc832x_rdb, mpc832x_spi_init);
/* ************************************************************************
*
@@ -123,15 +119,12 @@ static struct of_device_id mpc832x_ids[] = {
static int __init mpc832x_declare_of_platform_devices(void)
{
- if (!machine_is(mpc832x_rdb))
- return 0;
-
/* Publish the QE devices */
of_platform_bus_probe(NULL, mpc832x_ids, NULL);
return 0;
}
-device_initcall(mpc832x_declare_of_platform_devices);
+machine_device_initcall(mpc832x_rdb, mpc832x_declare_of_platform_devices);
void __init mpc832x_rdb_init_IRQ(void)
{
diff --git a/arch/powerpc/platforms/83xx/mpc834x_mds.c b/arch/powerpc/platforms/83xx/mpc834x_mds.c
index 459fb72..2b8a0a3 100644
--- a/arch/powerpc/platforms/83xx/mpc834x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc834x_mds.c
@@ -115,13 +115,10 @@ static struct of_device_id mpc834x_ids[] = {
static int __init mpc834x_declare_of_platform_devices(void)
{
- if (!machine_is(mpc834x_mds))
- return 0;
-
of_platform_bus_probe(NULL, mpc834x_ids, NULL);
return 0;
}
-device_initcall(mpc834x_declare_of_platform_devices);
+machine_device_initcall(mpc834x_mds, mpc834x_declare_of_platform_devices);
/*
* Called very early, MMU is off, device-tree isn't unflattened
diff --git a/arch/powerpc/platforms/83xx/mpc836x_mds.c b/arch/powerpc/platforms/83xx/mpc836x_mds.c
index 2ac9890..db491ec 100644
--- a/arch/powerpc/platforms/83xx/mpc836x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc836x_mds.c
@@ -141,15 +141,12 @@ static struct of_device_id mpc836x_ids[] = {
static int __init mpc836x_declare_of_platform_devices(void)
{
- if (!machine_is(mpc836x_mds))
- return 0;
-
/* Publish the QE devices */
of_platform_bus_probe(NULL, mpc836x_ids, NULL);
return 0;
}
-device_initcall(mpc836x_declare_of_platform_devices);
+machine_device_initcall(mpc836x_mds, mpc836x_declare_of_platform_devices);
static void __init mpc836x_mds_init_IRQ(void)
{
diff --git a/arch/powerpc/platforms/83xx/mpc837x_mds.c b/arch/powerpc/platforms/83xx/mpc837x_mds.c
index 9cdc32b..cfd0548 100644
--- a/arch/powerpc/platforms/83xx/mpc837x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc837x_mds.c
@@ -50,15 +50,12 @@ static struct of_device_id mpc837x_ids[] = {
static int __init mpc837x_declare_of_platform_devices(void)
{
- if (!machine_is(mpc837x_mds))
- return 0;
-
/* Publish of_device */
of_platform_bus_probe(NULL, mpc837x_ids, NULL);
return 0;
}
-device_initcall(mpc837x_declare_of_platform_devices);
+machine_device_initcall(mpc837x_mds, mpc837x_declare_of_platform_devices);
static void __init mpc837x_mds_init_IRQ(void)
{
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ads.c b/arch/powerpc/platforms/85xx/mpc85xx_ads.c
index bccdc25..a3fa1b0 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_ads.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_ads.c
@@ -233,13 +233,10 @@ static struct of_device_id __initdata of_bus_ids[] = {
static int __init declare_of_platform_devices(void)
{
- if (!machine_is(mpc85xx_ads))
- return 0;
-
of_platform_bus_probe(NULL, of_bus_ids, NULL);
return 0;
}
-device_initcall(declare_of_platform_devices);
+machine_device_initcall(mpc85xx_ads, declare_of_platform_devices);
/*
* Called very early, device-tree isn't unflattened
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_cds.c b/arch/powerpc/platforms/85xx/mpc85xx_cds.c
index 4d063ee..8b1de78 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_cds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_cds.c
@@ -222,9 +222,6 @@ static int mpc85xx_cds_8259_attach(void)
struct device_node *cascade_node = NULL;
int cascade_irq;
- if (!machine_is(mpc85xx_cds))
- return 0;
-
/* Initialize the i8259 controller */
for_each_node_by_type(np, "interrupt-controller")
if (of_device_is_compatible(np, "chrp,iic")) {
@@ -262,8 +259,7 @@ static int mpc85xx_cds_8259_attach(void)
return 0;
}
-
-device_initcall(mpc85xx_cds_8259_attach);
+machine_device_initcall(mpc85xx_cds, mpc85xx_cds_8259_attach);
#endif /* CONFIG_PPC_I8259 */
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
index e6c63a5..9f4f3aa 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
@@ -144,15 +144,12 @@ static struct of_device_id mpc85xx_ids[] = {
static int __init mpc85xx_publish_devices(void)
{
- if (!machine_is(mpc85xx_mds))
- return 0;
-
/* Publish the QE devices */
of_platform_bus_probe(NULL,mpc85xx_ids,NULL);
return 0;
}
-device_initcall(mpc85xx_publish_devices);
+machine_device_initcall(mpc85xx_mds, mpc85xx_publish_devices);
static void __init mpc85xx_mds_pic_init(void)
{
diff --git a/arch/powerpc/platforms/embedded6xx/ls_uart.c b/arch/powerpc/platforms/embedded6xx/ls_uart.c
index c99264c..9d891bd 100644
--- a/arch/powerpc/platforms/embedded6xx/ls_uart.c
+++ b/arch/powerpc/platforms/embedded6xx/ls_uart.c
@@ -117,9 +117,6 @@ static int __init ls_uarts_init(void)
phys_addr_t phys_addr;
int len;
- if (!machine_is(linkstation))
- return 0;
-
avr = of_find_node_by_path("/soc10x/serial@80004500");
if (!avr)
return -EINVAL;
@@ -142,4 +139,4 @@ static int __init ls_uarts_init(void)
return 0;
}
-late_initcall(ls_uarts_init);
+machine_late_initcall(linkstation, ls_uarts_init);
^ permalink raw reply related
* Re: Patches added to master/for-2.6.25 branch of powerpc.git
From: Grant Likely @ 2008-01-21 18:53 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40801172153v69d948e5hf01d963410123f38@mail.gmail.com>
On 1/17/08, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 1/17/08, Paul Mackerras <paulus@samba.org> wrote:
> > Grant Likely writes:
> >
> > > Paul, can you also please pull the following 52xx changes?
> >
> > Could you please re-do your tree and make sure the headline for each
> > commit starts with "[POWERPC]" (unless it isn't powerpc-specific, in
> > which case it probably shouldn't be in your tree...).
>
> Oops, I thought I had done that. Sorry, I'll get that respun ASAP.
Here you go; respun the 52xx patches as you requested. Please pull.
Also, can you please merge your 2.6.25 branch with Linus' top of tree?
There are some more patches which I'm withholding until then because
they'll cause nasty merge conflicts otherwise.
Thanks,
g.
The following changes since commit 52920df4aa9dd25836b8ed4dc0b177ea14c09e53:
Paul Mackerras (1):
Merge branch 'for-2.6.25' of
master.kernel.org:/.../olof/pasemi into for-2.6.25
are available in the git repository at:
git://git.secretlab.ca/git/linux-2.6-mpc52xx.git for-2.6.25
Grant Likely (2):
[POWERPC] mpc5200: eliminate mpc52xx_*_map_*() functions.
[POWERPC] mpc5200: merge defconfigs for all mpc5200 boards
John Rigby (2):
[POWERPC] Separate MPC52xx PSC FIFO registers from rest of PSC
[POWERPC] mpc5200: Cleanup checkpatch.pl problems in mpc52xx_uart.c
Marian Balakowicz (6):
[POWERPC] mpc5200: Add 'fsl,lpb' bus type for localplus bus
[POWERPC] mpc5200: Add common mpc52xx_setup_pci() routine
[POWERPC] mpc5200: Add TQM5200 DTS
[POWERPC] mpc5200: add CM5200 DTS
[POWERPC] mpc5200: Add Promess Motion-PRO DTS
[POWERPC] mpc5200: Add generic support for simple MPC5200 based boards
arch/powerpc/boot/dts/cm5200.dts | 236 +++++
arch/powerpc/boot/dts/lite5200.dts | 2 +-
arch/powerpc/boot/dts/lite5200b.dts | 2 +-
arch/powerpc/boot/dts/motionpro.dts | 309 ++++++
arch/powerpc/boot/dts/tqm5200.dts | 184 ++++
arch/powerpc/configs/lite5200_defconfig | 847 -----------------
arch/powerpc/configs/mpc5200_defconfig | 1286 ++++++++++++++++++++++++++
arch/powerpc/platforms/52xx/Kconfig | 27 +-
arch/powerpc/platforms/52xx/Makefile | 1 +
arch/powerpc/platforms/52xx/lite5200.c | 22 +-
arch/powerpc/platforms/52xx/lite5200_pm.c | 6 +-
arch/powerpc/platforms/52xx/mpc5200_simple.c | 85 ++
arch/powerpc/platforms/52xx/mpc52xx_common.c | 63 +-
arch/powerpc/platforms/52xx/mpc52xx_pci.c | 14 +
arch/powerpc/platforms/52xx/mpc52xx_pic.c | 8 +-
arch/powerpc/platforms/52xx/mpc52xx_pm.c | 8 +-
drivers/serial/mpc52xx_uart.c | 210 +++--
drivers/spi/mpc52xx_psc_spi.c | 9 +-
include/asm-powerpc/mpc52xx.h | 7 +-
include/asm-powerpc/mpc52xx_psc.h | 3 +
include/asm-ppc/mpc52xx_psc.h | 3 +
21 files changed, 2317 insertions(+), 1015 deletions(-)
create mode 100644 arch/powerpc/boot/dts/cm5200.dts
create mode 100644 arch/powerpc/boot/dts/motionpro.dts
create mode 100644 arch/powerpc/boot/dts/tqm5200.dts
delete mode 100644 arch/powerpc/configs/lite5200_defconfig
create mode 100644 arch/powerpc/configs/mpc5200_defconfig
create mode 100644 arch/powerpc/platforms/52xx/mpc5200_simple.c
>
> Cheers,
> g.
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* RE: Generated xilinx linux 2.6 image sections
From: Stephen Neuendorffer @ 2008-01-21 18:45 UTC (permalink / raw)
To: greenlean, linuxppc-embedded
In-Reply-To: <14997109.post@talk.nabble.com>
The testapps are generated using a different linker script.
Based on what you sent out, it looks like your EDK design has a memory
at 0x10000000, but this is
not reflected in the linux image you've generated. This makes me
suspect that you haven't generated the BSP and copied the appropriate
xparameters file over xparameters_xup.h (assuming you are using
CONFIG_XILINX_XUPV2P).
Steve
> -----Original Message-----
> From: linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@ozlabs.org
[mailto:linuxppc-embedded-
> bounces+stephen=3Dneuendorffer.name@ozlabs.org] On Behalf Of greenlean
> Sent: Monday, January 21, 2008 5:06 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: Generated xilinx linux 2.6 image sections
>=20
>=20
> Hi all,
>=20
> I'm trying to boot the 2.6 xilinx kernel downloaded from their git
server in
> the XUPV2P board I'm really having troubles (I can't see anything in
the
> minicom console terminal). I'm not seeing anything, neither the
ucompressing
> kernel string nor the prompt with the memory addresses that kernel
prompt at
> first time, so I have started to distrust of anything.
>=20
> When I download the kernel using xmd, I see:
>=20
> XMD% dow imagen_UART16550_ml300.elf
> section, .text: 0x00400000-0x0040387b
> section, .data: 0x00404000-0x004e6fff
> section, .bss: 0x004e7000-0x004e919f
> Downloaded Program imagen_UART16550_ml300.elf
> Setting PC with Program Start Address 0x00400000
>=20
> and when I download some of the TestApp generated by EDK I see:
>=20
> XMD% dow perif.elf
> section, .vectors: 0xfffe0000-0xfffe20c3
> section, .text: 0x10000000-0x10003b7b
> section, .init: 0x10003b7c-0x10003b9f
> section, .fini: 0x10003ba0-0x10003bbf
> section, .boot0: 0xfffe20c4-0xfffe20d3
> section, .boot: 0xfffffffc-0xffffffff
> section, .rodata: 0x10003bc0-0x10004111
> section, .sdata2: 0x10004114-0x10004113
> section, .sbss2: 0x10004114-0x10004113
> section, .data: 0x10004114-0x10004243
> section, .got: 0x10004244-0x10004243
> section, .got1: 0x10004244-0x10004243
> section, .got2: 0x10004244-0x1000425f
> section, .ctors: 0x10004260-0x10004267
> section, .dtors: 0x10004268-0x1000426f
> section, .fixup: 0x10004270-0x1000426f
> section, .eh_frame: 0x10004270-0x10004277
> section, .jcr: 0x10004278-0x1000427b
> section, .gcc_except_table: 0x1000427c-0x100042
> section, .sdata: 0x1000427c-0x10004293
> section, .sbss: 0x10004294-0x100042a3
> section, .bss: 0x100042a4-0x10004473
> section, .stack: 0x10004474-0x1000647f
> section, .heap: 0x10006480-0x1000847f
> Downloaded Program perif.elf
> Setting PC with Program Start Address 0xfffffffc
>=20
> Does anybody know why the kernel elf don't have a boot section like
the
> TestApp generated by EDK?
>=20
> I suppossed this is because the image kernel is compressed, but
despite
> beeing compressed it should have a boot section or something similar
???
> It's right that the kernel start address is set to the 0x00400000??
>=20
> Or does the section .text contains all the kernel code to uncompresse
the
> code of the kernel??
>=20
>=20
>=20
> --
> View this message in context:
http://www.nabble.com/Generated-xilinx-linux-2.6--image-sections-
> tp14997109p14997109.html
> Sent from the linuxppc-embedded mailing list archive at Nabble.com.
>=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [PATCH] autodetect serial console on efika
From: Grant Likely @ 2008-01-21 18:45 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, Paul Mackeras
In-Reply-To: <20080121152900.GA8664@aepfle.de>
On 1/21/08, Olaf Hering <olaf@aepfle.de> wrote:
>
> Efika boards have to be booted with console=ttyPSC0 unless there is a
> graphics card plugged in. Detect if the firmware stdout is the serial
> connector.
>
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
Hrrrum; I think this is a good idea, but I'm not thrilled with the
approach. Here are my concerns:
- Determining that linux,stdout-path points to a PSC should should be
done in common code. It's useful for all 5200 boards, not just the
Efika. (However, if 'failsafe' processing is efika specific, then it
can stay in efika.c). This might be best done within the PSC driver
itself, but I'm not sure.
- Recognizing a psc node should be done by inspecting the compatible
property, not by device_type and model properties.
Thanks,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* RE: Xilinx XPS_LL_TEMAC vs PLB_TEMAC
From: Stephen Neuendorffer @ 2008-01-21 18:42 UTC (permalink / raw)
To: Mohammad Sadegh Sadri, David Baird, linuxppc-embedded
In-Reply-To: <BAY115-W344A18C61627B3075C6281B23D0@phx.gbl>
Basically, git.xilinx.com has a tree with most of the xilinx-related
support already integrated and ported forward to a current kernel. It
also includes ongoing work to unify microblaze and powerpc device
drivers through flat device trees.
See:
http://www.mail-archive.com/linuxppc-embedded@ozlabs.org/msg28690.html
To use the git.xilinx.com tree you should *not* generate the driver code
directly into the Linux tree. Instead, you should generate the driver
code in a dummy directory and copy
arch/ppc/platforms/4xx/xparameters_ml*.h into the kernel tree.
The BSP generation process is designed older 2.6.10-era kernels and will
not work with recent kernels. =20
Steve
> -----Original Message-----
> From: linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@ozlabs.org
[mailto:linuxppc-embedded-
> bounces+stephen=3Dneuendorffer.name@ozlabs.org] On Behalf Of Mohammad
Sadegh Sadri
> Sent: Monday, January 21, 2008 12:54 AM
> To: David Baird; linuxppc-embedded@ozlabs.org
> Subject: RE: Xilinx XPS_LL_TEMAC vs PLB_TEMAC
>=20
> thanks for you reply david,
>=20
> As far as I know the Linux driver for Xilinx PLB TEMAC was two parts :
1- adapter.c and 2- the rest
> of the driver files
>=20
> Only adapter.c was really a linux related file and the rest of the
files were Xilinx generic driver
> code for PLB TEMAC.
>=20
> correct?
>=20
> then now, I know EDK 9.2 generates the needed Linux support package
and needed related files, so if
> this is the case can we use these files as the needed driver in our
linux kernel?
>=20
> by the way, i did never hear about this git repository before...can
you describe us, where is it and
> how we can access it and which projects are now hosted by it?
>=20
>=20
> thanks
>=20
>=20
> > Date: Mon, 21 Jan 2008 00:54:30 -0700
> > From: dhbaird@gmail.com
> > To: mamsadegh@hotmail.com
> > Subject: Re: Xilinx XPS_LL_TEMAC vs PLB_TEMAC
> >
> > On Jan 21, 2008 12:36 AM, Mohammad Sadegh Sadri
<mamsadegh@hotmail.com> wrote:
> > > As you know Xilinx PLB TEMAC is a module which connects Hard TEMAC
in
> > > Virtex-4 FX devices to PLB bus,
> > > now, in the new release of EDK , EDK 9.2 Xilinx has added a new
interface
> > > core , which is called XPS_LL_TEMAC and has a different structure
than
> > > normal PLB TEMAC. spacially it has some additional data transfer
buses.
> > >
> > > Now the question is,... is there any linux driver available for
this new
> > > core?
> >
> > Yes there is, but I had to use the git sources at:
> >
> > git.xilinx.com
>=20
>=20
> ________________________________
^ permalink raw reply
* Early driver development resources
From: Benedict, Michael @ 2008-01-21 18:20 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I wrote a driver for a 4 segment digital display device. I have
a requirement that this device be used as early as possible to report
kernel bootup state. The driver itself is pretty simple, just using
in/out_be32() and udelay(). The problem is that I don't know how to use
hardware resources in the early stages of booting, before I can call
request_mem_region() and friends.
Can anyone recommend a book / documentation / reference code /
anything that demonstrates this, or at least could improve my
understanding enough to accomplish this?
Many thanks,
Michael
^ 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