From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 46E52C4338F for ; Tue, 17 Aug 2021 10:05:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 25F1E60C3F for ; Tue, 17 Aug 2021 10:05:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239387AbhHQKFw (ORCPT ); Tue, 17 Aug 2021 06:05:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51734 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239287AbhHQKEc (ORCPT ); Tue, 17 Aug 2021 06:04:32 -0400 Received: from phobos.denx.de (phobos.denx.de [IPv6:2a01:238:438b:c500:173d:9f52:ddab:ee01]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 81BEAC061764 for ; Tue, 17 Aug 2021 03:03:51 -0700 (PDT) Received: from [IPv6:::1] (p578adb1c.dip0.t-ipconnect.de [87.138.219.28]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: marex@denx.de) by phobos.denx.de (Postfix) with ESMTPSA id A78F580C87; Tue, 17 Aug 2021 12:03:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=denx.de; s=phobos-20191101; t=1629194628; bh=m4wfMZxqNNmxFWB9gjExRoiafVD/AFM3ZmrLihzAB3A=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=UrNjRkMy352lv0le8KG5+J5uH+rnkUS4U67gU55mmpjMfhFBUX6eg6l6+CkDutxbE pV2WdKIoxIDLmiGLGpvzAI2tlzPjk73dBB+ztx16bmO1Yxq3eEJNizNDbzXjPCpetf +E5/fy/Q8GVw6RFrng2r2rWDCuRha0oLwbz1FlmROdrsmVIZxoaXywkzYDX4jhcLMx d8usbPJEQ+PsYd/5TFH2ShtOI5r6PmyCQI9GRPghSPW2yFxM/w+ZnHUG3MyK06bkaj b+J3n1YrICTRJScbYMwa86/HnMf1hPQ9+c9G3zQ+Rs+LtPXpPJ8iTB1278CvumNMAI npfBJPhPijZqA== Subject: Re: Revert "video: fbdev: mxsfb: Remove driver" To: Alistair Francis Cc: Fabio Estevam , Shawn Guo , Sascha Hauer , dl-linux-imx , b.zolnierkie@samsung.com, Linux Kernel Mailing List , Alistair Francis , Sam Ravnborg References: From: Marek Vasut Message-ID: Date: Tue, 17 Aug 2021 12:03:46 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.103.2 at phobos.denx.de X-Virus-Status: Clean Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 8/17/21 11:08 AM, Alistair Francis wrote: > On Mon, Aug 16, 2021 at 5:55 PM Marek Vasut wrote: >> >> On 8/16/21 9:34 AM, Alistair Francis wrote: >>> On Sun, Aug 15, 2021 at 10:31 PM Marek Vasut wrote: >>>> >>>> On 8/15/21 2:16 PM, Alistair Francis wrote: >>>>> Hello, >>>>> >>>>> Commit f225f1393f034 "video: fbdev: mxsfb: Remove driver" removed the >>>>> mxsfb fbdev driver. >>>>> >>>>> I am now working on getting mainline Linux running on the reMarkable 2 >>>>> eInk reader [1]. Unfortunately the rM2 doesn't use the standard EPD >>>>> controller on the i.MX SoC, but instead uses the LCD controller. >>>>> >>>>> eInk panels are complex to control and require writing temperature >>>>> dependent waveforms. As these waveforms are proprietary [2] the rM >>>>> team runs closed source software called SWTCON in userspace to control >>>>> the panel [3]. >>>>> >>>>> This closed source software expects the fbdev mxsfb driver and it >>>>> doesn't work with the DRM mxsfb driver (at least not that I can get it >>>>> to). >>>>> >>>>> The NXP fork of Linux also re-adds the fbdev driver [4], so they also >>>>> see some uses for it. >>>>> >>>>> I was wondering if the community would be open to re-adding the fbdev >>>>> mxsfb driver to mainline? It could be re-added with a different >>>>> dt-binding so that it is not used by default and only enabled for >>>>> boards when required (like for the rM2). >>>>> >>>>> 1: https://remarkable.com/store/remarkable-2 >>>>> 2: https://goodereader.com/blog/e-paper/e-ink-waveforms-are-a-closely-guarded-secret >>>>> 3: https://remarkablewiki.com/tech/rm2_framebuffer >>>>> 4: https://source.codeaurora.org/external/imx/linux-imx/log/drivers/video/fbdev/mxsfb.c?h=lf-5.10.35-2.0.0 >>>> >>>> +CC Sam. >>>> >>>> What sort of special thing does your proprietary userspace do that >>>> cannot be added to the DRM driver or the fbdev emulation (if needed) ? >>> >>> It's hard to tell. When using the DRM driver I get cryptic errors >>> about the frame buffer not being available. >> >> Do you have fbdev emulation enabled ? Does /dev/fbX exist ? > > I do and /dev/fb0 exists > >> >> What sort of messages do you get and from where ? > > This is the error I get: > > xochitl[252]: Error writing variable information: Invalid argument... Some ioctl returns -EINVAL maybe ? strace would tell you. > xochitl is the proprietary userspace code. I don't really have a good > idea of what that error would mean. > > I also see this: > > Framebuffer has wrong id: "mxcfb" Are you sure you're not confusing mxcfb (The freescale imx scanout engine) with mxsfb (The originally sgtl block, bought by freescale) ? >> You could run strace on the application to see how it communicates with >> the old driver via the ioctl interface and compare it with the fbdev >> emulation on the new driver, maybe there is some odd ioctl which is not >> emulated. > > I had a quick look at this. > > xochitl does a lot more than just controls the display, it interacts > with lots of other hardware and strace produces a lot of logs. I also > don't see the error when manually starting it, only at boot (but it > still doesn't work). > > A quick run with > > strace -f xochitcl > > and I don't even see an access to /dev/fb0, so I'm not sure where the > accesses are coming from. You can try writing the output of strace to file (strace -o) for easier analysis. Then grep for either access to /dev/fb0 (or any symlink to it which might exist), or search for the mxcfb string, maybe the application aborts even before opening the fbdev due to some other problem.