2009-09-22 10:35:39     Need help on hardware resource management.

Document created by Aaronwu Employee on Aug 19, 2013
Version 1Show Document
  • View in full screen mode

2009-09-22 10:35:39     Need help on hardware resource management.

V Hemanth Kumar (INDIA)

Message: 80248   




In our BF527 custom design we have both LCD and camera connected to PPI (PORTF).

The lcd is SHARP LQ035 and camera is OV9655.


All PPI lines is availabe on PORTF and is muxed with other functionalities like TIMER, SPORT and UART.

In the distribution we have drivers like the char PPI driver, PPI FCD (Frame capture Device), timer, uart and SPORT drivers.


Out of these some request for the hardware resource in init() and some in open().

The lcd and camera drivers request for PPI from open() and init() from their respective code.


When all these drivers are built into the kernel and when we boot, the 1st driver reserves the resource on PORTF but

other drivers fails to initialize. This results in non-usability of other features of the hardware peripherals.



Is it a good idea to move the request for the hardware resource from init() into the open(). So that all the drivers boots fine during

kernel boot and the resource is allocated only in open(), applications accesses the device and in close() release the resource.


This way user can use the resource when the other is not required without recompiling the kernel again.

Example: If the user does not want LCD and camera he can use the UART and timer functionality of PORTF.


Is there a better way of doing the hardware resource management? Pls give us some idea so that we can acheive this feature.






2009-09-22 10:44:46     Need help on hardware resource management.

Michael Hennerich (GERMANY)

Message: 80250    IMHO - all initialization should be in init.

I know there are people who think differently.


The issue you're experiencing is a typical issue when people build

multifunction development boards.


The workaround is to build drivers as modules. Then load and unload

drivers that have conflicting peripheral use cases.