Hi Ben,
On Fri, 06 Jun 2008 14:16:23 +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2008-06-05 at 09:48 +0200, Jean Delvare wrote:
> > As far as I am concerned, it's really up to the maintainers and users
> > of this platform. All I am asking for is that you do not call
> > i2c_add_numbered_adapte
On Thu, 2008-06-05 at 11:23 -0500, Kumar Gala wrote:
> On Jun 5, 2008, at 10:56 AM, Jerone Young wrote:
>
> > Update: Consolidated dbcr1 & dbcr2 under one define.
> >
> > Taken from the PowerPC ISA BookIII-E specifies that DBCR0 is different
> > for all others that are not ppc405 chips. So I have
Might be a platform thing, might be an ATA thing:
irq 18: nobody cared (try booting with the "irqpoll" option)
Call Trace:
[c06cf770] [c00120dc] .show_stack+0x58/0x1dc (unreliable)
[c06cf820] [c00a2d64] .__report_bad_irq+0x3c/0xac
[c06cf8a0] [c00a
On Jun 5, 2008, at 11:32 PM, Benjamin Herrenschmidt wrote:
On Thu, 2008-06-05 at 22:12 +0200, Arnd Bergmann wrote:
On Thursday 05 June 2008, Stephen Neuendorffer wrote:
"Grant Likely" <[EMAIL PROTECTED]> wrote:
Paulus, Can we just kill all of arch/ppc for .27 right now?
Acked-by: Josh Boy
> I've been bisecting that on Quad G5 (sata_svw): irq 18: nobody cared ...,
> then later endless ata1.00: exception..., blah blah, ata1: EH complete.
> It comes down to:
Thanks for finding that !
/me likes when he wakes up in the morning to find a G5 bug ... and the
fix in the same thread :-)
C
On Thu, 2008-06-05 at 22:12 +0200, Arnd Bergmann wrote:
> On Thursday 05 June 2008, Stephen Neuendorffer wrote:
> > > "Grant Likely" <[EMAIL PROTECTED]> wrote:
> > >
> > > > Paulus, Can we just kill all of arch/ppc for .27 right now?
> > >
> > > Acked-by: Josh Boyer <[EMAIL PROTECTED]>
> > Acked-b
On Thu, 5 Jun 2008 22:07:31 -0600
"Grant Likely" <[EMAIL PROTECTED]> wrote:
> The fallback is to just let the i2c layer auto-assign an ID. The only
> reason I can think of to want to assign a specific id to an i2c bus is
> so that a userspace application can reference a specific bus. The
> drive
On Thu, 2008-06-05 at 10:45 +0200, Stefan Roese wrote:
> Full ack from me. So I suggest to use "cell-index" if available and
> otherwise
> use an incremented number, same as the FSL i2c driver does now:
>
> http://ozlabs.org/pipermail/linuxppc-dev/2008-June/057254.html
>
> If nobody objects I'll
On Thu, 2008-06-05 at 10:43 -0500, Timur Tabi wrote:
> Grant Likely wrote:
>
> > if you need explicit indexing then use an alias. My opinion however
> > is that explicit indexing is unnecessary and is just an artifact of
> > current i2c subsystem internals. There is already enough information
>
On Thu, 2008-06-05 at 10:13 -0500, Timur Tabi wrote:
> Josh Boyer wrote:
>
> > From a device tree perspective, index and cell-index are both
> > incorrect. The IIC macros don't share register blocks with anything,
> > are enumerated as unique instances per macro in the device tree, and
> > should
On Wed, 2008-06-04 at 10:43 -0500, Scott Wood wrote:
> > I just posted a patch for the FSL I2C driver to check for cell-index. I'm
> > under
> > the impression that cell-index is the standard for enumerating devices in
> > the
> > device tree.
>
> No, it's the standard for correlating devices w
On Thu, 2008-06-05 at 09:48 +0200, Jean Delvare wrote:
> As far as I am concerned, it's really up to the maintainers and users
> of this platform. All I am asking for is that you do not call
> i2c_add_numbered_adapter() on an adapter with an automatically
> generated number. This function must only
On Wed, 2008-06-04 at 21:19 -0500, Josh Boyer wrote:
> So if possible, I'd like to eliminate the *index stuff all together
> from the 4xx driver. The private data structure contains an idx
> parameter, but this can be populated based on probe order or something.
>
> >From a device tree perspectiv
On Wed, Jun 4, 2008 at 8:41 PM, David Gibson <[EMAIL PROTECTED]> wrote:
> On Wed, Jun 04, 2008 at 09:19:42PM -0500, Josh Boyer wrote:
>> On Wed, 4 Jun 2008 10:43:51 -0500
>> Scott Wood <[EMAIL PROTECTED]> wrote:
>>
>> > On Wed, Jun 04, 2008 at 10:24:15AM -0500, Timur Tabi wrote:
>> > > Stefan Roese
On Thu, 2008-06-05 at 16:22 +0200, Stefan Roese wrote:
> This patch add a check to the PPC4xx PCIe driver to detect if the port
> is disabled via the device-tree. This is needed for the AMCC Canyonlands
> board which has an option to either select 2 PCIe ports or 1 PCIe port
> and one SATA port. Th
On Thu, Jun 05, 2008 at 07:10:22PM +0200, Wolfgang Grandegger wrote:
> Like for the TQM5200, the vendor prefix "tqc," is now used for all
> TQM85xx modules from TQ-Components GmbH (http://www.tqc.de) in the
> corresponding DTS files.
>
> Signed-off-by: Wolfgang Grandegger <[EMAIL PROTECTED]>
> ---
On Fri, Jun 06, 2008 at 04:40:20AM +0200, Segher Boessenkool wrote:
From a device tree perspective, index and cell-index are both
>>> incorrect. The IIC macros don't share register blocks with anything,
>>> are enumerated as unique instances per macro in the device tree, and
>>> should be abl
From a device tree perspective, index and cell-index are both
incorrect. The IIC macros don't share register blocks with anything,
are enumerated as unique instances per macro in the device tree, and
should be able to be distinguished by "regs" and/or unit address.
Does anyone disagree with tha
On Thu, 5 Jun 2008 16:28:18 +0200
"Stefan Roese" <[EMAIL PROTECTED]> wrote:
> n Thursday 05 June 2008, Valentine Barshak wrote:
> > The "ndfc-chip" device doesn't need any resources. All resources
> > are handled by the "ndfc-nand" device. Registering the same memory
> > resource twice causes "cat
On Wed, Jun 04, 2008 at 09:19:42PM -0500, Josh Boyer wrote:
> On Wed, 4 Jun 2008 10:43:51 -0500
> Scott Wood <[EMAIL PROTECTED]> wrote:
>
> > On Wed, Jun 04, 2008 at 10:24:15AM -0500, Timur Tabi wrote:
> > > Stefan Roese wrote:
> > > > I'm wondering what is currently recommended in the I2C device
On Thu, Jun 05, 2008 at 06:52:25AM -0500, Josh Boyer wrote:
> On Thu, 5 Jun 2008 10:45:42 +0200
> Stefan Roese <[EMAIL PROTECTED]> wrote:
>
> > On Thursday 05 June 2008, Jean Delvare wrote:
> > > > > Maybe it is time to remove the index, or maybe we should go back to
> > > > > using both a static
On Jun 5, 2008, at 3:39 PM, Wolfgang Grandegger wrote:
Kumar Gala wrote:
===
--- /dev/null
+++ linux-2.6-galak/arch/powerpc/boot/dts/tqm8548.dts
+memory {
+device_type = "memory";
+reg = <0x 0x200
On Thu, 05 Jun 2008 10:50:20 -0500
Timur Tabi <[EMAIL PROTECTED]> wrote:
> Jochen Friedrich wrote:
> > Hi Timur,
> >
> >> In situations where it doesn't matter which I2C bus is #1 and which one is
> >> #2,
> >> then I think the code should just initialize idx based on the order the
> >> nodes
>
On Thu, 5 Jun 2008 17:37:16 -0400
Sean MacLennan <[EMAIL PROTECTED]> wrote:
> On Thu, 5 Jun 2008 08:22:00 +0200
> "Stefan Roese" <[EMAIL PROTECTED]> wrote:
>
> > So what should we do now? Currently I2C doesn't work at all on 4xx
> > since the driver expects the "index" property and no dts sets th
On Thu, Jun 05, 2008 at 02:16:41PM -0500, Timur Tabi wrote:
> Grant Likely wrote:
>
> > No; use an alias in the aliases node. That is what aliases is designed
> > for. Something like 'index' is a reinvention of the wheel.
>
> Do aliases work in reverse? That is, if I have a pointer to a
> devi
On Thu, Jun 05, 2008 at 08:43:51AM -0500, Kumar Gala wrote:
>
> On Jun 5, 2008, at 4:05 AM, Wolfgang Grandegger wrote:
[snip]
>> +timebase-frequency = <0>; // from U-Boot
>> +bus-frequency = <0>;// from U-Boot
>> +clock-frequency
On Thu, Jun 05, 2008 at 11:40:37AM -0500, Timur Tabi wrote:
> Grant Likely wrote:
>
> > 2) for i2c purposes, explicit enumeration is not needed or desired.
> > All the necessary data is already present in the device tree in that
> > i2c device nodes are children of i2c bus nodes. The i2c bus numb
Hi All
With these rather fresh sources, obtained via git:
53c8ba9 Linux 2.6.26-rc5
and after just about an hour of mild tests on 2 powerpc laptops: an
older TiBookIV, a newer Powerbook5,8.
CD-Burning seems to work again: at least on the Powerbook5,8 - with a
real image burn. A simulated CD bu
On Thu, Jun 05, 2008 at 04:44:15PM -0500, Kim Phillips wrote:
>
> it is :). I'm working on it :).
Good :)
> the h/w has a IV out feature we should probably be using. How about
> something like this (UNTESTED):
Looks great!
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert
On Thu, 5 Jun 2008 13:14:00 -0600
"Grant Likely" <[EMAIL PROTECTED]> wrote:
> No; use an alias in the aliases node. That is what aliases is
> designed for. Something like 'index' is a reinvention of the wheel.
If we really want to get rid of the index, I like the alias method. I
mainly write dr
On Thu, Jun 05, 2008 at 02:43:59AM -0500, Kumar Gala wrote:
>
I'm puzzled. Could someone point me to some real code where cell-
index
is used as a pointer into some global data. Sorry for my ignorance.
>>>
>>> http://ozlabs.org/pipermail/linuxppc-dev/2008-June/057254.html
>>
>>
On Thu, Jun 05, 2008 at 10:45:42AM +0200, Stefan Roese wrote:
> On Thursday 05 June 2008, Jean Delvare wrote:
> > > > Maybe it is time to remove the index, or maybe we should go back to
> > > > using both a static and the index. But at the time we decided to
> > > > enforce an index.
> > >
> > > So
On Thu, 5 Jun 2008 15:22:24 +1000
Herbert Xu <[EMAIL PROTECTED]> wrote:
> On Fri, May 30, 2008 at 06:58:30PM -0500, Kim Phillips wrote:
> >
> > + /* get random IV */
> > + get_random_bytes(req->giv, crypto_aead_ivsize(authenc));
>
> Sorry but this is unworkable given our current RNG infrastru
On 5/7/08, Sascha Hauer <[EMAIL PROTECTED]> wrote:
> On Wed, May 07, 2008 at 11:53:49AM +0100, David Woodhouse wrote:
> > On Wed, 2008-05-07 at 12:27 +0200, Sascha Hauer wrote:
> > > memcpy_from/to_io() use word aligned accesses on the io side of memory.
> > > The MPC5200 local plus bus where ou
On Thu, 5 Jun 2008 08:22:00 +0200
"Stefan Roese" <[EMAIL PROTECTED]> wrote:
> So what should we do now? Currently I2C doesn't work at all on 4xx
> since the driver expects the "index" property and no dts sets this
> property. Personally I would like to move to using cell-index here,
> since this s
No; use an alias in the aliases node. That is what aliases is
designed
for. Something like 'index' is a reinvention of the wheel.
Do aliases work in reverse? That is, if I have a pointer to a device
node, can
I look up its alias directly? Or do I have to scan the aliases node
and do a
com
[Fixed up the collision between Grant and Olof]
"Grant Likely" <[EMAIL PROTECTED]> wrote:
Paulus, Can we just kill all of arch/ppc for .27 right now?
Acked-by: Josh Boyer <[EMAIL PROTECTED]>
Acked-by: Stephen Neuendorffer <[EMAIL PROTECTED]>
Acked-by: Arnd Bergmann <[EMAIL PROTECTED]>
Ack
Kumar Gala wrote:
>
>> ===
>> --- /dev/null
>> +++ linux-2.6-galak/arch/powerpc/boot/dts/tqm8548.dts
>>
>
>> +memory {
>> +device_type = "memory";
>> +reg = <0x 0x2000>;
>> +};
>
> is memory fixed
On Jun 5, 2008, at 3:30 PM, Scott Wood wrote:
Olof Johansson wrote:
On Jun 5, 2008, at 3:12 PM, Arnd Bergmann wrote:
On Thursday 05 June 2008, Stephen Neuendorffer wrote:
"Grant Likely" <[EMAIL PROTECTED]> wrote:
Paulus, Can we just kill all of arch/ppc for .27 right now?
Acked-by: Josh
Olof Johansson wrote:
On Jun 5, 2008, at 3:12 PM, Arnd Bergmann wrote:
On Thursday 05 June 2008, Stephen Neuendorffer wrote:
"Grant Likely" <[EMAIL PROTECTED]> wrote:
Paulus, Can we just kill all of arch/ppc for .27 right now?
Acked-by: Josh Boyer <[EMAIL PROTECTED]>
Acked-by: Stephen Ne
On Jun 5, 2008, at 3:12 PM, Arnd Bergmann wrote:
On Thursday 05 June 2008, Stephen Neuendorffer wrote:
"Grant Likely" <[EMAIL PROTECTED]> wrote:
Paulus, Can we just kill all of arch/ppc for .27 right now?
Acked-by: Josh Boyer <[EMAIL PROTECTED]>
Acked-by: Stephen Neuendorffer <[EMAIL PROT
On Thu, Jun 5, 2008 at 2:12 PM, Arnd Bergmann <[EMAIL PROTECTED]> wrote:
> On Thursday 05 June 2008, Stephen Neuendorffer wrote:
>> > "Grant Likely" <[EMAIL PROTECTED]> wrote:
>> >
>> > > Paulus, Can we just kill all of arch/ppc for .27 right now?
>> >
>> > Acked-by: Josh Boyer <[EMAIL PROTECTED]>
On Thursday 05 June 2008, Stephen Neuendorffer wrote:
> > "Grant Likely" <[EMAIL PROTECTED]> wrote:
> >
> > > Paulus, Can we just kill all of arch/ppc for .27 right now?
> >
> > Acked-by: Josh Boyer <[EMAIL PROTECTED]>
> Acked-by: Stephen Neuendorffer <[EMAIL PROTECTED]>
Acked-by: Arnd Bergmann <[
Grant Likely wrote:
> No; use an alias in the aliases node. That is what aliases is designed
> for. Something like 'index' is a reinvention of the wheel.
Do aliases work in reverse? That is, if I have a pointer to a device node, can
I look up its alias directly? Or do I have to scan the alias
On Thu, 5 Jun 2008 13:14:00 -0600
"Grant Likely" <[EMAIL PROTECTED]> wrote:
> On Thu, Jun 5, 2008 at 12:56 PM, Josh Boyer <[EMAIL PROTECTED]> wrote:
> > On Thu, 5 Jun 2008 12:46:39 -0600
> > "Grant Likely" <[EMAIL PROTECTED]> wrote:
> >
> >> In Timur's case, it is absolutely appropriate to use cel
On Thu, 5 Jun 2008 13:59:44 -0500
Kumar Gala <[EMAIL PROTECTED]> wrote:
>
> On Jun 5, 2008, at 10:18 AM, Josh Boyer wrote:
>
> > On Thu, 5 Jun 2008 09:11:48 -0600
> > "Grant Likely" <[EMAIL PROTECTED]> wrote:
> >
> >> On Thu, Jun 5, 2008 at 8:52 AM, Josh Boyer <[EMAIL PROTECTED]
> >> > wrote:
>
On Thu, Jun 5, 2008 at 12:56 PM, Josh Boyer <[EMAIL PROTECTED]> wrote:
> On Thu, 5 Jun 2008 12:46:39 -0600
> "Grant Likely" <[EMAIL PROTECTED]> wrote:
>
>> In Timur's case, it is absolutely appropriate to use cell-index and/or
>> a phandle to make sure it gets the correct DMA registers (which is
>>
On Jun 5, 2008, at 10:18 AM, Josh Boyer wrote:
On Thu, 5 Jun 2008 09:11:48 -0600
"Grant Likely" <[EMAIL PROTECTED]> wrote:
On Thu, Jun 5, 2008 at 8:52 AM, Josh Boyer <[EMAIL PROTECTED]
> wrote:
This commit (patch omitted due to size) is sitting in my local tree:
commit 0d7efc1e80fc262bcc507
===
--- /dev/null
+++ linux-2.6-galak/arch/powerpc/boot/dts/tqm8548.dts
+ memory {
+ device_type = "memory";
+ reg = <0x 0x2000>;
+ };
is memory fixed on this board to 256M?
On Thu, 5 Jun 2008 12:46:39 -0600
"Grant Likely" <[EMAIL PROTECTED]> wrote:
> > (And I'm talking about I2C, not DMA. I don't care about DMA because
> > this conversation will go off into the weeds if we start talking about
> > cell-index and every possible device out there.)
>
> I need to disagr
On Thu, Jun 5, 2008 at 12:27 PM, Josh Boyer <[EMAIL PROTECTED]> wrote:
> On Thu, 05 Jun 2008 11:25:23 -0500
> Timur Tabi <[EMAIL PROTECTED]> wrote:
>
>> Josh Boyer wrote:
>>
>> > And it does. It does so by the unique "regs" properties and
>> > unit-names. You can assign the index that the i2c sub
On Thu, Jun 5, 2008 at 12:31 PM, Anton Vorontsov
<[EMAIL PROTECTED]> wrote:
> On Thu, Jun 05, 2008 at 12:18:56PM -0600, Grant Likely wrote:
>> On Thu, Jun 5, 2008 at 12:00 PM, Anton Vorontsov
>> <[EMAIL PROTECTED]> wrote:
>> > On Thu, Jun 05, 2008 at 11:36:09AM -0600, Grant Likely wrote:
>> >> On T
On Thu, 05 Jun 2008 13:35:18 -0500
Timur Tabi <[EMAIL PROTECTED]> wrote:
> Josh Boyer wrote:
>
> > I don't understand this statement. Are your I2C macros hot-pluggable?
> > Can you dynamically add/remove an I2C engine on your hardware somehow?
> > Are you mucking about with the DTB and randomly
Josh Boyer wrote:
> I don't understand this statement. Are your I2C macros hot-pluggable?
> Can you dynamically add/remove an I2C engine on your hardware somehow?
> Are you mucking about with the DTB and randomly moving around the I2C
> node blobs so they probe order differs from boot to boot?
>
On Thu, Jun 05, 2008 at 12:18:56PM -0600, Grant Likely wrote:
> On Thu, Jun 5, 2008 at 12:00 PM, Anton Vorontsov
> <[EMAIL PROTECTED]> wrote:
> > On Thu, Jun 05, 2008 at 11:36:09AM -0600, Grant Likely wrote:
> >> On Thu, Jun 5, 2008 at 11:27 AM, Anton Vorontsov
> >> <[EMAIL PROTECTED]> wrote:
> >>
On Thu, 05 Jun 2008 11:25:23 -0500
Timur Tabi <[EMAIL PROTECTED]> wrote:
> Josh Boyer wrote:
>
> > And it does. It does so by the unique "regs" properties and
> > unit-names. You can assign the index that the i2c subsystem needs
> > based on probe order, like I already said.
>
> The probe orde
On Thu, Jun 5, 2008 at 12:00 PM, Anton Vorontsov
<[EMAIL PROTECTED]> wrote:
> On Thu, Jun 05, 2008 at 11:36:09AM -0600, Grant Likely wrote:
>> On Thu, Jun 5, 2008 at 11:27 AM, Anton Vorontsov
>> <[EMAIL PROTECTED]> wrote:
>> > Well, I mentioned the usb_add_hcd()-alike approach for the mmc_spi
>> >
Timur Tabi wrote:
Scott Wood wrote:
No, it's not. It can determine that it's at address 0x4f on the i2c bus
at 0xe0003100. This is exactly how the ethernet phy lookup is done.
But how does the fabric driver know whether e0003100 is I2C1 or I2C2?
It shouldn't have to care.
And how does t
On Thu, Jun 05, 2008 at 11:36:09AM -0600, Grant Likely wrote:
> On Thu, Jun 5, 2008 at 11:27 AM, Anton Vorontsov
> <[EMAIL PROTECTED]> wrote:
> > On Thu, Jun 05, 2008 at 10:45:17AM -0600, Grant Likely wrote:
> >> On Thu, Jun 5, 2008 at 10:16 AM, Anton Vorontsov
> >> <[EMAIL PROTECTED]> wrote:
> >>
Scott Wood wrote:
> No, it's not. It can determine that it's at address 0x4f on the i2c bus
> at 0xe0003100. This is exactly how the ethernet phy lookup is done.
But how does the fabric driver know whether e0003100 is I2C1 or I2C2?
And how does the codec driver, which sees only I2C information
On Thu, Jun 5, 2008 at 11:27 AM, Anton Vorontsov
<[EMAIL PROTECTED]> wrote:
> On Thu, Jun 05, 2008 at 10:45:17AM -0600, Grant Likely wrote:
>> On Thu, Jun 5, 2008 at 10:16 AM, Anton Vorontsov
>> <[EMAIL PROTECTED]> wrote:
>> > Here is v3. I'm out of ideas if you won't like it. :-)
>> >
>> > v3:
>>
On Thu, Jun 05, 2008 at 10:45:17AM -0600, Grant Likely wrote:
> On Thu, Jun 5, 2008 at 10:16 AM, Anton Vorontsov
> <[EMAIL PROTECTED]> wrote:
> > Here is v3. I'm out of ideas if you won't like it. :-)
> >
> > v3:
> > - Now these bindings are using bus notifiers chain, thus we adhere to the
> > spi
Kumar Gala wrote:
>
> On Jun 5, 2008, at 4:05 AM, Wolfgang Grandegger wrote:
>
>> [POWERPC] 85xx: add board support for the TQM8548 modules
>>
>> This patch adds support for the TQM8548 modules from TQ-Components
>> GmbH (http://www.tqc.de).
>>
>> Signed-off-by: Wolfgang Grandegger <[EMAIL PROTEC
Add local bus nodes for Flash and CAN to the DTS file of the TQM8650 module.
Signed-off-by: Wolfgang Grandegger <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/tqm8560.dts | 65 ++
1 file changed, 65 insertions(+)
Index: linux-2.6-galak/arch/powerpc/boot/dts/t
Some TQM85xx boards could be equipped with up to 1 GiB (NOR) flash
memory and therefore a modified memory map is required and setup by
the board loader. This patch adds an appropriate DTS file.
Signed-off-by: Wolfgang Grandegger <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/tqm8548-bigflash.dts |
This patch adds support for the TQM8548 modules from TQ-Components
GmbH (http://www.tqc.de).
Signed-off-by: Wolfgang Grandegger <[EMAIL PROTECTED]>
---
arch/powerpc/boot/Makefile |1
arch/powerpc/boot/dts/tqm8548.dts | 365 +
arch/powerpc/boot/wrapper
Like for the TQM5200, the vendor prefix "tqc," is now used for all
TQM85xx modules from TQ-Components GmbH (http://www.tqc.de) in the
corresponding DTS files.
Signed-off-by: Wolfgang Grandegger <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/tqm8540.dts |4 ++--
arch/powerpc/boot/dts/tqm854
For the sake of safety, document that drivers should return only
1 or 0 from the get_ro() and get_cd() callbacks. Also document context
in which these callbacks should be executed.
wbsd driver modified to comply with this requirement.
Also, fix mmc_spi driver to not return raw values from the pla
On Thu, Jun 05, 2008 at 11:44:51AM +0100, David Howells wrote:
> Scott Wood <[EMAIL PROTECTED]> wrote:
>
> > int tmp;
> >
> > asm volatile("addi %1, %2, -1;"
> > "andc %1, %2, %1;"
> > "cntlzw %1, %1;"
> > "subfic %0, %1, 31" : "=r" (j), "=&r" (tmp) : "r" (i
On Thu, Jun 5, 2008 at 10:16 AM, Anton Vorontsov
<[EMAIL PROTECTED]> wrote:
> Here is v3. I'm out of ideas if you won't like it. :-)
>
> v3:
> - Now these bindings are using bus notifiers chain, thus we adhere to the
> spi bus.
>
> By the way, this scheme (IMO) looks good for I2C devices which ne
Grant Likely wrote:
> 2) for i2c purposes, explicit enumeration is not needed or desired.
> All the necessary data is already present in the device tree in that
> i2c device nodes are children of i2c bus nodes. The i2c bus numbers
> should be dynamically assigned.
NACK. For ASoC driver, they ca
On Thu, Jun 5, 2008 at 10:25 AM, Timur Tabi <[EMAIL PROTECTED]> wrote:
> Josh Boyer wrote:
>
>> And it does. It does so by the unique "regs" properties and
>> unit-names. You can assign the index that the i2c subsystem needs
>> based on probe order, like I already said.
>
> The probe order is not
On Thu, Jun 5, 2008 at 10:18 AM, Timur Tabi <[EMAIL PROTECTED]> wrote:
> Grant Likely wrote:
>
>> [EMAIL PROTECTED] {
>> #size-cells = <1>;
>> #address-cells = <1>;
>> ranges = <0 0xe 0x1000>;
>> [EMAIL PROTECTED] {
>> cell-index = <0>;
>>
Josh Boyer wrote:
> And it does. It does so by the unique "regs" properties and
> unit-names. You can assign the index that the i2c subsystem needs
> based on probe order, like I already said.
The probe order is not sufficient on platforms that specifically enumerate their
I2C (or whatever) dev
On Thu, Jun 5, 2008 at 10:22 AM, Jochen Friedrich <[EMAIL PROTECTED]> wrote:
> Hi Timur,
>
>> It's a little late for that. I'm okay with coming up with a new property to
>> provide system-level indexing, but it needs to be the same property name for
>> each type of device. I don't want linux,i2c-
On Thu, Jun 05, 2008 at 11:09:16AM -0500, Timur Tabi wrote:
> The fabric driver doesn't have access to any I2C structures when it starts
> looking for the codec driver. The fabric driver is like an OF platform
> driver,
> in that it's OF-aware and machine-specific. By parsing the device tree (wh
On Jun 5, 2008, at 10:56 AM, Jerone Young wrote:
Update: Consolidated dbcr1 & dbcr2 under one define.
Taken from the PowerPC ISA BookIII-E specifies that DBCR0 is different
for all others that are not ppc405 chips. So I have now chnaged the
conditional to reflect this. Also added definitions n
Hi Timur,
> It's a little late for that. I'm okay with coming up with a new property to
> provide system-level indexing, but it needs to be the same property name for
> each type of device. I don't want linux,i2c-index and linux,dma-index and
> linux,ssi-index, etc. I also don't understand why
On Thu, 05 Jun 2008 11:13:23 -0500
Timur Tabi <[EMAIL PROTECTED]> wrote:
> Grant Likely wrote:
>
> > That is still Linux internal artifacts leaking out. Don't encode that
> > data into the device tree.
>
> The I2C bus number is *not* an internal artifact. On Freescale parts, the one
> I2C adap
Grant Likely wrote:
> [EMAIL PROTECTED] {
> #size-cells = <1>;
> #address-cells = <1>;
> ranges = <0 0xe 0x1000>;
> [EMAIL PROTECTED] {
> cell-index = <0>;
> regs = <0 0x100>;
> }
> [EMAIL PROTECTED] {
>
Here is v3. I'm out of ideas if you won't like it. :-)
v3:
- Now these bindings are using bus notifiers chain, thus we adhere to the
spi bus.
By the way, this scheme (IMO) looks good for I2C devices which needs
platform_data extracted from the device tree too (Cc'ing Jochen).
- Plus change
Grant Likely wrote:
> That is still Linux internal artifacts leaking out. Don't encode that
> data into the device tree.
The I2C bus number is *not* an internal artifact. On Freescale parts, the one
I2C adapter is specifically designated I2C1, and the 2nd one is specifically
designated I2C2. T
On Thu, Jun 5, 2008 at 9:50 AM, Timur Tabi <[EMAIL PROTECTED]> wrote:
> Jochen Friedrich wrote:
>> Hi Timur,
>>
>>> In situations where it doesn't matter which I2C bus is #1 and which one is
>>> #2,
>>> then I think the code should just initialize idx based on the order the
>>> nodes
>>> are foun
Segher Boessenkool wrote:
> Sounds to me like both simply need to use adapter->nr.
How can a non-I2C driver get the adapter structure for another driver that is an
I2C driver?
> For access to
> Linux-internal data structures (and that is what this "index" is), you
> shouldn't have to go via the
On Thu, Jun 5, 2008 at 9:43 AM, Timur Tabi <[EMAIL PROTECTED]> wrote:
> Grant Likely wrote:
>
>> if you need explicit indexing then use an alias. My opinion however
>> is that explicit indexing is unnecessary and is just an artifact of
>> current i2c subsystem internals. There is already enough i
On Thursday 05 June 2008, Anton Vorontsov wrote:
> On Tue, Jun 03, 2008 at 12:07:49PM +0200, Marc Pignat wrote:
> > Hi all!
> >
> > On Friday 23 May 2008, Anton Vorontsov wrote:
> > > get_ro() callback must return values >= 0 for its logical state, and
> > ...
> > > static void pxamci_set_ios(str
Update: Consolidated dbcr1 & dbcr2 under one define.
Taken from the PowerPC ISA BookIII-E specifies that DBCR0 is different
for all others that are not ppc405 chips. So I have now chnaged the
conditional to reflect this. Also added definitions needed for DBCR1 &
DBCR2.
Signed-off-by: Jerone Youn
On Thu, Jun 5, 2008 at 9:52 AM, Jochen Friedrich <[EMAIL PROTECTED]> wrote:
> Hi Grant,
>
>> if you need explicit indexing then use an alias. My opinion however
>> is that explicit indexing is unnecessary and is just an artifact of
>> current i2c subsystem internals. There is already enough infor
On Wed, 2008-06-04 at 21:14 -0500, Josh Boyer wrote:
> On Wed, 04 Jun 2008 17:26:44 -0500
> Jerone Young <[EMAIL PROTECTED]> wrote:
>
> > Taken from the PowerPC ISA BookIII-E specifies that DBCR0 is different
> > for all others that are not ppc405 chips. So I have now chnaged the
> > conditional t
if you need explicit indexing then use an alias. My opinion however
is that explicit indexing is unnecessary and is just an artifact of
current i2c subsystem internals. There is already enough information
in the device tree to match i2c devices with i2c busses without
resorting to indexes.
Not
Hi Grant,
> if you need explicit indexing then use an alias. My opinion however
> is that explicit indexing is unnecessary and is just an artifact of
> current i2c subsystem internals. There is already enough information
> in the device tree to match i2c devices with i2c busses without
> resorti
Jochen Friedrich wrote:
> Hi Timur,
>
>> In situations where it doesn't matter which I2C bus is #1 and which one is
>> #2,
>> then I think the code should just initialize idx based on the order the nodes
>> are found in the tree.
>>
>> In situations where it does matter, then we should use cell-i
> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:linuxppc-dev-
> [EMAIL PROTECTED] On Behalf Of Josh
Boyer
> Sent: Thursday, June 05, 2008 8:19 AM
> To: Grant Likely
> Cc: linuxppc-dev@ozlabs.org; Paul Mackerras
> Subject: Re: 4xx support in arch/ppc is going away Real Soon Now
>
> O
I think we should just expand the definition of cell-index to include
standard
device enumeration for when it's needed. The original definition is
too
limited, IMHO.
nak
if you need explicit indexing then use an alias. My opinion however
is that explicit indexing is unnecessary and is just
Hi Timur,
> In situations where it doesn't matter which I2C bus is #1 and which one is #2,
> then I think the code should just initialize idx based on the order the nodes
> are found in the tree.
>
> In situations where it does matter, then we should use cell-index.
that's what I did in i2c-cpm,
Grant Likely wrote:
> if you need explicit indexing then use an alias. My opinion however
> is that explicit indexing is unnecessary and is just an artifact of
> current i2c subsystem internals. There is already enough information
> in the device tree to match i2c devices with i2c busses without
On Thu, Jun 5, 2008 at 9:13 AM, Timur Tabi <[EMAIL PROTECTED]> wrote:
> Josh Boyer wrote:
>
>> From a device tree perspective, index and cell-index are both
>> incorrect. The IIC macros don't share register blocks with anything,
>> are enumerated as unique instances per macro in the device tree, a
Stefan Roese wrote:
> So what should we do now? Currently I2C doesn't work at all on 4xx since the
> driver expects the "index" property and no dts sets this property. Personally
> I would like to move to using cell-index here, since this seems to be more
> common. But I could also life with re
Josh Boyer wrote:
> seems to be a more distinct definition of what this is. But I have no
> idea how well that would go over, and it would probably need to be
> changed in all the fsl boards as well.
Which would end up breaking backwards compatibility with older device trees.
Like I said earlier
Josh Boyer wrote:
> From a device tree perspective, index and cell-index are both
> incorrect. The IIC macros don't share register blocks with anything,
> are enumerated as unique instances per macro in the device tree, and
> should be able to be distinguished by "regs" and/or unit address.
I th
1 - 100 of 136 matches
Mail list logo
