Re: [DISCUSSION] Hexagon code inside kernel

[cotulla@yandex.ua]

>
> šOne of the worst design errors in that code is that base addresses
> šwere made into compile-time constants, and then, to add serious injury
> što insult, a lot of complicated macros were written to obtain various
> šrelative offsets. šThe problem being that the hexagon uses exactly the
> šsame offsets, but just different base addresses -- and they're
> šrun-time configurable, e.g. by bootloader or by device tree. šDevice
> štree support for hexagon was planned, not sure about ARM.
>
for me it's normal to have hardcoded base addresses. it's not so bad.
I am talking about more general problems like useless code or code without enough data checks in my opinion.


Hexagon has same addresses for most shared devices except the private ones - like timers and second level interrupt controller.
For example, I am using exactly same base address for USB and it works.

> šI had started work on this, but I don't remember that I ever got it
> šclean enough to submit upstream. šThat plus the fact that interrupt
> šrouting was different: šhexagon has both second and third-level
> šinterrupt controllers, with ethernet being on a third-level
> šcontroller. šI'd gotten much/most of the 2nd-level code done, and some
> šof the 3rd-level code done, and I think its in the mainline kernel
> šnow, although I remember planning to do some more simplification and
> šcleanup.
Hm it seems dependent from SoC.
In QDS8250B there are two second level interrupt controllers (SIRC)
In common it can handle (32 - 2) + 2 * 32 interrupts.
I already got SIRC to work and receive USB interrupts without problems.

> šYes, that sounds right. šSorry, forgot about that.
> šHmm. Either that or volatile needs to be added to the upstream
> šdrivers: this is an issue for a variety of arches, not just hexagon.
> šCertainly powerpc treats treats uncached and i/o access in a very
> šdifferent way than memory access, and if you don't do it right, life
> šwill be painful.
Probably. It's just a thing which should be extremely careful looked during low level development for Hexagon - I am already few times was "catched" by that rule :-P


-Cotulla