Am Samstag, 24. November 2012, 12:24:49 schrieb Heiko Stübner: > Am Samstag, 24. November 2012, 10:01:31 schrieb Alexander Varnin: > > I've done it within another function, because otherwise users of other > > chips would pay for a one more runtime check, which they don't need. On > > the other hand, this function get called not so frequently, to make it > > valueable. The first version of my patch i've used internally worked as > > you said, so i can resend it. > > that would be cool, because as you said, this function isn't called this > often and adding another function here seems kinda counter-productive to > all the consolidation effort. > > Your could even do a > > #ifdef CONFIG_CPU_S3C2443 > if (samsung_cpu_id == ...) > the fix > #endif or alternatively introduce a soc_is_s3c2443 macro (plat- samsung/include/plat/cpu.h) for the conditional, like the other Samsung SoCs have. if (soc_is_s3c2443()) the fix If done like the other SoCs, it would evaluate to 0, when CONFIG_CPU_S3C2443 is not set and otherwise check the cpu_id. > so only people building multi-platform kernels will be affected. > > > I want to ask more experienced users of s3c2443. If this problem occures > > on all s3c2443 chips, or only with some series of it? Maybe we need some > > more checks, not to break working cases. > > Finding other s3c2443 mainline-users seems kinda hard - you're the first > one I see :-) . In all the things I did to the s3c2416 I tried to pull the > s3c2443 along (blindly) most of the time, because both SoCs are so similar > [0]. And during all the changes no-one ever complained or spoke up. > > > @Kgene do you have anybody near you, who can tell us if the problem of the > swapped EXTINT bits is common to all s3c2443 SoCs or how to identify > affected ones? > > > Heiko > > [0] for example, you should be able to use the s3c2416 cpufreq driver also > on the s3c2443, as the armdiv etc structure is the same. > > > 24.11.2012 04:16, Heiko Stübner пишет: > > >>> What does this do or what should it do? Also it gets calculated but > > >>> never used? > > >>> > > >>> And please use scripts/checkpatch.pl to verify your patch follows > > >>> coding guidelines, as this block is especially hard to read. > > > > > > So essentially register-reads somehow returned transformed data, but > > > the write is done according to the datasheet. > > > > > > > > > It would definitely be better to integrate it into the existing > > > _irqext_type function instead of introducing a second one. > > > > > > The cpu_id is present in the samsung_cpu_id var and the list of cpus > > > including the s3c2443 can be found in common.c. With this it would be > > > possible to identify when the irq code is run on a s3c2443 machine and > > > the original _irqext_type function could change the behaviour > > > accordingly. > > > > > > Not sure if it would make sense to introduce soc_is_s3c2443() etc > > > macros for this. > > > > > > And of course the actual block doing the transformation on read would > > > need a more elaborate comment on the why and how, because in 3 years > > > someone might not directly see what this does and why it was necessary. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |