On Thu, Mar 20, 2008 at 04:18:26PM +0100, Laurent Pinchart wrote:
> I don't want to kill it either. What I meant is that my first patch will not
> care about udbg so that I can get feedback about the CPM serial driver part.
> I'll then see how to make udbg fit into that.
OK.
> > Perhaps we shou
On Thursday 20 March 2008 16:08, Scott Wood wrote:
> On Thu, Mar 20, 2008 at 02:39:56PM +0100, Laurent Pinchart wrote:
> > I'm working on a patch. I'm not sure how to handle the early udbg printk
> > problem, so the first version will just ignore it.
>
> udbg printk is extremely useful... I'd not b
On Thu, Mar 20, 2008 at 02:39:56PM +0100, Laurent Pinchart wrote:
> I'm working on a patch. I'm not sure how to handle the early udbg printk
> problem, so the first version will just ignore it.
udbg printk is extremely useful... I'd not be fond of it breaking.
Perhaps we should stick more initia
Hi Scott,
On Monday 17 March 2008 16:33, Scott Wood wrote:
> On Mon, Mar 10, 2008 at 01:17:01PM +0100, Laurent Pinchart wrote:
> > On Friday 07 March 2008 17:21, Scott Wood wrote:
> > > cpm2_reset() doesn't currently actually reset the CPM, for some reason
> > > (unlike cpm1). This should probabl
On Mon, Mar 10, 2008 at 01:17:01PM +0100, Laurent Pinchart wrote:
> On Friday 07 March 2008 17:21, Scott Wood wrote:
> > cpm2_reset() doesn't currently actually reset the CPM, for some reason
> > (unlike cpm1). This should probably be fixed, though then we'd have to
> > deal with assigning SMC par
On Friday 07 March 2008 17:21, Scott Wood wrote:
> On Fri, Mar 07, 2008 at 03:20:55PM +0100, Laurent Pinchart wrote:
> > The CPM dual port ram was defined in the device tree as follows (copied
> > from the MPC8272ADS board device tree).
> >
> > [EMAIL PROTECTED] {
> > #addre
On Fri, Mar 07, 2008 at 03:20:55PM +0100, Laurent Pinchart wrote:
> The CPM dual port ram was defined in the device tree as follows (copied from
> the MPC8272ADS board device tree).
>
> [EMAIL PROTECTED] {
> #address-cells = <1>;
> #size-cells = <1>;
>
Laurent Pinchart wrote:
> Does anyone have any clue regarding what could write to the dpram ? I thought
> about some CPM peripheral set up by the boot loader, but my board
> initialization code calls cpm2_reset() long before initializing SCC1.
I'm not familar with the CPM, but in cpm_common.c a
