[RFC] Secure Digital Host Controller PCI class

[RFC] Secure Digital Host Controller PCI class

[Pierre Ossman]

I'm working on a driver for the Secure Digital Host Controller
interface. This is a generic interface, so it uses a PCI class for
identification instead of vendor/device ids.

The class ID used is 0805 and the programming interface (correct term?)
indicates DMA capabilities. Greg, since you're the PCI maintainer,
perhaps you have the possibility of checking this ID?

The standard also dictates a register at offset 0x40 in PCI space. This
is a one byte register detailing the number of slots on the controller
and the first BAR to use.

The driver isn't ready yet (I'm aiming for 2.6.16) but this is the PCI
related patch I'd like committed further on:


diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -68,6 +68,7 @@
 #define PCI_CLASS_SYSTEM_TIMER         0x0802
 #define PCI_CLASS_SYSTEM_RTC           0x0803
 #define PCI_CLASS_SYSTEM_PCI_HOTPLUG   0x0804
+#define PCI_CLASS_SYSTEM_SDHCI         0x0805
 #define PCI_CLASS_SYSTEM_OTHER         0x0880

 #define PCI_BASE_CLASS_INPUT           0x09
diff --git a/include/linux/pci_regs.h b/include/linux/pci_regs.h
--- a/include/linux/pci_regs.h
+++ b/include/linux/pci_regs.h
@@ -108,6 +108,9 @@
 #define PCI_INTERRUPT_PIN      0x3d    /* 8 bits */
 #define PCI_MIN_GNT            0x3e    /* 8 bits */
 #define PCI_MAX_LAT            0x3f    /* 8 bits */
+#define PCI_SLOT_INFO          0x40    /* 8 bits */
+#define  PCI_SLOT_INFO_SLOTS(x)        ((x >> 4) & 7)
+#define  PCI_SLOT_INFO_FIRST_BAR_MASK  0x07

 /* Header type 1 (PCI-to-PCI bridges) */
 #define PCI_PRIMARY_BUS                0x18    /* Primary bus number */

Re: [RFC] Secure Digital Host Controller PCI class

[Greg KH]

On Mon, Nov 21, 2005 at 12:45:40PM +0100, Pierre Ossman wrote:
> I'm working on a driver for the Secure Digital Host Controller
> interface. This is a generic interface, so it uses a PCI class for
> identification instead of vendor/device ids.
> 
> The class ID used is 0805 and the programming interface (correct term?)
> indicates DMA capabilities. Greg, since you're the PCI maintainer,
> perhaps you have the possibility of checking this ID?

What do you mean "checking this ID"?  Checking it with what?

> The standard also dictates a register at offset 0x40 in PCI space. This
> is a one byte register detailing the number of slots on the controller
> and the first BAR to use.

Do you have a pointer to the standard?

thanks,

greg k-h

Re: [RFC] Secure Digital Host Controller PCI class

[Pierre Ossman]

Greg KH wrote:

>On Mon, Nov 21, 2005 at 12:45:40PM +0100, Pierre Ossman wrote:
>  
>
>>I'm working on a driver for the Secure Digital Host Controller
>>interface. This is a generic interface, so it uses a PCI class for
>>identification instead of vendor/device ids.
>>
>>The class ID used is 0805 and the programming interface (correct term?)
>>indicates DMA capabilities. Greg, since you're the PCI maintainer,
>>perhaps you have the possibility of checking this ID?
>>    
>>
>
>What do you mean "checking this ID"?  Checking it with what?
>
>  
>

I figured you might have access to the official allocations from the PCI
SIG.

>>The standard also dictates a register at offset 0x40 in PCI space. This
>>is a one byte register detailing the number of slots on the controller
>>and the first BAR to use.
>>    
>>
>
>Do you have a pointer to the standard?
>
>  
>

The SDHC standard itself is a well guarded secret. We're basing this
work on the little information that is out there and reverse engineering
the Windows driver. The PCI registers are described in a spec. by Texas
Instruments though:

http://www-s.ti.com/sc/ds/pci6411.pdf

They only use three bits for each field (since their controller only has
three slots), but the Windows driver reads four so that is what I've put
in the patch.

Rgds
Pierre

Re: [RFC] Secure Digital Host Controller PCI class

[Greg KH]

On Tue, Nov 22, 2005 at 07:07:18AM +0100, Pierre Ossman wrote:
> Greg KH wrote:
> 
> >On Mon, Nov 21, 2005 at 12:45:40PM +0100, Pierre Ossman wrote:
> >  
> >
> >>I'm working on a driver for the Secure Digital Host Controller
> >>interface. This is a generic interface, so it uses a PCI class for
> >>identification instead of vendor/device ids.
> >>
> >>The class ID used is 0805 and the programming interface (correct term?)
> >>indicates DMA capabilities. Greg, since you're the PCI maintainer,
> >>perhaps you have the possibility of checking this ID?
> >>    
> >>
> >
> >What do you mean "checking this ID"?  Checking it with what?
> >
> >  
> >
> 
> I figured you might have access to the official allocations from the PCI
> SIG.

I do have access to the PCI specs from the SIG website by virtue of my
current employer, not by any recognition by the PCI-SIG that Linux is
important at all...

If you let me know what document you think this might be in, I'll dig
around to see if I can find it.

> >>The standard also dictates a register at offset 0x40 in PCI space. This
> >>is a one byte register detailing the number of slots on the controller
> >>and the first BAR to use.
> >>    
> >>
> >
> >Do you have a pointer to the standard?
> >
> >  
> >
> 
> The SDHC standard itself is a well guarded secret. We're basing this
> work on the little information that is out there and reverse engineering
> the Windows driver. The PCI registers are described in a spec. by Texas
> Instruments though:
> 
> http://www-s.ti.com/sc/ds/pci6411.pdf
> 
> They only use three bits for each field (since their controller only has
> three slots), but the Windows driver reads four so that is what I've put
> in the patch.

Nice, thanks for the link.

But how about I wait to add your patch, until you submit your driver
that needs that change?  At that time I'll be glad to add it.

thanks,

greg k-h

Re: [RFC] Secure Digital Host Controller PCI class

[Pierre Ossman]

Greg KH wrote:
>
> I do have access to the PCI specs from the SIG website by virtue of my
> current employer, not by any recognition by the PCI-SIG that Linux is
> important at all...
>
> If you let me know what document you think this might be in, I'll dig
> around to see if I can find it.
>
>   

It's difficult to tell what is inside each document without being a
member. But this sounds promising:

Appendix D -- Class codes updates
<http://www.pcisig.com/members/downloads/specifications/conventional/appd_latest.pdf>
(61k PDF)
http://www.pcisig.com/members/downloads/specifications/conventional/appd_latest.pdf

> Nice, thanks for the link.
>
> But how about I wait to add your patch, until you submit your driver
> that needs that change?  At that time I'll be glad to add it.
>
>   

That was the idea. I just wanted to get comments early on. This part
will probably not change so I might as well have it reviewed now.

Rgds
Pierre

Re: [RFC] Secure Digital Host Controller PCI class

[Pierre Ossman]

Pierre Ossman wrote:
> Greg KH wrote:
>> I do have access to the PCI specs from the SIG website by virtue of my
>> current employer, not by any recognition by the PCI-SIG that Linux is
>> important at all...
>>
>> If you let me know what document you think this might be in, I'll dig
>> around to see if I can find it.
>>
>>   
> 
> It's difficult to tell what is inside each document without being a
> member. But this sounds promising:
> 
> Appendix D -- Class codes updates
> <http://www.pcisig.com/members/downloads/specifications/conventional/appd_latest.pdf>
> (61k PDF)
> http://www.pcisig.com/members/downloads/specifications/conventional/appd_latest.pdf
> 

Greg, have you had time to have a look at this? Just a reminder in case 
you forgot (and before I do as well). :)

Rgds
Pierre

Re: [RFC] Secure Digital Host Controller PCI class

[Pierre Ossman]

Pierre Ossman wrote:
> Pierre Ossman wrote:
> 
>> Greg KH wrote:
>>
>>> I do have access to the PCI specs from the SIG website by virtue of my
>>> current employer, not by any recognition by the PCI-SIG that Linux is
>>> important at all...
>>>
>>> If you let me know what document you think this might be in, I'll dig
>>> around to see if I can find it.
>>>
>>>   
>>
>>
>> It's difficult to tell what is inside each document without being a
>> member. But this sounds promising:
>>
>> Appendix D -- Class codes updates
>> <http://www.pcisig.com/members/downloads/specifications/conventional/appd_latest.pdf>
>>
>> (61k PDF)
>> http://www.pcisig.com/members/downloads/specifications/conventional/appd_latest.pdf
>>
>>
> 
> Greg, have you had time to have a look at this? Just a reminder in case
> you forgot (and before I do as well). :)
> 

*poke again*