All of lore.kernel.org
 help / color / mirror / Atom feed
From: LEROY Christophe <christophe.leroy@c-s.fr>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: David Brownell <dbrownell@users.sourceforge.net>,
	spi-devel-general@lists.sourceforge.net,
	linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	Kumar Gala <galak@kernel.crashing.org>,
	Anton Vorontsov <avorontsov@ru.mvista.com>
Subject: Re: [PATCH] spi_mpc8xxx: issue with using definition of pram in Device Tree
Date: Fri, 24 Sep 2010 09:20:27 +0200	[thread overview]
Message-ID: <4C9C513B.40501@c-s.fr> (raw)
In-Reply-To: <20100924071006.GA21318@angua.secretlab.ca>

[-- Attachment #1: Type: text/plain, Size: 1618 bytes --]

  Hello,

The issue is that cpm_muram_alloc_fixed() allocates memory from the 
general purpose muram area (from 0x0 to 0x1bff).
Here we need to return a pointer to the parameter RAM, which is located 
somewhere starting at 0x1c00. It is not a dynamic allocation that is 
required here but only to point on the correct location in the parameter 
RAM.

For the CPM2, I don't know. I'm working with a MPC866.

Attached is a previous discussion on the subject where I explain a bit 
more in details the issue.

Regards
C. Leroy

Le 24/09/2010 09:10, Grant Likely a écrit :
> On Thu, Sep 16, 2010 at 09:05:03AM +0200, christophe leroy wrote:
>> This patch applies to 2.6.34.7 and 2.6.35.4
>> It fixes an issue during the probe for CPM1 with definition of parameter ram from DTS
>>
>> Signed-off-by: christophe leroy<christophe.leroy@c-s.fr>
> I'm sorry, I don't understand the fix from the given description.
> What is the problem, and why is cpm_muram_alloc_fixed() the wrong
> thing to call on CPM1?  Does CPM2 still need it?
>
> g.
>
>> diff -urN b/drivers/spi/spi_mpc8xxx.c c/drivers/spi/spi_mpc8xxx.c
>> --- b/drivers/spi/spi_mpc8xxx.c	2010-09-08 16:43:50.000000000 +0200
>> +++ c/drivers/spi/spi_mpc8xxx.c	2010-09-08 16:44:03.000000000 +0200
>> @@ -822,7 +822,7 @@
>>   	if (!iprop || size != sizeof(*iprop) * 4)
>>   		return -ENOMEM;
>>
>> -	spi_base_ofs = cpm_muram_alloc_fixed(iprop[2], 2);
>> +	spi_base_ofs = iprop[2];
>>   	if (IS_ERR_VALUE(spi_base_ofs))
>>   		return -ENOMEM;
>>
>> @@ -844,7 +844,6 @@
>>   			return spi_base_ofs;
>>   	}
>>
>> -	cpm_muram_free(spi_base_ofs);
>>   	return pram_ofs;
>>   }

[-- Attachment #2: Message joint --]
[-- Type: message/rfc822, Size: 6373 bytes --]

From: Scott Wood <scottwood@freescale.com>
To: LEROY Christophe <christophe.leroy@c-s.fr>
Cc: Kumar Gala <kumar.gala@freescale.com>, LinuxPPC-dev <linuxppc-dev@lists.ozlabs.org>
Subject: Re: Small issue at init with spi_mpc8xxx.c with CPM1
Date: Tue, 7 Sep 2010 15:00:38 -0500
Message-ID: <20100907150038.57a7b065@schlenkerla.am.freescale.net>

On Tue, 7 Sep 2010 11:17:17 +0200
LEROY Christophe <christophe.leroy@c-s.fr> wrote:

> 
>   Dear Kumar,
> 
> I have a small issue in the init of spi_mpc8xxx.c with MPC866 (CPM1)
> 
> Unlike cpm_uart that maps the parameter ram directly using 
> of_iomap(np,1), spi_mpc8xxx.c uses cpm_muram_alloc_fixed().
> 
> This has two impacts in the .dts file:
> * The driver must be declared with pram at 1d80 instead of 3d80 whereas 
> it is not a child of muram@2000 but a child of cpm@9c0
> * muram@2000/data@0 must be declared with reg = <0x0 0x2000>   whereas 
> is should be reg=<0x0 0x1c00> to avoid cpm_muram_alloc() to allocate 
> space from parameters ram.
> 
> Maybe I misunderstood something ?

Don't make the device tree lie, fix the driver instead.

The allocator should not be given any chunks of muram that are
dedicated to a fixed purpose -- it might hand it out to something else
before you reserve it.  I don't think that cpm_muram_alloc_fixed() has
any legitimate use at all.

-Scott

_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


WARNING: multiple messages have this Message-ID (diff)
From: LEROY Christophe <christophe.leroy@c-s.fr>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: David Brownell <dbrownell@users.sourceforge.net>,
	linux-kernel@vger.kernel.org,
	spi-devel-general@lists.sourceforge.net,
	Anton Vorontsov <avorontsov@ru.mvista.com>,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH] spi_mpc8xxx: issue with using definition of pram in Device Tree
Date: Fri, 24 Sep 2010 09:20:27 +0200	[thread overview]
Message-ID: <4C9C513B.40501@c-s.fr> (raw)
In-Reply-To: <20100924071006.GA21318@angua.secretlab.ca>

[-- Attachment #1: Type: text/plain, Size: 1618 bytes --]

  Hello,

The issue is that cpm_muram_alloc_fixed() allocates memory from the 
general purpose muram area (from 0x0 to 0x1bff).
Here we need to return a pointer to the parameter RAM, which is located 
somewhere starting at 0x1c00. It is not a dynamic allocation that is 
required here but only to point on the correct location in the parameter 
RAM.

For the CPM2, I don't know. I'm working with a MPC866.

Attached is a previous discussion on the subject where I explain a bit 
more in details the issue.

Regards
C. Leroy

Le 24/09/2010 09:10, Grant Likely a écrit :
> On Thu, Sep 16, 2010 at 09:05:03AM +0200, christophe leroy wrote:
>> This patch applies to 2.6.34.7 and 2.6.35.4
>> It fixes an issue during the probe for CPM1 with definition of parameter ram from DTS
>>
>> Signed-off-by: christophe leroy<christophe.leroy@c-s.fr>
> I'm sorry, I don't understand the fix from the given description.
> What is the problem, and why is cpm_muram_alloc_fixed() the wrong
> thing to call on CPM1?  Does CPM2 still need it?
>
> g.
>
>> diff -urN b/drivers/spi/spi_mpc8xxx.c c/drivers/spi/spi_mpc8xxx.c
>> --- b/drivers/spi/spi_mpc8xxx.c	2010-09-08 16:43:50.000000000 +0200
>> +++ c/drivers/spi/spi_mpc8xxx.c	2010-09-08 16:44:03.000000000 +0200
>> @@ -822,7 +822,7 @@
>>   	if (!iprop || size != sizeof(*iprop) * 4)
>>   		return -ENOMEM;
>>
>> -	spi_base_ofs = cpm_muram_alloc_fixed(iprop[2], 2);
>> +	spi_base_ofs = iprop[2];
>>   	if (IS_ERR_VALUE(spi_base_ofs))
>>   		return -ENOMEM;
>>
>> @@ -844,7 +844,6 @@
>>   			return spi_base_ofs;
>>   	}
>>
>> -	cpm_muram_free(spi_base_ofs);
>>   	return pram_ofs;
>>   }

[-- Attachment #2: Message joint --]
[-- Type: message/rfc822, Size: 6373 bytes --]

From: Scott Wood <scottwood@freescale.com>
To: LEROY Christophe <christophe.leroy@c-s.fr>
Cc: Kumar Gala <kumar.gala@freescale.com>, LinuxPPC-dev <linuxppc-dev@lists.ozlabs.org>
Subject: Re: Small issue at init with spi_mpc8xxx.c with CPM1
Date: Tue, 7 Sep 2010 15:00:38 -0500
Message-ID: <20100907150038.57a7b065@schlenkerla.am.freescale.net>

On Tue, 7 Sep 2010 11:17:17 +0200
LEROY Christophe <christophe.leroy@c-s.fr> wrote:

> 
>   Dear Kumar,
> 
> I have a small issue in the init of spi_mpc8xxx.c with MPC866 (CPM1)
> 
> Unlike cpm_uart that maps the parameter ram directly using 
> of_iomap(np,1), spi_mpc8xxx.c uses cpm_muram_alloc_fixed().
> 
> This has two impacts in the .dts file:
> * The driver must be declared with pram at 1d80 instead of 3d80 whereas 
> it is not a child of muram@2000 but a child of cpm@9c0
> * muram@2000/data@0 must be declared with reg = <0x0 0x2000>   whereas 
> is should be reg=<0x0 0x1c00> to avoid cpm_muram_alloc() to allocate 
> space from parameters ram.
> 
> Maybe I misunderstood something ?

Don't make the device tree lie, fix the driver instead.

The allocator should not be given any chunks of muram that are
dedicated to a fixed purpose -- it might hand it out to something else
before you reserve it.  I don't think that cpm_muram_alloc_fixed() has
any legitimate use at all.

-Scott

_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


  reply	other threads:[~2010-09-24  7:20 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-16  7:05 [PATCH] spi_mpc8xxx: issue with using definition of pram in Device Tree christophe leroy
2010-09-24  7:10 ` Grant Likely
2010-09-24  7:10   ` Grant Likely
2010-09-24  7:20   ` LEROY Christophe [this message]
2010-09-24  7:20     ` LEROY Christophe
2010-09-24  7:57     ` Anton Vorontsov
2010-09-24  7:57       ` Anton Vorontsov
2010-09-24 15:12       ` Scott Wood
2010-09-24 15:12         ` Scott Wood
2010-09-24 15:07   ` Scott Wood

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4C9C513B.40501@c-s.fr \
    --to=christophe.leroy@c-s.fr \
    --cc=avorontsov@ru.mvista.com \
    --cc=dbrownell@users.sourceforge.net \
    --cc=galak@kernel.crashing.org \
    --cc=grant.likely@secretlab.ca \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=spi-devel-general@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.