From: Andreas Kemnade <andreas@kemnade.info> To: "Jonathan Neuschäfer" <j.neuschaefer@gmx.net> Cc: robh+dt@kernel.org, shawnguo@kernel.org, s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com, linux-imx@nxp.com, Anson.Huang@nxp.com, marcel.ziswiler@toradex.com, sebastien.szymanski@armadeus.com, rjones@gateworks.com, leoyang.li@nxp.com, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, letux-kernel@openphoenux.org Subject: Re: [PATCH RFC 2/2] ARM: dts: imx: add devicetree for Tolino Shine 2 HD Date: Sun, 16 Aug 2020 16:50:58 +0200 [thread overview] Message-ID: <20200816165058.3a17d97a@aktux> (raw) In-Reply-To: <20200816125247.GA103070@latitude> Hi, Seems that we have different hardware, so the first question is first the most interesting thing: how much does the hw actually differ, especially do they require different device trees? Can you provide me a photo of your hardware? Or is it a Shine 3? Mine is at https://misc.andi.de1.cc/tolino2.jpg On Sun, 16 Aug 2020 14:54:41 +0200 Jonathan Neuschäfer <j.neuschaefer@gmx.net> wrote: [...] > > + > > +&usdhc3 { > > + pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep"; > > + pinctrl-0 = <&pinctrl_usdhc3>; > > + pinctrl-1 = <&pinctrl_usdhc3_100mhz>; > > + pinctrl-2 = <&pinctrl_usdhc3_200mhz>; > > + pinctrl-3 = <&pinctrl_usdhc3_sleep>; > > + vmmc-supply = <®_wifi>; > > + mmc-pwrseq = <&wifi_pwrseq>; > > + cap-power-off-card; > > + non-removable; > > + status = "okay"; > > + > > + /* CyberTan WC121 SDIO WiFi */ > > +}; > > The HWCONFIG block from my Shine2HD reports RTL8189 as the Wifi chip > (value 8 at offset 4), and kernel logs from the vendor kernel appear to > agree that it's a realtek chip, at least (lines prefixed RTL871X). > Just for the readers with IMX knowledge but without knowledge of the vendor kernel hacks used here: That block is on a hidden partition of the boot medium (uSD or eMMC) describing the hardware, the kernel gets it from the bootloader and it is used e.g. in the board file. My hwconfig is: {m_hdr = {cMagicNameA = "HW CONFIG " cVersionNameA = "v2.6" bHWConfigSize = 62 '>'} m_val = {bPCB = 50 '2' bKeyPad = 13 '\r' bAudioCodec = 0 '\000' bAudioAmp = 0 '\000' bWifi = 7 '\a' bBT = 0 '\000' bMobile = 0 '\000' bTouchCtrl = 11 '\v' bTouchType = 4 '\004' bDisplayCtrl = 7 '\a' bDisplayPanel = 6 '\006' bRSensor = 0 '\000' bMicroP = 0 '\000' bCustomer = 0 '\000' bBattery = 1 '\001' bLed = 4 '\004' bRamSize = 3 '\003' bIFlash = 0 '\000' bExternalMem = 0 '\000' bRootFsType = 2 '\002' bSysPartType = 11 '\v' bProgressXHiByte = 1 '\001' bProgressXLoByte = 104 'h' bProgressYHiByte = 2 '\002' bProgressYLoByte = 228 '\344' bProgressCnts = 0 '\000' bContentType = 0 '\000' bCPU = 5 '\005' bUIStyle = 2 '\002' bRamType = 5 '\005' bUIConfig = 0 '\000' bDisplayResolution = 5 '\005' bFrontLight = 13 '\r' bCPUFreq = 0 '\000' bHallSensor = 1 '\001' bDisplayBusWidth = 0 '\000' bFrontLight_Flags = 4 '\004' bPCB_Flags = 17 '\021' bFrontLight_LED_Driver = 3 '\003' bVCOM_10mV_HiByte = 0 '\000' bVCOM_10mV_LoByte = 0 '\000' bPCB_REV = 0 '\000' bPCB_LVL = 0 '\000' bHOME_LED_PWM = 0 '\000' bPMIC = 1 '\001' bFL_PWM = 0 '\000' bRTC = 1 '\001' bBootOpt = 0 '\000' bTouch2Ctrl = 0 '\000' bTouch2Type = 0 '\000' bGPS = 0 '\000' bFM = 0 '\000' bRSensor2 = 0 '\000' bLightSensor = 0 '\000' bTPFWIDByte0 = 0 '\000' bTPFWIDByte1 = 0 '\000' bTPFWIDByte2 = 0 '\000' bTPFWIDByte3 = 0 '\000' bTPFWIDByte4 = 0 '\000' bTPFWIDByte5 = 0 '\000' bTPFWIDByte6 = 0 '\000' bTPFWIDByte7 = 0 '\000' bGPU = 0 '\000' bPCB_Flags2 = 0 '\000' bEPD_Flags = 0 '\000' bLAN = 0 '\000' bMobileIF = 0 '\000' bPIR = 0 '\000' bPanelLaminationSrc = 0 '\000'} m_bReserveA = '\000' <repeats 24 times>} > From my experience with the CyberTan WC121, it has a Broadcom fullmac > chip inside. Now I wonder where this discrepancy or variability comes > from. > correct. It uses the brcmfmac driver on mainline and the . bcmdhd in the vendor kernel Output on the vendor kernel: bcmsdh_register: Linux Kernel SDIO/MMC Driver [bcm_wlan_get_oob_irq-43] gpio 127, irq 383 dhd_conf_set_hw_oob_intr: Enable HW OOB for 43362 F1 signature OK, socitype:0x1 chip:0xa962 rev:0x1 pkg:0x9 DHD: dongle ram size is set to 245760(orig 245760) at 0x0 dhdsdio_probe: Disable prop_txstatus dhd_conf_set_fw_name_by_chip: firmware_path=/system/lib/firmware/wc121/fw_bcm40181a2.bin wl_create_event_handler(): thread:wl_event_handler:92d started tsk Enter, tsk = 0xdb501304 p2p0: P2P Interface Registered dhd_attach(): thread:dhd_watchdog_thread:932 started dhd_attach(): thread:dhd_dpc:933 started dhd_attach(): thread:dhd_sysioc:934 started On mainline: [ 11.686469] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43362-sdio for chip BCM43362/1 [ 12.282783] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43362-sdio for chip BCM43362/1 [ 12.387000] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-11), device may have limited channels available [ 12.479403] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43362/1 wl0: May 16 2018 23:42:49 version 5.90.244 FWID 01-0 > I guess the SDIO setup can deal with different chips (like Broadcom vs. > Realtek) as long as the board has been designed to always use the same > reset/power/etc. lines. I don't see any branching based on the 'Wifi' > HWCONFIG entry in the vendor kernel, so I guess that's the case. > as long as these chips do not use oob interrupts, just sdio, it should be no problem. The question is just how much our devices differ. Regards, Andreas
WARNING: multiple messages have this Message-ID (diff)
From: Andreas Kemnade <andreas@kemnade.info> To: "Jonathan Neuschäfer" <j.neuschaefer@gmx.net> Cc: devicetree@vger.kernel.org, rjones@gateworks.com, Anson.Huang@nxp.com, marcel.ziswiler@toradex.com, shawnguo@kernel.org, s.hauer@pengutronix.de, linux-kernel@vger.kernel.org, leoyang.li@nxp.com, robh+dt@kernel.org, linux-imx@nxp.com, kernel@pengutronix.de, sebastien.szymanski@armadeus.com, letux-kernel@openphoenux.org, festevam@gmail.com, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH RFC 2/2] ARM: dts: imx: add devicetree for Tolino Shine 2 HD Date: Sun, 16 Aug 2020 16:50:58 +0200 [thread overview] Message-ID: <20200816165058.3a17d97a@aktux> (raw) In-Reply-To: <20200816125247.GA103070@latitude> Hi, Seems that we have different hardware, so the first question is first the most interesting thing: how much does the hw actually differ, especially do they require different device trees? Can you provide me a photo of your hardware? Or is it a Shine 3? Mine is at https://misc.andi.de1.cc/tolino2.jpg On Sun, 16 Aug 2020 14:54:41 +0200 Jonathan Neuschäfer <j.neuschaefer@gmx.net> wrote: [...] > > + > > +&usdhc3 { > > + pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep"; > > + pinctrl-0 = <&pinctrl_usdhc3>; > > + pinctrl-1 = <&pinctrl_usdhc3_100mhz>; > > + pinctrl-2 = <&pinctrl_usdhc3_200mhz>; > > + pinctrl-3 = <&pinctrl_usdhc3_sleep>; > > + vmmc-supply = <®_wifi>; > > + mmc-pwrseq = <&wifi_pwrseq>; > > + cap-power-off-card; > > + non-removable; > > + status = "okay"; > > + > > + /* CyberTan WC121 SDIO WiFi */ > > +}; > > The HWCONFIG block from my Shine2HD reports RTL8189 as the Wifi chip > (value 8 at offset 4), and kernel logs from the vendor kernel appear to > agree that it's a realtek chip, at least (lines prefixed RTL871X). > Just for the readers with IMX knowledge but without knowledge of the vendor kernel hacks used here: That block is on a hidden partition of the boot medium (uSD or eMMC) describing the hardware, the kernel gets it from the bootloader and it is used e.g. in the board file. My hwconfig is: {m_hdr = {cMagicNameA = "HW CONFIG " cVersionNameA = "v2.6" bHWConfigSize = 62 '>'} m_val = {bPCB = 50 '2' bKeyPad = 13 '\r' bAudioCodec = 0 '\000' bAudioAmp = 0 '\000' bWifi = 7 '\a' bBT = 0 '\000' bMobile = 0 '\000' bTouchCtrl = 11 '\v' bTouchType = 4 '\004' bDisplayCtrl = 7 '\a' bDisplayPanel = 6 '\006' bRSensor = 0 '\000' bMicroP = 0 '\000' bCustomer = 0 '\000' bBattery = 1 '\001' bLed = 4 '\004' bRamSize = 3 '\003' bIFlash = 0 '\000' bExternalMem = 0 '\000' bRootFsType = 2 '\002' bSysPartType = 11 '\v' bProgressXHiByte = 1 '\001' bProgressXLoByte = 104 'h' bProgressYHiByte = 2 '\002' bProgressYLoByte = 228 '\344' bProgressCnts = 0 '\000' bContentType = 0 '\000' bCPU = 5 '\005' bUIStyle = 2 '\002' bRamType = 5 '\005' bUIConfig = 0 '\000' bDisplayResolution = 5 '\005' bFrontLight = 13 '\r' bCPUFreq = 0 '\000' bHallSensor = 1 '\001' bDisplayBusWidth = 0 '\000' bFrontLight_Flags = 4 '\004' bPCB_Flags = 17 '\021' bFrontLight_LED_Driver = 3 '\003' bVCOM_10mV_HiByte = 0 '\000' bVCOM_10mV_LoByte = 0 '\000' bPCB_REV = 0 '\000' bPCB_LVL = 0 '\000' bHOME_LED_PWM = 0 '\000' bPMIC = 1 '\001' bFL_PWM = 0 '\000' bRTC = 1 '\001' bBootOpt = 0 '\000' bTouch2Ctrl = 0 '\000' bTouch2Type = 0 '\000' bGPS = 0 '\000' bFM = 0 '\000' bRSensor2 = 0 '\000' bLightSensor = 0 '\000' bTPFWIDByte0 = 0 '\000' bTPFWIDByte1 = 0 '\000' bTPFWIDByte2 = 0 '\000' bTPFWIDByte3 = 0 '\000' bTPFWIDByte4 = 0 '\000' bTPFWIDByte5 = 0 '\000' bTPFWIDByte6 = 0 '\000' bTPFWIDByte7 = 0 '\000' bGPU = 0 '\000' bPCB_Flags2 = 0 '\000' bEPD_Flags = 0 '\000' bLAN = 0 '\000' bMobileIF = 0 '\000' bPIR = 0 '\000' bPanelLaminationSrc = 0 '\000'} m_bReserveA = '\000' <repeats 24 times>} > From my experience with the CyberTan WC121, it has a Broadcom fullmac > chip inside. Now I wonder where this discrepancy or variability comes > from. > correct. It uses the brcmfmac driver on mainline and the . bcmdhd in the vendor kernel Output on the vendor kernel: bcmsdh_register: Linux Kernel SDIO/MMC Driver [bcm_wlan_get_oob_irq-43] gpio 127, irq 383 dhd_conf_set_hw_oob_intr: Enable HW OOB for 43362 F1 signature OK, socitype:0x1 chip:0xa962 rev:0x1 pkg:0x9 DHD: dongle ram size is set to 245760(orig 245760) at 0x0 dhdsdio_probe: Disable prop_txstatus dhd_conf_set_fw_name_by_chip: firmware_path=/system/lib/firmware/wc121/fw_bcm40181a2.bin wl_create_event_handler(): thread:wl_event_handler:92d started tsk Enter, tsk = 0xdb501304 p2p0: P2P Interface Registered dhd_attach(): thread:dhd_watchdog_thread:932 started dhd_attach(): thread:dhd_dpc:933 started dhd_attach(): thread:dhd_sysioc:934 started On mainline: [ 11.686469] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43362-sdio for chip BCM43362/1 [ 12.282783] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43362-sdio for chip BCM43362/1 [ 12.387000] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-11), device may have limited channels available [ 12.479403] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43362/1 wl0: May 16 2018 23:42:49 version 5.90.244 FWID 01-0 > I guess the SDIO setup can deal with different chips (like Broadcom vs. > Realtek) as long as the board has been designed to always use the same > reset/power/etc. lines. I don't see any branching based on the 'Wifi' > HWCONFIG entry in the vendor kernel, so I guess that's the case. > as long as these chips do not use oob interrupts, just sdio, it should be no problem. The question is just how much our devices differ. Regards, Andreas _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-08-16 14:51 UTC|newest] Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-08-15 19:33 [PATCH 0/2] ARM: dts: add Tolino Shine 2 HD Andreas Kemnade 2020-08-15 19:33 ` Andreas Kemnade 2020-08-15 19:33 ` [PATCH 1/2] dt-bindings: arm: fsl: add compatible string for " Andreas Kemnade 2020-08-15 19:33 ` Andreas Kemnade 2020-08-25 2:16 ` Rob Herring 2020-08-25 2:16 ` Rob Herring 2020-08-15 19:33 ` [PATCH RFC 2/2] ARM: dts: imx: add devicetree " Andreas Kemnade 2020-08-15 19:33 ` Andreas Kemnade 2020-08-16 12:54 ` Jonathan Neuschäfer 2020-08-16 12:54 ` Jonathan Neuschäfer 2020-08-16 14:50 ` Andreas Kemnade [this message] 2020-08-16 14:50 ` Andreas Kemnade 2020-08-16 15:57 ` Jonathan Neuschäfer 2020-08-16 15:57 ` Jonathan Neuschäfer 2020-08-17 5:59 ` Andreas Kemnade 2020-08-17 5:59 ` Andreas Kemnade 2020-08-26 6:24 ` Andreas Kemnade 2020-08-26 6:24 ` Andreas Kemnade 2020-08-23 1:42 ` Shawn Guo 2020-08-23 1:42 ` Shawn Guo 2020-08-23 16:38 ` Andreas Kemnade 2020-08-23 16:38 ` Andreas Kemnade
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20200816165058.3a17d97a@aktux \ --to=andreas@kemnade.info \ --cc=Anson.Huang@nxp.com \ --cc=devicetree@vger.kernel.org \ --cc=festevam@gmail.com \ --cc=j.neuschaefer@gmx.net \ --cc=kernel@pengutronix.de \ --cc=leoyang.li@nxp.com \ --cc=letux-kernel@openphoenux.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-imx@nxp.com \ --cc=linux-kernel@vger.kernel.org \ --cc=marcel.ziswiler@toradex.com \ --cc=rjones@gateworks.com \ --cc=robh+dt@kernel.org \ --cc=s.hauer@pengutronix.de \ --cc=sebastien.szymanski@armadeus.com \ --cc=shawnguo@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.