Re: [PATCH] ARM: S3C2443: Workaround for 2443 EXTINT error

["Heiko Stübner" <heiko@sntech.de>]

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

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.