Re: [PATCH v2 3/6] arm64: dts: qcom: r0q: add touchscreen support

[Ghatto <ghatto404@gmail.com>]

On Wed, Oct 29, 2025 at 6:50 AM Konrad Dybcio
<konrad.dybcio@oss.qualcomm.com> wrote:
>
> On 10/27/25 7:32 PM, Eric Gonçalves wrote:
> >
> >
> > On October 20, 2025 9:18:18 AM GMT-03:00, Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> wrote:
> >> On 10/17/25 8:22 PM, Eric Gonçalves wrote:
> >>>
> >>>
> >>> On October 17, 2025 5:20:43 AM GMT-03:00, Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> wrote:
> >>>> On 10/16/25 10:08 PM, Ghatto wrote:
> >>>>> On Thu, Oct 16, 2025 at 6:06 AM Konrad Dybcio
> >>>>> <konrad.dybcio@oss.qualcomm.com> wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 10/14/25 9:04 PM, Ghatto wrote:
> >>>>>>> On Tue, Oct 14, 2025 at 11:18 AM Konrad Dybcio
> >>>>>>> <konrad.dybcio@oss.qualcomm.com> wrote:
> >>>>>>>>
> >>>>>>>> On 10/14/25 5:10 PM, Ghatto wrote:
> >>>>>>>>> On Tue, Oct 14, 2025 at 7:01 AM Konrad Dybcio
> >>>>>>>>> <konrad.dybcio@oss.qualcomm.com> wrote:
> >>>>>>>>>>
> >>>>>>>>>> On 10/14/25 6:41 AM, Eric Gonçalves wrote:
> >>>>>>>>>>> Enable the ST-Microelectronics FTS2BA61Y touchscreen. This patch
> >>>>>>>>>>> depends on "Input: add support for the STM FTS2BA61Y touchscreen".
> >>>>>>>>>>
> >>>>>>>>>> The second sentence doesn't really make sense to be included in
> >>>>>>>>>> the git log
> >>>>>>>>> I'll keep it to the cover letter then
> >>>>>>>>>>
> >>>>>>>>>>> The device has an issue where SPI 8 (the bus which the touchscreen is
> >>>>>>>>>>> connected to) is not working properly right now, so
> >>>>>>>>>>> spi-gpio is used instead.
> >>>>>>>>>>
> >>>>>>>>>> Some Samsung devices used to use spi/i2c-gpio intentionally, also
> >>>>>>>>>> on downstream. I'm assuming this isn't the case for r0q.
> >>>>>>>>> It isn't, the device uses fts2ba61y on the spi8 bus - I hosted the
> >>>>>>>>> DT at https://github.com/ghatt-o/ss_experiments/blob/main/r0q.dts if you
> >>>>>>>>> want to take a look.
> >>>>>>>>>>
> >>>>>>>>>> Did you enable gpi_dma1, qupv3_id_1 before spi8, when testing
> >>>>>>>>> The driver probes, but it fails to recognize the touchscreen device
> >>>>>>>>
> >>>>>>>> Could you post a complete dmesg and the precise DT diff you used?
> >>>>>>> https://pastebin.com/QkYa8nMp (android dmesg) mainline dmesg doesn't have
> >>>>>>
> >>>>>> The link has expired 🙁
> >>>>> https://pastebin.com/s4abJS9M shouldn't expire now!
> >>>>
> >>>> And yet it did!
> >>>>
> >>>> Feel free to just attach it to your message.. the list may bounce
> >>>> it, but it will still reach the To/Cc recipients
> >>> Attached the dmesg.txt file.
> >>
> >> I'm interested in what happens early when the SPI hosts are programmed,
> >> whether there's any additional debug messages.
> >>
> >> If your log buffer is overrunning, you can add log_buf_len=8M to your
> >> cmdline (which will make the buffer 8MiB long)
> > Is it that big of a deal though? spi-gpio
> > works just fine for touchscreen.
>
> It's like using CPU rendering even though your computer has a GPU in it..
Yeah, but CPU rendering is slow, while the touchscreen
on spi-gpio is just as fast as it is on Android.

>
> Plus we don't expect the upstream driver to have such odd issues, so I'd
> really like to get to the bottom of it
I don't think the log buffer is overrunning, where can I find the SPI host logs?
>
> Konrad

I'm gonna drop this patch so the other ones are able to get merged
while I work on the driver.