SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +#include "sun4i-a10-mk802.dtsi"
> +
> +/ {
> + model = "Rikomagic MK802+";
> + compatible = "rikomagic,mk802-1gb", "allwinner,sun4i-a10&qu
Hi Marcus,
On Fri, Nov 20, 2015 at 7:45 PM, Marcus Weseloh wrote:
> Hi Julian,
>
> 2015-11-19 23:59 GMT+01:00 Julian Calaby :
>> Should you possibly hide the 3 clock periods from the user?
>>
>> I.e. they set whatever they want for the wdelay, we set it to the
>
> SPI clock periods (plus a constant 3 clock periods) before transmitting
> the next word.
Should you possibly hide the 3 clock periods from the user?
I.e. they set whatever they want for the wdelay, we set it to the
closest number we can that's greater or equal to what they ask for.
Tha
Hi Maxime,
On Thu, Nov 5, 2015 at 3:23 AM, Maxime Ripard
wrote:
> Hi Julian,
>
> On Wed, Oct 28, 2015 at 10:12:09AM +1100, Julian Calaby wrote:
>> > + of_property_for_each_u32(node, "clock-indices", prop, p, index) {
>> > + of_property_
clk_parent = AHB1;
> + else if (index >= 64 && index <= 95)
> + clk_parent = APB1;
> + else if (index >= 96 && index <= 127)
> + clk_parent = APB2;
A way to make this reusable in the
clk_name[i] != '_' &&
> - clk_name[i] != '\0'; i++) {
> + clk_name[i] != '\0'; i++)
> base_name[i] = clk_name[i];
&
AXP288 power management IC (PMIC).
> + If you say Y here you get support for the X-Powers AXP series I2C
> + based power management ICs (PMICs).
> This driver include only the core APIs. You have to select
> individual
> components like regulators
have lost the actual warnings here.
> Please review and possibly fold the followup patch.
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the bod
Hi Maxime,
On Tue, Aug 25, 2015 at 3:14 PM, Maxime Ripard
wrote:
> On Tue, Aug 25, 2015 at 10:24:51AM +1000, Julian Calaby wrote:
>> Hi Maxime,
>>
>> On Tue, Aug 25, 2015 at 12:26 AM, Maxime Ripard
>> wrote:
>> > Hi,
>> >
>> > On Fri,
not, then yeah, we'll have to make another
> DTSI.
IMHO that's enough of a change to warrant a new DTSI, I feel that
someone's going to use the lack of DTSI as "proof" that we don't
support the R8 or try to use the tv encoder on an A13.
Thanks,
--
Julian
Hi Maxime,
On Mon, Aug 3, 2015 at 7:34 PM, Maxime Ripard
wrote:
> On Mon, Aug 03, 2015 at 11:03:52AM +0200, Timo Sigurdsson wrote:
>> Hi again,
>>
>> Julian Calaby schrieb am 03.08.2015 06:22:
>> > My only real objection here is are there boards that can go down
Hi Chen-Yu,
On Mon, Aug 3, 2015 at 12:37 PM, Chen-Yu Tsai wrote:
> Hi,
>
> On Mon, Aug 3, 2015 at 7:35 AM, Julian Calaby wrote:
>> Hi Timo,
>>
>> On Mon, Aug 3, 2015 at 5:23 AM, Timo Sigurdsson
>> wrote:
>>> sun7i-a20.dtsi contains an cpufreq operatin
ernatively, would it make sense to modify the code that uses this
to use frequencies with voltages specified that are lower than can be
supplied with the lowest voltage it can?)
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
--
To u
Hi Hans,
On Mon, Jun 22, 2015 at 6:28 PM, Hans de Goede wrote:
> Hi,
>
> On 22-06-15 02:30, Julian Calaby wrote:
>>
>> Hi Hans,
>>
>> On Sun, Jun 21, 2015 at 1:40 AM, Hans de Goede
>> wrote:
>>>
>>> u-boot will have turned on the power
t; harddisks.
Stupid question: shouldn't u-boot set this property?
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
Hi Jon,
On Wed, Jun 3, 2015 at 10:40 AM, jonsm...@gmail.com wrote:
> On Tue, Jun 2, 2015 at 8:35 PM, Julian Calaby wrote:
>> Hi Jon,
>>
>> On Wed, Jun 3, 2015 at 6:20 AM, jonsm...@gmail.com
>> wrote:
>>> Resend with plain text for image links
>>&g
G/tree/master/kernel/drivers/net/wireless/rda5990
(Code implies GPL but is missing copyright / license notices, might be
for an older part.)
On an unrelated note, is MediaTek buying up every last small
manufacturer of WiFi parts?
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile
the 3th phy, but not exactly the same bits so we need
> a new compatible for this.
Minor spelling note: it's "3rd" not "3th".
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
--
To unsubscribe from this lis
2f79f9e35b ("ahci_xgene: Removing NCQ support from the APM X-Gene
> SoC AHCI SATA Host Controller driver")
Won't this mean that the 1st HW version won't work properly?
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/prof
jected as the maximum transfer size is a
property of the SPI controller, not the device and should be exported
to the device driver from the controller, not specified in the
device's binding.
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles
ff ff 49 89 c5 e9 ce fd ff ff 31 c0 90 e9 74 ff
> ff ff 49 c7 04 04 00 00 00 00 e9 05 ff ff ff 4c 89 e7 ff d0 e9 d9 fe ff ff
> <0f> 0b 4c 8b 73 38 44 89 e7 81 cf 00 00 20 00 4c 89 f6 48 c1 ee
> [0.028000] RIP [] new_slab+0x30c/0x3c0
> [0.028000] RSP
> [0.028039] ---[ en
USB_MUSB_SUNXI
> tristate "Allwinner (sunxi)"
> depends on ARCH_SUNXI
> + depends on NOP_USB_XCEIV
Shouldn't this be in a different patch?
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
--
To unsubsc
clk_disable_unprepare(ir->clk);
> clk_disable_unprepare(ir->apb_clk);
> + if (ir->rst)
> + reset_control_assert(ir->rst);
>
> spin_lock_irqsave(&ir->ir_lock, flags);
> /* disable IR IRQ */
> --
> 2.1.0
>
re infinite nodes in the devicetree,
>>> which would make the devicetree infinitely large, so this will never happen.
>>
>> If there are 1 frame buffers, the loop will continue beyond that,
>> as the index will be truncated to 4 digits due to the size of name[].
>&
(ret)
> + return ret;
> +
> + for (i = 0; ; i++) {
> + snprintf(name, sizeof(name), "framebuffer%d", i);
This smells like an infinite loop: we can be pretty sure that no
hardware will ever exist with more than (I think?) framebuffers,
ommand
> at the right point in the bootscript. It is also not fatal if the
> command is inserted at the wrong point, things will just needlessly
> flicker. It not even fatal if you never run this command, you'll just
> leave clocks/regulators turned on that could be turned off.
26 matches
Mail list logo
