Open hh opened 9 years ago
hh
commented
9 years ago @tingleby @arfoll is there some public facing github repo for work on the edison bsp? I've tried the https://communities.intel.com/community/makers/edison forum, but I'm not finding much there in regards to this type of integration.
I noticed you both worked for intel specifically on the iot-devkit and thought you might have some info on where the Intel Edison BSP repos / developers mailing list might be.
hh
commented
9 years ago @rexstjohn you've made some nice wiki's related to getting things up on the edison, have you looked into hid gadget stuff at all? or building a BSP with yoctol-linux-3.19?
arfoll
commented
9 years ago @hh sorry there are currently no Intel owned public git repositories for the edison BSPs for the time being. My apoligies. I'm not familiar enough with the edison kernel patchset to answer your question, asking on the Intel community forum is probably a good way to try get some attention.
hh
commented
9 years ago Here are the intel folks that have their email in the edison BSP patch. I don't want to reach out directly yet, but if anyone looking at this or the https://communities.intel.com/message/272533 forum post knows who on the list I should reach out to, or better yet just connect them to the post or this github issue. @rexstjohn
grep -rEiEio b[A-Z0-9._%+-]+@[A-Z0-9.-]+.[A-Z]2b ./linux-yocto-3.10/arch/x86/platform/intel-mid | sed s/.[hc]:/:/ | sort -u | grep intel.com grep -rEiEio b[A-Z0-9._%+-]+@[A-Z0-9.-]+.[A-Z]4b . | sed s/.[hc]:/:/ | sort -u | grep intel.com
./device_libs/platform_mrfl_ocd: saranya.gopal@intel.com
./device_libs/platform_mrfl_thermal: durgadoss.r@intel.com
./device_libs/platform_scu_flis: ning.li@intel.com
./device_libs/platform_sdio_regulator: chuanxiao.dong@intel.com
./device_libs/platform_sdio_regulator: feiyix.ning@intel.com
./device_libs/platform_soc_thermal: durgadoss.r@intel.com
./intel-mid: jacob.jun.pan@intel.com
./intel-mid: sathyanarayanan.kuppuswamy@intel.com
./intel_soc_dump: bin.gao@intel.com
./mrfl: mark.f.brown@intel.com
./pmu_tng: austin.hu@intel.com
./pmu_tng: dale.b.stimson@intel.comSince I was also looking at using Linux 3.19, it seems in the platform/intel-mid on master there are only three intel devs. I don't mind reaching out to them directly. They are likely the right people.
[linux]$ git log --pretty=oneline | head -1
eb74926920cfa756087a82e0b081df837177cb95 Merge tag 'sound-3.19-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
[linux]$ grep -rEiEio '\b[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,4}\b' ./arch/x86/platform/intel-mid/ | sed 's/.[hc]:/:/' | sort -u | grep intel.com | cut -d: -f 2 | sort -u
david.a.cohen@linux.intel.com
jacob.jun.pan@intel.com
sathyanarayanan.kuppuswamy@intel.com... and this was confirmed by @stevencrossing From https://twitter.com/stevencrossing/status/554318697649946625
@hippiehacker @rexstjohn no public mailing list (would be a good get), but those emails you found are the best guys to email & have fix
hh
commented
9 years ago I'm trying to document what these functions to do to help identify where the g_hid template should go... but I'm going to wait for input from the platform/intel-mid team before I dig any further
There are many _init functions in this patchset, and they differ greatly from the ones in 3.19.0-rc4... I'm guessing it's it's going to be int *_init() of some sort and I'm just trying to narrow it down.
device_libs/platform_btlpm.c:38:static int __init bluetooth_init(void)
device_libs/platform_gpio_keys.c:66:static int __init pb_keys_init(void)
device_libs/platform_hsu.c:332:int intel_mid_hsu_init(struct device *dev, int port)
device_libs/platform_mid_pwm.c:95:static int __init intel_mid_pwm_init(void)
device_libs/platform_mrfl_regulator.c:116:static int __init regulator_init(void)
device_libs/platform_msic.c:59:static int __init msic_init(void)SCU / System Controller Unit FLIS / .... something about GPIOs
device_libs/platform_scu_flis.c:257:static int __init intel_scu_flis_init(void)device_libs/platform_sdio_regulator.c:224:static int __init wifi_regulator_init(void)
device_libs/platform_soc_thermal.c:106:static int __init byt_soc_thermal_init(void)
device_libs/platform_soc_thermal.c:132:static int __init platform_soc_thermal_init(void)wl12xx is the Bluetooth and WLAN chip: http://wireless.kernel.org/en/users/Drivers/wl12xx
device_libs/platform_wl12xx.c:21:static int wl12xx_platform_init(struct
wl12xx_platform_data *platform_data);
device_libs/platform_wl12xx.c:65:void __init wl12xx_platform_data_init(void *info)
device_libs/platform_wl12xx.c:111: wl12xx_platform_data_init(info);
device_libs/platform_wl12xx.c:116:static int wl12xx_platform_init(struct wl12xx_platform_data *platform_data)early_printk_intel_mid.c:152: mrst_early_console_init();
early_printk_intel_mid.c:200:void mrst_early_console_init(void)
early_printk_intel_mid.c:301:void mrfld_early_console_init(void)
early_printk_intel_mid.c:406:void hsu_early_console_init(const char *s)
early_printk_intel_mid.c:568:static int pti_early_console_init(void)
intel-mid.c:97:static void __init intel_mid_time_init(void)
intel-mid.c:119: apbt_time_init();
intel_mid_pcihelpers.c:11:static int intel_mid_msgbus_init(void)
intel_mid_scu.c:56:int intel_mid_rproc_init(void)
intel_mid_scu.h:14:extern int intel_mid_rproc_init(void) __attribute__((weak));sfi is for simple firmware interface: https://simplefirmware.org/
intel_mid_sfi.c:579:static int __init intel_mid_platform_init(void)intel_mid_vrtc.c:111:void __init intel_mid_rtc_init(void)
intel_mid_vrtc.c:169:module_init(intel_mid_device_create);
intel_soc_clv.c:57:static int clv_pmu_init(void)
intel_soc_debug.c:32: * In addition, a platform check is done in soc_debug_init()
intel_soc_debug.c:163:int __init soc_debug_init(void)
intel_soc_dump.c:1560:static int __init intel_mid_dump_init(void)
intel_soc_dump.c:1572:module_init(intel_mid_dump_init);
intel_soc_mdfld.c:140:static int mfld_pmu_init(void)
intel_soc_mrfld.c:46:static int mrfld_pmu_init(void)
intel_soc_pm_debug.c:229:void s0ix_lat_stat_init(void)
intel_soc_pm_debug.c:339:void s0ix_lat_stat_init(void) {}
intel_soc_pm_debug.c:1277:void pmu_stats_init(void)
intel_soc_pm_debug.c:1293: s0ix_lat_stat_init();
intel_soc_pm_debug.c:2438:void pmu_stats_init(void)
intel_soc_pmu.c:1664:static int pmu_init(void)
intel_soc_pmu.c:1674: spin_lock_init(&mid_pmu_cxt->nc_ready_lock);
intel_soc_pmu.c:1680: pmu_stats_init();
intel_soc_pmu.c:1872: ret = pmu_init();
intel_soc_pmu.c:2075:static int __init mid_pci_register_init(void)
intel_soc_pmu.c:2101: sema_init(&mid_pmu_cxt->scu_ready_sem, 1);
intel_soc_pmu.h:388:extern void pmu_stats_init(void);
mrfl.c:134:static void __init tangier_time_init(void)
mrfl.c:142: intel_mid_timer_init();I'm not sure I understand the difference between configfs with gadgetfs.
Might be worth looking at these gadgetfs based sources as configfs for hid is only in 3.19.0-rc4
hh
commented
9 years ago @agnathan do you know anyone that could give me a bit of direction here?
hh
commented
9 years ago From http://article.gmane.org/gmane.linux.usb.general/120511
Thanks for all the direction and feedback thus far, configfs is the
way to go but I would need f_hid, f_mass_storage, and f_rdnis which
aren't available in v3.10. Configfs f_hid is relatively recent,
f_rndis + f_mass_storage where merged into v3.11, but similar
functions actual entered the kernel in v3.10... which is what gives me
hope that the porting may be simple.
Porting the platform/intel-mid forward to a new kernel version without
communication from Intel would probably result in needless duplication
of effort. Would it be advisable for me to backport the
drivers/usb/gadget/function/* from 3.19-rc1 and compile them in
3.10.17? I doubt it would be as simple as copying them over and
modifying the Makefile, but one can hope.
https://lkml.org/lkml/2014/12/14/274 - v3.19-rc1 for f_hid
https://lkml.org/lkml/2013/7/1/388 - v3.11-rc1 for f_rndis and f_mass_storage
https://lkml.org/lkml/2013/4/29/248 - v3.10-rc1 for f_acm (which seems
to load and configure **)
**root@...:/# cat
/sys/kernel/config/usb_gadget/gadget/functions/acm.usb0/port_num
0
This issues will track my attempt to integrate gadget_hid into the 3.10 kernel from yocto that has the intel patches applied which are included the Intel Edison BSP release.
From https://communities.intel.com/message/272533
Thus far the linux-usb mailing list has been quite responsive. https://www.mail-archive.com/linux-usb@vger.kernel.org/msg54279.html
"In the very same file [gadget_hid.txt] there is an example platform driver; well, at least the most important hid-specific parts of it. You must add the usual module boilerplate code and in module's init do platform_device_register(), while in module's exit do platform_device_unregister()." Andrzej Pietrasiewicz
This file contains precisely what we need to add to the intel-mid archictecture: linux-yocto-3.10/Documentation/usb/gadget_hid.txt
But the Intel provided patch completely creates the platform/intel-mid linux-yocto-3.10/arch/x86/platform/intel-mid
This is where I am a bit lost and looking to Intel (or an intel-mid mailing list) to give some suggestions as to where within platform/intel-mid this might be added.
I have a branch with a patch adding support for usb hid gadget based on csimmonds/g_hid-demo But it currently results in errors, and no HID yet 8(
Another alternative is to build edison-image BSP with Linux 3.19.x (which is issue #2) which supports gadget configfs, but I'd like to try and stay in the supported mainstream as much as possible for now.
Background on getting to the intel-mid platform source:
Edison - Software Downloads includes http://downloadmirror.intel.com/24389/eng/edison-image-rel1-maint-rel1-ww42-14.zip Which I imported into github: https://github.com/instantinfrastructure/edison-src to allow pointing to individual files.
The ww42-14 release includes a large patch to the linux-yocto kernel sources: edison-src/device-software/meta-edison/recipes-kernel/linux/files/upstream_to_edison.patch I have applied that to the linux-yocto-3.10 sources linux-yocto-3.10