not yet , we just sample hardware , we need fixed some issus ,and updtate hardware design,when ready ,will send sample out , now ,just frank got the sample version hardware.
Thanks, received board yesterday.
Can you give me the serial settings for debug-uart? the settings i tried seem not correct (got only garbage in minicom)
Edit: seems to be like rockchip has fixed setting of 1.5mbaud and my cp2102 does not support it,so i have ordered a cp2104
https://wiki.t-firefly.com/en/ROC-RK3328-PC/debug.html#choosing-a-usb-serial-adapter
do you have a shematic? i will need one to discuss with rockchip-people…currently discussing change of vccio6-supply which is 1v8 in evb, but 3v3 in your bsp.
which are differences to ref-board? so i can use evb-dts as base for r2pro and change only things needed
CH340 is much better
What can be done without a schematic though 
new sample ready:
I guess 2 typos:
- hdmi in (should be out)
- usb-otg is named debug-uart.
Is mt7531 same as on r64 (only used port 5 with rgmii)? Would be nice if some more devs get the board.
Is rtc/reset now working? Any other changes like iodomain? Just want to be sure no damage happens if using my/your current config.
Would be nice to have the sw1 (for disabling emmc) reachable from outside (like power/reset).
1,yes,it is HDMI out 2,it use USB to uart ,not USB-otg , we use a USB-3.0 to burn .(top of 2 use 3.0 interface)
yes ,it is same as BPI-R64, but dirive need some time to do .
when we finished this hardware test ,can send sample to you ,thank you.
Thanks,i have previous version and imho makes more sense that other devs can test too.
Was iodomain changed?
adding switch driver should be no big part as most part is mainline.if using p5 rgmii init is ready to,imho only ethsys/mtk bindung needs to be reworked.
Send sample.
Looking forward to run opnsense on this minux MTK driver
Banana Pi BPI-R2 Pro Public sale,
Wow nice and I still waiting for development sample. Good luck.
have you fixed the headphone-detection? in my version this pin is always gnd/0 so microphone does not switch to the headset one
hi Frank,
please refer to the below,
rk_headset: rk-headset {
status = "okay";
compatible = "rockchip_headset";
headset_gpio = <&gpio3 RK_PC2 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&hp_det>;
io-channels = <&saradc 2>; //HP_HOOK pin
};
… … &pinctrl { headphone { hp_det: hp-det { rockchip,pins = <3 RK_PC2 RK_FUNC_GPIO &pcfg_pull_up>; }; };
… …
hi Frank, Maybe you need enable internal pull-up
&pinctrl { headphone { hp_det: hp-det { rockchip,pins = <3 RK_PC2 RK_FUNC_GPIO &pcfg_pull_up>; }; };
Already tried pullup and read out gpio (without mapping to soundcard)…always 0
rockchip_headset
Is no valid upstream compatible. Downstream it is in
drivers/headset_observe/rockchip_headset_core.c:180: { .compatible = "rockchip_headset", },
this driver seems to read out gpio (looks like only as busy-indicator) then adc and then gpio again in rk_headset_irq_hook_adc.c/hook_work_callback
i’m not sure if the gpio is only some kind of hw-interrupt to trigger the adc-read, but at least for this there is no mainline driver, and porting this driver is much work for this small functionality
from hw view:
Adc works but gpio does not (alone). Have not found a way in upstream to use adc for mic switch
@zuowei8 can you explain how it should work? is the gpio a hw-interrupt to trigger the adc-read? maybe i can write a simpler driver to archive the same
have added the rk_headset driver to my 5.19-hdmi-tree, but it seems not triggering the mic-change, used same settings in dts like in bsp
root@bpi-r2pro:~# zgrep 'HEADSET' /proc/config.gz
CONFIG_RK_HEADSET=y
root@bpi-r2pro:~# uname -a
Linux bpi-r2pro 5.19.0-rc1-bpi-r2pro-r2pro-hdmi #1 SMP PREEMPT Wed Jun 15 15:07x
root@bpi-r2pro:~#
i see this messages, but it seems driver still does not switch mic to headset
root@bpi-r2pro:~# dmesg | grep -i headset
[ 1.251395] rockchip_headset rk-headset: Can not read property hook_gpio
[ 1.251456] rockchip_headset rk-headset: headset have hook adc mode
[ 1.251623] input: rk-headset as /devices/platform/rk-headset/input/input1
[ 1.413881] headset_interrupt:get pin level again, pin=114,i=0
[ 1.413887] (headset in is high level)headset status is in
any idea? on plugging in/out i see headset_interrupt messages in dmesg, but evtest does not show any change…and maybe i need to map this event to also somehow in userspace
root@bpi-r2pro:~# evtest /dev/input/event1
Input driver version is 1.0.1
Input device ID: bus 0x0 vendor 0x1 product 0x1 version 0x100
Input device name: "rk-headset"
Supported events:
Event type 0 (EV_SYN)
Event type 1 (EV_KEY)
Event code 226 (KEY_MEDIA)
Properties:
Testing ... (interrupt to exit)
[ 423.194007] headset_interrupt:get pin level again, pin=114,i=0
[ 426.034037] headset_interrupt:get pin level again, pin=114,i=0
edit: get it so far:
[ 127.406051] (headset in is high level)headset status is in
[ 127.610050] hook_once_work read adc value: 1023
[ 127.610307] hook_once_work notice android headset status = 1
[ 127.714012] DEBUG: hook_work_callback 329
...
[ 131.874090] hook_work_callback read adc value=1023
[ 131.874111] HOOK status is up , adc value = 1023 hook_time = 100
[ 131.874125] Hook adc read old_status == headset->hook_status=0 hook_time = 100
[ 131.929130] In the headset_interrupt
[ 131.978009] DEBUG: hook_work_callback 329
[ 131.978088] hook_work_callback read adc value=1023
[ 131.978100] Headset is out or waiting for headset is in or out, after same time check HOOK key
[ 132.086063] headset_interrupt:get pin level again, pin=114,i=0
[ 132.086063] headset_interrupt:get pin level again, pin=114,i=0
[ 132.086091] (headset in is high level)headset status is out
[ 132.086218] headset notice android headset status = 0
means driver recognizes the change, but mic is not switched yet to headphone…i see in driver there is some reference to an extcon_* and imho input-device should change too…currently debugging
HEADSET_OUT should set input device in headset_interrupt and !=HEADSET_OUT in hook_work_callback
inout device ist not updated because headset->hook_status is always HOOK_UP, i’m not sure whats the reasing for HOOK-STATUS, but is is set only to down in hook_work_callback which is not called if headset is removed. looks for me redundant with headset_info->headset_status = [HEADSET_IN,HEADSET_OUT]
1 Like