20.07.2018 03:07, Andrew Jeffery wrote:
>> Andrew, can you start with a list that shows what you expect us to need
>> on our systems ?
>>
> Okay, our Witherspoon and Romulus platforms containing the ASPEED AST2500
> currently need the following tuneables exposed:
>
> From the SCU:
> - Debug UART e
Andrew, Benjamin, Rob,
Thanks for bringing up the set of patches and a great discussion.
After going through the thread I figured that I'd like to share a few
things we needed to hack when programming several BMC boards:
- Debug UART enable/mux
- Disable GPIO D/E passthrough (I think this is supp
On Fri, 2018-07-20 at 09:37 +0930, Andrew Jeffery wrote:
> >
> > Andrew, can you start with a list that shows what you expect us to need
> > on our systems ?
> >
>
> Okay, our Witherspoon and Romulus platforms containing the ASPEED AST2500
> currently need the following tuneables exposed:
>
>
>
> Andrew, can you start with a list that shows what you expect us to need
> on our systems ?
>
Okay, our Witherspoon and Romulus platforms containing the ASPEED AST2500
currently need the following tuneables exposed:
>From the SCU:
- Debug UART enable
- VGA DAC mux
- VGA scratch registers 0-
On Thu, 2018-07-19 at 11:58 +0930, Andrew Jeffery wrote:
> > > I agree
> > > that not using /dev/mem is a good thing, but there are several ways
> > > you could do that independent of any DT binding.
> >
> > Such as ? The only other option is to have one or more kernel drivers
> > that have built-
> > I agree
> > that not using /dev/mem is a good thing, but there are several ways
> > you could do that independent of any DT binding.
>
> Such as ? The only other option is to have one or more kernel drivers
> that have built-in the precise and complete list of those tunables that
> need to be
On Thu, 19 Jul 2018, at 04:37, Rob Herring wrote:
> On Tue, Jul 17, 2018 at 5:28 PM Andrew Jeffery wrote:
> >
> > On Tue, 17 Jul 2018, at 14:26, Benjamin Herrenschmidt wrote:
> > > On Mon, 2018-07-16 at 07:55 -0600, Rob Herring wrote:
> > > > If that data is one set per SoC, then i'm not that conc
On Wed, 2018-07-18 at 13:50 -0600, Rob Herring wrote:
>
> > So Rob, I think that's precisely where the disconnect is.
> >
> > I think we all (well hopefully) agree that those few tunables don't fit
> > in any existing subystem and aren't likely to ever do (famous last
> > words...).
> >
> > Wher
On Mon, Jul 16, 2018 at 10:56 PM Benjamin Herrenschmidt
wrote:
>
> On Mon, 2018-07-16 at 07:55 -0600, Rob Herring wrote:
> > If that data is one set per SoC, then i'm not that concerned having
> > platform-specific data in the driver. That doesn't mean the driver is
> > not "generic". It's still n
On Tue, Jul 17, 2018 at 5:28 PM Andrew Jeffery wrote:
>
> On Tue, 17 Jul 2018, at 14:26, Benjamin Herrenschmidt wrote:
> > On Mon, 2018-07-16 at 07:55 -0600, Rob Herring wrote:
> > > If that data is one set per SoC, then i'm not that concerned having
> > > platform-specific data in the driver. Tha
On Tue, 17 Jul 2018, at 14:26, Benjamin Herrenschmidt wrote:
> On Mon, 2018-07-16 at 07:55 -0600, Rob Herring wrote:
> > If that data is one set per SoC, then i'm not that concerned having
> > platform-specific data in the driver. That doesn't mean the driver is
> > not "generic". It's still not cl
On Mon, 2018-07-16 at 07:55 -0600, Rob Herring wrote:
> If that data is one set per SoC, then i'm not that concerned having
> platform-specific data in the driver. That doesn't mean the driver is
> not "generic". It's still not clear to me in this thread, how much of
> this is board specific, but g
On Mon, 16 Jul 2018, at 23:25, Rob Herring wrote:
> On Fri, Jul 13, 2018 at 12:31 AM Andrew Jeffery wrote:
> >
> > Hi Rob, Ben,
> >
> > I've replied to you both inline below, hopefully it's clear enough from the
> > context.
> >
> > On Fri, 13 Jul 2018, at 10:25, Benjamin Herrenschmidt wrote:
> >
On Fri, Jul 13, 2018 at 12:31 AM Andrew Jeffery wrote:
>
> Hi Rob, Ben,
>
> I've replied to you both inline below, hopefully it's clear enough from the
> context.
>
> On Fri, 13 Jul 2018, at 10:25, Benjamin Herrenschmidt wrote:
> > On Thu, 2018-07-12 at 09:11 -0600, Rob Herring wrote:
> > > On We
Hi Alexander,
I've rearranged your reply slightly :)
On Sat, 14 Jul 2018, at 00:44, Alexander Amelkin wrote:
>
> So I'm writing this to support your position in this discussion and to
> let Rob and other reviewers know that this feature is actually needed.
Thanks.
So to summarise some other r
+ my vote as Nuvoton's BMC FW provider.
On Fri, Jul 13, 2018 at 10:07 PM wrote:
>
> >> Dell - Internal Use - Confidential
> >Really? To a public mailing list? odd...
>
> Ha yea sorry - I was so excited to show my support, that I jumped the gun :)
>
>> Dell - Internal Use - Confidential
>Really? To a public mailing list? odd...
Ha yea sorry - I was so excited to show my support, that I jumped the gun :)
On Fri, Jul 13, 2018 at 06:49:04PM +, eugene@dell.com wrote:
> Dell - Internal Use - Confidential
Really? To a public mailing list? odd...
l.org; Greg Kroah-Hartman; Cho, Eugene;
linux-kernel@vger.kernel.org; Joel Stanley; stew...@linux.ibm.com; OpenBMC
Maillist; moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
Subject: Re: [RFC PATCH v2 1/4] dt-bindings: misc: Add bindings for misc. BMC
control fields
Andrew, Ben, first o
Andrew, Ben, first of all let me thank you for bringing in this set of
patches.
From the discussion it looks to me like Rob is not familiar with
specifics of BMC-managed servers and tries to apply to them the rules
that have proven to be good for workstations and laptops.
As someone using /dev/me
Hi Rob, Ben,
I've replied to you both inline below, hopefully it's clear enough from the
context.
On Fri, 13 Jul 2018, at 10:25, Benjamin Herrenschmidt wrote:
> On Thu, 2018-07-12 at 09:11 -0600, Rob Herring wrote:
> > On Wed, Jul 11, 2018 at 6:54 PM Andrew Jeffery wrote:
> > >
> > > Hi Rob,
>
On Thu, 2018-07-12 at 09:11 -0600, Rob Herring wrote:
> On Wed, Jul 11, 2018 at 6:54 PM Andrew Jeffery wrote:
> >
> > Hi Rob,
> >
> > Thanks for the response.
> >
> > On Thu, 12 Jul 2018, at 05:34, Rob Herring wrote:
> > > On Wed, Jul 11, 2018 at 03:01:19PM +0930, Andrew Jeffery wrote:
> > > >
On Wed, Jul 11, 2018 at 6:54 PM Andrew Jeffery wrote:
>
> Hi Rob,
>
> Thanks for the response.
>
> On Thu, 12 Jul 2018, at 05:34, Rob Herring wrote:
> > On Wed, Jul 11, 2018 at 03:01:19PM +0930, Andrew Jeffery wrote:
> > > Baseboard Management Controllers (BMCs) are embedded SoCs that exist to
> >
Hi Rob,
Thanks for the response.
On Thu, 12 Jul 2018, at 05:34, Rob Herring wrote:
> On Wed, Jul 11, 2018 at 03:01:19PM +0930, Andrew Jeffery wrote:
> > Baseboard Management Controllers (BMCs) are embedded SoCs that exist to
> > provide remote management of (primarily) server platforms. BMCs are
On Wed, 2018-07-11 at 14:04 -0600, Rob Herring wrote:
> On Wed, Jul 11, 2018 at 03:01:19PM +0930, Andrew Jeffery wrote:
> > Baseboard Management Controllers (BMCs) are embedded SoCs that exist to
> > provide remote management of (primarily) server platforms. BMCs are
> > often tightly coupled to th
On Wed, Jul 11, 2018 at 03:01:19PM +0930, Andrew Jeffery wrote:
> Baseboard Management Controllers (BMCs) are embedded SoCs that exist to
> provide remote management of (primarily) server platforms. BMCs are
> often tightly coupled to the platform in terms of behaviour and provide
> many hardware f
26 matches
Mail list logo