On 09/09/2015 11:10 AM, Marc Zyngier wrote:
Jeremy,
I can see two issues here: we have a screaming interrupt, and
we seem to corrupt some workqueue.
How did you get this to work? Firmware release?
Marc,
I'm responding because its been a month or so since my last response,
and I haven't forg
On 10/6/2015 1:08 PM, David Woodhouse wrote:
On Mon, 2015-10-05 at 17:20 -0700, Charles Garcia-Tobin wrote:
it in ACPI circles
unless we had wider agreement among OSs to use it. AFAIK PRP1 has not
actually been approved yet in the specification forum, and that it in
itself is more of a conce
On Mon, 2015-10-05 at 17:20 -0700, Charles Garcia-Tobin wrote:
> it in ACPI circles
> unless we had wider agreement among OSs to use it. AFAIK PRP1 has not
> actually been approved yet in the specification forum, and that it in
> itself is more of a concern for me,as the code has been pushed up
On 01/10/2015 03:23, "a...@redhat.com" wrote:
>Adding Charles Garcia-Tobin from ARM
Thanks and sorry for chiming in late. You¹ve pretty much said it all, but
I had some comments. First one, is that if folk want to see what¹s
happening with the DSD process, then please join the dsd mailing li
Adding Charles Garcia-Tobin from ARM
On 09/25/2015 09:28 AM, Catalin Marinas wrote:
> On Thu, Sep 24, 2015 at 07:10:38PM +0100, David Woodhouse wrote:
>> On Thu, 2015-09-24 at 16:15 +0100, Catalin Marinas wrote:
>>> With "PRP0001", they can skip the _DSD properties review process (not
>>> that
On Fri, 2015-09-25 at 16:28 +0100, Catalin Marinas wrote:
>
> This only works as long as they target an existing driver with prior DT
> support (usually with reviewed bindings). If they have a new driver and
> only ACPI in mind, I'm pretty sure we'll end up with new insane things.
> That's why we
On 9/25/2015 5:28 PM, Catalin Marinas wrote:
On Thu, Sep 24, 2015 at 07:10:38PM +0100, David Woodhouse wrote:
On Thu, 2015-09-24 at 16:15 +0100, Catalin Marinas wrote:
With "PRP0001", they can skip the _DSD properties review process (not
that they bother much currently) as long as the existing
On Thu, Sep 24, 2015 at 07:10:38PM +0100, David Woodhouse wrote:
> On Thu, 2015-09-24 at 16:15 +0100, Catalin Marinas wrote:
> > With "PRP0001", they can skip the _DSD properties review process (not
> > that they bother much currently) as long as the existing DT support
> > covers their needs.
>
>
On Thu, 2015-09-24 at 16:15 +0100, Catalin Marinas wrote:
> With "PRP0001", they can skip the _DSD properties review process (not
> that they bother much currently) as long as the existing DT support
> covers their needs.
So no change there then. I take it the smsc911x bindings didn't go
through
On Thu, Sep 24, 2015 at 12:52:38PM +0100, David Woodhouse wrote:
> On Thu, 2015-09-24 at 11:31 +0100, Catalin Marinas wrote:
> > PRP0001 opens the door to any DT-like properties in ACPI and, knowing
> > how the ARM ecosystem works, I'm pretty sure we'll soon lose control (if
> > we haven't already;
On Thu, 2015-09-24 at 15:01 +0100, Lorenzo Pieralisi wrote:
> On Thu, Sep 24, 2015 at 12:52:38PM +0100, David Woodhouse wrote:
>
> [...]
>
> > And think about it... we *really* don't want a given peripheral device
> > to have *different* bindings depending on whether it's discovered with
> > a sp
On Thu, Sep 24, 2015 at 12:52:38PM +0100, David Woodhouse wrote:
[...]
> And think about it... we *really* don't want a given peripheral device
> to have *different* bindings depending on whether it's discovered with
> a specific ACPI HID, vs. when it's discovered via DT or the PRP0001
> HID. Tha
Hi Catalin,
I understand your concerns, but I'm still not convinced of your
conclusion.
On Thu, 2015-09-24 at 11:31 +0100, Catalin Marinas wrote:
> PRP0001 opens the door to any DT-like properties in ACPI and, knowing
> how the ARM ecosystem works, I'm pretty sure we'll soon lose control (if
> we
Hi Dave,
On Thu, Sep 24, 2015 at 09:16:19AM +0100, David Woodhouse wrote:
> On Wed, 2015-09-23 at 16:56 -0700, Hanjun Guo wrote:
> > It really depends on the people who writing the ASL code (DSDT),
> > I'm not sure if Windows will use _DSD and how to use it, but
> > firmware guys may just use the
On Wed, Sep 23, 2015 at 06:57:03PM +0100, Sudeep Holla wrote:
> On 23/09/15 18:22, Jeremy Linton wrote:
> >|FWIW, mainline booting with this patch on Juno r1 with ACPI enabled
> >dies a |horrible death:
> >
> >Sorry about the delay, I didn't see this message.
> >
> >
> >
> >|How did you get this to
On Wed, 2015-09-23 at 16:56 -0700, Hanjun Guo wrote:
>
> It really depends on the people who writing the ASL code (DSDT),
> I'm not sure if Windows will use _DSD and how to use it, but
> firmware guys may just use the device ID to make the firmware
> to be usable both by Linux and Windows, and tha
On 09/23/2015 02:03 PM, David Woodhouse wrote:
On Wed, 2015-09-23 at 22:51 +0200, Rafael J. Wysocki wrote:
But if the device ID is assigned already, why would it hurt to
actually use it?
It doesn't hurt at all, as long as we understand that there was no need
to assign it a device ID at all, a
On Wed, 2015-09-23 at 22:51 +0200, Rafael J. Wysocki wrote:
>
> But if the device ID is assigned already, why would it hurt to
> actually use it?
It doesn't hurt at all, as long as we understand that there was no need
to assign it a device ID at all, at least for Linux's benefit. And as
long as
On 9/23/2015 8:41 PM, David Woodhouse wrote:
On Wed, 2015-08-12 at 17:06 -0500, Jeremy Linton wrote:
+static const struct acpi_device_id smsc911x_acpi_match[] = {
+ { "ARMH9118", 0 },
+ { }
+};
+MODULE_DEVICE_TABLE(acpi, smsc911x_acpi_match);
+
static struct platform_driver smsc
On Wed, 2015-08-12 at 17:06 -0500, Jeremy Linton wrote:
>
>
> +static const struct acpi_device_id smsc911x_acpi_match[] = {
> + { "ARMH9118", 0 },
> + { }
> +};
> +MODULE_DEVICE_TABLE(acpi, smsc911x_acpi_match);
> +
> static struct platform_driver smsc911x_driver = {
> .prob
On 23/09/15 18:22, Jeremy Linton wrote:
Marc,
|FWIW, mainline booting with this patch on Juno r1 with ACPI enabled
dies a |horrible death:
Sorry about the delay, I didn't see this message.
|How did you get this to work? Firmware release?
Yes, it's a firmware problem with the ACPI tables.
On Wed, 23 Sep 2015 17:22:49 +
Jeremy Linton wrote:
Hi Jeremy,
> Marc,
>
> |FWIW, mainline booting with this patch on Juno r1 with ACPI enabled dies a
> |horrible death:
>
> Sorry about the delay, I didn't see this message.
>
>
>
> |How did you get this to work? Firmware release?
>
> Y
Marc,
|FWIW, mainline booting with this patch on Juno r1 with ACPI enabled dies a
|horrible death:
Sorry about the delay, I didn't see this message.
|How did you get this to work? Firmware release?
Yes, it's a firmware problem with the ACPI tables. It is likely you need _DSD
changes for the
Jeremy,
On 12/08/15 23:06, Jeremy Linton wrote:
> Add ACPI bindings for the smsc911x driver. Convert the DT specific calls
> to nonspecific device* calls, This allows the driver to work
> with both ACPI and DT configurations. Ethernet should now work when using
> ACPI on ARM Juno.
>
> Signed-off-
On Thu, Aug 13, 2015 at 10:38:38AM +0100, Graeme Gregory wrote:
> On Thu, Aug 13, 2015 at 10:01:17AM +0100, Lorenzo Pieralisi wrote:
> > On Thu, Aug 13, 2015 at 09:27:59AM +0100, Graeme Gregory wrote:
> > > On Wed, Aug 12, 2015 at 05:06:27PM -0500, Jeremy Linton wrote:
> > > > Add ACPI bindings for
On Thu, Aug 13, 2015 at 10:01:17AM +0100, Lorenzo Pieralisi wrote:
> On Thu, Aug 13, 2015 at 09:27:59AM +0100, Graeme Gregory wrote:
> > On Wed, Aug 12, 2015 at 05:06:27PM -0500, Jeremy Linton wrote:
> > > Add ACPI bindings for the smsc911x driver. Convert the DT specific calls
> > > to nonspecific
On Thu, Aug 13, 2015 at 09:27:59AM +0100, Graeme Gregory wrote:
> On Wed, Aug 12, 2015 at 05:06:27PM -0500, Jeremy Linton wrote:
> > Add ACPI bindings for the smsc911x driver. Convert the DT specific calls
> > to nonspecific device* calls, This allows the driver to work
> > with both ACPI and DT co
On Wed, Aug 12, 2015 at 05:06:27PM -0500, Jeremy Linton wrote:
> Add ACPI bindings for the smsc911x driver. Convert the DT specific calls
> to nonspecific device* calls, This allows the driver to work
> with both ACPI and DT configurations. Ethernet should now work when using
> ACPI on ARM Juno.
>
28 matches
Mail list logo
