gpio_blink_set + Kirkwood

Tibor Harsszegi tibor at harsszegi.com
Thu Jul 11 14:52:08 EDT 2013


On 2013-07-11 20:37, Jason Cooper wrote:
> On Thu, Jul 11, 2013 at 08:32:42PM +0200, Tibor Harsszegi wrote:
>>> On Thu, Jul 11, 2013 at 06:20:02PM +0200, Tibor Harsszegi wrote:
>>>> Hello guys,
>>>>
>>>> can anyone explain me how does the gpio_blink_set member gets filled
>>>> in leds-gpio through platform_get_drvdata()?
>>>> I can't seem to follow how the specific function pointer can be set
>>>> to orion_gpio_set_blink() for example.
>>>> Sorry for the dumb question :(
>>> Hi Tibor
>>>
>>> For DT based board, hardware blinking is not supported, as far as i
>>> remember.
>>>
>>> 	Andrew
>> Hello Andrew,
>>
>> is there an example for "mixed machine setup" (if there is anything
>> like that) ?
>> I'm thinking about:
>>
>> * DT based initialization starts
>> * then if supported board based "after-DT-init-board-code" executes
>>
>> similar what we have in board-*.c files just that it would be
>> executed after kirkwood has initialized the board
>> based upon the .DTB
>> [I'm thinking about getting rid of the LED setup from the .DTB and
>> move it back to .C land - at least for a trial]
> As a testing hack, just add the following to board-dt.c:
>
> 	if (of_machine_is_compatible("keymile,whizbang-board")) {
> 		/* GPIO hackery here */
> 	}
>
> hth,
>
> Jason.
Ok, but isn't board-dt.c is the very first thing (kinda) which is 
executed prior the .DTB is parsed
and executed?
E.g. if I add the GPIO hack there, I assume that kirkwood and orion is 
already initialized.
Or is the board-dt.c executed after the .DTB is loaded/parsed?
Thanks,



More information about the linux-arm-kernel mailing list