Hi Paul, Am 04.04.2015 um 19:42 schrieb Paul Boddie <p...@boddie.org.uk>:
> 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. It is different what you (and I did the same mistake for a while) indicates. It just means that you have written it or pass it along and has nothing to do directly with “quality” or “regular committer”. Here is the exact definition: https://www.kernel.org/doc/Documentation/SubmittingPatches > To improve tracking of who did what, especially with patches that can > percolate to their final resting place in the kernel through several > layers of maintainers, we've introduced a "sign-off" procedure on > patches that are being emailed around. > > The sign-off is a simple line at the end of the explanation for the > patch, which certifies that you wrote it or otherwise have the right to > pass it on as an open-source patch. The rules are pretty simple: if you > can certify the below: > > Developer's Certificate of Origin 1.1 > > By making a contribution to this project, I certify that: > > (a) The contribution was created in whole or in part by me and I > have the right to submit it under the open source license > indicated in the file; or > > (b) The contribution is based upon previous work that, to the best > of my knowledge, is covered under an appropriate open source > license and I have the right under that license to submit that > work with modifications, whether created in whole or in part > by me, under the same open source license (unless I am > permitted to submit under a different license), as indicated > in the file; or > > (c) The contribution was provided directly to me by some other > person who certified (a), (b) or (c) and I have not modified > it. > > (d) I understand and agree that this project and the contribution > are public and that a record of the contribution (including all > personal information I submit with it, including my sign-off) is > maintained indefinitely and may be redistributed consistent with > this project or the open source license(s) involved. Since this is clearly a case (a) I think it is ok that you can sign off the patch. If I were to submit it to LKML it would be case (c) and I would sign it as well. > >> 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? Yes, I also think so. > >> 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. musb (was) is for a specific VHDL macro by Mentor Graphics for USB/OTG controllers. The OMAP processors have it and OMAP3530 TRM says “The High-Speed USB OTG Controller is an instantiation of the MUSBMHDRC from Mentor Graphics Corporation.” So we have to check what Ingenic did. They may also have licensed the Mentor Graphics VHDL for the jz4730. Then we can assume they are very similar (except for an older version or a different base address of the controller registers). > 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). Exactly. DT would try to replace the macros that define register base addresses by code to query the DT. And different DTs for SoC can then specify the right address. But this major code rework has to be done first… Maybe our project has to do that unless some other project is working on the jz4740. BR, Nikolaus _______________________________________________ Mipsbook-devel mailing list Mipsbook-devel@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/mipsbook-devel
