linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 = <&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

  reply	other threads:[~2020-08-16 14:51 UTC|newest]

Thread overview: 11+ 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 ` [PATCH 1/2] dt-bindings: arm: fsl: add compatible string for " Andreas Kemnade
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-16 12:54   ` Jonathan Neuschäfer
2020-08-16 14:50     ` Andreas Kemnade [this message]
2020-08-16 15:57       ` Jonathan Neuschäfer
2020-08-17  5:59         ` Andreas Kemnade
2020-08-26  6:24     ` Andreas Kemnade
2020-08-23  1:42   ` Shawn Guo
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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).