Hi Matthias,
>
> Did you made any progress on the DT part?
>
I have not made much progress on DT part yet.
> Regards,
> Matthias
Hi Matthias,
>
> Did you made any progress on the DT part?
>
I have not made much progress on DT part yet.
> Regards,
> Matthias
Hi Brijesh,
On 18/03/16 19:36, Brijesh Singh wrote:
Hi Tejun,
On 03/17/2016 12:36 PM, Arnd Bergmann wrote:
On Wednesday 16 March 2016 14:07:13 Tejun Heo wrote:
Hello, Arnd.
On Mon, Feb 01, 2016 at 09:14:17PM +0100, Arnd Bergmann wrote:
I am not debating on your AML call recommendation, it
Hi Brijesh,
On 18/03/16 19:36, Brijesh Singh wrote:
Hi Tejun,
On 03/17/2016 12:36 PM, Arnd Bergmann wrote:
On Wednesday 16 March 2016 14:07:13 Tejun Heo wrote:
Hello, Arnd.
On Mon, Feb 01, 2016 at 09:14:17PM +0100, Arnd Bergmann wrote:
I am not debating on your AML call recommendation, it
On Thu, Jan 14, 2016 at 10:31:11AM -0600, Brijesh Singh wrote:
> AMD Seattle SATA controller mostly conforms to AHCI interface with some
> special register to control SGPIO interface. In the case of an AHCI
> controller, the SGPIO feature is ideally implemented using the
> "Enclosure Management"
On Thu, Jan 14, 2016 at 10:31:11AM -0600, Brijesh Singh wrote:
> AMD Seattle SATA controller mostly conforms to AHCI interface with some
> special register to control SGPIO interface. In the case of an AHCI
> controller, the SGPIO feature is ideally implemented using the
> "Enclosure Management"
Hello, Arnd.
On Mon, Feb 01, 2016 at 09:14:17PM +0100, Arnd Bergmann wrote:
>> I am not debating on your AML call recommendation, it sounds like
>> a good idea however BIOS is already released hence its bit late to
>> add AML methods for this. I am seeking guidance on what can be
>> done in the
Hello, Arnd.
On Mon, Feb 01, 2016 at 09:14:17PM +0100, Arnd Bergmann wrote:
>> I am not debating on your AML call recommendation, it sounds like
>> a good idea however BIOS is already released hence its bit late to
>> add AML methods for this. I am seeking guidance on what can be
>> done in the
Hi Tejun,
On 01/26/2016 03:36 AM, Hans de Goede wrote:
> Hi,
>
> On 25-01-16 21:43, Tejun Heo wrote:
>> On Thu, Jan 14, 2016 at 10:31:11AM -0600, Brijesh Singh wrote:
>>> AMD Seattle SATA controller mostly conforms to AHCI interface with some
>>> special register to control SGPIO interface. In
Hi Tejun,
On 01/26/2016 03:36 AM, Hans de Goede wrote:
> Hi,
>
> On 25-01-16 21:43, Tejun Heo wrote:
>> On Thu, Jan 14, 2016 at 10:31:11AM -0600, Brijesh Singh wrote:
>>> AMD Seattle SATA controller mostly conforms to AHCI interface with some
>>> special register to control SGPIO interface. In
Hi Tejun,
On 03/17/2016 12:36 PM, Arnd Bergmann wrote:
> On Wednesday 16 March 2016 14:07:13 Tejun Heo wrote:
>> Hello, Arnd.
>>
>> On Mon, Feb 01, 2016 at 09:14:17PM +0100, Arnd Bergmann wrote:
I am not debating on your AML call recommendation, it sounds like
a good idea however BIOS
Hi Tejun,
On 03/17/2016 12:36 PM, Arnd Bergmann wrote:
> On Wednesday 16 March 2016 14:07:13 Tejun Heo wrote:
>> Hello, Arnd.
>>
>> On Mon, Feb 01, 2016 at 09:14:17PM +0100, Arnd Bergmann wrote:
I am not debating on your AML call recommendation, it sounds like
a good idea however BIOS
On Wednesday 16 March 2016 14:07:13 Tejun Heo wrote:
> Hello, Arnd.
>
> On Mon, Feb 01, 2016 at 09:14:17PM +0100, Arnd Bergmann wrote:
> >> I am not debating on your AML call recommendation, it sounds like
> >> a good idea however BIOS is already released hence its bit late to
> >> add AML
On Wednesday 16 March 2016 14:07:13 Tejun Heo wrote:
> Hello, Arnd.
>
> On Mon, Feb 01, 2016 at 09:14:17PM +0100, Arnd Bergmann wrote:
> >> I am not debating on your AML call recommendation, it sounds like
> >> a good idea however BIOS is already released hence its bit late to
> >> add AML
Hello,
On Fri, Mar 18, 2016 at 01:36:40PM -0500, Brijesh Singh wrote:
> > It's your call in the end. My main objection is to the fact that
> > I have suggested a clean implementation for the normal DT based
> > path that also fixes existing platforms that used to work in the
> > past and were
Hello,
On Fri, Mar 18, 2016 at 01:36:40PM -0500, Brijesh Singh wrote:
> > It's your call in the end. My main objection is to the fact that
> > I have suggested a clean implementation for the normal DT based
> > path that also fixes existing platforms that used to work in the
> > past and were
Hi Arnd,
On 02/05/2016 11:23 AM, Brijesh Singh wrote:
> Hi,
>
>>> }
>>>
>>> Windows driver folks were okay to look at second resource field to map the
>>> SGPIO register and program the
>>> registers to blink the LEDs. I think as per ACPI spec, its legal to pass
>>> more than one block in
Hi Arnd,
On 02/05/2016 11:23 AM, Brijesh Singh wrote:
> Hi,
>
>>> }
>>>
>>> Windows driver folks were okay to look at second resource field to map the
>>> SGPIO register and program the
>>> registers to blink the LEDs. I think as per ACPI spec, its legal to pass
>>> more than one block in
Hi,
>> }
>>
>> Windows driver folks were okay to look at second resource field to map the
>> SGPIO register and program the
>> registers to blink the LEDs. I think as per ACPI spec, its legal to pass
>> more than one block in resource
>> template and since AML method is not mandatory for non
On Tuesday 02 February 2016 12:37:58 Brijesh Singh wrote:
> Hi,
>
> On 02/02/2016 08:08 AM, Arnd Bergmann wrote:
> > On Monday 01 February 2016 16:15:59 Brijesh Singh wrote:
> >>>
> >>> This is where we really need the ACPI maintainers to explain the
> >>> general policy for dealing with firmware
On Tuesday 02 February 2016 12:37:58 Brijesh Singh wrote:
> Hi,
>
> On 02/02/2016 08:08 AM, Arnd Bergmann wrote:
> > On Monday 01 February 2016 16:15:59 Brijesh Singh wrote:
> >>>
> >>> This is where we really need the ACPI maintainers to explain the
> >>> general policy for dealing with firmware
Hi,
>> }
>>
>> Windows driver folks were okay to look at second resource field to map the
>> SGPIO register and program the
>> registers to blink the LEDs. I think as per ACPI spec, its legal to pass
>> more than one block in resource
>> template and since AML method is not mandatory for non
Hi,
On 02/02/2016 08:08 AM, Arnd Bergmann wrote:
> On Monday 01 February 2016 16:15:59 Brijesh Singh wrote:
>>>
>>> This is where we really need the ACPI maintainers to explain the
>>> general policy for dealing with firmware updates.
>>>
>>> I would assume that adding the feature in a later
On Monday 01 February 2016 16:15:59 Brijesh Singh wrote:
> >
> > This is where we really need the ACPI maintainers to explain the
> > general policy for dealing with firmware updates.
> >
> > I would assume that adding the feature in a later firmware version
> > is a compatible change, and the
Hi,
On 02/02/2016 08:08 AM, Arnd Bergmann wrote:
> On Monday 01 February 2016 16:15:59 Brijesh Singh wrote:
>>>
>>> This is where we really need the ACPI maintainers to explain the
>>> general policy for dealing with firmware updates.
>>>
>>> I would assume that adding the feature in a later
On Monday 01 February 2016 16:15:59 Brijesh Singh wrote:
> >
> > This is where we really need the ACPI maintainers to explain the
> > general policy for dealing with firmware updates.
> >
> > I would assume that adding the feature in a later firmware version
> > is a compatible change, and the
Hi,
>
> This is where we really need the ACPI maintainers to explain the
> general policy for dealing with firmware updates.
>
> I would assume that adding the feature in a later firmware version
> is a compatible change, and the feature is non-essential (the
> device will work fine with the
On Monday 01 February 2016 12:56:06 Brijesh Singh wrote:
> On 01/29/2016 03:22 PM, Arnd Bergmann wrote:
> >
> > For the ACPI case, I still think that an AML call from the AHCI driver
> > is the most logical solution. You mentioned that you believe that calling
> > into the AML interpreter up to
Hi Arnd,
On 01/29/2016 03:22 PM, Arnd Bergmann wrote:
>
> For the ACPI case, I still think that an AML call from the AHCI driver
> is the most logical solution. You mentioned that you believe that calling
> into the AML interpreter up to 100 times per second is a noticeable
> overhead, but I
Hi Arnd,
On 01/29/2016 03:22 PM, Arnd Bergmann wrote:
>
> For the ACPI case, I still think that an AML call from the AHCI driver
> is the most logical solution. You mentioned that you believe that calling
> into the AML interpreter up to 100 times per second is a noticeable
> overhead, but I
On Monday 01 February 2016 12:56:06 Brijesh Singh wrote:
> On 01/29/2016 03:22 PM, Arnd Bergmann wrote:
> >
> > For the ACPI case, I still think that an AML call from the AHCI driver
> > is the most logical solution. You mentioned that you believe that calling
> > into the AML interpreter up to
Hi,
>
> This is where we really need the ACPI maintainers to explain the
> general policy for dealing with firmware updates.
>
> I would assume that adding the feature in a later firmware version
> is a compatible change, and the feature is non-essential (the
> device will work fine with the
> For the ACPI case, I still think that an AML call from the AHCI driver
> is the most logical solution. You mentioned that you believe that calling
> into the AML interpreter up to 100 times per second is a noticeable
> overhead, but I doubt that and would like to see actual number backing
> that
On Tuesday 26 January 2016 10:56:20 Brijesh Singh wrote:
>
> On 01/26/2016 06:17 AM, Arnd Bergmann wrote:
> >
> > I think it needs more work: The changelog describes it as a normal
> > driver, but based on the previous discussion, this is just a hack
> > to work around broken BIOS versions that
> For the ACPI case, I still think that an AML call from the AHCI driver
> is the most logical solution. You mentioned that you believe that calling
> into the AML interpreter up to 100 times per second is a noticeable
> overhead, but I doubt that and would like to see actual number backing
> that
On Tuesday 26 January 2016 10:56:20 Brijesh Singh wrote:
>
> On 01/26/2016 06:17 AM, Arnd Bergmann wrote:
> >
> > I think it needs more work: The changelog describes it as a normal
> > driver, but based on the previous discussion, this is just a hack
> > to work around broken BIOS versions that
Hi Arnd,
On 01/26/2016 06:17 AM, Arnd Bergmann wrote:
>
> I think it needs more work: The changelog describes it as a normal
> driver, but based on the previous discussion, this is just a hack
> to work around broken BIOS versions that can no longer be fixed in
> the field, and there has not
On Monday 25 January 2016 15:43:00 Tejun Heo wrote:
> On Thu, Jan 14, 2016 at 10:31:11AM -0600, Brijesh Singh wrote:
> > AMD Seattle SATA controller mostly conforms to AHCI interface with some
> > special register to control SGPIO interface. In the case of an AHCI
> > controller, the SGPIO feature
Hi,
On 25-01-16 21:43, Tejun Heo wrote:
On Thu, Jan 14, 2016 at 10:31:11AM -0600, Brijesh Singh wrote:
AMD Seattle SATA controller mostly conforms to AHCI interface with some
special register to control SGPIO interface. In the case of an AHCI
controller, the SGPIO feature is ideally
Hi,
On 25-01-16 21:43, Tejun Heo wrote:
On Thu, Jan 14, 2016 at 10:31:11AM -0600, Brijesh Singh wrote:
AMD Seattle SATA controller mostly conforms to AHCI interface with some
special register to control SGPIO interface. In the case of an AHCI
controller, the SGPIO feature is ideally
On Monday 25 January 2016 15:43:00 Tejun Heo wrote:
> On Thu, Jan 14, 2016 at 10:31:11AM -0600, Brijesh Singh wrote:
> > AMD Seattle SATA controller mostly conforms to AHCI interface with some
> > special register to control SGPIO interface. In the case of an AHCI
> > controller, the SGPIO feature
Hi Arnd,
On 01/26/2016 06:17 AM, Arnd Bergmann wrote:
>
> I think it needs more work: The changelog describes it as a normal
> driver, but based on the previous discussion, this is just a hack
> to work around broken BIOS versions that can no longer be fixed in
> the field, and there has not
On Thu, Jan 14, 2016 at 10:31:11AM -0600, Brijesh Singh wrote:
> AMD Seattle SATA controller mostly conforms to AHCI interface with some
> special register to control SGPIO interface. In the case of an AHCI
> controller, the SGPIO feature is ideally implemented using the
> "Enclosure Management"
On Thu, Jan 14, 2016 at 10:31:11AM -0600, Brijesh Singh wrote:
> AMD Seattle SATA controller mostly conforms to AHCI interface with some
> special register to control SGPIO interface. In the case of an AHCI
> controller, the SGPIO feature is ideally implemented using the
> "Enclosure Management"
Hi Tejun,
Ping ?
-Brijesh
On 01/14/2016 10:31 AM, Brijesh Singh wrote:
> AMD Seattle SATA controller mostly conforms to AHCI interface with some
> special register to control SGPIO interface. In the case of an AHCI
> controller, the SGPIO feature is ideally implemented using the
> "Enclosure
Hi Tejun,
Ping ?
-Brijesh
On 01/14/2016 10:31 AM, Brijesh Singh wrote:
> AMD Seattle SATA controller mostly conforms to AHCI interface with some
> special register to control SGPIO interface. In the case of an AHCI
> controller, the SGPIO feature is ideally implemented using the
> "Enclosure
46 matches
Mail list logo
