Hi Richard, On 4/13/2020 7:03 PM, Richard Neumann wrote: > Am Montag, den 06.04.2020, 10:56 +0530 schrieb Shah, Nehal- > bakulchandra: >> HI >> >> On 4/1/2020 9:58 PM, Richard Neumann wrote: >>> Am Dienstag, den 31.03.2020, 20:24 +0300 schrieb Andy Shevchenko: >>>> On Tue, Mar 31, 2020 at 4:26 PM Shah, Nehal-bakulchandra >>>> <nehal-bakulchandra.shah@xxxxxxx> wrote: >>>>> On 3/31/2020 6:01 PM, Richard Neumann wrote: >>>>>> Not a real review, but your patch series seems to be >>>>>> repeating a >>>>>> lot >>>>>> from drivers/i2c/busses/i2c-amd-mp2*. >>>>>> Is there any chance we could re-use the code? >>>>>> E.g. the AMD_C2P_* definitions from drivers/i2c/busses/i2c- >>>>>> amd- >>>>>> mp2.h? >>>>> Thanks for the mail. Yes there are some common structures, >>>>> however >>>>> as of now we have kept separately considering both >>>>> >>>>> are part of different sub systems. But may be will consider >>>>> this >>>>> input for future enhancement. >>>> It can be done in a form of shared definitions at least in >>>> include/linux/platform_data/x86/amd-mp2.h or alike ... >>>> >>> I managed to add support for the AMD SFH PCI device to i2c-amd-mp2* >>> and >>> outsourced the headers to include/linux/i2c-amd-mp2.h. [1] >>> I also refactored the patch series (excluded the documentation) [2] >>> to >>> use the PCI device now provided by i2c_amd_mp2_pci and removed some >>> duplicate and unncessary code. >>> The driver now consist of just one module (amd_sfhtp_hid). >>> Unfortunately I was not able to solve the problem, that I get AMD- >>> Vi >>> IO_PAGE_FAULT errors when not booted with amd_iommu=off. >>> >>> [1] >>> https://gist.githubusercontent.com/conqp/4d726f86da8a8397d6e70091a124de67/raw/f97e88a0b44d98bfa1258cb73c8afe4dce7afa87/i2c-amd-mp2.patch >>> [2] >>> https://gist.githubusercontent.com/conqp/67036e690aca89d08b958971edac283d/raw/2a1ef122f9c8c8e07164b6d597962ce7bbad6d45/amd-sfhtp.patch >> Thanks for the patch and appreciate your efforts. At this point of >> time, we would like to have our first patch for SFH to be upstreamed >> and dont want to complicate the >> >> with two sub systems and maintainers. Surely will consider this input >> for future enhancement. Thanks for your understanding. >> >> Thanks >> >> >> Nehal >> >> > Hi all, > > I spent the last two weeks learning the HID API and refactored [1] the > patch series again. I also took into consideration Nehal's input > regarding the two subsystems. After tinkering with the integration of > the SFH PCI driver into the existing i2c-amd-mp2-pci driver, I realized > that this was a futile effort at this point of time, since the SFH > protocol, as far as I understand it, does not really implement the I2C > protocol. Thusly I turned away from trying to integrate the two > drivers. The core changes I did, is to refactor the PCI driver to use a > similar initialization as the i2c-amd-mp2-pci driver. The registers are > now mapped correctly on initial setup (1 << 2) and not mapped to zero > (1 >> 2) and the ioremapped later. With this change, the AMD-Vi page > faults when not booting with amd_iommu=off also automagically > disappeared. > The second change is the HID device handling. I now implemented the > hid_ll_driver API with the respective functions to process raw events > as well device start / stop and open / close routines. I also > refactored the platform driver wich is now solely responsible for > spawning and despawning the HID devices. I also reduced the commonly > used structures and constats to those that were actually being used by > the driver and renamed the PCI registers to express what they are used > for in this driver. I also commented most functions and shared > structures. The only problem I keep having on my machine is, that the > register for the bit-shifted active sensors mask 0x1068C keeps > returning zero on readout and thusly I need to override it. > I tried to get the sensor mask by sending the "dump_sensorinfo" and > "number_of_sensors_discovered" commands to different C2P registers and > dumping the corresponding P2C registers. But so far I could not get any > information that could be interpreted as the sensor info and mask that > I need. Maybe Nehal or Sandeep could provide the information, if and > how it ts possible to get information about the amount, position and > type of the connected sensors in another way. I also found out, by > sweeping the SFH registers (from 0 to 31), that there seem to be other > sensors connected on my machine, namely at positions 0, 1, 2, 3, 4, 7, > 8 and 9. The ALS at 19 does not seem to be present on my system. I > suspect that at least one of those is an additional accelerometer, > since the only one working right now ist the accelerometer at position > 0, which is located in the sceen / lid. I suspect that the other one is > located in the chassis, allowing the use of both to perform tablet mode > detection by processing their relative orientation. I'd appreciate a > hint on this assumption as well. ;-) > > Sincere regards, > > Richard > > [1] https://gist.github.com/conqp/33baa079d9524914c4c0c196200e4f89 Thanks for the refactoring the patch. The .raw_request in hid_ll_driver is not correct, the output of sensor is not raw but it is processed one, so better to move it to .request function. Regarding your question for sensor position well it comes from firmware. So i am not sure about the firmware for sensor , what you have.Also, regarding the IOMMU, we figured out the issue, earlier patch series has bug that during DMA allocation pdev was passed from platform driver context, where in for IOMMU needs context PCI pdev. So that is taken care in your refactored patch hence issue is disappeared. Now regarding the patch (with your changes) i need to validate at our side. Due to lockdown i dont have access to the system, so may be we can wait on that. Thanks Nehal Shah
