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
next prev parent 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