m68knommu: CONFIG_I2C_COLDFIRE and CONFIG_RTC_DRV_M5441x

m68knommu: CONFIG_I2C_COLDFIRE and CONFIG_RTC_DRV_M5441x

[Paul Bolle]

Hi Geert,

In v3.6 both a check for CONFIG_I2C_COLDFIRE and two checks for
CONFIG_RTC_DRV_M5441x were added to the code for the coldfire platform
(in m525x.c and in m5441x.c respectively). Neither of these macros can
be matched to a Kconfig symbol.

Is a series that adds these Kconfig symbols pending?


Paul Bolle

Re: m68knommu: CONFIG_I2C_COLDFIRE and CONFIG_RTC_DRV_M5441x

[Geert Uytterhoeven]

Hi Paul,

On Tue, May 20, 2014 at 9:28 PM, Paul Bolle <pebolle@tiscali.nl> wrote:
> In v3.6 both a check for CONFIG_I2C_COLDFIRE and two checks for
> CONFIG_RTC_DRV_M5441x were added to the code for the coldfire platform
> (in m525x.c and in m5441x.c respectively). Neither of these macros can
> be matched to a Kconfig symbol.
>
> Is a series that adds these Kconfig symbols pending?

For the former, Steven King (cc) submitted patches in 2010 and 2012.
For the latter, he submitted patches in 2012.

Seems like they were never integrated...

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: m68knommu: CONFIG_I2C_COLDFIRE and CONFIG_RTC_DRV_M5441x

[Steven King]

On Tuesday 20 May 2014 1:19:26 pm Geert Uytterhoeven wrote:
> Hi Paul,
> 
> On Tue, May 20, 2014 at 9:28 PM, Paul Bolle <pebolle@tiscali.nl> wrote:
> > In v3.6 both a check for CONFIG_I2C_COLDFIRE and two checks for
> > CONFIG_RTC_DRV_M5441x were added to the code for the coldfire platform
> > (in m525x.c and in m5441x.c respectively). Neither of these macros can
> > be matched to a Kconfig symbol.
> >
> > Is a series that adds these Kconfig symbols pending?
> 
> For the former, Steven King (cc) submitted patches in 2010 and 2012.
> For the latter, he submitted patches in 2012.
> 
> Seems like they were never integrated...

Indeed.

At this point, they're pretty much superfluous so if someone were to submit a patch removing them, they would not get any objections from me.

Re: m68knommu: CONFIG_I2C_COLDFIRE and CONFIG_RTC_DRV_M5441x

[Paul Bolle]

On Tue, 2014-05-20 at 13:50 -0700, Steven King wrote:
> At this point, they're pretty much superfluous so if someone were to
> submit a patch removing them, they would not get any objections from
> me.

Just to be clear: you mean the checks for these two macros (and the code
hidden behind them), don't you?


Paul Bolle

Re: m68knommu: CONFIG_I2C_COLDFIRE and CONFIG_RTC_DRV_M5441x

[Steven King]

On Tuesday 20 May 2014 2:01:03 pm Paul Bolle wrote:
> On Tue, 2014-05-20 at 13:50 -0700, Steven King wrote:
> > At this point, they're pretty much superfluous so if someone were to
> > submit a patch removing them, they would not get any objections from
> > me.
> 
> Just to be clear: you mean the checks for these two macros (and the code
> hidden behind them), don't you?

Yes.

Re: m68knommu: CONFIG_I2C_COLDFIRE and CONFIG_RTC_DRV_M5441x

[Yannick GICQUEL]

Hi all,

The MCF5441x support is quite a hot topic today for our company.
This Soc family is seducing some of our customers, especially for it's 
long term support from Freescale.

We have worked on this target since past few weeks, using a Tower Kit 
hardware and JTag, and just about to prepare a full integration of this 
device on recent kernel release.
As a part of the open-source department, we have also planned to deliver 
this work to the community and propose some patches to refresh this 
target support.

Some informations we observe on this target to be refreshed:
  - NAND controller needs to be integrated again,
  - UART controller as well,

Also :
  - This chip contains a MMU and can be unlink from the !MMU dependency

This is for the big lines, if the community is ok for a patch receipt, 
some other feature can be also pushed.
BTW, what about this patches proposal ? Is there some time slot for 
patch proposal ?

Regards,

Le 20/05/2014 22:50, Steven King a écrit :
> On Tuesday 20 May 2014 1:19:26 pm Geert Uytterhoeven wrote:
>> Hi Paul,
>>
>> On Tue, May 20, 2014 at 9:28 PM, Paul Bolle <pebolle@tiscali.nl> wrote:
>>> In v3.6 both a check for CONFIG_I2C_COLDFIRE and two checks for
>>> CONFIG_RTC_DRV_M5441x were added to the code for the coldfire platform
>>> (in m525x.c and in m5441x.c respectively). Neither of these macros can
>>> be matched to a Kconfig symbol.
>>>
>>> Is a series that adds these Kconfig symbols pending?
>> For the former, Steven King (cc) submitted patches in 2010 and 2012.
>> For the latter, he submitted patches in 2012.
>>
>> Seems like they were never integrated...
> Indeed.
>
> At this point, they're pretty much superfluous so if someone were to submit a patch removing them, they would not get any objections from me.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: m68knommu: CONFIG_I2C_COLDFIRE and CONFIG_RTC_DRV_M5441x

[Paul Bolle]

Yannick,

On Wed, 2014-05-21 at 17:46 +0200, Yannick GICQUEL wrote:
> The MCF5441x support is quite a hot topic today for our company.
> This Soc family is seducing some of our customers, especially for it's 
> long term support from Freescale.
> 
> We have worked on this target since past few weeks, using a Tower Kit 
> hardware and JTag, and just about to prepare a full integration of this 
> device on recent kernel release.
> As a part of the open-source department, we have also planned to deliver 
> this work to the community and propose some patches to refresh this 
> target support.
> 
> Some informations we observe on this target to be refreshed:
>   - NAND controller needs to be integrated again,
>   - UART controller as well,
> 
> Also :
>   - This chip contains a MMU and can be unlink from the !MMU dependency
> 
> This is for the big lines, if the community is ok for a patch receipt, 
> some other feature can be also pushed.
> BTW, what about this patches proposal ? Is there some time slot for 
> patch proposal ?

The patch discussed (but not yet submitted) would remove all code
currently hidden behind
    #if IS_ENABLED(CONFIG_RTC_DRV_M5441x)

in the kernel tree. Now, I'm guessing the (new) code you're working on
doesn't care about CONFIG_RTC_DRV_M5441x. So chances are you could not
care less if that code gets removed.


Paul Bolle

Re: m68knommu: CONFIG_I2C_COLDFIRE and CONFIG_RTC_DRV_M5441x

[Steven King]

On Wednesday 21 May 2014 8:46:46 am Yannick GICQUEL wrote:
> Hi all,
> 
> The MCF5441x support is quite a hot topic today for our company.
> This Soc family is seducing some of our customers, especially for it's 
> long term support from Freescale.
> 
> We have worked on this target since past few weeks, using a Tower Kit 
> hardware and JTag, and just about to prepare a full integration of this 
> device on recent kernel release.
> As a part of the open-source department, we have also planned to deliver 
> this work to the community and propose some patches to refresh this 
> target support.
> 
> Some informations we observe on this target to be refreshed:
>   - NAND controller needs to be integrated again,
>   - UART controller as well,
> 
> Also :
>   - This chip contains a MMU and can be unlink from the !MMU dependency
> 
> This is for the big lines, if the community is ok for a patch receipt, 
> some other feature can be also pushed.
> BTW, what about this patches proposal ? Is there some time slot for 
> patch proposal ?
> 

That interesting.  As Paul mentioned the proposed patch would remove the unused code supporting the RTC on the m5441x, however, I do have an updated (v3.15-rc5) version of the RTC driver as well as updated versions of the 1wire driver that I had submiited a couple of years ago, also a much simplier version of the patches to enable the enet-fec that I had posted previously.  I've also been looking at getting the eDMA working with an eye on adding support for the dspi.

As it didnt seem there was much interest in the platform I hadn't felt any need to try to get these merged, but if there is actually anyone besides myself interested in the m5441x I'd be a bit more motivated.

Re: m68knommu: CONFIG_I2C_COLDFIRE and CONFIG_RTC_DRV_M5441x

[Greg Ungerer]

Hi Yannick,

On 22/05/14 01:46, Yannick GICQUEL wrote:
> The MCF5441x support is quite a hot topic today for our company.
> This Soc family is seducing some of our customers, especially for it's long term support from Freescale.
> 
> We have worked on this target since past few weeks, using a Tower Kit hardware and JTag, and just about to prepare a full integration of this device on recent kernel release.
> As a part of the open-source department, we have also planned to deliver this work to the community and propose some patches to refresh this target support.
> 
> Some informations we observe on this target to be refreshed:
>  - NAND controller needs to be integrated again,
>  - UART controller as well,

What needs to be done to the mcf UART driver?
It seems all other ColdFire parts have used pretty much the same
module.


> Also :
>  - This chip contains a MMU and can be unlink from the !MMU dependency

The ColdFire v4e MMU has been supported for quite a while in main
line kernels (from linux-3.3 onwards). I believe it will need some
tweaks for the mcf5441x, but the heavy lifting is done.

Also keep in mind that for ColdFire that have an MMU we support them
both with the MMU enabled and disabled.


> This is for the big lines, if the community is ok for a patch receipt, some other feature can be also pushed.
> BTW, what about this patches proposal ? Is there some time slot for patch proposal ?

Early and often :-)
Post them here. If you are really unsure about some specific feature
then you can discuss it here first. But if you have code already why
not just send patches.

Regards
Greg


> Regards,
> 
> Le 20/05/2014 22:50, Steven King a écrit :
>> On Tuesday 20 May 2014 1:19:26 pm Geert Uytterhoeven wrote:
>>> Hi Paul,
>>>
>>> On Tue, May 20, 2014 at 9:28 PM, Paul Bolle <pebolle@tiscali.nl> wrote:
>>>> In v3.6 both a check for CONFIG_I2C_COLDFIRE and two checks for
>>>> CONFIG_RTC_DRV_M5441x were added to the code for the coldfire platform
>>>> (in m525x.c and in m5441x.c respectively). Neither of these macros can
>>>> be matched to a Kconfig symbol.
>>>>
>>>> Is a series that adds these Kconfig symbols pending?
>>> For the former, Steven King (cc) submitted patches in 2010 and 2012.
>>> For the latter, he submitted patches in 2012.
>>>
>>> Seems like they were never integrated...
>> Indeed.
>>
>> At this point, they're pretty much superfluous so if someone were to submit a patch removing them, they would not get any objections from me.
>> -- 
>> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: m68knommu: CONFIG_I2C_COLDFIRE and CONFIG_RTC_DRV_M5441x

[Yannick GICQUEL]

Hi Greg,

Le 22/05/2014 03:04, Greg Ungerer a écrit :
> Hi Yannick,
>
> On 22/05/14 01:46, Yannick GICQUEL wrote:
>> The MCF5441x support is quite a hot topic today for our company.
>> This Soc family is seducing some of our customers, especially for it's long term support from Freescale.
>>
>> We have worked on this target since past few weeks, using a Tower Kit hardware and JTag, and just about to prepare a full integration of this device on recent kernel release.
>> As a part of the open-source department, we have also planned to deliver this work to the community and propose some patches to refresh this target support.
>>
>> Some informations we observe on this target to be refreshed:
>>   - NAND controller needs to be integrated again,
>>   - UART controller as well,
> What needs to be done to the mcf UART driver?
> It seems all other ColdFire parts have used pretty much the same
> module.
You're right. After initials investigations, we thought there was a 
rework needed but after yesterday investigations, we confirm it's 
functional state is Ok.
Please, just forget initial rework mentioned :-)
>> Also :
>>   - This chip contains a MMU and can be unlink from the !MMU dependency
> The ColdFire v4e MMU has been supported for quite a while in main
> line kernels (from linux-3.3 onwards). I believe it will need some
> tweaks for the mcf5441x, but the heavy lifting is done.
>
> Also keep in mind that for ColdFire that have an MMU we support them
> both with the MMU enabled and disabled.
>   
Ok, we will keep it in mind.
We had a look on this MMU activation and functional state is ko.
To state this, we had to unlink MMU activation to FPU activation, but 
this is not as simple and it need a deeper investigation.
>> This is for the big lines, if the community is ok for a patch receipt, some other feature can be also pushed.
>> BTW, what about this patches proposal ? Is there some time slot for patch proposal ?
> Early and often :-)
> Post them here. If you are really unsure about some specific feature
> then you can discuss it here first. But if you have code already why
> not just send patches.
Our patches are not clean enough to be posted right now, but as people 
here are receptive to this, we will go on.

>
> Regards
> Greg
>
>
>> Regards,
>>
>> Le 20/05/2014 22:50, Steven King a écrit :
>>> On Tuesday 20 May 2014 1:19:26 pm Geert Uytterhoeven wrote:
>>>> Hi Paul,
>>>>
>>>> On Tue, May 20, 2014 at 9:28 PM, Paul Bolle <pebolle@tiscali.nl> wrote:
>>>>> In v3.6 both a check for CONFIG_I2C_COLDFIRE and two checks for
>>>>> CONFIG_RTC_DRV_M5441x were added to the code for the coldfire platform
>>>>> (in m525x.c and in m5441x.c respectively). Neither of these macros can
>>>>> be matched to a Kconfig symbol.
>>>>>
>>>>> Is a series that adds these Kconfig symbols pending?
>>>> For the former, Steven King (cc) submitted patches in 2010 and 2012.
>>>> For the latter, he submitted patches in 2012.
>>>>
>>>> Seems like they were never integrated...
>>> Indeed.
>>>
>>> At this point, they're pretty much superfluous so if someone were to submit a patch removing them, they would not get any objections from me.
>>> -- 
>>> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> -- 
>> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>

Re: m68knommu: CONFIG_I2C_COLDFIRE and CONFIG_RTC_DRV_M5441x

[Yannick GICQUEL]

Hi Steven, Paul,

Le 21/05/2014 23:47, Steven King a écrit :
> On Wednesday 21 May 2014 8:46:46 am Yannick GICQUEL wrote:
>> Hi all,
>>
>> The MCF5441x support is quite a hot topic today for our company.
>> This Soc family is seducing some of our customers, especially for it's
>> long term support from Freescale.
>>
>> We have worked on this target since past few weeks, using a Tower Kit
>> hardware and JTag, and just about to prepare a full integration of this
>> device on recent kernel release.
>> As a part of the open-source department, we have also planned to deliver
>> this work to the community and propose some patches to refresh this
>> target support.
>>
>> Some informations we observe on this target to be refreshed:
>>    - NAND controller needs to be integrated again,
>>    - UART controller as well,
>>
>> Also :
>>    - This chip contains a MMU and can be unlink from the !MMU dependency
>>
>> This is for the big lines, if the community is ok for a patch receipt,
>> some other feature can be also pushed.
>> BTW, what about this patches proposal ? Is there some time slot for
>> patch proposal ?
>>
> That interesting.  As Paul mentioned the proposed patch would remove the unused code supporting the RTC on the m5441x, however, I do have an updated (v3.15-rc5) version of the RTC driver as well as updated versions of the 1wire driver that I had submiited a couple of years ago, also a much simplier version of the patches to enable the enet-fec that I had posted previously.  I've also been looking at getting the eDMA working with an eye on adding support for the dspi.
>
> As it didnt seem there was much interest in the platform I hadn't felt any need to try to get these merged, but if there is actually anyone besides myself interested in the m5441x I'd be a bit more motivated.

We agree these specifics defined are not handled in KConfig anymore and 
code cleanup is always a good thing.
RTC support is not a big deal, we are more focusing on the Nand 
reintegration and MMU.

FYI, as a part of pre-study and POC activities for industrials 
requirements, the code we are working on is today based on initials BSP 
from Freescale (ported on 2.6.29 and 2.6.38) with features set hopefully 
qualified on them (nand ctrl, dspi, i2c, can, enet-fec, ...).

Regards,
Yannick