From: yanhua <yanh@lemote.com>
To: Philippe Vachon <philippe@cowpig.ca>
Cc: linux-mips@linux-mips.org, Ralf Baechle <ralf@linux-mips.org>,
?????? <penglj@lemote.com>,
"zhangfx@lemote.com" <zhangfx@lemote.com>
Subject: Re: [PATCH 1/14] lemote: Loongson2F based machines support
Date: Thu, 09 Apr 2009 22:43:27 +0800 [thread overview]
Message-ID: <49DE098F.7090905@lemote.com> (raw)
In-Reply-To: <20090409141634.GA17941@cowpig.ca>
Philippe Vachon 写道:
> I think this patch would be a lot better off broken up into several
> pieces, but I also have found there's a lot of code that is duplicated
> in there that needs to be tidied up (even if the implementation isn't
> identical, the functionality is). This comment in particular applies to
> the yeelong/ and fuloong/ directories.
>
Thanks for your advice. we will merge the code to reduce duplicated
functions.
> As well, there's pretty egregious abuse of inline asm to do things that
> really don't require inline asm, like manipulating MMIO registers.
>
> The feedback I've provided is generally at a glance, though I have some
> familiarity with Lemote's code, so some of these are issues I've
> anticipated would come up. :-)
>
> I've also avoided stylistic feedback -- I think there are people who are
> far better qualified to comment on that.
>
> On Thu, Apr 09, 2009 at 12:50:16PM +0800, yanhua wrote:
>
>> +#ifdef CONFIG_TRACE_BOOT
>> + printk(KERN_INFO"arch_initcall:pcibios_init\n");
>> + printk(KERN_INFO"register_pci_controller :
>> %x\n",&loongson2f_pci_controller);
>> +#endif
>> +
>> +#ifdef CONFIG_64BIT
>> + loongson2f_pci_mem_resource.start = 0x50000000UL;
>> + loongson2f_pci_mem_resource.end = 0x7fffffffUL;
>> + __asm__(".set mips3\n"
>> + "dli $2,0x900000003ff00000\n"
>> + "li $3,0x40000000\n"
>> + "sd $3,0x18($2)\n"
>> + "or $3,1\n"
>> + "sd $3,0x58($2)\n"
>> + "dli $3,0xffffffffc0000000\n"
>> + "sd $3,0x38($2)\n"
>> + ".set mips0\n"
>> + :::"$2","$3","memory"
>> + );
>>
>
> This is completely unnecessary and should be rewritten without the
> inline asm; I've prepared a header that has both register offsets and
> bases, as well as accessor macros that look a lot neater than this mess.
>
> This can be found at:
> http://git.linux-cisco.org/?p=linux-mips.git;a=blob;f=arch/mips/include/asm/mach-stls2f/stls2f.h;h=9dbbb5d068618a1530c9396af32dfc4a394ea826;hb=refs/heads/linux-gdium
>
Really thanks. :-)
> (pardon the long URL)
>
>
>> +++ b/arch/mips/lemote/lm2f/fuloong/dbg_io.c
>> @@ -0,0 +1,182 @@
>>
> *snip*
>
>> +#ifdef CONFIG_64BIT
>> +#define BASE (0xffffffffbff003f8)
>> +#else
>> +#define BASE (0xbff003f8)
>> +#endif
>> +
>> +#else /* USE_CS5536_UART1/2 */
>> +
>> +#ifdef CONFIG_64BIT
>> +#define BASE 0xffffffffbfd002f8
>> +#else
>> +#define BASE 0xbfd002f8
>> +#endif
>> +
>> +#endif /* end of USE_GODSON2F_UART */
>>
>
> More magic numbers that should likely be moved into a header.
>
> *more code snipped*
>
>
>> +++ b/arch/mips/lemote/lm2f/fuloong/prom.c
>> +
>> +#ifdef CONFIG_32BIT
>> + *(volatile u32*)0xbfe00180 |= 0x7;
>> +#else
>> + *(volatile u32*)0xffffffffbfe00180 |= 0x7;
>> +#endif
>> + _rdmsr(0xe0000014, &hi, &lo);
>> + lo |= 0x00000001;
>> + _wrmsr(0xe0000014, hi, lo);
>> +
>>
>
> More magic numbers that should have names. Accesses to MMIO registers
> should be done through accessors.
>
>
>> + printk("Hard reset not take effect!!\n");
>> + __asm__ __volatile__ (
>> + ".long 0x3c02bfc0\n"
>> + ".long 0x00400008\n"
>> + :::"v0"
>> + );
>>
>
> This is really REALLY scary. Perhaps it'd be even slightly neater to
> convert that jump to a void function pointer -- something like
>
> ((void (*)(void))(RESET_VECTOR)))();
>
> (note that I haven't tested that, and RESET_VECTOR would have to be
> something appropriate, i.e. CKSEG1ADDR(BONITO_BOOT_BASE) in this case,
> though I think CKSEG1ADDR is frowned upon)
>
>
>
>> +static void loongson2f_halt(void)
>> +{
>> +#ifdef CONFIG_32BIT
>> + u32 base;
>> +#else
>> + u64 base;
>> +#endif
>> + u32 hi, lo, val;
>> +
>> + _rdmsr(0x8000000c, &hi, &lo);
>> +#ifdef CONFIG_32BIT
>> + base = (lo & 0xff00) | 0xbfd00000;
>> +#else
>> + base = (lo & 0xff00) | 0xffffffffbfd00000ULL;
>> +#endif
>> + val = (val & ~(1 << (16 + 13))) | (1 << 13);
>> + delay();
>> + *(__volatile__ u32 *)(base + 0x04) = val;
>> + delay();
>> + val = (val & ~(1 << (13))) | (1 << (16 + 13));
>> + delay();
>> + *(__volatile__ u32 *)(base + 0x00) = val;
>> + delay();
>> +}
>>
>
> See above, re: magic numbers.
>
> *snip*
>
>
>> +++ b/arch/mips/lemote/lm2f/fuloong/setup.c
>> +
>> +#ifdef CONFIG_64BIT
>> +#define PTR_PAD(p) ((0xffffffff00000000)|((unsigned long long)(p)))
>> +#else
>> +#define PTR_PAD(p) (p)
>> +#endif
>>
>
> This shouldn't be necessary at all.
>
>
>> +#ifdef CONFIG_64BIT
>> + __asm__(
>> + ".set mips3\n"
>> + "dli $2, 0x900000003ff00000\n"
>> + "dli $3, 0x0000000080000000\n"
>> + "sd $3, 0x10($2)\n"
>> + "sd $0, 0x50($2)\n"
>> + "dli $3, 0xffffffff80000000\n"
>> + "sd $3, 0x30($2)\n"
>> + ".set mips0\n"
>> + :::"$2","$3","memory");
>> + if (highmemsize > 0) {
>> + add_memory_region(0x90000000, highmemsize << 20, BOOT_MEM_RAM);
>> + }
>> +#endif
>>
>
> This can all be done using accessors, as described above.
>
> I notice there seems to be a lot of duplicated code in the yeelong
> directory. Perhaps it is worthwhile to try to further consolidate some
> of it?
>
> My comments above seem to largely apply to the Yeelong code as well.
>
>
>> +++ b/arch/mips/pci/fixup-fl2f.c
>> +#ifdef CONFIG_64BIT
>> + *(volatile u32*)0xffffffffbfe0004c = 0xd2000001;
>> +#else
>> + *(volatile u32*)0xbfe0004c = 0xd2000001;
>> +#endif
>>
>
> Again, stuff like this is really unnecessary.
>
> I generally mirror Arnaud's sentiment about the structuring of the code
> -- I suspect a loongson/ directory in arch/mips makes more sense, then
> followed by an ls2f/ and ls2e/ directory.
>
> Cheers,
> Phil
>
>
--
晏华
next prev parent reply other threads:[~2009-04-09 14:43 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-09 4:50 [PATCH 1/14] lemote: Loongson2F based machines support yanhua
2009-04-09 8:39 ` Arnaud Patard
2009-04-09 9:01 ` yanhua
2009-04-13 11:36 ` Zhang Le
2009-04-13 12:25 ` yanhua
2009-04-09 14:16 ` Philippe Vachon
2009-04-09 14:43 ` yanhua [this message]
2009-04-14 9:46 ` Zhang Le
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=49DE098F.7090905@lemote.com \
--to=yanh@lemote.com \
--cc=linux-mips@linux-mips.org \
--cc=penglj@lemote.com \
--cc=philippe@cowpig.ca \
--cc=ralf@linux-mips.org \
--cc=zhangfx@lemote.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 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.