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
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
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
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
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:
>
>
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
>
> 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
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
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
> > 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
> > 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
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
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...).
> >
> >
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...).
> >
> >
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
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
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.
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.
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
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
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
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
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 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
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
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
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
+ 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 :)
>
+ 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 :)
>> 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...
On Fri, Jul 13, 2018 at 06:49:04PM +, eugene@dell.com wrote:
> Dell - Internal Use - Confidential
Really? To a public mailing list? odd...
; 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 of all
; 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 of all
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
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
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,
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 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
>
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
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
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
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
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
52 matches
Mail list logo
