On Wednesday 09 November 2016 02:36 PM, John Garry wrote:
I'd suggest requiring #address-cells=<1> and #size-cells=<0> in the
master
node, and listing the children by reg property. If the address is not
easily expressed as a single integer, use a larger #address-cells
value.
We already have
On Wednesday 09 November 2016 02:36 PM, John Garry wrote:
I'd suggest requiring #address-cells=<1> and #size-cells=<0> in the
master
node, and listing the children by reg property. If the address is not
easily expressed as a single integer, use a larger #address-cells
value.
We already have
On Thursday 10 November 2016 03:10 AM, Arnd Bergmann wrote:
On Wednesday, November 9, 2016 9:58:38 AM CET Anurup M wrote:
I also see that the compatible strings have the version included in
them, and you can probably drop them by requiring them only in the
fallback:
compatible =
On Thursday 10 November 2016 03:10 AM, Arnd Bergmann wrote:
On Wednesday, November 9, 2016 9:58:38 AM CET Anurup M wrote:
I also see that the compatible strings have the version included in
them, and you can probably drop them by requiring them only in the
fallback:
compatible =
On Wednesday, November 9, 2016 9:58:38 AM CET Anurup M wrote:
>
> > I also see that the compatible strings have the version included in
> > them, and you can probably drop them by requiring them only in the
> > fallback:
> >
> > compatible = "hisilicon,hip05-cpu-djtag",
On Wednesday, November 9, 2016 9:58:38 AM CET Anurup M wrote:
>
> > I also see that the compatible strings have the version included in
> > them, and you can probably drop them by requiring them only in the
> > fallback:
> >
> > compatible = "hisilicon,hip05-cpu-djtag",
On Tuesday 08 November 2016 08:40 PM, Arnd Bergmann wrote:
On Tuesday, November 8, 2016 1:49:43 PM CET John Garry wrote:
Hi Arnd,
Thanks for the reference.
I think the i2c interface doesn't fully satisfy our requirements as we
need more than just a slave bus address when accessing the slave
On Tuesday 08 November 2016 08:40 PM, Arnd Bergmann wrote:
On Tuesday, November 8, 2016 1:49:43 PM CET John Garry wrote:
Hi Arnd,
Thanks for the reference.
I think the i2c interface doesn't fully satisfy our requirements as we
need more than just a slave bus address when accessing the slave
I'd suggest requiring #address-cells=<1> and #size-cells=<0> in the
master
node, and listing the children by reg property. If the address is not
easily expressed as a single integer, use a larger #address-cells
value.
We already have something equivalent to reg in "module-id" (see patch
I'd suggest requiring #address-cells=<1> and #size-cells=<0> in the
master
node, and listing the children by reg property. If the address is not
easily expressed as a single integer, use a larger #address-cells
value.
We already have something equivalent to reg in "module-id" (see patch
On Tuesday 08 November 2016 08:38 PM, Arnd Bergmann wrote:
On Tuesday, November 8, 2016 7:16:30 PM CET Anurup M wrote:
If these are backwards compatible, just mark them as compatible in DT,
e.g. hip06 can use
compatible = "hisilicon,hip06-cpu-djtag-v1", "hisilicon,hip05-cpu-djtag-v1";
On Tuesday 08 November 2016 08:38 PM, Arnd Bergmann wrote:
On Tuesday, November 8, 2016 7:16:30 PM CET Anurup M wrote:
If these are backwards compatible, just mark them as compatible in DT,
e.g. hip06 can use
compatible = "hisilicon,hip06-cpu-djtag-v1", "hisilicon,hip05-cpu-djtag-v1";
On Tuesday 08 November 2016 05:15 PM, Arnd Bergmann wrote:
On Tuesday, November 8, 2016 11:23:35 AM CET John Garry wrote:
On 07/11/2016 20:08, Arnd Bergmann wrote:
On Monday, November 7, 2016 2:15:10 PM CET John Garry wrote:
Hi Arnd,
The new bus type tries to model the djtag in a similar
On Tuesday 08 November 2016 05:15 PM, Arnd Bergmann wrote:
On Tuesday, November 8, 2016 11:23:35 AM CET John Garry wrote:
On 07/11/2016 20:08, Arnd Bergmann wrote:
On Monday, November 7, 2016 2:15:10 PM CET John Garry wrote:
Hi Arnd,
The new bus type tries to model the djtag in a similar
On 08/11/2016 15:10, Arnd Bergmann wrote:
On Tuesday, November 8, 2016 1:49:43 PM CET John Garry wrote:
Hi Arnd,
Thanks for the reference.
I think the i2c interface doesn't fully satisfy our requirements as we
need more than just a slave bus address when accessing the slave device
(which I
On 08/11/2016 15:10, Arnd Bergmann wrote:
On Tuesday, November 8, 2016 1:49:43 PM CET John Garry wrote:
Hi Arnd,
Thanks for the reference.
I think the i2c interface doesn't fully satisfy our requirements as we
need more than just a slave bus address when accessing the slave device
(which I
On Tuesday, November 8, 2016 1:49:43 PM CET John Garry wrote:
>
> Hi Arnd,
>
> Thanks for the reference.
>
> I think the i2c interface doesn't fully satisfy our requirements as we
> need more than just a slave bus address when accessing the slave device
> (which I think is what i2c uses). We
On Tuesday, November 8, 2016 1:49:43 PM CET John Garry wrote:
>
> Hi Arnd,
>
> Thanks for the reference.
>
> I think the i2c interface doesn't fully satisfy our requirements as we
> need more than just a slave bus address when accessing the slave device
> (which I think is what i2c uses). We
On Tuesday, November 8, 2016 7:16:30 PM CET Anurup M wrote:
> If these are backwards compatible, just mark them as compatible in DT,
> e.g. hip06 can use
>
> compatible = "hisilicon,hip06-cpu-djtag-v1",
> "hisilicon,hip05-cpu-djtag-v1";
>
> so you can tell
On Tuesday, November 8, 2016 7:16:30 PM CET Anurup M wrote:
> If these are backwards compatible, just mark them as compatible in DT,
> e.g. hip06 can use
>
> compatible = "hisilicon,hip06-cpu-djtag-v1",
> "hisilicon,hip05-cpu-djtag-v1";
>
> so you can tell
On 08/11/2016 11:45, Arnd Bergmann wrote:
On Tuesday, November 8, 2016 11:23:35 AM CET John Garry wrote:
On 07/11/2016 20:08, Arnd Bergmann wrote:
On Monday, November 7, 2016 2:15:10 PM CET John Garry wrote:
Hi Arnd,
The new bus type tries to model the djtag in a similar way to I2C/USB
On 08/11/2016 11:45, Arnd Bergmann wrote:
On Tuesday, November 8, 2016 11:23:35 AM CET John Garry wrote:
On 07/11/2016 20:08, Arnd Bergmann wrote:
On Monday, November 7, 2016 2:15:10 PM CET John Garry wrote:
Hi Arnd,
The new bus type tries to model the djtag in a similar way to I2C/USB
On Tuesday 08 November 2016 05:13 PM, Arnd Bergmann wrote:
On Tuesday, November 8, 2016 1:08:31 PM CET Anurup M wrote:
On Tuesday 08 November 2016 12:32 PM, Tan Xiaojun wrote:
On 2016/11/7 21:26, Arnd Bergmann wrote:
On Wednesday, November 2, 2016 11:42:46 AM CET Anurup M wrote:
From:
On Tuesday 08 November 2016 05:13 PM, Arnd Bergmann wrote:
On Tuesday, November 8, 2016 1:08:31 PM CET Anurup M wrote:
On Tuesday 08 November 2016 12:32 PM, Tan Xiaojun wrote:
On 2016/11/7 21:26, Arnd Bergmann wrote:
On Wednesday, November 2, 2016 11:42:46 AM CET Anurup M wrote:
From:
On Tuesday, November 8, 2016 11:23:35 AM CET John Garry wrote:
> On 07/11/2016 20:08, Arnd Bergmann wrote:
> > On Monday, November 7, 2016 2:15:10 PM CET John Garry wrote:
> >>
> >> Hi Arnd,
> >>
> >> The new bus type tries to model the djtag in a similar way to I2C/USB
> >> driver arch, where we
On Tuesday, November 8, 2016 1:08:31 PM CET Anurup M wrote:
> On Tuesday 08 November 2016 12:32 PM, Tan Xiaojun wrote:
> > On 2016/11/7 21:26, Arnd Bergmann wrote:
> >> On Wednesday, November 2, 2016 11:42:46 AM CET Anurup M wrote:
> >>> From: Tan Xiaojun
> >>> + /*
On Tuesday, November 8, 2016 11:23:35 AM CET John Garry wrote:
> On 07/11/2016 20:08, Arnd Bergmann wrote:
> > On Monday, November 7, 2016 2:15:10 PM CET John Garry wrote:
> >>
> >> Hi Arnd,
> >>
> >> The new bus type tries to model the djtag in a similar way to I2C/USB
> >> driver arch, where we
On Tuesday, November 8, 2016 1:08:31 PM CET Anurup M wrote:
> On Tuesday 08 November 2016 12:32 PM, Tan Xiaojun wrote:
> > On 2016/11/7 21:26, Arnd Bergmann wrote:
> >> On Wednesday, November 2, 2016 11:42:46 AM CET Anurup M wrote:
> >>> From: Tan Xiaojun
> >>> + /* ensure the djtag operation
On 07/11/2016 20:08, Arnd Bergmann wrote:
On Monday, November 7, 2016 2:15:10 PM CET John Garry wrote:
Hi Arnd,
The new bus type tries to model the djtag in a similar way to I2C/USB
driver arch, where we have a host bus adapter and child devices attached
to the bus. The child devices are bus
On 07/11/2016 20:08, Arnd Bergmann wrote:
On Monday, November 7, 2016 2:15:10 PM CET John Garry wrote:
Hi Arnd,
The new bus type tries to model the djtag in a similar way to I2C/USB
driver arch, where we have a host bus adapter and child devices attached
to the bus. The child devices are bus
On Tuesday 08 November 2016 12:32 PM, Tan Xiaojun wrote:
On 2016/11/7 21:26, Arnd Bergmann wrote:
On Wednesday, November 2, 2016 11:42:46 AM CET Anurup M wrote:
From: Tan Xiaojun
The Hisilicon Djtag is an independent component which connects
with some
On Tuesday 08 November 2016 12:32 PM, Tan Xiaojun wrote:
On 2016/11/7 21:26, Arnd Bergmann wrote:
On Wednesday, November 2, 2016 11:42:46 AM CET Anurup M wrote:
From: Tan Xiaojun
The Hisilicon Djtag is an independent component which connects
with some other components in the
On 2016/11/7 21:26, Arnd Bergmann wrote:
> On Wednesday, November 2, 2016 11:42:46 AM CET Anurup M wrote:
>> From: Tan Xiaojun
>>
>> The Hisilicon Djtag is an independent component which connects
>> with some other components in the SoC by Debug Bus. This driver
On 2016/11/7 21:26, Arnd Bergmann wrote:
> On Wednesday, November 2, 2016 11:42:46 AM CET Anurup M wrote:
>> From: Tan Xiaojun
>>
>> The Hisilicon Djtag is an independent component which connects
>> with some other components in the SoC by Debug Bus. This driver
>> can be
On Monday, November 7, 2016 2:15:10 PM CET John Garry wrote:
>
> Hi Arnd,
>
> The new bus type tries to model the djtag in a similar way to I2C/USB
> driver arch, where we have a host bus adapter and child devices attached
> to the bus. The child devices are bus driver devices and have bus
>
On Monday, November 7, 2016 2:15:10 PM CET John Garry wrote:
>
> Hi Arnd,
>
> The new bus type tries to model the djtag in a similar way to I2C/USB
> driver arch, where we have a host bus adapter and child devices attached
> to the bus. The child devices are bus driver devices and have bus
>
On 07/11/2016 13:26, Arnd Bergmann wrote:
On Wednesday, November 2, 2016 11:42:46 AM CET Anurup M wrote:
From: Tan Xiaojun
The Hisilicon Djtag is an independent component which connects
with some other components in the SoC by Debug Bus. This driver
On 07/11/2016 13:26, Arnd Bergmann wrote:
On Wednesday, November 2, 2016 11:42:46 AM CET Anurup M wrote:
From: Tan Xiaojun
The Hisilicon Djtag is an independent component which connects
with some other components in the SoC by Debug Bus. This driver
can be configured
On Wednesday, November 2, 2016 11:42:46 AM CET Anurup M wrote:
> From: Tan Xiaojun
>
> The Hisilicon Djtag is an independent component which connects
> with some other components in the SoC by Debug Bus. This driver
> can be configured to access the
On Wednesday, November 2, 2016 11:42:46 AM CET Anurup M wrote:
> From: Tan Xiaojun
>
> The Hisilicon Djtag is an independent component which connects
> with some other components in the SoC by Debug Bus. This driver
> can be configured to access the registers of connecting
Hi Tan,
[auto build test ERROR on linus/master]
[also build test ERROR on v4.9-rc3 next-20161028]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
[Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for
convenience) to record what
Hi Tan,
[auto build test ERROR on linus/master]
[also build test ERROR on v4.9-rc3 next-20161028]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
[Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for
convenience) to record what
From: Tan Xiaojun
The Hisilicon Djtag is an independent component which connects
with some other components in the SoC by Debug Bus. This driver
can be configured to access the registers of connecting components
(like L3 cache) during real
From: Tan Xiaojun
The Hisilicon Djtag is an independent component which connects
with some other components in the SoC by Debug Bus. This driver
can be configured to access the registers of connecting components
(like L3 cache) during real time debugging.
44 matches
Mail list logo