Hi, On Fri, May 31, 2024 at 9:51 AM Jeffrey Hugo <quic_jhugo@xxxxxxxxxxx> wrote: > > On 5/31/2024 10:20 AM, Doug Anderson wrote: > > Hi, > > > > On Fri, May 31, 2024 at 9:18 AM Jeffrey Hugo <quic_jhugo@xxxxxxxxxxx> wrote: > >> > >> On 5/30/2024 5:12 PM, Dmitry Baryshkov wrote: > >>> There are two ways to describe an eDP panel in device tree. The > >>> recommended way is to add a device on the AUX bus, ideally using the > >>> edp-panel compatible. The legacy way is to define a top-level platform > >>> device for the panel. > >>> > >>> Document that adding support for eDP panels in a legacy way is strongly > >>> discouraged (if not forbidden at all). > >>> > >>> While we are at it, also drop legacy compatible strings and bindings for > >>> five panels. These compatible strings were never used by a DT file > >>> present in Linux kernel and most likely were never used with the > >>> upstream Linux kernel. > >>> > >>> The following compatibles were never used by the devices supported by > >>> the upstream kernel and are a subject to possible removal: > >>> > >>> - lg,lp097qx1-spa1 > >>> - samsung,lsn122dl01-c01 > >>> - sharp,ld-d5116z01b > >> > >> Ok to drop the sharp one I added. It should be able to be handled by > >> the (newish) edp-panel, but I think the TI bridge driver needs some work > >> for the specific platform (no I2C connection) to verify. > > > > Is the platform supported upstream? If so, which platform is it? Is > > the TI bridge chip the ti-sn65dsi86? If so, I'm confused how you could > > use that bridge chip without an i2c connection, but perhaps I'm > > misunderstanding. :-P > > Yes, the platform is upstream. The 8998 laptops (clamshell). It is the > ti-sn65si86. I suspect the I2C connection was not populated for cost > reasons, then determined its much more convenient to have it as every > generation after that I've seen has the I2C. > > If you check the datasheet closely, the I2C connection is optional. You > can also configure the bridge inband using DSI commands. This is what > the FW and Windows does. > > So, the DT binding needs to make the I2C property optional (this should > be backwards compatible). The driver needs to detect that the I2C > connection is not provided, and fall back to DSI commands. Regmap would > be nice for this, but I got pushback on the proposal. Then I got > sidetracked looking at other issues. Crazy! I'm sure I've skimmed over that part of the ti-sn65dsi86 datasheet before but I don't think I internalized it. I guess if you did it this way then you'd instantiate it as a platform device instead of an i2c device and that would be how you'd detect the difference. I could imagine this being a bit of a challenge to get working in the driver.
