UART Route setting

[Patrick Venture]

+kunyi@

PTAL - I know we're looking for a way to move the hacks forward
properly, a driver or driver(s) is apparently already in the works,
albeit with upstream resistance.

Patrick

On Fri, Aug 3, 2018 at 3:03 PM, Andrew Jeffery <andrew at aj.id.au> wrote:
>
>
> On Sat, 4 Aug 2018, at 00:29, Patrick Venture wrote:
>> On Wed, Aug 1, 2018 at 8:33 PM, Andrew Jeffery <andrew at aj.id.au> wrote:
>> > On Thu, 2 Aug 2018, at 12:50, Oskar Senft wrote:
>> >> Interesting suggestion, that looks promising, thank you?
>> >>
>> >> What's the state of that driver? I.e. where do we expect it to land?
>> >
>> > If you think the bmc-misc-ctrl series is useful, please reply to the
>> > upstream thread to outline all of your use-cases. There's a lot of push-
>> > back on using the devicetree to describe these features, and I haven't
>> > had a lot of feedback on the acceptability of the rest (driver itself,
>> > userspace ABI).
>> >
>> > The more evidence we have of this being necessary/useful the better.
>>
>> I just skimmed that message, and we're looking for a mechanism to set
>> in the kernel some bits in the hwstrapping and other hardware
>> registers to do things like restrict P2A ranges, disable lpc2ahb
>> stuff, etc.  Things we had hacked into the mach-aspeed.c (iirc), and I
>> wasn't sure it made sense to write a half dozen small drivers to
>> control these individual things -- would these kind of use cases fall
>> under this misc driver?
>
> Yes, everything you listed there was a strong motivation for the series.
>
> Cheers
>
> Andrew