First of all, thanks for looking at the patch! On Saturday 4. April 2015 18.42.45 Daniel Glöckner wrote: > Hi, > > No Signed-off-by line?
Remember: I don't do kernel development, but I imagine that this has to be signed off by someone who is a regular committer, so there isn't any sign-off at the moment. Otherwise, I don't understand the significance of Signed-off- by. > On Sat, Apr 04, 2015 at 02:15:57PM +0200, Paul Boddie wrote: > > If anyone can see any obvious things that prevent these changes from > > making a bootable kernel, I'd be very pleased to hear about them. > > You need a spinlock to prevent a race condition when two processes > want to access the GPIOs at the same time. That's why they introduced > set and clear registers in the 4740. OK. So to put this into context, you mean that the various jz_gpio_* functions, when accessing the combined registers used to set different properties of the GPIO pins, need to acquire spinlocks around those operations? > For reading the battery voltage and powering off the device, you can > use the driver from the following mail. I used it with the 2.6.31 > Kernel (after fixing the non-standard API of the I2C driver). OK, I'll take a look, thanks! I didn't really look at the I2C code in the 2.6 kernel. > The Linux 2.4 USB gadget driver for the 4730 looks completely different > from the 4740 driver. I don't think is uses the same IP core. I'll take your word for it: I think that the jz4740 used to use different USB code, but it appears to use the musb framework now. Whether there are significant differences between the old jz4740 code and the 2.6 kernel for the jz4730, I don't know. > If the plan is to eventually switch to DT, it must be possible to > compile a kernel that can handle both the 4740 and the 4730. So > defining macros to different values depending on the processor is > not an option. My impression was that DT does things as declaratively as possible, and so the differing values would be expressed in the various device declarations. I guess we'd have to revisit this when switching, but no-one appears to be ready at the moment (or I haven't seen a repository exhibiting complete readiness, anyway). Paul _______________________________________________ Mipsbook-devel mailing list Mipsbook-devel@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/mipsbook-devel
