On Tue, Aug 04, 2015 at 12:09:52PM +0200, Martin Sperl wrote: > On 04.08.2015 11:54, Mark Brown wrote: > >Why would these things be configured in the device tree in the first > >place? They don't look like things that should be device tree > >properties, they look like something the kernel should figure out at > >runtime - the system tuning may change as the kernel evolves or > >depending on userspace needs. > Sometimes it may be necessary to define different values than the > "kernel" thinks may be necessary (hardcoded). So improve the kernel or (if you're really desparate) provide runtime configuration - if you're just randomly bashing on things you can rebuild the kernel just as well as the DT. We don't want random magic number performance tuning becoming an ABI, that way if the kernel changes we're stuck with trying to work with the old magic numbers even if they no longer work or perform well. > We just had one issue with fbtft devices where it would have been > nice to change those values on a per device basis (even if it was > just for some testing to see why it was behaving badly > - see the still un-merged patch: > "spi: bcm2835: set up spi-mode before asserting cs-gpio"). I'm not finding that patch particularly enlightening here, sorry... can you be more explicit please? > So I was wondering what was feasible/acceptable. There are properties that might make sense on a per device basis like descriptions of which chip select to use in the hardware, it's just that these don't seem like such properties.
Attachment:
signature.asc
Description: Digital signature
