* Re: 85xx FDT updates?
From: Eugene Surovegin @ 2006-04-25 19:31 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <01B6C49A-F82A-47CF-B7B8-106BC0BBDF14@kernel.crashing.org>
On Tue, Apr 25, 2006 at 02:20:03PM -0500, Kumar Gala wrote:
>
> On Apr 25, 2006, at 1:53 PM, Eugene Surovegin wrote:
>
> >On Tue, Apr 25, 2006 at 01:33:38PM -0500, Kumar Gala wrote:
> >>I personally dont have any time or interesting in it.
> >
> >So, don't break compatibility if you don't have time/interest to fix
> >it. We can wait till someone who "wants to move forward" can do this
> >professionally without screwing everybody else.
>
> If I break compatibility for boards I maintain I don't see the issue
> as long as I provide a workable solution.
Sorry, but IMO saying you have to upgrade firmware is not a workable
solution.
Firmware <-> kernel is external interface. Kernel shouldn't break it
unless there is a good technical reason to do so. Developer
convenience or lack of time is not a good technical reason in my book.
--
Eugene
^ permalink raw reply
* Re: 85xx FDT updates?
From: Eugene Surovegin @ 2006-04-25 19:27 UTC (permalink / raw)
To: Andy Fleming; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <F2D4EB11-5E74-4A8E-9F73-B5BFEB2B950C@freescale.com>
On Tue, Apr 25, 2006 at 02:14:28PM -0500, Andy Fleming wrote:
> I think there's some confusion here (at least, I'm confused), so let
> me see if I have this right:
>
> 1) Kumar is advocating the eventual removal of support for booting
> the 85xx CDS and 85xx ADS boards without a flat-device tree
>
> 2) Eugene and Dan say this will break systems that are already deployed
>
> 3) Kumar says that the 85xx CDS and ADS systems are reference
> platforms, and therefore not meant for deployment.
>
> 4) Eugene implies that removal of 85xx CDS and ADS support from arch/
> ppc should be accompanied by some sort of compatibility options for
> booting arch/powerpc Linux from an old u-boot
>
> Do I have this right?
Yes :)
--
Eugene
^ permalink raw reply
* Re: 85xx FDT updates?
From: Kumar Gala @ 2006-04-25 19:22 UTC (permalink / raw)
To: Andy Fleming; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <F2D4EB11-5E74-4A8E-9F73-B5BFEB2B950C@freescale.com>
On Apr 25, 2006, at 2:14 PM, Andy Fleming wrote:
>
> On Apr 25, 2006, at 13:48, Eugene Surovegin wrote:
>
>> On Tue, Apr 25, 2006 at 01:29:34PM -0500, Brent Cook wrote:
>>>> ....
>
>>>> Providing compatibility for non-flat-tree firmware. This doesn't
>>>> mean
>>>> keeping arch/ppc.
>>>
>>> Would it be possible to create the device tree in the kernel and
>>> then jump
>>> into the normal entry point? We need some sort of translation shim
>>> between
>>> the normal kernel and whatever oddball method firmware X chooses
>>> to hand-off
>>> to the kernel.
>>
>> Yes. This was suggested numerous number of times. Kumar, for some
>> reason which I don't understand, keeps ignoring this.
>>
>> And yes, I think person who breaks compatibility is the one who
>> should
>> be doing this work :).
>
> I think there's some confusion here (at least, I'm confused), so let
> me see if I have this right:
>
> 1) Kumar is advocating the eventual removal of support for booting
> the 85xx CDS and 85xx ADS boards without a flat-device tree
>
> 2) Eugene and Dan say this will break systems that are already
> deployed
>
> 3) Kumar says that the 85xx CDS and ADS systems are reference
> platforms, and therefore not meant for deployment.
I'd say production instead of deployment.
> 4) Eugene implies that removal of 85xx CDS and ADS support from arch/
> ppc should be accompanied by some sort of compatibility options for
> booting arch/powerpc Linux from an old u-boot
>
> Do I have this right?
>
> Oh, and 5) Kumar implies that anyone who buys a repackaged CDS system
> is a sucker, and should be parted from his or her money with all
> possible speed. :)
(as a production system).
I think everything else is correct.
- kumar
^ permalink raw reply
* Re: 85xx FDT updates?
From: Kumar Gala @ 2006-04-25 19:20 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20060425185314.GC1132@gate.ebshome.net>
On Apr 25, 2006, at 1:53 PM, Eugene Surovegin wrote:
> On Tue, Apr 25, 2006 at 01:33:38PM -0500, Kumar Gala wrote:
>> I personally dont have any time or interesting in it.
>
> So, don't break compatibility if you don't have time/interest to fix
> it. We can wait till someone who "wants to move forward" can do this
> professionally without screwing everybody else.
If I break compatibility for boards I maintain I don't see the issue
as long as I provide a workable solution.
- kumar
^ permalink raw reply
* Re: 85xx FDT updates?
From: Andy Fleming @ 2006-04-25 19:14 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20060425184857.GB1132@gate.ebshome.net>
On Apr 25, 2006, at 13:48, Eugene Surovegin wrote:
> On Tue, Apr 25, 2006 at 01:29:34PM -0500, Brent Cook wrote:
>>> ....
>>> Providing compatibility for non-flat-tree firmware. This doesn't
>>> mean
>>> keeping arch/ppc.
>>
>> Would it be possible to create the device tree in the kernel and
>> then jump
>> into the normal entry point? We need some sort of translation shim
>> between
>> the normal kernel and whatever oddball method firmware X chooses
>> to hand-off
>> to the kernel.
>
> Yes. This was suggested numerous number of times. Kumar, for some
> reason which I don't understand, keeps ignoring this.
>
> And yes, I think person who breaks compatibility is the one who should
> be doing this work :).
I think there's some confusion here (at least, I'm confused), so let
me see if I have this right:
1) Kumar is advocating the eventual removal of support for booting
the 85xx CDS and 85xx ADS boards without a flat-device tree
2) Eugene and Dan say this will break systems that are already deployed
3) Kumar says that the 85xx CDS and ADS systems are reference
platforms, and therefore not meant for deployment.
4) Eugene implies that removal of 85xx CDS and ADS support from arch/
ppc should be accompanied by some sort of compatibility options for
booting arch/powerpc Linux from an old u-boot
Do I have this right?
Oh, and 5) Kumar implies that anyone who buys a repackaged CDS system
is a sucker, and should be parted from his or her money with all
possible speed. :)
Andy Fleming
^ permalink raw reply
* Re: 85xx FDT updates?
From: Eugene Surovegin @ 2006-04-25 18:53 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <248CD1B3-A33B-47F5-AFE8-F7C9DDCD1D0B@kernel.crashing.org>
On Tue, Apr 25, 2006 at 01:33:38PM -0500, Kumar Gala wrote:
> I personally dont have any time or interesting in it.
So, don't break compatibility if you don't have time/interest to fix
it. We can wait till someone who "wants to move forward" can do this
professionally without screwing everybody else.
--
Eugene
^ permalink raw reply
* Re: 85xx FDT updates?
From: Eugene Surovegin @ 2006-04-25 18:48 UTC (permalink / raw)
To: Brent Cook; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <200604251329.35584.bcook@bpointsys.com>
On Tue, Apr 25, 2006 at 01:29:34PM -0500, Brent Cook wrote:
> On Tuesday 25 April 2006 13:24, Eugene Surovegin wrote:
> > On Tue, Apr 25, 2006 at 01:14:55PM -0500, Kumar Gala wrote:
> > > >What you will end up with is that that small amount of embedded people
> > > >who bother to contribute something back will stop doing this. We are
> > > >more than capable of maintaining our internal kernel trees :).
> > >
> > > I'm not sure what to say to this. Things need to move forward at
> > > some point.
> >
> > I don't see how removing features and breaking compatibility with
> > almost _all_ current embedded PPC boards boards is "moving forward".
> > Enlighten me, please.
> >
> > > I still not clear as to what exactly you are advocating
> > > beyond that we should keep the arch/ppc code around for ever.
> >
> > Providing compatibility for non-flat-tree firmware. This doesn't mean
> > keeping arch/ppc.
>
> Would it be possible to create the device tree in the kernel and then jump
> into the normal entry point? We need some sort of translation shim between
> the normal kernel and whatever oddball method firmware X chooses to hand-off
> to the kernel.
Yes. This was suggested numerous number of times. Kumar, for some
reason which I don't understand, keeps ignoring this.
And yes, I think person who breaks compatibility is the one who should
be doing this work :).
--
^ permalink raw reply
* Re: 85xx FDT updates?
From: Kumar Gala @ 2006-04-25 18:33 UTC (permalink / raw)
To: Brent Cook; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <200604251329.35584.bcook@bpointsys.com>
On Apr 25, 2006, at 1:29 PM, Brent Cook wrote:
> On Tuesday 25 April 2006 13:24, Eugene Surovegin wrote:
>> On Tue, Apr 25, 2006 at 01:14:55PM -0500, Kumar Gala wrote:
>>>> What you will end up with is that that small amount of embedded
>>>> people
>>>> who bother to contribute something back will stop doing this. We
>>>> are
>>>> more than capable of maintaining our internal kernel trees :).
>>>
>>> I'm not sure what to say to this. Things need to move forward at
>>> some point.
>>
>> I don't see how removing features and breaking compatibility with
>> almost _all_ current embedded PPC boards boards is "moving forward".
>> Enlighten me, please.
>>
>>> I still not clear as to what exactly you are advocating
>>> beyond that we should keep the arch/ppc code around for ever.
>>
>> Providing compatibility for non-flat-tree firmware. This doesn't mean
>> keeping arch/ppc.
>
> Would it be possible to create the device tree in the kernel and
> then jump
> into the normal entry point? We need some sort of translation shim
> between
> the normal kernel and whatever oddball method firmware X chooses to
> hand-off
> to the kernel.
Agreed, that would be nice. I would love for someone to create such
a thing. I personally dont have any time or interesting in it.
- kumar
^ permalink raw reply
* Re: 85xx FDT updates?
From: Kumar Gala @ 2006-04-25 18:31 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20060425182418.GA1132@gate.ebshome.net>
On Apr 25, 2006, at 1:24 PM, Eugene Surovegin wrote:
> On Tue, Apr 25, 2006 at 01:14:55PM -0500, Kumar Gala wrote:
>>
>>> What you will end up with is that that small amount of embedded
>>> people
>>> who bother to contribute something back will stop doing this. We are
>>> more than capable of maintaining our internal kernel trees :).
>>
>> I'm not sure what to say to this. Things need to move forward at
>> some point.
>
> I don't see how removing features and breaking compatibility with
> almost _all_ current embedded PPC boards boards is "moving forward".
> Enlighten me, please.
I'm not talking about all embedded PPC boards. I'm taking about the
subset that exists for 85xx. Also, its moving forward as the
standard way of booting future systems.
>> I still not clear as to what exactly you are advocating
>> beyond that we should keep the arch/ppc code around for ever.
>
> Providing compatibility for non-flat-tree firmware. This doesn't mean
> keeping arch/ppc.
And how do you suggest we do this? My argument is for the boards I'm
talking about updating u-boot is the easiest and most straight
forward solution. I'm not advocating this at the right solution for
all boards.
- kumar
^ permalink raw reply
* Re: 85xx FDT updates?
From: Brent Cook @ 2006-04-25 18:29 UTC (permalink / raw)
To: Kumar Gala, Dan Malek, linuxppc-dev@ozlabs.org
In-Reply-To: <20060425182418.GA1132@gate.ebshome.net>
On Tuesday 25 April 2006 13:24, Eugene Surovegin wrote:
> On Tue, Apr 25, 2006 at 01:14:55PM -0500, Kumar Gala wrote:
> > >What you will end up with is that that small amount of embedded people
> > >who bother to contribute something back will stop doing this. We are
> > >more than capable of maintaining our internal kernel trees :).
> >
> > I'm not sure what to say to this. Things need to move forward at
> > some point.
>
> I don't see how removing features and breaking compatibility with
> almost _all_ current embedded PPC boards boards is "moving forward".
> Enlighten me, please.
>
> > I still not clear as to what exactly you are advocating
> > beyond that we should keep the arch/ppc code around for ever.
>
> Providing compatibility for non-flat-tree firmware. This doesn't mean
> keeping arch/ppc.
Would it be possible to create the device tree in the kernel and then jump
into the normal entry point? We need some sort of translation shim between
the normal kernel and whatever oddball method firmware X chooses to hand-off
to the kernel.
^ permalink raw reply
* Re: 85xx FDT updates?
From: Eugene Surovegin @ 2006-04-25 18:24 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <265F73F8-F641-4EDD-B88F-A2B2F7FA1308@kernel.crashing.org>
On Tue, Apr 25, 2006 at 01:14:55PM -0500, Kumar Gala wrote:
>
> >What you will end up with is that that small amount of embedded people
> >who bother to contribute something back will stop doing this. We are
> >more than capable of maintaining our internal kernel trees :).
>
> I'm not sure what to say to this. Things need to move forward at
> some point.
I don't see how removing features and breaking compatibility with
almost _all_ current embedded PPC boards boards is "moving forward".
Enlighten me, please.
> I still not clear as to what exactly you are advocating
> beyond that we should keep the arch/ppc code around for ever.
Providing compatibility for non-flat-tree firmware. This doesn't mean
keeping arch/ppc.
--
Eugene
^ permalink raw reply
* Re: 85xx FDT updates?
From: Kumar Gala @ 2006-04-25 18:14 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20060425180119.GF20228@gate.ebshome.net>
On Apr 25, 2006, at 1:01 PM, Eugene Surovegin wrote:
> On Tue, Apr 25, 2006 at 12:39:45PM -0500, Kumar Gala wrote:
>>> Kumar, you are missing our point. Let's say I packaged Motorola eval
>>> board and sold it as my product. So, you have this board in the tree
>>> but I cannot update firmware on this board. What you suggest I
>>> have to
>>> do so my customer can run new kernel on it? Recall the board or fly
>>> to the customer site with Abatron? This is just ridiculous.
>>
>> If you are doing this, you should have someone for your customers to
>> update the firmware.
>
> Wow, I want to live in that world you seem to be living. I rest my
> case.
s/someone/someway/
>> What happens when Freescale finds an errata that requires a new
> firmware image?
>
> I find a way to handle it in the kernel. So far, I was quite
> successful in doing this for 440 (I just sent a patch for one of such
> erratum upstream).
This may be true for the errata on the 440, however I can envision
DDR performance tweaks which are not as ease to implement in the
kernel w/o reproducing the work of the firmware.
>> I understand the point for a custom solution, however I think make
>> the same claim for a reference board is silly, until someone can show
>> me a real case in which its not feasible to update the firmware.
>
> I can imagine doing this for CDS for example.
>
> Kumar, you seem to insist that it's easy to update firmware in field,
> it's not. I've been doing this stuff for many years, Dan - probably
> for decades, but you refuse to listen.
I believe you with regards to custom boards, however I dont feel the
same is true for reference boards. I'm in the same boat as you with
regards to building a product. But, I see the intent and usage of a
reference board from Freescale, IBM, or AMCC as a completely
different usage model. If you know of someone that is buttoning up a
reference board from one of these guys let me know. I've got some
bridges I can sell the guy as well.
> What you will end up with is that that small amount of embedded people
> who bother to contribute something back will stop doing this. We are
> more than capable of maintaining our internal kernel trees :).
I'm not sure what to say to this. Things need to move forward at
some point. I still not clear as to what exactly you are advocating
beyond that we should keep the arch/ppc code around for ever.
- kumar
^ permalink raw reply
* Re: 85xx FDT updates?
From: Eugene Surovegin @ 2006-04-25 18:01 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <BEC38EF6-326E-4ED1-8F02-4A3FA928908F@kernel.crashing.org>
On Tue, Apr 25, 2006 at 12:39:45PM -0500, Kumar Gala wrote:
> >Kumar, you are missing our point. Let's say I packaged Motorola eval
> >board and sold it as my product. So, you have this board in the tree
> >but I cannot update firmware on this board. What you suggest I have to
> >do so my customer can run new kernel on it? Recall the board or fly
> >to the customer site with Abatron? This is just ridiculous.
>
> If you are doing this, you should have someone for your customers to
> update the firmware.
Wow, I want to live in that world you seem to be living. I rest my
case.
> What happens when Freescale finds an errata that requires a new
firmware image?
I find a way to handle it in the kernel. So far, I was quite
successful in doing this for 440 (I just sent a patch for one of such
erratum upstream).
> I understand the point for a custom solution, however I think make
> the same claim for a reference board is silly, until someone can show
> me a real case in which its not feasible to update the firmware.
I can imagine doing this for CDS for example.
Kumar, you seem to insist that it's easy to update firmware in field,
it's not. I've been doing this stuff for many years, Dan - probably
for decades, but you refuse to listen.
What you will end up with is that that small amount of embedded people
who bother to contribute something back will stop doing this. We are
more than capable of maintaining our internal kernel trees :).
--
Eugene
^ permalink raw reply
* Re: 85xx FDT updates?
From: Kumar Gala @ 2006-04-25 17:39 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20060425170857.GE20228@gate.ebshome.net>
On Apr 25, 2006, at 12:08 PM, Eugene Surovegin wrote:
> On Tue, Apr 25, 2006 at 11:55:49AM -0500, Kumar Gala wrote:
>>
>> On Apr 25, 2006, at 11:49 AM, Dan Malek wrote:
>>
>>>
>>> On Apr 25, 2006, at 3:49 AM, Eugene Surovegin wrote:
>>>
>>>> It seems some people here lost touch with reality - embedded
>>>> Linux is
>>>> mostly run on custom hardware, not on evaluation boards.
>>>
>>> This is the reason I usually mention such things. While we all
>>> want to see the new features, we have to be sensitive to the
>>> real world product deployment of Linux. While your world
>>> may be a few evaluation boards that allow you to update
>>> software many times a day, the real world products can't
>>> afford to do that. From my own experience, I can tell you
>>> that none of the deployed systems I've worked on will
>>> ever update U-Boot. They consider this a sacred piece of
>>> software such that is all else fails they can recover a
>>> system remotely using U-Boot commands. They won't
>>> risk updating U-Boot in case it fails. Making Linux dependent
>>> on a particular, updated, version of U-Boot just isn't going
>>> to work in most deployed systems. Or worse, making
>>> Linux dependent on U-Boot isn't necessarily popular
>>> either. For various reasons, especially when replacing
>>> legacy software, some custom boot rom is often the
>>> only choice.
>>
>> I understand this, however these systems are not in the kernel tree
>> and thus we can only do so much for them. I agree a shim between a
>> non-flat dev tree aware u-boot and kernel would be a good thing.
>> However, I don't see that as something I have to produce as a board
>> maintainer if I can give you and updated u-boot to use.
>
> Kumar, you are missing our point. Let's say I packaged Motorola eval
> board and sold it as my product. So, you have this board in the tree
> but I cannot update firmware on this board. What you suggest I have to
> do so my customer can run new kernel on it? Recall the board or fly
> to the customer site with Abatron? This is just ridiculous.
If you are doing this, you should have someone for your customers to
update the firmware. What happens when Freescale finds an errata
that requires a new firmware image?
I understand the point for a custom solution, however I think make
the same claim for a reference board is silly, until someone can show
me a real case in which its not feasible to update the firmware.
- kumar
^ permalink raw reply
* Re: 85xx FDT updates?
From: Eugene Surovegin @ 2006-04-25 17:08 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <853005AF-8F43-454D-80E6-F39308F89A47@kernel.crashing.org>
On Tue, Apr 25, 2006 at 11:55:49AM -0500, Kumar Gala wrote:
>
> On Apr 25, 2006, at 11:49 AM, Dan Malek wrote:
>
> >
> >On Apr 25, 2006, at 3:49 AM, Eugene Surovegin wrote:
> >
> >>It seems some people here lost touch with reality - embedded Linux is
> >>mostly run on custom hardware, not on evaluation boards.
> >
> >This is the reason I usually mention such things. While we all
> >want to see the new features, we have to be sensitive to the
> >real world product deployment of Linux. While your world
> >may be a few evaluation boards that allow you to update
> >software many times a day, the real world products can't
> >afford to do that. From my own experience, I can tell you
> >that none of the deployed systems I've worked on will
> >ever update U-Boot. They consider this a sacred piece of
> >software such that is all else fails they can recover a
> >system remotely using U-Boot commands. They won't
> >risk updating U-Boot in case it fails. Making Linux dependent
> >on a particular, updated, version of U-Boot just isn't going
> >to work in most deployed systems. Or worse, making
> >Linux dependent on U-Boot isn't necessarily popular
> >either. For various reasons, especially when replacing
> >legacy software, some custom boot rom is often the
> >only choice.
>
> I understand this, however these systems are not in the kernel tree
> and thus we can only do so much for them. I agree a shim between a
> non-flat dev tree aware u-boot and kernel would be a good thing.
> However, I don't see that as something I have to produce as a board
> maintainer if I can give you and updated u-boot to use.
Kumar, you are missing our point. Let's say I packaged Motorola eval
board and sold it as my product. So, you have this board in the tree
but I cannot update firmware on this board. What you suggest I have to
do so my customer can run new kernel on it? Recall the board or fly
to the customer site with Abatron? This is just ridiculous.
--
Eugene
^ permalink raw reply
* Re: [PATCH] fix cpm_uart driver for PQ1...
From: Vitaly Bordug @ 2006-04-25 16:57 UTC (permalink / raw)
To: David Jander; +Cc: linuxppc-embedded
In-Reply-To: <200604251155.50781.david.jander@protonic.nl>
David,
Sorry haven't noticed you submit once working on series.
>
> Hi,
>
> This patch fixes the following three problems:
>
> 1. Memory mapping virtual<-->dma is broken in the case that
> CONFIG_CONSISTENT_START > CPM_ADDR.
Due to broken address translation, I used Kenneth work as a base. I'd
appreciate if you take a look/comment (CPM_UART: Fixed odd address
translations). Mostly it did the same as your patch/Kenneth work (so I
think it will be fair enough to put your both signed-off lines in there
as well - just let me know you do not object).
>
> 2. SCC uart sends a break sequence each time it is stopped with the
> CPM_CR_STOP_TX command. That means that each time an application closes the
> serial device, a break is transmitted.
Can you please rebase it with my series applied? I'll submit it as incremental to my series then.
I am maintaining this part, and trying to make it better :).
>
> 3. Implemented default BRG routing for PQ1 (in the same sense as it is done
> for PQ2).
All ioport things are board-specific and should reside in BSP code (I'm pretty sure nobody will object...) - the BSP patch has examples how to do that. Though the legacy behavior it retaining,
I claim it as "no longer supported " and encourage board port owners to do minor changes in board-specific code and have cpm_uart operate on platform-device basis.
>
> Signed-off-by: David Jander
>
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: 85xx FDT updates?
From: Kumar Gala @ 2006-04-25 16:55 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <66B13296-80E8-4C9E-803D-F4E3D7AABB25@embeddedalley.com>
On Apr 25, 2006, at 11:49 AM, Dan Malek wrote:
>
> On Apr 25, 2006, at 3:49 AM, Eugene Surovegin wrote:
>
>> It seems some people here lost touch with reality - embedded Linux is
>> mostly run on custom hardware, not on evaluation boards.
>
> This is the reason I usually mention such things. While we all
> want to see the new features, we have to be sensitive to the
> real world product deployment of Linux. While your world
> may be a few evaluation boards that allow you to update
> software many times a day, the real world products can't
> afford to do that. From my own experience, I can tell you
> that none of the deployed systems I've worked on will
> ever update U-Boot. They consider this a sacred piece of
> software such that is all else fails they can recover a
> system remotely using U-Boot commands. They won't
> risk updating U-Boot in case it fails. Making Linux dependent
> on a particular, updated, version of U-Boot just isn't going
> to work in most deployed systems. Or worse, making
> Linux dependent on U-Boot isn't necessarily popular
> either. For various reasons, especially when replacing
> legacy software, some custom boot rom is often the
> only choice.
I understand this, however these systems are not in the kernel tree
and thus we can only do so much for them. I agree a shim between a
non-flat dev tree aware u-boot and kernel would be a good thing.
However, I don't see that as something I have to produce as a board
maintainer if I can give you and updated u-boot to use.
- kumar
^ permalink raw reply
* Re: 85xx FDT updates?
From: Kumar Gala @ 2006-04-25 16:51 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-dev@ozlabs.org list, Paul Mackerras
In-Reply-To: <20060425163118.GD20228@gate.ebshome.net>
On Apr 25, 2006, at 11:31 AM, Eugene Surovegin wrote:
> On Tue, Apr 25, 2006 at 11:25:59AM -0500, Kumar Gala wrote:
>> If we are talking about a reference board than I think this is an
>> absurd requirement. If you are willing to update your kernel on such
>> a board why would you not be willing to update the firmware as well.
>
> 1) I don't have JTAG
> 2) I don't trust new U-Boot version
> 3) I want to be able to boot old kernels
>
> What you are proposing is more like saying - we changed kernel
> user-space API, old applications aren't supported anymore, get the new
> libc and rebuild them all. For some reason we don't intentionally do
> this, I wonder why.
I dont think this is like the user-space API at all. The binding
between kernel and u-boot is actually pretty tight. For certain
config options you have to ensure that u-boot and the kernel agree
(for example CONFIG_CPM2).
If you dont trust the new u-boot I dont know why you would trust the
new kernel anymore. Also, I find it difficult to believe people
would not be willing to update a u-boot to get any bug or performance
tweaks that might exist after the initial release that came on their
board.
You can boot old kernels with the new u-boot if you want to.
- kumar
^ permalink raw reply
* Re: 85xx FDT updates?
From: Dan Malek @ 2006-04-25 16:49 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20060425074902.GA20228@gate.ebshome.net>
On Apr 25, 2006, at 3:49 AM, Eugene Surovegin wrote:
> It seems some people here lost touch with reality - embedded Linux is
> mostly run on custom hardware, not on evaluation boards.
This is the reason I usually mention such things. While we all
want to see the new features, we have to be sensitive to the
real world product deployment of Linux. While your world
may be a few evaluation boards that allow you to update
software many times a day, the real world products can't
afford to do that. From my own experience, I can tell you
that none of the deployed systems I've worked on will
ever update U-Boot. They consider this a sacred piece of
software such that is all else fails they can recover a
system remotely using U-Boot commands. They won't
risk updating U-Boot in case it fails. Making Linux dependent
on a particular, updated, version of U-Boot just isn't going
to work in most deployed systems. Or worse, making
Linux dependent on U-Boot isn't necessarily popular
either. For various reasons, especially when replacing
legacy software, some custom boot rom is often the
only choice.
Thanks.
-- Dan
^ permalink raw reply
* Re: 85xx FDT updates?
From: Eugene Surovegin @ 2006-04-25 16:31 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org list, Paul Mackerras
In-Reply-To: <6F7CAB43-B4C0-47DA-BC7D-3FD04A552131@kernel.crashing.org>
On Tue, Apr 25, 2006 at 11:25:59AM -0500, Kumar Gala wrote:
> If we are talking about a reference board than I think this is an
> absurd requirement. If you are willing to update your kernel on such
> a board why would you not be willing to update the firmware as well.
1) I don't have JTAG
2) I don't trust new U-Boot version
3) I want to be able to boot old kernels
What you are proposing is more like saying - we changed kernel
user-space API, old applications aren't supported anymore, get the new
libc and rebuild them all. For some reason we don't intentionally do
this, I wonder why.
--
Eugene
^ permalink raw reply
* [PATCH 2/4] CPM_UART: Convert to use platform devices
From: Vitaly Bordug @ 2006-04-25 16:26 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-embedded
In-Reply-To: <20060425162633.23551.85273.stgit@vitb.ru.mvista.com>
This is intended to make the driver code more generic and flexible,
to get rid of board-specific layouts within driver, and generic rehaul,
yet keeping compatibility with the existing stuff utilizing it, being
compatible with legacy behavior (but with complaints that legacy mode
used).
Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
---
drivers/serial/cpm_uart/cpm_uart.h | 16 +-
drivers/serial/cpm_uart/cpm_uart_core.c | 259 +++++++++++++++++++++++++------
drivers/serial/cpm_uart/cpm_uart_cpm1.c | 47 ------
drivers/serial/cpm_uart/cpm_uart_cpm2.c | 9 -
4 files changed, 220 insertions(+), 111 deletions(-)
diff --git a/drivers/serial/cpm_uart/cpm_uart.h b/drivers/serial/cpm_uart/cpm_uart.h
index 73c8a08..17f2c7a 100644
--- a/drivers/serial/cpm_uart/cpm_uart.h
+++ b/drivers/serial/cpm_uart/cpm_uart.h
@@ -10,6 +10,8 @@
#define CPM_UART_H
#include <linux/config.h>
+#include <linux/platform_device.h>
+#include <linux/fs_uart_pd.h>
#if defined(CONFIG_CPM2)
#include "cpm_uart_cpm2.h"
@@ -26,14 +28,14 @@
#define FLAG_SMC 0x00000002
#define FLAG_CONSOLE 0x00000001
-#define UART_SMC1 0
-#define UART_SMC2 1
-#define UART_SCC1 2
-#define UART_SCC2 3
-#define UART_SCC3 4
-#define UART_SCC4 5
+#define UART_SMC1 fsid_smc1_uart
+#define UART_SMC2 fsid_smc2_uart
+#define UART_SCC1 fsid_scc1_uart
+#define UART_SCC2 fsid_scc2_uart
+#define UART_SCC3 fsid_scc3_uart
+#define UART_SCC4 fsid_scc4_uart
-#define UART_NR 6
+#define UART_NR fs_uart_nr
#define RX_NUM_FIFO 4
#define RX_BUF_SIZE 32
diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c b/drivers/serial/cpm_uart/cpm_uart_core.c
index b7bf4c6..8f33815 100644
--- a/drivers/serial/cpm_uart/cpm_uart_core.c
+++ b/drivers/serial/cpm_uart/cpm_uart_core.c
@@ -41,6 +41,7 @@
#include <linux/device.h>
#include <linux/bootmem.h>
#include <linux/dma-mapping.h>
+#include <linux/fs_uart_pd.h>
#include <asm/io.h>
#include <asm/irq.h>
@@ -60,7 +61,7 @@
/* Track which ports are configured as uarts */
int cpm_uart_port_map[UART_NR];
/* How many ports did we config as uarts */
-int cpm_uart_nr;
+int cpm_uart_nr = 0;
/**************************************************************/
@@ -85,6 +86,37 @@ static inline void *cpm2cpu_addr(unsigne
return bus_to_virt(addr);
}
+/* Place-holder for board-specific stuff */
+struct platform_device* __attribute__ ((weak)) __init
+early_uart_get_pdev(int index)
+{
+ return NULL;
+}
+
+
+void cpm_uart_count(void)
+{
+ cpm_uart_nr = 0;
+#ifdef CONFIG_SERIAL_CPM_SMC1
+ cpm_uart_port_map[cpm_uart_nr++] = UART_SMC1;
+#endif
+#ifdef CONFIG_SERIAL_CPM_SMC2
+ cpm_uart_port_map[cpm_uart_nr++] = UART_SMC2;
+#endif
+#ifdef CONFIG_SERIAL_CPM_SCC1
+ cpm_uart_port_map[cpm_uart_nr++] = UART_SCC1;
+#endif
+#ifdef CONFIG_SERIAL_CPM_SCC2
+ cpm_uart_port_map[cpm_uart_nr++] = UART_SCC2;
+#endif
+#ifdef CONFIG_SERIAL_CPM_SCC3
+ cpm_uart_port_map[cpm_uart_nr++] = UART_SCC3;
+#endif
+#ifdef CONFIG_SERIAL_CPM_SCC4
+ cpm_uart_port_map[cpm_uart_nr++] = UART_SCC4;
+#endif
+}
+
/*
* Check, if transmit buffers are processed
*/
@@ -829,14 +861,6 @@ static int cpm_uart_request_port(struct
if (pinfo->flags & FLAG_CONSOLE)
return 0;
- /*
- * Setup any port IO, connect any baud rate generators,
- * etc. This is expected to be handled by board
- * dependant code
- */
- if (pinfo->set_lineif)
- pinfo->set_lineif(pinfo);
-
if (IS_SMC(pinfo)) {
pinfo->smcp->smc_smcm &= ~(SMCM_RX | SMCM_TX);
pinfo->smcp->smc_smcmr &= ~(SMCMR_REN | SMCMR_TEN);
@@ -988,6 +1012,54 @@ struct uart_cpm_port cpm_uart_ports[UART
},
};
+int cpm_uart_drv_get_platform_data(struct platform_device *pdev, int is_con)
+{
+ struct resource *r;
+ struct fs_uart_platform_info *pdata = pdev->dev.platform_data;
+ int idx = pdata->fs_no; /* It is UART_SMCx or UART_SCCx index */
+ struct uart_cpm_port *pinfo;
+ int line;
+ u32 mem, pram;
+
+ for (line=0; line<UART_NR && cpm_uart_port_map[line]!=pdata->fs_no; line++);
+
+ pinfo = (struct uart_cpm_port *) &cpm_uart_ports[idx];
+
+ pinfo->brg = pdata->brg;
+
+ if (!is_con) {
+ pinfo->port.line = line;
+ pinfo->port.flags = UPF_BOOT_AUTOCONF;
+ }
+
+ if (!(r = platform_get_resource_byname(pdev, IORESOURCE_MEM, "regs")))
+ return -EINVAL;
+ mem = r->start;
+
+ if (!(r = platform_get_resource_byname(pdev, IORESOURCE_MEM, "pram")))
+ return -EINVAL;
+ pram = r->start;
+
+ if(idx > fsid_smc2_uart) {
+ pinfo->sccp = (scc_t *)mem;
+ pinfo->sccup = (scc_uart_t *)pram;
+ } else {
+ pinfo->smcp = (smc_t *)mem;
+ pinfo->smcup = (smc_uart_t *)pram;
+ }
+ pinfo->tx_nrfifos = pdata->tx_num_fifo;
+ pinfo->tx_fifosize = pdata->tx_buf_size;
+
+ pinfo->rx_nrfifos = pdata->rx_num_fifo;
+ pinfo->rx_fifosize = pdata->rx_buf_size;
+
+ pinfo->port.uartclk = pdata->uart_clk;
+ pinfo->port.mapbase = (unsigned long)mem;
+ pinfo->port.irq = platform_get_irq(pdev, 0);
+
+ return 0;
+}
+
#ifdef CONFIG_SERIAL_CPM_CONSOLE
/*
* Print a string to the serial port trying not to disturb
@@ -1067,9 +1139,7 @@ static void cpm_uart_console_write(struc
pinfo->tx_cur = (volatile cbd_t *) bdp;
}
-/*
- * Setup console. Be careful is called early !
- */
+
static int __init cpm_uart_console_setup(struct console *co, char *options)
{
struct uart_port *port;
@@ -1080,9 +1150,27 @@ static int __init cpm_uart_console_setup
int flow = 'n';
int ret;
+ struct fs_uart_platform_info *pdata;
+ struct platform_device* pdev = early_uart_get_pdev(co->index);
+
port =
(struct uart_port *)&cpm_uart_ports[cpm_uart_port_map[co->index]];
pinfo = (struct uart_cpm_port *)port;
+ if (!pdev) {
+ pr_info("cpm_uart: console: compat mode\n");
+ /* compatibility - will be cleaned up */
+ cpm_uart_init_portdesc();
+
+ if (pinfo->set_lineif)
+ pinfo->set_lineif(pinfo);
+ } else {
+ pdata = pdev->dev.platform_data;
+ if (pdata)
+ if (pdata->init_ioports)
+ pdata->init_ioports();
+
+ cpm_uart_drv_get_platform_data(pdev, 1);
+ }
pinfo->flags |= FLAG_CONSOLE;
@@ -1097,14 +1185,6 @@ static int __init cpm_uart_console_setup
baud = 9600;
}
- /*
- * Setup any port IO, connect any baud rate generators,
- * etc. This is expected to be handled by board
- * dependant code
- */
- if (pinfo->set_lineif)
- pinfo->set_lineif(pinfo);
-
if (IS_SMC(pinfo)) {
pinfo->smcp->smc_smcm &= ~(SMCM_RX | SMCM_TX);
pinfo->smcp->smc_smcmr &= ~(SMCMR_REN | SMCMR_TEN);
@@ -1143,11 +1223,8 @@ static struct console cpm_scc_uart_conso
int __init cpm_uart_console_init(void)
{
- int ret = cpm_uart_init_portdesc();
-
- if (!ret)
- register_console(&cpm_scc_uart_console);
- return ret;
+ register_console(&cpm_scc_uart_console);
+ return 0;
}
console_initcall(cpm_uart_console_init);
@@ -1165,44 +1242,130 @@ static struct uart_driver cpm_reg = {
.minor = SERIAL_CPM_MINOR,
.cons = CPM_UART_CONSOLE,
};
-
-static int __init cpm_uart_init(void)
+static int cpm_uart_drv_probe(struct device *dev)
{
- int ret, i;
+ struct platform_device *pdev = to_platform_device(dev);
+ struct fs_uart_platform_info *pdata;
+ int ret = -ENODEV;
- printk(KERN_INFO "Serial: CPM driver $Revision: 0.01 $\n");
-
-#ifndef CONFIG_SERIAL_CPM_CONSOLE
- ret = cpm_uart_init_portdesc();
- if (ret)
+ if(!pdev) {
+ printk(KERN_ERR"CPM UART: platform data missing!\n");
return ret;
-#endif
+ }
- cpm_reg.nr = cpm_uart_nr;
- ret = uart_register_driver(&cpm_reg);
+ pdata = pdev->dev.platform_data;
+ pr_debug("cpm_uart_drv_probe: Adding CPM UART %d\n",
+ cpm_uart_port_map[pdata->fs_no]);
- if (ret)
+ if ((ret = cpm_uart_drv_get_platform_data(pdev, 0)))
return ret;
- for (i = 0; i < cpm_uart_nr; i++) {
- int con = cpm_uart_port_map[i];
- cpm_uart_ports[con].port.line = i;
- cpm_uart_ports[con].port.flags = UPF_BOOT_AUTOCONF;
- uart_add_one_port(&cpm_reg, &cpm_uart_ports[con].port);
- }
+ if (pdata->init_ioports)
+ pdata->init_ioports();
+
+ ret = uart_add_one_port(&cpm_reg, &cpm_uart_ports[pdata->fs_no].port);
- return ret;
+ return ret;
}
-static void __exit cpm_uart_exit(void)
+static int cpm_uart_drv_remove(struct device *dev)
{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct fs_uart_platform_info *pdata = pdev->dev.platform_data;
+
+ pr_debug("cpm_uart_drv_remove: Removing CPM UART %d\n",
+ cpm_uart_port_map[pdata->fs_no]);
+
+ uart_remove_one_port(&cpm_reg, &cpm_uart_ports[pdata->fs_no].port);
+ return 0;
+}
+
+static struct device_driver cpm_smc_uart_driver = {
+ .name = "fsl-cpm-smc:uart",
+ .bus = &platform_bus_type,
+ .probe = cpm_uart_drv_probe,
+ .remove = cpm_uart_drv_remove,
+};
+
+static struct device_driver cpm_scc_uart_driver = {
+ .name = "fsl-cpm-scc:uart",
+ .bus = &platform_bus_type,
+ .probe = cpm_uart_drv_probe,
+ .remove = cpm_uart_drv_remove,
+};
+
+/*
+ This is supposed to match uart devices on platform bus,
+ */
+static int match_is_uart (struct device* dev, void* data)
+{
+ struct platform_device* pdev = container_of(dev, struct platform_device, dev);
+ int ret = 0;
+ /* this was setfunc as uart */
+ if(strstr(pdev->name,":uart")) {
+ ret = 1;
+ }
+ return ret;
+}
+
+
+static int cpm_uart_init(void) {
+
+ int ret;
int i;
+ struct device *dev;
+ printk(KERN_INFO "Serial: CPM driver $Revision: 0.02 $\n");
+
+ /* lookup the bus for uart devices */
+ dev = bus_find_device(&platform_bus_type, NULL, 0, match_is_uart);
+
+ /* There are devices on the bus - all should be OK */
+ if (dev) {
+ cpm_uart_count();
+ cpm_reg.nr = cpm_uart_nr;
+
+ if (!(ret = uart_register_driver(&cpm_reg))) {
+ if ((ret = driver_register(&cpm_smc_uart_driver))) {
+ uart_unregister_driver(&cpm_reg);
+ return ret;
+ }
+ if ((ret = driver_register(&cpm_scc_uart_driver))) {
+ driver_unregister(&cpm_scc_uart_driver);
+ uart_unregister_driver(&cpm_reg);
+ }
+ }
+ } else {
+ /* No capable platform devices found - falling back to legacy mode */
+ pr_info("cpm_uart: WARNING: no UART devices found on platform bus!\n");
+ pr_info(
+ "cpm_uart: the driver will guess configuration, but this mode is no longer supported.\n");
+#ifndef CONFIG_SERIAL_CPM_CONSOLE
+ ret = cpm_uart_init_portdesc();
+ if (ret)
+ return ret;
+#endif
+
+ cpm_reg.nr = cpm_uart_nr;
+ ret = uart_register_driver(&cpm_reg);
+
+ if (ret)
+ return ret;
+
+ for (i = 0; i < cpm_uart_nr; i++) {
+ int con = cpm_uart_port_map[i];
+ cpm_uart_ports[con].port.line = i;
+ cpm_uart_ports[con].port.flags = UPF_BOOT_AUTOCONF;
+ uart_add_one_port(&cpm_reg, &cpm_uart_ports[con].port);
+ }
- for (i = 0; i < cpm_uart_nr; i++) {
- int con = cpm_uart_port_map[i];
- uart_remove_one_port(&cpm_reg, &cpm_uart_ports[con].port);
}
+ return ret;
+}
+static void __exit cpm_uart_exit(void)
+{
+ driver_unregister(&cpm_scc_uart_driver);
+ driver_unregister(&cpm_smc_uart_driver);
uart_unregister_driver(&cpm_reg);
}
diff --git a/drivers/serial/cpm_uart/cpm_uart_cpm1.c b/drivers/serial/cpm_uart/cpm_uart_cpm1.c
index d789ee5..31223aa 100644
--- a/drivers/serial/cpm_uart/cpm_uart_cpm1.c
+++ b/drivers/serial/cpm_uart/cpm_uart_cpm1.c
@@ -81,58 +81,11 @@ void cpm_line_cr_cmd(int line, int cmd)
void smc1_lineif(struct uart_cpm_port *pinfo)
{
- volatile cpm8xx_t *cp = cpmp;
-
- (void)cp; /* fix warning */
-#if defined (CONFIG_MPC885ADS)
- /* Enable SMC1 transceivers */
- {
- cp->cp_pepar |= 0x000000c0;
- cp->cp_pedir &= ~0x000000c0;
- cp->cp_peso &= ~0x00000040;
- cp->cp_peso |= 0x00000080;
- }
-#elif defined (CONFIG_MPC86XADS)
- unsigned int iobits = 0x000000c0;
-
- if (!pinfo->is_portb) {
- cp->cp_pbpar |= iobits;
- cp->cp_pbdir &= ~iobits;
- cp->cp_pbodr &= ~iobits;
- } else {
- ((immap_t *)IMAP_ADDR)->im_ioport.iop_papar |= iobits;
- ((immap_t *)IMAP_ADDR)->im_ioport.iop_padir &= ~iobits;
- ((immap_t *)IMAP_ADDR)->im_ioport.iop_paodr &= ~iobits;
- }
-#endif
pinfo->brg = 1;
}
void smc2_lineif(struct uart_cpm_port *pinfo)
{
- volatile cpm8xx_t *cp = cpmp;
-
- (void)cp; /* fix warning */
-#if defined (CONFIG_MPC885ADS)
- cp->cp_pepar |= 0x00000c00;
- cp->cp_pedir &= ~0x00000c00;
- cp->cp_peso &= ~0x00000400;
- cp->cp_peso |= 0x00000800;
-#elif defined (CONFIG_MPC86XADS)
- unsigned int iobits = 0x00000c00;
-
- if (!pinfo->is_portb) {
- cp->cp_pbpar |= iobits;
- cp->cp_pbdir &= ~iobits;
- cp->cp_pbodr &= ~iobits;
- } else {
- ((immap_t *)IMAP_ADDR)->im_ioport.iop_papar |= iobits;
- ((immap_t *)IMAP_ADDR)->im_ioport.iop_padir &= ~iobits;
- ((immap_t *)IMAP_ADDR)->im_ioport.iop_paodr &= ~iobits;
- }
-
-#endif
-
pinfo->brg = 2;
}
diff --git a/drivers/serial/cpm_uart/cpm_uart_cpm2.c b/drivers/serial/cpm_uart/cpm_uart_cpm2.c
index fd9e53e..c9c3b1d 100644
--- a/drivers/serial/cpm_uart/cpm_uart_cpm2.c
+++ b/drivers/serial/cpm_uart/cpm_uart_cpm2.c
@@ -142,14 +142,6 @@ void scc2_lineif(struct uart_cpm_port *p
* be supported in a sane fashion.
*/
#ifndef CONFIG_STX_GP3
-#ifdef CONFIG_MPC8560_ADS
- volatile iop_cpm2_t *io = &cpm2_immr->im_ioport;
- io->iop_ppard |= 0x00000018;
- io->iop_psord &= ~0x00000008; /* Rx */
- io->iop_psord &= ~0x00000010; /* Tx */
- io->iop_pdird &= ~0x00000008; /* Rx */
- io->iop_pdird |= 0x00000010; /* Tx */
-#else
volatile iop_cpm2_t *io = &cpm2_immr->im_ioport;
io->iop_pparb |= 0x008b0000;
io->iop_pdirb |= 0x00880000;
@@ -157,7 +149,6 @@ void scc2_lineif(struct uart_cpm_port *p
io->iop_pdirb &= ~0x00030000;
io->iop_psorb &= ~0x00030000;
#endif
-#endif
cpm2_immr->im_cpmux.cmx_scr &= 0xff00ffff;
cpm2_immr->im_cpmux.cmx_scr |= 0x00090000;
pinfo->brg = 2;
^ permalink raw reply related
* [PATCH 3/4] PPC32: Update board-specific code of the CPM UART users
From: Vitaly Bordug @ 2006-04-25 16:26 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-embedded
In-Reply-To: <20060425162633.23551.85273.stgit@vitb.ru.mvista.com>
This has the relevant updates/additions to the BSP code so that proper
platform_info struct well be passed to the CPM UART drivers. The changes
covered mpc866ads, mpc885ads and mpc8272ads.
Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
---
arch/ppc/platforms/mpc8272ads_setup.c | 114 +++++++++++++++++++++++++++
arch/ppc/platforms/mpc866ads_setup.c | 140 +++++++++++++++++++++++++++++++++
arch/ppc/platforms/mpc885ads_setup.c | 131 +++++++++++++++++++++++++++++++
arch/ppc/platforms/pq2ads.c | 31 +++++++
4 files changed, 415 insertions(+), 1 deletions(-)
diff --git a/arch/ppc/platforms/mpc8272ads_setup.c b/arch/ppc/platforms/mpc8272ads_setup.c
index bc9b94f..d5c8a3a 100644
--- a/arch/ppc/platforms/mpc8272ads_setup.c
+++ b/arch/ppc/platforms/mpc8272ads_setup.c
@@ -26,11 +26,35 @@
#include <asm/irq.h>
#include <asm/ppc_sys.h>
#include <asm/ppcboot.h>
+#include <linux/fs_uart_pd.h>
#include "pq2ads_pd.h"
static void init_fcc1_ioports(void);
static void init_fcc2_ioports(void);
+static void init_scc1_uart_ioports(void);
+static void init_scc4_uart_ioports(void);
+
+static struct fs_uart_platform_info mpc8272_uart_pdata[] = {
+ [fsid_scc1_uart] = {
+ .init_ioports = init_scc1_uart_ioports,
+ .fs_no = fsid_scc1_uart,
+ .brg = 1,
+ .tx_num_fifo = 4,
+ .tx_buf_size = 32,
+ .rx_num_fifo = 4,
+ .rx_buf_size = 32,
+ },
+ [fsid_scc4_uart] = {
+ .init_ioports = init_scc4_uart_ioports,
+ .fs_no = fsid_scc4_uart,
+ .brg = 4,
+ .tx_num_fifo = 4,
+ .tx_buf_size = 32,
+ .rx_num_fifo = 4,
+ .rx_buf_size = 32,
+ },
+};
static struct fs_mii_bus_info mii_bus_info = {
.method = fsmii_bitbang,
@@ -201,6 +225,55 @@ static void __init mpc8272ads_fixup_enet
}
}
+static void mpc8272ads_fixup_uart_pdata(struct platform_device *pdev,
+ int idx)
+{
+ bd_t *bd = (bd_t *) __res;
+ struct fs_uart_platform_info *pinfo;
+ int num = ARRAY_SIZE(mpc8272_uart_pdata);
+ int id = fs_uart_id_scc2fsid(idx);
+
+ /* no need to alter anything if console */
+ if ((id <= num) && (!pdev->dev.platform_data)) {
+ pinfo = &mpc8272_uart_pdata[id];
+ pinfo->uart_clk = bd->bi_intfreq;
+ pdev->dev.platform_data = pinfo;
+ }
+}
+
+static void init_scc1_uart_ioports(void)
+{
+ cpm2_map_t* immap = ioremap(CPM_MAP_ADDR, sizeof(cpm2_map_t));
+
+ /* SCC1 is only on port D */
+ setbits32(&immap->im_ioport.iop_ppard,0x00000003);
+ clrbits32(&immap->im_ioport.iop_psord,0x00000001);
+ setbits32(&immap->im_ioport.iop_psord,0x00000002);
+ clrbits32(&immap->im_ioport.iop_pdird,0x00000001);
+ setbits32(&immap->im_ioport.iop_pdird,0x00000002);
+
+ /* Wire BRG1 to SCC1 */
+ clrbits32(&immap->im_cpmux.cmx_scr,0x00ffffff);
+
+ iounmap(immap);
+}
+
+static void init_scc4_uart_ioports(void)
+{
+ cpm2_map_t* immap = ioremap(CPM_MAP_ADDR, sizeof(cpm2_map_t));
+
+ setbits32(&immap->im_ioport.iop_ppard,0x00000600);
+ clrbits32(&immap->im_ioport.iop_psord,0x00000600);
+ clrbits32(&immap->im_ioport.iop_pdird,0x00000200);
+ setbits32(&immap->im_ioport.iop_pdird,0x00000400);
+
+ /* Wire BRG4 to SCC4 */
+ clrbits32(&immap->im_cpmux.cmx_scr,0x000000ff);
+ setbits32(&immap->im_cpmux.cmx_scr,0x0000001b);
+
+ iounmap(immap);
+}
+
static int mpc8272ads_platform_notify(struct device *dev)
{
static const struct platform_notify_dev_map dev_map[] = {
@@ -209,6 +282,10 @@ static int mpc8272ads_platform_notify(st
.rtn = mpc8272ads_fixup_enet_pdata
},
{
+ .bus_id = "fsl-cpm-scc:uart",
+ .rtn = mpc
+ },
+ {
.bus_id = NULL
}
};
@@ -230,7 +307,44 @@ int __init mpc8272ads_init(void)
ppc_sys_device_enable(MPC82xx_CPM_FCC1);
ppc_sys_device_enable(MPC82xx_CPM_FCC2);
+ /* to be ready for console, let's attach pdata here */
+#ifdef CONFIG_SERIAL_CPM_SCC1
+ ppc_sys_device_setfunc(MPC82xx_CPM_SCC1, PPC_SYS_FUNC_UART);
+ ppc_sys_device_enable(MPC82xx_CPM_SCC1);
+
+#endif
+
+#ifdef CONFIG_SERIAL_CPM_SCC4
+ ppc_sys_device_setfunc(MPC82xx_CPM_SCC4, PPC_SYS_FUNC_UART);
+ ppc_sys_device_enable(MPC82xx_CPM_SCC4);
+#endif
+
+
return 0;
}
+/*
+ To prevent confusion, console selection is gross:
+ by 0 assumed SCC1 and by 1 assumed SCC4
+ */
+struct platform_device* early_uart_get_pdev(int index)
+{
+ bd_t *bd = (bd_t *) __res;
+ struct fs_uart_platform_info *pinfo;
+
+ struct platform_device* pdev = NULL;
+ if(index) { /*assume SCC4 here*/
+ pdev = &ppc_sys_platform_devices[MPC82xx_CPM_SCC4];
+ pinfo = &mpc8272<F12>_uart_pdata[1];
+ } else { /*over SCC1*/
+ pdev = &ppc_sys_platform_devices[MPC82xx_CPM_SCC1];
+ pinfo = &mpc8272_uart_pdata[0];
+ }
+
+ pinfo->uart_clk = bd->bi_intfreq;
+ pdev->dev.platform_data = pinfo;
+ ppc_sys_fixup_mem_resource(pdev, IMAP_ADDR);
+ return NULL;
+}
+
arch_initcall(mpc8272ads_init);
diff --git a/arch/ppc/platforms/mpc866ads_setup.c b/arch/ppc/platforms/mpc866ads_setup.c
index ac8fcc6..7edefa5 100644
--- a/arch/ppc/platforms/mpc866ads_setup.c
+++ b/arch/ppc/platforms/mpc866ads_setup.c
@@ -20,6 +20,7 @@
#include <linux/device.h>
#include <linux/fs_enet_pd.h>
+#include <linux/fs_uart_pd.h>
#include <linux/mii.h>
#include <asm/delay.h>
@@ -37,6 +38,11 @@
extern unsigned char __res[];
+static void setup_fec1_ioports(void);
+static void setup_scc1_ioports(void);
+static void setup_smc1_ioports(void);
+static void setup_smc2_ioports(void);
+
static struct fs_mii_bus_info fec_mii_bus_info = {
.method = fsmii_fec,
.id = 0,
@@ -79,6 +85,28 @@ static struct fs_platform_info mpc8xx_sc
.phy_irq = -1,
.bus_info = &scc_mii_bus_info,
+
+};
+
+static struct fs_uart_platform_info mpc866_uart_pdata[] = {
+ [fsid_smc1_uart] = {
+ .brg = 1,
+ .fs_no = fsid_smc1_uart,
+ .init_ioports = setup_smc1_ioports,
+ .tx_num_fifo = 4,
+ .tx_buf_size = 32,
+ .rx_num_fifo = 4,
+ .rx_buf_size = 32,
+ },
+ [fsid_smc2_uart] = {
+ .brg = 2,
+ .fs_no = fsid_smc2_uart,
+ .init_ioports = setup_smc2_ioports,
+ .tx_num_fifo = 4,
+ .tx_buf_size = 32,
+ .rx_num_fifo = 4,
+ .rx_buf_size = 32,
+ },
};
void __init board_init(void)
@@ -92,9 +120,12 @@ void __init board_init(void)
printk(KERN_CRIT "Could not remap BCSR1\n");
return;
}
+
#ifdef CONFIG_SERIAL_CPM_SMC1
cp->cp_simode &= ~(0xe0000000 >> 17); /* brg1 */
clrbits32(bcsr_io,(0x80000000 >> 7));
+ cp->cp_smc[0].smc_smcm |= (SMCM_RX | SMCM_TX);
+ cp->cp_smc[0].smc_smcmr &= ~(SMCMR_REN | SMCMR_TEN);
#else
setbits32(bcsr_io,(0x80000000 >> 7));
@@ -108,6 +139,8 @@ void __init board_init(void)
cp->cp_simode &= ~(0xe0000000 >> 1);
cp->cp_simode |= (0x20000000 >> 1); /* brg2 */
clrbits32(bcsr_io,(0x80000000 >> 13));
+ cp->cp_smc[1].smc_smcm |= (SMCM_RX | SMCM_TX);
+ cp->cp_smc[1].smc_smcmr &= ~(SMCMR_REN | SMCMR_TEN);
#else
clrbits32(bcsr_io,(0x80000000 >> 13));
cp->cp_pbpar &= ~(0x00000c00);
@@ -232,6 +265,74 @@ static void mpc866ads_fixup_scc_enet_pda
mpc866ads_fixup_enet_pdata(pdev, fsid_scc1 + pdev->id - 1);
}
+static void setup_smc1_ioports(void)
+{
+ immap_t *immap = (immap_t *) IMAP_ADDR;
+ unsigned *bcsr_io;
+ unsigned int iobits = 0x000000c0;
+
+ bcsr_io = ioremap(BCSR1, sizeof(unsigned long));
+
+ if (bcsr_io == NULL) {
+ printk(KERN_CRIT "Could not remap BCSR1\n");
+ return;
+ }
+
+ clrbits32(bcsr_io,BCSR1_RS232EN_1);
+ iounmap(bcsr_io);
+
+ setbits32(&immap->im_cpm.cp_pbpar, iobits);
+ clrbits32(&immap->im_cpm.cp_pbdir, iobits);
+ clrbits16(&immap->im_cpm.cp_pbodr, iobits);
+
+}
+
+static void setup_smc2_ioports(void)
+{
+ immap_t *immap = (immap_t *) IMAP_ADDR;
+ unsigned *bcsr_io;
+ unsigned int iobits = 0x00000c00;
+
+ bcsr_io = ioremap(BCSR1, sizeof(unsigned long));
+
+ if (bcsr_io == NULL) {
+ printk(KERN_CRIT "Could not remap BCSR1\n");
+ return;
+ }
+
+ clrbits32(bcsr_io,BCSR1_RS232EN_2);
+
+ iounmap(bcsr_io);
+
+#ifndef CONFIG_SERIAL_CPM_ALT_SMC2
+ setbits32(&immap->im_cpm.cp_pbpar, iobits);
+ clrbits32(&immap->im_cpm.cp_pbdir, iobits);
+ clrbits16(&immap->im_cpm.cp_pbodr, iobits);
+#else
+ setbits16(&immap->im_ioport.iop_papar, iobits);
+ clrbits16(&immap->im_ioport.iop_padir, iobits);
+ clrbits16(&immap->im_ioport.iop_paodr, iobits);
+#endif
+
+}
+
+static void __init mpc866ads_fixup_uart_pdata(struct platform_device *pdev,
+ int idx)
+{
+ bd_t *bd = (bd_t *) __res;
+ struct fs_uart_platform_info *pinfo;
+ int num = ARRAY_SIZE(mpc866_uart_pdata);
+
+ int id = fs_uart_id_smc2fsid(idx);
+
+ /* no need to alter anything if console */
+ if ((id <= num) && (!pdev->dev.platform_data)) {
+ pinfo = &mpc866_uart_pdata[id];
+ pinfo->uart_clk = bd->bi_intfreq;
+ pdev->dev.platform_data = pinfo;
+ }
+}
+
static int mpc866ads_platform_notify(struct device *dev)
{
static const struct platform_notify_dev_map dev_map[] = {
@@ -244,6 +345,10 @@ static int mpc866ads_platform_notify(str
.rtn = mpc866ads_fixup_scc_enet_pdata,
},
{
+ .bus_id = "fsl-cpm-smc:uart",
+ .rtn = mpc866ads_fixup_uart_pdata
+ },
+ {
.bus_id = NULL
}
};
@@ -267,7 +372,42 @@ int __init mpc866ads_init(void)
#endif
ppc_sys_device_enable(MPC8xx_CPM_FEC1);
+/* Since either of the uarts could be used as console, they need to ready */
+#ifdef CONFIG_SERIAL_CPM_SMC1
+ ppc_sys_device_enable(MPC8xx_CPM_SMC1);
+ ppc_sys_device_setfunc(MPC8xx_CPM_SMC1, PPC_SYS_FUNC_UART);
+#endif
+
+#ifdef CONFIG_SERIAL_CPM_SMCer
+ ppc_sys_device_enable(MPC8xx_CPM_SMC2);
+ ppc_sys_device_setfunc(MPC8xx_CPM_SMC2, PPC_SYS_FUNC_UART);
+#endif
+
return 0;
}
+/*
+ To prevent confusion, console selection is gross:
+ by 0 assumed SMC1 and by 1 assumed SMC2
+ */
+struct platform_device* early_uart_get_pdev(int index)
+{
+ bd_t *bd = (bd_t *) __res;
+ struct fs_uart_platform_info *pinfo;
+
+ struct platform_device* pdev = NULL;
+ if(index) { /*assume SMC2 here*/
+ pdev = &ppc_sys_platform_devices[MPC8xx_CPM_SMC2];
+ pinfo = &mpc866_uart_pdata[1];
+ } else { /*over SMC1*/
+ pdev = &ppc_sys_platform_devices[MPC8xx_CPM_SMC1];
+ pinfo = &mpc866_uart_pdata[0];
+ }
+
+ pinfo->uart_clk = bd->bi_intfreq;
+ pdev->dev.platform_data = pinfo;
+ ppc_sys_fixup_mem_resource(pdev, IMAP_ADDR);
+ return NULL;
+}
+
arch_initcall(mpc866ads_init);
diff --git a/arch/ppc/platforms/mpc885ads_setup.c b/arch/ppc/platforms/mpc885ads_setup.c
index 50a99e5..fc37aea 100644
--- a/arch/ppc/platforms/mpc885ads_setup.c
+++ b/arch/ppc/platforms/mpc885ads_setup.c
@@ -20,6 +20,7 @@
#include <linux/device.h>
#include <linux/fs_enet_pd.h>
+#include <linux/fs_uart_pd.h>
#include <linux/mii.h>
#include <asm/delay.h>
@@ -35,9 +36,32 @@
#include <asm/ppc_sys.h>
extern unsigned char __res[];
+static void setup_smc1_ioports(void);
+static void setup_smc2_ioports(void);
static void __init mpc885ads_scc_phy_init(char);
+static struct fs_uart_platform_info mpc885_uart_pdata[] = {
+ [fsid_smc1_uart] = {
+ .brg = 1,
+ .fs_no = fsid_smc1_uart,
+ .init_ioports = setup_smc1_ioports,
+ .tx_num_fifo = 4,
+ .tx_buf_size = 32,
+ .rx_num_fifo = 4,
+ .rx_buf_size = 32,
+ },
+ [fsid_smc2_uart] = {
+ .brg = 2,
+ .fs_no = fsid_smc2_uart,
+ .init_ioports = setup_smc2_ioports,
+ .tx_num_fifo = 4,
+ .tx_buf_size = 32,
+ .rx_num_fifo = 4,
+ .rx_buf_size = 32,
+ },
+};
+
static struct fs_mii_bus_info fec_mii_bus_info = {
.method = fsmii_fec,
.id = 0,
@@ -116,6 +140,8 @@ void __init board_init(void)
#ifdef CONFIG_SERIAL_CPM_SMC1
cp->cp_simode &= ~(0xe0000000 >> 17); /* brg1 */
clrbits32(bcsr_io, BCSR1_RS232EN_1);
+ cp->cp_smc[0].smc_smcm |= (SMCM_RX | SMCM_TX);
+ cp->cp_smc[0].smc_smcmr &= ~(SMCMR_REN | SMCMR_TEN);
#else
setbits32(bcsr_io,BCSR1_RS232EN_1);
cp->cp_smc[0].smc_smcmr = 0;
@@ -126,6 +152,8 @@ void __init board_init(void)
cp->cp_simode &= ~(0xe0000000 >> 1);
cp->cp_simode |= (0x20000000 >> 1); /* brg2 */
clrbits32(bcsr_io,BCSR1_RS232EN_2);
+ cp->cp_smc[1].smc_smcm |= (SMCM_RX | SMCM_TX);
+ cp->cp_smc[1].smc_smcmr &= ~(SMCMR_REN | SMCMR_TEN);
#else
setbits32(bcsr_io,BCSR1_RS232EN_2);
cp->cp_smc[1].smc_smcmr = 0;
@@ -343,6 +371,70 @@ static void mpc885ads_scc_phy_init(char
out_be32(&fecp->fec_mii_speed, 0);
}
+static void setup_smc1_ioports(void)
+{
+ immap_t *immap = (immap_t *) IMAP_ADDR;
+ unsigned *bcsr_io;
+ unsigned int iobits = 0x000000c0;
+
+ bcsr_io = ioremap(BCSR1, sizeof(unsigned long));
+
+ if (bcsr_io == NULL) {
+ printk(KERN_CRIT "Could not remap BCSR1\n");
+ return;
+ }
+ clrbits32(bcsr_io,BCSR1_RS232EN_1);
+ iounmap(bcsr_io);
+
+ setbits32(&immap->im_cpm.cp_pbpar, iobits);
+ clrbits32(&immap->im_cpm.cp_pbdir, iobits);
+ clrbits16(&immap->im_cpm.cp_pbodr, iobits);
+}
+
+static void setup_smc2_ioports(void)
+{
+ immap_t *immap = (immap_t *) IMAP_ADDR;
+ unsigned *bcsr_io;
+ unsigned int iobits = 0x00000c00;
+
+ bcsr_io = ioremap(BCSR1, sizeof(unsigned long));
+
+ if (bcsr_io == NULL) {
+ printk(KERN_CRIT "Could not remap BCSR1\n");
+ return;
+ }
+ clrbits32(bcsr_io,BCSR1_RS232EN_2);
+ iounmap(bcsr_io);
+
+#ifndef CONFIG_SERIAL_CPM_ALT_SMC2
+ setbits32(&immap->im_cpm.cp_pbpar, iobits);
+ clrbits32(&immap->im_cpm.cp_pbdir, iobits);
+ clrbits16(&immap->im_cpm.cp_pbodr, iobits);
+#else
+ setbits16(&immap->im_ioport.iop_papar, iobits);
+ clrbits16(&immap->im_ioport.iop_padir, iobits);
+ clrbits16(&immap->im_ioport.iop_paodr, iobits);
+#endif
+}
+
+static void __init mpc885ads_fixup_uart_pdata(struct platform_device *pdev,
+ int idx)
+{
+ bd_t *bd = (bd_t *) __res;
+ struct fs_uart_platform_info *pinfo;
+ int num = ARRAY_SIZE(mpc885_uart_pdata);
+
+ int id = fs_uart_id_smc2fsid(idx);
+
+ /* no need to alter anything if console */
+ if ((id <= num) && (!pdev->dev.platform_data)) {
+ pinfo = &mpc885_uart_pdata[id];
+ pinfo->uart_clk = bd->bi_intfreq;
+ pdev->dev.platform_data = pinfo;
+ }
+}
+
+
static int mpc885ads_platform_notify(struct device *dev)
{
@@ -356,12 +448,17 @@ static int mpc885ads_platform_notify(str
.rtn = mpc885ads_fixup_scc_enet_pdata,
},
{
+ .bus_id = "fsl-cpm-smc:uart",
+ .rtn = mpc885ads_fixup_uart_pdata
+ },
+ {
.bus_id = NULL
}
};
platform_notify_map(dev_map,dev);
+ return 0;
}
int __init mpc885ads_init(void)
@@ -383,7 +480,41 @@ int __init mpc885ads_init(void)
ppc_sys_device_enable(MPC8xx_CPM_FEC2);
#endif
+#ifdef CONFIG_SERIAL_CPM_SMC1
+ ppc_sys_device_enable(MPC8xx_CPM_SMC1);
+ ppc_sys_device_setfunc(MPC8xx_CPM_SMC1, PPC_SYS_FUNC_UART);
+#endif
+
+#ifdef CONFIG_SERIAL_CPM_SMC2
+ ppc_sys_device_enable(MPC8xx_CPM_SMC2);
+ ppc_sys_device_setfunc(MPC8xx_CPM_SMC2, PPC_SYS_FUNC_UART);
+#endif
return 0;
}
arch_initcall(mpc885ads_init);
+
+/*
+ To prevent confusion, console selection is gross:
+ by 0 assumed SMC1 and by 1 assumed SMC2
+ */
+struct platform_device* early_uart_get_pdev(int index)
+{
+ bd_t *bd = (bd_t *) __res;
+ struct fs_uart_platform_info *pinfo;
+
+ struct platform_device* pdev = NULL;
+ if(index) { /*assume SMC2 here*/
+ pdev = &ppc_sys_platform_devices[MPC8xx_CPM_SMC2];
+ pinfo = &mpc885_uart_pdata[1];
+ } else { /*over SMC1*/
+ pdev = &ppc_sys_platform_devices[MPC8xx_CPM_SMC1];
+ pinfo = &mpc885_uart_pdata[0];
+ }
+
+ pinfo->uart_clk = bd->bi_intfreq;
+ pdev->dev.platform_data = pinfo;
+ ppc_sys_fixup_mem_resource(pdev, IMAP_ADDR);
+ return NULL;
+}
+
diff --git a/arch/ppc/platforms/pq2ads.c b/arch/ppc/platforms/pq2ads.c
index 3365fd7..7fc2e02 100644
--- a/arch/ppc/platforms/pq2ads.c
+++ b/arch/ppc/platforms/pq2ads.c
@@ -14,11 +14,40 @@
#include <linux/init.h>
+#include <asm/io.h>
#include <asm/mpc8260.h>
+#include <asm/cpm2.h>
+#include <asm/immap_cpm2.h>
void __init
m82xx_board_setup(void)
{
+ cpm2_map_t* immap = ioremap(CPM_MAP_ADDR, sizeof(cpm2_map_t));
+ u32 *bcsr = ioremap(BCSR_ADDR+4, sizeof(u32));
+
/* Enable the 2nd UART port */
- *(volatile uint *)(BCSR_ADDR + 4) &= ~BCSR1_RS232_EN2;
+ clrbits32(bcsr, BCSR1_RS232_EN2);
+
+#ifdef CONFIG_SERIAL_CPM_SCC1
+ clrbits32((u32*)&immap->im_scc[0].scc_sccm, UART_SCCM_TX | UART_SCCM_RX);
+ clrbits32((u32*)&immap->im_scc[0].scc_gsmrl, SCC_GSMRL_ENR | SCC_GSMRL_ENT);
+#endif
+
+#ifdef CONFIG_SERIAL_CPM_SCC2
+ clrbits32((u32*)&immap->im_scc[1].scc_sccm, UART_SCCM_TX | UART_SCCM_RX);
+ clrbits32((u32*)&immap->im_scc[1].scc_gsmrl, SCC_GSMRL_ENR | SCC_GSMRL_ENT);
+#endif
+
+#ifdef CONFIG_SERIAL_CPM_SCC3
+ clrbits32((u32*)&immap->im_scc[2].scc_sccm, UART_SCCM_TX | UART_SCCM_RX);
+ clrbits32((u32*)&immap->im_scc[2].scc_gsmrl, SCC_GSMRL_ENR | SCC_GSMRL_ENT);
+#endif
+
+#ifdef CONFIG_SERIAL_CPM_SCC4
+ clrbits32((u32*)&immap->im_scc[3].scc_sccm, UART_SCCM_TX | UART_SCCM_RX);
+ clrbits32((u32*)&immap->im_scc[3].scc_gsmrl, SCC_GSMRL_ENR | SCC_GSMRL_ENT);
+#endif
+
+ iounmap(bcsr);
+ iounmap(immap);
}
^ permalink raw reply related
* [PATCH 4/4] ppc32 CPM_UART: Fixed odd address translations
From: Vitaly Bordug @ 2006-04-25 16:26 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-embedded
In-Reply-To: <20060425162633.23551.85273.stgit@vitb.ru.mvista.com>
Current address translation methods can produce wrong results, because
virt_to_bus and vice versa may not produce correct offsets on dma-allocated
memory. The right way is, while tracking both phys and virt address of the
window that has been allocated for boffer descriptors, and use those
numbers to compute the offset and make translation properly.
Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
---
drivers/serial/cpm_uart/cpm_uart.h | 33 +++++++++++++++++++++++++++++++
drivers/serial/cpm_uart/cpm_uart_core.c | 31 ++++++++---------------------
drivers/serial/cpm_uart/cpm_uart_cpm1.c | 7 ++++---
drivers/serial/cpm_uart/cpm_uart_cpm2.c | 5 ++++-
4 files changed, 50 insertions(+), 26 deletions(-)
diff --git a/drivers/serial/cpm_uart/cpm_uart.h b/drivers/serial/cpm_uart/cpm_uart.h
index 17f2c7a..9db402c 100644
--- a/drivers/serial/cpm_uart/cpm_uart.h
+++ b/drivers/serial/cpm_uart/cpm_uart.h
@@ -66,6 +66,7 @@ struct uart_cpm_port {
uint dp_addr;
void *mem_addr;
dma_addr_t dma_addr;
+ u32 mem_size;
/* helpers */
int baud;
int bits;
@@ -92,4 +93,36 @@ void scc2_lineif(struct uart_cpm_port *p
void scc3_lineif(struct uart_cpm_port *pinfo);
void scc4_lineif(struct uart_cpm_port *pinfo);
+/*
+ virtual to phys transtalion
+*/
+static inline unsigned long cpu2cpm_addr(void* addr, struct uart_cpm_port *pinfo)
+{
+ int offset;
+ u32 val = (u32)addr;
+ /* sane check */
+ if ((val >= (u32)pinfo->mem_addr) &&
+ (val<((u32)pinfo->mem_addr + pinfo->mem_size))) {
+ offset = val - (u32)pinfo->mem_addr;
+ return pinfo->dma_addr+offset;
+ }
+ printk("%s(): address %x to translate out of range!\n", __FUNCTION__, val);
+ return 0;
+}
+
+static inline void *cpm2cpu_addr(unsigned long addr, struct uart_cpm_port *pinfo)
+{
+ int offset;
+ u32 val = addr;
+ /* sane check */
+ if ((val >= pinfo->dma_addr) &&
+ (val<(pinfo->dma_addr + pinfo->mem_size))) {
+ offset = val - (u32)pinfo->dma_addr;
+ return (void*)(pinfo->mem_addr+offset);
+ }
+ printk("%s(): address %x to translate out of range!\n", __FUNCTION__, val);
+ return 0;
+}
+
+
#endif /* CPM_UART_H */
diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c b/drivers/serial/cpm_uart/cpm_uart_core.c
index 8f33815..3549073 100644
--- a/drivers/serial/cpm_uart/cpm_uart_core.c
+++ b/drivers/serial/cpm_uart/cpm_uart_core.c
@@ -72,19 +72,6 @@ static void cpm_uart_initbd(struct uart_
/**************************************************************/
-static inline unsigned long cpu2cpm_addr(void *addr)
-{
- if ((unsigned long)addr >= CPM_ADDR)
- return (unsigned long)addr;
- return virt_to_bus(addr);
-}
-
-static inline void *cpm2cpu_addr(unsigned long addr)
-{
- if (addr >= CPM_ADDR)
- return (void *)addr;
- return bus_to_virt(addr);
-}
/* Place-holder for board-specific stuff */
struct platform_device* __attribute__ ((weak)) __init
@@ -290,7 +277,7 @@ static void cpm_uart_int_rx(struct uart_
}
/* get pointer */
- cp = cpm2cpu_addr(bdp->cbd_bufaddr);
+ cp = cpm2cpu_addr(bdp->cbd_bufaddr, pinfo);
/* loop through the buffer */
while (i-- > 0) {
@@ -633,7 +620,7 @@ static int cpm_uart_tx_pump(struct uart_
/* Pick next descriptor and fill from buffer */
bdp = pinfo->tx_cur;
- p = cpm2cpu_addr(bdp->cbd_bufaddr);
+ p = cpm2cpu_addr(bdp->cbd_bufaddr, pinfo);
*p++ = port->x_char;
bdp->cbd_datlen = 1;
@@ -660,7 +647,7 @@ static int cpm_uart_tx_pump(struct uart_
while (!(bdp->cbd_sc & BD_SC_READY) && (xmit->tail != xmit->head)) {
count = 0;
- p = cpm2cpu_addr(bdp->cbd_bufaddr);
+ p = cpm2cpu_addr(bdp->cbd_bufaddr, pinfo);
while (count < pinfo->tx_fifosize) {
*p++ = xmit->buf[xmit->tail];
xmit->tail = (xmit->tail + 1) & (UART_XMIT_SIZE - 1);
@@ -709,12 +696,12 @@ static void cpm_uart_initbd(struct uart_
mem_addr = pinfo->mem_addr;
bdp = pinfo->rx_cur = pinfo->rx_bd_base;
for (i = 0; i < (pinfo->rx_nrfifos - 1); i++, bdp++) {
- bdp->cbd_bufaddr = cpu2cpm_addr(mem_addr);
+ bdp->cbd_bufaddr = cpu2cpm_addr(mem_addr, pinfo);
bdp->cbd_sc = BD_SC_EMPTY | BD_SC_INTRPT;
mem_addr += pinfo->rx_fifosize;
}
- bdp->cbd_bufaddr = cpu2cpm_addr(mem_addr);
+ bdp->cbd_bufaddr = cpu2cpm_addr(mem_addr, pinfo);
bdp->cbd_sc = BD_SC_WRAP | BD_SC_EMPTY | BD_SC_INTRPT;
/* Set the physical address of the host memory
@@ -724,12 +711,12 @@ static void cpm_uart_initbd(struct uart_
mem_addr = pinfo->mem_addr + L1_CACHE_ALIGN(pinfo->rx_nrfifos * pinfo->rx_fifosize);
bdp = pinfo->tx_cur = pinfo->tx_bd_base;
for (i = 0; i < (pinfo->tx_nrfifos - 1); i++, bdp++) {
- bdp->cbd_bufaddr = cpu2cpm_addr(mem_addr);
+ bdp->cbd_bufaddr = cpu2cpm_addr(mem_addr, pinfo);
bdp->cbd_sc = BD_SC_INTRPT;
mem_addr += pinfo->tx_fifosize;
}
- bdp->cbd_bufaddr = cpu2cpm_addr(mem_addr);
+ bdp->cbd_bufaddr = cpu2cpm_addr(mem_addr, pinfo);
bdp->cbd_sc = BD_SC_WRAP | BD_SC_INTRPT;
}
@@ -1099,7 +1086,7 @@ static void cpm_uart_console_write(struc
* If the buffer address is in the CPM DPRAM, don't
* convert it.
*/
- cp = cpm2cpu_addr(bdp->cbd_bufaddr);
+ cp = cpm2cpu_addr(bdp->cbd_bufaddr, pinfo);
*cp = *s;
@@ -1116,7 +1103,7 @@ static void cpm_uart_console_write(struc
while ((bdp->cbd_sc & BD_SC_READY) != 0)
;
- cp = cpm2cpu_addr(bdp->cbd_bufaddr);
+ cp = cpm2cpu_addr(bdp->cbd_bufaddr, pinfo);
*cp = 13;
bdp->cbd_datlen = 1;
diff --git a/drivers/serial/cpm_uart/cpm_uart_cpm1.c b/drivers/serial/cpm_uart/cpm_uart_cpm1.c
index 31223aa..a5a3062 100644
--- a/drivers/serial/cpm_uart/cpm_uart_cpm1.c
+++ b/drivers/serial/cpm_uart/cpm_uart_cpm1.c
@@ -144,7 +144,7 @@ int cpm_uart_allocbuf(struct uart_cpm_po
/* was hostalloc but changed cause it blows away the */
/* large tlb mapping when pinning the kernel area */
mem_addr = (u8 *) cpm_dpram_addr(cpm_dpalloc(memsz, 8));
- dma_addr = 0;
+ dma_addr = (u32)mem_addr;
} else
mem_addr = dma_alloc_coherent(NULL, memsz, &dma_addr,
GFP_KERNEL);
@@ -157,8 +157,9 @@ int cpm_uart_allocbuf(struct uart_cpm_po
}
pinfo->dp_addr = dp_offset;
- pinfo->mem_addr = mem_addr;
- pinfo->dma_addr = dma_addr;
+ pinfo->mem_addr = mem_addr; /* virtual address*/
+ pinfo->dma_addr = dma_addr; /* physical address*/
+ pinfo->mem_size = memsz;
pinfo->rx_buf = mem_addr;
pinfo->tx_buf = pinfo->rx_buf + L1_CACHE_ALIGN(pinfo->rx_nrfifos
diff --git a/drivers/serial/cpm_uart/cpm_uart_cpm2.c b/drivers/serial/cpm_uart/cpm_uart_cpm2.c
index c9c3b1d..7c6b07a 100644
--- a/drivers/serial/cpm_uart/cpm_uart_cpm2.c
+++ b/drivers/serial/cpm_uart/cpm_uart_cpm2.c
@@ -209,8 +209,10 @@ int cpm_uart_allocbuf(struct uart_cpm_po
memsz = L1_CACHE_ALIGN(pinfo->rx_nrfifos * pinfo->rx_fifosize) +
L1_CACHE_ALIGN(pinfo->tx_nrfifos * pinfo->tx_fifosize);
- if (is_con)
+ if (is_con) {
mem_addr = alloc_bootmem(memsz);
+ dma_addr = mem_addr;
+ }
else
mem_addr = dma_alloc_coherent(NULL, memsz, &dma_addr,
GFP_KERNEL);
@@ -225,6 +227,7 @@ int cpm_uart_allocbuf(struct uart_cpm_po
pinfo->dp_addr = dp_offset;
pinfo->mem_addr = mem_addr;
pinfo->dma_addr = dma_addr;
+ pinfo->mem_size = memsz;
pinfo->rx_buf = mem_addr;
pinfo->tx_buf = pinfo->rx_buf + L1_CACHE_ALIGN(pinfo->rx_nrfifos
^ permalink raw reply related
* [PATCH 1/4] ppc32: odd fixes and improvements in ppc_sys
From: Vitaly Bordug @ 2006-04-25 16:26 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-embedded
This consists of offsets fix in ..._devices.c, and update of
ppc_sys_fixup_mem_resource() function to prevent subsequent fixups
Sigbed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
---
arch/ppc/syslib/mpc8xx_devices.c | 25 +++++++++++++++++++------
arch/ppc/syslib/ppc_sys.c | 4 +++-
arch/ppc/syslib/pq2_sys.c | 8 ++++----
include/asm-ppc/ppc_sys.h | 2 ++
4 files changed, 28 insertions(+), 11 deletions(-)
diff --git a/arch/ppc/syslib/mpc8xx_devices.c b/arch/ppc/syslib/mpc8xx_devices.c
index bd41ed8..6f53638 100644
--- a/arch/ppc/syslib/mpc8xx_devices.c
+++ b/arch/ppc/syslib/mpc8xx_devices.c
@@ -170,12 +170,18 @@ struct platform_device ppc_sys_platform_
[MPC8xx_CPM_SMC1] = {
.name = "fsl-cpm-smc",
.id = 1,
- .num_resources = 2,
+ .num_resources = 3,
.resource = (struct resource[]) {
{
.name = "regs",
- .start = 0xa82,
- .end = 0xa91,
+ .start = 0xa80,
+ .end = 0xa8f,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .name = "pram",
+ .start = 0x3e80,
+ .end = 0x3ebf,
.flags = IORESOURCE_MEM,
},
{
@@ -189,15 +195,22 @@ struct platform_device ppc_sys_platform_
[MPC8xx_CPM_SMC2] = {
.name = "fsl-cpm-smc",
.id = 2,
- .num_resources = 2,
+ .num_resources = 3,
.resource = (struct resource[]) {
{
.name = "regs",
- .start = 0xa92,
- .end = 0xaa1,
+ .start = 0xa90,
+ .end = 0xa9f,
.flags = IORESOURCE_MEM,
},
{
+ .name = "pram",
+ .start = 0x3f80,
+ .end = 0x3fbf,
+ .flags = IORESOURCE_MEM,
+
+ },
+ {
.name = "interrupt",
.start = MPC8xx_INT_SMC2,
.end = MPC8xx_INT_SMC2,
diff --git a/arch/ppc/syslib/ppc_sys.c b/arch/ppc/syslib/ppc_sys.c
index 7662c4e..2d48018 100644
--- a/arch/ppc/syslib/ppc_sys.c
+++ b/arch/ppc/syslib/ppc_sys.c
@@ -109,9 +109,11 @@ ppc_sys_fixup_mem_resource(struct platfo
int i;
for (i = 0; i < pdev->num_resources; i++) {
struct resource *r = &pdev->resource[i];
- if ((r->flags & IORESOURCE_MEM) == IORESOURCE_MEM) {
+ if (((r->flags & IORESOURCE_MEM) == IORESOURCE_MEM) &&
+ ((r->flags & PPC_SYS_IORESOURCE_FIXUPPED) != PPC_SYS_IORESOURCE_FIXUPPED)) {
r->start += paddr;
r->end += paddr;
+ r->flags |= PPC_SYS_IORESOURCE_FIXUPPED;
}
}
}
diff --git a/arch/ppc/syslib/pq2_sys.c b/arch/ppc/syslib/pq2_sys.c
index 75e64f1..433b0fa 100644
--- a/arch/ppc/syslib/pq2_sys.c
+++ b/arch/ppc/syslib/pq2_sys.c
@@ -113,13 +113,13 @@ struct ppc_sys_spec ppc_sys_specs[] = {
.ppc_sys_name = "8248",
.mask = 0x0000ff00,
.value = 0x00000c00,
- .num_devices = 11,
+ .num_devices = 12,
.device_list = (enum ppc_sys_devices[])
{
MPC82xx_CPM_FCC1, MPC82xx_CPM_FCC2, MPC82xx_CPM_SCC1,
- MPC82xx_CPM_SCC2, MPC82xx_CPM_SCC3, MPC82xx_CPM_SMC1,
- MPC82xx_CPM_SMC2, MPC82xx_CPM_SPI, MPC82xx_CPM_I2C,
- MPC82xx_CPM_USB, MPC82xx_SEC1,
+ MPC82xx_CPM_SCC2, MPC82xx_CPM_SCC3, MPC82xx_CPM_SCC4,
+ MPC82xx_CPM_SMC1, MPC82xx_CPM_SMC2, MPC82xx_CPM_SPI,
+ MPC82xx_CPM_I2C, MPC82xx_CPM_USB, MPC82xx_SEC1,
},
},
{
diff --git a/include/asm-ppc/ppc_sys.h b/include/asm-ppc/ppc_sys.h
index 4b94f70..40f197a 100644
--- a/include/asm-ppc/ppc_sys.h
+++ b/include/asm-ppc/ppc_sys.h
@@ -39,6 +39,8 @@
#error "need definition of ppc_sys_devices"
#endif
+#define PPC_SYS_IORESOURCE_FIXUPPED 0x00000001
+
struct ppc_sys_spec {
/* PPC sys is matched via (ID & mask) == value, id could be
* PVR, SVR, IMMR, * etc. */
^ permalink raw reply related
* Re: 85xx FDT updates?
From: Kumar Gala @ 2006-04-25 16:25 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-dev@ozlabs.org list, Paul Mackerras
In-Reply-To: <20060425161200.GC20228@gate.ebshome.net>
On Apr 25, 2006, at 11:12 AM, Eugene Surovegin wrote:
> On Tue, Apr 25, 2006 at 09:05:54AM -0500, Kumar Gala wrote:
>>
>> Second, this seems normal like normal kernel development to me. I
>> think its reasonable to pick some time frame after which we will
>> remove the support and to let everyone know what that is. I see this
>> as no different than having a driver outside of the kernel tree and
>> having it break when APIs change.
>
> I don't agree. This is not the same as changing _internal_ kernel API
> for a simple reason that _firmware_ was never part of the kernel and
> will never be. You seem to have an idea that's that's OK to _remove_
> existing functionality from the kernel for no reason except your
> convenience. I think this is unacceptable. If kernel was able to boot
> on some hardware (including reference one) in the past it should be
> able to do this now even if this will require some boot shim.
If we are talking about a reference board than I think this is an
absurd requirement. If you are willing to update your kernel on such
a board why would you not be willing to update the firmware as well.
To my knowledge all the in tree boards that are supported for 85xx
all boot via u-boot. So if u-boot is available for the given board
that is capable of booting an arch/powerpc kernel why would we need
to continue supporting the board in arch/ppc.
- kumar
^ 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