On Wed, 4 Sep 2019 at 13:56, Damien Hedde <damien.he...@greensocs.com> wrote: > > Switch the slcr to multi-phase reset and add some clocks: > + the main input clock (ps_clk) > + the reference clock outputs for each uart (uart0 & 1) > > The clock frequencies are computed using the internal pll & uart configuration > registers and the ps_clk frequency. > > Signed-off-by: Damien Hedde <damien.he...@greensocs.com>
Review of this and the following two patches by some Xilinx person would be nice. I've just looked them over for general issues, and haven't checked against the hardware specs. > --- > +/* > + * return the output frequency of a clock given: > + * + the frequencies in an array corresponding to mux's indexes > + * + the register xxx_CLK_CTRL value > + * + enable bit index in ctrl register > + * > + * This function make the assumption that ctrl_reg value is organized as > follow: "makes"; "that the"; "follows" > + * + bits[13:8] clock divisor > + * + bits[5:4] clock mux selector (index in array) > + * + bits[index] clock enable > + */ > +static uint64_t zynq_slcr_compute_clock(const uint64_t mux[], > + uint32_t ctrl_reg, > + unsigned index) > +{ > + uint32_t srcsel = extract32(ctrl_reg, 4, 2); /* bits [5:4] */ > + uint32_t divisor = extract32(ctrl_reg, 8, 6); /* bits [13:8] */ > + > + /* first, check if clock is enabled */ > + if (((ctrl_reg >> index) & 1u) == 0) { > + return 0; > + } > + > + /* > + * according to the Zynq technical ref. manual UG585 v1.12.2 in > + * "Clocks" chapter, section 25.10.1 page 705" the range of the divisor > + * is [1;63]. Is this the range notation the spec doc uses? > + * So divide the source while avoiding division-by-zero. > + */ > + return mux[srcsel] / (divisor ? divisor : 1u); > +} > + > +static const ClockPortInitArray zynq_slcr_clocks = { > + QDEV_CLOCK_IN(ZynqSLCRState, ps_clk, zynq_slcr_ps_clk_callback), > + QDEV_CLOCK_OUT(ZynqSLCRState, uart0_ref_clk), > + QDEV_CLOCK_OUT(ZynqSLCRState, uart1_ref_clk), > + QDEV_CLOCK_END > +}; > + > static void zynq_slcr_init(Object *obj) > { > ZynqSLCRState *s = ZYNQ_SLCR(obj); > @@ -425,6 +559,8 @@ static void zynq_slcr_init(Object *obj) > memory_region_init_io(&s->iomem, obj, &slcr_ops, s, "slcr", > ZYNQ_SLCR_MMIO_SIZE); > sysbus_init_mmio(SYS_BUS_DEVICE(obj), &s->iomem); > + > + qdev_init_clocks(DEVICE(obj), zynq_slcr_clocks); > } > > static const VMStateDescription vmstate_zynq_slcr = { > @@ -440,9 +576,12 @@ static const VMStateDescription vmstate_zynq_slcr = { > static void zynq_slcr_class_init(ObjectClass *klass, void *data) > { > DeviceClass *dc = DEVICE_CLASS(klass); > + ResettableClass *rc = RESETTABLE_CLASS(klass); > > dc->vmsd = &vmstate_zynq_slcr; > - dc->reset = zynq_slcr_reset; > + rc->phases.init = zynq_slcr_reset_init; > + rc->phases.hold = zynq_slcr_reset_hold; > + rc->phases.exit = zynq_slcr_reset_exit; > } We're adding an input clock, so doesn't the migration state struct need to be updated to migrate it ? thanks -- PMM