Linux 5.9-rc1 Kernel Released - Line Count Dominated By AMD Radeon Navi 2 Additions

[intelfx]

The files are big because the chips have a lot of registers. We used to only IP review and release register info for the registers we were actually using (since IP review was so painful in the early days of the open source effort) but now IP review and release info for essentially all of the registers from the start, so that if the driver code needs to access a new register we don't have to go through another round of IP review. It does make the files bigger though.

If you don't mind, here's what I've always wondered... Why would a chip have significantly more registers than a (feature-complete) driver ends up using?

Does it mean that the driver does not make full use of available hardware features, or is otherwise limited in some regards? Or does it instead mean that the hardware is being designed with a vast array of mutually redundant/overlapping usecases in mind, some of which are never realized at all?

[mlau]

If you don't mind, here's what I've always wondered... Why would a chip have significantly more registers than a (feature-complete) driver ends up using?

Does it mean that the driver does not make full use of available hardware features, or is otherwise limited in some regards? Or does it instead mean that the hardware is being designed with a vast array of mutually redundant/overlapping usecases in mind, some of which are never realized at all?

Various bits to disable/bypass functions, test bits, status bits for silicon testing, ...

[bridgman]

If you don't mind, here's what I've always wondered... Why would a chip have significantly more registers than a (feature-complete) driver ends up using?

Does it mean that the driver does not make full use of available hardware features, or is otherwise limited in some regards? Or does it instead mean that the hardware is being designed with a vast array of mutually redundant/overlapping usecases in mind, some of which are never realized at all?

Two part answer:

#1 - in the early days of the open source graphics effort the drivers were not anywhere near feature complete

#2 - as mlau pointed out, a number of registers are there for debug and other troubleshooting activities - those may be set by the driver (golden settings) or by firmware

There are relatively few registers that are not used by some part of the FW/SW stack.

We could make the register headers a bit smaller by making a guess about which registers we would never want to access from the driver, but that gets us back into having to do incremental IP reviews every time we use a new register.

[nivedita]

One thing I don't quite understand is the need for so many of those autogenerated lines of code.

Intuitively I always think that if it can be autogenerated it could also be replaced by smart code that does the same thing in a more on-the-fly manner or dinamically on compile time?

Obviously this is a non-expert view and there must be a ton of perfectly reasonable motives for it, I'm just curious to how that goes and haven't bumped into a for-noobs version of the explanation yet.

Is this initially auto-generated then gradually tweaked, is there a limitation in the programming language in this case because it's about headers, would it kill performance if done on the fly, is it impossible to autogenerate on compile time?

I don't know about this case, but one consideration in general is what tools are required to generate it, since those are unlikely to be commonly installed. The choice is to either include the auto-generated output in the kernel tree, or you need to include the input, and also either put the tools in the kernel tree (increasing build time since you have to build the tools first) or require anyone who wants to compile that driver to download and install the tools.

[kripteks]

My vega cant overclock with this 5.9-rc1, same issue with all linux-next after 5.8.0.


In same time, i have also this:
# dmesg | grep dax
[ 2.912377] sda1: error: dax access failed (-95)
[ 2.913027] sda1: error: dax access failed (-95)
[ 2.913682] sda1: error: dax access failed (-95)
[ 2.914431] sda1: error: dax access failed (-95)
[ 2.915016] sda1: error: dax access failed (-95)
[ 2.915596] sda1: error: dax access failed (-95)

Sometimes my disk dont respond few second when i write text file with geany.

[pal666]

Intuitively I always think that if it can be autogenerated it could also be replaced by smart code that does the same thing in a more on-the-fly manner or dinamically on compile time?

they are autogenerated from large and non-open data(hardware).