lkml.org 
[lkml]   [2006]   [Nov]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRFC - platform device, IRQs and SoC devices
Hi there.

Im working on some SoC type devices attached to the system bus of my ARM
devboard in an isa-like way.

The devices are small SoC (System On Chip) types, with one IRQ routed to
the half dozen (sub)devices on board the SoC.

At present, I am using a platform driver for the 'core' which handles
IRQ routing and device enumeration, and is currently passing the IRQ to
be used by the subdevices in a struct resource (along with two or three
IOMEM resources).

this, however means that the subdevice resource definitions must be
copied in order that the IRQ field can be set dynamically.

One solution would be for there to be a method by which the subdevice
can query the SoC core device for the base of its IRQ range, which would
allow the subdevice data to be declared as a constant and not copied.
This makes the declaration of the subdevices in the main driver very
neat and compact.

can this be done with a 'platform device' or is this simply not possible?

the real problem seems (to me) to be that struct resource is held as an
array. If it were a linked list, then I could hold all but the subdevice
IRQ in const data and simply 'tack on' a single dynamically created IRQ
resource to it.

I propose that a 'next' field be added to the struct resource. All
existing code could remain the same for now, and continue to work,
whilst newer device drivers could use the next-> field to taverse the
list rather than treat it as an array.

if all 'linked' entries come before 'array style' ones, then the
num_resources field would change to mean 'num_array_style_resources' and
the last 'linked' type resource would point to the head of the array.
The traversal routines would simply count the array offset from the
first 'array style' entry (with a NULL next field) or, if num_resources
is not set, assume all resources are linked, and the NULL ends the list
of resources.

This would allow for both statically allocated const arrays of struct
resource as we use now, and dynamically allocated resources, or a mix of
both for the few weird cases like my problem above.

Summary:

add struct resource *next; to struct resource.
rename num_resources as resource_array_len to indicate it only counts
the number of resources listed in an array
allow resources to be added dynamically by altering the pointer to the
firts resource and using that resources next pointer to point to the old
list head (OR) the old array head.

possible enhancements:

get_first_resource() - return first resource added, making it easy to
locate the first array type entry (if present)
remove_resource() - obvious, but perhaps not very useful.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-11-21 17:11    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site