docs: remove resource management references

The code referenced was removed back in 2009.

Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>

1 files changed, 0 insertions, 168 deletions

diff --git a/hw/xfree86/doc/ddxDesign.xml b/hw/xfree86/doc/ddxDesign.xml
index becb0c2c5..367844136 100644
--- a/hw/xfree86/doc/ddxDesign.xml
+++ b/hw/xfree86/doc/ddxDesign.xml
@@ -1108,16 +1108,6 @@ Here is what <function>InitOutput()</function> does:
 	    </para>
 
 	    <para>
-      All additional resources that the screen needs must be registered
-      here.  This should be done with
-      <function>xf86RegisterResources()</function>.  If some of the fixed
-      resources registered in the Probe phase are not needed or not
-      decoded by the hardware when in the OPERATING server state, their
-      status should be updated with
-      <function>xf86SetOperatingState()</function>.
-	    </para>
-
-	    <para>
       Modules may be loaded at any point in this function, and all
       modules that the driver will need must be loaded before the end
       of this function.  Either the  <function>xf86LoadSubModule()</function>
@@ -2601,20 +2591,6 @@ available at the driver level:
 
 	  <blockquote><para>
 	      <programlisting>
-    void xf86ClaimFixedResources(resList list, int entityIndex);
-	      </programlisting>
-	      <blockquote><para>
-      This function registers the non-relocatable resources which cannot
-      be disabled and which therefore would cause the server to fail
-      immediately if they were found to conflict.  It also records
-      non-relocatable but sharable resources for processing after the
-      <function>Probe()</function> phase.
-		</para>
-
-	      </blockquote></para></blockquote>
-
-	  <blockquote><para>
-	      <programlisting>
     void xf86AddEntityToScreen(ScrnInfoPtr pScrn, int entityIndex);
 	      </programlisting>
 	      <blockquote><para>
@@ -2692,52 +2668,6 @@ Several functions are provided to simplify resource registration:
 	      </blockquote></para></blockquote>
 	</para>
 
-	<para>
-The primary function for registration of resources is:
-	  <blockquote><para>
-	      <programlisting>
-    resPtr xf86RegisterResources(int entityIndex, resList list,
-                                 int access);
-	      </programlisting>
-	      <blockquote><para>
-      This function tries to register the resources in
-      <parameter>list</parameter>.  If list is <constant>NULL</constant> it tries
-      to determine the resources automatically.  This only works for
-      entities that provide a generic way to read out the resource ranges
-      they decode.  So far this is only the case for PCI devices.  By
-      default the PCI resources are registered as shared
-      (<constant>ResShared</constant>) if the driver wants to set a different
-      access type it can do so by specifying the access flags in the
-      third argument.  A value of <constant>0</constant> means to use the
-      default settings.  If for any reason the resource broker is not
-      able to register some of the requested resources the function will
-      return a pointer to a list of the failed ones.  In this case the
-      driver may be able to move the resource to different locations.
-      In case of PCI bus entities this is done by passing the list of
-      failed resources to <function>xf86ReallocatePciResources()</function>.
-      When the registration succeeds, the return value is
-      <constant>NULL</constant>.
-		</para>
-
-	      </blockquote></para></blockquote>
-	  </para>
-
-	<blockquote><para>
-	    <programlisting>
-    resPtr xf86ReallocatePciResources(int entityIndex, resPtr pRes);
-	    </programlisting>
-	    <blockquote><para>
-      This function takes a list of PCI resources that need to be
-      reallocated and returns <constant>NULL</constant> when all relocations are
-      successful.
-      <function>xf86RegisterResources()</function> should be called again to
-      register the relocated resources with the broker.
-      If the reallocation fails, a list of the resources that could not be
-      relocated is returned.
-	      </para>
-
-	    </blockquote></para></blockquote>
-
 <para>
 Two functions are provided to obtain a resource range of a given type:
 	  <blockquote><para>
@@ -2796,93 +2726,6 @@ Two functions are provided to obtain a resource range of a given type:
 	</para>
 
 	<para>
-The driver may replace the generic access control functions for an entity.
-This is done with the <function>xf86SetAccessFuncs()</function>:
-	  <blockquote><para>
-	      <programlisting>
-    void xf86SetAccessFuncs(EntityInfoPtr pEnt,
-                            xf86SetAccessFuncPtr funcs,
-                            xf86SetAccessFuncPtr oldFuncs);
-	      </programlisting>
-     with:
-	      <programlisting>
-      typedef struct {
-          xf86AccessPtr mem;
-          xf86AccessPtr io;
-          xf86AccessPtr io_mem;
-      } xf86SetAccessFuncRec, *xf86SetAccessFuncPtr;
-	      </programlisting>
-	      <blockquote><para>
-      The driver can pass three functions: one for I/O access, one for
-      memory access and one for combined memory and I/O access.  If the
-      memory access and combined access functions are identical the
-      common level assumes that the memory access cannot be controlled
-      independently of I/O access, if the I/O access function and the
-      combined access functions are the same it is assumed that I/O can
-      not be controlled independently.  If memory and I/O have to be
-      controlled together all three values should be the same.  If a
-      non <constant>NULL</constant> value is passed as third argument it is
-      interpreted as an address where to store the old access record.
-      If the third argument is <constant>NULL</constant> it will be assumed
-      that the generic access should be enabled before replacing the
-      access functions.  Otherwise it will be disabled.  The driver may
-      enable them itself using the returned values.  It should do this
-      from its replacement access functions as the generic access may
-      be disabled by the common level on certain occasions.  If replacement
-      functions are specified they must control all resources of the
-      specific type registered for the entity.
-		</para>
-
-	      </blockquote></para></blockquote>
-	</para>
-
-	<para>
-To find out if a specific resource range conflicts with another
-resource the <function>xf86ChkConflict()</function> function may be used:
-	  <blockquote><para>
-	      <programlisting>
-    memType xf86ChkConflict(resRange *rgp, int entityIndex);
-	      </programlisting>
-	      <blockquote><para>
-      This function checks if the resource range <parameter>rgp</parameter> of
-      for the specified entity conflicts with with another resource.
-      If a conflict is found, the address of the start of the conflict
-      is returned.  The return value is zero when there is no conflict.
-		</para>
-
-	      </blockquote></para></blockquote>
-	</para>
-
-	<para>
-The OPERATING state properties of previously registered fixed resources
-can be set with the <function>xf86SetOperatingState()</function> function:
-	  <blockquote><para>
-	      <programlisting>
-    resPtr xf86SetOperatingState(resList list, int entityIndex,
-                                 int mask);
-	      </programlisting>
-	      <blockquote><para>
-      This function is used to set the status of a resource during
-      OPERATING state.  <parameter>list</parameter> holds a list to which
-      <parameter>mask</parameter> is to be applied.  The parameter
-      <parameter>mask</parameter> may have the value <constant>ResUnusedOpr</constant>
-      and <constant>ResDisableOpr</constant>.  The first one should be used
-      if a resource isn't used by the driver during OPERATING state
-      although it is decoded by the device, while the latter one indicates
-      that the resource is not decoded during OPERATING state.  Note
-      that the resource ranges have to match those specified during
-      registration.  If a range has been specified starting at
-      <literal remap="tt">A</literal> and ending at <literal remap="tt">B</literal> and suppose
-      <literal remap="tt">C</literal> us a value satisfying
-      <literal remap="tt">A&nbsp;&lt;&nbsp;C&nbsp;&lt;&nbsp;B</literal> one may not
-      specify the resource range <literal remap="tt">(A,B)</literal> by splitting it
-      into two ranges <literal remap="tt">(A,C)</literal> and <literal remap="tt">(C,B)</literal>.
-		</para>
-
-	      </blockquote></para></blockquote>
-	</para>
-
-	<para>
 The following two functions are provided for special cases:
 	  <blockquote><para>
 	      <programlisting>
@@ -2896,17 +2739,6 @@ The following two functions are provided for special cases:
 		</para>
 
 	      </blockquote></para></blockquote>
-
-	  <blockquote><para>
-	      <programlisting>
-    void xf86DeallocateResourcesForEntity(int entityIndex, long type);
-	      </programlisting>
-	      <blockquote><para>
-      This function deallocates all resources of a given type registered
-      for a certain entity from the resource broker list.
-		</para>
-
-	      </blockquote></para></blockquote>
 	</para>
 
       </sect3>