On Thu, 2015-02-19 at 19:38 +0200, Pantelis Antoniou wrote:
Having to boot and tweak the bootloader settings to select the correct
dtb (even if it’s present on the flash medium) takes time and is
error-prone.
Dedicate a set of GPIO for board/PCB revision detection (it only costs a
few
On Thu, 2015-02-19 at 19:12 +0100, Sylvain Rochet wrote:
Or use a 1-wire or I2C EEPROM to store your board information.
no, you don't reduce the human error probability.
eeprom needs to be preprogrammed, factory will at some point have a lot
of eeprom with different version, and will
On Thu, 2013-10-24 at 10:52 +0100, Grant Likely wrote:
At this point if the hardware exists then it should be described in DTB,
even if it is merely compatible, reg, interrupts and maybe clocks
if your driver does not use them, chances are you'll get them wrong.
properties. In many cases
On Thu, 2013-10-24 at 12:47 +0100, David Woodhouse wrote:
If you can automatically infer the correct clock/interrupt/etc in order
to do DMA correctly, despite the fact that it wasn't explicitly spelled
out in the old DT, then the property is *not* a required property.
It's optional, and you
On Thu, 2013-10-24 at 14:23 +0200, Thierry Reding wrote:
To me it sounds more like the sensible default would be to continue to
run with PIO support if the optional properties needed for DMA support
are not present.
huge leap backward
- need to maintain test two completely different code
On Thu, 2013-10-24 at 12:22 +, David Woodhouse wrote:
If you are correct to insist that DMA needs yo be supported in the new
driver *even* with old firmware, then yes, maybe.
if DMA gives a performance boost for all workloads, what is the argument
for not always enabling it ?
The
On Thu, 2013-10-24 at 13:10 +, David Woodhouse wrote:
Note that you are not describing a normal DT scenario here. You are
describing a case in which we screwed up
AKA real world
So yes, after the public flogging has happened, and we're trying to
work out how best to cope with the
On Thu, 2013-10-24 at 13:14 +, David Woodhouse wrote:
If DMA gives a performance boost for all workloads, what bloody idiot
defined or reviewed a DT binding that didn't include the information which
who defined it:
- hobbyist programmer without DMA knowledge
- hobbyist programmer
On Thu, 2013-10-24 at 16:19 +0200, Thierry Reding wrote:
We treated DT the same way we had treated platform data before, which
has inevitable lead to the current mess, which is only slightly better
than what we used to have.
Side question, in your point of view, how is that better ?
On Wed, 2013-10-23 at 20:51 +0200, Richard Cochran wrote:
I have no problem with new kernel features unlocked by new DT
bindings.
I *do* have a problem with new kernels breaking existing DT bindings.
well this assume the new feature does not need modifying an existing
binding.
again
On Mon, 2013-10-21 at 11:15 +0200, Thierry Reding wrote:
A stable ABI means there's about zero chance of redesigning something
after it's been merged. Unless we want to live with having to support
several DT bindings in a driver.
That will happen for sure, and it will suffer from lack of
11 matches
Mail list logo
