Message-ID: <20200816165058.3a17d97a@aktux>
Date:   Sun, 16 Aug 2020 16:50:58 +0200
From:   Andreas Kemnade <andreas@...nade.info>
To:     Jonathan Neuschäfer <j.neuschaefer@....net>
Cc:     robh+dt@...nel.org, shawnguo@...nel.org, s.hauer@...gutronix.de,
        kernel@...gutronix.de, festevam@...il.com, linux-imx@....com,
        Anson.Huang@....com, marcel.ziswiler@...adex.com,
        sebastien.szymanski@...adeus.com, rjones@...eworks.com,
        leoyang.li@....com, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        letux-kernel@...nphoenux.org
Subject: Re: [PATCH RFC 2/2] ARM: dts: imx: add devicetree for Tolino Shine
 2 HD

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@....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 = <&reg_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

Powered by blists - more mailing lists