* Re: [PATCH 0/6] Remove owner field from sysfs attribute structure
From: Stephen Rothwell @ 2010-08-10 15:17 UTC (permalink / raw)
To: Jean Delvare
Cc: Guenter Roeck, Greg Kroah-Hartman, Dmitry Torokhov, Linus Walleij,
James Smart, Eric Biederman, Greg KH, Mark Brown, linux-kernel,
Chris Wright, linuxppc-dev, James E.J. Bottomley, Richard Purdie,
Nick Cheng, Jani Nikula, Tejun Heo, Paul Mackerras, Liam Girdwood,
linux-scsi, Alex Iannicelli, Benjamin Thery
In-Reply-To: <20100810154337.006a0df9@hyperion.delvare>
[-- Attachment #1: Type: text/plain, Size: 352 bytes --]
Hi Jean,
On Tue, 10 Aug 2010 15:43:37 +0200 Jean Delvare <khali@linux-fr.org> wrote:
>
> Related bug?
>
> https://bugzilla.kernel.org/show_bug.cgi?id=16544
Yep, fixed in linux-next today - hopefully the fix is on its way to Linus.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH 0/6] Remove owner field from sysfs attribute structure
From: Jean Delvare @ 2010-08-10 13:43 UTC (permalink / raw)
To: Greg KH
Cc: Mark Brown, Jani Nikula, Linus Walleij, James Smart,
Eric Biederman, Benjamin Thery, Greg Kroah-Hartman, linux-kernel,
Chris Wright, linuxppc-dev, James E.J. Bottomley, Richard Purdie,
Nick Cheng, Dmitry Torokhov, Tejun Heo, Paul Mackerras,
Liam Girdwood, linux-scsi, Alex Iannicelli, Guenter Roeck
In-Reply-To: <20100802233128.GA21286@kroah.com>
On Mon, 2 Aug 2010 16:31:28 -0700, Greg KH wrote:
> On Wed, Jul 28, 2010 at 11:16:35PM -0700, Eric Biederman wrote:
> > On Wed, Jul 28, 2010 at 10:09 PM, Guenter Roeck
> > <guenter.roeck@ericsson.com> wrote:
> > > The following comment is found in include/linux/sysfs.h:
> > >
> > > =C2=A0 /* FIXME
> > > =C2=A0 =C2=A0* The *owner field is no longer used.
> > > =C2=A0 =C2=A0* x86 tree has been cleaned up. The owner
> > > =C2=A0 =C2=A0* attribute is still left for other arches.
> > > =C2=A0 =C2=A0*/
> > >
> > > As it turns out, the *owner field is (again?) initialized in several =
modules,
> > > suggesting that such initialization may be creeping back into the cod=
e.
> > >
> > > This patch set removes the above comment, the *owner field, and each =
instance
> > > in the code where it was found to be initialized.
> > >
> > > Compiled with x86 allmodconfig as well as with all alpha, arm, mips, =
powerpc,
> > > and sparc defconfig builds.
> >=20
> > This seems reasonable to me. Can we get this in linux-next?
>=20
> It will show up in linux-next tomorrow.
Related bug?
https://bugzilla.kernel.org/show_bug.cgi?id=3D16544
--=20
Jean Delvare
^ permalink raw reply
* Re: [spi-devel-general] [PATCH v2 4/6] mtd: m25p80: add a read function to read page by page
From: David Brownell @ 2010-08-10 13:44 UTC (permalink / raw)
To: Mingkai Hu, David Woodhouse, Grant Likely
Cc: linuxppc-dev, kumar.gala, spi-devel-general
In-Reply-To: <AANLkTikM5je7Ckt=7bP6fj7OKCaroSn_AqgcS4T+Bv5d@mail.gmail.com>
=0A=0A--- On Tue, 8/10/10, Grant Likely <grant.likely@secretlab.ca> wrote:=
=0A=0A> This one bothers me, but I can't put my=0A> finger on it.=A0The fla=
g feels=0A> like a controller specific hack.=0A=0AThat's because it *IS* ..=
.=0A=0ANot clear what a good fix would look like.=0ABut in general, SPI mas=
ter controllers are=0Aresponsible for returning all bytes requested,=0Ainst=
ead of (as with this one) a subset.=0A=0ASuggesting the real issue is a bug=
gy SPI=0Amaster controller and/or driver. Can't it=0Aissue multiple reads =
to collect all the data=0Arequested?? =0A=0A- Dave=0A=0A=0A
^ permalink raw reply
* Accessing GPIO registers on MPC8377ERDB board
From: Ravi Gupta @ 2010-08-10 12:59 UTC (permalink / raw)
To: linuxppc-dev, linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 385 bytes --]
Hi,
I want to access the GPIO registers present in MPC8377ERDB board. I have to
write a GPIO driver for that, I am completely confused that how to do it.
Please suggest some way or doc to start with.
For the start-up, I was thinking of setting GPIO pins 9, 10 and 11 present
on the board to active low as they are connected to leds D3, D4 and D5 resp.
Thanks in advance
Ravi Gupta
[-- Attachment #2: Type: text/html, Size: 414 bytes --]
^ permalink raw reply
* Re: [PATCH 8/8] v5 Update memory-hotplug documentation
From: Nathan Fontenot @ 2010-08-10 12:17 UTC (permalink / raw)
To: Nishanth Aravamudan
Cc: linuxppc-dev, Greg KH, linux-kernel, Dave Hansen, linux-mm,
linuxppc-dev, KAMEZAWA Hiroyuki
In-Reply-To: <201008091344.37878.nacc@us.ibm.com>
On 08/09/2010 03:44 PM, Nishanth Aravamudan wrote:
> On Monday, August 09, 2010 11:43:46 am Nathan Fontenot wrote:
>> Update the memory hotplug documentation to reflect the new behaviors of
>> memory blocks reflected in sysfs.
>
> <snip>
>
>> Index: linux-2.6/Documentation/memory-hotplug.txt
>> ===================================================================
>> --- linux-2.6.orig/Documentation/memory-hotplug.txt 2010-08-09 07:36:48.000000000 -0500
>> +++ linux-2.6/Documentation/memory-hotplug.txt 2010-08-09 07:59:54.000000000 -0500
>
> <snip>
>
>> -/sys/devices/system/memory/memoryXXX/phys_index
>> +/sys/devices/system/memory/memoryXXX/start_phys_index
>> +/sys/devices/system/memory/memoryXXX/end_phys_index
>> /sys/devices/system/memory/memoryXXX/phys_device
>> /sys/devices/system/memory/memoryXXX/state
>> /sys/devices/system/memory/memoryXXX/removable
>>
>> -'phys_index' : read-only and contains section id, same as XXX.
>
> <snip>
>
>> +'phys_index' : read-only and contains section id of the first section
>
> Shouldn't this be "start_phys_index"?
Hmmm... looks like I missed something in the documentation.
The property should be 'phys_index'. I thought about changing it to
'start_phys_index' but that was rejected. The listing of the files
above is wrong in this patch, it should be
+/sys/devices/system/memory/memoryXXX/phys_index
+/sys/devices/system/memory/memoryXXX/end_phys_index
Thanks,
Nathan
^ permalink raw reply
* RE: [PATCH 1/3 v2] sdhci: Add auto CMD12 support for eSDHC driver
From: Zang Roy-R61911 @ 2010-08-10 10:07 UTC (permalink / raw)
To: Michał Mirosław; +Cc: linuxppc-dev, akpm, linux-mmc
In-Reply-To: <AANLkTikUypKobPAHsE+tz-Py-XvvJhbcj7Syj3rX_ej0@mail.gmail.com>
=20
> -----Original Message-----
> From: Micha=B3 Miros=B3aw [mailto:mirqus@gmail.com]=20
> Sent: Tuesday, August 10, 2010 2:25 AM
> To: Zang Roy-R61911
> Cc: linux-mmc@vger.kernel.org; linuxppc-dev@ozlabs.org;=20
> akpm@linux-foundation.org
> Subject: Re: [PATCH 1/3 v2] sdhci: Add auto CMD12 support for=20
> eSDHC driver
>=20
> 2010/8/3 Roy Zang <tie-fei.zang@freescale.com>:
> [...]
> > @@ -240,6 +240,8 @@ struct sdhci_host {
> > =A0#define SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN =A0 =A0 =A0 =A0 =A0 =A0 =
=A0(1<<25)
> > =A0/* Controller cannot support End Attribute in NOP ADMA=20
> descriptor */
> > =A0#define SDHCI_QUIRK_NO_ENDATTR_IN_NOPDESC =A0 =A0 =A0 =A0 =A0 =A0 =
=A0(1<<26)
> > +/* Controller uses Auto CMD12 command to stop the transfer */
> > +#define SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 =A0 =A0 =A0 =A0 =A0 =A0 =
(1<<27)
> >
> > =A0 =A0 =A0 =A0int =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 irq; =A0 =
=A0 =A0 =A0 =A0 =A0/* Device IRQ */
> > =A0 =A0 =A0 =A0void __iomem * =A0 =A0 =A0 =A0 =A0ioaddr; =A0 =A0 =A0 =
=A0 /* Mapped address */
>=20
> Just a cosmetic hint: I suggest SDHCI_QUIRK_MULTIBLOCK_READ_AUTO_CMD12
> or something for the quirk name, because ACMD12 part might be confused
> with MMC/SD App CMD 12 (CMD55+CMD12 combo) if/whenever that gets used.
Thanks for the suggestion.
There are several ACMD12 needed to be updated.
Send a new patch to update it.
Roy
^ permalink raw reply
* RE: [PATCH 1/3 v2] sdhci: Add auto CMD12 support for eSDHC driver
From: Zang Roy-R61911 @ 2010-08-10 10:04 UTC (permalink / raw)
To: Anton Vorontsov, Grant Likely; +Cc: linuxppc-dev, akpm, linux-mmc
In-Reply-To: <20100809174333.GC7665@oksana.dev.rtsoft.ru>
=20
> -----Original Message-----
> From: Anton Vorontsov [mailto:cbouatmailru@gmail.com]=20
> Sent: Tuesday, August 10, 2010 1:44 AM
> To: Grant Likely
> Cc: Zang Roy-R61911; linuxppc-dev@ozlabs.org;=20
> akpm@linux-foundation.org; linux-mmc@vger.kernel.org
> Subject: Re: [PATCH 1/3 v2] sdhci: Add auto CMD12 support for=20
> eSDHC driver
>=20
> On Wed, Aug 04, 2010 at 07:02:56PM -0600, Grant Likely wrote:
> > On Mon, Aug 2, 2010 at 9:11 PM, Roy Zang=20
> <tie-fei.zang@freescale.com> wrote:
> > > From: Jerry Huang <Chang-Ming.Huang@freescale.com>
> > >
> > > Add auto CMD12 command support for eSDHC driver.
> > > This is needed by P4080 and P1022 for block read/write.
> > > Manual asynchronous CMD12 abort operation causes protocol=20
> violations on
> > > these silicons.
> > >
> > > Signed-off-by: Jerry Huang <Chang-Ming.Huang@freescale.com>
> > > Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
> > > ---
> > > =A0drivers/mmc/host/sdhci-of-core.c | =A0 =A04 ++++
> > > =A0drivers/mmc/host/sdhci.c =A0 =A0 =A0 =A0 | =A0 14 =
++++++++++++--
> > > =A0drivers/mmc/host/sdhci.h =A0 =A0 =A0 =A0 | =A0 =A02 ++
> > > =A03 files changed, 18 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> > > index c6d1bd8..a92566e 100644
> > > --- a/drivers/mmc/host/sdhci.c
> > > +++ b/drivers/mmc/host/sdhci.c
> > > @@ -817,8 +817,12 @@ static void=20
> sdhci_set_transfer_mode(struct sdhci_host *host,
> > > =A0 =A0 =A0 =A0WARN_ON(!host->data);
> > >
> > > =A0 =A0 =A0 =A0mode =3D SDHCI_TRNS_BLK_CNT_EN;
> > > - =A0 =A0 =A0 if (data->blocks > 1)
> > > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 mode |=3D SDHCI_TRNS_MULTI;
> > > + =A0 =A0 =A0 if (data->blocks > 1) {
> > > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (host->quirks &=20
> SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12)
> > > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mode |=3D =
SDHCI_TRNS_MULTI |=20
> SDHCI_TRNS_ACMD12;
> > > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 else
> > > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mode |=3D =
SDHCI_TRNS_MULTI;
> >=20
> > nit:
> > + mode |=3D SDHCI_TRNS_MULTI;
> > + if (host->quirks &=20
> SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12)
> > + mode |=3D SDHCI_TRNS_ACMD12;
> >=20
> > Clearer, no?
>=20
> Much clearer. I would prefer the nit incorporated.
Agree.
>=20
> Another nit:
>=20
> > @@ -154,6 +154,10 @@ static int __devinit=20
> sdhci_of_probe(struct of_device *ofdev,
> > host->ops =3D &sdhci_of_data->ops;
> > }
> >=20
> > + if (of_get_property(np, "sdhci,auto-cmd12", NULL))
> > + host->quirks |=3D =
SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12;
> > +
> > + =20
>=20
> ^^ No need for the two empty lines.
Agree.
>=20
> > if (of_get_property(np, "sdhci,1-bit-only", NULL))
>=20
> Though, technically the patch looks OK, feel free to add my
>=20
> Acked-by: Anton Vorontsov <cbouatmailru@gmail.com>
I send a new patch to fix the nip. you are Cced.
Thanks.
Roy
^ permalink raw reply
* [PATCH 2/2] mmc: some nip clean up for the sdhci driver
From: Roy Zang @ 2010-08-10 9:47 UTC (permalink / raw)
To: akpm, linux-mmc; +Cc: linuxppc-dev, mirqus
In-Reply-To: <1281433632-18758-1-git-send-email-tie-fei.zang@freescale.com>
remove the extra line and rewrite the if condition line.
Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
---
drivers/mmc/host/sdhci-of-core.c | 1 -
drivers/mmc/host/sdhci.c | 5 ++---
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/host/sdhci-of-core.c b/drivers/mmc/host/sdhci-of-core.c
index d059805..732cffd 100644
--- a/drivers/mmc/host/sdhci-of-core.c
+++ b/drivers/mmc/host/sdhci-of-core.c
@@ -157,7 +157,6 @@ static int __devinit sdhci_of_probe(struct of_device *ofdev,
if (of_get_property(np, "sdhci,auto-cmd12", NULL))
host->quirks |= SDHCI_QUIRK_MULTIBLOCK_READ_AUTO_CMD12;
-
if (of_get_property(np, "sdhci,1-bit-only", NULL))
host->quirks |= SDHCI_QUIRK_FORCE_1_BIT_DATA;
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 4b7b2d5..a1e6269 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -818,10 +818,9 @@ static void sdhci_set_transfer_mode(struct sdhci_host *host,
mode = SDHCI_TRNS_BLK_CNT_EN;
if (data->blocks > 1) {
+ mode |= SDHCI_TRNS_MULTI;
if (host->quirks & SDHCI_QUIRK_MULTIBLOCK_READ_AUTO_CMD12)
- mode |= SDHCI_TRNS_MULTI | SDHCI_TRNS_AUTO_CMD12;
- else
- mode |= SDHCI_TRNS_MULTI;
+ mode |= SDHCI_TRNS_AUTO_CMD12;
}
if (data->flags & MMC_DATA_READ)
mode |= SDHCI_TRNS_READ;
--
1.5.6.5
^ permalink raw reply related
* [PATCH 1/2] mmc: change ACMD12 to AUTO_CMD12 for more clear
From: Roy Zang @ 2010-08-10 9:47 UTC (permalink / raw)
To: akpm, linux-mmc; +Cc: linuxppc-dev, mirqus
Change ACMD12 to AUTO_CMD12 to reduce the confusion.
ACMD12 might be confused with MMC/SD App CMD 12 (CMD55+CMD12 combo).
Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
---
drivers/mmc/host/sdhci-of-core.c | 2 +-
drivers/mmc/host/sdhci.c | 8 ++++----
drivers/mmc/host/sdhci.h | 10 +++++-----
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/mmc/host/sdhci-of-core.c b/drivers/mmc/host/sdhci-of-core.c
index dd1bdd1..d059805 100644
--- a/drivers/mmc/host/sdhci-of-core.c
+++ b/drivers/mmc/host/sdhci-of-core.c
@@ -155,7 +155,7 @@ static int __devinit sdhci_of_probe(struct of_device *ofdev,
}
if (of_get_property(np, "sdhci,auto-cmd12", NULL))
- host->quirks |= SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12;
+ host->quirks |= SDHCI_QUIRK_MULTIBLOCK_READ_AUTO_CMD12;
if (of_get_property(np, "sdhci,1-bit-only", NULL))
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index a92566e..4b7b2d5 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -73,7 +73,7 @@ static void sdhci_dumpregs(struct sdhci_host *host)
sdhci_readl(host, SDHCI_INT_ENABLE),
sdhci_readl(host, SDHCI_SIGNAL_ENABLE));
printk(KERN_DEBUG DRIVER_NAME ": AC12 err: 0x%08x | Slot int: 0x%08x\n",
- sdhci_readw(host, SDHCI_ACMD12_ERR),
+ sdhci_readw(host, SDHCI_AUTO_CMD12_ERR),
sdhci_readw(host, SDHCI_SLOT_INT_STATUS));
printk(KERN_DEBUG DRIVER_NAME ": Caps: 0x%08x | Max curr: 0x%08x\n",
sdhci_readl(host, SDHCI_CAPABILITIES),
@@ -818,8 +818,8 @@ static void sdhci_set_transfer_mode(struct sdhci_host *host,
mode = SDHCI_TRNS_BLK_CNT_EN;
if (data->blocks > 1) {
- if (host->quirks & SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12)
- mode |= SDHCI_TRNS_MULTI | SDHCI_TRNS_ACMD12;
+ if (host->quirks & SDHCI_QUIRK_MULTIBLOCK_READ_AUTO_CMD12)
+ mode |= SDHCI_TRNS_MULTI | SDHCI_TRNS_AUTO_CMD12;
else
mode |= SDHCI_TRNS_MULTI;
}
@@ -1112,7 +1112,7 @@ static void sdhci_request(struct mmc_host *mmc, struct mmc_request *mrq)
#ifndef SDHCI_USE_LEDS_CLASS
sdhci_activate_led(host);
#endif
- if (host->quirks & SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12) {
+ if (host->quirks & SDHCI_QUIRK_MULTIBLOCK_READ_AUTO_CMD12) {
if (mrq->stop) {
mrq->data->stop = NULL;
mrq->stop = NULL;
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 8fb088c..dfe1c4a 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -32,7 +32,7 @@
#define SDHCI_TRANSFER_MODE 0x0C
#define SDHCI_TRNS_DMA 0x01
#define SDHCI_TRNS_BLK_CNT_EN 0x02
-#define SDHCI_TRNS_ACMD12 0x04
+#define SDHCI_TRNS_AUTO_CMD12 0x04
#define SDHCI_TRNS_READ 0x10
#define SDHCI_TRNS_MULTI 0x20
@@ -116,7 +116,7 @@
#define SDHCI_INT_DATA_CRC 0x00200000
#define SDHCI_INT_DATA_END_BIT 0x00400000
#define SDHCI_INT_BUS_POWER 0x00800000
-#define SDHCI_INT_ACMD12ERR 0x01000000
+#define SDHCI_INT_AUTO_CMD12_ERR 0x01000000
#define SDHCI_INT_ADMA_ERROR 0x02000000
#define SDHCI_INT_NORMAL_MASK 0x00007FFF
@@ -130,7 +130,7 @@
SDHCI_INT_DATA_END_BIT | SDHCI_INT_ADMA_ERROR)
#define SDHCI_INT_ALL_MASK ((unsigned int)-1)
-#define SDHCI_ACMD12_ERR 0x3C
+#define SDHCI_AUTO_CMD12_ERR 0x3C
/* 3E-3F reserved */
@@ -157,7 +157,7 @@
/* 4C-4F reserved for more max current */
-#define SDHCI_SET_ACMD12_ERROR 0x50
+#define SDHCI_SET_AUTO_CMD12_ERROR 0x50
#define SDHCI_SET_INT_ERROR 0x52
#define SDHCI_ADMA_ERROR 0x54
@@ -241,7 +241,7 @@ struct sdhci_host {
/* Controller cannot support End Attribute in NOP ADMA descriptor */
#define SDHCI_QUIRK_NO_ENDATTR_IN_NOPDESC (1<<26)
/* Controller uses Auto CMD12 command to stop the transfer */
-#define SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 (1<<27)
+#define SDHCI_QUIRK_MULTIBLOCK_READ_AUTO_CMD12 (1<<27)
int irq; /* Device IRQ */
void __iomem * ioaddr; /* Mapped address */
--
1.5.6.5
^ permalink raw reply related
* RE: [PATCH 1/3 v2] sdhci: Add auto CMD12 support for eSDHC driver
From: Zang Roy-R61911 @ 2010-08-10 9:47 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, akpm, linux-mmc
In-Reply-To: <AANLkTinJKO3-iXOXuL7CMWCj5qMMHyMrtnadwPpqTeBu@mail.gmail.com>
=20
> -----Original Message-----
> From: glikely@secretlab.ca [mailto:glikely@secretlab.ca] On=20
> Behalf Of Grant Likely
> Sent: Thursday, August 05, 2010 9:03 AM
> To: Zang Roy-R61911
> Cc: linux-mmc@vger.kernel.org; linuxppc-dev@ozlabs.org;=20
> akpm@linux-foundation.org
> Subject: Re: [PATCH 1/3 v2] sdhci: Add auto CMD12 support for=20
> eSDHC driver
>=20
> On Mon, Aug 2, 2010 at 9:11 PM, Roy Zang=20
> <tie-fei.zang@freescale.com> wrote:
> > From: Jerry Huang <Chang-Ming.Huang@freescale.com>
> >
> > Add auto CMD12 command support for eSDHC driver.
> > This is needed by P4080 and P1022 for block read/write.
> > Manual asynchronous CMD12 abort operation causes protocol=20
> violations on
> > these silicons.
> >
> > Signed-off-by: Jerry Huang <Chang-Ming.Huang@freescale.com>
> > Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
> > ---
> > =A0drivers/mmc/host/sdhci-of-core.c | =A0 =A04 ++++
> > =A0drivers/mmc/host/sdhci.c =A0 =A0 =A0 =A0 | =A0 14 ++++++++++++--
> > =A0drivers/mmc/host/sdhci.h =A0 =A0 =A0 =A0 | =A0 =A02 ++
> > =A03 files changed, 18 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> > index c6d1bd8..a92566e 100644
> > --- a/drivers/mmc/host/sdhci.c
> > +++ b/drivers/mmc/host/sdhci.c
> > @@ -817,8 +817,12 @@ static void=20
> sdhci_set_transfer_mode(struct sdhci_host *host,
> > =A0 =A0 =A0 =A0WARN_ON(!host->data);
> >
> > =A0 =A0 =A0 =A0mode =3D SDHCI_TRNS_BLK_CNT_EN;
> > - =A0 =A0 =A0 if (data->blocks > 1)
> > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 mode |=3D SDHCI_TRNS_MULTI;
> > + =A0 =A0 =A0 if (data->blocks > 1) {
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (host->quirks &=20
> SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12)
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mode |=3D =
SDHCI_TRNS_MULTI |=20
> SDHCI_TRNS_ACMD12;
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 else
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mode |=3D =
SDHCI_TRNS_MULTI;
>=20
> nit:
> + mode |=3D SDHCI_TRNS_MULTI;
> + if (host->quirks & SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12)
> + mode |=3D SDHCI_TRNS_ACMD12;
>=20
> Clearer, no?
It is clear.
Thanks.
Roy
^ permalink raw reply
* Re: [spi-devel-general] [PATCH v2 3/6] mtd: m25p80: add support to parse the SPI flash's partitions
From: Grant Likely @ 2010-08-10 7:16 UTC (permalink / raw)
To: David Brownell; +Cc: linuxppc-dev, Mingkai Hu, kumar.gala, spi-devel-general
In-Reply-To: <796604.30863.qm@web180307.mail.gq1.yahoo.com>
On Tue, Aug 10, 2010 at 1:14 AM, David Brownell <david-b@pacbell.net> wrote=
:
>
>
> --- On Mon, 8/9/10, Grant Likely <grant.likely@secretlab.ca> wrote:
>
>
>> > + =A0 =A0 =A0 nr_parts =3D
>> of_mtd_parse_partitions(&spi->dev, np, &parts);
>
> Let's keep OF-specific logic out of drivers like
> this one ... =A0intended to work without OF.
>
> NAK on adding dependencies like OF to drivers
> and other infrastructure that starts generic.
The OF hooks compile to no-ops when CONFIG_OF is disabled. I've been
very careful about that.
g.
^ permalink raw reply
* Re: [spi-devel-general] [PATCH v2 3/6] mtd: m25p80: add support to parse the SPI flash's partitions
From: David Brownell @ 2010-08-10 7:14 UTC (permalink / raw)
To: Mingkai Hu, Grant Likely; +Cc: linuxppc-dev, kumar.gala, spi-devel-general
In-Reply-To: <AANLkTik9cy+at2n28U+Mut4RD6_cJ9uRZzjf+H86d-rp@mail.gmail.com>
=0A=0A--- On Mon, 8/9/10, Grant Likely <grant.likely@secretlab.ca> wrote:=
=0A=0A=0A> > + =A0 =A0 =A0 nr_parts =3D=0A> of_mtd_parse_partitions(&spi->d=
ev, np, &parts);=0A=0ALet's keep OF-specific logic out of drivers like=0Ath=
is one ... intended to work without OF.=0A=0ANAK on adding dependencies li=
ke OF to drivers=0Aand other infrastructure that starts generic.
^ permalink raw reply
* Re: [PATCH v2 6/6] DTS: add SPI flash(s25fl128p01) support on p4080ds and mpc8536ds board
From: Grant Likely @ 2010-08-10 7:10 UTC (permalink / raw)
To: Mingkai Hu; +Cc: linuxppc-dev, kumar.gala, spi-devel-general
In-Reply-To: <1280735524-17547-7-git-send-email-Mingkai.hu@freescale.com>
SGkgTWluZ2thaSwKCm9uZSBjb21tZW50IGJlbG93LiAgT3RoZXJ3aXNlIHRoaXMgcGF0Y2ggbG9v
a3MgZ29vZCwgYW5kIHNvIGRvZXMgcGF0Y2ggNS4KCmcuCgpPbiBNb24sIEF1ZyAyLCAyMDEwIGF0
IDE6NTIgQU0sIE1pbmdrYWkgSHUgPE1pbmdrYWkuaHVAZnJlZXNjYWxlLmNvbT4gd3JvdGU6Cj4g
U2lnbmVkLW9mZi1ieTogTWluZ2thaSBIdSA8TWluZ2thaS5odUBmcmVlc2NhbGUuY29tPgo+IC0t
LQo+Cj4gdjI6Cj4goC0gUmVtb3ZlIHRoZSB3aGl0ZXNwYWNlIGluY29uc2l0ZW5jaWVzCj4KPiCg
YXJjaC9wb3dlcnBjL2Jvb3QvZHRzL21wYzg1MzZkcy5kdHMgfCCgIDUyICsrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrCj4goGFyY2gvcG93ZXJwYy9ib290L2R0cy9wNDA4MGRzLmR0
cyCgIHwgoCAxMSArKystLS0tLQo+IKAyIGZpbGVzIGNoYW5nZWQsIDU2IGluc2VydGlvbnMoKyks
IDcgZGVsZXRpb25zKC0pCj4KPiBkaWZmIC0tZ2l0IGEvYXJjaC9wb3dlcnBjL2Jvb3QvZHRzL21w
Yzg1MzZkcy5kdHMgYi9hcmNoL3Bvd2VycGMvYm9vdC9kdHMvbXBjODUzNmRzLmR0cwo+IGluZGV4
IDgxNWNlYmIuLmE3NWMxMGUgMTAwNjQ0Cj4gLS0tIGEvYXJjaC9wb3dlcnBjL2Jvb3QvZHRzL21w
Yzg1MzZkcy5kdHMKPiArKysgYi9hcmNoL3Bvd2VycGMvYm9vdC9kdHMvbXBjODUzNmRzLmR0cwo+
IEBAIC0xMDgsNiArMTA4LDU4IEBACj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKB9Owo+IKAgoCCg
IKAgoCCgIKAgoH07Cj4KPiArIKAgoCCgIKAgoCCgIKAgc3BpQDcwMDAgewo+ICsgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgICNhZGRyZXNzLWNlbGxzID0gPDE+Owo+ICsgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgICNzaXplLWNlbGxzID0gPDA+Owo+ICsgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIGNvbXBhdGli
bGUgPSAiZnNsLG1wYzg1MzYtZXNwaSI7Cj4gKyCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgcmVnID0g
PDB4NzAwMCAweDEwMDA+Owo+ICsgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIGludGVycnVwdHMgPSA8
NTkgMHgyPjsKPiArIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBpbnRlcnJ1cHQtcGFyZW50ID0gPCZt
cGljPjsKPiArIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBmc2wsZXNwaS1udW0tY2hpcHNlbGVjdHMg
PSA8ND47Cj4gKwo+ICsgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIGZsYXNoQDAgewo+ICsgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgI2FkZHJlc3MtY2VsbHMgPSA8MT47Cj4gKyCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCAjc2l6ZS1jZWxscyA9IDwxPjsKPiArIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIGNvbXBhdGlibGUgPSAic3BhbnNpb24sczI1c2wxMjgwMSI7Cj4g
KyCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCByZWcgPSA8MD47Cj4gKyCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCBzcGktbWF4LWZyZXF1ZW5jeSA9IDw0MDAwMDAwMD47Cj4gKyCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBwYXJ0aXRpb25AdS1ib290IHsKPiArIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgbGFiZWwgPSAidS1ib290IjsKPiArIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgcmVnID0gPDB4MDAwMDAwMDAgMHgw
MDEwMDAwMD47Cj4gKyCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIHJlYWQt
b25seTsKPiArIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIH07Cj4gKyCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCBwYXJ0aXRpb25Aa2VybmVsIHsKPiArIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgbGFiZWwgPSAia2VybmVsIjsKPiArIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgcmVnID0gPDB4MDAxMDAwMDAgMHgwMDUwMDAwMD47
Cj4gKyCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIHJlYWQtb25seTsKPiAr
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIH07Cj4gKyCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCBwYXJ0aXRpb25AZHRiIHsKPiArIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgbGFiZWwgPSAiZHRiIjsKPiArIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgcmVnID0gPDB4MDA2MDAwMDAgMHgwMDEwMDAwMD47Cj4gKyCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIHJlYWQtb25seTsKPiArIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIH07Cj4gKyCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBwYXJ0
aXRpb25AZnMgewo+ICsgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBsYWJl
bCA9ICJmaWxlIHN5c3RlbSI7Cj4gKyCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIHJlZyA9IDwweDAwNzAwMDAwIDB4MDA5MDAwMDA+Owo+ICsgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgfTsKPiArIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCB9Owo+ICsgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIGZsYXNoQDEgewo+ICsgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
Y29tcGF0aWJsZSA9ICJzcGFuc2lvbixzMjVzbDEyODAxIjsKPiArIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIHJlZyA9IDwxPjsKPiArIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IHNwaS1tYXgtZnJlcXVlbmN5ID0gPDQwMDAwMDAwPjsKPiArIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCB9Owo+ICsgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIGZsYXNoQDIgewo+ICsgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgY29tcGF0aWJsZSA9ICJzcGFuc2lvbixzMjVzbDEyODAxIjsKPiAr
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIHJlZyA9IDwyPjsKPiArIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIHNwaS1tYXgtZnJlcXVlbmN5ID0gPDQwMDAwMDAwPjsKPiArIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCB9Owo+ICsgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIGZsYXNoQDMg
ewo+ICsgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgY29tcGF0aWJsZSA9ICJzcGFuc2lv
bixzMjVzbDEyODAxIjsKPiArIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIHJlZyA9IDwz
PjsKPiArIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIHNwaS1tYXgtZnJlcXVlbmN5ID0g
PDQwMDAwMDAwPjsKPiArIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCB9Owo+ICsgoCCgIKAgoCCgIKAg
oCB9Owo+ICsKPiCgIKAgoCCgIKAgoCCgIKBkbWFAMjEzMDAgewo+IKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgI2FkZHJlc3MtY2VsbHMgPSA8MT47Cj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAjc2l6
ZS1jZWxscyA9IDwxPjsKPiBkaWZmIC0tZ2l0IGEvYXJjaC9wb3dlcnBjL2Jvb3QvZHRzL3A0MDgw
ZHMuZHRzIGIvYXJjaC9wb3dlcnBjL2Jvb3QvZHRzL3A0MDgwZHMuZHRzCj4gaW5kZXggNmIyOWVh
Yi4uNDg0MzdhZCAxMDA2NDQKPiAtLS0gYS9hcmNoL3Bvd2VycGMvYm9vdC9kdHMvcDQwODBkcy5k
dHMKPiArKysgYi9hcmNoL3Bvd2VycGMvYm9vdC9kdHMvcDQwODBkcy5kdHMKPiBAQCAtMjM2LDIy
ICsyMzYsMTkgQEAKPiCgIKAgoCCgIKAgoCCgIKB9Owo+Cj4goCCgIKAgoCCgIKAgoCCgc3BpQDEx
MDAwMCB7Cj4gLSCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgY2VsbC1pbmRleCA9IDwwPjsKPiCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCNhZGRyZXNzLWNlbGxzID0gPDE+Owo+IKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgI3NpemUtY2VsbHMgPSA8MD47Cj4gLSCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgY29t
cGF0aWJsZSA9ICJmc2wsZXNwaSI7Cj4gKyCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgY29tcGF0aWJs
ZSA9ICJmc2wsbXBjODUzNi1lc3BpIjsKClNob3VsZCBiZSBtb3JlIHNwZWNpZmljIGhlcmUgYnkg
c3BlY2lmeWluZyB0aGUgZXhhY3QgZGV2aWNlOyBwbHVzIGEKbGlzdCBvZiB3aGF0IGl0IGlzIGNv
bXBhdGlibGUgd2l0aC4gIEZvciBleGFtcGxlOgoKY29tcGF0aWJsZSA9ICJmc2wscDQwODAtZXNw
aSIsICJmc2wsbXBjNTgzNi1lc3BpIjsKCnRoZSByZWFzb24gZm9yIHRoaXMgaXMgdGhhdCB0aGUg
ZHJpdmVyIGZvciB0aGUgZXhpc3RpbmcgcGFydCBpcyBzdGlsbAphYmxlIHRvIGJpbmQgYWdhaW5z
dCB0aGUgbm9kZSwgYnV0IGlmIGl0IGV2ZXIgbmVlZHMgaXQsIHRoZW4KaW5mb3JtYXRpb24gYWJv
dXQgdGhlIHNwZWNpZmljIGRldmljZSBpcyBhdmFpbGFibGUgd2hpY2ggY2FuIGJlIHVzZWQKdG8g
KGZvciBleGFtcGxlKSBmaWd1cmUgb3V0IHdoZW4gdG8gZW5hYmxlIHNpbGljb24gYnVnIHdvcmth
cm91bmRzLgoKPiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoHJlZyA9IDwweDExMDAwMCAweDEwMDA+
Owo+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgaW50ZXJydXB0cyA9IDw1MyAweDI+Owo+IKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgaW50ZXJydXB0LXBhcmVudCA9IDwmbXBpYz47Cj4gLSCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgZXNwaSxudW0tc3MtYml0cyA9IDw0PjsKPiAtIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCBtb2RlID0gImNwdSI7Cj4gKyCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgZnNsLGVzcGkt
bnVtLWNoaXBzZWxlY3RzID0gPDQ+Owo+Cj4gLSCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgZnNsX20y
NXA4MEAwIHsKPiArIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBmbGFzaEAwIHsKPiCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgI2FkZHJlc3MtY2VsbHMgPSA8MT47Cj4goCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCNzaXplLWNlbGxzID0gPDE+Owo+IC0goCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgY29tcGF0aWJsZSA9ICJmc2wsZXNwaS1mbGFzaCI7Cj4gKyCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBjb21wYXRpYmxlID0gInNwYW5zaW9uLHMyNXNsMTI4MDEi
Owo+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKByZWcgPSA8MD47Cj4gLSCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBsaW51eCxtb2RhbGlhcyA9ICJmc2xfbTI1cDgwIjsKPiCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgc3BpLW1heC1mcmVxdWVuY3kgPSA8NDAwMDAw
MDA+OyAvKiBpbnB1dCBjbG9jayAqLwo+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKBw
YXJ0aXRpb25AdS1ib290IHsKPiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKBsYWJlbCA9ICJ1LWJvb3QiOwo+IC0tCj4gMS42LjQKPgo+Cj4KCgoKLS0gCkdyYW50IExpa2Vs
eSwgQi5TYy4sIFAuRW5nLgpTZWNyZXQgTGFiIFRlY2hub2xvZ2llcyBMdGQuCg==
^ permalink raw reply
* Re: mpc870: hctosys.c unable to open rtc device rtc0
From: Shawn Jin @ 2010-08-10 7:07 UTC (permalink / raw)
To: Scott Wood; +Cc: ppcdev
In-Reply-To: <AANLkTim4tGYAyCMxHG8nPLKL4dHepB2Pp4Kxq4bNcsJE@mail.gmail.com>
> Thanks Scott for the confirmation. I added that to my dts file and the
> driver did try to probe the device. But accessing the device timed
> out. There are some microcode patches related to I2C that I've not
> applied. I'll try the patch(es) later. But how can I find out which
> patch should be applied to my MPC870?
:(, the I2C_SPI patch doesn't do any help. It still gets timeout when
probing the device. The slave address of DS1339 is 0x68. Here are the
debug messages. Before hooking up the oscilloscope, any quick hints
for me to try? The 2.4 kernel worked OK, BTW.
i2c-core: driver [rtc-ds1307] registered
i2c /dev entries driver
i2c-core: driver [dev_driver] registered
fsl-i2c-cpm fa200860.i2c: cpm_i2c_setup()
alloc irq_desc for 21 on node 0
alloc kstat_irqs on node 0
irq: irq 16 on host /soc@fa200000/cpm@9c0/interrupt-controller@930
mapped to virtual irq 21
fsl-i2c-cpm fa200860.i2c: i2c_ram 0xfddfa500, i2c_addr 0x0500, freq 60000
fsl-i2c-cpm fa200860.i2c: tbase 0x0340, rbase 0x0360
i2c i2c-0: adapter [i2c-cpm] registered
i2c-dev: adapter [i2c-cpm] registered as minor 0
fsl-i2c-cpm fa200860.i2c: hw routines for i2c-cpm registered.
i2c 0-0068: uevent
rtc-ds1307 0-0068: probe
i2c i2c-0: master_xfer[0] W, addr=0x68, len=1
i2c i2c-0: master_xfer[1] R, addr=0x68, len=2
i2c i2c-0: R: 0 T: 0
i2c i2c-0: cpm_i2c_write(abyte=0xd0)
i2c i2c-0: R: 0 T: 1
i2c i2c-0: cpm_i2c_read(abyte=0xd1)
i2c i2c-0: test ready.
i2c i2c-0: Interrupt: 2
i2c i2c-0: ready.
i2c i2c-0: tx sc 0 0x1400
i2c i2c-0: test ready.
i2c i2c-0: I2C transfer: timeout
i2c i2c-0: cpm_i2c_force_close()
rtc-ds1307: probe of 0-0068 failed with error -5
i2c i2c-0: client [ds1339] registered with bus id 0-0068
i2c-core: driver [lm75] registered
TCP cubic registered
NET: Registered protocol family 17
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
Freeing unused kernel memory: 1512k init
Thanks,
-Shawn.
^ permalink raw reply
* Re: [PATCH v2 4/6] mtd: m25p80: add a read function to read page by page
From: Grant Likely @ 2010-08-10 7:00 UTC (permalink / raw)
To: Mingkai Hu, David Woodhouse; +Cc: linuxppc-dev, kumar.gala, spi-devel-general
In-Reply-To: <1280735524-17547-5-git-send-email-Mingkai.hu@freescale.com>
[adding David Woodhouse]
(Btw, you should cc: David Woodhouse and the mtd list on the MTD patches).
On Mon, Aug 2, 2010 at 1:52 AM, Mingkai Hu <Mingkai.hu@freescale.com> wrote=
:
> For Freescale's eSPI controller, the max transaction length one time
> is limitted by the SPCOM[TRANSLEN] field which is 0xFFFF. When used
> mkfs.ext2 command to create ext2 filesystem on the flash, the read
> length will exceed the max value of the SPCOM[TRANSLEN] field, so
> change the read function to read page by page.
>
> For other SPI flash driver, also needed to supply the read function
> if used the eSPI controller.
>
> Signed-off-by: Mingkai Hu <Mingkai.hu@freescale.com>
This one bothers me, but I can't put my finger on it. The flag feels
like a controller specific hack. David, can you take a look at this
patch?
g.
> ---
>
> v2:
> =A0- Add SPI_MASTER_TRANS_LIMIT flag to indicate the master's trans lengt=
h
> =A0 limitation, so the MTD driver can select the correct transfer behavio=
ur
> =A0 at driver probe time
>
> =A0drivers/mtd/devices/m25p80.c | =A0 78 ++++++++++++++++++++++++++++++++=
++++++++++
> =A0drivers/spi/spi_fsl_espi.c =A0 | =A0 =A01 +
> =A0include/linux/spi/spi.h =A0 =A0 =A0| =A0 =A01 +
> =A03 files changed, 80 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
> index 5f00075..30e4568 100644
> --- a/drivers/mtd/devices/m25p80.c
> +++ b/drivers/mtd/devices/m25p80.c
> @@ -376,6 +376,81 @@ static int m25p80_read(struct mtd_info *mtd, loff_t =
from, size_t len,
> =A0}
>
> =A0/*
> + * Read an address range from the flash chip page by page.
> + * Some controller has transaction length limitation such as the
> + * Freescale's eSPI controller can only trasmit 0xFFFF bytes one
> + * time, so we have to read page by page if the len is more than
> + * the limitation.
> + */
> +static int m25p80_page_read(struct mtd_info *mtd, loff_t from, size_t le=
n,
> + =A0 =A0 =A0 size_t *retlen, u_char *buf)
> +{
> + =A0 =A0 =A0 struct m25p *flash =3D mtd_to_m25p(mtd);
> + =A0 =A0 =A0 struct spi_transfer t[2];
> + =A0 =A0 =A0 struct spi_message m;
> + =A0 =A0 =A0 u32 i, page_size =3D 0;
> +
> + =A0 =A0 =A0 DEBUG(MTD_DEBUG_LEVEL2, "%s: %s %s 0x%08x, len %zd\n",
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_name(&flash->spi->dev),=
__func__, "from",
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (u32)from, len);
> +
> + =A0 =A0 =A0 /* sanity checks */
> + =A0 =A0 =A0 if (!len)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return 0;
> +
> + =A0 =A0 =A0 if (from + len > flash->mtd.size)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -EINVAL;
> +
> + =A0 =A0 =A0 spi_message_init(&m);
> + =A0 =A0 =A0 memset(t, 0, (sizeof t));
> +
> + =A0 =A0 =A0 /* NOTE:
> + =A0 =A0 =A0 =A0* OPCODE_FAST_READ (if available) is faster.
> + =A0 =A0 =A0 =A0* Should add 1 byte DUMMY_BYTE.
> + =A0 =A0 =A0 =A0*/
> + =A0 =A0 =A0 t[0].tx_buf =3D flash->command;
> + =A0 =A0 =A0 t[0].len =3D m25p_cmdsz(flash) + FAST_READ_DUMMY_BYTE;
> + =A0 =A0 =A0 spi_message_add_tail(&t[0], &m);
> +
> + =A0 =A0 =A0 t[1].rx_buf =3D buf;
> + =A0 =A0 =A0 spi_message_add_tail(&t[1], &m);
> +
> + =A0 =A0 =A0 /* Byte count starts at zero. */
> + =A0 =A0 =A0 if (retlen)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 *retlen =3D 0;
> +
> + =A0 =A0 =A0 mutex_lock(&flash->lock);
> +
> + =A0 =A0 =A0 /* Wait till previous write/erase is done. */
> + =A0 =A0 =A0 if (wait_till_ready(flash)) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* REVISIT status return?? */
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 mutex_unlock(&flash->lock);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return 1;
> + =A0 =A0 =A0 }
> +
> + =A0 =A0 =A0 /* Set up the write data buffer. */
> + =A0 =A0 =A0 flash->command[0] =3D OPCODE_READ;
> +
> + =A0 =A0 =A0 for (i =3D page_size; i < len; i +=3D page_size) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 page_size =3D len - i;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (page_size > flash->page_size)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 page_size =3D flash->page_s=
ize;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 m25p_addr2cmd(flash, from + i, flash->comma=
nd);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 t[1].len =3D page_size;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 t[1].rx_buf =3D buf + i;
> +
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 spi_sync(flash->spi, &m);
> +
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 *retlen +=3D m.actual_length - m25p_cmdsz(f=
lash)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - FAST_READ_DUMMY_BYTE;
> + =A0 =A0 =A0 }
> +
> + =A0 =A0 =A0 mutex_unlock(&flash->lock);
> +
> + =A0 =A0 =A0 return 0;
> +}
> +
> +/*
> =A0* Write an address range to the flash chip. =A0Data must be written in
> =A0* FLASH_PAGESIZE chunks. =A0The address range may be any size provided
> =A0* it is within the physical boundaries.
> @@ -877,6 +952,9 @@ static int __devinit m25p_probe(struct spi_device *sp=
i)
> =A0 =A0 =A0 =A0flash->mtd.erase =3D m25p80_erase;
> =A0 =A0 =A0 =A0flash->mtd.read =3D m25p80_read;
>
> + =A0 =A0 =A0 if (spi->master->flags & SPI_MASTER_TRANS_LIMIT)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 flash->mtd.read =3D m25p80_page_read;
> +
> =A0 =A0 =A0 =A0/* sst flash chips use AAI word program */
> =A0 =A0 =A0 =A0if (info->jedec_id >> 16 =3D=3D 0xbf)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0flash->mtd.write =3D sst_write;
> diff --git a/drivers/spi/spi_fsl_espi.c b/drivers/spi/spi_fsl_espi.c
> index 61987cf..e15b7dc 100644
> --- a/drivers/spi/spi_fsl_espi.c
> +++ b/drivers/spi/spi_fsl_espi.c
> @@ -470,6 +470,7 @@ static struct spi_master * __devinit fsl_espi_probe(s=
truct device *dev,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto err_probe;
>
> =A0 =A0 =A0 =A0master->setup =3D fsl_espi_setup;
> + =A0 =A0 =A0 master->flags =3D SPI_MASTER_TRANS_LIMIT;
>
> =A0 =A0 =A0 =A0mpc8xxx_spi =3D spi_master_get_devdata(master);
> =A0 =A0 =A0 =A0mpc8xxx_spi->spi_do_one_msg =3D fsl_espi_do_one_msg;
> diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
> index af56071..0729cbd 100644
> --- a/include/linux/spi/spi.h
> +++ b/include/linux/spi/spi.h
> @@ -261,6 +261,7 @@ struct spi_master {
> =A0#define SPI_MASTER_HALF_DUPLEX BIT(0) =A0 =A0 =A0 =A0 =A0/* can't do f=
ull duplex */
> =A0#define SPI_MASTER_NO_RX =A0 =A0 =A0 BIT(1) =A0 =A0 =A0 =A0 =A0/* can'=
t do buffer read */
> =A0#define SPI_MASTER_NO_TX =A0 =A0 =A0 BIT(2) =A0 =A0 =A0 =A0 =A0/* can'=
t do buffer write */
> +#define SPI_MASTER_TRANS_LIMIT BIT(3) =A0 =A0 =A0 =A0 =A0/* have trans l=
ength limit */
>
> =A0 =A0 =A0 =A0/* Setup mode and clock, etc (spi driver may call many tim=
es).
> =A0 =A0 =A0 =A0 *
> --
> 1.6.4
>
>
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH v2 3/6] mtd: m25p80: add support to parse the SPI flash's partitions
From: Grant Likely @ 2010-08-10 6:56 UTC (permalink / raw)
To: Mingkai Hu; +Cc: linuxppc-dev, kumar.gala, spi-devel-general
In-Reply-To: <1280735524-17547-4-git-send-email-Mingkai.hu@freescale.com>
On Mon, Aug 2, 2010 at 1:52 AM, Mingkai Hu <Mingkai.hu@freescale.com> wrote=
:
> Signed-off-by: Mingkai Hu <Mingkai.hu@freescale.com>
> ---
>
> v2:
> =A0- Move the flash partition function from of_spi.c to MTD driver
>
> =A0drivers/mtd/devices/m25p80.c | =A0 29 +++++++++++++++++++++++++++++
> =A01 files changed, 29 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
> index 81e49a9..5f00075 100644
> --- a/drivers/mtd/devices/m25p80.c
> +++ b/drivers/mtd/devices/m25p80.c
> @@ -752,6 +752,31 @@ static const struct spi_device_id *__devinit jedec_p=
robe(struct spi_device *spi)
> =A0 =A0 =A0 =A0return NULL;
> =A0}
>
> +/*
> + * parse_flash_partition - Parse the flash partition on the SPI bus
> + * @spi: Pointer to spi_device device
> + */
> +void parse_flash_partition(struct spi_device *spi)
> +{
> + =A0 =A0 =A0 struct mtd_partition *parts;
> + =A0 =A0 =A0 struct flash_platform_data *pdata;
> + =A0 =A0 =A0 int nr_parts =3D 0;
> + =A0 =A0 =A0 struct device_node *np =3D spi->dev.of_node;
> +
> + =A0 =A0 =A0 nr_parts =3D of_mtd_parse_partitions(&spi->dev, np, &parts)=
;
> + =A0 =A0 =A0 if (!nr_parts)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return;
> +
> + =A0 =A0 =A0 pdata =3D kzalloc(sizeof(*pdata), GFP_KERNEL);
> + =A0 =A0 =A0 if (!pdata)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return;
> +
> + =A0 =A0 =A0 pdata->parts =3D parts;
> + =A0 =A0 =A0 pdata->nr_parts =3D nr_parts;
> + =A0 =A0 =A0 spi->dev.platform_data =3D pdata;
The driver is not allowed to write to the platform_data pointer in the
device structure because it leaves an absolute mess in trying to
figure out who owns the pdata pointer. Should it be freed when the
driver is unbound? Is it statically allocated? etc. There is a safer
way to get the data (see below).
> +
> + =A0 =A0 =A0 return;
> +}
>
> =A0/*
> =A0* board specific setup should have ensured the SPI clock used here
> @@ -771,6 +796,10 @@ static int __devinit m25p_probe(struct spi_device *s=
pi)
> =A0 =A0 =A0 =A0 * a chip ID, try the JEDEC id commands; they'll work for =
most
> =A0 =A0 =A0 =A0 * newer chips, even if we don't recognize the particular =
chip.
> =A0 =A0 =A0 =A0 */
> +
> + =A0 =A0 =A0 /* Parse the flash partition */
> + =A0 =A0 =A0 parse_flash_partition(spi);
> +
Doing this unconditionally is dangerous, and if a platform_data
structure is provided, then it must alwasy take precedence over the
device tree data (because the platform code has gone to extra lengths
to add a pdata structure; that must mean it is important!) :-)
Instead what can be done is to call of_mtd_parse_partitions() directly
from the probe routine after checking to see if the pdata structure
exists and has partition information. If it doesn't, then call
of_mtd_parse_partitions() to get values for parts and nr_parts. Doing
it that way completely eliminates the uncertainty over pdata pointer
ownership, and eliminates having an anonymous pointer buried in the
driver.
Cheers,
g.
^ permalink raw reply
* Re: [PATCH v2 2/6] eSPI: add eSPI controller support
From: Grant Likely @ 2010-08-10 6:44 UTC (permalink / raw)
To: Mingkai Hu; +Cc: linuxppc-dev, kumar.gala, spi-devel-general
In-Reply-To: <1280735524-17547-3-git-send-email-Mingkai.hu@freescale.com>
On Mon, Aug 2, 2010 at 1:52 AM, Mingkai Hu <Mingkai.hu@freescale.com> wrote=
:
> Add eSPI controller support based on the library code spi_fsl_lib.c.
>
> The eSPI controller is newer controller 85xx/Pxxx devices supported.
> There're some differences comparing to the SPI controller:
>
> 1. Has different register map and different bit definition
> =A0 So leave the code operated the register to the driver code, not
> =A0 the common code.
>
> 2. Support 4 dedicated chip selects
> =A0 The software can't controll the chip selects directly, The SPCOM[CS]
> =A0 field is used to select which chip selects is used, and the
> =A0 SPCOM[TRANLEN] field is set to tell the controller how long the CS
> =A0 signal need to be asserted. So the driver doesn't need the chipselect
> =A0 related function when transfering data, just set corresponding regist=
er
> =A0 fields to controll the chipseclect.
>
> 3. Different Transmit/Receive FIFO access register behavior
> =A0 For SPI controller, the Tx/Rx FIFO access register can hold only
> =A0 one character regardless of the character length, but for eSPI
> =A0 controller, the register can hold 4 or 2 characters according to
> =A0 the character lengths. Access the Tx/Rx FIFO access register of the
> =A0 eSPI controller will shift out/in 4/2 characters one time. For SPI
> =A0 subsystem, the command and data are put into different transfers, so
> =A0 we need to combine all the transfers to one transfer in order to pass
> =A0 the transfer to eSPI controller.
>
> Signed-off-by: Mingkai Hu <Mingkai.hu@freescale.com>
I've not dug deep into this patch, but it seems pretty good. I did
notice one thing below...
[...]
> diff --git a/drivers/spi/spi_fsl_lib.h b/drivers/spi/spi_fsl_lib.h
> index 774e1c8..0772c98 100644
> --- a/drivers/spi/spi_fsl_lib.h
> +++ b/drivers/spi/spi_fsl_lib.h
> @@ -22,10 +22,12 @@
> =A0struct mpc8xxx_spi {
> =A0 =A0 =A0 =A0struct device *dev;
> =A0 =A0 =A0 =A0struct fsl_spi_reg __iomem *base;
> + =A0 =A0 =A0 struct fsl_espi_reg __iomem *espi_base;
There's got to be a cleaner way to do this. Rather than putting both
pointers into mpc8xxx_spi, I suggest each driver use its own
fsl_spi_priv and fsl_espi_priv wrapper structures that contain the
controller specific properties.
cheers,
g.
^ permalink raw reply
* Re: [PATCH v2 1/6] spi/mpc8xxx: refactor the common code for SPI/eSPI controller
From: Grant Likely @ 2010-08-10 6:40 UTC (permalink / raw)
To: Mingkai Hu; +Cc: linuxppc-dev, kumar.gala, spi-devel-general
In-Reply-To: <1280735524-17547-2-git-send-email-Mingkai.hu@freescale.com>
On Mon, Aug 2, 2010 at 1:51 AM, Mingkai Hu <Mingkai.hu@freescale.com> wrote=
:
> Refactor the common code in file spi_mpc8xxx.c to spi_fsl_lib.c
> used by SPI/eSPI controller driver as a library, move the SPI
> controller driver to a new file spi_fsl_spi.c, and leave the
> QE/CPM SPI controller code in this file.
>
> Because the register map of the SPI controller and eSPI controller
> is so different, also leave the code operated the register to the
> driver code, not the common code.
>
> Signed-off-by: Mingkai Hu <Mingkai.hu@freescale.com>
> ---
> v2:
> =A0- Rename spi_mpc8xxx.c to spi_fsl_lib.c, also the config name
> =A0- Rename fsl_spi.c to spi_fsl_spi.c, also the config name
> =A0- Move register map definiton from spi_fsl_lib.c to spi_fsl_spi.c
> =A0- Break some funcions line in the arguments instead of the declaration
> =A0- Init bits_per_word to 0 to eliminate the else clause
> =A0- Add brace for the else clause to match if clause
> =A0- Drop the last entry's comma in the match table
> =A0- move module_init() immediately after the init fsl_spi_init() functio=
n
>
> =A0drivers/spi/Kconfig =A0 =A0 =A0 | =A0 20 +-
> =A0drivers/spi/Makefile =A0 =A0 =A0| =A0 =A03 +-
> =A0drivers/spi/spi_fsl_lib.c | =A0237 ++++++++
> =A0drivers/spi/spi_fsl_lib.h | =A0119 ++++
> =A0drivers/spi/spi_fsl_spi.c | 1173 +++++++++++++++++++++++++++++++++++++
> =A0drivers/spi/spi_mpc8xxx.c | 1421 -------------------------------------=
--------
This patch seems pretty good now. However, the rename from
spi_mpc8xxx.c to spi_fsl_lib.c should be done in a separate patch. It
is too difficult to track what has changed, when the file gets moved
at the same time. Move the file in one patch verbatim (with the
required Makefile change), and then move out the fsl_spi specific bits
in a second patch.
g.
^ permalink raw reply
* Re: Review Request: New proposal for device tree clock binding.
From: Grant Likely @ 2010-08-10 5:04 UTC (permalink / raw)
To: Li Yang-R58472; +Cc: devicetree-discuss, linuxppc-dev, Jeremy Kerr
In-Reply-To: <F9BD3E0A8083BE4ABAA94D7EDD7E3F631093B6@zch01exm26.fsl.freescale.net>
On Mon, Aug 9, 2010 at 10:56 PM, Li Yang-R58472 <r58472@freescale.com> wrot=
e:
>>>> I've avoided requiring clock nodes to have a separate sub node for
>>>> each output because it is more verbose and it prevents clock
>>>> providers from having child nodes for other purposes. =A0Are you
>>>> concerned that
>>>
>>> I don't see why there should be child nodes for other purposes under
>>clock node.
>>>
>>>> having the <phandle>+output name pair will be difficult to manage?
>>>
>>> That's part of my concern.
>>
>>I was concerned about this too until I found precedence for doing the
>>exact same thing in the pci binding (and ePAPR). =A0Mixing phandle and a
>>string in this way doesn't bother me anymore.
>
> Where exactly can I get the sample code for handling this binding?
In my test-devicetree branch. See the file drivers/of/clock.c[1] from
commit [2]:
[1] http://git.secretlab.ca/?p=3Dlinux-2.6.git;a=3Dblob;f=3Ddrivers/of/cloc=
k.c;h=3D26bd70c293d3ec23cbef3f67e0853069b6c24dc0;hb=3Dfadbfb859485148756533=
b28203b7b0188a17250
[2] http://git.secretlab.ca/?p=3Dlinux-2.6.git;a=3Dcommit;h=3Dfadbfb8594851=
48756533b28203b7b0188a17250
g.
^ permalink raw reply
* RE: Review Request: New proposal for device tree clock binding.
From: Li Yang-R58472 @ 2010-08-10 4:56 UTC (permalink / raw)
To: Grant Likely; +Cc: devicetree-discuss, linuxppc-dev, Jeremy Kerr
In-Reply-To: <AANLkTinQnFBcLiDyQtRRwzdAg_M48BnNsa2OyKWCiSUh@mail.gmail.com>
>>> I've avoided requiring clock nodes to have a separate sub node for
>>> each output because it is more verbose and it prevents clock
>>> providers from having child nodes for other purposes. =A0Are you
>>> concerned that
>>
>> I don't see why there should be child nodes for other purposes under
>clock node.
>>
>>> having the <phandle>+output name pair will be difficult to manage?
>>
>> That's part of my concern.
>
>I was concerned about this too until I found precedence for doing the
>exact same thing in the pci binding (and ePAPR). Mixing phandle and a
>string in this way doesn't bother me anymore.
Where exactly can I get the sample code for handling this binding?
- Leo
^ permalink raw reply
* Re: Questions about powerpc kernel tree
From: Benjamin Herrenschmidt @ 2010-08-10 4:19 UTC (permalink / raw)
To: Terren Chow; +Cc: linuxppc-dev
In-Reply-To: <AANLkTinqKv1OXDBtQfg0jOyw=04FQcAvoE8CPmMN7M5_@mail.gmail.com>
On Tue, 2010-08-10 at 10:39 +0800, Terren Chow wrote:
> Hi Ben:
> I'm not quite clearly know about the powerpc kernel tree histroy.
> why the tags in the powerpc kernel tree are only update to 2.6.26-rc9
> at about 2 years ago?
Not sure what you're looking at but your shouldn't need to use the
"powerpc kernel tree" whatever tree this is :-) All our work goes into
Linus tree on a regular basis, so unless you are specifically looking at
the powerpc "next" git branch aimed at the next merge window, there
should be nothing of interest to you there.
Ben.
^ permalink raw reply
* Questions about powerpc kernel tree
From: Terren Chow @ 2010-08-10 2:39 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 313 bytes --]
Hi Ben:
I'm not quite clearly know about the powerpc kernel tree histroy. why
the tags in the powerpc kernel tree are only update to 2.6.26-rc9 at about 2
years ago?
--
Terren Chow
College of informatics, SCAU
Graduate student
Lab of Embedded System and Wireless Sensor Network
MSN: terren.chow@hotmail.com
[-- Attachment #2: Type: text/html, Size: 412 bytes --]
^ permalink raw reply
* Re: mpc870: hctosys.c unable to open rtc device rtc0
From: Shawn Jin @ 2010-08-09 21:05 UTC (permalink / raw)
To: Scott Wood; +Cc: ppcdev
In-Reply-To: <20100809122933.5a314af3@schlenkerla.am.freescale.net>
>> Reading the fsl i2c bindings in the documentation, I found an example
>> as follows.
>> =A0 27 =A0 =A0 =A0i2c@860 {
>> =A0 28 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0compatible =3D "fsl,mpc823-i2c",
>> =A0 29 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "fsl,cpm1=
-i2c";
>> =A0 30 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0reg =3D <0x860 0x20 0x3c80 0x30>;
>> =A0 31 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0interrupts =3D <16>;
>> =A0 32 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0interrupt-parent =3D <&CPM_PIC>;
>> =A0 33 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0fsl,cpm-command =3D <0x10>;
>> =A0 34 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0#address-cells =3D <1>;
>> =A0 35 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0#size-cells =3D <0>;
>> =A0 36
>> =A0 37 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0rtc@68 {
>> =A0 38 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0compatible =3D "da=
llas,ds1307";
>> =A0 39 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0reg =3D <0x68>;
>> =A0 40 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0};
>> =A0 41 =A0 =A0 =A0 =A0};
>> =A0 42
>>
>> In the above example the rtc was explicitly declared as a subnode of
>> the i2c node. Is this the way to connect (or bind) a RTC to the I2C
>> driver?
>
> Yes.
Thanks Scott for the confirmation. I added that to my dts file and the
driver did try to probe the device. But accessing the device timed
out. There are some microcode patches related to I2C that I've not
applied. I'll try the patch(es) later. But how can I find out which
patch should be applied to my MPC870?
Thanks,
-Shawn.
^ permalink raw reply
* Re: [PATCH 8/8] v5 Update memory-hotplug documentation
From: Nishanth Aravamudan @ 2010-08-09 20:48 UTC (permalink / raw)
To: linuxppc-dev
Cc: linuxppc-dev, Greg KH, linux-kernel, Dave Hansen, linux-mm,
KAMEZAWA Hiroyuki
In-Reply-To: <201008091344.37878.nacc@us.ibm.com>
On Monday, August 09, 2010 01:44:37 pm Nishanth Aravamudan wrote:
> On Monday, August 09, 2010 11:43:46 am Nathan Fontenot wrote:
> > Update the memory hotplug documentation to reflect the new behaviors of
> > memory blocks reflected in sysfs.
>
> <snip>
>
> > Index: linux-2.6/Documentation/memory-hotplug.txt
> > ===================================================================
> > --- linux-2.6.orig/Documentation/memory-hotplug.txt 2010-08-09 07:36:48.000000000 -0500
> > +++ linux-2.6/Documentation/memory-hotplug.txt 2010-08-09 07:59:54.000000000 -0500
>
> <snip>
>
> > -/sys/devices/system/memory/memoryXXX/phys_index
> > +/sys/devices/system/memory/memoryXXX/start_phys_index
> > +/sys/devices/system/memory/memoryXXX/end_phys_index
> > /sys/devices/system/memory/memoryXXX/phys_device
> > /sys/devices/system/memory/memoryXXX/state
> > /sys/devices/system/memory/memoryXXX/removable
> >
> > -'phys_index' : read-only and contains section id, same as XXX.
>
> <snip>
>
> > +'phys_index' : read-only and contains section id of the first section
>
> Shouldn't this be "start_phys_index"?
Ah, actually it's that the Documentation change doesn't seem to agree with
patch 2/8 ? That is, 2/8 leaves phys_index in place, but changes several
variables, while this patch indicates its removal?
Thanks,
Nish
--
Nishanth Aravamudan <nacc@us.ibm.com>
Linux Technology Center
^ permalink raw reply
* Re: [PATCH 8/8] v5 Update memory-hotplug documentation
From: Nishanth Aravamudan @ 2010-08-09 20:44 UTC (permalink / raw)
To: linuxppc-dev
Cc: linuxppc-dev, Greg KH, linux-kernel, Dave Hansen, linux-mm,
KAMEZAWA Hiroyuki
In-Reply-To: <4C604C62.7060509@austin.ibm.com>
On Monday, August 09, 2010 11:43:46 am Nathan Fontenot wrote:
> Update the memory hotplug documentation to reflect the new behaviors of
> memory blocks reflected in sysfs.
<snip>
> Index: linux-2.6/Documentation/memory-hotplug.txt
> ===================================================================
> --- linux-2.6.orig/Documentation/memory-hotplug.txt 2010-08-09 07:36:48.000000000 -0500
> +++ linux-2.6/Documentation/memory-hotplug.txt 2010-08-09 07:59:54.000000000 -0500
<snip>
> -/sys/devices/system/memory/memoryXXX/phys_index
> +/sys/devices/system/memory/memoryXXX/start_phys_index
> +/sys/devices/system/memory/memoryXXX/end_phys_index
> /sys/devices/system/memory/memoryXXX/phys_device
> /sys/devices/system/memory/memoryXXX/state
> /sys/devices/system/memory/memoryXXX/removable
>
> -'phys_index' : read-only and contains section id, same as XXX.
<snip>
> +'phys_index' : read-only and contains section id of the first section
Shouldn't this be "start_phys_index"?
Thanks,
Nish
--
Nishanth Aravamudan <nacc@us.ibm.com>
Linux Technology Center
^ 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