Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: John Crispin <blogic@openwrt.org>
To: Daniel Schwierzeck <daniel.schwierzeck@googlemail.com>
Cc: Ralf Baechle <ralf@linux-mips.org>,
	Ralph Hempel <ralph.hempel@lantiq.com>,
	linux-mips@linux-mips.org
Subject: Re: [PATCH 01/10] MIPS: lantiq: add initial support for Lantiq SoCs
Date: Thu, 13 Jan 2011 12:14:26 +0100	[thread overview]
Message-ID: <4D2EDE92.40203@openwrt.org> (raw)
In-Reply-To: <AANLkTinBovWsPak3cCNRMigC8mxUwEik2oB3kSsw-YQL@mail.gmail.com>

Hi Daniel,

>> +static struct clk *cpu_clk;
>> +static int cpu_clk_cnt;
>> +
>> +static unsigned int r4k_offset;
>> +static unsigned int r4k_cur;
>>     
> What is the sense of these variables? They are never really used.
>   

left overs from old kernel patches, i'll remove them
>> +void __init
>> +plat_time_init(void)
>> +{
>> +       struct clk *clk = clk_get(0, "cpu");
>> +       mips_hpt_frequency = clk_get_rate(clk) / ltq_get_counter_resolution();
>> +       r4k_cur = (read_c0_count() + r4k_offset);
>> +       write_c0_compare(r4k_cur);
>>     
> Like stated above the r4k_cur and r4k_offset are only initailied with
> 0. So the last two lines
> could be written as write_c0_compare(read_c0_count()) and are actually
> ineffective.
>
>   

ok
>> +void
>> +early_printf(const char *fmt, ...)
>> +{
>> +       char buf[ASC_BUF];
>> +       va_list args;
>> +       int l;
>> +       char *p, *buf_end;
>> +       va_start(args, fmt);
>> +       l = vsnprintf(buf, ASC_BUF, fmt, args);
>> +       va_end(args);
>> +       buf_end = buf + l;
>> +       for (p = buf; p < buf_end; p++)
>> +               prom_putchar(*p);
>> +}
>>     
> With CONFIG_EARLY_PRINTK enabled and prom_putchar() implemented you
> can use printk() everywhere.
> So an own early_printf() is not needed.
>
>   

not quite, this is used by the prom code where printk is followed by an
unreachable() rendering the printk to not work. i asked in #mipslinux
about this already and was tolf that this is the only work around as the
early_printk api does not expose its internal simple_printf() function.

>> +
>> +static void
>> +ltq_hw_irqdispatch(int module)
>> +{
>> +       u32 irq;
>> +
>> +       irq = ltq_r32(LTQ_ICU_IM0_IOSR + (module * LTQ_ICU_OFFSET));
>> +       if (irq == 0)
>> +               return;
>> +
>> +       /* silicon bug causes only the msb set to 1 to be valid. all
>> +          other bits might be bogus */
>> +       irq = __fls(irq);
>> +       do_IRQ((int)irq + INT_NUM_IM0_IRL0 + (INT_NUM_IM_OFFSET * module));
>> +}
>> +
>> +#define DEFINE_HWx_IRQDISPATCH(x) \
>> +static void ltq_hw ## x ## _irqdispatch(void)\
>> +{\
>> +       ltq_hw_irqdispatch(x); \
>> +}
>> +DEFINE_HWx_IRQDISPATCH(0)
>> +DEFINE_HWx_IRQDISPATCH(1)
>> +DEFINE_HWx_IRQDISPATCH(2)
>> +DEFINE_HWx_IRQDISPATCH(3)
>> +DEFINE_HWx_IRQDISPATCH(4)
>>     
> The interrupt line IM0-IRL22 is shared by PCI (INT A) and EBU. Thus
> ltq_hw0_irqdispatch()
> should clear the PCI bit (5th bit) in EBU_PCC_ISTAT register (EBU_BASE
> + 0xA0) if you enable
> this interrupt in pcibios_plat_dev_init().
> This is undocumented in the hardware manuals but can be found in all
> Lantiq BSP's.
>
>   
i'll look into it


> +void __init
>> +arch_init_irq(void)
>> +{
>> +       int i;
>> +
>> +       for (i = 0; i < 5; i++)
>> +               ltq_w32(0, LTQ_ICU_IM0_IER + (i * LTQ_ICU_OFFSET));
>>     
> Perhaps pending interrupts should be cleared too with
> ltq_w32(~0, LTQ_ICU_IM0_ISR + (i * LTQ_ICU_OFFSET));
>
>   

will look into this too


>> +
>> +/* all access to the ebu must be locked */
>> +DEFINE_SPINLOCK(ebu_lock);
>> +EXPORT_SYMBOL_GPL(ebu_lock);
>>     
> This lock is only needed if you want to use software arbitration.
> Normally the EBU does hardware arbitration and can be accessed safely
> without lock.
>
>   
openwrt borks up on mini_fo init when this lock is not in-place. we saw
a lot of issues in the past which lead to this lock being added. i will
retry it with out the lock to verify

thx i will fold all suggestions into the next version of the series.

John

  reply	other threads:[~2011-01-13 11:26 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-05 19:56 [PATCH 00/10] MIPS: add support for Lantiq SoCs John Crispin
2011-01-05 19:56 ` [PATCH 01/10] MIPS: lantiq: add initial " John Crispin
2011-01-05 20:25   ` Geert Uytterhoeven
2011-01-13 11:05   ` Daniel Schwierzeck
2011-01-13 11:14     ` John Crispin [this message]
2011-01-13 12:47       ` Daniel Schwierzeck
2011-01-13 15:03         ` John Crispin
2011-01-05 19:56 ` [PATCH 02/10] MIPS: lantiq: add SoC specific code for XWAY family John Crispin
2011-01-05 19:56 ` [PATCH 03/10] MIPS: lantiq: add PCI controller support John Crispin
2011-01-05 19:56 ` [PATCH 04/10] MIPS: lantiq: add serial port support John Crispin
2011-01-05 19:56 ` [PATCH 05/10] MIPS: lantiq: add watchdog support John Crispin
2011-01-05 23:49   ` Jamie Iles
2011-01-06  9:51     ` John Crispin
2011-01-06 11:15       ` Jamie Iles
2011-01-06 11:38         ` John Crispin
2011-01-05 19:56 ` [PATCH 06/10] MIPS: lantiq: add NOR flash support John Crispin
2011-01-11  2:59   ` Daniel Schwierzeck
2011-01-11 10:29     ` John Crispin
2011-01-05 19:56 ` [PATCH 07/10] MIPS: lantiq: add NOR flash CFI address swizzle John Crispin
2011-01-06 10:06   ` John Crispin
2011-01-05 19:56 ` [PATCH 08/10] MIPS: lantiq: add platform device support John Crispin
2011-01-05 19:56 ` [PATCH 09/10] MIPS: lantiq: add mips_machine support John Crispin
2011-01-05 19:56 ` [PATCH 10/10] MIPS: lantiq: add machtypes for lantiq eval kits John Crispin
2011-01-11  2:44 ` [PATCH 00/10] MIPS: add support for Lantiq SoCs Daniel Schwierzeck
2011-01-11 12:07   ` John Crispin
2011-01-11 12:40     ` Daniel Schwierzeck
2011-01-11 12:49       ` John Crispin

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=4D2EDE92.40203@openwrt.org \
    --to=blogic@openwrt.org \
    --cc=daniel.schwierzeck@googlemail.com \
    --cc=linux-mips@linux-mips.org \
    --cc=ralf@linux-mips.org \
    --cc=ralph.hempel@lantiq.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox