Dear gregkh, arnd: > > > wrote: > > > > > > > > IOP (IO Processor) embedded inside SP7021 which is used as > > > > Processor for I/O control, RTC wake-up and cooperation with CPU & > > > > PMC in power management purpose. > > > > The IOP core is DQ8051, so also named IOP8051, it supports > > > > dedicated JTAG debug pins which share with SP7021. > > > > In standby mode operation, the power spec reach 400uA. > > > > > > > > Signed-off-by: Tony Huang <tonyhuang.sunplus@xxxxxxxxx> > > > > > > Thanks for the improvements, this again looks better than the previous > version. > > > I still have some minor comments, and there are a couple of details > > > I have commented on before that would need to be addressed, but > > > let's focus on the one main issue for now: > > > > > > The driver still doesn't actually /do/ anything: you load the > > > firmware when the driver is loaded, and you shut it down when the > > > driver is removed, but otherwise there is no way to interact with > > > the iop. You had the miscdevice earlier, and you still register > > > that, but there are no file_operations associated with it, so it still doesn't > have any effect. > > > > > > In the original version you had a couple of user-side interfaces, > > > for which Greg and I commented that they were not using the correct > > > abstractions, and you still list them in the changelog text as "I/O > > > control, RTC wake-up and cooperation with CPU & PMC in power > management". > > > > > > If you want to make any progress with adding the driver, I'd say you > > > should implement at least two of those high-level interfaces that > > > interact with the respective kernel subsystems in order to show that the > abstraction works. > > > > > > > Q:"with respective kernel subsystems in order to show that the abstraction > works." > > May I ask you about repective kernel subsystem. > > If I use the file_operation method > > Provide user can read and write IOP(8051)'s register. > > Is this a repective kernel subsystem? > > if not > > There are other driver code can give me reference > > > > I still do not understand what the goal of this driver is. > When the poweroff command is executed. 1.The 8051 has a register to control the power-on and power-off of the system(Linux kernel). If you turn off the power through the 8051 register(DEF_PWR_EN_0=0), The current measured by the circuit board is 0.4mA only. In order to save power. 2.The power is not turned off through the 8051 register. The current measured on the circuit board is 33mA 3.When the system linux kerenl is powered off. /driver/rtc, /driver/gpio cannot operate. 8051 is still alive and operational 8051 has RTC register. When the time is up, 8051 powers on the system The 8051 can detect GPIO0~7 pins, and GPIO pin high/low can be used as a power-on judgment mechanism for the system. > What is the problem that you are needing to solve? What needs to access > this hardware, and what exactly was this hardware designed to do? > for example: SP7021 8051 has three power states:S0, S1 and S3. S0:Default domain(linux kernel) is on. IOP domain of 8051 is on. AO domain of 8051 is on. S1:Default domain(linux kernel) is off. IOP domain of 8051 is on. AO domain of 8051 is on. S3:Default domain(linux kernel) is off. IOP domain of 8051 is off. AO domain of 8051 is on. The user can use the 12bytes mailbox register to notify 8051.8051 needs to turn off which domain. I need custom miscdevice. User<--->misc/sunplus_iop<--->Hardware(8051)
