Re: [U-Boot] [PATCH 3/3] TI: TNETV107X EVM initial support
Wolfgang, [...] Is davinci correct here? Yes, this SOC has the exact same controller as on Davinci, and therefore the NAND driver is reused. But you don't call this a Davinci-Board, or do you? Davinci NAND is a bit of a misnomer since this particular EMIF block is commonly used across multiple TI devices. Unfortunately, this misnomer (amongst others) carries forward into the kernel too. Consequently, if we use a different device name here, the mtdparts variable won't be usable as a kernel command-line argument. Regards Cyril. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] ARM1176: TI: TNETV107X soc initial support
Hi Wolfgang,
You might want to define a macro to reduce the amount of repeated
code here.
Will do in v2.
+void lpsc_control(unsigned int id, int state)
+{
+ __lpsc_control(1, -1, id, state);
+}
+
+int lpsc_status(unsigned int id)
+{
+ return psc_reg_read(PSC_MDSTAT(id)) 0x1f;
+}
+
+void clk_enable(unsigned int id)
+{
+ lpsc_control(id, PSC_MDCTL_NEXT_ENABLE);
+}
+
+void clk_disable(unsigned int id)
+{
+ lpsc_control(id, PSC_MDCTL_NEXT_DISABLE);
+}
These should probably be inlined ?
Are you referring to lpsc_control(), or to clk_enable/clk_disable?
The former can be eliminated, I think.
The latter are used elsewhere. Are you recommending that I inline and move to
a header?
Regards
Cyril.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] TI: TNETV107X EVM initial support
Hi Wolfgang, Thanks. Will send out a v2 with these changed. [...] +#define MTDPARTS_DEFAULT mtdparts=davinci_nand.0: \ + 1536k(uboot)ro, \ + 128k(params)ro, \ + 4m(kernel), \ + -(filesystem) Is davinci correct here? Yes, this SOC has the exact same controller as on Davinci, and therefore the NAND driver is reused. Regards Cyril. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/1] TI: Davinci: NAND Driver Cleanup
Hi Nick,
I didn't check, but I would assume checkpatch would complain about the
spaces that have crept in here?
Interestingly checkpatch complains only if it finds 8 or more spaces at the
beginning of the line (below). For some reason, vim cindent inserted 7 spaces
in there, and that kept checkpatch from complaining.
...
# at the beginning of a line any tabs must come first and anything
# more than 8 must use tabs.
if ($rawline =~ /^\+\s* \t\s*\S/ ||
$rawline =~ /^\+\s*\s*/) {
my $herevet = $here\n . cat_vet($rawline) . \n;
ERROR(code indent should use tabs where possible\n .
$herevet);
}
...
If you haven't already done so, it would be a good idea to run
checkpatch to check for any other formatting violations.
Thanks, resubmitted.
Regards
Cyril.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] TI: Davinci: NAND Driver Cleanup
Hi Scott, Configuring for davinci_schmoogie board... ... Should be lowercase? Thank you. I will be sending out a v2 shortly, and this time around all 8 davinci based boards build fine. Also, any particular reason to use the raw version of the accessors? Please correct me if I am wrong here, but my understanding is that the raw variants are for native-endian access, while the non-raw ones could potentially force little-endian conversions for PCI. If so, since these on-chip registers must always be accessed native-endian, I felt that the raw accessors would be appropriate. Any thoughts? Regards Cyril. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM1176: Coexist with other ARM1176 platforms
Tom, I was not able to access this link But, yes, please include this patch as part of the tnetv107x patchset. Sure. I will include this with the larger TNETV107X patchset and submit. Until then, a code preview can be found at http://arago-project.org/git/people/?p=cyril/u-boot-tnetv107x.git;a=commit;h=0ab8eaa7c4c4472d64f9f401fc2f091dca955abc (included a non-shortened URL this time). Ok. Obviously it is better to generalize than to make off-by-one copies but not if there are not enough similarities to make it work.. Absolutely. In this particular case, it just happens to be the latter. My concern is that start.S, because it came originally from s3c64xx, may need to either generalized or split up. With s3c64xx parts moving to SOC layer. Assembly is complicated enough without having #if-def's and if can be done in C it should. Indeed start.S needed to be generalized to an extent. Further, since similar generalizations existed on other ARM platforms, I figured it would be best to stick with the same scheme. My only reservation is with the whole peripheral port remap thing. I think that this should ideally be moved into SOC specific lowlevel_init. However, I did not want to mangle up s3c64xx code too much by moving stuff around in this manner. Any thoughts on this specific concern? Please review http://www.denx.de/wiki/U-Boot/Patches, clean up the patchset and submit, having another arm1176 soc will be great. Will do. Thanks. Cyril. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM1176: Coexist with other ARM1176 platforms
Hi Tom, This patch is premature. I need to see this patch within the context of the new SOC. For a new SOC, I would like it be added as a new sub dir off of cpu/arm1176. At the same level as s3c64xx. So this dir would look like. config.mk cpu.c Makefile new_soc_name s3c64xx start.S u-boot.lds Correct. The new SOC adds cpu/arm1176/tnetv107x/. Would you prefer if I were to include this patch as part of the initial tnetv107x submission? You could take a peek at this future submission at http://bit.ly/b1F2qX. The common code that is sharable should also be at this level. This may mean moving and generalizing some s3c64xx/*.c. I have taken a look at the code inside s3c64xx, and found it specific to that SOC (memory interface initialization, reset, etc.). Therefore, I don't think any of that code can be generalized and pulled out into cpu/arm1176/. Guennadi, do you agree with this assessment? The SOC specific code must be in its own dir. An example of this may be the lowlevel_init needs to move from start.S to SOC/lowlevel_init.S lowlevel_init is _called_ from start.S and is expected to be implemented by SOCs if needed (ifndef CONFIG_SKIP_LOWLEVEL_INIT). I do not want one SOC if-def-ing up another SOC. Absolutely. I understand your concern, but this patch if-defs up arm1176 code, and not s3c64xx SOC code. The maintainer of the original s3c64xx SOC, Guennadi Liakhovetski g.liakhovet...@gmx.de, should be cc-ed on at least the initial changes so he has a heads up that some of his code is being moved/generalized. Thanks. Cyril. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
