Flat device tree definitions for FLASH and MTD partitioning

Flat device tree definitions for FLASH and MTD partitioning

[Wolfgang Grandegger]

Hello,

are there already some thought or even example code on how to define 
Flash memory and MTD partitions in the DTS. This would avoid the ackward 
MTD partitioning via static structure or boot line argument and could be 
done in a generic way.

Thanks.

Wolfgang.

Re: Flat device tree definitions for FLASH and MTD partitioning

[Sergei Shtylyov]

Hello.

Wolfgang Grandegger wrote:

> are there already some thought or even example code on how to define 
> Flash memory and MTD partitions in the DTS. This would avoid the ackward 
> MTD partitioning via static structure or boot line argument and could be 
> done in a generic way.

    See Documentation/powerpc/booting-without-of.txt and 
drivers/mtd/physmap_of.c for what's been already done.

> Thanks.
> 
> Wolfgang.

WBR, Sergei

Re: Flat device tree definitions for FLASH and MTD partitioning

[Sergei Shtylyov]

Hello, I wrote:

>>are there already some thought or even example code on how to define 
>>Flash memory and MTD partitions in the DTS. This would avoid the ackward 
>>MTD partitioning via static structure or boot line argument and could be 
>>done in a generic way.

>     See Documentation/powerpc/booting-without-of.txt and 
> drivers/mtd/physmap_of.c for what's been already done.

    I meant drivers/mtd/maps/physmap_of.c

>>Thanks.

>>Wolfgang.

WBR, Sergei

Re: Flat device tree definitions for FLASH and MTD partitioning

[Wolfgang Grandegger]

Sergei Shtylyov wrote:
> Hello, I wrote:
> 
>>> are there already some thought or even example code on how to define 
>>> Flash memory and MTD partitions in the DTS. This would avoid the 
>>> ackward MTD partitioning via static structure or boot line argument 
>>> and could be done in a generic way.
> 
>>     See Documentation/powerpc/booting-without-of.txt and 
>> drivers/mtd/physmap_of.c for what's been already done.
> 
>    I meant drivers/mtd/maps/physmap_of.c

Ah, I missed that, thanks a lot.

Wolfgang.

Re: Flat device tree definitions for FLASH and MTD partitioning

[Wolfgang Grandegger]

Sergei Shtylyov wrote:
> Hello, I wrote:
> 
>>> are there already some thought or even example code on how to define 
>>> Flash memory and MTD partitions in the DTS. This would avoid the 
>>> ackward MTD partitioning via static structure or boot line argument 
>>> and could be done in a generic way.
> 
>>     See Documentation/powerpc/booting-without-of.txt and 
>> drivers/mtd/physmap_of.c for what's been already done.
> 
>    I meant drivers/mtd/maps/physmap_of.c

I had a closer look to this driver. Unfortunately, it can not handle yet 
  multiple FLASH banks. This could be achieved with an additional 
property "bank_count". What do you think?

Wolfgang.

Re: Flat device tree definitions for FLASH and MTD partitioning

[Sergei Shtylyov]

Hello.

Wolfgang Grandegger wrote:

>>>> are there already some thought or even example code on how to define 
>>>> Flash memory and MTD partitions in the DTS. This would avoid the 
>>>> ackward MTD partitioning via static structure or boot line argument 
>>>> and could be done in a generic way.

>>>     See Documentation/powerpc/booting-without-of.txt and 
>>> drivers/mtd/physmap_of.c for what's been already done.

>>    I meant drivers/mtd/maps/physmap_of.c
 
> I had a closer look to this driver. Unfortunately, it can not handle yet 
>  multiple FLASH banks. This could be achieved with an additional 
> property "bank_count". What do you think?

  I'm not sure what banks you're talking about -- note that this driver is equivalen in functionality to the plain 'physmap' driver and there's inherited "bank-width" property that handles flash banking.

> Wolfgang.

MBR, Sergei

Re: Flat device tree definitions for FLASH and MTD partitioning

[Wolfgang Grandegger]

Sergei Shtylyov wrote:
> Hello.
> 
> Wolfgang Grandegger wrote:
> 
>>>>> are there already some thought or even example code on how to 
>>>>> define Flash memory and MTD partitions in the DTS. This would avoid 
>>>>> the ackward MTD partitioning via static structure or boot line 
>>>>> argument and could be done in a generic way.
> 
>>>>     See Documentation/powerpc/booting-without-of.txt and 
>>>> drivers/mtd/physmap_of.c for what's been already done.
> 
>>>    I meant drivers/mtd/maps/physmap_of.c
> 
>> I had a closer look to this driver. Unfortunately, it can not handle 
>> yet  multiple FLASH banks. This could be achieved with an additional 
>> property "bank_count". What do you think?
> 
>  I'm not sure what banks you're talking about -- note that this driver 
> is equivalen in functionality to the plain 'physmap' driver and there's 
> inherited "bank-width" property that handles flash banking.

Yes, I know. Nevertheless the driver cannot handle flash regions 
composed of more than on FLASH bank because we need to probe every bank. 
Search for "BANK" in drivers/mtd/maps" to understand what I mean.

Wolfgang.

Re: Flat device tree definitions for FLASH and MTD partitioning

[Sergei Shtylyov]

Hello.

Wolfgang Grandegger wrote:

>>>>>> are there already some thought or even example code on how to 
>>>>>> define Flash memory and MTD partitions in the DTS. This would 
>>>>>> avoid the ackward MTD partitioning via static structure or boot 
>>>>>> line argument and could be done in a generic way.

>>>>>     See Documentation/powerpc/booting-without-of.txt and 
>>>>> drivers/mtd/physmap_of.c for what's been already done.

>>>>    I meant drivers/mtd/maps/physmap_of.c

>>> I had a closer look to this driver. Unfortunately, it can not handle 
>>> yet  multiple FLASH banks. This could be achieved with an additional 
>>> property "bank_count". What do you think?

   Please use hyphen, not underscore in property names ("device_type" seems an only exception from this rule).

>>  I'm not sure what banks you're talking about -- note that this driver 
>> is equivalen in functionality to the plain 'physmap' driver and 
>> there's inherited "bank-width" property that handles flash banking.
 
> Yes, I know. Nevertheless the driver cannot handle flash regions 
> composed of more than on FLASH bank because we need to probe every bank. 
> Search for "BANK" in drivers/mtd/maps" to understand what I mean.

   Hm, from what I could see, those banks are separate maps registered to MTD subsys separately.
What's the point of adding a count property when we simply can define multiple "rom" devices?

> Wolfgang.

MBR, Sergei

Re: Flat device tree definitions for FLASH and MTD partitioning

[Wolfgang Grandegger]

Sergei Shtylyov wrote:
> Hello.
> 
> Wolfgang Grandegger wrote:
> 
>>>>>>> are there already some thought or even example code on how to 
>>>>>>> define Flash memory and MTD partitions in the DTS. This would 
>>>>>>> avoid the ackward MTD partitioning via static structure or boot 
>>>>>>> line argument and could be done in a generic way.
> 
>>>>>>     See Documentation/powerpc/booting-without-of.txt and 
>>>>>> drivers/mtd/physmap_of.c for what's been already done.
> 
>>>>>    I meant drivers/mtd/maps/physmap_of.c
> 
>>>> I had a closer look to this driver. Unfortunately, it can not handle 
>>>> yet  multiple FLASH banks. This could be achieved with an additional 
>>>> property "bank_count". What do you think?
> 
>   Please use hyphen, not underscore in property names ("device_type" 
> seems an only exception from this rule).
> 
>>>  I'm not sure what banks you're talking about -- note that this 
>>> driver is equivalen in functionality to the plain 'physmap' driver 
>>> and there's inherited "bank-width" property that handles flash banking.
> 
>> Yes, I know. Nevertheless the driver cannot handle flash regions 
>> composed of more than on FLASH bank because we need to probe every 
>> bank. Search for "BANK" in drivers/mtd/maps" to understand what I mean.
> 
>   Hm, from what I could see, those banks are separate maps registered to 
> MTD subsys separately.
> What's the point of adding a count property when we simply can define 
> multiple "rom" devices?

Well, I was wrong. In the meantime I realized that physmap can handle 
flash region compiosed of multiple banks. Sorry for the noise.

Wolfgang.

Re: Flat device tree definitions for FLASH and MTD partitioning

[Wolfgang Grandegger]

Sergei Shtylyov wrote:
> Hello.
> 
> Wolfgang Grandegger wrote:
> 
>>>>>>> are there already some thought or even example code on how to 
>>>>>>> define Flash memory and MTD partitions in the DTS. This would 
>>>>>>> avoid the ackward MTD partitioning via static structure or boot 
>>>>>>> line argument and could be done in a generic way.
> 
>>>>>>     See Documentation/powerpc/booting-without-of.txt and 
>>>>>> drivers/mtd/physmap_of.c for what's been already done.
> 
>>>>>    I meant drivers/mtd/maps/physmap_of.c
> 
>>>> I had a closer look to this driver. Unfortunately, it can not handle 
>>>> yet  multiple FLASH banks. This could be achieved with an additional 
>>>> property "bank_count". What do you think?
> 
>   Please use hyphen, not underscore in property names ("device_type" 
> seems an only exception from this rule).

Yes, I know and I also wondered why an "_" is used for the device type.

>>>  I'm not sure what banks you're talking about -- note that this 
>>> driver is equivalen in functionality to the plain 'physmap' driver 
>>> and there's inherited "bank-width" property that handles flash banking.
> 
>> Yes, I know. Nevertheless the driver cannot handle flash regions 
>> composed of more than on FLASH bank because we need to probe every 
>> bank. Search for "BANK" in drivers/mtd/maps" to understand what I mean.
> 
>   Hm, from what I could see, those banks are separate maps registered to 
> MTD subsys separately.
> What's the point of adding a count property when we simply can define 
> multiple "rom" devices?

To complete this thread, physmap_of can map _one_ FLASH region composed 
of one or more FLASH banks. But it currently cannot map more than _one_ 
FLASH region. It would be nice to extend it for multiple FLASH 
definitions (could code it when time permits).

Wolfgang.

Re: Flat device tree definitions for FLASH and MTD partitioning

[Sergei Shtylyov]

Hello.

Wolfgang Grandegger wrote:

>>>>>>>> are there already some thought or even example code on how to 
>>>>>>>> define Flash memory and MTD partitions in the DTS. This would 
>>>>>>>> avoid the ackward MTD partitioning via static structure or boot 
>>>>>>>> line argument and could be done in a generic way.

>>>>>>>     See Documentation/powerpc/booting-without-of.txt and 
>>>>>>> drivers/mtd/physmap_of.c for what's been already done.

>>>>>>    I meant drivers/mtd/maps/physmap_of.c

>>>>> I had a closer look to this driver. Unfortunately, it can not 
>>>>> handle yet  multiple FLASH banks. This could be achieved with an 
>>>>> additional property "bank_count". What do you think?

>>   Please use hyphen, not underscore in property names ("device_type" 
>> seems an only exception from this rule).
 
> Yes, I know and I also wondered why an "_" is used for the device type.

   Ask the OF spec. developers. :-)
 
>>>>  I'm not sure what banks you're talking about -- note that this 
>>>> driver is equivalen in functionality to the plain 'physmap' driver 
>>>> and there's inherited "bank-width" property that handles flash banking.

>>> Yes, I know. Nevertheless the driver cannot handle flash regions 
>>> composed of more than on FLASH bank because we need to probe every 
>>> bank. Search for "BANK" in drivers/mtd/maps" to understand what I mean.

>>   Hm, from what I could see, those banks are separate maps registered 
>> to MTD subsys separately.
>> What's the point of adding a count property when we simply can define 
>> multiple "rom" devices?
 
> To complete this thread, physmap_of can map _one_ FLASH region composed 
> of one or more FLASH banks. But it currently cannot map more than _one_ 
> FLASH region.

   I wodner why?! :-O

> It would be nice to extend it for multiple FLASH 
> definitions (could code it when time permits).

   I'm seeing nothing that prevents it from working now -- it should register as much "rom" devices as you supply via the device tree.

> Wolfgang.

MBR, Sergei

Re: Flat device tree definitions for FLASH and MTD partitioning

[Wolfgang Grandegger]

Sergei Shtylyov wrote:
> Hello.
> 
> Wolfgang Grandegger wrote:
> 
>>>>>>>>> are there already some thought or even example code on how to 
>>>>>>>>> define Flash memory and MTD partitions in the DTS. This would 
>>>>>>>>> avoid the ackward MTD partitioning via static structure or boot 
>>>>>>>>> line argument and could be done in a generic way.
> 
>>>>>>>>     See Documentation/powerpc/booting-without-of.txt and 
>>>>>>>> drivers/mtd/physmap_of.c for what's been already done.
> 
>>>>>>>    I meant drivers/mtd/maps/physmap_of.c
> 
>>>>>> I had a closer look to this driver. Unfortunately, it can not 
>>>>>> handle yet  multiple FLASH banks. This could be achieved with an 
>>>>>> additional property "bank_count". What do you think?
> 
>>>   Please use hyphen, not underscore in property names ("device_type" 
>>> seems an only exception from this rule).
> 
>> Yes, I know and I also wondered why an "_" is used for the device type.
> 
>   Ask the OF spec. developers. :-)
> 
>>>>>  I'm not sure what banks you're talking about -- note that this 
>>>>> driver is equivalen in functionality to the plain 'physmap' driver 
>>>>> and there's inherited "bank-width" property that handles flash 
>>>>> banking.
> 
>>>> Yes, I know. Nevertheless the driver cannot handle flash regions 
>>>> composed of more than on FLASH bank because we need to probe every 
>>>> bank. Search for "BANK" in drivers/mtd/maps" to understand what I mean.
> 
>>>   Hm, from what I could see, those banks are separate maps registered 
>>> to MTD subsys separately.
>>> What's the point of adding a count property when we simply can define 
>>> multiple "rom" devices?
> 
>> To complete this thread, physmap_of can map _one_ FLASH region 
>> composed of one or more FLASH banks. But it currently cannot map more 
>> than _one_ FLASH region.
> 
>   I wodner why?! :-O

I know as well ;-).

>> It would be nice to extend it for multiple FLASH definitions (could 
>> code it when time permits).
> 
>   I'm seeing nothing that prevents it from working now -- it should 
> register as much "rom" devices as you supply via the device tree.

OK, I see, for each registered direct-mapped flash resource, 
of_physmap_probe() will be called.

Thanks.

Wolfgang.