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
Attachment:
signature.asc
Description: This is a digitally signed message part
