- User Since
- Jun 4 2014, 6:42 AM (372 w, 6 d)
Wed, Jul 21
@wulf , I considered that well. But if we use a dedicate taskqueue then it means having a thread anyway. And I didnd't want to put potentially slow LED operations on one of the global taskqueues.
Mon, Jul 19
@adrian , in my opinion two things guarantee correct operation:
- the current element can never be removed (thanks to in_use)
- an iteration is always done with the lock held
So, whatever perturbations might happen while the lock is dropped, they should settle down before the next iteration.
@adrian , I thought that I took care of that via the in_use flag.
Could you please look again?
Yeah, me too... but doing it directly from a callout puts a lot of restrictions.
I considered creating and destroying the thread dynamically as "blinkers" are added and removed.
I can implement that if you think it would be better than having the thread permanently.
Tested this with D30787 where LEDs are controlled via I²C and had no issues with turning the LEDs on / off and making then blink in various combinations and sequences.
No crashes, no LORs, no WITNESS warnings.
Mon, Jul 12
Jun 21 2021
I cannot think of any way.
rk_i2c needs to sleep to wait for an interrupt.
led(8) uses a non-sleepable mutex.
Jun 18 2021
Jun 17 2021
address reviews for rk805 poweroff support
Jun 16 2021
Jun 9 2021
May 31 2021
May 21 2021
May 7 2021
May 6 2021
May 5 2021
The only reason is that I thought that I could do some things better but never got around to actually working on them.
Specifically, I don't like having so many walk+callback patterns. Especially for _DSD.
I hoped that I would be able to represent it as an nvlist or something similar.
@mm , do you have amdgpio driver? Has it attached?
May 3 2021
Apr 15 2021
@kibab , you still may want to fix this pseudo-loop: https://github.com/kibab/freebsd/blob/mmccam-current/sys/cam/mmc/mmc_da.c#L1638
Maybe the last 'else' was supposed to be 'else if' ?
I think that I needed that patch because earlier I had a lot of bits from https://github.com/kibab/freebsd/tree/mmccam-current in my tree and now I don't.
Specifically, @kibab's mmc_set_timing supports a lot more timings and so on.
And in fact, it seems that I do not need that change anymore.
Apr 14 2021
Yes, most likely.
Is this the information you asked for?
# camcontrol devlist -v scbus0 on aw_mmc_sim0 bus 0: scbus1 on aw_mmc_sim1 bus 0: <SDIO card> at scbus1 target 0 lun 0 (sdiob0,pass1) scbus2 on aw_mmc_sim2 bus 0: <MMCHC 8GME4R 0.1 SN 4DAD8E5D MFG 09/200> at scbus2 target 0 lun 0 (sdda0,pass0) scbus-1 on xpt0 bus 0: <> at scbus-1 target -1 lun ffffffff (xpt0)
Mar 31 2021
LGTM. Thank you!
Mar 23 2021
Mar 5 2021
Feb 18 2021
Jan 20 2021
LGTM. Thank you!
I did not realize that hardware can be this quirky.
Jan 19 2021
Dec 18 2020
Dec 13 2020
Dec 11 2020
Dec 10 2020
It's been a while since I touched that kind of code, but I think that this change is good.
Dec 3 2020
Oct 28 2020
Oct 19 2020
Oct 16 2020
Oct 12 2020
Oct 7 2020