All of lore.kernel.org
 help / color / mirror / Atom feed
From: Per Hallsmark <per.hallsmark@t2data.se>
To: Jaap-Jan Boor <jjboor@aimsys.nl>
Cc: linuxppc-embedded <linuxppc-embedded@ozlabs.org>
Subject: RE: Question about cpm reset on 8xx
Date: Thu, 3 Feb 2005 16:02:28 +0100	[thread overview]
Message-ID: <41FFBC9A@webmail> (raw)

Thanks for replying,

Yes, probably the 8260 code evolved from the 8xx code?
Personally I like to code so logic is reset'd to a known base
even if that means we have to go through some setup steps again.

Of course, there could be a reason why it is like it is
and that's why I sent out the question...

We have a problem where hdlc sometimes seems to lookup, when the ppc
reboots it doesn't helps but after a while it is reseted by harder
means (pulling the resetline) which helps. Testing the change right now,
but it can take long time before it happens...

>===== Original Message From Jaap-Jan Boor <jjboor@aimsys.nl> =====
>On Thu, 2005-02-03 at 15:29, Per Hallsmark wrote:
>> Hi all,
>>
>> Working with a board using hdlc over SCC channel (852T) and kernel 2.4.21,
>> in the cpm reset code in arch/ppc/8xx_io/commproc.c it's like:
>>
>> void
>> m8xx_cpm_reset()
>> {
>>         volatile immap_t         *imp;
>>         volatile cpm8xx_t       *commproc;
>>         pte_t                   *pte;
>>
>>
>>         imp = (immap_t *)IMAP_ADDR;
>>         commproc = (cpm8xx_t *)&imp->im_cpm;
>>
>>
>> #ifdef CONFIG_UCODE_PATCH
>>         /* Perform a reset.
>>         */
>>         commproc->cp_cpcr = (CPM_CR_RST | CPM_CR_FLG);
>>
>>
>>         /* Wait for it.
>>         */
>>         while (commproc->cp_cpcr & CPM_CR_FLG);
>>
>>
>>         cpm_load_patch(imp);
>> #endif
>>      .......
>>
>> In our case, CONFIG_UCODE_PATCH is not defined so the commproc is never
>> reseted during reboot. Could it be that the #ifdef CONFIG_UCODE_PATCH
>> should just be around the cpm_load_patch command?
>
>It seems the author wants to reset the cpm only when microcode
>patches are needed.
>
>m8260_cpm_reset() does also not reset the cpm.
>
>I don't know why (e.g. the console is setup after this)
>
>Jaap-Jan
>
>> The CONFIG_UCODE_PATCH seems to point this to be i2c/spi patch, but
>> shouldn't a reset go to cpm in anycase?
>>
>> /Per
>>
>>
>>
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded

             reply	other threads:[~2005-02-03 15:11 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-03 15:02 Per Hallsmark [this message]
2005-02-03 15:34 ` Question about cpm reset on 8xx Dan Malek
  -- strict thread matches above, loose matches on Subject: below --
2005-02-03 14:29 Per Hallsmark
2005-02-03 14:53 ` Jaap-Jan Boor

Reply instructions:

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

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

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

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

  git send-email \
    --in-reply-to=41FFBC9A@webmail \
    --to=per.hallsmark@t2data.se \
    --cc=jjboor@aimsys.nl \
    --cc=linuxppc-embedded@ozlabs.org \
    /path/to/YOUR_REPLY

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

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