public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Jeremy Linton" <jeremy.linton@arm.com>
To: Ard Biesheuvel <ard.biesheuvel@arm.com>, devel@edk2.groups.io
Cc: leif@nuviainc.com, pete@akeo.ie, samer.el-haj-mahmoud@arm.com,
	awarkentin@vmware.com, philmd@redhat.com
Subject: Re: [PATCH 2/3] Platform/RaspberryPi/Acpitables: Add eMMC2 device and tweak Arasan
Date: Fri, 8 Jan 2021 10:27:24 -0600	[thread overview]
Message-ID: <11f288a0-aab8-bdca-de7e-b3a4bb9f1469@arm.com> (raw)
In-Reply-To: <89f1a21a-0435-3986-0420-c20a6b397c1b@arm.com>

Hi,

On 1/8/21 2:28 AM, Ard Biesheuvel wrote:
> On 1/8/21 7:16 AM, Jeremy Linton wrote:
>> The primarly problem with the rpi Arasan controller working
>> with a default SDHCI driver is the lack of a meaningful
>> capabilities register. As such if we add a _DSD entry
>> to provide that information, we can then bind it to
>> the linux sdhci_iproc driver which already
>> hardcodes the remaining controller bugs.
>>
>> Further we have gotten BRCME88C approved as the HID
>> for the newer eMMC2 controller. So lets define an
>> ACPI object to describe it.
>>
>> Of course both devices are sharing an interrupt so
>> we should also indicate that in the table as well.
>>
>> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
>> ---
>>   Platform/RaspberryPi/AcpiTables/Dsdt.asl |  2 +
>>   Platform/RaspberryPi/AcpiTables/Sdhc.asl | 86 +++++++++++++++++++++++++++++++-
>>   2 files changed, 86 insertions(+), 2 deletions(-)
>>
>> diff --git a/Platform/RaspberryPi/AcpiTables/Dsdt.asl b/Platform/RaspberryPi/AcpiTables/Dsdt.asl
>> index d116f965e1..cca08c0539 100644
>> --- a/Platform/RaspberryPi/AcpiTables/Dsdt.asl
>> +++ b/Platform/RaspberryPi/AcpiTables/Dsdt.asl
>> @@ -150,6 +150,7 @@ DefinitionBlock ("Dsdt.aml", "DSDT", 5, "RPIFDN", "RPI", 2)
>>             QWORDMEMORYBUF(23)
>>             QWORDMEMORYBUF(24)
>>             QWORDMEMORYBUF(25)
>> +          QWORDMEMORYBUF(26)
>>           })
>>   
>>           // USB
>> @@ -196,6 +197,7 @@ DefinitionBlock ("Dsdt.aml", "DSDT", 5, "RPIFDN", "RPI", 2)
>>           // SDC
>>           QWORDMEMORYSET(24, MMCHS1_OFFSET, MMCHS1_LENGTH)
>>           QWORDMEMORYSET(25, SDHOST_OFFSET, SDHOST_LENGTH)
>> +        QWORDMEMORYSET(26, MMCHS2_OFFSET, MMCHS2_LENGTH)
>>   
>>           Return (RBUF)
>>         }
>> diff --git a/Platform/RaspberryPi/AcpiTables/Sdhc.asl b/Platform/RaspberryPi/AcpiTables/Sdhc.asl
>> index 0ab1ba27f2..a7ac831066 100644
>> --- a/Platform/RaspberryPi/AcpiTables/Sdhc.asl
>> +++ b/Platform/RaspberryPi/AcpiTables/Sdhc.asl
>> @@ -19,7 +19,7 @@
>>   // Note: UEFI can use either SDHost or Arasan. We expose both to the OS.
>>   //
>>   
>> -// ArasanSD 3.0 SD Host Controller.
>> +// ArasanSD 3.0 SD Host Controller. (brcm,bcm2835-sdhci)
>>   Device (SDC1)
>>   {
>>     Name (_HID, "BCM2847")
>> @@ -37,7 +37,7 @@ Device (SDC1)
>>     Name (RBUF, ResourceTemplate ()
>>     {
>>       MEMORY32FIXED (ReadWrite, 0, MMCHS1_LENGTH, RMEM)
>> -    Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive) { BCM2836_MMCHS1_INTERRUPT }
>> +    Interrupt (ResourceConsumer, Level, ActiveHigh, Shared) { BCM2836_MMCHS1_INTERRUPT }
>>     })
>>     Method (_CRS, 0x0, Serialized)
>>     {
>> @@ -45,6 +45,86 @@ Device (SDC1)
>>       Return (^RBUF)
>>     }
>>   
>> +  // The standard CAPs registers on this controller
>> +  // appear to be 0, lets set some minimal defaults
>> +  // Since this cap doesn't indicate DMA capability
>> +  // we don't need a _DMA()
>> +  Name (_DSD, Package () {
>> +    ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
>> +    Package () {
>> +      Package () { "sdhci-caps", 0x0100fa81 },
>> +    }
>> +  })
>> +
>> +
>> +  //
>> +  // A child device that represents the
>> +  // sd card, which is marked as non-removable.
>> +  //
>> +  Device (SDMM)
>> +  {
>> +    Method (_ADR)
>> +    {
>> +      Return (0)
>> +    }
>> +    Method (_RMV) // Is removable
>> +    {
>> +      Return (0) // 0 - fixed
>> +    }
>> +  }
>> +}
>> +
>> +#if (RPI_MODEL == 4)
>> +// emmc2 Host Controller. (brcm,bcm2711-emmc2)
>> +Device (SDC3)
>> +{
>> +  Name (_HID, "BRCME88C")
>> +  Name (_UID, 0x1)
>> +  Name (_CCA, 0x0)
>> +  Name (_S1D, 0x1)
>> +  Name (_S2D, 0x1)
>> +  Name (_S3D, 0x1)
>> +  Name (_S4D, 0x1)
>> +  Method (_STA)
>> +  {
>> +    Return(0xf)
>> +  }
>> +  Name (RBUF, ResourceTemplate ()
>> +  {
>> +    MEMORY32FIXED (ReadWrite, 0, MMCHS2_LENGTH, RMEM)
>> +    Interrupt (ResourceConsumer, Level, ActiveHigh, Shared) { BCM2836_MMCHS1_INTERRUPT }
>> +  })
>> +  Method (_CRS, 0x0, Serialized)
>> +  {
>> +    MEMORY32SETBASE (RBUF, RMEM, RBAS, MMCHS2_OFFSET)
>> +    Return (^RBUF)
>> +  }
>> +
>> +  // forceably limit to 1G
>> +  Name (_DMA, ResourceTemplate() {
>> +    QWordMemory (ResourceConsumer,
>> +      ,
>> +      MinFixed,
>> +      MaxFixed,
>> +      NonCacheable,
>> +      ReadWrite,
>> +      0x0,
>> +      0x0,        // MIN
>> +      0x3fffffff, // MAX
>> +      0x0,        // TRA
>> +      0x40000000, // LEN
>> +      ,
>> +      ,
>> +    )
>> +  })
>> +
> 
> Shouldn't the _DMA method be on a container object instead of on the
> device object itself?

Pained cough... There is a _DMA on the gpu devs container of which this 
device belongs. That doesn't make the DMA work. The spec says that _DMA 
is to exist on the bus device, and I think what is happening here is 
that the "device" is the SDMM (which isn't directly visible because of 
the way diff broke this patch up) contained in the "SDC3 mmc bus".

Frankly, I could be wrong, but what I do know is that without that bit 
of ugliness DMA doesn't work in linux on this controller. I just 
stripped it out again to verify the failure with 4.11. It does the same 
thing, the controller itself seems to be working but the block device 
associated with it can't be read. There are few other possibilities 
(like maybe this controller shouldn't be a gpudevs child) and i'm fixing 
a bug I created..I had kernel instrumentation in 5.9 tracking the dma 
mask propagation, and I was fairly confident in this a couple months 
ago, less so now.



> 
> 
>> +  Name (_DSD, Package () {
>> +    ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
>> +    Package () {
>> +      Package () { "sdhci-caps-mask", 0x0000000000080000 },
>> +    }
>> +  })
>> +
>>     //
>>     // A child device that represents the
>>     // sd card, which is marked as non-removable.
>> @@ -62,6 +142,7 @@ Device (SDC1)
>>     }
>>   }
>>   
>> +#else // !RPI4
>>   
>>   // Broadcom SDHost 2.0 SD Host Controller
>>   Device (SDC2)
>> @@ -105,3 +186,4 @@ Device (SDC2)
>>       }
>>     }
>>   }
>> +#endif // !RPI4
>>
> 


  reply	other threads:[~2021-01-08 16:27 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-08  6:16 [PATCH 0/3] Rpi: SD/Wifi Acpi updates Jeremy Linton
2021-01-08  6:16 ` [PATCH 1/3] Platform/RaspberryPi/Acpitables: Further lower the DMA zone Jeremy Linton
2021-01-11  8:50   ` Ard Biesheuvel
2021-01-11 14:58     ` Andrei Warkentin
2021-01-08  6:16 ` [PATCH 2/3] Platform/RaspberryPi/Acpitables: Add eMMC2 device and tweak Arasan Jeremy Linton
2021-01-08  8:28   ` Ard Biesheuvel
2021-01-08 16:27     ` Jeremy Linton [this message]
2021-01-09 14:09       ` [edk2-devel] " Mark Kettenis
2021-01-10 11:53         ` Mark Kettenis
2021-01-11  1:45         ` Jeremy Linton
2021-01-12 18:48           ` Mark Kettenis
2021-01-11  5:59         ` Jeremy Linton
2021-01-08  6:16 ` [PATCH 3/3] Platform/RaspberryPi; Invert default Arasan, Emmc2 routing Jeremy Linton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=11f288a0-aab8-bdca-de7e-b3a4bb9f1469@arm.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox