01:26 <macromorgan> is there a proper way to ask a non-SPI driver to do spi_write()s?

01:26 <macromorgan> have a mipi screen that gets the data through DSI but the commands only through SPI

06:13 <hanetzer> anyone happen to have a handle on a 2x5 2.54mm to 2.0mm pitch shifter I can buy?

10:18 <broonie> macromorgan: DSI would need to provide a spi_controller

10:22 <hanetzer> nevermind, the pinout on this device isn't a 'standard' 2x5 jtag pinout buu

12:41 <macromorgan> broonie: Can you elaborate a bit? The BSP version of this driver bitbangs the SPI bus to deliver commands. Presume I'd do some imports of the spi-bitbang driver then (since I doubt kernel devs want me reproducing the same code).

12:42 <broonie> I know nothing about how the hardware is implemented, but if the hardware is providing a SPI controller then the Linux abstraction for that is to register a spi controller.

12:55 <macromorgan> the hardware is an SPI slave

12:57 <macromorgan> It's a Samsung AMOLED panel that can either be controlled with DSI data and DSI commands (like all normal sane hardware) or with DSI data and 3-Wire SPI commands (like my unfortunate implementation).

12:59 <macromorgan> I'm trying to think what is mainline-able... Assuming creating it as a mipi_dsi_device, but how to connect it to the SPI bus and define that it the devicetree properly is what I'm trying to figure out.

13:00 <macromorgan> even more funny about my implementation (the Anbernic RG503 handheld gaming device, for reference) is that while the panel's SPI pins are connected to SPI3 of the SoC, the MOSI/MISO pins are backwards so it has to be bitbanged.

13:01 <macromorgan> still, command only data isn't very much data

13:02 <broonie> If the DSI controller is also a SPI controller it should provide a SPI controller.

13:03 <broonie> Though it sounds like it's just connected directly to the SoC so you should just register a GPIO based SPI controller as normal and I don't understand what the question is?

14:08 <macromorgan> I guess the first question I have that will probably answer the most is this: if the device receives video data via DSI and commands via SPI (making it a client of both), should I register it as an spi_device or as a mipi_dsi_device?

14:11 <broonie> Both.

14:11 <broonie> Assuming DSI needs some kind of software representation I guess.

14:11 <macromorgan> yes

14:12 <macromorgan> the BSP driver I'm dealing with registers it as a mipi_dsi_device, but bypasses the spi stuff entirely by bitbanging

14:41 <arnd> broonie: I'm going through all the lines in multi_v7_defconfig that are removed by 'make savedefconfig', and came across 2cc1cd26e913 ("ARM: configs: Enable ASoC AC'97 glue")

14:42 <arnd> CONFIG_SND_SOC_AC97 does not exist in mainline, is that something you are adding in the ASoC tree, or a typo?

14:43 <broonie> It's been removed probably.

14:43 <broonie> It was a thnig.

14:43 <arnd> I can see CONFIG_SND_SOC_AC97_CODEC

22:09 <palmer> not sure if my bouncer is broken or if both will and null are gone, but I'm planning on taking https://lore.kernel.org/all/20220711174632.4186047-1-atishp@rivosinc.com/ via the RISC-V tree (which you asked me to do 2 months ago, but I forgot about https://lore.kernel.org/lkml/CAAhSdy23vE8+HxU5Jxy2rBMjy3rBTrJt_4sriuROac_sEESSVw@mail.gmail.com/T/#m9de15aef1b65ae6155fa33ea1239578ef463c2a2)