On Thu, 2016-03-03 at 08:39 +, Peter Maydell wrote:
> On 3 March 2016 at 05:14, Andrew Jeffery wrote:
> >
> > On Thu, 2016-02-25 at 16:29 +, Peter Maydell wrote:
> > >
> > > >
> > > > +case 0x20: /* Interrupt Enable */
> > > > +s->int_enable |= data;
> > >
On 3 March 2016 at 05:14, Andrew Jeffery wrote:
> On Thu, 2016-02-25 at 16:29 +, Peter Maydell wrote:
>> > +case 0x20: /* Interrupt Enable */
>> > +s->int_enable |= data;
>>
>> Are you sure this only ORs in new 1 bits?
>
> As in, am I sure I only want to take the
On Thu, 2016-02-25 at 16:29 +, Peter Maydell wrote:
> > +case 0x20: /* Interrupt Enable */
> > +s->int_enable |= data;
>
> Are you sure this only ORs in new 1 bits?
As in, am I sure I only want to take the newly set bits? If so, yes, as
the the following register serves to clear
On 2 March 2016 at 01:09, Andrew Jeffery wrote:
> Hi Peter,
>
> On Thu, 2016-02-25 at 16:29 +, Peter Maydell wrote:
>> On 16 February 2016 at 11:34, Andrew Jeffery wrote:
>> > +#define AVIC_L_MASK 0x
>>
>> This needs a 'U' suffix or at least one of
Hi Peter,
On Thu, 2016-02-25 at 16:29 +, Peter Maydell wrote:
> On 16 February 2016 at 11:34, Andrew Jeffery wrote:
> > Implement a minimal ASPEED AVIC device model, enough to boot a Linux
> > kernel configured with aspeed_defconfig. The VIC implements the 'new'
> >
On 16 February 2016 at 11:34, Andrew Jeffery wrote:
> Implement a minimal ASPEED AVIC device model, enough to boot a Linux
> kernel configured with aspeed_defconfig. The VIC implements the 'new'
> register set and expects this to be reflected in the device tree.
What do we mean